Indhold
1 Introduktion
1.1 Formål
1.2 Læsevejledning
1.3 Dokumenthistorik
1.4 Definitioner og referencer
2 Opslag og indhentning af laboratoriesvarsdokumenter via Dokumentdelingsservices
2.1 Forudsætninger for anvendelse af Dokumentdelingsservices
2.2 Opslag på tilgængelige laboratoriesvarsdokumenter
2.2.1 Søgeparametre
2.2.2 Forespørgsel
2.2.3 Svar
2.3 Indhentning af Svareksponeringsservicedokumenter
2.3.1 Forespørgsel
2.3.2 Svar
2.4 Videre behandling af fremfundne laboratoriesvarsdokumenter

Introduktion

Formål

Nærværende dokument beskriver i detaljer, hvordan opslag og udtræk af laboratoriesvarsdokumenter foretages ved brug af Dokumentdelingsservices på den nationale service platform (NSP).

Læsevejledning

Dette dokument henvender sig til udviklere og arkitekter, der skal anvende laboratoriesvar via den nationale infrastruktur til deling af dokumenter - Dokumentdelingsservices. For en overordnet beskrivelse heraf henvises til dokumentet \[Svareksponeringsservice anvender\].
Dokumentdelingsservices (DDS), der er beskrevet i \[DDS anvender\], er baseret på dokumentdelingsstandarden IHE XDS, der beskriver roller og ansvar for forskellige aktører i dokumentdeling. Et centralt led i denne dokumentdeling er udveksling af metadata om dokumenter. Strukturen og dele af indholdet er fastlagt ved IHE XDS, mens størstedelen af indholdet er fastlagt i en såkaldt affinitetsdomænedefinition og dennes understøttende dokumenter.
Det er tilstræbt, at dokumentanvender af laboratoriesvarsdata kan læse nærværende snitfladebeskrivelse, \[Svareksponeringsservice anvender\] samt refererede DDS snitfladebeskrivelser og anvenderguides uden at skulle kende til detaljerne i strukturen og indhold af metadata.

Dokumenthistorik

Definitioner og referencer

Opslag og indhentning af laboratoriesvarsdokumenter via Dokumentdelingsservices

I \[DDS anvender\] er beskrevet, hvordan et system, benævnt _dokumentanvender{_}, kan søge på metadata om dokumenter, der er registreret og stillet til rådighed for dokumentdeling af dokumentkilder. Efterfølgende kan dokumentanvender benytte metadata til at indhente dokumenterne. Ved at anvende Dokumentdelingsservices på NSP'en får dokumentanvender et sted at foretage opslag og indhentning, uden at skulle kende til og kunne forbinde til dokumentkilderne.
Ved anvendelse af Dokumentdelingsservicen til opslag returneres metadata for de dokumenter, der:

1. er registreret i Dokumentdelingsservicen,
2. matcher givne søgeparametre, herunder patient-id,
3. ikke er omfattet af patientens samtykke-begrænsninger

På baggrund af returnerede metadata kan en dokumentanvender udvælge hvilke dokumenter, der ønskes indhentet. Indhentning af dokumenterne sker ved anvendelse af Dokumentdelingsservicen til indhentning, der returnerer de dokumenter der:

1. er identificerede i forespørgslen,
2. på kaldstidspunktet kunne indhentes af Dokumentdelingsservicen fra den kilde, dokumentet/dokumenterne stammer fra,
3. ikke er omfattet af patientens samtykke-begrænsninger

En dokumentanvender, der er interesseret alene i laboratoriesvarsdokumenter, kan indsnævre de dokumenter, der returneres metadata for, ved at give søgeparametre til opslaget. Hvilke dokumenter, der returneres metadata for, afhænger dog stadig af de dokumentkilder, der har registreret metadata.

Forudsætninger for anvendelse af Dokumentdelingsservices

Brug af Dokumentdelingsservices forudsætter:

• Indgåelse af serviceaftale med Sundhedsdatastyrelsen via NSPOP Se https://www.nspop.dk/display/web/Aftaler (Aftaler).
• Erhvervelse af certifikat
  • Som udgangspunkt kræves medarbejdercertifikat (MOCES) Se https://www.nspop.dk/pages/viewpage.action?pageId=25663385 (FAQ Fælles testmiljøer).
  • Såfremt aftalt med Sundhedsdatastyrelsen kan andet certifikat anvendes

Opslag på tilgængelige laboratoriesvarsdokumenter

Til opslaget mod Dokumentdelingsservice på tilgængelige laboratoriesvars-dokumenter for en given patient, skal der anvendes en række søgeparametre beskrevet i det følgende.

