¿Por qué la TI de Obamacare está fallando tanto? ¿Puede la administración de Obama corregir rápidamente estos fracasos?

Revisando esta pregunta ocho meses después, es interesante leer todas las publicaciones de expertos de derecha autodenominadas que predicen la falla total del sistema, y ​​observar cuán equivocadas han sido esas predicciones.

Me impresionaría si algunas de estas personas revisaran sus afirmaciones ahora y explicaran por qué estaban tan equivocadas en su evaluación de si la administración de Obama podría solucionar los problemas.

No tal suerte.

Además, ninguno de sus análisis mencionó cómo el Partido Republicano saboteó el sistema. El sistema federal nunca tuvo la intención de ser un sistema nacionalizado. Solo fue diseñado para ser una copia de seguridad en caso de que un estado no pudiera hacer su propio sistema. Nunca se le ocurrió al presidente que el Partido Republicano realmente no creía en el federalismo, que no establecerían sus propios sistemas estatales, como lo hicieron los estados liderados por los demócratas.

El presidente Obama no se dio cuenta de cuán dispuesto estaba el liderazgo republicano a perjudicar a sus propios votantes por su ventaja partidista. Y funcionó. Hasta la fecha, una pequeña mayoría de los estadounidenses cree que “Obamacare” es una falla costosa, cuando de hecho es un éxito rentable. Eso es lo que le puede permitir gastar casi medio billón de dólares en anuncios de ataque.

El sistema federal recibió mucho más tráfico de lo que estaba diseñado para manejar. Pero el presidente trajo a un grupo de bateadores pesados ​​de Silicon Valley y arregló el sistema, esta vez tomando en serio el plan de sabotaje republicano. Y ahora funciona: funciona mucho mejor que la mezcolanza antipática de los planes privados que reemplaza.

Es curioso cómo esta noticia nunca ha recibido la menor mención en el Fox News Channel o en los cientos de estaciones de la extrema derecha de Hate Radio …

Vea mi respuesta completa aquí Respuesta anónima a los errores de escala: ¿es posible que los protocolos que facilitan la comunicación en Internet hayan provocado el fracaso durante el primer día de lanzamiento de Obamacare?

Fui parte de uno de los equipos de desarrollo de sitios web de Exchange basados ​​en el estado y descubrí los siguientes problemas:

1. Muy menos tiempo para desarrollarse. Desarrollar un producto masivo dentro de un año o 6 meses simplemente no es posible.
2. La recolección de requisitos se hizo como una broma. Equipo funcional incompetente y decisiones lentas del otro lado como lo que necesitan.
3. Equipo de desarrollo con visión cero como qué construir. La falta de perspectiva técnica.
4. Reparar los errores es más importante que buscar funcionalidad de extremo a extremo.
5. Muchas dependencias en el Sistema Externo que ni siquiera funcionó hasta unos días antes del lanzamiento.
6. Cambios de último minuto en el código.
7. Sin automatización en las pruebas. Todo se probó manualmente y los evaluadores tienen motivos para completar el caso de prueba, de modo que la calidad se cumple.
8. @ Más papeleo, informar y seguir los procesos que el desarrollo.
9. Project gestiona el enfoque en la entrega de la funcionalidad sin ninguna revisión de código.
10. La mayoría de los desarrolladores senior trabajaban como líderes del equipo y la mitad del tiempo se gastaban en informes de estado y otras actividades similares.
11. Y nuevamente limite el conocimiento técnico. Algunos desarrolladores de mediana experiencia estaban haciendo la administración del sistema, corrigiendo el rendimiento y desarrollando la parte más compleja del código simplemente buscando en Google sin saber implicaciones
12. Sin carga, prueba e indisponibilidad de la configuración adecuada del entorno de ensayo antes de hacerlo.
13. Muchos equipos dentro del proyecto trabajan en reclusión sin siquiera pensar en problemas potenciales que pueden llegar tarde

Todos estos y más conducen al fiasco, no a Internet. La prueba de carga se realizó en el entorno UAT / SIT (con 1 o 2 servidores) y los resultados se escalaron teóricamente mientras que el entorno de prueba ni siquiera estaba en funcionamiento.

EDITAR :: Agregado para responder debajo de la parte

¿Son los fracasos los que la administración de Obama puede corregir rápidamente?

Problemas técnicos en el sitio web : SÍ. (Todavía muy lento, ya que deberían haber reparado en una semana)

Cuestiones de seguridad : podría tomar algún tiempo. El código está escrito de una manera que no tardaría en descubrir los detalles de la persona. (Hay un caso que recientemente ha surgido al encontrar el nombre de usuario / contraseña de cualquier usuario – Ya arreglado). Nombre de usuario / contraseña no es lo único. Detalles de ingresos / impuestos de una persona / detalles del hogar, todo está en riesgo.

