EHRServer

Backend / Servidor

El problema

Antes de que existiera una implementación de referencia de código abierto, construir un repositorio de datos clínicos interoperable basado en openEHR implicaba dos opciones: adquirir un sistema propietario o implementar la especificación desde cero. Ninguna era viable para equipos pequeños, proyectos universitarios o startups de salud en etapas tempranas. La especificación openEHR es detallada y rigurosa — implementar un CDR conforme representa meses de trabajo incluso para desarrolladores experimentados.

La ausencia de un CDR de código abierto funcional y desplegable dificultaba enseñar el estándar en la práctica, ejecutar integraciones de prueba de concepto o evaluar si openEHR era la elección arquitectónica correcta. No había nada a lo que señalar y decir: "Aquí hay una implementación funcional que puedes ejecutar hoy."

Por qué lo construimos

EHRServer comenzó en 2012 como un proyecto interno de CaboLabs con dos objetivos: validar nuestra comprensión de la especificación openEHR implementándola, y dar a nuestros estudiantes de capacitación algo real con lo que trabajar durante los cursos. Si enseñábamos openEHR, necesitábamos un entorno donde los estudiantes pudieran observar la API, cargar composiciones y consultar datos en vivo — no solo leer diagramas.

Con el tiempo se convirtió en un CDR completamente funcional. Lo usamos en proyectos de investigación universitaria, en iniciativas de integración de salud y como backend para trabajos tempranos de prueba de concepto con clientes. Otros equipos comenzaron a usarlo de forma independiente. Para cuando decidimos lanzarlo públicamente, EHRServer se había convertido en lo que creemos fue la primera implementación de código abierto conocida de un CDR openEHR completo a nivel global.

Atomik es una refactorización de EHRServer — eliminamos la multiinquilinía, añadimos soporte para datos demográficos y rediseñamos varios componentes internos para uso SaaS en producción. Todo lo aprendido operando EHRServer en entornos reales informó el diseño y la construcción de Atomik. EHRServer sigue disponible para equipos que quieran estudiar la implementación o ejecutar un CDR de bajo costo para trabajo no productivo.

Ampliamente usado para educación y capacitación en openEHR

EHRServer es el CDR detrás de muchos programas de capacitación y cursos universitarios de openEHR. Su naturaleza de código abierto y bajo costo de configuración lo convierten en la opción práctica cuando los estudiantes necesitan un servidor real para ejecutar composiciones, inspeccionar respuestas de API y ver el modelo de datos openEHR en acción.

Capacidades principales

Lo que EHRServer implementa y proporciona de forma nativa.

APIs de EHR y Contribución

Implementa las APIs del modelo de servicio openEHR, permitiendo a las aplicaciones crear y gestionar EHRs de pacientes, composiciones clínicas y contribuciones de forma conforme a la especificación.

Arquitectura multiinquilino

Soporta múltiples organizaciones en un único despliegue, cada una con datos, usuarios y definiciones de plantillas aislados. Adecuado para infraestructura de investigación compartida o entornos de capacitación.

Motor de consultas visual y consultas almacenadas

Diseña consultas visualmente con un editor integrado, guárdalas como consultas almacenadas y ejéctalas mediante la REST API. Permite recuperar datos clínicos estructurados sin escribir sintaxis de consulta directamente.

Integración con SNOMED CT

Se integra con un servicio de terminología SNOMED CT para habilitar consultas semánticas — recupera composiciones por significado clínico, no solo por valores almacenados.

Consola web administrativa

Interfaz de gestión basada en navegador para EHRs, plantillas, composiciones, consultas almacenadas, usuarios y registros de auditoría. Útil para exploración práctica durante el desarrollo y la capacitación.

Despliegue preparado para clúster

Soporta despliegues en clúster mediante una API de sincronización dedicada, habilitando configuraciones de alta disponibilidad para entornos que necesitan redundancia sin migrar a un producto comercial.