Integrating the Healthcare Enterprise

5

10

IHE IT Infrastructure
Technical Framework
Volume 3(ITI TF-3)
Cross-Transaction Specifications and Content
Specifications

15

20

Revision 12.1 – Final Text
September 30, 201525

Please verify you have the most recent version of this document, which is published here.

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________CONTENTS

30

35

40

45

50

55

60

65

4 Metadata used in Document Sharing profiles ............................................................................ 7
4.1 Abstract Metadata Model .................................................................................................... 7
4.1.1 Metadata Object Types ................................................................................................ 8
4.1.2 Association Types ...................................................................................................... 10
4.1.3 Metadata Attributes ................................................................................................... 11
4.1.3.1 The Purpose of Metadata Attributes (Informative) ............................................ 12
4.1.3.2 DocumentEntry Metadata Attributes .................................................................. 13
4.1.3.3 SubmissionSet Metadata Attributes ................................................................... 15
4.1.3.4 Folder Metadata Attributes ................................................................................. 16
4.2 ebRIM Representation ...................................................................................................... 17
4.2.1 Metadata Object Types .............................................................................................. 19
4.2.1.1 DocumentEntry................................................................................................... 19
4.2.1.1.1 DocumentEntry types ................................................................................. 20
4.2.1.2 SubmissionSet .................................................................................................... 20
4.2.1.2.1 Creating a SubmissionSet object from a RegistryPackage element ......... 22
4.2.1.3 Folder .................................................................................................................. 23
4.2.1.3.1 Creating a Folder object from a RegistryPackage element ....................... 25
4.2.1.4 Registry Object List ............................................................................................ 26
4.2.2 Association Types ...................................................................................................... 27
4.2.2.1 HasMember ........................................................................................................ 29
4.2.2.1.1 SS-DE HasMember ................................................................................... 29
4.2.2.1.2 SS-FD HasMember ................................................................................... 31
4.2.2.1.3 FD-DE HasMember .................................................................................. 32
4.2.2.1.4 SS-HM HasMember.................................................................................. 33
4.2.2.1.5 Adding DocumentEntries to Folders ........................................................ 34
4.2.2.2 Document Relationship ...................................................................................... 37
4.2.2.2.1 APND........................................................................................................ 39
4.2.2.2.2 XFRM ....................................................................................................... 40
4.2.2.2.3 RPLC......................................................................................................... 41
4.2.2.2.4 XFRM_RPLC ........................................................................................... 46
4.2.2.2.5 Signs .......................................................................................................... 46
4.2.2.2.6 IsSnapshotOf............................................................................................... 47
4.2.3 Metadata Attributes ................................................................................................... 48
4.2.3.1 General Information about Metadata Attributes................................................. 48
4.2.3.1.1 Attribute Value Length ............................................................................. 48
4.2.3.1.2 Creating Coded Attributes ........................................................................ 49
4.2.3.1.3 Creating External Identifiers ..................................................................... 50
4.2.3.1.4 Creating Author Attribute ......................................................................... 51
4.2.3.1.4.1 authorInstitution................................................................................. 54
4.2.3.1.4.2 authorPerson ...................................................................................... 55
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

2

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

70

75

80

85

90

95

100

105

110

4.2.3.1.4.3 authorRole.......................................................................................... 56
4.2.3.1.4.4 authorSpecialty .................................................................................. 56
4.2.3.1.4.5 authorTelecommunication ................................................................. 57
4.2.3.1.5 UUIDs ....................................................................................................... 57
4.2.3.1.6 Extra Metadata Attributes ......................................................................... 57
4.2.3.1.7 Metadata Attribute Data types .................................................................. 58
4.2.3.1.8 General format of DocumentEntry, Folder and SubmissionSet attributetables ......................................................................................................... 62
4.2.3.1.9 Metadata Attribute Cardinality ................................................................. 64
4.2.3.1.10 classificationScheme vs. classificationNode ............................................ 64
4.2.3.2 DocumentEntry Attributes.................................................................................. 65
4.2.3.2.1 DocumentEntry.author .............................................................................. 67
4.2.3.2.2 DocumentEntry.availabilityStatus ............................................................ 67
4.2.3.2.3 DocumentEntry.classCode ........................................................................ 68
4.2.3.2.4 DocumentEntry.comments........................................................................ 69
4.2.3.2.5 DocumentEntry.confidentialityCode ........................................................ 69
4.2.3.2.6 DocumentEntry.creationTime................................................................... 72
4.2.3.2.7 DocumentEntry.entryUUID ...................................................................... 73
4.2.3.2.8 DocumentEntry.eventCodeList ................................................................. 73
4.2.3.2.9 DocumentEntry.formatCode ..................................................................... 74
4.2.3.2.10 DocumentEntry.hash ................................................................................. 75
4.2.3.2.11 DocumentEntry.healthcareFacilityTypeCode ........................................... 76
4.2.3.2.12 DocumentEntry.homeCommunityId ......................................................... 77
4.2.3.2.13 DocumentEntry.languageCode ................................................................. 77
4.2.3.2.14 DocumentEntry.legalAuthenticator .......................................................... 78
4.2.3.2.15 DocumentEntry.mimeType....................................................................... 78
4.2.3.2.16 DocumentEntry.patientId .......................................................................... 79
4.2.3.2.17 DocumentEntry.practiceSettingCode........................................................ 80
4.2.3.2.18 DocumentEntry.repositoryUniqueId ......................................................... 81
4.2.3.2.19 DocumentEntry.serviceStartTime............................................................. 81
4.2.3.2.20 DocumentEntry.serviceStopTime ............................................................. 82
4.2.3.2.21 DocumentEntry.size .................................................................................. 83
4.2.3.2.22 DocumentEntry.sourcePatientId ............................................................... 83
4.2.3.2.23 DocumentEntry.sourcePatientInfo ............................................................ 84
4.2.3.2.24 DocumentEntry.title .................................................................................. 85
4.2.3.2.25 DocumentEntry.typeCode......................................................................... 85
4.2.3.2.26 DocumentEntry.uniqueId .......................................................................... 86
4.2.3.2.27 DocumentEntry.URI ................................................................................. 87
4.2.3.2.28 DocumentEntry.referenceIdList................................................................ 87
4.2.3.2.29 DocumentEntry.limitedMetadata .............................................................. 88
4.2.3.2.30 DocumentEntry.objectType ...................................................................... 89
4.2.3.3 SubmissionSet Attributes ................................................................................... 89
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

3

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

115

120

125

130

135

140

145

150

4.2.3.3.1 SubmissionSet.author................................................................................ 90
4.2.3.3.2 SubmissionSet.availabilityStatus .............................................................. 90
4.2.3.3.3 SubmissionSet.comments ......................................................................... 91
4.2.3.3.4 SubmissionSet.contentTypeCode ............................................................. 91
4.2.3.3.5 SubmissionSet.entryUUID........................................................................ 92
4.2.3.3.6 SubmissionSet.homeCommunityId .......................................................... 92
4.2.3.3.7 SubmissionSet.intendedRecipient ............................................................. 93
4.2.3.3.8 SubmissionSet.patientId............................................................................ 94
4.2.3.3.9 SubmissionSet.sourceId ............................................................................ 95
4.2.3.3.10 SubmissionSet.submissionTime ............................................................... 96
4.2.3.3.11 SubmissionSet.title.................................................................................... 96
4.2.3.3.12 SubmissionSet.uniqueId............................................................................ 97
4.2.3.3.13 SubmissionSet.limitedMetadata................................................................ 97
4.2.3.4 Folder Attributes ................................................................................................. 98
4.2.3.4.1 Folder.availabilityStatus ........................................................................... 99
4.2.3.4.2 Folder.codeList ......................................................................................... 99
4.2.3.4.3 Folder.comments ..................................................................................... 100
4.2.3.4.4 Folder.entryUUID ................................................................................... 101
4.2.3.4.5 Folder.homeCommunityId ...................................................................... 101
4.2.3.4.6 Folder.lastUpdateTime............................................................................ 101
4.2.3.4.7 Folder.patientId ....................................................................................... 102
4.2.3.4.8 Folder.title ............................................................................................... 103
4.2.3.4.9 Folder.uniqueId ....................................................................................... 103
4.2.3.4.10 Folder.limitedMetadata ........................................................................... 104
4.2.4 Error Reporting ........................................................................................................ 105
4.2.4.1 RegistryErrors Element .................................................................................... 105
4.2.4.2 Error responses ................................................................................................. 109
4.2.5 Metadata Vocabulary ............................................................................................... 111
4.2.5.1 Submission Set Object UUIDs ......................................................................... 111
4.2.5.2 Document Entry Object .................................................................................... 111
4.2.5.3 Folder Object .................................................................................................... 112
4.3 Additional Document Sharing Requirements ................................................................. 112
4.3.1 Requirements on Submission Type Transactions .................................................... 112
4.3.1.1 Submission Metadata Attribute Optionality ..................................................... 113
4.3.1.2 XDS Specific Requirements ............................................................................. 115
4.3.1.2.1 Provide and Register Document Set-b Transaction [ITI-41] .................. 116
4.3.1.2.2 Register Document Set-b Transaction [ITI-42] ...................................... 116
4.3.1.2.3 XDS Atomicity of Submissions .............................................................. 117
4.3.1.2.4 XDS Registry Enforcement of Attributes ............................................... 118
4.3.1.2.5 XDS Registry Responsibilities ............................................................... 120
4.3.1.2.6 Required Initialization of the XDS Affinity Domain ............................. 123
4.3.2 Requirements on Query Type Transactions ............................................................ 123
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

4

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

155

160

165

170

175

180

185

190

4.3.2.1 Query Type Metadata Attribute Optionality .................................................... 123
5 IHE Content Specifications .................................................................................................... 126
5.1 Basic Patient Privacy Consents Module ......................................................................... 126
5.1.1 References ................................................................................................................ 126
5.1.2 Patient Privacy Consent Acknowledgment Document Specification
1.3.6.1.4.1.19376.1.5.3.1.1.7 – With no Scanned Document Part ........................... 126
5.1.2.1 XDS Metadata .................................................................................................. 126
5.1.2.1.1 XDS DocumentEntry Metadata ................................................................ 126
5.1.2.1.1.1 XDSDocumentEntry.classCode ........................................................ 126
5.1.2.1.1.2 XDSDocumentEntry.eventCodeList ................................................. 126
5.1.2.1.1.3 XDSDocumentEntry.formatCode ..................................................... 127
5.1.2.1.1.4 XDSDocumentEntry.uniqueId .......................................................... 127
5.1.2.1.2 XDS SubmissionSet Metadata .................................................................. 127
5.1.2.1.3 XDS Folder Metadata ............................................................................... 127
5.1.2.2 Specification ..................................................................................................... 127
5.1.2.2.1 Patient Privacy Acknowledgement Service Events
1.3.6.1.4.1.19376.1.5.3.1.2.6................................................................... 128
5.1.2.2.2 <documentationOf typeCode='DOC'> ..................................................... 129
5.1.2.2.3 <serviceEvent classCode='ACT' moodCode='EVN'> .............................. 129
5.1.2.2.4 <templateId root='1.3.6.1.4.1.19376.1.5.3.1.2.6'/> .................................. 129
5.1.2.2.5 <id root=' ' /> ............................................................................................ 129
5.1.2.2.6 <code code=' ' displayName=' ' codeSystem=' ' codeSystemName=' '/>.. 129
5.1.2.2.7 <effectiveTime><low value=' '/><high value=' '/></effectiveTime> ...... 129
5.1.3 Patient Privacy Consent Acknowledgment Document Specification
1.3.6.1.4.1.19376.1.5.3.1.1.7.1 – With Scanned Document .................................... 130
5.1.3.1 XDS Metadata .................................................................................................. 130
5.1.3.1.1 XDS DocumentEntry Metadata ................................................................ 130
5.1.3.1.1.1 XDSDocumentEntry.formatCode ..................................................... 130
5.1.3.1.2 XDS SubmissionSet Metadata .................................................................. 130
5.1.3.1.3 XDS Folder Metadata ............................................................................... 130
5.1.3.2 Specification ..................................................................................................... 130
5.1.3.3 Conformance .................................................................................................... 130
5.2 Scanned Documents Content Module............................................................................. 130
5.2.1 Referenced Standards ............................................................................................... 131
5.2.1.1 Discussion of Content Standards ...................................................................... 131
5.2.2 XDS Metadata .......................................................................................................... 132
5.2.2.1 XDS DocumentEntry Metadata ........................................................................ 132
5.2.2.1.1 XDSDocumentEntry.formatCode ............................................................. 133
5.2.2.1.2 XDSDocumentEntry.uniqueId.................................................................. 133
5.2.2.1.3 Relating instances of XDS-SD documents ............................................... 133
5.2.2.2 XDS SubmissionSet Metadata ......................................................................... 133
5.2.2.3 XDS Folder Metadata ....................................................................................... 133
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

5Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
195

200

205

210

215

220

225

5.2.3 Specification ............................................................................................................. 134
5.2.3.1 ClinicalDocument child-less elements ............................................................. 135
5.2.3.2 ClinicalDocument/recordTarget ....................................................................... 136
5.2.3.3 ClinicalDocument/author (original) ................................................................. 137
5.2.3.4 ClinicalDocument/author (scanner).................................................................. 138
5.2.3.5 ClinicalDocument/dataEnterer ......................................................................... 140
5.2.3.6 ClinicalDocument/custodian ............................................................................ 141
5.2.3.7 ClinicalDocument/legalAuthenticator .............................................................. 142
5.2.3.8 ClinicalDocument/documentationOf ................................................................ 143
5.2.3.9 ClinicalDocument/component/nonXMLBody ................................................. 143
5.2.4 Complete Example (Wrapped PDF) ........................................................................ 146
5.4 XDW Workflow Content Module .................................................................................. 149
5.4.1 Referenced Standards ............................................................................................... 149
5.4.2 Discussion of Content Standards.............................................................................. 149
5.4.2.1 XDW Workflow Document Elements from HL7 CDA Standard .................... 152
5.4.2.2 XDW Workflow Document Elements defined by IHE XDW Profile ............. 152
5.4.2.3 XDW Workflow Document Elements from the OASIS Human Task ............. 153
5.4.2.4 Relationship between Task and <taskEvent> ................................................... 154
5.4.3 Content Specification ............................................................................................... 156
5.4.4 Complete Example ................................................................................................... 169
5.4.5 Workflow Document Management .......................................................................... 173
5.4.5.1 Workflow Document Lifecycle Management .................................................. 173
5.4.5.2 Associations Types ........................................................................................... 174
5.4.5.3 Create workflow ............................................................................................... 175
5.4.5.4 Update Workflow Document ........................................................................... 175
5.4.5.5 Association of a clinical document to a task and <taskEvent> ........................ 176
5.4.5.6 Get the Workflow Document and a clinical document associated to theworkflow........................................................................................................... 176
5.4.5.7 Use of the eventCodeList to manage the status of a Workflow Document...... 176
5.4.5.8 Parameters for Required Queries...................................................................... 177
5.4.6 XDS Metadata .......................................................................................................... 177
5.4.6.1 Document Metadata.......................................................................................... 177
5.4.6.2 XDS SubmissionSet Metadata ......................................................................... 179
5.4.6.3 XDS Folder Metadata ....................................................................................... 179

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

6

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

230

235

