...

1. Opslag på patienter i Dokumentdelingsservicens registry
2. Registrering af metadata om dokumenter om patienter i Dokumentdelingsservicens registry.
3. Opdatering af metadata om dokumenter om patienter i Dokumentdelingsservicens registry.

Formålet med dette dokument er at beskrive systemarkitekturen for DDS Registry.

...

Introduktion til DDS Registry

...

NPI skal i passende omfang bygge på internationale standarder og profiler. IHE profilerne vinder stigende udbredelse internationalt ved indførelsen af IT i sundhedsvæsenet, og vil derfor være relevante at anvende i projektet. IHE profiler indgår i regionernes projekt vedrørende fællesregionalt billedindeks, og i EU projektet epSOS, hvor man skal kunne udveksle patientresuméer og elektroniske recepter på tværs af EU’s medlemsstater. NSI er derfor særligt interesserede i at få afdækket om IHE XDS og tilsvarende standarder (kost)effektivt kan understøtte en standardiseret og dynamisk indeksering af relevante sundhedsfaglige datakilder.”

...

Overblik over løsningen

Der etableres med løsningen en DDS Registry web service, som giver mulighed for opslag i DDS Registry

...

Baggrunden for registrering for både sundhedspersoner og borgere. Dette er beskrevet i DDS Registry er naturligvis, at opslag kun giver mening i det omfang, der findes data i indekset. Selvom opslag kunne returnere indhold fra andre indeks ved brug af IHE XDS Cross-Community Access (XCA), så opnås bedre performance ved at have indhold i det lokale indeks, dvs. i IHE Registry.

Med en snitflade på DDS Registry til registrering opnås følgende fordele:

1. Der kan etableres multiple DDS Registry-instanser, således at registrering til et enkelt IHE Repository kan foregå gennem flere adgangspunkter. Der kan fx etableres en DDS Registry pr. region med adgang til det ene IHE Repository.

2. NSP-baserede sikkerhedsløsninger kan anvendes til kontrol af, hvilke kildesystemer, der må foretage registrering i IHE Repository.

3. Sikring af overholdelse af affinitetsdomænet. Ved registrering af dokument-metadata kan der foretages skræddersyet validering af brug af klassifikationer og koder. Det er ikke givet, at det bagvedliggende IHE Registry kan varetage denne opgave.

4. Tidspunktet for en kildes seneste registrering kan opsamles (pt. er dette dog ikke implementeret) og returneres som ekstra information ved opslag. Derved kan en dokumentanvender afgøre, om alderen på dokument-metadata skyldes kildesystemets manglende forbindelse til indekset.

Overblik over løsningen

Der etableres med løsningen en DDS Registry web service, som giver mulighed for opslag i DDS Registry for både sundhedspersoner og borgere. Dette er beskrevet i DDS Registry opslag.

Med løsningen giver DDS Registry web service tillige mulighed for at kildesystemer kan registrere metadata om dokumenter om patienter, beskrevet i afsnit DDS Registry registrering.

...

Opslag gennemføres med operationen Reqistry Stored Query, der er IHE XDS.b’s operation til fremsøgning af metadata i et IHE registry. DDS Registry viderestiller fremsøgning af metadata til IHE Repository, der med produktet Healthshare er en implementation af netop IHE registry.

I DDS Registry’s implementation af Registry Stored Query fra IHE-standarden gennemføres desuden følgende ved sundhedspersons anvendelse af servicen:

• Logning i Min-log-servicen

• Igangsættelse af check af behandlingsrelation mellem borger og sundhedsfaglig

• Filtrering af det returnerede svar ved verifikation af at borgerens registrerede samtykker ikke forhindrer at metadata vises

• Mulighed for forceret fremsøgning (værdispring), som tilsidesætter check af samtykke

Anvendes Registry Stored Query af en borger anden end den borger, der er anført som patient, da gennemfører DDS logning i Min-log-servicen.

DDS Registry’s implementation af Registry Stored Query er, som beskrevet i [DDS Registry query snitflade], indpakket i headers, så den ud over IHE-standardens body:

• overholder Den Gode Web Service 1.0.1 (med få undtagelser som beskrevet i [DDS Registry query snitflade]) samt OIO IDWS for borgeradgang

• kræver anvendersystem autentificeret af STS’en på NSP

• for sundhedsperson med minimum sikkerhedsniveau 4

