Model/Test Designer

ANS has defined a new business use case that allows the sharing of imaging among practioners that are not on the same network. The DRIM-M project relies on the fact that a DICOM KOS is published in the patien health record and contains pointers to the images that are stored in the PACS of the facility where the exam took place. When the practitioner wants to access images that are referenced in an imaging report, he first retrieves the DICOM KOS and then use the RAD-107 transaction to retrieve the images in the PACS.

Two actors are involved in this process:

• the DRIMBox source is the system (or component of a system) that acts as a gateway to the PACS. It behaves as the Imaging Document Source actor of the IHE WIA profile
• the DRIMBox consommatrice is the system (or component of a system) that initiates the RAD-107 transactions to retrieves the images. It behaves as the Imaging Document Consumer actor of the IHE WIA profile.

In the context of the Segur program, ANS wants to verify the ability of

• the DRIMBox consommatrice to send out an HTTP request to the DRIMBox source that complies with the DRIM-M requirements;
• the DRIMBox source to build an HTTP response that complies the the DRIM-M requirements.

The SUT operator shall be able to verify the conformance of the message by either:

• Uploading the message content in the EVSClient
• Selected the message to validate in the Gazelle Proxy

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).