XDS-FAQ 2

From IHE Wiki
Revision as of 10:51, 18 March 2019 by Smoore (talk | contribs) (Created page with "= XDS-FAQ = <b>Frequently Asked Questions about the XDS Profile</b> == Are Classifications, in XML, coded inside or outside the element they refer to? == Classifications s...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

XDS-FAQ

Frequently Asked Questions about the XDS Profile


Are Classifications, in XML, coded inside or outside the element they refer to?

Classifications such as 

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

may be coded inside the object they refer to (classifiedObject) or outside. The registry standard allows either. Therefore, Document Registries and Document Consumers shall accept either.

How do I interpret the file log.msg that the test tool xdstest generates?

File format is basically:

Header stuff

(a row of stars)

Request you sent (header and body displayed separately)

(another row of stars)

Response back from server (header and body displayed separately)

So, the server response 

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<xdsheader SOAP-ENV:mustUnderstand="0">
	<logentry url="a real URL is found here"/>
</xdsheader>
</SOAP-ENV:Header>

<SOAP-ENV:Body>
<RegistryResponse xmlns="urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.1" status="Success">
</RegistryResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

shows status="Success" (in the RegistryResponse element). Furthermore, the logentry element in the soap header has a URL to the logger on the server. If you pop that url into a browser, up will come the same log info that I can see (you can see only your log info). Select the right most tab (tabs are shown across the top). This will show a page of detail about your message. It frequently does not add any new insight but it may occasionally tell you something about what the server thought about your request.

Which attributes can have multiple values in XDS?

By default all XDS attributes have a single value. When multiple values are allowed it is specifically stated in the documentation of the attribute. This style of documentation is opposite that of ebRS and ebRIM. As updates and corrections are applied to the document, the wording of individual attributes will be updated to make this clearer for the reader.

Mistake in Stored Query example

The Stored Query example in section 3.18.4.1.3.1 Sample Query Request has the Patient ID attribute improperly quoted. The example shows 

<rim:Slot name="$XDSDocumentEntryPatientId"> 
  <rim:ValueList>           
    <rim:Value>st3498702^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO</rim:Value> 
  </rim:ValueList> 
</rim:Slot>

The Patient ID value should be in single quotes as in 

<rim:Slot name="$XDSDocumentEntryPatientId"> 
  <rim:ValueList>           
    <rim:Value>'st3498702^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO'</rim:Value> 
  </rim:ValueList> 
</rim:Slot>

See section 3.18.4.1.2.3.5 Coding of Single/Multiple Values for details. A Change Proposal has been submitted to correct this typo.

Why does Stored Query require the specification Status attribute for Folder and Submission set?

Folder and Submission Set objects can only take on two values for the Status attribute, Submtited and Approved, and the Submitted value should be hidden from all but the Registry Adaptor. Stored Query requires the Status attribute be present in search-style queries (name starts with Find) to allow for future growth and adaptation. As a general philosophy, we know that XDS will have to grow and change. But we also know that updating product software is difficult and expensive. So, when we are forced to make changes to part of the XDS specification, we try to generalize the updates so as to avoid future changes.

Can Associations link to Deprecated objects?

Once an Association (or Classification or ExternalIdentifier) is linked to an object, Deprecating that object does not affect the linkage. But, once Deprecated, new Associations (Classifications, ExternalIdentifiers) can not be created for/with that object. This restiction is specified in ebRS.

XDS-SD and base64 encoding

According to the XDS-SD profile, documents are supposed to be base-64 encoded before being wrapped with XML (CDA) and sent. Apparently, there are several types of base-64 encoding schemes (MIME, PER, UTF-7). Can you clarify which standard we are to be following?

XDS-SD requires the use of MIME encoding also known as xs:base64Binary. Developers who use an off the shelf XML library will likely see xs:base64Binary in its specification. A Change Proposal has been filed against XDS-SD so this will be explicitly stated.

Do Stored Query and the older SQL query return the same content?

Not at the moment. This season the Public Registy implements 3 Affinity Domains:

  • Portals that have the form portals/repository (or query or registry at the end) reference the content from last year (and earlier)
  • Portals that have the form portals/yr3a/repository (or query or registry or storedquery at the end) reference year 3 metadata and uses a different version of the metadata validator that validates against the new rules.
  • Portals that have the form portals/yr3b/repository (or query or registry or storedquery at the end) reference year 3 metadata and will be used exclusively for BPPC testing which requires slightly different validation rules.

The Provide and Register, Register, and Stored Query transactions are implemented to hide the mechanisms used to separate the metadata. Unfortunately, the SQL query portal does not yet distinguish metadata assigned to different Affinity Domains. This is not intentional, just a work in progress. For now, metadata returned from an SQL query will contain data from all three Affinity Domains. Also, on yr3a and yr3b domains, you will see a Slot not documented in XDS named AffinityDomain. When completed, the SQL query will not produce this slot and will propery distinguish between domains.

Where can I find the escape characters/sequences used in XML?

The official reference is here but it is not that readable. A secondary source that is easy to read can be found here.

Can I use test data generated last year with the registry this year?

Yes, but with conditions...

Last year's portals are still active and working and you can use them to submit or access data according to the year 2 XDS specification.

But, the specification has changed slightly for this year, year 3.

The significant change is in the coding of authorName, authorInstitution, authorSpecialty, and authorRole in the Submission Set and Document objects. This change makes metadata submitted last year incompatible with the specification for this year. As such, if you want to submit and query last year'format then use last years portals. If you are engaged in pre-Connectathon testing for this season you must use this year's formats and portals. The Change Proposal (approved by ballot) can be downloaded from here.

Stored Query error - regQuery.jsp: Internal error: Metadata returned from registry could not be parsed

This is a failure that typically means that there is a problem parsing the query request. So far, every instance of this error has been caused by the lack of proper quotes in the query request. As an example, the Stored Query specification requires that when specifing values for query parameters:

  • Single values (for general string values, not numbers) be wrapped in single quotes. This requires a value for $XDSDocumentEntryPatientId be formatted as 'cd0d3e8fe37c4d2^^^&1.3.6.1.4.1.21367.2005.3.7&ISO', including the single quotes.
  • Multiple values be formatted as a parenthetical list of values. An simple example would be ('a', 'b').

In the short term, the Public Registry needs better parsing/error reporting (expect in a few days).

In the longer term I believe there is a flaw in the Stored Query specification that should be fixed at the end of the testing season via a Change Proposal to the Stored Query specification. Single values should be formatted as 

<Slot name="$XDSDocumentEntryPatientId">
    <ValueList>
        <Value>cd0d3e8fe37c4d2^^^&1.3.6.1.4.1.21367.2005.3.7&ISO</Value>
    </rim:ValueList>
</Slot>

instead of 

<Slot name="$XDSDocumentEntryPatientId">
    <ValueList>
        <Value>'cd0d3e8fe37c4d2^^^&1.3.6.1.4.1.21367.2005.3.7&ISO'</Value>
    </rim:ValueList>
</Slot>

Notice the lack of single quotes surrounding the value.

Multiple values should be formatted as 

<Slot name="$XDSDocumentEntryStatus">
    <ValueList>
        <Value>urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Approved</Value>
        <Value>urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Deprecated</Value>
    </ValueList>
</Slot>

instead of 

<Slot name="$XDSDocumentEntryStatus">
    <ValueList>
        <Value>('urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Approved', 'urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Deprecated')</Value>
    </ValueList>
</Slot>

Metadata Attribute Ordering

The ebXML Registry Schema enforces ordering of metadata attributes within all registry objects. Attributes within ExtrinsicObject and RegistryPackage must appear in the following order:

  • Name
  • Description
  • Slot
  • Classification
  • ExternalIdentifier

Why implement both ObjectRef and LeafClass style queries?

(Why require both test 11801 and 11802?)

Any potential document listing can be very long. To use LeafClass queries to generate listing pages (pick lists) would be very slow as this requires the Registry to assemble metadata XML for each document. Starting with an ObjectRef query that returns just the list of identifiers for each document can be used to generate 'page at a time' listing. For each page, a full LeafClass query can be issued to get the content for display. Vendors last year found the ObjectRef query followed by the LeafClass query to be the only acceptable means to produce a query listing page.

Association Names vs. UUIDs

There is some confusion about the use of names vs. UUIDs when filling in the assocationType attribute of an Association object. XDS is based on Version 2 ebXML Registry standard which requires association names such as HasMember when coding associations. The Metadata Validator checks for this.

Does RPLC have to reference an Approved document?

When a document source sends a replacement document (RPLC), does the original document as stored in the registry need to have an "Approved" status? The reason I'm asking is when I query the registry for a document id I want to make sure the user doesn't select an invalid document i.e. Deprecated.

A document in XDS can have the following status
Submitted - in the process of being stored in the registry, in limbo, not yet to be trusted. RPLC should not reference such a document
Approved - good
Deprecated - Has already been replaced. I cannot think of reason why a Deprecated document would be replaced. It has already been replaced. Although, the XDS profile does not specifically forbid it, it makes no sense.

Is the document life cycle managed by the registry or the repository?

The transition from Submitted to Approved is managed by the Registry Adaptor during a submission. A transition from Approved to Deprecated is also managed by the Registry Adaptor when it detects a RPLC Association being submitted in a Registry Submission Request.

Details can be found in Vol 2 page 93

What Assigning Authority Domain is being used for patient IDs this season?

Last year, the domain was

&1.3.6.1.4.1.21367.2005.3.7&ISO^PI

and will be the same for this season's pre-Connnectathon testing. Since there will be multiple registries as Connectathon and Showcase, it is likely that multiple domains will be defined.

Is ATNA required for XDS?

The XDS profile specifically points to the use of the ATNA profile for mutual TLS and syslog services.

What is specifically required for participation in a Connectathon or Showcase? Contact the managers of those events for more information.

When building an Association object for RPLC, do I code the registry UUID or the XDS uniqueId?

You use the registry UUID. Within the Registry, the UUID is ALWAYS used as a pointer to another object.

When creating a pointer that is stored in the Repository, like what happens in the DSG profile, then the uniqueId is used.

How do I translate the CDA document replacement semantics into XDS?

We have two parallel architectures/environments for encoding document relationships. They have almost identical semantics. CDA defines a document format which includes semantics for document relationships. CDA defines a document format that is independent of infrastructure. It defines types of relationships, which XDS uses and it defines a mechanism for 'pointers' between documents. These two combined form a document relationship.

XDS has the same semantics but of course must implement the semantics in the environment of ebXML Registry.

So, to answer your question. The CDA semantics start from the point of view of a document declaring the relationship it has, if any, with a parent document using parentDocument.Id and relatedDocument.typeCode.

The same semantic is coded in registry with an Association object: 

<Association
	associationType="RPLC"
	sourceObject=""
       targetObject=""/>

The associationType comes directly from CDA, RPLC for instance.

The sourceObject is always the CDA you are working with right now, so you should already have a symbolic or UUID based id for it.

The targetObject comes from the parentDocument.id attribute of CDA. Now, filling in this attribute is slightly more work. The ClinicalDocument.id attribute of a CDA should be the same as the XDSDocumentEntry.uniqueId in the registry. There are two cases to be dealt with here, the parent document is in the registry or not. First, let's consider the parent document is in the registry.

You must code the targetObject as a registry UUID. But, given the CDA, you only have the ClinicalDocument.Id (same as the parentDocument.id you started with). So, use the GetDocument XDS query to lookup the XDSDocumentEntry given the XDSDocumentEntry.uniqueId (same as parentDocument.id). Either you find such a document or not. As mentioned above, we are disussing the case where the document is found first. Given the results of this query, you now have the UUID of the XDSDocumentEntry representing the document and can use this UUID to code the targetObject attribute of the association.

The second case is when the document being replaced is not registered in the registry but you wish to encode in the registry the fact that this document is a replacement for a document that is not, at the moment, available. The XDS profile defines the object type XDSDocumentEntryStub to support this situation. The stub is an object in the registry which is a placeholder for the real document object. The detail coding and usage of this object type is not yet fully described in the XDS profile. If you are motivated to work in this area, the rules for using this object can be detailed out for use in the this Connectathon season. If this happens, they will be added to the profile in the next revision cycle.

The Metadata Validator rejects submissions containing XDSFolder.lastUpdateTime

The Metadata Validator is designed to validate either Provide and Register OR Register transaction metadata. The creation and maintenance of XDSFolder.lastUpdateTime is the responsibility of the Registry Adaptor and so this attribute is never seen in these transactions. Of course it is present in the results of a Query transaction.

SubmissionSetStatus attribute of a Submission Set

A document is linked to a Submission Set via an Association object that looks like: 

<rim:Association 
       associationType="HasMember" 
       sourceObject="SubmissionSet" 
       targetObject="theDocument101"> 
    <rim:Slot name="SubmissionSetStatus"> <!-- this value is fixed --> 
           <rim:ValueList> 
                    <rim:Value>Original</rim:Value> <!-- this value is either "Original" or "Reference" --> 
           </rim:ValueList> 
    </rim:Slot> 
</rim:Association>

The slot value is set to "Original" when the DocumentEntry metadata of the document being submitted is embedded in the submission set xml. The slot value is set to "Reference" if the DocumentEntry metadata already is in the registry and not a part of the submission.

One interesting note, if the SubmissionSetStatus is Reference then the sourceObject in the above Association will always contain a UUID of an object already in the registry.

Precision of time specification in XDS

For sourcePatientInfo, PID-7 is a HL7 TS type. This is of the format DTM^<degree or precision>. DTM's pattern is DTM format: [YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]]][+/-ZZZZ].

In my submission I have 

        <rim:Value>PID-7|19680820051044.5600+0000</rim:Value>

which fits the DTM pattern. Will the validator be expcting times only to YYYYMMDDHHMMSS precision or less?

There are several HL7 date-time datatypes. In XDS the HL7 V2.5 DTM definition is used, not the TS definition. The TS definition allows for ^<degree of precision> component, but DTM does not. However, I think the bulk of the question has to do with the fractional time part. XDS could include the [.S[S[S[S]]]] part in the description of DTM in the specificaiton. However it is of limited use for registry purposes, except to deal with diagnostics. Even then, XDS does not require any clock precision better than 1s of (using CT allows for SNTP which is limited to 1s), so anything after the second is potentially only what the submitter thinks, not what the client and registry agree upon.

These are the attributes that use DTM:

XDSDocumentEntry.creationTime

XDSDocumentEntry.serviceStartTime

XDSDocumentEntry.serviceStopTime

XDSSubmissionSet.submissionTime

XDSFolder.lastUpdateTime

XML Declaration and SOAP

The first thing that should appear in any XML document is the XML declaration. An example is:

<?xml version="1.0" encoding="UTF-8"?>

When the XML in question is a Submission Request to a Repository or Registry, this XML must be wrapped in an appropriate SOAP wrapper. One important thing to consider is that if the Submission Request has at the top an XML declaration, it is not copied into the SOAP wrapper. So as an example, an empty submission looks like this (with the XML declaration in place): 

<?xml version="1.0" encoding="UTF-8"?>
<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>
    </LeafRegistryObjectList>
</rs:SubmitObjectsRequest>

When this is wrapped in the necessary SOAP: 

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
  <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>
      </LeafRegistryObjectList>
  </rs:SubmitObjectsRequest></SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Note that there is no XML declaration in front of the SubmitObjectsRequest element (inside the SOAP-ENV:Body element).

If you insert the XML declaration you will get an XML parse error from the server or possibly your own encoding software on your client. Some XML parsers give very cryptic error messages in this situation.

How do you configure Tomcat for mutual TLS?

Here is a web site that discusses mutual TLS configuration issues for Tomcat.

How is the parentDocumentID attribute implemented?

This is functionality that originates out of HL7/CDA where a document can have a parent document which it replaces or transforms or amends. In CDA land you have to point to a second document with an OID, remember CDA is an architecture that does not specify any storage mechanism. In registry, all relationships between documents are implemented with Association objects. A Parent ID gets translated into the targetobject attribute on the Association.

Are UUIDs case sensitive?

Yes, they shall be in all lower case. The following text has been added to the framework to clarify:

3.14.4.1.2.13.3 Formatting of UUIDs

UUIDs shall be formatted according to RFC4122. Furthermore, values 10 through 15 shall be formatted in hexadecimal using lower case ‘a’-‘f’. An example of a properly formatted UUID is urn:uuid:10b545ea-725c-446d-9b95-8aeb444eddf3

Format Code, mimeType and typeCode for XDS-MS

  1. For format code, "PDF/IHE 1.x" is meant to be used by Wrapped PDF only,

and we will leave out raw PDF for now.

  1. For mime type, we will use "text/xml" for both XDS-MS and CDA wrapped

PDF.

  1. For type code, if there are two documents (one XDS-MS transfer summary

and one CDA wrapped PDF describing the XDS-MS doc), both docs will use 

<Code code="18761-7" display="Transfer Summarization Note" codingScheme="LOINC"/>

Error message - Owners not found for object urn:uuid:...

This error message can be generated when a submission contains a poorly formatted UUID. The one case we have seen included a UUID of

urn:uuid:900240f0affc-4eac-c0cc-00096b06e1a6

when it should have been

urn:uuid:900240f0-affc-4eac-c0cc-00096b06e1a6

(Note missing hyphen)

When do I add an ObjectRef to metadata?

As background one must understand the Id/IdRef facility in XML. Within XML Schema, attributes can be declared of type ID or IDREF. An element with an ID-type attribute can be pointed at. The ID is the label. An attribute of type IDREF points to an element containing an ID-type attribute. Each IDREF must have a matching ID to point at within the document. No dangling pointers are allowed.

ebXML Registry Schema depends heavily on this Id/IdRef mechanism.

An example is a submission containing a RegistryPackage and a Classification. The classification declares the RegistryPackage to be a submission set or folder. The RegistryPackage object has an attribute id of type ID. This tells us it can be pointed to. The Classification object has an attribute classifiedObject of type IDREF. This must point to an object containing a attribute of type ID. Pointing is achieved by having the ID and the IDREF contain the same value. In general, the value of IDREF must match an ID of same value within the XML document. Otherwise, the XML document is not valid XML.

A more complicated example is when some tiny piece of our XDS submission must point to some data already in the registry. This happens for several reasons: reference to a Classification Scheme, reference to an ExtrinsicObject, etc. Such a reference is always coded as a UUID by registry rules.

But, this reference to data in the registry must also fit into the rules of XML. All of these attributes that act as pointers are defined as type IDREF. There must be a matching ID within the XML document (XDS submission) to reference or our submission is not valid by the rules of XML. To achieve this, the registry standard includes the XML element ObjectRef. An ObjectRef declares that a particular UUID is known to represent an object in the registry.

How can the Document Source know the UUID assigned by the Registry to a piece of Metadata?

Neither the Provide and Register transaction nor Register transaction can return UUIDs. There are two ways for the Document Source to know the UUIDs:

  • Code raw UUIDs in the submitted metadata
  • Have the Document Source actor bound to a Document Consumer actor and discover the UUID via query

The only way for the Document Source to know the UUIDs is to assign them itself.

Do queries start with SELECT * or SELECT eo.id?

SQL allows both forms as does the ebXML Registry Standard. XDS has published a fixed collections of queries to be used with the Document Registry actor. Those queries specifically show the "SELECT eo.id" format. Document Registry actors are not required to accept the "SELECT *" format.

How are updates to these queres published?

Many issues have been found with the queries documented in this season's version of the XDS Profile. Updates to the queries are published in the XDS testkit. The text of the profile will be updated at the end of the Connectathon season. If you have problems with one of the queries, please start a discussion on one of the appropriate forums.

Why does XDS use External Classifications for document coding?

Both Internal and External Classification systems are available in ebXML Registry. In XDS the use of Internal Classifications was avoided for document coding. When a Classification object is returned that references an Internal Classification, the user must another query to the registry to look-up the names of the classification referenced so that a results listing can be produced. With an External Classification, the coded value is returned in the Classification object in the original query result. Since we expect XDSRegistry servers to handle a very large load and individual listing displays will likely contain many documents, we made several design choices to minimize the number of requests to the XDSRegistry server required to produce a listing display.

How can documents from two different patients be linked?

There is a single mechanism for linking documents to more than one patient. The typical use case for this mechanism is the recording of documents regarding child birth. It is necessary to know information about both the mother and child.

Under special conditions, a Submission Set can reference documents associated with more than one patient ID. The following rules apply.

1) A Submission Set shall be submitted with content belonging to only a single patient ID. The patient ID is present in the coding of the Submission Set and each document in the Submission Set.

