Declaración de conformidad de FHIR

Los almacenes FHIR de la API de Cloud Healthcare admiten varias versiones de la especificación de Fast Healthcare Interoperability Resources (Recursos de interoperabilidad para atención médica rápida) (FHIR) que publicó Health Level 7 International (HL7).

La API v1 admite las siguientes versiones:

Cuando creas un almacén de FHIR, especificas la versión de FHIR como un parámetro para el método fhirStores.create. No puedes cambiar la versión de FHIR después de crear el almacén.

La interfaz de la API de cada almacén se ajusta a la versión FHIR de ese almacén. Por ejemplo, la interacción DSTU2 conformance es diferente de la interacción STU3 capabilities, pero ambas comparten la ruta REST /fhir/metadata, por lo que esa ruta muestra respuestas diferentes según la versión FHIR del almacén.

La funcionalidad agregada en versiones posteriores de FHIR está disponible en almacenes que usan versiones anteriores de FHIR si no crean incompatibilidad. Por ejemplo, la interacción patch está disponible en un almacén DSTU2 aunque esa interacción solo se defina a partir de STU3.

Detalles de la funcionalidad de la API v1 compatible con la versión de FHIR

R4

La declaración de capacidades del servidor indica las partes de la especificación que son compatibles.

  • Almacenamiento y recuperación de todos los recursos de R4, incluida la compatibilidad con elementos de extensión. La API acepta, almacena y muestra extensiones en cualquier elemento de datos.
  • Se admiten todos los métodos de la API de RESTful que usan el tipo de contenido JSON, excepto los siguientes:
    • No se admiten las interacciones de historial a nivel de tipo y sistema que recuperan el historial en varios recursos. El historial de recursos solo se puede recuperar para un recurso a la vez.
    • La interacción batch/transaction no admite operaciones de búsqueda dentro del paquete.
  • Se admiten la validación y la aplicación del perfil.
  • Los parámetros de búsqueda definidos por el usuario, incluidas las búsquedas de elementos de extensión, son compatibles con la API de v1beta1.
  • Se admite toda la funcionalidad de búsqueda, excepto:

    • No se admiten los parámetros de búsqueda Group-characteristic-value, Location-near, Bundle-composition y Bundle-message.
    • Los parámetros de búsqueda que realizan la coincidencia fonética no son compatibles.
    • No se admiten los parámetros de resultados de búsqueda _contained, _containedType, _summary=count y _summary=true.
    • El parámetro de búsqueda especial _content busca todos los campos del recurso a los que hacen referencia los parámetros de búsqueda. Excluye los campos que no se pueden buscar. No admite AND explícito (los términos se combinan de forma implícita con AND) o corchetes.
    • No se admiten los parámetros de búsqueda especiales _query, _filter y _list.
    • El parámetro _sort, cuando se usa en campos con elementos repetidos, ordena por el primer elemento; esto difiere de la especificación. Todos los parámetros de búsqueda admitidos son aptos para _sort, excepto el parámetro de búsqueda especial _content.
    • No se admiten el modificador de búsqueda de tokens :of-type y el modificador de búsqueda de referencia :identifier.
    • No se admiten las búsquedas de referencias canónicas. Las referencias canónicas se tratan como referencias normales.
    • Cuando se usa el parámetro _type, solo se pueden usar los parámetros de búsqueda comunes (para todos los recursos) y no la intersección de los tipos de recursos especificados.
    • Se admite el siguiente subconjunto de parámetros de búsqueda compuestos:

      • 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

      No se admiten los parámetros de búsqueda compuestos restantes.

    • La búsqueda con el método POST no acepta parámetros application/x-www-form-urlencoded en el cuerpo de la solicitud.

    • El comodín (*) es compatible con _include, pero no con _revinclude.

Las áreas que no se admiten incluyen lo siguiente:

  • La mayoría de las operaciones extendidas no se implementaron.
  • No se admite el tipo de contenido XML.
  • La operación de parche no admite el parche XML o el parche FHIRPath.
  • No se admiten las solicitudes HEAD de HTTP.
  • El extremo ExecuteBundle no acepta paquetes history.

STU3

