Monitor

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.

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