Interoperabilità dei dati in sanità: FHIR, OMOP e openEHR
Nel mondo della sanità digitale, la gestione dei dati è la sfida più complessa. Per decenni, le informazioni cliniche sono rimaste intrappolate in “silos digitali”: sistemi informativi ospedalieri che non comunicano tra loro, database di ricerca incompatibili e applicazioni mobili isolate.
Per risolvere questo problema, sono emersi diversi standard, ma tre nomi ricorrono più di frequente: FHIR, OMOP CDM e openEHR.
Spesso vengono confusi o messi in competizione, ma la verità è che non sono affatto concorrenti. Svolgono lavori radicalmente diversi e, di fatto, funzionano al meglio quando collaborano.
Capire la differenza è essenziale per chiunque voglia costruire, acquistare o utilizzare tecnologia in ambito sanitario. Analizziamoli in dettaglio, con un linguaggio semplice ma formale, e con esempi pratici.
1. FHIR (Fast Healthcare Interoperability Resources): L’Interprete Universale
Cosa è?
FHIR (pronunciato “fire”) è, prima di tutto, uno standard di interoperabilità. È gestito dall’organizzazione internazionale HL7.
Il suo obiettivo non è archiviare i dati in un formato specifico, ma definire un linguaggio comune e un metodo (un’API RESTful) per scambiare dati sanitari tra sistemi diversi in modo rapido ed efficiente.
Pensate a FHIR come a un traduttore universale o a un adattatore di corrente. Non gli importa come l’elettricità è generata (openEHR) o come è catalogata in un magazzino (OMOP); gli importa solo di farla passare dalla presa al dispositivo (da sistema A a sistema B).
Come funziona?
FHIR scompone i dati sanitari in “mattoncini” logici chiamati Risorse (Resources). Esiste una Risorsa per Patient, una per Observation (es. una glicemia), una per MedicationRequest (una prescrizione), e così via. Ogni risorsa definisce una struttura dati semplice e moderna (spesso in formati JSON o XML).
Esempio Pratico
Scenario: Un paziente diabetico vuole usare un’app sul proprio smartphone per visualizzare gli ultimi esami di laboratorio eseguiti presso l’ospedale locale.
Come agisce FHIR:
L’app del paziente (Sistema A) invia una richiesta sicura al server dell’ospedale (Sistema B).
La richiesta, formattata secondo lo standard FHIR, dice: “Per favore, dammi tutte le Risorse
Observationdi tipo ‘glicemia’ per la RisorsaPatientcon ID ‘XYZ'”.Il server dell’ospedale, che “parla” FHIR, capisce la richiesta, recupera i dati (da qualsiasi database interno stia usando) e li restituisce all’app nel formato standard della Risorsa
Observation.L’app visualizza i dati al paziente.
In sintesi: FHIR è lo standard leader per l’interscambio di dati in tempo reale.
2. OMOP Common Data Model (CDM): La Biblioteca Standardizzata per la Ricerca
Cosa è?
L’OMOP CDM (Common Data Model) è un modello dati, ovvero uno schema di database standardizzato. È mantenuto dalla community OHDSI (Observational Health Data Sciences and Informatics).
Il suo obiettivo è risolvere un problema diverso: la ricerca su larga scala. I dati clinici nel mondo reale sono eterogenei e “disordinati”. L’OMOP CDM fornisce una struttura di archiviazione comune in cui questi dati eterogenei possono essere trasformati e armonizzati.
Pensate a OMOP come alla planimetria standard per una biblioteca di ricerca. Non importa se i libri provengono da diverse case editrici o nazioni; una volta arrivati in biblioteca, vengono tutti catalogati con lo stesso sistema (Dewey Decimal) e messi negli stessi scaffali predefiniti (“Storia”, “Scienza”, ecc.).
Come funziona?
OMOP definisce un set di tabelle (es. PERSON, CONDITION_OCCURRENCE, DRUG_EXPOSURE). Il processo cruciale è l’ETL (Extract, Transform, Load): i dati grezzi dei sistemi sorgente vengono estratti, trasformati nel formato OMOP e caricati nelle sue tabelle.
Un pilastro di OMOP sono i Vocabolari Standardizzati (come SNOMED, LOINC, RxNorm). Tutti i concetti clinici vengono “tradotti” in codici standard, garantendo l’interoperabilità semantica.
Esempio Pratico
Scenario: Un consorzio di ricerca internazionale vuole studiare se un farmaco antipertensivo (Farmaco A) aumenta il rischio di diabete in pazienti sopra i 60 anni. Devono analizzare i dati di 10 milioni di pazienti provenienti da 20 ospedali diversi.
Come agisce OMOP:
Ogni ospedale non condivide i propri dati grezzi (per privacy e incompatibilità).
Invece, ogni ospedale esegue un processo ETL per mappare i propri dati locali (es. “pressione alta”, “ipertensione”, “codice diagnosi XYZ”) nel database OMOP.
Nello standard OMOP, tutte queste diagnosi diventano lo stesso codice standard (es. SNOMED CT: 38341003 per “Hypertensive disorder”). Tutte le prescrizioni del Farmaco A finiscono nella tabella
DRUG_EXPOSURE.I ricercatori possono ora inviare una singola query (analisi) che funziona identicamente su tutti e 20 i database OMOP, ottenendo un risultato statistico robusto e aggregato.
In sintesi: OMOP è lo standard leader per l’analisi di dati osservazionali e la ricerca (uso secondario).
3. openEHR: Le Fondamenta Dettagliate della Cartella Clinica
Cosa è?
openEHR (pronunciato “open-air”) è una specifica architetturale aperta per le cartelle cliniche elettroniche (CCE). Il suo obiettivo è archiviare i dati clinici alla fonte (uso primario) con il massimo dettaglio, garantendo che siano comprensibili e utilizzabili per decenni.
È il più complesso dei tre, ma anche il più potente in termini di precisione clinica. Non è solo un modello dati, ma un intero ecosistema per definire i dati.
Pensate a openEHR come ai progetti di ingegneria civile per un ospedale. Non definisce solo che “c’è un reparto”, ma definisce nel dettaglio le fondamenta, l’impianto elettrico, quello idraulico (il Reference Model) e fornisce i progetti standardizzati per “Sala operatoria” o “Stanza di degenza” (Archetypes).
Come funziona?
openEHR utilizza un’architettura unica a due livelli:
-
Reference Model (RM): Un modello di base stabile, tecnico, che definisce la struttura generica dei dati (es. “un dato ha un nome, un valore, un orario”).
-
Archetypes & Templates (Archetipi): Sono il cuore di openEHR. Gli archetipi sono definizioni cliniche formali e riutilizzabili, create da medici ed esperti, che definiscono come deve essere registrato un concetto clinico. Ad esempio, esiste un archetipo per la “Pressione Arteriosa” che include campi obbligatori per “Sistolica”, “Diastolica”, “Posizione del paziente”, “Misurata con”.
Questo approccio separa la conoscenza clinica (che si evolve) dalla struttura tecnica (che è stabile), rendendo il sistema “a prova di futuro”.
Esempio Pratico
Scenario: Un cardiologo in un ospedale deve documentare i risultati di un ECG (elettrocardiogramma).
Come agisce openEHR:
Sistema Tradizionale: Il medico potrebbe avere un campo di testo libero (“Note ECG”) o alcuni campi base (es. “Ritmo”). I dati sono poco strutturati e difficili da analizzare.
Sistema openEHR: La CCE utilizza l’archetipo “ECG Result”. Questo modello impone al medico (o al macchinario) di registrare dati specifici in campi strutturati: “Frequenza cardiaca”, “Intervallo PR”, “Durata QRS”, “Asse”, “Interpretazione testuale”, ecc.
Il risultato è un dato incredibilmente ricco, preciso e semanticamente definito al momento della sua creazione.
In sintesi: openEHR è lo standard leader per la modellazione clinica dettagliata e l’archiviazione a lungo termine dei dati (uso primario).
Confronto Chiave: La Metafora della Casa
Per consolidare le idee, usiamo una metafora:
-
openEHR sono i progetti architettonici e le fondamenta della vostra casa. Definisce in modo granulare dove si trova ogni mattone, ogni cavo elettrico e ogni tubo dell’acqua. È costruito per durare 100 anni e per essere la fonte della verità su come è fatta la casa.
-
OMOP CDM è il modello standardizzato dell’agenzia immobiliare per descrivere la vostra casa (e tutte le altre del quartiere). Non gli importa come sono posati i tubi; gli importa solo sapere: “Numero di bagni: 2”, “Numero di stanze: 5”, “Riscaldamento: Sì/No”. Serve per confrontare e analizzare molte case contemporaneamente.
-
FHIR è il servizio di posta e corrieri. Non possiede la casa (openEHR) e non gestisce l’inventario (OMOP), ma è il servizio standardizzato che permette a chiunque (con il permesso) di chiedere e ricevere informazioni specifiche: “Mandami la bolletta del gas di questa casa” o “Dimmi il colore della porta d’ingresso”.
Tabella Riassuntiva
Conclusione: Non Competizione, ma Collaborazione
La domanda non è mai “FHIR o OMOP o openEHR?”. La domanda giusta è “Come usiamo FHIR, OMOP e openEHR?”.
In uno scenario sanitario ideale, questi sistemi lavorano insieme:
-
I dati di un paziente vengono creati e archiviati con la massima precisione clinica in una CCE basata su openEHR.
-
Quando il paziente apre la sua app per la pressione, l’app usa FHIR per richiedere gli ultimi dati dalla CCE openEHR.
-
Di notte, un processo ETL trasforma i dati dettagliati di openEHR (e di altri sistemi) nel formato OMOP CDM e li carica in un database di ricerca.
-
I ricercatori possono così condurre studi su larga scala utilizzando i dati OMOP, sapendo che la fonte originale (openEHR) era di altissima qualità.
English version
Beyond Data Chaos: Demystifying FHIR, OMOP, and openEHR
In the world of digital health, data management is the most complex challenge. For decades, clinical information has been trapped in “digital silos”: hospital information systems that don’t talk to each other, incompatible research databases, and isolated mobile applications.
To solve this problem, several standards have emerged, but three names appear most frequently: FHIR, OMOP CDM, and openEHR.
They are often confused or pitted against each other, but the truth is they are not competitors at all. They perform radically different jobs and, in fact, work best when they collaborate.
Understanding the difference is essential for anyone looking to build, buy, or use healthcare technology. Let’s analyze them in detail, with simple yet formal language and practical examples.
1. FHIR (Fast Healthcare Interoperability Resources): The Universal Interpreter
What is it?
FHIR (pronounced “fire”) is, first and foremost, an interoperability standard. It is managed by the international organization HL7.
Its goal is not to store data in a specific format, but to define a common language and a method (a RESTful API) to exchange health data between different systems quickly and efficiently.
Think of FHIR as a universal translator or a power adapter. It doesn’t care how the electricity is generated (openEHR) or how it’s cataloged in a warehouse (OMOP); it only cares about getting it from the socket to the device (from system A to system B).
How does it work?
FHIR breaks down health data into logical “building blocks” called Resources. There is a Resource for Patient, one for Observation (e.g., a blood glucose reading), one for MedicationRequest (a prescription), and so on. Each resource defines a simple, modern data structure (often in JSON or XML formats).
Practical Example
Scenario: A diabetic patient wants to use a smartphone app to view their latest lab results from the local hospital.
How FHIR acts:
The patient’s app (System A) sends a secure request to the hospital’s server (System B).
The request, formatted according to the FHIR standard, says: “Please give me all
ObservationResources of type ‘blood glucose’ for thePatientResource with ID ‘XYZ'”.The hospital server, which “speaks” FHIR, understands the request, retrieves the data (from whatever internal database it uses), and returns it to the app in the standard
ObservationResource format.The app displays the data to the patient.
In summary: FHIR is the leading standard for real-time data exchange.
2. OMOP Common Data Model (CDM): The Standardized Library for Research
What is it?
The OMOP CDM (Common Data Model) is a data model, meaning a standardized database schema. It is maintained by the OHDSI (Observational Health Data Sciences and Informatics) community.
Its goal is to solve a different problem: large-scale research. Clinical data in the real world is heterogeneous and “messy.” The OMOP CDM provides a common storage structure into which this heterogeneous data can be transformed and harmonized.
Think of OMOP as the standard blueprint for a research library. It doesn’t matter if the books come from different publishers or countries; once they arrive at the library, they are all cataloged with the same system (like the Dewey Decimal System) and placed on the same predefined shelves (“History,” “Science,” etc.).
How does it work?
OMOP defines a set of tables (e.g., PERSON, CONDITION_OCCURRENCE, DRUG_EXPOSURE). The crucial process is ETL (Extract, Transform, Load): raw data from source systems is extracted, transformed into the OMOP format, and loaded into its tables.
A pillar of OMOP is its Standardized Vocabularies (like SNOMED, LOINC, RxNorm). All clinical concepts are “translated” into standard codes, ensuring semantic interoperability.
Practical Example
Scenario: An international research consortium wants to study whether an antihypertensive drug (Drug A) increases the risk of diabetes in patients over 60. They need to analyze data from 10 million patients across 20 different hospitals.
How OMOP acts:
Each hospital does not share its raw data (due to privacy and incompatibility).
Instead, each hospital runs an ETL process to map its local data (e.g., “high blood pressure,” “hypertension,” “diagnosis code XYZ”) into the OMOP database.
In the OMOP standard, all these diagnoses become the same standard code (e.g., SNOMED CT: 38341003 for “Hypertensive disorder”). All prescriptions for Drug A end up in the
DRUG_EXPOSUREtable.Researchers can now send a single query (analysis) that runs identically across all 20 OMOP databases, obtaining a robust, aggregated statistical result.
In summary: OMOP is the leading standard for observational data analysis and research (secondary use).
3. openEHR: The Detailed Foundation of the Clinical Record
What is it?
openEHR (pronounced “open-air”) is an open architectural specification for electronic health records (EHRs). Its goal is to store clinical data at the source (primary use) with maximum detail, ensuring it is understandable and usable for decades.
It is the most complex of the three, but also the most powerful in terms of clinical precision. It is not just a data model, but an entire ecosystem for defining data.
Think of openEHR as the civil engineering blueprints for a hospital. It doesn’t just define “there is a ward”; it defines in detail the foundations, the electrical system, the plumbing (the Reference Model), and provides the standardized designs for an “Operating Room” or “Patient Room” (Archetypes).
How does it work?
openEHR uses a unique two-level architecture:
-
Reference Model (RM): A stable, technical base model that defines the generic structure of data (e.g., “a piece of data has a name, a value, a time”).
-
Archetypes & Templates: This is the heart of openEHR. Archetypes are formal, reusable clinical definitions, created by clinicians and experts, that define how a clinical concept must be recorded. For example, there is an archetype for “Blood Pressure” that includes mandatory fields for “Systolic,” “Diastolic,” “Patient Position,” and “Cuff Size.”
This approach separates clinical knowledge (which evolves) from the technical structure (which is stable), making the system “future-proof.”
Practical Example
Scenario: A cardiologist in a hospital needs to document the results of an ECG (electrocardiogram).
How openEHR acts:
Traditional System: The doctor might have a free-text field (“ECG Notes”) or a few basic fields (e.g., “Rhythm”). The data is poorly structured and difficult to analyze.
openEHR System: The EHR uses the “ECG Result” archetype. This model enforces that the clinician (or machine) records specific data in structured fields: “Heart Rate,” “PR Interval,” “QRS Duration,” “Axis,” “Textual Interpretation,” etc.
The result is an incredibly rich, precise, and semantically defined piece of data at the moment of its creation.
In summary: openEHR is the leading standard for detailed clinical modeling and long-term data persistence (primary use).
Key Comparison: The House Metaphor
To solidify the concepts, let’s use a metaphor:
-
openEHR is the architectural blueprint and foundation of your house. It defines in granular detail where every brick, electrical wire, and water pipe is located. It is built to last 100 years and to be the source of truth about how the house is built.
-
OMOP CDM is the real estate agency’s standardized form for describing your house (and all the others in the neighborhood). It doesn’t care how the pipes are laid; it just wants to know: “Number of Bathrooms: 2,” “Number of Rooms: 5,” “Heating: Yes/No.” It is used to compare and analyze many houses at once.
-
FHIR is the postal and courier service. It doesn’t own the house (openEHR) and doesn’t manage the inventory (OMOP), but it is the standardized service that allows anyone (with permission) to request and receive specific information: “Send me this house’s gas bill” or “Tell me the color of the front door.”
Summary Table
| Feature | FHIR (Fast Healthcare Interoperability Resources) | OMOP Common Data Model (CDM) | openEHR |
| Main Purpose | Data Exchange (Interoperability) | Data Analysis (Research) | Data Persistence (Clinical) |
| Type | API Standard / Exchange Format | Data Model (DB Schema) | Architecture / Modeling Specification |
| Focus | Data “in motion” | Secondary Use | Primary Use |
| Granularity | Variable (defined by Resources) | Aggregated (optimized for analysis) | Extremely High (clinical detail) |
| Flexibility | Moderate (extensible via “Profiles”) | Low (rigid schema, for consistency) | Very High (thanks to Archetypes) |
| Use Case | Mobile apps, system integration. | Clinical studies, pharmacovigilance. | Building EHRs, clinical data platforms. |
Conclusion: Not Competition, but Collaboration
The question is never “FHIR or OMOP or openEHR?”. The right question is “How do we use FHIR, OMOP, and openEHR?”.
In an ideal healthcare scenario, these systems work together:
-
A patient’s data is created and stored with maximum clinical precision in an EHR based on openEHR.
-
When the patient opens their blood pressure app, the app uses FHIR to request the latest data from the openEHR repository.
-
At night, an ETL process transforms the detailed openEHR data (and data from other systems) into the OMOP CDM format and loads it into a research database.
-
Researchers can then conduct large-scale studies using the OMOP data, knowing that the original source (openEHR) was of the highest quality.