Problemas de política : debería tomarse la mayor parte del tiempo para solucionarlo. Un pequeño problema en el código puede hacer que una persona sea elegible para Medicaid. (Aunque pueden apelar por eso), han empezado a surgir problemas. 834 Los archivos son un gran ejemplo.
Por encima de eso, no estoy seguro de si la Ley de Cuidado de Salud a Bajo Precio del Mercado de Seguros Médicos ha escrito una regla de tal manera que se realice cualquier cambio en las leyes estatales relacionadas con hix, pueden reflejarse fácilmente allí.

Problemas de sincronización: CMS / Fed Hub / Payment Gateway / Quality Center / DHS / muchas otras entidades más tiempo están involucrados en él. La clave es que no funciona una sola entidad. Si una cosa falla la inscripción / finalización de la solicitud no será exitosa. La mayoría de los problemas enfrentados en estados como Kentucky / Rhode Island son los principales centros de datos y no del sitio web en sí.

Ian McCullough responde perfectamente al punto anterior. El tiempo de integración es el mayor problema aquí.

No estoy de acuerdo con el punto de que si el estado puede hacerlo fácilmente, ¿por qué no puede ser federal? No hay coincidencia del trabajo. Tienen menos aseguradoras, personas menores que accederán al sitio web, requisitos y características casi insignificantes y complejidad del código.

Mi opinión es ligeramente diferente de lo que leerá en la web. Lo veo como una trifecta de problemas:

1. Adquisiciones federales de TI: este mundo está desconectado del resto del mundo y de la realidad. No es de extrañar, es política pura, de una lista de proveedores “seleccionados” de contratistas “preferidos”. Todo el proceso de licitación es tan bizantino y complejo, que muy pocos tienen el tiempo o la paciencia para atravesar el proceso, por lo que terminamos con los mismos proveedores, para la mayoría de los proyectos de TI federales. Las empresas externas * pueden * probar este proceso una vez, hasta que vean cómo funciona, entonces simplemente nunca regresan. Aquí hay una lista de los 100 principales, y los nombres tienen perfecto sentido: Lockheed Martin, Northrup Grumman, Boeing, SAIC, HP, etc. Estas compañías están bien versadas en contratos GRANDES y largos que rara vez llegan a tiempo, o que están cerca del presupuesto. Top 100 de tecnología de Washington de 2012 – Tecnología de Washington La idea de que podrían llegar a tiempo con una “fecha fija” es / era una expectativa irracional.
2. Infraestructura existente: todo el mundo aquí es anticuado, principalmente porque rara vez se destina dinero a actualizaciones importantes. Un informe reciente destacó que más de 65,000 puentes en los Estados Unidos son “estructuralmente deficientes” y alrededor de 21,000 son “críticos para fracturas”. Alrededor de 8,000 son ambos [10 cosas: dar sentido a los malos puentes de la nación]. Los 8,000 están distribuidos en los 50 estados. Si así es como vemos (y tratamos) la infraestructura que todos podemos ver (y usar), solo imagine cómo se traduce en una burocracia federal algo así como software. No es así Windows95, pantalla verde, código heredado, todo muy evidente en el nivel de TI federal. El usuario [CTO de Rackspace] fue citado en USA Today la semana pasada: “Es un problema central en el sentido de que es fundamental para que esto realmente funcione, pero no es necesariamente un problema al que las personas que escribieron HealthcareDotGov puedan acceder. HealthcareDotGov era un sistema perfecto, todavía no funciona “. A lo que se refiere, por supuesto, están todos los sistemas de back-end anticuados con los que HealthcareDotGov tiene que interactuar.
3. HHS / CMS: puede subcontratar todo lo que desee , pero al final , existe un Departamento Federal que debe asumir la propiedad y la responsabilidad de todas las especificaciones del sistema. Por definición , ese es el principal punto de estrangulación. El contratista principal de Health Insurance Marketplace, Affordable Care Act (una compañía llamada CGI) dependía de HHS / CMS para esas especificaciones. Como entidad federal (con un presupuesto federal y empleados federales), tanto el HHS como el CMS están a merced de la furiosa batalla política sobre toda la ACA. Del New York Times:
   

   Para evitar dar municiones a los republicanos que se oponen al proyecto, la administración pospuso emitir varias reglas importantes hasta después de las elecciones del pasado mes de noviembre. La casa controlada por los republicanos bloqueó los fondos. Más de 30 estados se negaron a establecer sus propios intercambios, requiriendo que el gobierno federal ampliara ampliamente su proyecto de maneras inesperadas. “ New York Times – 10/12/2013 [1]

