Maestría en Sistemas Interactivos Centrados en el Usuario

“Plataforma de e-salud con un enfoque de software como servicio para la

provisión a aplicaciones multicanal centradas en el usuario”

T E S I S

Presenta

Esther Varela Rodríguez

Para Obtener el grado de

Maestro en Sistemas Interactivos Centrados en el Usuario

Directores de Tesis

Dr. Ramón David Sarmiento Cervantes

Xalapa, Veracruz, México Enero 2015

UNIVERSIDAD VERACRUZANA

FACULTAD DE ESTADÍSTICA E INFORMÁTICA

Índice

1. Introducción 1

1.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Definición del Problema . . . . . . . . . . . . . . . . . . . . . 21.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . 31.3.2. Objetivos Específicos . . . . . . . . . . . . . . . . . . . 3

1.4. Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Estado del Arte 5

2.1. Definición de e-salud . . . . . . . . . . . . . . . . . . . . . . . 52.2. Áreas de aplicación de la e-salud . . . . . . . . . . . . . . . . 62.3. Beneficios de la e-salud . . . . . . . . . . . . . . . . . . . . . . 72.4. Iniciativas de e-salud . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.1. Ángel Guardián . . . . . . . . . . . . . . . . . . . . . 72.4.2. PING . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.3. Indivo . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.4. Dossia . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.5. HealthVault . . . . . . . . . . . . . . . . . . . . . . . . 102.4.6. Google Health . . . . . . . . . . . . . . . . . . . . . . 112.4.7. Tratamiento 2.0 . . . . . . . . . . . . . . . . . . . . . . 112.4.8. Portafolio Digital . . . . . . . . . . . . . . . . . . . . . 122.4.9. sugarDROID . . . . . . . . . . . . . . . . . . . . . . . 122.4.10. SAMIH . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5. Resumen iniciativas de e-salud . . . . . . . . . . . . . . . . . 14

3. Análisis de Arquitectura 15

3.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2. Cómputo en la nube . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1. Software como Servicio (SaaS) . . . . . . . . . . . . . 173.3. SOA y Servicios Web . . . . . . . . . . . . . . . . . . . . . . . 18

v

vi Índice

3.3.1. Arquitectura Orientada a Servicios (SOA) . . . . . . . 193.3.2. Servicios Web . . . . . . . . . . . . . . . . . . . . . . . 193.3.3. Protocolo Simple de Acceso a Objetos (SOAP) . . . . 203.3.4. Transferencia del Estado Representacional (REST) . . 213.3.5. Análisis comparativo de SOAP - REST . . . . . . . . 243.3.6. Lenguaje de Etiquetado Extensible (XML) . . . . . . . 253.3.7. Notación de Objetos de JavaScript (JSON) . . . . . . 263.3.8. Análisis comparativo de XML - JSON . . . . . . . . . 27

3.4. Arquitectura de e-Salud Propuesta . . . . . . . . . . . . . . . 283.4.1. Elementos de la Arquitectura . . . . . . . . . . . . . . 28

4. Caso de Estudio 31

4.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2. Descripción general del caso de estudio . . . . . . . . . . . . . 32

4.2.1. Establecimiento de los requerimientos . . . . . . . . . 334.2.2. Diseño Centrado en el Usuario (DCU) . . . . . . . . . 344.2.3. Análisis y diseño preliminar . . . . . . . . . . . . . . . 364.2.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5. Conclusiones y trabajos futuros 43

I Apéndices 45.1. Expediente clínico del paciente diabético . . . . . . . . . . . . 47

Bibliografía 55

Índice de figuras

2.1. Arquitectura de Indivo . . . . . . . . . . . . . . . . . . . . . . 72.2. Arquitectura de Indivo . . . . . . . . . . . . . . . . . . . . . . 92.3. Arquitectura de la plataforma Microsoft HealthVault . . . . . 102.4. Vista en capas de la arquitectura Google Health . . . . . . . . 112.5. Glucómetro conectado al dispositivo que envía la señal de

Bluetooth y el móvil con la aplicación de sugarDroid. . . . . . 132.6. Resumen iniciativas de e-Salud . . . . . . . . . . . . . . . . . 14

3.1. Cómputo en la nube . . . . . . . . . . . . . . . . . . . . . . . 173.2. Software como Servicio (SaaS) . . . . . . . . . . . . . . . . . . 183.3. Interacción en Servicios Web . . . . . . . . . . . . . . . . . . . 203.4. Estructura de mensaje SOAP . . . . . . . . . . . . . . . . . . 213.5. Estructura de un servicio web REST . . . . . . . . . . . . . . 223.6. Análisis comparativo de SOAP vs REST . . . . . . . . . . . . 243.7. Formato XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.8. Formato JSON . . . . . . . . . . . . . . . . . . . . . . . . . . 263.9. Análisis comparativo de XML vs JSON . . . . . . . . . . . . 273.10. Arquitectura Propuesta . . . . . . . . . . . . . . . . . . . . . 28

4.1. Directora y doctores del Centro de Salud Urbano “Dr. GastónMelo” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2. Diagrama general de casos de uso . . . . . . . . . . . . . . . . 374.3. Diagrama entidad-relación . . . . . . . . . . . . . . . . . . . . 39

1. Carátula del expediente clínico . . . . . . . . . . . . . . . . . 472. Hoja frontal del expediente clínico . . . . . . . . . . . . . . . 483. Historia clínica general - hoja 1 . . . . . . . . . . . . . . . . . 494. Historia clínica general - hoja 2 . . . . . . . . . . . . . . . . . 505. Historia clínica general - hoja 3 . . . . . . . . . . . . . . . . . 516. Notas de evolución . . . . . . . . . . . . . . . . . . . . . . . . 527. Resúmen clínico . . . . . . . . . . . . . . . . . . . . . . . . . . 53

vii

Índice de Tablas

4.1. Descripción del caso de uso “Consultar expediente clínico deun paciente diabético”. . . . . . . . . . . . . . . . . . . . . . . 40

4.2. Caso de prueba para el caso de uso “Consultar expedienteclínico de un paciente diabético” . . . . . . . . . . . . . . . . 41

ix

Capítulo 1

Introducción

1.1. Antecedentes

Las Tecnologías de la Información y la Comunicación (TIC) están pre-sentes en todos los niveles de nuestra sociedad actual, desde las más gran-des corporaciones multinacionales, a las pymes, gobiernos, administraciones,universidades, centros educativos, organizaciones socioeconómicas y asocia-ciones, profesionales y particulares (Alonso, 2010).

La aplicación de las TIC a todos los sectores de la sociedad y de la eco-nomía mundial ha generado términos nuevos como, por ejemplo, e-businessy e-commerce (negocio y comercio electrónico), e-government (gobierno-electrónico), e-health (salud electrónica), e-learning (formación a distancia),e-inclusión (inclusión social digital o el acceso a las TIC de los grupos ex-cluidos socialmente), entre otros.

Actualmente, existe un interés internacional en explotar el potencial delas TIC para mejorar la eficiencia, calidad y seguridad en la prestación deservicios de salud a través de iniciativas de e-salud también conocida comoe-Health o e-health.

Hasta antes de 1999 el término e-salud estaba apenas en uso. Sin em-bargo, actualmente es utilizado para describir medicina a través de Internetasí como todo lo relacionado a las computadoras y la medicina (Eysenbach,2001). Fueron líderes de la industria quienes crearon y aplicaron este términojunto con otras e-palabras tales como e-commerce o e-businees para transmi-tir y reflejar los principios y promesas del e-commerce o comercio electrónicoal área de la salud así como para mostrar las nuevas posibilidades que inter-net estaba abriendo a la salud.

Actualmente, no existe una definición formal de e-salud debido a que al

1

2 Capítulo 1. Introducción

igual que internet, esta es definida por su uso ya que se encuentra en unambiente dinámico evolucionando constantemente. Sin embargo, de acuerdoa la Organización Mundial de la Salud (OMS), e-salud es el uso de las tec-nologías de la información y la comunicación para la salud (OMS, 2014). Lae-salud se ha convertido en una prioridad en las naciones en todos los nive-les de desarrollo debido a que juega un rol sustancial para ayudar a creartecnologías para el sector salud.

Como se describe en (Catwell y Sheikh, 2009) las tecnologías de e-saludactuales comprenden el desarrollo de sistemas, portales y plataformas queproporcionan un medio para acceder a registros médicos e información rela-cionada a la salud de los pacientes; aunque sirven diferentes propósitos y adiferentes tipos de usuarios objetivo.

Este es uno de los principales motivos por los que actualmente no se hadesarrollado una arquitectura de software abierta que permita proporcionarservicios a otras aplicaciones y dispositivos a través de la infraestructura dela Web, sin dejar a un lado las necesidades del usuario, quien representa elaspecto más importante en todo el proceso desarrollo de software.

1.2. Definición del Problema

De acuerdo a una revisión del estado del arte de las estrategias de e-saludque se han desarrollado a nivel nacional e internacional, se observa que lossistemas de salud actuales, carecen de propuestas para estructurar una arqui-tectura de software abierta que funcione como guía para la implementaciónde una plataforma de e-salud que permita:

Extender la funcionalidad de la plataforma por terceros.

Proporcionar servicios en la nube para el desarrollo de aplicacionesde e-salud centradas en el usuario y en distintos dispositivos, sistemasoperativos y marcas.

