Presentation is loading. Please wait.

Presentation is loading. Please wait.

IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee.

Similar presentations


Presentation on theme: "IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee."— Presentation transcript:

1 IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee July 15, 2008

2 2 Agenda Who is IHE Overall Security Model Deep dive GapsConclusion

3 3 What Is IHE? IHE is a collaborative response to healthcare IT market requirements for system integration. Develop standards-based implementation specifications called profiles. Develop standards-based implementation specifications called profiles. Useful subsets of one or more standards Useful subsets of one or more standards Tested at Connectathons Tested at Connectathons Demonstrated at HIMSS, RSNA, and ACC shows Demonstrated at HIMSS, RSNA, and ACC shows Correct known integration problems. Correct known integration problems. Intra-enterprise and multi-enterprise scope Intra-enterprise and multi-enterprise scope Satisfy emerging market needs & prevent new problems. Satisfy emerging market needs & prevent new problems. EHR & government driven EHR & government driven Regional and national scope Regional and national scope Build trust, collegiality, effectiveness among vendors, providers, and other stakeholders. Build trust, collegiality, effectiveness among vendors, providers, and other stakeholders.

4 4 What is a RHIO? HIMSS: RHIO – A Regional Health Information Organization (RHIO) is a multi-stakeholder organization that enables the exchange and use of health information, in a secure manner, for the purpose of promoting the improvement of health quality, safety and efficiency. Competing enterprises Longitudinal view of the patients health history Protect Privacy Providing better care to patients Promoting Safety and Quality Aka: SNO, HIN, HIE, IHE: Affinity Domain

5 5 Affinity Domain -- Policies International Policies Country-Specific Policies Horizontal Industry Policies Enterprise Policies IHE – leverages/profiles OECD Guidelines On Transborder Flows US-HIPAA EU-EC95/46 JP-Act Medical Professional Societies Backup & Recovery Examples

6 6 RHIO: Document based Persistence, Captures the conclusion / summary of an episode Captures the conclusion / summary of an episodeStewardship, Long term maintenance (patients life 100+ years) Long term maintenance (patients life 100+ years) Potential for Authentication, and Which Doctors conclusion or opinion Which Doctors conclusion or opinion What predicate data or knowledge What predicate data or knowledgeWholeness. Integrity, completeness, inclusive, Integrity, completeness, inclusive,

7 7 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 victim Daughter with sensitive tests hidden from Parent Sensitive topics: mental health, sexual health Legal Guardian (cooperative) Care-Giver (assists w/ care)

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

9 9 RBAC table Sensitivity Functional Role Billing Information Administrativ e Information Dietary Restrictions General Clinical Information Sensitive Clinical Information Research Information Mediated by Direct Care Provider Administrative StaffXX Dietary Staff XX General Care Provider XXX Direct Care Provider XXXX X Emergency Care Provider XXXX X Researcher X Patient or Legal RepresentativeXXXXX

10 10 Document Accessibility Inside EntIn HIE

11 Privacy Controls

12 12 Basic Patient Privacy Consents Abstract The Basic Patient Privacy Consents (BPPC) profile provide mechanisms to: Record the patient privacy consent(s), Record the patient privacy consent(s), Mark documents published to XDS with the choice of patient privacy consent that was used to authorize the publication, Mark documents published to XDS with the choice of patient privacy consent that was used to authorize the publication, Enforce the privacy consent appropriate to the use. Enforce the privacy consent appropriate to the use. Builds upon the ATNA security infrastructure Builds upon the ATNA security infrastructure

13 13 Basic Patient Privacy Consents Value Proposition an Affinity Domain can develop privacy policies, develop privacy policies, and implement them with role-based or other access control mechanisms supported by edge/EHR systems. and implement them with role-based or other access control mechanisms supported by edge/EHR systems. A patient can Be made aware of an institution privacy policies. Be made aware of an institution privacy policies. Have an opportunity to selectively control access to their healthcare information. Have an opportunity to selectively control access to their healthcare information.

