Difference between revisions of "Phonegap Healthcare Adapter Design"

From CDOT Wiki
Jump to: navigation, search
(iOS)
(Mobile Device Libraries)
Line 71: Line 71:
 
** These all data transfer between physical devices
 
** These all data transfer between physical devices
 
** Bluetooth protocols are transparent
 
** Bluetooth protocols are transparent
 +
 +
=== Comparison ===
 +
==== Requirements ====
 +
* Querying of devices
 +
** Supported by both platforms on both communication mediums
 +
* The ability to fetch data from devices
 +
** Supported by both platforms on both communication mediums
 +
** Assuming connections have been created with medical devices, this requires a known address to be cross referenced with current devices from the ''query'' functionality above
 +
* ''Optional'' The ability to push data to devices
 +
** See above
 +
==== Assumptions ====
 +
* NexJ's spec dictates that devices can be assumed paired
 +
* Any semantic information required will be provided upon initialization

Revision as of 16:12, 17 August 2012


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

Class Diagram

NexjBluetooth.png

Classes

phonegapMedicalDeviceInterface

  • Interface to a medical device for use by the NexJ mobile health solution
  • Implemented in Javascript

medicalDevice

  • Representation of a medical device
  • Delegates to a native medical device interface
  • Implemented in Javascript

nativeMedicalDeviceInterface

  • Private interface to physical medical devices
  • Implemented in native code (Objective C on iOS, java on Android)

bluetoothAdapter

  • Adapter to allow medical device objects to interact with communication libraries on the device
  • In the future a Wifi adapter will also be needed to fulfill the same role of communication over another protocol
  • Implemented in native code

bloodPressureBluetoothAdapter

  • Adapter to allow medical device objects to interact with specific medical peripherals
  • These will be needed for each type of medical peripheral
  • Implemented in native code

Native Bluetooth API

  • Libraries on the mobile devices SDK that allows programmable interaction with Bluetooth devices

Blood Pressure Device

  • Physical medical device peripheral

Flaws

  • Should we be concerned about managing the instances of medicalDevice or will the rest of the solution
    • Rest of the application: It becomes more of a Medical device factory
    • This Project: Another layer should be added to represent a device manager
  • bloodPressureBluetoothAdapter should know about specific device communication without relying on any specific communication protocol, otherwise it will need be reimplemented per communication adapter(eg. BluetoothAdapter, WifiAdapter)

Mobile Device Libraries

iOS

Wifi

  • Unknown at this time

Bluetooth

  • CBCentralManager entry point to Bluetooth communication
    • Allows querying of devices
    • Can list connected devices
    • Can connect to devices, creating CBPreripheral Objects
  • CBPeripheral's allows reading and writing of CBCharacteristic Objects
    • Can listen for changes to characteristics
    • Writing and reading is event driven programing via callback parameters
  • CBCharacteristic's represent a piece of data from a device along with semantic data

Android

Wifi

  • WifiP2pManager is the starting point for all peer to peer communication
    • Upon initialization devices connections can be established
    • Peers can be queried

Bluetooth

Comparison

Requirements

  • Querying of devices
    • Supported by both platforms on both communication mediums
  • The ability to fetch data from devices
    • Supported by both platforms on both communication mediums
    • Assuming connections have been created with medical devices, this requires a known address to be cross referenced with current devices from the query functionality above
  • Optional The ability to push data to devices
    • See above

Assumptions

  • NexJ's spec dictates that devices can be assumed paired
  • Any semantic information required will be provided upon initialization