MHD Testing at 2018 North American Connectathon

MHD Testing at 2018 North American Connectathon

Table of Contents

• Status
• The alignment of MHD and FHIR Transactions is not quite right.
  • ITI Resolution
• Returning the Patient resource reference in responses from an MHD Document Responder
  • ITI Resolution
• Light weight multiple repository support
  • ITI Resolution
• Codes translation
  • ITI Resolution
• PDB Response Bundle
  • ITI Resolution

Below are issues that came up in Cleveland. Along with each issue I have included comments from the ITI Technical Committee discussion on Thursday February 22 in Oslo.

Status

These issues have been submitted to the ITI Technical committee as Change Proposals.

The alignment of MHD and FHIR Transactions is not quite right.

FHIR transactions are all or nothing. This is the classical definition of a transaction. But when it comes to document relations it seems to mean something else in MHD which is a problem. I’ll use document replace as an example but it applies equally to other document relationships and linkage to Folders/Lists.

The documented warnings are PartialReplaceContentNotProcessed, PartialTransformContentNotProcessed, PartialAppendContentNotProcessed, and PartialFolderContentNotProcessed.

In XDS a document replacement is three bound operations, submit a document, link it to the document it replaces, and deprecate the document it replaces. Being a transaction guarantees all three parts are executed or none.

In MHD, a Document Recipient can reject the replaces part with a warning and still accept the new document entry. The deprecation and linkage are optional behaviors. This is wrong in two ways.

First, how does optional behavior align with the all-or-nothing requirement of a transaction? I believe this is either undefined or just plain wrong. Second, if the MHD Document Source is working in a larger XDS environment, this is incompatible with XDS semantics - the MHD Document Source sees an MHD Document Recipient (with or without the XDSonFHIR option) so does not know what the semantics will be. So, relationships, if requested by the source and not supported by the recipient, must generate an error and store nothing. In short, XDS semantics must be preserved through MHD.

This still leaves the IHE customer needing to specify that only implementations that support relationships can be used in their environment. This behavior is not required or described as an option on an MHD Document Recipient so an additional specification must be written without direct IHE support. This issue is independent of the XDSonFHIR option which only deals with how the MHD Document Recipient implements the XDS semantics. Since MHD was conceived to be a mobile extension to XDS it should support XDS semantics and these warnings should be removed and support of relationships should be required behavior of an MHD Document Recipient.

ITI Resolution

A CP will be produced to change these WARNINGS to ERRORS.

Returning the Patient resource reference in responses from an MHD Document Responder

The Provide Document Bundle transaction requires the target Patient to be defined by a reference to a Patient resource which is resident on a live server and the reference is via a reference to that Patient resource via its URL.

This Patient resource must be discovered twice during an MHD workflow. First it must be discovered and a reference included in the Provide Document Bundle transaction. It must also be discovered and included in any Find Document Reference or Find Document Manifest query responses from the Document Responder.

For several implementers, passing the MHD tests this year included an ah-ha moment. The new tooling verified that the Patient resource references included in the response messages were live (could be READ). This brought up two points of discussion: how does the Document Responder know where to find the Patient resources and does it have to be the same Patient resource reference that was included in the submission?

Note that no supporting profiles such as PIXm were used or were part of the discussion.

The obvious answer (only obvious to some after discussion at the event) was that the profile does not offer guidance or requirements on either point. It was considered generally bad form to have the submission reference one Patient resource instance and have the query response reference a different Patient resource instance. Continuity should be maintained. Beside the obvious motivation to use PIXm, one vendor offered a partial solution. Use DocumentEntry.referenceIdList to store the Patient reference URL so that the XDS to MHD translation function could reliably return a reference to the same Patient resource.

This was not offered as a final solution but instead as a stepping stone as software designers come to grips with the architectural requirements of moving to FHIR. I summarize these requirements next.

In XDS and older versions of the HL7 standard the focus was on building messages that could, to some degree, stand alone and be interpreted without reference other information sources. FHIR forces an architectural shift requiring a live network of resources be accessed to interpret any one piece of data (resource).

So, for some, they came in thinking of MHD as a new way to code XDS and left realizing they have a much larger problem to solve, manage referential integrity of health data, even at this low level of the overall health data architecture.

ITI Resolution

The use of referenceIdList is probably a bad idea. An extension to sourcePatientId or sourcePatientInfo should be developed.

Light weight multiple repository support

Some MHD implementers are interested in making their MHD support as light weight as possible. We found a complication when there are multiple repositories surrounding a registry in the XDS environment behind an MHD Document Recipient.

The core of the problem is that the implementer wanted to code the repository into the resource URL so that a round trip to the registry was not needed. More specifically…

A query for Document References returns a collection of DocumentReference resources. Once the MHD Document Consumer has the collection of Document References they would like to get the document contents in one round-trip.

The focus is on the server that implements the MHD Document Responder and the XDS Document Consumer.

On that server, given the FHIR formatted URL of the Document Reference, must query the registry to find out which repository holds the document to enable the retrieve. One implementer coded this additional information in the resource reference returned for the Document Reference. Our tools rejected this because it did not align with the URL format requirements imposed by the FHIR specification. FHIR stipulates baseURL/ResourceType/ResourceID as the format. There is nowhere to code the repository. As I recall the implementer coded baseURL/ResourceType/repositoryID/ResourceID.

One way to accomplish this would be to encode the repositoryUniqueId in the baseURL and have the proper URL mappings in place. I did not think of this while at Connectathon so it was not discussed or evaluated as a possibility.

ITI Resolution

This is covered in the MHD supplement. These URLs were not intended to meet the Reference URL format required by FHIR. It was acknowledged that this could be made easier to find in the MHD Supplement.

Codes translation

The code format required in XDS (coding system identified by an OID without) must map to several possible formats in FHIR.

ITI Resolution

There are several possible translations between codes as currently required by XDS Affinity Domain design and FHIR. This is an ongoing concern in both IHE and FHIR.

PDB Response Bundle

Section 3.65.4.2.2 Message Semantics refers to

http://hl7.org/fhir/STU3/http.html#transaction-response

Which states

“Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values”.

Within Bundle the status code is 1..1, the location is 0..1, and the ETag is 0..1. This is pretty cloudy. I believe the profile should offer clarification. I think the write answer is:

Status is required Location is required ETag is required IF the server supports versioning.

And the MHD profile should offer shall language in this section.

ITI Resolution

It was agreed that this needs work.