Notes on XDS Profile

From IHEWiki

Revision as of 11:34, 6 March 2015 by Eric (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

XDS.a

This page contains information about XDS.a (formerly known as XDS) only.

Use of SOAP vs SOAP with Attachments

XDS specifies the use of SOAP and SOAP with Attachments for communicating between actors. It does not specifically say where to use which protocol. Although one can 'figure it out' for ones self, we list here the logic for using these two protocols.

SOAP differs from SOAP with Attachments in only very simple ways. SOAP has a payload with is always XML formatted. The HTTP body is always a SOAP Envelop. SOAP with Attachments always has multiple piece of content. The first part is always a SOAP payload. The following parts, the attachments, are of arbitrary format.

When to use which format?

Provide and Register transaction - Metadata is always submitted as part of this transaction. If no documents are attached then use SOAP. If documents are being transfered, use SOAP with Attachments.

Register transaction - This transfers metadata only so use SOAP.

Patient Identity Feed transaction - This is an HL7 transaction so has nothing to do with SOAP. If HL7 decides to offer SOAP as a transport wrapper in the future this could change.

Query Registry transaction - The query is always wrapped in XML and there is never an attachment so use SOAP.

Retrieve Document transaction - This is a pure HTTP Get so SOAP is not used.

Response messages in all transactions - All transactions that start with SOAP or SOAP with Attachments end with a response message that is SOAP encoded.

SOAP with Attachments

Below are encoding tips for using SOAP and SOAP with Attachments with XDS. This discussion is organized by the IHE transaction in which the encoding is used.

I still need to link in the example software in JAVA.

XDS Register Document Set transaction

This transaction must move registry metadata from the Repository actor to the Registry actor. There are no document attachments since the documents have already been deposited in the Repository by this time. This transaction just moves a single element, the bundle of registry metadata.

Since there is only one item of payload, the SOAP with Attachments format is not used. Instead the simpler SOAP format is used. Below is an example of this format. It contains an HTTP header and a HTTP Body.

HTTP Header - note the following header fields:

  • SOAPAction is required
  • Content-Type must be as shown

HTTP Body - note the following points:

  • It is entirely XML
  • The outer-most layers of XML are SOAP
  • Next is the registry SubmitObjectsRequest
  • Within the SubmitObjectsRequest is the registry metadata
  • Notice the namespace definitions on SubmitObjectsRequest.
POST /ebxmlrr/registry/soap HTTP/1.1
Accept: */*
Accept-Language: en-us
Referer: http://sst138.ncsl.nist.gov/web/soap/soap-diag-client.htm
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: gunshot.ncsl.nist.gov:8080
Connection: Keep-Alive
Cache-Control: no-cache
Content-Length: 851

<?xml version="1.0" ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
  <SOAP-ENV:Body>
    <rs:SubmitObjectsRequest 
       xmlns:rs="urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.1" 
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
       xmlns="urn:oasis:names:tc:ebxml-regrep:rim:xsd:2.1" 
       xmlns:rim="urn:oasis:names:tc:ebxml-regrep:rim:xsd:2.1">

    <!-- registry metadata as defined by XDS goes here -->

    </rs:SubmitObjectsRequest>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

XDS Provide and Registry Document Set transaction

This transaction is used to move documents and metadata from the Document Source actor and the Document Repository actor. Since more than one element of data must be encoded, a coding scheme must be employed that is capable of wrapping multiple elements. That coding scheme is SOAP with attachments.

HTTP Header - note the following header fields:

  • SOAPAction is required
  • Content-Type has a new part, the boundary sting
  • Within Content-Type is the boundary string to be used as a delimiter between the "parts". This string is typically generated randomly by toolkits that generate this format.
  • The final use of this delimeter has an extra "--". This is critical for some parsers.

HTTP Body - note the following points:

  • The body has multiple parts separated by the boundary string
  • Each part has a Content-Type header and optionally a Content-ID header
  • The Content-ID header is an "ID" for this piece of content within the message. The "ID" is always surrounded by angle brackets "< >".
  • The first part is always the metadata. See XDS Registry Document Set transaction above for details.
  • An ExtrinsicObject in the metadata representing and XDSDocumentEntry can have a id attribute with this "ID" value. This links the ExtrinsicObject in metadata to real document content in the message.
  • In the example below, the ExtrinsicObject XML element has an id attribute with the value "doc_1". This is interpreted as a "pointer" to the message part with Content-Id equal to <doc_1>.
  • A submission can contain any number of documents


POST /ebxmlrr/registry/soap HTTP/1.1
Content-Type: multipart/related; type="text/xml"; boundary=---------------------------7d4285f14803b8
SOAPAction: ""
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: gunshot.ncsl.nist.gov:8080
Accept: */*
Connection: Keep-Alive
Cache-Control: no-cache
Content-Length: 1318

-----------------------------7d4285f14803b8
Content-Type: text/xml

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
  <SOAP-ENV:Body>
    <SubmitObjectsRequest xmlns="urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.1">
      <LeafRegistryObjectList>
        <ExtrinsicObject id="doc_1" mimeType="text/xml"/>
      </LeafRegistryObjectList>
    </SubmitObjectsRequest>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>
-----------------------------7d4285f14803b8
Content-Type: text/xml
Content-Id: <doc_1>

<books>
  <book isbn="0345374827"><title>The Great Shark Hunt</title>
  <author>Hunter S. Thompson</author></book>
  <book><title>Life with Father</title><author>Clarence Day</author></book>
</books>

-----------------------------7d4285f14803b8--

XDS Query Registry transaction

See XDS Registry Document Set transaction above for encoding details.

Using MIME Multipart/Related as a document format

The MIME Multipart/Related format is used as a document format within XDS-I. This format is defined by RFC 2387 and is demonstrated by the following example (taken, in part, from the RFC):

Content-Type: Multipart/Related; boundary=example-2

--example-2
Content-Type: text/plain

Text related to the PDF below is inserted here.
--example-2
Content-Type: application/pdf
Content-Transfer-Encoding: BASE64

BASE64 encoded PDF goes here
--example-2--

The first line is a Content-Type header which must have as its first value the string "Multipart/Related" and an additional part must document the boundary string to be used. The blank lines (technically \r\n) are used to indicate "end of header". One of the parts must be of type text/plain and the other must be "application/pdf" and the contents of this part must be the BASE64 encoded contents of the relevant PDF.

How to Construct XDS Metadata (formerly known as Metadata Cookbook)

XDS is formally based on OASIS ebXML Registry standard version 2.0 which has been adopted by ISO. However, version 2.0 had several critical flaws and was quickly replaced by version 2.1 where many of these flaws were fixed. XDS relies on the improvements in version 2.1 so it is really the basis of XDS. This will be important below where the XML namespaces used reflect this version 2.1 lineage.

This rewrite of the Metadata Cookbook is not yet complete. You can retrieve last year's version from here.

Getting Started - Submit Objects

SubmitObjectsRequest is the registry action defined in ebRS that is used to submit content to the registry. It is used in the Provide and Register Document Set and Register Document Set transactions in XDS.

<rs:SubmitObjectsRequest 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:rs="urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.1"
    xmlns:rim="urn:oasis:names:tc:ebxml-regrep:rim:xsd:2.1"
    xmlns="urn:oasis:names:tc:ebxml-regrep:rim:xsd:2.1"
    xsi:schemaLocation="urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.1 rs.xsd">
           
    <LeafRegistryObjectList>

    <!-- registry metadata goes here -->

    </LeafRegistryObjectList>

</rs:SubmitObjectsRequest>

Above is the wrapper for XDS metadata. Several namespaces are defined. The key ones are rim representing ebRIM and rs representing ebRS. SubmitObjectsRequest is the only element coming from ebRS. Everything else in this message comes from ebRIM namespace. So, we have chosen in this example to make rim the default namespace. LeafRegistryObjectList and everything inside it will come from rim.

There is only one declaration for schemaLocation, that of rs. The rs schema file includes the other two schema files, rim and query.

All discussion below regarding metadata will be shown without this wrapper. Metadata items can be put in this wrapper in any order.

Submission Set

A Submission Set is a wrapper for documents and folders submitted to the registry. It becomes a permanent record of what content was submitted together. This can be used to infer a clinical relevance or not. Technically, a Submission Set is a ebRIM RegistryPackage object annotated with type information labeling it as a Submission Set. In registry, a RegistryPackage represents a folder or directory mechanism. The RegistryPackage object is the header for this folder/directory mechanism. Details of how to add objects to the RegistryPackage will be discussed later.

<RegistryPackage id="SubmissionSet"/>

This metadata example shows a minimalistic RegistryPackage labeled with an id for identification. This id could be any string. Giving it an id of SubmissionSet does not make it a SubmissionSet, it just makes for more readable metadata. This is a legal ebRIM RegistryPackage but not yet a Submission Set. To become a Submission Set, it must be annotated with internal attributes and assigned type information labeling it as a Submission Set.

<RegistryPackage id="SubmissionSet"/>

<Classification 
    classifiedObject="SubmissionSet" 
    classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"/>

<ObjectRef id="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"/>

The Classification object declares the RegistryPackage with id=SubmissionSet to be a Submission Set. The UUID shown in the attribute classificationNode is defined by the XDS profile to identify/label all Submission Set objects. Note that this Classification object could have been coded inside of the Registry package object like this.

<RegistryPackage id="SubmissionSet">
  <Classification 
    classifiedObject="SubmissionSet" 
    classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"/>
</RegistryPackage>


<ObjectRef id="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"/>

Object References (ObjectRef)

The XML standard defines a pointer mechanism called Id/IdRef which allows an XML schema designer to designate an attribute of an element type to be an Id. Ids give an object an identity within an XML document. In ebRIM, all objects have an attribute named id which is of type Id. Other attributes, designated IdRefs, are pointers to Ids. ebRIM designates the attributes classificationScheme, classificationNode, classifiedObject, and identificationNode as being of type IdRef.

In the above example, the Classification element contains two IdRefs, classifiedObject pointing to the RegistryPackage and classificationNode pointing to the ObjectRef. The ObjectRef is a placeholder representing an object already in the registry and is required to make this submission complete.

Raw UUIDs must be used when referencing metadata objects already in the registry. Such UUIDs must be known before composing the metadata. They can be discovered by querying the registry or because documentation for the objects has been provided. For basic functions in XDS, documentation exists. Definitions for XDS standard UUIDs can be found in doc/UUIDS.xls in the Test Kit. For advanced operations such as document replacement, the registry must be queried to discover the necessary UUIDs.

Symbolic identifiers are defined and referenced within the same metadata submission. Their scope is the submission. Symbolic identifiers are distinguished from UUIDs by their lack of the “urn:uuid:” prefix.

Symbolic identifiers may be used to reference other objects in the same submission. Symbolic identifiers are “compiled” into raw UUIDs by the registry. Raw UUIDs may also be used. If raw UUIDs are used, then the composer of the metadata must generate the UUIDs that are used.

Raw UUIDs must be used when referencing objects already in the registry. Such raw UUIDs must be declared as referencing objects outside of this submission. This is done with the ObjectRef element. In the above example, the classificationNode’s UUIDs is accompanied by an ObjectRef element indication that this reference is external to this submission.

Also in the above example, the classifiedObject attribute uses a symbolic identifier to reference the Submission Set object that was included in the submission.

Example Submission Set

Next, to be a valid Submission Set, the RegistryPackage object must contain a series of attributes required by the XDS profile.

        <RegistryPackage id="SubmissionSet01">
            <Name>
                <LocalizedString value="Physical"/>
            </Name>
            <Description>
                <LocalizedString value="Annual physical"/>
            </Description>
            <Slot name="submissionTime">
                <ValueList>
                    <Value>20041225235050</Value>
                </ValueList>
            </Slot>
            <Classification classificationScheme="urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d"
                classifiedObject="SubmissionSet01" nodeRepresentation="">
                <Slot name="authorPerson">
                    <ValueList>
                        <Value>^Dopplemeyer^Sherry</Value>
                    </ValueList>
                </Slot>
                <Slot name="authorInstitution">
                    <ValueList>
                        <Value>Cleveland Clinic</Value>
                        <Value>Berea Community</Value>
                    </ValueList>
                </Slot>
                <Slot name="authorRole">
                    <ValueList>
                        <Value>Primary Surgon</Value>
                    </ValueList>
                </Slot>
                <Slot name="authorSpecialty">
                    <ValueList>
                        <Value>Orthopedic</Value>
                    </ValueList>
                </Slot>
            </Classification>
            <Classification classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
                classifiedObject="SubmissionSet01" nodeRepresentation="History and Physical">
                <Name>
                    <LocalizedString value="History and Physical"/>
                </Name>
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>Connect-a-thon contentTypeCodes</Value>
                    </ValueList>
                </Slot>
            </Classification>
            <ExternalIdentifier identificationScheme="urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8"
                value="129.6.58.42.33726">
                <Name>
                    <LocalizedString value="XDSSubmissionSet.uniqueId"/>
                </Name>
            </ExternalIdentifier>
            <ExternalIdentifier identificationScheme="urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832"
                value="3670984664">
                <Name>
                    <LocalizedString value="XDSSubmissionSet.sourceId"/>
                </Name>
            </ExternalIdentifier>
            <ExternalIdentifier identificationScheme="urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446"
                value="8472644068936^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO">
                <Name>
                    <LocalizedString value="XDSSubmissionSet.patientId"/>
                </Name>
            </ExternalIdentifier>
        </RegistryPackage>

An example XDSDocumentEntry object looks like

        <ExtrinsicObject id="Document01" mimeType="text/plain"
            objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1">
            <Name>
                <LocalizedString value="Physical"/>
            </Name>
            <Description/>
            <Slot name="creationTime">
                <ValueList>
                    <Value>20051224</Value>
                </ValueList>
            </Slot>
            <Slot name="languageCode">
                <ValueList>
                    <Value>en-us</Value>
                </ValueList>
            </Slot>
            <Slot name="serviceStartTime">
                <ValueList>
                    <Value>200412230800</Value>
                </ValueList>
            </Slot>
            <Slot name="serviceStopTime">
                <ValueList>
                    <Value>200412230801</Value>
                </ValueList>
            </Slot>
            <Slot name="sourcePatientId">
                <ValueList>
                    <Value>89765a87b^^^fj34r</Value>
                </ValueList>
            </Slot>
            <Slot name="sourcePatientInfo">
                <ValueList>
                    <Value>PID-3|pid1^^^domain</Value>
                    <Value>PID-5|Doe^John^^^</Value>
                    <Value>PID-7|19560527</Value>
                    <Value>PID-8|M</Value>
                    <Value>PID-11|100 Main St^^Metropolis^Il^44130^USA</Value>
                </ValueList>
            </Slot>
            <rim:Slot name="size">
                <rim:ValueList>
                    <rim:Value>36</rim:Value>
                </rim:ValueList>
            </rim:Slot>
            <rim:Slot name="hash">
                <rim:ValueList>
                    <rim:Value>fbe2351a6a8ceba1a04ba3f832a12a53befeb04c</rim:Value>
                </rim:ValueList>
            </rim:Slot>
            <rim:Slot name="URI">
                <rim:ValueList>
                    <rim:Value>http://129.6.58.92:9080/Repository/129.6.58.92.3492.txt</rim:Value>
                </rim:ValueList>
            </rim:Slot>
            <Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
                classifiedObject="Document01" nodeRepresentation="">
                <Slot name="authorPerson">
                    <ValueList>
                        <Value>^Smitty^Gerald</Value>
                    </ValueList>
                </Slot>
                <Slot name="authorInstitution">
                    <ValueList>
                        <Value>Cleveland Clinic</Value>
                        <Value>Parma Community</Value>
                    </ValueList>
                </Slot>
                <Slot name="authorRole">
                    <ValueList>
                        <Value>Attending</Value>
                    </ValueList>
                </Slot>
                <Slot name="authorSpecialty">
                    <ValueList>
                        <Value>Orthopedic</Value>
                    </ValueList>
                </Slot>
            </Classification>
            <Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
                classifiedObject="Document01" nodeRepresentation="">
                <Slot name="authorPerson">
                    <ValueList>
                        <Value>^Dopplemeyer^Sherry</Value>
                    </ValueList>
                </Slot>
                <Slot name="authorInstitution">
                    <ValueList>
                        <Value>Cleveland Clinic</Value>
                        <Value>Berea Community</Value>
                    </ValueList>
                </Slot>
                <Slot name="authorRole">
                    <ValueList>
                        <Value>Primary Surgon</Value>
                    </ValueList>
                </Slot>
                <Slot name="authorSpecialty">
                    <ValueList>
                        <Value>Orthopedic</Value>
                    </ValueList>
                </Slot>
            </Classification>
            <Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
                classifiedObject="Document01" nodeRepresentation="History and Physical">
                <Name>
                    <LocalizedString value="History and Physical"/>
                </Name>
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>Connect-a-thon classCodes</Value>
                    </ValueList>
                </Slot>
            </Classification>
            <Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
                classifiedObject="Document01" nodeRepresentation="1.3.6.1.4.1.21367.2006.7.101">
                <Name>
                    <LocalizedString value="Clinical-Staff"/>
                </Name>
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>Connect-a-thon confidentialityCodes</Value>
                    </ValueList>
                </Slot>
            </Classification>
            <Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
                classifiedObject="Document01" nodeRepresentation="CDAR2/IHE 1.0">
                <Name>
                    <LocalizedString value="CDAR2/IHE 1.0"/>
                </Name>
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>Connect-a-thon formatCodes</Value>
                    </ValueList>
                </Slot>
            </Classification>
            <Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
                classifiedObject="Document01" nodeRepresentation="Outpatient">
                <Name>
                    <LocalizedString value="Outpatient"/>
                </Name>
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>Connect-a-thon healthcareFacilityTypeCodes</Value>
                    </ValueList>
                </Slot>
            </Classification>
            <Classification classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
                classifiedObject="Document01" nodeRepresentation="General Medicine">
                <Name>
                    <LocalizedString value="General Medicine"/>
                </Name>
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>Connect-a-thon practiceSettingCodes</Value>
                    </ValueList>
                </Slot>
            </Classification>
            <Classification classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
                classifiedObject="Document01" nodeRepresentation="34108-1">
                <Name>
                    <LocalizedString value="Outpatient Evaluation And Management"/>
                </Name>
                <Slot name="codingScheme">
                    <ValueList>
                        <Value>LOINC</Value>
                    </ValueList>
                </Slot>
            </Classification>
            <ExternalIdentifier identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427"
                value="8472644068936^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO">
                <Name>
                    <LocalizedString value="XDSDocumentEntry.patientId"/>
                </Name>
            </ExternalIdentifier>
            <ExternalIdentifier identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
                value="129.6.58.92.88336">
                <Name>
                    <LocalizedString value="XDSDocumentEntry.uniqueId"/>
                </Name>
            </ExternalIdentifier>
        </ExtrinsicObject>

To make this Submission Set object and Document object into a submission we still have to link them with an Association object and wrap them in a submission wrapper.

<rs:SubmitObjectsRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:rs="urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.1"
    xmlns:rim="urn:oasis:names:tc:ebxml-regrep:rim:xsd:2.1"
    xmlns="urn:oasis:names:tc:ebxml-regrep:rim:xsd:2.1">
    <LeafRegistryObjectList>
        <ExtrinsicObject id="Document01">
          <!-- Detail removed for clarity -->
        </ExtrinsicObject>
        <RegistryPackage id="SubmissionSet01">
          <!-- Detail removed for clarity -->
        </RegistryPackage>
        <Classification classifiedObject="SubmissionSet01"
            classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"/>
        <Association associationType="HasMember" sourceObject="SubmissionSet01"
            targetObject="Document01">
            <Slot name="SubmissionSetStatus">
                <ValueList>
                    <Value>Original</Value>
                </ValueList>
            </Slot>
        </Association>
    </LeafRegistryObjectList>
</rs:SubmitObjectsRequest>

This example shows the metadata objects in the order required by the Schema:

  • Name
  • Description
  • Slot
  • Classification
  • ExternalIdentifier

Metadata for individual attributes of an XDSSubmissionSet (or XDSDocumentEntry or XDSFolder) are detailed in sections 3.14.4.1-5 through 3.14.4.1-7 in volume 2 of the XDS profile.

Sample Query

Here is a sample query from last year's test kit. The attribute returnType can take on two values, LeafClass and ObjectRef. For testing in XDS year 2 (2005-2006) vendors should use the predefined queries in section 3.16.4.1.4 of XDS volume 2.

<AdhocQueryRequest>
    <ResponseOption returnType = "LeafClass" returnComposedObjects="true"/>
    <SQLQuery>
    SELECT *  FROM ExtrinsicObject eo, ExternalIdentifier ei
        WHERE
            eo.id = ei.registryobject AND
            ei.identificationScheme='urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427' AND
            ei.value='NIST-5678^^^&1.3.6.1.4.1.21367.2005.1.1&ISO^PI' AND
            eo.status = 'Approved'
    </SQLQuery>
</AdhocQueryRequest>


UUIDs Defined by XDS

XDSSubmissionSet
UUID Name Type Req for Source/Query
urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd XDSSubmissionSet ClassificationNode R/R
urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d XDSSubmissionSet.author External Classification Scheme R2/R
urn:uuid:aa543740-bdda-424e-8c96-df4873be8500 XDSSubmissionSet.contentTypeCode External Classification Scheme R/R
urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446 XDSSubmissionSet.patientId External Identifier R/R
urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832 XDSSubmissionSet.sourceId External Identifer R/R
urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8 XDSSubmissionSet.uniqueId External Identifer R/R
urn:uuid:5003a9db-8d8d-49e6-bf0c-990e34ac7707 XDSSubmissionSet.limitedMetadata ClassificationNode Metadata Limited
XDSDocumentEntry
UUID Name Type Req for Source/Query
urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1 XDSDocumentEntry ClassificationNode R/R
urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d XDSDocumentEntry.author External Classification Scheme R2/R
urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a XDSDocumentEntry.classCode External Classification Scheme R/R
urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f XDSDocumentEntry.confidentialityCode External Classification Scheme R/P
urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4 XDSDocumentEntry.eventCodeList External Classification Scheme O/R
urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d XDSDocumentEntry.formatCode External Classification Scheme R/R
urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1 XDSDocumentEntry.healthcareFacilityTypeCode External Classification Scheme R/R
urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427 XDSDocumentEntry.patientId ExternalIdentifier R/R
urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead XDSDocumentEntry.practiceSettingCode External Classification Scheme R/R
urn:uuid:f0306f51-975f-434e-a61c-c59651d33983 XDSDocumentEntry.typeCode External Classification Scheme R/R
urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab XDSDocumentEntry.uniqueId ExternalIdentifier R/R
urn:uuid:ab9b591b-83ab-4d03-8f5d-f93b1fb92e85 XDSDocumentEntry.limitedMetadata ClassificationNode Metadata Limited
XDSFolder
UUID Name Type Req for Source/Query
urn:uuid:d9d542f3-6cc4-48b6-8870-ea235fbc94c2 XDSFolder ClassificationNode R/R
urn:uuid:1ba97051-7806-41a8-a48b-8fce7af683c5 XDSFolder.codeList External Classification Scheme R/R
urn:uuid:f64ffdf0-4b97-4e06-b79f-a52b38ec2f8a XDSFolder.patientId External Identifier R/R
urn:uuid:75df8f67-9973-4fbe-a900-df66cefecc5a XDSFolder.uniqueId External Identifier R/R
urn:uuid:2c144a76-29a9-4b7c-af54-b25409fe7d03 XDSFolder.limitedMetadata ClassificationNode Metadata Limited
Document Relationships
UUID Name Type
urn:uuid:917dc511-f7da-4417-8664-de25b34d3def APND ClassificationNode
urn:uuid:60fd13eb-b8f6-4f11-8f28-9ee000184339 RPLC ClassificationNode
urn:uuid:ede379e6-1147-4374-a943-8fcdcf1cd620 XFRM ClassificationNode
urn:uuid:b76a27c7-af3c-4319-ba4c-b90c1dc45408 XFRM_RPLC ClassificationNode
urn:uuid:8ea93462-ad05-4cdc-8e54-a8084f6aff94 signs ClassificationNode
Other
UUID Name Type
urn:uuid:10aa1a4b-715a-4120-bfd0-9760414112c8 XDSDocumentEntryStub ClassificationNode
urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3 Association Documentation ClassificationNode
Stored Queries
UUID Name
urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d FindDocuments
urn:uuid:f26abbcb-ac74-4422-8a30-edb644bbc1a9 FindSubmissionSets
urn:uuid:958f3006-baad-4929-a4de-ff1114824431 FindFolders
urn:uuid:10b545ea-725c-446d-9b95-8aeb444eddf3 GetAll
urn:uuid:5c4f972b-d56b-40ac-a5fc-c8ca9b40b9d4 GetDocuments
urn:uuid:5737b14c-8a1a-4539-b659-e03a34a5e1e4 GetFolders
urn:uuid:a7ae438b-4bc2-4642-93e9-be891f7bb155 GetAssociations
urn:uuid:bab9529a-4a10-40b3-a01f-f68a615d247a GetDocumentsAndAssociations
urn:uuid:51224314-5390-4169-9b91-b1980040715a GetSubmissionSets
urn:uuid:e8e3cb2c-e39c-46b9-99e4-c12f57260b83 GetSubmissionSetAndContents
urn:uuid:b909a503-523d-4517-8acf-8e5834dfc4c7 GetFolderAndContents
urn:uuid:10cae35a-c7f9-4cf5-b61e-fc3278ffb578 GetFoldersForDocument
urn:uuid:d90e5407-b356-4d91-a89f-873917b4b0e6 GetRelatedDocuments
Multipatient Stored Queries
UUID Name
urn:uuid:3d1bdb10-39a2-11de-89c2-2f44d94eaa9f FindDocumentsForMultiplePatients
urn:uuid:50d3f5ac-39a2-11de-a1ca-b366239e58df FindFoldersForMultiplePatients

Topics to be Written

XDS Schema and what XML Schema is capable of checking for XDS

Coding/Classifications

History and background on UUIDs

Association types

How to make XDSDocumentEntry, XDSSubmissionSet, XDSFolder out of ebRIM pieces

SS by value, by reference. Why the difference. Goals of ss.

Why we can add our own classifications

Submitted, Approved, Deprecated

Personal tools