2) In the initial submission (submission set with documents), the association object linking a document to the submission set shall have a SubmissionSetStatus Slot with value 'Original'.

3) After a submission set is in the registry, documents can be added to it. The associations use to link new documents into an existing submission set shall contain the value 'Reference' in the Slot SubmissionSetStatus.

4) These referenced documents, of course, must be submitted as part of a new submission set where they have 'Original' status and the normal rules of a submission set must be followed.

5) The association objects used to link referenced documents into an existing submission set can be submitted alone in a submission or as part of the submission discussed in the preceeding step.

6) There is no restrictions on the patient ID of these 'referenced' documents. This allows documents of a second patient to be linked into submission set. This was needed because submission set is the primary mechanism for grouping and establishing context around documents.

These rules are more complicated that they need to be because the submission set is a mechanism with two separate purposes: manage the transactional nature of a submission (all or none, no partial submissions following an error) and to create clinical contexts for documents.

The submission set mechanism is the only 'cross patient linking' documented in XDS. Folders are not so enabled. All documents in a folder shall contain the same patient id.

There is no mechanism in XDS for allowing the patient ID of the document content (bits in the repository) to be different from the XDS metadata in the registry. More specifically, XDS does not document ANY discussion on the content of the Document Repository. But, there is an implicit understanding that the content of the XDS metadata reflects the content of the document in the repository.

