Bevor Bildschirme definiert wurden, überprüfte das Team die akademische Literatur zu elektronischen Gesundheitsakten und Healthcare-Analytics. Über zweiunddreißig Arbeiten, darunter mehrere aus Zeitschriften wie dem Journal of Biomedical Informatics, wurden acht Studien als direkt relevant für Interface-Entscheidungen identifiziert. Sie analysierten, wie Kliniker und Forscher innerhalb von EHR-Systemen suchen, wie oft sie während langer Sitzungen den Kontext verlieren und wo EHR-Interface-Design Provenance nicht sichtbar macht.

Diese Studien beschrieben konkrete Verhaltensweisen. Benutzer wechseln oft zwischen strukturierten klinischen Daten und narrativen Notizen hin und her. Sie verlassen sich auf zeitliche Muster in der Patientenakte, verlieren aber den Überblick darüber, welche Filter aktiv sind. Wenn Abfragen wiederholt verfeinert werden, wird die Historie von Entscheidungen undurchsichtig, was die Reproduzierbarkeit untergräbt. Klinische Daten sind technisch reichhaltig, aber kognitiv fragil.

Die Erkenntnisse wurden in Anforderungen für die medizinische Forschungssoftware übersetzt. Die Healthcare-Datenplattform benötigte klare Provenance-Hinweise, sichtbare Abfragehistorie und eine stabile Ansicht dessen, welche Patientendaten aktuell im Geltungsbereich waren. EHR-Interface-Design-Prinzipien aus der Literatur wurden als Einschränkungen genutzt, nicht als Dekoration. Die Plattform musste Benutzern helfen zu verstehen, wo sie sich in den Daten befanden und wie sie dorthin gelangten.

Durch Sandbox Experiments kombinierte eine zweiwöchige Discovery-Phase qualitative Forschung und Task-Analyse mit Benutzern aus drei Umgebungen. Vierzehn Einzelinterviews und drei Fokusgruppen brachten vierundzwanzig Teilnehmer zusammen, darunter NHS-Analysten, akademische Forscher und pharmazeutisches Forschungspersonal. Jede Gruppe arbeitete innerhalb unterschiedlicher institutioneller Einschränkungen und Genehmigungsprozesse, aber alle mussten Patient-Data-Analytics auf denselben Mental-Health-Datensätzen durchführen.

Akademische Teams beschrieben langwierige Ethik- und Datenzugriffsgenehmigungen, bevor sie sich überhaupt in klinische Forschungssoftware einloggen konnten, die echte Patientenakten berührte. Pharma-Teams hatten mehr Spielraum für frühe Exploration, sahen sich aber später im Projekt strikten Reporting- und Audit-Verpflichtungen gegenüber. NHS-Analysten nutzten ähnliche Werkzeuge für Service-Evaluierung und benötigten klare Grenzen zwischen Forschung und operativer Nutzung. Diese Realitäten prägten das Design mehr als jede generische Persona-Beschreibung.

Task-Analyse erfasste die Sequenz von Aktionen in einer vollständigen Studienreise, von der ersten Idee bis zur finalen Extraktion. Die Forschung bestätigte, dass Verwirrung oft während Übergaben zwischen Personen oder zwischen Governance-Stufen auftritt. Diese Erkenntnis führte zu einem starken Fokus auf Workflow-Kontinuität und klare Zustände, sodass dieselbe Healthcare-Datenplattform sehr unterschiedliche Genehmigungspfade unterstützen konnte, ohne die Erfahrung zu fragmentieren.

Um die Baseline für klinische Forschungssoftware zu verstehen, wurden neun kommerzielle Werkzeuge eingehend gebenchmarkt. Dies waren keine akademischen Prototypen, sondern echte Healthcare-Analytics-Produkte, die in Krankenhäusern, Forschungsinstituten und der Industrie verwendet wurden. Die Evaluierung betrachtete Query Builder, EHR-Interface-Design, Workspace-Modelle, Audit Trails und wie jedes System die Logik der Patientenkohorten-Auswahl offenlegte.

Mehrere wiederkehrende Probleme traten auf. Einige Werkzeuge zeigten nur das Endergebnis einer Abfrage und ließen Benutzer unsicher darüber, welche Bedingungen tatsächlich angewendet wurden. Andere zwangen Forscher in feste Schrittverfahren, die nicht der Art entsprachen, wie sich Mental-Health-Studien im Laufe der Zeit entwickeln. Provenance war oft hinter technischen Logs versteckt, statt als Teil der User Experience präsentiert zu werden. Selbst wo Funktionalität reichhaltig war, machte es die Medical-Software-UX schwer, dem Ergebnis zu vertrauen.

