Краткий ответ: OMOP Common Data Model (Observational Medical Outcomes Partnership CDM), поддерживаемая сообществом OHDSI, представляет собой реляционную схему, в которую преобразуются медицинские данные из любого источника (электронные медицинские карты, страховые данные, реестры), вместе с набором стандартизированных словарей, которые сопоставляют каждый локальный код со стандартным идентификатором концепта. Как только база данных переведена в формат OMOP, один и тот же аналитический код (определение когорты, оценка заболеваемости, исследование сравнительной эффективности) работает без изменений для сотен баз данных по всему миру, и передаются только агрегированные результаты. OMOP — это модель для исследований; FHIR — это модель для обмена данными и ухода за пациентами; опубликованное сопоставление связывает их, и большинство исследовательских платформ теперь принимают FHIR в качестве источника для их OMOP ETL.
Модель на одной картинке
Общая модель данных OMOP представляет все как событие, связанное с человеком в период наблюдения. Клиническая область определяет соответствующую таблицу: condition_occurrence для диагнозов, drug_exposure для лекарств, measurement для лабораторных результатов и жизненных показателей, procedure_occurrence, visit_occurrence, observation для других фактов, а также таблицы person, death, note, specimen, provider и cost. Версия 5.4 является наиболее распространенной.
Все является событием о человеке в течение периода наблюдения, причем клиническая область определяет таблицу:
| Таблица | Содержит | Стандартный словарь (типичный) | Источник FHIR |
|---|---|---|---|
| person | Одна строка на человека: пол, дата рождения, раса, этническая принадлежность, местоположение | Концепты пола, расы, этнической принадлежности | Patient |
| observation_period | Периоды, в течение которых ожидаются данные о человеке | — | Получено из дат покрытия и визитов |
| visit_occurrence (и visit_detail) | Визиты: стационарные, амбулаторные, экстренные, с датами | Концепты визитов | Encounter |
| condition_occurrence | Диагнозы и проблемы с началом и окончанием | SNOMED CT | Condition (коды ICD, сопоставленные с SNOMED) |
| drug_exposure | Рецепты, выдачи, назначения с количеством и сроком действия | RxNorm (и RxNorm Extension для неамериканских лекарств) | MedicationRequest, MedicationStatement, MedicationAdministration, MedicationDispense |
| procedure_occurrence | Выполненные процедуры | SNOMED CT, CPT4, ICD10PCS | Procedure |
| measurement | Результаты лабораторных исследований и жизненно важные показатели со значением, единицей измерения, диапазоном | LOINC, с единицами измерения UCUM | Observation (laboratory, vital signs) |
| observation | Другие клинические факты: история болезни, социальные факторы, оценки | SNOMED CT, LOINC | Observation (other), QuestionnaireResponse, FamilyMemberHistory |
| device_exposure | Используемые устройства | SNOMED CT | DeviceUseStatement, Procedure |
| death | Дата и причина смерти | SNOMED CT | Patient.deceased, Observation |
| note, note_nlp | Клинические заметки и извлеченные NLP термины | — | DocumentReference, DiagnosticReport |
| specimen | Образцы | SNOMED CT | Specimen |
| provider, care_site, location | Клиницисты, учреждения, места | Концепты специализации | Practitioner, Organization, Location |
| cost, payer_plan_period | Расходы и покрытие | — | Coverage, Claim (где доступно) |
Версия 5.4 используется на большинстве сайтов; версия 6 существует, но не получила широкого распространения, и разработка продолжается по линии 5.x.
Словари
Стандартизированные словари OMOP, распространяемые OHDSI через Athena, загружают более ста кодовых систем (SNOMED CT, LOINC, RxNorm, ICD-10, ATC и другие) в таблицы concept, concept_relationship и concept_ancestor. Каждый код становится concept_id, либо стандартным, либо сопоставленным со стандартным, поэтому анализы пишутся один раз, а исходный код сохраняется.
Вторая половина OMOP — это Athena, дистрибутив словарей OHDSI: более ста систем кодирования (SNOMED CT, LOINC, RxNorm, ICD-10 и национальные варианты, ATC, CPT, Read и многие другие), загруженные в таблицы concept, concept_relationship, concept_ancestor. Каждый код становится concept_id; каждый концепт является либо стандартным (используемым в анализах), либо нестандартным (исходный код, который сопоставляется со стандартным), либо классификацией. ETL хранит как исходный концепт (что было в записи: ICD-10 E11.9), так и стандартный концепт (SNOMED 44054006), поэтому анализы пишутся один раз против стандартных концептов, а оригинал сохраняется. Таблица concept_ancestor позволяет когорте запросить "любой тип диабета" одним соединением. См. SNOMED CT vs ICD-10 для объяснения, почему стандартом для состояний является SNOMED CT.
ETL
ETL OMOP — это работа по преобразованию исходной базы данных в общую модель данных, поддерживаемая инструментами OHDSI: WhiteRabbit профилирует источник, Rabbit-in-a-Hat документирует сопоставление таблиц, Usagi сопоставляет локальные коды со стандартными концепциями, Data Quality Dashboard проверяет результат на соответствие тысячам правил, а ACHILLES характеризует готовую базу данных.
Преобразование источника в OMOP — основная работа. Инструменты OHDSI помогают: WhiteRabbit сканирует источник и профилирует его; Rabbit-in-a-Hat документирует сопоставление из исходных таблиц с таблицами CDM; Usagi помогает сопоставить локальные коды со стандартными концептами; Data Quality Dashboard проверяет результат на соответствие тысячам правил; ACHILLES характеризует базу данных. Типичные решения: как определяются визиты, как записи о лекарствах становятся экспозициями с указанием срока действия, как нормализуются единицы измерения, что делать с кодами, у которых нет стандартного сопоставления, и как обрабатывать обновления (полная перезагрузка против инкрементальной).
Анализ в сети
Анализ в сети OHDSI работает по принципу написания исследования один раз и его выполнения везде: исследователи определяют когорты в ATLAS, проводят оценку и прогнозирование с помощью пакетов R HADES и упаковывают анализ в виде кода, который каждый сайт выполняет локально на своей базе данных OMOP, обмениваясь только агрегированными результатами. DARWIN EU и EHDEN следуют этой модели.
ATLAS — это веб-инструмент, где исследователи создают определения когорт (люди с состоянием X, подвергшиеся воздействию препарата Y, в течение временных окон), характеризуют их и проводят исследования по оценке и прогнозированию с помощью пакетов R HADES (CohortMethod, PatientLevelPrediction, SelfControlledCaseSeries). Сетевое исследование упаковывает анализ в виде кода; каждый сайт запускает его локально на своей базе данных OMOP и делится агрегированными результатами; никто не объединяет данные на уровне записей. Именно так сообщество OHDSI быстро провело крупные многонациональные исследования во время пандемии, и это модель, лежащая в основе сети DARWIN EU EMA и проекта EHDEN, который преобразовал более ста европейских баз данных в OMOP.
FHIR в OMOP
FHIR сопоставляется с OMOP на двух уровнях: ресурсы с таблицами и элементы со столбцами, при этом коды FHIR переводятся через словари OMOP в стандартные концепции. Руководство по реализации FHIR в OMOP от HL7 и рабочая группа FHIR OHDSI публикуют сопоставления; несколько платформ выполняют ETL непосредственно с сервера FHIR или экспорта больших данных (Bulk Data export).
FHIR и OMOP отвечают разным потребностям: FHIR передает запись одного пациента между системами с полной детализацией; OMOP "выравнивает" записи многих пациентов для статистического анализа. Сопоставление естественно на уровне ресурсов (таблица выше) и детализировано на уровне элементов: коды FHIR сопоставляются через словари OMOP со стандартными концептами; Observation.valueQuantity становится measurement value_as_number с unit_concept_id; Encounter.class становится visit_concept_id. Руководство по реализации FHIR в OMOP от HL7 (через ускоритель Vulcan) и рабочая группа OHDSI по FHIR публикуют сопоставления и эталонные реализации; несколько платформ запускают ETL непосредственно с сервера FHIR или экспорта Bulk Data. Неоднозначности остаются там, где FHIR богаче (несколько кодировок, статусов, происхождение данных) или где OMOP требует того, чего нет в FHIR (срок действия, периоды наблюдения).
Чем OMOP не является
OMOP не является форматом для оказания медицинской помощи и сам по себе не анонимен: он отбрасывает нарратив, упрощает статусы и не несет согласия, происхождения или рабочего процесса. Поэтому FHIR остается форматом обмена, а база данных OMOP по-прежнему содержит данные на уровне записей, которыми необходимо управлять, как и любой медицинской базой данных, обычно с псевдонимизированными идентификаторами пациентов в безопасной среде.
Это не формат для ухода за пациентами: он отбрасывает повествование, "выравнивает" статусы и не несет информации о согласии, происхождении данных или рабочем процессе. Сам по себе он не является анонимным: база данных OMOP содержит данные на уровне записей и управляется как любая медицинская база данных, обычно с псевдонимизированными идентификаторами пациентов и в безопасных средах. См. Вторичное использование медицинских данных и Деидентификация медицинских данных.
В Anpheros
Записи Anpheros представлены в формате FHIR R4 со стандартными кодами (LOINC, SNOMED CT, ATC, ICD-10), что является входными данными, которые требуются OMOP ETL; с согласия пациента для исследовательских целей псевдонимизированные выгрузки FHIR могут подаваться в ETL исследовательской платформы. Сам Anpheros вычисляет только агрегированные популяционные сигналы по группам из 20 или более человек и не работает с базой данных OMOP на основе идентифицированных данных.
Связанные страницы
- Вторичное использование медицинских данных: карта
- SNOMED CT против ICD-10
- Деидентификация медицинских данных
- Объяснение экспорта FHIR Bulk Data
- Объяснение серверов терминологии
- RxNorm против ATC
Источники
- OHDSI: OMOP Common Data Model
- OHDSI: The Book of OHDSI
- OHDSI Athena: стандартизированные словари
- OHDSI: ATLAS
- HL7 Vulcan: руководство по реализации FHIR в OMOP
- Проект EHDEN
- EMA: DARWIN EU
Частые вопросы
Является ли OMOP заменой FHIR?
Нет. FHIR обменивается подробной записью одного пациента между системами; OMOP структурирует множество записей для статистического анализа. Исследовательские платформы принимают FHIR (или другие источники) и производят OMOP.
Какую версию OMOP следует использовать?
5.4 — это широко развернутая версия с полной поддержкой инструментов; большинство новых преобразований нацелены на нее. Версия 6 внесла изменения, которые сообщество не приняло в широком масштабе.
Почему OMOP сопоставляет коды ICD с SNOMED CT?
Чтобы анализы можно было писать один раз против единого, иерархического стандартного словаря для состояний, независимо от того, использовал ли источник ICD-10, ICD-10-CM, ICD-9-CM или коды Read. Исходный код сохраняется рядом.
Является ли база данных OMOP анонимной?
Не сама по себе. Она содержит данные на уровне записей, обычно с псевдонимизированными идентификаторами и без прямых идентификаторов, и должна защищаться и управляться как любая медицинская база данных, как правило, в безопасной среде.
Попробуйте бесплатно в песочнице
Первый запрос FHIR за 5 минут. API HL7 FHIR R4 с встроенным согласием пациента: попробуйте в песочнице, затем подключите свое приложение или систему клиники.
Бесплатно · 30 синтетических пациентов · без карты
Anpheros создает медицинскую карту, которую пациент контролирует и может делиться с любой клиникой, на платформе HL7 FHIR R4, базирующейся в ЕС. Эти руководства помогут вам понять и организовать свое здоровье; они не заменяют вашего врача.
О Anpheros →