Projectathon

SUT Operator verifies the conformance of the RAD-107 request and response messages

Submitted by abe on Fri, 11/18/2022 - 16:08
Priority
High - Major feature, it achieves a lot of work
Status
Under development
Customer
ANS
Business owner
Marie Bruillard
Description

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
What is/are the targeted context(s)?
Who is the targeted audience?
Targetted goal(s)

The main objective is to offer to SUT operators a way to verify the correctness of the HTTP requests and responses issued by their systems under test, against the RAD-107 requirements. In case of failure of the SUT to demonstrate that it complies with the specifications, the SUT operator shall understand what and where the errors are.

When the HTTP message contains a body (RAD-107 response), the SUT operator shall be able to assess as well the conformance of its content against specifications.

Expected benefit

Short-term: offering an automated way to verify the conformance of the messages issued in the context of the RAD-107 transaction (DICOMWeb / WADO-RS). It will benefit as well to the IHE Connectathon participants who have currently no mean of non-manual verification.

Medium-term: offering an HTTP validator (HTTP headers for requests and responses) that can be customised based on the requirements to be tested (DICOMWeb QIDO-RS, FHIR, IUA in particular).

Long-term: coupling this HTTP validator with the Message Content Analyzer to be able to provide to the SUT operators a complete analysis of the HTTP messages his SUT produces.

Opportunities

Enlarge the conformance testing capabilities of the test bed by offering a new feature: validation of HTTP messages, including validation of the HTTP headers.

Introduce this new conformance checking tool to the IHE Connectathon participants. It will increase the level of testing for an important set of HTTP-based profiles and thus improve the level of confidence in the systems under test which implement such specifications. Forseen profiles to be tested first: WIA, WIC, AIR, and IUA.

Leverage this new conformance checking tool for testing the IUA profile in the context of the PAN Canadian project.

Documentation
  • RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1
  • RFC9110: HTTP Semantics
  • WIA: IHE Profile Web-based Access to Images 
  • CI-SIS (ANS): Acces aux Documents de Santé en Imagerie (currently in public comment status, link to the final version to be added later on)

 

The user shall have access to an overview of the test runs for a given testing session whatever the current status of the related test cases

Submitted by abe on Wed, 10/26/2022 - 15:20
Priority
High - Major feature, it achieves a lot of work
Status
Draft
Customer
DG Santé
Business owner
Malo Toudic
Description

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.
What is/are the targeted context(s)?
Who is the targeted audience?
Targetted goal(s)

Allow the users to see all the test runs from a test session, regardless of the current status of the executed test cases.

Expected benefit

User will have access to a page that summarizes the outcome of their test campaign

Opportunities

We might also want to experience new widget/features on that page like displaying statistics.

Call GITB validation service from EVSClient

Submitted by abe on Wed, 10/26/2022 - 14:41
Priority
Essential - Must have, it is essential for the use cases
Status
Draft
Customer
DG DIGIT
Business owner
Fanny Serre
Description

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

What is/are the targeted context(s)?
Who is the targeted audience?
Targetted goal(s)

Our main goal is being able to integrate GITB based conformance testing tool within the Gazelle Test Bed to automate the validation of the messages captured by the Gazelle Proxy during the testing events.

Expected benefit

Workflow will be made easier for participants and monitors.

All the pieces of proof will be stored in a single space.

Full advantage of using the Gazelle Proxy and the Gazelle test bed in general.

Demonstrate the ability of the Gazelle test bed to interact with GITB testing tools.

Opportunities

Integration of the GITB Validator is also something we have forseen to be able to reuse their Json validator (validation of WIA/AIR messages - DICOM Web) so there is an opportunity to mutualize the work here.

On the longer term, it will allow Gazelle Test Management to interact with other GITB based implementations. 

Documentation

The SOAP API of the XML validator is the same regardless of the specific instance (the OOTS instance we are discussing or a potential future  additional instance) and is detailed here (a SOAP UI project is also available as part of the documentation). A REST variant of the SOAP API will also be made available. It's planned to be released mid to end November. In the case of the REST API, inputs will be provided via JSON and the report will be returned in XML format (the exact same XML you already get through the UI and SOAP API). The GITB development team also plans to prepare an XSL stylesheet that can be customized to use Gazelle's style.

