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 Programming 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 providing 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 the 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 integrate 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 a departure from the then-inflexible EHR architectures to platforms that could not support third-party apps. The 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.
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.
The open-source tools facilitate the development of clinical applications by developers. Some of the tools include a web-based FHIR resource editor that aids the innovators in structuring sample data for their applications and a free API “sandbox” server to test the apps. The libraries are accessible for Python, iOS, and HTML5/Javascript.
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 are 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 of 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 an FHIR application operates in a SMART on an FHIR system, extending its performance through the use of contextual and clinical data.
Comparison of SMART on FHIR to the previous standards
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.
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.
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 payloads
A SMART app must first be registered with a given EHR 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 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.
With SMART-enabled apps, users are empowered to decide on the health IT products that they deem to be beneficial and valuable.
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.
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.
SMART streamlines internal EHR customization projects; this increases the return on EHR investment.
Let's work together!
Have questions? Ask anything!
Monday – Friday
9 AM – 5 PM EST
DISCLAIMER: ConductScience and affiliate products are NOT designed for human consumption, testing, or clinical utilization. They are designed for pre-clinical utilization only. Customers purchasing apparatus for the purposes of scientific research or veterinary care affirm adherence to applicable regulatory bodies for the country in which their research or care is conducted.
