create | INSERT | datasetsId, fhirId, fhirStoresId, locationsId, projectsId | Creates a FHIR resource. Implements the FHIR standard create interaction (DSTU2, STU3, R4), which creates a new resource with a server-assigned resource ID. The request body must contain a JSON-encoded FHIR resource, and the request headers must contain Content-Type: application/fhir+json. On success, the response body contains a JSON-encoded representation of the resource as it was created on the server, including the server-assigned resource ID and version ID. Errors generated by the FHIR store contain a JSON-encoded OperationOutcome resource describing the reason for the error. If the request cannot be mapped to a valid API method on a FHIR store, a generic GCP error might be returned instead. For samples that show how to call create, see Creating a FHIR resource. |
delete | DELETE | datasetsId, fhirId, fhirId1, fhirStoresId, locationsId, projectsId | Deletes a FHIR resource. Implements the FHIR standard delete interaction (DSTU2, STU3, R4). Note: Unless resource versioning is disabled by setting the disable_resource_versioning flag on the FHIR store, the deleted resources will be moved to a history repository that can still be retrieved through vread and related methods, unless they are removed by the purge method. For samples that show how to call delete, see Deleting a FHIR resource. |
capabilities | EXEC | datasetsId, fhirStoresId, locationsId, projectsId | Gets the FHIR capability statement (STU3, R4), or the conformance statement in the DSTU2 case for the store, which contains a description of functionality supported by the server. Implements the FHIR standard capabilities interaction (STU3, R4), or the conformance interaction in the DSTU2 case. On success, the response body contains a JSON-encoded representation of a CapabilityStatement resource. |
conditional_delete | EXEC | datasetsId, fhirId, fhirStoresId, locationsId, projectsId | Deletes a FHIR resource that match an identifier search query. Implements the FHIR standard conditional delete interaction, limited to searching by resource identifier. If multiple resources match, 412 Precondition Failed error will be returned. Search term for identifier should be in the pattern identifier=system|value or identifier=value - similar to the search method on resources with a specific identifier. Note: Unless resource versioning is disabled by setting the disable_resource_versioning flag on the FHIR store, the deleted resource is moved to a history repository that can still be retrieved through vread and related methods, unless they are removed by the purge method. For samples that show how to call conditionalDelete, see Conditionally deleting a FHIR resource. |
conditional_patch | EXEC | datasetsId, fhirId, fhirStoresId, locationsId, projectsId | If a resource is found with the identifier specified in the query parameters, updates part of that resource by applying the operations specified in a JSON Patch document. Implements the FHIR standard conditional patch interaction, limited to searching by resource identifier. DSTU2 doesn't define a conditional patch method, but the server supports it in the same way it supports STU3. Search term for identifier should be in the pattern identifier=system|value or identifier=value - similar to the search method on resources with a specific identifier. If the search criteria identify more than one match, the request returns a 412 Precondition Failed error. The request body must contain a JSON Patch document, and the request headers must contain Content-Type: application/json-patch+json. On success, the response body contains a JSON-encoded representation of the updated resource, including the server-assigned version ID. Errors generated by the FHIR store contain a JSON-encoded OperationOutcome resource describing the reason for the error. If the request cannot be mapped to a valid API method on a FHIR store, a generic GCP error might be returned instead. For samples that show how to call conditionalPatch, see Conditionally patching a FHIR resource. |
conditional_update | EXEC | datasetsId, fhirId, fhirStoresId, locationsId, projectsId | If a resource is found with the identifier specified in the query parameters, updates the entire contents of that resource. Implements the FHIR standard conditional update interaction, limited to searching by resource identifier. Search term for identifier should be in the pattern identifier=system|value or identifier=value - similar to the search method on resources with a specific identifier. If the search criteria identify more than one match, the request returns a 412 Precondition Failed error. If the search criteria identify zero matches, and the supplied resource body contains an id, and the FHIR store has enable_update_create set, creates the resource with the client-specified ID. It is strongly advised not to include or encode any sensitive data such as patient identifiers in client-specified resource IDs. Those IDs are part of the FHIR resource path recorded in Cloud Audit Logs and Pub/Sub notifications. Those IDs can also be contained in reference fields within other resources. If the search criteria identify zero matches, and the supplied resource body does not contain an id, the resource is created with a server-assigned ID as per the create method. The request body must contain a JSON-encoded FHIR resource, and the request headers must contain Content-Type: application/fhir+json. On success, the response body contains a JSON-encoded representation of the updated resource, including the server-assigned version ID. Errors generated by the FHIR store contain a JSON-encoded OperationOutcome resource describing the reason for the error. If the request cannot be mapped to a valid API method on a FHIR store, a generic GCP error might be returned instead. For samples that show how to call conditionalUpdate, see Conditionally updating a FHIR resource. |
execute_bundle | EXEC | datasetsId, fhirStoresId, locationsId, projectsId | Executes all the requests in the given Bundle. Implements the FHIR standard batch/transaction interaction (DSTU2, STU3, R4). Supports all interactions within a bundle, except search. This method accepts Bundles of type batch and transaction, processing them according to the batch processing rules (DSTU2, STU3, R4) and transaction processing rules (DSTU2, STU3, R4). The request body must contain a JSON-encoded FHIR Bundle resource, and the request headers must contain Content-Type: application/fhir+json. For a batch bundle or a successful transaction, the response body contains a JSON-encoded representation of a Bundle resource of type batch-response or transaction-response containing one entry for each entry in the request, with the outcome of processing the entry. In the case of an error for a transaction bundle, the response body contains a JSON-encoded OperationOutcome resource describing the reason for the error. If the request cannot be mapped to a valid API method on a FHIR store, a generic GCP error might be returned instead. This method checks permissions for each request in the bundle. The executeBundle permission is required to call this method, but you must also grant sufficient permissions to execute the individual requests in the bundle. For example, if the bundle contains a request to create a FHIR resource, the caller must also have been granted the healthcare.fhirResources.create permission. You can use audit logs to view the permissions for executeBundle and each request in the bundle. For more information, see Viewing Cloud Audit logs. For samples that show how to call executeBundle, see Managing FHIR resources using FHIR bundles. |
history | EXEC | datasetsId, fhirId, fhirId1, fhirStoresId, locationsId, projectsId | Lists all the versions of a resource (including the current version and deleted versions) from the FHIR store. Implements the per-resource form of the FHIR standard history interaction (DSTU2, STU3, R4). On success, the response body contains a JSON-encoded representation of a Bundle resource of type history, containing the version history sorted from most recent to oldest versions. Errors generated by the FHIR store contain a JSON-encoded OperationOutcome resource describing the reason for the error. If the request cannot be mapped to a valid API method on a FHIR store, a generic GCP error might be returned instead. For samples that show how to call history, see Listing FHIR resource versions. |
patch | EXEC | datasetsId, fhirId, fhirId1, fhirStoresId, locationsId, projectsId | Updates part of an existing resource by applying the operations specified in a JSON Patch document. Implements the FHIR standard patch interaction (STU3, R4). DSTU2 doesn't define a patch method, but the server supports it in the same way it supports STU3. The request body must contain a JSON Patch document, and the request headers must contain Content-Type: application/json-patch+json. On success, the response body contains a JSON-encoded representation of the updated resource, including the server-assigned version ID. Errors generated by the FHIR store contain a JSON-encoded OperationOutcome resource describing the reason for the error. If the request cannot be mapped to a valid API method on a FHIR store, a generic GCP error might be returned instead. For samples that show how to call patch, see Patching a FHIR resource. |
patient-everything | EXEC | PatientId, datasetsId, fhirStoresId, locationsId, projectsId | Retrieves a Patient resource and resources related to that patient. Implements the FHIR extended operation Patient-everything (DSTU2, STU3, R4). On success, the response body contains a JSON-encoded representation of a Bundle resource of type searchset, containing the results of the operation. Errors generated by the FHIR store contain a JSON-encoded OperationOutcome resource describing the reason for the error. If the request cannot be mapped to a valid API method on a FHIR store, a generic GCP error might be returned instead. The resources in scope for the response are: The patient resource itself. All the resources directly referenced by the patient resource. * Resources directly referencing the patient resource that meet the inclusion criteria. The inclusion criteria are based on the membership rules in the patient compartment definition (DSTU2, STU3, R4), which details the eligible resource types and referencing search parameters. For samples that show how to call Patient-everything, see Getting all patient compartment resources. |
read | EXEC | datasetsId, fhirId, fhirId1, fhirStoresId, locationsId, projectsId | Gets the contents of a FHIR resource. Implements the FHIR standard read interaction (DSTU2, STU3, R4). Also supports the FHIR standard conditional read interaction (DSTU2, STU3, R4) specified by supplying an If-Modified-Since header with a date/time value or an If-None-Match header with an ETag value. On success, the response body contains a JSON-encoded representation of the resource. Errors generated by the FHIR store contain a JSON-encoded OperationOutcome resource describing the reason for the error. If the request cannot be mapped to a valid API method on a FHIR store, a generic GCP error might be returned instead. For samples that show how to call read, see Getting a FHIR resource. |
resource-purge | EXEC | datasetsId, fhirId, fhirId1, fhirStoresId, locationsId, projectsId | Deletes all the historical versions of a resource (excluding the current version) from the FHIR store. To remove all versions of a resource, first delete the current version and then call this method. This is not a FHIR standard operation. For samples that show how to call Resource-purge, see Deleting historical versions of a FHIR resource. |
resource-validate | EXEC | datasetsId, fhirId, fhirStoresId, locationsId, projectsId | Validates an input FHIR resource's conformance to its profiles and the profiles configured on the FHIR store. Implements the FHIR extended operation $validate (DSTU2, STU3, or R4). The request body must contain a JSON-encoded FHIR resource, and the request headers must contain Content-Type: application/fhir+json. The Parameters input syntax is not supported. The profile query parameter can be used to request that the resource only be validated against a specific profile. If a profile with the given URL cannot be found in the FHIR store then an error is returned. Errors generated by validation contain a JSON-encoded OperationOutcome resource describing the reason for the error. If the request cannot be mapped to a valid API method on a FHIR store, a generic GCP error might be returned instead. |
search | EXEC | datasetsId, fhirStoresId, locationsId, projectsId | Searches for resources in the given FHIR store according to criteria specified as query parameters. Implements the FHIR standard search interaction (DSTU2, STU3, R4) using the search semantics described in the FHIR Search specification (DSTU2, STU3, R4). Supports four methods of search defined by the specification: GET [base]?[parameters] to search across all resources. GET [base]/[type]?[parameters] to search resources of a specified type. POST [base]/_search?[parameters] as an alternate form having the same semantics as the GET method across all resources. POST [base]/[type]/_search?[parameters] as an alternate form having the same semantics as the GET method for the specified type. The GET and POST methods do not support compartment searches. The POST method does not support application/x-www-form-urlencoded search parameters. On success, the response body contains a JSON-encoded representation of a Bundle resource of type searchset, containing the results of the search. Errors generated by the FHIR store contain a JSON-encoded OperationOutcome resource describing the reason for the error. If the request cannot be mapped to a valid API method on a FHIR store, a generic GCP error might be returned instead. The server's capability statement, retrieved through capabilities, indicates what search parameters are supported on each FHIR resource. A list of all search parameters defined by the specification can be found in the FHIR Search Parameter Registry (STU3, R4). FHIR search parameters for DSTU2 can be found on each resource's definition page. Supported search modifiers: :missing, :exact, :contains, :text, :in, :not-in, :above, :below, :[type], :not, and recurse (DSTU2 and STU3) or :iterate (R4). Supported search result parameters: _sort, _count, _include, _revinclude, _summary=text, _summary=data, and _elements. The maximum number of search results returned defaults to 100, which can be overridden by the _count parameter up to a maximum limit of 1000. The server might return fewer resources than requested to prevent excessively large responses. If there are additional results, the returned Bundle contains a link of relation "next", which has a _page_token parameter for an opaque pagination token that can be used to retrieve the next page. Resources with a total size larger than 5MB or a field count larger than 50,000 might not be fully searchable as the server might trim its generated search index in those cases. Note: FHIR resources are indexed asynchronously, so there might be a slight delay between the time a resource is created or changed, and the time when the change reflects in search results. The only exception is resource identifier data, which is indexed synchronously as a special index. As a result, searching using resource identifier is not subject to indexing delay. To use the special synchronous index, the search term for identifier should be in the pattern identifier=[system]\|[value] or identifier=[value], and any of the following search result parameters can be used: _count _include _revinclude _summary * _elements If your query contains any other search parameters, the standard asynchronous index will be used instead. Note that searching against the special index is optimized for resolving a small number of matches. The search isn't optimized if your identifier search criteria matches a large number (i.e. more than 2,000) of resources. For a search query that will match a large number of resources, you can avoiding using the special synchronous index by including an additional _sort parameter in your query. Use _sort=-_lastUpdated if you want to keep the default sorting order. For samples and detailed information, see Searching for FHIR resources and Advanced FHIR search features. |
search-type | EXEC | datasetsId, fhirStoresId, locationsId, projectsId, resourceType | Searches for resources in the given FHIR store according to criteria specified as query parameters. Implements the FHIR standard search interaction (DSTU2, STU3, R4) using the search semantics described in the FHIR Search specification (DSTU2, STU3, R4). Supports four methods of search defined by the specification: GET [base]?[parameters] to search across all resources. GET [base]/[type]?[parameters] to search resources of a specified type. POST [base]/_search?[parameters] as an alternate form having the same semantics as the GET method across all resources. POST [base]/[type]/_search?[parameters] as an alternate form having the same semantics as the GET method for the specified type. The GET and POST methods do not support compartment searches. The POST method does not support application/x-www-form-urlencoded search parameters. On success, the response body contains a JSON-encoded representation of a Bundle resource of type searchset, containing the results of the search. Errors generated by the FHIR store contain a JSON-encoded OperationOutcome resource describing the reason for the error. If the request cannot be mapped to a valid API method on a FHIR store, a generic GCP error might be returned instead. The server's capability statement, retrieved through capabilities, indicates what search parameters are supported on each FHIR resource. A list of all search parameters defined by the specification can be found in the FHIR Search Parameter Registry (STU3, R4). FHIR search parameters for DSTU2 can be found on each resource's definition page. Supported search modifiers: :missing, :exact, :contains, :text, :in, :not-in, :above, :below, :[type], :not, and recurse (DSTU2 and STU3) or :iterate (R4). Supported search result parameters: _sort, _count, _include, _revinclude, _summary=text, _summary=data, and _elements. The maximum number of search results returned defaults to 100, which can be overridden by the _count parameter up to a maximum limit of 1000. The server might return fewer resources than requested to prevent excessively large responses. If there are additional results, the returned Bundle contains a link of relation "next", which has a _page_token parameter for an opaque pagination token that can be used to retrieve the next page. Resources with a total size larger than 5MB or a field count larger than 50,000 might not be fully searchable as the server might trim its generated search index in those cases. Note: FHIR resources are indexed asynchronously, so there might be a slight delay between the time a resource is created or changed, and the time when the change reflects in search results. The only exception is resource identifier data, which is indexed synchronously as a special index. As a result, searching using resource identifier is not subject to indexing delay. To use the special synchronous index, the search term for identifier should be in the pattern identifier=[system]\|[value] or identifier=[value], and any of the following search result parameters can be used: _count _include _revinclude _summary * _elements If your query contains any other search parameters, the standard asynchronous index will be used instead. Note that searching against the special index is optimized for resolving a small number of matches. The search isn't optimized if your identifier search criteria matches a large number (i.e. more than 2,000) of resources. For a search query that will match a large number of resources, you can avoiding using the special synchronous index by including an additional _sort parameter in your query. Use _sort=-_lastUpdated if you want to keep the default sorting order. For samples and detailed information, see Searching for FHIR resources and Advanced FHIR search features. |
update | EXEC | datasetsId, fhirId, fhirId1, fhirStoresId, locationsId, projectsId | Updates the entire contents of a resource. Implements the FHIR standard update interaction (DSTU2, STU3, R4). If the specified resource does not exist and the FHIR store has enable_update_create set, creates the resource with the client-specified ID. It is strongly advised not to include or encode any sensitive data such as patient identifiers in client-specified resource IDs. Those IDs are part of the FHIR resource path recorded in Cloud Audit Logs and Pub/Sub notifications. Those IDs can also be contained in reference fields within other resources. The request body must contain a JSON-encoded FHIR resource, and the request headers must contain Content-Type: application/fhir+json. The resource must contain an id element having an identical value to the ID in the REST path of the request. On success, the response body contains a JSON-encoded representation of the updated resource, including the server-assigned version ID. Errors generated by the FHIR store contain a JSON-encoded OperationOutcome resource describing the reason for the error. If the request cannot be mapped to a valid API method on a FHIR store, a generic GCP error might be returned instead. For samples that show how to call update, see Updating a FHIR resource. |
vread | EXEC | _historyId, datasetsId, fhirId, fhirId1, fhirStoresId, locationsId, projectsId | Gets the contents of a version (current or historical) of a FHIR resource by version ID. Implements the FHIR standard vread interaction (DSTU2, STU3, R4). On success, the response body contains a JSON-encoded representation of the resource. Errors generated by the FHIR store contain a JSON-encoded OperationOutcome resource describing the reason for the error. If the request cannot be mapped to a valid API method on a FHIR store, a generic GCP error might be returned instead. For samples that show how to call vread, see Retrieving a FHIR resource version. |