AEGIS Touchstone Testing Implementation Guide

This is the Version 1.1.0 Release of the Touchstone Testing Implementation Guide, based on FHIR Version 4.0.1. See the Directory of published versions

General Guidance

This section outlines important definitions and interpretations and requirements common to all AEGIS Touchstone Testing actors used in this guide. The conformance verbs used are defined in FHIR Conformance Rules.


Contents


Rule and RuleSet Extensions

The TestScript rule and ruleset extensions can be used to reference complex validation logic that goes beyond what the basic TestScript assert element supports. As such, rules are recommended only when a TestScript assert cannot be used in its basic form.

The Touchstone Rules-Engine supports rules written in the following languages:

  • Groovy
  • XSLT
  • Schematron

Support for additional languages may be added in the future. Unless you plan on executing test scripts against a test system that only supports XML, it is highly recommended to write rules in Groovy as XSLT and Schematron rules can only be evaluated against requests and responses whose content is in XML while Groovy supports JSON as well.


OAuth2 Capabilities

Touchstone has the ability for a user to create and use a Test System that is OAuth2 enabled, and with that comes of few features that are important to take note of when it comes to Test Executions performed against a Test System that has an OAuth2 Authorization service connected to it.

Fixture Ids

With the addition of a more robust OAuth2 environment into Touchstone, there are a few new fixtures, and values under those fixtures, that can be reached for test script authors.

  • One new fixture is the dest1SmartConfig (dest2SmartConfig, dest3SmartConfig, etc.). The fixture allows the test script author to access different variables coming from the JSON document that is at the .well-known/smart-configuration.json endpoint. It acts the same as retrieving variables from the capabilities statement. For example, to use dest1SmartConfig to retrieve the Client ID, you would use the sourceId and path in the testscript as sourceId = dest1SmartConfig, path = $.clientId.

  • Test Systems have special Oauth2 values that can be be retrieved by test script authors. The fixtures have a naming convention of dest1SystemConifg, dest2SystemConfig, origin1SystemConfig, origin2SystemConfig, etc. These fixtures have the following attributes:

Fixture ID Description
name The Test System name
name The Test System name
fullName The Organization name + the Test System name
baseUrl The Base URL of the Test System
supportsSmartOnFhir Set to true if the Test System supports SMART on FHIR, false if it does not
oauth2GrantType The Grant Type of the OAuth2 enables Test System, either Authorization Code or Client Credentials
clientId The Client ID of the Test System that is registered with the OAuth2 server.
clientSecret The Client Secret of the Test System that is registered with the OAuth2 server.
authEndpoint The Authorization Endpoint for the Test System.
tokenEndpoint The Token Endpoint for the Test System.
registerEndpoint The Registration Endpoint for the Test System.
introspectEndpoint The Introspection Endpoint for the Test System.
revocationEndpoint The Revocation Endpoint for the Test System.
scopesSupported The scopes that allowed for the server access to certain user scopes
  • Another set of fixtures that can be used by the user in the test scripts are oauth2AuthzRequest and oauth2AuthzRedirect. These two fixtures are used to access parts the the last OAuth2 Authroization Request sent to the OAuth2 server and the last OAuth2 Authorization response returned from the server.

Base64Encoding

Touchstone is configured to use a Base64Encoding on the operation.requestHeader.value when it includes Basic + A Single Space “ “ ahead of the value and when the operation.requestHeader.name is equal to Authorization in your Testscript executions. This is done for security and is the explanation as to why an Authorization value in the header will be different from the one that was originally coded.