Page History
| Navitabs | ||||||
|---|---|---|---|---|---|---|
|
Æ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. |
...
Det Fælles Stamkort servicen (FSK) har har til formål at agere backend for Synkroniseringsservice til Fællesstamkort (SFSK). Der henvises til dokumentationen for SFSK i forhold til detaljer.
En anvender on-demand dokumentkilde for Dokumentdelingsservicen (DDS). En sundhedsfaglig kan foretage en forespørgsel til Dokumentdelingsservicen SFSK på, hvilke dokumenter, der findes for en person. Dokumentdelingsservicen Disse services returnerer en liste over dokumenter, og såfremt der er registreret et stamkort for personen, vil dette være iblandt de dokumenterdokumentreferencer, der returneres.
Herefter kan den sundhedsdaglige anvenderen kalde Dokumentddelingsservicen SFSK og bede om et dokumentselve dokumentet. Når der bedes om stamkortet, vil DDS SFSK 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, børn, forældre, 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.
- Data hentes fra Fravalg af Genoplivningsforsøg ved Hjertestop Register (FGVHR). Det undersøges, om borgeren har fravalgt genoplivningsforsøg i tilfælde af hjertestop
- Data hentes fra Yderservice (SYES).
Ud fra de hentede data sammensætter FSK et HL7 CDA ClinicalDocument, som returneres via den foranliggende service til anvenderen.
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 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 SFSK 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 baseret på HL7 Clinical Document Architecture (CDA).
...
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.
Forretningslogikken i servicen er afkoblet fra udvekslingsformatet, dvs. Fra fra HL7 CDA.
Se Guide til Anvendere for flere detaljer.
Sikkerhed
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.
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.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 MinLog2. 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.
MinLog
Opslag af oplysninger registreres i MinLog2. 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.
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 pågældende 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 tre 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
| 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> |
...
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: - |