OMOP CDM en OHDSI

Soort: datamodel voor analyse. De OMOP CDM is een open community-datastandaard om structuur en inhoud van observationele data te standaardiseren, zodat analyses betrouwbare evidentie opleveren^[1]. Het model is persoonsgericht: alle klinische event-tabellen hangen aan de PERSON-tabel voor een longitudinaal beeld^[9]. De OHDSI Standardized Vocabularies zijn een centraal onderdeel^[1]. Per klinisch event wordt één Standard Concept gekozen; bij aandoeningen is dat SNOMED, en ICD- of andere broncodes worden erop gemapt^[10]. Die omzetting heet "mapping"; niet-standaardconcepten blijven als source concepts bewaard^[10]. Standaardconcepten worden op zichzelf gemapt, niet-standaardconcepten op standaardconcepten^[10]. Technisch schrijft de CDM geen specifieke technologie voor: ze kan in elke relationele database of als SAS-analysedatasets worden gerealiseerd^[9].

Door data van verschillende bronnen in één model en vocabularium te brengen, worden gefedereerde analyses over instellingen heen mogelijk: het OHDSI-datanetwerk steunt op de OMOP CDM^[11]. OMOP hoort in het domein van longitudinale analyse en verkiest vergelijkbaarheid tussen sites boven bronfideliteit^[12]. OMOP past beter bij analyse dan bij operationele uitwisseling^[13][12]; zie FHIR, openEHR en OMOP: vergelijking voor de verhouding tot HL7 FHIR en openEHR.

• Organisatie: OHDSI werd in 2014 opgericht als voortzetting van het OMOP-partnerschap^[11]; het coördinatiecentrum zit aan Columbia University^[11]. De CDM wordt beheerd door de OHDSI CDM Working Group ^[1]. OHDSI heeft in de Atlas geen aparte pagina; deze pagina behandelt zowel de CDM als de community.
• Versie: v5.5 is de huidige versie^[1]. Ze voegt enkel niet-verplichte velden en vocabulariummetadata toe, zonder iets te verwijderen of te hernoemen t.o.v. v5.4^[14]. Niet alle OHDSI-tools ondersteunen al de v5.5-elementen^[1].
• Europees: het IMI-EHDEN-project (vanaf november 2018) harmoniseerde Europese real-world data met OMOP; de EHDEN Foundation zet dit voort^[15] met als missie een gefedereerd netwerk van OMOP-databronnen in Europa ^[16]. EHDEN telt 187 datapartners uit 29 landen^[2]. DARWIN EU (EMA) laat zijn datapartners alle data naar OMOP standaardiseren^[17].

