“You can do anything, but not everything.”
— David Allen
You can’t be great at everything.
This is particularly true in the world of hospital information systems (HIS) and electronic medical records (EMRs). They do an amazing job of capturing, processing and visualizing an array of core data, but will never be able to satisfy the demands of every single provider (Physicians, Nurses, Physiotherapists, etc.) working in different areas of specialization (Emergency Department, Family Medicine, Mental Health, etc.) who need functions and modules that allow them to interact with data differently as depicted in Figure 1.
If HIS and EMR product vendors offered app stores, it would allow them to focus on their core while allowing others to develop apps to cater for this variety of user needs that could run in the EMR or HIS product.
It would be very hard for a single product vendor to convince developers to build apps based on each vendors’ unique API and development tools. This is largely due to the limited market size that would be constrained to purchasers of the specific vendor’s products.
Enter SMART on FHIR. SMART on FHIR is a specification for a common API that product vendors can adopt for their own app marketplaces. It allows developers to create apps capable of running on a variety of vendors’ products, resulting in increased market
size, increased potential for profit and increased value to a larger number of users.
SMART on FHIR uses modern standards like OAuth to handle identity management and uses FHIR (HL7’s latest standard for trial use) as the standardized data model and syntax for how apps can expect data to be provided to them from the underlying EMR or HIS.
You can go to the SMART on FHIR website today and see a variety of apps already available, such as Boston Children’s Hospital Cardiac Risk app, or Vanderbilt University Medical Center’s SMART Precision Cancer Medicine app. Both provide real world examples of how common data and API standards can fulfil different user’s needs. The SMART on FHIR website also has a development sandbox and an easy way to register apps in several short steps.
Product vendors like Cerner and Epic have already launched their app stores based on the SMART on FHIR API1. Be warned however that if you’re a user of one of their products and you expect you can simply download a SMART on FHIR app and start using it immediately, you’ll likely be disappointed. Unlike your phone where you control how and when to install apps, HIS’ and EMRs have more complex deployment models and degrees of control afforded to users.
If the HIS is deployed in a hospital’s data centre and the hospital has a high degree of control over the various system layers, the IT department would be in a good position to help users install and access SMART on FHIR apps. Compare that to a true, multitenant, cloud-based EMR product where the EMR vendor has full control over the system layers. In that situation, the EMR user has to rely on the EMR vendor to make the SMART on FHIR app available to them. In either case, the user is essentially dependent on someone else to make the app available to them.
Ultimately, control will rest with the product vendors to decide if they will offer an app market in the first place. At first glance this may seem disheartening, but this is a good thing because it allows vendors to put processes in place to ensure apps provide a positive user experience, don’t introduce unintended privacy or safety risks and perhaps attempt to simplify some of the deployment challenges discussed. It also allows product vendors to establish policies for revenue and risk sharing with app developers, ultimately creating new lines of business.
Does an app developed using one product vendor’s SMART on FHIR API actually work in another’s? In our experience the answer is yes, but additional development is required. It’s not like starting from scratch, but there will always be some differences between the APIs of different companies. It also depends on the app itself. Some apps require specific data to run an algorithm, and thus are going to have a harder time being portable if the app expects a certain code from a terminology or needs a lab result and can’t anticipate the myriad units of measure that might be used to represent a result value.
Depending on the data the app needs from the underlying product, additional configuration may also be needed to cross geographical boarders. For example, an app that does a great job at visualizing and forecasting height and weight data runs off some basic constructs that are relatively standardized and could be easily designed to take into account different units of measure. However, an app that relies on an RxNorm code for a drug will work in the US, but crash if deployed in Canada since RxNorm is not supported here.
The fact that users might not have easy control over the installation of apps and some apps may not run well in different products or may not run well in different deployments of the same product definitely create some barriers to demand for SMART on FHIR apps. However, there are other scenarios outside of product vendors’ app stores where SMART on FHIR can have a big impact.
Larger organizations with dedicated IT teams can set up their own app servers and work with their in-house staff of clinical and IT experts to build and deploy SMART on FHIR apps. Duke University Health System has famously pursued this approach and demonstrated their ability to liberate data from their EPIC HIS.
Using a similar approach as Duke, jurisdictional EHR initiatives could enable SMART on FHIR apps via EHR viewers or portals. For jurisdictions looking to do more with their investments in EHR data and supporting technologies, SMART on FHIR apps would be great way to entice more users by providing more value to them. For example, the SMART on FHIR app gallery has apps for medication non-adherence, allowing physicians to see if patients are getting their prescriptions filled. These apps require data to be blended from different parts of the health care system (e.g. the GPs EMR for the prescription and the Pharmacy Information System for the dispense), which is what jurisdictional EHRs are designed for.
Another area where SMART on FHIR could have a big impact is in open source software. In past articles, we’ve written about the advancements in open source EMRs and HIS’ and how they can be used in developing countries that can’t afford North American products. Enabling SMART on FHIR APIs in open source products would increase the number of apps available to implementers around the world, and give them the benefit of first world knowledge in improving care using IT.
Whether there will be enough demand for SMART on FHIR apps to create a revenue stream to incentivize private developers to create apps is yet to be seen. However, we do anticipate that there will be lots of SMART on FHIR apps funded by health care delivery organizations, professional colleges and associations, academic and clinical research groups, and other bodies where the ability to invest in the development of an app for their own use, while allowing the app to be published and re-used by others, is aligned with their core values and business models.
It’s still early days for SMART on FHIR in Canada. We’re relatively confident that some of the large academic teaching hospitals will put effort into establishing the infrastructure and processes required to make SMART on FHIR apps available to their staff and patients. Whether we see product vendors in Canada with their own app market places remains an open question and one that we will continue to monitor in this column.