How one American state implemented successful health-insurance reform

And how Sparx tools helped them do it

This 2014 Case Study examines how two Sparx partners - including a major global consulting firm - used Sparx
software to help one American state government build an state-operated Health Insurance Exchange that was
totally successful in its mission from the first day it opened.

The review that follows illustrates how Sparx Enterprise Architect software can accelerate major projects by utilizing
re-usable knowledge stored in an open-standards-based framework and how that framework can enhance
team-based modeling, collaboration and planning.

The scope of this analysis extends to the application of Enterprise Architecture practices during development of
a health insurance exchange - and it wisely leaves any evaluation of the underlying public-policy issues to publicaffairs
specialists writing in policy-focused publications.

The Mission

In 2010 the U.S. federal government passed legislation intended to provide affordable medical insurance to vast
numbers of uninsured or underinsured American citizens. The legislation empowered state governments to
implement solutions that were built and managed locally -- at the state level. That is the focus of this study.

One of the things the legislation does to extend health insurance coverage is create new government-operated
insurance exchanges that provide consumers with access to individual medical-insurance policies. These exchanges
are essentially closed, controlled marketplaces where consumers shop for policies and, depending on
income eligibility, apply individual tax credits to offset the cost of their insurance premiums. The business model
is designed to encourage competition between insurance vendors.

For those unfamiliar with the U.S. health care system, there is no universal health insurance plan for Americans
under age 65, and as recently as 2013 almost a sixth of the American population had neither medical insurance
nor access to publicly-funded medical services beyond hospital emergency rooms.

Several state governments created their own insurance exchanges -- forgoing the option of leaving this service in
the hands of a national exchange. Consumers logged in to exchanges through the web or by a toll-free phone to:

establish a personal account as a basis for all subsequent interactions and transactions;

determine individual eligibility for income-based government tax credits to mitigate the cost of
premiums for insurance purchased on the exchange; and

place an order to purchase their preferred insurance plan from their selected vendor, with
mitigating government subsidies applied at the source to the final price charged to the
consumer.

The legislation gave federal and state governments three and a half years to create an entirely new private/public
insurance program - including the delivery system - all pretty well from scratch and with many of the regulations
undefined at the outset.

Before setting up the exchanges, the project teams in each jurisdiction needed to create the internal infrastructure
for building the program and the delivery system. They needed to identify and define requirements; determine
processes, protocols and standards; create mechanisms for collaboration, planning building, and testing and
select the tool(s) necessary to support all of this work.

The Requirements

This case study looks at one of 14 states that chose to build and operate its own exchange. This exchange adhered
to federal standards, but the federal government was not directly involved in either its development or its
management.

The state-operated exchanges have very little visibility outside their own jurisdiction. Across the United States,
the largest, highest-pro-file exchange has always been the federal operation - which today provides direct
exchange services in most American states.

Long before any of the exchanges opened their web sites, call centers and front counters to consumers, developers
working behind the scenes spent an intense couple of years setting up internal infrastructure while program
managers were busy negotiating with insurance vendors and creating dynamic links with income-verifying federal
databases. Pulling all these elements together into a complex, interactive "ecosystem" was one of the main challenges
facing the developers building each of the exchanges.

Federal legislation set out the major business requirements, business processes and the timelines for creating and
launching the program. This meant that state governments and their contractors had even less "wiggle-room"
than normal for tweaking the main features or adjusting the deadlines - even if everyone agreed there was a
strong business case for doing so.

On October 1, 2013 the federal exchange and its state-level counterparts went live and opened for business. The
results varied from one exchange to the next.

The media frenzy on launch day focussed on the federal exchange, which repeatedly crashed, froze or timed out
before consumers were able to complete the application process. Many of the state-operated exchanges experienced
similar problems at launch, but not all of them.

