Wednesday, April 21, 2010

A Quick Overview of the ebXML RIM objects in XDS Metadata

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 AttributeebXML TypeClassification or Identification SchemeOptData Types
XDSDocumentEntry
authorClassificationa7058bb9-b4e4-4307-ba5b-e3f0ab85e12d R2
authorInstitutionSlotR2XON
authorPersonSlotR2XCN
authorRoleSlotR2
authorSpecialtySlotR2
classCodeClassification41a5887f-8865-4c09-adf7-e362475b143aR
commentsDescriptionO
confidentialityCodeClassificationf4f85eac-e6cb-4883-b524-f2705394840fR
creationTimeSlotRDTM
eventCodeListClassification2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4O
formatCodeClassificationa09d5840-386c-46f2-b5ad-9c3699a4309dR
hashSlotRSHA1 hash
healthcareFacilityTypeCodeClassificationf33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1R
languageCodeSlotR
legalAuthenticatorSlotOXCN
mimeTypeExtrinsicObject.mimeTypeR
patientIdExternalIdentifier6b5aea1a-874d-4603-a4bc-96a0a7b38446RCX
practiceSettingCodeClassificationcccf5598-8b07-4b77-a05e-ae952c785eadR
serviceStartTimeSlotR2DTM
serviceStopTimeSlotR2DTM
sizeSlotRInteger
sourcePatientIdSlotRCX
sourcePatientInfoSlotO
titleNameO
typeCodeClassification41a5887f-8865-4c09-adf7-e362475b143aR
uniqueIdExternalIdentifier2e82c1f6-a085-4c72-9da3-8640a32e42abROID or OID^identifier
URISlotRURI
XDSSubmissionSet
authorClassificationa7058bb9-b4e4-4307-ba5b-e3f0ab85e12dR2
authorInstitutionSlotR2XON
authorPersonSlotOXCN
authorRoleSlotR2
authorSpecialtySlotR2
commentsDescriptionO
contentTypeCodeClassificationaa543740-bdda-424e-8c96-df4873be8500R
intendedRecipientSlotOXON or XCN
patientIdExternalIdentiferRCX
sourceIdExternalIdentifer554ac39e-e3fe-47fe-b233-965d2a147832ROID
submissionTimeSlotRDTM
titleNameO
uniqueIdExternalIdentifer96fdda7c-d067-4183-912e-bf5ee74998a8ROID
XDSFolder
codeListClassification1ba97051-7806-41a8-a48b-8fce7af683c5R
commentsDescriptionO
patientIdExternalIdentifierf64ffdf0-4b97-4e06-b79f-a52b38ec2f8aRCX
titleNameO
uniqueIdExternalIdentifier75df8f67-9973-4fbe-a900-df66cefecc5aROID

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.

2 comments: