4.2 ebRIM Representation

This section details the representation of the metadata objects and their attributes using classes provided by OASIS ebXML RegRep 3.0 specification at http://docs.oasis-open.org/regrep/v3.0/regrep-3.0-os.zip

The Electronic Business using eXtensible Markup Language (ebXML) Registry and Repository (RegRep) specification describes a way to implement registry and repository servers and clients using standard interfaces, protocols and an information model for publishing, management, discovery and retrieval of arbitrary content and metadata that describes it.

The ebXML RegRep specification is made of two parts:

• ebRIM: The "ebXML Registry Information Model version 3.0" (ebRIM) defines the types of metadata and content that can be stored in an ebXML Registry.
• ebRS: The "ebXML Registry Services Specification version 3.0" (ebRS) defines the services and protocols for an ebXML Registry.

IHE highly constrains the use of ebRIM and ebRS in Document Sharing profiles to fit the requirements for expression of metadata objects and to communicate the objects between actors. This section focuses on expression of the objects, and IHE transactions and profiles detail the communication.

When document sharing was first introduced in IHE, XDS was the only document sharing model. In the initial XDS Profile, the Document Registry could be implemented as an adaptor to an ebXML Registry. As such, all XDS content is valid in terms of the ebRIM, but XDS introduces additional restrictions on the data that may be transmitted. Only a limited number of the classes in ebRIM are supported by XDS and the contents and semantics of those classes are further restricted. While an XDS Registry may be implemented as an adaptor to an ebXML Registry, or without an underlying ebXML Registry, it should not be assumed that features available from a pure ebXML Registry are available in an IHE environment. Features of an ebXML Registry should be considered as not available unless they are explicitly defined by individual IHE profiles.

Now that document sharing in IHE has grown beyond the XDS model, Document Sharing metadata applies to profiles beyond XDS. In those other environments, it is highly unlikely to be implemented using an ebXML Registry.

IHE excludes the requirements found in ebRIM 3.0 Section 2.5.9 which state that "each RegistryObject instance MUST have a life cycle status indicator."  For some RegistryObjects the life cycle status indicator is required by IHE, and this requirement is stated within IHE’s description of use of the object. For other objects, where a requirement is not explicitly stated by IHE, the life cycle status indicator is optional.

IHE Technical Framework documentation conventionally refers to the ebRIM namespace using the “rim:” prefix, for example rim:ExtrinsicObject, rim:RegistryPackage, rim:Slot, rim:Classification, etc.

Table 4.2-1: ebRIM/Document Sharing Correspondence

Document Sharing Object/Association	ebRIM class
DocumentEntry	rim:ExtrinsicObject
SubmissionSet	rim:RegistryPackage
Folder
MemberOf	rim:Association
Relationship

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

The SubmissionSet and Folder object types are conveyed through the rim:RegistryPackage class. Since the ebRIM standard does not allow for subclassing the RegistryPackage class, these two objects are implemented as rim:RegistryPackages. A rim:Classification is used to distinguish between the SubmissionSet and Folder object types.

The HasMember and Relationship Association concepts are conveyed through the rim:Association class.

4.2.1 Metadata Object Types

4.2.1.1 DocumentEntry

The DocumentEntry does not contain the contents of the document; instead it contains attributes describing the document. Further details regarding the DocumentEntry object type can be found in Section 4.1.1.

Figure 4.2.1.1-1 represents the DocumentEntry and its attributes. Detailed descriptions of all the attributes of a DocumentEntry are described in Section 4.2.3.2.

The abstract concept of a DocumentEntry is expressed through an ebRIM ExtrinsicObject classified as a DocumentEntry.

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

The expression of the DocumentEntry is done by mapping the abstract DocumentEntry metadata attributes into rim:ExtrinsicObject class attributes, elements and other associated classes. This mapping uses, wherever possible, the parts of rim:ExtrinsicObject as intended (such as Name, Description and ExternalIdentifier), and holds the healthcare specific attributes in general purpose Slots or Classifications.

Requirements for matching SubmissionSet.patientId to included or referenced DocumentEntries’ patientId are detailed in Section 4.2.2.1.1.

4.2.1.1.1 DocumentEntry types

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

4.2.1.2 SubmissionSet

The abstract concept of a SubmissionSet is expressed through an ebRIM RegistryPackage classified as a SubmissionSet. The SubmissionSet bundles DocumentEntry, Folder and Association objects for submission. Further details regarding the SubmissionSet object type can be found in Section 4.1.1.

This expression is done by mapping the abstract SubmissionSet metadata attributes into, wherever possible, the parts of RegistryPackage as intended and holding the healthcare-specific attributes in general-purpose Slots and Classification. An ebRIM Classification class is used to identify a RegistryPackage as a SubmissionSet versus a Folder.

A SubmissionSet has a set of attributes that are described in Section 4.1.3.3 SubmissionSet Metadata.

SubmissionSets exist for two reasons:

1. To support atomic submissions
2. To provide a permanent record of:
• the existence and status of the submission
• the Folders and DocumentEntry objects and Associations included in the submission

The value of the patientId attribute of the DocumentEntry objects that a SubmissionSet contains shall match the value of the patientId attribute on the SubmissionSet itself.

Requirements for matching the value of SubmissionSet.patientId to the value of Patient Id in referenced DocumentEntry objects are detailed in Section 4.2.2.1.1.

Once the SubmissionSet has been submitted, no further associations to or from the SubmissionSet shall be created later on.

4.2.1.2.1 Creating a SubmissionSet object from a RegistryPackage element

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

SubmissionSet Classification encoded inside the RegistryPackage object

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

SubmissionSet Classification encoded outside the RegistryPackage object

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

Table 4.2.1.2.1-1: XML encoding of SubmissionSet Classification

Item	Description
Classification/@classifiedObject	The @id attribute of the RegistryPackage being classified.
Classification/@classificationNode	A fixed value identifying the type of object the RegistryPackage represents. Accepted values: urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd
Classification/@id	Symbolic id or UUID identifying this Classification. See Section 4.2.3.1.5 for details.
Classification/@objectType	Fixed value as specified by ebRIM. Optional upon submission of objects, required upon retrieval. If set, the value shall be urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification".

4.2.1.3 Folder

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

This expression is done by mapping the abstract Folder metadata attributes into, wherever possible, the parts of RegistryPackage as intended, and holds the healthcare-specific attributes in general purpose Slots and Classifications. An ebRIM Classification class is used to identify a RegistryPackage as a Folder versus a SubmissionSet.

Folders shall not be nested inside other Folders. The value of the patientId attribute of the DocumentEntry objects it contains shall match the value of the patientId attribute on the Folder itself.

4.2.1.3.1 Creating a Folder object from a RegistryPackage element

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

Folder Classification encoded inside the RegistryPackage object

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

Folder Classification encoded outside the RegistryPackage object

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

Table 4.2.1.3.1-1: XML encoding of Folder Classification

Item	Description
Classification/@classifiedObject	The @id attribute of the RegistryPackage being classified.
Classification/@classificationNode	A fixed value identifying the type of object the RegistryPackage represents. Accepted values: Folder: urn:uuid:d9d542f3-6cc4-48b6-8870-ea235fbc94c2
Classification/@id	Symbolic id or UUID identifying this Classification. See Section 4.2.3.1.5 for details.
Classification/@objectType	Fixed value as specified by ebRIM. Optional upon submission of objects, required upon retrieval. If set, the value shall be urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification.

4.2.1.4 Registry Object List

In submission requests and query responses, a Registry Object List contains a list of Folders, SubmissionSets, DocumentEntry objects and Associations.

Figure 4.2.1.4-1 shows in detail the content of the rim:RegistryObjectList used to exchange Document Sharing metadata; a subset of the ebXML Registry Information Model (ebRIM).

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

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

4.2.1.5 Submission Request

See Section 4.1.4 for a definition of Submission Request. The Submission Request is implemented as an <lcm:SubmitObjectsRequest>.

The <lcm:SubmitObjectsRequest> element shall contain one <rim:RegistryObjectList> element.

The <rim:RegistryObjectList> element shall contain:

• One rim:RegistryPackage for the Submission Set
• One rim:ExtrinsicObject for each DocumentEntry in the Submission Request
• One rim:Association for each Association in the Submission Request
• One rim:RegistryPackage for each Folder in the Submission Request

The rim:RegistryObjectList may also contain rim:Classification elements that identify the RegistryPackage elements as a SubmissionSet or Folder. See Section 4.2.1.2.1 and Section 4.2.1.3.1.

A full XML Schema Document for the XDS types is available online:  see ITI TF-2: Appendix W.

Any id attributes or references to other objects in the submission may contain valid UUIDs or symbolic ids (see Section 4.2.3.1.5). References to objects that are not contained in the submission request must be in UUID format.

4.2.2 Association Types

All relationships between metadata objects are handled through Associations. An Association is an object that describes a named relationship between two metadata objects. These relationships are used to form submissions and express some query responses. The relationship between the DocumentEntry and the Document it represents is made with the DocumentEntry.uniqueId attribute, and not an Association since the Document is not a metadata object.

Associations can be used to build relationships between:

• A SubmissionSet and a DocumentEntry – SS-DE HasMember
• A SubmissionSet and a Folder – SS-FD HasMember
• A Folder and a DocumentEntry – FD-DE HasMember
• A SubmissionSet and an Association – SS-HM HasMember
• A DocumentEntry and another DocumentEntry – Relationship

Once deprecated, a DocumentEntry shall not be referenced by future associations.

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

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

Associations have three other required attributes (see Figure 4.2.2-1):

• sourceObject
• targetObject
• associationType

These attributes can be thought to make a small sentence:

• sourceObject AssociationType targetObject

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

• Folder HasMember DocumentEntry

Graphically this example Association looks like:

Association Type formatting

An Association type shall be specified as a URN.

The sourceObject and targetObject are UUID or symbolic format depending on where they are used. Symbolic format is allowable only in submissions. The status attribute shall not be submitted but shall be returned from queries.

The valid Association types are specified in the following table.

Table 4.2.2-1: Association Types

Meaning	Association Type
Membership in a Registry Package (SubmissionSet or Folder)	urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember
Replace	urn:ihe:iti:2007:AssociationType:RPLC
Transformation	urn:ihe:iti:2007:AssociationType:XFRM
Addendum	urn:ihe:iti:2007:AssociationType:APND
Replace with Transformation	urn:ihe:iti:2007:AssociationType:XFRM_RPLC
Digital Signature	urn:ihe:iti:2007:AssociationType:signs
Snapshot of On-Demand document entry	urn:ihe:iti:2010:AssociationType:IsSnapshotOf

Example of basic Association

4.2.2.1 HasMember

In the Document Sharing abstract metadata model, many different relationships are defined between SubmissionSet, DocumentEntry and Folder objects. In this section, each of these relationships is given its own name, like SS-DE HasMember - SubmissionSetHasMemberDocumentEntry. In the underlying ebRIM model, all of these relationships are created using the ebRIM HasMember Association type.

Note: There are four variants of the HasMember Association. See Section 4.1.2 for an overview.

4.2.2.1.1 SS-DE HasMember

HasMember - a DocumentEntry shall be submitted as part of a SubmissionSet by connecting the objects with a HasMember Association. This is shown as SS-DE HasMember in Figure 4.1-1. DocumentEntries may be included in a SubmissionSet in two ways: inclusion by value and inclusion by reference.

SubmissionSet Association labeling

Two types of Association labels are defined: original (submission by value), or reference (Submission by reference). This enables finding the SubmissionSet that first submitted the document.

Submission of an original Document (inclusion by value)

When the creating entity has a new document to be submitted, it shall submit a DocumentEntry by value in the SubmissionSet. This means that the DocumentEntry (and corresponding Document) are part of the submission. The HasMember Association shall contain a Slot with the name SubmissionSetStatus with the value set to Original.

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

When submitting an existing document by value:

