国境を越えたEHR統合から得た5つの学び
私は数ヶ月を費やして、2つの異なる国にまたがる患者記録の連携に取り組みました。そこで、10年の臨床経験を持つリード・ビジネスアナリスト（BA）と共に働きました。彼女のアプローチは、私のヘルスケア・ソフトウェアに対する見方を変えました。
そのプロジェクトから得た5つの教訓を紹介します。
- 用語のマッピングはデータのマッピングよりも難しい
エンジニアは統合をスキーマの問題として捉えがちです。フィールドAをフィールドBにマッピングして終わり、という考え方です。しかし、ヘルスケアの分野ではこれは通用しません。
あるシステムはICD-10を使用し、もう一方はICD-11を使用していました。これらは単純にマッピングできるものではありません。また、一方のシステムは検査値にLOINCを使用していましたが、もう一方は古い内部コードを使用していました。
私たちのBAは、コードを書く前にコンセプトのクロスウォーク（対応表）を作成しました。彼女はローカルコードをSNOMED CTのような標準セットにマッピングしたのです。これなしでは、臨床的な意味が損なわれていたでしょう。
フィールドのマッピングが不適切だと、誤った値が生成されます。用語のマッピングが不適切だと、「もっともらしいが、臨床的には誤っている値」が生成されます。後者の方がはるかに危険です。
- データ法規制がアーキテクチャを早期に決定づける
私は、まずデータモデルを設計し、コンプライアンスへの対応は後回しにできると考えていました。しかし、それは間違いでした。
国境を越える患者データは、HIPAAやGDPRといった複数の法律に抵触します。国によっては、健康データの国外持ち出しを禁止している場合もあります。
私たちのBAは、早い段階から法務チームと連携しました。彼女は、どのフィールドを複製可能にし、どのフィールドに匿名化が必要かを判断しました。
これにより、アーキテクチャが変わりました。単一の複製データベースを作るのではなく、フェデレーション・クエリ層を構築したのです。また、スキーマにデータ分類タグを直接追加しました。
データモデルを設計する前に、コンプライアンスの専門家とBAを議論の場に招き入れましょう。
- 標準規格だけでは不十分である
両方のシステムがHL7をサポートしていました。しかし、一方はHL7 v2を使用し、もう一方はFHIR R4を使用していました。変換レイヤーがなければ、両者は通信できませんでした。
FHIR内であっても、プロファイルの不一致に直面しました。両方のシステムが準拠していると主張していても、使用している実装ガイドが異なっていたのです。
システムが標準規格をサポートしているからといって、統合が容易だと決めつけてはいけません。常に具体的なバージョンとプロファイルを確認してください。アダプター層の開発のための時間を予算に組み込んでおきましょう。
- ワークフロー図が隠れたエッジケースを捉える
以前の私は、ワークフロー図を単なる「余分なドキュメント」と考えていました。しかし、それは間違いでした。
私たちのBAは、患者の転院を詳細にマッピングしました。治療の途中で患者が移動する場合や、退院後に検査結果が届く場合に何が起こるかを検討したのです。
これらは病院においてはエッジケースではありません。日常的に起こることなのです。
これらの図によって、データモデルが変わりました。両方のシステムにわたって継続的なケアを追跡するために、「ケア・エピソード（care episode）」という概念を追加しました。
- 共通の用語集を早期に作成する
encounterやdischargeといった言葉は、システムによって意味が異なります。チーム間で用語の解釈が異なっていたため、時間を浪費してしまいました。
私たちのBAは共通の用語集を作成しました。すべてのステークホルダーがこれらの定義を確認し、合意しました。私たちはすべての要件において、このドキュメントを参照しました。
すべてのドメイン用語は曖昧であると想定してください。そして、双方の合意を得るために、署名を行うドキュメントで定義しましょう。
まとめ
有能なBAは、単にチケットを書くだけではありません。彼らは規制上の制約や臨床的な意味におけるアーキテクトとして機能します。複雑なソフトウェアを構築する場合、この役割をオーバーヘッドと見なさないでください。そうすることで、技術的な成功が臨床的な失敗に変わるのを防ぐことができるのです。
オプションの学習コミュニティ: https://t.me/GyaanSetuAi