2011-07-06

PIDS プロジェクト中間報告

1崎村夏彦 (@_nat)http://www.sakimura.org/

2 NHIN って、何？

3

NHIN とは

2004 に開始された、米国全土にまたがる健康情報交換インフラプロジェクト Health Information Exchange (HIE) 及び他の期間との間で

の健康情報の発見と取得を可能にする 患者情報のサマリーを提供して、患者ケアや患者の健康増進

に役立てる 情報交換は安全に行う すべての参加者が同意し遵守する、信頼の基となる契約書を

作成する 国民背番号無くして患者とデータをひもづけることを可能に

する ステークホルダーが任意で同意する標準のハーモニゼーショ

ンをサポートする

4

主なユースケース

Emergency Responder-Electronic Health Record

Electronic Health Record – Lab Results Medication Management Consumer Empowerment-Consumer Access

to Clinical Information Consumer Empowerment- Registration and

Medication History Quality Biosurveillance

5

（出所） (NHIN) 　 Architecture Overview 　 v.1.0 1/29/2010

Data Use and Reciprocal Support Agreement

6

Architecture Principles

1. 分散2. 自立・自治3. ローカル・アカウンタビ

リティ4. 標準準拠5. SOA6. Web サービスの利用7. 仕様ドリブン

① 認可フレームワーク② メッセージング・プラッ

トフォーム③ 患者ディスカバリ④ ドキュメント発見

⑤ ドキュメント取得⑥ Health Information

Event Messaging (HIEM)⑦ Document Submission⑧ Access Consent Policies⑨ Geocoded Interoperable

Population Summary Exchange (GIPSE) Profile

⑩ CARE (Continuity Assessment Record and Evaluation) Profile

8. PKI をセキュリティのベースとして利用

（出所） (NHIN) 　 Architecture Overview 　 v.1.0 1/29/2010 を基に OIDF-J

7

Architecture Requirements

参加者間での健康データの交換 背番号なしで患者をかれらの情報にマッピン

グ データ交換に関して、患者の希望を尊重できる

こと 安全なデータ交換 標準準拠 多くの機関や技術、アプローチ方法をサポー

ト 参加者全員がサインできる Trust

Agreement

（出所） (NHIN) 　 Architecture Overview 　 v.1.0 1/29/2010 を基に OIDF-J

8

NHIN Network Zones

（出所） (NHIN) 　 Architecture Overview 　 v.1.0 1/29/2010

HIO: Health Information Org

9

NHIN Architecture Layers

NHIN zone

Infrastructurezone

HIO zone

（出所） (NHIN) 　 Architecture Overview 　 v.1.0 1/29/2010 を基に OIDF-J

10

NHIN Operational Infrastructure Components

インフラ システムの説明

• 各機関が提供する NHIN Gateway Web Service のメタデータ (Service Endpoint, etc.) を提供

• UDDI ベース v3 (HP Sysinet Foundation Registry)

• PKI 相互認証された NHIN 参加者にしか公開されない

• 各 HIO がメンテする Sub Registry が可能。• Managed PKI (mPKI) を使って、 X.509 を各

node に提供。各 node はこれを使って互いに認証を行う。

• 各 NHIN G/W の稼働監視（出所） Puscas, “NHIN Operational Infrastructure Architecture Document”, 2009 をもとに OIDF-J

11

NHIN Messaging, Security & Privacy Foundation

Messaging Platform Spec. WS-I Basic v.2.0 WS-I Security v.1.1

Authorization Framework 個人の認証は SAML2.0 ベースで。

Requester, Date and Time 属性 Authorized Decision Statement Authorization Framework

12

NHIN Discovery and Information Services

1. NHIN Discovery and Information Services

UDDI で End Point を検索

2. 患者の発見 (Patient Discovery) ２つの Node が、患者の名寄せを行うためのシ

ステム

node1

node2

UDDI

1. End Point 候補ください

2. 候補一覧

3. 氏名・生年月日・他

4.Patient ID, 属性MPI

Master Person Index

一意に特定出来なかった場合には、属性を追加して再問合せ

13

NHIN Discovery and Information Services

3. ドキュメント ID とドキュメントの取得

4. Health Information Event Messaging (Pub/Sub)

5. Document Submission (Push)

Node 1

1. Patient ID

2. Doc ID

3. Doc ID

5. Document

Node 2

HIO 4. Authz

14

NHIN Specs

Access Consent Policies Production Specification - v1.0 [PDF - 176 KB] Administrative Distribution Production Specification - v2.0 [PDF - 157

KB] Authorization Framework Production Specification v2.0 [PDF - 256 KB] Document Submission Production Specification v2.0 [PDF -200 KB] Health Information Event Messaging Production Specification v2.0

