gms | German Medical Science

Telemonitoring typically comprises the periodic measurement of vital data on a sample basis, e.g. blood pressure or blood glucose level. However, there are also use cases where a continuous measurement of data is required. This kind of measurement produces a large amount of raw data that is typically not processed on the measuring device, but in a centralized unit of the telemonitoring system dedicated to high performance analysis. A current scenario for continuous monitoring is motion tracking in diseases with motor impairments. For example, in the research project Parkinson Therapy Control (PTC) [1] at the University of Applied Sciences in Ulm, a telemonitoring system was designed to support the control of therapy in Parkinson patients by means of external sensor units for motion tracking (9-axis inertial measurement unit).

As interoperability is regarded as a key technology-related factor for the high acceptance of telemonitoring systems [2], the transmission of continuously recorded data to a centralized unit should also be compliant with well-established standards. In the particular case of healthcare, interoperability enables information systems, medical devices and software applications to collaborate across organizational boundaries in order to improve the health status of individuals and the community. The initiatives Integrating the Healthcare Enterprise (IHE) and the Continua Health Alliance push interoperability forward by publishing guidelines, which define the appropriate standards for communication between typical components of a telemonitoring system. They propose the application of the ISO/IEEE 11073 Personal Health Device (PHD) standards, in the following denoted as X73, for communication between medical devices and application hosting devices (e.g. a smartphone). The X73 standards family is based on the X73-20601 framework standard and provides different device specializations for commonly used medical devices like blood pressure monitors or thermometers. The data transmission from application hosting devices to a remote medical service is specified in HL7 Version 2 messages via SOAP-based Web Services.

The use case of transmitting a high amount of raw motion data is not entirely covered by the guidelines of Continua and IHE. However, the transmission of continuously measured motion data represents the current trend for motion recording. The aim of this paper is to show how continuously measured motion-data can be transferred according to the IHE/CHA profiles and which adaptations are reasonable to achieve a high efficiency. The paper provides detailed results to support comparable work groups with their implementation.

Telemonitoring typically involves small wireless medical devices attached to the patient's body, an application hosting device such as a smartphone, and a medical service in the World Wide Web. Inertial sensors (accelerometer, gyroscope and also possibly a magnetometer, also called a MARG sensor) can be used e.g. for the detection of movement disorders, for rehabilitation, or gait analysis. The research group of Ferreira et al. placed inertial measurement units (accelerometers and gyroscopes) at relevant locations on the human body to measure postural imbalance in Alzheimer’s disease [2]. Various research groups describe the application of 9-axis inertial sensors for gait analysis in rehabilitation [3], [4], [5].

Patel et al. present a system in which Parkinson patients continuously wear 8 accelerometers, based on the Shimmer sensor platform, for 12 to 18 hours a day on their upper and lower limbs. The goal is, “to identify movement characteristics associated with motor fluctuations in patients with PD relying on wearable sensors” [6]. The collected data is processed to derive estimates of the Unified Parkinson’s Disease Rating Scale (UPDRS). The EU-funded PERFORM project [7] takes a similar approach with only 4 accelerometers on the limbs and one at the center of the body. Herrlich et al. [8] also implements a telemonitoring system for the ambulant treatment of Parkinson patients by means of a set of different sensors which include 9-axis inertial sensors, a smartphone as a mobile application host, and a web-based user interface at the point of care. Additionally, they equip patients with self-developed intraoral actuators for automatic drug delivery. Due to incompatibilities between these actuators and the Continua guidelines, they abandoned the guidelines and developed a private communication profile.

Several research groups limited their efforts in the implementation of a particular interface and related hard- and software. For example, Led et al. [9] developed a X73 compliant wearable electrocardiogram recorder. It is built for use in the intelligent bag, a mobile Point-of-Care (POC) including a tablet-PC and several plug-and-play medical devices such as a glucometer, a thermometer or a blood pressure meter. Ganchev et al. [10] focused on developing a suitable system for processing large data sets in remote patient health monitoring. The system includes a X73 compliant software adapter service for application hosting devices, and a distributed data processing system in the cloud. The interface between an application hosting device and cloud is covered by a proprietary protocol that is not defined more precisely. Lim et al. [11] present a X73 set-top-box for the management of chronic diseases in home environments. As the set-top-box will be mainly used by elderly patients, they focused on high usability but also on the implementation of standards. They used the Continua-Enabling Software Library (developed by Continua) to verify the compatibility of their set-top-box with X73.

