Phonegap Healthcare Adapter Backlog

NexJ Medical Peripheral Mobile Adapter Will be designed to enable NexJ's Mobile Healthcare solutions to interact with Bluetooth peripherals.

Main article: Mobile Medical Device Integration

Investigation

IOS

• Bluetooth can work on simulators.
• Deploy to devices, requiring enrollment in the developer program.
• Understand Objective C.
• Understand iOS best practice development.
• Understand iOS PhoneGap plugin best practices.

Android

• Bluetooth does not work on the emulator.
• Understand ADK best practice development.
• Understand ADK PhoneGap plugin best practices.

PhoneGap API

• Design a unified API in JavaScript that will allow the NexJ application to interact with Bluetooth devices.
• Define a project architecture that facilitates multiple device compatibility.

Blood Pressure Device

IOS

• Create native Bluetooth adapter for this device.

Android

• Create native Bluetooth adapter for this device.

Glucose Level Device

IOS

• Extend native Bluetooth adapter for this device.

Android

• Extend native Bluetooth adapter for this device.

Weight Scale Device

IOS

• Extend native Bluetooth adapter for this device.

Android

• Extend native Bluetooth adapter for this device.

Proof of Concept

Android

• We've created the Android native code (using Android Bluetooth API) to test the Bluetooth process between Android and medical devices.
  • Settings for connection: For creating the UUID of the Android device, "00001101-0000-1000-8000-00805f9b34fb" is used instead of conforming to the COD filter value on the A&D specs; but the service name and PIN on the specs have to be used.
  • Issues in the test:
    • For the blood pressure meter, pairing can be set but data transmission is unstable. The reason could be: The A&D medical device always forces one to use RFCOMM port/channel 1 for the connection; but the Android device will choose the next available channel.

Summary of Bluetooth communication test between Android and A&D BTP devices

• After the efforts of weeks, we have successfully built Bluetooth communication test programs of both Android native and PhoneGap (plugin on Android) framework applications.
  • The two versions of the test code, through Android Bluetooth APIs, make the Android devices work as Bluetooth server and perform SPP communication of Bluetooth.
  • Mobile devices: Android. The minimum version of Android is targeted at Android 2.2 and the test devices are HTC Desire (Android 2.3.3) and MOTOROLA XT885 (Android 4.04).
  • Medical devices: A&D BTP series which are SPP and SDP conformable. We use A&D UC-321PBT(Weight scale) and UA-767PBT (Blood Pressure Monitor)
• Important points obtained from the test practice:
  • Use the right Bluetooth service name and application UUID (00001101-0000-1000-8000-00805f9b34fb).
  • Set Android device to 'discoverable' state for the first medical measurement even through, for paired device, it is not required
  • About the Android Bluetooth server (for some medical sensors) work only after rebooting the Android device. This is the first issue we met on the tests. After search on the Internet, We condemned the medical devices uses the fixed RFCOMM port number - #1; and this conclusion was "confirmed" by documentation in the A&D Blackberry code from NexJ, which ask to the port #1 to build Bluetooth server socket. This conclusion could be right form A&D early products. But A&D BTP series current market products (at least UC-321PBT and UA-767PBT) are DSP conformable and use any RFCOMM port number provided by Bluetooth server. The reason of "Android Bluetooth server worked only after rebooting the Android device" is: when the application exited by click the "back" button, it became inactive but its Bluetooth server thread kept receiving signals from medical devices. So the newly started applications could not receive data. Therefore, the issue of "A&D medical devices use fixed Bluetooth port#" is actually not the case.
  • Unreadable data from medical devices may affect the Bluetooth communication. In the tests, we found inappropriate process of unreadable data from medical devices will interrupt the Bluetooth communication, leading to these measurement records accumulated within medical device's memory (up to 40 records). Each time a new measurement is made, unreadable records will sent to Bluetooth server first, and these records will cause the communication failure. The solution for this issue is that the Bluetooth server accepts these wrong data instead of giving exceptions to interrupt the process, then let applications to deal with these invalid data.