• for borger med minimum sikkerhedsniveau 3 eller IDWS borgerbilletter

• kræver anvendersystem autoriseret, hvilket kontrolleres vha. whiteliste

• kræver bruger identificeret ved brug af attributter i en ekstra header, HSUID-headeren.

• returnerer SOAPFault ved autentifikations- og autorisationsfejl samt ved visse systemfejl.

DDS Registry anvender eksterne ressourcer som vist i Figur 1 til at foretage behandling af et opslag. Denne behandling er beskrevet i det følgende afsnit.

Image Removed

Figur 1:  DDS Registry anvender ved opslag andre services og databaser

Behandling af opslag

Hvad enten bruger af DDS Registry er borger eller sundhedsperson foretages først autentificering og autorisering af henholdsvis anvendersystem og bruger.

Autorisation af anvendersystemet sker mod en whitelist i databasen.

Er bruger en borger sker følgende:

1. Er bruger anden borger end patienten, foretages:

   1. Kontrol af, at der er anført relation mellem borger og patient

   2. Kald af LogDataAdd på MinLogRegistration-servicen, så der foretages logning af borgerens adgang til den anden borgers data.

2. Opslaget viderestilles til IHE Registry

   1. Fejl i kald af IHE Registry bevirker fejl af opslaget

Er bruger en sundhedsperson sker følgende:

1. Er der anført cpr-nummer og Sundhedsstyrelsens autorisationsnummer for en sundhedsperson, som er ansvarlig for opslaget, kontrolleres overensstemmelse mellem cpr-nummer og autorisationsnummer i et autorisationsregister i database.

   1. Uoverensstemmelse mellem cpr-nummer og autorisationsnummer bevirker fejl af opslaget,

   2. Fejl i kontrollen bevirker logning, men ingen fejl af opslag

2. Ved kald af LogDataAdd på MinLogRegistration-servicen foretages logning af sundhedspersonens adgang til borgerdata.

   1. Fejl i kald af MinLogRegistration-servicen bevirker logning, men ingen fejl af opslag

3. Medmindre der er tale om værdispring, gennemføres kontrol af samtykke mod sundhedspersonen ved kald af ConsentForUserCheck på samtykkeverifikationsservicen.

   1. Fejl i kald af samtykkeverifikationsservicen bevirker fejl af opslaget

   2. Er der personligt negativt samtykke mod sundhedspersonen eller mod den sundhedsperson under hvis ansvar, der foretages opslag, da returnerer opslaget med en advarsel om, at samtykke forhindrer adgang til borgerdata

4. Opslaget viderestilles til IHE Registry

   1. Fejl i kald af IHE Registry bevirker fejl af opslaget

5. Medmindre der er tale om værdispring og medmindre forrige kald af samtykkeverifikationsservicen viste, at der ikke findes data-specifikke samtykker registreret for borgeren, gennemføres kontrol af data-specifikke samtykker mod sundhedspersonen. Dette sker ved kald af ConsentForDataCheck på samtykkeverifikationsservicen under anvendelse af udtræk fra resultatet fra IHE Registry.

   1. Fejl i kald af samtykkeverifikationsservicen bevirker fejl af opslaget

   2. Er der dele af resultatet fra IHE Registry, hvor der ikke er samtykke til adgang:

      1. Fjernes delene fra resultatet

      2. Tilføjes en advarsel om, at der er tilbageholdt borgerdata på grund af samtykkebegrænsning

6. Igangsættelse af kontrol af behandlingsrelation sker ved kald af Behandlingsrelationsservicen, medmindre det er konfigureret at servicen ikke skal kaldes.

   1. Fejl i kald af Behandlingsrelationsservicen bevirker logning, men ikke fejl af opslaget.

7. Det potentielt reducerede resultat returneres.

...

DDS Registry understøtter en række brugertype og adgangsscenarier. Disse brugertyper stille forskellige krav til autentifikations- og kaldkontekst. Derudover er anvendelsen af de eksterne services (samtykke, behandlingsrelation, minlog) forskellig for de forskellige adgangsscenarier.

Først gennemgåes de forskellige brugertyper og adgangsscenarier på et overordnet niveau (User Stories). Herefter beskrives, hvordan DDS Registry anvender eksterne services (samtykke, minlog og behandlerrelationservice) i forhold til de forskellige scenarier.

