Overview

Background

SMART stands for “Substitutable Medical Applications and Reusable Technologies”, a healthcare standard enabling applications to access clinical information from a data store. It was originally proposed by the SMART Health IT project (run by the Computational Health Informatics Program at Boston Children’s Hospital) and later formalized as SMART App Launch Framework, layered on top of the FHIR APIs to facilitate standardized data access.

The specification builds on OAuth 2.0 and OpenID Connect (OIDC), widely adopted industry standards for authentication and authorization. It allows third-party applications to authenticate and interoperate securely with any compliant system. It also defines launch sequences, token scopes, context passing mechanisms, and FHIR-based data access norms.

Glossary

Term Definition

SMART on openEHR

This specification document detailing the SMART framework for an openEHR enabled platform

SMART App Launch

The original SMART framework specified by HL7 FHIR, often referred as "SMART on FHIR"

Vendor

An entity that develops and supplies software to end-users.

User

The individual operating the Application to perform specific functions; also referred to as the "end-user".

Application

A software application developed by a Vendor to operate with a Platform and/or Launcher, potentially built by the same or a different Vendor. In OAuth terminology this is the "client", whereas in FHIR is often called the "SMART App".

Platform

A software ecosystem comprising at minimum an Authorization Server, an openEHR Clinical Data Repository (CDR), and a FHIR Server. It exposes openEHR REST APIs, FHIR APIs, and possibly other APIs. In FHIR this is often referred to as the "EHR system". The Platform includes the authentication and authorization infrastructure that supports OAuth 2.0 Framework and this specification.

Launcher

A user-facing application, typically developed by the Platform vendor, which initiates the launch of Applications within the context of a specific Patient or Practitioner. The Launcher may be integrated into the Platform’s main application (e.g. as a Portal) or exist as an independent application.

EHR

A (session) context representing the openEHR EHR container for the corresponding Patient, indicating the subject of interactions through the Application.

The SMART App Launch Framework specification uses the terms 'EHR' and 'EHR system' to describe a system comprising a FHIR Server, Authorization Server, and potentially other components, including a Launcher.

In contrast, openEHR defines an EHR Information Model, centered around the root EHR container.

To avoid ambiguity, this specification reserves the term 'EHR' exclusively for references to openEHR constructs (e.g., EHR type, EHR ID). Alternate terminology will be used to describe equivalent FHIR-based system components.

Why SMART on openEHR?

A widely accepted vision today is that no single software vendor can provide all the necessary tools and solutions required by a modern healthcare system, while simultaneously ensuring high quality and maintaining a low total cost of ownership. Independent vendors, specializing in solving specific problems, often offer advantages over monolithic software suites attempting to address all needs.

In practice, this vision necessitates a collaborative ecosystem where applications from multiple vendors operate together to deliver a comprehensive solution. This approach is often referred to as a "best-of-breed" architecture. However, current implementations typically involve a lengthy and complex manual "integration" phase, during which vendors must coordinate their systems to interoperate, an expensive and time-consuming process that poses a significant barrier to entry for new vendors.

The SMART specification addresses this challenge by standardizing the security and interactions between systems and applications. It establishes a clear contract between the Application Vendor and the Platform Vendor, covering the following requirements:

  • The Application must be able to run on a domain owned by the Application Vendor.

  • The Platform must be able to operate on a domain owned by the Platform Vendor.

  • The Application must be able to discover the API services provided by the Platform.

  • The Application must be able to authenticate with the Platform to access its APIs.

  • The Platform must be able to authorize the Application for specific actions and data access, based on user roles and granted scopes.

  • The Application must be able to determine the active operational "context" managed by the Platform, such as the current EHR.

  • The Application must be able to embed within the Platform's user interface while maintaining the current context to ensure a seamless user experience.

The SMART on openEHR specification is designed to maintain compatibility with SMART App Launch Framework, while extending it to work with openEHR REST APIs and potentially other API types. It defines a framework supporting the following capabilities:

Foundational Concepts

The openEHR Reference Model and the openEHR REST API specification provide the foundational structure for interoperable Applications. For these applications to be truly portable across systems and vendors, a standardized approach to authentication and authorization is essential.

Authentication is the process of verifying the identity of an end-user or client application, while Authorization is the process of determining what access or privileges that entity has.

The SMART on openEHR specification builds on the OAuth 2.0 Framework and optionally OpenID Connect (OIDC), to allow third-party applications to securely obtain authorized access to protected healthcare data exposed as APIs by the Platform.

Moreover, many such applications operate within the context of a specific Patient or a particular Episode. Therefore, selection of the appropriate context becomes a critical prerequisite for launching the Application.