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 є правильним вибором

• Дані є медичною картою особи: вимірювання, діагнози, ліки, алергії, результати лабораторних досліджень, документи.
• Вони коли-небудь залишать вашу систему: пацієнту, лікарю, клініці, лабораторії, страховій компанії, моделі ШІ або конкуренту, коли пацієнт переїде.
• Вам потрібно показати, хто що написав і що змінилося: аудити, клінічна безпека, суперечки.
• Пацієнти надаватимуть і відкликатимуть доступ для кожного додатка.
• Ви продаєте в Європейському Союзі, де Європейський простір даних про здоров'я очікує, що записи будуть обмінюватися у стандартних форматах.

Звичайний середній шлях

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

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-сервера з нуля. Ваші варіанти включають: використання відкритого серверу, який ви розгортаєте самостійно, FHIR-сховища від хмарного провайдера, відкритої медичної платформи або керованої медичної бази даних, такої як Anpheros. Вони відрізняються тим, хто відповідає за керування згодою, аудитом, походженням даних, їхнім розміщенням та інтеграціями, що детально описано в Порівняння Anpheros з іншими FHIR-серверами.

Часті запитання

Чи є FHIR базою даних?

Ні. FHIR — це стандарт для структури та обміну медичними даними: ресурсів, кодів та REST API. Сервер FHIR або керована база даних FHIR зберігає ресурси та реалізує API поверх реальної бази даних.

Чи можу я самостійно зберігати ресурси FHIR у PostgreSQL?

Так, як JSON-стовпці з вашими власними індексами, і деякі серверні рішення з відкритим кодом роблять саме це. Робота полягає у всьому, що стосується зберігання: параметрів пошуку, версіонування, посилань, валідації, контролю доступу для кожного пацієнта та походження даних.

Чи можу я почати з власної схеми, а потім перейти на 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