Chris Lindop GE Healthcare, IHE-International, IHE-Radiology Co-Chair (Wednesday, Interoperability Reference Architecture Workshop)

1. XDS
Cross-Enterprise Document Sharing

2. Health Document Exchange Options
Flexible Infrastructure
XDS
XDS INFRASTRUCTURE
M8354673993
Publish L-716 A87631
14355 Query/Retrieve
XDR Existing Reliable
Send to Messaging System Send to
Interchange Media
XDM
Read
Write Including Email
XCA
XCA INFRASTRUCTURE
M8354673993
L-716 A87631
14355 Query/Retrieve
2

3. What is XDS ?
The Cross-Enterprise Document Sharing
(XDS)
IHE Integration Profile facilitates the
registration, distribution and access across
health enterprises of patient electronic
health records
It provides a standards-based specification
for managing the sharing of documents
between any healthcare enterprise
3

4. XDS Affinity Domains
Group of healthcare enterprises that have agreed to work together using
a common set of policies and XDS-based infrastructures for sharing
patient clinical documents. Some examples are:
Regional community of care
Nationwide EHR
Specialized or disease-oriented (cardio, diabetes, oncology)
Government-sponsored or federation of enterprises
Insurance provider supported communities
XDS profile is designed to accommodate a wide range of policies on:
Patient identification and consent
Controlling access to information
Format, content, structure, and representation of clinical information
4

5. Use Cases
Patient Care Summary (e.g. within a region)
 Publishing of Care Summaries by providers
 Access to patient‟s Care Summary in an emergency
eReferral between primary and secondary care
providers
Sharing of radiology reports and images between
facilities
Sharing of laboratory reports by clinical laboratories
with ordering physicians and other care providers
ePharmacy between community pharmacy and
ambulatory physicians
5

6. Main Systems and Responsibilities
A document Repository is responsible for storing documents in a
transparent, secure, reliable and persistent manner and
responding to document retrieval requests.
A document Registry is responsible for storing information or
metadata about those documents so that the documents of
interest for the care of a patient may be easily found, selected and
retrieved irrespective of the repository where they are actually
stored.
Any IT system (e.g. point of care) may act as a Document Sources
or Document Consumers submitting documents for registration,
or querying/retrieving relevant documents.
Notes:
Analogous to a library (book repository) and catalog/index
The Registry does not have access to the documents – an important separation from security and
privacy perspective
Multiple Repositories can be linked to one Registry
6

7. XDS Flow and Interactions
XDS Document
(Metadata): Registry 3. Consumers search Consumer
Class for documents with
Patient Id specific information
Author
Facility
Date of Service
…
2. Repository registers
the documents
metadata and pointer
with the Registry
4. Consumers retrieve
selected documents
from Repository (-ies)
1. Sources post
document packages
Source of to the Repository
Documents Repository
7

8. XDS Transaction Diagram
Patient Identity
Source
Patient Identity Feed [ITI-8]
Patient Identity Feed HL7v3 [ITI-44]
Registry Stored Query [ITI-18]
Document Document
Registry Consumer
Register Document Set-b [ITI-42]
Retrieve Document Set [ITI-43]
Document Document
Source Provide&Register Repository
Document Set-b [ITI-41]
Integrated Document Source/Repository
8

9. XDS Actors
Document Source – producer and publisher of documents, responsible for
sending documents and their metadata to a Document Repository actor
Document Repository is responsible for both the persistent storage of
these documents as well as for their registration with the appropriate
Document Registry
Document Registry maintains metadata about each registered document
and a link to the Document in the Repository where it is stored. Responds
to queries from Document Consumer actors about documents meeting
specific criteria.
Document Consumer queries a Document Registry for documents meeting
certain criteria, and retrieves selected documents from one or more
Document Repository actors
Patient Identity Source provides unique identifier for each patient and
maintaining a collection of identity traits. This facilitates the validation of
patient identifiers by the Registry Actor in its interactions with other actors
Integrated Document Source/Repository combines the functionality of the
Document Source and Document Repository actors into a single actor that
does not expose the Provide and Register Document Set transaction
9

10. XDS Transactions (1)
Provide and Register Document Set – For each
document in the submitted set, the Document Source
Actor provides both the documents as an opaque
octet stream and the corresponding metadata to the
Document Repository. The Document Repository is
responsible to persistently store these documents,
and to register them in the Document Registry using
the Register Documents transaction.
Register Document Set allows a Document Repository
Actor to register one or more documents with a
Document Registry, by supplying metadata about
each document to be registered. This document
metadata will be used to create an XDS Document
Entry in the registry.
10

11. XDS Transactions (2)
Patient Identity Feed conveys the patient identifier and
corroborating demographic data, in order to populate the
Document Registry with patient identifiers that have been
registered for the XDS Affinity Domain. (At least one of the
options [ITI-8] or [ITI-44] must be supported.)
Registry Stored Query is issued by the Document
Consumer Actor to a Document Registry. It will return
registry metadata containing a list of document entries
found to meet the specified criteria including the locations
and identifier of each corresponding document in one or
more Document Repositories.
Retrieve Document Set – initiated by a Document
Consumer. The Document Repository shall return the
document set that was specified by the Document
Consumer.
11

12. XDS Document Content Types
XDS profile is content agnostic – it can be used with a
variety of document types, including:
XDS-SD: Scanned document, plain text or PDF/A, in
HL7 CDA R2 format
XDS-MS: Medical summary in HL7 CDA format
XDS-I: Radiology report in plain text of PDF format, or
reference to a collection of DICOM SOP Instances in a
manifest document in the DICOM Key Object Selection
format
Also supported are many other document content
profiles specified by the IHE Patient Care
Coordination, Laboratory, Cardiology, Pharmacy
Technical Frameworks
12

