This is an open-access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in the Interactive Journal of Medical Research, is properly cited. The complete bibliographic information, a link to the original publication on http://www.i-jmr.org/, as well as this copyright and license information must be included.
The Strategic Health IT Advanced Research Projects (SHARP) program seeks to conquer well-understood challenges in medical informatics through breakthrough research. Two SHARP centers have found alignment in their methodological needs: (1) members of the National Center for Cognitive Informatics and Decision-making (NCCD) have developed knowledge bases to support problem-oriented summarizations of patient data, and (2) Substitutable Medical Apps, Reusable Technologies (SMART), which is a platform for reusable medical apps that can run on participating platforms connected to various electronic health records (EHR). Combining the work of these two centers will ensure wide dissemination of new methods for synthesized views of patient data. Informatics for Integrating Biology and the Bedside (i2b2) is an NIH-funded clinical research data repository platform in use at over 100 sites worldwide. By also working with a co-occurring initiative to SMART-enabling i2b2, we can confidently write one app that can be used extremely broadly.
Our goal was to facilitate development of intuitive, problem-oriented views of the patient record using NCCD knowledge bases that would run in any EHR. To do this, we developed a collaboration between the two SHARPs and an NIH center, i2b2.
First, we implemented collaborative tools to connect researchers at three institutions. Next, we developed a patient summarization app using the SMART platform and a previously validated NCCD problem-medication linkage knowledge base derived from the National Drug File-Reference Terminology (NDF-RT). Finally, to SMART-enable i2b2, we implemented two new Web service “cells” that expose the SMART application programming interface (API), and we made changes to the Web interface of i2b2 to host a “carousel” of SMART apps.
We deployed our SMART-based, NDF-RT-derived patient summarization app in this SMART-i2b2 container. It displays a problem-oriented view of medications and presents a line-graph display of laboratory results.
This summarization app can be run in any EHR environment that either supports SMART or runs SMART-enabled i2b2. This i2b2 “clinical bridge” demonstrates a pathway for reusable app development that does not require EHR vendors to immediately adopt the SMART API. Apps can be developed in SMART and run by clinicians in the i2b2 repository, reusing clinical data extracted from EHRs. This may encourage the adoption of SMART by supporting SMART app development until EHRs adopt the platform. It also allows a new variety of clinical SMART apps, fueled by the broad aggregation of data types available in research repositories. The app (including its knowledge base) and SMART-i2b2 are open-source and freely available for download.
The burden for development of innovative views of the medical record has, until recently, rested largely on the core software architects of electronic health record (EHR) systems. Local innovation on those systems has functionally been restricted to a small number of academic research hospitals with large research budgets [
A new allocation of resources is emerging which will directly support distribution, modularity, and interoperability of local innovation. In 2009, Kohane and Mandl proposed that EHRs be designed as platforms for supporting modular third-party applications rather than as monolithic systems [
In 2010, the United States Office of the National Coordinator for Health Information Technology (ONC) launched a four-year, $60 million government initiative: the Strategic Health IT Advanced Research Projects (SHARP) program. SHARP seeks to conquer well-understood challenges in medical informatics through breakthrough research. ONC funded four SHARP centers, one to study each of four challenge areas: information security, cognitive support, reusable applications, and secondary use of EHR data [
The Substitutable Medical Apps Reusable Technologies (SMART) center at Harvard Medical School is attempting to make Kohane and Mandl’s ecosystem for user-interface innovation a reality. SMART defines an application programming interface (API) and provides core software components so that health care information technology (HIT) systems’ developers can implement a SMART “container” interface to provide access to the data in EHRs in a standardized resource description framework (RDF) format. Apps written to conform to the container interface will run without modification on all EHRs and HIT systems that provide a SMART container. Apps can be written for patients, providers, and researchers, and all are backed by EHR data. The high level design is shown in
At the beginning of 2012, SMART leadership reported on their progress 14 months into the contract [
SMART enables an ecosystems of apps in medical systems, just as app stores enable this on smartphones. Portions adapted with permission from [
One potentially important use-case for SMART-style user-interface innovation is in clinical decision support (CDS). There is substantial evidence to suggest that CDS can be a powerful tool to improve the quality of patient care, yet commercial EHR systems have highly variable and underutilized CDS capabilities [
Its “automated model-based clinical summarization of key patient data” project seeks to make EHR data more easily digestible, particularly by transforming it from pages of disconnected data into a concise problem-oriented medical record (POMR). Clinical summarization is becoming particularly important given the overwhelming amount of information present in today’s EHRs. Sifting through these data present an added burden to already-overwhelmed clinicians, who admit to making mistakes due to hurry and distractions [
SMART’s app approach offers the ability to integrate a POMR view with traditional views of clinical data, and it also overcomes the difficulty of integrating new, vendor-independent applications with many vendor products. Therefore, we had previously turned to SMART and developed a proof-of-concept POMR SMART app [
We theorized that i2b2’s popularity and the wealth of data available in i2b2 instances would make it a useful “clinical bridge”, to support SMART apps prior to large EHR vendors developing SMART containers. This led us to an architecture in which the patient summarization app runs in SMART-i2b2, shown in
In this paper, we describe the results of our collaborative endeavor between i2b2 and the cognitive support and reusable apps SHARP centers, focused on creating more intuitive views of the EHR. Our goal was to facilitate development of intuitive, problem-oriented views of the patient record using NCCD knowledge bases that would run in any EHR.
The overall architecture of the patient summarizer running in the SMART-i2b2 “clinical bridge”.
To assist effective collaboration among sites, we used an Amazon virtual machine [
The National Drug File Reference Terminology (NDF-RT) contains “may_treat” linkages between diagnoses and medications [
We are developing other knowledge bases using other techniques, each with strengths and weaknesses. One knowledge base utilizes probabilistic linkages in the medical record, an approach first suggested more than a decade ago [
When the app is launched, it makes asynchronous JavaScript SMART API calls to retrieve demographics, medications, problems, allergies, lab results, encounters, vital signs, and immunizations. Each API call returns a SMARTResponse object containing a RDF graph containing that component of the patient record. For all objects except problems and medications, the app iteratively traverses each graph as it is retrieved to generate HTML display data. The app does not process problem and medication objects until both are loaded, because they must be handled together. When both are loaded, the app traverses the medication graph, retrieves all possibly related problems through the PHP Web service, and then traverses the problem graph, adding the current medication to the HTML output for all matching problems.
We modeled our summarization app’s user interface on a previously designed prototype interface of a problem-oriented view for OpenVista, which was evaluated using the Task, User, Representation, and Function framework for EHR usability [
The app user interface displays the list of active problems on the left. Users may select a problem from the list to display associated medications on the right side. The user can also click the “All Medications” text to toggle a list of all prescribed medications for the patient. We have not yet integrated a knowledge base with lab results, so the app displays all historical lab results and vital signs in a list below the problems and medications. Users may click a lab result or vital sign to toggle display of the values; any lab result with multiple values is shown as a graph, generated using the Google Visualization API. See the Results section and
i2b2 is a “hive” of “cells” (software modules), where each cell provides a set of Web services. New cells can be added to the hive and communicate with the other cells via Web service calls. The standard hive has the blue cells shown in
First, we developed a new cell, the SMART container, which implements the SMART API and securely sends RDF messages to SMART apps as specified by the OAuth protocol. SMART places the burden of constructing valid SMART-RDF messages on the container developer. Therefore, we developed a flexible way in the SMART cell to transform an i2b2 XML message into a SMART-RDF XML message using stylesheets.
Second, in i2b2, one methodologically challenging piece is flexibly translating from the variety of i2b2 terminologies to the expected terminologies of SMART. To facilitate this translation, we developed a Mapper cell, which supports customizable mappings between terminologies and can be jumpstarted with existing linkages such as those in the UMLS. A set of about 2000 most used “target terms” for mapping, which covers 85% of terms used in the Partners Health care System [
The final change to i2b2 was an upgrade to the Web interface. The i2b2 Web interface supports plugins, and so a plugin was developed for the “SMART Patient Centric view”, shown on the right side of
With these aforementioned components, any SMART app can reside inside i2b2, communicating with i2b2 via the SMART container. These SMART-enabling components are freely available and can be installed as an add-on to any i2b2 installation [
SMART RxNorm medications are mapped to SNOMED CT problems using the NDF-RT “may treat” linkage as intermediary. Adapted from [
Left: i2b2 hive (blue) with SMART container and Mapper cells (yellow). Right: SMART Patient Centric view for the i2b2 Web interface.
We deployed i2b2 v1.6 in an Amazon-hosted virtual machine with the demonstration terminology dictionary and the 133 fake demonstration patients included in the standard release of i2b2. We then installed the SMART Web client plugin and SMART cells using the previously described “target mapping terms” list that was populated with mappings from this demonstration terminology dictionary. We were able to deploy our summarization app by adding it to the Web server hosting i2b2 and making a few small configuration changes.
To run the app, a user chooses the SMART plugin inside the i2b2 Web client and drags the patient of interest into the Patient Centric view. One can either drag a patient from a customizable patient list (eg, the set of patients for which the user provides care), or from a previously executed research query. The two different options are shown in
During development, we found that the engineered demonstration patients distributed with i2b2 tended to have uncorrelated problems and interventions, probably because they are not based on real patient data but only to meet the goal of testing research queries. Therefore, we developed a new test patient. Because we developed this test patient in i2b2 (using non-SMART terminologies like NDC and ICD-9), she was a patient who utilized the full translation pipeline from i2b2 to SMART, including the Mapper cell. Therefore, although she is still a test patient, we believe she comes close to a real-world i2b2 scenario, where local terms are dynamically mapped to SMART terminology. The app correctly found the problem-medication linkages shown in
By SMART-enabling i2b2, we were able to develop a patient summarization app that can run in any i2b2 instance, reusing research data extracted from EHRs for clinical care. SMART-enabled i2b2 could then be launched as a webpage on an EHR workstation to run the summarization app on the current patient. We are finalizing a more streamlined workflow, in which the Patient Centric view can be launched for a particular patient separately from the full i2b2 Web client. This will allow easier access to clinical apps for a patient but still backed by the i2b2-SMART infrastructure.
Problem-medication linkages found by the patient summarization app on our i2b2 test patient.
Problem | Medication |
Acute bronchitis | Aminophylline 200 mg oral tablet |
Pernicious anemia | Vitamin B12 1 mg/ml injectable solution |
Seizure | Lamotrigine 100mg oral tablet |
Urinary incontinence | Oxybutynin chloride 5 mg oral tablet |
The i2b2 Web application with the SMART container activated. A patient can be dragged from a patient list in the workplace (first oval) or from a previous query result (second oval).
The patient summarization app running inside the SMART-i2b2 container. Shown here: urinary incontinence is highlighted and a relevant medication (oxybutynin) is displayed to the right; lab results are shown as line graphs below.
We successfully created a patient summarization app based on a validated NCCD knowledge base that can be run in nearly any EHR environment. For SMART-enabled EHRs, the app can be run directly within the EHR. In other cases, a SMART-enabled i2b2 instance can be used as a “sidecar” to the EHR, extracting data from it for research and clinical apps like this one. SMART-enabled i2b2 can run in a webpage alongside the EHR. This is certainly beneficial to more than 100 sites using i2b2 worldwide. We also found that online tools like Google+, GitHub, DropBox, and a cloud-hosted virtual machine increased our ability to collaborate effectively.
SMART has accelerated the implementation and testing of our patient summarization work. This step of our research was previously impeded by the need to maintain multiple apps for various clinical systems, thereby needing to adapt to each system’s local ontologies and local API. By choosing SMART, we can now test our knowledge bases using a single clinical app that will run in all SMART-enabled environments. At Partners’ Healthcare, this includes both i2b2 data repositories and directly in the outpatient medical record system. We are hopeful that supporting a single SMART app will allow us to disseminate our results both as a raw knowledge bases and as an executable tool.
Broad interest in SMART puts it in a good position to spread in the coming years, either through the demands and requirements of hospital systems, or through smaller EHR vendors implementing it in anticipation of gaining market share. Our hope is that this “sidecar” approach of running clinical apps through i2b2 will help foster SMART, by supporting SMART app development until EHRs adopt the platform. Furthermore, the i2b2 approach might provide SMART-specific functionality that are absent in other clinical systems.. Because i2b2 aggregates many systems’ data, it is able to provide more information than individual clinical systems, at the expense of real-time data. A SMART clinical app backed by i2b2 could allow clinicians to, for example, perform comparative effectiveness research on the fly to make treatment decisions for rare combinations of comorbidities [
Writing our SMART app was not particularly time-consuming; the majority of the work was developing the SMART-i2b2 container and NCCD knowledge bases. This indicates that SMART might be an ideal platform for quick dissemination of innovative tools. It is also notable that SMART apps will naturally become easier to write as general Internet innovation flourishes, because SMART apps can leverage freely available Web development toolkits such as Bootstrap and the Google Visualization API. While only about a dozen SMART apps have been developed to date, SMART has already enabled small software shops to innovate on EHR data through the SMART “app challenges”.
Whether SMART becomes the de facto standard for EHR apps remains to be seen as the platform matures. Already it has several points in its favor. First, it lessens the learning curve of app development by leveraging existing Web standards (eg, JavaScript Object Notation data structures and Web service interfaces). Second, the current API is a straightforward RDF data model designed to meet the needs of app development without trying to solve all use-cases for external views of clinical data. This avoids the steep learning curve of formats such as the Clinical Document Architecture, a health care data standard used for representing all types of clinical data. Third, SMART’s current read-only approach will be extended in the future with methods to write data back to the record. SMART enables clinical app innovation by giving app developers access to clinical data elements on individual patients, and it is complemented by data analytical platforms such as i2b2 (for aggregate, research-oriented data repositories and reporting).
The greatest challenges we faced in this endeavor occurred in “gluing” the pieces together. The downloadable source code [
As the technology matures, installing and developing containers and deploying apps will become simpler. The longer-term challenge for SMART deployments will be terminology mappings. This is a barrier to interoperability in general, and it appears in almost all health information exchange problems in medical informatics—from generating conformant continuity of care documents to consuming quality measure queries. Advanced methods for mapping terminologies are necessary. The i2b2 platform utilizes a mapping tool that extracts terms from the National Center for Biomedical Ontology. This is freely available and has been integrated into the SMART-i2b2 platform [
Previous testing of ontology-based knowledge bases on real patient data showed poor sensitivity [
Also, although we have extended the SMART app beyond the original prototype, it does not yet have the full functionality of the usability-tested prototype interface, nor does it currently have a particularly compelling “look and feel”. Beyond further refinement of the user interface, the app will need improvements of its handling of SMART patient data. Our current app simply displays the most recent problem and medication instance rather than a summary of that problem or medication’s history. Also, methods should be developed to incorporate unencoded data into the summary, as SMART does not require every problem or medication to have an associated code.
For the SMART platform as a whole, there are several open questions. One is the level of programming expertise needed to build an app. SMART supports app distribution in an interoperable environment and it lowers the entry threshold for those interested in developing innovative apps. However, we have not yet evaluated what average EHR users can accomplish with SMART. Currently available SMART apps have been written by groups with significant prior programming experience. A second open question is the appropriate distribution model for these apps. The iPhone app store has a certification process, whereas the Android app store does not. Because SMART’s goal is to foster innovation, it does not seem wise to restrict distribution of apps. Instead, some type of certification for apps performing key clinical functions might be needed. Currently, the ONC’s certification criteria for EHR systems require that any component performing a function for which certification exists must be certified for that function [
We have successfully deployed a patient summarization app in the i2b2 clinical data repository platform. This provides a problem-oriented view of the medical record by combining a previously developed knowledge base and the SMART medical apps platform. It leverages co-occurring work in building a SMART-i2b2 container for research, so that this clinical app can be available to the many clinicians whose information systems include i2b2 but do not otherwise have access to SMART. This technical work lays the foundation for a broader ecosystem of reusable apps to provide innovative summary views of the health record. It also provides a “clinical bridge” an i2b2-based pathway for reusable app development that does not require EHR vendors to immediately adopt the SMART API. We hope this will support SMART app development until EHRs adopt the platform.
All software components discussed here are freely available for download, including i2b2, SMART, the SMART-i2b2 integration, and the patient summarization app [
Screencast demo of patient summarization app running inside SMART-i2b2. This is a primarily a technical demonstration of the system, and the patient shown in the example does not necessarily have comorbidities that are realistic or clinically interesting.
application programming interface
clinical decision support
cascading style sheet
concept unique identifier
electronic health records
health care information technology
hypertext markup language
Informatics for Integrating Biology and the Bedside
International Classification of Diseases, 9th edition
Logical Observation Identifier Names and Codes
National Center for Biomedical Ontology
National Center for Cognitive Informatics and Decision-making
National Drug File - Reference Terminology
National Institutes of Health
Office of the National Coordinator for Health Information Technology
PHP Hypertext Preprocessor
problem-oriented medical record
resource description framework
Strategic Health Information Technology Advanced Research Projects
Substitutable Medical Apps, Reusable Technologies
Systematized Nomenclature of Medicine-Clinical Terms
Unified Medical Language System
We would like to thank the senior leadership and the software engineers of all three initiatives, who have made this work possible, and SMART’s lead architect Josh Mandel, MD, who provided us with portions of
None declared.