International Journal of Medical Informatics 99 (2017) 1–10

Contents lists available at ScienceDirect

International Journal of Medical Informatics

journal homepage: www.ijmijournal.com

Opening the Duke electronic health record to apps: Implementing

SMART on FHIR
Richard A. Bloomfield Jr a,∗ , Felipe Polo-Wood b , Joshua C. Mandel c , Kenneth D. Mandl d
a
Duke Health Technology Solutions, 2424 Erwin Road, Suite 12053, Durham, NC 27705, USA
b
Duke Health Technology Solutions, 3100 Tower Blvd. Office 270, Durham, NC 27707, USA
c
Harvard Medical School, Department of Biomedical Informatics, 10 Shattuck St, Office 315B, Boston, MA 02115, USA
d
Boston Children’s Hospital, Computational Health Informatics Program, 300 Longwood Avenue, 1 Autumn 535 Mail Stop BCH3187, Boston, MA 02115, USA

a r t i c l e i n f o a b s t r a c t

Article history: Objective: Recognizing a need for our EHR to be highly interoperable, our team at Duke Health enabled
Received 27 September 2016 our Epic-based electronic health record to be compatible with the Boston Children’s project called
Received in revised form 3 December 2016 Substitutable Medical Apps and Reusable Technologies (SMART), which employed Health Level Seven
Accepted 11 December 2016
International’s (HL7) Fast Healthcare Interoperability Resources (FHIR), commonly known as SMART on
FHIR.
Keywords:
Methods: We created a custom SMART on FHIR-compatible server infrastructure written in Node.js that
Electronic health records
served two primary functions. First, it handled API management activities such rate-limiting, autho-
HL7 FHIR
Interoperability
rization, auditing, logging, and analytics. Second, it retrieved the EHR data and made it available in a
Software FHIR-compatible format. Finally, we made required changes to the EHR user interface to allow us to
integrate several compatible apps into the provider- and patient-facing EHR workflows.
Results: After integrating SMART on FHIR into our Epic-based EHR, we demonstrated several types of
apps running on the infrastructure. This included both provider- and patient-facing apps as well as apps
that are closed source, open source and internally-developed. We integrated the apps into the testing
environment of our desktop EHR as well as our patient portal. We also demonstrated the integration of
a native iOS app.
Conclusion: In this paper, we demonstrate the successful implementation of the SMART and FHIR
technologies on our Epic-based EHR and subsequent integration of several compatible provider- and
patient-facing apps.
© 2016 Elsevier Ireland Ltd. All rights reserved.

1. Introduction no universal standard for laptop or cell phone charging cables. Of

course, these inconveniences can also spur innovation.
Under the right circumstances, technology standardization can In the latter half of the twentieth century, the TCP/IP [2]
be a powerful driver of innovation [1]. The discovery of electricity communications protocol was created, forming the basis of the
required understanding and defining voltages and power transmis- Internet, which could be considered the greatest breakthrough in
sion systems so that electric current could be delivered and received information sharing since the printing press. This leveling of the
in a usable form. The standardization of dry battery cell sizes in information playing field and subsequent adoption of open stan-
the early 20th century led to increased competition from compa- dards and specifications such as HTML, REST, OAuth and JSON, not
nies such as Duracell and Energizer that has resulted in lowered only made possible technological breakthroughs such as Amazon,
costs and improved cell chemistry. Lack of standardization − or Uber, and the App Store economy, but also resulted in political
proliferation of competing standards − can be costly. There is still upheaval and transformation as individuals began to discover free-
doms enjoyed by others but lacking in their own countries. In other
words, open standardization of data resulted in real, measurable
change.
∗ Corresponding author. Yet, despite the technological advances brought by the Inter-
E-mail addresses: ricky.bloomfield@duke.edu (R.A. Bloomfield Jr), net and quickly adopted by large industries such as finance and
felipe.polowood@duke.edu (F. Polo-Wood), jmandel@med.harvard.edu air travel, healthcare has been slow to adopt open standards in the
(J.C. Mandel), Kenneth Mandl@harvard.edu (K.D. Mandl).

