CareGroup Caso 4

Para uso exclusivo de A.
Chica
9 - 303- 097
R E V : AU G U S T 1 1, 2 0 0 5
F. WA RR EN MC FA RL AN RO BERT D . AU S T IN
CareGroup
"Las buenas noticias", informó John Halamka, CIO de CareGroup, cuando abrió su presentación el 21 de noviembre de
2002 ante la junta directiva, "es que la atención médica no sufrió". Durante los siguientes 20 minutos, Halamka relató una
notable historia que explicaba por qué los sistemas de tecnología de la información (TI) de CareGroup se habían derrumbado
por completo durante tres días y medio la semana anterior, los miembros del personal de pasos y los vendedores habían
tomado para recuperarse, y cómo el hospital había vuelto a los sistemas basados en papel, muchos de los cuales no se habían
utilizado durante una década o más. Aunque su historia contenía desafíos y dificultades, al final los sistemas basados en
papel y los esfuerzos de recuperación habían funcionado bien. La atención a algunos pacientes se había retrasado, pero no
se había notificado ni un solo evento adverso relacionado con la interrupción. Aun así, se aprendieron numerosas lecciones
y se agregaron algunas partidas al presupuesto de TI; Halamka ahora delineó esto para la junta.
CareGroup
CareGroup fue un equipo de profesionales de la salud dedicados a proporcionar la mejor atención de calidad a los
pacientes de una manera altamente personalizada. CareGroup y sus miembros ofrecieron un amplio espectro de servicios
de salud a los residentes del este de Massachusetts en una variedad de entornos, que van desde centros de salud académicos
de renombre mundial y hospitales comunitarios excepcionales hasta oficinas médicas y centros de salud comunitarios. Los
miembros del hospital de CareGroup incluyeron Beth Israel Deaconess Medical Center en Boston, Mount Auburn Hospital
en Cambridge, New England Baptist Hospital (NEBH) en Boston, Deaconess-Glover Hospital en Needham, y Deaconess-
Nashoba Hospital en Ayer. Con más de 13.000 empleados y 2.000 empleados médicos, CareGroup ofreció atención
primaria basada en la comunidad y una amplia gama de servicios especializados cerca de donde las personas vivían o
trabajaban.
CareGroup se formó en una fusión a tres plazos el 1 de octubre de 1996. El Hospital Beth Israel, el Hospital Deaconess y
el Hospital Mount Auburn se reunieron ese día. Los hospitales Beth Israel y Deaconess, que eran físicamente adyacentes, se
fusionaron en un solo hospital; cada departamento se fusionó y encabezaba un individuo (por ejemplo, las dos unidades
quirúrgicas se fusionaron y se nombró a un jefe de cirugía). El Hospital Mount Auburn, ubicado en Cambridge, informó a
la gerencia de CareGroup como una entidad separada, al igual que otros cuatro hospitales que anteriormente habían sido
parte de la Red Pathway, reunidos durante la década anterior por la deaconess Hospital. (Véase Prueba documental 1
para el organigrama de CareGroup y la Prueba documental 2 para las descripciones de los diferentes hospitales.)
Los profesores F. Warren McFarlan y Robert D. Austin prepararon este caso. Los casos de HBS se desarrollan únicamente como base para la discusión en
clase. Los casos no pretenden servir como endosos, fuentes de datos primarios o ilustraciones de una gestión eficaz o inefica z.
Derechos de autor © 2003 Presidente y Becarios de la Universidad de Harvard. Para pedir copias o solicitar permiso para reproducir materiale s, llame al
1-800-545-7685, escriba Harvard Business School Publishing, Boston, MA 02163, o vaya a http://www.hbsp.harvard.edu. Ninguna parte de esta
publicación puede ser reproducida, almacenada en un sistema de recuperación, utilizada en una hoja de cálculo, o transmitida de ninguna forma o por
cualquier medio (electrónico, mecánico, fotocopiado, grabación o de otra manera) sin el permiso de Harvard Business School.
Este documento está autorizado para su revisión por parte de Adolfo E. Gal sólo hasta julio de 2015. Copiar o publicar es una infracción de los derechos de autor.
Permissions@hbsp.harvard.edu o 617.783.7860
Chica
CareGroup
Esta fusión produjo un grupo hospitalario con $1.600 millones en ingresos, el segundo grupo más grande de hospitales en
el este de Massachusetts. La fusión fue impulsada por el intenso entorno competitivo a mediados de la década de 1990. El
13 de diciembre de 1994, la comunidad médica de Massachusetts se sorprendió al descubrir que los dos hospitales más
grandes y prestigiosos de Boston, el Hospital General de Massachusetts y el Hospital Brigham and Women, habían acordado
fusionarse en una compañía holding estructura llamada Socios. La presión percibida que esta gran organización iba a ser
capaz de poner en las organizaciones de mantenimiento de la salud (HMO, que se encontraban entre los pacientes
individuales y los empleados y los hospitales y médicos) llevó a muchos hospitales a concluir que tenían masa subcrítica en
cuanto a su número de "vidas cubiertas"; en este nuevo mundo, necesitarías una masa crítica para obtener los precios de
supervivencia de los HMO (cuantas más vidas cubiertas tuvieras, más te necesitaban los HMO). Los hospitales sentían que
necesitaban un poder de negociación agrandado para hacer retroceder contra los HMO, que a su vez estaban bajo una gran
presión financiera de empresas de la región como FleetBank y Raytheon que estaban tratando de reducir su costos médicos.
Específicamente, los factores que unieron a CareGroup fueron:
1. El poder de contratación que necesitan los hospitales contra los HMO
2. La posibilidad de desarrollar servicios integrados en todos los hospitales que podrían mejorar la calidad de la
atención y reducir los costos
3. La necesidad de un balance sólido en una compleja guerra de precios, en la que había más del 40% de camas
hospitalarias en exceso en la región. Debido a este exceso de suministro, algunos hospitales estaban cerrando sus puertas.
Durante los siguientes siete años, bajo el liderazgo de dos CEOs, CareGroup trató de lidiar con estos temas. Un breve
resumen de los progresos realizados incluiría las siguientes observaciones:
1. Fue una época de extraordinaria presión financiera para CareGroup. Primero el Hospital Mount Auburn, que
había sido rentable durante más de 15 años, de repente produjo una pérdida de 10 millones de dólares y tuvo que rediseñar
sus operaciones. Justo cuando se recuperó, Beth Israel Deaconess comenzó a perder cantidades significativas de dinero. No
fue hasta mediados de 2002, bajo el liderazgo de un nuevo CEO, Paul Levy, que comenzó a recuperarse. Aproximadamente
en ese mismo momento, el Hospital Bautista de repente incurrió en una pérdida de $20 millones, lo que llevó al
nombramiento de una nueva administración allí. A principios de 2003, estos problemas estaban en gran parte detrás de
CareGroup. Cada hospital del grupo estaba encabezado por un CEO diferente al momento de la fusión, y los problemas de
estabilidad financiera se estaban desvaneciendo en el pasado.
2. La coordinación operativa en los hospitales había resultado extremadamente difícil debido a su historia de independencia.
Sin embargo, la sinergia financiera en términos de menores costos de la deuda había sido una característica fuerte. Del
mismo modo, la contratación conjunta con los OME ha tenido mucho éxito.
3. Un éxito inesperado fue el desarrollo de un sistema tecnológico integrado que uniera a todo el grupo. El sistema fue
ampliamente sobretratado a nivel nacional; fue considerado no sólo el mejor en la atención de la salud, sino también uno
de los mejores en cualquier industria.
En 2003, la alta dirección de CareGroup consistió en un director ejecutivo/director legal, un director financiero y un
CIO. En los últimos años, uno de los hospitales subsidiarios, Waltham Hospital, se había encuentra con dificultades, y la
Junta de CareGroup había comenzado el proceso de cerrarlo. Esto llevó a un especialista en bienes raíces a intervenir y, a
cambio de un tercio de las tierras del hospital, proporcionar a Waltham fondos adicionales que le permitieron emerger como
una organización independiente con un fuerte apoyo comunitario.
CareGroup 303-097
Chica
El 31 de diciembre de 2002, el Hospital Deaconess-Nashoba se secó a Essent, una organización con fines de lucro que
destinó fondos significativos a una renovación masiva del hospital durante los próximos dos años (lo que la estructura de
capital de CareGroup no permitió) . Finalmente, el Hospital Deaconess-Glover fue reorganizado como parte del Centro
Médico Beth Israel Deaconess debido a su fuerte patrón de referencia allí. Los tres hospitales continuaron recibiendo todo
su soporte de TI a través de la organización de TI de CareGroup, que se había convertido en un proveedor de outsourcing
de facto para los hospitales que ya no formaban parte de CareGroup .
El 1 de noviembre de 1998, Halamka se convirtió en CIO de CareGroup, ya que estaba trabajando sistemáticamente a
través de un proyecto de $41 millones para hacer frente al problema Y2K. En ese momento, la organización de TI tenía 380
miembros del personal y gastos anuales superiores a 50 millones de dólares. Halamka trajo un trasfondo extraordinario a
la tarea. Como estudiante universitario en la Universidad de Stanford con especialización en computación y economía, había
fundado una compañía de software en su dormitorio a la edad de 18 años. Después de Stanford, se matriculó
simultáneamente en la Escuela de Medicina de la UCSF y en la Escuela de Ingeniería de Berkeley, donde completó un
programa combinado mecánico/eléctrico/ingeniería y escuela de medicina. En el momento de la residencia, vendió su
compañía de software, que para entonces había crecido a 35 personas, y se convirtió en un especialista en medicina de
emergencia en Los Angeles. En su tiempo libre, escribió varios libros sobre temas de computación y escribió un sistema de
hipertexto para coordinar toda la información clínica en el hospital del condado en Los Angeles. En 1996, se trasladó a
Harvard para ejercer la medicina de emergencia en el Beth Israel Deaconess Medical Center y emprendió trabajos
postdoctorales en el Instituto Tecnológico de Massachusetts en infomáticamédica. También dirigió un grupo de 50 analistas
de datos y especialistas web que desarrollan aplicaciones web para CareGroup.
Halamka,en 2000, asumió el papel adicional de CIO de la Escuela de Medicina de Harvard. (El monte Auburn y Beth
Israel/Deaconess eran hospitales de enseñanza de Harvard.) Al hablar de sus antecedentes, Halamka observó:
La razón por la que he tenido éxito es porque conozco todas las tecnologías, programo en 12 idiomas, y he escrito libros
sobre la administración del sistema Unix. Soy médico, así que entiendo el dominio clínico y los requisitos técnicos. Pero
como le digo a la gente, mi propio punto ciego: he conectado un armario telefónico, he construido 100 servidores, cientos
de escritorios, pero nunca he construido nada más allá de una red doméstica. Es sólo la realidad. Pero, ahora sí.
CareGroup IT
La organización de TI que Halamka asumió en octubre de 1998 fue una operación descentralizada y no estandarizada.
Cada uno de los hospitales tenía sus propios sistemas heredados propios que anteriores a la fusión. En el Centro Médico
Beth Israel Deaconess, las operaciones informáticas se complicaron al tener que ejecutar una mezcla de los sistemas de cada
uno de los hospitales fusionados. Además del personal interno de TI, CareGroup empleó a 78 consultores. Deaconess-
Nashoba tenía un sistema de laboratorio anticuado con resultados tipados a mano (IBM Selectric),sin correo electrónico, y
pocos PCs. proveedor de terceros que fallaría durante cada tormenta eléctrica. Deaconess-Waltham tenía un sistema de 10
años de edad con sistemas de laboratorio y radiología no integrados. NEBH tenía $500,000 por año fuera de consultores,
un sistema de laboratorio problemático, un sistema de nómina autodesarrollado, una instalación fallida del sistema de
quirófanos y una red limitada que no puede acceder a distancia. Mount Auburn Hospital, el más sofisticado de los hospitales
del centro no médico, estaba funcionando en su propio sistema de cosecha propia construido alrededor del paquete
Meditech.
Chica
En 2002, todos estos hospitales se habían reunido en un sistema común con el software Meditech en el centro.
Todos tenían correos electrónicos de última generación, redes, pces y sistemas de información
clínica/financiera a costos similares o reducidos de los que en ese momento Halamka asumió. Por ejemplo, el
presupuesto de TI de NEBH redujo 135.000 dólares en el año fiscal 2002, y se esperaba que se retirara otros
400.000 dólares en el año fiscal 2003. En 2003, CareGroup creía que tenía la red más avanzada en
atención médica, el sistema de correo electrónico más avanzado en la atención de la salud, el más avanzado
sistema de voz/inalámbrico en el cuidado de la salud, el centro de datos más avanzado en atención médica y la
infraestructura web más avanzada en la atención de la salud. Atendió a 3.000 médicos, procesó 40 terabytes de
datos por día, y manejó 900.000 registros de pacientes que datan de 1977, todos apoyados por un equipo
de 200.
Todas las aplicaciones estaban habilitadas para Web. A finales de 2002, el autor del caso, utilizando la contraseña de
Halamka, pudo acceder a todos sus propios registros de salud personales, radiografías y registros de visitas al consultorio
de la última década en un PC a cinco millas del hospital donde había recibido esos servicios (él estaba encantado de descubrir
que eran exactos). La organizaciónde TI ejecutó un centro de datos completo "apagado" con tres generadores de copia de
seguridad y no había sufrido un corte de energía del centro de datos en tres años. En el primer trimestre de 2003, el
mainframe final de IBM estaba programado para ser dado de baja, y la red se construiría exclusivamente alrededor de
servidores Unix/Linux agrupados. El almacenamiento de información fue 100% EMC (sin almacenamiento de información
local basado en servidor). Las unidades de procesamiento central (CPU) emparejadas para el desarrollo, las pruebas y la
producción aseguraron que el nuevo software funcionaba bien en el momento en que estaba en uso.
Hewlett-Packard fue el principal proveedor de las cajas Unix, y Compaq (ahora HP) era el principal proveedor de cajas
Wintel; Dell suministra máquinas para clústeres Linux. Después de un estudio de McKinsey en Harvard, IBM llegó con una
oferta que subyace los precios de Dell para pcens en un 50%. Como resultado, durante un período de cinco años, todos los
escritorios (incluidos los de CareGroup, porque incluían hospitales de enseñanza deHarvard) estaban siendo reemplazados
por IBM PCs. El centro de datos alojaba sistemas de copia de seguridad en cinta que realizaban backups incrementales en
los 40 terabytes de datos diarios, transfiriéndolos a cintas de tres gigabytes. Todas las noches esas cintas eran llevadas a un
almacén de Iron Mountain que una vez había sido un silo de misiles. El software PeopleSoft manejaba recursos humanos,
nóminas, cuentas por pagar y la contabilidad general. A los médicos se les proporcionaron cuentas de correo electrónico
gratuitas, y habían comenzado a experimentar con dispositivos de mensajería inalámbrica como los localizadores de texto
Blackberry. En el primer trimestre de 2003, todas las redes se basaen en la P.I.; Novell IPX sería reemplazado por el final
del año 2002, y AppleTalk desaparecería a finales del trimestre siguiente.
También en 2002, hubo dos eventos que no se consideraron importantes cuando ocurrieron, pero que tomaron
importancia en retrospectiva. En primer lugar, a petición de Halamka, Cisco llevó a cabo un estudio de la red general
CareGroup en el verano, entregando su informe final, completo con recomendaciones detalladas para modernizar la red,
en octubre; los resultados del estudio se analizaron en noviembre, pero nada en él sugería un peligro inminente. En segundo
lugar, el gurú de las redes de CareGroup, que durante mucho tiempo había proporcionado la última palabra sobre cualquier
cosa que tuviera que ver con la red general, dejó su posición en CareGroup IT para buscar otra oportunidad; aunque
reemplazo se estaba buscando, no se evidenteron impactos inmediatos como resultado de su partida.
CareGroup había reducido los gastos presupuestarios de capital en un 90% en los tres años anteriores a 2003 (véase
Prueba documental 3). Las instalaciones de Meditech en los diversos hospitales se realizaron sin consultores a la mitad
del tiempo habitual, al 20% del costo. (La Prueba documental 4 muestra los costos de operación de TI de los distintos
hospitales. La Prueba documental 5 muestra los gastos operativos de CareGroup con respecto a los socios y los
estándares de Gartner.) En septiembre de 2001, la organización de TI CareGroup ocupó el primer lugar en Estados Unidos
por la Semana de la Información, y había estado en la Entre las 100 mejores empresas de la semana durante los
últimos tres años. En noviembre de 2002, los sistemas y servicios de TI de CareGroup eran ampliamente vistos como
críticos para la construcción de lealtad clínica, y se creía que proporcionaban el mejor servicio de gestión del conocimiento
en los Estados Unidos. Todo esto fue emocionante y emocionante, pero . . .
Chica
CareGroup 303-097
13 de noviembre de 2002
En los días previos al 13 de noviembre de 2002, un investigador de la red CareGroup había comenzado a experimentar
con una aplicación de gestión del conocimiento basada en el intercambio de archivos, una especie de "Napster for health
care". El software fue diseñado para localizar y copiar información a través de la red automáticamente. Tan pronto como
este investigador había configurado el software en su configuración original que recibió una llamada de su esposa diciéndole
que estaba en trabajo de parto. Se fue a toda prisa para una licencia de paternidad de tres semanas. El nuevo software se
dejó en ejecución en un modo básico que aún no se ha probado o ajustado para el entorno en el que estaba funcionando. La
nueva aplicación comenzó a explorar la red circundante, buscando y copiando datos en volúmenes más grandes y más
grandes desde otros equipos. En la tarde del miércoles 13 de noviembre, el programa de software no autorizado estaba
moviendo terabytes de datos a través de la red.
El colapso de la red
Estas enormes transferencias de datos monopolizaron rápidamente los servicios de un conmutador de red ubicado en el
centro. Ningún otro dato pudo obtener a través de este switch, ni pudo responder a las consultas de otros componentes de
red preguntando si todavía estaba funcionando. Otros componentes de la red concluyeron, razonablemente, que algo le
había sucedido al conmutador monopolizado, que había dejado de funcionar como una parte fiable de la red. Otros
componentes de red comenzaron entonces a calcular rutas alternativas para el flujo de datos a través de la red, rutas que no
atravesaron el conmutador con problemas.
Afortunadamente, la red era físicamente redundante en todo (véase Prueba documental 6);había rutas alternativas
a lo largo de las cuales los datos podían fluir. Los componentes de red tenían una capacidad integrada para volver a calcular
las rutas de acceso de datos en caso de errores. Teóricamente, cualquier computadora en la red CareGroup todavía podía
comunicarse con cualquier otro equipo, a pesar de que un interruptor importante ya no estaba disponible.
Desafortunadamente, la complejidad evolucionada de la red general —la forma en que las redes más pequeñas
individuales se habían agregado una a la vez, ninguna de ellas resultó en problemas cuando se agregaron— había creado un
problema oculto que se iniciaba con una venganza ahora que la red había perdió los servicios de un interruptor importante.
A medida que los componentes de red trataban de calcular nuevas rutas a lo largo de las cuales fluían los datos, ya que
decidían qué componentes de red redundantes actuarían ahora como principales y que actuarían como copias de seguridad,
se confundieron. Como las muchas redes más pequeñas habían sido "pegadas" juntas con el tiempo, la red se había deslizado
gradualmente "fuera de las especificaciones"; los algoritmos para calcular rutas de datos alternativas ya no podían funcionar
correctamente.
Los componentes redundantes destinados a funcionar en tándem, uno como primario y el otro como copia de seguridad,
comenzaron a funcionar con fines cruzados, ambos convirtiéndose en primarios. Empezaron a duplicar la funcionalidad del
otro. Cada uno retransmitió los mensajes del otro; un Switch retransmitiría un solo mensaje al otro, luego ese Switch
retransmitiría el mismo mensaje al primero, que luego lo retransmitiría al segundo otra vez. Todos los mensajes en la red
comenzaron a repetirse de esta manera, reproduciéndose rápidamente en un bucle sin fin hasta que la red fue totalmente
deshabilitada. (Véase Prueba documental 7 para obtener una explicación más detallada de este problema y la Prueba
documental 8 para un gráfico de los niveles de tráfico de la red durante la interrupción.)
Ninguno de estos detalles de lo que estaba sucediendo era evidente para los usuarios, operadores o gerentes de los
sistemas de TI y la red de CareGroup. Todo lo que cualquiera podía ver en esa tarde de noviembre era que todas las
aplicaciones de software que requerían comunicación de red habían dejado de funcionar, de repente y sin previo aviso.
Chica
303-097 CareGroup
En Beth Israel Deaconess Medical Center, las áreas y sistemas clave se vieron afectados: unidades clínicas, correo
electrónico, funciones de la oficina de admisión, funciones de quirófano, laboratorios clínicos, radiología, servicios
ambulatorios, farmacia, registros médicos, fiscal/nómina sistemas y funciones del Departamento de Emergencias. Los
médicos que recetaban medicamentos para sus pacientes se habían acostumbrado a la asistencia informática en la
identificación de interacciones farmacológicas; cuando un médico hizo un pedido de medicamentos para un paciente, el
sistema, que recordaba perfectamente qué otros medicamentos estaba tomando el paciente, marcó posibles interacciones e
incluso apareció los avisos recientes de la Administración de Alimentos y Medicamentos (FDA). Durante años, los rayos X
se habían digitalizado, y las herramientas informáticas para verlas proporcionaban muchas opciones para vistas mejoradas
que se utilizaban ampliamente. La sala de emergencias había llegado a depender del acceso inmediato a la historia clínica
del paciente, a menudo disponible y extremadamente valiosa si un paciente estaba incapacitado.
Pero con la red baja, nada de esto funcionó. Los médicos tenían que comprobar las interacciones con medicamentos por
sí mismos; los residentes de radiología que nunca habían tocado unaradiografía en forma de película fotográfica "primitiva"
obtuvieron un curso intensivo en el diagnóstico a la antigua. Las historias médicas tenían que venir enteramente de los
pacientes. En toda la comunidad de cuidadores, aparecieron innumerables problemas. Los teléfonos sustituyeron al correo
electrónico. Formas de papel fueron sacados de armarios y desempolvados; los veteranos comenzaron a explicar al personal
más joven cómo funcionaban los sistemas de papel. "Nos convertimos en un hospital de la década de 1970 en un instante",
explicó Halamka.
Los hospitales comunitarios utilizaron el paquete Meditech para todas las operaciones clínicas y no dependieron del
acceso al centro de datos central de CareGroup ni a las redes de diácones a Beth Israel para recuperar información clínica.
Por lo tanto, estos hospitales no se vieron afectados en gran medida por la interrupción, excepto por correo electrónico a
través del sistema. (Meditech tenía un sistema de mensajería interno que mantenía las comunicaciones dentro de un
hospital.)
El personal de TI de CareGroup se propuso urgentemente diagnosticar el problema en Beth Israel Deaconess y tratar de
restaurar la funcionalidad. Fue un desafío formidable. El síntoma principal del problema fue que "nada funcionó"; aunque
extremadamente impresionante en sus efectos, este hecho transmitió poca información detallada sobre por qué podría ser.
La red parecía un candidato fuerte como la fuente del problema, ya que era un elemento común en todo lo que no funcionaba,
pero no era la única fuente de problema posible. Incluso suponiendo que la red fuera el problema, había un gran número
de posibles razones para ello. La gente comenzó a formar ideas frenéticamente sobre lo que estaba mal y sugiriendo cambios
basados en sus ideas. Halamka,que había comenzado a supervisar personalmente los esfuerzos de recuperación casi tan
pronto como el incidente había comenzado, describió lo que estaba sucediendo:
Una persona decía: "Oh, sé cuál es el problema. Es la conexión de red de área amplia a Mount Auburn, debemos apagar
Mount Auburn". Y alguien más diría, "Bueno, no lo sé, estoy preocupado por la configuración de este componente de red."
Todos querían ir a hacer un cambio. Y el problema es que tan pronto como haces un cambio, entonces el diagnóstico del
problema se vuelve más difícil.
Utilizando medidas tácticas como el reinicio de equipos de red, el grupo de TI pudo restaurar los servicios antes de las
4:00 a.m. del jueves 14 de noviembre, unas 12 horas después de que el incidente había comenzado. Pero a medida que los
usuarios comenzaron a reanudar el negocio como de costumbre, la red se portó de nuevo mal. Durante todo el día del jueves,
los sistemas rebotaron hacia arriba y hacia abajo. A veces eran utilizables, a veces no lo eran. El jueves por la noche, el
personal de TI creyó una vez más que los sistemas estaban restaurados. Pero a primera hora de la mañana del viernes 15 de
noviembre, era evidente que la inestabilidad de la red se mantuvo; fracasos seguían ocurriendo.
Chica
CareGroup 303-097
Llamar en Cisco
A las 4:00 p.m. del jueves, aproximadamente 24 horas después de las primeras dificultades con la red, Halamka llamó
a Cisco y pidió ayuda urgente. Con su equipo de red de Cisco bajo contrato de mantenimiento y una historia fascinante que
contar, no tuvo problemas para llamar la atención del grupo de ingeniería de soporte avanzado de Cisco. Los ingenieros de
soporte de Cisco llevaron la historia a John Chambers, el CEO de Cisco, que aprobó escalar el incidente al "estado CAP";
esto puso en marcha el equipo SWAT de atención al cliente de la compañía.
En cuestión de horas, Cisco había enviado desde Santa Clara, California, un Boeing 747 cargado con equipos de red e
ingenieros de soporte. Al mismo tiempo, un equipo de expertos de Carolina del Norte, compuesto por personal de Cisco y
Callisma (un socio consultor de Cisco), abordó vuelos de aerolíneas comerciales que se dirigían a Boston. El equipo y el
equipo eran adecuados para construir toda una red central redundante para poner en marcha de nuevo los sistemas
CareGroup, en caso de que fuera necesario. En las últimas horas del jueves por la noche, mientras Halamka conducía al
aeropuerto para reunirse con los ingenieros de Cisco, se dio cuenta de lo cansado que estaba; para entonces había estado
despierto durante 36 horas consecutivas. Sabía que otros miembros de su equipo también estaban cansados y muy
necesitados el fuerte apoyo que esperaba él conseguiría de Cisco.
Cuando el equipo de Cisco llegó a CareGroup,se hicieron cargo, instituyendo inmediatamente su "proceso CAP."
Halamka explicó:
Cisco ha aprendido a lo largo de los años que demasiados cocineros en la cocina nunca sanan una red. Así que el proceso
de la PAC básicamente dice, "Vamos a congelar todos los cambios." Cisco posee el problema y pondrá sus recursos
empresariales completos a su disposición hasta que usted se vuelva estable otra vez. Pero usted delega toda la autoridad
para resolver este problema a Cisco. No haces nada por tu cuenta.
A lo largo de la noche, Cisco trabajó rápidamente, mapeando cuidadosamente la red existente. Alrededor de la 1:00
a.m. el viernes por la mañana, se habían puesto a cero en al menos parte del problema y decidieron instalar un switch grande
y moderno (un Cisco 6509) en lugar de un componente de red existente. Pasaron toda la noche reconstruyendo una parte
importante de la red. "En una noche", relató Halamka,"hicieron un mes de trabajo".
Al implementar el proceso CAP, Cisco mantuvo un promedio de alrededor de 10 personas en el sitio en Beth Israel
Deaconess. Pero eso era sólo la punta del iceberg de apoyo. Los ingenieros in situ trabajaron continuamente con equipos de
todo el mundo. Halamka explicó:
Siguen el sol. Carolina del Norte a Japón a Amsterdam. Literalmente teníamos equipos en todo el mundo entrecándose
el uno al otro. Tenían unas 10 personas aquí, al menos tres ingenieros 24 por 7, desde el jueves a eso de las 6:00 hasta el
martes. Y su reconstrucción de red aisló esa parte de la red CareGroup. Y dijimos, "Oh, genial, esto es maravilloso, lo
tenemos ahora." Fuimos a viernes y sábado pensando "las cosas se ven muy bien". Hasta que descubrimos que había otras
dos partes de la red que tenían el mismo tipo de problemas.
La decisión de permanecer en los procedimientos de copia de seguridad
Con cada una de las fallas de la red, el centro médico había promulgado procedimientos de respaldo establecidos. Cuando
se creyera que los sistemas se habían restaurado, el centro médico intentaba volver a los procedimientos estándar. Pero para
la mañana del 15 de noviembre era obvio que el cambio frecuente entre los procesos de copia de seguridad y estándar
conllevaba más riesgo potencial para la atención del paciente que permanecer en los procesos de copia de seguridad durante
un período más prolongado. Halamka por lo tanto recomendó, y se acordó rápidamente
Chica
CareGroup
por la alta dirección de CareGroup, que el hospital permanezca en procedimientos de copia de seguridad hasta que quedó
claro que la red fue restaurada completa y definitivamente. Halamka describió los fundamentos de esta decisión:
El desafío para mí, desde el punto de vista de la dirección, era que quieres creer que estás a un cambio de configuración
lejos de hacer que todos vuelvan a donde deberían estar. Así que tienes al CEO, el COO diciendo, "OK, ¿dónde estamos?"
"Oh,ya casillegamos", piensas. Mi gente me dice que ya casi llegamos. Cisco me dice que ya casi llegamos.
Así que usted tuvo la organización, que es totalmente electrónica, diciendo: "Bien, vamos a ir al tiempo de inactividad,
vamos a hacer papel,oh, escuché que la red está de vuelta, vamos a electrónica." Al igual que la red está oscilando, están
oscilando sus flujos de trabajo. Lo que terminé diciendo [CEO] Paul Levy y [COO] Michael Epstein es, "Voy a creer lo que
Cisco dice y le diré cuándo la red será de respaldo. Cuando tengamos funcionalidad las 24 horas a plena carga, la propia red
nos dirá que es una copia de seguridad. Así que mientras tanto, vamos a mover toda la organización a papel y mantenerlos
en papel, para que los ingenieros tengan la oportunidad de hacer cambios, y la organización no está sufriendo esta
probabilidad de error de ir entre dos flujos de trabajo".
El 15 de noviembre, Beth Israel Deaconess Medical Center activó un centro de mando interno para coordinar un período
prolongado sobre los procedimientos de respaldo. El acceso a la red se bloqueó para que no se produjera un uso intermitente
de los sistemas informáticos. El Departamento de Salud Pública de Massachusetts fue notificado al activar el centro de
mando. El centro de mando fue tripulado en todo momento por administradores superiores, y se establecieron contactos
clave con cada departamento clínico y administrativo. La experiencia durante el período de interrupciones intermitentes
reveló que los laboratorios clínicos se enfrentaron a la mayor interrupción en el flujo de trabajo en relación con la
interrupción, por lo que estas áreas recibieron especial atención y apoyo.
Los procesos específicos que se siguieron a partir del 15 de noviembre y durante toda la interrupción incluyeron:
 Establecimiento del centro de mando como punto central para todas las comunicaciones
 Establecimiento de sesiones informativas por la mañana y por la tarde cada día como parte de un horario regular. En cada
