Skip to Main Content

blogpost

Three steps to
outcomes-based
certification

12.04.19

Read this if you are a State Medicaid Director, State Medicaid Chief Information Officer, State Medicaid Project Manager, or State Procurement Officer—or if you work on a State Medicaid Enterprise System (MES) certification effort.

On October 24, 2019, the Centers for Medicaid and Medicare Services (CMS) published the Outcomes-Based Certification (OBC) guidance for the Electronic Visit Verification (EVV) module. Now, CMS is looking to bring the OBC process to the rest of the Medicaid Enterprise. 

The shift from a technical-focused certification to a business outcome-focused approach presents a unique opportunity for states as they begin re-procuring—and certifying—their Medicaid Enterprise Systems (MES).

Once you have defined the scope of your MES project—and know you need to undertake CMS certification—you need to ask “what’s next?” OBC can be a more efficient certification process to secure Federal Financial Participation (FFP).

What does OBC certification entail?

Rethinking certification in terms of business outcomes will require agencies to engage business and operations units at the earliest possible point of the project development process to define the program goals and define what a successful implementation is. One way to achieve this is to consider MES projects in three steps. 

Three steps to OBC evaluation

Step 1: Define outcomes

The first step in OBC planning seems easy enough: define outcomes. But what is an outcome? To answer that, it’s important to understand what an outcome isn’t. An outcome isn’t an activity. Instead, an outcome is the result of the activity. For example, the activity could be procuring an EVV solution. In this instance, an outcome could be that the state has increased the ability to detect fraud, waste, and abuse through increased visibility into the EVV solution.

Step 2: Determine measurements

The second step in the OBC process is to determine what to measure and how exactly you will measure it. Deciding what metrics will accurately capture progress toward the new outcomes may be intuitive and therefore easy to define. For example, a measure might simply be that each visit is captured within the EVV solution.

Increasing the ability to detect fraud, waste, and abuse could simply be measured by the number of cases referred to a Medicaid fraud unit or dollars recovered. However, you may not be able to easily measure that in the short-term. Instead, you may need to determine its measurement in terms of an intermediate goal, like increasing the number of claims checked against new data as a result of the new EVV solution. By increasing the number of checked claims, states can ensure that claims are not being paid for unverified visits. 

Step 3: Frequency and reporting

Finally, the state will need to determine how often to report to measure success. States will need to consider the nuances of their own Medicaid programs and how those nuances fit into CMS’ expectations, including what data is available at what intervals.

OBC represents a fundamental change to the certification process, but it’s important to highlight that OBC isn’t completely unfamiliar territory. There is likely to be some carry-over from the certification process as described in the Medicaid Enterprise Certification Toolkit (MECT) version 2.3. The current Medicaid Enterprise Certification (MEC) checklists serve as the foundation for a more abbreviated set of criteria. New evaluation criteria will look and feel like the criteria of old but are likely to be a fraction of the 741 criteria present in the MECT version 2.3.

OBC offers several benefits to states as you navigate federal certification requirements:

  1. You will experience a reduction in the amount of time, effort, and resources necessary to undertake the certification process. 
  2. OBC refocuses procurement in terms of enhancements to the program, not in new functions. Consequently, states will also be able to demonstrate the benefits that each module brings to the program which can be integral to stakeholder support of each module. 
  3. Early adoption of the OBC process can allow you to play a more proactive role in certification efforts.

Continue to check back for a series of our project case studies. Additionally, if you are considering an OBC effort and have questions, please contact our team. You can read the OBC guidance on the CMS website here
 

Related Industries

Related Professionals

Read this if you are a State Medicaid Director, State Medicaid Chief Information Officer, State Medicaid Project Manager, or State Procurement Officer—or if you work on a State Medicaid Enterprise System (MES) certification effort.

Measuring performance of Medicaid Enterprise Systems (MES) is emerging as the next logical step in moving Medicaid programs toward modularity. As CMS continues to refine and implement outcomes-based modular certification, it is critical that states adapt to this next step in order to continue to meet CMS funding requirements.

This measurement, in terms of program outcomes, presents a unique set of challenges, many of which a state may not have considered before. A significant challenge is determining how and where to begin measuring program outcomes―to meet it, states can leverage a trusted, independent partner as they undertake an outcomes-based effort.

Outcomes-based planning can be thought of as a three-step process. First, and perhaps most fundamental, is to define outcomes. Second, you need to determine what measurements will demonstrate progress toward achieving those outcomes. And the final step is to create reporting measurements and their frequency. Your independent partner can help you answer these critical questions and meet CMS requirements efficiently by objectively guiding you toward realizing your goals.

  1. Defining Outcomes
    When defining an outcome, it is important to understand what it is and what it isn’t. An outcome is a benefit or added value to the Medicaid program. It is not an output, which is a new or enhanced function of a new MES module. An output is the product that supports the outcome. For example, the functionality of a new Program Integrity (PI) module represents an output. The outcome of the new PI module could be that the Medicaid program continuously improves based on data available because of the new PI module. Some outcomes may be intuitive or obvious. Others may not be as easy to articulate. Regardless, you need to direct the focus of your state and solution vendor teams on the outcome to uncover what the underlying goal of your Medicaid program is.
     
  2. Determining Measurements
    The second step is to measure progress. Well-defined Key Performance Indicators (KPIs) will accurately capture progress toward these newly defined outcomes. Your independent partner can play a key role by posing questions to help ensure the measurements you consider align with CMS’ goals and objectives. Additionally, they can validate the quality of the data to ensure accuracy of all measurements, again helping to meet CMS requirements.
     
  3. Reporting Measurements
    Finally, your state must decide how―and how often―to report on outcomes-based measurements. Your independent partner can collaborate with both your state and CMS by facilitating conversations to determine how you should report, based on a Medicaid program’s nuances and CMS’ goals. This can help ensure the measurements (and support information) you present to CMS are useful and reliable, giving you the best chance for attaining modular certification.

Are you considering an outcomes-based CMS modular certification, or do you have questions about how to best leverage an independent partner to succeed with your outcomes-based modular certification effort? BerryDunn’s extensive experience as an independent IV&V and Project Management Office (PMO) partner includes the first pilot outcomes-based certification effort with CMS. Please visit our IV&V and certification experts at our booth at MESC 2019 or contact our team now.

Blog
Three steps to measure Medicaid Enterprise Systems outcomes

Editor's note: read this blog if you are a state liquor administrator or at the C-level in state government. 

Surprisingly, the keynote address to this year’s annual meeting of the National Alcohol Beverage Control Association (NABCA) featured few comments on, well, alcohol. 

Why? Because cannabis is now the hot topic in state government, as consumers await its legalization. While the thought of selling cannabis may seem foreign to some state administrators, many liquor agencies are―and should be―watching. The fact is, state liquor agencies are already equipped with expertise and the technology infrastructure needed to lawfully sell a controlled substance. This puts them in a unique position to benefit from the industry’s continued growth. Common technology includes enterprise resource planning (ERP) and point-of-sale (POS) systems.

ERP

State liquor agencies typically use an ERP system to integrate core business functions, including finance, human resources, and supply chain management. Whether the system is handling bottles of wine, cases of spirits, or bags of cannabis, it is capable of achieving the same business goals. 

The existing checks and balances on controlled substances like alcohol in their current ERP system translate well to cannabis products. This leads to an important point: state governments do not need to procure a new IT system solely for regulating cannabis.

By leveraging existing ERP systems, state liquor agencies can sidestep much of the time, effort, and expense of selecting, procuring, and implementing a new system solely for cannabis sales and management. In control states, where the state has exclusively control of alcohol sales, liquor agencies are often involved in every stage of product lifecycle, from procurement to distribution to retailing.

With a few modifications, the spectrum of business functions that control states require for liquor—procuring new product, communicating with vendors and brokers, tracking inventory, and analyzing sales—can work just as well for cannabis.

POS

POS systems are necessary for most retail stores. If a state liquor agency decides to sell cannabis products in stores, they can use a POS system to integrate with the agency’s ERP system, though store personnel may require training to help ensure compliance with related regulations.

Cannabis is cash only (for now)

There is one major difference in conducting liquor versus cannabis sales at any level: currently states conduct all cannabis sales in cash. With cannabis illegal on the federal level, major banks have opted to decline any deposit of funds earned from cannabis-related sales. While some community banks are conducting cannabis-related banking, many retailers selling recreational cannabis in places like Colorado and California still deal in cash. While risky and not without challenges, these transactions are possible and less onerous to federal regulators. 

Taxes 

As markets develop, monthly tax revenue collections from cannabis continue to grow. Colorado and California have found cannabis-related tax revenue a powerful tool in hedging against uncertainty in year-over-year cash flows. Similar to beer sold wholesale, which liquor agencies tax even in control states, cannabis can be taxed at multiple levels depending on the state’s business model.

E-commerce

Even with liquor, few state agencies have adopted direct-to-consumer online sales. However, as other industries continue shifting toward e-commerce and away from brick and mortar retailing, private sector competition will likely feed increased consumer demand for online sales. Similar to ERP and POS systems, states can increase revenue by selling cannabis through e-commerce sales channels. In today’s online retail world, many prefer to buy products from their computer or smart phone instead of shopping in stores. State agencies should consider selling cannabis via the web to maximize this revenue opportunity. 

