FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

5.5 Resource OperationDefinition - Content

FHIR Infrastructure icon Work GroupMaturity Level: N Normative (from v4.0.0)Security Category: Anonymous Compartments: No defined compartments

A formal computable definition of an operation (on the RESTful interface) or a named query (using the search interaction).

5.5.1 Scope and Usage

The OperationDefinition resource provides a formal computable definition of an operation or a named query. The OperationDefinition serves two principal purposes:

  • To allow for automatic determination of system compatibility
  • To allow for dynamic generation of forms to drive the operations

See below for further information about these, and about how operations and named queries are executed.

5.5.2 Boundaries and Relationships

OperationDefinitions are published to define operations that servers can implement in a common fashion. The FHIR specification itself describes some (see below), and other organizations (including IHE, national programs, jurisdictions and vendors) are able to publish additional OperationDefinitions.

OperationDefinition resources are referred to from two different places:

  • From a CapabilityStatement, to declare what operations a system does or should implement
  • From another OperationDefinition resource. This allows for a server to describe a limited implementation of a standard operation, or to allow traceability if the server has to rename the operation due to a name clash

OperationDefinitions can be used to define a custom query (kind = query, discussed below) which functions as a special kind of search. This is different to a SearchParameter because a custom query may define multiple parameters and can define of complex search behavior beyond what SearchParameter can specify. It also typically overrides the behavior of the query functionality, while search parameters can only act as additional filters.

5.5.3 References to this Resource

5.5.4 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. OperationDefinition N DomainResource Definition of an operation or a named query
+ Warning: Name should be usable as an identifier for the module by machine processing applications such as code generation
+ Rule: A query operation cannot be defined at the instance level
+ Rule: A query operation requires input parameters to have a search type
+ Rule: Named queries always have a single output parameter named 'result' of type Bundle

Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
Interfaces Implemented: CanonicalResource
... url ΣC 0..1 uri Canonical identifier for this operation definition, represented as an absolute URI (globally unique)
+ Warning: URL should not contain | or # - these characters make processing canonical references problematic
... identifier ΣTU 0..* Identifier Additional identifier for the implementation guide (business identifier)

... version Σ 0..1 string Business version of the operation definition
... versionAlgorithm[x] ΣTU 0..1 How to compare versions
Binding: Version Algorithm (Extensible)
.... versionAlgorithmString string
.... versionAlgorithmCoding Coding
... name ΣC 1..1 string Name for this operation definition (computer friendly)
... title ΣT 0..1 string Name for this operation definition (human friendly)
... status ?!Σ 1..1 code draft | active | retired | unknown
Binding: PublicationStatus (Required)
... kind ΣC 1..1 code operation | query
Binding: Operation Kind (Required)
... experimental Σ 0..1 boolean For testing only - never for real usage
... date Σ 0..1 dateTime Date last changed
... publisher ΣT 0..1 string Name of the publisher/steward (organization or individual)
... contact Σ 0..* ContactDetail Contact details for the publisher

... description T 0..1 markdown Natural language description of the operation definition
... useContext ΣTU 0..* UsageContext The context that the content is intended to support

... jurisdiction ΣXD 0..* CodeableConcept Intended jurisdiction for operation definition (if applicable)
Binding: Jurisdiction ValueSet (Extensible)

... purpose T 0..1 markdown Why this operation definition is defined
... copyright TTU 0..1 markdown Use and/or publishing restrictions
... copyrightLabel TTU 0..1 string Copyright holder and year(s)
... affectsState Σ 0..1 boolean Whether content is changed by the operation
... synchronicity Σ 0..1 code synchronous | asynchronous | either
Binding: Operation Synchronicity Control (Required)
... code Σ 1..1 code Recommended name for operation in search url
... comment 0..1 markdown Additional information about use
... base Σ 0..1 canonical(OperationDefinition) Marks this as a profile of the base
... resource Σ 0..* code Types this operation applies to
Binding: Version Independent Resource Types (All) (Required)
Additional BindingsPurpose
All Resource Types UI Binding


... system Σ 1..1 boolean Invoke at the system level?
... type Σ 1..1 boolean Invoke at the type level?
... instance ΣC 1..1 boolean Invoke on an instance?
... inputProfile 0..1 canonical(StructureDefinition) Validation information for in parameters
... outputProfile 0..1 canonical(StructureDefinition) Validation information for out parameters
... parameter C 0..* BackboneElement Parameters for the operation/query
+ Rule: Either a type must be provided, or parts
+ Rule: A search type can only be specified for parameters of type string
+ Rule: A targetProfile can only be specified for parameters of type Reference, Canonical, or a Resource
+ Rule: SearchParamType can only be specified on in parameters
+ Rule: Min <= Max