• OHDSI-node: volgens OHDSI Europe ontstond de Belgische node spontaan uit de Belgische EHDEN-gemeenschap; de node beschrijft zichzelf als een van de meest actieve in Europa (zelfbeschrijving)^[18]. Ze wil OMOP-implementatie versnellen en Belgische uitdagingen aanpakken zoals nationale vocabularia en ziekenhuisnetwerken ^[18]. De node brengt ziekenhuizen, onderzoeksinstellingen, kmo's, overheidsinstanties en middenveldorganisaties samen^[18], met een lichte governance: een Core Group en werkgroepen ^[18]. Doelen zijn onder meer duurzame OMOP-adoptie in Belgische ziekenhuizen en de afstemming van Belgische datamodellen en vocabularia op de OHDSI-standaarden^[18]. Daarvoor bestaat een 'BE Vocabulary & Terminology Alignment Working Group', naast een Oncology Working Group^[18].
• EHDEN-datapartners: EHDEN vermeldt (raadpleging 25 september 2026) 14 Belgische datapartners, zowel ziekenhuizen als bedrijven^[2]. De actuele namenlijst staat op de EHDEN-partnerpagina. Afwezigheid op die lijst zegt enkel iets over EHDEN-partnerschap, niet over eventueel ander OMOP-gebruik (interpretatie).
• DARWIN EU-datapartners: EMA publiceert een lijst van DARWIN EU-datapartners die in jaar I tot V werden onboard (document EMA/136956/2026 van 16 juni 2026); de lijst wordt doorlopend bijgewerkt^[3]. Op die lijst van 40 staan drie Belgische vermeldingen, volledig volgens de bron: het Belgisch Kankerregister ^[3], de IQVIA Longitudinal Patient Database Belgium (LPD) van IQVIA Solutions BV^[3] en een databank van het Universitair Ziekenhuis Antwerpen^[3]. Peildatum: 16 juni 2026.
• Ziekenhuisnetwerken: een verslag van de OHDSI Belgium-webinar 'FHIR x OMOP' (16 maart 2026) noemt vijf Belgische OMOP-netwerken: SPECTRA in Brussel, INAH in Wallonië, MOVE in Luik, en FHIN en Levilo in Vlaanderen. Ze zijn technisch op elkaar afgestemd en er lopen gesprekken over convergentie naar één gefedereerd netwerk^[4]. FHIN is een netwerk van negen ziekenhuizen^[5] dat data met RiAB omzet volgens de ETL-conventies van OMOP CDM 5.4^[5]. Het door Data Capabilities gefinancierde project DPI4INAH haalt met LLM's gegevens uit ongestructureerde ziekenhuisdocumenten, codeert ze in SNOMED CT en mapt ze daarna naar OMOP voor de ziekenhuizen van het MOVE-netwerk^[4]. Volgens het verslag investeerde België 20 miljoen euro in Data Capabilities-subsidies (2023-24) en 20 miljoen euro in Innovation-subsidies (2024-25)^[4]. Het bedrag geldt voor de oproepen in het algemeen, niet enkel voor OMOP-netwerken (interpretatie).
• Beleidskeuze (secundaire bron): volgens het webinarverslag maakte België de keuze FHIR + SNOMED CT voor primair gebruik en OMOP voor secundair gebruik; dat is een samenvatting door de organisatoren, geen overheidsdocument ^[4]. De beleidsvisie werd er gebracht door een adviseur van het kabinet van de minister van Volksgezondheid, die de keuze onder meer motiveerde met de wereldwijde gemeenschap, beschikbare FHIR-naar-OMOP-engines en de koppeling met EHDEN en DARWIN EU^[4]. Zie de tegenstrijdigheid met de HDA-whitepaper hieronder.
• Leveranciersstandpunt: volgens de spreker van een softwareleverancier op dezelfde webinar moeten ziekenhuizen OMOP niet zelf implementeren, omdat de Belgische wetgeving al FHIR-gereedheid vraagt en de leverancier de FHIR-naar-OMOP-conversie op zich neemt^[4]. Dat is een vendorclaim.
• HDA: het door de Health Data Agency gefinancierde innovatieproject FHIN-LLM wil ongestructureerde teksten omzetten naar gestructureerde data met standaarden zoals SNOMED CT/OMOP^[19]; het is een van de vier projecten uit de oproep van 2024^[19]. Het gaat om een innovatieproject, niet om een nationale keuze voor OMOP (interpretatie).
• Terminologie: in OMOP zijn SNOMED CT-concepten zelf de standaardconcepten voor aandoeningen; ICD- en andere broncodes worden daarop gemapt^[10]. Dat ICD-10-BE-codes als broncodes gemapt moeten worden, is een afleiding (interpretatie). België koos voor een nationale LOINC-subset en ReTaM^[20]; healthdata.be gebruikt voor labresultaten LOINC met voorrang voor de ReTaM-subset^[21].
• Athena-vocabularia: de OHDSI Vocabulary-wiki houdt een lijst bij van alle vocabularia in de OHDSI Standardized Vocabularies^[7]. Daarin is het Gecommentarieerd Geneesmiddelenrepertorium van het BCFI opgenomen als vocabularium 'GGR', actief, laatste refresh 2022^[7]. LPD_Belgium (IQVIA) staat er als 'Abandoned', laatste refresh 2021^[7]; het beschrijft geneesmiddelen op de Belgische markt onder licentie van IQVIA, met niet-standaardconcepten die grotendeels op RxNorm, RxNorm Extension of CVX worden gemapt^[22]. Landspecifieke ICD-10-uitbreidingen zoals ICD10CM en ICD10GM zijn aparte vocabularia, maar een ICD-10-BE-vocabularium staat niet in de lijst^[23]. Het OHDSI-vocabularium SNOMED steunt op de International, US en UK Edition; een Belgische editie of extensie wordt niet genoemd^[24]. De RIZIV-nomenclatuur en CNK werden evenmin gevonden (gap, geen bewijs van afwezigheid).
• Mappingkwaliteit (onderzoek): een Belgische poster op het OHDSI Europe Symposium 2026 evalueerde de automatische ICD-10-naar-SNOMED CT-mappings van Athena voor 34 codes; 22 (64,7%) kwamen exact overeen met een manuele expertmapping^[25]. De ICD-10-codes kwamen daarbij uit de ICD-10-CM-browser^[25]. In een FHIN-studie werd C34.1 naargelang de 4- of 5-cijferige variant naar verschillende OMOP-concepten gemapt ^[26].

