Business solution architecture – value based care programs

Value Based Care (VBC) programs require a health plan to make major investments in people, processes, and technology in order to successfully launch and scale. There is no “one-size-fits-all” solution in the market that comprehensively addresses the complex needs of VBC programs. While some component capabilities can be supported with out-of-the-box solutions, others require custom developed solutions or significant upgrades to existing business processes and associated technical infrastructure. A successful business solution architecture brings together technical solution plans with the business processes running across the systems and overlays team operating models on top of both. Given the unique challenges of administering VBC programs, a business solution architecture is especially important in this space.

Identifying the challenges

VBC programs require proactive management and integration of a multitude of complex business processes and technical systems, utilization of legacy capabilities in new ways, and integration of new solutions that all must work together to ensure actionable and accurate end-to-end results. Below are some of the most common challenges we see our clients facing:

1. A complex ecosystem: From program and contract management to provider analytics to cost efficiency measurement, many core operational capabilities must be considered when deploying a VBC program, along with a view on how these capabilities integrate together. The added complexities that exist within each of these capabilities often increases the stakes for a health plan to successfully define, design and enable a VBC program on the first try. For example, the quality outcome measurement capability alone requires a health plan to collaborate with provider partners to achieve joint definition on which quality outcomes indicate VBC program success. Once defined, a health plan must:

• Establish the correct member population to measure against
• Determine how to accurately calculate applicable quality measures for the derived member population
• Report on and share results in a timely way so that providers may take action
• Evaluate a provider’s performance against desired program outcomes
• Reward the provider with reimbursement based on the program outcomes as appropriate
• All of these sub-capabilities may not exist in the same system, thus requiring system integration across each step.

2. A multitude of program and business rules: From a program strategy perspective, what works for one VBC program or provider may not work for another. To see success, each VBC program will have its own set of unique program and business rule requirements to operate. To build a sustainable VBC capability set, there must be flexibility in the system and processes that enable programs to scale over time.

3. An increasingly saturated vendor landscape – focused in niche component areas: There are a growing number of technology vendors that have emerged to help health plans and providers tackle these challenges. However, in almost every circumstance, no single vendor has a solution that definitively serves all of the capabilities necessary to administer VBC programs. Furthermore, VBC systems must have integration into existing technologies and core operational processes within a health plan’s organization (e.g. reimbursement systems, financial reporting systems, employer group reporting solutions, etc.).

4. Stakeholder disruption: In a world where fee-for-service (FFS) has persisted as the norm, VBC is disruptive to the operational teams, the supporting technology, and the organization responsibilities. Compounding the complexity of program implementation is the number of stakeholders required to make a program successful. VBC programs may have different teams that own different processes, underlying sub-processes, and technologies. It is not only internally managed teams and personnel that are important, but provider partners also need to be proactively engaged to ensure their systems are appropriately integrated to enable critical program components such as information sharing.

Why act now?

VBC programs should be robust with regard to the required technology, business processes, and people needed to make them successful. It is critical that health plans understand the interaction between all of the pieces of the end-to-end solution, including vended solutions, upgrades to current solutions, and custom net new solutions. Failure to do this puts a health plan at a much greater risk of seeing negative outcomes from their VBC investments.

1. First, and worst-case, VBC initiatives may fail to launch due to core decision-making challenges on foundational VBC program elements.

2. Second, without consideration of the end-to-end solution goals, health plans are at risk for incurring higher program administration costs, human error, and provider abrasion shortly following program launch.

3. Finally, a health plan may launch a VBC program that is designed and implemented to address current state needs only. Regardless of how mature a health plan’s VBC program portfolio is, they should consider the goals of their long-term VBC portfolio ambition when building systems and processes to avoid missing out on valuable opportunities for scalability and to “futureproof” their design.

Imagine a world where people, processes and technology seamlessly support core VBC capabilities and can be easily scaled to support future programs at a lower cost. This scenario becomes much more achievable when an organization puts in the necessary up-front investment of VBC business solution architecture.

The path to finding success

Health plan’s need to act now on these challenges by putting a proper business solution architecture in place to guide their VBC investments. Designing and implementing a successful business solution architecture centered around the technologies, people and processes involves several parts to ensure positive investment and program results. Before diving into the actual design of a VBC portfolio’s business solution architecture, it is important to conceptualize what the VBC program aims to achieve and how it will operate. The outcome from this activity will create the foundation inputs to the business solution architecture.

