Presentation is loading. Please wait.

Presentation is loading. Please wait.

XDS Security ITI Technical Committee May 27, 2006.

Similar presentations


Presentation on theme: "XDS Security ITI Technical Committee May 27, 2006."— 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 Private entries shared with GP Private entries shared with several named parties Entries restricted to sexual health team Entries restricted to prison health service Entries accessible to administrative staff Entries accessible to direct care teams Document Accessibility Source: Dipak Kalra & prEN 13606-4 Entries accessible to clinical in emergency

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 Asset is the information in Registry & all Repositories Confidentiality, Integrity, and Availability Confidentiality, Integrity, and Availability Patient Safety overrides privacy (most of the time) Patient Safety overrides privacy (most of the time)Accountability Access Control model -- Prevention Access Control model -- Prevention Audit Control model -- Reaction Audit Control model -- Reaction Policy Enforcement Mutually agree to enforce Policies Mutually agree to enforce Policies Enforcement of policies centrally 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 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. 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 EHR RBAC capabilities must be considered PHR portal must be able to enforce restrictions PHR portal must be able to enforce restrictions Registry / Repositories must only talk to authorized systems 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 EHR- Workstation Browser EHR System PHR Portal Registry User Authentication User Interface Business Logic Policy Enforcement Repository A Repository B PIX Service PDQ Service ATNA Service Identity Svc RBAC Svc XDS Consumer

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 All actors that participate must agree to enforce these policiesXDS Patient Centric Queries Queries result in ONE patient exposed Patient Centric Queries Queries result in ONE patient exposedATNA Confidentiality, Integrity, Accountability Confidentiality, Integrity, Accountability Accountability distributed Accountability distributed Access controls at point of care (sensitive to context) Access controls at point of care (sensitive to context) Digital Signature Content Profile (DSIG) Enhanced locally by EUA EUA PWP PWP Application specific (Not IHE specified) RBAC, PMAC 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 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 State run RHIO ATNA Audit record repository

13 Todays XDS Accountability Mitigation against unauthorized use Investigate Audit log for patterns and behavior outside policy. Enforce policy 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 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 Investigate Audit log for specific evidence ATNA Audit Repositories can filter and auto-forward ATNA Audit Repositories can filter and auto-forward Support an Accounting of Disclosures ATNA Report: XDS-Export + XDS-Import ATNA Report: XDS-Export + XDS-Import

14 XDS Security Use-Cases Supported Today Prevent Indiscriminate attacks (worms) Prevent Indiscriminate attacks (worms) Normal Patient that accepts XDS participation Normal Patient that accepts XDS participation Patient asks for Accounting of Disclosures Patient asks for Accounting of Disclosures Protect against malicious neighbor doctor Protect against malicious neighbor doctor Patient that retracts consent to publish Patient that retracts consent to publish Provider Privacy Provider Privacy Malicious Data Mining 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 Access to Emergency data set all XDS open, or no access VIP Dont publish, or use special domain VIP Dont publish, or use special domain Domestic violence patient Dont publish any Domestic violence patient Dont publish any Daughter with sensitive tests Dont publish, or use special domain Daughter with sensitive tests Dont publish, or use special domain Sensitive topics Dont publish, or use special domain Sensitive topics Dont publish, or use special domain Legal Guardian (cooperative) Local enforcement Legal Guardian (cooperative) Local enforcement Care Giver (assists w/ care) Local enforcement Care Giver (assists w/ care) Local enforcement

15 Private entries shared with GP Private entries shared with several named parties Entries restricted to sexual health team Entries restricted to prison health service Entries accessible to administrative staff Entries accessible to clinical in emergency Entries accessible to direct care teams Document Accessibility Source: Dipak Kalra & prEN 13606-4

16 Next Year Solution IHE-ITI XDP – Cross-Enterprise Document Point-to-Point Interchange Can be used to handle sensitive data or sensitive patients Can be used to handle sensitive data or sensitive patients Point to Point communications of documents Point to Point communications of documents Email – using S/MIME to target the documents to a specific individual Email – using S/MIME to target the documents to a specific individual Media – carried by authorized/bonded courier Media – carried by authorized/bonded courier

17 Next Year Solution IHE-PCC PCC – Basic lists of Patient Consents Small number of Basic Consents the patient could choose from (about 10) Small number of Basic Consents the patient could choose from (about 10) Additive in nature, so it is clear which is most restrictive Additive in nature, so it is clear which is most restrictive Supporting Emergency Data Set, Clerical Data Set, Direct Caregiver Data Set. Supporting Emergency Data Set, Clerical Data Set, Direct Caregiver Data Set. Could include excluding/including organizations (enforced by Registry/Repository based on Node Certs) Could include excluding/including organizations (enforced by Registry/Repository based on Node Certs) Enables more than one Policy to be defined and claimed Enables more than one Policy to be defined and claimed Captured document with patient signature Captured document with patient signature –FormatCode identifies the document that captures the event 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) Enables data to be marked as to be controlled by a specific policy (Confidentiality Code) ***Need query extensions to limit query results to those that match policy (Confidentiality Code) requested ***Need query extensions to limit query results to those that match policy (Confidentiality Code) requested

18 Future possible topics Federated User Identity (XUA) Patient Access to Sensitive health topics (you are going to die) Sensitive health topics (you are going to die) Low sensitivity (scheduling) Low sensitivity (scheduling) Self monitoring (blood sugar) Self monitoring (blood sugar) Authoritative updates / amendments / removal Authoritative updates / amendments / removal Centralized Policy capabilities Suggested Policies Suggested Policies Supporting Inclusion Lists Supporting Inclusion Lists Supporting Exclusion Lists Supporting Exclusion Lists Supporting functional role language Supporting functional role language Central Policy Decision Point Note: Continued distributed Policy Enforcement Point near patient Note: Continued distributed Policy Enforcement Point near patient Un-Safe Client machine (home-computer)

19 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 Product Design Implementation Implementation Organizational Organizational Affinity Domain Affinity Domain TODO: Include Risk Assessment Table and Map


Download ppt "XDS Security ITI Technical Committee May 27, 2006."

Similar presentations


Ads by Google