reunión, se recordó a los médicos y al personal que la seguridad de los pacientes era de suma importancia, y se establecieron
mecanismos especiales para informar de las preocupaciones de seguridad de los pacientes.
 Establecimiento de un sistema de "corredores" disponible para recuperar especímenes, pruebas, equipos, documentación
o suministros en cualquier momento
 Documentación en papel de toda la actividad que se registró previamente electrónicamente, utilizando sistemas
establecidos como parte de los procedimientos de copia de seguridad
 Devolución de todos los resultados urgentes del laboratorio al médico responsable
 Establecimiento de dibujos de laboratorio escalonados para igualar la demanda en los laboratorios clínicos
 Implementación de procesos manuales para pedidos y dispensación de farmacias
 Implementación de listas de censos manuales por la oficina de admisión, actualizadas cada pocas horas
Chica
CareGroup 303-097
 Establecimiento de un plan de contingencia para la externalización de todo el volumen de laboratorio ambulatorio (esto
nunca se hizo necesario)
 Creación de líneas telefónicas directas para solicitar/informar resultados de laboratorio, preocupaciones de atención al
paciente y la necesidad de cualquier otra forma de apoyo
La planificación que CareGroup había hecho para prepararse para Y2K había hecho que Halamka tuviera
razonablemente confianza en que el centro médico podía operar completamente basado en papel. Pero las cosas habían
cambiado desde Y2K. Nadie sabía dónde estaban los formularios de papel. El personal médico vagaba por los pasillos,
diciendo: "Sé que tenemos esos formularios de papel en alguna parte. ¿Dónde están?" En un caso, los formularios se
recuperaron del centro de reciclaje, literalmente extraídos de las papeleras de reciclaje. Se llamó al personal adicional para
mover formularios. Los datos que normalmente se habrían enviado a lo largo de un cable tenían que ser enviados a travésde
"sneakernet" en su lugar. Halamka describió el trabajo en equipo y la ingeniosidad que permitieron al centro médico
adaptarse rápidamente a las operaciones en papel:
Todo el día viernes trabajamos para optimizar los procesos de copia de seguridad. Así que estamos en la entrada de
pedidos computarizados a la farmacia por completo, ¿cómo es que volvemos a los pedidos escritos a mano y la verificación
de dosis y la verificación de medicamentos y la verificación de alergias a medicamentos? Así que tiene [CEO] Paul Levy
dirigiendo copias de Xerox de los resultados de laboratorio que los corredores luego recogerían y llevarían a la unidad de
cuidados intensivos (UCI). El director de farmacia revisó manualmente cada pedido de papel para las interacciones entre
medicamentos y medicamentos y las interacciones entre medicamentos y alergias. Fue increíble lo que la gente era capaz de
hacer. El trabajo en equipo y el espíritu de resolución de problemas fue simplemente impresionante.
Resultó que podríamos manejar todo el hospital en papel. Simplemente no puedes ir y venir porque tomas todos tus
pedidos de papel y luego los introduces en la computadora, y luego la computadora se hace cargo, oh, pero ahora la red está
abajo de nuevo, tienes que volver a escribirlos todos en papel. Así que al menos duplicas, si no triplicas, tu trabajo oscilando
de un lado a otro.
La decisión de funcionar predominantemente en un sistema de información basado en papel también ayudó al grupo de
TI en sus esfuerzos por diagnosticar el problema. Se podrían realizar pruebas de red y aislar problemas sin preocuparse por
la interrupción de la actividad clínica de rutina.
Al final, los servicios a los pacientes y a la comunidad de Boston se interrumpieron mínimamente. Durante
aproximadamente cuatro horas el 14 de noviembre, cuando aún no estaba claro que se pudiera mantener el rendimiento del
paciente, el Departamento de Emergencias anunció a Boston Emergency Medical Services que estaba cerrado. Además, el
centro médico estuvo en ambulancia durante un total de 13,5 horas del 13 al 15 de noviembre. Esta cantidad de tiempo en
la desviación no sería muy inusual para cualquier hospital en la ciudad de Boston. De lo contrario, la actividad de la clínica
ambulatoria, la actividad del quirófano, la transferencia de pacientes y la actividad de entrada del paciente continuaron de
acuerdo con la política y el procedimiento estándar durante la interrupción.
Después de la restauración completa de los sistemas informáticos, se contactó a los directores de todos los servicios
clínicos para reforzar la importancia de informar de cualquier evento clínico adverso relacionado con la interrupción de la
red. Se notificaron doce acontecimientos en respuesta a esta solicitud. Se revisaron los registros relativos a cada uno de
ellos; revelaron que la atención se había retrasado en algunos casos, pero en ningún caso había pruebas de resultados
adversos relacionados con la interrupción de la red. También se revisaron los informes de incidentes y las quejas de los
pacientes en busca de resultados inesperados relacionados con la interrupción de la red; no se documentaron otros eventos.
Chica
303-097 CareGroup
Resolver el(los) problema(s)

