Integrating the Healthcare Enterprise5

IT Infrastructure
Technical Framework

10

Volume 3(ITI TF-3)
Cross-Transaction Specifications
andContent Specifications

15

Revision 9.0 – Final Text
August 31, 201220

Copyright © 2012 IHE International, Inc.

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

4.1 XDS METADATA ............................................................................................................................................. 3
4.1.1
Class Diagram ....................................................................................................................................... 4
4.1.2
Document Specification ......................................................................................................................... 4
4.1.3
XDS Submission Request Specification ................................................................................................. 4
4.1.4
Submission Set Specifications ................................................................................................................ 6
4.1.5
Folder Specification .............................................................................................................................. 9
4.1.6
Document Relationships and Associations ............................................................................................ 9
4.1.7
Document Definition Metadata ........................................................................................................... 13
4.1.8
Submission Set Metadata ..................................................................................................................... 32
4.1.9
Folder Metadata .................................................................................................................................. 40
4.1.10Registry Adaptor Enforcement of Attributes ................................................................................... 44
4.1.11XDS Registry Adaptor ..................................................................................................................... 47
4.1.12
General Metadata Issues ................................................................................................................ 50
4.1.13
Error Reporting .............................................................................................................................. 53
4.1.14Extra Metadata Elements ................................................................................................................ 58
4.2 CHARACTER STRING COMPARISONS .............................................................................................................. 59
4.3 XDS METADATA VOCABULARY .................................................................................................................... 59
4.3.1
Metadata UUIDs ................................................................................................................................. 59

25

30

35

40
5

45

50

CROSS-TRANSACTION SPECIFICATIONS .................................................................................................. 3

IHE CONTENT SPECIFICATIONS ............................................................................................................. 61
5.1 BASIC PATIENT PRIVACY CONSENTS MODULE .............................................................................................. 61
5.1.1 References ................................................................................................................................................. 61
5.1.2 Patient Privacy Consent Acknowledgment Document Specification 1.3.6.1.4.1.19376.1.5.3.1.1.7 – Withno Scanned Document Part................................................................................................................................ 61
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............................................................................................................................................. 65
5.2 SCANNED DOCUMENTS CONTENT MODULE ................................................................................................... 65
5.2.1 Referenced Standards ............................................................................................................................... 66
5.2.2 XDS Metadata ........................................................................................................................................... 67
5.2.3 Specification.............................................................................................................................................. 69
5.2.4 Complete Example (Wrapped PDF) ......................................................................................................... 79___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

2

Copyright © 2012 IHE International, Inc.

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

4
4.1

60

65

70

Cross-Transaction Specifications
XDS Metadata

The following sections specify the mapping of XDS concepts to ebRS and ebRIM semantics:• XDS Document• XDS Submission Request• XDS Submission Set• XDS Folder• Document Relationships
The next sections specify the metadata definitions to support the above concepts. The following
are discussed:• XDS Document• XDS Submission Request• XDS Submission Set• XDS Folder
The remaining two sections discuss the following topics:• XDS Registry Adaptor function• General Metadata issues
Transactions that Reference this Section 4.1
Registry Stored Query

ITI-18

Register Document Set – b

ITI-42

Provide and Register Document Set – b

ITI-41Retrieve Document Set

ITI-43

Transactions that reference specificsubsections of this Section 4.1
Distribute Document Set on Media

ITI-32(4.1.1, 4.1.7, 4.1.8, 4.1.12)___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

3

Copyright © 2012 IHE International, Inc.

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

4.1.1 Class Diagram
ExtrinsicObject

XDSDocumentEntry

ebXML ebRIM
Classes

RegistryPackage«type»XDSFolder«type»XDSSubmissionSet

XDSClassesFigure 4.1-1: ebXML Class Diagram of the Register Document Metadata

80

The XDSDocumentEntry class is derived from the ebXML ExtrinsicObject class. The
XDSSubmissionSet and XDSFolder classes are derived from the ebXML 1 RegistryPackageclass. Since the ebXML Registry standard does not allow for subclassing the RegistryPackageclass, these two classes are implemented as ebXML RegistryPackages. Type information(submission set vs. folder) is coded as an ebXML Classification against two object types createdby the XDS profile, XDSSubmissionSet and XDSFolder.
4.1.2 Document Specification

85

A new registry object type is declared as a subclass of ebXML ExtrinsicObject. Its name is
XDSDocumentEntry. An object of this type in the XDS registry is used to represent a document
in an XDS repository.
An XDSDocumentEntry object in the registry contains a reference to a single document in asingle repository.

90

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.
4.1.3 XDS Submission Request Specification
95

A Submission Request is the collection of information that is transferred to an XDS Document
Registry or Repository.
There are two types of submission requests: XDS Registry Submission Request and XDS
Repository Submission Request. Both are described below.

100

Appropriate protocol bindings are used to transfer this content between systems when the actors
are not implemented together on the same system. The bindings are described in “Protocol
Selection” section of the appropriate transaction.
1

ebXML Registry terms such as RegistryPackage are shown with an ebXML prefix to help distinguish
ebXML Registry terms from XDS terms. Unless otherwise indicated, references to ‘ebXML’ in XDS refer to the
ebXML Registry specifications as opposed to other ebXML specifications. The short term is used for readability.

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

4

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________The two types of XDS Submission Requests are described next.
4.1.3.1

105

110

XDS Registry Submission Request

An XDS Registry Submission Request is the collection of metadata transferred between a
Document Repository and a Document Registry in a single ebXML SubmitObjectsRequest. This
request contains:
A collection of metadata to be stored in the registry including:• Metadata for new documents• Folders to be created• Documents to be added to folders
A single XDS Submission Set object, contained within the metadata, organizing the metadataThis request is part of the Register Document Set-b [ITI-42] transaction.
4.1.3.2

115

120

An XDS Repository Submission Request is the collection of metadata and documents transferred
between a Document Source and a Document Repository using a single ebXML
SubmitObjectsRequest. This request contains:• Metadata• Zero or more documents; each document is represented by an XDSDocumentEntry object inthe metadata. Submissions that add metadata to the registry without adding documents to therepository are possible.
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.1.3.3

125

XDS Repository Submission Request

Atomicity Requirements for XDS Submission Requests

XDS Submission requests shall be atomic operations. The result of a Submission Request is to
update either:• a Registry or• a Registry and a Repository.
All changes requested are successfully applied or no net changes are made. More specifically:130

1. Atomicity shall be managed by an XDS registry adaptor (see ITI TF-3: 4.1.11 for details on
registry adaptor addressing the fact that the ebXML Registry specification does not guaranteethat a SubmitObjectsRequest is atomic). XDS specifies the mechanism through which atomicity
is to be implemented and where it is needed.
2. All objects shall have their Status attribute set to Submitted when the objects are first createdin the ebXML registry. An ebXML ApproveObjectsRequest, shall be issued within the XDS
Registry Adaptor to change the Status attribute to Approved. This completes the transaction.
___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

5

Copyright © 2012 IHE International, Inc.

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

3. The following types of objects shall have their status set to Approved to be consideredpublicly available:• XDSSubmissionSet (ebXML RegistryPackage)• XDSFolder (ebXML RegistryPackage)• XDSDocumentEntry (subclass of ebXML ExtrinsicObject)

140

If an error occurs storing documents in the repository then all documents stored as part of theRepository Submission Request shall be removed.

145

150

If an error occurs storing metadata in the registry, then the following actions are performed:• All metadata stored as part of the Registry Submission Request shall be removed from theregistry• 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 Query transaction shall not find XDS Submission Sets, XDS
Folders or XDSDocumentEntry objects until after the above atomic operation that creates themhas completed successfully and the status attributes have been set to Approved.
4.1.3.4

155

160

165

Other Properties of Submission Requests

A Submission Request may contain metadata beyond the XDS Submission Set, XDS Folder, andXDSDocumentEntry objects. These are:• ebXML Associations linking XDSDocumentEntry objects to XDSFolder objects. There are
no restrictions on whether the XDSDocumentEntry objects or XDSFolder objects are in thisSubmission Request. Such an Association is the ebXML mechanism for including objects inan ebXML RegistryPackage (the basis of XDSFolder). Each of these Associations shall beaccompanied by another association that links it with the XDSSubmissionSet object. Thisadditional association allows for the identification of the Document Source actor which
linked a particular document with a particular folder. See ITI TF-3: 4.1.5 for more
information.
• Associations linking existing (already contained in the registry) XDSDocumentEntry objects
to the XDSSubmissionSet RegistryPackage contained in this Submission Request. This
option is discussed in the next section.
4.1.3.5

Attribute Value Length

All attribute values shall conform to the size specification of ebRIM version 3.0 that is detailed
in section 2.2 of that specification - Data Types. More specifically, all Slots shall conform to thespecification of ebRIM version 3.0, which is detailed in section 2.8.1 of that specification.
4.1.4 Submission Set Specifications
170

Submission Sets exist for two reasons:___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

6

Copyright © 2012 IHE International, Inc.

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

To support atomic submission to the registry2.

To make a permanent record in the registry ofa) The existence and status of the submissionb) The XDS Folders and XDSDocumentEntry objects included in the submission.

175

Submission Sets, once shared, are immutable.
An XDS SubmissionSet is an ebXML RegistryPackage, classified as XDSSubmissionSet that isused to bundle XDSDocumentEntry, XDSFolder and Association objects for submission.
A Submission Set has a set of attributes that are described in ITI TF-3: 4.1.8 Submission Set
Metadata.

180

4.1.4.1

Inclusion of Documents in a SubmissionSet

Documents may be included in a Submission Set in two ways: inclusion by value and inclusion
by reference.
Inclusion by value: A new document is being submitted to the registry. The Submission Set
contains the XDSDocumentEntry object with associated attributes.
185

190

Inclusion by reference: Existing documents in the registry can be referenced by a Submission
Set. These documents are included because of their clinical relevance to the rest of theSubmission Set.
Linking document metadata to submission set: An XDSSubmissionSet shall be represented byan ebXML RegistryPackage. Document metadata (XDSDocumentEntry objects) shall be linked
to the RegistryPackage via ebXML Associations according to the ebXML Registry standard.
For documents included by reference, the Submission Request shall include the Association
object used to link the document. For documents included by value, the Submission Request
shall include the XDSDocumentEntry object and the Association object used to link the
document.

195

200

Submission Set Association labeling: Two types of association labels are defined: original(submission by value), or reference (Submission by reference). This allows finding thesubmission set that first submitted any document. It also supports proper rollback in case of a
submission error. For document metadata included by value, a rollback of the submission shalldelete the document metadata and the association. For document metadata included by reference,a rollback of the submission shall not delete the document metadata but shall still delete theassociation. (The document whose association is being deleted existed before this submission
and shall be maintained.) The following labeling of the Associations is required.
Table 4.1-1: Submission Set Association Labeling
Inclusion type
By ValueRollback
Yes

Association Labeling
Slot: Name=SubmissionSetStatus
Value=Original

By ReferenceNo

Slot: Name=SubmissionSetStatus___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

7

Copyright © 2012 IHE International, Inc.

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

Association Labeling
Value=Reference

205

Submission Sets and patients: A Submission Set is restricted in terms of mixing documentsfrom different patients. All documents included by value in a Submission Set shall have theirpatientId attribute set to the same value. This restriction does not apply to documents included byreference.
Document metadata duplication: There are several conditions regarding the duplication of
document metadata that can occur.

210

Duplicate registration of a document - A document and its metadata are submitted to therepository as part of a Repository Submission Request. This document already exists in one
or more repositories and is already represented in the registry. It is submitted with a new (notpreviously used) UUID for the XDSDocumentEntry and associated ancillary objects. The
registry shall accept such duplicate registration of the documents.

215

Duplicate document id submitted to repository - A document with its associated metadata is partof a Repository Submission Request. A document with the same
XDSDocumentEntry.uniqueID is present in the repository but the XDSDocumentEntry.hashis different. This is an error and the Submission Request shall be rejected by the repository.

220

225

230

Note: There are two approaches to detecting this fault. First, this can be detected at the repository if repository logic canvalidate the hashes and has record of the document id to compare. Otherwise the request can be forwarded on to theregistry and let the fault be detected by the registry (see next bullet). The repository then deals with the error returnedby the registry.

Duplicate document ID submitted to registry - Metadata representing a document(XDSDocumentEntry) is part of a Registry Submission Request. An XDSDocumentEntry
object with the same uniqueID is present in the registry but, the hash is different. This is anerror and the Submission Request shall be rejected by the XDS registry adaptor.
A document, once generated outside of the XDS environment, can be registered by multiple
Document Sources with the same uniqueId, same hash, different UUID, and with othermetadata 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 XDSDocumentEntry objects with that same uniqueId.
4.1.4.2

235

Inclusion of Folders in a SubmissionSet

Linking folder metadata to submission set: An XDSSubmissionSet shall be represented by an
ebXML RegistryPackage. Folder metadata (XDSFolder objects) shall be linked to theRegistryPackage via ebXML Associations according to the ebXML Registry standard.
Linking associations to a submission set: A document can be linked to a folder to indicate that
this document is a member of a particular folder. This link shall be represented via an ebXML
Association according to the ebXML Registry standard. Each of these Associations shall beaccompanied by another ‘HasMember’ Association that links it with the XDSSubmissionSet___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

8

Copyright © 2012 IHE International, Inc.

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

object. This additional association allows for the identification of the Document Source actor
which linked a particular document with a particular folder and shall be as follows:• The targetObject shall contain the id of the Association that links the document and thefolder.
• The sourceObject shall contain the id of the XDSSubmissionSet object.

245