[PDF - 152 KB] Messaging Platform Production Specification v2.0 [PDF - 248 KB] Patient Discovery Production Specification v1.0 [PDF - 214 KB] Query for Documents Production Specification v2.0 [PDF - 212 KB] Retrieve Documents Production Specification v2.0 [PDF - 178 KB] Web Services Registry Production Specification v2.0 [PDF - 378 KB]

http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__nhin_exchange/1407

15

Meaningful Use

医療データ電子提供化インセンティブ The American Recovery and Reinvestment

Act of 2009 (ARRA) authorizes the Centers for Medicare & Medicaid Services (CMS) to provide reimbursement incentives for eligible professionals and hospitals who are successful in becoming “meaningful users” of certified electronic health record (EHR) technology. Beginning in January 2010, meaningful use will play a prominent role in NHIN development.

16 Patient ID System (PIDS)

®

17

PIDS の目的

PIDS 全体の目的 Patient ID Service (PIDS) プロジェクトは、患者が自分の健康情報にア

クセスしたり処理したりすることができるようにするための、 Web 上の認証サービスを作ります。

PIDS プロジェクトで作られたコードは、 Apache ライセンスで提供され、各ベンダーが互換性の高い実装を提供するにあたっての、有用な素材を提供します。

PIDS プロジェクトのフェーズ１では、要件定義を行い、一つないし二つのアーキテクチャ案を提示し、フェーズ２におけるモデル実装、テスト、および認定サービスの開発の用に資するものとします。

OpenID ファウンデーション・ジャパンにとっての目的 PIDS のコンテキストの中での OpenID の有用性の立証 上記を用いた、 OpenID プロモーションマテリアルの獲得 Ph.2 での会員企業の参加＆ノウハウ獲得機会の提供

18

プロジェクト体制

Ray Campbell, Executive Director, Mass. Health Data Consortium,

eCitizens Foundation （実施責任者）

Joint Steering CommitteeKantara Inititative (Board Member, LC Member),

eCitizen Foundation (Board Member)

Dan Combs Dazza Greenwood Daniel Bennet

Matthew Gardiner, President, KI(Executive Adviser)

Project SponsorUS$20,000(Ph.1)

Requirements

（出所） eCitizen_Kantara_healthidpilot v.5 を元に NRI

19

プロジェクトメンバー経歴 Ray Campbell

Executive Director, Massachusetts Health Data Consortium Dan Combs

CEO, eCitizen Foundation Chair, EC3 Real ID Workgroup & Program Director, MIT Real ID

Forum Director, Digital Government, State of Iowa (200-2003)

Dazza Greenwood Co-Founder & ED, eCitizen Foundation 弁護士、 MIT Medialab 講師（ 1997-2007) 、 LegalXML E-Contract 委

員会委員長 (OASIS) 他 Daniel Bennet

CTO, eCitizen Foundation W3C’s eGov Interest Group Invited Expert 米国 Paperwork Elimination Act 、電子署名法　共同起草者

20

Patient ID System Vision Video

21

Kantara – Patient NHIN Login Project

Federated SSO

+ Directory

NHIN Gateway NHIN Gateway

Internet

NHIN Gateway

Federated SSO

+ Directory

Minnesota Health

Information Exchange

Massachusetts Health

Information Exchange

Federated SSO

+ Directory

Personal Health

Records(un-tethered)

Patient NHIN Service

Gateway

VERY DRAFT – FOR DISCUSSION ONLY – 2-22-2010 （出所） Kantara Healthcare IAWG 2010-02-22 資料を元に NRI

Patient

Doctor / Providers Doctor / ProvidersTLSTLS

TLS

TLS

TLS

Patient Preferences

/ Authorizatio

n Service

ICAM compatible/ certified Service??

Issues:1. PHRs must be trusted by NHIN (policy, legal

framework)2. PHRs should/must support SAML? OpenID?3. PHRs could be run by various groups4. Information could exist on cell phones

LoA3 LoA3

LoA2

Patient DI

試験結果、課題リスト、処方薬リスト、薬剤アレルギーリスト、

予防接種、退院要約、退院後指導書

e.g. Microsoft, Google

22

ゴール

PIDS プロジェクトは以下のゴールを目指しています。

1. Kantara Initiative の Identity Assurance Framework の適用可能性を実証する。

