情報プラットフォーム構築に必要なこと～欧州のユースケースに学ぶ医療・介護・健康情報連携基盤～

情報プラットフォーム構築に必要なこと
～欧州のユースケースに学ぶ医療・介護・健康情報連携基盤～
2022年1月15日
博士（医薬学）笹原英司
特定非営利活動法人ヘルスケアクラウド研究会理事

AGENDA
1. メガプラットフォーム事業者由来技術の
医療・介護・健康情報連携基盤への適用
2. COVID-19起点の欧州発保健医療
情報連携基盤構築のユースケース
3. COVID-19起点の欧州発ヘルスデータ
2次利用基盤構築のユースケース
2

1. メガプラットフォーム事業者由来技術の
医療・介護・健康情報連携基盤への適用
1-1. コンテナ／マイクロサービス／サーバーレスとは？
1-2. マイクロサービスを利用した医療・介護・健康情報連携のユースケース
3

1-1. コンテナ／マイクロサービス／サーバーレスとは？ (1)
4
・クラウドからアプリケーションコンテナ、マイクロサービスへの移行
 APIを軸とする自律サービスの疎結合型アーキテクチャへ
出典：ヘルスケアクラウド研究会（2016年1月)

5
・米国立標準技術研究所（NIST）「SP 800-180(Draft):
NIST マイクロサービス、アプリケーションコンテナ、システム仮想
マシンの定義」（2016年2月）
 アプリケーションコンテナ:
共有OS上で稼働するアプリケーションまたはそのコンポーネントと
してパッケージ化し、稼働するように設計された構成物
 マイクロサービス：
アプリケーション・コンポーネントのアーキテクチャを、疎結合のパタ
ーンに分解した結果生まれる基本的要素であり、標準的な通信
プロトコルや明確に定義された API を利用して相互に通信する
自己充足型サービスを構成し、いかなるベンダー、製品、技術か
らも独立している

6
・Cloud Security Alliance「セキュアなサーバーレスアーキテクチャ
の設計手法」(2021年9月14日)
 サーバーレスコンピューティングの定義
 アプリケーションオーナーのワークロードを提供するのに必要な、
計算処理／インフラストラクチャリソースを割り当てる責任が
クラウドプロバイダーにあるクラウドコンピューティングモデル
（“Pay as you go”）
 サーバーレスを利用するアプリケーションオーナーは、展開する
必要がある「呼び出し可能なユニット」および呼び出し可能な
ユニットを展開する必要がある一連の「イベント」を、サービス
プロバイダーに提供する

7
 呼び出し可能なユニット
 サービスプロバイダーによりサポートされるランタイムの1つの下で、
アプリケーションオーナーがファンクションコードを提供できるように
する
 アプリケーションオーナーが、呼び出し可能なユニットとして機能
するコントロールのコンテナイメージを提供できるようにする
（FaaSの拡張）
 イベント
 トリガーとなる特定のファンクションを引き起こす可能性がある
サーバーレス環境の状態

8
 サーバーレスセキュリティの概要
出典：Cloud Security Alliance Serverless WG「 How to Design a Secure Serverless Architecture」（2021年9月
14日）（https://cloudsecurityalliance.org/artifacts/serverless-computing-security-in-2021/）

9
 ファンクションベースのサーバーレス責任共有モデル

10
 イメージベースのサーバーレス責任共有モデル

11
 サーバーレスアーキテクチャの優位性と利点

12
 サーバーレスの責任共有モデル

1-2. マイクロサービスを利用した
医療・介護・健康情報連携のユースケース(1)
13
・スペイン：Alberto Garcés-Jiménez et al.「Medical
Prognosis of Infectious Diseases in Nursing Homes by
Applying Machine Learning on Clinical Data Collected
in Cloud Microservices」
Int J Environ Res Public Health. 2021 Dec 16;18(24):13278. doi: 10.3390/ijerph182413278
 目的：数日以内に感染症診断を予測することは、患者のウェルビーイングを画期
的に改善し、救急医療システムサービスの負荷を逓減すると想定された
 方法：
• 居住者からのバイタルサインが毎日収集され、クラウド上のデータベースに
転送された
• 収集されたデータの空間領域プロセスにおけるパターンを認識するために、
分類機が使用された
• 何らかの疾患が表れた時、医師は診断結果を報告した
• 柔軟性のあるマイクロサービスアーキテクチャがシステムへのアクセスと機能を
提供した