Das Benchmark kritisierte nicht einfach nur Wettbewerber. Es klärte, welche Muster Benutzer bereits kannten, wie vertraute Filter-Steuerungen, und welche strukturellen Probleme vermieden werden mussten. Die Akrivia-Plattform wurde als Healthcare-Datenplattform positioniert, die das Denken hinter Ergebnissen offenlegt und die kognitiven und regulatorischen Belastungen der Mental-Health-Forschung respektiert, statt generischen Business-Analytics-Konventionen zu folgen.

Basierend auf Forschung und Benchmarking wurden durch option space mapping fünf unterschiedliche Interaktionsmodelle für Kohortenerstellung vorgeschlagen. Eines verhielt sich wie ein Wizard und führte Benutzer durch sequentielle Schritte. Ein anderes präsentierte die Abfrage als verschachtelte Logikblöcke. Ein drittes organisierte Bedingungen entlang der Zeitleiste der Patientenakte. Die verbleibenden Modelle betonten die Wiederverwendung von Kohortenfragmenten oder den Vergleich von Varianten nebeneinander. Jedes repräsentierte eine unterschiedliche Hypothese darüber, wie klinische Forscher denken.

Diese Modelle durchliefen sechs Design-Zyklen mit zunehmender Treue, von Wireframes bis zu interaktiven Prototypen. Acht Usability-Sessions mit NHS-, akademischen und Pharma-Benutzern testeten realistische Aufgaben, wie den Aufbau einer behandlungsresistenten Depressions-Kohorte oder die Anpassung einer bestehenden Kohorte an neue Einschlusskriterien. Teilnehmer wurden beobachtet, während sie versuchten, vergangene Entscheidungen zu verstehen, Bedingungen zu modifizieren und ihre Logik einem Kollegen zu erklären.

Der finale Query Builder in der klinischen Forschungssoftware ist eine Konvergenz dieser Experimente. Er behält die Lesbarkeit des verschachtelten Modells, übernimmt zeitliche Hinweise aus dem Zeitleisten-Modell und integriert Fragmente, die über Projekte hinweg wiederverwendet werden können. In Healthcare-UX-Design-Begriffen bietet er Freiheit zur Exploration, ohne Nachverfolgbarkeit zu opfern, was für Governance und wissenschaftliche Überprüfung kritisch ist.

Über die Kohorten-Auswahl hinaus musste die Plattform die Analyse klinischer Daten innerhalb derselben Umgebung unterstützen. Die Healthcare-Datenplattform integriert Module für deskriptive Statistik, Korrelationsexploration und vergleichende Ansichten zwischen Kohorten. Forscher können Verteilungen wichtiger Messungen inspizieren, Outcome-Trajektorien verfolgen und Behandlungsreaktionen vergleichen, ohne Daten vorzeitig in externe Werkzeuge zu exportieren.

Visualisierung folgt einer klaren Grammatik, die auf medizinische Forschungssoftware zugeschnitten ist. Zeitbasierte Charts helfen Teams zu sehen, wie sich Symptom-Scores vor und nach Behandlungsänderungen entwickeln. Vergleichsansichten zeigen Unterschiede in Medikamentenmustern oder Service-Nutzung zwischen Kohorten. Diese Ansichten sind keine dekorativen Dashboards, sondern Instrumente für klinisches Denken. Sie sind so gestaltet, dass ein Statistiker, ein Psychiater und ein Data-Governance-Beauftragter alle verstehen können, was gezeigt wird.

Durch die Einbettung dieser Analytics-Module reduziert die Plattform die Anzahl der für Patient-Data-Analytics benötigten Werkzeuge. Sie hält auch mehr von der analytischen Reise innerhalb einer Umgebung, die für Datensicherheit, Provenance und NHS-Governance gestaltet ist. Für viele Teams ist dies genauso wichtig wie das visuelle Design selbst.

