Page History
| Table of Contents | ||
|---|---|---|
|
Indledning
Denne vejledning beskriver de tekniske forretningsregler forudsætninger i forhold til at implementere Forløbsplaner Forløbsplaner i et lokalt fagsystem eller en patient/ borgerportal. Vejledningen er tiltænkt forretningsarkitekter, systemarkitekter samt systemleverandører, således at disse de kan vurdere hvordan Forløbspalnerne Forløbsplanerne kan implementeres i systemerne.
| Info |
|---|
Det er vigtigt at forretningsreglerne og indhold for Forløbsplaner læses i forbindelse med en kommende implementering. Den tekniske implementeringsvejledning kan ikke stå alene. |
IHE XDS
På nationalt plan er der udarbejdes der udarbejdet en indholdsprofil ud fra HL7's s Clinical Document Architecture Architecture (CDA), som beskriver udvekslingsformatet for forløbsplanerne Forløbsplanerne til KOL, diabetes og hjertelidelseriskæmisk hjertesygdom. Indholdsprofilen er forankret hos MedCom.
CDA-dokumenterne for forløbsplaner Forløbsplaner forvaltes af Primærsektorens Leverandør Service Platform (PLSP), men udstilles via den nationale delingsinfrastruktur, således at borgerens forløbsplaner Forløbsplaner kan fremfindes af sundhedsvæsenets aktører. Aktører, som understøtter ForløbsplanerForløbsplaner, kan via deres fagsystemer anvende de standardiserede IHE XDS-snitflader til at hente borgernes forløbsplanerForløbsplaner.
Den nationale delingsinfrastruktur udstilles gennem dokumentdeling- og dokumentregistreringsservices via standardiserede IHE XDS-snitflader. Disse er tilpasset den nationale sikkerhedsinfrastruktur, som bl.a. omhandler autorisation, samtykkekontrol, auditlogning etc.
Anden dokumentation
De overordnede forretningsregler til Digital Løsning til Graviditetsforløb kan ses i dokumentet: Indhold og forretningsregler
Udveksling af data om den gravides gravidtetsmappe Forløbsplaner foregår via den nationale delingsinfrastruktur. Denne understøtter referencearkitekturen for for deling af dokumenter og billeder.
For generel introduktion til den nationale delingsinfrastruktur, 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 beskrivelsen på på Dokumentdeling på NSP (DROS, DDS, NXRG, OpenXDS)
Aktører
Figure Figuren giver et overblik over de aktører som er i spil i relation til deling af forløbsplanerForløbsplaner.
Den praktiserende læge: Lægen udarbejder forløbsplanen, og/eller klinikpersonale udarbejder Forløbsplanen for henholdsvis KOL, diabetes og hjertelidelser iskæmisk hjertesygdom i samerbejde samarbejde med patienten borgeren via eget klinikkens fagsystem.
Forløbsplanen Forløbsplanen opbevares i forløbsplandatabasen Forløbsplandatabasen som er forvaltet af PLSP.
Borgere (Patienter): Borgere har læseadgang til egne forløbsplaner Forløbsplaner via Sundhedsjournalen på sundhed.dk, bemærk borgere kan ikke få adgang til forløbsplaner for børn under forældremyndighed
Pårørende: Pårørende har læseadgang til borgerens forløbsplaner Forløbsplaner via Sundhedsjournalen på sundhed.dk, hvis . Hvis borgeren har tildelt den pårørende en læsefuldmagt via den fælles-offentlige fuldmagsservice fuldmagtsservice på borger.dk.
Sundhedspersoner: Sundhedspersoner har adgang til borgeres forløbsplaner Forløbsplaner via Sundhedsjournalen på sundhed.dk, eller via eget fagsystem - afhængigt ,afhængig af lokal implementering.
Sundhedsprofessionelle (uden sundhedsfaglig autorisation): Kan få adgang til borgerens forløbsplaner Forløbsplaner via lokal trustmodel, hvor parterne giver relevante medarbejdere adgang til at tilgå borgeres forløbsplaner Forløbsplaner via Sundhedsjournalen på sundhed.dk, eller via eget fagsystem - , afhængigt af lokal implementering.
Teknisk oversigt
Indhold i
...
forløbsplaner
...
Først og fremmest skal man kende til det indholdsformat, der benyttes til forløbsdokumenterForløbsplansdokumenter. Formatet er XML og indholdet er specificeret som en dansk profil af CDA. Den danske profil for CDA Careplan (CPD-DK 2v2.0.0) er forankret hos MedCom, der står for den danske profilering. Se under IMedCom CPD-DK hvor ses både beskrivelse af standarden samt forskellige aftale eksempler opbevares, bemærk der Forløbsplan eksempler. Bemærk:Der findes eksempler til alle versioner af CPD-DK, eksempler . Eksempler til CPD-DK 2v2.0.o 0 findes i Eksempel folderen.
Et CDA-dokument består af en header og en body, hvor headeren generelt . Headerenbeskriver en række metadata omkring dokumentets indhold, mens de dokumentspecifikke data placeres i body sektionenbodysektionen.
Indholdet i CDA headeren er fælles for alle danske CDA-dokumenter, og er ligeledes forankret hos MedCom, se under . Se under MedCom CDA Header v. 1.4.
I forbindelse med Forløbsplaner er der tilføjet en forløbslabel til CDA headeren, som ikke er inkluderet i CDA Header v. 1.4 standarden. Dette er beskrevet i CPD-DK v2.0.0 under afsnit 2.1.5.3.
Systemer der tilsluttes Forløbsplaner, skal Forløbsplaner skal bl.a. godkendes af MedCom ud fra en certificering. Testprotokollerne for certificering til Forløbsplaner,, Forløbsplaner kan findes på MedCom's hjemmeside under: Testprotokoller for modtagelse og afsendelse af careplaner.
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
...
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
...
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.
...
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.
...
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 hvordan CDA-dokumenter er opbygget kan findes hos IHE, under: IHE - Hvad er HL7 CDA?
Tekniske forudsætninger
Forløbsplaner 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.
| Info |
|---|
Det er et krav at dokumentdelingsservicen skal tilgås gennem afkoblingskomponenten |
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 Forløbsplaner skal sundhedspersoner have et STS-underskrevet SOSI-ID-kort på niveau 4 (medarbejder). Dette er beskrevet under administrative forudsætninger, således at borgeren har mulighed for atfrabede sig deling af data. Laves der en frabedelsekanForløbsplaner ikke deles med specifikke sundhedspersoner. Derudover harpatienten mulighed for at se, hvem der har haft adgang til patientens Forløbsplaner via MinLog.
For mere information om den gode webservice, se: https://www.medcom.dk/standarder/webservice-standarder/den-gode-webservice.
Sundhedsdatastyrelsen har beskrevet hvordan et SOSI-ID-kort kan skabes og anvendes under STS Dokumentationen.
De servicesnitflader der udstilles til Forløbsplaner er alle baseret på SOAP kald, der understøtter DGWS.
Indholdsdelen af den enkelte servicekald (SOAP-body) er den del der er specificeret af IHE XDS-snitfladerne,for eksempel ITI-18 og ITI-43. Se nærmere beskrivelse under: Dokumentdeling på NSP (DROS, DDS, NXRG/SDS Patientindex, OpenXDS)
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 derfor 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å forløbsplaner
For at søge efter en borgers Forløbsplaner, skal der laves en ITI-18 forespørgsel via NSP'ens dokumentdelingsservice.WSDLtil DDS Registry findes her: https://wsdl.nspop.dk/ddsregistry?wsdl.
Når der søges på Forløbsplaner, kan der søges på de værdier, der er angivet som XDS-metadata. Forløbsplaner benytter metadata profil version 0.96, der kan hentes på https://svn.medcom.dk/svn/releases/Standarder/IHE/DK_profil_metadata/.
Borgerens CPR-nummer (PatientId) samt Forløbsplansdokumenternes statuskode (Status) er påkrævede felter, som skal inkluderes i alle søgninger.
For Forløbsplaner er der desuden følgende forretningsmæssige XDS-metdata, som skal anvendes i søgninger:
- Typecode: 81215-6
- EventCodeList (Medtag kun parametre for den type forløbsplaner som er relevant for borgeren/den sundhedsfaglige)
- ALAL02 for hjertelidelser
- ALAL21 for KOL
- ALAL22 for Diabetes type-2
Desuden anbefales det at forespørge både efter specifikt format samt statiske og dynamiske (on-demand) dokumentkilder, angives denne værdi ikke, returneres kun data fra statiske dokumentkilder.
- Type
- urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1 (for statiske dokumentkilder)
- urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248 (for dynamiske "on-demand" dokumentkilder)
- FormatCode: urn:ad:dk:medcom:cpd-v2.0.0:full
Værdierne (klassifikationerne) som anvendes i XDS-metadata, er defineret i et regneark hos MedCom, se: DK-IHE_Metadata-Common_Code_systems-Value_sets.xlsx
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 dokumentationvolume 2
Eksempel på en ITI-18 forespørgsel efter Forløbsplaner:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<ns3:AdhocQueryRequest xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns4="urn:ihe:iti:xds-b:2007" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0">
<ns3:ResponseOption returnComposedObjects="true" returnType="LeafClass"/>
<AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d">
<Slot name="$XDSDocumentEntryTypeCode">
<ValueList>
<Value>('81215-6^^2.16.840.1.113883.6.1')</Value>
</ValueList>
</Slot>
<Slot name="$XDSDocumentEntryEventCodeList">
<ValueList>
<Value>('ALAL02^^1.2.208.176.2.4')</Value>
<Value>('ALAL21^^1.2.208.176.2.4')</Value>
<Value>('ALAL22^^1.2.208.176.2.4')</Value>
</ValueList>
</Slot>
<Slot name="$XDSDocumentEntryFormatCode">
<ValueList>
<Value>('urn:ad:dk:medcom:cpd-v2.0.0:full^^1.2.208.184.100.10')</Value>
</ValueList>
</Slot>
<Slot name="$XDSDocumentEntryPatientId">
<ValueList>
<Value>'2512489996^^^&1.2.208.176.1.2&ISO'</Value>
</ValueList>
</Slot>
<Slot name="$XDSDocumentEntryType">
<ValueList>
<Value>('urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248')</Value>
<Value>('urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1')</Value>
</ValueList>
</Slot>
<Slot name="$XDSDocumentEntryStatus">
<ValueList>
<Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')</Value>
</ValueList>
</Slot>
</AdhocQuery>
</ns3:AdhocQueryRequest> |
Retur-svaret indeholder referencerne til Forløbsplan dokumenterne, der skal benyttes efterfølgende til at udtrække de konkrete Forløbsplaner
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<ns3:AdhocQueryResponse 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" totalResultCount="3" status="urn:ihe:iti:2007:ResponseStatusType:Success">
<RegistryObjectList>
<ExtrinsicObject mimeType="text/xml" lid="urn:uuid:8ef612da-de9d-47f4-adca-e2d9fbbd740b" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:8ef612da-de9d-47f4-adca-e2d9fbbd740b">
<Slot name="creationTime">
<ValueList>
<Value>20201001081900</Value>
</ValueList>
</Slot>
<Slot name="hash">
<ValueList>
<Value>cf226a31ea1b88e8fbf2c19aabf8b39f015007d0</Value>
</ValueList>
</Slot>
<Slot name="languageCode">
<ValueList>
<Value>da-DK</Value>
</ValueList>
</Slot>
<Slot name="serviceStartTime">
<ValueList>
<Value>20201001081900</Value>
</ValueList>
</Slot>
<Slot name="repositoryUniqueId">
<ValueList>
<Value>1.2.208.176.43210.8.20.11</Value>
</ValueList>
</Slot>
<Slot name="size">
<ValueList>
<Value>78558</Value>
</ValueList>
</Slot>
<Slot name="sourcePatientId">
<ValueList>
<Value>2512489996^^^&1.2.208.176.1.2&ISO</Value>
</ValueList>
</Slot>
<Slot name="sourcePatientInfo">
<ValueList>
<Value>PID-5|Bonde^Sonja</Value>
<Value>PID-7|19481225</Value>
<Value>PID-8|F</Value>
</ValueList>
</Slot>
<Name>
<LocalizedString xml:lang="en-US" charset="UTF-8" value="Min forløbsplan for Diabetes"/>
</Name>
<VersionInfo versionName="1"/>
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="urn:uuid:8ef612da-de9d-47f4-adca-e2d9fbbd740b" nodeRepresentation="" id="urn:uuid:098b8a94-a2f2-41b0-99b0-ddb9309bc4e6">
<Slot name="authorPerson">
<ValueList>
<Value>^Andersen^Anders</Value>
</ValueList>
</Slot>
<Slot name="authorInstitution">
<ValueList>
<Value>Lægehuset Valdemarsgade^^^^^&1.2.208.176.1.1&ISO^^^^191901000016999</Value>
</ValueList>
</Slot>
</Classification>
<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="urn:uuid:8ef612da-de9d-47f4-adca-e2d9fbbd740b" nodeRepresentation="001" id="urn:uuid:2ab86472-7900-4977-9bcc-925a77f8ee13">
<Slot name="codingScheme">
<ValueList>
<Value>1.2.208.184.100.9</Value>
</ValueList>
</Slot>
<Name>
<LocalizedString xml:lang="en-US" charset="UTF-8" value="Clinical report"/>
</Name>
</Classification>
<Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="urn:uuid:8ef612da-de9d-47f4-adca-e2d9fbbd740b" nodeRepresentation="urn:ad:dk:medcom:appointmentsummary:full" id="urn:uuid:a428865b-1633-4374-a61e-45dd3cb9b138">
<Slot name="codingScheme">
<ValueList>
<Value>1.2.208.184.100.10</Value>
</ValueList>
</Slot>
<Name>
<LocalizedString xml:lang="en-US" charset="UTF-8" value="DK Appointment Summary Document schema"/>
</Name>
</Classification>
<Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="urn:uuid:8ef612da-de9d-47f4-adca-e2d9fbbd740b" nodeRepresentation="394761003" id="urn:uuid:3063e36c-bd48-426f-8b2b-1ed020239171">
<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="lægepraksis (snomed: almen lægepraksis)"/>
</Name>
</Classification>
<Classification classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="urn:uuid:8ef612da-de9d-47f4-adca-e2d9fbbd740b" nodeRepresentation="394821009" id="urn:uuid:872b4d5a-4c82-4932-ae30-610694a73123">
<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="arbejdsmedicin"/>
</Name>
</Classification>
<Classification classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="urn:uuid:8ef612da-de9d-47f4-adca-e2d9fbbd740b" nodeRepresentation="81215-6" id="urn:uuid:a9226a33-b2c6-470b-b418-2c3229ea64c5">
<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="Care plan - recommended C-CDA R2.0 & R2.1 sections"/>
</Name>
</Classification>
<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="urn:uuid:8ef612da-de9d-47f4-adca-e2d9fbbd740b" nodeRepresentation="N" id="urn:uuid:a42ac328-fdbb-413b-8130-de8fccf8a961">
<Slot name="codingScheme">
<ValueList>
<Value>2.16.840.1.113883.5.25</Value>
|
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
...
Beskrivelse
...
Eksempel
...
ID for aftalen
...
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"
...
<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"
...
<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>
...
<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:
- Lokationen er baseret på Sundhedsvæsnets Organisationsregister (SOR), og defineret som besøgsadresse i SOR.
typeCode="LOC" - Lokationen er baseret på en adresse udenfor SOR, f.eks den lokale idrætshal, eller den offentlige svømmehal.
typeCode="DST" - 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" />
...
<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
...
<entryRelationship typeCode="RSON">
<observation classCode="OBS" moodCode="EVN">
<code code="NI" displayName="Hjemmehjælp"/>
</observation>
</entryRelationship>
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å Forløbsplaner
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)
| 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"> <Name> <ValueList> <Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')</Value> <LocalizedString xml:lang="en-US" charset="UTF-8" value="N"/> </ValueList>Name> </Slot>Classification> <Slot<ExternalIdentifier nameregistryObject="$XDSDocumentEntryTypeCode"> <ValueList> <Value>('39289-4^^2.16.840.1.113883.6.1')</Value>urn:uuid:8ef612da-de9d-47f4-adca-e2d9fbbd740b" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="2512489996^^^&1.2.208.176.1.2&ISO" id="urn:uuid:b6d8d9de-123a-467f-b8bc-0815759174e6"> </ValueList> <Name> </Slot> <Slot<LocalizedString namevalue="$XDSDocumentEntryServiceStartTimeFromXDSDocumentEntry.patientId"/> <ValueList> <Value>20171231000000<</Value>Name> </ValueList>ExternalIdentifier> </Slot> <Slot name="$XDSDocumentEntryServiceStopTimeTo"> <ExternalIdentifier registryObject="urn:uuid:8ef612da-de9d-47f4-adca-e2d9fbbd740b" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="1.2.208.184^e23d1b0d-f4cc-4b3e-9973-b2a499aa15ba" id="urn:uuid:32b0c3d1-60aa-43ad-9152-8ef127a26980"> <ValueList> <Name> <Value>20181231000000</Value> <LocalizedString value="XDSDocumentEntry.uniqueId"/> </ValueList>Name> </Slot>ExternalIdentifier> <Slot name="$XDSDocumentEntryType"></ExtrinsicObject> <ValueList> <Value>('<ExtrinsicObject mimeType="text/xml" lid="urn:uuid:7edca82f16d20fa3-054d3db6-47f241dc-a032-9b2a5b5186c1')</Value> <Value>('a97f-0557fb973b8e" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:34268e4716d20fa3-fdf53db6-41a641dc-ba33-82133c465248')</Value>a97f-0557fb973b8e" home="1.2.208.176.43210.8.20"> </ValueList><Slot name="creationTime"> </Slot> <ValueList> <<Value>20190311000000</AdhocQuery>Value> </AdhocQueryRequest> |
Svaret indeholder referencerne til Aftale dokumenterne, der skal benyttes efterfølgende til at udtrække Aftaleoversigten
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<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> ValueList> </Slot> <Slot name="hash"> <ValueList> <Value>f2f2a5dcd1de12a06e375c55b429e01497418df3</Value> </ValueList> </Slot> <Slot name="languageCode"> <ValueList> <Value>da-DK</Value> </ValueList> </Slot> <Slot name="serviceStartTime"> <ValueList> <Value>20231012000000</Value> </ValueList> </Slot> <Slot name="repositoryUniqueId"> <ValueList> <Value>1.2.208.176.43210.8.20.11</Value> </ValueList> </Slot> <Slot name="size"> <ValueList> <Value>45429</Value> </ValueList> </Slot> <Slot name="sourcePatientId"> <ValueList> <Value>2512489996^^^&1.2.208.176.1.2&ISO</Value> </ValueList> </Slot> <Slot name="sourcePatientInfo"> <ValueList> <Value>PID-5|Berggren^Nancy^Ann</Value> <Value>PID-7|19481225</Value> <Value>PID-8|F</Value> </ValueList> </Slot> <Name> <LocalizedString xml:lang="en-US" charset="UTF-8" value="Min forløbsplan for Diabetes"/> </Name> <VersionInfo versionName="1"/> <Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="urn:uuid:16d20fa3-3db6-41dc-a97f-0557fb973b8e" nodeRepresentation="" id="urn:uuid:ddca4b06-a02e-4eee-82bf-7e84d1c18ad5"> <Slot name="authorPerson"> <ValueList> <Value>^Andersen^Anders</Value> </ValueList> </Slot> <Slot name="authorInstitution"> <ValueList> <Value>Lægehuset Valdemarsgade^^^^^&1.2.208.176.1.1&ISO^^^^191901000016999</Value> </ValueList> </Slot> </Classification> <Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="urn:uuid:16d20fa3-3db6-41dc-a97f-0557fb973b8e" nodeRepresentation="001" id="urn:uuid:a90d9294-60f9-4e7f-a3fc-952fd3d2ff96"> <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:16d20fa3-3db6-41dc-a97f-0557fb973b8e" nodeRepresentation="urn:ad:dk:medcom:cpd-v1.0.1:full" id="urn:uuid:65e6e8d9-889c-4e8f-bc2c-fd704c17ea9e"> <Slot name="codingScheme"> <ValueList> <Value>1.2.208.184.100.10</Value> </ValueList> </Slot> <Name> <LocalizedString xml:lang="en-US" charset="UTF-8" value="DK CPD schema"/> </Name> </Classification> <Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="urn:uuid:16d20fa3-3db6-41dc-a97f-0557fb973b8e" nodeRepresentation="N/A" id="urn:uuid:9cb1fd64-633a-4681-b326-bb1dc2895a1a"> <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="N/A"/> </Name> </Classification> <Classification classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="urn:uuid:16d20fa3-3db6-41dc-a97f-0557fb973b8e" nodeRepresentation="N/A" id="urn:uuid:3940a9a2-4715-4ed7-9401-ff2662f44a57"> <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="N/A"/> </Name> </Classification> <Classification classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="urn:uuid:16d20fa3-3db6-41dc-a97f-0557fb973b8e" nodeRepresentation="81215-6" id="urn:uuid:e79a48f4-2c1c-4e6c-8e45-edce17674878"> <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="Klinisk rapport"/> </Name> </Classification> <Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309dCare plan - recommended C-CDA R2.0 & R2.1 sections"/> </Name> </Classification> <Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="urn:uuid:f39c138016d20fa3-4d8f3db6-4e2741dc-9376a97f-398b397910670557fb973b8e" nodeRepresentation="urn:ad:dk:medcom:appointmentN" id="urn:uuid:c9783e44bbe74d44-fa81f747-442b4da9-a710900f-7a2598081167776ca70ce29b"> <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> <ValueList> <Value>2.16.840.1.113883.5.25</Value> </ValueList> </Slot> <Name> <LocalizedString xml:lang="en-US" charset="UTF-8" value="N"/> </Name> </Classification> <Classification classificationScheme="urn:uuid:f33fb8ac2c6b8cb7-18af8b2a-42cc4051-ae0eb291-ed0b0bdb91e1b1ae6a575ef4" classifiedObject="urn:uuid:f39c138016d20fa3-4d8f3db6-4e2741dc-9376a97f-398b397910670557fb973b8e" nodeRepresentation="22232009ALAL22" id="urn:uuid:552eae076f2e0754-cc8c723a-4afa4c6f-a93e8002-306b0349cda505f146f48bca"> <Slot name="codingScheme"> <ValueList> <Value>2.16.840.1.113883.6.96</Value> </ValueList> </Slot> <Name> <ValueList> <Value>1.2.208.176.2.4</Value> </ValueList> </Slot> <Name> <LocalizedString xml:lang="en-US" charset="UTF-8" value="hospitalType 2-diabetes"/> </Name> </Name> </Classification> <Classification classificationScheme <ExternalIdentifier registryObject="urn:uuid:cccf559816d20fa3-8b073db6-4b7741dc-a05ea97f-ae952c785ead0557fb973b8e" classifiedObjectidentificationScheme="urn:uuid:f39c138058a6f841-4d8f87b3-4e274a3e-937692fd-398b39791067a8ffeff98427" nodeRepresentationvalue="4084430032512489996^^^&1.2.208.176.1.2&ISO" id="urn:uuid:fe772f973fad78e0-377b3805-43a54819-94788b0b-de63e82ed911065614e706bd"> <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^^^ <Name> <LocalizedString value="XDSDocumentEntry.patientId"/> </Name> </ExternalIdentifier> <ExternalIdentifier registryObject="urn:uuid:16d20fa3-3db6-41dc-a97f-0557fb973b8e" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="1.2.208.184^a452b373-2c23-4a99-9039-f83c438c3a99" id="urn:uuid:11802916-f72e-4c7c-9baf-99a2f3bc72ee"> <Name> <LocalizedString value="XDSDocumentEntry.uniqueId"/> </Name> </ExternalIdentifier> </ExtrinsicObject> <ExtrinsicObject mimeType="text/xml" lid="urn:uuid:ff4fa9c1-4c74-47ba-8eae-31b8acd7dd34" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:ff4fa9c1-4c74-47ba-8eae-31b8acd7dd34" home="1.2.208.176.43210.8.20"> <Slot name="creationTime"> <ValueList> <Value>20231012000000</Value> </ValueList> </Slot> <Slot name="hash"> <ValueList> <Value>bea3a285af86464ff4937cf9fb36effabc7ec5de</Value> </ValueList> </Slot> <Slot name="languageCode"> <ValueList> <Value>da-DK</Value> </ValueList> </Slot> <Slot name="serviceStartTime"> <ValueList> <Value>20231012000000</Value> </ValueList> </Slot> <Slot name="repositoryUniqueId"> <ValueList> <Value>1.2.208.176.43210.8.20.11</Value> </ValueList> </Slot> <Slot name="size"> <ValueList> <Value>40550</Value> </ValueList> </Slot> <Slot name="sourcePatientId"> <ValueList> <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.1528403737836ISO</Value> </ValueList> </Slot> <Slot name="sourcePatientInfo"> <ValueList> <Value>PID-5|Berggren^Nancy^Ann</Value> <Value>PID-7|19481225</Value> <Value>PID-8|F</Value> </ValueList> </Slot> <Name> <LocalizedString xml:lang="en-US" charset="UTF-8" value="Min forløbsplan for KOL"/> </Name> <VersionInfo versionName="1"/> <Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="urn:uuid:ff4fa9c1-4c74-47ba-8eae-31b8acd7dd34" nodeRepresentation="" id="urn:uuid:fe083081c251d963-c2b1e53c-4e4c4a01-b5508a6b-4d852a60c18f84ee8a271b5b"> <Name> <LocalizedString value="XDSDocumentEntry.uniqueId"/> </Name> </ExternalIdentifier> </ExtrinsicObject> <ExtrinsicObject mimeType="text/xml" lid <Slot name="authorPerson"> <ValueList> <Value>^Andersen^Anders</Value> </ValueList> </Slot> <Slot name="authorInstitution"> <ValueList> <Value>Lægehuset Valdemarsgade^^^^^&1.2.208.176.1.1&ISO^^^^191901000016999</Value> </ValueList> </Slot> </Classification> <Classification classificationScheme="urn:uuid:72c193ba41a5887f-5d308865-4ebe4c09-b325adf7-5058cc314b6ce362475b143a" objectTypeclassifiedObject="urn:uuid:7edca82fff4fa9c1-054d4c74-47f247ba-a0328eae-9b2a5b5186c131b8acd7dd34" statusnodeRepresentation="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved001" id="urn:uuid:72c193bacf6df901-5d30fa20-4ebe448c-b325b38a-5058cc314b6c107e7f57bd92"> <Slot name="creationTimecodingScheme"> <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=" <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:ff4fa9c1-4c74-47ba-8eae-31b8acd7dd34" nodeRepresentation="urn:ad:dk:medcom:cpd-v1.0.1:full" id="urn:uuid:f634b293-64c9-4a31-a5c3-dab894529a22"> <Slot name="codingScheme"> <ValueList> <Value>1.2.208.184.100.10</Value> </ValueList> </Slot> <Name> <LocalizedString xml:lang="en-US" charset="UTF-8" value="DK CPD schema"/> </Name> </Classification> <Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="urn:uuid:ff4fa9c1-4c74-47ba-8eae-31b8acd7dd34" nodeRepresentation="N/A" id="urn:uuid:a5d6214a-f852-489c-bb32-d60359af9e4e"> <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="N/A"/> </Name> </Classification> <Classification classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="urn:uuid:ff4fa9c1-4c74-47ba-8eae-31b8acd7dd34" nodeRepresentation="N/A" id="urn:uuid:5d6b0d4d-15fc-4ac4-a142-9d6bc92d79b5"> <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="N/A"/> </Name> </Classification> <Classification classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="urn:uuid:ff4fa9c1-4c74-47ba-8eae-31b8acd7dd34" nodeRepresentation="81215-6" id="urn:uuid:65af478b-ecf3-4c47-9ec4-df2f61d86895"> <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="Care plan - recommended C-CDA R2.0 & R2.1 sections"/> </Name> </Classification> <Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="urn:uuid:ff4fa9c1-4c74-47ba-8eae-31b8acd7dd34" nodeRepresentation="N" id="urn:uuid:4ea2ae7180e5dbb5-92494e3f-47964cc1-b8efb435-a3285f82a0a1491d5f128c8b"> <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 <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="N"/> </Name> </Classification> <Classification classificationScheme="urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4" classifiedObject="urn:uuid:ff4fa9c1-4c74-47ba-8eae-31b8acd7dd34" nodeRepresentation="ALAL21" id="urn:uuid:b2b8499ef12bdd3f-f7f2b520-41df46a3-98e1a1c4-27f0d2f4d73b5caf649e0cb0"> <Slot name="codingScheme"> <ValueList> <ValueList> <Value>1.2.208.184176.1002.9<4</Value> </ValueList> </Slot> <Name> <LocalizedString xml </ValueList> </Slot> <Name> <LocalizedString xml:lang="en-US" charset="UTF-8" value="Klinisk rapportKronisk obstruktiv lungesygdom (KOL)"/> </Name> </Name> </Classification> <Classification classificationScheme <ExternalIdentifier registryObject="urn:uuid:a09d5840ff4fa9c1-386c4c74-46f247ba-b5ad8eae-9c3699a4309d31b8acd7dd34" classifiedObjectidentificationScheme="urn:uuid:72c193ba58a6f841-5d3087b3-4ebe4a3e-b32592fd-5058cc314b6ca8ffeff98427" nodeRepresentation="urn:ad:dk:medcom:appointmentvalue="2512489996^^^&1.2.208.176.1.2&ISO" id="urn:uuid:8a3337dd05987b69-8219f551-4dd443da-b5a292f4-e86166940b700ee563c7355b"> <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:
...
Yderligere information omkring forespørgsler via dokumentdeling kan ses i Brugervejledning til forespørgsler via DDS
Hentning af Forløbsplaner
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
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<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
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<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> |
Oprettelse af Forløbsplaner
Ændring af Forløbsplaner
Sletning af Forløbsplaner
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"
...
<Name>
<LocalizedString value="XDSDocumentEntry.patientId"/>
</Name>
</ExternalIdentifier>
<ExternalIdentifier registryObject="urn:uuid:ff4fa9c1-4c74-47ba-8eae-31b8acd7dd34" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="1.2.208.184^7ae3ed20-4401-11e9-b475-0800200c9a66" id="urn:uuid:5b53b0da-1002-4d11-80f2-f17baf41cdcd">
<Name>
<LocalizedString value="XDSDocumentEntry.uniqueId"/>
</Name>
</ExternalIdentifier>
</ExtrinsicObject>
</RegistryObjectList>
</ns3:AdhocQueryResponse>
|
Hentning af forløbsplaner
| Info |
|---|
Bemærk for at hente en forløbsplan på baggrund af en søgning, skal NSP's Service Deklaration: "Særlige begrænsninger ift. anvendelse af Dokumentdelingsservicen (DDS)" følges. Se: Dokumentdelingsservice (DDS) Opsummeret står der følgende: Der må højst være 10 minutter mellem disse kald (ITI-18 og ITI-43), begge kald skal udføres af samme bruger, og begge kald skal have samme (men unikke) ‘flowID’ |
Der er tre værdier fra retursvaret på ITI-18 forespørgslen som skal benyttes for at hente indholdet af en konkret Forløbsplan:
- HomeCommunityId - der beskriver det domæne dokumentet befinder sig i.
Værdien hentes ud fra ...ExtrinsicObject/@home
- RepositoryUniqueId - der bekriver den kilde under domænet der opbevarer dokumentet
Værdien hentes ud fra ...ExtrinsicObject/Slot[@name=’repositoryUniqueId’]/Value List/Value
- DocumentUniqueId - der identificerer selve dokumentet
Værdien hentes ud fra ...ExtrinsicObject/ExternalIdentifier[@identificationScheme=’urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab]/@value
Ud fra disse værdier 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
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<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>1.2.208.184^e23d1b0d-f4cc-4b3e-9973-b2a499aa15ba</DocumentUniqueId>
</DocumentRequest>
</RetrieveDocumentSetRequest> |
Det svar der returneres, er patientens Forløbsplan indeholdende de dataelementer, der er beskrevet i CPD v.2.0.0.
Bemærk at selve bodydelen af Forløbsplanen skal hentes ud som en mime attachement:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<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>
<RepositoryUniqueId>1.2.208.176.43210.8.20.11</RepositoryUniqueId>
<DocumentUniqueId>1.2.208.184^e23d1b0d-f4cc-4b3e-9973-b2a499aa15ba</DocumentUniqueId>
<mimeType>text/xml</mimeType>
<Document>
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:37b3a03a-70c8-45ea-9be5-bbaec58de49a-128338@urn%3Aihe%3Aiti%3Axds-b%3A2007"/>
</Document>
</DocumentResponse>
</RetrieveDocumentSetResponse> |
Oprettelse af forløbsplaner
Det er den praktiserende læge, som opretter borgerens Forløbsplan, hvorefter den udstilles via PLSP Indeks.
| Info |
|---|
Det er ikke muligt for andre parter, end de praktiserende læger, at oprette Forløbsplaner. |
Ændring af forløbsplaner
PLSP Indeks udstiller Forløbsplaner som en dynamisk (on-demand) dokumentkilde. Det betyder, at det altid er den sidste opdaterede Forløbsplan som hentes.
| Info |
|---|
Det er ikke muligt for andre parter, end de praktiserende læger, at ændre Forløbsplaner. |
Sletning af forløbsplaner
Det er praktiserende læge, som sletter borgerens Forløbsplan, hvorefter den ikke længere udstilles via PLSP Indeks.
| Info |
|---|
Det er ikke muligt for andre parter, end de praktiserende læger, at slette en borgers Forløbsplaner. |
Sikkerhed, roller og rettigheder
For adgang til Aftaleoversigten Forløbsplaner skal der for sundhedspersoner eksistere et gyldigt SOSI-ID-kort som . Dette er signeret af NSP'ens Secure Token Service, dokumentationen .Dokumentationen for SOSI-ID-kort og STS ligger under: Anvenderguide til STS
Sundhedsfaglige Sundhedspersoner, med en sundhedsfaglig autorisation har adgang til Aftaleoversigten. Sundhedspersoner uden sundhedsfaglig autorisation skal have tilknyttet en rettighed før disse de 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.
- og rettighedsstyring.
Følgende roller anvendes i forbindelse med Forløbsplaner.
Rollenavn | Rettighed | Notation som indsættes i SOSI IdKort ved udstedelse |
nspSundAssistR2 | Giver ret til at læse til Forløbsplaner 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)) | |
Rollenavn | Rettighed | Notation som indsættes i SOSI IdKort ved udstedelse |
nspSundAssistR2 | Giver ret til at læse til Forløbsplaner | urn:dk:healthcare:national-federation-role:code:41002:value:SundAssistR2
|
En sundhedsperson sundhedsfaglig uden sundhedsfaglig autorisation kan ikke have tilknyttet flere roller på samme tid - , dette skal administreres via den lokale identifikations- og rettighedsstyring , 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
Spærring
.
Ansvaret for at tildele rettigheder til sundhedsfaglige uden sundhedsfaglig autorisation ligger hos de enkelte parter. Parterne skal ligeledes via deres eget rolle/rettighedssystem kunne styre om sundhedsfaglige, uden sundhedsfaglig autorisation, skal have adgang til Forløbsplaner.
For yderligere information se Administrative forudsætninger #Brugerstyring/trust
Håndtering af frabedelse og fuldmagt
Frabedelse af deling af sundhedsdata
Borgeren kan have frabedt sig deling af at data, herunder Forløbsplaner, 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 dokumenterDokumenter med frabedelse). Det betyder at borgeren enten har spærret for frabedt sig deling af Aftaler data til den specifikke sundhedsperson, for Aftaler data i et givet tidsrum, for Aftaler data fra bestemte organisationer, eller i en kombination af disse. Klienten skal håndtere at der er angivet en spærringfrabedelse, og give sundhedspersonen mulighed for at få adgang til den fulde Aftaleoversigt Forløbsplaner under specielle vilkår. , se forretningsregel #6 under: Forretningsregler for Forløbsplaner
For adgang til spærrede Aftaler data, hvor der er lavet en frabedelse på, kan klienten enten angive at der ønskes foretaget 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 frabedelse er tilsidesat. Klienten skal samtidig angive årsagen (Eksempelvis: eksplicit samtykke fra patienten for at få adgang til data) til at spærringen frabedelsen er tilsidesat i eget journalsystem, da der kan forventes at være opfølgning på tilsidesatte spærringerfrabedelser.
Yderligere information omkring spærring frabedelse af deling af sundhedsdata og forespørgsler via dokumentdeling kan ses i Brugervejledning til forespørgsler via DDSi Brugervejledning til forespørgsler via DDS. Eksempel påITI-18 fejlsvar for dokumenter der er lavet frabedelse på:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<rs:RegistryError codeContext="urn:dk:nsi:Consent Filter Applied" errorCode="XDSRegistryError" severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/> |
Fuldmagt
Patientportaler Borgerportaler kan give patienternes borgernes 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 denne funktionalitet endnu. Fuldmagter er i stedet etableret via en trust-løsning hvor patientportalen borgerportalen selv håndterer kontrol af fuldmagter.
Information angående angivelse af fuldmagter via dokumentdelingsservicen, kan ses i HSUID header dokumentation.
Ændringslog
| Version | Dato | Ændret | Ændret af |
|---|---|---|---|
| 2.0.1 | 2025-09-01 | Tilrettet "døde" links | SDS |
| 2.0 | 2025-06-26 | Ny version publiceret | SDS |
Historisk log
| 1.0.1 | 2025-03-24 | Spærring ændret til frabedelse | SDS |
| 1.0 | 2023-09-14 | Version oprettet | SDS |
624 x 461