SUT operator verifies the conformance of a DICOM JSON Model based message

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.