SMART on FHIR
Understanding SMART (Substitutable Medical Apps, Reusable Technology) and why its use in healthcare information technology is almost a must because it hopes to integrate applications across different healthcare IT systems. As a result, SMART is attempting to be the next step after the protocols and standards for interoperability from FHIR has been bridged. FHIR provides the tools and capabilities for these disparate healthcare systems to finally securely transmit data without the hassle from before, however, a difficulty now lies ahead in ensuring that the information that rides on FHIR have been used in a similar or the same purpose.
FHIR by itself is already very developer friendly in that it allows and employs many modern web technologies aside from the coding languages, such as OAuth for added security, and REST for improved efficiency and connection establishment. REST is an API model that helps shuttle FHIR between servers and users. Because of its infrastructure, it allows for easier sharing in data exchange because it does not necessarily need confirmation from the opposite party at that exact moment. XML and JSON are both data describing formats and help with providing the user with information after connection establishment. FHIR comes from the HL7 company, which released HL7 v2 and HL7 v3, which were predecessors to FHIR in their goal of improving interoperability standards in healthcare. Unlike its predecessors though, it is freely available for developers without restrictions.
This is meant to help open up the Application Programming Interface (API) specifications that will allow Electronic Health Records (EHRs) to have access to. In short, SMART hopes to provide a framework for medical applications that will essentially piggy back on the interoperable standards set by FHIR in regard to private health information without any hindrances. As a result, SMART on FHIR will allow developers to create apps that can securely and seamlessly integrate into the healthcare system and allow the healthcare professionals and administrative staff to have all of the necessary information available at their fingertips to provide the best quality care available. SMART will allow for a library of apps to improve clinical care, public health and research, and the development domain. However, a challenge lies in the healthcare system and their ability to remain at least somewhat up to date with new technologies. Many hospitals are in a constant state of transition, be it from technologies to different managing companies with mergers and buyouts, and all of these will require data transfer between them. If data is disparate and without structure, therefore interoperability is still a challenge. Additionally, it is not anything new that the information technology infrastructure of hospitals is often well behind compared to other industries.
As mentioned before, FHIR was launched to help with the initiative in improving interoperability without the closed standards and high cost floor that HL7 v3 offered, another interoperability standard released by the HL7 community. FHIR aimed to provide a simple and easy to manage and implement API for healthcare that can be supported through contemporary web and computing standards. FHIR allows the ability to update, create, search, and delete FHIR blocks and resources for administrative, clinical, and infrastructure data. In fact, there are 6 categories of resources: clinical, workflow, conformance, identification, financial, and infrastructure. Not only does it have these capabilities standalone, but SMART on FHIR allows developers and even the healthcare professionals to onboard easily, reuse logic, share code, and easily build on existing templates to fit the purpose. By even taking it into the cloud, it can be used for data analytics in integrating clinical and financial information. Even though most hospitals now have EHRs, only a few hospitals are actually able to use them to its fullest potential in terms of finding, sending, receiving information. Despite being relatively simple tasks, the disparate formats and lack of standards during the initial comeuppance of EHRs make information manipulation difficult not just between healthcare systems, but also within healthcare systems as well because certain data blocks and modules can sometimes be used for different purposes.
Compared to some other previous standards:
Clinical Document Architecture (CDA) – CDA is a small subset of what SMART on FHIR covers, meant for documentation of various clinical tasks and procedures. However, CDA implementation in previous standards was overburdened by various granular data processes and has since been improved.
HL7 v3 – The latest of the HL7 standards, however due to a high cost and complex implementation, it led to a disparate adoption with incompatible documents and systems. However, HL7 v3 was the first step in expressing clinical documents in EHRs in a relatively consistent way or at the very least it provided the format for a consistent manner.
HL7 v2 – An older standard that required significant customization.
Overall, SMART is a health data protocol and layer that piggybacks onto the FHIR API and resource blocks. SMART allows integration of robust authentication models with OAuth while facilitating innovation for developers to create apps that can help healthcare professionals and patients stay in control of their data instead of not making any sense of it. FHIR provides a detailed set of data models that can be used in many fields and SMART uses those to enable applications that can help with medication, lab results, and other clinical data. In doing so, developers and the healthcare environment hope that it can optimize workflows for more efficiently doing the things that drives the organization forward. Additionally, it hopes to increase patient engagement and better clinical outcomes through pre- and post-care and can reduce the idea of turnstile medicine and readmissions. Clinical outcomes help with pay-for-performance with the upcoming and already implemented MACRA system.