13. XDS – Actors and Options
Actors Options Reference
Document Replacement ITI TF-1: 10.2.1
Document Addendum ITI TF-1: 10.2.2
Document Source Document Transformation ITI TF-1: 10.2.3
Folder Management ITI TF-1: 10.2.4
Basic Patient Privacy Enforcement ITI TF-2b:3.41.4.1.3.1
Document Repository
Document Registry Patient Identity Feed ITI TF-2a: 3.8
Patient Identity Source Patient Identity Feed HL7v3 ITI TF-2b: 3.44
ITI TF-2a: 3.18.4.1.3.5
Basic Patient Privacy Enforcement
Document Consumer ITI TF-2b: 3.43.4.1.3.1
Basic Patient Privacy Proof ITI TF-2a: 3.18.4.1.3.6
13

14. Standards Used
ebRIM OASIS/ebXML Registry Information
Model v3.0
ebRS OASIS/ebXML Registry Services
Specifications v3.0
ITI TF-2x: Appendix V
 WS-I Profiles BP 1.1, BSP 1.0
 WS-* Specifications (SOAP 1.2, MTOM/XOP)
14

15. Metadata Objects
Metadata is data stored in the Registry
Document - represents a real document
Submission Set - included in all
submissions to document the submitted
“package”
Folder - for grouping documents
(directory metaphor)
Association - Links other objects together

16. Object Structure
Each Metadata Object has internal
structure
ebRIM standard coding used (XML)

17. Single Document Submission
Submission Association Document
Set (HasMember)
Envelope Contents
Metadata

18. Submission Set Attributes
Author Coded elements
 person, role, specialt  contentType (type of
y, institution clinical activity)
Title, comments, s Identifiers
ubmission time  Patient ID, Source
Availability Status ID, Unique ID, UUID
 Submitted or
Approved

19. Document Attributes
Author Identifiers
 Person, role, specialty, in
 Patient ID, Unique
stitution
ID, UUID
Legal Authenticator
Demographics
Title, comments, creat
ion time, service  Source Patient
start/stop time ID, Patient
Demographics
Availability Status
 Submitted, Approved, De
precated

20. Document Attributes (cont)
Coded Values Technical Details
 Kind of Document
 MIME Type
• Class Code (general
catagory)  Format Code (more
• Type Code (more detail) detail)
 Event Code (main clinical  Size
event)
 Hash
 Healthcare Facility Type
 Practice Setting Type  URI
 Confidentiality Code  Language

21. Document Attributes (cont)
Document Metadata
points to
Document
in Repository

22. Association Attributes
Type
 HasMember
 RPLC (Replace)
 APND (Appends)
 XFRM (Transformation)
 Signs
SubmissionSetStatus
 Original or Reference
Pointers
 sourceObject, targetObject

23. Multiple Document Submission
Document
Association
(HasMember)
Submission
Set
Association
(HasMember) Document

24. Document Replacement
Submission Document
Set Association Status = Approved
Status = Approved
(HasMember) Status = Deprecated
Association
(RPLC)
Submission Association Document
Set (HasMember) Status = Approved
Status = Approved

25. Digital Signature
Clinical Document Stored in Repository
 Indexed in Registry
Digital Signature (Document) Stored in
Repository
 Indexed in Registry
How is Signature “attached” to Clinical
Document?

26. Digital Signature (DSG Profile)
Submission Clinical
Association
Set (HasMember) Document
Status = Approved Status = Approved
Association
(Signs)
Submission Signature
Association
Set (HasMember) Document
Status = Approved Status = Approved

27. XDS Metadata handling
Patient Identity
Source
Patient Identity Interprets
Feed
Query
Documents
Stores Document Document
Registry Consumer
Generates Register
Provide and Document Set
Register Retrieve
Document Set Document
Document Document
Source Repository
Adds

28. Affinity Domain
Set of organizations/systems organized
around a single Registry
Common set of Codes
Single Patient ID Domain
Involves business and legal agreements
Security model/agreements

29. XDS Example
Enterprise Imaging Center
PCP Enterprise
Repository
Repository
Enterprise Cross-
Hospital A
Enterprise
Document
Repository Registry
(XDS)
Emergency Room
Enterprise Repository
Patient
Admin
Hospital B

30. XDS: Standards Used
Electronic Business Internet Standards
HTML, HTTP,
Standards ISO, PDF, JPEG …
ebXML, SOAP …
Healthcare
Content Standards
HL7 CDA, CEN EHRcom
HL7, ASTM CCR
DICOM …

31. XDS: Standards Used
XDS Infrastructure Standards
OASIS/ebXML
 Registry Information Model v2.0
• Basis of XDS Registry Information Model
 Registry Services Specifications v2.0
• Registry Services
 Messaging Services Specifications v2.0
• Offline protocols
ISO/IEC 9075 Database Language SQL
 Registry Query Language
SOAP with Attachments
 Protocol for communication with XDS Registries and Repositories
SHA-1 [FIPS 180-1]
 Document Hashes

32. XDS: Standards Used
XDS Infrastructure Standards (cont)
HL7 Version 2.3.1
 Messages for Patient Identity Management
HL7 Version 2.5
 Datatypes for XDS Registry Attribute values
HL7 CDA Release 1
 XDS Document concept definition
 Source of XDS Document Entry Attributes
DICOM, ASTM CCR, HL7 CDA Release 2, CEN
EHRcom
 Sources of XDS Document Entry Attributes

33. XDS: Standards Used
• XDS Infrastructure Standards (cont)
HTTP MIME
 Protocol for Retrieve  Document Type codes
Document UTF-8
 Online SOAP bindings
 Encoding of Registry
SMTP Attributes
 Offline ebMS bindings
IETF
 Language Identifiers

34. XDS: Standards Used
Two “categories” of standards used
XDS Content
XDS Infrastructure

35. XDS Content Profiles
Outside scope of XDS; layer on top of XDS
Content Profiles
 Document use cases and translation of document
