IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee July 15, 2008

Agenda Who is IHE Overall Security Model Deep dive Gaps Conclusion

What Is IHE? IHE is a collaborative response to healthcare IT market requirements for system integration. Develop standards-based implementation specifications called profiles. Useful subsets of one or more standards Tested at Connectathons Demonstrated at HIMSS, RSNA, and ACC shows Correct known integration problems. Intra-enterprise and multi-enterprise scope Satisfy emerging market needs & prevent new problems. EHR & government driven Regional and national scope Build trust, collegiality, effectiveness among vendors, providers, and other stakeholders.

What is a RHIO? HIMSS: RHIO – A Regional Health Information Organization (RHIO) is a multi-stakeholder organization that enables the exchange and use of health information, in a secure manner, for the purpose of promoting the improvement of health quality, safety and efficiency. Competing enterprises Longitudinal view of the patient’s health history Protect Privacy Providing better care to patients Promoting Safety and Quality Aka: SNO, HIN, HIE, IHE: Affinity Domain

Affinity Domain -- Policies International Policies Country-Specific Policies Horizontal Industry Policies Enterprise Policies IHE – leverages/profiles OECD Guidelines On Transborder Flows US-HIPAA EU-EC95/46 JP-Act 57 - 2003 Medical Professional Societies Backup & Recovery Examples

RHIO: Document based Persistence, Stewardship, Captures the conclusion / summary of an episode Stewardship, Long term maintenance (patients life 100+ years) Potential for Authentication, and Which Doctor’s conclusion or opinion What predicate data or knowledge Wholeness. Integrity, completeness, inclusive,

XDS Security Use Cases Prevent Indiscriminate attacks (worms, DOS) Normal Patient that accepts XDS participation Patient asks for Accounting of Disclosures Protect against malicious neighbor doctor Patient that retracts consent to publish Provider Privacy Malicious Data Mining Access to Emergency data set VIP (movie star, sports figure) Domestic violence victim Daughter with sensitive tests hidden from Parent Sensitive topics: mental health, sexual health Legal Guardian (cooperative) Care-Giver (assists w/ care)

Document Accessibility Entries restricted to prison health service Entries restricted to sexual health team Entries accessible to administrative staff Entries accessible to clinical in emergency Private entries shared with GP Private entries shared with several named parties Entries accessible to direct care teams Source: Dipak Kalra & prEN 13606-4

RBAC table Sensitivity Functional Role Billing Information Administrative Information Dietary Restrictions General Clinical Information Sensitive Clinical Information Research Information Mediated by Direct Care Provider Administrative Staff X   Dietary Staff General Care Provider Direct Care Provider Emergency Care Provider Researcher Patient or Legal Representative

Document Accessibility Inside Ent In HIE There are many different possible ways to layout the RBAC permissions across data. Including different views based on if the data is being accessed wholely inside an enterprise or across a HIE.

Privacy Controls

Basic Patient Privacy Consents Abstract The Basic Patient Privacy Consents (BPPC) profile provide mechanisms to: Record the patient privacy consent(s), Mark documents published to XDS with the choice of patient privacy consent that was used to authorize the publication, Enforce the privacy consent appropriate to the use. Builds upon the ATNA security infrastructure

Basic Patient Privacy Consents Value Proposition an Affinity Domain can develop privacy policies, and implement them with role-based or other access control mechanisms supported by edge/EHR systems. A patient can Be made aware of an institution privacy policies. Have an opportunity to selectively control access to their healthcare information.

Basic Patient Privacy Consents Standards and Profiles Used Key Properties Human Readable Consents Machine Processable Support for standards-based Role-Based Access Control Standards CDA Release 2.0 XDS Scanned Documents Document Digital Signature Cross Enterprise Document Sharing (XDS.a, XDS.b, XDR, and XDM)

RBAC with Basic Consent

Basic Consent on an episode basis Affinity Domain Policy could require a per-episode consent be captured.

Basic Consent – Extended to HIE

