Building SMART on FHIR Apps: A Guide for Developers

The healthcare industry is rapidly adopting FHIR (Fast Healthcare Interoperability Resources) standards to improve interoperability and data sharing. FHIR provides a common framework and API for healthcare applications to access electronic health records (EHRs) and health data repositories, creating major opportunities for developers to build innovative healthcare apps.

One way developers can build FHIR-enabled apps is through SMART on FHIR. The SMART (Substitutable Medical Apps, Reusable Technologies) platform makes it easier for developers to create web applications that seamlessly integrate with EHRs and health IT systems. This guide covers key aspects of building SMART on FHIR apps.

Overview of SMART on FHIR

SMART on FHIR leverages the FHIR standard’s APIs to provide secure access to health data. It enables developers to create apps that work across multiple EHRs and health IT systems, avoiding the need to build custom integrations. Key capabilities include:

Standardized authentication and authorization. SMART on FHIR app development uses the OAuth 2.0 open standard for authentication and authorization, avoiding proprietary mechanisms.

Portability across systems. Apps can access data in multiple EHRs and health IT systems through their FHIR APIs, avoiding custom development.

Modular design and launch. SMART apps are designed to run standalone or be launched from an EHR portal, enabling modular use cases.

User choice. Patients can choose which SMART apps access their data, enabling user-centered applications.

Overall, SMART on FHIR reduces barriers for developers looking to harness FHIR APIs and improves the user experience.

Core Components of a SMART on FHIR App

When building a SMART on the FHIR app, developers should understand these core components:

FHIR API calls. The app utilizes the FHIR API to access health data and resources hosted in the FHIR server, including authentication, queries, and other operations.

Authorization server. Handles user authentication using OAuth 2.0 and determines data access privileges based on scopes and policies.

Client app. The end-user application with a provider-facing interface, patient-facing interface, or standalone functionality. It can be web-based, mobile, or desktop.

App launch framework.  Enables seamless EHR integration with standalone launch, in-context launch from the EHR UI, or both.

App registration. Registering the app in client EHRs enables authentication, data access provisioning, and launch support.

Key Development Decisions

Some key decisions developers face when building SMART apps include:

Standalone vs. EHR-integrated. Will the app only run standalone or launch from within the EHR user interface (in context)?

Web vs. mobile vs. desktop. The front-end client app can be web-based, a native mobile app, a desktop executable, or a combination of the two.

Programming languages and frameworks. SMART does not dictate technology choices. Developers can choose languages and frameworks like JavaScript, React, Angular, .NET, Java, Swift, etc.

Open source vs. custom code. Leveraging open-source SMART libraries and code samples accelerates development. But custom code can enable tailored experiences.

Cloud vs. on-prem hosting. Depending on security preferences, FHIR servers and apps can be hosted in the cloud or on-premises. Hybrid hosting is also an option.

Implementing SMART App Authentication

A core building block of SMART apps is integrated authentication using the OAuth 2.0 protocol. This handles:

1. User login. Patients or providers authenticate with their health IT system credentials.
2. Consent. Users authorize SMART apps to access protected health information.
3. Access tokens. Time-bound, revocable tokens enable access to FHIR resources.

The SMART authorization sequence involves:

1. The app initiates the OAuth 2.0 authorization request.
2. The authorization server authenticates the user.
3. The user grants access privileges to the app.
4. The authorization server provides an access token to the app.
5. The app uses an access token to retrieve FHIR resources.

SMART libraries and SDKs provide out-of-the-box support to implement OAuth 2.0 application authentication flows.

FHIR Queries and Resource Access

Once authenticated, SMART apps leverage FHIR’s RESTful API and extensive resource model to access health data.

FHIR resources.  Over 150 FHIR resource types are encompassing clinical, administrative, and infrastructure data models that apps can leverage.

Search and queries. To filter and retrieve resources, developers can query FHIR servers using parameterized search operations.

Read and write. In addition to querying data, SMART apps may have permission to write or update select FHIR resources by leveraging FHIR operations.

Version awareness. Apps should be designed to work across different FHIR specification versions and resource definitions.

Programmatically working with FHIR resources is central to delivering value in SMART apps. Developers should learn FHIR resource structures, query parameters, and server capabilities.

Implementing SMART App Launch Frameworks

A key benefit of SMART on FHIR apps is seamless embedding within EHR workflows. This depends on utilizing app launch frameworks.

There are two primary launch modes:

Standalone launch. Apps launch independently in a web browser or on a mobile device. This does not require EHR integration but depends on patient authorization.

EHR launch context. Apps launch directly within the EHR interface via an iframe, enabling tight workflows. The EHR provides patient context.

In addition, there are several launch types, including:

1. Patient-centered apps. Launch from the patient portal.
2. Provider-centered apps. Launch from the clinician dashboard.
3. Encounter context. Launch within a patient’s encounter.

The app registers launch details with authorization servers. At runtime, parameters enable context-aware launch.

Properly configuring app launch frameworks unlocks seamless embedding within EHRs and other health IT systems. Developers should understand technical launch requirements and workflows.

Testing and Certifying SMART on FHIR Apps

Thoroughly testing SMART apps is crucial before release. Testing verifies:

1. Standards conformance. Ensures apps comply with SMART on FHIR, OAuth 2.0, and FHIR specifications.
2. Functional operation. Validates app functionality, user flows, and FHIR API usage across test cases.
3. Interoperability. Proves seamless EHR integration and data exchange across systems.
4. Performance. Measures operation under load, at scale, and during stress scenarios.
5. Security. Identifies vulnerabilities through penetration testing.

Formal SMART app certification is also available. Certification by ARGO Labs or IHE USA validates standards conformance, transport testing, true interoperability, and production readiness.

Investing in robust testing and certification enables high-quality SMART apps.

Maturing a SMART App with Additional Standards

While SMART on FHIR provides the foundation for interoperable apps, developers can further mature apps through added standards support:

1. CDS Hooks. Implements the Clinical Decision Support Hooks standard for EHR integration and workflow events.
2. FHIR Bulk Data Access. Enables high-performance access to FHIR data at scale vs. API calls.
3. FHIRcast.  Allows push notifications to apps when FHIR resources change vs. polling.
4. FHIR Subscriptions. Set up standing queries with server push rather than repeated requests.
5. HL7 FHIR Implementation Guide.  Comply with implementation guides for focused data areas.

Building out added standards aligns apps with advanced EHR integration, performance, and functionality requirements for enterprise use.

Deploying and Distributing SMART on FHIR Apps

Once development is completed, SMART apps must be deployed and distributed. App distribution options include:

1. Enterprise clients. License directly to healthcare organizations for internal use after custom integration.
2. App marketplaces. Distribute through public SMART app repositories like SMART Health IT App Gallery.
3. App stores. For mobile apps, enable downloading from commercial app stores like the iOS App Store and Google Play Store.
4. Embedded offerings. Embed and distributed as part of a larger platform or solution.
5. Open source. Publish as open-source code for community adoption on GitHub.

When planning SMART app distribution, developers should consider target users, distribution partnerships, customization needs, and other dynamics.

Conclusion

SMART on FHIR provides a powerful framework for developers seeking to build apps that interoperate with electronic health records and data systems. Following SMART principles and best practices leads to scalable, innovative healthcare solutions. Robust testing and certification raise confidence for enterprise adoption. As healthcare data exchange continues accelerating, SMART promises to unlock data liquidity supporting personalized medicine.