Da Akrivia mehrere Institutionen bedient, musste die Plattform sich als Multi-Team-Healthcare-Datensystem verhalten statt als einzelnes Projektwerkzeug. Workspaces, Projekte und Berechtigungsebenen wurden definiert, sodass NHS Trusts, akademische Gruppen und Pharma-Partner dieselbe klinische Forschungssoftware teilen konnten, ohne Governance-Grenzen zu verwischen. Jede Studie sitzt innerhalb eines klar abgegrenzten Kontexts mit eigenen Genehmigungs- und Datenzugriffsregeln.

Data-Governance-Beauftragte waren in die Gestaltung des Modells für Zugriffsanfragen, Genehmigungen und Auditing involviert. Das Interface macht klar, welche Datensätze ein Benutzer sehen kann, welche Rolle er hat und welche Aktionen zu jedem gegebenen Zeitpunkt erlaubt sind. Dies ist für GDPR-Compliance bezüglich sensibler Gesundheitsdaten essenziell. Healthcare-UX-Design geht hier nicht um Komfort, sondern darum, unangemessenen Zugriff zu verhindern, ohne komplexe Richtliniendokumente auswendig lernen zu müssen.

Die Plattform bewahrt auch einen expliziten Audit Trail analytischer Aktionen, sodass Governance-Teams überprüfen können, wie eine Kohorte konstruiert wurde und wie klinische Daten verwendet wurden. Dies reduziert die Belastung durch Compliance-Reporting und gibt Institutionen mehr Vertrauen, wenn sie ihre Datensätze für breitere Forschungsnutzung öffnen.

Das visuelle System für die Akrivia-Plattform wurde als eigenständiges Healthcare-UX-Design behandelt. Die meisten Bildschirme präsentieren eine neutrale, ruhige Oberfläche für konzentrierte Arbeit mit klinischen Daten. Typografische Hierarchie ist klar und hilft Benutzern, zwischen Struktur, Inhalt und Steuerungen ohne bewusste Anstrengung zu unterscheiden. Interaktionsmuster sind über Module hinweg konsistent, sodass Forscher Verständnis von Kohortenerstellung zu Analytics und Workspace-Management übertragen können.

Farbe wird sparsam und mit definierter Bedeutung verwendet. Im Query Builder trennt sie logische Gruppen und hebt aktive Bedingungen hervor. In Analytics-Ansichten entspricht sie Kohorten oder Outcome-Zuständen statt dekorativen Paletten. Das Ergebnis ist ein klinisches Interface Design, das über lange Sitzungen lesbar bleibt, Supervision und Überprüfung unterstützt und nicht mit dem Inhalt konkurriert.

Für Medical-Software-UX ist diese Zurückhaltung eine strategische Wahl. Die Umgebung muss sich für NHS-Personal, Akademiker und Pharma-Forscher zuverlässig anfühlen, die sich für ernsthafte Entscheidungen auf die Anwendung verlassen. Die Designsprache unterstützt dieses Vertrauen, indem sie Klarheit, Konsistenz und Lesbarkeit über ausdrucksstarke visuelle Effekte stellt.

Von Anfang an behandelten Designer und Engineers die Akrivia-Plattform als langlebige Healthcare-Software, nicht als kurzfristigen Prototyp. Das Produkt ist eine webbasierte klinische Forschungsplattform, die mit bestehenden Datenpipelines und operativen Systemen integriert werden muss. Technische Workshops zu Beginn des Projekts klärten Einschränkungen bezüglich Performance, Sicherheit und Deployment, sodass Interaktionsmodelle nicht mit architektonischen Realitäten kollidierten.

Parallel dazu wurde ein Design System erstellt, um die Implementierung und zukünftige Roadmap zu unterstützen. Es definiert Komponenten für Query-Blöcke, Patientenakten-Ansichten, Analytics-Panels, Workspace-Management und Navigation, jeweils mit präzisen Verhaltensregeln und Zuständen. Für Entwickler fungiert diese Bibliothek als Vertrag. Sie verknüpft Healthcare-UX-Design-Entscheidungen mit konkreten Implementierungsdetails in einer Form, die über die Zeit stabil ist.

Während des Builds blieb das Design-Team involviert, um Fragen zu beantworten, Muster anzupassen, wo das Engineering Randfälle aufdeckte, und sicherzustellen, dass die klinische Forschungssoftware sich wie beabsichtigt in echten Umgebungen verhielt. Dies vermied die übliche Lücke zwischen Konzept und Produktion und gab Akrivia eine Grundlage für mehrere Jahre Produktevolution.