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

HL10 – What is it?

 

HL10 - mHealth framework

HL10 (Hamilton) is a proposal for a framework for mHealth behaviour intervention technologies (BIT). If you have not done so already, please read this introductory overview. In this post, I will explain the concept further and discuss my ideas on implementation tools.

Let us take the example of the most popular behaviour intervention technology, the wireless enabled activity tracker – Fitbit. It has mobile apps for all platforms and a web dashboard for visualisation and interaction. The Fitbit syncs information wirelessly with your mobile or computer. Now consider another app: Blood Pressure Monitor (BPM) – Family Lite, that lets you track and visualise your blood pressure over a period. What if you want an App that alerts you when your BP is high and activity is low? Do Apps talk to each other? There are proprietary frameworks like Apple health-kit that make data exchange possible to certain extent and some vendors like Fitbit may expose their APIs to other systems to consume. HL10 is an attempt to take it beyond this into the realm of a true App-pharmacy, where you can mix and match various BIT modules.

Most BITs can conceptually be divided into a ‘sensor’, a ‘planner’ and an ‘actor’ that gives an alert. This Sense-Plan-Act paradigm is a concept borrowed from Robotics [ 1 ]. Let us imagine the mHealth Sense-Plan-Act as separate components. The sense component can be an activity tracker as in Fitbit or the blood pressure entry form in BPM. The Plan component prepares an intervention based on available data. For example: If the activity data and BP data is available to the plan component, it creates an alert when BP is high and activity is low. The Act component delivers it to the user. These three components can be logically and physically segregated provided there is a platform to glue them together and there is a common standard for data exchange.

The sense component sends data to the platform. The plan component takes data from the platforms and creates a plan. The act components registered with the platform delivers the plan.

All these components can be mixed and matched if they are separate. You can change any of these components. If you want to add another sensor, say a blood sugar monitor, you don’t have to rewrite everything again. The modular architecture allows code reuse. You can use modules created by others. In the next post, I will go into one possible software implementation based on the next-generation MBaaS: Appcelerator-Arrow. I am planning to prototype it on our GitHub group combining my sunburn and skin tone algorithms. I will try to get some guidance from Appcelerator. Maybe we can get this ready for eHealth-Vancouver-2016. Want to join me? Don’t hesitate to like/share below 🙂

Cite this article as: Eapen BR. (October 21, 2015). Bell Eapen - HL10 – What is it?. Retrieved December 9, 2019, from https://nuchange.ca/2015/10/hl10-what-is-it.html.

References:

  1. Mohr DC, Schueller SM, Montague E, Burns MN, Rashidi P. The Behavioral Intervention Technology Model: An Integrated Conceptual and Technological Framework for eHealth and mHealth Interventions. J Med Internet Res 2014;16(6):e146