The Open Group Snapshot

Healthcare Enterprise Reference Architecture (HERA)

NOTICE
Snapshots are draft documents, which provide a mechanism for The Open Group to disseminate information on its current direction
and thinking to an interested audience, in advance of formal publication, with a view to soliciting feedback and comment.
A Snapshot represents the interim results of a technical activity. Although at the time of publication The Open Group intends to
progress the activity towards publication of a Preliminary Standard or Open Group Standard, The Open Group is a consensus
organization, and makes no commitment regarding publication. Similarly, a Snapshot does not represent any commitment by any
member of The Open Group to make any specific products available.
This Snapshot is intended to make public the direction and thinking about the path we are taking in the development of the Healthcare
Enterprise Reference Architecture (HERA). We invite your feedback and guidance. To provide feedback on this Snapshot, please
send comments to hcf-healthcare@opengroup.org.
This is a Snapshot of a work-in-progress. Do not require or claim conformance to this document.
This Snapshot document is valid through October 10, 2018 only.
For information on joining The Open Group Healthcare Forum, please contact Steve Borchert at s.borchert@opengroup.org.
Copyright © 2018, The Open Group
The Open Group hereby authorizes you to use this document for any purpose, PROVIDED THAT any copy of this document, or any
part thereof, which you make shall retain all copyright and other proprietary notices contained herein.
This document may contain other proprietary notices and copyright information.
Nothing contained herein shall be construed as conferring by implication, estoppel, or otherwise any license or right under any patent
or trademark of The Open Group or any third party. Except as expressly provided above, nothing contained herein shall be construed
as conferring any license or right under any copyright of The Open Group.
Note that any product, process, or technology in this document may be the subject of other intellectual property rights reserved by The
Open Group, and may not be licensed hereunder.
This document is provided “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, OR NON-INFRINGEMENT. Some jurisdictions do not allow the exclusion of implied warranties, so the
above exclusion may not apply to you.
Any publication of The Open Group may include technical inaccuracies or typographical errors. Changes may be periodically made to
these publications; these changes will be incorporated in new editions of these publications. The Open Group may make
improvements and/or changes in the products and/or the programs described in these publications at any time without notice.
Should any viewer of this document respond with information including feedback data, such as questions, comments, suggestions, or
the like regarding the content of this document, such information shall be deemed to be non-confidential and The Open Group shall
have no obligation of any kind with respect to such information and shall be free to reproduce, use, disclose, and distribute the
information to others without limitation. Further, The Open Group shall be free to use any ideas, concepts, know-how, or techniques
contained in such information for any purpose whatsoever including but not limited to developing, manufacturing, and marketing
products incorporating such information.
If you did not obtain this copy through The Open Group, it may not be the latest version. For your convenience, the latest version of
this publication may be downloaded at www.opengroup.org/library.

The Open Group Snapshot

Healthcare Enterprise Reference Architecture (HERA)
Document Number: S182

Published by The Open Group, April 2018.

Comments relating to the material contained in this document may be submitted to:
The Open Group, Apex Plaza, Forbury Road, Reading, Berkshire, RG1 1AX, United Kingdom
or by electronic mail to:
ogspecs@opengroup.org

ii The Open Group Snapshot (2018)

 Contents
1 Introduction ............................................................................................................... 1
1.1 Objective ......................................................................................................... 1
1.2 Overview......................................................................................................... 1
1.3 Conformance................................................................................................... 2
1.4 Normative References..................................................................................... 2
1.5 Terminology ................................................................................................... 2
1.6 Future Directions ............................................................................................ 3

2 Definitions................................................................................................................. 4

3 Foundations of the HERA ......................................................................................... 5

4 The HERA Level 0: Models and Cycles ................................................................... 6

4.1 Strategy & Plan Cycle..................................................................................... 6
4.2 Build & Deliver Cycle .................................................................................... 6
4.3 Operate & Evolve Cycle ................................................................................. 6

5 The HERA Level 1: Process Domains ...................................................................... 8

5.1 Strategy & Plan Cycle..................................................................................... 8
5.2 Build & Deliver Cycle .................................................................................... 9
5.3 Operate & Evolve Cycle ............................................................................... 10

6 The HERA Level 2: Processes ................................................................................ 13

6.1 Strategy & Plan Cycle................................................................................... 13
6.2 Build & Deliver Cycle .................................................................................. 14
6.3 Operate & Evolve Cycle ............................................................................... 15

7 The HERA Level 3: Tools, and Using the HERA in Practice ................................ 17

A The Healthcare Enterprise and Other Enterprises (Informative) ............................ 19

B Foundation, Levels, and Content Areas of the HERA ............................................ 20

C Rationale (Informative) ........................................................................................... 22

C.1 Person-Centricity .......................................................................................... 22

Healthcare Enterprise Reference Architecture (HERA) iii

 Preface
The Open Group

The Open Group is a global consortium that enables the achievement of business objectives
through technology standards. Our diverse membership of more than 600 organizations includes
customers, systems and solutions suppliers, tools vendors, integrators, academics, and
consultants across multiple industries.

The Open Group aims to:

 Capture, understand, and address current and emerging requirements, establish policies,
and share best practices
 Facilitate interoperability, develop consensus, and evolve and integrate specifications and
open source technologies
 Operate the industry’s premier certification service

Further information on The Open Group is available at www.opengroup.org.

