Antes de definir las pantallas, el equipo revisó la literatura académica sobre historias clínicas electrónicas y analítica sanitaria. Entre treinta y dos artículos, incluidos varios de revistas como el Journal of Biomedical Informatics, se identificaron ocho estudios como directamente relevantes para las decisiones de interfaz. Analizaban cómo los clínicos e investigadores buscan en los sistemas EHR, con qué frecuencia pierden el contexto durante sesiones prolongadas y en qué aspectos el diseño de las interfaces EHR no hace visible la procedencia de los datos.

Estos estudios describían comportamientos concretos. Los usuarios se mueven con frecuencia entre datos clínicos estructurados y notas narrativas. Se apoyan en patrones temporales del historial del paciente, pero pierden de vista qué filtros están activos. Cuando las consultas se refinan repetidamente, el historial de decisiones se vuelve opaco, lo que perjudica la reproducibilidad. Los datos clínicos son técnicamente ricos, pero cognitivamente frágiles.

Los hallazgos se tradujeron en requisitos para el software de investigación médica. La plataforma de datos sanitarios necesitaba indicios claros de procedencia, un historial de consultas visible y una vista estable de qué datos de pacientes estaban actualmente en alcance. Los principios de diseño de interfaces EHR extraídos de la literatura se utilizaron como restricciones y no como elementos decorativos. La plataforma debía ayudar a los usuarios a comprender dónde se encontraban en los datos y cómo habían llegado hasta allí.

A través de Sandbox Experiments, una fase de discovery de dos semanas combinó investigación cualitativa y análisis de tareas con usuarios de tres entornos. Catorce entrevistas individuales y tres grupos focales reunieron a veinticuatro participantes, incluidos analistas del NHS, investigadores académicos y personal de investigación farmacéutica. Cada grupo trabajó bajo diferentes restricciones institucionales y procesos de aprobación, pero todos necesitaban realizar analítica de datos de pacientes sobre los mismos conjuntos de datos de salud mental.

Los equipos académicos describieron largos procesos de aprobación ética y de acceso a datos antes de poder siquiera iniciar sesión en software de investigación clínica que trabajaba con historiales reales de pacientes. Los equipos pharma tenían más margen para la exploración temprana, pero más adelante en el proyecto se enfrentaban a estrictas obligaciones de informes y auditoría. Los analistas del NHS utilizaban herramientas similares para la evaluación de servicios y necesitaban límites claros entre la investigación y el uso operativo. Estas realidades influyeron en el diseño más que cualquier descripción genérica de persona.

El análisis de tareas mapeó la secuencia de acciones a lo largo de todo el recorrido de un estudio, desde la idea inicial hasta la extracción final. La investigación confirmó que la confusión suele aparecer durante los traspasos entre personas o entre distintas etapas de gobernanza. Este hallazgo llevó a un fuerte enfoque en la continuidad del workflow y en estados claros, para que la misma plataforma de datos sanitarios pudiera apoyar rutas de aprobación muy diferentes sin fragmentar la experiencia.

Para entender la base de los software de investigación clínica, se compararon en profundidad nueve herramientas comerciales de Healthcare Analytics. No eran prototipos académicos, sino productos reales utilizados en hospitales, institutos de investigación y en la industria. La evaluación analizó los query builders, el diseño de las interfaces EHR, los modelos de workspace, los audit trails y cómo cada sistema mostraba la lógica de selección de cohortes de pacientes.

Surgieron varios problemas recurrentes. Algunas herramientas solo mostraban el resultado final de una query, dejando a los usuarios sin claridad sobre qué condiciones se habían aplicado realmente. Otras obligaban a los investigadores a seguir procedimientos fijos por pasos que no reflejaban cómo evolucionan los estudios de salud mental con el tiempo. La procedencia de los datos solía quedar oculta en registros técnicos en lugar de presentarse como parte de la experiencia de usuario. Incluso cuando la funcionalidad era amplia, la UX del software médico dificultaba confiar en los resultados.

El benchmark no se limitó a criticar a los competidores. Aclaró qué patrones ya conocían los usuarios, como los controles de filtros familiares, y qué problemas estructurales debían evitarse. La plataforma Akrivia se posicionó como una plataforma de datos sanitarios que hace visible el razonamiento detrás de los resultados y respeta las cargas cognitivas y regulatorias de la investigación en salud mental, en lugar de seguir convenciones genéricas de business analytics.

Con base en la investigación y el benchmarking, se propusieron cinco modelos de interacción distintos para la creación de cohortes mediante option space mapping. Uno funcionaba como un wizard, guiando a los usuarios a través de pasos secuenciales. Otro presentaba la query como bloques lógicos anidados. Un tercero organizaba las condiciones en torno a la línea temporal del historial del paciente. Los modelos restantes enfatizaban la reutilización de fragmentos de cohortes o la comparación lado a lado de variantes. Cada uno representaba una hipótesis diferente sobre cómo piensan los investigadores clínicos.

Estos modelos pasaron por seis ciclos de diseño con una fidelidad creciente, desde wireframes hasta prototipos interactivos. Ocho sesiones de usabilidad con usuarios del NHS, académicos y pharma probaron tareas realistas, como construir una cohorte de depresión resistente al tratamiento o ajustar una cohorte existente a nuevos criterios de inclusión. Se observó a los participantes mientras intentaban comprender decisiones pasadas, modificar condiciones y explicar su lógica a un colega.

