Notes on XDS Profile
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^^^&1.3.6.1.4.1.21367.2005.3.7&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^^^&1.3.6.1.4.1.21367.2005.3.7&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
| 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 |
| 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 |
| 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 |
| 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 | |
| UUID | Name | Type | |
| urn:uuid:10aa1a4b-715a-4120-bfd0-9760414112c8 | XDSDocumentEntryStub | ClassificationNode | |
| urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3 | Association Documentation | ClassificationNode | |
| 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 | ||
| 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