Titel Het combineren van FHIR en IHE XDS

Dit artikel beschrijft hoe de beste eigenschappen van IHE XDS kunnen worden gecombineerd met de beste eigenschappen van FHIR. In het artikel laten we de Twiin en OTV-projecten even buiten beschouwing, inhoudelijk conflicteren die echter niet met wat er in dit artikel beschreven wordt.

De basiskenmerken van XDS en FHIR

Het IHE XDS workflow profiel beschrijft een architectuur voor de opslag en uitwisseling van documenten. De kern van het architectuurmodel is dat de metadata, de beschrijvende informatie van een document, wordt beheerd en opgeslagen in een apart register, los van de opslag van de documenten. Deze combinatie van een gedistribueerde documenten opslag met een centraal metadata register maakt het mogelijk relatief eenvoudig via het metadata register documenten te vinden en deze bij het juiste opslagsysteem op te halen.

Het begrip ‘document’ moet overigens breed begrepen worden in de context van XDS, in wezen gaat het om blobs met een mime-type, die een auteur/samensteller hebben. Voorbeelden van XDS-documenten zijn PDF/A, diagnostische beelden, video opnames, CDA-documenten, FHIR Questionnaires (vragenlijsten) of bundles (groeperingen) met FHIR-resources.

De FHIR-standaard wordt met name toegepast voor het uitwisselen van Resources (kleine informatie modellen) tussen zorgapplicaties, meestal op basis van REST. Om deze reden wordt FHIR met name ingezet om workflow processen te ondersteunen. FHIR ondersteunt tevens de uitwisseling van FHIR Documenten (een FHIR-variant van de oudere HL7 CDA e-document standaard), en de uitwisseling van bundles bestaande uit meerdere FHIR Resources.

De FHIR-standaard bevat Resource definities die context onafhankelijk zijn, en om die reden zijn de meeste data elementen in zo’n Resource optioneel. Als FHIR wordt toegepast in een bepaalde context (zoals: Nederland, MedMij of het LSP) dan moet nader worden vastgelegd (in FHIR Profielen en Implementatie Gidsen) hoe een FHIR Resource wordt ondersteund / moet worden ondersteund.

Record Locator Service

Zowel de verwijsindex van de LSP als het metadata register van XDS bieden de functie van een RLS (Record Locator service). Een Record Locator Service "provides the ability to identify where records are located based upon criteria such as a Person ID and/or record data type. It provides a key function en route to retrieval of information of interest by identifying candidate locations from which to retrieve. Retrievals may be simply Person-ID associated or optionally metadata-constrained, allowing for more narrowly focused location capabilities (based upon metadata items such as creator, category, source, size, format, language, dates, etc.)"

Een RLS kan relatief weinig informatie bevatten (zoals in het geval van het LSP) of rijk zijn voorzien van metadata (zoals in het geval van XDS). XDS (en de FHIR DocumentReference metadata resource) bevatten informatie over de vindplaats van één specifiek document, daar waar het LSP informatie bevat over de vindplaats van categorieën van informatie.

Een RLS kan op zichzelf staan (bijvoorbeeld in een specifieke XDS gebaseerde zorgregio), of weet hebben van het bestaan van andere RLS oplossingen (bijvoorbeeld van het LSP, of van andere zorgregio’s met behulp van IHE XCA). De inhoud van een RLS kan privacy gevoelige informatie bevatten, waardoor het meestal als routeringsmechanisme wordt ingezet: de vraag naar informatie van een zorgpartij wordt via de RLS (of: een infrastructuur die gebruikt maakt van een RLS) gerouteerd aan die organisaties waarvan bekend is dat zij relevante informatie bezitten.

Op het moment van schrijven is er nog geen generieke oplossing voor RLS (noch in FHIR, noch in IHE). Het zou zeker mogelijk moeten zijn nationale afspraken te maken op het gebied van RLS die compatibel zijn met IHE XCA (de IHE-implementatie van een RLS) en met de verwijsindex (de VZVZ implementatie van een RLS). Wellicht dat het programma Twiin hierin een rol kan spelen.

