Difference between revisions of "Annotated StoredQuery Transaction"

From IHE Wiki
Jump to navigation Jump to search
Line 138: Line 138:
 
</pre>
 
</pre>
  
−
=== The Response ===
+
==== The Response ====
  
 
The response to this query looks like the following.  How is it different from the metadata submitted via the Provide and Register.b transaction?
 
The response to this query looks like the following.  How is it different from the metadata submitted via the Provide and Register.b transaction?

Revision as of 12:18, 25 November 2009

Annotated StoredQuery Transaction

What follows is the metadata for a Stored Query transaction as generated by a Document Consumer actor. All the XML shown, when combined, makes a valid request. This example was generated with the testing tool xdstest using testkit test 11897/objectref.

The Stored Query transaction is always carried in a SOAP over HTTP packaged formatted with SIMPLE SOAP rules. An example showing the SOAP and HTTP is found here.

The outer-most wrapper is AdhocQueryRequest which contains two elements, ResponseOption and AdhocQuery. 

<query:AdhocQueryRequest xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
    xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">

The ResponseOption controls the type of content returned from the Registry. The attributes are:

  • returnType="ObjectRef" - returnType must have one of two values: ObjectRef or LeafClass.
    • ObjectRef returns ObjectRefs which are simple a list of UUIDs of registry objects (Document Entries, Submission Sets, Folders, Associations) that match the query.
    • LeafClass returns the full metadata describing the matched registry objects. Full metadata means all the attributes submitted in a Provide and Register transaction along with some others controlled and generated by the Registry. If your query matches a large number of registry objects this format can generate really large blocks of XML.
  • returnComposedObjects="true" is submitted as shown but has no meaning in the XDS. The ebRS standard on which XDS is based uses this to control additional content which is not used in XDS. Since the schema requires the attribute be present, we include it.
    <query:ResponseOption returnComposedObjects="true" returnType="ObjectRef"/>

The id attribute of the AdhocQuery element specifies which Stored Query is invoked. The Stored Query ids are documented in the Technical Framework in volume 2a in section 3.18.4.1.2.4 and as a convience, on the web here. The id shown is for the FindDocuments Stored Query. 

    <AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d">

Inside the AdhocQuery element are a collection of Slots defining the parameters to the Stored Query. The specific parameters required (or optional) is defined by the individual Stored Query as documented in Technical Framework volume 2a section 3.18.4.1.2.3.7 Parameters for Required Queries. The required parameters for FindDocuments are $XDSDocumentEntryPatientId and $XDSDocumentEntryStatus as shown below. This example shows more than the minimum values for the $XDSDocumentEntryStatus parameter. The bare minumum would be 'urn:oasis:names:tc:ebxml-regrep:StatusType:Approved') requesting only Approved Document Entries.

The special annotations on the values are documented in Technical Framework volume 2a sections 3.18.4.1.2.3.3 through 3.18.4.1.2.3.5.

Note that it is not an error to include extra parameters. A Document Registry must ignore any parameters it does not understand. Realize this means that if you mis-spell a parameter name in your request you will not get an error message back warning you. Of course if the mis-spelled parameter name is a required parameter you will get an error saying you did not include a required parameter. 

        <Slot name="$XDSDocumentEntryPatientId">
            <ValueList>
                <Value>'144ba3c4aad24e9^^^&1.3.6.1.4.1.21367.2005.3.7&ISO'</Value>
            </ValueList>
        </Slot>
        <Slot name="$XDSDocumentEntryStatus">
            <ValueList>
                <Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved',
                    'urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated')</Value>
            </ValueList>
        </Slot>
    </AdhocQuery>
</query:AdhocQueryRequest>

Annotated Response

These examples were generated by the Public Registry.

This request had returnType="ObjectRef" so the response is a list of ObjectRefs. An ObjectRef is simply an XML wrapper around a registry UUID. UUIDs are used to label every object in the registry. Having the UUID (also sometimes called the id since it is carried in the id attribute) means you can request the full metadata in a separate Strored Query or just feel good having a reference to the Document Entry of interest.

Thsi ObjecRef element has an optional ebRIM attribute home which corresponds to the XDS attribute HomeCommunityId. As shown the HomeCommunityId is empty (could just be missing) indicating that the object with that id is available in the local Registry (within the local Affinity Domain). But, XDS and XCA (Cross-Community Access) are crafted so that a Document Consumer does not have to know if it is talking to the local Registry or to a Gateway to the rest of the heathcare world. Unfortunately we did not hide all evidence of local vs remote content. If that were hidden then the home attribute would not be needed. But the home attribute is all that is necessary. 