Some research groups comply with the Continua guidelines for data transmission from a sensor, via an application hosting device, to a server. In the iCARDEA project, described by Yang et al. [12], a guideline-based telemonitoring system for implantable cardiovascular electronic devices was developed. Here, information on events, like shocks or arrhythmia, as well as electrocardiogram data formatted in PDF are encapsulated with X73 nomenclature and converted into an HL7 Version 2.5 message. Frohner et al. [13] developed an Android application providing an X73 interface, verified by existing commercial X73 medical devices, as well as an interface to a remote medical service implementing HL7 Version 2.6 messages.

As a first step, a general application scenario was given to define typical requirements and conditions for motion tracking. Subsequently, the guidelines and standards were analyzed as to how they met the needs for the given scenario and which alternatives were reasonable.

Inertial sensors can be used for motion tracking in telemonitoring systems. The goal of these systems is the long term monitoring of motion symptoms in the home environment of the patient. A typical monitoring period is 2 to 4 weeks long. Movement fluctuations during the day and their relation to medication dose might be analyzed by the practitioner, and results in a patient specific adaptation of therapy.

In a general scenario, the patients wear up to 5 inertial sensor units on their limbs and in the center of body during the whole day (8 h). The sensor unit comprises a 9-axis inertial sensor with a sampling rate of 100 Hz. One time per second one data package with 1266 Bytes is sent from the sensor unit to the smartphone via Bluetooth. In detail, these data packages consist of 600 Bytes acceleration, 600 Bytes angular rate, 60 Bytes magnetic field, 2 Byte temperature, 2 Byte battery level, 1 Byte photo sensor and 1 Byte system status flags (1266 Bytes netto without header). Assuming a recording time of 8 hours per day, the smartphone has to transmit approximately 37 MB per sensor unit. For more than one sensor unit, the amount of data has to be multiplied accordingly.

Raw data will typically be transmitted to the server once a day. The server receives and processes the raw data and performs the analysis. Results are available for physicians and patients upon request. The physician can assess data, generate a medical report and export it to the electronic health record of the patient.

The interface descriptions are based on the Continua End-to-End (E2E) reference architecture (see Figure 1 [Fig. 1]). Except where otherwise indicated, the subsequent section is based on the official Continua Design Guidelines Version 2014 [14].

The Personal Area Network Interface (PAN-IF) connects an application hosting device to a personal area network device that is typically a sensor (e.g. a glucose meter, weight scale, etc.), but may also be an actuator (e.g. a device that turns off the light or sets off an alarm). The application hosting device, or gateway device, may be a personal computer or a mobile phone, where the information is collected, analyzed and shared.

The PAN-IF is structured into three distinct layers, each of them with assigned appropriate standards. The transport technology for communication between the PAN device and the application hosting device can be divided into wired transport, represented by the USB Personal Healthcare Device Class standard and wireless transport represented by Bluetooth Health Device Profile (HDP) or Bluetooth Low Energy (LE). On top of that, Continua also specifies potential exchange protocols. Whereas the X73-20601 Personal Health Device Communication protocol [15] outlines the optimized exchange on top of USB or the Bluetooth HDP transport protocol, the wireless Bluetooth LE interface must use the Bluetooth LE device profiles. Nevertheless, both exchange protocols use nomenclature and data types compatible to those defined in X73.

Since the applied sensor platform comprises of a Bluetooth 2.1 module supporting Bluetooth HDP, the standard family X73 is given below. The core document of the standard family, i.e. X73-20601, contains the basic information for all the devices specified by the standard family. The central concept of the standard family deals with the conception of agents and managers. The software module deployed to the medical device is referred to as the agent, while the corresponding counterpart that receives the measured values supplied by the agent is called the manager. The properties and behavior of agents and managers are described in the core document of the standards in the form of three models. The domain information model (DIM, X73-10201) defines and structures all information that is utilized in the communication between all application entities in an object-oriented manner. The extract of the DIM which is required to represent the device and metric information involved in the upload of medical device data is denoted as containment tree. The conceptual mechanisms for data exchange in the form of various services such as GET and SET are described by the service model. The communication model defines both the characteristics of the communication and the state machine of a connection between agent and manager, as well as valid interactions between the two components.

