Rövid válasz: az OMOP Common Data Model (Observational Medical Outcomes Partnership CDM), amelyet az OHDSI közösség tart karban, egy relációs séma, amelybe bármilyen forrásból (EHR-ek, számlák, nyilvántartások) származó egészségügyi adatokat konvertálnak, valamint egy sor szabványosított szókincs, amely minden helyi kódot egy szabványos koncepcióazonosítóhoz (concept id) rendel. Miután egy adatbázis OMOP formátumban van, ugyanaz az elemzési kód (egy kohorszdefiníció, egy incidenciabecslés, egy összehasonlító hatékonysági tanulmány) változatlanul fut több száz adatbázison világszerte, és csak az összesített eredményeket osztják meg. Az OMOP a kutatás modellje; a FHIR a csere és gondozás modellje; egy publikált leképezés köti össze őket, és a legtöbb kutatási platform ma már elfogadja a FHIR-t az OMOP ETL forrásaként.
A modell egy képben
Az OMOP Common Data Model mindent eseményként ábrázol egy személyről egy megfigyelési időszak alatt, a klinikai tartomány határozza meg a táblát: condition_occurrence a diagnózisokhoz, drug_exposure a gyógyszerekhez, measurement a laboreredményekhez és életjelekhez, procedure_occurrence, visit_occurrence, observation egyéb tényekhez, továbbá person, death, note, specimen, provider és cost táblák. Az 5.4-es verzió a legelterjedtebb.
Minden egy esemény egy személyről egy megfigyelési időszak alatt, a klinikai tartomány határozza meg a táblát:
| Tábla | Tartalmazza | Szabványos szókincs (tipikus) | FHIR forrás |
|---|---|---|---|
| person | Egy sor személyenként: nem, születési dátum, faj, etnikum, tartózkodási hely | Gender, Race, Ethnicity koncepciók | Patient |
| observation_period | Időszakok, amelyek alatt az adatok a személyről várhatók | — | Coverage és encounter dátumokból származtatva |
| visit_occurrence (és visit_detail) | Ellátások: fekvőbeteg, járóbeteg, sürgősségi, dátumokkal | Visit koncepciók | Encounter |
| condition_occurrence | Diagnózisok és problémák kezdettel és véggel | SNOMED CT | Condition (ICD kódok SNOMED-hez rendelve) |
| drug_exposure | Felírások, kiváltások, beadások mennyiséggel és napok számával | RxNorm (és RxNorm Extension nem amerikai gyógyszerekhez) | MedicationRequest, MedicationStatement, MedicationAdministration, MedicationDispense |
| procedure_occurrence | Végrehajtott eljárások | SNOMED CT, CPT4, ICD10PCS | Procedure |
| measurement | Laboreredmények és életjelek értékkel, egységgel, tartománnyal | LOINC, UCUM egységekkel | Observation (laboratory, vital signs) |
| observation | Egyéb klinikai tények: kórtörténet, szociális, pontszámok | SNOMED CT, LOINC | Observation (other), QuestionnaireResponse, FamilyMemberHistory |
| device_exposure | Használt eszközök | SNOMED CT | DeviceUseStatement, Procedure |
| death | Dátum és ok | SNOMED CT | Patient.deceased, Observation |
| note, note_nlp | Klinikai jegyzetek és NLP-ből kinyert kifejezések | — | DocumentReference, DiagnosticReport |
| specimen | Minták | SNOMED CT | Specimen |
| provider, care_site, location | Orvosok, intézmények, helyszínek | Specialty koncepciók | Practitioner, Organization, Location |
| cost, payer_plan_period | Költségek és fedezet | — | Coverage, Claim (ahol elérhető) |
Az 5.4 verzió az, amit a legtöbb helyen használnak; a 6-os verzió létezik, de nem terjedt el széles körben, és a fejlesztés az 5.x vonalon folytatódik.
A szókincsek
Az OMOP standardizált szókincsei, amelyeket az OHDSI az Athena-n keresztül terjeszt, több mint száz kódrendszert (SNOMED CT, LOINC, RxNorm, ICD-10, ATC és mások) töltenek be a concept, concept_relationship és concept_ancestor táblákba. Minden kód concept_id-vé válik, akár standard, akár egy standardhoz rendelt, így az elemzések egyszer íródnak meg, miközben az eredeti forráskód megmarad.
Az OMOP második fele az Athena, az OHDSI szókincs-elosztója: több mint száz kódtípus (SNOMED CT, LOINC, RxNorm, ICD-10 és nemzeti változatok, ATC, CPT, Read, és még sok más) van betöltve a concept, concept_relationship, concept_ancestor táblákba. Minden kód egy koncepcióazonosítóvá (concept_id) válik; minden koncepció vagy szabványos (amelyet az elemzések használnak), nem szabványos (egy forráskód, amely egy szabványoshoz kapcsolódik), vagy egy osztályozás. Az ETL mind a forráskoncepciót (amit a rekord mondott: ICD-10 E11.9), mind a szabványos koncepciót (SNOMED 44054006) tárolja, így az elemzéseket egyszer írják meg szabványos koncepciók ellen, miközben az eredeti megmarad. A concept_ancestor tábla lehetővé teszi, hogy egy kohorsz egyetlen csatlakozással "bármilyen típusú cukorbetegséget" kérjen le. Lásd SNOMED CT vs ICD-10 a magyarázatot, miért a SNOMED CT a feltételek szabványos szókincse.
Az ETL
Az OMOP ETL a forrásadatbázis közös adattmodellre való átalakításának munkája, amelyet az OHDSI eszközök támogatnak: a WhiteRabbit profilozza a forrást, a Rabbit-in-a-Hat dokumentálja a táblamappolást, az Usagi hozzárendeli a helyi kódokat a standard koncepciókhoz, az Adatminőség-ellenőrző Dashboard (Data Quality Dashboard) több ezer szabály ellenőrzését végzi az eredménnyel, és az ACHILLES jellemzi a kész adatbázist.
A forrás OMOP-ra konvertálása a fő munka. Az OHDSI eszközei segítenek: a WhiteRabbit beolvassa a forrást és profilozza azt; a Rabbit-in-a-Hat dokumentálja a forrástáblák és a CDM táblák közötti leképezést; az Usagi segít a helyi kódok szabványos koncepciókhoz rendelésében; az Data Quality Dashboard több ezer szabály ellen ellenőrzi az eredményt; az ACHILLES jellemzi az adatbázist. Tipikus döntések: hogyan definiálják az ellátásokat, hogyan válnak a gyógyszerfeljegyzések expozíciókká napok ellátásával, hogyan normalizálják az egységeket, mit tegyenek azokkal a kódokkal, amelyeknek nincs szabványos leképezése, és hogyan kezeljék a frissítéseket (teljes újratöltés vs. inkrementális).
Elemzés a hálózaton keresztül
Az OHDSI hálózaton keresztüli elemzés úgy működik, hogy egy tanulmányt egyszer írnak meg, és mindenhol futtatnak: a kutatók a cohortokat az ATLAS-ban határozzák meg, becslést és előrejelzést futtatnak a HADES R csomagokkal, és az elemzést kóddá csomagolják, amelyet minden helyszín helyileg futtat a saját OMOP adatbázisán, csak az összesített eredményeket osztva meg. A DARWIN EU és az EHDEN követi ezt a modellt.
Az ATLAS az a webes eszköz, ahol a kutatók kohorszdefiníciókat (X feltétellel rendelkező személyek, Y gyógyszernek kitéve, időablakokon belül) építenek, jellemzik őket, és becslési és predikciós tanulmányokat futtatnak a HADES R csomagokkal (CohortMethod, PatientLevelPrediction, SelfControlledCaseSeries). Egy hálózati tanulmány kódként csomagolja az elemzést; minden helyszín helyileg futtatja az OMOP adatbázisán, és összesített eredményeket oszt meg; senki sem vonja össze a rekord-szintű adatokat. Így az OHDSI közösség gyorsan végzett nagyszabású nemzetközi tanulmányokat a pandémia alatt, és ez a modell áll az EMA DARWIN EU hálózata és az EHDEN projekt mögött, amely több mint száz európai adatbázist konvertált OMOP-ra.
FHIR-től OMOP-ig
A FHIR két szinten mapolódik az OMOP-hoz: erőforrások táblákhoz és elemek oszlopokhoz, a FHIR kódokat az OMOP szókincsein keresztül standard koncepciókhoz fordítva. Az HL7 FHIR-től OMOP-ig implementációs útmutatója és az OHDSI FHIR munkacsoportja teszi közzé a mappolásokat; több platform futtatja az ETL-t közvetlenül egy FHIR szerverről vagy a Bulk Data exportból.
A FHIR és az OMOP különböző igényeket elégítenek ki: a FHIR egy beteg rekordját viszi rendszerek között teljes részletességgel; az OMOP sok beteg rekordját lapítja statisztikai elemzésre. A leképezés erőforrás-szinten (fenti tábla) természetes, és elem-szinten részletes: a FHIR kódok az OMOP szókincsein keresztül szabványos koncepciókhoz kapcsolódnak; az Observation.valueQuantity lesz a measurement value_as_number, unit_concept_id-val; az Encounter.class lesz a visit_concept_id. A HL7 FHIR to OMOP implementation guide (a Vulcan gyorsítóprogramon keresztül) és az OHDSI FHIR munkacsoportja publikálja a leképezéseket és referenciaműködtetéseket; több platform futtatja az ETL-t közvetlenül FHIR szerverről vagy Bulk Data exportból. Továbbra is vannak kétértelműségek ott, ahol a FHIR gazdagabb (több kódolás, állapot, eredet) vagy ahol az OMOP-nak szüksége van valamire, ami a FHIR-ből hiányzik (napok ellátása, megfigyelési időszakok).
Mi az OMOP nem
Az OMOP nem a gondozás formátuma, és önmagában nem anonim: elhagyja a narratívát, ellaposítja a státuszokat, és nem tartalmaz beleegyezést, származást vagy munkafolyamatot, így a FHIR marad a csereformátum, és egy OMOP adatbázis továbbra is rekord szintű adatokat tartalmaz, amelyeket bármely egészségügyi adatbázishoz hasonlóan kell kezelni, általában álnéven megadott személyazonosítókkal egy biztonságos környezetben.
Nem gondozási formátum: elhagyja a narratívát, lapítja az állapotokat, és nem hordozza a beleegyezést, az eredetet vagy a munkafolyamatot. Nem önmagában anonim: egy OMOP adatbázis rekord-szintű adatokat tartalmaz, és úgy szabályozzák, mint bármely egészségügyi adatbázist, általában álnéven megadott személyazonosítókkal és biztonságos környezetben. Lásd Egészségügyi adatok másodlagos felhasználása és Egészségügyi adatok anonimizálása.
Az Anpheros-ban
Az Anpheros rekordok FHIR R4 formátumúak, szabványos kódokkal (LOINC, SNOMED CT, ATC, ICD-10), ami az OMOP ETL bemenete; a beteg beleegyezésével kutatási célra, az álnéven megadott FHIR kivonatok táplálhatják egy kutatási platform ETL-jét. Az Anpheros maga csak összesített populációs jeleket számol 20 vagy több fős csoportokon, és nem működtet OMOP adatbázist azonosított adatokkal.
Kapcsolódó oldalak
- Egészségügyi adatok másodlagos felhasználása: a térkép
- SNOMED CT vs ICD-10
- Egészségügyi adatok anonimizálása
- FHIR Bulk Data export magyarázata
- Terminológiai szerverek magyarázata
- RxNorm vs ATC
Források
- OHDSI: OMOP Common Data Model
- OHDSI: The Book of OHDSI
- OHDSI: Athena: szabványosított szókincsek
- OHDSI: ATLAS
- HL7 Vulcan: FHIR to OMOP implementation guide
- EHDEN projekt
- EMA: DARWIN EU
Gyakori kérdések
Az OMOP helyettesíti a FHIR-t?
Nem. A FHIR egy beteg részletes rekordját cseréli ki rendszerek között; az OMOP sok rekordot strukturál statisztikai elemzéshez. A kutatási platformok FHIR-t (vagy más forrásokat) fogadnak be, és OMOP-ot állítanak elő.
Melyik OMOP verziót használjam?
Az 5.4 a széles körben elterjedt verzió teljes eszköz támogatással; a legtöbb új konverzió ezt célozza. A 6-os verzió olyan változtatásokat vezetett be, amelyeket a közösség nem fogadott el széles körben.
Miért rendeli az OMOP az ICD kódokat a SNOMED CT-hez?
Annak érdekében, hogy az elemzéseket egyszer lehessen megírni egyetlen, hierarchikus szabványos szókincs ellen a feltételekre, függetlenül attól, hogy a forrás ICD-10, ICD-10-CM, ICD-9-CM vagy Read kódokat használt-e. A forráskód megmarad mellette.
Anonim egy OMOP adatbázis?
Nem önmagában. Rekord-szintű adatokat tartalmaz, általában álnéven megadott azonosítókkal és közvetlen azonosítók nélkül, és védeni és szabályozni kell, mint bármely egészségügyi adatbázist, általában egy biztonságos környezeten belül.
Próbálja ki ingyen a sandboxban
Az első FHIR-hívás 5 perc alatt. Egy HL7 FHIR R4 API, amely tartalmazza a beteg beleegyezését: próbáld ki a sandboxban, majd csatlakoztasd saját alkalmazásodat vagy klinikai rendszeredet.
Ingyenes · 30 szintetikus beteg · kártya nélkül
Az Anpheros egy olyan egészségügyi nyilvántartást épít, amelyet a beteg irányít, és megoszthat bármelyik klinikával, egy EU-ban működő HL7 FHIR R4 platformon. Ezek az útmutatók segítenek megérteni és rendszerezni az egészségügyi adataidat; nem helyettesítik az orvosodat.
Tudj meg többet az Anpherosról →