1. Indledning

Denne vejledning beskriver de tekniske forretningsregler i forhold til at implementere Aftaleoversigten i et lokalt fagsystem eller en patient/borgerportal. Vejledningen er tiltænkt forretningsarkitekter, systemarkitekter samt systemleverandører, således at disse kan vurdere hvordan Aftaleoversigten kan implementeres i systemerne.

Aftaleoversigten gør det muligt for aftalesystemer hos sundhedsvæsenets aktører at dele indgåede aftaler med patienten, således at de bliver tilgængelige for de øvrige parter i sundhedsvæsenet samt for den enkelte patient og dennes omsorgspersoner.

På nationalt plan er der udarbejdet en indholdsprofil for et CDA XML dokument (APD-DK 2.0.1), der kan beskrive en aftale med en patient. Indholdsprofilen er forankret hos MedCom.
Disse dokumenter skal, på nationalt plan, opbevares i et “IHE XDS Repository”, og der skal foretages en registrering af dokumentet i det nationale “IHE XDS Registry”, således at aftaledokumenter kan fremfindes på tværs af sundhedsvæsenets aktører.
For aktører i sundhedsvæsenet, der ikke ønsker at etablere et eget “repository”, etableres et statsligt “repository” til opbevaring af aftaledokumenter.

De aktører, der opretter aftaler med patienterne, kan gennem brug af de standardiserede IHE XDS snitflader dele information om oprettede, ændrede og annullerede aftaler med patienter.

I forbindelse med planlægning kan aktørerne få et overblik over patientens andre aftaler ved at hente disse gennem den fælles dokumentdelingsservice. Dokumentdelingsservicen vil udstille standardiserede IHE XDS snitflader til fremfinding og hentning af aftaledokumenter, der i processen vil undergå samtykkekontrol, auditlogning etc.

De standardiserede IHE XDS snitflader kan anvendes til at give patienter det samlede overblik over deres aftaler via sundhed.dk.

1.1. Aktører i løsningen

Som beskrevet ovenfor kan forskellige aktører i sundhedsvæsenet registrere aftaler med  patienten, og de samme aktører kan ligeledes fremsøge og hente information om patientens aftaler. På den måde åbnes der op for at  læger, kommuner og hospitaler kan danne sig et overblik over de aftaler der er lavet med en patient, og patienten får samtidig mulighed for at se sine aftaler på tværs af de forskellige aktører.

Som implementør af løsninger ifht. aftaleoversigten er det derfor også vigtigt at huske at aftaleoversigten alene er et supplement til de traditionelle aftalesystemer hos læger, kommuner, hospitaler og andre aktører i sundhedsvæsenet, der muliggør skabelsen af et overblik over aftaler for patienterne. Det betyder konkret at de aftaler der registreres typisk vil være en kopi af den registrering der allerede findes i det lokale fagsystem.


Hvis man ønsker det, er det muligt at inddrage evt. information registreret af andre i planlægningen af sine egne aftaler. Det kunne f.eks. være en praktiserende læge der ønsker at planlægge tid for en samtale efter en scanning er foretaget på et hospital. Som det ses af aktørbeskrivelsen i figuren ovenfor vil opgaven for implementeringspartnere primært være fokuseret omkring operationerne “Opret”, “Ændre” og “Nedlæg” aftale, således at aftaler med en given patient reflekterer det der findes i det lokale planlægningsystem.

Sundhed.dk vil være en af dokumentanvenderne, der vil kunne vise en samlet aftaleoversigt for en patient ved at bruge “Søg” og “Hent” operationerne. I det omfang andre systemer ønsker at stille et overblik over en patients aftaler til rådighed for brugerne vil disse ligeledes anvende “Søg” og “Hent”.

De følgende afsnit, beskriver hvordan DK-APD 2.0.1 anvendes, samt hvilke forretningsregler lokale fagsystemer og patient/borgerportaler skal implementere for at understøtte Aftaleoversigten

2. Anden dokumentation

De overordnede forretningsregler til Aftaleoversigten kan ses i dokumentet: Indhold og forretningsregler Aftaleoversigt

3. Teknisk oversigt

Udveksling af patientens Aftaleoversigt foregår via den nationale infrastruktur til dokumentdeling. Denne understøtter referencearkitekturen for deling af dokumenter og billeder.

For generel introduktion til den nationale infrastruktur om dokumentdeling, se vejledningen ’Kom godt i gang med dokumentdeling’ til deling af dokumenter via Dokumentdelingsservice på NSP lavet af MedCom.

For detaljeret teknisk dokumentation omkring dokumentdeling via NSP, se NSP'ens Dokumentdelingsservice.

4. Teknisk implementering

Den centrale komponent i Aftaleoversigten er det nationale registry, hvor søgbar metadata information om dokumenter opbevares, herunder aftaledokumenter. Denne komponent implementeres af “Document Registry” i nedenstående figur.

Selve aftaledokumenterne opbevares i et såkaldt repository, der kan tage to forskellige former. Enten er det et “Document Repository”, eller også er det en “On Demand Document Source”, som vist i den logiske model ovenfor.

NSP stiller et nationalt dokument repository til rådighed til opbevaring af dokumenter til Aftaleoversigten. De parter, der implementerer løsninger som en del af Aftaleoversigten, kan vælge imellem at benytte det nationale dokument repository, at implementere deres eget repository, eller implementere en “On Demand Document Source”.
Fælles for disse løsninger er dog at metadata skal registeres i det nationale dokument registry.

4.1. Indhold i Aftaleoversigt

Først og fremmest skal man kende til det indholdsformat der benyttes til aftaledokumenter. Formatet er XML og indholdet er specificeret som en dansk profil af CDA. Den danske profil for CDA Appointment (APD-DK 2.0.1) er forankret hos MedCom der står for den danske profilering. Se under MedCom APD-DK hvor både beskrivelse af standarden samt forskellige aftale eksempler opbevares, bemærk der findes eksempler til alle versioner af APD-DK, eksempler til APD-DK 2.0.1 findes i version 2.0 folderen.
Update 20/10-2020: Der er udgivet en Errata, hvori der er enkelte præciseringer samt rettelser af fejl i forhold til APD-DK 2.0.1, Errata'en kan kan hentes på MedCom's hjemmeside, og er gældende sammen med APD-DK 2.0.1 profilen.

Et CDA dokument består af en header og en body, hvor headeren generelt beskriver en række metadata omkring dokumentets indhold, mens de dokumentspecifikke data placeres i body sektionen.

Indholdet i CDA headeren er fælles for alle danske CDA dokumenter, og er ligeledes forankret hos MedCom, se under MedCom CDA Header v. 1.4.

Systemer der tilsluttes Aftaleoversigten, skal godkendes af MedCom ud fra en certificering. Testprotokollerne for certificering til Aftaleoversigten, hvor version 1.1 er gældende for afsendelse og version 1.0 er gældende for modtagelse, kan findes på MedCom's hjemmeside under: Testprotokoller for modtagelse og afsendelse af Aftaler.
Der er enkelte afvigelser i test-protokollerne for afsendelse og modtagelse af Aftaler, der ikke er defineret under forretningsreglerne. Følgende tabel viser disse afvigelser

Krav ID Krav Afvigelse
Afsendelse krav 4.7 Redegør for hvordan erstatnings CPR håndteres

Der er ingen forretningsregel der definerer at erstatnings CPR skal kunne benyttes.

Der er ikke noget krav til systemet at de skal anvende erstatnings CPR numre til afsendelse af Aftaler
Afsendelse krav 4.24 Aftaler som uploades skal, hvis de er del af et repetitionsmønster, uploades et år frem i tiden

Forretningsregel #3 definerer: at repetitionsmønsteret er gentaget 6 måneder frem, afhængigt af om repetitionerne stadig foregår.

Systemet der skal tilsluttes Aftaleoversigten, skal kunne håndtere et repetitionsmønster på 6 måneder som forretningsregel #3 angiver.
Afsendelse krav 4.27 Opret en ny aftale med angivelse af forløbs-label og forløbs-id

Oprettelse af Aftale med forløbslabel og forløbs-id, er ikke et krav i forhold til forretningsreglerne for Aftaleoversigten. CDA-Profilen (APD-DK 2.0.1) er en profil der giver fagsystemer som har behov for at dele forløbslabel og forløbs-id mulighed for det

Der er ikke noget krav til systemet at kan oprette Aftaler med forløbslabel og forløbs-id på skrivende tidspunkt.
Modtagelse krav 4.2

Vis aftale-indhold (aftale med region) fra testeksempel 1.5, hvor følgende er beskrevet:

Vis aftale forløbs-label og alle forløbs-id som er angivet i testeksemplet.

Vis at det kun er muligt at se forløbs-label i detaljeret visning (hvis dette er muligt).

Vis at det hverken er muligt at se forløbs-id i simpel eller evt. detaljeret visning.

Forløbs-id skal som minimum vises i det hentede CDA dokument

Visning af Aftaler med forløbslabel og forløbs-id, er ikke et krav i forhold til forretningsreglerne for Aftaleoversigten. Fagsystemerne skal dog kunne håndtere modtagelse af Aftaler, hvori forløbslabel og forløbs-id er inkluderet.

Der er ikke noget krav til systemet at kan vise Aftaler med forløbslabel og forløbs-id på skrivende tidspunkt.


Yderligere information om om hvordan CDA dokumenter er opbygget kan findes hos IHE, under: IHE - Hvad er HL7 CDA?

Aftaler i APD-DK 2.0.1 indeholder information, som defineret i nedenstående tabel