As a further part of the X73 standard family, the X73-10101 document focuses on semantic interoperability by specifying a common nomenclature for medical device communication semantics. It therefore contains an extensive set of term codes supporting the information model, device parameters, units of measurement, body side etc. For devices that are not standardized or that are private and should only be recognized by selected applications, the X73 terminology reserves a block that can be used for private terms.

Beside these general-purpose definitions and concepts, the standard family includes so-called device specializations (X73-104xx) that further specify certain types of medical devices, such as blood pressure monitors, in more detail.

The primary role of the WAN interface is to establish an interoperable connection for delivering messages between in-home or mobile application hosting devices and one or more WAN devices. A typical WAN device implements a service across a wide area network that collects information and hosts a wide range of value-adding services like health or fitness monitoring services. An example of a WAN device may be a remote patient monitoring server hosted by a disease management service provider.

For the realization of this interface, Continua references the IHE Device Enterprise Communications (DEC) [16] profile. The primary transaction in the DEC profile is called PCD-01: Communicate PCD Data. The messages defined by this transaction have been selected for the application in Continua WAN interfaces to enable the upload of device observations. As visualized in Figure 1 [Fig. 1] the PCD-01 transaction prescribes the usage of HL7 Version 2.6 messages of the message type Unsolicited Observation Result (ORU) as a messaging exchange protocol. For transport technology, SOAP-based web services are required. In addition, PCD-01 transaction bases the semantics of its messages on the X73-10101 nomenclature and the X73-10201 DIM.

The HL7 message type ORU obligatorily consists of exactly one Message Header (MSH) segment, one Patient Identification Segment (PID) and arbitrarily repeatable Observation Request (OBR) and Observation Result (OBX) segments, which contain the actual device and measurement data. The ORU message structure provides the mechanisms for mapping the hierarchical structure of an X73 containment tree to a series of OBX segments.

The PCD-01 transaction mainly targets the transmission of vital data that are measured at a certain point in time, such as systolic blood pressure measured at 8 PM. This is different from the data that is intended to be transmitted during the telemonitoring with the sensor units for motion tracking. Here, the main goal is to record motion data with a defined sampling rate over a certain time interval. Therefore, it had to be examined whether Continua or IHE provide solutions for the transmission of continuous data.

Indeed, IHE offers a supplementary framework called Waveform Content Module (WCM) [17], which can be applied to several of its PCD profiles. The main intention of this module is the definition of structure and semantics to communicate waveform and other time-series data sets. Although the WCM supplement aims to transmit ECG waveform snapshots, the proposed concept can be well adapted for the described telemonitoring scenario. The main difference to the common approach proposed by Continua and IHE PCD-01 is that the waveform data are contained as an instance of the channel level. This means measurements are not transmitted metric-wise, but channel-wise. Due to time intervals, the HL7 message must now also include the start and end times of the recorded interval which should be included in the OBR segment.

The WCM supplement of IHE proposes to send the data as a numerical array (NA) of decimal values. Moreover IHE PCD-01 limits the length of the OBX-5 field to 99,999 characters. According to the given precondition of 8 hours recording time, a total data volume of 37 MB per sensor unit has to be transmitted. In order to transfer 37 MB payload data as NA, a total traffic of 112 MB data in 177 messages would be necessary (see Table 1 [Tab. 1], left row). As an alternative, HL7 provides the possibility of including a binary object using the data type encapsulated data (ED) and sending the object Base64 encoded. This reduces the total traffic to 50 MB data and the number of messages to 80. Instead of including the data within the message itself, the actual measurement data could also be transmitted separately while only being referenced within the message. For this purpose, HL7 V2.6 provides the reference pointer (RP) data type. Table 1 [Tab. 1] shows that the ratio of payload to frame data is excellent and only one message is required for a full day of recording. All raw data can be sent directly as application data type, subtype octet-stream (uninterpreted binary data).

IHE and Continua prescribe the deployment of web services as transport technology for the interface between the application hosting device and the server. The two most common web service variants are SOAP-based and RESTful web services. SOAP-based web services represent an XML-based platform-independent API for remote procedure calls. In contrast, the REST approach is based on the consumption and manipulation of resources via HTTP methods. Although IHE and Continua propose to use the SOAP-based variant of web services, the question arises whether the less complex RESTful web services could also be applied. Therefore, a comparison between both forms of web services was performed based on a set of criteria that seem to be essential for the intended system. The results of this comparison are highlighted in Table 2 [Tab. 2].