Basic Consent – Publication controls Previous slides presumed publication was allowed, here we show that Basic consent could be used to prevent publication Consents can control what gets published, and what is too sensitive to publish Consents can also enable PHR access to the HIE Other examples would be to identify VIP patient’s data to not automatically publish

Document Level controls ‘confidentialityCode’ Must get explicit per-use consent During publication the documents can be labeled with appropriate uses using the confidentialityCode. This is informed by resulting RBAC policies and consents.

Security Controls

XDS Scenario + use of ATNA & CT Physician Office EHR System Teaching Hospital PACS ED Application EHR System PMS XDS Document Repository Community Clinic Lab Info. System PACS XDS Document Registry Query Document Register Document Secured Messaging Lets lift the cover and get a peek into some of the details that enable secured sharing of health records. Animated, but automatic, only two clicks: First Click: start placing the three infrastructure components: registry, audit trail repository and cosnsitent time server, then publishes a document and registers it with appropriate security Second Click: serach documents, retrieve them and impoirt them into the community clinic EMR. Retrieve Document Provide & Register Docs Maintain Time ATNA Audit record repository CT Time server Maintain Time Record Audit Event Maintain Time Record Audit Event Record Audit Event

ATNA Security Model(1) Dual Authenticated Links Secured Node Physician Office EHR System Teaching Hospital PACS ED Application EHR System Dual Authenticated Links PMS XDS Document Repository Community Clinic Lab Info. System PACS XDS Document Registry XDS Document Repository Lets lift the cover and get a peek into some of the details that enable secured sharing of health records. Animated, but automatic, only two clicks: First Click: start placing the three infrastructure components: registry, audit trail repository and cosnsitent time server, then publishes a document and registers it with appropriate security Second Click: serach documents, retrieve them and impoirt them into the community clinic EMR. XDS Document Repository Provide & Register Docs

IHE RHIO Solution RHIO boundary Teaching Hospital State run RHIO Physician Office EHR System Teaching Hospital State run RHIO Patient ID X-ref PMS ED Application XDS Document Repository XDS Document Registry PACS Query Document Register Document Explain the link between audit logs and accountability. EHR System PACS Retrieve Document Provide & Register Docs ATNA Audit record repository Lab Info. System ATNA Audit record repository CT Time server ATNA Audit record repository Community Clinic

Security Models Risk Assessment Accountability Policy Enforcement Asset is the information in Registry & all Repositories Confidentiality, Integrity, and Availability Patient Safety overrides privacy (most of the time) Accountability Access Control model -- Prevention Audit Control model -- Reaction Policy Enforcement Mutually agree to enforce Policies Enforcement of policies centrally