Doesn't the XDSDocumentEntry.hash attribute restrict the implemenation of the Document Repository actor

The Document Repository actor is required to compute the hash and size of each document it holds and forward these attributes to the Document Registry in the Register Document Set transaction.

There are two ways to think about repository implementations relative to the size and hash attributes.

One implementation style is to have a repository store documents in a filesystem and implement the Retrieve Document transaction via a web server like Tomcat or Apache. In this situation the calculation of hash and size could be simple operations on files.

Another implementation style would be to view an existing product database as a repository and produce document formatted information on demand for the Retrieve Document transaction. This style brings with it implicit restrictions on the database and the software surrounding it.

By offering the XDS interfaces/transactions the implementing system agrees to provide the interfaces faithfully. Given this implemenation style, the following assertions are important:

  • The hash and size attributes submitted to the Document Registry actor in a Register Document Set transaction for a document must exactly match the size and hash of the document produced in a subsequent Document Retreive transaction.

There are several simple mistakes that could be present in an implemenation of the Document Repository actor that would cause the above assertions to fail:

  • Database fields representing content of a registered document are allowed to be altered after the document is registered with a Register Document Set transaction
  • Formatting of the content for presentation as a document is not consistent.

What are the hash and size attributes used for?

First the Document Consumer actor has the ability to verify the content was delivered correcly by calculating the size and recomputing the hash. More importantly, the Digital Signature profile (DSG) uses the hash to show that the document that was digitally signed is the same document being viewed.

