This page is part of the FHIR Specification (v0.4.0: DSTU 2 Draft). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2
This resource maintained by the FHIR Management Group Work Group
A formal computable definition of an operation (on the RESTful interface) or a named query (using the search interaction).
The OperationDefinition resource provides a formal computable definition of an operation or a named query. The OperationDefinition serves two principle purposes:
See below for further information about these, and about how Operations and Named Queries are executed.
Operation Definitions are published to define operations that servers can implemnet in a common fashion. The FHIR specification itself describes a number (see below), and other organizations, including IHE, national programs, jurisdictions and vendors are able to publish additional operation definitions.
OperationDefinition resources are referred to from two different places:
This resource is referenced by [Conformance]
Structure
Name | Flags | Card. | Type | Description & Constraints |
---|---|---|---|---|
OperationDefinition | DomainResource | Definition of an operation or a named query | ||
url | 0..1 | uri | Logical url to reference this operation definition | |
version | 0..1 | string | Logical id for this version of the operation definition | |
name | 1..1 | string | Informal name for this profile | |
publisher | Σ | 0..1 | string | Name of the publisher (Organization or individual) |
contact | Σ | 0..* | Element | Contact details of the publisher |
name | Σ | 0..1 | string | Name of a individual to contact |
telecom | Σ | 0..* | ContactPoint | Contact details for individual or publisher |
description | 0..1 | string | Natural language description of the operation | |
requirements | 0..1 | string | Why is this needed? | |
status | M | 1..1 | code | draft | active | retired ResourceProfileStatus (Required) |
experimental | 0..1 | boolean | If for testing purposes, not real usage | |
date | 0..1 | dateTime | Date for this version of the operation definition | |
kind | 1..1 | code | operation | query OperationKind (Required) | |
code | 1..1 | code | Name used to invoke the operation | |
notes | 0..1 | string | Additional information about use | |
base | 0..1 | OperationDefinition | Marks this as a profile of the base | |
system | 1..1 | boolean | Invoke at the system level? | |
type | 0..* | code | Invoke at resource level for these type ResourceType (Required) | |
instance | 1..1 | boolean | Invoke on an instance? | |
parameter | I | 0..* | Element | Parameters for the operation/query Either a type must be provided, or parts |
name | 1..1 | code | Name of the parameter | |
use | 1..1 | code | in | out OperationParameterUse (Required) | |
min | 1..1 | integer | Minimum Cardinality | |
max | 1..1 | string | Maximum Cardinality (a number or *) | |
documentation | 0..1 | string | Description of meaning/use | |
type | I | 0..1 | code | What type this parameter hs OperationParameterType (Required) |
profile | 0..1 | Profile | Profile on the type | |
part | I | 0..* | Element | Parts of a Tuple Parameter |
name | 1..1 | code | Name of the parameter | |
min | 1..1 | integer | Minimum Cardinality | |
max | 1..1 | string | Maximum Cardinality (a number or *) | |
documentation | 0..1 | string | Description of meaning/use | |
type | 1..1 | code | What type this parameter hs OperationParameterType (Required) | |
profile | 0..1 | Profile | Profile on the type |
UML Diagram
XML Template
<OperationDefinition xmlns="http://hl7.org/fhir"> <!-- from Resource: id, meta, implicitRules, and language --> <!-- from DomainResource: text, contained, extension, and modifierExtension --> <url value="[uri]"/><!-- 0..1 Logical url to reference this operation definition --> <version value="[string]"/><!-- 0..1 Logical id for this version of the operation definition --> <name value="[string]"/><!-- 1..1 Informal name for this profile --> <publisher value="[string]"/><!-- 0..1 Name of the publisher (Organization or individual) --> <contact> <!-- 0..* Contact details of the publisher --> <name value="[string]"/><!-- 0..1 Name of a individual to contact --> <telecom><!-- 0..* ContactPoint Contact details for individual or publisher --></telecom> </contact> <description value="[string]"/><!-- 0..1 Natural language description of the operation --> <requirements value="[string]"/><!-- 0..1 Why is this needed? --> <status value="[code]"/><!-- 1..1 draft | active | retired --> <experimental value="[boolean]"/><!-- 0..1 If for testing purposes, not real usage --> <date value="[dateTime]"/><!-- 0..1 Date for this version of the operation definition --> <kind value="[code]"/><!-- 1..1 operation | query --> <code value="[code]"/><!-- 1..1 Name used to invoke the operation --> <notes value="[string]"/><!-- 0..1 Additional information about use --> <base><!-- 0..1 Reference(OperationDefinition) Marks this as a profile of the base --></base> <system value="[boolean]"/><!-- 1..1 Invoke at the system level? --> <type value="[code]"/><!-- 0..* Invoke at resource level for these type --> <instance value="[boolean]"/><!-- 1..1 Invoke on an instance? --> <parameter> <!-- 0..* Parameters for the operation/query --> <name value="[code]"/><!-- 1..1 Name of the parameter --> <use value="[code]"/><!-- 1..1 in | out --> <min value="[integer]"/><!-- 1..1 Minimum Cardinality --> <max value="[string]"/><!-- 1..1 Maximum Cardinality (a number or *) --> <documentation value="[string]"/><!-- 0..1 Description of meaning/use --> <type value="[code]"/><!-- 0..1 What type this parameter hs --> <profile><!-- 0..1 Reference(Profile) Profile on the type --></profile> <part> <!-- 0..* Parts of a Tuple Parameter --> <name value="[code]"/><!-- 1..1 Name of the parameter --> <min value="[integer]"/><!-- 1..1 Minimum Cardinality --> <max value="[string]"/><!-- 1..1 Maximum Cardinality (a number or *) --> <documentation value="[string]"/><!-- 0..1 Description of meaning/use --> <type value="[code]"/><!-- 1..1 What type this parameter hs --> <profile><!-- 0..1 Reference(Profile) Profile on the type --></profile> </part> </parameter> </OperationDefinition>
JSON Template
{ "resourceType" : "OperationDefinition", // from Resource: id, meta, implicitRules, and language // from DomainResource: text, contained, extension, and modifierExtension "url" : "<uri>", // Logical url to reference this operation definition "version" : "<string>", // Logical id for this version of the operation definition "name" : "<string>", // R! Informal name for this profile "publisher" : "<string>", // Name of the publisher (Organization or individual) "contact" : [{ // Contact details of the publisher "name" : "<string>", // Name of a individual to contact "telecom" : [{ ContactPoint }] // Contact details for individual or publisher }], "description" : "<string>", // Natural language description of the operation "requirements" : "<string>", // Why is this needed? "status" : "<code>", // R! draft | active | retired "experimental" : <boolean>, // If for testing purposes, not real usage "date" : "<dateTime>", // Date for this version of the operation definition "kind" : "<code>", // R! operation | query "code" : "<code>", // R! Name used to invoke the operation "notes" : "<string>", // Additional information about use "base" : { Reference(OperationDefinition) }, // Marks this as a profile of the base "system" : <boolean>, // R! Invoke at the system level? "type" : ["<code>"], // Invoke at resource level for these type "instance" : <boolean>, // R! Invoke on an instance? "parameter" : [{ // Parameters for the operation/query "name" : "<code>", // R! Name of the parameter "use" : "<code>", // R! in | out "min" : <integer>, // R! Minimum Cardinality "max" : "<string>", // R! Maximum Cardinality (a number or *) "documentation" : "<string>", // Description of meaning/use "type" : "<code>", // C? What type this parameter hs "profile" : { Reference(Profile) }, // Profile on the type "part" : [{ // C? Parts of a Tuple Parameter "name" : "<code>", // R! Name of the parameter "min" : <integer>, // R! Minimum Cardinality "max" : "<string>", // R! Maximum Cardinality (a number or *) "documentation" : "<string>", // Description of meaning/use "type" : "<code>", // R! What type this parameter hs "profile" : { Reference(Profile) } // Profile on the type }] }] }
Structure
Name | Flags | Card. | Type | Description & Constraints |
---|---|---|---|---|
OperationDefinition | DomainResource | Definition of an operation or a named query | ||
url | 0..1 | uri | Logical url to reference this operation definition | |
version | 0..1 | string | Logical id for this version of the operation definition | |
name | 1..1 | string | Informal name for this profile | |
publisher | Σ | 0..1 | string | Name of the publisher (Organization or individual) |
contact | Σ | 0..* | Element | Contact details of the publisher |
name | Σ | 0..1 | string | Name of a individual to contact |
telecom | Σ | 0..* | ContactPoint | Contact details for individual or publisher |
description | 0..1 | string | Natural language description of the operation | |
requirements | 0..1 | string | Why is this needed? | |
status | M | 1..1 | code | draft | active | retired ResourceProfileStatus (Required) |
experimental | 0..1 | boolean | If for testing purposes, not real usage | |
date | 0..1 | dateTime | Date for this version of the operation definition | |
kind | 1..1 | code | operation | query OperationKind (Required) | |
code | 1..1 | code | Name used to invoke the operation | |
notes | 0..1 | string | Additional information about use | |
base | 0..1 | OperationDefinition | Marks this as a profile of the base | |
system | 1..1 | boolean | Invoke at the system level? | |
type | 0..* | code | Invoke at resource level for these type ResourceType (Required) | |
instance | 1..1 | boolean | Invoke on an instance? | |
parameter | I | 0..* | Element | Parameters for the operation/query Either a type must be provided, or parts |
name | 1..1 | code | Name of the parameter | |
use | 1..1 | code | in | out OperationParameterUse (Required) | |
min | 1..1 | integer | Minimum Cardinality | |
max | 1..1 | string | Maximum Cardinality (a number or *) | |
documentation | 0..1 | string | Description of meaning/use | |
type | I | 0..1 | code | What type this parameter hs OperationParameterType (Required) |
profile | 0..1 | Profile | Profile on the type | |
part | I | 0..* | Element | Parts of a Tuple Parameter |
name | 1..1 | code | Name of the parameter | |
min | 1..1 | integer | Minimum Cardinality | |
max | 1..1 | string | Maximum Cardinality (a number or *) | |
documentation | 0..1 | string | Description of meaning/use | |
type | 1..1 | code | What type this parameter hs OperationParameterType (Required) | |
profile | 0..1 | Profile | Profile on the type |
XML Template
<OperationDefinition xmlns="http://hl7.org/fhir"> <!-- from Resource: id, meta, implicitRules, and language --> <!-- from DomainResource: text, contained, extension, and modifierExtension --> <url value="[uri]"/><!-- 0..1 Logical url to reference this operation definition --> <version value="[string]"/><!-- 0..1 Logical id for this version of the operation definition --> <name value="[string]"/><!-- 1..1 Informal name for this profile --> <publisher value="[string]"/><!-- 0..1 Name of the publisher (Organization or individual) --> <contact> <!-- 0..* Contact details of the publisher --> <name value="[string]"/><!-- 0..1 Name of a individual to contact --> <telecom><!-- 0..* ContactPoint Contact details for individual or publisher --></telecom> </contact> <description value="[string]"/><!-- 0..1 Natural language description of the operation --> <requirements value="[string]"/><!-- 0..1 Why is this needed? --> <status value="[code]"/><!-- 1..1 draft | active | retired --> <experimental value="[boolean]"/><!-- 0..1 If for testing purposes, not real usage --> <date value="[dateTime]"/><!-- 0..1 Date for this version of the operation definition --> <kind value="[code]"/><!-- 1..1 operation | query --> <code value="[code]"/><!-- 1..1 Name used to invoke the operation --> <notes value="[string]"/><!-- 0..1 Additional information about use --> <base><!-- 0..1 Reference(OperationDefinition) Marks this as a profile of the base --></base> <system value="[boolean]"/><!-- 1..1 Invoke at the system level? --> <type value="[code]"/><!-- 0..* Invoke at resource level for these type --> <instance value="[boolean]"/><!-- 1..1 Invoke on an instance? --> <parameter> <!-- 0..* Parameters for the operation/query --> <name value="[code]"/><!-- 1..1 Name of the parameter --> <use value="[code]"/><!-- 1..1 in | out --> <min value="[integer]"/><!-- 1..1 Minimum Cardinality --> <max value="[string]"/><!-- 1..1 Maximum Cardinality (a number or *) --> <documentation value="[string]"/><!-- 0..1 Description of meaning/use --> <type value="[code]"/><!-- 0..1 What type this parameter hs --> <profile><!-- 0..1 Reference(Profile) Profile on the type --></profile> <part> <!-- 0..* Parts of a Tuple Parameter --> <name value="[code]"/><!-- 1..1 Name of the parameter --> <min value="[integer]"/><!-- 1..1 Minimum Cardinality --> <max value="[string]"/><!-- 1..1 Maximum Cardinality (a number or *) --> <documentation value="[string]"/><!-- 0..1 Description of meaning/use --> <type value="[code]"/><!-- 1..1 What type this parameter hs --> <profile><!-- 0..1 Reference(Profile) Profile on the type --></profile> </part> </parameter> </OperationDefinition>
JSON Template
{ "resourceType" : "OperationDefinition", // from Resource: id, meta, implicitRules, and language // from DomainResource: text, contained, extension, and modifierExtension "url" : "<uri>", // Logical url to reference this operation definition "version" : "<string>", // Logical id for this version of the operation definition "name" : "<string>", // R! Informal name for this profile "publisher" : "<string>", // Name of the publisher (Organization or individual) "contact" : [{ // Contact details of the publisher "name" : "<string>", // Name of a individual to contact "telecom" : [{ ContactPoint }] // Contact details for individual or publisher }], "description" : "<string>", // Natural language description of the operation "requirements" : "<string>", // Why is this needed? "status" : "<code>", // R! draft | active | retired "experimental" : <boolean>, // If for testing purposes, not real usage "date" : "<dateTime>", // Date for this version of the operation definition "kind" : "<code>", // R! operation | query "code" : "<code>", // R! Name used to invoke the operation "notes" : "<string>", // Additional information about use "base" : { Reference(OperationDefinition) }, // Marks this as a profile of the base "system" : <boolean>, // R! Invoke at the system level? "type" : ["<code>"], // Invoke at resource level for these type "instance" : <boolean>, // R! Invoke on an instance? "parameter" : [{ // Parameters for the operation/query "name" : "<code>", // R! Name of the parameter "use" : "<code>", // R! in | out "min" : <integer>, // R! Minimum Cardinality "max" : "<string>", // R! Maximum Cardinality (a number or *) "documentation" : "<string>", // Description of meaning/use "type" : "<code>", // C? What type this parameter hs "profile" : { Reference(Profile) }, // Profile on the type "part" : [{ // C? Parts of a Tuple Parameter "name" : "<code>", // R! Name of the parameter "min" : <integer>, // R! Minimum Cardinality "max" : "<string>", // R! Maximum Cardinality (a number or *) "documentation" : "<string>", // Description of meaning/use "type" : "<code>", // R! What type this parameter hs "profile" : { Reference(Profile) } // Profile on the type }] }] }
Alternate definitions: Schema/Schematron, Resource Profile (XML, JSON), Questionnaire
Path | Definition | Type | Reference |
---|---|---|---|
OperationDefinition.status | The lifecycle status of a Resource Profile | Fixed | http://hl7.org/fhir/resource-profile-status |
OperationDefinition.kind | Whether an operation is a normal operation or a query | Fixed | http://hl7.org/fhir/operation-kind |
OperationDefinition.type | One of the resource types defined as part of FHIR | Fixed | http://hl7.org/fhir/valueset/resource-types |
OperationDefinition.parameter.use | Whether an operation parameter is an input or an output parameter | Fixed | http://hl7.org/fhir/operation-parameter-use |
OperationDefinition.parameter.type OperationDefinition.parameter.part.type | The type of a parameter | Fixed | http://hl7.org/fhir/operation-definition-parameter-type |
Generate a Document | [base]/Composition/$document |
Concept Translation | [base]/ConceptMap/$translate | [base]/ConceptMap/[id]/$translate |
Closure Table Maintenance | [base]/$closure |
Fetch Patient Record | [base]/Patient/$everything | [base]/Patient/[id]/$everything |
Build Questionnaire | [base]/Profile/$questionnaire | [base]/Profile/[id]/$questionnaire |
Populate Questionnaire | [base]/Questionnaire/$populate | [base]/Questionnaire/[id]/$populate |
Build Questionnaire | [base]/StructureDefinition/$questionnaire | [base]/StructureDefinition/[id]/$questionnaire |
Value Set Expansion | [base]/ValueSet/$expand | [base]/ValueSet/[id]/$expand |
Concept Look Up | [base]/ValueSet/$lookup |
Value Set based Validation | [base]/ValueSet/$validate | [base]/ValueSet/[id]/$validate |
Batch Mode Validation | [base]/ValueSet/$batch |
Operations are executed by POSTing to a URL that is defined by the operation definition. Named Queries are executed by performing a search with the value of the search parameter "_query" set to the name provided in the definition.
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 are also limited to a single return parameter "result" (though this may repeat).
It's possible for two different organisations to create different operation definitions that have the same name (or, perhaps more likely, to define equivalent operations that have the same name but incompatible approaches in their parameter lists).
It's also possible (though a little unlikely) that a server will be required to support both of these operations. Should this be the case, the server is able to do this by giving on of them a new name, and then referring to it by definition in the conformance statement. To illustrate this, let's assume that two different organisations (orgA and orgB) both define an operation called "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 conformance statement will say:
<Conformance 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 --> </Conformance>
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 conformance statement for the underlying definition URI, and then execute the name given in the conformance statement.
A client can determine the compatiblity of the server by iterating its conformance statement and seeing whether any of the operations it declares to support source from the same definitions as those the client depends on, and whether the paramters it uses are supported by the server. A client that does this can report a useful error to the user rather than allowing mystifying operational errors to occur.
Note, however, that there are fundamental limitations to this approach because there are many aspects of these operations that aren't (and can't be) defined in a formal fashion. (For example, co-occurrence constraints amongst parameters.)
In the same sense, a 3rd party tool can examine the conformance statements from a server and a client definition of an acceptable server and confirm whether those two system are would be unable to interoperate.
Finally, it is possible to generate user interface forms automatically from the operation definitions. The documentation in the form definition and the parameter documentation should be sufficiently useful to allow moderately technical users to guess at the correct content of the form. For this reason, highly technical documentation should go in OperationDefinition.notes.
Note also this is not expected to a be a tool of use to typical healthcare end-users; such users will usually need more support than can be offered in a generated form.
Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.
Name | Type | Description | Paths |
base | reference | Marks this as a profile of the base | OperationDefinition.base (OperationDefinition) |
code | token | Name used to invoke the operation | OperationDefinition.code |
date | date | Date for this version of the operation definition | OperationDefinition.date |
instance | token | Invoke on an instance? | OperationDefinition.instance |
kind | token | operation | query | OperationDefinition.kind |
name | string | Informal name for this profile | OperationDefinition.name |
profile | reference | Profile on the type | OperationDefinition.parameter.profile (Profile) |
publisher | string | Name of the publisher (Organization or individual) | OperationDefinition.publisher |
status | token | draft | active | retired | OperationDefinition.status |
system | token | Invoke at the system level? | OperationDefinition.system |
type | token | Invoke at resource level for these type | OperationDefinition.type |
url | token | Logical url to reference this operation definition | OperationDefinition.url |
version | token | Logical id for this version of the operation definition | OperationDefinition.version |