The Open Group publishes a wide range of technical documentation, most of which is focused
on development of Open Group Standards and Guides, but which also includes white papers,
technical studies, certification and testing documentation, and business titles. Full details and a
catalog are available at www.opengroup.org/library.

The Open Group Healthcare Forum

The Healthcare Forum is relatively new. The Forum membership varies in professional
background (Enterprise Architecture is a common thread for most), country of origin, and
stakeholder type. Members live in countries with very different healthcare systems: India and
Scandinavia, Japan and Germany, Australia, the US, the UK, Canada, and elsewhere. Many
work for global companies with a very broad market presence. What members have in common
is their organizations’ interest in and perceived need for a Healthcare Enterprise Reference
Architecture (HERA). As individuals, all are passionate about trying to do something that
improves health and healthcare in this world.

The global span of the Healthcare Forum membership is a valuable attribute. We have found that
stakeholder differences drive variation in member views more than cross-country differences.
The Forum’s operational procedures and processes, developed and refined over the past two-
and-a-half decades by The Open Group, help members understand why others may have
different viewpoints, help members see things from others’ perspectives, and help members
develop consensus positions and products. Each of these benefits – the development of
consensus products in particular – can be difficult to find outside the formal Forum activities
derived from the membership model and rules of The Open Group.

All Forum members have input into the Healthcare Forum’s activities, which include shaping the
specification, testing, governing, and promoting (via certification, for example) of the HERA.
The dozen or so Forums of The Open Group address the leading IT and technology issues (e.g.,

iv The Open Group Snapshot (2018)

 Internet of Things (IoT), Digital Transformation, Open Process Automation™, cybersecurity,
managing IT, and more) shared by large and small businesses worldwide. The Healthcare Forum
benefits from and contributes to all Forums of The Open Group.

For more information on the Healthcare Forum, see www.opengroup.org/healthcare.

This Document

This document is a Snapshot of what is intended to become The Open Group Healthcare
Enterprise Reference Architecture (HERA) Standard. It is being developed by The Open Group.

The HERA is the product of an ongoing multi-year collaboration of the global membership of
the Healthcare Forum.

About The Open Group Healthcare Enterprise Reference Architecture (HERA)

Many of the problems healthcare organizations need to solve today are not new problems. The
healthcare industrial complex has been dealing with cost, quality, access, and information flow
issues for decades. Legacy systems, typically a patchwork of “quick fixes” and band-aid
measures, now make some seemingly simple solutions complicated and complex. Sometimes
wiping the slate clean and starting over appears to be the best, if not the most expensive,
approach, at least in the short term. When starting over is not realistic, as is usually the case in
developed economies, then the HERA helps focus problem solving by simplifying system
complexity so decision-makers and technical staff can develop practical solutions.

The HERA is a framework for the development of a reference architecture for a healthcare
company, from big to small (50 employees or more).

The HERA is a logical, cognitive map that can help most healthcare stakeholders improve their
business by using IT in a smarter way. “Smart” means integrating IT into the whole business,
and on a macro-scale, into the whole enterprise.

The HERA is specified in this Snapshot as four views layered from most general to most
specific. Each view addresses business processes at a different “nested” level of abstraction.

Level 0 is the most abstract. Level 1 provides more detail than Level 0, Level 2 more detail than
Level 1, and so forth. Metaphorically, the views are a magnifying scope (think binoculars) to
enable the user to build a better understanding of the vast healthcare landscape and how and
where their company (enterprise) fits in. As the user focuses in on the landscape, they gain a
more detailed understanding of the common cycles, processes, and types of tools generally
applicable to healthcare enterprises. The HERA framework can help enterprises focus on the
inter-related processes and specific tools that will help to deliver value to customers.

In summary, the HERA:

 Is an architecture of the whole healthcare enterprise designed by diverse stakeholders
from around the world
 Lets you zoom in and out, focusing on business problems large and small
 Provides an evidence-based, integrative framework in which you use existing, known, and
familiar tools to meet your business needs

Healthcare Enterprise Reference Architecture (HERA) v

 Why is the HERA Needed?

This prototype 0.1 version of the HERA starts to fill in an important missing piece of the
healthcare enterprise; namely, the “big-picture view”. Granted, organizations of many types have
produced big-picture views for a long time. But in the private sector, they focus on a company or
company type, a stakeholder or stakeholder type, or a limited combination of both. In the not-
for-profit sector, research organizations focus big-picture views on broad issues (for instance, the
organization, finance, or delivery of healthcare; or long-term care, primary care, or “access”;
health IT, personalized medicine, or Digital Transformation). In government and quasi-
government sectors, where a big-picture view of the healthcare enterprise is perhaps most
expected, big-picture views tend to be focused on a crisis situation (emergency department
overcrowding, the opioid crisis, the obesity epidemic, access), a defined group of stakeholders
(veterans of war and their families), or a chronic healthcare problem (e.g., healthcare
interoperability, the solvency of public programs, comparative effectiveness research). What we
need, and what the HERA is designed to provide, is a cognitive map and conceptual guide to
help decision-makers grasp the larger ecosystem in which they compete.

The value of the HERA is expressed in the following properties that, alone and in combination,
show that at a conceptual level, at least, it is a unique and useful framework that healthcare
enterprises can use to solve business problems, large and small.
 The HERA provides an integrative framework that facilitates bridge-building across intra-
and inter-organizational silos
 The HERA responds to the need for an enterprise-wide framework for collaboration
among other standard development organizations and the many assorted efforts to solve
key healthcare problems including, but not limited to, interoperability
 The scope of the HERA extends to the “whole health enterprise” (see Figure 1)
 Its conceptual underpinnings are tied to the shared understanding that complex systems,
like healthcare, require complex yet clear solutions – while complex and clear are difficult
by themselves, together they are even more challenging
 A key insight about organizational behavior is built into the HERA; namely, that IT and
technical change involves human beings and their motivation and ability to learn and
adapt, desire to change, their workflow dynamics, and the pervasive ether we call culture
 The HERA is supported by the key sociology of knowledge insight that “what you see
depends on where you sit”
 The HERA is closely aligned with The Open Group vision of Boundaryless Information
Flow™: “achieved through global interoperability in a secure, reliable, and timely
manner”1
 The silo mentality is anathema to the HERA
It is designed to improve information flow and the healthcare services that follow, but the
usefulness of the HERA depends first on breaking boundaries and silos among the key
actors in an organization. Open and multi-directional communication between
management, builders, and operators is necessary for Continuous Quality Improvement
(CQI) and business’ response to advances and change in IT and technology.

1
See www.opengroup.org/aboutus/vision.

vi The Open Group Snapshot (2018)

  Interoperability issues – focused on information model harmonization and seamless
information exchange – stood front and center in early formulations of the HERA
However, the HERA designers wanted to build a broader, more inclusive framework that
precedes an architectural model (focused on building and delivering solutions) with a
management model (that focuses on strategy and planning) and supersedes it with an
operations/CQI model
 HERA designers understood that, to be truly useful and improvement-oriented, the
framework must capture the reality that change does not typically happen in a linear
fashion; thus, the HERA is designed with agility in mind
 The HERA is built through global collaboration
In many cases, this provides an obvious asset and advantage over solution frameworks
with a narrower focus. This is especially relevant for companies that have a global
presence and those that wish to “go global”.

Intended Audience

Who will benefit from using the HERA? Payers, providers, vendors, consultants? Is it applicable
to the private sector only or does its relevance extend to public sector healthcare organizations as
well? Does it apply to healthcare organizations internationally? Is it for engineers and architects
or managers? The answers to all of these questions is an unqualified “Yes”.

Healthcare Enterprise Reference Architecture (HERA) vii

 Trademarks
ArchiMate®, DirecNet®, Making Standards Work®, OpenPegasus®, Platform 3.0®, The Open
Group®, TOGAF®, UNIX®, UNIXWARE®, X/Open®, and the Open Brand X® logo are
registered trademarks and Boundaryless Information Flow™, Build with Integrity Buy with
Confidence™, Dependability Through Assuredness™, EMMM™, FACE™, the FACE™ logo,
IT4IT™, the IT4IT™ logo, O-DEF™, O-PAS™, Open FAIR™, Open Platform 3.0™, Open
Process Automation™, Open Trusted Technology Provider™, SOSA™, the Open O™ logo, and
The Open Group Certification logo (Open O and check™) are trademarks of The Open Group.

All other brands, company, and product names are used for identification purposes only and may
be trademarks that are the sole property of their respective owners.

viii The Open Group Snapshot (2018)

 Acknowledgements
The Open Group gratefully acknowledges the contribution of the following people in the
development of this document:
 Stig Hagestande, Managing Enterprise Architect, CTO Office – Nordic Healthcare,
Capgemini
 Jason S. Lee, PhD, Director, Healthcare Forum, The Open Group
 Members of The Open Group Healthcare Forum

The authors would like to thank all Members of the Healthcare Forum, and especially Oliver
Kipf, Phillips (Chair, Healthcare Forum).

Healthcare Enterprise Reference Architecture (HERA) ix

 Referenced Documents
The following documents are referenced in this Snapshot.

(Please note that the links below are good at the time of writing but cannot be guaranteed for the
future.)
 Health Care Information Systems: A Practical Approach for Health Care Management, 3rd
Edition, aren A. ager, Frances . Lee, John P. Glaser, Jossey-Bass, 2013
 The Elements of Architecture, Henry Wotten, 1624; refer to: http://archiv.ub.uni-
heidelberg.de/artdok/1870/1/Davis_Fontes68.pdf
 Using a Plan-Build-Run Organizational Model to Drive IT Infrastructure Objectives,
Himanshu Agarwal, Nagendra Bommadevara, Allen Weinberg, McKinsey & Company,
2013; refer to: www.mckinsey.com/business-functions/digital-mckinsey/our-
insights/using-a-plan-build-run-organizational-model-to-drive-it-infrastructure-objectives

x The Open Group Snapshot (2018)

1 Introduction

1.1 Objective
The subject of this Snapshot is the specification of The Open Group Healthcare Enterprise
Reference Architecture (HERA). It describes a framework for the development of a reference
architecture for a very wide range of healthcare companies.

The purpose of this Snapshot is to seek feedback from readers in advance of publishing The
Open Group HERA 1.0.

This Snapshot is intended to make public the direction and thinking about the path we are taking
in the development of the HERA. We invite your feedback and guidance. To provide feedback
on this Snapshot, please send comments to hcf-healthcare@opengroup.org no later than October
10, 2018.