Why are all the queries defined in the Stored Query transaction patient oriented?

All queries defined as part of the Stored Query transaction include a required 'patient ID' parameter because XDS, in its basic form, is patient record oriented.

There are many other potential uses for XDS such as public health surveillance where queries are not specific to a single patient. We anticipate that new and separate profiles will be created to focus on individual areas of this type. Each of these profiles will produce a set of queries for the Stored Query transaction which would be designated 'required' if an implemenation supports that profile.

What is the difference between mimeType and formatCode?

A MIME type is a label reflecting the content type or formatting of a document. Text/plain, application/pdf, and text/xml are well known MIME types. But, MIME type is no longer a sufficient label for documents. As an example take text/xml. An XML file could be a CDA R1, CDA R2, XDS-MS, XML Schema etc. You cannot tell which until you open the document itself. But, frequently we know the content type of the document we are searching for and having the real (meaning more detailed) content type available in metadata is an aid to search. The formatCode attribute holds this more detailed content type label.

The XDS profile does not stipulate the values to be used in the formatCode attribute. They are a part of the configuration of an XDS Affinity Domain.

The major objects, XDSDocumentEntry, XDSSubmissionSet, and XDSFolder, are labeled with redundant type information, why?

The short answer is because it makes easier to code different types of query.

XDSDocumentEntry, XDSSubmissionSet, and XDSFolder each have at least two ways they can be identified by query:

  • XDSDocumentEntry
    • objectType
    • PatientId attribute type
  • XDSSubmissionSet and XDSFolder
    • Classification on object
    • PatientId attribute type

