**3. Description of the platform**

knowledge). The health care process constitutes the heart of the health care organizations and, at the same time, it is made up of a clinical process and a resources management process, which is in charge of the logistic of the activity. Finally, the clinical process contains a clinical management process, a documentation and communication process and management of the quality of attention process. The documentation process is essential in the entire clinical act. It is that which allows the activity to be registered and able to communicate its results to other

activities, giving support to the health care continuity.

184 Telemedicine

**Figure 5.** Components of the organization of the attention process in accordance with EN 13940

In summary, in the following Table 1 the interoperability model defined for the PITES project

*2.2.3. Summary: the PITES interoperability framework*

can be specifically seen

Within the ambit of new services based on telemedicine, the generic overall scenario constitutes a heterogeneous and diverse ecosystem (Figure 6):


in an environment of convergence and the provision of services on an IP protocol. In this environment, the platforms act as elements of interrelation or an interface between them. The users already have more and more availability to network access technology and are familiarized with it.

**3.1. Conceptual entities model**

play a support or promoter role.

is wished to evaluate by means of the intervention.

to questionnaires on symptoms or actions.

the intervention. The patient entity is usually made up of:

task.

In the context of complex interventions it is fundamental to detect and make clear as soon as possible which agents participate actively in the intervention and its action and interaction mechanisms [29]. Once the said active agents are detected it facilitates the definition, design, development, implementation, and evaluation process of the intervention itself. In this sense, the Chronic Care Model (CCM) [51] [52] from the aspects that propose on the organization, interaction and identification of actors, contributes a good orientation to carry out this initial

PITES: Telemedicine and e-Health Innovation Platform

http://dx.doi.org/10.5772/57021

187

The CCM has been considered a general reference model on a global level that represents an organizational focus of the health care and tries to act as a guide for the activities aimed at improving the quality and the management of the chronic health care. It is the most studied model and that which has accumulated the most evidence, in more countries and health systems, illnesses and patient collectives, and which have derived the large part of the organizational models and models for the provision of chronic health care that have been proposed. The CCM establishes that in any chronic patient care scenario three contexts participate or interact: society (with its numerous resources and public and private policies), the health system, and the health professionals and the patients as direct actors of the health care. It is established that the improvements in the results of the chronic health care come to light by means of productive interactions between some informed and active patients and some prepared health teams together with a proactive attitude, which are promoted by the coordi‐ nation of additional resources at a social and health level. In this sense, the CCM specifies six categories of resources: the policies and social resources, the organization of the health care, help to self-management, the systems of provision of health care and help in the decision and the clinical information systems. Thus, it implicitly establishes a classification of entities from which it is possible to identify the agents participating in the interventions aimed at an improvement in the chronic health care. The patients and health professionals are always active agents of direct participation in any intervention, and the rest of the resources are agents or optionally active subsystems (they do not need to be present in all of the interventions) that

Taking the focus of the CCM as reference in the design process of the e-services, the PITES platform establishes a conceptual entities model that constitutes a user abstraction proposal, resources and their interactions. The model (Figure 7) is made up of six entities: patient entity, health care professional entity, external resource entity, health care information system entity, intervention management entity and technological platform entity. Each of the conceptual entities of the model represents a view or perspective of the health care provision model that

The patient entity encompasses the patient and all of the resources assigned to him or her for

**•** A patient protocol usually consists of periodically carrying out biometric measurements (arterial pressure, weight, pulse, ECG, spirometry, lipid profile, activity, etc.), and replies

**Figure 6.** Technological environment of the PITES platform

In this complex environment, the PITES platform is constituted as a stable public infrastructure technology, aimed at research groups with innovation nodes located in Health Centers, with the objective of making support possible to collaborative research and for the obtaining of evidence on new models for the health care provision based on ICT in scenarios related to chronic illness and dependency.

The design of the platform is sensitive to the complexity of the socio-health system and the difficulties and limitations that the implementation process of e-services has on the organiza‐ tions. Within the framework of experimental studies, the platform provides support to the first three phases of the aforementioned evaluation methodology of e-services, that is, authorize the resources and infrastructures necessary to deploy interventions with minimum imple‐ mentation necessities in the socio-health organizations.

The PITES platform is designed to support research projects; not health care activity in "clinical routine". As a research platform it responds to several requirements different from those platforms orientated to "clinical routine". These peculiarities manifest themselves, on the one hand, in a conceptual model of entities that constitute a proposal for a reduction in users, resources and their interactions in the design process of the e-services and, on the other hand, an architecture based on available technologies and those which are nowadays mature such as Web technologies, SOA (Service Oriented Architecture) and the "Cloud Computing" model.

#### **3.1. Conceptual entities model**

in an environment of convergence and the provision of services on an IP protocol. In this environment, the platforms act as elements of interrelation or an interface between them. The users already have more and more availability to network access technology and are

In this complex environment, the PITES platform is constituted as a stable public infrastructure technology, aimed at research groups with innovation nodes located in Health Centers, with the objective of making support possible to collaborative research and for the obtaining of evidence on new models for the health care provision based on ICT in scenarios related to

The design of the platform is sensitive to the complexity of the socio-health system and the difficulties and limitations that the implementation process of e-services has on the organiza‐ tions. Within the framework of experimental studies, the platform provides support to the first three phases of the aforementioned evaluation methodology of e-services, that is, authorize the resources and infrastructures necessary to deploy interventions with minimum imple‐

The PITES platform is designed to support research projects; not health care activity in "clinical routine". As a research platform it responds to several requirements different from those platforms orientated to "clinical routine". These peculiarities manifest themselves, on the one hand, in a conceptual model of entities that constitute a proposal for a reduction in users, resources and their interactions in the design process of the e-services and, on the other hand, an architecture based on available technologies and those which are nowadays mature such as Web technologies, SOA (Service Oriented Architecture) and the "Cloud Computing" model.

familiarized with it.

186 Telemedicine

**Figure 6.** Technological environment of the PITES platform

mentation necessities in the socio-health organizations.

chronic illness and dependency.

In the context of complex interventions it is fundamental to detect and make clear as soon as possible which agents participate actively in the intervention and its action and interaction mechanisms [29]. Once the said active agents are detected it facilitates the definition, design, development, implementation, and evaluation process of the intervention itself. In this sense, the Chronic Care Model (CCM) [51] [52] from the aspects that propose on the organization, interaction and identification of actors, contributes a good orientation to carry out this initial task.