Endelig gennemgås adgangsscenarierne i forhold til den gældende sikkerhedsprotokol på DDS Registry: Den Gode Webservice (DGWS). Det gennemgåes, hvorledes adgangsscenarierne kan implementeres i autentifikations- og kaldkontekst for DGWS: Sosi Id-kort og HSUID header.

Brugertyper og adgangsscenarier

DDS Registry understøtter følgende DDS brugertyper:

• Borger: Borgere kan tilgå egne data, eller data på andre borgere, som de har en passende relation til (børn, fuldmagt)
• Sundhedsperson: Sundhedspersoner kan tilgå data på borgere, hvis der er hjemmel til dette (behandlingsrelation, ikke-negativt samtykke, værdispring)
• Ikke-autoriseret sundhedsprofessionel: Myndighedspersoner uden lægefaglig autorisation, men som har brug for at tilgå data på borgere (f.eks. adgang til aftaler for kommunale medarbejdere)

De forskellige DDS brugertyper giver anledning til en række adgangsscenarier dvs. måder, hvorpå disse kan tilgå DDS Registry for fremsøgning af dokumenter for et givent CPR nummer. 

...

Brug af eksterne services ved adgangsscenarier

De forskellige adgangsscenarier giver anledning til forskellige anvendelser af eksterne services. Disse anvendelser er opsummerert i nedenstående skema:

...

Kaldes for at se, om der skulle foreligge et negativt samtykke mod den sundhedspersonen eller den organisations, som vedkommende repræsenterer.

I tilfældet S3, hvor der arbejdes på vegne af en anden, så er det den sundhedsperson og organisation, der arbejdes på vegne af, der tjekkes.

Ved værdispring springes samtykketjek over

...

Ja

I tilfældet S3, hvor der arbejdes på vegne af en anden, så er det den sundhedsperson og organisation, der arbejdes på vegne af, der logges.

...

Ja

I tilfældet S3, hvor der arbejdes på vegne af en anden, så er det den sundhedsperson og organisation, der arbejdes på vegne af, der tjekkes.

...

...

Adgangsscenarier og DGWS

Ovenstående adgangsscenarier bestemmes i DDS Registry ud fra bruger- og kaldkonteksten i DGWS - nemlig SOSI Id-kort og HSUID headeren. 

DDS Registry bestemmer DDS brugertypen udfra kaldkonteksten: Nærmere bestemt udfra HSUID-headerens attributter UserType samt ResponsibleUserAuthorizationCode. Disse kan antage een af følgende værdier brugertyper:

...

Hver brugertype kræver, at der i det indgående kald findes et gyldigt SOSI id-kort. I det nedenstående gennemgåes de forskellige krav til fremskaffelsen af SOSI-idkortet for de forskellige brugertyper.

...

Bestemmes i sikkerhedshandleren for komponenten. En OIO IDWS billet betyder, at brugeren er en borger.

Hvis SOSI Idkort benyttes, så bestemmes brugertypen udfra HSUID headers attribut nsi:UserType (værdi 'nsi:Citizen')

...

Niveau 3 (F/VOCES - dette kræver særskilt aftale om anvendelse, jf Dokumentdelingsservice (DDS))

...

Niveau 4 (MOCES) 

...

Hvis OIO IDWS anvedes, så trækkes cpr nummeret ud af IDWS billetten.

Hvis DGWS benyttes, så bestemmes det udfra HSUID headers attribut nsi:ActingUserCivilRegistrationNumber

...

Bestemmes udfra HSUID headers attribut nsi:ActingUserCivilRegistrationNumber

For sekrætærer (S3) er det den person, der arbejdes på vegne af, der er relevant. Denne findes i HSUID headers attribut nsi:ResponsibleUserCivilRegistrationNumber

For scenariet S1 vil værdien af de to HSUID header attributter være ens.

...

opslag.

Anchor
DDS Registry opslag DDS Registry opslag

DDS Registry opslag

Opslag gennemføres med operationen Reqistry Stored Query, der er IHE XDS.b’s operation til fremsøgning af metadata i et IHE registry. DDS Registry viderestiller fremsøgning af metadata til IHE Repository, der med produktet Healthshare er en implementation af netop IHE registry.

I DDS Registry’s implementation af Registry Stored Query fra IHE-standarden gennemføres desuden følgende ved sundhedspersons anvendelse af servicen:

• Logning i Min-log-servicen

• Igangsættelse af check af behandlingsrelation mellem borger og sundhedsfaglig

• Filtrering af det returnerede svar ved verifikation af at borgerens registrerede samtykker ikke forhindrer at metadata vises

• Mulighed for forceret fremsøgning (værdispring), som tilsidesætter check af samtykke

Anvendes Registry Stored Query af en borger anden end den borger, der er anført som patient, da gennemfører DDS logning i Min-log-servicen.

DDS Registry’s implementation af Registry Stored Query er, som beskrevet i [DDS Registry query snitflade], indpakket i headers, så den ud over IHE-standardens body:

• overholder Den Gode Web Service 1.0.1 (med få undtagelser som beskrevet i [DDS Registry query snitflade]) samt OIO IDWS for borgeradgang

• kræver anvendersystem autentificeret af STS’en på NSP

• for sundhedsperson med minimum sikkerhedsniveau 4

• for borger med minimum sikkerhedsniveau 3 eller IDWS borgerbilletter

• kræver anvendersystem autoriseret, hvilket kontrolleres vha. whiteliste

• kræver bruger identificeret ved brug af attributter i en ekstra header, HSUID-headeren.

• returnerer SOAPFault ved autentifikations- og autorisationsfejl samt ved visse systemfejl.

DDS Registry anvender eksterne ressourcer som vist i Figur 1 til at foretage behandling af et opslag. Denne behandling er beskrevet i det følgende afsnit.

Image Added

Figur 1:  DDS Registry anvender ved opslag andre services og databaser

Behandling af opslag

Hvad enten bruger af DDS Registry er borger eller sundhedsperson foretages først autentificering og autorisering af henholdsvis anvendersystem og bruger.

Autorisation af anvendersystemet sker mod en whitelist i databasen.

Er bruger en borger sker følgende:

1. Er bruger anden borger end patienten, foretages:

   1. Kontrol af, at der er anført relation mellem borger og patient

   2. Kald af LogDataAdd på MinLogRegistration-servicen, så der foretages logning af borgerens adgang til den anden borgers data.

2. Opslaget viderestilles til IHE Registry

   1. Fejl i kald af IHE Registry bevirker fejl af opslaget

Er bruger en sundhedsperson sker følgende:

1. Er der anført cpr-nummer og Sundhedsstyrelsens autorisationsnummer for en sundhedsperson, som er ansvarlig for opslaget, kontrolleres overensstemmelse mellem cpr-nummer og autorisationsnummer i et autorisationsregister i database.

   1. Uoverensstemmelse mellem cpr-nummer og autorisationsnummer bevirker fejl af opslaget,

   2. Fejl i kontrollen bevirker logning, men ingen fejl af opslag

2. Ved kald af LogDataAdd på MinLogRegistration-servicen foretages logning af sundhedspersonens adgang til borgerdata.

   1. Fejl i kald af MinLogRegistration-servicen bevirker logning, men ingen fejl af opslag

3. Medmindre der er tale om værdispring, gennemføres kontrol af samtykke mod sundhedspersonen ved kald af ConsentForUserCheck på samtykkeverifikationsservicen.

   1. Fejl i kald af samtykkeverifikationsservicen bevirker fejl af opslaget

   2. Er der personligt negativt samtykke mod sundhedspersonen eller mod den sundhedsperson under hvis ansvar, der foretages opslag, da returnerer opslaget med en advarsel om, at samtykke forhindrer adgang til borgerdata

4. Opslaget viderestilles til IHE Registry

   1. Fejl i kald af IHE Registry bevirker fejl af opslaget

5. Medmindre der er tale om værdispring og medmindre forrige kald af samtykkeverifikationsservicen viste, at der ikke findes data-specifikke samtykker registreret for borgeren, gennemføres kontrol af data-specifikke samtykker mod sundhedspersonen. Dette sker ved kald af ConsentForDataCheck på samtykkeverifikationsservicen under anvendelse af udtræk fra resultatet fra IHE Registry.

   1. Fejl i kald af samtykkeverifikationsservicen bevirker fejl af opslaget

   2. Er der dele af resultatet fra IHE Registry, hvor der ikke er samtykke til adgang:

      1. Fjernes delene fra resultatet

      2. Tilføjes en advarsel om, at der er tilbageholdt borgerdata på grund af samtykkebegrænsning