4 Metadata used in Document Sharing profiles
This section describes the metadata that is used in IHE profiles designed for sharing documents(Document Sharing profiles). The Document Sharing profiles are implementing the Document
Sharing concept outlined in the ITI whitepaper entitled Health Information Exchange: Enabling
Document Sharing Using IHE Profiles available on the IHE website(http://ihe.net/Technical_Frameworks/#IT). This section assumes understanding of the concepts
presented in the white paper.
The ITI Document Sharing profiles which use this metadata are:

240

245

•

Cross-Enterprise Document Sharing (XDS.b)•

Cross-Enterprise Document Reliable Interchange (XDR)•

Cross-Enterprise Document Media Interchange (XDM)•

Multi-Patient Queries (MPQ)•

Cross-Community Access (XCA)

It is likely that future ITI profiles will also use Document Sharing metadata. Profiles from IHE
domains other than ITI that use or constrain this metadata are not listed here. Those profiles will
document their use of this metadata.
Document Sharing profiles manage two aspects of the documents being shared, the metadata
about the document and the contents of the document. If you think of a document as a book in alibrary, the index card in the library’s card catalog is the document metadata.

250

Metadata encodes the properties of documents, the environments they come from, circumstancesof their submission, terms to reference in queries, and grouping with other documents.
Section 4 first explains the metadata at a conceptual level (Section 4.1), then at an
implementation level (Section 4.2) and then provides some profile- and transaction-specificmetadata constraints and considerations (Section 4.3).

4.1 Abstract Metadata Model
255

260

The metadata used in Document Sharing profiles is characterized by three types of objects andtwo types of Associations. In Figure 4.1-1, the three objects types and two Association types are
depicted using UML to show their relationships. The three object types are:•SubmissionSet – represents a collection of Folders, Documents and Associations
submitted together.

•

Folder – represents a collection of related Documents.

•

DocumentEntry – represents a Document.

•

The two Association types are:

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

7

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

265•

HasMember – represents membership of objects. There are four variations of
HasMember that are described in Section 4.1.2.

•

Relationship – represents a relationship between DocumentEntries.

Figure 4.1-1: Document Sharing Objects and Associations

4.1.1 Metadata Object Types
270

275

280

There are three metadata object types supported by the Document Sharing metadata, as seen in
Figure 4.1-1:•

SubmissionSet•

Folder•DocumentEntry

SubmissionSet – The SubmissionSet can be thought of as the packing slip of a postal package.
The details of the submission of DocumentEntries, Folders, and Associations are captured in the
SubmissionSet object. The creating entity of each submission must group the DocumentEntries,
Folders and Associations into a unique SubmissionSet. The Document Sharing profiles ensurethat the documents are treated as a unit for submission purposes – either all of the documents
arrive at their destination, or none of them do. An example of the use of a Submission Set ispackaging all documents related to a care episode at the end of the hospital stay. The EHR
system can submit the package. If the submission fails, none of the documents made it to theirdestination, and a retry is possible.
Submission Sets, once submitted, are immutable.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

8

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

285

290

295

DocumentEntries may be bundled into a SubmissionSet by a human, machine, or process. For
example, a laboratory machine might automatically submit results associated with a given lab
order when they are ready, rather than waiting for a human to bundle them. SubmissionSets may
contain DocumentEntries for multiple patients, but there are specific limitations on how this is
done.
A SubmissionSet shall be the source of at least one Association of type SS-FD HasMember, SSHM HasMember, and/or SS-DE HasMember.
Folder – A Folder is a logical collection of DocumentEntries that are related in some way, suchas to a clinical use case. A Folder is an arbitrary grouping relationship. Folders may be updated
by multiple SubmissionSets sent from multiples departments that are submitting their
DocumentEntry objects at different times. For example, a Folder may be used to collect theDocumentEntry objects for the patient’s documents that relate to an exam event, such as theexam request and prior results as well as the eventual exam results. As the exam results become
available, the DocumentEntry objects can be added to the Folder for the exam records.
All DocumentEntries in a Folder shall be for the same patient.

300

The metadata structure discussed in this volume only specifies how to describe a Folder, andimposes no requirements for when or how a Folder should be used. Additional detail on whenand how to use a Folder may be described in IHE profiles.
DocumentEntry – DocumentEntry is a metadata object representing a document. This metadata
object does not contain the contents of the document; instead it contains attributes describing the
document.

305

310

315

Details on how documents and metadata are managed depend on the requirements in a particularDocument Sharing Profile.
For example, in XDS, a Stable DocumentEntry is the logical representation in the Registry of theDocument that the Source submitted to a Repository. An entire document’s contents canconstitute several megabytes, but can be described in a few kilobytes of metadata. The
DocumentEntry metadata that describes the document are sufficient for the purposes of storing,organizing and locating documents for retrieval. Submitting a Stable DocumentEntry to a
Registry in lieu of submitting the document creates a separation of concerns, allowing theRegistry to specialize in indexing, while the Repository manages document storage.
There are two DocumentEntry Types: Stable DocumentEntry and On-Demand Document Entry.
The following sections describe these types in detail.
•320

Stable DocumentEntry
A Stable Document Entry contains metadata about an already created document available
for retrieval. Each Stable DocumentEntry represents a single document. This document isstable because the contents have been effectively combined in the exact representationthat will be returned in a Retrieve Document Set. A Stable Document Entry is an
XDSDocument Entry with objectType equal to the UUID for Stable (see Section 4.2.5.2

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

9Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
for the UUID) and availabilityStatus equal to Approved or Deprecated. All metadatafields contain valid values.
The uniqueID metadata attribute of a Stable DocumentEntry identifies the specificdocument associated with the entry. It is used in a retrieve request to identify which
specific document should be retrieved.

325

If the document returned on a retrieve request is CDA, it will have in theClinicalDocument/id field in the HL7 CDA R2 document header the same value as thevalue of the DocumentEntry uniqueId.
330

335

340

345

350

355

•

On-Demand Document Entry
An On-Demand Document Entry provides a unique identifier which can be used to create
an on-demand document which collects the latest, most recent available information at
the time of retrieval. On-Demand Document Entries never reflect actual document
content, but rather the potential for a document with the characteristics described in themetadata of the entry. An On-Demand DocumentEntry has objectType equal to the
UUID for On-Demand (see Section 4.2.5.2 for the UUID) and availabilityStatus equal toApproved or Deprecated. An On-Demand Document Entry may be replaced anddeprecated. If an On-Demand Document Entry is deprecated, the retrieval of thatuniqueID may not have the most recent information and should return an error.
The uniqueID associated with an On-Demand Document Entry will never represent an
actual document. A retrieve request specifying an On-Demand Document Entry uniqueID
will return content identified by a uniqueID different than the specified uniqueID.
Every On-Demand Document Entry with the same uniqueID will refer to the samepotential content. Actual content depends on the time of retrieval. The On-Demand
Document Entry uniqueID is valid for as long as the entry has availabilityStatus equal toApproved. The holder of the uniqueID may re-use it in a retrieve request to get the latest
information, without the need for an additional query.
When a retrieve request is received specifying an On-Demand Document Entry
uniqueID, the responder may choose to persist the document generated as a result andallow the requestor future access to the metadata and document. This capability is
declared through the Persistence of Retrieved Documents Option on the On-Demand
Document Source and Responding Gateway Actors. The persistence refers not only to thesaving of the content for re-use, but more specifically, to the ability of the requester to
use retrieve to access that exact, possibly now historic, content and use a query to get
metadata about the content.

4.1.2 Association Types
Associations represent a link from the source object to a target object. Association objects
describe all aspects of this link including references to source and target objects, the specificvariant or name of the Association, and status and version information.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

10

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
360

There are two types of Associations: HasMember and Relationship.
•

HasMember- defines a membership relationship between two objects. There are four
variants of the HasMember Association depending on the types of the source and target
object, see Figure 4.1-1.
SS-FD HasMember: An association from a SubmissionSet to a Folder identifies the
Folder as a member of that SubmissionSet. It identifies the Submission Set that
contained the initial creation of the Folder.

365

FD-DE HasMember: An association from a Folder to a DocumentEntry identifies that
DocumentEntry as a member of that Folder. Folders have a many-to-many
relationship to DocumentEntries (i.e., one folder may be linked to many
DocumentEntries, and one DocumentEntry may be linked to many folders).

370

SS-HM HasMember: An association from a SubmissionSet to a FD-DE HasMember
Association identifies that FD-DE HasMember as a member of that
SubmissionSet. This makes it possible to identify the Submission Set in which thelink between the Folder and the DocumentEntry was created.
375

SS-DE HasMember: An association from a SubmissionSet to a DocumentEntry identifies
the DocumentEntry as a member of that SubmissionSet. The association between
the SubmissionSet and the DocumentEntry provides information about thesubmission of the Documents. With this association of a DocumentEntry, you canfind the Submission Set and know when the document was submitted, who theauthor of the submission was, and other information contained in the attributes ofthat SubmissionSet.

380•

Relationship – defines an association between two DocumentEntry objects. There are
five variants based on the type of relationship between the DocumentEntry objects.
Replace – indicates the replacement of a previous document with a new document.

385

Transform - indicates the transformation of a previous document into a new document.
Append – indicates a new document that appends to the contents of a previous document.
Transform and Replace – indicates a transformed replacement of a previous documentwith a new document.

390

Signs – indicates a new document is a signature for a previous document, as in new
document signs previous document.
4.1.3 Metadata Attributes
Each metadata object holds attributes used for a variety of purposes. This section outlines thevariety of purposes metadata attributes serve as well as a general description of each attribute.
Detail about the coding of attributes is described in Section 4.2.3.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

11

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
395

4.1.3.1 The Purpose of Metadata Attributes (Informative)
Metadata attributes can be categorized according to specific document-handling purposes. Eachmetadata attribute typically has more than one purpose, although some have only one. Metadata
in the Document Sharing profiles has one or more of these purposes.
•

Patient Identity – Attributes that describe the subject of the document. This includes
patient Id, patient name, and other demographics.

•

Provenance – Attributes that describe where the document comes from. These items arehighly influenced by medical records regulations. This includes human author,
identification of system that authored, the organization that authored, predecessor
documents, successor documents, and the pathway that the document took.

405•

Security & Privacy – Attributes that are used by Privacy and Security rules toappropriately control the document. These values enable conformance to Privacy andSecurity regulations. These characteristics would be those referenced in Privacy or
Security rules. These characteristics would also be used to protect against security risks to
confidentiality, integrity, and availability.

410•

Descriptive – Attributes that are used to describe the clinical value, so they are expressly
healthcare-specific. These values are critical for query models and enable workflows inall exchange models. The number of attributes in this category is kept to minimum so themetadata doesn't simply duplicate the document, and to keep disclosure risk to aminimum. Thus the metadata attribute values tend to be from a small set of codes.
Because this category is close to the clinical values it tends to have few mandatory
attributes, allowing policy to choose to not populate. For healthcare documents, this is
typically very closely associated with the clinical workflows but also must recognize
other uses of healthcare documents such as quality reporting, public health reporting,authorized clinical research, patient access, etc.

•

Object Lifecycle – Attributes that describe the current lifecycle state of the document
including relationships to other documents. This would include classic lifecycle states ofcreated, published, replaced, transformed, and deprecated.

•

Exchange -- Attributes that enable the transfer of the document for both push typetransfers, and pull type transfers. These attributes are used for low-level automatedprocessing of the document. These attributes are not the workflow routing, but rather theadministrative overhead necessary to make the transfer. This includes the document
unique Id, location, size, MIME types, and document format.

400

415

420

425

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

12

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

Figure 4.1.3.1-1: Pictorial of Overlapping Document Sharing Metadata Purpose

430

435

All metadata attributes describe the document and are not a replacement for the document. Not
all metadata attributes are always required; indeed some metadata attributes would be used only
for specific uses. Care has been taken to limit the metadata to the minimum metadata attributes
necessary to achieve the goal. Each metadata element was assessed for risks posed by exposing it
as metadata. All metadata attributes are defined to assure that when the element is needed that it
be consistently assigned and processed.
4.1.3.2 DocumentEntry Metadata Attributes

440

Table 4.1.3.2-1 provides a conceptual view of the metadata attributes associated with aDocumentEntry object. The table describes each attribute and provides a mapping between theattribute and the purposes that attribute is designed to support. The full DocumentEntry metadata
attribute definition, including data type and coding is in Section 4.2.3.2.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

13

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

X

X

Characterizes the humans and/or machines that
authored the document. This attribute contains the
sub-attributes: authorInstitution, authorPerson,
authorRole, authorSpecialty andauthorTelecommunication.

availabilityStatus

Characterizes the lifecycle status of theDocumentEntry

classCodeA high-level classification of documents thatindicates the kind of document, e.g., report,
summary, note, consent.

comments

Comments associated with the document.

confidentialityCode

The code specifying the level of confidentiality of the
document.

creationTime

Characterizes the time the author created the
document.

entryUUID

A globally unique identifier used to manage theentry.

eventCodeList

This list of codes represents the main clinical acts,
such as a colonoscopy or an appendectomy, being
documented.

X

formatCode

Code globally uniquely specifying the detailed
technical format of the document.

X

hash

Hash of the document itself.

healthcareFacility
TypeCodeThis code represents the type of organizationalsetting of the clinical encounter during which the
documented act occurred.

homeCommunityId

A globally unique identifier for a community.

languageCode

Specifies the human language of character data in the
document.

legalAuthenticator

Characterizes a participant who has legallyauthenticated or attested the document within theauthorInstitution.

XlimitedMetadata

Indicates whether the Document Entry was createdusing the less rigorous requirements of metadata as
defined for the Metadata-Limited Document Source.

X

mimeType

MIME type of the document.

objectType

The type of DocumentEntry

patientId

The patientId represents the subject of care of the

Exchange

DescriptiveX

authorObject Lifecycle

Security&Privacy

Description

Patient identity

DocumentEntry
Metadata
Attribute

Provenance

Table 4.1.3.2-1: DocumentEntry Metadata Attribute Definition

X

X
X

X

X
X
X

X

X

X

X

X

X

X

X

X
X

X

X

X
X
X

X

X

X

X

X

X
X

X

X

X

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

14

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications

X

X

Exchange

Descriptive

X

Object Lifecycle

Security&Privacy

Description

Patient identity

DocumentEntry
Metadata
Attribute

Provenance______________________________________________________________________________

document.
practiceSettingCode

The code specifying the clinical specialty where theact that resulted in the document was performed (e.g.,
Family Practice, Laboratory, Radiology).

repositoryUniqueId

The globally unique identifier of the repository where
the document is stored.

serviceStartTime

Represents the start time the service being
documented took place.

X

X

serviceStopTime

Represents the stop time the service being
documented took place.

X

X

size

Size in bytes of the document.

XsourcePatientId

The sourcePatientId represents the subject of care
medical record Identifier (e.g., Patient Id) in the local
patient Identifier Domain of the creating entity.

X

X

sourcePatientInfo

This attribute contains demographic information of
the source patient to whose medical record thisdocument belongs.

X

X

title

Represents the title of the document.

X

typeCode

A low-level classification of documents within aclassCode that describes class, event, specialty, andsetting.

XuniqueId

The globally unique identifier assigned by the
document creator to this document.

URI

The URI for the document.

X

X

X

X
X

4.1.3.3 SubmissionSet Metadata Attributes
445

Table 4.1.3.3-1 provides a conceptual view of the metadata attributes associated with a
SubmissionSet object. The table describes each attribute and provides a mapping between theattribute and the purposes that attribute is designed to support. The full SubmissionSet metadata
attribute definition, including data type and coding is in Section 4.2.3.3.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

15

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
450

X

X

The humans and/or machines that created thesubmission set. This attribute contains the subattributes: authorInstitution, authorPerson,
authorRole, authorSpecialty,
authorTelecommunication.

availabilityStatus

The lifecycle status of the SubmissionSet

X

comments

Comments associated with the SubmissionSet.

X

contentTypeCode

The code specifying the type of clinical activity that
resulted in placing these documents in thisSubmissionSet.

entryUUID

A globally unique identifier used to manage theentry.

homeCommunityId

A globally unique identifier for a community.

intendedRecipient

The organization(s) or person(s) for whom the
Submission Set is intended.

patientId

The patientId represents the primary subject of carewhose longitudinal record is being reflected in thisSubmission Set.

sourceId

Identifier of the Document Source that created theSubmissionSet.

submissionTime

Point in Time at the Document Source when the
Submission Set was created.

title

The title of the SubmissionSet.

uniqueId

Globally unique identifier for the SubmissionSet
assigned by the Document Source.

X

X

X

X

X

Exchange

DescriptiveX

authorObject Lifecycle

Security&Privacy

Description

Patient identity

Submission Set
Metadata
Attribute

Provenance

Table 4.1.3.3-1: SubmissionSet Metadata Attribute Definition

X

X
X

X
X

X

X

X

X

X

X

X

X

X

X
X

X

4.1.3.4 Folder Metadata Attributes

455

Table 4.1.3.4-1 provides a conceptual view of the metadata attributes associated with a Folder
object. The table describes each attribute and provides a mapping between the attribute and the
purposes that attribute is designed to support. The full Folder metadata attribute definition,
including data type and coding is in Section 4.2.3.4.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

16

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

codeList

The set of codes specifying the type of clinicalactivities that resulted in placing documents in thisFolder.

comments

Comments associated with the Folder.

entryUUID

A globally unique identifier used to manage theentry.

homeCommunityId

A globally unique identifier for a community.

lastUpdateTime

Most recent point in time that the Folder has been
modified.

patientId

The patientId represents the subject of care of
documents within the Folder.

title

The name of the Folder.

uniqueId

Globally unique identifier for the Folder.

X

X

X

X

Exchange

Object Lifecycle

The lifecycle status of the Folder

Descriptive

availabilityStatus

Security&Privacy

Description

Patient identity

Folder Metadata
Attribute

Provenance

Table 4.1.3.4-1: Folder Metadata Attribute Definition

X

X
X

X

X
X
X

X

X

X
X

X

X

4.2 ebRIM Representation
460

465

This section details the representation of the metadata objects and their attributes using classes
provided by OASIS ebXML RegRep 3.0 specification at http://docs.oasisopen.org/regrep/v3.0/regrep-3.0-os.zip.
The Electronic Business using eXtensible Markup Language (ebXML) Registry and Repository(RegRep) specification describes a way to implement registry and repository servers and clientsusing standard interfaces, protocols and an information model for publishing, management,
discovery and retrieval of arbitrary content and metadata that describes it.
The ebXML RegRep specification is made of two parts:

470•

ebRIM: The "ebXML Registry Information Model version 3.0" (ebRIM) defines thetypes of metadata and content that can be stored in an ebXML Registry.

•ebRS: The "ebXML Registry Services Specification version 3.0" (ebRS) defines theservices and protocols for an ebXML Registry.

IHE highly constrains the use of ebRIM and ebRS in Document Sharing profiles to fit therequirements for expression of metadata objects and to communicate the objects between actors.
This section focuses on expression of the objects, and IHE transactions and profiles detail thecommunication.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

17

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
475

480

485

490

495

When document sharing was first introduced in IHE, XDS was the only document sharing
model. In the initial XDS Profile, the Document Registry could be implemented as an adaptor toan ebXML Registry. As such, all XDS content is valid in terms of the ebRIM, but XDS
introduces additional restrictions on the data that may be transmitted. Only a limited number ofthe classes in ebRIM are supported by XDS and the contents and semantics of those classes arefurther restricted. While an XDS Registry may be implemented as an adaptor to an ebXML
Registry, or without an underlying ebXML Registry, it should not be assumed that features
available from a pure ebXML Registry are available in an IHE environment. Features of an
ebXML Registry should be considered as not available unless they are explicitly defined byindividual IHE profiles.
Now that document sharing in IHE has grown beyond the XDS model, Document Sharing
metadata applies to profiles beyond XDS. In those other environments, it is highly unlikely to be
implemented using an ebXML Registry.
IHE excludes the requirements found in ebRIM 3.0 Section 2.5.9 which state that "eachRegistryObject instance MUST have a life cycle status indicator." For some RegistryObjects thelife cycle status indicator is required by IHE, and this requirement is stated within IHE’s
description of use of the object. For other objects, where a requirement is not explicitly stated by
IHE, the life cycle status indicator is optional.
IHE Technical Framework documentation conventionally refers to the ebRIM namespace using
the “rim:” prefix, for example rim:ExtrinsicObject, rim:RegistryPackage, rim:Slot,
rim:Classification, etc.
Table 4.2-1: ebRIM/Document Sharing Correspondence
Document Sharing
Object/Association

ebRIM class

DocumentEntry

rim:ExtrinsicObject

SubmissionSet

rim:RegistryPackage

FolderMemberOf
Relationship

rim:Association

The DocumentEntry object type is modeled through the rim:ExtrinsicObject class.
500

505

The SubmissionSet and Folder object types are conveyed through the rim:RegistryPackage class.
Since the ebRIM standard does not allow for subclassing the RegistryPackage class, these two
objects are implemented as rim:RegistryPackages. A rim:Classification is used to distinguishbetween the SubmissionSet and Folder object types.
The HasMember and Relationship Association concepts are conveyed through therim:Association class.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

18

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
4.2.1 Metadata Object Types
4.2.1.1 DocumentEntry

510

The DocumentEntry does not contain the contents of the document; instead it contains attributes
describing the document. Further details regarding the DocumentEntry object type can be foundin Section 4.1.1.
Figure 4.2.1.1-1 represents the DocumentEntry and its attributes. Detailed descriptions of all theattributes of a DocumentEntry are described in Section 4.2.3.2.

Figure 4.2.1.1-1: DocumentEntry Metadata Attributes (Informative)

515
The abstract concept of a DocumentEntry is expressed through an ebRIM RegistryPackageclassified as a DocumentEntry.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

19

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

Figure 4.2.1.1-2: UML diagram for rim:ExtrinsicObject (Informative)

520
Figure 4.2.1.1-2 represents rim:ExtrinsicObject as a structure made of classes and attributes ofthe ebRIM subset used for Document Sharing. This diagram is read from left to right andrim:ExtrinsicObject is considered as the root class.
525

530

The expression of the DocumentEntry is done by mapping the abstract DocumentEntry metadata
attributes into rim:ExtrinsicObject class attributes, elements and other associated classes. This
mapping uses, wherever possible, the parts of rim:ExtrinsicObject as intended (such as Name,
Description and ExternalIdentifier), and holds the healthcare specific attributes in general
purpose Slots or Classifications.
Requirements for matching SubmissionSet.patientId to included or referenced DocumentEntries’
patientId are detailed in Section 4.2.2.1.1.
4.2.1.1.1 DocumentEntry types

535

As described in Section 4.1.1, there are two DocumentEntry types: Stable Document Entry and
On-Demand Document Entry. A Stable Document Entry is an XDSDocument Entry with
objectType equal to the UUID for Stable (see Section 4.2.5.2 for the UUID). An On-Demand
DocumentEntry has an objectType equal to the UUID for on-demand (see Section 4.2.5.2 for the
UUID). Each Stable DocumentEntry represents a single document which is identified by theuniqueId attribute.
4.2.1.2 SubmissionSet

540

The abstract concept of a SubmissionSet is expressed through an ebRIM RegistryPackageclassified as a SubmissionSet. The SubmissionSet bundles DocumentEntry, Folder and
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

20

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Association objects for submission. Further details regarding the SubmissionSet object type canbe found in Section 4.1.1.

545

Figure 4.2.1.2-1: UML diagram for SubmissionSet (Informative)

550

This expression is done by mapping the abstract SubmissionSet metadata attributes into,
wherever possible, the parts of RegistryPackage as intended and holding the healthcare-specificattributes in general-purpose Slots and Classification. An ebRIM Classification class is used to
identify a RegistryPackage as a SubmissionSet versus a Folder.
A SubmissionSet has a set of attributes that are described in Section 4.1.3.3 SubmissionSet
Metadata.
SubmissionSets exist for two reasons:
1. To support atomic submissions555

2. To provide a permanent record of:•the existence and status of the submission•

the Folders and DocumentEntry objects and Associations included in the submission

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

21

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

Figure 4.2.1.2-2: SubmissionSet Metadata Attributes (Informative)

560
The value of the patientId attribute of the DocumentEntry objects that a SubmissionSet contains
shall match the value of the patientId attribute on the SubmissionSet itself.
Requirements for matching the value of SubmissionSet.patientId to the value of Patient Id inreferenced DocumentEntry objects are detailed in Section 4.2.2.1.1.
565

Immutability of Submission Sets: Submission Sets are immutable; that is, after they aresubmitted, they can never be changed. No associations to or from the submission set can becreated later on.
4.2.1.2.1 Creating a SubmissionSet object from a RegistryPackage element

570

A SubmissionSet object shall be created from a RegistryPackage element by labeling it with aClassification of type urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd. A receiver of
metadata shall accept the Classification element encoded within the RegistryPackage element oron the same level as the RegistryPackage. The following XML example demonstrates these twovalid approaches to encoding the Classification.
Classification encoded inside the RegistryPackage object

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

22

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
575

580

<RegistryPackage id="SubmissionSetId"><rim:Classification
classifiedObject="SubmissionSetId"
classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"
id="urn:uuid:1d4d08bc-85cc-4596-8fdc-4b5410a6feae"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"/></RegistryPackage>

585

Classification encoded outside the RegistryPackage object

590<RegistryPackage id="SubmissionSetId"></RegistryPackage><rim:Classification
classifiedObject="SubmissionSetId"
classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"
id="urn:uuid:1d4d08bc-85cc-4596-8fdc-4b5410a6feae"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
/>

595
Item

Description

Classification/@classifiedObject

The @id attribute of the RegistryPackage being classified.

Classification/@classificationNode

A fixed value identifying the type of object the RegistryPackage represents.
Accepted values:
urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd

Classification/@id

Symbolic id or UUID identifying this Classification. See Section 4.2.3.1.5 for details.

Classification/@objectType

Fixed value as specified by ebRIM. Optional upon submission of objects, required
upon retrieval. If set, must be "urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification".

This Classification shall not contain other Slot, Name, Description, Classification, or External
Identifier elements except as described above.
4.2.1.3 Folder
600

The abstract concept of a Folder is expressed through an ebRIM RegistryPackage classified as
Folder (see the UML representation of the ebRIM RegistryPackage, Figure 4.2.1.2-1). A Folder
is used to bundle DocumentEntry objects. Further details regarding the Folder object type can befound in Section 4.1.1.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

23

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

605

Figure 4.2.1.3-1: UML diagram for Folder (Informative)

610

This expression is done by mapping the abstract Folder metadata attributes into, wherever
possible, the parts of RegistryPackage as intended, and holds the healthcare-specific attributes ingeneral purpose Slots and Classifications. An ebRIM Classification class is used to identify a
RegistryPackage as a Folder versus a SubmissionSet.
Folders shall not be nested inside other Folders. The value of the patientId attribute of theDocumentEntry objects it contains shall match the value of the patientId attribute on the folder
itself.

615
Figure 4.2.1.3-2: Folder Metadata Attributes (Informative)

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

24

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
4.2.1.3.1 Creating a Folder object from a RegistryPackage element

620

A Folder object shall be created from a RegistryPackage element by labeling it with aClassification of type urn:uuid:d9d542f3-6cc4-48b6-8870-ea235fbc94c2. A receiver of metadata
shall accept the Classification element encoded within the RegistryPackage element or on thesame level. The following XML example demonstrates these two valid approaches to encoding
the Classification.
Classification encoded inside the RegistryPackage object

625

630

635

<…>
<RegistryPackage id="Fol"><!-- Classify registry package Fol as being a Folder --><Classification
classificationNode="urn:uuid:d9d542f3-6cc4-48b6-8870-ea235fbc94c2"
classifiedObject="Fol"id="IdExample_066"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"/></RegistryPackage><…>

Classification encoded outside the RegistryPackage object
640

645

650

<RegistryPackage id="Fol">…
</RegistryPackage><!-- Classify registry package as Folder --><Classification
classificationNode="urn:uuid:d9d542f3-6cc4-48b6-8870-ea235fbc94c2"
classifiedObject="Fol"id="IdExample_066"
objectType="urn:oasis:names:tc:ebXMLregrep:ObjectType:RegistryObject:Classification"
/>
<…>

Item

Description

Classification/@classifiedObject

The @id attribute of the RegistryPackage being classified.

Classification/@classificationNode

A fixed value identifying the type of object the RegistryPackage represents.
Accepted values:
Folder: urn:uuid:d9d542f3-6cc4-48b6-8870-ea235fbc94c2

Classification/@id

Symbolic id or UUID identifying this Classification. See Section 4.2.3.1.5 for details.

Classification/@objectType

Fixed value as specified by ebRIM. Optional upon submission of objects, required
upon retrieval. If set, must be "urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification".

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

25

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
This Classification shall not contain other Slot, Name, Description, Classification, or External
Identifier elements except as described above.
4.2.1.4 Registry Object List
655

In submission requests and query responses, a Registry Object List contains a list of Folders,SubmissionSets, DocumentEntries and Associations.
Figure 4.2.1.4-1 shows in detail the content of the rim:RegistryObjectList used to exchange
Document Sharing metadata; a subset of the ebXML Registry Information Model (ebRIM).

660
Figure 4.2.1.4-1: Registry Object List (Informative)

The following XML example demonstrates the encoding of several metadata objects grouped
within a rim:RegistryObjectList:
665

670

<rim:RegistryObjectList><rim:RegistryPackage id="SubmissionSet01"> ... </rim:RegistryPackage><rim:Association id="Document01InSubmissionSet01" ... /><rim:ExtrinsicObject id="Document01"> ... </rim:ExtrinsicObject></rim:RegistryObjectList>

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

26

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
4.2.2 Association Types

675

All relationships between metadata objects are handled through Associations. An Association isan object that describes a named relationship between two metadata objects. The relationshipbetween the DocumentEntry and the Document it represents is made with theDocumentEntry.uniqueId attribute, and not an Association since the Document is not a metadata
object.
Associations can be used to build relationships between:

680•

A SubmissionSet and a DocumentEntry – SS-DE HasMember•

A SubmissionSet and a Folder – SS-FD HasMember•

A Folder and a DocumentEntry – FD-DE HasMember•

A SubmissionSet and an Association – SS-HM HasMember•

A DocumentEntry and another DocumentEntry – RelationshipOnce deprecated, a DocumentEntry shall not be referenced by future associations.
685

The abstract concept of a HasMember or Relationship Association is expressed through an
ebRIM Association illustrated in the diagram below. This expression is done by mapping theabstract Association metadata attributes into Association class attributes and other associatedclasses. Further details regarding the Association object type can be found in Section 4.1.2.

690
Figure 4.2.2-1: Association (Informative)

695

Figure 4.2.2-1 represents the attributes of an Association. This diagram demonstrates that thevarious HasMember and Relationship Associations inherit the attributes from the Association
class, and that the SS-DE HasMember (SubmissionSet to DocumentEntry) also has thesubmissionSetStatus metadata attribute in addition to the Association class attributes. All
Associations shall have an id (entryUUID) attribute. It may have UUID or symbolic format
depending on where they are used. Symbolic format is allowable only in submissions.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

27

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Associations have 3 other required attributes (see Figure 4.2.2-1):
700•sourceObject•

targetObject•

associationType

These attributes can be thought to make a small sentence:•705

sourceObject AssociationType targetObject

The sentence is composed of noun-verb-object for example:•

Folder HasMember DocumentEntry

Graphically this example Association looks like:

710

Figure 4.2.2-2: Folder HasMember DocumentEntry (Informative)

Association Type formatting
An Association type shall be specified as a URN.
715

The sourceObject and targetObject are UUID or symbolic format depending on where they areused. Symbolic format is allowable only in submissions. The status attribute shall not be
submitted but shall be returned from queries.
The valid Association types are specified in the following table.
Table 4.2.2-1: Association Types
Meaning

Association Type

Membership in a Registry Package (SubmissionSet or
Folder)urn:oasis:names:tc:ebxmlregrep:AssociationType:HasMember

Replace

urn:ihe:iti:2007:AssociationType:RPLC

Transformation

urn:ihe:iti:2007:AssociationType:XFRM

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

28

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Meaning

Association Type

Addendum

urn:ihe:iti:2007:AssociationType:APND

Replace with Transformation

urn:ihe:iti:2007:AssociationType:XFRM_RPLC

Digital Signature

urn:ihe:iti:2007:AssociationType:signs

Snapshot of On-Demand document entry

urn:ihe:iti:2010:AssociationType:IsSnapshotOf

720
Example of basic Association725<rim:Association
id=”urn:uuid:95e9115b-3d90-46ae-9610-ed34fd683d96”
status=”urn:oasis:names:tc:ebxml-regrep:StatusType:Approved”
associationType=”urn:ihe:iti:2007:AssociationType:RPLC”
sourceObject=”urn:uuid:3cce0135-cedb-4a26-ba00-8698ee8dde04”
targetObject=”urn:uuid:e0985823-dc50-45a5-a6c8-a11a829893bd”/>

4.2.2.1 HasMember
730

735

In the Document Sharing abstract metadata model, many different relationships are defined
between SubmissionSet, DocumentEntry and Folder objects. In this section, each of these
relationships is given its own name, like SS-DE HasMember SubmissionSetHasMemberDocumentEntry. In the underlying ebRIM model, all of these
relationships are created using the ebRIM HasMember Association type.
Note: There are four variants of the HasMember Association. See Section 4.1.2 for an overview.

4.2.2.1.1 SS-DE HasMember

740

HasMember - a DocumentEntry shall be submitted as part of a SubmissionSet by connecting theobjects with a HasMember Association. This is shown as SS-DE HasMember in Figure 4.1-1.
DocumentEntries may be included in a SubmissionSet in two ways: inclusion by value andinclusion by reference.
SubmissionSet Association labeling
Two types of Association labels are defined: original (submission by value), or reference(Submission by reference). This enables finding the SubmissionSet that first submitted the
document.

745

Submission of an original Document (inclusion by value)
When the creating entity has a new document to be submitted, it shall submit a DocumentEntryby value in the SubmissionSet. This means that the DocumentEntry (and corresponding
Document) are part of the submission. The HasMember Association shall contain a slot with thename SubmissionSetStatus with the value set to original.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

29

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
750

All DocumentEntries submitted in a SubmissionSet, included by value, shall have their patientId
attribute set to the same value. The value of the SubmissionSet.patientId attribute shall match thevalue of the DocumentEntry.patientId attribute. The metadata of this submission contains the
SubmissionSet, the DocumentEntry, and the original SS-DE HasMember Association connecting
them.

755
Figure 4.2.2.1.1-1: SubmissionSet HasMember DocumentEntry (Informative)

When submitting an existing document by value:

760•

The targetObject shall contain the Id of the DocumentEntry object.

•

The sourceObject shall contain the Id of the SubmissionSet object

The following XML example demonstrates how to encode a submission by value.
765

770

775

780

<rim:Association
associationType="urn:oasis:names:tc:ebxmlregrep:AssociationType:HasMember"sourceObject="SubmissionSet01"
targetObject="Document01"><rim:Slot name="SubmissionSetStatus"><rim:ValueList><rim:Value>Original</rim:Value></rim:ValueList></rim:Slot></rim:Association>

Submission of a reference to an existing Document (inclusion by reference)
Existing documents can be referenced by a SubmissionSet. This means that the DocumentEntry(and corresponding Document) are not part of the submission; they have been previously
submitted and already exist in the receiving actor. Documents that were submitted in a previous
SubmissionSet may be referenced by subsequent SubmissionSets. In this case, the HasMember
Association shall contain a slot with the name SubmissionSetStatus with the value set toReference.
The value of the SubmissionSet.patientId attribute is not required to match the value of theDocumentEntry.patientId attribute of a DocumentEntry included by reference. The metadata of
this submission contains the SubmissionSet. The SS-DE HasMember Association with the
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

30

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
785‘Value=Reference’ connects the SubmissionSet to a DocumentEntry already present in thereceiving actor.

Figure 4.2.2.1.1-2: Submission of a reference to an existing Document (Informative)

790
When submitting a reference to an existing document:•

The targetObject shall contain the Id of the DocumentEntry object.

•

The sourceObject shall contain the Id of the SubmissionSet object.

The following XML example demonstrates how to encode a submission by reference.
795

800

805

<rim:Association
associationType="urn:oasis:names:tc:ebxmlregrep:AssociationType:HasMember"sourceObject="SubmissionSet01"
targetObject="Document01"><rim:Slot name="SubmissionSetStatus"><rim:ValueList><rim:Value>Reference</rim:Value></rim:ValueList></rim:Slot></rim:Association>

4.2.2.1.2 SS-FD HasMember
810

HasMember - Submit a Folder. The submission includes the Folder object and a HasMember
Association linking the Folder to the SubmissionSet. This is shown as SS-FD HasMember inFigure 4.2.2.1.2-1. The value of the SubmissionSet.patientId attribute shall match the value ofthe Folder.patientId attribute.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

31

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

815

Figure 4.2.2.1.2-1: SubmissionSet HasMember Folder (Informative)

When submitting a Folder:•

The targetObject shall contain the Id of the Folder object.

•

The sourceObject shall contain the Id of the SubmissionSet object.

820
Example SubmissionSet – Folder HasMember Association825<rim:Association
associationType=”urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember”
sourceObject=”SubmissionSet01”
targetObject=”Folder01”></rim:Association>

The sourceObject and targetObject attributes are shown using symbolic names to reference theother objects in the submission. UUID format values could have been used if those objects werecoded that way.
830

4.2.2.1.3 FD-DE HasMember
FD-DE HasMember - a HasMember Association linking a Folder to a DocumentEntry. The
value of the Folder.patientId attribute shall match the value of the DocumentEntry.patientId
attribute.

835
Figure 4.2.2.1.3-1: Folder HasMember DocumentEntry (Informative)

Linking documents to a folder
840

A document can be linked to a Folder to indicate that this document is a member of a particularFolder. This is colloquially called “putting the document into the folder.” Each FD-DE
HasMember Association shall be accompanied by a SS-HM HasMember Association that links

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

32

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
the FD-DE HasMember Association with the SubmissionSet object (see Section 4.2.2.1.4). See
Section 4.2.2.15 for the four ways a DocumentEntry can be added to a Folder.
When adding a DocumentEntry to a Folder:845•

The targetObject shall contain the Id of the DocumentEntry object.

•

The sourceObject shall contain the Id of the Folder object.
Example Folder HasMember Association

850<Association
id=”FolderToDocAssoc”
associationType=”urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember”
sourceObject=”urn:uuid:e0985823-dc50-45a5-a6c8-a11a8298aabb”
targetObject=”urn:uuid:e0985823-dc50-45a5-a6c8-a11a829893bd”/>

855<Association
associationType=”urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember”
sourceObject=”SubmissionSet”
targetObject=”FolderToDocAssoc”/>

860

In the first association, since both the sourceObject and targetObject attributes in the example are
in UUID format (and not symbolic id format), the Folder and the DocumentEntry referenced
could be part of this submission or already present in the registry.

865

The second Association shown is a SS-HM HasMember which is between the SubmissionSet
and the first Association documenting which submission added the DocumentEntry to the
Folder.
4.2.2.1.4 SS-HM HasMember

870

HasMember - a HasMember Association linking a SubmissionSet to a FD-DE HasMember
Association, which is in turn an Association between a Folder and a DocumentEntry. This isshown as SS-HM HasMember in Figure 4.2.2.1.5-1. This shall be used to record theSubmissionSet responsible for adding the DocumentEntry to the Folder. The values ofSubmissionSet.patientId, Folder.patientId, and DocumentEntry.patientId shall all be the same.
This kind of Association is used when adding a document to an existing Folder. It is used to
identify the entity that created the link between a particular document and a particular Folder andshall be as follows:875•

The targetObject shall contain the Id of the Association that links the DocumentEntry andthe Folder.

•

The sourceObject shall contain the Id of the SubmissionSet object.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

33

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
4.2.2.1.5 Adding DocumentEntries to Folders
A DocumentEntry can be added to a Folder in one of four ways:
880

1. The DocumentEntry can be submitted as part of the Folder in a single submission.
2. The DocumentEntry and Folder are already present. The new submission makes theDocumentEntry a member of the Folder by adding the Association.
3. The DocumentEntry is already present. The new submission includes the Folder and the
Association to make the DocumentEntry part of the Folder.

885

4. The Folder is already present. The new submission includes the DocumentEntry and the
Association to make the DocumentEntry part of the Folder.
Scenario 1 - DocumentEntry submitted as part of the Folder in a single submission.
The simplest scenario submits all related objects in one submission set, as shown below.

890
Figure 4.2.2.1.5-1: Scenario 1 - DocumentEntry submitted as part of the Folder(Informative)

Scenario 2 – Add existing DocumentEntry to existing Folder
895

Documents can be placed in a Folder at a later date and time, as shown in Figures 4.2.2.1.5-2 and4.2.2.1.5-3. In this case, the SubmissionSet SS03 which links to FD-DE HasMember will nothave as member either the DocumentEntry or the Folder that correspond to the referenced
document and Folder.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

34

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

900

Figure 4.2.2.1.5-2: Scenario 2 - Existing DocumentEntry and existing Folder (Informative)

Figure 4.2.2.1.5-3: Scenario 2 - Add existing DocumentEntry to existing Folder(Informative)

905

Scenario 3 – Folder submitted and existing DocumentEntry added to it
When a new Folder is submitted, an existing DocumentEntry can be added to that Folder. In thiscase, the SubmissionSet object will not contain the DocumentEntry metadata that correspond to
the referenced document.

910

Figure 4.2.2.1.5-4: Scenario 3 - Starting point - Existing DocumentEntry (Informative)
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

35

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

Figure 4.2.2.1.5-5: Scenario 3 - Folder submitted and existing DocumentEntry added to it(Informative)

915

Scenario 4 – DocumentEntry submitted and added to existing Folder
When a new DocumentEntry is submitted, it can be added to an existing folder. In this case, theSubmissionSet object will not contain the Folder metadata that correspond to the referenced
Folder.

920

Figure 4.2.2.1.5-6: Scenario 4 - Starting point - Existing Folder (Informative)

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

36

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

Figure 4.2.2.1.5-7: Scenario 4 - DocumentEntry submitted and added to existing Folder(Informative)

925

4.2.2.2 Document RelationshipDocument relationships are association types used to link two DocumentEntry objects anddeclare a semantic relationship between them. Receiving a document relationship Association
triggers specific processing in the receiving actor in some profiles. This is documented in the
Expected Actions section of the relevant transaction in an IHE profile.

930

A document relationship refers to any of the relationships listed in Table 4.2.2.2-1 Document
Relationships. The document relationship semantics (except Signs) are defined in HL7 ClinicalDocument Architecture (CDA) Release 2.
Table 4.2.2.2-1: Document Relationships
Relationship

935

Definition

APND (append)

The current document is an addendum to the parent document.

RPLC (replace)

The current document is a replacement of the parent document.

XFRM (transform)

The current document is a transformation of the parent document.

XFRM_RPLC (transformwith replace)

The current document is both a transformation and a replacement of the parent
document.

Signs

The current document is a Digital Signature which signs the parent document.

Is Snapshot of

The current document is a snapshot in time of the parent which shall be an ondemand document

Adapted from HL7 CDA Release 2, Committee Ballot 2

To create a document relationship in the registry, a creating entity shall submit:
A new Document (DocumentEntry).
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

37

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________An Association linking the new document to an existing document.
940

945

950

The Association type defines the document relationship. The new DocumentEntry and the
Association must be submitted in the same SubmissionSet. The existing DocumentEntry must be
an Approved object already in the registry (see Section 4.2.3.2.2,
DocumentEntry.availabilityStatus). The identity (entryUUID) of the existing document will beknown because the creating entity assigned the entryUUID prior to submission or discovered it(e.g., under XDS via Registry Stored Query [ITI-18]).
The targetObject attribute of the Association is the entryUUID representing the existing
DocumentEntry known to the receiving entity. This entryUUID may have been discovered via
Registry Stored Query [ITI-18], or other means.
Note to implementers: An XDS Document Source using saved UUIDs in future transactions can run into consistency
problems. A second XDS Document Source can deprecate any document. Once a document is deprecated, new
Associations to that document cannot be accepted by the XDS Document Registry. The saved UUID will point to
the deprecated document and not the replacement document.

A submitting actor creates a document relationship by submitting a SubmissionSet containing:
DocumentEntry – this describes the new document being submitted
955

The uniqueId attribute shall be unique
The entryUUID shall be unique or a symbolic Id as described in Section 4.2.3.1.5.
Association – this links the original DocumentEntry (already known to the receiving entity) with
the new DocumentEntry being submitted.

960

The targetObject attribute of the Association object references the existing
DocumentEntry known to the receiving entity.
The sourceObject attribute of the Association object references the DocumentEntry
contained in the SubmissionSet.
The Association Type is one of the relationships in Table 4.2.2.2-1: Document Relationships.

965

Associations of type XFRM, APND, RPLC, and XFRM_RPLC may include documentation
describing the Association (type of transformation, reason for replacement, etc.). If one of theseis included, it shall be specified as a Classification on the Association as shown in the example
below.
Example of a partial submission request:

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

38

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

970

975

980

985

990

995

1000

<rim:Association
associationType="urn:ihe:iti:2007:AssociationType:XFRM"
sourceObject="source"
targetObject="urn:uuid:XXX"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Association"
id="IdExample_042"><rim:Classification
classificationScheme="urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3"
classifiedObject="IdExample_042"
id="IdExample_043"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="LanguageExample"><rim:Name><rim:LocalizedString value="Translation into LanguageExample" /></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Example translation types</rim:Value></rim:ValueList></rim:Slot></rim:Classification></rim:Association><rim:ExtrinsicObject id=”source”
objectType=” urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1”>. . .
</rim:ExtrinsicObject>

Since the targetObject always references an object already in the Registry; it shall be coded in
UUID format, as shown.
A stub DocumentEntry is shown to illustrate the id reference coding (Association sourceObject
attribute referencing the id attribute of the DocumentEntry/ExtrinsicObject in the submission).

1005

The new documents (related to original document by RPLC, APND, XFRM, or XFRM_RPLC
Associations) shall be assigned their own uniqueId attribute unrelated to the original document’s
uniqueId. See IHE ITI TF-2x: Appendix B "Definition of uniqueIds".
See ITI TF-1: 10.4.10 for further detail on the use and meaning of document relationships.
4.2.2.2.1 APND

1010

The submission shall contain a new DocumentEntry and associated Document and an APND
Association linking this new DocumentEntry with an existing DocumentEntry. This newDocument/DocumentEntry forms an addendum to the existing Document/DocumentEntry. The
APND Association may include documentation describing the addendum (e.g., reason for adding
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

39

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
the addendum, etc.) The APND relationship leaves the original DocumentEntry with its
availabilityStatus unchanged (Approved).

1015
Figure 4.2.2.2.1-1: Starting Point (Informative)

Figure 4.2.2.2.1-2: New DocumentEntry and Document forming an addendum to an
existing DocumentEntry/Document (Informative)

1020
Interactions between XFRM and APND
A transformation (connected to original document with XFRM Association) is an alternate formof an original document. Therefore, a transformation shall not be appended (APND).
4.2.2.2.2 XFRM
1025

1030

The submission shall contain a new DocumentEntry and associated Document and a XFRM
Association linking this new DocumentEntry with an existing DocumentEntry. This newDocument/DocumentEntry defines a transformation of the existing Document/DocumentEntry.
The XFRM Association may include documentation describing the transformation (e.g., reason
for transformation, etc.). The XFRM relationship leaves the original DocumentEntry with its
availabilityStatus unchanged (Approved).

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

40

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

Figure 4.2.2.2.2-1: Starting Point (Informative)

1035
Figure 4.2.2.2.2-2: New DocumentEntry/Document defining a transformation of an
existing DocumentEntry/Document (Informative)

4.2.2.2.3 RPLC
1040

The submission shall contain a new DocumentEntry and associated Document and a RPLC
Association linking this new DocumentEntry with an existing DocumentEntry. The newDocumentEntry and Document are considered the approved version of the document; theexisting DocumentEntry and Document become a deprecated version. The RPLC Association
may include documentation describing the replacement (e.g., reason for replacement, etc.).

1045

Figure 4.2.2.2.3-1: Starting Point (Informative)

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

41

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

1050

Figure 4.2.2.2.3-2: New DocumentEntry and Document replacing existing
DocumentEntry/Document (Informative)

RPLC interactions with other Associations
1055

The submission of a RPLC relationship shall change the availabilityStatus of the original
DocumentEntry to Deprecated. All transformations (XFRM) and addenda (APND) of theoriginal document shall also be deprecated.
Figures 4.2.2.2.3-2 and 4.2.2.2.3-3 show a new DocumentEntry/Document replacing atransformation (XFRM) of an existing DocumentEntry/Document:

1060

Figure 4.2.2.2.3-3: New DocumentEntry/Document defining a transformation of an
existing DocumentEntry/Document – Starting point (Informative)

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

42

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

Figure 4.2.2.2.3-4: New DocumentEntry/Document replacing a transformation (XFRM) of
an existing DocumentEntry/Document (Informative)

1065
Figures 4.2.2.2.3-4 and 4.2.2.2.3-5 show a new DocumentEntry/Document replacing an
addendum (APND) of an existing DocumentEntry/Document.

1070

Figure 4.2.2.2.3-5: New DocumentEntry and Document forming an addendum to an
existing DocumentEntry/Document – Starting point (Informative)

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

43

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

Figure 4.2.2.2.3-6: New DocumentEntry/Document replacing an addendum (APND) of an
existing DocumentEntry/Document (Informative)

1075
Only an Approved DocumentEntry is replaceable. The most recent version of a DocumentEntry
carries an availabilityStatus of Approved while older versions carry an availabilityStatus of
Deprecated.
1080

A transformation (connected to original DocumentEntry with XFRM Association) is an alternate
form of an original document. Therefore, a transformation is permitted to be replaced (RPLC).

1085

When a DocumentEntry is replaced and that DocumentEntry is a member of one or more
Folders, new FD-DE HasMember and SS-HM HasMember Associations shall be created by thereceiving actor, connecting the replacement DocumentEntry to each Folder that held the original
DocumentEntry as a member. The result is that a Folder contains both the original andreplacement DocumentEntry differentiated by their availabilityStatus.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

44

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

Figure 4.2.2.2.3-7: DocumentEntry submitted as part of the Folder in a single submission– Starting point (Informative)

1090
Figure 4.2.2.2.3-8: Submission of a new DocumentEntry replacing the DocumentEntry
part of an existing Folder (Informative)

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

45

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
4.2.2.2.4 XFRM_RPLC
1095

1100

The submission contains a new DocumentEntry and associated Document and a XFRM_RPLC
Association linking this new DocumentEntry with an existing DocumentEntry. This newDocument/DocumentEntry defines a transformation of the existing Document/DocumentEntry
that replaces the existing Document/DocumentEntry. The XFRM_RPLC Association may
include documentation describing the transformation/replacement (e.g., reason, etc.). The
XFRM_RPLC can be thought of as a RPLC followed immediately by a XFRM. All behavior
associated with a RPLC association shall also apply to the XFRM_RPLC association.

Figure 4.2.2.2.4-1: Starting Point (Informative)

1105

Figure 4.2.2.2.4-2: New DocumentEntry/Document defining a transformation of an
existing DocumentEntry/Document that replaces this existing DocumentEntry/Document(Informative)1110
4.2.2.2.5 Signs
The submission contains a new DocumentEntry and associated Document and a Signs
Association linking this new DocumentEntry with an existing DocumentEntry. This newDocument is a Digital Signature that signs the existing Document.
1115

An ebRIM Association with associationType of signs shall be used to link a DocumentEntry
representing a Digital Signature with the DocumentEntry representing the document being
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

46

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
signed. Details of how Digital Signatures are represented are found in the ITI Digital Signatures
Profile.
In constructing this Association, the attributes are:1120

sourceObject: references the DocumentEntry representing the Digital SignaturetargetObject: references the DocumentEntry representing the document being signed
associationType: signs

1125

Figure 4.2.2.2.5-1: Starting Point (Informative)

Figure 4.2.2.2.5-2: New DocumentEntry/Digital signature document signing the existing
DocumentEntry/Document (Informative)1130
4.2.2.2.6 IsSnapshotOf

1135

When the content of an On-Demand DocumentEntry is retrieved, the retrieved version can besaved in a Document Repository as a Document and recorded in the Document Registry as aStable DocumentEntry. When this happens, the saved version is linked to the On-Demand
DocumentEntry through the IsSnapshotOf Association.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

47

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Example IsSnapshotOf Association<rim:Association
associationType=”urn:ihe:iti:2010:AssociationType:IsSnapshotOf”
sourceObject=”Snapshot”
targetObject=”urn:uuid:e0985823-dc50-45a5-a6c8-a11a829893bd”/>

1140<rim:ExtrinsicObject id=”Snapshot”
objectType=”urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1”>. . .
</rim:ExtrinsicObject>

1145
This Association shall be submitted together with the Stable DocumentEntry representing thesnapshot of the On-Demand Document. The sourceObject attribute references the snapshot andthe targetObject references the On-Demand DocumentEntry already in the Document Registry.
The Document Registry Actor shall verify upon submission:
1150

1155

•

The sourceObject references a DocumentEntry in the submission•

The targetObject references a DocumentEntry in the Registry•

The targetObject DocumentEntry has availabilityStatus of Approved•

Verify that the objectType attribute of the sourceObject DocumentEntry is
urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1 (Stable)•

Verify that the objectType attribute of the targetObject DocumentEntry is
urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248 (On-Demand)

Note: this example does not show the SubmissionSet object or the SubmissionSet to DocumentEntry HasMember
association.

4.2.3 Metadata Attributes
1160

This section details the coding of metadata attributes using in Document Sharing profiles.
4.2.3.1 General Information about Metadata Attributes
4.2.3.1.1 Attribute Value Length1165

All attribute values are limited by the size specifications of ebRIM version 3.0. The ebRIM Slots
are limited to 256 characters in length. Individual components of ebRIM Classification, ebRIM
ExternalIdentifier, and ebRIM Name are strings, attributes, and Slots. Those that are ebRIM
Slots are limited to 256 characters in length. The other components are naturally short (e.g.,language).

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

48

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
4.2.3.1.2 Creating Coded Attributes
1170

Many attributes of DocumentEntry, SubmissionSet, and Folder (see Table 4.2.3.2-1, Table
4.2.3.3-1 and Table 4.2.3.4-1) are coded attributes defined as ebRIM Classifications. Three
details are required to describe a coded value:
1. Code Value – contains the assigned value of the code.
2. Code Display Name - The display name used to represent the code (code values are notnecessarily human-friendly). Must be non-zero length.

1175

3. Coding Scheme - The name/identification of the coding scheme that the code comes
from.
These three values combine to define a single coded element. An example of a coded attribute ina submission request is:

1180

1185

1190

1195

<rim:Classification
classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7e362475b143a"classifiedObject="ExampleDocument"
id="IdExample_046"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="10160-0"><rim:Name><rim:LocalizedString value="History of Medication Use"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>2.16.840.1.113883.6.1</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

A code is constructed as a Classification object. The relevant parts of this classification are
described in Table 4.2.3.1.2-1 below.
1200

Table 4.2.3.1.2-1: Classifications and Descriptions
Item

Description

Classification/@classificationScheme

This UUID defines which metadata attribute this Classification is supplying avalue for. See Section 4.2.5 for a list of all values for this attribute. In the example
above, this attribute indicates that the Classification contains a value for theDocumentEntry.classCode metadata attribute.

Classification/@classifiedObject

This references the object in metadata being classified. In the example thisreferences the DocumentEntry object that the classCode value is for. Note that theClassification must also be embedded within the referenced object, thus providing
dual context.
This value must match the @id attribute of the containing ExtrinsicObject or

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

49

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Item

Description
RegistryPackage.

Classification/@id

UUID identifying this Classification.

Classification/@objectTypeebXML requires this for Query/Response type transactions but not for submissions.
When required, contains the value shown “urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification”
The code value. Required. The example above shows a code value of“10160-0”.

Classification/@nodeRepresentation
Name/LocalizedString/@value

The code displayName. The example above shows a display name of"History of Medication Use ".

Slot/@name

Fixed value that must always be the string “codingScheme”.

Slot/ValueList/Value/text()

The code codingScheme. Shall have exactly one value. In the example above it is"2.16.840.1.113883.6.1".

This Classification shall not contain other Slot, Name, Description, Classification, or External
Identifier elements except as described above.
1205

The creating entity defines the local configuration for each coded metadata attribute.
Specifically, it defines for each code:
Name of the coding scheme – shall be used in the codingScheme Slot.
Value for the code – shall be used in the nodeRepresentation attribute.

1210

One or more display Name values for each code value – A name shall be used in the Name
element. It is expected, but not enforced, that the name should be semantically consistent withthe code value. (This permits submitting using different local languages to a single Document
Registry.)
Some coded attributes allow multiple values. EventCodeList is an example. These attributes may
contain the letters ‘List’ in their name. These codes are XML encoded identically to the above
example except the entire Classification element may be repeated to specify additional values.

1215

1220

Note: the attribute DocumentEntry.languageCode attributed is not encoded as a coded attribute as shown above. See Table
4.2.3.1.7-2 for details.
Note: The same code value may have multiple valid human readable representations in different languages or in different,
but semantically equivalent, wording. An XDS Affinity Domain MAY restrict the displayName values it accepts
from XDS Document Sources to a list of allowed values. It is the XDS Document Consumer’s responsibility toresolve code values in metadata into human readable display values. A XDS Document Consumer may use thedisplayName found in the metadata provided by the XDS Document Source, or it may choose another local
designation for the code, for example to translate it from English into French.

4.2.3.1.3 Creating External Identifiers
1225

Several attributes of DocumentEntry, SubmissionSet and Folder (Table 4.2.3.2-1, Table, 4.2.3.31 and Table 4.2.3.4-1) are identifiers defined as ebRIM ExternalIdentifiers. These identifiers,

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

50

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
such as patient IDs or document unique IDs are considered to be real-world identifiers that haveglobal meaning external to an ebXML registry or other transaction.

1230

1235

1240

The identifiers consist of a single, opaque string stored in the value attribute of anExternalIdentifier element. The meaning and format depend on the particular identifier. An
example of an identifier in a submission request is:<rim:ExternalIdentifier
identificationScheme="urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446"
value="6578946^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO"
id="IdExample_051"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier"registryObject="DocumentEntry01"><rim:Name><rim:LocalizedString value="XDSDocumentEntry.patientId"/></rim:Name></rim:ExternalIdentifier>

Table 4.2.3.1.3-1: Identifiers and Descriptions
Item
ExternalIdentifier/@identificationScheme

Fixed value denoting the specific identifier. See Section 4.2.5 for a list of valid
values.

ExternalIdentifier/@value

The identifier value.

ExternalIdentifier/@id

UUID identifying this ExternalIdentifier.

ExternalIdentifier/@objectTypeebXML requires this for Query/Response type transactions but not for submissions.
When required, contains the value: "urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier"This references the object in metadata being identified. In the example thisreferences the DocumentEntry object that the patient identifier value is for. Note that
the ExternalIdentifier element must also be embedded within the referenced object,thus providing dual context.
This value must match the @id attribute of the containing ExtrinsicObject orRegistryPackage.

ExternalIdentifier/@registryObject

Name/LocalizedString/@value

1245

Description

The readable name for the identifier. Fixed value according to the particular
identifier.

This ExternalIdentifier shall not contain other Slot, Name, Description, Classification, orExternal Identifier elements except as described above.
4.2.3.1.4 Creating Author Attribute

1250

The author attributes of DocumentEntry and SubmissionSet represent the humans and/or
machines that authored the document or SubmissionSet. The author attribute defines a structure
to hold its sub-attributes that are individually defined in Sections 4.2.3.1.4.1 through 4.2.3.1.4.5.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

51

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

1255

•

authorPerson – zero or one•

authorInstitution – zero or more•authorRole – zero or more•authorSpecialty – zero or more•authorTelecommunication – zero or more

At least an authorPerson, authorTelecommunication or authorInstitution sub-attribute shall bepresent when the author attribute is included in the metadata.
Coding:1260

1265

The author attribute is as an ebRIM Classification which contains sub-attributes in ebRIM Slots.
An instance of the author Classification shall be considered a single author. Multiple authors arevalid and are represented by multiple author ebRIM Classification objects. For the author
metadata attribute, the value of classificationScheme is different for DocumentEntries andSubmissionSets; see Sections 4.2.3.2.1 and 4.2.3.3.1, respectively. The nodeRepresentation
attribute shall be empty.
The following example shows the definition of a single author for a DocumentEntry.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

52

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

1270

1275

1280

1285

1290

1295

<rim:Classification
classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"classifiedObject="ExampleDocument"
id="IdExample_045"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation=""><!-- nodeRepresentation intentionally left blank--><rim:Slot name="authorPerson"><rim:ValueList><rim:Value>^Welby^Marcus^^MD^Dr</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="authorInstitution"><rim:ValueList><rim:Value>Some Hospital^^^^^^^^^1.2.3.5.8.9.1789.45</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="authorRole"><rim:ValueList><rim:Value>name of role</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="authorSpecialty"><rim:ValueList><rim:Value>specialty of author</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="authorTelecommunication"><rim:ValueList><rim:Value>^^Internet^john.doe@healthcare.example.org</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

1300
The following example shows the definition of a single author for a SubmissionSet.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

53

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

1305

1310

1315

1320

1325

1330

<rim:Classification
classificationScheme="urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d"classifiedObject="theSubmission"
id="Id_045"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation=""><!-- nodeRepresentation intentionally left blank--><rim:Slot name="authorPerson"><rim:ValueList><rim:Value>^Welby^Marcus^^MD^Dr</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="authorInstitution"><rim:ValueList><rim:Value>Some Hospital^^^^^^^^^1.2.3.5.8.9.1789.45</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="authorRole"><rim:ValueList><rim:Value>name of role</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="authorSpecialty"><rim:ValueList><rim:Value>specialty of author</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="authorTelecommunication"> <!-- may be multivalued --><rim:ValueList><rim:Value>^^Internet^john.doe@healthcare.example.org</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

1335
The author Classification shall not contain other Slot, Name, Description, Classification, orExternal Identifier elements except as described above.
4.2.3.1.4.1 authorInstitution
Description:
1340

Represents a specific healthcare facility under which the human and/or machines authored the
document or SubmissionSet. This is a sub-attribute of the author attribute.
Coding:
The format of the authorInstitution value is XON. See Table 4.2.3.1.7-2 for description of XON
format.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

54

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
1345

The value is coded as an optional ebRIM Slot within an author Classification. See Section
4.2.3.1.4 for an example of author Classification. There may be multiple values within theebRIM Slot.
This example shows the authorInstitution Slot with two elements reflecting two names for thesame organization.

1350

1355

<rim:Slot name="authorInstitution"><rim:ValueList><rim:Value>MercyHospital</rim:Value><rim:Value>NY Mercy Hospital^^^^^^^^^1.2.3.9.1789.45</rim:Value></rim:ValueList></rim:Slot>

4.2.3.1.4.2 authorPerson
Description:
1360

Represents the humans and/or machines that authored the document or SubmissionSet within theauthorInstitution. The author may be the patient itself. This is a sub-attribute of the author
attribute.
Coding:

1365

The format of the authorPerson value is XCN; see Table 4.2.3.1.7-2 for description of XCNformat.
The value is coded as a required ebRIM Slot within an author Classification; see Section
4.2.3.1.4 for an example of author Classification. There may be only a single value within theebRIM Slot.
This example shows the authorPerson Slot holding the required single value.

1370

1375

<rim:Slot name="authorPerson"><rim:ValueList><rim:Value>^Welby^Marcus^^MD^Dr</rim:Value></rim:ValueList></rim:Slot>

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

55

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
4.2.3.1.4.3 authorRole
Description:
1380

A string that represents the role of the author with respect to the patient at the time the document
or SubmissionSet was created. This is a sub-attribute of the author attribute. If this is a codedvalue, it should follow the CX encoding in Table 4.2.3.1.7-2
Coding:
The format of the authorRole value is String.

1385

The value is coded as an optional ebRIM Slot within an author Classification. See Section
4.2.3.1.4 for an example of author Classification. There may be multiple values within theebRIM Slot.

1390<rim:Slot name="authorSpecialty"><rim:ValueList><rim:Value>Cardiologist</rim:Value></rim:ValueList></rim:Slot>

4.2.3.1.4.4 authorSpecialty
1395

Description:
Represents a specific specialty within a healthcare facility under which the human and/or
machines authored the document or SubmissionSet. This is a sub-attribute of the author attribute.
If this is a coded value, it should follow the CX encoding in Table 4.2.3.1.7-2.
Coding:

1400

The format of the authorSpecialty value is String.
The value is coded as an optional ebRIM Slot within an author Classification. See Section
4.2.3.1.4 for an example of author Classification. There may be multiple values within theebRIM Slot.

1405<rim:Slot name="authorSpecialty"><rim:ValueList><rim:Value>Cardiology</rim:Value><rim:ValueList></rim:Slot>

1410

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

56

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
4.2.3.1.4.5 authorTelecommunication
Description:
Represents the telecommunications address (e.g., email) of the document or SubmissionSet
author. This is a sub-attribute of author.
1415

Coding:
The format of the authorTelecommunication value is XTN; see Table 4.2.3.1.7-2 for descriptionof XTN format.

1420

1425

The value is coded as an optional ebRIM Slot within an author Classification. See Section
4.2.3.1.4 for an example of author Classification. There may be multiple values within theebRIM Slot.
<rim:Slot name="authorTelecommunication"><rim:ValueList><rim:Value>^^Internet^john.doe@healthcare.example.org</rim:Value></rim:ValueList></rim:Slot>

4.2.3.1.5 UUIDs
1430

UUIDs shall be formatted according to RFC 4122. Furthermore, values 10 through 15 shall beformatted in hexadecimal using only lower case ‘a’-‘f’. An example of a properly formatted
UUID is:urn:uuid:10b545ea-725c-446d-9b95-8aeb444eddf3

1435

Alternatively, symbolic Ids may be used when referencing objects in the same submission
request. A symbolic Id is any string which does not start with urn:uuid:. For example, in XDS, a
Document Source may create a submission request using symbolic Ids; the Document Registry
replaces these with assigned properly formatted UUIDs upon acceptance of the submission.
Once a UUID-format Id value is assigned to a Registry Object, that value is permanent and shallnot be changed.
4.2.3.1.6 Extra Metadata Attributes

1440

Metadata beyond what is specified in this volume may be specified by a creating entity. This
extra metadata may be ignored by the recipient but its presence shall not cause an error.
The following conditions shall apply.
1. All extra metadata content shall be in the form of Slots.

1445

2. These Slots may be attached to SubmissionSet, DocumentEntry, Folder, or Association
objects.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

57

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
3. Receiving actors shall ignore extra metadata elements they do not understand.
4. If an actor accepts extra metadata Slots (no warning on submission) then it shall returnthese Slots in query results.
5. The Name attribute of extra Slots shall conform to the following rules:
1450a) Name shall be a valid URN.
b) Name shall begin with 'urn:' prefix (formatted as a valid URN).
c) The prefix 'urn:ihe' shall not be used.
6. Note that ebRIM requires that the name of a Slot be unique within the containing object(DocumentEntry, SubmissionSet, Folder, or Association).