The CCM has been considered a general reference model on a global level that represents an organizational focus of the health care and tries to act as a guide for the activities aimed at improving the quality and the management of the chronic health care. It is the most studied model and that which has accumulated the most evidence, in more countries and health systems, illnesses and patient collectives, and which have derived the large part of the organizational models and models for the provision of chronic health care that have been proposed. The CCM establishes that in any chronic patient care scenario three contexts participate or interact: society (with its numerous resources and public and private policies), the health system, and the health professionals and the patients as direct actors of the health care. It is established that the improvements in the results of the chronic health care come to light by means of productive interactions between some informed and active patients and some prepared health teams together with a proactive attitude, which are promoted by the coordi‐ nation of additional resources at a social and health level. In this sense, the CCM specifies six categories of resources: the policies and social resources, the organization of the health care, help to self-management, the systems of provision of health care and help in the decision and the clinical information systems. Thus, it implicitly establishes a classification of entities from which it is possible to identify the agents participating in the interventions aimed at an improvement in the chronic health care. The patients and health professionals are always active agents of direct participation in any intervention, and the rest of the resources are agents or optionally active subsystems (they do not need to be present in all of the interventions) that play a support or promoter role.

Taking the focus of the CCM as reference in the design process of the e-services, the PITES platform establishes a conceptual entities model that constitutes a user abstraction proposal, resources and their interactions. The model (Figure 7) is made up of six entities: patient entity, health care professional entity, external resource entity, health care information system entity, intervention management entity and technological platform entity. Each of the conceptual entities of the model represents a view or perspective of the health care provision model that is wished to evaluate by means of the intervention.

The patient entity encompasses the patient and all of the resources assigned to him or her for the intervention. The patient entity is usually made up of:

**•** A patient protocol usually consists of periodically carrying out biometric measurements (arterial pressure, weight, pulse, ECG, spirometry, lipid profile, activity, etc.), and replies to questionnaires on symptoms or actions.

**•** Residential homes, in which there is the possibility of attending the patients collectively by means of shared equipment, for example, patients with oral anticoagulation therapy who share the INR monitor and the communications equipment. The interfaces with this type of external resource may be applications based on the Web, designed so that a person respon‐

PITES: Telemedicine and e-Health Innovation Platform

http://dx.doi.org/10.5772/57021

189

**•** Platforms for external monitoring that receive information of specific patient collectives, for example, a collective of patients with implantable cardioverter-defibrillator (ICD) moni‐ tored from a platform that authorizes the company providing the ICD. In these cases, the interface would be based on specific "middleware" that makes it possible to interoperate

The health care information system entity essentially represents the Electronic Clinical Records of the Patient and the perspective from the health information systems. The function that this entity contributes is that of making it possible to exchange clinical information on the said systems and the ECR essentially summarized clinical information generated by the patients and health professionals during the interventions. The interfaces with the ECR entities are based on "middleware" specific to interoperate with the said information systems in accord‐

The intervention management entity supports a series of roles and resources that are required to carry out the intervention and that are not available or cannot be carried out suitable either by the health system or the community. The services provided by this entity are of two kinds: **•** Support to the deployment of the intervention: it provides resources to make it possible to train the health professionals, patients, families; resources for the maintenance and man‐ agement of the equipment used; tools for the monitoring of the compliance with patient

**•** Support methodology of the experimental evaluation study: it provides resources for the support methodology of the clinical trials and experimental studies. For example, drawing up and management of the documentation (Case Report Forms), applications for the Electronic Data Capture, services for the centralized randomization, recompilation and

The Technological Platform Entity represents the ICT nucleus that supports the functional interfaces, the coordination of activities and finally the telematic infrastructure that require the interventions to be implemented during its evaluation. The services provided by the platform are provided mainly by means of the Internet, digital cellular networks or basic telephone

When it is desired to evaluate the health care provision model with the support of the platform, the steps to be followed are as follows: define the intervention that leads to the practice of the health care model and the experimental evaluation study (type of study, variables, measure‐ ment instruments, dimension of the study as regards the sample and duration of the inter‐ vention, etc.) and define and design the new e-service which will give support to the intervention. To carry out this second stage, the actors involved must be determined (direct

network; the architecture of the platform is described in the following section.

sible manages the patient collectives.

with the said external platform.

ance with regulations.

protocols, etc.

analysis of results, among others.

**Figure 7.** PITES conceptual entities


The health care professional entity represents the perspective of the health professionals and is made up of the series of tools and resources required to carry out the health care protocol established by the intervention. In general, it is applications adapted to the specific patient protocols by means of which the monitoring is carried out including help tools and function‐ alities that make an indirect communication possible with the patient (advice, warnings, etc.). These applications are usually accessible by means of the Internet with the appropriate access controls. The reply messages to the patients are sent by means of personalized services such as SMS, e-mail, interactive voice systems, etc.

The external resource entity represents any support resource additional to the intervention on the health or community environment. That is health centers, pharmacies, consultations, geriatric residencies, other platforms, etc. The function of this entity is usually to represent any infrastructure that acts as a resource shared between patients, because it supposes some type of logistic advantage (economical, location, etc.). They can act as external resources, for example:


The health care information system entity essentially represents the Electronic Clinical Records of the Patient and the perspective from the health information systems. The function that this entity contributes is that of making it possible to exchange clinical information on the said systems and the ECR essentially summarized clinical information generated by the patients and health professionals during the interventions. The interfaces with the ECR entities are based on "middleware" specific to interoperate with the said information systems in accord‐ ance with regulations.

The intervention management entity supports a series of roles and resources that are required to carry out the intervention and that are not available or cannot be carried out suitable either by the health system or the community. The services provided by this entity are of two kinds:

**•** Support to the deployment of the intervention: it provides resources to make it possible to train the health professionals, patients, families; resources for the maintenance and man‐ agement of the equipment used; tools for the monitoring of the compliance with patient protocols, etc.

**•** Some biomedical monitoring equipment for personal use (sphygmomanometer, pulse oximeter, scales, thermometer, etc.) or environmental monitoring, to carry out the meas‐

**•** Communications equipment to carry out the periodical sending of protocol information. The equipment must be suitable to interact with the interfaces authorized by the platform.

The health care professional entity represents the perspective of the health professionals and is made up of the series of tools and resources required to carry out the health care protocol established by the intervention. In general, it is applications adapted to the specific patient protocols by means of which the monitoring is carried out including help tools and function‐ alities that make an indirect communication possible with the patient (advice, warnings, etc.). These applications are usually accessible by means of the Internet with the appropriate access controls. The reply messages to the patients are sent by means of personalized services such

The external resource entity represents any support resource additional to the intervention on the health or community environment. That is health centers, pharmacies, consultations, geriatric residencies, other platforms, etc. The function of this entity is usually to represent any infrastructure that acts as a resource shared between patients, because it supposes some type of logistic advantage (economical, location, etc.). They can act as external resources, for

urements required by the patient protocol

**Figure 7.** PITES conceptual entities

188 Telemedicine

as SMS, e-mail, interactive voice systems, etc.

example:

**•** Support methodology of the experimental evaluation study: it provides resources for the support methodology of the clinical trials and experimental studies. For example, drawing up and management of the documentation (Case Report Forms), applications for the Electronic Data Capture, services for the centralized randomization, recompilation and analysis of results, among others.

The Technological Platform Entity represents the ICT nucleus that supports the functional interfaces, the coordination of activities and finally the telematic infrastructure that require the interventions to be implemented during its evaluation. The services provided by the platform are provided mainly by means of the Internet, digital cellular networks or basic telephone network; the architecture of the platform is described in the following section.

When it is desired to evaluate the health care provision model with the support of the platform, the steps to be followed are as follows: define the intervention that leads to the practice of the health care model and the experimental evaluation study (type of study, variables, measure‐ ment instruments, dimension of the study as regards the sample and duration of the inter‐ vention, etc.) and define and design the new e-service which will give support to the intervention. To carry out this second stage, the actors involved must be determined (direct and indirect); this datum will establish the entities of the conceptual model that participate. Below, from the perspective of each of the participating entities, we have to establish:

**•** Operative transparency in the access and location of the resources: the platform must deploy the services in such a way that they are perceived by the users as incorporated or integrated in the socio-health care. This requirement is of greater relevance during the evaluation phases on clinical effectiveness. In the said phases, the platform must not constitute an

PITES: Telemedicine and e-Health Innovation Platform

http://dx.doi.org/10.5772/57021

191

**•** Interoperability: capacity to interoperate with heterogeneous components, distributions, inherited, other platforms/devices. The interoperability is contemplated in a wide sense

**•** Robustness, safety, maintainability and high availability: just as in a clinical routine use, the platform must maintain operating production conditions in experimental studies whose interventions can be extended for months, even years, as well as having the capacity to

**•** Conformity with international regulations and developments based on "open-source" software: both as recommendations of the European interoperability framework and of the WHO for e-health [53]. Conformity with regulations is an essential element to have gener‐ alizable and interoperable solutions, as well as a promoter factor of the success in the implementations and a reduction in costs. Questions related to the regulation in the exchange of data (ECR), and the interoperability between platforms/devices must be

These requirements are currently completely reachable by means of available and mature

**•** The Web technologies as a series of services associated with the Internet for the provision

**•** The "Cloud Computing" model, as a paradigm for the provision of services and technologies through the Internet, which in collaborative research environments such as PITES, allows

**•** A basic Internet network infrastructure based on the current convergence of the ubiquitous

With the support of these technologies and from the requirements, the platform has been designed as an open system of distributed services on communications based on the IP protocol. Any e-service supported by the PITES platform adopts an architecture oriented to services (SOA) and design paradigms established on the web 2.0: weak connection between services, interfaces based on "web-services", "hybrid" web applications (mashups), etc. As additional priority directives, the developments on the PITES platform must be based on

**•** SOA as an architecture paradigm to implement open systems and distributed services

the platform to be able to act as a "hub" for the dynamic provision of services

"open-source" and obtaining conformity with international regulations.

The architecture of the platform is distributed on two levels (see Figure 8):

(syntactic and semantic level) and tied to the conformity with regulations.

element that commits the validity of the studies

support multiple interventions simultaneously

of e-services to users and interoperability support;

provision of services on IP networks.

attended to.

technologies such as:


Finally, the provision model establishes an organizational and functional framework to which the intervention and experimental evaluation study must be adapted, to be able to carry out a joint deployment which may be supported by the PITES technological platform, and therefore develop it in the context that establishes that of the evaluation methodology.

#### **3.2. Architecture**

As has already been said, the PITES platform is a platform for research, not a support to health care activity in "clinical routine". As a research platform, its design responds to some require‐ ments that are additional to those adopted by the platforms oriented to "clinical routine" and which condition architecture decisions.

The platforms oriented to "clinical routine" must provide greater attention to aspects such as scalability maintainability and availability. The research platforms, also:


Under these conditions, the requisites demanded by the PITES platform and which constitute the references for the design of its architecture, are as follows:


**•** Operative transparency in the access and location of the resources: the platform must deploy the services in such a way that they are perceived by the users as incorporated or integrated in the socio-health care. This requirement is of greater relevance during the evaluation phases on clinical effectiveness. In the said phases, the platform must not constitute an element that commits the validity of the studies

and indirect); this datum will establish the entities of the conceptual model that participate.

**•** the specifications of the interfaces, applications and services based on the roles that each

**•** the organization and management of the health care, the aspects of support to the decision

Finally, the provision model establishes an organizational and functional framework to which the intervention and experimental evaluation study must be adapted, to be able to carry out a joint deployment which may be supported by the PITES technological platform, and therefore

As has already been said, the PITES platform is a platform for research, not a support to health care activity in "clinical routine". As a research platform, its design responds to some require‐ ments that are additional to those adopted by the platforms oriented to "clinical routine" and

The platforms oriented to "clinical routine" must provide greater attention to aspects such as

**•** Must be capable of coexisting with the "clinical routine" platforms to make the mutual

Under these conditions, the requisites demanded by the PITES platform and which constitute

**•** Functionality independent of the technological infrastructure of the environment in which the e-services are going to be deployed: the platform must guarantee some homogeneous functional deployment conditions during the evaluation of the interventions, especially on

**•** Scalability: the platform must be capable of supporting from small pilot projects and concept trials, up to multi-centered interventions that involve hundreds of users (patients, profes‐

**•** Dynamism and flexibility: the platform must have the capacity for rapid adaptation and evolution, the incorporation of new functionalities and the reuse of components, incorpo‐

Below, from the perspective of each of the participating entities, we have to establish:

**•** the interactions with the patient as subject of the health care and their environment,

**•** the aspects related to responsibilities, flows and management of the information.

develop it in the context that establishes that of the evaluation methodology.

scalability maintainability and availability. The research platforms, also:

the references for the design of its architecture, are as follows:

ration of technological opportunities, etc.

**•** Must be conceived from their basis in order to change, evolve and interoperate; **•** Must contemplate intrinsically evaluation mechanisms in the widest sense, and

interaction possible together with the progressive implementation of e-services.

those that imply geographical dispersion so as to be more sensitive to this aspect

participant contributes in the health care process,

**•** the temporary aspects of the provision of health care,

and monitoring of the activity, and

which condition architecture decisions.

**3.2. Architecture**

190 Telemedicine

sionals, etc.).


These requirements are currently completely reachable by means of available and mature technologies such as:


With the support of these technologies and from the requirements, the platform has been designed as an open system of distributed services on communications based on the IP protocol. Any e-service supported by the PITES platform adopts an architecture oriented to services (SOA) and design paradigms established on the web 2.0: weak connection between services, interfaces based on "web-services", "hybrid" web applications (mashups), etc. As additional priority directives, the developments on the PITES platform must be based on "open-source" and obtaining conformity with international regulations.