• The targetObject shall contain the entryUUID of the DocumentEntry object.
• The sourceObject shall contain the entryUUID of the SubmissionSet object

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

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

Submission of a reference to an existing Document (inclusion by reference)

Existing documents can be referenced by a SubmissionSet. This means that the DocumentEntry (and corresponding Document) are not part of the submission; they have been previously submitted and already exist in the receiving actor. Documents that were submitted in a previous SubmissionSet may be referenced by subsequent SubmissionSets. In this case, the HasMember Association shall contain a Slot with the name SubmissionSetStatus with the value set to Reference.

The value of the SubmissionSet.patientId attribute is not required to match the value of the DocumentEntry.patientId attribute of a DocumentEntry included by reference. The metadata of this submission contains the SubmissionSet. The SS-DE HasMember Association with the ‘Value=Reference’ connects the SubmissionSet to a DocumentEntry already present in the receiving actor.

When submitting a reference to an existing document:

• The targetObject shall contain the entryUUID of the DocumentEntry object.
• The sourceObject shall contain the entryUUID of the SubmissionSet object.

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

4.2.2.1.2 SS-FD HasMember

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

When submitting a Folder:

• The targetObject shall contain the entryUUID of the Folder object.
• The sourceObject shall contain the entryUUID of the SubmissionSet object.

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

4.2.2.1.3 FD-DE HasMember

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

Linking documents to a folder

document can be linked to a Folder to indicate that this document is a member of a particular Folder. This is colloquially called “putting the document into the folder.” Each FD-DE HasMember Association shall be accompanied by a SS-HM HasMember Association that links the FD-DE HasMember Association with the SubmissionSet object (see Section 4.2.2.1.4). See Section 4.2.2.15 for the four ways a DocumentEntry can be added to a Folder.

When adding a DocumentEntry to a Folder:

• The targetObject shall contain the entryUUID of the DocumentEntry object.
• The sourceObject shall contain the entryUUID of the Folder object.

Example Folder HasMember Association

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

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

4.2.2.1.4 SS-HM HasMember

HasMember - a HasMember Association linking a SubmissionSet to a FD-DE HasMember Association, which is in turn an Association between a Folder and a DocumentEntry. This is shown as SS-HM HasMember in Figure 4.2.2.1.5-1. This shall be used to record the SubmissionSet responsible for adding the DocumentEntry to the Folder. The values of SubmissionSet.patientId, Folder.patientId, and DocumentEntry.patientId shall all be the same.

This kind of Association is used when adding a document to an existing Folder. It is used to identify the entity that created the link between a particular document and a particular Folder and shall be as follows:

• The targetObject shall contain the Id of the Association that links the DocumentEntry and the Folder.
• The sourceObject shall contain the entryUUID of the SubmissionSet object.

4.2.2.1.5 Adding DocumentEntries to Folders

A DocumentEntry can be added to a Folder in one of four ways:

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

Scenario 1 - DocumentEntry submitted as part of the Folder in a single submission.

The simplest scenario submits all related objects in one submission set, as shown below.

Scenario 2 – Add existing DocumentEntry to existing Folder

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

Scenario 3 – Folder submitted and existing DocumentEntry added to it

When a new Folder is submitted, an existing DocumentEntry can be added to that Folder. In this case, the SubmissionSet object will not contain the DocumentEntry metadata that correspond to the referenced document.

Scenario 4 – DocumentEntry submitted and added to existing Folder

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

4.2.2.2 Document Relationship

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

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

Table 4.2.2.2-1: 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 (transform with replace)	The current document is both a transformation and a replacement of the parent document.
Signs	The current document is a Digital Signature which signs the parent document.
Is Snapshot of	The current document is a snapshot in time of the parent which shall be an on-demand document

Adapted from HL7 CDA Release 2, Committee Ballot 2

A submitting actor creates a document relationship by submitting a SubmissionSet containing:

1. DocumentEntry – this describes the new document being submitted

2. Association – this links a DocumentEntry with the new DocumentEntry being submitted.

1. The sourceObject attribute of the Association object shall be the entryUUID of the new DocumentEntry contained in the SubmissionSet.
2. The targetObject of the Association object shall be the entryUUID of the linked DocumentEntry. The linked DocumentEntry shall be:

• an existing DocumentEntry known to the receiving entity, with availabilityStatus of Approved (see Section 4.2.3.2.2 DocumentEntry.availabilityStatus); or,
• another DocumentEntry contained in the SubmissionSet.

3. The Association Type is one of the relationships in Table 4.2.2.2-1: Document Relationships.

Note: Some transactions may limit the choice on the linked DocumentEntry.

To specify the entryUUID of an existing DocumentEntry in targetObject, the submitting actor will need to discover the value using a Registry Stored Query [ITI-18] transaction, or by other means.

Note to implementers: A submitting actor using saved entryUUIDs in future transactions can run into consistency problems. For example, a second actor can replace (and therefore deprecate) the DocumentEntry. The saved entryUUID will point to the deprecated DocumentEntry and not the replacement DocumentEntry. Once a DocumentEntry is deprecated, new Associations to that DocumentEntry will be rejected.

Document Relationship Associations may include documentation describing the Association (type of transformation, reason for replacement, etc.). If documentation is included, it shall be specified as a Classification on the Association as follows:

1. Classifications shall be coded following the restrictions set forth in Section 4.2.3.1.2, “Creating Coded Attributes.”
2. The Classification Scheme shall equal urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3 ,  Association Documentation.

Example of a partial submission request:

A stub DocumentEntry is shown to illustrate the id reference coding (Association sourceObject attribute referencing the id attribute of the DocumentEntry/ExtrinsicObject in the submission).

The uniqueId of the new document shall be different than the uniqueId of the existing document, unless the two documents have identical byte sequences (e.g., when replacing a document with a copy of itself in order to change the metadata). See Section 4.2.3.2.26 “DocumentEntry.uniqueId”.

See ITI TF-1: 10.4.10 for further detail on the use and meaning of document relationships.

4.2.2.2.1 APND

The submission shall contain a new DocumentEntry and associated Document and an APND Association linking this new DocumentEntry with an existing DocumentEntry. This new Document/DocumentEntry forms an addendum to the existing Document/DocumentEntry. The APND relationship leaves the original DocumentEntry with its availabilityStatus unchanged (Approved).

Interactions between XFRM and APND

A transformation (connected to original document with XFRM Association) is an alternate form of an original document. Therefore, a transformation shall not be appended (APND).

4.2.2.2.2 XFRM

The submission shall contain a new DocumentEntry and associated Document and a XFRM Association linking this new DocumentEntry with an existing DocumentEntry. This new Document/DocumentEntry defines a transformation of the existing Document/DocumentEntry. The XFRM relationship leaves the original DocumentEntry with its availabilityStatus unchanged (Approved).

4.2.2.2.3 RPLC

The submission shall contain a new DocumentEntry and associated Document and a RPLC Association linking this new DocumentEntry with an existing DocumentEntry. The new DocumentEntry and Document are considered the approved version of the document; the existing DocumentEntry and Document become a deprecated version.

RPLC interactions with other Associations

The submission of a RPLC relationship shall change the availabilityStatus of the original DocumentEntry to Deprecated. The availabilityStatus of all DocumentEntry objects that are transformations (XFRM) or addenda (APND) of the original DocumentEntry shall also be changed to Deprecated.

Figures 4.2.2.2.3-3 and 4.2.2.2.3-4 show a new DocumentEntry/Document [DE03] replacing an original DocumentEntry/Document [DE01] that has a transformation (XFRM) [DE02].

Figures 4.2.2.2.3-5 and 4.2.2.2.3-6 show a new DocumentEntry/Document [DE03] replacing an original DocumentEntry/Document [DE01] that has an addendum (APND) [DE02].

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

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

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

4.2.2.2.4 XFRM_RPLC

The submission contains a new DocumentEntry and associated Document and a XFRM_RPLC Association linking this new DocumentEntry with an existing DocumentEntry. This new Document/DocumentEntry defines a transformation of the existing Document/DocumentEntry that replaces the existing Document/DocumentEntry. The XFRM_RPLC can be thought of as a RPLC followed immediately by a XFRM. All behavior associated with a RPLC association shall also apply to the XFRM_RPLC association.

4.2.2.2.5 Signs

The submission contains a new DocumentEntry and associated Document and a Signs Association linking this new DocumentEntry with an existing DocumentEntry. This new Document is a Digital Signature that signs the existing Document.

An ebRIM Association with associationType of signs shall be used to link a DocumentEntry representing a Digital Signature with the DocumentEntry representing the document being signed. Details of how Digital Signatures are represented are found in the ITI Document Digital Signature (DSG) Profile.

In constructing this Association, the attributes are:

sourceObject : references the DocumentEntry representing the Digital Signature

targetObject : references the DocumentEntry representing the document being signed

associationType : signs

4.2.2.2.6 IsSnapshotOf

When the content of an On-Demand DocumentEntry is retrieved, the retrieved version can be saved in a Document Repository as a Document and recorded in the Document Registry as a Stable DocumentEntry. When this happens, the saved version is linked to the On-Demand DocumentEntry through the IsSnapshotOf Association.

Example IsSnapshotOf Association

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

This Association shall be submitted together with the Stable DocumentEntry representing the snapshot of the On-Demand Document. The sourceObject attribute references the snapshot and the targetObject references the On-Demand DocumentEntry already in the Document Registry.

4.2.3 Metadata Attributes

This section details the coding of metadata attributes using in Document Sharing profiles.

4.2.3.1 General Information about Metadata Attributes

4.2.3.1.1 Attribute Value Length

All attribute value lengths are limited by the size specifications of ebRIM version 3.0. For example, rim:Slot/rim:ValueList/rim:Value is limited to a maximum length of 256 characters.

4.2.3.1.2 Creating Coded Attributes

Many attributes of DocumentEntry, SubmissionSet, Folder, and Association objects are coded attributes defined as ebRIM Classifications. Three details are required to describe a coded value:

1. Code Value – contains the assigned value of the code.
2. Code Display Name - The display name used to represent the code (code values are not necessarily human-friendly). Must be non-zero length.
3. Coding Scheme - An identifier of the coding scheme that the code comes from.
   For common Coding Schemes, see DICOM PS3.16, Table 8-1 Coding Schemes ( http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_8.html ).

• If the Code Value is from a Coding Scheme in this table, the value for Coding Scheme should be taken from either the “Coding Scheme UID” or the “Coding Scheme Designator” column. If both are available, the value of Coding Scheme UID should be used.
• If the Code Value is from a Coding Scheme that is not in this table, and if the Coding Scheme can be identified with an OID, then the OID should be used.

These three values combine to define a single coded attribute.

The following example contains a code value (10160-0) from the LOINC coding scheme which is identified by an OID (2.16.840.1.113883.6.1):

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

Table 4.2.3.1.2-1: Classifications and Descriptions

Item	Description
Classification/@classificationScheme	This UUID defines which metadata attribute this Classification is supplying a value for. See Section 4.2.5 for a list of all values for this attribute. In the example above, this attribute indicates that the Classification contains a value for the DocumentEntry.classCode metadata attribute.
Classification/@classifiedObject	This references the object in metadata being classified. In the example this references the DocumentEntry object that the classCode value is for. Note that the Classification must also be embedded within the referenced object, thus providing dual context. This value must match the @id attribute of the containing Association, ExtrinsicObject or RegistryPackage.
Classification/@id	Symbolic id or UUID identifying this Classification. See Section 4.2.3.1.5 for details.
Classification/@objectType	Fixed value as specified by ebRIM. Optional upon submission of objects; required upon retrieval. If set, the value shall be “urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification”
Classification/@nodeRepresentation	The code value. Required. The example above shows a code value of “10160-0”.
Name/LocalizedString/@value	The code displayName. The example above shows a display name of "History of Medication Use".
Slot/@name	Fixed value that must always be the string “codingScheme”.
Slot/ValueList/Value/text()	The code codingScheme. Shall have exactly one value. In the example above it is "2.16.840.1.113883.6.1".

