Difference between revisions of "Phonegap Healthcare Adapter Design"

From CDOT Wiki
Jump to: navigation, search
(Mobile Device Libraries)
 
(3 intermediate revisions by one other user not shown)
Line 1: Line 1:
 +
{{Admon/obsolete}}
 +
 
[[Category: NexJ_Express]]
 
[[Category: NexJ_Express]]
 
[[category: NexJ Express PhoneGap]]
 
[[category: NexJ Express PhoneGap]]
Line 5: Line 7:
 
'''''NexJ Medical Peripheral Mobile Adapter''''' Will be designed to enable NexJ's Mobile Healthcare solutions to interact with Bluetooth peripherals.
 
'''''NexJ Medical Peripheral Mobile Adapter''''' Will be designed to enable NexJ's Mobile Healthcare solutions to interact with Bluetooth peripherals.
  
: ''{{Main|Phonegap Healthcare Adapter}}''
+
: ''{{Main|Mobile Medical Device Integration}}''
 +
: ''{{See Also|Phonegap Healthcare Adapter Bluetooth Implementation|Phonegap Healthcare Adapter Bluetooth Spec}}''
  
 
== Class Diagram ==
 
== Class Diagram ==

Latest revision as of 19:37, 26 January 2014

Important.png
This page may be obsolete.
It contains historical information.

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