Addressing the Pitfalls of Government Health Information...

Addressing the Pitfalls of Government Health Information Technology Implementation Projects

December 2014

Authored by:

Foster C. “Bud” Beall, Jr., MAPeggy C. Evans, PhDJeff Hummel, MD, MPH Qualis HealthSeattle, Washington

Addressing the Pitfalls of Government Health Information Technology Implementation Projects | of 14

Introduction

Regulatory requirements and advances in technology are

exerting considerable demands on federal, state, and

local government agencies to implement new information

systems or update existing ones. Government healthcare

agencies, including state Medicaid agencies, have

been especially impacted. Recent federal policies have

mandated implementation of Medicaid Management

Information Systems (MMIS) that comply with Medicaid

Information Technology Architecture (MITA) standards1.

The Affordable Care Act requires participating government

agencies to adopt technology that can deliver advanced

functionality (e.g., health insurance exchanges). And

other innovative technologies are being adopted with the

intention of greater efficiencies and cost savings. The

resulting system implementation projects are complex in

nature, large in size, and new in scope.

Because of the complexities of these new projects,

government technology implementation projects run

a high risk of failure, resulting in products that are

not implemented on time, on budget, or able to fulfill

the business needs that prompted the technology

procurement and implementation in the first place. Several

highly visible technology implementation failures have

captured the public eye in recent years, including the

healthcare.gov rollout in support of the Health Insurance

Marketplace, a cornerstone of the Affordable Care Act.

Additionally, several state MMIS implementation failures

have resulted in lawsuits over unpaid claims and public

backlash over spending of taxpayer dollars.

Case Study: One State Medicaid agency began its

original MMIS implementation in 2003 and went-live with

a significantly flawed system three years later. After initially

spending $25 million, this agency spent another $30

million dollars addressing the system issues only to be

faced with the realization after six months of being unable

to pay claims that the MMIS would never be able to meet

federal certification requirements. Four years and $55

million dollars later into the MMIS implementation project,

the agency decided to decommission the system and

start over with a new procurement that ultimately resulted

in a successful go-live three years later.

The Issues

There are multiple factors that contribute to the failure of

an implementation project.

Complexity and Scope: Government technology

implementations are inherently large, multi-year projects.

For example, Medicaid claims systems, eligibility systems,

and other Medicaid enterprise systems serve large

populations, process large volumes of data, and must

integrate with a number of other state systems. As a

result, there is a significant probability that a government

technology implementation project will not meet the

project goals and objectives. In fact, studies have shown

that larger projects are ten times more likely to fail3, and

are twice as likely to be late, over budget, and missing

critical features at go-live.

Because of the long duration of implementation

projects, the operational and technological environment

may change in the period between project start and

completion. New regulations, changes in organizational

priorities, and other external business factors may impact

requirements and project schedules. This can affect the

continuity of project staffing and may result in a loss of

project direction. The sheer number of project activities

Studies have shown that larger projects

are ten times more likely to fail3, and are

twice as likely to be late, over budget,

and missing critical features at go-live.


and issues can obscure the strategic vision and goals

set forth at the beginning of the project. Deficiencies in

project management plans and methods can allow key

project work plan dependencies to be missed, resulting

in significant scheduling delays and bottlenecks.

Unrealistic Expectations and Competing Priorities: A major system implementation involves and impacts

a diverse community of stakeholders associated with

an organization. It requires participation of executive

leadership, management, line staff, project management

and implementation teams, business partners, customers,

and numerous other community stakeholders that will

use or interact with the new system. This universe of

stakeholders will possess a set of goals, needs, and

priorities which can often conflict with one another.

Organizational expectations often begin to diverge as

early as the procurement process. Procurement rules

and system requirement priorities can create conflicts

and mixed messages that result in the acquisition of a

system that cannot possibly meet all expectations.

Over-emphasizing “low cost” or a specific set of functional

or technical requirements, for example, can create barriers

and limitations that have downstream impacts potentially

impeding the implementation process and resulting in a

system lacking the functionality to meet key operational

objectives. At the same time, procurement requirements

can incentivize software vendors to overpromise to win

contracts, further setting unrealistic expectations and

increasing the risk of a failed implementation.

Throughout the implementation project, maintaining

common goals, priorities, and expectations is a significant

challenge. “Political” and competitive divisions among

stakeholders impede the collaboration and coordination

necessary to ensure that an efficient and integrated

system solution is deployed. Ignoring or neglecting

conflicts further erodes an organization’s ability to

accurately set and manage expectations. This lack

of coordination often leads to unnecessary software

customization, replication of current inefficient business

processes, unrealistic project plans, strained relationships

between stakeholders, and ultimately a system that does

not sufficiently meet the organization’s needs.

Unproven Systems: The risks associated with the

implementation of newly developed or custom developed

systems are much higher than those associated with

systems that have a proven track record of success. Over

the past 10 years, a number of states have experienced

implementation delays, measured in years, and poor

performance associated with adopting these types of

unproven systems.

Lack of coordination often leads to

unnecessary software customization,

replication of current inefficient

business processes, unrealistic project

plans, strained relationships between

stakeholders, and ultimately a system

that does not sufficiently meet the

organization’s needs.


because “hundreds of critical user test cases were not

executed.7” The State Auditor also noted that the user

acceptance testing (UAT) and operational readiness

validation processes were flawed. The State Auditor

found that there were no established user acceptance

criteria by the state, a lack of clear benchmarks, and

acceptance criteria that was ultimately developed by

the vendor, creating a conflict of interest that resulted

in the state being unable to accurately assess software

operational readiness or system sufficiency. As result,

when the North Carolina MMIS system was fully deployed

in an operational setting, software defects and inefficient

system flows became readily apparent that were not

previously identified.

Lack of Transparency: Implementation project

management teams typically consist of a project

management office (PMO) supported by consultants and

other contract staff, with the group tracking and reporting

on project status, issues, and risks. In recent problematic

or failed projects, it was determined that senior leadership

and other key stakeholders were unaware of the depth

of issues and risks associated with their projects. The

PMO did not effectively communicate timely and accurate

project status (see case study about the Oregon health

insurance exchange website rollout on page 6).

Case Study: One State Medicaid agency terminated

its contract with its MMIS vendor to develop a custom

system after investing millions of dollars in design and

development. Despite the fact that the vendor had never

developed a system, their proposal and pricing had

convinced the agency that their approach offered the

best value. However, after considerable project delays

and issues, and upon a thorough review of the vendor’s

blueprint for the project, the agency concluded that the

vendor did not “have the capacity to deliver the system

they proposed.”

Software development is a complex, resource intensive,

time consuming endeavor, and implementations

associated with new development are much more

complicated and more likely to experience schedule

delays and cost overruns. Because the likelihood of major

system defects increases greatly with these types of

implementations, the importance of testing, contingency

planning, and other quality assurance measures take on

even greater significance.

Inadequate Testing: Developing effective test plans

and strategies, and conducting comprehensive testing

procedures to validate system performance and accuracy

are long-standing industry best practices. However, overly

aggressive implementation milestones and project delays

experienced during the development and implementation

phases of projects can motivate organizations to truncate

test processes or bypass key testing activities altogether.

In an effort make up for lost time and meet “go-live”

dates, organizations may skip critical system validation

steps, undermining the integrity of the new system. For

example, the North Carolina State Auditor found that

one key reason for its failed MMIS implementation was

To improve transparency and offer

greater assurances of effective project

management, government projects

have utilized independent verification

and validation (IV&V) resources to

assist the PMO and provide a neutral

and independent assessment of

project effectiveness.


Case Study: Recently, the federal government and several

states across the U.S. experienced significant delays and

functional problems with the implementation of health

insurance exchange solutions, despite the fact

that the technology was developed by a number of

well-known software vendors. One State’s health

insurance exchange website suffered from a failed

implementation due to 1) ineffective communications

between leading state entities, 2) limited cross-agency

collaboration, and 3) lack of a single point of

authority to make decisions, among other key factors.

A post-mortem assessment of the implementation

indicated also that communication to leadership was often

“confusing” or “misinterpreted.” Members of the project

oversight committee indicated that they were unaware

of the IV&V vendor’s role and did not receive any of the

IV&V vendor’s reports that indicated concerns about the

project. This resulted in an erroneous understanding of the

true status of progress toward project deadlines.

To improve transparency and offer greater assurances

