Bell Eapen

Physician | HealthIT Developer | Digital Health Consultant

Drishti: An mHealth platform for pervasive health monitoring

TL;DR: Here is an open-source mHealth framework based on FHIR! and here is the paper and my presentation at ICSE!

Pervasive health monitoring is becoming less and less intrusive with better sensors, and more and more useful with machine learning and predictive analytics.

mHealth (mobile health) could play an important part in pervasive health monitoring. It is difficult for clinicians to efficiently use the data from disparate apps that do not communicate with each other. For example, if a clinician has to monitor a patient’s blood sugar, blood pressure and physical activity, the clinician may have to check data from multiple apps. Another challenge is the difficulty in communicating clinical requirements to app developers and it is difficult to test and approve the clinical validity of these apps. Besides, there are always privacy and security concerns with personal health information.

Open mHealth is a framework introduced to manage the problem of interoperability between apps. It is an open-source project. Open mHealth project provides interfaces for cloud services such as GoogleFit and Fitbit and converts the data into a common data format. BIT model deals with the communication problem between clinicians and developers during app development. Drishti incorporates Open mHealth framework into the BIT model using FHIR as the common data model.

The BIT model is based on the Sense-Plan-Act paradigm from robotics. The BIT model encourages conceptualizing mHealth apps as three distinct components: Profilers that sense data on various physiological parameters such as blood pressure, planners that create a clinical intervention plan and actors that deliver the plan to the users as alerts or messages on their mobile devices. Drishti adopts the BIT model as a design model with all components sharing a central data repository. Drishti makes sharing of information with the doctors easy, by integrating it into an EMR. The central data repository also makes big data applications possible.

The central data repository in Drishti uses FHIR schema for storage. FHIR is a schema for health data created by HL7 that defines ‘Resources’ that can be exchanged as json or xml using RESTful interfaces. Resources support 80% of common use cases and the rest can be supported using extensions. For example, age and gender are defined for a Patient resource, while skin type that is not commonly used is defined through an extension if required. Drishti uses the ‘Observation’ resource for storing data from profilers and the ‘CarePlan’ resource for the planner and actor components.

Open mHealth is the profiler in Drishti. All data from the various cloud services are converted to FHIR Observations and stored in the Drishti-Cog. The Drishti-Planner can take data stored in the cog and create a careplan and the actor can deliver it to the patient. Drishti uses OpenMRS EMR for managing access, both for clinicians and patients. We have developed an OpenMRS module for integration with Drishti. The javascript visualization library called hGraph provides a consolidated view of the data pulled from sensors to the clinician.

In the current implementation, the cog is a FHIR server based on the HAPI java library. Planner and actor components are just stubs that can be extended for several use cases. The planner is a python flask app and the viewer is a Vue App that can be used as a native mobile app. Both are templates that can be extended. The entire stack is available on GitHub along with pre-built Docker containers for quick prototyping.

Here is a typical use case. Depression is a common mental health problem, characterized by loss of interest in activities that you normally enjoy. Patients with depression are typically treated with anti-depressant drugs. The clinicians need to track the patient’s activity to assess progress along with medication compliance. The patient can use an activity tracker app and a medication tracker app, both sending data to the cog as FHIR observations. The clinicians can have a consolidated view in their EMR and create alerts or messages (plan) that can be delivered to the patient’s mobile device. The interventions can also be created by AI systems.

Drishti was presented at Software Engineering in Healthcare conference in Montreal and selected for FHIR devdays. Please cite Drishti as below:

Bell Raj Eapen, Norm Archer, Kamran Sartipi, and Yufei Yuan. 2019. Drishti: a sense-plan-act extension to open mHealth framework using FHIR. In Proceedings of the 1st International Workshop on Software Engineering for Healthcare (SEH ’19). IEEE Press, Piscataway, NJ, USA, 49-52. DOI: https://doi.org/10.1109/SEH.2019.00016

Serverless on FHIR: Management guidelines for the semi-technical clinician!

Serverless is the new kid on the block with services such as AWS Lambda, Google Cloud Functions or Microsoft Azure Functions. Essentially it lets users deploy a function (Function As A Service or FaaS) on the cloud with very little effort. Requirements such as security, privacy, scaling, and availability are taken care of by the framework itself. As healthcare slowly yet steadily progress towards machine learning and AI, serverless is sure to make a significant impact on Health IT. Here I will explain serverless (and some related technologies) for the semi-technical clinicians and put forward some architectural best practices for using serverless in healthcare with FHIR as the data interchange format.

artificial intelligence
Serverless on FHIR

Let us say, your analyst creates a neural network model based on a few million patient records that can predict the risk for MI from BP, blood sugar, and exercise. Let us call this model r = f(bp, bs, e). The model is so good that you want to use it on a regular basis on your patients and better still, you want to share it with your colleagues. So you contact your IT team to make this happen.

This is what your IT guys currently do: First, they create a web application that can take bp, bs and e as inputs using a standard interface such as REST and return r. Next, they rent a virtual machine (VM) from a cloud provider (such as DigitalOcean). Then they convert this application into a container (docker) and deploy it in the VM. You now can use this as an application from your browser (chrome) or your EMR (such as OpenMRS or OSCAR) can directly access this function. You can share it with your colleagues and they can access it in their browsers and you are happy. The VM can support up to 3 users at a time.

In a couple of months, your algorithm becomes so popular that at any one time hundreds of users try to access it and your poor VM crashes most of the time or your users have to wait forever. So you call your IT guys again for a solution. They make 100 copies of your container, but your hospital is reluctant to give you the additional funding required.

Your smart resident notices that your application is being used only in the morning hours and in the night all the 100 containers are virtually sleeping. This is not a good use of the funding dollars. You contact your IT guys again, and they set up Kubernetes for orchestrating the containers according to usage. So, what is Serverless? Serverless is a framework that makes all these so easy that you may not even need your IT guys to do this. (Well, maybe that is an exaggeration)

My personal favourite serverless toolset (if you care) is Kubernetes + Knative + riff. I don’t try to explain what the last two are or how to use them. They are so new that they keep changing every day. In essence, your IT team can complete all the above tasks with few commands typed on the command line on the cloud provider of your choice. The application (function rather) can even scale to zero! (You don’t pay anything when nobody uses it and add more containers as users increase, scaling down in the night as in your case).

Best Practices

What are the best practices when you design such useful cloud-based ‘functions’ for healthcare that can be shared by multiple users and organizations? Well, here are my two cents!

First, you need a standard for data exchange. As JSON is the data format for most APIs, FHIR wins hands down here.

Next, APIs need a mechanism to expose their capabilities and properties to the world. For example, r = f(bp, bs, e) needs to tell everyone what it accepts (bp, bs, e) and what it returns (at the bare minimum). FHIR has a resource specifically for this that has been (not so creatively) named as an Endpoint. So, a function endpoint should return a FHIR Endpoint resource with information about itself if there is no payload.

What should the payload be? Payload should be a FHIR Bundle that has all the FHIR Resources that the function needs (bp, bs and e as FHIR Observations in your case). The bundle should also include a FHIR Subscription resource that points to the receiving system (maybe your EMR) for the response ( r ).

So, what next?

Take the phone and call your IT team. Tell them to take
Kubernetes + Knative + riff for a spin! I might do the same and if I do, I will share it here. And last but not the least, click on the blue buttons below! 🙂

SMART CDS-Hooks

CDS-Hooks specification describes a “hook”-based pattern for invoking decision support from within a clinician’s EHR workflow.