# data[].attributes.body
Solo tienen que hacer doble clic sobre el fondo o sobre el círculo rosa en la esquina inferior de la pantalla, y aparecerá el cuadro de texto para escribir.

Al escribir su texto por favor incluir su nombre y apellido en el título.

# data[].attributes.body
En primer lugar destacó la actitud de evaristo de admitir el error de la red del hospital como CIO y compartirlo luego de ya resuelto para que no le suceda a agentes o entendidades.
En segundo lugar también es importante la actitud tomada al momento de darse cuenta de que no podían resolverlo con su equipo interno pedir ayuda a Cisco para que ellos intervengan también para resolver el problema en cuestión.
En tercer lugar la perseverancia a la hora de resolver el asunto, buscando recursos, pidiendo ayuda, hablando con el equipo siempre para el mejor beneficio del hospital.

# data[].attributes.body
Detectar los problemas servirá para que en el futuro este colapso en la red no vuelva a ocurrir. En este caso el día que ocurrió el problema se cargaron a una carpeta compartida los pacs de imágenes, que causo esta congestión. Todo esto causo el colapso de la red.

Los componentes necesarios para resolver este problema fueron un núcleo de red redundante que tiene la función de asegurar la supervivencia de la red ante un fallo. Redes con switches nivel 3 que genera una conmutación más rápida. También controla el ancho de banda y aislar el tráfico pesado antes que colapse la red y plan de recuperación ante desastres que son procesos para recuperar los datos e información, creando copias de seguridad, esto es muy importante cuando existe algún desastre o evento inesperado que comprometa la información, se crean puntos de partida para recuperar los datos y no perderlos

# data[].attributes.body
me parece importante además agregar que los directivos de centros de salud deben contar con un programa alternativo para reducir el impacto que produce la caída del sistema, tratando de disminuir durante este tiempo la pérdida de información, y sobre todo no afectando la calidad de la atención brindada.

# data[].attributes.body
Por un lado me parece que una lección aprendida sería tener un censo actualizado lo más preciso posible de todos los componentes que integran la red del centro médico, sobre todo en relación a lo que se le pretende exigir a la misma, así como una actualización periódica de sus componentes, dentro del marco de los recursos disponibles.
Por otro lado un plan de contingencia en caso de alguna falla que invalide el correcto funcionamiento del sistema es vital para toda institución de salud que no puede darse el lujo de encontrarse no operativa en ningún momento.

# data[].attributes.body
Del caso Evaristo puedo concluir que todo evento adverso es una oportunidad de aprendizaje y de mejora. Puntualmente en esta historia que utilizamos como insumo disparador y de análisis, sin demasiados elementos todavía, pero con la mirada puesta en el futuro, creo que estimar la evolución de la tecnología no es un tema menor, y si la intención del equipo de trabajo es minimizar la posibilidad de ocurrencia de este tipo de episodios, el monitoreo y seguimiento es fundamental, la actualización de la tecnología y procedimientos; así como mencionó un compañero en su posteo, las copias de respaldo que permitan conservar la información, son fundamentales. Creo que intentaría además, estar preparados mediante simulacros de dichos eventos...

# data[].attributes.body
Creo que es un buen caso para tomar de ejemplo y sacar conclusiones que puedan servir como aprendizaje.
Considero que es fundamental en este caso tener en cuenta que el sistema de red en un hospital, sobre todo si se usa para atención al paciente como una "historia clínica electrónica" pasa a ser una herramienta fundamental en la atención médica. No debemos perder de vista que si hay un problema, el principal perjudicado puede ser el paciente.
Para no extenderme demasiado creo que son fundamentales los siguientes aspectos:
- actualización del hardware de la red
- realizar una detallada gestión de riesgos y posibles soluciones (a medida que se avanza con las funciones de la historia clínica o nuevo hardware esto debería actualizarse también)
- plan de contingencia ante la falla de la HCE

personal capacitado a enfrentar crisis,

algoritmo de acción para detectar y repara errores,

algoritmo de acción para la institución

roles claros de los involucrados a resolver la crisis

entrenamientos o simulacros

- tener todos los puntos anteriores escritos bajo protocolos

El objetivo de todo esto es minimizar los tiempos de recuperación y por ende favorece una mejor atención al paciente.

# data[].attributes.body
Aprendí que parte del mantenimiento es  actualizar los equipos y la red según el funcionamiento y crecimiento de la organización.  A tener un plan de contingencia ante la fallas. Actuar sobre los problemas en cuanto surgen, sin creer que soluciones mágicas, y finalmente tener un plan de recuperación de desastre en caso de que todo supere lo previsto.

# data[].attributes.body
Lo primero que aprendí es que por mas experiencia que se tenga como CIO, nunca debemos confiarnos. Otro aspecto a recalcar es que en sistemas de información siempre debe haber una planificación que permita contar con una estructura de TI robusta, eficiente, suficiente y segura, que permita la continuidad de la atención y que vaya creciendo conforme crece la organización y las nuevas tecnologías. Además de contar con la infraestructura y equipamiento necesario según la demanda de las transacciones, el usuario de dicho sistema debe tener protocolos de contingencia en caso de fallos del sistema, el ¿ que hacer en caso de? es imperativo conocerlo por todo el personal.
Por otra parte; aprendí de mis compañeros y sus formas de analizar el caso planteado, las diferentes alternativas de solución a una misma situación.

