バイオ/医療データの相互運用性とプライバシーエンジニアリング技術(前編)

米国のバイオ/医療領域では、クラウドサービスの利用が拡大するとともに、様々な機器やシステムから集約されるデータの利活用やリスク管理における前提条件として、相互運用性の標準化動向に注目が集まっている。

CSAが医療データの相互運用性に関するレポートを公開

クラウドセキュリティアライアンス(CSA)のヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)は、2022年9月26日に「医療の相互運用性」(https://cloudsecurityalliance.org/artifacts/healthcare-interoperability/)を公開している。「相互運用性(Interoperability)」という言葉は、医療ITシステムが相互に継ぎ目なくデータを交換する場合に参照される。受け取った電子健康記録(EHR)が読み取り可能で受け入れられることを認識したところで、標準化されたフォーマットを利用して情報を移転させる時、相互運用性が発生する。本文書では、共有するデータが、受け取る側の医療機関にとって、正確にデータを表現するコンテンツとコンテキストについての十分な評価を有することを目標としている。このようなデータは、正確な患者ケアだけでなく患者安全にとっても、非常に有益である。

「医療の相互運用性」は、以下のような構成になっている。

  • 謝辞
  • 要約
  • イントロダクション
  • 相互運用性
  • 相互運用性の現状
  • クラウドにおける相互運用性
  • 今後の進め方
  • 結論
  • 参考文献

CSA-HIM WGは、相互運用性について。「情報を交換し、交換した情報を利用するための2つ以上のシステムまたはコンポーネントの能力」と定義している。言い換えると、相互運用性は、異なるタイプの情報通信技術(ICT)システムが、読み取り可能で使えるフォーマットで、データを正確に、効率的に、一貫して交換する能力である。この文書では、相互運用性について、以下の4つのレベルを提示している。

  1. 基礎的(レベル1):システムまたはアプリケーションが、安全にデータを伝達し、他からのデータを受け取るための相互接続性を定義する
  2. 構造的(レベル2):解釈のためのデータフィールドのレベルなど、データ交換のフォーマット、構文、組織を定義する
  3. 意味的(レベル3):公に入手可能な値設定やコーディングの語彙からの標準化された定義を持つデータ要素の利用など、共通の基本的モデルやデータの成文化のために提供し、理解の共有やユーザーに対する意味を提供する
  4. 組織的(レベル4):組織や主体、個人の内部や相互間の、安全で、継ぎ目のない、タイムリーなデータ通信を促進するためのガバナンスやポリシー、社会的、法的、組織的な考慮事項を含む

電話に匹敵するようなレベルの総合運用性が医療に適用できれば、誰が機器やシステムを作ったか、どこに設置されているかに関わらず、医療機関がやりとりできる機能を持つことができる。加えて、医療機器からのデータを直接EHRにとりこむことができれば、患者のアウトカムや患者安全に様々なベネフィットを提供することができる。

「医療の相互運用性」では、EHRのユースケースとして、以下のような事例を挙げている。

  • 医療機関は、異なるEHRを利用する可能性がある他の医療機関に記録を送付する機能が必要である。データの構造と完全性を維持しながら、この種の転送を遂行しなければならない。
  • 外部ソースからのEHRコピーの要求と、オリジナルの詳細を保持するような標準的なフォーマットによる記録の返却。
  • 標準的なフォーマットによるHIEへの情報提供により、医療機関が他の医療機関からの患者記録の閲覧を可能にする。これには、患者の病歴を有する医療機関が含まれ、アウトカムの改善における重要な要因となる。

米国政府による医療データの相互運用性標準化推進策

なお、米国保健福祉省(HHS)は、病院の医療情報へのアクセス向上を通じで患者に権限を付与するとともに患者の電子健康記録へのアクセスを改善し、供給者が簡単に患者との時間を費やせるようにすることを目的とした「相互運用性の促進(Promoting Interoperability)」ルールの標準化を推進している。

その一環としてHHSは、2020年3月9日、「国家医療IT調整室(ONC)21世紀治療法最終規則(ONC規則)」 (https://www.hhs.gov/about/news/2020/03/09/hhs-finalizes-historic-rules-to-provide-patients-more-control-of-their-health-data.html)と「メディケア・メディケイド・サービス・センター(CMS)相互運用性および患者アクセス最終規則(CMS規則)」 (https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index)を公表している。ONC規則では、国際HL7協会が策定した電子保健医療情報の相互運用性に関わる標準規格であるHL7 FHIR(Fast Healthcare Interoperability Resources)4.0.1版を採用し、認証電子健康記録技術プログラムの一部であるアプリケーション・プログラミング・インタフェース(API)の利用を支援することによって、患者が、スマートフォンを利用しながら、医師のEHRから、重要な医療情報にアクセスすることを可能にするとしている。また、CMS規則では、規制対象となるすべての保険者が、患者アクセスAPI経由で請求・照合データの患者による利用(PHR)を可能にすることによって、患者が必要な時に必要な方法でPHRを利用しながら、医療におけるよりよい意思決定者や知識に基づくパートナーとなることを促進するとしている。一般のデジタルヘルススタートアップ企業でも、HL7 FHIR ベースで電子医療記録(EMR:Electric Medical Record)やEHRとデータ連携すれば、経済インセンティブの恩恵を受けられることから、相互運用性標準化の加速要因となっている。

このような動きと並行して、ONCは、2020年10月30日、「2020-2025年連邦医療IT戦略計画」(https://www.healthit.gov/topic/2020-2025-federal-health-it-strategic-plan) を公表している。2020-2025年計画では、以下のようなビジョンとミッションを掲げている。

  • ビジョン:情報を利用して、個人を関与させ、費用を低減し、高い品質のケアを提供し、個人および全住民の健康を向上させる健康システム
  • ミッション:それが最も重要な時や場所で、アクセス可能な技術・健康情報を利用して、個人やコミュニティの健康とウェルビーイングを向上させる

その上で、以下のような目標および目的から成るフレームワークを提示している。

目標1:保健とウェルネスを促進する

目的1a:個人の利用可能な保健情報へのアクセスを向上させる
目的1b:医療ITを通じて健康で安全なプラクティスを進化させる
目的1c:保健と福祉サービスの情報を統合する

目標2:ケアの提供と経験を強化する

目的2a:医療ITを活用して臨床プラクティスを向上させ、安全で高品質のケアを促進する
目的2b:医療ITを利用して、アクセスを拡張し、患者をケアにつなぐ
目的2c:医療における競争、透明性、負担可能性を育む
目的2d:提供者における規制や管理の負担を低減する
目的2e:医療ITリソースの効率的管理と、自信を持って医療ITを利用した国全体の労働力を可能にする

目標3:研究とイノベーションを加速させるためにセキュアなデータ駆動型エコシステムを構築する

目的3a:個人および人口レベルの保健データ移転を進化させる
目的3b:個人および人口レベルで医療ITとデータを利用した研究と分析を支援する

目標4:医療を健康データとつなぐ

目的4a:医療IT機能の開発と利用を進化させる
目的4b:データ共有への期待を創出する
目的4c:技術と通信のインフラストラクチャを強化する
目的4d:個人のプライバシーを保護するセキュアな保健情報プラクティスを促進する

バイオ/医療R&Dで重視されるAPIと相互運用性の標準化

ONCは、医療IT戦略計画の一環として、バイオ/医療R&D 領域におけるAPIの開発・標準化への取組をリードしながら、電子健康情報へのアクセスや交換、利用の負荷を低減することを目的として、以下のようなステークホルダー向け報告書を公表している。

各報告書とも、以下のような点に注目することによって、標準化されたAPIとヘルスケアアプリケーションに対する理解と利用を加速させるとしている。

  • どのようにして個人が、APIで可能になるアプリケーションを利用して、セキュアに自分のEHRデータにアクセスできるか
  • どのようにしてAPIが、研究者のために保健医療データへのアクセスを改善するか
  • どのようにしてデータアグリゲーターやデータインテグレーター、アプリケーション開発者が、APIを通して市場におけるイノベーションや競争を牽引できるか
  • どのようにして医療機関が、APIを利用してさらにケアを支援できるか

たとえば、「科学的発見に向けて加速するAPI:アプリケーション開発者とデータイングレーターの視点」は以下のような構成となっている。

  • イントロダクション
    • より大きな相互運用性へのシフト
    • 手法
  • 調査結果
    • 採用と利用の現状
      • 標準化されたAPI利用の動機づけ要因
      • 拡張されたデータセットとユースケース
      • モバイルプラットフォーム統合
      • 開発者ツールとリソース
    • 展開と統合の課題
      • 展開と検証サンドボックス
      • 独自APIとカスタム統合
      • データマッピングとデータの完全性
    • APIプロセス向上の機会
      • 集中型ツールとリソース
      • 業界教育と連携
      • 医療組織向けガイダンス
    • プライバシーとセキュリティの考慮事項
      • 粒度の細かいコンセントとワークフロー
      • データガバナンス
      • データセキュリティリスクと責務
  • 結論
  • 参考文献

CSA-HIM WGも、API利用をバイオ/医療データの相互運用性の中核に据えている。APIは、異なるアプリケーションから、アプリケーションの機能やデータにアクセスすることを可能にするエントリーポイントである。HL7 FHIRには、完璧な相互運用性ソリューションを構築するために拡張されたWeb標準規格と現代的な情報交換に基づくAPI向けの仕様が含まれる。APIとEHRの統合件数は増加傾向にあるが、FHIRデータ交換をサポートするAPIの割合は横ばい傾向にある。アプリケーションの中には、データ交換規格向け支援機能を利用・記述していないものがある点が、この要因と考えられる。加えて、FHIRリソースは、特定のデータ要素の交換を促進するにとどまっており、FHIRサポートのバリエーションに寄与していない可能性がある。特に、初期バージョンのFHIR標準規格にこれが当てはまる。FHIRリソースおよびサポートされたデータ要素の数が増えれば、FHIR向けのサポートも成長するとみている。

ただし、EHRと比較して医療機器の場合、事情が異なってくる。過去10年間多くのソリューションが推進され、標準規格が構築され、製品ソリューションも生産されてきたが、臨床現場の医療機器はEHRと通信するだけでなく、相互間で交換可能であることから、相互運用性がより複雑になっている。相互運用性によってケアが改善する可能性がある反面、データを生成する各機器やEHRシステムとの間を効率的にやりとりできるとは限らないので、注意が必要だ。

医療クラウドの普及がAPIや相互運用性に及ぼす影響と課題

さらに、バイオ/医療分野におけるクラウドコンピューティングの導入によって、データを供給し、利用可能なフォーマットで組み合わせることが可能になってきた。医療機関は、医療産業をサポートするデータ分析で利用する大容量データを保存・加工・共有することができる。

ただし、地理的に分散した場所にある様々なシステムにおいて、異なるソースから複数のデータタイプを有する医療データをクラウド上に集約すると、相互運用性のあるシステムを構築することがますます難しくなる。このような課題を解決するために、クラウドサービスプロバイダー側も、FHIR向けAPIとの相互運用性確保に向けて取組んでいる。また、クラウドは、臨床情報とともに、医用画像や医療機器からのメタデータを提供するので、より強力な結果をもたらすことも可能になる。

CSA-HIM WGは、相互運用性のあるシステムを構築するためには、以下のようなものが必要だとしている。

  • 共通のデータスキーム
  • 病院が大量のリアルワールドデータを共通のデータスキームにもたらすメカニズム
  • 共通のデータスキームに対する質問に答えるメカニズム

2011年、共通のFHIRデータモデルやAPI標準規格が、業界内で同じデータ言語と会話できる単一のデータスキーマに対する回答として提供されて以降、Google、AWS、Azureに代表される大規模クラウドサービスプロバイダー(CSP)は、医療機関が複雑なデータセットを収集し、検索できる手段を提供する技術プラットフォームの開発に尽力してきた。

医療機関がクラウドベースのサービスに移行するにつれて、ポイントツーポイントのカスタマイズなしで、アプリケーションやサービスを迅速に開発・接続・稼働するための機能が必要になってくる。FHIR向けAPIは、医療機関の情報技術チームが自らの製品を強化する際に役立つ。このようなソリューションによって、医療機関は、FHIRの標準化されたAPIで統合することによって、データをモバイル機器やWebポータルに素早く転送することができるとしている。

モバイル機器やWebブラウザ上で稼働するアプリケーションの多くは、API向け基盤として、REST(Representational State Transfer)情報交換規格を利用する。FHIRは、APIにおけるデータ交換向け基盤としてRESTを利用する。医薬品、観察、患者といった保健医療データのタイプは、自らのリソースによって表現される。このようなリソースについては、必要となる正確な情報を発見し、取得するために利用できる検索や要求のような相互作用に加えて、RESTFul HTTP APIコマンドを介してリクエストすることができる。サーバーは、FHIR APIがサポートできるリソースや相互作用のタイプによってプログラミングされる。FHIR APIを利用するサードパーティアプリケーションは、EHRに統合することによって、医療機関のワークフローに直接送り込むことが可能となる。

FHIR APIを利用した個々のリクエストは、リソースや、必要となるデータを特定するインディケーター、コマンドまたはパラメーターを提供する。FHIRのリクエストは、単独の患者のような情報ソースを返して、患者に関連する医療保険や医薬品または全患者のデータのような大量データの束に代表される情報の束を返す。リクエストは、どのタイプの、どれくらいのデータが必要かをアプリケーションに伝えるために、構造化される。

クラウドを利用することにより、医療機関は保健医療データをセキュアに管理できるようになる。FHIR向けAPIは、ネイティブなFHIRフォーマットにより、HIPAAの保護対象保健情報(PHI)の管理・保存向けに、拡張性のある安全な環境を提供するHL7 FHIR仕様に基づいており、一貫性のあるRESTful APIを介したデータ交換を可能にする。このようなFHIR向けAPIの特性により、EHRからの臨床データや、臨床医・患者ダッシュボード、遠隔モニタリングプログラム、医療機関の外部にあるデータベースを統合・正規化し、機械学習を適用するツールとして利用することもできる。

また医療機関は、無比のセキュリティインテリジェンス機能でPHIを保護することができる。データは、APIインスタンス毎に、独自のデータベースに分離して保護される。FHIR向けAPIは、階層型の多層防御と先進的なデータからの脅威保護機能を展開できる。加えて、医療機関は、連携型のロールベースアクセス制御(RBSC)機能を利用してデータを管理することができる。このように、相互運用性は、プライバシー/セキュリティの観点からも、医療機関がクラウドサービスに対するニーズを判断する際に重要な考慮事項となりつつある。

(後編に続く)

CSAジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

 

 

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*