A standardized SOA for clinical data interchange in a cardiac telemonitoring environment.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JBHI.2014.2334372, IEEE Journal of Biomedical and Health Informatics

TITB-00662-2013

1

A standardized SOA for clinical data interchange in a cardiac telemonitoring environment R. Gazzarata, F. Vergari, T. Salmon Cinotti and M. Giacomini, Member, IEEE  Abstract — Care of chronic cardiac patients requires information interchange between patients’ homes, clinical environments and the Electronic Health Record (EHR). Standards are emerging to support clinical information collection, exchange and management and to overcome information fragmentation and actors delocalization. Heterogeneity of information sources at patients’ homes calls for open solutions to collect and accommodate multi-domain information, including environmental data. Based on the experience gained in a European Research Program, this paper presents an integrated and open approach for clinical data interchange in cardiac telemonitoring applications. This interchange is supported by the use of standards following the indications provided by the national authorities of the countries involved. Taking into account the requirements provided by the medical staff involved in the project the authors designed and implemented a prototypal middleware, based on a Service Oriented Architecture (SOA) approach, to give a structured and robust tool to CHF (Congestive Heart Failure) patients for their personalized telemonitoring. The middleware is represented by a Health Record Management Service (HRMS), whose interface is compliant to the HSSP (Healthcare Services Specification Project) RLUS (Retrieve, Locate and Update Service) standard (Level 0), which allows communication between the agents involved through the exchange of CDA R2 (Clinical Document Architecture Release 2) documents. Three performance tests were carried out and showed that the prototype completely fulfilled all requirements indicated by the medical staff, however certain aspects, such as authentication, security and scalability, should be deeply analyzed within a future engineering phase. Manuscript received November 22, 2013, revised March 24, 2014 and May 15, 2014; accepted June 20, 2014. This work was supported in part by CHIRON project of the European Joint Undertaking on Embedded Systems ARTEMIS which was co-funded by the EU and by the National Authorities (CHIRON: GA n. 100228). R. Gazzarata is with the Department of Informatics, Bioengineering, Robotics and System Engineering, University of Genoa, Via Opera Pia 13, 16145 Genoa, Italy (e-mail: [email protected]). F. Vergari is with the Department of Energy and Information (DEI) of the University of Bologna, and with ARCES, the Advanced Research Center on Electronic Systems for Information and Communication Technologies E. De Castro at the University of Bologna, Via Toffano 2, 40125 Bologna, Italy (e-mail: [email protected]). T. Salmon Cinotti is with the Department of Information Science and Engineering (DISI) of the University of Bologna and with ARCES, the Advanced Research Center on Electronic Systems for Information and Communication Technologies E. De Castro at the University of Bologna, Via Toffano 2, 40125 Bologna, Italy (e-mail: [email protected]). M. Giacomini is with the Department of Informatics, Bioengineering, Robotics and System Engineering and with the Center of Excellence for Biomedical Research, University of Genoa, Via Opera Pia 13, 16145 Genoa, Italy (corresponding author phone: +390103536546, fax: +390103532154, e-mail: [email protected]).

Index Terms—Interoperability, healthcare, telemedicine solution, electronic health record, Healthcare Services Specification Project

I. INTRODUCTION

T

echnological-scientific progress in the medical field is extending the population’s life expectancy all around the word with the consequence that the population is aging: in fact, in 1990 a 60 year old person had a life expectancy of 18 years and in 2011 this period increased to 20 years [1]. The occurrence of chronic diseases and multimorbidity is continuously increasing. Specifically, in 2008 58.5% of adult deaths between the ages of 30 and 70 years were caused by chronic noncommunicable diseases (NCD) [1]. In the USA, the amounts spent to treat chronic patient represent 75% of the total health costs [2]. This percentage is increasing, but the economic constraints (especially in case of sustained public health costs) will force health stakeholders to find more competitive approaches to treat these patients [3]. One possible solution is represented by the use of telecare systems whose main aim is to provide a hospital like level of medical assistance to chronic patients while maintaining them at home with the intensive use of ICT (Information and Communication Technologies) [4]. According to many reviews, the complete achievement of this goal has not yet been reached [5]–[7]. Previous studies indicated that one of the main problems of the acceptance of telemedicine for chronic patients was the lack of integration with the public health information system [8], [9]. Moreover, Parè et al. stated that “more studies are still required in this area to build an in-depth body of knowledge related to its clinical effects, cost effectiveness, impact on the utilization of health services, and acceptance by health care providers”. In particular, in the treatment of chronic illnesses, the main focus should be put on integration of the tele-homecare approach with the overall patient care process [3]. Lastly, van den Berg et al. stated that none of the considered studies (even the most recent ones) were integrated with the regular patient care process; the cause of this was indicated as the lack of data transfer abilities of the proposed solutions [7]. Taking into account these issues, the Artemis agency [10] co-financed the European project CHIRON (Cyclic and person-centric Health management: Integrated appRoach for hOme, mobile and clinical eNvironments) [11] from 2010 to 2013. The main target of the project was to propose an integrated framework for person-centric health management throughout the complete care cycle. During the development of the project two pilot sites were set up to telemonitor seriously ill