La asignación subsiguiente por el equipo de soporte de Cisco finalmente descubrió otros lugares donde la red había
"evolucionado" hasta que estaba fuera de las especificaciones — hasta que los algoritmos para recalcular los trayectos de
datos a través de la red no podían funcionar correctamente. En toda la red de área amplia de CareGroup, la asignación reveló
problemas de los cambios en la red que habían realizado casualmente los usuarios. Halamka ofreció un ejemplo:
Algunos investigadores se quedaron sin puertos en uno de los switches. Entonces, ¿qué hicieron? Encadenaron un
interruptor a un interruptor. Imagina que tienes que llevar tu barbacoa a tu bañera de hidromasaje a tus luces de Navidad,
y tienes cinco cables de extensión sin un interruptor. ¡Vas a explotar! Así que descubrimos que esa era otra fuente del
problema de bucle. La cardiología también había hecho algunos cambios en la red que causaron problemas.
CareGroup IT y el equipo SWAT de Cisco pasaron el sábado arreglando todos los problemas de bucle en la red general. Al
final de esa tarea, se decepcionaron al descubrir que todavía había un problema en algún lugar de la red, que rastrearon a
un viejo router modelo. El router antiguo tenía un problema en su "firmware", el software que se escribió permanentemente
en los microchips dentro del dispositivo. No había manera de actualizar el router viejo, así que fue reemplazado.
La red informática fue restaurada el 18 de noviembre, pero los procesos fueron pasados a formatos basados en computadoras
gradualmente y de manera escalonada. Los sistemas basados en papel se retiraron sólo después de que los sistemas de
información de cada área hubieran funcionado de forma continua y sin incidentes durante al menos 24 horas.
Tras la restauración de los sistemas informáticos, toda la información en papel se transfirió al formato electrónico adecuado
en un plazo aproximado de 48 horas. La gran mayoría de documenta- tion se localizó fácilmente, pero aproximadamente
300 solicitudes de pruebas clínicas no pudieron emparejarse de forma fiable con una muestra o resultado clínico. Para cada
uno de estos casos, se contactó al médico que ordenaba, y los pacientes que necesitaban ser probados de nuevo fueron
informados de que se eximirían las tarifas y los costos de estacionamiento/transporte reembolsados por el hospital.
Lecciones aprendidas
Para todos los que se habían visto afectados por la interrupción de la red, se sintió profundamente una lección, como explicó
Halamka: "La gente se dio cuenta, muchas por primera vez, de lo dependientes que son de la tecnología. Se había convertido
en una parte de la cultura. Ni siquiera lo pensaste. Habíamos empezado a pensar en ello como si pensemos en el teléfono.
Coge el teléfono y oye un tono de llamada. Está justo ahí." Halamka también citó 10 lecciones más específicas que él, su
personal y el equipo directivo de CareGroup habían extraído de la experiencia:
Lección #1: No dude en traer a los expertos para asegurarse de que su red es configurado correctamente. Desde el
incidente de la red, Halamka había firmado un acuerdo de $300,000 por año para el soporte de los servicios de ingeniería
avanzada de Cisco. Como parte de este acuerdo, Cisco haría cualquier cambio a la red CareGroup que se considerara
significativo. La revisión en curso de Cisco aseguraría que la red permanecería "en las especificaciones". Dos ingenieros de
Cisco permanecerían en el lugar en Beth Israel Deaconess permanentemente.
Lección #2 : No permita que ninguna persona de su grupo de TI se convierta en el único punto de fracaso. En
retrospectiva, Halamka se dio cuenta de que el departamento de TI de CareGroup había dependido demasiado de un
solo empleado para mantener la red. Debido a que el personal de TI dependía exclusivamente de un experto, no había
nadie que ofreciera
10
Chica
CareGroup 303-097
una segunda opinión sobre la configuración de la red o para notar cualquier precursor del problema (si ha habido alguno).
"Es mejor extirpar a un excelente empleado que puede ser brillante y parece indispensable, si él o ella es recalcitrante y no
está dispuesto a abrirse, trabajar y compartir con los demás", sugirió Halamka.
Lección #3: Mantenga sus conocimientos de trabajo actualizados. CareGroup no sólo había dependido demasiado
de un experto en redes, sino que también había permitido que sus conocimientos quedaran desfasados. Después del hecho,
los ingenieros de soporte de Cisco resumían el problema en CareGroup de esta manera: "La red en CareGroup fue de última
generación para principios de la década de 1990. A finales de la década de 1990 había evolucionado hasta convertirse en un
estado frágil, y el personal de redes del grupo, que no se había mantenido al día con las tecnologías de redes, no veía
problemas en el que se avecinaban".
Lección #4: Cuidado con los usuarios armados con el conocimiento suficiente para ser peligroso. Un usuario que
experimentaba con un nuevo paquete de software había desencadenado la interrupción. Aunque los usuarios, y
especialmente los investigadores, siempre participarían en alguna experimentación con los recursos de TI locales, era
importante que el grupo de TI permaneciera vigilante, observando los cambios y supervisando los experimentos de los
usuarios según corresponda.
#5 de la lección : Instituir un riguroso controlde cambios de red. Después de la interrupción de la red, CareGroup
estableció un procedimiento formal para realizar cambios en la red. Se creó una Junta de Control de Cambios de Red con
membresía multidisciplinaria para revisar y aprobar todos los cambios en la infraestructura de la red. El grupo clasificado
cambia a tres categorías: impacto mínimo, moderado o sustancial. Cambios sustanciales requeridos por el equipo de
ingeniería avanzada de Cisco. Los cambios en la red sólo se hicieron entre las 2 a.m. y las 5 a.m. los fines de semana, y los
planes de pruebas y recuperación de incidentes tenían que ser evidenciados antes de que se permitiera que los cambios
avanzaran.
Lección #6: Adaptarse a externalidades. La red CareGroup había evolucionado a su condición "fuera de especificación"
como resultado de fusiones, reorganizaciones y otras actividades y eventos externos. La interrupción de la red de noviembre
llevó al personal de TI a examinar más detenidamente todos los eventos en el entorno exterior para ver posibles impactos
en la funcionalidad de TI existente.
Lección #7: Hay límites a la capacidad de respuestacentrada en el cliente. El personal de TI de CareGroup no podía
adoptar un enfoque de "cualquier cosa que el cliente quisiera", sino que necesitaba equilibrar la centralidad del cliente con
los riesgos para la red y los sistemas de TI solicitudes de apoyo a las nuevas tecnologías. Halamka ofreció un ejemplo de la
nueva perspectiva del grupo de TI sobre la capacidad de respuesta del cliente después de la interrupción:
El Departamento de Cirugía ha decidido que la cirugía mínimamente invasiva es una prioridad. Han contratado a un tipo
para que venga a ayudarlos con que está planeando usar video sobre IP. Necesitará redes de velocidad gigabit para mostrar
endoscopia al mundo. Llegará en febrero. ¿Eso es un problema? En el pasado, la idea era: "Por supuesto que apoyaremos
el video sobre IP para febrero". Ahora es un, "No, traeremos a Cisco para mirar el impacto en el entorno total." Pondremos
restricciones mucho más severas sobre qué protocolos y servicios puede ejecutar cualquiera, qué carga puede poner en la
red, dónde ejecutarlo y los cambios que tenemos que realizar.
Un proceso formal de control de cambios lograría poco si los procesos se cortocircuitaban cada vez que hubiera una
necesidad empresarial "urgente".
Lección #8: Tener procedimientos de copia de seguridad en los que puede tener confianza. CareGroup pudo dirigir
el hospital en sistemas de papel debido a la preparación de Y2K. Con Y2K pasado, sin embargo, seguía habiendo una
necesidad continua de asegurarse de que los procedimientos de copia de seguridad funcionaban. Los procedimientos de
copia de seguridad debían ser lo suficientemente eficaces como para funcionar durante un período prolongado. En caso de
una interrupción grave, no sería productivo moverse de un lado a otro entre los procesos informáticos y en papel, por lo que
el sistema de papel tendría que ser robusto.
11
Chica
303-097 CareGroup
Lección #9: La redundancia de componentes no es suficiente; necesita métodos de acceso alternativos. Durante la
interrupción, algunos sistemas importantes podrían haber seguido funcionando, aunque más lentamente, si hubieran
podido estar conectados de emergencia a módems de acceso telefónico. Las líneas telefónicas podrían haberse convertido
en una red rudimentaria de copia de seguridad que habría conservado una cantidad significativa de funcionalidad del
sistema. Después de la interrupción, CareGroup adquirió capacidad telefónica analógica adicional y agregó capacidades de
módem a 50 PC en todo el centro médico. 1
Lección #10: Gestión del ciclo de vida de los componentesde red. Los enrutadores, conmutadores y otros componentes
de red debían reemplazarse cada cuatro años. Durante la interrupción de CareGroup, un componente de más de cuatro
años de edad había causado un problema grave debido a un defecto en su firmware; no podía funcionar correctamente en
una red moderna. Es necesario presupuestar los componentes de red. Las actualizaciones requeridas después de la
interrupción de CareGroup equivalieron a un gasto único multimillonario y en los requisitos continuos para las
actualizaciones cada año.
También hubo muchas otras lecciones, importantes aunque quizás no tan merecedoras de titulares (La Prueba 9
enumera las acciones tomadas después de la interrupción). Todo el incidente había sido una gran oportunidad para
aprender, y Halamka estaba convencido de que compartir información sobre lo que había sucedido, y hablar de ello con
otros, en última instancia fortalecería CareGroup y su Capacidades. El incidente también había proporcionado tutoriales
en aspectos positivos y negativos de la psicología humana. Halamka había quedado tremendamente impresionado por la
forma en que la organización —médicos, enfermeras, investigadores, personal de TI y muchos otros— se había unido para
rendir muy bien en la crisis. Pero también tenía un renovado respeto por la perjudicial tendencia humana a responder a un
problema simplemente "haciendo algo", haciendo cambios impulsivos en la infraestructura de TI; si Halamka y sus colegas
no hubieran superado ese impulso, el diagnóstico y la recuperación del problema habrían sido mucho más difíciles.
La interrupción también le recordó a Halamka que las operaciones informáticas en una gran organización tienen decenas
de miles de "partes móviles" y que su trabajo era gestionar el proceso de conseguir que todas esas partes móviles funcionaran
en armonía. "Me llaman el 'jefe de información'", señaló Halamka, "pero en realidad soy el 'jefe oficial de integración';
Hago que todo hable con todo lo demás".
1 Por razones de seguridad, estos módems solo son accesibles desde dentro de la red telefónica interna de CareGroup y solo en caso de
emergencia.
12
Chica
CareGroup 303-097
Exhiben 1 CareGroup Organigrama, 1 de enero 2003
CareeGrGrou
CareGrou
CareGroup
Car
ppp
CEOICLO
CYO IOICLO
CEOICLO
CE CL
O
Beth
Sert araelel
thhIsirIsrael
Deaconess on un
Montaña
Hospital
New wEnnglglanan an
d De ye a caconnE
s Mo t Bautista de
Centro Médico Auburn
tporfavoruu dd BaptBaptist est
MEediDe ccal rnRN Nueva
CCet ter Hhosptispiat al
Inglaterra
Al 31 de diciembre de 2002, el Hospital Deaconess-Waltham y el Hospital Deaconess-Nashoba ya no formaban parte de
CareGroup, y el Hospital Nashoba-Glover informó al Centro Médico Beth Israel Deaconess.
Fuente: Documentos internos deCareGroup.
13
Chica
303-097 CareGroup
Exposición de 2 principales instalaciones médicas de CareGroup
Beth Israel Deaconess Medical Center