As recorded data is forwarded and consumed via smartphone, the applicability with mobile platforms represents a key point for the comparison. Furthermore, the data type, which is binary, has to be regarded especially with reference to transmission possibilities and performance. As always when dealing with medical data, security plays an important role and has to be considered. Last, but not least, scalability and flexibility are major topics when it comes to the productive deployment and maintenance of telemonitoring applications that are intended to be used by large amounts of patients.

Regarding performance and scalability, the lightweight RESTful web services seem to have an advantage over the complex and heavyweight SOAP-based web services. Additionally, as has been noted by Hamad et al. [18], RESTful web services are recommended for the consumption of web services by mobile phones. With regard to security related topics, REST-based web services are often deemed less convenient than the SOAP-based variant. Indeed, there are comprehensive and detailed security specifications and implementations which cover a large range of security aspects in SOAP-based web service communication. Due to the importance of security measures, it was decided to examine the security requirements and their possible implementation in more detail. The OWASP (Open Web Application Security Project) Cheat Sheets on the subject of web service security [19] were used as the formal foundation for comparing both web service variants. As a result of the comparison, it can be stated that all requested security features can be realized with either variant.

The aim of the Electronic/Personal Health Records Network Interface (xHRN-IF) is to communicate medical patient data from a WAN device to another WAN device, or an electronic health record. The typical xHRN device represents a health record database or another system that is managed by a traditional healthcare service provider like a hospital or a physician. Consequently, the xHRN interface enables enterprise healthcare entities to collaborate by exchanging health information.

One difference to the other interfaces is that both facilities must identify the right patient in their system for the correct assignment of transferred data. For this purpose, the IHE Patient Identifier Cross-reference (PIX) profile has been selected. The message exchange protocol is defined by the Implementation Guide for HL7 CDA R2: Personal Healthcare Monitoring (PHM). Message semantics depend on the data and can be SNOMED, LOINC, or UCUM units-of-measure using X73 terminology. The document exchange can be done via secure email or a fileshare according to the IHE Cross-Enterprise Document Sharing (XDS) profile or via direct communication according to the IHE XDR (Cross-Enterprise Document Reliable interchange).

Continua defines the data for transfer as “a report summarizing the patient’s current status, a detailed listing of specific patient results, readings from one or more personal health devices, or a combination of these“ ([14], chap. 12). The communicated information, e.g. vital data, must be agreed as relevant for the patient health condition from both communication parties. So far, there are no established metrics for the analysis of motion data. Hence, the raw motion data are necessary on a central server e.g. for the visualization of a 3D-animated human avatar in combination with the evaluation of new metrics. However, it is not reasonable to transfer them completely to the electronic health record. In this application scenario, it is assumed that the physician can assess data on the WAN device. At the moment, it is not clear which metrics are relevant for the EHR. Hence, the xHRN interface has not been evaluated in this step and will be neglected in the section results.

A concept for the use of the Continua design guidelines in the motion tracking scenario has been developed and successfully implemented in a prototype for the PTC project. The distinctive feature of the scenario is the efficient transmission of continuously measured motion data to the WAN-device. The following section gives an insight into how the guidelines have been realized and adapted for each component to support the intended telemonitoring system. All implemented devices and interfaces are visualized in Figure 2 [Fig. 2].

The transport protocol for the communication between the PTC inertial sensor unit and the smartphone is Bluetooth 2.1. The most appropriate device specialization for a 9-axis inertial sensor unit is the X73-10441 “Cardiovascular fitness and activity monitor”. In the specification, two Real-Time Sample Array (RT-SA) objects are defined for acceleration and angular rate (gyroscopes) measurements.

With the help of a domain expert, a DIM for the PTC sensor unit was developed using the objects proposed by the X73 device specialization where appropriate.