El query builder final del software de investigación clínica es una convergencia de estos experimentos. Mantiene la legibilidad del modelo anidado, toma referencias temporales del modelo de línea de tiempo e incorpora fragmentos reutilizables entre proyectos. En términos de healthcare UX design, ofrece libertad para explorar sin sacrificar la trazabilidad, lo cual es fundamental para la gobernanza y la revisión científica.

Más allá de la selección de cohortes, la plataforma también debía apoyar el análisis de datos clínicos dentro del mismo entorno. La plataforma de datos sanitarios integra módulos de estadísticas descriptivas, exploración de correlaciones y vistas comparativas entre cohortes. Los investigadores pueden examinar distribuciones de medidas clave, seguir trayectorias de resultados y comparar respuestas a tratamientos sin exportar los datos de forma prematura a herramientas externas.

La visualización sigue una gramática clara adaptada al software de investigación médica. Los gráficos basados en el tiempo ayudan a los equipos a ver cómo evolucionan las puntuaciones de los síntomas antes y después de los cambios de tratamiento. Las vistas comparativas muestran diferencias en los patrones de medicación o en el uso de servicios entre cohortes. Estas vistas no son dashboards decorativos, sino instrumentos para el razonamiento clínico. Están diseñadas para que un estadístico, un psiquiatra y un responsable de data governance puedan entender lo que se muestra.

Al integrar estos módulos de analytics, la plataforma reduce la cantidad de herramientas necesarias para el análisis de datos de pacientes. También mantiene una mayor parte del recorrido analítico dentro de un entorno diseñado para la seguridad de los datos, la procedencia y la gobernanza del NHS. Para muchos equipos, esto es tan importante como el propio diseño visual.

Dado que Akrivia da servicio a múltiples instituciones, la plataforma debía funcionar como un sistema de datos sanitarios multi-equipo en lugar de una herramienta para un solo proyecto. Se definieron workspaces, proyectos y niveles de permisos para que los trusts del NHS, los grupos académicos y los socios pharma pudieran compartir el mismo software de investigación clínica sin difuminar los límites de la gobernanza. Cada estudio se sitúa dentro de un contexto claramente delimitado con sus propias reglas de aprobación y acceso a datos.

Los responsables de data governance participaron en la definición del modelo de solicitudes de acceso, aprobaciones y auditorías. La interfaz deja claro qué conjuntos de datos puede ver un usuario, qué rol tiene y qué acciones están permitidas en cada momento. Esto es esencial para el cumplimiento del GDPR en relación con datos sanitarios sensibles. El healthcare UX design aquí no trata de comodidad, sino de prevenir accesos inapropiados sin que los usuarios tengan que memorizar documentos de políticas complejos.

La plataforma también mantiene un audit trail explícito de las acciones analíticas, para que los equipos de gobernanza puedan revisar cómo se construyó una cohorte y cómo se utilizaron los datos clínicos. Esto reduce la carga de los informes de cumplimiento y da a las instituciones mayor confianza al abrir sus conjuntos de datos a un uso de investigación más amplio.

El sistema visual de la plataforma Akrivia se trató como una pieza de healthcare UX design por derecho propio. La mayoría de las pantallas presentan una superficie neutra y tranquila para el trabajo concentrado con datos clínicos. La jerarquía tipográfica es clara y ayuda a los usuarios a distinguir entre estructura, contenido y controles sin esfuerzo consciente. Los patrones de interacción son consistentes entre módulos, de modo que los investigadores pueden transferir su comprensión de la creación de cohortes a analytics y la gestión de workspaces.

El color se utiliza de forma moderada y con un significado definido. En el query builder separa grupos lógicos y resalta condiciones activas. En las vistas de analytics, corresponde a cohortes o estados de resultado en lugar de paletas decorativas. El resultado es un diseño de interfaz clínica que se mantiene legible durante sesiones largas, apoya la supervisión y la revisión, y no compite con el contenido.

Para la UX de software médico, esta sobriedad es una elección estratégica. El entorno debe sentirse fiable para el personal del NHS, los académicos y los investigadores pharma que dependen de la aplicación para tomar decisiones importantes. El lenguaje de diseño respalda esa confianza al priorizar la claridad, la coherencia y la legibilidad frente a efectos visuales expresivos.

Desde el principio, diseñadores e ingenieros trataron la plataforma Akrivia como un software sanitario de larga duración, no como un prototipo a corto plazo. El producto es una plataforma de investigación clínica basada en la web que debe integrarse con las canalizaciones de datos y los sistemas operativos existentes. Los talleres técnicos al inicio del proyecto aclararon las limitaciones en torno al rendimiento, la seguridad y el despliegue, para que los modelos de interacción no entraran en conflicto con las realidades arquitectónicas.

En paralelo, se creó un design system para apoyar la implementación y la hoja de ruta futura. Define componentes para query blocks, vistas de historiales de pacientes, paneles de analytics, gestión de workspaces y navegación, cada uno con reglas de comportamiento y estados precisos. Para los desarrolladores, esta librería actúa como un contrato. Conecta las decisiones de healthcare UX design con detalles concretos de implementación en una forma que se mantiene estable en el tiempo.

Durante la fase de build, el equipo de diseño se mantuvo involucrado para responder preguntas, ajustar patrones cuando ingeniería detectaba edge cases y asegurar que el software de investigación clínica se comportara como se esperaba en entornos reales. Esto evitó la brecha habitual entre concepto y producción y dio a Akrivia una base para varios años de evolución del producto.