The United States Health Care industry is not known for its ability to adapt. Its complex, distributed market structure, intensely regulated, typically disconnected payer/provider/consumer relationships and potential life and death service consequences flow into a cautious, slow-to-change marketplace. Yet the very size and complexity of the industry creates a need for systematic process analysis and improvement. One quarter of all health spending goes to complete administrative activities, including revenue cycle functions, rather than direct patient care services. That is real money, and the industry has a business and ethical obligation to improve administrative processes.
Agile, a process management approach adapted from software development that promotes innovation, may seem an odd choice for a historically rigid industry. With its emphasis on inclusivity, data-driven feedback, customer focus, rapid results, and iterative improvement cycles, agile is exactly the approach to build performance improvement into the traditionally hierarchical, slow to change health care industry. Its popularity has grown, with even large organizations creating flexible organization and management processes using agile methods at scale rather than legacy management models.
Why Agile?
Agile (and its related approaches like Scrum, Kanban and Lean) offers a number of critical advantages. An agile approach has key foundational qualities:
- Inclusive by nature. Agile charters authorize horizontal involvement across the organization hierarchy in the process and the authorization of the team to immediately engage with required resources. No need to get them approved through a committee process. You can’t address health care administrative and revenue cycle issues without bringing together a wide and diverse group of people.
- Promotes adaptability by time-driven feedback loops. The disciplined meetings (Daily Stand Ups and Scrums) force focus, identify problems early and build collaborative structures. Consistent results builds performance data, which is then fed back into the effort to change/adjust focus and active engagement.
- Iterative. Discovery, discussion, design, prioritization (by product owner), build (either for technology such as work/task queues, procedural or policy changes) cycles occur on an iterative two or three week basis, with a continuous improvement emphasis.
- Customer and product owner driven. An agile approach requires a product owner be assigned who can in effect set the development priorities immediately. In revenue cycle work, this is either the Chief Revenue Cycle Officer or a director over the subject area, such as denials management.
Applying Agile in the Revenue Cycle
Denials in the revenue cycle-collection process is a window into every touch point in the revenue cycle. The root cause of a denial can be very specific to a single episode of care – or reflective of a larger systemic problem in authorizations, access, care management, coding, credit assessment or payer contracting, among others.
One organization using an agile approach to Denials process/technology improvement followed the path below:
Objective: Process Improvement & Work Tool Redesign of the Denials Management Process across all entities.
Measurement Approach: Reduction of Denials per open accounts to top quartile of performance benchmark within 180 days by payer and overall.
Performance Improvement Approach:
- Creation of charter/manifesto
- Flexible team structure
- Two to three week (maximum) sprint cycles
- Daily stand ups and weekly Scrums by sprint team; department managers as Scrum masters
- Retrospective after each sprint cycle
- Discovery(sprint one) time boxed to one sprint per subject area (i.e., Commercial denials)
- Redesign (sprint two) time boxed to one sprint per subject area (i.e., Commercial denials)
- Implementation (sprint three and beyond) must have quantitative process improvement goal-measurement for each sprint cycle
- Separate sprint process allowed for common tools across subject areas, such as core (not payer specific) denial code redesign
Product Owner: Chief Revenue Officer is product owner and is authorized to prioritize changes and resource allocation. CRO may also directly contact and assign resources from the organization for purposes of discovery and redesign sprints. For implementation sprints which require technical resources (i.e., work queue or reporting redesign), CRO will be provided with dedicated resources from relevant departments as needed for duration of sprint. CEO& CFO will arbitrate any conflicts as required.
Results: Over a three month timeframe, discovery and design, including new process maps and automated work tool designs, was completed. Corrective actions which did not require a rebuild of technology tools and work flows (i.e., profile based denial codes) and process/procedure improvements were implemented in Sprint cycle 4 and 5 (end of month 2, into month 3). Corrective training targeted to root causes with human factors involved also occurred in month 3 and 4. Technology changes (automated checking and prevention features, automated denials processing into work queues, work queue redesign, denial code standardization and usage, improved reporting) occurred in sprint cycles 6 and beyond.
After the Denials management process/technology improvement effort concluded, the organization moved on to utilization review, demonstrating the versatility of the agile approach.
