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.
Thx for the resource!
ReplyDeleteVery useful!
ReplyDelete