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;
• shop/compare options for personal health care insurance policies offered on the exchange by participating insurance-industry vendors;
• 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.