1.2 Overview
The HERA is a like a cognitive map. It can be used in whole or part by virtually all types of
stakeholders in the healthcare landscape. It can be applied globally, both in the sense of its
application by multi-national enterprises, and in the sense that it applies virtually anywhere there
is a healthcare system and is global in scope.

It provides a layered set of views into the healthcare enterprise. The “enterprise” in this context
is considered to be the companies and organizations that contribute to the healthcare economy at
the most meaningful levels of aggregation: markets, states, provinces, regions, countries, etc.2 At
the top layer of views is the HERA Level 0, a highly generalized conceptual framework based
on the longstanding and seminal “plan-build-run” conceptual model employed across numerous
manufacturing and service sectors.3 From there, the HERA is used to “drill down” or “zoom in”
to the key processes involved at each finer level of detail. Thus, from the most abstract level
(Level 0), the HERA provides more detailed views from Level 1 to Level 2 to Level 3. Level 3
is the most specific generalized point of view that remains relevant to the whole healthcare
enterprise. In other words, Level 3 is the “jumping off point”, not from the HERA framework
itself, but into the details of a specific enterprise.

The HERA presents its insights in an integrative framework. From the broadest perspective –
that is, “zoomed out” to the highest level of abstraction – the HERA specifies the key models
and cycles common to all healthcare businesses. At the next level, it shows and explains how a

2
It is confusing sometimes when the word “enterprise” is used, validly, in both a macro and micro sense (though not at the same time,
of course). From the macro perspective, enterprise means all companies and all types of companies. From the micro perspective,
enterprise means a specific company or type of companies. The context usually dictates which meaning is intended.
3
According to Mc insey: “sophisticated infrastructure organizations are increasingly turning to functional ‘plan-build-run’
organizational models, which, by breaking down silos and working across technology domains, can facilitate a broad set of
performance-improvement and transformation objectives”. (Mc insey Article: Using a Plan-Build-Run Organizational Model to
Drive IT Infrastructure Objectives, by Agarwal et al. (see Referenced Documents)).

Healthcare Enterprise Reference Architecture (HERA) 1

 dozen common processes are inter-related, how they provide feedback to one another, and how
they interact. This is what we call the HERA’s whole-health system perspective.

LEGEND
actors = red
capabilities = blue Person

Providers Innovators,
Vendors, Suppliers

Payers Governing Bodies

Health Systems
Management

Figure 1: The HERA Landscape

Figure 1 illustrates the breadth of the landscape of the HERA ecosystem. The ecosystem is
defined by actors in red and capabilities in blue. The actor categories are broad; perhaps none
more so than “innovators, suppliers, and vendors”. The scope of the HERA is the healthcare
enterprise, writ large. The HERA is designed to be useful to virtually all healthcare enterprises.

1.3 Conformance
This is a Snapshot, not an approved standard. Do not specify or claim conformance to it.

1.4 Normative References

None.

1.5 Terminology
For the purposes of the HERA, the following terminology definitions apply:

Can Describes a possible feature or behavior available to the user or application.

May Describes a feature or behavior that is optional. To avoid ambiguity, the opposite of
“may” is expressed as “need not”, instead of “may not”.

Shall Describes a feature or behavior that is a requirement. To avoid ambiguity, do not

use “must” as an alternative to “shall”.

Shall not Describes a feature or behavior that is an absolute prohibition.

Should Describes a feature or behavior that is recommended but not required.

Will Same meaning as “shall”; “shall” is the preferred term.

2 The Open Group Snapshot (2018)

1.6 Future Directions

Short-Term

This Snapshot features the HERA prototype 0.1. It has six-month shelf life. During this time, the
Forum seeks feedback that will help it produce a HERA 1.0 standard. Members encourage any
and all constructively framed requests for changes. For example, “I don’t like x because of y and
here is how I would change it …,” rather than a simple statement of approval or disapproval,
such as “I don’t like x”. Please send feedback to hcf-healthcare@opengroup.org. Please state
whether feedback should be kept anonymous or not.

Longer-Term

The second course of future work is to demonstrate that the HERA is executable. Members of
the Forum, and by collaboration agreement, others, will test the HERA to assess its usefulness. If
sufficient evidence supports its usefulness we would consider that a success and we would move
forward from there. “Forward” is in the direction of collecting more useful data on the HERA’s
“fit for purpose” qualifications. Ultimately, after repeated testing-revision cycles, the HERA will
be developed as a standard and certification processes will be developed.

Healthcare Enterprise Reference Architecture (HERA) 3

2 Definitions

For the purposes of this standard, all terms are as defined in the Merriam- ebster’s Collegiate
Dictionary.

4 The Open Group Snapshot (2018)

3 Foundations of the HERA

The HERA builds on and extends the plan-build-run organizational model.4 The longstanding
success of this model – its widespread use across enterprises – can be attributed to its wide scope
of relevance, its fit for multiple purposes, and its simplicity. The Healthcare Forum appreciates
the factors underlying its success but feels that the usefulness of plan-build-run for healthcare
organizations is limited by its generality and lack of specific healthcare-relevant use-cases.

The HERA builds on plan-build-run by logically extending and aligning “plan” with a
management model, “build” with an architectural model, and “run” with an operations model.
This foundation supports the most abstract presentation of the HERA (Level 0), discussed in
Chapter 4.

Plan Build Run

Management Architecture Operations

Figure 2: Plan-Build-Run and Three Key Models

