Notas de la versión 2024: Azure Health Data Services
En este artículo se describen las características, mejoras y correcciones de errores publicadas en 2024 para el servicio FHIR®, el servicio DICOM® y el servicio MedTech en Azure Health Data Services.
Noviembre de 2024
Azure Health Data Services
Mejoras en la operación de importación
- Mejoras de registro de errores: durante la operación de importación, el registro de errores ahora notifica los archivos específicos que se han producido un error durante la ingesta en el servicio FHIR. Esta mejora proporciona comentarios más detallados sobre las importaciones con errores.
- Cancelación del trabajo de importación: se identificó un error en el que la cancelación de un trabajo de importación no desencadenó la cancelación de los trabajos secundarios asociados. Este problema se resuelve y, ahora, la cancelación de un trabajo de importación también cancela todos los trabajos secundarios relacionados en el orquestador actual.
- Mejora de la validación de exportación: se encontró un problema en el que las exportaciones continuaron a pesar de los parámetros de búsqueda no válidos. Se implementa un cambio para evitar exportaciones en estas condiciones. Este es el comportamiento predeterminado, pero los clientes pueden invalidarlo con la marca lenienta. El cambio se ha comunicado a los clientes el mes pasado.
- Mejora del rendimiento del lote: el proceso de actualización del perfil durante la ejecución del lote se ha simplificado. Si una agrupación contiene cambios en
ValueSet,StructureDefinitiony/oCodeSystem, no se producirá ninguna actualización del perfil hasta que la agrupación se complete por completo. El cambio mejora el rendimiento de las agrupaciones al reducir los retrasos causados por varias actualizaciones al controlar los cambios en estos tipos de recursos. - Análisis de encabezados de tipo de contenido: se ha solucionado y resuelto un problema relacionado con el análisis del
application/x-www-form-urlencodedencabezado de tipo de contenido. - Mejoras de reindexación: la operación de reindexación se mejora mediante la eliminación de una limitación artificial que anteriormente limitaba el control de grandes conjuntos de datos históricos o los casos en los que los clientes solicitaron un tamaño de consulta limitado. Además, el proceso de reindexación notificaría incorrectamente como "completado" al controlar muchos recursos históricos o eliminados secuenciales con el tamaño de consulta predeterminado. Este problema se ha solucionado para asegurarse de que el proceso de reindexación se completa correctamente e informa del estado adecuado.
Octubre de 2024
Azure Health Data Services
Servicio FHIR
Correcciones de error
- Validación de exportación: se identificó un problema en el que las exportaciones continuaron a pesar de los parámetros de búsqueda no válidos. Estamos introduciendo un cambio que impide las exportaciones en estas condiciones. Esta característica está actualmente detrás de una marca de validación estricta y se convertirá en el comportamiento predeterminado en o después del 30 de octubre.
- Inclusión de parámetros de búsqueda: se ha resuelto un problema por el que los parámetros de búsqueda adicionales (por ejemplo,
_include,_has) no devolvieron todos los resultados esperados y, a veces, se omite el vínculo siguiente. - Ejecución del trabajo de exportación: se ha solucionado una aparición poco frecuente de durante la finalización del
System.ObjectDisposedExceptiontrabajo de exportación evitando las salidas prematuras. - Actualización del código de estado HTTP: el código de estado HTTP para parámetros no válidos durante
$reindexla creación de trabajos ahora se actualiza a 400, lo que garantiza un mejor control de errores. - Limpieza de parámetros de búsqueda: se ha implementado una corrección para garantizar una limpieza completa de los parámetros de búsqueda en la base de datos cuando se desencadena con llamadas API de eliminación, solucionando problemas relacionados con eliminaciones incompletas.
- Problema de ordenación descendente: se ha resuelto un problema por el que las operaciones de ordenación descendente no devolvían recursos si el campo ordenado no tenía datos en la base de datos, incluso cuando existían recursos pertinentes.
- Control de errores de autenticación: se ha agregado un nuevo bloque catch para administrar los errores de autenticación cuando se ejecutan solicitudes de importación con la identidad administrada desactivada.
Septiembre de 2024
Azure Health Data Services
Servicio FHIR
Eficacia mejorada de la exportación
Se ha mejorado la funcionalidad de exportación para optimizar el uso de memoria. Con este cambio, el proceso de exportación ahora inserta datos en Blob Storage un recurso cada vez, lo que reduce el consumo de memoria.
Agosto de 2024
Azure Health Data Services
Servicio FHIR
Control de errores de la operación de importación
- La operación de importación devuelve un error HTTP 400 cuando se ingiere un recurso de parámetro de búsqueda a través del proceso de importación. Este cambio pretende evitar que los parámetros de búsqueda se coloquen en un estado no válido cuando se ingieren con una operación de importación.
- La operación de importación devuelve un código de estado HTTP 400, en lugar del código de estado HTTP 500 anterior, en los casos en los que se producen problemas de configuración con la cuenta de almacenamiento. Esta actualización tiene como objetivo mejorar el control de errores asociado a identidades administradas durante las operaciones de importación.
Julio de 2024
Azure Health Data Services
Servicio FHIR
Permitir que las fechas de los datos JSON se traten como cadenas en la operación Convert-Data
Es posible que las fechas proporcionadas dentro de los datos JSON se devuelvan en un formato diferente al proporcionado. Durante la deserialización de las cadenas de carga JSON identificadas como fechas se convierten en objetos DateTime de .NET. A continuación, estos objetos se convierten en cadenas antes de pasar por el motor de plantillas Liquid. Esta conversión puede hacer que el valor de fecha se vuelva a formatear y represente en la zona horaria local del servicio FHIR.
La coerción de cadenas a objetos DateTime de .NET se puede deshabilitar mediante el parámetro jsonDeserializationTreatDatesAsStringsbooleano . Cuando se establece trueen , los datos proporcionados se tratan como una cadena y no se modificarán antes de proporcionarse al motor liquid.
Mejora de la operación de importación
El servicio FHIR ahora permite la ingesta de datos sin especificar una versión en el nivel de recurso. El orden de los recursos se mantiene con el valor lastUpdated. Esta mejora presenta la marca "allowNegativeVersions". La marca de configuración true permite al servicio FHIR asignar versiones negativas para los registros de recursos con un valor lastUpdated explícito y ninguna versión especificada.
Correcciones de errores
- Se ha corregido la inclusión de recursos eliminados temporalmente al usar _security:no parámetro de búsqueda Cuando se usa el parámetro de búsqueda _security:not en las operaciones de búsqueda, los identificadores de los recursos eliminados temporalmente se incluían en los resultados de la búsqueda. Hemos corregido el problema para que los recursos eliminados temporalmente ahora se excluyen de los resultados de la búsqueda.
- Exportar datos como smart User Exporting data as a SMART user ya no requiere ámbitos de escritura. Anteriormente, era necesario conceder privilegios de "escritura" a un usuario SMART para exportar datos, lo que implicaba niveles de privilegios superiores. Para iniciar un trabajo de exportación como usuario SMART, asegúrese de que el usuario sea miembro del rol de exportación de FHIR en RBAC y solicite el ámbito clínico smart de "lectura". Actualización del código de estado de HTTP 500 a HTTP 400
- Actualización del código de estado de HTTP 500 a HTTP 400 Durante una operación de revisión, si la carga solicitó una actualización para un tipo de recurso distinto del parámetro , inicialmente se produjo un error interno del servidor (HTTP 500). Esto se ha actualizado para producir un error HTTP 400 en su lugar.
Mejora del rendimiento
La optimización de consultas se agrega al buscar recursos de FHIR con un intervalo de datos. Esta optimización de consultas ayuda a realizar consultas eficaces a medida que se genera un CTE combinado.
Mayo de 2024
Azure Health Data Services
Servicio FHIR
Mejora del escalado a la operación de importación
Se ha mejorado la lógica de escalado para las operaciones de importación, lo que permite ejecutar varios trabajos en paralelo. Este cambio afecta a los registros de auditoría de la operación de importación. Los registros de auditoría de los trabajos de importación individuales tienen varias filas, con cada fila correspondiente a un trabajo de procesamiento interno.
Correcciones de error
- Corregido: código de estado HTTP para solicitudes de ejecución prolongada. Las solicitudes FHIR que tardan más de 100 segundos en ejecutar devuelven un código de estado HTTP 408 en lugar de HTTP 500.
- Corregido: solicitud de historial en la agrupación. Antes de la corrección, la solicitud de historial en un paquete devolvió el código de estado HTTP 404.
Convertidor FHIR independiente (versión preliminar)
La API de convertidor de FHIR independiente disponible para la versión preliminar se desacopla del servicio FHIR y se empaqueta como una imagen de contenedor (Docker). Además de permitirle convertir datos del origen de registros a paquetes de FHIR R4, el convertidor de FHIR ofrece:
- Conversión de datos bidireccionales de origen de registro a paquetes de FHIR R4 y vuelta. Por ejemplo, el convertidor de FHIR puede convertir datos del formato FHIR R4 de nuevo al formato HL7v2.
- Experiencia mejorada para la personalización de plantillas liquid predeterminadas.
- Ejemplos que muestran cómo crear una canalización de ETL (extracción, transformación y carga) con Azure Data Factory (ADF).
Para implementar la imagen del contenedor del convertidor de FHIR, consulte el proyecto de GitHub del convertidor de FHIR .
Abril de 2024
Servicio DICOM
Operación Upsert mejorada
La operación Upsert mejorada le permite cargar una imagen DICOM en el servidor y reemplazarla sin problemas si ya existe. Antes de esta mejora, los usuarios tenían que realizar una operación de eliminación seguida de STOW-RS para lograr el mismo resultado. Con la operación Upsert mejorada, la administración de imágenes DICOM es más eficaz y simplificada.
Almacenamiento expandido para los atributos necesarios
El servicio DICOM permite a los usuarios cargar archivos DICOM de hasta 4 GB de tamaño. No se permite que ningún archivo DICOM o combinación de archivos en una sola solicitud supere este límite.
Servicio FHIR
La operación de eliminación masiva está disponible con carácter general.
La operación de eliminación masiva permite la eliminación de recursos de FHIR en distintos niveles, lo que permite a las organizaciones sanitarias cumplir con las directivas de retención de datos al tiempo que proporciona funcionalidades de procesamiento asincrónicas. Las ventajas de la operación de eliminación masiva son:
- Ejecutar eliminación masiva en distintos niveles: la operación de eliminación masiva permite eliminar recursos del servidor FHIR de forma asincrónica. Puede ejecutar la eliminación masiva en distintos niveles:
- Nivel del sistema: habilita la eliminación de recursos de FHIR en todos los tipos de recursos.
- Tipo de recurso individual: permite la eliminación de recursos de FHIR específicos.
- Personalizable: los parámetros de consulta permiten el filtrado de recursos sin procesar para eliminaciones dirigidas.
- Procesamiento asincrónico: la operación es asincrónica y proporciona un punto de conexión de sondeo para realizar un seguimiento del progreso.
Más información:
Marzo de 2024
Servicio DICOM
La integración con Azure Data Lake Storage está disponible con carácter general
La integración de Azure Data Lake Storage para el servicio DICOM en Azure Health Data Services está disponible con carácter general. El servicio DICOM proporciona almacenamiento a escala en la nube para los datos de imágenes médicas mediante el estándar DICOMweb. Con la integración de Azure Data Lake Storage, las organizaciones pueden disfrutar de un control total sobre sus datos de creación de imágenes y una mayor flexibilidad para acceder a esos datos y trabajar con ellos a través del ecosistema y las API de Azure Storage.
Mediante el uso de Azure Data Lake Storage con el servicio DICOM, las organizaciones pueden:
- Habilite el acceso directo a los datos de imágenes médicas almacenados por el servicio DICOM mediante las API de Azure Storage y las API DICOMweb, lo que proporciona más flexibilidad para acceder a los datos y trabajar con ellos.
- Abra datos de creación de imágenes médicas hasta todo el ecosistema de herramientas para trabajar con Azure Storage, como AzCopy, Explorador de Azure Storage y la biblioteca de movimiento de datos.
- Desbloquee nuevos escenarios de análisis e inteligencia artificial y aprendizaje automático mediante servicios que se integran de forma nativa con Azure Data Lake Storage, incluidos Azure Synapse, Azure Databricks, Azure Machine Learning y Microsoft Fabric.
- Conceda controles para administrar permisos de almacenamiento, controles de acceso, niveles y reglas.
Más información:
- Administración de datos de imágenes médicas con el servicio DICOM y Azure Data Lake Storage
- Implementación del servicio DICOM con Azure Data Lake Storage
Servicio FHIR
Paralelización de agrupación (GA)
Las agrupaciones se ejecutan en serie en el servicio FHIR de forma predeterminada. Para mejorar el rendimiento con llamadas de agrupación, habilitamos el procesamiento paralelo.
Más información:
La operación de importación acepta varios tipos de recursos en un solo archivo
La operación de importación permite tener el tipo de recurso por archivo de entrada en los parámetros de solicitud. Con esta funcionalidad de mejora, puede pasar varios tipos de recursos en un solo archivo.
Correcciones de error
Corregido: la operación de importación ingiere recursos con el mismo tipo de recurso y el valor del campo lastUpdated. Antes de este cambio, los recursos ejecutados en un lote con el mismo tipo y
lastUpdatedvalor de campo no se ingerieron en el servicio FHIR. Esta corrección de errores soluciona el problema. Consulte PR#3768.Corregido: búsqueda de FHIR con 3 o más parámetros de búsqueda personalizados. Antes de esta corrección, una consulta de búsqueda de FHIR en la raíz con tres o más parámetros de búsqueda personalizados dio como resultado el código de estado HTTP 504. Consulte PR#3701.
Corregido: Mejora del rendimiento para el procesamiento de agrupación. Actualizaciones del método de ejecución de tareas, lo que permite mejorar el rendimiento del procesamiento de paquetes. Consulte PR#3727.
Febrero de 2024
Servicio FHIR
El recuento de todas las versiones de recursos está habilitada
El parámetro _summary=count de consulta y _count=0 se puede agregar al _history punto de conexión para obtener un recuento de todos los recursos con versiones. Este recuento incluye recursos históricos y eliminados temporalmente.
La búsqueda revinclude puede hacer referencia a todos los recursos con carácter comodín
El servicio FHIR admite búsquedas con caracteres comodín con revinclude. Agregue *.* al parámetro de consulta en una revinclude consulta para dirigir el servicio FHIR para hacer referencia a todos los recursos asignados al recurso de origen.
Correcciones de error
Corregido: mejora del tiempo de respuesta de las consultas de FHIR con mejoras de rendimiento. Para mejorar el rendimiento, se puede especificar un modificador que falta para un parámetro de búsqueda que se usa para la ordenación. Consulte PR#3655.
Corregido: la operación de importación respeta la ingesta de versiones de recursos no secuenciales. Antes de este cambio, el modo incremental en la operación presupone que las
importversiones son enteros secuenciales. Después de esta corrección de errores, las versiones se pueden ingerir en orden no quential. Consulte PR#3685.
Enero de 2024
Servicio DICOM
Actualización masiva de archivos
La operación de actualización masiva permite cambiar los metadatos de creación de imágenes para varios archivos almacenados en el servicio DICOM. Por ejemplo, la actualización masiva permite modificar atributos DICOM para uno o varios estudios en una sola operación asincrónica. Puede usar una API para realizar actualizaciones de los datos demográficos de los pacientes y evitar el costo de repetir cargas que consumen mucho tiempo.
Más allá de las mejoras de eficiencia, la funcionalidad de actualización masiva conserva un registro de los cambios en la fuente de cambios y conserva las instancias originales y sin modificar para la recuperación futura.
Más información:
Servicio FHIR
Parámetros de búsqueda seleccionables (versión preliminar)
La funcionalidad de parámetro de búsqueda seleccionable disponible para la versión preliminar le permite personalizar y optimizar las búsquedas en los recursos de FHIR. La funcionalidad le permite elegir qué parámetros de búsqueda integrados habilitar o deshabilitar para el servicio FHIR. Al habilitar solo los parámetros de búsqueda que necesita, puede almacenar más recursos de FHIR y mejorar potencialmente el rendimiento de las consultas de búsqueda de FHIR.
Más información:
Integración del servicio FHIR con Azure Active Directory B2C
Las organizaciones sanitarias pueden usar el servicio FHIR en Azure Health Data Services con Azure Active Directory B2C (Azure AD B2C). Las organizaciones obtienen una manera segura y cómoda de conceder acceso al servicio FHIR con un control de acceso específico para distintos usuarios o grupos, sin crear o venir cuentas de usuario en el inquilino de Microsoft Entra ID de su organización. Con esta integración, las organizaciones pueden:
- Use proveedores de identidades adicionales para autenticar y acceder a los recursos de FHIR con ámbitos de SMART on FHIR.
- Administre y personalice los derechos o permisos de acceso de usuario con ámbitos smart on FHIR que admiten el control de acceso específico, los tipos de recursos y las interacciones de FHIR, y los privilegios subyacentes de un usuario.
Contenido relacionado:
- Uso de Azure Active Directory B2C para conceder acceso al servicio FHIR
- Configuración de varios proveedores de identidades de servicio para el servicio FHIR
- Solución de problemas de configuración del proveedor de identidades para el servicio FHIR
- Habilitación de SMART on FHIR para el servicio FHIR
- Ejemplo: Azure ONC (g)(10) SMART on FHIR
Solicitar hasta 100 TB de almacenamiento
El servicio FHIR puede almacenar e intercambiar grandes cantidades de datos de mantenimiento, y cada instancia de servicio de FHIR tiene un límite de almacenamiento de 4 TB de forma predeterminada. Si tiene más datos, puede pedir a Microsoft que aumente el almacenamiento hasta 100 TB para el servicio FHIR.
Con más almacenamiento, las organizaciones pueden controlar grandes conjuntos de datos para habilitar escenarios de análisis. Por ejemplo, puede usar más almacenamiento para administrar el estado de la población, realizar investigaciones y obtener nuevas conclusiones de los datos de salud. Además, más almacenamiento permite a los clientes de Azure API for FHIR tener datos de gran volumen (más de 4 TB) para migrar al servicio FHIR en Azure Health Data Services.
Para solicitar almacenamiento superior a 4 TB, cree una solicitud de soporte técnico en Azure Portal y use el tipo de problema Servicio y límite de suscripción (cuotas).
Nota:
Debido a un problema con las métricas de facturación para el almacenamiento, los clientes que opten por más de 4 TB de capacidad de almacenamiento no se facturarán por el almacenamiento hasta que se resuelva el problema.