Everything You Need to Know About SMART on FHIR
It may be the hottest acronym in health IT: FHIR (pronounced “fire”), an evolving draft standard for data exchange between technology systems from different vendors, can best be described as a foundation for healthcare interoperability.
What Is FHIR?
First proposed in 2014 by the nonprofit organization Health Level Seven International, FHIR, which stands for Fast Healthcare Interoperability Resources, lays the groundwork for electronic health record systems to “speak” with third-party applications using a common language.
The specification, according to HL7, “leverages existing logical and theoretical models to provide a consistent, easy to implement, and rigorous mechanism” for such communication within a healthcare organization. FHIR, the organization explains, is meant to be used by the “implementation community — those who will actually write the software that uses the specification.”
Healthcare Is on FHIR: Interoperability Takes Hold
Today — almost five years after FHIR was introduced — all signs indicate that the software-developer community is on board.
“The U.S. is Poised to Catch FHIR in 2019,” announces one recent blog post by Steven Posnack, director of the Office of Standards and Technology in the Office of the National Coordinator for Health Information Technology.
More than 80 percent of hospitals and 64 percent of clinicians are now using EHRs that embrace FHIR, says Posnack. EHR vendors, he adds, are increasingly adopting the standard because it allows them to meet ONC certification criteria related to application programming interfaces: “The United States might be at a turning point when it comes to the adoption and implementation” of FHIR in health IT, he says.
SMART on FHIR Aligns EHR Data, Apps and Tools
If that turning point has, in fact, arrived — and most health IT leaders agree with Posnack that it has — it may be in part because of a project called Substitutable Medical Apps, Reusable Technologies, or SMART.
Back in 2010, explains Joshua Mandel, chief architect at Microsoft Healthcare, a team of software engineers and clinicians at Harvard Medical School and Boston Children’s Hospital launched SMART in an effort to develop a standards-based app platform for healthcare.
“The idea,” says Mandel, who was lead architect on the project, “was that patients and clinicians should be able to pick the healthcare apps that they want to use and plug those apps into the EHR system they have.”
A few years later, as the SMART project gained steam, it became clear to Mandel and others that their initiative shared many of the same goals as HL7.
“We realized there was this critical mass growing around FHIR, and that it would be better to align with and help shape the direction of that project rather than create a competing set of APIs.” SMART on FHIR, as that alignment became known, puts the SMART project’s platform of open-source tools for app developers on top of the FHIR API, Mandel explains.
“FHIR provides a standard set of data models or resource definitions to say, ‘Here is how we can represent a medication or a problem or an allergy.’ And SMART builds on that to say, ‘Here’s how we can plug an app into the EHR that uses those standard type of data.’”
SMART on FHIR Moves Toward the Future
So, what should health system CTOs understand about SMART on FHIR?
First, says Aneesh Chopra, former chief technology officer of the United States, it’s important to know that the technology represents “best practice” in internet-based health-data exchange.
Second, he says, given the legal requirement for Medicare providers to employ certified EHR technologies, organizations should either choose certified-EHR vendors that support SMART on FHIR (vendors participating in the Argonaut Project do), “or if your vendor doesn’t conform to the spec, start pressuring them to do so.”
Finally, says Chopra, who is now president of the healthcare analytics company CareJourney and a member of the SMART advisory committee, if your EHR system does support SMART on FHIR, start thinking about potential use cases for the technology.
The SMART project maintains an “app gallery” where developers can share their latest offerings and providers can try out SMART-compatible apps. And it provides resources for building applications to run on the SMART platform, including a list of app-development companies, a tech stack for SMART health apps, and free API “sandbox” servers where new apps can be put to the test.
“I think organizations that look at this will find many opportunities to improve how they use their EHR systems,” says Chopra. “The idea that a physician can download an app, safely and securely, to reduce the burden they face related to entering data into the system? Or that you might build an app that makes your EHR better? Those are the real headlines in my opinion — that this technology can make a difference right now.”
