FHIR运行时生成自定义资源的实现方案咨询

存在完全可行的实现路径，不需要每次新增数据模型都走硬编码继承DomainResource、编译部署的流程，完全可以满足FHIR数据与非FHIR数据统一存储、不拆分独立存储的需求。

具体实现流程 #

• 首先编写符合FHIR规范的自定义资源StructureDefinition，必须满足以下核心约束，否则服务端不会将其识别为独立资源类型：
  • kind 字段固定赋值为 resource，不能设置为logical（逻辑模型）或complex-type（数据类型）
  • derivation 字段固定赋值为 specialization，标记该定义是从上层资源特化出的全新资源类型，注意不要写成constraint——这个值是给现有资源做Profile约束用的，不会生成独立资源类型
  • baseDefinition 字段指向官方FHIR标准中DomainResource的规范地址
  • type 字段填写自定义资源的类型名称，建议统一加项目专属前缀（比如PrjCustomerInfo），避免和后续官方发布的新资源、其他项目的自定义资源重名
  • 按业务需求在snapshot节点中完整定义自定义资源的所有字段结构、绑定规则、校验要求
• 直接向FHIR服务端的StructureDefinition接口提交定义，调用方式和创建普通FHIR资源完全一致：

  POST [你的FHIR服务根地址]/StructureDefinition
  Content-Type: application/fhir+json
  // 请求体为上述编写完成的StructureDefinition内容
  

• 提前在FHIR服务端开启动态自定义资源支持：目前主流的开源/商用FHIR服务器（HAPI FHIR、Firely Server等）都原生支持该能力，只需要修改服务端配置项，打开“运行时加载StructureDefinition注册为自定义资源”的开关即可，不需要额外二次开发。注册完成后，你就可以像操作Patient、Observation等官方标准资源一样，对自定义资源执行增删改查、搜索等所有标准FHIR操作，数据和官方FHIR数据落在同一个持久化存储中，完全不需要拆分部署独立存储。

方案注意事项 #

• 运行时注册的自定义资源不属于FHIR官方正式发布的标准内容，如果需要跨系统交互数据，需要交互的对端系统也注册同一份StructureDefinition，否则对端无法识别该资源类型。
• 该方案和硬编码继承DomainResource的方案不冲突：如果后续某个自定义资源需要叠加复杂的业务逻辑、定制化校验规则，你随时可以补充对应硬编码的资源类，替换运行时注册的定义，已存储的历史数据不需要做任何迁移。
• 不要滥用自定义资源：如果待接入的非FHIR数据可以通过对现有官方FHIR资源加扩展、做Profile的方式承载，优先选择Profile方案，只有完全不在现有官方资源覆盖范围内的数据模型，再使用自定义资源方式接入。

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