The elaborated containment tree, an extract of the DIM, is depicted in Figure 3 [Fig. 3]. The PTC sensor (Medical Device System, MDS) unit can be considered as an aggregated device that includes multiple Virtual Medical Devices (VMD), i.e. the inertial sensor, a magnetic field sensor and a photo sensor. Although the magnetic field sensor is a physical part of the inertial sensor, it has been logically separated in the model with regard to the default configuration. Furthermore, the sensor device is able to deliver information that can be used to evaluate the quality of data measured by the device. These flags are also summarized as a Virtual Medical Device. VMDs can further be broken down into channels that deliver related metrics. Whereas gyroscope, accelerometer and magnetic field provide metrics for three axes each (x, y, and z-axis), photo flags, temperature channel and battery voltage channel only deliver one metric each. After having identified the objects and arranged them in an object hierarchy, the objects are provided with attributes. To process the data on the server, the MDS object should be equipped with the sensor unit device identifier. Additionally, the device’s location on the patient’s body during recording should be transmitted for later analysis. Since all metrics related to a channel are delivered by the sensor unit device with the same sampling rate, all channel objects are provided with a sample rate attribute. Where available, the attributes have also been assigned a textual reference identifier from the X73 nomenclature. Since not all attributes appear within the nomenclature, custom reference identifiers were defined for these attributes.

The developed information model serves as a basis for communication between system components. Therefore, upon establishing the connection for the first time, this information model is transmitted from the agent to the manager in the form of an extended configuration. Based on this configuration, the manager decides whether it can communicate with the respective agent. Due to the extension with new objects (magnetic field sensor) and attributes, it cannot be assumed that other managers can understand the extended configuration. Therefore, the agent offers a standard configuration that only specifies objects and attributes defined in the X73-10441. In the case of managers not understanding the extended configuration, the agent may fall back on this default configuration.

For communication between the smartphone and the WAN device, HL7 v2.6 ORU messages constrained by IHE DEC PCD-01 were implemented. The message structure is oriented to the IHE PCD WCM, recommending a channel-wise transmission of waveform data instead of a metric-wise transmission. In fact, this is quite reasonable, as later analysis of data will always consider the data delivered by one channel in its entirety. Therefore, there is no need to separate the data into single metrics.

Instead of sending the binary data in ASCII format (NA), two alternatives were implemented: the data transmission as ED data type included in the HL7 message, and separate data transmission using the HL7 Reference Pointer. The ED data type is convenient for the continuous transmission of snapshot data, while the RP variant is preferable for transferring large amounts of data at a single point in time. Semantic interoperability is achieved using the elaborated domain information model and nomenclature of the X73 standard family.

In a specified mapping procedure, the containment tree and its X73 terminology is mapped to HL7 messages. Assuming the information model is known, the system component receiving the HL7 message is able to interpret data extracted from HL7 syntax and to further process the information.

A resulting HL7 message implementing the ED data type will be explained hereinafter (cf. Table 3 [Tab. 3]). Each HL7 message used to transmit measured motion data starts with the message meta-data and patient information. This first part of the message is rather static as only the current timestamp and a message identifier have to be adapted for the MSH segment. The patient identifier must be inserted into the PID segment for each new message. The patient’s name is not transmitted within the message for security reasons and is instead indicated by the name type code ‘N’ denoting an unspecified name. The first OBR segment contains, amongst others, the start and end times of the observation time interval and therefore represents the header for all following observations. It is obligatory for the first OBX to indicate whether a time synchronization protocol is in place for the application hosting device. As proposed by Continua, the enumeration of OBX segments then starts with those related to the devices. Consequently, the second OBX segment represents the MDS device. Since no suitable device profile could be found, a private term has been added to the MDC nomenclature, denoting the profile for the custom PTC sensor unit device. Another attribute of the MDS object is the sensor position, which is transmitted within the third OBX segment. Here again, a private term has to be created and the encoded position is included in OBX-5 of the third OBX segment.

After having specified device related information, the actual measurement data can be indicated (from row 5). Due to the possibility of varying sampling rates for the different channels, the channel objects are transmitted in pairs of two OBX segments, one containing the sample rate, the other containing the measurement values for a channel. The OBX segments contain the measurement values in the OBX-5 field in the form of the HL7 data type ED in Table 3 [Tab. 3], abbreviated by ellipsis points. The field OBX-6 which follows, additionally indicates the unit of the data. While a corresponding nomenclature term exists for the units and the sampling rate parameter, new private terms have to be created for the channel names.

