Create Test System¶
To enable selection of your test system as the Destination (or ‘target’) of message exchanges in Test Setup, select the
Serveroption for Profiles Supported:
You do not need to include your organization name in the test system name. Touchstone prefixes the test system name with your organization name where necessary.
- Name – This will be displayed along with your Organization name in Test System select-boxes in Touchstone.
- Base URL – Must be reachable on the public internet. Refer to Service Base URL for details.
- IP Addresses – This will be populated automatically by Touchstone. You can add additional IP addresses for the test system if the auto-detected one is incorrect. Note that the IP address is used primarily for Client test systems. As such it can be ignored if your system only responds to request and does not initiate message exchanges to other test systems.
- Can be viewed by – If
My Organizationis selected, then test system will not be listed on the Test Systems screen for users outside your organization. If
Meis selected, then even other users within your organization will be unable to see the test system.
- Can be executed against by – If
My Organizationis selected, then users outside your organization cannot execute tests against the test system. If
Meis selected, then even other users within your organization will be unable to execute tests against the test system.
- Can be modified by – If
My Organizationis selected, then users outside your organization cannot modify this test system’s attributes in Touchstone. If
Meis selected, then even other users within your organization will be unable to modify attributes of this test system.
- Allow Touchstone to pull capability statement once a day – Touchstone conditionally evaluates assertions during test execution based on test system capabilities as defined by its Capability Statement. To ensure that Touchstone has the latest copy of your Capability Statement, allow Touchstone to download this statement from your server once a day (by checking this box) and ensure that your test system has the statement available.
- Can Be Anchor – Whether or not this test system can serve as an Anchor System in conformance suites. Conformance results are NOT collected on Anchor Systems. You can learn more about Anchor Systems here.
- Requires / OAuth2 – Leave this unchecked if your system is a client test system only or if it does not require OAuth2. Otherwise, choose whether this system uses a static token or a dynamic token. If Static Token is chosen,
Authorizationrequest header will be set to this value by Touchstone when your test system is the target of an interaction.
- Profiles Supported – If your test system only responds to requests and does not initiate message exchanges to other test systems, then select the
To enable OAuth, check the OAuth2 checkbox and choose whether this system uses a static token or a dynamic token:
If the Static Token button is checked, a default value for the static token is required, but the value can be overridden at Test Setup if needed.
If the Dynamic Token button is checked, the following is shown to the user:
- Authorization Endpoint – The authorization endpoint URL of the FHIR Server.
- Token Endpoint – The token endpoint URL of the FHIR Server.
- Registration Endpoint – The registration endpoint URL of the FHIR Server.
- Introspection Endpoint – The introspection endpoint URL of the FHIR Server.
- Revocation Endpoint – The revocation endpoint URL of the FHIR Server.
- OAuth2 Grant Type – The grant type used for the server, Authorization Code, Client Credentials, or JWT Assertion. Choosing one of these is required.
- Client ID / Client Secret – For Authorization Code, Client Credentials, and JWT Assertion grant type, Client ID is requried.
- OAuth2 Scopes Supported – Optional input of the OAuth2 scopes that are supported.
- SMART on FHIR – Whether or not the Test System supports SMART on FHIR. If this box is checked, then the URL endpoints will be overwritten if a FHIR CapabilityStatement is retrieved from the server.
If Authorization Code is selected, the following is shown to the user:
- ‘nonce’ Parameter – The ‘nonce’ parameter is sent in the Authorization Request with a randomly generated 12 character value.
- ‘response_mode’ Parameter – The ‘response_mode’ parameter is sent in the Authorization Request with a value of “query”.
If JWT Assertion is selected, the following is shown to the user:
- JWT Signing Algorithm – Algorithm used to sign or encrypt the JSON Web Token. Required for JWT Assertion.
- Note: The Touchstone public-key can be found using the link next to the JWT Signing Algorithm. Be sure to select the correct algorithm before navagating this link.
To enable selection of your test system as the Origin (or ‘source’) of message exchanges in Test Setup, select the
Clientoption for Profiles Supported:
- Match Peer-to-Peer client request to test execution using – This is the mechanism by which Touchstone will match peer-to-peer request messages to test executions. Peer-to-peer message exchanges are covered under Peer-to-Peering testing.
- Verify origin IP of request – If checked, Touchstone will verify that the origin IP address of the request in peer-to-peer exchanges matches the client test system’s IP address in Test Setup. Without this verification, other client test systems could pretend to be this test system.
- IP Addresses – This becomes critical if you have selected
Origin IP of requestfor
Match Peer-to-Peer. It’s also critical if you have checked
Verify origin IP of request.
- Requires / OAuth2 – Leave this unchecked if your system is a client test system only.
- Allow Touchstone to pull capability statement once a day – It is still recommended to have this checked even if the test system is a client system only. Capability statement is applicable to client test systems as well. See Rest Mode.
On the Edit Test System page, you can download the Capability Statement that is on your test server if you have one, or you can manually upload one to Touchstone: