1. IHE Security XDS as a case study
ITI Technical Committee
Aug 3, 2006

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

3. 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
Assume: Current EMR/EHR include Access Controls

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

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

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

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

8. XDS Affinity Domain (NHIN sub-network)
The Really Big Problem
The Registry is not the center, it is just a card catalogue to patient data.
XDS Affinity Domain (NHIN sub-network)
Teaching Hospital
PACS
ED Application
EHR System
Disclosure happens on Export
A Retrieve does result in a permanent copy of the Document.
The Document Consumer does agree to enforce policies forever
XDS Document Registry
XDS Document Repository
Physician Office
EHR System
Query Document
Register Document
Retrieve Document
Provide & Register Docs
PMS

9. Current Solution to Big Problem
Affinity Domain Policy (singular)
All ‘actors’ that participate must agree to enforce these policies
XDS
Patient Centric Queries  Queries result in ONE patient exposed
ATNA
Confidentiality, Integrity, Accountability
Accountability distributed
Access controls at point of care (sensitive to context)
Digital Signature Content Profile (DSIG)
Enhanced locally by
EUA
PWP
Application specific (Not IHE specified)
RBAC, PMAC

10. Accountability XDS Affinity Domain (NHIN sub-network) 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

11. Accountability XDS Affinity Domain (NHIN sub-network)
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
ATNA Audit record repository
Maintain
Time
Community Clinic

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

13. XDS Security Use-Cases
Supported Today
Prevent Indiscriminate attacks (worms)
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
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
VIP  Don’t publish, or use special domain
Domestic violence patient  Don’t publish any
Daughter with sensitive tests  Don’t publish, or use special domain
Sensitive topics  Don’t publish, or use special domain
Legal Guardian (cooperative)  Local enforcement
Care Giver (assists w/ care)  Local enforcement

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

15. XDR / XDM Key Technical Properties
Re-uses XDS approach for documents
SubmissionSet, DocumentEntry
XDS based XML meta-data w. limited extensions
XDR
Secure (ebMS over SMTP, S/MIME)
Optional on-line protocol (similar to XDS)
XDM
PDI like media profile with XDS meta-data
Potential association of XDS and PDI at the actor level (Document Source…)

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

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

18. 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  XDM, BPPC (Local enforcement)
Domestic violence patient  BPPC policy (Local enforcement)
Daughter with sensitive tests  XDM/XDP 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)

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

20. 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
Affinity Domain
TODO: Include Risk Assessment Table and Map

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