http://dx.doi.org/10.1016/j.ijmedinf.2016.12.005
1386-5056/© 2016 Elsevier Ireland Ltd. All rights reserved.
2 R.A. Bloomfield Jr et al. / International Journal of Medical Informatics 99 (2017) 1–10

same way. Health data standards HL7v2 and v3 are not only less tion permits the inclusion of SMART-enabled HTML apps directly
familiar and more complex than commonly-used web standards into the clinical workflow rather than as a “one-off” solution. These
[3], but until recently [4] have been encumbered by licensing issues additional features make it possible to create a SMART-enabled app
that increase cost and slow adoption. In order to bring healthcare that could communicate with any compliant EHR with no addi-
into the modern era of rapid technological change, it is impera- tional effort: a truly “plug-and-play” solution.
tive that broadly-supported, accessible health care standards are This paper decribes the first integration of SMART and FHIR in
deployed at scale as quickly as possible. an Epic-based EHR system.

1.1. Duke Health’s EHR journey 2. Methods

Between 2012 and 2014 Duke Health underwent a transition We implemented a SMART and FHIR-compatible server at Duke
from a home-grown, web-based electronic health record (EHR) sys- on our Epic 2014-based EHR. While continuing to develop a custom
tem called eBrowser to an Epic-based EHR. With this transition solution would have met Duke’s local needs, innovations would
came anxiety that the degree of flexibility enjoyed with a home- have remained siloed within Duke’s walls, inaccessible by other
grown system might be significantly curtailed. As an academic institutions without tremendous additional effort to support out-
medical center, this consideration was magnified by the desire of side EHR environments. The SMART platform was also attractive
our innovators, including physicians, nurses, and business leaders because of the ecosystem of apps that was actively being devel-
to use data generated by the EHR to fulfill their clinical, research oped, and made available in the SMART App Gallery, as shown in
and business needs, and to have the capability to access this data Fig. 1.
from anywhere. In other words, mobile data access was imperative.
It became clear that a system of open application programming 2.1. Implementation of SMART on FHIR
interfaces (APIs) would help us meet these needs.
In early 2014 we began to explore the feasibility of such a The implementation and pilot of the SMART and FHIR frame-
system with our development team, who, because of our prior works at Duke involved two major efforts: 1) integrating the SMART
experience implementing an enterprise-scale EHR system, under- and FHIR functionality into the Epic-based EHR, and 2) installing
stood the nuances related to access of protected health information several apps to validate this integration. The integration effort is
(PHI), including considerations related to security, compliance, data collectively known as Duke Apps Supporting Healthcare, or DASH,
validity, and standardization. We implemented a proof-of-concept as illustrated in Fig. 2.
system that employed use of standard technologies for authentica- At a high level, integrating the SMART and FHIR frameworks
tion, authorization and data access, including REST and OAuth 2.0, into an Epic EHR required mapping the data elements in the Epic
and demonstrated an Android application that allowed a provider database to data types used by FHIR (known as “Resources” [10]),
to log in to the Epic environment using standard Duke credentials and implementing the authorization/authentication scheme sup-
to access patient demographics, medications, and a problem list. ported by SMART (OAuth 2.0 and OpenID Connect). In addition to
Feasibility had been proven. supporting novel applications, the framework was also intended to
aid the transition of aging clinical systems to a modern infrastruc-
1.2. SMART on FHIR ture. All of this needed to be done in a way that would be secure,
compliant, and allow us to control the amount and type of users
Shortly after completing this work we became aware of a similar accessing the apps at any given time.
but much more comprehensive effort called SMART on FHIR, a new,
open API designed to support substitutable apps [5]. Substitutable 2.2. FHIR server
Medical Apps and Reusable Technologies (SMART) incorporates
Fast Healthcare Interoperability Resources (FHIR) [6], which was The FHIR server (based on the Draft Standard for Trial Use ver-
designed from the ground-up to be standards-based, open source sion 2, or DSTU2 [11]) is comprised of two components: 1) the API
and royalty free with no exceptions. HL7 maintains the FHIR stan- management layer (Fig. 2, middle row); and 2) the code to handle
dard as a departure from prior work. In the words of HL7, “FHIR the retrieving FHIR resources from the EHR (Fig. 2, bottom row).
combines the best features of HL7 s v2, HL7 v3 and CDA product The server is written using Node.js [12], an asynchronous, event-
lines while leveraging the latest web standards and applying a tight driven JavaScript runtime known for its efficiency and stability. The
focus on implementability [7].” These prior standards − HL7 v2, resulting architecture is fast and scalable, allowing for real-time
HL7 v3, and the clinical document architecture (CDA) − were not rate limiting on a per-app basis as well as appropriate auditing and
designed using modern web standards, are not open source, and logging as required (Fig. 3).
until 2013 required licensing fees. The FHIR resources can be retrieved from Epic in one of three
However, employing the FHIR APIs alone would not help us ways depending on our needs:
accomplish our goal of seamless EHR data access from apps. FHIR
did not define the method whereby a user could be appropri- • Epic web services. Our preferred method, when possible, is to
ately given permission (i.e., authorized) to access the data, it only use Epic’s provided web services to retrieve data elements, then
defined the data models, ontologies, and the method to exchange expose them via the FHIR interface. The advantage is that these
the information with a FHIR server. To close this gap, a group at web services take care of the required auditing and logging with
the Computational Health Informatics Program at Boston Children’s minimal overhead. They are also fast and efficient, and pull data
Hospital and Department of Biomedical Informatics at Harvard had from Chronicles, Epic’s real-time clinical database (see below),
been federally funded to develop open API specifications for EHR thus ensuring the data is always up to date. One important
data access, and had developed the SMART app platform. SMART caveat is that if a web service does not provide enough data
constrains FHIR with a standard set of data profiles, and adds stan- or metadata to satisfy the requirements of a particular FHIR
dard authorization and authentication technologies (OAuth 2.0 and resource, we may be required to combine the web service data
OpenID Connect) as well as EHR UI integration patterns to provide with one of the methods below in order to be compliant. This
an open health app platform [8]. SMART’s goal is to enable an app additional dependency dramatically increases complexity and
written once to run in any health IT system [9]. This deep integra- maintenance overhead. For example, when implementing the
 R.A. Bloomfield Jr et al. / International Journal of Medical Informatics 99 (2017) 1–10 3

