Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Dette dokument beskriver designet af Behandlingstestamenteregistret (BTR).

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

Ændringslog

...

Opdateret TreatmentWill database-schema figur med nyeste ændringer

...

Terminologi



HL7 CDAStandard til udveksling af oplysninger indenfor sundhedsvæsenet.

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.

Gliffy Diagram
displayNameLTR-BTR arktitektur v1
nameLTR-BTR arktitektur v1
pagePin2

Standarder

Dataudveksling er basereret på HL7 CDA.

...

Se Guide til Anvendere for flere detaljer.


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.

Gliffy Diagram
displayNameLTR-BTR arktitektur v1
nameLTR-BTR arktitektur v1
pagePin2


Sikkerhed

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

...

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

Integrationer


HTML
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/id-507fac52-f8c5-4e21-bca1-7be0ca6abf06.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.

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.

I miljøer med flere app-servere er det vigtigt at servicens interne job ikke kører i flere inkarnationer, da der så kan opstå "race conditions". Derfor bør det sikres at jobbets "enabled"-property fra application.properties kun er true på præcis én app-server, og false på de øvrige.
Det drejer sig om denne property: jobs.delete.enabled

NAS

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

Ved manglende adgang til NAS-servicen vil servicekaldet fejle.

Beskedformat

...

Der anvendes følgende topic (som kan konfigureres): http://sundhedsdatastyrelsen.dk/livstestamente/2022/08/01/:TreatmentWill.

Indholdet i notifikationen bestpår af et TreatmentWillUpdated-objekt, med følgende attributter:

  • id: Patientens CPR nummer
  • date: Dato for Hvornår ændringen er sket
  • type: Type for beskeddefinitionen
  • version: Versionsnummer for beskeddefinitionen.
  • messagenumber: Sekventielt løbenummer, således anvendere af adviseringer, kan se om de har modtaget alle adviseringer.
Code Block
firstline1
titleTreatmentWillUpdatedNotification
linenumberstrue
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<NotifyContent id="0501792275" idType="http://nsi.dk/advis/v10/CPR" xmlns="http://nsi.dk/advis/v10">
	<ns7:TreatmentWillUpdatedNotification Date="2022-08-17" Id="0501792275"
										  MessageId="urn:uuid:7fda5427-2376-472f-888d-b5e525bd72ba"
										  Type="http://sundhedsdatastyrelsen.dk/MessageDefinition/PDC-notification"
										  Version="1"
										  xmlns:ns7="http://sundhedsdatastyrelsen.dk/livstestamente/2022/08/01/"
	/>
</NotifyContent>

Der anvendes følgende topic (som kan konfigureres): http://sundhedsdatastyrelsen.dk/livstestamente/2022/08/01/:LivingWill.

Indholdet i notifikationen bestpår af et LivingWillUpdated-objekt, med følgende attributter:

  • id: Patientens CPR nummer
  • date: Dato for Hvornår ændringen er sket
  • type: Type for beskeddefinitionen
  • version: Versionsnummer for beskeddefinitionen.
  • messagenumber: Sekventielt løbenummer, således anvendere af adviseringer, kan se om de har modtaget alle adviseringer.
Code Block
firstline1
titleLivingWillUpdatedNotification
linenumberstrue
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<NotifyContent id="0501792275" idType="http://nsi.dk/advis/v10/CPR" xmlns="http://nsi.dk/advis/v10">
	<ns7:LivingWillUpdatedNotification Date="2022-08-18" Id="0501792275"
									   MessageId="urn:uuid:a0bdafe5-85a5-4381-a844-74af278ae612"
									   Type="http://sundhedsdatastyrelsen.dk/MessageDefinition/PDC-notification"
									   Version="1"
									   xmlns:ns7="http://sundhedsdatastyrelsen.dk/livstestamente/2022/08/01/"
	/>
</NotifyContent>

og topics

Se BTR - Guide til anvendere

MinLog

Alle opslag og ændringer af oplysninger i registret registreres i MinLog. Med undtagelse af system bruger og borgerens egen læsning af data.

Ved manglende adgang til MinLog-servicen vil servicekaldet fejle.

...

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 alderenalder. Denne validering kan køre i følgende tre modes:

  • OFF: Der foretages ikke yderligere verifikation af alderen. CPRExists kaldes ikke
  • WARNING: CPRExists kaldes, men der foretages ingen validering eller audit logning.
  • REJECT: CPRExists service kaldes. Hvis denne service svarer, at alderen er mindre end servicen er konfigureret med, så afvises kaldet.

Design

foretages altid.


Gliffy Diagram
displayNameLTR-BTR design v3
nameLTR-BTR design v3
pagePin7

...

Ved sletning afsluttet gyldighedsperioden blot.  


HTML
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/f72c13b1-dd78-4a85-a317-4ae73cee3635.html" name="test" height="450" 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.


Den detaljerede databasetabel Det detaljerede databaseschema for livstestamentet er vist på figuren herunder.

...

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

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

...

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ø.fordi de eksisterer side om side i det samme skema i et udviklingsmiljø.

Slettejob

BTR servicen indeholder to slettejobs der kan slette registreringer for afdøde personer. Registreringerne for en afdød skal slettes 1 år efter personen er afgået ved døden. Registreringerne bliver slettet fra databasen og data kan således ikke genskabes igen.

De to slettejobs virker grundlæggende på samme måde, men der slettes data i to forskellige tabeller.

Sletningen i enten livstestamenteregister/behandlingstestamenteregister foregår ved at der opbygges en arbejdskø der indeholder alle cpr numre for de personer der findes i det pågældende register:

  • Hvis arbejdskøen er tom, så hentes cpr numre fra alle personer der findes i hhv. livstestamenteregister/behandlingstestamenteregister. Dette findes ved at lave opslag i en af tabellerne LivingWill eller TreatmentWill.
  • Hvis arbejdskøen indeholder cpr numre, så tjekkes hver cpr nummer om personen har været død i mere end et år. Hvis dette er tilfældet, så slettes personen fra enten livstestamenteregister eller behandlingstestamenteregister.

Ændringslog

VersionDatoÆndringAnsvarlig
1.0.12018-08-30Initialt dokumentTrifork
1.0.22018-08-31Ny releaseTrifork
1.0.62018-10-15

Opdateret TreatmentWill database-schema figur med nyeste ændringer

Trifork
1.0.122019-08-16Tilføjet note om MinLog SessionIdTrifork
1.0.132021-01-18Opdateret 'Design'-figurKvalitetsIT
1.1.72021-09-06Opdateret efter udfasning af dgws/idws-proxy.KvalitetsIT
1.1.82021-10-12Opdateret ifm. udfasning af btr-snitflade med accept fra pårørende, værge eller fremtidsfuldmægtig for uafvendeligt døendeKvalitetsIT
1.1.92021-10-25Opdateret ifm inaktive cpr numre afvisesKvalitetsIT
1.1.102022-10-25Validering af alder med CprExists tiløjetKvalitetsIT