Difference between revisions of "Annotated ProvideAndRegister.b Transaction"

From IHE Wiki
Jump to navigation Jump to search
Line 577: Line 577:
 
                             id="ID_12702088_3"> </Association>
 
                             id="ID_12702088_3"> </Association>
 
</pre>
 
</pre>
 +
 +
=== Document Repositoy response to a document replace ===
 +
 +
There is no specific response.  To the Document Repository this is a submission of a new document.  The relationship to the original document is maintained in the Registry.  The original document is still available to be retrieved from the Repository.
  
 
=== Document Registry response to a document replace ===
 
=== Document Registry response to a document replace ===

Revision as of 08:47, 25 November 2009

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. A copy of this metadata, without annotations, can be found here.

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:

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:

            <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:

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>

Annotated Response

These examples were generated by the Public Registry.

Two possible responses can be received: success and failure. Here are examples.

Success

Not much can be said about this example. The status attribute gives the success/failure report.

           <rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
                    status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/>

Failure

There are many reasons for a failure. Table 4.1-11 Error Codes in Technical Framework volume 3 gives the complete list of error codes that may be returned.

Here is a failure returned back from the Document Registry because the documents were submitted for a Patient ID that is unknown to the Registry.

First the status is Failure with the required namespace on the value. This structure can contain multiple errors. RegistryErrorList is the wrapper around the list of errors.

<rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
    status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure">
    <rs:RegistryErrorList>

This example contains a single error: single RegistryError element. The parts are:

  • severity attribute, with proper namespace, labels this RegistryError structure as an error (as opposed to a warning)
  • codeContext is a free text message explaining the problem
  • errorCode is a text code taken from Table 4.1-11 Error Codes in Technical Framework volume 3
  • location is unconstrained detail about where the error occured. I usually put a Java stack trace here since it is helpful in debugging.
        <rs:RegistryError
            codeContext="XDS Unknown Patient Id:
 PatientId 1111111^^^&1.3.6.1.4.1.21367.2005.3.7&ISO is not known to the Registry"
            errorCode="XDSUnknownPatientId"
            location=""
            severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/>
    </rs:RegistryErrorList>
</rs:RegistryResponse>

Submission of two documents

The above example shows the submission of a single document. To expand that to submit two documents within the same submission:

  • Add a second Document Entry
  • Add a second HasMember Association linking the Document Entry to the Submission Set
  • The MTOM/XOP package includes a second document Mime Part

Document Replacement

XDS allows a document to be submitted as a replacement of another document. The replaced document does not vanish, it is just relabeled in the Registry so a Document Consumer knows it is not the most recent version. A document replacement is a combination of a document submission as shown here with some extra metadata indicating the document to be replaced.

To code a document replacement start with the single document replacement show above and add the following metadata within RegistryObjectList. This builds a replace (RPLC) association between the new document being submitted and the original one already in the Registry. The attributes are:

  • associationType="urn:ihe:iti:2007:AssociationType:RPLC" indicates the type of association - replace. Note that the namespace is different since this type was defined by a different committee
  • sourceObject="Document01" - indicating the replacing document which is part of this submission.
  • targetObject="urn:uuid:ad316644-202e-452d-902e-d3b53c0ee8c6" - a pointer to the Document Entry in the Registry that is being replaced. Since this references an object that is not part of this submission, a symbolic name cannot be used.
  • id="ID_12702088_3" - association objects must have a unique id attribute as always

An important issue is how to get the UUID of the Document Entry to be replace. There are two ways:

  • If you originally submitted it you could have pre-assigned a UUID to the Document Entry (as opposed to using a symbolic id and letting the Registry assign a UUID) and saved it. This is a little dangerous. If another Document Source has already replaced your document then this replace would fail.
  • You could issue a Stored Query transaction to the Registry and discover the UUID of your Document Entry. This is a pretty sensible approach especially if your product looks like a workstation and implements both the Document Source and Document Consumer actors. A user would select the document to be replaced on the screen and then indicate the document that should replace it. Obviously many other scenarios are possible.
         <Association associationType="urn:ihe:iti:2007:AssociationType:RPLC" sourceObject="Document01"
                            targetObject="urn:uuid:ad316644-202e-452d-902e-d3b53c0ee8c6"
                            id="ID_12702088_3"> </Association>

Document Repositoy response to a document replace

There is no specific response. To the Document Repository this is a submission of a new document. The relationship to the original document is maintained in the Registry. The original document is still available to be retrieved from the Repository.

Document Registry response to a document replace

A Provide and Register.b transaction sent to the Document Repository results in a Register.b transaction being forwarded on to the Document Registry. The Document Registry will:

  • Verify that the Document Entry pointed at by the targetObject attribute exists and has status of Approved. If not then the transaction fails and no updates are made.
  • The new Document Entry is assigned the status of Approved as a normal part of being submitted.
  • The Document Entry being replaced has its status changed to Deprecated.

Document Consumer actors typically search for Document Entry objects with status of Approved. So the result of your document replacement will be the Document Consumer seeing only the new replacement and not the original, now deprecated, Document Entry. Obviously the Document Consumer can look deeper and ask for both the Approved and Deprecated Document Entry objects.

How is XDR different?

XDR uses the Provide and Registery.b transaction to move documents and metadata to the Document Recipient actor. Everything said in the above sections holds for XDR. In addition:

  • We recommend that the size and hash attributes (Document Entry) be included.
  • The Intended Recipient attribute (Document Entry) is useful for guiding routing at the Document Recipient.