RHIO Domain Policy XDS Affinity Domain Definition Checklist See Template for XDS Affinity Domain Deployment Planning IHE gives no direction on the content of this Policy E.g. Patient allows general purpose healthcare information to be submitted, sensitive data will not be published. Only Healthcare Providers that are a member of that patients direct care team will be given access. Policy must be enforceable by all the systems in the RHIO Domain EHR RBAC capabilities must be considered PHR portal must be able to enforce restrictions Registry / Repositories must only talk to authorized systems Appendix L: XDS Affinity Domain Definition Checklist The concept of an XDS Affinity Domain is defined in ITI TF-1:10 and Appendix K. This informative appendix summarizes the key policies that need to be agreed to in order to deploy a EHR-LR document sharing environment. L.1 Configuration of an XDS Affinity Domain A number of systems implementing IHE Actors defined in the XDS Integration Profile need to be identified and configured to communicate. This includes defining addressing information and ATNA Secured Node certificate: 1. Identify the system that will support the Document Registry Actor. 2. Identify the systems that will support the Document Repository Actors. 3. Identify the systems that will support Document Source and/or Document Consumer Actors. L.2 Patient Identification Initialize the XDS Document Registry (See ITI TF-2:Appendix H) with the proper patient identification information: 1. Assign an Assigning Authority (OID) for the XDS Affinity Domain Patient Id Domain. 2. Assign an Assigning Authorities (OID) for the each one the Local Patient Id Domains in which the EHR-CR Document Source and/or Document Consumer operate. 3. Identify the system that will support the Patient Identity Source and if some of the systems that support Document Source and/or Document Consumer Actors also support a Patient Identity Cross-reference Manager (needs to receive a patient identity feed Transaction). L.3 XDS Registry Related Vocabularies Initialize the XDS Document Registry (See ITI TF-2:Appendix H) with the proper vocabulary information: 1. Select and initialize the XDS Document Registry as well as the Document Sources and/or Document Consumers with the vocabulary definitions specified in Registry Enforcement (ITI TF-2:3.14.4.1.2.9) where either the Coding Scheme or the Coding Scheme/Code Values are enforced. L.4 Document Sharing Practice Policies 1. Define the care events and the corresponding expected level of information that is expected to be shared within the EHR-LR. 2. Define the usage policies for XDS Folder (creation and update) in the selected care pathways supported. L.5 XDS Document Content 1. For each Document Format Code Value, establish the necessary interoperability agreements (e.g. by selecting IHE Document Content Profiles) to ensure that the Document Consumers may find (e.g. Document UniqueId structure) and process the XDS Documents content (e.g. MIME type, template definitions, archetypes, etc.) they retrieve from the XDS Repositories of the XDS Affinity Domain. L.6 Document Update and Maintenance Policies Document Sources are responsible for the on-going accuracy (custodianship) of the XDS Documents they have elected to shared in the EHR-LR supported by the Affinity Domain. This includes: 1. Replacement of documents in the EHR-LR 2. Cases and means to possibly delete documents in the EHR-LR L.7 Security and Privacy Policies 1. Establish agreed policies and procedures among care delivery organizations in the Affinity Domain. In particular address security considerations in ITI TF-2:Appendix K. 2. Establish operational security infrastructure, including certificate exchange. 3. Maintain operational security infrastructure, configuration management, audit management, periodic inspections, etc.

IHE-XDS Infrastructure Components Document Registry (XDS) – Queryable index of metadata and references to all documents shared within a connected community (XDS Affinity Domain) Document Repository (XDS) – Supports storage and retrieval of clinical information (as documents). May be centralized or distributed. Patient Identifier Cross Reference Manager (PIX) – Reconciles information on patients from multiple domains to a single, cross referenced set of IDs for each given patient. Patient Demographics Supplier (PDQ) – Returns demographic information and identifiers for patients based on specified demographic criteria. Audit Record Repository (ATNA) – Receive audit records from other actors and securely store for audit purposes. ATNA also authenticates peer-nodes and encrypt communications. Cross Enterprise User Assertion (XUA) – Mechanism for User Identity federation Basic Patient Privacy Consents (BPPC) – Providing for Patient Privacy dimension of Access control including Capturing Patient Consent including support for Opt-In and Opt-Out Time Server (CT) – Provides consistent definition of date/time enabling time synchronization across multiple systems. Enables events associated with patients to be sorted reliably in chronological order.

Security & Privacy Controls IHE Profile Accountability Identification and Authentication Data Access Confidentiality Data Integrity Non-Repudiation Patient Privacy Availability Audit Trails and Node Authentication D Basic Patient Privacy Consents I Consistent Time Enterprise User Authentication Cross-Enterprise User Assertion Document Digital Signature Cross-Enterprise Document Sharing Cross-Enterprise Document Reliable Messaging Cross-Enterprise Document exchange on Media Personnel White Pages

Identity and Access Control

Cross-Enterprise User Assertion Value Proposition Extend User Identity to Affinity Domain Users include Providers, Patients, Clerical, etc Must supports cross-enterprise transactions, can be used inside enterprise Distributed or Centralized Identity management (Directories) Provide information necessary so that receiving actors can make Access Control decisions Authentication mechanism used Attributes about the user (roles) Does not include Access Control mechanism Provide information necessary so that receiving actors can produce detailed and accurate Security Audit Trail

