Dokumentdeling gør det muligt for aktører sundhedsvæsnet at dele relevante data om borgere, og dermed skabe et overblik over den enkelte borgers situation for de aktører som har brug for dette. Det kan være dem, som planlægger og gennemfører behandlingsforløb eller for borgerens selv og omsorgspersoner. Samtidig skal det være muligt for borgeren at bestemme, hvem han/hun vil dele disse data med gennem samtykke samt se, hvem der har læst data via MinLog. Infrastrukturen der muliggør deling af dokumenter på tværs af sundhedsaktører er baseret på IHE XDS standarden
Dette dokuments fokus er selve dokumentdelingen; dens dele, dens infrastruktur og hvordan man kommer igang med at anvende den som eksempelvis udvikler, der skal udvikle systemer der skal anvende den.
Der forventes et hvis kendskab til CDA dokumenter - da fokus ikke er disse, ligesom kendskab til anvendelse af DGWS, NSP og SDN forventes. Hjælpe moduler som MinSpæring, MinLog og andre komponenter, der er i spil i forbindelse med dokumentdeling berøres heller ikke andet overfladisk.
Data i en XDS infrastruktur gemmes som dokumenter. Et dokument har et unikt id (documentId) og en række metadata, der beskriver, hvad dokumentet handler om. Dokumenter kan indholdsmæssigt være af flere forskellige typer: PDF, Word-dokument, men kan også være af typen CDA (Clinical Document Architecture). Et CDA dokument er egentlig bare et struktureret XML dokument, der følger en bestemt standard for kliniske dokumenter til udveksling (deling). Se f.eks. What is HL7 CDA? for en kort beskrivelse. Her kan man bl.a. se, at CDA findes på forskellige niveauer 1-3, hvor 3 har den højeste grad af struktur.
En vigtig egenskab ved CDA dokumenter er den fælles CDA header. Denne header indeholder information, der går igen henover alle typer af kliniske dokumenter f.eks. hvilken patient drejer dokumentet sig om, hvilken organisation er ansvarlig (ejer) af dokumentet mm. CDA headeren er således en international standard (HL7), men der findes en dansk specialisering af denne (standardiseret i regi af Medcom). Denne er beskrevet her HL7 Implementation Guide for CDA Release 2.0 CDA Header (DK CDA Header). Medcom vedligeholder en liste over tilladte værdi sæt for metadata, som findes her DK-IHE_Metadata-Common_Code_systems-Value_sets.
Der findes andre profiler, der er specialiseringer af CDA. Dvs. kliniske dokumenter, der har en struktur til bestemte formål. Medcom har leveret danske profileringer af følgende typer (se evt. Medcoms oversigt over HL7 standarder):
Oprindelig var det aftaledokumenter (APD) som blev delt på NSP platformen. Men det har ændret sig, så også de andre dokumenttyper er kommet i spil. Alle dokumenterne på NSP er CDA dokumenter for nuværende. Og de skal alle overholde Medcoms profiler nævnt ovenfor.
Der er to typer af CDA dokumenter (angives også i metadata feltet type) .
XDS står for Cross-Enterprise Document Sharing og er en international standard udarbejdet af Integrating the Healthcare Enterprise (IHE) for udveksling af kliniske dokumenter. En XDS infrastruktur består (mindst) af følgende to komponenter:
Integrationen med XDS infrastrukturen sker vha en række standardiserede SOAP webservices - ITI kald. Et overblik over XDS infrastrukturen og de forskellige services ses nedenfor:
Når data skal deles vha XDS sker følgende:
IHE XDS standarden er specificeret i en række dokumenter:
Id | Beskrivelse | Link * |
---|---|---|
ITI TF-1 | Alle IHE profilerne beskrives. For NSP dokumentdeling er relevant afsnit
Man vil også kunne finde brugbar information i flere af appendixerne. | IHE IT Infrastructure Technical Framework Volume 1 (ITI TF-1) Integration Profiles (Revision 17.0 – Final Text) |
ITI TF-2 | Hvert ITI håndtag beskrives med definition, information som overføres og begrænsninger Hvilket afsnit, som er relevant afhænger af hvilke ITI håndtag man skal implementere. Skal man lave fremsøgning (ITI-18) vælges afsnit "3.18 Registry Stored Query [ITI-18]" | IHE IT Infrastructure (ITI) Technical Framework, Volume 2 Revision 18.0, July 30, 2021 – Final Text |
ITI TF-3 | Her beskrives metadata ved dokumentdeling. For NSP dokumentdeling er relevant afsnit
| IHE IT Infrastructure (ITI) Technical Framework, Volume 3 Revision 18.0, July 30, 2021 – Final Text |
ITI TF-Metadata | Her beskrives Opdatering af metadata, som endnu ikke er med i den udgivne specifikation. Dokumentet indeholde de dele, som med tiden skal flettes ind i 1-3 ovenfor. Hvis man skal implementere opdatering af metadata (ITI-57) kan følgende afsnit være relevante:
| IHE IT Infrastructure Technical Framework Supplement 10 XDS Metadata Update 15 Rev. 1.12 – Trial Implementation July 2, 2021 |
(*revision og dato matcher versionen da link indsat) |
Hvis man skal igang med dokumentdeling, og ingen kendskab har til ovenstående specifikationer, kan en tilgang være:
På NSP består dokumentdelings infrastrukturen af følgende komponenter.
TODO
<< oversigtstegninger over komponenter og iti interaktioner - tag kopi fra aftaledeling: Aftaler - justser med (+SFSK og -backends)?? >> I den tegning for dokumentdeling er det DDS Repo+Registry+DRS+DROS+SFSK, der er relevante (diverse backends skal ikke dokumenteres her). Skrive "udløbsdato" for DRS.
<< liste og forklaring af tegning inkl links til anvender guide for de forskellige >>
husk at placere hjælpe moduler og nævne at det får man med
nævne flere miljøer med denne konfig, og ref'e til test link nedenfor
Minlog, behandlingsrelationer, minSpærring (filter) og værdispring
Komponenterne i dokumentdelings infrastrukuren kommunikerer med ITI kald, som er standardiserede SOAP services, der skal overholde IHE XDS specifikationen. De er i det såkaldte XML basererede "RIM format"
Det er op til anvenderen/udvikleren selv at vælge platform og frameworks, der passer til resten af dennes løsning. Fra et udvikler perspektiv kan man enten vælge selv at generere stubkode udfra de standardiserede WSDL filer eller at anvende et tredjepartsprodukt. Nedenfor gives et forslag til, hvordan det kan gribes an med tredjepartsproduktet IPF Open eHealth Integration Platform, som forudsætter man arbejder på en java platform. Andre platforme kan have tilsvarende værktøjer og muligheder.
Da dokumentdelingen kører på NSP og sundhedsdatanettet (SDN) skal man anvende Den gode Web Service og have adgang til SDN for den del af miljøerne. Dette beskrives ikke yderligere her.
Man behøver ikke at basere alting på Camel, men kan med fordel nøjes med at inkludere biblioteket IPF Commons IHE XDS i sin kodebase. Her findes både stubbe og en masse anvendelige utilities. Disse kan blandt andet mappe fra RIM formatet (specificeret af IHE XDS standarden), til en en "OpeneHealth core model", som er java klasser. Og gør det at udvikle ITI kald lettere at arbejde med.
Helt overordnet kan det at lave et ITI kald deles op i følgende trin
Dette kan illustreres ved følgende transformeringsdiagram, hvor man ser core modellen blive transformateret til RIM formatet og efterfølgende et ITI kald udført. Resultatet af ITI kaldet kommer tilbage i RIM format, og transformeres til core modellen:
Et eksempel på, hvordan forskellen mellem core model og RIM format kommer til udtryk, ses her for håndtering af confidentiality code og CPR nummer i forbindelse med oprettelse af et dokument.
Først OpeneHealth core model, den kode man skriver i sit program:
documentEntry.getConfidentialityCodes().add(new Code("N", new LocalizedString("N"), "2.16.840.1.113883.5.25")); AssigningAuthority patientIdAssigningAuthority = new AssigningAuthority("1.2.208.176.1.2"); Code patientCode = new Code("2512489996", new LocalizedString("CPR"), "1.2.208.176.1.2"); documentEntry.setPatientId(new Identifiable(patientCode, patientIdAssigningAuthority)); |
Og her tilsvarende RIM format, som openeHealth oversætter det til og som anvendes ved ITI kaldet:
<ns2:Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="urn:uuid:69d3b9f3-7919-40e0-8731-32fb339216c2" nodeRepresentation="N" id="urn:uuid:9068bc2b-1717-4337-abfb-027f303b20c6"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.5.25</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="N"/> </ns2:Name> </ns2:Classification> <ns2:ExternalIdentifier registryObject="urn:uuid:69d3b9f3-7919-40e0-8731-32fb339216c2" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="2512489996^^^&1.2.208.176.1.2&ISO" id="urn:uuid:6dc240d8-d871-4df1-b8c6-3414f1415022"> <ns2:Name> <ns2:LocalizedString value="XDSDocumentEntry.patientId"/> </ns2:Name> </ns2:ExternalIdentifier> |
Når man arbejder med OpeneHealth core model er der nogle centrale klasser/objekter man arbejder med. 3 af dem er SubmissionSet, DocumentEntry og Relation:
(Simplificert figur efter figur 4.1-1 i ITI TF-3. Da man på NSP ikke arbejder med folders er disse elementer udeladt)
Man anvender submissionSet når man sender data ind (dvs ikke til søgninger). Et submissionSet pakker et kald ind. Indholdet af et submissionSet er documententries og associations. Opretter man nye dokumenter, vil der i et submissionset være en eller flere documentEntries (et for hvert dokument) og tilsvarende antal "SE-DE HasMember" associationer. Tilsvarende gælder for ret dokument. Men her vil der yderligere være en "Relationship" association af typen "replace". Sletter (deprecate) man et dokument, har man ikke en documentEntry, men en "Relationship" association af typen "update availability status".
Når man opretter et documentEntry skal der sættes et entryUuid på. Dette id er vigtigt, da det anvendes i forbindelse med senere ret og slet (deprecate) af dokumentet. Det skal have prefix "urn:uuid:" for at være et entryUuid, ellers vil det blive opfattet som et symbolsk id, og den kaldte komponent vil selv tildele et gyldigt entryUuid.
Når man udfylder documentEntry med metadata skal man huske de førnævnte CDA standarder. Er der tale om et stable dokument, kan man overveje, om man ikke med fordel kan hente meget af metadata informationen fra dokumentet selv, ved at deserialisere det.
I forbindelse med, at man opretter associationer, skal der angives en source og target entryuuid, udover associationens egen entryUuid. Her gælder
På NSP er der 3 forskellige måder at lave en fremsøgning på:
Når man laver en fremsøgning med ITI-18, kan man få to typer af objekter tilbage, baseret på den retur type man sætter i kaldet.
En måde at fremsøge meget store datamængder på, kan derfor laves med først en fremsøgning retur type ObjektRef og efterfølgende anvende disse værdier til at lave en GetDocuments med retur typen LeafClass.
TODO: to versoiner af søgnings beskrivelse: en hvor søgning 2 udelades, og objektref resultat
problem: dds kan ikke filterer i forhold til spæringer og er det ok?
Det følgende er eksempelkode til at illustrere et ITI-41 kald til oprettelse af et dokument
// Nyt kald/request ProvideAndRegisterDocumentSet provideAndRegisterDocumentSet = new ProvideAndRegisterDocumentSet(); // Opret documentEntry DocumentEntry documentEntry = new DocumentEntry(); AssigningAuthority patientIdAssigningAuthority = new AssigningAuthority("1.2.208.176.1.2"); // OID for CPR registret Identifiable patientIdentifiable = patientIdentifiable = new Identifiable("2512489996", patientIdAssigningAuthority); documentEntry.setPatientId(patientIdentifiable); ... mere metadata, se CDA profilen // Tilføj dokumentet til request provideAndRegisterDocumentSet.getDocuments().add(new Document(documentEntry, new DataHandler(new ByteArrayDataSource(documentPayload.getBytes(), documentEntry.getMimeType())))); // Opret SubmissionSet provideAndRegisterDocumentSet.setSubmissionSet(createSubmissionSet(documentEntry.getPatientId(), contentTypeCode, submissionTime)); // Opret association mellem SubmissionSet og DocumentEntry provideAndRegisterDocumentSet.getAssociations().add(createAssociation(submissionSet, documentEntry)); // Transformer request - dette laver core model om til RIM format ProvideAndRegisterDocumentSetTransformer registerDocumentSetTransformer = new ProvideAndRegisterDocumentSetTransformer(ebXMLFactory); EbXMLProvideAndRegisterDocumentSetRequest30 ebxmlRequest = (EbXMLProvideAndRegisterDocumentSetRequest30) registerDocumentSetTransformer.toEbXML(provideAndRegisterDocumentSet); ProvideAndRegisterDocumentSetRequestType provideAndRegisterDocumentSetRequestType = ebxmlRequest.getInternal(); // Udfør kald RegistryResponseType registryResponse = iti41PortType.documentRepositoryProvideAndRegisterDocumentSetB(provideAndRegisterDocumentSetRequestType); // Transformer response - dette laver RIM format til core model ResponseTransformer responseTransformer = new ResponseTransformer(ebXMLFactory); Response response = responseTransformer.fromEbXML(new EbXMLRegistryResponse30(registryResponse)); // Aflæs kaldets svar if (response.getStatus().equals(Status.SUCCESS)) { // Kaldet gik godt } else if (response.getStatus().equals(Status.PARTIAL_SUCCESS) || response.getStatus().equals(Status.FAILURE)) { // Der er warning eller fejl i kaldet, håndter dem for (ErrorInfo error : response.getErrors()) { } } |
(Det er flere detaljer omkring ITI-41 eksempelkode i anvender guiden til DROS.)
Et tilsvarende eksempel for ITI-18 fremsøgning kunne se således ud:
// Nyt kald/request FindDocumentsQuery findDocumentsQuery = new FindDocumentsQuery(); // Opret søge kriterier AssigningAuthority patientIdAssigningAuthority = new AssigningAuthority("1.2.208.176.1.2"); // OID for CPR registret Identifiable patientIdentifiable = patientIdentifiable = new Identifiable("2512489996", patientIdAssigningAuthority); findDocumentsQuery.setPatientId(patientIdentifiable); // angiv patienten dokumenterne vedrører List<AvailabilityStatus> searchStatusList = new LinkedList<AvailabilityStatus>(); searchStatusList.add(AvailabilityStatus.APPROVED); findDocumentsQuery.setStatus(searchStatusList); // søg efter dokumenter, som har status approved findDocumentsQuery.getServiceStartTime().setFrom(serviceStartTimeFrom); // søg efter specifik dato interval som start tidspunkt findDocumentsQuery.getServiceStartTime().setTo(serviceStartTimeTo); // ved at angive fra og til serviceStartTime QueryRegistry queryRegistry = new QueryRegistry(findDocumentsQuery); queryRegistry.setReturnType(QueryReturnType.LEAF_CLASS); //returner fuld metadata for de fremsøgte dokumenter // Transformer request - dette laver core model om til RIM format QueryRegistryTransformer requestTransformer = new QueryRegistryTransformer(); EbXMLAdhocQueryRequest30 ebxmlRequest = (EbXMLAdhocQueryRequest30) requestTransformer.toEbXML(queryRegistry); AdhocQueryRequest adhocQueryRequest = ebxmlRequest.getInternal(); // Udfør kald AdhocQueryResponse adhocQueryResponse = iti18PortType.documentRegistryRegistryStoredQuery(adhocQueryRequest); // Transformer response - dette laver RIM format til core model QueryResponseTransformer responseTransformer = new QueryResponseTransformer(ebXMLFactory); EbXMLQueryResponse ebXML = new EbXMLQueryResponse30(adhocQueryResponse); QueryResponse queryResponse = responseTransformer.fromEbXML(ebXML); // Aflæs kaldets svar if (queryResponse.getStatus().equals(Status.SUCCESS)) { // Kaldet gik godt, håndter de fremsøgte dokumenter metadata for (DocumentEntry documentEntry : queryResponse.getDocumentEntries()) { } } else if (queryResponse.getStatus().equals(Status.PARTIAL_SUCCESS) || queryResponse.getStatus().equals(Status.FAILURE)) { // Der er warning eller fejl i kaldet, håndter dem for (ErrorInfo error : queryResponse.getErrors()) { } } |
Sammenholder man ovenståede kodeekspempler kan man genkende ovenstående transformeringsfigurs kasser i kodelinierne. Eksempelvis for ITI-41 kaldet, hvor line 1-18 svarer til boks 2 (core model), linie 20-23 til boks 2 og 3 (core model og RIM format), linie 26 til kaldet mellem boks 3 (RIM format) og NSP komponenten, linie 28-30 til boks 3 og 2 (RIM format og core model) samt linie 32-40 til boks 2 (core model)
Savner man inspiration til kodeeksempler er også integrationstestene til f.eks. DROS og NXRG et godt sted at kigge.
Et eksempel på ITI-41 request og response ses nedenfor.
--------------------------- ID: 4 Address: https://dros-url/dros/iti41 Encoding: UTF-8 Http-Method: POST Content-Type: multipart/related; type="application/xop+xml"; boundary="uuid:2f4c8aeb-3158-4730-acaf-d113802064c9"; start="<root.message@cxf.apache.org>"; start-info="application/soap+xml" Headers: {Accept=[*/*]} Payload: --uuid:2f4c8aeb-3158-4730-acaf-d113802064c9 Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml" Content-Transfer-Encoding: binary Content-ID: <root.message@cxf.apache.org> Payload: <?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> .. soap headers fjernet for overskueligehed... </soap:Header> <soap:Body> <ns4:ProvideAndRegisterDocumentSetRequest xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns4="urn:ihe:iti:xds-b:2007" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"> <ns5:SubmitObjectsRequest> <ns2:RegistryObjectList> <ns2:ExtrinsicObject mimeType="text/xml" lid="8438472030670286734.7450729509229840524.1645439411709" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67"> <ns2:Slot name="creationTime"> <ns2:ValueList> <ns2:Value>20220221113011</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="languageCode"> <ns2:ValueList> <ns2:Value>da-DK</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="serviceStartTime"> <ns2:ValueList> <ns2:Value>20220221113011</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="serviceStopTime"> <ns2:ValueList> <ns2:Value>20220221113011</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="sourcePatientId"> <ns2:ValueList> <ns2:Value>2512489996^^^&1.2.208.176.1.2&ISO</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="sourcePatientInfo"> <ns2:ValueList> <ns2:Value>PID-5|Berggren^Nancy^Ann</ns2:Value> <ns2:Value>PID-7|19481225</ns2:Value> <ns2:Value>PID-8|F</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Dato og tidspunkt for møde mellem patient og sundhedsperson"/> </ns2:Name> <ns2:Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" nodeRepresentation="" id="urn:uuid:5d10bc50-f8fc-4209-9b5b-9ae7e3ec9c16"> <ns2:Slot name="authorInstitution"> <ns2:ValueList> <ns2:Value>DROS Testafdeling^^^^^&1.2.208.176.1.1&ISO^^^^12345679999</ns2:Value> </ns2:ValueList> </ns2:Slot> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" nodeRepresentation="001" id="urn:uuid:fc8d7a57-1ca4-492d-ab01-69306d007f09"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>1.2.208.184.100.9</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Klinisk rapport"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" nodeRepresentation="urn:ad:dk:medcom:appointmentsummary:full" id="urn:uuid:1ad9b3b9-163a-401d-9bb8-087b14fad7ab"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>1.2.208.184.100.10</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="DK Appointment Summary Document schema"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" nodeRepresentation="22232009" id="urn:uuid:9e659080-2238-43b7-bc6d-6705596e9451"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.6.96</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="hospital"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" nodeRepresentation="408443003" id="urn:uuid:4c1de4ab-f396-4d40-aa0f-5cd48e9fbf46"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.6.96</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="almen medicin"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" nodeRepresentation="39289-4" id="urn:uuid:e80eacf0-9047-47de-9d7a-7b37ae7fb749"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.6.1</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Follow-up (referred to) provider &or specialist, appointment date"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" nodeRepresentation="N" id="urn:uuid:4274843e-3550-4234-877b-9b70ed5ec1ef"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.5.25</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="N"/> </ns2:Name> </ns2:Classification> <ns2:ExternalIdentifier registryObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="ABCDE^^^&1.2.208.176.1.2&ISO" id="urn:uuid:90e4671c-fed6-4b01-9b23-efbdad59a90a"> <ns2:Name> <ns2:LocalizedString value="XDSDocumentEntry.patientId"/> </ns2:Name> </ns2:ExternalIdentifier> <ns2:ExternalIdentifier registryObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="8438472030670286734.7450729509229840524.1645439411709" id="urn:uuid:6d5fe954-401e-4e44-b9a7-ea69713d55fb"> <ns2:Name> <ns2:LocalizedString value="XDSDocumentEntry.uniqueId"/> </ns2:Name> </ns2:ExternalIdentifier> </ns2:ExtrinsicObject> <ns2:RegistryPackage status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="6610087827968212831.3203050515460410630.1645439455555"> <ns2:Slot name="submissionTime"> <ns2:ValueList> <ns2:Value>20220221113011</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Classification classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500" classifiedObject="6610087827968212831.3203050515460410630.1645439455555" nodeRepresentation="39289-4" id="urn:uuid:5901c10c-427c-4e9f-bd02-f722bbe682cc"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.6.1</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Follow-up (referred to) provider &or specialist, appointment date"/> </ns2:Name> </ns2:Classification> <ns2:ExternalIdentifier registryObject="6610087827968212831.3203050515460410630.1645439455555" identificationScheme="urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446" value="2512489996^^^&1.2.208.176.1.2&ISO" id="urn:uuid:455d6c19-04a8-4abc-86a7-b4610879f9bb"> <ns2:Name> <ns2:LocalizedString value="XDSSubmissionSet.patientId"/> </ns2:Name> </ns2:ExternalIdentifier> <ns2:ExternalIdentifier registryObject="6610087827968212831.3203050515460410630.1645439455555" identificationScheme="urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8" value="6610087827968212831.3203050515460410630.1645439455555" id="urn:uuid:d86cc2f3-726d-4e67-8d5b-65ddcb244607"> <ns2:Name> <ns2:LocalizedString value="XDSSubmissionSet.uniqueId"/> </ns2:Name> </ns2:ExternalIdentifier> <ns2:ExternalIdentifier registryObject="6610087827968212831.3203050515460410630.1645439455555" identificationScheme="urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832" value="6610087827968212831.3203050515460410630.1645439455555" id="urn:uuid:995d3638-f9b9-4cf7-99da-396b2c15b82c"> <ns2:Name> <ns2:LocalizedString value="XDSSubmissionSet.sourceId"/> </ns2:Name> </ns2:ExternalIdentifier> </ns2:RegistryPackage> <ns2:Classification classifiedObject="6610087827968212831.3203050515460410630.1645439455555" classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" id="urn:uuid:71497627-476c-492c-8dac-b1532e4fcdb0"/> <ns2:Association associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember" sourceObject="6610087827968212831.3203050515460410630.1645439455555" targetObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="d5d9f096-a2d2-4029-86cc-6a19e3af30e4"> <ns2:Slot name="SubmissionSetStatus"> <ns2:ValueList> <ns2:Value>Original</ns2:Value> </ns2:ValueList> </ns2:Slot> </ns2:Association> </ns2:RegistryObjectList> </ns5:SubmitObjectsRequest> <ns4:Document id="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67"> <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:5cc72a7d-d08c-4a24-aecb-ada368be561d-1@urn%3Aihe%3Aiti%3Axds-b%3A2007"/> </ns4:Document> </ns4:ProvideAndRegisterDocumentSetRequest> </soap:Body> </soap:Envelope> --uuid:2f4c8aeb-3158-4730-acaf-d113802064c9 Content-Type: text/xml Content-Transfer-Encoding: binary Content-ID: <5cc72a7d-d08c-4a24-aecb-ada368be561d-1@urn:ihe:iti:xds-b:2007> <ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" classCode="DOCCLIN" moodCode="EVN" xsi:schemaLocation="urn:hl7-org:v3 ../../PHMR/Schema/CDA_SDTC.xsd"> ... resten af dokumetet er fjernet for overskuelighed ... </ClinicalDocument> --uuid:2f4c8aeb-3158-4730-acaf-d113802064c9-- -------------------------------------- |
---------------------------- ID: 4 Response-Code: 200 Encoding: ISO-8859-1 Content-Type: multipart/related; type="application/xop+xml"; boundary="uuid:bd72b204-e4ba-4cc8-86a6-9f1a1b18adfe"; start="<root.message@cxf.apache.org>"; start-info="text/xml" Headers: {connection=[keep-alive], content-type=[multipart/related; type="application/xop+xml"; boundary="uuid:bd72b204-e4ba-4cc8-86a6-9f1a1b18adfe"; start="<root.message@cxf.apache.org>"; start-info="text/xml"], Date=[Mon, 21 Feb 2022 10:30:57 GMT], Server=[WildFly/8], transfer-encoding=[chunked], X-Powered-By=[Undertow/1]} Payload: --uuid:bd72b204-e4ba-4cc8-86a6-9f1a1b18adfe Content-Type: application/xop+xml; charset=UTF-8; type="text/xml" Content-Transfer-Encoding: binary Content-ID: <root.message@cxf.apache.org> <?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> ...soapheaders fjernet for overskuelighed ... </soap:Header> <soap:Body> <ns3:RegistryResponse xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns4="urn:ihe:iti:xds-b:2007" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/> </soap:Body> </soap:Envelope> --uuid:bd72b204-e4ba-4cc8-86a6-9f1a1b18adfe-- -------------------------------------- |
Et eksempel på ITI-18 request og LeafClass response ses nedenfor.
--------------------------- ID: 2 Address: http://localhost:8282/nxrg/iti18 Encoding: UTF-8 Http-Method: POST Content-Type: application/soap+xml Headers: {Accept=[*/*]} Payload: <?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:Header> .. soap headers fjernet for overskueligehed... </soap:Header> <soap:Body> <ns4:AdhocQueryRequest xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns5="urn:ihe:iti:xds-b:2007" xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"> <ns4:ResponseOption returnType="LeafClass" returnComposedObjects="true"/> <ns2:AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d"> <ns2:Slot name="$XDSDocumentEntryServiceStartTimeFrom"> <ns2:ValueList> <ns2:Value>17991231230940</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="$XDSDocumentEntryServiceStartTimeTo"> <ns2:ValueList> <ns2:Value>21991231230000</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="$XDSDocumentEntryPatientId"> <ns2:ValueList> <ns2:Value>'2512489996^^^&1.2.208.176.1.2&ISO'</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="$XDSDocumentEntryStatus"> <ns2:ValueList> <ns2:Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')</ns2:Value> </ns2:ValueList> </ns2:Slot> </ns2:AdhocQuery> </ns4:AdhocQueryRequest> </soap:Body> </soap:Envelope> -------------------------------------- |
---------------------------- ID: 2 Response-Code: 200 Encoding: UTF-8 Content-Type: application/soap+xml;charset=UTF-8 Headers: {connection=[keep-alive], content-type=[application/soap+xml;charset=UTF-8], Date=[Thu, 24 Feb 2022 14:16:00 GMT], transfer-encoding=[chunked]} Payload: <?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:Header> .. soap headers fjernet for overskueligehed... </soap:Header> <soap:Body> <ns6:AdhocQueryResponse xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns4="urn:ihe:iti:xds-b:2007" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" totalResultCount="4" status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"> <ns2:RegistryObjectList> <ns2:ExtrinsicObject mimeType="text/xml" lid="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49"> <ns2:Slot name="creationTime"> <ns2:ValueList> <ns2:Value>20220224110454</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="hash"> <ns2:ValueList> <ns2:Value>2fab5a7dedfd249cfb508083cf36c8e569558889</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="languageCode"> <ns2:ValueList> <ns2:Value>da-DK</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="serviceStartTime"> <ns2:ValueList> <ns2:Value>20220224110454</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="serviceStopTime"> <ns2:ValueList> <ns2:Value>20220224110454</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="repositoryUniqueId"> <ns2:ValueList> <ns2:Value>1.3.6.1.4.1.21367.2010.1.2.1125</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="size"> <ns2:ValueList> <ns2:Value>9758</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="sourcePatientId"> <ns2:ValueList> <ns2:Value>2512489996^^^&1.2.208.176.1.2&ISO</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="sourcePatientInfo"> <ns2:ValueList> <ns2:Value>PID-5|Berggren^Nancy^Ann</ns2:Value> <ns2:Value>PID-7|19481225</ns2:Value> <ns2:Value>PID-8|F</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Dato og tidspunkt for møde mellem patient og sundhedsperson"/> </ns2:Name> <ns2:VersionInfo versionName="1"/> <ns2:Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49" nodeRepresentation="" id="urn:uuid:5f7c3610-c1f4-44f1-b544-742ed42f3ef1"> <ns2:Slot name="authorInstitution"> <ns2:ValueList> <ns2:Value>DROS Testafdeling^^^^^&1.2.208.176.1.1&ISO^^^^12345679999</ns2:Value> </ns2:ValueList> </ns2:Slot> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49" nodeRepresentation="001" id="urn:uuid:e572f5b4-0559-45aa-97dd-ee49697a4655"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>1.2.208.184.100.9</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Klinisk rapport"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49" nodeRepresentation="urn:ad:dk:medcom:appointmentsummary:full" id="urn:uuid:7bc6487b-6a10-44a9-a144-dcb0212a329c"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>1.2.208.184.100.10</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="DK Appointment Summary Document schema"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49" nodeRepresentation="22232009" id="urn:uuid:37e11025-321c-4e6e-ad67-bc55d37e0bb3"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.6.96</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="hospital"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49" nodeRepresentation="408443003" id="urn:uuid:29247c9d-1242-48b6-a123-f3e09f27eee8"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.6.96</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="almen medicin"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49" nodeRepresentation="39289-4" id="urn:uuid:d1cf019c-ec5d-4c16-8d2a-5e881025e63a"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.6.1</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Follow-up (referred to) provider &or specialist, appointment date"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49" nodeRepresentation="N" id="urn:uuid:d9c4d97d-e178-4620-b302-26a1517aed11"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.5.25</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="N"/> </ns2:Name> </ns2:Classification> <ns2:ExternalIdentifier registryObject="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="2512489996^^^&1.2.208.176.1.2&ISO" id="urn:uuid:6a6213db-0c22-4eba-81cc-a84f8070ce8c"> <ns2:Name> <ns2:LocalizedString value="XDSDocumentEntry.patientId"/> </ns2:Name> </ns2:ExternalIdentifier> <ns2:ExternalIdentifier registryObject="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="5337666919438249367.1626114178725398396.1645697094506" id="urn:uuid:7d03b553-07a3-465e-a9ce-f33b113a8d4c"> <ns2:Name> <ns2:LocalizedString value="XDSDocumentEntry.uniqueId"/> </ns2:Name> </ns2:ExternalIdentifier> </ns2:ExtrinsicObject> <ns2:ExtrinsicObject mimeType="text/xml" lid="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8"> <ns2:Slot name="creationTime"> <ns2:ValueList> <ns2:Value>20220224110539</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="hash"> <ns2:ValueList> <ns2:Value>2fab5a7dedfd249cfb508083cf36c8e569558889</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="languageCode"> <ns2:ValueList> <ns2:Value>da-DK</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="serviceStartTime"> <ns2:ValueList> <ns2:Value>20220224110539</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="serviceStopTime"> <ns2:ValueList> <ns2:Value>20220224110539</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="repositoryUniqueId"> <ns2:ValueList> <ns2:Value>1.3.6.1.4.1.21367.2010.1.2.1125</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="size"> <ns2:ValueList> <ns2:Value>9758</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="sourcePatientId"> <ns2:ValueList> <ns2:Value>2512489996^^^&1.2.208.176.1.2&ISO</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="sourcePatientInfo"> <ns2:ValueList> <ns2:Value>PID-5|Berggren^Nancy^Ann</ns2:Value> <ns2:Value>PID-7|19481225</ns2:Value> <ns2:Value>PID-8|F</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Dato og tidspunkt for møde mellem patient og sundhedsperson"/> </ns2:Name> <ns2:VersionInfo versionName="1"/> <ns2:Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8" nodeRepresentation="" id="urn:uuid:0a9b33a3-44a5-4ae9-903e-dd8aa0b63268"> <ns2:Slot name="authorInstitution"> <ns2:ValueList> <ns2:Value>DROS Testafdeling^^^^^&1.2.208.176.1.1&ISO^^^^12345679999</ns2:Value> </ns2:ValueList> </ns2:Slot> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8" nodeRepresentation="001" id="urn:uuid:ab51c75f-80f1-40e5-9fe1-5894fef1d39b"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>1.2.208.184.100.9</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Klinisk rapport"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8" nodeRepresentation="urn:ad:dk:medcom:appointmentsummary:full" id="urn:uuid:1550549c-218f-480b-9f02-19935af27026"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>1.2.208.184.100.10</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="DK Appointment Summary Document schema"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8" nodeRepresentation="22232009" id="urn:uuid:6fae994a-30ad-494a-a561-36acc86bae87"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.6.96</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="hospital"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8" nodeRepresentation="408443003" id="urn:uuid:e0e5b026-16f2-4c6f-b263-60fac49aaa46"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.6.96</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="almen medicin"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8" nodeRepresentation="39289-4" id="urn:uuid:981af5cc-a0a1-43f6-946b-e5565f0f907d"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.6.1</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Follow-up (referred to) provider &or specialist, appointment date"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8" nodeRepresentation="N" id="urn:uuid:05e47fdb-03ce-49a7-b12a-e2d8f2f66437"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.5.25</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="N"/> </ns2:Name> </ns2:Classification> <ns2:ExternalIdentifier registryObject="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="2512489996^^^&1.2.208.176.1.2&ISO" id="urn:uuid:1462c579-d012-490f-a632-8b263e728a76"> <ns2:Name> <ns2:LocalizedString value="XDSDocumentEntry.patientId"/> </ns2:Name> </ns2:ExternalIdentifier> <ns2:ExternalIdentifier registryObject="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="7164729179900753373.5043326759312572816.1645697139139" id="urn:uuid:3f509092-5833-4e5b-bfc7-2b0c78e1ade2"> <ns2:Name> <ns2:LocalizedString value="XDSDocumentEntry.uniqueId"/> </ns2:Name> </ns2:ExternalIdentifier> </ns2:ExtrinsicObject> </ns2:RegistryObjectList> </ns6:AdhocQueryResponse> </soap:Body> </soap:Envelope> -------------------------------------- |
En tilsvarende søgning efter ObjectRef ville give følgende response:
ID: 2 Response-Code: 200 Encoding: UTF-8 Content-Type: application/soap+xml;charset=UTF-8 Headers: {connection=[keep-alive], content-type=[application/soap+xml;charset=UTF-8], Date=[Thu, 24 Feb 2022 14:12:50 GMT], transfer-encoding=[chunked]} Payload: <?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:Header> .. soap headers fjernet for overskueligehed... </soap:Header> <soap:Body> <ns6:AdhocQueryResponse xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns4="urn:ihe:iti:xds-b:2007" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" totalResultCount="2" status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"> <ns2:RegistryObjectList> <ns2:ObjectRef id="urn:uuid:a573c596-6cc4-40e4-85c2-529d2fbf6914"/> <ns2:ObjectRef id="urn:uuid:4a68ec73-f9c1-4a32-8b50-1c8d585f6590"/> </ns2:RegistryObjectList> </ns6:AdhocQueryResponse> </soap:Body> </soap:Envelope> |
TODO: find noget
https://www.iheusa.org/sites/iheusa/files/IHE%20Profiles%20for%20Health%20Information%20Exchange.pdf
https://groups.google.com/g/ihe-north-america-connectathon-2007/c/dLNk8mWoMVY
De følgende links kan alle bidrage til at lette arbejdet med at implementere dokumentdeling.
Værktøj | Beskrivelse | Link |
---|---|---|
DDS | Guide til anvendere
| https://www.nspop.dk/display/public/web/DDS+-+Guide+til+anvendere |
DROS | Guide til anvendere Når man skal skrive noget:
| https://www.nspop.dk/display/public/web/DROS+-+Guide+til+anvendere |
Aftaleoversigt | Siden beskriver de tekniske forretningsregler i forhold til at implementere Aftaleoversigten i et lokal fagsystem eller en borgerportal. | Aftaleoversigt |
Aftaler | Beskriver servicearkitekturen, der ligger bag deling af aftaler via NSP | https://www.nspop.dk/display/public/web/Aftaler |
Medcom CDA Viewer | Her kan man fremsøge, hente, oprette, rette og slette (deprecate) dokumenter på test1 og test2 Hvis man f.eks har lavet et ITI-41 kald til en service, og vil se at dokumentet blev registreret og gemt kan man fremsøge og hente det her. Skal man lave en ITI-18 fremsøgning kan man oprette dokumenter her først. Det er også muligt at downloade request og response (RIM format) ved de forskellige udførsler. Det kan anvendes til sammenligning med et ITI kald man sidder og udvikler på og som f.eks. driller. Adgang kræver login, kontakt Medcom | https://cdaviewer.medcom.dk/cdaviewer/ |
Medcom CDA Validator | Her findes en CDA validator der kan checke om et CDA dokument opfylder den danske profil. | https://cda.medcom.dk/ |
Medcom CDA builder/parser | Bibliotek der kan benyttes til at serialisere og deserialisere CDA dokumenter standardiseret af MedCom. | https://bitbucket.org/4s/4s-cda-builder/src/master/4s-cda-builders/ |
MedCom igang guide | Medcoms "kom godt igang med dokumentdeling" Beskrivelsen er mere bred end, den i dette her dokument og går også mere i detaljer på udvalgte punkter. | https://www.medcom.dk/media/10982/kom-godt-igang-med-dokumentdeling-14-interactive.pdf |