Outcomes and organization development, part II

Here we go again! With the 2018 Medicaid Enterprise System Conference (MESC) underway, we have another Medicaid Enterprise Certification Toolkit (MECT) Release. On July 31, 2018, the Centers for Medicare and Medicaid Services (CMS) issued the MECT Version 2.3. Historically, CMS has updated their certification toolkit and lifecycles iteratively on a near yearly basis. With increasingly rapid technological advances and initiatives, CMS’ iterative releases of the MECT are provided in an effort to stay current with federal regulations and industry priorities.

Last year’s MECT update (version 2.2) brought a slew of certification checklist updates, with somewhat comprehensive changes to the certification criteria. Although there were still a few updates to the checklists, this year’s release focused more on updating the required documentation and processes, than revamping the checklists.

Many states are beginning work on Medicaid Information Management System (MMIS) modular procurements, to replace outdated or poorly functioning enterprise and legacy systems. States are continuing to conform the certification process to modern procurements; however, there is still gray area and differences in approach amongst states across regions. Certification teams eagerly await MECT updates as the Toolkit becomes more aligned with new modular procurements. Will MECT 2.3 accomplish that? Let’s look over some of the core certification elements, and consider the impacts. Are we collectively there yet, or do we still need to continue growing through the modular implementation pains?

CMS Certification Checklist Updates

The most impactful update to the certification checklist includes the comprehensive removal of the Medicaid Information Technology Architecture (MITA) Business Area Checklist Set. This removal is a nod to the ever changing Medicaid environment, where MITA-guided procurements are being replaced by modular business function mappings. Additional changes to the checklists include:

• Provider and Pharmacy checklists now include guidance tabs
• Program Integrity checklist now includes 6 additional certification criteria for Electronic Visit Verification (EVV) certifications
• Criterion TA.SP.75 was removed from the Access and Delivery checklists, and added to the Programmatic checklist in the IV&V Progress Report
• Two criteria, TA.DC.5 and TA.DC.6, were removed from the Intermediary and Interface checklists

Appendix D: MMIS IV&V Progress Report Updates

• Section instructions have been updated for all sections to include more detail and guidance

• General Information now includes fields for submitter company name and if/when the Project Partnership Understanding (PPU) document was sent to CMS. Activity 1 Consult Date and RFP release fields have been removed

• Summary of Project Progress and Status (formerly Executive Summary) instructions now direct the submitter to provide project-wide information, not just planned modules and/or seeking a Milestone Review

• Budget & Schedule Metrics (formerly Life Cycle Status and Schedule) now includes the ability to identify project and module state-specific metrics to report variance

• Life Cycle Status and Schedule replaced the MITA-Aligned Modules with Additional Modules to allow states to identify up to five (5) custom modules

• Risks and Recommendations instructions have been updated to direct the submitter to include project-wide information, not just planned modules and/or seeking a Milestone Review

• Programmatic Checklist now includes a “partially meets” assessment option

Required Artifacts (Appendix B) Updates

• One new artifact: New Medicare Card Program’s (NMCP) State Medicaid Agency Readiness Report (R1, R2, and R3)

• No removed artifacts

• One artifact with updates: Production Screenshots, Reports, and Data (R3)

Updates to the MECT Appendices

• Multiple updates to Appendix H: PPU Template, including updates to the section names, removal of multiple sections, and additional guidance on the use of this document

• Addition of Appendix K: Map of MITA Business Areas to Criteria (This document maps all of the MECT checklist criteria outside of the five core checklists to their appropriate MITA business area)

• Addition of Appendix L: Milestone Review Preparation Guide (This document explains how milestone reviews are conducted and how states can readily prepare for milestone reviews)

Additional Updates

• Updates to the Medicaid Enterprise Life Cycle (MECL)

• Updates to the MECL and At-a-Glance Sheets

• Additional recommendations for Independent Verification and Validation (IV&V) vendors, including when and how IV&V can provide advice to states

• Minor updates to additional MECT appendices

From initial assessment of the MECT 2.3 release, it is clear that CMS continues to take strides to align the certification process to support our new modular Medicaid enterprise world. Keep in mind that MECT 2.3 is the latest round of a continuous cycle. Though it will likely not be the answer to all states’ issues and needs, this release does make great strides in adapting to the ever-changing Medicaid landscape. As we reported last year with the release of MECT 2.2, CMS continues to foster and support an environment for states to better align their procurement and certification efforts with the new modular enterprise industry.

There’s a good chance that your organization is in the position of needing to do more with less under the strain of staffing constraints and competing initiatives. With fewer resources to work with, you’ll need to be persuasive to get the green light on new enterprise technology initiatives. To do that, you need to present decision makers with well-thought-out and targeted business cases that show your initiative will have impact and will be successful. Yet developing such a business case is no walk in the park. Perhaps because our firm has its roots in New England, we sometimes compare this process to leading a hiking trip into the woods—into the wild. 