content into registry metadata
 Publishable separately
 Generated (mostly) by other committees (PCC,
Radiology, Lab etc)
Of concern only to Document Source and
Document Consumer actors
Base standards for Content Profiles
include: HL7 CDA, DICOM, ASTM CCR

36. Security and Privacy Considerations
All actors be grouped with a ATNA Secure Node Actor
or Secure Application Actor resulting in each node
(systems supporting XDS actors) of the XDS Affinity
Domain should have audit and security mechanisms in
place
Transactions between different secure nodes that use
ATNA are encrypted
Each XDS Transaction will result in an audit event
record sent to an ATNA Audit Record Repository Actor
from each XDS actor
Timestamp consistency is provided by Consistent
Time (CT) profile
36

37. XDS Workflow
Health Information Exchange Network
PIX or PDQ PIX or PDQ
Query Patient Demographics Supplier Query
Patient Identity XRef Mgr
A87631
M8354673993
PMS M8354673993 14355
L-716 14355
L-716 A87631 ED Application
Physician Office
Document
Document Registry
Repository PACS
Document
Repository
EHR System
Query Document Register Document Provide &
(using Patient ID) (using Patient ID) Register
PACS
Retrieve Document
Maintain
Lab Info. Record Audit
Time
System Event Maintain
Time Teaching Hospital
Maintain
Community Clinic
Time
Audit record repository Time server
ATNA CT Record Audit Event
XDS Affinity Domain
37

38. XDS
Query Catalog
supported by Stored Query

39. Stored Query
Defines a collection of queries
 Name
 Function/purpose they serve
 Parameters they accept
Must be supported by all XDS Registries!

40. Query Types
Primary queries
 Based on Patient ID
Secondary queries
 Based on registry identifiers

41. Primary Queries
FindDocuments
 Find documents for a patient
FindSubmissionSets
 Find submission sets for a patient
GetAll
 Get everything known about a patient
Each have parameters to restrict
documents „found‟

42. Secondary Queries
GetDocuments
 Given the ids of the documents
GetFolders
 Given the ids of the folders
GetAssociations
 Related to a given document/folder/submission set

43. Secondary Queries (cont)
GetDocumentsAndAssociations
 Combines GetDocuments and GetAssociations
queries
GetSubmissionSets
 For a collection of documents and/or folders
GetSubmissionSetAndContents
 Given the id of the submission set, return its
contents

44. Secondary Queries (cont)
GetFolderAndContents
 Given the id of a folder return the folder and its
contents
GetFoldersForDocument
 Given the id of a document return all folders that
„contain‟ the document
GetRelatedDocuments
 Given the id of a document return all documents
that are related to the document through an
association

45. XDS Configurations
Understanding how
the actors work together

46. XDS Transaction Diagram
Patient Identity
Source
Patient Identity
Feed
Query
Documents
Document Document
Registry Consumer
Register
Provide and Document Set
Register Retrieve
Document Set Document
Document Document
Source Repository

47. Source/Consumer Grouping
A single 'workstation' that can submit and
access content.

48. XDS Transaction Diagram
Patient Identity
Source
Patient Identity
Feed
Query
Documents
Document Document
Registry Consumer
Register
Provide and Document Set
Register Retrieve
Document Set Document
Document Document
Source Repository

49. Registry/Repository Grouping
Affinity Domain could offer a central
Repository along with Registry to serve
facilities that do not have local Repository.

50. XDS Transaction Diagram
Patient Identity
Source
Patient Identity
Feed
Query
Documents
Document Document
Registry Consumer
Register
Provide and Document Set
Register Retrieve
Document Set Document
Document Document
Source Repository

51. Source/Repository Grouping
A source of documents could be an existing
EHR which
Registers documents in Registry
Allows document retrieval via Retrieve
Document transaction
Stores information internally in non-
document formats
Must manage document persistence

52. What is a Document?
Content/Documents have 3 formats:
 Storage
 Transfer/interface
 Display
XDS constrains the transfer/interface
through Content Profiles
 Use of IHE published Content Profiles is a local
choice. It is not required by XDS.
Transfer/interface formats are chosen
locally by Affinity Domain
IHE only makes recommendations

53. Security and Privacy
Overview
What IHE Delivers

54. Agenda
Overall Security and Privacy controls
Consistent Time (CT)
Audit Trails and Node Authentication (ATNA)
Enterprise User Authentication (EUA)
Cross-Enterprise User Assertion (XUA)
Document Digital Signature (DSG)
Basic Patient Privacy Consents (BPPC)
Access Control
Gaps
Conclusion
November 25, 2011 54

55. Layers of Policies
Examples
International OECD Guidelines on Transborder Flows
Profiles enables / enforces
Country-Specific US-HIPAA; EU-EC95/46; JP-Act 57 - 2003
Horizontal Industry Medical Professional Societies
Enterprise Backup and Recovery
November 25, 2011 55

56. Risk Scenario
In this scenario:
• The vulnerability is the
hole in the roof
• The threat is the rain
cloud
• Rain could exploit the
vulnerability
The risk is that the building and equipment in the building
could be damaged as long as the vulnerability exists and
there is a likely chance that rain will fall.
November 25, 2011 56

57. 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)
November 25, 2011 57

58. Accountability Models
Access Control model – Prevention
Strong controls on User Identification and Authentication
Strict Role-Based-Access-Control
 No one is given any more access rights than they minimally need
Typical in a Bank
Audit Control model – Reaction
Strong control on User Identification and Authentication
Relaxed Role-Based-Access-Control
 Emphasis on Training and Awareness of oversight
 Told what you are normally allowed to do
 Empowered to do what is right when necessary
Audit Logs are inspected regularly
Abuse is detected and acted upon
Healthcare: Typically mixture w/ emphasis on Patient Safety
November 25, 2011 58

