...

Introduktion til DDS

Baggrund for opslag i DDS Registry

Baggrunden for at tilbyde opslag gennem DDS Registry er:

”Formålet med NPI (Nationalt Patientindeks) er at tilvejebringe adgang til data om patienten fra forskellige datakilder via et indeks. Anvendersystemer (f.eks. Sundhedsjournalen) kan i indekset søge efter informationer om data på en given patient (metadata) og præsentere en oversigt over disse for sundhedsfaglige brugere og borgere. Såfremt en sundhedsfaglig bruger eller borger ønsker at få adgang til de bagvedliggende detaljerede patientdata, skal indekset levere tilstrækkelig information om, hvor og hvordan dette kan hentes. Hvis det system, der er kilde til data har etableret en standardiseret snitflade til at hente disse patientdata, vil den sundhedsfaglige bruger kunne hente disse, ligesom borgeren umiddelbart vil kunne hente data via sundhed.dk.

Indekset skal skabe adgang så:

• borgeren har muligheden for at se data fra de professionelle om sine undersøgelser og behandlinger

• de sundhedsprofessionelle får mulighed for at se metadata og derigennem få adgang til yderligere data om en specifik patient fra andre organisationer, og vist eget system (via Sundhedsjournalen), f.eks. ved modtagelse af patienter som er enten akut syge, ambulante med komplekse forløb eller i øvrigt ukendte for behandleren

…

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

Dokumentdelingsservice (DDS) består af to logiske services DDS Registry og DDS Repository, der tilsammen understøtter funktionerne

• Fremsøgning (DDS Registry)
  • Der etableres med løsningen en DDS Registry web service, som giver mulighed for opslag i DDS Registry for både sundhedspersoner og borgere.
  • 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.
• Hentning (DDS Repository)
  • Der etableres med løsningen en DDS Repository web service, som giver mulighed for både sundhedspersoner og borgere at udtrække dokumenter på baggrund af metadata registreret i dokumentdelingsservice.
  • DDS Repository benyttes som intelligent proxy for en eller flere dokumentkilder.
  • Udtræk gennemføres med operationen Retrieve Document Set, der er IHE XDS.b’s operation til udtræk af dokumenter fra et IHE repository.

Servicene gennemfører en række yderligere tjek, logninger og logningerbehandlinger af data:

• Logning i Min-log-servicen
• Igangsættelse af check af behandlingsrelation mellem borger og sundhedsfaglig
• Kontrol af samtykke herunder filtrering inden returnering af data
• Mulighed for værdispring
• For repository også bestemmelse af dokumentkildes webservice-endpoint
• Se DDS guide til anvendere, afsnit søgning og hentning hvor denne logik er udførligt beskrevet for registry henholdsvis repository blandt andet for forskellige brugertyper.

Servicene er yderligere indpakket i headers, som ikke er en del af IHE standarden:

• overholder Den Gode Web Service 1.0.1 (med få undtagelser som beskrevet i snitfladerne)
  • registry også OIO IDWS for borgeradgang
• kræver anvendersystem autentificeret af STS’en på NSP
  • registry

    • for sundhedsperson med minimum sikkerhedsniveau 4

    • for borger med minimum sikkerhedsniveau 3 eller IDWS borgerbilletter

  • repository
    • minimum sikkerhedsniveau 3
• kræver anvendersystem autoriseret, hvilket kontrolleres vha. whiteliste
• kræver bruger identificeret ved brug af attributter i en ekstra header, HSUID-headeren.
  • for repository skal også patient være identificeret i HSUID-headeren
• returnerer SOAPFault ved autentifikations- og autorisationsfejl samt ved visse systemfejl.

...