Esos estados recalcitrantes también esperaron hasta el último momento posible para anunciar su decisión. Esta no fue una acogedora asociación federal-estatal. De hecho, esto fue un intercambio de dumping en el Gobierno Federal de cualquier manera que realmente podría ayudar con el fracaso.

Ahora bien, esto podría haber funcionado mejor, ciertamente diferente, si hubiera uno o dos de los anteriores, pero con los 3, el proyecto estaba condenado mucho antes del 10/1/2013.

Es arreglable? Absolutamente. Ya se han realizado progresos sólidos, y el sitio web no es la única forma de inscribir a los solicitantes. Originalmente, HHS predijo que el 30% de las aplicaciones se basarían en papel.

¿Estoy defendiendo los errores? No, pero entiendo el contexto mucho más amplio en el que se hicieron. Rara vez hay una sola variable en un proyecto de este tamaño y alcance.

Al final, todo refleja la política en torno a la propia ACA. La ACA ha sobrevivido muchas matemáticas diferentes. Sobrevivió matemática electoral (dos veces), matemáticas SCOTUS y luego matemáticas legislativas (dos veces). Esto es solo una matemática diferente. Llámalo matemática de integración de sistemas. En el caso del Gobierno Federal, las matemáticas SI nunca han sido, y probablemente nunca lo serán, una fortaleza clave.

=======================
[1] Desde el principio, Signs of Trouble at Health Portal

Tres razones principales:

1. La parte delantera del intercambio federal fue hecha por una compañía, y la parte posterior hecha por otra. No se comunicaron adecuadamente entre sí durante el desarrollo, por lo que han surgido problemas basados ​​en la mala comunicación entre las dos partes.
2. Cada vez que se lanza un nuevo sistema nacional o mundial en línea, la carga máxima siempre llegará el PRIMER DÍA. Sin las pruebas de estrés adecuadas, muchos sistemas fallarán por completo en la avalancha de personas. Para ver ejemplos de esto, solo mira los problemas del día de lanzamiento de cualquier videojuego con un requisito siempre en línea.
3. La administración Obama esperaba que más estados hicieran sus propios intercambios y redujera la cantidad de trabajo en el sistema federal. En cambio, más del 60% del país viene al intercambio federal en lugar de uno estatal.

En cuanto a si se puede arreglar rápidamente, es imposible responder a menos que uno trabaje para la compañía que desarrolló el back-end del intercambio federal.

Respuesta corta: Porque la televisión, los periódicos y las fuentes en línea le dicen que sí.

Respuesta larga: un gran programa del gobierno, que involucra quizás a decenas de millones de personas que intentan completar complicados formularios en línea, está teniendo problemas. ¿Alguien tenía la impresión de que esto no iba a ocurrir?

Los principales paquetes de software de empresas CUYO SOFTWARE DE NEGOCIO PRINCIPAL falla rutinariamente. Un gigante del software no identificado cuyos programas de “oficina” se usan en todo el mundo, lanza sus productos mientras obliga a sus compradores a depurarlos. Todos están “bien” con eso.

La agencia pública más grande del mundo lanza una interfaz que tiene numerosos fallos y fallas en las primeras semanas y todos están sorprendidos y asombrados de que haya fallas y problemas técnicos importantes.

Que extraño.

El sistema eventualmente superará la mayoría de sus fallas actuales y la mayoría de las personas podrán usarlo si lo logran. Ese hecho no genera noticias “sexys” y no se informa como resultado.

No sé exactamente nada acerca de Obamacare IT, sin embargo, me parece un problema bastante conocido de TI empresarial magnificado por el tamaño y el alcance. Fue, después de todo, un proyecto que se le dio a un proveedor de TI empresarial de primer nivel.

Aquí están los problemas:

• Tratarlo como un “Proyecto empresarial”
• “Jardín amurallado” de TI empresarial y TI defensiva
• Obsesión por los “requisitos del usuario” (sí, lo explicaré a continuación)
• Falta de resumen
• Prácticas comerciales de IT Consulting
• Enfoque basado en la documentación

Un proyecto empresarial

¿Involucras a Google cuando desarrollas una aplicación que usa Google Earth? Por supuesto que no, es ridículo sugerir que su aplicación puede bloquear Google. Los vendedores de Internet tienen habilidades para desarrollar software que puede sobrevivir a un uso incorrecto e incluso hostil.

Sin embargo, para un proyecto empresarial, las pruebas de un sistema integrado es algo que se espera. Prueban de principio a fin todos los procesos comerciales afectados por el desarrollo.

