Formål

Dette dokument beskriver designet af Livs- og behandlingstestamenteregistret (forkortes LTR-BTR).

En beskrivelse af funktionaliteten i servicen kan findes i dokumentet "Livs- og 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 forudsat at adgangen sker via DGWS/IDWS Proxy, som er en separat service der afkobler selve servicen fra alt DGWS- og IDWS-specifikt.

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. Som beskrevet i afsnittet Arkitektur ovenfor, foretages kald til servicen igennem en DGWS/IDWS proxy, der har det primære formål at validere, at der er foretaget et korrekt DGWS- eller IDWS-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 igennem DGWS/IDWS Proxyen. Der kræves anvendelse af OCES sikkerhedsniveau 4, hvor der skal medsendes et ID-kort, som er signeret med medarbejdercertifikat (MOCES). Proxyen 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 igennem DGWS/IDWS Proxyen. Proxyen vil verificere at der er tale om et korrekt IDWS-kald.

Såfremt Proxyen kan verificere at der er tale om et korrekt DGWS- eller IDWS-kald, vil kaldet blive viderestillet til servicen. 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

MinLog

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

Ved manglende adgang til MinLog-servicen vil servicekaldet fejle.

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 databaseschema for livstestamentet er vist på figuren herunder.

Image Added

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

Det detaljerede databaseschema for behandlingstestamentet er vist på figuren herunder. 

Image Added

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, så det er muligt for dem at sameksistere i samme schema i et udviklingsmiljø.

Specifikke designbeslutninger

Vedr. DGWS/IDWS Proxy'en, er der foretaget følgende beslutninger:

• IDWS implementationen stammer fra FMK, og bygger på udgaver af oiosaml_java og oiosaml-trust, som er videreudviklet i forhold til de oprindelige, officielle udgaver af disse libraries. De 2 jar-filer er ikke tilgængelige som artifacts i nspop's Nexus repository, men levereres med som libs i nspop's Subversion sammen med den øvige DGWS/IDWS Proxy og projektets kildekode. Kildekoden til disse libraries findes i NSPs subversion repository.
• Proxy'en anvender Seal, som ved initialisering normalt registrerer til STR-Transform algoritme i forbindelse med xmlsec-biblioteket. oiosaml registrerer ligeledes denne algoritme, hvilket giver en konflikt. Dette er løst ved at sætte en System-property "sosi:do.not.register.STRTransform", som får Seal til at undlade at registrere algoritmen. Dette har ikke negative effekter i Seal, da Proxy'en kun anvender Seal til parsning af DGWS messages. Det betyder dog, at andre services, som afvikles på samme Wildfly instans, potentiet kan bliver berørt af dette, hvilket normalt ikke er acceptabelt i henhold til NSP's regler for services.