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 |
| 2025-01-16 | SDS-7115: FSK skal udstille rene ITI snitflader (uden DGWS og HSUID) | KIT |
HL7 CDA | Standard til udveksling af oplysninger indenfor sundhedsvæsenet. |
Forkortelse | Betydning |
|---|---|
FSK | Det Fælles Stamkort |
| DDS | Dokumentdelingsservicen |
| SCES | CPR Enkeltopslags service |
| ODR | Organdonorregistret |
| LTR | Livstestamenteregistret |
| BTR | Behandlingstestamenteregistret |
Det Fælles Stamkort servicen (FSK) har har til formål at agere on-demand dokumentkilde for Dokumentdelingsservicen (DDS) samt backend for Synkroniseringsservice til Fællesstamkort (SFSK). Der henvises til dokumentationen for disse services i forhold til detaljer.
En anvender kan foretage en forespørgsel til DDS eller SFSK på, hvilke dokumenter, der findes for en person. Disse services returnerer en liste over dokumenter, og såfremt der er registreret et stamkort for personen, vil dette være iblandt de dokumentreferencer, der returneres.
Herefter kan anvenderen kalde DDS eller SFSK og bede om selve dokumentet. Når der bedes om stamkortet, vil DDS/SFSK kalde FSK for at hente dette. FSK vil herefter kalde et antal underregistre for at hente de data, der skal indgå i det dokumentet:
Ud fra de hentede data sammensætter FSK et HL7 CDA ClinicalDocument, som returneres via den foranliggende service til anvenderen.
Alle data fra stamkortet indgår i svaret, men for livstestamente-, behandlingstestamente- og organdonorregistret gælder, at såfremt anvenderen 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 SFSK og de underliggende registre:
![]()
Der kan alene hentes data fra FSK. Opdateringer til de underliggende registre skal foretages ved direkte kald til pågældende services.
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 har MedCom udviklet en dansk implementeringsguide (PDC-DK V.3.0), for hvordan oplysningerne repræsenteres vha. standard CDA-elementer.
Forretningslogikken i servicen er afkoblet fra udvekslingsformatet, dvs. Fra HL7 CDA.
Se Guide til Anvendere for flere detaljer.
Kald til FSK servicen foretages alene igennem Dokumentdelingsservicen (DDS) samt Synkroniseringsservice til Fællesstamkort (SFSK). Da FSK ikke kaldes direkte af anvenderne, overlader FSK sikkerhedstjek og forretningsregler vedr. adgang til disse services. FSK kan derfor kaldes uden sikkerhedsbillet. Af bagudkompatibilitetshensyn tillader FSK at sikkerhedsbillet medsendes, men vil ignorere denne.
For at kalde bagvedliggende registre trækker FSK et system-idkort for at kunne foretage kaldet.
Ved kald til servicen vil der blive foretaget logning af, at der er foretaget et kald, hvornår kaldet blev foretaget, og hvor lang tid behandlingen af kaldet varede. Dette vil ske i form af SLA-logning. Logs vil ikke indeholde detaljer vedr kalderen identitet, da FSK overlader sikkerhedstjek til de foranliggende registre.
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.
CPR Enkeltopslagsservicen (SCES) anvendes til opslag af følgende oplysninger:
For personer, der er registreret som PersonWardRelation=barn, PersonCustodyRelation=mor og PersonCustodyRelation=far i CPR, laves et separat opslag:
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.
Fra stamkortregistret (SKR) hentes personens stamkort. Dette omfatter 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.
Fra FGHVR hentes ønske om fravalg af genoplivning, for en given borger.
Fra de 3 registre Livstestamenteregister (LTR), Behandlingstestamenteregister (BTR) og Organdonorregister (ODR) hentes alene oplysning om, hvorvidt der findes en registrering.
FSKs slettejob anvender PersonInformation, til at undersøge, om en given borger har været død i mindst et år.
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.
<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.
Servicen indeholder et slettejob, som kan slette stamkort for afdøde personer. Stamkort for en afdød skal slettes et år efter (kan konfigureres til noget andet end et år) efter personen er afgået ved døden. Stamkortets registrering bliver slettet fra databasen.
Sletningen foregår overordnet ved, at der opbygges en arbejdskø der indeholder alle cpr numre for de personer der er død for 1 år siden. PersonInformation Service bruges til at finde disse personer,
Jobbet består af følgende operationer:
Operation | Beskrivelse |
|---|---|
| Default operation | Formål: Benyttes til at fylde operationer på stakken, når stakken er tom. Java klasse: FskDeceasedCleanupSupplier Batching: For hvert af tallene 00-99, oprettes en "prefix baseret operation" Shuffles: nej Andet: - |
| Prefix baseret operation | Formål: Givet et tal mellem 00 og 99, hentes alle borger id'er fra som starter med disse cifre. Java klasse: FskDeceasedPatientIdPrefixCleanupSupplier Batching: Opretter en mængde "borger id baseret operation", hver med et konfigurerbart antal af disse borger id'er Shuffles: ja Andet: - |
| Borger id baseret operation | Formål: Givet en liste af borger id'er, tages de id'er der tilhører afdøde borgere. Dette afgøres ved kald til PersonInformation. Java klasse: FskDeceasedPatientIdBatchCleanupSupplier Batching: Opretter eet "oprydningsjob" med de afdøde borgers id Shuffles: nej Andet: - |
| Oprydningsjob | Formål: Givet en liste af borger id'er slettes i databasen stamkort for denne liste af id'er Java klasse: FskCleanupOperation Batching: na Shuffles: na Andet: - |