Refocusing Patient Architecture
Restructuring the information architecture of our software program to prioritize the Patient entity was paramount for our biotech company’s role as a patient advocacy organization.
Linking Subjects to Patients
Previously, the inability to link a patient’s clinical care data with that from a de-identified clinical trial led to an annoying deficiency.
Background: Patients entering the system via a clinical care order were listed as “Patient” records, including identifiable name and demographic information. On the contrary, patients who entered the system in most clinical trial orders were listed as “Subject” records; their information in these cases was de-identified for important regulatory reasons.)
We worked with SMEs to draft a solution in the UI: creating a “Human” record type. This record could serve as a parent entity and link its child Patient and Subject entities underneath it.
This redesign streamlined clinicians' access to patient-centric data, reinforcing our commitment to patient advocacy while enhancing business efficiency.
By introducing a new aggregate data tile to the UI, our users could see pragmatically helpful information about the status of recent tests and specimens.
By surfacing this real-time patient information in the interface, our analysts were able to deliver information more clearly and efficiently to the clinician customers. Ultimately, this aided the patient experience by delivering up-to-date information.
BACKGROUND
Image: the “Header Bar” component that we designed for the new Subject Details page.
Headers of pages where designated by Order, Subject, and Patient.
Image: the “Header Bar” component that we designed for the new Subject Details page.
Streamlining specimen and shipment workflows.
Based on our findings, the treatment of Specimens and Shipments would need to streamline the data transfer between OMS and LIMS and provide timely updates on shipments to manage processing.
Two key outcomes of our design solutions were:
The introduction of Flags
The redesign of the data display in Specimen tables
Data table expandable rows. (Example below)
To address the challenge of a deep and detailed information architecture of Specimens and Samples, we leveraged Carbon’s data table expandable rows:
We treated expandable rows as a way of deemphasizing secondary information on Specimens and their child elements as Samples.
We worked with the SMEs to identify which attributes of a Specimen were primary in the hierarchy and which were secondary.
We selected fluid states for the read-only fields' visual clarity, creating the feeling of a concise grid within the expandable row.
Our Design Process in the works
Results
Image: Whiteboarding and ideation highlight our first attempts to understand and resolve the specimen problems and workflows. This exploration includes information architecture, workflow definition, prioritization of pain points, and more.
Image: The result of the above whiteboarding exercise. Low-fidelity early drafts of a Specimen table.
Rapid Revision process with SME Panel - HiFi in Figma
To address the challenge of a deep and detailed information architecture of Specimens and Samples, we leveraged Carbon’s data table expandable rows:
We treated expandable rows as a way of deemphasizing secondary information on Specimens and their child elements as Samples.
We worked with the SMEs to identify which attributes of a Specimen were primary in the hierarchy and which were secondary.
We selected fluid states for the read-only fields' visual clarity; this created the feeling of a concise grid within the expandable row.
Image: Rough drafts and ideation in high-fidelity.
Image: Working Result
Image: Expandable rows shown now open.
Data-table iconography for ease of use at-a- glance using inco states.
Expanding on the IA, information architecture, users required that the data table also signify Specimen statuses:
We incorporated icons into our Carbon data tables to indicate the status.
We selected an icon to represent processing, completed, moved, discarded, and returned.
By using icons instead of text, we decluttered a text-heavy data table.
Image: Documentation showing the usage and definition of different status icons. Eg. a dotted line icon next to a specimen name signifies that the specimen is still processing.
The Carbon Data Table Toolbar.
Solution
Bringing it all together the new data table with an expandable sub-table for samples, imported data from LabVantage LIMS, with a batch selection toolbar.
We leveraged the Carbon data table toolbar (2) to address the specific needs of user’s needs in the Specimen table:
We re-used the investment in our toolbar design to include search, filter, and batch select tools.
We discovered a new set of batch-action tools that the users would require in Specimens and added them to the batch-action bar. These were particularly important in Clinical trial orders, where hundreds of Specimens may be in one order.
We identified the filtering options to address the most common workflows users use to work on Specimens.
Image: High level data table anatomy and tool bar.
Image: Active State of the Blue tool bar. When "active" Batch selection actions are present in the blue toolbar.
Dash-boarding Analytics
The IBM Carbon Design System has been instrumental in addressing the lack of dashboarding and analytics. Known for its robust suite of tools, Carbon enables teams to:
Integrating well-defined design and development standards is crucial for efficiently presenting complex data.
Facilitate a quick grasp of application functionalities and derive meaningful insights using graphs and charts.
Data Visualization for Worklists
During the initial phases of the project, the UX team undertook a design exercise focused on providing deep insights into the multifaceted layers of business operations. We introduced “insight tiles,” which employed a revised information architectural schema. This design was intended to address the various states of Workflows for clinical diagnostics, batch research orders, and their readiness, along with flagged alerts or discrepancies.
These workflows were categorized within different worklists, each queryable for unique purposes along the journey, such as:
Total number of orders awaiting resolution
Percentage of orders on the worklist unmodified in the last 24 hours
Number of orders nearing stabilization
Number of orders potentially unmodified in 3 days
Number of MRD-enabled patient orders
Number of fresh specimens (e.g., bone marrow, blood)
From a UX journey perspective, the system was designed to offer users multiple levels of insight as they begin their workday, helping them either commence new tasks or continue from where they left off.
Image: High-fidelity wireframes conceptualize a Dashboard homepage that displays all “Worklist groups” with real-time analytics and informs leadership of team progress.
Image: Worklist Groups with select data surfaced for specific persona needs and use-cases.
Image: Yet a layer deeper in the IA is the data at the work-list level.
Future Improvements
The UX team is exploring the potential of “smart tiles” that update order metadata live to inform staff better.
This innovative concept would allow users of the order management system to perform custom queries against specific views, providing even more profound and nuanced insights into the orders and clinical trial data. Users could create smart-tiles based on specific columns of interest within the custom queries, with the added functionality of saving and sharing these custom views. This capability would offer enhanced reporting tools for leadership, facilitating better decision-making and strategic planning.
