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 |
2.0.8 | 2019-08-16 | Tilføjet note om MinLog SessionId | Trifork |
2.0.11 | 2019-12-16 | Ajourført | Trifork |
2.0.12 | 2021-08-20 | Fjernet reference til Syncjob | KIT |
Terminologi
HL7 CDA | Standard til udveksling af oplysninger indenfor sundhedsvæsenet. |
...
HL7 CDA er tiltænkt kliniske dokumenter og ikke specifikt stamkortregisterdata. Derfor har MedCom udviklet en dansk implementeringsguide (PDC-DK V.23.0), for hvordan oplysningerne repræsenteres vha. standard CDA-elementer.
...
Kald til FSK servicen foretages alene igennem Dokumentdelingsservicen.
HTML |
---|
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/id-47687249-d866-45e5-b52e-7a14c53ea291.html" name="test" height="650" width="800">You need a Frames Capable browser to view this content.</iframe> |
* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.
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.
...
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 MinLogMinLog2.
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 Opslag af oplysninger registreres i MinLogMinLog2. Det kan konfigureres, om der skal logges, når der kaldes med SOSI Idkort niveau 3. Alle andre opslag logges.
(Dele af følgende bliver muligvis ændret senere:) Ved manglende adgang til MinLog-servicen logges en fejl i applikationsloggen men servicekaldet fejler ikke.
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).
SCES
CPR Enkeltopslagsservicen (SCES) anvendes til opslag af følgende oplysninger:
...
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.
FGHVR
Fra FGHVR hentes ønske om fravalg af genoplivning, for en given borger.
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.
HTML |
---|
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/id-5d2247bf-39c8-4088-9de8-030f6871cb4b.html" name="test" height="170" width="800">You need a Frames Capable browser to view this content.</iframe> |
* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.
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.