It is not necessary that the XDSSubmissionSet object which links to this Association also containthe XDSDocumentEntry metadata or the XDSFolder metadata that correspond to the referenced
document and folder. This allows for documents to be placed in folders at a later date and time.
If the XDSSubmissionSet object does contain the corresponding XDSDocumentEntry or
XDSFolder, then these should be linked to the XDSSubmissionSet object as previously
described.

250

4.1.5 Folder Specification

255

An XDS Folder is an ebXML RegistryPackage classified as XDSFolder. This folder is used tobundle XDSDocumentEntry objects. Folders shall not be nested inside other folders. The
patientId attribute of the XDSDocumentEntry objects it contains shall match the patientId
attribute on the folder itself. This shall be enforced by the Registry Actor.
Note: The nesting of folders may be considered as a future extension to this transaction.

260

265

Linking documents to a folder: A document can be linked to a folder to indicate that thisdocument is a member of a particular folder. This link shall be represented via an ebXML
Association according to the ebXML Registry standard. This association shall have an id
attribute which shall be a UUID. Each of these Associations shall be accompanied by anotherassociation that links it with the XDSSubmissionSet object. This additional association allows
for the identification of the Document Source actor which linked a particular document with aparticular folder. See ITI TF-3: 4.1.4.2 for more information regarding this accompanying
Association object.
4.1.6 Document Relationships and Associations
4.1.6.1

270

Document Relationships from HL7

Relationships between documents can be established with XDS. XDS adopts the document
relationship semantics defined in HL7 CDA. The supported relationships are listed below inTable 4.1-2. The semantics behind each of these relationships are documented in HL7 CDA
Release 2, Committee Ballot 2.
To create a document relationship in the registry, submit:• A new document (XDSDocumentEntry)• An Association linking the new document to an existing document.

275

The association type defines the document relationship. The new document and the associationmust be submitted in the same Submission Set. The existing document must be an Approved___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

9

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
object already in the registry. The identity (registry UUID) of the existing document must be
known because the Document Source pre-assigned the UUID prior to submission or discovered
it via registry query.
280

The association types used for document relationships are defined by XDS and an XDS Registrymust be initialized with their definitions. See ITI TF-2x: Appendix H for details.

285

Note to implementers: A Document Source pre-assigning UUIDs and using the saved UUIDs in future transactions can run into
consistency problems if a second Document Source submits to the Registry causing the document to be
deprecated. Once a document is deprecated, new Associations to that document cannot be accepted by theRegistry.

Table 4.1-2: Document Relationships
Relationship

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.

Adapted from HL7 CDA Release 2, Committee Ballot 2

290

A Document Relationship refers to any of the relationships listed in Table 4.1-2 Document
Relationships above.
A Document Source actor creates a document relationship by submitting a Submission Set
containing:
XDSDocumentEntry – this defines the new document being submitted
The uniqueId attribute must be unique.

295

The UUID must be unique or symbolic (the registry assigns)
Association – this links the original XDSDocumentEntry (already in the registry) with the
new XDSDocumentEntry being submitted.
The targetObject attribute of the Association object references the existing document in
the registry.

300

The sourceObject attribute of the Association object references the XDSDocumentEntry
contained in the Submission Set.
The Association Type is one of the relationships in Table 4.1-2.
The targetObject attribute of the Association is the registry UUID representing the existing
document in the registry. This UUID must be discovered via registry query.

305

The existing document shall be deprecated by the following rules (based on CDA R2):___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

10

Copyright © 2012 IHE International, Inc.

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

The APND and XFRM relationships leave the original document with its status unchanged(Approved).
The RPLC and XFRM_RPLC relationships change the status of the original document toDeprecated. All transformations (XFRM) and addenda (APND) of the original document
shall also be deprecated.
Note to implementers: if you are doing a replace where original has addenda, you should be real careful - may have been
important comment from another author.

The Registry Adaptor manages document deprecation. See ITI TF-3: 4.1.11 XDS Registry
Adaptor for details.
315

Only the most recent version of a document shall be replaceable. The most recent version of adocument carries a status of Approved while older versions carry a status of Deprecated.
A transformation (connected to original document with XFRM Association) is an alternate formof an original document. Therefore, a transformation is permitted to be replaced (RPLC) but
shall not be appended to (APND).

320

Associations of type XFRM, APND, RPLC, and XFRM_RPLC may include documentation
describing the association (type of transformation, reason for replacement, etc.). If included, it
shall be specified as a Classification on the Association as shown in the example below. See also
XDS Document Entry attribute parentDocumentRelationshipCode.
Example:

325

330

335

340

345

<rim:Association id=”ThisAssociation”
associationType=" urn:ihe:iti:2007:AssociationType:XFRM"
sourceObject="source"
targetObject="target"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Association”
id=”ID_042”><rim:Classification
classificationScheme="urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3"
classifiedObject="ThisAssociation"
id=”ID_043”
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="French"><rim:Name><rim:LocalizedString value="Translation into French"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Connect-a-thon translation types</rim:Value></rim:ValueList></rim:Slot></rim:Classification></rim:Association>___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

11

Copyright © 2012 IHE International, Inc.

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

When a document is replaced and that document is a member of one or more folders, a new
HasMember Association shall be created by the Registry Adaptor connecting the replacement
document to each folder that held the original document as a member. The result is that a folder
contains both the original and replacement document differentiated by their status. The
Document Registry actor shall detect this condition and generate the necessary Associations.

355

Table 4.1-3 lists all metadata associated with XDSDocumentEntry objects. The attribute
XDSDocumentEntry.parentDocumentId is a reference to the targetObject attribute of the new
Association. The attribute XDSDocumentEntry.parentDocumentRelationship is a reference to
the Association Type. This represents two distinct naming conventions, HL7 CDA and ebXML
Registry.

360

Document relationship metadata may coexist with other metadata in a Submission Set.
The new documents (related to original document by RPLC, APND, XFRM, or XFRM_RPLC
Associations) are assigned their own uniqueId attribute unrelated to the original document’s.
See ITI TF-1: 10.4.11.1 for further detail on the use and meaning of document relationships.
4.1.6.2

365

370

Association type signs

An ebRIM Association with associationType of signs shall be used to link an
XDSDocumentEntry representing a Digital Signature with the XDSDocumentEntry representing
the document being signed. Details of how Digital Signatures are represented in XDS are foundin the Document Content Profile on Digital Signatures. In constructing this association, theattributes are:sourceObject: references the XDSDocumentEntry representing the Digital SignaturetargetObject: references the XDSDocumentEntry representing the document being signed
associationType: signs
Other requirements on the use of this Association may exist in the Document Content Profile on
Digital Signatures.

375

4.1.6.3

Association Type formatting

380

ebRIM 3.0 requires a namespace qualified name (urn:oasis:names:tc:ebxmlregrep:AssociationType:HasMember) for an Association Type. The urn:oasis:names:tc:ebxmlregrep:AssociationType: namespace prefix only applies to Association Types defined by ebRIM
3.0 (HasMember only). Association Types defined by XDS and related profiles shall use the IHE
specific namespace urn:ihe:iti:2007:AssociationType:.
Table 4.1-2.1: Association Types used in XDS and related profiles
ebRIM 3.0 Format
urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember
urn:ihe:iti:2007:AssociationType:RPLC
urn:ihe:iti:2007:AssociationType:XFRM___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

12

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
ebRIM 3.0 Format
urn:ihe:iti:2007:AssociationType:APND
urn:ihe:iti:2007:AssociationType:XFRM_RPLC
urn:ihe:iti:2007:AssociationType:signs

4.1.7 Document Definition Metadata

385

Several data types are used in the tables below describing the document metadata. These datatypes are derived from other standards, and encoded in the registry as described in the following
table. For entries where no Data Type is specified the entry is any string of bytes that fits within
the length defined by the schema.
For the data types derived from HL7 standards, XDS requires that the default HL7 separators be
used to represent the structure of HL7 V2 data types:
Field Separator|

Component Separator^

Subcomponent Separator&

Repetition Separator~

390
Table 4.1-3: Data Types
XDS Data Type
CX

SourceStandard

Encoding Specification

HL7 V2 IdentifierThis is an identifier. HL7 Identifier type CX consist 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 represented using a
Universal ID and Universal ID Type. In XDS specification, 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.
An explicit example is:543797436^^^&1.2.840.113619.6.197&ISO
Note that the '&' character must be properly encoded in the XML content.
See the examples in the tables below for the appropriate representation.

DTM

HL7 V2
Date Time

This is a date/time value, represented as precisely as possible. All datetime values in the registry are stored using universal coordinated time
[UTC].
"UTC" implies that the source and the consumer shall convert the time
from/to the local time.

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

13

Copyright © 2012 IHE International, Inc.

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

SourceStandard

Encoding Specification
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

OID

ISO Object
Identifier

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

Field

HL7 V2 Message
Segment

Specified as the Field identifier, followed by a pipe (|) and then the data
value represented with corresponding HL7 V2 data type as defined in HL7
standard. Note that if a HL7 data type is used to derive XDS data type (asshown in this table), the derived XDS data type shall be used to represent
the value.
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

SHA1Document hashcalculated with
SHA1 algorithm

See RFC 3174 US Secure Hash Algorithm 1 (SHA1), September 2001

URI

Uniform
Resource
Identifier

See RFC 2616

UUID

Universally
Unique Identifier

A DCE Universally Unique Identifier, represented in registry attributes
using the URN syntax for UUIDs:

The encoding is the Lexical Representation of hexBinary ([0-9a-fA-F]).

urn:uuid:9e0110f8-4748-4f1e-b0a8-cecae32209c7
XCN

HL7 V2 Extended
Person Name

This data type describes a person along with the identifier by which he is
known in some domain (either the source domain or the XDS affinity
domain), using the HL7 v2.5 XCN data type. This data type contains,___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

14

Copyright © 2012 IHE International, Inc.

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

SourceStandard

Encoding Specification
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 withthe following restrictions:
Either name or an identifier shall be present. Inclusion of othercomponents is optional provided the slot value length restrictions imposedby ebXML3.0, 256 bytes, is not exceeded.
If component 1 (ID Number) is specified, component 9 (Assigning
Authority) shall be present if available.
The XDS XCN Component 9 is subject to the same the restrictions as
defined for the XDS CX data type component 4. Thus: the firstsubcomponent 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. Document
Registries 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
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
No other fields shall be specified. The XON data type in XDS 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
such cases, 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 the___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

15

Copyright © 2012 IHE International, Inc.

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

SourceStandard

Encoding Specification
organization. The XDS affinity domain must ensure that this assumption
is correct, through appropriate policies for assigning authorities.
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
Extended
Telecommunications NumberThis type provides the telecommunications address of an entity (forexample author, intended recipient). This specification restricts the use to
the following fields:
XTN.3 – The type of telecommunication address. For example, e-mailaddresses will have this valued with "Internet".
XTN.4 – the telecommunications address, e.g. name@example.com
No other fields shall be specified. The XTN data type in XDS Metadata
results in a valid encoding of an HL7 V2.5 XTN data type.
Example:^^Internet^radiology@healthcare.example.org

The source/query column indicates which attributes are required during submission, and whether
the registry must support the ability to execute queries against them.
395

Table 4.1-4: Codes for Source Column
Code

MeaningR

Required

R2

Required if Known

O

Optional

P

Registry is not required to support query of this attribute.

Cp

Computed/Assigned by Repository, required in register transaction.

Cg

Computed/Assigned by Registry

Cx

Optionally Computed/Assigned by a Document Registry or Initiating Gateway

The XDSDocumentEntry object type is created in ebXML Registry by extending the ebXML
Registry ObjectType Classification Scheme 2.
400

The following metadata elements shall be used to describe an XDS Document. They shall be
provided by the Document Repository Actor in the Register Document Set Transaction either
directly if grouped with a Document Source Actor or forwarded from a Provide and Register
Document Set Transaction.
The XDSDocumentEntry.repositoryUniqueId shall be supplied by the Document Repository
Actor. It identifies the repository that is storing the document.
2

The specific requirement in ebRIM that object types be user extendable was introduced after version 2.0.

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

16

Copyright © 2012 IHE International, Inc.

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

Each attribute shown below is an attribute on the XDSDocumentEntry object. The attributename is defined with a prefix of the object type of XDSDocumentEntry when referenced byother objects, for example XDSDocumentEntry.patientId.
Table 4.1-5: Document Metadata Attribute Definition
XDSDocumentEntry
Attribute
authorDefinition

SourceRepresents the humans and/or machines that authored the document. This
attribute contains the following sub-attributes:•

authorInstitution•

authorPerson•

authorRole•

authorSpecialty•

authorTelecommunication

R2

which are individually defined below.
The author attribute is defined as a Classification which contains theabove sub-attributes. The author attribute itself does not have a simple
value. It defines a structure to hold its sub-attributes. An instance of thisClassification shall be considered a single value of the author attribute. If
present, the author attribute shall have one or more sub-attributes. Eachinstance of this Classification shall contain:•

Zero or one instance of the authorPerson sub-attribute•

Zero or more instances of the authorInstitution sub-attribute•

Zero or more instances of the authorRole sub-attribute•

Zero or more instances of the authorSpecialty sub-attribute•

Zero or more instances of the authorTelecommunication subattribute

At least an authorPerson, authorTelecommunication, or authorInstitution
sub-attribute shall be present when the author attribute is included in the
document metadata.
The following example shows the definition of a single author. The
classification shows the authorPerson Slot holding the required single
value. Single values are shown for authorInstitution, authorRole,
authorSpecialty, and authorTelecommunication. Multiple values for thethree multi-valued sub-attributes, if present, shall be coded as additional
Value elements within the Slot/ValueList having the correct name.
<rim:Classification
classificationScheme="urn:uuid:93606bcf-949443ec-9b4e-a7748d1a838d"classifiedObject="theDocument"
id=”ID_045”
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation=""><!-- nodeRepresentation intentionally left blank -->___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

