Open Digital Platforms in Health Care
Thirty Seventh International Conference on Information Systems, Dublin 2016 1
Open Digital Platforms in Health Care:
Implementation and Scaling Strategies
Freie Universität Berlin
Garystr. 22, 14195 Berlin
Freie Universität Berlin
Boltzmannstr. 20, 14195 Berlin
We investigate strategies to implement and scale digital platforms in highly-regulated
settings such as health care. Despite considerable research efforts, these scaling
dynamics are still not well understood. Based on a qualitative, comparative study (U.S.
and Germany) of six digital health care platforms, we suggest two feedback cycles that
contribute to explaining the arising difficulties: First, we observe that openness on code
and content layers fuels platform growth as suppliers, healthcare providers, insurances,
and patients are more likely to use and contribute to the platform. In opposition, risks
such as a lack of or uncertainty about regulations prompt the provider to close the
platform to uphold control which in turn reduces the benefits for potential suppliers. We
further discuss scaling strategies when multiple user groups are involved.
Keywords: Digital health platform, implementation and scaling strategy, openness
Platforms leverage software code that other companies can build on and that consumers can use (Gawer
and Cusumano 2008). This has become the template for the establishment and long-term success of
software-based companies, startups and established businesses. Many digital platforms have emerged
over the last years in different industries. Some scaled exponentially – like Uber. While Uber was
occasionally held back (Freier 2015), it has constantly grown its population of users and services.
Launched in 2010 in the U.S., Uber now attracts around eight million users in 60 countries and has added
multiple services like carpooling and food delivery. This is hardly plain luck. To achieve that growth,
network effects are required that attract sufficient numbers of users, both on the supply and demand side
(Gawer 2014). To attract both sides, platform provider’s may try to tune their implementation and scaling
strategy, i.e. by identifying the need for interoperability or openness (Eisenmann et al. 2009) and
understanding and caring for the needs of customers and suppliers (Hagiu and Rothman 2016; van
Alstyne et al. 2016). The peak in attention for platform strategies shows the importance of this topic.
Surprisingly, we can only observe first efforts to implement and scale digital platforms in health care.
While Apple Health and Google Fit have begun to resurrect the industry (Chen 2014), vivid examples of
platforms that affect the everyday, regular treatment processes of patients are still rare. As Google noted in
2011 when it shut down its ‘Health’ platform, many companies ‘haven’t found a way to translate that
limited usage into widespread adoption in the daily health routines of millions of people’ (Google 2011). In
addition, Google’s and Apple’s attempts can be described as at least partially closed in that they subtly
exclude many parties from owning, providing, using, or contributing to the platform (Eisenmann et al.
2009). Open platforms, defined by the absence of restriction for participation, offer a promising
Page 1 of 12
Open Digital Platforms in Health Care
Thirty Seventh International Conference on Information Systems, Dublin 2016 2
alternative. Their architecture builds on components that have well-defined, published interfaces (API’s)
allowing for interconnection and use in ways other than as originally implemented or intended (Estrin and
Sim 2010). At least theoretically, this makes them an engine for health care innovation (Estrin and Sim
2010). Despite their potentials, we are still awaiting such ‘open’ platforms that overcome the traditional
model with episodic care in clinic and hospital settings which is suboptimal for overcoming for instance
chronic diseases. Implementation rates of IT-based solutions fall short in many major countries such as
the U.S. and Germany (Lluch and Abadie 2013). These examples show the preliminary nature of and the
difficulties to implement and scale open digital platforms in health care.
From the literature in health information systems, we begin to understand that implementing and scaling
a digital platform – especially in highly-regulated environments such as health care – is a difficult task. It
requires to resolve tensions around autonomy-related benefits and control (Eaton et al. 2015). While
autonomy of users without centralized control may result in difficulties for the provider to enforce his or
her own vision, find a viable business model, and meet the regulatory requirements, too strict control can
discourage potential users and thus prevent the platform from scaling. The question of control is
particularly challenging in health care. At worst lives are at risk when a platform fails. There is a need for
rigid quality control (Thorseng and Jensen 2015), security and privacy (Huckman and Uppaluru 2015),
and certification (Diamond and Shirky 2008). In extension to other markets, a health care platform must
thus sensibly balance the interests and goals of multiple parties as well as underlying issues of
accountability and liability (Constantinides and Barrett 2014). Thus, it is necessary for platform providers
to carefully consider the type and degree of openness when implementing and scaling a digital health
The literature on health information systems has produced a rich contextual understanding of how and
why implementing and scaling IT-based solutions in health care is difficult and how adoption may be
spurred (Aanestad et al. 2014; Aanestad and Jensen 2011; Braa et al. 2007; Grisot et al. 2014; Hanseth and
Aanestad 2003; Hanseth and Bygstad 2015), yet it says relatively little about the particular characteristics
of and challenges in platform-based settings. Thus, it tends to underplay the growing complexity arising
from more and more differentiated activities and actor constellations in the health care value creation
process. The novelty of our study lies in our focus on platforms that are targeted toward companies that
develop medical applications (supply-side users) for usage by health service providers, insurances, and/or
patients (demand-side users). This presents one very recent and promising form of service delivery in
health care, enabled by the growing availability of easy accessible health care API’s (Huckman and
Uppaluru 2015)1. Taking the scant knowledge on these issues as our point of departure, we ask:
How and by which strategies do actors implement and scale open digital platforms in highly-
institutionalized environments such as health care?
To shed light on this issue, we subscribe to a sociotechnical view on platforms (Eaton et al. 2015). That
means we consider platforms as mutually shaped by social and technical elements (Winter et al. 2014).
Our perspective – generally very close to a digital infrastructures viewpoint – considers platforms as
evolving sociotechnical systems (Tilson et al. 2010). We focus on bottom-up efforts as they often leverage
existing knowledge better and are more responsive to local needs than large-scale implementation
projects, hence increasing their odds of success (Aanestad and Jensen 2011; Constantinides and Barrett
2014; Hanseth and Bygstad 2015). Based on these premises, we are currently conducting an exploratory
multiple case study (Eisenhardt 1989; Yin 2013). We have chosen the U.S. and German health care
industry for a comparative study (for reasons and details see below). By doing so, we aim to investigate
how to design and position digital health care platforms that scale despite challenging institutional
conditions. Our preliminary results suggest that: Firstly, platform providers are faced with both a positive
cycle of network effects – fueled by incentives to open up to suppliers – that adjusts the establishment of a
platform as well as a countervailing risk cycle caused by the highly regulated and institutionalized
environment. This risk circle favors platform’s closeness in the sense that it rejects the interference of non-
core suppliers in the platform creation process, thereby potentially impeding its establishment. Secondly,
conceivable scaling strategies vary by the participating groups that become directly targeted and can be
1 Albeit representing another promising direction for the study of digital health care platforms, our focus is not on
health information exchanges (HIE) and other regional or national data exchange efforts (see e.g. Demirezen et al.
2016; Thorseng and Jensen 2015; Winkler et al. 2014; Yaraghi et al. 2015)
Page 2 of 12
Open Digital Platforms in Health Care
Thirty Seventh International Conference on Information Systems, Dublin 2016 3
divided into push and pull strategies, i.e. strategies that address the primary target group (push) and those
addressing other groups that affect the primary target group (pull) – a well-known concept from logistics,
supply chain management and marketing (see e.g. Hinkelman 2005).
To arrive at these contributions, this article proceeds as follows. Section 2 presents the theoretical
background on open digital health care platforms. In section 3, we introduce our research design. Section
4 shows preliminary results. Section 5 concludes, shows limitations of this study and introduces next steps
in exploring this research area.
Open Digital Platforms in Health Care!
Digital platforms can be distinguished from many traditional IT-based solutions which do not have built-
in, by-default capabilities for supply-side user extension and commercialization (Tilson et al. 2010, 2013).
Given the importance and ubiquity of the phenomenon in the digital era, both economics and engineering
have picked up on and theorized about it (Gawer 2014). The engineering view suggests that platforms
consist of a core and modules that interact via standardized interfaces (Tiwana et al. 2010). Accordingly, a
platform acts as a building block (Baldwin and Woodward 2008). From here we can see how standardized
interfaces allow for dynamics and scale in the periphery while the core can be optimized for stability and
reliability. This helps to explain innovation in platform ecosystems (Tiwana 2015; Tiwana et al. 2010).
Economists have suggested a second view on platforms (Gawer 2014). Here, platforms are seen as
competing in two- or multi-sided markets (Rochet and Tirole 2003). The platform acts as an intermediary,
spanning boundaries between at least two groups of actors, ‘complementors’ (which we will call suppliers
within this article) and ‘users’ (van Alstyne et al. 2016). This view creates sensitivity for the importance of
“getting both sides on board” in platform establishment and scaling processes (Rochet and Tirole 2003).
However, we suggest that platform providers in the health care sector tend not to act as classical
intermediaries in multi-sided markets. Platform providers are often main contributors to the platforms as
well as their financiers, bringing further user and suppliers together for their own sake (e.g., to achieve a
competitive advantage by offering the platform).
Generally, scaling refers to expanding an IT-based solution to support a growing population of users and
services (Monteiro 1998). For digital platforms, scaling requires an individual level adoption process by
two or more groups of actors. This necessitates structures that can accommodate both continuously
increasing numbers of users and suppliers, i.e. growing within and out of existing target groups, and
offering new services. Hence, the startup problem, i.e. attracting early users or “bootstrapping” a solution
(Hanseth and Lyytinen 2010), becomes more complex. Existing approaches, i.e. designing for initial
usefulness, mutual learning, and complexity management (Hanseth and Aanestad 2003; Sanner et al.
2014), may provide some guidance but they need refinement. For instance, incremental stakeholder
mobilization, as suggested by Aanestad and Jensen (2011), may be difficult as multiple sides need to be
convinced simultaneously. Therefore, it may be necessary to “push” or “pull” particular groups of users in
One important parameter in implementing and scaling a digital platform is its degree of openness.
Openness in platform-based contexts means access to at least three important layers: Code, content, and
physical infrastructure (Lessig 2001). We assume as known physical infrastructure and briefly discuss the
other two. On the code layer, openness refers firstly to questions of participation in the platform itself and
secondly to restrictions to innovate on top of the platform (Eisenmann et al. 2009). Complete openness on
all levels is rare. Linux may be mentioned as an example. A more common situation is some degree of
closeness of the platform core, i.e. ownership and provisioning may be restricted. Only a limited circle of
people have access. For Apple Health, the platform itself is for instance owned and provided by a single,
privately-owned entity. This is a potential source of controversy in health care given different opinions on
whether and to what extent health care is a private or public good (Constantinides and Barrett 2014). In
contrast, we also see more participatory approaches where the platform creation process itself is jointly
promoted by multiple parties, e.g. joint ventures, project-based organizations, or consortia. This can also
help to distribute the share of investment costs across multiple parties, integrate different knowledge, and
reduce the risk of failure (Berggren et al. 2011; Hanseth and Bygstad 2015; Sydow et al. 2012). Yet, it also
comes with a number of challenges such as ‘lowest common denominator’-solutions, slow progress, and
conflicts of interest (Eisenmann et al. 2009). The second set of code-related questions concerns
innovations on top of the platform, i.e. ‘how to handle complementors?’ (Eisenmann et al. 2009). As an
Page 3 of 12
Open Digital Platforms in Health Care
Thirty Seventh International Conference on Information Systems, Dublin 2016 4
example: In contrast to Apple, Google has historically provided suppliers a little more freedom in terms of
building apps (e.g., upload and certification is less regulated). Multiple ‘boundary resources’ appear which
represent potential control points for negotiating and tuning the relationship between platform provider
and suppliers (Eaton et al. 2015; Ghazawneh and Henfridsson 2013). One question is the type of interfaces
for building new applications: Should they be public or private; free or for charge; what level of access is
provided (Davenport and Iyer 2013)? All of these areas potentially restrict access for some suppliers. On
the content layer, openness relates to who can access what content, add content (see e.g. Wikipedia) and
with what ease data can be transferred to other contexts. In a sense, this goes beyond questions of
technical interoperability as discussed above but also taps into questions of semantic and process
interoperability. Dictionaries, glossaries, and ontologies try to standardize terminology so that it can be
used for treatment and decision support in multiple contexts. Also patients may want to access and use
their personal data in multiple contexts and in multiple parts of the health care system (Estrin and Sim
2010). Altogether, access to code, content, and physical infrastructure may be open or restricted in
multiple ways, depending on the access granted to ownership and provisioning of the core as well as
degrees of freedoms to innovate on top of it and to use the platform in different ways.
Figure 1. Elements and demand-sided mechanisms of digital health care platforms
Depending on the number of stakeholders participating in the platform, platforms can be one-sided, two-
sided, or even multi-sided (Yaraghi et al. 2015). In the empirical analysis, we focus on two-sided platforms
(e.g., platforms providing apps by developers to patients). We hereby suggest that the demand side of a
health care platform can be segmented into three broad user groups (see Figure 1): Patients, health service
providers like hospitals and physicians, and payers. Typical payers are – depending on the national health
care system – statutory and private health insurances as well as employers. Stakeholders can also take a
dual role, for instance if an organization is responsible for both health service delivery and its financing
(see cases of health care organization in the U.S.). The platform connects these stakeholders with
companies on the supply side that provide medical services or apps (suppliers), e.g., genomics labs or
providers of clinical decision support. Not in all cases do all the mentioned stakeholders participate in a
single platform. We however assume that different user groups are in specific reciprocal relationships to
each other (e.g. providers offer treatments for patients), influencing conceivable scaling strategies by
fulfilling the needs of each group by the platform.
Altogether, our interest in this study is how platform providers implement and scale open digital health
platforms. To this end, we adopt a sociotechnical view on platforms (Eaton et al. 2015), acknowledging the
Tra dit i ona l% model
Scali ng stra teg ies
Demand)for bettertreatment /)payment
Page 4 of 12
Open Digital Platforms in Health Care
Thirty Seventh International Conference on Information Systems, Dublin 2016 5
importance of actors, structures, technologies, processes, and their mutual interdependence (Winter et al.
2014). This allows considering tensions between openness and control in the process of implementing and
scaling digital platforms and debates over ‘control points’ (Eaton et al. 2015). Platform openness involves
challenging questions on multiple levels such as whether and to what extent the platform architecture
should allow user to interoperate. Platform openness in a technical and semantic sense is desirable for the
user and should also profit the entire health system (Estrin and Sim 2010). It may also be desirable for the
provider as long as it attracts users and creates network effects (Eisenmann et al. 2009). Yet, openness
may also create challenges as whether the user stays with the platform and whether the provider can
create a viable business model. Furthermore, it is important that legal, data security, privacy, and quality
control requirements are addressed. Therefore, openness becomes a strategic consideration. In a sense,
platforms can be understood as a centralized way of providing capabilities; they unify important control
rights in the hands of the platform provider. But, it is far from clear how health care actors organize the
process of creating a new digital platform: Who is influencing and sponsoring the newly emerging
platform and what role do users play in aligning the development of the platform with his/her own
interest? The empirical analysis should enable to gain some insights into the implementation and scaling
strategies that actors use to create digital health platforms.
This empirical study focuses on multiple exemplary cases within the German and U.S. health care system,
applying a qualitative research design. While our review of the existing literature showed that there are
many considerable efforts to understand implementation and scaling in health care, they have rarely
focused on digital health platforms as conceived here as innovation-promoting platforms that can be
extended via publicly available API’s (Estrin and Sim 2010; Huckman and Uppaluru 2015). An exploratory
and comparative multiple case study approach is appropriate for our aim to add insights to this topic
because it allows analyzing the phenomenon in its real-world context and to advance mechanisms and
strategies of scaling (Eisenhardt 1989; Henfridsson and Bygstad 2013).
Research contexts and comparative design. Our aim is to compare efforts in Germany and the U.S.
Comparing two different health care systems is fruitful because the institutional conditions and
regulations differ. The German health care sector is based on the general model of solidary financing
(citizens are obliged by law to get health insurance; insurers are independent from service providers). It is
especially characterized by its traditional long-grown structures and strong regulation (Klöcker et al.
2015). Yet, for about 10 years, new entrants such as internet-based platforms and digital health startups
try to enter the market, providing innovative platform solutions and enriching the market of more
traditional, internal IT infrastructures like electronic health record (EHR) systems in hospitals. In
contrast, the U.S. health care sector provides a generally more market-oriented environment in which
different approaches compete on different levels (Winkler et al. 2014). In addition, efforts to establish
open digital health platforms are generally more progressed than in Germany. First platform battles are
starting to arise, compromising different standards such as HL7 v2, v3, and HL7 FHIR (Fast Healthcare
Interoperability Resources; see Bender and Sartipi 2013). In both systems, markets are highly regulated by
the state, but due to the different general approaches the U.S. system can be classified as less regulated
than the German one. Contrasting efforts in both countries potentially helps to better understand the
institutional conditions in which efforts to implement and scale digital health platforms nest and unfold.
Sampling strategy. Case sampling represents a challenge as the phenomenon of open digital health
platforms is still infant. Many efforts are in their beginning and large private players (e.g., Google and
Apple) who recently entered the market are reluctant to share first-hand information on their strategy. As
we believe in the potential of bottom-up initiatives (Hanseth and Bygstad 2015), we have selected six
promising bottom-up initiatives, representing forerunners in the U.S. and Germany. Within our focus on
digital health care platforms, we have selected cases based on two additional criteria: (1) whether the
platform provider is an established player or a new entrant, and (2) the country (reasoning see above). We
did so because of an interesting tension that is (almost) exclusive for health care organizations: Whereas
established players (incumbents) often face considerable inertia in overcoming existing routines and
structures (Leonard-Barton 1992; Sydow et al. 2009; Tripsas and Gavetti 2000), the knowledge of existing
institutional structures and processes may help them to navigate through the complex regulated landscape
of health care. In contrast, new entrants may be less burdened with legacy processes and structures and
Page 5 of 12
Open Digital Platforms in Health Care
Thirty Seventh International Conference on Information Systems, Dublin 2016 6
may thus be abler to disrupt the rigid institutional environment. In addition, incumbents have the
advantage of the existing user network while probably facing greater difficulties to attract new users.
In Germany, we have selected three initiatives that are both different and extreme: Athena, a large hospital
chain, currently establishes a cloud-based health services platform for patients and physicians in
collaboration with startups. St. Mary’s, a large research hospital, plans to create a cloud-based healthcare
platform to connect users in its clinics and beyond. The startup Skyaid has launched a pilot for a cloud-
based Platform-as-a-Service (PaaS) platform. The German examples show an early, but promising stage of
health care platform development. In the U.S., we have selected three more advanced initiatives which we
consider as relevant (for an overview see Table 1). HSPC, the Healthcare Services Platform Consortium, is
health care provider-led organization striving for the delivery of a platform that supports innovative
healthcare apps to improve health and health care (HSPC 2016). SMART, a Boston-based initiative, has
created a promising app platform that enables applications to run on systems which have implemented the
SMART on FHIR specification accessing existing EHR systems or the like (Mandel et al. 2016). Carebox is
a U.S.-based PaaS-offering to create health care applications that run in a cloud environment. A more
detailed description of each of these cases is included in the findings section.
2. St. Mary’s University†
5. Smart Health IT
† We disguised the names of these cases as interviewees did only agree to provide access to information, which are
partly gauged as relevant for competition, if anonymity was guaranteed.
Table 1. Case sampling and interviews
Data collection. Our data collection started in 2015. For triangulation purposes, we rely on three main
data sources: First, we conducted first-hand interviews with different actors (platform providers, health
service providers, payers, other context-specific actors such as representatives of industry associations),
participating in emerging innovative health care platforms. Second, we analyzed different written
materials such as press releases, newspaper articles, blogs and position papers from and about the selected
platforms and, third, we participated in events (e.g., entrepreneurship summits, startup pitches, fairs,
meet-ups, discussions). At each event, various ad hoc interviews took place. So far we have conducted 29
formal interviews (see Table 1 for case split), took part in around 30 field events focusing on the
digitalization of health care and analyzed around 50 documents. Further interviews are scheduled.
Our data analysis follows an abductive approach (Locke et al. 2008). We have used both open and axial
coding to induce categories from the documents, transcribed interviews, and field notes, screening our
data for practices, drivers and challenges related to platform implementation and scaling. As a first step,
we coded the interviews with paraphrases close to the original data (e.g., ‘sensing conflicting interests’,
‘building coalitions’, ‘opening up to users’, ‘re-focusing’, ‘exerting control’, ‘taking advantage of
regulations’). For instance, we coded the statement “I try to hook up the right people to make decisions on
these draft standards” by a sponsor of HSPC (case 4) as ‘building coalitions’. Then, we started to aggregate
categories to a more abstract level (e.g., ‘fueling the positive cycle of network effects’, ‘fueling the risk
cycle’) (Gioia et al. 2012). By various iterations we strengthened our preliminary findings about
contributors to successful platform establishment and scaling strategies.
Case Description and Preliminary Findings
Table 2 characterizes the platforms in terms of their sides, platform openness on the code, content, and
physical infrastructure layer, as well as their scaling status. The analysis shows that while all of these
platforms are similar in that they bring together suppliers and demand-side users, the demand side varies
considerably regarding which user groups’ needs are or will be addressed. Also, while most of these cases
are committed to “openness” on many important layers, they have different approaches to platform
ownership, reflecting different levels of openness to participate in the platform development. To compare
Page 6 of 12
Open Digital Platforms in Health Care
Thirty Seventh International Conference on Information Systems, Dublin 2016 7
these cases regarding their implementation and scaling strategy, we must critically reflect their scaling
situation against the background of the individual case (country, established/entrant, sides, openness). In
this research-in-progress we can – based on the sample – only present relatively high-level observations
but our future strategy is to narrow down the sample (i.e., one-by-one) to limit the variance across cases.
Athena (Case 1, GER)
Sides: Athena aims to establish a two-sided platform which is designed for future expansion on the demand
side. The primary target groups on the demand side are patients and secondary collaborating physicians in
outpatient care. Startups are the main supplier. The platform aims to foster innovation and to promote the
long term goal of establishing an openly documented data exchange standard between hospitals and suppliers,
potentially usable also by other hospitals. Athena acts as the platform provider and also as its financier.
Code: Athena draws on IHE / HL7-based middleware and plans to open up to suppliers via a FHIR gateway.
Content: Easy access to content for patients is one of the platform’s main goals.
Infrastructure: No new physical infrastructure; usage of the German Telematics infrastructure is intended.
Scaling: The hospital chain has already begun to gather startups developing relevant apps in an accelerator
program. The platform is now in a development stage and will offer different services that are extended step-
by-step (first mainly in-house information to patients, later including services by suppliers). First services are
patient information display, appointments, and potentially medication plans.
St. Mary’s (Case 2, GER)
Sides: The platform is supposed to connect two sides. Healthcare providers, i.e. clinical users, represent the
demand side. Decision support vendors etc. will represent the supply side. The aim is firstly to automate
patient documentation and secondly to enable further value-creating processes such as better diagnoses.
Code: Commitment has been signaled to support HL7 and other international, non-proprietary standards.
Content: Content-wise standardization is planned to consistently “track quality indicators”.
Infrastructure: As for Athena, no separate physical infrastructure is planned.
Scaling: The platform is currently in a conceptual stage. Later, a step-wise roll out is planned. The first
clinical users will be intensive care units, anesthesia, surgery, and other counseling units (e.g., cardiology).
The potential future user network also includes outpatient clinics, family doctors, physiotherapists,
nutritionists, nurses, and case managers, among others. So far this has been done within a closed, clinic-
internal network of participants and no suppliers are on-boarded so far.
Skyaid (Case 3, GER)
Sides: The platform is two-sided. It intends to attract suppliers and companies to create apps which are then
deployed on the Skyaid platform for usage by clinical users or patients.
Code: The code of the platform is based on web technology and HL7 FHIR interfaces. It aims to translate
conflicting standards into a single one, therefore providing open interfaces to suppliers on the code level.
Content: The platform strives for content-wise standardization by the usage of FHIR-based messaging. Easy-
to-use web technology is another aspect to make the content accessible.
Infrastructure: The platform is hosted in a secure, trusted environment; other hosting options are planned.
Scaling: Skyaid is currently in pilot stage and has completed several use cases funded by a government grant.
As one of the first use cases, the platform has enabled a cloud-based data exchange between different
healthcare providers. Skyaid currently refines its platform services in a network of initial users and suppliers.
During this phase, the platform is closed due to control issues with further potential suppliers, but opening it
up to developers with the aim to generate network effects is planned in the near future.
HSPC (Case 4, U.S.)
Sides: There are currently two sides involved in the platform. Suppliers (e.g., startups) provide apps and
services. Clinical users run them on the HSPC platform (i.e., using the SMART standard) to enrich their EHR
system data, run them in a standalone fashion, or advice a clinical decision support mechanism.
Code: The code of the platform is open source. It builds strongly on available web technology and FHIR.
Suppliers can access it via a code repository. New apps that shall be displayed in the HSPC gallery undergo a
review process. A full-blown “app store” with a sophisticated certification process is planned.
Content: One important goal of the HSPC initiative is "true semantic interoperability“. The content shall be
standardized by using LOINC and SNOMED. HPSC is also collaborating with the Open CIMI initiative (CIMI
2016), which has created more than 5,000 clinical data models.
Infrastructure: The HSPC platform runs on public internet infrastructure or uses the clinics’ own networks.
Scaling: Several demo applications have been presented at HIMSS 2015 and 2016 conference (e.g., Bilirubin
risk chart, pediatric growth chart). We could identify around ten startups that are currently working with
HSPC to create apps. Some of these apps are already in use at client sites. The user side is leaning toward large
health service providers. The platform creation process is organized as a consortium; it is generally open to
everybody but discriminatory membership fees apply to engage in the consortium.
Page 7 of 12
Open Digital Platforms in Health Care
Thirty Seventh International Conference on Information Systems, Dublin 2016 8
SMART (Case 5, U.S.)
Sides: The platform is two-sided; the demand side is split into two customer segments. Suppliers create apps
(e.g., for clinical care, patient education, genomics). These apps are targeted either to health care providers or
Code: A code repository allows suppliers to create apps, which are included in the app gallery after a review.
Content: Content and data models shall be standardized by using FHIR resource profiles. One important
premise of the initiative is that content should be easily accessible via web interfaces.
Infrastructures: The platform runs on public web and/or clinic-internal infrastructure.
Scaling: SMART has demonstrated the first six prototypical apps at HIMSS conference in 2014 (Mandel et al.
2016). E.g., for personalized medication, patient information visualization, cardiac risk, and some other use
cases. In 2016, the app gallery has grown to 22 apps. Some of these apps are already in regular use at Boston
Children’s hospital and other sites. The platform creation process is run out of Boston Children’s Hospital and
Harvard Medical School. Several healthcare providers, vendors, and other firms sponsor the development.
Carebox (Case 6, U.S.)
Sides: The platform is two-sided. It allows suppliers to create apps which are then deployed on the platform
and can be used by clients as a backend, clinical data repository, or in integration scenarios.
Code: The platform code is based on FHIR for internal and external data model as well as messaging. It
provides relational storage for FHIR resources with use of open source FHIRbase project and supports HL7
v2 messaging, CDA/CCD documents, etc. Basic usage is free; enterprises must acquire a license.
Content: Data models are based on FHIR profiles, a relatively new way of representing medical data.
Infrastructure: The Carebox platform is hosted in a cloud environment.
Scaling: The platform is currently in its launch. The private firm collaborates heavily with open initiatives
such as the HL7 FHIR work group, project Argonaut, and HSPC. Opening the platform up on the code level
and collaborating with other initiatives is a way to attract potential customers (e.g., clinical users). It
demonstrates the firm’s commitment, credibility, and capability. This is particularly important as the firm
cannot yet build on an existing customer base (although several pilots are underway).
Table 2. Platform design, openness, and scaling efforts of the different platform initiatives
Initial Characteristics of Scaling Strategies for Health Care Platforms
Building on the insight that incremental stakeholder mobilization is important for large-scale IT imple-
mentations (Aanestad and Jensen 2011), our analysis suggests that platform providers can target potential
groups participating in a platform via a push- or pull-strategy (see also Figure 1). By a push-strategy, the
platform provider addresses one of the platform-user groups (payers, health service providers, or patients
– depending on the platform) directly as the primary target group. For instance, St. Mary’s, the German
research hospital, aims to scale within a closed set of hospitals while targeting the clinics themselves, but
initially no other user groups like patients. Secondly, by a pull strategy, a platform provider aims to attract
a certain platform-user group by addressing other groups which influence the targeted group in the sense
of the provider by a spillover effect. For instance, Athena (case 1) both tries to offer patients a better
service and to improve the quality of their stationary treatment to animate referring ambulatory
physicians to consider Athena’s hospitals in the highly competitive German hospital market. On the other
hand, they also plan to directly address referrers with the aim to attract more stationary patients (German
patients have the right to choose their hospitals freely). Pull strategies are multidimensional and address
by definition at least one user group less than the number of groups participating in the platform.
Two Feedback Cycles Influencing Platform Establishment and Scaling
To summarize major scaling dynamics in the cases, we suggest two feedback cycles which are important
for the establishment of health care platforms: First, the platform’s openness or closeness, which also
represents the level of control exerted by the platform provider, influences a positive cycle of network
effects. Second, the need to comply with regulatory requirements triggers a counterbalancing risk cycle.
First, the degree of platform openness and closeness mirrors the tension between autonomy and control
of each platform. Especially the more advanced U.S. cases show that the more open a platform is, the
higher is the probability that other organizations will build services on it which increases usage and thus
enables network effects to establish the platform (see also Eaton et al. 2015). For instance, SMART (case
5), has been fairly successful in attracting suppliers to its platform by drawing on openly available web
technology. This in turn resulted in a number of easy-to-use and useful medical apps, which has increased
the acceptance of the platform and directed further attention to it. The German hospital Athena (case 1)
Page 8 of 12
Open Digital Platforms in Health Care
Thirty Seventh International Conference on Information Systems, Dublin 2016 9
attempts to pursue a similar path, i.e. drawing on open standards and interfaces. This in turn has already
helped them to recruit several startups that aim to test their services in Athena’s hospitals. Due to the use
of open standards, suppliers do not fear lock-ins and high switching costs, adding to their willingness to
contribute to the platform. We call this the positive cycle of network effects.
Second, a platform needs to cope with a lack of or conform to existing regulations in the health care field.
This includes compliance to national and professional laws. For instance, all German cases stated that they
profit from their long-standing experience (e.g., Skyaid’s CEO works in health IT for 15 years) with
German regulatory authorities, e.g. in handling data security or certification issues. Nevertheless, handling
these regulatory issues is time-consuming and costly for the platform providers. Therefore, a lack of or
uncertainty about regulations can trigger a countervailing tendency: Due to the overly strict interpretation
of existing rules, e.g. regarding data security which is not adhered by all potential suppliers, and rigid
habits within highly-regulated environments, we observed that platform providers tend to establish
platforms – if at all – that ensure them to stay in control, especially in the pilot- and rollout phase
(German cases 1 and 3). That makes it unattractive for companies to engage in the platform as it favors
slow movement and risk aversion. While this tendency was less pronounced in the U.S. with some crucial
regulations in place, here the problems had already shifted toward more specific strategic ones, e.g. the
risky decision whether to focus on simple or more complex use cases. For instance, one startup that has
previously worked with HSPC noted, “where I’m disagreeing is … how they prioritize what, how fast they
are moving” (case 4). In all these cases, network effects slow down or come to a halt. Also, the rise of
different initiatives fragments national platform landscapes. This prevents stakeholders from engaging in
a particular platform as they fear losing their investment (sunk costs) if they chose one that does not scale.
We label this as the counteracting cycle of risks for as well platform providers as for stakeholders.
Concluding Remarks and Next Steps
Our aim in this paper was to start a debate on how and by which strategies actors implement and scale
open digital platforms in highly-institutionalized environments. In contrast to other sectors, so far neither
in the U.S. nor in Germany a platform provider was able to establish a field-wide digital health care
platform. Whereas the establishment of a platform requires a positive cycle of network effects, this cycle is
countervailed in health care: Opening platforms up to suppliers comes with losses of control for the
platform provider. This creates a difficult challenge to align with institutional requirements (e.g., in regard
of national standards and laws). Moreover, the institutional setting often prohibits offering entirely open
platforms (that do not in some ways restrict the who, how, and on what level access is granted). In
consequence, a vicious risk cycle emerges that prevents platforms from scaling and slows down or hinders
So far, the challenge of integrating data across multiple sources like care providers and patients stays
unsolved, though initiatives that aim for more open platforms are coming up both in the U.S. and in
Germany. Our study indicates the significance of a platform design approach that is sensitive to the
preferences of different user groups and that builds on deep knowledge about the institutionalized laws,
regulations, and habits of the field.
Although our analysis revealed preliminary drivers and challenges of platform implementation and sca-
ling, our research is ongoing and provisional. First, despite our efforts to triangulate the data by using
different sources, our method of data collection and analysis may be biased by the inclinations of
interviewees and interviewers. We also only considered a limited number of cases in two specific national
contexts. Second, we do not claim that our findings are exhaustive. Further drivers (e.g., impulses by
politics, other national drivers) and challenges (e.g., resource shortages, power dynamics, and path
dependencies) must be considered as additional or even alternative explanations. Earmarked for future re-
search are multi-stakeholder, processual, real-time observations of successful and failed attempts to create
platforms (Langley 1999; Langley et al. 2013). We hope that this article animates and guides such work.
We thank Stefan Klein and Martin Gersch as well as the two anonymous reviewers and the associate editor
of the 2016 International Conference on Information Systems for their very helpful comments on earlier
versions of this paper. Daniel Furstenau is grateful for his support by Freie Universität Berlin within the
Excellence Initiative of the German Research Foundation.
Page 9 of 12
Open Digital Platforms in Health Care
Thirty Seventh International Conference on Information Systems, Dublin 2016 10
Aanestad, M., and Jensen, T. B. 2011. “Building Nation-wide Information Infrastructures in Healthcare
through Modular Implementation Strategies,” Journal of Strategic Information Systems (20:2), pp.
Aanestad, M., Jolliffe, B., Mukherjee, A., and Sahay, S. 2014. “Infrastructuring Work: Building a State-
Wide Hospital Information Infrastructure in India,” Information Systems Research (25:4), pp. 834–
van Alstyne, M. W., Parker, G. G., and Choudary, S. P. 2016. “Pipelines, Platforms, and the New Rules of
Strategy,” Harvard Business Review (94:4), pp. 54–63.
Baldwin, C. Y., and Woodward, J. 2008. “The Architecture of Platforms: A Unified View,” Working Paper,
HBS Finance Working Paper No. 09-034, (doi: 10.2139/ssrn.1265155).
Bender, D., and Sartipi, K. 2013. “HL7 FHIR: An Agile and RESTful Approach to Healthcare Information
Exchange,” in 2013 IEEE 26th International Symposium on Computer-Based Medical Systems
(CBMS), pp. 326–331.
Berggren, C., Bergek, A., Bengtsson, L., Hobay, M., and Söderlund, J. 2011. Knowledge integration and
innovation: Critical challenges facing international technology-based firms, Oxford: Oxford
Braa, J., Hanseth, O., Heywood, A., Woinshet, M., and Shaw, V. 2007. “Developing Health Information
Systems in Developing Countries: The Flexible Standards Strategy,” MIS Quarterly (31:SI), pp. 381–
Chen, B. X. 2014. “Apple Unveils New iOS and Mac Software at Conference,” New York Times, New York,
CIMI. 2016. “Clinical Information Modeling Initiative,” (available from: http://www.opencimi.org/;
retrieved September 7, 2016).
Constantinides, P., and Barrett, M. 2014. “Information Infrastructure Development and Governance as
Collective Action,” Information Systems Research (26:1), pp. 40–56.
Davenport, T. H., and Iyer, B. 2013. “Move Beyond Enterprise IT to an API Strategy,” Harvard Business
Review, (available from: https://hbr.org/2013/08/move-beyond-enterprise-it-to-a; retrieved
September 6, 2016).
Demirezen, E. M., Kumar, S., and Sen, A. 2016. “Sustainability of Healthcare Information Exchanges: A
Game-Theoretic Approach,” Information Systems Research (Article in Advance).
Diamond, C. C., and Shirky, C. 2008. “Health Information Technology: A Few Years of Magical
Thinking?,” Health Affairs (27:5), pp. 383–390.
Eaton, B., Elaluf-Calderwood, S., Soerensen, C., and Yoo, Y. 2015. “Distributed Tuning of Boundary
Resources: The Case of Apple’s iOS Service System,” MIS Quarterly (39:1), pp. 217–243.
Eisenhardt, K. M. 1989. “Building Theories from Case Study Research,” Academy of Management Review
(14:4), pp. 532–550.
Eisenmann, T. R., Parker, G., and van Alstyne, M. 2009. “Opening Platforms: How, When and Why?,” in
Platforms, Markets and Innovation, A. Gawer (ed.), Cheltenham, UK: Edward Elgar, pp. 131–161.
Estrin, D., and Sim, I. 2010. “Open mHealth Architecture: An Engine for Health Care Innovation,” Science
(330:6005), pp. 759–760.
Freier, A. 2015. “Uber Usage Statistics and Revenue,” (available from:
http://www.businessofapps.com/uber-usage-statistics-and-revenue/; retrieved February 9, 2016).
Gawer, A. 2014. “Bridging Differing Perspectives on Technological Platforms: Toward an Integrative
Framework,” Research Policy (43:7), pp. 1239–1249.
Gawer, A., and Cusumano, M. A. 2008. “How Companies Become Platform Leaders,” MIT Sloan
Management Review (49:2), pp. 28–35.
Ghazawneh, A., and Henfridsson, O. 2013. “Balancing Platform Control and External Contribution in
Third-Party Development: The Boundary Resources Model,” Information Systems Journal (23:2),
Gioia, D. A., Corley, K. G., and Hamilton, A. L. 2012. “Seeking Qualitative Rigor in Inductive Research:
Notes on the Gioia methodology,” Organizational Research Methods (16:1), pp. 15–31.
Google. 2011. “An update on Google Health and Google PowerMeter,” (available from:
September 6, 2016).
Grisot, M., Hanseth, O., and Thorseng, A. A. 2014. “Innovation of, in, on Infrastructures: Articulating the
Page 10 of 12
Open Digital Platforms in Health Care
Thirty Seventh International Conference on Information Systems, Dublin 2016 11
Role of Architecture in Information Infrastructure Evolution,” Journal of the Association of
Information Systems (15:4), pp. 197–219.
Hagiu, A., and Rothman, S. 2016. “Network Effects Aren’t Enough,” Harvard Business Review (94:4), pp.
Hanseth, O., and Aanestad, M. 2003. “Design as Bootstrapping. On the Evolution of ICT Networks in
Health Care,” Methods of Information in Medicine (42:4), pp. 385–391.
Hanseth, O., and Bygstad, B. 2015. “Flexible Generification: ICT Standardization Strategies and Service
Innovation in Health Care,” European Journal of Information Systems (24:6), pp. 645–663.
Hanseth, O., and Lyytinen, K. 2010. “Design Theory for Dynamic Complexity in Information
Infrastructures: The Case of Building Internet,” Journal of Information Technology (25:1), pp. 1–19.
Henfridsson, O., and Bygstad, B. 2013. “The Generative Mechanisms of Digital Infrastructure Evolution,”
MIS Quarterly (37:3), pp. 907–931.
Hinkelman, E. G. 2005. Dictonary of International Trade - Handbook of the Global Trade Community,
Novato: World Trade Press.
HSPC. 2016. “The Healthcare Services Platform Consortium,” (available from:
http://www.hspconsortium.org/; retrieved September 7, 2016).
Huckman, R., and Uppaluru, M. 2015. “The Untapped Potential of Health Care APIs,” Harvard Business
Review (93:12), pp. 1–7.
Klöcker, P. N., Bernnat, R., and Veit, D. J. 2015. “Stakeholder Behavior in National EHealth
Implementation Programs,” Health Policy and Technology (4:2), pp. 113–120.
Langley, A. 1999. “Strategies for Theorizing from Process Data,” Academy of Management Review (24:4),
Academy of Management, pp. 691–710.
Langley, A., Smallman, C., Tsoukas, H., and van De Ven, A. H. 2013. “Process Studies of Change in
Organization and Management: Unveiling Temporality, Activity, and Flow,” Academy of
Management Journal (56:1), pp. 1–13.
Leonard-Barton, D. 1992. “Core Capabilities and Core Rigidities: A Paradox in Managing New Product
Development,” Strategic Management Journal (13:S1), pp. 111–125.
Lessig, L. 2001. The Future of Ideas (1st ed.), New York: Random House.
Lluch, M., and Abadie, F. 2013. “Exploring the Role of ICT in the Provision of Integrated Care - Evidence
from Eight Countries.,” Health Policy (111:1), pp. 1–13.
Locke, K., Golden-Biddle, K., and Feldman, M. S. 2008. “Perspective--Making Doubt Generative:
Rethinking the Role of Doubt in the Research Process,” Organization Science (19:6), pp. 907–918.
Mandel, J. C., Kreda, D. A., Mandl, K. D., Kohane, I. S., and Ramoni, R. B. 2016. “SMART on FHIR: A
Standards-Based, Interoperable Apps Platform for Electronic Health Records,” Journal of the
American Medical Informatics Association (2016:1), pp. 1–10.
Monteiro, E. 1998. “Scaling Information Infrastructure: The Case of Next-Generation IP in the Internet,”
The Information Society (14:1998), pp. 229–245.
Rochet, J.-C., and Tirole, J. 2003. “Platform Competition in Two-Sided Markets,” Journal of the
European Economic Association (1:4), pp. 990–1029.
Sanner, T. A., Manda, T. D., and Nielsen, P. 2014. “Grafting: Balancing Control and Cultivation in
Information Infrastructure Innovation,” Journal of the Association for Information Systems (15:4),
Sydow, J., Schreyögg, G., and Koch, J. 2009. “Organizational Path Dependence: Opening the Black Box,”
Academy of Management Review (34:4), pp. 689–709.
Sydow, J., Windeler, A., Schubert, C., and Möllering, G. 2012. “Organizing R&D Consortia for Path
Creation and Extension: The Case of Semiconductor Manufacturing Technologies,” Organization
Studies (33:7), pp. 907–936.
Thorseng, A., and Jensen, T. B. 2015. “Building National Infrastructures for Patient-centred Digital
Services,” in ECIS 2015 Proceedings.
Tilson, D., Lyytinen, K., and Sørensen, C. 2010. “Digital Infrastructures: The Missing IS Research
Agenda,” Information Systems Research (21:4), pp. 748–759.
Tilson, D., Sørensen, C., and Lyytinen, K. 2013. “Platform Complexity: Lessons from the Music Industry,”
in Proceedings of the Annual Hawaii International Conference on System Sciences, pp. 4625–4634.
Tiwana, A. 2015. “Evolutionary Competition in Platform Ecosystems,” Information Systems Research
(26:2), pp. 266–281.
Tiwana, A., Konsynski, B., and Bush, A. A. 2010. “Research Commentary - Platform Evolution:
Coevolution of Platform Architecture, Governance, and Environmental Dynamics,” Information
Page 11 of 12
Open Digital Platforms in Health Care
Thirty Seventh International Conference on Information Systems, Dublin 2016 12
Systems Research (21:4), pp. 675–687.
Tripsas, M., and Gavetti, G. 2000. “Capabilities, Cognition, and Inertia: Evidence from Digital Imaging,”
Strategic Management Journal (21:10/11), pp. 1147–1161.
Winkler, T. J., Brown, C. V., and Ozturk, P. 2014. “The Interplay of Top-Down and Bottom-Up:
Approaches for Achieving Sustainable Health Information Exchange,” in ECIS 2014 Proceedings.
Winter, S., Berente, N., Howison, J., and Butler, B. 2014. “Beyond the Organizational ‘Container’:
Conceptualizing 21st Century Sociotechnical Work,” Information and Organization (24:4), pp. 250–
Yaraghi, N., Du, A. Y., Sharman, R., Gopal, R. D., and Ramesh, R. 2015. “Health Information Exchange as
a Multisided Platform: Adoption, Usage, and Practice Involvement in Service Co-Production,”
Information Systems Research (26:1), pp. 1–18.
Yin, R. K. 2013. Case study research: Design and methods (5th ed.), Los Angeles: Sage.
Page 12 of 12