Death to HAPP, long live HAPP+

Proposed UI Design for HAPP+

Just over a year ago I discovered the OpenAPS and xDrip community projects and was excited at the possibilities to finally manage the data I can now collect about myself as a Type 1 Diabetic. I am fascinated by the use of technology and “easy access” for the wider nontechnical population, while I loved the goal of OpenAPS, I struggled with the logic of carrying a tiny computer, battery, cables and lack of visual feedback. These challenges could be resolved by porting the project to a mobile platform, with this utopia in mind I looked at learning Android application development.

This eventually resulted in HAPP my Mobile based Artificial Pancreas App. While the goal of wireless connectivity with my Pump is still unresolved (for now), the app is functioning as an Open Loop System that can in theory support any Pump has completely changed my management of my condition, a pleasantly surprising outcome for me. Also, I have had a lot of fun along the way discussing the #WeAreNotWaiting Community and motivation behind mine and other's work.

Early Development of HAPP

But, this was no easy journey and now the damaging results of that journey have started to take effect. Let's look at some of the challenges…

  1. I am not a developer, other than playing with code in college and simple scripting my experience is almost nonexistent. Development of HAPP was a significant learning process for myself and while I am still reluctant to call myself a developer, I am significantly more capable now. The code quality in HAPP, as a result of this, suffers.
  2. HAPP was extended from the original xDrip Android app to assist with my learning process and give me a starting point. While this was a great start for the project, xDrip code and design have directed my development path and this has not always been ideal. As a result, multiple areas of code have been ripped out and replaced, the result of this is that the code had not been developed from the start to take advantage of particular features. Realm is a great example of this.
  3. Development of HAPP was a blind path as I discovered what I could get from such an app and my data. As feedback came in from the community of HAPP users, functionality and features have been difficult at times to add to HAPP, where designing for these uses cases in mind from the start would have been more ideal
  4. Lack of a modular design, this has resulted in complicated code that is difficult to debug and develop on, for myself and anyone else.

While the above may sound harsh, as right now I do have an app on my phone that is significantly assisting me with the management of my condition, I have to be a strong critic of my work - I, have killed HAPP.

With such a realization, an exciting if challenging opportunity presents itself, let's start again.

Birth of HAPP+

Dec 2016 I started work on the design of a new App, an app that takes on all that I have learned in the last 12 months. My goals were…

  • Open Loop first, as this has a wider audience that can benefit
  • User feedback, a system that provides a point in time information about the APS system and clear diagnostic information in regards to the state of the multiple components that consist in the app.
  • Modular design based on Plugins, that can be easily extended and function independently to each other while giving the user full control.
  • Multiple Profile support that allows the user to easily switch between app configuration for HAPP+ and all its plugins.
  • Take advantage of support libraries from the start, rather than try and shoehorn this in later as done with HAPP
  • Allows the user to decide what APS, Insulin on Board, Carb, Bolus Wizard Algorithms to use and easily add their own.
  • Supports different type of user Events to be logged and easily allow new Event types to be created over time
  • Allow comparing APS Results across APS Algorithms
  • Can support data synchronization with multiple external systems
  • Provide all the boilerplate code to allow you to develop and add your own plugins

This has resulted in some key Architectural Designs in HAPP+

Plugins

All plugins extend from a singular PluginBase class, the final usable plugin is commonly based on an additional extension of the PluginBase that provides common Boilerplate code. An example…

xDripSourcePlugin extends CGMSourcePlugin extends PluginBase

Where:

  • PluginBase - core Plugin Class that provides common plugin functions for example name, function, saving and loading of prefs, loading, and unloading of the plugin and the current status of the plugin
  • CGMSourcePlugin  - the Plugin Type Class provides interfaces and common boilerplate code expected from a CGM Source such as new readings, getting lists of readings, saving readings, etc
  • xDripSourcePlugin  - the final Plugin that is responsible for providing CGM data from the external xDrip app

Another core Plugin Type in HAPP+ are Devices. Devices control other plugins and are the common point of contact for other plugins and the user in controlling and configuring HAPP+. Current Devices include…

  • DeviceCGM - management of CGMSource Plugins and formatting and retrieval of data, along with management of users prefs.
  • DeviceProfileManager - HAPP+ internal Profile Management System that allows the user to have multiple Profiles that consist of Profile Prefs. Profile Prefs have clear explanations with the ability to compare current Profile Prefs Values across Profiles and defaulting of values with the user's Default Profile. This Device transparently handles all of this logic for Plugins and the user.
  • DeviceSysFunctions - core functions that HAPP+ requires to operate, these functions also are Plugins that allows the users to decide what Plugin to use for each internal function. Example internal functions…
    • Bolus Wizzard
    • IOB Calculations
    • COB Calculations
  • DeviceAPS - handling of APS Algorithm Plugins with the ability to compare APS output across plugins
  • DeviceEventIntegration - handling of Plugins that work with Events, for example, sync to external systems
  • DeviceDataAnayltics - visualizations and/or analytical feedback of HAPP+ data for the user to review

An example Device…

DeviceCGM extends DeviceBase extends PluginBase

Events

HAPP+ data logging works around the AbstractEvent Object. This is a base class that is extended to allows handling of Events, be it user created, internally created or synced. Such events support notification, approval and contain additional data about itself. If a new Event type needs to be tracked by HAPP+, a simple extension of the AbstractEvent class can support this.

Validations

The InterfaceEventValidator interface allows the use of multiple plugins to perform Validations for HAPP+ Events. Whenever new Events are added to the system they are passed to all plugins with this interface where the plugin can pick the Event types it wishes to review and returns the adjusted list with details of any adjustments. HAPP+ will have its own final core Validator that events must pass and a user can enable/build additional validator Plugins as needed. This allows multiple plugins to Validate Events, for example, a Pump plugin to validate Bolus Events and more bespoke use cases, for example, a plugin that Validates Food based Events to manage diet. Architecture outline for HAPP+

Architecture outline for HAPP+

User Interface

UI design is also another area that I believe can be significantly improved. The aim is to provide a point in time and just enough historical data for the user to stay well informed in the app. Also, each Device will provide feedback on itself and plugins to help configuration and diagnose the issue.

Mockup of HAPP+ interface in NinjaMock

Mockup of HAPP+ interface in NinjaMock

HAPP+ is a completely new code base from HAPP, I have decided to add an HAPP+ branch to GitHub and avoid creating a completely new project, I am sure there are many reasons this should not be done but I felt it made sense - feel free to tell me off!

Your feedback has helped me shape what HAPP is and HAPP+ will become and I encourage you to continue to post your requests in GitHub and please feel free to give your options on my ideas/design for HAPP+ via gitter.

Things have come a long way since I first decided to try and build a mobile Artificial Pancreas System. We now have multiple Open Source Mobile APS systems being actively used (Loop, AndroidAPS) along with support apps xDrip, xDrip+, NSClient and active users providing feedback and use cases on how they wish for these tools to operate. I hope that HAPP will continue to be part of this growing ecosystem and thank you all for support and feedback on the continuing development.



 

 

Like this? Email me future posts!

Disclaimer

The contents of this site is for informational purposes only and is not intended to be a substitute for professional medical advice, diagnosis, or treatment. Always seek the advice of your Diabetes support team or other qualified health provider with any questions you may have regarding your medical condition.Sorry, have to say something like this!
Tagged under tech artificial pancreas HAPP hacking diabetes