The architecture of the platform is distributed on two levels (see Figure 8):

**•** the "front-end" of the platform, that encompasses the interaction mechanisms of the platform with the users of the system, that is, the interfaces of the entities (people or other platforms/services), and

From the point of view of the users to whom they are aimed, the support services and applications for the platform are of two types: those directed to the users-person, that is, patients, health professionals, health carers/caretakers or families and support staff for the experimental studies, and those directed to the users-machine, that is, to other platforms,

PITES: Telemedicine and e-Health Innovation Platform

http://dx.doi.org/10.5772/57021

193

The architecture adopted for the user-person applications follow a "mashup" model based on

**•** client application, in the "front-end" of the platform, based on different technologies: WWW, WAP, J2ME, SMS, VoiceXML, accessible from commercial devices such as PC, conventional or mobile telephones, "smartphones" (Android), IP telephones, etc. These applications are

**•** The "mashup" component also in the "front-end", whose function is the addition of information for the creation of enriched content destined for the client applications. These services interact with the providers of the content in the "front-end" and "back-end" by

**•** The providers of the content, made up of the "back-end" services of the platform correspond to the intervention in the "business layer" or services of the "application layer". They may

The services of the platform designed to interact with the user-machines are those directed at monitoring devices and external services platforms (health or non-health). They have a classic "middleware" architecture so as to eliminate heterogeneous points with the external entities, brought about by the manufacturer's or third-party software, networks or different commun‐ ity protocols. The "middleware" is implemented by means of "gateway" type services specific to each case. These "gateway" type services can be assimilated as new "application layer" services in the "back-end", so that in this way they are available to new services in the "business

The following example is proposed to illustrate the functioning of this architecture, consisting of the architecture required for a remote activity monitoring e-service of ICDs (Figure 9). Imagine that we want to evaluate the clinical effectiveness of a remote ICD monitoring service by means of an experimental study. The objective would be to meas‐ ure the possible improvement in the health results of a group of patients to whom this type of monitoring is carried out (intervention), as opposed to another group in which a conventional monitoring is based on hospital visits. We suppose that there is a remote monitoring platform deployed by the manufacturer of the ICD that gathers the informa‐ tion generated by these devices and stores it in its information system (ICD Monitoring Platform). The health professional needs to periodically analyze the activity generated by the ICDs in the patients of the intervention group and combine it with other clinical information through other means. As well as this, the health professional needs to be able to send messages to these patients to give them advice, warnings, etc. As the study is framed within a clinical trial, the health professional needs to be able to carry out a random assignment of the patients in an flexible and safe manner before being included in the study

services or monitoring devices.

located in the "front-end" of the platform

means of open interfaces based on Web services.

also be other services content providers located in the "front-end".

layer" or "front-end" applications and therefore for any e-service that requires it.

three components:

**•** the "back-end", which constitutes the heart of the platform in which the structure has been defined, integration, and interdependence of the internal components of the platform and those of the "front-end" components, that is, the support of the logic of the e-services that support the interventions

**Figure 8.** Architecture of the PITES technological platform

The "front-end" interfaces are based on applications, services and protocols based on Internet and digital cellular networks and commutated telephone networks. The platform, has a base services to support these types of intervention by means of content, server, Web SMS gateways, IVR system(Interactive Voice Response), TTS services (Text-to-speech), services ASR (Auto‐ matic Voice Recognition), streaming server managers, etc.

The design of the platform in "back-end" adopts an architecture oriented to services in two layers:


From the point of view of the users to whom they are aimed, the support services and applications for the platform are of two types: those directed to the users-person, that is, patients, health professionals, health carers/caretakers or families and support staff for the experimental studies, and those directed to the users-machine, that is, to other platforms, services or monitoring devices.

**•** the "front-end" of the platform, that encompasses the interaction mechanisms of the platform with the users of the system, that is, the interfaces of the entities (people or other

**•** the "back-end", which constitutes the heart of the platform in which the structure has been defined, integration, and interdependence of the internal components of the platform and those of the "front-end" components, that is, the support of the logic of the e-services that

The "front-end" interfaces are based on applications, services and protocols based on Internet and digital cellular networks and commutated telephone networks. The platform, has a base services to support these types of intervention by means of content, server, Web SMS gateways, IVR system(Interactive Voice Response), TTS services (Text-to-speech), services ASR (Auto‐

The design of the platform in "back-end" adopts an architecture oriented to services in two

**•** "Business layer", in which the functionalities/services specific to the support of the inter‐ ventions, the business logic of the applications and services directly linked to each inter‐

**•** "Application layer", where the additional services with functionalities of a special and specialized character and oriented to its use by the services of the "business layer" and of the "front-end" are located. The objective of this layer is to constitute an extendable, diverse and detached series of functionalities that give support to the e-services supported by the platform in the research projects. The provision of these services is transparent and with open interfaces based on "web-services" (SOAP and REST on HTTP/HTTPS protocols). These support services can be made public (beyond the PITES community) by moving the

vention and which implement the requirements proper to them are deployed

platforms/services), and

192 Telemedicine

support the interventions

**Figure 8.** Architecture of the PITES technological platform

access interface to the "front-end" layer.

layers:

matic Voice Recognition), streaming server managers, etc.

The architecture adopted for the user-person applications follow a "mashup" model based on three components:


The services of the platform designed to interact with the user-machines are those directed at monitoring devices and external services platforms (health or non-health). They have a classic "middleware" architecture so as to eliminate heterogeneous points with the external entities, brought about by the manufacturer's or third-party software, networks or different commun‐ ity protocols. The "middleware" is implemented by means of "gateway" type services specific to each case. These "gateway" type services can be assimilated as new "application layer" services in the "back-end", so that in this way they are available to new services in the "business layer" or "front-end" applications and therefore for any e-service that requires it.

The following example is proposed to illustrate the functioning of this architecture, consisting of the architecture required for a remote activity monitoring e-service of ICDs (Figure 9). Imagine that we want to evaluate the clinical effectiveness of a remote ICD monitoring service by means of an experimental study. The objective would be to meas‐ ure the possible improvement in the health results of a group of patients to whom this type of monitoring is carried out (intervention), as opposed to another group in which a conventional monitoring is based on hospital visits. We suppose that there is a remote monitoring platform deployed by the manufacturer of the ICD that gathers the informa‐ tion generated by these devices and stores it in its information system (ICD Monitoring Platform). The health professional needs to periodically analyze the activity generated by the ICDs in the patients of the intervention group and combine it with other clinical information through other means. As well as this, the health professional needs to be able to send messages to these patients to give them advice, warnings, etc. As the study is framed within a clinical trial, the health professional needs to be able to carry out a random assignment of the patients in an flexible and safe manner before being included in the study as well as guaranteeing an anonymity of the identification of the patients every time it is necessary to get access to their demographic information by searching the information system of the hospital. Finally the health professional has to periodically send a summa‐ ry of the clinical activity generated in the study to the ECR of the patients so that it does not become isolated in the platform that supports the intervention.