Full documentation is available here: https://www.itb.ec.europa.eu/docs/guides/latest/validatingXML/index.html#validation-via-soap-web-service-api. In case you are considering using Java to call the SOAP API, we have a step-by-step guide that walks you through the development of a client. The simple project presented through this guide is also available on GitHub.

SUT operators and the monitors exchange information about a test run

Submitted by abe on Thu, 03/03/2022 - 17:14
Priority
Medium - Feature to be considered
Status
Under development
Customer
Renovation
Business owner
Anne-Gaëlle BERGE
Description

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.

What is/are the targeted context(s)?
Who is the targeted audience?
Targetted goal(s)

Automate the creation of a channel in the communication tool.

Expected benefit

Save time to the participants and improve the channel management.

Access test tools

Submitted by abe on Fri, 02/18/2022 - 17:03
Priority
Essential - Must have, it is essential for the use cases
Status
Under development
Customer
Renovation
Business owner
Anne-Gaëlle BERGE
Description

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.

What is/are the targeted context(s)?
Who is the targeted audience?
Targetted goal(s)

Gather all the information of interest to the user on a single view.

Reduce the number of places where the user should look for information.

Inform better the user about the tes tools at his disposal.

Expected benefit

Gazelle Test Managemet can be used as the home page of the Gazelle test bed and the user will find all the documentation and pointers he needs in a single place.

Test plan page for SUT operators

Submitted by abe on Mon, 12/20/2021 - 12:48
Priority
Essential - Must have, it is essential for the use cases
Status
Under development
Customer
Renovation
Business owner
Anne-Gaëlle BERGE
Description

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.

What is/are the targeted context(s)?
Who is the targeted audience?
Targetted goal(s)

Make the event preparation and the test execution during the event smoother and easier to understand.

Expected benefit

Create a page intuitive enough for SUT operators to find their way without loosing time in reading documentation or watching webinars.

 

Opportunities

Reduce the number of pages to maintain by reusing the same layout for both types of tests.

Review the way we build the test plans.

Communication between management, participants, and monitors

Submitted by abe on Mon, 12/20/2021 - 11:28
Priority
Medium - Feature to be considered
Status
Draft
Customer
Renovation
Business owner
Anne-Gaëlle BERGE
Description

In the last years, the Projectathons have been held online as well as the two last European Connectathons. In that context, Rocket.chat has been used as a communication tool between the participants, with the test session managers, and with the monitors. 

The SHARAZONE participants also use this tool for one-to-one communications. It is also the place where the SHARAZONE administrator broadcast information to the participants: new object available, tool maintenance, and so on.

All the involved parties agree that this tool is really useful and might also have an interest during onsite testing events.

What is/are the targeted context(s)?
Targetted goal(s)

Main goal: allow participants to online events to communicate in a timely manner: find test partners, execute test cases, review test cases, share screen.

Secondary goals:

  • Support participants during the preparatory phase
  • facilitate the exchange of information (patient identifier, logs) during on-site events
  • be able to leave a message to an on-site participant (or monitor or TSM) when it is busy on another subject.

 

Expected benefit

Preparatory phase:

  • better support to the participants
  • create a place for exchange

Online:

  • make the test event happens

Onsite:

  • fasten the test execution and debugging

 

Documentation

As a Test Session Manager, I want to broadcast information to all the participants (text message / attachments).

As a Test Session Manager, I want to broadcast information to all the monitors (text message / attachments).

As a Test Session Manager, I want to hold calls with all the participants to the online event (video is optionnal).

As a Test Session Manager, I want to share my screen with all the participants when the event is online.

As a monitor, I want the participant to share his screen with me so that I can verify the outcome of the test even when working remotely.

As a SUT operator, I want to share information with my partners of the test instance.

As a monitor, I want to contact all the SUT operators of a particular test instance when we are working online.

As a SUT operator, I want to contact the management team when I have a question during an online event.

As a participant (SUT operator, monitor, test session manager), I want to receive all the notifications in one place.

As a test session manager, I want to enrol all the participants to the event in the communication tool.

