Annotated ProvideAndRegister.b Transaction

Annotated Provide and Register transaction.b

What follows is the metadata for a submission of a single document as generated by a Document Source. All the XML shown, when combined, makes a valid submission. This example was generated with the testing tool xdstest using testkit test 11966.

The Provide and Register.b transaction is always carried in a SOAP over HTTP package formatted with MTOM/XOP rules. An example showing the SOAP and HTTP is found here.

The outer-most wrapper is ProvideAndRegisterDocumentSetRequest. The inner wrapper, RegistryObjectList, contains the actual metadata.

<xdsb:ProvideAndRegisterDocumentSetRequest xmlns:xdsb="urn:ihe:iti:xds-b:2007">
    <lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0">
        <rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">

Submission Set

All submissions must include a Submission Set object. This documents the act of submission for later investigation. The Submission Set object is constructed from a ebRIM RegistryPackage object with a Classification labeling the RegistryPackage as a Submission Set. The ebRIM RegistryPackage is also used to construct the XDS Folder object so the Classification is important. (The classification is down below, it will be discussed further there.)

The RegistryPackage object must have id and objectType attributes. objectType has a fixed value as shown below. id has either a symbolic value, as show below, or a UUID value. UUID values have the 9 character prefix urn:uuid:. Symbolic values do not. By the time an object is stored in the Registry, it will have a UUID id value. The Registry has the responsibility of assigning UUIDs to all objects that have symbolic ids before storing.

Why use a symbolic id or a UUID? If you want to know what UUID id value is assigned to your objects then you must assign the UUIDs yourself. The Provide and Register transaction does not return to you the values assigned. Why care? If you want to perform a document replace later without performing a query to discover the UUID id value of your object then you must assign UUIDs. Most folks let the Registry perform this task.

            <rim:RegistryPackage id="SubmissionSet01"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:RegistryPackage">

Next is the list of attributes of the Submission Set. In ebRIM terms there are three types of attributes:

Slot

Name

Description

Classification

ExternalIdentifier

and they must be coded in this order. The schema requires it.

The Submission Set has a single Slot-code attribute: submissionTime which is required.

Many attributes, like submissionTime, have values that are formatted in specific/required ways. Volume 3 of the Technical Framework table 4.1-6 documents the details of this coding. It will not be repeated here.

                <rim:Slot name="submissionTime">
                    <rim:ValueList>
                        <rim:Value>20041225235050</rim:Value>
                    </rim:ValueList>
                </rim:Slot>

Next come the optional title and comments attributes coded as ebRIM Name and Description.

                <rim:Name>
                    <rim:LocalizedString value="Physical"/>
                </rim:Name>
                <rim:Description>
                    <rim:LocalizedString value="Annual physical"/>
                </rim:Description>

Next are the Classifications. There is no ordering to the classifications so they will be discussed in the order of this submission. First is an Author attribute which is coded as an ebRIM Classification object with significant internal structure. There may be multiple authors coded, each is coded as a separate Classification with no significance given to order. Other kinds of classifications will be discussed below.

The author attribute is labeled R2, required if known. The classification object is a wrapper for a collection of attributes describing an author. The XML attributes of the Classification element are decoded as:

• classificationScheme="urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d" formally labels the classification as a Submission Set author.
• classifiedObject="SubmissionSet01" indicates which object this Classification is part of (technically this is redundant since this Classification is nested inside its owner but the schema requires this attribute)
• objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" another redundant but required label
• nodeRepresentation="" a scheme required Classification attribute that is not used and must be the empty string
• id="id_11" all Classification elements must have a unique id (if symbolic must be unique within the submission, if UUID must be globally unique)

                <rim:Classification
                    classificationScheme="urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d"
                    classifiedObject="SubmissionSet01" nodeRepresentation=""
                    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                    id="id_11">

An author has a collection of sub-attributes which are ebRIM coded as Slots within the Classification. The authorPerson Slot is required and has a single value describing this author.

                    <rim:Slot name="authorPerson">
                        <rim:ValueList>
                            <rim:Value>^Dopplemeyer^Sherry^^^</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>

Optionally, an authorInstitution can be included.

                    <rim:Slot name="authorInstitution">
                        <rim:ValueList>
                            <rim:Value>Cleveland Clinic</rim:Value>
                            <rim:Value>Berea Community</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>

Optionally, roles can be document regarding the author

                    <rim:Slot name="authorRole">
                        <rim:ValueList>
                            <rim:Value>Primary Surgon</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>

Optionally, specialties can be coded.

                    <rim:Slot name="authorSpecialty">
                        <rim:ValueList>
                            <rim:Value>Orthopedic</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>
                </rim:Classification>

The next classification is the ebRIM coding of the Content Type Code attribute which is required and can only have a single value (single Classification object of this type). The XML attributes of the Classification element are decoded as:

• classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500" formally labels the classification as a Submission Set Content Type Code.
• classifiedObject="SubmissionSet01" indicates which object this Classification is part of (technically this is redundant since this Classification is nested inside its owner but the schema requires this attribute)
• objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" another redundant but required label
• nodeRepresentation="" a scheme required Classification attribute that is not used and must be the empty string
• id="id_12" all Classification elements must have a unique id (if symbolic must be unique within the submission, if UUID must be globally unique)

The remaining structure is the same for all Coded Attributes. A Coded Attribute has three parts: code value, coding scheme (from which the code value is taken), and code display name. Coded values used in metadata are controlled by the configuration of the Affinity Domain. The Affinity Domain configuration for the Public Registry is documented here. Submission of a coded attribute is validated against the Affinity Domain configuration. The display name is not validated since it will vary by local language and custom.

The three parts of a coded attribute are encoded in ebRIM as:

• code value - nodeRepresentation attribute
• coding scheme - codingScheme slot (must be single value)
• display name - Name attribute

                <rim:Classification
                    classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
                    classifiedObject="SubmissionSet01" nodeRepresentation="History and Physical"
                    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                    id="id_12">
                    <rim:Slot name="codingScheme">
                        <rim:ValueList>
                            <rim:Value>Connect-a-thon contentTypeCodes</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>
                    <rim:Name>
                        <rim:LocalizedString value="History and Physical"/>
                    </rim:Name>
                </rim:Classification>

A submission set requires 3 identifiers: uniqueID, PatientID, and sourceID which are encoded as ebRIM ExternalIdentifier attributes. The required structure of the ExternalIdentifier is:

• identificationScheme="urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8" labels the first ExternalIdentifier as a Submission Set UniqueID (note the other two have their own values)
• objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier" - ebRIM required decoration
• registryObject="SubmissionSet01" - redundantly documents what major object this attribute belong to
• id="id_13" - like a Classification, an ExternalIdentifier has identity and requires an id attribute
• the Name structure is required as shown

The value of the UniqueID/PatientID/SourceID is coded as the value attribute. The UniqueID must be a globally unique OID. If the Registry detects a UnqiueID collision the submission will be rejected. The Submission Set is identified by two unique id attributes: the XML id attribute of the RegistryPackage that defines the Submission Set and the UniqueID. In some ways this is redundant but necessary in other ways.

The SourceID documents which Document Source made the submission.

The PatientID is, well, the patient id. Notice there is a lot of structure here. The part between the two & (note XML encoding of & is &) is the OID identifying the patient id assigning authority. There is exactly one of these for an Affinity Domain. The part before the ^^^ is the identifier for this patient within this assigning authority.

                <rim:ExternalIdentifier
                    identificationScheme="urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8"
                    value="1.2009.0827.08.33.5017"
                    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
                    id="id_13" registryObject="SubmissionSet01">
                    <rim:Name>
                        <rim:LocalizedString value="XDSSubmissionSet.uniqueId"/>
                    </rim:Name>
                </rim:ExternalIdentifier>
                <rim:ExternalIdentifier
                    identificationScheme="urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832"
                    value="1.3.6.1.4.1.21367.2009.1.2.1"
                    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
                    id="id_14" registryObject="SubmissionSet01">
                    <rim:Name>
                        <rim:LocalizedString value="XDSSubmissionSet.sourceId"/>
                    </rim:Name>
                </rim:ExternalIdentifier>
                <rim:ExternalIdentifier
                    identificationScheme="urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446"
                    value="ef77eeda67dd4a2^^^&1.3.6.1.4.1.21367.2005.3.7&ISO"
                    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
                    id="id_15" registryObject="SubmissionSet01">
                    <rim:Name>
                        <rim:LocalizedString value="XDSSubmissionSet.patientId"/>
                    </rim:Name>
                </rim:ExternalIdentifier>
            </rim:RegistryPackage>

Document Entry

Next is the Document Entry object which is constructed from an ebRIM ExtrinsicObject object. In a Provide and Register transaction there is a one-to-one relationship between Document Entry objects and actual documents attached through the MTOM/XOP encoding. The id attribute is used to connect the ExtrinsicObject to the Mime Part.

The XML attributes of the ExtrinsicObject element are:

• id - all ExtrinsicObject elements must have a unique id (if symbolic must be unique within the submission, if UUID must be globally unique)
• mimeType - documents the mime type of the document being submitted
• objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" - ExtrinsicObjects are extendable (can create sub-types). This is controlled by the objectType value. A Document Entry is an ebRIM ExtrinsicObject with this objectType value. IHE may use the ebRIM ExtrinsicObject to define other objects in the future so it is important to have/maintain this value.

            <rim:ExtrinsicObject id="Document01" mimeType="text/plain"
                objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1">

Next is the list of attributes of the Document Entry. In ebRIM terms there are three types of attributes: Slot Name Description Classification ExternalIdentifier and they must be coded in this order. The schema requires it.

A Document Entry object holds the following required/optional attributes based on the ebRIM Slot:

Required

• creationTime
• languageCode
• sourcePatientId

Optional

• legalAuthenticator
• serviceStartTime (technically R2 - required if known)
• serviceStopTime (technically R2 - required if known)
• sourcePatientInfo

These attributes can be included and if they are they must match the contents (Repository can verify and reject if not correct)

• hash
• size

                <rim:Slot name="creationTime">
                    <rim:ValueList>
                        <rim:Value>20051224</rim:Value>
                    </rim:ValueList>
                </rim:Slot>
                <rim:Slot name="languageCode">
                    <rim:ValueList>
                        <rim:Value>en-us</rim:Value>
                    </rim:ValueList>
                </rim:Slot>
                <rim:Slot name="serviceStartTime">
                    <rim:ValueList>
                        <rim:Value>200412230800</rim:Value>
                    </rim:ValueList>
                </rim:Slot>
                <rim:Slot name="serviceStopTime">
                    <rim:ValueList>
                        <rim:Value>200412230801</rim:Value>
                    </rim:ValueList>
                </rim:Slot>
                <rim:Slot name="sourcePatientId">
                    <rim:ValueList>
                        <rim:Value>89765a87b^^^&3.4.5&ISO</rim:Value>
                    </rim:ValueList>
                </rim:Slot>
                <rim:Slot name="sourcePatientInfo">
                    <rim:ValueList>
                        <rim:Value>PID-3|89765a87b^^^&3.4.5&ISO</rim:Value>
                        <rim:Value>PID-5|Doe^John^^^</rim:Value>
                        <rim:Value>PID-7|19560527</rim:Value>
                        <rim:Value>PID-8|M</rim:Value>
                        <rim:Value>PID-11|100 Main St^^Metropolis^Il^44130^USA</rim:Value>
                    </rim:ValueList>
                </rim:Slot>