4
For a discussion of the utility of “plan-build-run” see the McKinsey Article: Using a Plan-Build-Run Organizational Model to Drive
IT Infrastructure Objectives, by Agarwal et al. (see Referenced Documents).

Healthcare Enterprise Reference Architecture (HERA) 5

4 The HERA Level 0: Models and Cycles

At this level of the HERA, we align the management, architecture, and operations models with
three cycles that are necessary for enterprise success – which in our case means better health and
healthcare for persons and populations.

4.1 Strategy & Plan Cycle

The ultimate responsibility for the strategic planning and direction of an organization is assigned
to the Chief Executive Officer (CEO). The other C-suite role occupants (CFO, CIO, CMO,
among others) have unique functional responsibilities and they also advise the CEO on
enterprise strategic planning. The work of strategists and planners is represented in the HERA’s
management model. This model embraces the Strategy & Plan cycle, which includes
understanding business drivers, setting goals, assessing and developing capabilities and
resources, and setting priorities. We elaborate these specific processes and some of the tools
used to accomplish them in the subsequent sections of this document that go deeper into the
HERA.

4.2 Build & Deliver Cycle

The work of architects and designers is represented in the architecture model at Level 0 of the
HERA. This model embraces the Build & Deliver cycle that includes information, application,
and technology and results in products and services based on the strategies and plans specified
by executives. Here it must be said that clear and consistent two-way communication between
managers and technicians is essential for successful business operations. Yet, it is well known
that organizations tend to be silo’ed and that communication barriers between managerial and
technical business units are known roadblocks in the effort to use IT and technology more
effectively to solve problems in healthcare. The HERA does not tell an organization how to
bridge this gap, but it does (again, at a deeper level) specify how processes are related to one
another, and from this, users may deduce where information flow problems are most dire and
can advise and act accordingly.

4.3 Operate & Evolve Cycle

The operations model encompasses key enterprise operations and improvement processes.
Because operations produce “real-world” data that can be used to improve the enterprise, the
HERA expands the concept of “do” to include measurement, quality improvement, and evolving
the enterprise. Thus, the operations model is associated with the Operate & Evolve cycle in the
HERA. Rapid evaluation and analysis of outcomes tied to processes is key to implementing a
“design approach” and to using agile methods to improve the enterprise.

6 The Open Group Snapshot (2018)

 Strategy & Plan

Management

Drive for
Continuous
Improvement Build & Deliver
Operate & Evolve

Operations Architecture

Figure 3: The HERA Level 0

Finally, it is important to highlight another extension of the traditional plan-build-do foundation

of the HERA. As shown in Figure 2, plan-build-do are linear phases. That is, once planning is
complete, it moves to building, and once building is complete, it moves to doing. There is an
obvious logic to this order. It describes how new companies enter a market, and it describes the
overall logic of change and transformation in mature enterprises. However, the HERA does not
assume that enterprises always function in a linear fashion. To capture the non-linear and
recursive nature of actual business dynamics, the HERA places the three key models/cycles in a
circle in which each is related to the other bi-directionally. Thus, depending on the business
problem the user is trying to solve, entrance to the HERA might start with Build & Deliver, then
return to Strategy & Plan, then feed into the Operate & Evolve cycle, which then feeds back to
the Strategy & Plan cycle. And of course there are many other permutations.

Healthcare Enterprise Reference Architecture (HERA) 7

5 The HERA Level 1: Process Domains

At the next level of the HERA, each of the three core cycles described in Level 0 is further
divided into four discrete process domains to elaborate the tasks that are required to complete
each cycle and to create a holistic architecture.

5.1 Strategy & Plan Cycle

The Strategy & Plan cycle focuses on the key business concerns that need to be addressed by all
enterprises. These concerns must be formulated using clear language to facilitate a meaningful
dialog among the business decision-makers and stakeholders. Strategy & Plan addresses key
business concerns, from what drives and impacts the business (e.g., market conditions,
government regulation), to business goals, strategies, and plans for change. The output from this
cycle is a transformation portfolio, which gives direction to the critical and challenging
processes encompassed in the Build & Deliver cycle. The output from this cycle should:
 Be open, explicit, and clear
 Facilitate communication between C-level and mid-level management, engineers, and
technicians who architect and build deliverables

Business Business
Drivers Goals

Strategy & Plan

Transformation Business
Portfolio Strategy

Figure 4: Process Domains in the Strategy & Plan Cycle

8 The Open Group Snapshot (2018)

5.2 Build & Deliver Cycle
The Build & Deliver cycle uses output from the Strategy & Plan cycle (i.e., the transformation
portfolio) to drive the architectural efforts needed to realize business strategies. In this cycle we
divide healthcare Enterprise Architecture into four process domains: business, information,
application, and technology. Initially, work in this domain should start in the business quadrant
to ensure that the architecture addresses the business needs in a top-down approach. Build &
Deliver is complete (but must always be revisited given the dynamic nature of healthcare
enterprises) when discrete deliverables are produced and can be implemented in the Operate &
Evolve cycle of the business.

