Page 72 - ITU KALEIDOSCOPE, ATLANTA 2019

2019 ITU Kaleidoscope Academic Conference

Table 3 – OpenAPI code snippet of blood pressure The authors also emphasized that healthcare IoT devices
could keep track of the people at risk of developing chronic
{
"swagger": "2.0", disease and manage their ailments. These devices can weave
"info": { into everyday lives, seamlessly collect activity metrics, and
"title": "Blood Pressure", encourage maintaining healthy behaviors. Furthermore, the
... authors stressed that standardizing the healthcare ecosystem
}, was the way forward to ensuring peer to peer independence,
... user’s confidence and data, which eventually lead to
"definitions": { actionable business insights. Since the healthcare industry is
"BloodPressure": { affected by many regulatory bodies, the new group intended
"properties": { to account for privacy, security and global regulatory bodies.
...
"systolic": { The OCF approved the establishment of the Healthcare
"description": "Systolic blood pressure", Project and the specification development was initiated.
"minimum": 0.0,
"readOnly": true, 4.2 Write draft specification
"type": "number"
}, Defining a new OCF device is twofold: Specify the behavior
"diastolic": { and requirements of a new device, and design any necessary
"description": "Diastolic blood pressure", data models which need to support the new device. The
"minimum": 0.0,
"readOnly": true, authors leveraged the existing core functionalities including
"type": "number" the protocol used for transmission [17], data modeling
}, practices [18], and security [19] to ensure the OCF healthcare
... devices are interoperable with other OCF devices from
"type": "object", different silos.
"required": [
"systolic", The authors designed each healthcare device as follows. The
"diastolic" authors specified a minimal set of resources that shall be
] implemented by the device and an additional optional set of
}
} resources that may be exposed by the device. A blood
} pressure monitor, for example, must expose blood pressure
information (systolic blood pressure, diastolic blood pressure,
healthcare applications. Table 2 summarizes the etc.) but may expose mean arterial pressure (MAP), pulse
specification development process in the OCF. The table rate, units (mmHg or kPa), associated timestamp [20] and
provides an overall view of how the authors developed OCF user identification. Defining mandatory and optional
specifications. resources separately allowed minimizing payload
transmitting between OCF devices.
4.1 Identify use cases, scope and requirements
Next, the authors defined healthcare data models based on
New specification development in the OCF starts with the OpenAPI specification [21]. The OpenAPI specification
identifying use cases, scope and technical requirements. In is an open-source project which defines programming
this sense, the authors proposed the Healthcare Project to language-agnostic RESTful APIs. The specification is
initiate standardization on healthcare IoT. The objective of expressed by Swagger [22]. Table 3 is a snippet of authors’
the new group was to evaluate use cases, derive proposed data model for blood pressure. The data model is
interoperability requirements and develop technical uploaded to OCF Github [23] and oneIoTa [24], which is the
specifications for the healthcare vertical within the OCF's official web-based data model repository. The data
framework of the OCF. model specifies how blood pressure data shall be exposed on
the wire. For example, all systolic blood pressure
The goal of the specification was to define OCF healthcare communicated within the OCF must be a read-only floating
devices in healthcare, fitness and medical domains of the number titled “systolic” whose minimum value is 0. The
OCF ecosystem. Regardless of devices, the authors proposed proposed data model was approved by OCF reviewers as
a simplified operational scenario which involves OCF final prior to open-source development because the open-
servers (e.g. body scale, glucose meter, etc.) and OCF clients source reference implementation had to comply with the
(monitoring devices such as smartphones). Eventually, the predefined approved data model.
collected data could be used for tracking users’ fitness
conditions or transferring them to medical institutes to In addition, the authors defined an additional functionality
receive remote services. The technical requirements for and requirement to the core specification [17] to ensure
healthcare specifications were to provide additional better interoperability among OCF devices. In certain use
healthcare device types and data models and, if deemed cases, healthcare devices require that the information of
necessary, additional functional requirements to be added to multiple resources be only accessible as a group and
the core specification [17]. individual access to this information of each resource by an

– 52 –