.... name C 1..1 code Name in Parameters.parameter.name or in URL
.... use C 1..1 code in | out
Binding: Operation Parameter Use (Required)
.... scope TU 0..* code instance | type | system
Binding: Operation Parameter Scope (Required)

.... min 1..1 unsignedInt Minimum Cardinality
.... max C 1..1 string Maximum Cardinality (a number or *)
+ Rule: Max SHALL be a number or "*"
.... documentation T 0..1 markdown Description of meaning/use
.... type C 0..1 code What type this parameter has
Binding: All FHIR Types (Required)
.... allowedType TU 0..* code Allowed sub-type this parameter can have (if type is abstract)
Binding: All FHIR Types (Required)

.... targetProfile C 0..* canonical(StructureDefinition) If type is Reference | canonical, allowed targets. If type is 'Resource', then this constrains the allowed resource types

.... searchType C 0..1 code number | date | string | token | reference | composite | quantity | uri | special
Binding: SearchParamType (Required)
.... binding 0..1 BackboneElement ValueSet details if this is coded
..... strength 1..1 code required | extensible | preferred | example | descriptive
Binding: BindingStrength (Required)
..... valueSet 1..1 canonical(ValueSet) Source of value set
.... referencedFrom TU 0..* BackboneElement References to this parameter

..... source 1..1 string Referencing parameter
..... sourceId 0..1 string Element id of reference
.... part C 0..* see parameter Parts of a nested Parameter

... overload 0..* BackboneElement Define overloaded variants for when generating code

.... parameterName 0..* string Name of parameter to include in overload

.... comment 0..1 string Comments to go on overload

doco Documentation for this format icon

See the Extensions for this resource

 

Additional definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) , the spreadsheet version & the dependency analysis

5.5.4.1 Terminology Bindings

Path ValueSet Type Documentation
OperationDefinition.versionAlgorithm[x] VersionAlgorithm Extensible

Indicates the mechanism used to compare versions to determine which is more current.
OperationDefinition.status PublicationStatus Required

The lifecycle status of an artifact.
OperationDefinition.kind OperationKind Required

Whether an operation is a normal operation or a query.
OperationDefinition.jurisdiction JurisdictionValueSet Extensible

This value set defines a base set of codes for country, country subdivision and region for indicating where a resource is intended to be used.

Note: The codes for countries and country subdivisions are taken from ISO 3166 icon while the codes for "supra-national" regions are from UN Standard country or area codes for statistical use (M49) icon.
OperationDefinition.synchronicity OperationSynchronicityControl Required

Indicates that an operation must always be handled as synchronous or asynchronous, or that the server must provide both, and clients can choose
OperationDefinition.resource VersionIndependentResourceTypesAll Required

Current and past FHIR resource types (deleted or renamed), including abstract types
  All Resource Types ui
OperationDefinition.parameter.use OperationParameterUse Required

Whether an operation parameter is an input or an output parameter.
OperationDefinition.parameter.scope OperationParameterScope (a valid code from Operation Parameter Use) Required

Indicates that a parameter applies when the operation is being invoked at the specified level
OperationDefinition.parameter.type FHIRTypes (a valid code from All FHIR Types) Required

All FHIR types
OperationDefinition.parameter.allowedType FHIRTypes (a valid code from All FHIR Types) Required

All FHIR types
OperationDefinition.parameter.searchType SearchParamType Required

Data types allowed to be used for search parameters.
OperationDefinition.parameter.binding.strength BindingStrength Required

Indication of the degree of conformance expectations associated with a binding.

5.5.4.2 Constraints