Beth Israel Deaconess Medical Center es un hospital de enseñanza de investigación, afiliado a Harvard, ubicado en el área
médica de Longwood de Boston. Sirviendo como el principal recurso académico y clínico de CareGroup,Beth Israel
Deaconess Medical Center es el hogar de varios centros clínicos reconocidos a nivel nacional de experiencia especializada,
incluyendo trasplante de órganos sólidos, diabetes/ cirugía vascular, obstetricia, cardiología y cirugía cardíaca,
gastroenterología, trauma, cáncer (con un interés particular en el cáncer de mama) y SIDA. Los centros hospitalarios y
ambulatorios complementarios y de última generación, además de dos centros ambulatorios regionales, las oficinas de
atención primaria en más de 30 comunidades y las unidades de cuidados transitorios y paliativos, mejoran la amplia gama
de servicios clínicos disponibles.
Hospital Mount Auburn

Mount Auburn Hospital en Cambridge es un hospital de enseñanza comunitario afiliado a Harvard, que sirve las necesidades
de atención médica de los residentes en Arlington, Belmont, Cambridge, Lexington, Medford, Somerville, Watertown y
Waltham. El hospital ofrece servicios médicos, quirúrgicos, obstétricos y psiquiátricos para pacientes hospitalizados y
ambulatorios y es un proveedor líder de atención avanzada especializada en cardiología, cirugía cardíaca, oncología,
ortopedia, neurología y vascular Cirugía. Además, Mount Auburn Hospital ofrece una extensa red de prácticas de atención
primaria por satélite en siete comunidades, así como una amplia gama de programas basados en la comunidad, incluyendo
Mount Auburn Home Care, servicios especializados para pacientes ambulatorios y Salud. El Centro de Prevención y
Recuperación del hospital es un proveedor de programas de educación, intervención y apoyo para problemas de salud
pública como el abuso de sustancias y la violencia. El Mount Auburn Center for Problem Gambling es la primera clínica
ambulatoria del estado.
Hospital Bautista de Nueva Inglaterra

