【发布时间】：2016-03-06 02:18:44
【问题描述】：
我们目前正在评估将 FHIR 用作我们医疗记录基础设施的一部分。对于 EHR 数据（过敏、访问、Rx 等），HL7 FHIR 似乎具有适当的映射。
但是，我们处理的很多数据与个人健身有关 - 想想 Fitbit 或 Apple HealthKit：
- 积极运动（有氧或锻炼）：数量、能量、心率
- 日常活动，例如每日步数或用水量
- 睡眠模式/质量（在同一时间跨度内出现重叠状态的奇怪情况）
- 其他用户提供：情绪评分、饮食活动、女性健康、紫外线
虽然有 Observation resource，但这似乎仍然最适合 EHR 域 (!)。特别是，用户健身数据没有在访问期间收集，并且没有人工验证。
我们的目标是找到一种“标准化的 FIHR 方法”来对此类数据进行建模。
-
使用带有扩展的观察 (?)？简介？特定领域的规则？
FHIR 具有非凡的灵活性，但每个扩展程序/配置文件可能会增加以后能够直接交换资源的成本。
关于 FHIR 资源的适当使用的解释 - 包括何时扩展、使用配置文件/标签或通过编码值编码差异 - 会很有用。
-
定义一个新的/自定义的资源类型？
FHIR DSTU2 没有定义定义新资源类型的方法。想要这样做可能表明资源的作用 - 逻辑概念与实现接口？ - 不明白。
-
根本不使用 FHIR？不使用 FHIR，除非在摘要交换中？
也可能是 FHIR 不适合我们的消息格式。但是在处理外部互操作性时，使用
FIHRa <-> FIHRb会比使用x <-> FIHRc更“糟糕”吗？
FHIR Registry 似乎不包含任何特定于用户健身的观察配置文件，Proposed Resources 似乎都没有添加适当的资源优化。
归根结底，如果能够声称能够做到这一点，那就太好了——只需很少或没有翻译，即。以“标准方式” - 能够将用户健身数据作为 FHIR 流进行交换。
【问题讨论】：
-
观察文档中是否有某些内容让您相信它需要在访问期间收集或人工验证？如果您提交更改请求以明确包含其中一些活动以及规范中的示例，以更明显地表明这是观察的预期用途，这也可能会有所帮助。
-
@LloydMcKenzie 我不相信对观察的更改（或添加新资源）符合FHIR ethos - 以一种或另一种方式寻找一个好的答案。观察有一个Observation Status，其中“最终”似乎要求人工批准。此外，the specification 没有提供示例来表明一般健身数据是主要用例；这些例子是临床性质的。
-
我已经提出跟踪器gforge.hl7.org/gf/project/fhir/tracker/… 来解决状态问题。将有各种不涉及人工审查的观察。我鼓励你提出一个跟踪器，在这个领域提出更多的例子。
标签： hl7-fhir dstu2-fhir