Declaración de conformidad de FHIR

Los almacenes FHIR de la API Cloud Healthcare son compatibles con varias versiones de la especificación Fast Healthcare Interoperability Resources (FHIR), publicada por Health Level 7 International (HL7).

La API v1 admite las siguientes versiones:

Cuando creas un almacén FHIR, especificas la versión de FHIR como parámetro del 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 tienda se ajusta a la versión de FHIR de esa tienda. Por ejemplo, la interacción de DSTU2 conformance es diferente de la interacción de STU3 capabilities, pero ambas comparten la ruta REST /fhir/metadata, por lo que esa ruta devuelve respuestas diferentes en función de la versión de FHIR de la tienda.

Las funciones añadidas en versiones posteriores de FHIR están disponibles en tiendas que usan versiones anteriores de FHIR si no generan incompatibilidad. Por ejemplo, la interacción patch está disponible en una tienda DSTU2 aunque solo se haya definido a partir de STU3.

Detalles de las funciones admitidas en la API v1 por versión de FHIR

R5

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

  • Almacenamiento y recuperación de todos los recursos de R5, incluida la compatibilidad con los elementos de extensión. La API acepta, almacena y devuelve extensiones en cualquier elemento de datos.
  • Se admiten todos los métodos de la API RESTful que usan el tipo de contenido JSON, excepto los siguientes:
    • No se admiten las interacciones de historial a nivel de tipo y de sistema que recuperan el historial de varios recursos. El historial de recursos solo se puede obtener de un recurso a la vez.
    • La interacción lote/transacción no admite operaciones de búsqueda dentro del paquete.
  • Se admite la validación y la implementación obligatoria de perfiles.
  • La API v1beta1 admite parámetros de búsqueda definidos por el usuario, incluidas las búsquedas en elementos de extensión.

  • Se admite toda la función de búsqueda, excepto lo siguiente:

    • No se admiten los parámetros de búsqueda Group-characteristic-value, Location-near, Location-contains, DocumentReference-relationship, Bundle-composition, Bundle-message, Observation-component-value-canonical,Observation-value-canonical, QuestionnaireResponse-item-subject y Composition-section-text.
    • No se admiten parámetros de búsqueda que realicen coincidencias fonéticas.
    • 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 del recurso al que hacen referencia los parámetros de búsqueda. Excluye los campos que no se pueden buscar. No admite AND explícitos (los términos se combinan implícitamente con AND) ni corchetes.
    • No se admiten los parámetros de búsqueda especiales Resource-query, Resource-filter, Resource-language, Resource-in y Resource-list.
    • El parámetro _sort, cuando se usa en campos con elementos repetidos, ordena por el primer elemento, lo que difiere de la especificación. _sort se admite en los parámetros de búsqueda de tipo number, data, string, token y quantity.
    • No se admiten los modificadores de búsqueda de tokens :of-type, :code-text, text-advanced, :text ni los modificadores de búsqueda de referencias :identifier, not-in, text-advanced y :code-text. No se admite el modificador contains para las búsquedas de URIs.
    • No se admiten las búsquedas de referencias canónicas. Las referencias canónicas se tratan como referencias normales. No se admiten los modificadores above y below.
    • Cuando se usa el parámetro _type, solo se pueden usar los parámetros de búsqueda comunes a todos los recursos, no la intersección de los tipos de recursos especificados.

    • Se admite el siguiente subconjunto de parámetros de búsqueda compuestos:

      • 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

      El resto de los parámetros de búsqueda compuestos no se admiten.

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

    • Se admite el comodín (*) en _include, pero no en _revinclude.

Las áreas que no se admiten son las siguientes:

  • No se admite el tipo de contenido XML.
  • La operación de parche no admite parches XML ni parches FHIRPath.
  • No se admiten las solicitudes HTTP HEAD.

Algunos aspectos de la API se desviaron de la especificación FHIR debido a la compatibilidad con versiones anteriores de FHIR. Se han corregido en la versión R5:

  • Cuando se habilita la validación de campos obligatorios, ahora se rechazan los campos null y los campos vacíos (por ejemplo, {}).
  • Ya no se admite UpperCamelCase en los campos de recursos de JSON.
  • No se permiten referencias urn:uuid en paquetes de lote, independientemente de si la integridad referencial está inhabilitada o no. Los paquetes por lotes nunca reescriben las referencias.
  • Los paquetes de transacciones son más estrictos a la hora de reescribir referencias que antes, y se producen errores en FullUrls no válidas en las entradas, tal como se define en la especificación: https://www.hl7.org/fhir/bundle.html#references.
  • Las referencias que parezcan referencias de recursos deben tener IDs válidos.
  • La validación del perfil base está habilitada para las solicitudes PATCH.

R4