Establecido en 1893, New England Baptist Hospital es un hospital médico/quirúrgico para adultos de 150 camas ubicado
en el barrio Mission Hill de Boston, con servicios especializados en atención musculoesquelética, medicina deportiva,
medicina ocupacional y cardiología.
El Hospital Bautista de Nueva Inglaterra se encuentra entre los principales proveedores de cirugía de reemplazo de cadera
y rodilla de la nación. Para consolidar su compromiso con el cuidado musculoesquelético, el hospital en 1995 formó el
Instituto Bautista de Huesos y Articulaciones de Nueva Inglaterra. El instituto es el principal recurso de la región para una
amplia gama de servicios de prevención y educación, diagnóstico, tratamiento y rehabilitación en ortopedia y reumatología,
reemplazo articular, cuidado de la columna vertebral, cuidado de pies y tobillos, cirugía de manos, medicina ocupacional y
medicina deportiva. El hospital cuenta con una unidad de enfermería especializada de 40 camas especializada en la atención
de rehabilitación para el paciente ortopédico, además de pacientes médicos postquirúrgicos. NEBH es el hospital de
medicina deportiva de los Boston Celtics.
Deaconess-Glover Hospital
Deaconess-Glover Hospital es un hospital comunitario de 41 camas que atiende las necesidades primarias y secundarias de
atención médica de los residentes de Needham y las comunidades circundantes de Dedham, Dover, Medfield y Westwood.
Fundada hace más de 80 años como hospital municipal, Deaconess- Glover ofrece una amplia gama de servicios para
pacientes hospitalizados y ambulatorios, servicio completo, 24 horas
14
Chica
CareGroup 303-097
departamento de emergencias, pruebas cardíacas de última generación y capacidades de tratamiento, atención de la diabetes
a través del Centro Joplin en Deaconess-Glover, y radiología de diagnóstico avanzada. El hospital también alberga
instalaciones de laboratorio clínico y un nuevo centro de salud ocupacional para la prevención, tratamiento y rehabilitación
de lesiones laborales. El personal médico está compuesto por médicos y especialistas altamente cualificados en atención
primaria con formación avanzada en 30 disciplinas médicas y quirúrgicas, incluyendo artritis y reumatología, dermatología,
endocrinología, gastroenterología, obstetricia y ginecología, oncología, ortopedia, medicina pulmonar y urología, así como
cirugía plástica, torácica y vascular.
Hospital Deaconess-Nashoba (desviado el 31 de diciembre de 2002)