The state exchange featured in this case study - located in the eastern U.S.A. - was one of the
few that fully delivered on its promise to consumers right from day one. It was identified by an independent Associated
Press analysis in February, 2014 as one of the "successful state exchanges [that] have outperformed the
federal website." A Google search identified several other articles with similar conclusions.

The state government was very pleased with the results. At a time when most other governments were still
apologizing for a seriously-flawed start, the state director of our case study exchange was able to boast that her
operation had "performed beyond expectations."

She was quoted in the media saying "We have one of the only systems that's up and running - and has been
since the beginning."

This state - and its contracted IT companies - clearly did something right.

One of Sparx' Global Partners - a major international consulting firm - was principal contractor during the final 27
months of planning, design and development of this state-level exchange. Their team was led by senior partners
from the firm's highly specialized enterprise architecture practice - supplemented by a couple of trusted outside
experts from the Sparx Global Network.

The initial nine-month engagement - while the project was still in planning and high level design - started in
2011, less than three years before launch. During that first phase the consulting team was responsible for several
core elements:

strategic planning;

the IT gap analysis;

the implementation roadmap;

the budget for the exchange and the application for federal funding assistance; and

the identification and flagging of any functional and technical gaps between the state government's
current program architecture and the evolving, newly-developed federal standards¹.

Once the planning project - the enterprise-architecture transformation - had run its course the state government
re-engaged the same consulting team for the next phase. At this point, with just 18 months left until launch
deadline, the clock was ticking even louder.

The original consulting team was now part of a larger consortium responsible for full lifecycle support during
development and deployment. The new deliverables list included:

refining plans and developing detailed business and software specifications for:

the entire business model

staffing

systems

(and ensuring that all these specifications complied with federal standards);

assisting with a process to ensure any new systems developed for the exchange were
aligned with policies and business practices already in place elsewhere within the state
government;

providing Quality Assurance/Oversight while monitoring the development and implementation
of IT infrastructure for the exchange;

developing a reporting infrastructure capable of meeting the needs of all exchange stakeholders - including
consumer groups, insurance carriers and the federal government;

managing the entire User Acceptance Testing (UAT) process:

defining UAT scenarios and creating detailed scripts for those scenarios;

planning all UAT activities;

providing oversight for all testing;

reporting on defects encountered during testing (including an informed assessment of severity).

The contrast between the relative success in this case study and the troubled launches at many of the other
exchanges begs a question: can the consultants identify specific factors that enabled this state to build a
system that largely succeeded in meeting its business requirements - or did the project just get lucky?

A survey of project-team leaders attributes their success to four main factors: a clearly defined method, a reusable
framework, highly capable modeling software and "a client team that was smart, flexible and realistic."

The most important element in their success was the consulting team's re-usable pre-built framework. They
arrived at the project doorstep with their own proprietary open-standards reference model already built. This
model - built with Sparx Enterprise Architect modelling software - was calibrated specifically for creating health
insurance exchanges under the American Affordable Care Act.

As one of the lead consultants said to Sparx "Our re-usable framework and model enabled us to hit the ground
running in a situation where circumstances provided very little tolerance (and no time) for error."

The consulting team's health insurance exchange framework and model was developed back at their national office
by a unit specializing in enterprise architecture for the health care sector.

Practice leaders at the consulting firm had anticipated a market where American states were creating health insurance
exchanges, and developed the reference model as a strategic instrument for getting ahead of the emerging
need: "We wanted to be able to arrive at the client's with a mature, robust, good-fit framework already in
place."

The framework consolidates and incorporates relevant specifications and standards from several existing federalgovernment
sources, including:

the Federal Health Insurance Guidelines and Reference Models from the Centers for
Medicare and Medicaid Services (CMS);

all the Guidelines and References set out in the Medicaid Information and Technology
Architecture (MITA) standards.

Arriving with a calibrated reference framework already in place provided several benefits. Not only did it give the
planning and development team a running start - it also mandated a culture of best practices based on model-driven
frameworks. In a note to Sparx, one of the lead consultants said:

Architectural modelling imposes a structured methodology on the planning and
development process. It constantly forces the team to align architectural design and
resource allocation to the underlying business requirements. It keeps everyone on
the path.

The planning team used the pre-built reference framework and model as a starting point - as an initial platform
for the project. With the model in place they worked with senior health officials from the state to identify all the
key business requirements and all the key systems requirements for the new exchange.

With these requirements in hand (and stored within the model in a project repository) the team then designed
the higher-level integrated business processes for the new exchange. All this new design work was also captured
in the project repository and integrated into the evolving model of the exchange.

At the same time the team also worked with the project's designated Systems Integrator, who was charged with
designing the detailed systems functions for the new exchange. As with the business processes, this output was
captured in the model and stored in the shared project repository.

The business requirements and use-case stories were all written using Sparx Enterprise Architect - the same
software environment that was used to create the original, pre-built reference framework. The Sparx software
actually served the project in a variety of ways. The development team also used it to manage the shared repository
that held all project-related information: the framework, the model, the documentation and all the related
artifacts.

Sparx Enterprise Architect software also provided individual team members with access to the repository directly
from their computer desktops. Any changes to the model or to documentation made during this desktop access
is traced and tracked automatically on the fly.

As an aside, when the consulting firm first discovered Sparx Enterprise Architect they used it strictly as an inhouse
tool. They chose Sparx only after vigorous due diligence examined all the competing software in the sector.
As staff and partners became more familiar with Enterprise Architect, the software earned its way into clientbased
projects (like health-insurance exchanges) where it supported the team through the entire life cycle - from
business architecture to business requirements to software development.

Today the consulting team uses repositories created with Sparx Enterprise Architect for all its architecture modelling
requirements: business, application, information and technology.

Affordability and licence flexibility also influenced the decision to choose Sparx. During the health-insurance
project the consultants equipped 25 team members with the Sparx software, using "floating licences" that moved
from person to person as needs (and personnel) changed over the life of the project.

Enterprise Architect's strong tracking features were increasingly useful as the team grew in size, models of the
exchange became more complex, and multi-tasking acquired more threads. Although team-members from the
consulting firm were already familiar with Sparx Enterprise Architect from its increasing use within their home
practice, the tool was new to project team members from outside the firm - personnel from the state government
and from other contractors.

The newcomers needed to be brought up to speed, and the consulting team brought in Sparx Global Partner
Ramsay Millar to take the lead on this aspect of project readiness. Millar's mandate was to get the entire team
utilising the Sparx software with a common approach and a common mindset.

He accomplished this with a series of extended on-site team workshops: "I worked hands-on to bring the entire
project team up to speed on the latest, best-practice techniques within the Sparx environment," said Millar

The consultants selected Millar - a Practice Leader at consulting firm integrate iT - because of his strong background
working with development teams on project readiness and his extensive experience using Sparx Enterprise
Architect for business modelling, software engineering and TOGAF. (TOGAF - an acronym for The Open
Group Architecture Framework - is a standardized approach for managing enterprise-architecture transformation
planning and implementation; and for governing an enterprise architecture capability.)

Prior to delivering his first workshop Millar worked closely with the lead consultants and customized his standard
syllabus and aligned it with the specific details of this project. "People learn methodology better if they're using
their own content," said Millar. (He later delivered this modified syllabus to teams working on similar projects
elsewhere in the United States.)

Once everyone had mastered a common notation, common methods of architecture, common roadmaps and
common ways to use a shared project repository, the team turned its focus to Business Requirements Definition
(BRD). Following guidelines set down by the state and the federal governments, they used Sparx Enterprise Architect
software to organize the BRD into four distinct value streams:

insurance issuers

individuals and families

employers and employees

health-exchange management

Within each of these streams the consultants defined the detailed business processes, organizational roles,
responsibilities and accountabilities required to support all the client-centric interactions necessary for a fullyfunctioning
health insurance exchange.