The creating entity defines the local configuration for each coded metadata attribute. Specifically, it defines for each code:

Coding Scheme – shall be used in the codingScheme Slot.

Code Value – shall be used in the nodeRepresentation attribute.

Code Display Name – shall be used in the Name element. It is expected that the name be semantically consistent with the code value. The same code value may have multiple valid human-readable representations in different languages or in different, but semantically equivalent, wording. The displayName is a convenience provided by the actor that creates the metadata (“metadata creator”), indicating the meaning of the code in a local language used at the “metadata creator”. It is the responsibility of the actor that consumes the metadata (“metadata consumer”) to resolve code values in metadata into human-readable display values. A “metadata consumer” may use the displayName found in the metadata provided by the “metadata creator”, or it may choose another local designation for the code, for example to translate it from English into French.

Some coded attributes allow multiple values. EventCodeList is an example. These attributes may contain the letters ‘List’ in their name. These codes are XML encoded identically to the above example except the entire Classification element may be repeated to specify additional values.

Note: The attribute DocumentEntry.languageCode is not encoded as a coded attribute as shown above. See Table 4.2.3.1.7-2 for details.

4.2.3.1.3 Creating External Identifiers

Several attributes of DocumentEntry, SubmissionSet and Folder (Table 4.2.3.2-1, Table, 4.2.3.3-1 and Table 4.2.3.4-1) are identifiers defined as ebRIM ExternalIdentifiers. These identifiers, such as patient IDs or document unique IDs are considered to be real-world identifiers that have global meaning external to an ebXML registry or other transaction.

The identifiers consist of a single, opaque string stored in the value attribute of an ExternalIdentifier element. The meaning and format depend on the particular identifier. An example of an identifier in a submission request is:

Table 4.2.3.1.3-1: Identifiers and Descriptions

Item	Description
ExternalIdentifier/@identificationScheme	Fixed value denoting the specific identifier. See Section 4.2.5 for a list of valid values.
ExternalIdentifier/@value	The identifier value.
ExternalIdentifier/@id	Symbolic id or UUID identifying this ExternalIdentifier. See Section 4.2.3.1.5 for details.
ExternalIdentifier/@objectType	Fixed value as specified by ebRIM. Optional upon submission of objects; required upon retrieval. If set, the value shall be  "urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
ExternalIdentifier/@registryObject	This references the object in metadata being identified. In the example this references the DocumentEntry object that the patient identifier value is for. Note that the ExternalIdentifier element must also be embedded within the referenced object, thus providing dual context. This value must match the @id attribute of the containing ExtrinsicObject or RegistryPackage.
Name/LocalizedString/@value	The readable name for the identifier. Fixed value according to the particular identifier.

4.2.3.1.4 Creating Author Attributes

The author attribute contains personal and organizational details of a DocumentEntry or SubmissionSet author.

A DocumentEntry’s author is any human and/or machine that is actively involved in the document’s creation process. Depending on the Affinity Domain’s policy, this can include report writers, data enterers, transcriptionists, informants, expert systems, or other participants in the creation process.

A SubmissionSet’s author is any human and/or machine actively involved in selecting the documents to include, in assembling the metadata, or in the submission process.

The author attribute defines a structure to hold its sub-attributes that are individually defined in Sections 4.2.3.1.4.1 through 4.2.3.1.4.5.

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

At least an authorPerson, authorTelecommunication or authorInstitution sub-attribute shall be present when the author attribute is included in the metadata.

Note: Even if the authorPerson sub-attribute is not present, then the human or machine who authored the document or SubmissionSet exists but is not known. The other author sub-attributes apply to that unknown authorPerson.

Note: Author sub-attributes can contain lists of values. IHE does not define a positional correspondence between values in the sub-attributes; e.g., the second authorTelecom value might be a second way of contacting the authorPerson in the first authorInstitution, or might apply to the second (or third) authorInstitution.

Coding:

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

The @classifiedObject attribute references the object being classified, either ExtrinsicObject or RegistryPackage. The Classification must be embedded within the referenced object and the @classifiedObject attribute must match the @id attribute of the referenced object, thus providing dual context. In the example below, the Classification references the DocumentEntry object that the author value is associated with.

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

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

4.2.3.1.4.1 authorInstitution

Description:

Represents the healthcare facility of the author.

If the author works for multiple facilities then the authorInstitution should only include the one relevant to this DocumentEntry or SubmissionSet. Depending on Affinity Domain policy, authorInstitution can denote any organizational unit from an enterprise or a hospital, down to a department or ward. To avoid duplicating static directory information, Affinity Domains should require the use of multiple authorInstitutions only in rare cases, e.g., to identify both the relevant hospital and department in cases where a joint department is attached to two hospitals.

To avoid ambiguity, content creators are encouraged to include a globally unique identifier for the facility. Multiple authorInstitution values should not be used to represent alternate facility names, or the organizational hierarchy.

This is a sub-attribute of the author attribute.

Coding:

The format of the authorInstitution value is XON. See Table 4.2.3.1.7-2 for a description of XON format.

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

4.2.3.1.4.2 authorPerson

Description:

Represents a human or machine that authored the document or SubmissionSet. The author may be the patient itself.

This is a sub-attribute of the author attribute.

Coding:

The format of the authorPerson value is XCN; see Table 4.2.3.1.7-2 for a description of XCN format.

The value is coded as an ebRIM Slot within an author Classification; see Section 4.2.3.1.4 for an example of author Classification. There may be only a single value within the ebRIM Slot.

4.2.3.1.4.3 authorRole

Description:

The authorRole attribute represents the role of the author with respect to the documented act (e.g., Primary Surgeon) or the relationship with the patient (e.g., Primary Care Physician) at the time of authorship.

For a SubmissionSet, authorRole may represent the role of the author with respect to the act of constructing or submitting the SubmissionSet (e.g., legal authenticator).

If no authorPerson is included in the author attribute, authorRole still refers to the unknown authorPerson’s role and not to an authorInstitution’s role. It should not be used to communicate the author’s organizational role (e.g., head of medicine, resident).

This is a sub-attribute of the author attribute.

Coding:

The format of the authorRole value is String or Coded String (see Table 4.2.3.1.7-2).

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

4.2.3.1.4.4 authorSpecialty

Description:

Represents a specific specialty under which the DocumentEntry or SubmissionSet were authored. Unlike a DocumentEntry’s practiceSettingCode, this attribute depends on the author’s specialty, not on the specialty of the healthcare facility. If no authorPerson is included in the author attribute, authorSpecialty still refers to the unknown authorPerson’s specialty and not the authorInstitution’s specialty.

This is a sub-attribute of the author attribute.

Coding:

The format of the authorSpecialty value is String or Coded String (see Table 4.2.3.1.7-2).

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

4.2.3.1.4.5 authorTelecommunication

Description:

Represents a telecommunications address (e.g., email or telephone number) for contacting the author.

This is a sub-attribute of the author attribute.

Coding:

The format of the authorTelecommunication value is XTN; see Table 4.3.1.7-2 for a description of XTN format.

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

4.2.3.1.5 UUIDs

UUIDs shall be formatted according to RFC4122. Furthermore, values 10 through 15 shall be formatted in hexadecimal using only lower case ‘a’-‘f’. An example of a properly formatted UUID is:

urn:uuid:10b545ea-725c-446d-9b95-8aeb444eddf3

Alternatively, symbolic Ids may be used when referencing objects in the same submission request. A symbolic Id is any string which does not start with urn:uuid:. For example, in XDS, a Document Source may create a submission request using symbolic Ids; the Document Registry replaces these with assigned properly formatted UUIDs upon acceptance of the submission.

Once a UUID-format Id value is assigned to a Registry Object, that value is permanent and shall not be changed.

4.2.3.1.6 Extra Metadata Attributes

The term “Extra Metadata Attributes” refers to ebRIM Slots on any DocumentEntry, SubmissionSet, Folder, or Association that are not defined in the Technical Framework.

An actor that creates metadata may add Extra Metadata Attributes. An actor that receives metadata shall not generate an error due to the presence of Extra Metadata Attributes.

Some IHE transactions require that a receiving actor take specific actions if the submission contains Extra Metadata Attributes. Otherwise, the receiving actor may ignore them.

The ‘name’ attribute of the ebRIM Slot for an Extra Metadata Attribute shall conform to the following rules:

• The value of ‘name’ shall be a valid URN.
• The prefix 'urn:ihe:' shall not be used.

Note that ebRIM requires that the name of a Slot be unique within the containing object (DocumentEntry, SubmissionSet, Folder, or Association).

An example of coding an Extra Metadata Attribute for DocumentEntry is shown below:

4.2.3.1.7 Metadata Attribute Data types

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

For the data types derived from HL7 standards, IHE Document Sharing profiles require that the data be encoded according to HL7 encoding rules and that the default HL7 separators in Table 4.2.3.1.7-1 be used to represent the structure of HL7 v2.5 data types:

Table 4.2.3.1.7-1: HL7 Separators

HL7 Separators
Field Separator	|
Component Separator	^
Subcomponent Separator	&
Repetition Separator	~
Escape Character	\

The special character escape sequences (\F\, \S\, \R\, \T\, and \E\) shall be used to encode HL7 separators and the escape character. The escape sequences for formatting (\H\, \N\) and locally defined escape sequences (\Zdddd\) shall not be included for these data types.

For the data types derived from HL7 standards, Document Sharing actors shall not enforce any length constraints specified by the HL7 standards.

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

