Readers Write: Systems Integration with SMART on FHIR ─ We’ve Come So Far, Yet …

Systems Integration with SMART on FHIR ─ We’ve Come So Far, Yet …
By Dan Fritsch, PhD

Dan Fritsch, PhD is chief applications architect at First Databank of South San Francisco, CA.

When we first launched Meducation in 2009, we realized that we would have to integrate the application with electronic health records if we wanted clinicians to use it with their patients. The good news? Through our efforts, we’ve become industry leaders in such integration. The burst-our-bubble reality? Despite our success, even after 10 years, many integration challenges remain.

Because electronic health record (EHR) systems were not originally designed to accommodate third-party apps, we have found ourselves taking up the integration cause ever since we initially developed our cloud-based solution that enables healthcare providers to dynamically create fully personalized patient medication instructions in more than 20 languages.

While the integration nut is difficult to crack, we’ve experienced quite a bit of success. Case in point: In 2011 we won an Office of the National Coordinator for Health IT contest for our use of Substitutable Medical Apps and Reusable Technology (SMART) – an open, standards-based technology platform – to integrate our product with other systems.

Yet we weren’t able to fully utilize what we had developed. This SMART integration didn’t allow us to leverage real-time data, but instead required data to be transformed and stored in an alternative format. While we had established ourselves as a systems integration trailblazer, we still didn’t experience the live integration needed.

To make integration work, we had to custom-code the product for each EHR, to accommodate each unique data access framework and each underlying data model. This meant starting from scratch with each new integration. Because of this complexity, we often found ourselves relying on outside systems integration specialists for assistance, which is a costly proposition.

When Health Level Seven International (HL7) introduced the Fast Health Interoperability Resources (FHIR) standard, SMART developed code to support it. As such, we were able to run the product in this new SMART on FHIR architecture environment. This integration model made it possible to use the same FHIR resources to implement our product on various EHR platforms without having to significantly modify code. So, if we wanted to integrate our app into 10 EHRs, we didn’t have to reinvent the wheel with each one.

At the most recent American Medical Informatics Association (AMIA) conference in San Francisco, we demonstrated how a mature SMART on FHIR integration enables us to run an app on various EHR systems, something that many other app developers are still striving to accomplish. AMIA members ranked our demonstration as the top presentation at the conference and recognized us with the AMIA/HL7 FHIR App Showcase Award.

Yet, like all app developers, we are still struggling with a variety of integration challenges, such as:

• Optimal workflow placement within the EHR. While some vendors allow our app to be launched in an optimal place – such as at the top of the discharge screen – others bury the app launch in the user interface menu, making it burdensome for an end user to find and use at the right time in workflow. We are constantly working to align with our EHR partners to realize that our application is valuable, not a threat to their autonomy.
• Juggling multiple versions of FHIR. FHIR is a young and rapidly evolving standard. Since its introduction, three versions have been adopted and implemented by various EHR vendors. Each of these standards uses a slightly different data model. As an app developer, we have to know which version each EHR vendor is using so we can modify our code to support that particular iteration.
• Coping with vendors’ interpretations of resources. To function optimally, our app needs to know the patient’s medication list at the point of discharge, which requires specific resources (specific pieces of information). This information is represented in FHIR by either the “Medication Order” resource or the “Medication Request” resource, or sometimes by a combination of both. As such, we often need to query both of those resources and run an algorithm that gives us the discharge medication list that we need. As FHIR becomes more mature, there will be more agreement among the vendors on what the resources mean, but for now, we need to continue to find ways to deal with each vendors’ interpretation.
• Dealing with costs. As a developer, we have to cope with fees to enter developer programs; certification costs; legal fees associated with intellectual property protection; costs that sometimes arise when developers need additional integration assistance from vendors; and royalties paid to EHR vendors. These fees are costly and are prohibitive to many smaller companies.

So while we have been able to establish ourselves as integration leaders, especially around SMART on FHIR, we still, like all other app developers, have our work cut out for us. We look for forward to continuing to pave the way and challenging the status quo.