17

Copyright © 2012 IHE International, Inc.

Constraints
ebRIM

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

Definition

SourceConstraints<rim:Slot name="authorPerson"><!-- shall be single valued, includes
optional ID --><rim:ValueList><rim:Value>D12398^Doe^John^^^^^^&1.2.3.4.5.6.7.8.
9.1789.45.1&ISO</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="authorInstitution"><!-- may be multivalued --><rim:ValueList><rim:Value> Some
Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="authorRole"><!-- may be multivalued --><rim:ValueList><rim:Value>name ofrole</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="authorSpecialty"><!-- may be multivalued --><rim:ValueList><rim:Value>specialty ofauthor</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="authorTelecommunication"><!-- shall be single valued --><rim:ValueList><rim:Value>^^Internet^john.doe@healthcare.example.org</rim:Value></rim:ValueList></rim:Slot></rim:Classification>authorInstitution (subattribute of author)

Represents a specific healthcare facility under which the human and/or
machines authored the document. A specific case is that of homecare.
This is a sub-attribute of the author attribute. See the author attribute fordefinition of the requirements of usage.

R2

XON

R2

XCN

See author for example.
authorPerson (subattribute of author)

Represents the humans and/or machines that authored the document
within the authorInstitution. The document author may be the patient
itself. This is a sub-attribute of the author attribute. See the author
attribute for definition of the requirements of usage.
See author for example.

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

18

Copyright © 2012 IHE International, Inc.

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

Definition

SourceauthorRole (sub-attributeof author)

A code that represents the role of the author with respect to the patientwhen the document was created. This is a sub-attribute of the author
attribute. See the author attribute for definition of the requirements ofusage.

Constraints

R2

See author for example.
authorSpecialty (subattribute of author)

Represents a specific specialty within a healthcare facility under which
the human and/or machines authored the document. This is a subattribute of the author attribute. See the author attribute for definition of
the requirements of usage.

R2

See author for example.
authorTelecommunication

Represents the telecommunications address (e.g. email) of the document
author, intended to assist with automated routing of other messages
intended for the document author. See the author attribute for definitionof the requirements of usage.

O

XTN

See author for example
availabilityStatus

An XDS Document shall have one of two availability statuses:
Approvedavailable for patient care

Deprecatedobsolete

Cg

This attribute is always set to Approved as part of the submission of new
XDS Documents. It may be changed to Deprecated under the primary
responsibility of the Document Source with possible patient supervision.
Although XDS supports the ability to delete documents, there is no suchstate as “the Document Entry is removed” (only an audit trail is kept if
such a deletion is allowed).
This list may be extended in the future. See ITI TF-3: 4.1.3.3 Atomicity
Requirements for XDS Submission Requests for additional details.
If present, shall have a single value.
The example below shows the status attribute, however, this attribute is
only returned on query, not set during any registry or repositorytransaction.

classCode<ExtrinsicObject
id="urn:uuid:fbeacdb7-5421-4474-9267985007cd8855"
objectType="urn:uuid:7edca82f-054d-47f2-a0329b2a5b5186c1"
status="urn:oasis:names:tc:ebxmlregrep:StatusType:Approved"
mimeType="application/octet-stream"> …

The code specifying the particular kind of document (e.g., Prescription,

R___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

19

Copyright © 2012 IHE International, Inc.

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

Definition

SourceDischarge Summary, Report). It is suggested that the XDS Affinity
Domain draws these values from a coding scheme providing a coarse
level of granularity (about 10 to 100 entries). Shall have a single value.

classCodeDisplayName<rim:Classification
classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7e362475b143a"classifiedObject="theDocument"
id=”ID_046”
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="classCode"><rim:Name><rim:LocalizedStringvalue="classCodeDisplayName"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>XDS Affinity Domain
Specific Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

The name to be displayed for communicating to a human the meaning of
the classCode. Shall have a single value for each value of classCode.

Affinity
DomainspecificR

XDS
Affinity
DomainspecificO

XDS
Affinity
DomainspecificR

XDS
Affinity
Domainspecific

See classCode for example.
comments

Comments associated with the Document. Free form text with an XDS
Affinity Domain specified usage.
<rim:Description><rim:LocalizedString value = "comments"/></rim:Description>

confidentialityCode

The code specifying the level of confidentiality of the XDS Document.
These codes are specific to an XDS Affinity Domain. Enforcement andissues related to highly sensitive documents are beyond the scope of
XDS (see security section). These issues are expected to be addressed inlater years. confidentialityCode is part of a codification scheme andvalue set enforced by the Document Registry. Shall have one or morevalues. Code multiple values by creating multiple classification objects.
<rim:Classification
classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524f2705394840f"
classifiedObject="theDocument"
id=”ID_047”
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="confidentialityCode"><rim:Name><rim:LocalizedStringvalue="displayName"/></rim:Name>___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

20

Constraints

Copyright © 2012 IHE International, Inc.

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

entryUUID

Definition

Source<rim:Slot name="codingScheme"><rim:ValueList><rim:Value>XDS Affinity Domain
Specific Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

Represents the time the author created the document in the Document
Source. Shall have a single value.

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

This globally unique identifier is primarily intended for use as a
document registry management identifier. It is not meant to be an
external reference (outside of the Document Registry) for XDS
Documents (e.g., in links within other documents). The uniqueId ismeant for that purpose so that such links remain valid beyond the XDS
Affinity Domain. Values of this attribute are in one of two formats:properly formatted UUID (including urn:uuid: prefix) or symbolic name(anything that does not have the urn:uuid: prefix). Provide and Register
Document Set-b [ITI-41] and Register Document Set-b [ITI-42]
transactions may carry UUID or symbolic formats. All other transactions
shall carry only the UUID format. In processing the Register Document
Set-b [ITI-42] transaction, the Document Registry actor shall accept andstore the offered UUID values and assign UUID values to all symbolic
values.

Constr
aints

R

DTM

R

UUID

O

XDS
Affinity
Domainspecific

In the XML form, entryUUID is represented by the id attribute. In theexample below, the entryUUID is a6e06ca8-0c75-4064-9e5c88b9045a96f6

eventCodeList<rim:ExtrinsicObject mimeType="application/pdf"
id="urn:uuid:a6e06ca8-0c75-4064-9e5c88b9045a96f6"
objectType="urn:uuid:7edca82f-054d-47f2-a0329b2a5b5186c1"> …

This list of codes represents the main clinical acts, such as a colonoscopy
or an appendectomy, being documented. In some cases, the event isinherent in the typeCode, such as a "History and Physical Report" inwhich the procedure being documented is necessarily a "History andPhysical" act.
An event can further specialize the act inherent in the typeCode, such aswhere it is simply "Procedure Report" and the procedure was a"colonoscopy". If one or more eventCodes are included, they shall notconflict with the values inherent in the classCode, practiceSettingCode or
typeCode, as such a conflict would create an ambiguous situation.
This short list of codes is provided to be used as “key words” for certain
types of queries. If present, shall have one or more values. Code multiple
values by creating multiple classification objects.

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

21

Copyright © 2012 IHE International, Inc.

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

eventCodeListDisplay
Name

Definition<rim:Classification
classificationScheme="urn:uuid:2c6b8cb7-8b2a-4051-b291b1ae6a575ef4"
classifiedObject="theDocument"
id=”ID_048”
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="eventCode"><rim:Name><rim:LocalizedStringvalue="eventCodeDisplayName"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>XDS Affinity Domain
Specific Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

The list of names to be displayed for communicating to human reader themeaning of the eventCode. If present, shall have a single value
corresponding to each value in eventCodeList.

O

SourceConstr
aints

3

XDS
Affinity
Domainspecific

See eventCodeList for an example.
formatCode

Code globally uniquely specifying the format of the document. Alongwith the typeCode, it should provide sufficient information to allow any
potential XDS Document Consumer to know if it will be able to process
the document. The formatCode shall be sufficiently specific to ensure
processing/display by identifying a document encoding, structure andtemplate (e.g., for a CDA Document, the fact that it complies with a
CDA schema, possibly a template and the choice of a content-specificstyle sheet). Shall have a single value.

R

Format codes may be specified by multiple organizations. Format codes
defined by ITI shall have names with the prefix
urn:ihe:iti:Format codes defined by other IHE domains shall have names with theprefix
urn:ihe:’domain initials’:
Format codes defined by the Affinity Domain shall have names with theprefix
urn:ad:’name of affinity domain’:
Affinity Domains shall be unique.
The prefixes described here are not assumed to be exhaustive.

<rim:Classification
classificationScheme=

3

Required if eventCode has a value.

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

22

Copyright © 2012 IHE International, Inc.

XDS
Affinity
Domainspecific

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

Definition

Source"urn:uuid:a09d5840-386c-46f2-b5ad9c3699a4309d"
classifiedObject="theDocument"
id=”ID_049”
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="formatCode"><rim:Name><rim:LocalizedString value="name"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>XDS Affinity Domain
Specific Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

The name to be displayed for communicating to human reader themeaning of the formatCode. Shall have a single value corresponding to
the value in formatCode.

R

XDS
Affinity
Domainspecific

Cp

SHA1
hash

See formatCode for an example.
hash

Hash key of the XDS Document itself. This value is computed by theDocument Repository and used by the Document Registry for detecting
the improper resubmission of XDS Documents. If present, shall have asingle value.

Constraints

See Table
4.1-3

If this attribute is received in a Provide & Register Document Set-b [ITI41] transaction, it shall be verified by the repository with the actual hashvalue of the submitted document; an XDSRepositoryMetadataError shallbe returned on mismatch.
<rim:Slot name="hash"><rim:ValueList><rim:Value>

healthcareFacility
TypeCodeda39a3ee5e6b4b0d3255bfef95601890afd80709</rim:Value></rim:ValueList></rim:Slot>

This code represents the type of organizational setting of the clinicalencounter during which the documented act occurred.

R

In some cases, the setting of the encounter is inherent in the typeCode,such as "Diabetes Clinic Progress Note". healthcareFacilityTypeCodeshall be equivalent to or further specialize the value inherent in the
typeCode; for example, where the typeCode is simply "Clinic Progress
Note" and the value of healthcareFacilityTypeCode is "private clinic".
The value shall not conflict with the value inherent in the typeCode, assuch a conflict would create an ambiguous situation. Shall have a single
value.
<rim:Classification
classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0eed0b0bdb91e1"
classifiedObject="theDocument"
id=”ID_050"___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

23

Copyright © 2012 IHE International, Inc.

XDS
Affinity
Domainspecific

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

Definition

SourceConstraints

objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="healthcareFacilityTypeCode"><rim:Name><rim:LocalizedString

healthcareFacility
TypeCodeDisplay
Namevalue="healthcareFacilityTypeCodeDisplayName"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>XDS Affinity Domain
Specific Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

The name to be displayed for communicating to a human the meaning of
the healthcareFacilityTypeCode. Shall have a single value for each valueof healthcareFacilityTypeCode.

R

XDS
Affinity
Domainspecific

Cx

64
character
OID inURIsyntaxSee healthcareFacilityTypeCode for an example.
homeCommunityId

A globally unique identifier for a community.

See TF2a:3.18.4.1.2.3.8 ITI
TF-2b:
3.38.4.1.2.1languageCode

Specifies the human language of character data in the document. The
values of the attribute are language identifiers as described by the IETF
(Internet Engineering Task Force) RFC 3066.

R

This value may further be restricted by the registry according to XDS
Affinity Domain specific policy. Shall have a single value.

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

Represents a participant who has legally authenticated or attested the
document within the authorInstitution. Legal authentication implies thata document has been signed manually or electronically by thelegalAuthenticator. This attribute may be absent if not applicable. If
present, shall have a single valueO<rim:Slot name="legalAuthenticator"><rim:ValueList><rim:Value>^Welby^Marcus^^^Dr^MD</rim:Value>___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

24

Copyright © 2012 IHE International, Inc.

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

mimeType

Definition

Source</rim:ValueList></rim:Slot>

MIME type of the document in the Repository. Shall have a single
value.

Constraints

R<rim:ExtrinsicObject mimeType="application/pdf"
id="theDocument"
objectType="urn:uuid:7edca82f-054d-47f2-a0329b2a5b5186c1"

patientId> …
The patientId represents the subject of care of the document. This
identifier shall be from the Assigning Authority Domain supporting the
XDS Affinity Domain in which the Document Registry operates. It shallcontain two parts:

R

CX

R

XDS
Affinity
Domainspecific

Authority Domain Id (enforced by the Registry)An Id in the above domain.
No other values are allowed, as specified for the CX type in Table 4.1-3
above. Using HL7 terminology, no other values are allowed in thecomponents of the coded value, nor are further subcomponents allowed.
The value of the patientId shall be the same for all new documents of a
Submission Set.
Shall have a single value.
<rim:ExternalIdentifier
identificationScheme="urn:uuid:6b5aea1a-874d-4603-a4bc96a0a7b38446"
value="6578946^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO"
id=”ID_051"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier"registryObject=”DocumentEntry01”><rim:Name><rim:LocalizedString value ="XDSDocumentEntry.patientId"/></rim:Name></rim:ExternalIdentifier>practiceSettingCode

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 XDS Affinity Domain draws thesevalues from a coding scheme providing a coarse level of granularity(about 10 to 100 entries). Shall have a single value.
<rim:Classification
classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05eae952c785ead"classifiedObject="theDocument"
id=”ID_052"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="practiceSettingCode"___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

25

Copyright © 2012 IHE International, Inc.

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

Definition>