First let's define what these mean. In creating an XDSDocumentEntry object, we use an ExtrinsicObject with objectType set correctly as in 

<ExtrinsicObject objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"/>

This objectType value is unique to XDSDocumentEntry objects.

In addition, the metadata to create the patientID attribute also specifies the identificationScheme for patientID which is unique to XDSDocumentEntry 

<ExternalIdentifier 
   identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" 
   value="NIST-test-1^^^&1.3.6.1.4.1.21367.2005.3.7&ISO">
         <Name>
              <LocalizedString value = "XDSDocumentEntry.patientId"/>
         </Name>
</ExternalIdentifier>

Which one should be used in a query? It doesn't really matter, but if the query is based on the patientID then the identificationScheme of the ExternalIdentifier defining the patientID attribute is easier because it is already involved in the query.

In a query that is not patientId based, it is probably faster to use the objectType.

For XDSSubmissionSet and XDSFolder, based on the RegistryPackage object, a different technique must be used to label the datatype. On RegistryObject, the objectType attribute is restricted. Instead, a Classification object is created labeling the RegistryPackage as either XDSSubmissionSet or XDSFolder. For XDSSubmissionSet this looks like 

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

Again, like the patientID attribute, the XDS profile defines a different ClassificationNode for XDSSubmissionSet and XDSFolder. Simple queries for all SubmissionSets could depend on the Classification of the RegistryPackage. Otherwise, if the patientID attribute is involved in the query, then identificationScheme used to define the patientID attribute is easier.