Kode

Beskrivelse

Eksempel

ID for aftalen

ClinicalDocument.id

Den unikke identifikation for aftalen
Bemærk: dette er ikke det samme som dokument-id'et der returneres ved at svar på en søgning. dokument-id'et vil ændres hvis en aftale opdateres, det vil Id for aftalen ikke.

<id
 extension="31af7e14-891c-48f0-a414-fd432289bf7d"
 root="1.2.208.184"
 assigningAuthorityName="MedCom"/>

Patienten aftalen omhandler

...recordTarget.patientRole

Patientens Navn og CPR nr.

<patientRole classCode="PAT">

<id extension="2512489996" root="1.2.208.176.1.2" assigningAuthorityName="CPR"/>

<patient classCode="PSN" determinerCode="INSTANCE">

<name>

<given>Nancy</given>

<given>Ann</given>

<family>Berggren</family>

</name>

<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<birthTime value="19481225000000+0000"/>

</patient>

</patientRole>

Ansvarlig for aftalen

ClinicalDocument.author

Den organisation og person der er ansvarlig for aftalen

Der kan tilføjes et ekstra "author" element, efter den aftale ansvarlige, dette vil være rekvirenten for aftalen hvis en sådan er tilgængelig.
Efter "id" men før "addr" skal der tilføjes følgende "code"

<code code="REFB" codeSystem="2.16.840.1.113883.5.90" codeSystemName="ParticipationType (HL7) Code System" displayName="ParticipationReferredBy"/>

Bemærk at "code" er ændret på baggrund af tastefejl, til "REFB" - dette kan ses i Errata_APD-DK-v2.0.1_20_10_2020

<author typeCode="AUT" contextControlCode="OP">

<time value="20190816100000+0100"/>

<assignedAuthor classCode="ASSIGNED">

<id extension="378631000016009" root="1.2.208.176.1.1" assigningAuthorityName="SOR"/>

<addr use="WP">
<streetAddressLine>Sundhedsenhedsforvaltningen</streetAddressLine>
<streetAddressLine>Ørbækvej 100</streetAddressLine>
<postalCode>5220</postalCode>
<city>Odense SØ</city>
</addr>

<assignedPerson classCode="PSN" determinerCode="INSTANCE"><name>
<given>Jens</given>
<family>Jensen</family>
</name>
</assignedPerson>

</assignedAuthor>

</author>

Forvalter for CDA dokumentet, hvori aftalen indgår

ClinicalDocument.custodian

Forvalteren er den myndighed der sørger for opbevaring og udlevering af CDA dokumentet ved relevante forespørgsler. Forvalteren er ligeledes ansvalig for at CDA dokumentet behandles på lovlig og forsvarlig vis, når det er i forvalterens varetægt.

Forvalteren er ikke ansvarlig for det sundhedsspecifikke indhold i CDA dokumentet.

<custodian typeCode="CST">

<assignedCustodian classCode="ASSIGNED">

<representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">

<id extension="378631000016009" root="1.2.208.176.1.1" assigningAuthorityName="SOR"/>

</representedCustodianOrganization>

</assignedCustodian>

</custodian>

Start dato og tidspunkt for aftalen

documentationOf.serviceEvent.
effectiveTime.low

templateId
 root="11.2.208.184.200.1.11"
 extension="2019-09-10"

Start dato og tidspunkt for aftalen

<documentationOf typeCode="DOC">

<serviceEvent classCode="MPROT" moodCode="EVN">

<templateId root="1.2.208.184.200.1.11" extension="2019-09-10"/>

<effectiveTime>

<low value="20191231090000+0100"/>

<high value="20191231120000+0100"/>

</effectiveTime>

</serviceEvent>

</documentationOf>

Slut dato og tidspunkt for aftalen

documentationOf.serviceEvent.
effectiveTime.high

templateId
 root="11.2.208.184.200.1.11"
 extension="2019-09-10"

 Slut dato og tidspunkt for aftalen

<documentationOf typeCode="DOC">

<serviceEvent classCode="MPROT" moodCode="EVN">

<templateId root="1.2.208.184.200.1.11" extension="2019-09-10"/>

<effectiveTime>

<low value="20191231090000+0100"/>

<high value="20191231120000+0100"/>

</effectiveTime>

</serviceEvent>

</documentationOf>

Indikation om tidspunkterne i aftalen er vejledende

<body>.encounter.preCondition

templateId
 root="1.2.208.184.14.11.5"
 extension="2019-09-10"

code
 code="GuidedIntervalType"
 codeSystem="1.2.208.184.100.1"

 Hvis tidspunkterne i aftalen er vejledende vil

<precondition>

<templateId root="1.2.208.184.14.11.5" extension="2019-09-10" />

<criterion>

<code code="GuidedIntervalType" codeSystem="1.2.208.184.100.1"

codeSystemName="MedCom Message Codes"/>

<text>Tidspunktet er vejledende</text>

</criterion>

</precondition>

Status for aftalen

<body>.encounter.statusCode

code="active"

 

Status for aftalen

Bemærk: Status skal altid have værdien "active"

<statusCode code="active" />

Version for aftalen standarden

documentationOf.serviceEvent.id

templateId
 root="1.2.208.184.200.1.10"
 extension="2019-09-10"

Feltet indeholder hvilken version af aftalestandarden dokumentet er baseret på.

Bemærk: Feltet er først indført fra version 2.0, og vil derfor ikke findes i de tidligere versioner af aftalestandarden (1.0 og 1.1)

<documentationOf>

<serviceEvent>

<templateId root="1.2.208.184.200.1.10" extension="2019-09-10"/>

<!--This id @extension equals the identification and version of the CDA profile-->

<id root="1.2.208.184.100.3" extension="apd-v2.0" assigningAuthorityName="MedCom"/>

</serviceEvent>

</documentationOf>
Aftaletypen

<body>.encounter.code

Aftalen kan være af typerne: Regional, Kommunal, Praksis - dette kommer sig til udtryk ud fra følgende værdier

Kommunal: MunicipalityAppointment

Regional: RegionalAppointment

Praksis: PractitionerAppointment

<code

code="MunicipalityAppointment" codeSystem="1.2.208.184.100.1"

codeSystemName="MedCom Message Codes">

</code>

Repetitionsmønster for aftalen

<body>.encounter.preCondition

templateId
 root="1.2.208.184.14.11.4"
 extension="2019-09-10"

code
 code="RepeatingAppointmentType"
 codeSystem="1.2.208.184.100.1"

Viser om aftalen er en del af et repeterende aftalemønster

<precondition>

<templateId root="1.2.208.184.14.11.4" extension="2019-09-10" />

<criterion>

<code code="RepeatingAppointmentType" codeSystem="1.2.208.184.100.1"

codeSystemName="MedCom Message Codes"/>

<value xsi:type="II" root="1.2.208.184" extension="06b2b3bb-dac5-446f-aa19-ed5c46d8b0b7"

assigningAuthorityName="MedCom" />

</criterion>

</precondition>

Udførende for aftalen

<body>.encounter.performer

Den udførende organisation i forhold til aftalen

Bemærk: Den udførende organisation, er ofte også den ansvarlige organisation for aftalen.

<performer typeCode="PRF">

<assignedEntity classCode="ASSIGNED">

<id extension="378631000016009" root="1.2.208.176.1.1" assigningAuthorityName="SOR"/>

<addr use="WP">

<streetAddressLine>Vestergade 5</streetAddressLine>

<postalCode>3000</postalCode>

<city>Odense</city>

</addr>

<telecom value="tel:66113333-3" use="WP"/>

<representedOrganization classCode="ORG" determinerCode="INSTANCE">

<name>Hjemmehjælp, afdeling City, Odense Kommune</name>

</representedOrganization>

</assignedEntity>

</performer>

Lokation for aftalen

encounter.participant

Den lokation hvor aftalen udføres,
Lokationen kan være en af tre forskellige typer:

  1. Lokationen er baseret på Sundhedsvæsnets Organisationsregister (SOR), og defineret som besøgsadresse i SOR.
    typeCode="LOC"
  2. Lokationen er baseret på en adresse udenfor SOR, f.eks den lokale idrætshal, eller den offentlige svømmehal.
    typeCode="DST"
  3. Lokationen er patientens hjemadresse.
    typeCode="SBJ"

For virtuelle aftaler, se nedenfor

Lokation #1

<participant typeCode="LOC">

<participantRole classCode="SDLOC">

<templateId root="1.2.208.184.14.11.3" extension="2019-09-10" />

<id extension="240901000016000" root="1.2.208.176.1.1" assigningAuthorityName="SOR"/>

<addr use=”WP”>
<streetAddressLine>OUH Radiologisk Afdeling (Odense)</streetAddressLine>
<streetAddressLine>Sdr Boulevard 29</streetAddressLine>
<city>Odense</city>
<postalCode>5000</postalCode>
</addr>

<playingEntity classCode="PLC">
<name>Radiologisk Afdeling</name>
</playingEntity>

</participantRole>

</participant>


Lokation #2

<participant typeCode="DST">

<participantRole classCode="SDLOC">

<templateId root="1.2.208.184.14.11.3" extension="2019-09-10" />

<addr use=”WP”>
<streetAddressLine>Radiologisk Afdeling</streetAddressLine>
<streetAddressLine>Kløvervænget 47</streetAddressLine>
<city>Odense</city>
<postalCode>5000</postalCode>
</addr>

<playingEntity classCode="PLC">
<name>Radiologisk Afdeling, indgang A</name>
</playingEntity>