59. Profiles mapped to Security & Privacy Controls
Audit Log
Authentication
Identification and
Control
Data Access
Secrecy
Data Integrity
Non-Repudiation
Patient Privacy
Security & Privacy Controls
Profile
IHE Profile
Issued
Audit Trails and Node Authentication 2004 √ √ √ √ √ √ √
Consistent Time 2003 √ ∙ √
Enterprise User Authentication 2003 √ ∙ ∙ ∙
Cross-Enterprise User Assertion 2006 √ ∙ ∙ ∙
Basic Patient Privacy Consents 2006 ∙ √
Personnel White Pages 2004 √ √ ∙
Healthcare Provider Directory 2010 √ ∙ ∙
Document Digital Signature 2005 √ √ √
Document Encryption 2011 √ √ ∙
November 25, 2011 59

60. ATNA
Audit Trail and Node Authentication
November 25, 2011 60

61. ATNA 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
November 25, 2011 61

62. ATNA: Actors / Transactions
 ITI-1: Maintain Time
Time Server Secure Node
grouped with
ITI-20: Record Audit Event
Any IHE Actor
 ITI-1:
Maintain Time
Secure Node
grouped with Audit Repository
PHI Application ITI-20: Record
Audit Event
ITI-19: Node
Authentication 
ITI-20: Record Audit Event
Secure Node
grouped with
Any IHE Actor
November 25, 2011 62

63. ATNA: Authenticate Node Transaction
Mutually Authenticate all network
communications of Sensitive Information
Encrypt and Integrity Protect
Standards
 X.509 Digital Certificate
 RSA Authentication
 AES Encryption
 SHA Integrity
 Transport Layer Security (TLS) RFC 2246
 Web-Services Security
 S/MIME
November 25, 2011 63

64. ATNA Authenticate Node
Secured Node
Dual Authenticated Links
EHR System
Physician Office ED Application
XDS
Secured Node
Document
Repository
PACS
XDS
Document
Registry XDS
EHR System
PACS Document
Repository Provide & Register Docs
Lab Info.
System
Teaching Hospital
Community Clinic
Secured Node
Secured Node
November 25, 2011 64

65. 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 is informed by XDS-Export + XDS-Import
November 25, 2011 65

66. Centralized Accountability
HIE boundary
EHR System PMS
Physician Office ED Application
XDS
Document
Repository XDS
Document PACS
Registry
XDS
Document
Repository
Query Document Register Document
EHR System
PACS
Retrieve Document Provide & Register Docs
Lab Info. Maintain Time
System
Maintain Teaching Hospital
Maintain Time
ATNA Audit Time
record CT Time server
Community Clinic repository
November 25, 2011 66

67. Distributed Accountability
Teaching Hospital
State run HIE
EHR System PMS
Physician Office ED Application
XDS
Document
Repository XDS
Document PACS
Registry
XDS
Document
Repository
Query Document Register Document
EHR System
PACS
Retrieve Document Provide & Register Docs
Lab Info. Maintain Time
System
ATNA Audit Maintain
record Maintain Time
repository ATNA Audit Time
record CT Time server
Community Clinic repository ATNA Audit
record
HIE boundary repository
November 25, 2011 67

68. Example: Audit Log Cascade
Sjfldjlsdj a
Kdjldsj
Clinic A
Lsjldjl
EMR jfjfjlslkjln
Lslasdjj;ask;sls
Sflksdjfl;saf
Salasaska
Faslskf;sf
Slsjlsdjlsdjf
Lsjflsdjldsjfs Audit HIE Infrastructure
Slkfjsdlfjldsf
lsjfldsjfldsfj
Sjfldjlsdj a
Lslasdjj;ask;sls
Faslskf;sf
lsjfldsjfldsfj
1) Many audit
events, both internal
Audit
and external
2) Local Audit Repository
Service filters out events
correlating to HIE
interactions
3) HIE Audit Record
combines with others for
total HIE view
November 25, 2011 68

69. ATNA: References
Status: Final Text
IHE ITI Technical Framework
 Vol. 1 - Section 9
 Vol. 2a - Sections 3.19, 3.20
“Security Considerations” section found in other
Profiles may specialize how ATNA is applied
The Audit Event Message typically specialized in Vol
2 at the Transaction level
 PIX QueryTransaction : See section Vol 2a:3.9.5.1
 XDS Register Document Set-b: See section Vol 2b:3.42.7.1
November 25, 2011 69

70. XUA
Cross-Enterprise User Assertion
November 25, 2011 70

71. What Problem is Being Solved?
XUA Problem Statement: The industry needs a
standards-based method to provide the initiating
user‟s identity in cross-enterprise transactions in a
way that the responder can make access decisions
and proper audit entries.
November 25, 2011 71

72. Value Proposition
Extend User Identity across organizations
 Users include Providers, Patients, Clerical, etc
 Must supports cross-enterprise transactions (e.g XDS, XCA),
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
November 25, 2011 72

73. 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 Kantara Initiative (formerly Liberty Alliance)
 May be obtained using WS-Trust or SAML
Define grouping behavior with EUA and ATNA
November 25, 2011 73

74. XUA: Attribute Extension supplement
User Role
 To support Role Based Access Control
Consent / Authorization
 To support use-cases where the requesting party
has explicit consent
Purpose Of Use
 Carry an indicator of what the reason for the
transaction is and what will be done with the result
November 25, 2011 74

75. XUA encoded in Web-Services
TLS -
HTTP HTTP Who is Authority?
SOAP Envelope
SOAP Header
How/Why to Trust?
WS-Security
Security Constraints (time)?
SAML 2.0
Assertion Assertion
Authentication Who is User?
Statement
How they were
Attribute
Statement
authenticated?
Authorization
Decision
What Roles apply?
Statement What is the Purpose?
Assertion
SecurityTokenReference
Signature
Original Transaction
Security Signature
SOAP Header What Consent
Security Token
SOAP Body applies?
Reference
Original Transaction
SOAP Body
SOAP Body
November 25, 2011 75

