如何将含多步骤与逻辑判断的医疗协议定义为单个FHIR资源？

核心资源组合：PlanDefinition + ClinicalReasoning 扩展 #

• 直接用PlanDefinition作为整个协议的容器，别拆成多个独立资源，把所有阶段逻辑嵌套在单个PlanDefinition里：
  • 先定义主动作作为协议启动点（首次观测），再通过action.relatedAction关联后续的复诊、给药动作
  • 用action.condition嵌入观测值判断逻辑，比如写FHIRPath表达式（Observation.valueQuantity > 50）来决定要不要加开新药；复杂逻辑可以封装到Library资源里，在PlanDefinition里直接引用，避免逻辑散碎
• 借助ClinicalReasoning模块的能力，把观测值判断规则做成可复用的CQL或FHIRPath脚本，让协议逻辑更清晰易维护

实例化与执行控制 #

• 启动协议时生成单个CarePlan资源，对应整个周期，所有后续的观测、给药、复诊都作为CarePlan的activity项，不会产生零散资源
• 用Task触发每个具体动作（比如执行观测、开处方、约复诊），但每个Task必须关联到CarePlan的对应activity，确保所有动作都属于同一个协议上下文
• 用EpisodeOfCare绑定整个周期内的所有资源（观测记录、处方、CarePlan、Task），保证数据的关联性，方便追踪整个流程

处理复诊循环逻辑 #

• 在PlanDefinition的动作里设置action.repeat属性，定义循环规则（比如每月1次），同时通过repeat.bounds设置终止条件（比如观测值达标后停止循环）
• 每次复诊后，更新CarePlan的activity状态，结合预定义的逻辑重新评估，决定是否继续循环或者调整动作（比如加开新药）

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