UniqueKeyLevelLocationDescriptionExpression
img cnl-0Warning (base)Name should be usable as an identifier for the module by machine processing applications such as code generationname.exists() implies name.matches('^[A-Z]([A-Za-z0-9_]){1,254}$')
img cnl-1Warning OperationDefinition.urlURL should not contain | or # - these characters make processing canonical references problematicexists() implies matches('^[^|# ]+$')
img opd-1Rule OperationDefinition.parameterEither a type must be provided, or partstype.exists() or part.exists()
img opd-2Rule OperationDefinition.parameterA search type can only be specified for parameters of type stringsearchType.exists() implies type = 'string'
img opd-3Rule OperationDefinition.parameterA targetProfile can only be specified for parameters of type Reference, Canonical, or a ResourcetargetProfile.exists() implies (type = 'Reference' or type = 'canonical' or type.memberOf('http://hl7.org/fhir/ValueSet/all-resource-types'))
img opd-4Rule OperationDefinition.parameterSearchParamType can only be specified on in parameters(use = 'out') implies searchType.empty()
img opd-5Rule (base)A query operation cannot be defined at the instance level(kind = 'query') implies (instance = false)
img opd-6Rule (base)A query operation requires input parameters to have a search type(kind = 'query') implies (parameter.all((use = 'in' and searchType.exists()) or (use != 'in')))
img opd-7Rule (base)Named queries always have a single output parameter named 'result' of type Bundle(kind = 'query') implies ((parameter.where(use = 'out').count() = 1) and (parameter.where(use = 'out').all(name = 'result' and type = 'Bundle')))
img opd-8Rule OperationDefinition.parameterMin <= Max(max = '*') or iif(max != '*', min <= max.toInteger())
img opd-9Rule OperationDefinition.parameter.maxMax SHALL be a number or "*"empty() or ($this = '*') or (toInteger() >= 0)

5.5.4.3 Derived OperationDefinitions

OperationDefinitions can describe entirely new operations, but they can also describe a restricted implementation of an existing operation e.g. when a server implements some but not all the features of an operation defined in another specification. These are called derived operation definitions.

An OperationDefinition does by declaring a base as shown in the example: 

{
  "resourceType" : "OperationDefinition",
  "id" : "example",
  "url" : "http://hl7.org/fhir/OperationDefinition/example",
  "name" : "PopulateQuestionnaire",
  // snip
  "code" : "populate",
  "base" : "http://hl7.org/fhir/OperationDefinition/Questionnaire-populate"
  // snip
}

When constraining an existing operation like this, operation definitions can make optional parameters required or not used, introduce new parameters (required or optional), clarify documentation, and even change the code for the operation (see next section). The derived operation can't change the nature of the operation itself, nor can it change add types to parameters or prohibit mandatory parameters.

5.5.4.4 OperationDefinition Code

Operations are invoked by their code, not their name. The name is descriptive, for code generation, e.g. ValueSetExpansion, while the code is what is used in a URL e.g. http://example.org/fhir/ValueSet/$expand. When defining operations, for maximum compatibility, use only lowercase ASCII characters. See Naming Rules & Guidelines icon for the internal HL7 rules around codes, which are useful additional advice for all implementers.

It is possible for two different organizations to create different operation definitions with the same code or, perhaps more likely, to define equivalent operations that have the same code but incompatible approaches in their parameter lists. Note that HL7 will never define multiple operations with the same code.

It is also possible, though unlikely, that a server will be required to support both of these operations. If this is the case, the server is able to do this by giving one of them a new code and referring to it by definition in the capability statement. To illustrate this, assume that two different organizations, "orgA" and "orgB", both define an operation with a code dothis, and the definitions are incompatible. OrgA publishes its operation definition at http://orga.com/fhir/dothis.xml, and OrgB publishes its operation at http://fhir.orgb.com/meta/OperationDefinition/dothis. The server is able to implement both. Its capability statement will say: 

<CapabilityStatement xmlns="http://hl7.org/fhir">
  <!-- snip -->
  <rest>
    <!-- snip -->
    <operation>
      <name value="dothis"/>
      <definition>
        <reference value="http://orga.com/fhir/dothis.xml"/>
      </definition>
    </operation>
    <operation>
      <name value="dothis2"/>
      <definition>
        <reference value="http://fhir.orgb.com/meta/OperationDefinition/dothis"/>
      </definition>
    </operation>
    <!-- snip -->
  </rest>
  <!-- snip -->
</CapabilityStatement>

If a general purpose cross server client is looking for the implementation of the http://fhir.orgb.com/meta/OperationDefinition/dothis operation and wants to be robust against this name clash problem, instead of simply executing the $dothis operation, it can look at the server's CapabilityStatement for the underlying definition URI and then execute with the name given in the capability statement.