Next come the optional title and comments attributes coded as ebRIM Name and Description.

                <rim:Name>
                    <rim:LocalizedString value="Physical"/>
                </rim:Name>
                <rim:Description/>

A Document Entry has a documented author(s) just like the Submission Set. The coding of this attribute is identical to the Submission Set version except for the value of the classificationScheme attribute. Note that this Document Entry has two authors.

                <rim:Classification
                    classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
                    classifiedObject="Document01" nodeRepresentation=""
                    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                    id="id_1">
                    <rim:Slot name="authorPerson">
                        <rim:ValueList>
                            <rim:Value>^Smitty^Gerald^^^</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>
                    <rim:Slot name="authorInstitution">
                        <rim:ValueList>
                            <rim:Value>Cleveland Clinic</rim:Value>
                            <rim:Value>Parma Community</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>
                    <rim:Slot name="authorRole">
                        <rim:ValueList>
                            <rim:Value>Attending</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>
                    <rim:Slot name="authorSpecialty">
                        <rim:ValueList>
                            <rim:Value>Orthopedic</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>
                </rim:Classification>
                <rim:Classification
                    classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
                    classifiedObject="Document01" nodeRepresentation=""
                    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                    id="id_2">
                    <rim:Slot name="authorPerson">
                        <rim:ValueList>
                            <rim:Value>^Dopplemeyer^Sherry^^^</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>
                    <rim:Slot name="authorInstitution">
                        <rim:ValueList>
                            <rim:Value>Cleveland Clinic</rim:Value>
                            <rim:Value>Berea Community</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>
                    <rim:Slot name="authorRole">
                        <rim:ValueList>
                            <rim:Value>Primary Surgon</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>
                    <rim:Slot name="authorSpecialty">
                        <rim:ValueList>
                            <rim:Value>Orthopedic</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>
                </rim:Classification>

A Document Entry carries the following code style attributes:

Required

• Class Code (single)
• Confidentiality Code (single)
• Format Code (single)
• Healthcare Facility Type Code (single)
• Practice Setting Code (single)
• Type Code (single)

Optional

• Event Code List (multiple)

The structure of code style attribute is discussed above in the section on Submission Set.

Each of these attributes is assigned a unique UUID as its classificationScheme. The value urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a indicates the Classification is documenting a Class Code. These values are documented in the Technical Framework in Volume 3 Section 4.3.1. As a convenience, they are also available on the web here.

                <rim:Classification
                    classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
                    classifiedObject="Document01" nodeRepresentation="History and Physical"
                    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                    id="id_3">
                    <rim:Slot name="codingScheme">
                        <rim:ValueList>
                            <rim:Value>Connect-a-thon classCodes</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>
                    <rim:Name>
                        <rim:LocalizedString value="History and Physical"/>
                    </rim:Name>
                </rim:Classification>
                <rim:Classification
                    classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
                    classifiedObject="Document01" nodeRepresentation="1.3.6.1.4.1.21367.2006.7.101"
                    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                    id="id_4">
                    <rim:Slot name="codingScheme">
                        <rim:ValueList>
                            <rim:Value>Connect-a-thon confidentialityCodes</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>
                    <rim:Name>
                        <rim:LocalizedString value="Clinical-Staff"/>
                    </rim:Name>
                </rim:Classification>
                <rim:Classification
                    classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
                    classifiedObject="Document01" nodeRepresentation="CDAR2/IHE 1.0"
                    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                    id="id_5">
                    <rim:Slot name="codingScheme">
                        <rim:ValueList>
                            <rim:Value>Connect-a-thon formatCodes</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>
                    <rim:Name>
                        <rim:LocalizedString value="CDAR2/IHE 1.0"/>
                    </rim:Name>
                </rim:Classification>
                <rim:Classification
                    classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
                    classifiedObject="Document01" nodeRepresentation="Outpatient"
                    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                    id="id_6">
                    <rim:Slot name="codingScheme">
                        <rim:ValueList>
                            <rim:Value>Connect-a-thon healthcareFacilityTypeCodes</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>
                    <rim:Name>
                        <rim:LocalizedString value="Outpatient"/>
                    </rim:Name>
                </rim:Classification>
                <rim:Classification
                    classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
                    classifiedObject="Document01" nodeRepresentation="General Medicine"
                    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                    id="id_7">
                    <rim:Slot name="codingScheme">
                        <rim:ValueList>
                            <rim:Value>Connect-a-thon practiceSettingCodes</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>
                    <rim:Name>
                        <rim:LocalizedString value="General Medicine"/>
                    </rim:Name>
                </rim:Classification>
                <rim:Classification
                    classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
                    classifiedObject="Document01" nodeRepresentation="34108-1"
                    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                    id="id_8">
                    <rim:Slot name="codingScheme">
                        <rim:ValueList>
                            <rim:Value>LOINC</rim:Value>
                        </rim:ValueList>
                    </rim:Slot>
                    <rim:Name>
                        <rim:LocalizedString value="Outpatient Evaluation And Management"/>
                    </rim:Name>
                </rim:Classification>

