©2011 Healthcare Information and Management Systems Society (HIMSS).

HIMSS Enterprise Architecture (EA) Frequently Asked Questions

What is Enterprise Architecture? 1. What is EA?

Enterprise Architecture (EA) is a rigorous description of the structure of an enterprise. It can be used as a strategic planning tool and as reference architecture for modeling which is used to develop a master plan that acts as an integrating force between aspects of:

• Business Planning - including goals, visions, strategies and governance principles • Business Operations - including clinical and business terms, organization structures, processes and

data • Automation - including application systems and databases • The Business’s Enabling Technological Infrastructure - including computers, operating systems and

networks. (Stevenson, 2010) It is important to recognize that EA can drive an ongoing process of achieving and optimizing alignment of goals, processes, and enabling technology resources. When leveraged properly within an organization, EA can be used as a communication, coordination, and education tool that can bridge the traditional knowledge gap between information technology (IT) architects and other stakeholders. In many respects, healthcare is unique in the degree and complexity of information, processes, and technologies involving multiple organizations with different technical architectures. In the healthcare setting, EA can promote collaboration across multiple care venues and between hospitals, affiliated physicians, accountable care organizations, regional health information exchanges, and other stakeholders. These extended relationships typically have their own technology components, cultures and standards that must effectively meld with other organizations’ technology, workflow, and governance models to promote seamless service delivery and effective decision-making.

2. What is the current usage and adoption in the health care Industry?

EA has not been widely adopted or pervasively used in the commercial healthcare industry. Those that have adopted so far, such as Denver Health and the Cleveland Clinic, are institutions with dedicated IT resources that have historically led the way in healthcare information technology (HIT) initiatives. EA has a stronger presence within the federal healthcare system at Veterans Affairs (VA), Veterans Health Administration (VHA) and within the US Department of Defense (DOD). New technologies and government incentives are encouraging organizations to look at the entire healthcare ecosystem, analyzing data and process interactions with other organizations and government entities towards a common goal of usable interoperable electronic health records (EHRs). These initiatives have prompted a review of HIT data streams and processes, and have encouraged a renewed interest in Enterprise Architecture.

2

3. I have a multiple heterogeneous and legacy systems. Is it too late to implement EA? No, it is not too late to implement EA even with multiple and mature systems. Very few organizations have the luxury of starting with a clean slate. It is much more common for organizations to have a wide variety of existing investments in health IT systems. These investments have often been made over the span of many years and include offerings from many different software and hardware vendors. At its foundation, EA is an agent for change, and provides an approach and outcome to enable you to better understand what you have today, what you need for tomorrow, and how to get there. Using EA to help document the “As-Is” state of your organization (systems, processes, and core functions) is the first step, which is essential to understanding where your strategic investments should be made and the dependencies among them to allow you to plan and invest wisely.

4. Is my organization too small for EA? To what size organization can EA apply? Any business that manages information that executes strategies and must comply with government regulations is a good candidate for EA. While EA scope and focus varies greatly depending on company size, understanding the value each element contributes to the business better enables investment decisions that can help target limited resources, especially important in smaller organizations. It is appropriate and prudent to scale EA to align with the size, complexity, and maturity of the organization.

5. How does EA relate to health information technology? HIT has the potential to improve coordination by making information electronically available at the point of care, especially if it is widely implemented as proposed in HIT provisions of the American Recovery and Reinvestment Act of 2009 (ARRA). EA is the overarching framework linking HIT systems and enabling them to coalesce, communicate, and perform. The HITECH Act aims to create a strategic plan for implementing a nationwide interoperable health information system. The new funding for electronic medical record (EMR) adoption, and the ongoing work with standards for data exchange, requires an EA plan to fully support the coordination of care. The information management of referrals, consultations, care transitions, and emergency care are dependent on the dimensions of a robust EA, such as interoperable systems, standards, interfaces, physical technology (hardware), connectivity (network, EDI, HIE), data center, services, workflow, governance, security, and others.