Although Continua and IHE propose the use of SOAP-based web services, both SOAP-based as well as REST-based variants have been considered for transporting messages. After an evaluation with regards to system-relevant criteria such as the use in connection with mobile devices, the transmission of binary data, security, scalability and performance, REST-based web services have been chosen for transmitting HL7 messages to the server.

A prototype of the described system architecture was implemented. In order to ensure communication through the specified standard, a X73 capable software component was implemented on the sensor unit. The mobile application prototype was developed for Android Version 2.2 (API 8) and higher, and was tested on various Android devices. In addition to the respective counterpart for X73 compliant communication, the mobile application includes software modules for the generation of HL7 messages and for the consumption of web services offered by the server.

The open source HL7 application programming interface (HAPI) [20] was used on the smartphone to generate HL7 messages. To deploy HAPI in a mobile application, all unnecessary libraries were removed in order to keep the application as small as possible. The HL7 messages for data upload contain static structures to a considerable extent, thus a message template was created. During the message generation process, this template was loaded and filled with the required data and adapted where necessary by means of HAPI. After the HL7 message was created, it was forwarded to the REST client which then consume the corresponding web service on the server. The implementation of a REST client on Android was based on a design pattern proposed in a presentation which the Google developer Virgil Dobjanschi held at the official Google I/O Developer Conference in 2010 [21].

Focusing on the WAN part, the first step was to set up the server environment. A virtual machine, hosting a Linux operating system, was established in the domain of the University of Applied Sciences Ulm to act as the server. A relational database was required on the server. It was decided to use the open source fork of MySQL, denoted as MariaDB, for this purpose. For the implementation of the server logic the Java Enterprise Edition (Java EE) was selected. For this purpose, a JBoss Java EE application server was set up.

The web service interface was implemented by creating resource objects that could be accessed via RESTful web services. The Jersey framework was used to declare resource objects as accessible via REST calls. With the help of Jersey annotations, GET, PUT, POST and DELETE methods could be implemented for a resource object. The Hibernate framework for object relational mapping was used to implement the database access.

Firstly, security features were implemented. To provide transport security, SSL in server authentication mode was deployed. Hash-based Message Authentication Code (HMAC) was used to achieve not only client authentication, but also message integrity. OAuth was implemented to establish an authorization concept as it especially fits the presetting of a REST based architecture.

It was then possible to record motion data, and transmit it in a standards compliant way from the sensor system to the central server where data were extracted and stored in a database. The prototypic system was used successfully in a first field test in 5 local Parkinson support groups with 81 test persons. Performance and load tests have not been conducted yet.

Goal of this work was the efficient transmission of motion data compliant to Continua und IHE guidelines. According to current literature research, a 9-axis motion sensor unit was not utilized in combination with X73 standards before. However, a concept was elaborated and implemented in a proof-of-concept prototype.

The 9-axis inertial sensor unit is not fully covered by the X73 device specializations. In contrast to Herrlich et al. [8], who abandoned the use of the Continua guidelines due to the incompatibility with their medical device, the extensibility of the specifications were utilized to make them convenient for the developed sensor system. Extensions were made for the magnetic field sensor and specific attributes, like sensor body position. As a result, all features of the sensor unit can be used. But extending and adapting a standard contradicts the idea of interoperability. Due to the extended configuration, third-party smartphone applications and health information systems will not be able to interpret the information. A fallback configuration for third-party systems that fully complies with the standards and only communicates the information destined for the respective device profile was therefore implemented. This standard configuration would be sufficient for some of the projects described in related work only using the accelerometer and/or the angular rate sensor.

It is remarkable that many projects have only implemented one interface of the Continua E2E Reference Architecture. When it comes to specific requirements, in many cases (for example [10]) proprietary protocols are preferred, as they enable simple and fast solutions. However, the implementation of standards brings several advantages, such as cost reduction and extensibility of systems [22]. For example, in the motion tracking context, the patients would need to document their medication intake for later correlation to symptoms. The implementation of the X73 standards family enables the easy integration of a medication monitor which reduces the burden of documentation by hand.

Although achieving interoperability was one goal, adaptions were made to the message format and transport protocol of the WAN interface. These were reasonable and showed an alternative way of transmitting motion data or waveform data to the WAN device. By introducing the HL7 RP data type, the total data volume per day could be reduced by 66%. Data were contained as an instance of the channel level which is common in medical monitoring.

