Índice:
Primeiro nao faça nenhum mal! Esse decreto - parafraseado no Juramento de Hipócrates - permeia a assistência médica profissional, como tem acontecido desde o início da Medicina Ocidental, há cerca de 2.500 anos. Qualquer um pode apreciar a simplicidade e o significado desse mantra. Se você não faz mais nada como profissional de saúde, pelo menos não machuque seu paciente.
Escrito na corrente subjacente dessa frase, você pode encontrar uma humildade inegável. De fato, para todas as diversas e variadas avenidas da ciência, existe um axioma crítico: esteja sempre disposto a questionar suas suposições. Sabemos apenas o que sabemos e com certeza ainda não sabemos tudo, e nunca saberemos. Deixe que essa sabedoria sirva de cautela para suas prescrições mais fortes.
Depois, há a parte do fazer. Em qualquer empreendimento da vida, espera-se conhecer algo importante e, em seguida, tomar as medidas apropriadas. Cuidado é o mesmo que cuidado, e quando se cuida da vida de outras pessoas, a seriedade é necessária. Com essa perspectiva como nossa tela e um entendimento da tecnologia da informação (TI) sob nossos cinturões, vamos dar uma olhada no lançamento do HealthCare.gov, o carro-chefe frequentemente caracterizado da Affordable Care Act, também conhecido como "Obamacare".
Suporte de vida
Quão franco posso ser? HealthCare.gov estava morto na chegada. A transparência coletiva agora diz que todas as seis pessoas se inscreveram no primeiro dia, 1º de outubro. Seis. Apenas 32.994 aquém da meta diária de 33.000. E enquanto os problemas de "capacidade" eram apresentados como elogios à demanda, qualquer pessoa com conhecimento da dinâmica da Web sabia mais.
"Este não é um problema não resolvido", observa o Dr. Robin Bloor, cientista de dados e cofundador do The Bloor Group. "A Holanda tem essa troca."
De fato, os holandeses estão à frente do jogo há duas décadas, com muitas lições aprendidas. Os suíços também têm alguma experiência e, é claro, Massachusetts tem o MAHealthConnector.org, chamado "RomneyCare".
Bloor continuou dizendo que 40 anos de experiência em TI provaram que grandes projetos sempre trazem grandes riscos.
"Faça um grande projeto, alto risco e alto risco de falha. Ter três anos e meio parece que, nos dias de hoje, isso seria suficiente, mas aqui está um projeto de alto risco e tudo acabou mal, "Disse Bloor.
Ele foi mais sincero sobre a maneira como os testes de integração foram realizados no HealthCare.gov.
"A última coisa que me fez, quase me fez rir, é que não há testes de integração até duas semanas antes de você ir ao ar - e é como, como você pode fazer isso com algo assim? Como você pode?" Bloor disse.
Compartilhando essa perspectiva, é um veterano contratado federal e um cientista de dados, o Dr. Geoffrey Malafsky da Phasic Systems Inc. Malafsky recentemente ofereceu uma avaliação detalhada de uma hora da implementação do HeathCare.gov e comentou as decisões estratégicas e táticas tomadas . Acima de tudo, ele aponta o protocolo de aquisição do governo federal.
"Um dos pontos críticos de falha que permeia particularmente os projetos governamentais de TI é essa noção herdada, arcaica e obsoleta de que você pode articular toda a lógica de negócios necessária com algum processo linear de requisitos. Isso fundamentalmente não funciona com grandes sistemas de TI", disse ele.
Seu argumento é que os grandes sistemas de TI afetarão até os planejadores mais inteligentes. Você nunca sabe de onde virão os problemas, onde precisará fornecer suporte extra ou em que tipo de solução de problemas se envolverá. Consequentemente, é uma má idéia restringir o processo de design, forçando os engenheiros de projeto a antecipar tudo eles precisarão antecipadamente.
Para complicar a situação, diz Malafsky, o fato de os funcionários de compras do governo federal terem se tornado tão poderosos - devido à grande quantidade de dinheiro que eles controlam - que eles estão essencialmente no controle de como os principais projetos de TI avançam. Isso coloca os funcionários do departamento no papel de suplicante e insere um elemento de risco em um procedimento crucial no centro de qualquer iniciativa de TI significativa: a escolha das ferramentas, tecnologias e prestadores de serviços certos.
"As pessoas que discordam mais profundamente dessa afirmação são chamadas de profissionais de aquisição, e eu as encorajo a aparecer em minha casa e vamos sentar e debater isso, porque tenho muitas evidências empíricas para apoiar isso", Malafsky disse.
Estratégia do site
Uma grande pergunta a ser feita é por que o governo adotou uma arquitetura tão abrangente para este site.
"Se o programa governamental abrangente for configurado de modo que as companhias de seguros sejam realmente donas do cliente depois de se comprometerem, por que não direcionar o tráfego para o canal do ambiente de interação com o cliente existente que as companhias de seguros já possuem? Sim, elas podem precisam aumentar os seus próprios, mas isso seria uma razão comercial válida, porque agora eles vão conseguir novos clientes ", disse Malafsky.
O renomado (e agora um tanto infame) pioneiro em software de segurança John McAfee também comentou essa estratégia recentemente, fazendo algumas observações controversas sobre o "Neil Cavuto Show" na Fox News:
"Oh, é muito ruim", disse McAfee. "Alguém cometeu um erro grave, não no design do programa, mas na simples implementação do aspecto da Web. Quero dizer, por exemplo, qualquer pessoa pode criar uma página da Web e alegar ser uma corretora para esse sistema … qualquer hacker pode colocar um no site, faça com que pareça extremamente competitivo e, devido à natureza do sistema - e, afinal de contas, este é o sistema de saúde - eles podem fazer as perguntas mais íntimas e você livremente responderá ".
Com relação à própria arquitetura da Web, Malafsky aponta para o óbvio - que a Internet não foi construída para executar aplicativos complexos. Esse era o trabalho do mainframe nos dias em que a Web estava em sua infância. Em vez disso, o ponto de design da Internet era o simples compartilhamento de informações por meio de páginas individuais distribuídas em uma ampla rede de computadores. No design de sistemas, o objetivo é construir algo que funcione. Incorporar complexidade por si só é desaconselhável, absolutamente sacrílego e quase sempre uma receita para o desastre.
Em seu próprio aprofundamento sobre o que deu errado com o HealthCare.gov, o Washington Post publicou um gráfico agora famoso que descrevia os vários desafios enfrentados pelo site. A linguagem usada pelo jornal para descrever o site é realmente bastante reveladora, especialmente quando você considera que este é o jornal estabelecido de Washington, DC, o epicentro do governo federal dos EUA:
O HealthCare.gov, construído por 55 prestadores de serviços, é uma das mais complexas peças de software já criadas para o governo federal. Ele se comunica em tempo real com pelo menos 112 sistemas de computadores diferentes em todo o país. Nos primeiros 10 dias, recebeu 14, 6 milhões de visitas únicas, segundo o governo Obama.
Fonte: The Washington Post
Indiscutivelmente, por definição, para alguém afirmar que possui um software, deve ser o caso em que o software realmente funciona. Caso contrário, você terá uma compilação de código que ainda não constitui um software. Além disso, observe os números listados, especialmente a parte sobre a comunicação "em tempo real" com 112 sistemas de computadores diferentes em todo o país. Este é um exemplo perfeito de glorificar a complexidade por si só.
"Sabemos que outra possibilidade é a criação de um sistema simples e muito simples de intermediação da Web, que tudo o que faz é através de um código muito simples do servidor de aplicativos e ainda mais simples do Javascript do lado do cliente, cria uma interface muito agradável que produz dados acumulados para as pessoas ", Disse Malafsky. "Aqui está o que você pode fazer: passar por isso; passar por isso. Em seguida, qualquer ação que ocorrer pode ser executada no ponto de seleção e enviada a alguém que realmente será o proprietário do programa". É claro que "alguém" se refere às companhias de seguros que serão as donas das apólices de qualquer maneira.
O Gráfico Gráfico
Os projetistas de sistemas em todo o mundo devem ter se encolhido ao ver esse gráfico. Vamos dar uma olhada nas diferentes etapas descritas e, em particular, nos problemas sérios que surgem com uma arquitetura tão ambiciosa. Em primeiro lugar, consideraremos o número de transações em potencial que falharam até agora, a maioria devido a tempos limite de software - instâncias em que uma parte do processo de transação não recebe os dados necessários dentro de um período de tempo aceitável.
"Cada software desse gráfico tinha seus próprios tempos limite, e não é nem um tempo limite. Pode ser mais", disse Malafsy. "A expiração de qualquer um deles matará a transação inteira. Alguns deles são fáceis de configurar e monitorar, como arquivos de log. Esses são como os tempos limite no servidor da Web e no servidor de aplicativos. Alguns são mais opacos. Você tem bancos de dados com simultaneidade e gatilhos, mas são multi-interações. Se você realmente se aprofundar em como os bancos de dados funcionam, não é uma visão bonita ". (Aprenda o básico de como os bancos de dados funcionam em nosso Tutorial de bancos de dados.)
"Os servidores de banco de dados adoram dizer: 'Mantemos tudo em ordem." Na verdade, não ", disse Malafsky. A única maneira de melhorar e gerenciar verdadeiramente o desempenho é que há uma série de arquivos com registro de data e hora criados no armazenamento, armazenamento persistente e que não são agrupados em um só conjunto abrangente e preciso de dados que estão disponíveis para qualquer pessoa a qualquer momento, porque isso leva muito tempo. Isso acabaria com a latência transacional. Você precisa examinar esses detalhes e depois ser agregado por meio de uma interface de gerenciamento - e isso é muito sofisticado e agradável. nomes como gatilhos e simultaneidade - mas basicamente significa que leva muito tempo para obter os dados, atualizar os dados e, se eu não puder fazê-lo antes que outra solicitação seja recebida, vou lhe dizer: Esqueça. Estou fechado para os negócios. '"
- "A porta da frente"
O gráfico do Washington Post inclui uma informação muito curiosa bem no topo da sua primeira seção de "problemas", onde diz que "o governo Obama decidiu no final de setembro excluir por enquanto um recurso que deixaria as pessoas comprarem" planos de saúde sem antes criar uma conta on-line ".
Uau. Primeiro de tudo, isso é realmente um "recurso" que foi excluído? Estamos falando sobre o fluxo fundamental do site. Originalmente, o plano era permitir que as pessoas comprassem, e no momento apropriado, considere registrar uma conta.
Alguns críticos especularam que essa mudança de última hora (por si só, é uma jogada incrivelmente arriscada com um projeto desse tamanho) mostra que a administração sabia que o site não estava funcionando bem nas últimas duas semanas antes do lançamento em 1º de outubro . Em vez disso, a ideia passou a capturar todas as informações daqueles que precisavam de seguro, de modo que esforços de marketing pudessem ser feitos para eles em algum lugar abaixo da linha assim que o site estivesse funcional.
Do ponto de vista da usabilidade e da capacidade, esse movimento de última hora colocou uma enorme pressão sobre qualquer base de dados que o site tivesse. Isso explica todas as histórias de pessoas que não conseguem se registrar ou são forçadas a alterar suas senhas. E sejamos honestos aqui. Existe algum problema resolvido mais detalhadamente em toda a Internet do que o processo de criação de uma conta de usuário? Yahoo, Google, Microsoft, YouTube, Twitter, LinkedIn - até a turma de tricô de sua avó - tem seu próprio formulário de inscrição dinâmico atualmente, com cancelamento de inscrição, encaminhamento e outros recursos fundamentais. - Cadastro
Quando chegou a hora de se registrar no HealthCare.gov, os contratados disseram: "A comunicação entre alguns desses sistemas não estava funcionando corretamente, o que significa que muitos usuários não conseguiram criar uma conta com êxito".
O que? Quais sistemas? Estamos falando de um banco de dados de clientes! Os "sistemas" seriam então o cliente da Web e o banco de dados do cliente. Quais outros sistemas estavam envolvidos? Essa "explicação" específica não faz sentido. - Prova de identidade
A seguir, prova de identidade. Para esta etapa, não há problemas listados, o que também é curioso. O Experian é listado como agente de terceiros que "verifica" a identidade de alguém. Sem dúvida, a resolução de identidade é um problema sério que deve ser tratado. A maioria das companhias de seguros usa seu número de Seguro Social, bem como fornecedores de terceiros como Experian. Realmente não há problemas com esta etapa?
Sabemos, com certeza, de várias histórias, verificadas pela documentação apresentada, que o HealthCare.gov experimentou definitivamente fragmentos de informações confidenciais. Malafsky ressalta que os problemas de qualidade dos dados são muito mais graves do que os problemas de capacidade. (E Bloor observa que, se os problemas de capacidade realmente eram os problemas, eles deveriam ter sido resolvidos em dias, não em semanas. Você pode adicionar hardware, virtualizar, fazer várias coisas para problemas de capacidade.)
Não, os problemas de qualidade dos dados são realmente perigosos. E o aspecto mais preocupante de todos são os tipos de problemas de qualidade de dados que surgiram. Há histórias de pessoas se inscrevendo e recebendo documentos confidenciais de qualificação pertencentes a outros registrantes! Isso parece um design absolutamente terrível por baixo das cobertas. Eles não usam algum tipo de código de identificação universal para cada pessoa?
"A jogada inteligente seria criar um identificador universalmente exclusivo (UUID), armazenar valores criptografados - observe o plural - do que pode ser informação exclusiva (SSN, DOB, idade, biometria) e depois avaliar esses dados para evidenciar uma personalidade única". Malafsky disse.
O fato de alguém poder receber documentos confidenciais de uma pessoa diferente é indescritivelmente ruim e demonstra alguns problemas de mapeamento muito sérios no fundo da barriga da besta. - Elegibilidade
Tudo bem pessoal. Aqui é onde a vida fica interessante! Se sua transação ainda não havia atingido o tempo limite, quase certamente ocorreu nesta etapa. De acordo com o gráfico do The Washington Post, "o sistema deve determinar a elegibilidade para obter ajuda financeira enviando as informações pessoais do consumidor a um Data Hub que contrate dezenas de agências federais e estaduais".
Tentar executar uma transação em três ou quatro sistemas principais é um desafio genuíno. Tentar atingir "dezenas" de agências estaduais e federais "em tempo real" está fora de cogitação e é totalmente desnecessário. Malafsky levou apenas um ponto de interação para defender seu argumento:
"Um dos mais óbvios aqui é obter dados financeiros por pessoa para determinar se eles merecem um subsídio ou qual seria seu preço, então vamos para o IRS. Agora, temos algum link por lá, mas esse link está ativo Isso significa que, como o usuário está sentado, esperando na tela do computador, que precisa fazer um link para os sistemas de IRS. Em um mundo perfeito, esse link acontece, os computadores falam, eu recebo o resultado e volto.
"E no mundo real? E quando os sistemas de IRS estão sobrecarregados? E quando estão em capacidade? E quando talvez estejam fazendo manutenção? E uma rede entre o centro operacional de rede do nível de entrada Página da Web que o cliente vê no centro do IRS? Talvez haja alguns problemas. Talvez haja um vírus. Talvez haja um cavalo de Tróia correndo e as telecomunicações desliguem as coisas para resolver esse problema. Isso matará a transação a partir do ponto de visão do usuário. Esse é apenas um dos muitos pontos dessa arquitetura ", disse Malafsky.
Seu argumento é que todos e cada um desses sistemas - como essa arquitetura da Web foi projetada para HealthCare.gov - todos e cada um deles são um potencial calcanhar de Aquiles. Essa é uma situação sem vitória. E, novamente, é desnecessário da perspectiva do fluxo de trabalho. Há vários pontos ao longo do caminho em que o fluxo de trabalho pode ser aumentado com data marts em tempo quase real, data marts no tempo certo e até intervenção humana para tratar dos principais pontos de falha da automação.
O grande erro estratégico, portanto, foi tentar alcançar um site tão incrivelmente complexo. - Comprando um plano
Lembre-se: esse deveria ser o fluxo do site original. Os internautas comprariam primeiro um plano de seguro. Então, quando encontrassem algo interessante, poderiam se registrar em uma conta, procurar subsídios, se desejassem e, finalmente, comprar um plano.
De acordo com o gráfico, "algumas pessoas com baixa renda estão sendo informadas de que não são elegíveis para subsídios ou não se qualificam para o Medicaid, mesmo que devessem". A questão aqui é a seguinte: Por que esse problema está listado na Etapa 5 em vez da Etapa 4? Esse é um problema associado à etapa anterior que não está sendo calculada adequadamente e, portanto, não está sendo corretamente fatorada na Etapa 5. - Tradução de seguros
Em nosso mundo, chamamos essa parte de ETL. É um problema tão resolvido quanto o registro no site.
- Inscrição de Seguros
O Santo Graal! Mas espere, há uma última "falha", de acordo com os prestadores de serviços da HealthCare.gov: "Os relatórios, conhecidos como 834s, às vezes são confusos e duplicados, dificultando às empresas de seguros saber quem realmente são seus novos clientes".
Vamos ter um momento de silêncio para apreciar este …
Portanto, sim, na realidade, uma companhia de seguros deve saber quem é realmente o seguro. Esse é um componente bastante crítico. O mesmo vale para um trabalhador de emergência que sabe qual pessoa tratar ou um médico que sabe em cujo peito um coração deve ser transplantado. No setor de mídia, podemos caracterizar essa cantiga como um caso de nossos contratados federais enterrando com sucesso o lede. - Cobertura
Por último, mas não menos importante, o gráfico declara que "os funcionários da administração dizem que os compradores apresentaram mais de 700.000 pedidos de seguro de saúde. Alguns deles passaram pelo HealthCare.gov e outros pelos mercados do estado. Mas os funcionários se recusam a dizer quantas pessoas se inscreveram em um plano."
Controle manual
Talvez a curva mais acentuada lançada recentemente tenha sido a mudança para promover aplicativos de papel devido aos desafios de funcionalidade do site. Infelizmente, mesmo os formulários em papel devem ser enviados para o site que não está funcionando. Por definição, isso não é uma substituição manual. Por definição, uma substituição manual deve permitir que alguém ou algo substitua manualmente o sistema automatizado.
E agora, no momento da publicação deste artigo, ouvimos dizer que, para o relançamento do HealthCare.gov, o governo estava confiando mais nas companhias de seguros para resolver os problemas. Adivinhe o que isso significa - aposto que você faz rosquinhas em dólares (sim, costumava ser o contrário), que o que está acontecendo agora é um caso de troca e troca generalizada. Especificamente, programadores e engenheiros provavelmente arrancaram muitas das "conexões em tempo real" e outros middlewares intensamente caros que deixaram os editores do Washington Post tão empolgados. Substituindo todo esse código complexo, há conexões muito mais simples e de alta latência, alimentadas por uma variedade de data marts vinculados por meio de um ambiente em lote a vários sistemas estaduais e federais.
Em outras palavras, o tipo de solução sugerida por Malafsky, Bloor e McAfee é para onde estamos indo. E todo esse código espaguete sofisticado que esses empreiteiros federais gastaram meio bilhão de dólares construindo nos últimos três anos e meio? No recipiente para objectos cortantes.
Enterrado chumbo
E uma nota final: de acordo com testemunho no Congresso de Henry Chao, vice-diretor de informações do Center for Medicare e Medicaid Services, o sistema de pagamento que reembolsará as seguradoras com todos esses subsídios federais? Ainda não foi construído! Isso significa que esse pode ser apenas o primeiro site de comércio eletrônico em larga escala já lançado sem um meio de transferir dinheiro.
