Release 4B Snapshot 3: Connectathon 32 Base

This page is part of the Snapshot #3 for FHIR Specification (v4.3.0: R4B - STU ). The current version which supercedes this version is 5.0.0 R5 , released to support Connectathon 32 . For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3

Operation-capabilitystatement-implements

Example OperationDefinition/CapabilityStatement-implements (Narrative)

FHIR Infrastructure Work Group Maturity Level : N/A Standards Status : Informative Compartments : Not linked to any defined compartments

This is the narrative for the resource. See also the XML , JSON or Turtle format.

Implements OPERATION: Implements The official URL for

Note that this operation is the formal definition is: http://hl7.org/fhir/OperationDefinition/CapabilityStatement-implements This operation asks for the server to check that it implements all the resources, interactions, search parameters, and operations that the client provides in its capability statement. The client provides its capability statement inline, or by referring the server to operation as an OperationDefinition on CapabilityStatement. See the canonical URL of its capability statement Operation documentation

URL: [base]/CapabilityStatement/$implements

URL: [base]/CapabilityStatement/[id]/$implements

Parameters

Use Name 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:

  • The server's capability statement must have an entry for each resource in the client's capability statement
  • The server's resource support must have matching flags for updateCreate, conditionalCreate, conditionalRead, conditionalUpdate, conditionalPatch, conditionalDelete, searchInclude, searchRevInclude
  • The server's capability statement must have a matching interaction for each interaction in the client capability statement (whether or not it is on a resource)
  • The server's capability statement must have a search parameter with matching name and definition for any search parameters in the client capability statement
  • The server must have an operation definition with a matching reference for any operations in the client capability statement

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.