Just as in hiking, success in developing a business case for a new initiative boils down to planning, preparation, and applying a few key concepts we’ve learned from our travels. 

Consensus is critical when planning new technology initiatives

Before you can start the hike, everyone has to agree on some fundamentals: 

Who's going? 

Where are we going? 

When do we go and for how long? 

Getting everyone to agree requires clear communication and, yes, even a little salesmanship: “Trust me. The bears aren’t bad this time of year.” The same principle applies in proposing new technology initiatives; making sure everyone has bought into the basic framework of the initiative is critical to success.

Although many hiking trips involve groups of people similar in age, ability, and whereabouts, for your business initiative you need to communicate with diverse groups of colleagues at every level of the organization. Gaining consensus among people who bring a wide variety of skills and perspectives to the project can be complex.

To gain consensus, consider the intended audiences of your message and target the content to what will work for them. It should provide enough information for executive-level stakeholders to quickly understand the initiative and the path forward. It should give people responsible for implementation or who will provide specific skills substantive information to implement the plan. And remember: one of the most common reasons projects struggle to meet their stated objectives (and why some projects never materialize to begin with), is a lack of sponsorship and buy-in. The goal of a business case is to gain buy-in before project initiation, so your sponsors will actively support the project during implementation. 

Set clear goals for your enterprise technology project 

It’s refreshing to take the first steps, to feel that initial sense of freedom as you set off down the trail. Yet few people truly enjoy wandering around aimlessly in the wilderness for an extended period of time. Hikers need goals, like reaching a mountain peak or seeing famous landmarks, or hiking a predetermined number of miles per day. And having a trail guide is key in meeting those goals. 

For a new initiative, clearly define goals and objectives, as well as pain points your organization wishes to address. This is critical to ensuring that the project’s sponsors and implementation team are all on the same page. Identifying specific benefits of completing your initiative can help people keep their “eyes on the prize” when the project feels like an uphill climb.

Timelines provide additional detail and direction—and demonstrate to decision makers that you have considered multiple facets of the project, including any constraints, resource limitations, or scheduling conflicts. Identifying best practices to incorporate throughout the initiative enhances the value of a business case proposition, and positions the organization for success. By leveraging lessons learned on previous projects, and planning for and mitigating risk, the organization will begin to clear the path for a successful endeavor. 

Don’t compromise on the right equipment

Hiking can be an expensive, time-consuming hobby. While the quality of your equipment and the accuracy of your maps are crucial, you can do things with limited resources if you’re careful. Taking the time to research and purchase the right equipment, (like the right hiking boots), keeps your fun expedition from becoming a tortuous slog. 

Similarly, in developing a business case for a new initiative, you need to make sure that you identify the right resources in the right areas. We all live with resource constraints of one sort or another. The process of identifying resources, particularly for funding and staffing the project, will lead to fewer surprises down the path. As many government employees know all too well, it is better to be thorough in the budget planning process than to return to authorizing sources for additional funding while midstream in a project. 

Consider your possible outcomes

You cannot be too singularly focused in the wild; weather conditions change quickly, unexpected opportunities reveal themselves, and being able to adapt quickly is absolutely necessary in order for everyone to come home safely. Sometimes, you should take the trail less traveled, rest in the random lean-to that you and your group stumble upon, or go for a refreshing dip in a lake. By focusing on more than just one single objective, it often leads to more enjoyable, safe, and successful excursions.

This type of outlook is necessary to build a business case for a new initiative. You may need to step back during your initial planning and consider the full impact of the process, including on those outside your organization. For example, you may begin to identify ways in which the initiative could benefit both internal and external stakeholders, and plan to move forward in a slightly new direction. Let’s say you’re building a business case for a new land management and permitting software system. Take time to consider that this system may benefit citizens, contractors, and other organizations that interact with your department. This new perspective can help you strengthen your business case. 

Expect teamwork

A group that doesn’t practice teamwork won’t last long in the wild. In order to facilitate and promote teamwork, it’s important to recognize the skills and contributions of each and every person. Some have a better sense of direction, while some can more easily start campfires. And if you find yourself fortunate enough to be joined by a truly experienced hiker, make sure that you listen to what they have to say.

Doing the hard work to present a business case for a new initiative may feel like a solitary action at times, but it’s not. Most likely, there are other people in your organization who see the value in the initiative. Recognize and utilize their skills in your planning. We also suggest working with an experienced advisor who can leverage best practices and lessons learned from similar projects. Their experience will help you anticipate potential resistance and develop and articulate the mitigation strategies necessary to gain support for your initiative.

If you have thoughts, concerns, or questions, contact our team. We love to discuss the potential and pitfalls of new initiatives, and can help prepare you to head out into the wild. We’d love to hear any parallels with hiking and wilderness adventuring that you have as well. Let us know! 

BerryDunn’s local government consulting team has the experience to lead technology planning initiatives and develop actionable plans that help you think strategically and improve service delivery. We partner with you, maintaining flexibility and open lines of communication to help ensure that your team has the resources it needs.