Note to implementers: it would be more consistent if CapabilityStatement.rest.operation.name was actually called "code", since it relates to OperationDefinition.code, but the confusion this can cause wasn't appreciated until the resource was normative.

5.5.4.5 Describing Operation Parameters

There are 2 ways to describe the input and output parameters for an operation:

  • Using OperationDefinition.parameter to describe the parameters
  • Using OperationDefinition.inputProfile and OperationDefinition.outputProfile

The parameters is a simple list of possible parameters, along with cardinalities and types. The profiles allow a rich set of validation rules etc. to be provided. OperationDefinitions SHALL always define the parameters using OperationDefinition.parameter in the resource, and MAY also provide profiles for the parameters. If present, the profiles SHALL NOT disagree with the parameters defined for the operation.

As an example, consider an operation that defines 3 parameters, 2 in and 1 out:

In Parameters:
Name Cardinality Type Binding Profile Documentation
a 0..1 integer

An integer parameter

b 0..1 Patient

A patient parameter

Out Parameters:
Name Cardinality Type Binding Profile Documentation
c 1..1 decimal

A result parameter

In addition to specifying the operation parameters directly, an operation definition can also provide a profile: 

 "inputProfile" : "http://example.org/StructureDefinition/op.x.in.profile"

This profile would describe a parameters resource with 2 parameters (using slicing), with the same details as the table above. The operation definition would still list the parameters directly to save applications consuming the definition (e.g. to produce an OpenAPI document icon) from parsing and interpreting the profile.

5.5.4.6 Executing Operations

OperationDefinitions with kind = operation are executed as defined in the Operations Framework.

5.5.4.7 Executing Named Queries

Named queries (OperationDefinitions with kind = query) are executed by performing a search with the value of the search parameter "_query" set to the name provided in the definition. Named queries are a kind of search: both client and server must conform to all the requirements of search, including regarding the content of the result bundle. From a client's perspective, it's really just a kind of search, though it may have a completely separate processing pipeline. Named queries cannot be invoked using the $[operationname] mechanism.

If the named query is to be performed over the RESTful API, all the parameters must be simple search parameters, so that they can be represented directly in the URL without tricky encoding issues. Named queries always have a single output parameter named "result" of type Bundle.

The order of parameters doesn't matter; a _query parameter anywhere in the query means the entire query will be handled according to the named query OperationDefinition. Parameters may repeat if permitted by the OperationDefinition (or for unlisted common search parameters, as specified in this specification).

For named queries, all the standard search parameters are automatically in scope. Specifically, all common search parameters (e.g. _id, _text, _count, _sort, etc.) as well as search parameters that pertain to the resources returned by the operation (e.g. name for Patient or Organization) are allowed. "In scope" doesn't mean all servers will support them. If a server wishes to declare which search parameters it supports for a given named query, it must explicitly list these in its OperationDefinition (which might be a server-specific derived OperationDefinition).

5.5.4.8 Passing Resources to Operations

There are two ways to pass resources to an operation: directly or by reference. The definition of an operation distinguishes between these two, since they have very different behaviors and consequences.

As an example, take the ValueSet.$expand operation. This operation takes a valueset as a direct parameter. The type of the parameter is defined as 'ValueSet'. In a Parameters resource, it would be represented like this: 

  <parameter>
    <name value="valueset"/>
    <resource>
      <ValueSet>
        <!-- ValueSet contents -->
      </ValueSet>
    </resource>
  </parameter>

or, in JSON: 

 "parameter": [
    {
      "name": "valueset",
      "resource": {
        "resourceType": "ValueSet",
        // ValueSet contents 
      }
    }
  ]

Other parameters are passed by reference. For example, the ChargeItemDefinition.$apply operation takes two parameters of type Reference - one to the chargeItem and the other to the account. The type of the parameters is Reference(Charge) and Reference(Account), respectively. The expectation is that the server performing the operation will resolve those references as part of the operation execution. In a parameters resource, the chargeItem parameter would be represented like this: 

  <parameter>
    <name value="chargeItem"/>
    <valueReference>
      <reference value="ChargeItem/123"/>
    </valueReference>
  </parameter>

or, in JSON: 

 "parameter": [
    {
      "name": "chargeItem",
      "valueReference" : {
        "reference" : "ChargeItem/123"
      }
    }
  ]

Some operations can take either form; in that case, two distinct parameters must be defined: one for a resource as a direct parameter, and one for a reference.

