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.
  • 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 por lotes/transacción 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 en elementos de extensión, se admiten en 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 ni el modificador de búsqueda de referencias :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.

Áreas en las que la API se desvía de la especificación de FHIR para permitir la retrocompatibilidad:

  • Se acepta null para los campos obligatorios
  • Se acepta un código vacío para los campos obligatorios
  • Se permiten referencias urn:uuid en paquetes por lotes

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 por lotes/transacción 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 en elementos de extensión, se admiten en 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.

Áreas en las que la API se desvía de la especificación de FHIR para permitir la retrocompatibilidad:

  • Se acepta null para los campos obligatorios
  • Se acepta un código vacío para los campos obligatorios
  • Se permiten referencias urn:uuid en paquetes por lotes

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.
  • 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 por lotes/transacción no admite operaciones de búsqueda dentro del paquete.
  • Se admiten la validación y la aplicación del perfil.
  • Se admite toda la funcionalidad de búsqueda, excepto:
    • 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.

Áreas en las que la API se desvía de la especificación de FHIR para permitir la retrocompatibilidad:

  • Se acepta null para los campos obligatorios
  • Se acepta un código vacío para los campos obligatorios
  • Se permiten referencias urn:uuid en paquetes por lotes

Detalles de las operaciones fuera de la especificación publicada

  • 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.
  • El extremo ExecuteBundle acepta paquetes history en v1beta1 para crear versiones históricas de los recursos.