Formål

Dette dokument beskriver designet af Organdonorregister-servicen..

Det forudsættes at læseren er bekendt med grundfunktionaliteten i servicen, beskrevet i dokumentet Organdonorregister-service (ODR).

Ændringslog

Version

Dato

Ændring

Ansvarlig

1.0.22018-08-31Ny releaseTrifork
1.0.82019-04-12Tilføjelse af flere PermissionType værdierTrifork
1.0.112019-08-16Tilføjet note om MinLog SessionIdTrifork
1.0.122021-01-18Opdateret 'Design'-figurKvalitetsIT

Terminologi



HL7 CDA

Standard til udveksling af oplysninger indenfor sundhedsvæsenet.

Forkortelser

Forkortelse

Betydning

ODR

Organdonorregistret

Arkitektur

Systemet består af registerservicen, der håndterer kald til systemet, funktionalitet og databaseadgang. Der understøttes adgang gennem DGWS eller IDWS.

Som illustreret på figuren herunder tilgår brugerne servicen indirekte via Sundhed.dk, patientjournalsystemer, lægepraksissystemer osv. Herudover foretager Dokumentdelingsservicen (DDS) opslag via FSK. Opslaget via FSK returnerer alene information om, hvorvidt der findes data for en person eller ej.

Standarder

Alt data udveksling 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.

Ved forespørgsler til oprettelse (Create) og opdatering (Update) medsendes en komplet datastruktur og ikke kun de opdaterede elementer i tilfælde af en opdatering. Ved de øvrige forespørgsler (Get, Has, Delete) medsendes kun borgerens cpr nummer, som anvendes til at slå op med.

Forretningslogikken i servicen er afkoblet fra udvekslingsformatet, dvs. Fra HL7 CDA.

Se Guide til Anvendere for flere detaljer.

Sikkerhed

Kald til servicen kan foretages som enten DGWS- (Den Gode Webservice) eller IDWS- (Identity Based Web Services) kald.

Sundhedsprofessionelle, der vil tilgå servicen fra deres EPJ- eller EOJ-system, kan foretage DGWS-kald igennem den centrale NSP afkoblingskomponent (DCC), som viderestiller kaldet til servicen. Der kræves anvendelse af OCES sikkerhedsniveau 4, hvor der skal medsendes et ID-kort, som er signeret med medarbejdercertifikat (MOCES). Servicen vil verificere at kaldet er korrekt signeret, og at signeringen ikke er udløbet.

Borgerer, der ønsker at tilgå servicen, skal gøre det igennem Sundhed.dk, som står for borgervendt funktionalitet. Sundhed.dk kan foretage IDWS-kald til servicen, som vil verificere at der er tale om et korrekt IDWS-kald.

Servicen vil tillade kaldet hvis:

Der henvises til hhv. Den Gode Webservice og OIO Identity-based Web Services v1.0.1a for yderligere information.

Integrationer

CPR-subscriber

Cpr-subscriber er en fælles intern applikation hvis formål er at håndtere al kommunikation til stamdata (cpr-registry). ODR-servicen inkluderer et slettejob der skal sørge for at slette en borgers registrering 1 år efter personen er afgået ved døden.

Oplysningen om døde personer stammer fra stamdata. Cpr-subscriber gør det muligt for ODR-servicen at lave opslag i stamdata til brug i dette slettejob.

MinLog

Alle opslag og ændringer af oplysninger i registret registreres i MinLog2 med undtagelse af borgerens egen tilgang og ændring af data.

Ved manglende adgang til MinLog-servicen vil servicekaldet fejle.

ODR anvender MinLog Producer biblioteket til at registrere i Minlog2.

CprExists

Gennem kald til CprExists Service foretages validering af CPR nummer. CPR valideringen kan køre i følgende tre modes:

Design

Datamodel

Da det kun er borgeren selv der har adgang til at oprette og ændre i vedkommendes organdonorregistrering, kan datamodellen for servicen realiseres relativt simpelt, idet at det ikke er nødvendigt at lagre information omkring hvem der har oprettet / opdateret data.

Alle registreringer indeholder oplysninger om en gyldighedsperiode, som angiver hvorvidt registreringen stadig betragtes som gyldig eller ej.

Der kan kun eksistere én gyldig registrering for hver enkelt borger, og ønsker borgeren at tilføje en ny registrering skal vedkommende slette den gyldige først.

Når borgeren opdaterer sin registrering med en eller flere ændringer, afsluttes gyldigheden for den nuværende registrering og der oprettet en ny række. Dermed bliver data ikke slettet, men får blot afsluttet en gyldighed.

Ved sletning afsluttet gyldighedsperioden blot.  

Det detaljerede schema for databasen er vist på figuren herunder.

Tabellen OrganDonor bliver anvendt til at lagre information om en borgers organdonorregistrering. ValidFrom - ValidTo definerer gyldighedsperioden.

PermissionType kan antage 4 værdier, som repræsenterer følgende:

RelativeAcceptanceRequired anvendes ved FULLRES, FULL, LIMITEDRES, LIMITED. Har borgeren angivet denne, forudsætter valget som organdonor pårørendes accept.

Tabellen Properties er anvendt til at lagre information omkring hvornår et slettejob sidst er blevet eksekveret.  

v2_person_simplified er et view der anvendes til at slå op i cpr-stamdata (cpr-registry)