Applying expertise in the systems and processes of alcoholic beverage control can translate into the sale and regulation of cannabis, easing the transition states face to this burgeoning industry. If your agency is considering bringing in cannabis under management, you should consider strategic planning sessions and even begin a change management approach to ensure your agency adapts successfully. 

Blog
Considering cannabis: how state liquor agencies can manage the growing industry

Editor’s note: If you are a higher education CFO, CIO, CTO or other C-suite leader, this blog is for you.

The Gramm-Leach-Bliley Act (GLBA) has been in the news recently as the Federal Trade Commission (FTC) has agreed to extend a deadline for public comment regarding proposed changes to the Safeguards Rule. Here’s what you need to know.

GLBA, also known as the Financial Modernization Act, is a 1999 federal law providing rules to financial institutions for protecting consumer information. Colleges and universities fall under this act because they conduct financial activities (e.g., administration of financial aid, loans, and other financial services).

Under the Safeguards Rule financial Institutions must develop, implement, and maintain a comprehensive information security program that consists of safeguards to handle customer information.

Proposed changes

The FTC is proposing five modifications to the Safeguards Rule. The new act will:

  • Provide more detailed guidance to impacted institutions regarding how to develop and implement specific aspects of an overall information security program.
  • Improve the accountability of an institution’s information security programs.
  • Exempt small business from certain requirements.
  • Expand the definition of “financial institutions” to include entities engaged in activities that the Federal Reserve Board determines to be incidental to financial activities.
  • Propose to include the definition of “financial institutions” and related examples in the rule itself rather than cross-reference them from a related FTC rule (Privacy of Consumer Financial Information Rule).

Potential impacts for your institution

The Federal Register, Volume 84, Number 65, published the notice of proposed changes that once approved by the FTC would add more prescriptive rules that could have significant impact on your institution. For example, these rules would require institutions to:

  1. Expand existing security programs with additional resources.
  2. Produce additional documentation.
  3. Create and implement additional policies and procedures.
  4. Offer various forms of training and education for security personnel.

The proposed rules could require institutions to increase their commitment in time and staffing, and may create hardships for institutions with limited or challenging resources.

Prepare now

While these changes are not final and the FTC is requesting public comment, here are some things you can do to prepare for these potential changes:

  • Evaluate whether your institution is compliant to the current Safeguards Rule.
  • Identify gaps between current status and proposed changes.
  • Perform a risk assessment.
  • Ensure there is an employee designated to lead the information security program.
  • Monitor the FTC site for final Safeguard Rules updates.

In the meantime, reach out to us if you would like to discuss the impact GLBA will have on your institution or if you would like assistance with any of the recommendations above. You can view a comprehensive list of potential changes here.

Source: Federal Trade Commission. Safeguards Rule. Federal Register, Vol. 84, No. 65. FTC.gov. April 4, 2019. https://www.ftc.gov/enforcement/rules/rulemaking-regulatory-reform-proceedings/safeguards-rule

Blog
Higher ed: GLBA is the new four-letter word, but it's not as bad as you think

Phew! We did it—The Medicaid Enterprise Systems Conference (MESC) 2019 is one for the books! And, it was a great one. Here is my perspective on objectives and themes that will guide our work for the year.

Monday 

My day started in the fog—I live on an island in Maine, take a boat to get into Portland, and taxi to the airport. Luckily, I got to Portland, and, ultimately Chicago, on time and ready to go. 

Public Sector Technology Group (PSTG) meeting

At the PSTG meetings, we reviewed activities from the previous year and did some planning for the coming year. Areas for consideration included:

  • Modernization Schedule
  • Module Definitions
  • Request for Proposal (RFP) Requirements
  • National Association of State Procurement Officers

Julie Boughn, Centers for Medicare and Medicaid (CMS) Director, Data and Systems Group (DSG) introduced her new boss, Karen Shields, who is the Deputy Director for the Center for Medicaid and CHIP Services (CMCS) within CMS. Karen shared her words of wisdom and encouragement with us, while Julie reminded us that being successful in our work is about the people. CMS also underscored the goal of speeding up delivery of service to the Medicaid program and asking ourselves: “What is the problem we are trying to resolve?” 

CMS’ “You be the State” officer workshop

Kudos to CMS for creating this open environment of knowledge sharing and gathering input.  Areas for discussion and input included:

  • APD Processes
  • Outcomes-Based Certification
  • Increasing and Enhancing Accountability

Tuesday
Opening Plenary

I was very touched by the Girls Inc. video describing the mission of Girls Inc. to inspire girls to be strong, smart, and bold. With organizations like this, and our awareness and action, I am optimistic for the future. Thank you to NESCSO for including this in their opening program.

John Doerr, author of Measure What Matters: OKRs: The Simple Idea that Drives 10x Growth and famed investor, shared his thoughts on how to create focus and efficiency in what we do. Julie’s interview with him was excellent, and I appreciated how John’s Objectives and Key Results (OKR) process prompted Julie to create objectives for what we are trying to do. The objectives Julie shared with us:

  • Improve the quality of our services for users and other stakeholders 
  • Ensure high-quality data is available to manage the program and improve policy making 
  • Improve procurement and delivery of Medicaid technology projects

Sessions

The sessions were well attended and although I can't detail each specific session I attended, I will note that I did enjoy using the app to guide me through the conference. NESCSO has uploaded the presentations. 

Auxiliary meetings

Whether formal or informal, meetings are one of the big values of the conference—relationships are key to everyone’s success, and meeting with attendees in one-on-one environments was incredibly productive. 

Poster session

The poster sessions were excellent. States are really into this event, and it is a great opportunity for the MESC community to engage with the states and see what is going on in the Medicaid Enterprise space.

Wednesday

Some memorable phrases heard in the sessions:

  • Knowledge is power only if you share it
  • We are in this together and want the same outcomes, so let’s share more
  • Two challenges to partnering projects—the two “P”s—are purchasing and personnel
  • Don’t let perfection be the enemy of the good
  • Small steps matter
  • Sharing data is harder than it needs to be—keep in mind the reason for what you are doing

Our evening social event was another great opportunity to connect with the community at MESC and the view of Chicago was beautiful.

Julie Boughn challenged us to set a goal (objective) in the coming year, and, along with it, to target some key results in connection with that goal. Here are some of her conference reflections:

  • Awesome
    • Several State Program and Policy leaders participated at MESC—impressed with Medicaid Director presence and participation
    • Smaller scoped projects are delivering in meeting the desired improved speed of delivery and quality
    • Increased program-technology alignment
  • Not so awesome
    • Pending state-vendor divorces
    • Burden of checklists and State Self-Assessments (SS-As)—will have something to report next year
    • There are still some attempts at very large, multi-year replacement projects—there is going to be a lot of scrutiny on gaining outcomes. Cannot wait five years to change something.

OKRs and request for states and vendors

  • Objective: Improve the quality of services for our users and other stakeholders
    • Key Result (KR): Through test results and audits, all States and CMS can state with precision, the overall accuracy of Medicaid eligibility systems.
    • KR: 100% of State electronic visit verification (EVV) systems are certified and producing annual performance data.
    • KR: 100% of States have used CMS-required testing guidance to produce testing results and evidence for their eligibility systems.
  • Objective: Ensure high-quality data is available to manage the program and improve policy making
    • KR: Transformed Medicaid Statistical Information System (T-MSIS) data is of sufficient quality that it is used to inform at least one key national Medicaid policy decision that all states have implemented.
    • KR:  Eliminate at least two state reporting requirements because T-MSIS data can be used instead.
    • KR: At least five states have used national or regional T-MSIS data to inform their own program oversite and/or policy-making decisions.
  • Objective: Improve how Medicaid technology projects are procured and delivered
    • KR: Draft standard language for outcomes metrics for at least four Medicaid business areas.
    • KR:  Five states make use of the standard NASPO Medicaid procurement.
    • KR:  CMS reviews of RFPs and contracts using NASPO vehicle are completed within 10 business days.
    • KR:  Four states test using small incremental development phases for delivery of services.
  • Request: Within 30 days, states/vendors will identify at least one action to take to help us achieve at least one of the KRs within the next two years.

Last thoughts

There is a lot to digest, and I am energized to carry on. There are many follow-up tasks we all have on our list. Before we know it, we’ll be back at next year’s MESC and can check in on how we are doing with the action we have chosen to help meet CMS’s requirements. See you in Boston!

Blog
MESC 2019―Reflections and Daily Recap

Editor’s note: If you are a state government CFO, CIO, project or program manager, this blog is for you. 

This is the second blog post in the blog series: “Procuring Agile vs. Non-Agile Service”. Read the first blog. This blog post demonstrates the differences in Stage 1: Plan Project in the five stages of procuring agile vs. non-agile services.

Overview of Procurement Process for Agile vs. Non-Agile IT Services

What is important to consider in agile procurement?