2168-2194 (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.


TITB-00662-2013

2

cardiac patients (affected by Congestive Heart Failure (CHF)). One of the project deliverables was a middleware to integrate the data collected in the patients’ home, summarized in an Electronic Health Record (EHR), and the hospital environment. The project had a large participation of technical partners (research centers, universities and private companies) as well as some medical partners. The advice of the physicians involved was important in obtaining both the necessary medical knowledge and in defining the feature of the final product in order to enhance the probability of acceptance by the medical community [12]–[15]. Another secondary aim of the CHIRON project was to facilitate the co-existence of the EHR standards (Health Level Seven Version 3 ( HL7 v3) / International Organization for Standardization (ISO) Clinical Document Architecture Release 2 (CDA R2) [16], European Committee for Standardization (CEN) / ISO 13606 [17] and openEHR [18], [19]) in a real application environment. The authors focused their activity on this target. Based on the experience gained in the project, the paper presents an integrated and open approach for clinical data interchange in cardiac telemonitoring applications supporting the most popular emerging standards. In this project two different approaches were used to meet the requirements of the CEN/ISO 13606: HL7 CDA R2 and openEHR [20].The proposed solution is based on the Service Oriented Architecture (SOA) and was designed and developed within the CHIRON project. This paper is organized as follows: the next section enlightens some of the critical aspects of SOA-based middleware systems proposed in literature to connect the actors involved in telemonitoring solutions and presents the SOA approach integrated with the indications provided by the Healthcare Service Specification Project (HSSP) standards as a possible solution to overcome these issues. Section III presents the materials treated in this paper: standardized medical reports, exchanged among the involved actors, the requirements provided by the medical staff and the home platform adopted. In section IV, the authors describe and justify the technical approach to middleware design and implementation. In section V, the authors present the prototypal middleware developed and a performance test. Lastly, a Discussion section concludes the paper. II. RELATED WORK In recent years, one of the design and technology strategies adopted in telemonitoring solutions to implement clinical information systems middleware was the SOA approach [21]–[24]. The main reason for the diffusion of the SOA paradigm was that it proposed a highly feasible approach to promote the easy integration and alignment of new and existing solutions into a cohesive architecture [25]. A SOA is formed by a set of network-accessible and platform neutral software services, which can encapsulate the functionality and information of existing applications and provides them through well-defined interfaces [26], [27]. This aspect makes the SOA suitable for the healthcare scenario where the reuse of software

is a primary evaluation criterion considered by healthcare organizations [28], [29]. The pure SOA approach is not sufficient to guarantee interoperability. It is necessary to have a standard message format to map medical and administrative information which can be only efficiently interchanged through standardized functions and protocols [30]. This explains why a lack of integration with the public health information system is still present even in SOA-based tele-monitoring systems [30]. Taking into account these considerations, in 2005 the HSSP was formed by the HL7 International and the Object Management Group (OMG) in order to define health industry SOA standards which promote interoperability [30]. The main HSSP objective was to use the SOA approach to support interoperability between applications and distributed and heterogeneous devices, which belong to independent socio-health system organizations [30]. The aim of each HSSP project was the standardization of a specific service, which was related to a functional socio-health domain, as a generic service [30]. Kawamoto et al. recognized chronic disease management as a possible task for the “Healthcare Specific Task Service” category of the SOA services classified by the HSSP [30]. III. MATERIALS The core idea behind the proposed middleware may apply to tele-monitoring of patients affected by any chronic disease. In fact, the management of chronic diseases is always characterized by the extensive use of historical data which allows medical staff to provide personalized treatment for patients throughout the course of illness[31]–[34]. Within the CHIRON project the authors implemented this planning idea to allow the telemonitoring of chronic patients affected by Congestive Heart Failure (CHF) class III [35], who had already been hospitalized. Knowledge of the specific class of the patients monitored was essential in identifying the parameters to be considered. For CHF, an extensive search of medical literature, performed by the medical staff involved in the project, yielded over 60 parameters, with differing significance values, considered as potential risk factors [36]. Among these, some were characterized by low time variability, i.e. those referring to demographic or pharmacological aspects, while others were highly dynamic, e.g. certain clinical and biological parameters, and therefore had to be frequently monitored. In detail, medical staff indicated the following requirements: --Vital and environmental signs must be collected three times per day, made available to the Intensive Care Unit (ICU) for occasional evaluation within an hour, and processed with specific algorithms by the platform hosted in the patient’s home in order to identify critical events. --In case of critical events, the platform must generate an alarm to inform the ICU (e.g. sms, email, phone call). --The medical staff, informed of the critical situation, must have access to the complete clinical history of the patient within 15 minutes.



TITB-00662-2013

3

The devices and sensors used in this solution, with the corresponding vital and environmental signs observed, are listed in Table 1. These sets of devices and sensors represent a typical example of a Body-Home integrated Sensor Network. TABLE I LIST OF DEVICES WITH THE CORRESPONDING MEASURED PARAMETERS Device

Parameters

body scale blood pressure monitor pulse oximeter wearable vital signal monitor Wireless Environmental Sensor Network

body weight diastolic, systolic, mean blood pressure and heart rate saturation of peripheral oxygen, heart rate heart rate, breathing rate, skin temperature, activity index, posture environmental temperature, humidity, dust concentration, pollution

In the proposed CHIRON prototype, the home solution was based on an open platform, named Smart-M3 [37], [56]. Smart-M3 decouples producers and consumers who do not need to know each other’s protocol and connectivity solution, as they exchange information through the platform itself [37]. While providing a publish/subscribe mechanism and semantic representation of information, Smart-M3 is an interoperability enabler for sensors, controllers, user interfaces, reasoners and data communication interfaces as well. The platform integrates different communication technologies, domain specific connectivity standards and legacy devices with simple adapters and abstraction layers [38]. Home automation network standards like Konnex (KNX - ISO/IEC 14543) [39] and Modbus [40] or health specific connectivity standards like Continua [41] can be integrated to build multi-domain Smart-M3 centered ecosystems according to the Smart Space based design paradigm which is agnostic with respect to domain specific connectivity solutions [37]. Smart M3 was used to integrate different partner contributions and to develop the home prototype as orchestration of different legacy and prototypal CHIRON sensors, CHIRON business-logic software and third-party solutions [38], [42], including the HL7 dispatcher to integrate the home platform with the proposed middleware. The medical report can be an additional useful tool to provide a personalized care management solution [43]. In this study, the patients were already hospitalized, therefore the first type of medical report available was the discharge summary document. In many cases, it was provided in CDA R2 format, so clinical information was well-defined, machine readable, and could therefore be automatically extracted to configure the algorithms that manage the alarm system in the home telemonitoring platform, which manages the Body-Home integrated Sensors Network, as will be described in the following sections. IV. METHODS In order to satisfy the requirements indicated by the physicians, the middleware had to connect three agents involved in the telemonitoring of CHF patients: the home platform, the

EHR and the ICU. Within the CHIRON project, the partners decided to adopt the CDA R2 standard for the information interchange between these agents and the formalism proposed by openEHR for the storage of health information within the EHR. In order to provide a robust communication channel between the three distinct agents, which would not be able to lose the recorded data, the authors decided to integrate a temporary database which was emptied when the EHR was updated. For the design of the middleware, the authors took into account the indication provided by the HSSP in order to facilitate the integration of the telemonitoring system proposed by the CHIRON project with external applications, devices and services; in particular, they decided to implement a Health Record Management Service (HRMS) to connect the agents through the exchange of observations contained within the medical report. This service belongs to the “Healthcare Specific Task Service” category of the SOA services indicated by the HSSP [30], and the corresponding HSSP standard the Retrieve, Locate and Update Services (RLUS) Release 1, was adopted [44]. The RLUS provides a set of web service interfaces through which health information resources can be accessed and managed, independent of their nature, by information systems within and between healthcare organizations [45]. The RLUS standard, as all HSSP products, is distributed through the HL7 Service Functional Model (SFM) and the OMG Service Technical Model (STM) [46]. The SFM provides a service interface specification at a functional level while the STM specifies the literal technical requirements of the service [46]. SFM for RLUS is available at [45], STM for RLUS is available at [47] and some templates of WSDL (Web Service Description Language) and XSD (XML Schema Definition) files are available in [48]. In the RLUS, the nature of the health information resource is managed through the semantic signifier concept [45]. A semantic signifier is defined as “the manifestation of a computable information model, tagged with a name and version and capable of being used and enforced by reference” [30]. This approach allows abstraction of the RLUS capabilities from different resource types and data structures which can therefore be managed in a flexible and standardized manner [45]. In the proposed solution, the authors decided to adopt the CDA R2 as a semantic signifier because it provided a generic and flexible structure which could be used to map the clinical content of different types of medical reports [49]. In order to constrain the CDA R2 specification for each use case, an implementation guide (CDA R2 IG) could be provided [49]. A CDA R2 IG was initially produced by HL7 International and then each country-specific HL7 Affiliate Organization was authorized to edit a national IG version appropriate for the realm healthcare context [50]. At present, the HL7 Italian affiliate has not yet produced an Italian CDA R2 IG which can be adopted for the use case proposed in this paper, but it is working on the localization of two HL7 International CDA R2 IGs:



TITB-00662-2013

4

“Implementation Guide: CDA Release 2 – Care Record Summary Release 2 Discharge Summary” [51] and “Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD)” [52]. For this reason, the authors, who were participating (as HL7 Italy members) in this localization process, decided to focus the implementation on these Italian IG draft versions, taking into account each possible modification. Specifically, in this application, the content of the produced CDA R2 documents was limited to the header and the “Vital Signs” body section, in the case of both the discharge summarization note and the continuity of care document, as only these parts were interesting for the purpose of the project. The STM defines two levels of conformance to the RLUS standard, which depend on the state of service interfaces implementation [47]. The RLUS standard, Level L0, requires the implementation of the so called “RLUS Management and Query Interface” which provides all the capabilities needed to manage and access the health information resources mapped through the specific semantic signifier [47]. The compliance to RLUS Level L1 requires, in addition to compliance to RLUS Level L0, the implementation of all capabilities which allow dynamic meta data management, that is the definition and manipulation of RLUS semantic signifiers [47]. A “Minimum RLUS implementation”, that is compliance to RLUS Level L0 [47], was sufficient for the purpose of the proposed solution because the semantic signifier used was unique and therefore operations to define and manipulate it were not necessary. The functions provided by the RLUS Management and Query Interface are: Get(), List(), Locate(), Put(), Discard(), Describe() and Initialize() [47]. Table 2 presents only the functions needed by the reader to understand the proposed solution. The RLUS standard, as with all HSSP products, is explicitly an interface specification, not an implementation specification [45]. In fact, the RLUS can be adopted with different internal technical implementations which can be either a registry and