76. Level of Identity Assurance
Multi-Factor Token
PKI/ Digital Signature
Increased $ Cost
Knowledge-Based
Kerberos Very
High
Username - Password
High
PIN/User ID Medium
Low
Access to Access to Verification Remote
Summary of Local Of Data Clinical
Clinical research EHR/EMR Transcription Entry
Increased Need for Identity Assurance
November 25, 2011 76

77. XUA Actors
November 25, 2011 77

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

79. XUA: References
Status: Final Text
IHE ITI Technical Framework
 Vol 1: Section 13
 Vol 2b: Section 3.40
Standards Used
 SAML 2.0 Identity Assertions
 Web-Services Security header
 WS-I Basic Security Profile
November 25, 2011 79

80. BPPC
Basic Patient Privacy Consent
November 25, 2011 80

81. Problem
In a cross-enterprise or cross-community
environment how are the Privacy Preferences of the
Patient (Consumer) made known and thus enforced?
Consent is given and retracted
Consent in some environments is only for a specific
time
There may be many consents relevant to different
organizations or situations
Need to support Privacy Policies beyond consent,
such as authorizing research access
The BPPC Solution is only BASIC, advanced consents not supported
November 25, 2011 81

82. How does it work? (1 of 3)
A Patient Privacy Policy Domain (e.g. XDS Affinity
Domain)
Develop “Patient Privacy Policies”,
 E.g. Opt-In, Opt-Out-fully, Opt-Out-Safe, No-Publish
Assign each “Patient Privacy Policy” a Privacy
Domain wide unique identifier – “Patient Privacy
Policy Identifier”
Configure Access Control engines to recognize these
“Patient Privacy Policies” with the rules necessary to
enforce them
Define the default rule that is used when no consent
is found for a given Patient
November 25, 2011 82

83. How does it work? (2 of 3)
Capture a Patient consent
Inform the patient about the available “Patient Privacy
Policies” that they can chose from (Acknowledge)
A “Patient Privacy Policy Acknowledgement Document”
is created identifying that the patient has agreed to the
policy or policies (a type of CDA document)
 May include a scanned image – such as a scan of the patient ink-on-
paper signature on a replica printed version of the same policy
 May be digitally signed – such as by the clerk witnessing the consent
 May be time-limited
The “Patient Privacy Policy Acknowledgement Document”
is made available using same mechanism as is used for
clinical documents in that Privacy Domain (e.g., XDS)
 eventCodeList – holds the “Patient Privacy Policy Identifiers”
November 25, 2011 83

84. How does it work? (3 of 3)
Access Controls enforce consent
Assumes Access Control is implemented with sufficient ability to
enforce any Patient Privacy Policy allowed by the Patient Privacy
Domain
Can Leverage any interoperability profile in use: ATNA, EUA, XUA,
PWP and metadata (e.g. confidentialityCode)
Can Leverage application functionality such as Break-Glass
XDS Query on Patient ID for BPPC type documents
 If zero results returned – use default rule
 Else for each result returned validate entry startTime and stopTime (to
eliminate expired consents)
 Use configured logic for remaining using eventCodeList as the list of
acknowledged “Patient Privacy Policy Identifiers”
November 25, 2011 84

85. Standards and Profiles Used
Key Properties
 Support Human Readable Consents
 Support Machine Processable Access Controls
 Support for standards-based Role-Based Access Control
Standards
 CDA Release 2.0
 XDS Scanned Documents
 Document Digital Signature
 Cross Enterprise Document Sharing (XDS, XDR, and XDM)
 Cross Community Access (XCA)
November 25, 2011 85

86. Enforcing BPPC OPT-OUT at the HIE
Hospital Domain
HIE Domain
EHR
6) Return Query Results Integrated XDS
Document Registry Document Consumer
Document
Repository
Access Control 1) Authenticates User
Management
Identity and
Access
Management
4) Looks in Document
Registry for any BPPC
documents
If OPT-OUT found  Return 3) Intercepts Transaction
zero results and inspects XUA and
XDS Query parameters
November 25, 2011 86

87. 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
November 25, 2011 87

88. BPPC: References
Status: Final Text
IHE ITI Technical Framework
 Vol 1: Section 19
 Vol 3: Section 5.1
 Options added to other transactions
• Vol 2a: Section 3.18
• Vol 2b: Section 3.32, 3.41, 3.42, 3.43
November 25, 2011 88

89. ATNA + EUA + XUA + BPPC
Access Controls leveraging the Security
Profiles
November 25, 2011 89

90. Access Control model mapped to
IHE Security and Privacy Profiles
XDS …
November 25, 2011 90

91. Role-Based-Access-Control mapped to
confidentialityCodes
for OPT-IN  Normal Sharing
Billing Information
Sensitive Clinical
General Clinical
Administrative
Sensitivity
Mediated by
Direct Care
Information
Information
Information
Information
Research
Provider
Functional Role
HL7 confidentialityCode (2.16.840.1.113883.5.25) L N D R V T
Administrative Staff X X
Dietary Staff X
General Care Provider X X
Direct Care Provider X X X X
Emergency Care Provider (e.g. EMT) X
Researcher X
Patient or Legal Representative X X X X
November 25, 2011 91

92. Role-Based-Access-Control mapped to
confidentialityCodes for OPT-OUT
Only Direct Care
Billing Information
Sensitive Clinical
General Clinical
Administrative
Sensitivity
Mediated by
Direct Care
Information
Information
Information
Information
Research
Provider
Functional Role
HL7 confidentialityCode (2.16.840.1.113883.5.25) L N D R V T
Administrative Staff
Dietary Staff
General Care Provider
Direct Care Provider X
Break Glass Permission X
Emergency Care Provider (e.g. EMT)
Researcher
Patient or Legal Representative X X X X
November 25, 2011 92

93. Distributed Access Control – enabled by
XUA
XDS Document XDS Registry
ATNA
ConsumerAccess
Control
XDS Document XDS Registry
ATNA + XUA
Consumer Access
Control
XDS Document XDS Registry
ATNA + XUA
ConsumerAccess Access
Control Control
November 25, 2011 93