Deaconess-Nashoba Hospital es un hospital comunitario de 41 camas que atiende a 11 comunidades en el centro norte de
Massachusetts. Ubicado en Ayer, el hospital cuenta con un personal médico altamente calificado con 122 médicos miembros
activos y asociados que ofrecen atención primaria basada en la comunidad y una amplia gama de servicios especializados.
Fundada en 1964, Deaconess-Nashoba es conocida por muchas fortalezas clínicas, incluyendo medicina de emergencia,
cardiología, gastroenterología, oncología, ortopedia y cirugía. El hospital también ofrece una amplia gama de servicios
ambulatorios en su centro de atención ambulatoria, incluyendo un Joslin Diabetes Center. Otras instalaciones del hospital
incluyen un centro de enfermería y rehabilitación de 123 camas y un edificio de oficinas médicas. El hospital también ofrece
un centro de salud ocupacional en el lugar, que se centra en la prevención de lesiones y enfermedades relacionadas con el
trabajo, la rehabilitación y el manejo de problemas de regreso al trabajo.
Fuente: Documentos internos de CareGroup.
15
Chica
303-097 CareGroup
Prueba documental 3 Gastos operativos y de capital deCAREGroup IT, FY1998–FY2001
$60,000,00
0
$50,000,00
0
$40,000,00
0
Capital
$20,000,00
0
$10,000,00
0
16
Chica
CareGroup 303-097
Prueba documental 4 Comparaciones de puntos de referencia, año 2001
Gastos operativos de TI como porcentaje de los ingresos de la organización
CareGroup 1.9%
Socios 2,3%
Los puntos de referencia de Gartner para los IDN 1B un rango del 2,7% para losquintiles 2o 3:
1,9%–2,9%
TI como porcentaje del total de los gastos de capital