One word about this cycle. e formerly called it the “BIAT wheel” (business, information,
application, and technology). In the Forum’s early days, members focused only on the
development of the BIAT wheel. Why? This should not be a surprise. This is where many
architects and medical informaticians (including CIOs, CMIOs, semantics and taxonomy
experts) devote most of their time and effort – particularly in the information process domain.
Building and harmonizing health information models is a very difficult, time-consuming, and
costly challenge. First there is the technical challenge of capturing health information in a broad,
widely applicable model. Second, most private enterprises that provide electronic health record
capabilities – including point-to-point interoperability – do not make this information open and
available to others. It is highly proprietary. Thus, health information model building is both
extremely complex and highly political. Similar issues exist in the application process domain.

In light of the heavy focus on the information and application processes of the architecture
model, the leadership and members of the Healthcare Forum determined that healthcare needs a
reference architecture that frames all key functional dynamics in the healthcare enterprise at both
a broad and more detailed level. Thus, the Forum began to work on a prototype of the HERA
based on the view that architects (or, “builders” more generally) need to adopt a more enterprise-
wide perspective.

Healthcare Enterprise Reference Architecture (HERA) 9

 Business Information

Build & Deliver

Technology Application

Figure 5: Process Domains in the Build & Deliver Cycle

5.3 Operate & Evolve Cycle

The Operate & Evolve cycle is enabled by deliverables produced in the Build & Deliver cycle.
In this cycle, there is a repeating loop of four process domains – Operate, Measure, Analyze, and
Evolve – that is necessary to ensure continuous delivery of high-quality services. The operations
domain includes all the processes necessary to produce value for customers and consumers.
Operations also produce data that is collected according to Key Performance Indicator (KPI)
guidelines. KPIs, in turn, are analyzed – in big to small data sets, using a variety of analytic tools
to improve and evolve the business. The HERA developers recognize that continuous
improvement is not enough; there must be close attention given to evolving the services
delivered to remain agile and meet the demands of a high-speed changing environment.

10 The Open Group Snapshot (2018)

 Operate Measure

Operate & Evolve

Evolve Analyze

Figure 6: Process Domains in the Operate & Evolve Cycle

Healthcare Enterprise Reference Architecture (HERA) 11

 Business Business
Drivers Goals

Strategy & Plan

Transformation Business
Portfolio Strategy

Drive for
Continuous
Improvement
Business Information
Operate Measure

Build & Deliver

Operate & Evolve

Technology Application
Evolve Analyze

Figure 7: The HERA: Level 1

In summary, the HERA Level 1 view is composed of three cycles, with four process domains
each, and 12 inter-related processes in all.

The ability to change in response to new business demands requires continuous high-paced
iterations of the HERA’s three cycles.

12 The Open Group Snapshot (2018)

6 The HERA Level 2: Processes

Thinking about the HERA framework as three cycles with four process domains each, Level 2 of
the HERA focuses on the key processes in each domain of each cycle.

6.1 Strategy & Plan Cycle

The Strategy & Plan cycle focuses on the business and, like all other cycles, is iterative. There
must be an understanding of the business drivers or the why: what is our business?; why are we
here?; and what are the internal and external changes that necessitate continuous transformation
in an enterprise that rapidly changes on so many levels? An assessment is done to formulate the
business goals. The business goals must address who the stakeholders are and their concerns. It
must take into consideration the business requirements to formulate a transformation plan for
how to realize the business goals. This plan is the basis for a business strategy to decide how
changes need to be implemented. The business capabilities (existing or to-be-developed)
determine where to direct enterprise effort to move from the “as-is” to the “to-be,” identified
using a gap analysis of the business baseline and target. This analysis suggests what specific
target goals need to be included in an enterprise’s transformation portfolio, which is the sum of
all work packages derived from the Strategy & Plan cycle. The transformation portfolio is the
output to the next Build & Deliver cycle. As noted earlier in this document, the HERA can be
employed linearly. Or, the user can jump into the HERA at any-to-all of the 12 process domains.

Healthcare Enterprise Reference Architecture (HERA) 13

 Stakeholders

Business Drivers Business Goals

Requirements
Business Business
Assessment
Drivers Goals

Transformation
Plan

Strategy & Plan

Business
Gap Strategy
Baseline
(”to-be”)

Business
Transformation Capabilities
Portfolio Target
(“as-is”)
Transformation Business Strategy
Portfolio

Figure 8: Processes in the Four Domains of the HERA Strategy & Plan Cycle

6.2 Build & Deliver Cycle

The transformation portfolio from the Strategy & Plan cycle drives the efforts undertaken in the
Build & Deliver cycle. This cycle is service-oriented and its main objective is to realize
improved business functions and services. Business service requirements guide value set (i.e.,
raw and/or semi-structured data) needs. Raw and semi-structured data is codified using
information models. Information model needs are determined by a user’s enterprise-specific
HERA reference model. Ultimately, a structured information model is required to achieve true
interoperability. When the information model is exposed through interfaces, interoperability can
be achieved through common services and reduces the number of point-to-point integrations.
These interfaces are provided by application services that expose application functions to enable
information exchange and transformation. The application services create an abstraction layer
that removes the dependencies for business services to interact directly with physical
applications. This enables coexistence with legacy systems and allows for a migration without
affecting the business services. Technology services create the same form of abstraction level for
the application services and enable the coexistence and migration of legacy platforms and
technology.

14 The Open Group Snapshot (2018)

 Business Information
Information
Actor(s)
Model
Transformation
Portfolio
Business
Terminologies
Function

Business
Value Set
Service
Build & Deliver
Technology Application
Service Service

Technology Application
Function Function

