Răspuns scurt: OMOP Common Data Model (Observational Medical Outcomes Partnership CDM), întreținut de comunitatea OHDSI, este un schemă relațională în care datele de sănătate din orice sursă (EHR-uri, decontări, registre) sunt convertite, împreună cu un set de vocabularuri standardizate care mapează fiecare cod local la un ID de concept standard. Odată ce o bază de date este în OMOP, același cod de analiză (o definiție de cohortă, o estimare a incidenței, un studiu de eficacitate comparativă) rulează neschimbat pe sute de baze de date la nivel mondial, iar doar rezultatele agregate sunt partajate. OMOP este modelul pentru cercetare; FHIR este modelul pentru schimb și îngrijire; o mapare publicată le conectează, iar majoritatea platformelor de cercetare acceptă acum FHIR ca sursă pentru ETL-ul lor OMOP.
Modelul într-o singură imagine
Modelul Comun de Date OMOP reprezintă totul ca un eveniment despre o persoană pe parcursul unei perioade de observație, domeniul clinic decidând tabelul: condition_occurrence pentru diagnostice, drug_exposure pentru medicamente, measurement pentru rezultate de laborator și semne vitale, procedure_occurrence, visit_occurrence, observation pentru alte informații, plus tabelele person, death, note, specimen, provider și cost. Versiunea 5.4 este cea mai utilizată.
Totul este un eveniment despre o persoană în timpul unei perioade de observație, cu domeniul clinic care decide tabelul:
| Tabel | Conține | Vocabular standard (tipic) | Sursă FHIR |
|---|---|---|---|
| person | O linie per persoană: gen, data nașterii, rasă, etnie, locație | Concepte de gen, rasă, etnie | Patient |
| observation_period | Perioade în care se așteaptă date despre persoană | — | Derivat din datele de acoperire și de internare |
| visit_occurrence (și visit_detail) | Internări: în spital, ambulatoriu, urgență, cu date | Concepte de vizită | Encounter |
| condition_occurrence | Diagnostice și probleme cu început și sfârșit | SNOMED CT | Condition (coduri ICD mapate la SNOMED) |
| drug_exposure | Rețete, eliberări, administrări cu cantitate și zile de aprovizionare | RxNorm (și RxNorm Extension pentru medicamente non-SUA) | MedicationRequest, MedicationStatement, MedicationAdministration, MedicationDispense |
| procedure_occurrence | Proceduri efectuate | SNOMED CT, CPT4, ICD10PCS | Procedure |
| measurement | Rezultate de laborator și semne vitale cu valoare, unitate, interval | LOINC, cu unități UCUM | Observation (laborator, semne vitale) |
| observation | Alte fapte clinice: istoric, social, scoruri | SNOMED CT, LOINC | Observation (altele), QuestionnaireResponse, FamilyMemberHistory |
| device_exposure | Dispozitive utilizate | SNOMED CT | DeviceUseStatement, Procedure |
| death | Data și cauza | SNOMED CT | Patient.deceased, Observation |
| note, note_nlp | Note clinice și termeni extrasi prin NLP | — | DocumentReference, DiagnosticReport |
| specimen | Specimene | SNOMED CT | Specimen |
| provider, care_site, location | Clinicieni, facilități, locuri | Concepte de specialitate | Practitioner, Organization, Location |
| cost, payer_plan_period | Costuri și acoperire | — | Coverage, Claim (acolo unde este disponibil) |
Versiunea 5.4 este cea pe care o rulează majoritatea site-urilor; versiunea 6 există, dar nu a fost adoptată pe scară largă, iar dezvoltarea continuă pe linia 5.x.
Vocabularele
Vocabularele standardizate OMOP, distribuite de OHDSI prin Athena, încarcă peste o sută de sisteme de coduri (SNOMED CT, LOINC, RxNorm, ICD-10, ATC și altele) în tabelele concept, concept_relationship și concept_ancestor. Fiecare cod devine un concept_id, fie standard, fie mapat la unul standard, astfel încât analizele sunt scrise o singură dată, în timp ce codul sursă original este păstrat.
A doua jumătate a OMOP este Athena, distribuția de vocabular a OHDSI: mai mult de o sută de sisteme de coduri (SNOMED CT, LOINC, RxNorm, ICD-10 și variante naționale, ATC, CPT, Read și multe altele) încărcate în tabelele concept, concept_relationship, concept_ancestor. Fiecare cod devine un concept_id; fiecare concept este fie standard (cel pe care îl folosesc analizele), fie non-standard (un cod sursă care se mapează la unul standard) sau o clasificare. ETL-ul stochează atât conceptul sursă (ce spunea înregistrarea: ICD-10 E11.9), cât și conceptul standard (SNOMED 44054006), astfel încât analizele sunt scrise o singură dată împotriva conceptelor standard, în timp ce originalul este păstrat. Tabelul concept_ancestor permite unei cohorte să solicite "orice tip de diabet" într-o singură interogare. Vezi SNOMED CT vs ICD-10 pentru motivul pentru care standardul pentru afecțiuni este SNOMED CT.
ETL-ul
ETL-ul OMOP este munca de conversie a unei baze de date sursă în modelul comun de date, susținută de instrumentele OHDSI: WhiteRabbit profilează sursa, Rabbit-in-a-Hat documentează maparea tabelelor, Usagi mapează codurile locale la concepte standard, Data Quality Dashboard verifică rezultatul conform a mii de reguli, iar ACHILLES caracterizează baza de date finalizată.
Convertirea unei surse în OMOP este munca principală. Instrumentele OHDSI ajută: WhiteRabbit scanează sursa și o profilează; Rabbit-in-a-Hat documentează maparea de la tabelele sursă la tabelele CDM; Usagi ajută la maparea codurilor locale la concepte standard; Data Quality Dashboard verifică rezultatul împotriva a mii de reguli; ACHILLES caracterizează baza de date. Decizii tipice: cum sunt definite vizitele, cum înregistrările de medicamente devin expuneri cu zile de aprovizionare, cum sunt normalizate unitățile, ce se face cu codurile care nu au o mapare standard și cum se gestionează actualizările (reîncărcare completă vs. incrementală).
Analiză în rețea
Analiza în rețeaua OHDSI funcționează prin scrierea unui studiu o singură dată și rularea acestuia peste tot: cercetătorii definesc cohorte în ATLAS, rulează estimarea și predicția cu pachetele R HADES și împachetează analiza ca un cod pe care fiecare site îl execută local pe propria bază de date OMOP, partajând doar rezultatele agregate. DARWIN EU și EHDEN urmează acest model.
ATLAS este instrumentul web unde cercetătorii construiesc definiții de cohorte (persoane cu afecțiunea X, expuse la medicamentul Y, în intervale de timp), le caracterizează și rulează studii de estimare și predicție cu pachetele R HADES (CohortMethod, PatientLevelPrediction, SelfControlledCaseSeries). Un studiu de rețea împachetează analiza ca și cod; fiecare site îl rulează local pe baza sa de date OMOP și partajează rezultate agregate; nimeni nu combină date la nivel de înregistrare. Acesta este modul în care comunitatea OHDSI a produs rapid studii multinaționale mari în timpul pandemiei și este modelul din spatele rețelei DARWIN EU a EMA și a proiectului EHDEN, care a convertit peste o sută de baze de date europene în OMOP.
FHIR către OMOP
FHIR se mapează la OMOP la două niveluri: resurse la tabele și elemente la coloane, cu codurile FHIR traduse prin vocabularele OMOP în concepte standard. Ghidul de implementare FHIR la OMOP al HL7 și grupul de lucru FHIR al OHDSI publică mapările; mai multe platforme rulează ETL-ul direct dintr-un server FHIR sau export de date în vrac (Bulk Data).
FHIR și OMOP răspund unor nevoi diferite: FHIR transportă înregistrarea unui pacient între sisteme cu detalii complete; OMOP aplatizează înregistrările multor pacienți pentru statistici. Maparea este naturală la nivel de resursă (tabelul de mai sus) și detaliată la nivel de element: codurile FHIR se mapează prin vocabularele OMOP la concepte standard; Observation.valueQuantity devine measurement value_as_number cu unit_concept_id; Encounter.class devine visit_concept_id. Ghidul de implementare FHIR to OMOP al HL7 (prin acceleratorul Vulcan) și grupul de lucru FHIR al OHDSI publică mapările și implementările de referință; mai multe platforme rulează ETL-ul direct dintr-un server FHIR sau dintr-un export de date în bloc. Ambiguitățile rămân acolo unde FHIR este mai bogat (codificări multiple, stări, proveniență) sau unde OMOP are nevoie de ceea ce FHIR nu are (zile de aprovizionare, perioade de observație).
Ce NU este OMOP
OMOP nu este un format pentru îngrijire și nu este anonim de la sine: omite narațiunea, aplatizează stările și nu poartă consimțământ, proveniență sau flux de lucru, astfel încât FHIR rămâne formatul de schimb, iar o bază de date OMOP deține în continuare date la nivel de înregistrare care trebuie guvernate ca orice bază de date de sănătate, de obicei cu ID-uri de persoană pseudonimizate într-un mediu securizat.
Nu este un format pentru îngrijire: elimină narațiunea, aplatizează stările și nu transportă consimțământul, proveniența sau fluxul de lucru. Nu este anonim de la sine: o bază de date OMOP deține date la nivel de înregistrare și este guvernată ca orice bază de date de sănătate, de obicei cu ID-uri de persoană pseudonimizate și în medii securizate. Vezi Utilizarea secundară a datelor de sănătate și De-identificarea datelor de sănătate.
În Anpheros
Înregistrările Anpheros sunt FHIR R4 cu coduri standard (LOINC, SNOMED CT, ATC, ICD-10), care este intrarea pe care o dorește un ETL OMOP; cu consimțământul persoanei pentru un scop de cercetare, extrase FHIR pseudonimizate pot alimenta ETL-ul unei platforme de cercetare. Anpheros în sine calculează doar semnale agregate la nivel de populație pe grupuri de 20 sau mai multe și nu operează o bază de date OMOP pe date identificate.
Pagini conexe
- Utilizarea secundară a datelor de sănătate: harta
- SNOMED CT vs ICD-10
- De-identificarea datelor de sănătate
- Exportul de date în bloc FHIR explicat
- Serverele de terminologie explicate
- RxNorm vs ATC
Surse
- OHDSI: OMOP Common Data Model
- OHDSI: The Book of Ohdsi
- OHDSI Athena: vocabulare standardizate
- OHDSI: ATLAS
- HL7 Vulcan: Ghid de implementare FHIR către OMOP
- Proiectul EHDEN
- EMA: DARWIN EU
Întrebări frecvente
Este OMOP un înlocuitor pentru FHIR?
Nu. FHIR schimbă înregistrarea detaliată a unui pacient între sisteme; OMOP structurează multe înregistrări pentru analiză statistică. Platformele de cercetare preiau FHIR (sau alte surse) și produc OMOP.
Ce versiune OMOP ar trebui să folosesc?
5.4 este versiunea implementată pe scară largă cu suport complet pentru instrumente; majoritatea conversiilor noi o vizează. Versiunea 6 a introdus modificări pe care comunitatea nu le-a adoptat pe scară largă.
De ce OMOP mapează codurile ICD la SNOMED CT?
Pentru ca analizele să poată fi scrise o singură dată împotriva unui singur vocabular standard, ierarhic, pentru afecțiuni, indiferent dacă sursa a folosit coduri ICD-10, ICD-10-CM, ICD-9-CM sau Read. Codul sursă este păstrat alături.
Este o bază de date OMOP anonimă?
Nu de la sine. Deține date la nivel de înregistrare, de obicei cu identificatori pseudonimizați și fără identificatori direcți, și trebuie protejată și guvernată ca orice bază de date de sănătate, de obicei în interiorul unui mediu securizat.
Încearcă gratuit în sandbox
Primul apel FHIR în 5 minute. Un API HL7 FHIR R4 cu consimțământul pacientului integrat: încearcă-l în sandbox, apoi conectează-ți propria aplicație sau sistemul clinicii.
Gratuit · 30 de pacienți sintetici · fără card
Anpheros construiește un dosar medical pe care pacientul îl controlează și îl poate da oricărei clinici, pe o platformă HL7 FHIR R4, cu sediul în UE. Ghidurile te ajută să-ți înțelegi și să-ți organizezi sănătatea; nu înlocuiesc medicul.
Despre Anpheros →