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
April 7, 2008

2. Agenda Who is IHE Overall Security Model Deep dive HITSP 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. 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. RHIO: Document based Persistence, Stewardship,
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. 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.

8. XDS Scenario + use of ATNA & CT
Physician Office
EHR System
Teaching Hospital
PACS
ED Application
EHR System
PMS
XDS Document Repository
Community Clinic
Lab Info. System
PACS
XDS Document Registry
Query Document
Register Document
Secured Messaging
Lets lift the cover and get a peek into some of the details that enable secured sharing of health records.
Animated, but automatic, only two clicks:
First Click: start placing the three infrastructure components: registry, audit trail repository and cosnsitent time server, then publishes a document and registers it with appropriate security
Second Click: serach documents, retrieve them and impoirt them into the community clinic EMR.
Retrieve Document
Provide & Register Docs
Maintain Time
ATNA Audit record repository
CT Time server
Maintain
Time
Record Audit
Event
Maintain
Time
Record Audit
Event
Record Audit
Event

9. ATNA Security Model(1) Dual Authenticated Links Secured Node
Physician Office
EHR System
Teaching Hospital
PACS
ED Application
EHR System
Dual Authenticated Links
PMS
XDS Document Repository
Community Clinic
Lab Info. System
PACS
XDS Document Registry
XDS Document Repository
Lets lift the cover and get a peek into some of the details that enable secured sharing of health records.
Animated, but automatic, only two clicks:
First Click: start placing the three infrastructure components: registry, audit trail repository and cosnsitent time server, then publishes a document and registers it with appropriate security
Second Click: serach documents, retrieve them and impoirt them into the community clinic EMR.
XDS Document Repository
Provide & Register Docs

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

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

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

13. Security Models Risk Assessment Accountability Policy Enforcement
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

14. RHIO Domain Policy Today there must be ONE set of policies
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 RHIO Domain
EHR RBAC capabilities must be considered
PHR portal must be able to enforce restrictions
Registry / Repositories must only talk to authorized systems
Appendix L: XDS Affinity Domain Definition Checklist
The concept of an XDS Affinity Domain is defined in ITI TF-1:10 and Appendix K. This informative appendix summarizes the key policies that need to be agreed to in order to deploy a EHR-LR document sharing environment.
L.1 Configuration of an XDS Affinity Domain
A number of systems implementing IHE Actors defined in the XDS Integration Profile need to be identified and configured to communicate. This includes defining addressing information and ATNA Secured Node certificate:
1. Identify the system that will support the Document Registry Actor.
2. Identify the systems that will support the Document Repository Actors.
3. Identify the systems that will support Document Source and/or Document Consumer Actors.
L.2 Patient Identification
Initialize the XDS Document Registry (See ITI TF-2:Appendix H) with the proper patient identification information:
1. Assign an Assigning Authority (OID) for the XDS Affinity Domain Patient Id Domain.
2. Assign an Assigning Authorities (OID) for the each one the Local Patient Id Domains in which the EHR-CR Document Source and/or Document Consumer operate.
3. Identify the system that will support the Patient Identity Source and if some of the systems that support Document Source and/or Document Consumer Actors also support a Patient Identity Cross-reference Manager (needs to receive a patient identity feed Transaction).
L.3 XDS Registry Related Vocabularies
Initialize the XDS Document Registry (See ITI TF-2:Appendix H) with the proper vocabulary information:
1. Select and initialize the XDS Document Registry as well as the Document Sources and/or Document Consumers with the vocabulary definitions specified in Registry Enforcement (ITI TF-2: ) where either the Coding Scheme or the Coding Scheme/Code Values are enforced.
L.4 Document Sharing Practice Policies
1. Define the care events and the corresponding expected level of information that is expected to be shared within the EHR-LR.
2. Define the usage policies for XDS Folder (creation and update) in the selected care pathways supported.
L.5 XDS Document Content
1. For each Document Format Code Value, establish the necessary interoperability agreements (e.g. by selecting IHE Document Content Profiles) to ensure that the Document Consumers may find (e.g. Document UniqueId structure) and process the XDS Documents content (e.g. MIME type, template definitions, archetypes, etc.) they retrieve from the XDS Repositories of the XDS Affinity Domain.
L.6 Document Update and Maintenance Policies
Document Sources are responsible for the on-going accuracy (custodianship) of the XDS Documents they have elected to shared in the EHR-LR supported by the Affinity Domain. This includes:
1. Replacement of documents in the EHR-LR
2. Cases and means to possibly delete documents in the EHR-LR
L.7 Security and Privacy Policies
1. Establish agreed policies and procedures among care delivery organizations in the Affinity Domain. In particular address security considerations in ITI TF-2:Appendix K.
2. Establish operational security infrastructure, including certificate exchange.
3. Maintain operational security infrastructure, configuration management, audit management, periodic inspections, etc.