of effective project management, government projects

have utilized independent verification and validation

(IV&V) resources to assist the PMO and provide a neutral

and independent assessment of project effectiveness.

However, the key benefits of the IV&V function can be lost

due to potential flaws in the project reporting structure.

Placing IV&V in a subordinate role to the PMO and

prohibiting IV&V from reporting assessment results directly

to senior leadership increases the risks that key findings

and recommendations will be filtered, sanitized, or ignored

by the PMO. As a result, senior leadership may not be

aware of important issues and potential risks.


Mitigation Strategies

While government technology implementations can

be difficult because of the nature of the projects and

requirements, implementations can be successful with the

right experience and the right team in six key areas:

1) Planning

2) Leadership

3) System Validation

4) Project Monitoring and Metrics

5) Business Process Transformation

6) Risk Management

Below we discuss the key strategies government agencies

should take to have a successful implementation.

1) PlanningThe team must have a shared vision of the project

objectives, and maintain a strategic approach to

implementation that includes a focus on the milestones,

understanding the dependencies between project tasks,

and also the contingencies, which can be developed into

a project management plan. Additionally, the team will

want to create specific strategies for implementation,

communications, and change management at the outset

of the project.

Project Management Plan:

• Establishastrategic-levelmanagementplanand

schedule time to document major goals, constraints,

milestones, resource needs, and dependencies

based on consistently maintained detailed project

work plans.

• Beginningintheprocurementprocessandcarried

through design, development, implementation, and

post implementation, leadership must focus on the

project “critical path:” maintaining organizational

priorities, monitoring key milestones and

dependencies, and understanding the implications

of deviations from plan.

Too often projects get bogged down in issues that are not

critical to the success of the implementation. This results

in mission critical tasks, such as quality assurance (QA),

training, go-live/operational readiness, and testing phases

being truncated or abbreviated to meet milestones,

thereby increasing the risk of implementation failure.

Implementation Strategy:

• Establishanimplementationstrategythatallows

for phased functionality deployment, contingency

planning, operational readiness planning, and post-

implementation activities.

• Post-implementationactivitiesshouldprovidefor

system stabilization, performance monitoring, and

implementation of any deferred functionality.

These implementation activities fit within the standard

system development life cycle (SDLC) and align with

the key SDLC phases: design, development, and

implementation (DDI). Allowing for phased functionality

deployment provides for a more controlled system

roll-out, and helps to organize the larger, complex

implementation project into smaller, more

manageable subprojects.

Develop a communication strategy and

protocols early in the process to share

information between project managers,

operations, leadership, vendors, and

other key stakeholders, and adjust them

to meet changing project requirements.


Communication Strategy:

• Developacommunicationstrategyandprotocols

early in the process to share information between

project managers, operations, leadership, vendors,

and other key stakeholders, and adjust them to meet

changing project requirements. The approach should

reinforce project goals and criteria for success.

• Developmethodstomaintaininvolvementand

cooperation with diverse stakeholders through

reporting, meetings, town hall sessions, and

other forums.

As government agencies develop their communications

strategies, consider involving well-respected “champions”

as project advocates to work with project stakeholders,

reinforcing the goals and benefits of the new system. In

addition, the project will benefit from engaging potential

detractors to address their issues and concerns.

Suggestions for engagement of potential detractors

include providing a platform to share concerns, involving

them in developing solutions, and if feasible, incorporating

their recommendations in the project.

Change Management Strategy:

• Establishandimplementconsistentchange

management processes early in the project.

• Proceduresmustbeinplacetoensurethatonly

those system changes that are absolutely necessary

are made. Criteria must be established to determine

whether and when changes in design should be

allowed, and a governing body must be established to

review, evaluate, and approve system changes.

Business operations do not go on hiatus during the

implementation project, and as a result, environmental

changes and business demands may necessitate

changes to the design and functional requirements of

the new system. These changes, however, need to be

minimized, controlled, and managed properly. If not, an

inordinate number of system changes will adversely affect

development activities and undermine quality assurance

activities. On-going changes to design and functionality

do not allow for proper testing, and set the stage for

deploying a system with untested and potential

defective functionality.

2) LeadershipThe leadership of an implementation project is critical

to develop and maintain a shared vision for the project,

