User's Manual

Enhanced Class 1 Bluetooth v2.1 Module
User’s Guide
Americas: [phone] Option 2
Europe: [phone]
Hong Kong: [phone]
www.lairdtech.com/wireless
157
CONN-GUIDE-BT740_v0.2
14.5.3 Abstract Data Model
From a software engineer’s perspective, an abstract data model for an IEEE data specialization can best
be described as a collection of arrays of different types of data (which the specifications refer to as
attributes).
Each attribute is unambiguously defined to consist of a tag, a type, and the actual value. There is no
reliance on any programming language in the definition; it is purely a data model.
As a minimum there shall be one array of attributes called the ‘Medical Device System’, henceforth
referred to as an MDS which represents the properties and services of the device, independent of its
health data capabilities and its status. There shall also be one array of attributes called the Numeric,
henceforth referred to as NU which contains episodic measurements. There is also an RT-SA collection
which to represents continuous samples or waveforms.
Other collections exist and the reader is advised to refer to the IEEE11073-20601 standard for a definitive
list, described under the general heading of “Domain Information Model”.
At this point, imagine an HDP agent as just a collection of data records that can be read and written to
locally under program control and each data point is identified by its tag and publishes its data type. This
is analogous to a database table with 4 fields in each record. Three fields are called ‘Tag’, ‘Type’, ‘Value’,
and the fourth field is called ‘Collection Name’ such as MDS or NU or RT-SA.
You should further imagine this ‘database’ as accessible from a Manager over a physical transport media
such as Bluetooth or USB. The procedure a Manager uses to gain access to that database of attributes is
rigidly defined and standardised via a ‘Service Model’ using an association state machine defined in the
IEEE11073-20601 standard. This ‘Service Model’ is encapsulated in the Laird Module and the user is
encouraged to think of it in terms of a black box whose internal details are not relevant.
The picture that should emerge for the Laird module user who requires a data specialization is that of a
black box consisting of that conceptual database with a 4 field table and an ‘engine’ that implements the
association service model over Bluetooth so that it facilitates the mirroring of that said database at the
HDP manager end.
This picture then vastly simplifies the design and development of a health instrument that is required to be
Continua Alliance certified. The hope is that, the user is only required to have a general idea about the
content of the IEEE 11073-20601 and the data specialization IEEE11073-104xx standards.
The following subsections provide more details as to how you can control and manipulate the black box.
Please note that initially only a Weigh Scale data specialization as defined in 11073-10415 is available
embedded inside the black box. By ‘embedded’ it is implied that the MDS and NU collections are pre-
defined as per the standard and the attributes that may change values are exposed to the user for
manipulation.
In future it is hoped that a generic API will be exposed that allows any data specialization to be
downloaded and tested. If a user requires a specific data specialization then they are encouraged to
contact Laird with that request until that generic API is made available.
It is also pertinent to note here that once a user has a working instrument using this module, it is up to the
user to obtain Bluetooth Listing (quoting the QDID of the Laird module) prior to Continua Alliance testing
and certification.