Eksterne referencer i CDA dokumenter

Transkript

1 Eksterne referencer i CDA dokumenter Michael Due Madsen, MedCom, mdm@medcom.dk Søren Ærendal Mikkelsen, Lakeside, smi@lakeside.dk Bjarne Hansen, Lakeside, bjh@lakeside.dk Version 0.9.1

2 Indledning Dette notat beskriver et forslag til den praktiske anvendelse af reference og externaldocument elementer i CDA dokumenter til krydsreferencer. Behovet er identificeret i forbindelse med arbejdet med PHMR, QFDD og QRD CDA dokumenterne, hvor der er et identificeret behov for at kunne referere fra f.eks. et PHMR dokument til et QRD dokument, fra et QRD dokument til et PHMR dokument, eller måske mellem et QRD dokument og den template QRD dokumentet er baseret på (QFDD). Den basale del af problemstillingen er selvfølgelig hvordan man udtrykker en sådan reference, en anden del er hvordan man i praksis opløser referencen og får fat i det dokument der refereres til. Vi kender referencer mellem dokumenter til hudløshed, bl.a. fra links mellem hjemmesider, dvs. URL er som vi kender som tekster på formen: En URL som vist ovenfor angiver en protokol (http), en server ( docrep.medcom.dk ), en sti ( /documents ), parametre ( docid=12345 ) og et bogmærke inden i dokumentet ( #about ). Den information der er indeholdt i URL en gør det muligt for os på en standardiseret måde at hente dokumentet og navigere brugeren ned til den sektion der er markeret med bogmærket #details. En af problemstillingerne med URL er er at hvis en server omdøbes, en sti ændres eller et id laves om, så vi de dokumenter der refererer til URL en have en ugyldig reference, hvilket udgør et ikke ligegyldigt problem for referencer mellem websider i dag. Retfærdigvis skal det siges at i hvert fald HTTP protokollen giver anvisninger på hvordan flytninger af dokumenter håndteres, men i praksis anvendes disse sjældent. For referencer fra CDA dokumenter til andre (CDA) dokumenter ønsker vi derfor ikke at indkode protokol, server, sti og andre information der potentielt kan ændre sig over tid. I stedet ønsker vi at referencer baseres på et unikt id som kan opløses på baggrund af basal information om typen af referencen. En basal komponent for opbevaring af CDA dokumenter i det danske sundhedsvæsen er IHE XDS repositories. En vigtig egenskab ved krydsreferencerne er derfor at de skal kunne opløses ved kald til et IHE XDS registry/repository. Ud over referencer til andre CDA dokumenter kan man forestille sig et behov for referencer til andre typer af dokumenter, for eksempel PDF filer eller videoer med vejledninger eller lignende. Igen vil det være formålstjenligt at kunne sikre at vores referencer er stabile overfor ændringer i placering. 2/14

3 Beskrivelse Her gives en beskrivelse af hvordan externaldocument anvendes som reference til CDA dokumenter i den danske infrastruktur. Først beskriver vi hvordan referencerne vil optræde i CDA dokumenter, derefter beskriver vi hvordan IHE XDS baserede referencer kan opløses og til sidst gives lidt inspiration til hvordan vi kunne håndtere andre typer af referencer der minder om URL er. CDA dokument referencer Elementet externaldocument En reference fra et CDA dokument til et andet dokument laves ved at benytte et reference element med typecode= REFR og et externaldocument element med classcode= DOC. Da vi ønsker at angive at referencen opfylder en dansk profilering for krydsreferencer anvender vi en templateid med værdien Indeni externaldocument elementet har vi de elementer der beskriver detaljer for selve referencen. Vi har valgt at benytte code og id elementerne for at holde beskrivelsen så simpel som muligt. Typen på det refererede dokument For at et system skal kunne afgøre om det ønsker at hente et konkret dokument skal det som minimum vide hvad det er for en dokumenttype der refereres til. For CDA dokumenter er det oplagt at angive LOINC koden for for den generelle dokument profil, mens det for andre dokumenter kan være nok at angive formatet, som f.eks. application/pdf for et PDF dokument. 3/14

4 Brug af LOINC koder til identifikation af indhold Et bud på hvordan man angiver typen for det refererede dokument er at benytte code elementet med den tilhørende LOINC kode for dokumenttypen hvis der er tale om et CDA dokument. <code code= codesystem= displayname= Questionnaire Form Definition Document > Eksempel 1: Brug af code til at identificere typen af indhold med LOINC kode. I eksemplet ovenfor bruges codesystem OID for LOINC og code angiver at der refereres til et Questionnaire Response Document (QRD). LOINC Beskrivelse Personal Health Monitoring Report (PHMR) Questionnaire Form Definition Document (QFDD) Questionnaire Response Document (QRD) Tabel: LOINC code værdier for CDA dokumenter Ovenfor ses sammendrag af de relevante LOINC koder for CDA dokumenter. Indenfor HL7 er codesystem OID en for LOINC Brug af mime type til identifikation af indhold Bemærk: Der er ikke beskrevet use-case for at referere fra CDA dokumenter til andre typer af indhold. Beskrivelsen af hvordan andre typer af indhold refereres er derfor vejledende og angivet her som et eksempel. For CDA dokumenter vil indholdet når det fremfindes være et XML dokument, og der er derfor ikke nogen umiddelbar grund til yderligere at specificere dokumentets format ved brug af en mime type. Ønsker man derimod at referere til indhold der ikke er et standard CDA dokument, for eksempel et PDF dokument med instruktioner eller lignende, har man brug for at den som ønsker at opløse referencen ved hvilket type dokument der findes for enden af referencen. I internet sammenhæng benyttes Mime Media Types (RFC 2045), og en liste af gyldige medietyper vedligeholdes af IANA (Internet Assigned Numbers Authority). 4/14

5 Vi kender medietyper som for eksempel application/pdf, der beskriver at indholdet er et PDF dokument. <code code= application/pdf codesystem= displayname= Mime Media Type > Eksempel 2: Brug af code til at identificere mime type af indhold. Brug af id element til identifikation af dokument Til at angive referencen til det eksterne dokument anvendes et id element i externaldocument elementet. Hvis der for eksempel er tale om et CDA dokument der referes til benyttes root og extension fra id feltet i CDA header. <id root= extension= edb802b0-2e36-11e6-bdf c9a66 /> <code code= codesystem= displayname= LOINC > Eksempel 3: Reference til CDA dokument. I eksemplet ovenfor benyttes OID (MedCom) som root og en UUID som extension. Med ovenstående brug af code og id vil man vide hvilket slag dokument der refereres til og hvilket id dokumentet har, men man vil ikke umiddelbart kunne afgøre hvordan man får fat i det dokument der refereres til. I den danske nationale infrastruktur må man antage, at hvis man ønsker at fremfinde ovenstående dokument bør man fremsøge det via dokumentdelingsservice en. Det vil dog være formålstjenligt at kunne referere til dokumenter på anden vis, og til det formål har vi brug for at angive hvordan en reference opløses. 5/14

6 Brug af id element til opløsning af reference til dokument Vi kan ud over at angive id for dokumentet også angive et id der beskriver hvorledes man kan opløse referencen, dvs. hvordan man får fat i det dokument der refereres til. Til det formål tildeles en OID ( ) som anvendes i root attributten til at angive at den efterfølgende extension indeholder information om hvordan id er kan opløses. Indtil videre har vi allokeret 3 værdier, én som angiver at id kan opløses via kald til dokumentdelingsservicen, én som angiver at id kan opløses via en linkresolver, og én som angiver opløsning af id via URL. Bemærk: Der er ikke etableret nogen Handle infrastruktur for det danske sundhedsvæsen i dag. Beskrivelserne af Linkresolver og Handle infrastruktur er alene medtaget her som inspiration og eksempel på andre måder at opløse referencer på. root extension Anvendelse NA CDA externaldocument id opløsning root Dokumentdelingsservice reference (XDS) uniqueid reference Linkresolver reference HTTP(S) baserede URL er. Tabel: root og extension der angiver hvordan id referencer opløses. Reference til dokument i dokumentdelingsservice Som eksempel er nedenfor vist hvordan man kan referere til et CDA dokument der er registreret i dokumentdelingsservicen. <id root= extension= edb802b0-2e36-11e6-bdf c9a66 /> <id root= extension= 1 /> <code code= codesystem= displayname= LOINC > Eksempel 4: Reference til CDA dokument registreret i dokumentdelingsservice. 6/14

7 Reference til dokument via Linkresolver Ønsker man at bruge et reference der kan opløses ved hjælp af en Linkresolver skal man anvende et id element med root og extension for PID referencen. Herudover angives et id der fortæller at det første id kan opløses ved hjælp af en Linkresolver. Endelig angives typen af indholdet ved hjælp af en mime media type som beskrevet ovenfor. Dette sker i code elementet. <id root= extension= 74e950bb-542f a3ad9940cf87 /> <id root= extension= 2 /> <code code= application/pdf codesystem= displayname= Media Type > Eksempel 5: Reference til PDF dokument gennem Linkresolver PID en er en dokument reference som kan veksles til en almindelig URL og indholdet kan derefter hentes på normal vis via Internettet. Vi opnår med denne arkitektur en afkobling mellem referencer fra CDA dokumenter og konkrete URL er der måske ændres over tid. I Danmark findes der allerede en Linkresolver infrastruktur baseret på Handle infrastruktur og software. Denne infrastruktur drives i Danmark af Det Kongelige Bibliotek. Der kunne, for det danske sundhedsvæsen, oprettes en separat Handle infrastruktur med eget prefix hvis det ikke anses for hensigtsmæssigt at belaste infrastrukturen for bibliotekerne med data fra sundhedsvæsenet. I afsnittet Opløsning af reference via Linkresolver kan finde yderligere information om brugen af Linkresolvere. Den ovenstående PID består af et prefix og et suffix. Prefix er , hvilket er et prefix hørende til den danske demo-system. Du kan på siden for eksempel opløse referencen /medcom, hvilket i praksis vil tage dig til MecCom s hjemmeside. Reference til dokument via URL Den mest almindelige form for referencer til dokumenter er nok brugen af HTTP(S) baserede URL er. Fordelen ved brug af Internet baserede protokoller er den nemme 7/14

8 adgang til programmeringsbiblioteker og værktøjer der kan anvendes til at hente indholdet. Ulempen ved brug af direkte URL er, sammenlignet med brug af linkresolver id er beskrevet ovenfor, er at hvis dokumenter flyttes til anden server (DNS) vil man skulle opdatere referencer i dokumentet, eller understøtte omdirigering via HTTP status kode 302 Found konstruktionen fra den oprindelige lokation. <id root= extension= KOL v1.0.xml /> <id root= extension= 3 /> <code code= codesystem= displayname= LOINC > Eksempel 6: Reference til QFDD dokument gennem URL. En mulig anvendelse af direkte URL er er referencer til standardiserede spørgeskemaer opbevaret hos f.eks. MedCom. Ovenstående eksempel viser en reference til et QFDD dokument opbevaret på MedCom s SVN server. Referencer ind i indholdet af det refererede dokument Ønsker man ikke blot at referere til et andet dokument, men ønsker man at referere til en specifik observation inde i et CDA dokument kan man i stedet vælge at benytte externalobservation elementet. Her bruger man den samme templateid samt id og code elementer til at referere til det eksterne dokument. Herudover angiver man et id element der specificerer hvilken observation i det refererede dokument man ønsker at udpege. <externalobservation classcode="obs"> <id root= extension= edb802b0-2e36-11e6-bdf c9a66 /> <id root= extension= 1 /> <id root= extension= ob1 /> <code code= codesystem= displayname= LOINC > </externalobservation> 8/14

9 Eksempel 7: Reference til konkret spørgsmål i QRD dokument. Eksempler på referencer der udpeger en konkret observation i et CDA dokument kunne være: En reference fra svaret i et QRD dokument (observation) til det tilsvarende spørgsmål i et QFDD dokument. En reference fra svaret i et QRD dokument til en konkret måling i et PHMR dokument. En reference fra en konkret måling i et PHMR dokument til et konkret svar i et QRD dokument. For alle ovenstående referencetyper gælder det at det man peger på i CDA termer er en observation. Ovenstående eksempler er ikke identificeret som konkrete use-cases, men medtages her til inspiration på hvordan krydsreferencer til konkret indhold kan repræsenteres. Opløsning af reference til IHE XDS repository ClinicalDocument/id og XDS DocumentEntry/uniqueId I forhold til den helt centrale use-case med at referere fra et CDA dokument til et andet CDA dokument opbevaret i et IHE XDS registry/repository kan vi starte med at notere at der i XDS meta-data registreres et uniqueid, og at for CDA dokumenter svarer dette til præcist til id attributten angivet i CDA header. IHE IT Infrastructure Technical Framework, Volume 3: Cross-Transaction and Content Specifications: The uniqueid meta-data attribute of a Stable DocumentEntry identified the specific document associated with the entry. It is used in a retrieve request to identify which specific document should be retrieved. (170) if the document returned in a retrieve request is CDA, it will have the ClinicalDocument/id field in the HL7 CDA R2 document header the same value as the value of the DocumentEntry uniqueid. (175) Dette betyder at når CDA dokumenter registreres i et IHE XDS registry vil dokument id et fra CDA dokumentet blive benyttet som uniqueid i XDS registry meta-data. Opløsning af XDS uniqueid reference Ovenstående gør det muligt at benytte CDA id en på det (CDA) dokument man refererer til som basis for en søgning i et IHE XDS registry efter dokumentet (ITI-18). 9/14

10 Konkret vil man kunne kalde søge funktionen GetDocuments i ITI-18, med én eller flere uniqueid (CDA id attribut) værdier for dokumenter man ønsker at fremfinde. Resultatet vil være en samling af XDSDocumentEntry objekter der kan benyttes til at hente dokumentet fra et IHE XDS repository (ITI-43: Retrieve Document Set). Vær opmærksom på at et CDA dokument med et givent id kan være gemt i flere forskellige IHE XDS repositories, hvorfor svaret fra ITI-18 kan returnere flere XDSDocumentEntry objekter for det samme dokument. Direkte opløsning via XDS Registry Den ovenstående proces for opløsning af en reference ved brug af uniqueid gennem registry (initiating gateway) har, fra et performance perspektiv, den ulempe at der først skal foretages en søgning via ITI-18 som returnerer XDSDocumentEntry objekter, og derefter et kald til ITI-43 for at hente en eller flere konkrete dokumenter. Umiddelbart virker det som at der kunne ligge en optimering i at kalde ITI-43 direkte med det uniqueid man har fra referencen i CDA dokumentet. ITI-43 tager parametrene repositoryuniqueid, documentuniqueid ( uniqueid ) og evt. homecommunityid. Disse værdier er alle del af de XDSDocumentEntry objekter der returneres fra ITI-18, men disse skulle være en del af referencen hvis man skulle kunne opløse den direkte med kald til ITI /14

11 <id root= extension= 74e950bb-542f a3ad9940cf87 /> <id root=... OID der betyder repositoryuniqueid... extension=... uuid... /> <id root=... OID der betyder homecommunityid... extension=... uuid... /> Det er uklart hvad konsekvenserne af en sådan anvendelse af referencer vil være, men man kan umiddelbart forestille sig at man binder sig på en måde som ikke nødvendigvis vil være hensigtsmæssig hvis man flytter/migrerer enkelte specifikke repositories. Opløsning af reference via Linkresolver Opløsning af reference via URL 11/14

12 Sammendrag Referencer mellem CDA dokumenter i en IHE XDS infrastruktur kan ved hjælp af externaldocument eller externalobservation referencer hvor code elementet angiver dokumenttypen og id elementet angiver den CDA uniqueid man kan benytte når man ønsker at fremfinde det refererede dokument. Et yderligere id element benyttes til at angive hvordan man opløser referencen og henter selve det refererede dokument.   <id root= extension= edb802b0-2e36-11e6-bdf c9a66 />  <id root= extension= 1 />  <code code= codesystem= displayname= LOINC > Ønsker man at referere til en konkret observation inde i det refererede dokument anvendes en externalobservation reference. Denne indeholder de samme elementer som anvendes i externaldocument elementet, og derudover et ekstra id til identifikation af observationen.  <externalobservation classcode="obs">  <id root= extension= edb802b0-2e36-11e6-bdf c9a66 />  <id root= extension= 1 />  <id root= extension= ob1 />  <code code= codesystem= displayname= LOINC > 12/14

13 </externalobservation> De to vigtige kodesæt til at lave denne type referencer er angivet her nedenfor. Det drejer sig om LOINC koder for CDA dokumenter og MedCom id der beskriver hvordan en dokumentreference skal opløses. LOINC Beskrivelse Personal Health Monitoring Report (PHMR) Questionnaire Form Definition Document (QFDD) Questionnaire Response Document (QRD) Tabel: LOINC code værdier for CDA dokumenter root extension Anvendelse NA CDA externaldocument id opløsning root Dokumentdelingsservice reference (XDS) uniqueid reference Linkresolver reference HTTP(S) baserede URL er. Tabel: OID der angiver hvordan id referencer opløses. 13/14

14 Referencer DK IHE Metadata Common Code Systems Value Set IHE information like class code, type code, format code etc. Code_systems-Value_sets.xlsx DK IHE IHE IT Infrastructure Technical Framework, Volume 2a: Transactions Part A IHE IT Infrastructure Technical Framework, Volume 2b: Transactions Part B IHE IT Infrastructure Technical Framework, Volume 3): Cross-Transaction and Content Specifications Link from a CDA narrative to another CDA document in an XDS repository Attachments in CDA DFCE46A2/wg/ca/ASIG-CDA-Tutorial-0304-Rishel.pdf mediatype codesystem definition at hl7.org 4B4A161F/standards/vocabulary/vocabulary_tables/infrastructure/vocabulary/medi atype.html Handle.net Registry RFC Handle System Overview Information om PID (Linkresolver) i Danmark 14/14