De igual forma, como menciona (Alberto Riva, 2001) son mínimas lasiniciativas de e-salud existentes que satisfacen los requerimientos de protec-ción de confidencialidad, portabilidad, seguridad, interoperabilidad, así comointegración con otros sistemas de información de salud utilizando protocolosestándar y almacenando la información mediante la infraestructura de Inter-net. Esto se debe en gran parte debido a la variedad de sistemas operativos,dispositivos y marcas hoy en día disponibles.

1.3. Objetivos 3

1.3. Objetivos

1.3.1. Objetivo General

Diseñar e implementar una arquitectura de software abierta y orienta-da a servicio en la nube, que permita el desarrollo e intercomunicación deaplicaciones de e-salud a través de distintos dispositivos y plataformas.

1.3.2. Objetivos Específicos

Investigar el estado del arte de las iniciativas de salud más sobresa-lientes desarrolladas a nivel nacional e internacional y que comprendenaplicaciones, sistemas o plataformas de e-salud.

Realizar un análisis de tecnologías y estándares de Internet involucra-dos en el diseño y desarrollo de una arquitectura de software. Esto conel objetivo de determinar los componentes de una arquitectura abiertay orientada a servicios en la nube.

Diseñar un caso de aplicación o estudio, en donde se implemente laarquitectura propuesta a través del desarrollo de una plataforma dee-salud.

Probar la plataforma de e-salud desarrollada con los dos tipos de usua-rios objetivo: Usuarios desarrolladores de aplicaciones de e-salud yusuarios finales; éste último grupo es formado por médicos y pacientesdel Centro de Salud Urbano Dr. Gastón Melo, de la Ciudad de Xalapa,Veracruz.

1.4. Hipótesis

La construcción de una plataforma de e-salud orientada a servicios per-mitirá facilitar el desarrollo e interconexión de aplicaciones de e-salud endistintos dispositivos y plataformas.

1.5. Justificación

Con el desarrollo de una plataforma de e-salud que proporcione serviciosen la nube, se busca establecer una propuesta de modelo integral de serviciossalud que mejorará la eficiencia en el desarrollo de aplicaciones de este tipo.

De igual forma, gracias a la automatización por parte de las aplicacionesde e-salud, de algunos de los procesos llevados a cabo actualmente de maneramanual, se disminuirán los tiempos de respuesta y se elevará la calidad en la

4 Capítulo 1. Introducción

prestación de servicios por parte de las instituciones.

Este modelo integral de salud se mantiene a la vanguardia no obstantela constante evolución tecnolóiga.

Capítulo 2

Estado del Arte

Resumen: En este capítulo se presenta el estado del arte de la e-salud,

con el objetivo de conocer la definición del término e-salud así como sus

principales áreas de aplicación y beneficios. De igual forma, se describe

brevemente la evolución de las aplicaciones, sistemas y plataformas de

e-salud más innovadoras desarrolladas nacional e internacionalmente.

Finalmente, se muestra un resumen con las principales características

de las tecnologías de e-salud.

2.1. Definición de e-salud

La Fundación France Telecom España en su Informe Anual de 2006 (Es-paña, 2006) sobre el desarrollo de la Sociedad de la Información en España,define la e-salud como:

“La aplicación de las Tecnologías de Información y Comunicación en elamplio rango de aspectos que afectan el cuidado de la salud desde el diag-nóstico hasta el seguimiento de los pacientes, pasando por la gestión de lasorganizaciones implicadas en estas actividades. En el caso concreto de losciudadanos, la e-salud les proporciona considerables ventajas en materia deinformación, incluso favorece la obtención de diagnósticos alternativos. Engeneral, para los profesionales, la e-salud se relaciona con una mejora en elacceso a información relevante, asociada a las principales revistas y asocia-ciones médicas, con la prescripción electrónica asistida y, finalmente, con laaccesibilidad global a los datos médicos personales a través de la HistoriaClínica Informatizada.”

5

6 Capítulo 2. Estado del Arte

2.2. Áreas de aplicación de la e-salud

En su “Primer ensayo sobre la eSalud española”, (Díaz, 2006) proponeque la e-salud se apoya en las siguientes áreas de aplicación:

Telemedicina. Permite brindar atención médica sin estar en el mismoespacio físico. En sus inicios se realizaba por teléfono, pero hoy en díase puede llevar a cabo de otras formas, como por videoconferencia.Es muy conveniente para que los pacientes crónicos puedan recibir untratamiento y seguimiento sin tener que desplazarse físicamente. Lospacientes se desplazan menos pero el área de intervención del médicose extiende.

Cita y consulta online. La consulta online y la cita online son dosformas de interactuar con un médico a distancia. Gracias a la cita on-line se puede concertar una cita con un médico sin salir de casa y conla consulta online se puede realizar una consulta médica a un profesio-nal sanitario que no sea de urgencias. Existen múltiples herramientaspara realizar la consulta online tales como videoconferencia, consultaasíncrona, etc.

Historial clínico online. Es un objetivo a futuro, que la tecnologíapueda implantar en todo el sistema de salud por completo el acceso delpersonal sanitario y/o paciente a su historial clínico online. De formaque los archivos que conforman el expediente clínico de un paciente yque antes estaban en una carpeta de papel, puedan estar de manerasegura en la nube y sean accesibles para todas las instituciones desalud.

Tecnología llevable. La tecnología llevable, traducción de tecnologíawearable ha surgido como una tendencia debido a los nuevos disposi-tivos desarrollados aplicados a la salud. Estos dispositivos son capacesde monitorizar datos sobre los pacientes y enviarlos a otro dispositivocomo un teléfono inteligente o una computadora, para que estos datosse puedan consultar y estar al alcance del profesional sanitario que lonecesite.

Registros médicos electrónicos. Administración digital de historiasclínicas que facilita el archivo, consulta, edición e intercambio de in-formación de los pacientes entre diversos profesionales sanitarios comocentros de salud, hospitales, especialistas y farmacias.

m-Health. Uso de dispositivos móviles para reunir datos de los pa-cientes, proporcionar información a profesionales, investigadores, mo-

2.3. Beneficios de la e-salud 7

nitoreo en tiempo real de los signos vitales de los pacientes y provisiónde cuidado a través de técnicas de telemedicina.

2.3. Beneficios de la e-salud

La introducción de las TICs en el cuidado de la salud en combinacióncon los cambios sociales necesarios tanto en las organizaciones como en laforma de pensar de los ciudadanos, ha reducido sustancialmente los costos ymejorado la eficiencia (of the European Communities, 2004)

Como lo menciona (Alvarez, 2002), las iniciativas de telemedicina puedentraspasar los retos que los profesionales de salud enfrentan al proporcionarservicios de salud equitativos, accesibles y de alta calidad a personas que vi-ven en ubicaciones remotas y a aquellos que no pueden desplazarse fácilmentea otro lugar.

2.4. Iniciativas de e-salud

A partir de 1990, se inició el desarrollo de los sistemas de información desalud centrados en el paciente. A continuación, se describen brevemente lasprincipales características, así como sus ventajas y desventajas.

2.4.1. Ángel Guardián

Figura 2.1: Logotipo de Ángel Guardián

El proyecto que marcó la pauta es Ángel Guardián (Szolovits et al., 1994),el cual se empezó a desarrollar en 1994 por el Laboratorio de Ciencias dela Computación del Instituto Tecnológico de Massachussets (MIT) en cola-boración con el Programa de Informática del Hospital de Niños de Boston(CHIP).

Un Ángel Guardián (AG) es un agente de software que reúne informaciónde los pacientes, la revisa, interpreta y almacena. Sus principales funciones

8 Capítulo 2. Estado del Arte

son: envía alertas de posibles peligros, genera recomendaciones basado en lasexperiencias anteriores y preferencias del paciente, realiza revisiones sobrela eficacia y efectividad del costo de diagnóstico, monitorea el progreso detratamientos, proporciona información médica al paciente e interactúa conotros agentes de proveedores de salud, aseguradoras, etc.

AG proponía una arquitectura abierta y flexible capaz de adaptarse a losdesarrollos tecnológicos a largo plazo. Así mismo, sugería la implementaciónde estándares para proporcionar facilidades de seguridad y autenticación,interfaces a dispositivos de captura de datos e interfaces de usuario fácilesde usar, entre otras.

2.4.2. PING

En 1998, el Programa de Informática del Hospital de Niños de Boston,desarrolló la implementación prototipo de AG a la que denominó Guardian yNotario Personal Interconectado (PING). De acuerdo a (Alberto Riva, 2001)el principal objetivo de PING consistía en desarrollar un sistema de registrosmédicos controlado por el paciente.

PING implementa tecnologías Web y mecanismos de encriptación de lla-ve pública para definir una arquitectura segura, distribuida y escalable quepermita a los pacientes ejercer un control total de sus datos médicos. El sis-tema organiza la información como un árbol de archivos en formato XML entexto plano para asegurar independencia de la plataforma. Además, utilizaun esquema de permisos basado en roles para asignar privilegios de acceso.

2.4.3. Indivo

PING fue renombrado como Indivo en 2006. Continúa con el concepto deregistros médicos controlados por el paciente. Sin embargo, implementa unainterfaz Web, con estándares abiertos así como una Interfaz de Programaciónde Aplicaciones (API) abierta.

Como se describe en (Mandl et al., 2001) la arquitectura de Indivo estácompuesta de tres capas: almacenamiento de datos, lógica de negocios einterfaz de usuarios. Las características principales de Indivo son cumplircon la transparencia y alta seguridad en todas las capas del sistema.

2.4. Iniciativas de e-salud 9

Figura 2.2: Arquitectura de Indivo

2.4.4. Dossia

Dossia es un consorcio integrado por algunas de las marcas mundialesmás grandes como Applied Materials, AT&T, Walmart, Intel (Consortium,2014) entre otras. Dossia proporciona la infraestructura para terceras partespara el desarrollo de aplicaciones de salud centradas en el paciente. Estainfraestructura incluye una plataforma de software de código abierto y unaAPI para los proveedores de datos y desarrolladores de aplicaciones.

Como se menciona en (Research, 2007) en 2007 el consorcio adoptó aIndivo como la plataforma de registros de salud para los trabajadores queconforman las empresas de Dossia.

En 2008, Walmart fué el primer miembro del consorcio en ofrecer losregistros de salud a sus empleados como un beneficio voluntario con unainfraestructura segura y basada en Web (InformationWeek, 2008). De acuer-do a (TechWeb, 2010) para el año 2010, más de la mitad de empresas delconsorcio habían implementado la plataforma y actualmente integra más de40 aplicaciones de salud de terceros y dispositivos conectados, ofreciendosecomo Software como Servicio a través de la nube a otras empresas.

10 Capítulo 2. Estado del Arte

2.4.5. HealthVault

Fue desarrollada en 2007 por Microsoft. Es una plataforma de salud desoftware y servicios basada en la nube (Microsoft, 2012).

Como la describe (Rijpma, 2008), la arquitectura de HealthVault permiteconectar a la plataforma dispositivos de salud y condición física tales comomonitores de ritmo cardiaco, de presión sanguínea, glucómetros, básculas,etc., para obtener datos de los usuarios. De igual forma, proporciona un con-junto de interfaces basadas en XML y HTTP que permiten a terceros crearservicios para la plataforma.

La infraestructura en la nube de HealthVault, proporciona a los usuariosun único lugar para reunir, almacenar, compartir y utilizar su informaciónde salud. Así mismo, provee una API abierta y accesible desde cualquierlenguaje de programación moderno.

Figura 2.3: Arquitectura de la plataforma Microsoft HealthVault

2.4. Iniciativas de e-salud 11

2.4.6. Google Health

En 2008, Google presentó su plataforma de registros de salud denomi-nada Google Health. Esta plataforma implementaba estándares Web comoHTTP, XML, RSS y Atom, así como estándares de tecnologías de informa-ción para el cuidado de la salud como el Registro de Continuidad de Cuidados(CCR)(Jason, 2009).

La API de servicios de Google Health estaba desarrollada en los lenguajesde programación .Net, Java, Python y PHP para permitir el desarrollo deaplicaciones clientes.

Figura 2.4: Vista en capas de la arquitectura Google Health

La plataforma fue descontinuada a partir del 01 de junio de 2013 debidoa que como Google menciona en su blog oficial (Aaron, 2011) no cumplió consus expectativas. En 2011, el Director Ejecutivo de Dossia, Michael Critelliafirmaba que el error de Google fue solicitar a los usuarios recabar e ingresarsu propia información de salud a la plataforma (Review, 2011).

2.4.7. Tratamiento 2.0

Este proyecto fue creado en 2008 por Indra (Indra, 2014), una multina-cional Española que ofrece soluciones y servicios tecnológicos para diversossectores. Es una plataforma para el desarrollo de aplicaciones destinadas a

12 Capítulo 2. Estado del Arte

la gestión y aplicación a distancia del tratamiento de enfermedades crónicas,especialmente diabetes mellitus.

Tratamiento 2.0 permite la interacción de pacientes y profesionales desalud. Consta de una Unidad Central de Integración (UCI), una PC conconexión a Internet instalada en el domicilio del paciente a la que se conectandispositivos biomédicos y domóticos que registran información del pacientey la canalizan a la UCI, desde donde es enviada a la plataforma, facilitandoel seguimiento, evolución del paciente y su enfermedad (Indra, 2011).

2.4.8. Portafolio Digital

Portafolio Digital es una plataforma electrónica creada en 2012 por elInstituto Carlos Slim de la Salud como parte del proyecto Casalud (de laSalud, 2014).

De acuerdo a (de la Salud, 2013), esta plataforma brinda a los profe-sionales de la salud información actualizada y herramientas para elevar lacalidad de la atención tales como material de consulta para la atención deenfermedades crónicas y prevención focalizada de esas patologías, por gruposde edad.

La plataforma se ha puesto a funcionar en treinta centros de salud delpaís. Se apoya de herramientas como Diabediario (de la Salud, 2012), unsistema interactivo por medio de dispositivos móviles que proporciona herra-mientas a las personas que padecen diabetes mellitus tipo 2 para el control desu enfermedad a través de consejos diarios a su teléfono celular, recordatoriode citas y de toma de medicamentos.

2.4.9. sugarDROID

En 2012, estudiantes de la Universidad Pontificia de Salamanca, España,desarrollaron sugarDROID, una aplicación móvil para la plataforma Androida través de la cual un paciente de diabetes puede llevar una supervisión con-trolada de la enfermedad para facilitar el seguimiento y proceso de consultacuando acuda a revisión con su médico o profesional de servicios de salud(de Salamanca, 2013).

La aplicación funciona con un glucómetro al cual se conecta un dispositi-vo que permite el envío de las mediciones de glucosa del paciente por mediode bluetooth a un dispositivo móvil celular (DICYT, 2013). Posteriormente,las mediciones son enviadas a una aplicación Web que será accesible tantopara el paciente como para el personal de servicios de salud. Así mismo, la

2.4. Iniciativas de e-salud 13

aplicación envía alertas al especialista si se registran constantes hipogluce-mias o hiperglucemias de un paciente.

Figura 2.5: Glucómetro conectado al dispositivo que envía la señal de Blue-tooth y el móvil con la aplicación de sugarDroid.

2.4.10. SAMIH

El Sistema de Administración Médica e Información Hospitalaria (SA-MIH) es una plataforma creada por el Instituto Carlos Slim de la Salud cuyolanzamiento se realizará a partir de 2015 en hospitales y clínicas de salud enMéxico (Geek, 2014).

El objetivo de este proyecto es combatir las principales enfermedadesque se presentan en el país a través de una plataforma de salud en la quelos pacientes tendrán su historial médico electrónico que estará disponibleen cualquier centro de atención médica pública.

La principal característica del SAMIH es la identificación precisa del pa-ciente, la confidencialidad así como la reducción del tiempo de espera en laatención. Además de que permitirá que los diferentes sistemas hospitalariosse puedan comunicar entre sí, así como que sólo el personal de salud ten-drá acceso a la información médica asegurando con esto la seguridad de lainformación de los pacientes.

14 Capítulo 2. Estado del Arte

2.5. Resumen iniciativas de e-salud

A continuación se presentan las principales características de las inicia-tivas de e-Health mencionadas anteriormente.

Figura 2.6: Resumen iniciativas de e-Salud

Capítulo 3

Análisis de Arquitectura

Resumen: En el capítulo III se realiza un análisis de tecnologías

y estándares para el desarrollo de aplicaciones orientadas a servicios

tomando en consideración requerimientos funcionales y no funcionales.

Como resultado de este análisis, se propone una arquitectura abierta

orientada a proporcionar servicios en la nube.

3.1. Antecedentes

En la década de los 90’s surgió la preocupación por cómo diferentes má-quinas podían comunicarse entre sí. En esa época, era suficiente con que lasaplicaciones de una misma computadora lograrán establecer una comunica-ción.

En 1990 se desarrolló el Modelo de Objetos de Componentes (COM)y CORBA (Common Object Request Broker Architecture) . El primero fuecreado por Microsoft y el segundo por el Object Management Group (OMG).No obstante, estos modelos tenían como desventaja que no eran fácilmenteinteroperables, ya que las dos computadoras que llevaban a cabo la comuni-cación debían soportar COM o CORBA.

Posteriormente, Microsoft creó el Modelo de Objetos de ComponentesDistribuidos (DCOM) y Sun desarrolló la Llamada a Métodos Remotos(RMI). Aunque estas tecnologías permitián establecer una conexión entrecomputadoras a través de la red, tampoco eran interoperables ya que RMIestaba disponible únicamente para Java y por lo tanto, es dependiente dellenguaje de programación.

En 1997 Microsoft empezó a interesarse por la computación distribui-da basada en el Lenguaje de Marcado Extensible (XML). Su objetivo era

15

16 Capítulo 3. Análisis de Arquitectura

terminar con los problemas de interoperabilidad de las tecnologás anterioresy permitir que las aplicaciones se conectaran mediante Llamadas a Proce-dimientos Remotos (RPCs), utilizando los estándares de comunicación deXML y del Protocolo de Transferencia de Hipertexto (HTTP).

En 1998, el Protocolo de Acceso a Objetos Simple (SOAP) fue desa-rrollado por Microsoft por Dave Winer, Don Box, Bob Atkinson y MohsenAl-Ghosein. La versión SOAP 1.1 se presentó en el ano 2001 e IBM partici-pó en su creación con lo que se produjeron cambios significativos y crucialespara su uso posterior: se diseño de una forma más modular y escalable, eli-minando los problemas derivados de una tecnología propietaria, en este casode Microsoft. Además IBM desarrolló una implementación de SOAP en Javay SOAP se integró en Web Services J2EE.

La especificación SOAP es mantenida actualmente por el XML ProtocolWorking Group del World Wide Web Consortium (W3C). En la versión 1.2de SOAP, se eliminó la sigla Protocolo de Acceso a Objetos Simple y se con-virtió en una recomendación del W3C a partir del 24 de junio de 2003.

Después de que SOAP se introdujo por primera vez, se convirtió en lacapa subyacente de un conjunto más complejo de los Servicios Web los cualessurgieron ante la necesidad de estandarizar la comunicación entre distintasplataformas y lenguajes de programación (Singh, 2009).

Sin embargo, aunque son muchos los beneficios de SOAP, también pre-senta inconvenientes, razón por la que un nuevo estilo de arquitectura desoftware conocido como Transferencia del Estado Representacional (REST)ha tomado fuerza en los últimos años representando una alternativa a SOAPpara el desarrollo de Servicios Web.

3.2. Cómputo en la nube

De acuerdo a (de la Sociedad de la Información de Castilla y León ORSI,2010), Cómputo en la nube o Cloud Computing consiste en la gestión y sumi-nistro de aplicaciones, información y datos como un servicio. Estos serviciosse proporcionan a través de la “nube"(una red de telecomunicaciones públi-ca, generalmente Internet) por lo general en un modelo basado en el consumo.

Cómputo en la nube proporciona de manera eficiente el acceso a serviciosinformáticos, independientemente de los sistemas físicos que utilizan o de suubicación real, siempre y cuando se disponga de acceso a Internet.

3.2. Cómputo en la nube 17

Figura 3.1: Cómputo en la nube

Existen varias empresas que proporcionan servicios gratuitos en la nubecomo Google Docs de Google para procesamiento de textos, Flickr para al-macenar o compartir imágenes, Youtube o Vimeo para almacenar videos, etc.De igual forma, empresas como Microsoft o Amazon proveen herramientaspropietarias y de pago para uso más profesional con diferentes modelos depago.

Los proveedores de Cloud Computing ofrecen servicios que se agrupan entres categorías:

Software como servicio (SaaS)

Plataforma como servicio (PaaS)

Infraestructura como Servicio (IaaS)

3.2.1. Software como Servicio (SaaS)

Software como servicio o Software as a Service (SaaS) es un modelo dedespligue de software en donde una aplicación informática se ofrece comoun servicio a través de Internet. De esta manera, las aplicaciones en la “nu-be"son accesibles desde varios dispositivos del cliente a través de una interfaz

18 Capítulo 3. Análisis de Arquitectura

la cual puede ser un navegador Web, sin necesidad de que el usuario instaleo actualice las aplicaciones en sus equipos.

SaaS permite el uso de nuevo software sin necesidad de realizar una graninversión inicial en adquisición de licencias o sistemas informáticos contribu-yendo con esto a reducir el costo de implementación.

Figura 3.2: Software como Servicio (SaaS)

Un ejemplo de SaaS es el servicio de correo Web. Los servicios de correopermiten enviar y recibir correos fuera de la oficina o domicilio, así comoconsultar los correos almacenados. Entre los servicios más conocidos destacanGmail, Hotmail y Yahoo.

3.3. SOA y Servicios Web

La Arquitectura Orientada a Servicios (SOA) ha emergido como una ar-quitectura importante en el ambiente de cómputo complejo y heterogéneoactual ya que las empresas deben permitir acceso a sus servicios más queuna interfaz a su lógica de negocios.

SOA puede ayudar a las organizaciones y empresas a agilizar sus proce-sos de manera que puedan realizar sus transacciones más eficientemente y

3.3. SOA y Servicios Web 19

adaptarse a las necesidades cambiantes y competencia a través de la imple-mentación de software como servicio.

SOA y Web Services son dos conceptos diferentes. Web Services son losestándares preferidos para SOA.

3.3.1. Arquitectura Orientada a Servicios (SOA)

SOA es un estilo arquitectónico que utiliza los servicios disponibles en lared para la construcción de aplicaciones. SOA promueve un bajo acoplamien-to entre los componentes de software para que estos puedan ser reutilizados.Las aplicaciones SOA son construidas de servicios.

Un servicio es una implementación de una funcionalidad de negocio biendefinida y tales servicios pueden por lo tanto, ser consumidos por clientes endiferentes aplicaciones o procesos de negocios.

3.3.2. Servicios Web

Los servicios web son el punto clave de integración para diferentes apli-caciones pertenecientes a diferentes plataformas, lenguajes de programacióny sistemas.

El World Wide Web Consortium (W3C) define los Servicios Web o WebServices como un conjunto de aplicaciones o tecnologías con capacidad parainteroperar en la Web (W3C, 2014a). Estas aplicaciones o tecnologías inter-cambian datos entre sí con el objetivo de ofrecer servicios. Esta interopera-bilidad es adquirida a través de un conjunto de estándares abiertos basadosen el Lenguaje de Etiquetado Extensible (XML) tales como el Lenguaje deDescripción de Servicios Web (WSDL), el Protocolo Simple de Acceso a Ob-jetos (SOAP) y UDDI. Estos estándares proporcionan un enfoque comúnpara definir, publicar y utilizar Servicios Web (W3C, 2004).

La definición de Servicios Web propuesta por la W3C alberga varios ti-pos diferentes de sistemas, pero el caso más común se refiere a clientes yservidores que se comunican mediante mensajes XML que siguen el estándarSOAP. Sin embargo, en los últimos años se ha popularizado un nuevo estilode arquitectura de software conocido como Transferencia del Estado Repre-sentacional (REST). Este nuevo estilo ha supuesto una nueva opción paralos Servicios Web (Navarro Marset, 2006).

A continuación, se describen brevemente las tecnologías y estándares deservicios web.

20 Capítulo 3. Análisis de Arquitectura

Figura 3.3: Interacción en Servicios Web

3.3.3. Protocolo Simple de Acceso a Objetos (SOAP)

SOAP es un protocolo basado en el lenguaje XML para el intercambiode información entre aplicaciones. Los datos son transmitidos comúnmentea través de HTTP pero puede utilizar otros protocolos como el Protocolode Transferencia de Correo Simple (SMTP). SOAP especifica el formato delos mensajes. El mensaje SOAP está compuesto por un sobre (envelope) cu-ya estructura está formada por los una cabecera (header) y cuerpo (body).La cabecera es opcional y proporciona información sobre autenticación, co-dificación de los datos o cómo un destinatario del mensaje SOAP deberíaprocesarlo. El cuerpo contiene el mensaje (Barry, 2012). XML Schema esutilizado para describir la estructura del mensaje SOAP de manera que lainfraestructura SOAP en los dos extremos pueda formar y desarmar el conte-nido del mensaje y enrutarlo a la implementación apropiada (Pautasso et al.,2008). El Lenguaje de Descripción de Servicios Web (WSDL) es un lenguajeXML para la definición de las interfaces.

3.3.3.1. Fortalezas

A pesar de su complejidad, SOAP ha ganado una amplia adopción comouna de las principales tecnologías capaces de entregar interoperabilidad entresistemas heterogéneos. Una ventaja de la pila del protocolo WS-* es la trans-

3.3. SOA y Servicios Web 21

Figura 3.4: Estructura de mensaje SOAP

parencia e independencia del protocolo. Utilizando SOAP, el mismo mensajeen el mismo formato puede ser transportado a través de una variedad desistemas los cuales pueden implementar HTTP así como otros protocolos detransporte.

El contrato WSDL proporciona una descripción procesable por la máqui-na de la sintaxis y estructura de los mensajes de petición y respuesta. Debidoa que los requerimientos de la tecnología cambian, la misma interfaz de ser-vicio puede ser asociada a diferentes protocolos de transporte y extremos dela comunicación.

3.3.3.2. Debilidades

Los problemas de interoperabilidad pueden generarse cuando no hay unacoincidencia entre el XML y los lenguajes de programación (orientados aobjetos) existentes. Por otro lado, XML Schema es un lenguaje muy comple-to, lo cual hace difícil identificar la construcción correcta para expresar unmodelo de datos en una forma que sea completamente soportada por todaslas implementaciones SOAP/WSDL.

3.3.4. Transferencia del Estado Representacional (REST)

REST es un estilo de arquitectura de software para el diseño de aplica-ciones en red. De acuerdo a (Barry, 2012), está basado en un conjunto deprincipios que describen como los recursos de la red son definidos y dirigidos.Estos principios fueron introducidos en 2000 por Roy Fielding como parte desu tesis doctoral (Fielding, 2000). REST es una alternativa a mecanismos co-mo RPC y SOAP. Las aplicaciones o arquitecturas REST son referidas comoRESTful o REST-style. REST utiliza el protocolo HTTP para las operacio-

22 Capítulo 3. Análisis de Arquitectura

nes CRUD (Crear/Leer/Actualizar/Borrar). Debido a que es la arquitecturaque Internet implementa, se ha convertido en la opción más popular para eldesarrollo de Servicios Web. La Transferencia del Estado (ST, de sus siglás)describe que en un buen diseño REST, las operaciones son independientes ycada petición contiene (transfiere) toda la información (estado) que el servi-dor necesita con el objetivo de ser completada (Elkstein, 2008).

Figura 3.5: Estructura de un servicio web REST

3.3.4.1. Principios de la Tecnología REST

Identificación de recursos a través de una URI. Un servicio WebRESTful expone un conjunto de recursos los cuales son identificadospor URIs o Identificadores Uniformes de Recursos, los cuales proporcio-nan un espacio de direccionamiento global para los recursos y serviciosde descubrimiento.

Interfaz uniforme. Los recursos son manipulados utilizando un con-junto de cuatro operaciones para crear, leer, actualizar y eliminar:PUT, GET, POST y DELETE. PUT permite crear un recurso, el cualpuede ser borrado utilizando DELETE, GET obtiene el estado actualde un recurso en alguna representación y POST transfiere un nuevoestado a un recurso.

3.3. SOA y Servicios Web 23

Mensajes autodescriptivos. Los recursos no están asociados a surepresentación, de manera que su contenido puede ser accesado en unavariedad de formatos como HTML, XML, texto plano, PDF, JPEG,etc.

Interacciones con estado a través de hipervínculos. Cada inter-acción con un recurso es sin estado lo que significa que una peticiónes por sí misma auto contenida. Las interacciones con estado estánbasadas en el concepto de transferencia del estado explćita.

3.3.4.2. Fortalezas

REST es simple debido a que los estándares e infraestructura que imple-menta como HTTP y XML son ampliamente conocidos y de uso generalizado.

Es una infraestructura de peso ligero en donde los servicios RESTfulpueden ser construidos con las herramientas mínimas, siendo de bajo costo ypor lo tanto tiene una barrera muy baja de adopción para los desarrolladores.

El esfuerzo requerido para construir un cliente que consuma un servicioRESTful es mínimo, de manera que los desarrolladores pueden probar estosservicios desde un navegador Web, sin tener que desarrollar un software per-sonalizado en el lado del cliente para consumir el servicio.

Las URIs e hipervínculos permiten descubrir recursos Web sin registrarlosobligatoriamente en un repositorio centralizado. Otra fortaleza de REST esque proporciona flexibilidad para optimizar el rendimiento de un ServicioWeb debido a la posibilidad de seleccionar un formato de peso ligero comoJSON para los mensajes.

3.3.4.3. Debilidades

Existe una confusión de las mejores prácticas para la construcción deServicios Web RESTful ya que hay dos enfoques: Hi-REST and Lo-REST.

Hi-REST defiende el uso de los cuatro verbos (GET, POST, PUT y DE-LETE) y recomienda el uso de URIs y de Plain Old XML (POX) o XMLbásico para formatear el contenido de los mensajes. Por otro lado, Lo-RESTsugiere el uso de dos verbos, GET para consultas y POST para todo lo de-más. Esto se debe a que algunos proxies y firewalls podrían bloquear lasconexiones HTTP entrantes que utilicen otro verbo.

Así mismo, GET y POST son las únicas operaciones que pueden serutilizadas en el atributo METHOD de un formulario HTML.

24 Capítulo 3. Análisis de Arquitectura

Otra limitación de REST es para las peticiones GET con más de 4 KB dedatos de entrada ya que no será posible codificar esos datos en la URI delrecurso. Sin embargo, el método POST no sufre de estas limitaciones.

3.3.5. Análisis comparativo de SOAP - REST

Figura 3.6: Análisis comparativo de SOAP vs REST

3.3. SOA y Servicios Web 25

3.3.6. Lenguaje de Etiquetado Extensible (XML)

La W3C define XML como un lenguaje de etiquetado que permite el in-tercambio de una gran variedad de datos entre diferentes tipos de computado-ras, diferentes aplicaciones y organizaciones sin necesidad de pasar a travésde muchas capas de conversión. (W3C, 2014b). Como lo describe (Laurent,1998), XML está derivado del Lenguaje de Etiquetado Generalizado Están-dar (SGML) el cual se caracterizaba por el manejo de grandes cantidades dedocumentos. XML tiene una sintaxis más pequena y más simple dirigida adesarrolladores web ya que representa una solución simple para la creación,administración y visualización de documentos. Las principales ventajas deXML como un lenguaje de representación de datos son: a) está basado entexto y b) es independiente de la plataforma, estas características fomentanun alto nivel de independencia de las aplicaciones más que con otros for-matos de intercambio de datos. Sin embargo, las desventajas de XML sonque transporta información extra y no coincide con el modelo de datos de lamayoría de los lenguajes de programación a pesar de la interoperabilidad yapertura que proporciona este estándar de la W3C (json.org, 2014b).

Figura 3.7: Formato XML

26 Capítulo 3. Análisis de Arquitectura

3.3.7. Notación de Objetos de JavaScript (JSON)

JSON es un formato ligero de intercambio de datos. Es fácil para los hu-manos leerlo y escribirlo, mientras que para las máquinas es simple interpre-tarlo y generarlo. Está basado en un subconjunto del lenguaje de programa-ción Javascript. JSON es un formato de texto completamente independientedel lenguaje que utiliza convenciones que son conocidas por programado-res de la familia de lenguajes C, tales como C++, C#, Java, JavaScript,Perl, Python y muchos otros. Estas características hacen que JSON sea unlenguaje ideal para el intercambio de datos. JSON está constituído por dosestructuras: a) una colección de pares nombre/valor, en varios lenguajes estoes conocido como objeto, registro, estructura, etc., y b) una lista ordenadade valores, en la mayoría de los lenguajes de programación se implementacomo arreglos, vectores, listas o secuencias. Estas dos estructuras son univer-sales, por lo tanto son soportadas por todos los lenguajes de programación(json.org, 2014a).

Figura 3.8: Formato JSON

3.3. SOA y Servicios Web 27

3.3.8. Análisis comparativo de XML - JSON

Figura 3.9: Análisis comparativo de XML vs JSON

28 Capítulo 3. Análisis de Arquitectura

3.4. Arquitectura de e-Salud Propuesta

De acuerdo al análisis de tecnologías y estándares se propone la siguientearquitectura:

Figura 3.10: Arquitectura Propuesta

3.4.1. Elementos de la Arquitectura

Servidor GlassFish. Un servidor es un nodo que ofrece servicios através de la red a otros nodos denominados clientes.

El servidor es el núcleo de la arquitectura de e-Salud, debido a que seencarga de exponer servicios de la Base de Datos MySQL, el Backend

3.4. Arquitectura de e-Salud Propuesta 29

REST JSON y la aplicación Web.

La aplicación Web y el Backend REST JSON se desplegarán en el ser-vidor de aplicaciones GlassFish versión 3.1.2.

GlassFish es un servidor de aplicaciones gratuito y de código abier-to desarrollado por Sun Microsystems bajo un licenciamiento dual através de la licencia Common Development and Distribution License(CDDL) y la GNU Public License (GPL).

El término código abierto significa que es posible para cualquier per-sona descargar el código fuente para utilizarlo, estudiarlo y ajustarlo asus necesidades.

Glassfish provee un servidor para el desarrollo y despliegue de aplica-ciones de la Plataforma Java Edición Empresarial (Java EE) (Oracle,2013) y de tecnologías Web basadas en la tecnología Java tales comoJava Server Pages (JSP), Servlets, Enterprise Java Beans (EJBs), JavaAPI para Servicios Web (JAX-WS) y Arquitectura Java para EnlacesXML (JAXB) así como para otras tecnologías.

Base de datos MySQL. Se utilizará MySQL como Sistema de Ad-ministración de Base de Datos (RDBMS) para crear y administrar laBase de Datos de la plataforma.

MySQL es un Sistema de Administración de Base de Datos Relacionalgratuito, apliamente utilizado y de código abierto disponible bajo la li-cencia GNU General Public License. Es una opción popular de base dedatos que se utiliza para aplicaciones Web y proyectos de código abiertoque requieren un sistema de administración completo de base de datos.

MySQL es utilizado por sitios web grandes y populares como Wikipedia,Google, Facebook, Twitter, Flickr y Youtube entre otros.

API REST JSON. La API de la arquitectura proporciona una inter-faz para que las aplicaciones de salud de terceros extiendan la funcio-nalidad de la misma mediante operaciones de creación, actualización yconsulta de expedientes clínicos de los pacientes. De igual manera, laAPI proporciona una interfaz abierta para desarrollar aplicaciones dee-salud que estén centradas en las necesidades de los usuarios.

La API ha sido desarrollada siguiendo el patrón de diseno REST y elformato JSON, descritos en secciones anteriores de este documento.

30 Capítulo 3. Análisis de Arquitectura

Esta API está compuesta por un conjunto de servicios Web desarrolla-dos en el lenguaje de programación Java mediante la tecnología ADFBusiness Components de Oracle.

Oracle ADF proporciona un conjunto de herramientas para la imple-mentación de una Arquitectura Orientada a Servicios (SOA), ADF Bu-siness Components (ADF BC) entre otros. ADF BC proporciona unframework estándar para desarrollar servicios de negocios e interfacesde usuario para accesar a esos servicios.

Aplicación Web. La aplicación Web propuesta en esta arquitectu-ra consumirá los servicios expuestos en la API REST JSON para elcontrol de la enfermedad de pacientes de diabetes mellitus tipo 2 delCentro de Salud Urbano Dr. Gaston Melo.

En el siguiente capítulo, se describe el caso de estudio en donde seimplementará la arquitectura propuesta en esta sección.

Capítulo 4

Caso de Estudio

Resumen: Este capítulo describe un caso de estudio para pacientes

con diabetes mellitus tipo 2, en donde se implementa la arquitectura

orientada a servicios propuesta en este trabajo de tesis mediante la

utilización de la metodología ICONIX. Se mencionan las técnicas de

Diseño Centrado en el Usuario (DCU) empleadas para la obtención de

requerimientos y necesidades de los usuarios finales de la plataforma

de e-salud y finalmente se presentan los casos de prueba para el caso

de uso “Consultar expediente clínico”.

4.1. Antecedentes

La diabetes mellitus es un grupo de enfermedades caracterizadas por unalto nivel de glucosa resultado de defectos en la capacidad del organismopara producir o utilizar eficazmente la insulina que produce (Association,2014). La insulina es una hormona que regula el azúcar en la sangre.

La clasificación de la DM contempla cuatro grupos: Diabetes tipo 1(DM1), Diabetes tipo 2 (DM2), Diabetes gestacional (DMG) y otros tiposespecíficos de diabetes.

La diabetes tipo 1 (DM1) se caracteriza por una producción deficientede insulina y requiere la administración diaria de esta hormona. Sólo 5 % delas personas con diabetes padecen este tipo. La diabetes tipo 2 (no insulino-dependiente o de inicio en la edad adulta) tiene su origen en la incapacidaddel cuerpo para utilizar eficazmente la insulina. Representa el 90 % de loscasos mundiales y se debe en gran medida a un peso corporal excesivo y ala inactividad física.

31

32 Capítulo 4. Caso de Estudio

La diabetes mellitus gestacional (DMG) se define como una alteracióndel metabolismo de los hidratos de carbono, de severidad variable que seinicia o se reconoce por primera vez durante el embarazo.(ejecutivo ALAD2010-2013, 2013)

De acuerdo a (de la Salud, 2011), la diabetes representa un serio problemaa nivel mundial. La gravedad del problema se relaciona no sólo con el creci-miento alarmante de sus cifras, sino con la alta frecuencia de co-morbilidadesy el cuadro de complicaciones en el que suele derivar. A nivel mundial, elporcentaje de personas de 35-64 años con diabetes aumentará de menos del3 % en el año 2000 a más del 8 % en el año 2030. De acuerdo con la OMS,en el año 2030 habrá 366 millones de adultos con diabetes; de éstos, el 90 %corresponderá a la diabetes mellitus (DM) de tipo 2 y de éstos, el 75 % estaráviviendo en países en vías de desarrollo.

En el caso de México, la prevalencia de la DM2 y sus consecuencias cons-tituyen una seria preocupación de salud pública. De hecho, la DM2 es laprimera causa de muerte. A partir de 2009, México se encuentra entre losprimeros diez países con mayor prevalencia de la enfermedad, siendo que enel año 2000 no formaba parte de este grupo.

Estimaciones realizadas en México indican que para el año 2025, el nú-mero de habitantes con diabetes en México será de 11.7 millones.

El reto en términos de lo que representa para la sociedad es doble: porun lado, el importante monto de recursos que requieren los prestadores deservicios de salud para su atención, y por el otro el costo económico y emo-cional para las personas con diabetes y sus familias.

Todas las enfermedades son importantes, pero la diabetes y sus principa-les factores de riesgo son una verdadera emergencia de salud pública ya queponen en riesgo la viabilidad del sistema de salud.

4.2. Descripción general del caso de estudio

El objetivo general del caso de estudio es el desarrollo de una plataformade e-salud que implemente la arquitectura abierta y orientada a servicios enla nube propuesta en este trabajo de tesis.

Debido a que la DM2 es el tipo de diabetes más común en México asícomo por la accesibilidad a los dispositivos biomédicos utilizados para elcontrol de este padecimiento, la plataforma de e-salud estará dirigida parapacientes del Centro de Salud Urbano “Dr. Gastón Melo” de la ciudad de

4.2. Descripción general del caso de estudio 33

Xalapa, Veracruz, diagnosticados con este tipo de diabetes.

Para el desarrollo de este caso de estudio, se siguió la metodología ICO-NIX, la cual es un Enfoque de Modelado de Objetos Conducido por Casosde Uso. Este enfoque fue propuesto por Rosenberg(Rosenberg y Scott, 1999)e integra los mejores elementos de los enfoques de los “tres amigos” (GradyBooch, Jim Rumbaugh e Ivar Jacobson) proporcionando un conjunto de di-agramas y técnicas para el desarrollo de software orientado a objetos.

Esta metodología ofrece un método práctico de menor complejidad quepermite a los Ingenieros de Software realizar sistemas más pequeños dandopautas para identificar los elementos estáticos y dinámicos de los diferentesmodelos.

Las etapas que comprende ICONIX son: análisis de requerimientos, aná-lisis y diseño preliminar, diseño e implementación.A continuación, se presentan los artefactos desarrollados en cada una de lasetapas de ICONIX para la implementación de la arquitectura de e-salud.

4.2.1. Establecimiento de los requerimientos

Para desarrollar software de calidad, es necesario realizar un Análisis deRequerimientos de Software (ARS) como primera etapa del proceso de de-sarrollo, con el objetivo de definir qué es lo que se quiere del nuevo softwareantes de empezar a diseñarlo.

Dentro del ARS, se utilizarón técnicas de Diseño Centrado en el Usuario(DCU) con los estudiantes de la Licenciatura en Medicina de la UniversidadVeracruzana Karla Verónica Vásquez Hernández, Rodolfo Machorro Rosasasí como con los doctores Magdalena Moreno Todd y Gersón Moreno Monfilpara conocer el proceso actual de adscripción, consulta y control de la en-fermedad de los pacientes de DM2 del Centro de Salud Urbano “Dr. GastónMelo”.

De manera general, cuando un paciente acude al centro de salud por pri-mera ocasión, se crea un expediente clínico (ver apéndice 1) el cual contienedatos básicos del paciente y establecimiento, datos de sus beneficiarios, suhistoria clínica general y sus notas de evolución.

Posteriormente, los pacientes de DM2 llevan un control de su nivel deglucosa en sangre realizando mediciones diarias que son llevadas a consulta,aunque en algunos casos el realizar mediciones diariamente representa unproblema de adherencia al tratamiento para algunos pacientes y familiares.

34 Capítulo 4. Caso de Estudio

Cuando el paciente se dirige a la consulta, la enfermera o el doctor delconsultorio al que pertenece dicho paciente, proceden a realizar una mediciónde sus de niveles de azúcar en sangre, presión arterial y peso utilizando losdispositivos biomédicos glucómetro, baumanómetro y báscula. Estas medi-ciones son anotadas en una nota de evolución, en donde además el doctordescribe las notas de la consulta.

4.2.2. Diseño Centrado en el Usuario (DCU)

De acuerdo a la Asociación de Profesionales de Usabilidad o UPA(Hassan,2009), el Diseño Centrado en el Usuario o DCU es definido como un enfoquede diseño cuyo proceso está dirigido por información sobre las personas quevan a hacer uso de un producto.

En base a la definición anterior, es importante diferenciar los términosusabilidad y diseño centrado en el usuario. Usabilidad es un atributo de cali-dad del diseño mientras que DCU es una guía para mejorar la usabilidad deun producto. Usabilidad representa el qué mientras que el diseño centradoen el usuario representa el cómo lograrlo.

Por lo tanto, el objetivo del DCU es lograr la satisfacción de las necesida-des de todos sus usuarios potenciales, adaptar la tecnología a sus expectativasy crear interfaces que faciliten la consecución de sus objetivos. El DCU abar-ca un conjunto de metodologías y técnicas que tienen como finalidad conocery comprender las necesidades, limitaciones, comportamiento y característi-cas del usuario, el cual puede ser potencial o real.

A continuación, se presentan algunas de las técnicas de DCU que permi-tieron identificar las necesidades y requerimientos de los usuarios finales de laplataforma de e-salud, para reflejar este análisis en el diseño de la aplicaciónWeb de la plataforma de e-salud.

4.2.2.1. Entrevistas

Las entrevistas se emplean cuando se desea obtener información valiosapara el diseño de un proyecto por medio de preguntas a los usuarios, de talmanera que ayuda a descubrir sus deseos, motivaciones, valores y experien-cias.

Esta técnica fue implementada en primera instancia para platicar conestudiantes de la Licenciatura en Medicina de la Universidad Veracruzana ypresentarles una propuesta del proyecto. Posteriormente, se llevaron a cabomás entrevistas para averiguar cómo realizan actualmente los doctores del

4.2. Descripción general del caso de estudio 35

Centro de Salud el proceso de creación del expediente clínico y el controlde la enfermedad de pacientes con DM2. Así mismo, mediante esta técnicase logró obtener la información que integra el expediente clínico, notas deevolución y resumen clínico.

Figura 4.1: Directora y doctores del Centro de Salud Urbano “Dr. GastónMelo”

4.2.2.2. Test de Usuarios

Se utiliza está técnica cuando el evaluador necesita observar cómo esque los usuarios realizan sobre un producto o prototipo las tareas que sedesea automatizar o mejorar, esto con el objetivo de detectar problemas deusabilidad. De igual forma, contribuye a disminuir los problemas de diseñogenerados cuando se hace demasiado énfasis en el proyecto desde un puntode vista como diseñador o programador y se deja a un lado la experienciadel usuario que realmente utilizará el producto.

Se empleó está técnica para que el personal que colabora en el desarrollodel proyecto, evaluara los prototipos elaborados del expediente clínico deacuerdo a las entrevistas previamente realizadas con los involucrados.

4.2.2.3. Etnografía

Esta técnica es empleada cuando es necesario que los investigadores oespecialistas conozcan el comportamiento y actividades que los usuarios rea-lizan en su entorno mediante técnicas cualitativas y de observación.

36 Capítulo 4. Caso de Estudio

A diferencia de la entrevista en donde los usuarios proporcionaron infor-mación, se utilizó esta técnica para obtener información de los usuarios pormedio de la observación del entorno en donde desempeñan sus actividades.

4.2.2.4. Focus Group

Grupos focales o grupos de discusión es una variante de las entrevistas endonde un moderador entrevista de manera conjunta a un grupo de usuarios yen donde la interacción entre los participantes ofrecerá información adicionalsobre problemas, experiencias u opiniones compartidas por los miembros delgrupo.

Esta técnica se aplicará a un grupo de usuarios que utilicen la plataformade e-salud con el objetivo de lograr una interacción entre los miembros delgrupo, de manera que permita obtener una diversidad de opiniones respectoal uso de la plataforma.

Se planea realizar varios grupos focales en la etapa de pruebas de laplataforma de e-salud, de manera que los usuarios involucrados externen susopiniones y sugerencias respecto al uso de la plataforma y dichas opiniones setomen en cuenta para realizar las adecuaciones que se consideren pertinentes.

4.2.3. Análisis y diseño preliminar

El objetivo de la etapa de análisis en la metodología ICONIX es revisarlos requerimientos del nuevo software.

De acuerdo al análisis de requerimientos realizado previamente mediantetécnicas de DCU, se procede a realizar un diseño preliminar a través dediagramas de casos de uso y diagramas entidad-relación.

4.2.3.1. Diagrama de Casos de Uso

Dentro del enfoque ICONIX, uno de los pasos iniciales es la construcciónde un modelo de casos de uso para que el usuario capte los requerimientosde un nuevo sistema.

Un caso de uso es una secuencia de acciones que un actor realiza dentrode un sistema para conseguir un objetivo particular. En la figura 4.2 se pre-senta el diagrama de casos de uso de la plataforma de e-salud.

4.2. Descripción general del caso de estudio 37

Fig

ura

4.2:

Dia

gram

age

nera

lde

caso

sde

uso

38 Capítulo 4. Caso de Estudio

Este modelo se encuentra en el centro del enfoque debido a que conduceen la elaboración de otros artefactos como los diagramas de robustez, cola-boración, estado y diagramas de secuencia o interacción; así como tambiénes la base para las pruebas de aceptación durante la fase de implementación.

4.2.3.2. Diagrama Entidad-Relación

El modelo entidad-relación es una forma de representar la organizaciónde los datos en los sistemas de software.

En la figura 4.3, se presenta el modelo relacional de la base de datosde la plataforma de e-salud, el cual está formado por 24 entidades con susatributos y las relaciones entre ellas.

4.2.3.3. Descripción de Caso de Uso

En la tabla 4.1 se presenta la descripción del caso de uso “Consultarexpediente clínico de un paciente diabético” para los dos tipos de usuariosobjetivo de la plataforma de e-salud: usuarios finales (administradores, mé-dicos y pacientes) así como para usuarios desarrolladores de aplicaciones dee-salud.

4.2.4. Pruebas

De acuerdo a la descripción del caso de uso “Consultar expediente clínicode un paciente diabético”, se generaron los casos de prueba de la tabla 4.2,los cuales fueron realizados con una aplicación de e-salud desarrollada paradispositivos móviles que consume los servicios que ofrece la plataforma dee-salud.

4.2. Descripción general del caso de estudio 39

Fig

ura

4.3:

Dia

gram

aen

tida

d-re

laci

ón

40 Capítulo 4. Caso de Estudio

Tabla 4.1: Descripción del caso de uso “Consultar expediente clínico de unpaciente diabético”.

Nombre: Consultar expediente clínico de un paciente diabético.Autor: Esther Varela Rodríguez.Fecha: 10/01/2015

Descripción:Este caso de uso describe los pasos a seguir por losmédicos del Centro de Salud Urbano “Dr. Gastón Melo”para consultar el expediente clínico de un paciente diabético.

Actores: Médico del Centro de Salud “Dr. Gastón Melo”.

Pre condiciones:1. El servidor de aplicaciones en donde está alojada la plataformade e-salud debe ser accesible.2. La base de datos de la plataforma de e-salud debe ser accesible.

Flujo normal:

1. El médico da clic en el botón Pacientes desde la aplicaciónWeb de la plataforma de e-salud o desde la aplicación móvildesarrollada para los médicos.2. El servicio web de Pacientes de la API REST JSON de laplataforma de e-salud recibe una petición para obtener elrecurso “https://omnius.com.mx/esaludBackend/jersey/PacientesWS/getPacientes” que devuelve una cadena enformato JSON con una lista de pacientes.3. El médico visualiza una lista de los pacientes asignados a suconsultorio y da clic en el botón Consultar Expediente Clínico.4. El servicio web de Pacientes recibe una petición paraobtener el recurso “https://omnius.com.mx/esaludBackend/jersey/PacientesWS/getPaciente/idPaciente” y regresauna cadena JSON con la información del expediente clínicodel paciente.5. El médico visualiza una ventana en donde puede consultar lainformación basica del paciente, su historia clínica general,notas de evolución y el resumen clínico del paciente.

Flujo alternativo:4.1 El servicio web de Pacientes detecta que el usuario médicono tiene los privilegios de acceso necesarios para consultarinformación y regresa un código de error.

Pos condiciones:El médico consulta correctamente el expediente clínico delpaciente diabético.

4.2.D

escripción

generaldel

casode

estudio41

Tabla 4.2: Caso de prueba para el caso de uso “Consultar expediente clínico de un paciente diabético”

Número Entrada Condiciones de entrada Salida esperada Condiciones de salida

1El médico da clic enla opción Pacientes.

El servidor de aplicacionesde la plataforma de e-saludes accesible.

El servicio web de Pacientesde la API REST JSON recibeuna petición para obtener elrecurso https://omnius.com.mx/esaludBackend/jersey/PacientesWS/getPacientes ydevuelve una cadena en formatoJSON con una lista de pacientes.

El médico visualiza unalista de los pacientesasignados a su consultorio.

2El médico da clic enla opción Pacientes.

El servidor de aplicacionesde la plataforma de e-saludno es accesible.

La aplicación web o móvilque intenta conectarse alservicio web de Pacientes,recibe un código de error deconexión fallida.

El médico visualiza unmensaje de "No se hapodido establecer unaconexión con elservidor de la plataformade e-salud."

3El médico da clic enla opción Pacientes.

La base de datos de laplataforma de e-salud esaccesible.

El servicio web de Pacientesde la API REST JSON recibeuna petición para obtener elrecurso https://omnius.com.mx/esaludBackend/jersey/PacientesWS/getPacientes ydevuelve una cadena en formatoJSON con una lista depacientes.

El médico visualiza unalista de los pacientesasignados a su consultorio.

4El médico da clic enla opción Pacientes.

La base de datos de laplataforma de e-saludno es accesible.

El servicio web de Pacientesde la API REST JSONdevuelve un código de errorde conexión fallida a la basede datos.

El médico visualiza unmensaje de No se hapodido establecer unaconexión con la basede datos de laplataforma.

Capítulo 5

Conclusiones y trabajos futuros

De acuerdo a las pruebas realizadas con los desarrolladores de aplicacio-nes de e-salud, se obtiene como resultado que la arquitectura de la plataformapermite facilitar el desarrollo e intercomunicación de aplicaciones entre dis-tintos dispositivos.

Esto se debe principalmente a que la estructura de la llamada a los re-cursos de la API es fácil de entender para los desarrolladores de aplicacionesy de igual forma, la respuesta generada en formato JSON es más fácil deprocesar por los sistemas por ser un lenguaje más simple que XML.

Considero que el desarrollo de este proyecto de tesis es relevante y tras-cendental debido a que permitirá mejorar la imagen de los servicios de saludprestados en el Centro de Salud Urbano “Dr. Gastón Melo”, así como la efi-ciencia del personal de salud, la cual se ve reflejada en una reducción de lostiempos de respuesta empleados en la creación y actualización del expedienteclínico del paciente diabético.

Además, se contribuye a elevar la participación de la tecnología en elmejoramiento de los servicios sanitarios.

Aunque actualmente la aplicación Web ha sido desarrollada a un 85 %,se planea terminarla en las semanas próximas para poder aplicar pruebas deusabilidad y aceptación con los usuarios finales del Centro de Salud.

De igual manera, se desea implementar el protocolo abierto oAuth (OpenAuthorization) como un esquema de autenticación segura para la API RESTJSON de la plataforma.

43

Parte I

Apéndices

.1. Expediente clínico del paciente diabético 47

.1. Expediente clínico del paciente diabético

Figura 1: Carátula del expediente clínico

48

Figura 2: Hoja frontal del expediente clínico

.1. Expediente clínico del paciente diabético 49

Figura 3: Historia clínica general - hoja 1

50

Figura 4: Historia clínica general - hoja 2

.1. Expediente clínico del paciente diabético 51

Figura 5: Historia clínica general - hoja 3

52

Figura 6: Notas de evolución

.1. Expediente clínico del paciente diabético 53

Figura 7: Resúmen clínico

Bibliografía

