DSTU2
<

This page is part of the FHIR Specification (v1.0.2: DSTU 2). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see the Directory of published versions . For a full list of available versions, see the Directory of published versions . Page versions: . Page versions: R5 R4B R4 R3 R2

a name="base">

2.2.0 Extended Operations on the RESTful API

FHIR Infrastructure Work Group Maturity Level : N/A Ballot Status : DSTU 2

The RESTful API defines a set of common interactions (read, update, search, etc.) performed on a repository of typed resources (read, update, search, etc). resources. These interactions follow the RESTful paradigm of managing state by Create/Read/Update/Delete C reate/ R ead/ U pdate/ D elete actions on a set of identified resources. While this approach solves many use cases, there is some specific functionality that can be met more efficiently using an RPC-like paradigm, where named operations are performed with inputs and outputs. outputs ( E xecute). Operations are used (a) where the server needs to play an active role in formulating the content of the response, not merely return existing information, or (b)where the intended purpose is to cause side effects such as the modification of existing resources, or creation of new resources. This specification describes a light lightweight operation framework that seamlessly extends the RESTful API.

Operations have the following general properties:

  • Each operation has a name
  • Each operation has a list of 'in' and 'out' parameters
  • The parameters Parameters are either resources, data types or search parameters
  • The operations Operations are subject to the same security arrangements constraints and requirements as the RESTful API
  • The URIs for the operation end points end-points are based on the existing RESTful API address scheme
  • The operations Operations may make use of the existing repository of resources in their definitions
  • Operations are may be performed against on a specific resource, a resource type, or the a whole system

2.2.0.1 Executing an Operation

Most Operations are a POST to a FHIR endpoint, where the name of the operations is prefixed by a "dollar sign" ('$') character. For example: 


 POST http://fhir.someserver.org/fhir/Patient/1/$everything

When an operation is idempotent, and the parameters are all simple ones (as is the case with the example above), it may be invoked using GET as well.

