MITA 4.0, APDs, and more: Clearer guidance and helpful templates are coming!

This October, my colleagues and I attended the National Association of Health Data Organizations (NAHDO) annual meeting in Park City, Utah. NAHDO is a national non-profit membership and educational association dedicated to improving healthcare data collection and use. NAHDO is also a co-founder and member of the All-Payer Claims Database (APCD) Council, which provides leadership and technical assistance to states implementing APCDs. For more on the history of NAHDO, click here.

This year’s conference centered on balancing transparency, privacy, and quality in an age of enhanced reporting on public health information. As a follow-up to the annual meeting, I wanted to share with you some of the key takeaways:

1. Stakeholder engagement is key to achieving increased data transparency. As state agencies, hospitals, researchers, and other health data representatives embark on data transparency-related initiatives, representatives from Colorado, Maine, New Hampshire, and Washington made clear the importance of having the right stakeholders involved from the start. To NAHDO attendees these stakeholders include attorneys, providers, members, state agency representatives, legislators, payers, and others with the subject matter expertise and experience to integrate and publicly share health information data.
2. Collaboration maximizes cost transparency. Collecting cost-related information from providers, and making the information accessible to health data consumers, remains a difficult task for many organizations. Although several states have worked diligently with legislators to mandate that providers supply cost-related information to state health agencies, several other states have partnered with their member, provider, and insurance communities to form work groups that collaborate in the name of making healthcare more accessible and affordable.
3. If you build it, they may not come. Building treasure troves of information for health data consumers is only beneficial if the consumers know the information exists, and are interested in using it. To help spread the word about new web-based platforms and/or tools, organizations across the nation are leveraging creative marketing strategies via Google AdWords and Facebook. Colleagues from Colorado’s Shop for Care, Maine’s CompareMaine, New Hampshire’s HealthCost, New York’s FAIR Health, and Washington’s HealthCareCompare shared their successes and challenges in making the public aware of critical healthcare information. In support of this takeaway, Andrea Clark, BerryDunn’s Senior Analytics Manager, joined colleagues from the Center for Improving Value in Health Care, Washington State, and FAIR Health to speak about BerryDunn’s work helping clients develop enhanced public use healthcare data products. You can read more about that here.

Rally behind “The Year of Data Quality.” During the recent Medicaid Enterprise Systems Conference (MESC) in Portland, Oregon, Julie Boughn—Director of CMS’ Data and Systems Group—named 2018 “The Year of Data Quality.” NAHDO attendees, in support of this mission, highlighted that consistent nation-wide file layouts, coupled with consistent field definitions across databases, could go a long way in improving data quality in health IT solutions, such as APCDs.

In sum, the annual meeting was an excellent venue for hearing from data gurus, state health information officials, and those passionate about affecting change through health data solutions. As the conference in years past was attended mostly by APCD gurus, the stakeholder audience continues to broaden to include all those who have a hand in improving citizens’ health and well-being.

Are you struggling to improve business outcomes through modifications to your software solutions? If so, then you have no doubt tried — or are trying — traditional software implementation approaches. Yet, these methods can overwhelm staff, require strong project management, and consume countless hours (and dollars).

It may be time for your organization to consider the DevOps (Development and Operations) implementation model — a software implementation approach that uses agile methodologies.

The DevOps implementation model — proven to be effective in upgrading large software solutions such as Integrated Eligibility and Enrollment — increases organizational flexibility with frequent prioritization of business problems.

An alternative approach
In contrast to traditional software implementation approaches, the DevOps implementation model features continuous collaboration by the development and operations teams in breaking down, prioritizing, and implementing solution fixes in small release packages. Positive results include improved business prioritization through collaboration, better management of the backlog of software requests, focused development staff efforts, and high-velocity implementation of each release — leading to an improved software solution.

Here are seven essential implementation steps for adopting the DevOps implementation model:

Step 1: Define your software solution’s backlog of outstanding business problems — Understanding the business problems is the first step towards solving them.

Step 2: Prioritize the business backlog using such factors as:

• Operational impact
• Priority and severity levels
• Development level of effort
• Infrastructure considerations

Step 3: Schedule regular team meetings to address the status, prioritization, and resolution of the software solution’s business backlog — keeping the team focused and coordinated increases your efficiency towards resolution.

Step 4: Group prioritized items into small work packages that you can release through the software development life cycle (SDLC) in two- to three-week efforts —helping to keep work packages in small, organized, and manageable packages.

Step 5: Cycle each release through the various stages of the SDLC, utilizing an implementation approach that is defined, documented, and approved by all key stakeholders —providing a predictable and repeatable process for simultaneous development of multiple work packages.

Step 6: Schedule work package releases for implementation to help coordination and planning activities with stakeholders prior to implementation.

Step 7: Implement and integrate the software solution into operations. Making sure stakeholders are aware of release changes is critical for the success of a release. Be sure staff are trained ahead of the release, and that changes are communicated to all appropriate audiences.

You can pair DevOps with other methodologies. This allows you to address smaller components of functionality through DevOps while leaving larger components of functionality to traditional methodologies.

Other considerations:

• Once you resolve the business problem, monitor the solution to make sure the release did not negatively impact other areas of your software solution.
• Ensure the software solution is supported by management plans (e.g., change, configuration, and issue management plans) that are thorough and approved by the key stakeholders. This will help ensure expectations of processes and procedures are agreed upon.
• Maintain the list of business problems in a location accessible to all key stakeholders for awareness, accessibility, and accountability purposes.
• Communicate, report, and manage the status, definition, and/or resolution of issues and/or defects in a consistent, concise, and clear manner to assist in efficiently prioritizing and addressing your business problems.
• Begin communicating the impact of the issue and/or defect as soon as possible–the sooner the issue and/or defect is known; the quicker the team can begin down the path towards resolution.
• Develop materials to train affected staff. Clear and concise training materials will help educate and communicate updated processes to stakeholders.

Improving your software solution
Finding a way to improve your software solution does not always mean using traditional software implementation approaches. Based on our experience, we’ve learned that collaboration between the development and operations teams, and continuously repeating the seven steps of the DevOps implementation model, allows organizations to efficiently address software solution problems.

Interested in learning more about how the DevOps implementation model could work for your organization? Please contact Zachary Rioux.

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.  
 

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.

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.