IHE-profielen voor documentdeling (XDS, XCA, XCPD, MHD en verwante)

De IHE-profielen voor documentdeling zijn specificaties van IHE in het domein IT Infrastructure (ITI). Zoals elk IHE-profiel legt een profiel de actoren, transacties en informatie-inhoud voor een use case vast door naar bestaande standaarden te verwijzen.^[14] Het kernprofiel is XDS.b (Cross-Enterprise Document Sharing): het regelt de registratie, verspreiding en raadpleging van elektronische patiëntendossiers over zorginstellingen heen, van een artsenpraktijk tot een acuut ziekenhuis.^[1]

Twee begrippen dragen het hele stelsel. Een XDS Affinity Domain is een groep zorginstellingen die gemeenschappelijke afspraken en een gedeelde infrastructuur hanteert.^[1] Een gemeenschap (community) in de zin van XCA is een groep instellingen met gemeenschappelijke afspraken voor het delen van klinische informatie, herkenbaar aan een wereldwijd unieke homeCommunityId.^[3] XDS werkt binnen een gemeenschap; de cross-community-profielen leggen de brug tussen gemeenschappen, bijvoorbeeld tussen landen.^[2][3]

Patiëntidentificatie, beveiliging en toestemming

PIX koppelt patiëntidentificatoren uit meerdere identificatiedomeinen aan elkaar, maar schrijft zelf geen instellingsbeleid of koppelalgoritme voor; dat blijft bij de Patient Identifier Cross-reference Manager en de instelling.^[17][17] PDQ laat toepassingen een centrale patiëntenserver bevragen op zoekcriteria en de demografische gegevens van een patiënt rechtstreeks ophalen.^[18] ATNA legt de basis van beveiliging vast: authenticatie van knooppunten en gebruikers, auditlogging en versleuteling van de communicatie.^[4] Veel andere IHE-profielen vragen of raden aan om hun actoren met ATNA-actoren te groeperen.^[4] XUA geeft beweringen over een geauthenticeerde gebruiker of toepassing mee in transacties tussen instellingen, zodat de ontvanger over toegang kan beslissen en correct kan auditen.^[19] CT synchroniseert de klokken van computers in een netwerk, wat audit en tijdstempels vergelijkbaar maakt.^[20] BPPC laat een affinity domain een basisvocabularium van codes voor privacybeleid vastleggen en ondersteunt zowel veronderstelde als uitdrukkelijke toestemming.^[21][21]

De mobiele variant: MHD

MHD definieert één gestandaardiseerde API voor documentdeling, bedoeld voor mobiele en andere lichte toepassingen.^[22] Het kan dienen als API bovenop een documentdelingsomgeving met XDS of XCA, of als pushmechanisme naast XDR en XDM.^[22] MHD is gebaseerd op HL7 FHIR: de actuele gepubliceerde versie 4.2.5 steunt op FHIR R4.^[22] mXDE combineert MHD met het profiel QEDm, zodat individuele gegevenselementen uit gedeelde documenten bevraagbaar worden.^[22]

De profielen staan in het IHE IT Infrastructure Technical Framework, dat zoals elk domein-framework door het technische comité van het domein wordt uitgewerkt.^[25] De normatieve final-textprofielen staan in revisie 20, laatst bijgewerkt tot revisie 20.2 op 11 november 2025.^[5] Nieuwe inhoud verschijnt eerst als supplement dat public comment, trial implementation en final text doorloopt, en zodra een specificatie final text is, verbiedt de IHE-governance brekende wijzigingen.^[26][26] IHE stelt de specificaties vrij beschikbaar onder een Creative Commons-licentie.^[27]