<query:AdhocQueryResponse
    xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
    status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success">
    <rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
        <rim:ObjectRef id="urn:uuid:22c85315-12cd-4d52-97a9-8d827f03ddc5" home=""/>
        <rim:ObjectRef id="urn:uuid:6eb82cee-a028-4db2-b346-8837d5043227" home=""/>
        <rim:ObjectRef id="urn:uuid:d2dc7a78-577d-4be7-8c33-c097879cf96b" home=""/>
        <rim:ObjectRef id="urn:uuid:94fc7d01-e216-4873-8168-ee94e760e8bd" home=""/>
        <rim:ObjectRef id="urn:uuid:9d6fdebb-16dc-4d7f-935c-8621c9692d83" home=""/>
        <rim:ObjectRef id="urn:uuid:44b9abc1-c4dc-4b95-b099-9415baaf3880" home=""/>
    </rim:RegistryObjectList>
</query:AdhocQueryResponse>

The presence of the home attribute places a requirement on the Document Consmer implementation. At the completion of a Stored Query, the Document Consumer can do one of four things:

  • Present its data to a user (my way of saying that no further XDS/XCA transactions are initiated)
  • Initiate a secondary Stored Query request
  • Initiate a Retreive Document Set request to get the contents of a Document
  • Start an unrelated Stored Query (unrelated in the XDS/XCA sense, it may be related from the point of view of your application)

Possible next steps

Before we discuss the generation of a secondary Stored Query, it is necessary to understand the management of the HomeCommunityId attribute. It affects all the options below.

A Document Consumer actor operates without knowing whether it is sending transactions to a Document Registry/Docuement Repository pair or an Initiating Gateway. They look the same except for the management of HomeCommunityId. Don't be confused thinking - But a Document Registry / Document Repository pair will have separate web services endpoints so we will know the difference. It is likely they will but not required. You could be fooled.

There is one simple rule to follow to be adaptable to both configurations:

If a query returns a home attribute, any follow-up (secondary) queries or Retrieve Document Set transactions must include the value of the home attribute in their request. (Note that it is coded differently in a query vs a retrieve)

BTW, the Technical Framework requires this behaviour of a Document Consumer to pass Connectathon. So, it's not only a good idea ... it's the law.

Initiate a secondary Stored Query

