Hace 6 años, era el propietario de Medcarelive, mi propia empresa de telesalud. También me convertí en un entusiasta de la telesalud y más tarde en un consultor de telesalud e innovación. Participé en más de 40 proyectos de implantación, desde los grandes en los sistemas de salud y los estados, hasta los pequeños de una sola capa, pasando por el asesoramiento a empresas de plataformas sobre cómo utilizar mejor sus modelos. En los últimos 2 años, formé parte del equipo de innovación sanitaria de Kaiser Southern California, donde aprendí de primera mano la dificultad de utilizar la tecnología y aprovechar la innovación en un gran sistema con necesidades sanitarias complejas.

En 2013, leí un artículo escrito por Hayim Makabee Desarrollador de software veterano, programador entusiasta, y un compañero Influencer innovador. El artículo Simplicidad en el diseño de software: KISS, YAGNI y la Navaja de Occam. trataba realmente de la simplicidad. La simplicidad es un atributo de calidad deseable en cualquier sistema de software, me gusta compartirlos con usted como base para la implementación exitosa del programa de telesalud.

#1 KISS significa «Keep it simple, stupid». Es probablemente uno de los principios más antiguos del diseño de software (pero seguimos olvidándolo). El principio KISS establece que la mayoría de los sistemas funcionan mejor si se mantienen simples en lugar de hacerse complejos; por lo tanto, la simplicidad debe ser un objetivo clave en el diseño y se debe evitar la complejidad innecesaria. Los sistemas de software deben ser mantenidos por desarrolladores humanos con capacidades limitadas, por lo que cualquier aumento de la complejidad de un sistema también aumenta la dificultad para mantenerlo. «Depurar es el doble de difícil que escribir el código en primer lugar. Por lo tanto, si escribes el código de la forma más inteligente posible, no eres, por definición, lo suficientemente inteligente como para depurarlo.» -Brian Kernighan. Si utiliza una plataforma compleja para iniciar su programa de telesalud y añade capas de herramientas, gadgets y otros programas, no sólo lo hace complejo para sus usuarios, sino imposible de mantener y controlar para su departamento de TI.

#2 YANGI significa «No lo vas a necesitar». Es un principio de programación que establece que un programador no debe añadir funcionalidad hasta que sea necesario. «Implementa siempre las cosas cuando las necesites realmente, nunca cuando sólo preveas que las necesitas». – Ron Jeffries

Todo programa de telesalud debe empezar por responder a las siguientes preguntas:

• • ¿Qué problemas intentamos resolver? ¿Qué criterios se van a utilizar para medir el éxito?

• • ¿Quién es el mejor proveedor para realizar la visita? MA, RN, técnico de farmacia, NP, médico.

• • ¿Dónde debe estar el proveedor/paciente? hogar, clínica, hospital, centro

• • ¿Cómo se puede realizar esta visita? ¿Necesito «ojos en este paciente»? ¿Puedo realizar esta visita por teléfono? ¿Podemos hacer telemedicina asíncrona en este caso a través del correo electrónico?

En muchos casos, utilizar el «nivel mínimo de licencia» y el teléfono es más rentable que utilizar «el nivel más alto de licencia y el vídeo». También es crucial tener en cuenta la ubicación del proyecto y las herramientas para medir el éxito.

#3 RAZOR DE OCCAM «Principio de parsimonia, economía o concisión utilizado en la lógica y la resolución de problemas. Establece que entre las hipótesis que compiten entre sí, debe seleccionarse la hipótesis con el menor número de supuestos.» – Michael Lant

Trabajar sobre suposiciones de necesidad frente a la «necesidad aprendida» puede tener un pobre retorno de la inversión y malos resultados. La necesidad de la telesalud no puede basarse en suposiciones. Constantemente escucho afirmaciones como «a todos los pacientes les gustaría hablar con su médico en lugar de acudir a la consulta». Si sólo el 10% de los pacientes puede utilizar un servicio y sólo el 5% se beneficiará de él, ¿merece la pena el esfuerzo y el presupuesto para desarrollar todo un programa en torno a ello? . El bombo y platillo frente a la realidad es el comienzo de muchos programas fallidos en la atención sanitaria y está directamente relacionado con un pobre retorno de la inversión y los resultados. El éxito de la aplicación depende de una evaluación real y precisa de las necesidades, del estudio de la población, de la preparación de los proveedores y de la capacidad de ampliar la escala una vez obtenidos los objetivos. El concepto de «último momento responsable» del desarrollo de software ajustado puede aplicarse fácilmente a la implantación de la telesalud: «Decidir lo más tarde posible: Retrasar al máximo las decisiones hasta que puedan tomarse basándose en hechos y no en suposiciones y predicciones inciertas.»

Como dice Hayim Makabee en su artículo: Creo que el peligro del diseño simplista está muy bien expresado por esta cita: «Hazlo simple, tan simple como sea posible, pero no más simple». – Albert Einstein

Buena suerte.

Sigi marmorstein FNP-BC, directora general de Telehealth Consulting Services, equipo de innovación sanitaria de Kaiser Permanente, enfermera, profesora adjunta, fundadora y presidenta de empresas como Telehealth Conulting Services y Medcarelive.com. Actualmente trabaja en Kaiser Permanente, miembro del equipo de innovación sanitaria dedicado a la expansión de los servicios de telesalud.