1455

4.2.3.1.7 Metadata Attribute Data types
Several data types are used in the tables below describing the Document Entry, Folder andSubmission Set metadata. These data types are derived from other standards, and encoded as
described in Table 4.2.3.1.7-2.

1460

For the data types derived from HL7 standards, IHE Document Sharing Profiles require that thedefault HL7 separators in Table 4.2.3.1.7-1 be used to represent the structure of HL7 v2.5 datatypes:
Table 4.2.3.1.7-1: HL7 Separators
HL7 Separators

1465

Field Separator|

Component Separator^

Subcomponent Separator&

Repetition Separator~

Table 4.2.3.1.7-2: Data Types (previously Table 4.1-3)
Data Type

Source Standard

Encoding Specification

Code

ITI TFSee Section 4.2.3.1.2

CX

HL7 V2.5 IdentifierThis is an identifier. HL7 Identifier type CX consists of several components,
but this specification restricts them to the use of two components, the Id
Number, and the Assigning Authority (AA). The Assigning Authority
identifies the "domain" over which the Id Number represents a unique entity.
Furthermore, the AA is characterized by a Universal Id and Universal Id
Type. In Document Sharing profiles, ISO Object Identifiers (see OID below)
must be used as Universal Id. Therefore, Universal Id Type is always ISO.
The required format is:
IdNumber^^^&OIDofAA&ISO
No other values/modifications in other components or subcomponents areallowed. Specifically, components 2 and 3 shall be empty as listed above.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

58

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Data Type

Source Standard

Encoding Specification
An explicit example is:543797436^^^&1.2.840.113619.6.197&ISO
Note that the '&' character must be properly encoded in the XML content.

CXi

HL7 V2 IdentifierThis is an identifier of a reference object, distinct from the use of CX for
Patient Identifiers. HL7 Identifier type CX consists of several components.
•
CXi.1 shall be present and hold the identifier value.
•
CXi4 (Assigning Authority) shall be present when the identifier in
CXi.1 is not globally unique and holds the identifier of the"domain" over which the ID Number represents a unique entity. It
is formatted just like CX.4 in the CX datatype above.
•
CXi.5 (Identifier Type Code) shall be present and chosen fromeither a URN defined by IHE, or a locally defined value.
•
When the homeCommunityId is known, CX.6 shall be present andholds the homeCommunityId encoded as ISO. See CX.4 in the CX
datatype above.
•
No other components shall be present.
The following IHE values for CXi.5 (Identifier Type Codes) are defined:
urn:ihe:iti:xds:2013:uniqueId
This code shall be used when the identifier is a uniqueID from
Document Sharing metadata attribute.
For example if uniqueID equals “1.3.6367.3.7^11379”, andhomeCommunityID is “1.2.3.4” then the CXi value is11379^^^&1.3.6367.3.7&ISO^urn:ihe:iti:xds:2013:uniqueId^&1.2.
3.4&ISO

urn:ihe:iti:xds:2013:accession
This code shall be used when the identifier is an accession number. It
shall contain•
The accession number and•for accession values that are not globally unique, the Assigning
Authority shall be included.
For example when the accession number has a value of “2013001” andthe assigning authority is “1.2.3.4.5.6” then the CXi value is2013001^^^&1.2.3.4.5.6&ISO^urn:ihe:iti:xds:2013:accession

urn:ihe:iti:xds:2013:referral
Referral number and assigning authority shall be present.
For example:
201300001^^^1.2.3.4.5.6^urn:ihe:iti:xds:2013:referral

urn:ihe:iti:xds:2013:order
Order number and assigning authority shall be present.
For example:
134467653^^^1.2.3.4.5.42.1^urn:ihe:iti:xds:2013:order

urn:ihe:iti:xdw:2013:workflowId
This code shall be used when the identifier is an XDW workflow
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

59

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Data Type

Source Standard

Encoding Specification
identifier. The workflow identifier shall be an OID. Only the CXi.1 andCXi.5 component shall be present:
For example, if the workflow identifier is “2.16.840.1” the value ofreferenceIdList attribute is:
2.16.840.1^^^^urn:ihe:iti:xdw:2013:workflowId

DTM

HL7 V2.5
Date Time

This is a date/time value, represented as precisely as possible. All date timevalues in the registry are stored using Coordinated Universal Time [UTC].
"UTC" implies that time shall be converted from/to the local time.
The format of these values is defined as the following regular expression:
YYYY[MM[DD[hh[mm[ss]]]]]
Where:YYYY is the four digit year i.e., 2006
MM is the two digit month 01-12, where Jan is 01, Feb is 02, etc.
DD is the two digit day of the month 01-31
HH is the two digit hour, 00-23, where 00 is midnight, 01 is 1 am, 12 isnoon, 13 is 1 pm, etc.
mm is the two digit minute, 00-59
ss is the two digit seconds, 00-59
The following are legal date time values with increasing precision
representing the date and time January 2, 2005, 3:04:05am
2005
200501
20050102
2005010203
200501020304
20050102030405

Field

HL7 V2.5 Message
Segment

Specified as the Field identifier, followed by a pipe (|) and then the data
value characterized as a corresponding HL7 V2.5 data type as defined in
HL7 standard. Note that if a Document Sharing data type is based on an
HL7 data type, then the Document Sharing data type is used to represent thevalue.
An example of field Patient Identifier List (the third field of PID segment) is
as follows:
PID-3|DTP-1^^^&1.3.6.1.4.1.21367.2005.3.7& ISO

Integer

W3C XML Schema Part
2

XML Schema Part 2: Data Types Section 3.3.13

MIME TypeRFC 2046

https://www.iana.org/assignments/media-types

OID

ISO Object Identifier

An ISO Object identifier. Limited in length to 64 characters, and made up ofcharacters from the set [0-9.]. It must start with an integer, and is followed
by one or more additional integer values, separated by periods. Integers arecharacterized without leading 0 digits unless the value is zero.
(e.g.,1.3.6.1.4.1.21367.2005.3.7)
In the attribute tables below, when an OID format is specified, it shall follow
the assignment and format rules defined for document UID in ITI TF-2x:
Appendix B

OID URN

RFC 3061. OID in URN
syntaxSee RFC 3061. An example is urn:oid: 1.3.6.1.4.1.21367.2005.3.7.

Predefined URN

RFC 2141

Specific URNs are defined and assigned in this framework. An example is

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

60

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Data Type

Source Standard

Encoding Specification
urn:ihe:iti:2007:ResponseStatusType:PartialSuccess

SHA1

RFC 3174

Document hash calculated with SHA1 algorithm. The encoding is the
Lexical Representation of hexBinary ([0-9a-fA-F]).

StringXML

XML Schema Part 2: Data Types Section 3.2.1

URI

RFC 2616

Uniform Resource Identifier

UTF-8

RFC 3629

Unicode standard

UUID

RFC 4122

A DCE Universally Unique Identifier, represented in registry attributes
using the URN syntax for UUIDs
e.g.,urn:uuid:9e0110f8-4748-4f1e-b0a8-cecae32209c7
Some Document Sharing profiles may allow use of symbolic Ids in certain
conditions or locations.

XCN

HL7 V2.5 Extended
Person Name

This data type describes a person along with the identifier by which he is
known in some domain (e.g., the XDS affinity domain), using the HL7 v2.5
XCN data type. This data type contains, amongst others:
Identifier
Last NameFirst Name
Second and Further Given Names
SuffixPrefixAssigning Authority
All of the HL7 v2.5 fields may be specified as optional components with thefollowing restrictions:
Either name or an identifier shall be present. Inclusion of other components
is optional provided the slot value length restrictions imposed by
ebXML3.0, 256 characters, is not exceeded.
If component 1 (Id Number) is specified, component 9 (Assigning
Authority) shall be present if available.
The XCN Component 9 is subject to the same the restrictions as defined for
the CX data type component 4. Thus: the first subcomponent shall be empty,
the second subcomponent must be an ISO OID (e.g., 1.2.840.113619.6.197),
and the third subcomponent shall read ‘ISO’.
Any empty component shall be treated by the Document Registry as not
specified. This is in compliance with HL7 v2.5.
Trailing delimiters are recommended to be trimmed off. Receiving actors
shall ignore trailing delimiters. This is in compliance with HL7 v2.5.
An example of person name with Id number using this data type is asfollows:
11375^Welby^Marcus^J^Jr. MD^Dr^^^&1.2.840.113619.6.197&ISO

XON

HL7 V2.5 Organization
Name

This type provides the name and identification of an organization. This
specification restricts the coding to the following fields:
XON.1 – Organization Name – this field is required
XON.6.2 – Assigning Authority Universal Id – this field is required if
XON.10 is valued and not an OID
XON.6.3 – Assigning Authority Universal Id Type – this field is required if
XON.10 is valued and not an OID and shall have the value "ISO"XON.10 – Organization Identifier – this field is optional

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

61

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Data Type

Source Standard

Encoding Specification
No other fields shall be specified. The XON data type in Document Sharing
metadata results in a valid encoding of an HL7 v2.5 XON encoding, with the
exception of length limitations. Component length restrictions areunobserved; however, the total length including delimiters shall not exceed
the limit of the ebXML Slot Value.
It is common for organizations to be uniquely identified by an OID. In suchcases, the Organization (Identifier component 10) may contain theorganization’s OID. If the Organization Identifier is not an OID, themetadata use assumes that it has been assigned so that the composite Id
created by combining components 6 and 10 is a unique identifier for theorganization.
Examples:Some HospitalSome Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45
Some Hospital^^^^^&1.2.3.4.5.6.7.8.9.1789&ISO^^^^45

XTN

HL7 V2.5
Extended
Telecommunications
Number
Chapter 2A Section 89

This type provides the telecommunications address of an entity (for example
author, intended recipient). This specification restricts the use to thefollowing fields:
For phone numbers:
XTN.2 – Indicates the type of phone number (Optional)
XTN.3 – The type of telecommunication address (Required)
XTN.5 – Country Code (Optional)
XTN.6 – Area/City Code (Optional)
XTN.7 – Subscriber Number (Required)
XTN.8 – Extension (Optional)
For email addresses:
XTN.2 – Optional. If present, SHALL have the value "NET".
XTN.3 –SHALL have the value "Internet".
XTN.4 – the telecommunications address, e.g., name@example.com(Required)No other fields shall be specified. The XTN data type in Document Sharing
metadata results in a valid encoding of an HL7 V2.5 XTN data type.
Use of ITU E.123 notation for telephone numbers is recommended.
Example:^^Internet^radiology@healthcare.example.org org (e-mail address)^PRS^PH^^31^^(042) 1123 4567 (national phone number)^PRS^PH^^^^+31 42 1123 4567 (international phone number)

4.2.3.1.8 General format of DocumentEntry, Folder and SubmissionSet attributetablesThe metadata attribute definition tables each have five columns:
1470

1. The first column contains the name used to refer to the attribute in IHE documentation. It
is not always related to the way the attribute is coded in ebRIM.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

62

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
2. The second column contains a brief description of the attribute.

1475

3. The third column identifies how the value of the attribute is coded. Table 4.2.3.1.7-2 lists
all the possible types of data. In isolated instances a value may be complex enough torequire a separate section to describe, in which case a reference to that section is
included. For example, author.
4. The fourth column describes where to find the encoding of the attribute within theDocumentEntry/Folder/SubmissionSet. In other words, how the value of the attribute isheld within the enclosing object. The possible values in this column are:

1480

1485

•

ebRIM Classification – indicates that the attribute is coded as a classification object,see Section 4.2.3.1.2.

•

XML attribute – indicates that the attribute is the value of an XML attribute of theenclosing object. For example:<rim:ExtrinsicObject ... id="urn:uuid:a6e06ca8-0c75-4064-9e5c-88b9045a96f6"... >Showing the entryUUID attribute coded as a value of the idXML attribute of the ExtrinsicObject
representing the DocumentEntry. Note that the name of the attribute – entryUUID – is notreferenced in its actual representation.
•
1490

1495

ebRIM Slot– indicates that the attribute is encoded within a slot. For example:<rim:ExtrinsicObject ...>
<rim:Slot name="creationTime"><rim:ValueList><rim:Value>20041225212010</rim:Value></rim:ValueList></rim:Slot>Showing the creationTime attribute within a Slot of the ExtrinsicObject representing
the Document Entry. In this case the name of the slot is the attribute name.
•ebRIM ExternalIdentifier– indicates the value is held within an ExternalIdentifier
object, using the XML element rim:ExternalIdentifier, providing an additional
identifier to a registry object (see Section 4.2.3.1.3).

•

ebRIM Name– indicates this attribute is held in an ebRIM Name object. For example
the title attribute is:

1500

1505

<rim:Name><rim:LocalizedString value="ExampleTitle"/></rim:Name>.

•

ebRIM Description– indicates this attribute is held in an ebRIM Description object.
For example the comment attribute is:

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

63

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

1510<rim:Description><rim:LocalizedString value="ExampleComment"/></rim:Description>.

5. The fifth column links to a section which describes the attribute in more detail, including
further detail and examples regarding its use and its coding.
4.2.3.1.9 Metadata Attribute Cardinality
1515

Metadata attributes have several dimensions of cardinality.
One dimension is whether or not any value is required, or the attribute is optional. Thisdimension is dependent on the profile, actor and transaction in which the attribute is being
specified and is detailed in Sections 4.2.3.2, 4.2.3.3 and 4.2.3.4.

1520

1525

Another dimension is the required handling of the receiving actor. This is specified within eachtransaction, or in the case of XDS Document Registry, Section 4.3.1.2.
The last dimension of cardinality is whether the attribute can contain multiple values and, when
multiple values are allowed, how multiple values are expressed. This is specified within the text
explaining each of the attributes in Sections 4.2.3.2.1 through 4.2.3.2.27 for DocumentEntry,
Sections 4.2.3.3.1 through 4.2.3.3.12 for SubmissionSet, and Sections 4.2.3.4.1 through 4.2.3.4.9
for Folder. The text indicates whether multiple values are allowed and, if they are allowed, how
to express them. For example, for codes expressed using a Classification element, if multiple
values are allowed they are coded by specifying multiple Classification elements.
4.2.3.1.10

1530

classificationScheme vs. classificationNode

Classification elements in ebRIM use one of two attributes: classificationScheme andclassificationNode.
The attributes serve two different purposes:
•

1535

1540

classificationScheme
As the name suggests, the classificationScheme attribute specifies the category("scheme") by which the referenced object is being classified. For example,
classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" indicates thata DocumentEntry is being classified by practiceSetting. The classificationScheme does
not indicate WHICH practiceSetting applies; that information is recorded elsewhere in
the Classification element.
The use of classificationScheme corresponds with "external classifications", as describedin ebRIM. This is the predominant type of classification in Document Sharing.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

64

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________•

classificationNode
The classificationNode attribute provides an actual classification for the referenced
object. For example, classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5b4633d873bdd" indicates that a RegistryPackage is a SubmissionSet.

1545

1550

The use of classificationNode corresponds with "internal classifications", as described in
ebRIM. Document Sharing metadata uses this type of classification for three purposes:•

To label a RegistryPackage as a SubmissionSet•

To label a RegistryPackage as a Folder•

To label a SubmissionSet, Folder, or DocumentEntry as containing Limited Metadata

4.2.3.2 DocumentEntry Attributes
The following metadata attributes shall be used to describe a Document Sharing DocumentEntry.
Optionality is determined by specific transaction requirements; see Section 4.2.3.1.9.

1555

Each attribute shown below is an attribute on the DocumentEntry object. The attribute name isdefined with a prefix of the object type of DocumentEntry when referenced by other objects, forexample DocumentEntry.patientId.
Please see Section 4.2.3.1.8 for the general format of DocumentEntry, Folder and SubmissionSet
attribute tables.
Table 4.2.3.2-1: DocumentEntry Metadata Attribute Definition (previously Table 4.1-5)
DocumentEntry
Metadata
Attribute

Description

Data Type(Table4.2.3.1.7-2)

Coding(Section
4.2.3.1.8)

Detail(See
Section)author

The humans and/or machines that authored the
document. This attribute contains the subattributes: authorInstitution, authorPerson,
authorRole, authorSpecialty andauthorTelecommunication.

See Section
4.2.3.2.1

ebRIM
Classification

4.2.3.2.1

availabilityStatus

The lifecycle status of the DocumentEntry

Predefined
URN

XML attribute

4.2.3.2.2

classCodeThe code specifying the high-level use
classification of the document type (e.g., Report,
Summary, Images, Treatment Plan, Patient
Preferences, Workflow).

Code

ebRIM
Classification

4.2.3.2.3

comments

Comments associated with the Document.

StringebRIM
Description

4.2.3.2.4

confidentialityCode

The code specifying the level of confidentiality of
the Document.

Code

ebRIM
Classification

4.2.3.2.5

creationTime

The time the author created the document. Shall
have a single value.

DTM

ebRIM Slot

4.2.3.2.6

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

65

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
DocumentEntry
Metadata
Attribute

Description

Data Type(Table4.2.3.1.7-2)

Coding(Section
4.2.3.1.8)

Detail(See
Section)entryUUID

A globally unique identifier used to identify theentry.

UUID

XML attribute

4.2.3.2.7

eventCodeList

This list of codes represents the main clinical acts,
such as a colonoscopy or an appendectomy, being
documented.

Code

ebRIM
Classification

4.2.3.2.8

formatCode

Code globally uniquely specifying detailed
technical the format of the document.

Code

ebRIM
Classification

4.2.3.2.9

hash

Hash of the Document itself.

SHA1 hashebRIM Slot

4.2.3.2.10

healthcareFacility
TypeCodeThis code represents the type of organizationalsetting of the clinical encounter during which the
documented act occurred.

Code

ebRIM
Classification

4.2.3.2.11

homeCommunityId

A globally unique identifier for a community.

OID URN

home XMLattribute

4.2.3.2.12

languageCode

Specifies the human language of character data inthe document. Using codes from IETF RFC 5646

StringebRIM Slot

4.2.3.2.13

legalAuthenticator

Represents a participant who has legallyauthenticated or attested the document within theauthorInstitution.

XCN

ebRIM Slot

4.2.3.2.14

limitedMetadata

Indicates whether the Document Entry was createdusing the less rigorous requirements of metadata as
defined for the Metadata-Limited Document
Source.

4.2.3.2.29

ebRIM
Classification

4.2.3.2.29

mimeType

MIME type of the document.

MIME typeXML attribute

4.2.3.2.15

objectType

The type of DocumentEntry

UUID

XML attribute

4.2.3.2.30

patientId

The patientId represents the subject of care of the
document.

CX

ebRIM
ExternalIdentifier

4.2.3.1.3

practiceSettingCode

The code specifying the clinical specialty where
the act that resulted in the document was
performed (e.g., Family Practice, Laboratory,
Radiology).

Code

ebRIM
Classification

4.2.3.2.17

referenceIdList

A list of identifiers that apply to the document.

CXi

ebRIM Slot

4.2.3.2.28

repositoryUniqueId

The globally unique identifier of the repository
where the document is stored.

OID

ebRIM Slot

4.2.3.2.18

serviceStartTime

The start time the service being documented took
place.

DTM

ebRIM Slot

4.2.3.2.19

serviceStopTime

The stop time the service being documented took
place.

DTM

ebRIM Slot

4.2.3.2.20

sizeSize in bytes of the document.

Integer

ebRIM Slot

4.2.3.2.21

sourcePatientId

The sourcePatientId represents the subject of care
medical record Identifier (e.g., Patient Id) in thelocal patient Identifier Domain of the Document
Source.

CX

ebRIM Slot

4.2.3.2.22

sourcePatientInfo

This attribute contains demographic information of

CX

ebRIM Slot

4.2.3.2.23

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

66

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
DocumentEntry
Metadata
Attribute

Description

Data Type(Table4.2.3.1.7-2)

Coding(Section
4.2.3.1.8)

Detail(See
Section)the patient to whose medical record this document
belongs.

1560

title

The title of the document.

UTF-8

ebRIM Name

4.2.3.2.24

typeCode

The code specifying the precise type of documentfrom the user perspective (e.g., LOINC code).

Code

ebRIM
Classification

4.2.3.2.25

uniqueId

The globally unique identifier assigned by the
document creator to this document.

OID

ebRIM
ExternalIdentifier

4.2.3.1.3

URI

The URI for the document.

URI

ebRIM Slot

4.2.3.2.27

4.2.3.2.1 DocumentEntry.author
Description:
Represents the humans and/or machines that authored the document. See Section 4.2.3.1.4 fordetails on creating the structure.
The classificationScheme shall be urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d

1565

4.2.3.2.2 DocumentEntry.availabilityStatus
Description:
Represents the status of the DocumentEntry. A DocumentEntry shall have one of two availability
statuses:

1570

Approved:

The document is available for patient care.

Deprecated:

The document is obsolete.

This attribute is typically omitted in a submission of new documents. If present in a submission,
the submitted value is ignored. It is always set to Approved as a result of the successful
submission of new documents. It may be changed to Deprecated under the primary responsibilityof the creating entity.
1575

Coding:
The format of the availabilityStatus value is a URN.

1580

In a query response the value is coded in the status attribute of the ExtrinsicObject representing
the DocumentEntry and shall be "urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" or"urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated". The example below shows the status
attribute.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

67

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

1585<ExtrinsicObject
id="urn:uuid:fbeacdb7-5421-4474-9267-985007cd8855"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved">...

4.2.3.2.3 DocumentEntry.classCode
1590

1595

Description:
The code specifying the high-level use classification of the document type (e.g., Report,
Summary, Images, Treatment Plan, Patient Preferences, Workflow). The typeCode specifies theprecise type of document from the user perspective. Valid values for classCode attribute are
specified by the policies of the creating entity. It is recommended that the creating entity draws
these values from a coding scheme providing a coarse level of granularity (about 10 to 100
entries). For example, XDS specifies that the XDS Affinity Domain will establish this list.
Coding:

1600

There shall be exactly zero or one ebRIM Classification containing a classCode for any
DocumentEntry. See Section 4.2.3.1.2 for a description of coding an ebRIM Classification. For
the classCode metadata attribute, the classificationScheme shall be urn:uuid:41a5887f-88654c09-adf7-e362475b143a.
The following example specifies classCode=10160-0 with display name "History of Medication
Use" and coding scheme "2.16.840.1.113883.6.1" for the DocumentEntry labeled"ExampleDocument".

1605

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

68

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

1610

1615

1620

1625

<rim:Classification
classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"classifiedObject="ExampleDocument"
id="IdExample_046"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="10160-0"><rim:Name><rim:LocalizedStringvalue="History of Medication Use"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>2.16.840.1.113883.6.1</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

4.2.3.2.4 DocumentEntry.comments
Description:
Contains comments associated with the document.
Coding:Max length is unbounded.

1630

The value of the comments attribute is coded in XML as the "value" attribute of the
LocalizedString element within the ebRIM Description structure. There can be at most one
ebRIM Description structure per DocumentEntry.
The following example shows a comment for the document.

1635<rim:Description><rim:LocalizedString value = "comment associated with the Document"/></rim:Description>

4.2.3.2.5 DocumentEntry.confidentialityCode
1640

Description:
The code specifying the security and privacy tags of the document. These codes are set by policyof the participants in the exchange, e.g., XDS affinity domain. confidentialityCode is part of a
codification scheme.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

69

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

1645

1650

1655

