用途：在确定存储、代码结构或客户端架构之前，先规划健康数据模型，默认以FHIR为起点，避免把互操作性当作后期附加项。
主要能力：识别核心实体（人/参与者、观察或测量、问卷或评估、回答或结果、任务/干预/提醒、状况、用药、同意、照护计划等），为每个实体定义用途、必填与可选属性、创建更新者和随时间变化情况；映射实体关系（如一对多、是否保留历史、哪些需版本化）；定义生命周期状态（draft、active、completed、cancelled、archived）及触发状态变更的事件、是否覆盖历史、哪些保持不可变；评估互操作性，判断是否需要与临床系统交换数据、FHIR是现在还是以后需要、是否需要LOINC、SNOMED CT、RxNorm等术语，区分仅内部使用与可对外共享的概念；给出治理与质量要点，包括数据来源、验证规则、单位与取值范围、重复处理、保留与删除、隐私敏感度。
使用方式：围绕领域澄清产品要跟踪或协调什么、谁创建读取更新或解释数据、哪些必须纵向可审计可共享或具临床意义、哪些需结构化或自由形式、涉及哪些标准与下游系统。产出简洁的规划简报，包含上述内容及未解决的建模问题，保存为docs/planning/data-model-brief.md。
与fhir-data-model-design的关系：本技能只规划概念与FHIR是否适用；当需要具体FHIR R4规范（资源、profile、术语绑定）时，之后运行fhir-data-model-design，其输出取代本简报的初步FHIR建议。
库复用建议：优先复用成熟生态库，而非自建FHIR模型或解析器。例如Swift的apple/FHIRModels、Spezi生态的StanfordSpezi/SpeziFHIR；TypeScript与Firebase的StanfordSpezi/spezi-firebase（含npm包@stanfordspezi/spezi-firebase-fhir）；TypeScript与Medplum的Medplum SDK及Spezi React Native生态的@spezivibe/medplum。若已有具体技术栈，应让建模选择适配这些现有库。
限制：不假定特定数据库、TypeScript模型或移动框架；临床含义或术语需临床输入验证；部分概念可保留为应用内部，但需明确选择。