Søgeparametre

I Tabel 1 er anført de søgeparametre, der forventeligt vil variere med patient og ønsket periode, mens Tabel 2 indeholder de søgeparametre, der er af mere statisk karakter. Alle søgeparametre kan dog varieres uafhængigt heraf, hvis dokumentanvender fx ønsker ugyldige dokumenter eller ønsker at søge på dokumenter i andre formater.

Tabel 1 Basale søgeparametre ved opslag på laboratoriesvarsdokumenter.

Søgeparametrene i Tabel 2 anvendes i opslaget for at indsnævre returnerede metadata til de gyldige dokumenter, hvor dokumentet er af typen laboratoriesvarsdokumenter, der overholder \[Svareksponeringsservice snitflade\].

Tabel 2 Søgeparametre til i videst muligt omfang at indsnævre fremfundne metadata til de, der omhandler laboratoriesvarsdokumenter. De konkrete værdier fremgår af afsnit 2.2.2.
Opslag med disse søgeparametre giver tilgængelige metadata for laboratoriesvarsdokumenter på pågældende patient. Hvorvidt parametrene er krævet eller ej, er set i forhold IHE XDS standarden. Alle parametre i Tabel 2 er anbefalede for bedst mulig indsnævring af udfaldet ift. Svareksponeringsservice-dokumenter.

Øvrige søgeparametre

Udover ovennævnte søgeparametre, der bør benyttes for maksimal filtrering af dokumenter i forhold til at finde laboratoriesvarsdokumenter specifikt, er der også mere generelle parametre, der kan benyttes.
Deling af en patients laboratoriesvar sker ved brug af IHE XDS-proxyer, der udstiller metadata og laboratoriesvarsdokumenter til henholdsvis opslag og indhentning via Dokumentdelingsservicen. IHE XDS-proxyerne afviger – delvist afhængigt af deres konfiguration – fra håndteringen foreskrevet i IHE-standarderne. Afvigelserne præciseres i Tabel 3.

Tabel 3: Mulige afvigende parametre

Forespørgsel

Opslag i Dokumentdelingsservicen sker ved brug af Dokumentdelingsservicens DocumentRegistry_RegistryStoredQuery webservice-operation, som beskrevet i \[Opslag snitflade\]. I det nedenstående fokuseres på den SOAP-body, der skal skabes ved forespørgsel, og den SOAP-body, der returneres i svar. Se i øvrigt \[Opslag snitflade\] for fejlkoder mm.

SOAP-body i forespørgslen til dokumentopslag er struktureret som en såkaldt AdhocQueryRequest indeholdende en query af varianten FindDocuments. At det er varianten FindDocuments afspejles af, at det indlejrede AdhocQuery element benytter id-attribut med værdien urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d, der er query id defineret for FindDocuments.

Eksempel på forespørgsel:

<AdhocQueryRequest>
 <ResponseOption returnComposedObjects="true" returnType="LeafClass" />
 <AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d">
    <!—- CPR-nummer for patient -->
    <Slot name="$XDSDocumentEntryPatientId">
     <ValueList>
      <Value>'2512484916^^^&amp;1.2.208.176.1.2&amp;ISO'</Value>
     </ValueList>
    </Slot>
    <!—- Dokumenter skal vedrøre hændelser på eller efter dette tidspunkt, givet i Zulu-tid -->
    <Slot name="$XDSDocumentEntryServiceStartTimeFrom">
     <ValueList>
      <Value>20160620104500</Value>
     </ValueList>
    </Slot>
    <!—- Dokumenter skal vedrøre hændelser før dette tidspunkt, givet i Zulu-tid -->
    <Slot name="$XDSDocumentEntryServiceStopTimeTo">
     <ValueList>
      <Value>20160625112500</Value>
     </ValueList>
    </Slot>
    <!—- Søg på gældende dokumenter -->
    <Slot name="$XDSDocumentEntryStatus">
     <ValueList>
      <Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')</Value>
     </ValueList>
    </Slot>
    <!—- Finkornet dokumenttype er LABORATORY REPORT.TOTAL (Laboratoriesvar) -->
    <Slot name="$XDSDocumentEntryTypeCode">
     <ValueList>
      <Value>('11502-2^^2.16.840.1.113883.6.1')</Value>
     </ValueList>
    </Slot>
    <!—- Søg på Svareksponeringsservice laboratoriesvar -->
    <Slot name="$XDSDocumentEntryFormatCode">
     <ValueList>
     <Value>('urn:ad:dk:medcom:labreports:svareksponeringsservice^^1.2.208.184.100.10')</Value>
     </ValueList>
    </Slot>
    <!—- Søg på faste eller On-demand dokumenter -->
    <Slot name="$XDSDocumentEntryType">
     <ValueList>
      <Value>('urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1')</Value>
      <Value>('urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248')</Value>
     </ValueList>
    </Slot>
  </AdhocQuery>