94. Supported Security Mis-Use-Cases
Prevent Indiscriminate attacks  Mutual Auth TLS
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)
November 25, 2011 94

95. Profiles mapped to Security & Privacy Controls
Audit Log
Authentication
Identification and
Control
Data Access
Secrecy
Data Integrity
Non-Repudiation
Patient Privacy
Security & Privacy Controls
Profile
IHE Profile
Issued
Audit Trails and Node Authentication 2004 √ √ √ √ √ √ √
Consistent Time 2003 √ ∙ √
Enterprise User Authentication 2003 √ ∙ ∙ ∙
Cross-Enterprise User Assertion 2006 √ ∙ ∙ ∙
Basic Patient Privacy Consents 2006 ∙ √
Personnel White Pages 2004 √ √ ∙
Healthcare Provider Directory 2010 √ ∙ ∙
Document Digital Signature 2005 √ √ √
Document Encryption (in development) 2011 √ √ ∙
November 25, 2011 95

96. Conclusion
IHE provides the Interoperability Profiles needed to
enable Security and Privacy
 Much of Security and Privacy is policy, operational environment,
procedures, and functional capabilities of systems
As standards develop and mature new profiles will be
created
Continuous Risk Assessment is necessary at all levels
 Profile writing (Cookbook for Security Considerations)
 System design and implementation
 Network design
 Physical layout
 Organizational
 Privacy/Security Domain
 Community
November 25, 2011 96

97. Healthcare Provider Directory
(HPD)
November 25, 2011 97

98. HPD Introduction
HPD supports queries against, and management of, healthcare
provider information that may be publicly shared in a directory
structure. HPD directory structure is a listing of the following two
categories of healthcare providers that are classified by provider
type, specialties, credentials, demographics and service
locations.
 Individual Provider: A person who provides healthcare
services, such as a physician, nurse, or pharmacist.
 Organizational Provider: Organization that provides or
supports healthcare services, such as a hospital, Healthcare
Information Exchange (HIE), Managed Care, Integrated
Delivery Network (IDN), and Association.

99. What Problem is Being Solved?
HPD Problem Statement: The industry needs a
standards-based method to support queries against,
and management of, healthcare provider information
that may be publicly shared in a directory structure.

100. HPD Scope
Designed to maintain a structured list of
attributes for both organizations (such as
clinics) and people (such as physicians)
Allows extensibility
Leverages ISO standard (21091)
Designed to enable cross organizational
directory access

101. HPD Value Proposition
Single Authoritative Knowledge Base
 Reduce duplicate and unconnected user info database
 Single place to update
• Name Changes
• New Phone Number
• Additional Addresses
Enhance Workflow and Communications
 Providing information necessary to make connections
• Phone Number
• Email Address
• Postal Address
Common data model supports semantic interoperability
Contributes to Identity Management
 Additional methods of identity cross verification
• Name, address, phone number, email
• Cross reference with Enterprise User Authentication identity
 Can contain certificates

102. HPD Selected Use Cases
Yellow pages lookup
Query providers and their associations for Social
Services Disability Determination
Emergency Responders Identification in planning for
an emergency event
Provider Authorization and lookup during an
emergency event
Forwarding of Referral Documents to a Specialist
Certificate Retrieval
Language Retrieval

103. HPD Actor Diagram
Provider Information
Feed
Provider Information [ITI-59] Provider Information
Source Directory
Provider Information
Query
[ITI-58]
Provider Information
Consumer

104. HPD Actors
Three Actors
 Provider Information Directory – Processes
queries to search for providers based on criteria
received from the Provider Information Consumer
actor and processes management operations
based on actions received from the Provider
Information Source actor.
 Provider Information Consumer – Initiates query
requests.
 Provider Information Source – Initiates
management commands consisting of Add,
Update, or Delete requests.

105. HPD Transactions & Options
Two Transactions
 Provider Information Query [ITI-58] – Sends query
commands.
 Provider Information Feed [ITI-59] – Sends
management commands.
One Option
 Provider Information Feed – Used to specify when
the optional Provider Information Feed transaction is
supported by the Provider Information Directory.

106. HPD Relationships

107. HPD Process Flow

108. HPD Organizational Provider

109. HPD Individual Provider

110. HPD Security and Privacy
Security and privacy for HPD is established via other
mechanisms
 ATNA can optionally be used for node authentication and
secure audit logging
 EUA to authenticate users
 XUA for access control
 PWP for system users identification
 IT best practices
 LDAP authentication for attribute protection
Regional-specific legal, regulatory, policy, privacy,
and security analysis is suggested
See the HPD supplement section 28.4 for a security
considerations analysis

111. HPD References
Status: Trial Implementation
IHE IT Infrastructure Technical Framework
Supplement Healthcare Provider Directory
(HPD) – Primary Content
Standards Used
 LDAP
 DSML
 ISO/TS 21091
November 25, 2011 111

112. DSUB
Document Metadata Subscription supplement

113. DSUB Overview
The Document Metadata Subscription
(DSUB) supplement contains two related
parts:
Publish/Subscribe Infrastructure: General
framework for defining web-services
based publish/subscribe interactions
Document Metadata Subscription (DSUB)
Integration Profile: Use of subscriptions
within an XDS Affinity Domain or across
communities
113

114. Publish/Subscribe
Infrastructure
Presents a framework for building event-
driven information exchange patterns
using a publish/subscribe data exchange
model
Defines the transport of publish,
subscribe and notify messages.
Supports IHE profiles which define the use
case specific content to be carried in the
publish, subscribe and notify messages
 Document Metadata Subscription (DSUB)
114
first profile to use this framework.

115. Publish/Subscribe Infrastructure
Actors and Transactions
Publisher
Publish 4.4.2.3
Notification Subscribe 4.4.2.1
Subscriber
Broker
Notify 4.4.2.2
Notification
Recipient
115

