¿Por qué usar una fachada de API FHIR?
Hay muchas razones para que su solución de software se comunique con otras. Entre la interacción con otras aplicaciones y la ampliación de su solución con nuevos módulos, su solución necesita compartir datos y realizar operaciones a través de solicitudes externas. Una forma habitual de lograrlo es proporcionar una API (Interfaz de Programación de Aplicaciones). Además, si desea que su aplicación se comunique con fluidez con todos los demás sin contratar intérpretes costosos, debería ceñirse a la API estándar, que es la API FHIR. Los desarrolladores experimentados de nuevas tecnologías sanitarias piensan en la API desde el primer día. Muchos de ellos adoptan el proceso de desarrollo «FHIR-first», en el que el backend de una nueva solución se construye sobre un servidor FHIR. Este utiliza el modelo de datos FHIR internamente y soporta una API FHIR completa desde el primer momento. Sin embargo, ¿qué ocurre si desarrolló su solución hace tiempo y no dispone de una capa de API? Necesita permitir que su aplicación se comunique con otras, y para eso sirve una fachada de API: una interfaz añadida a su solución que otorga a otras aplicaciones acceso a las operaciones y los datos de la misma.
Cómo construir una fachada FHIR
Fachada FHIR sin almacenamiento
Un enfoque para implementar una fachada FHIR consiste en traducir las llamadas REST de FHIR en consultas a la base de datos subyacente o a los servicios del sistema original. Es necesario mapear el modelo de información interno a FHIR, es decir, determinar qué recursos y atributos FHIR representan las estructuras de datos de su sistema. Esta fachada redirige todas las llamadas a la base de datos original.
La implementación es sencilla para una API de solo lectura, pero puede volverse compleja si desea permitir que los usuarios escriban datos de vuelta en el sistema original. Los casos de uso simples pueden resolverse con herramientas de mapeo, mientras que las implementaciones más complejas requerirán un desarrollo personalizado considerable.
Fachada FHIR con un servidor FHIR intermedio
El otro enfoque consiste en utilizar un servidor FHIR genérico para almacenar los datos que se van a servir a través de la API. Se realiza el mismo mapeo del modelo de información interno a FHIR, pero luego se sincronizan los datos de su base de datos con los del servidor FHIR, que se encarga del resto del trabajo.
El servidor FHIR gestiona todos los comandos de la API sin redirigirlos a la base de datos subyacente del sistema original. Todos los cambios en la base de datos original se trasladan oportunamente al servidor FHIR, de modo que el sistema original y el servidor FHIR permanecen sincronizados.
Ventajas e inconvenientes
Ambos enfoques son viables para distintos casos de uso y presentan diferentes ventajas e inconvenientes. La fachada FHIR sin almacenamiento funciona bien en casos de uso simples, cuando es necesario implementar unos pocos endpoints de API individuales. No hay duplicación de datos y utiliza recursos informáticos mínimos.
Sin embargo, si desea que su fachada FHIR aloje aplicaciones empresariales y habilite casos de uso a nivel poblacional, «cachear» los datos en un servidor FHIR intermedio puede ser beneficioso e incluso necesario en algunas ocasiones. Cuando un servidor FHIR gestiona todas las llamadas a la API, usted controla el rendimiento de cada llamada. Es posible lograr un rendimiento excelente a escala, incluso cuando el servidor FHIR virtualiza datos procedentes de varios sistemas. Las mismas llamadas a la API con una fachada sin almacenamiento podrían ser muy lentas.
Comience a trabajar con el Servidor FHIR de Aidbox para el almacenamiento de datos, integraciones, analítica sanitaria y mucho más, o contrate a nuestro equipo para dar soporte a sus necesidades de desarrollo de software.
Es importante mencionar la complejidad de la búsqueda FHIR. Será considerablemente más rápida con el servidor FHIR intermedio, ya que es posible soportar la búsqueda mediante índices, algo que no es posible con el enfoque sin almacenamiento.
Aunque su servidor FHIR reciba un gran número de consultas de aplicaciones externas, no sobrecarga el sistema subyacente. Los datos se solicitan al sistema original únicamente una vez; el servidor FHIR se encarga de atender todas las llamadas a la API. Si utiliza una fachada sin almacenamiento, todas las consultas se dirigen a la base de datos subyacente del sistema original, lo que podría afectar al rendimiento de dicho sistema y de sus usuarios.
Utilizar un servidor FHIR completo le ofrece una ventaja adicional en comparación con la fachada FHIR sin almacenamiento. Le permite construir todo un nuevo ecosistema de aplicaciones modernas «FHIR-first» sobre él, de modo que algún día podrá migrar de su backend propietario heredado a un futuro basado en FHIR. Aunque requiere más recursos informáticos, estos no se desperdician: le proporcionan un nivel superior de flexibilidad.
Conclusiones
La elección del enfoque para implementar su API es suya. Health Samurai puede dar soporte a ambos enfoques con sus soluciones y servicios. Envíenos un mensaje o llámenos.
Véase también: Por qué necesita un servidor FHIR independiente.