Fig. 1. SMART App Gallery.

MedicationOrder FHIR resource we were not provided with the cles, the production Epic database that uses the Caché database
RxNorm code, but rather given an internal Epic code that we management system based on the Massachusetts General Hospi-
used to pull the RxNorm code from Clarity (see below) before tal Utility Multi-Programming System, or MUMPS [13]. MUMPS
combining and exposing the data via FHIR. is described by Menn et al. as “a versatile text-oriented language
• Clarity. When there is not a web service available for a specific [that is] easy to use, allows rapid access to a dynamic data base,
data type, we can quickly and easily pull the data from Clarity, a and can be implemented on a relatively modest-sized computer
relational database that is typically updated once or twice daily system [14],” the last of which is still true. This method requires
with data from the production clinical database. This is not ideal the greatest effort since we also need to take responsibility for
for data elements that require up-to-the-minute accuracy, but is appropriate auditing and logging, yet the end result is fast and
very useful for prototyping FHIR resource in our proof-of-concept timely access to the clinical data. These custom routines are then
environment with very little effort. exposed as custom web services that can be used alongside Epic’s
• Chronicles. When a web service is not available, yet we need web services.
immediate access to recent data elements, we turn to Chroni-
4 R.A. Bloomfield Jr et al. / International Journal of Medical Informatics 99 (2017) 1–10

Fig. 2. Apps (on top) interact with FHIR resources (on bottom) via an additional layer of API management controls (middle).

