Dette dokument er en vejledning til brug for anvendere af AO XDS Adapter.
AO XDS Adapter er en read-only til at hente Bookplan aftaledata i hhv Region Nord og Region Midt i APD-DK v1.0: Borgerens aftaler med Sundhedsvæsenet via Dokumentdelingsservicen (DDS).
Da anvendelsen af AO XDS Adapter sker via DDS, starter dokumentet med et overblik over arkitekturen. Formålet med dette er at dokumentere, hvordan DDS, AO XDS Adapter og Bookplan hænger sammen, og hvilke opgaver de forskellige komponenter dækker hver især.
Da AO XDS Adapters primære opgave er at fortolke forespørgsler fra dokumentanvendere og levere konkrete svar på disse, indeholder dette dokument beskrivelser af:
Herefter dokumenteres det, hvordan et svar på en søgning mod AO XDS Adapter ser ud - herunder sammenhæng aftale dokumenternes indhold og med Medcoms danske profilering: XDS Metadata for Document Sharing v. 0.95.
Derudover opbygger AO XDS Adapters aftaledokumenter. Dette dokument indeholder dokumentation af:
Dette dokument antager, at læseren er bekendt med basale koncepter indenfor IHE XDS, Dokumentdelingsservicen og CDA Dokumenter.
Der kan blandt andet henvises til følgende:
MedComs brug af HL7 standarder
AO XDS Adapter | Aftaleoversigt XDS adapter |
DDS | Dokumentdelingsservice |
BRS | Behandlingsrelationsservice |
XDS | Cross-Enterprise Document Sharing |
Fremsøgning af BookPlan aftaler sker via DDS (se DDS Registry - Querying User's Guide og DDS Registry Querying Interface Description).
AO XDS Adapter understøtter følgende user stories:
AO-SOEG-1 |
---|
Som en dokumentanvender ønsker jeg at fremsøge dokumentreference til en borgers bookplan aftaler, så jeg kan få adgang til borgerens aftaledokumenter |
AO XDS Adapter er således en kilde, som DDS anvender til at understøtte fremsøgingsforespørgsler fra anvendere. Den er installeret i to kørende udgaver: Een til Region Nord Bookplan og een til Region Midt Bookplan.
Således foregår en forespørgsel mod AO XDS Adapters på følgende måde:
DDS Registry forholder sig ikke til indholdet af den konkrete query, der kommer fra Dokumentanvenderen, men overlader til de bagvedliggende registre (herunder AO XDS Adapters) at fortolke og besvare den konkrete query. I næste afsnit findes en detaljeret oversigt over, hvorledes AO XDS Adapters fortolker indkommende queries.
Som en lidt speciel ting vil AO XDS Adapter danne et aftaledokument pr fremsøgt Bookplan aftale. Dette sker hver gang en dokumentanvender laver en søgning. Hver søgning giver derved anledning til et unikt sæt af dokumenter.
Alle tekniske detaljer vedr request og response i forbindelse med fremsøgning af DocumentEntries er beskrevet i afsnittet 3. AO XDS Adapters fortolkning af forespørgsler i forbindelse med søgning (AO-SOEG-1).
Når en dokumentanvender har fremsøgt dokumentreferencer til Bookplan aftaler kan de konkrete aftaledokumenter fremsøges. Dette giver anledning til følgende user story:
AO-HENT-1 |
---|
Som en dokumentanvender ønsker jeg at hente en eller flere konkrete aftaledokumenter for en borger, så jeg kan få adgang til aftaledokumenternes indhold |
I illustrationen ovenfor vises afhentning fra AO XDS Adapter RN. Afhentning fra AO XDS Adapter RM foregår på samme vis. En afhentning af et eller flere dokumenter forløber på følgende måde:
Som beskrevet i user story AO-SOEG-1, så genererer AO XDS Adapter det konkrete dokumentindhold ved hver søgning, som en anvender foretager. De genererede dokumenter opbevares (midlertidigt) i en lokal database. Dokumentanvendere kan ikke antage at genererede aftaledokumenter overlever i denne database i længere end få timer, så enhver afhentning skal ske på baggrund af en søgning.
AO XDS Adapter implementerer transaktionen Registry Stored Query (ITI-18), som er beskrevet i IHE IT Infrastructure Technical Framework Volume 2a (ITI TF-2a) 10 Transactions Part A.
ITI-18 query beskeder følger ebXML Registry Information Mode Version (RIM) 3.0. Overordnet set findes der i en ITI-18 query 3 typer af parametre:
I det følgende afsnit vil vi gennemgå hver af disse 3 parameter-typer og angive, hvordan disse er understøttede/fortolkede i AO XDS Adapter. Gennemgangen vil indeholde eksempler på queries, hvor dette giver mening.
AO XDS Adapter melder tilbage til DDS med et response af DocumentEntries. Det dokumenteres, hvorledes en sådan DocumentEntry ser ud, og i hvor høj grad AO XDS Adapter lever op til de krav, der er sat i Medcoms danske profilering af XDS Metadata.
ReturnType kan som udgangspunkt antage een af følgende to værdier:
AO XDS Adapter ignorerer ReturnCompoesedObjects parameteren. Alle queries besvarers, somom denne parameter er true.
AO XDS Adapter ignorerer return type parameteren. Alle queries besvares, somom denne parameter er sat til LeafClass dvs. fuldt sæt af metadata.
DDS bruger de returnerede metadata til evt. at foretage filtrering i forhold til dataspecifikke spærringer. For at dette kan lade sig gøre, har DDS brug for adgang til det fulde sæt af metadata (LeafClass) og ikke kun objekt-ider (ObjectRef).
I IHE IT Infrastructure Technical Framework opereres med en række standard XDS Query identificeret med UUID'er. Nedenstående tabel viser den samlede oversigt over de definerede Query ID.
Kolonnen længst til højre viser, om AO XDS Adapter forstår/understøtter den specifikke Query.
Query Name | Query ID | AO XDS Adapter understøttelse |
---|---|---|
FindDocuments | urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d | Ja |
FindSubmissionSets | urn:uuid:f26abbcb-ac74-4422-8a30-edb644bbc1a9 | Nej |
FindFolders | urn:uuid:958f3006-baad-4929-a4de-ff1114824431 | Nej |
GetAll | urn:uuid:10b545ea-725c-446d-9b95-8aeb444eddf3 | Nej |
GetDocuments | urn:uuid:5c4f972b-d56b-40ac-a5fc-c8ca9b40b9d4 | Nej |
GetFolders | urn:uuid:5737b14c-8a1a-4539-b659-e03a34a5e1e4 | Nej |
GetAssociations | urn:uuid:a7ae438b-4bc2-4642-93e9-be891f7bb155 | Nej |
GetDocumentsAndAssociations | urn:uuid:bab9529a-4a10-40b3-a01f-f68a615d247a | Nej |
GetSubmissionSets | urn:uuid:51224314-5390-4169-9b91-b1980040715a | Nej |
GetSubmissionSetAndContents | urn:uuid:e8e3cb2c-e39c-46b9-99e4-c12f57260b83 | Nej |
GetFolderAndContents | urn:uuid:b909a503-523d-4517-8acf-8e5834dfc4c7 | Nej |
GetFoldersForDocument | urn:uuid:10cae35a-c7f9-4cf5-b61e-fc3278ffb578 | Nej |
GetRelatedDocuments | urn:uuid:d90e5407-b356-4d91-a89f-873917b4b0e6 | Nej |
FindDocumentsByReferenceId | urn:uuid:12941a89-e02e-4be5-967c-ce4bfc8fe492 | Nej |
AO XDS Adapter vil besvare en forespørgsel med ikke-understøttet Query ID med en fejl af typen 'XDSUnknownStoredQuery'.
De søgeparametre, der er kan anvendes er defineret udfra Query ID. Dette betyder at hver Query type (se tabellen ovenfor) medfører en liste af tvungne/optionelle søgeparametre. I de følgende afsnit gennemgås AO XDS Adapter understøttede Query typer, og for hver af disse angives søgeparametrene, som defineret i IHE IT Infrastructure Technical Framework Volume 2a (ITI TF-2a) 10 Transactions Part A. En kolonne udfor hver søgeparameter angiver AO XDS Adapters fortolkning (hvis nogen) af den medsendte parameter samt evt. valideringer.
Som defineret i IHE IT Infrastructure Technical Framework Volume 2a (ITI TF-2a) 10 Transactions Part A giver Querytypen FindDocuments anledning til en specificeret liste af søgeparametre. Nedenfor er denne tabel gengivet, og AO XDS Adapter understøttelse angivet i kolonnen yderst til højre. AO XDS Adapter understøttelser viser, om AO XDS Adapter kigger på søgeparametren, og hvad AO XDS Adapter betegner som et match på query (kommer der et svar tilbage eller ej).
Fra IHE IT Infrastructure Technical Framework for specifikation af parametre relevante for FindDocuments: Find documents (XDSDocumentEntry objects) in the registry for a given patientID with a matching availabilityStatus attribute. The other parameters can be used to restrict the set of XDSDocumentEntry objects returned. | ||||
Parameter Name | Attribute | Opt | Mult | AO XDS Adapter understøttelse |
---|---|---|---|---|
$XDSDocumentEntryPatientId | XDSDocumentEntry.patientId | R | -- | |
$XDSDocumentEntryReferenceIdList (5) | XDSDocumentEntry.referenceIdList (3) | R | M | |
$XDSDocumentEntryClassCode (1) | XDSDocumentEntry.classCode | O | M | |
$XDSDocumentEntryTypeCode (1) | XDSDocumentEntry.typeCode | O | M | |
$XDSDocumentEntryPracticeSettingCode (1) | XDSDocumentEntry.practiceSettingCode | O | M | |
$XDSDocumentEntryCreationTimeFrom | Lower value of XDSDocumentEntry.creationTime | O | -- | |
$XDSDocumentEntryCreationTimeTo | Upper value of XDSDocumentEntry.creationTime | O | -- | |
$XDSDocumentEntryServiceStartTimeFrom | Lower value of XDSDocumentEntry.serviceStartTime | O | -- | |
$XDSDocumentEntryServiceStartTimeTo | Upper value of XDSDocumentEntry.serviceStartTime | O | -- | |
$XDSDocumentEntryServiceStopTimeFrom | Lower value of XDSDocumentEntry.serviceStopTime | O | -- | |
$XDSDocumentEntryServiceStopTimeTo | Upper value of XDSDocumentEntry.serviceStopTime | O | -- | |
$XDSDocumentEntryHealthcareFacilityTypeCode (1) | XDSDocumentEntry.healthcareFacilityTypeCode | O | M | |
$XDSDocumentEntryEventCodeList (1) | XDSDocumentEntry.eventCodeList (3) | O | M | |
$XDSDocumentEntryConfidentialityCode (1) | XDSDocumentEntry.confidentialityCode (3) | O | M | |
$XDSDocumentEntryAuthorPerson (4) | XDSDocumentEntry.author | O | M | |
$XDSDocumentEntryFormatCode (1) | XDSDocumentEntry.formatCode | O | M | |
$XDSDocumentEntryStatus | XDSDocumentEntry.availabilityStatus | R | M | |
$XDSDocumentEntryType (6) | XDSDocumentEntry.objectType | O | M(1) |
1) Shall be coded according to specification of Coding of Code/Code
3) 3 Supports AND/OR semantics
4) The value for this parameter is a pattern compatible with the SQL keyword LIKE which allows the use of the following wildcard characters: % to match any (or no) characters and _ to match a single character. The match shall be applied to the text contained in the Value elements of the authorPerson Slot on the author Classification (value strings of the authorPerson sub-attribute)
5) The value for this parameter is a pattern compatible with the SQL keyword LIKE which allows the use of the following wildcard characters: % to match any (or no) characters and _ to match a single character.
AO XDS Adapter er sat op med en række miljøspecifikke variable. De forskellige variable gennemgåes og deres anvendelse specificeres. Nogle af disse variable er miljøspecifikke (i disse tilfælde listes parametrene for de forskellige miljøer) mens andre er ens henover de forskellige miljøer (den nuværende konfiguration vises).
Som det fremgår af tabellen anvendes de forskellige metadata opsætningsvariable til filtrering af queries og/eller til indsættelse i de DocumentEntries, som AO XDS Adapter returnerer til dokumentanvender. Udover opsætningsvariable indeholder både DocumentEntries (returneret i response på queries) og selve CDA dokumentet data, der stammer fra bookplan. Dokumentet indeholder et eksempel på bookplan aftaledata.
Der være en sammenhæng mellem det forventede indhold af de returnerede DocumentEntries og den af Medcom specifikcerede danske metadataprofil.
Gennem et konkret eksempel på svar fra AO XDS Adapter vil vi dokumentere sammenhængen med den danske metadataprofil.
I forbindelse med hver udførelse af user story AO-SOEG-1 kalder AO XDS Adapter en REST service i Bookplan. Givet et CPR nummer er denne service i stand til at give en liste af alle borgerens gældende aftaler (på forespørgselstidspunktet). Formatet for en bookplan-aftale ser således ud:
[ { "arrivalDateTime" : "2015-10-21T13:15:00.000+02:00", "serviceName": "Blodprøve", "arrivalLocation": { "postalCode": "8860", "postalDistrict": "Skanderborg", "address": "Sygehusvej 7", "site": "Skanderborg Sundhedscenter", "location": "Hovedindgangen, stueetagen" }, "departmentName": "Ortopædkirurgisk Afdeling, HEH hospital" }, { "arrivalDateTime" : "2013-09-17T09:00:00.000+02:00", "serviceName": "TRY Ambulant besøg 30min", "arrivalLocation": { "postalCode": "", "postalDistrict": "", "address": "", "site": "", "location": "" }, "departmentName": "Urinvejskirurgisk Ambulatorium - LADET" } ] |
Til filtrering af indkommende queries (se afsnit vedr. AO XDS Adapter Query Parameters) samt til generering af de udgående DocumentEntries i responses er AO XDS Adapter konfigureret med følgende opsætningsvariable:
Opsætningsvariablens navn | Beskrivelse | Miljø-specifik | Værdi for RN (nuværende opsætning) | Værdi for RM (nuværende opsætning) |
---|---|---|---|---|
documentEntry.repositoryUniqueId | Anvendes til indsættelse i feltet $XDSDocumentEntry.repositoryUniqueId for de returnerede DocumentEntries | J | ?? (TEST1) (TEST2) | |
documentEntry.title | Anvendes til indsættelse i $XDSDocumentEntry.Name for de returnerede DocumentEntries | N | ||
documentEntry.mimeType | Anvendes til indsættelse i $XDSDocumentEntry.mimeType for de returnerede DocumentEntries | N | ||
documentEntry.languageCode | Anvendes til indsættelse i $XDSDocumentEntry.languageCode for de returnerede DocumentEntries | N | ||
documentEntry.patient.assigningAuthority.root | Anvendes til kvalificering af $XDSDocumentEntry.sourcePatientId for de returnerede DocumentEntries | N | ||
documentEntry.organisation.assigningAuthority.root | Anvendes til kvalificering af $XDSDocumentEntry.author (urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d) for de returnerede DocumentEntries | N | ||
documentEntry.healthcareFacilityTypeCode.code | Anvendes til indsættelse i $XDSDocumentEntry.healthcareFacilityTypeCode (urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1) for de returnerede DocumentEntries | N | ||
documentEntry.healthcareFacilityTypeCode.schemeName | Anvendes til indsættelse i $XDSDocumentEntry.healthcareFacilityTypeCode (urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1) for de returnerede DocumentEntries | N | ||
documentEntry.healthcareFacilityTypeCode.name | Anvendes til indsættelse i $XDSDocumentEntry.healthcareFacilityTypeCode (urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1) for de returnerede DocumentEntries | N | ||
documentEntry.classCode.code | Anvendes til filtrering af queries. Anvendes til indsættelse i $XDSDocumentEntry.classCode (urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a) for de returnerede DocumentEntries | N | ||
documentEntry.classCode.schemeName | Anvendes til filtrering af queries. Anvendes til indsættelse i $XDSDocumentEntry.classCode (urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a) for de returnerede DocumentEntries | N | ||
documentEntry.classCode.name | Anvendes til indsættelse i $XDSDocumentEntry.classCode (urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a) for de returnerede DocumentEntries | N | ||
documentEntry.formatCode.code | Anvendes til filtrering af queries. Anvendes til indsættelse i $XDSDocumentEntry.formatCode (urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d) for de returnerede DocumentEntries | N | ||
documentEntry.formatCode.schemeName | Anvendes til filtrering af queries. Anvendes til indsættelse i $XDSDocumentEntry.formatCode (urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d) for de returnerede DocumentEntries | N | ||
documentEntry.formatCode.name | Anvendes til indsættelse i $XDSDocumentEntry.formatCode (urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d) for de returnerede DocumentEntries | N | ||
documentEntry.typeCode.code | Anvendes til filtrering af queries. Anvendes til indsættelse i $XDSDocumentEntry.typeCode (urn:uuid:f0306f51-975f-434e-a61c-c59651d33983) for de returnerede DocumentEntries | N | ||
documentEntry.typeCode.schemeName | Anvendes til filtrering af queries. Anvendes til indsættelse i $XDSDocumentEntry.typeCode (urn:uuid:f0306f51-975f-434e-a61c-c59651d33983) for de returnerede DocumentEntries | N | ||
documentEntry.typeCode.name | Anvendes til indsættelse i $XDSDocumentEntry.typeCode (urn:uuid:f0306f51-975f-434e-a61c-c59651d33983) for de returnerede DocumentEntries | N | ||
documentEntry.author.organisation.id | Anvendes til indsættelse i $XDSDocumentEntry.author (urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d) for de returnerede DocumentEntries | N | ||
documentEntry.author.organisation.name | Anvendes til indsættelse i $XDSDocumentEntry.author (urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d) for de returnerede DocumentEntries | N | ||
documentEntry.confidentialityCode.code | Anvendes til filtrering af queries. Anvendes til indsættelse i $XDSDocumentEntry.confidentialityCode (urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f) for de returnerede DocumentEntries | N | ||
documentEntry.confidentialityCode.schemeName | Anvendes til filtrering af queries. Anvendes til indsættelse i $XDSDocumentEntry.confidentialityCode (urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f) for de returnerede DocumentEntries | N | ||
documentEntry.confidentialityCode.name | Anvendes til indsættelse i $XDSDocumentEntry.confidentialityCode (urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f) for de returnerede DocumentEntries | N | ||
documentEntry.practiceSettingCode.code | Anvendes til indsættelse i $XDSDocumentEntry.practiceSettingCode (urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead) for de returnerede DocumentEntries | N | ||
documentEntry.practiceSettingCode.schemeName | Anvendes til indsættelse i $XDSDocumentEntry.practiceSettingCode (urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead) for de returnerede DocumentEntries | N | ||
documentEntry.practiceSettingCode.name | Anvendes til indsættelse i $XDSDocumentEntry.practiceSettingCode (urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead) for de returnerede DocumentEntries | N |
Som det fremgår af ovenstående tabel anvendes variablene til både:
Følgende request viser en fremsøgning af dokumenter på CPR nummeret 2110979421 via DDS (SOAP headers er fjernet for at gøre eksemplet mere læsevenligt).
TODO
Som vist i overblikket delegerer DDS query videre til bl.a. FSK Registry og samler kildernes svar i et samlet response til anvenderen. Følgende viser, hvordan response ser ud (SOAP headers er fjernet for at gøre eksemplet mere læsevenligt).
TODO
Et response fra AO XDS Adapter består som tidligere beskrevet af en liste af selvindeholdte XDS Document Entries. Indholdet af et sådant response er specificeret i IHE IT Infrastructure Technical Framework Volume 3 IHE ITI TF-3 10 Cross-Transaction Specifications and Content Specifications. Derudover har Medcom udarbejdet Medcoms danske profilering: XDS Metadata for Document Sharing v. 0.95.
Med udgangspunkt i Medcoms profilering kan det returnede metadata beskrives udfra tabel 4 i Medcoms specifikation: Metadata Attributes optionality and sources sammenhold med IHE specifikationen for On-demand DocumentEntries. For hver af disse metadataattributter angivers i "AO XDS Adapter implementeringsstatus", om den danske metadataprofil er overholdt i AO XDS Adapter implementeringen. Eksempelkolonnen indeholder udklip fra responseeksemplet ovenfor og kan evt. sammenholdes med specifikationen i Medcoms metadataprofilering.
Uoverensstemmelser mellem data leveret af AO XDS Adapter og specifikationer i den danske metadataprofil er fremhævet med rød.
Fra Medcoms danske profilering tabel 4 (de rækker der er relevante for DocumentEntries minus de rækker, der ikke er relevante for on-demand Entries) | ||||
Metadata attribute | Optional (IHE) | Optional (DK) | AO XDS Adapter implementerings-status | Eksempel (udklip af response ovenfor) |
---|---|---|---|---|
author.authorInstituation | R | |||
author.authorPerson | R2 | |||
availabilityStatus | R | R | ||
R | R | OK | ||
contentTypeCode | R | - | ||
creationTime | R | R | ||
entryUUID | R | R | ||
eventCodeList | O | R2 | ||
R | R | OK | ||
hash | M | R | ||
healthcareFacilityTypeCode | R | R | ||
homeCommunityId | R | R | ||
languageCode | R | R | ||
legalAuthenticator | O | R2 | ||
mimeType | R | R | ||
objectType | R | R | ||
patientId | M | R | Se sourcePatientId | |
practiceSettingCode | R | - | ||
referenceIdList | O | O | ||
repositoryUniqueId | R | R | ||
serviceStartTime | R2 | R2 | ||
serviceStopTime | R2 | R2 | ||
size | R | R | ||
sourcePatientId | R | R | ||
sourcePatientInfo | R | R | ||
title | O | R | ||
typeCode | R | R | ||
uniqueId | R | R | ||
URI | O | O |
O=Optional, R=Required, R2=Required when known
AO XDS Adapter implementerer transaktionen Retrieve Document Set (ITI-43), som er beskrevet i IHE IT Infrastructure Technical Framework Volume 2b (ITI TF-2b) 10 Transactions Part A.
ITI-43 beskeder beskeder er simple og består af
I det følgende har vi et eksempel på et ITI-43 request og et tilhørende response. Dette request og response hører sammen med eksemplet, der blev præsenteret i forbindelse med søgning AO-SOEG-01.
TODO
Med udgangspunkt i eksemplet ovenfor vil vi kigge nærmere på dokumentindholdet.
Det første der bør undersøges er, om de genererede aftaledokumenter overholder Medcoms standard i forhold til profilering af aftale dokumenter. Til dette formål har vi kørt eksempel dokumentet igennem en validering.
TODO
Dernæst genbesøges Medcoms Metadataprofil