</AdhocQueryRequest>

Søgeparameter for patient-id

Patient-id er encoded som <id>^^^&<assigning authority>&ISO, hvor <id> er et dansk cpr-nummer og <assigning authority> er en object identifier (OID) for udsteder af danske cpr-numre, 1.2.208.176.1.2.
Som obligatorisk søgeparameter i AdhocQueryRequesten skal følgende tilføjes (her vist for patient med cpr-nummer 2512484916 med escapede XML-tegn):

    <Slot name="$XDSDocumentEntryPatientId">
     <ValueList>
      <Value>'2512484916^^^&amp;1.2.208.176.1.2&amp;ISO'</Value>
     </ValueList>
    </Slot>

Søgeparameter for starttidspunkt

De valgfrie søgeparametre for starttidspunkt, hvor der kan søges eksakt eller via periode, gives ved følgende:

    <Slot name="$XDSDocumentEntryServiceStartTimeFrom">
     <ValueList>
      <Value>20160620104500</Value>
     </ValueList>
    </Slot>

    <Slot name="$XDSDocumentEntryServiceStartTimeTo">
     <ValueList>
      <Value>20160620112500</Value>
     </ValueList>
    </Slot>

De faktiske værdier for tidspunkter specificeres i Zulu-tid i formatet DTM (DTM er beskrevet i ITI TF-3 afsnit 4.1.7.) med følgende mønster givet alene ved tal: YYYY\[MM\[DD\[hh\[mm\[ss\]\]\]\]\].
Der kan søges med periode (fra-til), med inkluderet tidspunkt (fra) og med ekskluderet tidspunkt (til) ved at medtage henholdsvis begge søgeparametre, første søgeparameter og sidste søgeparameter. Metadata i dokumentdelingsservicen, XDSDocumentEntry.serviceStartTime, evalueres mod søgeparametrene som følger:

$XDSDocumentEntryServiceStartTimeFrom <=
XDSDocumentEntry.serviceStartTime < 
$XDSDocumentEntryServiceStartTo

Søgeparameter for sluttidspunkt

De valgfrie søgeparametre for sluttidspunkt, hvor der kan søges eksakt eller via periode, gives ved følgende:

    <Slot name="$XDSDocumentEntryServiceStopTimeFrom">
     <ValueList>
      <Value>20160621104500</Value>
     </ValueList>
    </Slot>

    <Slot name="$XDSDocumentEntryServiceStopTimeTo">
     <ValueList>
      <Value>20160625112500</Value>
     </ValueList>
    </Slot>

De faktiske værdier for tidspunkter specificeres i Zulu-tid i formatet DTM (DTM er beskrevet i ITI TF-3 afsnit 4.1.7.) med følgende mønster givet alene ved tal: YYYY\[MM\[DD\[hh\[mm\[ss\]\]\]\]\].
Der kan søges med periode (fra-til), med inkluderet tidspunkt (fra) og med ekskluderet tidspunkt (til) ved at medtage henholdsvis begge søgeparametre, første søgeparameter og sidste søgeparameter. Metadata i dokumentdelingsservicen, XDSDocumentEntry.serviceStopTime, evalueres mod søgeparametrene som følger:

$XDSDocumentEntryServiceStopTimeFrom <=
XDSDocumentEntry.serviceStopTime < 
$XDSDocumentEntryServiceStopTo

Søgeparametre for præcisering af specialer for laboratoriesvar

Laboratoriesvar fra Svareksponeringsservicen kan fremsøges efter specialer. I nedenstående tabel er anført hvilke værdier, der skal anvendes ved opslag på metadata, for at der kan indhentes laboratoriesvar med tilsvarende specialer.

Værdierne fra kolonnerne under Værdier til søgeparameter, anvendes for søgeparameteren $XDSDocumentEntryPracticeSettingCode. Der kan anføres et eller flere sæt værdier, afhængigt af, hvilke specialer, der ønskes. Anføres ingen værdier i søgeparameteren, svarer dette til alle specialerne. 