Data Type	Source Standard	Encoding Specification
Code	ITI TF	See Section 4.2.3.1.2.
Coded String	ITI TF	A coded value data type that can be communicated in one string. It combines a Code and a Code System ID in the following form: Code^^^&CodeSystemID&ISO The Code is a character sequence defined by the Code System. The CodeSystemID is a unique identifier for the code system, using the ISO Object Identifier format (see OID below). This data type shall be treated according to HL7 encoding rules described above. Note that the '&' character must be properly encoded in the XML content.
CX	HL7 V2.5 Identifier	This is an identifier. HL7 Identifier type CX consists of several components, but this specification restricts them to the use of two components, the Id Number, and the Assigning Authority (AA). The Assigning Authority identifies the "domain" over which the Id Number represents a unique entity. Furthermore, the AA is characterized by a Universal Id and Universal Id Type. In Document Sharing profiles, ISO Object Identifiers (see OID below) must be used as Universal Id. Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
CXi	HL7 V2 Identifier	This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components. CXi.1 shall be present and hold the identifier value. This component may exceed the HL7 conformance length of 15 characters. CXi.2 and CXi.3 shall be empty. CXi.4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. Either Universal ID with Universal ID Type or Namespace ID is permitted. CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value. No other components shall be present. The following IHE values for CXi.5 (Identifier Type Codes) are defined: urn:ihe:iti:xds:2013:uniqueId This code shall be used when the identifier is a uniqueID from Document Sharing metadata attribute. For example if uniqueID equals “1.3.6367.3.7^11379”, then the CXi value is 11379^^^&1.3.6367.3.7&ISO^urn:ihe:iti:xds:2013:uniqueId urn:ihe:iti:xds:2013:accession This code shall be used when the identifier is an accession number. It shall contain The accession number and for accession values that are not globally unique, the Assigning Authority shall be included. For example when the accession number has a value of “2013001” and the assigning authority is “1.2.3.4.5.6" then the CXi value is 2013001^^^&1.2.3.4.5.6&ISO^urn:ihe:iti:xds:2013:accession urn:ihe:iti:xds:2013:referral Referral number and assigning authority shall be present. For example: 134467699^^^&2.999.1.2.3.4&ISO^urn:ihe:iti:xds:2013:referral urn:ihe:iti:xds:2013:order Order number and assigning authority shall be present. For example: 134467653^^^&1.2.3.4.5.42.1&ISO^urn:ihe:iti:xds:2013:order urn:ihe:iti:xdw:2013:workflowInstanceId This code shall be used when the identifier is an XDW workflow identifier. The workflow identifier shall be an OID. Only the CXi.1 and CXi.5 components shall be present: For example, if the workflow identifier is “2.16.840.1” the CXi value is: 2.16.840.1^^^^urn:ihe:iti:xdw:2013:workflowInstanceId urn:ihe:iti:xds:2016:studyInstanceUID This code shall be used when the identifier is a DICOM Study Instance UID. CXi.1 shall contain the value of Study Instance UID. Only the CXi.1 and CXi.5 components shall be present. For example when the Study Instance UID has a value of “1.2.3.45.678” then the CXi value is 1.2.3.45.678^^^^urn:ihe:iti:xds:2016:studyInstanceUID urn:ihe:iti:xds:2015:encounterId Encounter identifier (also known as visit number) and assigning authority shall be present. For example: 245348841^^^&1.2.840.113619.6.197&ISO^urn:ihe:iti:xds:2015:encounterId Note that the '&' character must be properly encoded in the XML content.
DTM	HL7 V2.5 Date Time	This is a date/time value, represented as precisely as possible. All date time values in the registry are stored using Coordinated Universal Time [UTC]. "UTC" implies that time shall be converted from/to the local time. The format of these values is defined as the following regular expression: YYYY[MM[DD[hh[mm[ss]]]]] Where: YYYY is the four digit year i.e., 2006 MM is the two digit month 01-12, where Jan is 01, Feb is 02, etc. DD is the two digit day of the month 01-31 HH is the two digit hour, 00-23, where 00 is midnight, 01 is 1 am, 12 is noon, 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 In situations where systems distinguish between strings and numbers, the data type of DTM in document sharing metadata shall be handled as a number. Note that this means that only years between 1000 and 9999 inclusive are supported in document sharing metadata, since the year portion is fixed to 4 digits and the numeric data type prevents the use of leading zeros.
Field	HL7 V2.5 Message Segment	Specified as the HL7 field identifier, followed by a pipe (|) and then the data value characterized as a corresponding HL7 V2.5 data type as defined in HL7 standard. Note that if a Document Sharing data type is based on an HL7 data type, then the Document Sharing data type is used to represent the value. If the HL7 field’s segment definition allows repetitions, then they may be used in this context as well. When using HL7 repetitions, they shall be encoded using the HL7 repetition separator ‘~’. Individual Document Sharing metadata attributes using this data type may define additional ways of implementing repetitions. An example of an HL7 field Patient Identifier List (the third field of PID segment) containing repetitions is as follows:                PID-3|D\E\TP-1^^^&1.3.6&ISO~XTP-1^^^&1.3.11&ISO Note that the '&' character must be properly encoded in the XML content.
Identifier	See referenced data types	A globally unique identifier. This may be one of OID, URI, UUID (as defined in this table) or any other format that employs effective mechanisms to ensure global uniqueness.
Integer	W3C XML Schema Part 2	XML Schema Part 2: Data Types Section 3.3.13.
MIME Type	RFC2046	https://www.iana.org/assignments/media-types
OID	ISO Object Identifier	An ISO Object identifier. Made up of characters from the set [0‑9.]. It must start with an integer, and is followed by one or more additional integer values, separated by periods. Integers are characterized without leading 0 digits unless the value is zero. (e.g., 2.999.2005.3.7) In the attribute tables below, when an OID format is specified, it shall follow the assignment and format rules defined for unique IDs in ITI TF-2: Appendix B.
OID URN	RFC3061. OID in URN syntax	See RFC3061. An example is urn:oid:2.999.2005.3.7.
Predefined URN	RFC2141	Specific URNs are defined and assigned in this framework. An example is urn:ihe:iti:2007:ResponseStatusType:PartialSuccess
SHA1	RFC3174	Document hash calculated with SHA1 algorithm. The encoding is the Lexical Representation of hexBinary ([0-9a-fA-F]).
String	XML	XML Schema Part 2: Data Types Section 3.2.1.
URI	RFC2616	Uniform Resource Identifier
UTF-8	RFC3629	Unicode standard
UUID	RFC4122	A DCE Universally Unique Identifier, represented in registry attributes using the URN syntax for UUIDs e.g.,urn:uuid:9e0110f8-4748-4f1e-b0a8-cecae32209c7 Some Document Sharing profiles may allow use of symbolic Ids in certain conditions or locations.
XCN	HL7 V2.5 Extended Person Name	This data type describes a person (or in some cases, a software agent) along with an identifier by which they are known in some domain (e.g., the XDS affinity domain). It is based on the HL7 v2.5 XCN data type containing: Identifier Last Name First Name Second and Further Given Names Suffix Prefix Assigning Authority Note: Last Name should be used to convey a software agent name. All of the HL7 v2.5 fields may be specified as optional components with the following restrictions: At least the last name or an identifier shall be present. Inclusion of other components is optional provided the slot value length restrictions are not exceeded (see Section 4.2.3.1.1). If component 1 (Id Number) is specified, component 9 (Assigning Authority) shall be present if available, unless component 1 is already globally unique (e.g., an OID). The XCN Component 9 is subject to the same the restrictions as defined for the CX data type component 4. Thus: the first subcomponent shall be empty, the second subcomponent must be an ISO OID (e.g.,2.999.6.197), and the third subcomponent shall be ‘ISO’. Any empty component shall be treated by the Document Registry as not specified. Trailing delimiters are recommended to be trimmed off. Receiving actors shall ignore trailing delimiters. An example of person name with Id number using this data type is as follows:       11375^Welby^Marcus^J^Jr. MD^Dr^^^&2.999.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
XON	HL7 V2.5 Organization Name	This type provides the name and identification of an organization. This specification restricts the coding to the following fields: XON.1 – Organization Name – this field is required XON.6.2 – Assigning Authority Universal Id – this field is required if XON.10 is valued and not an OID XON.6.3 – Assigning Authority Universal Id Type – this field is required if XON.10 is valued and not an OID and shall have the value "ISO" XON.10 – Organization Identifier – this field is optional No other fields shall be specified. The XON data type in Document Sharing metadata results in a valid encoding of an HL7 v2.5 XON encoding, with the exception of length limitations. Component length restrictions are unobserved; 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 the organization’s OID. If the Organization Identifier is not an OID, the metadata 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 organization. Examples:    Some Hospital    Some Hospital^^^^^^^^^2.999.1.2.3.4.5.6.7.8.9.1789.45    Some Hospital^^^^^&2.999.1.2.3.4.5.6.7.8.9.1789&ISO^^^^45 Note that the '&' character must be properly encoded in the XML content.
XTN	HL7 V2.5 Extended Telecommunications Number Chapter 2A Section 89	This type provides the telecommunications address of an entity (for example author, intended recipient). This specification restricts the use to the following fields: For phone numbers: XTN.2 – Indicates the type of phone number (Optional) XTN.3 – The type of telecommunication address (Required) XTN.5 – Country Code (Optional) XTN.6 – Area/City Code (Optional) XTN.7 – Subscriber Number (Required) XTN.8 – Extension (Optional) For email addresses: XTN.2 – Optional. If present, SHALL have the value "NET". XTN.3 – shall have the value "Internet". XTN.4 – the telecommunications address (Required), e.g., name@example.com No other fields shall be specified. The XTN data type in Document Sharing metadata results in a valid encoding of an HL7 V2.5 XTN data type. Use of ITU E.123 notation for telephone numbers is recommended. Example:               ^^Internet^radiology@healthcare.example.org (e-mail address)               ^PRS^PH^^31^^(042) 1123 4567 (national phone number)               ^PRS^PH^^^^+31 42 1123 4567 (international phone number)

4.2.3.1.8 General format of DocumentEntry, Folder and SubmissionSet attribute tables

Each metadata attribute definition table below has five columns:

1. The first column contains the name used to refer to the attribute in IHE documentation. It is not always related to the way the attribute is coded in ebRIM.
2. The second column contains a brief description of the attribute.
3. The third column identifies how the value of the attribute is coded. Table 4.2.3.1.7-2 lists all the possible types of data. In isolated instances a value may be complex enough to require a separate section to describe, in which case a reference to that section is included. For example, author.
4. The fourth column describes where to find the encoding of the attribute within the DocumentEntry/Folder/SubmissionSet. In other words, how the value of the attribute is held within the enclosing object. The possible values in this column are:

• ebRIM Classification – indicates that the attribute is coded as a classification object, (see Section 4.2.3.1.2 ).
• XML attribute – indicates that the attribute is the value of an XML attribute of the enclosing object. For example:

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

Showing the entryUUID attribute coded as a value of the id XML attribute of the ExtrinsicObject representing the DocumentEntry. Note that the name of the attribute – entryUUID – is not referenced in its actual representation.

• ebRIM Slot – indicates that the attribute is encoded within a slot. For example:

Showing the creationTime attribute within a Slot of the ExtrinsicObject representing the Document Entry. In this case the name of the slot is the attribute name.

• ebRIM ExternalIdentifier – indicates the value is held within an ExternalIdentifier object, using the XML element rim:ExternalIdentifier, providing an additional identifier to a registry object (see Section 4.2.3.1.3 ).
• ebRIM Name – indicates this attribute is held in an ebRIM Name object. For example, the title attribute is:

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

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

4.2.3.1.9 Metadata Attribute Cardinality

Metadata attributes have several dimensions of cardinality.

One dimension is whether or not any value is required, or the attribute is optional. This dimension is dependent on the profile, actor and transaction in which the attribute is being specified and is detailed in Section 4.3.

Another dimension is the required handling of the receiving actor. This is specified within each transaction.

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

4.2.3.1.10 classificationScheme vs. classificationNode

Classification elements in ebRIM use one of two attributes:  classificationScheme and classificationNode.

The attributes serve two different purposes:

(1) classificationScheme

As the name suggests, the classificationScheme attribute specifies the category ("scheme") by which the referenced object is being classified. For example, classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" indicates that a DocumentEntry is being classified by practiceSetting. The classificationScheme does not indicate WHICH practiceSetting applies; that information is recorded elsewhere in the Classification element.

The use of classificationScheme corresponds with "external classifications", as described in ebRIM. This is the predominant type of classification in Document Sharing.

(2) classificationNode

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

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

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

4.2.3.2 DocumentEntry Attributes

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

Each attribute shown below is an attribute on the DocumentEntry object. The attribute name is defined with a prefix of the object type of DocumentEntry when referenced by other objects, for example DocumentEntry.patientId.

See Section 4.2.3.1.8 for the general format of DocumentEntry, Folder and SubmissionSet attribute tables.

Table 4.2.3.2-1: DocumentEntry Metadata Attribute Definition (previously Table 4.1-5)