</participantRole>

</participant>


Lokation #3

<participant typeCode="SBJ">

<participantRole classCode="SDLOC">

<templateId root="1.2.208.184.14.11.3" extension="2019-09-10" />

<addr use=”WP”>
<streetAddressLine>Skovvejen 12, Landet</streetAddressLine>
<city>Svendborg</city>
<postalCode>5700</postalCode>
</addr>

<playingEntity classCode="PLC">

<name>Borgers Hjemmeadresse</name>

</playingEntity>

</participantRole>

</participant>

Årsag til aftalen

<body>.encounter.entryRelationship.
observation.code.displayName

 Årsagen til at der er indkaldt til aftalen

<entryRelationship typeCode="RSON">

<observation classCode="OBS" moodCode="EVN">

<code code="NI" displayName="Hjemmehjælp"/>

</observation>

</entryRelationship>

4.1.1. Visning af felterne i Aftaleoversigten

Nedenstående tabel viser hvilke elementer i en aftale der skal vises til slutbrugerne af Aftaleoversigten i de forskellige visninger.

Simpel visning: Er eksempelvis en kalender- eller listevisning

Detaljeret visning: Er hvis alle detaljer om aftalen skal kunne ses.

Nr.

Dataelement

Beskrivelse

Påkrævet

Vises for slutbruger i simpel visning

Vises for slutbruger i detaljeret visning (optionel)

1

Appointment unique id

Entydigt id for Aftalen

Nej

Nej

Nej

2

Document unique id

Entydigt id for CDA dokumentet

Ja

Nej

Nej

3

Patient

Entydig identifikation af patienten

Ja

Ja

Ja

4

Appointment responsible, ”placer”

Den organisation som er ansvarlig for Aftalen

Ja

Nej

Ja

5

Appointment requester, ”filler”

Den organisation som har bestilt Aftalen, rekvirent, henviser

Nej

Nej

Ja

6

Appointment custodian, Steward

Den organisation som har ansvaret for CDA dokumentet

Ja

Nej

Ja

7

Start date and time

Tidspunkt for start af Aftalen

Ja

Ja

Ja

8

End date and time

Tidspunkt for slut af Aftalen

Dette tidspunkt er optionelt, men er det til stede skal det vises for slutbrugeren.

Nej

Ja

Ja

9

EpisodeOfCare label 

Information ang. overordnet patientforløb (forløbs-label)

Nej

Nej

Ja

10

EpisodeOfCare id

Information ang. deltaljeret patientforløb (forløbs-id)

Nej

Nej

Ja

11

APD-DK version

APD-DK version af CDA dokumentet

Ja

Nej

Nej

12

Organization that plans to perform the appointment. ”performer”

Den ansvarlige organisation for gennemførelse af Aftalen

Ja

Ja

Ja

13

The location of the appointment

Mødested for Aftalen.

Ja

Ja

Ja

14

Information if the appointment time is guiding

Visning hvis aftale tidspunktet er vejledende

Nej

Ja

Ja

15

The Reason for the appointment

Årsag til Aftalen

Ja

Ja

Ja

16

The Appointment Status

Status for Aftalen (kun status aktiv er mulig)

Ja

Nej

Nej

17

The appointment is repetitive

Angivelse af at aftalen er del at et gentagene mønster

Nej

Ja

Ja

18

The appoitment type

Aftale er regional, praksis, kommunal

Ja

Nej

Nej

4.1.2. Virtuelle aftaler

En virtuel aftale, er defineret som en Aftale med sundhedsvæsnet, hvor den sundhedsfaglige kommunikerer med patienten via live video konference og eller chat. Alle aspekter af Aftalen, er som hvis patienten og den sundhedsfaglige sad overfor hinanden.
Der er mulighed for at vise både patienten og sundhedsfaglige fra parterne at der ligger en virtuel aftale med patienten, dette kan gøres ved at indkalde til en Aftale, hvor mødestedet er patientens hjem-adresse, og så beskrive i brødtekst at det er en virtuel aftale.

 — Alle henvisninger til afsnit nedenstående er til CDA-standarden for Aftaler (DK-APD 2.0.1) —

Hvis Aftalen er placeret på patientens hjem-adresse, sættes participant@typecode til “SBJ” som beskrevet i afsnit 5.3.1

I playingEntity->name afsnit 5.3.3 tabel 14 sættes en beskrivende tekst om mødestedet, hvilket kunne være “Virtuel Aftale” eller anden beskrivende tekst således patienten og sundhedsfaglige kan se der ikke skal mødes op personligt.

Der er ikke mulighed for at give en reference/link til den virtuelle aftale, det skal foregå via de kanaler der foregår i i dag. 

Eksempler på mødested for virtuelle aftaler:

1 - Hvor borgerens hjem-adresse (og telefonnummer) er kendt:

<participant typeCode="SBJ"> 
<participantRole classCode="SDLOC">
<templateId root="1.2.208.184.14.11.3" extension="2019-09-10" />
<addr use="H"> 
    <streetAddressLine>Hindbærvej 23</streetAddressLine>
    <streetAddressLine>Hjallese</streetAddressLine>
    <city>Odense S</city>
    <postalCode>5260</postalCode> 
  </addr>
  <telecom value="tel:35986256" use="H"/> 
  <playingEntity classCode="PLC">
    <name>Virtuel aftale</name> 
  </playingEntity>
 </participantRole> 
</participant> 

2 -Hvor borgerens hjem-adresse (og telefonnummer) ikke er kendt:

<participant typeCode="SBJ"> 
  <participantRole classCode="SDLOC"> 
  <templateId root="1.2.208.184.14.11.3" extension="2019-09-10" />
  <addr nullFlavor="NI" />
  <telecom nullFlavor="NI"/>
  <playingEntity classCode="PLC">
    <name>Virtuel aftale</name> 
  </playingEntity>
 </participantRole> 
</participant>  

Parterne er på forskellige stadier med hensyn til udrulning af deres aftaleløsninger, det er derfor ikke et krav at virtuelle aftaler skal understøttes, men det skal ses som en mulighed, således at patienten får så komplet en Aftaleoversigt som muligt.

Ved at understøtte virtuelle aftaler som foreslået ovenfor, vil det ikke have indvirkning for de parter der allerede har udrullet deres aftaleløsninger, da Aftaler med adresse på patientens hjem-adresse er en del af den gældende standard.

4.2. Tekniske forudsætninger

Se Administrative forudsætninger for at få adgang til NSP'en.

Aftaleoversigten udstilles via services på NSP'en, disse skal tilgås gennem en afkoblingskomponent "DCC'en" DCC'en viderestiller kald til underliggende services, så der er ikke en WSDL for DCC'en. Se DCC Dokumentation for adgang til services gennem DCC'en.

NSP services kan tilgås enten via Den Gode Webservice (DGWS) eller via OIO-IDWS (Udelukkende borger adgang).
Den Gode WebService (DGWS) benytter XMLDSIG til at signere SAML assertions ud fra X.509 certifikater/nøgler - for adgang til Aftaleoversigten skal sundhedspersoner have et gyldigt Nem-ID Medarbejdercertifikat (MOCES), hvilket også er beskrevet under administrative forudsætninger, således at patienten har mulighed for at frabede sig, at aftaler kan deles med specifikke sundhedspersoner, samt at patienten har mulighed for at se hvem der har haft adgang til patientens Aftaleoversigt via Min-log.
For mere information om den gode webservice, se: https://www.medcom.dk/standarder/webservice-standarder/den-gode-webservice

Til at understøtte SAML har Sundhedsdatastyrelsen udviklet biblioteker til Java og .NET (SEAL biblioteket) Dette bør benyttes så vidt det er muligt, se STS Dokumentation

De servicesnitflader der udstilles til Aftaleoversigten er alle baseret på SOAP kald der opfylder DGWS.
Der arbejdes på at indføre en model baseret på IDWS kompatibel med XUA, som anvendes af de standard produkter der implementerer IHE XDS.

Indholdsdelen af den enkelte servicekald (SOAP body) er den del der er specificeret af IHE XDS snitfladerne, dvs. for eksempel ITI-18 og ITI-43.

De detaljerede beskrivelser af snitfladerne findes i IHE IT Infrastructure Technical Framework dokumenterne volume 1, 2a, 2b, 2x og 3.

Beskrivelserne i de officielle dokumenter fra IHE er relativt komplicerede, og det kan være svært at opnå et godt overblik over hvordan specifikke kald sættes sammen. Der findes en række generelle og praktiske eksempler og programmer på IPF Open eHealth Integration Platform siderne. Se for eksempel:

4.3. Søgning på Aftaler

For at søge på en patients Aftaleoversigt, skal der laves en ITI-18 forespørgsel via NSP'ens dokumentdelingsservice.

WSDL til DDS Registry findes her: https://wsdl.nspop.dk/ddsregistry?wsdl

Når der søges på Aftaleoversigten, kan der søges på de værdier der er angivet i dokument metadata. Aftaleoversigten benytter MedCom's metadata profil version 0.96, der kan hentes på https://svn.medcom.dk/svn/releases/Standarder/IHE/DK_profil_metadata/

Typisk angives patientens CPR nummer, samt en typecode - for APD er typecode 39289-4, bemærk at aftaledokumenter både udstilles som statiske dokumenter, og on-demand dokumenter hvorfor DocumentEntryType for begge typer skal angives. Se følgende eksempel.

