CASE STUDY
Medical Record Retrieval
Domain: Healthcare
Project Type: B2B
Platform: Web
To comply with the non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. The information in this case study is my own and does not necessarily reflect the views of my previous organization.
My Role
As a single UX point of contact, I was involved in working sessions and stakeholder interviews with product owners, SMEs and end users to holistically understand requirements and drive design decisions in a collaborative environment with business analysts, visual designers and development teams.
Ideation and Experience Strategy
Partnered with product owners and business analysts to discuss, uncover insights and translate broad level business requirements into features that address customer behaviours and motivations. Created rapid prototypes to share the vision, design principles and content strategy. This helped to evangelise ideas, gain alignment and drive decision making.
Planning and Scope Definition
Defined product by envisioning customer needs while balancing the business goals. This was achieved by identifying key user groups, their tasks, the challenges they face and gaps in existing solutions in the market.
Design Execution and Validation
With clear journeys defined for each user group, low fidelity prototypes were iterated upon. These include paper prototypes and whiteboard sketches for quick feedback from the internal teams. With consensus on a design, high fidelity wireframes were iterated using actual content. These designs at later stage were validated through extensive Usability Testing with end users.
Oversight and Co-ordination
As the product evolved, I collaborated with 6 developers and 2 business analysts to understand the entire product ecosystem and its integration with multiple platforms to stitch a product suite.
Leadership
Designs were presented to gain buy‐in from product owners, development teams and a few prospective clients throughout the project lifecycle.
Approach
Extensive primary & secondary market research was done by the product team to identify key areas in the payer market that needs attention. This research was supported and validated by multiple payers, providers and end users to pave way for this product.
Problem Statement
The existing inefficient process of manually identifying, retrieving and recording gaps during audit season or year round services that were rendered (but not reported) was unsuccessful in meeting the NCQA guidelines.
The Vision
Introducing Medical Record Retrieval (MRR)
MRR is a tool to improve quality of care & Health Plan (Insurance Firm) performance in clinical quality programs for closing the gaps in existing patient records.
Understanding the Ecosystem
One of the crucial aspect of this project was to understand MRR in its alliance with live CitiusTech products and how it leverages well established production setup to best suit the client requirements.
Rules Management Module (RMM), Business Intelligence Clinical (BIC) had to come along with Medical Record Retrieval form SCORE+, a holistic data integration and aggregation framework to implement HEDIS measures, campaigns and processes.
MRR Timeline
-
Health Plans in U.S.A. need to run campaigns to collect missing documents for the services that were provided but not recorded, from a regulatory stand point to NCQA (National Committee for Quality Assurance) by the end of a year. To do so, these campaigns run from October to December and records received are logged in the following year for accreditation. Considering these were for records from the previous year, they are termed as 'Retrospective Chase'.
-
However, Health Plans also run campaigns for the ongoing year which are termed as 'Prospective Chase' or 'Year Round Chase'.
-
Retrospective Chase uses a limited cohort to represent the entire population considering the limited time span to close gaps in records. Prospective Chase however, ensures the gaps are actively closed for entire population in a timely manner and also helps in providing improved care to members.
Campaign Manager
Admin
Chaser
Abstractor
Reviewer
- Create Campaign
- Monitor Campaign
- Assign Admin
- Update Information
- Replace Provider
- Replace Member
- Provider Outreach
- Provider Follow-up
- Notify CM
- Contact Provider
- Collect Charts
- Upload Charts
- Abstract Charts
- Request Charts
- Review Abstractions
- Edit Abstractions
- Close Chase
Identifying User Groups
Key user groups and their day to day tasks were identified basis multiple interactions with stakeholders happening on regular basis. The existing process of 'Chase' already have these active user groups but interviews and discussions helped clearly define 5 major Personas.
Persona
A deep understanding of target audience acted as a guide in the ideation process and have helped create meaningful products. 5 personas were created to understand their expectations, concerns & motivations in context of their day to day tasks, providing a clear direction for design.
Abstractor
Campaign Workflow
-
Once the systems, its actors, their tasks, steps and online/offline activities required to complete a goal were defined, creating a work-flow provided a general overview of a business process and often a foundation for other documentations like use cases.
-
It provided a visual representation of how those individual elements connect and/or interact and identified what conditions allow the sequence to move forward.
Information Architecture
Equipped with a broad level understanding of the product/business requirement, users, their goals, tasks and challenges we started with the landing page 'Information Architecture' to give us structural design to build on. This formed a backbone of the entire application.
Low Fidelity Wireframing
Creating low fidelity prototypes helped in quick feedback or buy-in from both product owners as well as the development team and set up a base for detailed design later.
Landing Page: Campaign
Landing Page: Workspace
Create Campaign: Define Cohort
Create Campaign: Basic Details
Detailed Design
At this stage, more value was added to the designs with relevant content to make it look as close as the actual product. This gives a better view of how the users may perceive certain features or functionalities of the product and the way they would possibly interact with them.
Landing Page: Workspace
Create Campaign: Basic Details
Abstraction
Reports
New Proposal: Tablet Version
-
During the course of desktop version designs, parallel discussions and interviews with key stakeholders revealed that in some payer organisations, the chaser and abstractor roles overlapped.
-
This new insight got us a unique use case of a chaser/abstractor scheduling and visiting providers to collect documents during the day, then uploading them in the system with relevant tagging at the end of a day/week and later abstracting them to close on gaps.
-
This process was a huge cost to the company considering the amount of time spent on visits, manual upload and abstraction. Moreover, the overall gap closure progress rate would take a hit.
-
It was proposed to have a tablet version which the chaser can access on the move and upload the charts at the provider facility itself, along with relevant tags.
-
However, considering the PHI data and certain security apprehensions, this concept was parked and not explored further.
Chaser/Abstractor Tablet Workspace
Design Challenges
The sheer size of this project and its complexity threw its fair share of challenges at every stage of design. Finding a way to represent a wide range of crucial data on a single page, identifying unique 'use cases' not defined in requirement documents, the requirements itself evolving over the course of stakeholder discussions or updates to design due to development feasibilities were some of the common occurrences.
One such stimulating design feature was 'Upload' for the chaser persona. It involved a chaser uploading a clinical chart into MRR and tagging it for provider it was received from, patient for which the chart was requested and the measure against which there is gap in records.
Complexity of this 'small' requirement compounded when we identified multiple scenarios of many-to-many mapping as well as possibly multiple entry points for the same set of activities
Upload Scenarios
Development Support
As more and more journeys started taking shape and reaching completion after detailed designs, parallel discussions were scheduled with the Lead Architects, Senior Developers and QA Lead to define user stories and tackle any back-end/front-end related road blocks. Each team with its own sets of challenges like timelines, resources and/or capabilities would try to find a middle ground with the designs.
The support was not limited to discussions but also post development of certain user journeys, where a UX review of the UAT links would be conducted to make sure the UI guidelines are being followed to ensure visual as well as usability consistency throug multiple development teams.
Validation
Once the UAT version was developed, we knew we needed to put it in the hands of our customers. 20 participants across 5 user personas were recruited for Usability Testing to get insights on key tasks and features.
Usability Test Protocol was created for an hour long session with each participant to understand:
-
Discoverability/legibility/readability issues
-
Blind spots on the screen
-
Ease/difficulty with which a task is completed
-
Things they liked/disliked about the application
-
Their feelings about this new application
The feedback captured by note takers and video recordings was used to generate a detailed 'UT Analysis Report'. The report was further used to identify high/low impact and critical/noncritical changes to revisit the drawing boards and follow the same iterative design process in collaboration with development teams and business analysts. This helped in creating a product which is closer to what the users actually need.
Product Evolution
In 2 years span, the project grew exponentially with regular insights from new prospective clients, each having their unique set of requirements to cater to their needs. This resulted in branching out of product features and creating a custom fit solution, not just from UX stand point but also from backend architecture as well.
The regulatory guidelines too had its own impact for development with updates to measures list, the compliance/non-compliance conditions and even the way cohort sampling was done to define a campaign.
From 'no client' at the start of this journey to now '4 clients' actively using MRR and possibly many more in the future, the evolving nature of it should help it sustain for a long time.
The Impact
This application has proved to be a one stop shop for clients, who were so far relying on traditional methods of identifying, chasing, logging and tracking the missing clinical records. And although these methods were functioning well, they could not do justice to the time and effort invested by a payer.
With MRR, all users can work in a collaborative environment with better visibility and well defined actionables to ensure the campaigns are efficiently run with desired outputs adding value to all stakeholders involved.
What I Learned
Trust the Design Process
Considering it was a new domain for me and also the fact that there was no similar product in the market meant that we as a team were taking a shot in the dark. However sticking to the design process helped in gradually progressing and get in the groove for larger things.
Development for Design OR Design for Development
As designers we always advocate for good user experience and ensure users are at the centre of every design decision. However, either due to strict timelines or limited resources or sometimes due to genuine technical challenges, the designs are requested to be updated to ensure MVP dates are met. The development team and/or product team knowing the fact that these changes may impact user experience end up having it their way, which then makes you think if we are designing for the user or the developers.
User Validations are Critical
No matter what we design or develop as a product team, validating it with end users is the most important step for any project, which helps steer the ship in the right direction at the right time. Earlier the validations, lower the cost of development updates and easier to meet project timelines.
