Preguntas más frecuentes sobre Azure API for FHIR

Azure API for FHIR: Conceptos básicos

¿Qué es FHIR?

Recursos Rápidos de Interoperabilidad en Salud (FHIR, pronunciado como "fire" en inglés) es un estándar de interoperabilidad diseñado para permitir el intercambio de datos del sector sanitario entre diferentes sistemas sanitarios. Este estándar fue desarrollado por la organización HL7 y lo adoptan organizaciones del sector sanitario de todo el mundo. La versión más reciente de FHIR disponible es la R4 (versión 4). Azure API for FHIR admite R4 y la versión anterior STU3 (estándar para uso de prueba 3). Para más información sobre FHIR, visite HL7.org.

¿Están los datos detrás de las API de FHIR almacenados en Azure?

Sí, los datos se almacenan en bases de datos administradas en Azure. Azure API for FHIR no proporciona acceso directo al almacén de datos subyacente.

¿Cómo se puede obtener acceso a los datos subyacentes?

En el servicio administrado, no puede acceder a los datos subyacentes. Esto es para asegurarse de que Azure API for FHIR ofrece las certificaciones de privacidad y cumplimiento necesarias para los datos sanitarios. Si necesita acceso a los datos subyacentes, puede usar el servidor FHIR de código abierto.

¿Qué proveedor de identidades admite?

Se admite el identificador de Entra de Microsoft como proveedor de identidades.

¿Cuál es la directiva de copia de seguridad y recuperación para Azure API for FHIR?

Se realiza una copia de seguridad de los datos del servicio administrado automáticamente cada 4 horas y se mantienen dos copias de seguridad. Por lo tanto, la duración de retención es de 8 horas. El equipo de soporte técnico realiza la recuperación de datos y el objetivo de punto de recuperación (RPO) es inferior a 240 minutos.

Los clientes pueden realizar una solicitud para restaurar los datos o cambiar la directiva de copia de seguridad de datos predeterminada a través de una incidencia de soporte técnico.

¿Qué versión de FHIR admite?

Se admiten las versiones 4.0.0 y 3.0.1. Para obtener más información, consulte las características admitidas de FHIR. Lea sobre lo que ha cambiado entre las versiones de FHIR (es decir, de STU3 a R4) en el historial de versiones de HL7 STU3.

Actualmente, el conector de Azure IoT para FHIR (versión preliminar) solo admite la versión R4 de FHIR y está visible en instancias de R4 de Azure API for FHIR.

¿En qué regiones está disponible Azure API for FHIR?

Tenemos disponibilidad general para el público y el gobierno en varias regiones geográficas. Para obtener información sobre los servicios en la nube gubernamentales en Microsoft, consulte Servicios de Azure de FedRAMP.

¿Dónde puedo ver qué se publica en Azure API for FHIR?

La página de notas de la versión proporciona información general sobre todo lo que se ha enviado al servicio administrado en el mes anterior.

Para más información sobre lo que se publica en Azure API for FHIR, consulte las versiones del servidor FHIR de código abierto. Hemos trabajado para etiquetar elementos con Azure-API-for-FHIR si se liberarán en el servicio administrado y normalmente estarán disponibles dos semanas después de que se encuentren en la página de versión en código abierto. También hemos incluido instrucciones sobre cómo probar la compilación si quiere probar en su propio entorno.

Para ver qué paquete de versión está actualmente en el servicio administrado, puede ver la instrucción de funcionalidad de Azure API for FHIR en la software.version propiedad . Verá qué paquete se implementa.

¿Dónde puedo encontrar qué versión de FHIR (es decir, R4/STU3) se ejecuta en mi base de datos?

Puede encontrar la versión exacta de FHIR expuesta en la instrucción de funcionalidad en la fhirVersion propiedad .

¿Puedo cambiar mi instancia de Azure API for FHIR de STU3 a R4?

