SMART uses for public health

From Clinfowiki
Revision as of 01:15, 1 May 2017 by Mkochmann (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

== What is SMART == [1]

SMART stands for Sustainable Medical Applications, Reusable Technologies. [2] 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 [3]. One Year later in 2010, they secured a 14 million U.S dollar funding through the Strategic Health IT Advanced Research Project (SHARP) of the Office of the National Coordinator for Health Information Technology’s (ONC) [4]. The first generation of SMART Apps called SMART Classics, was created using universal health IT standards like RxNorm [5], LOINC [6] and SNOMED CT [7]. The user interface would operate over HTML and JavaScript with a newly created API for data transfer. Despite holding a SMART App Competition which created multiple software applications for use cases in 2011, large EHR vendors were not interested in this new technology [8]. The fundamental problem was the creation of a standard API that all vendors could accept.

At the same time, it became apparent that the new version 3 of HL7 was unsuccessful and out of this failure the new “Fast Healthcare Interoperability Resources” (FHIR) API emerged [9]. FHIR focused on providing an API for healthcare that was “simple and easy to implement and manage, “ inspired by contemporary Web API’s [7]. FHIR’s API offered a superset of SMART Classic functionality, and was there for adopted by SMART coining the term SMART on FHIR [8]. Since 2013 SMART has been collaborating with FHIR creating a symbiotic connection. The breakthrough for SMART on FHIR came at the Healthcare Information and Management Systems Society meeting in 2014 where they showcased six SMART on FHIR apps. With hospital systems like Intermountain Health [9] and Geisinger [10] starting to create their Apps in the SMART on FHIR envelope EHR vendors became interested. With the Meaningful Use Stage two, interoperability became more important [11]. Currently SMART on FHIR has many more challenges ahead before becoming a viable App ecosystem which will be discussed in “Future Challenges for SMART on FHIR implementation.”

Technical Overview of SMART on FHIR Apps

SMART on FHIR Apps are built on three pillars. The first one is FHIR’s ReST API, the second the FHIR Profiles and the third one the SMART platform itself. FHIR’s ReST API uses resources (i.e. Medication, Patient, Order…) that defined 80% of the common used cases for that category to capture the information. The remaining 20% can be added on using extensions.

The second pillar, the FHIR Profiles, are used to constrain a resource allowing the “plug and play” feature. FHIR profiles set the number of resources and define the nomenclature (i.e. SNOMED CT, LOINC, …) that is needed to generate the information, which is especially important for complex entities. One resource can be part of multiple profiles, and one profile can include various resources and extensions to describe the entity.

The third and last pillar is the SMART platform itself. A SMART app is a web app that is embedded into the vendor’s EHR. It uses HTML5 and Java Script. The URL of this web app contains enough information to know how to communicate to the data source that is specified by the FHIR service from that EHR to fetch the data. The app authenticates itself using the security standard OAuth2 [12].

Benefits of SMART

The rapidly changing and complex health care landscape requires short cycle, nimble innovation of novel solutions to health care challenges. Vendor developed EHR’s, with their long development cycles and unwieldy proprietary platforms , do not allow for the rapid development and deployment of useful, malleable and swappable applications to meet regional and national needs in a time frame that is responsive enough to meet the public good or private imperatives. Use of SMART programming is particularly useful to address public health imperatives such as disease outbreaks and preparations for mass gatherings.

Examples of Current and Future Applications

Current and future apps can be grouped too but are not limited to the following categories:

Decision support ;Mobile Health ; Integration of external data into workflow (i.e. Genomics); National scale services

In all cases, the app fills a particular niche that the current EHR does not cover or covers insufficiently and will micromanage that entity. During HIMSS 2014 the SMART group showcased six applications:

Decision support SMART Apps likes this Bilirubin Chart [13] developed by Intermountain Health [14] present the laboratory results of total bilirubin in front of the hyperbilirubinemia nomogram to improve decision making.

Mobile Health OpenHRE on SMART developed by Lightbeam Health Solution [15] collects patient data from all the connected facilities giving patients in the community access to all their records from all facilities in the patient portal on all their mobile devices.

Integration of external data into workflow (i.e. Genomics) SMART Precision Cancer Medicine [16] compares a patient’s diagnosis-specific somatic gene mutation(s) to a population-level set of comparable data. Context-specific links within the app connect to WikiGene [17], My Cancer Genome [18], and HemOnc.org [19].

National scale services The recent Ebola crisis in the US highlighted the deficiencies in our current EHR infrastructure to rapidly respond on a national level in a coordinated fashion to public health threats. [10] 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.[11] 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. [12] 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 [20]. 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 [21] 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 [22]. 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 [13] by disseminating standardized, generalizable, easily digestible but locally applicable frameworks to screen for and manage disease in individuals or populations.

References

  1. What is SMART. Accessed 7/30/2015. http://smarthealthit.org/about//>
  2. NEJM- No Small Change for the Health Information Economy". http://www.nejm.org/doi/full/10.1056/nejmp0900411>
  3. Strategic Health IT Advanced Research Project (SHARP) [1]
  4. RxNorm [2]
  5. LOINC [3]
  6. SNOMED CT [4]
  7. JAMIA- SMART on FHIR a standards based interoperable apps [5]
  8. FHIR [6]
  9. Mandl KD. Ebola in the United States: EHRs as a public health tool at the point of care. JAMA. 2014;312(23):2499-2500.>
  10. McCann E. Missed ebola diagnosis leads to debate. http://www.healthcareitnews.com/news/epic-pushes-back-against-ebola-ehr-blame-shifting. Updated 2014. Accessed July 30, 2015.>
  11. Dill S, Ahn J. Drug shortages in developed countries--reasons, therapeutic consequences, and handling. Eur J Clin Pharmacol. 2014;70(12):1405-1412.>
  12. Friedman CP, Wong AK, Blumenthal D. Achieving a nationwide learning health system. Sci Transl Med. 2010;2(57).>


Original Article by Karen Pinsky

Submitted by (Matthias Kochmann)