University 2019-08-21: OpenMRS-FHIR Webinar by @pmanko

pmanko · August 21, 2019, 5:04am

Thanks for the announcement @ssemakadde!

Here’s the tutorial I’ll follow on the University call, which you can also follow on the Webinars Github Page.

Check out https://pasteapp.com/p/OzVTNeWZln3/s/hljtep4x for the companion slide deck

An Introduction to the FHIR API

Outline

An Introduction to the FHIR API

Learning Objectives

Recognize the basic features and uses of modern web APIs & how FHIR fits in as a RESTful API.
Understand the general concepts behind FHIR standard for health care data exchange, including the history, purpose, scope, the adoption and implementation situation.
Be aware of major projects, collaborations, implementations, and technologies that use or focus on FHIR, and recognize the gaps between a Standard and its implementations.
Complete a FHIR tutorial that queries data from a FHIR endpoint to implement a simple cardiovascular risk calculator.
Explore FHIR independently through provided access to projects, readings, tutorials, and other useful resources
Participate in an ideation session on opportunities for FHIR in the OpenMRS community

So, what is FHIR?

FHIR stands for Fast Healthcare Interoperability Resources.

According to the the official documentation, FHIR is a

“…next generation standards framework created by HL7. FHIR combines the best features of HL7’s v2 , HL7 v3 and CDA product lines while leveraging the latest web standards and applying a tight focus on implementability.”

source: Summary - FHIR v5.0.0

If FHIR is “next generation”, what came before?

The summary above does not paint a very comprehensive picture of the major health data standards maintained by the HL7 Organization before FHIR.

If you’re interested in a more thorough history lesson about the HL7 V2, V3, and CDA standards, check out this slide deck and an associated walk-through and send us any questions you might have!

Main Takeaway for Now: Previous HL7 standards are still in use today to varying degrees, but FHIR is experiencing very fast growth, maturation, and adoption.

Here’s a slightly-outdated map showing the growth of FHIR- at least in the United States: FHIR-USA-Map

And here’s some more on the topic: Heat Wave: The U.S. is Poised to Catch FHIR in 2019 - Health IT Buzz Health IT Buzz

What are the web standards that FHIR leverages?

To understand FHIR better, we’ll dive into what the latest web standards are, how they facilitate implementability, and what this implementability could mean.

The key point to remember is: FHIR is a RESTful API, which puts it in a class of web standards that is very widely used in the tech field to transfer all kinds of data between different applications and systems.

Some examples you might be familiar with: the Twitter Search API, the Github API, IBM’s Watson Assistant and countless other services provide access to their data through a RESTful API.

Note: Slack also has a REST API that you can easily play with - I started doing an analysis of the OpenMRS fhir channel here if you’re interested: https://github.com/pmanko/slack_analysis/blob/master/fhir_channel.ipynb)

FHIR is a RESTful API… which means what exactly?

Let’s first focus on APIs - or Application Programming Interfaces - in general.

Here’s a diagram from https://learn.g2.com/api that illustrates the concept behind APIs “in simple terms”:

Say you have some app or service - in this case, a kitchen full of chefs that can create and output many exciting dishes. You also have a set of clients - very hungry restaurant patrons - who want to get at the provided services.

However, these clients might be completely ignorant of how this specific kitchen (service) operates, what food is provided, how this food is made and dispensed, and all the other intricacies of running a restaurant. Yet these clients still want access to this and other such restaurant services with minimal hassle.

That’s where the waiter (API) comes in. The waiter acts as an interface that the customers to interact with, and translates their needs to the kitchen in a way the kitchen can understand. Finally, the waiter/API devlivers the services to the clients, isolating the kitchen from individual interactions.

Ideally, the waiter/API provides the customers with an experiance they’ve come to expect from other such fine establishments. Even if this kitchen/service operates completely differently and - maybe a different cuisine, done on a different scale, at a different pricepoint - the experience as viewed by the clients using the waiter/API is not unfamiliar.

In summary, an ideal API provides a standardized, well-documented, and convenient endpoint for clients to interface with a given app or service.

If you want to learn a bit more about APIs and how they relate to FHIR, check out Pascal Brandt’s quick API & FHIR tutorial: BIME 533: HL7 FHIR

Ok, now what about the RESTful part?

