Page History
| Navitabs | ||||
|---|---|---|---|---|
|
Overblik over servicen
Nedstående diagram viser opbygningen af FGVHR-servicenIndholdsfortegnelse:
| Gliffy Diagramtoc | ||||||||
|---|---|---|---|---|---|---|---|---|
|
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 (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. | |||||||
National Adviseringsservice på NSP'en funger som en afkoblet system-til-system advisering gennem et "publish-subscribe"-mønster | |||||||
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
| |||||||
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) | |||||||
CPR-enkeltopslag er en realisering af MedCom-standarden 'Det Gode CPR Opslag' | |||||||
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:
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 | ||||||
|---|---|---|---|---|---|---|
|
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 | ||||||||
|---|---|---|---|---|---|---|---|---|
|
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.
Forretningsrelateret data
Data, der anvendes forretningsmæssigt, f.eks. sygehusafdelingsnummer, ydernummer og autorisationsnummer, 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 | ||||
|---|---|---|---|---|
|
Formater
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
Typebestemmelse med OID'er
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
Beslutninger ift. arkitektur og jura
I følgende tabel er listet beslutninger, som har indvirkning på arkitekturen bag Nationalt eCPR.
| Dato | Emne | Problem, beskrivelse og beslutning | Afklaret med |
|---|---|---|---|
| Opbevaring af data | Problem Beskrivelse Beslutning | SDS's juridiske afdeling |
| Genbrug af eCPR-numre | Problem Beskrivelse 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 | SDS's juridiske afdeling |
| Autorisation | Problem Beskrivelse Beslutning | SDS's juridiske afdeling |
| Brug af eCPR udenfor sundhedsvæsenet | Problem Beskrivelse Beslutning | SDS's juridiske afdeling |
| Log i MinLog Borgerlog | Problem Beskrivelse Tilgang til og ændringer i CPR-registreret logges heller ikke i MinLog Borgerlog. Beslutning | SDS's juridiske afdeling |
| Log i MinLog Medhjælpslog | Problem Beskrivelse Beslutning | SDS's juridiske afdeling |
| Anvendelse af SKRS | Problem Beskrivelse SKRS bruges bl.a. til at have en lokale kope af CPR registret i dag. Beslutning | SDS's juridiske afdeling |
| Begrænsning i brug af datamodellen | Problem Beskrivelse 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
| Slutbrugergruppe Nationalt eCPR 2020 |
| Valg af X-eCPR format | Problem Beskrivelse 1. Brug af formatet ”X-eCPR” i de lokale systemer 2. Brug af formatet ”D-eCPR+kildeangivelse” i de lokale systemer Beslutning | Styregruppen for eCPR-projektet |
...
Ændringslog
| 0.8 | 2023-10-31 | Udkast publiceret | SDS |
| 1.0 | 2023-12-05 | Side færdiggjort | SDS |
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
| Dato | Emne | Problem, beskrivelse og beslutning | Afklaret med | 14.08.2023 | Optimistisk låsning ved skrivning til registeret | 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?NSP | 14.08.2023 | Historik på data i FGVHR | SDS's Juridiske afdeling | 25.05.2023 | Version af FHIR profil | NSP |
|---|---|---|---|
| 27.03.2023 | Skrivning til Minlog | Problem: I hvilke situationer skal FGVHR skrive til Minlog? Beslutning:
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.2023 | Sundhedsfaglig 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. | NSP
