Formål

Dette dokument beskriver designet af Behandlingstestamenteregistret (BTR).

En beskrivelse af funktionaliteten i servicen kan findes i dokumentet "Behandlingstestamenteregistret-service".

Ændringslog

Terminologi

Arkitektur

Systemet består af en enkelt service der håndterer begge registre. Som illustreret på figuren herunder tilgår brugerne servicen indirekte via Sundhed.dk , patientjournalsystemer, lægepraksissystemer osv. som integrerer til systemet.  Herudover foretager Dokumentdelingsservicen (DDS) opslag via FSK. Opslaget via FSK returnerer alene information om, hvorvidt der findes data for en person eller ej.

Servicen understøtter adgang gennem DGWS eller IDWS. Håndteringen af DGWS/IDWS-billetter håndteres ved hjælp af security-api'et.

Standarder

Dataudveksling er basereret på HL7 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 oplysningerne vedrører.

Da HL7 CDA er tiltænkt kliniske dokumenter og ikke borgeres stamkortregister-data, er oplysningerne repræsenteret som CDA-udvidelser, så vidt muligt opbygget af dataelementer fra CDA. 

Oprettelse, ændring og sletning af data sker via forespørgsler, der indeholder typer som er specialfremstillet til formålet, da HL7 CDA ikke direkte er tiltænkt dette.

Forretningslogikken i servicen er afkoblet fra udvekslingsformatet, dvs. 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.

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

Såfremt servicen kan verificere at der er tale om et korrekt DGWS- eller IDWS-kald, vil kaldet blive udført. Servicen vil tillade kaldet hvis:

• Der er tale om et DGWS-kald foretaget af en autoriseret sundhedsprofessionel.
• Der er tale om et IDWS-kald, foretaget af samme person, som der slås data op for.

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). SKR-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 SKR-servicen at lave opslag i stamdata til brug i dette slettejob.

NAS

Alle ændringer (oprettelser, opdateringer og sletning) af Stamkort afstedkommer adviseringer til NAS.

Ved manglende adgang til NAS-servicen vil servicekaldet fejle.

Beskedformat og topics

Se BTR - Guide til anvendere

MinLog

Alle opslag og ændringer af oplysninger i registret registreres i MinLog.

Ved manglende adgang til MinLog-servicen vil servicekaldet fejle.

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

CprExists

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

• OFF: Der foretages ikke yderligere verifikation af CPRnummeret udover simpel validering af længde. CPRExists kaldes ikke
• WARNING: CPRExists service kaldes. Hvis denne service svarer, at CPR nummeret ikke findes eller er inaktivt, så audit logges denne information.
• REJECT: CPRExists service kaldes. Svaret fra denne er en hård validering dvs kaldet til BTR fejler, hvis CPRExist service ikke kender CPR nummeret eller det er inaktivt.

CprExists Service benyttes ligeledes til validering af alder. Denne validering foretages altid.

Design

Datamodel

Da det kun er borgeren selv der har adgang til at oprette og ændre i vedkommendes livs- og behandlingstestamente, kan datamodellen for disse services 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, både i det enkelte register, men også imellem de to registre.  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 database tabellen for livstestamentet er vist på figuren herunder.

Tabellen LivingWill anvendes til at lagre information om en borgers livstestamente. ValidFrom - ValidTo definerer gyldighedsperioden.

Det detaljerede databas tabellen for behandlingstestamentet er vist på figuren herunder. 

Tabellen TreatmentWill anvendes til at lagre information om en borgers behandlingstestamente. ValidFrom - ValidTo definerer gyldighedsperioden.

De to Properies-tabeller indeholder tekniske key/value properties, som anvendes internt af servicen. Tabellerne er navngivet, fordi de eksisterer side om side i det samme skema i et udviklingsmiljø.