Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Navitabs
rootSundhedsvæsenets Nationale Erstatnings-CPR (Nationalt eCPR) - Leverancebeskrivelse
includeroottrue

Overblik over servicen


Nedstående diagram viser opbygningen af FGVHR-servicenIndholdsfortegnelse:

Gliffy Diagramtoc
macroIdb3d2a3f5-05db-4e36-8dad-bf88e6e539d8
displayNameFGVHR-Overblik
nameFGVHR-Overblik
pageid203266871

Sikkerhed

Brugertyper

Der findes følgende brugertyper i FGVHR:

  • Borger
  • Administrativ

De enkelte brugertyper bestemmes udfra modellen, der udstilles i Security API. Disse regler er opsummeret i tabellerne nedenfor.

...

Database model

Datamodel

Datamodellen består af en tabel der hedder 'citizen_consent' og den har følgende kolonner:

...


Introduktion

Dette er en foreløbig beskrivelse, med rettelser på vej. 

Formålet med dette dokument er at beskrive systemarkitekturen for Nationalt eCPR.

Dokumentet er tiltænkt udviklere og IT-arkitekter med interesse i Nationalt eCPR og dens opbygning. Siden indeholder primært information om Nationalt eCPR-servicen i forhold til dens relationer til andre systemer

Introduktion til eCPR

Løsningens Afhængigheder

Nationalt eCPR anvender følgende NSP komponenter:

Komponent

Beskrivelse

DCC

DCC (DeCoupling Component), også kendt som SOSI afkoblingskomponenten, fungerer som en webservice gateway og foretager routing af forespøgsler mod services der udstilles på eller via NSP'en. 

NAS

National Adviseringsservice på NSP'en funger som en afkoblet system-til-system advisering gennem et "publish-subscribe"-mønster

SEB

Sundhedsvæsenets Elektroniske Brugerstyring er en fælles platform for brugeradministration af forskellige sundhedsfaglige systemer. SEB vil blive brugt i Nationalt eCPR til udstilling af nationale roller som understøtter anvendersystemernes brugerrettighedsstyring mod Nationalt eCPR. Denne tilgåes via Acces Handler

Status
subtletrue
titleto be
SEB implementeres når Nationalt eCPR flyttes til NSP platformen.

SDM

