DSTU2

This page is part of the FHIR Specification (v1.0.2: DSTU 2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

6.24 Resource TestScript - Content

FHIR Infrastructure Work GroupMaturity Level: 0Compartments: Not linked to any defined compartments

TestScript is a resource that specifies a suite of tests against a FHIR server implementation to determine compliance against the FHIR specification.

6.24.1 Scope and Usage

The TestScript resource is used to define tests that can be executed on one or more FHIR servers. The TestScript resource would typically contain

  • a list of fixtures (required resources used in the tests)
  • setup procedures
  • a suite of thematically related tests
  • teardown procedures

For example, one TestScript might feature a set of tests focusing on searching Patients and validating the Bundle responses. The fixtures for such a test would contain a list of Patient resources that are required for the test to complete successfully. The setup procedures create the fixtures on the FHIR server being tested. A series of tests execute various search parameters and search for the fixtures in the results. The teardown procedures would then clean up (delete) the fixtures on FHIR server that were created during the setup procedures.

The purpose of the TestScript is to encode in an executable representation tests that can be used to

  1. determine whether a given FHIR server adheres to the FHIR specification and
  2. determine whether two or more FHIR servers implement capabilities in a compatible or interoperable manner.
It may not be possible to fully automate the latter goal (especially with regards to business rules that might ride on top of different implementations), however the tests should be able to determine whether two servers support the operations, value sets, profiles, and extensions to exchange Bundles of Resources (such as returned from the Patient $everything operation).

6.24.2 Boundaries and Relationships

The TestScript resource should NOT be used to represent Clinical tests, Prescriptions, or any other Healthcare related concept. The TestScript resource is an infrastructure support resource used to represent standardized tests to determine an implementation's level of adherence to the FHIR specification.

The TestScript resource relies is a part of the conformance framework; its purpose is to test whether systems conform to a set of expectations. The expectations are expressed using a combination of the following resources:

6.24.3 Background and Context

6.24.3.1 Background

The TestScript resource is designed to establish testing as a first class artifact within the FHIR specification. This resource allows defining a suite of tests that can be executed on one or more FHIR servers. The TestScript resource provides an implementation agnostic description of tests that allows test execution engines to evaluate if a server implementation conforms with the FHIR specification. Providing a clear and concise test methodology for the FHIR specification through the TestScript resource helps to enable interoperability among various FHIR server and client implementations.

Furthermore, the TestScript resource provides clear examples of the appropriate use of the FHIR specification through test-based documentation. The TestScript resource stands as a form of executable documentation allowing developers to examine the operations defined by the tests to understand how various RESTful API interactions and resources should be used in coordination. The tests can also be automatically executed against systems under development to determine how well the systems adhere to the specification.

The TestScript resource contains:

  • Name and description detailing the purpose of the test suite
  • Links describing how the test suite relates to the FHIR specification
  • A list of server interactions required to execute the test suite
  • A list of server interactions that the test suite validates the correctness of
  • The fixtures (required data or resources) the tests use during execution
  • A set of operations to set up the test suite environment
  • A list of tests each containing
    • Name and description of the test
    • Links describing how the test relates to the FHIR specification
    • A list of server interactions required to execute the test
    • A list of server interactions that the test validates the correctness of
    • A list of operations that provide the execution logic of the test
    • A list of assertions that provide the verification logic of the test
  • A set of operations to tear down the test environment

6.24.3.2 Execution

6.24.3.2.1 Workflow

Pre-Processing

The TestScript execution workflow begins by determining if the test suite is appropriate for the server under test. This can be determined by evaluating if the interactions listed in the TestScript metadata "capabilities" section are supported by the server's conformance resource. If the capabilities are supported by the server, then the TestScript can be executed. Otherwise, the TestScript as a whole or a specific test within the test script may be skipped depending on where the capabilities section is defined. See How to specify metadata capabilities.

If the server supports the requirements of the TestScript instance, any specified fixtures are loaded or retrieved. If the fixtures are marked as 'autocreate' then they are automatically created on the server(s) under test using 'create' operations. If any of the autocreate operations fail, then the tests in the TestScript are skipped.

Setup Execution

After the fixtures are loaded and autocreates are executed, then the setup section is executed to establish the test suite environment. The purpose of the setup section is typically to pre-load data (if it was not autocreated) required for the execution of the tests into the FHIR server under test. The setup operations are executed once before all the tests are run (see Operation Execution). All operations in a setup section (including assertions) must complete successfully for the tests to be executed. If an assertion operation in the setup section fails, then execution and evaluation of the tests in the TestScript should be skipped. Technically, any operation (see the operations table for a complete listing) can be included in the setup section, but typical operations will be create, update, read, and vread.

Due to the possibility that the setup actions are not required on the server under test, the TestScript execution workflow MAY provide the capability of skipping or ignoring the setup section of the TestScript.

Test Execution

Once setup is complete, each test is executed. Tests contain a set of operations, and executing a test involves the evaluation of each operation listed in the test in the order defined by the test (see Operation Execution and the list of operations).

Teardown Execution

After all the tests have completed execution, the teardown section is executed. The purpose of the teardown section is to revert the FHIR server under test to a pre-test clean state. This requires removing any resources or artifacts generated as part of test suite setup or test execution. Technically, any operation (see the operations table for a complete listing) can be included in the teardown section, but the most often used operation will be delete. Assertions are not supported in the teardown section.

Due to the possibility that the teardown actions are not required on the server under test, the TestScript execution workflow MAY provide the capability of skipping or ignoring the teardown section of the TestScript.

Post-Processing

After the teardown section is executed, any fixtures that were marked 'autodelete' are removed from the server(s) under test. After this final stage, the execution of the TestScript is complete.

6.24.3.2.2 Fixtures

The fixtures section of the TestScript defines a set of resource instances that will be used as part of the setup, test, and teardown sections during TestScript execution. The fixtures are required for the test script to execute. Each fixture defines a resource instance by URI, and must be identified by an ID. The URI can be local or remote (i.e. another server than the one the TestScript resource resides), absolute or relative. The ID on the fixture is considered the "source" identifier of the fixture -- it is not the same thing as the resource ID on the server where it was hosted. The "source" identifier is used to define the fixture instance within the context of the TestScript. Operations reference the ID of a fixture to uniquely identify the fixture instance the operation is using ("sourceId") or acting against ("targetId"). Once a fixture has been instantiated on a server (typically by the use of a create operation), the fixture ID is mapped to the ID of the corresponding resource instance on the server. TestScript execution engines must maintain this relationship between fixture IDs and server resource IDs. The TestScript execution engine is responsible for translating the fixture IDs (whether provided to the operation as "source" or "target") to the ID of the resource on the server during execution.

Using the optional "autocreate" and "autodelete" elements (missing values default to false), fixtures can be configured to automatically be created during TestScript setup and automatically deleted during TestScript teardown. This means that additional "create" and "delete" operations in the TestScript.setup and TestScript.teardown sections are unnecessary.

6.24.3.2.3 Variables

The variables section of the TestScript defines a set of expressions whose evaluations will be used in substitutions. These substitutions are performed in operation request headers and URL paths as well as assertion values.

Without variables, search parameters and request headers (such as If-Modified-Since) would be specified in outgoing requests as literal values. Variables allow the values to be managed externally in fixtures or dynamically in server response fixtures. They would be defined to hold path expressions against the fixtures. The path expressions would not change from one server to another but the fixture data could.

Using variables allows for the same test scripts to be executed against the same servers by different clients at the same time. Each client would change the fixture data (external to the test script) to make the data unique to that client. This ensures that the same delete/create/read operations executed concurrently by one client does not interfere with those of a another client. That can be important in testing environments such as a Connectathon. It can be very useful in year-round testing against public servers as well.

See Use variables for more information.

6.24.3.2.4 Operation Execution

The setup, test, and teardown sections of a TestScript can contain operation elements. Operations are intended to be executed in sequence and they represent the logic defined by the TestScript. Operations define a type, sourceId, targetid, destination, responseId, contentType, and other parameters. The type of the operation aligns with a corresponding RESTful API interaction. The sourceId and targetId of an operation define the context of the fixture data the operation is acting against (see Fixtures). The destination defines the server the operation is executed on and is only required for tests that include multiple servers. The responseId specifies a fixture ID to use to map to the server response. The contentType defines the format (XML or JSON) and the corresponding mime-type (application/xml+fhir and application/json+fhir) to use in the RESTful operation (defaulting to XML). The parameters of an operation allow providing additional data required for execution.

TestScript execution engines must load the operation details and execute the operation against the server(s) under test. Operations that are expected to result in an error or exception, shall immediately be followed by one or more "assertion" operations (that test for those error conditions), otherwise the test fails. This allows for "negative" testing (for example, the test script may perform operations that should return a 4XX or 5XX HTTP response code). Test execution is halted as soon as an operation or assertion fails. If an operation or assertion fails, then the test ends in failure and the test script execution proceeds to the next test. Once all tests have completed execution, the teardown section is executed. Once teardown completes, the suite execution is complete. If any setup or test operation or assertion failed, the test script is marked in failure. Failures in teardown are ignored.

6.24.3.2.5 Assertion Execution

The "assertion" evaluates the results of previous operations to determine if the server under test behaves appropriately. In order to evaluate an assertion, the request, response, and results of the most recently executed operation must always be maintained by the TestScript execution engine.

The TestScript execution engine must implement the behavior of each assertion to determine if the response of the last operation meets the conditions of the assertion.

If the conditions of the assertion are met execution of the test continues. If the conditions of the assertion are not met, the test being executed fails and execution of the test is halted.

6.24.4 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. TestScript DomainResourceDescribes a set of tests
... url Σ1..1uriAbsolute URL used to reference this TestScript
... version Σ0..1stringLogical id for this version of the TestScript
... name Σ1..1stringInformal name for this TestScript
... status ?! Σ1..1codedraft | active | retired
ConformanceResourceStatus (Required)
... identifier Σ0..1IdentifierExternal identifier
... experimental Σ0..1booleanIf for testing purposes, not real usage
... publisher Σ0..1stringName of the publisher (Organization or individual)
... contact Σ0..*BackboneElementContact details of the publisher
.... name Σ0..1stringName of a individual to contact
.... telecom Σ0..*ContactPointContact details for individual or publisher
... date Σ0..1dateTimeDate for this version of the TestScript
... description Σ0..1stringNatural language description of the TestScript
... useContext Σ0..*CodeableConceptContent intends to support these contexts
Context of Use ValueSet (Extensible)
... requirements 0..1stringScope and Usage this Test Script is for
... copyright 0..1stringUse and/or publishing restrictions
... metadata I0..1BackboneElementRequired capability that is assumed to function correctly on the FHIR server being tested
TestScript metadata capability SHALL contain required or validated or both.
.... link 0..*BackboneElementLinks to the FHIR specification
..... url 1..1uriURL to the specification
..... description 0..1stringShort description
.... capability 1..*BackboneElementCapabilities that are assumed to function correctly on the FHIR server being tested
..... required 0..1booleanAre the capabilities required?
..... validated 0..1booleanAre the capabilities validated?
..... description 0..1stringThe expected capabilities of the server
..... destination 0..1integerWhich server these requirements apply to
..... link 0..*uriLinks to the FHIR specification
..... conformance 1..1Reference(Conformance)Required Conformance
... multiserver 0..1booleanWhether or not the tests apply to more than one FHIR server
... fixture 0..*BackboneElementFixture in the test script - by reference (uri)
.... autocreate 0..1booleanWhether or not to implicitly create the fixture during setup
.... autodelete 0..1booleanWhether or not to implicitly delete the fixture during teardown
.... resource 0..1Reference(Any)Reference of the resource
... profile 0..*Reference(Any)Reference of the validation profile
... variable I0..*BackboneElementPlaceholder for evaluated elements
Variable cannot contain both headerField and path.
.... name 1..1stringDescriptive name for this variable
.... headerField 0..1stringHTTP header field name for source
.... path 0..1stringXPath or JSONPath against the fixture body
.... sourceId 0..1idFixture Id of source expression or headerField within this variable
... setup 0..1BackboneElementA series of required setup operations before tests are executed
.... metadata I0..1see metadataCapabilities that are assumed to function correctly on the FHIR server being tested
Setup metadata capability SHALL contain required or validated or both.
.... action I1..*BackboneElementA setup operation or assert to perform
Setup action SHALL contain either an operation or assert but not both.
..... operation I0..1BackboneElementThe setup operation to perform
Setup operation SHALL contain either sourceId or targetId or params or url.
...... type 0..1CodingThe setup operation type that will be executed
TestScriptOperationCodes (Extensible)
...... resource 0..1codeResource type
FHIRDefinedType (Required)
...... label 0..1stringTracking/logging operation label
...... description 0..1stringTracking/reporting operation description
...... accept 0..1codexml | json
ContentType (Required)
...... contentType 0..1codexml | json
ContentType (Required)
...... destination 0..1integerWhich server to perform the operation on
...... encodeRequestUrl 0..1booleanWhether or not to send the request url in encoded format
...... params 0..1stringExplicitly defined path parameters
...... requestHeader 0..*BackboneElementEach operation can have one ore more header elements
....... field 1..1stringHTTP header field name
....... value 1..1stringHTTP headerfield value
...... responseId 0..1idFixture Id of mapped response
...... sourceId 0..1idFixture Id of body for PUT and POST requests
...... targetId 0..1idId of fixture used for extracting the [id], [type], and [vid] for GET requests
...... url 0..1stringRequest URL
..... assert I0..1BackboneElementThe assertion to perform
Setup action assert shall contain both compareToSourceId and compareToSourcePath or neither.
Only a single assertion SHALL be present within setup action assert element.
...... label 0..1stringTracking/logging assertion label
...... description 0..1stringTracking/reporting assertion description
...... direction 0..1coderesponse | request
AssertionDirectionType (Required)
...... compareToSourceId 0..1stringId of fixture used to compare the "sourceId/path" evaluations to
...... compareToSourcePath 0..1stringXPath or JSONPath expression against fixture used to compare the "sourceId/path" evaluations to
...... contentType 0..1codexml | json
ContentType (Required)
...... headerField 0..1stringHTTP header field name
...... minimumId 0..1stringFixture Id of minimum content resource
...... navigationLinks 0..1booleanPerform validation on navigation links?
...... operator 0..1codeequals | notEquals | in | notIn | greaterThan | lessThan | empty | notEmpty | contains | notContains
AssertionOperatorType (Required)
...... path 0..1stringXPath or JSONPath expression
...... resource 0..1codeResource type
FHIRDefinedType (Required)
...... response 0..1codeokay | created | noContent | notModified | bad | forbidden | notFound | methodNotAllowed | conflict | gone | preconditionFailed | unprocessable
AssertionResponseTypes (Required)
...... responseCode 0..1stringHTTP response code to test
...... sourceId 0..1idFixture Id of source expression or headerField
...... validateProfileId 0..1idProfile Id of validation profile reference
...... value 0..1stringThe value to compare to
...... warningOnly 0..1booleanWill this assert produce a warning only on error?
... test 0..*BackboneElementA test in this script
.... name 0..1stringTracking/logging name of this test
.... description 0..1stringTracking/reporting short description of the test
.... metadata I0..1see metadataCapabilities that are expected to function correctly on the FHIR server being tested
Test metadata capability SHALL contain required or validated or both.
.... action I1..*BackboneElementA test operation or assert to perform
Test action SHALL contain either an operation or assert but not both.
..... operation I0..1see operationThe setup operation to perform
Test operation SHALL contain either sourceId or targetId or params or url.
..... assert I0..1see assertThe setup assertion to perform
Test action assert shall contain both compareToSourceId and compareToSourcePath or neither.
Only a single assertion SHALL be present within test action assert element.
... teardown 0..1BackboneElementA series of required clean up steps
.... action I1..*BackboneElementOne or more teardown operations to perform
Teardown action SHALL contain an operation.
..... operation I0..1see operationThe teardown operation to perform
Teardown operation SHALL contain either sourceId or targetId or params or url.

doco Documentation for this format

UML Diagram

TestScript (DomainResource)An absolute URL that is used to identify this Test Script. This SHALL be a URL, SHOULD be globally unique, and SHOULD be an address at which this Test Script is (or will be) publishedurl : uri [1..1]The identifier that is used to identify this version of the TestScript. This is an arbitrary value managed by the TestScript author manuallyversion : string [0..1]A free text natural language name identifying the TestScriptname : string [1..1]The status of the TestScript (this element modifies the meaning of other elements)status : code [1..1] « The lifecycle status of a Value Set or Concept Map. (Strength=Required)ConformanceResourceStatus! »Identifier for the TestScript assigned for external purposes outside the context of FHIRidentifier : Identifier [0..1]This TestScript was authored for testing purposes (or education/evaluation/marketing), and is not intended to be used for genuine usageexperimental : boolean [0..1]The name of the individual or organization that published the Test Scriptpublisher : string [0..1]The date this version of the test tcript was published. The date must change when the business version changes, if it does, and it must change if the status code changes. In addition, it should change when the substantive content of the test cases changedate : dateTime [0..1]A free text natural language description of the TestScript and its usedescription : string [0..1]The content was developed with a focus and intent of supporting the contexts that are listed. These terms may be used to assist with indexing and searching of Test ScriptsuseContext : CodeableConcept [0..*] « Indicates the countries, regions, disciplines and other aspects of use within which this artifact is targeted for use. (Strength=Extensible)Context of Use ValueSet+ »Explains why this Test Script is needed and why it's been constrained as it hasrequirements : string [0..1]A copyright statement relating to the Test Script and/or its contents. Copyright statements are generally legal restrictions on the use and publishing of the details of the constraints and mappingscopyright : string [0..1]If the tests apply to more than one FHIR server (e.g. cross-server interoperability tests) then multiserver=true. Defaults to false if value is unspecifiedmultiserver : boolean [0..1]Reference to the profile to be used for validationprofile : Reference [0..*] « Any »ContactThe name of an individual to contact regarding the Test Scriptname : string [0..1]Contact details for individual (if a name was provided) or the publishertelecom : ContactPoint [0..*]MetadataLinkURL to a particular requirement or feature within the FHIR specificationurl : uri [1..1]Short description of the linkdescription : string [0..1]CapabilityWhether or not the test execution will require the given capabilities of the server in order for this test script to executerequired : boolean [0..1]Whether or not the test execution will validate the given capabilities of the server in order for this test script to executevalidated : boolean [0..1]Description of the capabilities that this test script is requiring the server to supportdescription : string [0..1]Which server these requirements apply todestination : integer [0..1]Links to the FHIR specification that describes this interaction and the resources involved in more detaillink : uri [0..*]Minimum conformance required of server for test script to execute successfully. If server does not meet at a minimum the reference conformance definition, then all tests in this script are skippedconformance : Reference [1..1] « Conformance »FixtureWhether or not to implicitly create the fixture during setup. If true, the fixture is automatically created on each server being tested during setup, therefore no create operation is required for this fixture in the TestScript.setup sectionautocreate : boolean [0..1]Whether or not to implicitly delete the fixture during teardown If true, the fixture is automatically deleted on each server being tested during teardown, therefore no delete operation is required for this fixture in the TestScript.teardown sectionautodelete : boolean [0..1]Reference to the resource (containing the contents of the resource needed for operations)resource : Reference [0..1] « Any »VariableDescriptive name for this variablename : string [1..1]Will be used to grab the HTTP header field value from the headers that sourceId is pointing toheaderField : string [0..1]XPath or JSONPath against the fixture body. When variables are defined, either headerField must be specified or path, but not bothpath : string [0..1]Fixture to evaluate the XPath/JSONPath expression or the headerField against within this variablesourceId : id [0..1]SetupActionOperationServer interaction or operation typetype : Coding [0..1] « The allowable operation types. (Strength=Extensible)TestScriptOperationCodes+ »The type of the resource. See http://hl7-fhir.github.io/resourcelist.htmlresource : code [0..1] « Either a resource or a data type. (Strength=Required)FHIRDefinedType! »The label would be used for tracking/logging purposes by test engineslabel : string [0..1]The description would be used by test engines for tracking and reporting purposesdescription : string [0..1]The content-type or mime-type to use for RESTful operation in the 'Accept' headeraccept : code [0..1] « The content or mime type. (Strength=Required)ContentType! »The content-type or mime-type to use for RESTful operation in the 'Content-Type' headercontentType : code [0..1] « The content or mime type. (Strength=Required)ContentType! »Which server to perform the operation ondestination : integer [0..1]Whether or not to implicitly send the request url in encoded format. The default is true to match the standard RESTful client behavior. Set to false when communicating with a server that does not support encoded url pathsencodeRequestUrl : boolean [0..1]Path plus parameters after [type]. Used to set parts of the request URL explicitlyparams : string [0..1]The fixture id (maybe new) to map to the responseresponseId : id [0..1]The id of the fixture used as the body of a PUT or POST requestsourceId : id [0..1]Id of fixture used for extracting the [id], [type], and [vid] for GET requeststargetId : id [0..1]Complete request URLurl : string [0..1]RequestHeaderThe HTTP header field e.g. "Accept"field : string [1..1]The value of the header e.g. "application/xml"value : string [1..1]AssertThe label would be used for tracking/logging purposes by test engineslabel : string [0..1]The description would be used by test engines for tracking and reporting purposesdescription : string [0..1]The direction to use for the assertiondirection : code [0..1] « The type of direction to use for assertion. (Strength=Required)AssertionDirectionType! »Id of fixture used to compare the "sourceId/path" evaluations tocompareToSourceId : string [0..1]XPath or JSONPath expression against fixture used to compare the "sourceId/path" evaluations tocompareToSourcePath : string [0..1]The content-type or mime-type to use for RESTful operation in the 'Content-Type' headercontentType : code [0..1] « The content or mime type. (Strength=Required)ContentType! »The HTTP header field name e.g. 'Location'headerField : string [0..1]The ID of a fixture. Asserts that the response contains at a minimumId the fixture specified by minimumIdminimumId : string [0..1]Whether or not the test execution performs validation on the bundle navigation linksnavigationLinks : boolean [0..1]The operator typeoperator : code [0..1] « The type of operator to use for assertion. (Strength=Required)AssertionOperatorType! »The XPath or JSONPath expression to be evaluated against the fixture representing the response received from serverpath : string [0..1]The type of the resource. See http://hl7-fhir.github.io/resourcelist.htmlresource : code [0..1] « Either a resource or a data type. (Strength=Required)FHIRDefinedType! »okay | created | noContent | notModified | bad | forbidden | notFound | methodNotAllowed | conflict | gone | preconditionFailed | unprocessableresponse : code [0..1] « The type of response code to use for assertion. (Strength=Required)AssertionResponseTypes! »The value of the HTTP response code to be testedresponseCode : string [0..1]Fixture to evaluate the XPath/JSONPath expression or the headerField againstsourceId : id [0..1]The ID of the Profile to validate againstvalidateProfileId : id [0..1]The value to compare tovalue : string [0..1]Whether or not the test execution will produce a warning only on error for this assertwarningOnly : boolean [0..1]TestThe name of this test used for tracking/logging purposes by test enginesname : string [0..1]A short description of the test used by test engines for tracking and reporting purposesdescription : string [0..1]ActionTeardownActionContacts to assist a user in finding and communicating with the publishercontact[0..*]A link to the FHIR specification that this test is coveringlink[0..*]Capabilities that must exist and are assumed to function correctly on the FHIR server being testedcapability[1..*]The required capability must exist and are assumed to function correctly on the FHIR server being testedmetadata[0..1]Fixture in the test script - by reference (uri). All fixtures are required for the test script to executefixture[0..*]Variable is set based either on element value in response body or on header field value in the response headersvariable[0..*]Capabilities that must exist and are assumed to function correctly on the FHIR server being testedmetadata[0..1]Header elements would be used to set HTTP headersrequestHeader[0..*]The operation to performoperation[0..1]Evaluates the results of previous operations to determine if the server under test behaves appropriatelyassert[0..1]Action would contain either an operation or an assertionaction[1..*]A series of required setup operations before tests are executedsetup[0..1]Capabilities that must exist and are assumed to function correctly on the FHIR server being testedmetadata[0..1]An operation would involve a REST request to a serveroperation[0..1]Evaluates the results of previous operations to determine if the server under test behaves appropriatelyassert[0..1]Action would contain either an operation or an assertionaction[1..*]A test in this scripttest[0..*]An operation would involve a REST request to a serveroperation[0..1]The teardown action will only contain an operationaction[1..*]A series of operations required to clean up after the all the tests are executed (successfully or otherwise)teardown[0..1]

XML Template

<TestScript xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <url value="[uri]"/><!-- 1..1 Absolute URL used to reference this TestScript -->
 <version value="[string]"/><!-- 0..1 Logical id for this version of the TestScript -->
 <name value="[string]"/><!-- 1..1 Informal name for this TestScript -->
 <status value="[code]"/><!-- 1..1 draft | active | retired -->
 <identifier><!-- 0..1 Identifier External identifier --></identifier>
 <experimental value="[boolean]"/><!-- 0..1 If for testing purposes, not real usage -->
 <publisher value="[string]"/><!-- 0..1 Name of the publisher (Organization or individual) -->
 <contact>  <!-- 0..* Contact details of the publisher -->
  <name value="[string]"/><!-- 0..1 Name of a individual to contact -->
  <telecom><!-- 0..* ContactPoint Contact details for individual or publisher --></telecom>
 </contact>
 <date value="[dateTime]"/><!-- 0..1 Date for this version of the TestScript -->
 <description value="[string]"/><!-- 0..1 Natural language description of the TestScript -->
 <useContext><!-- 0..* CodeableConcept Content intends to support these contexts --></useContext>
 <requirements value="[string]"/><!-- 0..1 Scope and Usage this Test Script is for -->
 <copyright value="[string]"/><!-- 0..1 Use and/or publishing restrictions -->
 <metadata>  <!-- 0..1 Required capability that is assumed to function correctly on the FHIR server being tested -->
  <link>  <!-- 0..* Links to the FHIR specification -->
   <url value="[uri]"/><!-- 1..1 URL to the specification -->
   <description value="[string]"/><!-- 0..1 Short description -->
  </link>
  <capability>  <!-- 1..* Capabilities  that are assumed to function correctly on the FHIR server being tested -->
   <required value="[boolean]"/><!-- 0..1 Are the capabilities required? -->
   <validated value="[boolean]"/><!-- 0..1 Are the capabilities validated? -->
   <description value="[string]"/><!-- 0..1 The expected capabilities of the server -->
   <destination value="[integer]"/><!-- 0..1 Which server these requirements apply to -->
   <link value="[uri]"/><!-- 0..* Links to the FHIR specification -->
   <conformance><!-- 1..1 Reference(Conformance) Required Conformance --></conformance>
  </capability>
 </metadata>
 <multiserver value="[boolean]"/><!-- 0..1 Whether or not the tests apply to more than one FHIR server -->
 <fixture>  <!-- 0..* Fixture in the test script - by reference (uri) -->
  <autocreate value="[boolean]"/><!-- 0..1 Whether or not to implicitly create the fixture during setup -->
  <autodelete value="[boolean]"/><!-- 0..1 Whether or not to implicitly delete the fixture during teardown -->
  <resource><!-- 0..1 Reference(Any) Reference of the resource --></resource>
 </fixture>
 <profile><!-- 0..* Reference(Any) Reference of the validation profile --></profile>
 <variable>  <!-- 0..* Placeholder for evaluated elements -->
  <name value="[string]"/><!-- 1..1 Descriptive name for this variable -->
  <headerField value="[string]"/><!-- 0..1 HTTP header field name for source -->
  <path value="[string]"/><!-- 0..1 XPath or JSONPath against the fixture body -->
  <sourceId value="[id]"/><!-- 0..1 Fixture Id of source expression or headerField within this variable -->
 </variable>
 <setup>  <!-- 0..1 A series of required setup operations before tests are executed -->
  <metadata><!-- 0..1 Content as for TestScript.metadata Capabilities  that are assumed to function correctly on the FHIR server being tested --></metadata>
  <action>  <!-- 1..* A setup operation or assert to perform -->
   <operation>  <!-- 0..1 The setup operation to perform -->
    <type><!-- 0..1 Coding The setup operation type that will be executed --></type>
    <resource value="[code]"/><!-- 0..1 Resource type -->
    <label value="[string]"/><!-- 0..1 Tracking/logging operation label -->
    <description value="[string]"/><!-- 0..1 Tracking/reporting operation description -->
    <accept value="[code]"/><!-- 0..1 xml | json -->
    <contentType value="[code]"/><!-- 0..1 xml | json -->
    <destination value="[integer]"/><!-- 0..1 Which server to perform the operation on -->
    <encodeRequestUrl value="[boolean]"/><!-- 0..1 Whether or not to send the request url in encoded format -->
    <params value="[string]"/><!-- 0..1 Explicitly defined path parameters -->
    <requestHeader>  <!-- 0..* Each operation can have one ore more header elements -->
     <field value="[string]"/><!-- 1..1 HTTP header field name -->
     <value value="[string]"/><!-- 1..1 HTTP headerfield value -->
    </requestHeader>
    <responseId value="[id]"/><!-- 0..1 Fixture Id of mapped response -->
    <sourceId value="[id]"/><!-- 0..1 Fixture Id of body for PUT and POST requests -->
    <targetId value="[id]"/><!-- 0..1 Id of fixture used for extracting the [id],  [type], and [vid] for GET requests -->
    <url value="[string]"/><!-- 0..1 Request URL -->
   </operation>
   <assert>  <!-- 0..1 The assertion to perform -->
    <label value="[string]"/><!-- 0..1 Tracking/logging assertion label -->
    <description value="[string]"/><!-- 0..1 Tracking/reporting assertion description -->
    <direction value="[code]"/><!-- 0..1 response | request -->
    <compareToSourceId value="[string]"/><!-- 0..1 Id of fixture used to compare the "sourceId/path" evaluations to -->
    <compareToSourcePath value="[string]"/><!-- 0..1 XPath or JSONPath expression against fixture used to compare the "sourceId/path" evaluations to -->
    <contentType value="[code]"/><!-- 0..1 xml | json -->
    <headerField value="[string]"/><!-- 0..1 HTTP header field name -->
    <minimumId value="[string]"/><!-- 0..1 Fixture Id of minimum content resource -->
    <navigationLinks value="[boolean]"/><!-- 0..1 Perform validation on navigation links? -->
    <operator value="[code]"/><!-- 0..1 equals | notEquals | in | notIn | greaterThan | lessThan | empty | notEmpty | contains | notContains -->
    <path value="[string]"/><!-- 0..1 XPath or JSONPath expression -->
    <resource value="[code]"/><!-- 0..1 Resource type -->
    <response value="[code]"/><!-- 0..1 okay | created | noContent | notModified | bad | forbidden | notFound | methodNotAllowed | conflict | gone | preconditionFailed | unprocessable -->
    <responseCode value="[string]"/><!-- 0..1 HTTP response code to test -->
    <sourceId value="[id]"/><!-- 0..1 Fixture Id of source expression or headerField -->
    <validateProfileId value="[id]"/><!-- 0..1 Profile Id of validation profile reference -->
    <value value="[string]"/><!-- 0..1 The value to compare to -->
    <warningOnly value="[boolean]"/><!-- 0..1 Will this assert produce a warning only on error? -->
   </assert>
  </action>
 </setup>
 <test>  <!-- 0..* A test in this script -->
  <name value="[string]"/><!-- 0..1 Tracking/logging name of this test -->
  <description value="[string]"/><!-- 0..1 Tracking/reporting short description of the test -->
  <metadata><!-- 0..1 Content as for TestScript.metadata Capabilities  that are expected to function correctly on the FHIR server being tested --></metadata>
  <action>  <!-- 1..* A test operation or assert to perform -->
   <operation><!-- 0..1 Content as for TestScript.setup.action.operation The setup operation to perform --></operation>
   <assert><!-- 0..1 Content as for TestScript.setup.action.assert The setup assertion to perform --></assert>
  </action>
 </test>
 <teardown>  <!-- 0..1 A series of required clean up steps -->
  <action>  <!-- 1..* One or more teardown operations to perform -->
   <operation><!-- 0..1 Content as for TestScript.setup.action.operation The teardown operation to perform --></operation>
  </action>
 </teardown>
</TestScript>

JSON Template

{doco
  "resourceType" : "TestScript",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "url" : "<uri>", // R!  Absolute URL used to reference this TestScript
  "version" : "<string>", // Logical id for this version of the TestScript
  "name" : "<string>", // R!  Informal name for this TestScript
  "status" : "<code>", // R!  draft | active | retired
  "identifier" : { Identifier }, // External identifier
  "experimental" : <boolean>, // If for testing purposes, not real usage
  "publisher" : "<string>", // Name of the publisher (Organization or individual)
  "contact" : [{ // Contact details of the publisher
    "name" : "<string>", // Name of a individual to contact
    "telecom" : [{ ContactPoint }] // Contact details for individual or publisher
  }],
  "date" : "<dateTime>", // Date for this version of the TestScript
  "description" : "<string>", // Natural language description of the TestScript
  "useContext" : [{ CodeableConcept }], // Content intends to support these contexts
  "requirements" : "<string>", // Scope and Usage this Test Script is for
  "copyright" : "<string>", // Use and/or publishing restrictions
  "metadata" : { // Required capability that is assumed to function correctly on the FHIR server being tested
    "link" : [{ // Links to the FHIR specification
      "url" : "<uri>", // R!  URL to the specification
      "description" : "<string>" // Short description
    }],
    "capability" : [{ // R!  Capabilities  that are assumed to function correctly on the FHIR server being tested
      "required" : <boolean>, // Are the capabilities required?
      "validated" : <boolean>, // Are the capabilities validated?
      "description" : "<string>", // The expected capabilities of the server
      "destination" : <integer>, // Which server these requirements apply to
      "link" : ["<uri>"], // Links to the FHIR specification
      "conformance" : { Reference(Conformance) } // R!  Required Conformance
    }]
  },
  "multiserver" : <boolean>, // Whether or not the tests apply to more than one FHIR server
  "fixture" : [{ // Fixture in the test script - by reference (uri)
    "autocreate" : <boolean>, // Whether or not to implicitly create the fixture during setup
    "autodelete" : <boolean>, // Whether or not to implicitly delete the fixture during teardown
    "resource" : { Reference(Any) } // Reference of the resource
  }],
  "profile" : [{ Reference(Any) }], // Reference of the validation profile
  "variable" : [{ // Placeholder for evaluated elements
    "name" : "<string>", // R!  Descriptive name for this variable
    "headerField" : "<string>", // HTTP header field name for source
    "path" : "<string>", // XPath or JSONPath against the fixture body
    "sourceId" : "<id>" // Fixture Id of source expression or headerField within this variable
  }],
  "setup" : { // A series of required setup operations before tests are executed
    "metadata" : { Content as for TestScript.metadata }, // Capabilities  that are assumed to function correctly on the FHIR server being tested
    "action" : [{ // R!  A setup operation or assert to perform
      "operation" : { // The setup operation to perform
        "type" : { Coding }, // The setup operation type that will be executed
        "resource" : "<code>", // Resource type
        "label" : "<string>", // Tracking/logging operation label
        "description" : "<string>", // Tracking/reporting operation description
        "accept" : "<code>", // xml | json
        "contentType" : "<code>", // xml | json
        "destination" : <integer>, // Which server to perform the operation on
        "encodeRequestUrl" : <boolean>, // Whether or not to send the request url in encoded format
        "params" : "<string>", // Explicitly defined path parameters
        "requestHeader" : [{ // Each operation can have one ore more header elements
          "field" : "<string>", // R!  HTTP header field name
          "value" : "<string>" // R!  HTTP headerfield value
        }],
        "responseId" : "<id>", // Fixture Id of mapped response
        "sourceId" : "<id>", // Fixture Id of body for PUT and POST requests
        "targetId" : "<id>", // Id of fixture used for extracting the [id],  [type], and [vid] for GET requests
        "url" : "<string>" // Request URL
      },
      "assert" : { // The assertion to perform
        "label" : "<string>", // Tracking/logging assertion label
        "description" : "<string>", // Tracking/reporting assertion description
        "direction" : "<code>", // response | request
        "compareToSourceId" : "<string>", // Id of fixture used to compare the "sourceId/path" evaluations to
        "compareToSourcePath" : "<string>", // XPath or JSONPath expression against fixture used to compare the "sourceId/path" evaluations to
        "contentType" : "<code>", // xml | json
        "headerField" : "<string>", // HTTP header field name
        "minimumId" : "<string>", // Fixture Id of minimum content resource
        "navigationLinks" : <boolean>, // Perform validation on navigation links?
        "operator" : "<code>", // equals | notEquals | in | notIn | greaterThan | lessThan | empty | notEmpty | contains | notContains
        "path" : "<string>", // XPath or JSONPath expression
        "resource" : "<code>", // Resource type
        "response" : "<code>", // okay | created | noContent | notModified | bad | forbidden | notFound | methodNotAllowed | conflict | gone | preconditionFailed | unprocessable
        "responseCode" : "<string>", // HTTP response code to test
        "sourceId" : "<id>", // Fixture Id of source expression or headerField
        "validateProfileId" : "<id>", // Profile Id of validation profile reference
        "value" : "<string>", // The value to compare to
        "warningOnly" : <boolean> // Will this assert produce a warning only on error?
      }
    }]
  },
  "test" : [{ // A test in this script
    "name" : "<string>", // Tracking/logging name of this test
    "description" : "<string>", // Tracking/reporting short description of the test
    "metadata" : { Content as for TestScript.metadata }, // Capabilities  that are expected to function correctly on the FHIR server being tested
    "action" : [{ // R!  A test operation or assert to perform
      "operation" : { Content as for TestScript.setup.action.operation }, // The setup operation to perform
      "assert" : { Content as for TestScript.setup.action.assert } // The setup assertion to perform
    }]
  }],
  "teardown" : { // A series of required clean up steps
    "action" : [{ // R!  One or more teardown operations to perform
      "operation" : { Content as for TestScript.setup.action.operation } // The teardown operation to perform
    }]
  }
}

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. TestScript DomainResourceDescribes a set of tests
... url Σ1..1uriAbsolute URL used to reference this TestScript
... version Σ0..1stringLogical id for this version of the TestScript
... name Σ1..1stringInformal name for this TestScript
... status ?! Σ1..1codedraft | active | retired
ConformanceResourceStatus (Required)
... identifier Σ0..1IdentifierExternal identifier
... experimental Σ0..1booleanIf for testing purposes, not real usage
... publisher Σ0..1stringName of the publisher (Organization or individual)
... contact Σ0..*BackboneElementContact details of the publisher
.... name Σ0..1stringName of a individual to contact
.... telecom Σ0..*ContactPointContact details for individual or publisher
... date Σ0..1dateTimeDate for this version of the TestScript
... description Σ0..1stringNatural language description of the TestScript
... useContext Σ0..*CodeableConceptContent intends to support these contexts
Context of Use ValueSet (Extensible)
... requirements 0..1stringScope and Usage this Test Script is for
... copyright 0..1stringUse and/or publishing restrictions
... metadata I0..1BackboneElementRequired capability that is assumed to function correctly on the FHIR server being tested
TestScript metadata capability SHALL contain required or validated or both.
.... link 0..*BackboneElementLinks to the FHIR specification
..... url 1..1uriURL to the specification
..... description 0..1stringShort description
.... capability 1..*BackboneElementCapabilities that are assumed to function correctly on the FHIR server being tested
..... required 0..1booleanAre the capabilities required?
..... validated 0..1booleanAre the capabilities validated?
..... description 0..1stringThe expected capabilities of the server
..... destination 0..1integerWhich server these requirements apply to
..... link 0..*uriLinks to the FHIR specification
..... conformance 1..1Reference(Conformance)Required Conformance
... multiserver 0..1booleanWhether or not the tests apply to more than one FHIR server
... fixture 0..*BackboneElementFixture in the test script - by reference (uri)
.... autocreate 0..1booleanWhether or not to implicitly create the fixture during setup
.... autodelete 0..1booleanWhether or not to implicitly delete the fixture during teardown
.... resource 0..1Reference(Any)Reference of the resource
... profile 0..*Reference(Any)Reference of the validation profile
... variable I0..*BackboneElementPlaceholder for evaluated elements
Variable cannot contain both headerField and path.
.... name 1..1stringDescriptive name for this variable
.... headerField 0..1stringHTTP header field name for source
.... path 0..1stringXPath or JSONPath against the fixture body
.... sourceId 0..1idFixture Id of source expression or headerField within this variable
... setup 0..1BackboneElementA series of required setup operations before tests are executed
.... metadata I0..1see metadataCapabilities that are assumed to function correctly on the FHIR server being tested
Setup metadata capability SHALL contain required or validated or both.
.... action I1..*BackboneElementA setup operation or assert to perform
Setup action SHALL contain either an operation or assert but not both.
..... operation I0..1BackboneElementThe setup operation to perform
Setup operation SHALL contain either sourceId or targetId or params or url.
...... type 0..1CodingThe setup operation type that will be executed
TestScriptOperationCodes (Extensible)
...... resource 0..1codeResource type
FHIRDefinedType (Required)
...... label 0..1stringTracking/logging operation label
...... description 0..1stringTracking/reporting operation description
...... accept 0..1codexml | json
ContentType (Required)
...... contentType 0..1codexml | json
ContentType (Required)
...... destination 0..1integerWhich server to perform the operation on
...... encodeRequestUrl 0..1booleanWhether or not to send the request url in encoded format
...... params 0..1stringExplicitly defined path parameters
...... requestHeader 0..*BackboneElementEach operation can have one ore more header elements
....... field 1..1stringHTTP header field name
....... value 1..1stringHTTP headerfield value
...... responseId 0..1idFixture Id of mapped response
...... sourceId 0..1idFixture Id of body for PUT and POST requests
...... targetId 0..1idId of fixture used for extracting the [id], [type], and [vid] for GET requests
...... url 0..1stringRequest URL
..... assert I0..1BackboneElementThe assertion to perform
Setup action assert shall contain both compareToSourceId and compareToSourcePath or neither.
Only a single assertion SHALL be present within setup action assert element.
...... label 0..1stringTracking/logging assertion label
...... description 0..1stringTracking/reporting assertion description
...... direction 0..1coderesponse | request
AssertionDirectionType (Required)
...... compareToSourceId 0..1stringId of fixture used to compare the "sourceId/path" evaluations to
...... compareToSourcePath 0..1stringXPath or JSONPath expression against fixture used to compare the "sourceId/path" evaluations to
...... contentType 0..1codexml | json
ContentType (Required)
...... headerField 0..1stringHTTP header field name
...... minimumId 0..1stringFixture Id of minimum content resource
...... navigationLinks 0..1booleanPerform validation on navigation links?
...... operator 0..1codeequals | notEquals | in | notIn | greaterThan | lessThan | empty | notEmpty | contains | notContains
AssertionOperatorType (Required)
...... path 0..1stringXPath or JSONPath expression
...... resource 0..1codeResource type
FHIRDefinedType (Required)
...... response 0..1codeokay | created | noContent | notModified | bad | forbidden | notFound | methodNotAllowed | conflict | gone | preconditionFailed | unprocessable
AssertionResponseTypes (Required)
...... responseCode 0..1stringHTTP response code to test
...... sourceId 0..1idFixture Id of source expression or headerField
...... validateProfileId 0..1idProfile Id of validation profile reference
...... value 0..1stringThe value to compare to
...... warningOnly 0..1booleanWill this assert produce a warning only on error?
... test 0..*BackboneElementA test in this script
.... name 0..1stringTracking/logging name of this test
.... description 0..1stringTracking/reporting short description of the test
.... metadata I0..1see metadataCapabilities that are expected to function correctly on the FHIR server being tested
Test metadata capability SHALL contain required or validated or both.
.... action I1..*BackboneElementA test operation or assert to perform
Test action SHALL contain either an operation or assert but not both.
..... operation I0..1see operationThe setup operation to perform
Test operation SHALL contain either sourceId or targetId or params or url.
..... assert I0..1see assertThe setup assertion to perform
Test action assert shall contain both compareToSourceId and compareToSourcePath or neither.
Only a single assertion SHALL be present within test action assert element.
... teardown 0..1BackboneElementA series of required clean up steps
.... action I1..*BackboneElementOne or more teardown operations to perform
Teardown action SHALL contain an operation.
..... operation I0..1see operationThe teardown operation to perform
Teardown operation SHALL contain either sourceId or targetId or params or url.

doco Documentation for this format

UML Diagram

TestScript (DomainResource)An absolute URL that is used to identify this Test Script. This SHALL be a URL, SHOULD be globally unique, and SHOULD be an address at which this Test Script is (or will be) publishedurl : uri [1..1]The identifier that is used to identify this version of the TestScript. This is an arbitrary value managed by the TestScript author manuallyversion : string [0..1]A free text natural language name identifying the TestScriptname : string [1..1]The status of the TestScript (this element modifies the meaning of other elements)status : code [1..1] « The lifecycle status of a Value Set or Concept Map. (Strength=Required)ConformanceResourceStatus! »Identifier for the TestScript assigned for external purposes outside the context of FHIRidentifier : Identifier [0..1]This TestScript was authored for testing purposes (or education/evaluation/marketing), and is not intended to be used for genuine usageexperimental : boolean [0..1]The name of the individual or organization that published the Test Scriptpublisher : string [0..1]The date this version of the test tcript was published. The date must change when the business version changes, if it does, and it must change if the status code changes. In addition, it should change when the substantive content of the test cases changedate : dateTime [0..1]A free text natural language description of the TestScript and its usedescription : string [0..1]The content was developed with a focus and intent of supporting the contexts that are listed. These terms may be used to assist with indexing and searching of Test ScriptsuseContext : CodeableConcept [0..*] « Indicates the countries, regions, disciplines and other aspects of use within which this artifact is targeted for use. (Strength=Extensible)Context of Use ValueSet+ »Explains why this Test Script is needed and why it's been constrained as it hasrequirements : string [0..1]A copyright statement relating to the Test Script and/or its contents. Copyright statements are generally legal restrictions on the use and publishing of the details of the constraints and mappingscopyright : string [0..1]If the tests apply to more than one FHIR server (e.g. cross-server interoperability tests) then multiserver=true. Defaults to false if value is unspecifiedmultiserver : boolean [0..1]Reference to the profile to be used for validationprofile : Reference [0..*] « Any »ContactThe name of an individual to contact regarding the Test Scriptname : string [0..1]Contact details for individual (if a name was provided) or the publishertelecom : ContactPoint [0..*]MetadataLinkURL to a particular requirement or feature within the FHIR specificationurl : uri [1..1]Short description of the linkdescription : string [0..1]CapabilityWhether or not the test execution will require the given capabilities of the server in order for this test script to executerequired : boolean [0..1]Whether or not the test execution will validate the given capabilities of the server in order for this test script to executevalidated : boolean [0..1]Description of the capabilities that this test script is requiring the server to supportdescription : string [0..1]Which server these requirements apply todestination : integer [0..1]Links to the FHIR specification that describes this interaction and the resources involved in more detaillink : uri [0..*]Minimum conformance required of server for test script to execute successfully. If server does not meet at a minimum the reference conformance definition, then all tests in this script are skippedconformance : Reference [1..1] « Conformance »FixtureWhether or not to implicitly create the fixture during setup. If true, the fixture is automatically created on each server being tested during setup, therefore no create operation is required for this fixture in the TestScript.setup sectionautocreate : boolean [0..1]Whether or not to implicitly delete the fixture during teardown If true, the fixture is automatically deleted on each server being tested during teardown, therefore no delete operation is required for this fixture in the TestScript.teardown sectionautodelete : boolean [0..1]Reference to the resource (containing the contents of the resource needed for operations)resource : Reference [0..1] « Any »VariableDescriptive name for this variablename : string [1..1]Will be used to grab the HTTP header field value from the headers that sourceId is pointing toheaderField : string [0..1]XPath or JSONPath against the fixture body. When variables are defined, either headerField must be specified or path, but not bothpath : string [0..1]Fixture to evaluate the XPath/JSONPath expression or the headerField against within this variablesourceId : id [0..1]SetupActionOperationServer interaction or operation typetype : Coding [0..1] « The allowable operation types. (Strength=Extensible)TestScriptOperationCodes+ »The type of the resource. See http://hl7-fhir.github.io/resourcelist.htmlresource : code [0..1] « Either a resource or a data type. (Strength=Required)FHIRDefinedType! »The label would be used for tracking/logging purposes by test engineslabel : string [0..1]The description would be used by test engines for tracking and reporting purposesdescription : string [0..1]The content-type or mime-type to use for RESTful operation in the 'Accept' headeraccept : code [0..1] « The content or mime type. (Strength=Required)ContentType! »The content-type or mime-type to use for RESTful operation in the 'Content-Type' headercontentType : code [0..1] « The content or mime type. (Strength=Required)ContentType! »Which server to perform the operation ondestination : integer [0..1]Whether or not to implicitly send the request url in encoded format. The default is true to match the standard RESTful client behavior. Set to false when communicating with a server that does not support encoded url pathsencodeRequestUrl : boolean [0..1]Path plus parameters after [type]. Used to set parts of the request URL explicitlyparams : string [0..1]The fixture id (maybe new) to map to the responseresponseId : id [0..1]The id of the fixture used as the body of a PUT or POST requestsourceId : id [0..1]Id of fixture used for extracting the [id], [type], and [vid] for GET requeststargetId : id [0..1]Complete request URLurl : string [0..1]RequestHeaderThe HTTP header field e.g. "Accept"field : string [1..1]The value of the header e.g. "application/xml"value : string [1..1]AssertThe label would be used for tracking/logging purposes by test engineslabel : string [0..1]The description would be used by test engines for tracking and reporting purposesdescription : string [0..1]The direction to use for the assertiondirection : code [0..1] « The type of direction to use for assertion. (Strength=Required)AssertionDirectionType! »Id of fixture used to compare the "sourceId/path" evaluations tocompareToSourceId : string [0..1]XPath or JSONPath expression against fixture used to compare the "sourceId/path" evaluations tocompareToSourcePath : string [0..1]The content-type or mime-type to use for RESTful operation in the 'Content-Type' headercontentType : code [0..1] « The content or mime type. (Strength=Required)ContentType! »The HTTP header field name e.g. 'Location'headerField : string [0..1]The ID of a fixture. Asserts that the response contains at a minimumId the fixture specified by minimumIdminimumId : string [0..1]Whether or not the test execution performs validation on the bundle navigation linksnavigationLinks : boolean [0..1]The operator typeoperator : code [0..1] « The type of operator to use for assertion. (Strength=Required)AssertionOperatorType! »The XPath or JSONPath expression to be evaluated against the fixture representing the response received from serverpath : string [0..1]The type of the resource. See http://hl7-fhir.github.io/resourcelist.htmlresource : code [0..1] « Either a resource or a data type. (Strength=Required)FHIRDefinedType! »okay | created | noContent | notModified | bad | forbidden | notFound | methodNotAllowed | conflict | gone | preconditionFailed | unprocessableresponse : code [0..1] « The type of response code to use for assertion. (Strength=Required)AssertionResponseTypes! »The value of the HTTP response code to be testedresponseCode : string [0..1]Fixture to evaluate the XPath/JSONPath expression or the headerField againstsourceId : id [0..1]The ID of the Profile to validate againstvalidateProfileId : id [0..1]The value to compare tovalue : string [0..1]Whether or not the test execution will produce a warning only on error for this assertwarningOnly : boolean [0..1]TestThe name of this test used for tracking/logging purposes by test enginesname : string [0..1]A short description of the test used by test engines for tracking and reporting purposesdescription : string [0..1]ActionTeardownActionContacts to assist a user in finding and communicating with the publishercontact[0..*]A link to the FHIR specification that this test is coveringlink[0..*]Capabilities that must exist and are assumed to function correctly on the FHIR server being testedcapability[1..*]The required capability must exist and are assumed to function correctly on the FHIR server being testedmetadata[0..1]Fixture in the test script - by reference (uri). All fixtures are required for the test script to executefixture[0..*]Variable is set based either on element value in response body or on header field value in the response headersvariable[0..*]Capabilities that must exist and are assumed to function correctly on the FHIR server being testedmetadata[0..1]Header elements would be used to set HTTP headersrequestHeader[0..*]The operation to performoperation[0..1]Evaluates the results of previous operations to determine if the server under test behaves appropriatelyassert[0..1]Action would contain either an operation or an assertionaction[1..*]A series of required setup operations before tests are executedsetup[0..1]Capabilities that must exist and are assumed to function correctly on the FHIR server being testedmetadata[0..1]An operation would involve a REST request to a serveroperation[0..1]Evaluates the results of previous operations to determine if the server under test behaves appropriatelyassert[0..1]Action would contain either an operation or an assertionaction[1..*]A test in this scripttest[0..*]An operation would involve a REST request to a serveroperation[0..1]The teardown action will only contain an operationaction[1..*]A series of operations required to clean up after the all the tests are executed (successfully or otherwise)teardown[0..1]

XML Template

<TestScript xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <url value="[uri]"/><!-- 1..1 Absolute URL used to reference this TestScript -->
 <version value="[string]"/><!-- 0..1 Logical id for this version of the TestScript -->
 <name value="[string]"/><!-- 1..1 Informal name for this TestScript -->
 <status value="[code]"/><!-- 1..1 draft | active | retired -->
 <identifier><!-- 0..1 Identifier External identifier --></identifier>
 <experimental value="[boolean]"/><!-- 0..1 If for testing purposes, not real usage -->
 <publisher value="[string]"/><!-- 0..1 Name of the publisher (Organization or individual) -->
 <contact>  <!-- 0..* Contact details of the publisher -->
  <name value="[string]"/><!-- 0..1 Name of a individual to contact -->
  <telecom><!-- 0..* ContactPoint Contact details for individual or publisher --></telecom>
 </contact>
 <date value="[dateTime]"/><!-- 0..1 Date for this version of the TestScript -->
 <description value="[string]"/><!-- 0..1 Natural language description of the TestScript -->
 <useContext><!-- 0..* CodeableConcept Content intends to support these contexts --></useContext>
 <requirements value="[string]"/><!-- 0..1 Scope and Usage this Test Script is for -->
 <copyright value="[string]"/><!-- 0..1 Use and/or publishing restrictions -->
 <metadata>  <!-- 0..1 Required capability that is assumed to function correctly on the FHIR server being tested -->
  <link>  <!-- 0..* Links to the FHIR specification -->
   <url value="[uri]"/><!-- 1..1 URL to the specification -->
   <description value="[string]"/><!-- 0..1 Short description -->
  </link>
  <capability>  <!-- 1..* Capabilities  that are assumed to function correctly on the FHIR server being tested -->
   <required value="[boolean]"/><!-- 0..1 Are the capabilities required? -->
   <validated value="[boolean]"/><!-- 0..1 Are the capabilities validated? -->
   <description value="[string]"/><!-- 0..1 The expected capabilities of the server -->
   <destination value="[integer]"/><!-- 0..1 Which server these requirements apply to -->
   <link value="[uri]"/><!-- 0..* Links to the FHIR specification -->
   <conformance><!-- 1..1 Reference(Conformance) Required Conformance --></conformance>
  </capability>
 </metadata>
 <multiserver value="[boolean]"/><!-- 0..1 Whether or not the tests apply to more than one FHIR server -->
 <fixture>  <!-- 0..* Fixture in the test script - by reference (uri) -->
  <autocreate value="[boolean]"/><!-- 0..1 Whether or not to implicitly create the fixture during setup -->
  <autodelete value="[boolean]"/><!-- 0..1 Whether or not to implicitly delete the fixture during teardown -->
  <resource><!-- 0..1 Reference(Any) Reference of the resource --></resource>
 </fixture>
 <profile><!-- 0..* Reference(Any) Reference of the validation profile --></profile>
 <variable>  <!-- 0..* Placeholder for evaluated elements -->
  <name value="[string]"/><!-- 1..1 Descriptive name for this variable -->
  <headerField value="[string]"/><!-- 0..1 HTTP header field name for source -->
  <path value="[string]"/><!-- 0..1 XPath or JSONPath against the fixture body -->
  <sourceId value="[id]"/><!-- 0..1 Fixture Id of source expression or headerField within this variable -->
 </variable>
 <setup>  <!-- 0..1 A series of required setup operations before tests are executed -->
  <metadata><!-- 0..1 Content as for TestScript.metadata Capabilities  that are assumed to function correctly on the FHIR server being tested --></metadata>
  <action>  <!-- 1..* A setup operation or assert to perform -->
   <operation>  <!-- 0..1 The setup operation to perform -->
    <type><!-- 0..1 Coding The setup operation type that will be executed --></type>
    <resource value="[code]"/><!-- 0..1 Resource type -->
    <label value="[string]"/><!-- 0..1 Tracking/logging operation label -->
    <description value="[string]"/><!-- 0..1 Tracking/reporting operation description -->
    <accept value="[code]"/><!-- 0..1 xml | json -->
    <contentType value="[code]"/><!-- 0..1 xml | json -->
    <destination value="[integer]"/><!-- 0..1 Which server to perform the operation on -->
    <encodeRequestUrl value="[boolean]"/><!-- 0..1 Whether or not to send the request url in encoded format -->
    <params value="[string]"/><!-- 0..1 Explicitly defined path parameters -->
    <requestHeader>  <!-- 0..* Each operation can have one ore more header elements -->
     <field value="[string]"/><!-- 1..1 HTTP header field name -->
     <value value="[string]"/><!-- 1..1 HTTP headerfield value -->
    </requestHeader>
    <responseId value="[id]"/><!-- 0..1 Fixture Id of mapped response -->
    <sourceId value="[id]"/><!-- 0..1 Fixture Id of body for PUT and POST requests -->
    <targetId value="[id]"/><!-- 0..1 Id of fixture used for extracting the [id],  [type], and [vid] for GET requests -->
    <url value="[string]"/><!-- 0..1 Request URL -->
   </operation>
   <assert>  <!-- 0..1 The assertion to perform -->
    <label value="[string]"/><!-- 0..1 Tracking/logging assertion label -->
    <description value="[string]"/><!-- 0..1 Tracking/reporting assertion description -->
    <direction value="[code]"/><!-- 0..1 response | request -->
    <compareToSourceId value="[string]"/><!-- 0..1 Id of fixture used to compare the "sourceId/path" evaluations to -->
    <compareToSourcePath value="[string]"/><!-- 0..1 XPath or JSONPath expression against fixture used to compare the "sourceId/path" evaluations to -->
    <contentType value="[code]"/><!-- 0..1 xml | json -->
    <headerField value="[string]"/><!-- 0..1 HTTP header field name -->
    <minimumId value="[string]"/><!-- 0..1 Fixture Id of minimum content resource -->
    <navigationLinks value="[boolean]"/><!-- 0..1 Perform validation on navigation links? -->
    <operator value="[code]"/><!-- 0..1 equals | notEquals | in | notIn | greaterThan | lessThan | empty | notEmpty | contains | notContains -->
    <path value="[string]"/><!-- 0..1 XPath or JSONPath expression -->
    <resource value="[code]"/><!-- 0..1 Resource type -->
    <response value="[code]"/><!-- 0..1 okay | created | noContent | notModified | bad | forbidden | notFound | methodNotAllowed | conflict | gone | preconditionFailed | unprocessable -->
    <responseCode value="[string]"/><!-- 0..1 HTTP response code to test -->
    <sourceId value="[id]"/><!-- 0..1 Fixture Id of source expression or headerField -->
    <validateProfileId value="[id]"/><!-- 0..1 Profile Id of validation profile reference -->
    <value value="[string]"/><!-- 0..1 The value to compare to -->
    <warningOnly value="[boolean]"/><!-- 0..1 Will this assert produce a warning only on error? -->
   </assert>
  </action>
 </setup>
 <test>  <!-- 0..* A test in this script -->
  <name value="[string]"/><!-- 0..1 Tracking/logging name of this test -->
  <description value="[string]"/><!-- 0..1 Tracking/reporting short description of the test -->
  <metadata><!-- 0..1 Content as for TestScript.metadata Capabilities  that are expected to function correctly on the FHIR server being tested --></metadata>
  <action>  <!-- 1..* A test operation or assert to perform -->
   <operation><!-- 0..1 Content as for TestScript.setup.action.operation The setup operation to perform --></operation>
   <assert><!-- 0..1 Content as for TestScript.setup.action.assert The setup assertion to perform --></assert>
  </action>
 </test>
 <teardown>  <!-- 0..1 A series of required clean up steps -->
  <action>  <!-- 1..* One or more teardown operations to perform -->
   <operation><!-- 0..1 Content as for TestScript.setup.action.operation The teardown operation to perform --></operation>
  </action>
 </teardown>
</TestScript>

JSON Template

{doco
  "resourceType" : "TestScript",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "url" : "<uri>", // R!  Absolute URL used to reference this TestScript
  "version" : "<string>", // Logical id for this version of the TestScript
  "name" : "<string>", // R!  Informal name for this TestScript
  "status" : "<code>", // R!  draft | active | retired
  "identifier" : { Identifier }, // External identifier
  "experimental" : <boolean>, // If for testing purposes, not real usage
  "publisher" : "<string>", // Name of the publisher (Organization or individual)
  "contact" : [{ // Contact details of the publisher
    "name" : "<string>", // Name of a individual to contact
    "telecom" : [{ ContactPoint }] // Contact details for individual or publisher
  }],
  "date" : "<dateTime>", // Date for this version of the TestScript
  "description" : "<string>", // Natural language description of the TestScript
  "useContext" : [{ CodeableConcept }], // Content intends to support these contexts
  "requirements" : "<string>", // Scope and Usage this Test Script is for
  "copyright" : "<string>", // Use and/or publishing restrictions
  "metadata" : { // Required capability that is assumed to function correctly on the FHIR server being tested
    "link" : [{ // Links to the FHIR specification
      "url" : "<uri>", // R!  URL to the specification
      "description" : "<string>" // Short description
    }],
    "capability" : [{ // R!  Capabilities  that are assumed to function correctly on the FHIR server being tested
      "required" : <boolean>, // Are the capabilities required?
      "validated" : <boolean>, // Are the capabilities validated?
      "description" : "<string>", // The expected capabilities of the server
      "destination" : <integer>, // Which server these requirements apply to
      "link" : ["<uri>"], // Links to the FHIR specification
      "conformance" : { Reference(Conformance) } // R!  Required Conformance
    }]
  },
  "multiserver" : <boolean>, // Whether or not the tests apply to more than one FHIR server
  "fixture" : [{ // Fixture in the test script - by reference (uri)
    "autocreate" : <boolean>, // Whether or not to implicitly create the fixture during setup
    "autodelete" : <boolean>, // Whether or not to implicitly delete the fixture during teardown
    "resource" : { Reference(Any) } // Reference of the resource
  }],
  "profile" : [{ Reference(Any) }], // Reference of the validation profile
  "variable" : [{ // Placeholder for evaluated elements
    "name" : "<string>", // R!  Descriptive name for this variable
    "headerField" : "<string>", // HTTP header field name for source
    "path" : "<string>", // XPath or JSONPath against the fixture body
    "sourceId" : "<id>" // Fixture Id of source expression or headerField within this variable
  }],
  "setup" : { // A series of required setup operations before tests are executed
    "metadata" : { Content as for TestScript.metadata }, // Capabilities  that are assumed to function correctly on the FHIR server being tested
    "action" : [{ // R!  A setup operation or assert to perform
      "operation" : { // The setup operation to perform
        "type" : { Coding }, // The setup operation type that will be executed
        "resource" : "<code>", // Resource type
        "label" : "<string>", // Tracking/logging operation label
        "description" : "<string>", // Tracking/reporting operation description
        "accept" : "<code>", // xml | json
        "contentType" : "<code>", // xml | json
        "destination" : <integer>, // Which server to perform the operation on
        "encodeRequestUrl" : <boolean>, // Whether or not to send the request url in encoded format
        "params" : "<string>", // Explicitly defined path parameters
        "requestHeader" : [{ // Each operation can have one ore more header elements
          "field" : "<string>", // R!  HTTP header field name
          "value" : "<string>" // R!  HTTP headerfield value
        }],
        "responseId" : "<id>", // Fixture Id of mapped response
        "sourceId" : "<id>", // Fixture Id of body for PUT and POST requests
        "targetId" : "<id>", // Id of fixture used for extracting the [id],  [type], and [vid] for GET requests
        "url" : "<string>" // Request URL
      },
      "assert" : { // The assertion to perform
        "label" : "<string>", // Tracking/logging assertion label
        "description" : "<string>", // Tracking/reporting assertion description
        "direction" : "<code>", // response | request
        "compareToSourceId" : "<string>", // Id of fixture used to compare the "sourceId/path" evaluations to
        "compareToSourcePath" : "<string>", // XPath or JSONPath expression against fixture used to compare the "sourceId/path" evaluations to
        "contentType" : "<code>", // xml | json
        "headerField" : "<string>", // HTTP header field name
        "minimumId" : "<string>", // Fixture Id of minimum content resource
        "navigationLinks" : <boolean>, // Perform validation on navigation links?
        "operator" : "<code>", // equals | notEquals | in | notIn | greaterThan | lessThan | empty | notEmpty | contains | notContains
        "path" : "<string>", // XPath or JSONPath expression
        "resource" : "<code>", // Resource type
        "response" : "<code>", // okay | created | noContent | notModified | bad | forbidden | notFound | methodNotAllowed | conflict | gone | preconditionFailed | unprocessable
        "responseCode" : "<string>", // HTTP response code to test
        "sourceId" : "<id>", // Fixture Id of source expression or headerField
        "validateProfileId" : "<id>", // Profile Id of validation profile reference
        "value" : "<string>", // The value to compare to
        "warningOnly" : <boolean> // Will this assert produce a warning only on error?
      }
    }]
  },
  "test" : [{ // A test in this script
    "name" : "<string>", // Tracking/logging name of this test
    "description" : "<string>", // Tracking/reporting short description of the test
    "metadata" : { Content as for TestScript.metadata }, // Capabilities  that are expected to function correctly on the FHIR server being tested
    "action" : [{ // R!  A test operation or assert to perform
      "operation" : { Content as for TestScript.setup.action.operation }, // The setup operation to perform
      "assert" : { Content as for TestScript.setup.action.assert } // The setup assertion to perform
    }]
  }],
  "teardown" : { // A series of required clean up steps
    "action" : [{ // R!  One or more teardown operations to perform
      "operation" : { Content as for TestScript.setup.action.operation } // The teardown operation to perform
    }]
  }
}

 

Alternate definitions: Schema/Schematron, Resource Profile (XML, JSON), Questionnaire

6.24.4.1 Terminology Bindings

PathDefinitionTypeReference
TestScript.status The lifecycle status of a Value Set or Concept Map.RequiredConformanceResourceStatus
TestScript.useContext Indicates the countries, regions, disciplines and other aspects of use within which this artifact is targeted for use.ExtensibleContext of Use ValueSet
TestScript.setup.action.operation.type The allowable operation types.ExtensibleTestScriptOperationCodes
TestScript.setup.action.operation.resource
TestScript.setup.action.assert.resource 		Either a resource or a data type.Requiredhttp://hl7.org/fhir/valueset/defined-typesFHIRDefinedType
TestScript.setup.action.operation.accept
TestScript.setup.action.operation.contentType
TestScript.setup.action.assert.contentType 		The content or mime type.RequiredContentType
TestScript.setup.action.assert.direction The type of direction to use for assertion.RequiredAssertionDirectionType
TestScript.setup.action.assert.operator The type of operator to use for assertion.RequiredAssertionOperatorType
TestScript.setup.action.assert.response The type of response code to use for assertion.RequiredAssertionResponseTypes

6.24.4.2 Constraints

  • inv-1: On TestScript.setup.action: Setup action SHALL contain either an operation or assert but not both. (xpath on f:TestScript/f:setup/f:action: (f:operation or f:assert) and not(f:operation and f:assert))
  • inv-10: On TestScript.setup.action.operation: Setup operation SHALL contain either sourceId or targetId or params or url. (xpath on f:TestScript/f:setup/f:action/f:operation: f:sourceId or ((f:targetId or f:url or f:params) and (count(f:targetId) + count(f:url) + count(f:params) =1)) or (f:type/f:code/@value='conformance' or f:type/f:code/@value='search' or f:type/f:code/@value='transaction' or f:type/f:code/@value='history'))
  • inv-11: On TestScript.test.action.operation: Test operation SHALL contain either sourceId or targetId or params or url. (xpath on f:TestScript/f:test/f:action/f:operation: f:sourceId or (f:targetId or f:url or f:params) and (count(f:targetId) + count(f:url) + count(f:params) =1) or (f:type/f:code/@value='conformance' or f:type/f:code/@value='search' or f:type/f:code/@value='transaction' or f:type/f:code/@value='history'))
  • inv-12: On TestScript.teardown.action.operation: Teardown operation SHALL contain either sourceId or targetId or params or url. (xpath on f:TestScript/f:teardown/f:action/f:operation: f:sourceId or (f:targetId or f:url or (f:params and f:resource)) and (count(f:targetId) + count(f:url) + count(f:params) =1) or (f:type/f:code/@value='conformance' or f:type/f:code/@value='search' or f:type/f:code/@value='transaction' or f:type/f:code/@value='history'))
  • inv-13: On TestScript.setup.action.assert: Setup action assert shall contain both compareToSourceId and compareToSourcePath or neither. (xpath on f:TestScript/f:setup/f:action/f:assert: (f:compareToSourceId and f:compareToSourcePath) or not(f:compareToSourceId or f:compareToSourcePath))
  • inv-14: On TestScript.test.action.assert: Test action assert shall contain both compareToSourceId and compareToSourcePath or neither. (xpath on f:TestScript/f:test/f:action/f:assert: (f:compareToSourceId and f:compareToSourcePath) or not(f:compareToSourceId or f:compareToSourcePath))
  • inv-2: On TestScript.test.action: Test action SHALL contain either an operation or assert but not both. (xpath on f:TestScript/f:test/f:action: (f:operation or f:assert) and not(f:operation and f:assert))
  • inv-3: On TestScript.teardown.action: Teardown action SHALL contain an operation. (xpath on f:TestScript/f:teardown/f:action: f:operation)
  • inv-4: On TestScript.variable: Variable cannot contain both headerField and path. (xpath on f:TestScript/f:variable: not(f:headerField and f:path))
  • inv-5: On TestScript.metadata: TestScript metadata capability SHALL contain required or validated or both. (xpath on f:TestScript/f:metadata: f:capability/f:required or f:capability/f:validated or (f:capability/f:required and f:capability/f:validated))
  • inv-6: On TestScript.setup.metadata: Setup metadata capability SHALL contain required or validated or both. (xpath on f:TestScript/f:setup/f:metadata: f:capability/f:required or f:capability/f:validated or (f:capability/f:required and f:capability/f:validated))
  • inv-7: On TestScript.test.metadata: Test metadata capability SHALL contain required or validated or both. (xpath on f:TestScript/f:test/f:metadata: f:capability/f:required or f:capability/f:validated or (f:capability/f:required and f:capability/f:validated))
  • inv-8: On TestScript.setup.action.assert: Only a single assertion SHALL be present within setup action assert element. (xpath on f:TestScript/f:setup/f:action/f:assert: count(f:contentType) + count(f:headerField) + count(f:minimumId) + count(f:navigationLinks) + count(f:path) + count(f:resource) + count(f:responseCode) + count(f:response) + count(f:validateProfileId) <=1)
  • inv-9: On TestScript.test.action.assert: Only a single assertion SHALL be present within test action assert element. (xpath on f:TestScript/f:test/f:action/f:assert: count(f:contentType) + count(f:headerField) + count(f:minimumId) + count(f:navigationLinks) + count(f:path) + count(f:resource) + count(f:responseCode) + count(f:response) + count(f:validateProfileId) <=1)

6.24.5 Notes


6.24.5.1 How Tos


6.24.5.1.1 Test create operation

To test if create operation is properly supported on a server, run the operation as part of TestScript.test.

First, define the fixture as a reference at the top of the test script. The fixture will hold the body of the POST request:

<fixture id="example-patient"> <resource> <reference value="Patient/patient-example.xml"/> </resource> </fixture>

Note that it is illegal for the fixture to contain a resource id in a create operation.

Point the sourceId element of the create operation to the fixture id just defined:

<action> <operation> <type value="create"/> <sourceId value="example-patient"/> </operation> </action>

There are two ways to verify that the create operation returned the right status code:

  1. Use assert.response:

    <action> <assert> <response value="created"/> </assert> </action>
    See response codes for complete list.

  2. Use assert.responseCode explicitly:

    <action> <assert> <responseCode value="201"/> </assert> </action>

6.24.5.1.2 Test search operation

To test if search operation is properly supported on a server, run the operation as part of TestScript.test.

Use the resource element to specify the resource type and the params element to specify the search parameters:

<action> <operation> <type value="search"/> <resource value="Patient"/> <contentType value="json"/> <params value="?given=John&amp;family=Doe"/> <responseId value="R1"/> </operation> </action>

The contentType element is optional and will default to "xml" which will translate to HTTP request header "Content-Type" being set to "application/xml+fhir" by test engines. In this case, though, it was used to set it to "application/json+fhir".

The responseId element was used to store the response in a reference called "R1". This reference will hold both the response headers and the response body.

Verify that the search operation returned the right status code:

<action> <assert> <response value="okay"/> </assert> </action>

See response codes for complete list.

Verify that the search operation returned the right resource type:

<action> <assert> <resource value="Patient"/> </assert> </action>

There are many ways to verify that the search operation returned the right Patient:

  1. Explicitly compare the elements to known value:

    <action> <assert> <path value="fhir:Patient/fhir:birthDate/@value"/> <sourceId value="R1"/> <value value="1974-12-31"/> </assert> </action>

    The sourceId element is pointed to the responseId value of the search operation. If no sourceId is specified, then test engines will use the response of the last operation in the test script even if responseId was not specified in the operation.

    The path element holds an XPath or JSONPath expression against the response body contents.

  2. Compare the elements in response to elements in another fixture that is either dynamically set by responseId or defined statically by the fixture element at the top of the script:

    <action> <assert> <compareToSourceId value="F1"/> <compareToSourcePath value="fhir:Patient/fhir:birthDate/@value"/> <path value="fhir:Patient/fhir:birthDate/@value"/> </assert> </action>

    This time the birthDate value in the response is compared to the birthDate value in a fixture called 'F1'.

  3. Verify that the response contains all the element/content in another fixture pointed to by minimumId.

    <action> <assert> <minimumId value="F1"/> <sourceId value="R1"/> </assert> </action>

    Test engines will parse the 'body' of the F1 fixture and verify that each element and its value matches the corresponding element in the R1 response body. In other words, R1 is verified to be a 'superset' of F1. The resource id element in the body will be ignored during comparison. The headers will also be ignored.

    F1 can be statically defined or it can be the responseId for another operation. If sourceId is not specified, then test engines will use the response of the last operation. So the previous assertion could have been defined as:

    <action> <assert> <minimumId value="F1"/> </assert> </action>

6.24.5.1.3 Perform delete operation in teardown

Test scripts should clean up resources created as part of execution. The TestScript.teardown operations will get executed once before the test script execution completes.

Here are a couple of ways to run delete operation in TestScript.teardown:

  1. Use conditional delete operation in TestScript.teardown:
    <action> <operation> <type value="delete"/> <resource value="Patient"/> <params value="?given=John&amp;family=Doe"/> </operation> </action>

  2. Use delete operation with targetId fixture.

    To do that, the resource must have been created during TestScript.setup or TestScript.test:

    <action> <operation> <type value="create"/> <responseId value="create-response"/> <sourceId value="example-patient"/> </operation> </action>

    As part of TestScript.teardown, run the delete operation with targetId value pointed to sourceId value of the create operation:

    <action> <operation> <type value="delete"/> <targetId value="create-response"/> </operation> </action>

    Test engines will keep track of response headers and body of all operations.

    The delete operation's targetId value is expected to correspond to the responseId of a GET operation (such as search or read) or the sourceId of a POST/PUT operation (such as create).

    For targetId value corresponding to responseId of GET operations (such as search or read), test engines will use the resource type and id returned in the GET response body's resource to set the [type] and [id] in delete operation's URL, respectively.

    For targetId value corresponding to responseId of POST/PUT operations (such as create), test engines will use the resource type and id returned in the POST/PUT response "Location" header to set the [type] and [id] in delete operation's URL, respectively. This is the case in the example above.

    The targetId value cannot point to a statically defined fixture as the id in the fixture cannot be relied upon.

6.24.5.1.4 Perform delete operation in setup

Deletion of resources created during test script execution should be done using delete operation in TestScript.teardown. See Perform delete operation in teardown for details.

There might be left-over resource instances though on the server from prior executions of the script that terminated prematurely through an error. Resources can be deleted in TestScript.setup as well to ensure reliable test execution.

To delete a resource in setup, the server is required to support Conditional Delete operation.

Use the params element to specify the search criteria for the delete operation:

<action> <operation> <type value="delete"/> <resource value="Patient"/> <params value="?family=Doe&amp;given=Joe"/> </operation> </action>

Test engines will append the contents of the params element to url after [type]: "[base]/[type]?[search parameters]". The resource element value ("Patient") will be used to replace [type] in the url.

6.24.5.1.5 Test conditional delete operation

To test if a server supports conditional delete operation, run a create operation prior to the delete using a sourceId that points to a fixture defined at the top of the script:

<action> <operation> <type value="create"/> <sourceId value="example-patient"/> </operation> </action>

Then use the params element to specify the search criteria for the delete operation:

<action> <operation> <type value="delete"/> <resource value="Patient"/> <params value="?family=Doe&amp;given=Joe"/> </operation> </action>

Test engines will append the contents of the params element to url after [type]: "[base]/[type]?[search parameters]". The resource element value ("Patient") will be used to replace [type] in the url.

To verify that the delete operation returned the right status code:

<action> <assert> <operator value="in"/> <responseCode value="200,204"/> </assert> </action>

To verify that the resource was indeed deleted on the server, run a search using the same parameters and verify that the status code is 404 (not found):

<action> <operation> <type value="search"/> <resource value="Patient"/> <params value="?given=John&amp;family=Doe"/> </operation> </action>
<action> <assert> <response value="notFound"/> </assert> </action>

6.24.5.1.6 Test conditional create operation

To test if a server supports conditional create operation, use the 'If-None-Exist' request header:

<action> <operation> <type value="create"/> <requestHeader> <field value="If-None-Exist"/> <value value="Patient?given=John&amp;Doe&amp;birthdate=1974-12-31"/> </requestHeader> <sourceId value="F1"/> </operation> </action>

The response code of 200 verifies that the resource already exists and did not get created:

<action> <assert> <responseCode value="200"/> </assert> </action>

6.24.5.1.7 Test update operation

Update operations require a resource id. The id must be present in the fixture (PUT body contents) as well as the URL. The values must match.

Because resource ids cannot be predicted on the server, it is best to retrieve the id on a resource freshly created as part of the script

There are many ways to do that. Below is a couple:

  1. Use update operation with targetId fixture pointing to create operation's responseId:

    <action> <operation> <type value="create"/> <responseId value="create-response"/> <sourceId value="example-patient"/> </operation> </action>
    <action> <operation> <type value="update"/> <resource value="Patient"/> <responseId value="R3"/> <sourceId value="john-doe-update"/> <targetId value="create-response"/> </operation> </action>

    Test engines will keep track of response headers and body of all operations.

    The update operation's targetId value is expected to correspond to the responseId of a GET operation (such as search or read) or the sourceId of a POST/PUT operation (such as create).

    For targetId value corresponding to responseId of GET operations (such as search or read), test engines will use the resource type and id returned in the GET response body's resource to set the [type] and [id] in update operation's URL, respectively. This is the case in the next example below.

    For targetId value corresponding to responseId of POST/PUT operations (such as create and update), test engines will use the resource type and id returned in the POST/PUT response "Location" header to set the [type] and [id] in update operation's URL, respectively. This is the case in the example above.

    The targetId value cannot point to a statically defined fixture as the id in the fixture cannot be relied upon.

  2. Use update operation with targetId fixture pointing to search operation's responseId:

    <action> <operation> <type value="create"/> <responseId value="R1"/> <sourceId value="john-doe-patient"/> <!-- Fixture must be defined at the top of the script --> </operation> </action>
    <action> <operation> <type value="search"/> <resource value="Patient"/> <params value="?family=Doe&amp;given=Joe"/> <responseId value="R2"/> </operation> </action>
    <action> <operation> <type value="update"/> <resource value="Patient"/> <responseId value="R3"/> <sourceId value="john-doe-update"/> <targetId value="R2"/> </operation> </action>

After the update operation, test scripts would perform at least one more read/search operation to retrieve the contents of the updated resource and then perform assertions to verify that the data did indeed get updated on the server:

<action> <operation> <type value="search"/> <resource value="Patient"/> <params value="?family=Doe&amp;given=Joe"/> <responseId value="R4"/> </operation> </action>

Verify that the birthdate got updated and is being returned properly:

<action> <assert> <path value="fhir:Patient/fhir:birthDate/@value"/> <sourceId value="R4"/> <value value="1974-12-31"/> </assert> </action>

6.24.5.1.8 Test conditional update operation

Unlike a regular update operation, a conditional update operation does not require a resource id in the URL (or the body of the PUT).

To test conditional update, use params element in the operation instead of targetId. The resource element will be required in this case.

<action> <operation> <type value="update"/> <resource value="Patient"/> <params value="?family=Doe&amp;given=Joe"/> <responseId value="R3"/> <sourceId value="john-doe-update"/> <!-- john-doe-update fixture will have the 'correct' birthDate --> </operation> </action>

Test engines will append the contents of the params element to url after [type]: "PUT [base]/[type]?[search parameters]". The resource element value ("Patient") will be used to replace [type] in the URL.

Verify that the birthdate got updated and is being returned properly:

<action> <operation> <type value="search"/> <resource value="Patient"/> <params value="?family=Doe&amp;given=Joe"/> <responseId value="R4"/> </operation> </action>
<action> <assert> <path value="fhir:Patient/fhir:birthDate/@value"/> <sourceId value="R4"/> <value value="1974-12-31"/> </assert> </action>

6.24.5.1.9 Test read operation

The read operation operation requires the resource id in the URL. Since resource ids are unpredictable on servers, it's best to create the resource within the test script prior to executing the read operation:

<action> <operation> <type value="create"/> <responseId value="create-response"/> <sourceId value="example-patient"/> </operation> </action>

One way to execute the read operation is to run the read operation with targetId value pointed to responseId value of the create operation:

<action> <operation> <type value="read"/> <targetId value="create-response"/> </operation> </action>

Test engines will keep track of response headers and body of all operations.

The read operation's targetId value is expected to correspond to the responseId of a GET operation (such as search or read) or the sourceId of a POST/PUT operation (such as create).

For targetId value corresponding to responseId of GET operations (such as search or read), test engines will use the resource type and id returned in the GET response body's resource to set the [type] and [id] in read operation's URL, respectively.

For targetId value corresponding to responseId of POST/PUT operations (such as create), test engines will use the resource type and id returned in the POST/PUT response "Location" header to set the [type] and [id] in read operation's URL, respectively. This is the case in the example above.

The targetId value cannot point to a statically defined fixture as the id in the fixture cannot be relied upon.

6.24.5.1.10 Test vread operation

The vread operation operation requires the resource id as well as the resource version id in the URL. Since resource ids and version ids are unpredictable on servers, it's best to create the resource within the test script prior to executing the vread operation:

<action> <operation> <type value="create"/> <responseId value="create-response"/> <sourceId value="example-patient"/> </operation> </action>

One way to execute the vread operation is to run the vread operation with targetId value pointed to responseId value of the create operation:

<action> <operation> <type value="vread"/> <targetId value="create-response"/> </operation> </action>

Test engines will keep track of response headers and body of all operations.

The vread operation's targetId value is expected to correspond to the responseId of a GET operation (such as search or read) or the sourceId of a POST/PUT operation (such as create).

For targetId value corresponding to responseId of GET operations (such as search or read), test engines will use the resource type, id and version id returned in the GET response body's resource to set the [type], [id] and [vid] in vread operation's URL, respectively.

For targetId value corresponding to responseId of POST/PUT operations (such as create), test engines will use the resource type, id and version id returned in the POST/PUT response "Location" header to set the [type], [id] and [vid] in vread operation's URL, respectively. This is the case in the example above.

The targetId value cannot point to a statically defined fixture as the id in the fixture cannot be relied upon.

6.24.5.1.11 Test history operation

The history operation can be executed in the following ways:

  1. GET [base]/[type]/[id]/_history{?[parameters]&_format=[mime-type]}

    Here the resource id is required in the URL. This is similar to read operation if targetId elemet is used. See Test read operation for details.

    <action> <operation> <type value="history"/> <targetId value="create-response"/> <!-- or search-response or update-response --> </operation> </action>
    <action> <assert> <resource value="Bundle"/> </assert> </action>
  2. GET [base]/[type]/_history{?[parameters]&_format=[mime-type]}

    Here the resource id is not required in the URL.

    Instead of targetId element, the params element can be used to specify the search criteria for the history operation.

    In the following example, all history entries for John Doe patient would be returned by server:

    <action> <operation> <type value="history"/> <resource value="Patient"/> <params value="?family=Doe&amp;given=Joe"/> </operation> </action>
  3. GET [base]/_history{?[parameters]&_format=[mime-type]}

    Here neither the resource type nor the resource id is required in the url. In the following example, no more than 50 history entries would be returned by server:

    <action> <operation> <type value="history"/> <params value="?_count=50"/> </operation> </action>

6.24.5.1.12 Specify Accept header in request

The default "Accept" header that will be set on all GET operations (such as read, vread, search, history, etc.) will be "application/xml+fhir".

There are two ways to change the default "Accept" header:

  1. Use the accept element:

    <action> <operation> <type value="read"/> <accept value="json"/> <targetId value="F1"/> </operation> </action>

    Test engines will set the Accept header to "application/json+fhir" if "json" is specified and will use "application/xml+fhir" if "xml" is specified.

  2. Use the requestHeader element to set "Accept" explicitly:

    <action> <operation> <type value="read"/> <requestHeader> <field value="Accept"/> <value value="application/json+fhir"/> </requestHeader> <targetId value="F1"/> </operation> </action>

    Test engines will take values specified for requestHeader "as-is" and not transform them. This might be useful for negative testing e.g. the value can be set explicitly to "applcation/xml" or an invalid value and verify server response.

6.24.5.1.13 Specify Content-Type header in request

The default "Content-Type" header that will be set on all POST/PUT operations (such as create, update, etc.) will be "application/xml+fhir".

There are two ways to change the default "Content-Type" header:

  1. Use the contentType element:

    <action> <operation> <type value="create"/> <contentType value="json"/> <targetId value="F1"/> </operation> </action>

    Test engines will set the Content-Type header to "application/json+fhir" if "json" is specified and will use "application/xml+fhir" if "xml" is specified.

  2. Use the requestHeader element to set Content-Type explicitly:

    <action> <operation> <type value="create"/> <requestHeader> <field value="Content-Type"/> <value value="application/json+fhir"/> </requestHeader> <targetId value="F1"/> </operation> </action>

    Test engines will take values specified for requestHeader "as-is" and not transform them. This might be useful for negative testing e.g. the value can be set explicitly to "applcation/xml" or an invalid value and verify server response.

6.24.5.1.14 Verify Content-Type header in response

There are two ways to verify the "Content-Type" header in response:

  1. Use the contentType element:

    <action> <assert> <contentType value="json"/> </assert> </action>

    Test engines will verify that "application/json+fhir" is present in Content-Type header if "json" is specified and will verify that "application/xml+fhir" is present if "xml" is specified.

  2. Use the requestHeader element to verify Content-Type explicitly:

    <action> <assert> <headerField value="Content-Type"/> <value value="application/json+fhir"/> </assert> </action>

    Test engines will take values specified for headerField "as-is" and not interpret them.

    Note that test engines will not verify contentType in response if assertions for contentType are missing.

6.24.5.1.15 Use variables

Variables can be defined against static fixtures and dynamic operation responses. They can be used in "operation.params", "operation.requestHeader.value", "operation.url", and "assert.value" element values. As such they allow for the data used in operations and assertions to be externally defined. The data could be unique to each client involved in interactions with a server or could be unique to a given server database instance. This allows for multiple clients to execute the same test scripts concurrently against the same server.

Variables would be defined at the top of the script.

Below is a variable that is defined as the Location header to the response referenced by "R1":

<variable> <name value="V1"/> <headerField value="Location"/> <sourceId value="R1"/> </variable>

Test engines will not evaluate this at this point. They will store the expresssion in "V1" and will look for "${}" in "operation.params", "operation.requestHeader.value", and "operation.url" element values during operation calls.

Here is a read operation that will use the V1 variable. The variable expression was "Location against R1 response" (defined above). If a prior operation has not set R1 to be the responseId of the operation, then test engine will error out. Otherwise, V1 will be set to the Location header value of R1 response and that value will be substituted for ${V1} below. In other words, the read will be performed against the Location header value of R1 response.

<action> <operation> <type value="read"/> <accept value="json"/> <responseId value="R2"/> <url value="${V1}"/> </operation> </action>

Below are three variables defined as path expressions against the static fixture referenced by "F1". The expressions are against the given name, family name, and birthDate of a patient resource. The resource data will be managed external to the test script.

<variable> <name value="PatientGivenName"/> <path value="fhir:Patient/fhir:name/fhir:given/@value"/> <sourceId value="F1"/> </variable> <variable> <name value="PatientFamilyName"/> <path value="fhir:Patient/fhir:name/fhir:family/@value"/> <sourceId value="F1"/> </variable> <variable> <name value="PatientDOB"/> <path value="hir:Patient/fhir:birthDate/@value"/> <sourceId value="F1"/> </variable>

Again, test engines will not evaluate the path expression at this point. They will look for anything wrapped in '${}' in "operation.params", "operation.requestHeader.value", "operation.url", and "assert.value" element values and substitute the placeholders with the evaluated expressions.

Here is a conditional create operation that will set the requestHeader using the PatientGivenName, PatientFamilyName, and PatientDOB variables defined above. The variable expressions were path expressions against the statically defined F1 fixture. They will be evaluated against the fixture body (containing resource) and the corresponding values will be extracted from the fixtures and used to substitute the variables in the requestHeader value below.

<action> <operation> <type value="create"/> <requestHeader> <field value="If-None-Exist"/> <value value="Patient?given=${PatientGivenName}&amp;${PatientFamilyName}&amp;birthdate=${PatientDOB}"/> </requestHeader> <sourceId value="F1"/> </operation> </action>

Here is a search operation that will perform a search using the PatientGivenName, PatientFamilyName, and PatientDOB variables defined above. The variable expressions were path expressions against the statically defined F1 fixture. They will be evaluated against the fixture body (containing resource) and the corresponding values will be extracted from the fixtures and used to substitute the variables in the params value below.

<action> <operation> <type value="search"/> <resource value="Patient"/> <accept value="json"/> <params value="?given=${PatientGivenName}&amp;family=${PatientFamilyName}&amp;birthdate=${PatientDOB}"/> <responseId value="R3"/> </operation> </action>

Here are the assertions that verify that the search was successful:

<action> <assert> <path value="Patient/name/given"/> <value value="${PatientGivenName}"/> </assert> </action> <action> <assert> <path value="Patient/name/family"/> <value value="${PatientFamilyName}"/> </assert> </action> <action> <assert> <path value="Patient/birthdate"/> <value value="${PatientDOB}"/> </assert> </action>

6.24.5.1.16 Test server support for '_format'

Servers are required to support "_format" in the request url to determine the response mime-type. See Content Type and Encodings

Use the params element to specify the _format:

<action> <operation> <type value="search"/> <resource value="Patient"/> <params value="?family=Doe&amp;given=Joe&amp;_format=application/json+fhir"/> <responseId value="R1"/> </operation> </action>

Use the requestHeader element to verify Content-Type explicitly:

<action> <assert> <headerField value="Content-Type"/> <value value="application/json+fhir"/> </assert> </action>

6.24.5.1.17 How to specify metadata capabilities

If the capabilities are supported by the server, then the TestScript can be executed. Otherwise, the TestScript as a whole or a specific test within the test script may be skipped depending on where the capabilities section is defined.

Here's how to specify that the test script requires the server to support Patient create and delete operations:

<metadata> <capabilities> <required value="true"/> <description value="Patient Create and Delete Operation"/> <link value="http://hl7.org/implement/standards/FHIR-Develop/http.html#create"/> <link value="http://hl7.org/implement/standards/FHIR-Develop/http.html#delete"/> <conformance> <reference value="/Conformance/PatientCreateDelete.xml"/> </conformance> </capabilities> </metadata>

The contents of PatientCreateDelete.xml would be a minimal conformance statement to indicate what sections need to be present in server conformance statement:

<Conformance xmlns="http://hl7.org/fhir"> <rest> <mode value="server"/> <resource> <type value="Patient"/> <interaction> <code value="create"/> </interaction> <interaction> <code value="delete"/> </interaction> </resource> </rest> </Conformance>

When the metadata capabilities section is defined at TestScript.metadata or at TestScript.setup.metadata, and the server's conformance statement does not contain the elements defined in the minimal conformance statement, then all the tests in the TestScript are skipped.

When the metadata capabilities section is defined at TestScript.test.metadata and the server's conformance statement does not contain the elements defined in the minimal conformance statement, then only that test is skipped.

The "metadata.capabilities.required" and "metadata.capabilities.validated" elements only indicate whether the capabilities are the primary focus of the test script or not. The do not impact the skipping logic. Capabilities whose "metadata.capabilities.validated" flag is true are the primary focus of the test script.

6.24.6 Operations

This table presents a summary of the constraints applicable to TestScript.setup.action.operation, TestScript.test.action.operation, and TestScript.teardown.action.operation elements. The operation elements should be configured consistently with the FHIR RESTful API summary.

read vread search history create update transaction conformance delete
params The params element can be used to specify the [id] using variable substitutions and the rest of the highlighted portion in the request URL:

[base]/[type]/[id] {?_format=[mime-type]}

If used, then resource is required and targetId and url must not be specified.		 The params element can be used to specify the [id] and [vid] using variable substitutions and the rest of the highlighted portion in the request URL:

[base]/[type]/[id]/_history/[vid] {?_format=[mime-type]}

If used, then resource is required and targetId and url must not be specified.		 The params element can be used to specify the highlighted portion in the request URL:

[base]/[type]{?[parameters]{&_format=[mime-type]}}

If used, then resource is optional and targetId and url must not be specified.		 The params element can be used to specify the [id] using variable substitutions and the rest of the highlighted portion in the following request URLs:
[base]/[type]/[id]/_history{?[parameters]&_format=[mime-type]}
[base]/[type]/_history{?[parameters]&_format=[mime-type]}
[base]/_history{?[parameters]&_format=[mime-type]}

If used, then resource is optional and targetId and url must not be specified.		 N/A The params element can be used in conditional update operation to specify the highlighted portion of the request URL:

[base]/[type]?[search parameters]

If used, then resource is required and targetId and url must not be specified.		 N/A The params element can be used to specify the highlighted portion in the request URL:

[base]/metadata {?_format=[mime-type]}

If used, then resource is ignored and targetId and url must not be specified.		 The params element can be used to specify the [id] using variable substitutions in the request URL:

[base]/[type]/[id]

If used, then resource is required and targetId and url must not be specified.
resource The resource element is required to specify the resource ([type]) in the request URL when params element is used. Will be ignored if targetId or url are specified. In the case of targetId, the resource type will be extracted from the fixture. If targetId is specified, then [type] for request URL will be determined from targetId's fixture and resource element will be ignored. Otherwise, resource type will be extracted from sourceId's fixture if specified. For conditional updates, resource is required. N/A N/A If targetId is specified, then [type] for request URL will be determined from targetId and resource element will be ignored. For conditional deletes, resource is required.
sourceId N/A N/A N/A N/A The sourceId element points to a fixture to be used for the created resource. The fixture cannot contain the id element. The sourceId element points to a fixture to be used for the updated resource. Has to correspond to the responseId of an operation executed upstream in the test script. The response body must contain a resource with a resource id. The sourceId fixture cannot be statically defined because the id cannot be relied upon. Fixture to be used for the transaction. Has to be a Bundle. N/A N/A
targetId The targetId element can be used to specify the [type] and [id] in the request URL.

If used, then params and url must not be specified.

The targetId value has to correspond to the responseId of an operation executed upstream in the test script. The response body must contain a reosurce with a resource id. The targetId fixture cannot be statically defined because the id cannot be relied upon.		 The targetId element can be used to specify the [type], [id], and [vid] in the request URL.

If used, then params and url must not be specified.

The targetId value has to correspond to the responseId of an operation executed upstream in the test script. The response body must contain a reosurce with a resource id. The targetId fixture cannot be statically defined because the id and vid cannot be relied upon.		 The targetId element cannot be used as it's not allowed with params element The targetId element can be used to specify the [type], [id], and [vid] in the request URL.

If used, then params and url must not be specified.

The targetId value has to correspond to the responseId of an operation executed upstream in the test script. The response body must contain a reosurce with a resource id. The targetId fixture cannot be statically defined because the id and vid cannot be relied upon.		 N/A. The [type] for the request URL will be extracted from sourceId. N/A. The [type] for the request URL will be extracted from sourceId. N/A. N/A. The targetId element can be used to specify the [type] and [id] in the request URL.

If used, then params and url must not be specified.

The targetId value has to correspond to the responseId of an operation executed upstream in the test script. The response body must contain a reosurce with a resource id. The targetId fixture cannot be statically defined because the id cannot be relied upon.
responseId The responseId element can be used to reference the operation response containing response body and headers. If specified, the value can later be used in assertion sourceId to evaluate path (XPath/JSONPath) and headerFields against the response received for an operation. N/A
accept The accept element can be used to specify the "Accept" header in the outgoing HTTP request. If "json" is specified, then "Accept" value of "application/json+fhir" will be set in the request header. If "xml" is specified, then "application/xml+fhir" will be used. N/A
contentType The contentType element can be used to specify the "Content-Type" header in the outgoing HTTP request. If "json" is specified, then "Content-Type" value of "application/json+fhir" will be set in the request header. If "xml" is specified, then "application/xml+fhir" will be used. N/A
requestHeader The requestHeader element allows for request headers to be specified explicitly. Test engines will take values specified for requestHeader "as-is" and not transform them. This allows for testing using:
destination If the TestScript is testing more than one FHIR server simultaneously, the destination identifies which server the operation applies to using zero-based indexing.
url The url element will contain the full HTTP URL for the operation. This should rarely be used in test scripts. One possible application would be to test if the Location header returned in a response is pointing to an expected resource. See testscript-search example.

6.24.7 Assertions

Assertion Valid operator values Description
contentType equals | notEquals | contains | notContains Asserts that the "Content-Type" in response header is or is not the specified value for contentType element depending on the operator used.
headerField equals | notEquals | in | notIn | greaterThan | lessThan | empty | notEmpty | contains | notContains Asserts that the header specified for headerField element in the response contains, not contains, is equal, not equal, in, not in, greater than, or less than the value specified for value element if present.
If the operator is "empty" or "notEmpty" then value will be ignored.
If sourceId is not specified, then headerField will be evaluated against the last operation's response headers.
minimumId N/A Asserts that the response contains all the element/content in another fixture pointed to by minimumId element. This can be a statically defined fixture or one that is dynamically set via responseId.
navigationLinks N/A Asserts that the response Bundle contains or does NOT contain first, last, and next links depending on whether or not navigationLinks element is set to true or false.
path equals | notEquals | in | notIn | greaterThan | lessThan | empty | notEmpty | contains | notContains Asserts that path against the response body evaluates to a value that contains, not contains, is equal, not equal, in, not in, greater than, or less than the value specified for value element if present.
If the operator is "empty" or "notEmpty" then value will be ignored.
If sourceId is not specified, then path will be evaluated against the last operation's response body.
compareToSourcePath equals | notEquals Asserts that compareToSourcePath against the response body of compareToSourceId fixture evaluates to a value that is equal or notEqual to the evaluated value of path which must be present also.
resource equals | notEquals Asserts that the resource returned in the response body is or is not of the specified value for resource element.
response equals | notEquals Asserts that status code in the response is or is not one of the enumerated values in response abbreviations.
responseCode equals | notEquals | in | notIn | greaterThan | lessThan Asserts that status code in the response is equal, notEqual, in, not in, greater than, or less than the specified value(s) for responseCode element
validateProfileId N/A Asserts that the response is valid according to the profile specified by validateProfileId element.

6.24.8 Search Parameters

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

NameTypeDescriptionPaths
descriptionstringNatural language description of the TestScriptTestScript.description
identifiertokenExternal identifierTestScript.identifier
namestringInformal name for this TestScriptTestScript.name
testscript-capabilitystringTestScript required and validated capabilityTestScript.metadata.capability.description
testscript-setup-capabilitystringTestScript setup required and validated capabilityTestScript.setup.metadata.capability.description
testscript-test-capabilitystringTestScript test required and validated capabilityTestScript.test.metadata.capability.description
urluriAbsolute URL used to reference this TestScriptTestScript.url