Información de la revista
Vol. 34. Núm. 2.Marzo 2014
Páginas 0-272
Compartir
Compartir
Descargar PDF
Más opciones de artículo
Vol. 34. Núm. 2.Marzo 2014
Páginas 0-272
DOI: 10.3265/Nefrologia.pre2014.Jan.12115
Acceso a texto completo
Aproximación metodológica al diseño de un sistema de teleasistencia para pacientes en prediálisis y diálisis peritoneal
Methodological approach to designing a telecare system for pre-dialysis and peritoneal dialysis patients
Visitas
11088
Jorge Calvillo Arbizua, Jorge Calvillo-Arbizub, Laura María Roa Romeroc, Laura M. Roa-Romerob, José A. Milán Martínd, José A. Milán-Martíne, Nuria Aresté Fosalbaf, Nuria Aresté-Fosalbag, Fernando Tornero Molinah, Fernando Tornero-Molinai, Manuel Macía Herasj, Manuel Macía-Herask, Nicanor Vega Díazl, Nicanor Vega-Díazm
a Grupo de Ingenier??a Biom??dica, Universidad de Sevilla, Sevilla, Spain,
b Grupo de Ingenier??a Biom??dica; CIBER-BBN, Universidad de Sevilla,
c Grupo de Ingenier??a Biom??dica, Universidad de Sevilla; CIBER-BBN, Sevilla, Spain,
d Nefrolog??a, Hospital Universitario Virgen Macarena. Grupo de Ingenier??a Biom??dica, Universidad de Sevilla; CIBER-BBN, Sevilla, Spain,
e Grupo de Ingenier??a Biom??dica; CIBER-BBN. Universidad de Sevilla, Servicio de Nefrolog??a. Hospital Universitario Virgen Macarena, Sevilla,
f Nefrologia, Servicio de Nefrolog??a, Hospital Universitario Virgen Macarena, Sevilla, Spain,
g Servicio de Nefrolog??a, Hospital Universitario Virgen Macarena, Sevilla,
h Nefrolog??a, Hospital Sureste de Madrid, Madrid, Spain,
i Servicio de Nefrolog??a, Hospital Sureste de Madrid,
j Nefrologia, Hospital Universitario Ntra. Sra. de Candelaria, Santa Cruz de Tenerife, Islas Canarias, Spain,
k Servicio de Nefrologia, Hospital Universitario Nuestra Se??ora de Candelaria, Santa Cruz de Tenerife,
l Nefrologia, Hospital Universitario Dr. Negr??n, Las Palmas de Gran Canaria Islas Canarias, Spain,
m Servicio de Nefrolog??a, Hospital Universitario Doctor Negr??n, Las Palmas de Gran Canaria
Este artículo ha recibido
11088
Visitas
Información del artículo
Resumen
Texto completo
Bibliografía
Descargar PDF
Estadísticas
Figuras (3)
Mostrar másMostrar menos

Antecedentes: Un importante obstáculo que dificulta el despliegue de soluciones tecnológicas en sanidad es el rechazo que encuentran los sistemas desarrollados por los usuarios que tienen que utilizarlos (ya sean profesionales sanitarios o pacientes), que consideran que no se adaptan a sus necesidades reales. Objetivos: (1) Diseñar una arquitectura tecnológica para la asistencia remota de pacientes nefrológicos aplicando una metodología que prime la implicación de los usuarios (profesionales y pacientes) en todo el diseño y desarrollo; (2) ilustrar cómo las necesidades de los usuarios pueden ser recogidas y respondidas mediante la tecnología, aumentando el nivel de aceptación de los sistemas finales. Métodos: Para obtener las principales necesidades que existen actualmente en Nefrología se implicó a un conjunto de servicios españoles de la especialidad. Se realizó una recogida de necesidades mediante entrevistas semiestructuradas al equipo médico y cuestionarios a profesionales y pacientes. Resultados: Se extrajeron un conjunto de requisitos tanto de profesionales como de pacientes y, paralelamente, el grupo de ingenieros biomédicos identificó requisitos de la asistencia remota de pacientes desde un punto de vista tecnológico. Todos estos requisitos han dado pie al diseño de una arquitectura modular para la asistencia remota de pacientes en diálisis peritoneal y prediálisis. Conclusiones: Este trabajo ilustra cómo es posible implicar a los usuarios en todo el proceso de diseño y desarrollo de un sistema. Fruto de este trabajo es el diseño de una arquitectura modular adaptable para asistencia remota de pacientes nefrológicos respondiendo a las preferencias y necesidades de los usuarios pacientes y profesionales consultados.

Palabras clave:
Diseño de sistemas
Palabras clave:
Telemedicina

Background: A major obstacle that hinders the implementation of technological solutions in healthcare is the rejection of developed systems by users (healthcare professionals and patients), who consider that they do not adapt to their real needs. Objectives: (1) To design technological architecture for the telecare of nephrological patients by applying a methodology that prioritises the involvement of users (professionals and patients) throughout the design and development process; (2) to show how users’ needs can be determined and addressed by means of technology, increasing the acceptance level of the final systems. Methods: In order to determine the main current needs in Nephrology, a group of Spanish Nephrology Services was involved. Needs were recorded through semi-structured interviews with the medical team and questionnaires for professionals and patients. Results: A set of requirements were garnered from professionals and patients. In parallel, the group of biomedical engineers identified requirements for patient telecare from a technological perspective. All of these requirements drove the design of modular architecture for the telecare of peritoneal dialysis and pre-dialysis patients. Conclusions: This work shows how it is possible to involve users in the whole process of design and development of a system. The result of this work is the design of adaptable modular architecture for the telecare of nephrological patients and it addresses the preferences and needs of patient and professional users consulted.

Keywords:
System design
Keywords:
Telemedicine
Texto completo

1. INTRODUCCIÓN

 

La aplicación de las tecnologías de la información y las comunicaciones (TIC) en el dominio sanitario ha revolucionado la práctica asistencial en todas sus áreas y especialidades. En Nefrología, la aplicación de las TIC puede dotar de capacidades avanzadas a la asistencia, tales como, por ejemplo, el control remoto de pacientes en hemodiálisis, la monitorización de las sesiones de diálisis para la detección temprana de problemas, la transmisión de datos y mensajes desde el hogar a la organización sanitaria o el desarrollo del riñón artificial1-4. Estos avances aún no están implantados en la práctica asistencial principalmente porque existen diversos obstáculos que dificultan la aplicación efectiva de las TIC. Uno de ellos es el rechazo que encuentran los sistemas desarrollados por los usuarios que tienen que utilizarlos (ya sean profesionales sanitarios o pacientes), que consideran que no se adaptan a sus necesidades reales1,5,6.

Al margen de las capacidades avanzadas que puede suponer la aplicación de las TIC, otro beneficio a menudo discutido es la mejora en la eficiencia de los procesos asistenciales y la reducción de los costes asociados7,8. Un ejemplo a favor de la telemedicina para pacientes en diálisis peritoneal es9 que esta técnica supone un ahorro de gastos en transporte sanitario y obtiene una respuesta favorable por parte de los pacientes. Dado el envejecimiento poblacional, la consecuente demanda creciente de servicios sanitarios y la actual coyuntura económica, este tipo de técnicas que optimizan recursos y mejoran la relación coste-eficiencia de la práctica asistencial se hace indispensable. Este hecho es particularmente acuciante en Nefrología, debido a que el tratamiento sustitutivo renal tiene costes altos y un nivel elevado de exigencia desde el punto de vista de la organización10,11.

Con todo ello, la aplicación efectiva de las TIC en sanidad, aunque puede aportar beneficios en varios niveles (organizacional, asistencial, etc.), impone numerosos y complejos requisitos pertenecientes a muy diversas disciplinas (tecnología, asistencia sanitaria, gestión de recursos, etc.). Algunos de ellos son:

  • La sostenibilidad debe ser una de las claves de los desarrollos, primando soluciones con alta tasa de coste-eficiencia. Es decir, se ha de tratar de aplicar la tecnología más adecuada (y no la más novedosa) con respecto a las necesidades particulares del problema12,13.
  • En un entorno tan fragmentado como el sanitario, los sistemas deben integrarse y cooperar entre sí tratando de reducir el impacto de sistemas aislados. La interoperatividad es un requisito necesario para el avance de los sistemas de información sanitarios con capacidades avanzadas14.
  • Debe fomentarse la continuidad de la asistencia a través de fronteras administrativas, regionales y temporales. La práctica asistencial es cada vez más distribuida y compartida entre organizaciones separadas. La continuidad de la asistencia, íntimamente relacionada con aspectos de interoperatividad técnica y organizativa, es un requisito clave para potenciar la calidad de los servicios asistenciales15.
  • Dada la alta sensibilidad de la información que se maneja en este ámbito (principalmente datos administrativos y de salud), la protección de los sistemas y la confidencialidad de las comunicaciones son requisitos indispensables para cualquier aplicación de TIC en sanidad16.
  • Finalmente, desde un punto de vista clínico, un aspecto clave en el desarrollo de soluciones TIC debe ser la implicación de los usuarios en todo el proceso de diseño y como evaluadores de los desarrollos. A menudo se obvian las aportaciones de los usuarios (ya sean profesionales sanitarios o pacientes) en el diseño y el desarrollo de los sistemas, resultando en aplicaciones tecnológicas que encuentran enormes rechazos por parte de ellos debido a que no se adaptan a los métodos de la práctica diaria o a que presentan una usabilidad limitada17.

La complejidad que supone cubrir y satisfacer un espectro tan amplio y heterogéneo de requisitos (los anteriormente mostrados son solo una muestra) es uno de los principales obstáculos para el desarrollo de soluciones eficientes y completas. La aplicación de las TIC en sanidad siguiendo un enfoque metodológico será clave para lidiar con dicha complejidad, permitiendo además hacer efectivos nuevos escenarios de asistencia, reducir costes y mejorar los procesos asistenciales.

Teniendo en cuenta la situación actual del sistema sanitario español, se ha desarrollado un proyecto denominado e-Nefro18 en el que se pone en práctica una metodología de aplicación TIC en sanidad que prima la implicación de los usuarios en todas las etapas de diseño y desarrollo. En el apartado 2 se explica la metodología, así como los aspectos fundamentales sobre los que se sustenta. En el apartado 3 se describe brevemente el objetivo de esta iniciativa, se exponen los requisitos extraídos de los usuarios y los expertos, y se presenta una primera aproximación al diseño del sistema. En el apartado 4 se resumen las conclusiones.

 

2. METODOLOGÍA DE APLICACIÓN DE LAS TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIONES EN SANIDAD

 

El dominio de las metodologías de diseño y desarrollo de sistemas TIC ha crecido exponencialmente en las últimas décadas y actualmente existen multitud de enfoques metodológicos con distintos propósitos (desarrollo de software y/o hardware, por ejemplo), modos de operación (en cascada, iterativos, etc.) o aspectos fundamentales (usabilidad, experiencia de usuario, sostenibilidad, etc.)19.

Uno de los factores que más afectan al éxito de las aplicaciones TIC en sanidad es el entendimiento imperfecto entre las partes implicadas en el diseño, desarrollo y uso de los sistemas, especialmente cuando se establecen los requisitos de los usuarios. Cualquier sistema de información necesita poner al usuario en el centro del diseño. Esto se aplica con mayor énfasis en el dominio sanitario y principalmente cuando los sistemas están directamente implicados en la asistencia sanitaria de los pacientes, pudiendo ser estos usuarios del sistema (aparte de los usuarios profesionales). Reconocer a los usuarios finales como participantes clave a involucrar en todas las etapas del diseño y desarrollo de los sistemas puede contribuir a que estos tengan mayores oportunidades de éxito una vez desplegados y en uso.

La implicación de los usuarios y la consideración de sus necesidades en los procesos de diseño y desarrollo son aspectos ampliamente reconocidos, pero aún no está muy claro cómo se llevan a la práctica20. Existen diversas filosofías de trabajo que tratan de implicar a los usuarios en los procesos de diseño, como el diseño centrado en el usuario21, el diseño participativo22, el diseño para todos (el cual potencia la inclusión de todos los tipos de usuarios)23 o el diseño centrado en la persona (que se aborda en la norma ISO 9241-210)24. Entre los beneficios de las propuestas centradas en el usuario y aplicadas al dominio sanitario figuran: mayor seguridad del paciente, mejores resultados de la práctica asistencial y mayor satisfacción de los usuarios25,26.

Fruto del análisis de metodologías de propósito general se plantea un método de aplicación de las TIC en el dominio sanitario (figura 1). Este enfoque metodológico tiene en cuenta principios de diseño considerados como buenas prácticas en la normativa aplicable24. Estos son:

  • Entender a los usuarios, las tareas y los escenarios. Ante cualquier diseño hay que tener claro qué perfiles tienen quienes van a utilizar el sistema. Así, no solo se deben tener en cuenta los diferentes tipos de usuarios (pacientes, profesionales sanitarios, cuidadores, etc.), sino también el grado de conocimiento digital y sanitario (lo que comúnmente se conoce en inglés como digital and health literacy) que puede presentar cada uno. El sistema, por tanto, deberá adaptarse a las necesidades, los usos y las preferencias de cada usuario con sus características particulares.
  • La implicación del usuario en el diseño y el desarrollo: proporciona una valiosa fuente de conocimiento sobre el contexto de uso y cómo los usuarios prefieren trabajar con el sistema en desarrollo.
  • Ciclo de diseño y desarrollo basado en iteraciones incrementales. Al final de cada ciclo se obtendrá un prototipo completamente funcional y validado, aunque no con todas las capacidades del sistema final que se busca desarrollar. La primera fase de cada ciclo es una revisión incremental en la que se define el alcance del prototipo a desarrollar en ese ciclo y se analizan los objetos desarrollados hasta el momento. Es una fase con un doble propósito: permite planificar el ciclo siguiente especificando exactamente qué partes del sistema van a ser desarrolladas y, además, sirve como fase de evaluación del proceso mejorando su eficiencia, al buscar y corregir errores cometidos en los ciclos anteriores.
  • Evaluación continua y centrada en el usuario. A menudo la etapa final de desarrollo de un sistema comprende su evaluación y es en ese momento donde aparecen fallos y errores que difícilmente son subsanables en una fase tan avanzada. Por ello la evaluación debe asumirse desde el principio del proyecto como una parte integral de este. También se mejora la robustez del sistema al ir adquiriendo conocimiento y experiencia de los posibles fallos y de cómo solucionarlos, lo que permite una especial atención y previsión de alternativas adecuadas cuando la avería pueda tener consecuencias sobre la asistencia al paciente.
  • Como se ilustra en la figura 1, nuestra propuesta metodológica comienza con una recogida de necesidades por parte de los usuarios (teniendo en cuenta la gran heterogeneidad de potenciales usuarios) y de los requisitos tecnológicos definidos por el equipo de desarrolladores. Con todos ellos se realiza un primer diseño del sistema para la primera iteración, se desarrolla y se valida con los usuarios. Este ciclo continúa añadiendo funcionalidad al sistema hasta que se alcance la solución completa.

    A continuación, se describe la aplicación de esta metodología al proyecto e-Nefro, cuyo objetivo es el diseño y desarrollo de un sistema de teleasistencia para pacientes en prediálisis y diálisis peritoneal.

     

    3. APLICACIÓN DE LA METODOLOGÍA A UN CASO DE EJEMPLO: EL PROYECTO E-NEFRO

     

    El proyecto e-Nefro (Arquitectura modular adaptable para la teleasistencia integral de pacientes renales)18 es un esfuerzo multicéntrico entre la Universidad de Sevilla y diversos hospitales nacionales, cuyo objetivo es establecer una arquitectura extensible y adaptable para la asistencia remota de pacientes en prediálisis y diálisis peritoneal. Se está llevando a cabo mediante la metodología presentada en el apartado anterior, con los usuarios con un rol activo en el diseño y el desarrollo de la solución final. Buscando implicarlos en el desarrollo de los sistemas a aplicar, el primer paso fue determinar las principales necesidades que existen actualmente en un conjunto de servicios de Nefrología españoles a partir de las experiencias y el punto de vista de los nefrólogos y los propios pacientes. Esta recogida de necesidades y requisitos se realizó en tres etapas:

  • Entrevistas semiestructuradas con el equipo médico: en ellas se conoció la realidad de la asistencia sanitaria a pacientes en diálisis peritoneal y prediálisis en España y se profundizó en las posibles necesidades e intereses del equipo médico.
  • Cuestionarios a profesionales (nefrólogos y enfermería) y pacientes (en prediálisis y diálisis peritoneal): se llevaron a cabo con la intención de extraer sus experiencias en los distintos servicios y entender cuáles son, desde sus diferentes puntos de vista, las necesidades asistenciales y tecnológicas actuales. Esta modalidad de consulta permitió una recogida de información diferida (no se precisaba contacto directo entre el equipo de diseño y los usuarios) y poder así abarcar diferentes servicios nacionales separados geográficamente, con la idea de tener información multicéntrica, reduciendo el posible sesgo de experiencias locales. Los servicios de Nefrología implicados fueron los pertenecientes a: Hospital Sureste de Madrid, Hospital Universitario Doctor Negrín de Gran Canaria, Hospital Universitario Nuestra Señora de Candelaria de Tenerife y Hospital Universitario Virgen Macarena de Sevilla. En la figura 2 se muestran los bloques de preguntas de los que constaban los cuestionarios.
  • Paralelamente a las anteriores consultas, se realizó una revisión bibliográfica para añadir a los resultados obtenidos otra información publicada en este campo1-3,7,12.
  • Por otro lado, el equipo de desarrollo, compuesto principalmente por expertos en ingeniería biomédica, estableció los principales requisitos tecnológicos a los que tendría que hacer frente el sistema y su infraestructura de soporte. Estos requisitos se muestran en el apartado 3.2.

     

    3.1. Aspectos independientes de la tecnología: el punto de vista de los usuarios

     

    Las entrevistas y los cuestionarios permitieron extraer dos conjuntos de requisitos: aquellos provenientes de los usuarios profesionales y los identificados por los usuarios asistidos. En este apartado se describen brevemente los resultados más relevantes de esta tarea de recolección de necesidades.

    En primer lugar, los profesionales sanitarios entrevistados y encuestados opinan que, mediante el uso de la tecnología, se podría incrementar la eficiencia de su labor asistencial, aunque identifican diversos obstáculos y deficiencias que dificultan dicho proceso de mejora. Entre los requisitos que plantean y que podrían ser resueltos por la tecnología están:

  • La capacidad de acceder a registros de los usuarios asistidos completos y fiables, así como a datos del usuario asistido actualizados en tiempo real en cualquier momento. Uno de los retos primordiales que debe resolver la tecnología (según el 92 % de los profesionales entrevistados) es el de integrar de forma coherente toda la información relacionada con cada paciente, sea cual sea su naturaleza (pruebas diagnósticas, medicación, episodios asistenciales pasados, partes de quirófano, etc.), de manera que un profesional pueda disponer de toda esa información y hacer uso de ella de forma ubicua en cualquier instante.
  • La recepción de eventos críticos en tiempo real, evitando además ser inundados con intervenciones/alarmas no críticas (este aspecto requerirá que cada profesional configure las alarmas que desea recibir y su nivel de prioridad). Los profesionales abogan por el uso de la mensajería móvil como canal de comunicación con los pacientes (61,5 %) también para recibir alarmas o eventos anómalos que requieran una pronta respuesta (53,77 %). El correo electrónico es, asimismo, interesante para los profesionales sanitarios siempre que no se trate de asuntos urgentes (61,5 %). Tanto este requisito como el anterior están íntimamente relacionados con la fuerte componente de movilidad que posee la asistencia sanitaria, que obliga a los profesionales a desplazarse por la organización sanitaria, lo que dificulta su disponibilidad para una comunicación telefónica tradicional.
  • La posibilidad de acceder a información útil (con una visualización de esta flexible de acuerdo a las necesidades y preferencias de cada usuario profesional) para evaluar la evolución de los pacientes. Otro elemento que se considera interesante para la asistencia remota de los pacientes es la comunicación directa entre el paciente y el médico, con posibilidad de hacer una consulta mediante videoconferencia y transmitir datos remotamente sin necesidad de desplazamientos ni consultas presenciales (indicado por el 83 % de los profesionales encuestados).
  • De los cuestionarios a los usuarios asistidos se extrae que el diseño y desarrollo de un sistema de asistencia remota a pacientes en prediálisis y diálisis peritoneal debe considerar:

  • La capacidad de monitorizar y transmitir de forma automática condiciones sanitarias y ambientales, así como la de notificar de manera automática o bajo demanda del usuario situaciones de emergencia que deriven en una solicitud de intervención o una consulta al médico. Si bien el 92 % de los encuestados considera adecuada la frecuencia de las consultas presenciales (en general de dos meses), la mayoría de los pacientes incide en la importancia de un canal de comunicación en el período entre consultas para que el médico esté al tanto de la evolución del paciente (71 %) y para comunicar alarmas o eventos anómalos (85 %).
  • La posibilidad de comunicarse fácilmente con profesionales sanitarios y cuidadores de forma flexible de acuerdo a las necesidades y preferencias de cada usuario asistido. La frecuencia en la que el médico podría recibir información del paciente puede depender en gran medida de la voluntad de este último (por ejemplo, frecuencia con la que evalúa sus parámetros fisiológicos y rellena un formulario vía web). Los resultados muestran que la voluntad de los pacientes de enviar esa información explícitamente es baja (la mitad de los encuestados acordarían enviar los datos una vez al mes, mientras que solo el 35 % estaría dispuesto a hacerlo una vez por semana). Se concluye que un parámetro de diseño crucial es la automatización del proceso de recogida de variables fisiológicas y el envío a la organización sanitaria de forma transparente al usuario.
  • La posibilidad de recibir información útil sobre el tratamiento de su enfermedad y visualizar la evolución de sus datos sanitarios, indicado como deseable por el 92 % de los usuarios encuestados. Es interesante destacar que los pacientes, aun cuando desean recibir información concerniente a su salud y al tratamiento de su enfermedad, expresan la voluntad de hacerlo solo cuando haya algo interesante y no con una frecuencia fija (así es expresado en el 72 % de los casos). Esto se traduce en la necesidad de que cada paciente especifique qué considera interesante y qué no, y así establecer un sistema de información personalizable y adaptado a las preferencias concretas de cada uno. A pesar de esto, siempre deberán ser los profesionales los que en última instancia decidan sobre la frecuencia con la que los pacientes deben ser informados (o reentrenados) en el tratamiento de su enfermedad, compensando así la escasa voluntad que pueden presentar aquellos que sean malos cumplidores.
  •  

    3.2. Aspectos dependientes de la tecnología

     

    De forma paralela al estudio de las necesidades de los profesionales y los pacientes, el grupo de ingenieros biomédicos realizó un análisis desde un punto de vista tecnológico de la asistencia remota de pacientes. El escenario descentralizado de asistencia sanitaria que viene dado por la monitorización remota de los pacientes en prediálisis y diálisis peritoneal en su hogar impone un conjunto de requisitos tecnológicos a las soluciones a desarrollar. A continuación se enumeran los más relevantes:

  • Acceso remoto: los componentes van a estar distribuidos geográficamente, luego la infraestructura debe facilitar esta comunicación.
  • Concurrencia y asincronía: los componentes han de poder ejecutarse en paralelo y no existir dependencias entre unos y otros en actividades de comunicación (por ejemplo, un paciente puede enviar datos desde su domicilio sin necesidad de que su médico esté simultáneamente conectado en el hospital para recoger los datos).
  • Disponibilidad: los canales de comunicación han de estar disponibles en todo momento para no interrumpir la provisión de servicio de los componentes.
  • Heterogeneidad: los componentes del sistema o sistemas pueden estar construidos sobre distintas tecnologías, y estas incluso cambiar en el tiempo. La infraestructura debe facilitar la comunicación entre componentes heterogéneos a través de la provisión de interoperatividad técnica, sintáctica y semántica.
  • Transparencia de complejidad al usuario final: usuarios pacientes y profesionales han de estar completamente al margen de la complejidad inherente a las comunicaciones de los diferentes sistemas.
  • Fiabilidad en la distribución de mensajes: la infraestructura debe asegurar una fiabilidad b ásica en la distribución y entrega de los mensajes. Pueden existir mecanismos de priorización de mensajes (por ejemplo, datos frente a alarmas) que se basen en sus requisitos de fiabilidad.
  • Escalabilidad de dispositivos, servicios y usuarios: el sistema ha de diseñarse asegurando que un aumento del número de componentes en un sistema, de sistemas o de usuarios es asumible sin pérdida en la calidad de servicio de las comunicaciones.
  • Confidencialidad (de la transmisión), seguridad (protección de la información del usuario de otros no autorizados) y privacidad (derecho del usuario de controlar la diseminación de su información personal).
  • Relación coste/beneficio sostenible: el último requisito de diseño es la necesidad de idear un sistema económica y ambientalmente sostenible.
  •  

    3.3. Diseño de una arquitectura tecnológica para la asistencia remota de pacientes en prediálisis y diálisis peritoneal

     

    Dados los requisitos tecnológicos y de los usuarios, la arquitectura que se ha de diseñar presenta una enorme complejidad. El uso de un software de intermediación (middleware) que proporcione elementos y capacidades que permiten resolver la mayoría de los requisitos de los sistemas distribuidos posibilita simplificar dicha complejidad. Uno de los paradigmas de diseño de sistemas distribuidos más extendido, la arquitectura orientada a servicios (SOA)27, establece un modelo arquitectural que busca la agilidad, eficiencia y productividad del sistema, así como los servicios como su componente fundamental. La principal característica de SOA es que es independiente de la tecnología subyacente de implementación. Aplicando este paradigma se facilita la satisfacción de los requisitos funcionales relacionados con la operación, distribución y heterogeneidad de los sistemas. El sistema se configura como servicios que, por su propia definición, son unidades autónomas y físicamente independientes (requisitos de concurrencia y asincronía). Además el uso del paradigma de publicación y descubrimiento de servicios en el que se basa SOA satisface los requisitos de distribución, escalabilidad y heterogeneidad. Sobre este software de intermediación (que consistirá en una implementación tecnológica de SOA como pueden ser las tecnologías de servicios web28), se desarrollarán los servicios específicos del dominio de aplicación, es decir, de teleasistencia domiciliaria para pacientes en prediálisis y diálisis peritoneal.

    Para construir una arquitectura flexible que sea adaptable a distintos escenarios y tenga capacidad de evolucionar en el tiempo, lo más adecuado es seguir un diseño modular en el que la arquitectura se descompone en sistemas cooperantes y autónomos, cada uno centrado en una funcionalidad concreta y con la posibilidad de sustituir o añadir módulos sin necesidad de modificar toda la arquitectura. En la figura 3 se muestra un esquema de dicha arquitectura, que se compone de una infraestructura de comunicaciones (que recaerá principalmente en la middleware) y un conjunto de sistemas, cada uno centrado en aspectos concretos de la arquitectura completa. Cada subsistema está compuesto a su vez de módulos o servicios que engloban funcionalidades concretas. Se define un sistema de infraestructura (SI), que recoge la funcionalidad básica de comunicación entre el domicilio del paciente y el hospital (módulo de teleasistencia), entre hospitales (módulo interhospitalario) y de protección de datos y control de la privacidad (módulo de seguridad). El SI proporciona los componentes tecnológicos básicos que sustentan la comunicación de datos entre sistemas (envío de medida de variables desde el domicilio al hospital, trasvaso de historiales de pacientes entre hospitales, etc.), así como diferentes modos de comunicación entre personas (mensajería, videoconferencia, etc.).

    El sistema de entornos de acceso (SEA) agrupa toda la funcionalidad relacionada con las interfaces de los usuarios asistidos y especializados, así como de los profesionales sanitarios. Estos módulos permiten personalizar el acceso a los servicios de la arquitectura según las preferencias de los usuarios, sus limitaciones y sus permisos autorizados. El SEA cubrirá la gestión y el cumplimiento de las preferencias que cada usuario tenga para el acceso a los servicios de la plataforma. Algunas de estas preferencias podrán ser: la frecuencia de recepción de nueva información, el conjunto de eventos de alerta que desea recibir o los parámetros de la interfaz acordes a posibles limitaciones funcionales de los usuarios (tamaño de letra, uso de software de lector de pantalla limitación auditiva, etc.).

    El objetivo del sistema de seguimiento (SS) es el de proveer a la arquitectura las capacidades de envío, recepción y consulta de datos entre el hogar del paciente y las organizaciones sanitarias, valiéndose de los mecanismos del SI tanto para la comunicación como para la seguridad. Además, se incluyen en este sistema todos los servicios específicos de la asistencia de pacientes en prediálisis y en diálisis peritoneal. La configuración remota de dispositivos y el acceso a los datos que recaban también se llevaría a cabo en este sistema. En él se incluirán, por un lado, los dispositivos que automáticamente recojan variables fisiológicas del usuario y las envíen al hospital y, por otro, los sistemas de información que permitan al usuario asistido (y especializado) a través de un ordenador o dispositivo móvil estar al tanto de las actividades determinadas por los profesionales en su plan de cuidados. También los profesionales podrán a través de diversos dispositivos (móviles, tabletas u ordenadores) estar al tanto de las incidencias que ocurran a sus pacientes, intercambiar mensajes con ellos y adaptar el plan de cuidados de cada uno, permitiendo hacer un seguimiento continuado de la terapia.

    Por último, el sistema de proveedor de servicios (SPS) complementa la arquitectura con un conjunto de servicios añadidos de propósito general dentro del entorno sanitario. Estos servicios aportan valor añadido al sistema y pueden ser proporcionados por uno o varios proveedores. En este sistema se pueden encontrar aquellos destinados al procesamiento de datos, la gestión de alarmas (notificándolas a los usuarios pertinentes de acuerdo con los protocolos definidos para cada una) y las herramientas de generación de conocimiento (sistemas de apoyo a la decisión clínica, simulación mediante modelos matemáticos, etc.).

    Vemos que los módulos, aunque autónomos y separados, están íntimamente relacionados entre sí. Así, por ejemplo, cuando un usuario accede al sistema se consulta el módulo correspondiente del SEA para recuperar cómo desea el usuario acceder a la información y cómo debe esta presentarse. Previamente habrá que consultar al módulo de seguridad para que autorice el acceso el usuario al sistema e indique qué funcionalidad está disponible para él. En función del servicio que vaya a utilizar el usuario, se hará uso de módulos del SS o del SPS.

    Una vez diseñado el sistema, el siguiente paso consistirá en un proceso iterativo e incremental de desarrollo en el que la implicación de los usuarios finales será una constante, así como una garantía de aceptación una vez el sistema esté desarrollado. Cabe destacar que los aspectos de usabilidad de los dispositivos y sistemas desarrollados están contemplados en etapas subsiguientes de la metodología y se abordarán en el proyecto cuando se comiencen a diseñar las interfaces y dispositivos de usuario final.

     

    4. CONCLUSIONES

     

    Una de las claves principales para la aceptación de los sistemas por parte de los usuarios finales (profesionales y pacientes) es partir de sus necesidades concretas e implicarlos en todo el proceso de diseño y desarrollo. Este requisito metodológico ha sido puesto en práctica en el proyecto e-Nefro, el cual tiene como objetivo establecer una arquitectura extensible y adaptable para la asistencia remota de pacientes en prediálisis y diálisis peritoneal. Para el estudio de necesidades se realizaron un conjunto de entrevistas y cuestionarios a profesionales y pacientes, cuyos resultados se han presentado en este trabajo.

    De los resultados se han extraído diversos requisitos. Los pacientes desean: monitorizar y transmitir automáticamente sus condiciones sanitarias entre consultas, pero sin tener que participar activamente, estar en contacto con sus médicos, principalmente para notificar situaciones de emergencia, y recibir información sobre el tratamiento de su enfermedad de acuerdo a sus preferencias. Por su parte, los profesionales sanitarios identifican las siguientes necesidades: la capacidad de acceder a registros de los usuarios asistidos completos y fiables, así como a datos del usuario asistido actualizados en tiempo real en cualquier momento, la recepción de eventos críticos en tiempo real, evitando además ser inundados con intervenciones/alarmas no críticas, y la posibilidad de acceder a información útil (con una visualización de esta flexible de acuerdo a las necesidades y preferencias de cada usuario profesional) para evaluar la evolución de los pacientes.

    Estas necesidades de los usuarios, unidas a los requisitos tecnológicos identificados por los desarrolladores, han llevado al diseño de una arquitectura modular adaptable a los distintos escenarios existentes y a las preferencias de usuarios pacientes y profesionales. Sobre esta arquitectura se desarrollarán los servicios particulares de asistencia remota de usuarios en prediálisis y diálisis peritoneal, aunque su flexibilidad permitirá reutilizarla en cualquier otra especialidad y escenario clínico.

     

    Conflictos de interés

     

    Los autores declaran que no tienen conflictos de interés potenciales relacionados con los contenidos de este artículo.

    Figura 2. Esquemas de los cuestionarios utilizados para profesionales sanitarios y pacientes.

    Figura 3. Arquitectura modular para la teleasistencia de pacientes en prediálisis y diálisis peritoneal.

    Figura 1. Metodología de aplicación de las tecnologías de la información y las comunicaciones en sanidad incremental y centrada en los usuarios.

    Bibliografía
    [1]
    Kaldoudi E, Vargemezis V. Renal telemedicine and telehealth - Where do we stand? IFMBE Proc 2010;29:920-3.
    [2]
    G??mez-Martino JR, Su??rez MA, Gallego SD, Gonz??lez PM, Covars?? AR, Castellano IC, et al. Telemedicina aplicada a la nefrolog??a: otra forma de consulta. Nefrologia 2008;4:407-12.
    [3]
    Musso C, Aguilera J, Otero C, Vilas M, Luna D, de Quir??s FG. Informatic nephrology. Int Urol Nephrol 2013;45:1033-8. [Pubmed]
    [4]
    Ronco C, Davenport A, Gura V. The future of the artificial kidney: moving towards wearable and miniaturized devices. Nefrologia 2011;31:9-16. [Pubmed]
    [5]
    Mair FS, May C, O'Donnell C, Finch T, Sullivan F, Murray E. Factors that promote or inhibit the implementation of e-health systems: an explanatory systematic review. Bull World Health Organ 2012;90(5):357-64. [Pubmed]
    [6]
    May CR, Finch TL, Cornford J, Exley C, Gately C, Kirk S, et al. Integrating telecare for chronic disease management in the community: what needs to be done? BMC Health Serv Res 2011;11:131. [Pubmed]
    [7]
    Mark DA, Fitzmaurice GJ, Haughey KA, O'Donnell ME, Harty JC. Assessment of the quality of care and financial impact of a virtual renal clinic compared with the traditional outpatient service model. Int J Clin Pract 2011;65(10):1100-7. [Pubmed]
    [8]
    Kumar G, Falk DM, Bonello RS, Kahn JM, Perencevich E, Cram P. The costs of critical care telemedicine programs: a systematic review and analysis. Chest 2013;143(1):19-29. [Pubmed]
    [9]
    Gallar P, Guti??rrez M, Ortega O, Rodr??guez I, Oliet A, Herrero JC, et al. Utilidad de la Telemedicina en el seguimiento de los pacientes en di??lisis peritoneal. Nefrologia 2006;26(3):365-71. [Pubmed]
    [10]
    Arrieta J. Evaluaci??n econ??mica del tratamiento sustitutivo renal (hemodi??lisis, di??lisis peritoneal y trasplante) en Espa??a. Nefrologia 2010;1(Supl Ext 1):37-47.
    [11]
    Parra Moncasi E, Arenas Jim??nez MD, Alonso M, Mart??nez MF, G??men Pardo A, Rebollo P, et al. Estudio multic??ntrico de costes en hemodi??lisis. Nefrologia 2011;31(3):299-307. [Pubmed]
    [12]
    Connor A, Mortimer F, Tomson C. Clinical transformation: the key to green nephrology. Nephron Clin Pract 2010;116(3):c200-5.
    [13]
    Connor A, O'Donoghue D. Sustainability: the seventh dimension of quality in health care. Hemodial Int 2012;16(1):2-5. [Pubmed]
    [14]
    de la Torre I, Gonz??lez S, L??pez-Coronado M. Analysis of the EHR systems in Spanish Primary Public Health System: the lack of interoperability. J Med Syst 2012;36(5):3273-81. [Pubmed]
    [15]
    EN 13940 ?? Health informatics ?? System of concepts to support continuity of care, 2007.
    [16]
    ISO 27799 - Health informatics - Information security management in health using ISO/IEC 27002, 2008.
    [17]
    Blackburn SJ, Cudd PA. A discussion of systematic user requirements gathering from a population who require assistive technology. Technol Disabil 2012;24(3):193-204.
    [18]
    PI11/00111 - Arquitectura modular adaptable para la teleasistencia integral de paciente renales (e-Nefro). FIS, Instituto de Salud Carlos II. 2012-2014.
    [19]
    Wikipedia. Metodolog??as de desarrollo de software. Availabe at: http://es.wikipedia.org/wiki/Metodolog????a_de_desarrollo_de_software (accessed 25 April 2013).
    [20]
    Martin JL, Barnett J. Integrating the results of user research into medical device development: insights from a case study. BMC Med Inform Decis Mak 2012;12:74. [Pubmed]
    [21]
    Usability Professionals?? Association. User-centered design. Available at: http://www.usabilityprofessionals.org/usability_resources/about_usability/what_is_ucd.html (accessed 25 April 2013).
    [22]
    CPSR. Participatory Design. Available at: http://cpsr.org/issues/pd/ (accessed 25 April 2013).
    [23]
    Emiliani PL, Stephanidis C. Universal access to ambient intelligence environments: opportunities and challenges for people with disabilities. IBM Syst J 2005;44(3):605-19.
    [24]
    ISO 9241 - Ergonomics of human-system interaction -- Part 210: Human-centred design for interactive systems, 2010.
    [25]
    Gosbee J. Human factors engineering and patient safety. Qual Saf Health Care 2002;11(4):352-4. [Pubmed]
    [26]
    Martin JL, Clark DJ, Morgan SP, Crowe JA, Murphy E. A user-centred approach to requirements elicitation in medical device development: a case study from an industry perspective. Appl Ergon 2012;43(1):184-90. [Pubmed]
    [27]
    Erl T. SOA: principles of service design. 5.?? ed. Upper Saddle River New Jersey: Prentice Hall; 2009.
    [28]
    Booth D, Haas H, McCabe F, Newcomer E, Champion M, Ferris C, et al. Web Services Architecture. W3C recommendation. 2004.
    Idiomas
    Nefrología

    Suscríbase a la newsletter

    Opciones de artículo
    Herramientas
    es en

    ¿Es usted profesional sanitario apto para prescribir o dispensar medicamentos?

    Are you a health professional able to prescribe or dispense drugs?

    es en
    Política de cookies Cookies policy
    Utilizamos cookies propias y de terceros para mejorar nuestros servicios y mostrarle publicidad relacionada con sus preferencias mediante el análisis de sus hábitos de navegación. Si continua navegando, consideramos que acepta su uso. Puede cambiar la configuración u obtener más información aquí. To improve our services and products, we use "cookies" (own or third parties authorized) to show advertising related to client preferences through the analyses of navigation customer behavior. Continuing navigation will be considered as acceptance of this use. You can change the settings or obtain more information by clicking here.