Prima di definire le schermate, il team ha esaminato la letteratura accademica sulle cartelle cliniche elettroniche e sull’analisi dei dati sanitari. Su trentadue articoli, inclusi diversi pubblicati su riviste come il Journal of Biomedical Informatics, otto studi sono stati identificati come direttamente rilevanti per le decisioni di interfaccia. Hanno analizzato come clinici e ricercatori effettuano ricerche nei sistemi EHR, con quale frequenza perdono il contesto durante sessioni prolungate e dove il design delle interfacce EHR non rende visibile la provenienza dei dati.

Questi studi descrivevano comportamenti concreti. Gli utenti passano spesso avanti e indietro tra dati clinici strutturati e note narrative. Si affidano a schemi temporali nella cartella del paziente, ma perdono traccia dei filtri attivi. Quando le query vengono affinate ripetutamente, la cronologia delle decisioni diventa opaca, compromettendo la riproducibilità. I dati clinici sono tecnicamente ricchi, ma cognitivamente fragili.

I risultati sono stati tradotti in requisiti per il software di ricerca medica. La piattaforma di dati sanitari doveva offrire chiari indicatori di provenienza, una cronologia delle query visibile e una vista stabile dei dati dei pazienti attualmente in ambito. I principi di design delle interfacce EHR tratti dalla letteratura sono stati utilizzati come vincoli piuttosto che come elementi decorativi. La piattaforma doveva aiutare gli utenti a comprendere dove si trovavano nei dati e come ci erano arrivati.

Attraverso Sandbox Experiments, una fase di discovery di due settimane ha combinato ricerca qualitativa e analisi dei compiti con utenti provenienti da tre contesti. Quattordici interviste individuali e tre focus group hanno riunito ventiquattro partecipanti, tra cui analisti NHS, ricercatori accademici e personale della ricerca farmaceutica. Ogni gruppo operava con vincoli istituzionali e processi di approvazione diversi, ma tutti dovevano svolgere analisi dei dati dei pazienti sugli stessi dataset di salute mentale.

I team accademici hanno descritto lunghi processi di approvazione etica e di accesso ai dati prima di poter persino accedere a software di ricerca clinica che utilizzavano vere cartelle cliniche. I team pharma avevano più spazio per l’esplorazione iniziale, ma in seguito nel progetto dovevano affrontare rigorosi obblighi di reporting e audit. Gli analisti NHS utilizzavano strumenti simili per la valutazione dei servizi e avevano bisogno di confini chiari tra ricerca e uso operativo. Queste realtà hanno influenzato il design più di qualsiasi descrizione generica di persona.

L’analisi delle attività ha mappato la sequenza di azioni lungo l’intero percorso di uno studio, dall’idea iniziale all’estrazione finale. La ricerca ha confermato che la confusione emerge spesso durante i passaggi di consegne tra persone o tra fasi di governance. Questa intuizione ha portato a una forte attenzione sulla continuità del workflow e su stati chiari, in modo che la stessa piattaforma di dati sanitari potesse supportare percorsi di approvazione molto diversi senza frammentare l’esperienza.

Per comprendere la base di riferimento per i software di ricerca clinica, nove strumenti commerciali di Healthcare Analytics sono stati benchmarkati in modo approfondito. Non si trattava di prototipi accademici, ma di prodotti reali utilizzati in ospedali, istituti di ricerca e nell’industria. La valutazione ha analizzato i query builder, il design delle interfacce EHR, i modelli di workspace, gli audit trail e il modo in cui ogni sistema esponeva la logica di selezione delle coorti di pazienti.

Sono emersi diversi problemi ricorrenti. Alcuni strumenti mostravano solo il risultato finale di una query, lasciando gli utenti incerti su quali condizioni fossero state effettivamente applicate. Altri costringevano i ricercatori a seguire procedure fisse a fasi che non rispecchiavano il modo in cui gli studi sulla salute mentale evolvono nel tempo. La provenienza dei dati era spesso nascosta nei log tecnici invece di essere presentata come parte dell’esperienza utente. Anche quando le funzionalità erano ricche, la UX del software medico rendeva difficile fidarsi dei risultati.

Il benchmark non si è limitato a criticare i concorrenti. Ha chiarito quali schemi gli utenti conoscevano già, come i controlli di filtro familiari, e quali problemi strutturali dovevano essere evitati. La piattaforma Akrivia è stata posizionata come una piattaforma di dati sanitari che rende esplicito il ragionamento alla base dei risultati e rispetta i carichi cognitivi e normativi della ricerca sulla salute mentale, invece di seguire convenzioni generiche di business analytics.

Sulla base della ricerca e del benchmarking, tramite option space mapping sono stati proposti cinque distinti modelli di interazione per la creazione delle coorti. Uno funzionava come un wizard, guidando gli utenti attraverso passaggi sequenziali. Un altro presentava la query come blocchi logici annidati. Un terzo organizzava le condizioni attorno alla timeline della cartella clinica del paziente. I modelli rimanenti enfatizzavano il riuso di frammenti di coorti o il confronto affiancato tra varianti. Ognuno rappresentava un’ipotesi diversa su come pensano i ricercatori clinici.

Questi modelli hanno attraversato sei cicli di design con una fedeltà crescente, dai wireframe ai prototipi interattivi. Otto sessioni di usability con utenti NHS, accademici e pharma hanno testato attività realistiche, come la creazione di una coorte di depressione resistente al trattamento o l’adattamento di una coorte esistente a nuovi criteri di inclusione. I partecipanti sono stati osservati mentre cercavano di comprendere decisioni passate, modificare le condizioni e spiegare la loro logica a un collega.

