Tabla de contenido:
Primero, no hagas daño! Ese edicto, parafraseado del juramento hipocrático, impregna la atención médica profesional, como lo ha hecho desde los albores de la medicina occidental hace unos 2.500 años. Cualquiera puede apreciar la simplicidad y el significado de este mantra. Si no hace nada más como profesional de la salud, al menos no lastime a su paciente.
Escrito en el trasfondo de esa frase, puedes encontrar una humildad innegable. De hecho, para todas las diversas y variadas avenidas de la ciencia, existe un axioma crítico: siempre esté dispuesto a cuestionar sus suposiciones. Solo sabemos lo que sabemos, y seguro que todavía no lo sabemos todo, ni lo sabremos nunca. Deje que esa sabiduría sirva como precaución para sus recetas más fuertes.
Luego está la parte de hacer. En cualquier esfuerzo de la vida, uno espera saber algo importante, luego tomar las medidas apropiadas. Cuidar es tan cuidadoso como lo es, y cuando se cuida la vida de los demás, se requiere seriedad. Con esta perspectiva como nuestro lienzo, y una comprensión de la tecnología de la información (TI) bajo nuestros cinturones, echemos un vistazo a la implementación de HealthCare.gov, el buque insignia a menudo caracterizado de la Ley de Asistencia Asequible, también conocida como "Obamacare".
Soporte vital
¿Qué tan directo puedo ser? HealthCare.gov estaba muerto a la llegada. La transparencia colectiva ahora dice que las seis personas se inscribieron en su primer día, 1 de octubre. Seis. Solo 32, 994 menos que la meta diaria de 33, 000. Y aunque los problemas de "capacidad" se promocionaban como elogios de la demanda, cualquier persona con conocimiento de la dinámica de la Web lo sabía mejor.
"Este no es un problema sin resolver", señala el Dr. Robin Bloor, científico de datos y cofundador de The Bloor Group. "Holanda tiene tal intercambio".
De hecho, los holandeses han estado a la vanguardia del juego durante dos décadas, con muchas lecciones aprendidas. Los suizos también tienen algo de experiencia y, por supuesto, Massachusetts tiene MAHealthConnector.org, llamado "RomneyCare".
Bloor continuó diciendo que 40 años de experiencia en TI han demostrado que los grandes proyectos siempre conllevan un gran riesgo.
"Hacer un gran proyecto, alto riesgo, alto riesgo de fracaso. Tener tres años y medio suena como, en un día moderno, eso sería suficiente, pero aquí hay un proyecto de alto riesgo y todo salió mal, "Dijo Bloor.
Fue muy sincero sobre la forma en que se llevaron a cabo las pruebas de integración para HealthCare.gov.
"Lo último que me hizo, casi me hizo estallar de risa, es que no hay pruebas de integración hasta dos semanas antes de que salgas a la vida, y eso es como, ¿cómo podrías hacer eso con algo como esto? ¿Cómo podrías?" Dijo Bloor.
Compartiendo esa perspectiva es un veterano contratista federal y científico de datos, el Dr. Geoffrey Malafsky de Phasic Systems Inc. Malafsky recientemente ofreció una evaluación detallada de una hora de la implementación de HeathCare.gov, y comentó sobre las decisiones estratégicas y tácticas tomadas . Por encima de todo, señala con el dedo el protocolo de adquisición del gobierno federal.
"Uno de los puntos críticos de falla que impregna particularmente los proyectos de TI del gobierno es esta noción heredada, arcaica y obsoleta de que puedes articular toda la lógica de negocios necesaria con algunos procesos de requisitos lineales. Eso fundamentalmente no funciona con grandes sistemas de TI", dijo.
Su punto es que los grandes sistemas de TI serán perjudiciales incluso para los planificadores más inteligentes. Nunca se sabe de dónde vendrán los problemas, dónde necesitará proporcionar asistencia adicional o en qué tipo de solución de problemas se encontrará involucrado. En consecuencia, es una mala idea restringir el proceso de diseño al obligar a los ingenieros de proyecto a anticipar todo Necesitarán por adelantado.
Para complicar las cosas, dice Malafsky, es el hecho de que los funcionarios de adquisiciones en el gobierno federal ahora se han vuelto tan poderosos, debido a la gran cantidad de dinero que controlan, que esencialmente tienen el control de cómo avanzan los principales proyectos de TI. Esto coloca a los funcionarios departamentales en el papel de suplicantes e inserta un elemento de riesgo en un procedimiento crucial en el centro de cualquier iniciativa de TI importante: elegir las herramientas, tecnologías y contratistas adecuados.
"Las personas que estarán más en desacuerdo con esa declaración se llaman profesionales de adquisición, y les animo a que se presenten en mi casa y nos sentaremos a debatir esto, porque tengo mucha evidencia empírica para respaldar eso", dijo Malafsky. dijo.
Estrategia del sitio
Una gran pregunta es por qué el gobierno adoptó una arquitectura tan completa para este sitio web.
"Si el programa general del gobierno se establece de manera tal que las compañías de seguros realmente sean propietarias del cliente después de que se comprometan, entonces ¿por qué no simplemente desviar el tráfico al canal del entorno de interacción con el cliente existente que las compañías de seguros ya tienen? Sí, podrían necesitan aumentar los suyos, pero esa sería una razón comercial válida porque ahora van a tener nuevos clientes ", dijo Malafsky.
El pionero del software de seguridad de renombre mundial (y ahora algo infame) John McAfee también comentó sobre esta estrategia recientemente, haciendo algunos comentarios controvertidos sobre el "Neil Cavuto Show" en Fox News:
"Oh, es muy malo", dijo McAfee. "Alguien cometió un grave error, no al diseñar el programa, sino simplemente al implementar el aspecto web del mismo. Quiero decir, por ejemplo, cualquiera puede abrir una página web y afirmar ser un agente para este sistema … cualquier hacker puede poner un en el sitio web, haga que parezca extremadamente competitivo, y debido a la naturaleza del sistema, y esto es la atención médica, después de todo, pueden hacerle las preguntas más íntimas, y usted las responderá libremente ".
Con respecto a la arquitectura web en sí, Malafsky señala lo obvio: que Internet no se creó para ejecutar aplicaciones complejas. Ese era el trabajo de la unidad central en los días en que la Web estaba en su infancia. Más bien, el punto de diseño para Internet era el simple intercambio de información a través de páginas individuales distribuidas a través de una amplia red de computadoras. En el diseño de sistemas, el objetivo es construir algo que funcione. La incorporación de la complejidad por sí misma no es aconsejable, francamente sacrílega y casi siempre es una receta para el desastre.
En su propia inmersión profunda en lo que salió mal con HealthCare.gov, The Washington Post publicó un gráfico ahora famoso que describía los diversos desafíos experimentados por el sitio. El lenguaje utilizado por el periódico para describir el sitio es bastante revelador, especialmente si considera que este es el periódico establecido de Washington, DC, el epicentro del gobierno federal de los Estados Unidos:
HealthCare.gov, creado por 55 contratistas, es una de las piezas de software más complejas jamás creadas para el gobierno federal. Se comunica en tiempo real con al menos 112 sistemas informáticos diferentes en todo el país. En los primeros 10 días, recibió 14, 6 millones de visitas únicas, según la administración de Obama.
Fuente: The Washington Post
Podría decirse, por definición, que alguien puede afirmar que tiene un software, debe ser el caso de que el software realmente funcione. De lo contrario, tiene una compilación de código que aún no constituye una pieza de software. Aparte de eso, tenga en cuenta los números enumerados, especialmente la parte sobre la comunicación "en tiempo real" con 112 sistemas informáticos diferentes en todo el país. Este es un ejemplo perfecto de glorificar la complejidad por sí misma.
"Sabemos que otra posibilidad es haber creado un sistema de corretaje web simple y muy simple, que todo lo que hace es mediante un código de servidor de aplicación muy simple e incluso Javascript más simple del lado del cliente, crea una interfaz muy agradable que produce datos acumulados para las personas ", Dijo Malafsky. "Esto es lo que puedes hacer: pasar por esto; pasar por esto. Luego, cualquier acción que ocurra puede hacerse en el punto de selección y enviarse a alguien que realmente será el dueño del programa". Por supuesto, ese "alguien" se refiere a las compañías de seguros que serán propietarias de las pólizas de todos modos.
El gráfico gráfico
Los diseñadores de sistemas de todo el mundo deben haberse encogido al ver ese gráfico. Echemos un vistazo a los diferentes pasos descritos, y en particular, los problemas graves que surgen con una arquitectura tan ambiciosa. En primer lugar, consideraremos la cantidad de transacciones potenciales que han fallado hasta ahora, la mayoría debido a tiempos de espera de software, instancias en las que una parte del proceso de transacción no recibe los datos necesarios dentro de un período de tiempo aceptable.
"Cada pieza de software en ese gráfico tenía sus propios tiempos de espera, y ni siquiera es un tiempo de espera. Puede ser más", dijo Malafsy. "La expiración de cualquiera de ellos matará la transacción completa. Algunos de ellos son fáciles de configurar y monitorear, como los archivos de registro. Esos son como los tiempos de espera en el servidor web y el servidor de aplicaciones. Algunos son más opacos. bases de datos con concurrencia y desencadenantes, pero son de interacción múltiple. Si realmente profundiza en cómo funcionan las bases de datos, no es una vista bonita ". (Aprenda los conceptos básicos de cómo funcionan las bases de datos en nuestro Tutorial de bases de datos).
"A los servidores de bases de datos les encanta decir: 'Mantenemos todo ordenado". En realidad, no ", dijo Malafsky. La única forma en que pueden mejorar el rendimiento y realmente administrarlo es que hay una serie de archivos con marca de tiempo que se crean en el almacenamiento, almacenamiento persistente, y no se agrupan en uno conjunto de datos completo y preciso que está disponible para cualquier persona en cualquier momento porque eso lleva demasiado tiempo. Eso mataría la latencia transaccional. Hay que mirar esos detalles y luego se acumula a través de una interfaz de administración, y eso pasa por algo muy sofisticado nombres como disparadores y concurrencia, pero básicamente significa que lleva un montón de tiempo obtener los datos, actualizar los datos, y si no puedo hacerlo antes de que llegue otra solicitud, solo voy a decirte, ' Olvídalo. Estoy cerrado por negocios '".
- "La puerta delantera"
El gráfico del Washington Post incluye una información muy curiosa justo en la parte superior de su primera sección "problema", donde dice que "la administración de Obama decidió a fines de septiembre excluir por ahora una característica que hubiera permitido a la gente comprar". planes de salud sin crear primero una cuenta en línea ".
Guau. En primer lugar, ¿es realmente una "característica" que fue excluida? Estamos hablando del flujo fundamental del sitio. Originalmente, el plan era dejar que las personas compraran, luego, en el momento apropiado, considerar registrar una cuenta.
Algunos críticos han especulado que este cambio de último minuto (en sí mismo, un movimiento increíblemente arriesgado con un proyecto tan grande), muestra que la administración sabía que el sitio no estaba funcionando bien en las últimas dos semanas antes del lanzamiento del 1 de octubre. . En cambio, la idea se convirtió en capturar toda la información de aquellos que necesitaban un seguro, de modo que se pudieran hacer esfuerzos de marketing en algún momento una vez que el sitio funcionara.
Desde una perspectiva de usabilidad y capacidad, este movimiento de último minuto ejerció una gran presión sobre la base de datos que tenía el sitio. Esto explica todas las anécdotas de personas que no pueden registrarse o se ven obligadas a cambiar sus contraseñas. Y seamos honestos aquí. ¿Hay algún problema más resuelto en todo el mundo que el proceso de configuración de una cuenta de usuario? Yahoo, Google, Microsoft, YouTube, Twitter, LinkedIn, incluso la clase de tejido de punto de su abuela, tiene su propio formulario de registro dinámico en estos días, con cancelación de suscripción, avance y otras características fundamentales. - Registro
Cuando llegó el momento de registrarse en HealthCare.gov, los contratistas dijeron: "La comunicación entre algunos de estos sistemas no funcionaba correctamente, lo que significa que muchos usuarios no pudieron crear una cuenta con éxito".
¿Qué? Que sistemas ¡Estamos hablando de una base de datos de clientes! Los "sistemas" serían el cliente web y la base de datos de clientes. ¿Qué otros sistemas estuvieron involucrados? Esta "explicación" particular no tiene sentido. - Prueba de identidad
A continuación, prueba de identidad. Para este paso, no se enumeran problemas, lo que también es curioso. Experian aparece como el agente externo que "verificará" la identidad de alguien. Sin duda, la resolución de identidad es un problema grave que debe abordarse. La mayoría de las compañías de seguros usan su número de Seguro Social, así como también proveedores externos como Experian. ¿Realmente no hay problemas con este paso?
Sabemos con certeza por numerosas anécdotas, verificadas por la documentación presentada, que HealthCare.gov definitivamente ha experimentado brechas de información confidencial. Malafsky señala que los problemas de calidad de los datos son mucho más graves que los problemas de capacidad. (Y Bloor señala que si los problemas de capacidad realmente fueran los problemas, deberían haberse resuelto en días, no en semanas. Puede agregar hardware, virtualizar, hacer cualquier cantidad de problemas de capacidad).
No, los problemas de calidad de los datos son los realmente peligrosos. Y el aspecto más preocupante de todos es el tipo de problemas de calidad de datos que han surgido. ¡Hay historias de personas que se registran y luego reciben documentos confidenciales de elegibilidad que pertenecen a otros registrantes! Esto huele a un diseño absolutamente terrible debajo de las cubiertas. ¿No usan algún tipo de código de identificación universal para cada persona?
"El movimiento inteligente sería crear un identificador universalmente único (UUID), almacenar valores encriptados (nota plural) de lo que podría ser información única (SSN, DOB, edad, biometría), y luego evaluarlos en busca de evidencia de personalidad única". Dijo Malafsky.
Que alguien pueda recibir los documentos confidenciales de una persona diferente es indescriptiblemente malo y demuestra algunos problemas de mapeo muy serios en el vientre de la bestia. - Elegibilidad
OK amigos. ¡Aquí es donde la vida se pone interesante! Si su transacción no había expirado por ahora, casi seguramente lo hizo en este paso. Según el gráfico de The Washington Post, "El sistema debe determinar la elegibilidad para recibir ayuda financiera enviando la información personal del consumidor a un Data Hub que contrata a docenas de agencias federales y estatales".
Intentar ejecutar una transacción en tres o cuatro sistemas clave es un verdadero desafío. Intentar llegar a "docenas" de agencias estatales y federales "en tiempo real" está fuera de lugar y es completamente innecesario. Malafsky solo tomó un punto de interacción para exponer su caso:
"Uno de los más obvios aquí es obtener datos financieros por persona para determinar si merecen un subsidio o cuál sería su precio, por lo que nos dirigimos al IRS. Ahora, tenemos algún enlace allí, pero ese enlace está activo Eso significa que cuando el usuario está sentado allí esperando en la pantalla de su computadora, tiene que hacer un enlace a los sistemas del IRS. En un mundo perfecto, ese enlace sucede, las computadoras hablan, obtengo mi resultado y regreso.
"¿Qué pasa en el mundo real? ¿Qué pasa cuando los sistemas IRS están sobrecargados? ¿Qué pasa cuando están en capacidad? ¿Qué pasa cuando tal vez están haciendo mantenimiento? ¿Qué pasa si se trata de una red entre el centro operativo de la red del nivel de entrada? Página web que el cliente ve al centro del IRS. Quizás haya algunos problemas allí. Quizás haya un virus. Quizás haya un caballo de Troya corriendo y las telecomunicaciones hayan cerrado las cosas para resolver ese problema. Eso matará la transacción desde el punto de vista del usuario. Ese es solo uno de los muchos puntos en esta arquitectura ", dijo Malafsky.
Su punto es que todos y cada uno de esos sistemas, ya que este archivo web fue diseñado para HealthCare.gov, todos y cada uno de ellos son un talón de Aquiles potencial. Esa es una situación de no ganar. Y de nuevo, es innecesario desde la perspectiva del flujo de trabajo. Hay varios puntos en el camino en los que el flujo de trabajo podría aumentarse con marts de datos casi en tiempo real, marts de datos en el momento adecuado, incluso la intervención humana para abordar los principales puntos de falla de la automatización.
El gran error estratégico, por lo tanto, fue tratar de lograr un sitio tan increíblemente complejo. - Comprar un plan
Recuerde: se suponía que este era el flujo original del sitio. Los internautas primero comprarían un plan de seguro. Luego, cuando encuentran algo de interés, pueden registrarse para obtener una cuenta, buscar subsidios si lo desean y, en última instancia, comprar un plan.
Según el gráfico, "a algunas personas con bajos ingresos se les dice que no son elegibles para subsidios o que no califican para Medicaid, aunque deberían". La pregunta aquí es: ¿Por qué este problema aparece en el Paso 5 en lugar del Paso 4? Este es un problema asociado con el paso anterior que no se calculó adecuadamente y, por lo tanto, no se factorizó correctamente en el Paso 5. - Traducción de seguros
En nuestro mundo, llamamos a esta parte ETL. Es un problema tan resuelto como el registro del sitio.
- Inscripción de seguros
¡El Santo Grial! Pero espere, hay un último "problema técnico", según los contratistas de HealthCare.gov: "Los informes, conocidos como 834, a veces son confusos y duplicativos, lo que dificulta a las compañías de seguros saber quiénes son realmente sus nuevos clientes".
Tomemos un momento de silencio para apreciar esto …
Entonces, sí, de hecho, una compañía de seguros debe saber a quién está asegurando realmente. Ese es un componente bastante crítico. Lo mismo ocurre con un trabajador de emergencias que sabe a qué persona tratar, o un médico que sabe en qué cofre se debe trasplantar un corazón. En el negocio de los medios, podríamos caracterizar esta pequeña cancioncilla como un caso de nuestros contratistas federales que enterraron con éxito el lede. - Cobertura
Por último, pero no menos importante, el gráfico establece que "los funcionarios de la administración dicen que los compradores han presentado más de 700, 000 solicitudes de seguro de salud. Algunos de ellos llegaron a través de HealthCare.gov y otros a través de mercados estatales. Pero los funcionarios se niegan a decir cuántas personas se han inscrito en un plan."
Accionamiento manual
Quizás la curva más aguda lanzada recientemente a la mezcla fue el movimiento para promover las aplicaciones en papel debido a los desafíos de funcionalidad del sitio. Desafortunadamente, incluso los formularios en papel deben enviarse al sitio que no funciona. Por definición, eso no es una anulación manual. Por definición, una anulación manual debe permitir que alguien o algo anule manualmente el sistema automatizado.
Y ahora, al momento de la publicación de este artículo, escuchamos que para el relanzamiento de HealthCare.gov, la administración confía más en las compañías de seguros para solucionar los problemas. Adivina lo que eso significa: apuesto a que donas a dólares (sí, solía ser al revés), que lo que está sucediendo en este momento es un caso de extracción y reemplazo generalizado. Específicamente, los programadores e ingenieros probablemente han eliminado muchas de las "conexiones en tiempo real" y otros middleware intensamente costosos que entusiasmaron tanto a los editores del Washington Post. Reemplazar todo ese código complejo son conexiones mucho más simples y de mayor latencia que son alimentadas por una gama de datos de marts vinculados a través de un entorno por lotes a los diversos sistemas estatales y federales.
En otras palabras, el tipo de solución que sugieren Malafsky, Bloor y McAfee es hacia dónde vamos. ¿Y todo ese elegante código de espagueti que estos contratistas federales gastaron 500 millones de dólares construyendo durante los últimos tres años y medio? En el contenedor de objetos punzantes.
Plomo Enterrado
Y una nota final: según el testimonio ante el Congreso de Henry Chao, subdirector de información de los Centros de Servicios de Medicare y Medicaid, ¿el sistema de pago que reembolsará a las compañías de seguros con todos esos subsidios federales? ¡Aún no se ha construido! Eso significa que este podría ser el primer sitio de comercio electrónico a gran escala que se haya lanzado sin un medio de trabajo para transferir dinero.
