关于FHIR Appointment资源新增15个额外数据元素的方案咨询

首选方案：用Extensions扩展 #

完全可以用Extensions来添加这些非标准字段，这本来就是FHIR用来支持自定义数据的官方方案，适配性很强。

关于15个元素是否要各自建独立Extension？ #

分两种场景选择：

• 如果这15个元素是各自独立的单一数据项（比如患者紧急联系人电话、预约特殊饮食需求、第三方支付单号这类互不相关的字段），建议每个元素单独做一个Extension。好处是每个Extension职责单一，以后其他资源要用到其中某一个字段时直接复用就行；而且FHIR校验工具能精准校验，不同系统对接时也更容易理解每个字段的含义。
• 如果这15个元素是一套关联紧密的业务数据（比如同属企业客户预约的附加信息：企业ID、项目编号、服务等级这类绑定在一起的字段），可以做一个容器式Extension，把这组元素都放在这个容器Extension下面。这样能保持业务逻辑的整体性，不会出现一堆零散的Extension，看起来更规整。

其他备选方案 #

• 塞进note字段：如果这些额外数据都是无结构的文本，临时用用可以，但15个结构化元素这么搞的话，后续解析会非常麻烦，不推荐。
• 关联自定义资源：如果这些数据特别复杂，还有独立的业务生命周期（比如需要单独更新、查询），可以自己定义一个FHIR资源（比如叫AppointmentExtraInfo），然后通过Appointment的标识符或者Extension关联这个资源。但这种方式复杂度高，需要额外维护资源定义，一般15个元素用Extension就足够了，没必要搞这么复杂。

实操建议 #

1. 先把15个元素的业务关系理清楚，再决定是拆分还是用容器Extension
2. 每个Extension要设置唯一的URL（比如http://your-org-domain/fhir/StructureDefinition/appointment-emergency-contact），避免和其他组织的Extension冲突
3. 一定要写Extension的结构定义（StructureDefinition），明确每个字段的数据类型、是否必填、约束规则，这样系统能自动校验，对接起来也更顺畅
4. 如果用容器Extension，要在结构定义里把子元素的规则都写清楚，别让对接方猜结构

内容的提问来源于stack exchange，提问作者Rachel