an interface based on the ISO EN 13606 regulation that standardizes access to this informa‐

PITES: Telemedicine and e-Health Innovation Platform

http://dx.doi.org/10.5772/57021

195

**•** a gateway service in the "application layer" of the "back-end" (EHR Gateway) which permits the sending of summaries of the clinical activity generated by the users during the intervention to the ECR of the organization. Once the clinical information is validated by the health professional, the gateway receives an extract in accordance with the a ISO-EN 13606 regulation by means of an interface based on Web services which contains the said information and which the "middleware" sends to the hospital information system through

**•** a service in the "business layer" of the "back-end" (Service Intervention) that established the operating logic of the intervention managed by means of data bases and processes

**•** a gateway service in the "application layer" of the "back-end" (Random Gateway) which permits access through an interface based on Web services to a centralized randomizing service making the robust distribution of the patients in the two established assignment

The application of the health professional has access to a specific service in the "business layer" (service intervention), to a specific service in the "front-end" (ICD gateway) and to four services oriented to general use within the "application layer" of the "back-end" by means of his or her "mashup" component. While the client application together with the "mashup" component´, the service located in the "business layer" and the gateway ICD, are specific to the intervention, the gateway services of the "application layer" are also resources accessible for any other intervention that supports the platform. As an additional element, it is evident that to carry out the implementation of the study, the minimum is to commit resources to be contributed

The SOA architecture of the PITES platform makes it possible for the services that are initially specified for an intervention to be able to be promoted to services of general use because of its interest, use, and functionality. The weak connection between the services through the Web services interfaces allows functionalities to be added or taken away with relative ease. Following the "cloud computing" paradigm, these services can be used and evolved for future experiments in the PITES community, even making them accessible to the global community. This possibility gives the platform a significant advantage in the promotion of collaborative research in this field as well as being able to put the progressive implementation strategies into practice so that the platform can act as a temporary support to platforms in "clinical routine".

The PITES platform has an autonomous functioning (without the need for operators) on a 24x7 regime. The platform is accessible through Internet by means of a redundant link and has the capacity to establish point-to-point VPN with other networks. In order to achieve this de‐ manding working regime, there is a robust telematic infrastructure available in many of its

tion.

the established protocol.

groups possible.

*3.2.1. Component hardware*

components (communications, storage).

aspects specific to the intervention

to the structure of the health organization.

**Figure 9.** Example of the ICD e-service monitoring architecture

Within the framework of the architecture of the PITES platform, for the health professional, a client application would be implemented based on the Web to which it would be accessed securely (access control and HTTPS protocol). This application (client application) would be managed by a "mashup", component in the "front-end" of the platform that provides it access to the different sources of distributed data:


an interface based on the ISO EN 13606 regulation that standardizes access to this informa‐ tion.


The application of the health professional has access to a specific service in the "business layer" (service intervention), to a specific service in the "front-end" (ICD gateway) and to four services oriented to general use within the "application layer" of the "back-end" by means of his or her "mashup" component. While the client application together with the "mashup" component´, the service located in the "business layer" and the gateway ICD, are specific to the intervention, the gateway services of the "application layer" are also resources accessible for any other intervention that supports the platform. As an additional element, it is evident that to carry out the implementation of the study, the minimum is to commit resources to be contributed to the structure of the health organization.

The SOA architecture of the PITES platform makes it possible for the services that are initially specified for an intervention to be able to be promoted to services of general use because of its interest, use, and functionality. The weak connection between the services through the Web services interfaces allows functionalities to be added or taken away with relative ease. Following the "cloud computing" paradigm, these services can be used and evolved for future experiments in the PITES community, even making them accessible to the global community. This possibility gives the platform a significant advantage in the promotion of collaborative research in this field as well as being able to put the progressive implementation strategies into practice so that the platform can act as a temporary support to platforms in "clinical routine".

#### *3.2.1. Component hardware*

as well as guaranteeing an anonymity of the identification of the patients every time it is necessary to get access to their demographic information by searching the information system of the hospital. Finally the health professional has to periodically send a summa‐ ry of the clinical activity generated in the study to the ECR of the patients so that it does

Within the framework of the architecture of the PITES platform, for the health professional, a client application would be implemented based on the Web to which it would be accessed securely (access control and HTTPS protocol). This application (client application) would be managed by a "mashup", component in the "front-end" of the platform that provides it access

**•** a gateway service at the "front-end" based on "middleware" (Gateway ICD) which has the capacity to access an external monitoring ICD platform in such a way that from the client application client, the health professional can obtain information on the ICD activity of the

**•** a gateway service in the "application layer" of the "back-end" (SMS Gateway) which permits the sending of SMS messages. This gateway service consists of a "middleware" which

**•** a gateway service in the "application layer" of the "back-end" (Demog Gateway) which permits access to the demographic information of the patients located in the information system of its organization. On the one hand, the "middleware" accesses the said system by means of a proprietary protocol and, on the other hand, as regards the platform, it authorizes

manages the transactions with the SMS Center of the mobile telephone provider

not become isolated in the platform that supports the intervention.

194 Telemedicine

**Figure 9.** Example of the ICD e-service monitoring architecture

to the different sources of distributed data:

patients of the intervention group

The PITES platform has an autonomous functioning (without the need for operators) on a 24x7 regime. The platform is accessible through Internet by means of a redundant link and has the capacity to establish point-to-point VPN with other networks. In order to achieve this de‐ manding working regime, there is a robust telematic infrastructure available in many of its components (communications, storage).

The platform consists at the physical level of a segmented Internet-accessible network including: 9 physical and virtual servers (Xen) on IBM xSeries equipment over Linux OS (Suse Linux Enterprise); SAN/NAS (IBM N3600) redundant storage networks; backup library systems (TSM and IBM System Storage TS3200 Tape Library).

Another limitation of SMS messages is the nominal limitation in the total number of characters that can be included in each message, and which is fixed at 160. This length is very limiting in the majority of notifications from the doctor to the patient. It is also impractical for the doctor to send consecutive messages to the patient referring to the same matter (one of them might not arrive or arrive in the wrong order, etc.). However, there is the technical possibility of generating messages that are longer than usual ( "long SMS" calls) and which are segmented at the origin and later reassembled by the patient's mobile telephone in a way transparent to the user, and therefore permitting the sending of arbitrarily long messages. This functionality