Cross-Enterprise User Assertion Technical Solution Initial scope to XDS.b Stored Query and Retrieve Relies on Web-Services Easily extended to any Web-Services transactions Leverage WS-I Basic Security Profile 1.1 Use SAML 2.0 Identity Assertions Does not constrain ‘how’ the Assertion was obtained Supporting Liberty Alliance, WS-Trust, and SAML Define grouping behavior with EUA and ATNA

Four Identity Assurance Levels OMB E-Authentication Guidance establishes four assurance levels for consistent application of E-Authentication across gov’t Level 4 Level 3 Level 2 Level 1 Little or no confidence in asserted identity (e.g. self identified user/password) Some confidence in asserted identity (e.g. PIN/Password) High confidence in asserted identity (e.g. digital cert) Very high confidence in the asserted identity (e.g. Smart Card) E-RA tool assists agencies in defining authentication requirements & mapping them to the appropriate assurance level NIST SP800-63 Electronic Authentication technical guidance matches technology to each assurance level Slide c/o David Temoshok and GSA

Security Considerations: Four Identity Assurance Levels Increased $ Cost Multi - Factor Token PKI/ Digital Signature Knowledge - Based Very Strong Password High - High PIN/User ID Medium Low Slide c/o David Temoshok and GSA Access to Summary of Clinical research Access to Local EHR/EMR Verification Of Data Transcription Remote Clinical Entry Increased Need for Identity Assurance

Cross-Enterprise User Assertion Implementation Example EHR (ATNA Secure Node) XDS Registry XDS Consumer (ATNA Secure Node) Patient Data X-Service User X-Identity Provider XUA = Web-Services Security + SAML Assertions XUA Assertion Audit user auth provider Audit Log User Auth Key: Original Transaction TLS Protections

Distributed Access Control – enabled by XUA XDS Document Consumer XDS Registry Access Control B XDS Document Consumer XDS Registry Access Control Access Control C XDS Document Consumer XDS Registry Access Control Access Control Access Control

Accountability

Today’s XDS Accountability Mitigation against unauthorized use Investigate Audit log for patterns and behavior outside policy. Enforce policy Secure Node requires appropriate Access Controls to enforce at the enterprise by XDS Source and Consumers Investigation of patient complaints Investigate Audit log for specific evidence ATNA Audit Repositories can filter and auto-forward Support an Accounting of Disclosures ATNA Report: XDS-Export + XDS-Import The ATNA audit log includes enough information to detect a potential problem. Where enough information is not available in ATNA, the results can be used to enable forensic logs if they are available. The ATNA Audit Repository must protect the audit log appropriately, and provide the necessary tools to enable the necessary functionality and reporting.

Centralized Accountability RHIO boundary Physician Office EHR System PMS ED Application XDS Document Repository XDS Document Registry PACS Query Document Register Document Explain the link between audit logs and accountability. EHR System PACS Retrieve Document Provide & Register Docs Maintain Time Lab Info. System ATNA Audit record repository CT Time server Maintain Time Teaching Hospital Maintain Time Community Clinic

Distributed Accountability RHIO boundary Physician Office EHR System Teaching Hospital State run RHIO PMS ED Application XDS Document Repository XDS Document Registry PACS Query Document Register Document Explain the link between audit logs and accountability. EHR System PACS Retrieve Document Provide & Register Docs ATNA Audit record repository Maintain Time Lab Info. System ATNA Audit record repository CT Time server Maintain Time Maintain Time ATNA Audit record repository Community Clinic

Example: Audit Log Cascade Clinic A EMR Kdjldsj Sjfldjlsdj a Lsjldjl jfjfjlslkjln Lslasdjj;ask;sls Sflksdjfl;saf Salasaska Faslskf;sf Slsjlsdjlsdjf Lsjflsdjldsjfs Slkfjsdlfjldsf lsjfldsjfldsfj HIE Infrastructure Audit Sjfldjlsdj a Lslasdjj;ask;sls Faslskf;sf lsjfldsjfldsfj Audit Inform Disclosure Reports Detect unusual behavior  Follow chain back

