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.

Advertisements

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

 Image

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.

 Image

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

Image

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.

MyOscar Integration with Cron like Syncronization Design

Since working on this project requires pulling data from a medical device and pushing that data to MyOscar. One barrier to overcome is the how many clients will be making concurrent request to MyOscar Personal Health Record System.
Could this pose a problem for the application developer that will maintain this system in the future?
As one of the research assistant in charge of designing this mobile integration software, I have to look far into the future. Some problems like size of data can cause a problem when storing heart beat data which comes in every second. I’ve implemented a solution to address that problem by persist the data in JSON format and storing it in sqlite. Here is an example:
{ 'Reading' : '[0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0]' ,
'theshold' : '[{'reading' : '0', 'over' : '20.0' },{'reading' : '1', 'over' : '20.0' },
{'reading' : '2', 'over' : '20.0' },{'reading' : '3', 'over' : '20.0' },
{'reading' : '4', 'over' : '20.0' },{'reading' : '5', 'over' : '20.0' },
{'reading' : '6', 'over' : '20.0' },{'reading' : '7', 'over' : '20.0' },
{'reading' : '8', 'over' : '20.0' },{'reading' : '9', 'over' : '20.0' }]'

Concurrent Request All Day on Client Phone

The next problem was concurrent request being sent from multiple phones multiple times a day will cause problems for the application and the user may incur expenses when heavy network usage is done all day. In light of that I’ve designed a system to synchronize MyOscar data at a 24 hour interval like a cron job in Linux. After doing some research on either implementing it from scratch or working on top of an already existing open source solution. I came across CWAC-Wakeful Service library. I’ve implemented an error message notification that will appear at the top when an error occurs on the clients phone when synchronization with MyOscar fails for the following reason:
  • No Network available
  • Web Service Error
  • Not Authenticated to MyOscar
  • Any Unknown error
Image
I am still in the process of implementing this solution but from what I gathered. When the phone is rebooted android will not remember unless I set a broadcast receiver to remember this service.Here is the XML required to make this happen.
<action android:name="android.intent.action.BOOT_COMPLETED" />

Here is a link if someone is trying to implement a similar solution:

In conclusion, data synchronized at a specific interval will be a solution for this project and the users using this software.
Till next time

Zak Hassan
/ Software Developer & Research Assistant – NexJExpress Team

/

Seneca Centre for Development of Open Technology, Research Department – Seneca College

Office: 416-4915050 ext. 3548


70 The Pond Road
Toronto, Ontario
M3J 3M6

http://cdot.senecacollege.ca/

“Time is the coin of life. Only you can determine how it will be spent.”

— Carl Sandburg

NFC on Android

It is possible to enable for NFC support in Android applications on Android devices which support Bluetooth. There is documentation on the NFC section under Connectivity at http://developer.android.com/guide/topics/connectivity/nfc/index.html. It gives details on how NFC works with Android and how it can be used with it. It also shows code samples in which NFC is used in an application.