14 14 Basic Patient Privacy Consents Standards and Profiles Used Key Properties Human Readable Consents Human Readable Consents Machine Processable Machine Processable Support for standards-based Role-Based Access Control Support for standards-based Role-Based Access ControlStandards CDA Release 2.0 CDA Release 2.0 XDS Scanned Documents XDS Scanned Documents Document Digital Signature Document Digital Signature Cross Enterprise Document Sharing (XDS.a, XDS.b, XDR, and XDM) Cross Enterprise Document Sharing (XDS.a, XDS.b, XDR, and XDM)

15 15 RBAC with Basic Consent

16 16 Basic Consent on an episode basis

17 17 Basic Consent – Extended to HIE

18 18 Basic Consent – Publication controls

19 19 Document Level controls confidentialityCode Must get explicit per-use consent

20 Security Controls

21 21 Community Clinic Lab Info. System PACS Teaching Hospital PACS ED Application EHR System Physician Office EHR System XDS Scenario + use of ATNA & CT PMS Retrieve Document Register Document Query Document XDS Document Registry ATNA Audit record repository CT Time server Record Audit Event MaintainTime MaintainTime Event Maintain Time Provide & Register Docs Record Audit Event XDS Document Repository Secured Messaging

22 22 Community Clinic Lab Info. System PACS Teaching Hospital PACS ED Application EHR System Physician Office EHR System ATNA Security Model(1) PMS XDS Document Registry Provide & Register Docs XDS Document Repository Secured Node XDS Document Repository Dual Authenticated Links

23 23 RHIO boundary Community Clinic Lab Info. System PACS Teaching Hospital PACS ED Application EHR System Physician Office EHR System IHE RHIO Solution PMS Retrieve Document Register Document Query Document XDS Document Registry ATNA Audit record repository CT Time server Provide & Register Docs XDS Document Repository ATNA Audit record repository State run RHIO ATNA Audit record repository Patient ID X-ref

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

25 25 RHIO Domain Policy XDS Affinity Domain Definition Checklist See Template for XDS Affinity Domain Deployment Planning See Template for XDS Affinity Domain Deployment Planning Template for XDS Affinity Domain Deployment Planning Template for XDS Affinity Domain Deployment Planning 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 RHIO 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

26 26 IHE-XDS Infrastructure Components Document Registry (XDS) – Queryable index of metadata and references to all documents shared within a connected community (XDS Affinity Domain) Document Repository (XDS) – Supports storage and retrieval of clinical information (as documents). May be centralized or distributed. Patient Identifier Cross Reference Manager (PIX) – Reconciles information on patients from multiple domains to a single, cross referenced set of IDs for each given patient. Patient Demographics Supplier (PDQ) – Returns demographic information and identifiers for patients based on specified demographic criteria. Audit Record Repository (ATNA) – Receive audit records from other actors and securely store for audit purposes. ATNA also authenticates peer-nodes and encrypt communications. Cross Enterprise User Assertion (XUA) – Mechanism for User Identity federation Basic Patient Privacy Consents (BPPC) – Providing for Patient Privacy dimension of Access control including Capturing Patient Consent including support for Opt-In and Opt-Out Time Server (CT) – Provides consistent definition of date/time enabling time synchronization across multiple systems. Enables events associated with patients to be sorted reliably in chronological order.

27 27 Security & Privacy Controls IHE Profile AccountabilityIdentification andAuthenticationData AccessConfidentialityData IntegrityNon-RepudiationPatient PrivacyAvailability Audit Trails and Node AuthenticationDDDDDDD Basic Patient Privacy ConsentsID Consistent TimeDID Enterprise User AuthenticationIDIIII Cross-Enterprise User AssertionIDIIII Document Digital SignatureDDDD Cross-Enterprise Document SharingDDID Cross-Enterprise Document Reliable MessagingDDID Cross-Enterprise Document exchange on MediaIDDID Personnel White PagesIDDI