5.5.4.9 Determining System Compatibility

A client can determine the compatibility of the server by processing its capability statement and ensuring that the server implements the specific operation definitions and parameters required by the client. The client can then report a useful error to the user rather than allowing mystifying operational errors to occur.

However, there are fundamental limitations to this approach because there are many aspects of these operations that are not (or cannot be) defined in a formal fashion using OperationDefinition, for example, co-occurrence constraints among parameters.

In the same sense, a 3rd party tool can examine a server's CapabilityStatement and a client's definition of an acceptable server to determine whether those two system are interoperable or not.

5.5.4.10 Dynamically Generating Forms

Finally, it is possible to generate user interface forms automatically from the OperationDefinition. The documentation in the OperationDefinition.description and OperationDefinition.parameter.documentation should be sufficient to allow moderately technical users to guess at the correct content of the form. For this reason, highly technical documentation should go in OperationDefinition.comment.

It is anticipated that this would be used to automate development processes, rather than to generate end-user forms: such users will usually need more support than can be offered in a generated form.

5.5.4.11 Operations defined as part of this Specification

Base Operations (All resource types)
Validate a resource [base]/$validate | [base]/[Resource]/$validate | [base]/[Resource]/[id]/$validate
Access a list of profiles, tags, and security labels [base]/$meta | [base]/[Resource]/$meta | [base]/[Resource]/[id]/$meta
Add profiles, tags, and security labels to a resource [base]/[Resource]/[id]/$meta-add
Delete profiles, tags, and security labels for a resource [base]/[Resource]/[id]/$meta-delete
Convert from one form to another [base]/$convert
Execute a graphql statement [base]/$graphql | [base]/[Resource]/[id]/$graphql
Return a graph of resources [base]/[Resource]/[id]/$graph
Add to an array in a large resource [base]/[Resource]/[id]/$add
Remove from an array in a large resource [base]/[Resource]/[id]/$remove
Filter an array in a large resource [base]/[Resource]/[id]/$filter
Fetch the current version of a canonical resource (based on canonical versioning) [base]/$current-canonical | [base]/[CanonicalResource]/$current-canonical
Operations Defined by Resource Types
Apply [base]/ActivityDefinition/$apply | [base]/ActivityDefinition/[id]/$apply
Data Requirements [base]/ActivityDefinition/[id]/$data-requirements
Fetch a subset of the CapabilityStatement resource [base]/CapabilityStatement/$subset | [base]/CapabilityStatement/[id]/$subset
Test if a server implements a client's required operations [base]/CapabilityStatement/$implements | [base]/CapabilityStatement/[id]/$implements
Test if a server implements a client's required operations [base]/CapabilityStatement/$conforms
Discover what versions a server supports [base]/$versions
Apply [base]/ChargeItemDefinition/[id]/$apply
Submit a Claim resource for adjudication [base]/Claim/$submit
Concept Look Up & Decomposition [base]/CodeSystem/$lookup | [base]/CodeSystem/[id]/$lookup
Code System based Validation [base]/CodeSystem/$validate-code | [base]/CodeSystem/[id]/$validate-code
Subsumption Testing [base]/CodeSystem/$subsumes | [base]/CodeSystem/[id]/$subsumes
Finding codes based on supplied properties [base]/CodeSystem/$find-matches | [base]/CodeSystem/[id]/$find-matches
Generate a Document [base]/Composition/[id]/$document
Concept Translation [base]/ConceptMap/$translate | [base]/ConceptMap/[id]/$translate
Closure Table Maintenance [base]/$closure
Submit an EligibilityRequest resource for assessment [base]/CoverageEligibilityRequest/$submit
Generate a DocumentReference from a document [base]/DocumentReference/$generate
Fetch DocumentReference [base]/DocumentReference/$docref
Fetch Encounter Record [base]/Encounter/[id]/$everything
Fetch EpisodeOfCare Record [base]/EpisodeOfCare/[id]/$everything
Fetch a group of Patient Records [base]/Group/[id]/$everything
Purge Group Record [base]/Group/[id]/$purge
Data Requirements [base]/$data-requirements | [base]/Library/[id]/$data-requirements
Find a functional list [base]/List/$find
Evaluate Measure [base]/Measure/$evaluate-measure | [base]/Measure/[id]/$evaluate-measure
Data Requirements [base]/Measure/[id]/$data-requirements
Submit Data [base]/Measure/$submit-data | [base]/Measure/[id]/$submit-data
Collect Data [base]/Measure/$collect-data | [base]/Measure/[id]/$collect-data
Care Gaps [base]/Measure/$care-gaps
Fetch Product Record [base]/MedicinalProductDefinition/$everything | [base]/MedicinalProductDefinition/[id]/$everything
Process Message [base]/$process-message
Fetch Preferred id [base]/NamingSystem/$preferred-id
Translate id [base]/NamingSystem/$translate-id
Observation Statistics [base]/Observation/$stats
Last N Observations Query [base]/Observation/$lastn
Find patient matches using MPI based logic [base]/Patient/$match
Fetch Patient Record [base]/Patient/$everything | [base]/Patient/[id]/$everything
Patient Merge [base]/Patient/$merge
Purge Patient Record [base]/Patient/[id]/$purge
Apply [base]/PlanDefinition/$apply | [base]/PlanDefinition/[id]/$apply
Data Requirements [base]/PlanDefinition/[id]/$data-requirements
Apply [base]/SpecimenDefinition/$apply | [base]/SpecimenDefinition/[id]/$apply
Build Questionnaire [base]/StructureDefinition/$questionnaire | [base]/StructureDefinition/[id]/$questionnaire
Generate Snapshot [base]/StructureDefinition/$snapshot | [base]/StructureDefinition/[id]/$snapshot
Model Instance Transformation [base]/StructureMap/$transform | [base]/StructureMap/[id]/$transform
Search and retrieve prior events for a Subscription [base]/Subscription/[id]/$events
Get Current Subscription Status for One or More Subscriptions [base]/Subscription/$status | [base]/Subscription/[id]/$status
Get a binding token for use in a websocket connection [base]/Subscription/$get-ws-binding-token | [base]/Subscription/[id]/$get-ws-binding-token
Value Set Expansion [base]/ValueSet/$expand | [base]/ValueSet/[id]/$expand
Value Set based Validation [base]/ValueSet/$validate-code | [base]/ValueSet/[id]/$validate-code