En søgning efter en patients aftale dokumenter baserer sig typisk på et tidsinterval. For Aftaler er det parametrene ServiceStartTime og ServiceStopTime, der angiver hvornår en aftale begynder og slutter.
For parametre med tidsangivelser gælder følgende søgeregel, således alle tidspunkter der angives inden for dette interval inkluderet. (eksempel med ServiceStartTime):

$XDSDocumentEntryServiceStartTimeFrom <= XDSDocumentEntry.serviceStartTime < $XDSDocumentEntryServiceStartTimeTo

Der er specielle regler for søgninger, hvor ServiceStopTime ikke er angivet. Konkret betyder det følgende:
Hvis DocumentEntry.serviceStopTime ikke er angivet, og hvis søge paramtrerne inkluderer en værdi for enten $XDSDocumentEntryServiceStopTimeFrom eller $XDSDocumentEntryServiceStopTimeTo. Så vil disse parametre ikke blive benyttet for udsøgning af det konkrete dokument.

For henholdsvis AND og OR søgninger gælder det at angives der flere søgeværdier i samme <slot> så tæller det som en OR søgning for disse værdier. Hvor der mellem de forskellige <slot> tæller som en AND søgning.

De detaljerede tekniske informationer om ITI-18 og angivelse af søgeparametre, kan ses i IHE ITI dokumentation volume 2

Specifikt for Aftaler der løber over flere dage, gælder det at søgningen skal inkludere de tidspunkter Aftalen har angivet. Hvis ServiceStartTime angives til 1/1-2021 og ServiceStopTime angives til 3/1-2021 vil det ikke returnere en aftale der har sat ServiceStartTime til 31/12-2020, og ServiceStopTime til 2/1-2021, da ServiceStartTime og ServiceStopTime er angivet i hvert deres <slot> og det derfor er en AND søgning mellem parametrene. I dette tilfælde skal anvendersystemerne stå for filtreringen selv hvis denne funktionalitet ønskes (evt. med flere søgninger, eller udvide angivelserne for søgetidsrum).

Specifikt for Aftaler hvor sluttidspunktet ikke er defineret, kan det ikke afgøres om Aftalen løber over flere dage. Der vil søgningen gælde som om ServiceStopTime ikke er angivet (som specificeret ovenfor)

ITI-18 AdhocQueryRequest 
		<AdhocQueryRequest xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0">
			<ResponseOption returnType="LeafClass" returnComposedObjects="true"/>
			<AdhocQuery xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d">
				<Slot name="$XDSDocumentEntryPatientId">
					<ValueList>
						<Value>'2512489996^^^&1.2.208.176.1.2&ISO'</Value>
					</ValueList>
				</Slot>
				<Slot name="$XDSDocumentEntryStatus">
					<ValueList>
						<Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')</Value>
					</ValueList>
				</Slot>
				<Slot name="$XDSDocumentEntryTypeCode">
					<ValueList>
						<Value>('39289-4^^2.16.840.1.113883.6.1')</Value>
					</ValueList>
				</Slot>
				<Slot name="$XDSDocumentEntryServiceStartTimeFrom">
					<ValueList>
						<Value>20171231000000</Value>
					</ValueList>
				</Slot>
				<Slot name="$XDSDocumentEntryServiceStopTimeTo">
					<ValueList>
						<Value>20181231000000</Value>
					</ValueList>
				</Slot>
				<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>

Svaret indeholder referencerne til Aftale dokumenterne, der skal benyttes efterfølgende til at udtrække Aftaleoversigten

