1. XDS Security ITI Technical Committee May, 2006

2. 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 Emergency access data set VIP (movie star, sports figure) Domestic violence patient Daughter with sensitive tests, mental health, sexual health Guardian (cooperative)

3. Security Models Security protects Assets  In XDS the asset is the information in Reg & all Rep(s)  Confidentiality, Integrity, and Availability  Patient Safety trumps privacy (most of the time) Accountability options  Access Control model  Audit Control model Policy Enforcement options  Mutually agree to enforce Policies  Enforcement of policies centrally

4. 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

5. Affinity Domain Policy Today there must be ONE policy Etc…

6. Classic n-Tier Security Client / Browser Application Server Database User Authentication User Interface Business Logic Policy Enforcement Data Index Data Values

7. Mapped to XDS EHR / Browser XDS Document Consumer Registry User Authentication User Interface Business Logic Policy Enforcement Repository A Repository B PIX Service PDQ Service ATNA Service Identity Svc RBAC Svc

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

9. 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) Enhanced locally by  EUA  PWP  DSIG Application specific (Not IHE specified)  RBAC, PMAC

10. XDS Affinity Domain (NHIN sub-network) Community Clinic Lab Info. System PACS Teaching Hospital PACS ED Application EHR System Physician Office EHR System Accountability PMS Retrieve Document Register Document Query Document XDS Document Registry ATNA Audit record repository CT Time server MaintainTime MaintainTime Maintain Time Provide & Register Docs XDS Document Repository ATNA Audit record repository

11. 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 Support an Accounting of Disclosures  ATNA Report: XDS-Export + XDS-Import

12. XDS Security Use-Cases Supported Today  Prevent Indiscriminate attacks (worms)  Normal Patient that accepts XDS participation  Patient asks for Accounting of Disclosures  Patient that retracts consent to publish  Protect against malicious neighbor doctor  Provider Privacy Not directly supported with IHE technology  Emergency access data set  all XDS open, or no access  VIP  Don’t publish, or make special XDS  Domestic violence patient  Don’t publish any  Daughter with sensitive tests  Don’t publish, or make special XDS  Guardian (cooperative)  Local enforcement

13. Next Problem

14. Next Year Solution PCC – Basic Patient Consents enable the YELLOW policies  Enables more than one Policy to be defined and claimed Captured document with patient signature Captured document with patient signature Coded identifier to enable automated enforcement Coded identifier to enable automated enforcement  Enables data to be marked as to be controlled by a specific policy (Confidentiality Code)  Supporting Emergency Data Set, Clerical Data Set, Direct Caregiver Data Set.  ***Need query extensions to limit query results to those that match policy (Confidentiality Code) requested XDP  Can be used to handle sensitive data or sensitive patients

15. 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

16. Profile Security Considerations Volume 1 – Last section of the Profile description Volume 2 – Section for each Transaction Section Contents  Statement that a risk assessment has been done and is maintained in the IHE Risk Repository  Pre-Conditions – the expected environmental factors  Profile Specific Mitigations  Profile Unresolved Risks to be mitigated downstream