IHE Security and Privacy John Moehrke GE Healthcare IHE ITI Technical Committee Member March 6, 2011

2 Agenda Overall Security and Privacy controls ATNAEUAXUA Access Control BPPCGapsConclusion

3 What Is IHE? TBD

4 Layers of 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

5 Security Mis-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)

6 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

7 Security & Privacy Controls IHE Profile Profile Issued AccountabilityIdentification andAuthenticationData AccessControlConfidentialityData IntegrityNon-RepudiationPatient PrivacyAvailability Audit Trails and Node Authentication2004√√√√√√√ Consistent Time2003√∙√ Enterprise User Authentication2003∙√∙∙∙∙ Cross-Enterprise User Assertion2006∙√∙∙∙∙ Basic Patient Privacy Consents2006∙√ Document Digital Signature2005√√√√ Personnel White Pages2004∙√√∙ Healthcare Provider Directory2010∙∙∙∙ Document Encryption2011√√∙

AUDIT TRAIL AND NODE AUTHENTICATION (ATNA) 8

ATNA: Audit Trail and Node Authentication Profile Secure Node or Secure Application Access Controls  Functional – can be shown to enforce policies Audit Controls  SYSLOG + IHE/DICOM/RFC3881 Audit Message  Auditable Events Network Controls  Mutually Authenticated TLS  Or S/MIME or WS-Security or physical isolation 9

10 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

11 Audit Log - 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

12 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

13 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

14 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

ENTERPRISE USER AUTHENTICATION 15

Enterprise User Authentication Scope Support a single enterprise governed by a single set of security policies and having a common network domain. Establish one name per user to be used for all IT applications and devices. Facilitate centralized user authentication management. Provide users with single sign-on.

Sept 13-15, 2004 IHE Interoperabi lity Workshop 17 Enterprise User Authentication Value Proposition Meet a basic security requirement  User authentication is necessary for most applications and data access operations. Achieve cost savings/containment  Centralize user authentication management  Simplify multi-vendor implementations Provide workflow improvement for users  Increase user acceptance through simplicity  Decrease user task-switching time. More effective security protection  Consistency and simplicity yields greater assurance.

Sept 13-15, 2004 IHE Interoperabi lity Workshop 18 Consistent Time Scope and Value Proposition Meet a basic security requirement  System clocks and time stamps of the many computers in a network must be synchronized.  Lack of consistent time creates a “security hole” for attackers.  Synchronization ±1 second is generally sufficient. Achieve cost savings/containment  Use the Network Time Protocol (NTP) standard defined in RFC  Leverage exisisting Internet NTP services, a set-up option for mainstream operating systems.

Sept 13-15, 2004 IHE Interoperabi lity Workshop 19 Enterprise User Authentication Key Attributes Limited network overhead  Kerberos is network-efficient, developed at a time when high-speed networks were rare. Kerberos work with any user authentication technology  Tokens, biometric technologies, smart cards, …  Specific implementations require some proprietary components, e.g., biometric devices.  Once user authentication is complete, network transactions are the same for all technologies.

Sept 13-15, 2004 IHE Interoperabi lity Workshop 20 EUA and CT Key Technical Properties Standards Used  Kerberos v5 (RFC 1510) Stable since 1993, Stable since 1993, Widely implemented on current operating system platforms Widely implemented on current operating system platforms Successfully withstood attacks in its 10-year history Successfully withstood attacks in its 10-year history Fully interoperable among all platforms Fully interoperable among all platforms  Network Time Protocol (RFC 1305) Minimal Application Changes  Eliminate application-specific, non-interoperable authentication  Replace less secure proprietary security techniques  Leverage NTP interfaces built-into operating systems

Sept 13-15, 2004 IHE Interoperabi lity Workshop 21 Enterprise User Authentication Transaction Diagram

Sept 13-15, 2004 IHE Interoperabi lity Workshop 22 Consistent Time Transaction Diagram Maintain Time [ITI-1]↑ Time Server Time Client

