SUT Owner

In most of the architecture, the security layer makes use of TLS as an encryption protocol. In the last years, TLS 1.2 was enforced to improve the security of systems. WHO is going one step further, and expects the systems that claim support to the DDCC profile to support TLS 1.3.

The Gazelle test suite offers tools to test the compliance of systems under test against TLS up to version 1.2. In the context of the WHO specifications, the SUT operators wants to verify the implementation of TLS 1.3 in his system, acting either as client or server. It includes verifying that the system under test supports a restricted set of cipher suites.

The DDCC specifications developed by WHO relies on TLSv1.2 and TLSv1.3 to secure the HTTP-based transactions.

During a testing event, when SUT operators are executing peer-to-peer tests, they want the test-bed to capture the messages they exchange, regardless of the TLS version used by their SUT.

The DDCC specifications published by WHO relies on the FHIR standard, and on IHE FHIR-based Profiles such as 

• SVCM: Sharing Valuesets, Codes, and Maps
• mCSD: Mobile Care Services Discovery
• PMIR: Patient Master Identity Registry
• MHD: Mobile access to Health Documents
• DDCC: Digital Documentation of COVID-19 Certificates

In this context, the SUT Operators want to verify the compliance of the FHIR resources produced by their SUTs.

The SUT Operator might choose to

• extract the message from his logs and validate it using Gazelle validation services (GUI or API)
• validate a message captured by Gazelle Proxy

The DDCC specifications relies on FHIR Smart App Launch Implementation Guide for the user authorization feature. See http://hl7.org/fhir/smart-app-launch/index.html.

In this context, the SUT Operator shall have a mean to verify that his SUT is able to

• Support OAuth v1.0 tokens when requesting resources from a REST server
• Support OAuth v1.0 tokens when receiving requests from a REST client
• Support OAuth v2.0 tokens when requesting resources from a REST server
• Support OAuth v2.0 tokens when receiving requests from a REST client
• Limit access to resources based on the authorization token it receives;
• Get an authorization code by sending a request to an Authorization Server compliant with the SMART App Launch pattern
• Get an access token sending a request with a JWT assertion to an Authorization Server based on SMART App Launch pattern
• Get an access token sending a request with a client secret to an Authorization Server based on SMART App Launch pattern
• Get an access token sending a request with a JWT assertion to an Authorization Server based on SMART Backend Services pattern

The DDCC specifications published by WHO relies on the FHIR standard, and on IHE FHIR-based Profiles such as 

• SVCM: Sharing Valuesets, Codes, and Maps
• mCSD: Mobile Care Services Discovery
• PMIR: Patient Master Identity Registry
• MHD: Mobile access to Health Documents
• DDCC: Digital Documentation of COVID-19 Certificates

In this context, the SUT Operators who develop the client side of those specifications want to verify the compliance of their system under test in regards to the specifications, in particular, whether the HTTP Header and Body of the HTTP requests are conform.

The SUT Operator might choose to

• extract the message from his logs and validate it using Gazelle validation services (GUI or API)
• validate a message captured by Gazelle Proxy

validate RPPS data contained in the CDA document and/or message

https://annuaire.sante.fr/web/site-pro/extractions-publiques

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.