TestScript
is
a
resource
that
specifies
a
suite
of
tests
against
a
FHIR
server
implementation
to
determine
compliance
against
the
FHIR
specification.
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
6.29.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
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.
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
determine
whether
a
given
FHIR
server
adheres
to
the
FHIR
specification
and
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
).
The purpose of the TestScript is to encode in an executable representation tests that can be used to
determine whether a given FHIR server adheres to the FHIR specification and
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
6.29.2
Boundaries and Relationships The
TestScript
resource
should
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:
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 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.29.3
Background and Context
6.24.3.1
6.29.3.1
Background
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
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 and clients. The TestScript resource provides an implementation agnostic description of tests that allows test execution engines to evaluate if a FHIR 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 in order 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
6.29.3.2
Execution
Execution
6.24.3.2.1
6.29.3.2.1
Workflow
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.
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
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
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
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.
). 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
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
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
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.
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.
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
6.29.3.2.2
Fixtures
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.
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. All defined fixtures are expected to be required in order 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
6.29.3.2.3
Variables
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.
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 within the context of a testing event such as a Connectathon. It can be very useful in year-round testing against public servers as well.
6.24.3.2.4
6.29.3.2.4
Operation
Execution
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
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.
). 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
6.29.3.2.5
Assertion
Execution
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.
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.
Required
capability
that
is
assumed
to
function
correctly
on
the
FHIR
server
being
tested
Required capability that is assumed to function correctly on the FHIR server being tested
TestScript
metadata
capability
SHALL
contain
required
or
validated
or
both.
TestScript metadata capability SHALL contain required or validated or both.
Capabilities
that
are
assumed
to
function
correctly
on
the
FHIR
server
being
tested
Capabilities that are assumed to function correctly on the FHIR server being tested
Placeholder
for
evaluated
elements
Placeholder for evaluated elements
Variable
cannot
contain
both
headerField
and
path.
Variable cannot contain both headerField and path.
Capabilities
that
are
assumed
to
function
correctly
on
the
FHIR
server
being
tested
Capabilities that are assumed to function correctly on the FHIR server being tested
Setup
metadata
capability
SHALL
contain
required
or
validated
or
both.
Setup metadata capability SHALL contain required or validated or both.
A
setup
operation
or
assert
to
perform
A setup operation or assert to perform
Setup
action
SHALL
contain
either
an
operation
or
assert
but
not
both.
Setup action SHALL contain either an operation or assert but not both.
The
setup
operation
to
perform
The setup operation to perform
Setup
operation
SHALL
contain
either
sourceId
or
targetId
or
params
or
url.
Setup operation SHALL contain either sourceId or targetId or params or url.
The
setup
operation
type
that
will
be
executed
The operation code type that will be executed
TestScriptOperationCodes
(
TestScriptOperationCode
(
Extensible
)
Id
of
fixture
used
for
extracting
the
[id],
[type],
and
[vid]
for
GET
requests
Id of fixture used for extracting the [id], [type], and [vid] for GET requests
The
assertion
to
perform
The assertion to perform
Setup
action
assert
shall
contain
both
compareToSourceId
and
compareToSourcePath
or
neither.
Setup action assert shall contain both compareToSourceId and compareToSourcePath or neither.
Only
a
single
assertion
SHALL
be
present
within
setup
action
assert
element.
Only a single assertion SHALL be present within setup action assert element.
XPath
or
JSONPath
expression
against
fixture
used
to
compare
the
"sourceId/path"
evaluations
to
XPath or JSONPath expression against fixture used to compare the "sourceId/path" evaluations to
Capabilities
that
are
expected
to
function
correctly
on
the
FHIR
server
being
tested
Capabilities that are expected to function correctly on the FHIR server being tested
Test
metadata
capability
SHALL
contain
required
or
validated
or
both.
Test metadata capability SHALL contain required or validated or both.
A
test
operation
or
assert
to
perform
A test operation or assert to perform
Test
action
SHALL
contain
either
an
operation
or
assert
but
not
both.
Test action SHALL contain either an operation or assert but not both.
The
setup
operation
to
perform
The setup operation to perform
Test
operation
SHALL
contain
either
sourceId
or
targetId
or
params
or
url.
Test operation SHALL contain either sourceId or targetId or params or url.
The
setup
assertion
to
perform
The setup assertion to perform
Test
action
assert
shall
contain
both
compareToSourceId
and
compareToSourcePath
or
neither.
Test action assert shall contain both compareToSourceId and compareToSourcePath or neither.
Only
a
single
assertion
SHALL
be
present
within
test
action
assert
element.
Only a single assertion SHALL be present within test action assert element.
One
or
more
teardown
operations
to
perform
One or more teardown operations to perform
Teardown
action
SHALL
contain
an
operation.
Teardown action SHALL contain an operation.
The
teardown
operation
to
perform
The teardown operation to perform
Teardown
operation
SHALL
contain
either
sourceId
or
targetId
or
params
or
url.
Teardown operation SHALL contain either sourceId or targetId or params or url.
Required
capability
that
is
assumed
to
function
correctly
on
the
FHIR
server
being
tested
Required capability that is assumed to function correctly on the FHIR server being tested
TestScript
metadata
capability
SHALL
contain
required
or
validated
or
both.
TestScript metadata capability SHALL contain required or validated or both.
Capabilities
that
are
assumed
to
function
correctly
on
the
FHIR
server
being
tested
Capabilities that are assumed to function correctly on the FHIR server being tested
Placeholder
for
evaluated
elements
Placeholder for evaluated elements
Variable
cannot
contain
both
headerField
and
path.
Variable cannot contain both headerField and path.
Capabilities
that
are
assumed
to
function
correctly
on
the
FHIR
server
being
tested
Capabilities that are assumed to function correctly on the FHIR server being tested
Setup
metadata
capability
SHALL
contain
required
or
validated
or
both.
Setup metadata capability SHALL contain required or validated or both.
A
setup
operation
or
assert
to
perform
A setup operation or assert to perform
Setup
action
SHALL
contain
either
an
operation
or
assert
but
not
both.
Setup action SHALL contain either an operation or assert but not both.
The
setup
operation
to
perform
The setup operation to perform
Setup
operation
SHALL
contain
either
sourceId
or
targetId
or
params
or
url.
Setup operation SHALL contain either sourceId or targetId or params or url.
The
setup
operation
type
that
will
be
executed
The operation code type that will be executed
TestScriptOperationCodes
(
TestScriptOperationCode
(
Extensible
)
Id
of
fixture
used
for
extracting
the
[id],
[type],
and
[vid]
for
GET
requests
Id of fixture used for extracting the [id], [type], and [vid] for GET requests
The
assertion
to
perform
The assertion to perform
Setup
action
assert
shall
contain
both
compareToSourceId
and
compareToSourcePath
or
neither.
Setup action assert shall contain both compareToSourceId and compareToSourcePath or neither.
Only
a
single
assertion
SHALL
be
present
within
setup
action
assert
element.
Only a single assertion SHALL be present within setup action assert element.
XPath
or
JSONPath
expression
against
fixture
used
to
compare
the
"sourceId/path"
evaluations
to
XPath or JSONPath expression against fixture used to compare the "sourceId/path" evaluations to
Capabilities
that
are
expected
to
function
correctly
on
the
FHIR
server
being
tested
Capabilities that are expected to function correctly on the FHIR server being tested
Test
metadata
capability
SHALL
contain
required
or
validated
or
both.
Test metadata capability SHALL contain required or validated or both.
A
test
operation
or
assert
to
perform
A test operation or assert to perform
Test
action
SHALL
contain
either
an
operation
or
assert
but
not
both.
Test action SHALL contain either an operation or assert but not both.
The
setup
operation
to
perform
The setup operation to perform
Test
operation
SHALL
contain
either
sourceId
or
targetId
or
params
or
url.
Test operation SHALL contain either sourceId or targetId or params or url.
The
setup
assertion
to
perform
The setup assertion to perform
Test
action
assert
shall
contain
both
compareToSourceId
and
compareToSourcePath
or
neither.
Test action assert shall contain both compareToSourceId and compareToSourcePath or neither.
Only
a
single
assertion
SHALL
be
present
within
test
action
assert
element.
Only a single assertion SHALL be present within test action assert element.
One
or
more
teardown
operations
to
perform
One or more teardown operations to perform
Teardown
action
SHALL
contain
an
operation.
Teardown action SHALL contain an operation.
The
teardown
operation
to
perform
The teardown operation to perform
Teardown
operation
SHALL
contain
either
sourceId
or
targetId
or
params
or
url.
Teardown operation SHALL contain either sourceId or targetId or params or url.
Indicates
the
countries,
regions,
disciplines
and
other
aspects
of
use
within
which
this
artifact
is
targeted
for
use.
Indicates the countries, regions, disciplines and other aspects of use within which this artifact is targeted for use.
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)
: On TestScript.setup.action: Setup action SHALL contain either an operation or assert but not both. (
expression
on TestScript.setup.action:
operation xor 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')
: On TestScript.setup.action.operation: Setup operation SHALL contain either sourceId or targetId or params or url. (
expression
on TestScript.setup.action.operation:
sourceId or (targetId.count() + url.count() + params.count() = 1) or (type.code in ('conformance' |'search' | 'transaction' | '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')
: On TestScript.test.action.operation: Test operation SHALL contain either sourceId or targetId or params or url. (
expression
on TestScript.test.action.operation:
sourceId or (targetId.count() + url.count() + params.count() = 1) or (type.code in ('conformance' | 'search' | 'transaction' | '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')
: On TestScript.teardown.action.operation: Teardown operation SHALL contain either sourceId or targetId or params or url. (
expression
on TestScript.teardown.action.operation:
sourceId or (targetId.count() + url.count() + params.count() = 1) or (type.code in ('conformance' | 'search' | 'transaction' | '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)
: On TestScript.setup.action.assert: Setup action assert shall contain both compareToSourceId and compareToSourcePath or neither. (
expression
on TestScript.setup.action.assert:
compareToSourceId.empty() xor 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)
: On TestScript.test.action.assert: Test action assert shall contain both compareToSourceId and compareToSourcePath or neither. (
expression
on TestScript.test.action.assert:
compareToSourceId.empty() xor 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)
: On TestScript.test.action: Test action SHALL contain either an operation or assert but not both. (
expression
on TestScript.test.action:
operation xor assert
)
inv-3
:
On
TestScript.teardown.action:
Teardown
action
SHALL
contain
an
operation.
(xpath
on
f:TestScript/f:teardown/f:action:
f:operation
: On TestScript.teardown.action: Teardown action SHALL contain an operation. (
expression
on TestScript.teardown.action:
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)
: On TestScript.variable: Variable cannot contain both headerField and path. (
expression
on TestScript.variable:
headerField.empty() or path.empty()
)
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)
: On TestScript.metadata: TestScript metadata capability SHALL contain required or validated or both. (
expression
on TestScript.metadata:
capability.required or capability.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)
: On TestScript.setup.metadata: Setup metadata capability SHALL contain required or validated or both. (
expression
on TestScript.setup.metadata:
capability.required or capability.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)
: On TestScript.test.metadata: Test metadata capability SHALL contain required or validated or both. (
expression
on TestScript.test.metadata:
capability.required or capability.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
: On TestScript.setup.action.assert: Only a single assertion SHALL be present within setup action assert element. (
expression
on TestScript.setup.action.assert:
contentType.count() + headerField.count() + minimumId.count() + navigationLinks.count() + path.count() + resource.count() + responseCode.count() + response.count() + rule.count() + ruleset.count() + validateProfileId.count() <=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
: On TestScript.test.action.assert: Only a single assertion SHALL be present within test action assert element. (
expression
on TestScript.test.action.assert:
contentType.count() + headerField.count() + minimumId.count() + navigationLinks.count() + path.count() + resource.count() + responseCode.count() + response.count() + rule.count() + ruleset.count() + validateProfileId.count() <=1
)
6.24.5.1.1
6.29.5.1.1
Test
create
operation
Test create operation To
test
if
To test if
create
operation
is
properly
supported
on
a
server,
run
the
operation
as
part
of
operation is properly supported on a server, run the operation as part of
TestScript.test
.
First,
define
the
<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
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:
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:
Use
There are two ways to verify that the create operation returned the right status code:
Use
assert.response
:
<action> <assert> <response value="created"/> </assert> </action> See
response
codes
for
complete
list.
Use
6.24.5.1.2
6.29.5.1.2
Test
search
operation
Test search operation To
test
if
To test if
search
operation
is
properly
supported
on
a
server,
run
the
operation
as
part
of
operation is properly supported on a server, run the operation as part of
TestScript.test
.
Use
the
resource
element
to
specify
the
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
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:
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:
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:
Explicitly
compare
the
elements
to
known
value:
There are many ways to verify that the search operation returned the right Patient:
The
path
element
holds
an
XPath
or
JSONPath
expression
against
the
response
body
contents.
Compare
the
elements
in
response
to
elements
in
another
fixture
that
is
either
dynamically
set
by
element holds an XPath or JSONPath expression against the response body contents.
Compare the elements in response to elements in another fixture that is either dynamically set by
responseId
or
defined
statically
by
the
or defined statically by the
fixture
element
at
the
top
of
the
script:
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'.
Verify
that
the
response
contains
all
the
element/content
in
another
fixture
pointed
to
by
This time the birthDate value in the response is compared to the birthDate value in a fixture called 'F1'.
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
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.
6.24.5.1.3
6.29.5.1.3
Perform
delete
operation
in
teardown
Perform delete operation in teardown Test
scripts
should
clean
up
resources
created
as
part
of
execution.
The
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
operations will get executed once before the test script execution completes.
Here are a couple of ways to run delete operation in
TestScript.teardown
:
Use
conditional
delete
operation
in
<action> <operation> <type value="delete"/> <resource value="Patient"/> <params value="?given=John&family=Doe"/> </operation> </action> Use
delete
operation
with
targetId
fixture.
To
do
that,
the
resource
must
have
been
created
during
Use delete operation with targetId fixture.
To do that, the resource must have been created during
TestScript.setup
or
or
TestScript.test
:
<action> <operation> <type value="create"/> <responseId value="create-response"/> <sourceId value="example-patient"/> </operation> </action> As
part
of
<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.
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
6.29.5.1.4
Perform
delete
operation
in
setup
Perform delete operation in setup Deletion
of
resources
created
during
test
script
execution
should
be
done
using
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
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:
element to specify the search criteria for the delete operation:
<action> <operation> <type value="delete"/> <resource value="Patient"/> <params value="?family=Doe&given=Joe"/> </operation> </action> Test
engines
will
append
the
contents
of
the
params
element
to
url
after
[type]:
"[base]/[type]
6.24.5.1.5
6.29.5.1.5
Test
conditional
delete
operation
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
<action> <operation> <type value="create"/> <sourceId value="example-patient"/> </operation> </action> Then
use
the
Then use the
params
element
to
specify
the
search
criteria
for
the
delete
operation:
element to specify the search criteria for the delete operation:
<action> <operation> <type value="delete"/> <resource value="Patient"/> <params value="?family=Doe&given=Joe"/> </operation> </action> Test
engines
will
append
the
contents
of
the
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):
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):
6.24.5.1.6
6.29.5.1.6
Test
conditional
create
operation
Test conditional create operation To
test
if
a
server
supports
conditional
create
operation,
use
the
'If-None-Exist'
request
header:
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&Doe&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:
The response code of 200 verifies that the resource already exists and did not get created:
<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.
Use
update
operation
with
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.
Use update operation with
targetId
fixture
pointing
to
search
operation's
fixture pointing to search operation's
responseId
:
<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:
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&given=Joe"/> <responseId value="R4"/> </operation> </action> Verify
that
the
birthdate
got
updated
and
is
being
returned
properly:
Verify that the birthdate got updated and is being returned properly:
6.24.5.1.8
6.29.5.1.8
Test
conditional
update
operation
Test conditional update operation Unlike
a
regular
update
operation,
a
conditional
Unlike a regular
update
operation
does
not
require
a
resource
id
in
the
URL
(or
the
body
of
the
PUT).
To
test
conditional
update,
use
operation, a
conditional update
operation does not require a resource id in the URL (or the body of the PUT).
<action> <operation> <type value="update"/> <resource value="Patient"/> <params value="?family=Doe&given=Joe"/> <responseId value="R3"/> <sourceId value="john-doe-update"/> </operation> </action> Test
engines
will
append
the
contents
of
the
6.24.5.1.9
6.29.5.1.9
Test
read
operation
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
The
read
operation:
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
One way to execute the read operation is to run the read operation with
targetId
value
pointed
to
value pointed to
responseId
value
of
the
create
operation:
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.
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
6.29.5.1.10
Test
vread
operation
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
The
vread
operation:
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
One way to execute the vread operation is to run the vread operation with
targetId
value
pointed
to
value pointed to
responseId
value
of
the
create
operation:
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.
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
6.29.5.1.11
Test
history
operation
Test history operation The
The
history
operation
can
be
executed
in
the
following
ways:
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.
operation can be executed in the following ways:
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> <assert> <resource value="Bundle"/> </assert> </action> GET
[base]/[type]/_history{?[parameters]&_format=[mime-type]}
Here
the
resource
id
is
not
required
in
the
URL.
Instead
of
GET [base]/[type]/_history{?[parameters]&_format=[mime-type]}
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&given=Joe"/> </operation> </action> 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:
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:
6.24.5.1.12
6.29.5.1.12
Specify
Accept
header
in
request
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:
Use
the
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:
Use the
accept
element:
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.
Use
the
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.
Use the
requestHeader
element
to
set
"Accept"
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
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.
"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
6.29.5.1.13
Specify
Content-Type
header
in
request
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:
Use
the
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:
Use the
contentType
element:
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.
Use
the
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.
Use the
requestHeader
element
to
set
Content-Type
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
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.
"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
6.29.5.1.14
Verify
Content-Type
header
in
response
Verify Content-Type header in response There
are
two
ways
to
verify
the
"Content-Type"
header
in
response:
Use
the
There are two ways to verify the "Content-Type" header in response:
Use the
contentType
element:
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.
Use
the
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.
Use the
requestHeader
element
to
verify
Content-Type
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
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.
"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
6.29.5.1.15
Use
variables
Use variables
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.
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.
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.
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}&${PatientFamilyName}&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.
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}&family=${PatientFamilyName}&birthdate=${PatientDOB}"/> <responseId value="R3"/> </operation> </action> Here
are
the
assertions
that
verify
that
the
search
was
successful:
Here are the assertions that verify that the search was successful:
6.24.5.1.16
6.29.5.1.16
Test
server
support
for
'_format'
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
Servers are required to support "_format" in the request url to determine the response mime-type. See
Content Type and Encodings
Use
the
Use the
params
element
to
specify
the
_format:
element to specify the _format:
<action> <operation> <type value="search"/> <resource value="Patient"/> <params value="?family=Doe&given=Joe&_format=application/json+fhir"/> <responseId value="R1"/> </operation> </action> Use
the
Use the
requestHeader
element
to
verify
Content-Type
element to verify Content-Type
explicitly
:
6.24.5.1.17
6.29.5.1.17
How
to
specify
metadata
capabilities
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:
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:
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
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.
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
6.29.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
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
The
params
element
can
be
used
to
specify
the
[id]
using
variable
substitutions
and
the
rest
of
the
highlighted
portion
in
the
request
URL:
element can be used to specify the [id] using variable substitutions and the rest of the highlighted portion in the request URL:
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:
element can be used to specify the [id] and [vid] using variable substitutions and the rest of the highlighted portion in the request URL:
The
params
element
can
be
used
to
specify
the
highlighted
portion
in
the
request
URL:
element can be used to specify the highlighted portion in the request URL:
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:
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]}
The
params
element
can
be
used
in
conditional
update
operation
to
specify
the
highlighted
portion
of
the
request
URL:
element can be used in
conditional update
operation to specify the highlighted portion of the request URL:
The
params
element
can
be
used
to
specify
the
highlighted
portion
in
the
request
URL:
element can be used to specify the highlighted portion in the request URL:
The
params
element
can
be
used
to
specify
the
[id]
using
variable
substitutions
in
the
request
URL:
element can be used to specify the [id] using variable substitutions in the request URL:
If
targetId
is
specified,
then
[type]
for
request
URL
will
be
determined
from
targetId's
fixture
and
resource
element
will
be
ignored.
Otherwise,
is specified, then [type] for request URL will be determined from targetId's fixture and
resource
type
will
be
extracted
from
element will be ignored. Otherwise, resource type will be extracted from
sourceId
's
fixture
if
specified.
For
conditional
updates
,
's fixture if specified. For
conditional updates
,
resource
is
required.
is required.
The
sourceId
element
points
to
a
fixture
to
be
used
for
the
created
resource.
The
fixture
cannot
contain
the
id
element.
The
element points to a fixture to be used for the created resource. The fixture cannot contain the id element.
Fixture to be used for the transaction. Has to be a
Bundle
.
N/A
N/A
targetId
The
The
targetId
element
can
be
used
to
specify
the
[type]
and
[id]
in
the
request
URL.
element can be used to specify the [type] and [id] in the request URL.
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
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.
element can be used to specify the [type], [id], and [vid] in the request URL.
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
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
element cannot be used as it's not allowed with
params
element
The
element
The
targetId
element
can
be
used
to
specify
the
[type],
[id],
and
[vid]
in
the
request
URL.
element can be used to specify the [type], [id], and [vid] in the request URL.
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
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
N/A. The [type] for the request URL will be extracted from
sourceId
.
N/A.
N/A.
The
The
targetId
element
can
be
used
to
specify
the
[type]
and
[id]
in
the
request
URL.
element can be used to specify the [type] and [id] in the request URL.
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 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
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
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
to evaluate
path
(XPath/JSONPath)
and
(XPath/JSONPath) and
headerFields
against
the
response
received
for
an
operation.
against the response received for an operation.
N/A
accept
The
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.
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
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.
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.
Conditional Create using "If-None-Exist". See
Conditional Create
.
Invalid
"Content-Type"
header
for
negative
testing.
Invalid "Content-Type" header for negative testing.
etc.
destination
If
the
TestScript
is
testing
more
than
one
FHIR
server
simultaneously,
the
If the TestScript is testing more than one FHIR server simultaneously, the
destination
identifies
which
server
the
operation
applies
to
using
zero-based
indexing.
identifies which server the operation applies to using zero-based indexing.
url
The
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
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
6.29.7
Assertions
Assertion
Valid
operator
values
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
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.
element depending on the operator used.
headerField
equals
|
notEquals
|
in
|
notIn
|
greaterThan
|
lessThan
|
empty
|
notEmpty
|
contains
|
notContains
Asserts
that
the
header
specified
for
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
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.
element if present.
If
the
If the
operator
is
"empty"
or
"notEmpty"
then
is "empty" or "notEmpty" then
value
will
be
ignored.
will be ignored.
If
If
sourceId
is
not
specified,
then
is not specified, then
headerField
will
be
evaluated
against
the
last
operation's
response
headers.
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
Asserts that the response contains all the element/content in another fixture pointed to by
minimumId
element.
This
can
be
a
statically
defined
element. This can be a statically defined
fixture
or
one
that
is
dynamically
set
via
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
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.
element is set to true or false.
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
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.
element if present.
If
the
If the
operator
is
"empty"
or
"notEmpty"
then
is "empty" or "notEmpty" then
value
will
be
ignored.
will be ignored.
If
If
sourceId
is
not
specified,
then
is not specified, then
path
will
be
evaluated
against
the
last
operation's
response
body.
will be evaluated against the last operation's response body.
compareToSourcePath
equals
|
notEquals
Asserts
that
resource
returned
in
the
response
body
is
or
is
not
of
the
specified
value
for
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
element.
response
abbreviations
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
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
element
validateProfileId
N/A
Asserts
that
the
response
is
valid
according
to
the
profile
specified
by
Asserts that the response is valid according to the profile specified by
validateProfileId
element.
element.
6.24.8
Search
Parameters
6.29.8
Search Parameters Search
parameters
for
this
resource.
The
common
parameters
also
apply.
See
TestScript
url
identifier
contact
conformance
metadata
<!-- 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 -->