Stamdatamodul på NSP består af 6 registreservices, hvor eCPR gør brug af SCES servicen (se nedenfor) og Stamdata Kopi register Service (SKRS) databasen, hvor den tilgår Bemyndigelsesregisteret, CPR registeret og authorisationsregisteret gennem 3 views (Se eCPR - Installationsvejledning

SCES

CPR-enkeltopslag er en realisering af MedCom-standarden 'Det Gode CPR Opslag'

eCPR2 importer

eCPR2 importer bruges til at lægge eCPR stamdata i KRS-databasen. Dette foregår ved, at brugere indsender data til eCPR2-servicen, hvorefter eCPR2 servicen eksporterer dette data via et job, og lægger det i et filsystem på NSP'en. eCPR2 Importeren læser data fra dette export og lægger det i databasen hvorefter SKRS servicen udstiller dette data.

Løsningens opbygning

Nationalt eCPR består af én javabaseret web-service, nemlig eCPR-service. Den udstilles på NSP via DCC, og udstiller ligeledes adviseringer gennem NAS på NSP. For at servicen fungerer har den ligeledes en ekstern afhængighed til NSP stamdata gennem views, herunder SCES (CPR-enkeltopslag).  I nedenstående diagram ses et arkitektur overblik over servicen og dens eksterne afhængigheder:


Image Added

Både service og dataformater for Nationalt eCPR er udviklet til at være generelle og fleksible, så de kan understøtte forskellige scenarier for brug, og implementeringsstrategier på tværs af sundhedsvæsenets aktører.

Nationalt eCPR-service er beskrevet i eCPR - Snitfladebeskrivelse

Dataformater er beskrevet under NSP stamdataregistre her.

Sekvensdiagrammer

Nedenfor ses 2 sekvensdisagrammer. De blå komponenenter hører alle til eCPR-servicen, og illustrerer hvordan flowet overordnet set forløber internt, uden at gå i detaljer med implementationen.

Sekvensdiagrammet for CreatePersonRequest ses nedenfor.

Gliffy Diagram
displayNamesd eCPR - Opret person
namesd eCPR - Opret person
pagePin11

I forløbet "CreatePerson" bruges Cpr-enkeltopslag samt NAS ikke. I sekvensdiagrammet for UpdatePersonRequest ses hvordan Cpr-enkeltopslag og NAS bruges i et UpdatePerson kald. Cpr-enkeltopslag bruges kun, hvis UpdatePerson indeholder et CPR-nummer, hvorved der bliver tjekket op mod stamdata, om CPR-nummeret eksisterer. I nedenstående sekvensdiagram antages det, at UpdatePersonRequest laves med et medsendt CPR-nummer:

Gliffy Diagram
macroId98e5eb2c-53c2-4f9e-aefb-da9af43061cd
displayNamesd eCPR - UpdatePerson
namesd eCPR - UpdatePerson
pagePin5

Sikkerhed

Sikkerhedsmodellen for National eCPR er baseret på MedComs “Den Gode Webservice” og brug af SOSI-Gateway. Sundhedsfaglige brugere anvender SOSI sikkerhedsmodellen, hvor adgang gives via lokale fagsystemer og udveksles med NSP infrastrukturen, herunder Nationalt eCPR, således sundhedsfaglige brugere er identificeret med navn, rolle og organisation. Sundhedsfaglige brugere får udstedt erhvervsidentiteter via de organisationer de er tilknyttet. Disse erhvervsidentiteter vedhæftes i SOSI sikkerhedsmodellen.

NSP Sikkerhedsservices (STS)

Forretningsrelateret data

Data, der anvendes forretningsmæssigt, f.eks. sygehusafdelingsnummer, ydernummer og autorisations­nummer, bør medsendes i den forretningsmæssige del af dokumentet, og ikke hentes fra dokumentheaderen. Det kan ikke udelukkes at f.eks.:

  • En sekretær på en sygehusafdeling logger ind med SKS-sygehusafdelingsnummer med 6 cifre og foretager en opdatering af data på et afsnit angivet med 7 cifre

  • En lægepraksis har to ydernumre, der logges ind med det ene men sendes data for begge.

Skal der senere opstilles regler for hvorvidt dette skal være muligt bør valideringen af disse regler holdes adskilt fra den forretningsmæssige implementering. Dette bør ske for at minimere risikoen for at ændringer i sikkerhedsmodellen påvirker denne.

Adgangsstyring

Excerpt Include
eCPR - Roller og rettigheder
eCPR - Roller og rettigheder

Formater 

Excerpt Include
eCPR - Formater (X-eCPR og D-eCPR)
eCPR - Formater (X-eCPR og D-eCPR)
nopaneltrue

Typebestemmelse med OID'er

Excerpt Include
eCPR - OIDer
eCPR - OIDer
nopaneltrue

Beslutninger ift. arkitektur og jura

I følgende tabel er listet beslutninger, som har indvirkning på arkitekturen bag Nationalt eCPR.

DatoEmneProblem, beskrivelse og beslutningAfklaret med

 

Opbevaring af data

Problem
Hvor længe må data opbevares i eCPR?

Beskrivelse
Da en patient kan komme i kontakt med sundhedsvæsenet af flere omgange, og det centralt ikke vides om der sker kontakt decentralt, kan man ikke vide centralt om eCPR-nummeret fortsat er i brug.

Beslutning
Der er ingen udløb på opbevarings tid for data i eCPR. Data slettes ikke.

SDS's juridiske afdeling

 

Genbrug af eCPR-numre

Problem
Hvis et eCPR-nummer bliver 'erstattet' af et CPR-nummer, kan eCPR-nummeret så frigives til en ny patient?

Beskrivelse
Oplysningerne overføres til den rigtige patientjournal, når en ukendt patient identificeres. Hvis der er tale om flygtninge, der ved godkendelse af ophold får et CPR-nummer, oprettes også en ny journal på dette CPR-nummer og data overføres hertil. Dermed vil der være eCPR-numre, der ikke længere er i aktivt brug. 

Dog kan der stadig være lokale journaler hos andre aktører som endnu ikke har fået omlagt patientjournalen. Hvis eCPR-nummeret 'genbruges' til en ny patient risikerer man derfor at flere patienters journaler samkøres; at 'gammelt data kobles på ny patient'.

Beslutning
eCPR-nummeret benyttes kun én gang og CPR-nummeret registreres på personregistreringen, så identifikationen er entydig på tværs af eCPR-nummer og CPR-nummer.

SDS's juridiske afdeling

 

Autorisation

Problem
Er autorisation påkrævet for adgang til og brug af eCPR?

Beskrivelse
Der bliver udstedt et eCPR-nummer når en patient uden CPR-nummer skal modtage en behandling (og de ikke allerede har et eCPR-nummer). Dette sker i deres møde med sundhedsvæsenet, enten hos en praksislæge, i lægevagten, på et sygehus eller lignende. Det er dog ofte en administrativ person (fx en lægesekretær) der udfører opgaven med at trække eCPR nummeret. Derefter bruges det på samme vis som et CPR nummer, når der kommunikeres mellem parterne (fx til apoteket).

Beslutning
eCPR kan udstedes af forskellige personalegrupper med og uden autorisation. 

SDS's juridiske afdeling

 

Brug af eCPR udenfor sundhedsvæsenet

Problem
Må andre myndigheder udenfor sundhedsvæsenet få adgang til Nationalt eCPR?

Beskrivelse
Det er ikke kun i sundhedsvæsenet at man har brug for erstatningspersonnumre til registrering af personer uden CPR-nummer. SDS har dog alene hjemmel til at udstede eCPR-numre til brug indenfor sundhedsvæsenet. Hvis andre mydigheder ønsker adgang, skal den konkrete henvendelse behandles, med det formål at afklare hvad der teknisk og/eller hjemmelsmæssigt skal til for at imødekomme ønsket. Pt. er det ikke i scope.

Beslutning
Brug af Nationalt eCPR af andre myndigheder udenfor sundhedsvæsenet er ikke indenfor nuværende scope.

SDS's juridiske afdeling

 

Log i MinLog Borgerlog 

Problem
Skal adgang og ændringer til en personregistrering i Nationalt eCPR register logges i MinLog Borgerlog?

Beskrivelse
Der er pt ingen patienter med eCPR-nummer der kan få adgang til at kigge i borgerloggen, da dette kræver en sammenknytning af et eID og en personregistrering i Nationalt eCPR. En patient med et Nationalt eCPR-nummer vil heller ikke kunne få elektronisk adgang til sundhedsdata registreret i andre systemer, såsom lokale EPJ og FMK. Patienten vil kunne få adgang til disse oplysninger vi procedurer i disse systemer.

Tilgang til og ændringer i CPR-registreret logges heller ikke i MinLog Borgerlog.

Beslutning
Adgang og ændringer til en personregistrering i Nationalt eCPR logges ikke i MinLog Borgerlog.

SDS's juridiske afdeling

 

Log i MinLog Medhjælpslog

Problem
Skal adgang og ændringer til en personregistrering i Nationalt eCPR register logges i MinLog Medhjælpslog?

Beskrivelse
Ved bemyndigelse af en medhjælp, f.eks. ved opslag i FMK-online, har sundhedspersonen pligt til at følge op på hvad medhjælpen har foretages sig. Dertil benyttes medhjælpsloggen, hvor det ikke sker i eget system men på en webbrugerflade. Gælder det samme for Nationalt eCPR?

Beslutning
Der er ikke pligt til opfølgning på bemyndigede ved brug af selve udstedelsesservicen. Derfor logges en bemyndigets adgang og ændringer til en personregistrering i Nationalt eCPR ikke i MinLog Medhjælpslog.

SDS's juridiske afdeling

 

Anvendelse af SKRS

Problem
Må eCPR data replikeres med SKRS?

Beskrivelse
Brug af SKRS vil give mulighed for at tage en kopi af Nationalt eCPR og opbevare den lokalt.

SKRS bruges bl.a. til at have en lokale kope af CPR registret i dag.

Beslutning
Brugen af SKRS for Nationalt eCPR skal lægges så tæt op ad brugen af SKRS for CPR som muligt. 

SDS's juridiske afdeling

 

Begrænsning i brug af datamodellen

Problem
Datamodellen blev oprindeligt udarbejdet med det formål at kunne rumme meget divers information, men var alt informationen brugbar i den kliniske hverdag?

Beskrivelse
Datamodellen er oprindeligt udarbejdet med mulighed for at angive mange forskellige typer af navn, adresse og kontaktinformation. I slutbrugergruppen blev der peget på, at man skal opveje klinikernes tid ift. indtastning af data, ift. hvor brugbare disse data er senere. Alle data tilknyttet en personregistrering i Nationalt eCPR, har udelukkende det formål at understøtte en fremsøgning af patientens eksisterende personregistrering.

Da der ikke sker en automatisk opdatering af data, og da patienten ikke selv har adgang til at vedligeholde data i Nationalt eCPR, er adresse og kontaktinformation forældet med det samme efter endt kontakt; dvs. at man ikke kan forvente at kunne benytte de angivne information til at kontakte patienten efterfølgende.

Slutbrugergruppen blev derfor bedt om at vurdere datamodellen, og de data det er muligt at angive.

Beslutning
Det blev besluttet at:

  • Man kun angiver officielt navn. 
    • Dvs. at i data objektet Name, er Use:official det eneste der bruges.
  • Man kun angiver telefonnummer.
    • Dvs. at i data objektet Contact, er System:phone det eneste der bruges.
  • Man ikke differentierer på typerne af adresse - det er altid hjemme adressen der registreres.
    • Dvs. at i data objektet Address, er Use:Home de eneste der bruges og at Type parameteren ikke benyttes.
Slutbrugergruppe Nationalt eCPR 2020

 

Valg af X-eCPR format

Problem
Beslutning om hvilket format der bruges til udstedelse af Nationale eCPR-numre

Beskrivelse
Regionerne har udført lokale analyseprojekter i større eller mindre omfang. Der er ikke blevet lavet en tilbundsgående analyse, da dette ville være for omkostnings- og ressourcetungt. I stedet har regionerne taget udgangspunkt i de for regionen vigtigste systemer og på den baggrund lavet et skøn for, hvor mange ændringer der skal foretages som konsekvens af:

1.  Brug af formatet ”X-eCPR” i de lokale systemer

2. Brug af formatet ”D-eCPR+kildeangivelse” i de lokale systemer

Beslutning
Brugen af X-eCPR formatet fastholdes som det nationale format. Dette er det mindst omkostningstunge, og styregruppen vurderer dermed, at det er det eneste realistiske scenarie at implementere for Regionerne.

Styregruppen for eCPR-projektet

...

Ændringslog

0.82023-10-31Udkast publiceretSDS
1.02023-12-05Side færdiggjortSDS

Scenarier

I det følgende beskrives en række scenarier og hvordan de tilhørende data ser ud. Rækker bliver aldrig slettet eller rettet - der bliver altid kun tilføjet nye rækker. Så fordelen ved denne løsninger er at historikken bevares.

Der er anvendt forsimplede uuid'er for læsbarhedens skyld.

...

'CPR'

...

'ACTIVE'

...

'CPR'

...

'ACTIVE'

...

'CPR'

...

'INACTIVE'

...

Modellen skal læses på følgende måde:

Indenfor et givent CPR nummer er det altid rækken med den seneste 'created_date' der er gældende.

Hvis status er 'ENTERED-IN-ERROR', så er denne og den foregående række ikke gyldige. Dvs. i scenarie nr. 6 har borgeren ikke et aktivt fravalg, mens i scenarie nr. 7 har borgeren et aktivt fravalg.

Beslutninger ift. arkitektur og jura

Følgende tabel er beslutninger, som har indvirkning på arkitekturen bag FGVHR

Problem: Er der behov for optimistisk låsning, således der ikke sker en oprettelse/ændring af data bagom ryggen på den visning man nu ser?
Beskrivelse: Der er kun to klienter som kan skrive data til register for fravalg. Den ene er borgeren selv via sundhed.dk, den anden er en administrativ medarbejder via NADM snitfladen. Administrative medarbejdere indtaster borgerens data fra papirblanketter indsendt fra de borgere som ikke er kyndige med det digitale. Sandsynligheden for at en borger skriver egne data via sundhed.dk på samme tid en administrativ medarbejder skriver borgerens data via NADM er defor minimal.
At indføre optimistisk låsning på nuværende tidspunkt, kræver en ændring til læse- og registreringssnitfladen, da der skal indføres en ekstra kolonne i databasen, eksempelvis "replaces_uuid" som fortæller hvilken række som erstattes. Derved kan registeret se om der er kommet ny data ind i mellemtiden for borgeren inden der skrives.
Problemstillingen er at snitfladerne er udsendt (pr. 1/7-2023) og en ændring af snitfladen på nuværende tidspunkt kan resultere i en samlet forsinkelse af projektet. Risikoen for at der skrives data bag om ryggen på enten borgeren eller den administrative medarbejder er så lille at vi ikke skal indføre ændringen ift. optimistisk låsning for borgerens registrering af fravalg.

Beslutning: Der indføres ikke optimistisk låsning ved skrivning ift nuværende snitflade

Problem: Må borgerens historiske registrering af fravalg samt tilbagetrækninger opbevares i FGVHR?

Beskrivelse: "Fravalgs-registeret" er lige nu designet til at opbevare al historik på borgerens registrerede fravalg, og ikke kun den aktuelle registrering. Data slettes først et år efter borgeren er registreret som afdød i CPR-registeret.
Det betyder at for en borger som har registreret fravalg, og senere trækker registreringen tilbage, vil man kunne se i registeret hvornår disse transaktioner er foretaget.
Det er muligt at se alle historiske registreringer via den administrative brugergrænsefladen (NADM)
Årsagen til at historik bør være tilgængelig i FGVHR er oplysningernes følsomhed, således der aldrig kan dannes tvivl om hvad borgerens registrering har været på et hvilket som helst tidspunkt.
Et scenarie som skal tænkes ind er borgere som registrerer et fravalg, fortryder registreringen, for derefter at registrere sig igen o.s.v. Der vil det være vigtigt at kunne dokumentere at disse handlinger er foretaget.
Beslutning: Juridisk afdeling godkender at historikken opbevares omkring fravalg af genoplivningsforsøg. De mener derfor, at der ikke er et problem med hjemlen til opbevaring af disse data. Der har tidligere været henvendelser på VAR og Organdonor omkring dette, hvor de også kom frem til, at fravalg og tilvalg er vigtig historisk. Særligt ift. klagesager hos STPK - hvis fx en pårørende påstår, at deres familiemedlem ikke var registeret på tidspunktet, fordi de havde overbevist dem, om ikke lade sig registrere og bede om genoplivningsforsøg ved hjertestop, men så har familiemedlemmet ændret valget igen lige op til dødsfaldet.
Om data skal vises for borgeren er ikke givet. Derfor skal historik udelukkende udstilles til den administrative brugergrænseflade for nuværende.

Problem:  Den 26.03.2023 blev FHIR release 5 frigivet, skal FGVHR's snitflade opdateres tilsvarende?

Beskrivelse: Oprindeligt er snitfladen til FGVHR profileret efter version 4: http://hl7.org/fhir/R4/consent.html  i mellemtiden 26/3 er FHIR release 5 blevet frigivet http://hl7.org/fhir/R5/consent.html
Der er nogle mindre forskelle, bl.a. på kardinaliteter og på datatyper og konstantværdier, så spørgsmålet er om SDS vil understøtte Release 4 af modellen, eller den Release 5?Beslutning: Da der er tale om mindre justeringer baseret på en R4-R5 sammenligning, og vi samtidig kan sige, at hvis R5 havde været til rådighed, da vi lavede den første modellering, så havde vi vel valgt R5 uden at blinke ret meget, så peger de to ting tilsammen på, at vi skal basere os på version 5.
Eneste argument for at blive på R4 ville være, hvis vi allerede havde noget andet, der anvendte/refererede til Consent i R4, ifølge NSP er det dem ikke bekendt.
Beslutning: Snitfladen opdateres til FHIR release version 5NSP
SDS's juridiske afdeling
DatoEmneProblem, beskrivelse og beslutningAfklaret med
14.08.2023Optimistisk låsning ved skrivning til registeretNSP14.08.2023Historik på data i FGVHRSDS's Juridiske afdeling25.05.2023Version af FHIR profilNSP
27.03.2023Skrivning til Minlog

Problem: I hvilke situationer skal FGVHR skrive til Minlog?

Beslutning:

  1. Der skrives til borgerens Minlog når registrereringen oprettes/slettes - uanset om det er borgeren selv der ændrer via sundhed.dk, eller om det er en administrativ medarbejder som behandler en papirblanket.
  2. Der skrives til borgerens Minlog når en administrativ medarbejder henter oplysninger om en borgers registrering i FGVHR
  3. Der skrives ikke til Minlog når registreringen læses af borgeren selv.
  4. Der skrives ikke til Minlog når status hentes via Fælles Stamkort grænsefladen

Det vil forventeligt være meget få logninger, og desuden vil enhver tvivl om hvornår noget er ændret, derfor udvides den sædvanlige logning med retistreringer fra borgeren selv.

SDS's Juridiske afdeling
23.01.2023Sundhedsfaglig adgang til borgerens registrering

Problem: Der er efterspurgt adgang til borgerens registrering uden om Fælles Stamkort, eksempelvis via replikering - kan det tillades?

Beslutning: Status om borgerens fravalg for genoplivningsforsøg ved hjertestop udestilles kun til sundhedsfaglige systemer via Fælles Stamkort.