Arquitectura de Atomik
Atomik está diseñado como un servicio backend — una capa de persistencia para datos clínicos que se sitúa entre las aplicaciones y el almacén de datos. No impone un frontend ni un flujo de trabajo clínico particular. Las aplicaciones que se estén desarrollando se conectan a su API REST.
Modelo de Despliegue
Atomik se ejecuta como una aplicación Java/Grails sobre la JVM. Puede desplegarse on-premises, en una nube privada o en cualquier proveedor de nube pública. La capa de persistencia usa Hibernate, lo que lo hace compatible con cualquier base de datos relacional que tenga un driver JDBC.
Las bases de datos soportadas incluyen PostgreSQL (recomendada para producción), MySQL, Oracle y SQL Server. La elección de la base de datos no afecta al comportamiento de la API ni al modelo de datos — Atomik lo abstrae a través de la capa ORM.
Atomik se distribuye como un paquete de aplicación autocontenido. El despliegue basado en Docker también está disponible — contáctanos para hablar sobre tus requisitos de contenedorización y te proporcionaremos la imagen adecuada.
Ejecute Atomik en su propio hardware o centro de datos. Control total sobre el entorno y la residencia de los datos.
Despliegue en AWS, Azure, GCP o cualquier proveedor VPS. Sin dependencias específicas de ninguna nube.
El despliegue Docker está disponible bajo petición. Proporcionamos la imagen del contenedor según tus requisitos — no existe un registro público.
También ofrecemos despliegue gestionado para organizaciones que no quieren operar Atomik por su cuenta.
Capas de API
Atomik expone cuatro categorías de APIs REST. Cada una cumple una función diferente en el sistema.
API REST openEHR
La API principal para datos clínicos. Implementa la especificación openEHR ITS REST para almacenar y recuperar HCEs, composiciones y datos demográficos. Cualquier cliente compatible con openEHR puede interactuar con esta API sin modificaciones.
Conforme al estándarAPI de Administración
Para gestionar usuarios, organizaciones, plantillas, consultas almacenadas y configuración del sistema. Utilizada por la Consola Web y disponible para scripts de automatización y pipelines CI/CD que necesiten configurar Atomik de forma programática.
GestiónAPI de Sincronización / Clúster
Permite que múltiples instancias de Atomik sincronicen su estado para despliegues de alta disponibilidad. Se usa cuando se necesita ejecutar Atomik detrás de un balanceador de carga con más de un nodo activo, o simplemente para tener una copia de seguridad completa de los datos en una ubicación secundaria.
Alta disponibilidadAPI de Monitorización
Proporciona endpoints de health check y métricas operacionales. Compatible con herramientas estándar de monitorización de infraestructura. Útil para verificaciones de disponibilidad, planificación de capacidad e integraciones de alertas.
OperacionesPatrones de Integración
La forma en que las aplicaciones se conectan a Atomik depende de lo que ya exista en el entorno.
Integración Directa por API
Las aplicaciones llaman directamente a la API REST de Atomik para almacenar y recuperar datos clínicos. Es el patrón de integración más sencillo y funciona bien para proyectos nuevos donde se controla todo el stack.
Motor de Integración
Para entornos con infraestructura de integración existente — feeds HL7 v2, servidores FHIR, sistemas de mensajería y otras fuentes de datos — Atomik se sitúa detrás de un motor de integración como Mirth Connect. El motor gestiona el enrutamiento y la transformación de mensajes; Atomik gestiona la persistencia de datos clínicos.
API Gateway
En despliegues más complejos, un API gateway se sitúa delante de Atomik para gestionar la autenticación, la limitación de tasa y el enrutamiento. La capa de API sin estado de Atomik es compatible con configuraciones estándar de gateway.
CDR Compartido en un Sistema Multi-Aplicación
Cuando varias aplicaciones clínicas necesitan compartir los mismos datos de pacientes, Atomik actúa como la capa de persistencia compartida. Cada aplicación lee y escribe a través de la misma API openEHR, y el modelo de datos está gobernado por plantillas operacionales compartidas.
Escalabilidad
Atomik soporta escalado horizontal a través de su API de clúster. Múltiples instancias de Atomik pueden sincronizarse para compartir estado. La capa de API REST sin estado permite el balanceo de carga entre instancias sin requisitos de afinidad de sesión.
Para la mayoría de los despliegues — una única organización o un número reducido de tenants — una sola instancia de Atomik con una base de datos bien aprovisionada es suficiente. La configuración en clúster es relevante cuando se necesita alta disponibilidad o se gestionan altos volúmenes de escritura entre muchos tenants simultáneamente.
La base de datos es la principal restricción de escalado. Las características de rendimiento de PostgreSQL están bien documentadas, y el modelo de datos de Atomik está diseñado para funcionar con estrategias de indexación estándar sobre el esquema relacional subyacente.
¿Tienes alguna pregunta?
Dinos cómo podemos ayudarte.