The term Secondary Stored Query is my way of explaining this concept, you will not find it in the Technical Framework. If you start with a Stored Query for ObjectRefs you will likely use a second Stored Query to get the details contents of the registry objects of interest. This is what I call a secondary stored query. The primary stored queries all have Find in their name and include a Patient ID as a required parameter. The secondary stored queries are more like gets than queries because you use them to get (maybe retrieve is a better word but it confuses with the Retrieve Document Set transaction so I don't use it) the detailed metadata. The primary, find, stored queries are:

  • FindDocuments
  • FindSubmissionSets
  • FindFolders

and all the others are get style queries.

Note that I have intentionally not include the GetAll Stored Query in this discussion. First it is mis-named because it is a Find style query with a Get style name. Second I believe it to be too powerful and easy to abuse that I don't document it or include it in my test facility. I think it should be removed from the Technical Framework. Just my opinion.

A typical secondary query to follow a FindDocuments for ObjectRef would be a GetDocumets for LeafClass to get the detailed metadata for all or a subset of the documents identified in the FindDocumets. Why get a subset? A FindDocuments query could return a very large number of objects. Moving around really larget blobs of XML can kill system performace. Sometimes it is better to do a ObjectRef style query followed by a bunch of smaller LeafClass style queries. I certainly promote this approach. A Document Registry actor may reject queries if they ask for too much all at one time. This is an implementation issue and not specified by IHE.

A GetDocuments Stored Query follows.

Note the returnType is LeafClass indicating we want to get full metadata back. 

<query:AdhocQueryRequest xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
    xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
    <query:ResponseOption returnComposedObjects="true" returnType="LeafClass"/>

The id attribute indicates GetDocuments Stored Query. 

    <AdhocQuery id="urn:uuid:5c4f972b-d56b-40ac-a5fc-c8ca9b40b9d4">

This parameter takes a list of UUIDs that we want full metadata for.

There is an ebRIM limitation we have to work around. The contents of a <Value/> element is limited to 256 characters. You cannot list 25 UUIDs and stay under this limit. The trick is to code the request with multiple <Value/> elements. There is no restriction on how many <Value/> elements are present. A simple strategy is to code each UUID in a separate <Value/> element. 

        <Slot name="$XDSDocumentEntryEntryUUID">
            <ValueList>
                <Value>('urn:uuid:22c85315-12cd-4d52-97a9-8d827f03ddc5')</Value>
            </ValueList>
        </Slot>
    </AdhocQuery>
</query:AdhocQueryRequest>

The Response

The response to this query looks like the following. How is it different from the metadata submitted via the Provide and Register.b transaction?

  • ExtrinsicObject (Document Entry) and RegistryPackage (Submission Set and Folder) objects will have a status attribute with (ignoring the namespace prefix) values of Approved or Deprecated. Note that this list may be expanded in the future.
  • ExtrinsicObject (Document Entry) and RegistryPackage (Submission Set and Folder) objects may have a non-empty home attribute indicating the involvement of a gateway (implications discussed above)
  • No symbolic ids will be present, only UUIDs
  • Document Entries (ExtrinsicObjects) will have size, hash, and repositoryUniqueId attributes
  • There will be no Submission Set. This Stored Query did not ask for it so it was not returned.

Note that this example shows a URI attribute since my registry supports both the deprecated XDS.a and XDS.b. 

<query:AdhocQueryResponse xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
    status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success">
    <rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
        <rim:ExtrinsicObject id="urn:uuid:22c85315-12cd-4d52-97a9-8d827f03ddc5"
            objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
            status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" mimeType="text/xml"
            isOpaque="false" home="" lid="urn:uuid:22c85315-12cd-4d52-97a9-8d827f03ddc5">
            <rim:Slot name="URI">
                <rim:ValueList>
                    <rim:Value>http://129.6.24.109:9080/XdsDocs/testdata/my_document.txt</rim:Value>
                </rim:ValueList>
            </rim:Slot>
            <rim:Slot name="creationTime">
                <rim:ValueList>
                    <rim:Value>20061224</rim:Value>
                </rim:ValueList>
            </rim:Slot>
            <rim:Slot name="hash">
                <rim:ValueList>
                    <rim:Value>e543712c0e10501972de13a5bfcbe826c49feb75</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="repositoryUniqueId">
                <rim:ValueList>
                    <rim:Value>1.19.6.24.109.42.1</rim:Value>
                </rim:ValueList>
            </rim:Slot>
            <rim:Slot name="serviceStartTime">
                <rim:ValueList>
                    <rim:Value>200612230800</rim:Value>
                </rim:ValueList>
            </rim:Slot>
            <rim:Slot name="serviceStopTime">
                <rim:ValueList>
                    <rim:Value>200612230900</rim:Value>
                </rim:ValueList>
            </rim:Slot>
            <rim:Slot name="size">
                <rim:ValueList>
                    <rim:Value>36</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|pid1^^^&1.2.3&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>
            <rim:Name>
                <rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="DocA"/>
            </rim:Name>
            <rim:Description/>
            <rim:VersionInfo versionName="1.1"/>
            <rim:Classification id="urn:uuid:c7d7c1f1-b1e3-446c-8f82-f843e0b13260"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
                classifiedObject="urn:uuid:22c85315-12cd-4d52-97a9-8d827f03ddc5"
                nodeRepresentation="" home="" lid="urn:uuid:c7d7c1f1-b1e3-446c-8f82-f843e0b13260">
                <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="authorPerson">
                    <rim:ValueList>
                        <rim:Value>^Smitty^Gerald^^^</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:Name/>
                <rim:Description/>
                <rim:VersionInfo versionName="1.1"/>
            </rim:Classification>
            <rim:Classification id="urn:uuid:d213a35d-9da9-4ba2-8968-90a4e61a54a5"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
                classifiedObject="urn:uuid:22c85315-12cd-4d52-97a9-8d827f03ddc5"
                nodeRepresentation="" home="" lid="urn:uuid:d213a35d-9da9-4ba2-8968-90a4e61a54a5">
                <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="authorPerson">
                    <rim:ValueList>
                        <rim:Value>^Dopplemeyer^Sherry^^^</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:Name/>
                <rim:Description/>
                <rim:VersionInfo versionName="1.1"/>
            </rim:Classification>
            <rim:Classification id="urn:uuid:e21feda1-3f31-49cf-b680-916a4b484d4d"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
                classifiedObject="urn:uuid:22c85315-12cd-4d52-97a9-8d827f03ddc5"
                nodeRepresentation="History and Physical" home=""
                lid="urn:uuid:e21feda1-3f31-49cf-b680-916a4b484d4d">
                <rim:Slot name="codingScheme">
                    <rim:ValueList>
                        <rim:Value>Connect-a-thon classCodes</rim:Value>
                    </rim:ValueList>
                </rim:Slot>
                <rim:Name>
                    <rim:LocalizedString xml:lang="en-us" charset="UTF-8"
                        value="History and Physical"/>
                </rim:Name>
                <rim:Description/>
                <rim:VersionInfo versionName="1.1"/>
            </rim:Classification>
            <rim:Classification id="urn:uuid:81a157b8-30d3-4951-9caf-b92d2424f515"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
                classifiedObject="urn:uuid:22c85315-12cd-4d52-97a9-8d827f03ddc5"
                nodeRepresentation="1.3.6.1.4.1.21367.2006.7.102" home=""
                lid="urn:uuid:81a157b8-30d3-4951-9caf-b92d2424f515">
                <rim:Slot name="codingScheme">
                    <rim:ValueList>
                        <rim:Value>Connect-a-thon confidentialityCodes</rim:Value>
                    </rim:ValueList>
                </rim:Slot>
                <rim:Name>
                    <rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="Clinical-Staff"/>
                </rim:Name>
                <rim:Description/>
                <rim:VersionInfo versionName="1.1"/>
            </rim:Classification>
            <rim:Classification id="urn:uuid:f5053707-f321-4d15-8411-f8439fdef2f5"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
                classifiedObject="urn:uuid:22c85315-12cd-4d52-97a9-8d827f03ddc5"
                nodeRepresentation="CDAR2/IHE 1.0" home=""
                lid="urn:uuid:f5053707-f321-4d15-8411-f8439fdef2f5">
                <rim:Slot name="codingScheme">
                    <rim:ValueList>
                        <rim:Value>Connect-a-thon formatCodes</rim:Value>
                    </rim:ValueList>
                </rim:Slot>
                <rim:Name>
                    <rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="CDAR2/IHE 1.0"/>
                </rim:Name>
                <rim:Description/>
                <rim:VersionInfo versionName="1.1"/>
            </rim:Classification>
            <rim:Classification id="urn:uuid:5563eba1-56e2-45be-9659-b37e12e98c1e"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
                classifiedObject="urn:uuid:22c85315-12cd-4d52-97a9-8d827f03ddc5"
                nodeRepresentation="Outpatient" home=""
                lid="urn:uuid:5563eba1-56e2-45be-9659-b37e12e98c1e">
                <rim:Slot name="codingScheme">
                    <rim:ValueList>
                        <rim:Value>Connect-a-thon healthcareFacilityTypeCodes 2</rim:Value>
                    </rim:ValueList>
                </rim:Slot>
                <rim:Name>
                    <rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="Outpatient"/>
                </rim:Name>
                <rim:Description/>
                <rim:VersionInfo versionName="1.1"/>
            </rim:Classification>
            <rim:Classification id="urn:uuid:9b4e331f-0cc7-4114-858c-c64e86e820c9"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
                classifiedObject="urn:uuid:22c85315-12cd-4d52-97a9-8d827f03ddc5"
                nodeRepresentation="Dialysis" home=""
                lid="urn:uuid:9b4e331f-0cc7-4114-858c-c64e86e820c9">
                <rim:Slot name="codingScheme">
                    <rim:ValueList>
                        <rim:Value>Connect-a-thon practiceSettingCodes</rim:Value>
                    </rim:ValueList>
                </rim:Slot>
                <rim:Name>
                    <rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="Dialysis"/>
                </rim:Name>
                <rim:Description/>
                <rim:VersionInfo versionName="1.1"/>
            </rim:Classification>
            <rim:Classification id="urn:uuid:289f4226-9c3c-4129-b621-9ac6fbf96fd4"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                classificationScheme="urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
                classifiedObject="urn:uuid:22c85315-12cd-4d52-97a9-8d827f03ddc5"
                nodeRepresentation="T-D4909" home=""
                lid="urn:uuid:289f4226-9c3c-4129-b621-9ac6fbf96fd4">
                <rim:Slot name="codingScheme">
                    <rim:ValueList>
                        <rim:Value>SNM3</rim:Value>
                    </rim:ValueList>
                </rim:Slot>
                <rim:Name>
                    <rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="Kidney"/>
                </rim:Name>
                <rim:Description/>
                <rim:VersionInfo versionName="1.1"/>
            </rim:Classification>
            <rim:Classification id="urn:uuid:0d929651-d74a-4fb1-89e6-d1704c9522e4"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                classificationScheme="urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
                classifiedObject="urn:uuid:22c85315-12cd-4d52-97a9-8d827f03ddc5"
                nodeRepresentation="T-62002" home=""
                lid="urn:uuid:0d929651-d74a-4fb1-89e6-d1704c9522e4">
                <rim:Slot name="codingScheme">
                    <rim:ValueList>
                        <rim:Value>SNM3</rim:Value>
                    </rim:ValueList>
                </rim:Slot>
                <rim:Name>
                    <rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="Liver"/>
                </rim:Name>
                <rim:Description/>
                <rim:VersionInfo versionName="1.1"/>
            </rim:Classification>
            <rim:Classification id="urn:uuid:6d2ae58e-95f1-42cf-801c-a1a55f66c604"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
                classifiedObject="urn:uuid:22c85315-12cd-4d52-97a9-8d827f03ddc5"
                nodeRepresentation="34108-1" home=""
                lid="urn:uuid:6d2ae58e-95f1-42cf-801c-a1a55f66c604">
                <rim:Slot name="codingScheme">
                    <rim:ValueList>
                        <rim:Value>LOINC</rim:Value>
                    </rim:ValueList>
                </rim:Slot>
                <rim:Name>
                    <rim:LocalizedString xml:lang="en-us" charset="UTF-8"
                        value="Outpatient Evaluation And Management"/>
                </rim:Name>
                <rim:Description/>
                <rim:VersionInfo versionName="1.1"/>
            </rim:Classification>
            <rim:ExternalIdentifier id="urn:uuid:5c93dd7c-844b-41cf-9f1c-b5ebed64dc15"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
                identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
                value="1.2009.0827.08.33.5074" home=""
                lid="urn:uuid:5c93dd7c-844b-41cf-9f1c-b5ebed64dc15"
                registryObject="urn:uuid:22c85315-12cd-4d52-97a9-8d827f03ddc5">
                <rim:Name>
                    <rim:LocalizedString xml:lang="en-us" charset="UTF-8"
                        value="XDSDocumentEntry.uniqueId"/>
                </rim:Name>
                <rim:Description/>
                <rim:VersionInfo versionName="1.1"/>
            </rim:ExternalIdentifier>
            <rim:ExternalIdentifier id="urn:uuid:31fe3b6b-4741-46d3-b199-d8f17eca66ce"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
                identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427"
                value="144ba3c4aad24e9^^^&1.3.6.1.4.1.21367.2005.3.7&ISO" home=""
                lid="urn:uuid:31fe3b6b-4741-46d3-b199-d8f17eca66ce"
                registryObject="urn:uuid:22c85315-12cd-4d52-97a9-8d827f03ddc5">
                <rim:Name>
                    <rim:LocalizedString xml:lang="en-us" charset="UTF-8"
                        value="XDSDocumentEntry.patientId"/>
                </rim:Name>
                <rim:Description/>
                <rim:VersionInfo versionName="1.1"/>
            </rim:ExternalIdentifier>
        </rim:ExtrinsicObject>
    </rim:RegistryObjectList>
</query:AdhocQueryResponse>

Initiate a Retrieve Document Set transaction

Once you have the full metatata for a Document Entry, you have enough information to initiate a Retrieve Document Set transaction to retrieve the document contents from a Document Repository or Initiating Gateway.

You will need to extract the following information for each document from the representative Document Entry (ExtrinsicObject)

  • HomeCommunityId
  • RepositoryUniqueId
  • UniqueId

The details of the Retrieve Document Set transaction are discussed here.

Retrieved from "http://wiki.ihe.net/index.php?title=Annotated_StoredQuery_Transaction&oldid=38694"