DocumentEntry Metadata Attribute	Description	Data Type (Table 4.2.3.1.7-1)	Coding  (Section 4.2.3.1.8)	Detail (See Section)
author	The humans and/or machines that authored the document. This attribute contains the sub-attributes: authorInstitution, authorPerson, authorRole, authorSpecialty and authorTelecommunication.	See Section 4.2.3.2.1	ebRIM Classification	4.2.3.2.1
availabilityStatus	The lifecycle status of the DocumentEntry	Predefined URN	XML attribute	4.2.3.2.2
classCode	The code specifying the high-level use classification of the document type (e.g., Report, Summary, Images, Treatment Plan, Patient Preferences, Workflow).	Code	ebRIM Classification	4.2.3.2.3
comments	Comments associated with the document.	String	ebRIM Description	4.2.3.2.4
confidentialityCode	The code specifying the level of confidentiality of the document.	Code	ebRIM Classification	4.2.3.2.5
creationTime	The time the author created the document.	DTM	ebRIM Slot	4.2.3.2.6
entryUUID	A globally unique identifier used to identify the entry.	UUID	XML attribute	4.2.3.2.7
eventCodeList	This list of codes represents the main clinical acts, such as a colonoscopy or an appendectomy, being documented.	Code	ebRIM Classification	4.2.3.2.8
formatCode	The code specifying the detailed technical format of the document.	Code	ebRIM Classification	4.2.3.2.9
hash	The hash of the contents of the document.	SHA1 hash	ebRIM Slot	4.2.3.2.10
healthcareFacility TypeCode	This code represents the type of organizational setting of the clinical encounter during which the documented act occurred.	Code	ebRIM Classification	4.2.3.2.11
homeCommunityId	A globally unique identifier for a community.	OID URN	home XML attribute	4.2.3.2.12
languageCode	Specifies the human language of character data in the document.	String	ebRIM Slot	4.2.3.2.13
legalAuthenticator	Represents a participant within an authorInstitution who has legally authenticated or attested the document.	XCN	ebRIM Slot	4.2.3.2.14
limitedMetadata	Indicates whether the DocumentEntry was created using the less rigorous requirements of metadata as defined for the Metadata-Limited Document Source.	4.2.3.2.29	ebRIM Classification	4.2.3.2.29
mimeType	MIME type of the document.	MIME type	XML attribute	4.2.3.2.15
objectType	The type of DocumentEntry (e.g., On-Demand DocumentEntry).	UUID	XML attribute	4.2.3.2.30
patientId	The patientId represents the subject of care of the document.	CX	ebRIM ExternalIdentifier	4.2.3.2.16
practiceSettingCode	The code specifying the clinical specialty where the act that resulted in the document was performed (e.g., Family Practice, Laboratory, Radiology).	Code	ebRIM Classification	4.2.3.2.17
referenceIdList	A list of identifiers related to the document.	CXi	ebRIM Slot	4.2.3.2.28
repositoryUniqueId	The globally unique identifier of the repository where the document can be accessed.	OID	ebRIM Slot	4.2.3.2.18
serviceStartTime	The start time of the service being documented.	DTM	ebRIM Slot	4.2.3.2.19
serviceStopTime	The stop time of the service being documented.	DTM	ebRIM Slot	4.2.3.2.20
size	Size in bytes of the document.	Integer	ebRIM Slot	4.2.3.2.21
sourcePatientId	The sourcePatientId represents the subject of care’s medical record identifier (e.g., Patient Id) in the local patient identifier domain of the creating entity.	CX	ebRIM Slot	4.2.3.2.22
sourcePatientInfo	This attribute contains demographic information of the patient to whose medical record this document belongs.	Field	ebRIM Slot	4.2.3.2.23
title	The title of the document.	UTF-8	ebRIM Name	4.2.3.2.24
typeCode	The code specifying the precise type of document from the user perspective (e.g., LOINC code).	Code	ebRIM Classification	4.2.3.2.25
uniqueId	Globally unique identifier assigned to the document by its creator.	Identifier	ebRIM ExternalIdentifier	4.2.3.2.26
URI	The URI for the document.	URI	ebRIM Slot	4.2.3.2.27

4.2.3.2.1 DocumentEntry.author

Description:

Represents the humans and/or machines that authored the document. See Section 4.2.3.1.4 for details on creating the structure.

The classificationScheme shall be urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d

4.2.3.2.2 DocumentEntry.availabilityStatus

Description:

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

Approved   The document is available for patient care.

Deprecated   The document is obsolete.

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

Coding:

The format of the availabilityStatus value is a URN.

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

 

4.2.3.2.3 DocumentEntry.classCode

Description:

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

Coding:

There shall be exactly zero or one ebRIM Classification containing a classCode for any DocumentEntry. See Section 4.2.3.1.2 for a description of coding an ebRIM Classification. For the classCode metadata attribute, the classificationScheme shall be
urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a.

The following example specifies classCode=10160-0 with display name "History of Medication Use" and coding scheme "2.16.840.1.113883.6.1" for the DocumentEntry labeled "ExampleDocument".

 

4.2.3.2.4 DocumentEntry.comments

Description:

Contains comments associated with the document.

Coding:

Max length is unbounded.

The value of the comments attribute is coded in XML as the "value" attribute of the LocalizedString element within the ebRIM Description structure. There can be at most one ebRIM Description structure per DocumentEntry.

The following example shows a comment for the document.

4.2.3.2.5 DocumentEntry.confidentialityCode

Description:

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

The confidentialityCode can carry multiple vocabulary items. HL7 has developed an understanding of security and privacy tags that might be desirable in a Document Sharing environment, called HL7 Healthcare Privacy and Security Classification System (HCS). The following specification is recommended but not mandated by IHE, as the vocabulary bindings are an administrative domain responsibility. The use of this method is up to the policy domain such as the XDS Affinity Domain or other Trust Domain where all parties including sender and recipients are trusted to appropriately tag and enforce.

• [1…1] Confidentiality Security Classification Label Field
• [0…*] Sensitivity Security Category Label Field
• [0…*] Compartment Security Category Label Field
• [0…*] Integrity Security Category Label Field
• [0…*] Handling Caveat Security Category Field

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

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

When using the HL7 Healthcare Privacy and Security Classification System (HCS):

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

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

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

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

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

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

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

• Multiple values are all applicable to the content.

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

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

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

Coding:

Each confidentialityCode is coded within an ebRIM Classification object. See Section 4.2.3.1.2 for a description of coding an ebRIM Classification. There shall be zero or more ebRIM Classification containing a confidentiality code (some profiles require at least one). Multiple values of confidentialityCode are coded by specifying multiple classification objects. For the confidentialityCode metadata attribute, the classificationScheme shall be
urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f.

The following example shows two confidentialityCode values. It specifies normal confidentiality with code “N”, display name “Normal Clinical Data”, and coding scheme “2.16.840.1.113883.5.25”, and an obligation not to reuse with code ”NOREUSE”, display name “prohibit use beyond purpose of use”, and coding scheme “2.16.840.1.113883.1.11.20471", for the DocumentEntry labeled “ExampleDocument”.

4.2.3.2.6 DocumentEntry.creationTime

Description:

Represents the time the author created the document.

Coding:

Max length is 256 characters. The format of the creationTime value is DTM; see Table 4.2.3.1.7-2 for a description of DTM format.

The value is coded as a single value within an ebRIM Slot in the DocumentEntry.

The following example shows a creationTime of December 25, 2004 21:20:10 Coordinated Universal Time (UTC).

4.2.3.2.7 DocumentEntry.entryUUID

Description:

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

Coding:

The format of the entryUUID value is UUID. Certain Document Sharing transactions may allow symbolic Ids (anything that does not have the urn:uuid: prefix) to be used.

The value of the entryUUID is coded in the id XML attribute on the ExtrinsicObject representing the DocumentEntry. In the example below, the entryUUID is urn:uuid:a6e06ca8-0c75-4064-9e5c-88b9045a96f6.

 

4.2.3.2.8 DocumentEntry.eventCodeList

Description:

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

Coding:

The eventCodeList is coded with ebRIM Classification objects. See Section 4.2.3.1.2 for a description of coding an ebRIM Classification. There may be zero or more ebRIM Classifications containing a code and additional eventCode entries are coded by specifying multiple classification objects. For the eventCodeList metadata attribute, the classificationScheme shall be urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4.

The following example specifies an eventCode="ExampleeventCode" with display name "eventCodeDisplayName" and coding scheme "Example Event Code Scheme" for the DocumentEntry labeled "ExampleDocument".

4.2.3.2.9 DocumentEntry.formatCode

Description:

The code specifying the detailed technical format of the document. Along with the typeCode, it should provide sufficient information to allow potential consumer to know if it will be able to process the document.

The mimeType indicates the base format; the formatCode indicates the detailed-level technical structure. Together with the mimeType, the formatCode used shall be sufficiently specific to ensure processing/display by identifying a document encoding, structure and template (e.g., for a CDA Document, the fact that it complies with a CDA schema, possibly a template and the choice of a content-specific style sheet). The formatCode alone is often sufficiently specific, but an actor that consumes metadata should not assume that it is.

The formatCode is often an indicator of the IHE Document Content Profile to which the document conforms.

The mimeTypeSufficient formatCode of EV("urn:ihe:iti:xds:2017:mimeTypeSufficient", "1.3.6.1.4.1.19376.1.2.3") may be used when the mimeType is sufficient to identify the technical format of the document.

Format codes may be specified by multiple organizations. Format codes for Document Content profiles defined by the ITI domain shall be in URN format and have names with the prefix

urn:ihe:iti:

Format codes defined by other IHE domains shall have names with the prefix

urn:ihe:’domain initials’:

The IHE-managed codes and value set for formatCode are published on http://profiles.ihe.net/fhir/ihe.formatcode.fhir/.

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

The canonical URI that identifies a FHIR StructureDefinition “profile” may be used as a formatCode. For example there is a “Clinical Document” FHIR StructureDefinition profile on the Composition Resource that has the canonical URI: http//hl7.org/fhir/StructureDefinition/clinicaldocument.

Coding:

There shall be zero or one ebRIM Classification containing a formatCode. See Section 4.2.3.1.2 for a description of coding an ebRIM Classification. For the formatCode metadata attribute, the classificationScheme shall be urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d. Any valid URN may be used as a formatCode.

The following example using the XDS-SD document content profile specifies formatCode="urn:ihe:iti:xds-sd:pdf:2008" with display name "XDS-Scanned Documents" and coding scheme "1.3.6.1.4.1.19376.1.2.3" for the DocumentEntry labeled "ExampleDocument".

4.2.3.2.10 DocumentEntry.hash

Description:

The hash of the contents of the document.

The hash attribute can be used to identify accidental document corruption, mistaken duplicate IDs, etc. The SHA1 algorithm and hash attribute should not be used for identifying malicious alterations.

Note: Environments requiring a higher level of protection against document modification should consider using a digital signature such as defined in the Digital Signature (DSG) Profile (see ITI TF-1: 37 ).

Coding:

Max length is 256 characters. The format of the hash value is SHA1 hash; see Table 4.2.3.1.7-2 for a description of SHA1.

The value is coded as a case-insensitive single value within an ebRIM Slot in the DocumentEntry.

The following example shows a hash of da39a3ee5e6b4b0d3255bfef95601890afd80709.

4.2.3.2.11 DocumentEntry.healthcareFacilityTypeCode

Description:

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

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

Coding:

There shall be zero or one ebRIM Classification containing a healthcareFacilityTypeCode. See Section 4.2.3.1.2 for a description of coding an ebRIM Classification. For the healthcareFacilityTypeCode metadata attribute the classificationScheme shall be urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1.

The following example specifies healthcareFacilityTypeCode = "ExamplehealthcareFacilityTypeCode " with display name "healthcareFacilityTypeCodeDisplayName " and coding scheme "Example Healthcare Facility Scheme" for the DocumentEntry labeled "ExampleDocument".

 

4.2.3.2.12 DocumentEntry.homeCommunityId

Description:

A globally unique identifier for a community where the DocumentEntry and document can be accessed.

Coding:

Contained in the ebRS ExtrinsicObject home attribute for the ExtrinsicObject that corresponds to the DocumentEntry. It is an OID URN (see Table 4.2.3.1.7-2). The OID is limited to 64 characters.

See ITI TF-2: 3.18.4.1.2.3.8 and ITI TF-2: 3.38.4.1.2.1.

4.2.3.2.13 DocumentEntry.languageCode

Description:

Specifies the human language of character data in the document.

Coding:

Max length is 256 characters. The values of the attribute are language identifiers as described by the IETF (Internet Engineering Task Force) RFC5646.

The value is coded as a single value within an ebRIM Slot in the DocumentEntry.

The following example shows a languageCode of en-CA.

4.2.3.2.14 DocumentEntry.legalAuthenticator

Description:

Represents a participant within an authorInstitution who has legally authenticated or attested the document. Legal authentication implies that a document has been signed manually or electronically by the legalAuthenticator.

Coding:

Max length is 256 characters. This attribute shall be absent if not applicable. The value is coded as a single value within an ebRIM Slot in the DocumentEntry. The format of the legalAuthenticator value is XCN; see Table 4.2.3.1.7-2 for description of XCN format.