The decision to use REST-based web services instead of the SOAP-based web services prescribed by the Continua Guidelines, represents another arguable point. When using RESTful web services, the system does not fully comply with the proposals of Continua and IHE. If this is the goal, the SOAP-based variant must be used. Nevertheless, it has been shown that the guidelines of Continua and IHE can also be realized by RESTful web services. Therefore, when comparing both alternatives, the question arises, why Continua does not leave it up to the developer, and instead concentrate only on one alternative. The non-mentioning of REST-based web service may be justified by the fact that the propagation and acceptance of REST-based web services is still in progress. Additionally, HL7 V2.6 message have in general rarely been deployed with the RESTful web service until now. The focus on SOAP-based web services may also have arisen from security concerns. Continua considered confidentiality and integrity both in transport and message level as well as authentication and authorization to be obligatorily implemented in their guidelines. It has been shown that these security features can also be introduced to a REST-based system. When it comes to e.g. reliability, REST-based web services do not offer any framework like SOAP-based web services. However, reliable messaging can be implemented by taking advantage of the idempotence that is inherent to the HTTP methods GET, PUT and DELETE if implemented correctly. As the server is part of a secure university network, security features were not the focus of this work and were only implemented partly.

To sum up, RESTful web services are thus just as eligible as SOAP for communication in the medical domain. In fact, they might be even better suited for mobile platforms due to their lightweight architecture. Urbauer et al. [23] and Lasierra et al. [24] come to a similar conclusion. This is supported further by the fact that the HL7 International Group is currently developing a next generation standard framework that incorporates the latest web standards. This framework, called Fast Health Interoperable Resources (FHIR) [25], is based on a RESTful API and will be suitable for use in a wide variety of contexts including mobile phones, cloud communications, EHR-based data sharing and server communication in large institutional healthcare providers. With an organization like the HL7 International Group currently developing new standards based on REST principles, it can be observed that the advantages of a REST-based system have also been recognized for the scope of communicating medical data. It can also be noted that, with regard to security, the FHIR framework prescribes almost the same security requirements as were elaborated for this telemonitoring system.

The research presented focused on finding and elaborating concepts for the communication of continuously measured sensor data. The communication of further data such as answered questions, diary entries and drug intake has yet to be specified. Here, the conceived REST-based system already provided the required infrastructure and could be easily adapted and extended. Furthermore, the telemonitoring system could be enhanced by providing a link to an electronic health record or hospital information system over the xHRN interface e.g. for accessing patient master data.

In order to achieve a fully interoperable system, the communication of motion data must be included in the guidelines of IHE and Continua Health Alliance. Continua has called for the submission of new use cases. A submission of the project’s use case seems meaningful, as motion tracking can be used for the monitoring of movement disorders appearing not only in Parkinson’s disease but also in multiple sclerosis or restless legs syndrome. Other use cases for 9-axis inertial sensors are gait analysis, rehabilitation [4] or physiotherapy. Literature shows that 9-axis sensors are increasingly utilized by many other systems. Once the sensor is included in the guidelines, standard compliance should be validated using tools provided by the Continua (e.g. the Continua-Enabling Software Library also used by [11]).

Currently, the application server analyzes data and provides results and statistics on demand for the users. A further improvement could be realized by enabling the server to push messages directly to the mobile device without waiting for the patient to request information from the server. This way, the patient could be provided with current information about his/her health status and actively participate in the course of treatment. Here, Android provides Google Cloud Messaging technology, which would e.g. enable a physician to send a message or newly configured motor tasks to the mobile application of the patient at any time. Of course, the deployment of cloud communication may require an even stronger security concept.

In summary, a concept was elaborated and implemented that used extended standards for individual requirements. Motion data can be transmitted efficiently from the inertial sensor to the WAN device. Due to the adaptation that was required for the application of the X73 standard to communicate the data of the special sensor units and the deployment of RESTful web services, the elaborated concept does not fully comply with the proposals of Continua and IHE. The choice of deploying RESTful web services is a promising approach for medical systems. The work presented here is intended to promote the further development of interoperable medical devices and the work of the Continua Health Alliance.

The authors declare that they have no competing interests.

This work was supported by a grant from the Ministry of Science, Research and the Arts of Baden-Wuerttemberg (Az: 33–7533–7–11.6–10/2).