1 / 16

XDS Security

XDS Security. ITI Technical Committee May, 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 Patient that retracts consent to publish

ordell
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, 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 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

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

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

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

More Related