Like the Submission Set, the Document Entry has UniqueID and PatientID attributes. The identificationSchemes are different (between Submission Set and Document Entry) but the structure is the same.

                <rim:ExternalIdentifier
                    identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427"
                    value="ef77eeda67dd4a2^^^&1.3.6.1.4.1.21367.2005.3.7&ISO"
                    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
                    id="id_9" registryObject="Document01">
                    <rim:Name>
                        <rim:LocalizedString value="XDSDocumentEntry.patientId"/>
                    </rim:Name>
                </rim:ExternalIdentifier>
                <rim:ExternalIdentifier
                    identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
                    value="1.2009.0827.08.33.5016"
                    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
                    id="id_10" registryObject="Document01">
                    <rim:Name>
                        <rim:LocalizedString value="XDSDocumentEntry.uniqueId"/>
                    </rim:Name>
                </rim:ExternalIdentifier>
            </rim:ExtrinsicObject>

It was mentioned above in the discussion of the Submission Set that the RegistryPackage object on which it is based must be labeled to give it the semantics of Submission Set. The following Classification does that labeling. It can be coded as a peer of the RegistryPackage it labels (as is shown here) or nested inside. Same meaning. The XML attributes have the following meanings:

• classifiedObject="SubmissionSet01" - identifies the target of the classification (the Submission Set in this case)
• classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" - this value, defined by the XDS Profile, identifies the classifiedObject as a Submission Set
• id="ID_446196_1" - as mentioned above, classification have identify
• objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" - required redundant labeling

            <rim:Classification classifiedObject="SubmissionSet01"
                classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" id="ID_446196_1"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"/>

HasMember Association

So far we have created a Submission Set and a Document Entry. To make this submission correct and complete, we must link these two objects thereby making the Document Entry part of the Submission Set. This Association does that. The parts are:

• associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember" - this is a HasMember association (the Submission Set has the member Document Entry)
• sourceObject="SubmissionSet01" - who has the member?
• targetObject="Document01" - who is the member?
• id="ID_446196_2" - Association objects, like many other, has identity
• objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Association" - required redundant labeling

The SubmissionSetStatus slot is only used on HasMember associations linking Document Entry objects to the Submission Set.

            <rim:Association
                associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember"
                sourceObject="SubmissionSet01" targetObject="Document01" id="ID_446196_2"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Association">
                <rim:Slot name="SubmissionSetStatus">
                    <rim:ValueList>
                        <rim:Value>Original</rim:Value>
                    </rim:ValueList>
                </rim:Slot>
            </rim:Association>
        </rim:RegistryObjectList>
    </lcm:SubmitObjectsRequest>
</xdsb:ProvideAndRegisterDocumentSetRequest>