IHE Security XDS as a case study ITI Technical Committee Aug 3, 2006

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

Privacy Needs Protect against inappropriate disclosure Provide an Accounting of Disclosures Protect employee privacy Resulting in compliance with Laws and Regulations by the Legal Entity Assume: Current EMR/EHR include Access Controls

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 patient 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 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

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

Affinity Domain Policy Today there must be ONE policy See IHE TF Volume 1: Appendix L: XDS Affinity Domain Definition Checklist 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 Affinity 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.

XDS Affinity Domain (NHIN sub-network) The Really Big Problem The Registry is not the center, it is just a card catalogue to patient data. XDS Affinity Domain (NHIN sub-network) Teaching Hospital PACS ED Application EHR System Disclosure happens on Export A Retrieve does result in a permanent copy of the Document. The Document Consumer does agree to enforce policies forever XDS Document Registry XDS Document Repository Physician Office EHR System Query Document Register Document Retrieve Document Provide & Register Docs PMS

Current Solution to Big Problem Affinity Domain Policy (singular) All ‘actors’ that participate must agree to enforce these policies XDS Patient Centric Queries  Queries result in ONE patient exposed ATNA Confidentiality, Integrity, Accountability Accountability distributed Access controls at point of care (sensitive to context) Digital Signature Content Profile (DSIG) Enhanced locally by EUA PWP Application specific (Not IHE specified) RBAC, PMAC

Accountability XDS Affinity Domain (NHIN sub-network) 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 ATNA Audit record repository Maintain Time Lab Info. System ATNA Audit record repository CT Time server Maintain Time Teaching Hospital Maintain Time Community Clinic

Accountability XDS Affinity Domain (NHIN sub-network) 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 ATNA Audit record repository Maintain Time Community Clinic

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.

XDS Security Use-Cases Supported Today Prevent Indiscriminate attacks (worms) 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 Not directly supported with IHE technology (applications can provide this functionality in their feature e.g. Portals) Access to Emergency data set  all XDS open, or no access VIP  Don’t publish, or use special domain Domestic violence patient  Don’t publish any Daughter with sensitive tests  Don’t publish, or use special domain Sensitive topics  Don’t publish, or use special domain Legal Guardian (cooperative)  Local enforcement Care Giver (assists w/ care)  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

XDR / XDM Key Technical Properties Re-uses XDS approach for documents SubmissionSet, DocumentEntry XDS based XML meta-data w. limited extensions XDR Secure e-mail (ebMS over SMTP, S/MIME) Optional on-line protocol (similar to XDS) XDM PDI like media profile with XDS meta-data Potential association of XDS and PDI at the actor level (Document Source…)

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

Next Year Solution IHE-PCC PCC – Basic lists of Patient Consents Small number of Basic Consents the patient could choose from (about 10) Additive in nature, so it is clear which is most restrictive Supporting Emergency Data Set, Clerical Data Set, Direct Caregiver Data Set. Could include excluding/including organizations (enforced by Registry/Repository based on Node Certs) Enables more than one Policy to be defined and claimed Captured document with patient signature FormatCode identifies the document that captures the event Coded identifier to enable automated enforcement Enables data to be marked as to be controlled by a specific policy (Confidentiality Code) New XDS query can limit query results to those that match policy (Confidentiality Code) requested

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  XDM, BPPC (Local enforcement) Domestic violence patient  BPPC policy (Local enforcement) Daughter with sensitive tests  XDM/XDP 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)

Future possible topics Federated User Identity (XUA) Patient Access to Sensitive health topics (you are going to die) Low sensitivity (scheduling) Self monitoring (blood sugar) Authoritative updates / amendments / removal Centralized Policy capabilities Suggested Policies Supporting Inclusion Lists Supporting Exclusion Lists Supporting functional role language Central Policy Decision Point Note: Continued distributed Policy Enforcement Point near patient 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 Affinity Domain TODO: Include Risk Assessment Table and Map

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 http://www.acc.org/quality/ihe.htm John Moehrke John.Moehrke@med.ge.com