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) 2つの 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 プロジェクトのフェーズ1では、要件定義を行い、一つないし二つのアーキテクチャ案を提示し、フェーズ2におけるモデル実装、テスト、および認定サービスの開発の用に資するものとします。
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
進捗状況と今後の予定
3月 4月 5月 6月 7月▲ キックオフ ▲ 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
報告書もくじ - 1Executive 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