MHD server with XDS back-end

[Ernst Lawende]

Hi all,

tldr; is it possible to pass the MHD server tests in the FHIR toolkit when using an XDS back-end?

We have implemented an MHD service using an XDS back-end which we want to test during the Connectathon next week. As part of preparatory testing, I use the NIST FHIR toolkit to run some tests.

The MHD server tests (both comprehensive and minimal) start with the following steps:

1. Post a Bundle (with a DocumentManifest, DocumentReference, and Binary). The server transforms this to XDS format and sends it to an XDS repository as an ITI-41 message (ProvideAndRegisterDocumentSet).
2. Read the DocumentReference which was included in the Bundle. The server queries the XDS repository for the DocumentEntry (XDS), transforms it back to a DocumentReference and returns this resource.

The test validation expects the value of `subject.reference` to equal the submitted value (which is a url pointing to the toolkit). However, in XDS the patient information cannot be expressed as a reference to a FHIR Patient resource. Instead, the DocumentReference in the server response has a contained Patient resource. This leads to the following error in the test:

Eval expression: DocumentReference.subject.reference
Expected http://localhost:9760/asbestos/proxy/default__default/Patient/5
Operator is equals
Found #wa3W82LXWpql

Because "FHIR systems are not obligated to store and return data as it was received" (http://hl7.org/fhir/R4/updates.html), I think this validation is too simple (resolving the reference and validate based on patient identifier would be better, although more complicated). Anyway I don't see how to pass the test without some form of a FHIR-native repository/registry. Is it possible to pass using an XDS back-end? Has anyone done this before?

kind regards,

Ernst Lawende

[John Moehrke]

This would be best asked of the connectathon channel, as you are asking about connectathon capabilities.

as to the question.. it should be possible. This is indeed a configuration intended for MHD especially the XDS-on-FHIR option.

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security
IHE Co-Chair IT Infrastructure Planning and Technical
HL7 Co-Chair Security WG, FHIR FMG, FHIR facilitator, and FHIR Foundation founding member

Employee of By Light -- Contractor to VHA MyHealtheVet
JohnM...@gmail.com  |  M +1 920-564-2067  |  John.M...@bylight.com
 https://healthcaresecprivacy.blogspot.com

--
You received this message because you are subscribed to the Google Groups "IHE MHD Implementors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-mhd-implemen...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ihe-mhd-implementors/ee8ff241-0a38-4026-a448-605a0e96ec9bn%40googlegroups.com.

[Oliver Egger]

Hi Ernst

Because "FHIR systems are not obligated to store and return data as it was received" (http://hl7.org/fhir/R4/updates.html), I think this validation is too simple (resolving the reference and validate based on patient identifier would be better, although more complicated). Anyway I don't see how to pass the test without some form of a FHIR-native repository/registry. Is it possible to pass using an XDS back-end? Has anyone done this before?

We had a university last week at the Swiss Projectathon which did exactly those tests with NIST Toolkit and a gateway to map from MHD to XDS and back:

- For the ITI-65 transaction the NIST Toolkit provides the Patient with an endpoint where the identifiers can be extracted and the selected identifier used in XDS (e.g. assigning authority IHERED .... etc) will be used for ITI-41.

- For ITI-67 the inverse needs to be done, the patient identifier used in XDS needs to be translated back by querying the provided NIST FHIR server and returning the patient url based on id/assigning authority.

This is also described in MHD, patient, see https://profiles.ihe.net/ITI/MHD/ITI-65.html#23654122-patient-identity:

If the Patient Resource is accessible to both the Document Source and Document Recipient via an external reference to a commonly accessible server then that external reference shall be used and the Patient Resource will not be included in the Bundle. Otherwise, the Patient Resource shall be included in the Bundle.

In this scenario I would expect that the patient retrieved from the DocumentReference ITI-67 should also be the external reference like the NIST Tooolkit does the test. This is also very transparent for the client application, why should it be able to handle/understand suddenly other patient id's?

There are however other scenarios possbile as described in https://profiles.ihe.net/ITI/MHD/ITI-65.html#23654122-patient-identity

I will be a monitor next week in Rennes, looking forward to what you come up :-)

Best regards,

Oliver