Thinking about the Next Steps for the Seneca Health Research (CDOT / NexJ MMDI) Project

After the MMDI project’s showing remarkable progress in building the wireless communication adapter and in processing and analyzing personal health data, it is the time to consider and plan the possible next steps for the project.

On one hand, extending or enriching the functionalities of the MMDI wireless communication adapter is an important task in the near future. The MMDI project was intended to build a universal adapter to connect multiple medical devices to cross-platform mobile devices with different wireless technologies. Medical devices can be classified into different categories and each category can have different products provided different venders. Similarly, mobile devices can be divided into various platforms, such as Android, iOS, Blackberry and etc. as well as mobile frameworks like Cordova/Phonegap. Meanwhile, the wireless technologies used in the device communication are also various, including Bluetooth, NFC and Wi-Fi. Therefore, different combinations of these factors make the MMDI project have a large number of aspects or areas that need to be researched or probed. Currently, the MMDI project has completed the implementations of using Android platform and Cordova on Android platform to connect to a certain number of medical devices based on Bluetooth technology. This means we have merely finished the first one or two step(s). The possible new research areas of the MMDI project could among the following list:

  •   Extending the MMDI project to support other mobile platforms or Cordova which are based on these platforms, such as iOS, Windows Mobile, webOS, Blackberry and etc.
  •   Adding NFC or Wi-Fi connectivity to the MMDI for supporting alternative wireless communication technologies.
  •   Implementing more Bluetooth enabled medical devices into the MMDI project to extend the current Bluetooth communication library for Android and Cordova/Phonegap on Android platform.

On the other hand, building up PHR data-process-adapter and common PHR data model would be the significant task or goal which will make the CDOT (NexJ) Health Research team be leading in the research of people-centered PHR system in healthcare industry. Actually, the Seneca Health Research team’s research and implementation of the applications based on the APIs of FitBit, Withings and MyOSCAR have made the team on the way toward this goal.

What is PHR data-process-adapter?
The PHR data-process-adapter is a new concept here, referring to universal the mobile/Web adapter which can retrieve data and update/upload data (if possible) from/to different personal health record (PHR) servers. For end user applications on Android platform, the PHR data-process-adapter could be an Android (Java) library project. For web (mobile Cordova/Phonegap or desktop) front-end applications, the PHR data-process-adapter should be a JavaScript library.

What is Common PHR Data Model?
Nowadays, there is no standard data model for building personal health record applications. The personal health data retrieved from different PHR servers may have different naming formats and data structures. The Common PHR (person health record) Data Model is the standard data model for retrieving, updating, analyzing personal health records (PHRs) used in mobile native or front-end web applications. Within these applications, all PHR data from different PHR servers will be converted into the common PHR data model by the PHR data-process-adapter. Thus, the end user (mobile native or front-end web) applications can process personal health records from different PHR servers seamlessly, supporting people-centered PHR analysis process.

Why we need the PHR data-process-adapter and the Common PHR Data Model?
The PHR data-process-adapter and the Common PHR Data Model will be used to deal with the mess or problems in today’s PHR software market and to realize the break-through of building people-centered personal health record analysis applications.
Today, there are a number of different PHR software/systems in the market. The interoperability among different PHRs is the issue to which no PHRs architecture wants to face. As results, people/patients may be forced to used certain PHR systems but none of these systems can provide comprehensive PHR data from different systems; doctors and health coaches are facing the same problems when accessing patient’s PHR.
Please view the following situations.

  •   People who use FitBit and Withings serial medical devices have to use vendor-provided mobile apps and servers for the collection and storage of personal health data.
  • A patient who is suffering chronic illness may be asked to use MyOSCAR for his/her personal health records by his/her family doctor.
  • A patient is probably asked to use TELUS PHR if the patient visits a specialist for his/her chronic illness.
  • The health coaches for chronic illness may ask their patients to use the NexJ PHR systems created by the connected health and wellness project.

The above situations can mostly happen in particular for the patients who suffer multiple chronic diseases.

Building up PHR data-process-adapter and common PHR data model is to create a framework for building front end (mobile and Web) PHR applications which support people-centered PHR analysis or comprehensive PHR data analysis from multiple data sources.


New Bluetooth Enabled Medical Devices

I’ve just done a search for medical devices and found several newly released Bluetooth enabled devices which could be possible implemented into or related to the MMDI project. Here is the simple description about these devices.


1. LifeScan OnoTouch Verio® Sync® Blood Glucose Meter


This new device is release as OneTouch® Verio®Sync System including the blood glucose meter and a iOS application called Onetouch® Reveal™ mobile app. This app can make blood glucose readings transfer to iPod, iPhone and iPad by using Bluetooth technology and provide data analysis for the data of 14 days.

No Android app for this device is provided by the vendor.

No Bluetooth communication API /protocol is found. However, It would be amazing if we can get its api and implement it in our MMDI project.


2. Ploytel Blood Glucose Meter Adapters.

Ploytel recently release a serial of new model for its blood glucose meter adapters, including GMA1-L, GMA2-A and GMA2-B. All this devices have the same appearance.