28 Identity and Access Control

29 29 Cross-Enterprise User Assertion Value Proposition Extend User Identity to Affinity Domain Users include Providers, Patients, Clerical, etc Users include Providers, Patients, Clerical, etc Must supports cross-enterprise transactions, can be used inside enterprise Must supports cross-enterprise transactions, can be used inside enterprise Distributed or Centralized Identity management (Directories) Distributed or Centralized Identity management (Directories) Provide information necessary so that receiving actors can make Access Control decisions Authentication mechanism used Authentication mechanism used Attributes about the user (roles) Attributes about the user (roles) Does not include Access Control mechanism Does not include Access Control mechanism Provide information necessary so that receiving actors can produce detailed and accurate Security Audit Trail

30 30 Cross-Enterprise User Assertion Technical Solution Initial scope to XDS.b Stored Query and Retrieve Relies on Web-Services Relies on Web-Services Easily extended to any Web-Services transactions Easily extended to any Web-Services transactions Leverage WS-I Basic Security Profile 1.1 Leverage WS-I Basic Security Profile 1.1 Use SAML 2.0 Identity Assertions Does not constrain how the Assertion was obtained Does not constrain how the Assertion was obtained Supporting Liberty Alliance, WS-Trust, and SAML Supporting Liberty Alliance, WS-Trust, and SAML Define grouping behavior with EUA and ATNA

31 31 Four Identity Assurance Levels NIST SP Electronic Authentication technical guidance matches technology to each assurance level OMB E-Authentication Guidance establishes four assurance levels for consistent application of E-Authentication across govt Level 4Level 3Level 2Level 1 Little or no confidence in asserted identity (e.g. self identified user/password) Some confidence in asserted identity (e.g. PIN/Password) High confidence in asserted identity (e.g. digital cert) Very high confidence in the asserted identity (e.g. Smart Card) E-RA tool assists agencies in defining authentication requirements & mapping them to the appropriate assurance level

32 32 Factor Token Very High Medium Low Remote Clinical Entry Verification Of Data Transcription Access to Local EHR/EMR Access to Summary of Clinical research PIN/User ID - Knowledge Strong Password -Based PKI/ Digital Signature Multi- Increased $ Cost Increased Need for Identity Assurance Security Considerations: Four Identity Assurance Levels

33 33 Key: Original Transaction TLS Protections EHR Patient Data XDS Consumer XDS Registry user auth provider Cross-Enterprise User Assertion Implementation Example User Auth (ATNA Secure Node) Audit Log X-Service User X-Identity Provider XUA = Web-Services Security + SAML Assertions XUA Assertion Audit

34 34 Distributed Access Control – enabled by XUA XDS Registry XDS Document Consumer Access Control XDS Registry XDS Document Consumer Access Control Access Control XDS Registry XDS Document Consumer Access Control Access Control Access Control

35 Accountability

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

37 37 RHIO boundary Community Clinic Lab Info. System PACS Teaching Hospital PACS ED Application EHR System Physician Office EHR System Centralized 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

38 38 RHIO boundary Community Clinic Lab Info. System PACS Teaching Hospital PACS ED Application EHR System Physician Office EHR System Distributed 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

39 39 Sjfldjlsdj a Kdjldsj Lsjldjl jfjfjlslkjln Lslasdjj;ask;sls Sflksdjfl;saf Salasaska Faslskf;sf Slsjlsdjlsdjf Lsjflsdjldsjfs Slkfjsdlfjldsf lsjfldsjfldsfj Sjfldjlsdj a Lslasdjj;ask;sls Faslskf;sf lsjfldsjfldsfj Clinic A HIE Infrastructure Audit EMR Example: Audit Log Cascade Inform Disclosure Reports Detect unusual behavior Follow chain back