practiceSettingCode
DisplayName

Source<rim:Name><rim:LocalizedStringvalue="practiceSettingCodeDisplayName"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>XDS Affinity Domain
Specific Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

The name to be displayed for communicating to a human the meaning of
the practiceSettingCode. Shall have a single value for each value ofpracticeSettingCode.

R

See practiceSettingCode for an example.
repositoryUniqueId

Constraints

The globally unique identifier of the repository where the document isstored, assigned by the Document Repository. This unique identifier for
the Document Repository may be used to identify and connect to thespecific Document Repository where the document is stored once its
metadata has been retrieved from a Document Registry.

XDS
Affinity
DomainspecificCp
ITI TF2b:3.41.4.1
3.42.4.1.2

This repositoryUniqueId is intended to respond to the following types ofusage:The means to reference the Document Repository where this XDS
document is stored. The repositoryUniqueId represents an immutable id
for the Document Repository.
The means to ensure that a XDS Document is retrieved from theappropriate Document Repository.
Shall have a single value.

serviceStartTime<rim:Slot name="repositoryUniqueId"><rim:ValueList><rim:Value>1.3.6.1.4…</rim:Value></rim:ValueList></rim:Slot>

Represents the start time 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 encounter time incase the service was delivered during an encounter. Encounter time is notcoded in XDS metadata but may be coded in documents managed by
XDS. This time is expressed as (date/time/UTC). If present, shall have asingle value.

R2

HL7 V2DTM

R2

HL7 V2

Note: Other times, such as document creation or approval are to berecorded, if needed, within the document.

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

Represents the stop time the service being documented took place___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

26

Copyright © 2012 IHE International, Inc.

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

Definition

SourceDTM(clinically significant, but not necessarily when the document was
produced or approved). This may be the same as the encounter time incase the service was delivered during an encounter. Encounter time is notcoded in XDS metadata but may be coded in documents managed by
XDS. This time is expressed as (date/time/UTC). If the Service happens
at a point in time, this attribute shall contain the same value as theserviceStartTime. If present, shall have a single value.
<rim:Slot name="serviceStopTime"><rim:ValueList><rim:Value>20041225232010</rim:Value></rim:ValueList></rim:Slot>size

Size in bytes of the byte stream that was provided in the Register andProvide Transaction and stored by the XDS Document Repository. Thisvalue is computed by the Document Repository and included in theRegister Documents Set Transaction. If present, shall have a single
value.

Constraints

Cp

Integer
ITI TF2b:3.41.4.1

If this attribute is received in a Provide & Register Document Set-b [ITI41] transaction, it shall be verified by the repository with the actual sizeof the submitted document; an XDSRepositoryMetadataError shall be
returned on mismatch.
<rim:Slot name="size"><rim:ValueList><rim:Value>3654</rim:Value></rim:ValueList></rim:Slot>sourcePatientId

The sourcePatientId represents the subject of care medical record
Identifier (e.g., Patient Id) in the local patient Identifier Domain of theDocument Source. It shall contain two parts:

R

Authority Domain Id
An Id in the above domain (e.g., Patient Id).
This sourcePatientId is not intended to be updated once the Document isregistered (just as the Document content and metadata itself will not be
updated without replacing the previous document). As thissourcePatientId may have been merged by the source actor, it may nolonger be in use within the Document Source (EHR-CR). It is only
intended as an audit/checking mechanism and has occasional use forDocument Consumer Actors. There can be only one Slot named
sourcePatientId.
<rim:Slot name="sourcePatientId"><rim:ValueList><rim:Value>
j98789^^^&amp;1.2.3.4.343.1&amp;ISO</rim:Value></rim:ValueList></rim:Slot>sourcePatientInfo

This attribute should contain demographics information of the patient towhose medical record this document belongs, as the Document SourceO___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

27

Copyright © 2012 IHE International, Inc.

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

Definition

Sourceknew it at the time of Submission.
This information typically includes: the patient first and last name, sex,
and birth date. The Clinical XDS Affinity Domain policies may require
more or less specific information and format.
This patient information is not intended to be updated once theDocument 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 nolonger be in use within the Document Source (EHR-CR). It is only
intended as an audit/checking mechanism and has occasional use forDocument Consumer actors. Shall have a single value (only a single
sourcePatientInfo slot may be present).
<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>PID5|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>

PID-3 should include the source patient identifier.
PID-5 should include the patient name.
PID-8 should code the patient gender as
M – Male F – Female
O – OtherU – Unknown
PID-7 should include the patient date of birth.
PID-11 should include the patient address.

PID-2, PID-4, PID-12 and PID-19 should not be used.
title

Represents the title of the document. Clinical documents often do nothave a title, and are collectively referred to by the display name of theclassCode (e.g., a "consultation" or "progress note"). Where these display
names are rendered to the clinician, or where the document has a uniquetitle, the title component shall be used. Max length, 128 bytes, UTF-8.
If present, shall have a single value.

O<rim:ExtrinsicObject
id="theDocument"
objectType="urn:uuid:7edca82f-054d-47f2-a0329b2a5b5186c1"
mimeType="application/pdf"><rim:Name><rim:LocalizedStringvalue="title"/></rim:Name>…
</rim:ExtrinsicObject>___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

28

Copyright © 2012 IHE International, Inc.

Constraints

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

typeCodeDisplay
Name

Definition

Source

The code specifying the precise kind of document (e.g., Pulmonary
History and Physical, Discharge Summary, Ultrasound Report). It issuggested that the XDS Affinity Domain draw these values from a
coding scheme providing a fine level of granularity. Shall have a single
value.
<rim:Classification
classificationScheme=" urn:uuid:f0306f51-975f-434e-a61cc59651d33983"
classifiedObject="theDocument"
nodeRepresentation="typeCode"
id=”ID_053"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"><rim:Name><rim:LocalizedStringvalue="typeCodeDisplayName"/></rim:Name><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>XDS Affinity Domain
Specific Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

The name to be displayed for communicating to a human the meaning of
the typeCode. Shall have a single value for each value of typeCode.

R

XDS
Affinity
DomainspecificR

XDS
Affinity
DomainspecificR

See ITI
TF-3:
4.1.7.2

See typeCode for an example.
uniqueId

The globally unique identifier assigned by the document creator to thisdocument. This unique identifier may be used in the body of other XDS
Documents to reference this document. The length of Unique Identifier
shall not exceed 128 bytes. The structure and format of this Id shall beconsistent with the specification corresponding to the format 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 form oid^extension, where OID is a 64 digits max, andthe ID is a 16 UTF-8 char max). If the oid is coded without the extension
then the '^' character shall not be included.
This uniqueId is intended to respond to the following types of usage:
The means to reference this XDS document from within the content ofanother document. Neither the XDS Registry nor the Repository isaware of such references, but the Document Sources and Consumers are.
Shall have a single value.
<rim:ExternalIdentifier
identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da38640a32e42ab"
value="1.3.6.1.4.1.21367.2005.3.7^11379"
id=”ID_054"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier"___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

29

Constraints

Copyright © 2012 IHE International, Inc.

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

URI

Definition

SourceConstraints

registryObject=”DocumentEntry01”><rim:Name><rim:LocalizedStringvalue="XDSDocumentEntry.uniqueId"/></rim:Name></rim:ExternalIdentifier>

For XDM the URI element shall point to the file containing the
document.

O

URI

If present, shall have a single value.

ITI TF-2b:

There are two formats for coding this attribute. If the string representing
the URI is 128 characters or shorter, the short format may be used:

3.32.4.1.2.
2<rim:Slot name="URI"><rim:ValueList><rim:Value>http://www.ihe.net</rim:Value></rim:ValueList></rim:Slot>

If the string is more than 128 characters long, the long format shall be
used:<rim:Slot name="URI"><rim:ValueList>
nt?

.3

pdf

<rim:Value>1|http://www.ihe.net/IHERetrieveDocume</rim:Value><rim:Value>2|requestType=DOCUMENT&documentUID=1.2</rim:Value><rim:Value>3|&preferredContentType=application%2f</rim:Value></rim:ValueList></rim:Slot>

Each Value is composed of an ordering prefix followed by a portion of
the actual URI string. The ordering prefix shall be sequential starting at
the value 1. When the long format is used, all Values shall have anordering prefix.
Each value is ordered by its ordering prefix:
ordering-prefix :== digit vertical-bar
digit :== ‘1’ | ‘2’ | ‘3’ | ‘4’ | ‘5’ | ‘6’ | ‘7’ | ‘8’ | ‘9’vertical-bar :== ‘|’The long version may be used for URIs of less than 129 characters. This
profile does not specify how a URI is to be broken up into pieces. The
following example is valid.

<rim:Slot name="URI"><rim:ValueList><rim:Value>1|http://www.ihe.net</rim:Value></rim:ValueList></rim:Slot>___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

30

Copyright © 2012 IHE International, Inc.

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

Definition

SourceConstraints

The long version is assembled into a URI by concatenating the Values
without the ordering prefixes in the order specified by the orderingprefixes.

410

415

4.1.7.1

XDSDocumentEntry.formatCode

In general, the repository holds an octet stream representing the document. The registry metadata
describes, among other things, the format of the document. This is coded in
XDSDocumentEntry.formatCode. This code will identify document format parameters necessary
for interoperability. Rules about handling the formatCode are necessary but are not imposed by
XDS. In the future IHE content specific Integration Profiles may be created that specify theserules.
Note: Although only a small number of document standards may be used, a large number of code values may be defined topoint to specific templates and archetypes structuring specific document content.

4.1.7.2
420

425

XDSDocumentEntry.uniqueId

The specification of the format and encoding for this attribute depends on the document standard
defining the content of the XDS Document (e.g., OID with optional extension ID for HL7 CDA,UUID in some cases, SOP Instance UID for DICOM composite objects. Format is:
OID^Extension). This attribute shall not exceed 128 bytes in size. It shall be used as an opaqueand globally unique identifier for the XDS Document. Document Consumers, Registries,
Repositories shall not attempt to interpret its content. When the Extension is not present, the ‘^’character shall not be included.
4.1.7.3 XDSDocumentEntry.repositoryUniqueId

430

435

440

To better match the Web Services messaging architecture and provide a MTOM/XOP binding
for the Retrieve Document Set and the Provide and Register Document Set-b transactions, it isnecessary to further specify the location of the document to identify the actual Document
Repository that contains it before the Document Repository can be queried to retrieve the actual
document.
The Document Repository shall populate the following attribute in the XDSDocumentEntry
class:• repositoryUniqueId: this single-valued attribute of type OID represents the unique id of theDocument Repository that stores the document. The attribute is populated by the Document
Repository as part of the Provide and Register Document Set-b transaction. The Document
Repository id is considered immutable throughout the lifetime of the Document Repository
to which it is associated. In other words, once an id has been associated to a Document
Repository it can never change. The repositoryUniqueId attributes are defined in acommunity and assigned to Document Repository actors.
___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

31

Copyright © 2012 IHE International, Inc.

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

445

The Document Repository shall populate this attribute before registering documents in theDocument Registry. This allows for positive identification of the web service endpoint of theDocument Repository for the purposes of retrieving a document or set of documents. The
mechanism by which the service endpoints are discovered and associated to the appropriate
actors and how that configuration is maintained is out of scope for this transaction.
4.1.8 Submission Set Metadata

450

455

The following metadata elements shall be used to describe an XDS Submission Set. They shallbe provided by the Document Source Actor in the Provide and Register Document Set
transaction. They shall be provided by the Document Repository Actor in the Register Document
Set Transaction either directly if grouped with a Document Source Actor or forwarded from a
Provide and Register Document Set Transaction.
Each of the attributes listed below is an attribute on the RegistryPackage object defining theSubmission Set. The attribute name is defined with a prefix of the object type of
XDSSubmissionSet when referenced by other objects, for example XDSSubmissionSet.sourceId.
In the attribute tables below, when an OID format is specified, it shall follow the assignment andformat rules defined for document UID in ITI TF-2x: Appendix B.

Table 4.1-6: Submission Set Metadata Attribute Definitions
XDSSubmission
Set
Attribute
authorDefinition

SourceRepresents the humans and/or machines that authored thesubmission set. This attribute contains the following subattributes:• authorInstitution• authorPerson• authorRole• authorSpecialty• authorTelecommunication
which are individually defined below.

R2

Constraints
ebRIM

The author attribute is defined as a Classification which contains
the above sub-attributes. The author attribute itself does not havea simple value. It defines a structure to hold its sub-attributes. An
instance of this Classification shall be considered a single valueof the author attribute. If present, the author attribute shall haveone or more sub-attributes. Each instance of this Classification
shall contain:• Zero or one instance of the authorPerson sub-attribute• Zero or more instances of the authorInstitution subattribute• Zero or more instances of the authorRole sub-attribute• Zero or more instances of the authorSpecialty subattribute___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

32

Copyright © 2012 IHE International, Inc.

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

Definition•

SourceConstraints

Zero or more instances of the authorTelecommunication
sub-attribute

At least an authorPerson, authorTelecommunication, or
authorInstitution sub-attribute shall be present when the author
attribute is included in the submission set.
The following example shows the definition of a single author.
The classification shows the authorPerson Slot holding therequired single value. Single values are shown forauthorInstitution, authorRole, authorSpecialty, andauthorTelecommunication. Multiple values for the threemultivalued sub-attributes, if present, shall be coded as additional
Value elements within the Slot/ValueList having the correct
name.
<rim:Classification
classificationScheme="urn:uuid:a7058bb9-b4e44307-ba5b-e3f0ab85e12d"classifiedObject="theSubmissionSet"
id=”ID_055"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation=""><!-- nodeRepresentation intentionally left blank --><rim:Slot name="authorPerson"><!-- shall be single valued, includes
optional ID --><rim:ValueList><rim:Value>
D12398^Doe^John^^^^^^&1.2.3.4.5.6.7.8.9.1789.45.1&ISO</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="authorInstitution"><!-- may be multivalued --><rim:ValueList><rim:Value> Some
Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="authorRole"><!-- may be multivalued --><rim:ValueList><rim:Value>name ofrole</rim:Value></rim:ValueList></rim:Slot><rim:Slot name="authorSpecialty"><!-- may be multivalued --><rim:ValueList><rim:Value>specialty ofauthor</rim:Value></rim:ValueList>___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