Flexible Infrastructure: Sharing, Sending and Interchanging Health Information Exchange or RHIO XDS Structured objects Pull Publish Pull Send to Switch XDR Write Read Interchange Media XDM Transactions Workflow Mgr

HITSP

HITSP and IHE HITSP construct IHE Profile TN900 - Security and Privacy n/a T16 - Consistent Time CT - Consistent Time C19 - Entity Identity Assertion XUA – Cross-Enterprise User Assertion TP30 - Manage Consent Directives BPPC – Basic Patient Privacy Consents T15 - Collect and Communicate Security Audit Trail ATNA – Audit Trail and Node Authentication TP20 - Access Control T17 - Secured Communication Channel C26 - Nonrepudiation of Origin DSG – Document Digital Signature Content Profile TP13 - Manage Sharing of Documents XDS – Cross-Enterprise Document Sharing T31 - Document Reliable Interchange XDR – Cross-Enterprise Document Reliable Interchange T33 - Transfer of Documents on Media XDM – Cross-Enterprise Document Media Interchange T23 - Patient Demographics Query PDQ - Patient Demographics Query TP22 - Patient ID Cross-Referencing PIX - Patient ID Cross-Referencing T29 - Notification of Document Availability NAV – Notification of Document Availability TP21 - Query for Existing Data QED - Query for Existing Data TP50 - Retrieve Form for Data Capture RFD - Retrieve Form for Data Capture

Conclusion

Supported XDS Security Use-Cases Prevent Indiscriminate attacks  Mutual Auth TLS Normal Patient that accepts XDS participation Patient asks for Accounting of Disclosures  informed by ATNA log Protect against malicious neighbor doctor  informed by ATNA log Patient that retracts consent to publish  Repository is local, manual Provider Privacy  User identity is not exposed Malicious Data Mining  queries are all patient based Access to Emergency data set  BPPC policy VIP  XDR/M, BPPC (Local enforcement) Domestic violence victim  BPPC policy (Local enforcement) Daughter with sensitive tests  XDR/M BPPC policy Sensitive topics  Don’t publish, BPPC policy Legal Guardian (cooperative)  BPPC policy (Local enforcement) Care Giver (assists w/ care)  BPPC policy (Local enforcement)

Document Accessibility Entries restricted to sexual health team Private entries shared with GP Entries accessible to administrative staff Entries accessible to clinical in emergency ü Entries accessible to direct care teams Private entries shared with several named parties Entries restricted to prison health service Source: Dipak Kalra & prEN 13606-4

Gaps for potential future development Better coded vocabulary for confidentiality codes Complex policies on a document by document basis Extension to objects other than XDS (e.g. DICOM) Patient Access to Sensitive health topics (you are going to die) Low sensitivity (scheduling) Self monitoring (blood sugar) Authoritative updates / amendments / removal Complex Privacy ‘consent’ Policy capabilities Supporting Inclusion Lists Supporting Exclusion Lists Exceptions, and Obligations Supporting functional role language Access Control Service Centralized Policies Policy Decision Point / Policy Enforcement Points Accounting of Disclosures reports, alerts, messaging To support reporting to the ‘consumer’ when their data is accessed Un-Safe Client machine (home-computer)

Conclusion IHE provides the necessary basic security for XDS today There is room for improvement Roadmap includes prioritized list of use-cases Continuous Risk Assessment is necessary at all levels Product Design Implementation Organizational RHIO Domain

More Information IHE Web Site - http://www.ihe.net Sponsors’ IHE sites Technical Frameworks Technical Framework Supplements – Trial Implementation Calls for Participation IHE Fact Sheet and FAQ IHE Integration Profiles: Guidelines for Buyers IHE Connectathon Results Vendors’ Product Integration Statements Sponsors’ IHE sites http://www.himss.org/IHE http://www.rsna.org/IHE John Moehrke John.Moehrke@med.ge.com