2.3. App integration above, there are several methods available to obtain these data from
the EHR. In this instance we needed to write a custom routine to
Since we expect that future apps will primarily come from three pull the data from Chronicles in order to ensure up-to-date data.
development sources − open source, proprietary, or internal − This was important because this app will be used in the inpatient
we chose apps for this pilot reflective of each of these categories setting, where providers would need access for rounding purposes
(Table 2). In addition, the Duke team wanted to demonstrate how soon after the values were recorded in the patient’s chart.
the flexibility of this platform allowed for these apps to be deployed In addition to mapping the EHR data elements to the appropri-
within a desktop or mobile workflow. ate FHIR resources, a critical element to full workflow integration
This aspect − integration into the desktop or mobile workflow − was the authentication and authorization process. Without an inte-
was a key motivation for undertaking this effort, and was based on grated process, also known as single sign-on (SSO), providers would
our experience that any app that did not seamlessly integrate into be required to log in to this app even after they were logged into
the patient or provider workflow would quickly fall into disuse and their EHR environment. This additional barrier would significantly
fail. The SMART and FHIR frameworks provide the technical tools decrease app usage. This integration was accomplished through the
that allow us to make the requisite connections to the EHR, but standard OAuth 2.0 standard, and required modification of our EHR
beyond enabling these frameworks in our Epic-based EHR, we also environment so that the EHR could generate a token that could then
needed to ensure that this integration made sense from a usability be understood and interpreted by the FHIR infrastructure, which
standpoint. would, in turn, grant appropriate access to an authorized user. We
customized the SMART on FHIR authorization flow slightly (see
3. Results “Limitations”).

3.1. SMART Growth Chart

3.1.2. Workflow integration
We began with the open source SMART Growth Chart app devel- The final integration step was unique to the Epic EHR, but would
oped at Boston Children’s Hospital case for several reasons. It was be the same for any FHIR app: we needed to determine where
relatively simple, requiring only a few FHIR resources; it provided within the clinical workflow the app should be made available,
a straightforward “drop-in” replacement for our EHR’s existing and make it simple to invoke the app within that workflow. For
growth chart functionality; it contains a patient-centric view ideal this particular example, we chose to follow the precedent set by
for display within a patient portal; and it allows for implementation the EHR’s current growth chart functionality, and added a “SMART
of basic “write” support of parental height. Growth Chart” button to the same menu. When clicked, it opens
the SMART Growth Chart app in the same manner as the default
3.1.1. Technical integration growth chart app. For our pilot, we chose to retain both the default
For the SMART Growth Chart to display appropriate data from growth chart button as well as the SMART Growth Chart button so
a patient’s medical record within the EHR, we mapped the EHR users could choose whichever they preferred.
data elements to the equivalent FHIR resources. The data elements In addition to making it available to the provider, we also
included items from the FHIR Patient resource (name, gender, demonstrated that it is feasible to integrate this into the patient-
date of birth), Observations resource (height, weight, head circum- facing portal, also invoked with a single button, and with no
ference), and FamilyMemberHistory resource (parental height, to additional authentication necessary. These integrations are high-
calculate the child’s mid-parental height if available). As noted lighted in Fig. 4.
 R.A. Bloomfield Jr et al. / International Journal of Medical Informatics 99 (2017) 1–10 5

Fig. 3. a. SMART on FHIR Growth Chart app integrated within the provider workflow; b. SMART on FHIR Growth Chart app integrated within the patient portal and displaying
a patient-centric view.
6 R.A. Bloomfield Jr et al. / International Journal of Medical Informatics 99 (2017) 1–10

Fig. 4. SMART growth chart app deployed on mobile devices via the mobile EHR apps in our proof of concept system.

Table 1 The SMART Growth Chart app was deployed in our production
Type of integration required for each FHIR resource.
EHR environment in October 2015 to a small pilot group consisting
Web Services Clarity Chronicles of about 20 EHR physician champions, making it the first FHIR app
FamilyMemberHistory X X deployed in production at any health system with an Epic-based
MedicationOrder X X EHR.
Observation (Vital Signs) X
Patient X

