Resposta curta: o OMOP Common Data Model (Observational Medical Outcomes Partnership CDM), mantido pela comunidade OHDSI, é um esquema relacional para o qual os dados de saúde de qualquer fonte (EHRs, sinistros, registos) são convertidos, juntamente com um conjunto de vocabulários padronizados que mapeiam cada código local para um ID de conceito padrão. Uma vez que uma base de dados está em OMOP, o mesmo código de análise (uma definição de coorte, uma estimativa de incidência, um estudo de eficácia comparativa) é executado sem alterações em centenas de bases de dados em todo o mundo, e apenas os resultados agregados são partilhados. OMOP é o modelo para pesquisa; FHIR é o modelo para troca e cuidados; um mapeamento publicado liga-os, e a maioria das plataformas de pesquisa agora aceita FHIR como fonte para o seu ETL OMOP.
O modelo numa imagem
O Modelo de Dados Comum OMOP representa tudo como um evento sobre uma pessoa durante um período de observação, com o domínio clínico a decidir a tabela: condition_occurrence para diagnósticos, drug_exposure para medicamentos, measurement para resultados de laboratório e sinais vitais, procedure_occurrence, visit_occurrence, observation para outros factos, mais as tabelas person, death, note, specimen, provider e cost. A versão 5.4 é a mais utilizada.
Tudo é um evento sobre uma pessoa durante um período de observação, com o domínio clínico a decidir a tabela:
| Tabela | Contém | Vocabulário padrão (típico) | Fonte FHIR |
|---|---|---|---|
| person | Uma linha por pessoa: género, data de nascimento, raça, etnia, localização | Conceitos de Género, Raça, Etnia | Patient |
| observation_period | Períodos durante os quais se esperam dados sobre a pessoa | — | Derivado de datas de cobertura e encontro |
| visit_occurrence (e visit_detail) | Encontros: internamento, ambulatório, urgência, com datas | Conceitos de visita | Encounter |
| condition_occurrence | Diagnósticos e problemas com início e fim | SNOMED CT | Condition (códigos ICD mapeados para SNOMED) |
| drug_exposure | Prescrições, dispensações, administrações com quantidade e dias de fornecimento | RxNorm (e RxNorm Extension para medicamentos não-EUA) | MedicationRequest, MedicationStatement, MedicationAdministration, MedicationDispense |
| procedure_occurrence | Procedimentos realizados | SNOMED CT, CPT4, ICD10PCS | Procedure |
| measurement | Resultados de laboratório e sinais vitais com valor, unidade, intervalo | LOINC, com unidades UCUM | Observation (laboratório, sinais vitais) |
| observation | Outros factos clínicos: histórico, social, pontuações | SNOMED CT, LOINC | Observation (outros), QuestionnaireResponse, FamilyMemberHistory |
| device_exposure | Dispositivos utilizados | SNOMED CT | DeviceUseStatement, Procedure |
| death | Data e causa | SNOMED CT | Patient.deceased, Observation |
| note, note_nlp | Notas clínicas e termos extraídos por NLP | — | DocumentReference, DiagnosticReport |
| specimen | Amostras | SNOMED CT | Specimen |
| provider, care_site, location | Clínicos, instalações, locais | Conceitos de especialidade | Practitioner, Organization, Location |
| cost, payer_plan_period | Custos e cobertura | — | Coverage, Claim (onde disponível) |
A versão 5.4 é a que a maioria dos locais executa; a versão 6 existe mas não foi amplamente adotada, e o desenvolvimento continua na linha 5.x.
Os vocabulários
Os vocabulários padronizados OMOP, distribuídos pela OHDSI através da Athena, carregam mais de uma centena de sistemas de códigos (SNOMED CT, LOINC, RxNorm, ICD-10, ATC e outros) para as tabelas concept, concept_relationship e concept_ancestor. Cada código torna-se um concept_id, seja padrão ou mapeado para um padrão, pelo que as análises são escritas uma vez, enquanto o código original é preservado.
A segunda metade do OMOP é Athena, a distribuição de vocabulário da OHDSI: mais de cem sistemas de códigos (SNOMED CT, LOINC, RxNorm, ICD-10 e variantes nacionais, ATC, CPT, Read, e muitos mais) carregados nas tabelas concept, concept_relationship, concept_ancestor. Cada código torna-se um concept_id; cada conceito é padrão (aquele que as análises usam), não padrão (um código de origem que mapeia para um padrão) ou uma classificação. O ETL armazena tanto o conceito de origem (o que o registo dizia: ICD-10 E11.9) como o conceito padrão (SNOMED 44054006), para que as análises sejam escritas uma vez contra conceitos padrão enquanto o original é preservado. A tabela concept_ancestor permite que uma coorte peça "qualquer tipo de diabetes" numa única junção. Veja SNOMED CT vs ICD-10 para saber por que o padrão para condições é SNOMED CT.
O ETL
O ETL OMOP é o trabalho de conversão de uma base de dados de origem para o modelo de dados comum, suportado por ferramentas OHDSI: WhiteRabbit perfila a origem, Rabbit-in-a-Hat documenta o mapeamento das tabelas, Usagi mapeia códigos locais para conceitos padrão, o Data Quality Dashboard verifica o resultado contra milhares de regras, e ACHILLES caracteriza a base de dados finalizada.
Converter uma origem para OMOP é o trabalho principal. As ferramentas da OHDSI ajudam: WhiteRabbit analisa a origem e perfila-a; Rabbit-in-a-Hat documenta o mapeamento de tabelas de origem para tabelas CDM; Usagi ajuda a mapear códigos locais para conceitos padrão; o Data Quality Dashboard verifica o resultado contra milhares de regras; ACHILLES caracteriza a base de dados. Decisões típicas: como as visitas são definidas, como os registos de medicação se tornam exposições com dias de fornecimento, como as unidades são normalizadas, o que fazer com códigos que não têm mapeamento padrão, e como lidar com atualizações (recarga completa vs incremental).
Análise em rede
A análise através da rede OHDSI funciona escrevendo um estudo uma vez e executando-o em todo o lado: os investigadores definem coortes no ATLAS, executam estimação e previsão com os pacotes R HADES, e empacotam a análise como código que cada local executa localmente na sua própria base de dados OMOP, partilhando apenas resultados agregados. DARWIN EU e EHDEN seguem este modelo.
ATLAS é a ferramenta web onde os investigadores constroem definições de coorte (pessoas com condição X, expostas ao medicamento Y, dentro de janelas de tempo), caracterizam-nas e executam estudos de estimação e previsão com os pacotes R HADES (CohortMethod, PatientLevelPrediction, SelfControlledCaseSeries). Um estudo de rede empacota a análise como código; cada local executa-o localmente na sua base de dados OMOP e partilha resultados agregados; ninguém agrupa dados a nível de registo. É assim que a comunidade OHDSI produziu rapidamente grandes estudos multinacionais durante a pandemia, e é o modelo por trás da rede DARWIN EU da EMA e do projeto EHDEN, que converteu mais de cem bases de dados europeias para OMOP.
FHIR para OMOP
FHIR mapeia para OMOP em dois níveis: recursos para tabelas e elementos para colunas, com códigos FHIR traduzidos através dos vocabulários OMOP para conceitos padrão. O guia de implementação FHIR para OMOP da HL7 e o grupo de trabalho FHIR da OHDSI publicam os mapeamentos; várias plataformas executam o ETL diretamente a partir de um servidor FHIR ou exportação de dados em massa.
FHIR e OMOP respondem a necessidades diferentes: FHIR troca o registo de um paciente entre sistemas com detalhe completo; OMOP achata os registos de muitos pacientes para estatísticas. O mapeamento é natural ao nível do recurso (tabela acima) e detalhado ao nível do elemento: códigos FHIR mapeiam através dos vocabulários OMOP para conceitos padrão; Observation.valueQuantity torna-se measurement value_as_number com unit_concept_id; Encounter.class torna-se visit_concept_id. O guia de implementação FHIR para OMOP da HL7 (através do acelerador Vulcan) e o grupo de trabalho FHIR da OHDSI publicam os mapeamentos e implementações de referência; várias plataformas executam o ETL diretamente a partir de um servidor FHIR ou de uma exportação de Dados em Massa. Permanecem ambiguidades onde FHIR é mais rico (múltiplas codificações, estados, proveniência) ou onde OMOP necessita do que FHIR não tem (dias de fornecimento, períodos de observação).
O que OMOP não é
OMOP não é um formato para cuidados e não é anónimo por si só: descarta narrativas, achata estados e não transporta consentimento, proveniência ou fluxo de trabalho, pelo que FHIR permanece o formato de intercâmbio, e uma base de dados OMOP ainda detém dados a nível de registo que devem ser geridos como qualquer base de dados de saúde, geralmente com IDs de pessoa pseudonimizados dentro de um ambiente seguro.
Não é um formato para cuidados: descarta a narrativa, achata estados e não transporta consentimento, proveniência ou fluxo de trabalho. Não é anónimo por si só: uma base de dados OMOP detém dados a nível de registo e é governada como qualquer base de dados de saúde, geralmente com IDs de pessoa pseudonimizados e em ambientes seguros. Veja Uso secundário de dados de saúde e Desidentificação de dados de saúde.
Em Anpheros
Os registos Anpheros são FHIR R4 com códigos padrão (LOINC, SNOMED CT, ATC, ICD-10), que é a entrada que um ETL OMOP deseja; com o consentimento da pessoa para um propósito de pesquisa, extratos FHIR pseudonimizados podem alimentar o ETL de uma plataforma de pesquisa. A Anpheros em si calcula apenas sinais populacionais agregados sobre grupos de 20 ou mais e não opera uma base de dados OMOP com dados identificados.
Páginas relacionadas
- Uso secundário de dados de saúde: o mapa
- SNOMED CT vs ICD-10
- Desidentificação de dados de saúde
- Exportação de Dados em Massa FHIR explicada
- Servidores de terminologia explicados
- RxNorm vs ATC
Fontes
- OHDSI: OMOP Common Data Model
- OHDSI: The Book of OHDSI
- OHDSI Athena: vocabulários padronizados
- OHDSI: ATLAS
- HL7 Vulcan: guia de implementação FHIR para OMOP
- Projeto EHDEN
- EMA: DARWIN EU
Perguntas frequentes
OMOP é um substituto para FHIR?
Não. FHIR troca o registo detalhado de um paciente entre sistemas; OMOP estrutura muitos registos para análise estatística. As plataformas de pesquisa recebem FHIR (ou outras fontes) e produzem OMOP.
Qual versão do OMOP devo usar?
5.4 é a versão amplamente implementada com suporte total de ferramentas; a maioria das novas conversões tem como alvo essa versão. A versão 6 introduziu alterações que a comunidade não adotou amplamente.
Por que o OMOP mapeia códigos ICD para SNOMED CT?
Para que as análises possam ser escritas uma vez contra um único vocabulário padrão hierárquico para condições, independentemente de a origem ter usado códigos ICD-10, ICD-10-CM, ICD-9-CM ou Read. O código de origem é mantido ao lado.
Uma base de dados OMOP é anónima?
Não por si só. Contém dados a nível de registo, geralmente com identificadores pseudonimizados e sem identificadores diretos, e deve ser protegida e governada como qualquer base de dados de saúde, tipicamente dentro de um ambiente seguro.
Experimente grátis no sandbox
Sua primeira chamada FHIR em 5 minutos. Uma API HL7 FHIR R4 com o consentimento do paciente integrado: experimente na sandbox e depois conecte a sua própria app ou sistema clínico.
Grátis · 30 pacientes sintéticos · sem cartão
A Anpheros desenvolve um registo médico que o doente controla e pode partilhar com qualquer clínica, numa plataforma HL7 FHIR R4, sediada na UE. Estes guias ajudam-no a compreender e organizar a sua saúde; não substituem o seu médico.
Sobre a Anpheros →