PITES: Telemedicine and e-Health Innovation Platform

http://dx.doi.org/10.5772/57021

197

Functionally, access to the SMS messages server is carried out by means of the HTTP/ SOAP1.1/1.2. "web-services" interface. In each request to send, the following is indicated: addressee of the message, text of the message, need for confirmation of delivery, period of validity and preferred time period for sending the message (or immediate delivery). Once the request is accepted a univocal identifier is generated with the service applicant and the sending procedure commences with an adjustment of the parameters of the message (establishment of the output queue, internal register, etc). The SMS service is in charge of sending the message through one of the available GSM modems. From the moment of sending the message to the corresponding SMS Center, the progress of the SMS is monitored through to the reception of the corresponding DLR. Before the arrival of each DLR message, the SMS messages server analyzes its content and notifies the state to the corresponding service that requested its

By means of a widely available mobile service, this service authorizes, by means of an open interface, a way of indirect communication between health professionals and patients with a high level of security (delivery security and range of validity), and personalization (flexibility in the size of the message and the establishment of the preferred period of time for delivery). Randomizing service: telematic service accessible through the Internet that implements support to the randomizing process of clinical trials in a centralized way. The service deploys

**•** Complete management of the randomizing process by the promoter of the clinical trial **•** Randomizing support in different modalities: simple, by block, stratified, centralized and

**•** Control of transactions to guarantee the integrity for the applicants of the assignation

The service establishes three levels of privilege (overall administrator, project administrator,

**•** The "overall administrator" user (level 1), has the capacity to create new projects and administer the functioning of the overall service; each project corresponds to a clinical trial.

sending in such a way that the state of the messages can be known at all times.

**•** Simultaneous support to randomizing in multiple studies

**•** Assignation lists of up to 6 groups with the capacity for self-replication

**•** Generation statistics of the randomizing progress upon request

is supported by the SMS service of the platform.

the following functionalities:

blind

project user):

As basic support for e-services the platform provides a number of different general services: WWW service (Apache), DBMS (MySQL, PostgreSQL), applications managers (Tomcat), content managers (Drupal, LifeRay), "e-learning" server (Moodle), VoiceXML/IVR (VXI\*/ Asterisk) service, TTS/ASR (Verbio) engines.

The platform includes security elements at different levels: control access (physical and telematic) policies, (storage and communications) redundancy and monitoring tools (Nagios/ Cacti).

#### **3.3. Services**

The specific services currently provided by the platform include:

Messenger service: telematic service accessible through the Internet which implements the possibility of sending short SMS messages, usually from the health professionals sent to the patients for notifications, warnings, advice, etc. The service interacts with the SMS Centers of the telephone operators via GSMs available on the platform.

Two conditions are demanded from the SMS service:


Obviously the SMS service offered by the GSM is highly reliable although none of the two conditions demanded can be guaranteed 100%. However, the SMS service has mechanisms available that make it possible to know the current state of the SMS messages together with the occasional incidents that could take place in transit to the destination terminal. The SMS Centers offer the possibility of sending reports to the sender on the progress of the SMS (DLR, Delivery Reports). By means of the DLR request by message, the SMS service of the central station is capable of knowing whether a message is still in transit, has been delivered to the addressee (with time and date of receipt), or not or has been eliminated (together with its cause).

Equally, the SMS service is capable of establishing the period of validity ("validity period") of each message, exceeding which, if it has not been delivered to the addressee, it instructs the SMS Center in order to eliminate the said message from its lists (accompanied by the corre‐ sponding DLR report). The period of validity chosen depends on different factors and can vary from just a few hours to several days; its choice for example, in the case of communications to patients, depends on the medical protocol followed in the specific scenario. However, it is not a critical aspect in other types of task, and the default expiry period is not extended.

Another limitation of SMS messages is the nominal limitation in the total number of characters that can be included in each message, and which is fixed at 160. This length is very limiting in the majority of notifications from the doctor to the patient. It is also impractical for the doctor to send consecutive messages to the patient referring to the same matter (one of them might not arrive or arrive in the wrong order, etc.). However, there is the technical possibility of generating messages that are longer than usual ( "long SMS" calls) and which are segmented at the origin and later reassembled by the patient's mobile telephone in a way transparent to the user, and therefore permitting the sending of arbitrarily long messages. This functionality is supported by the SMS service of the platform.

Functionally, access to the SMS messages server is carried out by means of the HTTP/ SOAP1.1/1.2. "web-services" interface. In each request to send, the following is indicated: addressee of the message, text of the message, need for confirmation of delivery, period of validity and preferred time period for sending the message (or immediate delivery). Once the request is accepted a univocal identifier is generated with the service applicant and the sending procedure commences with an adjustment of the parameters of the message (establishment of the output queue, internal register, etc). The SMS service is in charge of sending the message through one of the available GSM modems. From the moment of sending the message to the corresponding SMS Center, the progress of the SMS is monitored through to the reception of the corresponding DLR. Before the arrival of each DLR message, the SMS messages server analyzes its content and notifies the state to the corresponding service that requested its sending in such a way that the state of the messages can be known at all times.

By means of a widely available mobile service, this service authorizes, by means of an open interface, a way of indirect communication between health professionals and patients with a high level of security (delivery security and range of validity), and personalization (flexibility in the size of the message and the establishment of the preferred period of time for delivery).

Randomizing service: telematic service accessible through the Internet that implements support to the randomizing process of clinical trials in a centralized way. The service deploys the following functionalities:

**•** Simultaneous support to randomizing in multiple studies

The platform consists at the physical level of a segmented Internet-accessible network including: 9 physical and virtual servers (Xen) on IBM xSeries equipment over Linux OS (Suse Linux Enterprise); SAN/NAS (IBM N3600) redundant storage networks; backup library

