Clinical Data Repository - SaaS Design

Overview

For eight months, I worked as part of a three-person design team building the user-facing web application for a Clinical Data Repository, a system a global healthcare company uses to manage clinical trial data across its full lifecycle. My role blended lead UI design with production design: I translated a dense technical specification, covering an entire lifecycle and versioning model across six different data asset types, into interfaces that clinical, data, and medical teams could use with confidence.

By the end of my engagement, I had helped design the foundational lifecycle experience: the core screens and interaction patterns that let users see, promote, and manage assets across Development, UAT, and Production.

Information

Type

Confidential healthcare company (name withheld under NDA), engagement delivered through Perficient

Role

UX/UI Designer — blended Lead UI Design and Production Design

Industry

Healthcare / Life Sciences — Clinical Data Management

The PRoblem

The Clinical Data Repository is part of D4U (Data for the User), which uses Databricks and Postgres inside the client's AWS cloud. It was technically sound but lacked a way for users, such as Clinical Programmers and Data Managers, to view and act on data themselves. Before, there was no interface for study setup, data review, query management, or asset catalog. Users had no self-service tools. Behind this was a complex rule system that managed the lifecycle of study assets across Development, UAT, and Production, with strict versioning and promotion rules. Mistakes could lead to compliance issues. My role was to make this technical, rule-based system understandable and safe for clinical data professionals.

Screen of View section

Process & Research

The starting point for this project was not a set of user interviews; it was a dense functional specification. Each asset type had its own compatibility checks, versioning behavior, and promotion rules, and the same lifecycle logic had to apply consistently across six object types: Development always used the latest version, while UAT and Production remained frozen at the version explicitly promoted to them.

My process began by mapping that specification into a shared mental model I could design against. What does it look like on screen when an asset already promoted to UAT is modified in Development, and the system silently generates a new version behind the scenes to avoid disrupting the UAT team's work? I worked through questions like that with the UX Director, translating raw requirements into concrete interaction questions, then into flows, before applying components from the existing design system.
The diagram below summarizes that lifecycle model for this write-up. It reflects the rules I designed throughout the engagement.

Asset Lifecycle & versioning model

Applies to Pipelines, Checks, Mapping, Data Models, Tables, and Code Lists

Figure: the asset lifecycle and versioning model I designed the promotion and status interactions around.

Role & Team

What shipped was a role-based web application that covered the core lifecycle experience end to end. A few of the patterns I am most proud of:

Lifecycle and versioning were made visible wherever they mattered. Study- and asset-level status tags, version numbers, and promotion history meant nothing required a user to remember the state the system already knew.
A catalog-matching experience for assets like checks and code lists used a simple star-rating pattern to briefly show how well an available catalog asset matched a study's data model, turning a dense compatibility check into a scannable comparison.
Consistent list-detail CRUD patterns for administrative objects like vendors and permission sets were deliberately reused across the application, so once a user learned one, they could operate the rest without relearning an interaction. That consistency was a direct application of the consistency and standards heuristic, meaning the design system could scale to new object types without inventing new patterns each time.
A publish-to-catalog flow with taxonomy tagging and explicit success and failure states ensured users always knew whether their action took effect and, if not, why.
An inquiry and query management view gave Clinical Monitors and Medical Reviewers a shared space to raise, track, and resolve data questions tied directly to a study, closing a workflow that previously had no dedicated home in the platform.

The Solution

The final concept combines the strongest parts of both tested directions. The portal opens to a guided, tabbed flow (Dashboard, Smart Waste Calculator, Review Details, Billing Summary) instead of a single dense form, so residents move through the decision in stages rather than confronting all of it at once, a direct application of progressive disclosure. A persistent AI assistant sits alongside the flow, not on top of it: a searchable FAQ for quick questions, and a chat entry point for anything the guided flow doesn't cover.

The assistant supports English, Spanish, Tagalog, Mandarin, Vietnamese, and Arabic, plus voice input, so language and literacy aren't a second barrier stacked on top of an already confusing civic process. Every screen keeps container size, price, and collection schedule visible together instead of split across pages, directly answering the “poor visual comparison” problem every persona raised independently. Typography, contrast, and screen-reader compatibility were built in from the start, not retrofitted, so residents using assistive technology aren't a secondary consideration.

Shows the check parameters panel and pipeline canvas described above.

Shows the add / remove / request promotion actions available on a code list within the lifecycle model.

Show how to created taxonomies for the study

Shows the star rating pattern used to communicate compatibility between catalog assets and a study's data model.

Outcome

While I lack specific usage metrics from this project because the platform was still in development when my involvement ended, I prefer honesty over estimation. What I can confidently assert is that within eight months, the team established a functioning, stakeholder-approved foundation that covers the entire lifecycle model—development, UAT, promotion, and versioning—across all six specified asset types. The UX Director and client stakeholders approved the interaction patterns I designed, including status tags, promote flow, and catalog matching pattern. These became the reference system for managing lifecycle and versioning in future platform modules, which is the outcome I am most proud of. Instead of individual screens, I delivered reusable patterns for the platform to build upon.

The most challenging and valuable aspect was learning to design for a rule-based system before focusing on visual details. Clinical data governance demands precision and clarity, and this project was no exception. If I could revisit it, I would advocate for earlier engagement with end users, such as Clinical Monitors and Medical Reviewers, rather than routing all feedback through the UX Director's stakeholder relationships. Although this structure aided client alignment, direct usability testing with actual clinical roles—especially regarding the promotion flow—would have helped validate assumptions about irreversible actions more promptly. This experience reinforced a key lesson for high-stakes or regulated product design: the further removed I am from the end user, the more deliberate checkpoints I must build to gather their feedback.

Workflow sample

Designing for a Clinical Data Repository

A UX/UI case study on designing versioning, promotion, and asset governance for a regulated healthcare data platform.