33

Copyright © 2012 IHE International, Inc.

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

Definition

SourceConstraints</rim:Slot><rim:Slot name="authorTelecommunication"><!-- shall be single valued --><rim:ValueList><rim:Value>^^Internet^john.doe@healthcare.examp
le.org</rim:Value></rim:ValueList></rim:Slot></rim:Classification>authorInstitution(sub-attribute of
author)authorPerson (subattribute of author)

Represents a specific healthcare facility under which the human
and/or machines authored the Submission Set. This is a subattribute of the author attribute. See the author attribute fordefinition of the requirements of usage.
See author for example.
Represents the human and/or machines that authored theSubmission Set. The document author may be the patient itself.
This is a sub-attribute of the author attribute. See the author
attribute for definition of the requirements of usage.

R2

XON

O

XCN

See author for example.
authorRole (subattribute of author)authorSpecialty(sub-attribute of
author)authorTelecommuni
cationavailabilityStatus

A code that represents the role of the author with respect to thepatient when the submission set was created. This is a subattribute of the author attribute. See the author attribute fordefinition of the requirements of usage.
See author for example.
Represents a specific specialty within a healthcare facility underwhich the human and/or machines authored the submission set.
This is a sub-attribute of the author attribute. See the author
attribute for definition of the requirements of usage.
See author for example.
Represents the telecommunications address (e.g. email) of thesubmission set author, intended to assist with automated routingof other messages intended for the submission set author. See theauthor attribute for definition of the requirements of usage.
See author for example
An XDSSubmissionSet shall have one of two availability
statuses:
Submitted
submission transaction not completed, notavailable for patient care
Approvedavailable for patient careThis attribute is always set to Approved as part of a successful
submission of new XDS Documents. XDS does not allow for the

R2

R2

O

XTN

Cg

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

34

Copyright © 2012 IHE International, Inc.

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

Definition

SourceConstraints

deprecation of Submission Sets.
See ITI TF-3: 4.1.3.3 Atomicity Requirements for XDS
Submission Requests for additional details.
If present, shall have a single value.
The example below shows the status attribute, however, this
attribute is only returned on query, not set during any registry or
repository transaction.
<rim:RegistryPackage
id="urn:uuid:fbeacdb7-5421-4474-9267-985007cd8855"
status="urn:oasis:names:tc:ebxmlregrep:StatusType:Approved"> ...
comments

Comments associated with the Submission Set. Free form text
with an XDS Affinity Domain specified usage.

O

Use specific to
XDS Affinity
Domain.

R

XDS Affinity
Domain specificR

XDS Affinity
Domain specific<rim:Description><rim:LocalizedString value = "comments"/></rim:Description>

contentTypeCode

The code specifying the type of clinical activity that resulted inplacing these XDS Documents in this XDS-Submission Set.
These values are to be drawn for a vocabulary defined by the
XDS Affinity Domain. Shall have a single value.
<rim:Classification
classificationScheme=“urn:uuid:aa543740-bdda-424e-8c96df4873be8500”
classifiedObject=”submissionSet”
id=”ID_056"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation=”contentTypeCode”><rim:Name><rim:LocalizedString

contentTypeCode
DisplayName

value=”contentTypeCodeDisplayName” /></rim:Name><rim:Slot name=”codingScheme”><rim:ValueList><rim:Value>XDS Affinity Domain
Specific Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

The name to be displayed for communicating to a human themeaning of the contentTypeCode. Shall have a single value foreach value of contentTypeCode.
See contentTypeCode for an example.

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

35

Copyright © 2012 IHE International, Inc.

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

Definition

SourceThis globally unique identifier is primarily intended for use as a
document registry management identifier. It is not meant to be an
external reference (outside of the Document Registry) for XDS
Documents (e.g., in links within other documents). The uniqueId
is meant for that purpose so that such links remain valid beyond
the XDS Affinity Domain. Values of this attribute are in one of
two formats: properly formatted UUID (including urn:uuid:
prefix) or symbolic name (anything that does not have theurn:uuid: prefix). Provide and Register.b and Register.btransactions may carry UUID or symbolic formats. All othertransactions shall carry only the UUID format. In processing theRegister.b transaction, the Document Registry actor shall accept
and store the offered UUID values and assign UUID values to all
symbolic values.

Constraints

R

UUID

64 character OID
in URI syntax
See TF-2a:3.18.4.1.2.3.8
ITI TF-2b:
3.38.4.1.2.1
XON/XCNIn the XML form, entryUUID is represented by the id attribute.
In the example below, the entryUUID is

urn:uuid:a6e06ca8-0c75-4064-9e5d-88b9045a9ab6<rim:RegistryPackage mimeType="application/pdf"
id="urn:uuid:a6e06ca8-0c75-4064-9e5d-88b9045a9ab6"> ...
homeCommunityId

A globally unique identifier for a community.

Cx

intendedRecipient

Represents the organization(s) or person(s) for whom the
Submission set is intended. If present, shall have one or morevalues. Each slot value shall include at least one of theorganization, person, or telecommunications address fields
described below. Example below shows two doctors from thesame organization, another doctor without precision of theorganization, another organization without the precision of theperson, and just a telecommunications address. The receipt of this
attribute in any transaction will not cause the request to be
rejected but the attribute may be ignored.

O

Note: It is highly recommended to define the organization for all
the persons, avoiding errors in the transmission of the documentsinternally at the Document Recipient side. There is a “|” character
separator between the organization and the person, and between
the person and the telecommunications address, which is required
when the person or telecommunications address information ispresent.
<rim:Slot name="intendedRecipient">___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

36

Copyright © 2012 IHE International, Inc.

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

Definition

sourceId

Constraints<rim:ValueList><rim:Value> Some
Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45|^Wel^Marcus^^^Dr^MD|^^Internet^mwel@healthcare.example.org</rim:Value><rim:Value> Some
Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45|^Al^Peter^^^Dr^MD</rim:Value>>patientId

Source<rim:Value>|12345^John^Smith^^^Dr^MD</rim:Value<rim:Value>Main
Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.2364</rim:Value><rim:Value>||^^Internet^dr.oz@healthcare.exampl
e.org</rim:Value></rim:ValueList></rim:Slot>

The patientId represents the medical record identifier of subjectof care whose longitudinal record is being maintained, as selectedby the Document Source. Attaching an existing document forpatient A to a folder for patient B is presumed in this case to be
an update to the longitudinal record for patient B. In this case,the Submission Set patientId would be that of patient B.
This identifier shall be from the Assigning Authority Domain
supporting the XDS Affinity Domain in which the Document
Registry operates. It shall contain two parts:
Authority Domain Id (enforced by the Registry)An Id in the above domain.
No other values are allowed, as specified for the CX type inTable 4.1-3 above. Using HL7 terminology, no other values areallowed in the components of the coded value, nor are further
subcomponents allowed.
The value of the patientId shall be the same for all new
documents of a Submission Set.
Shall have a single value.
<rim:ExternalIdentifier
identificationScheme=" urn:uuid:6b5aea1a-874d-4603-a4bc96a0a7b38446"
value="6578946^^^&amp;1.3.6.1.4.1.21367.2005.3.
7&amp;ISO"
id=”ID_057"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier"registryObject=”SubmissionSet01”><rim:Name><rim:LocalizedString value ="XDSSubmissionSet.patientId"/></rim:Name></rim:ExternalIdentifier>

OID identifying the instance of the Document Source that
contributed the Submission Set. When a "broker" is involved insending submission sets from a collection of client systems, it
should use a different source ID for submissions from eachseparate system to allow for tracking. Shall have a single value.

R

CX

R

OID

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

37

Copyright © 2012 IHE International, Inc.

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

submissionTime

Definition

Source<rim:ExternalIdentifier
identificationScheme="urn:uuid:554ac39e-e3fe-47fe-b233965d2a147832"
value="1.3.6.1.4.1.21367.2005.3.7"
id=”ID_058"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier"registryObject=”SubmissionSet01”><rim:Name><rim:LocalizedString value ="XDSSubmissionSet.sourceId"/></rim:Name></rim:ExternalIdentifier>

Point in Time at the Document Source when the Submission Set
was created and issued for registration to the Document Registry.
Shall have a single value.
This shall be provided by the Document Source (in case of e-mailwith significant delay).
<rim:Slot name="submissionTime"><rim:ValueList><rim:Value>20041225212010</rim:Value></rim:ValueList></rim:Slot>

title

Represents the title of the Submission Set. If present, shall havea single value.

uniqueId<rim:Name><rim:LocalizedString value="title"/></rim:Name>

Globally unique identifier for the submission-set instanceassigned by the Document Source in OID format. Shall have asingle value.

Constraints

R

DTM

O

XDS Affinity
Domain specificR

OID
See ITI TF-2x:
Appendix B<rim:ExternalIdentifier
identificationScheme=" urn:uuid:96fdda7c-d067-4183-912ebf5ee74998a8"
id=”ID_059"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier"value="1.3.6.1.4.1.21367.2005.3.7.3670984664"
registryObject=”SubmissionSet01”><rim:Name><rim:LocalizedString value ="XDSSubmissionSet.uniqueId"/></rim:Name></rim:ExternalIdentifier>460

4.1.8.1

Creating an XDSSubmissionSet object from a RegistryPackage element

An XDSSubmissionSet object shall be created from a RegistryPackage element by labeling itwith a Classification of type urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd. A receiver of
metadata shall accept the Classification element coded within the RegistryPackage element or on___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

38

Copyright © 2012 IHE International, Inc.

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

465

the same level. The following XML example demonstrates these two valid approaches to coding
the Classification.
Classification coded inside the RegistryPackage object<…><RegistryPackage id=”SS”><!-- Classify registry package SS as being an XDSSubmissionSet --><Classification classificationNode=”urn:uuid:a54d6aa5-d40d-43f9-88c5b4633d873bdd” classifiedObject=”SS” id=”ID_060"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"/></RegistryPackage><RegistryPackage id=”Fol”><!-- Classify registry package Fol as being an XDSFolder --><Classification classificationNode=”urn:uuid:d9d542f3-6cc4-48b6-8870ea235fbc94c2” classifiedObject=”Fol” id=”ID_061"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"/></RegistryPackage><…>

Classification coded outside the RegistryPackage object<…><RegistryPackage id=”SS”></RegistryPackage><!-- Classify registry package as XDSSubmissionSet --><Classification classificationNode=”urn:uuid:a54d6aa5-d40d-43f9-88c5b4633d873bdd” classifiedObject=”SS” id=”ID_060"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"/><RegistryPackage id=”Fol”></RegistryPackage><!-- Classify registry package as XDSFolder--><Classification classificationNode=”urn:uuid:d9d542f3-6cc4-48b6-8870ea235fbc94c2” classifiedObject=”Fol” id=”ID_061"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"/><…>___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

39

Copyright © 2012 IHE International, Inc.

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

The following UUIDs shall be used to label RegistryPackage elements as Submission Set or
FolderObject being coded

UUID used on the Classification

Submission Set

urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd

Folderurn:uuid:d9d542f3-6cc4-48b6-8870-ea235fbc94c2

4.1.9 Folder Metadata
475

480

The following metadata elements shall be used to describe an XDS Folder. They shall be
provided by the Document Source Actor in the Provide and Register Document Set transaction.
They shall be provided by the Document Repository Actor in the Register Document Set
transaction if this transaction is used outside the context of a Provide and Register Document Set
transaction.
Each of the attributes listed below is an attribute on the RegistryPackage object defining the
Folder. The attribute name is defined with a prefix of the object type of XDSFolder whenreferenced by other objects, for example XDSFolder.patientId.
In the attribute tables below, when an OID format is specified, it shall follow the assignment andformat rules defined for document UID in ITI TF-2x: Appendix B.
485

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 be expected to hold the folder
name.

Table 4.1-7: Folder Metadata Attribute Definitions
XDSFolder
AttributeavailabilityStatus

Definition

SourceAn XDSFolder shall have one of two availability statuses:
Submitted
submission transaction not completed, notfor patient care
Approved

Constraints

Cgavailable

available for patient careThis attribute is always set to Approved as part of a successful
submission of new XDS Folders. XDS does not allow for the deprecationof Folders.
See ITI TF-3: 4.1.3.3 Atomicity Requirements for XDS Submission
Requests for additional details.
If present, shall have a single value.
The example below shows the status attribute, however, this attribute is
only returned on query, not set during any registry or repositorytransaction.
<rim:RegistryPackage___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

40

Copyright © 2012 IHE International, Inc.

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

Definition

SourceConstraints

R

Multi-Valued.
XDS Affinity
DomainspecificR

Multi-valued.

O

XDS Affinity
Domainspecific.

R

UUID

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

Shall contain the set of codes specifying the type of clinical activity that
resulted in placing XDS Documents in this XDSFolder. These values
shall be drawn from a vocabulary or coding scheme defined by the XDS
Affinity Domain.
Shall have one or more values. Code multiple values by creating multiple
classification objects.

