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 v1beta1 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 v1beta1 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 or patch operations inside the bundle.
  • 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 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 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 and _filter 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 isn't supported.
    • Canonical reference searches are not supported. Canonical references are treated as normal references.
    • 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.

  • The HTTP HEAD requests aren't supported.

  • The ExecuteBundle endpoint doesn't accept history bundles.

Areas that aren't supported include:

  • Most extended operations aren't implemented.
  • Profiles aren't validated or enforced by the server.
  • User-defined search parameters aren't supported.
  • The XML content type isn't supported.
  • The patch operation doesn't support XML Patch or FHIRPath Patch.

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.
  • 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 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 and _filter 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.

Areas that aren't supported include:

  • Most extended operations aren't implemented.
  • Profiles aren't validated or enforced by the server.
  • User-defined search parameters aren't supported.
  • The XML content type isn't supported.
  • The patch operation doesn't support XML Patch or FHIRPath Patch.

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.
  • 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 and _filter 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.

Areas that aren't supported include:

  • Most extended operations aren't implemented.
  • Profiles aren't validated or enforced by the server.
  • User-defined search parameters aren't supported.
  • The XML content type isn't supported.

Details of operations outside of the published specification

  • The FHIR gRPC API offers an RPC interface for FHIR using the gRPC framework. It's nonstandard, under development, and doesn't support all FHIR methods.
  • 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.