Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
Схема базы данных FHIR
Как хранить ресурсы FHIR: нормализованные таблицы против JSON с индексами поиска против графа, схема PostgreSQL, на которой работает Anpheros (ресурсы, история, типизированные индексы, проекции) и важные правила.
База данных FHIR хранит ресурсы HL7 FHIR, чтобы их можно было читать, искать и версионировать через FHIR API; наиболее распространенная схема хранит каждый ресурс в виде JSON и заполняет отдельные индексные таблицы для параметров поиска, вместо того чтобы распределять каждый элемент по нормализованным реляционным таблицам. На этой странице объясняются три обычных дизайна, схема, которую Anpheros использует в PostgreSQL, и когда вам не следует создавать свою собственную.
Три способа хранения FHIR
| Normalised tables | JSON + search indexes | Graph database | |
|---|---|---|---|
| Stores any valid resource unchanged | — | ✓ | ✓ |
| Standard FHIR search on any parameter | ◐ | ✓ | ◐ |
| New fields need a schema migration | ✓ | — | — |
| Easy SQL reporting | ✓ | ◐ | — |
| Used by mainstream FHIR servers | ◐ | ✓ | — |
◐ = possible with extra work. HAPI FHIR and Anpheros both keep the resource as JSON and index search parameters separately.
FHIR-ресурсы являются глубокими, опциональными и расширяемыми: один ресурс Observation имеет десятки элементов, выбор типов (value[x]), повторяющиеся кодировки и расширения. Нормализация этого в реляционные столбцы означает миграцию при каждом добавлении поля в профиль. Хранение ресурса в виде JSON сохраняет все допустимое без изменений; индексные таблицы делают его доступным для поиска.
Схема Anpheros
- APIFHIR R4 REST and the simpler /v1 REST API
- Current resourcesOne row per resource: type, id, patient, version, the full FHIR JSON (JSONB)
- Search indexesTyped tables filled on every write: token, string, date, reference, quantity
- HistoryEvery version of every resource, never overwritten
- ProjectionsFlat tables for the common REST views: observations, conditions, medications
- PostgreSQLOne database per environment; sandbox and production are separate
| Таблица | Одна строка на | Ключевые столбцы |
|---|---|---|
fhir_resources |
текущая версия ресурса | resource_type, id, patient_id, version, json (полный ресурс), last_updated, deleted, а также столбцы provenance |
fhir_history |
каждая когда-либо записанная версия | resource_type, id, version, json, last_updated |
idx_token |
значение для поиска по коду или идентификатору | system, code — для code, category, identifier, status |
idx_string |
значение для текстового поиска | нормализованный текст — для имен и свободного текста |
idx_date |
значение для поиска по дате | начало и конец диапазона — для date, onset-date, birthdate |
idx_reference |
значение для поиска по ссылке | target type и id — для patient, subject, encounter |
idx_quantity |
значение для поиска по количеству | value, system, unit — для value-quantity |
proj_observations, proj_conditions, proj_medications |
ресурс, развернутый | столбцы, по которым фильтрует простой REST API |
При каждой записи платформа проверяет ресурс, записывает новую версию в fhir_resources и fhir_history, заменяет строки индекса и проекции, а также записывает Provenance. Поиск, такой как Observation?patient=…&code=http://loinc.org|4548-4&date=ge2026-01-01, становится объединением по idx_reference, idx_token и idx_date; результат возвращает сохраненный JSON в том виде, в котором он был записан.
Важные правила проектирования
- Индексируйте только объявленные параметры поиска и отклоняйте неизвестные с кодом
400, вместо того чтобы молча игнорировать их. - Никогда не обновляйте на месте без истории: исправления должны сохранять ранее известную информацию.
- Мягкое удаление: удаленный ресурс исчезает из результатов чтения и поиска, но его версии остаются для аудита.
- Столбец "пациентский отсек": хранение
patient_idв каждом ресурсе удешевляет$everything, фильтры согласия и изоляцию по пациентам. - Проверяйте перед сохранением: недопустимый JSON в хранилище нарушит работу всех последующих читателей.
Часто задаваемые вопросы
Какая база данных лучше всего подходит для FHIR?
Большинство продакшн-серверов FHIR используют реляционную базу данных, такую как PostgreSQL, с ресурсами, хранящимися в формате JSON (JSONB), а параметры поиска индексируются в отдельных таблицах. Это сочетает гибкое хранение с быстрым, стандартным поиском.
Следует ли нормализовать ресурсы FHIR в реляционные таблицы?
Обычно нет для основного хранилища. Нормализованные таблицы подходят для отчетности; сохраняйте их как проекции, построенные из хранимых ресурсов, как это делает Anpheros для своего более простого REST API.
Как HAPI FHIR хранит ресурсы?
JPA-сервер HAPI FHIR также хранит каждую версию ресурса как сериализованный JSON и хранит параметры поиска в отдельных индексных таблицах. Дизайн Anpheros следует тому же принципу.
Нужно ли мне создавать FHIR-базу данных самостоятельно?
Только если вам нужен полный контроль над профилями и типами ресурсов. В противном случае управляемая FHIR-платформа предоставит вам хранилище, поиск, историю, согласие и аудит без необходимости управления схемой.
Связанные материалы
- FHIR против пользовательской медицинской базы данных
- Как хранить медицинские записи, используя FHIR R4
- Бесплатная база данных FHIR и песочница
- Сравнение Anpheros с другими FHIR-серверами
- Платформа FHIR
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card