hospitalario
CareGroup 10.0%
Socios 25.0%
Puntos de referencia de Gartner para IDN 1B 21.0%
2o
Rango para quintiles /3o:10%–6%
Fuente: Documentos internos deCareGroup. unared de entrega integrada de IDN.
Nadocumental 5 Presupuestos de TI ingresos)

delos Hospitales Comunitarios (% de
FY2001 FY2002
Monte Auburn 0.7% .8%

NEBH 1.6% 1.5%
Waltham 1.8% 1.9%
Nashoba 1.2% 1.3%
Glover 1.0% 1.1%
Todo CareGroup, incluyendo BIDMC/PSN 1.9% 1,9% a

a Ajustado para PSN y reasignaciones de capital en el año
2002.
17
Chica
CareGroup
Prueba documental 6 La red existente en el momento de la interrupción (la pérdida del conmutador del campus
este etiquetado ly030 activó el evento)
(1) 5500 Interruptor (1) 5500 Switch

(1) Interruptor 5505 (1) Interruptor 5505
(3) 5509 Interruptores (1) 5509 Interruptor
(4) Ren Ctr (rc5, rc6,

rc7, rcc) (3) Ren Ctr (rc7, rc8,
(1) Monte Auburn (Remoto) rcc)
Parque
Del
8Renac
5500 5500
FEC6/23-24 12FEC6/23-24
(1) Investigación
ATM10/1 ATM10/1
Del Este
FEC4/21-24
(1) Baker
FEC4/21-24 FEC3/21-24 (4) Deaconiss
(7) LowryMedical
(1) Mantenimiento
(3) Palmer
(3) 109 Brookline (1) CCWest
Ave (Doble hogar
2127Burlington
Investigación Este Oeste
w/ccw00m4)
5509 ATM7/1 ATM5/1

5500
FEC10/1-4
FEC8/3- FEC10/1-2
FEC8/1-3 8
4
FEC10/5-6
12 12 FEC9/1-2
FEC9/1-2 5500 FEC10/1-4 FEC10/5-6
FEC8/1-2 FEC11/1-2
FEC11/3-4
12 FEC11/5-6
2 FEC8/1-2
FEC8/1-2
5500
(4) Dana
(3) Este (13) Farr
(12)Campus CCEast (7) Feldberg (6) Kennedy
(4) HIM Finard (2) Lowry
Kirstein (24) Campus CCWest - Medical
Reisman - 1is Dual Homed (1) Masco
rosa w/spg06b
(1) Servicio (1) PACS
(5) Stoneham
ATMOC-3 (155Mbps) sobre (2) Yamens
Sonet ATMOC-3 (155Mbps)
fibra oscura Fast
Etherchannel (400 Mbps)
Fast Etherchannel (800
Mbps) No activo
Fuente:"CareGroup Network Outage", presentación de John D. Halamka,M.D., 25 de noviembre de 2002.
18 Chica
Chica
CareGroup 303-097
Prueba documental 7 Descripción simplificada del problema que causó la interrupción de la red
El protocolo Ethernet
Las computadoras en una red pequeña se comunican usando reglas como esas personas acatan en una reunión de un
pequeño número de personas. Cuando una computadora tiene algo que decir, lo desenfoca. El equipo o los equipos a los que
se dirige el mensaje escuchan y atienden el mensaje. Esto funciona bien siempre y cuando dos computadoras no "hablan"
al mismo tiempo. Cuando dos equipos hablan al mismo tiempo, se produce una colisión. Cuando hay una colisión, los
equipos "hablando" deben detenerse, esperar una cantidad aleatoria de tiempo y, a continuación, intentarlo de nuevo. Este
método funciona bien, ya sea con computadoras en una red, o con personas en una reunión, siempre y cuando no haya
demasiados ordenadores / personas involucradas en la red / reunión.
Puentes e interruptores
A medida que agrega más personas a una reunión, puede determinar con el tiempo que se ha vuelto demasiado grande.
A continuación, puede dividir una reunión en dos subreuniones. Los dos grupos podrían establecerse en diferentes salas, y
podría designar a una persona para que se comunique entre la habitación cuando las cosas que la gente dice en una
habitación son relevantes para el trabajo de la otra. Este mismo principio se aplica a las redes. Cuando demasiados equipos
se unen a una sola red y las colisiones se vuelven demasiado comunes, las redes a menudo se dividen en dos segmentos
separados, conectados entre sí por computadora (un puente o conmutador) que retransmite mensajes de un segmento a
otro, cuando el remitente y el receptor del mensaje están en dos segmentos diferentes. Si hay más equipos conectados a
estos segmentos de red, es posible que tenga que subdividir de nuevo. O bien, es posible que necesite conectar otra red
pequeña a la suya; un puente o un interruptor también se puede utilizar para este propósito. Las redes pequeñas conectadas
entre sí por puentes y conmutadores de esta manera forman una topología de red que los expertos a menudo llaman "plana".
Puentes e interruptores redundantes

Para asegurarse de que los mensajes se pueden mover de forma fiable entre segmentos de red conectados por puentes o
conmutadores, es común instalarlos en una configuración redundante. Es decir, en lugar de instalar un puente entre dos
segmentos de red, instale dos. Si uno deja de funcionar, el otro está ahí para recoger el trabajo. Cuando ambos están
funcionando, los dos deben realizar un seguimiento de cuál está allí para actuar como primario, para hacer todo el trabajo
de puente —y que está ahí sólo para respaldar la primaria— para intervenir si algo le sucede a la primaria. Cuando esto
funciona correctamente, la copia de seguridad permanece a la vez, siempre escuchando para asegurarse de que el principal
está funcionando, interviniendo para actuar como un primario sólo si el primario se queda en silencio.
Spanning Tree Protocol (STP) y STP Loops

Cuando una red se activa por primera vez, necesita una manera de averiguar qué componentes redundantes actuarán
como principales y cuáles serán copias de seguridad. El Spanning Tree Protocol es la manera que las redes compuestas de
Bridges y Switches toman estas decisiones. Una vez que se establecen los roles, principal y de copia de seguridad,
permanecen así hasta que ocurra algo en la red que requiera un cambio en los roles de uno o varios de los componentes. Por
ejemplo, si un componente primario falla en algún lugar de la red, el Spanning Tree Protocol volverá a iniciarse para decidir
los roles de los componentes de red. Los componentes se comunican para decidir sus roles mediante mensajes de red
especiales. Estos mensajes tienen dentro de ellos contadores que hacen un seguimiento de cuántos "saltos" han hecho,
cuántos segmentos de red
19
Chica
303-097 CareGroup
han atravesado. En el Spanning Tree Protocol, si este contador excede siete (7), el mensaje de red especial se cae (ignorado).
Lo que esto significa, en efecto, es esto: cuando el número de segmentos de red conectados entre sí por puentes o switches
supera siete (7), la red puede tener problemas para resolver los roles primarios y de backup correctamente. En lugar de los
pares primarios y de copia de seguridad, puede terminar con dos componentes redundantes que funcionan como primarios.
¿Qué sucede cuando los componentes redundantes funcionan como primarios? Se transmiten todos los mensajes
que se escuchan el uno al otro. Un solo mensaje es retransmitido por ambos componentes, a ambos
componentes; cada uno entonces transmite fielmente el mismo mensaje de nuevo, como si fuera nuevo. Un solo
mensaje se multiplica en muchos, reproduciéndose en un bucle exponencial sin fin, hasta que todos capacidad de
red se consume. Cuando el conmutador en la red CareGroup fue abrumado por el paquete de software dejado en
ejecución por un investigador, esto es exactamente lo que pasó con la red CareGroup.
Obtener la red "In Spec"

La red CareGroup estaba "fuera de especificación" porque contenía numerosos casos de más de siete (7) segmentos de
red conectados por puentes o switches. Para corregir esta red de topología plana, era necesario hacer menos plana. En lugar
de conectar segmentos con puentes y switches, los routers fueron sustituidos en algún caso. Los enrutadores permiten una
transferencia más inteligente de mensajes a través de redes. Mediante el uso de enrutadores para dividir la complejidad
evolucionada de los muchos segmentos de red conectados a puentes y conmutadores, la topología de red se hizo menos
plana y se volvió inmune a los bucles Spanning Tree Protocol.
La inteligencia en el Routers surge de su capacidad de utilizar la información de direccionamiento en los paquetes TCP/IP
que encapsulan la información transmitida en una red moderna. Antes de que los routers trabajen, por lo tanto, una red
debe ser capaz de ejecutar TCP/IP. Esta es una de las razones por las que la red CareGroup se desprende de las
especificaciones. En el momento en que algunas redes más pequeñas se agregaron a la red general, esas redes más pequeñas
se basaban en tecnologías propietarias en lugar de TCP/IP. Por lo tanto, los mensajes que atravesaron esas redes
propietarias no eran "enrutables". Conseguir la red "en especificación", de modo que los routers pudieran ser utilizados en
lugar de puentes/interruptores, por lo tanto requería deshacerse de las viejas tecnologías de red propietarias que no eran
enrutables.
Fuente: Basado en entrevistas con documentos de John Halamka y CareGroup, incluyendo

http://home.caregroup.org/templatesnew/departments/BID/network_outage/.
20
Chica
CareGroup 303-097
Prueba documental 8 Core Router CPU Use during the Outage (11 de noviembre de 2002 a 15 de noviembre de
2002)
Fuente: "CareGroup Network Outage", presentación de John D. Halamka,M.D., 25 de noviembre de 2002.
Chica
CareGroup
Prueba documental 9 Cambios realizados o planificados en respuesta a la interrupción de la red
Las mejoras específicas ya puestas en marcha incluyen:
 Rediseño y reconstrucción de la red informática de radiología, la red del campus de investigación y la red de campus
clínicos
 Colocación de 40 ordenadores de acceso telefónico en áreas estratégicas del hospital
 Adición de la capacidad de acceso telefónico del sistema clínico a los escritorios de entrada de pedidos de 21 médicos en
los pisos de atención al paciente
 Implementación de una red central redundante que se puede conectar para reemplazar la red principal existente
Las siguientes mejoras se completan o se completarán en las próximas semanas:
 Actualización selectiva de hardware de red no core para aumentar la redundancia y estabilidad de nuestra red
 Programación del tiempo de inactividad los fines de semana de 2:00 a.m. a 5:00 a.m. para realizar cambios en la red
 Implementación de un estricto proceso de control de cambios con todos los cambios de ingeniería supervisados por Cisco
Las siguientes mejoras se completarán en el plazo de un año:
 Reconfiguración de la red principal
 Introducción de la redundancia en todo el hardware y enlaces
 Implementación del hardware y topologías más modernos
 Implementación de mejoras de software de gestión de redes
 Programación de tiempos de inactividad adecuados con énfasis en la estabilidad de la red
Fuente: Resumido de"CareGroup Network Outage", presentación de John D. Halamka,M.D., 25 de noviembre de 2002.
22

CareGroup Caso 4

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

CareGroup Caso 4

Cargado por

Copyright:

Formatos disponibles

Para uso exclusivo de A.

1. El poder de contratación que necesitan los hospitales contra los HMO

La decisión de permanecer en los procedimientos de copia de seguridad

 Devolución de todos los resultados urgentes del laboratorio al médico responsable

 Implementación de procesos manuales para pedidos y dispensación de farmacias

Resolver el(los) problema(s)

Exhiben 1 CareGroup Organigrama, 1 de enero 2003

Fuente: Documentos internos deCareGroup.

Exposición de 2 principales instalaciones médicas de CareGroup

Beth Israel Deaconess Medical Center

Hospital Mount Auburn

Hospital Bautista de Nueva Inglaterra

Hospital Deaconess-Nashoba (desviado el 31 de diciembre de 2002)

Fuente: Documentos internos de CareGroup.

Prueba documental 3 Gastos operativos y de capital deCAREGroup IT, FY1998–FY2001

Fuente: Documentos internos deCareGroup.

Prueba documental 4 Comparaciones de puntos de referencia, año 2001

Gastos operativos de TI como porcentaje de los ingresos de la organización

TI como porcentaje del total de los gastos de capital

Fuente: Documentos internos deCareGroup. unared de entrega integrada de IDN.

Nadocumental 5 Presupuestos de TI ingresos)