The following example shows a legalAuthenticator of ^Welby^Marcus^^^ Dr^MD.

4.2.3.2.15 DocumentEntry.mimeType

Description:

MIME type of the document in the Repository.

Coding:

Max length is unbounded. Shall have only a single value. Encoded in the ebRS ExtrinsicObject mimeType attribute for the ExtrinsicObject that corresponds to the DocumentEntry. See ebRS Schema RIM.XSD.

In this example, the MIME type is “application/pdf”.

4.2.3.2.16 DocumentEntry.patientId

Description:

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

Within a submission request, the value of patientId of the DocumentEntries shall match that of the SubmissionSet.

Coding:

The format of the patientId value is CX; see Table 4.2.3.1.7-2.

It shall contain two parts:

• Assigning Authority Domain Id (organization that issued the Id)
• An Id from the above Assigning Authority.

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

Coded as an ebRIM ExternalIdentifier. See Section 4.2.3.1.3 for a description of coding an ebRIM ExternalIdentifier. This element references, and is contained in, the ExtrinsicObject representing the DocumentEntry. There shall be zero or one patientId value.

In the example below, the patientId is 6578946^^^&1.3.6.1.4.1.21367.2005.3.7&ISO where 6578946 is the ID and 1.3.6.1.4.1.21367.2005.3.7 is the assigning authority.

4.2.3.2.17 DocumentEntry.practiceSettingCode

Description:

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

Coding:

There shall be zero or one ebRIM Classification containing a practiceSettingCode. See Section 4.2.3.1.2 for a description of coding an ebRIM Classification. For the practiceSettingCode metadata attribute, the classificationScheme shall be
urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead.

The following example specifies practiceSettingCode="ExamplepracticeSettingCode" with display name "ExamplepracticeSettingCodeDisplayName" and coding scheme "Example Practice Setting Code Scheme" for the DocumentEntry labeled "ExampleDocument".

4.2.3.2.18 DocumentEntry.repositoryUniqueId

Description:

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

Coding:

Max length is 64 characters. The format of the repositoryUniqueId value is OID.

The value is coded as a single value within an ebRIM Slot in the DocumentEntry.

The following example shows a repositoryUniqueId of 1.3.6.1.4.5.

 

4.2.3.2.19 DocumentEntry.serviceStartTime

Description:

Represents the start time of the service being documented (clinically significant, but not necessarily when the document was produced or approved). This may be the encounter time in case the service was delivered during an encounter.

There are cases where it may be appropriate to omit this attribute, for example: the document is not episodic (e.g., an On-Demand “Active Problem List”), or the service start time is not known.

Note: If needed, other times associated with the document, such as time of approval, are to be recorded within the document.

Coding:

Max length is 256 characters. The format of the serviceStartTime value is DTM; see Table 4.2.3.1.7-2 for a description of DTM format.

The value is coded as a single value within an ebRIM Slot Attribute in the DocumentEntry.

The following example shows a serviceStartTime of December 25, 2004 21:20:10 Coordinated Universal Time (UTC).

4.2.3.2.20 DocumentEntry.serviceStopTime

Description:

Represents the stop time of the service being documented (clinically significant, but not necessarily when the document was produced or approved). This may be the encounter time in case the service was delivered during an encounter.

There are cases where it may be appropriate to omit this attribute, for example: the document is not episodic (e.g., an On-Demand “Active Problem List”), the document is for an episode that is still in progress, or the end time is not known.

If the service happens at a point in time, this attribute shall contain the same value as the serviceStartTime.

Coding:

Max length is 256 characters. The format of the serviceStopTime value is DTM; see Table 4.2.3.1.7-2 for a description of DTM format.

The value is coded as a single value within an ebRIM Slot Attribute in the DocumentEntry.

The following example shows a stop time of December 25, 2004 21:20:10 Coordinated Universal Time (UTC).

4.2.3.2.21 DocumentEntry.size

Description:

Size in bytes of the byte stream that comprises the document.

Coding:

Max length of the encoded size is 256 characters. Coded as an ebRIM Slot. Shall have only a single value.

The following example shows a size value of 3654 bytes.

4.2.3.2.22 DocumentEntry.sourcePatientId

Description:

The sourcePatientId represents the subject of care’s medical record identifier (e.g., Patient Id) in the local patient identifier domain of the creating entity.

Coding:

Max length is 256 characters. Coded as an ebRIM Slot with the value encoded according the CX datatype (see Table 4.2.3.1.7-2). Shall contain zero or one value.

4.2.3.2.23 DocumentEntry.sourcePatientInfo

Description:

This attribute contains demographics information at the time of submission of the patient to whose medical record this document belongs.

This information typically includes: the patient first and last name, sex, and birth date. Policies at the creating entity may require more or less specific information and format.

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

Coding:

Coded as an ebRIM Slot. If present, each rim:Value contains a Field (see Table 4.2.3.1.7-2 for a description of the Field datatype). Multiple rim:Value elements may exist for the same field name as a way to implement repetition; there shall be at most one rim:Value element for each of the PID-7 and PID-8 fields. Only field defined for the PID segment shall be used.

Maximum length of each rim:Value is 256 characters. The sourcePatientInfo attribute should include:

• PID-3 - (source patient identifier list)
• PID-5 - (source patient name)

• If multiple patient names are present, then PID-5.7 (Name Type Code) and PID-5.8 (Name Representation Code) should be valued in each entry.

• PID-7 - (source patient date of birth)
• PID-8 - (source patient gender)

The sourcePatientInfo attribute should not include values for PID-2 (patient id), PID-4 (alternate patient id), PID-12 (country code), or PID-19 (social security number).

Example 1:

This example illustrates several of the encoding rules:

• In the first PID-3 entry, the use of the HL7 escape sequence \E\, representing the ”\” character (see Section 4.2.3.1.7).
• The encoding of two patient identifiers in the first PID-3 entry and a third patient identifier in the second PID-3 entry (see above and definition of Field in Table 4.2.3.1.7-2).
• In the PID-3.4 values, the XML encoding of the "&" subcomponent separators (see definition of Field in Table 4.2.3.1.7-2).

Example 2:

This example illustrates encoding of a patient name with alphabetic, phonetic and ideographic representations of the legal name using both the HL7 repetition separator as well as multiple PID-5 entries.

4.2.3.2.24 DocumentEntry.title

Description:

Represents the title of the document.

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

Coding:

The format of DocumentEntry.title shall be any string of length less than 128 characters.

DocumentEntry.title is represented in ebXML as the "value" attribute of the LocalizedString element within the ebRIM Name structure. There can be only one ebRIM Name structure per DocumentEntry.

The following example shows a title for the DocumentEntry.

4.2.3.2.25 DocumentEntry.typeCode

Description:

The code specifying the precise type of document from the user’s perspective. It is recommended that the creating entity draw these values from a coding scheme providing a fine level of granularity such as LOINC.

Coding:

Coded as an ebRIM classification. See Section 4.2.3.1.2 for a description on creating classifications. Shall have zero or one value.

The following example specifies typeCode="ExampletypeCode" with display name "typeCodeDisplayName " and coding scheme " Example Type Code Scheme " for the DocumentEntry labeled "ExampleDocument".

4.2.3.2.26 DocumentEntry.uniqueId

Description:

Globally unique identifier assigned to the document by its creator. This value may come from inside the document, e.g., for a CDA, ClinicalDocument/id.

A DocumentEntry representing a single document is identified by the uniqueId attribute; the linkage between DocumentEntry and the document it represents is made with the uniqueId attribute.

This unique identifier may be used in other documents to reference this document.

Two documents MAY be assigned the same uniqueId if the documents have the same byte sequence, but they SHALL NOT be assigned the same uniqueId if the documents have different byte sequences when communicated via a Document Sharing protocol. The size and hash metadata attributes allow for a quick comparison, so it is adequate to treat two documents as having the same byte sequence if their size and hash attributes are the same.

For formats where different byte sequences can be functionally equivalent (XML, for example, where whitespace between elements is ignored), it is important to note that documents with different byte sequences SHALL have different uniqueIds even if they are functionally equivalent when communicated via a Document Sharing protocol.

Coding:

The format of the DocumentEntry.uniqueId value is Identifier (see Table 4.2.3.1.7-2).

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

Document creators should use one of the following formats for the uniqueId:

• OID in dot notation (see OID in Table 4.2.3.1.7-2).
• UUID URN-encoded (see UUID in Table 4.2.3.1.7-2).
• URI (see URI in Table 4.2.3.1.7-2).
• For documents using HL7v3 Instance Identifiers (e.g., CDAs) with an extension attribute, the uniqueId should be a serialization of the root and extension attributes in the form root^extension. The HL7v3 Instance Identifier URN encoding (using the namespace urn:hl7ii) should not be used.

All guidance regarding the structure and format of the identifier is meant to support document creators in following best practices for identifier management. From the perspective of all other actors, the uniqueId should be considered an opaque string.

Note: Some IHE profiles may restrict the length and format of this attribute.

4.2.3.2.27 DocumentEntry.URI

Description:

The URI attribute contains the URI for the document.

Coding:

Max length is 256 characters. Coded as an ebRIM Slot. Shall have only a single value.

For example, in the XDM Profile the URI attribute will contain a relative URI to the document (see ITI TF-2: 3.32.4.1.2.2 ).

4.2.3.2.28 DocumentEntry.referenceIdList

Description:

These Identifiers may be internal or external identifiers, e.g., Identifiers may be Accession Numbers, Order Numbers, Referral Request Identifiers, XDW Workflow Instance Identifiers, etc. The referenceIdList contains Identifiers CXi encoded, as specified in Table 4.2.3.1.7-2.

Coding:

Coded as an ebRIM Slot. May have multiple rim:Value.

Maximum length of each rim:Value is 256 characters.

The name of the slot in the metadata shall be urn:ihe:iti:xds:2013:referenceIdList.

For example encoding two values in the referenceIdList:

4.2.3.2.29 DocumentEntry.limitedMetadata

Description:

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

Coding:

The Document Entry is flagged using an ebRIM Classification with a classificationNode of urn:uuid:ab9b591b-83ab-4d03-8f5d-f93b1fb92e85.

The following example marks the “DocEntry” Document Entry as created via the less rigorous metadata requirements.

4.2.3.2.30 DocumentEntry.objectType

Description:

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

Coding:

Max length is unbounded. The format of the objectType value is UUID.

The value of the objectType is coded in the objectType XML attribute on the ExtrinsicObject representing the DocumentEntry. In the example below, the objectType is urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1 and reflects a stable DocumentEntry.

4.2.3.3 SubmissionSet Attributes

The following metadata elements shall be used to describe a SubmissionSet.

Each attribute shown is an attribute on the RegistryPackage object defining the SubmissionSet. The attribute name is defined with a prefix of the object type of SubmissionSet when referenced by other objects, for example SubmissionSet.sourceId.

See Section 4.2.3.1.8 for the General format of DocumentEntry, Folder and SubmissionSet attribute tables.

Table 4.2.3.3-1: Submission Set Metadata Attribute Definitions (previously Table 4.1-6)