Según tengo entendido, el proyecto fue entregado a un integrador de sistemas empresarial. Estrictamente hablando, uno federal más cincuenta gobiernos estatales representan una empresa extendida, sin embargo, es una tarea demasiado grande tratarlo de esa manera. Obviamente, nadie hizo pruebas que requeriría un proyecto empresarial normal: no contaban con los fondos suficientes para realizar ese tipo de pruebas.

Jardín amurallado de TI empresarial y TI defensiva

Es una rareza que las fallas de Enterprise IT estén expuestas al público en general. En muchos casos, un proyecto de TI empresarial superará el presupuesto, se renegociará su alcance y se declarará un éxito.

“TI defensiva” es un patrón de ejecución de proyectos de TI con el único objetivo de minimizar la posible pérdida política. Eso genera cierto tipo de proveedores que se destacan en las ventas y navegan por el laberinto político, pero con una ejecución más bien poco óptima. (Descargo de responsabilidad: no conozco CGI Corp y no hago ningún comentario sobre esa compañía en particular)

Obsesión por los requisitos

Hace un par de décadas, comenzó una broma: “comience a codificar, y subiré las escaleras para descubrir lo que necesitan”. Sí, sucedió, sin embargo, desde entonces se convirtió en práctica de registrar cada capricho de cada persona que de alguna manera logró involucrarse, y tratarlos literalmente. El papel de alguien debería ser redundante por una solución de TI decente; en cambio, un par de Business Analysts trabajará durante meses para registrar sus requisitos muy detallados.

Los requisitos para ese proyecto en particular tenían que ser bastante fáciles: usted tiene a su Stakeholder (el que está tomando el pelo ahora) representado por sus designados políticos, usted tiene la ley aprobada y los formularios de solicitud de todos los proveedores de seguros (como secundarios a la ley) – luego diseña una ontología (si no está ya diseñada) y busca la ley para reglas comerciales. En cambio, estoy seguro de que recibieron una gran cantidad de declaraciones de requisitos basadas en las prácticas actuales sin ninguna justificación.

Falta de resumen

¿Te imaginas Facebook donde “enviar actualizaciones sobre mi desayuno”, “publicar una broma” son funciones codificadas individualmente, junto con miles y miles de otras?

Las buenas soluciones de software se producen al idear abstracciones efectivas, produciendo primero la implementación de esos fundamentos, luego abordando detalles particulares con metadatos, reglas, etc. u organizando esos detalles.

En general, Enterprise IT no hace bien la abstracción, por muchas razones, incluidas las que se enumeran más arriba y más abajo. Sin embargo, el problema clave de la abstracción es que no sobrevive bien a la política de la oficina. (Los psicópatas de la oficina odian la abstracción, pero ese es otro tema)

Prácticas comerciales de consultoría informática

Una de las razones clave por las que la abstracción no se hace cargo y la avalancha de requisitos detallados continúa es que encaja muy bien con el modelo de negocio de los principales proveedores de IT Consulting / Integración de sistemas.

Es un error decir que los grandes equipos de IT Consulting obtienen ganancias al recaudar márgenes en el personal. Obtienen ganancias recogiendo margen en personal menos calificado : a los especialistas destacados se les debe pagar mucho para evitar que se vuelvan independientes, y para cuando agreguen su viaje para reunirse y asistir a conferencias, hay poco margen para hacer. Sin embargo, ese vertedero de requisitos detallados exige un ejército de desarrolladores poco calificados, formas individuales de codificación de spaghetti y condiciones individuales, todo mientras se les paga una fracción de sus tarifas facturables.

Enfoque basado en la documentación

Prácticamente cualquier proyecto de TI de la empresa pasa por varias etapas de especificaciones. Esas especificaciones se producen con un enorme esfuerzo, aunque raramente se leen.

La documentación como texto tenía algún sentido cuando la Descomposición funcional era el rey: la estructura de un documento se reducía de forma natural a secciones más pequeñas de la misma manera. Sin embargo, la documentación de la solución Objeto / Componente / Orientada a Servicios con un buen grado de reutilización en documentos impresos es prácticamente imposible, ya que cada sección puede depender de muchas otras partes del documento.

La superposición de varias capas de abstracción combinada con herramientas que permiten una navegación efectiva y cortar y cortar en cubitos puede resolver eso, sin embargo, ese enfoque a menudo es demasiado para “TI defensiva”.

Divulgación: esta publicación aboga por prácticas que son proporcionadas comercialmente por Business Abstraction

