SMART uses for public health

What is SMART

SMART stands for Sustainable Medical Applications, Reusable Technologies. SMART is an application programming interface (API) that leverages the emerging FHIR standard to define health data resources, REST to access them, and OAuth for authentication. This platform allows developers to write apps once and have them run on any vendor's EHR without custom programming or development. It was created in a collaboration between the ONC and teams from Boston Children’s Hospital Computational Health Informatics Program and the Harvard Medical School Department for Biomedical Informatics.

Developmental History of SMART Apps

Mandl and Kohane first mentioned the idea of SMART applications in 2009 When Thomas Duncan presented to a Texas hospital complaining of flu like symptoms after recently arriving from Liberia, his travel history was recorded in the hospital EHR. There was some question in the aftermath of his misdiagnosis if the travel history obtained by the nurses was , in fact, viewable by the provider seeing Mr. Duncan in the emergency department on that day. There was an initial flurry of accusations and speculation that the EHR screens may not have been designed to promulgate the travel history from one part of the chart to another. Those speculations later proved to be unfounded. But following that incident, every hospital in the country gathered swat teams of EHR builders to add more explicit database elements and design surveys screens and alerts to implement more rigorous and highly conspicuous mandatory questioning of all patients on their travel history and presenting symptoms.

As highlighted by Mandl, the EHR's should have been nimble enough to be rapidly adapted to accommodate a nationally standardized travel and symptom questionnaire tailored to the emerging public health threat posed by the Ebola outbreak. Using SMART, the "CDC or another innovator could release a single app and affect the point of care nationwide."

Additional Public Health Uses for SMART

Most recently, Middle Eastern Respiratory Syndrome has reemerged, becoming the latest in a series of travel related zoonosis to threaten the health of US citizens. In the absence of SMART API's or other such plug and play strategies, most US institutions will again be faced with having to reconvene teams to perform custom builds to trigger appropriate screening and alerting for this reemerging threat.

Natural disasters and Mass Gathering preparations could be also be managed using SMART apps to collate information about hospital admissions and event related injuries. Additionally, using SMART apps designed to sift local content through national standards can drive down antibiotic over prescribing as in the case of streptococcal pharyngitis.

Another relevant application for SMART could be the management of drug shortages and backorders that have been all too common over the last decade. Managing such late breaking notification around lack of availability of essential medications within the context of a health care infrastructure that is heavily reliant on EHR's for drug ordering is problematic and time consuming. It requires national, at times global responses across wide ranging systems and weighs heavily on resources to quickly create ordering and dispensing solutions within disparate EHR's. Using SMART apps to quickly incorporate alternative dosing, formulation or dispensing strategies to interested and affected institutions would be welcome.

Future Challenges for SMART on FHIR Implementation

As an emerging technology SMART on FHIR still has a set of challenges to overcome before it can be implemented. These challenges can be grouped around three main areas: The App Store, the Apps themselves and the data that the apps will be handling.

App Store To date there has not been a vendor neutral app store announced or launched. The question would be which entity would maintain and care for such a store? Comparing the situation with the mobile world, from which the idea of SMART Apps originated, each vendor created their own store (i.e. Itunes, GooglePlay, Windows Store). These vendors created guidelines for their app stores (i.e. Apple Software Developer Kit), test and approve the functionality and compatibility of the app with their system, but are actually not liable for the content that the app delivers [1]. Even though a vendor neutral app store would be ideal, the two largest EHR vendors EPIC and Cerner have both already created their own system specific test areas for app developers. In the EPIC Sandbox [2] and the Cerner Open Developer Experience [ https://code.cerner.com/] app developers learn how to create apps and customize it to the vendors EHR for full functionality. In addition, App development has a cost which the developer would like to regain or make a profit. Participants in the app store will have commercial interests and it will be interesting to see which business models will develop around SMART apps.

Apps “First and foremost, physicians, patients, and organizations running apps must be assured that the apps they run are safe and non-malicious” said Mandel, one of the cofounders of SMART Apps [3]. This calls for a formal app certification process. Who will take the role for this process? Also, next to running safely the app also has to run efficient. Comparison again to the mobile app stores show that different apps have different system requirements and effects on the system. Who will be reliable when hospital system slows down secondary to certain SMART apps? Other questions arise around the maintenance of an application. If a company goes bankrupt what will happen to the app or if the app is no longer supported by the system, who is reliable?

Data There are four different types of data models emerging around SMART apps. 1. The app feeds data into the EHR system (i.e. wearable devices) 2. The app takes data out of the EHR (i.e. cloud based 3rd party patient portal) 3. The app exchanges data with the EHR inside the firewall of the system (i.e. disease/specialty specific diagnostic app) 4. The app exchanges data with the EHR outside the firewall (i.e. cloud based applications) In all cases highly protected patient health information (PHI) data is exchanged. The HIPPA privacy rule states that vendors who have access to PHI must have business associates agreements (BAA) with covered entities like health care providers. A new set of BAA’s has to be developed around apps company and the clinical entity running the app. Lastly, there are the risks that third parties will run unknown analytics on the PHI acquired though their apps for their own benefit (i.e. pharmaceutical companies to improve drug sales) or a data breech occur on the app vendors site.

All in all, SMART on FHIR Apps have the potential to transform the healthcare system, despite that there are still many roadblocks that need to be overcome. However, the future looks promising for this technology. There is need for more interoperability in the healthcare system and between vendor systems. Healthcare is shifting towards more patient-centered care with more patient engagement and reimbursement changing from volume to value-based care. Also, there is one more stage of financial Meaningful Use incentives left to be disseminated. SMART on FHIR could be the solution to solve many of these problems. If the last Meaningful Stage favors FHIR and SMART Apps, they have a good chance to become a new healthcare IT standard.

Summary

SMART supports the vision of a learning healthcare system by disseminating standardized, generalizable, easily digestible but locally applicable frameworks to screen for and manage disease in individuals or populations.

References

Original Article by Karen Pinsky

Submitted by (Matthias Kochmann)