# data[].attributes.body
Me gustaría destacar el valor de admitir el error para aprender de los mismo aunque el costo fue alto.
La importancia de la actualización constante tanto en el hardware como software y mismo del personal atrás vez de la capacitación continua.
Creación de un plan de contingencia esté servirá para los cortes programados o los inesperados y permitirá que siga funcionando el hospital de forma adecuada. Así mismo copia de seguridad de los archivos para facilitar la recuperación de ellos.

# data[].attributes.body
Como una de las lecciones aprendidas del caso Evaristo es lo importante que es trabajar con protocolos y planes de contingencias que garanticen la continuidad en la atención. Aprendimos que es fundamental el rol del CIO y contar con el apoyo de la Dirección Técnica para responder ante estos casos de tanta magnitud.
Debemos manejarnos con información actualizada acerca del hardware y software que cuenta nuestra organización.
Es indispensable contar con un sistema de monitoreo y realizar simulacros, de modo de garantizar la seguridad de la información y la continuidad del negocio de la organización .

# data[].attributes.body
Aprendí varias cosas:
La importancia del CIO, no solo en experiencia y conocimientos
La importancia del mantenimiento actualizado de los TI en cuanto a infraestructura, software , hardware, etc
La importancia de mantener una gestión de riesgo (AMFE)
La importancia de planes de contingencia actualizados y con realización de simulacros para detectar fallos en los mismos
La importancia de la mejora continua
La importancia de los planes de recuperación
Sistema de monitoreo continuo de redes , dispositivos y disponibilidad del sistema y de  red
Protocolizar según carga de trabajo y horarios para respaldar, cargar imagenes, realizar copias de seguridad , etc
Siempre hay más por hacer y aprender y por actualizarnos

# data[].attributes.body
La principal enseñanza que me deja el caso Evaristo es que por más robusto (que creamos) que es nuestro sistema, siempre hay que contemplar la posibilidad de que el mismo falle, hasta en los centros con más experiencia en tecnología. Si esto ocurre, lo que puede salvarnos de una situación caótica para la institución e insegura para los pacientes es tener un plan de contingencia bien diseñado, con roles definidos y conocido por los usuarios.  Al no tenerlo, Evaristo tuvo que soportar la presión de la responsabilidad de su cargo de CIO, y acompañar a su equipo trabajando contrarreloj para resolver el incidente. Asimismo, supo que era necesario recurrir a ayuda externa para lograrlo, y no dudo en solicitarla. Finalmente, compartió su experiencia con nosotros para que no repitamos sus errores. Otros aprendizajes fundamentales de este tramo fueron la arquitectura de la infraestructura de TI, los niveles del modelo OSI, los componentes de las redes y los conceptos fundamentales sobre seguridad de la información.

# data[].attributes.body
Lo que más destaco del Caso Evaristo son las enseñanzas aprendidas a partir del análisis de los desastres que pueden afectar a nuestros sistemas. Más allá del impacto negativo que generen, son herramientas valiosas de crecimiento, a partir de las cuales, se llevarán a cabo mejoras o ampliarán el escenario de variables a considerar en la planificación de proyectos posteriores.
Reflexionando, gran parte de lo que hacemos y cómo lo hacemos, es gracias al conocimiento previo (propio o a través de terceros) de potenciales riesgos.

# data[].attributes.body
Considero fundamental tener un plan de respuesta a un incidente como el que surgio aqui. La falta del mismo impide evaluar la capacidad de respuesta la velocidad con la que se respondió y los resultados luego de las acciones seguidas acorde a ese plan. Conocer siempre nuestras vulnerabilidades también es de suma importancia, sin olvidar las amenazas permenentes a las redes donde estamos trabajando que pueden ser externas o incluso externas.

# data[].attributes.body
Creo que como lección aprendida, puedo mencionar la importancia del factor previsión, bajado a tierra en un plan concreto, que permita no correr detrás de los sucesos, sino encuadrarlos en una estructura algorítmica que ya tenga asignada funciones y tareas para cada miembro del equipo, con un fin fundamental que está detrás de la informática en salud (IS), que es la salud más o menos urgente de los pacientes que dependen de ella. Esto implica que la misma puede ser la mejor amiga del paciente y el médico, pero a la vez la peor enemiga en caso de fallar, si no hay un plan (como los problemas de la guardia en el caso). Aprendí a que DUDAR sobre la estructura actual, aunque fuera "la mejor", es tan importante como la construcción o utilización de la misma, y a que hay amplia disponibilidad de recursos tecnológicos que permiten apoyar la redundancia de estos circuitos alternativos.