Here are some questions that can help focus the planning for procurement of IT services for agile vs. non-agile projects.

Plan Project Considerations for Agile vs. Non-Agile IT Services

Why are these considerations important?

When you procure agile IT services, you can define the scope of your procurement around a vision of what your organization intends to become, as opposed to being restricted to an end-date for a final delivery.

In an agile project, you get results iteratively; this allows you to constantly reassess requirements throughout the project, including the project plan, the guiding principles, and the project schedule. Your planning is not restricted to considering the effect of one big result at the end of the project schedule. Instead, your plan allows for sequencing of changes and improvements that best reflect the outcomes and priorities your organization needs

Since planning impacts the people-aspect of your strategy, it is important to consider how various teams and stakeholders will provide input, and how you will make ongoing communication updates throughout the project. With an agile procurement project, your culture will shift, and you will need a different approach to planning, scheduling, communicating, and risk management. You need to communicate daily, allowing for reviewing and adjusting priorities and plans to meet project needs. 

How do you act on these considerations?

A successful procurement plan of agile IT services should include the following steps:

  1. Develop a project charter and guiding principles for the procurement that reflect a vision of how your organization’s teams will work together in the future
  2. Create a communication plan that includes the definition of project success and communicates project approach
  3. Be transparent about the development strategy, and outline how iterations are based on user needs, that features will be re-prioritized on an ongoing basis, and that users, customers, and stakeholders are needed to help define requirements and expected outcomes
  4. Provide agile training to your management, procurement, and program operation teams to help them accept and understand the project will present deliverables in iterations, to include needed features, functionality and working products
  5. Develop requirements for the scope of work that align with services and outcomes you want, rather than documented statements that merely map to your current processes 

What’s next? 

Now that you have gained insight into the approach to planning an agile project, consider how you may put this first stage into practice in your organization. Stay tuned for guidance on how to execute the second stage of the procurement process—how to draft the RFP. Our intention is that, following this series, your organization will better understand how to successfully procure and implement agile services. If you have questions or comments, please contact our team.
 

Blog
Plan agile projects: Stage 1

Read this if you are a State Medicaid Director, State Medicaid Chief Information Officer, State Medicaid Project Manager, or State Procurement Officer.

As CMS moves away from the monolithic Medicaid Management Information System (MMIS) toward an outcomes-based approach that includes a modular Medicaid Enterprise System (MES), there is now more emphasis on system integration (SI). 

In the August 16, 2016 letter, State Medicaid Director (SMD) #16-010, CMS clarified the role of the system integrator (SI) by stating:

CMS envisions a discrete role for the system integrator (SI) in each state, with specific focus on ensuring the integrity and interoperability of the Medicaid IT architecture and cohesiveness of the various modules incorporated into the Medicaid enterprise. 

While the importance of the SI role is apparent, not all states have the resources to build the SI capability within their own organizations. Some state Medicaid IT teams try to solve this by delegating management roles to vendors or contractors. This approach has various risks. A state could lose:

  • Institutional knowledge, as vendors and contractors transition off the project
  • Control of governance, oversight, and leadership
  • The ability to enforce contractual requirements across each vendor, especially the SI

In addition, the ramifications of loss of state accountability can have wide-reaching implementation, operational, and financial impacts, including:

  • The loss of timely decision making, causing projects to fall behind schedule
  • State-specific policy needs not being met, impacting how the MMIS functions in production 
  • Poor integration into the state-specific Operation and Maintenance (O&M) support model, increasing the state’s portion of long-term O&M costs
  • Inefficient and ineffective contract management of each module vendor and contractor (including the SI), possibly leading to unneeded change requests and cost overruns
  • Lack of coordination with the state’s business or IT roadmap initiatives (i.e., system consolidation or cloud migration vendor/approach), possibly leading to rework and missed opportunities to reduce cost or improve interoperability 

Apply strong governance and IV&V to tackle risks

Because the SI vendor is responsible for the integration of multiple modules across multiple vendors, you may consider delegating oversight of module vendors to the SI vendor. 

The major benefit states get from using the SI vendor is efficiency. Having your vendor as the central point of contact can quickly resolve technical issues, while allowing easy coordination of project tasks across each module vendor on a continual basis. 

If you choose to use a vendor for the SI role, establish safeguards and governance to make sure your goals are being met:

  • Build a project-specific governance model (executive committee [EC]) to oversee the vendors and the project
  • Establish a regular meeting cadence for the EC to allow for status updates on milestones and discuss significant project risks and issues 
  • Allocate state resources into project leadership roles (i.e., project manager, vendor contract manager, security lead, testing/Quality Assurance lead, etc.)
  • Conduct regular (weekly) SI status meetings to track progress and address risks and issues 

You also need a strong, involved governance structure that includes teams of state senior leadership, state program managers, SI vendor engagement/contract managers, and Independent Verification and Validation (IV&V) vendors. By definition, one responsibility of IV&V is to identify and monitor project risks and issues that could arise from a lack of independence. 

Your governance teams can debate decisions and disputes, risks and issues, and federal compliance issues with their vendors to define direction and action plans. However, a state representative within these teams should always make the final management decisions, approve all SI scope items and changes, and approve all contractual deliverables from each vendor or contractor.

Your state staff (business and IT) provides project management decision, business needs, requirements (functional and non-functional), policy guidance, and continuity as the vendors and/or contractors change over time. 

The conclusion? In order to be successful, you must retain certain controls and expertise to deploy and operate a successful MMIS system. Our consultants understand the need to keep you in control of managing key portions of implementation projects/programs and operational tasks. If you have questions, please contact BerryDunn’s Medicaid team.  
 

Blog
Risks when using vendors to manage Medicaid system implementation projects

Read this if you are a state Medicaid Director, State Medicaid Chief Information Officer, State Medicaid Project Manager, State Procurement Officer, or work in a State Medicaid Program Integrity Unit.

The Centers for Medicare & Medicaid Services (CMS) issued a Payment Error Rate Measurement (PERM) Final Rule on July 5, 2017, that made several changes to the PERM requirements. One important change was the updates to the Medicaid Eligibility Quality Control (MEQC) requirement. 

The Final Rule restructures the MEQC program into a pilot program that requires states to conduct eligibility reviews during the two years between PERM cycles. CMS has also introduced the potential for imposing disallowances or reductions in federal funding percentage (FFP) as a result of PERM eligibility error rates that do not meet the national standard. One measure states can use to lessen the chance of this happening is by successfully carrying out the requirements of the MEQC pilot. 

What states should know―important points to keep in mind regarding MEQC reviews:

  • Each state must have a team in place to conduct MEQC reviews. The individuals responsible for the MEQC reviews and associated activities must be separate from the state agencies and personnel responsible for Medicaid and Children’s Health Insurance Program (CHIP) policy and operations, including eligibility determinations.
  • States can apply for federal funding to help cover the costs of the MEQC activities. CMS encourages states to partner with a contractor in conducting the MEQC reviews.
  • The deadline to submit the state planning document to CMS is November 1 following the end of your state’s PERM cycle. If you are a Cycle 2 state, your MEQC planning document is due by November 1, 2019. 
  • If you are a Cycle 1 state, you are (or should be) currently undergoing the MEQC reviews.
  • There are minimum sample size requirements for the MEQC review period: 400 negative cases and 400 active cases (consisting of both Medicaid and CHIP cases) over a period of 12 months.
  • Upon conclusion of all MEQC reviews, states must submit a final findings report along with a corrective action plan that addresses all error findings identified during the MEQC review period.

CMS encourages states to utilize federal funding to carry out and fulfill MEQC requirements. BerryDunn has staff with experience in preparing Advanced Planning Documents (APD) and can assist your state in submitting an APD request to CMS for these MEQC activities. 

Check out the previously released blog, “PERM: Prepared or Not Prepared?” and stay tuned for upcoming blogs about specific PERM topics, including the financial impacts of PERM, and how each review phase will affect your state.   

For questions or to find out more, contact the team

Blog
PERM: Does MEQC affect states?

Read this if you are a state Medicaid Director, State Medicaid Chief Information Officer, State Medicaid Project Manager, or State Procurement Officer.

When I was growing up, my dad would leave the Bureau of Motor Vehicles or hang up the phone after talking with the phone company and say sarcastically, “I’m from the government (or the phone company) and I’m here to help you. Yeah, right.” I could hear the frustration in his voice. As I’ve gotten older, I understand the hassle of dealing with bureaucracy, where the red tape can make things more difficult than they need to be, and where customers don’t come first. It doesn’t have to be that way.

In my role performing Independent Verification and Validation (IV&V) at BerryDunn, I hear the same skepticism in the voices of some of my clients. I can hear them thinking, “Let me get this straight… I’m spending millions of dollars to replace my old Medicaid Management Information System (MMIS), and the Centers for Medicare and Medicaid Services (CMS) says I have to hire an IV&V consultant to show me what I am doing wrong? I don’t even control the contract. You’re here to help me? Yeah, right.” Here are some things to assuage your doubt. 

Independent IV&V―what they should do for you and your organization

