Strategies and Priorities for Information Technology at the Centers for Medicare and Medicaid Services (2012)

3

A Meta-Methodology for the Modernization and Transformation of Business and Information Ecosystems

This chapter offers a meta-methodology for modernizing and transforming the business and information systems of the Centers for Medicare and Medicaid Services (CMS). This abstract (meta-level) discussion concerns conceptual models of the business roles and processes under consideration. The approach described is simultaneously comprehensive and incremental, combining top-down guidance for establishing global context with bottom-up specificity regarding what is transitioned and how.¹ This is distinct from a “big bang” approach that would attempt to transition everything at once—as Chapter 2 indicates, such an approach would be unlikely to succeed. The committee’s exhortation is that individual modernization or transformation efforts move forward within an understood comprehensive context, as opposed to piecemeal or program-by-program as has traditionally been done.

CMS’s Office of Information Services (OIS) either has developed or is currently developing many components of the plan outlined in this chapter, including its shared services plan,² an enterprise data environment

¹ The committee is aware that a more concrete and tactical approach than what is described here is desirable. Indeed, during its input gathering the committee had several discussions with CMS about the question of specificity and tactics. Given the nature of the study and limited time and resources, the committee ultimately decided that a meta-methodology was as tactical an approach as it could offer.

² CMS, 2011, CMS 18-Month Plan for Enterprise & Shared Services, Baltimore, Md.: CMS, July 7.

(EDE),³ and OIS-wide architectural and life-cycle guidelines,⁴ among others. The approach described here combines and generalizes activities already underway in OIS and provides a meta-methodology to guide future efforts toward modernization and transformation. The proposed meta-methodology should be viewed as augmenting CMS’s alreadyexisting plans for modernization with a larger context and confirming some of the actions and principles of which the committee was made aware by the CMS Office of Information Services during the course of this study (see Appendix B for a list of committee meetings and briefers).

The methodology has two goals: first, it provides these components with a context that includes the full scope of CMS; second, and more importantly, it links the information technology (IT) components with the corresponding elements at the business level to create a context within which the relevant multidisciplinary teams can collaboratively plan and execute the CMS-wide modernization or transformation of all CMS systems. Thus, a specific contribution of this proposed method is the combination of an ecosystems perspective in concert with clearly articulated interactions and interrelationships between the business side and information technology.

The meta-methodology described here is a generalization (and perhaps, formalization) of that described by OIS itself. In its 18-month plan for enterprise and shared services,⁵ CMS lays out the need to formalize and define services that can be shared across its various businesses, suggesting a useful list of such services, including master data management, portals, and identity management. The plan also suggests a governance model that spans the business and information technology organizations. The committee applauds this direction in CMS, and nothing here is meant to contradict the intent of this plan.

The meta-methodology that the committee proposes is necessarily abstract. A specific method—that is, one specific to CMS systems— requires an extremely detailed understanding of those systems. The committee had neither the resources nor the charter to acquire that depth of understanding of CMS systems. Detailed knowledge of CMS systems is only a part of the picture, however. As the outline of the meta-methodology below reveals, an end-to-end plan requires a comprehensive knowledge not just of the CMS systems but also of the business and information

³ CMS, 2010, Modernizing CMS Computer and Data Systems to Support Improvements in Care Delivery, Version 1, IT Modernization Program, December 23, available at http://www.cms.gov/InfoTechGenInfo/downloads/CMSSection10330Plan.pdf, last accessed July 27, 2011.

⁴ See CMS, 2011, Technical Reference Architecture (TRA) Standards, available at http://www.cms.gov/SystemLifecycleFramework/TRAS/list.asp, last accessed July 27, 2011.

⁵ CMS, 2011, CMS 18-Month Plan for Enterprise & Shared Services, Baltimore, Md.: CMS, July 7.

ecosystems of which they are a part. An undertaking of this scope and scale must be addressed incrementally, over a period of 10 to 15 years. The committee’s view is that CMS is moving forward appropriately, given the constraints under which it must proceed.

For purposes of consistency and clarity of definition the committee uses its own terminology in this report. (The glossary in Appendix F defines important terms.) CMS may have its own terms for the concepts used and defined here. The first section below describes a conceptual model and language used to describe the meta-methodology.⁶ The second outlines the approach, which has two phases: Phase 1 focuses on the modernization and transformation of the business ecosystems, and Phase 2 addresses the modernization and transformation of the information ecosystems. Both phases are detailed further in Appendix E. Finally, the third section describes the preparations necessary for the transformation to succeed.

