IHE Security XDS as a case study

1. IHE SecurityXDS 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. Agenda • Who is IHE • Overall Security Model • Deep dive • Gaps • Conclusion

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

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 patient’s health history • Protect Privacy • Providing better care to patients • Promoting Safety and Quality Aka: SNO, HIN, HIE, IHE: Affinity Domain

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

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

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. Entries restricted tosexual health team Private entriesshared with GP Entries accessible toadministrative staff Entries accessible toclinical in emergency Entries accessible todirect care teams Private entriesshared with severalnamed parties Entries restricted toprison health service Document Accessibility Source: Dipak Kalra & prEN 13606-4

9. RBAC table

10. Document Accessibility Inside Ent In HIE

11. Privacy Controls

12. Basic Patient Privacy ConsentsAbstract • The Basic Patient Privacy Consents (BPPC) profile provide mechanisms to: • 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, • Enforce the privacy consent appropriate to the use. • Builds upon the ATNA security infrastructure

13. Basic Patient Privacy ConsentsValue Proposition • an Affinity Domain can • develop privacy policies, • 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. • Have an opportunity to selectively control access to their healthcare information.

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

15. RBAC with Basic Consent

16. Basic Consent on an episode basis

17. Basic Consent – Extended to HIE

18. Basic Consent – Publication controls

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

20. Security Controls

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

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

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

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

25. RHIO Domain Policy • XDS Affinity Domain Definition Checklist • See Template for XDS Affinity Domain Deployment Planning • 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 RHIO Domain • EHR RBAC capabilities must be considered • PHR portal must be able to enforce restrictions • Registry / Repositories must only talk to authorized systems

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.

28. Identity and Access Control

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

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

31. OMB E-Authentication Guidance establishes four assurance levels for consistent application of E-Authentication across gov’t Level 1 Level 2 Level 3 Level 4 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) Four Identity Assurance Levels E-RA tool assists agencies in defining authentication requirements & mapping them to the appropriate assurance level NIST SP800-63 Electronic Authentication technical guidance matches technology to each assurance level

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

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

34. Distributed Access Control – enabled by XUA A XDS Registry XDS Document Consumer Access Control B XDS Registry XDS Document Consumer Access Control Access Control C XDS Registry XDS Document Consumer Access Control Access Control Access Control

35. Accountability

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

37. EHR System Physician Office XDS Document Repository XDSDocument Repository ATNA Audit record repository CT Time server RHIO boundary Centralized 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

38. EHR System Physician Office XDS Document Repository XDSDocument Repository ATNA Audit record repository CT Time server ATNA Audit record repository ATNA Audit record repository RHIO boundary Distributed 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

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

40. Send to Send to Switch Interchange Media Write Read Workflow Mgr Workflow Mgr Transactions Flexible Infrastructure: Sharing, Sending and Interchanging Health Information Exchange or RHIO XDS Structuredobjects Pull Publish Pull XDR XDM

41. Conclusion

42. 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  Don’t publish, BPPC policy • Legal Guardian (cooperative)  BPPC policy (Local enforcement) • Care Giver (assists w/ care)  BPPC policy (Local enforcement)

43. Document Accessibility Entries restricted tosexual health team Private entriesshared with GP Entries accessible toadministrative staff Entries accessible toclinical in emergency ü Entries accessible todirect care teams Private entriesshared with severalnamed parties Entries restricted toprison health service Source: Dipak Kalra & prEN 13606-4

44. Gaps for potential future development • Better coded vocabulary for confidentiality codes • Complex policies on a document by document basis • Extension to objects other than XDS (e.g. DICOM) • Patient Access to • Sensitive health topics (you are going to die) • Low sensitivity (scheduling) • Self monitoring (blood sugar) • Authoritative updates / amendments / removal • Complex Privacy ‘consent’ Policy capabilities • Supporting Inclusion Lists • Supporting Exclusion Lists • Exceptions, and Obligations • Supporting functional role language • Access Control Service • Centralized Policies • Policy Decision Point / Policy Enforcement Points • Accounting of Disclosures reports, alerts, messaging • To support reporting to the ‘consumer’ when their data is accessed • Un-Safe Client machine (home-computer)

45. 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 • RHIO Domain

46. IHE Web Site - http://www.ihe.net Technical Frameworks Technical Framework Supplements – Trial Implementation Calls for Participation IHE Fact Sheet and FAQ IHE Integration Profiles: Guidelines for Buyers IHE Connectathon Results Vendors’ Product Integration Statements Sponsors’ IHE sites http://www.himss.org/IHE http://www.rsna.org/IHE John Moehrke John.Moehrke@med.ge.com More Information