On-demand FHIR bundles

Voor het modelleren van zorginformatie wordt in Nederland gebruik gemaakt van ZIBs (Zorg Informatie Bouwstenen). Dit zijn conceptuele- of businessmodellen, die vastleggen wat inhoudelijk gezien de kenmerken zijn van een zorgbegrip zoals “allergieën”. Een ZIB kan worden afgebeeld op een willekeurige interoperabiliteitsstandaard, zoals op CDA, FHIR, HL7 versie 2 of desnoods Edifact. Zeker bij afbeelding op modernere standaarden als CDA of FHIR gaat bij zo’n afbeelding geen informatie verloren.

Een ZIB correspondeert veelal met 1 of meer FHIR Resources, die elk geprofileerd zijn voor deze ZIB-context. In Nederland zijn er gegevenssets (bijv. de BgZ, Basisgegevensset Zorg) die gebaseerd zijn op een collectie ZIBs. Het equivalent van een gegevensset is in FHIR is een bundle met een collectie geprofileerde FHIR Resources.

Deze FHIR bundles kunnen via IHE XDS worden uitgewisseld, want het zijn documenten in de zin van XDS. Het is op die manier mogelijk via XDS een BgZ van een patiënt te delen, dan wel via XDS een door anderen ter beschikking gestelde BgZ op te halen. Om te voorkomen dat de BgZ “te oud” is kan gebruik gemaakt worden van de “on-demand” optie in XDS, die het mogelijk maakt een document pas aan te maken op het moment dat het wordt opgevraagd. Daarmee wordt de mogelijkheid geboden altijd een actuele BgZ op te kunnen vragen.

Het LSP, dat qua architectuur op hoofdlijnen overeenkomt met die van XDS in combinatie met on-demand documenten, gaat naast het huidige HL7 versie 3 koppelvlak een FHIR-koppelvlak aanbieden, met automatische vertaalmogelijkheid van/naar FHIR. Het LSP heeft recent succesvol een MedMij certificeringproces ondergaan en de naam is veranderd van LSP naar LSP+. De beschikbare informatie zal in de vorm van bundles van FHIR-resources worden gedeeld, waarbij zo veel als mogelijk gebruik zal worden gemaakt van ZIBs.

Een opgevraagde FHIR bundle (bijv. een BgZ via XDS, of een medicatielijst via het LSP+) kan of worden getoond aan een zorgverlener (al is daar wel speciale functionaliteit voor nodig), of de inhoud kan gedeeltelijk worden overgenomen in het eigen xIS systeem (zie figuur 1). Stel men heeft al weet van 2 allergieën, en de BgZ van een andere instelling noemt nog een derde allergie. Indien die andere instelling als betrouwbare bron wordt gezien dan zul je die extra allergie in je eigen systeem willen overnemen. Uiteraard zal de originele gegevensbron van deze ene allergie wel bekend moeten blijven in het xIS waarin de gegevens worden opgeslagen. In FHIR wordt de gegevensbron en eventuele latere bewerkers overigens vastgelegd door middel van de Provenance resource.

MHD of FHIR Facade?

IHE heeft een FHIR gebaseerde API beschreven voor een XDS-omgeving: MHD (Mobile access to Health Documents). Deze heeft tot oogpunt dezelfde functionaliteit te bieden als de huidige Webservices gebaseerde functionaliteit van XDS. Leveranciers van XDS-omgevingen/toolkits bieden vaak ook een MHD gebaseerde FHIR API aan.

XDS en FHIR/XDS verschillen op een aantal punten, waarbij we de volgende met name willen noemen:

• In XDS wordt de metadata beschreven met behulp van de ebRM standaard (een XML-formaat). De metadata worden in FHIR uitgedrukt als een DocumentReference resource. Deze zijn inhoudelijk gelijk, er is een volledige afbeelding mogelijk van de XDS-metadata op de DocumentReference resource. Omgekeerd is dit niet per definitie mogelijk.
• Daar waar XDS gebruikt maakt van Webservices maakt FHIR gebruik van REST als communicatieprotocol. Qua functionaliteit zit daar niet zoveel verschil tussen, toch zijn er met name rond de foutafhandeling een aantal fundamentele verschillen.
• XDS maakt gebruik van SAML-tokens voor de uitwisseling van authenticatie en autorisatie gegevens. SAML is met name geschikt voor het uitwisselen van autorisatie gegevens tussen backend systemen. OAuth2 is met name geschikt om de autorisatie en identificatie van gebruikers en hun Apps met derden uit te wisselen. Interoperabiliteit tussen OAuth en SAML 2.0 implementaties is daarbij niet vanzelfsprekend. Om dit te laten werken in de praktijk zijn goede afspraken nodig op (inter)nationaal niveau.

MHD heeft echter ook een aantal nadelen. De specificatie is bijvoorbeeld beschreven vanuit de visie van XDS, het is niet geoptimaliseerd vanuit een FHIR-implementatie filosofie. XDS-leveranciers hebben veelal de neiging de MHD-specificaties redelijk minimalistisch te implementeren (zie figuur 1), wat an sich begrijpelijk is als men XDS als ijkpunt gebruikt. Met een FHIR mindset zijn er veel meer dingen mogelijk dan alleen dat wat MHD te bieden heeft, zoals een full-text zoekmogelijkheid, geïntegreerde functionaliteit rond vragenlijsten (FHIR Questionnaires), de extractie van één specifieke ZIB uit een FHIR-gegevensset, een eenvoudig Subscription mechanisme, en het combineren van FHIR-resources afkomstig uit een XDS-context met FHIR-resources uit andere bronnen.

Er zijn twee manieren om de functionaliteit van XDS zo goed mogelijk op een FHIR manier uit te wisselen:

• Gebruik wil maken van de MHD-functionaliteit zoals geleverd door een softwareleverancier, en de gegevens zelf verrijken/aanvullen met FHIR-tools. Een voorbeeld is dat de MHD-interface de gegevens van de auteur en de patiënt oplevert zoals die waren ten tijde van het opstellen van het document. Dit soort gegevens zou je willen vervangen door een FHIR-referentie naar de laatste patiënt/auteurs gegevens zoals opgenomen in een persoonsregister of xIS systeem.
• Gebruik maken van een FHIR Facade voor XDS (figuur 2), een toolkit van een andere aanbieder dan die van de XDS-software, die de mogelijkheden van de klassieke XDS webservices interface op een zo FHIR-achtige mogelijke manier omzet in een FHIR REST API. Met behulp van deze Facade zijn metadata zoals zorgverlener, zorgaanbieder uit centrale registers, of opnamegegevens uit een xIS eenvoudiger te “hergebruiken”.

Overigens komt ook vanuit de IHE-community een groeiende vraag naar een meer FHIR-achtige benadering rond het uitwisselen van metadata en documenten. De eerste gedachten daarover heeft men op papier gezet (onder de naam MHDS, Mobile Health Document Sharing) en in een whitepaper die in het 1e kwartaal van 2020 gepubliceerd zal worden.

Conclusie

Bij een combinatie van FHIR en XDS en/of het LSP+ zal gebruik gemaakt worden van ‘ZIB gebaseerde bundles met FHIR-resources’. FHIR wordt daarnaast met name ingezet om workflow processen te ondersteunen, denk aan de PGOs, apps voor zorgverleners, het maken van afspraken, en order communicatie.

Naar verwachting zullen hybride modellen ontstaan waarin het beste van FHIR en het beste van XDS naar boven zullen komen. Dit vereist nadere afspraken op (inter)nationaal niveau die niet alleen technisch van aard zijn. De combinatie van beide benaderingen lijkt een goede stap vooruit om verdere interoperabiliteit in Nederland te bereiken.

René Spronk (Firely/Ringholm) en Robert Breas (MedicalPHIT)

Dit artikel is ook verschenen in HL7 Highlights Magazine #16

{phocadownload view=file|id=263|target=s}