6. How does EA fit into my current processes? EA can be defined as “the structure of components, their relationships, and the principles and guidelines governing their design and evolution over time.”(DOD) Establishing an EA is primarily strategic and focused on the holistic direction or evolution of an organization’s IT environment through a solid understanding of the current and desired future state of the business environment. Part of the implementing EA is governance, required to establish the authority and control to drive the business environment toward that future state goal. EA is primarily focused on designing the future state of architecture in support of the organization and business environment. The EA oversees and supports an organization’s IT governance by helping analyze requirements and impacts through a documented understanding of the interrelationships of an enterprise’s functional and technical environments. The framework facilitates improved decision making and acquiring or enhancing IT based on a strategy to provide the technology that supports the organization’s mission and business need rather than the latest advancements. The focus shifts from technology alone to the effect of technology within the organization.

3

EA Business Case and Value 7. Why does my organization need EA if I am going to buy a vendor-supported or off-the-shelf product?

The use of commercial offerings (COTS, SAAS, Cloud computing, vendor supported software, etc.) is a viable option to those with limited programming resources. Using EA is one way in which these strategies can be visually implemented and help determine if you have leveraged these options to optimize them towards your strategy, objectives, and goals. EA allows you to see where systems overlap and have gaps, where data is sent and received, and where systems dependencies. This can be critical in situations where many vendors or a multitude of software is used. EA can identify ownership of data services, and can be used as a tool for communicating ownership. It will allow you to see a road map of IT process flows in and out of your control, and allow for better governance of the data. It is the data originator’s responsibility to control access to the data. You are also responsible to know how vendor-supported programs are handling, transmitting, and retaining your data, including how your employees are interacting with it. Inusing EA you can also ensure that your vendor or commercial off-the-shelf (COTS) software is delivering on expectations which align with your strategic goals. Specific IT requirements to achieve short- and long-term strategic goals must be stated in contract agreements. Modifications made to COTS to enable successful implementation may be required. Ensuring the software uses the same verbiage that your employees are used to is essential. Implementation of EA will expose not only verbiage and usage variations but may also expose duplication, unneeded processes, or processes not previously considered.

8. How can EA support healthcare transformation (Meaningful Use objectives, ARRA, ACO, HITEC, etc.)? The healthcare transformation goals of increased efficiency, access and quality care along with decreased costs require the broad adoption of EHRs and HIT. To achieve these goals, the federal government, through ARRA, is offering eligible providers incentives to adopt certified EHRs and use them in a meaning way. This accelerated implementation of EHRs will have a dramatic impact on data management. Many different technologies and databases are used to obtain, store, and analyze healthcare data. The healthcare industry must embrace new and innovative approaches in examining, understanding and using the data flowing in, out and stored within HIT and EHRs to successfully transform the US healthcare industry and meet reform goals. EA can provide a healthcare delivery system, health information exchange (HIE), and/or community with a framework for data and business process mapping. This mapping may include identifying key data collection points and the ‘true source’ of data, avoiding duplication of collection efforts and data interfaces, as well as identifying standardized data for business processes, which are all key to reporting quality measures and capturing true care costs necessary for value-based purchasing decisions. Additionally, EA may assist with plans to share data between entities of a community or an accountable care organization in various locations, providing an understanding of where the data resides and how best to efficiently and securely share the data. EA tools which map data, processes, interfaces and system intersections will allow enterprises to view their data at granular and broad spectrum levels, facilitating important decisions on IT purchases, IT implementation plans, business intelligence, and care coordination.

9. What value does an EA bring to my organization? What are the benefits of EA?

EA provides your organization with a logical framework for business processes and IT infrastructure. The EA can provide a long-term view of the company’s processes, systems, and technologies so that individual

4