The model GMA2-L or PWR-09-02 is used to connected to LifeScan OneTouch Ultra serial (and more) of blood glucose meters. The PWR-09-02 model is compatible with the old mode PWR-08-06, which we have implemented into our MMDI project. This means that MMDI applications can receive Bluetooth data from the new PWR-09-02 Polytel devices for LifeScan OneTouch Ultra, Ultra 2 and UltraMini blood glucose metters without the need to change any code.


3. Withings Wireless Blood Pressure Monitor


This is new products of Withings blood pressure monitor which can transfer readings to mobile devices by using Bluetooth technology. But this device is not current available because it is waiting for US FDA clearance.  

This device is Bluetooth Smart Ready device with both regular Bluetooth and Bluetooth low Energy connectivity.  The vendor provides free Health Mate app for both iOS and Android devices. But development kit for Bluetooth API cannot be found.

MMDI – The Integration of Polytel GMA Device

In the past week, a progress has been made – the Polytel GMA device was integrated into the MMDI project. With the integrated Polytel GMA device, the blood glucose readings from LifeScan oneTouch Ultra, Ultra 2 or UltraMini glucose meters can be transferred to Android (PhoneGap) devices using Bluetooth wirelessly.


This is another integration of Bluetooth adapter for LifeScan blood glucose meter products. The first integrated Bluetooth adapter for our MMDI project is the bluglu device, which can work with OneTouch UltraMini blood glucose meters.

Weekly Update for SHRH

This week I started on the integration of Ploytel GMA device. I migrated the code into our MMDI project. But at end, a property of CordovaPlgin class, called cordova, always get the null value, causing the demo app crashed.

Meanwhile, we also have obtained progress in the test for bluglu device. The measurement taken from OneTouch UltraMini has successfully received by our demo app through the bluglu’s Bluetooth transmission with using the “SYNC” button. We are now trying to know if we can get reading without the help of the button.

Weekly Update for SHRP

My work of this week is focused on refining the code of bluglu device integration. The purposes of the work are to prepare for pushing the bluglu integration into our project repo and make the bluglu demo ready for the FSOSS demostration. Some detailed work include: added device serial number verification feature for bluglu; updated UI for better demostration; performing tests for both bluglu and A&D devices and fixed bugs; Update project specification ( file.

Here is the notes about some features of bluglu and A&D devices:

  1. When A&D devices sending data using Bluetooth, they have a discovery process using service name. So, verifying the service name makes sure to find right service, but the discovery process costs time.
  2.  While bluglu device has no such discovery process when sending data using Bluetooth. After Android device pairing with bluglu device, the bulglu device will remember the MAC address of the Android. When sending data to Android, the bluglu device will directly connect to the Android device using Android’s MAC address without discovery process.
  3. Therefore the bluglu device uses less time in transferring data to Android than A&D devices. However, bluglu device will interfere with other Bluetooth server if the Android is listening to other devices. And in this situation, the bluglu device will enter and error state, which we need to press the reset button to recover it.
  4. Meanwhile, another device, Polytel, uses the same Bluetooth service name as the A&D devices. Therefore, the Android device’s opening multiple Bluetooth servers at the same to listen different medical devices will cause interference problem for each device type currently we have. So, I set the disconnect / stop_device command to stop the Bluetooth server for all devices rather than a specific server.

Weekly Update

The bluglu device was integrated into the MMDI project

This week my job is focus on figuring out how to integrate the bluglu device into the MMDI project and implementing the integration. Eventually, the bluglu device was integrated into our project successfully. From the Demo application, we can start and stop the device and get the emulated readings.


The newly created classes implementation include: DeviceManager, BlugluDeviceManager, BluetoothAndroid, DeviceStartCommand and DeviceStopCommand. The DeviceManager is a super abstract class for all device manager and adapters. It provides the supported brands and devices of medical devices by the project for the TypeCommand and also defines 3 abstract methods: _start(), _pause() and _stop(), which are used for the basic device operaction. And the BluetoothAndroid is used for basic Bluetooth operation for the Android device.

There is an issue of that When the application is start to connect/listen to the AND device, the application can catch the Bluetooth signals sent by bluglu devices. AND and bluglu use different service name, so the interference should not happen. Meanwhile, the bluglu integration is test on the emulator of blood glucose device. It need to test on the real device.

Weekly Update for SHRP

After implemented the simple PhoneGap app using the bluglu library, this week my work include the following aspects:

  • Wrapped the pieces of data from the Bluglu service into to JSON format. For each reading of blood glucose, the Bluglu service divide into pieces, such device type, value, time serial number, and transfer them separately. It’s necessary to package them together to fit the PhoneGap anf multiple device environment.
  • Looked into the Polytel sample code for common part with the bluglu, seeking for the way  to integrate different device into the project.
  • worked on the code of MMDI project, separating the functionality of Bluetooth operations from the BluetoothDeviceAdapter and immigrate them into the new class of BluetoothAndroid. This is the my fork of the project reop.