and to ensure that the implemented system ultimately

meets strategic and operational needs. There are several

components of effective leadership, described below.

Maintain Shared Vision, Strategic Focus,

and Commitment:

• Leadershipmustbeabletoarticulatewhycurrent

state operational processes and/or systems are

inadequate, a vision for an improved future state

including the benefits, and the business case for

making changes. Leadership should also have clear

understanding of the implementation project and

the business needs that the technology supports,

including identifying business cases for all major

business processes.

• Leadershipshouldensurethattheimplementation

team maintains a strategic approach keeping the

project moving toward established objectives,

including goals that may include deploying

business process improvements, achieving system

certification and meeting regulatory requirements.

• Beginningintheprocurementprocessandcarried

through design, development, implementation, and

post implementation, leadership must focus on the

project “critical path” of maintaining organizational

priorities, monitoring key milestones and

dependencies, and understanding the implications

of deviations from plan.


Government agencies must also live up to their

contractual obligations with vendors and other project

stakeholders, including providing appropriate staffing,

meeting deadlines, and completing administrative

functions (e.g., task orders, deliverables) in a timely

manner. Lack of engaged, visible, and committed

leadership throughout the project can impede the

timeliness of key decisions, impact project momentum,

and lead to cutting corners. This typically creates

vulnerabilities that make it more difficult to effectively

address vendor performance issues.

Communications with leadership:

• Developacommunicationplanthatinvolves

leadership to ensure they have enough information to

make informed decisions that have significant impact

on the project, such as procurement strategies,

financial management, and timelines.

To have a successful implementation, strategic reporting

to leadership needs to occur throughout the project

life cycle so that leadership is informed, has the ability

and knowledge to give feedback, can provide guidance

and remove barriers, and intervene with stakeholders,

vendors, and others, if necessary. Leadership can also

articulate decisions and the decision making process

to stakeholders, including business partners and the

taxpaying public.

Clear governance structure:

• Developanoversightstructuretoidentifyand

mitigate factors that increase risk of failure identified

in the planning stage. One element of the oversight

may be to establish a collaborative working

environment between the government agency

implementing the system, software vendor, IV&V,

and operating departments.

• Establishmulti-disciplinary,seniorlevelleadership

team to address and resolve conflicts and

set direction.

A well-defined governance structure, with clearly

identified roles and responsibilities, and communications

protocols with leadership should be identified early in

the implementation process. Governance leadership

can assist with addressing major disagreements and

interdepartmental conflicts, as well as pave the way for

difficult messages identifying potential issues and risks.

An independent IV&V function should be

in place to assist and monitor the PMO,

and to provide independent assessments

of project management performance and

project status to executive management.

Project Management (PMO) Accountability:

• Theprojectmanagementteamshouldworkclosely

with software vendors, operating departments,

and organizational leadership to plan, control, and

execute project activities. Projects must be led by the

government agency PMO, collaborating with vendor

project management teams, operating department

leadership, “governance bodies,” and the IV&V entity,

and not solely dependent upon a vendor to manage

the project.

• IfanexternalconsultantperformsthePMOrole,an

internal senior level project sponsor/manager must be

dedicated to collaborate with the PMO. Someone with

“authority” within the government organization must be

involved at the highest levels of project leadership.

• ThePMOfunctionmustconformtoindustrystandards

such as IEEE and Project Management Body of

Knowledge (PMBOK), and must be accountable to

engaged executive leadership. This accountability

must include frequent, consistent, and transparent

communication of project status, issues, risks, and

mitigation strategies through reports, dashboards,

and meetings.


• AnindependentIV&Vfunctionshouldbein

place to assist and monitor the PMO, and to

provide independent assessments of project

management performance and project status

to executive management.

An effective project management function is essential to

the success of any project. Recent surveys and research

all demonstrate that poor project management can

negatively impact a technology implementation9,10.

3) System ValidationIf appropriate testing planning, execution, and

documentation steps have been followed, the final “go/

no-go” decision will be meaningful. Without the proper

planning and documentation (data), the organization is

incapable of making an informed “go/no-go” decision. It

cannot be confident that an appropriate testing process

was completed and that results of the testing process

are truly indicative of the system’s performance in a

production environment.

Planning:

• Documenttestingstrategiesandactivitiesinatest