De mobiele profielen zijn nog trial-implementationsupplementen. MHD 4.2.5 voor FHIR R4 werd laatst herzien op 18 oktober 2026, en MHD 5.0.0 voor FHIR R5 werd op 19 december 2025 gepubliceerd.^[5][5] PDQm 3.2.0 en PIXm 3.1.0 werden beide op 6 november 2025 herzien.^[5] RESTful ATNA (herzien op 25 november 2025) en APPC (herzien op 2 juli 2021) zijn eveneens trial implementation, net als mXDE (herzien op 4 augustus 2023).^[5][5]

In de Europese lijst voor overheidsopdrachten

Besluit (EU) 2015/1302 laat de IHE-profielen in zijn bijlage in aanmerking komen als referentie in overheidsopdrachten.^[28] Die bijlage begint met XCPD, XCA, XCF en XDR, bevat ook CT, ATNA, BPPC en XUA, en verder PIX, PDQ, XDS.b, XDS-I.b en XDM.^{[28][28][28][28]}

Grensoverschrijdend: MyHealth@EU

In het epSOS-project steunde de uitwisselingsspecificatie op de IHE-profielen XCPD, XCA, XDR en optioneel XCF.^[29] OpenNCP, de referentie-implementatie van het nationale contactpunt, verzorgt de grensoverschrijdende uitwisseling van patiëntsamenvattingen, e-voorschriften, e-afleveringen en medische beelden met IHE-profielen en wordt onderhouden door de Europese Commissie (DG SANTE).^[6][6] XCPD dient daarin voor de grensoverschrijdende identificatie van de patiënt, XCA voor het bevragen en ophalen van documenten en XDR voor het indienen ervan, en van elke verrichting houdt OpenNCP een ATNA-audittrail bij.^[6][6] OpenNCP biedt daarnaast ook FHIR-diensten.^[6] Uitvoeringsverordening (EU) 2026/2083 laat nationale contactpunten die referentie-implementatie gebruiken; kiezen ze een andere oplossing, dan moet die voldoen aan de requirements catalogue en de technische specificaties.^[7] Het EU4Health-project 'Setup BE-NCPeH PS-A' bereidt de aansluiting van België op MyHealth@EU voor; welke software het Belgische contactpunt gebruikt, werd niet gevonden.^[34]

Belgisch voorbereidend werk liep via Brussel: de Europese Commissie mandateerde Abrumet om over vier jaar (2018-2021) de technische haalbaarheid van de Europese uitwisseling van het SUMEHR uit te werken, omdat Abrumet een systeem met internationale IHE-normen kon aanbieden.^[35] Het technische werk voor de dienst PS B (het SUMEHR van een Europese patiënt in België lezen) werd op 20 december 2019 voorgesteld in de werkgroep architectuur van het eHealth-platform.^[35]

In België: de hubs en Brusafe+

De technische interfaces tussen de hubs en met de metahub zijn standaard-webservices ('KMEHR-webservices') waarvan het eHealth-platform de specificaties publiceert.^[8] De hub-metahubarchitectuur definieert als onderdeel van KMEHR twee sets operaties: intrahub en interhub.^[30] Een cookbook van het eHealth-platform, Vitalink, de hubs of MyCareNet dat XDS, XCA, XCPD, ATNA of XUA voorschrijft, werd in de verwerkte bronnen niet gevonden. Een GitHub-project HubsOnFHIR gaat over hoe het hub-metahubsysteem FHIR zal omarmen.^[36] Een niet-officiële referentie-implementatie moderniseert de interhubtransacties getTransactionList en getTransaction naar IHE MHD op FHIR R4.^[37]