The confidentialityCode can carry multiple vocabulary items. HL7 has developed anunderstanding of security and privacy tags that might be desirable in a Document Sharing
environment, called HL7 Healthcare Privacy and Security Classification System (HCS). The
following specification is recommended but not mandated by IHE, as the vocabulary bindings
are an administrative domain responsibility. The use of this method is up to the policy domainsuch as the XDS Affinity Domain or other Trust Domain where all parties including sender andrecipients are trusted to appropriately tag and enforce.
•[1…1] Confidentiality Security Classification Label Field•[0…*] Sensitivity Security Category Label Field•[0…*] Compartment Security Category Label Field•[0…*] Integrity Security Category Label Field•[0…*] Handling Caveat Security Category Field

In the HL7 Healthcare Privacy and Security Classification System In the HL7 Healthcare
Privacy and Security Classification (HCS) there are code systems specific to Confidentiality,
Sensitivity, Integrity, and Handling Caveats. Some values would come from a local vocabulary
as they are related to workflow roles and special projects.
1660

The decision to include a code is the responsibility of the publisher/sender (e.g., Access Control
decision) and is dependent on the Policy rules and Trust Framework in place for the exchange.
Use of Sensitivity tags expose the nature of the sensitivity and should be used only when theend-to-end confidentiality of the tags can be assured.
When using the HL7 Healthcare Privacy and Security Classification System (HCS):

1665

•

The confidentialityCode SHALL contain exactly one value from the HL7 code system
V:Confidentiality (@codeSystem=”2.16.840.1.113883.5.25” i.e., U, L, M, N, R, or V), toindicate the Confidentiality coding of the content.
•

1670

•

The confidentialityCode MAY contain values from the HL7 code system
V:InformationSensitivityPolicy (@codeSystem=”2.16.840.1.113883.1.11.20428”), toindicate the Sensitivity coding of the content.
•

1675

•

The value represents the most restrictive content in the identified document (aka.
High water mark).

Multiple values are all applicable to the content. This means that a consuming
system/user must have rights to all Sensitivity classes indicated.

The confidentialityCode MAY contain values from the HL7 code system V:Compartment(@codeSystem=”2.16.840.1.113883.1.11.20478”), to indicate the Compartment of thecontent.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

70

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
•
1680

•

The confidentialityCode MAY contain values from the HL7 code system
V:SecurityIntegrityObservationValue (@codeSystem=”2.16.840.1.113883.1.11.20469”),
to indicate the Integrity of the content.
•

•
1685

1690

Multiple values are all applicable to the content.

The confidentialityCode MAY contain values from the HL7 code system
V:SecurityControlObservationValue (@codeSystem=”2.16.840.1.113883.1.11.20471”),
to address the Handling Caveats that must be applied to the use of the content.
••

Multiple values are all applicable to the content. This means that a consuming
system/user must have rights to all Compartments indicated.

Multiple values all applicable to the content. A consuming system must enforce all
Handling Caveats indicated.

Other value-sets and codesystems MAY be used as agreed between the communicating
partners.

Coding:

1695

1700

Each confidentialityCode is coded within an ebRIM Classification object. See Section 4.2.3.1.2
for a description of coding an ebRIM Classification. There shall be zero or more ebRIM
Classification containing a confidentiality code (some profiles require at least one). Multiple
values of confidentialityCode are coded by specifying multiple classification objects. For theconfidentialityCode metadata attribute, the classificationScheme shall be urn:uuid:f4f85eace6cb-4883-b524-f2705394840f.
The following example shows two confidentialityCodes values. It specifies normal
confidentiality with code “N”, display name “Normal Clinical Data”, and coding scheme“2.16.840.1.113883.5.25”, and an obligation not to reuse with code ”NOREUSE”, display name“prohibit use beyond purpose of use”, and coding scheme “2.16.840.1.113883.1.11.20471", for
the DocumentEntry labeled “ExampleDocument”.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

71

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

1705

1710

1715

1720

1725

1730

1735

1740

<rim:Classification
classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
classifiedObject="ExampleDocument"
id="IdExample_046"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="N"<rim:Name><rim:LocalizedStringvalue="Normal Clinical Data"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>2.16.840.1.113883.5.25</rim:Value></rim:ValueList></rim:Slot></rim:Classification><rim:Classification
classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
classifiedObject="ExampleDocument"
id="IdExample_046"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="NOREUSE"><rim:Name><rim:LocalizedString value="prohibit reuse beyond purpose of use"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>2.16.840.1.113883.1.11.20471</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

4.2.3.2.6 DocumentEntry.creationTime
Description:
Represents the time the author created the document.
Coding:1745

Max length is 256 characters. The format of the creationTime value is DTM; see Table 4.2.3.1.72 for a description of DTM format.
The value is coded as a single value within an ebRIM Slot in the DocumentEntry.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

72

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
The following example shows a creationTime of December 25, 2004 21:20:10 Coordinated
Universal Time (UTC).
1750<rim:Slot name="creationTime"><rim:ValueList><rim:Value>20041225212010</rim:Value></rim:ValueList></rim:Slot>

1755
4.2.3.2.7 DocumentEntry.entryUUID
Description:
entryUUID is a globally unique identifier primarily intended for internal document management
purposes. In contrast, the uniqueId attribute is used for external references (e.g., links, etc.).
1760

Coding:Max length is unbounded. The format of the entryUUID value is UUID. Certain Document
Sharing transactions may allow symbolic Ids (anything that does not have the urn:uuid: prefix) tobe used in certain conditions.

1765

1770

The value of the entryUUID is coded in the id XML attribute on the ExtrinsicObject representing
the DocumentEntry. In the example below, the entryUUID is urn:uuid:a6e06ca8-0c75-40649e5c-88b9045a96f6<rim:ExtrinsicObject mimeType="application/pdf"
id="urn:uuid:a6e06ca8-0c75-4064-9e5c-88b9045a96f6"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"> …

4.2.3.2.8 DocumentEntry.eventCodeList
Description:
1775

1780

This list of codes represents the main clinical acts, such as a colonoscopy or an appendectomy,
being documented. In some cases, the event is inherent in the typeCode, such as a "History andPhysical Report" in which the procedure being documented is necessarily a "History andPhysical" act. An event can further specialize the act inherent in the typeCode, such as where it issimply "Procedure Report" and the procedure was a "colonoscopy". When defining the value setsfor eventCodes, they should not conflict with the values inherent in the classCode,practiceSettingCode or typeCode as such a conflict would create an ambiguous situation.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

73

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Coding:

1785

1790

1795

1800

1805

The eventCodeList is coded with ebRIM Classification objects. See Section 4.2.3.1.2 for a
description of coding an ebRIM Classification. There may be zero or more ebRIM
Classifications containing a code and additional eventCode entries are coded by specifying
multiple classification objects. For the eventCodeList metadata attribute, theclassificationScheme shall be urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4.
The following example specifies an eventCode="ExampleeventCode" with display name"eventCodeDisplayName" and coding scheme "Example Event Code Scheme" for theDocumentEntry labeled "ExampleDocument".
<rim:Classification
classificationScheme="urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
classifiedObject="ExampleDocument"
id="IdExample_048"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="ExampleeventCode"><rim:Name><rim:LocalizedString value="eventCodeDisplayName"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Example Event Code Scheme</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

1810
4.2.3.2.9 DocumentEntry.formatCode
Description:

1815

1820

The code specifying the detailed technical format of the document. Along with the typeCode, it
should provide sufficient information to allow potential consumer to know if it will be able toprocess the document.
The mimeType indicates the base format; the formatCode indicates the detailed-level technicalformat. The formatCode shall be sufficiently specific to ensure processing/display by identifying
a document encoding, structure and template (e.g., for a CDA Document, the fact that it complies
with a CDA schema, possibly a template and the choice of a content-specific style sheet). The
formatCode is often an indicator of the IHE Document Content Profile to which the document
conforms.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

74

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Format codes may be specified by multiple organizations. Format codes for Document Content
Profiles defined by the ITI domain shall be in URN format and have names with the prefix
urn:ihe:iti:1825

Format codes defined by other IHE domains shall have names with the prefix
urn:ihe:’domain initials’:

Format codes defined by non-IHE domains should be a valid unique URN.
Coding:
1830

1835

1840

1845

1850

1855

There shall be zero or one ebRIM Classification containing a formatCode. See Section 4.2.3.1.2
for a description of coding an ebRIM Classification. For the formatCode metadata attribute, theclassificationScheme shall be urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d. Any valid
URN may be used as a formatCode.
The following example using the XDS-SD document content profile specifies
formatCode="urn:ihe:iti:xds-sd:pdf:2008" with display name "XDS-Scanned Documents" andcoding scheme "urn" for the DocumentEntry labeled "ExampleDocument".
<rim:Classification
classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
classifiedObject="ExampleDocument"
id="IdExample_049"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="urn:ihe:iti:xds-sd:pdf:2008"><rim:Name><rim:LocalizedString value="XDS-Scanned Documents"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>1.3.6.1.4.1.19376.1.2.3</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

4.2.3.2.10

DocumentEntry.hash

Description:
1860

The hash of the contents of the document. If this attribute is present in a transaction, it may bevalidated; the rules for validation are specified in the relevant profile. If this attribute is missing,it may be created using the rules in the relevant profile.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

75

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Coding:Max length is 256 characters. The format of the hash value is SHA1 hash; see Table 4.2.3.1.7-2
for a description of SHA1.
1865

The value is coded as a case-insensitive single value within an ebRIM Slot in theDocumentEntry.
The following example shows a hash of da39a3ee5e6b4b0d3255bfef95601890afd80709.

1870

1875

<rim:Slot name="hash"><rim:ValueList><rim:Value>da39a3ee5e6b4b0d3255bfef95601890afd80709</rim:Value></rim:ValueList></rim:Slot>

4.2.3.2.11

DocumentEntry.healthcareFacilityTypeCode

Description:
This code represents the type of organizational setting of the clinical encounter during which the
documented act occurred.
1880

In some cases, the setting of the encounter is inherent in the typeCode, such as "Diabetes Clinic
Progress Note". healthcareFacilityTypeCode shall be equivalent to or further specialize the value
inherent in the typeCode; for example, where the typeCode is simply "Clinic Progress Note" andthe value of healthcareFacilityTypeCode is "private clinic".
Coding:

1885

1890

There shall be zero or one ebRIM Classification containing a healthcareFacilityTypeCode. See
Section 4.2.3.1.2 for a description of coding an ebRIM Classification. For thehealthcareFacilityTypeCode metadata attribute the classificationScheme shall be
urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1.
The following example specifies healthcareFacilityTypeCode ="ExamplehealthcareFacilityTypeCode " with display name"healthcareFacilityTypeCodeDisplayName " and coding scheme "Example Healthcare Facility
Scheme" for the DocumentEntry labeled "ExampleDocument".

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

76

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

1895

1900

1905

<rim:Classification
classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
classifiedObject="ExampleDocument"
id="IdExample_050"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="ExamplehealthcareFacilityTypeCode"><rim:Name><rim:value="healthcareFacilityTypeCodeDisplayName"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Example Healthcare Facility Scheme</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

1910
4.2.3.2.12

DocumentEntry.homeCommunityId

Description:
A globally unique identifier for a community where the DocumentEntry and document can beaccessed.
1915

Coding:Max length is unbounded. Contained in the ebRS ExtrinsicObject home attribute for the
ExtrinsicObject that corresponds to the DocumentEntry. It is an OID URN (see Table 4.2.3.1.72).
See ITI TF-2a: 3.18.4.1.2.3.8 and ITI TF-2b: 3.38.4.1.2.1.

1920<rim:ExtrinsicObject home="urn:oid:1.2.3" ...>...
</rim:ExtrinsicObject>

1925

4.2.3.2.13

DocumentEntry.languageCode

Description:
Specifies the human language of character data in the document.
Coding:
1930

Max length is 256 characters. The values of the attribute are language identifiers as described by
the IETF (Internet Engineering Task Force) RFC 5646.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

77

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________The value is coded as a single value within an ebRIM Slot in the DocumentEntry.
The following example shows a languageCode of en-CA.

1935

1940

<rim:Slot name="languageCode"><rim:ValueList><rim:Value>en-CA</rim:Value></rim:ValueList></rim:Slot>

4.2.3.2.14

DocumentEntry.legalAuthenticator

Description:
Represents a participant within the authorInstitution who has legally authenticated or attested the
document. Legal authentication implies that a document has been signed manually orelectronically by the legalAuthenticator.
1945

Coding:Max length is 256 characters. This attribute shall be absent if not applicable. The value is coded
as a single value within an ebRIM Slot in the DocumentEntry. The format of thelegalAuthenticator value is XCN; see Table 4.2.3.1.7-2 for description of XCN format.
The following example shows a legalAuthenticator of ^Welby^Marcus^^^ Dr^MD.

1950

1955

<rim:Slot name="legalAuthenticator"><rim:ValueList><rim:Value>^Welby^Marcus^^^Dr^MD</rim:Value></rim:ValueList></rim:Slot>

4.2.3.2.15

DocumentEntry.mimeType

Description:
MIME type of the document in the Repository
1960

Coding:Max length is unbounded. Shall have only a single value. Encoded in the ebRS ExtrinsicObject
mimeType attribute for the ExtrinsicObject that corresponds to the DocumentEntry. See ebRS
Schema RIM.XSD.
In this example the MIME type is “application/pdf”.

1965
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

78

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________<rim:ExtrinsicObject mimeType="application/pdf"
id="ExampleDocument"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1">

1970

4.2.3.2.16

DocumentEntry.patientId

Description:
The patientId represents the subject of care of the document. For XDS the patient identifier
domain is the XDS Affinity Domain Patient Identifier Domain (XAD-PID).
1975

Within a submission request, the value of patientId of the DocumentEntries shall match that of
the SubmissionSet.
Coding:
The format of the patientId value is CX, see Table 4.2.3.1.7-2.
It shall contain two parts:

1980

Assigning Authority Domain Id (organization that issued the Id),
An Id from the above Assigning Authority.
No other values are allowed, as specified for the CX type. Using HL7 terminology, no othervalues are allowed in the components of the coded value, nor are further subcomponents
allowed.

1985

Coded as an ebRIM ExternalIdentifier. See Section 4.2.3.1.3 for a description of coding an
ebRIM ExternalIdentifier. This element references, and is contained in, the ExtrinsicObject
representing the DocumentEntry. There shall be zero or one patientId value.
In the example below the patientId is 6578946^^^&1.3.6.1.4.1.21367.2005.3.7&ISO where
6578946 is the ID and 1.3.6.1.4.1.21367.2005.3.7 is the assigning authority.

1990

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

79

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

1995

2000

2005

<rim:ExternalIdentifier
identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427"
value="6578946^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO"
id="IdExample_051"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier"registryObject="DocumentEntry01"><rim:Name><rim:LocalizedString value="XDSDocumentEntry.patientId "/></rim:Name></rim:ExternalIdentifier>This ExternalIdentifier shall not contain other Slot, Name, Description, Classification, orExternal Identifier elements except as described above.
4.2.3.2.17

DocumentEntry.practiceSettingCode

Description:

2010

The code specifying the clinical specialty where the act that resulted in the document was
performed (e.g., Family Practice, Laboratory, Radiology). It is suggested that the creating entity
draws these values from a coding scheme providing a coarse level of granularity (about 10 to 100
entries).
Coding:2015

There shall be zero or one ebRIM Classification containing a practiceSettingCode. See Section
4.2.3.1.2 for a description of coding an ebRIM Classification. For the practiceSettingCode
metadata attribute, the classificationScheme shall be urn:uuid:cccf5598-8b07-4b77-a05eae952c785ead.
The following example specifies practiceSettingCode="ExamplepracticeSettingCode" withdisplay name "ExamplepracticeSettingCodeDisplayName" and coding scheme "Example
Practice Setting Code Scheme" for the DocumentEntry labeled "ExampleDocument".

2020

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

80

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

2025

2030

2035

<rim:Classification
ClassificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"classifiedObject="ExampleDocument"
id="IdExample_052"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="ExamplepracticeSettingCode"><rim:Name><rim:LocalizedStringvalue="ExamplepracticeSettingCodeDisplayName"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Example Practice Setting Code Scheme</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

4.2.3.2.18
2040

DocumentEntry.repositoryUniqueId

Description:
The globally unique, immutable, identifier of the repository where the document referenced by
the Document Entry can be accessed. This unique identifier for the repository may be used to
identify and connect to the specific repository to access the document.
Coding:2045

Max length is 64 characters. The format of the repositoryUniqueId value is OID.
The value is coded as a single value within an ebRIM Slot in the DocumentEntry.
The following example shows a repositoryUniqueId of 1.3.6.1.4.5.

2050

2055

<rim:Slot name="repositoryUniqueId"><rim:ValueList><rim:Value>1.3.6.1.4.5</rim:Value></rim:ValueList></rim:Slot>

4.2.3.2.19

DocumentEntry.serviceStartTime

Description:
Represents the start time of the service being documented took place (clinically significant, but
not necessarily when the document was produced or approved). This may be the same as the

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

81

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

2060

encounter time in case the service was delivered during an encounter. Encounter time is notcoded in metadata but may be coded within the document.
Note: If needed, other times associated with the document, such as time of approval, are to berecorded within the document.
Coding:2065

Max length is 256 characters. The format of the serviceStartTime value is DTM; see Table
4.2.3.1.7-2 for a description of DTM format.
The value is coded as a single value within an ebRIM Slot Attribute in the DocumentEntry.
The following example shows a creationTime of December 25, 2004 21:20:10 Coordinated
Universal Time (UTC).

2070<rim:Slot name="serviceStartTime"><rim:ValueList><rim:Value>20041225212010</rim:Value></rim:ValueList></rim:Slot>

2075
4.2.3.2.20

DocumentEntry.serviceStopTime

Description:

2080

Represents the stop time of the service being documented took place (clinically significant, but
not necessarily when the document was produced or approved). This may be the same as theencounter time in case the service was delivered during an encounter. Encounter time is notcoded in metadata but may be coded within the document.
If the service happens at a point in time, this attribute shall contain the same value as theserviceStartTime.
Coding:2085

Max length is 256 characters. The format of the serviceStartTime value is DTM; see Table
4.2.3.1.7-2 for a description of DTM format.
The value is coded as a single value within an ebRIM Slot Attribute in the DocumentEntry.
The following example shows a stop time of December 25, 2004 21:20:10 Coordinated
Universal Time (UTC).

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

82

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
2090<rim:Slot name="serviceStopTime"><rim:ValueList><rim:Value>20041225232010</rim:Value></rim:ValueList></rim:Slot>

2095
4.2.3.2.21

DocumentEntry.size

Description:
Size in bytes of the byte stream that comprises the document.
Coding:2100

Max length of the encoded size is 256 characters. Coded as an ebRIM Slot. Shall have only asingle value.
The following example shows a size value of 3654 bytes.

2105

2110

<rim:Slot name="size"><rim:ValueList><rim:Value>3654</rim:Value></rim:ValueList></rim:Slot>

4.2.3.2.22

DocumentEntry.sourcePatientId

Description:
The sourcePatientId represents the subject of care’s medical record Identifier (e.g., Patient Id) inthe local patient identifier domain of the creating entity.
Coding:2115

Max length is 256 characters. Coded as an ebRIM Slot with the value encoded according the
HL7 v2.5 CX datatype (See Table 4.2.3.1.7-2). Shall contain zero or one value.
It shall contain only two parts:
An Id (e.g., Patient Id CX.1).
The Authority Domain Id that assigned the Id (CX.4).

2120

All other CX components shall be omitted.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

83

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

2125<rim:Slot name="sourcePatientId"><rim:ValueList><rim:Value>j98789^^^&amp;1.2.3.4.343.1&amp;ISO</rim:Value></rim:ValueList></rim:Slot>

4.2.3.2.23

DocumentEntry.sourcePatientInfo

Description:
2130

This attribute contains demographics information at the time of submission of the patient towhose medical record this document belongs.
This information typically includes: the patient first and last name, sex, and birth date. Policies atthe creating entity may require more or less specific information and format.

2135

This patient information is not intended to be updated once the document is registered (just as the
document content and metadata itself will not be updated without replacing the previous
document). As sourcePatientInfo may have been updated by the source actor, it may no longer be
in use within the Document Source (EHR-CR). It is only intended as an audit/checking
mechanism and has occasional use for Document Consumer Actors.
Coding:

2140

2145

2150

Max length is 256 characters. Coded as an ebRIM Slot. Shall contain zero or one value list ofdemographic elements, where each element in the list is identified by fields from the HL7 PID
segment (See HL7 v2.5, chapter 3, Section 3.4.2).
<rim:Slot name="sourcePatientInfo"><rim:ValueList><rim:Value>PID-3|DTP-1^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO</rim:Value><rim:Value>PID-5|DICTAPHONE^ONE^^^</rim:Value><rim:Value>PID-7|19650120</rim:Value><rim:Value>PID-8|M</rim:Value><rim:Value>PID-11|100 Main St^^BURLINGTON^MA^01803^USA</rim:Value></rim:ValueList></rim:Slot>sourcePatientInfo should include values for:2155•

PID-3 (source patient identifier list. A list uses the repetition separator ~, for example:
DTP 1^^^&1.3.6&ISO~XTP1^^^&1.3.11&ISO.)•

PID-5 (source patient name)•

PID-7 (source patient date of birth)

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

84

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________•
2160

PID-8 (source patient gender)

M – MaleF – Female

O – Other U – Unknown
sourcePatientInfo should not include values for PID-2 (patient id), PID-4 (alternate patient id),
PID-12 (country code), or PID-19 (social security number).
4.2.3.2.24
2165

DocumentEntry.title

Description:
Represents the title of the document.
Clinical documents often do not have a title, in such case the classCode (e.g., a "consultation" or"progress note") is often used as the title. In that case, the title is usually omitted.
Coding:

2170

The format of DocumentEntry.title shall be any string of length less than 128 characters.
DocumentEntry.title is represented in ebXML as the "value" attribute of the LocalizedString
element within the ebRIM Name structure. There can be only one ebRIM Name structure perDocumentEntry.
The following example shows a title for the DocumentEntry.

2175

2180

<rim:ExtrinsicObject
id="ExampleDocument"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
mimeType="application/pdf"><rim:Name><rim:LocalizedString value="Example Document Title"/></rim:Name>...
</rim:ExtrinsicObject>2185
4.2.3.2.25

DocumentEntry.typeCode

Description:

2190

The code specifying the precise type of document from the user perspective. It is recommended
that the creating entity draw these values from a coding scheme providing a fine level of
granularity such as LOINC.
Coding:Coded as an ebRIM classification. See Section 4.2.3.1.2 for a description on creatingclassifications. Shall have zero or one value.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

85

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

2195

2200

2205

2210

2215

The following example specifies typeCode="ExampletypeCode" with display name"typeCodeDisplayName " and coding scheme " Example Type Code Scheme " for theDocumentEntry labeled "ExampleDocument".
<rim:Classification
classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
classifiedObject="ExampleDocument"
nodeRepresentation="ExampletypeCode"
id="IdExample_053"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"><rim:Name><rim:LocalizedString value="typeCodeDisplayName" /></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Example Type Code Scheme</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

4.2.3.2.26

DocumentEntry.uniqueId

Description:
Globally unique identifier assigned to the document by the creating entity.

2220

A DocumentEntry representing a single document is identified by the uniqueId attribute; thelinkage between DocumentEntry and the document it represents is made with the uniqueId
attribute.
This unique identifier may be used in other documents to reference this document.

2225

2230

Two documents MAY be assigned the same uniqueId if the documents have the same byte
sequence, but they SHALL NOT be assigned the same uniqueId if the documents have different
byte sequences when communicated via a Document Sharing protocol. The size and hashmetadata attributes allow for a quick comparison, so it is adequate to treat two documents as
having the same byte sequence if their size and hash attributes are the same.
For formats where different byte sequences can be functionally equivalent (XML, for example,
where whitespace between elements is ignored), it is important to note that documents withdifferent byte sequences SHALL have different uniqueIds even if they are functionallyequivalent when communicated via a Document Sharing protocol.
Coding:
The format of the DocumentEntry.uniqueId value is OID see Table 4.2.3.1.7-2.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

86

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

2235

Coded as an ebRIM ExternalIdentifier (see Section 4.2.3.1.3 for a description of coding an
ebRIM ExternalIdentifier) which references, and is contained in, the ExtrinsicObject
representing the DocumentEntry. There shall be only a single uniqueId value.

2240

The structure and format of this Id shall be consistent with the specification corresponding to theformatCode attribute. (e.g., for a DICOM standard document a 64 character numeric UID, for an
HL7 CDA format a serialization of the CDA Document Id extension and root in the formoid^extension, where OID is a 64 digits max, and the Id is a 16 UTF-8 char max. If the OID iscoded without the extension then the '^' character shall not be included.)

2245

2250

<rim:ExternalIdentifier
identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
value="1.2.3.4.5.6.78901.2345.6.7^123456"
id="IdExample_054"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier"registryObject="DocumentEntry01"><rim:Name><rim:LocalizedString value="XDSDocumentEntry.uniqueId"/></rim:Name></rim:ExternalIdentifier>4.2.3.2.27
2255

DocumentEntry.URI

Description:
The URI attribute contains the URI for the document.
Coding:Coded as an ebRIM Slot. Shall have only a single value. Max length is 256 characters.

2260<rim:Slot name="URI"><rim:ValueList><rim:Value>DOC001.XML</rim:Value></rim:ValueList></rim:Slot>

2265
4.2.3.2.28

DocumentEntry.referenceIdList

Description:
This list contains zero or more Identifiers. These Identifiers may be internal or external
identifiers, e.g., Identifiers may be Accession Numbers, Order Numbers, Referral Request

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

87

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
2270

Identifiers, XDS Workflow Instance Identifiers, etc. The referenceIdList contains Identifiers CXi
encoded, as specified in Table 4.2.3.1.7-2.
XDS Document Registry Actors supporting the ReferenceId Option shall preserve this value.
When the ReferenceId Option is not declared, the Document Registry shall handle this extra
metadata according to the historic rules outlined in Section 4.2.3.1.6 “Extra Metadata Elements”.

2275

Coding:Coded as an ebRIM Slot. May have multiple values. Max length for each value is 256 characters.
The name of the slot in the metadata shall be “urn:ihe:iti:xds:2013:referenceIdList”.
For example encoding two values in the referenceIdList:

2280

2285

<rim:Slot name="urn:ihe:iti:xds:2013:referenceIdList "><rim:ValueList><rim:Value>
2013001^^^&1.2.3.4.5.6&ISO^urn:ihe:iti:xds:2013:accession</rim:Value><rim:Value>
1.2.3.12.78.23^^^^urn:ihe:iti:xds:2013:uniqueId^&1.2.3.4&ISO</rim:Value></rim:ValueList></rim:Slot>

2290
4.2.3.2.29

DocumentEntry.limitedMetadata

Description:
Indicates whether the Document Entry was created using the less rigorous requirements ofmetadata as defined for the Metadata-Limited Document Source.
2295

Coding:
The Document Entry is flagged using an ebRIM Classification with a classificationNode of
urn:uuid:ab9b591b-83ab-4d03-8f5d-f93b1fb92e85.
The following example marks the “DocEntry” Document Entry as created via the less rigorous
metadata requirements.

2300

2305

<ExtrinsicObject id="DocEntry">(…)<Classification classifiedObject="DocEntry"
classificationNode="urn:uuid:ab9b591b-83ab-4d03-8f5d-f93b1fb92e85”/>(…)</ExtrinsicObject>

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

88

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
4.2.3.2.30

DocumentEntry.objectType

Description:
2310

2315

The objectType attribute reflects the type of DocumentEntry. As described in Section 4.1.1, there
are two DocumentEntry types: Stable Document Entry and On-Demand Document Entry. A
Stable Document Entry contains metadata about an already created document available for
retrieval is an Document Entry and is designated by setting objectType equal to the UUID for
Stable (see Section 4.2.5.2 for the UUID). An On-Demand DocumentEntry contains metadata
which can be used to create an on-demand document which collects the latest, most recent
available information at the time of retrieval. It is designed by setting an objectType equal to the
UUID for on-demand (see Section 4.2.5.2 for the UUID).
Coding:Max length is unbounded. The format of the objectType value is UUID.

2320

2325

The value of the objectType is coded in the objectType XML attribute on the ExtrinsicObject
representing the DocumentEntry. In the example below, the objectType is urn:uuid:7edca82f054d-47f2-a032-9b2a5b5186c1 and reflects a stable DocumentEntry.
<rim:ExtrinsicObject mimeType="application/pdf"
id="urn:uuid:a6e06ca8-0c75-4064-9e5c-88b9045a96f6"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"> …

4.2.3.3 SubmissionSet Attributes
2330

The following metadata elements shall be used to describe a SubmissionSet.
Each attribute shown is an attribute on the RegistryPackage object defining the SubmissionSet.
The attribute name is defined with a prefix of the object type of SubmissionSet when referenced
by other objects, for example SubmissionSet.sourceId.

2335

Please see Section 4.2.3.1.8 for the General format of DocumentEntry, Folder andSubmissionSet attribute tables.
Table 4.2.3.3-1: Submission Set Metadata Attribute Definitions (previously Table 4.1-6)
SubmissionSet
Metadata
Attribute
authorDescription

The humans and/or machines that authored the
document in the SubmissionSet. This attributecontains the sub-attributes: authorInstitution,authorPerson, authorRole, authorSpecialty.

Form

4.2.3.3.1

Coding

DetailebRIM
Classification

4.2.3.3.1

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

89

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
SubmissionSet
Metadata
Attribute

Description

Form

Coding

DetailavailabilityStatus

The lifecycle status of the SubmissionSet

PredefinedURN

XML
attribute

4.2.3.3.2

comments

Comments associated with the SubmissionSet.

StringebRIM
Description

4.2.3.3.3

contentTypeCode

The code specifying the type of clinical activity
that resulted in placing the documents in thisSubmissionSet.

Code

ebRIM
Classification

4.2.3.3.4

entryUUID

A globally unique identifier used to identify the
SubmissionSet.

UUID

XML
attribute

4.2.3.3.5

homeCommunityId

A globally unique identifier for a community.

OID URN

home XMLattribute

4.2.3.3.6

intendedRecipient

The organization(s) or person(s) for whom the
SubmissionSet is intended.

See 4.2.3.3.7

ebRIM Slot

4.2.3.3.7

limitedMetadata

A flag that the associated SubmissionSet was
created using the less rigorous metadata
requirements as defined for the Metadata-limited
Document Source.

See 4.2.3.3.13

ebRIM
Classification

4.2.3.3.13

patientId

The patientId represents the subject of carewhose longitudinal record is being reflected inthis SubmissionSet.

CX

ebRIM
ExternalIdent
ifier

4.2.3.3.8

sourceId

OID identifying the instance of the creating entitythat contributed the SubmissionSet.

OID

ebRIM
ExternalIdent
ifier

4.2.3.3.8

submissionTime

Point in time at the creating entity when the
SubmissionSet was created.

DTM

ebRIM Slot

4.2.3.3.10

title

The title of the SubmissionSet.

UTF-8

ebRIM Name

4.2.3.3.11

uniqueId

A globally unique identifier for theSubmissionSet assigned by the creating entity.

OID

ebRIM
ExternalIdent
ifier

4.2.3.3.12

4.2.3.3.1 SubmissionSet.author
2340

Description:
Represents the humans and/or machines that authored the submission set. See Section 4.2.3.1.4
for details on creating the structure.
The classificationScheme shall be urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d
4.2.3.3.2 SubmissionSet.availabilityStatus

2345

Description:

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

90

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Represents the status of the SubmissionSet. Since the deprecation of SubmissionSets is notallowed, this value shall always be Approved.
Coding:
The availabilityStatus value shall be "urn:oasis:names:tc:ebxml-regrep:StatusType:Approved".
2350<rim:RegistryPackage
id="urn:uuid:fbeacdb7-5421-4474-9267-985007cd8855"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
> ...

2355
4.2.3.3.3 SubmissionSet.comments
Description:
Contains comments associated with the SubmissionSet.
Coding:2360

Max length is unbounded. The value of the comments attribute is coded in XML as the "value"
attribute of the LocalizedString element within the ebRIM Description structure. There can be at
most one ebRIM Description structure per SubmissionSet.
The following example shows a comment for the SubmissionSet.

2365<rim:Description><rim:LocalizedString value = "comment associated with SubmissionSet"/></rim:Description>

4.2.3.3.4 SubmissionSet.contentTypeCode2370

Description:
The code specifying the type of clinical activity that resulted in placing these DocumentEntries,
Folders, and/or Associations in this SubmissionSet. These values are to be drawn from a
vocabulary defined by the creating entity that contributed the SubmissionSet.
Coding:2375

Coded as an ebRIM Classification. See Section 4.2.3.1.2 for a description of coding an ebRIM
Classification. Shall have zero or one value
The following example specifies contentTypeCode="ExamplecontentTypeCode" with display
name "Example contentTypeCodeDisplayName" and coding scheme "Example
contentTypeCode Scheme" for the SubmissionSet labeled "ExampleSubmissionSet".
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

91

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
2380

2385

2390

2395

<rim:Classification
classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
classifiedObject="ExampleSubmissionSet"
id="IdExample_056"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="ExamplecontentTypeCode"><rim:Name><rim:LocalizedString value="Example contentTypeCodeDisplayName" /></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Example Specific Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

4.2.3.3.5 SubmissionSet.entryUUID
2400

entryUUID is a globally unique identifier primarily intended for internal document management
purposes. In contrast, the uniqueId attribute is used for external references (e.g., links, etc.).
Coding:
The format of the entryUUID value is UUID. Certain Document Sharing transactions may allow
symbolic Ids (any string that does not have the urn:uuid: prefix) to be used.

2405

The value of the entryUUID is coded in the id XML attribute on the RegistryPackage
representing the Submission Set. In the example below, the entryUUID is urn:uuid:a6e06ca80c75-4064-9e5c-88b9045a96f6

2410<rim:RegistryPackage
id="urn:uuid:a6e06ca8-0c75-4064-9e5c-88b9045a96f6"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:RegistryPackage"
> …

2415
4.2.3.3.6 SubmissionSet.homeCommunityId
Description:
A globally unique identifier for a community.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

92

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Coding:
2420

The ebRIM RegistryPackage home attribute for the RegistryPackage that corresponds to the
SubmissionSet. It is an OID URN. See Table 4.2.3.1.7-2.
See ITI TF-2a: 3.18.4.1.2.3.8 and ITI TF-2b: 3.38.4.1.2.1.

2425<rim:RegistryPackage home="urn:oid:1.2.3" ...>...
</rim:RegistryPackage>

4.2.3.3.7 SubmissionSet.intendedRecipient
Description:
2430

Represents the organization(s) or person(s) for whom the SubmissionSet is intended at time ofsubmission. Each slot value shall include at least one of the organization, person, or
telecommunications address fields described below. It is highly recommended to define theorganization for all the persons, avoiding errors in the transmission of the documents.
Coding:

2435

2440

Max length is 256. The format of the SubmissionSet.intendedRecipient value is XON|XCN|XTN
where XON identifies the organization, XCN identifies a person and XTN identifies thetelecommunications, see Table 4.2.3.1.7-2 for description of XON, XCN and XTN format. Thereis a "|" character separator between the organization and the person, and between the person andthe telecommunications address, which is required when the person or the telecommunications
address information is present.
The value is coded as zero or more values within a single ebRIM Slot in the SubmissionSet.
The following example shows two doctors from the same organization, another doctor without
the organization details and another organization without the person details, and just atelecommunications address.

