This page is part of the FHIR Specification v6.0.0-ballot1: Release 6 Ballot (1st Draft) (see Ballot Notes). The current version is 5.0.0. For a full list of available versions, see the Directory of published versions
FHIR Infrastructure Work Group | Maturity Level: N/A | Standards Status: Informative | Compartments: No defined compartments |
This is the narrative for the resource. See also the XML, JSON or Turtle format.
Note that this is the formal definition for the implements operation as an OperationDefinition on CapabilityStatement. See the Operation documentation
URL: [base]/CapabilityStatement/$implements
URL: [base]/CapabilityStatement/[id]/$implements
Parameters
Use | Name | Scope | Cardinality | Type | Binding | Documentation |
IN | server | 0..1 | canonical | A canonical reference to the server capability statement - use this if the implements is not invoked on an instance (or on the /metadata end-point) | ||
IN | client | 0..1 | canonical | A canonical reference to the client capability statement - use this if the implements is not invoked on an instance (or on the /metadata end-point) | ||
IN | resource | 0..1 | CapabilityStatement | The client capability statement, provided inline | ||
OUT | return | 1..1 | OperationOutcome | Outcome of the CapabilityStatement test |
The operation does not perform a full conformance check; in particular it does not check that the profiles align. It merely checks that the behaviors the client wishes to use are provided Technically, this operation is implemented as follows:
If the capability statements match by these rules, then the return value is a 200 OK with an operation outcome that contains no issues with severity >= error. If the capability statement doesn't match, the return value is a 4xx error, with an OperationOutcome with at least one issue with severity >= error
Usage note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of the specification.