Monte Auburn 0.7% .8%

Fuente: Documentos internos deCareGroup.

(1) 5500 Interruptor (1) 5500 Switch

(4) Ren Ctr (rc5, rc6,

5509 ATM7/1 ATM5/1

Fuente:"CareGroup Network Outage", presentación de John D. Halamka,M.D., 25 de noviembre de 2002.

Puentes e interruptores redundantes

Spanning Tree Protocol (STP) y STP Loops

Obtener la red "In Spec"

Fuente: Basado en entrevistas con documentos de John Halamka y CareGroup, incluyendo

Fuente: "CareGroup Network Outage", presentación de John D. Halamka,M.D., 25 de noviembre de 2002.

Prueba documental 9 Cambios realizados o planificados en respuesta a la interrupción de la red

Las mejoras específicas ya puestas en marcha incluyen:

 Colocación de 40 ordenadores de acceso telefónico en áreas estratégicas del hospital

Las siguientes mejoras se completan o se completarán en las próximas semanas:

Las siguientes mejoras se completarán en el plazo de un año:

 Reconfiguración de la red principal

 Introducción de la redundancia en todo el hardware y enlaces

 Implementación del hardware y topologías más modernos

 Implementación de mejoras de software de gestión de redes

 Programación de tiempos de inactividad adecuados con énfasis en la estabilidad de la red

También podría gustarte