As a participant, I want to use my Gazelle login to access the communication space.

As a test session manager, I want to offer one public channel per system or at least one public channel per organisation.

As a test session manager, I want to reuse the same "default" channels from an event to the other.

As a test session manager, I want to pin a message at the top of a given channel as a reminder to readers.

Split of responsibilities for SUT

Submitted by abe on Fri, 12/17/2021 - 13:48
Status
Draft
Customer
Renovation
Business owner
Anne-Gaëlle BERGE
Description

Gazelle Test Management requires an owner to be set for each SUT. However, the owner might be a person who does not attend the event. In that case, it is problematic for the other participants and the test session manager because there is no onsite contact point.

In addition, some companies regiter their SUT for a large amount of capabilities and they attend with more than 3/4 persons. In that case, it is also hard for the participants to know who to address testing inquiries.

This new need tries to solve (at least partially) this issue.

What is/are the targeted context(s)?
Who is the targeted audience?
Targetted goal(s)

Give an accurate single point of contact to test partners

Expected benefit

Ease the communication between participants

Target the correct person when looking for test partners

Documentation

As a SUT Operator, I want to know who to contact to test a particular profile with one of my possible test partners.

If a communication tool is set up for the event, I want to have a link to send a direct message to my contact.

Enhanced notifications

Submitted by abe on Fri, 12/17/2021 - 12:29
Status
Draft
Customer
Renovation
Business owner
Anne-Gaëlle BERGE
Description

A lot of information are shared with the test event participant through the tool and they are available in various places. As a consequence, the participant has to regularly consult the various pages to check if a status changed or if a new information is available.

To inform the information in a timely manner, a notification system should be put in place.

 

What is/are the targeted context(s)?
Targetted goal(s)

Inform the participant in a timely manner of any useful information through an instant messaging system.

Expected benefit

Improve the user experience;

Save time to the participant, he does not have to look in the tool to find the information.

Documentation

As a SUT Operator, I want to be notified when the status of a test instance changes.

As a SUT Operator, I want to be notified when my SUT is accepted to the session.

As a SUT Operator, I want to be informed when my SUT is graded.

As a SUT Operator, I want to be notified when someone posts a message in the chat window of a test run in which I am involved.

As a SUT Operator, I want to be notified when a milestone is reached: registration starts, registration ends, session starts...

SUT definition page

Submitted by abe on Thu, 12/16/2021 - 16:00
Status
Draft
Customer
Renovation
Business owner
Anne-Gaëlle BERGE
Description

The SUT edition page shall be reworked in order to make it clearer, and more complete, so that the participants to not have to jump in multiple locations to manage their systems.

Avoid using tabs and use a navigation bar instead.

What is/are the targeted context(s)?
Who is the targeted audience?
Targetted goal(s)

Centralize the information about the SUT for the participant

Expected benefit

Reduce the number of pages to maintain

Ease the work of the SUT operator

Documentation

As a SUT operator, I want to set the name of my SUT.

As a SUT operator, I want to give a type for my SUT (Gateway, Workstation, PACS).

As a SUT operator, I want to communicate to my partners the links to my capability statements (HL7, IHE, DICOM, FHIR).

Do we really need a keyword ? It brings confusion because there is no consistency in the tool (names and keywords are used in several places)

As a SUT operator, I want to list the capabilities of my SUT that I want to test.

As a SUT operator, I want to be aware of the testing status of each AIPO (testable, not testable, at risk) when it has already been decided by the test session manager.

As a SUT operator, I want to know when a profile is not testable:

  • If it is already selected for my system, I need to be warned so that I am free to remove it from the list of capabilities;
  • If it is not selected, I shall not be allowed to select it (but the reason why I cannot select shall be clearly stated)

As a SUT operator, I want to ask the test session manager to allow me to test a capability as supportive.

As a SUT operator, I want to filter out the list of capabilities my system is registered for (filter on actor, profile, domain, option, supportive, result).

As a SUT operator, I want to see the result for each capability.

As a SUT operator, I want to see the notes from the domain manager on a given capability (if any).

As a SUT operator, I want to see where I have to sit in the room.

As a SUT operator, I want to access the communication channel dedicated to my system.