SMART (Substitutable Medical Apps, Reusable Technology) is a platform that seeks to integrate apps across different healthcare IT systems. This computational health informatics program was developed to open Application Programing Interface (API) specifications for Electronic Health Records (EHR) data access. The EHR system refers to any system that can control and keep individually identifiable health information. Such a system should be able to authorize access to Fast Healthcare Interoperability Resources (FHIR) and mediate app requests. With this platform, an app written once can integrate and communicate freely with portals, Electronic Health Records, Health Information Exchanges and other different healthcare IT systems without any hindrances. The SMART platform facilitates this integration by adding EHR UI integration patterns to FHIR, adding a standard set of data profiles that improve FHIR and provides secure and reliable authorization technologies (OAuth 2.0 and OpenID Connect).
With this, innovators and app developers can develop apps that can securely and seamlessly integrate into the healthcare system. Doctors, patients, and other players in healthcare can make use of the library of apps supported by the SMART standard to improve clinical care, public health and research and development domain. To further support this initiative, the five largest electronic health record vendors, the HL7 organization (Health Level Seven International) and the SMART team launched the Argonaut Project. The Argonaut project seeks to standardize the SMART API in HL7 specifications as well as integrating SMART into the releases of EHR products. The Argonaut project seeks to further enhance the sharing of electronic health information by developing a Core Data Services specification; an FHIR based API as well as a Security Implementation Guide. With this, providers and other interested vendors can design and apply a complete FHIR API specification and the necessary security implementation.
Kenneth D Mandl and Isaac S Kohane were some of the first people to propose for a departure from the then inflexible EHR architectures to platforms that could not support third-party apps. Establishment of a common interoperable data specification was necessary for the current mobile app space, for EHR systems to support such apps without expensive custom integration. As opposed to the then inflexible EHR architectures and other interoperability and data exchange efforts, SMART was different in the sense that it centered on creating tangible vendor-independent apps that were immediately interoperable. The project of developing the platform began in 2010; it was started by Harvard Medical School Department of Biomedical Informatics and the Boston Children’s Hospital with funds from the U.S. government to the tune of $15M on a four-year contract. Since then, many clinical applications have been developed.SMART platform helps healthcare systems integrate. See how.Provides resources and open source tools that facilitate the creation of clinical applications. Smart also makes it much easier and cheaper to integrate apps with customers EHR systems.With SMART enabled apps, users are empowered to decide on the health IT products that they deem to be beneficial and valuable. App Gallery
The app gallery is publicly accessible, not restricted to a single EHR platform and creates a platform that connects app developers and the intended users. The gallery enables the developers to share the apps that they have come up with and also gives healthcare providers the opportunity to try out new SMART compatible apps with a single click.
Tools for developers
With open standards, clinical applications developed can integrate with different health data systems seamlessly. Apps can be developed to meet the diverse needs of patients, clinicians and other players in healthcare without requiring specialized knowledge about a given health data system.The first open Specification that could support substitutable Apps was SMART Classic. It was released in 2011. Between 2011 and 2013, there was a slow adoption of this platform by EHR vendors as by then; third-party medical applications had not yet become a key business driver for them. The slow adoption was mainly because the EHR vendors had specific concerns and technical obstacles such as the lack of population-level API, the solution to write API and the focus on clinical data and the exclusion of other types. In addition to this, EHR vendors were displeased with the API and the SMART data model because they did not factor in recommendations from the health IT standards community.
SMART Classic used RDF to present common clinical statements. Resource Description Framework (RDF) was used for this because of its flexibility and adoption in Semantic Web applications. A corresponding state transfer API that offered data access was built to expose patient-level data through a hypertext transfer protocol (HTTP) verbs (e.g., GET, POST) and through a fixed uniform resource locator structure. Clinical statements and API calls were later added and refined to facilitate richer payloads with more expressive queries.FHIR was launched to explore new approaches to interoperability as the HL7 community recognized that the HL7 Version 3 had certain limitations. FHIR’s main focus was providing a simple and easy to manage and implement API for healthcare that is supported on contemporary Web APIs. The API is a modern resource-oriented HTTP interface to update, create, search for and delete FHIR resources representing administrative, clinical and infrastructure data. Clinical data is presented in FHIR as resources. The resources are concrete, intuitive concepts e.g. procedure, adverse reaction, medication prescription, and condition. A given health system can run SMART apps and be regarded as a SMART on an FHIR system if it has adopted the SMART on an FHIR specification that includes the profiled versions of FHIR, a Web standard for authentication (OpenID Connect) and a Web standard for authorization (OAuth2). OAuth2 serves to enable an end user to approve a third party app to access a specific set of data from a service provider (e.g., EHR). OpenID Connect facilitates the signing into a clinical app by a patient or clinician (end user) by describing the OAuth2-based protocol that allows by using external identity providers. SMART on FHIR established a platform, with the necessary security guarantees, that apps could use to integrate with various EHR systems.
FHIR uses idiomatic XML and JSON to serialize resources. FHIR’s API was better for some SMART Classic functionality, in light of the EHR vendor responses on the difficulties they had with SMART classic, and FHIR resources carried out the same function as the SMART’s clinical statements. As a matter of fact, FHIR resources had a comprehensive domain coverage adding to the efficiency of the SMART on FHIR. A SMART on a FHIR application operates in a SMART on a FHIR system, extending its performance through the use of contextual and clinical data.Comparison of SMART on FHIR to the previous standards
The Clinical Document Architecture (CDA).
CDA implementation was hampered by the fact that it did not address granular data access. The specifications were based on Reference Information Model (RIM). During the Meaningful Use Stage 1 timeframe, its C32 templates are important in the provision of more detailed guidance.
HL7 Version 3
The HL7 Version 3 RIM implementation was complex leading to incompatible documents and systems. It, however, offered a platform that could express clinical documents in a semantically consistent way.
HL7 Version 2
The HL7 Version 2 required significant site customization and centered on messaging-based exchange, and this contributed to semantic inconsistencies across implementations. The messaging standard could, however, be deployed widely, and it also supported granular data payloadsA SMART app must first be registered with a given EHR’s authorization service before it can run against that EHR. SMART on FHIR uses the OAuth 2.0 standard to provide secure and reliable authorization for different app architectures.
The OAuth 2.0 authorization servers are designed such that they can regulate access depending on the formula designed to implement institutional policy. At times such a policy may include requesting end-user authorization.
To integrate apps that can operate unmodified on different health IT systems, certain aspects have to be defined beforehand that define the coding systems to be used and which data fields are optional vs. required in a given situation. So as to ensure that FHIR can operate in a variety of cases, the FHIR specification has not clearly spelled out the specifications and instead these decisions are left open to downstream implementers.
When registering with a given EHR’s authorization service, a SMART clinical application must register a fully-specified and fixed launch URL and redirect_uris with the EHR’s authorization server. A clinical app platform must first address some pertinent issues such as constraining resources, data validation and curbing semantic fragmentation before being integrated with EHR systems.Pure client-side apps such as Windows desktop apps, iOS mobile apps or HTML5/JS browser-based apps cannot “keep a secret,” in the OAuth2 sense, but they are however able to provide adequate security. As such an end-user or attacker can potentially extract any “secret” string, code or key that is inserted in the application. Security assurance for these apps can then only be confirmed when hosted within a trusted server environment as opposed to relying on secrets embedded at install-time.
The SMART App Authorization profile defines how an application can request authorization to access and retrieve an FHIR resource. Other HIPAA (Health Insurance Portability and Accountability Act of 1996) mandated security mechanisms e.g. session time-out, accounting of disclosures, security auditing and end-user authentication are not covered in the profile.
The confidential app profile can only be applied when the app is operated on a trusted server, can protect a client_secret and has a server-side business logic (e.g. using Python, PHP, .NET or Ruby). On the other hand, the public app profile is applicable if the app cannot protect a client_secret and when it is operated on an end user’s device (e.g. native iOS, HTML5/JS in-browser, Android or Windows).
SMART on FHIR defines how applications can obtain authorization tokens; this is important in enabling apps that run across heterogeneous security environments. SMART on FHIR also permits servers to adopt any necessary policies to determine a user’s permissions.
An app can launch as a standalone app or within an existing EHR session. In a standalone launch, an app during the authorization process can request context from the EHR authorization server. In this case, once it is launched it redirects its authorization request to the EHR’s authorization server so as to request authorization to access an FHIR resource. Depending on the end-user authorization and the pre-defined rules, the EHR authorization server can either deny the request or grant it by returning an authorization code to the app’s redirect URL.
Alternatively, in an EHR launch, as part of the launch URL, an opaque handle to the EHR context is passed along to the application. When the app is requesting authorization to access resources, the inclusion of this context handle is necessary as a scope parameter.For patients and other healthcare providers
With SMART enabled apps, users are empowered to decide on the health IT products that they deem to be beneficial and valuable.
For app developers
Provides resources and open source tools that facilitate the creation of clinical applications. Smart also makes it much easier and cheaper to integrate apps with customers EHR systems.
In public health
SMART facilitates decision support since updates can be made rapidly without having to customize for specific EHR, this greatly enhances rapid response in times of outbreaks and as guidelines change.
SMART improves efficiency in public health since the apps developed can transfer workflow and functionality in one package. A great App developed can be distributed widely, something that has the potential to reshape the service overnight.
In health care institutions
SMART streamlines internal EHR customization projects; this increases the return on EHR investment.SMART is a health data layer that is based on FHIR API and resource definitions. SMART standards make use of the robust authorization model (OAuth standard). This standard facilitates innovation while keeping providers and patients in control of their data. SMART aimed to produce specifications that work for forward-thinking medical app developers and are implementable within today’s evolving healthcare technology landscape (Mandel et al. 899-908).
SMART is an important addition to FHIR since it enables third-party application services and substitutable health apps. The detailed set of core data models that is provided by FHIR may be under-constrained in the vocabularies and many fields optional because of the many diverse requirements supported across the many use cases and in the varied regions. SMART uses a set of profiles to enable third-party application services; these help the app developers to know what to expect about the vocabularies used to express problems, medications, labs, and other clinical data.
Through the SMART CDS Hooks and the SMART Genomics initiatives, the SMART project is helping define the next generation of FHIR based standards for the integration of clinical decision support into provider workflows and the clinical use of genomic data.Mandel JC, Kreda DA, Mandl KD, Kohane IS, Ramoni RB. (2017). SMART On FHIR: A Standards-Based, Interoperable Apps Platform For Electronic Health Records. Journal of the American Medical Informatics Association. 23.5: 899-908. doi: 10.1093/jamia/ocv189.