# data[].attributes.body
Algunas de las lecciones aprendidas a partir de este caso y su análisis que me gustaría destacar son:
La importancia de mantener actualizados no sólo la parte de software sino también el hardware, acompasando el crecimiento institucional y el avance de la tecnología. Por otro lado, con el caso se ve que no debemos descuidar ningún riesgo; así como velar por la seguridad de la información, es igualmente importante (y en particular en este ámbito de la salud) que esa información esté disponible en tiempo y forma ya que el proceso asistencial no se puede postergar. También, y en base a esta necesidad, otro aspecto a destacar es la importancia de realizar una buena gestión de riesgos y contar con protocolos de contingencia, que además deben ser ensayados regularmente. Más allá de estos protocolos, creo que se podría evaluar la posibilidad de un ‘plan B’ para acceder a la información; no sé qué tan viable es, pero sería bueno poder contar con una red alternativa o algo desde donde se pudiera al menos sólo consultar la información clínica de los pacientes para no perjudicar la toma de decisiones.. Finalmente, destaco también como aprendizaje la importancia de siempre ante cualquier pequeña falla de los sistemas, detenerse a estudiar a fondo sus causas, más allá de que se haya ‘solucionado’, saber con exactitud qué está pasando y por qué puede prevenir o ayudar en futuros casos.

# data[].attributes.body
La primera lección aprendida es que por mucha experiencia que tenga el CIO, los desastres pueden ocurrir en cualquier momento y ser de cualquier tipo y no siempre se va a estar 100% preparado.

La segunda lección aprendida es contar siempre con un plan de recuperación ante desastres, que contemple varios escenarios posibles y no solo el respaldo de las bases de datos, si no que, ponerse en los casos más extremos como la caída del sistema en forma total.

Y otra lección aprendida es que al incorporar nuevos componentes o dispositivos a la red de datos, o al hardware o al software, debemos asegurarnos que el restos de los elementos que los componen sean capaces de funcionar en conjunto y darles el soporte adecuado.

# data[].attributes.body
La primera lección que aprendí de la lectura de este caso es que nunca hay que subestimar las diferentes situaciones problemáticas que se producen, ya que nunca se sabe cuándo se estará frente a un desastre.

La segunda lección es reconocer que uno no siempre tiene la capacidad para dar una respuesta ante un desastre y por ello es importante pedir ayuda y en lo posible saber a quién  pedir ayuda.

La tercera lección es contar con un plan de contingencia que considere todos los casos posibles, y tratar de mantener la calma, ante todo.

Por ultimo no solo debe tratar de optimizar todo lo relacionado con el almacenamiento de los datos, su seguridad, etc.; sino que se debe optimizar toda la arquitectura de la red, sin dejar de pensar en todos sus componentes.

# data[].attributes.body
Pienso que la lección 1 podría ser que cuando un hospital crece en tamaño, cantidad de pacientes, cantidad de datos que genera, ese crecimiento debe pensarse de forma integral, teniendo en cuenta  el almacenamiento de datos, la seguridad pero también la infraestructura de redes que permite que finalmente esos datos sean accesibles y se conviertan en información para el usuario final. Dado el caráctercrítico que tiene la información médica en un hospital, es un aspecto que no puede descuidarse.

Otra lección podría ser que los hospitales deben estar preparados para las contingencias, en particular en áreas críticas del sistema asistencial como la guardia, el quirófano, laboratorios y las unidades cerradas.  Esa preparación debería incluir con cierta frecuencia simulacros, para que los profesionales se sientan con mayor confianza y seguridad para enfrentar situaciones de este tipo. En el caso de Evaristo, el relato daba cuenta de la falta de entrenamiento del personal médico para manejar la situación de falta de sistema informático, donde los médicos que mejor se adaptaron fueron posiblemente aquellos que habían experimentado en algún momento de su vida profesional hacer su trabajo sin sistema informático.

# data[].attributes.body
El caso Evaristo evidencia la realidad del manejo de la tecnología de la información en el ámbito de un hospital muy grande. En mi caso me permitió tomar un primer contacto con este tipo de estructura y reconocer lo complejo, intrincado y difícil que puede ser migrar desde un tipo de administración anterior. En la medida que se evoluciona implementando el sistema pueden aparecer junto con los beneficios, graves consecuencias. Respecto a las lecciones aprendidas: Una correcta arquitectura de red, basada en reconocimiento del cableado estructurado, puede haber identificado y aislado el problema más rápido. Sin embargo no sé cuán difícil es hacerlo una vez declarada la saturación. Mantener el hardware de red actualizado hubiera permitido acceder a nuevas tecnologías que hubieran impedido el accidente. Además esta actitud es una inversión ya que se pueden abaratar costos por ejemplo de energía en el data center. Se hubieran minimizado los daños ocurridos con un buen plan de recuperación de desastres diseñado previamente. Se debe garantizar la continuidad de las operaciones vitales, evitar la pérdida de información vital, preveer la acción de retroceso para atender los casos médicos urgentes. Esto es necesario ya que este tipo de negocio no admite que pueda discontinuarse. La implementación de tecnologías de información en un hospital moderno es una necesidad vital, es un desafío a emprender aún a costa del riesgo que esto implica.

