- From: Marcos Caceres <marcos@marcosc.com>
- Date: Thu, 25 Sep 2014 13:21:05 -0400
- To: Marcos Fábio Pereira <marcos.pereira@signove.com>
- Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>, Mats Wichmann <m.wichmann@samsung.com>
On September 25, 2014 at 1:07:17 PM, Marcos Fábio Pereira (marcos.pereira@signove.com) wrote: > Basically we have health devices using: > > Bluetooth Serial Port Profile (SPP) > Bluetooth Heatlh Device Profile (HDP) > Bluetooth Low Energy 4.0 (BLE) > USB > ZigBee > NFC > > Continua guidelines recomend the use of: > *) Bluetooth HDP with IEEE 11073 standard over it. > *) Bluetooth low energy GATT profiles that are able to be mapped (or > transcoded) to IEEE 11073 infrastructure. > *) USB using PHDC and IEEE 11073. > *) NFC using a specific profile defined by NFC-Forum and IEEE 11073. > *) ZigBee using something that I can´t remember. > > The main reason to choose IEEE 11073 standard, is to have a common > specification to represent/model personal health devices (eg. how to > represent a blood pressure device?). > That´s why even though BLE GATT provides health profiles, Continua > recommends to use a miniminum set of attributes and precision to make > possible "map" them to IEEE 11073 structures. > > Besides Continua's guidelines, some manufacturers define and use their own > protocols over Bluetooth SPP. So, they do not follow any standard for > that... Ok, then this definitely looks like it should be happening in the BlueTooth CG [1]. We are initially doing GATT, and later adding a serial port interface. Seems that would cater for both GATT-based communication and for custom protocols over SPP. Eventually, we might want to bring the BT work over to DAP - but it would be nice to have working prototypes running, for instance, using Chrome App's BT implementation before attempting any standardization. USB, NFC, and ZigBee should also be exposed independently of domain. [1] http://www.w3.org/community/web-bluetooth/
Received on Thursday, 25 September 2014 17:23:46 UTC