repository architecture or an integrated application which can be based, for example, on an XML database or a RIMBAA (RIM-based Application Architecture) [53] solution [45]. In this work, the authors decided to design and then implement a SQL (Structured Query Language) database based on a subset of HL7 v3 RIM (Reference Information Model) [54] in order to take advantage of the high query capability provided by SQL DBMSs (Database Management Systems) useful to respond to filter requests in the Get() capability. Finally, for implementation of the services, the authors adopted the Windows Communication Foundation (WCF) framework since it addressed the SOA needs, supported interoperability and integration and unified programming models [55]. V. RESULTS A. Proposed Solution Architecture The main result of this work was a standardized prototypal middleware which was able to support an architecture which aimed to give a structured and robust tool to CHF patients for their personalized telemonitoring. The middleware was formed by a HRMS, whose interface was compliant to the RLUS standard (Level 0). The HRMS allowed communication between the agents, which were involved in this complex patient treatment, through the exchange of CDA R2 documents. Fig. 1 shows this workflow in a schematic way. The authors would like to emphasize that the HRMS clients, described in this section, were implemented in order to develop a full prototypal solution within the CHIRON project. In a real applicative context, these agents could be replaced with any application which is able to create and read CDA R2 documents which fulfill the indications by the IGs adopted. The trigger event of the telemonitoring scenario is the discharge of the CHF patient from the hospital, or in the CHIRON scenario from the ICU; contextually the physician

TABLE 2 THE RLUS MANAGEMENT AND QUERY INTERFACE CAPABILITY NEEDED TO UNDERSTAND THE PROPOSED SOLUTION Capability Get()

Put()

Discard()

Aim To retrieve a single health information resource, mapped through a specific semantic signifier, which fulfills the specific query performed by the client. To store an instance of a logical record in the repository.

Input Parameters

Output Parameters

Instance of RLUSSearchStruct (a well-defined and machine readable data structure to describe a search based on filter criteria or examples and the name of the semantic signifier to retrieve).

Requested resource only if it exists and if it is unique. Instance of RLUSStatusCode (a structure to contain the code indicating whether the operation was successful or not and a corresponding message). Instance of RLUSWriteCommandEnum (a structure to contain an enumeration Instance of RLUSStatusCode (as indicating the action the service must perform: insert only, update only or defined in Get()). “upsert”. “Upsert” means that first the service has to check whether the Logical record identifier. resource already exists and then, if so, it executes an update, but if not, it executes an insert). Instance of RLUSPutRequestSrcStruct (a structure to contain the semantic signifier, which maps the logical record, and security, source, and network address context of the caller of the Discard() operation which is necessary to retrieve data to clean the RLUS and audit logs). Logical record mapped through a specific semantic signifier. To either physically or Instance of RLUSSearchStruct (as defined in Get()). Instance of RLUSStatusCode (as logically delete resources Instance of RLUSPutRequestSrcStruct (as defined in Put()). defined in Get()). from the repository.



TITB-00662-2013 draws up the discharge summarization note using the ICU application. Once it has been completed, the ICU application saves a copy of this CDA R2 document in the Hospital Information System (HIS) and sends another copy to the HRMS, using the Put() functionality (Arrow 1 – Fig. 1). Afterwards, the HRMS processes the CDA R2 document, stores only the information which is relevant for the purpose, i.e. the one contained in the header and in the “Vital Signs” section and it responds to the Put() request (Arrow 2 – Fig. 1). When the telemonitoring platform is installed, its client interacts with the HRMS through the Get() capability to download the CDA R2 document which contains only the header and “Vital Signs” section of the discharge summarization note (Arrow 3, 4 – Fig. 1), sets the alarms and calls the Discard() functionality to delete this clinical document from the temporary database (Arrow 5, 6 – Fig. 1). When the actual telemonitoring is working a consultation note (i.e. a continuity of care document), which contains measured values enclosed within the “Vital Signs” section, is synchronically generated and sent to the HRMS, by calling the Put() capability (Arrow 7 – Fig. 1); in the same way as described above, the HRMS processes and responds to this request (Arrow 8 – Fig. 1). In order to connect the HRMS to the EHR of the specific patient, an Instance Location Service (ILS) was also included in the architecture. One of the operations provided by the ILS, was UpdateEHR(); when this capability is invoked by a client, the ILS calls the HRMS Get() functionality to obtain a CDA R2 document which contains all the observations which are stored

