1 / 19

XDS Security

XDS Security. ITI Technical Committee May 26, 2006. 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

adonai
Download Presentation

XDS Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Registry Repository A Repository B PIX Service EHR / Browser XDS Document Consumer PDQ Service ATNA Service Identity Svc User Authentication User Interface Business Logic Policy Enforcement RBAC Svc

  9. EHR System ED Application Physician Office PACS EHR System Teaching Hospital 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. • 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 XDSDocument Repository Query Document Register Document Retrieve Document Provide & Register Docs PMS

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

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

More Related