ITI-18 AdhocQueryResponse 
<ns3:AdhocQueryResponse totalResultCount="20" status="urn:ihe:iti:2007:ResponseStatusType:PartialSuccess" xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns7="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns8="http://www.w3.org/2000/09/xmldsig#" xmlns:ns9="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns10="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns11="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd">
         <ns2:RegistryErrorList highestSeverity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error">
            <ns2:RegistryError codeContext="[Document Unique Id: null, Home Community Id: null, Repository Unique Id: null]" errorCode="dk.nsi.dds.projects.ao.documentmetadataprovider.exceptions.InvokerCallException: dk.nsi.dds.projects.ao.documentmetadataprovider.exceptions.InvokerCallException: Bookplan server returned error: Forbidden" severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/>
         </ns2:RegistryErrorList>
         <RegistryObjectList>
            <ExtrinsicObject mimeType="text/xml" lid="urn:uuid:f39c1380-4d8f-4e27-9376-398b39791067" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:f39c1380-4d8f-4e27-9376-398b39791067">
               <Slot name="creationTime">
                  <ValueList>
                     <Value>20180607</Value>
                  </ValueList>
               </Slot>
               <Slot name="hash">
                  <ValueList>
                     <Value>da39a3ee5e6b4b0d3255bfef95601890afd80709</Value>
                  </ValueList>
               </Slot>
               <Slot name="languageCode">
                  <ValueList>
                     <Value>da-DK</Value>
                  </ValueList>
               </Slot>
               <Slot name="serviceStartTime">
                  <ValueList>
                     <Value>2018083110</Value>
                  </ValueList>
               </Slot>
               <Slot name="serviceStopTime">
                  <ValueList>
                     <Value>2018083111</Value>
                  </ValueList>
               </Slot>
               <Slot name="repositoryUniqueId">
                  <ValueList>
                     <Value>1.2.208.176.43210.8.20.11</Value>
                  </ValueList>
               </Slot>
               <Slot name="size">
                  <ValueList>
                     <Value>8689</Value>
                  </ValueList>
               </Slot>
               <Slot name="sourcePatientId">
                  <ValueList>
                     <Value>2512489996^^^&1.2.208.176.1.2&ISO</Value>
                  </ValueList>
               </Slot>
               <VersionInfo versionName="1"/>
               <Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="urn:uuid:f39c1380-4d8f-4e27-9376-398b39791067" nodeRepresentation="" id="urn:uuid:1c3664df-c061-4f0b-b3ac-5a2a39f09f1a">
                  <Slot name="authorInstitution">
                     <ValueList>
                        <Value>OUH Radiologisk Afdeling (Svendborg)^^^^^&1.2.208.176.1.1&ISO^^^^242621000016001</Value>
                     </ValueList>
                  </Slot>
               </Classification>
               <Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="urn:uuid:f39c1380-4d8f-4e27-9376-398b39791067" nodeRepresentation="001" id="urn:uuid:b6079de8-8a21-4878-9a8d-f2ad9bf9a868">
                  <Slot name="codingScheme">
                     <ValueList>
                        <Value>1.2.208.184.100.9</Value>
                     </ValueList>
                  </Slot>
                  <Name>
                     <LocalizedString xml:lang="en-US" charset="UTF-8" value="Klinisk rapport"/>
                  </Name>
               </Classification>
               <Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="urn:uuid:f39c1380-4d8f-4e27-9376-398b39791067" nodeRepresentation="urn:ad:dk:medcom:appointment" id="urn:uuid:c9783e44-fa81-442b-a710-7a2598081167">
                  <Slot name="codingScheme">
                     <ValueList>
                        <Value>1.2.208.184.14.1</Value>
                     </ValueList>
                  </Slot>
                  <Name>
                     <LocalizedString xml:lang="en-US" charset="UTF-8" value="DK CDA APD"/>
                  </Name>
               </Classification>
               <Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="urn:uuid:f39c1380-4d8f-4e27-9376-398b39791067" nodeRepresentation="22232009" id="urn:uuid:552eae07-cc8c-4afa-a93e-306b0349cda5">
                  <Slot name="codingScheme">
                     <ValueList>
                        <Value>2.16.840.1.113883.6.96</Value>
                     </ValueList>
                  </Slot>
                  <Name>
                     <LocalizedString xml:lang="en-US" charset="UTF-8" value="hospital"/>
                  </Name>
               </Classification>
               <Classification classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="urn:uuid:f39c1380-4d8f-4e27-9376-398b39791067" nodeRepresentation="408443003" id="urn:uuid:fe772f97-377b-43a5-9478-de63e82ed911">
                  <Slot name="codingScheme">
                     <ValueList>
                        <Value>2.16.840.1.113883.6.96</Value>
                     </ValueList>
                  </Slot>
                  <Name>
                     <LocalizedString xml:lang="en-US" charset="UTF-8" value="almen medicin"/>
                  </Name>
               </Classification>
               <Classification classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="urn:uuid:f39c1380-4d8f-4e27-9376-398b39791067" nodeRepresentation="39289-4" id="urn:uuid:033e3218-1987-4570-a2a7-5f8e297422b9">
                  <Slot name="codingScheme">
                     <ValueList>
                        <Value>2.16.840.1.113883.6.1</Value>
                     </ValueList>
                  </Slot>
                  <Name>
                     <LocalizedString xml:lang="en-US" charset="UTF-8" value="Dato og tidspunkt for møde mellem patient og sundhedsperson"/>
                  </Name>
               </Classification>
               <Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="urn:uuid:f39c1380-4d8f-4e27-9376-398b39791067" nodeRepresentation="N" id="urn:uuid:7505668a-de96-4df0-9c1d-8cf847f8d87c">
                  <Slot name="codingScheme">
                     <ValueList>
                        <Value>2.16.840.1.113883.5.25</Value>
                     </ValueList>
                  </Slot>
                  <Name>
                     <LocalizedString xml:lang="en-US" charset="UTF-8" value="Normal"/>
                  </Name>
               </Classification>
               <ExternalIdentifier registryObject="urn:uuid:f39c1380-4d8f-4e27-9376-398b39791067" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="2512489996^^^&1.2.208.176.1.2&ISO" id="urn:uuid:43a5db59-bf47-4fe9-ad87-5bcd38f4c5cd">
                  <Name>
                     <LocalizedString value="XDSDocumentEntry.patientId"/>
                  </Name>
               </ExternalIdentifier>
               <ExternalIdentifier registryObject="urn:uuid:f39c1380-4d8f-4e27-9376-398b39791067" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="8353399289394569667.5264237518200418635.1528403737836" id="urn:uuid:fe083081-c2b1-4e4c-b550-4d852a60c18f">
                  <Name>
                     <LocalizedString value="XDSDocumentEntry.uniqueId"/>
                  </Name>
               </ExternalIdentifier>
            </ExtrinsicObject>
            <ExtrinsicObject mimeType="text/xml" lid="urn:uuid:72c193ba-5d30-4ebe-b325-5058cc314b6c" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:72c193ba-5d30-4ebe-b325-5058cc314b6c">
               <Slot name="creationTime">
                  <ValueList>
                     <Value>20180608</Value>
                  </ValueList>
               </Slot>
               <Slot name="hash">
                  <ValueList>
                     <Value>da39a3ee5e6b4b0d3255bfef95601890afd80709</Value>
                  </ValueList>
               </Slot>
               <Slot name="languageCode">
                  <ValueList>
                     <Value>da-DK</Value>
                  </ValueList>
               </Slot>
               <Slot name="serviceStartTime">
                  <ValueList>
                     <Value>2018083110</Value>
                  </ValueList>
               </Slot>
               <Slot name="serviceStopTime">
                  <ValueList>
                     <Value>2018083111</Value>
                  </ValueList>
               </Slot>
               <Slot name="repositoryUniqueId">
                  <ValueList>
                     <Value>1.2.208.176.43210.8.20.11</Value>
                  </ValueList>
               </Slot>
               <Slot name="size">
                  <ValueList>
                     <Value>8689</Value>
                  </ValueList>
               </Slot>
               <Slot name="sourcePatientId">
                  <ValueList>
                     <Value>2512489996^^^&1.2.208.176.1.2&ISO</Value>
                  </ValueList>
               </Slot>
               <VersionInfo versionName="1"/>
               <Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="urn:uuid:72c193ba-5d30-4ebe-b325-5058cc314b6c" nodeRepresentation="" id="urn:uuid:4ea2ae71-9249-4796-b8ef-a3285f82a0a1">
                  <Slot name="authorInstitution">
                     <ValueList>
                        <Value>OUH Radiologisk Afdeling (Svendborg)^^^^^&1.2.208.176.1.1&ISO^^^^242621000016001</Value>
                     </ValueList>
                  </Slot>
               </Classification>
               <Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="urn:uuid:72c193ba-5d30-4ebe-b325-5058cc314b6c" nodeRepresentation="001" id="urn:uuid:b2b8499e-f7f2-41df-98e1-27f0d2f4d73b">
                  <Slot name="codingScheme">
                     <ValueList>
                        <Value>1.2.208.184.100.9</Value>
                     </ValueList>
                  </Slot>
                  <Name>
                     <LocalizedString xml:lang="en-US" charset="UTF-8" value="Klinisk rapport"/>
                  </Name>
               </Classification>
               <Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="urn:uuid:72c193ba-5d30-4ebe-b325-5058cc314b6c" nodeRepresentation="urn:ad:dk:medcom:appointment" id="urn:uuid:8a3337dd-8219-4dd4-b5a2-e86166940b70">
                  <Slot name="codingScheme">
                     <ValueList>
                        <Value>1.2.208.184.14.1</Value>
                     </ValueList>
                  </Slot>
                  <Name>
                     <LocalizedString xml:lang="en-US" charset="UTF-8" value="DK CDA APD"/>
                  </Name>
               </Classification>
               <Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="urn:uuid:72c193ba-5d30-4ebe-b325-5058cc314b6c" nodeRepresentation="22232009" id="urn:uuid:a0e57848-74a4-452e-a46b-a09705d62735">
                  <Slot name="codingScheme">
                     <ValueList>
                        <Value>2.16.840.1.113883.6.96</Value>
                     </ValueList>
                  </Slot>
                  <Name>
                     <LocalizedString xml:lang="en-US" charset="UTF-8" value="hospital"/>
                  </Name>
               </Classification>
               <Classification classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="urn:uuid:72c193ba-5d30-4ebe-b325-5058cc314b6c" nodeRepresentation="408443003" id="urn:uuid:787e7195-f375-4c15-b583-88a4c0f9d03e">
                  <Slot name="codingScheme">
                     <ValueList>
                        <Value>2.16.840.1.113883.6.96</Value>
                     </ValueList>
                  </Slot>
                  <Name>
                     <LocalizedString xml:lang="en-US" charset="UTF-8" value="almen medicin"/>
                  </Name>
               </Classification>
               <Classification classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="urn:uuid:72c193ba-5d30-4ebe-b325-5058cc314b6c" nodeRepresentation="39289-4" id="urn:uuid:374a1168-4783-46c8-a021-e77758185869">
                  <Slot name="codingScheme">
                     <ValueList>
                        <Value>2.16.840.1.113883.6.1</Value>
                     </ValueList>
                  </Slot>
                  <Name>
                     <LocalizedString xml:lang="en-US" charset="UTF-8" value="Dato og tidspunkt for møde mellem patient og sundhedsperson"/>
                  </Name>
               </Classification>
               <Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="urn:uuid:72c193ba-5d30-4ebe-b325-5058cc314b6c" nodeRepresentation="N" id="urn:uuid:e5d4507a-0b78-42e7-a7e0-93a6cf163f8d">
                  <Slot name="codingScheme">
                     <ValueList>
                        <Value>2.16.840.1.113883.5.25</Value>
                     </ValueList>
                  </Slot>
                  <Name>
                     <LocalizedString xml:lang="en-US" charset="UTF-8" value="Normal"/>
                  </Name>
               </Classification>
               <ExternalIdentifier registryObject="urn:uuid:72c193ba-5d30-4ebe-b325-5058cc314b6c" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="2512489996^^^&1.2.208.176.1.2&ISO" id="urn:uuid:6e9a8799-949e-46ce-99c4-bb392da42ef2">
                  <Name>
                     <LocalizedString value="XDSDocumentEntry.patientId"/>
                  </Name>
               </ExternalIdentifier>
               <ExternalIdentifier registryObject="urn:uuid:72c193ba-5d30-4ebe-b325-5058cc314b6c" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="4626988570895596169.1706949989627285041.1528441530671" id="urn:uuid:86d5cf9d-e459-402e-9a0a-8326d581c425">
                  <Name>
                     <LocalizedString value="XDSDocumentEntry.uniqueId"/>
                  </Name>
               </ExternalIdentifier>
            </ExtrinsicObject>
         </RegistryObjectList>
      </ns3:AdhocQueryResponse>

Der er tre værdier der skal benyttes:

  1. HomeCommunityId - der beskriver det domæne dokumentet befinder sig i.

    Værdien hentes ud fra ...ExtrinsicObject/@home

  2. RepositoryUniqueId - der bekriver den kilde under domænet der opbevarer dokumentet
    Værdien hentes ud fra ...ExtrinsicObject/Slot[@name=’repositoryUniqueId’]/Value List/Value
  3. DocumentUniqueId - der identificerer selve dokumentet
    Værdien hentes ud fra ...ExtrinsicObject/ExternalIdentifier[@identificationScheme=’urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab]/@value

Yderligere information omkring forespørgsler via dokumentdeling kan ses i Brugervejledning til forespørgsler via DDS

4.4. Hentning af Aftaler

For at hente en patients Aftaleoversigt, skal der laves en ITI-43 forespørgsel via NSP'ens dokumentdelingsservice.

Som beskrevet ovenfor benyttes de tre værdier: HomeCommunityId, RepositoryUniqueId og DocumentUniqueId til at hente dokumenterne.

WSDL til DDS Repository findes her: https://wsdl.nspop.dk/ddsrepository?wsdl

ITI-43 RetrieveDocumentSetRequest 
        <RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007">
            <DocumentRequest>
                <HomeCommunityId>urn:oid:1.2.208.176.43210.8.20.11</HomeCommunityId>
                <RepositoryUniqueId>1.2.208.176.43210.8.20.11</RepositoryUniqueId>
                <DocumentUniqueId>6946778998876148702.7192223840203720416.1528441845022</DocumentUniqueId>
            </DocumentRequest>
        </RetrieveDocumentSetRequest>


Det svar der returneres er patientens Aftaleoversigt, indeholdende de dataelementer der er beskrevet under indhold.

Bemærk at selve body delen af aftalen skal hentes ud som en mime attachement

