Page History
Table of Contents | ||||
---|---|---|---|---|
|
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.
...
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 MedcomMedCom.
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.
...
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 MedCom der står for den danske profilering. Se under Medcom 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.
...
Indholdet i CDA headeren er fælles for alle danske CDA dokumenter, og er ligeledes forankret hos MedcomMedCom, se under Medcom under MedCom CDA Header v. 1.4.
Systemer der tilsluttes Aftaleoversigten, skal godekendes godkendes af medcom 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ældendefor gældende for modtagelse, kan findes på MedcomMedCom'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
...
Kode | Beskrivelse | Eksempel |
ID for aftalen ClinicalDocument.id | Den unikke identifikation for aftalen | <id |
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. <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"> <assignedPerson classCode="PSN" determinerCode="INSTANCE"><name> </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. templateId | 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. templateId | 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 code | 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 | 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 code | 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,
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”> <playingEntity classCode="PLC"> </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”> <playingEntity classCode="PLC"> </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”> <playingEntity classCode="PLC"> <name>Borgers Hjemmeadresse</name> </playingEntity> </participantRole> </participant> |
Årsag til aftalen <body>.encounter.entryRelationship. | Årsagen til at der er indkaldt til aftalen | <entryRelationship typeCode="RSON"> <observation classCode="OBS" moodCode="EVN"> <code code="NI" displayName="Hjemmehjælp"/> </observation> </entryRelationship> |
...
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 |
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 servies gennem DCC'en.
NSP services kan tilgås enten via Den Gode Webservice (DGWS) eller via OIO-IDWS (Udelukkende borgeradgang).
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 fat lave en spærring for 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, allebaseret 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 dokumenterner volume 1, 2a, 2b, 2x og 3.
- IHE ITI TF Vol. 1 - Integration Profiles
http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf - IHE ITI TF Vol. 2a - Transactions 1-28
http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2a.pdf - IHE ITI TF Vol. 2b - Transactions 29-64
http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf - IHE ITI TF Vol. 2x - Appendices A-X
http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2x.pdf - IHE ITI TF Vol. 3 - Metadata
http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf
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:
- IPF Open eHealth Integration Platform
http://oehf.github.io/ipf/ipf-platform-camel-ihe/ - IPF Commons IHE XDS
https://mvnrepository.com/artifact/org.openehealth.ipf.commons/ipf-commons-ihe-xds
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/
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.
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 fat lave en spærring for 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.
- IHE ITI TF Vol. 1 - Integration Profiles
http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf - IHE ITI TF Vol. 2a - Transactions 1-28
http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2a.pdf - IHE ITI TF Vol. 2b - Transactions 29-64
http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf - IHE ITI TF Vol. 2x - Appendices A-X
http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2x.pdf - IHE ITI TF Vol. 3 - Metadata
http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf
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:
- IPF Open eHealth Integration Platform
http://oehf.github.io/ipf/ipf-platform-camel-ihe/ - IPF Commons IHE XDS
https://mvnrepository.com/artifact/org.openehealth.ipf.commons/ipf-commons-ihe-xds
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):
Code Block |
---|
$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)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.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<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> |
...
Oprettelse af aftaler foregår via dokumentregistreringsservicen (DRSDROS), 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 DRSDROS'en findes under: Snitfladebeskrivelse og endpoints og på https://wsdl.nspop.dk/drs/wsdl/drs.wsdl#dros
Igen som når aftaler hentes ud, så skal selve ClinicalDocument oprettes som en MIME attachment, se eksemplet for detaljer.
...
Æ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 en aftale skal ændres, 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)
...
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 Sundhedsstyrelssens Sundhedsstyrelsens Elektroniske Brugerstyring (SEB), eller give rettigheden via den lokale identifikations- og rettighedstyringrettighedsstyring.
Følgende rollebeskrivelser roller anvendes i forbindelse med Et samlet patientoverblik.
Rollenavn |
Rettighed | Notation som indsættes i SOSI IdKort ved udstedelse |
urn:dk:healthcare:national-federation-role:code:41001:value:SundAssistR1
nspSundAssistR2
Giver ret til at læse til Aftaleoversigt, FSK og Planer og Indsatser
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 overordnet dokumentation for nationale roller 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 rettighedstyringrettighedsstyring, eller via SEB
Bemærk: SEB-dokumentationen samt vejledningen ved oprettelse af en rolle er ved at blive tilrettet, så rettigheden for nspSundAsisstR2 afspejler ovenstående.
Håndtering af Spærring og Fuldmagt
...
Patienten kan have spærret for 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 spærrede dokumenter). Det betyder at borgeren enten har spærret for 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 spærring, for Aftaler fra bestemte organisationer, eller i en kombination af disse. Klienten skal håndtere at der er angivet en spærring, og give sundhedspersonen mulighed for at få adgang til den fulde Aftaleoversigt under specielle vilkår.
For adgang til spærrede Aftaler 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 spærring er tilsidesat. Klienten skal samtidig angive årsagen (Eksempelvis: eksplicit samtykke fra patienten for at få adgang til data) til at spærringen er tilsidesat i eget journalsystem, da der kan forventes at være opfølgning på tilsidesatte spærringer.
Yderligere information omkring spærring og forespørgsler via dokumentdeling kan ses i Brugervejledning til forespørgsler via DDS
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<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 istedet 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.
Ændringslog
og give sundhedspersonen mulighed for at få adgang til den fulde Aftaleoversigt under specielle vilkår.
For adgang til spærrede Aftaler 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 spærring er tilsidesat. Klienten skal samtidig angive årsagen (Eksempelvis: eksplicit samtykke fra patienten for at få adgang til data) til at spærringen er tilsidesat i eget journalsystem, da der kan forventes at være opfølgning på tilsidesatte spærringer.
Yderligere information omkring spærring og forespørgsler via dokumentdeling kan ses i Brugervejledning til forespørgsler via DDS
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<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.
Æ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 | 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 | |
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 | 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 lokationstyperSDS |