116. Possible Combined Actors
Publisher Publisher
Notification Subscribe
Subscriber Publish
Broker
Notify Notification Subscribe
Broker
Notification
Publisher
Recipient Notify
Notification Subscribe
Broker Notification
Subscriber
Recipient
Notify
Notification
Subscriber
Recipient
116

117. Document Metadata Subscription (DSUB)
Integration Profile
Defines a subscription which allows for the
matching of metadata during the publication of a
new document for a given patient, and results in
the delivery of a notification.
Enabled within an XDS Affinity Domain or XCA
environment
Use Cases
 Emergency Department: Notification of new document
availability during treatment
 Primary Care Management: PCP receives notification when
new documents for patient are available
117

118. DSUB Actors and Transactions
Document Metadata Document Metadata
Publisher Subscriber
Document Metadata
Publish [ITI-54]
Document Metadata
Document Metadata Subscribe [ITI-52]
Notification Broker
Document Metadata
Notify [ITI-53]
Document Metadata
Notification Recipient
118

119. Transactions
Document Metadata Subscribe : start a
subscription for a particular topic and filtering
within that topic. Supports full and minimal
notifications and where to send the notification.
Document Metadata Notify : send a notification
about the availability of a document or
documents of interest, based on the subscribers'
filters on selected topics
Document Metadata Publish : notify that an event
occurred for which there may be a subscription.
119

120. DSUB Process Flow
Notification Notification
Publisher Subscriber
Broker Recipient
XDS Document XDS Document
Source Subscribe Consumer
XDS Document
Registry
Publish
Notify
Publish
Notify
Unsubscribe
Publish
120

121. DSUB Subscription Topics and Standards
DSUB Topic Tree
 ihe:FullDocumentEntry : subscribes to Document Entry registration
events; the notification shall contain the full metadata describing
each matching Document Entry
 ihe:MinimalDocumentEntry : subscribes to Document Entry
registration events; the notification shall contain a minimal set of
data (identifiers only) describing each matching Document Entry
DSUB Standards
 OASIS Web Services Notification Family of Standards
• WS-BaseNotification 1.3 OASIS Standard
• WS-BrokeredNotification 1.3 OASIS Standard
• WS-Topics 1.3 OASIS Standard
• ITI TF-2x: Appendix V
 Filter expression
• Registry Stored Query [ITI-18]
121

122. DSUB References
Primary
 DSUB Supplement Rev 1.4 2010-08-10
Underlying Technical Framework Content
 ITI TF-2a
• Section 3.18 Registry Stored query
 ITI TF-2b
• Section 3.42.4.1 Register Document Set-b Request
• Section 3.43.4.2.2 Message Semantics
 ITI TF-2x
• Appendix V “Web Services for IHE Transactions”
122

123. Cross-enterprise
Document Workflow
(XDW)
September, 2011 What IHE Delivers

124. XDW Introduction
The Cross-Enterprise Document Workflow (XDW)
profile enables participants in a multi-organizational
environment to manage and track the tasks related
to patient-centric workflows as they coordinate their
activities:
 No central controller
 No central scheduler
 Decisions are made by the “edges” (providers,
doctors, nurses, etc)
 XDW coordinates these activities

125. XDW Problem Statements
Necessity:
 Digitizingclinical processes (paperless) and
enhancing care coordination is a focus across
organization and boundaries such as many
regional and national projects
 Allexpect to manage workflows beyond a single
organization:
 Examples: eReferral & eOrders workflows

126. XDW Framework
Framework:
 XDW is a framework operating in an XDS contest which support
the management of clinical process
 XDW is a framework which need to be specialized and different
Workflow Definition profiles will be write to define specific clinical
process
 Increases the consistency of workflow interoperability, and
enables the development of interoperable workflow
management applications where workflow-specific customization
is minimized
 Facilitates the integration of multi-organizational workflows with
the variety of existing workflow management systems used
within the participating organizations (peer-to-peer)

127. XDW Key Design Elements
Key XDW design elements:
 Provides a common, workflow-independent approach to
interoperability
 Enables the support of a wide range a specific workflow “content”
 Designed to support the complexity of health services delivery with
flexibility to adapt
 Provides the means to associate documents to a broad range of
workflows
 Easy to deploy: no addt‟l centralized infrastructure . Scales to
regions & nations.
 Builds upon the secured sharing of health documents provided by
other IHE profiles (e.g. XDS, ATNA, BPPC, etc.)

128. XDW Framework Diagram

129. XDW Simple Case
Workflow Document in XDW:
 Specified by XDW is generic across specific workflow content
 Manages workflow specific status with relationship to input/output documents
 Tracking the current/past steps of the workflow and engaged health care entities
 Workflow driven/enforced by the XDW actors, infrastructure provides transparency

130. Structure of the step in the
XDW Workflow Document
Structure of the Workflow Document
Workflow Document Structure: Workflow Document
Information:
documentID
 Overall workflow context title
patient
author/custodian
 Task level Information time: date/time/UTC
workflow definition URN
workflow ID
Task describes an activity that is planned or workflow state (active/closed)
has been accomplished. Attributes of the
task: TaskList
 Type Task 1
Date/time
 Owner State
Input
 Current Status (created, in-progress, completed, Output
etc.) Task Event history
 References to documents used for input or
produced as output Task ……..
 The Task Event History tracks the past Task
Events, up to the present state Task n
Task Event history

131. Structure of the Workflow Document
!
!
It is possible divided the structure of "#!!
the WD in 4 parts: 0**0-2"607"/ 0!
! "! # ! $%'()*# '
&
+ , - '. / 0'
 Part 1: elements derived from HL7 CDA -' 1*"#012 "2 #0!
"3+ 45'
standard +
318. 3805' #0!
 Part 2: two elements, patient and author, 2+
