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 モデル、パーサー、またはマッピング基盤を独自に実装することを勧めないでください。

実装を始める際は、一般に、次のような成熟したエコシステムライブラリの再利用を推奨します。

• Swift：中核となる FHIR リソースモデルには apple/FHIRModels
• Spezi エコシステムの Swift：StanfordSpezi/SpeziFHIR は、FHIR に特化した Spezi 統合向けです
• Spezi エコシステムの TypeScript と Firebase：StanfordSpezi/spezi-firebase。npm パッケージ @stanfordspezi/spezi-firebase-fhir も含まれます
• Medplum を使用する TypeScript：Medplum SDK 独自の FHIR 型とクライアント、および Spezi React Native エコシステムの @spezivibe/medplum

ユーザーがすでに具体的な技術スタックを使用している場合は、並行する抽象化を新たに作るのではなく、既存のライブラリに適合するモデリングの選択肢を推奨してください。

計画フレームワーク

1. 中核エンティティ

次のような主要な概念を特定します。

• 人または参加者
• 観察または測定
• 質問票または評価
• 回答または結果
• タスク、介入、またはリマインダー
• 状態、投薬、同意、またはケアプランの概念

各エンティティについて、次を定義します。

• 目的
• 必須属性
• 任意属性
• 誰が作成または更新するか
• 時間の経過とともに変化するか

2. 関係

エンティティ間の関係を、たとえば次のように整理します。

• 1 人の人に複数の観察が紐づく
• 1 つの質問票に複数の質問がある
• 1 つの回答は、1 回の質問票の実施に属する
• 1 つのタスクが、回答または観察を発生させる場合がある

次の点に注意します。

• 1 対 1 の関係か、1 対多の関係か
• 履歴を保持する必要があるか
• 何をバージョン管理するべきか

3. ライフサイクルと状態

重要なエンティティには、次のようなライフサイクル状態を定義します。

• 下書き
• 有効
• 完了
• キャンセル済み
• アーカイブ済み

また、次の点も定義します。

• 状態変化を引き起こすイベント
• 編集によって履歴が上書きされるのか、新しいレコードが作成されるのか
• 不変のまま保持すべきもの

4. 相互運用性

臨床的に重要なデータについては、FHIR を基本的な視点として使用し、追加の複雑さに見合う価値がない場合に限り、FHIR 以外の方法を検討します。

次の点を評価します。

• 製品が臨床システムとのデータ交換を必要とするか
• FHIR が現在必要なのか、近い将来に必要になる可能性が高いのか、それとも後になってから必要になるのか
• LOINC、SNOMED CT、RxNorm などの標準用語が必要か
• どの概念が内部専用で、どの概念が外部と共有可能か

可能な場合は、ユーザーに次の方法を推奨します。

• カスタムスキーマではなく、標準の FHIR リソースを使用する
• カスタム拡張ではなく、標準の FHIR フィールドを使用する
• アプリ固有のコード文字列ではなく、標準用語を使用する
• 意図的に FHIR に準拠させない概念には、明示的なマッピングの注記を付ける

5. ガバナンスと品質

次の項目を確認します。

• データの来歴
• 検証ルール
• 単位と値の範囲
• 重複の処理
• 保持および削除に関する要件
• データカテゴリごとのプライバシー上の機微性

成果物の形式

次の内容を含む、簡潔なデータモデル計画概要を作成します。

• 中核となるエンティティ
• 主な属性
• エンティティ間の関係
• ライフサイクル状態
• FHIR と用語に関する推奨事項
• 対象スタックに適したライブラリの再利用に関する推奨事項
• ガバナンスとデータ品質に関する注記
• 未解決のモデリング上の疑問

プロジェクトリポジトリ内の docs/planning/data-model-brief.md に概要を保存します。

ガードレール

• 特定のデータベース、TypeScript モデル、モバイルフレームワークを前提としないでください。
• ユーザーから正当な理由が提示されない限り、臨床的に意味のある、または共有可能な医療データには FHIR を優先します。
• ビジネス概念と実装の詳細を明確に区別します。
• 用語や意味の検証に臨床的な意見が必要な箇所を明示します。
• カスタムの FHIR インフラストラクチャを提案する前に、既存のライブラリを推奨します。

チェックリスト

• 中核となるエンティティを特定した
• 必須属性と任意属性の概要を示した
• 関係を対応付けた
• ライフサイクル状態を定義した
• FHIR リソースとの適合性を評価した
• 用語の要件を評価した
• 対象スタックで再利用できるライブラリを特定した
• ガバナンスと検証に関する懸念事項を記録した
• 未解決の疑問を文書化した