FHIR conformance statement

FHIR stores within the Cloud Healthcare API support multiple versions of the Fast Healthcare Interoperability Resources (FHIR) specification published by Health Level 7 International (HL7).

The v1 API supports the following versions:

When you create a FHIR store, you specify the FHIR version as a parameter to the fhirStores.create method. You can't change the FHIR version after the store is created.

The API interface to each store conforms to the FHIR version of that store. For example, the DSTU2 conformance interaction is different from the STU3 capabilities interaction but both share the /fhir/metadata REST path, so that path returns different responses based on the FHIR version of the store.

Functionality added in later FHIR versions is available in stores using earlier FHIR versions if it doesn't create incompatibility. For example, the patch interaction is available on a DSTU2 store even though that interaction is only defined from STU3 onwards.

Details of supported functionality in the v1 API by FHIR version

R4

The server's capability statement indicates the parts of the specification that are supported.

  • Storage and retrieval of all R4 resources, including support for extension elements. The API accepts, stores, and returns extensions on any data element.
  • All the methods in the RESTful API that use the JSON content type are supported, except for:
    • The type-level and system-level history interactions that retrieve history across multiple resources aren't supported. Resource history can only be retrieved for one resource at a time.
    • The batch/transaction interaction doesn't support search operations inside the bundle.
  • Profile validation and enforcement are supported.
  • User-defined search parameters, including searches on extension elements, are supported in the v1beta1 API.

  • All the search functionality is supported, except for:

    • The search parameters Group-characteristic-value, Location-near, Bundle-composition, and Bundle-message aren't supported.
    • Search parameters that perform phonetic matching aren't supported.
    • The search result parameters _contained, _containedType, _summary=count, and _summary=true aren't supported.
    • The special search parameter _content searches all fields of the resource that search parameters refer to. It excludes fields that aren't searchable. It doesn't support explicit AND (terms are implicitly combined with AND) or brackets.
    • The special search parameters _query, _filter, and _list aren't supported.
    • The _sort parameter, when used on fields with repeated elements, sorts by the first element; this differs from the specification. All supported search parameters are eligible for _sort, except for the special search parameter _content.
    • The token search modifier :of-type and the reference search modifier :identifier aren't supported.
    • Canonical reference searches are not supported. Canonical references are treated as normal references.
    • When using the _type parameter, only the common (to all resources) search parameters can be used and not the intersection of the specified resource types.

    • The following subset of composite search parameters are supported:

      • DocumentReference-relationship
      • Observation-code-value-concept
      • Observation-code-value-date
      • Observation-code-value-quantity
      • Observation-code-value-string
      • Observation-combo-code-value-concept
      • Observation-combo-code-value-quantity
      • Observation-component-code-value-concept
      • Observation-component-code-value-quantity

      The remaining composite search parameters aren't supported.

    • Search using the POST method does not accept application/x-www-form-urlencoded parameters in the request body.

    • Wildcard (*) is supported for _include but is not supported for _revinclude.

Areas that aren't supported include:

  • Most extended operations aren't implemented.
  • The XML content type isn't supported.
  • The patch operation doesn't support XML Patch or FHIRPath Patch.
  • The HTTP HEAD requests aren't supported.

Areas where the API deviates from the FHIR spec to allow for backwards compatibility:

  • null is accepted for required fields
  • An empty code is accepted for required fields
  • urn:uuid references are allowed in batch bundles

STU3