5 in the temporary database for the specific patient (Arrow 9, 10 – Fig. 1). Then, it interacts with the specific EHR to update its content with the observed values (Arrow 11, 12 – Fig. 1) and, by calling the HRMS Discard() functionality, it deletes all the clinical documents whose observations are already stored in the EHR from the temporary database (Arrow 13, 14 – Fig. 1). When the ICU medical staff want to check the evolution of the patient’s status, the ICU client calls the HRMS Get() operation (Arrow 15 – Fig. 1). The HRMS processes this request, interacts with both the temporary database and the EHR through the ILS (Arrow 16, 17, 18, 19 – Fig. 1), and produces and returns a CDA R2 documents which fulfills the specific query performed by the physician (Arrow 20 – Fig. 1). When one or more vital or environmental signs go out of range, as indicated by the medical staff in the discharge summarization note, the home platform creates a particular continuity of care document, a transfer summarization note and sends it as an input parameter of the HRMS Put() capability (Arrow 21, 22 – Fig. 1). In addition, the home platform sends an informative sms to the medical staff (Arrow 23 – Fig. 1) who can call the HRMS Get() capability to obtain this specific CDA R2 document which contains the parameter values which generated the alarm in the “Vital Signs” section. To perform this request, the medical staff can use the ICU client. In the following description, the authors first provide implementation details of the HRMS and then focus attention on the content of the data structures exchanged in the workflow described above. Finally, the numeric results relating to the performance test of the communication between the home

Fig. 1. The workflow supported by the middleware: black arrows represent the request (continuous line) and respond (dashed line) of Get() capability, dark gray arrows represent the request (continuous line) and respond (dotted line) of Put() capability and light gray arrows represent the request (continuous line) and respond (dashed line) of Discard() capability. Double gray arrows represent the connection between the ILS and the EHR supported by API over HTTP. Thick black arrow represents the sms which the home platform sends to the ICU.



TITB-00662-2013

Header Validation

Valid: the value of each element attribute is both compliant with the indication provided by the IG used and correct for the use case.

Are id, code, No effectiveTime, recordTarget, author, confidentialityCode, custodian valid? Yes

The HRMS extracts the patient id (recordTarget) and the clinical document type (code)

Body Validation

Health Record Management Service The HRMS is formed by a WCF service, located on a server (Single Processor Quad Core Xeon 3470, 2.93Ghz, 6GB Random Access Memory (RAM), 64 Bit Windows Server 2008 R2 Standard Edition), whose interface represents a “Minimum RLUS implementation”. The definition of this interface is provided to the client through a WSDL file while the structures of the object (i.e. the semantic signifier) and datatypes, which are used to call the service functionality, are supplied through different XSD files. In this prototype, in order to manage access to the health information resources, the authors decided to adopt an authorization mechanism based on certificate exchanges between the HRMS and the clients. When the HRMS receives a CDA R2 document as an input parameter of the Put() functionality from an authorized client, it extracts and stores the enclosed observations in the temporary database following the algorithm shown in Fig. 2. When the HRMS receives a Get() request from an authorized client, it first processes the RLUSSearchStruct input parameter and interacts with the temporary database performing the corresponding SQL query. In this prototype the authors focused the implementation of searches based on filter criteria. In this specific implementation, it is important to highlight that the temporary database only stored the observations until the ILS updated the EHR. For this reason, the HRMS must consider the identity of the client which has called the Get() functionality. In fact, if the client is the ILS or the home platform, it must only consider the observations which are stored in the temporary database. Otherwise, if the client is the ICU application, it must consider the observations which are stored in the EHR which are accessible to the HRMS through the ILS. Anyway, the HRMS creates a new CDA R2 document which contains all the observations which fulfill the specific query performed by the client and returns it to the client with a RLUSStatusCode instance, which indicates that the operation was successful. If the HRMS does not find any observation, it returns a RLUSStatusCode instance, which indicates that the operation was unsuccessful. Finally, when the HRMS receives a Discard() request from an authorized client, it processes the RLUSSearchStruct input parameter and interacts with the temporary data base with the same mechanism described for the Get() capability. Also, in this case, the HRMS must consider the identity of the client that has called the Get() functionality. In fact, to allow elimination of the observations, it must correspond to the one indicated by the client, which previously stored the CDA R2 document, within the RLUSPutRequestSrcStruct instance input parameter of Put() capability. If this condition is verified, the HRMS deletes

The HRMS receives a Put(CDA R2 document) request

Are all observations valid and is their number equal to the number of items in the narrative block?

No

The HRMS returns RLUSStatusCode.success = False

Yes

«Update» Are all observations alredy stored in the temporary database?

What is the value of RLUSWriteCommand Enum input paramiter?

No

«Insert only»

Yes

Information Storage

platform and the HRMS are shown. This test was also useful in indicating which agent should invoke the ILS to update the EHR. As relates to the transfer methods, the arrows 11, 12, 17, 18 use Application Programming Interface (API) calls over HyperText Transfer Protocol over Secure Socket Layer (HTTPS), arrow 23 is a sms over Global System for Mobile Communications (GSM) or higher, all other arrows use Simple Object Access Protocol (SOAP) over HTTPS.

6

What is «Insert only» or «Upset» the value of RLUSWriteCommand Enum input paramiter? «Updatey» or «Upset» The HRMS stores in the database the content of RLUSPutRequestSrcStruct input paramiter and the relevant information for each observation

The HRMS returns RLUSStatusCode.success = True

Relevant information: clinical document type, patient id, code and codesystem of the observed parameter, the measured value and unit of measuremen and referenceRange, if present.

Fig. 2. The algorithm adopted by the HRMS to process the CDA R2 document received.



TITB-00662-2013 the observations which fulfill the client query and returns a RLUSStatusCode instance, which indicates that the operation was successful. In the other case, or if there is no observation to delete, the HRMS returns an error as in the case of Get() and Put() capabilities.

7 situation and to send a consultation note when the patient acquired a new measurement [56]. The home platform was developed from a previous study by the authors [57], [58].

Intensive Care Unit Discharge Client The ICU Discharge Client consists of a web application which was implemented to simulate the hospital client, which was used to write the discharge summarization note when the patient is discharged from the hospital and is going to be telemonitored. It provides the medical staff with a form to automatically create a simple CDA R2 document formed by the header and a section related to “Vital Signs” which contains the last observed values during the patient’s hospitalization and the expected ranges of values compatible with the actual status of the patient. When the physician saves this clinical document, the ICU client automatically sends it to the HRMS as an input parameter of the Put() functionality. In addition, it indicates that the HRMS must “insert only” this medical report (RLUSWriteCommandEnum input parameter) and that the specific patient’s home platform will be the caller of the Discard() operation (input parameter RLUSPutRequestSrcStruct). Home Platform The home platform system was responsible for collecting and processing heterogeneous physiological and environmental sensor data from different devices. The discharge summarization note of the specific patient, which could be obtained through the HRMS Get() functionality, was automatically elaborated to configure the alarm algorithms. In this way, each instance of the algorithm was personalized for the specific patient. Fig. 3 shows an example of the search based on filter criteria which the home platform can use as part of the RLUSSearchStruct input parameter of this capability. The same example could also be adopted as an input parameter of the Discard() operation to delete this CDA R2 document from the temporary database. Physically the home solution, which was adopted within the CHIRON project, consisted of a gateway (i.e. a low cost PC) connected to the internet and environmental and physiological sensors (reported in Table 1) communicating via wireless technology (i.e. ZigBee and Bluetooth). The gateway hosted different local services cooperating via the Smart-M3 platform: one of these services was the HL7 dispatcher which collected all vital and environmental parameters related to the patient from Smart-M3, mapped them in the corresponding observations and created a CDA R2 document which was sent to the HRMS as an input parameter of the Put () capability. The action which the HRMS had to perform was indicated as “insert only” (RLUSWriteCommandEnum input parameter), while the caller of the Discard() capability was the ILS (RLUSPutRequestSrcStruct input parameter). In order to satisfy the requirements indicated by medical staff, in the prototype, the HL7 dispatcher service was configured at run-time to automatically send a transfer summarization note and an sms when the home platform identified a critical

