現在、医療記録インフラストラクチャの一部として使用するための FHIR の評価を行っています。EHR データ (アレルギー、訪問、Rx など) については、HL7 FHIR に適切なマッピングがあるようです。
ただし、私たちが扱うデータの多くは個人のフィットネスに関連しています。Fitbit や Apple HealthKit を考えてみてください。
- 積極的な運動(有酸素運動またはワークアウト): 量、エネルギー、心拍数
- 毎日の歩数や水の消費量などの日常的な活動
- 睡眠のパターン/質 (同じ期間内に状態が重なり合う奇妙なケース)
- その他のユーザー提供: 感情評価、食事活動、女性の健康、UV
Observationリソースはありますが、これは EHR ドメインに最適 (!) のようです。特に、ユーザーのフィットネス データは訪問中に収集されず、人間による検証も行われません。
目標は、この種のデータをモデル化するための「標準化された FIHR の方法」を見つけることです。
拡張機能で観測 (?) を使用しますか? プロフィール？ドメイン固有のルール?
FHIR は並外れた柔軟性を可能にしますが、各拡張機能/プロファイルにより、後でリソースを直接交換できるようにするためのコストが増加する可能性があります。
FHIR リソースの適切な使用に関する説明 (いつ拡張するか、プロファイル/タグを使用するか、またはコード化された値を介して差別化をエンコードするかを含む) が役立つでしょう。
新しい/カスタム リソース タイプを定義しますか?
FHIR DSTU2 は、新しいリソース タイプを定義する方法を定義していません。そうしたいということは、リソースの役割 - 論理的な概念と実装のインターフェース? - わかりません。
FHIR をまったく使用しない場合 サマリー インターチェンジ以外では FHIR を使用しないでください。
また、FHIR がメッセージ形式に適していない場合もあります。しかし、外部の相互運用性を扱う場合
FIHRa <-> FIHRbよりも「悪い」ことはありますか?x <-> FIHRc
FHIRレジストリには、ユーザーフィットネス固有の観察プロファイルが含まれていないようであり、提案されたリソースのいずれも、適切なリソースの詳細化を追加していないようです。
結局のところ、最小限の翻訳または翻訳なしで、できると主張できるとよいでしょう。「標準的な方法」で - ユーザーフィットネスデータを FHIR ストリームとして交換できます。