The server's capability statement indicates the parts of the specification that are supported.

  • Storage and retrieval of all STU3 resources is supported, including support for extension elements. The API accepts, stores, and returns extensions on any data element.

  • All the methods in the RESTful API that use the JSON content type are supported, except for:

    • The type-level and system-level history interactions that retrieve history across multiple resources aren't supported. Resource history can only be retrieved for one resource at a time.
    • The batch/transaction interaction doesn't support search operations inside the bundle.

  • Profile validation and enforcement are supported.

  • User-defined search parameters, including searches on extension elements, are supported in the v1beta1 API.

  • All the search functionality is supported, except for:

    • The search parameters Group-characteristic-value, Sequence-coordinate, Location-near, Location-near-distance, Bundle-composition, and Bundle-message aren't supported.
    • Search parameters that perform phonetic matching aren't supported.
    • The search result parameters _contained, _containedType, _summary=count, and _summary=true aren't supported.
    • The special search parameter _content searches all fields of the resource that are referred to by search parameters. It excludes fields that aren't searchable. It doesn't support explicit AND (terms are implicitly combined with AND) or brackets.
    • The special search parameters _query, _filter, and _list aren't supported.
    • The _sort parameter, when used on fields with repeated elements, sorts by the first element; this differs from the specification. All supported search parameters are eligible for _sort, except for the special search parameter _content.
    • Search using the POST method does not accept application/x-www-form-urlencoded parameters in the request body.
    • Wildcard (*) is supported for _include but is not supported for _revinclude.

Areas that aren't supported include:

  • Most extended operations aren't implemented.
  • The XML content type isn't supported.
  • The patch operation doesn't support XML Patch or FHIRPath Patch.

Areas where the API deviates from the FHIR spec to allow for backwards compatibility:

  • null is accepted for required fields
  • An empty code is accepted for required fields
  • urn:uuid references are allowed in batch bundles

DSTU2

The server's conformance statement indicates the parts of the specification that are supported.

  • Storage and retrieval of all DSTU2 resources is supported, including support for extension elements. The API accepts, stores, and returns extensions on any data element.
  • All the methods in the RESTful API that use the JSON content type are supported, except for:
    • The type-level and system-level history interactions that retrieve history across multiple resources aren't supported. Resource history can only be retrieved for one resource at a time.
    • The batch/transaction interaction doesn't support search operations inside the bundle.
  • Profile validation and enforcement are supported.
  • All the search functionality is supported, except for:
    • The search parameters Group-characteristic-value, Location-near, Location-near-distance, Bundle-composition, Bundle-message, Coverage-dependent, and Coverage-sequence aren't supported.
    • Search parameters defined on extension elements aren't supported.
    • Search parameters that perform phonetic matching aren't supported.
    • The search result parameters _contained, _containedType, _summary=count, and _summary=true aren't supported.
    • The special search parameter _content searches all fields of the resource that are referred to by search parameters. It excludes fields that aren't searchable. It doesn't support explicit AND (terms are implicitly combined with AND) or brackets.
    • The special search parameters _query, _filter, and _list aren't supported.
    • The _sort parameter, when used on fields with repeated elements, sorts by the first element; this differs from the specification. All supported search parameters are eligible for _sort, except for the special search parameter _content.
    • Search using the POST method does not accept application/x-www-form-urlencoded parameters in the request body.
    • Wildcard (*) is supported for _include but is not supported for _revinclude.

Areas that aren't supported include:

  • Most extended operations aren't implemented.
  • User-defined search parameters aren't supported for DSTU2.
  • The XML content type isn't supported.

Areas where the API deviates from the FHIR spec to allow for backwards compatibility:

  • null is accepted for required fields
  • An empty code is accepted for required fields
  • urn:uuid references are allowed in batch bundles

Details of operations outside of the published specification

  • The FHIR store configuration includes an option to notify a user-specified Pub/Sub topic for all changes to resources in the store. This notification mechanism is common across all Cloud Healthcare API stores and isn't intended to replace FHIR Subscription (DSTU2, STU3, and R4) functionality.
  • The FHIR store export operation to Cloud Storage destinations offers only a bulk export of the entire store. It's not an implementation of the FHIR Bulk Data draft specification.
  • The FHIR store import operation isn't defined in the specification.
  • The Resource-purge operation that removes historical versions of resources isn't defined in the specification. This API could change in the future if the standards process or other FHIR implementations converge on a different API method for this use case.
  • The ExecuteBundle endpoint accepts history bundles in v1beta1 to create historical versions of resources.