mcpField
H
health-data-model-planning

health-data-model-planning

github.com/stanfordspezi数据与数据库26114 次安装5 周前更新
代码仓库

关于 health-data-model-planning

health-data-model-planning 是一项在选择存储或实现结构前规划健康数据概念的技能，面向产品与工程团队。它默认以 FHIR 为临床数据设计视角，并涵盖实体、关系、生命周期、互操作性与治理。

主要功能

  1. 01确定核心健康实体与属性
  2. 02梳理关系和生命周期状态
  3. 03评估 FHIR 资源适配性
  4. 04审视术语与互操作需求
  5. 05记录治理和数据质量问题
  6. 06生成规划简报

适用场景

  1. 01规划数字健康产品的数据概念
  2. 02选择应用数据结构前评估 FHIR
  3. 03为目标技术栈整理健康数据建模问题

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/stanfordspezi/spezivibe --skill health-data-model-planning

安装后在 Claude Code 中输入/health-data-model-planning确认已加载。

详细介绍

健康数据模型规划器

在确定代码结构或客户端特定架构之前，先规划健康数据模型，并强烈倾向于 FHIR。

何时使用

在以下情况下使用本技能：

  • 定义产品需要表示的核心健康概念
  • 决定哪些实体、关系及生命周期状态至关重要
  • 以 FHIR 作为临床数据的默认起点，思考互操作性需求
  • 为后续在移动应用、后端、分析管道或研究工作流中的实现做准备

与 fhir-data-model-design 的关系： 本技能规划概念——实体、关系、生命周期状态以及 FHIR 是否适用。当应用需要具体的 FHIR R4 规范（特定资源、配置文件和术语绑定）时，随后运行 fhir-data-model-design；其输出将取代本简要中的初步 FHIR 建议。

工作风格

从领域出发，但假设具有临床意义的数据通常受益于面向 FHIR 的设计，除非有充分理由不这样做。

厘清：

  1. 产品试图跟踪或协调什么
  2. 谁创建、读取、更新或解读数据
  3. 哪些内容必须具有纵向性、可审计性、可共享性或临床意义
  4. 哪些需要结构化，哪些需要自由形式
  5. 哪些标准、机构或下游系统至关重要

默认偏向 FHIR

在数字健康领域，宁可尽早问"这如何映射到 FHIR？"，而不是把互操作性当作后期附加项。

默认问题：

  • 这个概念是否应成为 FHIR 资源，而不是自定义对象
  • 此工作流是否已有现成的 FHIR 模式
  • 值是否应使用 LOINC、SNOMED CT 或 RxNorm 等既定术语
  • 这些数据最终是否需要在应用、研究系统、后端服务或 EHR 相邻系统之间迁移

决定某些概念保留在应用内部是可以的，但要将其作为明确选择。

先复用，再构建

除非存在明显空白，否则不要鼓励团队手工编写 FHIR 模型、解析器或映射基础设施。

当实现开始时，通常建议复用成熟的生态库，例如：

如果用户已经在具体技术栈中工作，建议选择适合这些现有库的建模方案，而不是发明并行抽象。

规划框架

1. 核心实体

识别主要概念，例如：

  • 人员或参与者
  • 观察或测量
  • 问卷或评估
  • 回答或结果
  • 任务、干预或提醒
  • 状况、药物、同意或护理计划概念

对每个实体，定义：

  • 目的
  • 必需属性
  • 可选属性
  • 谁创建或更新它
  • 它是否随时间变化
2. 关系

映射实体之间的关系，例如：

  • 一个人有多个观察
  • 一份问卷有多个问题
  • 一份回答属于一个问卷实例
  • 一个任务可以触发一个回答或观察

注意：

  • 一对一与一对多关系
  • 是否必须保留历史
  • 哪些应进行版本管理
3. 生命周期与状态

对于重要实体，定义生命周期状态，例如：

  • 草稿
  • 活跃
  • 已完成
  • 已取消
  • 已归档

同时定义：

  • 哪些事件会导致状态变化
  • 编辑是覆盖历史还是创建新记录
  • 哪些内容应保持不可变
4. 互操作性

将 FHIR 作为临床相关数据的默认视角，只有当额外复杂性不合理时才偏离它。

评估：

  • 产品是否需要与临床系统交换数据
  • FHIR 是现在就需要、可能很快需要，还是只在以后需要
  • 是否需要标准术语集，例如 LOINC、SNOMED CT 或 RxNorm
  • 哪些概念仅供内部使用，哪些可对外共享

在可能的情况下，推动用户采用：

  • 标准 FHIR 资源，而不是自定义模式
  • 标准 FHIR 字段，而不是自定义扩展
  • 标准术语集，而不是应用特定的代码字符串
  • 对任何有意非 FHIR 的概念提供明确的映射说明
5. 治理与质量

审查：

  • 数据来源
  • 校验规则
  • 单位和值范围
  • 重复处理
  • 保留和删除预期
  • 每个数据类别的隐私敏感性

交付格式

生成一份简明的数据模型规划简报，包含：

  • 核心实体
  • 关键属性
  • 实体关系
  • 生命周期状态
  • FHIR 和术语集建议
  • 针对目标技术栈的库复用建议
  • 治理和数据质量说明
  • 未解决的建模问题

将简报保存到项目仓库中的 docs/planning/data-model-brief.md。

护栏

  • 不要假设特定的数据库、TypeScript 模型或移动框架。
  • 除非用户给出充分理由不这样做，否则对具有临床意义或可共享的健康数据优先采用 FHIR。
  • 清楚区分业务概念和实现细节。
  • 标记需要临床输入来验证术语或含义的地方。
  • 在建议自定义 FHIR 基础设施之前，先推荐现有库。

检查清单

  • 已识别核心实体
  • 已概述必填和可选属性
  • 已映射关系
  • 已定义生命周期状态
  • 已评估 FHIR 资源适配性
  • 已评估术语集需求
  • 已为目标技术栈识别可复用库
  • 已记录治理和校验方面的关注点
  • 已记录未解决的问题

评论

支持 Markdown