• Geen OMOP-verplichting gevonden: OMOP was in de HealthData@EU-pilot een optie, geen verplichting ^[27]; een academisch raamwerk noemt OMOP voor EHDS-secundair gebruik, maar als voorstel^[13].
• Toekomstige EU-verplichting (los van OMOP): de EHDS-verordening is van toepassing vanaf 26 maart 2027 ^[8]; hoofdstuk IV (secundair gebruik) geldt vanaf 26 maart 2029^[8]. Vanaf dan zullen gegevenshouders onder meer EPD-gegevens beschikbaar moeten stellen voor secundair gebruik^[8]; enkele categorieën van art. 51(1) volgen pas vanaf 26 maart 2031^[8]. Een verwijzing naar OMOP als verplicht datamodel werd daarbij niet gevonden (gap).
• EHDS-kwaliteitslabel: het kwaliteits- en bruikbaarheidslabel (art. 78) omvat voor datadocumentatie onder meer metadata, het datawoordenboek, de formaten en standaarden en, waar van toepassing, het datamodel; een specifiek datamodel zoals OMOP wordt niet voorgeschreven^[8]. Datasets die met Unie- of nationale publieke financiering werden verzameld, moeten zo'n label dragen^[8]; de Commissie legt de technische specificaties uiterlijk 26 maart 2027 vast^[8]. Een TEHDAS2-ontwerprichtlijn (april 2026) noemt OMOP als nuttig hulpmiddel om terminologieverschillen te overbruggen, als ontwerp en niet als verplichting ^[28].
• Netwerk: er bestaat een Belgische OHDSI-node, ontstaan uit de EHDEN-gemeenschap^[18], en vijf Belgische ziekenhuisnetwerken werken met OMOP^[4].
• Financiering: volgens het webinarverslag moeten toekomstige FOD-oproepen Data Capabilities en Innovatie de financiële duurzaamheid van de netwerken verzekeren^[4].
• Aanbeveling: overweeg een OMOP-kopie pas na een duidelijke onderzoeksvraag of netwerkdeelname (bv. EHDEN of de Belgische OHDSI-node); investeer eerst in codering aan de bron (SNOMED CT, LOINC) en een onderhouden mapping van lokale en Belgische codes, en wissel ervaringen uit met Belgische ziekenhuizen die al EHDEN-datapartner zijn of aan een Belgisch OMOP-netwerk deelnemen. Toets een leveranciersaanbod voor FHIR-naar-OMOP-conversie aan de bekende informatieverliezen.

• De omzetting vanuit FHIR kan niet verliesvrij zijn (fideliteit, informatie, relaties, accuraatheid) ^[12]. De HL7 FHIR-to-OMOP IG v1.0.0 is informatief, gebaseerd op R5 en US Core, met v5.4 als doel ^[12], terwijl Belgische IG's R4 zijn^[29]. Een bevinding uit DPI4INAH is dat een naïeve FHIR-naar-OMOP-mapping klinisch belangrijke informatie verliest, bv. bij allergieën de klinische status, de ernst van de reactie en de blootstellingsroute^[4].
• Mapping vanuit ICD-10-codes is foutgevoelig: in een FHIN-studie werd bij de eerste datakwaliteitstest slechts ongeveer de helft van de patiënten succesvol gemapt^[26].
• Mappingrelaties komen uit externe bronnen of worden manueel onderhouden en zijn daardoor niet perfect ^[10]; de vocabularia worden doorgaans per kwartaal ververst^[10]. Een lokale mapping vraagt dus periodiek nazicht (interpretatie).

• De FHIR-to-OMOP IG noemt v5.4, OHDSI v5.5; dit is een tijdsverschil, geen inhoudelijke tegenspraak ^[12][1][14].
• Belgische beleidskeuze voor OMOP: tegenstrijdige signalen. Volgens het verslag van de OHDSI Belgium-webinar (maart 2026) stelde een kabinetsadviseur dat België voor secundair gebruik expliciet voor OMOP koos ^[4]. Een whitepaper die in augustus 2025 op de HDA-website verscheen^[30], stelt daarentegen een nationaal gezondheidsdatamodel voor met uniforme semantiek voor primair en secundair gebruik ^[6], met terminologie zoals SNOMED of LOINC en een structuur op basis van FHIR, zonder OMOP te noemen ^[6]. De whitepaper is een voorstel, geen beleid^[6], en het webinarverslag is een secundaire weergave van een mondelinge toelichting^[4]. Een primair HDA-, FOD- of kabinetsdocument dat OMOP vastlegt, werd niet gevonden (gap). Beide kunnen verenigbaar zijn als FHIR het bronmodel en OMOP het analysemodel is (interpretatie).
• Beschikbaarheid van ICD-10-BE, CNK/SAM, de RIZIV-nomenclatuur en de Belgische SNOMED CT-extensie in OHDSI Athena: niet gevonden^[23][24]; enkel GGR en LPD_Belgium zijn Belgisch^[7].
• De DARWIN EU-lijst en de EHDEN-lijst zijn momentopnames (16 juni 2026, resp. 25 september 2026) ^[3][2].
• De releasedatum van v5.5.0 (augustus 2026) staat enkel in de metadata van de GitHub-releasepagina, niet in de brontekst; ze wordt daarom niet als feit vermeld.