MODEL AND TERMINOLOGY

A major business is a complex affair. Businesses typically perform a number of business roles, each with its own objectives and requirements. For example, one of CMS’s roles is to pay claims; its objective for that role is to pay all legitimate claims (and to avoid paying any that are fraudulent), and it is required to do so within a certain period of time. To meet its objectives, the business role follows a set of business processes and leverages a set of business services. Business service is a business organization concept; it does not refer to any specific implementation—automated or non-automated. In CMS’s role as claims’ payer, for example, it must generate a check (a business service). Business services may be shared across multiple business roles. For example, the check-generation service might also be used in conducting a procurement role of buying office supplies from vendors. If the services are shared, they are referred to here as shared business services. (In its enterprise and shared services plan,⁷ CMS refers to such business services, shared CMS-wide, as enterprise services.)

In this report, a business ecosystem consists of the people, processes, services, and information required to operate all aspects of a specific busi-

⁶ The terminology selected for use in this report is not unique; CMS should adopt the terms with which it is most comfortable, taking into account relevant U.S. federal guidance and standards.

⁷ CMS, 2011, CMS 18-Month Plan for Enterprise & Shared Services, Baltimore, Md.: CMS, July 7.

ness role that is independent of other business roles.⁸ An ecosystem for a given role can be seen in various ways, including as an operational model and as a business model for that role. A complex organization such as CMS will involve many roles and hence many business ecosystems. These may not all be internal to CMS—that is, CMS business ecosystems also interact with external business ecosystems. For example, the claims payment business ecosystem must interact with the Social Security Administration (an external business ecosystem) concerning eligibility. The union of all of the business ecosystems bearing on the business is referred to here as the global business ecosystem.

A design objective for business ecosystems in an enterprise is to achieve as much reuse of common services among ecosystems as possible, taking into account considerations such as cost, governance, and architecture. Reuse typically increases efficiency and reduces costs. People, processes, services, and information can be shared across ecosystems. Ecosystems continuously evolve, reflecting and corresponding to the continuous evolution of the business roles that they characterize.

Because the modernization and transformation of a global information ecosystem constitute an enormously complex task, it is critical to begin by adopting standards and conventions that foster a common understanding of the various architectures, systems, and services being modeled. As described in Chapter 2, an enterprise architecture (EA) framework sets the standards for structure, properties, and behavior to which each layer of the architecture should adhere. As an example, one piece of the EA framework would be information architecture standards. See Box 3.1 for a description of the several architectural layers that must be taken into account. CMS has identified the need for such standards in its plans, for instance, the enterprise data environment. It correctly identifies the Enterprise Data Environment (EDE) as central and critical to the future of CMS.

CMS has business and information ecosystems in place, such as the medical beneficiary membership systems, the Medicare claims and utilization data systems, the Medicare pricing systems, and many others. CMS refers to these as CMS systems families, by which the committee assumes that CMS means several information systems used to accomplish what

⁸ Independence of business roles is not meant to imply that there must be a complete lack of sharing of resources or services. Systems implementing separate business roles can and likely should share lower-level services. A purpose of independence at the business level is to distinguish roles. Sharing of services occurs at a different level—that of implementation. For example, human resources functions and payroll activities can serve all organizations within an enterprise, even if the system dealing with sales, for example, is compensated under rules completely different from those that govern the IT system; payment in both is made using the same shared services—people, systems, and other resources, for example, for issuing checks.

in this report is called a business role. The committee did not observe a concept in CMS analogous to what this report calls a business ecosystem, and it suggests that CMS begin approaching modernization and transformation within this broader context.

This report refers to existing constructs as sources: for example, source information ecosystems. It refers to desired constructs as targets: for example, target business ecosystems. Such targets could be the result of modernizing or transforming one or more sources, or they could result from new requirements. If CMS wants a new business service that combines the functions of two existing business services, the new target business service will be created from those two source services. Once a target is envisioned, how the target transitions to or is derived from one or more sources is specified in a process known as mapping. Mapping, like the

terms “source” and “target,” can apply to any construct defined above. Mappings can relate multiple sources to multiple targets, for example, to represent the need to combine parts of several source ecosystems into a single target ecosystem or to show that multiple targets are derived from or consolidated to produce a single source.