An independent IV&V partner that is invested in your project’s success can:

  • Enhance your system implementation to help you achieve compliance
  • Help you share best practice experience in the context of your organization’s culture to improve efficiency in other areas
  • Assist you in improving your efficiency and timeliness with project management capabilities.

Even though IV&V vendors are federally mandated from CMS, your IV&V vendor should also be a trusted partner and advisor, so you can achieve compliance, improve efficiency, and save time and effort. 

Not all IV&V vendors are equal. Important things to consider:

Independence―independent vendors are a good place to start, as they are solely focused on your project’s success. They should not be selling you software or other added services, push vendor affiliations, or rubber stamp CMS, nor the state. You need a non-biased sounding board, a partner willing to share lessons learned from experience that will help your organization improve.

Well-rounded perspective―IV&V vendors should approach your project from all perspectives. A successful implementation relies on knowledge of Medicaid policy and processes, Medicaid operations and financing, CMS certification, and project management.

“Hello, we are IV&V from BerryDunn, and we are here to help.”

BerryDunn offers teams that consist of members with complementary skills to ensure all aspects of your project receive expert attention. Have questions about IV&V? Contact our team.
 

Blog
We're IV&V and we are here to help you improve your Medicaid organization

Federal contractors with the Centers for Medicare & Medicaid Services (CMS) have begun performing Payment Error Rate Measurement (PERM) reviews under the Final Rule issued in July 2017—a rule that many states may not realize could negatively impact their Medicaid budgets.

PERM is a complex process—states must focus on several activities over a recurring three-year period of time—and states may not have the resources needed to make PERM requirements a priority. However, with the Final Rule, this PERM eligibility review could have financial implications. 

After freezing the eligibility measurement for four years while undergoing pilot review, CMS has established new requirements for the eligibility review component and made significant changes to the data processing and medical record review components. As part of the Final Rule, CMS may implement reductions in the amount of federal funding provided to a state’s Medicaid and Children’s Health Insurance Program (CHIP) programs based on the error rates identified from the eligibility reviews. 

Since the issuance of the Final Rule in July 2017, Cycle 1 states are the first group of states to undergo a PERM cycle, including reviews of the data processing, medical record, and eligibility components. These states are wrapping up the final review activities, and Cycle 2 states are in the early stages of their PERM reviews.

How can your state prepare?

Whether your state is a Cycle 1, Cycle 2, or Cycle 3 state, there are multiple activities your Medicaid departments should engage in throughout each three-year period of time during and between PERM cycles: 

  • Analyzing prior errors cited or known issues, along with the root cause of the error
  • Identifying remedies to reduce future errors
  • Preparing and submitting required questionnaires and documents to the federal contractors for an upcoming review cycle
  • Assisting federal contractors with current reviews and findings
  • Preparing for and undergoing Medicaid Eligibility Quality Control (MEQC) planning and required reviews
  • Corrective action planning

Is your state ready?

We’ve compiled a few basic questions to gauge your state’s readiness for the PERM review cycle:

  • Do you have measures in place to ensure all eligibility factors under review are identifiable and that all federal and state regulations are being met? The eligibility review contractor (ERC) will reestablish eligibility for all beneficiaries sampled for review. This process involves confirming all verification requirements are in the case file, income requirements are met, placement in an accurate eligibility category has taken place, and the timeframe for processing all determinations meets federal and state regulations. 
  • Do you have up-to-date policy and procedures in place for determining and processing Medicaid or CHIP eligibility of an individual? Ensuring eligibility policies and procedures meet federal requirements is just as important as ensuring the processing of applications, including both system and manual actions, meet the regulations. 
  • Do you have up-to-date policy, procedures, and system requirements in place to ensure accurate processing of all Medicaid/CHIP claims? Reviewers will confirm the accuracy of all claim payments based on state and federal regulations. Errors are often cited due to the claims processing system allowing claims to pay that do not meet regulations.
  • Do you have a dedicated team in place to address all PERM requirements to ensure a successful review cycle? This includes staff to answer questions, address review findings, and respond to requests for additional information. During a review cycle, the federal contractors will cite errors based on their best understanding of policies and/or ability to locate required documentation. Responding to requests for information or reviewing and responding to findings in a timely manner should be a priority to ensure accurate findings. 
  • Have you communicated all PERM requirements and updates to policy changes to all Medicaid/CHIP providers? Providers play two integral roles in the success of a PERM review cycle. Providers must understand all claims submission requirements in order to accurately submit claims. Additionally, the medical record review component relies on providers responding to the request for the medical records on a sampled claim. Failure to respond will result in an error. Therefore, states must maintain communication with providers to stress the importance of responding to these requests.
  • Have you begun planning for the MEQC requirement? Following basic requirements identified by CMS during your state’s MEQC period, your state must submit a case planning document to CMS for approval prior to the MEQC review period. After the MEQC review, your state should be prepared to issue findings reports, including a corrective action plan as it relates to MEQC findings.

Need help piloting your state’s PERM review process?

BerryDunn has subject matter experts experienced in conducting PERM reviews, including a thorough understanding of all three PERM review components—eligibility, data processing, and medical record reviews. 

We would love to work with your state to see that measures are in place that will help ensure the lowest possible improper payment error rate. Stay tuned for upcoming blogs where we will discuss other PERM topics, including MEQC requirements, the financial impacts of PERM, and additional details related to each phase of PERM. For questions or to find out more, please email me
 

Blog
PERM: Prepared or not prepared?

As the Project Management Body of Knowledge® (PMBOK®) explains, organizations fall along a structure and reporting spectrum. On one end of this spectrum are functional organizations, in which people report to their functional managers. (For example, Finance staff report to a Finance director.) On the other end of this spectrum are projectized organizations, in which people report to a project manager. Toward the middle of the spectrum lie hybrid—or matrix—organizations, in which reporting lines are fairly complex; e.g., people may report to both functional managers and project managers. 

Problem: Weak Matrix Medicaid System Vendors

This brings us to weak matrix organizations, in which functional managers have more authority than project managers. Many Medicaid system vendors happen to fall into the weak matrix category, for a number of different reasons. Yet the primary factor is the volume and duration of operational work—such as provider enrollment, claims processing, and member enrollment—that Medicaid system vendors perform once they exit the design, development, and implementation (DDI) phase.

This work spans functional areas, which can muddy the reporting waters. Without strong and clear reporting lines to project managers, project success can be seriously (and negatively) affected if the priorities of the functional leads are not aligned with those of the project. And when a weak matrix Medicaid system vendor enters a multi-vendor environment in which it is tasked with implementing a system that will serve multiple departments and bureaus within a state government, the reporting waters can become even muddier.


Solution: Using a Project Management Office (PMO) Vendor

Conversely, consulting firms that provide Project Management Office (PMO) services to government agencies tend to be strong matrix organizations, in which project managers have more authority over project teams and can quickly reallocate team members to address the myriad of issues that arise on complex, multi-year projects to help ensure project success. PMOs are also typically experienced at creating and running project governance structures and can add significant value in system implementation-related work across government agencies.

Additional benefits of a utilizing a PMO vendor include consistent, centralized reporting across your portfolio of projects and the ability to quickly onboard subject matter expertise to meet program and project needs. 
For more in-depth information on the benefits of using a PMO on state Medicaid projects, stay tuned for my second blog in this series. In the meantime, feel free to send your PMO- or Medicaid-related questions to me
 

Blog
The power of the PMO: Fixing the weak matrix

As your organization works to modernize and improve your Medicaid Enterprise System (MES), are you using independent verification and validation (IV&V) to your advantage? Does your relationship with your IV&V provider help you identify high-risk project areas early, or provide you with an objective view of the progress and quality of your MES modernization initiative? Maybe your experience hasn’t shown you the benefits of IV&V. 

If so, as CMS focuses on quality outcomes, there may be opportunities for you to leverage IV&V in a way that can help advance your MES to increase the likelihood of desired outcomes for your clients. 

According to 45 Code of Federal Regulations (CFR) § 95.626, IV&V may be required for Advanced Planning Document (APD) projects that meet specific criteria. That said, what is the intended role and benefit of IV&V? 

To begin, let’s look at the meaning of “verification” and “validation.” The Institute of Electrical and Electronics Engineers, Inc. (IEEE) Standard for Software Verification and Validation (1012-1998) defines verification as, “confirmation of objective evidence that the particular requirements for a specific intended use are fulfilled.” Validation is “confirmation of objective evidence that specified requirements have been fulfilled.” 

Simply put, verification and validation ensure the right product is built, and the product is built right. 
As an independent third party, IV&V should not be influenced by any vendor or software application. This objectivity means IV&V’s perspective is focused on benefiting your organization. This support includes: 

  • Project management processes and best practices support to help increase probability of project success
  • Collaboration with you, your vendors, and stakeholders to help foster a positive and efficient environment for team members to interact 
  • Early identification of high-risk project areas to minimize impact to schedule, cost, quality, and scope 
  • Objective examination of project health in order for project sponsors, including the federal government, to address project issues
  • Impartial analysis of project health that allows state management to make informed decisions 
  • Unbiased visibility into the progress and quality of the project effort to increase customer satisfaction and reduce the risk and cost of rework
  • Reduction of errors in delivered products to help increase productivity of staff, resulting in a more efficient MES 

