Preguntas más frecuentes sobre Azure API for 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 la versión R4 y la versión anterior STU3 (Standard for Trial Use 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 Microsoft Azure Active Directory como proveedor de identidades.

No, no se admite B2C en Azure API for FHIR. Si necesita controles de acceso más pormenorizados, se recomienda examinar el proxy FHIR de código abierto.

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 la 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.

El Conector de Azure IoT para FHIR (versión preliminar) admite actualmente la versión R4 de FHIR y solo es visible en instancias de R4 de Azure API for FHIR.

Azure API for FHIR es un servicio de FHIR administrado disponible con carácter general. Azure Health Data Services permite implementar un servicio FHIR y un servicio DICOM en la misma área de trabajo. En la introducción a Azure Health Data Services se proporcionan más detalles.

Azure API for FHIR es una versión hospedada y administrada de Microsoft FHIR Server for Azure de código abierto. En el servicio administrado, Microsoft proporciona todo el mantenimiento y las actualizaciones.

Al ejecutar FHIR Server para Azure, tiene acceso directo a los servicios subyacentes, pero también es responsable de mantener y actualizar el servidor y todo el trabajo de cumplimiento requerido si almacena datos de PHI.

Actualmente, tenemos disponibilidad general tanto para el público como para la administración pública en varias regiones geográficas. Para información sobre los servicios en la nube de la administración pública de 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 obtener 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 estén en la página de versión en código abierto. También se han incluido instrucciones sobre cómo probar la compilación si se quiere probar en el entorno propio.

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

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

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 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. Al crear una aplicación SMART on FHIR, puede garantizar que una gran cantidad de sistemas diferentes pueden acceder a la aplicación y aprovecharla. Para obtener más información sobre SMART, visite el sitio web de SMART Health IT.

Sí, se admite la funcionalidad SMART on FHIR mediante ejemplos de AHDS. Esto se conoce como SMART on FHIR(Enhanced). SMART on FHIR(Enhanced) se puede considerar para cumplir los requisitos con la Guía de implementación de SMART on FHIR (v 1.0.0) y §170.315(g)(10) API estandarizada para criterios de pacientes y servicios de población. Para obtener más información, visite la 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 la 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 el conjunto de que solo se mostrarán 1000 registros.

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

Actualmente se admite la publicación de conjuntos por lotes, pero no la de conjuntos 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 permite obtener todos los recursos relacionados con un paciente determinado. Tenga en cuenta que de momento un compartimiento incluye todos los recursos relacionados con el paciente, pero no al propio paciente, por lo que también hay que buscar para obtener el paciente si se necesita ese recurso en los resultados.

Se admite la ordenación por la fecha de la última actualización: _sort=_lastUpdated. También se admiten _sort en los elementos FirstName, LastName, BirthDate y ClinicalDate. Para más información sobre otros parámetros de búsqueda admitidos, consulte la página de características admitidas.

Sí, admitimos patient-$everything. Para obtener más información, consulte la guía paso a paso para Patient-$Everything.

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

$export forma parte de la especificación de FHIR. Si el servicio FHIR se configura con una identidad administrada y una cuenta de almacenamiento, y si la identidad administrada tiene acceso a esa cuenta de almacenamiento, puede llamar simplemente 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 no identificada.

La exportación anonimizada solo se admite actualmente en caso de exportación completa del sistema (/$export), no de exportación de pacientes (/Patient/$export). Se está trabajando para que también esté disponible en el nivel de paciente.

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

• Con Delete, puede optar por realizar una eliminación temporal (tipo más común) y poder 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 parámetro hardDelete, todos los registros y el historial se eliminan y no se pueden recuperar.

Puede recuperar archivos eliminados si no usa el parámetro hardDelete. Los registros de Azure API for FHIR deberían seguir existiendo. 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 quiere 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 todavía tiene problemas, envíe 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 se encuentra por debajo de este valor mínimo.

Hay una colección de arquitecturas de referencia disponible en la página de GitHub de arquitectura sanitaria.

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. Respuesta de 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 de 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.