The 4S Device Communication module collection is a library for applications interacting with personal health devicesPersonal Health Device (like blood pressure monitors, oximeters, thermometers, weight scales, exercise bikes and so on). The main focus is on devices compliant with the Continua Design GuidelinesContinua Design Guidelines, but other types of devices are also supported.
4SDC4S Device Communication (module collection) comprises a cross-platform library written in C++ which is able to communicate through a Platform Abstraction Layer (PAL) with platform-specific modules. We currently have some support for Android, iOS, Linux and OS X.
Furthermore, there is a Qt5-based demo application,
Notice that 4SDC4S Device Communication (module collection) is not meant to be a stand-alone software product (even though you are free to use our demo application). 4SDC4S Device Communication (module collection) is intended to be used as a code library, which will provide communication between your software and the personal health devicesPersonal Health Device.
The 4SDC4S Device Communication (module collection) 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 4SDC4S Device Communication (module collection) as well. Furthermore, the 4SDC4S Device Communication (module collection) project is currently used by the 4S organisation to develop the governance models needed to support certification according to the Medical Devices DirectiveMedical Devices Directive, more specifically the software life cycle processes of IEC 62304IEC 62304.
The 4SDC4S Device Communication (module collection) 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 4SDC4S Device Communication (module collection) 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 4SDC4S Device Communication (module collection) – as the “application” and a personal health devicePersonal Health Device as the “printer”. The standards mandated by ContinuaContinua Health Alliance (such as Bluetooth HDP(Bluetooth) Health Device Profile and IEEE 11073 PHDISO/IEEE 11073 PHD) or any proprietary device communication will play the role as “communication protocol” and “document format”, and finally 4SDC4S Device Communication (module collection) itself will be the “printing system”. As this analogy illustrates, the purpose of the “printer drivers” of 4SDC4S Device Communication (module collection) 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 Continua Design GuidelinesContinua Design Guidelines have a significant influence on the architecture of 4SDC4S Device Communication (module collection), many important features in 4SDC4S Device Communication (module collection) are completely out of their scope. Furthermore, 4SDC4S Device Communication (module collection) must support any type of device, and cannot be limited to only ContinuaContinua Health Alliance compliant devices. Focus is on the needs of OpenTele, and in OpenTele a number of non-ContinuaContinua Health Alliance-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.
The documentation is available in two formats – as either online web-pages or a downloadable PDF file. Furthermore, you can choose between the “public interface” and “full developer” versions. Unless you are planning to contribute to the core of 4SDC4S Device Communication (module collection), stick to the “public interface” version – the other one is huge and contains lots of irrelevant details.
Instructions about how to build and run the demo application is kept here at the wiki. Please feel free to contribute to these wiki pages with any issue you come across when testing the demo on your platform, in order to help others get up and running as smoothly as possible.
The following devices are currently supported by 4SDC4S Device Communication (module collection) (sorted by type and with transport class in parentheses):
Notice, however, that the demo application depends on Qt libraries, hence the demo application will inherit the Qt license terms. Qt has a dual license – you may choose between the “copy-left” LGPL license or a commercial license, which you will have to buy from The Qt Company. More information here.
Currently, the 4SDC4S Device Communication (module collection) core libraries and the demo application are kept in the same repository. This is only temporary! Stay tuned, as the core libraries will be moving out to a different repository in the (near?) future.
Source code contributions can be submitted as pull requestsPull Request. Again, please read our general 4S guidelines before submitting. Furthermore, please contact us before you start making contributions, in order to coordinate the work.
Improvements to our wiki-guide on building and running the demo application are also welcome. This page will guide you through contributing to the wiki.