2445

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

93

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

2450

2455

2460

<rim:Slot name="intendedRecipient"><rim:ValueList><rim:Value>Some
Hospital^^^^^^^^^1.2.3.9.1789.45|^Wel^Marcus^^^Dr^MD|^^Internet^mwel@healthca
re.example.org</rim:Value><rim:Value>
Some Hospital^^^^^^^^^1.2.3.9.1789.45|^Peirre^LaPointe^^^Dr^MD</rim:Value><rim:Value>|12345^LaShawn^James^^Dr^MD</rim:Value><rim:Value>MainHospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.2364</rim:Value><rim:Value>||^^Internet^dr.oz@healthcare.example.org</rim:Value></rim:ValueList></rim:Slot>

4.2.3.3.8 SubmissionSet.patientId
Description:
The patientId represents the primary subject of care of the SubmissionSet.
2465

Coding:
The format of the patientId value is CX (see Table 4.2.3.1.7-2).
It shall contain two parts:
Assigning Authority Domain Id (organization that issued the Id).
An Id from the above Assigning Authority.

2470

2475

No other values are allowed, as specified for the CX type. Using HL7 terminology, no othervalues are allowed in the components of the coded value, nor are further subcomponents
allowed.
The value is coded within a single ebRIM ExternalIdentifier element (see Section 4.2.3.1.3 for a
description of coding an ebRIM ExternalIdentifier) which references, and is contained in, theRegistryPackage representing the SubmissionSet. There shall be zero or one single patientId
value.
In the example below the patientId is 6578946^^^&1.3.6.1.4.1.21367.2005.3.7&ISO where
6578946 is the ID and 1.3.6.1.4.1.21367.2005.3.7 is the assigning authority.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

94

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
2480

2485

2490

<rim:ExternalIdentifier
identificationScheme="urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446"
value="6578946^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO"
id="IdExample_057"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier"registryObject="SubmissionSet01">><rim:Name><rim:LocalizedString value = "XDSSubmissionSet.patientId"/></rim:Name></rim:ExternalIdentifier>This ExternalIdentifier shall not contain other Slot, Name, Description, Classification, orExternal Identifier elements except as described above.
2495

4.2.3.3.9 SubmissionSet.sourceId
Description:
The globally unique, immutable, identifier of the entity that contributed the SubmissionSet.
When a "broker" is involved in sending SubmissionSets from a collection of client systems, it
shall use a different sourceId for submissions from each separate system to allow for tracking.

2500

Coding:
The format of the sourceId value is OID (see Table 4.2.3.1.7-2).
The value is coded within a single ebRIM ExternalIdentifier element (see Section 4.2.3.1.3 for a
description of coding an ebRIM ExternalIdentifier) which references, and is contained in, theRegistryPackage representing the SubmissionSet. There shall be only a single sourceId value.

2505

2510

2515

In the example below the sourceId is “1.3.6.1.4.1.21367.2005.3.7”.
<rim:ExternalIdentifier
identificationScheme="urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832"
value="1.3.6.1.4.1.21367.2005.3.7"
id="IdExample_058"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier"registryObject="SubmissionSet01"><rim:Name><rim:LocalizedString value = "XDSSubmissionSet.sourceId"/></rim:Name></rim:ExternalIdentifier>

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

95

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
4.2.3.3.10
2520

SubmissionSet.submissionTime

Description:
Represents the point in time at the creating entity when the Submission Set was submitted.
This shall be provided by the submitting system.
Coding:2525

Max length is 256. The format of the submissionTime value is DTM. See Table 4.2.3.1.7-2 for a
description of DTM format.
The value is coded as a single value within an ebRIM Slot Attribute in the SubmissionSet.
The following example shows a submissionTime of December 25, 2004 21:20:10 Coordinated
Universal Time (UTC).

2530<rim:Slot name="submissionTime"><rim:ValueList><rim:Value>20041225212010</rim:Value></rim:ValueList></rim:Slot>2535
4.2.3.3.11

SubmissionSet.title

Description:
Shall contain the title of the Submission Set.
Coding:
2540

The format of SubmissionSet.title shall be any string of length less than 256 characters.
SubmissionSet.title is represented in ebXML as the "value" attribute of the LocalizedString
element within the ebRIM Name structure. There can be only one ebRIM Name structure per
SubmissionSet.
The following example shows a title for the SubmissionSet.

2545<rim:Name><LocalizedString value="Example Submission Set Title"/></rim:Name>

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

96

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
2550

4.2.3.3.12

SubmissionSet.uniqueId

Description:
The globally unique identifier for the SubmissionSet assigned by the entity that contributed theSubmissionSet.
Coding:
2555

The format of the SubmissionSet.uniqueId value is OID (see Table 4.2.3.1.7-2).
The value is coded within a single ebRIM ExternalIdentifier element which references, and iscontained in, the RegistryPackage representing the SubmissionSet. See Section 4.2.3.1.3 for a
description of coding an ebRIM ExternalIdentifier. There shall be only a single uniqueId value.
The following example shows a uniqueId of 1.2.3.4.5.

2560

2565

2570

<rim:ExternalIdentifier
identificationScheme="urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8"
id="IdExample_059"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier"value="1.2.3.4.5"
registryObject="SubmissionSet01"><rim:Name><rim:LocalizedString value = "XDSSubmissionSet.uniqueId"/></rim:Name></rim:ExternalIdentifier>4.2.3.3.13

SubmissionSet.limitedMetadata

Description:
2575

Indicates whether the SubmissionSet was created using the less rigorous requirements ofmetadata as defined for the Metadata-Limited Document Source Actor.
Coding:The SubmissionSet is flagged using an ebRIM Classification with a classificationNode of
urn:uuid:5003a9db-8d8d-49e6-bf0c-990e34ac7707. Zero or one may be present.

2580

The following example marks the “SubmissionSet” SubmissionSet as created via the lessrigorous metadata requirements.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

97

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

2585

2590

<RegistryPackage id="SubmissionSet">(…)<Classification classifiedObject="SubmissionSet"
classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"/><Classification classifiedObject="SubmissionSet"
classificationNode="urn:uuid:5003a9db-8d8d-49e6-bf0c-990e34ac7707"/>(…)</RegistryPackage>

4.2.3.4 Folder Attributes

2595

The following metadata elements shall be used to describe a Folder. Each attribute shown below
is an attribute on the RegistryPackage object defining the Folder. The attribute name is definedwith a prefix of the object type of Folder when referenced by other objects, for example
Folder.patientId. See Section 4.2.3.1.8 for the general format of DocumentEntry, Folder andSubmissionSet attribute tables.
Table 4.2.3.4-1: Folder Metadata Attribute Definitions (previously Table 4.1-7)
Folder Metadata
Attribute

Description

Form

Coding

Detail(See
Section)availabilityStatus

The lifecycle status of the Folder

Predefined
URN

XML attribute

4.2.3.4.1

codeList

Shall contain the set of codes specifying the type ofclinical activities that resulted in placing
DocumentEntries in this Folder.

Code

ebRIM
Classification

4.2.3.4.2

comments

Comments associated with the Folder.

StringebRIM
Description

4.2.3.4.3

entryUUIDThis globally unique identifier used to identify the
Folder.

UUID

XML attribute

4.2.3.4.4

homeCommunityId

A globally unique identifier for a community.

OID URN

XML attribute

4.2.3.4.5

lastUpdateTime

Most recent point in time that the Folder has been
modified.

DTM

ebRIM Slot

4.2.3.4.6

limitedMetadata

A flag that the associated Folder was created using
the less rigorous metadata requirements as definedfor the Metadata-Limited

4.2.3.4.10

ebRIM
Classification

4.2.3.4.1
0patientId

The patientId represents the subject of care of theDocumentEntries within the Folder.

CX

ebRIM
ExternalIdentifi
er

4.2.3.1.3

title

The title of the Folder.

StringebRIM Name

4.2.3.4.8

uniqueId

Globally unique identifier for the Folder.

OID

ebRIM
ExternalIdentifi
er

4.2.3.4.9

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

98

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
2600

4.2.3.4.1 Folder.availabilityStatus
Description:
Represents the status of the Folder. Since the deprecation of Folders is not allowed, this value
shall always be Approved.
Coding:2605

Max length is unbounded. The availabilityStatus value shall be "urn:oasis:names:tc:ebxmlregrep:StatusType:Approved".
The example below shows the status attribute; however, this attribute is only returned on query,
not set during any transaction.

2610<rim:RegistryPackage
id="urn:uuid:fbeacdb7-5421-4474-9267-985007cd8855"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
> ...

2615

4.2.3.4.2 Folder.codeList
Description:
Shall contain the set of codes specifying the type of clinical activity that resulted in placing
Documents in this Folder. These values shall be drawn from a vocabulary or coding scheme
defined by the creating entity.

2620

Coding:Coded as an ebRIM classification. See Section 4.2.3.1.2 for a description of coding an ebRIM
Classification. Shall have zero or more values. Code multiple values by creating multiple
classification objects.

2625

The following example specifies contentTypeCode="ExamplecontentTypeCode" with display
name "ExamplecodeList CodeDisplayName" and coding scheme "Example coding scheme" forthe Folder labeled "ExampleFolder".

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

99

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

2630

2635

2640

2645

<rim:Classification
classificationScheme= "urn:uuid:1ba97051-7806-41a8-a48b-8fce7af683c5"
classifiedObject="ExampleFolder"
id="IdExample_062"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="Examplecode"><rim:Name><rim:LocalizedStringvalue="ExamplecodeList CodeDisplayName" /></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Example coding scheme</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

4.2.3.4.3 Folder.comments
Description:
Comments associated with the Folder. Free form text or IHE profile-specified usage.
2650

Note: Prior to the availability of the Folder.title attribute, the comments attribute might have been used to hold the title ofthe folder (folder name). With the addition of the title attribute, the comments attribute shall not hold the folder
name.

Coding:
The format of Folder.comments is any string. Max length is unbounded.
2655

The value of the comments attribute is coded in XML as the "value" attribute of the
LocalizedString element within the ebRIM Description structure. There can be at most one
ebRIM Description structure per DocumentEntry.
The following example shows a comment for the Folder.

2660<rim:Description><rim:LocalizedString value = "comments"/></rim:Description>

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

100

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
4.2.3.4.4 Folder.entryUUID
2665

Description:
This globally unique identifier is primarily intended for use as a document registry management
identifier. It is not meant to be an external reference (e.g., outside of the Document Registry) for
documents (e.g., in links within other documents).
Coding:2670

Max length is unbounded. The format of the entryUUID value is UUID. Certain Document
Sharing transactions may allow symbolic Ids (anything that does not have the urn:uuid: prefix) tobe used.
The value of the entryUUID is coded in the id XML attribute on the ExtrinsicObject representing
the DocumentEntry. In the example below, the entryUUID is2675

urn:uuid:a6e06ca8-0c75-4064-9e5c-88b9045a9ab6<rim:RegistryPackage
id="urn:uuid:a6e06ca8-0c75-4064-9e5c-88b9045a9ab6"
> ...

2680
4.2.3.4.5 Folder.homeCommunityId
Description:
A globally unique identifier for a community.
Coding:2685

Max length is unbounded. The ebRS RegistryPackage home attribute for the RegistryPackagethat corresponds to the Folder. It is an OID URN (see Table 4.2.3.1.7-2).
See ITI TF-2a: 3.18.4.1.2.3.8 and ITI TF-2b: 3.38.4.1.2.1.

2690<rim:RegistryPackage home="urn:oid:1.2.3" ...>...
</rim:RegistryPackage>

4.2.3.4.6 Folder.lastUpdateTime
Description:
2695

Most recent point in time when a DocumentEntry was placed in the Folder.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

101

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Coding:Max length is 256 characters. The format of the lastUpdateTime value is DTM. See Table
4.2.3.1.7-2 for a description of DTM format.
The value is coded as a single value within an ebRIM Slot Attribute in the DocumentEntry.
2700

2705

The following example shows a last update of December 25, 2004 21:20:10 Coordinated
Universal Time (UTC).
<rim:Slot name="lastUpdateTime"><rim:ValueList><rim:Value>20041225212010</rim:Value></rim:ValueList></rim:Slot>

4.2.3.4.7 Folder.patientId
2710

Description:
The patientId represents the primary subject of care of the Folder.
The value of the patientId shall be the same for all new documents of a SubmissionSet. All
DocumentEntries placed in a Folder shall have the same patiendId as the Folder.
Coding:2715

Max length unbounded. The format of the patientId value is CX (See Table 4.2.3.1.7-2).
It shall contain two parts:
Assigning Authority Domain Id (organization that issued the Id).
An Id from the Assigning Authority.

2720

No other values are allowed, as specified for the CX type in Table 4.2.3.1.7-2 above. Using HL7
terminology, no other values are allowed in the components of the coded value, nor are further
subcomponents allowed.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

102

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

2725

2730

2735

<rim:ExternalIdentifier
identificationScheme="urn:uuid:f64ffdf0-4b97-4e06-b79f-a52b38ec2f8a"
value="6578946^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO"
id="IdExample_057"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier"><rim:Name><rim:LocalizedString value = "XDSFolder.patientId"/></rim:Name></rim:ExternalIdentifier>This ExternalIdentifier shall not contain other Slot, Name, Description, Classification, orExternal Identifier elements except as described above.
4.2.3.4.8 Folder.title
Description:
Shall contain the Folder name.

2740

Note: Prior to the availability of this attribute the comments attribute might have been used to hold the title of the folder(folder name). With the addition of this attribute the comments attribute shall not hold the folder name.

Coding:Encoded in the name element within the ebRS ExtrinsicObject for the document (see ebRS
Schema RIM.XSD). Shall have only a single value.
2745

Max length is 256 characters.
In this example the title is “title”.

2750<Name><LocalizedString value="this is the title of the Folder"/></Name>4.2.3.4.9 Folder.uniqueId
Description:
Globally unique identifier for the folder instance assigned by the creating entity.
2755

Coding:Max length is 256 characters. Encoded as the ExternalIdentifier. See Section 4.2.3.1.3 for a
description of coding an ebRIM ExternalIdentifier. Shall have only a single value. Shall be of
OID format.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

103

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

2760

2765

2770

<rim:ExternalIdentifier
identificationScheme="urn:uuid:75df8f67-9973-4fbe-a900-df66cefecc5a"
id="IdExample_059"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier"value="1.3.6.1.4.1.21367.2005.3.7.3670984664"
registryObject="Folder01"><rim:Name><rim:LocalizedString value = "XDSFolder.uniqueId"/></rim:Name></rim:ExternalIdentifier>This ExternalIdentifier shall not contain other Slot, Name, Description, Classification, orExternal Identifier elements except as described above.

2775

4.2.3.4.10

Folder.limitedMetadata

Description:
Indicates whether the Folder was created using the less rigorous requirements of metadata as
defined for the Metadata-Limited Document Source Actor.
Coding:2780

The Folder is flagged using an ebRIM Classification with a classificationNode of
urn:uuid:2c144a76-29a9-4b7c-af54-b25409fe7d03. Zero or one may be present.
The following example marks the “Folder” Folder as created via the less rigorous metadata
requirements.

2785

2790

2795

<RegistryPackage id="Folder">(…)<Classification classifiedObject=”Folder”
classificationNode=”urn:uuid:d9d542f3-6cc4-48b6-8870-ea235fbc94c2”
id=”ID_061" objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"/><Classification classifiedObject="Folder"classificationNode="urn:uuid:2c144a76-29a9-4b7c-af54-b25409fe7d03"/>(…)</RegistryPackage>

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

104

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
4.2.4 Error Reporting
2800

Registry Services schema (ebRS 3.0) defines the RegistryError element for reporting details oferrors or warnings.
4.2.4.1 RegistryErrors Element
The RegistryError element contains the attributes in Table 4.2.4.1-1.
All IHE transactions that carry the RegistryError element shall return these attributes with eacherror reported.

2805

The body of all RegistryError elements shall be empty.
Table 4.2.4.1-1: RegistryError Element Attributes
Attribute

Optionality

ValueerrorCodeR

Shall be taken from Table 4.2.4.1-2 when one of those codes isappropriate. All extensions to the list of error codes shall be
unique.

codeContext

R

Supplies additional detail for the errorCodeseverityR

Indicates the severity of the error. Shall be one of:oasis:names:tc:ebxmlregrep:ErrorSeverityType:Error
urn:oasis:names:tc:ebxmlregrep:ErrorSeverityType:Warning

locationO

Supplies the location of the error: module name and line number
or stack trace if appropriate.

An example of an error response reporting two errors using ebRS and ebRIM 3.0 is:

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

105

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
2810

2815

2820

2825

<RegistryResponse
xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure"><RegistryErrorList
highestSeverity="urn:oasis:names:tc:ebxmlregrep:ErrorSeverityType:Error"><RegistryError
errorCode="XDSPatientIdDoesNotMatch"
codeContext="Patient Id in Document (Document1) does not match
SubmissionSet"
location=""severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/><RegistryError
errorCode="XDSRegistryMetadataError"
codeContext="RegistryPackage (SubmissionSet) is not labeled as
SubmissionSet or Folder"
location=""severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/></RegistryErrorList></RegistryResponse>

2830
Table 4.2.4.2-1 through Table 4.2.4.2-4 control the reporting of errors for transactions that use
the Document Sharing metadata attributes.
Table 4.2.4.1-2: Error Codes (previously Table 4.1-11)
Error Code1

Discussion

Transaction(See Note 1)

DocumentQueued

An XDR Recipient queued the document
for future manual matching to a patientP

InvalidDocumentContent

The recipient has rejected this submission
because it detected that one of the
documents does not match the metadata(e.g., formatCode) or has failed otherrequirements for the document content.

P

When the RegistryError element contains
this error code , the @location shall containthe DocumentUniqueID of the document inerror.
If multiple documents are in error, there
shall be a separate RegistryError element
for each document in error.
PartialAppendContentNotProcessed

1

An XDR Document Recipient did notprocess some part of the content.

P

The XDS Metadata Update Supplement adds error codes to this table.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

106

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Error Code1

Discussion

Transaction(See Note 1)

Specifically the parts not processed are
Append semantics
PartialFolderContentNotProcessed

An XDR Document Recipient did notprocess some part of the content.
Specifically the parts not processed are
Folder semantics

P

PartialReplaceContentNotProcessed

An XDR Document Recipient did notprocess some part of the content.
Specifically the parts not processed are
Replacement semantics

P

PartialTransformNotProcessed

An XDR Document Recipient did notprocess some part of the content.
Specifically the parts not processed areTransform semantics

P

PartialTransformReplaceNotProcessed

An XDR Document Recipient did notprocess some part of the content.
Specifically the parts not processed areTransform and Replace semantics

P

XDSDocumentUniqueIdError

The document associated with the uniqueId
is not available. This could be because thedocument is not available, the requestor is
not authorized to access that document or
the document is no longer available.

RS, XGRXDSDuplicateUniqueIdInRegistry

UniqueId received was not unique.
UniqueId could have been attached to
SubmissionSet or Folder. codeContext shallindicate which and the value of the nonunique uniqueId. This error cannot be
thrown for DocumentEntry. See
XDSNonIdenticalHash and
XDSNonIdenticalSize.

P,R
P

XDSExtraMetadataNotSaved

This warning is returned if extra metadata
was present but not saved.

P,R

XDSMissingDocument

DocumentEntry exists in metadata with nocorresponding attached documentP

XDSMissingDocumentMetadata

MIME package contains MIME part with
Content-Id header not found in metadataP

XDSMissingHomeCommunityId

A value for the homeCommunityId isrequired and has not been specified

SQ, XGQ, RS,
XGR

XDSNonIdenticalHash

Document being registered was a duplicate(uniqueId already in Document Registry)
but hash does not match. codeContext
indicates UniqueId.

R

XDSNonIdenticalSize

Document being registered was a duplicate(uniqueId already in Document Registry)
but size does not match. CodeContext
indicates UniqueId.

R

XDSPatientIdDoesNotMatch

This error is thrown when the patient Id isP,R

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

107

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Error Code1

Discussion

Transaction(See Note 1)

required to match and does not. The
codeContext shall indicate the value of thePatient Id and the nature of the conflict.
XDSRegistryBusy
XDSRepositoryBusy

Too much activity

P,R,SQ, XGQ
P, RS, XGR

XDSRegistryDeprecatedDocumentError

The transaction was rejected because it
submitted an Association referencing a
deprecated document.

P,R

XDSRegistryDuplicateUniqueIdInMessage
XDSRepositoryDuplicateUniqueIdInMessage

A UniqueId value was found to be used
more than once within the submission.
Error code indicates where error was
detected. codeContext shall indicate theduplicate UniqueId.

P,R

XDSRegistryError
XDSRepositoryError

Internal Error
The error codes XDSRegistryError or
XDSRepositoryError shall be returned if
and only if a more detailed code is notavailable from this table for the condition
being reported.
If one of these error codes is returned, theattribute codeContext shall contain detailsof the error condition that may be
implementation-specific.

P,R, SQ, XGQ
P, RS. XGRXDSRegistryMetadataError
XDSRepositoryMetadataError

Error detected in metadata. Actor nameindicates where error was detected.
(Document Recipient uses Repository
error). codeContext indicates nature of
problem.

P,R

XDSRegistryNotAvailable

Repository was unable to access theRegistryP

XDSRegistryOutOfResources
XDSRepositoryOutOfResources

Resources are low.

P,R,SQ, XGQ
P, RS, XGR

XDSResultNotSinglePatientThis error signals that the single Stored
Query would have returned metadata for
multiple Patient Ids

SQ, RSXDSStoredQueryMissingParamA required parameter to a stored query is
missing.

SQ, XGQXDSStoredQueryParamNumber

A parameter which only accepts a single
value is coded with multiple values

SQ, XGQ

XDSTooManyResults

Query resulted in too many results. No
results are returned.

Q,SQ, XGQXDSUnavailableCommunity

A community which would have been
contacted was not available. See Note 2.

SQ, RSXDSUnknownCommunity

A value for the homeCommunityId is notrecognized

SQ, XGQ, RS,
XGR

XDSUnknownPatientId

Patient Id referenced in metadata is notknown by the receiving actor. The

P,R, XGQ
Note: this error

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

108

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Error Code

2835

1

Discussion

Transaction(See Note 1)

codeContext shall include the value ofpatient Id in question.

code is not usedin the response toRegistry Stored
Query

XDSUnknownRepositoryId

The repositoryUniqueId value could not be
resolved to a valid document repository or
the value does not match therepositoryUniqueId.

RS, XGRXDSUnknownStoredQueryThe Query Id provided in the request is notrecognized.

SQ, XGQ

Note 1:
P = Provide and Register-b
R = Register-b
SQ = Stored Query
RS = Retrieve Document Set

2840

XGQ = Cross Gateway QueryXGR = Cross Gateway Retrieve
Note 2:
Two examples of the use of error code XDSUnavailableCommunity are:2845

A Cross Gateway Query or Cross Gateway Retrieve fails because the community identified by a homeCommunityId could
not be contacted.
A Cross Gateway Query based on Patient ID could not contact some known communities to relay the query.
The error would be generated by the Initiating Gateway and returned in the Registry Stored Query or Retrieve Document
Set. This would only apply when XDS Affinity Domain Option was used.

4.2.4.2 Error responses
2850

The RegistryError elements shall be contained within an ebXML RegistryErrorList element in
the ebXML RegistryResponse or ebXML AdhocQueryResponse.
The status attribute of the RegistryResponse or AdhocQueryResponse shall be one of thefollowing values:
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success2855

urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure
urn:ihe:iti:2007:ResponseStatusType:PartialSuccess

The highestSeverity attribute may be present in a RegistryErrorList. If present, it shall containthe severity of the most severe of the RegistryErrors in the RegistryErrorList.
2860

The following tables explain the meaning of the status attribute in RegistryResponse andAdhocQueryResponse. Tables 4.2.4.2-1, 4.2.4.2-2, 4.2.4.2-3 and 4.2.4.2-4 below indicate

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

109

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
whether the RegistryErrorList element shall be present and what other content shall be part of the
response.
Table 4.2.4.2-1: [ITI-41] Provide and Register Document Set-b Responses
RegistryResponse status

RegistryErrorList element

Resulturn:oasis:names:tc:ebxmlregrep:ResponseStatusType:SuccessMay be present. If present will containone or more RegistryError elementswith warning severity, none with error
severity.

All metadata defined in this volume, anddocuments were successfully registered.
Extra metadata may or may not be saved,
based on the presence of the
XDSExtraMetadataNotSaved warning.

urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Failure

Present, contains one or more
RegistryError elements. At least one
has error severity others may havewarning severity.

Metadata and documents not stored

2865
Table 4.2.4.2-2: [ITI-42] Register Document Set-b Responses
RegistryResponse status

RegistryErrorList element

Resulturn:oasis:names:tc:ebxmlregrep:ResponseStatusType:SuccessMay be present. If present will containone or more RegistryError elementswith warning severity, none with error
severity

All metadata defined in this volume was
successfully registered Extra metadata
may or may not be saved, based on thepresence of the
XDSExtraMetadataNotSaved warning.

urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Failure

Present, contains one or more
RegistryError elements. At least one
has error severity, others may havewarning severity.

Metadata not stored

Table 4.2.4.2-3: [ITI-18] Stored Query and [ITI-38] Cross Gateway Query Responses
AdhocQueryResponse status

RegistryErrorList element

Resulturn:oasis:names:tc:ebxmlregrep:ResponseStatusType:SuccessMay be present. If present will containone or more RegistryError elementswith warning severity; none with error
severity

Results shall be returned.
Results may contain zeroor more entries.

urn:ihe:iti:2007:ResponseStatusType:PartialSuccess

Present, contains one or more
RegistryError elements. At least one
has error severity; others may havewarning severity.

Results shall be returned.
Results may contain zeroor more entries.

urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Failure

Present, contains one or more
RegistryError elements. At least one
has error severity; others may havewarning severity.

Results not returned

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

110

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

2870

Table 4.2.4.2-4: [ITI-43] Retrieve Document Set and [ITI-39] Cross Gateway Retrieve
Responses
Registry Response status

RegistryErrorList element

Resulturn:oasis:names:tc:ebxmlregrep:ResponseStatusType:SuccessMay be present. If present will containone or more RegistryError elementswith warning severity; none with error
severity

All documents weresuccessfully retrieved

urn:ihe:iti:2007:ResponseStatusType:PartialSuccess

Present, contains one or more
RegistryError elements. At least one
has error severity; others may havewarning severity.

Some documents weresuccessfully retrieved

urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Failure

Present, contains one or more
RegistryError elements. At least one
has error severity; others may havewarning severity.

No documents weresuccessfully retrieved

Note: Complete details on how these elements shall be populated are available at ITI TF-2b: 3.43.5 Protocol Requirements.

4.2.5 Metadata Vocabulary
The UUIDs in the following tables shall be used in constructing and interpreting XDS metadata.
2875

4.2.5.1 Submission Set Object UUIDs
UUID

Use/meaning

urn:uuid:a54d6aa5-d40d-43f9-88c5b4633d873bdd

SubmissionSet ClassificationNode

urn:uuid:a7058bb9-b4e4-4307-ba5be3f0ab85e12d

author External Classification Scheme

urn:uuid:aa543740-bdda-424e-8c96df4873be8500

contentTypeCode External Classification Scheme

urn:uuid:6b5aea1a-874d-4603-a4bc96a0a7b38446

patientId External Identifier

urn:uuid:554ac39e-e3fe-47fe-b233965d2a147832

sourceId External Identifier

urn:uuid:96fdda7c-d067-4183-912ebf5ee74998a8

uniqueId External Identifier

4.2.5.2 Document Entry Object
UUID

Use/meaning

urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1

DocumentEntry objectType for Stable Document
Entries

urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248

ntry objectType for On-Demand Document Entries

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

111

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________UUID

Use/meaning

urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d

author External Classification Scheme

urn:uuid:41a5887f-8865-4c09-adf7-e362475b143aclassCode External Classification Scheme

urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f

confidentialityCode External Classification
Schemeurn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4

eventCodeList External Classification Scheme

urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d

formatCode External Classification Scheme

urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1

healthCareFacilityTypeCode External
Classification Scheme

urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427

patientId ExternalIdentifier

urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead

practiceSettingCode External Classification
Schemeurn:uuid:f0306f51-975f-434e-a61c-c59651d33983

typeCode External Classification Scheme

urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab

uniqueId ExternalIdentifier

4.2.5.3 Folder Object
UUID

Use/meaning

urn:uuid:d9d542f3-6cc4-48b6-8870-ea235fbc94c2

Folder ClassificationNode

urn:uuid:1ba97051-7806-41a8-a48b-8fce7af683c5

codeList External Classification Scheme

urn:uuid:f64ffdf0-4b97-4e06-b79f-a52b38ec2f8apatientId External Identifier

urn:uuid:75df8f67-9973-4fbe-a900-df66cefecc5a

uniqueId External Identifier

2880

4.3 Additional Document Sharing Requirements
This section includes profile specific requirements.
4.3.1 Requirements on Submission Type Transactions
2885

2890

A Submission Type Transaction transfers a collection of Document Sharing metadata to areceiving actor for processing. There are three Submission Type transactions:•[ITI-42] Register Document Set-b – transfers only Document Sharing metadata•[ITI-41] Provide and Register Document Set-b – transfers Document Sharing metadataalong with document content•[ITI-32] Distribute Document Set on Media - transfers Document Sharing metadata alongwith document content

The Document Sharing metadata Objects found in the Submission Request of a Submission TypeTransaction are:

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

112

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

2895

•

SubmissionSet metadata•

Metadata for new or existing documents•

Folders to be created•

Associations (various relationships and HasMember as needed)

An XDS Registry Submission Request is the collection of metadata transferred between a
Document Repository and a Document Registry. This request is part of the Register Document
Set-b [ITI-42] and Register On-Demand Document Entry [ITI-61] transactions.
2900

An XDS Repository Submission Request is the collection of metadata and documents transferred
between a Document Source and a Document Repository. This request is the information
payload of the Provide and Register Document Set message of the Provide and Register
Document Set-b [ITI-41] transaction.
4.3.1.1 Submission Metadata Attribute Optionality

2905

This section lists which metadata attributes an actor shall provide when initiating a Submission
Type Transaction.
The Actor/Transaction pairs addressed by this section are as follows:
Table 4.3.1.1-1: Sending Actor/Transaction Pairs
Actor

Transaction

ShortnameXDS Document Source

ITI-41 Provide and Register Document Set-b

XDS DSXDS Document Repository

ITI-42 Register Document Set-b

XDS DRXDM Portable Media Creator

ITI-32 Distribute Document Set on MediaXDM MCXDR Document Source

ITI-41 Provide and Register Document Set-b

XDR DSXDR Metadata-Limited Document Source

ITI-41 Provide and Register Document Set-b

XDR MSXDS On-Demand Document Source

ITI-61 Register On-Demand Document Entry

XDS OD2910
For each actor/transaction pair across the top of Table 4.3.1.1-3, and each metadata attribute row,
the cell indicates the requirement for that actor when creating a submission request using thepaired transaction. The requirements are expressed through these codes:
2915

Table 4.3.1.1-2: Sending Actor Metadata Attribute Optionality Code Definitions
Code

MeaningR

Required – A value for the attribute shall be supplied by the sending Actor when sending thesubmission

R2

Required if Known – A value for the attribute shall be supplied by the sending Actor whensending the submission unless the Actor does not have any value for the attribute

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

113

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Code

Meaning

O

Optional – The sending Actor may or may not supply a value for this attribute

X

Prohibited – when sending a submission, a value for the attribute shall not be supplied by
the sending Actor.

Table 4.3.1.1-3: Sending Actor Metadata Attribute Optionality
Metadata
Element

Metadata Attribute

XDS
DS

XDS
DR

XDM
MC

XDR
DS

XDR
MS

DocumentEntry

author

R2

R2

R2

R2

R2

R2

DocumentEntry

availabilityStatus

O

O

O

O

O

O

DocumentEntry

classCode

R

R

R2

R

R2

R

DocumentEntry

comments

O

O

O

O

O

O

DocumentEntry

confidentialityCode

R

R

R2

R

R2

R

DocumentEntry

creationTime

R

R

R2

R

R2

X

DocumentEntry

entryUUID

R

R

R

R

R

R

DocumentEntry

eventCodeList

O

O

O

O

O

O

DocumentEntry

formatCode

R

R

R2

R

R2

R

DocumentEntry

hash

O

R

R

O

O

X

DocumentEntry

healthcareFacility
TypeCode

R

R

R2

R

DocumentEntry

homeCommunityId

O

O

O

O

O

O

DocumentEntry

languageCode

R

R

R2

R

R2

R

DocumentEntry

legalAuthenticator

O

O

O

O

O

O

DocumentEntry

limitedMetadata

X

X

O

X

R

X

DocumentEntry

mimeType

R

R

R

R

R

R

DocumentEntry

objectType

R

R

R

R

R

R

DocumentEntry

patientId

R

R

R2

R

R2

R

DocumentEntry

practiceSettingCode

R

R

R2

R

R2

R

DocumentEntryreferenceIdList

O

O

O

O

O

O

DocumentEntry

repositoryUniqueId

O

R

O

O

O

O

DocumentEntry

serviceStartTime

R2

R2

R2

R2

R2

O

DocumentEntry

serviceStopTime

R2

R2

R2

R2

R2

O

DocumentEntry

size

O

R

R

O

O

X

DocumentEntry

sourcePatientId

R

R

R2

R

R2

R

DocumentEntry

sourcePatientInfo

O

O

R2

O

R2

O

DocumentEntry

title

O

O

O

O

O

O

DocumentEntry

typeCode

R

R

R2

R

R2

R

DocumentEntry

uniqueId

R

R

R

R

R

R

DocumentEntry

URI

O

O

R

O

O

O

R2

XDS
OD

R

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

114

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Metadata
Element

Metadata Attribute

XDS
DS

XDS
DR

XDM
MC

XDR
DS

XDR
MS

XDS
OD

SubmissionSet

author

R2

R2

R2

R2

R2

R2

SubmissionSet

availabilityStatus

O

O

O

O

O

O

SubmissionSet

comments

O

O

O

O

O

O

SubmissionSet

contentTypeCode

R

R

R2

R

R2

R

SubmissionSet

entryUUID

R

R

R

R

R

R

SubmissionSet

homeCommunityId

O

O

O

O

O

O

SubmissionSet

intendedRecipient

O

O

R2

R2

R2

O

SubmissionSet

limitedMetadata

X

X

O

X

R

X

SubmissionSet

patientId

R

R

R2

R

R2

R

SubmissionSet

sourceId

R

R

R

R

R

R

SubmissionSet

submissionTime

R

R

R

R

R

R

SubmissionSet

title

O

O

O

O

O

O

SubmissionSet

uniqueId

R

R

R

R

R

R

FolderavailabilityStatus

O

O

O

O

O

O

FoldercodeList

R

R

R2

R

R2

R

Foldercomments

O

O

O

O

O

O

FolderentryUUID

R

R

R

R

R

R

FolderhomeCommunityId

O

O

O

O

O

O

FolderlastUpdateTime

O

O

O

O

O

O

FolderlimitedMetadata

X

X

O

X

R

X

FolderpatientId

R

R

R2

R

R2

R

Folder

title

R

R

O

R

O

R

FolderuniqueId