Fig. 3. Example of RLUSSearchCriteria instance adopted by home platform to get the discharge summarization note (corresponding LOINC code 18842-5) of the specific patient.

Instance Locate Service From the technical point of view, this service is a WCF service, located on the same server as mentioned above, which was developed to manage the connection between the HRMS and the EHRs of telemonitored patients. Among all the capabilities which the ILS provides, two are important to correctly understand the workflow: UpdateEHR() and Get(). The UpdateEHR operation allowed the EHR to be fed with the observations produced by the home platform for a specific patient, which were then sent to the HRMS as a consultation note and stored in the temporary database. This capability had one input parameter which was the patient id, mapped through the patientRole CDA R2 class; the patient id and the type of the CDA R2 document (i.e. consultation note) were used to create the RLUSSearchStruct instance of the HRMS Get() capability through a search, based on filter criteria, similar to the one



TITB-00662-2013

8

shown in Fig. 3. After that the ILS completed the EHR update, it used the same RLUSSearchStruct instance to delete from the temporary database all the observations, stored in the EHR, through the Discard() capability [20]. The signature of the ILS Get() function is identical to that of the HRMS Get() function. It was developed to allow the HRMS to obtain a CDA R2 document which contained the observations stored in the EHR and fulfilled the search performed by the client who requested the HRMS Get() capability. Intensive Care Unit Document Visualization Client This client is a web application which was developed to provide the medical staff with a tool to check the evolution of the patient’s health status by visualizing a CDA R2 document. The tool allowed physicians to indicate a few simple filter criteria on some CDA R2 document fields (e.g. effectiveTime or code elements of observations) which the client then automatically inserted into the RLUSSearchStruct input parameter of HRMS Get() capability. B. Performance test Performance tests were carried out in order to investigate the quality of the proposed prototype. In particular, a stress test was executed to evaluate system responsiveness under simulated workloads. All tests described below were performed by one or more personal computers (PCs) (Intel Xeon 1.86GHz, 4 GB RAM, 64 bit Windows 8) running simulating home platform clients providing set of observed values described in Table 1. Each PC was connected to a 100 Mbps wired LAN (Local Area Network). At the beginning, the authors adopted an asynchronous EHR update policy; therefore, the ILS UpdateEHR() capability was invoked by an internal component of the EHR used in the project. The main aim of the first test was to check the fulfillment of medical staff requirements. Specifically: no recorded data may be lost and all collected data have to be stored in the temporary database within 15 minutes. The analysis was performed by sending 10000 CDA R2 documents, each containing 13 observations, which corresponded to all available measured parameters, from a single platform. These clinical documents were sent in groups of 100 CDA R2 documents at a time and the mean time to send each group of documents to the HRMS was measured. At the beginning, the database was empty and at the end of the experiment 130000 observations were stored. In order to calculate this mean value, the time interval was considered between the first Put() request issued by the client and the 100th acknowledgment received. The results of this experiment showed that the mean time required to send a CDA R2 document rose linearly from 0.40 s for the 1st group to 4.39 s for the 100th group with an increase of 997% (Fig. 4). Most likely this trend was due to the increasing size of the temporary database and consequent increase of its read-access latency. In fact the HRMS had to query the database to check if the observations had been already stored before executing the RLUSWriteCommandEnum input parameter of the Put() request.

Fig. 4. Experiment 1 results.

In order to verify this hypothesis, the same experiment was repeated with a synchronous EHR update. In this case, the home platform, emptied the temporary database by calling the UpdateEHR() functionality provided by the ILS and waited for the corresponding acknowledgement before sending a new group of 100 clinical documents (Fig. 5). Fig. 6 shows the results. The mean time to send a CDA R2 document, within a group of 100, is included in a range from 0.34 s to 0.41s with a mean value of 0.35 s and a standard deviation of 0.02 s. This experiment demonstrates that the number of observations stored within the database affects the HRMS response time. For this reason, the authors decided to adopt a synchronous EHR update policy to test system performance on a simulated telemonitoring scenario with 14 platforms concurrently sending clinical documents to the HRMS. In this case, 14 PCs (equipped as described above) were simultaneously used. In this experiment, each platform sent 1000 CDA R2 documents for a total of 14000 clinical documents. The mean transmission time was measured on groups of 10 documents each. Fig. 7 shows the results of experiment 3. The mean time to send a CDA R2 document from 14 home platforms concurrently, calculated in groups of 10, ranged from 0.26 s to 1.09 s. with a mean value of 0.38 s and a standard deviation of 0.10 s. In order to evaluate the significance of the differences between these mean values (experiment 2 versus experiment 3), a t-test was run on these datasets, providing the fulfillment of its prerequisites. In particular, the normal distribution of the sets was assessed (Table 3 summarizes the parameters that demonstrate the normality of the two distributions). The t-test result (p < 0.05) showed that the mean time to send a clinical document in experiment 3 was significantly higher than the time used in experiment 2, for a limited amount (9%). TABLE 3 T TEST Parameter Arithmetic mean Standard Deviation Median Skewness

Experiment 2

Experiment 3

0.35 0.02 0.35 1.96

0.38 0.10 0.38 1.94



TITB-00662-2013

9

Fig. 5. Sequence diagram of experiment 2 and 3.

VI. DISCUSSION

Fig. 6. Experiment 2 results.

Fig. 7. Experiment3 results.

This paper presents the middleware of the CHIRON project whose aims were to allow standardized communication between the agents involved in the telemonitoring of CHF class III patients: the home platform, the hospital environment (ICU) and a standardized EHR. Within the project a prototype of this middleware was implemented, focusing on the features which could facilitate integration with the external e-health world. The experiment tests showed that this prototype completely fulfilled all requirements indicated by the medical staff. Nevertheless, these standardization characteristics allow the middleware to ideally communicate with any hospital / home application with the capability to produce and read a discharge summarization note and CCD document. The only requirement is that these CDA R2 documents must be compliant to the same CDA R2 Implementation Guides adopted in the proposed solution. This aspect, allows the middleware to also be adopted in other medical domains since disease specificity only influenced the selection of sensors and devices, the data processing algorithms and the timing constrains. The prototype described above, was implemented within the CHIRON project, in which the authentication and the security aspects were decided to be handled by the HTTPS technology and involved certificates. This aspect should be deeply analyzed within a possible future engineering phase when more