How are Documents organized into Submission Sets?

XDS requires that documents must be submitted as part of a Submission Set. The Submission Set documents the context of the submission and the knowledge of the things that were submitted together. What does a Submission Set look like? First there are one or more XDSDocumentEntry objects each representing a single document in a repository. The XDSDocumentEntry is constructed from an ebRIM ExtrinsicObject object. Next is the XDSSubmissionSet object which contains the submission context information. It is built from an ebRIM RegistryPackage object. For each XDSDocumentEntry object an Association object is coded. This object is used to link the submission set object to the document object. If there are 3 documents in the submission set then there will be 3 association objects creating the linkage. Each association has three basic attributes, a from pointer, a to pointer, and an association type. For this use the association type is HasMember.

As an example of a submission set containing a single document, there would be 3 objects coded in the submission: an XDSSubmissionSet object, an XDSDocumentEntry object, and an Association object linking them. All three of these objects must be submitted together in a single Register transaction.

As a Document Source, how can I later reference my submissions?

There are three ways. The registry standard allows the submitter to pre-assign UUIDs (internal registry identifiers) to the objects it submits. Submitting a later reference to the document requires having this UUID. This approach is legal but discouraged. There are potential additions to the XDS profile in 2007-2008 that would make this awkward.

The next approach makes use of the uniqueID attribute assigned to a document. The Document Source could use the GetDocuments query specifying the document uniqueID while specifying the query returnType of ObjectRef. Only the UUID of the document is returned.

