Respuesta corta: el OMOP Common Data Model (Observational Medical Outcomes Partnership CDM), mantenido por la comunidad OHDSI, es un esquema relacional en el que se convierten datos de salud de cualquier fuente (EHRs, reclamaciones, registros), junto con un conjunto de vocabularios estandarizados que mapean cada código local a un id de concepto estándar. Una vez que una base de datos está en OMOP, el mismo código de análisis (una definición de cohorte, una estimación de incidencia, un estudio de efectividad comparativa) se ejecuta sin cambios contra cientos de bases de datos en todo el mundo, y solo se comparten los resultados agregados. OMOP es el modelo para la investigación; FHIR es el modelo para el intercambio y la atención; un mapeo publicado los conecta, y la mayoría de las plataformas de investigación ahora aceptan FHIR como fuente para su ETL OMOP.
El modelo en una imagen
El Modelo Común de Datos OMOP representa todo como un evento sobre una persona durante un período de observación, con el dominio clínico decidiendo la tabla: condition_occurrence para diagnósticos, drug_exposure para medicamentos, measurement para resultados de laboratorio y signos vitales, procedure_occurrence, visit_occurrence, observation para otros hechos, además de las tablas person, death, note, specimen, provider y cost. La versión 5.4 es la más utilizada.
Todo es un evento sobre una persona durante un período de observación, con el dominio clínico decidiendo la tabla:
| Tabla | Contiene | Vocabulario estándar (típico) | Fuente FHIR |
|---|---|---|---|
| person | Una fila por persona: género, fecha de nacimiento, raza, etnia, ubicación | Conceptos de Género, Raza, Etnia | Patient |
| observation_period | Períodos durante los cuales se esperan datos sobre la persona | — | Derivado de las fechas de cobertura y encuentro |
| visit_occurrence (y visit_detail) | Encuentros: hospitalizados, ambulatorios, de emergencia, con fechas | Conceptos de visita | Encounter |
| condition_occurrence | Diagnósticos y problemas con inicio y fin | SNOMED CT | Condition (códigos ICD mapeados a SNOMED) |
| drug_exposure | Recetas, dispensaciones, administraciones con cantidad y días de suministro | RxNorm (y RxNorm Extension para medicamentos no estadounidenses) | MedicationRequest, MedicationStatement, MedicationAdministration, MedicationDispense |
| procedure_occurrence | Procedimientos realizados | SNOMED CT, CPT4, ICD10PCS | Procedure |
| measurement | Resultados de laboratorio y signos vitales con valor, unidad, rango | LOINC, con unidades UCUM | Observation (laboratorio, signos vitales) |
| observation | Otros hechos clínicos: historial, social, puntuaciones | SNOMED CT, LOINC | Observation (otros), QuestionnaireResponse, FamilyMemberHistory |
| device_exposure | Dispositivos utilizados | SNOMED CT | DeviceUseStatement, Procedure |
| death | Fecha y causa | SNOMED CT | Patient.deceased, Observation |
| note, note_nlp | Notas clínicas y términos extraídos por NLP | — | DocumentReference, DiagnosticReport |
| specimen | Muestras | SNOMED CT | Specimen |
| provider, care_site, location | Clínicos, instalaciones, lugares | Conceptos de especialidad | Practitioner, Organization, Location |
| cost, payer_plan_period | Costos y cobertura | — | Coverage, Claim (donde esté disponible) |
La versión 5.4 es la que la mayoría de los sitios ejecutan; la versión 6 existe pero no fue ampliamente adoptada, y el desarrollo continúa en la línea 5.x.
Los vocabularios
Los vocabularios estandarizados de OMOP, distribuidos por OHDSI a través de Athena, cargan más de cien sistemas de códigos (SNOMED CT, LOINC, RxNorm, ICD-10, ATC y otros) en las tablas concept, concept_relationship y concept_ancestor. Cada código se convierte en un concept_id, ya sea estándar o mapeado a uno estándar, por lo que los análisis se escriben una vez mientras se conserva el código fuente original.
La segunda mitad de OMOP es Athena, la distribución de vocabularios de OHDSI: más de cien sistemas de códigos (SNOMED CT, LOINC, RxNorm, ICD-10 y variantes nacionales, ATC, CPT, Read, y muchos más) cargados en las tablas concept, concept_relationship, concept_ancestor. Cada código se convierte en un concept_id; cada concepto es estándar (el que usan los análisis), no estándar (un código de origen que se mapea a uno estándar) o una clasificación. El ETL almacena tanto el concepto de origen (lo que decía el registro: ICD-10 E11.9) como el concepto estándar (SNOMED 44054006), por lo que los análisis se escriben una vez contra conceptos estándar mientras se preserva el original. La tabla concept_ancestor permite que una cohorte solicite "cualquier tipo de diabetes" en una sola unión. Consulte SNOMED CT vs ICD-10 para saber por qué el estándar para las condiciones es SNOMED CT.
El ETL
El ETL de OMOP es el trabajo de convertir una base de datos de origen en el modelo de datos común, respaldado por herramientas de OHDSI: WhiteRabbit perfila el origen, Rabbit-in-a-Hat documenta el mapeo de tablas, Usagi mapea códigos locales a conceptos estándar, el Data Quality Dashboard verifica el resultado contra miles de reglas y ACHILLES caracteriza la base de datos terminada.
Convertir una fuente a OMOP es el trabajo principal. Las herramientas de OHDSI ayudan: WhiteRabbit escanea la fuente y la perfila; Rabbit-in-a-Hat documenta el mapeo de tablas de origen a tablas CDM; Usagi ayuda a mapear códigos locales a conceptos estándar; el Data Quality Dashboard verifica el resultado contra miles de reglas; ACHILLES caracteriza la base de datos. Decisiones típicas: cómo se definen las visitas, cómo los registros de medicamentos se convierten en exposiciones con días de suministro, cómo se normalizan las unidades, qué hacer con los códigos que no tienen un mapeo estándar y cómo manejar las actualizaciones (recarga completa vs. incremental).
Análisis a través de la red
El análisis a través de la red OHDSI funciona escribiendo un estudio una vez y ejecutándolo en todas partes: los investigadores definen cohortes en ATLAS, ejecutan estimación y predicción con los paquetes R de HADES, y empaquetan el análisis como código que cada sitio ejecuta localmente en su propia base de datos OMOP, compartiendo solo resultados agregados. DARWIN EU y EHDEN siguen este modelo.
ATLAS es la herramienta web donde los investigadores construyen definiciones de cohortes (personas con condición X, expuestas al medicamento Y, dentro de ventanas de tiempo), las caracterizan y ejecutan estudios de estimación y predicción con los paquetes R de HADES (CohortMethod, PatientLevelPrediction, SelfControlledCaseSeries). Un estudio de red empaqueta el análisis como código; cada sitio lo ejecuta localmente en su base de datos OMOP y comparte resultados agregados; nadie agrupa datos a nivel de registro. Así es como la comunidad OHDSI produjo rápidamente grandes estudios multinacionales durante la pandemia, y es el modelo detrás de la red DARWIN EU de la EMA y el proyecto EHDEN, que convirtió más de cien bases de datos europeas a OMOP.
FHIR a OMOP
FHIR se mapea a OMOP en dos niveles: recursos a tablas y elementos a columnas, con códigos FHIR traducidos a través de los vocabularios de OMOP a conceptos estándar. La guía de implementación de FHIR a OMOP de HL7 y el grupo de trabajo de FHIR de OHDSI publican los mapeos; varias plataformas ejecutan el ETL directamente desde un servidor FHIR o una exportación de datos masiva.
FHIR y OMOP responden a diferentes necesidades: FHIR transporta el registro de un paciente entre sistemas con detalles completos; OMOP aplana los registros de muchos pacientes para análisis estadísticos. El mapeo es natural a nivel de recurso (tabla anterior) y detallado a nivel de elemento: los códigos FHIR se mapean a través de los vocabularios de OMOP a conceptos estándar; Observation.valueQuantity se convierte en measurement value_as_number con unit_concept_id; Encounter.class se convierte en visit_concept_id. La guía de implementación de FHIR a OMOP de HL7 (a través del acelerador Vulcan) y el grupo de trabajo de FHIR de OHDSI publican los mapeos e implementaciones de referencia; varias plataformas ejecutan el ETL directamente desde un servidor FHIR o una exportación de datos masiva. Persisten ambigüedades donde FHIR es más rico (codificaciones múltiples, estados, procedencia) o donde OMOP necesita lo que FHIR carece (días de suministro, períodos de observación).
Lo que OMOP no es
OMOP no es un formato para la atención ni es anónimo por sí solo: descarta la narrativa, aplana los estados y no lleva consentimiento, procedencia ni flujo de trabajo, por lo que FHIR sigue siendo el formato de intercambio, y una base de datos OMOP aún contiene datos a nivel de registro que deben ser gobernados como cualquier base de datos de salud, generalmente con identificadores de persona seudonimizados dentro de un entorno seguro.
No es un formato para la atención: elimina la narrativa, aplana los estados y no transporta consentimiento, procedencia o flujo de trabajo. No es anónimo por sí solo: una base de datos OMOP contiene datos a nivel de registro y se rige como cualquier base de datos de salud, generalmente con identificadores de persona seudonimizados y en entornos seguros. Consulte Uso secundario de datos de salud y Desidentificación de datos de salud.
En Anpheros
Los registros de Anpheros son FHIR R4 con códigos estándar (LOINC, SNOMED CT, ATC, ICD-10), que es la entrada que desea un ETL OMOP; con el consentimiento de la persona para un propósito de investigación, las extracciones FHIR seudonimizadas pueden alimentar el ETL de una plataforma de investigación. Anpheros en sí mismo solo calcula señales poblacionales agregadas sobre grupos de 20 o más y no opera una base de datos OMOP con datos identificados.
Páginas relacionadas
- Uso secundario de datos de salud: el mapa
- SNOMED CT vs ICD-10
- Desidentificación de datos de salud
- Exportación de datos masiva de FHIR explicada
- Servidores de terminología explicados
- RxNorm vs ATC
Fuentes
- OHDSI: OMOP Common Data Model
- OHDSI: The Book of OHDSI
- OHDSI Athena: vocabularios estandarizados
- OHDSI: ATLAS
- HL7 Vulcan: guía de implementación de FHIR a OMOP
- Proyecto EHDEN
- EMA: DARWIN EU
Preguntas frecuentes
¿Es OMOP un reemplazo para FHIR?
No. FHIR intercambia el registro detallado de un paciente entre sistemas; OMOP estructura muchos registros para análisis estadísticos. Las plataformas de investigación toman FHIR (u otras fuentes) y producen OMOP.
¿Qué versión de OMOP debo usar?
5.4 es la versión ampliamente implementada con soporte completo de herramientas; la mayoría de las nuevas conversiones la tienen como objetivo. La versión 6 introdujo cambios que la comunidad no adoptó ampliamente.
¿Por qué OMOP mapea códigos ICD a SNOMED CT?
Para que los análisis se puedan escribir una vez contra un único vocabulario estándar jerárquico para condiciones, independientemente de si la fuente utilizó códigos ICD-10, ICD-10-CM, ICD-9-CM o Read. El código de origen se mantiene junto.
¿Es una base de datos OMOP anónima?
No por sí sola. Contiene datos a nivel de registro, generalmente con identificadores seudonimizados y sin identificadores directos, y debe protegerse y regirse como cualquier base de datos de salud, típicamente dentro de un entorno seguro.
Pruébalo gratis en el sandbox
Tu primera llamada FHIR en 5 minutos. Una API HL7 FHIR R4 con el consentimiento del paciente integrado: pruébala en el sandbox y luego conecta tu propia app o sistema de clínica.
Gratis · 30 pacientes sintéticos · sin tarjeta
Anpheros crea un historial médico que el paciente controla y puede compartir con cualquier clínica, en una plataforma HL7 FHIR R4, con sede en la UE. Estas guías te ayudan a entender y organizar tu salud; no reemplazan a tu médico.
Sobre Anpheros →