La declaración de capacidades del servidor indica las partes de la especificación que son compatibles.

  • Se admite el almacenamiento y la recuperación de todos los recursos de STU3, incluida la compatibilidad con los elementos de extensión. La API acepta, almacena y muestra extensiones en cualquier elemento de datos.
  • Todos los métodos en la API de RESTful que usan el tipo de contenido JSON son compatibles, excepto:

    • No se admiten las interacciones de historial a nivel de tipo y sistema que recuperan el historial en varios recursos. El historial de recursos solo se puede recuperar para un recurso a la vez.
    • La interacción batch/transaction no admite operaciones de búsqueda dentro del paquete.
  • Se admiten la validación y la aplicación del perfil.

  • Los parámetros de búsqueda definidos por el usuario, incluidas las búsquedas de elementos de extensión, son compatibles con la API de v1beta1.

  • Se admite toda la funcionalidad de búsqueda, excepto:

    • No se admiten los parámetros de búsqueda Group-characteristic-value, Sequence-coordinate, Location-near, Location-near-distance, Bundle-composition y Bundle-message.
    • Los parámetros de búsqueda que realizan la coincidencia fonética no son compatibles.
    • No se admiten los parámetros de resultados de búsqueda _contained, _containedType, _summary=count y _summary=true.
    • El parámetro de búsqueda especial _content busca en todos los campos a los que se hace referencia mediante los parámetros de búsqueda. Excluye los campos que no se pueden buscar. No admite AND explícito (los términos se combinan de forma implícita con AND) o corchetes.
    • No se admiten los parámetros de búsqueda especiales _query, _filter y _list.
    • El parámetro _sort, cuando se usa en campos con elementos repetidos, ordena por el primer elemento; esto difiere de la especificación. Todos los parámetros de búsqueda admitidos son aptos para _sort, excepto el parámetro de búsqueda especial _content.
    • La búsqueda con el método POST no acepta parámetros application/x-www-form-urlencoded en el cuerpo de la solicitud.
    • El comodín (*) es compatible con _include, pero no con _revinclude.

Las áreas que no se admiten incluyen lo siguiente:

  • La mayoría de las operaciones extendidas no se implementaron.
  • No se admite el tipo de contenido XML.
  • La operación de parche no admite el parche XML ni el parche FHIRPath.

DSTU2

La declaración de conformidad del servidor indica las partes de la especificación que se admiten.

  • Se admite el almacenamiento y la recuperación de todos los recursos de DSTU2, incluida la compatibilidad con los elementos de extensión. La API acepta, almacena y muestra extensiones en cualquier elemento de datos.
  • Se admiten todos los métodos de la API de RESTful que usan el tipo de contenido JSON, excepto los siguientes:
    • No se admiten las interacciones de historial a nivel de tipo y sistema que recuperan el historial en varios recursos. El historial de recursos solo se puede recuperar para un recurso a la vez.
    • La interacción batch/transaction no admite operaciones de búsqueda dentro del paquete.
  • Se admiten la validación y la aplicación del perfil.
  • Se admiten todas las funcionalidades de la búsqueda, excepto las siguientes:
    • No se admiten los parámetros de búsqueda Group-characteristic-value, Location-near, Location-near-distance, Bundle-composition, Bundle-message, Coverage-dependent y Coverage-sequence.
    • No se admiten los parámetros de búsqueda definidos en los elementos de extensión.
    • Los parámetros de búsqueda que realizan la coincidencia fonética no son compatibles.
    • No se admiten los parámetros de resultados de búsqueda _contained, _containedType, _summary=count y _summary=true.
    • El parámetro de búsqueda especial _content busca en todos los campos a los que se hace referencia mediante los parámetros de búsqueda. Excluye los campos que no se pueden buscar. No admite AND explícito (los términos se combinan de forma implícita con AND) o corchetes.
    • No se admiten los parámetros de búsqueda especiales _query, _filter y _list.
    • El parámetro _sort, cuando se usa en campos con elementos repetidos, ordena por el primer elemento; esto difiere de la especificación. Todos los parámetros de búsqueda admitidos son aptos para _sort, excepto el parámetro de búsqueda especial _content.
    • La búsqueda con el método POST no acepta parámetros application/x-www-form-urlencoded en el cuerpo de la solicitud.
    • El comodín (*) es compatible con _include, pero no con _revinclude.

Las áreas que no se admiten incluyen lo siguiente:

  • La mayoría de las operaciones extendidas no se implementaron.
  • Los parámetros de búsqueda definidos por el usuario no son compatibles con DSTU2.
  • No se admite el tipo de contenido XML.

Detalles de las operaciones fuera de la especificación publicada

  • La API de gRPC de FHIR ofrece una interfaz de RPC para FHIR mediante el framework de gRPC. No es estándar, está en desarrollo y no es compatible con todos los métodos FHIR.
  • La configuración del almacén de FHIR incluye una opción para notificar a un tema de Pub/Sub especificado por el usuario sobre todos los cambios en los recursos del almacén. Este mecanismo de notificación es común en todas las tiendas de API de Cloud Healthcare y no está diseñado para reemplazar la funcionalidad de suscripción FHIR (DSTU2, STU3 y R4).
  • La operación de exportación del almacén de FHIR a los destinos de Cloud Storage solo ofrece una exportación masiva de todo el almacén. No es una implementación de la especificación del borrador de datos masivos de FHIR.
  • La operación de importación del almacén de FHIR no está definida en la especificación.
  • La operación Resource-purge que quita las versiones históricas de los recursos no está definida en la especificación. Esta API podría cambiar en el futuro si el proceso estándar o las otras implementaciones de FHIR convergen en un método de API diferente para este caso práctico.