Based on our experience, when a trusted relationship exists between state governments and IV&V, an open, collaborative dialogue of project challenges—in a non-threatening manner—allows for early resolution of risks. This leads to improved quality of MES outcomes.    

Is your IV&V provider helping you advance the quality of your MES? Contact our team.

Blog
Leveraging IV&V to achieve quality outcomes

Editor’s note: If you are a state government CFO, CIO, project or program manager, this blog is for you.

What is the difference in how government organizations procure agile vs. non-agile information technology (IT) services? (Learn more about agile here).

In each case, they typically follow five stages through the process as shown in Figure A:
 

Figure A: Overview of Procurement Process for Agile vs. Non-Agile IT Services

However, there are differences in how these stages are carried out if procuring agile vs. non-agile IT services. 

Unfortunately, most government organizations are unaware of these differences, which could result in unsuccessful procurements and ultimately not meeting your project’s needs and expectations. 
This blog series will illustrate how to strategically adjust the standard stages outlined in Figure A to successfully procure agile IT services.

Stage 1: Plan project
In Stage 1, you define the scope of the project by identifying what your organization wants, needs, and can achieve within the available timeframe and budget. You then determine the project’s objectives while strategically considering their impact on your organization before developing the RFP. Figure B summarizes the key differences between the impacts of agile vs. non-agile services to consider in this stage.


Figure B: Plan Project for Agile vs. Non-Agile IT Services

The nuances of planning for agile services reflect an organization’s readiness for a culture shift to a continuous process of development and deployment of software and system updates. 

Stage 2: Draft RFP
In Stage 2, as part of RFP drafting, define the necessary enhancements and functionality needed to achieve the project objectives determined in Stage 1. You then translate these enhancements and functionalities into business requirements. Requirement types might include business needs as functionality, services, staffing, deliverables, technology, and performance standards. Figure C summarizes the key differences between drafting the RFP for a project procuring agile vs. non-agile services.


Figure C: Draft RFP for Agile vs. Non-Agile IT Services

In drafting the RFP, the scope of work emphasizes expectations for how your team and the vendor team will work together, the terms of how progress will be monitored, and the description of requirements for agile tools and methods.

Stage 3: Issue RFP
In Stage 3, issue the RFP to the vendor community, answer vendor questions, post amendments, and manage the procurement schedule. Since this stage of the process requires you to comply with your organization’s purchasing and procurement rules, Figure D illustrates very little difference between issuing an RFP for a project procuring agile or non-agile services.


Figure D: Issue RFP for Agile vs. Non-Agile IT Services 

Stage 4: Review proposals
In Stage 4, you evaluate vendor proposals against the RFP’s requirements and project objectives to determine the best proposal response. Figure E summarizes the key differences in reviewing proposals for a project that is procuring agile vs. non-agile services.


Figure E: Reviewing Proposals for Agile vs. Non-Agile IT Services 

Having appropriate evaluation priorities and scoring weights that align with how agile services are delivered should not be under-emphasized. 

Stage 5: Award and implement contract
In Stage 5, you award and implement the contract with the best vendor proposal identified during Stage 4. Figure F summarizes the key differences in awarding and implementing the contract for agile vs. non-agile services.


Figure F:  Award and Implement Contract for Agile vs. Non-Agile Services 

Due to the iterative and interactive requirements of agile, it is necessary to have robust and frequent collaboration among program teams, executives, sponsors, and the vendor to succeed in your agile project delivery.

What’s next?
The blog posts in this series will explain step-by-step how to procure agile services through the five stages, and at the series conclusion, your organization will better understand how to successfully procure and implement agile services. If you have questions or comments, please contact our team.  

Blog
Procuring agile vs. non-agile projects in five stages: An overview

Focus on the people: How higher ed institutions can successfully make an ERP system change

The enterprise resource planning (ERP) system is the heart of an institution’s business, maintaining all aspects of day-to-day operations, from student registration to staff payroll. Many institutions have used the same ERP systems for decades and face challenges to meet the changing demands of staff and students. As new ERP vendors enter the marketplace with new features and functionality, institutions are considering a change. Some things to consider:

  1. Don’t just focus on the technology and make change management an afterthought. Transitioning to a new ERP system takes considerable effort, and has the potential to go horribly wrong if sponsorship, good planning, and communication channels are not in place. The new technology is the easy part of a transition—the primary challenge is often rooted in people’s natural resistance to change.  
  2. Overcoming resistance to change requires a thoughtful and intentional approach that focuses on change at the individual level. Understanding this helps leadership focus their attention and energy to best raise awareness and desire for the change.
  3. One effective tool that provides a good framework for successful change is the Prosci ADKAR® model. This framework has five distinct phases that align with ERP change:

These phases provide an approach for developing activities for change management, preparing leadership to lead and sponsor change and supporting employees through the implementation of the change.

The three essential steps to leveraging this framework:

  1. Perform a baseline assessment to establish an understanding of how ready the organization is for an ERP change
  2. Provide sponsorship, training, and communication to drive employee adoption
  3. Prepare and support activities to implement, celebrate, and sustain participation throughout the ERP transition

Following this approach with a change management framework such as the Prosci ADKAR® model can help an organization prepare, guide, and adopt ERP change more easily and successfully. 

If you’re considering a change, but need to prepare your institution for a healthy ERP transition using change management, chart yourself on this ADKAR framework—what is your organization’s change readiness? Do you have appropriate buy-in? What problems will you face?

You now know that this framework can help your changes stick, and have an idea of where you might face resistance. We’re certified Prosci ADKAR® practitioners and have experience guiding Higher Ed leaders like you through these steps. Get in touch—we’re happy to help and have the experience and training to back it up. Please contact the team with any questions you may have.

1Prosci ADKAR®from http://www.prosci.com

Blog
Perspectives of an Ex-CIO

Law enforcement, courts, prosecutors, and corrections personnel provide many complex, seemingly limitless services. Seemingly is the key word here, for in reality these personnel provide a set number of incredibly important services.

Therefore, it should surprise no one that justice and public safety (J&PS) IT departments should also provide a well-defined set of services. However, these departments are often viewed as parking lots for all technical problems. The disconnect between IT and other J&PS business units often stems from differences in organizational culture and structure, and differing department objectives and goals. As a result, J&PS organizations often experience misperception between business units and IT. The solution to this disconnect and misperception? Defining IT department services.

The benefits of defined IT services

  1. Increased business customer satisfaction. Once IT services align with customer needs, and expectations are established (e.g., service costs and service level agreements), customers can expect to receive the services they agreed to, and the IT department can align staff and skill levels to successfully meet those needs.
  2. Improved IT personnel morale. With clear definition of the services they provide to their customers, including clearly defined processes for customers to request those services, IT personnel will no longer be subject to “rogue” questions or requests, and customers won’t be inclined to circumvent the process. This decreases IT staff stress and enables them to focus on their roles in providing the defined services. 
  3. Better alignment of IT services to organizational needs. Through collaboration between the business and IT organizations, the business is able to clearly articulate the IT services that are, and aren’t, required. IT can help define realistic service levels and associated services costs, and can align IT staff and skills to the agreed-upon services. This results in increased IT effectiveness and reduced confusion regarding what services the business can expect from IT.
  4. More collaboration between IT and the organization. The collaboration between the IT and business units in defining services results in an enhanced relationship between these organizations, increasing trust and clarifying expectations. This collaborative model continues as the services required by the business evolve, and IT evolves to support them.
  5. Reduced costs. J&PS organizations that fail to strategically align IT and business strategy face increasing financial costs, as the organization is unable to invest IT dollars wisely. When a business doesn’t see IT as an enabler of business strategy, IT is no longer the provider of choice—and ultimately risks IT services being outsourced to a third-party vendor.

Next steps
Once a J&PS IT department defines its services to support business needs, it then can align the IT staffing model (i.e., numbers of staff, skill sets, roles and responsibilities), and continue to collaborate with the business to identify evolving services, as well as remove services that are no longer relevant. Contact us for help with this next step and other IT strategies and tactics for justice and public safety organizations.

Blog
The definition of success: J&PS IT departments must define services

If you’ve been tasked with leading a high-impact project for your organization, you may find managing the scope, budget and schedule is not enough to ensure project success—especially when you encounter resistance to change. When embarking on large-scale change projects spanning people, processes and technology, appointing staff as “coaches” to help support stakeholders through the change—and to manage resistance to the change—can help increase adoption and buy-in for a new way of doing things.

The first step is to identify candidates for the coaching role. These candidates are often supervisory staff who have credibility in the organization—whether as a subject matter expert, through internal leadership, or from having a history of client satisfaction. Next, you need a work plan to orient them to this role. One critical component is making sure the coaches themselves understand what the change means for their role, and have fully committed before asking them to coach others. They may exhibit initial resistance to the change you will need to manage before they can be effective coaches. According to research done by Prosci®, a leading change management research organization, some of the most common reasons for supervisor resistance in large-scale change projects are:

  • Lack of awareness about and involvement in the change
  • Loss of control or negative impact on job role
  • Increased work load (i.e., lack of time)
  • Culture of change resistance and past failures
  • Impact to their team

