2022
Medtech Product Design
Lead Product Designer
Single Org Study (PII and No PII)
Medable encounters a challenge in supporting multiple organizations (orgs) for a single study. To grasp this challenge fully, let's begin by clarifying the meanings of "org" and "environment" within the context of Medable.
Org
refers to a single instance of the Medable platform that should be able to support a single study. Ideally, orgs and studies should have a 1:1 relationship, but this is not always the case currently.
Environment
is a copy of an org that is used for development and testing purposes. Each org has three environments: Development, Testing, and Production. All three environments should have the same build and workflows as the production environment, but they serve different purposes.
Medable studies need multiple organizations due to regulatory requirements in certain countries like France. Here, personal identifiable information (PII) must be stored separately from personal health information (PHI). The challenge arises because the Medable platform can only assess whether a study allows PII or not at the study level. This setup means an organization either has PII or does not, while clinical trial studies may have varying PII requirements from country to country, as is evident with sites in France.
See below how you currently determine if a study allows PII or not at the study/org level
When a study requires both PII and No PII organizations, a TPM duplicates the PII organization by transferring the PII study to the No PII organization. Given the potential for errors in this process, DSDs must scrutinize the new No PII build to confirm its alignment with the PII organization. Following this, QAs review and QEs test the build to ensure everything functions as intended. This entire procedure is quite time-consuming for the delivery team, clocking in at a total of 512 hours. In terms of costs, this process amounts to $35,840 in Medable hours, with each hour priced at $70.
CS invests significant time duplicating studies and managing two organizations once a study is live. With the complete suite of applications, a single study in a single organization needs 21 URLs. However, supporting the same study across two organizations with the full suite demands 78 URLs, doubling the time for building, testing, and maintenance. Now, having a single study support both PII and No PII cuts the URLs down from 78 to 21, streamlining the entire process.
(see below)
Medable needs to support studies in countries with differing PII requirements within a single org. To do this, they will establish a "No PII Site" for sites that don't collect PII. With the new ability to assign PII status at the site level, they can support studies with both PII and No PII sites in a single org. They will use the current participant-site relationship to execute the site-level PII feature and handle participant invites and tasks accordingly. However, moving the No PII flag from the study level to the site level creates challenges in determining a participant's site and PII status in the user flow. This requires changes to Patient App sign-in, enabling separate authentication tasks within the same study build, and a new unified forgot username and password flow.
UX Research, Product Design, UI Design
Initial research focused on better understanding user’s ability to use one centralized app that will drive users with PII and No PII.
Focus Areas
-
01
What Why should a customer use this service/feature?
-
02
What do you want someone sitting across the table at lunch saying about your product?
-
03
How will we measure success?
-
04
Why do we believe this release will be successful?
Five participants were interviewed in-depth to identify their pain points and feedback in managing PII and No PII within Medable's app.
“moving to a single org would reduce time to completion by 40-50% for the DSDs, TPMs, and QE. Having PII assigned at the site level poses no foreseeable risks.”
John Walton (Dir, Tech Solution)
“Submitting identical apps to the App Store leads to confusion and delays because Medable needs to explain the rationale behind submitting identical apps. If we move to a single org, consent reports in Study Manager should contain eConsents and e-signatures for paper consents.”
Amy Pegg (Sr. Lead Implementation Mgr)
“the financial impact of multiple orgs to support a single study. Using the approximation that CS costs $70/hour, we can estimate the time savings by enabling a single org to support a study that has PII and no PII requirements.”
Kofi Akomeah (Finance)
After conducting user interviews, we synthesized responses from all participants to create a flowchart, pinpointing areas that Medable could concentrate on for improvement.
-
01
The delivery team and our enabled partners should utilize this service as it will decrease the time needed to build, test, and maintain studies by 33%, thereby accelerating the overall process of building and deploying studies.
-
02
The configuration flexibility for studies supporting both PII and No PII sites has cut down the time required to build studies involving countries like France. This efficiency saves time for roles such as TPM, Engineer, or DSD, allowing a focus on finding better ways to enhance customer delivery.
-
03
Fewer URLs per study, Fewer orgs to support a single study, Drastically reduce the cost of study build, and Accelerate time to deploy studies
-
04
We've thoroughly researched the requirements for supporting both PII and No PII Sites within a single organization. Introducing PII at the site level will streamline the study building and deployment process, aligning with our company-wide goal of reducing time and effort. This new functionality is expected to be highly motivating for our user base.
Delivery Teams
-
01
Data Stewardship Directors (DSD)
-
02
Trusted Platform Module (TPM)
-
03
BE Engineer
-
04
Enabled Partners
To tackle the earlier mentioned issue, the Participant Onboarding Team focused on creating a centralized application customizable through Study Builder, replacing Study Manager. This strategy aims to cut deployment costs and enhance support. Clinical trial sites can now decide if participants share personal information (PII or No PII), streamlining Medable's efforts in designing, developing, testing, and deploying the trial just once.
To initiate the design process, I started with quick sketches to put my ideas on paper and determine the essential elements for each screen. Following that, a low-fidelity prototype was crafted for the initial round of user testing.
This main user flow includes signing in, specifying whether it involves PII or No PII, and outlining the steps to regain access.
I quickly doodled some rough sketches to jot down my initial ideas and brainstorm fresh concepts for specific UI elements.
Created Lofi wireframes to visually comprehend the flow, following initial sketches. Presented the wireframes to the team for review, enhancing overall understanding of the design.
Moving the option to select PII or No PII to the Site Level
At the patient level, we made a change by combining the 'email' and 'username' text input fields into one. This allows users to enter either their email address or a unique username to log in. As PII and No PII were merged, if a user forgets their username or password, they will need to determine if their site is categorized as PII or No PII. In the case of No PII, participants will have to contact their site to retrieve their login credentials.
If the user forgot their password and is PII they will go through the flow of retrieving their password via email.
During the project, our team made some big strides in setting up the foundation for a centralized app. We dug deep, collaborated a ton, and ended up cutting the number of URLs from 78 to 21. Plus, we slashed the cost of running trials by 40-50% and made scaling a breeze for Medable. We even ran user tests with clinicians, the VP & GM of eConsent, our own folks, and some nurses in charge of participant care in ongoing trials to see how the changes were playing out. Long story short, the project nailed its goals.
After checking out this study, turns out our users are pretty stoked with the results. Everyone's on board because, you know, cutting down the time to build and deploy is a company thing. Our users are all in for trying out the new functionality.
