📚 课程目录第4章康复训练方案的数据模型

4. 康复训练方案的数据模型

康复训练方案不是一张“动作清单”，而是一套随时间演进、可追溯、可复用的结构化数据。要让系统能自动生成方案、跟踪执行、动态调整，就必须先把方案拆成若干稳定的实体，并定义它们之间的引用关系。本节围绕六个核心实体展开：患者画像、功能诊断、训练目标、动作库、参数集、进度记录。理解它们的字段含义与连接方式，是后续做方案生成、版本管理和效果评估的基础。

一、六个实体的职责与关键字段

患者画像（PatientProfile）描述“这个人是谁、身体条件如何”。它不是病历的复制，而是训练决策所需的稳定属性集合，典型字段包括：患者ID、年龄、性别、身高体重、损伤类型（如脑卒中偏瘫、ACL术后）、患侧（左/右）、合并症、禁忌症、当前负重限制、认知与配合度等级。其中“负重限制”和“禁忌症”是硬约束，会直接过滤动作库中的候选动作。

功能诊断（FunctionalDiagnosis）描述“当前功能缺什么”。它通常来自量表与测量，例如Brunnstrom分期、Fugl-Meyer上肢评分、Berg平衡量表、关节活动度（ROM）、徒手肌力（MMT）、疼痛VAS。每条诊断应带时间戳，因为功能是变化的。诊断结果决定训练目标的起点，也决定参数集的初始强度。

训练目标（TrainingGoal）描述“要练成什么样”。目标必须可测量，建议采用“指标+基线+目标值+期限”的结构，例如：{指标: 患侧肩关节前屈主动ROM, 基线: 45°, 目标值: 90°, 期限: 4周}。目标可分层：长期目标（出院/回归生活）、短期目标（2周）、单次训练目标。目标与诊断之间是“依据”关系，与动作之间是“被支撑”关系。

动作库（ExerciseLibrary）是标准化动作的集合，每个动作是一条可复用记录，字段包括：动作ID、名称、类别（肌力/关节活动/平衡/步态/协调）、目标肌群或功能、所需器械、起始体位、执行描述、禁忌标签、难度等级、计量单位（次/组/秒/米）。动作库是“字典”，方案中的动作应引用动作ID而非自由文本，否则无法统计和替换。

参数集（ParameterSet）描述“这个动作这次怎么做”。同一动作在不同患者、不同阶段参数不同，典型参数：组数、每组次数、阻力（kg或弹力带等级）、动作幅度、节奏（如3秒向心/3秒离心）、组间休息、总时长、辅助等级、疼痛上限（如VAS≤3）。参数集是方案中最需要版本化的部分，因为调整往往发生在参数层。

进度记录（ProgressRecord）描述“实际做了什么、结果如何”。字段包括：记录ID、方案版本号、日期、实际完成组次、实际阻力、完成率、疼痛评分、疲劳评分（RPE）、异常事件（如头晕、跌倒）、治疗师备注。进度记录是闭环的反馈端，它回写后触发目标达成判断与参数调整。

二、实体关系：从画像到进度记录的引用链

六个实体不是并列的，而是一条带约束的引用链：患者画像提供约束条件 → 功能诊断给出缺口 → 训练目标定义方向 → 动作库提供候选动作 → 参数集把动作实例化为可执行处方 → 进度记录回写实际结果。下图展示了这一关系结构，其中实线表示“引用/依据”，虚线表示“反馈/调整”。

三、版本管理：为什么必须做，怎么做

康复方案几乎每周都会调整：疼痛升高要降阻力，ROM改善要加幅度，目标达成要换动作。如果每次调整都覆盖原记录，就会丢失“当时为什么这样练”的依据，也无法判断效果来自哪一版。因此方案必须版本化。

推荐采用“主版本+次版本”的语义：主版本（v1.0→v2.0）表示目标或动作集合发生结构性变化，例如从“被动关节活动”转为“主动抗阻”；次版本（v1.0→v1.1）表示仅参数调整，例如阻力从1kg改为1.5kg、组数从2组改为3组。每次变更记录四个要素：变更时间、变更人、变更字段、变更原因。进度记录必须绑定它执行时对应的方案版本号，这样后续统计“完成率”和“目标达成率”时才不会把不同强度的训练混在一起。

版本号建议由系统自动生成，禁止手工填写；变更原因用受控词表（如“疼痛超限”“目标达成”“患者疲劳”“器械不可用”），便于后期做归因分析。

四、一个可落地的方案数据结构示例

下面给出一个简化的JSON结构，展示六个实体如何通过ID互相引用。示例为教学假设数据，非真实患者记录。

{
  "planId": "PLAN-2024-0312-007",
  "version": "v1.1",
  "patientProfileId": "PAT-1024",
  "diagnosisId": "DX-20240310-01",
  "goals": [
    {
      "goalId": "G-01",
      "metric": "患侧肩前屈主动ROM",
      "baseline": 45,
      "target": 90,
      "unit": "deg",
      "deadline": "2024-04-07"
    }
  ],
  "prescriptions": [
    {
      "exerciseId": "EX-0217",
      "exerciseName": "坐位弹力带肩前屈",
      "parameterSetId": "PS-0217-A",
      "params": {
        "sets": 3,
        "reps": 10,
        "resistance": "黄色弹力带",
        "tempo": "3s向心/3s离心",
        "restSec": 60,
        "painLimitVAS": 3
      }
    }
  ],
  "changeLog": [
    {
      "version": "v1.1",
      "time": "2024-03-19T10:20:00",
      "field": "params.resistance",
      "from": "红色弹力带",
      "to": "黄色弹力带",
      "reason": "疼痛超限"
    }
  ]
}

对应的进度记录则写成：

{
  "recordId": "PR-20240319-007",
  "planId": "PLAN-2024-0312-007",
  "planVersion": "v1.1",
  "date": "2024-03-19",
  "exerciseId": "EX-0217",
  "completedSets": 3,
  "completedReps": 28,
  "completionRate": 0.93,
  "painVAS": 2,
  "rpe": 12,
  "adverseEvent": null,
  "note": "末组速度下降，下次维持当前阻力"
}

五、建模时的三个关键判断

第一，动作库与参数集必须分离。如果把“3组×10次”写死在动作库里，动作就无法复用于不同患者。动作库只描述“怎么做这个动作”，参数集描述“这次做多少”。

第二，诊断与目标之间要有明确的映射规则。例如Fugl-Meyer上肢评分低于30分时，目标优先设为“辅助下完成关节活动”，而非“独立抗阻”。这条规则可以写成配置，让系统自动推荐目标层级。

第三，进度记录要能反向触发版本升级。当连续两次记录显示疼痛VAS≥4，或完成率低于70%，系统应提示治疗师评估是否降级参数，并生成新的次版本。这样版本管理就不是事后补录，而是嵌入训练闭环的自动动作。

禁忌症与负重限制属于硬约束，任何版本调整都不得绕过。若动作库中的动作与患者画像的禁忌标签冲突，系统应在方案生成阶段直接拦截，而不是等到执行时才发现。

把六个实体、引用链和版本规则定义清楚之后，后续的自动方案生成、执行监控和效果分析才有稳定的数据基础。下一阶段的工作，就是把这些结构落到具体的数据库表或对象模型中，并设计好版本对比与回滚的操作界面。