Our team has broad and deep experience partnering with local government clients across the country to modernize technology-based business transformation projects and the decision-making and planning efforts. Our expertise includes software system assessments/planning/procurement and implementation project management; operational, management, and staffing assessments; information security; cost allocation studies; and data management.  

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.
 

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. 
 

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.

Best practices for financial institution contracts with technology providers

As the financial services sector moves in an increasingly digital direction, you cannot overstate the need for robust and relevant information security programs. Financial institutions place more reliance than ever on third-party technology vendors to support core aspects of their business, and in turn place more reliance on those vendors to meet the industry’s high standards for information security. These include those in the Gramm-Leach-Bliley Act, Sarbanes Oxley 404, and regulations established by the Federal Financial Institutions Examination Council (FFIEC).

On April 2, 2019, the FDIC issued Financial Institution Letter (FIL) 19-2019, which outlines important requirements and considerations for financial institutions regarding their contracts with third-party technology service providers. In particular, FIL-19-2019 urges financial institutions to address how their business continuity and incident response processes integrate with those of their providers, and what that could mean for customers.

Common gaps in technology service provider contracts

As auditors of IT controls, we review lots of contracts between financial institutions and their technology service providers. When it comes to recommending areas for improvement, our top observations include:

• No right-to-audit clause
  Including a right-to-audit clause encourages transparency and provides greater assurance that vendors are providing services, and charging for them, in accordance with their contract.
• Unclear and/or inadequate rights and responsibilities around service disruptions
  In the event of a service incident, time and transparency are vital. Contracts that lack clear and comprehensive standards, both for the vendor and financial institution, regarding business continuity and incident response expose institutions to otherwise avoidable risk, including slow or substandard communications.
• No defined recovery standards
  Explicitly defined recovery standards are essential to ensuring both parties know their role in responding and recovering from a disaster or other technology outage.

FIL-19-2019 also reminds financial institutions that they need to properly inform regulators when they undertake contracts or relationships with technology service providers. The Bank Service Company Act requires financial institutions to inform regulators in writing when receiving third-party services like sorting and posting of checks and deposits, computation and posting of interest, preparation and mailing of statements, and other functions involving data processing, Internet banking, and mobile banking services.

Writing clearer contracts that strengthen your institution

Financial institutions should review their contracts, especially those that are longstanding, and make necessary updates in accordance with FDIC guidelines. As operating environments continue to evolve, older contracts, often renewed automatically, are particularly easy to overlook. You also need to review business continuity and incident response procedures to ensure they address all services provided by third-parties.

Senior management and the Board of Directors hold ultimate responsibility for managing a financial institution’s relationship with its technology service providers. Management should inform board members of any and all services that the institution receives from third-parties to help them better understand your operating environment and information security needs.

Not sure what to look for when reviewing contracts? Some places to start include:

• Establish your right-to-audit
  All contracts should include a right-to-audit clause, which preserves your ability to access and audit vendor records relating to their performance under contract. Most vendors will provide documentation of due diligence upon request, such as System and Organization Control (SOC) 1 or 2 reports detailing their financial and IT security controls.
  
  Many right-to-audit clauses also include a provision allowing your institution to conduct its own audit procedures. At a minimum, don’t hesitate to perform occasional walk-throughs of your vendor’s facilities to confirm that your contract’s provisions are being met.

• Ensure connectivity with outsourced data centers
  If you outsource some or all of your core banking systems to a hosted data center, place added emphasis on your institution’s business continuity plan to ensure connectivity, such as through the use of multiple internet or dedicated telecommunications circuits. Data vendors should, by contract, be prepared to assist with alternative connectivity.

• Set standards for incident response communications 
  Clear expectations for incident response are crucial  to helping you quickly and confidently manage the impact of a service incident on your customers and information systems. Vendor contracts should include explicit requirements for how and when vendors will communicate in the event of any issue or incident that affects your ability to serve your customers. You should also review and update contracts after each incident to address any areas of dissatisfaction with vendor communications.

• Ensure regular testing of defined disaster recovery standards
  While vendor contracts don’t need to detail every aspect of a service provider’s recovery standards, they should ensure those standards will meet your institution’s needs. Contracts should guarantee that the vendor periodically tests, reviews, and updates their recovery standards, with input from your financial institution.
  
  Your data center may also offer regular disaster recovery and failover testing. If they do, your institution should participate in it. If they don’t, work with the vendor to conduct annual testing of your ability to access your hosted resources from an alternate site.

As financial institutions increasingly look to third-party vendors to meet their evolving technology needs, it is critical that management and the board understand which benefits—and related risks—those vendors present. By taking time today to align your vendor contracts with the latest FFIEC, FDIC, and NCUA standards, your institution will be better prepared to manage risk tomorrow.

For more help gaining control over risk and cybersecurity, see our blog on sustainable solutions for educating your Board of Directors and creating a culture of cybersecurity awareness.
 

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.  

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.

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.