4S Device Communication Module Collection  Version 0.6-SNAPSHOT
Public interfaces of the modules in the 4SDC collection (aimed at users of the 4SDC modules)
Architecture

The 4SDC module collection is born out of – and closely linked to – the OpenTele3 architectural design efforts. The General Principles of the OpenTele3 architecture are all fundamental in the architecture of 4SDC as well. Furthermore, the 4SDC project is currently used by the 4S organisation to develop the governance models needed to support certification according to the Medical Devices Directive – specifically the IEC 62304 [10] software life cycle processes.

The OpenTele3 architectural design relates to the Danish Reference Architecture for Collecting Health Data From Citizens ([5] and [6]). This reference architecture in turn points toward the Continua Design Guidelines (CDG) [9] as a technical framework for collecting the data from personal health devices. As this is the core purpose of 4SDC, a basic understanding of the CDG would be a good place to begin. A brief introduction to the CDG can be found in this Fundamentals of Data Exchange white paper [8].

The purpose of this and the following pages is to describe the 4SDC overall architecture, as well as the reasoning behind it. To set the stage, the following sections will present the scope of this module collection and explain some of the key terms and concepts. On the following Background and Basics page the basic requirements and their implications on the overall architecture are presented. This will then lead to the presentation of the (goal) architecture for the 4SDC module collection on The 4SDC Architecture page. Finally, the Architecture Status and Road-maps page will outline the status of the current 4SDC library, and how we plan to complete the implementation of this architecture.

Scope

The 4SDC library is not intended to be just another implementation of communication standards, rather it is designed to be a framework adapting to the users' needs, drawing on the extensive experience from OpenTele. To better understand what the 4SDC is designed to accomplish, consider the following analogy:

You are about to print a hardcopy of a document on a printer. In order to do so, your application must communicate with the printer, so there must be a communication protocol in place (for instance communication over a local network). Furthermore, your application must provide the printer with a description of what the printed page should look like, so the application and printer must share a document format (PostScript is a commonly used format for this). This is all you will need to get the document hardcopy – if all goes well, that is. For what will happen if your printer is out of paper or toner, or perhaps experiences a paper jam? Or what if you want to print on both sides of the paper or want to use the built-in stapler? You would want your application to help you with that, right?

Now, if you have 10 different applications and 4 types of printers, and each application should be able to handle all printers, you would need 40 integration efforts to make that possible!

Introducing the operating system's printing system with printer drivers: rather than having each application communicating directly with the printer, the application will deliver its document to the OS printing system which will use one of the just 4 different printer drivers to interact with your printer. The printer drivers will offer access to the advanced settings of the printer (such as duplex printing or stapling), and help you troubleshoot problems – typically with images or even animated guides instructing you to fix paper jams or change the toner cartridge.

To complete this analogy, think of OpenTele – or any other application using 4SDC – as the "application" and a personal health device as the "printer". The standards mandated by the CDG (such as Bluetooth HDP [3] and IEEE 11073 PHD [2]) or any proprietary device communication will play the role as "communication protocol" and "document format", and finally 4SDC itself will be the "printing system". As this analogy illustrates, the purpose of the "printer drivers" of 4SDC is not merely to provide communication between the application and the device, but their purpose is also to focus on the users' needs, providing in-context user instructions and help/guides.

So while the CDG have a significant influence on the architecture of 4SDC, many important features in 4SDC are completely out of their scope. Furthermore, 4SDC must support any type of device, and cannot be limited to only Continua compliant devices. Focus is on the needs of OpenTele, and in OpenTele a number of non-Continua-compliant devices are currently in use. Most likely, this will always be the case, as there will always be a need for using new and experimental (or proprietary) devices (at least in research projects). Furthermore, as a new device type is introduced to the market, it will take a couple of years before a standard way of communicating with this device is ratified, and in the meantime only non-standard communication protocols can be available.

Terminology

Before we dig into the architecture details, this section will list the terms and definitions used in the remainder of this document.

Components

Software components are classified and grouped using the following terms:

UML'ish illustration of model relations
Example of the relation between modules, submodules, and units.
a hack to tell Doxygen to copy the image file
modulerelation.svg

Unit
This word is used to indicate the smallest / atomic software components – typically a class or a compilation unit (i.e. a source file). This is different from a module (defined below) as a unit need not have any public interfaces, nor does it have to adhere to the module contract. A (very small) module may also be a unit, however, this is probably a rare case.
Module and Module interface
A module is a software component, which is independently replaceable (and upgradable). It is fully defined by a set of module interfaces (which are always public), and other modules exposing the same module interfaces may be used as drop-in replacements (possibly resulting in different functionality). A module must adhere to the Module Contract.
Submodule
Larger modules may be constructed by a number of smaller components, called submodules, which in turn may comprise more submodules and so on. Submodules are not subject to the Module Contract, although they may adhere to some or all of the requirements. (Typically submodules will expose private interfaces.) See the figure for an example of this.
Module collection
This term is used to signify a group of modules sharing governance, such as the 4SDC Module Collection. The modules of the collection will reside in the same source code repository and share version/revision numbers etc. A module collection may comprise modules that are not normally used together (thus, not belonging to the same runtime library). For instance, one subsets of the 4SDC module collection may be used to build a device communication library for Android and a different subset will build a library for iOS.
Layer