TITB-00662-2013

10

sophisticated technologies such as ESB (Enterprise Service Bus) should be adopted. This architectural choice is also suggested by HSSP guidelines [59]. For this future work a straightforward widening of the application field is also envisioned. In detail, other CDA R2 IGs should be used such as the “Implementation Guide: CDA R2 - Personal Healthcare Monitoring Report” [60], which could not be adopted in this prototypal implementation because there was no suitable Italian localization available yet. Another issue which should be addressed is represented by the relationship between horizontal standards like SOA and vertical standards like CDA R2 IGs; this aspect will cause a certain increase in software development load; in fact, the absence of automatic tools to translate the constraints described in the IGs will be replaced with an additional implementation activity [61]. A similar implementation workload increase will be required if the middleware has to take into account the information provided by IHE (Integrating the Healthcare Enterprise) profiles whose compatibility is assured by the RLUS standard [45], [47]. In order to adopt the proposed solution within a real medical application, scalability issues should also be considered. At prototypal level, the performance measured with less than twenty home platforms may be satisfactory, as the one simulated by the authors, was sufficient. Nevertheless, the results of the stress tests carried out provided that a drastic increase in telemonitored patients will require coordinated and load-balanced servers with storage tools giving better performance than a single relational DBMS. In a future release closer to the real deployment, the high performance of the storage capabilities of the temporary databases will allow the maintenance of an asynchronous EHR update.

[4]

ACKNOWLEDGMENT

[20]

The authors would like to thank: the CHIRON partners (in particular Francesco Morandi, Enrico Poncini, Chiara Petrioli, Gaia Maselli, Angelo Capossele, Andrea Vitaletti, Luca Filipponi, Simone Naso, Viola Parodi, Paolo Emilio Puddu, Jan-Marc Verlinden, Kevin Keene and Carlos Cavero Barca for the collaboration in research and implementation activities and Silvio Bonfiglio and Letizia Gabrielli for their coordination activities); Massimo Gazzarata for the medical collaboration and support; Jennifer McDermott for the English revision and Maria Eugenia Monteverde and Valeria Pupella for editorial help.

[5] [6]

[7]

[8]

[9]

[10] [11]

[12]

[13]

[14]

[15]

[16]

[17]

[18] [19]

[21]

[22]

[23]

[24]

REFERENCES [1] [2]

[3]

World Health Organization (WHO), World Health Statistics 2013. WHO Library Cataloguing-in-Publication Data, 2013. Centers for Disease Control and Prevention (2014, May). The Power to Prevent, The Call to Control: At A Glance 2009. [Online]. Available: http://www.cdc.gov/chronicdisease/resources/publications/AAG/chronic .htm G. Paré, M. Jaana, and C. Sicotte, “Systematic review of home telemonitoring for chronic diseases: the evidence base,” J. Am. Med. Informatics Assoc., vol. 14, no. 3, pp. 269–277, 2007.

[25]

[26] [27]

F. Mair and P. Whitten, “Systematic review of studies of patient satisfaction with telemedicine,” Bmj, vol. 320, no. 7248, pp. 1517–1520, 2000. C. Ruggiero, R. Sacile, and M. Giacomini, “Home telecare,” J. Telemed. Telecare, vol. 5, no. 1, pp. 11–17, 1999. E. Seto, “Cost comparison between telemonitoring and usual care of heart failure: a systematic review,” Telemed. e-Health, vol. 14, no. 7, pp. 679–686, 2008. N. van den Berg, M. Schumann, K. Kraft, and W. Hoffmann, “Telemedicine and telecare for older patients—a systematic review,” Maturitas, vol. 73, no. 2, pp. 94-114, 2012. T. L. Finch, F. S. Mair, and C. R. May, “Teledermatology in the UK: lessons in service innovation,” Br. J. Dermatol., vol. 156, no. 3, pp. 521–527, 2007. C. R. May et al., “Integrating telecare for chronic disease management in the community: what needs to be done?,” BMC Health Serv. Res., vol. 11, no. 1, p. 131, 2011. ARTEMIS Agency. [Online]. Available: http://www.artemis-ju.eu/. Cyclic and person-centric Health management: Integrated appRoach for hOme, mobile and clinical eNvironments (CHIRON) Project. [Online]. Available: http://www.chiron-project.eu/. S. Robinson, K. Stroetmann, and V. Stroetmann, “Tele-homecare for chronically ill patients: Improved outcomes and new developments,” J Inf Technol Heal. Care, vol. 2, pp. 251–262, 2004. L. B. Young, P. S. Chan, and P. Cram, “Staff Acceptance of Tele-ICU CoverageA Systematic Review,” CHEST J., vol. 139, no. 2, pp. 279–288, 2011. Y. Kowitlawakul, “The technology acceptance model: predicting nurses’ intention to use telemedicine technology (eicu),” Comput. Informatics Nurs., vol. 29, no. 7, pp. 411–418, 2011. J. Moeckli, P. Cram, C. Cunningham, and H. S. Reisinger, “Staff acceptance of a telemedicine intensive care unit program: A qualitative study,” J. Crit. Care, vol. 28, no. 6, pp. 890–901, 2013. Health Level 7 version 3 (HL7 v3) Clinical Document Architecture Release 2 (CDA R2). [Online]. Available: http://www.hl7.org/implement/standards/product_brief.cfm?product_id =7. European Committee for Standardization (CEN) / International Organization for Standardization (ISO) 13606. [Online]. Available: http://www.en13606.org/the-ceniso-en13606-standard. openEHR. [Online]. Available: http://www.openehr.org/. O. Kilic and A. Dogac, “Achieving clinical statement interoperability using R-MIM and archetype-based semantic transformations,” Inf. Technol. Biomed. IEEE Trans., vol. 13, no. 4, pp. 467–477, 2009. R. Gazzarata et al., “The Integration of e-health into the Clinical Workflow–Electronic Health Record and Standardization Efforts,” in Impact Analysis of Solutions for Chronic Disease Prevention and Management, Springer, 2012, pp. 107–115. J. M. Corchado, J. Bajo, D. I. Tapia, and A. Abraham, “Using heterogeneous wireless sensor networks in a telemonitoring system for healthcare,” Inf. Technol. Biomed. IEEE Trans., vol. 14, no. 2, pp. 234–240, 2010. F.-C. Chang, “A Framework for Prototyping Telecare Applications,” Journal of Information Hiding and Multimedia Signal Processing, vol. 5, no. 1, pp. 61-71, 2014. D. G. Katehakis, S. G. Sfakianakis, G. Kavlentakis, D. N. Anthoulakis, and M. Tsiknakis, “Delivering a lifelong integrated electronic health record based on a service oriented architecture,” Inf. Technol. Biomed. IEEE Trans., vol. 11, no. 6, pp. 639–650, 2007. V. G. Koutkias, I. Chouvarda, A. Triantafyllidis, A. Malousi, G. D. Giaglis, and N. Maglaveras, “A personalized framework for medication treatment management in chronic care,” Inf. Technol. Biomed. IEEE Trans., vol. 14, no. 2, pp. 464–472, 2010. E. Vasilescu and S. K. Mun, “Service oriented architecture (SOA) implications for large scale distributed health care enterprises,” in Distributed Diagnosis and Home Healthcare, 2006. D2H2. 1st Transdisciplinary Conference on, 2006, pp. 91–94. Y. V Natis, Service-oriented architecture scenario. Gartner Research, Stamford, 2003. K. Kawamoto and D. F. Lobach, “Proposal for fulfilling strategic objectives of the US roadmap for national action on decision support