3.2. Limitations

This functionality was completed in our proof of concept envi- 3.2.1. Authorization flow
ronment in January 2015, and later demonstrated at HIMSS15 [19] As noted above, our implementation introduced a small devia-
along with Meducation and Duke PillBox [20]. With the infras- tion from the SMART on FHIR authorization flow in order to remain
tructure in place, it was a simple matter to demonstrate how the compliant with the OAuth 2.0 specification as well as with the poli-
SMART Growth Chart app could be included in additional envi- cies of our Information Security Office. As illustrated in Fig. 6a,
ronments, including the Epic mobile applications, Haiku and Canto the SMART on FHIR JS client library expects that the Authorization
(for iPhone/Android and iPad, respectively). This integration in our Server (AS) will be able to provide information regarding the patient
proof-of-concept environment required a simple, ∼5-min configu- context when it provides the access token. In our case, because the
ration, and would work for any HTML-based FHIR app. Note that the Duke Information Security Office required that the AS remain sep-
SMART Growth Chart app is not yet optimized for mobile, touch- arate from the EHR, we needed to modify it to support this flow in
based interfaces through a responsive web design. This is work that a compliant way. In our modified flow, as illustrated in Fig. 6b, we
will need to be done before the apps are deployed on mobile devices launch the application from Hyperspace using a JSON Web Token
in production. (JWT) as an authorization grant according to RFC 7523 [24], and
In addition to the integration of HTML5-based apps, we also encrypted according to RFC 7516 [25], with the patient context
demonstrated that a SMART on FHIR-compliant, native iOS app passed as custom claims. This JWT is opaque to the application,
could also be configured to connect directly to the same FHIR end- which in turn passes it to the AS. After the AS decrypts the JWT
point (see Table 1). This app made use of open source libraries for and verifies the signature, it exchanges the JWT for an access token
SMART [21] and FHIR [22] written in the open source Swift [23] that it returns to the application. At the same time, the AS takes
programming language. See Fig. 5. the custom claims and links them to the generated access token,
 R.A. Bloomfield Jr et al. / International Journal of Medical Informatics 99 (2017) 1–10 7

Table 2
Apps integrated into our Epic-based EHR via SMART on FHIR.

Type Name Developer Functionality FHIR Resources Used

Web; Open Source SMART Growth Chart [15] Boston Children’s Hospital Pediatric growth chart Patient
interface that includes Observation (Vital Signs)
traditional curves, data tables, FamilyMemberHistory
and a unique parental-specific
view
Native; Proprietary Pediatric Growth Charts [16] Boston Children’s Hospital Pediatric growth chart app that Patient
provides a native interface for Observation (Vital Signs)
iOS devices
Web; Proprietary Meducation [17] Polyglot Patient-specific medication Patient
instructions provided at a MedicationOrder
5–8th grade reading level in 21
languages
Web; Internally-developed Duke PillBox [18] Duke Health Interactive, patient-specific Patient
medication adherence teaching MedicationOrder
tool
Native; Internally-developed Duke FHIR Wedge Duke Health Software adapter to allow Patient
legacy app to receive patient
demographic information via
FHIR interface

Fig. 5. Pediatric Growth Charts iOS Application.

which the app can retrieve as needed using an introspection call and clinical expertise to accurately map the data elements to FHIR
according to RFC 7662 [26]. from their equivalent element in the EHR. The complexity of this
issue has been recognized by others, and attempts to collectively
3.2.2. Data validation solve this problem have not yet been widely successful. As a start-
While the use cases demonstrated here were ideal for a simple ing point, SMART defines data category level profiles that align to
proof of concept for the SMART on FHIR platform, building out more meaningful use (e.g. specifying that RxNorm codes are required for
complex FHIR resources on our own would require significant effort FHIR medication resources) and is working with Argonaut [27] (see
8 R.A. Bloomfield Jr et al. / International Journal of Medical Informatics 99 (2017) 1–10

Fig. 6. a. SMART on FHIR authorization flow versus b. Duke’s authorization flow.

“Future Directions”) to codify this approach. Other efforts include Table 3

