FHIR, SMART and Sidecar Applications
July 10, 2015 4 Comments
I was reading the SMART on FHIR support group and came across this post from Wes Rishel. I thought it was really good, and so asked him if I could duplicate here. Not only did he agree, but he added some more stuff to it!
Thanks Wes…
Just before I retired last year I wrote a Gartner Research Note Healthcare Delivery Organizations Should Avoid These Pitfalls When Using Sidecar Integration. That note is only available to Gartner clients. In it I recommended the use of FHIR and SMART for a certain style of integration (recognizing the preliminary nature of those technologies). Recently Chandan Datta read the article and sent me some questions. This post is based on my reply to him and shows how my thinking has evolved since I retired from Gartner.
My fundamental point is that there is a natural, incremental path forward for SMART and FHIR. While it doesn’t represent the full power of either technology it is the path of least resistance for these technologies to gain a foothold in production use and quickly bring value to the healthcare industry.
Definitions:
Electronic Health Record a system that is the repository of virtually all patient-specific healthcare information stored by a care delivery organization, and is used day-in and day-out for the workflow of providing care. This includes looking up clinical information about a patient in order to diagnose, create a plan of care and monitor and modify the plan. It covers all care settings of the care delivery organization and may provide cognitive assistance to care providers in the form of trending information, alerts, work lists, disease- or patient-specific displays and any future “miracles of healthcare IT.” (Note: the terms that are used for enterprise medical record systems vary from country to country. EHR is pretty much a blatant Americanism. I will use it in lieu of a truly international term.)
Visual integration is the combined use of two applications by the same user during a workflow where both applications are presenting information visually and usually accepting inputs from the user. The combined use may happen simultaneously, as when one application runs in a pane that is part of the overall layout managed by the other application, or the user may click between the user interfaces in rapid succession as part of a single workflow.
Sidecar applications are those that supplement an enterprise EHR application without taking over the fundamental workflow that is orchestrated by the enterprise app. For the most part sidecar applications are visual (that is to say they have a user interface) although one can certainly imagine side car applications that operate as daemons.
Although SMART does not use the term sidecar, most, if not all, of the examples of SMART that are circulating are sidecar applications.
Sidecar applications are, theoretically, much simpler to write because the massive problem of structuring all clinical data and designing to support required the workload and response time for a large organization are not in the wheelhouse of the sidecar app developer. They often do not need to be designed with the extensive configurability necessary to support the ICU and the podiatry clinic.
Sidecar appls ought to be easier to market because a decision to use one does not usually impacts the daily work of tens of thousands of healthcare providers. They might be offered to specialized groups such a pediatric cardiologists, diabetes care managers, or gerontologists. They might be adopted by individuals within those departments or by the entire group.
Sidecar apps ought to be easier to implement for the same reasons. They ought to support rapid innovation because the user community can be small enough to enable an informal relationship between users and developers in the best spirit of extreme programming.
In the 1990s my consulting practice included a major component of users and vendors trying to create a market for sidecar applications implemented through component technology. I supported many failures in this area, in part because the technology of visual integration was not ready but mainly because the vendors of enterprise systems saw no economic case for enabling sidecar apps among their customers.
Chandan asks:
- Who can write the apps?
- Who can use the apps?
- Who will sell the apps?
- Will it work in countries other than the US?
Here are some answers for your consideration.
Who can write the apps? A somewhat trivialized answer is “whoever has the technical skills and a valuable idea on how to enhance the work of users of the EHR.” Some important classes of authors include innovators within healthcare delivery organizations, EHR vendors looking to enhance their products with very compartmentalized efforts and entrepreneurs hoping to sell incremental enhancements to healthcare delivery organizations or EHR vendors.
The next question has a more interesting answer.
Who can use the apps? The practical answer is any organization that uses an EHR providing the use of sidecar apps is supported by the vendor of the EHR. Although various users and policy makers would like to force vendors to accept interoperability there are many pragmatic reasons why the power lies with the vendors of enterprise EHRs.
Fortunately, there is reason to hope that the major vendors will see better technological and economic reasons to support FHIR and hopefully SMART on FHIR.
- Technology has come a long way towards enabling secure visual integration.
- FHIR interfaces are at least putatively easier for small programming shops to understand and use leading to less vendor time distracted by having to support the sidecar vendors.
- FHIR interfaces are putatively easier to control to avoid impacts on overall application performance and data integrity.
- FHIR interfaces can be constructed so as to offer some modularity between sidecar products and versions of the application.
- As the prospects of EHRs become larger organizations, they face increasing pressure to include integration
- The history of the Internet and smartphones has demonstrated that large organizations can substantially increase the value of their own products by allowing thousands of entities to create applications. Many of these will fail, but that is not a business risk assumed by the large vendor. Some of these will marginally increase the value of the big product and perhaps from time to time one will be a “killer app” that revolutionizes the market. Look for the distribution of sidecar apps through mechanisms that are similar to an “app store.”
- Successful sidecar apps don’t threaten the lock-in of enterprise apps. If a sidecar vendor develops a brilliant sidecar for a competitor’s enterprise product economics favor the sidecar vendor offering its app to users of the other enterprise apps.
- Where a sidecar app is an innovation that is in line with the strategic direction of an enterprise vendor it has options to gain control of it including buying the vendor and simply reinventing the sidecar app with enough variation to avoid intellectual property issues.
Who will sell the apps? Innovators who have worked in care delivery centers will create startups in their virtual garages. Sizeable specialized vendors in allied fields will develop and offer apps. (Think medical appliances, specialized medical or other therapies, accreditation, large disease-specific advocacy organizations.) The market becomes increasingly attractive to all innovators if they can program once and be compatible with the largest enterprise vendors.
Item (8), above, implies a bit of caution for investors and also for users. What Epic user would want to invest in and roll out a sidecar app to have the vendor be bought by Cerner? (Or vice versa.) But as people say in the Southern US, “bidness is bidness.” Translation: all business ventures carry risk, including the risk of predation.
Will it work outside the US? The bigger question now is will it work anywhere. Virtually everything I have written here is hypothetical. I will say that I have held this view of sidecar apps for a number of years and developed these hypotheses with respect to SMART and FHIR in 2012 and 2013. 2-3 years later we have seen a lot of progress towards proving the hypotheses and have not had substantially modify them to maintain our belief. If it works in the U.S. I would expect it to work in any country that represents a large market for the major enterprise vendors.
In countries where the market is dominated by other enterprise vendors it can still work if the technological hypotheses are proven in practice and if policy makers are willing to forsake grand schemes about total modularity of EHRs for incremental progress.
What I say here represents only my own opinion, not that of Gartner or any of the non-profits with which I have worked.
About David Hay
Pingback: Implementing SMART on FHIR in an EHR | Hay on FHIR
Pingback: Using SMART to talk between systems | Hay on FHIR
Pingback: What is SMART and why should you care. | Hay on FHIR
Pingback: Sidecar EHR Apps: SMART and FHIR Lift Vendors Over the Hump and On to New Humps - Retired Healthcare IT Nerd