Aaron, B. An update on google health and google powerme-ter. 2011. Disponible en http://googleblog.blogspot.mx/2011/06/

update-on-google-health-and-google.html/ (último acceso, Octubre,2013).

ejecutivo ALAD 2010-2013, C. Guías alad sobre el diagnóstico, control ytratamiento de la diabetes mellitus tipo 2 con medicina basada en eviden-cia. En Revista de la ALAD - Asociación Latinoamericana de Diabetes,páginas 24–26. 2013.

Alberto Riva, D. H. O. D. J. N. A. B. P. S. I. S. K., Kenneth. Mandl. The personal internetworked notary and guardian. InternationalJournal of Medical Informatics , 2001.

Alonso, R. Tecnologías de la Información Y la Comunicación (módulo).Ideaspropias Editorial, 2010. ISBN 9788498392630.

Alvarez, R. C. The promise of e-health - a canadian perspective. EHealthInternational , 2002.

Association, A. D. Información básica de la diabetes. 2014. Disponible enhttp://www.diabetes.org/es/informacion-basica-de-la-diabetes/

(último acceso, Enero, 2015).

Barry, D. Web Services, Service-Oriented Architectures, and Cloud Com-puting: The Savvy Manager’s Guide. Elsevier Science, 2012. ISBN9780124072008. Disponible en http://books.google.com.mx/books?id=

RTMb5vlByEUC (último acceso, Diciembre, 2013).

Catwell, L. y Sheikh, A. Evaluating ehealth interventions: The needfor continuous systemic evaluation. PLOS Medicine, vol. 6(8), 2009. Dis-ponible en http://journals.plos.org/plosmedicine/article?id=10.

1371/journal.pmed.1000126#s2 (último acceso, Enero, 2015).

55

56 Bibliografía

Consortium, D. About us. 2014. Disponible en http://www.dossia.org/

about-us (último acceso, Abril, 2014).

Díaz, J. J. Primer ensayo sobre la esalud espanola. 2006. Disponible enhttp://javierjdiaz.com/ebook-esalud/ (último acceso, Marzo, 2015).

DICYT, A. I. p. l. D. d. l. C. y. l. T. Una aplicaciónpara móviles facilita el control de los pacientes con diabe-tes. 2013. Disponible en http://www.dicyt.com/noticias/

una-aplicacion-para-moviles-facilita-el-control-de-los-pacientes-con-diabetes

(último acceso, Abril, 2014).

Elkstein, M. Learn rest: A tutorial. 2008. Disponible en http://rest.

elkstein.org/2008/02/what-is-rest.html (último acceso, Diciembre,2013).

España, F. F. T. Informe anual sobre el desarrollo de la sociedad de lainformación en españa. eespaña 2006. 2006.

of the European Communities, C. e-health - making healthcare betterfor european citizens: An action plan for a european e-health area. 2004.

Eysenbach, G. What is e-health? J Med Internet Res , vol. 3(2), página e20,2001. Disponible en http://www.jmir.org/2001/2/e20 (último acceso,Octubre, 2014).

Fielding, R. T. Architectural styles and the design of network-basedsoftware architectures. doctoral dissertation, university of california, ir-vine. 2000. Disponible en http://www.ics.uci.edu/~fielding/pubs/

dissertation/rest_arch_style.htm (último acceso, Diciembre, 2013).

Geek. En 2015, historial médico electrónico. 2014. Disponible en http://

www.geek.com.mx/2014/04/en-2015-historial-medico-electronico/

(último acceso, Abril, 2014).

Hassan, Y. Informe apei sobre usabilidad. asociación profesional de espe-cialistas en información. 2009.

Indra. Teletratamiento inteligente para los diabéticos. 2011. Disponible enhttp://www.indracompany.com/prensa/actual-indra/edition/2011/

1/teletratamiento-inteligente-para-los-diabéticos-6735 (últimoacceso, Marzo, 2013).

Indra. Sobre indra. 2014. Disponible en http://www.indracompany.com/

sobre-indra/compania-global-de-ti (último acceso, Octubre, 2013).

InformationWeek. Wal-mart rolls out e-health records to all employees.2008. Disponible en http://www.informationweek.com/database/

Bibliografía 57

wal-mart-rolls-out-e-health-records-to-all-employees/d/d-id/

1072519? (último acceso, Abril, 2014).

Jason, S. Consultant’s guide to google health part i of iv an architectureview. 2009. Disponible en http://healthtechsynthesis.wordpress.

com/2009/05/12/consultant_guide_to_google_health_part_i_of_

iv/ (último acceso, Octubre, 2013).

json.org. Introducción a json. 2014a. Disponible en http://www.json.

org/json-es.html (último acceso, Diciembre, 2013).

json.org. Json: The fat-free alternative to xml. 2014b. Disponible enhttp://www.json.org/xml.html (último acceso, Diciembre, 2013).

Laurent, S. S. Why xml. 1998. Disponible en http://www.simonstl.

com/articles/whyxml.htm (último acceso, Diciembre, 2013).

de la Sociedad de la Información de Castilla y León ORSI, O. R.Cloud computing - la tecnología como servicio. 2010. Disponible en www.

orsi.jcyl.es (último acceso, Abril, 2014).

Mandl, K. D., Szolovits, P. y Kohane, I. S. Public standards andpatient’s control: how to keep electronic medical records accessible butprivate. BMJ , 2001.

Microsoft. Introduction to healthvault for developers.2012. Disponible en http://www.slideshare.net/aliemami/

health-vault-intro-for-developers (último acceso, Abril, 2014).

Navarro Marset, R. Rest vs web services. modelado, diseno e imple-mentación de servicios web 2006-07. 2006. Disponible en http://users.

dsic.upv.es/~rnavarro/NewWeb/docs/RestVsWebServices.pdf (últimoacceso, Octubre, 2014).

OMS. ehealth at who. 2014. Disponible en http://www.who.int/ehealth/

about/en/ (último acceso, Abril, 2014).

Oracle. Glassfish server open source edition. quick start guide. 2013. Dispo-nible en https://glassfish.java.net/docs/4.0/quick-start-guide.

pdf (último acceso, Mayo, 2013).

Pautasso, C., Zimmermann, O. y Leymann, F. Restful web services vs.’big’web services: Making the right architectural decision. En Proceedingsof the 17th International Conference on World Wide Web, WWW ’08,páginas 805–814. 2008. ISBN 978-1-60558-085-2.

Research, C. Indivo health: Further details on dossia agreement.2007. Disponible en http://www.chilmarkresearch.com/2007/10/17/

58 Bibliografía

indivo-health-further-details-on-dossia-agreement/ (último ac-ceso, Abril, 2014).

Review, M. T. A better personal health record? 2011. Dis-ponible en http://www.technologyreview.com/news/424761/

a-better-personal-health-record/ (último acceso, Octubre, 2013).

Rijpma, G. Microsoft healthvault. 2008. Disponible en http://www.

slideshare.net/HINZ/microsoft-healthvault (último acceso, Abril,2014).

Rosenberg, D. y Scott, K. Use Case Driven Object Modeling with UML:a practical approach.. Boston: Addison Wesley, 1999.

de Salamanca, U. P. sugardroid, descripción general del proyecto.2013. Disponible en https://www.upsa.es/clubinnovacion/proyectos/

2013/fichas_pdf_new/11_sugarDROID.pdf (último acceso, Abril, 2014).

de la Salud, I. C. S. Manual para profesionales de la salud - diabetesmellitus tipo 2. 2011. Disponible en www.salud.carlosslim.org (últimoacceso, Enero, 2015).

de la Salud, I. C. S. Estudio para medir el impacto de diabe-diario, innovación para el control de la diabetes única en américalatina. 2012. Disponible en http://www.salud.carlosslim.org/

estudio-para-medir-el-impacto-de-diabediario-innovacion-para-el-control-de-la-

(último acceso, Abril, 2014).

de la Salud, I. C. S. Portafolio digital, plataforma para profesionales dela salud. 2013. Disponible en http://www.portafoliodigital.org.mx

(último acceso, Abril, 2014).

de la Salud, I. C. S. Casalud, modelo desarrollado para revolucionar laatención en los centros de salud de primer contacto. 2014. Disponibleen http://www.salud.carlosslim.org/casalud/ (último acceso, Abril,2014).

Singh, T. Rest vs. soap - the right web servi-ce. 2009. Disponible en http://geeknizer.com/

rest-vs-soap-using-http-choosing-the-right-webservice-protocol/

(último acceso, Octubre, 2014).

Szolovits, P., Doyle, J., Long, W. J., Kohane, I. y Pauker, S. G.Guardian angel: Patient-centered health information systems. 1994.

TechWeb. Dossia expanding ehr platform reach. 2010.Disponible en http://www.techweb.com/news/225100002/

dossia-expanding-ehr-platform-reach.html (último acceso, Ma-yo, 2010).

Bibliografía 59

W3C. Web services architecture. 2004. Disponible en http://www.w3.org/

TR/ws-arch/#whatis (último acceso, Diciembre, 2013).

W3C. Guía breve de servicios web. 2014a. Disponible en http://w3c.

es/Divulgacion/GuiasBreves/ServiciosWeb (último acceso, Diciembre,2013).

W3C. Guía breve de tecnologías xml. 2014b. Disponible en http:

//www.w3c.es/Divulgacion/GuiasBreves/TecnologiasXML (último ac-ceso, Diciembre, 2013).