Number of times each FHIR resource has been accessed between 12/1/15-12/1/16.
the Clinical Information Modeling Initiative, or CIMI [28], whose
stated mission is to “Improve the interoperability of healthcare sys- FHIR Resource Number of Times Accessed
tems through shared implementable clinical information models.” AllergyIntolerance 212
Initiatives such as CIMI exist because the use of FHIR does not guar- Condition 80
antee interoperability [29], and much work will still be required to FamilyHistory 46
ensure that data elements mapped in different EHRs relay the same FamilyMemberHistory 45
Immunization 11
clinical content when used with FHIR.
MedicationOrder 105
MedicationPrescription 41
Observation 478
3.3. Usage
Patient 35424
Total 36442
Our FHIR infrastructure has been used consistently since it went
live in August 2015. The data in Table 3 represent the number of
times each FHIR resource has been accessed in the 1 year period been more apparent. The introduction of easily-substitutable EHR
from 12/1/15-12/1/16. apps will likely raise red flags for health system security and com-
pliance offices given the complexity and variety of such apps, and
4. Discussion the fact that each app developer will have varying processes for
managing the security of their apps and development processes.
4.1. Security considerations While standardization of the use of OAuth 2.0 and OpenID con-
nect for use with the FHIR and SMART APIs can ensure that the
Given recent high-profile security breaches in both retail [30] authorization and authentication workflows are done optimally
and healthcare [31], the need for secure clinical systems has never from a security perspective, there is no guarantee that those pro-
 R.A. Bloomfield Jr et al. / International Journal of Medical Informatics 99 (2017) 1–10 9

tocols and the corresponding app will be securely implemented by