projects can build capabilities, not just fulfill immediate needs. EA aides in business process integration and standardization. An effective EA is one that identifies the processes, data, technologies, and customer interfaces that will take your operating model from vision to reality. Enterprise architecture provides an instrument to make informed decisions and ensure organizational and user compliance with the transformations required of these decisions. EA serves to create a shared understanding of the existing situation, conceptualization of future directions, gap and overlap analysis, tactical planning, operational planning, and solution architecture. EA facilitates consistency of communication, assists in meeting regulatory requirements, improves business agility, decreases IT bottlenecks, reduces duplication of efforts, and increases access to critical information. To deliver and improve care, it is very important that there is consistency in clinical data. Historically, much of the data has been captured in unstructured formats (text, voice/dictation, image, etc.), but the industry is moving toward structured data with standardized coding and terminology. EA can ensure that the data structures and taxonomies adopted throughout your organization are in harmony internally and compatible externally with business partners, regulators, and payers. A helpful analogy may be to think of the architecture as if you are constructing a building. The blueprint process begins with a vision and requirements of what you want to accomplish (e.g., create a house where you can entertain, raise a family, work at home, etc.) This drives the conceptual design and then the various dimensions of detailed design (e.g., layout, plumbing, electrical, flow, etc.). Healthcare delivery is an extremely complex system, requiring precise timing, accurate information, excellent communication, and reliable protection of privacy. Just as you would not construct a hospital building without detailed architectural plans, it is imprudent to construct a complex information sharing system without equally detailed plans. The benefits of an EA will include improved efficiency, effectiveness, and safety for you, your patients, and all your organization's stakeholders.

10. How will EA reduce costs and increase efficiency? EA serves as a framework to align an organization's strategic business objectives to IT: that is, from business process to technical infrastructure. One of the goals of an effective EA is to promote technical standardization, reuse of existing IT assets, sharing of common processes and workflows, and optimization of the IT service portfolio. EA’s ability to identify unplanned redundancy results in a decrease in master file maintenance, interfaces, reconciliation, and duplicative business efforts, thereby providing organizations with cost savings opportunities. EA grants visibility into those aspects of business processes and technology infrastructure that are inefficient, duplicative, and/or misaligned.

Getting Started with EA 11. How do I get started?

The first step in getting started with EA in a healthcare setting is to understand the forces driving the organization to implement EA. Understanding current, near-term and longer-term end goals is necessary to measure the level of success in implementing EA. It is also important to know or establish an overall business strategy for the organization. These two pieces of information will help garner leadership support for the process and ensure the successful implementation of overarching enterprise architecture. Hiring or identifying an individual or individuals to act as your enterprise architect(s) and defining governance structure for the process are also important initial steps when starting to implement EA. Ownership of the

5

process and executive buy-in and sponsorship are necessary to ensure tasks are carried out through completion and done in compliance with the strategic goals laid out by the EA team. Implementing a formal governance structure for EA enables you to maintain oversight of decisions made during implementation, to gain feedback during the effort, and to provide a venue to monitor compliance after the initial implementation is complete.

12. What are the skills my organization needs to accomplish EA Tasks? Leadership is the fundamental skill necessary for the completion of EA tasks. This process depends on collaboration between technical, IT and business teams to ensure all are working in alignment with the overall organizational strategy. The enterprise architect must be able to effectively lead groups with membership from each specialty through the EA process. This individual must also possess enough knowledge of the engaged business units and IT teams to act as an effective facilitator and leader. Other important roles that are needed for the successful implementation of EA are executive sponsorship, project management, business unit leadership, IT leadership, IT subject matter expertise, and business unit subject matter expertise (e.g., clinical, financial, administrative). The ability to fill all of these roles with different individuals is often linked to the size of an organization. Many of the roles can be filled by the same individuals in smaller firms. The enterprise architect can fill the role of project manager depending on the volume and pace of implementation. They may also be able to provide some expertise and/or leadership for the IT component of EA. IT and business unit leadership can often supply the necessary subject matter expertise in smaller organizations with minimal assistance from staff.

