Hola @Felipe_Larraguibel !
Mi impresión general (sin perjuicio de una importante cantidad de otros aspectos que habría que revisar) es que el problema principal de este borrador es que introduce también varias características o criterios que no corresponden a los/las de un producto software, sino que son características de conectividad (ej. latencia), de procesos de una organización (ej. gestión de incidentes de seguridad, planes de contingencia), o características más bien de un servicio que aplicarían solo en los casos en que en que el software fuese proporcionado en modalidad SaaS/Software as a Service etc. y otras que en realidad dependen de cada tipo diferente de implementación (ej. alta disponibilidad), las que incluso podrían darse con un mismo software.
Y lo hace además en abierta contradicción con lo que se declara en el alcance del documento, donde se dice: “Este estándar se aplica exclusivamente a los componentes de software de las plataformas tecnológicas utilizadas para realizar prestaciones de telemedicina”.
¿Qué vamos entonces a querer acreditar? ¿Productos? ¿“Plataformas”? (definir, porque una plataforma podría ser cualquier cosa) ¿Procesos? ¿Servicios? ¿Organizaciones? ¿Una empresa proveedora? ¿Un prestador de salud que usa o implementa una determinada plataforma en su servicio? ¿Algunas o todas las anteriores?
Esto hay que tenerlo bien claro y hay que ser consistentes para que esto pueda funcionar.
Sobre los puntos que señalas en particular, partiendo por el 1. tal vez yo personalmente pensaría que no es necesario que el proveedor de una solución software para la telemedicina tenga que ser también dueño (ej. de la propiedad intelectual) de todos los componentes software que utiliza (siempre que tenga licencia para usarlos e incorporarlos en su solución) ni de los eventuales servicios de terceros que va a utilizar (de hecho, casi siempre vamos a utilizar servicios de terceros, por ej. conectividad, cloud, etc.). Lo importante es que la plataforma resultante cumpla con las características requeridas. Tal vez por eso no sea necesario referirse expresamente a ello. Así que esa parte no me llama particularmente la atención, pero a lo mejor, para dejar las cosas más claras, tal vez se podría de todos modos decir algo al respecto. Yeap.
Sobre el 2. que mencionas, bueno, la verdad es que así como está formulado el tema de la exigencia HD o FullHD etc. no produce ningún efecto real y es totalmente ilusorio pensar que la “plataforma debe garantizar” esas cosas. Ninguna plataforma (por sí sola) puede garantizar que cuando fuera a ser utilizada se logrará realmente una resolución FullHD etc.
¿Por qué? Sencillamente porque lograr eso no depende solo de lo que se pueda hacer del lado de la plataforma: por ej. si el paciente o cualquiera de los actores de una teleconsulta no tuvieran a disposición una cámara o monitor fullHD o lo que fuera.. es obvio que no se podrá lograr eso en esos casos (además que muchas tecnologías se van adaptando de manera dinámica a las condiciones de conectividad, reduciendo también la resolución y también la resolución temporal -i.e. frames por segundo- “runtime” de ser necesario). Y también lo que tu mencionas desde luego, muchos lugares tienen pocos recursos.
Entonces, lo que se podría solicitar a los que proveen la plataforma software es que esta “permita” (no “garantice”!!!) una resolución video de esa naturaleza, cada vez que se den también las otras condiciones necesarias para lograr eso en una prestación de telesalud (es decir, que la plaforma en sí no sea la limitante para alcanzar esas resoluciones cada vez que se pueda). Así lo vería yo.
Bueno, el domingo 5 de abril vence el plazo para enviar retroalimentación.
