FHIR EN AZURE

HL7 FHIR (Fast Healthcare Interoperability Resources) es un estándar abierto para la interoperabilidad de la atención médica. Microsoft contribuye con entusiasmo a FHIR y a la comunidad de estándares de salud, desde el desarrollo de servidores de código abierto, herramientas y bibliotecas hasta el alojamiento de servicios administrados en Azure, así como el evangelismo técnico y el desarrollo de especificaciones básicas.

De vez en cuando en este blog, nuestro equipo compartirá pensamientos, desafíos de diseño y progreso de implementación con la comunidad para transparencia y comentarios. La publicación de hoy es la primera entrega, que se centra en los próximos cambios en las suscripciones de FHIR.

A medida que crece la adopción de FHIR, la comunidad comienza a abordar flujos de trabajo más complejos. Crítico en muchos de estos flujos de trabajo es la capacidad de enviar notificaciones a los clientes en función de las acciones que ocurren dentro de un servidor. Un mecanismo para administrar las notificaciones de eventos a los clientes es el recurso de suscripción incorporado de FHIR. En la próxima versión de FHIR (R5), hay un rediseño significativo del recurso de Suscripción y los mecanismos de notificaciones a su alrededor.

El rediseño introduce la capacidad de los servidores de enviar notificaciones que incluyen referencias (por ID de recurso) o el contenido completo de los recursos involucrados en un evento. A medida que el nuevo diseño ha madurado, hemos tenido discusiones en profundidad de la comunidad sobre lo que debe incluirse en las notificaciones y a continuación se presenta un resumen de los resultados.

Como contexto, en esencia, una Suscripción genera notificaciones sobre cambios de estado. Un cambio de estado implica dos visiones del mundo: el estado anterior al cambio, al que me referiré como el estado "anterior", y el estado posterior al cambio, al que me referiré como el estado "actual". Al considerar un servidor RESTful (p. Ej., Un servidor FHIR), los cambios de estado se pueden clasificar en tres grupos: crear, eliminar y actualizar (el CUD en CRUD, ya que las lecturas no cambian de estado).

Las operaciones de creación son las más sencillas: solo hay un estado útil porque el estado anterior era inexistente. Un implementador puede asumir que cualquier información se refiere al estado actual y cualquier estructura de notificación se puede completar a gusto del servidor. Intentar incluir datos del estado anterior simplemente no tiene sentido. Con eso en mente, la "mejor" oferta de un servidor es incluir datos (ID, recurso o gráfico) basados ​​en el estado actual del mundo.

Las operaciones de eliminación parecen creadas al principio: el estado anterior es el único válido, por lo que cualquier información debería extraerse de ella. Lamentablemente, no es tan simple. Por ejemplo, si un recurso se eliminó por razones de privacidad, un servidor no debería transmitirlo. Además, enviar un recurso después de que se haya eliminado no es coherente con lo que ve un cliente cuando consulta un servidor. Por otro lado, un cliente que intenta descubrir qué recurso se eliminó (por ejemplo, determinar un paciente perdido del servidor) es una operación costosa y debe evitarse. Dadas todas estas preocupaciones, considero el "mejor" comportamiento para que un servidor incluya la identificación de un recurso eliminado, pero no el contenido real.

Las operaciones de actualización son las más complicadas: tanto el estado anterior como el actual son generalmente válidos, y ambos son potencialmente útiles (por ejemplo, un cliente puede determinar fácilmente los detalles de una actualización). Aquí, hay tres áreas principales a considerar. Primero, puede haber problemas de privacidad, seguridad o seguridad similares a las operaciones de eliminación; los estados no válidos no deben transmitirse. En segundo lugar, si un cliente necesita hacer comparaciones, puede almacenar en caché los datos en una tienda local o emitir solicitudes de recursos FHIR versionadas como seguimiento. Finalmente, exigir a los servidores que extraigan recursos o gráficos del estado anterior tiene importantes implicaciones de rendimiento y diseño: las notificaciones no se pueden procesar fuera de banda ya que necesitan datos de ambos estados en torno a la actualización. Considerado todo, creo que la "mejor" oferta de un servidor durante una actualización es extraer ID, recursos o gráficos del estado actual del sistema; cualquier persona que necesite un estado anterior debería ocuparse de eso por su cuenta (por ejemplo, emitiendo historial o llamadas de API de lectura versionada).

Hay un problema más que me gustaría abordar, que es la posibilidad de que falten estados intermedios. Hay varios escenarios en los que esto es posible: actualizaciones de alta frecuencia de un recurso, respaldo de la cola de procesamiento del servidor, tiempos de transmisión a los clientes, etc.

Referencias

https://azure.microsoft.com/en-in/services/azure-api-for-fhir/

https://www.getcirrus.com/his?utm_source=GoogleAds&utm_medium=cpc&utm_campaign=Search%20-%20Hospitales%20(Mex)&utm_term=hl7&ads_cmpid=1598009439&ads_adid=77803753672&ads_matchtype=b&ads_network=g&ads_creative=406680232287&utm_term=hl7&ads_targetid=kwd-295589319747&utm_campaign=&utm_source=adwords&utm_medium=ppc&ttv=2&gclid=Cj0KCQiAgebwBRDnARIsAE3eZjRnfKN40DrICzWID7JrqaXEkyfs77ScGxy-IwE2rKoI_3Up0Szw3nYaArUJEALw_wcB


https://cloudblogs.microsoft.com/opensource/2020/01/07/fhir-subscriptions-state-changes/?amp=1&fbclid=IwAR3y4w8MJe7YQNuyEdd2An_Gzm1v85HdvlKDUoS1y5JZzv--LKFDb4xMT70