SMART on FHIR Applications: Best Practices

SMART on FHIR Applications: Best Practices for Security, Monitoring, and Burden Reduction

SMART (Substitutable Medical Applications and Reusable Technologies) was a joint venture between Harvard Medical School and Boston Children’s Hospital to develop a platform to enable secure access to healthIT data providing greater medical interoperability between the IT solution, an EHR (Electronic Health Record), and healthcare providers. SMART on FHIR Applications are applications built using the SMART on FHIR API, OAuth2, and OpenID Connect. SMART utilizes FHIR resources and, with the passing of the 21st Century Cures Act and 2020 Final Rules from the Office of the National Coordinator for Health Information Technology’s (ONC), has become a certification requirement for health IT developers working under the ONC Health IT Certification Program. The SMART on FHIR API usage has increased in recent years, with integration being built into major EHR products such as Apple health apps, and Microsoft applications.  With this increased usage of SMART on FHIR, and subsequently FHIR-enabled resources, let’s look at some of the key points of building a successful SMART on FHIR application.

Application Security and Authorization

Adding new layers of security to health information technologies includes OAuth2 for authorization and then OpenID Connect for authentication after that. There are two main types of SMART on FHIR applications – Public Applications and Confidential Applications. Public Apps are client-side (browser/web-based apps) and are unable to protect potential secret keys from users. Confidential Apps are run on trusted servers that access any secret keys and conceal them from possible end-user exposure. SMART on FHIR applications allow for access tokens that work within user permission policies, so access is still restricted to relevant information. Access tokens can be restricted specifically to single patient viewing as well, instead of always allowing broad access to information. A SMART on FHIR application will utilize both Refresh and Access tokens which will work in tandem to maintain the security of the application.  When a user logs in, they will be provided a Refresh and Access token that will tell the server what information they are allowed to access and view.  The Refresh token will allow the user to continually receive new Access tokens during their session so that security can be controlled via the application.  If someone tries to access specific information they are not authorized to view, the application will send an error message regarding the information and the application will create an audit log of the event.  We’ll discuss how these audit logs are important for monitoring the security of a SMART on FIHR application next.

Monitoring our Application

Monitoring with FHIR Resources

One way application developers can track the security of our application is using the ‘AuditEvent’ FHIR resource. This resource creates logs of events related to our application, including logins, who or which actor is accessing the application, and confirm that our access control is properly functioning. It allows us to view user activities (login, logout) and sever activities (REST operations and Search operations). With AuditEvent, we get the elements of ‘purposeOfEvent’ and ‘purposeOfUse.’ ‘purposeOfEvent’ provides us the information of the activity that resulted in the log event. ‘purposeOfUse’ provides application developers the reason the actor (machine, person, software) is interacting with the system and thus logged an event. Both purpose resources can be null, but if the program is aware of the reason for either it can provide us insight into why and how our system is being accessed.  This knowledge provides us valuable security information to ensure properly credentialed users are the only ones accessing the program and ensuring that the system is correctly blocking unauthorized users.

Monitoring with API Identifiers

Another way to monitor the activity of an application and security is using an “x-request-id” system.  With every API call initiated from an end-user, this special id will be included and will show up on our AuditEvent logs. In an instance where the application falters, the “x-request-id” will provide us relevant information related to which feature or user-type made the call. By tracking this information, application developers can assess whether there was an attempted security breach and address the route by which the attacker tried to exploit or if the issue was caused by a faulty feature of the application itself.

Burden Reduction through SMART on FHIR

One of the goals and targets of the ONC 21st Century Cures Act (Cures Act) was to reduce information blocking amongst payers and providers. By addressing information blocking, the Cures Act seeks to reduce the burden on all relevant players – patients, providers, and payers. Reducing the burden means implementing technology that makes it easier to obtain required information for all players.   One example of this relates to prior authorization information.  Prior authorizations require multiple communication steps between providers and payers and this communication process can be tedious and time consuming. Different APIs were suggested to help alleviate confusion and time consumption surrounding different steps of the process. Timeline standards were also put forth to decrease the time to authorization once the process was initiated. When putting this into the context of a SMART on FHIR application, it is important to analyze the application and view it from the standpoint of how many ‘clicks’ does it take to accomplish the task the application is needed for.  It is important that the application is clear and concise.  We do not want to create extraneous burden for providers or patients when creating SMART on FHIR applications.  The goal should be to provide enough information needed to accomplish the goal in as few steps as possible for the user.

GigaTECH specializes in working with FHIR and SMART on FHIR applications.  We create functional, concise, and easy to use applications to accomplish tasks as small as triaging service tickets for customers all the way to importing bulk FHIR data from insurance databases for use by hospitals and clinicians, as they seek a holistic view of integrated health information to support clinical decisions. For a more in-depth look into how GigaTECH addresses software concerns and problem solving, check out one of our recent white papers.

For a more in-depth look into how GigaTECH addresses software concerns and problem-solving, check out one of our recent white papers.