Projectathon

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.

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

https://github.com/ansforge/annuaire-sante-fhir-documentation/tree/main/metadata

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.