ITI-43 RetrieveDocumentSetResponse 
<RetrieveDocumentSetResponse xmlns="urn:ihe:iti:xds-b:2007" xmlns:ns2="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns3="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns4="http://www.w3.org/2000/09/xmldsig#" xmlns:ns5="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns6="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns7="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns8="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns9="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns10="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns11="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns12="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"><ns9:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/><DocumentResponse><HomeCommunityId>urn:oid:1.2.208.176.43210.8.20.11</HomeCommunityId><RepositoryUniqueId>1.2.208.176.43210.8.20.11</RepositoryUniqueId><DocumentUniqueId>6946778998876148702.7192223840203720416.1528441845022</DocumentUniqueId><mimeType>text/xml</mimeType><Document><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:8110ae30-37ff-4306-9c98-0ec153181a9f-68078@urn%3Aihe%3Aiti%3Axds-b%3A2007"/></Document></DocumentResponse></RetrieveDocumentSetResponse></soap:Body></soap:Envelope>
--uuid:52a6c54a-20db-4aba-bf36-2ac132997b00
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-ID: <8110ae30-37ff-4306-9c98-0ec153181a9f-68078@urn:ihe:iti:xds-b:2007>

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<ClinicalDocument
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:hl7-org:v3 ../../PHMR/Schema/CDA_SDTC.xsd"
	xmlns="urn:hl7-org:v3" classCode="DOCCLIN" moodCode="EVN">
	<realmCode code="DK" />
	<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040" />
	<!-- MedCom DK CDA APD profile OID -->
	<templateId root="1.2.208.184.14.1" />
	<id extension="aa2386d0-79ea-11e3-981f-0800200c9a66"
		root="1.2.208.184" assigningAuthorityName="MedCom" />
	<!-- LOINC code for appointment date -->
	<code code="39289-4" codeSystem="2.16.840.1.113883.6.1"
		codeSystemName="LOINC"
		displayName="Dato og tidspunkt for møde mellem patient og sundhedsperson" />
	<!-- title = "Aftale for" + patient id -->
	<title>Aftale for 2512489996</title>
	<effectiveTime value="20170113100000+0100" />
	<confidentialityCode code="N"
		codeSystem="2.16.840.1.113883.5.25" />
	<languageCode code="da-DK" />

	<!-- information about the patient -->
	<recordTarget typeCode="RCT" contextControlCode="OP">
		<patientRole classCode="PAT">
			<id extension="2512489996" root="1.2.208.176.1.2"
				assigningAuthorityName="CPR" />
			<addr use="H">
				<streetAddressLine>Skovvejen 12</streetAddressLine>
				<streetAddressLine>Landet</streetAddressLine>
				<postalCode>5700</postalCode>
				<city>Svendborg</city>
				<country>Danmark</country>
			</addr>
			<telecom value="tel:65123456" use="H" />
			<telecom value="mailto:nab@udkantsdanmark.dk" use="WP" />
			<patient classCode="PSN" determinerCode="INSTANCE">
				<name>
					<given>Nancy</given>
					<given>Ann</given>
					<family>Berggren</family>
				</name>
				<administrativeGenderCode code="F"
					codeSystem="2.16.840.1.113883.5.1" />
				<birthTime value="19481225000000+0000" />
			</patient>
		</patientRole>
	</recordTarget>

	<!-- the health care organisation and person responsible for the appointment -->
	<author typeCode="AUT" contextControlCode="OP">
		<time value="20170216100000+0100" />
		<assignedAuthor classCode="ASSIGNED">
			<id extension="242621000016001" root="1.2.208.176.1.1"
				assigningAuthorityName="SOR" />
			<addr use="WP">
				<streetAddressLine>Valdemarsgade 53</streetAddressLine>
				<postalCode>5700</postalCode>
				<city>Svendborg</city>
				<country>Danmark</country>
			</addr>
			<telecom value="tel:65113333-1" use="WP" />
			<assignedPerson classCode="PSN"
				determinerCode="INSTANCE">
				<name>
					<prefix>Læge</prefix>
					<given>Jens</given>
					<family>Jensen</family>
				</name>
			</assignedPerson>
			<representedOrganization classCode="ORG"
				determinerCode="INSTANCE">
				<name>OUH Radiologisk Afdeling (Svendborg)</name>
				<telecom nullFlavor="NI" />
				<addr use="WP">
					<streetAddressLine nullFlavor="NI" />
				</addr>
			</representedOrganization>
		</assignedAuthor>
	</author>

	<!-- the organisation responsible for maintaing the CDA document -->
	<custodian typeCode="CST">
		<assignedCustodian classCode="ASSIGNED">
			<representedCustodianOrganization
				classCode="ORG" determinerCode="INSTANCE">
				<id extension="515361000016007" root="1.2.208.176.1.1"
					assigningAuthorityName="SOR" />
				<name>OUH Klinisk IT (Odense)</name>
				<telecom value="tel:66113333-2" use="WP" />
				<addr use="WP">
					<streetAddressLine>J. B. Winsløwsvej 4 1</streetAddressLine>
					<postalCode>5000</postalCode>
					<city>Odense C</city>
					<country>Danmark</country>
				</addr>
			</representedCustodianOrganization>
		</assignedCustodian>
	</custodian>

	<!-- the date and time for when the service event will take place -->
	<documentationOf typeCode="DOC">
		<serviceEvent classCode="MPROT" moodCode="EVN">
			<effectiveTime>
				<low value="20180831110000+0100" />
				<high value="20180831120000+0100" />
			</effectiveTime>
		</serviceEvent>
	</documentationOf>

	<!-- CDA Body -->
	<component typeCode="COMP" contextConductionInd="true">
		<structuredBody classCode="DOCBODY" moodCode="EVN">

			<component typeCode="COMP" contextConductionInd="true">

				<section classCode="DOCSECT" moodCode="EVN">
					<!-- DK APD Plan of treatment section template -->
					<templateId root="1.2.208.184.14.11.1"
						extension="2017-03-10" />
					<code code="18776-5" codeSystem="2.16.840.1.113883.6.1"
						codeSystemName="LOINC" displayName="Plan of care note" />
					<title>Aftale</title>
					<text>Aftale-tekst-her</text>

					<entry>
						<encounter moodCode="APT" classCode="ENC">
							<!-- DK APD Planned Encounter template -->
							<templateId root="1.2.208.184.14.11.2"
								extension="2017-03-10" />

							<id root="1.2.208.184"
								extension="9a6d1bac-17d3-4195-89a4-1121bc809b4d"
								assigningAuthorityName="MedCom" />
							<code code="185353001" displayName="Aftale dato"
								codeSystemName="SNOMED CT" codeSystem="2.16.840.1.113883.6.96">
							</code>
							<statusCode code="active" />

							<!-- time period for the planned health care service -->
							<effectiveTime>
								<low value="20170531110000+0100" />
								<high value="20170531120000+0100" />
							</effectiveTime>

							<!-- responsible organisation/person for the health care service -->
							<performer typeCode="PRF">
								<assignedEntity classCode="ASSIGNED">
									<id extension="320161000016005" root="1.2.208.176.1.1"
										assigningAuthorityName="SOR" />
									<addr use="WP">
										<streetAddressLine>Valdemarsgade 53</streetAddressLine>
										<postalCode>5700</postalCode>
										<city>Svendborg</city>
										<country>Danmark</country>
									</addr>
									<telecom value="tel:66113333-3" use="WP" />
									<assignedPerson classCode="PSN"
										determinerCode="INSTANCE">
										<name>
											<prefix>Læge</prefix>
											<given>Anders</given>
											<family>Andersen</family>
										</name>
									</assignedPerson>
									<representedOrganization
										classCode="ORG" determinerCode="INSTANCE">
										<name>OUH Radiologisk Ambulatorium (Nyborg)</name>
										<telecom nullFlavor="NI" />
										<addr use="WP">
											<streetAddressLine nullFlavor="NI" />
										</addr>
									</representedOrganization>
								</assignedEntity>
							</performer>

							<!-- organisation/person who are requesting the appointment (placer) -->
							<author typeCode="AUT" contextControlCode="OP">
								<time value="20170216100000+0100" />
								<assignedAuthor classCode="ASSIGNED">
									<id extension="48681000016007" root="1.2.208.176.1.1"
										assigningAuthorityName="SOR" />
									<addr use="WP">
										<streetAddressLine>Toldbodvej 9</streetAddressLine>
										<postalCode>5700</postalCode>
										<city>Svendborg</city>
										<country>Danmark</country>
									</addr>
									<telecom value="tel:62214518" use="WP" />
									<assignedPerson classCode="PSN"
										determinerCode="INSTANCE">
										<name>
											<given>Anders</given>
											<family>Andersen</family>
										</name>
									</assignedPerson>
									<representedOrganization
										classCode="ORG" determinerCode="INSTANCE">
										<name>Lægerne Toldbodvej</name>
										<telecom nullFlavor="NI" />
										<addr use="WP">
											<streetAddressLine nullFlavor="NI" />
										</addr>
									</representedOrganization>
								</assignedAuthor>
							</author>

							<!-- location for the planned health care service -->
							<participant typeCode="LOC">
								<participantRole classCode="SDLOC">
									<!-- DK Service Delivery Location template -->
									<templateId root="1.2.208.184.14.11.3"
										extension="2017-03-10" />
									<id extension="320161000016005" root="1.2.208.176.1.1"
										assigningAuthorityName="SOR" />
									<addr use="WP">
										<streetAddressLine>Vestergade 17</streetAddressLine>
										<postalCode>5800</postalCode>
										<city>Nyborg</city>
										<country>Danmark</country>
									</addr>
									<telecom value="tel:66113333-4" use="WP" />
									<playingEntity classCode="PLC">
										<name>OUH Radiologisk Ambulatorium (Nyborg)</name>
									</playingEntity>
								</participantRole>
							</participant>

							<!-- reason for the planned health care service -->
							<entryRelationship typeCode="RSON">
								<observation classCode="OBS" moodCode="RQO">
									<code code="NI"
										displayName="Ekkokardiografi (Ultralydsundersøgelse af hjertet)" />
								</observation>
							</entryRelationship>
						</encounter>
					</entry>

				</section>

			</component>

		</structuredBody>
	</component>
</ClinicalDocument>


4.5. Oprettelse af Aftaler

Oprettelse af aftaler foregår via dokumentregistreringsservicen (DROS), detaljeret dokumentation er beskrevet under: Dokumentregistreringsservice