# data[].attributes.body
Buenas! Antes que nada agradecer el caso de Evaristo, que nos abrió la cabeza a tantos problemas que pueden pasar en el "detrás de escenas" de los sistemas de información.
Coincido en primer lugar que es importante ver estas catástrofes como oportunidades de aprendizaje, evitando "echar la culpa" , y generando protocolos
Aprendí que no solo los cortes de luz y los hackers son amenazas,  sino que hay que prestar atención a todos los niveles, las "capas" (física, acceso a la red, internet , transporte y aplicación... haciendo un mapa del riesgo, identificando las vulnerabilidades y posibles amenazas, elaborando un plan de gestión de riesgos, con su posibles soluciones, y mitigando las amenazas con planes de contingencia. Y algo muy importante es el personal: definiendo roles y entrenando en posibles contingencias.

# data[].attributes.body
A razón de la consigna, considero que hay varias lecciones por aprender.
En primer lugar, me parece importante para futuras intervenciones, tener en cuenta que, cuando se considera la implementación de un sistema informático en una institución, no sólo hay que pensar  en las necesidades actuales de la misma (la institución del "hoy"), sino también en la institución "del futuro", aquella a la que se aspira. Dentro de esta consideración se incluyen todas las necesidades que puedan llegar a ser requeridas. En otras palabras, preveer de forma tal de dejar sentadas las bases para suplir dichas necesidades.  Uno de los problemas que dio origen al "caso evaristo" fue una falla en el diseño de infraestructura, ya que no se consideró que necesidades podrían llegar a surgir.
Otra lección en mi opinión, esta relacionada con tener siempre presente la necesidad de un plan de contigencia. Este plan debe contar con un diseño acorde a la institución, ser claro en las tareas y responsables de las mismas e incluir un cronograma de educació y simulacro del mismo.
En el caso, se comentaba la incertidumbre de muchos profesionales ante la perdida del sistema. La misma, se extendía no sólo a los profesionales "nuevos" (que nunca habían trabajado sin el sistema digital) sino también aquellos que habían trabajado con el sistema en papel, pero hace mucho tiempo. Esta incertidumbre, colaboró en la demora en los procesos de trabajo.
Otra lección aprendida es considerar que, aunque contemos con mucha experiencia en el sector el error siempre puede ocurrir. Ante estas circunstancia es importante contar con un buen equipo de trabajo que este dispuesto a colaborar, a trabajar en conjunto y también  reconocer que, nadie es infalible.
Teniendo en cuenta lo anterior, tener un sistema de monitoreo y de nuevos requerimientos me parece otra lección para aprender.
También  a modo de lección, me parece relevante, tomar el habito de hacer una evaluación posterior al suceso. De esta forma, se puede dejar sentado un precedente de lo ocurrido y de su resolución, a modo de referencia.

# data[].attributes.body
Dentro de las lecciones aprendidas se evidencia la necesidad de una plan de contingencia por cualquier eventualidad que pueda surgir.  Debe estar asegurado el acceso a la información en Salud.
Debe haber monitoreo continuo de la red, deteccion temprana de fallas, y soluciones oportunas.

# data[].attributes.body
Para mi la principal lección es que más allá del desarrollo informático en si mismo y los avances tecnológicos, si no está definido como deben actuar los equipos de trabajo frente a situaciones de contingencia se pone en riesgo un largo trabajo de implementación de las soluciones TI aplicadas a salud. La confianza es un valor muy importante en la implementación de las soluciones digitales en salud, teniendo presente que la gestión del cambio es un proceso lento y sistemático. Frente a una falla del sistema, es muy importante entonces dar las señales claves y en tiempos de respuesta razonables para mantener la confiabilidad del sistema en uso y que de esa forma no se vean amenazadas dichas transformaciones en las organizaciones. El exceso de confianza siempre en un peligro, por ende es fundamental la existencia de un buen plan de contingencia, prestar atención a las alertas y por sobre todo que dicho plan sea monitorizado y puesto en práctica en casos de prueba para asegurar que los equipos tienen la capacidad de respuesta que se espera.

# data[].attributes.body
Lección principal es tener presente constantemente la Ley de Moore.
El constante crecimiento de la tecnología y la necesidad de su actualización.
Sumado al aumento de las prestaciones, incorporación de tecnología, por ejemplo en diagnósticos,  y mayor numero de terminales es imprescindible su constante actualización.
Elaboración de un protocolo, en el cual se deberían determinar las vulnerabilidades, amenazas potenciales de eventos, respuesta ante el evento, determinar prioridades para el funcionamiento de la institución
Personal capacitado para afrontar los eventos.

# data[].attributes.body
La primer lección aprendida es que ¨Todos los sistemas pueden fallar, ya que están expuestos a riesgos y pueden ser vulnerados¨ . Partiendo de esto, se debe trabajar de forma continua en el mantenimiento y actualización de los componentes del sistema (Software y Hardware), como también en el componente humano del mismo (Capacitación y actualización de los conocimientos del personal que forma parte del equipo de IT).
La segunda lección que interpreto es que en el proceso de Gestión de Riesgos, se debe incluir un (Plan de recuperación ante desastres), para la recuperación y/o restauración de los datos perdidos o dañados, una vez solucionado el problema del SIS. También interpreto que se debe contar con un (Plan de Respuesta a Incidentes) para minimizar y reducir los daños potenciales que estos puedan producir, no solo al sistema, si no al funcionamiento de toda la institución, ya que se debe tener en cuenta que la misma debe contar con un plan de contingencias para poner en marcha en caso de fallas o mantenimientos programados del SIS.
La tercera y ultima lección es la de compartir los conocimientos adquiridos en los procesos de investigación, sean casuales, buscados o por error, para así enriquecer el conocimiento universal y poder avanzar en un mejor, mayor y plural conocimiento. Esto es lo que hizo Evaristo.

´´La experiencia ajena, no duele y no cuesta´´

# data[].attributes.headline
He aprendido a tener en cuenta todos los componentes que hacen al sistema de información. 

# data[].attributes.subject
He aprendido a tener en cuenta todos los componentes que hacen al sistema de información. 

# data[].attributes.body
He aprendido algunas diferencias entre las partes del hardware y el software y la relevancia de mantener  el circuito vigilado y monitoreado periódicamente.
Además, la relevancia de tener un plan de contingencia que contemple todas las posibles fallas y errores, ya sean internos o externos.
Es importante tener un equipo de trabajo que se maneje con canales de comunicación fluidos y constantes ante emergencias y catástrofes y que se planifiquen medidas de sostén en caso de ser necesarias
.

# data[].attributes.body
Una de las lecciones aprendidas del caso Evaristo es con respecto a la seguridad, la cual no solo hace referencia a la confidencialidad e integridad de la información sino también a la disponibilidad de la misma. Evaristo, reconoció que su atención estaba puesta en el Datacenter y en el crecimiento de la capacidad de almacenamiento y no así en el poder tener acceso a la misma. Otra entidad a tener en cuenta es la arquitectura de la red, la cual debe estar acorde a las necesidades.

Y desde mi punto de vista la lección fundamental es estar preparado para las posibles eventualidades ya sean tanto amenazas como vulnerabilidades. Es imprescindible contar con un plan de recuperación ante desastres, un protocolo que guie los pasos a seguir hasta la restauración del status quo.

# data[].attributes.body
Como lei en varios posts, teniendo en cuenta que lo principal para una "empresa" es poder seguir prestando servicios y disminuir la perdida economica que una caida total del sistema puede generar, debe tener un plan de contingencia para mitigar los riesgos y debe contar con un plan de recuperacion ante desastres para volver al funcionamiento normal lo mas pronto posible.
Respecto a lo que es la arquitectura de los sistemas de informacion, el concepto de escalable me parece fundamental, monitorizando la necesidad de modificar los componentes en las distintas capas del modelo OSI, teniendo en cuenta los requerimientos ( en constante aumento por parte de los usuarios), de mayor utilizacion de datos.

# data[].attributes.body
Algunas de las lecciones aprendidas con el caso Evaristo son:

- Es indispensable contar con un buen plan de contingencia para caídas de red. Este debe incluir cual es el procedimiento a seguir así como la función bien definida que va a cumplir cada uno de los que va a participar.

- Es recomendable capacitar constantemente a todos los integrantes del sector de sistemas acerca de las nuevas tecnologías ya que estas cambian relativamente rápido y teniendo conocimiento de ellas se puede generar una arquitectura de red cada vez mas eficiente de la manera mas organizada posible sin afectar el funcionamiento diario de la red . A su vez, considero que tener una arquitectura de red lo mas organizada y diagramada posible, optimiza la detección de problemas.

- El registro de todas las acciones realizadas sobre la red, ya sean físicas o digitales, me parece fundamental para evitar confusiones entre distintos miembros de la organización.

# data[].attributes.body
El caso Evaristo deja muchas lecciones aprendidas sobre el manejo de la información en un sistema de información de salud (SIS) como es el del hospital Medical Center. Algunas que son importante destacar son la importancia de adoptar un conjunto mínimo de controles de seguridad, confeccionar un plan de respuesta a incidentes y un plan de contingencia, generar un equipo de trabajo que abarque todas las áreas involucradas, definir un plan de recupero ante desastres, revisar continuamente los componentes de la red y tener una correcta comunicación dentro de la institución.

Teniendo en cuenta que el SIS de la institución se basa en una red, desde su confección es importante trabajar sobre la premisa de que algo puede fallar, y, esta falla tiene más o menos probabilidad de suceder. La confección de una red incluye varios elementos, aplicaciones, softwares y hardwares, por lo cual es importante establecer prioridades para el armado de cada una de sus contingencias.

Al estar trabajando con información es importante que la institución trabaje sobre un plan de seguridad para proteger la información y sus sistemas, logrando así, reducir las probabilidades de que un evento suceda o disminuir su impacto. Es importante formular un plan de respuesta a incidentes y probarlo regularmente. Este último es importante para minimizar o detener el incidente, investigarlo, restaurar los recursos afectados e informar el incidente a los canales apropiados. Se busca evitar o minimizar las consecuencias de alto costo e impacto que sucedieron al no tener activo el SIS en la institución.

Establecer un plan de contingencia es imprescindible, implica una respuesta planificada a un riesgo identificado que ha superado su mitigación. El plan de contingencia tiene en cuenta cuales son los elementos que pueden fallar, la probabilidad de ocurrencia, el impacto y su tiempo y costo de resolución. El cableado estructurado es uno de los primeros puntos a tener en cuenta en una contingencia ya que ante una falla, su reparación implica tiempo y un alto costo. Para evitar que la red se caiga también es importante tener dos switch/routers en vez de una.

El desarrollo de un plan de contingencia implica la conformación de un equipo de trabajo que cuente al menos con informáticos de seguridad, auditoría, usuarios que pueden afectarse por la contingencia y los responsables de normativas y procedimientos. El tener un equipo consolidado con diferentes puntos de vista y responsabilidades es fundamental para cubrir todas las áreas que pueden verse comprometidas ante una contingencia. El plan generado debe tener como objetivo que la institución pueda continuar con la operatividad dentro de un marco contenido, minimizando el impacto ante la falta de disponibilidad del sistema.

Teniendo en cuenta que una falla puede tener un alto impacto, es importante duplicar los datos para salvar una contingencia. Lógicamente la duplicación de datos no es completa ya que esto implica un alto costo, por lo tanto es importante realizar un balance teniendo en cuenta los costos y beneficios que implica tener los datos duplicados.

Al activar un plan de contingencia se debe definir quién o quiénes son los responsables de activar la entrada en contingencia teniendo en cuenta la estimación de tiempo que se requiere para la solución del problema. Al tomar esta decisión se debe comunicar correctamente a todos los involucrados, todos los usuarios deben estar informados de cuando inicia la contingencia y cuando finaliza. Se debe tener definido dónde y cómo se registra la información durante la contingencia.

Al tener un plan de contingencia, también lo que debería tenerse en cuenta es la vuelta al uso normal del SIS. La vuelta atrás es uno de los procesos más difíciles, para esto es importante que el datacenter sea completo y contingente, para que esto sea así solo debe existir otro igual esperando entrar en acción, siendo entonces poco o nada redundante. Para realizar una correcta vuelta atrás es esencial tener un plan de recupero ante desastres (DRP) en donde se informa como se realiza técnicamente la recuperación de la infraestructura al nivel operativo normal. El DRP implica un proceso mediante el cual se recuperan datos, es importante para que los usuarios sepan cómo actuar ante un desastre para que la institución no colapse y se reduzcan las consecuencias al mínimo.

# data[].attributes.body
Para mi la principal lección es que más allá del desarrollo informático en si mismo y los avances tecnológicos, si no está definido como deben actuar los equipos de trabajo frente a situaciones de contingencia se pone en riesgo un largo trabajo de implementación de las soluciones TI aplicadas a salud. La confianza es un valor muy importante en la implementación de las soluciones digitales en salud, teniendo presente que la gestión del cambio es un proceso lento y sistemático. Frente a una falla del sistema, es muy importante entonces dar las señales claves y en tiempos de respuesta razonables para mantener la confiabilidad del sistema en uso y que de esa forma no se vean amenazadas dichas transformaciones en las organizaciones. El exceso de confianza siempre en un peligro, por ende es fundamental la existencia de un buen plan de contingencia, prestar atención a las alertas y por sobre todo que dicho plan sea monitorizado y puesto en práctica en casos de prueba para asegurar que los equipos tienen la capacidad de respuesta que se esp

# data[].attributes.body
El caso Evaristo, nos sirve para reflexionar sobre todos los posibles puntos de filtración que se pueden dar en un sistema de salud. Y que consecuencias se ponen en juego frente al quiebre de ese  sistema. 
Por ejemplo, tener un plan de contingencia, frente  a la saturación de datos, y la consecuente caída del sistema. Tener la planificación para este tipo de circunstancia, ya que se puede ver con un “efecto mariposa”. Donde un problema surgido en el sector de imágenes, por la sobrecarga de datos, hace que se llegue a suspender cirugías y dejar de atender pacientes.
Para ellos se deben contar con instrucciones escritas de trabajo para cada una de las áreas.  Contar con personal capacitado, y que manejen en forma certera la resolución de problemas y conflictos diarios. Que se monitoree en forma cotidiana, y que sirva de entrenamiento constante para el nuevo personal. Hacer simulacros periódicos frente a posibles problemas, estudiando las posibles soluciones. 
Puntualmente para Evaristo, se debe marca, la humildad de decir, que el problema lo superó, y que buscó ayuda, para poder solucionar el tema, ya que se pone en juego, el funcionamiento general de la clínica. Y que no descanso hasta que se soluciono. Y más allá de lo estrictamente técnico, se pudo solucionar ya que se trabajo en equipo.

# data[].attributes.body
Hola a todos! Al llegar tarde a esta pizarra, tuve ocasión de leer los aprendizajes de cada uno. Yo también aprendí muchas cosas..., ya que no me había cuestionado nunca acerca del SIS... Ni de su infraestructura, ni de sus partes, ni de sus procesos.
Pero como hay que puntualizar destaco, como muchos, la necesidad de trabajar con un plan de contingencia que, además de afrontar y solucionar posibles eventos negativos dentro del sistema, nos permita evaluar el crecimiento y por tanto las nuevas necesidades del sistema, tanto de software, como de hardware.
Me gustaría destacar también que, en lo personal, me fue de mucha utilidad adentrarme en la lectura de la bibliografía con la mente puesta en un caso concreto.

# data[].attributes.body
Buenas tardes, creo que el principal error y que nos sirve como experiencia, es que tanto Evaristo como las autoridades de la Clínica, se confiaron y dejaron de preocuparse, creyendo que si algo funciona bien hoy funcionará bien siempre. Si bien la clínica no es una empresa de negocios o proyectos que deban ser resguardados celosamente, ellos deberían ser conscientes que maneja información vital, tanto para su funcionamiento como para la privacidad de sus pacientes, si hubieran pensado en eso, deberían   saber que jamás uno debe dejar de supervisar , controlar , actualizar, tanto sus recursos informáticos (hardware y software), como a su personal para que el mismo esté preparado y sepa como actuar ante un evento semejante.
Al igual que en la medicina,  siempre es mejor prevenir que curar, ir subsanando problemas a medida que ocurren es una muy mala estrategia y muy costosa.
De todas maneras hay que destacar el esfuerzo en equipo realizado por el personal luego de declararse el evento. Si bien a mi opinión, quizas no estuvo aplicado de la manera más eficiente, siempre se mantuvo la calma y no se entró en pánico cosa que hubiera dificultado aún mas la situación y que creo que es importante en esos casos y ésta es una segunda lección,  siempre tratar de pensar con claridad.
Personalmente me ha gustado mucho la metodología de aprendizaje aplicando los conceptos en un caso y he aprendido que al igual que en la medicina siempre hay que considerar muchos diagnósticos diferenciales en un principio y jamás ir por un solo camino, siempre hay que tener un plan B o un camino alternativo. (otro de los tantos errores que surgieron en la clínica y su deficiente o inexistente plan de contingencia)

# data[].attributes.body
Del Caso de Evaristo puedo decir que como primer aprendizaje me llevo la importancia del correcto funcionamiento de un sistema de red cuando, de el depende, un efector de salud, con lo que esto implica, y  por tal motivo la necesidad de contar con un plan de contingencia adecuado, ordenado, preestablecido y ensayado.
También destacar que por lo menos en el caso presentado, la persona a cargo, el CIO, Evaristo, entendió la urgencia de resolver y solicitar ayuda externa, aun cuando esto fuese una mancha en su trayectoria y no dudo en compartir su experiencia, sabiendo que de los errores también uno se lleva aprendizaje muy valioso.
En cuanto a la infraestructura de TI  la importancia de ir actualizando  la arquitectura de la red sobre todo si es un sistema en constante crecimiento y expansión.
El trabajo en equipo como en cualquier especialidad o profesión debe ser entendido por todos sus integrantes, es muy importante que desde la individualidad se comprenda la importancia de los roles de cada uno sin subestimar la experiencia del otro y lo que puede aportar.
Desde lo estrictamente personal aprendí mucho lenguaje, me sirvió el glosario para ir incorporando palabras nuevas y para empezar a entender los componentes de los sistemas de red y sus atributos, totalmente desconocidos para mi.
Muchas gracias

# data[].attributes.body
Me parece importante destacar que en cualquier sistema informático (computadoras, red, etc) se deben hacer análisis periódicos para determinar si se encuentran adaptadas al volumen y al tipo de datos que se manejan. Es de público conocimiento que la cantidad de datos se va incrementando, lo que puede provocar una saturación de los sistemas y llevar a la falla de los mismos.
También es importante recalcar que ante el valor de los datos que se procesan en la red y ante la permanente posibilidad de fallas que puede haber, siempre es necesario establecer un plan de respuesta ante la falla, ya que la corrupción de los datos pueden llevar a la falla total del servicio.
Por ultimo, es importante destacar el trabajo en equipo que debe realizarse en el mantenimiento de los sistemas de información, ya que, como dice el refrán, dos cabezas piensan más que una

# data[].attributes.body
Para mi una de las lecciones aprendidas es no haberse actualizado y seguir utilizando equipamiento antiguo, siendo que aumentó el flujo y tamaño de la información en la institución, que ya demandaba de otro tipo de tecnología. Por otra parte siempre tenemos que definir un Plan ante Desastres y realizar una Evaluación de riesgos para identificar y evaluar posibles amenazas que podrían afectar el óptimo funcionamiento de las plataformas de TI.

# data[].attributes.body
Evaristo nos regala un panorama del que podemos aprender para saber como fortalecer los sistemas de información hospitalarios y los planes mejora de su funcionamiento.

Desde mi entendimiento, el componente tecnológico hospitalario se debe basar en la identificación de todas políticas, reglamentos, recursos y condiciones basadas en tecnología, que permiten el procesamiento, depósito y difusión de información y la tecnología de la información y comunicación.

De la experiencia adquirida con el caso de Evaristo, es importante que consideremos los componentes importantes en el diagnóstico descriptivo como es el diseño lógico de la organización, los recursos y las actividades que permiten la operación del componente tecnológico, la arquitectura y las aplicaciones tecnológicas, la plataforma electrónica de la comunicación virtual, los criterios, tipo de datos y normas para cada módulo o sistema específico que se usan en la red de datos hospitalaria, incluyendo aspectos de lenguaje computacional e interfaces entre lenguajes, también considerar el flujo e intercambio de la información virtual entre diversos niveles, áreas y dónde y cómo se almacenan los datos e información (incluidas copias de seguridad). Las normas, criterios escritos y los reglamentos nos ayudaran a conservar la calidad, confidencialidad, conectividad, seguridad y funcionamiento continuo del sistema.

La evaluación continua y el mantenimiento necesario nos ayuda a enfrentar eficazmente cualquier emergencia, así como el manejo de la tecnología de la información, y las responsabilidades y funciones específicas de todos aquellos que participan en el proceso de producción de información, aquí la existencia de mecanismos de evaluación y control del recurso tecnológico y de la calidad de su operación son fundamentales y deben estar involucrados además de quienes intervienen en la operación, los tomadores de decisiones como la alta dirección. Considero que el caso de Evaristo nos ayuda a entender la necesidad de tener y aplicar estándares de calidad en los procesos técnicos, una continua supervisión de la infraestructura tecnológica hospitalaria y el involucramiento de los tomadores de decisiones en los temas técnico que por lo general son de desconocimiento o poco entendimiento.

# data[].attributes.body
Veo varias posibles lecciones aprendidas:
- En una Institución de Salud, es indispensable un plan de contingencia con varios escenarios posibles de fallas, hasta el nivel de la falla total y la existencia de procediemientos alternativos en papel ante una falla catastrofica, que deberia ser de baja probabilidad pero estar contemplada
- Es indispensable el entrenamiento del personal en los planes de contingencia y la existencia de simulacros
- Es indispensable la existencia de equipamiento redundante para reemplazar equipos vitales para el funcionamiento de la red como son: servidores, switches, hubs, etc
- Es indispensable contar con personal de IT idoneo que pueda monitorear en tiempo real el funcionamiento y performance de los distintos componentes de la red del Hospital. Y que este personal pueda actuar de manera proactiva y preventiva ante síntomas de alguna falla y evitar que éstas crezcan en gravedad

# data[].attributes.body
Me gustaría partir diciendo que me encantó el enfoque práctico de este tramo, creo que el caso fue preciso para poder ir afianzando el conocimiento y también algo muy cercano a lo que enfrentamos día a día, quizás no tan catastrófico, pero si a menudo registramos diferentes incidencias que hacen que el trabajo sea dinámico.

Sobre lecciones aprendidas de este caso muchas, primero lo relevante que es que al aplicar una mejora, abrir un nuevo servicio, expandirse, etc. tener en cuenta que debemos tener una infraestructura concordante a este cambio. Habitualmente las organizaciones se enfocan mucho en mejorar solo partes del hardware, pero lo que permite la conectividad muchas veces queda relegado.

También creo importante diseñar planes robustos de contingencia que permiten afrontar este tipo de situaciones y algunas más leves. Hacer simulacros continuos y asegurar que el personal esté entrenado y conocimiento de cómo deben actuar.

Por último, la comunicación entre los equipos debe ser realmente efectiva. En ciertas partes del caso se evidencia que se desconocían muchas actividades realizadas por otros usuarios dentro de la institución o con los prestadores externos. Creo que aunque las actividades sean mínimas y parecieran no tener gran impacto, debiesen existir sesiones breves semanales entre los departamentos para transparentar este tipo de cosas.

A modo personal puedo decir que esto me hizo mucho sentido ya que viví algo muy parecido cuando en uno de mis trabajos se intento hacer el upgrade de middleware. En ese minuto no tenía tanto conocimiento en como se inter- relacionaban los sistemas, pero esta unidad despejó muchas de las interrogantes que me hice en ese instante.

# data[].attributes.body
Lo primero que aprendí es cuan compleja puede llegar a ser   la arquitectura de un sistema como el referido en el caso, la cantidad de componentes y la posibilidad de que fallen en una o varias etapas , aprendí de la necesidad de la implementación de sistemas de seguridad , de la necesidad de auditar y modernizar tanto el Hardware como el software en forma periódica , pero lo que mas me llamo la atención es la dependencia de todos equipos de salud  a un único sistema informático desconociendo la posibilidad de un fallo y por lo tanto a la  ausencia de preparación para la contingencia , no solo del equipo encargado del soporte del sistema , sino también del equipo medico.