No he profundizado en los problemas técnicos específicos que afectan el despliegue (aunque ciertamente invito al Departamento de Salud y Servicios Humanos de EE. UU. A contratar mis servicios profesionales). Dan Munro ha destacado el grosero error político original de que todos los estados no aprovecharían la oportunidad de construir y administrar sus propios sitios, dejando la tarea al Gobierno Federal para la mayoría de los estados. Podemos llamar a ese problema con la “aceptación de los interesados”. Además de eso, ya ha habido un montón de artículos sobre “mejores prácticas de desarrollo de software” que destacan cosas como sobreescalar y cortocircuitar el tiempo de prueba y todo tipo de cosas de otros libros de texto.

A los efectos de abordar esta cuestión aquí, mi respuesta breve es que, por lo que entiendo, el lugar en el que las cosas se han vuelto realmente feas es al tratar con los subsidios. Los intercambios no son una aplicación web independiente construida desde cero. Son ecosistemas altamente integrados que tienen que empujar y extraer datos hacia y desde una gama de entidades públicas y privadas existentes en tiempo real. Si la función de los intercambios consistía simplemente en permitir a los consumidores comparar planes de salud y presentar solicitudes a los proveedores, sería un trabajo desafiante con muchas partes interesadas, pero lo suficientemente sencillo como para finalmente cortar en muchas piezas del tamaño de un bocado. Los intercambios deben determinar si los consumidores son elegibles para recibir subsidios, confirmar cuánto califican y manejar el pago con la aseguradora elegida por el consumidor.

Dada la maraña de bases de datos y aplicaciones utilizadas en las agencias federales y en las diversas agencias de los distintos estados y sus respectivos grados de legado, eso no es más que un nudo de pesadilla de serpientes venenosas que escupen fuego.

Consulte este artículo de 2011: Guía de intercambio de seguro de salud: lo que necesita saber para comenzar.

Integración de sistemas e intercambio de datos

La integración en tiempo real entre el seguro privado y las opciones de cobertura de salud pública es otro requisito. La guía establece que los sistemas deben permitir la interoperabilidad con intercambios de información médica, agencias de salud pública, programas de servicios humanos y organizaciones comunitarias que brinden alcance e inscripción, y deben conectar a los consumidores no solo con programas de salud (integración vertical) sino también con el Programa de Asistencia SNAP), Ayuda temporal para familias necesitadas (TANF) y otros servicios humanos (integración horizontal).

Para permitir la interoperabilidad e integración previstas en la guía, se espera que los estados utilicen las pautas de datos del Modelo Nacional de Intercambio de Información (NIEM) para permitir el intercambio de datos consistente, eficiente y transparente entre programas y estados (Medicaid, CHIP, SNAP, TANF). NIEM permite el intercambio de información promoviendo un entendimiento semántico común entre las organizaciones participantes y los datos formateados de una manera semánticamente consistente; promoviendo esencialmente el nivel de estandarización necesario para lograr la interoperabilidad exigida en la orientación de ACA hasta la fecha. NIEM estandariza el contenido (estándares reales de intercambio de datos), proporciona herramientas y gestiona procesos (vea NIEM | Modelo de intercambio de información nacional | NIEM.gov para obtener más información).

Finalmente, se requieren transacciones estándar de HIPAA para inscribir a los consumidores en programas de cobertura de salud públicos y privados. La guía promueve el aprovechamiento de los estándares de transacción HIPAA existentes (p. Ej., HIPAA 834, 270, 271) para enviar y responder a consultas de elegibilidad, así como para transmitir datos de inscripción entre programas de seguros públicos y privados.

Procesos de verificación
La guía federal requiere que los estados utilicen verificaciones en tiempo real con agencias federales y otras a los fines de la determinación de elegibilidad para Medicaid, CHIP y subsidios, y para volver a certificar y cambiar las circunstancias para las opciones de cobertura de seguro médico.

La Guía recomienda el desarrollo de un “modelo de software de referencia” federal para obtener la verificación de la elegibilidad inicial, la renovación y el cambio en las circunstancias del consumidor. El gobierno federal está contemplando la creación de un “centro de verificación” para que los estados lo usen para verificar la información de un consumidor en las siguientes bases de datos:

• Servicio de ingresos internos
• Seguridad nacional
• Administracion de la Seguridad Social
• Directorio nacional de nuevos empleados
• Sistema de registro de verificación electrónica de eventos vitales (EVVE)
• Sistemas estatales de verificación de ingresos y elegibilidad (IEVS)
• Sistema de información de informes de asistencia pública (PARIS)
• Estandarización de direcciones del servicio postal de EE.

Los sistemas de inscripción también deberán facilitar consultas coordinadas y automatizadas a través de múltiples programas para determinar si un consumidor es conocido por otros sistemas de elegibilidad e inscripción. Si el consumidor es conocido por otro sistema, el sistema de intercambio debería permitir la recuperación y reutilización de los datos de elegibilidad relevantes. La orientación también señala el uso de un enfoque de servicios web para respaldar las determinaciones de elegibilidad en otros programas de servicios humanos y de salud, incluidos Medicaid, CHIP, SNAP y TANF.

