Page History
...
Det forudsættes at læseren er bekendt med grundfunktionaliteten i servicen, beskrevet i dokumentet dokumentet Organdonorregister-service (ODR).
Ændringslog
Version | Dato | Ændring | Ansvarlig |
|---|---|---|---|
| 1.0.2 | 2018-08-31 | Ny release | Trifork |
| 1.0.8 | 2019-04-12 | Tilføjelse af flere PermissionType værdier | Trifork |
| 1.0.11 | 2019-08-16 | Tilføjet note om MinLog SessionId | Trifork |
| 1.0.12 | 2021-01-18 | Opdateret 'Design'-figur | KvalitetsIT |
| 1.0.13 | 2021-12-07 | Opdateret ifm inaktive cpr numre afvises | KvalitetsIT |
| 1.0.14 | 2022-10-24 | SDS-5679: validering af alder | KvalitetsIT |
Terminologi
HL7 CDA | Standard til udveksling af oplysninger indenfor sundhedsvæsenet. |
...
Forkortelse | Betydning |
|---|---|
ODR | Organdonorregistret |
Arkitektur
Organdonorregister-servicen består af en webservice, som andre systemer kan benytte til at oprette, opdatere, slette og aflæse seneste registrering fra.
| HTML |
|---|
<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
| displayName | ODR-Arkitektur v7 |
|---|---|
| name | ODR-Arkitektur v7 |
| pagePin |
...
2
| 2 |
Standarder
Alt data udveksling er basereret på HL7 Clinical Document Architecture (CDA).
...
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 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 MinLog med MinLog2. Med undtagelse af borgerens egen tilgang og ændring af datasystem bruger.
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)
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.
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
<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> |
PersonInformation
Der findes pt 2 implementationer af kald til PersonInformation. Den oprindelige CprExist og den senere PersonInformation.
CprExist
Gennem kald til PersonInformation 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. PersonInformation kaldes ikke
- WARNING: PersonInformation service kaldes. Hvis denne service svarer, at CPR nummeret ikke findes, eller er inaktivt, så audit logges denne information.
- REJECT: PersonInformation service kaldes. Svaret fra denne er en hård validering dvs. kaldet til ODR fejler, hvis PersonInformation service ikke kender CPR nummeret eller det er inaktivt.
PersonInformation Service benyttes ligeledes til validering af alder. Denne validering foretages altid.
PersonInformation
Gennem kald til denne foretages opslag efter personer, som er døde og som er flyttet ud af landet. Dette anvende af slettejobbet. Ligeledes anvendes den til at få en liste af Personer, der snart fyldes 18 år. Dette anvendes af notifikations jobbet sådan, at de kan få et brev omkring organ donation.
Digital Post
Gennem kald til Digital Post Adapter foretages forsendelse af notifikationer om organ donation til borgere. For nuværende drejer det sig om borgere som snart bliver 18.
Design
Gliffy Diagram displayName ODR-Design v3 name ODR-Design v3 pagePin
| displayName | ODR-Design v3 |
|---|---|
| name | ODR-Design v3 |
| pagePin |
...
10
| 10 |
I guide til udviklere findes der et diagram, som kan hjælpe med at forstå den konkrete implementation af forretningslogikken til notifikationsjobbet herunder status opdateringen.
Datamodel
Forretningsservice
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.
| HTML |
|---|
<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.
...
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:
...
Operations
Afsendelse af notifikationer gør brug af 2 database tabeller, for at kunne holde styr på, hvilken dag, der er håndteret samt, hvilke personer, der har fået tilsendt post på dagen. De detaljerede schema for disse er:
NotificationDate
| FeltNavn | Optional | Unik nøgle | Datatype | Beskrivelse |
| NotificationDatePID | Nej | Ja | INT(11) | Tabellen unikke nøgle, auto inc |
| Status | Nej | Nej | VARCHAR(50) | Angiver hvilken status den aktuelle dato den enkelte har i flowet at få sine notifkationer sent Kan indholde værdierne: Pending, InProgress, Sent, Completed, Error, Locked |
| LatestDate | Nej | Ja | Date | Den dato som behandles. Notifikationsjobbet indsætter en ny dato, når det er kørt færdigt på den gamle. |
| CreatedDateTime | Nej | Nej | DATETIME | Sættes automatisk når recorden oprettes |
| ModifiedDateTime | Nej | Nej | DATETIME | Opdateres automatisk når recorden opdateres |
NotificationPerson
| FeltNavn | Optional | Unik nøgle | Datatype | Beskrivelse |
| NotificationPersonPID | Nej | Ja | INT(11) | Tabellen unikke nøgle, auto inc |
| NotificationDatePID | Nej | Nej | INT(11) | Fremmednøgle til NatificationDate |
| Status | Nej | Nej | VARCHAR(50) | Angiver hvilken status den enkelte record har i flowet at blive sent Kan indholde værdierne: Pending, InProgress, Sent, Completed, Error |
| Type | Nej | Ja | VARCHAR(50) | Unik nøgle sammen med PersonIdentifier |
| PersonIdentifier | Nej | Ja | VARCHAR(30) | Unik nøgle sammen med Type |
| SentAtDateTime | Nej | Nej | DATETIME | Angiver det tidspunkt notifikationen er forsøgt sendt med digital post |
| ErrorMessage | Nej | Nej | VARCHAR(2000) | Hvis der kom en fejl tilbage ved afsendelse af digital post gemmes den her. Status sættes samtidig til Error |
| CreatedDateTime | Nej | Nej | DATETIME | Sættes automatisk når recorden oprettes |
| ModifiedDateTime | Nej | Nej | DATETIME | Opdateres automatisk når recorden opdateres |
Baggrundsjob
Slettejob m.m
ODR servicen indeholder to baggrundsjobs der kan henholdsvis slette registreringer for afdøde personer og ugyldiggøre registreringer for udrejste personer.
Registreringerne for en afdød slettes 60 dage (kan konfigureres) efter personen er afgået ved døden. Registreringerne bliver slettet fra databasen og data kan således ikke genskabes igen.
Registreringerne for en person der er udrejst opdateres (ValidTo angives) så registreringen ikke længere er gyldig. Hvis personen vender tilbage til Danmark igen, så skal der laves en ny registrering af organdonation.
Jobbet for OrganDonorDeceased består af følgende operationer:
| Operation | Beskrivelse |
| Default operation | Formål: Benyttes til at fylde operationer på stakken, når stakken er tom. Java klasse: OrganDonorDeceasedCleanupSupplier Batching: For hver dag i et skudår i formatet ddMM (dd=dag i format 01, MM=måned i format 09) oprettes en "prefix baseret operation" Shuffles: nej Andet: - |
| Prefix baseret operation | Formål: Givet et prefix mellem 0101 og 3112 hentes cpr alle borgere, som har en registrering i ODR, hvor borgerens cpr starter med prefix. Java klasse: CPRPrefixDeceasedCleanupSupplier Batching: Opretter en mængde "borger id baseret operation", hver med et konfigurerbart antal af disse borger id'er Shuffles: ja Andet: - |
| Borger id baseret operation | Formål: Givet en liste af borger id'er, tages de id'er der tilhører afdøde borgere. Dette afgøres ved kald til PersonInformation. Java klasse: CPRBatchDeceasedCleanupSupplier Batching: Opretter et "oprydningsjob" med de afdøde borgers id Shuffles: nej Andet: - |
| Oprydningsjob | Formål: Givet en liste af borger id'er slettes i databasen registreringer for denne liste af id'er Java klasse: CPRDeceasedCleanupOperation Batching: na Shuffles: na Andet: - |
Jobbet for OrganDonorEmigrated består af følgende operationer:
| Operation | Beskrivelse |
| Default operation | Formål: Benyttes til at fylde operationer på stakken, når stakken er tom. Java klasse: OrganDonorEmigratedCleanupSupplier Batching: For hver dag i et skudår i formatet ddMM (dd=dag i format 01, MM=måned i format 09) oprettes en "prefix baseret operation" Shuffles: nej Andet: - |
| Prefix baseret operation | Formål: Givet et prefix mellem 0101 og 3112 hentes cpr alle borgere, som har en aktiv registrering i ODR, hvor borgerens cpr starter med prefix. Java klasse: CPRPrefixEmigratedCleanupSupplier Batching: Opretter en mængde "borger id baseret operation", hver med et konfigurerbart antal af disse borger id'er Shuffles: ja Andet: - |
| Borger id baseret operation | Formål: Givet en liste af borger id'er, tages de id'er der tilhører afdøde borgere. Dette afgøres ved kald til PersonInformation. Java klasse: CPRBatchEmigratedCleanupSupplier Batching: Opretter et "oprydningsjob" med de afdøde borgers id Shuffles: nej Andet: - |
| Oprydningsjob | Formål: Givet en liste af borger id'er opdateres ValidTo på borgerens registrering. Java klasse: CPREmigratedCleanupOperation Batching: na Shuffles: na Andet: - |
Notikationer
ODR servicen et baggrundsjob der kan sende notifikationer omkring organ donation til udvalgte borgere:
- borgere der snart fylder 18 år
Jobbet fremfinder de relevante personer og kalder digital post client med cpr og relevant brev template. Se iøvrigt se figur i guide til udviklere for detaljer omkring den konkrete logik.
Jobbet for OrganDonorNotification består af operationerne listet nedenfor. Hver operation kører som en transaktion, sådan at databasen forbliver konsistent uagtet at der opstår en fejl.
| Operation | Beskrivelse |
| Default operation | Formål: Benyttes til at fylde operationer på stakken, når stakken er tom. Den finder den næste dato der skal håndteres. Java klasse: OrganDonorDateNotificationSupplier Batching: na Shuffles: na Andet: - |
| Borger id baseret operation | Formål: Skaffer de borger id, hvortil der skal sendes en notifikation. De skaffes vha. PersonInformation Java klasse: OrganDonorFetchPersonNotificationSupplier Batching: den fulde fremfundne liste sendes videre Shuffles: na Andet: - |
| Borger id baseret operation | Formål: Givet listen af borger id gemmes disse ned i den fælles arbejds tabel Java klasse: OrganDonorPersonNotificationSupplier Batching: na Shuffles: na Andet: - |
| Borger id baseret operation | Formål: Henter en liste af borger id fra den fælles arbejds tabel med konfigurerbart antal Java klasse: OrganDonorPersonBatchNotificationSupplier Batching: opretter en mængde "Notifikationsjob", hver med et borgerid fra listen Shuffles: na Andet: - |
| Notifikationsjob | Formål: Sender en notifikation for et givet borger id Java klasse: OrganDonorSendNotificationOperation Batching: na Shuffles: na Andet: -
|