Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20110706 PIDSプロジェクト中間報告


Published on


途中のビデオは、こちらで →

Published in: Technology, Health & Medicine
  • Be the first to comment

  • Be the first to like this

20110706 PIDSプロジェクト中間報告

  1. 1. 2011-07-06<br />PIDSプロジェクト中間報告<br />崎村夏彦 (@_nat)<br /><br />1<br />
  2. 2. NHINって、何?<br />2<br />
  3. 3. NHINとは<br />3<br />2004 に開始された、米国全土にまたがる健康情報交換インフラプロジェクト<br />Health Information Exchange (HIE) 及び他の期間との間での健康情報の発見と取得を可能にする<br />患者情報のサマリーを提供して、患者ケアや患者の健康増進に役立てる<br />情報交換は安全に行う<br />すべての参加者が同意し遵守する、信頼の基となる契約書を作成する<br />国民背番号無くして患者とデータをひもづけることを可能にする<br />ステークホルダーが任意で同意する標準のハーモニゼーションをサポートする<br />
  4. 4. 主なユースケース<br />4<br />Emergency Responder-Electronic Health Record<br />Electronic Health Record – Lab Results<br />Medication Management<br />Consumer Empowerment-Consumer Access to Clinical Information<br />Consumer Empowerment- Registration and Medication History<br />Quality<br />Biosurveillance<br />
  5. 5. 5<br />Data Use and Reciprocal Support Agreement <br />(出所) (NHIN) Architecture Overview v.1.0 1/29/2010<br />
  6. 6. Architecture Principles<br />分散<br />自立・自治<br />ローカル・アカウンタビリティ<br />標準準拠<br />SOA<br />Webサービスの利用<br />仕様ドリブン<br />認可フレームワーク<br />メッセージング・プラットフォーム<br />患者ディスカバリ<br />ドキュメント発見<br />ドキュメント取得<br />Health Information Event Messaging (HIEM)<br />Document Submission<br />Access Consent Policies<br />Geocoded Interoperable Population Summary Exchange (GIPSE) Profile<br />CARE (Continuity Assessment Record and Evaluation) Profile<br />PKIをセキュリティのベースとして利用<br />6<br />(出所) (NHIN) Architecture Overview v.1.0 1/29/2010 を基にOIDF-J<br />
  7. 7. Architecture Requirements<br />7<br />参加者間での健康データの交換<br />背番号なしで患者をかれらの情報にマッピング<br />データ交換に関して、患者の希望を尊重できること<br />安全なデータ交換<br />標準準拠<br />多くの機関や技術、アプローチ方法をサポート<br />参加者全員がサインできる Trust Agreement<br />(出所) (NHIN) Architecture Overview v.1.0 1/29/2010 を基にOIDF-J<br />
  8. 8. NHIN Network Zones<br />8<br />HIO: Health Information Org<br />(出所) (NHIN) Architecture Overview v.1.0 1/29/2010<br />
  9. 9. NHIN Architecture Layers<br />9<br />HIO zone<br />NHIN zone<br />Infrastructure<br />zone<br />(出所) (NHIN) Architecture Overview v.1.0 1/29/2010 を基にOIDF-J<br />
  10. 10. NHIN Operational Infrastructure Components<br />10<br />(出所)Puscas, “NHIN Operational Infrastructure Architecture Document”, 2009 をもとにOIDF-J<br />
  11. 11. NHIN Messaging, Security & Privacy Foundation<br />11<br />Messaging Platform Spec. <br />WS-I Basic v.2.0<br />WS-I Security v.1.1<br />Authorization Framework<br />個人の認証はSAML2.0ベースで。<br />Requester, Date and Time<br />属性<br />Authorized Decision Statement<br />Authorization Framework<br />
  12. 12. NHIN Discovery and Information Services<br />12<br />NHIN Discovery and Information Services<br />UDDIでEnd Pointを検索<br />患者の発見(Patient Discovery)<br />2つのNodeが、患者の名寄せを行うためのシステム<br />UDDI<br />一意に特定出来なかった場合には、属性を追加して再問合せ<br />1. End Point候補ください<br />2. 候補一覧<br />node1<br />3.氏名・生年月日・他<br />MPI<br />node2<br />4.Patient ID, 属性<br />Master Person Index<br />
  13. 13. NHIN Discovery and Information Services<br />13<br />ドキュメントIDとドキュメントの取得<br />Health Information Event Messaging (Pub/Sub)<br />Document Submission (Push)<br />Node 1<br />1. Patient ID<br />Node 2<br />2. Doc ID<br />3. Doc ID<br />HIO<br />5. Document<br />4. Authz<br />
  14. 14. NHIN Specs<br />14<br />Access Consent Policies Production Specification - v1.0 [PDF - 176 KB]<br />Administrative Distribution Production Specification - v2.0 [PDF - 157 KB]<br />Authorization Framework Production Specification v2.0 [PDF - 256 KB]<br />Document Submission Production Specification v2.0 [PDF -200 KB]<br />Health Information Event Messaging Production Specification v2.0 [PDF - 152 KB]<br />Messaging Platform Production Specification v2.0 [PDF - 248 KB]<br />Patient Discovery Production Specification v1.0 [PDF - 214 KB]<br />Query for Documents Production Specification v2.0 [PDF - 212 KB]<br />Retrieve Documents Production Specification v2.0 [PDF - 178 KB]<br />Web Services Registry Production Specification v2.0 [PDF - 378 KB]<br /><br />
  15. 15. Meaningful Use<br />15<br />医療データ電子提供化インセンティブ<br />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.<br />
  16. 16. Patient IDSystem (PIDS)<br />16<br />®<br />
  17. 17. PIDSの目的<br />17<br />PIDS全体の目的<br />Patient ID Service (PIDS) プロジェクトは、患者が自分の健康情報にアクセスしたり処理したりすることができるようにするための、Web上の認証サービスを作ります。<br />PIDSプロジェクトで作られたコードは、Apacheライセンスで提供され、各ベンダーが互換性の高い実装を提供するにあたっての、有用な素材を提供します。<br />PIDSプロジェクトのフェーズ1では、要件定義を行い、一つないし二つのアーキテクチャ案を提示し、フェーズ2におけるモデル実装、テスト、および認定サービスの開発の用に資するものとします。<br />OpenIDファウンデーション・ジャパンにとっての目的<br />PIDSのコンテキストの中でのOpenIDの有用性の立証<br />上記を用いた、OpenIDプロモーションマテリアルの獲得<br />Ph.2 での会員企業の参加&ノウハウ獲得機会の提供<br />
  18. 18. 18<br />プロジェクト体制<br />Joint Steering Committee<br />Kantara Inititative (Board Member, LC Member), <br />eCitizen Foundation (Board Member)<br />Project Sponsor<br />US$20,000(Ph.1)<br />Matthew Gardiner, <br />President, KI<br />(Executive Adviser) <br />Requirements<br />Ray Campbell, Executive Director, <br />Mass. Health Data Consortium, <br />eCitizens Foundation (実施責任者)<br />Dan Combs<br />Dazza Greenwood<br />Daniel Bennet<br />(出所)eCitizen_Kantara_healthidpilot v.5 を元に NRI<br />
  19. 19. 19<br />プロジェクトメンバー経歴<br />Ray Campbell<br />Executive Director, Massachusetts Health Data Consortium<br />Dan Combs<br />CEO, eCitizen Foundation<br />Chair, EC3 Real ID Workgroup & Program Director, MIT Real ID Forum<br />Director, Digital Government, State of Iowa (200-2003)<br />Dazza Greenwood<br />Co-Founder & ED, eCitizen Foundation<br />弁護士、MIT Medialab 講師(1997-2007)、LegalXML E-Contract 委員会委員長(OASIS) 他<br />Daniel Bennet<br />CTO, eCitizen Foundation<br />W3C’s eGov Interest Group Invited Expert<br />米国 Paperwork Elimination Act 、電子署名法 共同起草者<br />
  20. 20. Patient ID System Vision Video<br />20<br />
  21. 21. 21<br />Kantara – Patient NHIN Login Project<br />試験結果、課題リスト、処方薬リスト、薬剤アレルギーリスト、<br /> 予防接種、退院要約、退院後指導書<br />ICAM compatible/ certified Service??<br />Personal Health Records<br />(un-tethered)<br />Patient DI<br />Federated SSO<br />+ Directory<br />LoA2<br />Issues:<br />PHRs must be trusted by NHIN (policy, legal framework)<br />PHRs should/must support SAML? OpenID?<br />PHRs could be run by various groups<br />Information could exist on cell phones<br />Patient<br />e.g. Microsoft, <br />Google<br />Patient NHIN Service Gateway<br />Patient Preferences / Authorization Service<br />TLS<br />NHIN Gateway<br />Internet<br />TLS<br />TLS<br />Doctor / Providers<br />Doctor / Providers<br />NHIN Gateway<br />TLS<br />NHIN Gateway<br />TLS<br />LoA3<br />LoA3<br />Federated SSO<br />+ Directory<br />Federated SSO<br />+ Directory<br />Minnesota Health Information Exchange<br />Massachusetts <br />Health Information Exchange<br />VERY DRAFT – FOR DISCUSSION ONLY – 2-22-2010 (出所)Kantara Healthcare IAWG 2010-02-22資料を元にNRI<br />
  22. 22. ゴール<br />22<br />PIDSプロジェクトは以下のゴールを目指しています。<br />Kantara Initiative の Identity Assurance Framework の適用可能性を実証する。<br />NSTICの目標の実現可能性を実証する。<br />多様なクレデンシャルを用いてユーザーが利用出来るサービスを構築し、それが「ONC Meaningful Use基準」に合致させることが可能であることを示す。<br />Health Information Exchange 、Helth Benefit Exchange 他のシステムの構築に資する認証システムのモデル実装を構築する。<br />公共・民間双方の各種ステークホルダーを引きこみ、PIDSに必要なインプットを得る。<br />必要とされていながら現在存在していない「ギャップ」を発見する。<br />
  23. 23. 23<br />Goal: Health care simplified authentication<br />【ご参考】<br />Health Information Exchange - HIE<br />Health Information Systems – Clinics, Hospitals, etc<br />Interoperability for<br /><ul><li>Patient Lookup
  24. 24. Clinical Document Exchange
  25. 25. Privacy and Security</li></ul>HIE Gateway<br />EMR<br />Hospitals<br />HIE Gateway<br />Payors<br />EMR<br />RLS<br />HIE Gateway<br />HIE Gateway<br />PHR<br />HIE<br />Member<br />Users<br />Simplified Sign Ons: to Clinics, Google Health, MS HealthVault, etc, or via iPhone or similar smartphone apps<br />Patient <br />Logins<br />Simplified Sign Ons<br />Clinics<br />Healthcare Workers<br />Patients <br />(出所)Kantara Initiative Healthcare IAWG 2009-10-22資料<br />
  26. 26. 進捗状況と今後の予定<br />24<br />NISTとOIXで共同開催。eCitizenがStakeholderに関してプレゼン<br />NISTとeCitizen Fで共同開催<br />▲OIX総会<br />▲NSTIC Governance<br />▲EIDカンファレンス<br />▲NSTIC Privacy<br />▲Kantara総会<br />▲PIDSカンファレンス<br />対象を拡大<br />▲<br />※NSTIC正式発表に伴い、要件取り込みおよびスケジュールの調整を実施<br />
  27. 27. 機能要件~患者の視点<br />25<br />患者がPIDS Account作成<br />PIDS OpenID Identifierの発行>患者<br />外部のPIDS accountへの結びつけ<br />SAFE<br />PIV<br />Mobile phone<br />Smart phone<br />患者はRPにPIDSクレデンシャルを用いてログイン<br />RPはより高い認証レベルを要求可能<br />患者はPIDS accountへのアクセス許可を設定<br />通常時参照許可<br />緊急時参照許可(特に医療関係者用)<br />患者はPIDSシステムから様々なレポートを生成 (activity logs, linked accounts)<br />
  28. 28. HIT Policy Committee Privacy and Security Tiger Team<br />(出所)Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011<br />
  29. 29. Architectural Super Structure<br />27<br />(出所)Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011<br />
  30. 30. Simplified Patient Log-On<br />28<br />(出所)Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011<br />
  31. 31. Simplified Patient Log-On<br />29<br />(出所)Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011<br />
  32. 32. Simplified Patient-Controlled Sharing<br />30<br />(出所)Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011<br />
  33. 33. Complex, Robust Back-End Rules & Policy-Based Auditable Access Control<br />31<br />(出所)Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011<br />
  34. 34. Open Architecture Enables Markets<br />(出所)Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011<br />
  35. 35. 2 – Authenticate<br />Open ID Server<br />3 - Retrieve<br />1 – Login<br />Additional Info<br />Credentials<br />display<br />PHR<br />login<br />Patient X<br />Indivo<br />(出所)Greenwood, Masson “Open Architecture for Patient Identity as a Service”, 2011<br />
  36. 36. Actors and Elements of PIDS<br />The actors and elements of the PIDS component include:<br />Patient<br />PHR Service<br />PIDS services<br />Registration Authority<br />Identity Proofing<br />Enrollment<br />Issuance (or adoption) of Identifier<br />Issuance (or adoption) of Identity Credential<br />Authentication registration, discovery and implementation service<br />Authorization and attribute registration, discovery and implementation service (e.g. PDP with XACML)<br />Relying Parties outside of NHIN<br />Relying Party Registries<br />Health care standard APIs or translation services<br />Health care providers within NHIN<br />Personal health and wellness devices<br />Smart Phone health and wellness apps<br />Other services on the web<br />34<br />
  37. 37. Interfaces, Connectors & Adapters<br />35<br />NwHINGateway<br />Direct Project<br />Indivo/Dossia Personal Health Platform*1<br />Microsoft Health Vault<br />Health & Wellness Apps on Android and iPhone Devices<br />Personal Medical Devices and Appliances<br />Back-End EMR, EHR and MPI Systems<br />*1 インテル、ウォルマートなどの共同PHR。オープンソースPHRのIndivoを採用<br />
  38. 38. Modular "Component" Approach<br />36<br />PIDS Component Contains Services and Data Stores<br /> Legal and Policy Interoperability and Modularity<br /> Interfaces Points With External Systems/Services<br /> Features of ID Service Component Approach:<br /> Capacity to Upgrade Components and Not Interfaces<br /> Capacity to Replace Component and Not Interfaces<br /> Capacity to Maintain Component and Replace Interfaces<br />
  39. 39. General Security Requirements<br />37<br />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)<br />HIPAA Security Rule - Examples of the weakness identified at the eight hospitals: <br />unprotected wireless networks,<br />lack of vendor support for OSs,<br />inadequate system patching,<br />outdated or missing antivirus software,<br />lack of encryption of data on portable devices and media,<br />lack of system event logging or review,<br />shared user accounts,  <br />excessive user access and administrative rights.<br />encrypting data stored on mobile devices, such as compact disks (CD) and thumb drives;<br />requiring two-factor authentication when remotely accessing an HIT system;<br />patching the operating systems (OS) of computer systems that process and store EHR.<br />Inspector General<br />“HIPAA does not provides adequate general IT security”<br />
  40. 40. List of Technical Components<br />A simple account system with identity information from each account holding patient information, including first, last name, phone, address, etc. <br />A URI/URL for each Patient Account<br />A SAML 2.0 service that can send each Relying Party (Shibboleth) <br />PIDS URI/URL or OID and<br />either the Patient URI/URL or another OID to that Relying Party<br />PIDS Credentials<br />An OpenID service<br />An Advanced Credential issuance or adoption service (enabling a patient to use, bind and/or link different identity credentials to their PIDS account)<br />Advanced credential 1 is an X.509v3 digital certificate (optional)<br />Advanced credential 2a is a Registered Mobile Phone for voice and/or text and/or keypad-based verification (optional)<br />Advanced credential 2b is a Registered Smart Phone for 2a functions plus... (optional)<br />Advanced credential 3 is an RSA Data Security Key Fob (optional)<br />Advanced credential 4 is a PIV, PIV-I or other variations of these Cards (optional)<br />(option) An Authentication as a Service account linkage, enabling the account credentials to be linked to KBA, crypto-based and other methods<br />(option) An Authorization as a Service account linkage, enabling the account credential to be linked to UACS/RBAC and XACML types of services<br />(option) An eSignature Service, enabling the use of credential to assent to or otherwise approve a document, signify consent or perform other related transactions<br />Credential Suspension/De-linking/De-binding and Termination Service<br />(option) Time Stamp Service and other real-time audit-friendly tools (e.g. GIS, HTTP logs, etc)<br />Audit and Logging Service<br />OpenID Connect and Oauth Services<br />38<br />
  41. 41. Legal Architecture<br />Roles and Relatioship<br />Tbd<br />Legal Design Spec. <br />Federation PoV<br />Patient PoV<br />RP PoV<br />IdPPoV<br />AS PoV<br />Multilateral Contract<br />Operating Rules and Trust Framework<br />Governance<br />Dispute Resolution<br />Recourse<br />Records Retention and Audit<br />Privacy and FIPPs<br />Participation Agreements<br />Patients<br />Relying Party<br />Provider<br />Apps/Service<br />39<br />
  42. 42. Legal Ecosystem<br />40<br />Statutes & Regulations<br />Government Policies and Procedures<br />Accreditation, Certification, Licensing<br />Contracts and ToS<br />Interest Groups and Oversight Organizations<br />Advocacy and Internal Controls, Ombuds & Dispute Resolution<br />
  43. 43. Next Steps<br />41<br />Ph.1 報告書の完成<br />Ph.1.5 – Ph.2 参加者の確定<br />LOI – Scopeの明確な定義<br />Ph.2 パイロットシステム<br />Agile Development<br />Funding Ideas<br />MIT Media Lab と New Media Medicing group と共同で科研費を取得<br />NSTICパイロット予算の獲得<br />産業界からの参加者<br />
  44. 44. 42<br />&<br />
  45. 45. 報告書もくじ-1<br />Executive Summary<br /> Objective<br /> Goals<br /> Solution<br />  Open Architecture<br />  Public Infrastructure<br /> Introduction<br /> Requirements and Constraints<br />  Use Cases, Field Survey and Requirements Gathering<br />  Patient and Individual End-User Needs<br /> Conceptual Solution Design and Options<br />  Functional Description-Patient Perspective<br /> Functional Description-Relying Party Perspective<br /> Functional Description-External Credential Provider (?)<br /> Actors and Elements of PIDS<br /> List of Technical Components<br /> Details of PIDS Process<br />  PIDS Instance Host and Business Models<br />  Process for Enrollment<br />   Linkage to Identity Credentials and Token<br /> PIDS Used with OpenID Connect Web Services<br /> Functional Design Layers<br />  1. Identity Service<br />  2. Authentication Service<br />  3. Authorization/Attribute Service<br /> Legal Architecture<br />  Roles and Relationships<br />  Legal Design Specification<br />43<br />
  46. 46. 報告書もくじ-2<br />Phase 2 Development and Implementation Plan<br /> Agile Coding and Waterfall Method<br /> Phase 2 Pilot and Testing<br /> Servers, Platforms, Applications, Services, Sub-Components and Partner Systems<br /> Pilot Test System, Service and Test Cases: Certifications and Accreditation<br /> NIST 800-63-1 Certified Level 1, 2 and 3 and FIPS 201 Authentication Products and Services<br /> Release and Evolve<br /> Budget Assumptions and Alternatives<br />  Alternative Budget #1<br />  Alternative Budget #2<br /> Schedule<br />Conclusion<br />Contact Information<br />44<br />