1. XDS Security ITI Technical Committee May 26, 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 hidden from Parent Sensitive topics: mental health, sexual health Guardian (cooperative)

3. Document Accessibility Source: prEN 13606-4

4. Security Models Security protects Assets  The information in Registry & all Repositories  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

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

6. Affinity Domain Policy Today there must be ONE policy IHE gives no direction on the content of this Policy Policy must be enforceable by all the participants in the Affinity Domain  E.g. EHR RBAC capabilities must be considered See IHE TF Volume 1: Appendix L: XDS Affinity Domain Definition Checklist

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

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

9. 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 B)Disclosure happens on Export Physician Office EHR System C)A Retrieve does result in a permanent copy of the Document. D)The Document Consumer does agree to enforce policies forever A)The Registry is not the center, it is just a card catalogue to patient data.

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

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

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

13. 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  Emergency access 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  Guardian (cooperative)  Local enforcement

14. Next Problem Source: prEN 13606-4

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

16. Future possible topics 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)

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

18. Profile Template Security Considerations

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