2. NSTIC の目標の実現可能性を実証する。3. 多様なクレデンシャルを用いてユーザーが利用出来るサービスを構築し、それが「ONC Meaningful Use 基準」に合致させることが可能であることを示す。

4. Health Information Exchange 、 Helth Benefit Exchange 他のシステムの構築に資する認証システムのモデル実装を構築する。

5. 公共・民間双方の各種ステークホルダーを引きこみ、 PIDS に必要なインプットを得る。

6. 必要とされていながら現在存在していない「ギャップ」を発見する。

23

PHR

Hospitals

Clinics

Payors

Health Information Exchange - HIE

RLS

EMR

EMR

Interoperability for• Patient Lookup• Clinical Document Exchange• Privacy and Security

Goal: Health care simplified authentication

Simplified Sign Ons

HIEMemberUsers

Simplified Sign Ons: to Clinics, Google Health, MS HealthVault, etc, or via iPhone or similar smartphone apps

Patient Logins

Health Information Systems – Clinics, Hospitals, etc

Patients Healthcare Workers

HIE Gateway

HIE Gateway

HIE Gateway

HIE Gateway

【ご参考】

（出所） Kantara Initiative Healthcare IAWG 2009-10-22 資料

24

進捗状況と今後の予定

３月 ４月 ５月 ６月 ７月▲ キックオフ 　▲ NSTIC 発表 ▲IIW 最終報告▲

ステークホルダーインタビュー

要件定義

方式案整理・法的方式・技術方式

報告書作成

ビデオ作成

最終報告

▲PIDS カンファレンス▲NSTIC Privacy▲EID カンファレンス

▲Kantara 総会

▲OIX総会▲NSTIC Governance

▲

※NSTIC正式発表に伴い、要件取り込みおよびスケジュールの調整を実施

NIST と eCitizen F で共同開催

NIST と OIX で共同開催。 eCitizen が

Stakeholder に関してプレゼン

対象を拡大

25

機能要件～患者の視点

患者が PIDS Account 作成PIDS OpenID Identifier の発行＞患者外部の PIDS accountへの結びつけ

SAFEPIVMobile phoneSmart phone

患者は RP に PIDS クレデンシャルを用いてログイン RP はより高い認証レベルを要求可能 患者は PIDS accountへのアクセス許可を設定

通常時参照許可緊急時参照許可（特に医療関係者用）

患者は PIDS システムから様々なレポートを生成 (activity logs, linked accounts)

HIT Policy Committee Privacy and Security Tiger Team

（出所） Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011

Architectural Super Structure

27

（出所） Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011

Simplified Patient Log-On

28

（出所） Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011

Simplified Patient Log-On

29

（出所） Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011

Simplified Patient-Controlled Sharing30

（出所） Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011

Complex, Robust Back-End Rules & Policy-Based Auditable Access Control31

（出所） Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011

Open Architecture Enables Markets

（出所） Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011

PHR

Open ID Server

Patient X

Credentials

1 – Login

2 – Authenticate

3 - Retrieve

login

Indivo

Additional Info

display

（出所） Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011

34

Actors and Elements of PIDS

The actors and elements of the PIDS component include:

Patient PHR Service PIDS services

Registration Authority Identity Proofing Enrollment

Issuance (or adoption) of Identifier

Issuance (or adoption) of Identity Credential

Authentication registration, discovery and implementation service

Authorization and attribute registration, discovery and implementation service (e.g. PDP with XACML)

Relying Parties outside of NHIN Relying Party Registries Health care standard APIs or

translation services

Health care providers within NHIN

Personal health and wellness devices

Smart Phone health and wellness apps

Other services on the web

35

Interfaces, Connectors & Adapters

NwHIN Gateway Direct Project Indivo/Dossia Personal Health Platform*1

Microsoft Health Vault Health & Wellness Apps on Android and

iPhone Devices Personal Medical Devices and Appliances Back-End EMR, EHR and MPI Systems

*1 インテル、ウォルマートなどの共同 PHR 。オープンソース PHR の Indivo を採用

36

Modular "Component" Approach

PIDS Component Contains Services and Data Stores

 Legal and Policy Interoperability and Modularity  Interfaces Points With External Systems/Services  Features of ID Service Component Approach:

 Capacity to Upgrade Components and Not Interfaces  Capacity to Replace Component and Not Interfaces  Capacity to Maintain Component and Replace

Interfaces

37

General Security Requirements A holistic approach to information security – Address Inspector General’s report on “

Audit of Information Technology Security Included in Health Information Technology Standards” ( A-18-09-30160)