Sept 13-15, 2004 IHE Interoperabi lity Workshop 23 Enterprise User Authentication Kerberos Authentication Kerberos Server “kinit” Cache Request TGT Response (contains TGT) application TGT Request Service ticket Response with Service Ticket Application server Protocol specific communication, using Service Ticket as authenticator Communication Initiated Initial username, password Single System Environment

Sept 13-15, 2004 IHE Interoperabi lity Workshop 24 Enterprise User Authentication HTTP Authentication Client Authentication Agent HTTP Client HTTP Kerberized Server Kerberos Authentication Server Start HTTP Session HTTP Get – with no authentication. 401 response (WWW Authenticate: Negotiate) Get Kerberos Service Ticket Service Ticket HTTP Get – Kerberized Communication HTTP Response

CROSS-ENTERPRISE USER ASSERTION (XUA) 25

26 Cross-Enterprise User Assertion Value 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

27 Cross-Enterprise User Assertion Technical 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

XUA encoded in Web- Services

29 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 gov’t 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

30 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

XUA Actors

32 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

ACCESS CONTROLS - SECURITY 33

34 Role-Based-Access-Control Sensitivity Functional Role Billing Information Administrative Information General Clinical Information Sensitive Clinical Information Research Information Mediated by Direct Care Provider HL7 confidentialityCode ( )LNDRVT Administrative StaffXX Dietary Staff X General Care Provider XX Direct Care Provider XXX X Emergency Care Provider (e.g. EMT) X Researcher X Patient or Legal RepresentativeXXXX

35 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

BASIC PATIENT PRIVACY CONSENT (BPPC)

37 Basic Patient Privacy Consents Abstract 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

38 Basic Patient Privacy Consents Value Proposition A Privacy Domain (e.g. XDS Affinity Domain)  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.

39 Basic Patient Privacy Consents Standards 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)

40 OPT-IN  Share normally Sensitivity Functional Role Billing Information Administrative Information General Clinical Information Sensitive Clinical Information Research Information Mediated by Direct Care Provider HL7 confidentialityCode ( )LNDRVT Administrative StaffXX Dietary Staff X General Care Provider XX Direct Care Provider XXX X Emergency Care Provider (e.g. EMT) X Researcher X Patient or Legal RepresentativeXXXX

41 OPT-OUT  Only Direct Care Sensitivity Functional Role Billing Information Administrative Information General Clinical Information Sensitive Clinical Information Research Information Mediated by Direct Care Provider HL7 confidentialityCode ( )LNDRVT Administrative Staff Dietary Staff General Care Provider Direct Care Provider X Emergency Care Provider (e.g. EMT) * Researcher Patient or Legal RepresentativeXXXX * Only in case of risk to Life-or-Limb == Break-Glass

42 RBAC with Basic Consent

43 Basic Consent – Multiple Consents on file Enable Specific Research Study Normal HIE Opt-In

BPPC Enables Basic Opt-In or Basic Opt-Out Specific cases  authorize a specific use Control Use or Publication  Existence of Opt-Out could forbid publication  Typically Normal data is always published and control is on use of the data Time based Consent  Episodic Consent Site specific Consent 44

ETCETERA 45

Other Profiles of Interest Document Digital Signature (DSG)   Non-Repudiation of Document Personnel White Pages (PWP)   Organizational Directory of Users Healthcare Provider Directory (HPD)   External Directory of Individuals and Organizations Document Encryption (DEC)   Encryption of Documents 46

Conclusion

48 Supported Security Mis-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)

49 Security & Privacy Controls IHE Profile Profile Issued AccountabilityIdentification andAuthenticationData AccessControlConfidentialityData IntegrityNon-RepudiationPatient PrivacyAvailability Audit Trails and Node Authentication2004√√√√√√√ Consistent Time2003√∙√ Enterprise User Authentication2003∙√∙∙∙∙ Cross-Enterprise User Assertion2006∙√∙∙∙∙ Basic Patient Privacy Consents2006∙√ Document Digital Signature2005√√√√ Personnel White Pages2004∙√√∙ Healthcare Provider Directory2010∙∙∙∙ Document Encryption2011√√∙

50 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)

51 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

52 IHE Web Site -  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   John Moehrke  More Information