plan and comply with test plans.

• Ensurethattheprojectfollowspre-definedplans

by allowing for sufficient time and resources to

validate mission critical test cases in a designed,

systematic fashion.

• Testingprocessesshouldincludeadiversesetof

organizational stakeholders who will be reliant

upon the system.

• Exitcriteriaidentifying“acceptable”levelsofdefect

rates for all testing activities should be defined prior

to testing. Exit criteria establish the basis for

go/no-go decisions.

While nearly all major system implementation projects

will have an established test plan, complying with these

plans has been inconsistent. Complying with test plans,

defining user acceptance criteria, allowing sufficient time

for testing, and engaging a diverse set of stakeholders

who will use the system will be imperative for the success

of the implementation.

Documentation:

• Documentingtestcases,scripts,acceptancecriteria,

and results must be performed.

• Testcasesshouldreflectthecomprehensiveand

mission-critical business processes impacted

by the system.

• Loggingtestresultsandassigningclearlydefined

severity levels for defects helps the organization to

more effectively monitor and remediate quality issues.

Effective test documentation provides the organization

with a systematic approach to testing. Test cases, scripts,

and acceptance criteria establish a consistent method for

validating system performance and accuracy.

Execution:

• Duringtesting,softwaredefectsmustbeassigned

clearly pre-defined severity levels, documented

against the test case, and monitored. Staff

responsible for testing must have a unified (consistent)

understanding of defect severity levels, and should

not over or under state severities as realistic

assessments are critical.

• Largesystemimplementationsshouldincludetesting

activities by an internal or external IV&V or QA entity,

to independently validate the test results. Independent

testing will help to confirm test results and the

appropriateness of test cases. When this does not

occur, the government agency may be overly reliant

on the software vendor to accurately document and

report test results and system defects.


The software vendor and organization must work together

to ensure that key test phases include, at a minimum,

functional testing, integration testing, user acceptance,

and operational readiness testing. Departmental

operations staff must be included in testing and validation

of the system to ensure mission critical functionality is

fully operational, effective, and efficient prior to go-live.

4) Project Monitoring and Metrics

Monitoring:By the time that a project reaches the monitoring phase, it

is quite possible that there will have been changes to the

initial project plans. During this phase,

• Teammembersmustreviewprojectplansand

timelines to evaluate how the project is progressing.

• Teammembersmustmanagescopechanges,

report and mitigate project risks document and

store progress reports, and continue to inform and

engage stakeholders and leaders, according to the

communications plan.

• IfanIV&VorQAentityisengagedintheproject,

project monitoring would include partnering with the

IV&V or QA entity and others responsible for work

processes to make sure all activities are aligned with

the strategic plans and specifications.

• Teammembersshouldidentifyandimplementclear

metrics to monitor the progress of the project.

When monitoring and evaluating project metrics, it is

important not to suppress or ignore performance results

that indicate problems. Warnings are important indicators

of project status and should not be viewed as indicators

of “personal failure” or treated as a threat. They are

meant to provide feedback that must be evaluated and

addressed in order to identify and prioritize risk mitigation

strategies and promote improvement.

Equally important but external to the organization is to

ensure that the software vendor has the right staff for the

implementation (e.g., personnel that is adequately trained

and/or are experienced subject matter experts), and

that the vendor is well-staffed (e.g., has enough people

assigned to the project).

Gate Reviews for Medicaid-Related

Implementation Projects:

• Agatereviewwouldbetriggeredwhenthebulkof

work within a phase is complete based on pre-defined

exit and entrance criteria.

• Aprojectshouldnotmoveforwardwithouthaving

conducted a gate review, assessing results, and

developing or adjusting plans to mitigate risks and

implement corrective actions.

Conducting gate reviews is a CMS Enterprise Life Cycle

standard and is intended to provide oversight, guidance,

and coordination for large, complex information system

implementations to achieve higher levels of success

in Medicaid-related system implementations. Gate

reviews give project leadership a complete picture of

project status at a specific stage in the project, based

on quantitative and qualitative data, in order to support

decision making. This includes go/no-go decisions as to

whether the project is ready to close the previous phase

and transition to the next life cycle phase.


5) Business Process Transformation Many government agencies are in the midst of major