OVERVIEW OF THE META-METHODOLOGY

The meta-methodology recommended by the committe for transitioning—modernizing or transforming—CMS systems consists of two phases. Phase 1 establishes a plan for the business ecosystems, in the process defining the business requirements. Phase 2, guided by the plan for the business ecosystems, creates a plan for the information ecosystems. Both phases follow the same pattern: understand the source ecosystems of interest and how they interrelate, choose a starting point, understand the relevant target ecosystems, and develop a mapping between the source and the target ecosystems. The plan for the business ecosystems guides the plan for the information ecosystems, which is also guided by relevant standards for the global information ecosystem (GIE) and the EA framework.⁹ An objective of this proposed meta-methodology is to achieve agility in modifying plans and designs as required by constant and unanticipated changes.

In brief, the meta-methodology proceeds as follows:

• Phase 1 is for understanding and planning the modernization or transformation of business ecosystems. It consists of three tasks:

—The first task is to identify and characterize the source business ecosystems of interest and to create a model of the full source global business ecosystem (GBE).

—The second task is to design a set of target business ecosystems and a target global business ecosystem, paying particular attention to opportunities to consolidate and redesign business roles and processes by identifying commonalities and potential shared services.

—The third task is to develop a transition plan that will map roles and processes of the source GBE to the target GBE.

⁹ A simple example of a plan is one in which one source ecosystem is transformed to a target ecosystem to accommodate new requirements, such as new legislation or regulations. In this case, the target global business ecosystem (GBE) is identical to the source GBE with the exception of the ecosystem to be transformed. The plan delineates the mapping of the source ecosystem within the source GBE to the target in the target GBE. In other words, the target ecosystem is almost never a completely “blank piece of paper”; instead, in the proposed incremental method, only the ecosystem being transformed changes.

• Phase 2 is for transitioning—modernizing or transforming—the corresponding information ecosystems. This phase starts by drawing on the standards as needed to guide the mapping and then follows the same sequence (source, target, and mapping) as in Phase 1, guided by the decisions made there and by the relevant standards. Then, the IT systems must be modernized or transformed. This phase therefore has five tasks:

—The first task is to develop or enhance, as needed, already established standards to guide the design of any common components of the target GIE, including an EA framework.

—The second task is to identify and characterize the source information ecosystems that are relevant to the business ecosystems identified in Phase 1, and to model the source GIE that implements that GBE (if that was not done in a previous incremental step).

—The third task is to characterize the desired target information ecosystems to support the target GBE.

—The fourth task is to develop mappings between the source and the target information ecosystems, creating a plan that can be sequenced so that individual technical transitions can be conducted one at a time.

—The fifth task is as follows: For each transition identified in the fourth task, plan a technical process that follows its own sequence: a process that (1) creates a development version of the newly envisioned technical ecosystem, (2) tests and evaluates this version against requirements and against relevant changes, and (3) moves this information ecosystem to production once the requirements are satisfied, replacing the source information ecosystem.

At the end of each such rollout, the incrementally updated target becomes the source for the inevitable subsequent transitions to face CMS. This is true at the levels of both the business ecosystems and the information ecosystems. That is, this process will repeat indefinitely in an iterative fashion as each individual modernization or transformation task is accomplished. Activities in Phase 1 and Phase 2 will be taking place simultaneously, since efforts toward one transition will inevitably need to begin before an earlier transition is completed. The source and target information ecosystems will be in a state of constant change that will have to be accounted for at each stage of the iteration. The committee proposes this methodology as a new life-cycle methodology for CMS.¹⁰

¹⁰ Although the committee’s recommended approach is presented abstractly, it embeds the notions of iteration and incrementalism, which are well studied in the literature regarding software-intensive systems. See, for example: Craig Larman and Victor R. Basili, 2003, “Iterative and Incremental Development: A Brief History,” IEEE Computer 36(6):47-56; Barry W. Boehm, 1985, “A Spiral Model of Software Development and Enhancement,” Proceedings of the International Workshop on Software Processes and Software Environments, New York: ACM