each developer. This brings additional inherent risk with each app Summary points
deployed in the EHR environment. Already known
At Duke, any new app or infrastructure that will be deployed
• SMART on FHIR framework provides the infrastructure to
in the production environment will go through a standard process
enable plug-and-play apps with electronic health records
called the Service Transition Readiness Assessment, or STRA. This
(EHRs).
process ensures that each app is appropriately vetted based on the • SMART on FHIR has not been successfully implemented and
app’s functionality and intended use. Our own infrastructure was tested a production environment on all major EHR systems.
approved through this process and any additional FHIR and SMART
apps would require the same. As a result of this review, it may Knowledge added
be determined that external vendors would be required to pro-
vide documentation of appropriate security reviews such a Service • A custom integration of SMART on FHIR with the Epic EHR
Organization Controls (SOC) 1 or 2 report, as indicated by the State- was demonstrated.
ment on Standards for Attestation Engagements (SSAE) No. 16 [32] • This integration required the creation of an API management
from the American Institute of Certified Public Accountants. layer and a slight standards-based deviation from the SMART
OAuth profile in order to accommodate single sign-on from
the EHR context.
4.2. Future directions • Several different applications were demonstrated in several
different contexts, including our production system at Duke.
Enabling an Epic-based EHR system to work seamlessly with
standards-based clinical applications is a major step forward in our
ability to provide more effective care to our patients at lower cost
available, the sooner we will achieve the economies of scale that
by harnessing the rapid innovation that we anticipate from such
will drive real and lasting change.
open standards. The next step is to ensure that such apps are also
compatible with a variety of EHR systems so the innovations can
reach the widest possible audience. To that end, initiatives such Conflicts of interest
as the Argonaut Project, which is a collaboration between major
EHR vendors, academic medical centers, HL7, the SMART team, RAB: Currently employed at Apple Inc., although was not
and other partners to accelerate implementation of the SMART API employed there during the drafting of this manuscript.
within EHR products and to promote wider use of FHIR resources, FPW: No conflicts of interest to report.
have helped align efforts to ensure that the standard will be imple- JCM: Currently employed at Verily (Google Life Sciences),
mented broadly in a way that will ultimately benefit providers and although was not employed there during the drafting of this
patients. All major EHR vendors have backed this initiative by either manuscript.
providing feedback or implementing a version of the SMART on KDM: No conflicts of interest to report.
FHIR standard in upcoming versions of their products.
While the majority of apps we have integrated at Duke thus far Author contributions
are designed to be used by providers, these efforts will also enable
a new generation of precision medicine research through patient- RAB wrote the first and final draft of the manuscript. FPW, JCM,
centric apps that aim to streamline collection of genomic or family and KDM contributed substantially to the manuscript.
history information. One such example is the MeTree [33] app,
which was selected by the White House to be highlighted as part Funding
of the Champions of Change for Precision Medicine event in July
2015 [34]. MeTree makes it possible for patients to share detailed This research did not receive any specific grant from funding
family history information that can then be used in conjunction agencies in the public, commercial, or not-for-profit sectors.
with evidenced-based algorithms to predict and prevent disease.
We are currently working to integrate this app into our patient References
portal through the SMART and FHIR APIs.
Standards-based apps will also be critical to realizing the vision [1] J. Farrell, G. Saloner, Standardization, compatibility, and innovation, RAND J.
of the Precision Medicine Initiative Cohort Program, whereby one Econ. (April 1) (1985) 70–83.
[2] RFC 675: Specification of Internet Transmission Control Program. 1974.
million or more volunteers will share their health data to help us
http://www.ietf.org/rfc/rfc0675.txt. (Accessed May 2016).
understand how we can improve health and treat disease [35]. Ide- [3] Health Intersections HL7 needs a fresh look because V3 has failed. 2011.
ally, the development of a FHIR-compatible “Sync for Science” [36] http://www.healthintersections.com.au/?p=476. (Accessed May 2016).
[4] Health Level 7. HL7’s Standards Licensed At No Cost. 2013. http://www.hl7.
app will allow patients to share their data directly from the patient
org/implement/standards/nocost.cfm. (Accessed May 2016).
portal of whichever EHR system their health system has deployed. [5] K.D. Mandl, I.S. Kohane, No small change for the health information economy,
N. Engl. J. Med. 360 (13) (2009) 1278–1281.
[6] Health Level 7. Welcome to FHIR. https://www.hl7. org/fhir/. (Accessed May
5. Conclusion 2016).
[7] Health Level 7. Introducing HL7 FHIR. https://www.hl7.org/fhir/summary.
html. (Accessed May 2016).
We demonstrated the first successful implementation of a [8] J.C. Mandel, et al., SMART on FHIR: a standards-based, interoperable apps
standards-based API layer on an Epic-based EHR, including the inte- platform for electronic health records, J. Am. Med. Inform. Assoc. (2016) 1–10
gration of several clinical applications. We believe that the scalable https://jamia.oxfordjournals.org/content/jaminfo/early/2016/02/16/jamia.
ocv189.full.pdf.
adoption of standards-based APIs will create a platform on which [9] K.D. Mandl, J.C. Mandel, I.S. Kohane, Driving innovation in health systems
innovators large and small can contribute to these improvements through an apps-Based information economy, Cell Syst. 1 (1) (2015) 8–13.
in health. The deployment and use of technologies such as FHIR and [10] Health Level 7. Resource Index. https://www.hl7.org/fhir/resourcelist.html.
(Accessed May 2016).
SMART in live clinical systems such as ours demonstrates that this [11] Health Level 7. FHIR Publication Directory. https://www.hl7.org/fhir/
technology is not just feasible, but also ready for widespread clin- directory.html. (Accessed August 2016).
ical deployment. The sooner these technologies are more broadly [12] Node.js. https://nodejs.org/en/. (Accessed May 2016).
10 R.A. Bloomfield Jr et al. / International Journal of Medical Informatics 99 (2017) 1–10

