FHIR conformance statement

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

The versions supported by the v1beta1 API are:

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 despite that interaction being defined only from STU3 onwards.

Details of supported functionality in the v1beta1 API by FHIR version

STU3

In general, the server's capability statement indicates the parts of the specification that are supported.

  • Storage and retrieval of all STU3 resources, including support for extension elements. The API accepts, stores, and returns extensions on any data element.
  • All of the methods in the RESTful API, using the JSON content type, except for:
    • The type-level and system-level history interactions that retrieve history across multiple resources are not supported. Resource history can only be retrieved for one resource at a time.
    • The batch/transaction interaction does not support search operations inside the bundle.
  • All of the search functionality, except for:
    • The search parameters Group-characteristic-value, Sequence-coordinate, Location-near, Location-near-distance, Bundle-composition, and Bundle-message are not supported. Search parameters defined on extension elements are not supported.
    • Search parameters that perform phonetic matching are not supported.
    • The search result parameters _contained, _containedType, _summary=count, and _summary=true are not supported.
    • The special search parameter _content searches all fields of the resource that are referred to by search parameters. It excludes fields that are not searchable. It does not support explicit AND (terms are implicitly combined with AND) or brackets.
    • The special search parameters _query and _filter are not 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 are not supported include:

  • Most extended operations are not implemented.
  • Profiles are not validated or enforced by the server.
  • User-defined search parameters are not supported.
  • The XML content type is not supported.
  • The patch operation does not support XML Patch or FHIRPath Patch.

DSTU2

In general, the server's conformance statement indicates the parts of the specification that are supported.

  • Storage and retrieval of all DSTU2 resources, including support for extension elements. The API accepts, stores, and returns extensions on any data element.
  • All of the methods in the RESTful API, using the JSON content type, except for:
    • The type-level and system-level history interactions that retrieve history across multiple resources are not supported. Resource history can only be retrieved for one resource at a time.
    • The batch/transaction interaction does not support search operations inside the bundle.
  • All of the search functionality, except for:
    • The search parameters Group-characteristic-value, Location-near, Location-near-distance, Bundle-composition, Bundle-message, Coverage-dependent, and Coverage-sequence are not supported. Search parameters defined on extension elements are not supported.
    • Search parameters that perform phonetic matching are not supported.
    • The search result parameters _contained, _containedType, _summary=count, and _summary=true are not supported.
    • The special search parameter _content searches all fields of the resource that are referred to by search parameters. It excludes fields that are not searchable. It does not support explicit AND (terms are implicitly combined with AND) or brackets.
    • The special search parameters _query and _filter are not 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 are not supported include:

  • Most extended operations are not implemented.
  • Profiles are not validated or enforced by the server.
  • User-defined search parameters are not supported.
  • The XML content type is not supported.

Details of operations outside of the published specification

  • The FHIR gRPC API offers an RPC interface for FHIR using the gRPC framework. It is nonstandard, under development, and does not 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 is not intended as a replacement for FHIR Subscription functionality.
  • The FHIR store export operation to Cloud Storage destinations offers only a bulk export of the entire store. It is not an implementation of the FHIR Bulk Data draft specification.
  • The FHIR store import operation is not defined in the specification.
  • The Resource-purge operation that removes historical versions of resources is not 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.
หน้านี้มีประโยชน์ไหม โปรดแสดงความคิดเห็น