TITB-00662-2013

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39] [40] [41] [42]

[43]

[44]

[45]

[46]

[47] [48] [49]

through a service-oriented architecture leveraging HL7 services,” J. Am. Med. Informatics Assoc., vol. 14, no. 2, pp. 146–155, 2007. M. W. Bridges, “SOA in healthcare, Sharing system resources while enhancing interoperability within and between healthcare organizations with service-oriented architecture.,” Health Manag. Technol., vol. 28, no. 6, pp. 6–8, 2007. J. Mykkänen, A. Riekkinen, M. Sormunen, H. Karhunen, and P. Laitinen, “Designing web services in health information systems: From process to application level,” Int. J. Med. Inform., vol. 76, no. 2, pp. 89–95, 2007. K. Kawamoto, A. Honey, and K. Rubin, “The HL7-OMG Healthcare Services Specification Project: motivation, methodology, and deliverables for enabling a semantically interoperable service-oriented architecture for healthcare,” J. Am. Med. Informatics Assoc., vol. 16, no. 6, pp. 874–881, 2009. S. A. Hunt et al., “ACC/AHA guidelines for the evaluation and management of chronic heart failure in the adult: executive summary” J. Am. Coll. Cardiol., vol. 38, no. 7, pp. 2101–2113, 2001. M. P. Dubé et al., “Guidelines for the evaluation and management of dyslipidemia in human immunodeficiency virus (HIV)-infected adults receiving antiretroviral therapy: recommendations of the HIV Medicine Association of the Infectious Disease Society of America and the Adult,” Clin. Infect. Dis., vol. 37, no. 5, pp. 613–627, 2003. S. Schutte-Rodin, L. Broch, D. Buysse, C. Dorsey, and M. Sateia, “Clinical guideline for the evaluation and management of chronic insomnia in adults,” J. Clin. sleep Med. JCSM Off. Publ. Am. Acad. Sleep Med., vol. 4, no. 5, p. 487, 2008. P. Fraccaro et al., “The Ligurian Human Immunodeficiency Virus Clinical Network: A Web Tool to Manage Patients With Human Immunodeficiency Virus in Primary Care and Multicenter Clinical Trials,” Med. 2.0, vol. 2, no. 2, p. e5, 2013. New York Heart Association (NYHA), Nomenclature and criteria for diagnosis of diseases of the heart and great vessels. Little, Brown Medical Division, 1979. M. Luštrek, B. Cvetković, M. Bordone, E. Soudah, C. Cavero, J. M. Rodríguez, A. Moreno, A. Brasaola, and P. E. Puddu, “Supporting clinical professionals in decision-making for patients with chronic diseases,” in 15th International Multiconference Information Society - IS 2012, Ljubljana, 2012, pp. 126-129. J. Honkola, H. Laine, R. Brown, and O. Tyrkko, “Smart-M3 information sharing platform,” in Computers and Communications (ISCC), 2010 IEEE Symposium on, 2010, pp. 1041–1046. L. Filipponi, A. Vitaletti, G. Landi, V. Memeo, G. Laura, and P. Pucci, “Smart city: An event driven architecture for monitoring public spaces with heterogeneous sensors,” in Sensor Technologies and Applications (SENSORCOMM), 2010 Fourth International Conference on, 2010, pp. 281–286. Konnex. [Online]. Available: http://www.knx.org/knx-en/index.php Modbus. [Online]. Available: http://www.modbus.org/ Continua. [Online]. Available: http://www.continuaalliance.org/ F. Morandi, L. Roffia, A. D’Elia, F. Vergari, and T. S. Cinotti, “RedSib: a Smart-M3 semantic information broker implementation,” in Proceedings of the 12th Conference of Open Innovations Association FRUCT, Oulu, Finland, Nov, 2012, pp. 86–98. Z. Yoediono and R. Snyderman, “Proposal for a new health record to support personalized, predictive, preventative and participatory medicine,” Personalized Medicine, vol. 5, no. 1, pp. 47-54, 2008. HL7 Version 3 Standard: Retrieve, Locate, and Update Service (RLUS) Release 1. [Online]. Available: http://www.hl7.org/implement/standards/product_brief.cfm?product_id =89 S. Lotti, J. Koisch, A. P. Honey, S. Robinson, and K. Kawamoto, Service Functional Model Specification Retrieve, Locate and Update Service (RLUS), Release 1. HL7, 2012. R. Hamm, A. Estelrich, N. Canu, F. Oemig, and S. Nachimuthu, HL7 Common Terminology Services, Release 2: Service Functional Model Specification, Normative Release. HL7, 2013. OMG, Retrieve, Locate, and Update Service (RLUS) Specification, Version 1.0.1. OMG, 2011. Documents Associated With RLUS, Version 1.0.1. [Online]. Available: http://www.omg.org/spec/RLUS/1.0.1/ R. H. Dolin et al., “HL7 clinical document architecture, release 2,” J. Am. Med. Informatics Assoc., vol. 13, no. 1, pp. 30–39, 2006.

