Ændringslog

Version

Dato

Ændring

Ansvarlig

2.0.0

2018-08-27

Initialt dokument

Trifork

2.0.82019-08-16Tilføjet note om MinLog SessionIdTrifork
2.0.112019-12-16AjourførtTrifork
2.0.122021-08-20Fjernet reference til SyncjobKIT

2025-01-16SDS-7115: FSK skal udstille rene ITI snitflader (uden DGWS og HSUID)KIT

Terminologi



HL7 CDA

Standard til udveksling af oplysninger indenfor sundhedsvæsenet.

Forkortelser

Forkortelse

Betydning

FSK

Det Fælles Stamkort
DDSDokumentdelingsservicen
SCESCPR Enkeltopslags service
ODROrgandonorregistret
LTRLivstestamenteregistret
BTRBehandlingstestamenteregistret

Arkitektur

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.

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 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.

Sikkerhed

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.

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.

SCES

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.

Stamkortregister

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.

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.

PersonInformation

FSKs slettejob anvender PersonInformation, til at undersøge, om en given borger har været død i mindst et år.

Design

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.


<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.

Slettejob

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: -