IHE og IHE-profiler
Integrating the Healthcare Enterprise (IHE) er et globalt initiativ av helsepersonell og leverandørmarkedet som i felleskap vil forbedre måten datasystemer deler opplysninger på i helsesektoren.
(IHE)-profiler beskriver interaksjoner mellom forskjellige datasystemer, men samtidig ikke beksriver hvordan disse skal være integrert i den konkrete datasystem. Ordet "profil" er brukt i betydning av en "form", som at en profil har en bestemt form, men hva som utgjør formen (f.eks. detaljer) ikke er spesifisert. Dette gir frihet og muligheter for de som implementerer til å "fylle opp" formen som de vil, så lenge formen blir den samme. I praktisk betydning gir dette nok frihet til den som implementerer for å sikre at løsningen er kompatibel med deres eget system men samtidig som profiler er også nok beskrevet for å garantere interoperabilitet med andre øvrige systemer
Aspekter av IHE-profiler som ikke dekkes:
Roller og ansvar
Bekymringer om personvern
Autorizasjon
Når publisering av dokument oppstår, og hva som er publisert
Administrative roler
Konfigurasjoner
Service-Level Agreements (SLA)
Før man begynner med implementasjon av integrasjon av pasientens journaldokumenter, det er viktig at man blir kjent med konseptet for samarbeisområdet, og ikke minst profiler XDS, MHD, XCA, XUA og respektive transaksjoner (ITI-meldinger).
IHE-profiler for lagring av dokumenter [ITI XDS, ITI MHD]
IHE har beskrevet profiler for diverse interaksjoner mellom datasystemer i helsesektoren. Melding "Provide and Register Document Set-b" ITI-41/ITI-65 profil er relevant for lagring/oppbevaring av dokumenter
Det er opp til dokumentkilde til å definere mekanisme for lagring av dokumenter. Det kan være basert på bruk av ITI-41/ITI-65 profil men andre tilnærminger er også mulige så lenge formatet og metadata-opplysninger følger spesifikasjoner.
Nasjonale tilpasninger av IHE-profiler
Under her er det beskrivelse av nasjonale hensyn når pasientens journaldokumenter (tidligere: dokumentdeling) ble etablert som nasjonal tjeneste. Disse tilpasninger ble utført i sammenheng med nasjonale identifikater som finnes fra før, som pasientidentifikator (NIN).
Når en pasient skal identifiseres, XDS-profil spesifiserer When identifying a patient, the XDS profile specifies the actor Patient Identity Source, as specified in ITI-TF Volume 1 chapter 10.1.
As the need for identifying patients based on local identifiers are not required, another decision was to utilize a central, national XCA-gateway (maintained by Norsk helsenett) for centralized querying and retrieval of documents. This means that all queries to PHR goes through the national XCA, and the national XCA acts as a forwarder to the document sources. Norsk helsenett administrates the service on a national level.
Optimized queries
Note: As of writing, this is not in use. It is described here for informational purposes.
Use of IHE XCA requires an Initiating Gateway to always send document queries to every existing responding gateway. South-Eastern Norway Regional Health Authority covers about half the population in Norway. It is probably not effective to send all queries to all communities. And since our document sharing architecture is not including a national master patient index register, holding information on where to find patients' documents, other measures to optimize queries must be evaluated. A possible solution is to use the IHE standard Cross-Community Patient Discovery (IHE XCPD). IHE XCPD supports the means to locate communities that hold patient relevant health data across communities. The Cross Gateway Patient Discovery transaction ITI-56 supports the ability for Initiating Gateways to request a list of communities which may have healthcare data about the identified patient.
Beskrivelse av IHE XCPD-profil
When an Initiating Gateway receives a document query (ITI-18) for a given patient, it requests all Responding Gateways with an ITI-56 Patient Location Query. Each Responding Gateway must work out whether they have any health data about the requested patient and send a negative or positive response back to the Initiating Gateway. The Initiating Gateway will make a list of communities responding positively, and then send an ITI-38 to these communities. When acquiring/implementing a Responding Gateway, communities should ensure that the solution supports processing an ITI-56 Patient Location Query.