15. Security & Privacy Controls
IHE Profile
Accountability
Identification and Authentication
Data Access
Confidentiality
Data Integrity
Non-Repudiation
Patient Privacy
Availability
Audit Trails and Node Authentication D
Basic Patient Privacy Consents I
Consistent Time
Enterprise User Authentication
Cross-Enterprise User Assertion
Document Digital Signature
Cross-Enterprise Document Sharing
Cross-Enterprise Document Reliable Messaging
Cross-Enterprise Document exchange on Media
Personnel White Pages

16. Identity and Accountability

17. Classic n-Tier Security
Client /
Browser
Application
Server
Database
User Authentication
User Interface
Business Logic
Policy Enforcement
Data Index
Data Values

18. Mapped to XDS Registry Repository A Repository B PIX Service EHR 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

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

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

21. Four Identity Assurance Levels
OMB E-Authentication Guidance establishes
four assurance levels for
consistent application of E-Authentication
across gov’t
Level 4
Level 3
Level 2
Level 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
NIST SP800-63
Electronic
Authentication
technical guidance
matches technology
to each assurance level
Slide c/o David Temoshok and GSA

22. 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
Slide c/o David Temoshok and GSA
Access to
Summary of
Clinical research
Access to
Local
EHR/EMR
Verification
Of Data
Transcription
Remote
Clinical
Entry
Increased Need for Identity Assurance

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

24. 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
The ATNA audit log includes enough information to detect a potential problem. Where enough information is not available in ATNA, the results can be used to enable forensic logs if they are available.
The ATNA Audit Repository must protect the audit log appropriately, and provide the necessary tools to enable the necessary functionality and reporting.

25. ATNA Audit record repository ATNA Audit record repository
Accountability
RHIO boundary
Physician Office
EHR System
PMS
ED Application
XDS Document Repository
XDS Document Registry
PACS
Query Document
Register Document
Explain the link between audit logs and accountability.
EHR System
PACS
Retrieve Document
Provide & Register Docs
ATNA Audit record repository
Maintain Time
Lab Info. System
ATNA Audit record repository
CT Time server
Maintain
Time
Teaching Hospital
Maintain
Time
Community Clinic

26. Accountability RHIO boundary Teaching Hospital State run RHIO
Physician Office
EHR System
Teaching Hospital
State run RHIO
PMS
ED Application
XDS Document Repository
XDS Document Registry
PACS
Query Document
Register Document
Explain the link between audit logs and accountability.
EHR System
PACS
Retrieve Document
Provide & Register Docs
ATNA Audit record repository
Maintain Time
Lab Info. System
ATNA Audit record repository
CT Time server
Maintain
Time
Maintain
Time
ATNA Audit record repository
Community Clinic

27. Example: Audit Log Cascade
Clinic A
EMR
Kdjldsj
Sjfldjlsdj a
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
Inform Disclosure Reports
Detect unusual behavior  Follow chain back

28. Privacy Controls

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

30. Basic Patient Privacy Consents Value 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.

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

32. Basic Patient Privacy Consents Example
Log-in= local role R3 R3=Consent A&B
Query
Retrieve
RHIO XDS Doc Registry/Repositories
Consent A
Consent B
Register
Encounter 2 (Patient OK with B)
Register
Log-in= local role R1 R1=Consent B
Encounter 1 (Patient Requires A)

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

34. HITSP

35. HITSP and IHE HITSP construct IHE Profile TN900 - Security and Privacy
n/a
T16 - Consistent Time
CT - Consistent Time
C19 - Entity Identity Assertion
XUA – Cross-Enterprise User Assertion
TP30 - Manage Consent Directives
BPPC – Basic Patient Privacy Consents
T15 - Collect and Communicate Security Audit Trail
ATNA – Audit Trail and Node Authentication
TP20 - Access Control
T17 - Secured Communication Channel
C26 - Nonrepudiation of Origin
DSG – Document Digital Signature Content Profile
TP13 - Manage Sharing of Documents
XDS – Cross-Enterprise Document Sharing
T31 - Document Reliable Interchange
XDR – Cross-Enterprise Document Reliable Interchange
T33 - Transfer of Documents on Media
XDM – Cross-Enterprise Document Media Interchange
T23 - Patient Demographics Query
PDQ - Patient Demographics Query
TP22 - Patient ID Cross-Referencing
PIX - Patient ID Cross-Referencing
T29 - Notification of Document Availability
NAV – Notification of Document Availability
TP21 - Query for Existing Data
QED - Query for Existing Data
TP50 - Retrieve Form for Data Capture
RFD - Retrieve Form for Data Capture

36. Conclusion

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

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

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

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

41. More Information IHE Web Site - http://www.ihe.net Sponsors’ IHE sites
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