It is not unusual for IT projects as complex as this one to respond to tight deadlines by multi-tracking several
worker streams. This kind of multi-tracking must be well managed, or it will cost more time than it saves when
the streams are eventually stitched together ¬and managers discover unintended consequences.

The Sparx Enterprise Architect software enabled the consulting team to manage multi-stream BRD development
without delays caused by surprises ¬- while still maintaining best practice levels of quality assurance. Work-inprogress
from all four streams was stored in the shared project repository, and the merged BRDs were integrated
into a master model. Every team member had instant access to all the stored changes in real time.

Using a tool that supported this degree of iteration management, collaboration and integration allowed project
sub-teams to work on all four streams simultaneously without having to trade-off quality or risk losing track of details.
Ramsay Millar - the outside consultant who helped the main consulting team with project readiness - said
Sparx' software has a "powerful" capacity to track changes and to trace individual team members to the work
they delivered.

"In a project that combined tight deadlines, complex modelling and extensive multi-tasking," said Millar. "The
traceability, re-usability and change-tracking provided by Sparx were essential factors in being launch-ready when
launch day finally arrived."

The consulting team's methodology and tools also enabled project managers to engage in end-to-end testing -
another key component helping the team meet the launch deadline. Once again the Sparx Enterprise Architect
software - and the consulting team's familiarity with the tool - provided the project with critical capacity.

After the Sparx software had been used to create a model of the exchange and store that model in a repository,
it was then used to manage testing of the model and confirm it worked as intended - or to identify bugs and spot
areas where there was room for improvement.

Looking Back

The health-insurance exchange project avoided the kind of catastrophic launch-day seen at many of the other
exchanges across the United States because:

the development team was able to tap into the reusable knowledge stored in the prebuilt
health insurance exchange framework and reuse the model;

modelling in Sparx Enterprise Architect is robust enough to accommodate a complex ecosystem of live data
links between the state-exchange, the policy holder's account, several federal databases and several
distinct insurance vendors;

the tools included in Sparx Enterprise Architect software supported a disciplined approach based on a
shared, testable model of the project;

the shared reusable model and Sparx Enterprise Architect software enabled the consultants to accelerate
development of the exchange, and this created the breathing room necessary for thorough testing and quality
control;

the client's management team rose to the challenge with flexibility and a realistic sense of practical
limitations.

There are always lessons learned in a project of this scope, and the consulting team does have a list of
things they will do differently next time. However, the list is largely focussed on tactical and logistical
details. The core strategy - their basic approach to the project - did work as expected and did work well: this
exchange, after all, was one of a small handful across the United States that actually met its business
requirements from the very first day.

Project-readiness consultant Ramsay Millar has his own perspective on the success factors in this project.
"Every project develops its own culture," he said. "In this project the culture was framed by
placing high value on constantly aligning the technology to the business models and the business requirements.
This became a strong practice within the team."

Millar said this emphasis on alignment was reinforced by leadership, methodology and tools. "The senior
people at the client's project office and the principal consultants 'got it,' he said. "TOGAF
best practices provided the methodology and Sparx Enterprise Architect provided the key tool.

"Success didn't come to this project 'by chance,' " said Millar. "The project
succeeded because it was well managed and well-equipped."

The whole point of a case study is to learn from the work of others. Those closest to this project learned
that, if called to take on a similar challenge again, they would still arrive on day one with a robust
open-standards reference framework and re-usable model already in place, they would still use Sparx Systems'
Enterprise Architect software and the methods supported by that software (especially TOGAF), and they would still
make sure everyone on the project team is trained on these core methodologies and core tools very early in the
process.

EDITOR
David Reilley and Sparx Systems

¹:By this point in the process the American federal government's Centers for Medicare and Medicaid Services had
already developed a recommended Exchange Reference Architecture.