La declaración de capacidad 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 los elementos de extensión. La API acepta, almacena y devuelve extensiones en cualquier elemento de datos.
  • Se admiten todos los métodos de la API RESTful que usan el tipo de contenido JSON, excepto los siguientes:
    • No se admiten las interacciones de historial a nivel de tipo y de sistema que recuperan el historial de varios recursos. El historial de recursos solo se puede obtener de un recurso a la vez.
    • La interacción lote/transacción no admite operaciones de búsqueda dentro del paquete.
  • Se admite la validación y la implementación obligatoria de perfiles.
  • La API v1beta1 admite parámetros de búsqueda definidos por el usuario, incluidas las búsquedas en elementos de extensión.

  • Se admite toda la función de búsqueda, excepto lo siguiente:

    • No se admiten los parámetros de búsqueda Group-characteristic-value, Location-near, Bundle-composition y Bundle-message.
    • No se admiten parámetros de búsqueda que realicen coincidencias fonéticas.
    • 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 del recurso al que hacen referencia los parámetros de búsqueda. Excluye los campos que no se pueden buscar. No admite AND explícitos (los términos se combinan implícitamente con AND) ni 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, lo que difiere de la especificación. _sort se admite en los parámetros de búsqueda de tipo number, data, string, token y quantity.
    • No se admiten el modificador de búsqueda de token :of-type ni 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 (a 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

      El resto de los parámetros de búsqueda compuestos no se admiten.

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

    • Se admite el comodín (*) en _include, pero no en _revinclude.

Las áreas que no se admiten son las siguientes:

  • La mayoría de las operaciones extendidas no se implementan.
  • No se admite el tipo de contenido XML.
  • La operación de parche no admite parches XML ni parches FHIRPath.
  • No se admiten las solicitudes HTTP HEAD.

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

  • Se acepta null en los campos obligatorios
  • Se acepta un código vacío en los campos obligatorios
  • Se permiten referencias urn:uuid en paquetes por lotes cuando la integridad referencial está inhabilitada.

STU3

La declaración de capacidad 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 devuelve extensiones en cualquier elemento de datos.

  • Se admiten todos los métodos de la API RESTful que usan el tipo de contenido JSON, excepto los siguientes:

    • No se admiten las interacciones de historial a nivel de tipo y de sistema que recuperan el historial de varios recursos. El historial de recursos solo se puede obtener de un recurso a la vez.
    • La interacción lote/transacción no admite operaciones de búsqueda dentro del paquete.

  • Se admite la validación y la implementación obligatoria de perfiles.

  • La API v1beta1 admite parámetros de búsqueda definidos por el usuario, incluidas las búsquedas en elementos de extensión.

  • Se admite toda la función de búsqueda, excepto lo siguiente:

    • No se admiten los parámetros de búsqueda Group-characteristic-value, Sequence-coordinate, Location-near, Location-near-distance, Bundle-composition y Bundle-message.
    • No se admiten parámetros de búsqueda que realicen coincidencias fonéticas.
    • 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 del recurso al que hacen referencia los parámetros de búsqueda. Se excluyen los campos que no se pueden buscar. No admite AND explícitos (los términos se combinan implícitamente con AND) ni 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, lo que difiere de la especificación. _sort se admite en los parámetros de búsqueda de tipo number, data, string, token y quantity.
    • La búsqueda con el método POST no acepta parámetros application/x-www-form-urlencoded en el cuerpo de la solicitud.
    • Se admite el comodín (*) en _include, pero no en _revinclude.

Las áreas que no se admiten son las siguientes:

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

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

  • Se acepta null en los campos obligatorios
  • Se acepta un código vacío en los campos obligatorios
  • Se permiten referencias urn:uuid en paquetes por lotes cuando la integridad referencial está inhabilitada.

DSTU2

La declaración de conformidad 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 DSTU2, incluida la compatibilidad con los elementos de extensión. La API acepta, almacena y devuelve extensiones en cualquier elemento de datos.
  • Se admiten todos los métodos de la API RESTful que usan el tipo de contenido JSON, excepto los siguientes:
    • No se admiten las interacciones de historial a nivel de tipo y de sistema que recuperan el historial de varios recursos. El historial de recursos solo se puede obtener de un recurso a la vez.
    • La interacción lote/transacción no admite operaciones de búsqueda dentro del paquete.
  • Se admite la validación y la implementación obligatoria de perfiles.
  • Se admite toda la función de búsqueda, excepto lo siguiente:
    • 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 parámetros de búsqueda definidos en elementos de extensión.
    • No se admiten parámetros de búsqueda que realicen coincidencias fonéticas.
    • 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 del recurso al que hacen referencia los parámetros de búsqueda. Se excluyen los campos que no se pueden buscar. No admite AND explícitos (los términos se combinan implícitamente con AND) ni 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, lo que difiere de la especificación. _sort se admite en los parámetros de búsqueda de tipo number, data, string, token y quantity.
    • La búsqueda con el método POST no acepta parámetros application/x-www-form-urlencoded en el cuerpo de la solicitud.
    • Se admite el comodín (*) en _include, pero no en _revinclude.

Las áreas que no se admiten son las siguientes:

  • La mayoría de las operaciones extendidas no se implementan.
  • No se admiten parámetros de búsqueda definidos por el usuario en DSTU2.
  • No se admite el tipo de contenido XML.

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

  • Se acepta null en los campos obligatorios
  • Se acepta un código vacío en los campos obligatorios
  • Se permiten referencias urn:uuid en paquetes por lotes cuando la integridad referencial está inhabilitada.

Detalles de las operaciones fuera de la especificación publicada

  • La configuración de un almacén FHIR incluye una opción para notificar un tema de Pub/Sub especificado por el usuario para todos los cambios en los recursos del almacén. Este mecanismo de notificación es común a todos los almacenes de la API Cloud Healthcare y no pretende sustituir la funcionalidad de suscripción FHIR (DSTU2, STU3, R4 y R5).
  • La operación de exportación de almacenes FHIR a los destinos de Cloud Storage solo permite una exportación en bloque de todo el almacén. No se trata de una implementación de la especificación en borrador de los datos en bloque de FHIR.
  • La operación de importación de almacenes FHIR no se define en la especificación.
  • La operación Resource-purge que elimina las versiones históricas de los recursos no se define en la especificación. Esta API podría cambiar en el futuro si el proceso de los estándares u otras implementaciones de FHIR convergen en un método de API diferente para este caso práctico.
  • El endpoint ExecuteBundle acepta paquetes history en v1beta1 para crear versiones históricas de los recursos.