codeListDisplayNam
e<rim:Classification
classificationScheme=“urn:uuid:1ba97051-7806-41a8-a48b8fce7af683c5”
classifiedObject=”Folder”
id=”ID_062"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation=”codeList”><rim:Name><rim:LocalizedStringvalue=”codeListCodeDisplayName” /></rim:Name><rim:Slot name=”codingScheme”><rim:ValueList><rim:Value>XDS Affinity Domain
Specific Value</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

The list of human readable descriptions of the meaning of each of thecodes present in the codeList. Shall have a single value corresponding toeach value in codeList.
Only one code may be assigned to the Folder when an XDS Document isplaced in such a Folder.
See codeList for an example.

comments

entryUUID

Comments associated with the Folder. Free form text with an XDS
Affinity Domain specified usage.
<rim:Description><rim:LocalizedString value = "comments"/></rim: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 (outside of the Document Registry) for XDS
Documents (e.g., in links within other documents). The uniqueId ismeant for that purpose so that such links remain valid beyond the XDS
Affinity Domain. Values of this attribute are in one of two formats:properly formatted UUID (including urn:uuid: prefix) or symbolic name(anything that does not have the urn:uuid: prefix). Provide and Register.band Register.b transactions may carry UUID or symbolic formats. All___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

41

Copyright © 2012 IHE International, Inc.

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

Definition

SourceConstraints

Cx

64 character
OID in URI
syntaxother transactions shall carry only the UUID format. In processing theRegister.b transaction, the Document Registry actor shall accept andstore the offered UUID values and assign UUID values to all symbolic
values.
In the XML form, entryUUID is represented by the id attribute.
In the example below, the entryUUID is
urn:uuid:a6e06ca8-0c75-4064-9e5c-88b9045a9ab6

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

A globally unique identifier for a community.

See TF-2a:3.18.4.1.2.3.8
ITI TF-2b:
3.38.4.1.2.1
lastUpdateTime

Point in time at the Document Registry when an XDS Document was
registered and placed in the XDS Folder. If present, shall have a single
value.

Cg

DTM

R

CX

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

The Document Registry shall set lastUpdateTime on submission offolder. The value in the submission request (if present), shall be ignored.
patientId

The patientId represents the subject of care medical record Identifier as
defined by the Document Source. This identifier shall be from theAssigning Authority Domain supporting the XDS Affinity Domain inwhich the Document Registry operates. It shall contain two parts:
Authority Domain Id (enforced by the Registry)An Id in the above domain.
No other values are allowed, as specified for the CX type in Table 4.1-3
above. Using HL7 terminology, no other values are allowed in thecomponents of the coded value, nor are further subcomponents allowed.
The value of the patientId shall be the same for all new documents of a
Folder.
Shall have a single value.
<rim:ExternalIdentifier
identificationScheme=" urn:uuid:f64ffdf0-4b97-4e06-b79fa52b38ec2f8a "___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

42

Copyright © 2012 IHE International, Inc.

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

Definition
value="6578946^^^&amp;1.3.6.1.4.1.21367.2005.3.7&
amp;ISO"
id=”ID_063"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExternalIdentifier"registryObject=”Folder01”><rim:Name><rim:LocalizedString value ="XDSFolder.patientId"/></rim:Name></rim:ExternalIdentifier>title

Represents the title of the Folder. If present, shall have a single value.

uniqueId<rim:Name><rim:LocalizedString value="title"/></rim:Name>

Globally unique identifier for the XDS-Folder in which one or more XDS
Documents are placed. It is assigned by the Document Source at the time
the XDS Folder is created in OID format. Shall have a single value.

SourceConstraintsO

XDS Affinity
DomainspecificR

OID
See ITI TF-2x:
Appendix B<rim:ExternalIdentifier
identificationScheme="urn:uuid:75df8f67-9973-4fbe-a900df66cefecc5a"
id=”ID_064"
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>4.1.9.1

Creating an XDSFolder object from a RegistryPackage element490

An XDSFolder 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 coded within the RegistryPackage element or on the samelevel. The following XML example demonstrates these two valid approaches to coding theClassification.

495

Classification coded inside the RegistryPackage object<…><RegistryPackage id=”SS”><!-- Classify registry package SS as being an XDSSubmissionSet --><Classification classificationNode=”urn:uuid:a54d6aa5-d40d-43f9-88c5-___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

43

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
b4633d873bdd” classifiedObject=”SS” id=”ID_065"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"/></RegistryPackage><RegistryPackage id=”Fol”><!-- Classify registry package Fol as being an XDSFolder --><Classification classificationNode=”urn:uuid:d9d542f3-6cc4-48b6-8870ea235fbc94c2” classifiedObject=”Fol” id=”ID_066"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"/></RegistryPackage><…>

Classification coded outside the RegistryPackage object<…><RegistryPackage id=”SS”></RegistryPackage><!-- Classify registry package as XDSSubmissionSet --><Classification classificationNode=”urn:uuid:a54d6aa5-d40d-43f9-88c5b4633d873bdd” classifiedObject=”SS” id=”ID_065"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"/><RegistryPackage id=”Fol”></RegistryPackage><!-- Classify registry package as XDSFolder--><Classification classificationNode=”urn:uuid:d9d542f3-6cc4-48b6-8870ea235fbc94c2” classifiedObject=”Fol” id=”ID_066"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"/><…>

The following UUIDs shall be used to label RegistryPackage elements as Submission Set or
FolderObject being coded

500

UUID used on the Classification

Submission Set

urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd

Folderurn:uuid:d9d542f3-6cc4-48b6-8870-ea235fbc94c2

4.1.10 Registry Adaptor Enforcement of Attributes
ebRIM version 3.0 datatype Slot/ValueList/Value is limited to 256 characters by that standard.
Sometimes HL7 datatypes, which the attribute tables show as being encoded as a Slot, can be___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

44

Copyright © 2012 IHE International, Inc.

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

505

larger. The Document Source shall encoded these Slots so they fit into the 256 character space
allocated to them. This may require some information to be excluded. This profile gives noguidance as to how information is to be excluded to make this coding limit.
The Registry Adaptor shall reject any submission which includes attribute values whose size
exceeds the specification in the standard.
Table 4.1-8: Document Metadata Attribute Enforcement
XDSDocumentEntry Attribute

Registry Enforcement

availabilityStatus

No enforcement

authorInstitution

No enforcement

authorPerson

No enforcement

authorRole

No enforcement

authorSpecialty

No enforcementclassCodeCoding Scheme and Code Value.

classCodeDisplayName

Must be non-zero length and may be restricted by
XDS Affinity Domain (see 4.1.12.2 Assigning Codes
to Documents)

confidentialityCode

Coding Scheme and Code Value

confidentialityCodeDisplayName

Must be non-zero length and may be restricted by
XDS Affinity Domain (see 4.1.12.2 Assigning Codes
to Documents)

creationTime

No enforcement

entryUUID

No enforcement

eventCodeList

Coding Scheme and Code Value

eventCodeDisplayName

Must be non-zero length and may be restricted by
XDS Affinity Domain (see 4.1.12.2 Assigning Codes
to Documents)

formatCode

Coding Scheme and Code Value

formatCodeDisplayName

Must be non-zero length and may be restricted by
XDS Affinity Domain (see 4.1.12.2 Assigning Codes
to Documents)

hash

Hash value enforcement

healthcareFacilityTypeCode

Coding Scheme and Code Value

healthcareFacilityTypeCodeDisplayName

Must be non-zero length and may be restricted by
XDS Affinity Domain (see 4.1.12.2 Assigning Codes
to Documents)

legalAuthenticator

No enforcement

languageCode

Optionally enforced by XDS Affinity Domain

mimeType

Code ValueparentDocumentRelationship

One of four values

parentDocumentId

Existing UUID

patientId

Authority Domain Id
Patient Id (known from patient identity feed)___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

45

Copyright © 2012 IHE International, Inc.

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

Registry Enforcement

practiceSettingCode

Coding Scheme and Code Value

practiceSettingCode DisplayName

Must be non-zero length and may be restricted by
XDS Affinity Domain (see 4.1.12.2 Assigning Codes
to Documents)

serviceStartTime

No enforcement

serviceStopTime

Verifies serviceStartTime <= serviceStopTime

size

No enforcement

sourcePatientId

No enforcement

sourcePatientInfo

Some parts required

title

No enforcement

typeCode

Coding Scheme and Code Value

typeCodeDisplayName

Must be non-zero length and may be restricted by
XDS Affinity Domain (see 4.1.12.2 Assigning Codes
to Documents)

uniqueId

See ITI TF-3: 4.1.7.2

URI

No enforcement

510
Table 4.1-9: SubmissionSet Metadata Attribute Enforcement
XDSSubmissionSet Attribute

Registry Enforcement

authorInstitution

No enforcement

authorPerson

No enforcement

authorRole

No enforcement

authorSpecialty

No enforcement

comments

No enforcement

contentTypeCode

Coding Scheme and Code value

contentTypeCodeDisplayName

Must be non-zero length and may be restricted by
XDS Affinity Domain (see 4.1.12.2 Assigning
Codes to Documents)

patientId

Authority Domain Id
Patient Id (known from patient identity feed)sourceId

No enforcement

submissionTime

No enforcement

uniqueId

No identical existing uniqueId in registry according
to rules in ITI TF-3: 4.1.7.2

Table 4.1-10: Folder Metadata Attribute Enforcement
XDSFolder Attribute

Registry Enforcement

codeList

Coding Scheme and Code value

codeListDisplayName

Must be non-zero length and may be restricted by XDS___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

46

Copyright © 2012 IHE International, Inc.

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

Registry Enforcement
Affinity Domain (see 4.1.12.2 Assigning Codes to Documents)

comments

No enforcement

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 to
XDSDocumentEntry, XDSSubmissionSet, or XDSFolder)

4.1.11 XDS Registry Adaptor
515

520

525

530

535

540

The XDS Registry Adaptor is a set of functionality that is not provided for in the ebXML
registry standard, but is instead specified by XDS to support integration into the healthcare
environment. This adaptor has the following responsibility:
Validate patient ID – patient identifiers (XDSDocumentEntry.patientId,
XDSSubmissionSet.patientId, XDSFolder.patientId) shall be validated by:• Patient identifiers shall be verified against the patient identifiers received from thePatient Identity Feed [ITI-8] indicating that it is registered against the Patient ID
Domain of the Affinity Domain.
• Patient identifiers shall be verified against known merged patient identifiers received
from the Patient Identity Feed [ITI-8]. A submission containing a merged patient
identifier shall return an XdsUnknownPatientId error. See section 3.8.4.2.4 forbackground on patient identifier merge.
Validate submitted metadata – the adaptor shall verify that submitted metadata meets XDS
Registry metadata specification
Verify coded values – the adaptor shall verify that coded fields (ebXML externalclassifications) contain valid XDS specified values or where the XDS Affinity
Domain constrains code values, to verify them (See ITI TF-3: 4.1.10).
Ensure submissions are atomic - The adaptor shall make submission to registry an atomic
operation – see ITI TF-3: 4.1.3.3 Atomicity Requirements for Submission Requests
for atomicity requirements.
If the registry submission is successful then the adaptor shall label all Document Entry,
Folder, and Submission Set objects as Approved. The ebRIM specification provides
the ApproveObjectsRequest for this purpose.
If the registry submission fails then the adaptor shall remove from the registry all objects
stored as part of this submission set. The ebRIM specification provides theRemoveObjectsRequest for this purpose.

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

47

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
Support document replacement - When a Submission Request includes a ‘RPLC’ or‘XFRM_RPLC’ association indicating that a document is being replaced, thefollowing shall be true:
Document to be replaced must have status = Approved.
545

550

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 section 3.8.4.2.4 of theTechnical Framework.
The association’s sourceObject attribute shall contain the id (UUID or symbolic id) ofan ExtrinsicObject representing an XDSDocumentEntry included in the
Submission Set.

555

The association’s targetObject attribute shall contain the UUID of an ExtrinsicObject(XDSDocumentEntry) already in the registry.
When the ‘RPLC’ or ‘XFRM_RPLC’ association is detected by the Registry Adaptor
it shall:560

Verify the ExtrinsicObject pointed to by the Association’s targetObject attribute ispresent in the registry and has status of Approved. The error
XDSReplaceFailed shall be thrown if this object is not contained in theregistry or has status other than Approved. This ensures that only the mostrecent version of a document 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. The ebRIM requests ApproveObjectsRequest
and DeprecateObjectsRequest are available to do this.

565

If the Document being replaced is a member of one or more Folders, generate
HasMember Associations connecting the replacement Document with each of the
Folders holding the original Document. This makes the replacement Document a
member of all Folders where the original Document is a member.

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

48

Copyright © 2012 IHE International, Inc.

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

570

575

580

585

Validate patientIDs in Folders - The adaptor shall verify that all documents in a folder are
for the same patient. Specifically, verify that the patientId attribute of the folder
matches the patientId attribute of each document in the folder. This comparison shalltake into consideration patient identity merges as described in section 3.8.4.2.4 of theTechnical Framework.
Validate MIME types - The adaptor shall validate that the mimeType document attribute forall documents received is on the approved list for this XDS Affinity Domain.
Maintain Folder attribute ‘lastUpdateTime’ - The XDS Folder attribute lastUpdateTime
shall be updated by the adaptor every time a new document is added to an XDS
Folder.
Validate patientID on documents being added to a Folder - The patientId attribute of an
XDSDocumentEntry object shall match the patientId attribute on any folder that
holds it.
Validate coding - The adaptor shall enforce the number of classifications offered against a
document. Code lists are allowed to be multiples. Codes are required to be singular.
Accept submissions containing multiple documents – The adapter shall be capable ofaccepting submissions containing multiple documents.
4.1.11.1 Required Initialization of the XDS Affinity Domain