11 [50] HL7 (2014, May). HL7 Reﬁnement, Constraint and Localization, Release 2. [Online]. Available: http://www.hl7.org/v3ballot/html/infrastructure/conformance/conforman ce.htm [51] L. Alschuler et al., Implementation Guide for CDA Release 2.0 Care Record Summary Release 2 Discharge Summary, Draft Standard for Trial Use. HL7, 2009. [52] R. H. Dolin et al., HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD). HL7, 2007. [53] HL7 RIM (Reference Information Model) based application architecture (RIMBAA) working group. [Online]. Available: http://wiki.hl7.org/index.php?title=RIMBAA [54] HL7 Reference Information Model (RIM). [Online]. Available: http://www.hl7.org/implement/standards/rim.cfm [55] W. Zhang and G. Cheng, “A service-oriented distributed framework-WCF,” in Web Information Systems and Mining, 2009. WISM 2009. International Conference on, 2009, pp. 302–305. [56] F. Vergari et al., “A Standardized Middleware as the core of a Telemonitoring European Project,” Stud. Health Technol. Inform., vol. 180, p. 497, 2012. [57] F. Vergari et al., “A smart space application to dynamically relate medical and environmental information,” in Proceedings of the Conference on Design, Automation and Test in Europe, 2010, pp. 1542–1547. [58] F. Vergari, T. S. Cinotti, A. D’Elia, L. Roffia, G. Zamagni, and C. Lamberti, “An integrated framework to achieve interoperability in person-centric health management,” Int. J. Telemed. Appl., vol. 2011, p. 5, 2011. [59] HL7, OMG, The Practical Guide to SOA in Healthcare. HL7, OMG, 2008. [60] L. Alschuler et al., HL7 Implementation Guide for CDA R2 - Personal Healthcare Monitoring Report. HL7, 2010. [61] J. Mykkänen and M. Tuomainen, “Balancing between Local Requirements, Interoperability Standards, and SOA principles‐Case eBooking of Health Services,” Finnish J. eHealth eWelfare, vol. 4, no. 1, pp. 10–19, 2012.

Roberta Gazzarata was born in Savona, Italy, on June 4th 1985. She graduated in biomedical engineering in 2007 and received a master’s degree in bioengineering in 2010 from the University of Genoa, Italy. She received her Ph.D. in bioengineering in 2014 from the University of Genoa. At present, she is a post-doctorate researcher at the Nano-biotechnology and Medical Informatics Laboratory of the Department of Informatics, Bioengineering, Robotics and System Engineering of the University of Genoa. Her research interests include medical informatics with special reference to format and vocabulary standards. She is author of one journal paper in press and some conference papers on this subject. Dr. Gazzarata received the Joachim W Dudeck Award in 2013 for the best paper presented at the International HL7 Interoperability Conference by a young researcher (less than 35 years of age) in health informatics for the paper: R. Gazzarata and M. Giacomini “Advanced Service Oriented Architecture (SOA) for the reuse of clinical data to enhance the collaboration between actors involved in the treatment of chronic and/or infectious diseases”.



TITB-00662-2013 Fabio Vergari was born in Rimini, Italy, on February 22nd 1982. He graduated in electronic engineering in 2004 and received a master’s degree in electronic systems for biomedical applications in 2007 from the University of Bologna, Italy. He received his Ph.D. in bioengineering in 2011 from the University of Bologna. Since 2011 he has been a post-doctorate researcher at the University of Bologna, doing research on embedded systems and semantic interoperability in the healthcare domain. Dr. Fabio Vergari received the second best poster presentation Award at the 1st IEEE EMBS Summer School on Emerging Technologies and Applications in Telemedicine in Smolenice in 2013.

Tullio Salmon Cinotti was born in Bologna, Italy, on May 7th, 1950 and graduated in electrical engineering at the University of Bologna in 1974. He is currently an Associate Professor (1987) at the School of Engineering and Architecture of the University of Bologna, where he is in charge of courses on computer architecture, logic design and interoperability of embedded systems for undergraduate and master students in electronics, telecommunications, automation and computer engineering. He has a long standing experience on joint research with primary Italian and International academic, research and industrial institutions. He is co-author of papers written with researchers from Intel Labs, Nokia Research, Siemens Corporate Technology, Telecom Italia Lab, VTT, Polytechnic of Milano, University of Kent. His research interest is focused on embedded systems and on semantics based data distribution architectures for multi-domain environment-driven ecosystems, including tele-homecare ecosystems. Prof. Salmon Cinotti currently leads a research group on semantic architectures at ARCES Labs (University of Bologna). He has led in the past and is currently leading the University of Bologna participation in European research initiatives focused on interoperability in the areas of open cultural heritage, smart environments and electric mobility. He is a member of the ARTEMIS-IA SRA workgroup

12 His research interests include medical informatics with special reference to application of standards in medical data treatment, medical knowledge based systems and to the development of data bases of importance in medicine and biology; microbial classification methods based on artificial neural networks and studies on antibiotic-resistance; the study of biological systems by modeling, data and signal analysis. He has been involved in more than 20 projects financed by EU since III framework; he has published more 60 papers in international referred journals over the past 20 years and about 350 published works. He teaches Biomedical Engineering and Bioengineering courses of study and some Medical Specialization Courses for Doctors. Prof. Giacomini is member of: IEEE - EMBS, Center of Excellence for Biomedical Research – University of Genoa (CEBR), HL7 Italy Board, Associazione Italiana d’ Informatica Medica – European Federation for Medical Informatics (AIIM-EFMI). He was associate editor of the IEEE T-BME from 2006-2012.

Mauro Giacomini (M’06) was born in Genoa, Italy, on April 17th 1963. He received a master’s degree in electronic engineering in 1987 from the University of Genoa, Genoa, Italy and a Ph.D. in bioengineering in 1993 from the Polytechnic of Milan, Italy. At present, he is an Aggregate Professor of bioengineering, in the Department of Informatics, Bioengineering, Robotics and System Engineering of the University of Genoa, Italy.


CIF (Crystallographic Information File): A Standard for Crystallographic Data Interchange.

XAFS Data Interchange: A single spectrum XAFS data file format.

Collimator Interchange System for Adaptive Cardiac Imaging in C-SPECT.

Rationale and design of a randomised clinical trial for an extended cardiac rehabilitation programme using telemonitoring: the TeleCaRe study.

A Standardized Reference Data Set for Vertebrate Taxon Name Resolution.

Developing a standardized healthcare cost data warehouse.

Cardiac Pacing - Is Telemonitoring Now Essential?

A novel telemonitoring device for improving diabetes control: protocol and results from a randomized clinical trial.

GRDR® Common Data Elements: A leading force for standardized data collection.

Electronic Data Interchange in medical care: an evaluation study.

Geocoding health data with Geographic Information Systems: a pilot study in northeast Italy for developing a standardized data-acquiring format.

In heart failure, automatic implant-based telemonitoring reduced a composite of cardiac events and mortality.

Does a standardized preoperative algorithm of clinical data improve outcomes in patients with ovarian cancer? A quality improvement project.

A novel multimodal tool for telemonitoring patients with COPD.

A multivariate spatial mixture model for areal data: examining regional differences in standardized test scores.

Data for a common clinical dilemma.

Building blocks for a clinical imaging informatics environment.

Cardiac rhythm management devices in a magnetic resonance environment.

APPLYING A SPATIOTEMPORAL MODEL FOR LONGITUDINAL CARDIAC IMAGING DATA.

PhenStat: A Tool Kit for Standardized Analysis of High Throughput Phenotypic Data.

Telemonitoring for patients with COPD.

How "typical" is a stutterer's stuttering in a clinical environment?

TRAPLINE: a standardized and automated pipeline for RNA sequencing data analysis, evaluation and annotation.

Invasive Pneumococcal Disease: Still Lots to Learn and a Need for Standardized Data Collection Instruments.