14
・介護に関わる看護師向けプロトコルのワークフロー
出典：Int J Environ Res Public Health. 2021 Dec 16;18(24):13278. doi: 10.3390/ijerph182413278

15
・医療センサー、ハブ、Androidタブレット接続

16
・感染症診断予測向けマイクロサービス・アーキテクチャ

17
・結論：
 本研究は、効率的な介護施設の医療スタッフ向けツール
を提供するために、モバイル通信や、クラウドサービス、
機械学習技術を適用する方法を探索している
 拡張性のあるアーキテクチャは、医療研究向けの価値ある
知識パターンを抽出する可能性があるビッグデータアプリ
ケーションに拡張させることができる

2. COVID-19起点の欧州発保健医療
情報連携基盤構築のユースケース
2-1. オープンソースコミュニティ主導型のCOVID-19接触追跡アプリケーション
開発・運用
2-2. クラウドネイティブ基盤を利用したEUのCOVID-19接触追跡アプリケーション
連携ゲートウェイ
2-3.分散型基盤を利用した欧州連合デジタルCOVID証明書ゲートウェイ
18

2-1.オープンソースコミュニティ主導型の
COVID-19接触追跡アプリケーション開発・運用(1)
19
・アップル＆グーグル「Apple and Google partner on
COVID-19 contact tracing technology」（2020
年4月10日）
 両社は、プライバシー保護コンタクト・トレーシング・サービスに
おける曝露通知機能の技術仕様草案（Bluetooth、暗号、
フレームワークAPI）を公開
 両社は、2020年5月に、公衆衛生当局からの公式アプリケーショ
ンを利用して、iOSとAndroidの相互運用性を実現するAPIを
リリース(米国連邦政府の医療データ相互運用性推進策を反映)
 両社は、数ヶ月中の間に、Bluetoothベースのコンタクト・トレーシ
ング・プラットフォーム機能（分散型）を基本プラットフォームに組込
んで幅広く提供できるようにする

20
・アイルランド保健サービス委員会（HSE）「COVID
Tracker」（2020年7月7日リリース）
 Bluetoothを介した近接検知メカニズムと、Google／Appleが
提供する暴露通知(GAEN) APIを利用した新型コロナウイルス
感染症向け接触確認アプリケーション
 アプリケーション・コードをオープンソース化（COVID Green）