590

595

600

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 ITI TF-3: 4.1.11.
How this information is loaded into the Registry Adaptor or how the Registry Adaptor is
implemented is not defined by this profile.
1.

List of acceptable mimeTypes for documents indexed by the registry.

2.

PIX domain name (Assigning Authority) for XDS Affinity Domain. PatientIds attached
to metadata submitted to this registry must come from this PIX Assigning Authority.

3.

Acceptable values for all coded attributes represented in the registry by ebXML
External Classifications. These include classCode, eventCode, confidentialityCode,healthCareFacilityTypeCode, formatCode for XDS Document and
XDSSubmissionSet.code and XDSFolder.codeList.

4.1.11.2 Required Registry Initialization and Schema
A standard ebXML Registry must be initialized with key Classification Schemes and object
types to support XDS. An ebXML Registry SubmitObjectsRequest is available to perform thisinitialization. It includes:• Classification Schemes that anchor the definition of ExternalIdentifiers___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

49

Copyright © 2012 IHE International, Inc.

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

610

615

Additions to the ObjectType ClassificationScheme that introduces a general XDS
ClassificationNode that anchors these additions. The usable new ClassificationNodes are:
XDSDocumentEntry, XDSDocumentEntryStub, XDSFolder, and XDSSubmissionSet.
XDSDocumentEntry and XDSDocumentEntryStub are used as new objectTypes for use in an
ExtrinsicObject to create XDS specific object types. XDSFolder and XDSSubmissionSet areused to classify RegistryPackage objects to label them as XDS Folders or XDS
SubmissionSets.
• External Classification Schemes to support attribute coding.
This initialization includes the assignment of UUIDs to these definitions. These pre-assigned
UUIDs shall be used when implementing XDS.
This initialization is available online on the IHE FTP site, see ITI TF-2x: Appendix W, as
ITI/packages/XDSb.Registry.Initialization.zip•

4.1.12 General Metadata Issues
This section documents ebXML Registry issues that are confusing, under documented, or are in
conflict between various versions of the registry specification.
620

4.1.12.1 Association Type naming
XDS requires that Association names be specified as text names with proper namespaces and not
UUIDs. This is consistent with version 3.0 of ebRIM. XDS requires the use of the following
standard Associations:
HasMember – for linking RegistryPackage objects to their contents

625

In addition, XDS defines a collection of Association types defined in ITI TF-3: 4.1.6 Document
Relationships and Associations.
4.1.12.2 Assigning Codes to Documents

630

635

Many attributes of XDSDocumentEntry, XDSSubmissionSet, and XDSFolder (Tables 4.1-5,
4.1-6, and 4.1-7) are coded attributes defined as ebRIM Classifications. Three details are
required to describe a coded value:
1.

The value of the code2.

A display name used by Document Source to represent the code (raw codes are nothuman-friendly)

3.

The name of the coding scheme that the code comes from.

These three values combine to define a single coded element.
As described in ebXML Registry metadata, a coded attribute looks like:___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

50

Copyright © 2012 IHE International, Inc.

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

640

645

650

655

660

665

670

<!--++++++++++++++++++++++++++++++++++++++++++++++++++--XdsDocumentEntry.classCode-++++++++++++++++++++++++++++++++++++++++++++++++++ --><rim:Classification
classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"classifiedObject="theDocument"
id=”ID_067"
objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="My Class Code"><!-- +++++++++++++++++++++++++++++++++++++++++++++++++
XdsDocumentEntry.classCodeDisplayName++++++++++++++++++++++++++++++++++++++++++++++++++ --><rim:Name><rim:LocalizedString value="Display Name for My Class Code"/></rim:Name><!-- ++++++++++++++++++++++++++++++++++++++++++++++++++
Coding scheme for classCode++++++++++++++++++++++++++++++++++++++++++++++++++ --><rim:Slot name="codingScheme"><rim:ValueList><rim:Value>Name of the Coding Scheme (LOINC for
example)</rim:Value></rim:ValueList></rim:Slot></rim:Classification>

A code is constructed as a Classification object. The relevant parts of this classification are:

675

680

Classification – this element wraps the definition
classificationScheme attribute – this UUID references a Classification Scheme object
already present in the registry. This Classification Scheme object and its UUID are
predefined by XDS and serve as the defining ‘type’ for the code.
classifiedObject attribute – this references the object in metadata being classified. This canbe specified as a UUID or as a symbolic name as shown in the example above.
nodeRepresentation attribute – this is the value of the code.
Name element - this is the display name for the code.
codingScheme Slot (Value sub-element) - this is the name of the coding scheme.
The XDS Affinity Domain defines the local configuration for each coding scheme. Specifically,
it defines:
Name of the coding scheme – which must be used in the codingScheme Slot___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

51

Copyright © 2012 IHE International, Inc.

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

690

695

Values for the code – one of which must be used in the nodeRepresentation attribute
One or more display Name values for each code value – which should be used in theName element and should be semantically consistent with the value for the code.
Note: The same code value may have multiple valid human readable representations in different languages or different, but
semantically equivalent, wording. An XDS Affinity domain MAY restrict the displayName values it accepts
from Document Sources to a list of allowed values. It is the Document Consumer’s responsibility to resolve codevalues in XDS metadata into human readable display values. A Document Consumer may use the displayName
found in the XDS metadata provided by the Document Source, or it may choose another local designation for thecode, for example to translate it from English into French.

Some code types allow multiple values. EventCodeList is an example. These codes contain theletters ‘List’ in their name. These codes are XML coded identically to the above example with
one exception. The entire Classification element may be repeated to specify additional values.
The Registry Adaptor Function is responsible for validating codes against the configuration of
the XDS Affinity Domain.

700

Note: the attribute XDSDocumentEntry.languageCode is not encoded as shown above. See Tables 4.1-5 for details.

4.1.12.3 Formatting of UUIDs

705

710

715

UUIDs shall be formatted according to RFC4122. Furthermore, values 10 through 15 shall beformatted in hexadecimal using lower case ‘a’-‘f’. An example of a properly formatted UUID is:
urn:uuid:10b545ea-725c-446d-9b95-8aeb444eddf3
Registries shall only accept and produce lowercase UUIDs.
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.
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 permanentand shall not be changed.
4.1.12.4 XML Namespaces

720

The Register Document Set, Provide and Register Document Set, and Query Registrytransactions are SOAP requests/responses containing valid XML. All elements shall benamespace qualified. Namespaces must be present in all elements. All referenced namespaces
must be defined within the transmission.
___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

52

Copyright © 2012 IHE International, Inc.

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

730

735

Registry Services schema (ebRS 3.0) defines the RegistryError element for reporting details oferrors or warnings. RegistryError contains two required attributes, errorCode and codeContext.
All transactions that carry the RegistryError element shall return these two attributes with eacherror reported. Codes reported in errorCode shall be taken from Table 4.1-11 when one of thosecodes is appropriate. All extensions to the list of error codes shall be unique. The error codes
XDSRegistryError or XDSRepositoryError shall be returned if and only if a more detailed code
is not available from this table for the condition being reported. The attribute codeContext shallcontain details of the error condition that may be implementation specific.
The following attributes are required on the RegistryError element when reporting errors or
warnings:• errorCode shall be a value taken from Table 4.1-11• codeContext supplies additional detail for the errorCode• severity supplies a coded indication of the severity of the error:• urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error• urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning
The body of all RegistryError elements shall be empty.

740

745

750

The following attributes on the RegistryError element are optional:• location supplies the location of the error: module name and line number or stack trace if
appropriate.
• highestSeverity – supplies the severity of the most severe error
The value of the status attribute of either the RegistryResponse or AdHocQueryResponse
elements shall be taken from the following lists. For Version 3.0 ebRIM/ebRS:• urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure• urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success• urn:ihe:iti:2007:ResponseStatusType:PartialSuccess
Tables 4.1-12 through 4.1-15 control the reporting of errors for transactions that use the
ebRS/ebRIM schemas.
An example of an error response reporting two errors using ebRS and ebRIM 3.0 is:

755

760

<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"___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

53

Copyright © 2012 IHE International, Inc.

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

765

770

codeContext="Patient ID in Document (Document1) does not match
Submission Set"
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>

Table 4.1-11: Error Codes

Error Code¹

Discussion

Transaction(See Note 1)

XDSMissingDocument

XDSDocumentEntry exists in metadata
with no corresponding attached documentP

XDSMissingDocumentMetadata

MIME package contains MIME part with
Content-Id header not found in metadataP

XDSRegistryNotAvailable

Repository was unable to access theRegistryP

XDSRegistryError

Internal Registry/Repository Error.

P,R, SQ, XGQ

XDSRepositoryError
XDSRegistryDuplicateUniqueIdInMessage

P, RS. XGRA 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

UniqueId received was not unique within
the Registry. UniqueId could have been
attached to XDSSubmissionSet or
XDSFolder. CodeContext shall indicate
which and the value of the non-uniqueuniqueId. This error cannot be thrown for
XDSDocumentEntry. See
XdsNonIdenticalHash.

P,R

XDSNonIdenticalHash

Document being registered was a duplicate(uniqueId already in registry) but hashdoes not match. CodeContext indicates
UniqueId.

R

XDSNonIdenticalSize

Document being registered was a duplicate(uniqueId already in registry) but size does
not match. CodeContext indicates
UniqueId.

R

XDSRegistryBusy

Too much activity

P,R,SQ, XGQ

XDSRepositoryDuplicateUniqueIdInMessage

XDSDuplicateUniqueIdInRegistry

XDSRepositoryBusy
XDSRegistryOutOfResources

P, RS, XGRResources are low.

XDSRepositoryOutOfResources
XDSRegistryMetadataError

P

P,R,SQ, XGQ
P, RS, XGR

Error detected in metadata. Actor nameindicates where error was detected.

P,R___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

54

Copyright © 2012 IHE International, Inc.

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

Discussion

Transaction(See Note 1)

CodeContext indicates nature of problem.

XDSTooManyResults

Q,SQ, XGQXDSExtraMetadataNotSaved

This warning is returned if extra metadata
was present but not saved in the registry.

P,R

XDSUnknownPatientId

Patient ID referenced in metadata is notknown to the Registry actor via the Patient
Identity Feed or is unknown because ofpatient identifier merge or other reasons.
The codeContext shall include the value ofpatient ID in question.

P,R, XGQXDSPatientIdDoesNotMatch

XDS specifies where patient IDs mustmatch between documents, submission
sets, and folders. This error is thrown when
the patient ID is required to match anddoes not. The codeContext shall indicate
the value of the Patient Id and the nature of
the conflict.

P,R

XDSUnknownStoredQueryThe Query ID provided in the request is
not recognized.

SQ, XGQXDSStoredQueryMissingParamA required parameter to a stored query is
missing.

SQ, XGQXDSStoredQueryParamNumber

A parameter which only accepts a single
value is coded with multiple values

SQ, XGQXDSRegistryDeprecatedDocumentError

The Register transaction was rejected
because it submitted an Associationreferencing a deprecated document.

P,R

XDSUnknownRepositoryId

The repositoryUniqueId value could not be
resolved to a valid document repository or
the value does not match therepositoryUniqueId of the Document
Repository

RS, XGRXDSDocumentUniqueIdError

The document associated with theDocumentUniqueId is not available. This
could be because the document is notavailable to the Document Repository, therequestor is not authorized to access that
document or the document is no longer
available.

RS, XGRXDSResultNotSinglePatientThis error signals that the single Stored
Query would have returned metadataassigned to multiple Patient IDs

SQ, RS

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

Note: this error
code is not usedin the response toRegistry Stored
Query___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

55

Copyright © 2012 IHE International, Inc.

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

Discussion

Transaction(See Note 1)

ParitalTransformNotProcessed

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

P

ParitalAppendContentNotProcessed

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

P

ParitalTransformReplaceNotProcessed

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

P

DocumentQueued

An XDR Document Recipient queued the
document for future manual matching to apatient.

P

XDSUnknownCommunity

A value for the homeCommunityId is notrecognized

SQ, XGQ, RS,
XGR

XDSMissingHomeCommunityId

A value for the homeCommunityId isrequired and has not been specified

SQ, XGQ, RS,
XGR

XDSUnavailableCommunity

A community which would have been
contacted was not available . See Note 2.

SQ, RS¹The XDS Metadata Update Supplement adds error codes to this table.

775

Note 1:
P = Provide and Register, Provide and Register-b
R = Register, Register-b
Q = Query
SQ = Stored Query

780

RS = Retrieve Document Set
XGQ = Cross Gateway QueryXGR = Cross Gateway Retrieve
Note 2:
Two examples of the use of error code XDSUnavailableCommunity are:

785

790

1.

A Cross Gateway Query or Cross Gateway Retrieve fails because the community
identified by a homeCommunityId could not be contacted.

2.

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.
___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

56

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
The following tables explain the meaning of the status attribute in responses from the Registry or
Repository.
795

In the following tables, the values shown in the RegistryResponse Status andAdhocQueryResponse Status columns shall be prefixed by the namespace•
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:•or
urn:ihe:iti:2007:ResponseStatusType: (for PartialSuccess)when used with ebRS 3.0.
800
Table 4.1-12: Provide and Register Document Set-b Responses
RegistryResponse
statusRegistryErrorList element

ResultSuccess

May be present. If present will contain one ormore RegistryError elements with warning
severity, none with error severity

All metadata and documents were successfully
registered

FailurePresent, contains one or more RegistryError
elements. At least one has error severity,
others may have warning severity.

Metadata and documents not stored

Table 4.1-13: Register Document Set-b Responses
RegistryResponse
statusRegistryErrorList element

ResultSuccess

