Resumen Ejecutivo
En la mayoría de las organizaciones sanitarias, las personas que saben qué hay que construir no pueden construirlo — y las que pueden siempre están a meses de distancia. Cada herramienta que podría mejorar la atención o cerrar una brecha en el flujo de trabajo queda atascada entre ambas partes.
Atomic Workspace cierra esa brecha. Es una plataforma de IA donde los equipos clínicos diseñan, construyen y despliegan aplicaciones sanitarias — sin un ciclo de desarrollo tradicional. Clínicos, diseñadores, desarrolladores y agentes de IA trabajan todos en el mismo espacio. Los clínicos describen lo que necesitan y aprueban el resultado. Los agentes de IA se encargan de la construcción. Y si surge algo complejo — una integración difícil, un caso límite — un desarrollador puede intervenir sin perder el hilo de lo que el equipo ya ha construido. Cada proyecto se ejecuta dentro de un gemelo digital del entorno de producción, construido sobre un servidor FHIR, de modo que los equipos construyen y prueban contra estructuras de datos reales desde el primer día.
Resultados preliminares del piloto:
- De requisito clínico a prototipo funcional: 1–2 días (frente a 3–6 meses)
- De prototipo validado a producción: 2–4 semanas (frente a 6–18 meses)
- Los equipos clínicos lanzan 10 veces más aplicaciones al año sin incorporar ingenieros
El Problema
Construir una herramienta clínica requiere dos tipos de conocimiento que rara vez residen en la misma persona: experiencia clínica e ingeniería de software. Tender ese puente es costoso.
Cada requisito necesita ser explicado, clarificado e interpretado. Cada decisión de diseño requiere un ciclo de retroalimentación. Cada iteración implica otra ronda de traducción — desde lo que el clínico necesita, hasta lo que el desarrollador entendió, hasta lo que realmente se construyó. Cada paso lleva tiempo, y cada paso introduce distorsión.
Para cuando una herramienta sale al mercado, han pasado meses y se ha invertido un presupuesto considerable — no en construir, sino en comunicar. Y con frecuencia, lo que se entrega todavía no encaja del todo.
Así que los equipos se las arreglan con hojas de cálculo, soluciones provisionales y formularios en papel. Dejan de solicitar las herramientas que necesitan porque el coste de pedirlas es demasiado elevado. Y la brecha entre lo que tienen los equipos clínicos y lo que realmente necesitan no deja de crecer.
Lo que ya se ha intentado
Herramientas de desarrollo de IA de propósito general
Las plataformas de codificación de IA de propósito general — asistentes, marcos de agentes y constructores de bajo código no diseñados para el sector sanitario — ofrecen velocidad. Pero crean nuevos problemas en un contexto de salud.
No tienen conocimiento del dominio sanitario incorporado. Generan código sin conocimiento de la semántica de los recursos FHIR, los estándares de datos clínicos ni las restricciones de los entornos de HCE. Cada proyecto requiere un trabajo de adaptación considerable para producir resultados que cumplan los requisitos de interoperabilidad sanitaria. La carga de integración — conectar aplicaciones a los sistemas de HCE, gestionar la autorización SMART, mapear a los recursos FHIR — recae sobre el equipo de desarrollo, no sobre la plataforma.
Estas herramientas aceleran a los desarrolladores. No eliminan la dependencia de los desarrolladores.
Plataformas de aplicaciones nativas para la salud
La categoría más cercana a Atomic Workspace. Algunas plataformas permiten a los equipos clínicos construir herramientas sanitarias personalizadas con asistencia de IA — formularios, paneles, portales, flujos de trabajo. Son rápidas y están construidas teniendo en cuenta el cumplimiento normativo sanitario.
La limitación principal es la interoperabilidad. Estas plataformas se sitúan sobre la HCE como una capa de interfaz — no son nativas en FHIR. Cada despliegue en un nuevo entorno de HCE requiere trabajo de integración personalizado. Los datos que capturan no están estructurados de forma nativa en FHIR, lo que genera fricciones más adelante cuando necesitan volver a los sistemas clínicos.
Plataformas de desarrollo nativas en FHIR
Algunas plataformas son genuinamente nativas en FHIR — resuelven bien el problema de los estándares y la interoperabilidad. Pero están construidas para desarrolladores, no para equipos clínicos. Un clínico sigue sin poder describir una necesidad de flujo de trabajo y convertirla en una aplicación funcional. La dependencia de ingeniería no desaparece.
El Enfoque de Atomic Workspace
Atomic Workspace se basa en cuatro decisiones que abordan el problema directamente.
1. FHIR como capa operativa
En Atomic Workspace, FHIR no es una capa de integración. Es el modelo de datos central sobre el que opera toda la plataforma. Los agentes de IA trabajan directamente con recursos FHIR. El entorno de gemelo digital ejecuta un servidor FHIR activo. Cada aplicación producida es una aplicación SMART on FHIR, compatible con cualquier HCE conforme a FHIR a través del Marco de Lanzamiento de Aplicaciones SMART — sin conectores personalizados, middleware específico del proveedor ni trabajo de integración por despliegue.
La plataforma va más allá del FHIR base: incorpora el HL7 SDC IG para formularios clínicos estructurados y cuestionarios, SQL on FHIR para análisis e informes, validación de esquemas FHIR en cada etapa, y un servicio de Terminology integrado (SNOMED CT, LOINC y otros) accesible a los agentes de IA como herramientas de línea de comandos, de modo que los códigos clínicos se resuelven en el momento de la generación del código.
Esto significa que cada aplicación construida en Atomic Workspace es interoperable por construcción — no por configuración.
2. Un entorno de desarrollo de gemelo digital
Cada proyecto en Atomic Workspace se ejecuta dentro de un gemelo digital aislado del entorno clínico de producción. El gemelo digital comprende un CDR FHIR Virtual (Repositorio de Datos Clínicos con simulación de HCE), un Motor de Flujo de Trabajo (Temporal) y un Portal Virtual. Los agentes de IA y los equipos clínicos construyen y prueban contra las mismas estructuras de datos y el mismo comportamiento de servicio que encontrarán en producción.
Esto elimina la fuente más común de fallos tras el despliegue en software sanitario: la brecha entre lo que asumía el entorno de desarrollo y lo que resultó ser la realidad de producción. Cuando una aplicación funciona en el gemelo digital, funciona en la HCE.
3. Desarrollo guiado por especificaciones
Atomic Workspace invierte la transferencia de desarrollo tradicional. Cada construcción comienza con una especificación estructurada generada por el Analista de IA a partir de los requisitos clínicos, revisada y aprobada por el equipo clínico antes de escribir ningún código. La especificación aprobada configura entonces el entorno de gemelo digital, define el conjunto de pruebas y rige lo que los agentes de IA construyen a lo largo de todo el ciclo de vida.
La intención clínica queda codificada como un artefacto verificable — no se interpreta durante el desarrollo, ni se reconstruye a posteriori. Esto es lo que hace posible que los clínicos participen en la construcción sin escribir código: no están aprobando resultados técnicos, sino aprobando una especificación escrita en términos que comprenden.
4. Colaborativo por diseño
Atomic Workspace está construido como un entorno compartido desde sus cimientos. Clínicos, diseñadores, desarrolladores, analistas y agentes de IA trabajan en el mismo espacio de trabajo simultáneamente — viendo los mismos requisitos, el mismo estado de construcción, los mismos resultados de validación. Los desarrolladores pueden incorporarse a cualquier proyecto activo en cualquier etapa para resolver un caso límite técnico sin perder el hilo de lo que el equipo clínico ya ha construido.
Los puntos de control de intervención humana están integrados en el flujo de trabajo en la aprobación de la especificación, la validación clínica y la firma de las partes interesadas. Los agentes de IA operan entre esos puntos de control. Ningún proyecto llega a producción sin la aprobación clínica y de las partes interesadas.
Cómo funciona
Un proyecto en Atomic Workspace avanza a través de un ciclo de vida definido, con agentes de IA dirigiendo la ejecución y los participantes clínicos controlando las decisiones.
1. Captura Un clínico o equipo asistencial describe una necesidad de flujo de trabajo en su propio lenguaje. El Analista de IA mantiene un diálogo estructurado para extraer requisitos, casos límite y restricciones. No se requieren conocimientos técnicos.
2. Especificación El Analista de IA convierte los requisitos capturados en una especificación estructurada: modelo de datos, lógica de flujo de trabajo, reglas de validación y criterios de aceptación. El equipo clínico revisa y aprueba la especificación antes de que se genere ningún código.
3. Configuración La especificación aprobada configura el entorno de gemelo digital del proyecto — instanciando los recursos FHIR, las definiciones de flujo de trabajo y los datos de prueba contra los que se construirá la aplicación.
4. Construcción Los agentes Desarrolladores de IA generan la aplicación — backend y frontend — apuntando a las APIs nativas en FHIR del gemelo digital. Las Habilidades integradas (SDC, UI, Análisis, Terminology) actúan como salvaguardas, restringiendo la salida de la IA a patrones conformes a FHIR y clínicamente sólidos.
5. Pruebas Los agentes de pruebas automatizadas validan la aplicación contra el gemelo digital, comprobando la conformidad con FHIR, la corrección del flujo de trabajo y los criterios de aceptación de la especificación.
6. Validación El equipo clínico interactúa con la aplicación funcional dentro del gemelo digital — el mismo entorno en el que se ejecutará cuando se despliegue. La retroalimentación fluye de vuelta al espacio de trabajo para iteración.
7. Despliegue Tras la aprobación de las partes interesadas, la aplicación se despliega como una aplicación SMART on FHIR, lanzándose directamente dentro de la HCE conforme a FHIR de la organización. No hay infraestructura de despliegue que construir, ni trabajo de integración que realizar.
Una única instancia de Atomic Workspace gestiona cualquier número de proyectos concurrentes — cada uno ejecutándose en un entorno completamente aislado. Esto significa que múltiples equipos clínicos pueden construir simultáneamente sin interferencias, y los datos, el código y el contexto del agente de cada proyecto permanecen completamente separados. La Figura 1 ilustra esta arquitectura multiproyecto.
Cada entorno de proyecto no es un entorno de pruebas genérico — es un gemelo digital estructurado con tres capas diferenciadas que trabajan conjuntamente. La Figura 2 muestra la arquitectura interna de un proyecto individual: a la izquierda, el gemelo digital de los servicios de producción (CDR FHIR, Motor de Flujo de Trabajo, Portal Virtual); en el centro, el código base de la aplicación y el entorno de ejecución; a la derecha, la capa de Copiloto de IA con Agentes de Codificación que operan mediante el protocolo ACP, guiados por una capa de Habilidades y Conocimiento integrada que restringe la salida de la IA a patrones conformes a FHIR y clínicamente sólidos.
Base Técnica
Infraestructura y stack
Atomic Workspace está construido sobre Aidbox, una plataforma de servidor FHIR. Cada proyecto se ejecuta en un contenedor Docker aislado, gestionado a través de Multibox — la capa multitenant de Aidbox — que gestiona el aprovisionamiento y el aislamiento de datos entre proyectos.
| Componente | Tecnología |
|---|---|
| Entorno de ejecución | Bun |
| Contenedorización | Docker / Docker Compose |
| Servidor FHIR | Aidbox (Multibox) |
| Motor de Flujo de Trabajo | Temporal |
| Agentes de IA | Claude Code, Codex vía ACP (Agent Communication Protocol) |
| Frontend | TypeScript, basado en navegador |
| Estructura del Proyecto | Basada en plantillas, alineada con FHIR |
Estándares HL7
| Estándar | Uso |
|---|---|
| FHIR R4 | Modelo de datos central, APIs REST, validación de recursos |
| SMART on FHIR | Formato de salida de aplicaciones, lanzamiento en HCE, autorización |
| HL7 SDC IG | Captura de datos estructurados, formularios clínicos y cuestionarios |
| SQL on FHIR | Capa de análisis e informes |
| SNOMED CT / LOINC | Servicio de Terminology mediante herramientas CLI, resuelto en la generación de código |
Despliegue
Atomic Workspace admite despliegue en la nube, en local y en modalidad híbrida. Las organizaciones con requisitos de residencia de datos o aislamiento de red pueden ejecutar la plataforma completa dentro de su propia infraestructura. Las aplicaciones SMART on FHIR se despliegan sin trabajo de integración específico por destino en Epic, Cerner y otros sistemas de HCE conformes a FHIR.
Seguridad y Cumplimiento Normativo
Aislamiento de datos y autorización
Cada proyecto se ejecuta en un entorno de gemelo digital aislado. El desarrollo y las pruebas utilizan datos sintéticos o seudoanonimizados de forma predeterminada. Los despliegues en producción operan bajo los BAA correspondientes con los socios de organizaciones sanitarias. Todo acceso a la plataforma utiliza autenticación de grado empresarial con controles de acceso basados en roles tanto en la capa de plataforma como en la de aplicación.
Todas las aplicaciones producidas por la plataforma utilizan el marco de autorización SMART para el control de acceso, alineándose con las normas de interoperabilidad de CMS y los requisitos de certificación de ONC para aplicaciones integradas en HCE.
Intervención humana por diseño
Los puntos de control de validación humana obligatorios están integrados en el flujo de trabajo en la aprobación de la especificación, la validación clínica y la firma de las partes interesadas. Los agentes de IA operan entre estos puntos de control, pero no pueden avanzar un proyecto a producción sin la autorización clínica y de las partes interesadas. El código generado por la IA, las especificaciones y los resultados de las pruebas son completamente visibles y revisables dentro del espacio de trabajo. Los participantes clínicos y técnicos pueden inspeccionar, modificar y anular los resultados de la IA en cada etapa.
Posición regulatoria
Las aplicaciones producidas por Atomic Workspace que entren dentro del ámbito del Software como Dispositivo Médico (SaMD) requieren una revisión regulatoria independiente. La plataforma proporciona la infraestructura de desarrollo e integración; no reemplaza el proceso de validación clínica y autorización regulatoria para herramientas que toman o influyen en decisiones clínicas.
El Caso de Negocio
La economía
Atomic Workspace no consiste en sustituir a los desarrolladores. Consiste en cambiar en qué necesitan participar los desarrolladores.
Hoy en día, cada aplicación clínica requiere una participación de ingeniería completa — desde los requisitos hasta el diseño, el desarrollo, las pruebas y el despliegue. El equipo de desarrollo es el cuello de botella para cada proyecto, independientemente de su complejidad. Las organizaciones aumentan la plantilla para incrementar la capacidad, pero el coste de cada aplicación adicional se mantiene elevado.
Atomic Workspace cambia esta proporción. Los agentes de IA se encargan de la ejecución. Los desarrolladores intervienen donde se necesita verdadera profundidad técnica — integraciones complejas, casos límite, optimización del rendimiento. El resultado es que un equipo de un tamaño determinado puede dar soporte a significativamente más proyectos al año.
Modelo de costes
El coste de la plataforma es principalmente un coste de infraestructura fijo que se amortiza entre proyectos. Una vez desplegada la plataforma y establecida la biblioteca inicial de Habilidades, el coste marginal de cada aplicación adicional disminuye. Las organizaciones que construyen una biblioteca de Habilidades institucionales — codificando sus propios flujos de trabajo, reglas clínicas y patrones de datos — ven reducciones de costes adicionales a medida que cada nuevo proyecto comienza con una base más sólida.
Construir frente a comprar
Para las organizaciones de TI sanitaria que evalúan construir frente a comprar:
Construir una plataforma de desarrollo de IA personalizada requiere profunda experiencia en FHIR, infraestructura de orquestación de múltiples agentes, conocimiento del dominio clínico integrado en la cadena de herramientas y mantenimiento continuo a medida que los estándares evolucionan. Es una inversión de varios años y varios millones de euros con una sobrecarga operativa continua considerable.
Adaptar herramientas de propósito general para la salud traslada la carga de integración y cumplimiento normativo a cada proyecto individual. Cada aplicación se convierte en un ejercicio de integración personalizado. La plataforma no acumula conocimiento clínico ni alineación con estándares a lo largo del tiempo.
Atomic Workspace comienza con la base específica para la salud ya establecida — nativa en FHIR, alineada con estándares, lista para HCE. La biblioteca de Habilidades crece con cada proyecto, de modo que la plataforma se vuelve más útil con el tiempo, no menos.
Casos de Uso Ilustrativos
Recogida de Resultados Comunicados por los Pacientes (PROMs)
El problema Un equipo asistencial que gestiona pacientes postquirúrgicos necesita recoger puntuaciones de resultados estandarizadas (KOOS, HOOS, PROMIS) en intervalos definidos. Actualmente, esto se hace mediante formularios en papel o llamadas telefónicas manuales — los datos acaban en PDFs escaneados o notas no estructuradas, no en la HCE.
La construcción Un analista clínico describe el requisito al Analista de IA: recoger PROMs específicos a las 2 semanas, 6 semanas y 3 meses tras la cirugía, vinculados al CarePlan del paciente en la HCE. El Analista de IA convierte esto en una especificación estructurada utilizando recursos Questionnaire del HL7 SDC IG para cada instrumento de resultados.
El Desarrollador de IA genera una aplicación SMART on FHIR orientada al paciente que envía a los pacientes un enlace seguro en el intervalo apropiado. Los pacientes completan el formulario en cualquier dispositivo; las respuestas se almacenan como recursos QuestionnaireResponse de FHIR, vinculados al CarePlan de origen e inmediatamente disponibles en la HCE.
Para los pacientes que prefieren la interacción por voz, el mismo flujo de trabajo admite una llamada de voz por IA: un agente de IA lee los ítems del cuestionario, captura las respuestas por voz y las mapea a los campos QuestionnaireResponse de FHIR correspondientes.
El resultado Los datos de resultados estructurados y codificados fluyen directamente al almacén de datos FHIR — sin transcripción manual, sin notas no estructuradas. El equipo asistencial obtiene una visión longitudinal completa de los resultados comunicados por los pacientes sin cambiar la forma en que estos prefieren interactuar.
Capacidades de la plataforma demostradas: Questionnaire/QuestionnaireResponse del SDC IG, aplicación SMART on FHIR orientada al paciente, servicio de Terminology, integración de voz con IA, vinculación a CarePlan.
Panel de Análisis Clínico mediante Lenguaje Natural
El problema Un responsable de operaciones clínicas quiere hacer seguimiento de las tasas de reingreso, la duración de la estancia y la adherencia a la medicación en una cohorte de pacientes — pero no dispone de soporte de ingeniería y no puede esperar a que un equipo de BI priorice la solicitud.
La construcción El analista abre un nuevo proyecto en Atomic Workspace y describe el panel en lenguaje natural: qué población de pacientes, qué métricas, qué ventanas temporales y cómo deben mostrarse los resultados. No se requieren conocimientos de SQL ni de consultas FHIR.
El Analista de IA produce una especificación que mapea cada métrica a los recursos FHIR relevantes (Encounter, MedicationRequest, Observation) y define las consultas SQL on FHIR que potenciarán el panel. Tras la aprobación de la especificación por parte del analista, los agentes Desarrolladores de IA generan la aplicación del panel — una aplicación SMART on FHIR que consulta el servidor FHIR utilizando SQL on FHIR y muestra los resultados en una interfaz interactiva.
El analista puede refinar el panel mediante conversación de seguimiento: «añadir un filtro por diagnóstico principal», «mostrar líneas de tendencia para los últimos 90 días», «desglosar esto por médico responsable». Cada solicitud se traduce en una actualización de la especificación y es implementada por los agentes de IA.
El resultado Un panel de análisis clínico completamente funcional, desplegado en la HCE, construido sin participación de ingeniería — de descripción a aplicación funcional en menos de un día.
Capacidades de la plataforma demostradas: SQL on FHIR, Habilidades Analíticas, generación de especificaciones en lenguaje natural, salida de aplicación SMART on FHIR, refinamiento iterativo impulsado por IA.
Servicio de Toma de Decisiones para Autorización Previa
El problema La autorización previa es uno de los procesos más intensivos en mano de obra en el sector sanitario. Las enfermeras de gestión de utilización (UM) verifican manualmente la elegibilidad, las reglas de cobertura y los criterios de necesidad médica para cada solicitud de autorización — trabajando con grandes hojas de cálculo de códigos de facturación, navegando por los sitios web de CMS para buscar criterios LCD/NCD (Determinaciones de Cobertura Local y Nacional), y realizando múltiples llamadas a los proveedores para recopilar documentación clínica. El proceso lleva horas por caso.
El problema central es que las reglas de cobertura existen como texto no estructurado en los sitios web de CMS y hojas de cálculo internas — no como lógica legible por máquina. Cada pagador tiene reglas ligeramente diferentes. No existe una forma estándar de codificarlas, mantenerlas o ejecutarlas automáticamente.
La construcción En Atomic Workspace, un especialista en gestión de utilización (UM) — un miembro del personal con formación clínica responsable de las decisiones de cobertura, normalmente sin formación técnica — trabaja con el Analista de IA para definir las reglas de cobertura para una línea de negocio específica — comenzando, por ejemplo, con el Oxígeno Domiciliario (LCD de Medicare L33797). La plataforma incluye una Base de Conocimiento integrada poblada a partir de documentos LCD/NCD de Medicare: extraídos de CMS, estructurados e indexados, y puestos a disposición de los agentes de IA mediante búsqueda y búsqueda por similitud.
El agente de IA utiliza esta Base de Conocimiento para extraer los criterios de necesidad médica relevantes, generar un recurso Questionnaire de FHIR que captura la evidencia clínica requerida, y codificar la lógica de cobertura como una regla de decisión estructurada. El especialista de UM revisa y refina el resultado — sin necesidad de codificación.
El resultado es un Servicio de Toma de Decisiones: un componente basado en estándares que acepta una solicitud de CDS Hooks de la HCE cuando se ordena un procedimiento sujeto a autorización previa, evalúa las reglas de cobertura aplicables contra el registro FHIR del paciente, y responde con una decisión — aprobada automáticamente (para proveedores con tarjeta dorada o casos claramente elegibles), o un enlace al Questionnaire de FHIR generado para que el clínico lo complete.
El servicio completo se construye como un proyecto de plantilla en Atomic Workspace, desplegable en múltiples organizaciones pagadoras con conjuntos de reglas específicos de cada organización creados sobre el marco compartido.
El resultado Las decisiones de autorización previa rutinarias se procesan automáticamente en el momento de la orden — sin la intervención de la enfermera de UM. Los casos complejos o excepcionales se derivan a revisión humana con la evidencia clínica relevante ya recopilada. Las reglas de cobertura son mantenidas directamente por los especialistas de UM, sin participación de desarrolladores, y actualizadas a medida que cambian los criterios LCD/NCD.
Para los pagadores, esto reemplaza un proceso manual y propenso a errores con una automatización auditable y basada en estándares construida en semanas — no en los meses y el coste de seis cifras de las herramientas tradicionales de gestión de políticas.
Capacidades de la plataforma demostradas: integración de CDS Hooks, generación de Questionnaire de FHIR, Base de Conocimiento LCD/NCD de Medicare, autoría de reglas de cobertura asistida por IA por personal no técnico, despliegue multitenant basado en plantillas.
Evidencia Preliminar
Atomic Workspace se encuentra actualmente en un piloto activo con un equipo clínico. El entorno de gemelo digital está en funcionamiento; el desarrollo real de proyectos y la validación clínica están en marcha.
Los siguientes indicadores están informados por las observaciones preliminares del piloto y serán validados formalmente a través del piloto en curso:
| Métrica | Referencia del sector | Objetivo de Atomic Workspace |
|---|---|---|
| De requisito a prototipo funcional | 3–6 meses | 1–2 días |
| De prototipo validado a producción | 6–18 meses | 2–4 semanas |
| Puntuación de satisfacción del clínico | — | 4+ / 5 |
| Aplicaciones lanzadas al año (mismo tamaño de equipo) | Referencia | 10x |
Cómo Empezar
Atomic Workspace está disponible para despliegue piloto con organizaciones de TI sanitaria y sus socios clínicos.
La plataforma admite despliegue en la nube, en local y en modalidad híbrida. Los compromisos piloto comienzan con un caso de uso clínico definido y terminan con una aplicación funcional desplegada en la HCE.
Para hablar sobre un piloto o una evaluación técnica: Contacto: mary@health-samurai.io
Recursos de la plataforma:
- Entorno de pruebas disponible para evaluación técnica
- Documentación de arquitectura y guías de integración disponibles bajo petición
Atomic Workspace es desarrollado por Health Samurai, el equipo detrás de la plataforma FHIR Aidbox.