Volgens de ontwikkelaarsdocumentatie van 2017 gebruikt de Brusafe+-omgeving IHE XDS-conforme componenten, verloopt de uitwisseling tussen XDS-omgevingen via een XCA-gateway en steunt de communicatie met het Brussels Gezondheidsnetwerk op KMEHR.^[9][9] Een MHD Document Recipient en Document Responder waren toen in ontwikkeling.^[9] Abrumet stelde in 2020 dat de Belgische eHealth enkel KMEHR gebruikt en dat Brusafe+ via XDS/CDA en een mapping de brug slaat naar internationale standaarden.^[38] Het actieplan e-Gezondheid 2019-2021 omschreef Brusafe+ als gestructureerde gegevensuitwisseling volgens sommige door de Europese Commissie erkende IHE-profielen, waarop projecten konden aansluiten met een online cookbook en een open-source testplatform op Gazelle-basis.^[39][39] Datzelfde plan noemde de Brusselse IHE-server met het profiel XDW als mogelijke referentie voor elektronische voorschriften en opdrachten; dat was een voorstel.^[39] Volgens de documentatie van 2017 bestond er in België geen organisatie die een gemeenschappelijke codeset voor XDS-metadata onderhoudt.^[40] Het jaarverslag 2025 stelt dat Brusafe+ aanvankelijk op XDS steunde, naar FHIR evolueerde, en dat alle toekomstige investeringen enkel naar FHIR gaan.^[10]

Software en opleiding

Integratiesoftware levert de profielen als bouwsteen: IPF biedt bouwstenen voor IHE-profielen zoals XDS, PIX, PDQ en XCPD (zie Apache Camel).^[33] Agoria biedt sinds 2016 academies aan over onder meer IHE XDS.^[41]

De EHDS-verordening verplicht de Commissie om tegen 26 maart 2027 het EEHRxF vast te leggen, met onder meer technische interoperabiliteitsspecificaties inclusief standaarden en profielen.^[11] Het ontwerp van de EU Health Data API koppelt de prioritaire categorieën patiëntsamenvatting, testresultaten, ontslagverslag en beeldvorming telkens aan documentuitwisseling via MHD, en laat de workflow van e-voorschrift en e-aflevering aan IHE MPD.^[12][12] Dat ontwerp is een voorstel van HL7 Europe en IHE Europe waarover de Commissie en de lidstaten nog moeten beslissen.^[13]

• Verplichting: geen Belgische regel die een ziekenhuis een IHE-documentdelingsprofiel oplegt werd in de verwerkte bronnen gevonden; de nationale uitwisseling via de hubs loopt over KMEHR-webservices.^[8]
• Aankoop: XDS.b, XCA, XCPD, XDR, XDM, PIX, PDQ, ATNA, XUA, CT en BPPC komen sinds 2015 in aanmerking als referentie in overheidsopdrachten.^[28][28][28]
• Grensoverschrijdend: wat een ziekenhuis via MyHealth@EU bereikt, loopt in de referentiesoftware via XCPD, XCA en XDR op het niveau van het nationale contactpunt, niet rechtstreeks vanuit het ziekenhuis.^[6][6]
• Toekomst: het Europese ontwerp zet MHD op FHIR centraal voor documentuitwisseling, maar dat is nog niet beslist.^[12][13]
• Aanbeveling (eigen): vraag aan EPD-, PACS- en integratieleveranciers welke actoren van XDS.b, XCA, PIX/PDQ, ATNA en MHD hun product ondersteunt en of MHD op FHIR R4 op de roadmap staat; zo blijft een latere aansluiting op een Europees of FHIR-gebaseerd kanaal mogelijk zonder het documentbeheer te vervangen.

• Europese profielkeuze open: de uitvoeringsverordening laat conforme alternatieven voor de referentiesoftware toe, en de profielen van de requirements catalogue en de technische specificaties werden niet gevonden.^[7]
• Status van Brusafe+: de documentatie van 2017 beschrijft XDS en een XCA-gateway, het jaarverslag 2025 een evolutie naar FHIR; of er nog XDS-componenten draaien, is niet vastgesteld.^[9][10]
• MHD in België niet officieel: de MHD-modernisering van de interhubtransacties is een niet-officiële referentie-implementatie, geen gepubliceerde specificatie van het eHealth-platform.^[37]
• Belgisch contactpunt: welke software en dus welke profielen het Belgische contactpunt gebruikt, werd niet gevonden.^[34]