SUT Operator

DG DGIT is developping specifications for the OOTS (eWallet) project. Conformance tools have been developped using the GITB framework, and more especially the Test Bed’s XML validator. 

In this context, DG DGIT want to use the Gazelle Test Bed to execute the peer-to-peer test cases. To ease the verification of the exchanged messages, the Gazelle Proxy shall be able to call the Conformance tools through EVSClient. In other words, EVSClient shall be extended to call the GITB SOAP API (or alternatively the REST API).

Time constraints: A Projectathon is scheduled for mid-April 2023 (Week 16).

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.