HIPAA Security Rule - Examples of the weakness identified at the eight hospitals: unprotected wireless networks, lack of vendor support for OSs, inadequate system patching, outdated or missing antivirus software, lack of encryption of data on portable devices and media, lack of system event logging or review, shared user accounts,   excessive user access and administrative rights.

encrypting data stored on mobile devices, such as compact disks (CD) and thumb drives;

requiring two-factor authentication when remotely accessing an HIT system; patching the operating systems (OS) of computer systems that process and store

EHR.

Inspector General

“HIPAA does not provides adequate

general IT security”

38

List of Technical Components

1. A simple account system with identity information from each account holding patient information, including first, last name, phone, address, etc.

2. A URI/URL for each Patient Account

3. A SAML 2.0 service that can send each Relying Party (Shibboleth)

a. PIDS URI/URL or OID and

b. either the Patient URI/URL or another OID to that Relying Party

4. PIDS Credentials

a. An OpenID service

b. An Advanced Credential issuance or adoption service (enabling a patient to use, bind and/or link different identity credentials to their PIDS account)

i. Advanced credential 1 is an X.509v3 digital certificate (optional)

ii. Advanced credential 2a is a Registered Mobile Phone for voice and/or text and/or keypad-based verification (optional)

iii. Advanced credential 2b is a Registered Smart Phone for 2a functions plus... (optional)

iv. Advanced credential 3 is an RSA Data Security Key Fob (optional)

v. Advanced credential 4 is a PIV, PIV-I or other variations of these Cards (optional)

5. (option) An Authentication as a Service account linkage, enabling the account credentials to be linked to KBA, crypto-based and other methods

6. (option) An Authorization as a Service account linkage, enabling the account credential to be linked to UACS/RBAC and XACML types of services

7. (option) An eSignature Service, enabling the use of credential to assent to or otherwise approve a document, signify consent or perform other related transactions

8. Credential Suspension/De-linking/De-binding and Termination Service

9. (option) Time Stamp Service and other real-time audit-friendly tools (e.g. GIS, HTTP logs, etc)

10. Audit and Logging Service

11. OpenID Connect and Oauth Services

39

Legal Architecture

Roles and Relatioship Tbd

Legal Design Spec. Federation PoV Patient PoV RP PoV IdP PoV AS PoV

Multilateral Contract Operating Rules and Trust

Framework Governance Dispute Resolution Recourse Records Retention and

Audit Privacy and FIPPs Participation Agreements Patients Relying Party Provider Apps/Service

40

Legal Ecosystem

Statutes & Regulations Government Policies and Procedures Accreditation, Certification, Licensing Contracts and ToS Interest Groups and Oversight

Organizations Advocacy and Internal Controls, Ombuds &

Dispute Resolution

41

Next Steps

Ph.1 報告書の完成 Ph.1.5 – Ph.2 参加者の確定

LOI – Scope の明確な定義 Ph.2 パイロットシステム

Agile Development Funding Ideas

MIT Media Lab と New Media Medicing group と共同で科研費を取得

NSTIC パイロット予算の獲得産業界からの参加者

42

&

43

報告書もくじ - １Executive Summary

　 Objective

　 Goals

　 Solution

　　 Open Architecture

　　 Public Infrastructure

　 Introduction

　 Requirements and Constraints

　　 Use Cases, Field Survey and Requirements Gathering

　　 Patient and Individual End-User Needs

　 Conceptual Solution Design and Options

　　 Functional Description-Patient Perspective

　 Functional Description-Relying Party Perspective

　 Functional Description-External Credential Provider (?)

　 Actors and Elements of PIDS

　 List of Technical Components

　 Details of PIDS Process

　　 PIDS Instance Host and Business Models

　　 Process for Enrollment

　　　 Linkage to Identity Credentials and Token

　 PIDS Used with OpenID Connect Web Services

　 Functional Design Layers

　　 1. Identity Service

　　 2. Authentication Service

　　 3. Authorization/Attribute Service

　 Legal Architecture

　　 Roles and Relationships

　　 Legal Design Specification

44

報告書もくじ -2

Phase 2 Development and Implementation Plan

　 Agile Coding and Waterfall Method

　 Phase 2 Pilot and Testing

　 Servers, Platforms, Applications, Services, Sub-Components and Partner Systems

　 Pilot Test System, Service and Test Cases: Certifications and Accreditation

　 NIST 800-63-1 Certified Level 1, 2 and 3 and FIPS 201 Authentication Products and Services

　 Release and Evolve

　 Budget Assumptions and Alternatives

　　 Alternative Budget #1

　　 Alternative Budget #2

　 Schedule

Conclusion

Contact Information