Page History
Navitabs | ||||||
---|---|---|---|---|---|---|
| ||||||
Overblik
Dette dokument beskriver designet af Det Fælles Stamkort 1.5 -servicen.
Det forudsættes at læseren er bekendt med grundfunktionaliteten i servicen, beskrevet i dokumentet Fælles Stamkort-service (FSK 1.5).
Ændringslog
Version | Dato | Ændring | Ansvarlig |
---|---|---|---|
2.0.0 | 2018-08-27 | Initialt dokument | Trifork |
Terminologi
HL7 CDA | Standard til udveksling af oplysninger indenfor sundhedsvæsenet. |
Forkortelser
Forkortelse | Betydning |
---|---|
FSK | Det Fælles Stamkort |
DDS | Dokumentdelingsservicen |
SCES | CPR Enkeltopslags service |
ODR | Organdonorregistret |
LTR | Livstestamenteregistret |
BTR | Behandlingstestamenteregistret |
Arkitektur
Det Fælles Stamkort servicen (FSK) har har til formål at agere on-demand dokumentkilde for Dokumentdelingsservicen (DDS). En sundhedsfaglig kan foretage en forespørgsel til Dokumentdelingsservicen på, hvilke dokumenter der findes for en person. Dokumentdelingsservicen returnerer en liste over dokumenter, og såfremt der er registreret et stamkort for personen, vil dette være iblandt de dokumenter, der returneres. Herefter kan den sundhedsdaglige kalde Dokumentddelingsservicen og bede om et dokument. Når der bedes om stamkortet, vil DDS kalde FSK for at hente dette, da denne type dokumenter er registreret i DDS som et on-demand dokument. FSK vil herefter kalde et antal underregistre for at hente de data, der skal indgå i det dokumentet:
- CPR-oplysninger slås op ved et kald til CPR Enkeltopslagsservice (SCES). Der hentes herunder navn, adresse, pårørende, egen læge og sygesikringsgruppe.
- Stamkort hentes fra Stamkortregistret (SKR). Disse data omfatter kontaktoplysninger, midlertidige adresser, pårørende, talte sprog samt tandlægeoplysninger.
- Data hentes fra Livstestamenteregistret (LTR). Der undersøges alene, hvorvidt der findes data eller ej.
- Data hentes fra Behandlingstestamenteregistret (BTR). Der undersøges alene, hvorvidt der findes data eller ej.
- Data hentes fra Organdonorregistret (ODR). Der undersøges alene, hvorvidt der findes data eller ej.
Ud fra de hentede data sammensætter FSK et HL7 CDA ClinicalDocument, som returneres via DDS til til den sundhedsfaglige. Alle data fra stamkortet indgår i svaret, men for livstestamente-, behandlingstestamente- og organdonorregistret gælder, at såfremt den sundhedsfaglige vil tilgå de faktiske data fra registrene, skal disse hentes ved et direkte kald til den pågældende registerservice.
Figuren herunder illustrerer hvorledes FSK servicen indgår som samleled mellem DDS og de underliggende registre:
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Der kan alene hentes data fra FSK. Opdateringer til de underliggende registre skal foretages ved direkte kald til pågældende services.
Standarder
Alt dataudveksling er basereret på HL7 Clinical Document Architecture (CDA).
Data fra selve registret udstilles i CDA-dokumentets body (structuredBody), mens metadata og informationer fra andre datakilder udstilles i CDA-dokumentets header. Metadata er hovedsageligt information om, hvilken borger de pågældende oplysninger vedrører.
HL7 CDA er tiltænkt kliniske dokumenter og ikke specifikt stamkortregisterdata. Derfor er oplysningerne repræsenteret som CDA-udvidelser, som så vidt muligt er opbygget af dataelementer fra CDA.
Forretningslogikken i servicen er afkoblet fra udvekslingsformatet, dvs. Fra HL7 CDA.
Se Guide til Anvendere for flere detaljer.
Sikkerhed
Kald til FSK servicen foretages alene igennem Dokumentdelingsservicen. Kaldet til FSK 1.5 fra DDS er et SOAP 1.2 kald med DGWS headers (Den Gode Webservice). Der kræves anvendelse af OCES sikkerhedsniveau 4, hvor der skal medsendes et ID-kort, som er signeret med medarbejdercertifikat (MOCES). Dog er der pt. konfigureret en undtagelse for Sundhed.dk, som kan foretage kald med OCES sikkerthedsniveau 3. Servicen vil verificere at kaldet er korrekt signeret, og at signeringen ikke er udløbet.
Der henvises til hhv. Den Gode Webservice og OIO Identity-based Web Services v1.0.1a for yderligere information.
Ved kald til servicen vil der blive foretaget logning af, at der er foretaget et kald, samt hvem der har foretaget kaldet, hvornår kaldet blev foretaget, og hvor lang tid behandlingen af kaldet varede. Dette vil ske i form af auditlogning, SLA-logning samt logning i MinLog.
Integrationer
CPR-subscriber
Cpr-subscriber er en fælles intern applikation hvis formål er at håndtere al kommunikation til stamdata (cpr-registry). FSK-servicen inkluderer et job der skal sørge for at vedligeholde DDS registry med information om aktuelle on-demand dokumenter. Som en del af dette sletter jobbet dokumenter for borger 1 år efter at personen er afgået ved døden.
MinLog
Alle opslag af oplysninger registreres i MinLog.
(Dele af følgende bliver muligvis ændret senere:) Ved manglende adgang til MinLog-servicen logges en fejl i applikationsloggen men servicekaldet fejler ikke.
SCES
CPR Enkeltopslagsservicen (SCES) anvendes til opslag af følgende oplysninger:
- Navn
- Køn
- Adresse
- Egen læge
- Sygesikringsgruppe
- Værge
For personer, der er registreret som værger i CPR, laves et separat opslag:
- Navn
- Adresse
Såfremt opslag af CPR-data for personen fejler, f.eks. hvis data ikke findes, vil on-demand servicekaldet fejle. Hvis opslag af værge fejler vil servicekaldet også fejle, dog ikke hvis det blot er fordi at data ikke findes.
Stamkortregister
Fra stamkortregistret (SKR) hentes personens stamkort. Dette omfatter følgende oplysninger:
- Kontaktoplysninger (telefonnumre)
- Pårørende
- Midlertidige adresser
- Sprog
- Tandlæge
Såfremt data for tandlæge omfatter ydernummer, vil FSK servicen foretage opslag af navn, adresse mv for pågælende tandlæge i yderregistret. Disse yder data vil indgå i det endelige svar fra on-demand servicen.
Livstestamente-, behandlingstestamente- og organdonorregister
Fra de 3 registre Livstestamenteregister (LTR), Behandlingstestamenteregister (BTR) og Organdonorregister (ODR) hentes alene oplysning om, hvorvidt der findes en registrering.
Design
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Datamodel
FSK er ikke i sig selv et databærende register, men håndterer alene data fra de underliggende registre.
Dog er det nødvendigt at for servicen at lagre data i en database omkring, hvilke dokument-ID'er, der er tildelt til hvilke borgeres stamkort.
Det detaljerede schema for databasen er vist på figuren herunder.
RegistryIndex indeholder information om en persons stamkorts dokument-ID i DDS registry. Såfremt jobbet til synkronisering af DDS registry identificerer at en borgers status skifter til død ud fra stamdata, markeres dette i feltet DeleteAfter.
Tabellen Properties er anvendt til at lagre information omkring hvor langt jobbet til synkronisering af DDS registry er nået i forhold til ændringer i CPR-stamdata.