R

R

R

R

R

R

4.3.1.2 XDS Specific Requirements
2920

In an XDS setting, a DocumentEntry is stored in the XDS Document Registry and its related
document is stored in a XDS Document Repository.
A DocumentEntry in the XDS Document Registry is used to represent a document in a XDS
Document Repository.

2925

A DocumentEntry object in the XDS Document Registry contains a reference to a single
document in a single XDS Document Repository.
Note: A repository may hold documents that are not indexed in the registry.

ITI TF-2x: Appendix H defines the metadata to initialize an ebXML registry to serve as an XDS
Document Registry.
SubmissionSets are immutable, except in cases where patientID must be updated.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

115

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
2930

A Submission Request is the collection of information that is transferred to an XDS Document
Registry or Repository.
4.3.1.2.1 Provide and Register Document Set-b Transaction [ITI-41]

2935

XDS uses ITI-41to transfer the collection of metadata and documents between an XDS
Document Source and an XDS Document Repository using a single
ebXMLSubmitObjectsRequest. This request contains:•

Submission Set metadata
Document Metadata
Folders to be created
Associations (various relationships and HasMember as needed)

2940
•

2945

Metadata

Zero or more documents (Each document is represented by a DocumentEntry object inthe metadata. Submissions that add metadata to the Document Registry without
adding documents to the Document Repository are possible. If the metadata contains
a DocumentEntry, then the Document must be present.)

The metadata is relayed by the XDS Document Repository to the XDS Document Registry
through a Register Document Set-b [ITI-42] transaction. Relayed metadata may include fields
added by the XDS Document Repository.
Id attributes and references: The submission may contain valid UUIDs or symbolic ids (or both)as specified in Section 4.3.1.2.2.

2950

4.3.1.2.2 Register Document Set-b Transaction [ITI-42]
XDS uses ITI-42 to transfer the collection of metadata between a XDS Document Repository
and a XDS Document Registry in a single ebXMLSubmitObjectsRequest. This request contains:

2955

•

SubmissionSet metadata•

DocumentEntry metadata•

Folders to be created•

Associations (various relationships and HasMember as needed)

Document duplication: There are several conditions regarding the duplication of document thatcan occur.
•
2960

Duplicate registration of a document - A document and its metadata are submitted to the
XDS Document Repository as part of a Provide and Register Document Set [ITI-41]
transaction. It is submitted with a symbolic entryUUID or a new (not previously used)
entryUUID for the DocumentEntry and associated ancillary objects. The same Document(i.e., one with the same DocumentEntry.uniqueId, DocumentEntry.hash and

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

116

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
DocumentEntry.size) already exists in one or more Document Repositories and is alreadyrepresented in the Document Registry. The Document Repository and Document
Registry shall accept such duplicate registration of the documents.

2965
•

2970

2975

Note: There are two approaches to detecting this fault. First, this can be detected at the Document Repository if repository
logic can validate the hashes and sizes and has record of the document uniqueId to compare. Otherwise therequest can be forwarded on to the Document Registry and let the fault be detected by the Document Registry(see next bullet). The Document Repository then deals with the error returned by the Document Registry.

•

2980

Duplicate document id submitted to repository - A document with its associated metadata
is submitted to an XDS Document Repository as part of a Provide and Register
Document Set [ITI-41] transaction. A document with the same DocumentEntry.uniqueId
is present in the Repository but the hash or size is different. This is an error, but aDocument Repository MAY choose not to reject the Submission Request (see note).

Duplicate document Id submitted to Document Registry - Metadata representing a
document (DocumentEntry) is submitted to a Document Registry as part of a Register
Document Set-b [ITI-42] transaction. A DocumentEntry object with the same uniqueId ispresent in the Document Registry but the hash or size is different. This is an error and theSubmission Request shall be rejected by the XDS Document Registry.

Note: A document can be registered by multiple Document Sources with the same uniqueId, same hash, same size,
different entryUUID, and with other metadata attributes not the same as described above. As a result, a Document
Consumer may issue a GetDocuments Stored Query with a uniqueId parameter and have returned two or more
DocumentEntry objects with that same uniqueId.

2985

Id attributes and references: Registries shall only accept and produce lowercase UUIDs as
specified in Section 4.2.3.1.4.

2990

Id references, or pointers, between elements of metadata are necessary for forming submissions
and understanding query responses. The sourceObject and targetObject attributes of an
Association are id references. Classifications and ExternalIdentifier type attributes are nested
inside the objects they describe but they also contain id references to their parent objects.

2995

Id references to objects in the Registry shall be in UUID format. Id references to other objects
within a submission may be UUID or symbolic format. All Id references returned in a Stored
Query shall be in UUID format. A responsibility of a Document Registry when accepting a
Register Document Set transaction is to translate any symbolic Ids into UUIDs before storingthem in the registry.
Symbolic Id format is any string that does not have the prefix ‘urn:uuid:’.
Once a UUID format Id value is assigned to a Registry Object, that value shall be permanent andshall not be changed.
4.3.1.2.3 XDS Atomicity of Submissions

3000

XDS Submission requests shall be atomic operations. If any part of the Submission Request
Processing fails, the entire transaction shall fail and no changes result. The result of a successful
Submission Request is to update either:
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

117

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________a Document Registry ora Document Registry and a Document Repository.
3005

The XDS Document Registry addresses the fact that the ebXML Registry specification does notguarantee that SubmitObjectsRequest are atomic. XDS specifies the mechanism through which
atomicity is to be implemented and where it is needed.
If an error occurs, storing documents in the repository then all documents stored as part of theRepository Submission Request shall be removed.

3010

If an error occurs, storing metadata in the Document Registry, then the following actions shall be
performed:
All metadata stored as part of the Registry Submission Request shall be removed from theDocument Registry3015

All documents stored as part of the Repository Submission Request shall be removed. This only
applies if the Registry Submission Request is a result of a Repository Submission Request.
Registry queries from the Registry Stored Query [ITI-18] transaction shall not find XDS
SubmissionSets, XDS Folders or DocumentEntry objects until after the above atomic operationthat creates them has completed successfully and the availabilityStatus attributes of the Folders
and DocumentEntries have been set to Approved.

3020

For document metadata included by value, a rollback of the submission shall delete thedocument metadata and the Association. For document metadata included by reference, arollback of the submission shall not delete the document metadata but shall still delete the
Association. The document whose Association is being deleted existed before this submission
and shall be maintained.

3025

4.3.1.2.4 XDS Registry Enforcement of Attributes
The XDS Document Registry enforces rules on metadata content. Other document sharing
profiles have their own different enforcement specifications. A summary of attributeenforcement is provided in Tables 4.3.1.2-1, 4.3.1.2-2 and 4.3.1.2-3; details on certain attributes
are given in Section 4.3.1.2.5 XDS Registry Responsibilities.

3030

3035

The Registry shall reject any submission which includes attribute values whose size exceeds the
specification in the standard.
ebRIM version 3.0 data type Slot/ValueList/Value is limited to 256 characters before XML
escaping by that standard. Document Sharing metadata may have restricted this to 128 charactersor less. Some HL7 data types may be longer according to HL7; however, when encoded as slots,
the Document Source shall restrict these to fit into the 256 character space allocated. This may
require some information to be excluded. The XDS Profile gives no guidance as to how
information is to be excluded to make this coding limit.
The XDS Document Registry shall enforce the cardinality rules as per Section 4.2.3.1.9.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

118

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Table 4.3.1.2-1: DocumentEntry Metadata Attribute Enforcement
DocumentEntry Attribute

Registry Enforcement

availabilityStatus

Enforcement of format only

authorInstitution

Enforcement of format only

authorPerson

Enforcement of format only

authorRole

Enforcement of format only

authorSpecialty

Enforcement of format only

authorTelecommunication

Enforcement of format onlyclassCodeCoding Scheme and Code Value and
CodeDisplayName

confidentialityCode

Coding Scheme and Code Value and
CodeDisplayName

creationTime

Enforcement of format only

entryUUID

Enforcement of format only

eventCodeList

Coding Scheme and Code Value and
CodeDisplayName

formatCode

Coding Scheme and Code Value and
CodeDisplayName

hash

Hash value enforcement

healthcareFacilityTypeCode

Coding Scheme and Code Value and
CodeDisplayName

legalAuthenticator

Enforcement of format only

languageCode

Optionally enforced by XDS Affinity Domain

mimeType

Code Value

patientId

Authority Domain Id
Patient Id (known from patient identity feed)practiceSettingCode

Coding Scheme and Code Value and
CodeDisplayNamereferenceIdList

If present and not empty then shall be CXi encoded

serviceStartTime

Enforcement of format only

serviceStopTime

Verifies serviceStartTime <= serviceStopTime

size

Enforcement of format only

sourcePatientId

Enforcement of format only

sourcePatientInfo

Some parts required

title

Enforcement of format only

typeCode

Coding Scheme and Code Value and
CodeDisplayName

uniqueId

No identical existing uniqueId in registry (assigned
to DocumentEntry, SubmissionSet, or Folder) ,unless there is duplicate Document registration as
described in the Document Duplication text in
Section 4.3.1.2.2

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

119

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
DocumentEntry Attribute

Registry Enforcement

URI

Enforcement of format only

3040
Table 4.3.1.2-2: SubmissionSet Metadata Attribute Enforcement
SubmissionSet Attribute

Registry Enforcement

authorInstitution

Enforcement of format only

authorPerson

Enforcement of format only

authorRole

Enforcement of format only

authorSpecialty

Enforcement of format only

authorTelecommunication

Enforcement of format only

comments

Enforcement of format only

contentTypeCode

Coding Scheme and Code value and
CodeDisplayName

patientId

Authority Domain Id
Patient Id (known from patient identity feed)sourceId

Enforcement of format only

submissionTime

Enforcement of format only

uniqueId

No identical existing uniqueId in registry (assigned
to DocumentEntry, SubmissionSet, or Folder)

Table 4.3.1.2-3: Folder Metadata Attribute Enforcement
Folder Attribute

3045

Registry Enforcement

codeList

Coding Scheme and Code value and CodeDisplayName

comments

Enforcement of format only

lastUpdateTime

Shall be set to the current time on submission of folder orfolder content changes.

patientId

The value of the patientId shall be the same for all documentsof a Folder.

uniqueId

No identical existing uniqueId in registry (assigned toDocumentEntry, SubmissionSet, or Folder)

4.3.1.2.5 XDS Registry Responsibilities
The XDS Document Registry extends functionality beyond the ebXML registry standard. The
Document Registry performs validation as specified below:
Validate patient Id –patientIds (such as the DocumentEntry.patientId attribute) shall be a
known patient Id and registered against the Patient Id Domain of the XDS Affinity Domain
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

120

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
3050

3055

3060

managed by the Patient Identity Source Actor for the XDS Affinity Domain. This validation
requirement does not apply to DocumentEntry.sourcePatentId.
•

Patient identifiers shall be verified against the patient identifiers received from the Patient
Identity Feed [ITI-8] indicating that it is registered against the Patient ID Domain of theAffinity Domain.

•

Patient identifiers shall be verified against known subsumed patient identifiers received
from the Patient Identity Feed [ITI-8]. A submission containing a subsumed patient
identifier shall return an XDSUnknownPatientId error. See ITI TF-2a: 3.8.4.2.4 forbackground on patient identifier merge.

Validate submitted metadata – the adaptor shall verify that submitted metadata meets XDS
Registry metadata specificationVerify coded values – the adaptor shall verify that coded fields (ebXML external classifications)contain valid XDS specified values or where the XDS Affinity Domain constrains code values,
to verify them. Optionally, verify that the code display names match the code value and schema.

3065

Ensure submissions are atomic - The adaptor shall make submission to registry an atomic
operation – see Section 4.3.1.2.3 XDS Atomicity of Submissions for Submission Requests foratomicity requirements.
If the registry submission is successful then the adaptor shall label all submitted DocumentEntry,
Folder, and SubmissionSet objects as Approved. If the registry submission fails then the adaptor
shall remove from the registry all objects stored as part of this SubmissionSet.

3070

3075

Support Folder membership - When the Document Registry Actor detects a HasMember
association in the submission with a sourceObject attribute which references a Folder in thesubmission or in the registry then it shall verify that:•

The targetObject references a DocumentEntry in the submission or registry.

•

If the targetObject is in the registry then it shall have availabilityStatus of Approved.

•

There is also a HasMember association linking the SubmissionSet to the FolderDocumentEntry association.

Support document relationship associations - When a Submission Request includes a‘APND’, ‘XFRM’, ‘RPLC’, ‘XFRM_RPLC’ or ‘Signs” association the Document Registry shallverify the association attributes as follows.
3080•

The sourceObject references a DocumentEntry in the submission•

The targetObject references a DocumentEntry in the Registry•

The targetObject DocumentEntry has availabilityStatus of Approved

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

121

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

3085

Support document replacement - When a Submission Request includes a ‘RPLC’ or‘XFRM_RPLC’ Association indicating that a DocumentEntry is being replaced, the following
shall be true:•

DocumentEntry to be replaced shall have status = Approved.

•

The Association’s sourceObject attribute shall contain the Id (UUID or symbolic Id) ofan ExtrinsicObject representing a DocumentEntry included in the SubmissionSet.

•

The Association’s targetObject attribute shall contain the UUID of an ExtrinsicObject(DocumentEntry) already in the registry.

3090

When the ‘RPLC’ or ‘XFRM_RPLC’ Association is detected by the Registry Adaptor it shall:•

Return the error XDSReplaceFailed if this object is not contained in the registry, or
has status other than Approved. This ensures that only the most recent version of adocument can be replaced.

•

Submit the Submission Request to the registry.

•

If the submission is successful, label the replacement document as Approved and thereplaced document as Deprecated.

•
3100

The existing document and the document replacing it shall have the same patient
identifier (XDSDocumentEntry.patientId attribute). This comparison shall take into
consideration patient identity merges as described in ITI TF-2a: 3.8.4.2.4.

3105

Validate patientIds in Folders - The adaptor shall verify that all DocumentEntries in a Folder
are for the same patient. Specifically, verify that the value of the patientId attribute of the Folder
matches the value of the patientId attribute of each DocumentEntry in the Folder. This
comparison shall take into consideration patient identity merges as described in ITI TF-2a:3.8.4.2.4.

3095

Validate patientId in SubmissionSets:

3110

•

Must match included Folders•

Must match include DocumentEntries (by value)

Validate MIME types - The adaptor shall validate that the mimeType DocumentEntry attributefor all DocumentEntries received is on the approved list for this XDS Affinity Domain.
Maintain Folder attribute ‘lastUpdateTime’ – The Folder attribute lastUpdateTime shall be
updated by the adaptor every time a new DocumentEntry is added to a Folder.

3115

Validate patientId on documents being added to a Folder - The value of the patientId
attribute of a DocumentEntry object shall match the value of the patientId attribute on any folderthat holds it.
Accept submissions containing multiple DocumentEntries– The adaptor shall be capable ofaccepting submissions containing multiple DocumentEntries.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

122

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
4.3.1.2.6 Required Initialization of the XDS Affinity Domain
3120

This initialization supports the operation of the Registry Adaptor. The following informationmust be provided by the XDS Affinity Domain administrator and loaded into the Registry
Adaptor. This supports the functionality specified for the Registry Adaptor in Section 4.3.1.2.
How this information is loaded into the Registry Adaptor or how the Registry Adaptor is
implemented is not defined by the XDS Profile.
1. List of acceptable mimeTypes for documents indexed by the registry.

3125

2. Domain name (Patient Id Assigning Authority) for XDS Affinity Domain. PatientIds
attached to metadata submitted to this registry shall come from this Assigning Authority.
3. Acceptable values for all coded attributes characterized in the registry by ebXML
External Classifications.
4.3.2

3130

Requirements on Query Type Transactions

4.3.2.1 Query Type Metadata Attribute Optionality
This section lists which attributes shall contain content in a response to a query transaction. The
query transactions covered in Table 4.3.2.1-1. The content of the query request can be foundwithin the referenced transaction.

3135

Table 4.3.2.1-1: Responding Actor/Transaction Pairs
Actor

Transaction

ShortnameXDS Document RegistryITI-18 Registry Stored QueryXDS DRXCA Initiating Gateway

ITI-18 Registry Stored Query

XCA IGXCA Responding Gateway

ITI-38 Cross-Gateway Query

XCA RGMPQ Document RegistryITI-51 Multi-Patient Stored QueryMQP DRFor each actor/transaction pair across the top of the table, and each metadata attribute row, thecells indicates the requirement for that actor when creating a query response to the paired
transaction. The requirements are expressed through these codes:
3140

Table 4.3.2.1-2: Responding Actor Metadata Attribute Optionality Code Definitions
Code

MeaningR

Required – A value for the attribute shall be supplied by the responding Actor when
responding to a query

R2

Required if Known – A value for the attribute shall be supplied by the responding Actor
when responding to the query if a value is available to the Actor. For the Document
Registry it must supply the value specified in the submission request.

O

Optional – The responding Actor may or may not supply a value for this attribute. For theDocument Registry it must supply the value specified in the submission request.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

123

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Code

Meaning

X

Prohibited – When responding to a query, a value for the attribute shall not be supplied by
the responding Actor.

R3

Required for Stable DocumentEntries and not allowed for On-Demand DocumentEntries.

Table 4.3.2.1-3: Responding Actor Metadata Attribute Optionality
Metadata
Element

Metadata Attribute

XDS
DR

XCA
IG

XCA
RG

MPQ
DR

DocumentEntry

author

R2

R2

R2

R2

DocumentEntry

availabilityStatus

R

R

R

R

DocumentEntry

classCode

R

R

R

R

DocumentEntry

comments

O

O

O

O

DocumentEntry

confidentialityCode

R

R

R

R

DocumentEntry

creationTime

R3

R3

R3

R3

DocumentEntry

entryUUID

R

R

R

R

DocumentEntry

eventCodeList

O

O

O

O

DocumentEntry

formatCode

R

R

R

R

DocumentEntry

hash

R3

R3

R3

R3

DocumentEntry

healthcareFacility
TypeCode

R

R

R

R

DocumentEntry

homeCommunityId

O

R

R

O

DocumentEntry

languageCode

R

R

R

R

DocumentEntry

legalAuthenticator

O

O

O

O

DocumentEntry

limitedMetadata

X

X

X

X

DocumentEntry

mimeType

R

R

R

R

DocumentEntry

objectType

R

R

R

R

DocumentEntry

patientId

R

R

R

R

DocumentEntry

practiceSettingCode

R

R

R

R

DocumentEntryreferenceIdList

O

O

O

O

DocumentEntry

repositoryUniqueId

R

R

R

R

DocumentEntry

serviceStartTime

R2

R2

R2

R2

DocumentEntry

serviceStopTime

R2

R2

R2

R2

DocumentEntry

size

R3

R3

R3

R3

DocumentEntry

sourcePatientId

R

R

R

R

DocumentEntry

sourcePatientInfo

O

O

O

O

DocumentEntry

title

O

O

O

O

DocumentEntry

typeCode

R

R

R

R

DocumentEntry

uniqueId

R

R

R

R

DocumentEntry

URI

O

O

O

O

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

124

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Metadata
Element

Metadata Attribute

XDS
DR

XCA
IG

XCA
RG

MPQ
DR

SubmissionSet

author

R2

R2

R2

R2

SubmissionSet

availabilityStatus

R

R

R

R

SubmissionSet

comments

O

O

O

O

SubmissionSet

contentTypeCode

R

R

R

R

SubmissionSet

entryUUID

R

R

R

R

SubmissionSet

homeCommunityId

O

R

R

O

SubmissionSet

intendedRecipient

O

O

O

O

SubmissionSet

limitedMetadata

X

X

X

X

SubmissionSet

patientId

R

R

R

R

SubmissionSet

sourceId

R

R

R

R

SubmissionSet

submissionTime

R

R

R

R

SubmissionSet

title

O

O

O

O

SubmissionSet

uniqueId

R

R

R

R

FolderavailabilityStatus

R

R

R

R

FoldercodeList

R

R

R

R

Foldercomments

O

O

O

O

FolderentryUUID

R

R

R

R

FolderhomeCommunityId

O

R

R

O

FolderlastUpdateTime

O

O

O

O

FolderlimitedMetadata

X

X

X

X

FolderpatientId

R

R

R

R

Folder

title

R

R

R

R

FolderuniqueId

R

R

R

R

3145

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

125

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

5 IHE Content Specifications
This section follows the documentation pattern found in the IHE PCC Technical Framework.
The reader should be familiar with the IHE PCC Technical Framework.

5.1
3150

Basic Patient Privacy Consents ModuleThis section describes the encoding requirements for the Basic Patient Privacy Consents
Document Content.
The BPPC document has two possible document templates, one without a scanned document
part, and one in Section 5.1.2 defines the requirements of the BPPC document without a scanned
document part; Section 5.1.3 explains with a scanned document part.

3155

5.1.1 References•

HL7 CDA Release 2.0 (denoted HL7 CDA R2, or just CDA, in subsequent text)

5.1.2 Patient Privacy Consent Acknowledgment Document Specification
1.3.6.1.4.1.19376.1.5.3.1.1.7 – With no Scanned Document Part
3160

A patient acknowledgement of a Patient Privacy Consent Policy is a document that contains
machine readable indication. This specification describes the BPPC document without a scanned
part. When the Patient Privacy Consent Acknowledgment Document contains a Scanned
Document (XDS-SD), it will conform to Section 5.1.3.
5.1.2.1 XDS Metadata
5.1.2.1.1 XDS DocumentEntry Metadata

3165

BPPC leverages the XDS DocumentEntry Metadata requirements in the IHE PCC TF-2: 4.1.1
unless otherwise specified below.
5.1.2.1.1.1 XDSDocumentEntry.classCode
The LOINC code for these documents is “57016-8” “Privacy Policy Acknowledgement
Document” and the codeSystem is 2.16.840.1.113883.6.1.

3170

For backward compatibility historic documents may be registered with:•classCode -- This attributes may have been set to the value "Consent".

•

classCodeDisplayName -- This attributes may have been set to the value "Consent".

5.1.2.1.1.2 XDSDocumentEntry.eventCodeList•
3175

eventCodeList -- the eventCodeList shall be populated using the Patient Privacy Policy
Identifiers that have been acknowledged to within the document.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

126

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
•
•
3180

