On NHIN Direct Content Packaging Workgroup calls and wiki page discussions, there've been several questions about XDS metadata. I post a response here to some of the issues raised because it is of general interest to all users of IHE XDS and related profiles.
The IHE Cross Enterprise Document Sharing (XDS) profile is a protocol for sharing clinical documents in health information exchanges used widely around the world. This profile, along with it’s sister profiles in the ITI Technical Framework: Cross Enterprise Document Sharing using Reliable Messaging (XDR), and Cross Enterprise Document Sharing using Media (XDM) use the same metadata to facilitate exchange.
This metadata is described using the ebXML RIM Standard. The original XDS.a protocol used ebRIM 2.1, but the newer version (XDS.b) uses the ebRIM 3.0 standard. The ebRIM standard was adopted by ISO as ISO Standard 15000-3: ebXML Registry Information Model.
The ebRIM object model (pdf) defines a number of fundamental data types and approximately 25 classes. Nine of these classes are used in an XDS Registry, but only seven are needed to communicate the metadata in the various IHE transactions. This metadata is all documented in volume 3 of the ITI Technical Framework (pdf). Of these seven classes, six derive from the ebXML Registry Object, and the seventh is the Slot class used to contain extensible metadata associated with Registry Objects.
A Registry Object has a few fundamental attributes including a name, description, status and a local identifier, and may be composed of additional slots and sets of classifications and external identifiers.
Slots are simply named string lists that can provide additional metadata for an object in a name and value list pair. A typical representation of a Slot in XDS metadata is:
‹Slot name='XDSMetadataObject.name'›
‹ValueList›‹Value›Metadata Value‹/Value›‹/ValueList›
‹/Slot›
External Identifiers in the ebRIM allow additional identifiers to be associated with a Registry Object. An External Identifier has a UUID that indicates the identification scheme being used. The XDS metadata includes a human readable name in the External Identifier to show which metadata element is represented. A typical representation of an External Identifier in XDS metadata is:
‹ExternalIdentifier
identificationScheme='urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab'
value='someExternallyMeaningfulIdentifer'›
‹Name›
‹LocalizedString value="XDSDocumentEntry.uniqueId"/›
‹/Name›
‹/ExternalIdentifier›
Classifications allow Registry Objects to be organized in various ways. Classifications are most commonly associated with a controlled terminology. The ebXML registry notion of Classifications makes use of Classification Nodes that appear within a hierarchical (tree-structured) Classification Scheme. The Classification Node and Classification Scheme ebXML RIM objects are used internally by the XDS Registry but not by edge systems.
Most healthcare standards require that both the code and an identifier for the coded terminology be represented, and some also allow for human readable forms of the concepts to be exchanged. In XDS metadata, all three of these components are required in classifications. A typical representation of a Classification in XDS metadata is:
‹Classification
classificationScheme='urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead'
classifiedObject='objectID'
classificationNode='codeValue'›
‹Name value='Display name for codeValue'/›
‹Slot name='codeSystem'›
‹ValueList›‹Value›identifier for code system‹/Value›‹/ValueList›
‹/Slot›
‹/Classification›
Documents and submissions are also organized (classified) by who created or submitted them. In this case, a controlled terminology is insufficient, since there are four different axes which can be used in this organization. These are the author's name, organization, specialty, and role with respect to the patient. These are simply represented as slots in a classification. These slots are named authorPerson, authorRole, authorInstitution and authorSpecialty. When the author Classification is present, at least one of these Slots must be included.
‹Classification
classificationScheme='urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d'
classifiedObject='Document01' nodeRepresentation=''›
‹Slot name='authorPerson'›
‹ValueList›‹Value›AuthorName‹/Value›‹/ValueList›
‹/Slot›
‹/Classification›
The XDS family of profiles recognized three kinds of objects that need to be registered, Documents, Folders and Submissions. Documents are external objects that have associated metadata. The Extrinsic Object is designed for this purpose in the ebRIM, and is how this metadata is stored in the XDS metadata. Folders and Submissions are collections of objects that may have been submitted by multiple parties and also have associated metadata. The Registry Package object is designed for that function and is used by XDS for metadata for these objects.
These three XDS metadata objects have an optional Name and Description that provide the ‘title’ and descriptive text. While optional according to the IHE profiles, these are very strongly recommended. These are found in the ‹Name› and ‹Description› elements of the ‹ExtrinsicObject› or ‹RegistryPackage›.
These objects also carry an availability status that is managed by the registry and is reported during query operations. This is found in the status attribute of the ‹ExtrinsicObject› or ‹RegistryPackage›. Each metadata object within a registry has a (universally) unique identifier that identifies the metadata element. This identifier is found in the id attribute of the ‹ExtrinsicObject› or ‹RegistryPackage›. Finally, the mimeType attribute of the Extrinsic Object element provide the MIME type of the content associated with this metadata.
To complete the XDS Metadata, you must associate Registry Objects with the Registry Packages they are members of, and classify the Registry Packages to describe them as Submissions or folders. The necessary classification for a submission set appears below, and assumes that a Registry Package exists in the submission with the identifier SubmissionSet01.
‹Classification
classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"
classifiedObject="SubmissionSet01"/›
The necessary association between that submission set and the Extrinsic Object representing Document01 follows:
‹Association associationType="HasMember" sourceObject="SubmissionSet01"
targetObject="Document01"›
‹Slot name="SubmissionSetStatus"›
‹ValueList›‹Value›Original‹/Value›‹/ValueList›
‹/Slot›
‹/Association›
The table below is a simplified list of the XDS Metadata requirements for a registry submission (the same requirements used for XDM). I have not include XDS Metadata attributes required by the ebXML RIM (e.g., mimeType, id or scheme identifiers), and have removed display names from the list, since every code in the metadata requires a display name, treating them as parts of the same object.
XDS Metadata Attribute ebXML Type Classification or Identification Scheme Opt Data Types
XDSDocumentEntry
author Classification a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d R2
authorInstitution Slot R2 XON
authorPerson Slot R2 XCN
authorRole Slot R2
authorSpecialty Slot R2
classCode Classification 41a5887f-8865-4c09-adf7-e362475b143a R
comments Description O
confidentialityCode Classification f4f85eac-e6cb-4883-b524-f2705394840f R
creationTime Slot R DTM
eventCodeList Classification 2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4 O
formatCode Classification a09d5840-386c-46f2-b5ad-9c3699a4309d R
hash Slot R SHA1 hash
healthcareFacilityTypeCode Classification f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1 R
languageCode Slot R
legalAuthenticator Slot O XCN
mimeType ExtrinsicObject.mimeType R
patientId ExternalIdentifier 6b5aea1a-874d-4603-a4bc-96a0a7b38446 R CX
practiceSettingCode Classification cccf5598-8b07-4b77-a05e-ae952c785ead R
serviceStartTime Slot R2 DTM
serviceStopTime Slot R2 DTM
size Slot R Integer
sourcePatientId Slot R CX
sourcePatientInfo Slot O
title Name O
typeCode Classification 41a5887f-8865-4c09-adf7-e362475b143a R
uniqueId ExternalIdentifier 2e82c1f6-a085-4c72-9da3-8640a32e42ab R OID or OID^identifier
URI Slot R URI
XDSSubmissionSet
author Classification a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d R2
authorInstitution Slot R2 XON
authorPerson Slot O XCN
authorRole Slot R2
authorSpecialty Slot R2
comments Description O
contentTypeCode Classification aa543740-bdda-424e-8c96-df4873be8500 R
intendedRecipient Slot O XON or XCN
patientId ExternalIdentifer R CX
sourceId ExternalIdentifer 554ac39e-e3fe-47fe-b233-965d2a147832 R OID
submissionTime Slot R DTM
title Name O
uniqueId ExternalIdentifer 96fdda7c-d067-4183-912e-bf5ee74998a8 R OID
XDSFolder
codeList Classification 1ba97051-7806-41a8-a48b-8fce7af683c5 R
comments Description O
patientId ExternalIdentifier f64ffdf0-4b97-4e06-b79f-a52b38ec2f8a R CX
title Name O
uniqueId ExternalIdentifier 75df8f67-9973-4fbe-a900-df66cefecc5a R OID
This table with the overview above should be sufficient for an engineer with some knowledge of XML and HL7 Version 2 data types to put together an XDS Submission.