Følgende eksempel viser søgeparametrene for opslag med henblik på indhentning af laboratoriesvar inden for specialerne klinisk mikrobiologi og klinisk biokemi.

    <Slot name="$XDSDocumentEntryPracticeSettingCode ">
     <ValueList>
      <Value>('408454008^^2.16.840.1.113883.6.96')</Value>
      <Value>('394596001^^2.16.840.1.113883.6.96')</Value>
     </ValueList>
    </Slot>

Søgeparametre med faste værdier (for laboratoriesvar fra Svareksponeringsservicen)

Dokumenttypen angives som laboratoriesvarsdokumenttype (Koden 11502-2 angiver et LABORATORY REPORT.TOTAL Dokument i kodesystemet Logical Observation Identifiers Names and Codes (LOINC) identificeret ved OID 2.16.840.1.113883.6.1.) med følgende søgeparameter:

    <Slot name="$XDSDocumentEntryTypeCode">
     <ValueList>
      <Value>('11502-2^^2.16.840.1.113883.6.1')</Value>
     </ValueList>
    </Slot>

Format angives med følgende søgeparameter, hvor værdierne udpeger formatet for Svareksponeringsservice laboratoriesvardokumenter, der overholder \[Svareksponeringsservice snitflade\]:

    <Slot name="$XDSDocumentEntryFormatCode">
     <ValueList>   <Value>('urn:ad:dk:medcom:labreports:svareksponeringsservice^^ 1.2.208.184.100.10')</Value>
     </ValueList>
    </Slot>

Søgeparameteren for status gives ved:

    <Slot name="$XDSDocumentEntryStatus">
     <ValueList>
      <Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')</Value>
     </ValueList>
    </Slot>

Ved værdien '…:Approved' søges for gældende dokumentmetadata. Der kan alternativt søges for enten forældede dokumentmetadata eller både gældende og forældede dokumentmetadata, men dette er atypisk.
Søgeparameter for faste dokumenter og dokumenter genereret on-demand er givet ved:

    <!—- Søg på faste eller On-demand dokumenter -->
    <Slot name="$XDSDocumentEntryType">
     <ValueList>
      <Value>('urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1')</Value>
      <Value>('urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248')</Value>
     </ValueList>
    </Slot>

Svar

Svarets SOAP-body indeholder fremfundne dokument-metadata, hvor hvert dokuments metadata er fastholdt i en ExtrinsicObject–struktur.

<AdhocQueryResponse>
…
  <RegistryObjectList>
    <ExtrinsicObject mimeType="text/xml" … home="urn:oid:1.2.3">
…
     <Slot name="repositoryUniqueId">
      <ValueList>
       <Value> 1.2.3.4.55.66</Value>
      </ValueList>
     </Slot>
…
     <ExternalIdentifier 
      registryObject="urn:uuid:37ce367c-e4f3-463c-bff5-c8d7b512ebf1"
      identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
      value="12345678901234567" 
      lid="urn:uuid:0202562e-f942-4c73-85f6-f20bbe8c145d"
      id="urn:uuid:0202562e-f942-4c73-85f6-f20bbe8c145d">
      <Name>
       <LocalizedString value="XDSDocumentEntry.uniqueId" />
      </Name>
      <VersionInfo versionName="1.1" />
     </ExternalIdentifier>
…
    </ExtrinsicObject>
  </RegistryObjectList>
…   
</AdhocQueryResponse>

Behandling af svar

For hvert dokument, hvortil der er returneret metadata, skal det afgøres, hvorvidt dokumentet ønskes indhentet. En pragmatisk løsning vil være at inddrage alle dokumenter. Skal der foretages filtrering på baggrund af metadata vil det være relevant at konsultere affinitetsdomænedefinitionen.
For hvert ønsket dokument skal følgende metadata fremfindes i opslagssvaret og anvendes i indhentningsforespørgslen:

Som beskrevet i \[Opslag snitflade\] kan et eller flere dokumenters metadata være tilbageholdt grundet samtykke-begrænsninger. I \[Opslag snitflade\] er beskrevet, hvordan dette er markeret i svaret på opslag. Det kan være relevant at informere en dokumentanvender-bruger om dette samt om mulighed for, under skærpet logning, at gentage opslaget ved anvendelse af såkaldt værdispring. Derved gennemføres opslaget, hvor samtykke-begrænsninger tilsidesættes.

Indhentning af Svareksponeringsservicedokumenter

Indhentning af dokumenter fra Dokumentdelingsservicen sker ved brug af Dokumentdelingsservicens DocumentRepository_RetrieveDocumentSet webservice-operation, som beskrevet i \[Indhentning snitflade\]. I det nedenstående fokuseres på den SOAP-body, der skal skabes ved forespørgsel, og den SOAP-body, der returneres i svar. Se i øvrigt \[Indhentning snitflade\] for fejlkoder, samt markering i svaret ved utilgængelige dokumenter, dokumenter tilbageholdt grundet samtykke-begrænsninger mm.