6. Igangsættelse af kontrol af behandlingsrelation sker ved kald af Behandlingsrelationsservicen, medmindre det er konfigureret at servicen ikke skal kaldes.

   1. Fejl i kald af Behandlingsrelationsservicen bevirker logning, men ikke fejl af opslaget.

7. Det potentielt reducerede resultat returneres.

Anchor
DDSRegistryBrugertyperAdgangsscenarier DDSRegistryBrugertyperAdgangsscenarier

Brugertyper og adgangsscenarier

DDS Registry understøtter en række brugertype og adgangsscenarier. Disse brugertyper stille forskellige krav til autentifikations- og kaldkontekst. Derudover er anvendelsen af de eksterne services (samtykke, behandlingsrelation, minlog) forskellig for de forskellige adgangsscenarier.

Først gennemgåes de forskellige brugertyper og adgangsscenarier på et overordnet niveau (User Stories). Herefter beskrives, hvordan DDS Registry anvender eksterne services (samtykke, minlog og behandlerrelationservice) i forhold til de forskellige scenarier.

Endelig gennemgås adgangsscenarierne i forhold til den gældende sikkerhedsprotokol på DDS Registry: Den Gode Webservice (DGWS). Det gennemgåes, hvorledes adgangsscenarierne kan implementeres i autentifikations- og kaldkontekst for DGWS: Sosi Id-kort og HSUID header.

Brugertyper og adgangsscenarier

DDS Registry understøtter følgende DDS brugertyper:

• Borger: Borgere kan tilgå egne data, eller data på andre borgere, som de har en passende relation til (børn, fuldmagt)
• Sundhedsperson: Sundhedspersoner kan tilgå data på borgere, hvis der er hjemmel til dette (behandlingsrelation, ikke-negativt samtykke, værdispring)
• Ikke-autoriseret sundhedsprofessionel: Myndighedspersoner uden lægefaglig autorisation, men som har brug for at tilgå data på borgere (f.eks. adgang til aftaler for kommunale medarbejdere)

De forskellige DDS brugertyper giver anledning til en række adgangsscenarier dvs. måder, hvorpå disse kan tilgå DDS Registry for fremsøgning af dokumenter for et givent CPR nummer. 

Brug af eksterne services ved adgangsscenarier

De forskellige adgangsscenarier giver anledning til forskellige anvendelser af eksterne services. Disse anvendelser er opsummerert i nedenstående skema:

Adgangsscenarier og DGWS

Ovenstående adgangsscenarier bestemmes i DDS Registry ud fra bruger- og kaldkonteksten i DGWS - nemlig SOSI Id-kort og HSUID headeren. 

DDS Registry bestemmer DDS brugertypen udfra kaldkonteksten: Nærmere bestemt udfra HSUID-headerens attributter UserType samt ResponsibleUserAuthorizationCode. Disse kan antage een af følgende værdier brugertyper:

• nsi:Usertype == nsi:Citizen  → DDS Borger
• nsi:Usertype == nsi:HealthcareProfessional samt lovlig værdi i nsi:ResponsibleUserAuthorizationCode→ DDS Sundhedsperson
• nsi:Usertype == nsi:HealthcareProfessional samt ingen, tom eller '-' værdi i nsi:ResponsibleUserAuthorizationCode → DDS Ikke-autoriseret sundhedsperson
  
  

Hver brugertype kræver, at der i det indgående kald findes et gyldigt SOSI id-kort. I det nedenstående gennemgåes de forskellige krav til fremskaffelsen af SOSI-idkortet for de forskellige brugertyper.

Adgangsscenarier og tests

De ovenstående adgangsscenarier giver anledning til en række integrationstests.

Målene med integrationstestene er at udføre en række tests, der påviser at:

• Adgangsscenarierne er understøttet af DDS som beskrevet ovenfor: Dvs det er muligt at få data ud af DDS i de forskellige scenarier
• Negative tests: For hvert scenarie vil integrationstestene inkludere en række negative tests .. det tjekkes f.eks. at der ikke kan anvendes værdispring i scenarie IA-1

Integrationstestene er bygget op på følgende måde:

• Integrationstestene i DDS er delt ind i testklasser, der dækker de ovenstående scenarier. De er navngivet med scenariernes ID som prefix og en efterfølgende beskrivende tekst , så sammenhængen med dokumenationen bevares.
• Alle testcases i integrationstestene er implementeret som metoder, der har en titel, der forklarer intentionen med testen.
• Alle testcases er bygge op efter samme skabelon med kommentarer, der klart definerer præconditions (Given), aktivering af funktion (When) og tjek af svar/postconditions (Then). Se f.eks. Martin Fowler: Given-When-Then

Således indeholder integrationstestsuiten følgende:

• B1BorgerVocesIntegrationsTest
• B2BorgerPaaVegneAfVocesIntegrationsTest
• S1SundhedspersonMocesIntegrationTest
• S1SundhedspersonVocesIntegrationTest
• S3SundhedspersonPaaVegneAfMocesIntegrationsTest
• S3SundhedspersonPaaVegneAfVocesIntegrationsTest
• IA1IkkeAutoriseretBrugerLaegeSekretaerIntegrationsTest
• IA1IkkeAutoriseretBrugerSundhedsAssistentIntegrationsTest
• IA1IkkeAutoriseretBrugerUdenRollerIntegrationsTest

For afvikling af integrationstests henvises til dokumenterne Testvejledning DDS Registry og Testvejledning DDS Repository.

Adgangsscenarier og tests

De ovenstående adgangsscenarier giver anledning til en række integrationstests.

Målene med integrationstestene er at udføre en række tests, der påviser at:

• Adgangsscenarierne er understøttet af DDS som beskrevet ovenfor: Dvs det er muligt at få data ud af DDS i de forskellige scenarier
• Negative tests: For hvert scenarie vil integrationstestene inkludere en række negative tests .. det tjekkes f.eks. at der ikke kan anvendes værdispring i scenarie IA-1

Integrationstestene er bygget op på følgende måde:

• Integrationstestene i DDS er delt ind i testklasser, der dækker de ovenstående scenarier. De er navngivet med scenariernes ID som prefix og en efterfølgende beskrivende tekst , så sammenhængen med dokumenationen bevares.
• Alle testcases i integrationstestene er implementeret som metoder, der har en titel, der forklarer intentionen med testen.
• Alle testcases er bygge op efter samme skabelon med kommentarer, der klart definerer præconditions (Given), aktivering af funktion (When) og tjek af svar/postconditions (Then). Se f.eks. Martin Fowler: Given-When-Then

Således indeholder integrationstestsuiten følgende:

• B1BorgerVocesIntegrationsTest
• B2BorgerPaaVegneAfVocesIntegrationsTest
• S1SundhedspersonMocesIntegrationTest
• S1SundhedspersonVocesIntegrationTest
• S3SundhedspersonPaaVegneAfMocesIntegrationsTest
• S3SundhedspersonPaaVegneAfVocesIntegrationsTest
• IA1IkkeAutoriseretBrugerLaegeSekretaerIntegrationsTest
• IA1IkkeAutoriseretBrugerSundhedsAssistentIntegrationsTest
• IA1IkkeAutoriseretBrugerUdenRollerIntegrationsTest

For afvikling af integrationstests henvises til dokumenterne Testvejledning DDS Registry og Testvejledning DDS Repository.

DDS Registry registrering

Der er to operationer til registrering af metadata om dokumenter: en operation til registrering af såkaldt statiske dokumenter og en til on-demand-dokumenter.

Til forskel fra et statisk dokument, hvor indholdet ligger fast, kan on-demand-dokumenter skabes dynamisk, dvs. med variabelt og potentielt dugfrisk indhold.

Registrering af statiske dokumenter gennemføres med operationen Reqister Document Set-B, der er IHE XDS.b’s operation til registrering af metadata om statiske dokumenter i et IHE registry svarende til arbejdsgangen ITI-42.

I DDS Registry’s implementation af Reqister Document Set-B gennemføres følgende ved anvendelse af servicen:

• Register Document Set-B-requesten viderestilles til IHE register-instansen IHE Registry.
• Er registrering i IHE Registry succesfuld foretages audit-logning af hvilket system, der har registreret metadata om en borger (dette foretages for alle de borgere, der indgår metadata om i Reqister Document Set-B-requesten).

Registrering af on-demand-dokumenter gennemføres med Register On-Demand Document Entry. Denne er IHE XDS.b’s operation til registrering af metadata om on-demand-dokumenter i et IHE registry svarende til arbejdsgangen ITI-61.