40 40 Flexible Infrastructure: Sharing, Sending and Interchanging Health Information Exchange or RHIO Publish Pull Structured objects Pull TransactionsWorkflowMgrWorkflowMgr Send to Switch Write Read InterchangeMedia XDS XDR XDM

41 HITSP

42 42 HITSP and IHE HITSP constructIHE Profile TN900 - Security and Privacyn/a T16 - Consistent TimeCT - Consistent Time C19 - Entity Identity AssertionXUA – Cross-Enterprise User Assertion TP30 - Manage Consent DirectivesBPPC – Basic Patient Privacy Consents T15 - Collect and Communicate Security Audit TrailATNA – Audit Trail and Node Authentication TP20 - Access ControlATNA – Audit Trail and Node Authentication T17 - Secured Communication ChannelATNA – Audit Trail and Node Authentication C26 - Nonrepudiation of OriginDSG – Document Digital Signature Content Profile TP13 - Manage Sharing of DocumentsXDS – Cross-Enterprise Document Sharing T31 - Document Reliable InterchangeXDR – Cross-Enterprise Document Reliable Interchange T33 - Transfer of Documents on MediaXDM – Cross-Enterprise Document Media Interchange T23 - Patient Demographics QueryPDQ - Patient Demographics Query TP22 - Patient ID Cross-ReferencingPIX - Patient ID Cross-Referencing T29 - Notification of Document AvailabilityNAV – Notification of Document Availability TP21 - Query for Existing DataQED - Query for Existing Data TP50 - Retrieve Form for Data CaptureRFD - Retrieve Form for Data Capture

43 Conclusion

44 44 Supported XDS Security Use-Cases Prevent Indiscriminate attacks Mutual Auth TLS Normal Patient that accepts XDS participation Patient asks for Accounting of Disclosures informed by ATNA log Protect against malicious neighbor doctor informed by ATNA log Patient that retracts consent to publish Repository is local, manual Provider Privacy User identity is not exposed Malicious Data Mining queries are all patient based Access to Emergency data set BPPC policy VIP XDR/M, BPPC (Local enforcement) Domestic violence victim BPPC policy (Local enforcement) Daughter with sensitive tests XDR/M BPPC policy Sensitive topics Dont publish, BPPC policy Legal Guardian (cooperative) BPPC policy (Local enforcement) Care Giver (assists w/ care) BPPC policy (Local enforcement)

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

46 46 Gaps for potential future development Better coded vocabulary for confidentiality codes Complex policies on a document by document basis Complex policies on a document by document basis Extension to objects other than XDS (e.g. DICOM) Extension to objects other than XDS (e.g. DICOM) 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 Complex Privacy consent Policy capabilities Supporting Inclusion Lists Supporting Inclusion Lists Supporting Exclusion Lists Supporting Exclusion Lists Exceptions, and Obligations Exceptions, and Obligations Supporting functional role language Supporting functional role language Access Control Service Centralized Policies Centralized Policies Policy Decision Point / Policy Enforcement Points Policy Decision Point / Policy Enforcement Points Accounting of Disclosures reports, alerts, messaging To support reporting to the consumer when their data is accessed To support reporting to the consumer when their data is accessed Un-Safe Client machine (home-computer)

47 47 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 RHIO Domain RHIO Domain

48 48 IHE Web Site - Technical Frameworks Technical Frameworks Technical Framework Supplements – Trial Implementation Technical Framework Supplements – Trial Implementation Calls for Participation Calls for Participation IHE Fact Sheet and FAQ IHE Fact Sheet and FAQ IHE Integration Profiles: Guidelines for Buyers IHE Integration Profiles: Guidelines for Buyers IHE Connectathon Results IHE Connectathon Results Vendors Product Integration Statements Vendors Product Integration Statements Sponsors IHE sites John Moehrke More Information


Download ppt "IHE Security XDS as a case study John Moehrke GE Healthcare IHE ITI Technical Committee Member HITSP Co-Chair - Security Privacy and Infrastructure Committee."

Similar presentations


Ads by Google