Operations can be invoked on four types of FHIR endpoints:

  • The "base" FHIR service endpoint (e.g. http://fhir.someserver.org/fhir): These are operations that operate on the full scale of the server. For example, "return me all extensions known by this server"
  • A Resource type (e.g. http://fhir.someserver.org/fhir/Patient): These are operations that operate across all instances of a given resource type
  • A Resource instance (e.g. http://fhir.someserver.org/fhir/Patient/1): These are operations involve only a single instance of a Resource, like the $everything operation above does
  • A specific version of a resource instance (http://fhir.someserver.org/fhir/Patient/1/_history/4): These operations involve only a specific version of a single instance of a FHIR Resource and extists only to allow manipulation of profile and tag metadata of past versions

The body of the invocation contains a special infrastructure resource called Parameters , which represents a collection of named parameters as <key,value> pairs, where the value may be any primitive or complex datatype or even a full Resource. It may also include strings formatted as search parameter types.

Upon completion, the operation returns another Parameters resource, containing one or more output parameters. This means that a FHIR operation can take any parameter in and return a set of result parameters out . Both the body of the POST and the returned result are always a Resource.

Some Operations with simple input types and a single Resource output parameter named ' return ' can be invoked using a GET directly, with parameters as HTTP URL parameters. In this case, the response is simply the resource that is the return value, with no Parameters resource.

2.2.0.2 FHIR defined Operations

This specification defines several operations:

Batch Mode Validation
Base Operations (All resource types)
Validate a resource [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
Operations Defined by Resource Types
Generate a Document [base]/Composition/$document
Concept Translation [base]/ConceptMap/$translate | [base]/ConceptMap/[id]/$translate
Batch Mode Translation Closure Table Maintenance [base]/ConceptMap/$batch [base]/$closure
Closure Table Maintenance Fetch Encounter Record [base]/$closure [base]/Encounter/[id]/$everything
Fetch Encounter Record Find a functional list [base]/Encounter/[id]/$everything [base]/List/$find
Process Message [base]/$process-message
Fetch Patient Record [base]/Patient/$everything | [base]/Patient/[id]/$everything
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-code | [base]/ValueSet/[id]/$validate-code
Operations Defined by Implementation Guides [base]/ValueSet/$batch

Notes:

  • The special operations on the meta element also operate on previous version (/_history/) - they versions of a resource (/_history/). They are the only ones operations that can manipulate versions other than the "current" version.

2.2.0.2 2.2.0.3 Implementations Implementation Defined Operations

Implementations are able to define their own operations in addition to those defined here. Name clashes between operations defined by different implementers can be resolved by the use of the server's conformance Conformance statement .

In addition, Also, the definition of these operations or additional run time operations does not prevent the use of other kinds of operations that are not dependent on and/or not integrated with the RESTful API, as long as provided that their addressing scheme does not clash with the scheme defined herein. here.

2.2.0.3 2.2.0.4 Defining an Operation

Each Operation is defined by:

  • A context for the operation Operation - system, system , resource type, type , or resource instance
  • A name for the operation Operation
  • A list of parameters, parameters along with their definitions

For each parameter, the following information is needed:

  • Name - the name of the operation. parameter. For implementer convenience, the name should be a valid token (see below)
  • Use - In | Out | Both
  • Type - a data type or a resource Resource type
  • Profile - a profile StructureDefinition that applies additional restrictions about the resource
  • Documentation - describes its a description of the parameter's use

There is a special parameter type called "Tuple" which is a parameter type that has additional parts. Each part has the same information as a parameter, except for use, which is taken from the parameter it is part of.

The resource Operation Definition is used to provide a computable definition of the operation. Operation.

2.2.0.4 2.2.0.5 Extending an Operation

Implementations are able to extend operations an operation by defining new named parameters. Implementations can publish their own extended definitions using the Operation Definition resource, and this variant definition can use OperationDefinition.base to refer to the underlying definition.

Note that the FHIR specification will never define any parameter names starting with "x-".

2.2.0.5 2.2.0.6 Executing an Operation Synchronously

Most commonly, operations Operations are typically executed synchronously - the synchronously: a client sends a request to the a server with that includes the operation operation's in parameters, parameters and the server replies with the operation operation' out parameters.

The URL for an operation end-point depends on its context:

  • system: the url URL is [base]/$[name]
  • resource type: the url URL is [base]/[type]/$[name]
  • resource instance: the url URL is [base]/[type]/[id]/$[name]

2.2.0.5.1 2.2.0.6.1 Operation Request

In the general case, an An operation is generally invoked by performing an HTTP POST to the operation operation's end-point. The format of the submitted content is the special Parameters format (the "in" parameters) - a list of named parameters (the "in" parameters). parameters. For an example, see the value set expansion request example .

Note that the same arrangement as for the RESTful interface applies in regard with respect to content types .

If there are no parameters with complex types (including resources) to the operation, and the operation is idempotent (see HTTP specification definition of idempotent ), the operation may be invoked by performing an HTTP GET operation where all of the parameters are appended to the URL in the search portion of the URL (e.g. after the "?"). '?' character). Servers SHALL support this method of invocation.

Servers MAY choose to support submission of the parameters multi-part form multi-part/form-data method as well, which can be useful for allowing when testing of an operation using HTML forms.

2.2.0.5.2 2.2.0.6.2 Operation Response

If the an operation succeeds, the an HTTP Status code is of 200 OK. OK is retruned. An HTTP status code if of 4xx or 5xx indicates an error, and an OperationOutcome may be returned. User agents should note that servers may issue redirects etc redirects, etc. to authenticate the client in response to an operation request.

In the general case, general, an operation response uses the same Parameters format whether there is only one or more there are multiple named parameters (the "out" parameters). out parameters.

If there is only one out parameter, which is a resource, and it has Resource with the parameter name "return" then the parameter format is not used, and the response is simply the resource itself.

The resources that are returned by the operation may be retained and made available in the resource repository on the operation server. In that case, the server will provide the identity of the resource in the returned resources. When resources that are not persisted are returned in the a response, they will have no id property.

2.2.0.6 2.2.0.7 Executing an Operation Asynchronously

Operations can also be executed asynchronously. In this case, the requester sends a message requesting that an operation be executed, and the destination system subsequently sends a message back with the results of the operation. Given the increased complexity of the asynchronous use case, the implementation has increased complexity. As a summary, asynchronous operations are performed like this: The requester contructs a message (a bundle with type = message) The message header has an event.system of http://blame-Lloyd.com/operations The event.code DSTU Note: there is the URL of the operation definition The message data item refers presentlly no mechanism to a Parameters format that carries the execute operations asynchronously in parameters for the operation. If there are no parameters, the message SHOULD have no data element The sender accepts the message (see Asynchronous messaging ) When the operation has been executed, the processor sends back one or more messages Each message is a bundle of type = message that contains a message header that refers to the id of the original message If the operation fails, RESTful manner. However, the MessageHeader.response.code must indicate failure, and an OperationOutcome messaging page SHOULD be returned as well If there is only one out parameter, which is describes a resource, and it has the name "return", then the data of the message is the return resource Else the message data will refer way to a Parameters format that carries the out parameters for the operation. If there are no parameters, the message SHOULD have no data element execute operations asynchronously using messages.

Todo: fill out with details and examples. Provide feedback/discussion here .