1 / 18

XDS Security

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

quant
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 27, 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 • 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)

  3. Document Accessibility Source: prEN 13606-4

  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. Security Models • Risk Assessment • 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

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

  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- Workstation Browser EHR System PHR Portal PDQ Service XDS Consumer 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) • Digital Signature Content Profile (DSIG) • Enhanced locally by • EUA • PWP • 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. EHR System Physician Office XDS Document Repository XDSDocument Repository ATNA Audit record repository CT Time server ATNA Audit record repository ATNA Audit record repository XDS Affinity Domain (NHIN sub-network) Accountability Teaching Hospital State run RHIO 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 Maintain Time Community Clinic

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

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

  15. Next Problem ü Source: prEN 13606-4

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

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

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