OpeniDファウンデーション・ジャパン主催で2011/7/6に行われたPIDSプロジェクトの中間報告資料 途中のビデオは、こちらで → http://www.sakimura.org/2011/07/1149/

1. 2011-07-06 PIDSプロジェクト中間報告 崎村夏彦 (@_nat) http://www.sakimura.org/ 1

2. NHINって、何？ 2

3. NHINとは 3 2004 に開始された、米国全土にまたがる健康情報交換インフラプロジェクト Health Information Exchange (HIE) 及び他の期間との間での健康情報の発見と取得を可能にする 患者情報のサマリーを提供して、患者ケアや患者の健康増進に役立てる 情報交換は安全に行う すべての参加者が同意し遵守する、信頼の基となる契約書を作成する 国民背番号無くして患者とデータをひもづけることを可能にする ステークホルダーが任意で同意する標準のハーモニゼーションをサポートする

4. 主なユースケース 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. 5 Data Use and Reciprocal Support Agreement （出所） (NHIN) Architecture Overview v.1.0 1/29/2010

6. Architecture Principles 分散 自立・自治 ローカル・アカウンタビリティ 標準準拠 SOA Webサービスの利用 仕様ドリブン 認可フレームワーク メッセージング・プラットフォーム 患者ディスカバリ ドキュメント発見 ドキュメント取得 Health Information Event Messaging (HIEM) Document Submission Access Consent Policies Geocoded Interoperable Population Summary Exchange (GIPSE) Profile CARE (Continuity Assessment Record and Evaluation) Profile PKIをセキュリティのベースとして利用 6 （出所） (NHIN) Architecture Overview v.1.0 1/29/2010 を基にOIDF-J

7. Architecture Requirements 7 参加者間での健康データの交換 背番号なしで患者をかれらの情報にマッピング データ交換に関して、患者の希望を尊重できること 安全なデータ交換 標準準拠 多くの機関や技術、アプローチ方法をサポート 参加者全員がサインできる Trust Agreement （出所） (NHIN) Architecture Overview v.1.0 1/29/2010 を基にOIDF-J

8. NHIN Network Zones 8 HIO: Health Information Org （出所） (NHIN) Architecture Overview v.1.0 1/29/2010

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

10. NHIN Operational Infrastructure Components 10 （出所）Puscas, “NHIN Operational Infrastructure Architecture Document”, 2009 をもとにOIDF-J

11. NHIN Messaging, Security & Privacy Foundation 11 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 12 NHIN Discovery and Information Services UDDIでEnd Pointを検索 患者の発見(Patient Discovery) ２つのNodeが、患者の名寄せを行うためのシステム UDDI 一意に特定出来なかった場合には、属性を追加して再問合せ 1. End Point候補ください 2. 候補一覧 node1 3.氏名・生年月日・他 MPI node2 4.Patient ID, 属性 Master Person Index

13. NHIN Discovery and Information Services 13 ドキュメントIDとドキュメントの取得 Health Information Event Messaging (Pub/Sub) Document Submission (Push) Node 1 1. Patient ID Node 2 2. Doc ID 3. Doc ID HIO 5. Document 4. Authz

14. NHIN Specs 14 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 15 医療データ電子提供化インセンティブ 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 IDSystem (PIDS) 16 ®

17. PIDSの目的 17 PIDS全体の目的 Patient ID Service (PIDS) プロジェクトは、患者が自分の健康情報にアクセスしたり処理したりすることができるようにするための、Web上の認証サービスを作ります。 PIDSプロジェクトで作られたコードは、Apacheライセンスで提供され、各ベンダーが互換性の高い実装を提供するにあたっての、有用な素材を提供します。 PIDSプロジェクトのフェーズ１では、要件定義を行い、一つないし二つのアーキテクチャ案を提示し、フェーズ２におけるモデル実装、テスト、および認定サービスの開発の用に資するものとします。 OpenIDファウンデーション・ジャパンにとっての目的 PIDSのコンテキストの中でのOpenIDの有用性の立証 上記を用いた、OpenIDプロモーションマテリアルの獲得 Ph.2 での会員企業の参加＆ノウハウ獲得機会の提供

18. 18 プロジェクト体制 Joint Steering Committee Kantara Inititative (Board Member, LC Member), eCitizen Foundation (Board Member) Project Sponsor US$20,000(Ph.1) Matthew Gardiner, President, KI (Executive Adviser) Requirements Ray Campbell, Executive Director, Mass. Health Data Consortium, eCitizens Foundation （実施責任者） Dan Combs Dazza Greenwood Daniel Bennet （出所）eCitizen_Kantara_healthidpilot v.5 を元に NRI

19. 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 20

21. 21 Kantara – Patient NHIN Login Project 試験結果、課題リスト、処方薬リスト、薬剤アレルギーリスト、 予防接種、退院要約、退院後指導書 ICAM compatible/ certified Service?? Personal Health Records (un-tethered) Patient DI Federated SSO + Directory LoA2 Issues: PHRs must be trusted by NHIN (policy, legal framework) PHRs should/must support SAML? OpenID? PHRs could be run by various groups Information could exist on cell phones Patient e.g. Microsoft, Google Patient NHIN Service Gateway Patient Preferences / Authorization Service TLS NHIN Gateway Internet TLS TLS Doctor / Providers Doctor / Providers NHIN Gateway TLS NHIN Gateway TLS LoA3 LoA3 Federated SSO + Directory Federated SSO + Directory Minnesota Health Information Exchange Massachusetts Health Information Exchange VERY DRAFT – FOR DISCUSSION ONLY – 2-22-2010 （出所）Kantara Healthcare IAWG 2010-02-22資料を元にNRI

22. ゴール 22 PIDSプロジェクトは以下のゴールを目指しています。 Kantara Initiative の Identity Assurance Framework の適用可能性を実証する。 NSTICの目標の実現可能性を実証する。 多様なクレデンシャルを用いてユーザーが利用出来るサービスを構築し、それが「ONC Meaningful Use基準」に合致させることが可能であることを示す。 Health Information Exchange 、Helth Benefit Exchange 他のシステムの構築に資する認証システムのモデル実装を構築する。 公共・民間双方の各種ステークホルダーを引きこみ、PIDSに必要なインプットを得る。 必要とされていながら現在存在していない「ギャップ」を発見する。

24. Clinical Document Exchange

25. Privacy and SecurityHIE Gateway EMR Hospitals HIE Gateway Payors EMR RLS HIE Gateway HIE Gateway PHR HIE Member Users Simplified Sign Ons: to Clinics, Google Health, MS HealthVault, etc, or via iPhone or similar smartphone apps Patient Logins Simplified Sign Ons Clinics Healthcare Workers Patients （出所）Kantara Initiative Healthcare IAWG 2009-10-22資料

26. 進捗状況と今後の予定 24 NISTとOIXで共同開催。eCitizenがStakeholderに関してプレゼン NISTとeCitizen Fで共同開催 ▲OIX総会 ▲NSTIC Governance ▲EIDカンファレンス ▲NSTIC Privacy ▲Kantara総会 ▲PIDSカンファレンス 対象を拡大 ▲ ※NSTIC正式発表に伴い、要件取り込みおよびスケジュールの調整を実施

27. 機能要件～患者の視点 25 患者がPIDS Account作成 PIDS OpenID Identifierの発行＞患者 外部のPIDS accountへの結びつけ SAFE PIV Mobile phone Smart phone 患者はRPにPIDSクレデンシャルを用いてログイン RPはより高い認証レベルを要求可能 患者はPIDS accountへのアクセス許可を設定 通常時参照許可 緊急時参照許可（特に医療関係者用） 患者はPIDSシステムから様々なレポートを生成 (activity logs, linked accounts)

28. HIT Policy Committee Privacy and Security Tiger Team （出所）Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011

29. Architectural Super Structure 27 （出所）Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011

30. Simplified Patient Log-On 28 （出所）Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011

31. Simplified Patient Log-On 29 （出所）Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011

32. Simplified Patient-Controlled Sharing 30 （出所）Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011

33. Complex, Robust Back-End Rules & Policy-Based Auditable Access Control 31 （出所）Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011

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

35. 2 – Authenticate Open ID Server 3 - Retrieve 1 – Login Additional Info Credentials display PHR login Patient X Indivo （出所）Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011

36. 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 34

37. Interfaces, Connectors & Adapters 35 NwHINGateway 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を採用

38. Modular "Component" Approach 36 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

39. General Security Requirements 37 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”

40. List of Technical Components A simple account system with identity information from each account holding patient information, including first, last name, phone, address, etc. A URI/URL for each Patient Account A SAML 2.0 service that can send each Relying Party (Shibboleth) PIDS URI/URL or OID and either the Patient URI/URL or another OID to that Relying Party PIDS Credentials An OpenID service An Advanced Credential issuance or adoption service (enabling a patient to use, bind and/or link different identity credentials to their PIDS account) Advanced credential 1 is an X.509v3 digital certificate (optional) Advanced credential 2a is a Registered Mobile Phone for voice and/or text and/or keypad-based verification (optional) Advanced credential 2b is a Registered Smart Phone for 2a functions plus... (optional) Advanced credential 3 is an RSA Data Security Key Fob (optional) Advanced credential 4 is a PIV, PIV-I or other variations of these Cards (optional) (option) An Authentication as a Service account linkage, enabling the account credentials to be linked to KBA, crypto-based and other methods (option) An Authorization as a Service account linkage, enabling the account credential to be linked to UACS/RBAC and XACML types of services (option) An eSignature Service, enabling the use of credential to assent to or otherwise approve a document, signify consent or perform other related transactions Credential Suspension/De-linking/De-binding and Termination Service (option) Time Stamp Service and other real-time audit-friendly tools (e.g. GIS, HTTP logs, etc) Audit and Logging Service OpenID Connect and Oauth Services 38

41. Legal Architecture Roles and Relatioship Tbd Legal Design Spec. Federation PoV Patient PoV RP PoV IdPPoV 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 39

42. Legal Ecosystem 40 Statutes & Regulations Government Policies and Procedures Accreditation, Certification, Licensing Contracts and ToS Interest Groups and Oversight Organizations Advocacy and Internal Controls, Ombuds & Dispute Resolution

43. Next Steps 41 Ph.1 報告書の完成 Ph.1.5 – Ph.2 参加者の確定 LOI – Scopeの明確な定義 Ph.2 パイロットシステム Agile Development Funding Ideas MIT Media Lab と New Media Medicing group と共同で科研費を取得 NSTICパイロット予算の獲得 産業界からの参加者

44. 42 &

45. 報告書もくじ-１ 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 43

46. 報告書もくじ-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 44