transformation of their IT systems and business

processes. State Medicaid agencies, for example, are

implementing systems that will allow them to employ

innovative reimbursement models, provide new healthcare

services, assist with eligibility expansion, and pilot test

new care delivery models. As business models change,

so must existing business processes, requiring a need for

business process re-engineering and communications to

support change management.

Business process re-engineering:

• Projectteamsworkwithinternalstafftoidentify

changes in processes that will help with project

design and implementation.

• Teammembersshouldpartnerwithvendorsto

develop process flow maps of how the software can

support operations. Attention to process flow will

be an essential component of successful change

management, empowering the operations staff who

must implement the technology and gaining buy-in

from other stakeholders.

• Ensurethatoperationsstaffisinvolvedinkey

workflow, system design, and system build decisions.

Government agencies should not rely solely on the vendor

or other support entities, such as outside consultants

or PMO-based analysts to make all decisions regarding

system design and new business processes. These

support entities can help to expedite workflow and system

design, but the operations staff is ultimately responsible

for these processes and must be involved. It is critical to

engage knowledgeable operations staff to re-engineer

business processes that effectively align with new

system functions, offer greater efficiencies, and comply

with business requirements. This involvement promotes

adoption and helps to head-off issues at go-live.

Performance metrics:

• Aspartofthebusinessre-engineeringefforts,itis

useful to collect data designed to inform whether

the new system and processes are generating

performance improvements.

• Defineandmeasurekeyperformanceindicators

before and after the new system is implemented.

Data can drive transformation by revealing whether

changes have an impact, and which changes have the

strongest effects.

It should be expected that initially performance will

decline as the organization acclimates to the new

system, however, with continued post-implementation

measurement, monitoring, and refinements, improvements

should be observed. Additionally, performance metrics are

also essential in determining whether software vendors

are meeting contractual obligations. The organization

will need to monitor and assess whether the vendor is

complying with Service Level Agreements and other

contract terms.


6) Independent Verification & Validation

IV&V is a valuable asset that informs and supports the

implementation, including support of leadership and the

PMO. However, when engaging IV&V, the organization

should strive to insulate the IV&V function from the PMO.

This is not to isolate the IV&V function, but to promote

objective and transparent performance feedback to

the organization by ensuring that IV&V findings and

recommendations are readily available to leadership.

Project Control:

• Optimally,IV&Vwouldbeinvolvedbeginninginthe

procurement process.

• TheIV&Vfunctionshouldbeengagedeffectivelyto

support the PMO in its efforts to plan, monitor, and

control the implementation project.

• TheroleoftheIV&Vteamshouldbetopromote

visibility, accountability, and fact-based decision

making for technology initiatives, increasing the

likelihood of a successful system implementation.

Through consistent and periodic IV&V assessments

focused on key activities most relevant to the

project phase or milestone, the IV&V entity will help to

ensure that 1) the system is designed and built upon

the proper requirements (verification); and 2) the system

functions as designed, works effectively in the intended

operating environment, ands meets performance

expectations (validation).

Risk Management:

• UseIV&Vtoidentifyhigh-riskareasearlyinthe

implementation project to allow businesses to either

mitigate risks or prepare for contingencies.

• IV&Vcanalsobeusedtorecommendremediation

strategies and steps, as well as monitor associated

resolutions and outcomes.

IV&V can provide support for project management efforts

by offering proactive guidance and advice. Additionally,

IV&V teams can nurture communications

and collaboration between your organization, system

vendors, and other stakeholders, assisting with issue

resolution as needed.

SummaryGovernment technology implementation projects have

high rates of failure because the requirements tend to

be complex and new to organizations, with far-reaching

business implications and the ability to impact a variety of

stakeholders. In the last five to ten years, numerous state

Medicaid MMIS implementation projects have suffered

highly visible failures, only to spend millions of dollars

more to correct initial errors.

However, technology implementation projects do not have

to fail. The recommendations presented in this document

describe critical elements that, if followed, will lead to a

higher probability of implementation success. The key

drivers of success will be giving the appropriate resources

to the project (staffing, attention), which means creating

and maintaining an experienced project team that can

align the implementation with the strategic roadmap, is

capable of leading the implementation tasks, and has the

ability to know when the project may be veering off path

