Developing A Business Model and IT Foundation for Digital

Healthcare
Michael Ali and Eric Plummer
April 2016

I.

Introduction

The business case for digital healthcare derives from the need to continually deliver
better value at lower cost. The healthcare industry is migrating toward measuring
value by using objective measures of beneficial results for the patient, which BCG
calls competing on outcomes [BCGa]. There are a number of case studies
demonstrating that outcomes-based healthcare works for the patient, the provider,
and the payer [BCGb]. The Gartner Group [Gartnera] states The successful
transformation of the industry to a consumer-centric, value-based delivery model
depends upon healthcare digitalization,and the means to leverage IT to achieve
quality outcomes at lower cost. This paper proposes an approach to creating the
business model and enabling IT infrastructure that can serve as a foundation for
achieving digitalized healthcare.

II.

Business Case for Digital Healthcare

The business case for digital healthcare derives from the need to continually deliver
better value at lower cost. The healthcare industry is migrating toward measuring
value by using objective measures of beneficial results for the patient, which BCG
calls competing on outcomes [BCGa]. Competing on outcomes requires the
following business capabilities:
a. 360 view of the patient: ideally, every interaction with a patient is
captured, from prevention and wellness, to diagnosis, to intervention and
therapy, to treatment and monitoring. Interactions include the various
channels such as the pharmacy, in- and out-patient care, emergency room,
self-service (perhaps via mobile), etc.
b. Analytics: identification of patterns and trends, modeling and decisionsupport, ideally with the option of leveraging machine learning
c. Low-friction interface between partners: patient data needs to be
accessible across 1st, 2nd, and 3rd level service providers, payers, suppliers,
etc.
There are a number of case studies demonstrating that outcomes-based healthcare
works for the patient, the provider, and the payer [BCGb]. However, achieving the
enabling capabilities requires that each of the players in the value chain have a
vision, strategy, and plan for creating a digital business model and the aligned

Information Technology (IT) infrastructure enabling that model. In many cases,

developing a business model and enabling IT is a transformational exercise. In any
transformation, the first step is to determine the end-state vision (i.e., if you dont
know where youre going, you will probably end up someplace else). In Sections III
and IV we present an approach and an example for creating this vision. In Section
III, we layout a digital business model and in section IV we layout the enabling IT
from a logical architecture, process, organization, and governance standpoint. We
are leveraging an approach developed over the past 20 years at MITs Center for
Information Systems Research (CISR) [MITa] and used by one of the authors (Ali) at
large multi-national enterprises such as Ford, Jaguar Land Rover, Harman
International, US Foods, and W. W. Grainger.

III.

Digital Healthcare Business Model

A. Context Model
The first step in laying out the business model is to create a context model. The
context model puts a boundary on what we are calling our enterprise vs their
enterprise. For this paper, we will take the position of the healthcare provider. The
context model (Figure 1) shows the entities which interface to the enterprise.

Figure 1: Provider Context Model

B. Structure Model
We need the structure of the Provider. In this case, we assume that the provider is a
large healthcare group with divisions consisting of hospitals, labs, pharmacies, etc.
These are shown in Figure 2.

Figure 2: Provider Structure Model

C. Operating Model
Next we need to determine what the MIT CISR calls the operating model, which
describes how processes and data are to be shared across the various divisions of
the enterprise. Note that the decision around process and data sharing is a
business decision, not an IT decision. There must be some business benefit for
sharing beyond savings or synergies in IT because the cost of creating and
maintaining process/data standards is primarily business cost (time, people,
governance, etc.). The operating model is captured as the 2x2 shown below. In this
example, we have assumed that all of the divisions need to share patient data, and
in addition, the hospital facilities (inpatient, outpatient, and emergency) need to
share vendor data to leverage purchases of equipment, material, etc. Since each
facility handles a different aspect of patient care, we do not see a need to share all
processes, but we expect that some subset of processes (ex: patient billing) will be
the same for the inpatient, emergency, and outpatient facilities. Using the 2x2, we
therefore see that we have Coordination (shared data) and Unification (shared data
and shared process) operating models. The definitions of the operating models are
in Appendix A.