SubmissionSet Metadata Attribute	Description	Form	Coding	Detail (See Section)
author	The humans and/or machines that authored the SubmissionSet. This attribute contains the sub-attributes: authorInstitution, authorPerson, authorRole, authorSpecialty, authorTelecommunication.	See Section 4.2.3.3.1	ebRIM Classification	4.2.3.3.1
availabilityStatus	The lifecycle status of the SubmissionSet.	Predefined URN	XML attribute	4.2.3.3.2
comments	Comments associated with the SubmissionSet.	String	ebRIM Description	4.2.3.3.3
contentTypeCode	The code specifying the type of clinical activity that resulted in placing the associated content in the SubmissionSet.	Code	ebRIM Classification	4.2.3.3.4
entryUUID	A globally unique identifier used to identify the entry.	UUID	XML attribute	4.2.3.3.5
homeCommunityId	A globally unique identifier for a community.	OID URN	home XML attribute	4.2.3.3.6
intendedRecipient	The organizations or persons for whom the SubmissionSet is intended.	See Section 4.2.3.3.7	ebRIM Slot	4.2.3.3.7
limitedMetadata	A flag that the associated SubmissionSet was created using the less rigorous metadata requirements as defined for the Metadata-Limited Document Source.	See Section 4.2.3.3.13	ebRIM Classification	4.2.3.3.13
patientId	The patientId represents the primary subject of care of the SubmissionSet.	CX	ebRIM ExternalIdentifier	4.2.3.3.8
sourceId	Identifier of the entity that contributed the SubmissionSet.	OID	ebRIM ExternalIdentifier	4.2.3.3.9
submissionTime	Point in time at the creating entity when the SubmissionSet was created.	DTM	ebRIM Slot	4.2.3.3.10
title	The title of the SubmissionSet.	UTF-8	ebRIM Name	4.2.3.3.11
uniqueId	Globally unique identifier for the SubmissionSet assigned by the creating entity.	OID	ebRIM ExternalIdentifier	4.2.3.3.12

4.2.3.3.1 SubmissionSet.author

Description:

Represents the humans and/or machines that authored the SubmissionSet. See Section 4.2.3.1.4 for details on creating the structure.

The classificationScheme shall be urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d.

4.2.3.3.2 SubmissionSet.availabilityStatus

Description:

Represents the status of the SubmissionSet. Since the deprecation of SubmissionSets is not allowed, this value shall always be Approved.

Coding:

The availabilityStatus value shall be
urn:oasis:names:tc:ebxml-regrep:StatusType:Approved.

4.2.3.3.3 SubmissionSet.comments

Description:

Contains comments associated with the SubmissionSet.

Coding:

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

The following example shows a comment for the SubmissionSet.

4.2.3.3.4 SubmissionSet.contentTypeCode

Description:

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

Coding:

Coded as an ebRIM Classification. See Section 4.2.3.1.2 for a description of coding an ebRIM Classification. Shall have zero or one value

The following example specifies contentTypeCode="ExamplecontentTypeCode" with display name "Example contentTypeCodeDisplayName" and coding scheme "Example contentTypeCode Scheme" for the SubmissionSet labeled "ExampleSubmissionSet".

4.2.3.3.5 SubmissionSet.entryUUID

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

Coding:

The format of the entryUUID value is UUID. Certain Document Sharing transactions may allow symbolic Ids (any string that does not have the urn:uuid: prefix) to be used.

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

4.2.3.3.6 SubmissionSet.homeCommunityId

Description:

A globally unique identifier for a community.

Coding:

The ebRIM RegistryPackage home attribute for the RegistryPackage that corresponds to the SubmissionSet. It is an OID URN. See Table 4.2.3.1.7-2.

See ITI TF-2: 3.18.4.1.2.3.8 and ITI TF-2: 3.38.4.1.2.1.

4.2.3.3.7 SubmissionSet.intendedRecipient

Description:

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

Coding:

The format of the SubmissionSet.intendedRecipient value is XON|XCN|XTN where XON identifies the organization, XCN identifies a person and XTN identifies the telecommunications, see Table 4.2.3.1.7-2 for description of XON, XCN and XTN format. 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 the telecommunications address information is present.

The value is coded as zero or more rim:Value within a single ebRIM Slot in the SubmissionSet.

Maximum length of each rim:Value is 256 characters.

The following example shows two doctors from the same organization, another doctor without the organization details and another organization without the person details, and just a telecommunications address.

4.2.3.3.8 SubmissionSet.patientId

Description:

The patientId represents the primary subject of care of the SubmissionSet.

Coding:

The format of the patientId value is CX (see Table 4.2.3.1.7-2).

It shall contain two parts:

• Assigning Authority Domain Id (organization that issued the Id).
• An Id from the above Assigning Authority.

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

The value is coded within a single ebRIM ExternalIdentifier element (see Section 4.2.3.1.3 for a description of coding an ebRIM ExternalIdentifier) which references, and is contained in, the RegistryPackage representing the SubmissionSet. There shall be zero or one single patientId value.

In the example below the patientId is 6578946^^^&1.3.6.1.4.1.21367.2005.3.7&ISO where 6578946 is the ID and 1.3.6.1.4.1.21367.2005.3.7 is the assigning authority.

4.2.3.3.9 SubmissionSet.sourceId

Description:

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

Coding:

The format of the sourceId value is OID (see Table 4.2.3.1.7-2).

The value is coded within a single ebRIM ExternalIdentifier element (see Section 4.2.3.1.3 for a description of coding an ebRIM ExternalIdentifier) which references, and is contained in, the RegistryPackage representing the SubmissionSet. There shall be only a single sourceId value.

In the example below the sourceId is 1.3.6.1.4.1.21367.2005.3.7.

4.2.3.3.10 SubmissionSet.submissionTime

Description:

Represents the point in time at the creating entity when the SubmissionSet was created.

This shall be provided by the submitting system.

Coding:

Max length is 256. The format of the submissionTime value is DTM. See Table 4.2.3.1.7-2 for a description of DTM format.

The value is coded as a single value within an ebRIM Slot Attribute in the SubmissionSet.

The following example shows a submissionTime of December 25, 2004 21:20:10 Coordinated Universal Time (UTC).

4.2.3.3.11 SubmissionSet.title

Description:

Shall contain the title of the SubmissionSet.

Coding:

The format of SubmissionSet.title shall be any string of length less than 256 characters.

SubmissionSet.title is represented in ebXML as the "value" attribute of the LocalizedString element within the ebRIM Name structure. There can be only one ebRIM Name structure per SubmissionSet.

The following example shows a title for the SubmissionSet.

4.2.3.3.12 SubmissionSet.uniqueId

Description:

The globally unique identifier for the SubmissionSet assigned by the entity that contributed the SubmissionSet.

Coding:

The format of the SubmissionSet.uniqueId value is OID (see Table 4.2.3.1.7-2).

The value is coded within a single ebRIM ExternalIdentifier element which references, and is contained in, the RegistryPackage representing the SubmissionSet. See Section 4.2.3.1.3 for a description of coding an ebRIM ExternalIdentifier. There shall be only a single uniqueId value.

The following example shows a uniqueId of 1.2.3.4.5.

4.2.3.3.13 SubmissionSet.limitedMetadata

Description:

Indicates whether the SubmissionSet was created using the less rigorous requirements of metadata as defined for the Metadata-Limited Document Source.

Coding:

The SubmissionSet is flagged using an ebRIM Classification with a classificationNode of urn:uuid:5003a9db-8d8d-49e6-bf0c-990e34ac7707. Zero or one may be present.

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

4.2.3.4 Folder Attributes

The following metadata elements shall be used to describe a Folder. Each attribute shown below is an attribute on the RegistryPackage object defining the Folder. The attribute name is defined with a prefix of the object type of Folder when referenced by other objects, for example Folder.patientId. See Section 4.2.3.1.8 for the general format of DocumentEntry, Folder and SubmissionSet attribute tables.

Table 4.2.3.4-1: Folder Metadata Attribute Definitions (previously Table 4.1-7)

Folder Metadata Attribute	Description	Form	Coding	Detail (See Section)
availabilityStatus	The lifecycle status of the Folder.	Predefined URN	XML attribute	4.2.3.4.1
codeList	The set of codes specifying the type of clinical activities that resulted in placing DocumentEntry objects in the Folder.	Code	ebRIM Classification	4.2.3.4.2
comments	Comments associated with the Folder.	String	ebRIM Description	4.2.3.4.3
entryUUID	A globally unique identifier used to identify the entry.	UUID	XML attribute	4.2.3.4.4
homeCommunityId	A globally unique identifier for a community.	OID URN	XML attribute	4.2.3.4.5
lastUpdateTime	Most recent point in time that the Folder has been modified.	DTM	ebRIM Slot	4.2.3.4.6
limitedMetadata	A flag that the associated Folder was created using the less rigorous metadata requirements as defined for the Metadata-Limited	Section 4.2.3.4.10	ebRIM Classification	4.2.3.4.10
patientId	Represents the primary subject of care of the Folder.	CX	ebRIM ExternalIdentifier	4.2.3.4.7
title	The title of the Folder.	String	ebRIM Name	4.2.3.4.8
uniqueId	Globally unique identifier for the Folder.	OID	ebRIM ExternalIdentifier	4.2.3.4.9

4.2.3.4.1 Folder.availabilityStatus

Description:

Represents the status of the Folder. Since the deprecation of Folders is not allowed, this value shall always be Approved.

Coding:

Max length is unbounded. The availabilityStatus value shall be
urn:oasis:names:tc:ebxml-regrep:StatusType:Approved.

The example below shows the status attribute; however, this attribute is only returned on query, not set during any transaction.

 

4.2.3.4.2 Folder.codeList

Description:

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

Coding:

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

The following example specifies code = "Examplecode", display name "codeDisplayName" and coding scheme "Example codeList coding scheme" for the Folder with id "ExampleFolder".

4.2.3.4.3 Folder.comments

Description:

Comments associated with the Folder. Free form text or IHE profile-specified usage.

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

Coding:

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

The value of the comments attribute is coded in XML as the "value" attribute of the LocalizedString element within the ebRIM Description structure. There can be at most one ebRIM Description structure per DocumentEntry.

The following example shows a comment for the Folder.

4.2.3.4.4 Folder.entryUUID

Description:

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

Coding:

The format of the entryUUID value is UUID. Certain Document Sharing transactions may allow symbolic Ids (anything that does not have the urn:uuid: prefix) to be used.

The value of the entryUUID is coded in the id XML attribute on the RegistyPackage representing the Folder. In the example below, the entryUUID is urn:uuid:a6e06ca8-0c75-4064-9e5c-88b9045a9ab6.

4.2.3.4.5 Folder.homeCommunityId

Description:

A globally unique identifier for a community.

Coding:

The ebRS RegistryPackage home attribute for the RegistryPackage that corresponds to the Folder. It is an OID URN (see Table 4.2.3.1.7-2). The OID is limited to 64 characters.

See ITI TF-2: 3.18.4.1.2.3.8 and ITI TF-2: 3.38.4.1.2.1.

4.2.3.4.6 Folder.lastUpdateTime

Description:

Most recent point in time that the Folder has been modified by changing which DocumentEntry objects are associated with the Folder, or by changing the Folder’s metadata attributes. If the Folder has not been modified since creation, the lastUpdateTime contains the creation time.

Coding:

Max length is 256 characters. The format of the lastUpdateTime value is DTM and shall have at least “second” precision. See Table 4.2.3.1.7-2 for a description of DTM format.

The value is coded as a single value within an ebRIM Slot Attribute in the DocumentEntry.

The following example shows a last update of December 25, 2004 21:20:10 Coordinated Universal Time (UTC).

4.2.3.4.7 Folder.patientId

Description:

The patientId represents the primary subject of care of the Folder.

The value of the patientId shall be the same for all new documents of a SubmissionSet. All DocumentEntries placed in a Folder shall have the same patiendId as the Folder.

Coding:

Max length unbounded. The format of the patientId value is CX (see Table 4.2.3.1.7-2).

It shall contain two parts:

• Assigning Authority Domain Id (organization that issued the Id).
• An Id from the Assigning Authority.

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

4.2.3.4.8 Folder.title

Description:

Shall contain the title of the Folder.

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

Coding:

Max length is 256 characters. Encoded in the name element within the ebRS ExtrinsicObject for the document (see ebRS Schema RIM.XSD). Shall have only a single value.

In this example the title is “title”.

4.2.3.4.9 Folder.uniqueId

Description:

Globally unique identifier for the folder instance assigned by the creating entity.

Coding:

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

4.2.3.4.10 Folder.limitedMetadata

Description:

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

Coding:

The Folder is flagged using an ebRIM Classification with a classificationNode of urn:uuid:2c144a76-29a9-4b7c-af54-b25409fe7d03. Zero or one may be present.

The following example marks the “Folder” Folder as created via the less rigorous metadata requirements.

4.2.4 Success and Error Reporting

The ebXML RegistryResponse (for submission transactions) or ebXML AdhocQueryResponse (for query transactions) element will contain the status of the requested operation. The status attribute reflects the status of the operation and shall be one of the following values:

A response to a Submission Request that indicates success with no warnings is:

A response to a query request that indicates success with no warnings and no documents found is:

If the transaction resulted in warnings or errors, the ebXML RegistryResponse or ebXML AdhocQueryResponse shall contain an ebXML RegistryErrorList, which shall contain corresponding RegistryError elements.

The highestSeverity attribute may be present in a RegistryErrorList. If present, it shall contain the severity of the most severe of the RegistryErrors in the RegistryErrorList. See Section 4.2.4.2 for more details.

4.2.4.1 RegistryError Element

Registry Services schema (ebRS 3.0) defines the RegistryError element for reporting details of errors or warnings.

The RegistryError element contains the attributes in Table 4.2.4.1-1.

All IHE transactions that carry the RegistryError element shall return these attributes with each error reported.

The body of all RegistryError elements shall be empty.

Table 4.2.4.1-1: RegistryError Element Attributes

Attribute	Optionality	Value
errorCode	R	Shall be taken from Table 4.2.4.1-2 when one of those codes is appropriate. All extensions to the list of error codes shall be unique.
codeContext	R	Supplies additional detail for the errorCode
severity	R	Indicates the severity of the error. Shall be one of: urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning
location	O	Supplies the location of the error module name and line number or stack trace if appropriate.

An example response to a Submission Request that reports two errors and one warning is:

An example response to a query request that reports two errors is:

Table 4.2.4.2-1 through Table 4.2.4.2-4 control the reporting of errors for transactions that use the Document Sharing metadata attributes.

Table 4.2.4.1-2: Error Codes (previously Table 4.1-11)

Error Code	Discussion	Transaction (See Note 1)
DocumentQueued	A recipient queued the submission, for example, a manual process matching it to a patient.	P
InvalidDocumentContent	The recipient has rejected this submission because it detected that one of the documents does not match the metadata (e.g., formatCode) or has failed other requirements for the document content. When the RegistryError element contains this error code, the codeContext shall contain the uniqueID of the document in error. If multiple documents are in error, there shall be a separate RegistryError element for each document in error.	P
PartialAppendContentNotProcessed	An XDR Document Recipient did not process some part of the content. Specifically the parts not processed are Append semantics	P
PartialFolderContentNotProcessed	An XDR Document Recipient did not process some part of the content. Specifically the parts not processed are Folder semantics	P
PartialRelationshipContentNotProcessed	An XDR Document Recipient did not process some part of the content. Specifically the parts not processed are Relationship Association semantics.	P
PartialReplaceContentNotProcessed	An XDR Document Recipient did not process some part of the content. Specifically the parts not processed are Replacement semantics	P
PartialTransformNotProcessed	An XDR Document Recipient did not process some part of the content. Specifically the parts not processed are Transform semantics	P
PartialTransformReplaceNotProcessed	An XDR Document Recipient did not process some part of the content. Specifically the parts not processed are Transform and Replace semantics	P
UnresolvedReferenceException	The recipient cannot resolve an entryUUID reference in the transaction.	P, R
XDSDocumentUniqueIdError	The document associated with the uniqueId is not available. This could be because the document is not available, the requestor is not authorized to access that document or the document is no longer available.	RS, XGR
XDSDuplicateUniqueIdInRegistry	UniqueId received was not unique. UniqueId could have been attached to SubmissionSet or Folder. codeContext shall indicate which and the value of the non-unique uniqueId. This error cannot be thrown for DocumentEntry. See XDSNonIdenticalHash and XDSNonIdenticalSize.	P, R
XDSExtraMetadataNotSaved	This warning is returned if extra metadata was present but not saved.	P, R
XDSMissingDocument	DocumentEntry exists in metadata with no matching Document element	P
XDSMissingDocumentMetadata	Document element present with no matching DocumentEntry	P
XDSMissingHomeCommunityId	A value for the homeCommunityId is required and has not been specified	P, SQ, XGQ, RS, XGR
XDSNonIdenticalHash	Document being registered was a duplicate (uniqueId already in Document Registry) but hash does not match. The codeContext shall indicate uniqueId.	P, R
XDSNonIdenticalSize	Document being registered was a duplicate (uniqueId already in Document Registry) but size does not match. The codeContext shall indicate uniqueId.	P, R
XDSPatientIdDoesNotMatch	This error is thrown when the patient Id is required to match and does not. The codeContext shall indicate the value of the Patient Id and the nature of the conflict.	P, R
XDSRegistryBusy XDSRepositoryBusy	Too much activity	P, R, SQ, XGQ P, RS, XGR
XDSRegistryDeprecatedDocumentError	The transaction was rejected because it submitted an Association referencing a deprecated document.	P, R
XDSRegistryDuplicateUniqueIdInMessage XDSRepositoryDuplicateUniqueIdInMessage	A uniqueId value was found to be used more than once within the submission. The errorCode indicates where the error was detected. The codeContext shall indicate the duplicate uniqueId.	P, R
XDSRegistryError XDSRepositoryError	Internal Error The error codes XDSRegistryError or XDSRepositoryError shall be returned if and only if a more detailed code is not available from this table for the condition being reported. If one of these error codes is returned, the attribute codeContext shall contain details of the error condition that may be implementation-specific.	P, R, SQ, XGQ P, RS, XGR
XDSRegistryMetadataError XDSRepositoryMetadataError	Error detected in metadata. Actor name indicates where error was detected. (Document Recipient uses Repository error). codeContext indicates nature of problem.	P, R
XDSRegistryNotAvailable	Repository was unable to access the Registry	P
XDSRegistryOutOfResources XDSRepositoryOutOfResources	System Resources are currently unavailable to respond to the request. The request may be retried later.	P, R, SQ, XGQ P, RS, XGR
XDSReplaceFailed Note: This error code is deprecated. See ITI TF-2: 3.42.4.1.3.5.	Error detected by the Document Registry during a document replacement.	P, R
XDSResultNotSinglePatient	This error signals that a single request would have returned content for multiple Patient Ids	SQ, RS, XGQ, XGR
XDSStoredQueryMissingParam	A required parameter to a stored query is missing.	SQ, XGQ
XDSStoredQueryParamNumber	A parameter which only accepts a single value is coded with multiple values	SQ, XGQ
XDSTooManyResults	The request cannot be satisfied due to being overly broad or having a response that is too large. The request should be adjusted, e.g., narrowed to reduce the number of results.	SQ, XGQ, RS, XGR
XDSUnavailableCommunity	A community which would have been contacted was not available. See Note 2.	P, SQ, RS
XDSUnknownCommunity	A value for the homeCommunityId is not recognized	P, SQ, XGQ, RS, XGR
XDSUnknownPatientId	Patient Id referenced in the transaction is not known by the receiving actor. The codeContext shall include the value of patient Id in question.	SQ, P, R, XGQ
XDSUnknownRepositoryId	The repositoryUniqueId value could not be resolved to a valid document repository or the value does not match the repositoryUniqueId.	RS, XGR
XDSUnknownStoredQuery	The Query Id provided in the request is not recognized.	SQ, XGQ
UnavailableRecipient	An intendedRecipient which would have been contacted was not available.	P
UnknownRecipient	A value for intendedRecipient is not recognized.	P

Note 1:

P = Provide and Register-b

R = Register-b

SQ = Stored Query

RS = Retrieve Document Set

XGQ = Cross Gateway Query

XGR = Cross Gateway Retrieve

Note 2:

Two examples of the use of error code XDSUnavailableCommunity are:

1. A Cross Gateway Query, Cross Gateway Retrieve or Cross Gateway Document Set Provide 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 [ITI-18] or Retrieve Document Set [ITI-43] transaction. This would only apply when XDS Affinity Domain Option was used.

The ‘XDS Metadata Update’ and ‘Remove Metadata and Documents’ Trial Implementation Supplements add error codes to this table.

4.2.4.2 Error responses

The following tables explain the meaning of the status attribute in RegistryResponse and AdhocQueryResponse. Tables 4.2.4.2-1, 4.2.4.2-2, 4.2.4.2-3 and 4.2.4.2-4 below indicate whether the RegistryErrorList element shall be present and what other content shall be part of the response.

Table 4.2.4.2-1: Provide and Register Document Set-b [ITI-41] Responses

RegistryResponse status	RegistryErrorList element	Result
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success	May be present. If present will contain one or more RegistryError elements with warning severity, none with error severity.	All metadata defined in this volume, and documents were successfully registered. Extra metadata may or may not be saved, based on the presence of the XDSExtraMetadataNotSaved warning.
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure	Present, contains one or more RegistryError elements. At least one has error severity others may have warning severity.	Metadata and documents not stored

Table 4.2.4.2-2: Register Document Set-b [ITI-42] Responses

RegistryResponse status	RegistryErrorList element	Result
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success	May be present. If present will contain one or more RegistryError elements with warning severity, none with error severity	All metadata defined in this volume was successfully registered Extra metadata may or may not be saved, based on the presence of the XDSExtraMetadataNotSaved warning.
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure	Present, contains one or more RegistryError elements. At least one has error severity, others may have warning severity.	Metadata not stored

Table 4.2.4.2-3: Registry Stored Query [ITI-18] and Cross Gateway Query [ITI-38] Responses

AdhocQueryResponse status	RegistryErrorList element	Result
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success	May be present. If present will contain one or more RegistryError elements with warning severity; none with error severity	Results shall be returned. Results may contain zero or more entries.
urn:ihe:iti:2007:ResponseStatusType: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.
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure	Present, contains one or more RegistryError elements. At least one has error severity; others may have warning severity.	Results not returned

Table 4.2.4.2-4: Retrieve Document Set [ITI-43] and Cross Gateway Retrieve [ITI-39] Responses

Registry Response status	RegistryErrorList element	Result
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success	May be present. If present will contain one or more RegistryError elements with warning severity; none with error severity	All documents were successfully retrieved
urn:ihe:iti:2007:ResponseStatusType:PartialSuccess	Present, contains one or more RegistryError elements. At least one has error severity; others may have warning severity.	Some documents were successfully retrieved
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure	Present, contains one or more RegistryError elements. At least one has error severity; others may have warning severity.	No documents were successfully retrieved

4.2.5 Metadata Vocabulary

The UUIDs in the following tables shall be used in constructing and interpreting Document Sharing metadata.

4.2.5.1 Submission Set Object UUIDs

UUID	Use/meaning
urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd	SubmissionSet 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.2.5.2 Document Entry Object

UUID	Use/meaning
urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1	DocumentEntry objectType for Stable Document Entries
urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248	DocumentEntry objectType for On Demand  Document Entries
urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d	author External Classification Scheme
urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a	classCode External Classification Scheme
urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f	confidentialityCode External Classification Scheme
urn: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 Scheme
urn:uuid:f0306f51-975f-434e-a61c-c59651d33983	typeCode External Classification Scheme
urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab	uniqueId ExternalIdentifier

4.2.5.3 Folder Object

UUID	Use/meaning
urn:uuid:d9d542f3-6cc4-48b6-8870-ea235fbc94c2	Folder ClassificationNode
urn:uuid:1ba97051-7806-41a8-a48b-8fce7af683c5	codeList External Classification Scheme
urn:uuid:f64ffdf0-4b97-4e06-b79f-a52b38ec2f8a	patientId External Identifier
urn:uuid:75df8f67-9973-4fbe-a900-df66cefecc5a	uniqueId External Identifier

4.2.5.4 Association Object

UUID	Use/meaning
urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3	Association Documentation ClassificationNode