You should anticipate encountering these and other types of resistance from staff while preparing them to be coaches. Once coaches buy into the change, they will need ongoing support and guidance to fulfill their role. This support will vary by individual, but may be correlated to what managerial skills they already possess, or don’t. How can you focus on developing coaching skills among your staff for purposes of the project? Prosci® recommends a successful change coach take on the following roles:

  • Communicator—communicate with direct reports about the change
  • Liaison—engage and liaise with the project team
  • Advocate—advocate and champion the change
  • Resistance manager—identify and manage resistance
  • Coach—coach employees through the change

One of the initial tasks for your coaches will be to assess the existing level of change resistance and evaluate what resistance you may encounter. Prosci® identifies three types of resistance management work for your coaches to begin engaging in as they meet with their employees about the change:

  • Resistance prevention―by providing engagement opportunities for stakeholders throughout the project, building awareness about the change early on, and reinforcing executive-level support, coaches can often head off expected resistance.
  • Proactive resistance management―this approach requires coaches to anticipate the needs and understand the characteristics of their staff, and assess how they might react to change in light of these attributes. Coaches can then plan for likely forms of resistance in advance, with a structured mitigation approach.
  • Reactive resistance management―this focuses on resistance that has not been mitigated with the previous two types of resistance management, but instead persists or endures for an extended amount of time. This type of management may require more analysis and planning, particularly as the project nears its completion date.

Do you have candidates in your organization who may need support transitioning into coaching roles? Do you anticipate change resistance among your stakeholders? Contact us and we can help you develop a plan to address your specific challenges.

Blog
How to identify and prepare change management coaches

Writing a Request for Proposal (RFP) for a new software system can be complex, time-consuming, and—let’s face it—frustrating, especially if you don’t often write RFPs. The process seems dogged by endless questions, such as:

  • How specific should the problem statement and system requirements be?
  • How can the RFP solicit a response that proves the vendor is qualified?
  • Should the RFP include legal terms and conditions? If so, which ones? 
  • Is there another strategy that can help cut down on size without forfeiting a quality response?

The public RFP process can be onerous for both the issuer and the respondents, as they can reach lengths upwards of 100 pages. And, while your procurement department would probably never let you get away with developing an RFP that is only one page, we know a smaller document requires less labor and time devoted to writing and reading. What if you could create a lean, mean, and focused RFP? Here are some tips for creating such a document: 

Describe the problem as simply as possible. At its core, an RFP is a problem statement—your organization has a particular problem, and it needs the right solution. To get the right solution, keep your RFP laser-focused: adequately but briefly convey your problem and desired outcomes, provide simple rules and guidelines for respondents to submit their proposed solutions, and clarify how you will evaluate responses to make a selection. Additional information can be white noise, making it harder for respondents to give you what you want: easy-to-read and evaluate proposals. Use bullet points and keep the narrative to a minimum.

Be creative and open about how vendors must respond. RFPs often have pages of directions on how vendors need to write responses or describe their products. The most important component is to emphasize vendor qualifications. Do you want to know if the vendor can deliver a quality product? Request sample deliverables from past projects. Also ask for the number of successful past projects, with statistics on the percent deviation to client schedule, budget, including explanations for large variances. Does your new system need to keep audit trails and product billing reports? Rely on a list of pass/fail requirements and then a separate table for nice-to-have or desired functionalities.

Save the legal stuff until the end. Consider including legal terms and conditions as an attachment instead of in the body of an RFP. If you’re worried about compliance, you can require respondents to attest in writing that they found, read, and understand your terms and conditions, or state that by responding to the RFP they have read and agreed to them. State that any requested deviations can be negotiated later to save space in the RFP. You can also decrease length by attaching a glossary of terms. What’s more, if you find yourself including language from your state’s procurement manual, provide a link to the manual itself instead.

Create a quality template to save time later. Chances are your organization has at least one RFP template you use to save time, but are you using that template because it gets you the best responses, or because you’re in the habit of using it? If your answer is the latter, it may be to time review and revise those old templates to reflect your current business needs. Maybe the writing style can be clearer and more concise, or sections combined or reordered to make the RFP more intuitive.

Qualify providers in advance and reduce the scope. Another time-saver is a pre-qualification, where solution providers propose on an RFP focused primarily on their experience and qualifications. Smaller statements of work are then issued to the qualified providers, allowing for shorter drafting, response, and award timelines. If procurement rules allow, break the procurement up into a requests for information (RFI) and then a smaller RFP.

Need additional RFP assistance?
A simplified RFP can reduce long hours needed to develop and evaluate responses to RFPs, while vendors have more flexibility to propose the solutions you need. To learn more about how BerryDunn’s extensive procurement experience can help your organization develop effective RFPs.
 

Blog
The one-page RFP: How to create lean, mean, and focused RFPs

Truly effective preventive health interventions require starting early, as evidenced by the large body of research and the growing federal focus on the role of Medicaid in addressing Social Determinants of Health (SDoH) and Adverse Childhood Experiences (ACEs).

Focusing on early identification of SDoH and ACEs, CMS recently announced its Integrated Care for Kids (InCK) model and will release the related Notice of Funding Opportunity this fall.

CMS describes InCK as a child-centered approach that uses community-based service delivery and alternative payment models (APMs) to improve and expand early identification, prevention, and treatment of priority health concerns, including behavioral health issues. The model’s goals are to improve child health, reduce avoidable inpatient stays and out-of-home placement, and create sustainable APMs. Such APMs would align payment with care quality and support provider/payer accountability for improved child health outcomes by using care coordination, case management, and mobile crisis response and stabilization services.

State Medicaid agencies have many things to consider when evaluating this funding opportunity. Building on current efforts and innovations, building or leveraging strong partnerships with community organizations, incentivizing evidence-based interventions, and creating risk stratification of the target population are critical parts of the InCK model. Here are three additional areas to consider:

1. Data. States will need information for early identification of children in the target population. State agencies?like housing, justice, child welfare, education, and public health have this information?and external organizations—such as childcare, faith-based, and recreation groups—are also good sources of early identification. It is immensely complicated to access data from these disparate sources. State Medicaid agencies will be required to support local implementation by providing population-level data for the targeted geographic service area.

  • Data collection challenges include a lack of standardized measures for SDoH and ACEs, common data field definitions, or consistent approaches to data classification; security and privacy of protected health information; and IT development costs.
  • Data-sharing agreements with internal and external sources will be critical for state Medicaid agencies to develop, while remaining mindful of protected health information regulations.
  • Once data-sharing agreements are in place, these disparate data sources, with differing file structures and nomenclature, will require integration. The integrated data must then be able to identify and risk-stratify the target population.

For any evaluative approach or any APM to be effective, clear quality and outcome measures must be developed and adopted across all relevant partner organizations.

2. Eligibility. Reliable, integrated eligibility and enrollment systems are crucial points of identification and make it easier to connect to needed services.

  • Applicants for one-benefit programs should be screened for eligibility for all programs they may need to achieve positive health outcomes.
  • Any agency at which potential beneficiaries appear should also have enrollment capability, so it is easier to access services.

3. Payment models. State Medicaid agencies may cover case management services and/or targeted case management as well as health homes; leverage Early and Periodic Screening, Diagnostic, and Treatment (EPSDT) services; and modify managed care organization contract language to encourage, incent, and in some cases, require services related to the InCK model and SDoH. Value-based payment models, already under exploration in numerous states, include four basic approaches:

  • Pay for performance—provider payments are tied directly to specific quality or efficiency indicators, including health outcomes under the provider organization’s control. 
  • Shared savings/risk—some portion of the organization’s compensation depends on the managed care entity achieving cost savings for the targeted patient population, while realizing specific health outcomes or quality improvement.
  • Pay for success—payment is dependent upon achieving desired outcomes rather than underlying services.
  • Capitated or bundled payments—managed care entities pay an upfront per member per month lump sum payment to an organization for community care coordination activities and link that with fee-for-service reimbursement for delivering value-added services.

By focusing on upstream prevention, comprehensive service delivery, and alternative payment models, the InCK model is a promising vehicle to positively impact children’s health. Though its components require significant thought, strategy, coordination, and commitment from state Medicaid agencies and partners, there are early innovators providing helpful examples and entities with vast Section 1115 waiver development and Medicaid innovation experience available to assist.

As state Medicaid agencies develop and implement primary and secondary prevention, cost savings can be achieved while meaningful improvements are made in children’s lives.

Blog
Three factors state medicaid agencies should consider when applying for InCK funding

When an organization wants to select and implement a new software solution, the following process typically occurs:

  1. The organization compiles a list of requirements for essential and non-essential (but helpful) functions.
  2. The organization incorporates the requirements into an RFP to solicit solutions from vendors.
  3. The organization selects finalist vendors to provide presentations and demonstrations.
  4. The organization selects one preferred vendor based on various qualifications, including how well the vendor’s solution meets the requirements listed in the RFP. A contract between the organization and vendor is executed for delivery of the solution.
  5. The preferred vendor conducts a gap analysis to see if there are gaps between the requirements and its solution—and discloses those gaps.
  6. The preferred vendor resolves the gaps, which often results in change orders, cost adjustments, and delays.