Figure 3: Operating Model

D. Core Diagram
The last step is to create a Core Diagram, which captures the functional model of
the enterprise. This diagram will consist of major processes and key interfaces.
While process reference models (ex: APQC) exist, in practice, this model is businessspecific as it needs to capture how business leaders think of their enterprise, using
their terminology. The Core Diagram for this example is shown in Figure 4 below.
As a check, we confirm that the Core diagram provides interfaces for the external
entities in the Context Model (Figure 1) via the Channels, API Services and Payor
Integration functions. Two key processes are Analytics and Medical Records.
Medical Records provides the master data capability needed for the operating
model in Section C. The Analytics function serves as a center of excellence for
coordination and support of analytics capability that is distributed within each of the
other functions. As an example, we have incorporated Episode Analytics [iHTT] in
the model.
Episode Analytics uses an episodedefined as a patient care event that crosses
care settings and timeframes including pre- and post-care, as the unit of analysis.
An episode includes enough services to allow treatment choices and intensity to
be measured and analyzed. Aligning care episode data with traditional and
historical payor data creates standard profiles form comparing costs and outcomes
of various care options. The profiles and comparisons create a framework for valuebased outcome analysis over time [Plummer]. As shown in Figure 4, episode data is
captured at the point(s) of patient care (InPatient, OutPatient, Emergency, Lab,
Pharmacy). This data is integrated with other data, such as Payor data, in Medical
Records. The integrated data is then available to Analytics.

Figure 4: Core Diagram

IV.

Enabling IT Model

A. Application Architecture
The enabling IT model starts with an application architecture (Appendix B and the
right side of Figure 5, example applications from [MITb]).
The application
architecture mirrors the Core Diagram (Figure 4 and the left side of Figure 5), as the
applications enable and enhance the processes expressed in the Core Diagram. Of
course, there are other elements to enterprise architecture (information, servers,
network, security, etc.), however the application architecture has the most direct tie
to the business model, which is why it is the starting point. The applications in the
architecture can be on-premise or cloud-based. For sharing medical records, a
NoSQL database management system is proposed in addition to any legacy or
traditional databases. Per Gartner [Gartnerb, Gartnerc], use cases that involve
combining data from different databases along with real-time data are best
addressed with NoSQL-type databases.

Figure 5: Core Diagram (left) and Corresponding Application Architecture (right)

B. IT Organization
The IT architecture defined above requires an IT organization that is structured to
plan, build, and maintain it. The necessary functions are described below and
shown as an organization chart (Figure 6). The recommendation is that these
functions report directly to the CIO.
End-user Interface: The healthcare applications are ultimately used by end-users
including patients, doctors, nurses, administrators, and suppliers. The End-User
Interface function ensures that these constituents have a voice and a view into the
IT organization. Of course, there are other interfaces as well (ex: the Service/Help
Desk), but this team provides a place to start, especially for conversations about the
strategic use of IT.
Enterprise Architecture: Ensures that the current and future state architecture is
consistent with the strategy and goals of the organization. Architecture includes
the application architecture in the previous section, plus the infrastructure
architecture (desktop/laptop, mobile, servers, storage, network), information
architecture, and security architecture.
Cybersecurity:
Ensures that a comprehensive risk-based approach to
infrastructure, application, and information security is implemented. Provides a
focal point for internal and external audits and control reviews.
Program Management Office:
ensures the success of major development
programs and projects via process, personnel, training, and regular reviews.
Solution Delivery: responsible for the delivery and maintenance of software
applications. Per the next section, this function will be organized to deliver using an
Agile development model, so within the function, we will have sprint teams aligned
against the application architecture described earlier. There will be sprint teams