An immediately recognizable iteration scenario is one in which a key stakeholder (e.g., Congress) creates a new business requirement (e.g., a new program), or changes an existing role (e.g., making changes to rules about CMS operations). Completing such an iteration will require changing existing processes and/or creating new ones. An appropriately comprehensive view might suggest that existing components, software, and/or hardware could be reused or modified to support the new requirements or roles. Alternatively, the new requirements or roles might suggest the need for broadening the global view, requiring the addition of lowerlevel capabilities. This should be done with a view toward making them suitable for use in satisfying further requirements that might be expected to emerge.

The transition from the use of the of the International Statistical Classification of Diseases and Related Health Problems, 9th Revision (ICD-9) to the use of ICD-10 might be an example of such a requirement—and indeed is illustrative of the challenges facing CMS that are described throughout this report (see Box 3.1). First, this transition is an example of a very pervasive set of application and data changes that traverse a wide range of systems within the agency. Second, this transition will occur at the same time that many other changes (such as the certification and implementation/ disbursement of financial incentives for the meaningful use of electronic health records technology) take place, illustrating the increase in the pace of change confronting CMS. Third, it is one more example of the shift taking place as CMS moves toward being a data-centric organization (discussed further in Chapter 5). An even more transformative example would be the new role of CMS in managing the insurance exchanges—the collection of state-regulated, standardized health care plans, from which eligible individuals may purchase federally subsidized health insurance. Whereas the transition to ICD-10 is crosscutting, it is, at root, an update to existing functionality. By contrast, management of the insurance exchanges will demand entirely new functionality (and correspondingly new data and information). Each of these challenges can be addressed within the proposed methodology.

Or, imagine a comparatively simple case in which the target CMS global business ecosystem is known to require one CMS role, that of beneficiary registration, whose business requirements are partially known. The context for this case should include the beneficiary registration role characterized by all known and anticipated details. In addition, there would be an abstract target role for each source CMS role. Modernization

Press; F.P. Brooks, Jr., 1987, ”No Silver Bullet—Essence and Accidents of Software Engineering,” IEEE Computer 20(4):10-19; and, recently, NRC, 2010, Critical Code: Software Producibility for Defense, Washington, D.C.: The National Academies Press.

and transformation activities related to the beneficiary registration role would proceed by mapping source to target roles in terms of the component services. This activity may identify services or resources that might be shared by one or more of the abstract roles—for example, security and registry services. Opportunities identified during this initial activity may be confirmed by subsequent incremental activities in which details emerge.

Not all iterations through this process of modernization or transformation will be undertaken in response to changes in higher-level layers. An iteration might instead be aimed at modernization at a lower layer, such as the hardware layer or a well-contained application layer. One example of this sort of transition is the replacement by CMS of a large number of accounting and ledger systems with a modern commercial, off-the-shelf integrated general ledger: the Health Care Integrated General Ledger Accounting System (HIGLAS). These sorts of modernization iterations might result in a marked improvement in performance that is noticeable to key stakeholders. Subsequently, stakeholders’ realization of the possibility of an expedited response to their needs might encourage them to change the roles that they would like to play or indeed to expand their business requirements to include capabilities previously thought to be unrealistic or unachievable.

CMS’s iterative modernization and transformation activities should be approached comprehensively in the most global context, but with the recognition that the fifth task listed above is the crucial implementation step at the appropriate level of abstraction, where the transitions take place. Each CMS modernization or transformation activity should identify its most global context and initiate the design of that activity within that context. Representatives of the relevant business roles and functions, as well as those with relevant technical specializations, should be involved in the process. (See Chapter 4 for more on organizational aspects of modernization and transformation.) To the extent that the components of that context can be identified, those components should be part of the design. To the extent that details of those components are known, they should be included in the characterization of that component. If a component is anticipated but few details are known, the component should be identified as part of the context and characterized in terms of those aspects that are known or anticipated. In some cases a component may be anticipated, but little may be known of its details. Most aspects of business ecosystems and information ecosystems can be expected to evolve over time, emphasizing the importance of being sure to consider all phases of the life cycle of a business ecosystem or information ecosystem incrementally.

A significant number of source and target business ecosystems are encompassed within the scope of the CMS modernization and transfor-

mation activity. It is feasible to carry out a complete analysis and mapping from sources to targets only as an incremental activity over a period of approximately 5 to 10 years.¹¹ Hence, business system analysis and mapping should be conducted opportunistically to meet business priorities, allowing activities in Phase 2 to begin as quickly as possible for the given task of interest. For example, if fee for service is the most urgent business ecosystem to transition, the mapping should focus on the relevant source and target business ecosystems, taking into consideration as many global aspects as are known. Subsequent incremental mappings will focus on the relevant source and target business ecosystems as well as on those business system mappings that already exist. The global CMS ecosystem at any point in time consists of all of the individual ecosystems. When transitioning any one ecosystem, the target global ecosystem is identical to the source global ecosystem except for the one being transitioned.

