¿Prevenir o curar?

28 Jul ¿Prevenir o curar?

Por Albert Oriol
i-wonder: mensaje 67

Cuando los presupuestos para TICs son escasos y hay que decidir si se invierte en un visualizador web de PACS o en una infraestructura de prevención y respuesta en situaciones catastróficas (en inglés ?disaster recovery?), la decisión suele ser siempre la misma: El visualizador de PACS permite a nuestros radiólogos hacer guardias desde casa, interpretar más imágenes y expandir el área de cobertura, responder más rápida y eficientemente, mejorar su satisfacción laboral y aumentar la calidad de la atención al paciente. Es decir, permite añadir ingresos y reducir costes a la organización. Su retorno a la inversión es claro, y rápido.

La infraestructura de prevención, por el contrario, es una inversión para mitigar riesgo, y su retorno no queda claro. En muchos casos es nulo. Como una póliza de seguro, la mayoría de organizaciones que han hecho la inversión esperan no tener que utilizarla.

Pero algunas organizaciones, han aprendido a diseñar una infraestructura de prevención que les da un retorno a la inversión además de darles tranquilidad de espíritu. Una de estas organizaciones es The Children?s Hospital (TCH), en Denver, Colorado, EEUU.

A finales del 2003, TCH embarcó en un proyecto para identificar la aversión al riesgo de la organización y sus necesidades de mitigación teniendo en cuenta la inminente adopción de una historia clínica electrónica. El funcionamiento de la organización y la capacidad operativa del personal clínico pronto dependería totalmente de la disponibilidad de sus sistemas de información. Dos años y medio más tarde, el equipo de sistemas es capaz de restaurar el servicio a los aplicativos clínicos de máxima prioridad con un tiempo de respuesta de 5 (sí, cinco) minutos.

Esta respuesta, que puede parecer exagerada por su rapidez, es el resultado de una arquitectura basada en la innovación . Descartando la arquitectura tradicional, donde una organización con sistemas críticos mantenía un clúster de dos o más servidores en su centro de datos, más un tercero en un centro de datos remoto que se activa en caso de desastres, TCH optó por un modelo de clúster remoto con replicación sincrónica, ahorrando la inversión y el mantenimiento del tercer servidor.

Esta estrategia, ha sido posible gracias al despliegue de una red óptica a un coste asequible, y entre otras cosas, permite a la organización operar sus aplicativos indistintamente desde cualquiera de sus centros de datos (el principal o el remoto). En el pasado, cuando una organización activaba su servidor remoto de emergencia, ésta experimentaba dos momentos de ?downtime?: el primero cuando se pasaba a operar en estado de desastre procesando datos desde el servidor de emergencia y el segundo cuando se revertía a la normalidad. Con el diseño de clúster remoto, no hace falta volver a procesar en el centro de datos principal porque los servidores son igual de robustos a ambos lados (en la arquitectura tradicional el servidor remoto se utilizaba solo en caso de un desastre, y por tanto se construía con una capacidad inferior a los servidores ?normales?).

Este diseño facilita las tareas de mantenimiento  y hará posible que cuando el hospital se traslade a su nueva sede 11 kilómetros al este de su campus actual, los sistemas de información clínicos sigan funcionando incluso durante la mudanza del centro de datos sin la necesidad de alquilar equipos para la transición.

El retorno a la inversión está asegurado, pero la verdad es que en la dicotomía planteada al principio del artículo, hay una pequeña trampa. TCH ya había desplegado su visualizador web de PACS.

¿Prevenir o curar? Tal vez la respuesta adecuada sea ?sí, gracias??

Albert Oriol