How can FHIR APIs help to prevent heart attacks?

October 18, 2017 Dr. David Hay

Heart disease and heart attacks are one of the leading causes of chronic disease and premature death globally.

The Framingham Risk Score is a scoring system used to determine an individual's chances of developing heart/cardiovascular disease. The Framingham Cardiovascular Risk Calculator gives an estimate of the likelihood (as a percentage) of an individual having a cardiovascular event (e.g., a heart attack) in the subsequent 10 to 30 years. The risk score can also highlight individuals who may benefit from prevention plans, such as being offered preventive drugs to lower blood pressure and lower cholesterol levels.

A demo app has been developed that uses HL7Ⓡ FHIRⓇ APIs both as the source data and also as a repository to store the data it creates. The application is an implementation of the Framingham Cardiovascular Risk Calculator.

It works by taking a number of measures (e.g., blood lipid levels, blood pressure, smoking status, and whether an individual is a diabetic) and assigning a number of "points" to each one (and there can be negative points for good results as well). The points are totaled and the overall risk is calculated and saved back to the platform, which means that it can be viewed directly from a portal.

The application is a web application, which means that it will run in a browser on any device—including smart phones and tablets.

We’ll discuss this project in a series of posts over the next three weeks.

  1. In this first post we’ll talk about the way the app works: how we meet the requirements of calculating the risk for an individual patient
  2. Next, we’ll consider what APIs we need from the platform, and how to call them
  3. Finally, we’ll dig into the security details: how we use OAuth to secure the application

The overall application flow is as follows.

First we log into the application. Actually, behind the scenes we are really logging into the Orion Health Amadeus Platform, so we need to have a portal login. Our user account also needs to have permissions to access the clinical data we need (we’ll talk about this in the third post in this series).

Once we’ve logged in, the app will retrieve the worklists that have been defined for the logged-in user. These worklists are lists of individuals/patients that can be maintained by the user. The lists are displayed in the app.

We select a worklist, and the app then displays all the patients in that worklist. We can select any patient and the app will retrieve the data from the platform (via the API) and calculate the cardiovascular disease (CVD) risk. Both risk and the data used to calculate the risk are displayed on the screen. (Please don’t rely on these figures from this app—this is a demonstration only!) Here’s a screen shot:

We can then save the assessment back to the platform using the green "Save Risk Assessment" button, after which it can be viewed in the portal—or retrieved from the API again. In fact, we display the previous assessments on the screen over on the right-hand side of the app.

Here’s a screen shot of the assessment being viewed from the portal:

And because this is a demo app, we’ve also provided the ability to generate random test data (using the red button).

And that’s really all the app is! There’s a lot more we could do. For example, we could allow the user to modify the data on screen and re-generate the risk to show someone how they could reduce their risk, or display a chart showing the risk changing over time, but this is only a demo, after all!

Here is the architecture of the app.

It’s a single-page application (SPA) using Angular on the client and communication with a Node.js application on the server. The node app makes the actual API calls to the platform (via the API Manager) and returns the results to the client. It also has the assessment algorithm. This approach was taken to avoid any cross origin resource sharing (CORS) issues that can occur when the call is made directly from the browser to the server.

In next week’s blog post, we’ll dig into the API in more detail.

***

To learn more about FHIR for Clinicians, download the white paper now.

Previous Article
The Future is Open: Why Open Data Platforms Are Essential
The Future is Open: Why Open Data Platforms Are Essential

As the volume of health data increases from almost every avenue, the need for open health IT ecosystems has...

Next Article
Self-Driving Cars Could Save a Life One Day
Self-Driving Cars Could Save a Life One Day

The first thing people tend to think of with autonomous vehicles, or AVs, is the personal convenience facto...

×

Subscribe to our Blog!

First Name
Last Name
Thank you!
Error - something went wrong!