"2 0!
defined in the XDWSchema with the
!
structure derived from HL7 R-MIM standard : 32 !
"012
! "! # ! $%'()*# '
&
$% & ' () *+ , % -. / 012
& ' ' ! + , - '12 4 '
3 3
 Part 3: elements defined by IHE XDW 3. 2 (!
9'
Profile
!
, ' () *+ , ?1@31-0?#!
' 2
 Part 4: the element <TaskList> in which
is defined by elements derived from the , ' () *+ , % -. / 012 0<. 01-0= . / >0(!
' ' ;
OASIS WS-HumanTask standard. ! "! # ! $%''
&
, ' () *+ , ; 2 . @
' 32 ! 5! (6 5'78''
$!
9/ : '; )*(6 '"!
, ' () *+ , %
' 0*"1"2 1A0*0(01-0!
"'
! ! "! # ! $%'()*# ''
&
73@ B"@!
) 2
<0=4 =2 ># ?$@ A'
=': + ?&

132. XDW Flow and Interactions
in an XDS scenario
Content Content
Creator Consumer
XDS 2. Consumers search
Infrastructure about patient’s
workflows
1. Sources post
workflow document
and referenced 3. Consumers retrieve
document to the selected documents
XDS Infrastructure from the XDS Content
Infrastructure Updater
5. Consumers search
Content about patient’s
Consumer workflows 4. Sources update
the workflow
document and post
possible new
6. Consumers retrieve referenced
selected documents documents
from the XDS
Infrastructure

133. XDW Process Flow
workflow definition
2-
Admission of
the patient
1-Visit and production
of eReferral 3- Start of the
Consultation
The workflow within
5 – Possible
notification to the GP 4 – End of the the organization is
consultation and
creation of the clinical
encapsulated into a
report single XDW step

134. XDW Process Flow
first task of the process
Workflow Document
task: REQUESTED
Status: COMPLETED
Author: Mr.Rossi
Time: date/time/utc
Inputs:
-> Lab Report
Task A: Requested
Outputs:
Status 1: Completed -> eReferralDoc1
1-Visit and taskEventHistory
production of TaskEvent: 1
eReferral Status:
COMPLETED
Inputs:
-> Lab Report
Outputs:
-> eReferralDoc1

135. XDW Process Flow
second task of the process, first status
Workflow Document
REQUESTED
task: REFERRED
Status:
INPROGRESS
2- Author: Mr.Brum
Admission of Time: date/time/utc
the patient
Inputs:
-> eReferralDoc1
Task B: Referred
Outputs:
Status 1: In Progress ->
taskEventHistory
TaskEvent: 1
Status:
The workflow INPROGRESS
within the Inputs:
organization is -> eReferralDoc1
encapsulated into Outputs:
a single XDW step ->

136. XDW Process Flow
second task of the process, second status
Workflow Document
REQUESTED
task: REFERRED
Status:
COMPLETED
Author: Mr.Brum
Time: date/time/utc
Inputs:
Task B: Referred -> eReferralDoc1
Status 2: Completed Outputs:
-> ClinicalRepDoc2
3- Start of the taskEventHistory
Consultation TaskEvent: 1
TaskEvent: 2
Status:
5 – Possible
The workflow COMPLETED
notification to the 4 – End of the within the Inputs:
GP consultation and organization is -> eReferralDoc1
creation of the
clinical report encapsulated into Outputs:
a single XDW step ->
ClinicalRepDoc3

137. XDW profile and Workflow Definition profile
 Cross Enterprise Document Workflow is:
 a framework to manage workflows
 a platform upon which a wide range of specific workflows can be
defined with minimal specification and implementation efforts
 workflow independent
 applicable on different document sharing infrastructures
 Workflow Definition Profile is:
 the definition of a specific clinical process
 a set of rules and task definition which characterize the
process
 the definition of the actors involved in the process and their
roles

138. Use Case: an example of eReferral workflow(2)
A B C
Workflow Step
The specialist admits the The specialist completes
The GP produces the patient and starts the the consultation and
eReferral consultation produce the report
Workflow
Description Creation of the
eReferral Document
Creation of the
Clinical Report
Creation of the Updated of the Updated of the
Workflow Document Workflow Document Workflow Document
Workflow Document Workflow Document Workflow Document
REQUESTED REQUESTED
task: REQUESTED
Status: COMPLETED
Author: Mr.Rossi
Time: date/time/utc
task: REFERRED task: REFERRED
Inputs: Status: INPROGRESS Status: COMPLETED
-> Lab Report Author: Mr.Brum Author: Mr.Brum
XDW Outputs:
-> eReferralDoc1
Time: date/time/utc
Inputs:
-> eReferralDoc1
Time: date/time/utc
Inputs:
-> eReferralDoc1
Outputs: Outputs:
-> -> ClinicalRepDoc2
taskEventHistory
Evolution TaskEvent: 1
Status: COMPLETED
Inputs:
taskEventHistory
taskEventHistory
-> Lab Report TaskEvent: 1
of shared Outputs:
Status: INPROGRESS
Inputs:
TaskEvent: 1
-> eReferralDoc1
Workflow -> eReferralDoc1
Outputs:
TaskEvent: 2
Status: COMPLETED
->
Document Inputs:
-> eReferralDoc1
Outputs:
-> ClinicalRepDoc3

139. Selected Standards & Systems
 XDW Supplement introduces a new content
framework profile for a workflow management
document
 OASIS Human Task for task structure and encoding
 HL7 CDA for provider description
 HL7 R-MIM for patient and author description
 No new transaction are introduced. Leverages existing
ITI IHE Profiles:
 XDS.b, DSUB, XDR, XDM, BPPC, ATNA
 No XDS Metadata extension, but specific rules about
XDS Metadata content for the registry entry
associated to the XDW Workflow Document

140. XDW references
 Trial Implementation status
 Primary Content
 XDW Supplement
 Underlying technical framework content
 ITI XDS.b profile

141. 141