<!--
This source file is part of the Stanford Spezi open-source project.
SPDX-FileCopyrightText: 2026 Stanford University and the project authors (see CONTRIBUTORS.md)
SPDX-License-Identifier: MIT
-->
<!--
此源文件是斯坦福Spezi开源项目的一部分。
SPDX-FileCopyrightText: 2026 斯坦福大学及项目作者（详见CONTRIBUTORS.md）
SPDX-License-Identifier: MIT
-->
Health Data Model Planner
健康数据模型规划指南
Plan a health data model with a strong bias toward FHIR before committing to storage, code structures, or client-specific architecture.
在确定存储方案、代码结构或特定客户端架构之前，优先基于FHIR规划健康数据模型。
When to Use
适用场景
Use this skill when you need to:
define the core health concepts a product needs to represent
decide which entities, relationships, and lifecycle states matter
reason about interoperability requirements with FHIR as the default starting point for clinical data
prepare for later implementation in a mobile app, backend, analytics pipeline, or research workflow
当你需要完成以下工作时，可使用本指南：
定义产品需要表示的核心健康概念
确定关键的实体、关系和生命周期状态
以FHIR为默认起点，分析临床数据的互操作性需求
为后续在移动应用、后端系统、分析管道或研究工作流中的实施做准备
Working Style
工作原则
Start with the domain, but assume that clinically meaningful data will often benefit from a FHIR-oriented design unless there is a strong reason not to.
Clarify:
what the product is trying to track or coordinate
who creates, reads, updates, or interprets the data
what must be longitudinal, auditable, shareable, or clinically meaningful
what needs to be structured versus free-form
which standards, institutions, or downstream systems matter
从业务领域出发，但除非有充分理由，否则临床相关数据应优先采用面向FHIR的设计。
需明确以下内容：
产品需要追踪或协调的对象
数据的创建、读取、更新或解读人员
哪些数据需要具备纵向性、可审计性、可共享性或临床意义
哪些数据需要结构化，哪些可以采用自由格式
相关的标准、机构或下游系统
Default Bias Toward FHIR
默认优先采用FHIR
In digital health, prefer asking "How would this map to FHIR?" early rather than treating interoperability as a late-stage add-on.
Default questions:
should this concept become a FHIR resource instead of a custom object
is there an existing FHIR pattern for this workflow
should values use established terminologies such as LOINC, SNOMED CT, or RxNorm
will this data eventually need to move between apps, research systems, backend services, or EHR-adjacent systems
It is fine to decide that some concepts remain app-internal, but make that an explicit choice.
在数字健康领域，应尽早思考“如何将此映射到FHIR？”，而非将互操作性视为后期附加功能。
默认思考问题：
该概念是否应作为FHIR资源，而非自定义对象
针对此工作流是否已有现成的FHIR模式
是否应使用LOINC、SNOMED CT或RxNorm等已确立的术语集
这些数据最终是否需要在应用、研究系统、后端服务或电子健康记录（EHR）相关系统之间流转
部分概念可保留为应用内部使用，但需做出明确选择。
Reuse Before Building
优先复用而非自建
Do not encourage teams to hand-roll FHIR models, parsers, or mapping infrastructure unless there is a compelling gap.
When implementation starts, generally recommend reusing mature ecosystem libraries, for example:
If the user is already working in a concrete stack, recommend modeling choices that fit those existing libraries instead of inventing parallel abstractions.