Si alguna vez trabajó en un sistema a gran escala o si alguna vez trabajó con el gobierno o, especialmente, si trabajó en sistemas gubernamentales a gran escala, esa lista debería generarle escalofríos.

Debido a la forma en que las compras y contrataciones federales funcionan (o no funcionan). Es lo que llamo el problema del “ratón que baila con el hipopótamo”. Las empresas pequeñas e innovadoras que realmente saben cómo hacer cosas (como programar un sitio web como Healthcare.gov) prácticamente no tienen ninguna posibilidad de GANAR el contrato para programar el sitio web. El proceso de compras federales se enfoca en ganar el contrato, no en realizar la función. La mayor parte del proceso de solicitud, por ejemplo, son los materiales de la placa de la caldera que tienen poco o nada que ver con el servicio o producto que realmente se requiere. En muchos casos, las empresas pequeñas / innovadoras ni siquiera pujarán porque están estupefactas por el proceso. Esto evita que se elijan las mejores y más novedosas soluciones para resolver algunos de los problemas más importantes.

Para agregar un poco de ligereza a esta pregunta, veo el problema ya que se subcontrata a una empresa con sede en Quebec que había sido despedida anteriormente por el gobierno canadiense y el gobierno de Ontario, en lugar de contratar el grupo de talento increíble en San Francisco.

Ciber ataques de derecha en el sitio web Healthcare.gov confirmados
¿Pueden los ataques cibernéticos de derecha chocar con el mercado de seguros de salud, Ley de asistencia médica asequible?
¿Es esto una guerra civil? Esto puede no afectar las aplicaciones ACA en papel, hablé con el Director del Programa 2 para el procesamiento de la aplicación de papel de ACA @ Corporación Serco, usan pantallas diferentes. Correo electrónico [email protected] Explicaré cómo difieren las aplicaciones de papel. Los datos de las aplicaciones en papel requieren menos pantallas de entrada y se pueden procesar en lotes nocturnos y no deberían tener tanto impacto en el portal para consumidores. Validé las aplicaciones de Seguridad Social. También envié este tweet @ todd_park. ¿El HHS tiene una copia duplicada del sitio web público 2A de ACA utilizado únicamente por navegadores y corredores que no estarían sujetos a ataques cibernéticos de denegación de servicio? ¿El HHS tiene una copia alternativa alternativa del sitio web público de ACA para ser utilizada solo por navegadores y corredores que no estarían sujetos a la denegación de servicio. Debido a la pobre arquitectura de Healthcare .gov, los derechistas podrían degradar el servicio sin un virus de denegación de servicio si suficientes de ellos iniciaban sesión al mismo tiempo y alternaban o saltaban a diferentes pantallas. Creo que el despliegue de Obamacare tampoco tiene una interfaz sólida entre humanos. Cuando comenzó Medicare, tomamos todo el año para inscribir a las personas y las oficinas de la SSA estaban abiertas las noches y los fines de semana.
Ya que:

1. Obamacare seguirá siendo complejo y cambiante
2. Implica declaraciones de impuestos
3. Los ciudadanos necesitarán un lugar para informar cambios y / o discrepancias en los ingresos
4. Los ciudadanos necesitarán un lugar al que acudir para resolver las disputas con las compañías de seguros

Será imperativo que Obamacare tenga presencia en la comunidad.
Trabajé para la Administración de Seguridad Social (SSA) durante 34 años y durante los últimos años se nos encomendó contactar a 10 de miles de ciudadanos para verificar los ingresos y los activos del programa de medicamentos con receta de la Parte D de Medicare. Y siempre manejamos las inscripciones en las Partes A y B. Contamos con más de 1300 oficinas en todo el país. Vea mi presentación al comité de formas y medios de la casa en whitecollargreenspace para un plan para implementar el servicio al cliente y la verificación de ACA de manera rápida y económica. A HHS le tomaría mucho tiempo y dinero hacerlo por su cuenta.
La SSA cuenta con un software para verificar los ingresos y los activos del programa de SSI, Ayuda Adicional con los Costos de los Medicamentos Recetados de Medicare y para cobrar primas más altas por la Parte B de Medicare a los clientes con altos ingresos. ¿Podría HHS haber usado algunas de las mismas rutinas de software y haberlas ajustado para Obamacare? Muchos programadores de la SSA fueron reasignados para crear el software de Ayuda adicional justo después de una importante reescritura del software de la Seguridad Social y varios años para solucionar todos los problemas técnicos de esa versión principal. La elegibilidad se basa en los ingresos del año anterior en lugar del año siguiente, como lo está Obamacare. Si las estimaciones de ingresos son demasiado bajas, miles le deben dinero al gobierno al final del año y habrá una necesidad de que hagan planes de pago o soliciten exenciones. Algo debe hacerse para que los requisitos de ingresos y activos para estos cuatro programas sean más uniformes.

