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.