May be present. If present will contain one ormore RegistryError elements with warning
severity, none with error severity

All metadata was successfully registered

FailurePresent, contains one or more RegistryError
elements. At least one has error severity,
others may have warning severity.

Metadata not stored

805

Table 4.1-15: Stored Query and Cross Gateway Query Responses
AdhocQueryResp
onse status

RegistryErrorList element

ResultSuccess

May be present. If present will contain one ormore RegistryError elements with warning
severity, none with error severity

Results shall be returned. Results may contain
zero or more entries.

PartialSuccess

Present, contains one or more RegistryError
elements. At least one has error severity,
others may have warning severity.

Results shall be returned. Results may contain
zero or more entries.

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

57

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
AdhocQueryResp
onse status
FailureRegistryErrorList element

ResultPresent, contains one or more RegistryError
elements. At least one has error severity,
others may have warning severity.

Results not returned

Table 4.1-16: Retrieve Document Set and Cross Gateway Retrieve Responses
Registry
Response status

RegistryErrorList element

ResultSuccess

May be present. If present will contain one ormore RegistryError elements with warning
severity, none with error severity

All documents were successfully retrieved

PartialSuccess

Present, contains one or more RegistryError
elements. At least one has error severity,
others may have warning severity.

Some documents were successfully retrieved

FailurePresent, contains one or more RegistryError
elements. At least one has error severity,
others may have warning severity.

No documents were successfully retrieved

Complete details on how these elements shall be populated in available at ITI TF-2b: 3.43.5 Protocol Requirements.

810

4.1.14 Extra Metadata Elements
XDS transactions may contain metadata not defined in the XDS Profile. This extra metadata may
be ignored by the recipient but its presence shall not cause an error.
The following conditions shall apply.

815

1.

All extra metadata content shall be in the form of Slots.

2.

These Slots may be attached to XDSSubmissionSet, XDSDocumentEntry, XDSFolder,or Association objects.

3.

If the Document Registry actor is not capable of storing extra metadata and extra
metadata is provided in a Register Document Set transaction, it shall return a warningwith an error code of XDSExtraMetadataNotSaved. The XDS defined metadata shallbe saved.

4.

Document Consumer actors shall ignore extra metadata elements they do notunderstand.

5.

If a Document Registry actor accepts extra metadata Slots (no warning on submission)then it shall return these Slots in query results.

6.

The Name attribute of extra Slots shall conform to the following rules:

820

825

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

58

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________a) 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
830

7.

4.2

Note that ebRIM requires that the name of a Slot be unique within the containing object(Document Entry, Submission Set, Folder, Association).

Character String Comparisons

All character string comparisons shall be done in conformance with the rules of the Unicode
standard (http://www.unicode.org/versions/latest/) using the normalized form C defined inUnicode Technical Report 15 (http://unicode.org/reports/tr15).
835

840

Note:

Latin alphabet case-insensitive NFC matching corresponds to byte string matching. The primary impact of this isfor non-Latin alphabets. They need to be converted into normalized form before comparison. The TR 15
approach is consistent with the working documents of W3C, although W3C has not yet issued a balloted
recommendation that Unicode normalized form C be used. See http://www.w3.org/TR/WD-charreq,
http://www.w3.org/International/charlint/, and the current W3C draft (http://www.w3.org/TR/charmod-norm).

See the following references for more details:
Unicode Technical Report #15,
Unicode Consortium UAX #15: Unicode
Normalization Forms (http://www.unicode.org/reports/tr15/)
Unicode Standard
Unicode Consortium. The Unicode Standard,(http://www.unicode.org/versions/latest/)

845

4.3

XDS Metadata Vocabulary

4.3.1 Metadata UUIDs
The UUIDs in the following sections shall be used in constructing and interpreting XDS
metadata. The assigning authority “IHE XDS Metadata” shall be used for these codes.
4.3.1.1

Submission Set Object
UUID

850

Use/meaning

urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd

ClassificationNode

urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d

author External Classification Scheme

urn:uuid:aa543740-bdda-424e-8c96-df4873be8500

contentTypeCode External Classification Scheme

urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446

patientId External Identifier

urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832

sourceId External Identifier

urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8

uniqueId External Identifier

4.3.1.2

Document Entry Object
UUID

Use/meaning

urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1

XDSDocumentEntry ClassificationNode___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

59

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
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.3.1.3

Folder Object
UUID

Use/meaning

urn:uuid:d9d542f3-6cc4-48b6-8870-ea235fbc94c2

XDSFolder 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___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

60

Copyright © 2012 IHE International, Inc.

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

5 IHE Content Specifications
855

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

Basic Patient Privacy Consents ModuleThis section describes the encoding requirements for the Basic Patient Privacy Consents
Document Content.
860

The BPPC document has two possible document templates, one without a scanned document
part, and one in ITI TF-3: 5.1.2 defines the requirements of the BPPC document without ascanned document part; ITI TF-3: 5.1.3 explains with a scanned document part.
5.1.1 References•865

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
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 ITI TF-3: 5.1.3.

870

5.1.2.1 XDS Metadata
5.1.2.1.1 XDS DocumentEntry Metadata
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.classCode875

The LOINC code for these documents is “57016-8” “Privacy Policy Acknowledgement
Document” and the codeSystem is 2.16.840.1.113883.6.1.
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".

880

5.1.2.1.1.2 XDSDocumentEntry.eventCodeList•

eventCodeList -- the eventCodeList shall be populated using the Patient Privacy Policy
Identifiers that have been acknowledged to within the document.

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

61

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________/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 thedisplay 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
•

885

•

5.1.2.1.1.3 XDSDocumentEntry.formatCode890

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.
5.1.2.1.1.4 XDSDocumentEntry.uniqueId895

This value shall be the ClinicalDocument/id in the HL7 CDA R2 header. The root attribute isrequired, 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
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

900

905

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

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

62

Copyright © 2012 IHE International, Inc.

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

910

915

920

925

<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></structuredBody></component></ClinicalDocument>

Figure 5.1.2.3-1: Sample Consent to Share Information Document

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

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.

935

R

Template ID
1.3.6.1.4.1.19376.1.5.3.1.2.6

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

940___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

63

Copyright © 2012 IHE International, Inc.

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

945

950

<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.3-2: Patient Privacy Acknowledgement Service Events Example

5.1.2.3.2 <documentationOf typeCode='DOC'>
955

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.3.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.
5.1.2.3.4 <templateId root='1.3.6.1.4.1.19376.1.5.3.1.2.6'/>

960

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.3.5 <id root=' ' />965

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.3.6 <code code=' ' displayName=' ' codeSystem=' ' codeSystemName=' '/>970

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.3.7 <effectiveTime><low value=' '/><high value=' '/></effectiveTime>975

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 bepresent. If present, it shall indicate the maximum effective time of the consent. The___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

64

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
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.
980

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.
5.1.3.1 XDS Metadata985

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
The BPPC document shall conform to the XDS DocumentEntry Metadata requirements in the
IHE PCC TF-2:5.1.1.1.1 unless otherwise specified below.

990

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
No additional constraints. For more information, see IHE PCC TF-2: 5.1.1.1.2

995

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.3 Specification
This BPPC document shall conform to the XDS-SD (ITI TF-3: 5.2) specification and shall havethe additional requirements stated in ITI TF-3: 5.1.2.3.

1000

5.1.3.4 Conformance
See ITI TF-3: 5.1.2.4

5.2
1005

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 thisprofile can and should make use of additional annotation within the CDA header to provide___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

65

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
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.
1010

1015

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

1020

•
•
•
•

1025

1030

1035

1040

PDF RFC 3778, The application/pdf Media Type (informative)
PDF/A ISO 19005-1b. Document management - Electronic document file format for longterm preservation - Part 1: Use of PDF (PDF/A)
HL7 CDA Release 2.0 (denoted HL7 CDA R2, or just CDA, in subsequent text)
RFC 3066, Tags for the identification of languages

5.2.1.1 Discussion of Content Standards
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:• 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• 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___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

66

Copyright © 2012 IHE International, Inc.

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

1045

1050

1055

1060

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 ITI TF-3: 5.2.3).

1065

Medical imagery and photographs are outside the scope of this profile. Diagnostic orintervention medical imagery will be supported through DICOM (which includes the use of
JPEG and MPEG). Additionally audio and video recorded content is not covered by this profile.
5.2.2 XDS Metadata
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.

1070

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.
5.2.2.1.1 XDSDocumentEntry.formatCode1075

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.

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

67

Copyright © 2012 IHE International, Inc.

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

1080

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

1085

1090

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
5.2.2.3 XDS Folder Metadata1095

No additional requirements. For more information, see PCC TF-2: 4.1.3___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

68

Copyright © 2012 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.

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

69

Copyright © 2012 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

1100

1105

1110

1115

1120

1125

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 shall containthe 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 forthe document, in which case the extension attribute shall be empty, or an oid that scopes theset of possible unique values for the extension attribute, in which case the extension shall be
populated with a globally unique identifier within the scope of the root oid.
• The ClinicalDocument/code will in most cases be provided by the operator. Values for thiscode are dictated by the CDA R2 documentation, but are permissible to extend to fit theparticular 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 wasscanned. At a minimum, the time shall be precise to the day and shall include the time zone
offset from GMT.
• The ClinicalDocument/confidentialityCode shall be assigned by the operator in accordancewith the scanning facility policy. The notion or level of confidentiality in the header 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 be present.
• 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 thescanned content, when rendered, is in a language different than that of the header, thelanguage context of the CDA will be overwritten at the body level (see ITI TF-3: 5.2.3.9
ClinicalDocument/component/nonXMLBody for an example). Attribute code@code shall bepresent. Attribute code@codeSystem shall be IETF (Internet Engineering Task Force) RFC
3066 in accordance with the HL7 CDA R2 documentation.
Example:<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”/>___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

70

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
5.2.3.2 ClinicalDocument/recordTarget
1130

1135

1140

1145

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 andthe extension attributes. Refer back to PCC TF-2: 4.1.1 for more details.
• At least one ClinicalDocument/recordTarget/patientRole/addr element shall include at least
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 minimallyspecified by the country sub element.
• At least one ClinicalDocument/recordTarget/patientRole/ patient/name element shall be atleast 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 be present
with precision to the year.
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>___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

71

Copyright © 2012 IHE International, Inc.

IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3): Cross-Transaction andContent Specifications______________________________________________________________________________
5.2.3.3 ClinicalDocument/author (original)

1150

1155

1160

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 attribute shallcontain 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.
• The ClinicalDocument/author/assignedAuthor/representedOrganization/id element if known
shall include both the root and the extension attributes. Refer to PCC TF-2: 4.1.1for moredetails.
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>1165
5.2.3.4 ClinicalDocument/author (scanner)
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.
___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

72

Copyright © 2012 IHE International, Inc.

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

•

•
1175
•

1180

1185

•

•

1190
•
1195
•

The ClinicalDocument/author/templateId element shall be present. The root attribute shallcontain the oid, ‘1.3.6.1.4.1.19376.1.2.20.2’, to indicate this author is the scanning device
and software.
The ClinicalDocument/author/time shall denote the time at which the original content wasscanned. 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 thescanning device.
The ClinicalDocument/author/assignedAuthor/assignedAuthoringDevice/code element shallbe present. The values set here are taken from appropriate DICOM vocabulary. The value ofcode@codeSystem shall be set to “1.2.840.10008.2.16.4”. The value of code@code shall be
set to “CAPTURE” for PDF scanned content and “WSD” for plaintext. The value ofcode@displayName shall be set to “Image Capture” for PDF scanned content and“Workstation” for plaintext.
The
ClinicalDocument/author/assignedAuthor/assignedAuthoringDevice/manufacturerModelNa
me element shall be present. The mixed content shall contain string information that specifies
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 technologythat 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 thescanning 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 shall bepresent. The root attribute shall be set to the oid of the scanning facility.

Example:___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

73

Copyright © 2012 IHE International, Inc.

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

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

1205

1210

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 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 from
GMT.
• The ClinicalDocument/dataEnterer/assignedEntity/id element shall be both the root and theextension 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.
Example:___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

74

Copyright © 2012 IHE International, Inc.

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

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

1220

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 be present.
• At least one ClinicalDocument/assignedCustodian/representedOrganization/addr element
shall include at least the country sub element.

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

75

Copyright © 2012 IHE International, Inc.

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

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>

5.2.3.7 ClinicalDocument/legalAuthenticator

1230

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.
• The ClinicalDocument/legalAuthenticator/assignedEntity/id element if known shall include
both the root and the extension attributes. Refer back to PCC TF-2: 4.1.1 for more details.
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>___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

76

Copyright © 2012 IHE International, Inc.

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

1240

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>

5.2.3.9 ClinicalDocument/component/nonXMLBody
1245

1250

1255

1260

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 torecover 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.
• If the human-readable language of the scanned content is different than that of the wrapper(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 3066 in accordance with the HL7 CDA R2 documentation.
• The ClinicalDocument/component/nonXMLBody/text element shall be present and encodedusing 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.

___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

77

Copyright © 2012 IHE International, Inc.

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

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>___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

78

Copyright © 2012 IHE International, Inc.

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

1270

1275

1280

1285

1290

1295

1300

1305

1310

1315

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”/>___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

79

Copyright © 2012 IHE International, Inc.

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

1325

1330

1335

1340

1345

1350

1355

1360

1365

1370

<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><postalCode>01803</postalCode>___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

80

Copyright © 2012 IHE International, Inc.

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

1375

1380

1385

1390

1395

1400

1405

1410

1415

<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>___________________________________________________________________________
Rev. 9.0 Final Text – 2012-08-31

81

Copyright © 2012 IHE International, Inc.