Deliverables Physical Physical

Device Application

Technology Application

Figure 9: Processes in the Four Domains of the HERA Build & Deliver Cycle

6.3 Operate & Evolve Cycle

Deliverables from the Build & Deliver cycle drive the efforts in the Operate & Evolve cycle. Of
course, the specific processes in the operations domain vary from company to company, but the
“outcome of business operations is the harvesting of value from assets owned by a business”.5
Growing assets and increasing value requires accurate, timely, and CQI data. The Measure
domain in this cycle addresses this requirement through the collection of KPI data relating to
business, IT, and clinical outcomes.6 (Of course, identifying and building capabilities to collect
KPI data are key processes in the Strategy & Plan and Build & Deliver cycles.) The collection of
KPI data leads naturally to the analysis process domain of the current cycle. The analysis of data
to produce information and knowledge is the primary function of the application of analytic
tools. Some processes, like the development of a patient reminder system, can be fully
automated. Others require extensive exploratory analysis, including the use of big data and
predictive analytic tools. The knowledge gained from analytic processes directly informs the
evolve process domain.

5
Source: https://en.wikipedia.org/wiki/Business_operations.
6
“A ey Performance Indicator (KPI) is a type of performance measurement. KPIs evaluate the success of an organization or of a
particular activity in which it engages.” (Source: http://eitbokwiki.org/Glossary#eit.)

Healthcare Enterprise Reference Architecture (HERA) 15

 Deliverables
Operate Measure
Business

Business
Service
Measure IT
KPIs
IT Service

Clinical

Operate & Evolve

Business
Outcomes

Business
Drivers Evolve Assessment Clinical
Outcomes
Back to the
Strategy & Plan Cycle
IT
Outcomes

Evolve Analyze

Figure 10: Processes in the Four Domains of the HERA Operate & Evolve Cycle

16 The Open Group Snapshot (2018)

7 The HERA Level 3: Tools, and Using the HERA in
Practice

In this chapter we take each HERA cycle, quadrant by quadrant, and provide examples of well-
known generic resource tools available to users. We do not advocate for one tool or another. Not
all useful resources are cited in the following figures. Our aim is simply to indicate that the
HERA is highly flexible and can accommodate a wide range of tools available to users. Level 3
of the HERA is the most specific level of the general framework. Here, one begins to see
healthcare-specific tools specified. Beyond Level 3, a user begins to specify the tools that are
most useful given the capabilities, resources, and legacy systems of their companies.

Interviews
Strategic vision and mission Case studies
Ecosystem/landscape Stakeholders Networks maps
Regulatory environment Role identif ication
Market conditions (e.g., interests,
Internal, organizational f actors
Business Drivers Business Goals
relationships,
Requirements collaborators,
Business Business naysayers)
Assessment
Drivers Goals

Analysis of markets,
regulations, Transformation IT principles (architecture, security)
economics, Plan Enterprise Resource Planning (ERP)
demographics Applications lif ecycle management
Requirements Traceability
Strategy & Plan Matrix (RTM)
Business
Strength, Weakness, Gap Strategy
Baseline
Opportunity, Threat
(”to-be”)
(SWOT) analysis Strategy f ormation may not
Business f ollow a f ormal process
Transformation Capabilities
To Portfolio Target
(“as-is”)
BUILD &
DELIVER Transformation Business Strategy Applications lif ecycle management
Portfolio

Figure 11: Resource Examples: Strategy & Plan Cycle

Healthcare Enterprise Reference Architecture (HERA) 17

 Landscape
Business Information
From FHIM, CIMI, etc.
Transformation Information
STRATEGY Portfolio Actor(s)
Model
& PLAN
LOINC, RxNorm,
Business
Terminologies Snomed-CT, ICD-10, etc.
Function
Service-Oriented Architecture
(SOA)
Orchestration layer (e.g., Business
Value Set
Service
Clinical Decision Support EHR eClinical quality measures
(CDS) and rules-based claims Build & Deliver Cost of care, Value
processing), etc.

Enterprise Service Bus (ESB) Technology Application

Web Services Description Service Service RESTf ul call, cdsHooks,
Language (WSDL), etc. Argonaut API call, etc.
Technology Application
Function
To Function
Internal f unctionality
OPERATE Deliverables
Physical Physical
& EVOLVE Device Application Line-of -business application
(e.g., hospital admissions,
Technology Application clinical management
Medical IOT in general sof tware, etc.
Physical devices (mobile or f acility-based)
Consumer devices, etc.

Figure 12: Resource Examples: Build & Deliver Cycle

Tools businesses use to

From track how ef f ectively they
Deliverables
BUILD & achieve their objectives
Operate Measure
DELIVER
Business
Business
eCQM
services,
products, and NQF-endorsed measures
operations Measure IT STAR ratings
Operation of capabilities
KPIs Inpatient & Outpatient
f rom landscape map
IT Service Quality Reporting (IQR, OQR)
(actor-dependent)
Physician Quality Reporting
Clinical System (PQRS)
Incident, problem, Value
perf ormance, security
management, etc.
Operate & Evolve
Business
Outcomes
To Big data analytics
Business Clinical
STRATEGY Drivers
Evolve Assessment
Outcomes
Health Services Research (HSR)
Medical inf ormatics
& PLAN Public health
IT Epidemiology
Outcomes
Clinical trials
Artif icial intelligence
Agile, sprints, etc. Evolve Analyze Evidence and value-based
medicine, etc.

Figure 13: Resource Examples: Operate & Evolve Cycle

18 The Open Group Snapshot (2018)

A The Healthcare Enterprise and Other Enterprises
(Informative)

This appendix looks at why IT in the healthcare enterprise is uniquely difficult compared to
other enterprises, and why healthcare needs a reference architecture.

We start by acknowledging some essential facts. Technology, and Information Technology in

particular, has reached an unparalleled level of complexity in the healthcare enterprise. By
“unparalleled” we mean compared to other industries that use IT to solve business problems.
The reasons for this, more thoroughly described in a different context elsewhere,7 are
summarized here:
1. The healthcare enterprise is populated by a very large number of organizations, big and
small. This poses quite real cost barriers to IT acquisitions for providers and vendors.
(Consider the history of “meaningful use” in the US.)
2. Payment systems (especially fee-for-service reimbursement systems) do not provide
sufficient incentives for the adoption of IT.
3. Care is fragmented across different systems (payers, providers, organizations, offices,
regions, etc.) that do not share information.
4. The business of healthcare is more complex than any manufacturing process. Standards of
care typically allow a provider at least some degree of latitude in treatment decisions,
variability in application of standards is well documented, and the evidence base and
innovation rate in medicine is highly volatile.
5. Health and medical data is complex. It is difficult to develop agreed code sets using
common semantics and syntax. Medical conditions can be nuanced and impossible to
express in a fully standardized manner. Machine input can be cumbersome and restrictive
compared to using traditional analog methods of data capture.
6. The nature of provider organizations can be a barrier to IT adoption for at least two major
reasons:
a. Provider organizations often view data sharing as a competitive disadvantage. On
the flip side, the means by which provider organizations achieve the degree of
interoperability they have achieved to-date is treated as among the most proprietary
intellectual property the organization owns.
b. Provider organizations’ dual power structures – administrative and clinical – hinder
rather than facilitate decision-making.

7
Health Care Information Systems: A Practical Approach for Health Care Management, Wager et al. (see Referenced Documents).

Healthcare Enterprise Reference Architecture (HERA) 19

B Foundation, Levels, and Content Areas of the HERA

Level 0 Level 1 Level 2 Level 3

Tools
(see Figure 11
Foundation Models Cycles Process Domains Processes to Figure 13)

Plan Management Strategy & Plan Business Drivers Drivers

Assessment

Business Goals Goals

Stakeholders

Requirements

Transformation Plan

Business Strategy Strategy

Capabilities

Baseline

Target

Transformation As-Is – To-Be Gap

Portfolio
Transformation
Portfolio

Build Architecture Build & Deliver Business Service

Function

Actors

Information Value Set

Terminology

Information Model

Application Service

Function

20 The Open Group Snapshot (2018)

 Level 0 Level 1 Level 2 Level 3

Tools
(see Figure 11
Foundation Models Cycles Process Domains Processes to Figure 13)

Physical Application

Technology Physical Device

Technology Function

Technology Service

Run Operations Operate & Evolve Operate Business Service

IT Service

Measure Measure KPIs

Business

IT

Clinical

Analyze Assessment

Business Outcomes

IT Outcomes

Clinical Outcomes

Evolve Evolve

Healthcare Enterprise Reference Architecture (HERA) 21

C Rationale (Informative)

This informative appendix contains additional information concerning the contents of this
document.

C.1 Person-Centricity
Figure 1 puts the person in the middle of the landscape. The HERA is patient-centered and
customer-focused. Ultimately, outcomes related to the patient are the ultimate metric of success.
In this way, the HERA is aligned with value-based medicine and pay-for-performance rather
than fee-for-service or capitation schemes that are not directly related to patient health outcomes.

HERA users who represent stakeholders who do not provide direct patient care – i.e., much of
the healthcare supply chain – may focus on outcomes that are not directly related to patients.
Many IT vendors are in this situation, where the outcome is a product or service that meets
certain standards or expectations.

The general point about the HERA is that it is designed for users whose operations are directed
by their ends, and their ends are directed by the vision, mission, and specific goals of the
organization. As Henry Wotten wrote in the classic The Elements of Architecture (1624): “In
Architecture, as in all other Operative Arts, the end must direct the operations.”

Figure 14: The Elements of Architecture8

8
The Elements of Architecture, Henry Wotten, 1624, p.1; refer to: http://archiv.ub.uni-
heidelberg.de/artdok/1870/1/Davis_Fontes68.pdf.

22 The Open Group Snapshot (2018)

 Index
application services .................. 14 information model .................... 14
Build & Deliver ...................... 6, 9 models ........................................ 6
business capabilities ................. 13 Operate & Evolve........... 6, 10, 15
business drivers ........................ 13 person-centricity....................... 22
business goals ........................... 13 process domains ..................... 8, 9
business strategy ....................... 13 processes .................................. 13
cycles .......................................... 6 resource tools ........................... 17
gap analysis .............................. 13 Strategy & Plan ................ 6, 8, 13
healthcare enterprise ................... 2 technology services .................. 14
HERA ecosystem ....................... 2 transformation plan .................. 13
HERA foundations ..................... 5 transformation portfolio . 8, 13, 14
HERA landscape ........................ 2 users ......................................... vii

Healthcare Enterprise Reference Architecture (HERA) 23