Il query builder finale nel software di ricerca clinica è una convergenza di questi esperimenti. Mantiene la leggibilità del modello annidato, riprende i riferimenti temporali dal modello basato sulla timeline e incorpora frammenti riutilizzabili tra progetti. In termini di healthcare UX design, offre libertà di esplorazione senza sacrificare la tracciabilità, che è fondamentale per la governance e la revisione scientifica.

Oltre alla selezione delle coorti, la piattaforma doveva supportare anche l’analisi dei dati clinici nello stesso ambiente. La piattaforma di dati sanitari integra moduli per statistiche descrittive, esplorazione delle correlazioni e viste comparative tra coorti. I ricercatori possono esaminare le distribuzioni delle misure chiave, seguire le traiettorie degli esiti e confrontare le risposte ai trattamenti senza esportare prematuramente i dati verso strumenti esterni.

La visualizzazione segue una grammatica chiara, pensata per i software di ricerca medica. I grafici basati sul tempo aiutano i team a vedere come evolvono i punteggi dei sintomi prima e dopo i cambiamenti di trattamento. Le viste comparative mostrano le differenze nei modelli di prescrizione o nell’uso dei servizi tra le coorti. Queste viste non sono dashboard decorative, ma strumenti per il ragionamento clinico. Sono progettate affinché uno statistico, uno psichiatra e un responsabile della data governance possano tutti comprendere ciò che viene mostrato.

Integrando questi moduli di analytics, la piattaforma riduce il numero di strumenti necessari per l’analisi dei dati dei pazienti. Inoltre, mantiene una parte maggiore del percorso analitico all’interno di un ambiente progettato per la sicurezza dei dati, la provenienza e la governance del NHS. Per molti team, questo è importante quanto il design visivo stesso.

Poiché Akrivia serve più istituzioni, la piattaforma doveva comportarsi come un sistema di dati sanitari multi-team piuttosto che come uno strumento per un singolo progetto. Workspaces, progetti e livelli di permesso sono stati definiti in modo che NHS trust, gruppi accademici e partner pharma potessero condividere lo stesso software di ricerca clinica senza confondere i confini della governance. Ogni studio si colloca in un contesto chiaramente delimitato con proprie regole di approvazione e accesso ai dati.

I responsabili della data governance sono stati coinvolti nella definizione del modello per le richieste di accesso, le approvazioni e gli audit. L’interfaccia rende chiaro quali dataset un utente può visualizzare, quale ruolo ricopre e quali azioni sono consentite in un dato momento. Questo è essenziale per la conformità al GDPR in relazione ai dati sanitari sensibili. Qui il healthcare UX design non riguarda la comodità, ma la prevenzione di accessi inappropriati senza la necessità di memorizzare complessi documenti di policy.

La piattaforma mantiene inoltre un audit trail esplicito delle azioni analitiche, in modo che i team di governance possano verificare come è stata costruita una coorte e come sono stati utilizzati i dati clinici. Questo riduce l’onere del reporting di conformità e offre alle istituzioni maggiore sicurezza nell’aprire i propri dataset a un uso di ricerca più ampio.

Il sistema visivo della piattaforma Akrivia è stato trattato come un vero e proprio elemento di healthcare UX design. La maggior parte delle schermate offre una superficie neutra e silenziosa per il lavoro concentrato con i dati clinici. La gerarchia tipografica è chiara e aiuta gli utenti a distinguere tra struttura, contenuto e controlli senza sforzo consapevole. I pattern di interazione sono coerenti tra i moduli, consentendo ai ricercatori di trasferire la loro comprensione dalla creazione delle coorti all’analytics e alla gestione dei workspace.

Il colore viene utilizzato con parsimonia e con un significato ben definito. Nel query builder separa i gruppi logici ed evidenzia le condizioni attive. Nelle viste di analytics corrisponde alle coorti o agli stati di outcome, invece di usare palette decorative. Il risultato è un design dell’interfaccia clinica che rimane leggibile durante sessioni prolungate, supporta la supervisione e la revisione e non compete con i contenuti.

Per la UX dei software medicali, questa sobrietà è una scelta strategica. L’ambiente deve trasmettere affidabilità al personale del NHS, agli accademici e ai ricercatori pharma che fanno affidamento sull’applicazione per prendere decisioni importanti. Il linguaggio di design sostiene questa fiducia privilegiando chiarezza, coerenza e leggibilità rispetto a effetti visivi espressivi.

Fin dall’inizio, designer e ingegneri hanno trattato la piattaforma Akrivia come un software sanitario di lunga durata, non come un prototipo a breve termine. Il prodotto è una piattaforma di ricerca clinica basata sul web che deve integrarsi con le pipeline di dati e i sistemi operativi esistenti. I workshop tecnici all’inizio del progetto hanno chiarito i vincoli legati a performance, sicurezza e deployment, in modo che i modelli di interazione non entrassero in conflitto con le realtà architetturali.

In parallelo è stato creato un design system per supportare l’implementazione e la roadmap futura. Definisce componenti per i query block, le viste delle cartelle cliniche, i pannelli di analytics, la gestione dei workspace e la navigazione, ciascuno con regole di comportamento e stati precisi. Per gli sviluppatori, questa libreria funge da contratto. Collega le decisioni di healthcare UX design a dettagli di implementazione concreti in una forma stabile nel tempo.

Durante la fase di build, il team di design è rimasto coinvolto per rispondere alle domande, adattare i pattern quando l’ingegneria individuava edge cases e garantire che il software di ricerca clinica si comportasse come previsto in ambienti reali. Questo ha evitato il consueto divario tra concept e produzione e ha dato ad Akrivia una base per diversi anni di evoluzione del prodotto.