Bell Eapen MD, PhD.

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 [ ¹ ]. 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 🙂