[13] R.A. Greenes, A.N. Pappalardo, C.W. Marble, et al., Design and implementation [25] RFC 7516: JSON Web Encryption (JWE). May 2015. https://tools.ietf.org/html/
of a clinical data management system, Comput. Biomed. Res. 2 (1969) rfc7516. (Accessed August 2016).
469–485. [26] RFC 7662: OAuth 2.0 Token Introspection. October 2015. https://tools.ietf.org/
[14] S.J. Menn, G.O. Barnett, D. Schmechel, et al., A computer program to assist in html/rfc7662. (Accessed June 2016).
the care of acute respiratory failure, JAMA 223 (3) (1973) 309. [27] Argonaut Project. http://argonautproject.org/. (Accessed May 2016).
[15] Substitutable Medical Apps and Reusable Technology. App Gallery −Growth [28] Clinical Information Modeling Initiative. http://opencimi.org. (Accessed May
Chart. 2016. https://gallery.smarthealthit.org/boston-childrens-hospital/ 2016).
growth-chart. (Accessed May 2016). [29] Health Intersections. #FHIR and the Gartner Hype Cycle. 2016. http://www.
[16] Substitutable Medical Apps and Reusable Technology. App Gallery −Pediatric healthintersections.com.au/?p=2514. (Accessed May 2016).
Growth Charts (iOS). 2016. https://gallery.smarthealthit.org/boston- [30] The Wall Street Journal. Home Depot’s 56 Million Card Breach Bigger Than
childrens-hospital/pediatric-growth-charts-ios. (Accessed May 2016). Target’s. Sept. 18, 2014. http://www.wsj.com/articles/home-depot-breach-
[17] Substitutable Medical Apps and Reusable Technology. App Gallery bigger-than-targets-1411073571. (Accessed June 2016).
−Meducation RS. 2016. https://gallery.smarthealthit.org/polyglot-systems/ [31] Modern Healthcare Big healthcare breaches affected millions before Anthem’s
meducation-rs. (Accessed May 2016). hack. 2015. http://www.modernhealthcare.com/article/20150210/blog/
[18] Substitutable Medical Apps and Reusable Technology. App Gallery −Duke 302109995. (Accessed June 2016).
Pillbox. 2016. https://gallery.smarthealthit.org/duke/pillbox. (Accessed May [32] SSAE-16. http://www.ssae-16.com/. (Accessed May 2016).
2016). [33] L.A. Orlando, A.H. Buchanan, S.E. Hahn, et al., Development and validation of a
[19] Smart Health IT YouTube Channel. Duke: SMART Launch & Apps Demo in primary care-based family health history and decision support program
Epic. 2015 https://www.youtube.com/watch?v=fN z92Twlec. (Accessed May (MeTree), NC Med. J. 74 (4) (2013) 287–296.
2016). [34] The Mobile Doc. White House Champions of Change in Precision Medicine:
[20] Smart Health IT YouTube Channel. Duke: PillBox. 2015. https://www.youtube. Duke’s Commitment. http://www.rickybloomfield.com/2015/07/white-
com/watch?v=ilpOR1lS7Lk. (Accessed May 2016). house-champions-of-change-in.html. (Accessed May 2016).
[21] GitHub. Swift-SMART. 2016. https://github.com/smart-on-fhir/Swift-SMART. [35] National Institutes of Health. An Update on the Precision Medicine Initiative
(Accessed May 2016). Cohort Program. 2015. http://www.nih.gov/about-nih/who-we-are/nih-
[22] GitHub. Swift-FHIR. 2016. https://github.com/smart-on-fhir/Swift-FHIR. director/statements/update-precision-medicine-initiative-cohort-program.
(Accessed May 2016). (Accessed May 2016).
[23] Swift.org. 2016. https://swift.org. (Accessed May 2016). [36] Sync For Science. Helping patients share EHR data with research. http://
[24] RFC 7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication syncfor.science. (Accessed June 2016).
and Authorization Grants. May 2015. https://tools.ietf.org/html/rfc7523.
(Accessed June 2016).