As basic support for e-services the platform provides a number of different general services: WWW service (Apache), DBMS (MySQL, PostgreSQL), applications managers (Tomcat), content managers (Drupal, LifeRay), "e-learning" server (Moodle), VoiceXML/IVR (VXI\*/

The platform includes security elements at different levels: control access (physical and telematic) policies, (storage and communications) redundancy and monitoring tools (Nagios/

Messenger service: telematic service accessible through the Internet which implements the possibility of sending short SMS messages, usually from the health professionals sent to the patients for notifications, warnings, advice, etc. The service interacts with the SMS Centers of

**•** that the SMS messages are delivered to the addressee and if not, get notification that it has

**•** that the SMS messages are delivered after a certain period of time so that the validity of its

Obviously the SMS service offered by the GSM is highly reliable although none of the two conditions demanded can be guaranteed 100%. However, the SMS service has mechanisms available that make it possible to know the current state of the SMS messages together with the occasional incidents that could take place in transit to the destination terminal. The SMS Centers offer the possibility of sending reports to the sender on the progress of the SMS (DLR, Delivery Reports). By means of the DLR request by message, the SMS service of the central station is capable of knowing whether a message is still in transit, has been delivered to the addressee (with time and date of receipt), or not or has been eliminated (together with its

Equally, the SMS service is capable of establishing the period of validity ("validity period") of each message, exceeding which, if it has not been delivered to the addressee, it instructs the SMS Center in order to eliminate the said message from its lists (accompanied by the corre‐ sponding DLR report). The period of validity chosen depends on different factors and can vary from just a few hours to several days; its choice for example, in the case of communications to patients, depends on the medical protocol followed in the specific scenario. However, it is not

a critical aspect in other types of task, and the default expiry period is not extended.

systems (TSM and IBM System Storage TS3200 Tape Library).

The specific services currently provided by the platform include:

the telephone operators via GSMs available on the platform.

Two conditions are demanded from the SMS service:

not (together with the causes) and

content is not indefinite.

Asterisk) service, TTS/ASR (Verbio) engines.

Cacti).

196 Telemedicine

cause).

**3.3. Services**


The service establishes three levels of privilege (overall administrator, project administrator, project user):

**•** The "overall administrator" user (level 1), has the capacity to create new projects and administer the functioning of the overall service; each project corresponds to a clinical trial. The process of creating a new project has the aim of authorizing the permission, structures and data necessary for its configuration in the service. Once the new project is created, the figure of the administrator "project administrator" already associated to a specific study is established.

**•** Querying of the information through a graphical interface: the user, after identification, has access to a browser which permits him or her to navigate through the information, but only to that part on which it has permissions depending on his/her role (access control compliant with part 4 of the 13606 standard). This functionality makes use of the archetype server service in order to obtain those used in the generation of the information and be able to present the data in a complete manner and in the language or using the terminologies

PITES: Telemedicine and e-Health Innovation Platform

http://dx.doi.org/10.5772/57021

199

**•** Retrieval of a patient's information: web service which permits to request a given patient's information using an interface compliant with part 5 of the standard. Through this service the user can request (utilizing other application, service or system) the whole information stored in a person's record or a part of it, obtaining an extract with the requested composi‐

**•** Information queries: the service also offers the possibility to pose specific queries oriented to the statistical processing of the total population in the repository and yielding numerical

Archetype repository service: telematic service which stores and retrieves archetypes compli‐ ant with the model established in the standard: archetypes are transferred in text files codified in the ADL language and using an interface compatible with part 5 of the 13606 standard. The system stores archetypes according the reference model normalized in part 2, which enables to perform searches using any identification data or any state of the archetype and also through the meaning of the nodes (specified as restrictions to the RECORD\_COMPONENT class of the reference model of the extracts) defined in it. The retrieval/querying of archetypes permits two

**•** Retrieval of archetypes: following the specifications of the interface defined in part 5 of the standard this automatic service enables to retrieve archetypes through its identifier, concept, terminology, language or those that are specializations or have been specialized by another archetype. This service is oriented to its use by other services, applications or even other

**•** Archetype querying: the server offers a web graphical browser for users to navigate through the archetypes repository; to query them through concept or type; see their specializations

Following the philosophy of the double model in the standard, this service permits the

Demographic information service: this service stores and provides demographic information of the entities involved in the clinical information systems. It is based upon the demographic information model included in the reference model of part 1 in the standard; this permits to deal with persons (patients and health professionals) and also with organizations or devices and programs in use. This service keeps track of all the identifiers assigned to each entity, including official entities but also those assigned internally by organizations, for instance in specific projects. This working method allows to separate demographic information from the

desired by the user (if they are defined and mapped in the archetype).

tions and complaining the corresponding access restrictions.

results about prevalence of diseases or concurrence of problems.

and download them to be used in their own projects.

archetype querying in an open fashion.

possibilities:

external systems.


The service does not establish limits on the studies in relation to the total number of stratifi‐ cation levels. A random assignment list is generated for each stratification branch with as many assignment groups as have been established to guarantee the assignment balance in groups of varying sized blocks. Each randomizing request that the service carries out is associated to a transaction identifier which the service may propose or generated dynamically, in such a way that it is possible to control each assignment individually in relation not only to the activity register but also the recovery in real time of errors in the process. The randomizing service includes internal functionalities for the register of auditing in each clinical trial. In relation to the generation of the project and the assignment tables, the randomizing seed is stored which makes it possible to guarantee the integrity of the assignment lists and their reproduction. It also generates a series of daily files on the degree of activity and functioning of the server, created and updated dynamically by date/time/project/user access/action carried out.

The service is accessible through an interface based on Web services by means of the SOAP (1.1/1.2) protocol and transport on the HTTPS service. This randomizing service has the advantage of basing its functionality on an open interface for the integral management of the process. This approximation makes it possible to promote the clinical trial, design and develop client applications in the measurement of their requirements and resources, incorporating the randomizing process transparently as another element/service in the management of its clinical trial.

Clinical information service: telematic service which stores and retrieves clinical information compliant with the ISO EN 13606 standard. In is based upon a web services structure with two groups of functionalities: the input of information and its querying/retrieval. The input of information is performed through an interface compliant with part 5 of the standard which accepts extracts codified in XML. The service processes the received information before storing it in order to obtain features which permit to classify it and enable its ulterior querying and retrieval. To do so for one side complete extracts are stored (preserving the integrity of the information) and for the other a relational database is built where the obtained features are kept in order. The querying/retrieval of information presents three options:

**•** Querying of the information through a graphical interface: the user, after identification, has access to a browser which permits him or her to navigate through the information, but only to that part on which it has permissions depending on his/her role (access control compliant with part 4 of the 13606 standard). This functionality makes use of the archetype server service in order to obtain those used in the generation of the information and be able to present the data in a complete manner and in the language or using the terminologies desired by the user (if they are defined and mapped in the archetype).

The process of creating a new project has the aim of authorizing the permission, structures and data necessary for its configuration in the service. Once the new project is created, the figure of the administrator "project administrator" already associated to a specific study is

**•** The "project administrator" (level 2), has the capacity to create the structure of the process of randomizing the clinical trial: total sample, number of assigned groups (identified successively by: A, B, C, D, E, F), variable block sizes (multiples of the number of assignation groups), and the stratification tree (if required). The "project administrator" has the capacity to open/interrupt/close the randomizing process, and request progress statistics on the

**•** The "project user" (level 3), whose function is basically to request the assignments to groups