Arbejdsgangene omkring booking af aftaler med patienter, og derved deling af aftalerne foregår ofte som automatiske processer og system til system kommunikation, derfor kan der både benyttes et medarbejdercertifikat (MOCES) eller et Funktionscertifikat (FOCES) til deling af aftaler via Dokumentregistreringsservicen.

WSDL til DROS'en findes under: Snitfladebeskrivelse og endpoints og på https://wsdl.nspop.dk/#dros

Igen som når aftaler hentes ud, så skal selve ClinicalDocument oprettes som en MIME attachment, se eksemplet for detaljer.

ITI-41 ProvideAndRegisterDocumentSetRequest 
		<ProvideAndRegisterDocumentSetRequest xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns="urn:ihe:iti:xds-b:2007">
			<lcm:SubmitObjectsRequest>
				<rim:RegistryObjectList>
					<rim:ExtrinsicObject id="10614913492668759151.7526722965054630547.1561027587628" lid="17744819518467516435.5289508129896542596.1561027587628" mimeType="text/xml" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved">
						<rim:Slot name="creationTime">
							<rim:ValueList>
								<rim:Value>20170531120000</rim:Value>
							</rim:ValueList>
						</rim:Slot>
						<rim:Slot name="serviceStartTime">
							<rim:ValueList>
								<rim:Value>20190101010101</rim:Value>
							</rim:ValueList>
						</rim:Slot>
						<rim:Slot name="serviceStopTime">
							<rim:ValueList>
								<rim:Value>20200101010101</rim:Value>
							</rim:ValueList>
						</rim:Slot>
						<rim:Slot name="sourcePatientId">
							<rim:ValueList>
								<rim:Value>2512489996^^^&1.2.208.176.1.2&ISO</rim:Value>
							</rim:ValueList>
						</rim:Slot>
						<rim:Name>
							<rim:LocalizedString charset="UTF-8" value="Aftale for 2512489996" xml:lang="en-US"/>
						</rim:Name>
						<rim:Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="10614913492668759151.7526722965054630547.1561027587628" id="urn:uuid:0f2732cd-628f-4df7-821c-ede951749ccd" nodeRepresentation="">
							<rim:Slot name="authorInstitution">
								<rim:ValueList>
									<rim:Value>OUH Radiologisk Afdeling (Svendborg)^^^^^&1.2.208.176.1.1&ISO^^^^242621000016001</rim:Value>
								</rim:ValueList>
							</rim:Slot>
						</rim:Classification>
						<rim:Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="10614913492668759151.7526722965054630547.1561027587628" id="urn:uuid:03549911-5dd4-4406-8157-2f0c76cf6565" nodeRepresentation="001">
							<rim:Slot name="codingScheme">
								<rim:ValueList>
									<rim:Value>1.2.208.184.100.9</rim:Value>
								</rim:ValueList>
							</rim:Slot>
							<rim:Name>
								<rim:LocalizedString charset="UTF-8" value="Klinisk rapport" xml:lang="en-US"/>
							</rim:Name>
						</rim:Classification>
						<rim:Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="10614913492668759151.7526722965054630547.1561027587628" id="urn:uuid:fa1a078e-43e8-4cc3-a177-a670656b56e9" nodeRepresentation="urn:ad:dk:medcom:appointmentsummary:full">
							<rim:Slot name="codingScheme">
								<rim:ValueList>
									<rim:Value>1.2.208.184.100.10</rim:Value>
								</rim:ValueList>
							</rim:Slot>
							<rim:Name>
								<rim:LocalizedString charset="UTF-8" value="DK PHMR schema" xml:lang="en-US"/>
							</rim:Name>
						</rim:Classification>
						<rim:Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="10614913492668759151.7526722965054630547.1561027587628" id="urn:uuid:21648bfe-b78c-46d2-8bb1-80017f618775" nodeRepresentation="550621000005101">
							<rim:Slot name="codingScheme">
								<rim:ValueList>
									<rim:Value>2.16.840.1.113883.6.96</rim:Value>
								</rim:ValueList>
							</rim:Slot>
							<rim:Name>
								<rim:LocalizedString charset="UTF-8" value="hjemmesygepleje" xml:lang="en-US"/>
							</rim:Name>
						</rim:Classification>
						<rim:Classification classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="10614913492668759151.7526722965054630547.1561027587628" id="urn:uuid:a0594198-3c4a-4039-a269-18a970de3abf" nodeRepresentation="408443003">
							<rim:Slot name="codingScheme">
								<rim:ValueList>
									<rim:Value>2.16.840.1.113883.6.96</rim:Value>
								</rim:ValueList>
							</rim:Slot>
							<rim:Name>
								<rim:LocalizedString charset="UTF-8" value="almen medicin" xml:lang="en-US"/>
							</rim:Name>
						</rim:Classification>
						<rim:Classification classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="10614913492668759151.7526722965054630547.1561027587628" id="urn:uuid:98128f66-7cfc-480d-b1cf-14bedac10132" nodeRepresentation="39289-4">
							<rim:Slot name="codingScheme">
								<rim:ValueList>
									<rim:Value>2.16.840.1.113883.6.1</rim:Value>
								</rim:ValueList>
							</rim:Slot>
							<rim:Name>
								<rim:LocalizedString charset="UTF-8" value="Dato og tidspunkt for møde mellem patient og sundhedsperson" xml:lang="en-US"/>
							</rim:Name>
						</rim:Classification>
						<rim:ExternalIdentifier id="urn:uuid:7c0f749b-679d-4ac4-b039-0e4a6cd1378f" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" registryObject="10614913492668759151.7526722965054630547.1561027587628" value="2512489996^^^&1.2.208.176.1.2&ISO">
							<rim:Name>
								<rim:LocalizedString value="XDSDocumentEntry.patientId"/>
							</rim:Name>
						</rim:ExternalIdentifier>
						<rim:ExternalIdentifier id="urn:uuid:c8eb9924-b511-4883-8736-a6c24e329ee7" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" registryObject="10614913492668759151.7526722965054630547.1561027587628" value="10613314401450021042.16485562384221947016.1561027587628">
							<rim:Name>
								<rim:LocalizedString value="XDSDocumentEntry.uniqueId"/>
							</rim:Name>
						</rim:ExternalIdentifier>
					</rim:ExtrinsicObject>
					<rim:RegistryPackage id="7874116232104445829.6778506344390820751.1561027587628" lid="7874116232104445829.6778506344390820751.1561027587628" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved">
						<rim:Slot name="submissionTime">
							<rim:ValueList>
								<rim:Value>20170531120000</rim:Value>
							</rim:ValueList>
						</rim:Slot>
						<rim:Name>
							<rim:LocalizedString charset="UTF-8" value="7874116232104445829.6778506344390820751.1561027587628" xml:lang="en-US"/>
						</rim:Name>
						<rim:Classification classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500" classifiedObject="7874116232104445829.6778506344390820751.1561027587628" id="urn:uuid:3f20f9c0-ef4b-449d-985b-2e923431e1d8" nodeRepresentation="39289-4">
							<rim:Slot name="codingScheme">
								<rim:ValueList>
									<rim:Value>2.16.840.1.113883.6.1</rim:Value>
								</rim:ValueList>
							</rim:Slot>
							<rim:Name>
								<rim:LocalizedString charset="UTF-8" value="Dato og tidspunkt for møde mellem patient og sundhedsperson" xml:lang="en-US"/>
							</rim:Name>
						</rim:Classification>
						<rim:Classification classificationScheme="urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d" classifiedObject="7874116232104445829.6778506344390820751.1561027587628" id="urn:uuid:b28dc026-efd5-40bc-895c-f978127be6fd" nodeRepresentation="">
							<rim:Slot name="authorInstitution">
								<rim:ValueList>
									<rim:Value>OUH Radiologisk Afdeling (Svendborg)^^^^^&1.2.208.176.1.1&ISO^^^^242621000016001</rim:Value>
								</rim:ValueList>
							</rim:Slot>
						</rim:Classification>
						<rim:ExternalIdentifier id="urn:uuid:a541991d-f8b3-47f1-8dab-78cec036815f" identificationScheme="urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446" registryObject="7874116232104445829.6778506344390820751.1561027587628" value="2512489996^^^&1.2.208.176.1.2&ISO">
							<rim:Name>
								<rim:LocalizedString value="XDSSubmissionSet.patientId"/>
							</rim:Name>
						</rim:ExternalIdentifier>
						<rim:ExternalIdentifier id="urn:uuid:d49106ed-2ccf-403b-a785-4d5a1bd25242" identificationScheme="urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8" registryObject="7874116232104445829.6778506344390820751.1561027587628" value="7874116232104445829.6778506344390820751.1561027587628">
							<rim:Name>
								<rim:LocalizedString value="XDSSubmissionSet.uniqueId"/>
							</rim:Name>
						</rim:ExternalIdentifier>
						<rim:ExternalIdentifier id="urn:uuid:9bdc2b25-a86b-4088-9ae8-1e1d7027214d" identificationScheme="urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832" registryObject="7874116232104445829.6778506344390820751.1561027587628" value="7874116232104445829.6778506344390820751.1561027587628">
							<rim:Name>
								<rim:LocalizedString value="XDSSubmissionSet.sourceId"/>
							</rim:Name>
						</rim:ExternalIdentifier>
					</rim:RegistryPackage>
					<rim:Classification classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" classifiedObject="7874116232104445829.6778506344390820751.1561027587628" id="urn:uuid:6e17db47-168b-49bc-bbaa-c2570e255cf2"/>
					<rim:Association associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember" id="5855258517755215834.4341855612522046622.1561027587628" sourceObject="7874116232104445829.6778506344390820751.1561027587628" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" targetObject="10614913492668759151.7526722965054630547.1561027587628">
						<rim:Slot name="SubmissionSetStatus">
							<rim:ValueList>
								<rim:Value>Original</rim:Value>
							</rim:ValueList>
						</rim:Slot>
					</rim:Association>
				</rim:RegistryObjectList>
			</lcm:SubmitObjectsRequest>
			<Document id="10614913492668759151.7526722965054630547.1561027587628">
				<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:d028af6e-dc46-4049-b3bd-a4496767e42d@urn%3Aihe%3Aiti%3Axds-b%3A2007"/>
			</Document>
		</ProvideAndRegisterDocumentSetRequest>


