Connectathon

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.

This is a user need defines in the context of the new Gazelle product. 

As a participant (SUT operator) to an interoperability testing event, I want to execute a peer-to-peer test with one or more other systems under test and report the result of the execution to the event management team, for review and grading. To prove the correct execution of the test case, I might be asked to provide evidences of the following types:

• Screenshots;
• Messages exchanged between the systems;
• Log files.

The workflow involves 2 main actors (we don't check the IDP part) :

• The Authorization Client : A client that retrieves access tokens.
• The Authorization Server : A server that issues access tokens to requesting clients.

In order to check the compliance a complete ITI-71 transaction, I need to validate :

1. The Get Authorization Code request (Http GET message).
2. The Get Authorization Code response (with the code).
3. The Get Access Token Request (Http POST message, code included).
4. The Get Access Token response (with also a Token validation).

The steps of this workflow SHALL be tested either for a Basic Token or an Extended Token.

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

In Gazelle Test Management, the tests are executed from the Test execution page. This page also logs all the runs executed by the systems. The test runs are linked to the test case they relate to.

The test execution page shows only the test cases with a status set to "ready". As a consequence, if a test case is deprecated at some points, the SUT operator cannot access the test runs that were executed when the test case was "ready". 

In the same way, the "All test runs" page displays only the test runs that relates to the "ready" test cases.

As a consequence, we experience a loss of information and that is not accessible neither from the SUT operator's or Testing Session Manager's point of view.

• As a SUT Operator, I want to see all the test runs that have been executed by a system under test owned by my organisation, during a given testing session, at any time.
• As a TSM, I want to see all the test runs that have been executed during a given testing session, at any time.
• As a user, for each test run, I want to see the following details:
  • Test run identifier
  • Test case keyword (and a link access its details)
  • Whether the test case is currently deprecated
  • Last update date/time
  • Test run status
  • The role assigned to my SUT in this particular test run
  • The other partners
  • The status of the test run
  • If a monitor is assigned, his first and last names
• As a user, I want to be able to access the test run page for any test run (whatever the status of the test case is)
• As a user, I want to be able to access the description of the test case.
• As a user, I want to be able to filter on
  • System (name/keyword)
  • Test case keyword
  • Monitor
  • Type of test
  • Domain
  • Tested profile
  • Tested actor
  • Tested profile option
  • Involved transactions
  • Test run status
• As a testing session manager or admin user, I want to be able to filter by Organisation (name/keyword)
• As a user, I want the test runs to be grouped by tested SUT capabilities
• As a user, for each SUT capabilities, I want to see the evaluation.
• As a user, I want to be able to sort on test case and test status within each SUT capability.

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.

During online events, we want the participants to a test run to be able to chat with each other. They might also need to share their screen or to exchange logs or screenshots that do not need to be logged in Gazelle Test Management.

Participants to the online events expect this capability to be offered also for face-to-face test events.

The chat room is convenient to share short information that are relevant to the execution of the test but not for large logs or images.

As a SUT participant, I want to have a dedicated place where I can chat with my test partners, share my screen, share images, and start calls if needed.

As a monitor, I want to be able to chat with the participants to the test run I am grading. When online, I might also need to view their screen or ask them images. I might also need to start a short call with them.

During past events, we created one test channel per test run. Gazelle Test Management shall be able to manage those channels for the users.

When navigating and working in Gazelle Test Management, the users need to access other test tools in order to execute the test cases.

As a tool administrator, I want to provide the links to the tools of interest for the users to access them from whatever page in Gazelle Test Management. This list shall be organised according to the project's context. 

As a SUT operator or a monitor, I want to see the links to the test tool I need to use when I execute/grade tests. The links shall be available on all the pages so that it is very quick to find the pointers.

Currently the SUT operator can execute tests from two pages:

• Connectathon > Pre-Connectathon > Pre-Connectathon results
• Connectathon > Connectathon > Connectathon

It is confusing and both pages need to be reviewed in order to give a better level of information to the SUT operator.

As a SUT Operator, I want to execute preparatory tests as soon as my system is accepted to the test session.

As a SUT Operator, I want to execute the Connectathon/Projectathon/Conformity assessment tests during the test event, for accepted systems.

As a SUT Operator, I want to filter the test plan based on my system's capabilities.

As a SUT Operator, I want to see a summary of all the test runs for my systems along with their status.

As a SUT Operator, I want to create quick links to display the results of a previous search on test runs (currently named preset).

As a SUT Operator, I want to see indicators about my progresses in executing the test plan.

As a test designer, I want to decide whether a test shall be graded by a monitor or if the operator can mark it as self-verified.

As a test session manager, when I assign the test to the monitors, I do not want to see those that have to be self-verified by the operator; because they do not need to be reviewed by a monitor.