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:
- R4 versión 4.0.1 (Versión 4)
- STU3 versión 3.0.1 (Versión 3: Estándar para uso de prueba)
- DSTU2 versión 1.0.2 (Borrador de estándar para uso de prueba)
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
El nombre del servidor declaración de capacidades indica las partes de la especificación que se admiten.
- 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 de la
API de RESTful
que usan el tipo de contenido JSON, excepto en los siguientes casos:
- El nivel de tipo y el nivel de sistema historia que recuperan el historial en múltiples recursos no no es compatible. El historial de recursos solo se puede recuperar para un recurso a la vez.
- El batch/transaction interacción no admite operaciones de búsqueda dentro del paquete.
- Perfil de validación y aplicación.
- 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.
Toda la búsqueda de la aplicación, excepto en los siguientes casos:
- No se admiten los parámetros de búsqueda
Group-characteristic-value
,Location-near
,Bundle-composition
yBundle-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 admiteAND
explícito (los términos se combinan de forma implícita conAND
) 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
. - El modificador de búsqueda de tokens
:of-type
y el modificador de la búsqueda de referencias No se admiten: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ámetrosapplication/x-www-form-urlencoded
en el cuerpo de la solicitudEl comodín (
*
) es compatible con_include
, pero no es compatible con_revinclude
- No se admiten los parámetros de búsqueda
Las áreas que no se admiten incluyen lo siguiente:
- Más probable operaciones extendidas no están implementados.
- 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
urn:uuid
referencias en paquetes por lotes
STU3
El nombre del servidor declaración de capacidades indica las partes de la especificación que se admiten.
- Almacenamiento y recuperación de todos Recursos de STU3 se admite, incluida la compatibilidad con elementos de extensión. La API acepta, almacena y muestra extensiones en cualquier elemento de datos.
Todos los métodos de la API de RESTful que usan el tipo de contenido JSON, excepto en los siguientes casos:
- El nivel de tipo y el nivel de sistema historia que recuperan el historial en múltiples recursos no no es compatible. El historial de recursos solo se puede recuperar para un recurso a la vez.
- El batch/transaction interacción no admite operaciones de búsqueda dentro del paquete.
Perfil la validación y la aplicación.
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.
Toda la búsqueda de la aplicación, excepto en los siguientes casos:
- No se admiten los parámetros de búsqueda
Group-characteristic-value
,Sequence-coordinate
,Location-near
,Location-near-distance
,Bundle-composition
yBundle-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 admiteAND
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ámetrosapplication/x-www-form-urlencoded
en el cuerpo de la solicitud - El comodín (
*
) es compatible con_include
, pero no es compatible con_revinclude
- No se admiten los parámetros de búsqueda
Las áreas que no se admiten incluyen lo siguiente:
- Más probable operaciones extendidas no están implementados.
- 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
urn:uuid
referencias en paquetes por lotes
DSTU2
El nombre del servidor declaración de conformidad indica las partes de la especificación que se admiten.
- Almacenamiento y recuperación de todos Recursos de DSTU2 se admite, incluida la compatibilidad con elementos de extensión. La API acepta, almacena y muestra extensiones en cualquier elemento de datos.
- Todos los métodos de la
API de RESTful
que usan el tipo de contenido JSON, excepto en los siguientes casos:
- El nivel de tipo y el nivel de sistema historia que recuperan el historial en múltiples recursos no no es compatible. El historial de recursos solo se puede recuperar para un recurso a la vez.
- El batch/transaction interacción no admite operaciones de búsqueda dentro del paquete.
- Perfil de validación y aplicación.
- Todas las
buscar
de la aplicación, excepto en los siguientes casos:
- No se admiten los parámetros de búsqueda
Group-characteristic-value
,Location-near
,Location-near-distance
,Bundle-composition
,Bundle-message
,Coverage-dependent
yCoverage-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 admiteAND
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ámetrosapplication/x-www-form-urlencoded
en el cuerpo de la solicitud - El comodín (
*
) es compatible con_include
, pero no es compatible con_revinclude
- No se admiten los parámetros de búsqueda
Las áreas que no se admiten incluyen lo siguiente:
- Más probable operaciones extendidas no están implementados.
- 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
urn:uuid
referencias 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 los Datos masivos de FHIR la especificación preliminar.
- 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 paqueteshistory
en la versión v1beta1 para crear versiones históricas de los recursos.