Release 5 R6 Ballot (2nd Draft)

This page is part of the FHIR Specification (v5.0.0: R5 - STU v6.0.0-ballot2: Release 6 Ballot (2nd Draft) (see Ballot Notes ). This is the The current published version in it's permanent home (it will always be available at this URL). is 5.0.0 . For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3

Example OperationDefinition/CapabilityStatement-implements (Narrative)

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

Generated Narrative: OperationDefinition CapabilityStatement-implements

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:

  • 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.