that work within one layer of the architecture (ex: with one or two applications) but
also teams that can work across multiple layers/applications to create complete
solutions.
Infrastructure & Operations:
responsible for the day-to-day running of
applications, desktops/laptops, mobile, servers, storage, and the network.

Figure 6. IT Department Organization Chart

C. IT Processes
The mission of the IT department is to plan, build, and run the healthcare systems
enabling the enterprise. There are three main processes required to achieve this
mission: Program Management, Agile, and ITIL.
Program Management: processes for program management. Programs consist
of multiple projects that need to be coordinated to achieve an outcome. Programs
require a process distinct from project management, with emphasis on risk
management and governance to ensure success.
Agile: Creating applications across the typical multi-tier architecture shown earlier
requires software development techniques that can handle complexity, incomplete
and/or evolving requirements, fast check and adjust cycles.
Agile software
development, which has been in existence almost 20 years, is the preferred
approach to meet these needs.
ITIL: The IT Infrastructure Library is a set of processes for maintaining and
upgrading systems and software. Chief among these are the Service/Help Desk,
which handles end-user requests and incidents, Incident Management for handling
systems failures and root cause analysis, and change management for making
system changes in a safe and structured manner.
D. IT Project Investment Governance
Maximizing the value of investments requires governance to align business needs
against project investments. This group must (a) set the appropriate budget for IT
projects, (b) select a portfolio of projects from a list of proposals, (c) track project
execution against budget and deliverables, and (d) confirm the realization of
benefits on project completion.

V.

Summary

In Section II, we listed three capabilities that need to be provided in digitalized

healthcare model. Then in Sections III and IV, we laid out an approach and example
to creating this model. The approach is based on research from the MIT Center for
Information Systems Research and experiences of the authors. The table below
links the model features to the desired capabilities.
1
.

Capability
360 view of the patient

2
.

Analytics

3
.

Low-friction interface with

partners

How achieved
The model captures interactions with the
patient via the various channels (in-person and
digital). The data is captured in the underlying
applications as shown in the application
architecture, and shared via a master data
construct.
Analytics capability is specifically called out in
both the Core Diagram and the application
architecture.
There is a portal channel provided as well as a
partner API for sharing medical records.

References
[BCGa] Competing on Outcomes: Winning Strategies for Value-Based Health Care,
Boston Consulting Group, January 2014.
[BCGb] Alternative Payer Models Show Improved Health-Care Value, Boston
Consulting Group, May 2013.
[Gartnera] Business Drivers for Healthcare Provider Information Technology
Decisions, 2016. Gartner, January 2016.
[Gartnerb] Match Use Cases and Capabilites for Operational DBMSs, Gartner, August
2015.
[Gartnerc] A Tour of NoSQL in Eight Use Cases, Gartner, February 2014.
[iHTT] Episode Analytics: Essential Tools for New Healthcare Models, Institute for
Health Technology Transformation, 2014.
[MITa] Enterprise Architecture as Strategy: Creating a Foundation for Business
Execution, Harvard Business School Press, 2006.
[MITb] Trinity Health: Using Digitization, Unification, and Data Analytics to Tame the
Quality and Accessibility Problems of Healthcare, MIT Sloan School Working Paper
4960-11, December 2011.

[Plummer] Episode Analytics: A Healthcare Information Integration Platform, March

2016. Unpublished presentation by Eric Plummer.

Appendix A: Operating Model Definitions [MITa]

Diversification (low process commonality, low data commonality): business
units have limited commonality across customers, suppliers, and/or products. There
may be some shared services (ex: human resources, and IT infrastructure such as
email and scheduling.
Replication (high process commonality, low data commonality): operations
are standardized, but business units are autonomous. Competitive advantage is
repeatable processes vs shared information.
Coordination (low process commonality, high data commonality): business
units must share customer, supplier, and/or product data, but execute different
processes with that data.
Unified (high process commonality, high data commonality): business units
are interdependent, so are organized around standard and shared processes and
data.

Appendix B: Application Architecture