Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 24 Next »



Program Resource System (PRS)

Objective

To uncover the users, use cases, and pain points of the legacy Program Resource System (PRS) and identify features and requirements for the new PRS 2.0 system. 

The PRS is a repository of demographic information for hospital providers in the Centers for Medicare & Medicaid Services (CMS), Survey and Certification System (CASPER), and Quality Improvement and Evaluation System (QIES). PRS assists Quality Improvement Organizations (QIOs) and Program Support Contractors in maintaining CMS Programs and providing hospital information used in Hospital Quality Reporting (HQR) applications.

Problem

The legacy PRS system (PRS 1.0) is decades old, very outdated, and not actively supported. CMS wants to decommission PRS 1.0 and replace it with a new, redesigned PRS 2.0. However, CMS does not have a subject matter expert (SME) that fully understands what's in PRS, who's in PRS, and its data flow between multiple CMS systems. Multiple groups know a piece of the puzzle, but no one knows the whole picture. The overall lack of understanding of PRS 1.0 results in the following issues:

  • CMS stakeholders are unable to make informed business decisions regarding PRS
  • Difficult to redesign and define requirements for the new PRS 2.0 system
  • Unable to prioritize what needs to be done to decommission PRS 1.0

Goals

  • Understand the PRS 1.0 users, use cases, and pain points
  • Create a solution that aligns with the needs of the business and user
  • Identify problem statements and areas of focus for the PRS 2.0 redesign
  • Become PRS SMEs to effectively improve the user experience for PRS end users
  • Provide guidance to CMS for the current and future state PRS data flow
  • Create an artifact repository for PRS 1.0 research and analysis

Stakeholders

Primary Customer

    • Director, ISG/CMS

End-users

    • Beneficiary and Family Centered-Quality Improvement Organizations (BFCC-QIOs) are the point of contact when Medicare beneficiaries or their families want to file a quality of care complaint or make an appeal.
    • Quality Innovation Network-Quality Improvement Organizations (QIN-QIOs) work with providers, stakeholders, and Medicare beneficiaries to improve the quality of healthcare for targeted health conditions.
    • Health Services Advisory Group (HSAG) collaborates with patients, families, caregivers, hospitals, nursing homes, home health agencies, physician offices, and other stakeholders in order to improve healthcare.

    • The CCSQ Service Center is always seeking to innovate and grow in order to achieve our mission of providing world class customer service and advancing the CMS mission.

Approach

We used our HCD process to structure our research and design activities. This process continuously evaluates the user experience and engagement so that all work completed is focused on improving design and providing value to customers and end users. There are 4 total stages, and within each stage is multiple phases where HCD activities take place to support the goals of that phase.

  • Strategize phase: We prepared a research strategy which included what type of research studies we would conduct and why, and what artifacts would come out of each study. We discovered the end user's needs, pain points, and challenges through secondary/existing research, a heuristic evaluation of PRS 1.0, areas for improvement, and user interviews.
  • Design phase: We ideated new solutions to address our problem statements via wireframes and created low-fidelty prototypes to test and evaluate with PRS 1.0 users. Simultaneously we conducted card sorts and surveys to help prioritize features and validate user needs.
  • Customer Engagement & Experience Improvement Cycle: Throughout each activity there has been multiple collaboration and analysis sessions with the internal team and CMS stakeholders. We leveraged Miro, an online whiteboarding tool to facilitate these sessions to document data flows, tabular analysis and user flows.

Methodologies & Activities

  • Analysis of secondary/existing research
  • Heuristic evaluation of PRS 1.0 and areas for improvement
  • 13 User Interviews across 4 user groups
  • 6 Wireframe Usability Tests
  • 2 Card Sorting activities
  • 1 Survey
  • 4 Personas (BFCC-QIO, QIN-QIO, HQR Support, Service Center)
  • Collaboration and analysis via online whiteboarding tool (Miro) as project source of truth
  • Continuous analysis and artifact creation (data flow diagrams, tabular analysis, user flows, etc.) See Artifacts on right of page.
  • Multiple iterations of wireframes and InVision prototyping
  • Consistent interfacing with relevant stakeholder application development organizations (ADOs)

Challenges

  • Finding the true picture of data - "we don't know what we don't know"
  • Determining the source of truth for the data and who owns the data
  • No PRS subject matter expert (SME)
  • Many moving parts, dependencies, and availability of key stakeholders
  • Lack of prioritization for this effort across dependent ADOs

Results / Metrics

The findings and documentation we have produced from using various HCD methodologies have resulted in:

  • PRS 2.0 problem statements, vision, and goals identified
  • Dozens of research artifacts created on Miro
  • PRS organizational level personas
  • Initial design and direction determined for PRS 2.0

What's Next?...

The team is now ready to move into the next phases of the HCD process: Develop and Launch
Future activities will include testing the coded design, ensure product quality by conducting QA testing, and communicating and deploying PRS 2.0.


The content of this case study was provided by Sara Neel, Lead UX Designer and Meghan Nichols, Lead User Researcher.

Program Resource System (PRS) Artifacts

(Click to enlarge)

Organizational Persona


User Groups


Card Sorting Categories


Card Sorting Results


User Task Flows


Data Flows


User Interview Analysis


Full Board Analysis


  • No labels