Sound painful? It can be. Step #5—the gap analysis, and its post-contract timing—is the main culprit. However, without it, an organization will be unaware of solution shortcomings, which can lead to countless problems down the road. So what’s an organization to do?

A Possible Solution
One suggestion: Don’t wait until you choose the preferred vendor for a gap analysis. Have finalist vendors conduct pre-contract gap analyses for you.

You read that right. Pay each finalist vendor to visit your organization for a week to learn about your current and desired software needs. Then pay them to develop and present a report, based on both the RFP and on-site discussions, which outlines how their solution will meet your current and desired software needs—as well as how they will meet any gaps. Among other things, a pre-contract gap analysis will help finalist vendors determine:

  • Whether programming changes are necessary to meet requirements
  • Whether functions can be provided through configuration setup, changes in database tables, or some other non-customized solution
  • What workarounds will be necessary
  • What functionalities they can't, or won't, provide

Select a preferred vendor based on both their initial proposal and solution report.
Of course, to save time and money, you could select only one finalist vendor for the pre-contract gap analysis. But having multiple finalist vendors creates a competitive environment that can benefit your organization, and can prevent your organization from having to go back to other vendors if you’re dissatisfied with the single finalist vendor’s proposal and solution report, or if contract negotiations prove unsuccessful.

Pros
You can set realistic expectations. By having finalist vendors conduct gap analyses during the selection process, they will gain a better understanding of your organization, and both your essential and nonessential software needs. In turn, your organization gets a better understanding of the functionality and limitations of the proposed solutions. This allows your organization to pinpoint costs for system essentials, including costs to address identified gaps. Your organization can also explore the benefits and costs of optional functions. Knowing the price breakdowns ahead of time will allow your organization to adjust its system requirements list.

You can reduce the need for, or pressure to accept, scope changes and change orders. Adding to, or deleting from, the scope of work after solution implementation is underway can create project delays and frustration. Nailing down gaps—and the preferred vendor’s solutions to meet those gaps—on the front end increases efficiency, helps to ensure best use of project resources, and minimizes unnecessary work or rework. It may also save you expense later on in the process.

Cons
You will incur additional up-front costs. Obviously, your organization will have to pay to bring finalist vendors on-site so they can learn the intricacies of your business and technical environment, and demonstrate their proposed solutions. Expenses will include vendors’ time, costs for transportation, lodging, and meals. These costs will need to be less than those typically incurred in the usual approach, or else any advantage to the modified gap analysis is minimized.

You might encounter resistance. Some finalist vendors might not be willing to invest the time and effort required to travel and conduct gap analyses for a system they may not be selected to implement. They will be more interested in the larger paycheck. Likewise, stakeholders in your own organization might feel that the required costs and time investments are impractical or unrealistic. Remind staff of the upfront investment and take note of which vendors are willing to do the same.

Blog
The pros and cons of pre-contract gap analyses

While new software applications help you speed up processes and operations, deciding which ones will work best for your organization can quickly evolve into analysis paralysis, as there are so many considerations.

Case in point: Software as a Service (SaaS) model
The benefits of the SaaS model, in which a vendor remotely hosts an organization’s applications, are fairly well known: your organization doesn’t have to shell out for costly hardware, the vendor tackles upgrades, backups, data recovery, and security, and you have more time and money to focus on your business goals.

There are multiple factors to look at when determining whether a SaaS solution is right for you. We’ve compiled a list of the top three SaaS considerations:

1. Infrastructure and capacity
Your organization should consider your own people, processes, and tools when determining whether SaaS makes sense. While an on-site solution may require purchasing new technologies, hiring new staff, and realigning current roles and responsibilities to maintain the system, maintaining a SaaS solution may also require infrastructure updates, such as increased bandwidth to sufficiently connect to the vendor's hosting site.

Needless to say, it’s one thing to maintain a solution; it’s an entirely different thing to keep it secure. An on-site hosting solution requires constant security upgrades, internal audits, and a backup system—all of which takes time and money. A SaaS model requires trust in your vendor to provide security. Make sure your potential vendor uses the latest security measures and standards to keep your critical business data safe and secure.

2. Expense
When you purchase major assets—for example, hardware to host its applications—it incurs capital expenses. Conversely, when you spend money on day-to-day operations (SaaS subscriptions), it incurs operating expenses.

You should weigh the pros and cons of each type of expense when considering a SaaS model. On-site upfront capital expenses for hosting hardware are generally high, and expenses can spike overtime when you update the technology, which can be difficult to predict. And don’t forget about ongoing costs for maintenance, software upgrades, and security patches.

In the SaaS model, you spread out operating costs over time and can predict costs because you are paying via subscription—which generally includes costs for maintenance, software upgrades, and security patches. However, remember you can depreciate capital expenses over time, whereas the deductibility of operating expenses are generally for the year you use them.

3. Vendor viability
Finally, you need to conduct due diligence and vet SaaS vendors before closing the deal. Because SaaS vendors assume the responsibility for vital processes, such as data recovery and security, you need to make sure the potential vendor is financially stable and has a sustainable business model. To help ensure you receive the best possible service, select a vendor considered a leader in its market sector. Prepare a viable exit strategy beforehand so you can migrate your business processes and data easily in case you have any issues with the SaaS provider.

You must read—and understand—the fine print. This is especially important when it comes to the vendor’s policies toward data ownership and future migrations to other service providers, should that become necessary. In other words: Make sure you have final say and control over your data.

Every organization has different aspects of their situation to consider when making a SaaS determination. Want to learn more? It’s a snap! Contact the authors: Clark Lathrum and Matthew Tremblay

Blog
SaaS: Is it right for you? Making SaaS determinations a snap.

Most of us have been (or should have been) instructed to avoid using clichés in our writing. These overstated phrases and expressions add little value, and often only increase sentence length. We should also avoid clichés in our thinking, for what we think can often influence how we act.

Consider, for example, “death by committee.” This cliché has greatly — and negatively — skewed views on the benefits of committees in managing projects. Sure, sometimes committee members have difficulty agreeing with one another, which can lead to delays and other issues. In most cases, though, an individual can’t possibly oversee all aspects of a project, or represent all interests in an organization. Committees are vital for project success — and arguably the most important project committee is the steering committee.

What Exactly is a Steering Committee?
It is a group of high-level stakeholders that provides strategic direction for a project, and supports the project manager. Ideally, the group increases the chances for project success by closely aligning project goals to organizational goals. However, it is important to point out that the group’s top priority is project success.

The committee should represent the different departments and agencies affected by the project, but remain relatively small in size, chaired by someone who is not an executive sponsor of the project (in order to avoid conflicts of interest). While the project manager should serve on the steering committee, they should not participate in decision-making; the project manager’s role is to update members on the project’s progress, areas of concern, current issues, and options for addressing these issues.

Overall, the main responsibilities of a steering committee include:

  1. Approving the Project Charter
  2. Resolving conflicts between stakeholder groups
  3. Monitoring project progress against the project management plan
  4. Fostering positive communicating about the project within the organization
  5. Addressing external threats and issues emerging outside of the project that could impact it
  6. Reviewing and approving changes made to the project resource plan, scope, schedules, cost estimates, etc.

What Are the Pros and Cons of Utilizing a Steering Committee?
A group of executive stakeholders providing strategic direction should benefit any project. Because steering committee members are organizational decision-makers, they have the access and credibility to address tough issues that can put the project at a risk, and have the best opportunities to negotiate positive outcomes. In addition, steering committees can engage executive management, and make sure the project meshes with executive management’s vision, mission, and long-range strategic plan. Steering committees can empower project managers, and ensure that all departments and agencies are on the same page in regards to project status, goals, and expectations. In a 2009 article in Project Management Journal, authors Thomas G. Lechler and Martin Cohen concluded that steering committees are important to implementing and maintaining project management standards on an operational level — not only do steering committees directly support project success, they are instrumental in deriving value from an organization's investments in its project management system.

A steering committee is only as effective as it’s allowed to be. A poorly structured steering committee that lacks formal authority, clear roles, and clear responsibilities can impede the success of a project by being slow to respond to project issues. A proactive project manager can help the organization avoid this major pitfall by helping develop project documents, such as the governance document or project plan that clearly define the steering committee structure, roles, responsibilities and authority.

Steer Toward Success!
Steering committees can benefit your organization and its major projects. Yet understanding the roles and responsibilities — and pros and cons — is only a preliminary step in creating a steering committee. Need some advice on how to organize a steering committee? Want to learn more about steering committee best practices? Together, we can steer your project toward success.

Blog
Success by steering committee

The relationship between people, processes, and technology is as elemental as earth—and older than civilization. From the first sharpened rock to the Internet of Things, the three have been crucially intertwined and interdependent. There would have been no Industrial Revolution, for instance, without entrepreneurs who developed new tools to facilitate new manufacturing methods.

