Difference between revisions of "Phonegap Healthcare Adapter"

From CDOT Wiki
Jump to: navigation, search
m
Line 21: Line 21:
  
 
The unified JavaScript API will be developed to utilize PhoneGap's JavaScript API to make native code calls. These native calls will focus on a medical Bluetooth device adapter which also must be implemented. This Bluetooth adapter will be extended for each supported measuring device and implemented on each supported mobile operating system.
 
The unified JavaScript API will be developed to utilize PhoneGap's JavaScript API to make native code calls. These native calls will focus on a medical Bluetooth device adapter which also must be implemented. This Bluetooth adapter will be extended for each supported measuring device and implemented on each supported mobile operating system.
 +
 +
== Project Scope ==
 +
 +
=== Facts ===
 +
 +
* Not responsible for communication with server
 +
* Responsible for communication with Bluetooth peripherals
 +
 +
=== Questions ===
 +
 +
* Where do the responsiblities of the adapter end? Confirmation that it is an interface to provide data for the mobile solution.
 +
* The need for persistence is apparent, where will this responsibility lie?
 +
* What is the adapters relationship with Bluetooth pairing, if there are no assumptions the adapter is resonsible for device pairing at any time.
  
 
== Supported Versions ==
 
== Supported Versions ==

Revision as of 10:08, 9 August 2012


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

Contributors

Problem

NexjMobile.png

NexJ's mobile health solution requires its smartphone health coach application to have the ability to read medical measurement data from Bluetooth-capable devices, The devices included in the initial project proposal are as follows: blood pressure device, glucose level measuring device and a weight measuring device.

The health coach application will be designed to use PhoneGap, a rising technology that blurs the line between mobile operating systems. Implementing native Bluetooth adapters becomes only part of the solution. The health coach application will interact with a unified API in JavaScript to retrieve data from Bluetooth-capable medical peripherals.

The unified JavaScript API will be developed to utilize PhoneGap's JavaScript API to make native code calls. These native calls will focus on a medical Bluetooth device adapter which also must be implemented. This Bluetooth adapter will be extended for each supported measuring device and implemented on each supported mobile operating system.

Project Scope

Facts

  • Not responsible for communication with server
  • Responsible for communication with Bluetooth peripherals

Questions

  • Where do the responsiblities of the adapter end? Confirmation that it is an interface to provide data for the mobile solution.
  • The need for persistence is apparent, where will this responsibility lie?
  • What is the adapters relationship with Bluetooth pairing, if there are no assumptions the adapter is resonsible for device pairing at any time.

Supported Versions

OSX

  • Xcode 4.3 +
  • OSX 10.7 +
  • iOS 4.3 +
  • Bluetooth SPP capable

Android

  • Eclipse 3.6.2 +
  • ADT Latest
  • Java 1.6 +
  • Minimum OS: 2.2
  • Recommended OS: latest
  • Bluetooth SPP capable

Project Status

Project Backlog

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.

Process Description of Bluetooth Communication

NexjPhoneGap.png

Bluetooth Profile

Serial Port Profile (SPP).

Bluetooth protocols

RFCOMM and Service Discovery protocols.

Pairing

Secure Simple Pairing

Data transmission

Measurement date/time, measurement values, Bluetooth Id of remote unit, mode, and serial number of A&D PBT Series.

Master devices

A&D Bluetooth® devices PBT series, including blood pressure meter, blood glucose meter, and weight scale.

Slave devices/Access Points

mobile devices, including iOS and Android smartphones/tablets.

Communication Process Description for unpaired devices in brief:

  • Enable Bluetooth on the mobile device and set the device to discoverable mode (as slave device).
  • Make a measurement on selected A&D Bluetooth device such as weight scale. Upon the completion of measurement, the device (as master device) searches slave devices and initials Bluetooth communication.
  • The mobile device receives the signal of the A&D Bluetooth device and prompts user to enter a PIN/passkey.
  • Once the PIN is matched, the A&D Bluetooth device sends the measurement data to the mobile device using the specified format such as weight scale packet followed by the Confirmation Packet Response.
  • Upon the success of connection, the two devices are paired. Then PIN code is no longer needed afterward.

Communication Process Description for paired devices in brief:

  • Enable Bluetooth on the mobile device and set the device to discoverable mode.
  • Make a measurement on selected A&D Bluetooth device. Upon the completion of measurement, the A&D Bluetooth device checks its memory for previously paired address of mobile device and directly sends the measurement data to the mobile device using the specified format, followed by the Confirmation Packet Response.

Communication Packet

Communication packet consists of two sections: the dataheader section and the data section.

Header Section

Offset Type Field
0 Integer (2 byte) Packet type (always equal to 2)
2 Integer (4 byte) Packet length (exclusive of 60 byte of data header)
6 Integer (2 byte) Device type – 767 or 02FF (Hex) for UA-767PBT, 321 or 0141 (Hex) for UC-321PBT
8 Byte Flag
9 Integer (2 byte) Year of measurement
11 Byte Month of measurement
12 Byte Day of measurement
13 Byte Hour of measurement
14 Byte Minute of measurement
15 Byte Second of measurement
16 Integer (2 byte) Year of transmission
18 Byte Month of transmission
19 Byte Day of transmission
20 Byte Hour of transmission
21 Byte Minute of transmission
22 Byte Second of transmission
23 Byte (6) Bluetooth ID of remote unit
29 Byte (6) Bluetooth ID of access point (null)
35 Byte (12) Serial Number of A&D PBT Series
47 Byte (10) Reserved
57 Byte Device Battery Status (Note 1)
58 Byte Reserved
59 Byte Device Firmware Revision and Hardware Revision (Note 2)

Data Section

Blood Pressure Device Specification
Offset Type Field
0-1 Printable Hex Valid (= “80”) Non-“80” means invalid BP measurement.
2-3 Printable Hex Systolic – Diastolic
4-5 Printable Hex Diastolic
6-7 Printable Hex Pulse rate per minute
8-9 Printable Hex Mean Arterial Pressure (MAP)
Glucose Device Specification

unknown

Weight Scale Specification

Kilogram Mode

S T , + 1 2 5 . 1 0 k g <CR> <LF>

Pound Mode

S T , + 0 4 0 5 . 2 l b <CR> <LF>

Project Repository

Mercurical HowTo

Branching Rules

  • Nobody commits to default.
    • default is the master branch we will use to generate submissions back to NexJ
  • Nobody commits to dev.
    • dev is the branch were the latest completed features and bug fixes come together for testing
  • Keep branches relevant.
    • If the focus of what your coding changes, make a new branch
  • Best practice is to branch off of dev.
    • Exceptional scenarios call for branching off of default or other branches, you will not encounter them
  • Branch names in lowercase.
  • Hyphenate branch names if required.
    • bluetooth-plugin
  • Branch names must either be:
    • A bitbucket issue, example: issue-14 OR bug-14
    • A feature name, example: cryptography-bug

Resources