Ad-hoc testing

The IHE XDM (Cross-Enterprise Document Media interchange) Profile defines how data are exchanged on a media (USB stick, DVD, email). In particular, it specifies the content of the ZIP archive being exchange on those media.

ANS requires the XDM profile to be used when documents (for examples CDA) are exchanged over MS Santé (Messagerie Sécurisée en santé).

As of March 2022, the following conformance checker tools are used and involved in the verification of the XDM requirements:

• Message Content Analyser (MCA) detects the various parts of the ZIP archive and allows to validate those parts independently the ones from the other
• Schematron Validator is called to verify the conformance of the CDA files included in the XDM archive
• XD* Client is called to verify the conformance of the XDS metadata
• Gazelle X Validator is used to verify the consistency of the XDS metadata with the CDA file it describes.

Although this verification requires several clicks, it is integrated in EVSClient and achieves a lot of work.

However, there are several issues that needs to be considered:

• The XDM archive might contain more than one CDA document; in that case the XDS metadata describes the submission set and each CDA file;
• The X Validation is only specified/performed between the XDS medatada and a single CDA document
• The output of the Message Content Analyser module reports failures to find optional content
• For each CDA, the user has to select manually which validation profile (aka Schematron) to use whereas it could be selected based on the templateIds contained in the document;
• There is no automation of the validation process; as a consequence, many clicks are required to obtain a comprehensive report about the conformance of the whole archives.

ANS expresses the need to review the workflow in EVSClient to perform the XDM archive validation in one-click.

This high level need implies the following:

• As a SUT Operator, I want to see the results of the message content analyser, the analyses logs shall not be displayed since they content misleading level of details.
• As a test designer, I want to link a given schematron with one or several CDA template Ids that shall be present in the file, to allow an automatic selection of the schematron to be applied.
• As a SUT Operator, I want EVSClient to detect automatically the validator to use when validating a CDA document
• As a test designer, when developing a X Validation profile for an XDS Submission set, I would like to tell the tool to iterate some of the rules with a different file each time
• As a test designer, when developing a X validation profile for an XDS submission set, I would like to tell the tool to automatically select the file on which the rule applies based on the document the metadata describes.

For those last two points, it relates to the structure of the XDS submission set within the XDM archive. The XDS metadata are gathered in a file that has:

• one section that describes the whole submission set;
• one section per file within the submission set; this section contains a location attribute that gives the name of the file the metadata relates to

The number of files, as well as their names, are not known in advance when developing the X validation rules. Thus, the test designer need a way to tell the tool that rules A applies on element Metadata[f] of the metadata and on File f; and the X Validator will automatically iterate and choose the relevant file and element for each execution. 

Gazelle test bed offers numerous features and most of them are targeted to well-defined categories of users. Thus, there is a need for the tool administrator to decide which users can access which features. As a consequence, the users who interact with the test bed shall be uniquely identified and be granted with the relevant permissions based on the features they are allowed to access.

In the EU countries, management of identities is ruled by the GDPR. Other local privacy regulations might apply and Gazelle shall comply to them.

IHE defines a lot of profiles that relies on HTTP protocol for the transport. However, Gazelle does not cover the conformance verification of the HTTP header. 

Gazelle currently offers:

• SOAP body verification, for the SOAP webservice based transactions;
• FHIR resource / URL verification, for the FHIR-based transactions.

Although most of the profiles do not specify additional requirements on the HTTP header, some other do and its content might influence the behaviour of the targetted system under test. 

As a test designer, I want to make sure that a system under test use appropriate content in the HTTP header when communicating with peers.

As a SUT operator, when I verify the conformance of a message sent over HTTP (or HTTPS), I want the verification to include checks on the HTTP headers. In particular, I want to know:

• Whether all the expected HTTP headers are present in the message issued by the system under test;
• Whether the values of the HTTP headers are correct regarding the specification requirements
• Whether no forbidden HTTP header is present in the message.
• Optionaly and if it applies, whether the content of the message is correctly reflected in the HTTP headers.

As a developer of a conformance checker tool, I want to be able to implement the requirements on the HTTP headers in a specific context (IHE Transaction or derivative).

The WIA, WIC, and AIR profiles define transactions that leverage the DICOM JSON Model either for the request or response HTTP payload. A SUT operator implementing on of those transactions in his product wants to verify the conformance of the messages the latter produces.

As of March 2022, the IHE transactions to consider are:

• RAD-108 (Store Instances over the Web / STOW-RS); 
• RAD-129 (QIDO-RS Query / QIDO-RS);
• RAD-107 (WADO-RS Retrieve / WADO-RS).

Several levels of verifications are expected:

• Is the message syntax valid regarding the JSON standard?
• Is the message valid regarding the DICOM JSON Model?
• Is the message valid regarding the specific requirement of the transaction I am implementing?

For each level, the SUT operator expects to understand whether the message is valid or not. If not, he wants to be able to fix the issues. That is to say that he needs to know:

• Which verification level is failing;
• Where the error is located in the message;
• Which requirement is not met that causes the validator to report an error.

The SUT operator wants the conformance checker tool to be made available in the cloud (no need to install a software locally). Ideally, the SUT operator shall be able to perform the validation:

• From Gazelle Proxy if the message was captured in the context of an interoperability test;
• From EVS Client user interface, by uploading the JSON file;
• From EVS Client API, in the context of integration testing.

As an output, the SUT operator shall be able to download a report and to see its content directly into EVS Client.

Gazelle platform stores cookies and information about individuals. According to the GDPR terms, the user shall at least be informed of the data collected and the usage the system makes of it.

The Gazelle test bed home page as well as the Gazelle applications shall comply to this EU regulation.