No. No tenemos una manera de cambiar la versión de una base de datos existente. Deberá crear una nueva INSTANCIA de Azure API for FHIR y volver a cargar los datos. Puede aprovechar el convertidor JSON a FHIR como un lugar para empezar con la conversión de datos STU3 en R4.

¿Puedo personalizar la dirección URL de mi INSTANCIA de Azure API for FHIR?

No. No se puede cambiar la dirección URL de Azure API for FHIR.

Implementaciones y especificaciones de FHIR

¿Qué es SMART on FHIR?

SMART (Substitutable Medical Applications and Reusable Technology) on FHIR es un conjunto de especificaciones de código abierto para integrar aplicaciones de asociados con servidores de FHIR y otros sistemas de TI sanitarios, como los registros sanitarios electrónicos y los intercambios de información sanitaria. Mediante la creación de una aplicación SMART on FHIR, puede asegurarse de que se pueda acceder a la aplicación y aprovecharla mediante una gran cantidad de sistemas diferentes. Para obtener más información sobre SMART, visite el sitio web de TI de SMART Health .

¿Azure API for FHIR admite SMART on FHIR?

Sí, la funcionalidad SMART on FHIR se admite mediante ejemplos de AHDS. Esto se conoce como SMART on FHIR(Enhanced). SMART on FHIR (mejorado) puede ser la opción idónea para cumplir los requisitos de la Guía de implementación de SMART on FHIR (v 1.0.0) y del criterio §170.315(g)(10) Standardized API for patient and population services. Para obtener más información, visite SMART on FHIR(Enhanced) Documentation (Documentación de SMART on FHIR(Enhanced).

¿Puedo crear un recurso personalizado de FHIR?

No se permiten recursos de FHIR personalizados. Si necesita un recurso FHIR personalizado, puede crear un recurso personalizado sobre el recurso básico con extensiones.

¿Se admiten extensiones en Azure API for FHIR?

Está permitido cargar datos JSON de FHIR válidos en el servidor. Si desea almacenar la definición de estructura que define la extensión, puede guardarla como un recurso de definición de estructura. Para buscar en extensiones, deberá definir sus propios parámetros de búsqueda.

¿Cuál es el límite del tamaño de un recurso que puedo cargar?

El recurso debe estar justo por debajo de 2 MB. Se trata de una limitación del almacén de datos subyacente y no podemos aumentar este valor.

¿Cómo veo Azure API for FHIR en XML?

En el servicio administrado, solo se admite JSON. El servidor FHIR de código abierto admite JSON y XML. Para ver la versión XML en código abierto, use _format= application/fhir+xml.

¿Cuál es el límite en recuento?

El límite actual de "_count" es 1000. Si establece _count en más de 1000, recibirá una advertencia en la agrupación que solo se mostrarán 1000 registros.

¿Existen limitaciones en la funcionalidad De exportación de grupos?

Para la exportación de grupos, solo exportamos las referencias incluidas del grupo y no todas las características del recurso de grupo.

¿Puedo publicar una agrupación en Azure API for FHIR?

Actualmente se admite la publicación de agrupaciones por lotes, pero no se admite la contabilización de agrupaciones de transacciones en Azure API for FHIR. Puede usar el servicio FHIR en Azure Health Data Services si necesita compatibilidad con la agrupación de transacciones.

¿Cómo puedo obtener todos los recursos de un único paciente en Azure API for FHIR?

Puede usar la operación Patient-$everything o puede usar una búsqueda de compartimiento en Azure API for FHIR. Esto le permite obtener todos los recursos relacionados con un paciente específico. Tenga en cuenta que el compartimiento del paciente incluye todos los recursos relacionados con el paciente, pero no el propio paciente, por lo que deberá buscar también para obtener el paciente si necesita el recurso del paciente en sus resultados.

¿Cuál es la ordenación predeterminada al buscar recursos en Azure API for FHIR?

Se admite la ordenación por la fecha actualizada por última vez: _sort=_lastUpdated. También se admiten _sort en los elementos FirstName, LastName, BirthDate y ClinicalDate. Para obtener más información sobre otros parámetros de búsqueda admitidos, consulte Introducción a la búsqueda de FHIR.

¿Admite Azure API for FHIR $everything?

Sí, tenemos soporte para pacientes $everything. Para obtener más información, consulte la guía de procedimientos para pacientes $Everything.

¿Azure API for FHIR admite operaciones de terminología?

No, Azure API for FHIR no admite actualmente operaciones de terminología.

¿Cómo funciona $export?

$export forma parte de la especificación FHIR. Si el servicio FHIR está configurado con una identidad administrada y una cuenta de almacenamiento, y si la identidad administrada tiene acceso a esa cuenta de almacenamiento, puede llamar a $export en la API de FHIR y todos los recursos de FHIR se exportarán a la cuenta de almacenamiento. Para obtener más información, consulte el artículo $export.

¿Hay alguna solución lista para identificar datos de EHR?

Tenemos una herramienta de código abierto para desidentificar datos de FHIR. La misma tecnología también se integra en Azure API for FHIR en forma de exportación desidentificado .

¿También está disponible la exportación desidentificado en el nivel paciente y grupo?

Actualmente, la exportación anonimizada solo se admite en una exportación completa del sistema (/$export) y no para la exportación de pacientes (/Paciente/$export). Estamos trabajando para que también esté disponible en el nivel paciente.

¿Cuáles son las diferencias entre los tipos de eliminación en Azure API for FHIR?

Hay dos tipos básicos de eliminación admitidos en Azure API for FHIR. Estas son Delete y Conditional Delete.

• Con Delete, puede optar por realizar una eliminación temporal (tipo más común) y seguir pudiendo recuperar versiones históricas del registro.
• Con la eliminación condicional, puede pasar un criterio de búsqueda para eliminar un recurso de un elemento cada vez o varios a la vez.
• Con Delete o Conditional Delete, si ha pasado el hardDelete parámetro , todos los registros y el historial se eliminan y no se pueden recuperar.

¿Cómo se recuperan los registros eliminados en Azure API for FHIR?

Puede recuperar archivos eliminados si no usa el hardDelete parámetro . Los registros de Azure API for FHIR deben existir. Los registros se pueden encontrar realizando una búsqueda de historial en el recurso y buscando la última versión con datos.

Uso de Azure API for FHIR

¿Cómo se habilita Log Analytics para Azure API for FHIR?

Para más información sobre cómo habilitar registros de auditoría y consultas de ejemplo, consulte Habilitación del registro de diagnóstico en Azure API for FHIR. Si desea incluir información adicional en los registros, consulte uso de encabezados HTTP personalizados.

Obtengo 429s al cargar y actualizar datos. ¿Cómo puedo resolver esto?

Para resolverlo, puede aumentar el rendimiento o cambiar al escalado automático para asegurarse de que tiene suficiente proceso para procesar las solicitudes. Si sigue teniendo problemas, abra una incidencia de soporte técnico.

¿Cómo se reducen mis RU y no puedo y las RU son superiores a las que las he establecido?

El valor mínimo de RU debe ser de al menos 40 RU por GB. A medida que carga datos, las RU de la base de datos aumentarán si está por debajo de este valor mínimo.

¿Dónde puedo ver algunos ejemplos de uso de Azure API for FHIR dentro de un flujo de trabajo?

Tenemos una colección de arquitecturas de referencia disponibles en la página de GitHub Arquitectura de mantenimiento.

Características y servicios de Azure API for FHIR

¿Puedo realizar comprobaciones de estado en el servicio FHIR?

Para realizar la comprobación de estado en el servicio FHIR, escriba {{fhirurl}}/health/check en la solicitud GET. Debería poder ver el estado del servicio FHIR. La respuesta del código de estado HTTP con 200 y OverallStatus como "Correcto" en respuesta significa que la comprobación de estado se realiza correctamente. En caso de errores, recibirá una respuesta de error con el código de estado HTTP 404 (no encontrado) o el código de estado 500 (error interno del servidor) e información detallada en el cuerpo de la respuesta en algunos escenarios.

¿Hay alguna manera de cifrar mis datos mediante mi clave personal y no una clave predeterminada?

Sí, Azure API for FHIR permite configurar claves administradas por el cliente, aprovechando la compatibilidad con Azure Cosmos DB. Para obtener más información sobre cómo cifrar los datos con una clave personal, consulte Configuración de claves administradas por el cliente en REST.

¿Qué debo hacer si no puedo eliminar un recurso de FHIR debido a su estado de aprovisionamiento?

Compruebe si la recuperación ante desastres está habilitada para el recurso de FHIR. Si es así, deshabilite la característica de recuperación ante desastres.

¿Qué debo hacer si recibo el código de estado HTTP 429 del servicio Azure API for FHIR?

Compruebe el consumo de RU asociado a la instancia de FHIR. En el caso de un consumo elevado de RU (alrededor de 100%), compruebe si el error de limitación corresponde al tiempo de uso elevado de RU. Si es así, considere la posibilidad de habilitar el escalado automático para el servicio y aumentar la RU asignada al servicio. Consulte Escalado automático de Azure API for FHIR para más información.

Recursos Rápidos de Interoperabilidad en Salud (FHIR, pronunciado como "fire" en inglés) es un estándar de interoperabilidad diseñado para permitir el intercambio de datos del sector sanitario entre diferentes sistemas sanitarios. Este estándar fue desarrollado por la organización HL7 y lo adoptan organizaciones del sector sanitario de todo el mundo. La versión más reciente de FHIR disponible es la R4 (versión 4). Azure API for FHIR admite R4 y la versión anterior STU3 (estándar para uso de prueba 3). Para más información sobre FHIR, visite HL7.org.

Sí, los datos se almacenan en bases de datos administradas en Azure. Azure API for FHIR no proporciona acceso directo al almacén de datos subyacente.

En el servicio administrado, no puede acceder a los datos subyacentes. Esto es para asegurarse de que Azure API for FHIR ofrece las certificaciones de privacidad y cumplimiento necesarias para los datos sanitarios. Si necesita acceso a los datos subyacentes, puede usar el servidor FHIR de código abierto.

Se admite el identificador de Entra de Microsoft como proveedor de identidades.

Se realiza una copia de seguridad de los datos del servicio administrado automáticamente cada 4 horas y se mantienen dos copias de seguridad. Por lo tanto, la duración de retención es de 8 horas. El equipo de soporte técnico realiza la recuperación de datos y el objetivo de punto de recuperación (RPO) es inferior a 240 minutos.

Los clientes pueden realizar una solicitud para restaurar los datos o cambiar la directiva de copia de seguridad de datos predeterminada a través de una incidencia de soporte técnico.

Se admiten las versiones 4.0.0 y 3.0.1. Para obtener más información, consulte las características admitidas de FHIR. Lea sobre lo que ha cambiado entre las versiones de FHIR (es decir, de STU3 a R4) en el historial de versiones de HL7 STU3.

Actualmente, el conector de Azure IoT para FHIR (versión preliminar) solo admite la versión R4 de FHIR y está visible en instancias de R4 de Azure API for FHIR.

Tenemos disponibilidad general para el público y el gobierno en varias regiones geográficas. Para obtener información sobre los servicios en la nube gubernamentales en Microsoft, consulte Servicios de Azure de FedRAMP.

La página de notas de la versión proporciona información general sobre todo lo que se ha enviado al servicio administrado en el mes anterior.

Para más información sobre lo que se publica en Azure API for FHIR, consulte las versiones del servidor FHIR de código abierto. Hemos trabajado para etiquetar elementos con Azure-API-for-FHIR si se liberarán en el servicio administrado y normalmente estarán disponibles dos semanas después de que se encuentren en la página de versión en código abierto. También hemos incluido instrucciones sobre cómo probar la compilación si quiere probar en su propio entorno.

Para ver qué paquete de versión está actualmente en el servicio administrado, puede ver la instrucción de funcionalidad de Azure API for FHIR en la software.version propiedad . Verá qué paquete se implementa.

Puede encontrar la versión exacta de FHIR expuesta en la instrucción de funcionalidad en la fhirVersion propiedad .

No. No tenemos una manera de cambiar la versión de una base de datos existente. Deberá crear una nueva INSTANCIA de Azure API for FHIR y volver a cargar los datos. Puede aprovechar el convertidor JSON a FHIR como un lugar para empezar con la conversión de datos STU3 en R4.

No. No se puede cambiar la dirección URL de Azure API for FHIR.

SMART (Substitutable Medical Applications and Reusable Technology) on FHIR es un conjunto de especificaciones de código abierto para integrar aplicaciones de asociados con servidores de FHIR y otros sistemas de TI sanitarios, como los registros sanitarios electrónicos y los intercambios de información sanitaria. Mediante la creación de una aplicación SMART on FHIR, puede asegurarse de que se pueda acceder a la aplicación y aprovecharla mediante una gran cantidad de sistemas diferentes. Para obtener más información sobre SMART, visite el sitio web de TI de SMART Health .

Sí, la funcionalidad SMART on FHIR se admite mediante ejemplos de AHDS. Esto se conoce como SMART on FHIR(Enhanced). SMART on FHIR (mejorado) puede ser la opción idónea para cumplir los requisitos de la Guía de implementación de SMART on FHIR (v 1.0.0) y del criterio §170.315(g)(10) Standardized API for patient and population services. Para obtener más información, visite SMART on FHIR(Enhanced) Documentation (Documentación de SMART on FHIR(Enhanced).

No se permiten recursos de FHIR personalizados. Si necesita un recurso FHIR personalizado, puede crear un recurso personalizado sobre el recurso básico con extensiones.

Está permitido cargar datos JSON de FHIR válidos en el servidor. Si desea almacenar la definición de estructura que define la extensión, puede guardarla como un recurso de definición de estructura. Para buscar en extensiones, deberá definir sus propios parámetros de búsqueda.

El recurso debe estar justo por debajo de 2 MB. Se trata de una limitación del almacén de datos subyacente y no podemos aumentar este valor.

En el servicio administrado, solo se admite JSON. El servidor FHIR de código abierto admite JSON y XML. Para ver la versión XML en código abierto, use _format= application/fhir+xml.

El límite actual de "_count" es 1000. Si establece _count en más de 1000, recibirá una advertencia en la agrupación que solo se mostrarán 1000 registros.

Para la exportación de grupos, solo exportamos las referencias incluidas del grupo y no todas las características del recurso de grupo.

Actualmente se admite la publicación de agrupaciones por lotes, pero no se admite la contabilización de agrupaciones de transacciones en Azure API for FHIR. Puede usar el servicio FHIR en Azure Health Data Services si necesita compatibilidad con la agrupación de transacciones.

Puede usar la operación Patient-$everything o puede usar una búsqueda de compartimiento en Azure API for FHIR. Esto le permite obtener todos los recursos relacionados con un paciente específico. Tenga en cuenta que el compartimiento del paciente incluye todos los recursos relacionados con el paciente, pero no el propio paciente, por lo que deberá buscar también para obtener el paciente si necesita el recurso del paciente en sus resultados.

Se admite la ordenación por la fecha actualizada por última vez: _sort=_lastUpdated. También se admiten _sort en los elementos FirstName, LastName, BirthDate y ClinicalDate. Para obtener más información sobre otros parámetros de búsqueda admitidos, consulte Introducción a la búsqueda de FHIR.

Sí, tenemos soporte para pacientes $everything. Para obtener más información, consulte la guía de procedimientos para pacientes $Everything.

No, Azure API for FHIR no admite actualmente operaciones de terminología.

$export forma parte de la especificación FHIR. Si el servicio FHIR está configurado con una identidad administrada y una cuenta de almacenamiento, y si la identidad administrada tiene acceso a esa cuenta de almacenamiento, puede llamar a $export en la API de FHIR y todos los recursos de FHIR se exportarán a la cuenta de almacenamiento. Para obtener más información, consulte el artículo $export.

Tenemos una herramienta de código abierto para desidentificar datos de FHIR. La misma tecnología también se integra en Azure API for FHIR en forma de exportación desidentificado .

Actualmente, la exportación anonimizada solo se admite en una exportación completa del sistema (/$export) y no para la exportación de pacientes (/Paciente/$export). Estamos trabajando para que también esté disponible en el nivel paciente.

Hay dos tipos básicos de eliminación admitidos en Azure API for FHIR. Estas son Delete y Conditional Delete.

• Con Delete, puede optar por realizar una eliminación temporal (tipo más común) y seguir pudiendo recuperar versiones históricas del registro.
• Con la eliminación condicional, puede pasar un criterio de búsqueda para eliminar un recurso de un elemento cada vez o varios a la vez.
• Con Delete o Conditional Delete, si ha pasado el hardDelete parámetro , todos los registros y el historial se eliminan y no se pueden recuperar.

Puede recuperar archivos eliminados si no usa el hardDelete parámetro . Los registros de Azure API for FHIR deben existir. Los registros se pueden encontrar realizando una búsqueda de historial en el recurso y buscando la última versión con datos.

Para más información sobre cómo habilitar registros de auditoría y consultas de ejemplo, consulte Habilitación del registro de diagnóstico en Azure API for FHIR. Si desea incluir información adicional en los registros, consulte uso de encabezados HTTP personalizados.

Para resolverlo, puede aumentar el rendimiento o cambiar al escalado automático para asegurarse de que tiene suficiente proceso para procesar las solicitudes. Si sigue teniendo problemas, abra una incidencia de soporte técnico.

El valor mínimo de RU debe ser de al menos 40 RU por GB. A medida que carga datos, las RU de la base de datos aumentarán si está por debajo de este valor mínimo.

Tenemos una colección de arquitecturas de referencia disponibles en la página de GitHub Arquitectura de mantenimiento.

Para realizar la comprobación de estado en el servicio FHIR, escriba {{fhirurl}}/health/check en la solicitud GET. Debería poder ver el estado del servicio FHIR. La respuesta del código de estado HTTP con 200 y OverallStatus como "Correcto" en respuesta significa que la comprobación de estado se realiza correctamente. En caso de errores, recibirá una respuesta de error con el código de estado HTTP 404 (no encontrado) o el código de estado 500 (error interno del servidor) e información detallada en el cuerpo de la respuesta en algunos escenarios.

Sí, Azure API for FHIR permite configurar claves administradas por el cliente, aprovechando la compatibilidad con Azure Cosmos DB. Para obtener más información sobre cómo cifrar los datos con una clave personal, consulte Configuración de claves administradas por el cliente en REST.

Compruebe si la recuperación ante desastres está habilitada para el recurso de FHIR. Si es así, deshabilite la característica de recuperación ante desastres.

Compruebe el consumo de RU asociado a la instancia de FHIR. En el caso de un consumo elevado de RU (alrededor de 100%), compruebe si el error de limitación corresponde al tiempo de uso elevado de RU. Si es así, considere la posibilidad de habilitar el escalado automático para el servicio y aumentar la RU asignada al servicio. Consulte Escalado automático de Azure API for FHIR para más información.