This is another term used to group related modules based on their function / purpose. Please read section ?? for more information. Notice that two modules may belong to different module collections but be in the same layer or vice versa.

Todo:
link to architecture.

Terms inherited from CDG

The following terms are inherited from the Continua Design Guidelines (CDG)[9] and all the related standards, these guidelines recommends:

Personal Health Device (PHD)
This is the general term used for all the kinds of devices that may be connected to 4SDC. The term comprises medical sensors (such as blood pressure monitors, thermometers, oximeters etc.), medical actuators (e.g. insulin pumps), as well as health and fitness devices (e.g. weight scales, pedometers, cadence sensors, activity monitors).
PAN
A personal area network is typically defined as a network with a short range of about 10 meters. As the name suggest, it is typically centered around a person and "moves" with her – for instance with a smartphone or laptop as the central hub. In the CDG three technologies are recommended:
  • USB which is a cabled network with a range of 5 meters.
  • Bluetooth Classic which is a wireless network with a range of about 10 meters (see below).
  • Bluetooth LE which is a wireless network with a range of about 10 meters (see below).
LAN (Sensor)
A local area network is typically covering a larger area than the PAN and in addition to that, it is normally fixed to a geographic location – for instance permanently installed in a building. CDG currently recommends only one LAN technology:
  • ZigBee which is a low-power wireless network typically used for home-automation, and especially suited for long-time battery-operated sensors.
TAN
A touch area network is like a PAN but with a significantly shorter range – less than 1 meter, and often in the order of a few cm. TAN technologies often (but not always) includes power transfer, so that the sensor device need not have its own power supply, but receives power from the master device during the communication. CDG currently recommends only one TAN technology:
  • NFC which is a group of standards from the RFID family of technologies. It supports wireless communication within a range of (typically) less than 10 cm along with wireless power transfer to the sensor.
Bluetooth Classic (BC)
The original Bluetooth wireless cable-replacement standard, also known as Bluetooth Basic Rate / Extended Data Rate (BR/EDR). The technology behind BC is fundamentally different from BLE (see below) and a BC-only device will not be able to communicate with a BLE-only device. Even the communication protocols used for personal health devices are completely different. BC uses the HDP profile (also described below) along with the IEEE 11073 PHD standards[2] for PHD communication.
Bluetooth LE (BLE)
The new Bluetooth wireless cable-replacement standard for low power (and low data throughput) communication (also branded as "Bluetooth Smart"). The BLE technology is fundamentally different from BC (see above) and a BC-only device will not be able to communicate with a BLE-only device. Even the communication protocols used for personal health devices are completely different. BLE uses the GATT profile (see below) along with different specific profiles and transcoding[4] for PHD communication.
Health Device Profile (HDP)
The Bluetooth (classic) HDP[3] defines how a BC-based personal health device can be connected to a host and deliver data using the IEEE 11073 PHD[2] protocol.
Generic Attribute Profile (GATT)
The parent of all Bluetooth LE profiles. BLE sensors publish one or more services, each exposing a number of characteristics, containing attributes that may be queried using operations from the Generic Attribute Profile.
Personal Healthcare Devices Class (USB-PHDC)
The USB PHDC[12] defines how a USB-based personal health device can be connected to a host and deliver data using the IEEE 11073 PHD[2] protocol.
ZigBee Health Care Profile (ZHC)
The ZigBee ZHC[11] defines how a ZigBee-based personal health device can be connected to a host and deliver data using the IEEE 11073 PHD[2] protocol.
Personal Health Device Communication (NFC-PHDC)
The NFC PHDC[7] specification defines how an NFC-based personal health device can be connected to a host and deliver data using the IEEE 11073 PHD[2] protocol.
AHD
The Application hosting Device, also known as the Personal Health Gateway, is the point of data collection near the citizen. Typically a smartphone, pc, tablet, or a set-top box. The role of the AHD is to collect the data from the PHDs and forward these data to the WAN device (see below) using the PCD-01 data format (see below).
WAN (device / interface)
The WAN (wide area network) device, also known as the Health and Fitness Service, is the central point of data collection hosted by the service provider. This is where the AHD will deliver the collected data. The WAN interface (between the AHD and WAN devices) uses the PCD-01 data format (see below).
PCD-01
The data format for WAN interface communication (between the AHD and WAN devices) is defined by [1]. The CDG recommends using either SOAP or REST as the exchange protocol with PCD-01 as the message content.

Proceed to Background and Basics