13. How do I prepare a business case to get funding to support building my EA?

Establishing funding for EA may be difficult as it is challenging to predict the ROI gained. The key is to package EA in a way that will get it on the organization’s priority list. This can be done through many different methods. Some examples are selling EA on its own based on benefits, packaging it with other initiatives like within IT strategy or systems implementations, funding it through savings from other initiatives or by seeking partial funding for analysis to gain a better understanding of the potential benefits. Using experiences from other similar organizations that have been successful with EA can also be beneficial. Approaches may vary depending on an organization’s decision makers and priorities. It is also helpful to spell out some of the intangible benefits of EA when looking for a funding source. These may include improvement in interoperability between systems, increased agility to respond to changes, improved security, and the reduction of technical risks. Establishing an EA program need not begin with significant budget allocation. Many organizations elect to assign these responsibilities to existing staff, with pre-planning starting with 1 FTE over a year (generally best staffed across two individuals with deep institutional experience and EA experience, or some combination thereof). Note that this level of staffing would not be sufficient to build an EA or capitalize on its benefits, but it would be sufficient to "get your arms around the challenges", identify opportunity areas, and create an investment plan.

EA Execution

14. What are the more recognized frameworks and analytical approaches used to build and analyze an EA? Establishing an EA involves strategy, framework models, methods, techniques, tools, and processes. There are several frameworks and methods available to guide the creation and management of an EA. Organizations can benefit by consulting an enterprise architect or a consulting firm specializing in EA. Decisions involving

6

architecture and changing architecture can become costly as current states are modeled and future states implemented. This decision may depend on not only the maturity of the organization, but the maturity and direction of the strategic goals. It can be very costly to realize the wrong architecture type has been selected once the implementation process has begun. It is essential to focus on aligning strategy with the robustness of the architecture. Some of the more common and established models include:

• Zachman Framework - developed in the 1980s by John Zachman (IBM), this model relies on the classification by descriptive representations of an entire enterprise. The framework consists of a 36-cell matrix that characterizes the environment from different viewpoints. The matrix expresses the environment in terms of enterprise, system, and technology. It identifies the what, how, where, who, when and why viewpoints to characterize the environment. The Zachman Framework is a common, internationally-recognized integrated EA framework. Recently, the Zachman framework has been used by the National Institute of Standards and Technology (NIST).

• Department of Defense Architectural Framework (DoDAF) - The Office of the Secretary of Defense (OSD) established a standard for defense organizations to document their EAs. The DoDAF is well-suited to large, highly interoperable environments. Like other EA frameworks, DoDAF depicts a defense enterprise using various views: all view (AV), operational view (OV), systems view (SV), and technical standards view (TV). The AV addresses the overarching scope and vision, while the OV, SV, and TV add detail to the EA.

• Federal Enterprise Architecture (FEA) - The FEA framework is the model, developed in 2006 by the

federal government, to identify opportunities for simplifying processes and unifying work across agencies and within the lines of business of the federal government. The FEA is being constructed through a collection of five interrelated “reference models” (performance, business, service, data and information, and technology) designed to facilitate cross-agency analysis and the identification of duplicative service domains to support discovery and reuse of those service and component assets. In healthcare, HHS's over-arching central direction is to function as a single entity, as "One HHS," rather than as a collection of disparate and unrelated agencies. HHS is in the process of using EA to document and manage the information assets that support fulfillment of the Department's mission and goals.

• The Open Group Architecture Framework (TOGAF) - developed in 1995, is based on early DOD models.

The TOGAF model uses four views: business, application, data, and technology. It relies heavily on modularization and phased designed called the Architecture Development Method (ADM). TOGAF is more of a framework for designing architecture rather than an architectural model. But it is commonly used as an approach to build the artifacts needed for an architectural framework.