RESTful APIs are a subclass of Web APIs that define a set of standard Operations on digital representations of objects called Resources.

The official FHIR page iillustrates how foundational these two concepts are for the FHIR standard.

Resources are mentioned in the second paragraph of the summary:

FHIR solutions are built from a set of modular components called Resources…[that can] easily be assembled into working systems that solve real world clinical and administrative problems…

source: Summary - FHIR v5.0.0

These resources are defined to represent the various different concepts important in healtcare scenarios, including patients, clinical encounters, medications, and so on.

You can browse them all on the following page:
https://www.hl7.org/fhir/resourcelist.html

Operations are highlighted here, and introduced as follows:

The RESTful API defines a set of common interactions (read, update, search, etc.) performed on a repository of typed resources. For further information concerning how operations are defined and invoked, see Extended Operations on the RESTful API.

This is a full list of the operations defined by this specification:

source: Operationslist - FHIR v5.0.0

Let’s step back a bit and talk about what exactly is part of the FHIR standard, and what falls out of scope - or is addressed by a related project or technology.

slide from https://pasteapp.com/p/OzVTNeWZln3/s/9mm9e825

slide from https://pasteapp.com/p/OzVTNeWZln3/s/EPMk15fruiV

slide from https://pasteapp.com/p/OzVTNeWZln3/s/8gw43cz9

In Summary

FHIR provides a framework for the representation of healthcare data and methods for sending and retrieving this data.

The standard has the potential to be the language that all kinds of different healthcare apps and services
- EHRs, personal health apps, fitness trackers, patient portals, clinical labs, and so on - all communicate with.

FHIR aims to cover ~ 80% of Healthcare situations, and provides a standard method for extension to cover the other ~ 20%.

FHIR and Related Projects

slide from https://pasteapp.com/p/OzVTNeWZln3/s/HQu2XIzmDF3

FHIR Tutorials

SMART on FHIR

tutorial: GitHub - uw-fhir/smart-on-fhir-tutorial: SMART on FHIR Tutorial for 2018 UW FHIR Workshop based on https://engineering.cerner.com/smart-on-fhir-tutorial/

CDS Hooks

UW FHIR tutorial: GitHub - uw-fhir/CDS-Hooks-Tutorial: A hands-on tutorial for introducing the CDS Hooks Specification and API Cerner tutorial: GitHub - cerner/cds-services-tutorial: A tutorial to help you get started running your own CDS Services.

Apple Health Records

Healthcare - Health Records - Apple

Google Cloud Healthcare API and FHIR

FHIR | Cloud Healthcare API | Google Cloud SoF + App Galleries

AWS and FHIR

Achieving healthcare interoperability | AWS Public Sector Blog CDS Hooks

Spec vs. Implementation

There’s a large difference between the FHIR specifications and the actual implementation of a standard.

FHIR is relatively mature as an API, and the documented features are relatively comprehensive.

However, the FHIR endpoints that have been implemented so far differ widely in the extent their implementation matches the spec.

This distinction between the (1) state of the FHIR standard itself and the (2) the adherance of different implementations to the standard is crucial for any organization exploring the use of this technology.

FHIR API Tutorial

Now, we’ll put all of this learning in action and build our own Cardiovascular Risk Calculator using FHIR resources!

github.com

uw-fhir/fhir-api-tutorial/blob/master/fhir-calculator-notebook.ipynb

{
 "cells": [
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "*Thanks to Viet Nguyen MD for this book*\n",
    "\n",
    "\n",
    "**Use Case**\n",
    "As a physician, I want to calculate a patient's cardiovascular risk using the Framingham calculator based on LDL \n",
    "    (http://reference.medscape.com/calculator/framingham-coronary-risk-ldl)\n",
    "\n",
    "\n",
    "**Define Functional requirements**  \n",
    "Step 1 - Define required clinical data elements  \n",
    "- Patient Age  \n",
    "- Patient Gender  \n",
    "- LDL Cholesterol in mg/dL  \n",
    "- HDL Cholesterol in mg/dL  \n",

This file has been truncated. show original

Explore on your own!

Work through this tutorial on your own, and post comments with any thoughts or questions.
Check out the links in the FHIR and Related Projects section.
Look through some more resources we’ve complied over the last couple years: FHIR, SMART & CDS Hooks Resources – FHIR up UW