Dette dokument beskriver designet af Stamkortregister-servicen..
Det forudsættes at læseren er bekendt med grundfunktionaliteten i servicen, beskrevet i dokumentet Stamkortregister-service (SKR).
Version | Dato | Ændring | Ansvarlig |
|---|---|---|---|
1.0.0 | 2018-08-31 | Initialt dokument | Trifork |
| 1.0.11 | 2019-08-16 | Fjernet note om SCES. Tilføjet note om MinLog SessionId. | Trifork |
HL7 CDA | Standard til udveksling af oplysninger indenfor sundhedsvæsenet. |
Forkortelse | Betydning |
|---|---|
SKR | Stamkortregistret |
| FSK | Det Fælles Stamkort |
| DDS | Dokumentdelingsservicen |
| DCC | Viderestillingsservicen |
Systemet består af to services. Stamkortregister-servicen håndterer funktionalitet og databaseadgang, og en separat DGWS/IDWS Proxyservice håndterer DGWS- og IDWS-specifik sikkerhed i forbindelse med udefrakommende kald til systemet.
Som illustreret på figuren herunder tilgår brugerne servicen indirekte via Sundhed.dk, patientjournalsystemer, lægepraksissystemer osv. Herudover kan stamkort hentes via Dokumentdelingsservicen (DDS), som anvender FSK som On-Demand datakilde. FSK henter data fra en række datakilder, herunder Stamkortregistret.
Dataudveksling er basereret på HL7 CDA.
Data fra selve stamkortet udstilles i CDA-dokumentets body (structuredBody) mens metadata udstilles i CDA-dokumentets header. Metadata er hovedsageligt information om hvilken borger stamkortet vedrører og hvem der har opdateret stamkortet.
Da HL7 CDA er tiltænkt kliniske dokumenter og ikke stamkortoplysninger om borgere, er stamkortet repræsenteret som CDA-udvidelser, så vidt muligt opbygget af dataelementer fra CDA.
Oprettelse, ændring og sletning af stamkort-data sker via separate opdateringsoperationer til hver del af stamkortet, eksempelvis midlertidig adresse eller sprog. Disse opdateringsoperationer modtager ikke et komplet stamkort-dokument men kun de relevante data som ændres. Her benyttes de samme CDA-strukturer, som ved læsning af stamkortet.
Forretningslogikken i Stamkortregister-servicen er afkoblet fra udvekslingsformatet, dvs. HL7 CDA.
Se Guide til Anvendere for flere detaljer.
Kald til Stamkortregister-servicen kan foretages som enten DGWS- (Den Gode Webservice) eller IDWS- (Identity Based Web Services) kald. Som beskrevet i afsnittet Arkitektur ovenfor, foretages kald til SKR igennem en DGWS/IDWS proxy, der har det primære formål at validere, at der er foretaget et korrekt DGWS- eller IDWS-kald.
Sundhedsprofessionelle, der vil tilgå Stamkortregister-servicen fra deres EPJ- eller EOJ-system, kan foretage DGWS-kald igennem den centrale NSP afkoblingskomponent (DCC), som viderestiller kaldet til Stamkortregistret igennem DGWS/IDWS Proxyen. Der kræves som udgangspunkt anvendelse af OCES sikkerhedsniveau 4, hvor der skal medsendes et ID-kort, som er signeret med medarbejdercertifikat (MOCES). Proxyen vil verificere at kaldet er korrekt signeret, og at signeringen ikke er udløbet.
Borgere, der vil tilgå Stamkortregister-servicen, skal gøre dette igennem Sundhed.dk, som står for borgervendt funktionalitet. Sundhed.dk kan foretage et IDWS-kald til Stamkortregistret igennem DGWS/IDWS Proxyen. Proxyen vil verificere at der er tale om et korrekt IDWS-kald.
Såfremt Proxyen kan verificere at der er tale om et korrekt DGWS- eller IDWS-kald, vil kaldet blive viderestillet til Stamkortregister-servicen. Servicen vil tillade kaldet hvis:
De tilfælde, der er angivet i parentes ovenfor, kræver at der er etableret integration til hhv. samtykke- og fuldmagt-services. Denne funktionalitet er pt. ikke understøttet.
Der henvises til hhv. Den Gode Webservice og OIO Identity-based Web Services v1.0.1a for yderligere information.
Cpr-subscriber er en fælles intern applikation hvis formål er at håndtere al kommunikation til stamdata (cpr-registry). SKR-servicen inkluderer et slettejob der skal sørge for at slette en borgers registrering 1 år efter personen er afgået ved døden.
Oplysningen om døde personer stammer fra stamdata. Cpr-subscriber gør det muligt for SKR-servicen at lave opslag i stamdata til brug i dette slettejob.
Alle opslag og ændringer af Stamkort registreres i MinLog.
Ved manglende adgang til MinLog-servicen vil servicekaldet fejle.
Som MinLog SessionId anvendes MessageID defineret i anvender-requests. Hvis SessionId er længere end 46 tegn (det maksimalt tilladte i MinLog-servicen) anvendes i stedet SHA-1 værdien (altid 40 tegn).
Service og database er opbygget således at det vil være nemt at udvide stamkortet med yderligere informationer senere.
Den logiske datamodel er illustreret på figuren herunder.
Det centrale dataelement er en stamkortopdatering (tabel: PersonalDataCard), som der kan eksistere et antal af for hver borger/CPR-nummer.
Til hver stamkortopdatering hører en eller flere ændringer af de oplysninger, som indgår i stamkortet, eksempelvis borgerens pårørende. Hver af disse oplysninger har en gyldighedsperiode, der angiver hvorvidt informationen er gældende eller ej. Data slettes således ikke, men får blot afsluttet sin gyldighed.
En række af disse stamkortopdateringer kan være gyldige på samme tidspunkt, eksempelvis hvis der er registreret flere pårørende ad flere omgange.
Hver stamkortopdatering har tilknyttet en aktør (tabel: ServiceActor) som er den person, der lavede den pågældende ændring af stamkortet. Denne aktør kan være borgeren selv, en sundhedsprofessionel eller en person der har fuldmagt til at opdatere stamkortet.
Det detaljerede schema for databasen er vist på figuren herunder.
Vedr. DGWS/IDWS Proxy'en, er der foretaget følgende beslutninger: