Kısa cevap: OHDSI topluluğu tarafından sürdürülen OMOP Ortak Veri Modeli (Observational Medical Outcomes Partnership CDM), sağlık verilerinin herhangi bir kaynaktan (EHR'ler, talepler, kayıtlar) dönüştürüldüğü ilişkisel bir şema ve her yerel kodu standart bir kavram kimliğine eşleyen bir dizi standartlaştırılmış kelime hazinesidir. Bir veritabanı OMOP'a girdikten sonra, aynı analiz kodu (bir kohort tanımı, bir insidans tahmini, bir karşılaştırmalı etkinlik çalışması) dünya çapında yüzlerce veritabanında değişmeden çalışır ve yalnızca toplu sonuçlar paylaşılır. OMOP araştırma için bir modeldir; FHIR ise değişim ve bakım için bir modeldir; yayınlanmış bir eşleme onları birbirine bağlar ve çoğu araştırma platformu artık OMOP ETL'si için bir kaynak olarak FHIR'ı kabul etmektedir.
Model tek bir resimde
OMOP Ortak Veri Modeli, her şeyi bir gözlem dönemi boyunca bir kişiyle ilgili bir olay olarak temsil eder; klinik alan tabloyu belirler: teşhisler için condition_occurrence, ilaçlar için drug_exposure, laboratuvar sonuçları ve yaşamsal belirtiler için measurement, prosedürler için procedure_occurrence, ziyaretler için visit_occurrence, diğer gerçekler için observation ve ayrıca person, death, note, specimen, provider ve cost tabloları. Sürüm 5.4 en yaygın kullanılanıdır.
Her şey, gözlem dönemi boyunca bir kişi hakkındaki bir olaydır, klinik alan tabloyu belirler:
| Tablo | Tutuyor | Standart kelime hazinesi (tipik) | FHIR kaynağı |
|---|---|---|---|
| person | Kişi başına bir satır: cinsiyet, doğum tarihi, ırk, etnik köken, konum | Cinsiyet, Irk, Etnik Köken kavramları | Patient |
| observation_period | Kişi hakkında veri beklendiği dönemler | — | Kapsam ve karşılaşma tarihlerinden türetilmiştir |
| visit_occurrence (ve visit_detail) | Karşılaşmalar: yatan hasta, ayakta hasta, acil, tarihlerle | Ziyaret kavramları | Encounter |
| condition_occurrence | Başlangıç ve bitişli teşhisler ve sorunlar | SNOMED CT | Condition (ICD kodları SNOMED'e eşlenmiş) |
| drug_exposure | Miktar ve tedarik günleri ile reçeteler, dağıtımlar, uygulamalar | RxNorm (ve ABD dışı ilaçlar için RxNorm Extension) | MedicationRequest, MedicationStatement, MedicationAdministration, MedicationDispense |
| procedure_occurrence | Yapılan prosedürler | SNOMED CT, CPT4, ICD10PCS | Procedure |
| measurement | Değer, birim, aralık ile laboratuvar sonuçları ve hayati belirtiler | LOINC, UCUM birimleri ile | Observation (laboratuvar, hayati belirtiler) |
| observation | Diğer klinik gerçekler: tarihçe, sosyal, puanlar | SNOMED CT, LOINC | Observation (diğer), QuestionnaireResponse, FamilyMemberHistory |
| device_exposure | Kullanılan cihazlar | SNOMED CT | DeviceUseStatement, Procedure |
| death | Tarih ve neden | SNOMED CT | Patient.deceased, Observation |
| note, note_nlp | Klinik notlar ve NLP ile çıkarılan terimler | — | DocumentReference, DiagnosticReport |
| specimen | Numuneler | SNOMED CT | Specimen |
| provider, care_site, location | Klinisyenler, tesisler, yerler | Uzmanlık kavramları | Practitioner, Organization, Location |
| cost, payer_plan_period | Maliyetler ve kapsam | — | Coverage, Claim (varsa) |
Sürüm 5.4 çoğu sitenin kullandığı sürümdür; sürüm 6 mevcuttur ancak yaygın olarak benimsenmemiştir ve 5.x hattında geliştirme devam etmektedir.
Kelime Hazineleri
OHDSI tarafından Athena aracılığıyla dağıtılan OMOP standartlaştırılmış kelime hazineleri, yüz yüzden fazla kod sistemini (SNOMED CT, LOINC, RxNorm, ICD-10, ATC ve diğerleri) concept, concept_relationship ve concept_ancestor tablolarına yükler. Her kod, standart veya standart olana eşlenmiş bir concept_id haline gelir, böylece analizler bir kez yazılırken orijinal kaynak kod korunur.
OMOP'un ikinci yarısı Athena'dır, OHDSI'nin kelime hazinesi dağıtımı: yüzlerce kod sistemi (SNOMED CT, LOINC, RxNorm, ICD-10 ve ulusal varyantlar, ATC, CPT, Read ve daha fazlası) concept, concept_relationship, concept_ancestor tablolarına yüklenir. Her kod bir concept_id olur; her kavram ya standart (analizlerin kullandığı), standart olmayan (standart birine eşlenen bir kaynak kod) veya bir sınıflandırmadır. ETL, hem kaynak kavramını (kaydın ne dediği: ICD-10 E11.9) hem de standart kavramı (SNOMED 44054006) depolar, böylece analizler standart kavramlara karşı bir kez yazılırken orijinali korunur. concept_ancestor tablosu, bir kohortun tek bir birleştirmeyle "herhangi bir diyabet türü" istemesine olanak tanır. Koşullar için standardın neden SNOMED CT olduğunu görmek için SNOMED CT vs ICD-10 bölümüne bakın.
ETL
OMOP ETL, bir kaynak veritabanını ortak veri modeline dönüştürme işlemidir ve OHDSI araçları tarafından desteklenir: WhiteRabbit kaynağı profiller, Rabbit-in-a-Hat tablo eşlemesini belgeler, Usagi yerel kodları standart kavramlara eşler, Veri Kalitesi Panosu sonucu binlerce kurala karşı kontrol eder ve ACHILLES bitmiş veritabanını karakterize eder.
Bir kaynağı OMOP'a dönüştürmek ana iştir. OHDSI'nin araçları yardımcı olur: WhiteRabbit kaynağı tarar ve profillerini çıkarır; Rabbit-in-a-Hat kaynak tablolarından CDM tablolarına eşlemeyi belgeler; Usagi yerel kodları standart kavramlara eşlemeye yardımcı olur; Data Quality Dashboard sonucu binlerce kurala karşı kontrol eder; ACHILLES veritabanını karakterize eder. Tipik kararlar: ziyaretlerin nasıl tanımlandığı, ilaç kayıtlarının tedarik günleri ile pozisyonlara nasıl dönüştüğü, birimlerin nasıl normalleştirildiği, standart eşlemesi olmayan kodlarla ne yapılacağı ve güncellemelerin nasıl ele alınacağı (tam yeniden yükleme vs. artımlı).
Ağ genelinde analiz
OHDSI ağındaki analiz, bir çalışmayı bir kez yazıp her yerde çalıştırmakla çalışır: araştırmacılar ATLAS'ta kohortları tanımlar, HADES R paketleriyle tahmin ve öngörü çalıştırır ve analizi her sitenin kendi OMOP veritabanında yerel olarak yürüttüğü kod olarak paketler, yalnızca toplu sonuçları paylaşır. DARWIN EU ve EHDEN bu modeli takip eder.
ATLAS, araştırmacıların kohort tanımları (X durumuna sahip kişiler, Y ilacına maruz kalanlar, zaman pencereleri içinde) oluşturduğu, bunları karakterize ettiği ve HADES R paketleri (CohortMethod, PatientLevelPrediction, SelfControlledCaseSeries) ile tahmin ve öngörü çalışmaları yürüttüğü web aracıdır. Bir ağ çalışması, analizi kod olarak paketler; her site bunu OMOP veritabanında yerel olarak çalıştırır ve toplu sonuçları paylaşır; kimse kayıt düzeyinde veri havuzlamaz. OHDSI topluluğunun pandemi sırasında hızlı bir şekilde büyük uluslararası çalışmalar ürettiği ve EMA'nın DARWIN EU ağı ile yüzlerce Avrupa veritabanını OMOP'a dönüştüren EHDEN projesinin arkasındaki model budur.
FHIR'dan OMOP'a
FHIR, OMOP'a iki seviyede eşlenir: kaynaklar tablolara ve öğeler sütunlara, FHIR kodları OMOP'un kelime hazineleri aracılığıyla standart kavramlara çevrilir. HL7'nin FHIR'dan OMOP'a uygulama kılavuzu ve OHDSI'nin FHIR çalışma grubu eşlemeleri yayınlar; birkaç platform ETL'yi doğrudan bir FHIR sunucusundan veya Toplu Veri dışa aktarmasından çalıştırır.
FHIR ve OMOP farklı ihtiyaçlara cevap verir: FHIR, tek bir hastanın ayrıntılı kaydını sistemler arasında tam ayrıntıyla taşır; OMOP, istatistiksel analiz için birçok kaydın kaydını düzleştirir. Eşleme kaynak düzeyinde (yukarıdaki tablo) doğaldır ve öğe düzeyinde ayrıntılıdır: FHIR kodları OMOP'un kelime hazineleri aracılığıyla standart kavramlara eşlenir; Observation.valueQuantity, unit_concept_id ile measurement value_as_number olur; Encounter.class, visit_concept_id olur. HL7'nin FHIR'dan OMOP'a uygulama kılavuzu (Vulcan hızlandırıcı aracılığıyla) ve OHDSI'nin FHIR çalışma grubu, eşlemeleri ve referans uygulamaları yayınlar; birkaç platform doğrudan bir FHIR sunucusundan veya Toplu Veri dışa aktarmasından ETL'yi çalıştırır. FHIR'ın daha zengin olduğu (birden fazla kodlama, durum, köken) veya OMOP'un ihtiyaç duyduğu ancak FHIR'ın eksik olduğu (tedarik günleri, gözlem dönemleri) yerlerde belirsizlikler kalır.
OMOP ne değildir
OMOP, bakım için bir format değildir ve kendi başına anonim değildir: anlatımı atar, durumları düzleştirir ve onay, köken veya iş akışı taşımaz, bu nedenle FHIR değişim formatı olarak kalır ve bir OMOP veritabanı hala kayıt düzeyinde veriler içerir ve bu veriler, genellikle güvenli bir ortamda takma adla kişisel kimlikler içeren herhangi bir sağlık veritabanı gibi yönetilmelidir.
Bakım için bir format değildir: anlatımı bırakır, durumları düzleştirir ve onay, köken veya iş akışı taşımaz. Kendi başına anonim değildir: bir OMOP veritabanı kayıt düzeyinde veri tutar ve herhangi bir sağlık veritabanı gibi yönetilir, genellikle takma adlı kişi kimlikleri ve güvenli ortamlarda. Sağlık verilerinin ikincil kullanımı ve Sağlık verilerinin anonimleştirilmesi bölümlerine bakın.
Anpheros'ta
Anpheros kayıtları, bir OMOP ETL'sinin istediği girdi olan standart kodlara (LOINC, SNOMED CT, ATC, ICD-10) sahip FHIR R4'tür; hastanın araştırma amacı için izniyle, takma adlı FHIR çıkarımları bir araştırma platformunun ETL'sini besleyebilir. Anpheros, yalnızca 20 veya daha fazla gruplar üzerinde toplu nüfus sinyalleri hesaplar ve tanımlanmış veriler üzerinde bir OMOP veritabanı çalıştırmaz.
İlgili sayfalar
- Sağlık verilerinin ikincil kullanımı: harita
- SNOMED CT vs ICD-10
- Sağlık verilerinin anonimleştirilmesi
- FHIR Toplu Veri dışa aktarma açıklandı
- Terminoloji sunucuları açıklandı
- RxNorm vs ATC
Kaynaklar
- OHDSI: OMOP Ortak Veri Modeli
- OHDSI: OHDSI Kitabı
- OHDSI Athena: standartlaştırılmış kelime hazineleri
- OHDSI: ATLAS
- HL7 Vulcan: FHIR'dan OMOP'a uygulama kılavuzu
- EHDEN projesi
- EMA: DARWIN EU
Sık sorulan sorular
OMOP, FHIR'ın yerini mi alıyor?
Hayır. FHIR, tek bir hastanın ayrıntılı kaydını sistemler arasında değişir; OMOP, istatistiksel analiz için birçok kaydı yapılandırır. Araştırma platformları FHIR'ı (veya diğer kaynakları) alır ve OMOP üretir.
Hangi OMOP sürümünü kullanmalıyım?
5.4, tam araç desteğiyle yaygın olarak dağıtılan sürümdür; çoğu yeni dönüşüm buna hedeflenir. Sürüm 6, topluluğun geniş çapta benimsemediği değişiklikler getirdi.
OMOP neden ICD kodlarını SNOMED CT'ye eşliyor?
Analizlerin, kaynağın ICD-10, ICD-10-CM, ICD-9-CM veya Read kodları kullanıp kullanmadığına bakılmaksızın, koşullar için tek, hiyerarşik bir standart kelime hazinesine karşı bir kez yazılabilsin diye. Kaynak kod yanında tutulur.
Bir OMOP veritabanı anonim mi?
Kendi başına değil. Kayıt düzeyinde veri tutar, genellikle takma adlı tanımlayıcılarla ve doğrudan tanımlayıcılar olmadan, ve herhangi bir sağlık veritabanı gibi korunmalı ve yönetilmelidir, tipik olarak güvenli bir ortamda.
Sandbox'ta ücretsiz deneyin
İlk FHIR çağrınız 5 dakikada. Hasta izniyle yerleşik HL7 FHIR R4 API: sandbox'ta deneyin, ardından kendi uygulamanızı veya klinik sisteminizi bağlayın.
Ücretsiz · 30 sentetik hasta · kart gerekmez
Anpheros, hasta kontrolünde olan ve herhangi bir klinik ile paylaşılabilecek, AB merkezli bir HL7 FHIR R4 platformu üzerinde tıbbi kayıtlar oluşturur. Bu rehberler, sağlığınızı anlamanıza ve düzenlemenize yardımcı olur; doktorunuzun yerini tutmaz.
Anpheros Hakkında →