Of course, the increasing complexity of processes and the rapid innovations in technology tend to eclipse the present role that people play in progress. On the surface the trend seems understandable, even reasonable, when it comes to implementing a new Enterprise Resource Planning (ERP) system. Implementing a new ERP system is one of the most daunting projects an institution can undertake. Some sobering statistics—over 70% of all implementations take longer than planned, while over 50% go over budget—illustrate why many institutions focus on selecting the right ERP model and purchasing the right software. This is important, yet there are two excellent and connected reasons why your institution should focus on the “people component” of an ERP implementation.

Reason #1: The Technology is Tenable

Companies have improved and vetted ERP systems over time, so that today there’s little chance your institution will purchase poorly designed ERP software. And you have multiple options. For example, you could pursue a hosted ERP model in which a data center houses your ERP system, or a Software as a Service (SaaS) model, in which a third party administers your ERP software. These options help minimize hardware implementation, maintenance, and incomplete attempts at full system utilization—which in turn saves you time, money, and headaches.

In short: You won’t have to bear the full brunt of the tech burden, and the software and hardware you purchase should work. This enables you to concentrate on the people component of the system.

Reason #2: People Propel the Processes

A higher education institution can optimize an ERP system to complete countless processes: automating registration, onboarding staff, processing financial aid, improving self-service capabilities, simplifying record-keeping, etc. Yet a system can’t do all this on its own (not yet, at least). People—both functional and IT staff—propel these processes. For this to happen, your institution needs to secure buy-in and equip people with vision, training, and resources.

People are wary of ERP projects, for good reason. When an institution decides to tackle an ERP implementation the onus often falls on already busy staff, some of whom may rather find a new career than manage a new system implementation. Your staff and their institutional knowledge are your greatest assets. It is important to empower staff to define how future-state business processes should work—and for you to remember that a common reason for ERP implementation failure is lack of engagement. Sometimes, those at the executive level make decisions without adequate input from the people who actually do the work. You will need to sharpen your “people skills” in order to educate stakeholders on the value of a new ERP system, and how the software will make their day-to-day roles and responsibilities more efficient and effective. To ensure that staff have the bandwidth to engage in this change, it is advisable to provide backfill for key administrative functions.

Designing business processes of a future-state system is arguably the most challenging part of an ERP implementation. Often, stakeholders don’t understand the new functionality that a future system can offer because they have only used the prior system. It is important to engage the ERP vendor early and educate your staff to ensure that they understand the possibilities when designing future-state processes.

Once you have designed processes, training should take center stage. And once again, people play a pivotal role in this process. Modern ERP systems usually require staff to fundamentally conduct business differently; this can require training not only on the new system, but also on other foundational technologies (e.g., the office suite) not relied upon before. It is important to identify these needs and incorporate them into your institution’s training plan up front.

An effective training plan needs to balance multiple types of training, ranging from formal classroom sessions to online learning and train-the-trainer sessions. Tech-savvy staff will be able to train other staff in using the new ERP system, which will not only increase the skill sets of said staff, but will also help them better understand how their roles fit within the larger picture of the institution. This, in turn, will organically improve communication and workflow, as well as lead to more collaboration and teamwork. The result: positive institution-wide change.

Moving Forward

Think about your institution’s focus when implementing a new ERP system—and be aware of the benefits that it could have for your staff, your students, and your bottom line. You will face other ERP-related challenges, such as selecting the right third-party vendor and facilitating change management. If you’d like to discuss some strategies for tackling these challenges, this process is easy—just send me an email.

Blog
The people component: Why higher education institutions should focus on staff when implementing an ERP system

A year ago, CMS released the Medicaid Enterprise Certification Toolkit (MECT) 2.1: a new Medicaid Management Information Systems (MMIS) Certification approach that aligns milestone reviews with the systems development life cycle (SDLC) to provide feedback at key points throughout design, development, and implementation (DDI).

The MECT (recently updated to version 2.2) incorporates lessons learned from pilot certifications in several states, including the successful West Virginia pilot that BerryDunn supported. MECT updates have a direct impact on E&E systems—an impact that may increase in the near future. Here is what you need to know:         

Then: Initial Release

In February 2017, CMS introduced six Eligibility & Enrollment (E&E) checklists. Five were leveraged from the MECT, while the sixth checklist contained unique E&E system functionality criteria and provided a new E&E SDLC that—like the MECT—depicted three milestone reviews and increased the Independent Verification and Validation (IV&V) vendor’s involvement in the checklists completion process.

Now: Getting Started

Completing the E&E checklists will help states ensure the integrity of their E&E systems and help CMS guide future funding. This exercise is no easy task, particularly when a project is already in progress. Completion of the E&E checklists involves many stakeholders, including:

  • The state (likely more than one agency)
  • CMS
  • IV&V
  • Project Management Office (PMO)
  • System vendor(s)

As with any new processes, there are challenges with E&E checklists completion. Some early challenges include:

  • Completing the E&E checklists with limited state project resources
  • Determining applicable criteria for E&E systems, especially for checklists shared with the MMIS
  • Identifying and collecting evidence for iterative projects where criteria may not fall cleanly into one milestone review phase
  • Completing the E&E checklists with limited state project resources
  • Working with the system vendor(s) to produce evidence

What’s Next?

Additionally, working with system vendors may prove tricky for projects that already have contracts with E&E vendors, as E&E systems are not currently subject to certification (unlike the MMIS). This may lead to instances where E&E vendors are not contractually obligated to provide the evidence that would best satisfy CMS criteria. To handle this and other challenges, states should communicate risks and issues to CMS and work together to resolve or mitigate them.

As CMS partners with states to implement the E&E checklists, some questions are expected to be asked. For example, how much information can be leveraged from the MECT, and how much of the checklists completion process must be E&E-specific? Might certification be required in the near future for E&E systems?

While there will be more to learn and challenges to overcome, the first states completing the E&E checklists have an opportunity to lead the way on working with CMS to successfully build and implement E&E systems that benefit all stakeholders.

On July 31, 2017, CMS released the MECT 2.2 as an update to the MECT 2.1.1. As the recent changes continue to be analyzed, what will the impact be to current and future MMIS and E&E projects?

Check back here at BerryDunn Briefings in the coming weeks and we will help you sort it out.

Blog
Check this: CMS checklists aren't just for MMIS anymore.

We all know them. In fact, you might be one of them — people who worry the words “go live” will lead to job loss (theirs). This feeling is not entirely irrational. When an organization is ready to go live from an existing legacy system to a new enterprise system, stress levels rise and doubts emerge: What can go wrong? How much time will be lost? Are we really ready for this?

We’re here to help. Here is a list of go-live essentials to help you mitigate stress and assess your readiness. While not all-encompassing, it’s a good place to start. Here’s what you need:

  1. A detailed project plan which specifies all of the implementation tasks
    A project plan is one of the most important parts of an implementation. A detailed plan that identifies all of the implementation tasks along with an assigned resource for each task is critical to success. The implementation vendor and the organization should develop this plan together to get buy-in from both teams.
  1. A completed system configuration
    New system configuration is one of the most time-consuming aspects of a technology implementation. If you don’t complete the implementation in a timely manner, it will impact your go-live date. Configure the new system based upon the best practices of the system — not how the existing system was — for timely implementation.
  1. External system interface identification
    While replacement of some external systems may be a goal of an implementation, there may be situations where external systems are not replaced or the organization has to send and/or receive data from external organizations. And while new systems have advanced interface technology capabilities, the external systems may not share these capabilities. Therefore it is imperative that you identify external system interfaces to avoid gaps in functionality.
  1. Testing, testing, testing
    End-to-end testing or User Acceptance Testing (UAT) is often overlooked. It involves completing testing scenarios for each module to ensure appropriate system configuration. While the timing of UAT may vary, allow adequate time to identify solutions to issues that may result from UAT.
  1. Data conversion validation
    When you begin using a new system, it’s best to ensure you’re working with clean, up-to-date data. Identify data conversion tasks in the project plan and include multiple data conversion passes. You must also determine if the existing data is actually worth converting. When you complete the data conversion, check for accuracy.
  1. End user training
    You must train all end users to ensure proper utilization across the organization. Don’t underestimate the amount of time needed for end user training. It is also important to provide a feedback mechanism for end users to determine if the training was successful.
  1. A go-live cutover plan
    The overall project plan may indicate go-live as an activity. List specific activities to complete as part of go-live. You can build these tasks into the project plan or maintain them as a separate checklist to promote a smooth transition.
  1. Support structure
    Establish an internal support structure when preparing for go-live to help address issues that may arise. Most organizations take time to configure and test the system and provide training to end users prior to go-live. Questions will arise as part of this process — establish a process to track and address these questions.

Technology implementations can significantly impact your organization, and it’s common for stress levels to rise during the go-live process. But with the right assessment and preparation, you can lessen their impact and reduce staff stress. Our experienced, objective advisors work with public and private sector organizations across the country to oversee large enterprise projects from inception to successful completion. Please reach out to us to learn more about preparing for your next big project.

Blog
Don't worry, just assess: Eight tips for reducing go-live stress