Pasé 35 años en el negocio de software comercial con algunos de los grandes actores de la industria. Si bien no tengo ningún conocimiento directo de este proyecto en particular, fui uno de los líderes del proyecto en un producto de agregación de servidores que realizó algunas operaciones muy similares. Aunque ciertamente se basó en una escala más pequeña, nuestro producto sí creó el mismo tipo de conexiones de mainframe y agregaciones de datos que el cuidado de Obama también debe tener para poder hablar inteligentemente al respecto. Construimos nuestro sistema por una muy pequeña fracción del 1% del costo de esta nación Obama. La tecnología está disponible, construimos nuestros servidores en 1998-2002 y desde entonces se han realizado grandes mejoras.

El verdadero problema está en la gestión de adquisiciones y proyectos que tiene lugar cada vez que el gobierno está involucrado.

Hicimos varios proyectos gubernamentales y cada uno fue así. 1) El trato se consumó en un campo de golf donde el comprador no tenía idea de lo que estaba comprando. 2) Los requisitos para lo que se necesitaba siempre eran retrasados, siempre cambiantes, y casi siempre indescifrables. 3) Hubo tantos intermediarios involucrados que hubo 0 posibilidades de lograr un consenso sobre cuál debería ser el producto. 4) Cuando se entregó, hubo poca o ninguna validación de que lo que construimos fue lo que querían. Los compradores no estaban listos para la próxima adquisición.

Así que no tengo dudas de que todo el proyecto fue creado por alguien que tenía buenas conexiones políticas y 0 capacidades técnicas. Lo ofrecieron a empresas capaces a las que nunca se les dijo qué hacer exactamente. Luego, cuando se construyó, había 200 personas y empresas que recibían una parte de las tarifas y el crédito, pero había 0 empresas o personas que asumían la responsabilidad del trabajo.

Muchos proyectos a gran escala, incluidos sitios web, tienen muchos problemas al principio. Cuando Medicare se implementó por primera vez, tenía muchos problemas de registro y ataques políticos casi fatales (como los actuales ataques de la mayoría de los gobernadores republicanos). Espere un año o dos, y la AHA será tan popular e indispensable como Medicare.

Bueno, para empezar, Obamacare NO está fallando. Han logrado inscribir a más de 7 millones de estadounidenses en el sitio web oficial de la Ley de Cuidado de Salud a Bajo Precio del Mercado de Seguros Médicos, que ahora funciona bastante bien. Este 7+ millones NO incluye un estimado de 1.3 millones de estadounidenses que se registraron directamente con compañías de seguros.

Y dos, las compañías de seguros involucradas han dado enormes donaciones a políticos que estaban en contra de cualquier tipo de plan de salud para los estadounidenses. La mayoría de los destinatarios financieros han sido miembros republicanos (GOP). Uno solo puede suponer, basado en la completa falta de alternativas ofrecidas, que esos pagos al GOP se ofrecieron para oponerse, destruir o burlar cualquier esfuerzo de salud organizado.

No soy médico, pero he seguido este debate sobre la atención de la salud como un paciente cardíaco con mucho cuidado desde los días en que Hillary Clintons trató de brindar una mejor manera de mejorar la atención médica para los estadounidenses.

América es actualmente 37 ° en el ranking mundial de sistemas de salud. Para muchos, incluyéndome a mí, eso es inaceptable teniendo en cuenta que somos el número 1 en gasto sanitario a nivel mundial.

Tenemos una administración (la administración) que está ansiosa por adoptar la tecnología, lo cual es bueno. Pero, al mismo tiempo, tienen muy poco conocimiento de la tecnología y de lo que se necesita para que la tecnología funcione.

En otras palabras, está fallando de la misma manera que la mayoría de los programas fallan.

Todo cuesta más de lo que crees que será. Todo lleva más tiempo de lo que crees que será. Esperar para implementar una característica es siempre mejor que implementarlo hoy. La integración, incluso cuando ambas partes juran que están haciendo todo de acuerdo con los estándares, es siempre la parte más difícil y que consume más tiempo del proyecto.

Lo que el gobierno de Obama tiene en su defensa, que casi ningún otro equipo de administración tiene, es que la fecha no se pudo mover. Si se tratara de una empresa privada que lanza un nuevo producto, lo único inteligente que se podría hacer habría sido presionar la fecha porque simplemente no estaban listos. Esa no era una opción en este caso.