I DDS Registry gennemføres følgende ved anvendelse af Register On-Demand Document Entry:

• Register On-Demand Document Entry-requesten viderestilles til IHE register-instansen IHE Registry.
• Er registrering i IHE Registry succesfuld foretages audit-logning af hvilket system, der har registreret metadata om en borger (dette foretages for alle de borgere, der indgår metadata om i Register On-Demand Document Entry-requesten).

En enkelt operation UpdateDocumentSet i varianten UpdateAvailabilityStatus benyttes til at sætte tilstanden af en eksisterende metadata-indgang til deprecated (eller approved). Dette er den eneste metode til at sikre, at seneste tilstand er deprecated. I IHE XDS.b svarer dette til ITI-57 UpdateDocumentSet.

I DDS Registry gennemføres følgende ved anvendelse af Update Document Set:

• Update Document Set-requesten kontrolleres at være af varianten UpdateAvailabilityStatus
• Update Document Set-requesten viderestilles til IHE register-instansen IHE Registry.
• Er registrering i IHE Registry succesfuld foretages audit-logning af hvilket system, der har registreret tilstandsskift af metadata om en borger (dette foretages for alle de borgere, der indgår metadata om i Update Document Set-requesten).

DDS Registry’s implementation af Reqister Document Set-B, Register On-Demand Document Entry og Update Document Set er, som beskrevet i [DDS Registry register snitflade], indpakket i headers, så den ud over IHE-standardens body:

• Overholder Den Gode Web Service 1.0.1 (med få undtagelser som beskrevet i [DDS Registry register snitflade])
• Kræver anvendersystem autentificeret af STS’en på NSP med minimum sikkerhedsniveau 4 (eller 3 afhængig af tilslutningsaftalen)
• Kræver anvendersystem autoriseret, hvilket kontrolleres vha. whiteliste
• Returnerer SOAPFault ved autentifikations- og autorisationsfejl samt ved visse systemfejl.

Til behandling af registrering anvender DDS Registry eksterne ressourcer som vist i Figur 1.

Image Removed

Figur 2:  Til registrering anvender DDS Registry de viste services og databaser

Designmålsætninger og -beslutninger

...

Den generelle servicestruktur er at servicen implementeres som to webservicesen webservice, der implementerer det webinterface, der er genereret fra DDS Registry WSDL. Webservicen DDSRegistryWS er en tynd skal, der for sin eneste weboperation til opslag i DDS Registry blot kalder den faktiske implementation DDSRegistryQueryImpl. De to weboperationer til registrering håndteres af DDSRegistryRegisterImpl.Webservice DDSRegistryMetadataUpdateWS er ligeledes DDS Registry WSDL. Webservicen DDSRegistryWS er en tynd skal, der for Update Document Set-operationen sin eneste weboperation til opslag i DDS Registry blot kalder den tilsvarende faktiske implementation i DDSRegistryQueryImpl.

Figur 3: Implementationen af webservice-interfaces

...

DDSRegistryQueryImpl foretager fejlhåndtering ved at omdanne exceptions til SOAP fault med indhold som beskrevet i [DDS Registry query snitflade]. En undtagelse herfra er dog ved exception pga. negativt samtykke mod en sundhedsperson, hvor der dannes en advarsel i et tomt svar, også beskrevet i [DDS Registry query snitflade].

Behandling af registrering

DDSRegistryRegisterImpl foretager også autentifikation og autorisation af anvendersystem vha. DGWSProvider. Da registrering håndteres som system-til-system-kald gennemføres ingen bruger-autentifikation eller –autorisation.

Øvrig behandling af registrering foretages i DDSRegistryRegisterLogic beskrevet i afsnit DDS Registry Register Logicder dannes en advarsel i et tomt svar, også beskrevet i [DDS Registry query snitflade].

Service business logik

DDSRegistryQueryLogic

...

I Figur 5 er vist et sekvensdiagram for DDSRegistryQueryLogic ved opslag foretaget af en sundhedspersons uden anvendelse af værdispring, hvor: der ikke er personligt negativt samtykke mod sundhedspersonen eller den ansvarlige sundhedsperson; der er data-specifikt negativt samtykke.

DDSRegistryRegisterLogic

...

.

Generel struktur af invoker

...