5.5.5 Search Parameters

Search parameters for this resource. See also the full list of search parameters for this resource, and check the Extensions registry for search parameters on extensions related to this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name Type Description Expression In Common
base reference Marks this as a profile of the base OperationDefinition.base
(OperationDefinition)
code token Name used to invoke the operation OperationDefinition.code
context token A use context assigned to the operation definition (OperationDefinition.useContext.value.ofType(CodeableConcept)) 30 Resources
context-quantity quantity A quantity- or range-valued use context assigned to the operation definition (OperationDefinition.useContext.value.ofType(Quantity)) | (OperationDefinition.useContext.value.ofType(Range)) 30 Resources
context-type TU token A type of use context assigned to the operation definition OperationDefinition.useContext.code 30 Resources
context-type-quantity TU composite A use context type and quantity- or range-based value assigned to the operation definition On OperationDefinition.useContext:
  context-type: code
  context-quantity: value.ofType(Quantity) | value.ofType(Range)		 30 Resources
context-type-value TU composite A use context type and value assigned to the operation definition On OperationDefinition.useContext:
  context-type: code
  context: value.ofType(CodeableConcept)		 30 Resources
date date The operation definition publication date OperationDefinition.date 31 Resources
description string The description of the operation definition OperationDefinition.description 29 Resources
identifier token External identifier for the search parameter OperationDefinition.identifier 35 Resources
input-profile reference Validation information for in parameters OperationDefinition.inputProfile
(StructureDefinition)
instance token Invoke on an instance? OperationDefinition.instance
jurisdiction token Intended jurisdiction for the operation definition OperationDefinition.jurisdiction 27 Resources
kind token operation | query OperationDefinition.kind
name string Computationally friendly name of the operation definition OperationDefinition.name 28 Resources
output-profile reference Validation information for out parameters OperationDefinition.outputProfile
(StructureDefinition)
publisher string Name of the publisher of the operation definition OperationDefinition.publisher 31 Resources
status token The current status of the operation definition OperationDefinition.status 35 Resources
system token Invoke at the system level? OperationDefinition.system
title string The human-friendly name of the operation definition OperationDefinition.title 28 Resources
type token Invoke at the type level? OperationDefinition.type
url uri The uri that identifies the operation definition OperationDefinition.url 34 Resources
version token The business version of the operation definition OperationDefinition.version 32 Resources