Download presentation
1
20 Oct 2014
2
ONC/VA Privacy on FHIR Pilot Drivers : Vision
We are on the cusp of a sea change in interoperability, population management, and clinical decision support. CCD led to CCDA which leads to FHIR for content summary exchange. The Direct protocol will evolve to a RESTful interface using OAuth/OpenID for trust fabric creation. However, we're not going to make the move to FHIR and REST unless pilots (followed by agile development of implementation guides) are funded to enable incremental progress. FHIR is too new and REST has too many industry skeptics. The pilots will create a tipping point which mitigates risk and enables progress. Dr. John Halamka We are on the cusp of a sea change in interoperability, population management, and clinical decision support. CCD led to CCDA which leads to FHIR for content summary exchange. The Direct protocol will evolve to a RESTful interface using OAuth/OpenID for trust fabric creation. However, we're not going to make the move to FHIR and REST unless pilots (followed by agile development of implementation guides) are funded to enable incremental progress. FHIR is too new and REST has too many industry skeptics. The pilots will create a tipping point which mitigates risk and enables progress.
3
ONC/VA Privacy on FHIR Pilot Drivers : Embrace FHIR, JSON, REST and OAuth
Recommendations in the ONC 10 year plan “Connecting Health and Care for the Nation: A 10-Year Vision to Achieve an Interoperable Health IT Infrastructure" and on the MU 2017 Roadmap PCAST: “Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward” AHRQ Jason Report: “ A Robust Health Data Infrastructure “ We are on the cusp of a sea change in interoperability, population management, and clinical decision support. CCD led to CCDA which leads to FHIR for content summary exchange. The Direct protocol will evolve to a RESTful interface using OAuth/OpenID for trust fabric creation. However, we're not going to make the move to FHIR and REST unless pilots (followed by agile development of implementation guides) are funded to enable incremental progress. FHIR is too new and REST has too many industry skeptics. The pilots will create a tipping point which mitigates risk and enables progress.
4
ONC/VA Privacy on FHIR Pilot: Summary of Pilot Project Plan
What is it? On-Demand bi-directional exchange of Health Information with Selected Apps…What, When and How You Want it Why do it? Test technical feasibility of using FHIR and associated privacy and security protocols to provide Patients with meaningful access, management and use of their own information. Deliverables? Incremental pilot milestone demonstrations, Several ONC sponsored HIMSS 2015 Interoperability Booths, Open Source Reference Model for implementers Who will do it? Collaborative of Stakeholders dedicated to demonstrating the benefits of HIT cloud capabilities for consumers and providers including: ONC, VA, DoD, Vendors, Patient Privacy Rights, HL7 Standards Development Organization
5
ONC/VA Privacy on FHIR Pilot [PoF]: What is HL7 FHIR
ONC/VA Privacy on FHIR Pilot [PoF]: What is HL7 FHIR? Fast Healthcare Interoperability Resources FHIR defines a set of "Resources" that represent granular clinical concepts managed in isolation, or aggregated into complex documents. FHIR is designed for the web: Simple XML or JSON structures, http-based RESTful protocol, Each resource has a predictable URL. FHIR Security and Privacy follows HL7 Security Labeling, Data Segmentation, and Consent Directive standards FHIR is under development and has not yet reached full standard status
6
ONC/VA Privacy on FHIR Pilot (PoF): Applying User Managed Access (UMA)-Oauth 2.0 Profile Patient controls Who gets What User Managed Access (UMA) OpenID Connect / OAuth 2.0 PoF Architecture leverages cloud Privacy and Security Services that Patients use daily as Online Consumers
7
ONC/VA Privacy on FHIR Pilot [PoF]: Introducing the Actors
8
ONC/VA Privacy on FHIR Pilot (PoF): MY Apps on FHIR Workflow
Assumptions: The resource owner must be and is capable of labeling information with an arbitrary collection of sensitivity categories designated by the patient (e.g, the system must be capable of applying sensitivity labels for the patient designated categories). Initial Conditions: The patient creates their own personal list of sensitivities (HIV, ETH, Other, …) for Apps on FHIR The RS will not share any of these categories without a clearance for that label in the App token The patient grants Application clearances to sensitivities in #1 as desired via the AS The AS issues tokens to Apps according to patient policy containing both authorizations to resources and clearances to sensitivities Request/provide Authorizations: App A requires IMMUZ including IMMUZ tagged with HIV; App B requires IMMUZ but not HIV and the patient does not want to share HIV or any other category on their sensitive information list with App B Based on patient authorizations, App A is provided a token for IMMUZ and clearance for HIV; APP B is provided a token for IMMUZ Response: App A receives IMMUZ including HIV tagged IMMUZ but no other sensitivities on the restriction list App B receives IMMUZ but none tagged with sensitivities on the restriction list PbD The system is privacy protecting by default since RS does not share information designated sensitive by the patient without a token containing the appropriate clearance The patient chooses to share sensitive information, sharing is the patient’s choice
9
My Privacy on FHIR Share Health Information Among Your Providers… Organizations, Apps, and Individuals… IOT IOT My Personal Health Record-Send to any
10
My Health Information Exchange on FHIR
Share Health Information Among Your Providers… Organizations, Apps, and Individuals… IOT My Personal Health Record-Send to any
11
Request for Data + Authz Token Check Overarching Policies
HIE on FHIR (detail) Out of Band: UMA Protection Flow: UMA Authz. Flow: Data Access Flow: Patient Set Resource Authz Policy 3 Submit CD Authorization API Authorization Server Protection API GUI 7 2 AAT a 7 Acquire Authorization Access Token (AAT) a Acquire Protection Access Token (PAT) a Request Requesting Party Token (RPT) b PAT b 2 AAT b 7 Register Resources & Scopes b Issue and send RPT c PAT a 2 RPT c 7 Requesting Org. Provider Org. Resource Server (Receiving) FHIR Client Authorization client Resource Server (Providing) Protection client FHIR API Request for Data 4 CDMS GUI Approve CD 1 Redirect to AS 6 PPS/SLS ACS Request for Data + Authz Token 8 RPT 10 Provide Data Check Overarching Policies 5 Verify Token Label/Transform Data 9
13
My Apps on FHIR Share Health Information with Your Selected Apps… What, When and How You Want it…All 24/7 Use your Information for Healthy Living, Wellness Management and Talking to Your Doctor Online IOT My Personal Health Record-Send to any My Personal Health Record My Travel App (Immunizations) My Diet Planner App (Diabetic) Smart Phone Tablet Personal Computer
14
all 24/7, wherever there is Internet access.
My Apps on FHIR Share Health Information with Your Selected Apps… What, When and How You Want it… all 24/7, wherever there is Internet access. IOT Use your Information for Healthy Living, Wellness Management and Talking to Your Doctor Online: My Personal Health Record My Travel App (Immunizations) My Diet Planner App (Diabetic) My Personal Health Record-Send to any Smart Phone Tablet Personal Computer
15
My Apps on FHIR 3 Authorization Server 6 2 EHR/PHR 1 3 Patient
Out of Band: UMA Protection Flow: UMA Authz. Flow: Data Access Flow: Authorize App 3 Authorization API Authorization Server Protection API GUI Register Resources and Scopes 2 Provide Claims and Acquire Authz Token 6 EHR/PHR FHIR Client Authz Client Resource server Protection client FHIR API Approve CD 1 Request for Data 3 Patient CDMS GUI Mobile App Redirect to AS 5 PPS/SLS ACS Submit CD Authz Token + Request for Data 7 Provide Data 9 Verify Token Check Overarching Policies Label/Transform Data 8
17
Restrictions enforced by Resource Server Privacy Protective Service
ONC/VA Privacy on FHIR Pilot (PoF): MY Apps on FHIR Enforcement Resource Server My “Apps on FHIR” Policy Restrictions enforced by Resource Server Privacy Protective Service (e.g.,Redact, Mask, Anonymize, Pseudononymize) Patient creates their own personal sensitivities list (e.g., HIV, ETH, Other, …) Privacy Protected
18
My Consent Directives on FHIR
Privacy…Share Only What You Want. Your Sensitive Healthcare Information Stays Secure. IOT IOT Assumptions: The resource owner must be and is capable of labeling information with an arbitrary collection of sensitivity categories designated by the patient (e.g, the system must be capable of applying sensitivity labels for the patient designated categories). Initial Conditions: The patient creates their own personal list of sensitivities (HIV, ETH, Other, …) for Apps on FHIR The RS will not share any of these categories without a clearance for that label in the App token The patient grants Application clearances to sensitivities in #1 as desired via the AS The AS issues tokens to Apps according to patient policy containing both authorizations to resources and clearances to sensitivities Request/provide Authorizations: App A requires IMMUZ including IMMUZ tagged with HIV; App B requires IMMUZ but not HIV and the patient does not want to share HIV or any other category on their sensitive information list with App B(Item 1) Based on patient authorizations, App A is provided a token for IMMUZ and clearance for HIV; APP B is provided a token for IMMUZ Upon request the Resource Privacy and Security Protective Service (PPS) processes the response as follows: App A receives IMMUZ including HIV tagged IMMUZ but no other sensitivities on the restriction list App B receives IMMUZ but none tagged with sensitivities on the restriction list PbD The system is privacy protecting by default since RS does not share information designated sensitive by the patient without a token containing the appropriate clearance The patient chooses to share sensitive information, sharing is the patient’s choice
19
My Consent Directives on FHIR
Privacy…Share Only What You Want. Your Sensitive Healthcare Information Stays Secure. Simple one-stop management of your privacy choices from one place for all your providers and Apps. Get a report of all disclosures Privacy by Design Manage Your Apps Choose what to Share IOT Assumptions: The resource owner must be and is capable of labeling information with an arbitrary collection of sensitivity categories designated by the patient (e.g, the system must be capable of applying sensitivity labels for the patient designated categories). Initial Conditions: The patient creates their own personal list of sensitivities (HIV, ETH, Other, …) for Apps on FHIR The RS will not share any of these categories without a clearance for that label in the App token The patient grants Application clearances to sensitivities in #1 as desired via the AS The AS issues tokens to Apps according to patient policy containing both authorizations to resources and clearances to sensitivities Request/provide Authorizations: App A requires IMMUZ including IMMUZ tagged with HIV; App B requires IMMUZ but not HIV and the patient does not want to share HIV or any other category on their sensitive information list with App B(Item 1) Based on patient authorizations, App A is provided a token for IMMUZ and clearance for HIV; APP B is provided a token for IMMUZ Upon request the Resource Privacy and Security Protective Service (PPS) processes the response as follows: App A receives IMMUZ including HIV tagged IMMUZ but no other sensitivities on the restriction list App B receives IMMUZ but none tagged with sensitivities on the restriction list PbD The system is privacy protecting by default since RS does not share information designated sensitive by the patient without a token containing the appropriate clearance The patient chooses to share sensitive information, sharing is the patient’s choice
21
Consent Directive Management Service 1/2
ONC/VA Privacy on FHIR Pilot (PoF): My Consent Directive on FHIR Policy Consent Directive Management Service 1/2 Consent Directive Policy Resource Authorizations Restrictions Organizational restrictions Role-Data Sensitivity Restrictions Specific individual restrictions My Apps on FHIR Policy Patient selected sensitivity restrictions (e.g. HIV, ETH, Other…) “Pre-Approved” policies to preserve automated workflow HL7 FHIR Consent Directive (Under Development)
22
Authorization Server 2/2
ONC/VA Privacy on FHIR Pilot (PoF): My Consent Directive on FHIR Policy Authorization Server 2/2 Application Authorization Authorizations as Tokens, meeting App Information Requirements and patient’s approval
23
ONC/VA Privacy on FHIR Pilot (PoF): Bill of Lading
(Stuff We Need)
24
END
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.