Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

FHIR против пользовательской медицинской базы данных

Ваши собственные таблицы или HL7 FHIR R4 для медицинских данных: одинаковое чтение, сохраненное обоими способами, компромиссы бок о бок, когда каждый вариант подходит, и обычное разделение между вашей базой данных и записью FHIR.

Команда, начинающая медицинский продукт, обычно сталкивается с одним и тем же выбором на раннем этапе: спроектировать собственные таблицы для пациентов, измерений и диагнозов в PostgreSQL или другой базе данных, или с самого начала хранить медицинские данные в виде ресурсов HL7 FHIR R4. Пользовательская схема быстрее в первый день и точно соответствует вашему продукту. FHIR требует больше размышлений на начальном этапе и окупается каждый раз, когда данные должны покинуть вашу систему, пройти аудит, быть переданы с согласия или прочитаны кем-то, кто не вы. Эта страница честно излагает компромиссы, с одним и тем же чтением, хранящимся обоими способами, и говорит, когда каждый выбор правильный.

Это отличается от вопроса о том, какой FHIR-сервер использовать. Для этого см. Как Anpheros сравнивается с другими FHIR-серверами.

Одно и то же измерение, два способа представления

Измерение артериального давления в пользовательской схеме:

CREATE TABLE bp_readings (
  id          uuid PRIMARY KEY,
  user_id     uuid REFERENCES users(id),
  systolic    int,
  diastolic   int,
  measured_at timestamptz,
  created_at  timestamptz DEFAULT now()
);

Просто, быстро для запросов, именно то, что нужно приложению. Затем возникают вопросы, на которые таблица не дает ответа:

• Какое устройство или человек произвел значение? Было ли оно введено пациентом, измерено манжетой или внесено медсестрой?
• Каким было значение до того, как кто-то его исправил, и кто его исправил?
• Как его прочитает системный клиник, лаборатория или страховщик? Что означает systolic в их системе?
• Как пациент поделится им с приложением своего врача и прекратит делиться им в следующем месяце?
• Когда вы добавляете частоту сердечных сокращений, вес, HbA1c и еще 200 измерений, это 200 таблиц или одна универсальная таблица, которую вы разрабатываете сами?

То же измерение в формате FHIR R4:

{"resourceType": "Observation", "status": "final",
 "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "vital-signs"}]}],
 "code": {"coding": [{"system": "http://loinc.org", "code": "85354-9", "display": "Blood pressure panel"}]},
 "subject": {"reference": "Patient/d09e3942-…"}, "effectiveDateTime": "2026-10-10T08:30:00Z",
 "component": [
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8480-6"}]}, "valueQuantity": {"value": 138, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}},
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8462-4"}]}, "valueQuantity": {"value": 88, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}}],
 "meta": {"versionId": "1"}}

Более многословно, но каждая часть имеет значение, общее для любой системы FHIR: LOINC указывает, что было измерено, UCUM — единицу измерения, meta.versionId начинает историю, а та же форма Observation содержит остальные 200 измерений. С Anpheros ресурс Provenance также записывает, кто его создал. Как хранить медицинские записи с использованием FHIR R4 подробно описывает этот процесс.

Параллельное сравнение

Когда пользовательская схема — правильный выбор

• Данные не являются медицинскими или не относятся к одному человеку. Планы обучения, контент, каталог продуктов: используйте свои собственные таблицы.
• Краткосрочный прототип для проверки спроса на продукт с использованием синтетических данных и планом миграции.
• Данные плохо соответствуют стандартным моделям, например, новое исследовательское измерение. FHIR все еще может их содержать (Observation с вашей собственной системой кодирования или Basic), но пользовательская таблица может быть более понятной.
• Интенсивная аналитика. Даже при использовании FHIR в качестве системы записи, большинство команд копируют данные в хранилище данных в собственной структуре для отчетности.

Когда FHIR — правильный выбор

• Данные представляют собой медицинскую карту человека: измерения, диагнозы, лекарства, аллергии, результаты лабораторных исследований, документы.
• Данные будут покидать вашу систему: пациенту, врачу, клинике, лаборатории, страховщику, модели ИИ или конкуренту при переезде пациента.
• Вам необходимо отслеживать, кто что записал и что изменилось: аудит, клиническая безопасность, разрешение споров.
• Пациенты будут предоставлять и отзывать доступ для каждого приложения.
• Вы продаете в Европейском Союзе, где Европейское пространство данных о здоровье (European Health Data Space) ожидает, что записи будут обмениваться в стандартных форматах.

Обычный средний путь

Большинство продуктов в итоге используют оба подхода, разделяя данные по типу:

your database                         FHIR record (Anpheros)
─────────────                         ──────────────────────
users, sessions, settings             Patient
subscriptions, billing                Observation, Condition, MedicationStatement
product content, feature flags        AllergyIntolerance, Immunization, DocumentReference
user id → patient id (one column)     Provenance, Consent, history
caches and analytics copies  ◄─────── webhooks

Ваша база данных остается небольшой и соответствует форме продукта. Медицинская карта стандартизирована, версионирована и доступна для обмена, и вам не пришлось ее создавать. Бэкенд и база данных медицинского приложения подробно описывает это разделение, а Как создать API для здравоохранения с помощью TypeScript реализует его.

Что нужно для самостоятельной разработки FHIR

Выбор FHIR не означает написание FHIR-сервера с нуля. Ваши варианты: запуск open-source сервера, использование FHIR-хранилища облачного провайдера, open-source медицинской платформы или управляемой медицинской базы данных, такой как Anpheros. Они различаются тем, кто отвечает за управление согласиями, аудитом, происхождением данных, размещением и интеграциями, что подробно описано в Сравнение Anpheros с другими FHIR-серверами.

Часто задаваемые вопросы

Является ли FHIR базой данных?

Нет. FHIR — это стандарт для структуры и обмена медицинскими данными: ресурсов, кодов и REST API. FHIR-сервер или управляемая FHIR-база данных хранит ресурсы и реализует API поверх реальной базы данных.

Могу ли я самостоятельно хранить FHIR-ресурсы в PostgreSQL?

Да, в виде JSON-колонок с вашими собственными индексами, и некоторые open-source серверы делают именно это. Работа заключается во всем, что связано с хранением: параметрах поиска, версионировании, ссылках, валидации, контроле доступа по пациентам и происхождении данных.

Могу ли я начать с пользовательской схемы и перейти на FHIR позже?

Можете, и многие команды так делают, но миграция — это проект по сопоставлению: каждая таблица нуждается в кодах, единицах измерения и авторах, которые она никогда не записывала. Хранение медицинских данных в формате FHIR с первой же функции обходится дешевле, чем их последующее преобразование.

Нужен ли мне FHIR для соблюдения GDPR?

Нет. GDPR не требует определенного формата. FHIR упрощает выполнение нескольких обязательств: переносимость (запись экспортируется в стандартном формате), контроль доступа по назначению и отображение того, кто обрабатывал какие данные.

Связанные материалы

• Схема базы данных FHIR: как ресурсы FHIR хранятся и индексируются
• Как хранить медицинские записи с использованием FHIR R4
• Платформа FHIR
• Сравнение Anpheros с другими серверами FHIR
• Бэкенд и база данных медицинских приложений
• API для здравоохранения

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card