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 R4
首个功能实现时间	小时	一到两天学习资源
契合您的产品	精确	通用；您的产品视图叠加其上
添加新类型数据	每种类型一次迁移	通常是现有资源中的新代码
系统外含义	无映射则无意义	共享代码 (LOINC, ICD-10, ATC, UCUM)
历史和更正	您设计	版本和 `_history` 按设计
谁编写了什么	您设计	`Provenance` (Anpheros 中自动)
与诊所、实验室、其他应用交换	每次自定义集成	FHIR R4 API, HL7 v2 导入, International Patient Summary
每个应用的患者同意	您设计	SMART on FHIR 范围和 OAuth
查询分析	纯 SQL	FHIR 搜索，或导出到您的仓库
法规 (GDPR Article 9, EHDS)	您记录每个部分	法规引用的标准格式

何时应使用自定义模式

数据并非真正医疗相关，或不涉及个人。 训练计划、内容、产品目录：请使用您自己的表。
短暂的原型，用于测试产品是否有人需要，使用合成数据，并计划迁移。
数据难以用标准模型很好地表示，例如新颖的研究测量。FHIR 仍可承载它（通过您自己的代码系统 Observation，或 Basic），但自定义表可能更清晰。
重度分析。 即使 FHIR 是记录系统，大多数团队也会将数据复制到数据仓库中，并以自己的格式进行报告。

何时选择 FHIR

数据是个人健康记录：测量值、诊断、药物、过敏史、实验室结果、文档。
数据将离开您的系统：发送给患者、医生、诊所、实验室、保险公司、AI 模型，或在患者迁移时发送给竞争对手。
您需要展示谁创建了什么以及发生了什么更改：审计、临床安全、争议。
患者将授予和撤销每个应用程序的访问权限。
您在欧盟销售，欧洲健康数据空间 (EHDS) 要求记录以标准格式进行交换。

通常的中间路径

大多数产品最终都会兼顾两者，按数据种类进行划分：

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

您的数据库保持精简且符合产品形态。病历是标准的、版本化的且可共享的，您无需自行构建。 Medical app backend and database 详细描述了这种划分，而 How to build a healthcare API with TypeScript 则实现了它。

构建 FHIR 本身的考量

选择 FHIR 并不意味着需要从头编写 FHIR 服务器。您的选择包括：运行一个开源服务器、使用云提供商的 FHIR 存储、部署一个开源医疗保健平台，或者使用像 Anpheros 这样的托管医疗保健数据库。它们在处理同意、审计、溯源、数据驻留和集成方面有所不同，具体请参阅 Anpheros 与其他 FHIR 服务器的对比。

常见问题解答

FHIR 是数据库吗？

不是。FHIR 是用于健康数据结构和交换的标准：资源、代码和 REST API。FHIR 服务器或托管的 FHIR 数据库存储资源，并在真实数据库之上实现 API。

我可以自己将 FHIR 资源存储在 PostgreSQL 中吗？

可以，作为 JSON 列，并带有您自己的索引，一些开源服务器正是这样做的。工作在于存储相关的其他所有内容：搜索参数、版本控制、引用、验证、每个患者的访问控制和来源。

我可以先使用自定义模式，以后再迁移到 FHIR 吗？

可以，许多团队也是这样做的，但迁移是一个映射项目：每个表都需要它从未记录过的代码、单位和作者。从第一个功能开始就将医疗数据存储为 FHIR，比以后进行转换成本更低。

我需要 FHIR 来符合 GDPR 吗？

不需要。GDPR 不要求特定的格式。FHIR 使满足几项义务变得更容易：可移植性（记录以标准格式导出）、按目的的访问控制，以及显示谁处理了哪些数据。