The last approach is to discover the document via an arbitrary query, extract the UUID of the document and then send a submission referencing it.

How do I code XDSDocumentEntry.parentDocumentId attribute?

The parentDocumentId is a very poorly conceived and documented attribute. In fact, it is not an attribute of either XDSDocumentEntry or XDSSubmissionSet. It is a side-ways reference to the Association object that is used to link two documents. Documents are linked, to create a replace or append or transform relationship, by creating an Association object with type RPLC, APND, or XFRM.

In XDS-I, how do I link a report to an existing study?

Since I do not work directly on XDS-I this is only my opinion. Please send me feedback if this answer seems wrong in any way.

In XDS-I according to section 4.54.4.1.2.4.1 Linking Report to Set of DICOM Instances and specifically Figure 4.45.4-1 it looks like you create a new submission set containing the final report (by value) and the study (by reference). The difference between 'by value' and 'by reference' is documented in XDS in section 3.14.4.1.2.4 Submission Set Specifications.

If I am a consumer, how do I determine that this study and report are linked?

The association objects linking a submission set and a document must have a Slot named SubmissionSetStatus. A value of Original indicates that the document was submitted with the submission set (by value). A value of Reference indicates the document was actually submitted as part of another submission set but is included here for an application specific purpose (by reference). The action of linking a report to a set of DICOM instances uses this. You can tell they are linked by ignoring the SubmissionSetStatus attribute. What I don't see is when you list these submission sets, how you tell that they are related. In the diagram, they are labeled Submission Set 1, Submission Set 2, and Submission Set 3. You will have to ask the Rad Tech folks how you know they are related. You know which is most recent by the XDSSubmissionSet.submissionTime attribute.

Retrieved from "http://wiki.ihe.net/index.php?title=XDS-FAQ_2&oldid=114467"