|Home | About | Journals | Submit | Contact Us | Français|
We have developed an interface to serve patient data from Informatics for Integrating Biology and the Bedside (i2b2) repositories in the Fast Healthcare Interoperability Resources (FHIR) format, referred to as a SMART-on-FHIR cell. The cell serves FHIR resources on a per-patient basis, and supports the “substitutable” modular third-party applications (SMART) OAuth2 specification for authorization of client applications. It is implemented as an i2b2 server plug-in, consisting of 6 modules: authentication, REST, i2b2-to-FHIR converter, resource enrichment, query engine, and cache. The source code is freely available as open source. We tested the cell by accessing resources from a test i2b2 installation, demonstrating that a SMART app can be launched from the cell that accesses patient data stored in i2b2. We successfully retrieved demographics, medications, labs, and diagnoses for test patients. The SMART-on-FHIR cell will enable i2b2 sites to provide simplified but secure data access in FHIR format, and will spur innovation and interoperability. Further, it transforms i2b2 into an apps platform.
We have developed an open-source interface that serves patient data from Informatics for Integrating Biology and the Bedside (i2b2) repositories in a Fast Healthcare Interoperability Resources (FHIR) format. The objective of this work is to enable simplified and secure access to patient data, in order to spur innovation of portable and scalable clinical apps by leveraging emerging health IT standards.
I2b2 is an open source clinical data analytics platform originally developed under funding from the National Institutes of Health.1,2 I2b2 is used at over 140 sites for querying patient data to address research questions. I2b2 has been adapted to build multi-institutional networks to allow federated querying, and is a central component in the infrastructure for many institutions that have Clinical and Translational Science Awards and Patient-Centered Outcomes Research Institute Awards.3,4
I2b2 supports a sidecar approach wherein the software aggregates a copy of the patient data from the electronic health record (EHR) and provides query services in parallel to the EHR for research. While the EHR manages patient data for clinical workflow, the i2b2 sidecar hosts a data copy for secondary use. Each i2b2 installation (called a hive) comprises several i2b2 cells that provide different services, and the cells communicate with each other using XML web services.
I2b2 software has been extended to handle a variety of data models and functionalities. There are i2b2 extensions for importing C-CDAs,5 translating HQMF,6 managing images,7 doing federated querying, conducting data analysis,8 conducting studies in specific disease domains,9,10 and complying with meaningful use. I2b2 has an active community of developers and has become a popular component of health care research.
FHIR is a new standard for exchanging health care information electronically.11 It is based on emerging industry approaches and builds on the lessons from previous standards including Health Level Seven’s v2 and v3, the Reference Information Model, and Clinical Document Architecture. FHIR uses a predominantly compositional approach, in contrast to the previous v3 approach of modeling by constraint, in that FHIR data is organized utilizing a combination of building blocks called resources. Furthermore, FHIR specifies a RESTful application programming interface (API) to access resources. Several projects are under way through standards organizations to facilitate adoption of FHIR, including the Argonaut Project,12 the Data Access Framework, and the Clinical Information Modeling Initiative.13
SMART is a project aimed at developing a health information technology platform for supporting “substitutable” modular third-party applications (SMART apps) constructed around a set of core services.14–16 These apps can run directly within EHRs; the 5 top EHR vendors have implemented SMART standards through a project called Argonaut.12 The same apps that run in the EHR context could also run on a “sidecar” such as i2b2 supporting the SMART-on-FHIR API. SMART Health IT transforms an EHR or its sidecar into an iPhone-like platform.17 Smartphone platforms support an ecosystem of applications that extend the capability of the phone beyond the core software. Similarly, SMART Health IT supports an “app store for health” of substitutable apps constructed around core services and is intended to drive down health care technology costs and spur innovation, by fostering market competition for the evolution of applications that better support care provider needs.
The SMART specification provides a protocol for apps to authenticate with and run against existing health information technology systems, and the SMART library uses a JSON format for payload representation. We have implemented FHIR and OAuth2 specifications, and have completely rewritten the i2b2 plug-in for SMART apps developed previously.18 Our new interface is referred to as the SMART-on-FHIR cell. Given the wide adoption and investment in the FHIR standard, the i2b2 SMART-on-FHIR cell will support a vast array of applications.
We designed and implemented the SMART-on-FHIR cell as an i2b2 server component consisting of 6 modules: authentication module, REST API, i2b2-to-FHIR converter, resource enrichment module, FHIR query engine, and a cache (Figure 1). The source code is freely available in Github (https://github.com/i2b2plugins/i2b2-fhir-cell). A technical reference is attached as a supplementary file.
The authentication module implements OAuth2 SMART specification to control access to the REST API. Specifically, it allows a client to request read-only access to data for a particular i2b2 user.
The REST-API allows a client to query and read FHIR resources, and provides metadata about the FHIR cell. On receiving a request from the web client, it communicates with the i2b2 instance to retrieve “i2b2 observation facts” for a particular patient and invokes the i2b2-to-FHIR conversion module to construct FHIR resources from the i2b2 facts. The conversion module constructs the following FHIR resources: patient-containing demographic information, observation for laboratory data, condition for diagnosis, and medication prescription information (Table 1).
Additional semantic information is then added to these resources by the enrichment module, and then persisted on the disk cache. The enrichment/semantic module translates codes in the FHIR resources into preferred coding systems, and expands on codes in Systematized Nomenclature of Medicine-Clinical Terms (SNOMED-CT), Logical Observation Identifiers Names and Codes (LOINC), and International Statistical Classification of Diseases and Related Health Problems (ICD9), to add semantic information to the resources.
Finally, if the client request is a FHIR query, the Representational state transfer-Application Programming interface (REST-API) module invokes the query engine to execute the query for selection of a subset of FHIR resources, and sends them back to the client. The i2b2-to-FHIR converter translates the i2b2 observation facts to FHIR resources in EXtensible Markup Language (XML) format, using XQuery (Figure 2). The query engine implements the FHIR search specification. Its output is a set of FHIR resources in the form of a FHIR bundle. The cache persists FHIR resources between RESTful calls, thereby reducing redundant data retrieval requests to the i2b2 instance.
Figure 1 details the SMART-on-FHIR cell architecture, where the numbers denote the typical flow of control among the modules:
The cell protects the password of the i2b2 user (from the client app) by directly communicating with the user using the OAuth2 SMART specification. It supports 2 types of FHIR query URLs: (1) retrieval of 1 particular FHIR resource by providing the resource ID, and (2) retrieval of a set of FHIR resources of a particular type, by specifying the resource type and query name value parameters (see Table 2). The cell does not support paging, versioning (history), or tagging.
We tested the cell by accessing FHIR resources from a demonstration installation of i2b2, and tested whether a SMART app could be executed on the cell to display FHIR resources for simulated patients.
We successfully retrieved the demographics, medications, labs, and diagnoses for fake test patients. Table 2 shows example queries. The developed SMART app ran successfully, demonstrating a dashboard to summarize data. These results are demonstrated live at http://fhir.i2b2.org and http://fhir.i2b2.org/smartapp-demo.html.
I2b2 software has generally been deployed in a sidecar approach at most institutions, wherein a copy of the data from the EHR is stored in the i2b2 repository (Figure 3). The i2b2 client is used to interactively query the repository to identify patient cohorts for hypothesis testing. I2b2 software has evolved to provide a secure and scalable environment for such research operations. Another advantage of this approach is that the EHR system is not overloaded by research operations, allowing the EHR to focus on clinical operations.
The FHIR cell builds on this approach, providing an alternate channel to access the i2b2 data, which can be used to supplement clinical operations through use of apps.
The cell supports the SMART specification, which is based on the OAuth2 protocol.19,20 OAuth2 specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Hence the FHIR cell can issue access tokens to clients/apps, with the approval of users with i2b2 accounts. The tokens can then be used by the apps to access FHIR resources from the cell. Hence the cell provides an additional layer of security over existing i2b2 security.
The FHIR specification provides a simplified abstraction of a medical record with normalized data elements that app developers can understand. FHIR specifications are freely available and easy to understand and develop on.11
Currently the cell provides read-only access on a per-patient basis. Provision of per-patient data access itself enables implementation of a vast array of clinical decision support use cases. The cell is being used to develop SMART apps for decision support at Partners Healthcare and the Reachnet Consortium,21 and is expected to accelerate the development of SMART apps at PCORnet sites as an integral part of the architecture for Scalable Collaborative Infrastructure for a Learning Healthcare System (SCILHS).22 The SCILHS infrastructure supports apps to improve PCOR research methods and enables functions such as consent, enrollment, randomization, and outreach for patient-reported outcomes.
The query module is implemented using XQuery, and is generated automatically from FHIR specification. Inclusion of patient ID is required in each query (see Table 2).
In addition to conventional methods for importing EHR data into i2b2, an i2b2 extension was recently released that provides a method for PCORnet’s patient-powered research to import their patients’ EHR data in CCD format into i2b2 instances.5,23 The FHIR cell can be used to expose this data in FHIR format. This pathway lowers the barrier for smaller practices to invest in making their data available in FHIR format. In addition to supporting SMART apps, the FHIR API can also be useful in importing data from a legacy EHR system into a new EHR system that supports the FHIR standard, potentially reducing the effort required for migrating data from the legacy system.
In summary, for institutions running i2b2 instances, the FHIR cell will facilitate (1) deployment of SMART apps, (2) an additional mechanism to search and access the i2b2 repository, and (3) migration of data from legacy EHR systems replicated with the sidecar approach into i2b2 instances into new FHIR-enabled EHRs.
Currently the cell only supports read-only access on a per-patient basis. We are implementing additional FHIR resources and plan to extend the cell to allow population-level querying. Another planned feature is write capability to the cell, which will allow importing of data in FHIR format into i2b2. Including population queries and allowing apps to write data back to the i2b2 instance considerably increase the complexity of implementation, which was the rationale for currently limiting the scope to per-patient access.
We have developed an interface that provides patient data from i2b2 repositories in FHIR format on a per-patient basis. The source code is freely available online as open source. We were able to successfully retrieve the demographics, medications, labs, and diagnoses for random patients in a demonstration i2b2 instance, and were able to successfully run SMART apps to show a dashboard summary for these patients. The SMART-on-FHIR cell will facilitate i2b2 sites in providing simplified but secure data access in FHIR format, and will spur innovation and interoperability.
We would like to thank member organizations of the SMART Advisory Committee, including the Hospital Corporation of America, Lilly, Surescripts, the Advisory Board Company, Centros, Polyglot System Inc., Premier, Blue Cross Blue Shield Association, and the BMJ Group, which provide philanthropic support to Boston Children’s Hospital, which funds SMART development.
This study was approved by the institutional review board at Massachusetts General Hospital, Boston.
K.B.W. led the design and implementation of the FHIR cell and wrote the majority of the manuscript. J.C.M., J.G.K., N.W., M.M., and S.N.M. made key contributions to the architecture of the SMART-on-FHIR cell. S.N.M., K.D.M., and C.G.C. conceived of and initiated the project. All authors reviewed and approved the final version of the manuscript.
This work was supported by National Library of Medicine grant numbers K99LM011575 and R00LM011575, and National Institute of General Medical Sciences grant number R01GM104303.
The authors have no competing interests to declare.