and can bring it back to the center.

It might be helpful to contract with external parties to

assist you with aspects of your implementation project.

Experienced consulting organizations will have the benefit

of having been part of multiple implementation projects in

the government sector, and can bring those experiences

to your team.

Note to Reader: This paper contains examples of government health information technology projects that have experienced implementation problems. The information presented in project examples and the Case Studies was collected through research of readily available materials, and is not related to any current or past Qualis Health client project. Qualis Health has not provided any project or client specific information in this paper.


About Qualis Health

Qualis Health is one of the nation’s leading population health management organizations, and a leader in improving care

delivery and patient outcomes, working with clients throughout the public and private sector to advance the quality,

efficiency and value of healthcare for millions of Americans every day. We deliver solutions to ensure that our partners

transform the care they provide, with a focus on process improvement, care management and effective use of health

information technology. We have experience offering a broad range of IV&V, quality assurance, and project oversight

expertise to a range of different government clients.

Whereas other consulting firms often provide a “check-the-box” approach to technology implementation project

oversight, Qualis Health collaborates with our clients to enable an approach that fits your unique implementation needs.

We have broad and detailed understanding of the technology implementation issues facing government agencies today

based on the experiences we have gained through the completion of other projects in the public and private sector.

Our consulting team consists of senior level consultants or managers that possess a minimum of 10 years of related,

real-work experience. Each member of the team has extensive experience with a variety of state and local government

agencies and demonstrates skills in one or more of the following areas: information technology, project management,

business and clinical operations, management, and technical operations.

The consulting team has access to Qualis Health subject matter experts from departments throughout our company. This

includes healthcare and health IT professionals with care management, quality improvement, and practice transformation

experience. Qualis Health professionals are active in the healthcare marketplace and can bring to your organization a

comprehensive understanding of trends, best practices, regulatory requirements, and advances in technology.

For more information about Qualis Health’s services, please contact

Bud Beall, Vice President of Consulting Services at [email protected].


References

1 Friedman, H.R. (2007). Medicaid Information Technology Architecture: An Overview.

Health Care Financing Review, 28 (2), 1-9.

2 Harvey, B., & Chacon R. An inside look at Maine’s MMIS Implementation. Government Health IT, July 19, 2011.

Retrieved June 25, 2014 from www.govhealthit.com/blog/inside-look-maines-mmis-implementation.

3 The Standish Group. CHAOS Manifesto 2013. Boston, MA: The Standish Group International, Incorporated, 2013.

4 Hayes, H.B. Why are Medicaid MIS contracts failing? Government Health IT, October 30, 2009. Retrieved June 25,

2014, from www.govhealthit.com/news/why-are-medicaid-mis-contracts-failing.

5 Nebraska nixes multi-million dollar contract. (2009). Retrieved June 25, 2014, from

journalstar.com/news/local/nebraska-nixes-multimillion-dollar-contract/

article_1b90dd1e-7e36-11de-83a2-001cc4c002e0.html.

6 Richardson, V. Colorado unveils Obamacare tax to boost struggling state exchange.

The Washington Post, June 10, 2014. Retrieved June 25, 2014, from

www.washingtontimes.com/news/2014/jun/10/colo-unveils-obamacare-tax-boost-state-exchange/.

7 Wood, B.A. Performance Audit, Department of Health and Human Services,

NCTracks (MMIS Replacement) – Implementation. Raleigh, NC: Office of the State Auditor, May 2013.

8 First Data Government Solutions. Cover Oregon Website Implementation Assessment,

Assessment Report. Atlanta, GA: First Data Corporation, April, 2013.

9 Chen, C.C., Law, C.C.H, & Yang, S.C. (2009). Managing ERP implementation failure:

A project management perspective. IEEE Transactions on Engineering Management, 56 (1), 157-170.

10 Bloch, M., Blumberg, S., & Laartz, J. Delivering large-scale IT projects on time, on budget, and on value.

Insights & Publications, McKinsey & Company, October 2012. Retrieved June 25, 2014, from

www.mckinsey.com/insights/business_technology/

delivering_large-scale_it_projects_on_time_on_budget_and_on_value.

Addressing the Pitfalls of Government Health Information...

Documents

Transcript of Addressing the Pitfalls of Government Health Information...