Forespørgsel

SOAP-body i forespørgslen til dokumentindhentning er struktureret som en såkaldt RetrieveDocumentSetRequest-struktur.
For hvert dokument, der ønskes indhentet skabes en DocumentRequest-struktur, hvor det specificeres:

• RepositoryUniqueId
• DocumentUniqueId
• HomeCommunityId udfyldes kun såfremt der blev returneret en værdi i metadata for dokumentet.

Værdierne tages fra svaret på opslaget, som beskrevet i afsnit 2.2.3.1.
Eksempel:

  <RetrieveDocumentSetRequest>
   <DocumentRequest>
    <RepositoryUniqueId>1.2.3.4.55.66</RepositoryUniqueId>
    <DocumentUniqueId>12345678901234567</DocumentUniqueId>
   </DocumentRequest>
 </RetrieveDocumentSetRequest>

Håndtering af relation mellem bruger og patient

Ved opslag på metadata og indhentning af dokument, anføres i en header (Dette er Healthcare Service User Identification (HSUID) headeren til Dokumentdelingsservicen. Relation sættes i attributten nsi:CitizenUserRelation.) i kaldet til Dokumentdelingsservicen, hvorvidt brugeren er borger eller sundhedsperson. I samme header, kan der for bruger af borger-typen anføres en relation mellem bruger og den patient, der laves oplag eller indhentes dokumenter om.
Relation mellem bruger og patient er medgivet som parameter i kaldet til Svareksponeringsservicen XDS-adapteren med følgende tilladte værdier:

Såfremt der ikke er medgivet en relation vil relationen automatisk blive videreført til Svareksponeringsservicen som "Self" for borger-type brugere såfremt patient-id'et og bruger-id'et er identiske. Se \[Svareksponeringsservice snitflade\] for nærmere beskrivelse af behandlingen af forespørgslen ved de forskellige relationer.

Svar

Svarets SOAP-body indeholder få dokument-metadata for fremfundne dokumenter, herunder for hvert dokument en reference til en MTOM encoded repræsentation af dokumentet indeholdt i HTTP response.

  <RetrieveDocumentSetResponse>
   <DocumentResponse>
    <RepositoryUniqueId>1.2.3.4.55.66</RepositoryUniqueId>
    <DocumentUniqueId>12345678901234567</DocumentUniqueId>
    <mimeType>text/xml</mimeType>
    <Document>
     <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include"
      href="cid:2f35d330-b1c3-4799-8655-18a22e55e518-10@urn%3Aihe%3Aiti%3Axds-
            b%3A2007" />
    </Document>
   </DocumentResponse>
  </RetrieveDocumentSetResponse>

Dokumentets indhold er fastholdt i HTTP-svaret:

--uuid:058cdd20-9071-41d2-9f57-4a8b1f901997
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-ID: <2f35d330-b1c3-4799-8655-18a22e55e518-10@urn:ihe:iti:xds-b:2007>
… MTOM-encoding af dokumentet

Hvordan dokumentet/dokumenterne aflæses i praksis vil afhænge af hvilket webservice-framework, der er anvendt af dokumentanvender. Det kan være så simpelt som at få et byte array returneret ved et getDocument()-kald.

Som ved opslag kan samtykke-begrænsninger bevirke, at data tilbageholdes. I \[Indhentning snitflade\] er beskrevet, hvordan dette er markeret i svaret på indhentning. Det kan være relevant at informere en dokumentanvender-bruger om dette samt om mulighed for, under skærpet logning, at foretage såkaldt værdispring, hvor samtykke-begrænsninger tilsidesættes.

Desuden skal en dokumentanvender overveje en strategi for håndtering af situationer, hvor dokumentkilden er utilgængelig, ikke svarer rettidigt, eller er ukendt. Se \[Indhentning snitflade\] for beskrivelse af, hvordan disse situationer er markeret i svaret.

Videre behandling af fremfundne laboratoriesvarsdokumenter

Den videre behandling af laboratoriesvarsdokumenter forudsættes kendt af dokumentanvender. Se beskrivelsen i \[Svareksponeringsservice snitflade\]. Dog er brug af Privacy Information Header i svaret ikke aktuel, da denne alene benyttes til samtykkekontrol i Dokumentdelingsservicen. Et laboratoriesvarsdokument returneret fra Dokumentdelingsservicen er altså uden Privacy Information Header.