4.6. Ændring af Aftaler

Ændring af aftaler er tilsvarende oprettelse af aftaler. Fagsystemet skal blot sikre sig at aftaleid'en er den samme når dokumentet oprettes (husk at aftale-id og dokument-id ikke er det samme - se beskrivelsen ovenfor).

Når ændringen af kalenderaftalen har betydning for patienten og/eller sundhedsprofessionelle, fx ændring af tid eller sted, skal ændringerne i kalenderaftalen være tilgængelige på infrastrukturen.

Når en aftale er ændret, eksempelvis fordi mødetidspunktet er flyttet, skal metoden der er beskrevet i dokumentationen benyttes (altså lave et ITI-41 provideAndRegister request, men man skal som dokument-provider selv angive associationstypen, source-objektet og target objektet
For en præcis teknisk vejledning, kan opskriften fra IHE’s wikiside følges (https://wiki.ihe.net/index.php/Annotated_ProvideAndRegister.b_Transaction#Document_Replacement)

Infrastrukturen vil derefter automatisk sørge for at tage den tidligere instans af aftalen, og sætte den til status "deprecated" og så gemme den nye instans af aftalen.
Den nye instans af aftalen bliver samtidigt kædet til den tidligere instans - således der er historik på aftalen.

Arbejdsgangene omkring ændringer af en aftale med patienten, og derved deling af aftalen foregår ofte som automatiske processer og system til system kommunikation, derfor kan der både benyttes et medarbejdercertifikat (MOCES) eller et Funktionscertifikat (FOCES) til deling af aftaler via Dokumentregistreringsservicen.

4.7. Sletning af Aftaler

Der er ikke udstillet funktionalitet til at slette aftaler for fagsystemerne.
Aftaler bliver automatisk slettet 2 år efter udførelsestidspunktet, hvilket er fastsat lovgivningsmæssigt.

Fagsystemer skal istedet ændre aftalen, og give den status "deprecated". Det kan gøres ved at benytte ITI-57 UpdateDocumentSet, hvorved AvailabilityStatus stættes til "deprecated" istedet for "approved"

Arbejdsgangene omkring sletning af en aftale med patienten, og derved stoppe deling af aftalen foregår ofte som automatiske processer og system til system kommunikation, derfor kan der både benyttes et medarbejdercertifikat (MOCES) eller et Funktionscertifikat (FOCES).

5. Sikkerhed, roller og rettigheder

For adgang til Aftaleoversigten skal der for sundhedspersoner eksistere et gyldigt SOSI-ID kort som er signeret af NSP'ens Secure Token Service, dokumentationen for SOSI-ID kort og STS ligger under: Anvenderguide til STS

Sundhedspersoner, med en sundhedsfaglig autorisation har adgang til Aftaleoversigten. Sundhedspersoner uden sundhedsfaglig autorisation skal have tilknyttet en rettighed før disse kan få adgang. Lokale organisationer kan enten tilknytte disse rettigheder via Sundhedsstyrelsens Elektroniske Brugerstyring (SEB), eller give rettigheden via den lokale identifikations- og rettighedsstyring.

Følgende roller anvendes i forbindelse med Et samlet patientoverblik.

Rollenavn

Rettighed

Notation som indsættes i SOSI IdKort ved udstedelse

nspSundAssistR2

Giver ret til at læse Aftaleoversigten

Giver også adgang til at læse andre dokumenter, der deles via dokumentdelingsinfrastrukturen jvf. Sundhedslovens §42a stk. 4

Se detaljeret beskrivelse af alle nationale roller her: Beskrivelse af de nationale roller i produktion - NSP services - Global Site (nspop.dk) samt overordnet dokumentation for SEB her: SEB - Sundhedsvæsenets Elektroniske Brugerstyring - Sundhedsdatastyrelsen Services (nsi.dk)

urn:dk:healthcare:national-federation-role:code:41002:value:SundAssistR2

En sundhedsperson kan ikke have tilknyttet flere roller på samme tid - dette skal administreres via den lokale identifikations- og rettighedsstyring eller via SEB.

6. Håndtering af Frabedelse og Fuldmagt

Frabedelse af deling af sundhedsdata

Patienten kan have frabedt sig at data fra Aftaleoversigten må deles med andre parter i sundhedssektoren, i det tilfælde vil fejlkoden "Consent Filter Applied” blive returneret (se nedenstående xml eksempel for ITI-18 Dokumenter med frabedelse). Det betyder at borgeren enten har frabedt sig deling af Aftaler til den specifikke sundhedsperson, for Aftaler i et givet tidsrum, for Aftaler fra bestemte organisationer, eller i en kombination af disse. Klienten skal håndtere at der er angivet en frabedelse, og give sundhedspersonen mulighed for at få adgang til den fulde Aftaleoversigt under specielle vilkår. 

For adgang til Aftaler, hvor der er frabedt deling, kan klienten enten angive et værdispring, eller angive at der ligger et explicit samtykke til at se data, og så sende forespørgslen igen med “ConsentOverride” flaget sat til “True”. Der laves logning i dokumentdelingsinfrastrukturen der angiver at en frabedelse er tilsidesat. Klienten skal samtidig angive årsagen (Eksempelvis: eksplicit samtykke fra patienten for at få adgang til data) til at frabedelsen er tilsidesat i eget journalsystem, da der kan forventes at være opfølgning på tilsidesatte frabedelser.

Yderligere information omkring frabedelse af deling af sundhedsdata og forespørgsler via dokumentdeling kan ses i Brugervejledning til forespørgsler via DDS. Eksempel på ITI-18 fejlsvar for dokumenter, som der er lavet frabedelse på: 

ITI-18 Dokumenter med frabedelse 
<rs:RegistryError codeContext="urn:dk:nsi:Consent Filter Applied" errorCode="XDSRegistryError" severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/>

Fuldmagt

Patientportaler kan give patienternes pårørende adgang via den Fælles Offentlige Fuldmagtsservice, hvortil der er tilknyttet en brugergrænseflade på Borger.dk.

Bevis for fuldmagter er understøttet i OIO-IDWS identitytokens signeret af STS'en, dog understøtter dokumentdelingsservicen ikke OIO-IDWS - så fuldmagter er i stedet etableret via en trust-løsning hvor patientportalen selv håndterer kontrol af fuldmagter.

Information angående angivelse af fuldmagter via dokumentdelingsservicen, kan ses i HSUID header dokumentation.

7. Ændringslog

0.8 2019-12-06 Udkast til Teknisk implementeringsguide til Aftaleoversigt SDS
0.9 2019-12-20 Opdateret på baggrund af indkommende kommentarer SDS
1.0 2020-01-06 Offentlig efter afsluttet kommenteringsrunde SDS
1.0.1 2020-01-10

Uddybning af den tekniske dokumentation angående:

Ændring af aftaler samt opdatering af aftaler

 SDS
1.1 2020-03-27

Tilrettet efter opdatering af testprotokol for CDA profilen
Desuden mindre tekstuelle rettelser

 SDS
1.1.1 2020-05-11

Præciseret ordlyden omkring brug af medarbejdercertifikater (MOCES) og Funktionscertifikater (FOCES)

 SDS
1.2 2020-05-22 Tilrettet efter mindre opdatering af DK-APD fra 2.0 til 2.0.1 SDS
1.2.1 2020-06-26 Præcisering omkring hvilke felter i aftalen, der skal vises for slutbrugerne i henhold til testprotokollen SDS
1.2.2 2020-08-21 Præcisering af forvalter ("custodian") begrebet i CDA dokumentet SDS
1.2.3 2020-10-21 Tilføjelse af Errata til APD-DK 2.0.1 SDS
1.2.4 2020-10-26 Præciseringer af SOR ved de forskellige lokationstyper SDS
1.2.5 2021-03-04 Præcisering af "Ændring af aftaler"  SDS
1.2.6 2021-08-16 Præciseret angivelse af IHE's søgeparamtre for ITI-18 SDS
1.2.7 2022-01-28 Opdateret med beskrivelse af virtuelle aftaler SDS
1.2.8 2022-04-27 Ændret endpoints til dokumentregistrering til DROS, da DRS udfases i henhold til NSP-28724

SDS
1.2.9 2023-03-01 Rettet link til MedCom CDA Header v. 1.4.

SDS
1.2.10 2023-03-20 Rettet rettighed for nspSundAssistR2 - rollen giver kun adgang til Aftaleoversigten og Fælles Stamkort

SDS
1.2.11 2024-03-12 Rettet rettighed for nspSundAssistR2 - rollen giver adgang til alle dokumenter der deles via dokumentdelingsinfrastrukturen

SDS
1.2.12 2025-03-24 Spærring ændret til frabedelse

SDS



  • No labels