The service does not establish limits on the studies in relation to the total number of stratifi‐ cation levels. A random assignment list is generated for each stratification branch with as many assignment groups as have been established to guarantee the assignment balance in groups of varying sized blocks. Each randomizing request that the service carries out is associated to a transaction identifier which the service may propose or generated dynamically, in such a way that it is possible to control each assignment individually in relation not only to the activity register but also the recovery in real time of errors in the process. The randomizing service includes internal functionalities for the register of auditing in each clinical trial. In relation to the generation of the project and the assignment tables, the randomizing seed is stored which makes it possible to guarantee the integrity of the assignment lists and their reproduction. It also generates a series of daily files on the degree of activity and functioning of the server,

created and updated dynamically by date/time/project/user access/action carried out.

The service is accessible through an interface based on Web services by means of the SOAP (1.1/1.2) protocol and transport on the HTTPS service. This randomizing service has the advantage of basing its functionality on an open interface for the integral management of the process. This approximation makes it possible to promote the clinical trial, design and develop client applications in the measurement of their requirements and resources, incorporating the randomizing process transparently as another element/service in the management of its

Clinical information service: telematic service which stores and retrieves clinical information compliant with the ISO EN 13606 standard. In is based upon a web services structure with two groups of functionalities: the input of information and its querying/retrieval. The input of information is performed through an interface compliant with part 5 of the standard which accepts extracts codified in XML. The service processes the received information before storing it in order to obtain features which permit to classify it and enable its ulterior querying and retrieval. To do so for one side complete extracts are stored (preserving the integrity of the information) and for the other a relational database is built where the obtained features are

kept in order. The querying/retrieval of information presents three options:

randomizing (overall, by time intervals, by stratum, etc.)

established.

198 Telemedicine

in a specific study.

clinical trial.


Archetype repository service: telematic service which stores and retrieves archetypes compli‐ ant with the model established in the standard: archetypes are transferred in text files codified in the ADL language and using an interface compatible with part 5 of the 13606 standard. The system stores archetypes according the reference model normalized in part 2, which enables to perform searches using any identification data or any state of the archetype and also through the meaning of the nodes (specified as restrictions to the RECORD\_COMPONENT class of the reference model of the extracts) defined in it. The retrieval/querying of archetypes permits two possibilities:


Following the philosophy of the double model in the standard, this service permits the archetype querying in an open fashion.

Demographic information service: this service stores and provides demographic information of the entities involved in the clinical information systems. It is based upon the demographic information model included in the reference model of part 1 in the standard; this permits to deal with persons (patients and health professionals) and also with organizations or devices and programs in use. This service keeps track of all the identifiers assigned to each entity, including official entities but also those assigned internally by organizations, for instance in specific projects. This working method allows to separate demographic information from the rest of data facilitating to make information anonym. For security reasons this service is not accessible from the outside of the platform so that its possible clients may only be its running applications or other supplied services.

of responding to a simple questionnaire. At some later moment, with no obligation imposed by the protocol in terms of frequency of access to the CS, the GPs accessed the data sent by their patients via the Web. According to his or her own criteria, the GP could send an SMS regarding any related issue to the patient's phone. The CG patients followed the same SBPM protocol, with the exception that the results were recorded on paper in a data collection notebook; they sent no data to the CS, and thus, had no interaction with their GPs. They continued to make their scheduled visits to their GPs at their corresponding center, as they

PITES: Telemedicine and e-Health Innovation Platform

http://dx.doi.org/10.5772/57021

201

– Study variables. The main outcome measure, referred to by us as the degree of hypertension control, was the percentage of patients who were not optimally controlled at the time of the final visit. Optimal control was defined as a mean of three arterial pressure determinations carried out by a professional during the final visit, resulting in pSBP ≤ 140 mmHg and pDBP ≤ 90 mmHg. The secondary outcome measures were: 1) the changes in pSBP and pDBP between the initial and final visits measured in the office of the GP; 2) the changes in the mean selfmeasured sSBP, sDBP, and HR throughout the intervention period; 3) the changes in the dimensions of the brief profiles of the SF-36 Health Survey physical component summary (PCS) and mental component summary (MCS) and in the state anxiety (SA) and trait anxiety (TA), according to the State–Trait Anxiety Inventory (STAI); and 4) the number of consultations

– Results. A) Degree of hypertension control. The number of patients exhibiting poor control at the final visit, was the case in 31.7% of the patients in the TmG and in 35.7% of those in the CG, (difference: 4.0%, 95% CI: −7.0% to 14.9%) there being no significant difference (p = 0.47). B) Change in hypertension during follow-up. In the comparison of the measurements carried out by the GPs at the initial and final visits, the TmG presented a decrease in pSBP of 15.5 mmHg and a decrease in pDBP of 9.6 mmHg, while in the CG, the pSBP decreased by 11.9 mmHg and the pDBP by 4.4 mmHg, decreases that did not differ significantly (pSBP: p=0.13; pDBP: p=0.40). The mean values for self-measured sSBP, sDBP, and HR (TmG: 131.6, 78.7, 70.1; CG: 132.4, 78.0, 69.7) throughout the six-month period, calculated according to the area under the curve, were not significantly different between the two groups (sSBP: p = 0.52; sDBP: p =

– Comments. There are no significant differences between the two groups in terms of the degree of hypertension control, measured as the number of poorly controlled patients at the final visit, given that the intention to treat analysis adds those that dropped out prior to the initial visit (TmG: n = 11; CG: n = 1) and those occurring during follow-up (TmG: n = 4; CG: n = 10) to the number of poorly controlled patients who underwent follow-up (TmG: n = 30; CG: n = 40). However self-blood pressure monitoring brings about improvements in hypertension control, given that the percentage of controlled patients in the final visit is greater in TmG. The reduction obtained in pSBP and pDBP in the TmG are consistent with the values reported by

**•** Evaluation of a Telemedicine-Based Service for the Follow-Up and Monitoring of Patients Treated With Oral Anticoagulant Therapy. (FIS 02/1156. SEP 1201/02. AIRMED II Program).

had done prior to the study.

0.50; and HR: p = 0.79).

[55]

and hospital admissions in the two groups.

other authors, independent of the intervention selected.

Anonymisation service: this service enables to make anonym clinical information to be used in secondary uses such as research or statistics. This service accepts and returns extracts compliant with the standard reference model, codified in XML. Received extracts are analyzed to suppress the identification of the patient including demographic information codified in class IDENTIFIED\_ENTITY of the reference model, even though the year of birthday (not including day and month) and the sex of the patient may be preserved for statistical purposes. To do so, a new randomized identifier is assigned and substituted in the extract. This service makes use of the demographic service in order to maintain a record of the identifiers in use so that if further information about the same patient arrives its identifier can be assigned and the health information repository remains coherent. For this reason it is possible to install this service and the demographic service in the client side so that the information about the person does not leave the organization where it was generated and the clinical information is presented anonym to the outside world.