/ClinicalDocument/documentationOf/serviceEvent[templateId/@root='1.3.6.1.4.1.193
76.1.5.3.1.2.6']/code/@code

eventCodeDisplayNameList -- The eventCodeDisplayNameList shall be populated using
the display names for those policies.
•/ClinicalDocument/documentationOf/serviceEvent[templateId/@root='1.3.6.1.4.1.193
76.1.5.3.1.2.6']/code/@displayName

5.1.2.1.1.3 XDSDocumentEntry.formatCode
The XDSDocumentEntry format code for this content shall be urn:ihe:iti:bppc:2007. The
formatCode codeSystem shall be 1.3.6.1.4.1.19376.1.2.3.
3185

5.1.2.1.1.4 XDSDocumentEntry.uniqueId
This value shall be the ClinicalDocument/id in the HL7 CDA R2 header. The root
attribute is required, and the extension attribute is optional. The total length is limited to 256
characters. Additionally see IHE PCC TF-2: 4.1.1, for further content specification.
5.1.2.1.2 XDS SubmissionSet Metadata

3190

No additional constraints. For more information, see IHE PCC TF-2: 4.1.2
5.1.2.1.3 XDS Folder Metadata
No additional requirements. For more information, see IHE PCC TF-2: 4.1.3
5.1.2.2 Specification

3195

CDA Release 2.0 documents that conform to the requirements of this content module shallindicate their conformance by the inclusion of the appropriate <templateId> elements in theheader of the document. This is shown in the sample document below. A CDA Document may
conform to more than one template. This content module inherits from the Medical Document
content module, and so must conform to the requirements of that template as well, thus all<templateId> elements shown in the example below shall be included.

3200

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

127

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

3205

3210

<ClinicalDocument xmlns='urn:hl7-org:v3'><typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/><templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.1'/><templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.7'/><id root=' ' extension=' '/><code code='57016-8' displayName='PATIENT PRIVACY ACKNOWLEDGEMENT'
codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/><title>Consent to Share Information</title><effectiveTime value='20070619012005'/><confidentialityCode code='N' displayName='Normal'
codeSystem='2.16.840.1.113883.5.25' codeSystemName='Confidentiality' /><languageCode code='en-US'/>:<component><structuredBody>

3215</structuredBody></component></ClinicalDocument>

Figure 5.1.2.2-1: Sample Consent to Share Information Document

3220

3225

A Patient Privacy Acknowledgement Document shall contain a text description of what thepatient consented to, a list of codes indicating the policy(s) agreed to, and a time range indicating
the effective time of the consent. It may be attested to using an electronic digital signature,
conforming to the ITI Digital Signature Profile.
A Patient Privacy Acknowledgement Document shall have one or more <serviceEvent> elementsin the header identifying the policies acknowledged by the document (see Section 4.2.3.4 of
CDA R2). Each <serviceEvent> element indicates an acknowledgement of a Patient Privacy
Policy. More than one policy may be acknowledged to within a given document.
Data Element Name

Opt

Patient Privacy Acknowledgement Service EventAt least one, and possibly more than one acknowledgement can be provided within the
document.

3230

R

Template ID
1.3.6.1.4.1.19376.1.5.3.1.2.6

5.1.2.2.1 Patient Privacy Acknowledgement Service Events
1.3.6.1.4.1.19376.1.5.3.1.2.6
Within a Patient Privacy Acknowledgement Document, there shall be a Patient Privacy
Acknowledgement Service Event with the effective time of the consent shall be specified within
the documentationOf/serviceEvent element.

3235

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

128

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

3240

3245

<documentationOf typeCode='DOC'><serviceEvent classCode='ACT' moodCode='EVN'><templateId root='1.3.6.1.4.1.19376.1.5.3.1.2.6'/><id root='1.2.3.4.5.6'/><code code='9.8.7.6.5.4.3.2.1' displayName='Chicken Costume Consent'
codeSystem='9.8.7.6.5.4.3.2.2' codeSystemName='Silly Policy Land'/><effectiveTime><low value='20101130'/></effectiveTime></serviceEvent></documentationOf>

Figure 5.1.2.2-2: Patient Privacy Acknowledgement Service Events Example

5.1.2.2.2 <documentationOf typeCode='DOC'>
3250

At least one <documentationOf> element shall exist, describing the service event. This element
shall have a typeCode attribute with the value DOC.
5.1.2.2.3 <serviceEvent classCode='ACT' moodCode='EVN'>
One <serviceEvent> shall exist for each Patient Privacy Policy acknowledged. This element shallhave a classCode attribute set to ACT, and a moodCode attribute of EVN.

3255

5.1.2.2.4 <templateId root='1.3.6.1.4.1.19376.1.5.3.1.2.6'/>
The <templateId> element shall be recorded exactly as shown above, and identifies this<serviceEvent> as recording the acknowledgement of a Patient Privacy Policy.
5.1.2.2.5 <id root=' ' />3260

The service event shall have one <id> element, providing an identifier for the service event. The
root attribute of this element shall be present, and shall be a GUID or OID. The extension
attribute shall not be present.
5.1.2.2.6 <code code=' ' displayName=' ' codeSystem=' ' codeSystemName=' '/>3265

The <code> element shall be present, and shall indicate the Patient Privacy Policy
acknowledged. The code attribute indicates the Patient Privacy Policy Identifier, and thecodeSystem attribute indicates the code system for the Patient Privacy Policy Domain fromwhich this Patient Privacy Policy Identifier is assigned. The displayName attribute may bepresent, and describes the Patient Privacy Policy acknowledgement. The codeSystemName
attribute may be present, and describes the Patient Privacy Policy Domain code system.
5.1.2.2.7 <effectiveTime><low value=' '/><high value=' '/></effectiveTime>3270

The <effectiveTime> element shall be present, and shall indicate the effective time range overwhich acknowledgement is given. The low value must be provided. The high value may be
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

129

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
present. If present, it shall indicate the maximum effective time of the consent. The
effectiveTime must be the same for all ServiceEvents in one Patient Privacy Acknowledgement
Document. If different effectiveTimes are needed then different documents should be generated.
3275

5.1.3 Patient Privacy Consent Acknowledgment Document Specification
1.3.6.1.4.1.19376.1.5.3.1.1.7.1 – With Scanned Document
A patient acknowledgement of a Patient Privacy Consent Policy is a document that contains
machine readable indication. This section specifies the BPPC document with a scanned
document part.

3280

5.1.3.1 XDS Metadata
The BPPC document shall conform to the requirements in Section 5.1.2.1 with the formatCode
exception listed below
5.1.3.1.1 XDS DocumentEntry Metadata

3285

The BPPC document shall conform to the DocumentEntry Metadata requirements in the IHE
PCC TF-2:5.1.1.1.1 unless otherwise specified below.
5.1.3.1.1.1 XDSDocumentEntry.formatCode
The XDSDocumentEntry format code for this content is urn:ihe:iti:bppc-sd:2007. The
formatCode codeSystem shall be 1.3.6.1.4.1.19376.1.2.3.
5.1.3.1.2 XDS SubmissionSet Metadata

3290

No additional constraints. For more information, see IHE PCC TF-2: 5.1.1.1.2
5.1.3.1.3 XDS Folder Metadata
No additional requirements. For more information, see IHE PCC TF-2: 5.1.1.1.3
5.1.3.2 Specification

3295

This BPPC document shall conform to the XDS-SD (Section 5.2) specification and shall havethe additional requirements stated in Section 5.1.2.3.
5.1.3.3 Conformance
See Section 5.1.2.2.

5.2
3300

Scanned Documents Content ModuleThis section outlines the content of the HL7 CDA R2 constraints for the document. We note herethat requirements specified below are to ensure the presence of a minimum amount of wrapper
data in order to enhance description and facilitate sharing of the document. Implementers of this
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

130

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

3305

profile can and should make use of additional annotation within the CDA header to provide
richer context. The examples in the following sections contain the minimal amount of wrapper
data, as specified, and in many cases do make use of additional CDA header elements forenriched context.
Assumptions and Definitions: We assume that the scanning facility and equipment within it areassigned an OID and that the scanning facility assembles the wrapped scanned content. Moreinformation regarding the construction of OIDs can be found in ITI TF-2x: Appendix B. We
define the following nomenclature for entity roles concerned in forming the wrapper content.

3310

3315

3320

•

Original content – Legacy paper or electronic document intended for wrapping.

•

Scanned content – Scanned or appropriately converted/encoded electronic version of theoriginal content.

•

Original author – Author of the original content.

•(Scanner) Operator – Person assembling the scanned content.

5.2.1 Referenced Standards•

PDF RFC 3778, The application/pdf Media Type (informative)•

PDF/A ISO 19005-1b. Document management - Electronic document file format for
long-term preservation - Part 1: Use of PDF (PDF/A)•

HL7 CDA Release 2.0 (denoted HL7 CDA R2, or just CDA, in subsequent text)•

RFC 5646, Tags for the identification of languages

5.2.1.1 Discussion of Content Standards

3325

PDF and plaintext documents intended for wrapping can consist of multiple pages. Encoding ofmultiple page PDF documents are subject to the PDF/A standard. This ISO standard, PDF/A, is asubset of Adobe PDF version 1.4 intended to be suitable for long-term preservation of pageoriented documents. PDF/A attempts to maximize:•

Device independence•

Self-containment•

Self-documentation

The constraints imposed by PDF/A include:
3330•

Audio and video content are forbidden•

JavaScript and executable file launches are prohibited•All fonts must be embedded and also must be legally embeddable for unlimited, universal
rendering

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

131

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

3335

3340

3345

3350

3355

•

Colorspaces specified in a device-independent manner•

Encryption is disallowed (although the enclosing document and transport may provide
encryption external to the PDF content)•

Compression methods are restricted to a standard list

The PDF/A approach has several advantages over TIFF or JPEG. First, there are more image
compressions and format flexibility in PDF, so that the image files sizes can be kept smaller.
There are many simple programs available for converting TIFF and JPEG into PDF with various
other features for improving compression or adding other information. The PDF/A enables
devices that produce vectorized output. Unlike TIFF, JPEG, or BMP, a PDF/A image has theability to provide several "layers" of information. This allows the creation of PDF searchable
images.
A PDF searchable image is a PDF document with an exact bitmapped replica of the scanned
paper pages and with text information stored behind the bitmap image of the page. This approachretains the look of the original pages while enabling text searchability and computer analysis.
This approach is especially suitable for documents that have to be searchable while retaining theoriginal scan details. The text layer is created by an Optical Character Recognition (OCR)
application that scans the text on each page. It then creates a PDF file with the recognized text
stored in a layer beneath the image of the text. Unrecognized graphics areas and annotations arepreserved with full fidelity in the image. The text form may be incomplete or the OCR confusedby some words, but the original image is preserved and available.
Plaintext as well as PDF/A documents shall be base-64 encoded before wrapped in a HL7 CDA
R2 header. The PDF/A documents shall conform to PDF/A-1b. Creators are encouraged toconform to PDF/A-1a to the maximum extent possible, but a simple document scanner may beunable to fully conform to PDF/A-1a. Other profiles may require PDF/A-1a conformance.
HL7 CDA R2 header schema is constrained so that pertinent metadata values and scanningfacility, technology and operator information shall be present (see Section 5.2.3).

3360

Medical imagery and photographs are outside the scope of this profile. Diagnostic or intervention
medical imagery will be supported through DICOM (which includes the use of JPEG andMPEG). Additionally audio and video recorded content is not covered by this profile.
5.2.2 XDS Metadata3365

XDS-SD is a CDA R2 document and thus conforms to the XDS Metadata requirements in the
PCC TF-2:4 unless otherwise specified below.
5.2.2.1 XDS DocumentEntry Metadata
XDS-SD leverages the XDS DocumentEntry Metadata requirements in the PCC TF-2: 4.1.1
unless otherwise specified below.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

132

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
5.2.2.1.1 XDSDocumentEntry.formatCode3370

The XDSDocumentEntry.formatCode shall be urn:ihe:iti:xds-sd:pdf:2008 when the document
is scanned pdf and urn:ihe:iti:xds-sd:text:2008 when the document is scanned text. The
formatCode codeSystem shall be 1.3.6.1.4.1.19376.1.2.3.
5.2.2.1.2 XDSDocumentEntry.uniqueId

3375

This value shall be the ClinicalDocument/id in the HL7 CDA R2 header. The root attribute isrequired, and the extension attribute is optional. In accordance with the XDS Profile, total length
is limited to 256 characters. Additionally see PCC TF-2: 4.1.1, for further content specification.
5.2.2.1.3 Relating instances of XDS-SD documents

3380

3385

In general, most instances of XDS-SD will not have parent documents. It is possible, however, insome specific use cases that instances of XDS-SD documents are related. For example, for aparticular document it may be the case that both the PDF scanned content and somewhat
equivalent plaintext need to be wrapped and submitted. Each document would correspond to
separate XDSDocumentEntries linked via an XFRM Association that indicates one document is
a transform of the other. These can be submitted in a single submission set, or in separate ones.
Other specific examples may exist and this profile does not preclude the notion of a parent
document for these cases.
5.2.2.2 XDS SubmissionSet Metadata
No additional constraints. Particular to this profile, a legitimate use of submission sets would be
to maintain a logical grouping of multiple XDS-SD documents. We encourage such usage. For
more information, see PCC TF-2: 4.1.2

3390

5.2.2.3 XDS Folder Metadata
No additional requirements. For more information, see PCC TF-2: 4.1.3

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

133

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

5.2.3 Specification
HL7 CDA R2 header
element

CDA asconstrai
ned byXDS-SD

SectionNumber ofExtended
Discussion

SourceType

ClinicalDocument/typeId

R

5.2.3.1

FM

Fixed, per CDA R2 version inuse.

ClinicalDocument/templateId

R

5.2.3.1

FM

Fixed, per this specification

ClinicalDocument/id

R

5.2.3.1

DS

Computable.

O / FMEntered by operator orappropriately fixed for scanned
content

ClinicalDocument/code

R

5.2.3.1

Source / Value

ClinicalDocument/title

R2

5.2.3.1

SA / OEntered by operator, or possibly
can be taken from the scanned
content.

ClinicalDocument/confidentiality
CodeR

5.2.3.1

O

Assigned by the operator

ClinicalDocument/effectiveTimeR

5.2.3.1

DS

Computed. This is the scantime.

ClinicalDocument/languageCodeR

5.2.3.1

OEntered by operator

ClinicalDocument/recordTarget

R

5.2.3.2

SA / O

Taken from scanned content,
supplemented by operator.

SA / O

Taken from scanned content,
supplemented by operator. Thisis the original author.

DS / FM/O

Can be computed or fixed basedon the scanning device andsoftware. This is theinformation about the scanningdevice.

DS / OCan be computed by thescanner or supplemented byoperator. This is theinformation about the scanner
operator.

DS / FM

Retains original HL7 CDA
Context. To be computed or
fixed appropriately to denote
guardianship of the scanned andwrapped content.

ClinicalDocument/author/assigne
dAuthor/assignedPerson

ClinicalDocument/author/assigne
dAuthor/authoringDevice

ClinicalDocument/dataEnterer

ClinicalDocument/custodian

R2

R

R

R

5.2.3.3

5.2.3.4

5.2.3.5

5.2.3.6

ClinicalDocument/legalAuthenti
cator

O

5.2.3.7

O

Most likely supplemented by
the operator, when applicable ormandated.

ClinicalDocument/documentatio
nOf/serviceEvent/effectiveTimeR

5.2.3.8

SA / O

Denotes the time/date range ofthe original content.

ClinicalDocument/component/no
nXMLBodyR

5.2.3.9SA

The scanned/encoded content.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

134

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
5.2.3.1 ClinicalDocument child-less elements
3395

In this section we further discuss id, code, effectiveTime, confidentialityCode andlanguageCode elements of the ClinicalDocument.
•

The ClinicalDocument/templateId element shall be present. The root attribute shallcontain the oid, ‘1.3.6.1.4.1.19376.1.2.20’, to indicate this document is an XDS-SD
document.

•

The ClinicalDocument/id element shall be present. The root attribute shall contain the oid
for the document, in which case the extension attribute shall be empty, or an oid that
scopes the set of possible unique values for the extension attribute, in which case theextension shall be populated with a globally unique identifier within the scope of the rootoid.

•

The ClinicalDocument/code will in most cases be provided by the operator. Values forthis code are dictated by the CDA R2 documentation, but are permissible to extend to fit
the particular use case. Attributes code@code and code@codeSystem shall be present.

•

The ClinicalDocument/title shall be present if known.

•

The ClinicalDocument/effectiveTime shall denote the time at which the original content
was scanned. At a minimum, the time shall be precise to the day and shall include thetime zone offset from GMT.

•

The ClinicalDocument/confidentialityCode shall be assigned by the operator inaccordance with the scanning facility policy. The notion or level of confidentiality in theheader may not be the same as that in the Affinity Domain, but in certain cases could be
used to derive a confidentiality value among those specified by the Affinity Domain.
Attributes confidentialityCode@code and confidentialityCode@codeSystem shall bepresent.

•

The ClinicalDocument/languageCode, in accordance with the HL7 CDA R2
documentation, shall denote the language used in the character data of the wrapper CDA
header. If the scanned content, when rendered, is in a language different than that of theheader, the language context of the CDA will be overwritten at the body level (seeSection 5.2.3.9 ClinicalDocument/component/nonXMLBody for an example). Attributecode@code shall be present. Attribute code@codeSystem shall be IETF (Internet
Engineering Task Force) RFC 5646 in accordance with the HL7 CDA R2 documentation.

3400

3405

3410

3415

3420

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

135

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Example:3425<ClinicalDocument xmlns=“urn:hl7-org:v3”><typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/><templateId root=”1.3.6.1.4.1.19376.1.2.20”/><id root=“1.3.6.4.1.4.1.2835.2.7777”/><code code=“34133-9” codeSystem=“2.16.840.1.113883.6.1”
codeSystemName=“LOINC” displayName=“SUMMARIZATION OF EPISODE NOTE”/><title>Good Health Clinic Care Record Summary</title><effectiveTime value=“20050329224411+0500”/><confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/><languageCode code=“en-US”/>

5.2.3.2 ClinicalDocument/recordTarget

3430

The ClinicalDocument/recordTarget contains identifying information about the patientconcerned in the original content. In many cases this will have to be supplied by the operator. All
subelements retain their original definition as defined by the HL7 CDA R2 specification, unless
noted below.
•

The ClinicalDocument/recordTarget/patientRole/id element shall include both the root
and the extension attributes. Refer to PCC TF-2: 4.1.1 for more details.

•

At least one ClinicalDocument/recordTarget/patientRole/addr element shall include atleast the country subelement. The addr element has an unbounded upper limit on
occurrences. It can, and should, be replicated to include additional addresses for a patient,each minimally specified by the country sub element.

•

At least one ClinicalDocument/recordTarget/patientRole/ patient/name element shall be
at least one given subelement and one family subelement.

•

The ClinicalDocument/recordTarget/patientRole/patient/ administrativeGenderCode
element shall be present.

•

The ClinicalDocument/recordTarget/patientRole/patient/ birthTime element shall bepresent with precision to the year.

3435

3440

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

136

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Example:<recordTarget><patientRole><id extension="12345" root="2.16.840.1.113883.3.933"/><addr><streetAddressLine>17 Daws Rd.</streetAddressLine><city>Blue Bell</city><state>MA</state><postalCode>02368</postalCode><country>USA</country></addr><patient><name><prefix>Mrs.</prefix><given>Ellen</given><family>Ross</family></name><administrativeGenderCode code="F"
codeSystem="2.16.840.1.113883.5.1"/><birthTime value="19600127"/></patient></patientRole></recordTarget>

3445

5.2.3.3 ClinicalDocument/author (original)

3450

This ClinicalDocument/author element represents the author of the original content. It
additionally can encode the original author’s institution in the subelement
representedOrganization. Information regarding the original author and his/her institution shallbe included, if it is known. In many cases this will have to be supplied by the operator. All
subelements retain their original definition as defined by the HL7 CDA R2 specification, unless
noted below.
•

The ClinicalDocument/author/templateId element shall be present. The root attributeshall contain the oid, ‘1.3.6.1.4.1.19376.1.2.20.1’, to indicate this is the original author.

•

The ClinicalDocument/author/time represents the day and time of the authoring of theoriginal content. This value is not restricted beyond statements made in the HL7 CDA R2
documentation.

•

The ClinicalDocument/author/assignedAuthor/id element if known shall include both theroot and the extension attributes. Refer to PCC TF-2: 4.1.1 for more details.

3455

3460

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

137

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________•The ClinicalDocument/author/assignedAuthor/representedOrganization/id element if
known shall include both the root and the extension attribute. Refer to PCC TF-2:
4.1.1for more details.

Example:<author><templateId root=”1.3.6.1.4.1.19376.1.2.20.1”/><time value=“19990522”/><assignedAuthor><id extension=“11111111” root=“1.3.5.35.1.4436.7”/><assignedPerson><name><prefix>Dr.</prefix><given>Bernard</given><family>Wiseman</family><suffix>Sr.</suffix></name></assignedPerson><representedOrganization><id extension=“aaaaabbbbb” root=“1.3.5.35.1.4436.7”/><name>Dr. Wiseman’s Clinic</name></representedOrganization></assignedAuthor></author>3465

5.2.3.4 ClinicalDocument/author (scanner)

3470

This ClinicalDocument/author element shall be present and represent the scanning device andsoftware used to produce the scanned content. All subelements retain their original definition as
defined by the HL7 CDA R2 specification, unless noted below.
•

The ClinicalDocument/author/templateId element shall be present. The root attributeshall contain the oid, ‘1.3.6.1.4.1.19376.1.2.20.2’, to indicate this author is the scanningdevice and software.

•

The ClinicalDocument/author/time shall denote the time at which the original content
was scanned. This value shall be equal to that of ClinicalDocument/effectiveTime. At aminimum, the time shall be precise to the day and shall include the time zone offset fromGMT.

•

The ClinicalDocument/author/assignedAuthor/id element shall be at least the root oid of
the scanning device.

•

The ClinicalDocument/author/assignedAuthor/assignedAuthoringDevice/code element
shall be present. The values set here are taken from appropriate DICOM vocabulary. The

3475

3480

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

138

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
value of code@codeSystem shall be set to “1.2.840.10008.2.16.4”. The value ofcode@code shall be set to “CAPTURE” for PDF scanned content and “WSD” forplaintext. The value of code@displayName shall be set to “Image Capture” for PDF
scanned content and “Workstation” for plaintext.

3485
•

The
ClinicalDocument/author/assignedAuthor/assignedAuthoringDevice/manufacturerModel
Name element shall be present. The mixed content shall contain string information thatspecifies the scanner product name and model number. From this information, features
like bit depth and resolution can be inferred. In the case of virtually scanned documents(for example, print to PDF), the manufactureModelName referenced here refers to the
makers of the technology that was used to produce the embedded content.

•

The ClinicalDocument/author/assignedAuthor/assignedAuthoringDevice/softwareName
element shall be present. The mixed content shall contain string information that specifies
the scanning software name and version. In the case of virtually scanned documents, thesoftwareName referenced here refers to the technology that was used to produce theembedded content.

•

The ClinicalDocument/author/assignedAuthor/representedOrganization/id element shallbe present. The root attribute shall be set to the oid of the scanning facility.

3490

3495

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

139

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
3500

Example:<author><templateId root=”1.3.6.1.4.1.19376.1.2.20.2”/><time value=“20050329224411+0500”/><assignedAuthor><id root=“1.3.6.4.1.4.1.2835.2.1234”/><assignedAuthoringDevice><code code=“CAPTURE” displayName=“Image Capture” codeSystem=“
1.2.840.10008.2.16.4” /><manufacturerModelName>SOME SCANNER NAME AND MODEL</manufacturerModelName><softwareName>SCAN SOFTWARE NAME v0.0</softwareName></assignedAuthoringDevice><representedOrganization><id root=“1.3.6.4.1.4.1.2835.2”/><name>SOME Scanning Facility</name><addr><streetAddressLine>21 North Ave</streetAddressLine><city>Burlington</city><state>MA</state><postalCode>01803</postalCode><country>USA</country></addr></representedOrganization></assignedAuthor></author>

5.2.3.5 ClinicalDocument/dataEnterer
3505

This ClinicalDocument/dataEnterer element shall represent the scanner operator who produced
the scanned content. All subelements retain their original definition as defined by the HL7 CDA
R2 specification, unless noted below.
•

The ClinicalDocument/dataEnterer/templateId element shall be present. The root attributeshall contain the oid, ‘1.3.6.1.4.1.19376.1.2.20.3’, to indicate this is the scanner operator.

•

The ClinicalDocument/dataEnterer/time shall denote the time at which the originalcontent was scanned. This value shall be equal to that ofClinicalDocument/effectiveTime. At a minimum, the time shall be precise to the day andshall include the time zone offset from GMT.

•

The ClinicalDocument/dataEnterer/assignedEntity/id element shall be both the root andthe extension attributes the root shall be the oid of the scanning facility and the extension
shall be an appropriately assigned, facility unique id of the operator.

3510

3515

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

140

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Example:<dataEnterer><templateId root=”1.3.6.1.4.1.19376.1.2.20.3”/><time value=“20050329224411+0500”/><assignedEntity><id extension=“22222222” root=“1.3.6.4.1.4.1.2835.2”/><assignedPerson><name><prefix>Mrs.</prefix><given>Bernice</given><family>Smith</family></name></assignedPerson></assignedEntity></dataEnterer>

5.2.3.6 ClinicalDocument/custodian
3520

3525

The ClinicalDocument/custodian shall be present. Its context is left up to the scanning facility torefine in accordance with local policies and to reflect the entity responsible for the scanned
content. In most cases this will be the scanning facility. All subelements retain their original
definition as defined by the HL7 CDA R2 specification, unless noted below.
•

The ClinicalDocument/assignedCustodian/representedOrganization/name shall bepresent.

•

At least one ClinicalDocument/assignedCustodian/representedOrganization/addr element
shall include at least the country sub element.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

141

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Example:<custodian><assignedCustodian><representedCustodianOrganization><id root=“1.3.6.4.1.4.1.2835.2”/><name>SOME Scanning Facility</name><addr><streetAddressLine>21 North Ave</streetAddressLine><city>Burlington</city><state>MA</state><postalCode>01803</postalCode><country>USA</country></addr></representedCustodianOrganization></assignedCustodian></custodian>

3530

5.2.3.7 ClinicalDocument/legalAuthenticator
The ClinicalDocument/legalAuthenticator may be present and its context is left up to thescanning facility to refine in accordance with local policies. All subelements retain their original
definition as defined by the HL7 CDA R2 specification, unless noted below.
•

3535

The ClinicalDocument/legalAuthenticator/assignedEntity/id element if known shall
include both the root and the extension attribute. Refer back to PCC TF-2: 4.1.1 for moredetails.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

142

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Example:<legalAuthenticator><time value=“19990522”/><signatureCode code=“S”/><assignedEntity><id extension=“11111111” root=“1.3.5.35.1.4436.7”/><assignedPerson><name><prefix>Dr.</prefix><given>Bernard</given><family>Wiseman</family><suffix>Sr.</suffix></name></assignedPerson></assignedEntity></legalAuthenticator>

3540

3545

5.2.3.8 ClinicalDocument/documentationOf
This ClinicalDocument/documentationOf element is used to encode the date/time range ofthe original content. If the original content is representative of a single point in time then theendpoints of the date/time range shall be the same. Information regarding this date/time range
shall be included, if it is known. In many cases this will have to be supplied by the operator. This
profile does not restrict the documentationOf element beyond statements made in the HL7 CDA
R2 documentation.
Example:<documentationOf><serviceEvent ><effectiveTime><low value=“19800127”/><high value=“19990522”/></effectiveTime></serviceEvent></documentationOf>

3550

5.2.3.9 ClinicalDocument/component/nonXMLBody
This ClinicalDocument/component/nonXMLBody element shall be present and used to wrap thescanned content. The nonXMLBody element is guaranteed to be unique; thus the x-path to
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

143

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
recover the scanned content is essentially fixed. All subelements of the nonXMLBody retain
their original definition as defined by the HL7 CDA R2 specification, unless noted below.
3555•

If the human-readable language of the scanned content is different than that of thewrapper (specified in ClinicalDocument/languageCode), thenClinicalDocument/component/nonXMLBody/languageCode shall be present. Attributecode@code shall be present. Attribute code@codeSystem shall be IETF (Internet
Engineering Task Force) RFC 5646 in accordance with the HL7 CDA R2 documentation.

3560

•

The ClinicalDocument/component/nonXMLBody/text element shall be present andencoded using xs:base64Binary encoding and shall contain the scanned content.
•

ClinicalDocument/component/nonXMLBody/text@mediaType shall be“application/pdf” for PDF, or “text/plain” for plaintext.

•

When the character encoding of text/plain content is other than UTF-8, the@mediaType shall be text/plain;charset=XXX, where XXX is the name of theencoding as specified by RFC-2046.

•

ClinicalDocument/component/nonXMLBody/text@representation shall be present.
The @representation for both PDF and plaintext scanned content will be “B64”,
because this profile requires the base-64 encoding of both formats.

3565

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

144

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
3570

Example (PDF scanned content is in the same language as the wrapper):<component><nonXMLBody><text mediaType=“application/pdf” representation=“B64”>
JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0
ZURlY29kZT4+CnN0cmVhbQp4nGWPMWsDMQyFd/8KjfJwqmVbkr0GQqFbg7fQoSRNWuhB
Q/4/1L67TEEYme+9J1s3CMQQRm39NLuXg8H17gK89nN1N8eLAbZ2mmHXuql2QDVUhnZx
a5iBcyQtoMIUM7TZHbH5KZEVDgm//SSUswbFHx/JzBLeu5yYxOIzE8bPcRWqdaGDmcZO
BWc/9bfUNOPfOte44O9jxtcIKskqp0JZouJ5deYqeBn58ZmKtIU+2ptjqWQRJpGyrHDu
K7CXIe2be+/1DzXQP+RlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMjAxCmVuZG9iago0...
SW5mbyAyIDAgUgovSUQgWzxGNENDN0FFQjU0QjM2RkIyODNDNUMzMjQ3OUFEMjgzRj48
RjRDQzdBRUI1NEIzNkZCMjgzQzVDMzI0NzlBRDI4M0Y+XQo+PgpzdGFydHhyZWYKMzAx
MgolJUVPRgo=</text></nonXMLBody></component></ClinicalDocument>

Example (PDF scanned content is in a different language than the wrapper):<component><nonXMLBody><languageCode code=“zh-CN”/><text mediaType=“application/pdf” representation=“B64”>
JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0
ZURlY29kZT4+CnN0cmVhbQp4nGWPMWsDMQyFd/8KjfJwqmVbkr0GQqFbg7fQoSRNWuhB
Q/4/1L67TEEYme+9J1s3CMQQRm39NLuXg8H17gK89nN1N8eLAbZ2mmHXuql2QDVUhnZx
a5iBcyQtoMIUM7TZHbH5KZEVDgm//SSUswbFHx/JzBLeu5yYxOIzE8bPcRWqdaGDmcZO
BWc/9bfUNOPfOte44O9jxtcIKskqp0JZouJ5deYqeBn58ZmKtIU+2ptjqWQRJpGyrHDu
K7CXIe2be+/1DzXQP+RlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMjAxCmVuZG9iago0...
SW5mbyAyIDAgUgovSUQgWzxGNENDN0FFQjU0QjM2RkIyODNDNUMzMjQ3OUFEMjgzRj48
RjRDQzdBRUI1NEIzNkZCMjgzQzVDMzI0NzlBRDI4M0Y+XQo+PgpzdGFydHhyZWYKMzAx
MgolJUVPRgo=</text></nonXMLBody></component></ClinicalDocument>

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

145

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

3575

3580

3585

3590

3595

3600

3605

3610

3615

3620

5.2.4 Complete Example (Wrapped PDF)
<ClinicalDocument xmlns="urn:hl7-org:v3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" classCode="DOCCLIN"
moodCode="EVN" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd"><typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/><templateId root=”1.3.6.1.4.1.19376.1.2.20”/><id root=“1.3.6.4.1.4.1.2835.2.7777”/><code code=“34133-9” codeSystem=“2.16.840.1.113883.6.1”
codeSystemName=“LOINC” displayName=“SUMMARIZATION OF EPISODE NOTE”/><title>Good Health Clinic Care Record Summary</title><effectiveTime value=“20050329224411+0500”/><confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/><languageCode code=“en-US”/><recordTarget><patientRole><id extension="12345" root="2.16.840.1.113883.3.933"/><addr><streetAddressLine>17 Daws Rd.</streetAddressLine><city>Blue Bell</city><state>MA</state><postalCode>02368</postalCode><country>USA</country></addr><patient><name><prefix>Mrs.</prefix><given>Ellen</given><family>Ross</family></name><administrativeGenderCode code="F"
codeSystem="2.16.840.1.113883.5.1"/><birthTime value="19600127"/></patient></patientRole></recordTarget><author><templateId root=”1.3.6.1.4.1.19376.1.2.20.1”/><time value=“19990522”/><assignedAuthor><id extension=“11111111” root=“1.3.5.35.1.4436.7”/><assignedPerson><name><prefix>Dr.</prefix><given>Bernard</given><family>Wiseman</family><suffix>Sr.</suffix></name></assignedPerson><representedOrganization><id extension=“aaaaabbbbb”
root=“1.3.5.35.1.4436.7”/>
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

146

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
3625

3630

3635

3640

3645

3650

3655

3660

3665

3670

3675

<name>Dr. Wiseman’s Clinic</name></representedOrganization></assignedAuthor></author><author><templateId root=”1.3.6.1.4.1.19376.1.2.20.2”/><time value=“20050329224411+0500”/><assignedAuthor><id root=“1.3.6.4.1.4.1.2835.2.1234”/><assignedAuthoringDevice><code code=“CAPTURE” displayName=“Image Capture” codeSystem=“
1.2.840.10008.2.16.4” /><manufacturerModelName>SOME SCANNER NAME AND MODEL </manufacturerModelName><softwareName>SCAN SOFTWARE NAME v0.0</softwareName></assignedAuthoringDevice><representedOrganization><id root=“1.3.6.4.1.4.1.2835.2”/><name>SOME Scanning Facility</name><addr><streetAddressLine>21 North Ave</streetAddressLine><city>Burlington</city><state>MA</state><postalCode>01803</postalCode><country>USA</country></addr></representedOrganization></assignedAuthor></author><dataEnterer><templateId root=”1.3.6.1.4.1.19376.1.2.20.3”/><time value=“20050329224411+0500”/><assignedEntity><id extension=“22222222” root=“1.3.6.4.1.4.1.2835.2”/><assignedPerson><name><prefix>Mrs.</prefix><given>Bernice</given><family>Smith</family></name></assignedPerson></assignedEntity></dataEnterer><custodian><assignedCustodian><representedCustodianOrganization><id root=“1.3.6.4.1.4.1.2835.2”/><name>SOME Scanning Facility</name><addr><streetAddressLine>21 North Ave</streetAddressLine><city>Burlington</city><state>MA</state>

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

147

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

3680

3685

3690

3695

3700

3705

3710

3715

3720

<postalCode>01803</postalCode><country>USA</country></addr></representedCustodianOrganization></assignedCustodian></custodian><legalAuthenticator><time value=“19990522”/><signatureCode code=“S”/><assignedEntity><id extension=“11111111” root=“1.3.5.35.1.4436.7”/><assignedPerson><name><prefix>Dr.</prefix><given>Bernard</given><family>Wiseman</family><suffix>Sr.</suffix></name></assignedPerson></assignedEntity></legalAuthenticator><documentationOf><serviceEvent ><effectiveTime><low value=“19800127”/><high value=“19990522”/></effectiveTime></serviceEvent></documentationOf><component><nonXMLBody><text mediaType=“application/pdf” representation=“B64”>
JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0
ZURlY29kZT4+CnN0cmVhbQp4nGWPMWsDMQyFd/8KjfJwqmVbkr0GQqFbg7fQoSRNWuhB
Q/4/1L67TEEYme+9J1s3CMQQRm39NLuXg8H17gK89nN1N8eLAbZ2mmHXuql2QDVUhnZx
a5iBcyQtoMIUM7TZHbH5KZEVDgm//SSUswbFHx/JzBLeu5yYxOIzE8bPcRWqdaGDmcZO
BWc/9bfUNOPfOte44O9jxtcIKskqp0JZouJ5deYqeBn58ZmKtIU+2ptjqWQRJpGyrHDu
K7CXIe2be+/1DzXQP+RlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMjAxCmVuZG9iago0...
SW5mbyAyIDAgUgovSUQgWzxGNENDN0FFQjU0QjM2RkIyODNDNUMzMjQ3OUFEMjgzRj48
RjRDQzdBRUI1NEIzNkZCMjgzQzVDMzI0NzlBRDI4M0Y+XQo+PgpzdGFydHhyZWYKMzAx
MgolJUVPRgo=</text></nonXMLBody></component></ClinicalDocument>

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

148

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

5.4 XDW Workflow Content Module
3725This section defines the XDW Workflow Document by providing a schema and explaining its
use. This document does not include clinical information about the patient directly. It shall only
contain information necessary for organizing and defining work tasks. All clinical information
regarding any task shall be provided through separate documents that are referenced from theassociated input or output documents.
5.4.1 Referenced Standards

3730

HL7 CDA Release 2.0 (denoted HL7 CDA R2, or just CDA, in subsequent text)
Web Services – Human Task (WS-HumanTask) Specification Version 1.1, OASIS
5.4.2 Discussion of Content Standards

3735

3740

3745

The XDW Workflow Document is a document that incorporates elements from the HL7 CDA
document structure and from the WS-HumanTask structure. The Workflow Document exists tocoordinate the activities of multiple people in different organizations. They agree to share these
documents as a method of exchanging work information. These documents are used by theseorganizations to feed what is often considered their own internal task management systems andhave their own administrative rules for managing activities.
Sharing clinical documents is often accomplished as a normal part of providing healthcare. The
XDW workflow allows the work information to be shared in the same way as other patient
related clinical information. Integrating the internal workflow management systems of
independent organizations with independent administrative rules, and perhaps in different legal
and regulatory systems, is avoided.
The XDW Workflow Document does not contain clinical information about the patient. The
input, output, and other elements of the task data shall contain references to documents(DocumentEntry.uniqueId) that contain the clinical information.
XDW Workflow uses the XDS lifecycle management tools to coordinate updates to theWorkflow Document instead of requiring an integration of all the different task management
systems in the different organizations.

3750

The XDW Workflow Document builds upon two other standards, HL7 CDA and OASIS WSHuman Task.
The XDW Workflow Document shall comply with the XDW XML Schema that includes
elements from the CDA and OASIS Human Task standards. Access to the schema files fromthose standards will be needed.

3755

The figure below represents the main level structure of the Workflow Document with the firstlevel of the elements that composed the structure.
It is possible to divide the structured into four parts:

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

149

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________•Part 1: elements derived from HL7 CDA standard (Type of the element: CDA),•

Part 2: two elements, patient and author, defined in the XDWSchema with the structure
derived from HL7 R-MIM standard (Type of the element: tXDWpatient and
tXDWauthor),•

Part 3: elements defined by IHE XDW Profile•

Part 4: the element <TaskList> in which is defined by elements derived from the
OASIS WS-HumanTask standard. In this last section the <TaskList> is a list ofelements <XDWTask> composed of the HumanTask <taskData> (all data that define
the XDWTask) and the HumanTask <taskEventHistory> that contains a list ofelements <taskEvent>.

3760

3765

All the elements of the Figure 5.4.2-1 are described in Section 5.4.3.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

150

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

id

title

elements from
CDA Standard

effectiveTime

confidentialityCode
languageCode

XDWWorkflowDocument

patient

elements fromRIM Standard

authorworkflowInstanceId

workflowDocumentSequenceNumber

elements
defined by
XDW Profile

workflowStatus

workflowStatusHistory

workflowDefinitionReference

TaskList

3770

elements fromOASIS WS-HumanTask

Figure 5.4.2-1: XDW.WorkflowDocument Structure

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

151

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
5.4.2.1 XDW Workflow Document Elements from HL7 CDA Standard

3775

Some elements are incorporated directly from the HL7 CDA standard. This means that theelements, their definitions, and the rules for interpreting them are in the HL7 standard. These aresummarized here for convenience.
<patient> and <author> elements have been defined based upon the HL7 CDA R-MIM.
The XDW schema defines these elements using elements from CDA, and was derived byeliminating all elements that are not needed for workflow identification purposes. The R-MIM
includes elements that are of clinical value. These have been removed for workflow use.

3780

5.4.2.2 XDW Workflow Document Elements defined by IHE XDW Profile
The XDW Workflow Document also has elements that are defined by IHE (see Table 5.4.3-1):•<workflowInstanceId> Every version of the Workflow Document shall have thesame workflowInstanceId value. This value shall be an OID. It is conveyed in theDocumentEntry.referenceIdList attribute of the workflow document’s metadata.. It shallbe globally unique, because it is shared by many organizations.

•<workflowDocumentSequenceNumber> This is used to simplify management of
the changes to the Workflow Document as the workflow is executed. It shall be createdas "1", and be incremented for each update to the Workflow Document.

•<workflowStatus> This shall be either

3785

3790

OPEN– which means that further updates are expected for this Workflow Document.
These updates could be modifications to existing tasks or addition of new tasks or
update to an existing task. Tasks shall not be deleted.
CLOSED– which means that further updates to this Workflow Document are notexpected. A workflow with a CLOSED workflowStatus may continue to be updated,
after which the value of workflowStatus may be transitioned back to OPEN or remain
CLOSED. These constraints will be defined by the Workflow Definition referenced.

3795
•

3800

3805

<workflowStatusHistory> This element represents the history of changes ofstatus of the workflow document. It consists of sub-elements named documentEvent.
Each documentEvent describes a change of status of the workflow document. In case thatthe workflowDefinitionReference describes a type of workflow that can’t change its
status from CLOSED to OPEN, the workflowStatusHistory contain at most two
documentEvent elements, one for the opening of the workflow corresponding to thecreation of the workflow document, and one to track the closing of the process related.
Instead, if the workflowDefinitionReference permits the change of status from CLOSED
to OPEN (e.g., OPEN-->CLOSED-->OPEN…) the element workflowStatusHistory willcontain from 1 to N documentEvent elements to track these changes. A documentEvent is
described by sub-elements defined in Table 5.4.3-5.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

152

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

eventTime
workflowStatusHistory

1…∞

documentEvent

1…1

eventTypetaskEventIdentifier

authorpreviousStatusactualStatus

3810

Figure 5.4.2.2-1: workflowStatusHistory Element

•

3815

<workflowDefinitionReference>. This is the reference to the workflow
definition. This is usually contained in policy or procedure document or may be definedby IHE as a specific workflow definition profile. This profile places no restriction on thestyle used to document such Workflow definition. It is recommended to assign an OID to
those. It shall be recorded by the creator of the initial Workflow Document and shall bepreserved unchanged in all subsequent versions of the document.

5.4.2.3 XDW Workflow Document Elements from the OASIS Human Task
3820

3825

The descriptions of a task and of <taskEvent> are taken from the OASIS Human Task
standard. This standard defines a way to describe a human task. It was defined as an extension to
the BPEL and BPMN workflow standards. These standards are in use to manage the workflow of
automated tasks under the control of an integrated task management system. It was recognizedthat while these standards do not have the ability to control human task, they needed a way todescribe tasks to be performed by humans and other organizations.
The element <XDWTask> groups all information about one task in the workflow, the<XDWTask> is structured in two sub elements: <taskData> and <taskEventHistory>.
•<taskData> describes a single task. This is a list of details about the task, adescription, the inputs to the task (e.g., documents), the outputs from the task (e.g.,documents), fault descriptions and comments. The <taskDetails> include elements
like the task ID, description, state, etc. (see Table 5.4.3-8)•<taskEventHistory> contains a list of the <taskEvent> elements that describe
the changes of the task. For each task, there is one or more <taskEvent> that
describes the history of the task. There is a list of the <taskEvent>: an<eventType>, a description, the inputs to the <taskEvent> (e.g., documents), theoutputs from the <taskEvent> (e.g., documents), fault descriptions, comments, and

3830

3835

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

153

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
attachments (other documents that do not represent outputs). The details include elements
like the task ID, status, etc. (see Table 5.4.3-10)

3840

The definitions and rules such as the state machine that defines status are in the Human Task
standard. There are other datatypes and web services also defined in Human Task standard thatare not used by XDW.

Figure 5.4.2.3-1: XDW Workflow elements derived from OASIS WS-HumanTask

3845

5.4.2.4 Relationship between Task and <taskEvent>
When a Task is generated it has a first <taskEvent>. A Task can either have only one<taskEvent> if the status of the task is not modifiable and it is born just completed or it canhave more status and so more taskEvents. In this case at any time the task changed a new<taskEvent> is created.

3850

3855

3860

3865

When a new Task is generated, zero or more references to external documents, associated with
the Task, either as input or output, are put in the respective element of the Task. As a Task
changes new input or output documents may be added (cumulative list of references). However,for each Task Event, only the input and output document related to the specific task Event shallbe included. The inputs documents of a <taskEvent> are the documents that have been used
as input for performing the Task change. The Output documents are those that have been createdas a result of the Task Change. As a consequence, all input and output document references,
present one or more times in the task Events list shall be listed (without duplicates) in the Task.
Likewise for output document references.
The clinical documents referenced in the input or output data elements of Tasks and task Events
shall be accessible in the affinity domain (if XDW is used along with XDS) or MediaInterchange (if used along with XDM) or Point-to-point submission set (if used along with
XDR). In anticipation of the use of XDW in a cross-community environment, both the document
uniqueId and homeCommunityId are permitted to be included.
The XDW Workflow Document defines a task list which is a series of task descriptions. The
relationship between the task, the order of the elements in this list and the possible status of atask, all this rules are defined in the Workflow Definition Document.
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

154

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________The XDW profiles define the recommended statuses processable in a Task with the<taskEvent>. These statuses are a subset of the HumanTask Standard. There are other task
status values possible, but these are not normally used.
3870
Table 5.4.2.4-1: Description of Task Status
Task status

Description

CREATEDThe workflow is open, the task is created
but not assigned to an owner

READY

The task created is assigned to an owner
and is ready to be performed

IN_PROGRESS

The task is started and the owner isperforming the task actions

FAILED

The task is completed with fault response(it is not possible conclude the action of
the task)

COMPLETEDThe task is completed with response

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

155

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

3875

3880

Figure 5.4.2.4-1: Task Status Transition

The element <XDWTask> and XDW <taskEvent> is constrained by XDW with a minimal
set of elements required. These elements are fully extensible with any kind of attributes definedby Human Task standard. This allows specific Workflow Definition profiles to add elements
defined in Human Task to manage for example intertask relationships, additional status, etc. toaddress more advanced specific workflow requirements.
5.4.3 Content Specification

3885

The tables below represent all Workflow Document elements. The tables show for each element
the Optionality and the standard from which the definition and the structure of the element
derive.
Optionality:
R= element Required for XDW Profile
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

156

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
R2= element Required if known for XDW Profile
O= element Optional for XDW Profile3890

X= element shall not be used
Inside the tables the column description is used to constrain the use of the attribute whenreferring to element defined in the underlining standard. When the description in blank noconstrains is required. When the element is defined by XDW this is the complete description.
There are three functional roles for interacting with these elements.

3895

•

The "create" role specifies what elements shall be created. The Content Creator ispermitted to include any optional element, and may include other elements.

•

The "view" role specifies what elements shall be presented by Content Consumer orContent Updater that support viewing of the document. It may present for viewing anyother element that it understands or has a means of presenting. There are elements thatare required for viewing, while being optional for both creation and viewing.

•

The "update" role specifies what elements shall be maintained with correct values when
updating a document. An "update" operation shall preserve the value of all elements thatare present, even if their meaning is unknown. This means that an updater might not
update the contents of optional elements when updating a workflow document.

3900

3905

If one of the following tables does not specify separate values for the three roles, then thespecified value applies to all three roles.
Tables uses the following namespace conventions:

3910

•

•

cda="urn:hl7-org:v3";•

ht="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/types/200803"•

xs="http://www.w3.org/2001/XMLSchema"•

xdw="urn:ihe:iti:xdw:2011"<XDW.WorkflowDocument>

3915

Table 5.4.3-1: Elements of the Workflow Document
XDW.WorkflowDocument
element

Standard

id

HL7 CDA

cda:IIR

Document ID

title

HL7 CDA

cda:STO

Displayable title

Data
Type

OptionalityDescription

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

157

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
XDW.WorkflowDocument
element

Data
TypeStandard
HL7 CDA

Optionalitycda:TS

effectiveTimeR

confidentialityCode

HL7 CDA

cda:CER

languageCode

HL7 CDA

cda:CSO

HL7 CDA

xdw:tX
DWpatient

HL7 CDA

xdw:tX
DWAuthorpatient

author

IHE

workflowDocumentSequenceN
umber

R

R

Author information
derived from R-MIM.
Restricted to nonclinical necessarycontent.
See Table 5.4.3-3

RIHE

workflowStatusHistory

Conveys theworkflow identifier.
It shall contain thesame value as theCXi.1 component oftheDocumentEntry.referenceIdList metadata
attribute.

xs:intR

R

OPEN ifmodifications are
permitted to the
document contents.
CLOSED if
modifications are notexpected.

R

List of changes of theworkflowStatus
See Table 5.4.3-4R

References (urn:
OID:) to the
documents that define
this kind of workflow.

R

List of all tasks andtheir history
See Table 5.4.3-6

xs:tokenworkflowStatus

Time of most recent
updatePatient information
derived from R-MIM.
Restricted to nonclinical necessarycontent.
See Table 5.4.3-2

OID

workflowInstanceId

Description

IHE

IHE

workflowDefinitionReference

IHE

TaskList

IHE

xdw:workflow
StatusHistory_typexs:anyURI

xdw:TaskList_type

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

158

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________•<patient>
Table 5.4.3-2: Patient Element
Patient element

3920

Data
Type

Standard

Optionalityid

HL7 CDA

cda:IIR

name

HL7 CDA

cda:PNO

administrativeGenderCode

HL7 CDA

cda:CEO

birthTime

HL7 CDA

cda:TSO

martialStatusCode

HL7 CDA

cda:CEO•

Description<author>Table 5.4.3-3: Author Element
Author element

assignedAuthor

•

Data
Type

Standard

HL7 CDA

cda:PO
CD_MT000040.
AssignedAuthor

OptionalityDefinition
EitherassignedAuthoringDe
vice orassignedPerson
should be specifiedR<workflowStatusHistory>

3925
Table 5.4.3-4: workflowStatusHistory Element
TaskListelement

documentEvent

Data
Type

Standard

IHE

xdw:tX
DWdocumentEv
ent_type

OptionalityDescription

R

A detailed eventthat represents achange of theworkflowStatus
The first
documentEventelement is added
when the workflow
document is created.
A documentEvent

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

159

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
TaskListelement

Data
TypeStandard

OptionalityDescription
element is thenadded whenever theworkflowStatus of
the workflow
document changes.
See Table 5.4.3-5•<documentEvent>

3930

Table 5.4.3-5: documentEvent Element
documentEventelement

eventTime

eventTypetaskEventIdentifier

Data
Type

Standard

OASIS_WSHumanTask

OASIS_WSHumanTask

IHE

xs:dateTime

ht:tTaskEventTypexs:anyURI

OptionalityDescription

R

Time when thespecific
documentEventelement is added to
the workflow
document.

R

The type of event that
happens that solicits
the modification of
the workflowStatus. It
should be valorizedwith one of thesetypes: create, stop,suspend, resume, fail,complete.
These types aredefined in the
HumanTask
specification (C. WSHumanTask Data
Types Schema, <!-Defines the humantask event types -->).

R

Element that permits
to track the reference
to the taskEvent thatsolicits themodification of theworkflowStatus. It
stores the same valueof the elementtaskEvent/identifier

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

160

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
documentEventelement

Data
TypeStandard

OptionalityDescriptionof the taskEvent ofreference.

authorpreviousStatusactualStatus•

xs:string

IHE

xs:tokenIHE

xs:token

IHE

R

Actual owner of theworkflow after the
event

R

The previous value ofworkflowStatus.
Either “OPEN” or“CLOSED”. In caseof a Workflow
Document justcreated this element
shall be valorizedwith “”R

Equal to the current
value of theworkflowStatuselement. Either“OPEN” or“CLOSED”.

<TaskList>
Table 5.4.3-6: TaskList Element
TaskListelement

XDWTask

Data
TypeStandard
IHE

xdw:tX
DWTaskOptionalityDescription
List of tasks
See Table 5.4.3-7

R

3935
•

<XDWTask>
Table 5.4.3-7: XDWTask Element
XDWTaskelement

Standard

Data
Type

OptionalitytaskData

OASIS_WSHumanTask

ht:tTaskInstanceData

R

Description of thecurrent task (status,
inputs, outputs, etc.)
See Table 5.4.3-8

taskEventHistory

IHE

xdw:tX
DWevenR

History of thechanges to the current

Description

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

161

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
XDWTaskelement

Data
TypeStandard

OptionalityDescriptiontask (dates, changes,
etc.)
See Table 5.4.3-11

tHistory

3940•<taskData>

The XDW Profile adds the following restrictions to the OASIS definition for taskDetails:•

The taskData/input shall contain a taskData/input/part for every clinical document orworkflow that is to be used as input to the task. This element is of typetMessagePartsData. An element <part> shall have a child element<AttachmentInfo> of type tAttachmentInfo. Table 5.4.3-9 describes how to assign
values to each AttachmentInfo child elements.

•

The taskData/output shall contain a taskData/output/part for every clinical document orworkflow that is created as a result of the task that is to be shared. This element is of typetMessagePartsData. An element <part> shall have a child element<AttachmentInfo> of type tAttachmentInfo. Table 5.4.3-9 describes how to assign
values to each AttachmentInfo child element.

•

Any clinical documents that are registered in an XDS Document Registry shall beidentified in the taskData/input/part, taskData/output/part, or
taskData/attachmentInfos/info as described in Table 5.4.3-9.

3945

3950

3955

The element <part> shall have an attribute @name. The value of this attribute identifies therole played by the referenced object within the task. A Workflow Definition profile shall define alist of acceptable values for this attribute. If no Workflow Definition profile is supported and if
no values are defined by local policies, this value shall be set to “XDSRegisteredDocument”.

3960

Table 5.4.3-8: taskData Element
taskData
element

Standard

Data TypetaskDetails

OASIS_WS
HumanTask

description

input

Optionality

Description

CreateView

Updateht:tTask
DetailsR

R

R

See Table 5.4.3-10

OASIS_WS
HumanTask

xs:strin
g

R

R

R

Textual description

OASIS_WS
HumanTask

ht:tMessageParts
Data

R

This element lists
documents/workflowsreferenced by the task as
inputs, using a child

R

R

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

162

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
taskData
element

Standard

Data Type

Optionality
CreateView

UpdateDescription<part> elements foreach
document/workflow.

outputOASIS_WS
HumanTask

fault

OASIS_WS
HumanTask

comments

OASIS_WS
HumanTask

•

3965

R

R

R

This element lists
documents/workflowsreferenced by the task as
outputs, using a child<part> elements foreach
document/workflow.

ht:tFaul
tData

O

R

O

Description of fault

xs:strin
g

O

R

O

Simple text comments
about the task

ht:tMessageParts
Data<AttachmentInfo>

Each document referenced in input or output elements is structured using a tAttachmentInfo data
type. The XDW Profile extends this data type, adding a new optional child element(homeCommunityId) that can be used to convey the home community Id of the referenced
document. The structure of the <AttachmentInfo> element is described in Table 5.4.3-9.
An <AttachmentInfo> element can be used to refer to another workflow. An<AttachmentInfo> element that stores a reference to a child or parent workflow shallcontain an accessType with the value “urn:ihe:iti:xdw:2013:workflowInstanceId”.

3970
Table 5.4.3-9: AttachmentInfo Element
AttachedInfoele
mentStandard

Data
Type

Optionality
CreateView

Description
Update

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

163

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
AttachedInfoele
mentStandard

Data
Type

Optionality
CreateView

Description
UpdateIf the accessType isurn:ihe:iti:xdw:2011:XDSregistered, the identifier
shall contain the value ofDocumentEntry.uniqueId

identifier

OASIS_WSHumanTask

name

OASIS_WSHumanTask

xs:anyU
RI

R

R

R

xs:stri
ng

R

R

R

If the accessType isurn:ihe:iti:xdw:2013:workf
lowInstanceId, theidentifier shall contain thevalue of theDocumentEntry.referenceIdList in the referenced
workflow.
See Note 1.
Stores the same value ofthe part/@name attribute
If the attachment is adocument, the value ofaccessType shall beurn:ihe:iti:
xdw:2011:XDSregistered.

accessType

OASIS_WSHumanTask

contentType

OASIS_WSHumanTask

contentCategory

OASIS_WSHumanTask

attachedTime

OASIS_WSHumanTask

attachedBy

OASIS_WSHumanTask

xs:stri
ng

R

R

R

If the part element
references anotherworkflow, the value ofaccessType shall beurn:ihe:iti:xdw:2013:workf
lowInstanceId.
See Note 1.

xs:stri
ng

R

R

R

Conveys the MIME type ofthe referenced document. If
the attachment refers to achild/parent workflow thenthis element shall be
empty.

xs:anyU
RI

R

R

R

Fixed value
http://www.iana.org/assign
ments/media-types

xs:date
Time

R

R

R

The date/time when the
document is attached as
reference

ht:tUser

R

RR

The owner that attached
the reference to the task

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

164

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
AttachedInfoele
ment

homeCommunityId

Standard

Data
Type

OID

IHE

Optionality

Description

CreateView

UpdateOOOThe home community Id of
the referenced document

Note 1: The XDW Profile allows for reference to objects other than XDS documents or XDW Workflows. In this case the<identifier> element identifies the uid of the referenced object. The <accessType> of this referenced objects shall be“URL”. No further constraints are defined for other elements.

3975•<taskDetails>
Table 5.4.3-10: taskDetails Element
Optionality
taskDetails
element

Standard

Data
Type

CreateView

UpdateDescription

id

OASIS_WS
HumanTask

xs:any
URI

R

R

R

taskType

OASIS_WS
HumanTask

xs:str
ing

R

R

R

name

OASIS_WS
HumanTask

xs:QName

R

R

R

The name of the task

statusOASIS_WS
HumanTask

ht:tSt
atus

R

R

R

Recommend limiting
values to the statuses
described above.

priority

OASIS_WS
HumanTask

ht:tPriorityO

R

O

taskInitiator

OASIS_WS
HumanTask

ht:tuser

O

O

O

taskStakeholders

OASIS_WS
HumanTask

ht:tOrganizationalEntityOOO

potentialOwners

OASIS_WS
HumanTask

ht:tOrganizationalEntityOOOInternal ID for the task

Owners in Human Task
terminology arepeople/organizations/ etc.
that perform the task.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

165

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Optionality
taskDetails
element

Standard

Data
Type

businessAdministrators

OASIS_WS
HumanTask

actualOwner

OASIS_WS
HumanTask

View

Updateht:tOrganizationalEntityO

OO

ht:tUser

R

R

R

The actual performer of
the task.
Notification Recipient may
be used to contain
information about persons
to be notified. Use of thiselement does not imply
that Human Task
"notification" will be used.
This element may be used
to trigger notification
mechanisms outside of
XDW (e.g., IHE DSUB
Profile). This combined
use is not part of thisprofile specification

ht:tOrganizationalEntitynotificationRecipients

OASIS_WS
HumanTask

createdTime

OASIS_WS
HumanTask

Description

CreateORO

xs:dat
eTime

R

R

O

ht:tUser

RRO

createdBy

OASIS_WS
HumanTask

xs:dateTime

R(Note 1)R

R

lastModifiedTime

OASIS_WS
HumanTask

ht:tUser

O

R

R

lastModifyBy

OASIS_WS
HumanTask

xs:dat
eTime

O

R

O

activationTime

OASIS_WS
HumanTask

xs:dat
eTime

O

R

O

expirationTime

OASIS_WS
HumanTask

xs:boo
lean

O

R

O

isSkipable

OASIS_WS
HumanTask

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

166

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Optionality
taskDetails
element

Standard

Data
Type

hasPotentialOwners

OASIS_WS
HumanTask

CreateView

Updatexs:boo
lean

O

O

O

xs:boo
lean

X

X

X

startedByTimeExists

OASIS_WS
HumanTask

completedByTimeExi
sts

OASIS_WS
HumanTask

xs:boo
lean

X

X

X

OASIS_WS
HumanTask

ht:tPresentationNameOOOOASIS_WS
HumanTask

ht:tPresentationSu
bject

O

O

O

renderingMethodExists

OASIS_WS
HumanTask

xs:boo
lean

R

R

R

xs:boo
lean

X

X

X

hasOutput

OASIS_WS
HumanTask

xs:boo
lean

X

X

X

hasFault

OASIS_WS
HumanTask

xs:boo
lean

X

X

X

hasAttachments

OASIS_WS
HumanTask

xs:boo
lean

X

X

X

hasComments

OASIS_WS
HumanTask

xs:boo
lean

O

R

O

escalated

OASIS_WS
HumanTask

xs:str
ing

X

X

X

searchBy

OASIS_WS
HumanTask

xs:str
ing

X

X

X

outcomeOASIS_WS
HumanTask

presentationName

presentationSubject

Description

Value shall be “false”

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

167

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Optionality
taskDetails
element

Standard

Data
Type

parentTaskId

OASIS_WS
HumanTask

hasSubTasksOASIS_WS
HumanTask

Description

CreateView

Updatexs:any
URI

X

X

X

XDW prohibits use of
subTasks

xs:boo
lean

X

X

X

XDW prohibits use of
subTasks.

Note 1: lastModifiedTime shall be the same as createdTime

3980•<taskEventHistory>
Table 5.4.3-11: taskEventHistory ElementtaskEventHistory
element

Data
TypeStandard
OASIS_WSHumanTask

ht:taskEvent_type

taskEvent•

Optionality

Description

See Table 5.4.3-12
R<taskEvent>

3985
Table 5.4.3-12: taskEvent ElementtaskEventelement

Standard

Data
Type

id

OASIS_WSHumanTask

xs:integer

ReventTimeOASIS_WSHumanTask

xs:dateTime

Ridentifier

OASIS_WSHumanTask

xs:anyURI

R

principal

OASIS_WSHumanTask

xs:string

OOptionality

Description

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

168

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
taskEventelement
eventType

Data
Type

Standard
OASIS_WSHumanTask

Optionality

The type of event that
happens that solicits themodification of the statusof the task (adding a newtaskEvent). It should bevalorized with one of thesetypes: create, stop,suspend, resume, fail,complete.
These types are defined in
the HumanTask
specification (C. WSHumanTask Data Types
Schema, <!-- Defines thehuman task event types ->).

ht:tTaskEventType

RstartOwner

OASIS_WSHumanTask

xs:string

O

endOwner

OASIS_WSHumanTask

xs:string

OstatusOASIS_WSHumanTask

ht:tStatus

R

hasData

OASIS_WSHumanTask

xs:Boolean

O

OASIS_WSHumanTask

xs:anyType

eventData
faultNameR2OASIS_WSHumanTask

xs:string

Description

This structure includes thedata elements that werechanged by this event.

O

5.4.4 Complete Example
3990

In the example in Figure 5.4.4-1 represents the XML of the XDW Workflow Document for theuse case described in ITI TF-1: 30.4.2.1. This example represents the complete Workflow
Document at the end of the process (see column C of ITI TF-1: Figure 30.4.2.1.1-1).
In this case there are two tasks:

3995

•

the first task has been created in status “COMPLETED” and so it has only one taskEventin the taskEventHistory;•

the second task ends the process in status “COMPLETED” and it has two taskEvent.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

169

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

4000

4005

4010

4015

4020

4025

4030

4035

4040

4045

<?xml version="1.0" encoding="UTF-8"?><xdw:XDW.WorkflowDocument xmlns:hl7="urn:hl7-org:v3"
xmlns:ws-ht="http://docs.oasis-open.org/ns/bpel4people/wshumantask/types/200803"
xmlns:xdw="urn:ihe:iti:xdw:2011"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ihe:iti:xdw:2011 XDW-2014-12-23.xsd"><xdw:id root="1.2.3.4.5"/><xdw:effectiveTime value="20110401031520"/><xdw:confidentialityCode code="1.24.3.3.3"/><xdw:patient><xdw:id root="1.3.6.1.4.1.21367.13.20.1000" extension="33333"
assigningAuthorityName="IHERED"/></xdw:patient><xdw:author><xdw:assignedAuthor><hl7:id root="1.2.3.4.5" extension="11111"/><hl7:assignedPerson><hl7:name><hl7:family>Blum</hl7:family><hl7:prefix>Dr.</hl7:prefix></hl7:name></hl7:assignedPerson></xdw:assignedAuthor></xdw:author><xdw:workflowInstanceId>1.2.3.4</xdw:workflowInstanceId><xdw:workflowDocumentSequenceNumber>3</xdw:workflowDocumentSequenceNumber><xdw:workflowStatus>CLOSED</xdw:workflowStatus><xdw:workflowStatusHistory><xdw:documentEvent><xdw:eventTime>2011-03-28T10:00:12.0Z</xdw:eventTime><xdw:eventType>create</xdw:eventType><xdw:taskEventIdentifier>urn:oid:1.2.3.4.5</xdw:taskEventIdentifier><xdw:author>Mr. Rossi</xdw:author><xdw:previousStatus/><xdw:actualStatus>OPEN</xdw:actualStatus></xdw:documentEvent><xdw:documentEvent><xdw:eventTime>2011-04-01T03:15:20.0Z</xdw:eventTime><xdw:eventType>complete</xdw:eventType><xdw:taskEventIdentifier>urn:oid:1.2.3.4.7</xdw:taskEventIdentifier><xdw:author>Dr. Brum</xdw:author><xdw:previousStatus>OPEN</xdw:previousStatus><xdw:actualStatus>CLOSED</xdw:actualStatus></xdw:documentEvent></xdw:workflowStatusHistory><xdw:workflowDefinitionReference>urn:oid:1.2.3.4.5.6.7.8.9</xdw:workflowDefi
HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

170

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________

4050

4055

4060

4065

4070

4075

4080

4085

4090

4095

nitionReference><xdw:TaskList><xdw:XDWTask><xdw:taskData><ws-ht:taskDetails><ws-ht:id>1</ws-ht:id><ws-ht:taskType>Requested</ws-ht:taskType><ws-ht:name>ReferralRequested</ws-ht:name><ws-ht:status>COMPLETED</ws-ht:status><ws-ht:actualOwner>Mr. Rossi</ws-ht:actualOwner><ws-ht:createdTime>2011-03-28T10:00:12.0Z</wsht:createdTime><ws-ht:createdBy>Mr. Rossi</ws-ht:createdBy><ws-ht:lastModifiedTime>2011-03-28T10:00:12.0Z</wsht:lastModifiedTime><ws-ht:renderingMethodExists>false</wsht:renderingMethodExists></ws-ht:taskDetails><ws-ht:description>Request for a specialist visit</wsht:description><ws-ht:input/><ws-ht:output/></xdw:taskData><xdw:taskEventHistory><xdw:taskEvent><xdw:id>101</xdw:id><xdw:eventTime>2011-03-28T10:00:12.0Z</xdw:eventTime><xdw:identifier>urn:oid:1.2.3.4.5</xdw:identifier><xdw:eventType>create</xdw:eventType><xdw:status>COMPLETED</xdw:status></xdw:taskEvent></xdw:taskEventHistory></xdw:XDWTask><xdw:XDWTask><xdw:taskData><ws-ht:taskDetails><ws-ht:id>2</ws-ht:id><ws-ht:taskType>Referral Referred</ws-ht:taskType><ws-ht:name>Referred</ws-ht:name><ws-ht:status>COMPLETED</ws-ht:status><ws-ht:actualOwner>Dr. Brum</ws-ht:actualOwner><ws-ht:createdTime>2011-03-29T09:20:01.0Z</wsht:createdTime><ws-ht:createdBy>Dr. Brum</ws-ht:createdBy><ws-ht:lastModifiedTime>2011-04-01T03:15:20.0Z</wsht:lastModifiedTime><ws-ht:renderingMethodExists>false</wsht:renderingMethodExists></ws-ht:taskDetails><ws-ht:description>Specialist visit</ws-ht:description><ws-ht:input>

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

171

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________<!-- one part element for each document in input --><ws-ht:part name="eReferralDoc1"><ws-ht:attachmentInfo><ws-ht:identifier>1.2.3.4.56.7.78</ws-4100
ht:identifier>

4105

4110

4115

4120

4125

4130

4135

4140

4145

<ws-ht:name>eReferralDoc1</ws-ht:name><ws-ht:accessType>urn:ihe:iti:
xdw:2011:XDSregistered</ws-ht:accessType><ws-ht:contentType>application/pdf</wsht:contentType><wsht:contentCategory>http://www.iana.org/assignments/media-types</wsht:contentCategory><ws-ht:attachedTime>2011-0401T03:15:20.0Z</ws-ht:attachedTime><ws-ht:attachedBy>Dr. Brum</wsht:attachedBy><xdw:homeCommunityId>urn:oid:1.2.3.4.5</xdw:homeCommunityId></ws-ht:attachmentInfo><!--eReferralDoc1--></ws-ht:part></ws-ht:input><ws-ht:output><!-- one documentReference element for each document in
input -->
<ws-ht:part name="ChildWorkflow"><ws-ht:attachmentInfo><ws-ht:identifier>1.2.3.4.12312.34</wsht:identifier><ws-ht:name>ChildWorkflow</ws-ht:name><wsht:accessType>urn:ihe:iti:xdw:2013:workflowInstanceId</ws-ht:accessType><ws-ht:contentType>application/xml</wsht:contentType><wsht:contentCategory>http://www.iana.org/assignments/media-types</wsht:contentCategory><ws-ht:attachedTime>2011-04-01T03:15:20.0Z</wsht:attachedTime><ws-ht:attachedBy>Dr. Brum</ws-ht:attachedBy></ws-ht:attachmentInfo></ws-ht:part></ws-ht:output></xdw:taskData><xdw:taskEventHistory><xdw:taskEvent><xdw:id>201</xdw:id><xdw:eventTime>2011-03-29T09:20:01.0Z</xdw:eventTime><xdw:identifier>urn:oid:1.2.3.4.6</xdw:identifier><xdw:eventType>create</xdw:eventType>

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

172

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
4150

4155

4160

<xdw:status>IN_PROGRESS</xdw:status></xdw:taskEvent><xdw:taskEvent><xdw:id>202</xdw:id><xdw:eventTime>2011-04-01T03:15:20.0Z</xdw:eventTime><xdw:identifier>urn:oid:1.2.3.4.7</xdw:identifier><xdw:eventType>complete</xdw:eventType><xdw:status>COMPLETED</xdw:status></xdw:taskEvent></xdw:taskEventHistory></xdw:XDWTask></xdw:TaskList></xdw:XDW.WorkflowDocument>

Figure 5.4.4-1: Sample XDW Workflow Document4165

5.4.5 Workflow Document Management
5.4.5.1 Workflow Document Lifecycle Management
The Cross-Enterprise Document Workflow Profile takes advantage of the lifecycle managementof XDS when used in an XDS environment.

4170

4175

A Workflow Document shall be created and be assigned a workflow identifier. The initial
document shall include at least one task on the TaskList, and have a workflowStatus of OPEN.
The Workflow Document is updated when:•

The information about a task is modified. This may be due to a change in some other task
related information like updating the output information.

•

A new task is added to the <TaskList>.

•

The workflow status is changed to CLOSED.

Each update shall be done using the XDS Document Replace when in an XDS environment. The
series of steps to be taken is:•

Update the XDW document to reflect the desired changes. This is often replacement of
the <TaskData>. It may also be a change by adding a new task to the <TaskList> ora new <taskEvent> to a Task.

•

Use the XDS Replace operation to replace the old document with this modified
document. This replacement document shall carry the same workflow identifier as theoriginal Workflow Document.

•

It is possible that a document replace will be rejected by the XDS Document Registry if
another actor has also done a replace in the time since the Workflow Document instancewas obtained. In this case (attempting to replace a document already replaced), the XDW

4180

4185

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

173

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Document Creator or Updater shall obtain the most recent version of the Workflow
Document which was updated by another XDW Actor, consider the evolution of theworkflow, and performed a new content update. This kind of race condition should bevery rare because updating is much faster than the rate at which people perform tasks. If
certain workflows definitions require reducing the likelihood of such race conditions, one
should consider placing in the Workflow Description one or more tasks "In Progress" andrequiring that other Actor wait while such tasks are in-progress.

4190

When using XDR or XDM, the receiving actor shall perform an equivalent local update process.
4195

4200

When an XDW Actor decides that a workflow status code shall be placed in a CLOSED status, afinal update to set the workflow status code to CLOSED shall be performed. The specific rules
for determining when and which XDW Actors are allowed or should set the workflow status
code to CLOSED are not specified by the XDW Profile. They may be determined within the
Workflow Definition. XDW Content Consumer and Content Updater Actors shall support themeans to query for Workflow Documents that are in a workflow status OPEN.
This profile does not further constrain the rules for document lifecycle management, but a
specific Workflow Definition may add requirements requiring that certain kinds of tasks becreated initially, restricting the kinds of tasks that can be added, and requiring that updates be
performed for specific task changes.

4205

5.4.5.2 Associations Types
A clinical document can be referenced by many Workflow Documents in different steps and for
different reasons. When the content of a Workflow Document is known, the related clinicaldocuments are always reached through the references (DocumentEntry.uniqueId andhomeCommunityId) tracked inside the different task in the “input" and “output” elements.

4210

The use of a workflow identifier is necessary to have a fixed id to identify the whole workflow.
Since the Workflow Document will be replaced many times (it is replaced at each step), itsDocumentEntry.uniqueId metadata attribute is not useful for maintaining a fixed reference. The
document uniqueId of each of the successive XDW documents can be used to identify aparticular state of the workflow.

4215

XDW uses a workflow identifier stored in the DocumentEntry.referenceIdList metadata attributeof each workflow document to group all versions of the workflow document.

4220

•

The Content Creator shall create a workflow identifier, as an OID, when a new workflow
is created.

•

The Content Creator shall create a single value in DocumentEntry.referenceIdList
containing the workflow identifier. Only the CXi.1 and CXi.5 component shall bepresent.
An example workflow identifier in DocumentEntry.referenceIdList is:
2.16.840.1^^^^urn:ihe:iti:xdw:2013:workflowInstanceId

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

174

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________•
4225

The Content Updater shall use the same value for the workflow identifier when it createsa new version of the Workflow Document.

Since every version of the Workflow Document replaces the previous, there is always one andonly one approved document with a given workflow identifier.

4230

If a workflow generates another workflow there shall be two different workflow identifiers, one
for each workflow. The relationship between the different workflows is always guaranteed to beinside the Workflow Documents using the DocumentEntry.referenceIdList as output of the taskof the parent Workflow Document and as the input of the first task in the child Workflow
Document.
5.4.5.3 Create workflow
When the first step of a new workflow is completed, the XDW Content Creator shall:

4235

•

create the first version of the Workflow Document.

Then the XDW Content Creator shall use ITI-41 Provide and Register Document Set-b (in thecase of XDS):•
4240

submit the Workflow Document to the XDS Document Repository, using a newworkflow identifier in the document’s DocumentEntry.referencedIdList metadata
attribute, using ITI-41 Provide and Register Document Set-b.

5.4.5.4 Update Workflow Document
For each subsequent step in the Workflow an XDW Content Updater shall:•obtain the most recent version of the Workflow Document, the only version approved
with the specific workflow identifier in the DocumentEntry.referenceIdList (e.g., using agrouped XDS Document Consumer)•

update the content in the Workflow Document (by adding a new task or updating an
existing task with a new <taskEvent>);•

re-register (update) the Workflow Document by performing a document replace (e.g., in a
XDS environment using a grouped XDS Document Source).

4245

4250

This new version of the workflow document has the same workflow identifier as the previous
version.
In a Document Sharing infrastructure (e.g., an XDS environment) two different Content
Updaters could be in the situation of race condition when both update, in the same time, the same
Workflow Document.

4255

In this case two actors (Content Updater A and Content Updater B) retrieve the same Workflow
Document (e.g., Workflow Document with document uniqueId 1) and change it.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

175

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Content Updater A publishes a new version updated with a new document uniqueId (e.g.,document uniqueId 2) and the previous version (with document uniqueId 1) is deprecated..
4260

When Updater Creator B tries to replace the same Workflow Document (document uniqueId 1)
with his updated version this transaction generates an error because the document uniqueId 1 isdeprecated and replaced with document uniqueId 2.
Content Updater B shall retrieve the current version of the Workflow Document (document
uniqueId 2) and update it with a new version of the document with document uniqueId 3.
5.4.5.5 Association of a clinical document to a task and <taskEvent>4265

Any clinical documents included as input or output documents within the taskData element thatare registered in an XDS Document Registry shall be referenced using uniqueId andhomeCommunityId of the Clinical Document referenced.
5.4.5.6 Get the Workflow Document and a clinical document associated to theworkflow

4270

The most recent version of the Workflow Document may be retrieved at any point during theworkflow.
The version of the Workflow Document with an approved status contains the most current
information on the workflow and its tasks. So an XDW Content Consumer needs to analyze only
the approved version to get all current information.

4275

Any Workflow Document contains details of each task that has been performed. A task or<taskEvent> includes the references (DocumentEntry.uniqueId and homeCommunityId) tozero or more input and/or output clinical documents. These documents may be obtained bymeans of XDS, or should be included along with the Workflow Document if XDR or XDM is
used.

4280

5.4.5.7 Use of the eventCodeList to manage the status of a Workflow Document
An overall workflow status is required to be set by each author of a new step. This value is either
OPEN or CLOSED.
This workflow status is required to be present in every workflow step, and shall take either thevalue OPEN or CLOSED.

4285

By setting this workflow status to OPEN, a step author indicates that, for the workflow definition
and the step author further steps are expected to be performed.
By setting this workflow status to CLOSED, a step author indicates that, for the workflow
definition and the step author no further steps are expected to be performed.
This workflow status shall be present for all XDW documents in its eventCodeList metadata.

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

176

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
4290

This use of workflow status enables the use of query to locate OPEN or CLOSED workflows
with certain other properties.
The EventCodeList contains the workflow status with two possible code values: either OPEN or
CLOSED.
5.4.5.8 Parameters for Required Queries

4295

The section below documents some examples of the possible queries in an XDS environment(defined in the Registry Stored Query transaction [ITI-18]) to obtain the different documents
related to the workflow from some parameters available:•

Find all open Workflow Documents for a patient
A Registry Stored Query “FindDocuments” maybe used with patientId, XDW document
formatCode and eventCodeList with the value “urn:ihe:iti:xdw:2011:eventCode:open”
for the Workflow Document.

4300•

Find all particular type of open Workflow Documents for a patient
A Registry Stored Query “FindDocuments” may be used with patientId, XDW document
formatCode, eventCodeList with the value “urn:ihe:iti:xdw:2011:eventCode:open” forthe Workflow Document and a specific XDW document typeCode.

4305•

Get one or more documents referenced in a Workflow Document
A Registry Stored Query “FindDocuments” which retrieves the Workflow Document(like in the first example) and a Registry Stored Query “GetDocuments” with document
uniqueId and homeCommunityId to retrieve one or more documents referenced inside theWorkflow Document.

4310•

Find the latest version of a Workflow Document for a given workflow identifier
A Registry Stored Query “FindDocumentsByReferenceId” may be used with patientId
and the workflow identifier.

5.4.6 XDS Metadata4315

5.4.6.1 Document Metadata
The following metadata elements shall be used to describe the Workflow Document in an XDS
Affinity Domain. The XDW Profile does not introduce new metadata and all the metadata
elements used are the common Document Sharing specified in Section 4.2.3.2.

4320

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

177

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Table 5.4.6.1-1: XDW Constraints for Document Metadata Attributes
DocumentEntry Attribute

XDW Constraints

authorRepresents the humans and/or machines that authored the
document.
In the Workflow Document the Author is the human and/or
machine which most recently updated the Workflow Document.
This means that when a Workflow Document is updated by adifferent person or machine, the author changes.

authorInstitution (sub-attribute of author)

No special requirements for Workflow Document

authorPerson (sub-attribute of author)

No special requirements for Workflow Document

authorRole (sub-attribute of author)

No special requirements for Workflow Document

authorSpecialty (sub-attribute of author)

No special requirements for Workflow Document

availabilityStatus

No special requirements for Workflow DocumentclassCodeThis code is specified by the XDS Affinity Domain. The XDS
Affinity Domain should specify a code for non-clinical
Workflow Management documents.

comments

No special requirements for Workflow Document

confidentialityCode

No special requirements for Workflow Document

creationTime

No special requirements for Workflow Document

entryUUID

No special requirements for Workflow Document

eventCodeList

For a Workflow Document, one code of this list shall be used todefine the overall status of the workflow. This code shall haveone of the following two values:••

code: urn:ihe:iti:xdw:2011:eventCode:open
codingScheme: 1.3.6.1.4.1.19376.1.2.3
code: urn:ihe:iti:xdw:2011:eventCode:closed
codingScheme: 1.3.6.1.4.1.19376.1.2.3(See Section 5.4.5.7.)
formatCode

Each XDW Workflow Document shall have the following value
for the formatCode attribute:
code: urn:ihe:iti:xdw:2011:workflowDoc
codingScheme: 1.3.6.1.4.1.19376.1.2.3

hash

No special requirements for Workflow Document

healthcareFacility
TypeCode

No special requirements for Workflow Document

homeCommunityId

No special requirements for Workflow Document

languageCode

No special requirements for Workflow Document

legalAuthenticator

No special requirements for Workflow Document

mimeType

No special requirements for Workflow Document

patientId

No special requirements for Workflow Document

practiceSettingCodeNo special requirements for Workflow Document

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

178

Copyright © 2015 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
DocumentEntry Attribute

XDW Constraints

referenceIdList

Contains the workflow identifier.
Only a single value shall be sent in this list.
Only the CXi.1 and CXi.5 components shall be used:
CXi.1 shall contain same value as
XDW.WorkflowDocument.workflowInstanceId
CXi.5 shall contain
urn:ihe:iti:xdw:2013:workflowInstanceId.

repositoryUniqueId

No special requirements for Workflow Document

serviceStartTime

Shall be the starting time the service being documented tookplace
For the Workflow Document the serviceStartTime is the time atwhich work began on the earliest task for this workflow.
If present, shall have a single value.

serviceStopTime

No special requirements for Workflow Document

size

No special requirements for Workflow Document

sourcePatientId

No special requirements for Workflow Document

sourcePatientInfo

No special requirements for Workflow Document

title

No special requirements for Workflow Document

typeCode

For Workflow Documents defined by an IHE profile, the profile
specifies the value of typeCode used. For other Workflow
Documents defined in the XDS Affinity Domain, the XDS
Affinity Domain specifies the value for typeCode.

uniqueId

No special requirements for Workflow Document

URI

No special requirements for Workflow Document

5.4.6.2 XDS SubmissionSet Metadata4325

No additional constraints. See Section 4.2.3.3.
5.4.6.3 XDS Folder Metadata
No additional constraints

HL7, HEALTH LEVEL SEVEN and CDA are the registered trademarks of Health Level Seven International.

___________________________________________________________________________
Rev. 12.1 Final Text – 2015-09-30

179

Copyright © 2015 IHE International, Inc.