Operations

RESTful API Transactions

FHIR is based on a RESTful API framework where transactions are performed directly on a server resource using an HTTP request/response.

The API describes the FHIR resources as a set of operations (known as "interactions") on resources where individual resource instances are managed in collections by their type. Servers can choose which of these interactions are made available and which resource types they support. Servers SHALL provide a Capability Statement that specifies which interactions and resources are supported.

The read interaction used to access the current contents of a resource is the primary interaction in scope for this guide.

The interaction is performed by an HTTP GET command as shown:

GET [base]/[type]/[id] {?_format=[mime-type]}

Operations

The FHIR specification defines a special kind of operations that have an RPC-like functionality. These are called "Execute Operations", or simply "Operations" throughout the FHIR specification. These FHIR operations can be executed against a FHIR server, type, or resource instance. These invocations are named using the convention $name (i.e. the name is prefixed with $) and will generally take a Parameters resource as input and output.

Approach Towards Operations

Because this guide is aimed at ensuring a core set of capabilities and behaviors are implemented by Canadian systems, the operations highlighted in this guide are not enforced at the same degree as other artifacts.

This specification has identified the following operations that should be supported by the implementations complying to the SMART IG. This list may expand as per the community and implementer's feedback.

Patient/[id]/$everything Operation

The Patient/$everything operation provides a to return all the information related to one or more patients described in the resource or context on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, medications, locations, organizations etc.

Proposed use within Ontario eReferral is to use this operation in combination with launch context to return a restricted subset of resources with in the patient record.

Note:

• The intended use for this operation is to provide a patient with access to their entire record (e.g. "Blue Button"), or for provider or other user to perform a bulk data download. The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient(s), and any resource referenced from those, including binaries and attachments. In the US Realm, at a minimum, the resources returned SHALL include all the data covered by the meaningful use common data elements as defined in the US Core Implementation Guide.
• Other applicable implementation guides may make additional rules about how much information that is returned.