No es solo el software de EE. UU. El que tiene este problema. Gran parte del software actualmente se publica bajo una política de “sí,” sabiendo que hay errores menores o mayores en cada nivel, pero que exige un ingreso (en el mundo comercial) para financiar la corrección. Además, en el pasado las actualizaciones de corrección de errores han sido gratuitas para los usuarios, pero ahora se agregan a una actualización trivial y se les cobra.

Los desarrolladores de software del gobierno provienen del mundo de los desarrolladores en el que existen. Los tiempos y los costos para el desarrollo se basan y se comparan en gran medida con los del comercio, que con demasiada frecuencia son el software de basura exagerado por el reconocimiento.

En el Reino Unido, IMV, esta situación no se rectificará hasta que haya una acción de “idoneidad para el propósito” presentada sobre un software para enviar señales claras sobre los estándares razonablemente esperados por el técnico del Clapham ómnibus. Eso sacudirá la jaula. Sugiero además que el software de computadora es un paraíso para los abogados de propiedad intelectual y la idea de permitir que el software se construya sobre el éxito de otros envía escalofríos a su flujo de ingresos. La única razón por la que Internet se usa en todo el mundo y está libre de la mayoría de los errores es porque Berners-Lee renunció a sus derechos.

Respuesta corta: todo proviene de un problema particularmente atroz de Principal-Agent (aparentemente recursivo). Simplemente no estamos acostumbrados a verlo en la industria del software, y especialmente no en el 95% de las aplicaciones web / móviles de consumo utilizadas por Joe & Jane American hoy en día, dadas las estructuras de incentivos típicas de las nuevas empresas y las grandes empresas de Internet en estos días.

Los proyectos de software se deslizan incluso en compañías en las que todos tienen un capital sustancial; nadie debería sorprenderse por este resultado.

Hay un número de razones. Otros aquí han tocado varios de ellos, por lo que abordaré un problema fundamental con el complejo industrial del gobierno. En el sector privado de la industria tecnológica, las personas se mueven mucho y están constantemente expuestas a nuevas ideas y tecnologías. El sector privado también enfatiza la capacitación, ya que necesitan que su gente comprenda las tecnologías que cambian casi a diario. Las empresas contratistas con el gobierno, OTOH, tienden a atraer a las personas que buscan establecerse en un empleo a largo plazo. Existe poca o ninguna capacitación sobre las tecnologías emergentes y la elección de qué tecnología utilizar para un proyecto generalmente está dictada por personas que están muy alejadas de las líneas del frente. La elección del stack tecnológico a menudo se hace porque es lo que “siempre hemos usado” o por un acuerdo de ventas / licencias que no tiene nada que ver con lo que mejor se ajusta a las necesidades del proyecto.

Hay un incentivo para escribir software de vanguardia en el sector gubernamental, y este proyecto requirió absolutamente un conocimiento de las herramientas y las ideas que se crean y refinan casi a diario.

Algunas buenas respuestas aquí.

Evidentemente hay dos problemas, no solo uno.

Primero, tenemos un sistema grande y complejo que se ha improvisado en un período de tiempo ridículamente corto sin las especificaciones o pruebas adecuadas y que se está implementando en un entorno altamente politizado con muchas personas que se deleitan al ver que fracasa.

En segundo lugar, el sistema es, de hecho, una especie de Intersystem: una red de sistemas que tienen que comunicarse entre sí, cada uno de ellos operado por diferentes partes, diseñado y construido en diferentes momentos por diferentes desarrolladores que usan diferentes tecnologías y protocolos para personas con diferentes agendas.

CGI y las otras partes involucradas pueden hacer que el sistema tarde o temprano funcione. Tal vez. Pero luego veremos aparecer al verdadero elefante en la sala: mantenimiento. Dios ayude a todos los involucrados!

No tengo acceso a las estadísticas en este momento, pero la cantidad de sistemas de tamaño empresarial que nunca logran lo que se propusieron hacer a pesar de los incalculables millones de dólares que les arrojaron es aterradora. Es muy posible que los sistemas de TI de Obamacare tengan que ser reconstruidos desde cero.

¿Podría ser simplemente un proyecto ejecutado de manera incompetente? Después de todo, nos han dicho que varios estados (por ejemplo, Kentucky) han creado con éxito intercambios estatales que funcionan bien. Es de suponer que estos intercambios estatales tuvieron que lidiar con la mayoría o la totalidad de los mismos desafíos que enfrenta el intercambio federal, incluidos picos de tráfico, integración con diversos sistemas heredados, requisitos cambiantes, infraestructura antigua, etc.