1. Build a high-level process definition: Health plans should first create a high-level process definition of new VBC programs to articulate understanding of all major objectives of the business processes. A high-level process definition will help in scoping project business goals and key success criteria. This will help a health plan focus on new program goals and success criteria so that key workflows are identified upfront, reducing the risk of change requests or scope creep later on.

2. Roadmap for the future: Once major process objectives are established, incumbent versus future state solution planning should be considered. This is a great time to perform a current and future state capabilities assessment to help understand where a health plan’s capabilities are today, compared to where they need to be tomorrow. As gaps are identified, a roadmap should be constructed to aid with planning; this is a key aspect of building a sustainable and flexible platform for the future.

3. Understand human intervention processes versus automated processes: When considering all of the business processes involved in the VBC program, a health plan needs to map which processes are driven by human interventions and which will be fully automated system processes. For those responsibilities requiring human intervention, the inventory should include the skill level and expertise involved, along with required segregation of duty control requirements. This information will help when considering the organizational structure component of the overall business architecture.

4. Determine technology types: Similar to the focus on process types above, a health plan must identify the required technology type involved in each process. Technology types such as graphical user interfaces (GUIs), algorithms (e.g. attribution), reporting/visualization software and technical integration solutions will likely all be relevant to the overall VBC architecture.

After a health plan has established this conceptual understanding of their VBC program needs, they can then begin tackling a more detailed business solution architecture design, tying together the technology, people, and processes of the program. Once complete, a business solution architecture will illustrate the major components of the total solution from each of these perspectives and demonstrate how each of them support the other. The following high-level steps describe how Baker Tilly approaches the development of a comprehensive business solution architecture.

5. Establish conceptual components: Discrete solution components required to solve each business process should be defined in order to capture all key elements of the end state solution. For example, a quality outcome measurement business process involves several solution components that need to be explicitly defined. These components may include a quality measure calculation engine, integration with VBC contract information and member populations, a reporting layer with a multitude of report types (e.g. patient care gap reports, final year end quality performance results, etc.), and integration into VBC outcome incentive measurement and reimbursement. Across all of these process components, multiple different types of technologies and operational process owners will likely be identified.

6. Define additional component details: After the solution components are defined, each module should be broken down into sub-components, features, and perhaps even versions to enable definition of work plans at both the component and “big picture” level. Using the reporting layer component of the quality measurement business process as an example, sub-components and features could include items like individual quality metrics for tracking performance, unique measure sets for different VBC programs, and report parameterization and filtering to support distribution to different audiences.

7. Map business processes to components: Each component of the VBC program is interconnected as part of the end-to-end process. It is essential for health plans to illustrate each integration point across the various solution elements to help program stakeholders see the relative role each component plays in the overall solution. The various business processes that the solution must support can be seen through this view.

8. Define technology to use for each component: As discussed above, there are many technology vendors in the market for helping address a health plan’s VBC program solution components. Therefore, health plans should investigate the marketplace and perform a build versus buy analysis to select an existing packaged software solution, enhance an existing in-house solution, or build a custom net new in-house solution for VBC solution components. Such decisions are likely required at the solution component level of detail, and may need to also consider sub-components and features. As the components are analyzed, the technology layer of the solution architecture comes together. For those components identified to be supported by vendor solutions, health plans can go through a selection process to identify the best fit and move forward with negotiations and purchasing if vended technologies prove to be best.

9. Map organization structures and operating models to the solution: Finally, the teams intended to use the solution must be incorporated into the overall architecture design. Business solution architectures should account for the major divisions responsible for each major process component and also break down details to the department, team, and role levels. Charts that describe the teams responsible and accountable for operational results may also be helpful. Some solution architectures are built to consider both the team structures assigned to maintain the solution along with those responsible for operating the business within the solution.

10. Consider external stakeholder needs: Outside of the health plan, the contracted provider’s environment should factored in as changes will exist there too. Health plans need to consider the capabilities assumed to exist within the provider network and the various integration points, information sets, and process connections to link the health plans solutions components with those at the provider.

With a proactive solution approach inclusive of a significant focus on the development of a comprehensive business solution architecture to guide delivery, we have seen many of our clients successfully launch and scale VBC programs.

For more information on this topic, or to learn how Baker Tilly healthcare specialists can help, contact our team.