Page History
| Navitabs | ||||
|---|---|---|---|---|
| ||||
| Table of Contents |
|---|
*Dokumentationen af NSP services og komponenter på NSPOP omfatter udelukkende NSP produktionsmiljøet og ikke NSP’s øvrige miljøer. Det er muligt at få information og indblik i tilstanden på et af de øvrige miljøer via de gængse kommunikationsveje.
Indledning
Formål
Dokumentdeling gør det muligt for aktører sundhedsvæsnet i sundhedsvæsenet 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 borgeren selv og deres omsorgspersoner. Samtidig skal det være muligt for borgeren at bestemme, hvem han/hun vil dele disse data med gennem samtykke samtykkeservicen samt se, hvem der har læst data via MinLog. Infrastrukturen på NSP, 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 kommer i gang med at anvende den, som eksempelvis udvikler, der skal udvikle systemer, der skal anvende den.
Der forventes et hvis vist kendskab til CDA dokumenter - da fokus ikke er disse, ligesom kendskab til anvendelse af DGWS, NSP og SDN forventes for implementeringen. Hjælpe moduler Hjælpemoduler som MinSpæringSamtykkeService, MinLog MinLog2 og andre komponenter, der er i spil i forbindelse med dokumentdeling berøres heller ikke andet overfladisk.
Hvad er dokumenter
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: slags mht indhold og format. Eksempler er PDF, Word-dokument, men kan også være af typen dokument og XML. Et eksempel på et XML dokument er 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 Medcomden danske profilering af metadata). Denne er beskrevet her HL7 Implementation Guide for CDA Release 2.0 CDA Header (DK CDA Header). Medcom vedligeholder en XDS Metadata for Document Sharing. Danish profile. Der er en tilhørende liste over tilladte værdi sæt for metadata, som findes her DK-IHE_Metadata-Common_Code_systems-Value_sets.
Der findes andre flere 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 Hver af disse har deres egen kode værdi i metadata feltet typecode. Følgende er nogle af de danske profileringer (se evt. Medcoms oversigt over HL7 standarder):
- Appointment Document (APD) til aftaler
- Careplan (CPD)
- Personal Data Card/Stamkort (PDC)
- Personal Health Monitoring Report (PHMR) til hjemmemonitorering
- Questionnaire Form Definition Document (QFDD) og Questionnaire Response Document (QRD) til patientrapporterede oplysninger (PRO)
- Personal Health Attachment Document (PHAD) til psykiatriplaner
- Vandrejournal (PSCR), Svangerskabsjournal (PRF), Kliniske målinger (CMR) til graviditetsmappen
- Laboratoriesvar (LABSVAR)
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 De skal alle overholde Medcoms de danske profiler nævnt ovenfor.
Der er to typer af CDA dokumenter (angives også i metadata feltet type) .
- "Stable document" som bliver skabt og gemt en gang for alle
- "On-demand" som først skabes på det tidspunkt det faktisk efterspørges
Hvad er dokumentdeling
Hvad er dokumentdeling
XDS står for Cross-Enterprise Document Sharing og er en international standard udarbejdet af Integrating the Healthcare Enterprise (IHE) for 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:
- XDS Document Repository: Står for til persistering af dokumenter tilknyttet et unikt ID.
- XDS Document Registry: Står for til opbevaring og indexering indeksering af metadata vedr. dokumenterne i et eller flere XDS repositories. Dette Metadata kunne f.eks. være start- og sluttidspunkt dokumentet dækker over, eller dets forfatter (author) (oplysningerne stammer typisk fra CDA headeren)
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:
...
Der er to varianter af CDA dokumenter, som deles i infraskturen (angives også i metadata feltet type). De har hver deres servicehåndtag, som det fremgår nedenfor.
- "Stable document" som bliver skabt og gemt en gang for alle
- "On-demand" som skabes på det tidspunkt, det faktisk efterspørges, (gemmes ikke, men skabes hver gang)
Integrationen med XDS infrastrukturen sker vha. en række standardiserede SOAP webservices - ITI kald. Et overblik over en standard XDS infrastruktur og de forskellige services ses nedenfor:
Når data skal deles vha XDS er der følgende overordnede flows:
- Oprettelse af dokumenter:
- Dokumenter afleveres af dokumentkilden (Document Source) til XDS repository via servicehåndtaget ITI-41 Provide and Register Document Set. Herefter sørger XDS repository for at registrere dokumentet i XDS registry via servicehåndtaget ITI-42 Register Document Set.
- Hvis der er tale om et on-demand dokument registreres det af dokumentkilden (On Demand Document Source) direkte i XDS registry via servicehåndtaget ITI-61 Register On Demand Document Entry, da der ikke er et
- faktisk CDA dokument at gemme.
- Fremsøgning og hentning af dokumenter
- Dokumentaftager (Document Consumer) fremsøger dokumenter i XDS registry via servicehåndtaget ITI-18 Registry Stored Query. Svaret på denne query
- kan være en liste
- af metadata for de dokumenter, som matcher søgningen. Et af felterne er repositoryId, der fortæller
- ,
- hvor
- dokumentet kan findes.
- Dokumentaftager (Document Consumer) henter dokument i XDS repository via servicehåndtaget ITI-43 Retrieve Document Set
- Dokumentadministrator (Document Administrator) kan opdatere metadata (heriblandt slet (deprecate)ugyldiggøre) i XDS registry via servicehåndtaget ITI-57 Update Document Set.
- (Patient Identify Source som fremgår af figuren anvendes ikke på NSP), men er med i figuren da den indgår i standarden)
IHE IHE XDS standarden er specificeret i en række dokumenter:. Disse er listet i nedenstående tabel med links og en beskrivelse af, hvordan man med fordel kan navigere i dem.
| 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 I dette dokument 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 Dette dokument indeholder information omkring opdatering af metadata, som endnu ikke er med blevet indsat i den udgivne specifikation. Dokumentet indeholde indeholder 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 i gang med dokumentdeling, og ingen kendskab har til ovenstående specifikationerspecifikation, kan en tilgang være:
- Start med at skabe et overblik over documententry, associations og submissionsest - f.eks. i "ITI TF-3 afsnit 4.1 Abstract Metadata Model". Det er de objekttyper, man primært taler om i standarden og datamodellen man bør forstå.
- Læs derefter omkring de forskellige kald nævnt ovenfor:
- ITI-41 til oprettelse/ret af dokumenter - ITI TF-2 afsnit "3.41 Provide and Register Document Set-b [ITI-41]"
- ITI-18 fremsøgning af dokumenter : ITI TF-2 afsnit "3.18 Registry Stored Query [ITI-18]"
- ITI-43 hent af dokumenter: ITI TF-2 afsnit "3.43 Retrieve Document Set [ITI-43]"
NSP Arkitekturoversigt af komponenter
På NSP består dokumentdelings infrastrukturen dokumentdelingsinfrastrukturen af følgende komponenter.TODO:
| Gliffy Diagram | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
<< 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
Hvordan kommer man igang
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.
OpeneHealth biblioteket til Java
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
- Opret kald i OpeneHealth coree model
- For ITI41 kald indebærer det blandt andet opret/indlæs af dokument samt opret af metadata til documententry
- For ITI42, 57 og 61 indebærer det oprettelse af metadata
- For ITI18 skal søge kriterierne sættes op
- For ITI43 skal dokumentiderne sættes op
- Udfør kald - det transformeres til RIM format på vej ud, og tilbage til core model ved returnering vha. openeHealth frameworket
- Aflæs kaldets svar og håndter eventuelle fejl returneret. For ITI-18 og ITI-43 er der ligeledes dokument id'er henholdsvis dokumenter, der skal håndteres.
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:
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
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:
| Code Block | ||||
|---|---|---|---|---|
| ||||
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:
|
- DROS (anvenderguide) anvendes til skrive aktiviteterne:
- Oprettelse af nye dokumenter (ITI-41 Provide and Register Document Set) sker fra anvendersystemerne. DROS lagrer det oprettede dokument i det bagvedliggende nationale XDS Repository. I forbindelse med oprettelsen sørger det nationale XDS Repository for at få indexeret dokumentet og dets metadata i det nationale XDS Registry (ITI-42 Register Document Set).
- Oprettelse af et dokument, som en opdatering til et eksisterende dokument (ITI-41 Provide and Register Document Set). Her ugyldiggøres det eksisterende/gamle dokument.
- Ugyldiggøre (deprecate) et dokument eller opdatering af et dokument (ITI-57: Update Document Set)
- Registrering af On-Demand dokumenter (ITI-61 Register On-Demand Document Entry)
- Registrering af Stable dokumenter (ITI-42 Register Document Set). Dette anvendes, hvis man selv ejer et repository, men anvender det nationale registry til indeksering. Et eksempel på dette er KIH databasen, som indeholder hjemmemålinger (PHMR) og spørgeskemaer (QRD) .
- DokumentDelingsServicen (DDS registry) (anvenderguide) anvendes til fremsøgning af dokumenter (ITI-18 Registry Stored Query) hvor der blandt andet kigges i
- det Nationale XDS Registry
- Svareksponeringsservice XDS Registry Adapter. Der delegerer søgninger videre til Svareksponeringsservicen efter laboratoriesvar
- DokumentDelingsServicen (DDS repository) (anvenderguide) anvendes til at hente dokumenter (ITI-43 Retrieve Document Set) fra repositories som
- det Nationale XDS Repository
- Svareksponeringsservice XDS Repository Adapter. Der delegerer hentning af laboratoriesvar videre til Svareksponeringsservicen
- KIH databasen
- Graviditetsmappe On-Demand repository
- Søgning af Fælles StamKort (SFSK) (anvenderguide) er til at fremsøge (ITI-18 Registry Stored Query) og hente (ITI-43 Retrieve Document Set) Fælles Stamkort vha system idkort . Dette er on-demand dokumenter, som skabes ud fra en række bagvedliggende stamdata services.
- Læse servicene i DDS registry/ DDS repository gør brug at hjælpe komponenterne SamtykkeService, BehandlerRelationsService og MinLog2 for at sikre borgerens rettigheder. Se evt. DDS anvenderguide for mere beskrivelse.
- Læse servicene i SFSK gør brug at hjælpe komponenterne BehandlerRelationsService og MinLog2 for at sikre borgerens rettigheder.
Ovenstående infrastruktur findes i flere versioner/miljøer. Eksempelvis findes miljøerne test1, test2, prodtest og produktion. Og f.eks. findes DROS i versionerne "Aftaler" og "Graviditetsmappe".
Hvordan kommer man i gang
Komponenterne i dokumentdelings infrastrukturen kommunikerer med ITI kald, som er standardiserede SOAP services, der skal overholde IHE XDS specifikationen - 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 ud fra 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.
De metadata, man registrerer om dokumentet, skal ligesom CDA headeren, overholde de danske standarder XDS Metadata for Document Sharing. Danish profile og DK-IHE_Metadata-Common_Code_systems-Value_sets.
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.
OpeneHealth biblioteket til Java
Man kan med fordel 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 den IHE XDS standard specificerede RIM format, 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
- Opret kald i OpeneHealth core model
- For ITI41 kald indebærer det blandt andet opret/indlæs af dokument samt opret af metadata til senere fremsøgning
- For ITI42, 57 og 61 indebærer det registrering og indeksering af metadata
- For ITI18 skal søgekriterierne angives
- For ITI43 skal dokumentid'erne angives
- Udfør kald - det transformeres til RIM format på vej ud, og tilbage til core model ved returnering vha. openeHealth frameworket
- Aflæs kaldets svar og håndter eventuelle fejl returneret. For ITI-18 og ITI-43 er der ligeledes metadata/dokument id'er henholdsvis dokumenter, der skal håndteres.
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:
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
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:
| Code Block | ||||
|---|---|---|---|---|
| ||||
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:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<ns2:Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="urn:uuid:69d3b9f3-7919-40e0-8731-32fb339216c2" nodeRepresentation="N" id="urn:uuid | ||||
| Code Block | ||||
| ||||
<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> |
Vigtige Objekter og id'er
Når man arbejder med OpeneHealth core model, er der nogle centrale klasser/objekter man arbejder at beskæftige sig med. 3 af dem er SubmissionSet, DocumentEntry og RelationAssociation:
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
(Simplificert Simplificeret 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 skriver data ind (dvs ikke til søgninger). Et submissionSet pakker et kald ind. Indholdet af et submissionSet er documententries og associations. Opretter man Oprettes 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 Ugyldiggøres 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 ugyldiggørelse 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 udfyldes med metadata, skal man huske de førnævnte CDA standarder. Er der tale om et stable dokument, kan man overveje, om ikke man ikke med fordel kan hente meget af metadata informationen fra dokumentet selv (fra headeren), ved at deserialisere det.
I forbindelse med, at man opretter oprettelse af associationer, skal der angives en source og target entryuuid, udover associationens egen entryUuid. Her gælder
- For opret af dokumenter: source er submissionSet entryUuid og target er documentEntry 's entryUuid
- For ret; som for opret. Men den Den ekstra "replace" association: source er source nye dokuments dokumentEntry entryUuid og target det gamle dokumentdokumentEntry entryUuid
- For slet (deprecate)ugyldiggørelse: source er submissionSet entryUuid, og target er documentEntry entryUuid for det dokument, som skal slettesugyldiggøres
På NSP er der forskellige måder at lave en fremsøgning på:
- FindDocuments: Den traditionelle måde, hvor man opsætter en række søgekriterier som dato interval, dokument status, dokument type mm.
- GetDocuments: her fremsøges dokumenterne efter entryuuid eller uniqueid
Når man laver en fremsøgning med ITI-18, kan man få forskellige typer af objekter tilbage, baseret på den retur type man sætter i kaldet. NSP understøtter een:
- LeafClass: her returnes en liste af matchende documentEntry med fuld metadata
#Som søge funktionaliteten kunne/burde være#
På NSP er der 3 forskellige måder at lave en fremsøgning på:
- FindDocuments: Den traditionelle måde, hvor man opsætter en række søgekriterier som dato interval, dokument status, dokument type mm.
- FindDocuemensByReference: her søge efter dokumentreferencer, man måtte have sat på da dokumentet blev oprettet kombineret med andre almindelige søgekriteriertypekode mm.
- GetDocuments: her fremsøges dokumenterne efter entryuuid eller uniqueid
Når man laver en fremsøgning med ITI-18, kan man få to forskellige typer af objekter tilbage, baseret på den retur type man sætter i kaldet. NSP understøtter een:
- LeafClass: her returnes en liste af matchende documentEntry med fuld metadata
- ObjectRef: her returnes en liste af objekt referencer, som entryuuid
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: Afklaring omkring der skal gøres noget at det bliver som "kunne være". Der gælder 2 ting:
- DDS'en tillader ikke FindDocuemensByReference. Den findes i NXRG.
- DDS'en ser ikke ud til at tillade ObjectRef Og hvordan skal den kunne håndtere spæringer på den baggrund. Er det nødvendigt at spære for ID'er?
- indhold
Eksempler på kald
Det følgende er eksempelkode til at illustrere et ITI-41 kald til oprettelse af et dokument
...
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
// 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 Nærlæser man ovenstående kodeeksempler, kan man genkende ovenstående transformeringsfigurs kasser i kodelinierne. Eksempelvis for ITI-41 kaldet, hvor 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 Savnes 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.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
---------------------------
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-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:xsd:lcm:3.0StatusType:Approved" xmlns:ns4id="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">uuid:cfe0c274-170c-457e-8db4-978ef88cbc67">
<ns2:Slot name="creationTime">
<ns2:ValueList>
<ns2:Value>20220221113011</ns2:Value>
<ns5:SubmitObjectsRequest> </ns2:ValueList>
<ns2:RegistryObjectList> </ns2:Slot>
<ns2:ExtrinsicObjectSlot mimeTypename="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">languageCode">
<ns2:ValueList>
<ns2:Value>da-DK</ns2:Value>
</ns2:ValueList>
</ns2:Slot>
<ns2:Slot name="creationTimeserviceStartTime">
<ns2:ValueList>
<ns2:Value>20220221113011</ns2:Value>
</ns2:ValueList>
</ns2:Slot>
<ns2:Slot name="languageCodeserviceStopTime">
<ns2:ValueList>
<ns2:Value>da-DK<Value>20220221113011</ns2:Value>
</ns2:ValueList>
</ns2:Slot>
<ns2:Slot name="serviceStartTimesourcePatientId">
<ns2:ValueList>
<ns2:Value>20220221113011<Value>2512489996^^^&1.2.208.176.1.2&ISO</ns2:Value>
</ns2:ValueList>
</ns2:Slot>
<ns2:Slot name="serviceStopTimesourcePatientInfo">
<ns2:ValueList>
<ns2:Value>20220221113011<Value>PID-5|Berggren^Nancy^Ann</ns2:Value>
<<ns2:Value>PID-7|19481225</ns2:ValueList>Value>
< <ns2:Value>PID-8|F</ns2:Slot>Value>
</ns2:ValueList>
<ns2:Slot name="sourcePatientId">
</ns2:Slot>
<ns2:ValueList>Name>
<ns2:Value>2512489996^^^&1.2.208.176.1.2&ISO</ns2:Value>
</ns2:ValueList>LocalizedString xml:lang="en-US" charset="UTF-8" value="Dato og tidspunkt for møde mellem patient og sundhedsperson"/>
</ns2:Slot>Name>
<ns2:Slot name="sourcePatientInfo":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:ValueList>Slot name="authorInstitution">
<ns2:Value>PID-5|Berggren^Nancy^Ann</ns2:Value>ValueList>
<ns2:Value>PID-7|19481225</ns2:Value>
<ns2:Value>PID-8|F<<ns2:Value>DROS Testafdeling^^^^^&1.2.208.176.1.1&ISO^^^^12345679999</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"/>ValueList>
</ns2:Slot>
</ns2:Name>Classification>
<ns2:Classification classificationScheme="urn:uuid:93606bcf41a5887f-94948865-43ec4c09-9b4eadf7-a7748d1a838de362475b143a" classifiedObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" nodeRepresentation="001" id="urn:uuid:5d10bc50fc8d7a57-f8fc1ca4-4209492d-9b5bab01-9ae7e3ec9c1669306d007f09">
<ns2:Slot name="authorInstitutioncodingScheme">
<ns2:ValueList>
<ns2:Value>DROS Testafdeling^^^^^&1Value>1.2.208.176184.1100.1&ISO^^^^12345679999<9</ns2:Value>
</ns2:ValueList>
</ns2:Slot>
<ns2:Name>
</ns2:ValueList> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Klinisk rapport"/>
</ns2:Slot>Name>
</ns2:Classification>
<ns2:Classification classificationScheme="urn:uuid:41a5887fa09d5840-8865386c-4c0946f2-adf7b5ad-e362475b143a9c3699a4309d" classifiedObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" nodeRepresentation="001urn:ad:dk:medcom:appointmentsummary:full" id="urn:uuid:fc8d7a571ad9b3b9-1ca4163a-492d401d-ab019bb8-69306d007f09087b14fad7ab">
<ns2:Slot name="codingScheme">
<ns2:ValueList>
<ns2:Value>1.2.208.184.100.9<10</ns2:Value>
</ns2:ValueList>
</ns2:Slot>
<ns2:Name>
<ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Klinisk rapportDK Appointment Summary Document schema"/>
</ns2:Name>
</ns2:Classification>
<ns2:Classification classificationScheme="urn:uuid:a09d5840f33fb8ac-386c18af-46f242cc-b5adae0e-9c3699a4309ded0b0bdb91e1" classifiedObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" nodeRepresentation="urn:ad:dk:medcom:appointmentsummary:full22232009" id="urn:uuid:1ad9b3b99e659080-163a2238-401d43b7-9bb8bc6d-087b14fad7ab6705596e9451">
<ns2:Slot name="codingScheme">
<ns2:ValueList>
<ns2:Value>1Value>2.16.2840.2081.184113883.1006.10<96</ns2:Value>
</ns2:ValueList>
</ns2:Slot>
<ns2:Name>
<ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="DK Appointment Summary Document schemahospital"/>
</ns2:Name>
</ns2:Classification>
<ns2:Classification classificationScheme="urn:uuid:f33fb8accccf5598-18af8b07-42cc4b77-ae0ea05e-ed0b0bdb91e1ae952c785ead" classifiedObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" nodeRepresentation="22232009408443003" id="urn:uuid:9e6590804c1de4ab-2238f396-43b74d40-bc6daa0f-6705596e94515cd48e9fbf46">
<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="hospitalalmen medicin"/>
</ns2:Name>
</ns2:Classification>
<ns2:Classification classificationScheme="urn:uuid:cccf5598f0306f51-8b07975f-4b77434e-a05ea61c-ae952c785eadc59651d33983" classifiedObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" nodeRepresentation="40844300339289-4" id="urn:uuid:4c1de4abe80eacf0-f3969047-4d4047de-aa0f9d7a-5cd48e9fbf467b37ae7fb749">
<ns2:Slot name="codingScheme">
<ns2:ValueList>
<ns2:Value>2.16.840.1.113883.6.96<1</ns2:Value>
</ns2:ValueList>
</ns2:Slot>
<ns2:Name>
<ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="almen medicinFollow-up (referred to) provider &or specialist, appointment date"/>
</ns2:Name>
</ns2:Classification>
<ns2:Classification classificationScheme="urn:uuid:f0306f51f4f85eac-975fe6cb-434e4883-a61cb524-c59651d33983f2705394840f" classifiedObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" nodeRepresentation="39289-4N" id="urn:uuid:e80eacf04274843e-90473550-47de4234-9d7a877b-7b37ae7fb7499b70ed5ec1ef">
<ns2:Slot name="codingScheme">
<ns2:ValueList>
<ns2:Value>2.16.840.1.113883.65.1<25</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 dateN"/>
</ns2:Name>
</ns2:Classification>
<ns2:ClassificationExternalIdentifier classificationSchemeregistryObject="urn:uuid:f4f85eaccfe0c274-e6cb170c-4883457e-b5248db4-f2705394840f978ef88cbc67" classifiedObjectidentificationScheme="urn:uuid:cfe0c27458a6f841-170c87b3-457e4a3e-8db492fd-978ef88cbc67a8ffeff98427" nodeRepresentationvalue="NABCDE^^^&1.2.208.176.1.2&ISO" id="urn:uuid:4274843e90e4671c-3550fed6-42344b01-877b9b23-9b70ed5ec1efefbdad59a90a">
<ns2:Slot name="codingScheme">Name>
<ns2:ValueList>LocalizedString value="XDSDocumentEntry.patientId"/>
<ns2:Value>2.16.840.1.113883.5.25<</ns2:Value>Name>
</ns2:ValueList>ExternalIdentifier>
<ns2:ExternalIdentifier registryObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" </ns2:Slot>value="8438472030670286734.7450729509229840524.1645439411709" id="urn:uuid:6d5fe954-401e-4e44-b9a7-ea69713d55fb">
<ns2:Name>
<ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="NXDSDocumentEntry.uniqueId"/>
</ns2:Name>
</ns2:Classification>
ExternalIdentifier>
</ns2:ExtrinsicObject>
<ns2:ExternalIdentifierRegistryPackage registryObjectstatus="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-efbdad59a90aoasis:names:tc:ebxml-regrep:StatusType:Approved" id="6610087827968212831.3203050515460410630.1645439455555">
<ns2:Slot name="submissionTime">
<ns2:Name>ValueList>
<ns2:LocalizedString value="XDSDocumentEntry.patientId"/>Value>20220221113011</ns2:Value>
</ns2:Name>ValueList>
</ns2:ExternalIdentifier>Slot>
<ns2:ExternalIdentifier registryObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" identificationScheme<ns2:Classification classificationScheme="urn:uuid:2e82c1f6aa543740-a085bdda-4c72424e-9da38c96-8640a32e42abdf4873be8500" valueclassifiedObject="84384720306702867346610087827968212831.7450729509229840524.16454394117093203050515460410630.1645439455555" nodeRepresentation="39289-4" id="urn:uuid:6d5fe9545901c10c-401e427c-4e444e9f-b9a7bd02-ea69713d55fbf722bbe682cc">
<ns2:Name>Slot name="codingScheme">
<ns2:LocalizedString value="XDSDocumentEntry.uniqueId"/>
ValueList>
<<ns2:Value>2.16.840.1.113883.6.1</ns2:Name>Value>
</ns2:ExternalIdentifier>ValueList>
</ns2:ExtrinsicObject>Slot>
<ns2:RegistryPackage status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="6610087827968212831.3203050515460410630.1645439455555">
<ns2:Slot name="submissionTime">
Name>
<ns2:ValueList>
<ns2:Value>20220221113011</ns2:Value>LocalizedString xml:lang="en-US" charset="UTF-8" value="Follow-up (referred to) provider &or specialist, appointment date"/>
</ns2:ValueList>Name>
</ns2:Slot>Classification>
<ns2:Classification classificationSchemeExternalIdentifier registryObject="6610087827968212831.3203050515460410630.1645439455555" identificationScheme="urn:uuid:aa5437406b5aea1a-bdda874d-424e4603-8c96a4bc-df4873be850096a0a7b38446" classifiedObjectvalue="6610087827968212831.3203050515460410630.1645439455555" nodeRepresentation="39289-42512489996^^^&1.2.208.176.1.2&ISO" id="urn:uuid:5901c10c455d6c19-427c04a8-4e9f4abc-bd0286a7-f722bbe682ccb4610879f9bb">
<ns2:Slot name="codingScheme">
Name>
<ns2:ValueList>
<ns2:LocalizedString value="XDSSubmissionSet.patientId"/>
<ns2:Value>2.16.840.1.113883.6.1<</ns2:Value>Name>
</ns2:ValueList>ExternalIdentifier>
<ns2:ExternalIdentifier registryObject="6610087827968212831.3203050515460410630.1645439455555" </ns2:Slot>identificationScheme="urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8" value="6610087827968212831.3203050515460410630.1645439455555" id="urn:uuid:d86cc2f3-726d-4e67-8d5b-65ddcb244607">
<ns2:Name>
<ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Follow-up (referred to) provider &or specialist, appointment datevalue="XDSSubmissionSet.uniqueId"/>
</ns2:Name>
</ns2:Classification>ExternalIdentifier>
<ns2:ExternalIdentifier registryObject="6610087827968212831.3203050515460410630.1645439455555" identificationScheme="urn:uuid:6b5aea1a554ac39e-874de3fe-460347fe-a4bcb233-96a0a7b38446965d2a147832" value="2512489996^^^&16610087827968212831.2.208.176.1.2&ISO3203050515460410630.1645439455555" id="urn:uuid:455d6c19995d3638-04a8f9b9-4abc4cf7-86a799da-b4610879f9bb396b2c15b82c">
<ns2:Name>
<ns2:LocalizedString value="XDSSubmissionSet.patientIdsourceId"/>
</ns2:Name>
</ns2:ExternalIdentifier>
</ns2:RegistryPackage>
<ns2:ExternalIdentifierClassification registryObjectclassifiedObject="6610087827968212831.3203050515460410630.1645439455555" classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" identificationSchemeid="urn:uuid:96fdda7c71497627-476c-d067492c-4183-912e-bf5ee74998a8" value8dac-b1532e4fcdb0"/>
<ns2:Association associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember" sourceObject="6610087827968212831.3203050515460410630.16454394555551645439455555" targetObject="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67" idstatus="urn:uuid:d86cc2f3-726d-4e67-8d5b-65ddcb244607:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="d5d9f096-a2d2-4029-86cc-6a19e3af30e4">
<ns2:Name>
<ns2:LocalizedString value="XDSSubmissionSet.uniqueId"/Slot name="SubmissionSetStatus">
</ns2<ns2:Name>ValueList>
</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">Value>Original</ns2:Value>
<ns2</ns2:Name>ValueList>
</ns2:Slot>
<ns2:LocalizedString value="XDSSubmissionSet.sourceId"/> </ns2:Association>
</ns2:RegistryObjectList>
</ns2ns5:Name>SubmitObjectsRequest>
<ns4:Document id="urn:uuid:cfe0c274-170c-457e-8db4-978ef88cbc67">
</ns2:ExternalIdentifier><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>
</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 </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--
-------------------------------------- |
| Code Block | ||||
|---|---|---|---|---|
| ||||
---------------------------- 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> <ClinicalDocument xmlns2007" xmlns:ns3="urn:hl7-org:v3oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:xsins2="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> urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/> </soap:Body> </soap:Envelope> --uuid:2f4c8aebbd72b204-3158e4ba-47304cc8-acaf86a6-d113802064c99f1a1b18adfe-- -------------------------------------- |
Et eksempel på ITI-18 request og LeafClass response ses nedenfor.
| Code Block | ||||
|---|---|---|---|---|
| ||||
---------------------------- ID: 42 Response-CodeAddress: 200http://localhost:8282/nxrg/iti18 Encoding: ISOUTF-8859-18 Http-Method: POST 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>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> ...soapheaders fjernet for overskuelighed ... <ns2:Value>17991231230940</ns2:Value> </soapns2:Header>ValueList> <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.
| Code Block | ||||
|---|---|---|---|---|
| ||||
--------------------------- 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="</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:xsd:rs:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">StatusType:Approved')</ns2:Value> <ns4:ResponseOption returnType="LeafClass" returnComposedObjects="true"/> </ns2:ValueList> <ns2:AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d"> </ns2:Slot> </ns2:AdhocQuery> <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> </ns4:AdhocQueryRequest> </soap:Body> </soap:Envelope> -------------------------------------- |
| Code Block | ||||
|---|---|---|---|---|
| ||||
---------------------------- 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:SlotExtrinsicObject namemimeType="$XDSDocumentEntryStatustext/xml"> <ns2:ValueList> <ns2:Value>(' 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')</ns2:Value>Approved" id="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49"> <ns2:Slot name="creationTime"> </ns2 <ns2:ValueList> < <ns2:Value>20220224110454</ns2:Slot>Value> </ns2:AdhocQuery> </ns4:AdhocQueryRequest> </soap:Body> </soap:Envelope> -------------------------------------- | ||||
| Code Block | ||||
| ||||
---------------------------- 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: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: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">Value>20220224110454</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="creationTimeserviceStopTime"> <ns2:ValueList> <ns2:Value>20220224110454</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="hashrepositoryUniqueId"> <ns2:ValueList> <ns2:Value>2fab5a7dedfd249cfb508083cf36c8e569558889<Value>1.3.6.1.4.1.21367.2010.1.2.1125</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="languageCodesize"> <ns2:ValueList> <ns2:Value>da-DK<Value>9758</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="serviceStartTimesourcePatientId"> <ns2:ValueList> <ns2:Value>20220224110454<Value>2512489996^^^&1.2.208.176.1.2&ISO</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="serviceStopTimesourcePatientInfo"> <ns2:ValueList> <ns2:Value>20220224110454<Value>PID-5|Berggren^Nancy^Ann</ns2:Value> </ns2:ValueList> < <ns2:Value>PID-7|19481225</ns2:Slot> <ns2:Slot name="repositoryUniqueId"> Value> <ns2:ValueList>Value>PID-8|F</ns2:Value> <ns2:Value>1.3.6.1.4.1.21367.2010.1.2.1125<</ns2:Value>ValueList> </ns2:ValueList>Slot> </ns2<ns2:Slot>Name> <ns2:SlotLocalizedString namexml:lang="sizeen-US"> <ns2:ValueList> charset="UTF-8" value="Dato og tidspunkt for møde mellem patient og sundhedsperson"/> <ns2:Value>9758<</ns2:Value>Name> </ns2:ValueList> <ns2:VersionInfo versionName="1"/> </ns2:Slot> <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="sourcePatientIdauthorInstitution"> <ns2:ValueList> <ns2:Value>2512489996^^^Value>DROS Testafdeling^^^^^&1.2.208.176.1.21&ISO<ISO^^^^12345679999</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="sourcePatientInfo"></ns2:Classification> <ns2:Classification <ns2:ValueList> 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:Value>PID-5|Berggren^Nancy^Ann</ns2:Value>Slot name="codingScheme"> <ns2:Value>PID-7|19481225</ns2:Value>ValueList> <ns2:Value>PID-8|F< <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="Dato og tidspunkt for møde mellem patient og sundhedspersonKlinisk rapport"/> </ns2:Name> <ns2:VersionInfo versionName="1"/></ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:93606bcfa09d5840-9494386c-43ec46f2-9b4eb5ad-a7748d1a838d9c3699a4309d" classifiedObject="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49" nodeRepresentation="urn:ad:dk:medcom:appointmentsummary:full" id="urn:uuid:5f7c36107bc6487b-c1f46a10-44f144a9-b544a144-742ed42f3ef1dcb0212a329c"> <ns2:Slot name="authorInstitution">codingScheme"> <ns2:ValueList> <ns2:Value>1.2.208.184.100.10</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:ValueList> <ns2:Name> <ns2:Value>DROS Testafdeling^^^^^&1.2.208.176.1.1&ISO^^^^12345679999</ns2:Value> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="DK Appointment Summary Document </ns2:ValueList>schema"/> </ns2:Slot>Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:41a5887ff33fb8ac-886518af-4c0942cc-adf7ae0e-e362475b143aed0b0bdb91e1" classifiedObject="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49" nodeRepresentation="00122232009" id="urn:uuid:e572f5b437e11025-0559321c-45aa4e6e-97ddad67-ee49697a4655bc55d37e0bb3"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>1Value>2.16.2840.2081.184113883.1006.9<96</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Klinisk rapporthospital"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:a09d5840cccf5598-386c8b07-46f24b77-b5ada05e-9c3699a4309dae952c785ead" classifiedObject="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49" nodeRepresentation="urn:ad:dk:medcom:appointmentsummary:full408443003" id="urn:uuid:7bc6487b29247c9d-6a101242-44a948b6-a144a123-dcb0212a329cf3e09f27eee8"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>1Value>2.16.2840.2081.184113883.1006.10<96</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="DK Appointment Summary Document schemaalmen medicin"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:f33fb8acf0306f51-18af975f-42cc434e-ae0ea61c-ed0b0bdb91e1c59651d33983" classifiedObject="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49" nodeRepresentation="2223200939289-4" id="urn:uuid:37e11025d1cf019c-321cec5d-4e6e4c16-ad678d2a-bc55d37e0bb35e881025e63a"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.6.96<1</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="hospitalFollow-up (referred to) provider &or specialist, appointment date"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:cccf5598f4f85eac-8b07e6cb-4b774883-a05eb524-ae952c785eadf2705394840f" classifiedObject="urn:uuid:d0d43880-d89e-42a5-8acb-c14dd9347d49" nodeRepresentation="408443003N" id="urn:uuid:29247c9dd9c4d97d-1242e178-48b64620-a123b302-f3e09f27eee826a1517aed11"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.65.96<25</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="almen medicinN"/> </ns2:Name> </ns2:Classification> <ns2:ClassificationExternalIdentifier classificationSchemeregistryObject="urn:uuid:f0306f51d0d43880-975fd89e-434e42a5-a61c8acb-c59651d33983c14dd9347d49" classifiedObjectidentificationScheme="urn:uuid:d0d4388058a6f841-d89e87b3-42a54a3e-8acb-c14dd9347d49" nodeRepresentation="39289-4"92fd-a8ffeff98427" value="2512489996^^^&1.2.208.176.1.2&ISO" id="urn:uuid:d1cf019c6a6213db-ec5d0c22-4c164eba-8d2a81cc-5e881025e63aa84f8070ce8c"> <ns2:Slot name="codingScheme">Name> <ns2:ValueList>LocalizedString value="XDSDocumentEntry.patientId"/> <ns2:Value>2.16.840.1.113883.6.1<</ns2:Value>Name> </ns2:ValueList>ExternalIdentifier> <ns2:ExternalIdentifier </ns2:Slot>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 xml:langvalue="en-US" charset="UTF-8" value="Follow-up (referred to) provider &or specialist, appointment date"/>XDSDocumentEntry.uniqueId"/> </ns2:Name> </ns2:Name>ExternalIdentifier> </ns2:Classification>ExtrinsicObject> <ns2:Classification classificationSchemeExtrinsicObject mimeType="text/xml" lid="urn:uuid:f4f85eac2772945d-e6cb4dcb-488345f8-b524b1c1-f2705394840f0bf9489033d8" classifiedObjectobjectType="urn:uuid:d0d438807edca82f-d89e054d-42a547f2-8acba032-c14dd9347d499b2a5b5186c1" nodeRepresentationstatus="Nurn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:d9c4d97d2772945d-e1784dcb-462045f8-b302b1c1-26a1517aed110bf9489033d8"> <ns2:Slot name="codingSchemecreationTime"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.5.25< <ns2:Value>20220224110539</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="hash"> <ns2:Name>ValueList> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="N"/>Value>2fab5a7dedfd249cfb508083cf36c8e569558889</ns2:Value> </ns2:Name>ValueList> </ns2:Classification>Slot> <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-a84f8070ce8cSlot name="languageCode"> <ns2:Name>ValueList> <ns2:LocalizedString value="XDSDocumentEntry.patientId"/>Value>da-DK</ns2:Value> </ns2:Name>ValueList> </ns2:ExternalIdentifier>Slot> <ns2:ExternalIdentifierSlot registryObjectname="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">serviceStartTime"> <ns2:ValueList> <ns2:Value>20220224110539</ns2:Value> <ns2</ns2:Name>ValueList> </ns2:Slot> <ns2:LocalizedStringSlot valuename="XDSDocumentEntry.uniqueIdserviceStopTime"/> </ns2<ns2:Name>ValueList> < <ns2:Value>20220224110539</ns2:ExternalIdentifier>Value> </ns2:ExtrinsicObject>ValueList> <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> <ns2:Slot name="creationTimerepositoryUniqueId"> <ns2:ValueList> <ns2:Value>20220224110539< <ns2:Value>1.3.6.1.4.1.21367.2010.1.2.1125</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="hashsize"> <ns2:ValueList> <ns2:Value>2fab5a7dedfd249cfb508083cf36c8e569558889<Value>9758</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="languageCodesourcePatientId"> <ns2:ValueList> <ns2:Value>da-DK<Value>2512489996^^^&1.2.208.176.1.2&ISO</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="serviceStartTimesourcePatientInfo"> <ns2:ValueList> <ns2:Value>20220224110539<Value>PID-5|Berggren^Nancy^Ann</ns2:Value> < <ns2:Value>PID-7|19481225</ns2:ValueList>Value> < <ns2:Value>PID-8|F</ns2:Slot>Value> <ns2:Slot name="serviceStopTime"> </ns2:ValueList> </ns2:Slot> <ns2:ValueList>Name> <ns2:Value>20220224110539</ns2:Value> </ns2:ValueList>LocalizedString xml:lang="en-US" charset="UTF-8" value="Dato og tidspunkt for møde mellem patient og sundhedsperson"/> </ns2:Slot>Name> <ns2:SlotVersionInfo nameversionName="repositoryUniqueId1"/> <ns2:ValueList> <ns2:Value>1.3.6.1.4.1.21367.2010.1.2.1125</ns2:Value> </ns2:ValueList>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> <ns2:Slot name="sizeauthorInstitution"> <ns2:ValueList> <ns2:Value>9758<Value>DROS Testafdeling^^^^^&1.2.208.176.1.1&ISO^^^^12345679999</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Slot name="sourcePatientId"></ns2:Classification> <ns2:ValueList> <ns2:Value>2512489996^^^&1.2.208.176.1.2&ISO</ns2:Value> </ns2:ValueList> </ns2:Slot> 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="sourcePatientInfocodingScheme"> <ns2:ValueList> <ns2:Value>PID-5|Berggren^Nancy^Ann</ns2:Value> <ns2:Value>PID-7|19481225<<ns2:Value>1.2.208.184.100.9</ns2:Value> <ns2:Value>PID-8|F<</ns2:Value>ValueList> </ns2:ValueList>Slot> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Dato og tidspunkt for møde mellem patient og sundhedspersonKlinisk rapport"/> </ns2:Name> <ns2:VersionInfo versionName="1"/></ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:93606bcfa09d5840-9494386c-43ec46f2-9b4eb5ad-a7748d1a838d9c3699a4309d" classifiedObject="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8" nodeRepresentation=""nodeRepresentation="urn:ad:dk:medcom:appointmentsummary:full" id="urn:uuid:0a9b33a31550549c-44a5218f-4ae9480b-903e9f02-dd8aa0b6326819935af27026"> <ns2:Slot name="authorInstitutioncodingScheme"> <ns2:ValueList> <ns2:Value>DROS Testafdeling^^^^^&1Value>1.2.208.176184.1100.1&ISO^^^^12345679999<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:41a5887ff33fb8ac-886518af-4c0942cc-adf7ae0e-e362475b143aed0b0bdb91e1" classifiedObject="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8" nodeRepresentation="00122232009" id="urn:uuid:ab51c75f6fae994a-80f130ad-40e5494a-9fe1a561-5894fef1d39b36acc86bae87"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>1Value>2.16.2840.2081.184113883.1006.9<96</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Klinisk rapporthospital"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:a09d5840cccf5598-386c8b07-46f24b77-b5ada05e-9c3699a4309dae952c785ead" classifiedObject="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8" nodeRepresentation="urn:ad:dk:medcom:appointmentsummary:full408443003" id="urn:uuid:1550549ce0e5b026-218f16f2-480b4c6f-9f02b263-19935af2702660fac49aaa46"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>1Value>2.16.2840.2081.184113883.1006.10<96</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="DK Appointment Summary Document schemaalmen medicin"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:f33fb8acf0306f51-18af975f-42cc434e-ae0ea61c-ed0b0bdb91e1c59651d33983" classifiedObject="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8" nodeRepresentation="2223200939289-4" id="urn:uuid:6fae994a981af5cc-30ada0a1-494a43f6-a561946b-36acc86bae87e5565f0f907d"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.6.96<1</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="hospitalFollow-up (referred to) provider &or specialist, appointment date"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:cccf5598f4f85eac-8b07e6cb-4b774883-a05eb524-ae952c785eadf2705394840f" classifiedObject="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8" nodeRepresentation="408443003N" id="urn:uuid:e0e5b02605e47fdb-16f203ce-4c6f49a7-b263b12a-60fac49aaa46e2d8f2f66437"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.65.96<25</ns2:Value> </ns2:ValueList> </ns2:Slot> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="almen medicinN"/> </ns2:Name> </ns2:Classification> <ns2:Classification classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObjectExternalIdentifier registryObject="urn:uuid:2772945d-4dcb-45f8-b1c1-0bf9489033d8" nodeRepresentationidentificationScheme="39289-4" id="urn:uuid:981af5cc58a6f841-a0a187b3-43f64a3e-946b92fd-e5565f0f907da8ffeff98427"> <ns2:Slot name="codingScheme"> <ns2:ValueList> <ns2:Value>2.16.840.1.113883.6.1</ns2:Value> </ns2:ValueList> </ns2:Slot> value="2512489996^^^&1.2.208.176.1.2&ISO" id="urn:uuid:1462c579-d012-490f-a632-8b263e728a76"> <ns2:Name> <ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="Follow-up (referred to) provider &or specialist, appointment dateXDSDocumentEntry.patientId"/> </ns2:Name> </ns2:Classification>ExternalIdentifier> <ns2:ClassificationExternalIdentifier classificationSchemeregistryObject="urn:uuid:f4f85eac2772945d-e6cb4dcb-488345f8-b524b1c1-f2705394840f0bf9489033d8" classifiedObjectidentificationScheme="urn:uuid:2772945d2e82c1f6-4dcba085-45f84c72-b1c19da3-0bf9489033d88640a32e42ab" nodeRepresentationvalue="N7164729179900753373.5043326759312572816.1645697139139" id="urn:uuid:05e47fdb-03ce-49a7-b12a-e2d8f2f66437">3f509092-5833-4e5b-bfc7-2b0c78e1ade2"> <ns2:Name> <ns2:SlotLocalizedString namevalue="codingSchemeXDSDocumentEntry.uniqueId"/> <ns2:ValueList></ns2:Name> </ns2:ExternalIdentifier> <ns2:Value>2.16.840.1.113883.5.25< </ns2:Value>ExtrinsicObject> </ns2:RegistryObjectList> </ns6:AdhocQueryResponse> </soap:Body> </soap:Envelope> -------------------------------------- |
En tilsvarende søgning efter ObjectRef ville give følgende response:
| Code Block | ||||
|---|---|---|---|---|
| ||||
ID: </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>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:ExtrinsicObject><ns2:ObjectRef id="urn:uuid:a573c596-6cc4-40e4-85c2-529d2fbf6914"/> </ns2:RegistryObjectList> </ns6:AdhocQueryResponse> </soap:Body> </soap:Envelope> -------------------------------------- |
En tilsvarende søgning efter ObjectRef ville give følgende response:
| Code Block | ||||
|---|---|---|---|---|
| ||||
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> |
Biblioteker til .Net
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
Hjælpeværktøjer og links
De følgende links kan alle bidrage til at lette arbejdet med at implementere dokumentdeling.
<ns2:ObjectRef id="urn:uuid:4a68ec73-f9c1-4a32-8b50-1c8d585f6590"/>
</ns2:RegistryObjectList>
</ns6:AdhocQueryResponse>
</soap:Body>
</soap:Envelope> |
Dokumenttype-adskillelse i XDS-infrastrukturen
For at smidiggøre infrastrukturen ift. performance, vedligehold og sikkerhed er det besluttet, at vi fremadrettet etablerer separate registries (indexes) og repositories for hver dokumenttype (typecode). Dette er endvidere i fin overensstemmelse med den domænebaserede målarkitektur, der baserer sig på IHE-XCA-profilen.
Da data i registry (SDS patientindex) og repository registreres via Dokument Registrerings- og Opdateringsservicen (DROS), skal der tilsvarende etableres en separat DROS tilknyttet hvert par af registry (SDS patientindex) og repository, så vi ender op med en separat trio DROS/registry/repository per dokumenttype.
Dette betyder, at der vil være et separat endpoint pr dokumenttype, som anvenderne skal anvende, når dokumenter registreres (og opdateres). Der vil til gengæld fortsat kun være behov for ét endpoint til dokumentdelingsservicen, når man skal fremsøge dokumenter.
Krav til eksterne registries og repositories
Dokumentdelingsservicen anvendes til at fremsøge og hente dokumenter på NSP. Det sker ved, at servicen har en række registries og repositories konfigureret, den kalder med ITI-18 Registry Stored Query henholdsvis ITI-43 Retrieve Document Set. For at sikre godt samarbejde/ fejlhåndtering mellem dokumentdelingsservice og disse registries/ repositories, er der opstillet en række punkter, der skal overholdes, hvis man som registry/ repository ønsker at være en del af NSP's dokumentdeling. Disse findes her: registry og repository.
Hjælpeværktøjer og links
De følgende links kan alle bidrage til at lette arbejdet med at implementere dokumentdeling.
| Værktøj | Beskrivelse | Link |
|---|---|---|
| DDS | Guide til anvendere, når man skal læse data:
| https://www.nspop.dk/display/public/web/DDS+-+Guide+til+anvendere |
| DROS | Guide til anvendere, når man skal skrive data:
| 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. | Aftaleoversigten |
| Aftaler | Beskriver servicearkitekturen, der ligger bag deling af aftaler via NSP | https://www.nspop.dk/display/public/web/Aftaler |
| NSP test endpoints | For test1 kan man anvende endpoints til højre. Ønskes i stedet adgang til test2, skiftet "test1" ud med "test2". sts endpointet anvendes i forbindelse med at man trækker et idkort til DGWS. | Alle test miljøer: Endpoints for eksterne testmiljøer iti18: http://test1-cnsp.ekstern-test.nspop.dk:8080/ddsregistry |
| 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 ugyldiggøre (deprecate) dokumenter 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 oprettes 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. Herunder udtræk af metadata. | 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. Den er dog ikke helt opdateret på alle punkter. | https://www.medcom.dk/media/10982/kom-godt-igang-med-dokumentdeling-14-interactive.pdf |
...