• Integrated Definition Language (IDEF) - developed by the US Air Force, is an early effort (the Wing-

IDEF Project started in 1993) to model and document model business process, data, and other influencers for software development projects. There are 16 methods (IDEF0 - IDEF14) for documenting the range of business or system functions, business processes, drill down information, and the interrelationships.

• Veterans Integrated System Technology Architecture (VISTA) - was developed by the VA for purposes

of serving as an EHR. This architecture is now open source. For information about the open source EHR custodial agent, see http://osehrca.org/

• Reference Information Model (RIM) - is a static model of health and healthcare information as viewed

within the scope of Health Level 7 (HL7) standards development activities. RIM was developed in the Netherlands as part of HL7's ongoing mission of increasing precision of data. The RIM provides a

7

static view of the information needs of HL7 Version 3 standards. It includes class and state-machine diagrams, and is accompanied by use case models, interaction models, data type models, terminology models, and other types of models to provide a complete view of the requirements and design of HL7 standards.

Risks and Challenges of EA 15. What are the risks or challenges associated with an EA program?

Risks associated with EA tend to be more associated with outcomes rather than with the execution of the project. An effective way to consider risk is to compare the risk of doing EA with the risk of not doing EA, where IT systems do not meet business needs and cannot easily work together. The biggest risks generally associated with EA include:

• EA Document Gathers Dust. If governance processes are not put into place and expectations throughout the organization are not effectively managed, the EA may likely never be used. This can be mitigated by having project-level involvement in the activity and clear feedback channels to foster continuous improvement.

• Opportunity Costs. EA is often perceived as “taking money away from ‘real’ projects.” This

perception stems largely from looking at specific point needs and not the overall organizational perspective. This can be mitigated via executive sponsorship and governance follow-through.

• Improper Drivers. EA, done correctly, is a business enabler and helps ensure alignment between business needs and IT investments. When driven from the IT community, constrained by organizational structure, or initiated without proper authority, the EA program sub-optimizes parts of the organization but fails to enable the business. This risk can be mitigated by providing traceability through business drivers and visibility through business community stakeholders.

• Organizational Culture. Even when an EA team is able to produce an excellent document and has the appropriate authority, programs suffer when the organizational adoption approach is faulty or ill-conceived. EA is as much about organizational change management as it is about architecture. Items such as outreach to project teams, receptiveness to feedback, education and training, clearly-documented processes, and published success metrics are all key components to help the organization embrace EA.

EA Follow Through

16. How do we know if we are being successful? An EA can provide reference points for business executives and technology professionals regarding both the current state (“as-is”) and desired future state (“to-be”). EA frameworks facilitate the development of strategic business capabilities to address the needs of key stakeholders. The degree to which an EA is successful may be determined by how it answers the questions that facilitate alignment between strategic business objectives and information technology. For example, the EA can be used to help executives understand their current capabilities, when additional capabilities may be available, and at what cost. To do this, executives may want to know what opportunities exist to improve clinical and business activities, what investments are required, and when expected benefits may be realized. Concurrently, an effective EA will help technology leaders answer questions such as what technology

8

components and process changes must be implemented to effectively achieve the business and clinical goals while minimizing any undesirable impacts to the stakeholder community. From an operational standpoint, project managers rely on the EA to assess the benefits, trade-offs, resource requirements, timing and risks associated with a given initiative. Technologists rely on the EA to help them understand what components (e.g., software, hardware, interfaces, file conversions, etc.) must be acquired or developed to achieve the business and clinical goals. The extent to which an EA (”as-is” and “to-be”) outlines a reference point or roadmap and provides an understanding of the resources, benefits, risks, and timing required will be a significant factor in determining its overall value to the organization as it executes its strategic objectives. Successful EA should have IT delivered and maintained in a transparent manner that earns the highest level of confidence from patients, families, clinicians, employees and other stakeholders.

17. What is the long term, future outlook for EA? Establishing an EA is not a point-in-time activity, but should be part of an ongoing process that evolves and matures in sync with the business, IT and the market. While initial goals of an EA attempt to capture business requirements to properly align IT, alignment alone is not the ultimate end-game. The long-term use of an EA attempts to capture business purpose and then help design the business to deliver desired business outcomes. The future EA is a ubiquitous, embedded architecture that becomes a way of life for organizations, embraced by all levels of functional staff and leadership. Similar to other industries, the continued adoption of EA by healthcare organizations leads to more standards on terms and methods that are specific to the HIT industry. It may also lead to more case studies and benchmarks of good and bad EAs for healthcare organizations based on business outcomes. This kind of data will not only help increase the capability level of the organizations adopting an EA, but the growth and maturity of the HIT industry as a whole.

9

REFERENCES

Ashby J, Ballard K, Hooper J. Building an EA Program at Saint Louis University (PowerPoint presentation). March 13, 2007. Retrieved from http://www.educause.edu/Resources/BuildinganEnterpriseArchitectu/159453

Blumenthal D, Tavenner M. The “Meaningful Use” Regulation for Electronic Health Records. Health Policy and Reform. New England Journal of Medicine. July; 2010. Posted June 17, 2011. <http://healthpolicyandreform.nejm.org/?p=3732>.

Department of Defense Integrated Architecture Panel. 1995. Based on IEEE STD 610.12, 1990. COBRA Continuation Coverage Assistance under ARRA. US Department of Labor. Posted June 17, 2011.

<www.dol.gov/ebsa/cobra.html >. Gøtze J. The Future of Enterprise Architecture (slide presentation). 2010. Retrieved from

http://www.slidefinder.net/T/The_Future_Enterprise_Architecture_Towards/9937299 Hajela S. Making a Case for Enterprise Architecture. Posted May 27, 2009. Retrieved from

http://www.cioindex.com/enterprise_architecture/ArticleId/1037/Making-a-Case-for-Enterprise-Architecture.aspx

Jones J. Developing Architecture Skills (PowerPoint presentation). 2003. Retrieved from

http://www.opengroup.org/architecture/0404brus/presents/jones/Developing_Architecture_Skills1.pdf

Kamran A. Healthcare Modeling through Enterprise Architecture: A Hospital Case. 2010. Op’t Land M, Proper E, Waage M, Cloo J, Steghuis C. Creating Value by Informed Governance. In The Enterprise

Engineering Series. Springer: Berlin; 2009. Ross JW, Weill P, Robertson D. Enterprise Architecture as Strategy : Creating a Foundation for Business Execution.

Boston: Harvard Business School Press. 2006. xviii, p 234. Stevenson Dennis, IS World, 2003 as quoted in the Journal of International Technology, 2010

U.S. Department of Defense Architecture Framework Working Group, DoD Architecture Framework: Volume II Product Descriptions, Version 1.0 (Feb. 9, 2004)

Weng C, Levine BA, Mun SK, Software architecture and engineering for patient records: current and future. Mil

Med. 2009: 174(5 Suppl):27-34.

10

EA Workgroup Members Suzanne Gerstner, BS Workgroup Chair

University of South Florida DO-IT ACCESS STEM- University of Washington

William Rauch, MSM

Director of Informatics and Acute Care Systems Berkshire Health Systems

Michael G. Brooks Specialist Leader | Information Management / Healthcare Industry Deloitte Consulting LLP

Maria Everhart Gaboury, PMP Director, Health Information Technologies LMI Ken Rubin

Chief Architect, Federal Healthcare Portfolio HP Enterprise Services

EA FAQ Editors William Beach, MBA Center for Health Care Quality

University of Missouri Health Care Monica Cunningham

VP, Marketing Health IT Certification.com

Raul Grinberg

Technical Logistics Lead PAREXEL International

Kenneth A. Kleinberg, FHIMSS Saugerties, NY Roger Zaremba

Chief Technology Officer (CTO) Saint Luke's Health System

HIMSS Staff Liaison Edna Boone, MA, CPHIMS Senior Director Mobile Initiatives