Appendix E offers an elaboration of the steps in Phase 1 and in Phase 2 and includes a discussion of information strategy and the CMS enterprise data environment.

PREPARING FOR INEVITABLE TRANSFORMATIONS

Owing to the continuous evolution of methods and technologies in business and information technology, those communities have been in a period of continuous change for decades. In 2011, business and IT are not just changing but are being continuously transformed through the development of methods and technologies that are usually significantly more efficient and flexible than their predecessors were. Efficiency and flexibility distinguish those methods and technologies that not only will succeed but also are inevitable. In 2011, in the committee’s view, there are several inevitable business and IT transformations, or revolutions, underway, each at a different level of maturity and with its own momentum. These are in addition to changes taking place in the health care and health IT communities with which CMS must engage.

Taking advantage of or accommodating any one such transformation to gain the benefits that it will provide poses significant challenges. Moving from the current or source state to the transitioned or target state involves the following: developing a model and reasonably robust methods and technologies for the target state, demonstrating that the target methods and technologies will fully meet the target requirements, planning and executing the migration from the source to the target state, and

¹¹ CMS, 2010, Modernizing CMS Computer and Data Systems to Support Improvements in Care Delivery, Version 1, IT Modernization Program, December 23, available at http://www.cms.gov/InfoTechGenInfo/downloads/CMSSection10330Plan.pdf, last accessed July 27, 2011.

accommodating the cost, schedule, and procedural impact of the migration. Each impact factor must be considered at the scale of the source and target environments. The complexity of these considerations has often prevented large organizations such as CMS from launching transformative efforts, leaving the source or legacy environment in place and thus missing an opportunity to reduce long-term costs and increase flexibility. Over time, the cost of not taking advantage of those opportunities is an unsustainable legacy ecosystem characterized by legacy or uncompetitive costs and inflexible processes, resources, organizational structures, and information ecosystems.

This chapter urges incremental transformation to a global ecosystem environment in which business and IT cooperate to ensure that business requirements drive IT solutions and vice versa. CMS’s OIS has already taken significant steps in this direction. Expanding those steps to be CMSwide and enhancing the business-IT partnership while doing so will be important. The target global ecosystem should be developed incrementally based on well-defined requirements, a migration that the meta-methodology offered here can contribute to planning. This transformation, already underway at CMS, is inevitable and necessary.

CMS should focus on the transformation to a global ecosystem environment in order to be prepared to take advantage of and to accommodate other revolutions currently underway in the broader IT industry, such as service orientation, cloud computing, and Enterprise 2.0 (i.e., the use of social networking, collaborative spaces, and other Web 2.0 technologies to streamline business processes). The transformation to service-oriented business operations and service-oriented computing has been underway since the early 2000s. While some industry leaders have established best practices, the business practices and supporting technologies are maturing. Although OIS is on that path as well, as evidenced by its 18-month plan for enterprise and shared services, the transformation is a long-term project. It involves reformulating both business and IT, as well as significant implementation involving reorganizing the business and re-architecting the information ecosystems.

The transformation to cloud computing is compelling and is a federal strategic direction. However, in the committee’s view, despite the fact that industrial practice has succeeded in achieving significant benefits through server virtualization and for small and green-field applications, the movement of existing applications to “the cloud” is not yet mature and should be deployed only on the basis of solid evidence that the target requirements are met within reasonable costs and with appropriate attention to risk assessment and risk tolerance. Careful analysis is also needed regarding the costs and benefits not only of degrees of virtualization but also of private (in this case, agency-managed) versus public (third-

party-managed) cloud services. Additionally, in the committee’s view, the inevitable transformation from so-called Enterprise 1.0 to Enterprise 2.0 is just getting started. CMS would benefit significantly from the appropriate and efficient interaction among all of its stakeholders to achieve CMS objectives.

In summary, to take advantage of current and future business and technical advances, CMS should consider the relevant opportunities, such as those described above, and plan prudently to make transformations on the basis of its capacity to do so and using the proposed meta-methodology to manage the iterative process that will be needed.