Se ha hablado mucho de sistemas de recogidas de datos electrónicos aplicados a la investigación clínica ya no son una novedad y todos conocemos sus ventajas. Pero ¿Qué sabemos de su desarrollo? , ¿Cómo debe implementarse?, ¿Qué aspectos técnicos debe cumplir y de cuáles podemos prescindir?.
Todo aquel que trabaje de forma habitual con estas herramientas tendrá sus preferencias y sabrá decir lo que para él resulta imprescindible. Los requisitos funcionales están claros: una interfaz de usuario amigable, ayudas en la entrada de datos, campos calculados, contenido dinámico, informes en tiempo real, sistemas de detección de errores automáticos, etc. La funcionalidad y la estética de la aplicación resultan partes fundamentales, pero los requisitos que garantizan la seguridad a nivel físico y lógico de los datos resultan partes imprescindibles para garantizar la continuidad de la aplicación. Teniendo esto en cuenta podemos diferenciar los requisitos de una aplicación en tres tipos diferentes:
- requisitos funcionales en el que se incluirían los comentados anteriormente (interfaz de usuario amigable, ayudas en la entrada de datos, campos calculados…)
- requisitos de infraestructura física en el que se incluirían todos los elementos de hardware
- requisitos de lógica y seguridad en el que se incluiría la metodología de desarrollo y la seguridad de la aplicación.
A nivel de infraestructura física el pilar principal a tener en cuenta es la redundancia. Tener los sistemas duplicados posibilita la sustitución del equipo, línea de datos, disco duro,... dañado sin necesidad de interrumpir los servicios y aplicaciones que soporta. En consecuencia un buen proveedor debería contar con: un servidor propio con discos y fuentes de alimentación redundados, dos o más líneas de datos proveídas por compañías telefónicas diferentes que garanticen índices de desconexión prácticamente nulos, sistemas de monitorización de servicios para detectar una posible caída del servidor, sistemas de alimentación ininterrumpida por baterías y generadores eléctricos capaces de suministrar energía a todos los sistemas en caso de caída total de la red eléctrica, copias de seguridad diarias de todos los sistemas (bases de datos, aplicaciones y sistema operativo) que posibiliten una recuperación total del sistema en caso de desastre.
Hablar de la lógica y seguridad resulta algo más complejo, existe una normativa, la 21 CFR part 11, que indica los requisitos mínimos que debe cumplir un sistema de recogida de datos electrónico: auditoría de cambios, registros de acceso, firma electrónica,... pero desde mi punto de vista es demasiado generalista, declara los mismos requisitos para una simple encuesta que para un ensayo clínico con lógica compleja, sistemas de aleatorización electrónica, monitorización online, etc.
Si bien es cierto que por pequeño que sea el sistema ha de cumplir con unos mínimos, también lo es que en función de la complejidad de la aplicación cobra mayor importancia: un diseño modular o escalable que posibilite la incorporación de funcionalidades independientes entre ellas (ej. módulo de aleatorización, módulo de monitorización, etc.) , una arquitectura separada por al menos tres capas (presentación, lógica de negocio y acceso a datos), encapsulación para evitar accesos a datos desde métodos no autorizados, validación de cada uno de los métodos de la aplicación por separado mediante testeos unitarios para garantizar su independencia del resto, utilización del protocolo de internet seguro https para asegurar que la información entre el cliente y el servidor se envíe cifrada, encriptación de los datos del ordenador cliente o cookies, etc.
Es muy posible que de entrada les pueda resultar algo complejo. Mi intención no es que intenten recordar un sinfín de términos informáticos, ni detenerme a explicar técnicas de desarrollo aplicadas a los sistemas de recogidas de datos electrónicos. Sin embargo, sí me gustaría que entendieran y tuvieran en cuenta que dos aplicaciones aparentemente similares pueden resultar radicalmente diferentes; y que un proveedor de servicios puede ser adecuado para desarrollar aplicaciones de recogida de sencillas, pero resultar inadecuado para el desarrollo de aplicaciones de mayor complejidad.