SMART on FHIR

In a hospital, all data about a patient resides in one large central program, the electronic health record. These programs come from a handful of major vendors and are far from able to do everything. A doctor might want to use an additional program that calculates a risk from blood values. For this additional program to get access to the necessary data at all, fixed rules of the game are needed. SMART on FHIR is exactly such a rulebook: a publicly defined set of technical agreements for how an outside program may tap into a patient record. The name is made up of two parts, which are explained in the rest of this entry.

Why clinical software would otherwise be a dead end

Without such rules, every additional program would have to be adapted individually for every hospital system. A small company with a good idea would then have no chance. It would have to negotiate separately with each vendor and reprogram everything each time. That was exactly the state of affairs in healthcare for years.

With a shared standard, the situation is reversed. An app is built once and then runs everywhere the standard is supported. This is reminiscent of apps on a smartphone: the developer knows the rules of the system and doesn’t need to know which device model the user owns.

This is especially important for AI applications. A model that supports diagnoses is worthless without access to real patient data. Many companies therefore deliver their AI as a SMART-on-FHIR app. In the US, legislators have even mandated such open access for several years now.

What FHIR contributes and what SMART contributes

FHIR is the data format. It defines how a lab value, a diagnosis, or a medication is technically written down. Each piece of this information is a so-called resource, meaning a clearly delineated data package with fixed fields. This way, an app knows that the field for blood pressure is always named the same, regardless of which hospital supplies the data.

SMART adds the security and the launch process. The app is opened directly from within the patient record, usually via a menu item. In doing so, it receives a digital ticket, an access token. This ticket proves to the system that the app is authorized, and it is valid only for a short time.

The scope of the permission matters here. An app does not get the whole database, but only certain areas for a specific patient. This works similarly to the prompt on a phone asking whether an app may access the camera or contacts. A common misconception is that SMART on FHIR itself encrypts or stores the data. It only organizes the access.

Where the standard shows up in everyday life

It is most visible in US hospitals, where systems like Epic or Cerner run their own app directories. Doctors there click on an additional program that integrates seamlessly into the record. Typical examples are calculators for heart attack risk or tools for medication dosing.

Patients benefit too, often without noticing. Health apps on smartphones pull findings directly from the clinic once the user consents. In Germany, FHIR also plays a growing role, for instance around the electronic patient record and the e-prescription.

In business news, the term usually comes up in connection with approvals and partnerships. When an AI start-up announces that its software is now integrated into a major hospital system, this standard is almost always behind it. For investors, this is a signal that a product is actually reaching the doctor and not just working in the lab.