Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
FHIR 数据库模式
如何存储 FHIR 资源：规范化表与带搜索索引的 JSON 或图数据库，Anpheros 运行的 PostgreSQL 模式（资源、历史记录、类型化索引、投影）以及重要的规则。
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，以及溯源列 |
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 |
引用搜索值 | 目标类型和 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 如何存储资源？
HAPI FHIR 的 JPA 服务器还将每个资源版本存储为序列化的 JSON，并将搜索参数保留在单独的索引表中。Anpheros 的设计遵循相同的原则。
我需要自己构建 FHIR 数据库吗？
只有当您需要完全控制配置文件和资源类型时才需要。否则，托管的 FHIR 平台将为您提供存储、搜索、历史记录、同意和审计功能，而无需运行模式。
相关资源
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card