SMART om FHIR has been there for quite a while now but If you’ve arrived at this article and you’re thinking “I don’t even know what FHIR is?” then we would recommend starting off by giving our What is FHIR article a quick read.
Application Programming Interfaces (APIs), particularly those that expose Personal Health Information (PHI) have security issues to consider. Substitutable Medical Applications and Reusable Technologies (SMART) is a healthcare standard, that adds a layer of security in front of FHIR interfaces to support safe access to data held within an Electronic Health Record (EHR) – or any other repository.
SMART is a standards-based, interoperable apps platform for electronic health records. It was originally developed—before FHIR was ever ignited—by the Harvard Medical School and Boston Children’s Hospital in 2010. It began an interoperability project with the distinctive goal of developing a platform to enable medical applications to be written once and run unmodified across different healthcare IT systems.
In addition to health systems providers, SMART has applicability for patients. For example, veterans can now access their health records using Apple’s SMART on FHIR health app.
Why SMART on FHIR?
At many health systems, workflows span not only different areas of an EHR but also a variety of applications and software across various physical locations. The progression of a patient over time cannot be easily viewed in one place by a caregiver.
A physician may need to log into different healthcare applications to get a complete view of a patient’s treatment and progress over time, or a doctor may have to task a staff member with manually assembling workflows. These processes take time and have an internal cost.
Let’s go to a popular example and track the progress of premature infants. When a baby is born prematurely, the initial care provided at the hospital represents one track in the overall care for the patient. The next visit could be at an outpatient office (in the same or a different healthcare system) representing a separate workflow, and subsequent appointments or hospital stays also mean additional tracks in that ongoing continuum of care.
With SMART on FHIR, this disparate data can be assembled in a longitudinal view so that caregivers no longer need to switch among different applications to piece together a complete patient story. With the unification of underlying data, a host of possibilities are unlocked. For example, applications can display graphs to offer a comprehensive visualization of patient progress. In the case of the premature infant, the visualization can display key health indicators such as length, weight, and head circumference—over time and across different caregivers and facilities.
An overview of FHIR
Initially released in 2014, FHIR (a set of standards, FHIR meaning Fast Healthcare Interoperability Resources) was a response to the need for a more contemporary standard for the exchange of information in healthcare environments.
FHIR is published by Health Level Seven International (HL7), the same HL7 that has set the gold standard for healthcare IT interoperability formats for decades. They are an ANSI-accredited standards developing organization that provides a framework for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practices and health services.
On the technical side, FHIR is an evolving set of standardized APIs among different healthcare resources. Some examples of these resources are:
· Patient
· Practitioner
· Location
· Appointment
Each resource has a detailed definition. If you’re technically-minded, here is part of the specification for the Patient Resource, which is the “who” information about a patient. Because FHIR is still evolving, the many resources (there are over 150) are at varying levels of stability and implementation readiness. At a high level, FHIR defines data structure in addition to securely retrieving and presenting the data in an EHR and other interfaces.
How SMART and FHIR come together
In 2013, SMART was updated to leverage the FHIR standard. However, that was still early on in the evolution of FHIR.
Today, SMART & FHIR represent an open, standardized, and practical means of exchanging data among EHRs, health system sites, and data sources. The SMART team maintains a sandbox and app gallery and continues to innovate with projects like CDS Hooks, Flat FHIR, and SMART Markers.
What organizations should be most excited about
SMART on FHIR is becoming a requirement for organizations nationwide, providing a compelling reason to roll out a SMART on FHIR capability. There’s more than Federal compliance to get excited about, however. Before, large EHR vendors like Epic and Cerner did not have very open APIs to encourage outside development. Thanks to a cultural shift spurred by the Federal government, apps that are compatible with SMART on FHIR will link right up to previously closed-off (but incredibly popular) EHRs. Want to see for yourself? Check out Cerner’s sandbox.
What is it like to implement a SMART on FHIR app?
The process of implementation happens in the following steps:
· The specification is developed.
· EHR vendors implement the standards and specifications, albeit differently.
· The health systems – the customer of EHR vendors – install, update, and configure their systems to incorporate the standards.
· Applications are built on top of the health system’s specifications.
HL7 creates the specification. FHIR and SMART are not platforms; they’re guidelines on how to implement a certain technology. After designing the standard, it’s in the hands of the EHR vendors to implement, and they all implement somewhat differently.
How is SMART different from Redox?
Both Redox and SMART authorize apps to achieve EHR integration, but it’s done slightly differently. The way Redox operates, the authorization layer happens at the system level through interactions with the businesses involved. Redox completes the setup process and verifies who is authorized to receive data. For example, if Redox has a set of subscriptions set up which say application X is allowed to get scheduling info from UPMC, they will not receive scheduling info from any other health systems unless authorized through our system. In an ideal state, SMART would happen at the user level (patient or provider), but right now it’s also at the system level.
Santeware’s SMART on FHIR Accelerator approach
To help healthcare companies comply with the new regulations quickly, Santeware offers a proprietary approach towards extending an existing EHR solution with SMART on FHIR capabilities and FHIR API. Depending on the technology stack or a type of infrastructure you are currently using, Santeware can recommend the right components from a multitude of available options and help put them together to make sure that those components are connected to the existing solution.