してLinuxファウンデーションに寄贈 ⇒ AWS Lambdaを採用
(サーバーレス）
20
出典：Health Service Executive (HSE) 「COVID Tracker App」
（2020年7月7日）（https://covidtracker.gov.ie/）
出典：github.com: COVID GREEN
（https://github.com/covidgreen/covid-green-lambdas）

21
COVID Trackerの拡張機能(2022年1月7日時点)
21

22
・[参考] 厚生労働省「COCOA (COVID-19 Contact-
Confirming Application)」（2020年6月19日）
 Bluetoothを介した近接検知メカニズムと、Google／Appleが
提供する暴露通知(GAEN) APIを利用した新型コロナウイルス
感染症向け接触確認アプリケーション
 Microsoft Azureを採用
 Xamarin（開発環境）
 Azure Functions（サーバーレス）
 Azure CosmosDB
（NoSQLデータベース）
22
Source: The Ministry of Health, Labor, and Welfare, “(COCOA) COVID-19 Contact-Confirming Application”, June 22, 2020
(https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/cocoa_00138.html)

23
・オープンソース・テクノロジー・インプルーブメント・ファンド
(OSTIF) 「Linux Foundation公衆衛生イニシアティブ
がCOVID暴露通知アプリケーションの監査を支援」
(2021年1月15日)
 OSTIFが、Linux Foundation公衆衛生イニシアティブ
(LFPH)の支援を受けて、オープンソース化されたCOVID-19
暴露通知アプリケーション（アイルランド発「COVID Green」と
カナダ発「COVID Shield」）に対する監査を実施
 いずれのアプリケーションも、設計における潜在的弱点を特定し、
攻撃者が、ソフトウェアのプライバシー／完全性に対して改ざん
しようとする方法を特定するために、脅威モデルを構築し、クライアン
トソースコードのレビューを実施 *サーバーサイド・ソフトウェアはスコープ外

24
 セキュリティ目標
• ユーザープライバシー
1. 他のユーザーまたは第三者に、ユーザー識別情報(名前、電話番号、
位置情報、IPアドレスなど)を明らかにすべきでない
2. ユーザー識別情報、陽性検査結果、ユーザー兆候履歴を、相互に
紐付けできるようにすべきでない
3. ユーザー診断キー(GAEN APIにより生成・利用される）は、他の
ユーザーから秘密にしなければならない
4. いかなる2つの異なるユーザーのユーザー診断キーおよび近ID(GAEN
APIにより生成・利用される）も、相互に識別可能であってはならない
24

25
• クライアント・サーバー間の認証
1. 診断キーのExposure Managerへのアップロードは、陽性検査結果
を受けたユーザーおよび医療従事者により検査結果が認証済のユーザ
ーのみが可能でなければならない
2. 偽陽性を回避するために、診断キーは、すべてのユーザーについて一意
でなければならない
3. ユーザーは、診断キーを送信する前に、Exposure Service(TLS、ピ
ン留めされた証明書または同様のもの)のIDを認証できるようにしなけ
ればならない
• データの完全性
1. 攻撃者は、ユーザーに配布されたまたはユーザーがアップロードした診断
キーを改ざんできないようにすべきである
2. 攻撃者は、CSOStatsサービスに送信された統計を改ざんできないよう
にすべきである 25

26
• データ管理
1. COVID-19と診断された人は、COVID-19の兆候を示さなくなるまで
またはCOVID-19から治癒したと宣言されるまでの間、毎日、
Exposure Registryに診断キーをアップロードすべきである
2. ユーザーデータは、ユーザーからの要請により、 Registration
Serviceから削除されるべきである
3. ユーザーデータは、Registration Serviceまたはその他のCOVID
GreenやCOVID Alertサーバーコンポーネントによって、権限のない
第三者に提供されるべきでない
4. COVID GreenやCOVID Alertサービスによって引き受けられたデー
タ管理はすべて、企業や法人に適用されるのと同様に、一般データ保護
規則(GDPR)を遵守しなければならない
26

27
• サービスの可用性
1. ユーザーは、診断キーを一度だけアップロードできるようにすべきである
2. COVID GreenやCOVID Alertの過負荷を回避するために、サービ
スユーザーは、x SMS コードまたは電話のみを、y時間に、x場所で、ま
たyが賢明な選択肢として予め決定される形で、要求できるようにすべき
である
3. 妥当性のあるユーザーのみが、電話またはSMSの確認を要求できるよ
うにすべきである
4. モバイル機器の多くは、同時に他の7つの機器に接続するだけの場合が
あるので、Bluetooth接続は、適切にスケジュール設定されるようにす
べきである
27

28
 監査結果
28
監査指摘項目
Audit One –
COVID Shield /
COVID Alert
・CVG-01-003 COVID Shield – Misleading Security Guarantees –
WILL NOT FIX – EXPLAINED BELOW
・CVG-01-004 COVID Shield – Diagnosis Key Timestamps Set by
Client – NO FIX REQUIRED – SERVER DISCARDS DATA
・CVG-01-007 COVID Shield – Tests Fail to Generate Random
Keys – FIXED
Audit Two –
COVID Green /
COVID Tracker
・CVG-01-001 COVID Green: Denial of Service through Diagnosis
Key Flooding – FIXED
・CVG-01-002 COVID Green: Potential Diagnosis Keys Reuse –
FIXED
・CVG-01-005 COVID Green: SMS Provider Obtains Diagnosed
Phone Numbers – WILL NOT FIX – EXPLAINED BELOW
・CVG-01-006 COVID Green: Statistical Data Figures Overly
Precise – OUT OF SCOPE ISSUE
出典：OSTIF「The Linux Foundation Public Health Initiative Sponsored the Audit of COVID Exposure Notification Apps」（2021年1月15日）
https://ostif.org/the-linux-foundation-public-health-initiative-sponsored-the-audit-of-covid-exposure-notification-apps-here-are-the-
results/

29
・アイルランド保健サービス委員会（HSE）「Conti cyber
attack on the HSE」（2021年12月3日）
 2021年5月21日、HSEがランサムウェア「Conti」に起因する
サイバーインシデントで、ITシステムをシャットダウン
 一般医(GP)のシステムやCOVID-19検査予約紹介システムに
影響が出る
29
出典：Health Service Executive
(HSE) 「Conti cyber attack on
the HSE」（2021年12月3日）
（https://www.hse.ie/eng/serv
ices/publications/conti-cyber-
attack-on-the-hse-full-
report.pdf）

30
 HSEの組織図
30
出典：Health Service Executive (HSE) 「Conti cyber attack on the HSE」（2021年12月3日）
（https://www.hse.ie/eng/services/publications/conti-cyber-attack-on-the-hse-full-report.pdf）

31
 戦略的提言
1. ITおよびセキュリティに渡って、適切なフォーカス、注意、監視を提供する強
化されたガバナンス構造を導入する
2. 堅牢性があり、将来に適した技術機能をのためのビジョンやアーキテクチャを
構築し、必要とされる重要なトランスフォーメーション・プログラムの提供を先
導して、IT変革のスケールを実行するのに必要な拡大機能を構築するため
に、チーフ・テクノロジー＆トランスフォーメーション・オフィサー(CTTO)および
事務局を設置する
3. チーフ・インフォメーション・セキュリティ・オフィサー(CISO)を選任し、充分な
リソースとスキルを有するサイバーセキュリティ機能を創設して、サイバー
セキュリティ・トランスフォーメーション・プログラムの展開を構築・推進する
4. ナショナル・ガバナンス・リスク・ディレクターに報告する臨床／サービス継続ト
ランスフォーメーション・プログラムを展開し、影響度の大きいサイバー攻撃や
大規模なITの損失などのイベントをカバーする危機管理機能を強化する
31

2-2.クラウドネイティブ基盤を利用した
EUのCOVID-19接触追跡アプリケーション
連携ゲートウェイ(1)
32
・欧州委員会「承認済アプリケーション間の越境移転チェーン
のための相互運用性仕様に関するEU加盟国および欧州
委員会向けeヘルスネットワーク・ガイドライン V1.0」
（2020年6月16日）＊2020年10月より実稼働
 シェンゲン協定に基づいた域内経済交流の再開に向けて、接触
追跡アプリケーション越境連携の相互運用性に関わる統一標準
規格として策定 → SAPとドイツテレコムがシステムを構築
 基本的な相互運用性の要素
• Bluetoothの仕様
• COVID+ Keys（診断キー）
• 利害関係国リスト
• バックエンドサーバーの相互運用性

33
・欧州委員会「接触追跡アプリケーションの相互運用性に
関する技術仕様V1.0」（2020年6月16日）
 1. イントロダクション
 2. アーキテクチャ概要
 3. 通信
 4. データ構造（データタイプ、データストレージ）
 5. インタフェース
 6. セキュリティ（機密性、完全性、可用性）
 7. 技術選択
 8. 監査（全体、データプライバシー、データ転送、トラフィック）
 9. 分散プライバシー保護接近追跡（DP3T）互換性
 10.代替データ交換手法（ミラーリング、ブロックチェーン）

34
 接触追跡アプリケーションの越境連携エコシステム導入例
[域内共通の連携ゲートウェイサービスのアーキテクチャ]
• コンテナプラットフォーム
（例：Kubernetesベースの
OpenShift）
• REST API
（例：Node.jsとExpress）
• 分散NoSQLデータベース
（例：MongoDB）
• ロードバランサー
（例：Docker上のHAProxy）
• Webサーバー(：Docker上の
Nginx)
出典：European Commission「Technical specifications for interoperability of contact tracing apps - eHealth Network
Guidelines to the EU Member States and the European Commission on Interoperability specifications for cross-border
transmission chains between approved apps」（2020年6月16日）
(https://ec.europa.eu/health/sites/health/files/ehealth/docs/mobileapps_interoperabilitydetailedelements_en.pdf)

35
 域内共通の連携ゲートウェイサービスの概要

36
 自律的な各国のバックエンド

37
 通信(1)
デバイス－デバイス間通信デバイス－バックエンド間通信

38
 通信(2)
間接的なバックエンド－バックエンド間通信

39
 データベース構造：明快性のために省略されたAPIと発信
トラフィック

40
 インタフェース：APIの概要

41
 セキュリティ：バックエンドの機密性

42
 監査：全体
• 監査条件を保証するために、すべての連携ゲートウェイサービスへ
のリクエストは、監査ログを生成する監査モジュールを通過させて、
データベース内にログ、イベントストリーム、テーブルを生成するよう
にする
• このデータは、標準的な可視化ツール(例．Tableau、Kibana、
Splunk、Grafana)を経由して、ダッシュボード上に表示すること
ができる

43
 監査：データプライバシー
• 監査メカニズムの留意点
• GDPR遵守のデータ処理
• 不正アクセスのリスクの低減
• データ主体の権利保護
• 具体的な対策例
• 各国のバックエンドのIDを証明するクライアント認証
• アクティブな信頼性メカニズム：バックエンドは、誰が信頼できるか
（ホワイトリスト）、信頼できないか（ブラックリスト）を選択する
可能性がある
• データアクセスのロギング
• TLSを利用した転送時の暗号化
• データベース保存時の暗号化
• 侵入検知と悪用に関するアラート

44
 監査：データ転送
• クライアント情報は、クライアント認証や、要求／提出されたデータ
（鍵のオリジン、鍵のデスティネーション）、オペレーションのタイム
スタンプから抽出されて、クライアントやトラフィックの詳細に関する
統計を作成するために利用される
• アップロード／ダウンロードされたすべての情報は、証明可能である
ことが保証される
 監査：トラフィック
• モニタリング手法
 データベースログ経由
 データベース機能（手動）経由
 外部のイベントベースのモニタリングツール経由

2-3.分散型基盤を利用した
欧州連合デジタルCOVID証明書ゲートウェイ(1)
45
・欧州議会、EU理事会、欧州委員会「EUがデジタル
COVID証明書の手法を明確化」（2021年6月14日）
 EUデジタルCOVID証明書の目的：
COVID-19の期間中、EU域内の安全で自由な移動を促進する
 COVID-19ワクチン接種、検査、回復をカバーする
 EUの全言語で無料で利用可能である
 デジタルおよび紙の様式で利用可能である
 安全で、デジタル署名されたQRコードを含む
 2021年6月1日より、EU7カ国（ブルガリア、チェコ、デンマーク、ド
イツ、ギリシャ、クロアチア、ポーランド）が証明書を先行導入開始
 2021年7月1日より、EUデジタルCOVID証明書規則の正式適用
開始

46
 EUデジタルCOVID証明書
出典：European Commission「EU Digital COVID Certificate」（2020年6月16日）
(https://ec.europa.eu/info/live-work-travel-eu/coronavirus-response/safe-covid-19-vaccines-europeans/eu-digital-
covid-certificate_en#map)

47
・欧州委員会「デジタルグリーン証明書(*現デジタルCOVID
証明書)に関する技術仕様ガイドラインV1.3」
(2021年4月21日)
 2. アーキテクチャの概要
 3. 通信
 4. データ構造
 5. ビルディングブロックのスキーマ
 6. インタフェース
 7. 技術選択
 8. 展開ロードマップ
 9. 用語集

48
 デジタルグリーン証明書ゲートウェイの概要
出典：European Commission「Guidelines on Technical Specifications for Digital Green Certificates Volume 2」（2021年4月21日）
(https://ec.europa.eu/health/sites/default/files/ehealth/docs/digital-green-certificates_v2_en.pdf)

49
 相互運用性
信頼性の三角形 (Trust Triangle) 信用点 (Trust Anchor)

50
 署名と検証情報の配布

51
 デバイス－デバイス間通信

52
 間接的なバックエンド－バックエンド間通信

53
 トラステッド・データ・エクスチェンジ

54
 インタフェース：APIの概要

55
 技術選択
• REST API：Java／Spring Boot
• データベース：MySQL
• ロードバランサー：F5
• Webサーバー：Tomcat
出典：GitHub「Digital Green
Certificate Gateway」
（https://eu-digital-green-
certificates.github.io/dgc-
gateway/)

3.COVID-19起点の欧州発ヘルスデータ
2次利用基盤構築のユースケース
3-1. ポストCOVID-19時代のヘルスデータ連携を担う
EU4HEALTHプログラム
3-2. ポストCOVID-19時代の保健DXとR&Dを担う
欧州保健・デジタル政策庁
56

3-1. ポスト COVID-19時代のヘルスデータ連携を担う
EU4Healthプログラム(1)
57
・欧州連合「2021-2027年EU4Healthプログラム」
（2021年3月9日欧州議会採択）
出典：Health Service Executive (HSE) 「COVID Tracker App」（2020年7月7日）
（https://covidtracker.gov.ie/）
目標骨子
1. 感染症および非感染症の負荷を軽減する
ために、欧州連合の健康を向上させ、推進する
・疾病予防と健康増進（がんを含む）
・国際的な健康イニシアチブや協力関係
2. 重大な国境を越えた健康脅威から市民を
保護する
・国境を越えた健康脅威の予防や準備、対応
・不可欠な危機関連製品の国家備蓄の補充
・医療や健康ケア、支援スタッフの予備隊の創設
3. 医薬品や医療機器、危機関連製品の利用
可能性、アクセスのしやすさ、購入しやすさを
向上させる
・欧州連合における持続可能な生産・サプライチェーンを
推奨する一方、医療製品の有効利用を支援する
4.強靭性や資源効率を向上させることによって
健康システムを強化する
・健康データやデジタルツール・サービス、健康ケアの強化
・健康ケアへのアクセスの強化
・EU健康法制や根拠に基づく意思決定の構築と展開
・複数国の健康システム間の統合作業

58
 EU4Healthプログラムの戦略的方向性
出典：European Commission「Workshop EU4Health Programme 2021: potential solutions for
a healthier European Union」（2021年3月24日）を基にヘルスケアクラウド研究会作成
戦略的方向性ニーズ
危機準備・COVID-19体験に基づき、どのようにして、国家レベルのサーベイランスシステムを強化するか
・新型コロナウイルスの拡大を予防・制御するための既存の健康対策に
ついて、どのようにして公からの信頼を向上させるか
疾病予防
（がんを含む）
・どのような種類の協働モデルが、より多くの知識の移転やグッドプラクティス、現場での実装を生み
出せるか
・予防や診断、資料、ケア、すなわち、がん領域において、全ての市民向け標準規格の提示を、より
効率的に支援できるか
健康システムと
健康ケア労働力
・どのようにして、健康システムの強靭性を検証するか、またどのようにして、プライマリーケアや、健康
ケア向け労働力のスキル、欧州レファレンスネットワーク（ERNs）の国家システムへの統合を強化す
るか
・どのようにして、患者のニーズを考慮した医療機器や医療製品を開発するか
デジタル・健康データの品質や健康データの越境フローを向上させるために、何ができるか
・どのようにして、市民が、デジタルヘルスを通して自身の健康を引き受けるよう、効果的に動機付けら
れるか

59
・欧州委員会「欧州保健データスペース（EHDS）」構想
（2020年11月11日提案）
出典：European Commission「Towards a common European Health Data
Space」（2021年3月24日）

60
・[参考]欧州委員会「欧州データガバナンス法」
（2020年11月25日提案）
 経済社会におけるデータの潜在力を活用する
1. 公的セクターの主体が保有する機微データの再利用
2. 単一市場：データブローカーにおける新たなデータ仲介
機関向けのフレームワーク
3. データ利他主義向けのフレームワーク
4. 調整と相互運用性：欧州データイノベーション会議
（専門家グループ）

61
 欧州保健データスペース（EHDS）とは？
保健データ＋デジタルヘルス＋保健AIをベースとする
• データエクスチェンジ
（ガバナンス、プライバシー、品質、ポータビリティ、
データへのアクセス、インフラストラクチャ、相互運用性）
• デジタルヘルスサービス・製品向けの単一市場
• 保健AIなど、データ集約的なデジタルヘルスサービス・
製品の開発および展開に適した明確なルール
出典：European Commission「Towards a common European Health Data
Space」（2021年3月24日）

62
 保健データの1次利用と2次利用：
• 法律／ガバナンス、データ品質、インフラストラクチャ、キャパシティービルディング
出典：Saara Malkamäki, Sitra 「Introduction to the Joint Action Towards a European Health
Data Space (TEHDAS)」（2021年11月23日）

63
 EHDSにおける一般データ保護規則（GDPR）順守の
検証：
• 保健セクターにおける国レベルでのGDPR導入のマッピング
• 国レベルの保健データのルールとガバナンス構造
• 研究およびイノベーションにおける保健データ利用
• 政策の策定および規制上で目的とする保健データ利用、規制当
局の保健データへのアクセス
• 市民の保健データへのアクセスとデータポータビリティ
• 忘れ去られる権利など、患者の権利

3-1. ポスト COVID-19時代の保健データ2次利用を担う
64
・欧州委員会「GDPRに照らした保健データ向けEU加盟国
規則の評価」（2021年2月11日）
 2. 手法
 3. 患者ケア向け法的フレームワーク
 4. 公衆衛生目的の保健データ２次利用
 5. 科学的／歴史的研究の保健データ２次利用
 6. データ主体の権利
 7. データガバナンス戦略と主体
 8. EUレベルの潜在的活動
 参考文献

3-1. ポスト COVID-19時代の保健データ2次利用を担う
65
 評価結果からの考察
• 欧州の医療システムが、直接的な患者ケアのための１次利用、安全で効率
的な医療システム機能を支援するための２次利用、保健研究やイノベーション
を牽引するための２次利用の3つの相互関連した保健データをできるかぎり上
手に利用できるように保証するためには、数多くの法的および業務的課題に取
組む必要がある
• GDPRは、感謝すべき法令である反面、その解釈や導入に関連した国レベル
の法令の変化が、断片的なアプローチにつながり、ケア提供や医療システム管
理、研究をに関する越境協力を困難なものにしてきた
• 欧州保健データスペース（EHDS）への関心は高いが、確実なレベルの法的
および業務的ガバナンスが要求される
• 法的要求事項やガバナンスと同様に、加盟国における技術インフラストラクチャ
や、意味的な相互運用性、データ品質、データ収集、デジタルスキル、ケーパビ
リティビルディングへの取組も重要である
• 保健データ共有やガバナンスの取組には、多面的なアプローチが要求される

3-2. ポスト COVID-19時代の保健DXとR&Dを担う
欧州保健・デジタル政策庁(HaDEA) (1)
66
・欧州委員会「欧州気候・インフラストラクチャ・環境政策庁、
欧州保健・デジタル政策庁、欧州研究政策庁、欧州イノベー
ション会議・中小企業政策庁、欧州研究会議政策庁、欧州
教育文化政策庁の創設および実施決定の廃止」
（2021年2月12日）
 実際のスタッフやプログラム、資産の移転に先駆けて、欧州保健・
デジタル政策庁を新設(2021年2月16日付)
 欧州保健・デジタル政策庁は、EU4Healthプログラム、ホライズン・
ヨーロッパの保健研究部分、単一市場プログラムの保健コンポーネン
トなど、すべての保健関連活動に専心するとともに、欧州のデジタル
時代への参入を保証するデジタルプログラムをとりまとめる

67
 HaDEAのミッション：
• 地球から宇宙に至るまで、健康的な社会、競争的な産業、デジ
タル経済を構築することによって、欧州を強化する
 HaDEAのビジョン：
• 保健、食品安全、デジタル技術・ネットワーク、産業機能、宇宙
の領域において、欧州を強化する活動を展開する
• 欧州社会を、より健康的で、強靭性があり、公平なものとし、欧
州の産業を、より競争力のあるものとすることを目的として、高品
質でサービスオリエンテッドな支援を提供する
• HaDEAの資金を受けたプロジェクトが、すべてのEU市民の生
活に恩恵をもたらす完璧な結果を提供し、欧州委員会に、政策
向けの価値あるインプットを提供することを保証する

68
 HaDEAのプログラム：
• 欧州委員会の保健・食品安全総局などと連携しながら、政策
立案の法的・戦略的タスクに取組む
• 欧州委員会に代わり、EUのプログラム／イニシアティブを管理
する
 EU4Healthプログラム: 47億ユーロ
 ホライズン・ヨーロッパ：41億ユーロ
 単一市場プログラム：13億ユーロ
 デジタルヨーロッパ・プログラム：8億ユーロ
 産業・宇宙：56億ユーロなど

69
 欧州のエビデンスに基づくオープンサイエンス・ポータルとしての役割：
出典：European Health and Digital Executive Agency (HaDEA)
(https://hadea.ec.europa.eu/index_en)

4. まとめ／質疑応答
70
https://www.linkedin.com/in/esasahara
https://www.facebook.com/esasahara
https://twitter.com/esasahara

情報プラットフォーム構築に必要なこと～欧州のユースケースに学ぶ医療・介護・健康情報連携基盤～

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 情報プラットフォーム構築に必要なこと～欧州のユースケースに学ぶ医療・介護・健康情報連携基盤～

Similaire à 情報プラットフォーム構築に必要なこと～欧州のユースケースに学ぶ医療・介護・健康情報連携基盤～ (20)

Plus de Eiji Sasahara, Ph.D., MBA 笹原英司

Plus de Eiji Sasahara, Ph.D., MBA 笹原英司 (18)

情報プラットフォーム構築に必要なこと～欧州のユースケースに学ぶ医療・介護・健康情報連携基盤～