Formål

Dette dokument beskriver designet af Organdonorregister-servicen..

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

Ændringslog

Terminologi

Forkortelser

Arkitektur

Organdonorregister-servicen består af en webservice, som andre systemer kan benytte til at oprette, opdatere, slette og aflæse seneste registrering fra.

<iframe src="https://archi.nspop.dk/NSP/570928ca/views/id-198d99a1-fbb0-4f0a-8e05-e2e0e880c919.html" name="test" height="580" 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å kassenSystemet består af to services. Selve registerservicen håndterer funktionalitet og databaseadgang og en separat DGWS/IDWS Proxyservice håndterer kald til systemet. Der understøttes adgang gennem DGWS eller IDWS forudsat at adgangen sker via en DGWS/IDWS Proxy, som er en separat service der afkobler alt DGWS- og IDWS-specifikt.

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. Der understøttes adgang gennem DGWS eller IDWS.

Gliffy Diagram
displayName ODR-Arkitektur v7 name ODR-Arkitektur v7 pagePin

...

2

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. 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 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 kan foretage IDWS-kald til servicen igennen DGWS / IDWS Proxyen som vist på figuren længere oppe: ODR-Arkitektur.png. Proxyen vil servicen, som 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

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.

...

MinLog

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

Ved manglende adgang til MinLog-servicen vil servicekaldet fejle.

ODR anvender MinLog Producer biblioteket til at registrere i Minlog2.

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/OrganDonation/2022/05/05:OrganDonationUpdated.

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

• type: Type for beskeddefinitionen
• date: Dato for Hvornår ændringen er sket
• version: Versionsnummer for beskeddefinitionen.

<ns3:Notify xmlns:ns3="http://docs.oasis-open.org/wsn/b-2" xmlns:ns2="http://www.w3.org/2005/08/addressing" xmlns:ns6="http://nsi.dk/advis/v10" xmlns:ns8="http://sundhedsdatastyrelsen.dk/organdonor/2022/08/01/" xmlns="">
     <ns3:NotificationMessage>
          <ns3:Topic Dialect="http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple">http://sundhedsdatastyrelsen.dk/OrganDonation/2022/05/05:OrganDonationUpdated</ns3:Topic>
          <ns3:Message>
               <ns6:NotifyContent id="0501792275" idType="http://nsi.dk/advis/v10/CPR">
                    <ns8:OrgandonorUpdated>
                         <type value="http://sundhedsdatastyrelsen.dk/MessageDefinition/PDC-notification"/>
                         <date value="2022-08-01"/> 
                         <version value="1"/>
                    </ns8:OrgandonorUpdated>
               </ns6:NotifyContent>
          </ns3:Message>
     </ns3:NotificationMessage>
</ns3:Notify>

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 ODR 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

Gliffy Diagram
displayName ODR-Design v3 name ODR-Design v3 pagePin

...

7

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.

<iframe src="https://archi.nspop.dk/NSP/570928ca/views/a8998bfe-c235-4089-9971-9fee199ff7f5.html" name="test" height="240" 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.

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.

Image Modified

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:

• Fuld tilladelse

  • Borgerens fuld tilladelse til, at vedkommendes organer kan anvendes til transplantation efter død.

• Begrænset tilladelse

  • Tabellens boolske værdier til at udtrykke, hvad der gives begrænset tilladelse til.

• Ved ikke

  • Borger har endnu ikke taget stilling og dermed overlades beslutning som organdonor til de nærmeste pårørende.

• Forbud

  • Borgeren modsætter at vedkommendes organer anvendes til transplantation efter død.

• inklusiv forskning (FULLRES)

  • Ja, patienten vil donere alle sine organer efter sin død: til transplantation og forskning i forbindelse med donationen, som har til hensigt at forbedre transplantationsresultater

• Fuld tilladelse (FULL)
  
  • Ja, patienten vil donere alle sine organer efter sin død: udelukkende til transplantation

• Begrænset tilladelse inklusiv forskning (LIMITEDRES)

  • Ja, patienten vil donere de organer, der er sat kryds ud for, efter sin død: til transplantation og forskning i forbindelse med donationen, som har til hensigt at forbedre transplantationsresultater

• Begrænset tilladelse (LIMITED)
  
  • Ja, patienten vil donere de organer, der er sat kryds ud for, efter sin død: udelukkende til transplantation

• Ved ikke (DONT_KNOW)

  • Patienten overlader det i stedet til sine nærmeste pårørende at tage stilling til, om patientens organer må anvendes til transplantation og forskning efter sin død

• Forbud (NONE)

  • Patienten modsætter sig, at patientens organer anvendes til transplantation efter sin død

RelativeAcceptanceRequired anvendes ved FULLRES, FULL, LIMITEDRES, LIMITEDRelativeAcceptanceRequired anvendes ved fuld -og begrænset tilladelse. 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)

Specifikke designbeslutninger

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

Slettejob

ODR servicen indeholder også et slettejob der kan slette registreringer for afdøde personer. Registreringen 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.

Sletningen foregår ved at der opbygges en arbejdskø der indeholder cpr numre på de personer der skal slettes:

• Hvis arbejdskøen er tom, så hentes nye cpr numre fra alle personer der findes i Organdonorregister. Dette findes ved at lave opslag i tabellen OrganDonor.
• 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 OrgandonorregisterIDWS 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/IIDWS Proxy og FSK kildekode. Kildekoden til disse libraries findes i nspop's SVN 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.