Taula de continguts:
Primer, no faci mal! Aquell edicte, parafrasejat des del jurament d’Hipocràtics, persisteix en l’assistència sanitària professional, tal com va passar des de l’alba de la medicina occidental fa uns 2.500 anys. Qualsevol persona pot apreciar la senzillesa i el significat d’aquest mantra. Si no fas res més com a professional sanitari, almenys no facis mal al teu pacient.
Escrit al subcurrent d'aquesta frase, es pot trobar una humilitat innegable. De fet, per a totes les diverses i diverses vies de la ciència, hi ha un axioma crític: estar sempre disposat a qüestionar els vostres supòsits. Només sabem el que sabem i segurament no ho sabem tot, ni ho farem mai. Que la saviesa serveixi de precaució a les vostres receptes més fortes.
Després hi ha la part de fer. En qualsevol esforç vital, s’espera saber alguna cosa d’importació, i després prendre les mesures adequades. Tenir cura és tan atent com, i per tenir cura de la vida dels altres, cal serietat. Amb aquesta perspectiva com el nostre llenç i una comprensió de la tecnologia de la informació (IT) sota els nostres cinturons, fem un cop d’ull al llançament de HealthCare.gov, l’oferta caracteritzada sovint de la Llei de cura assequible, també coneguda com "Obamacare".
Suport de vida
Com de contundent puc ser? HealthCare.gov va morir a l’arribada. La transparència col·lectiva diu que les sis persones es van inscriure el primer dia, 1 d’octubre. Sis. Només 32.994 tenen menys de 33.000 objectius diaris. I mentre que els problemes de "capacitat" eren plantejats com a demandes recaptades de demanda, qualsevol persona amb coneixement de la dinàmica web ho sabia millor.
"Aquest no és un problema no resolt", assenyala el doctor Robin Bloor, científic de dades i cofundador del grup The Bloor. "Holanda té un intercanvi com aquest."
De fet, els holandesos han estat al capdavant del joc des de fa dues dècades, amb moltes lliçons apreses. Els suïssos també tenen alguna experiència i, per descomptat, Massachusetts té MAHealthConnector.org, l'anomenat "RomneyCare".
Bloor va continuar dient que 40 anys d'experiència en TI han demostrat que els grans projectes sempre tenen un gran risc.
"Feu un projecte gran, amb risc elevat de fracàs. Tenir tres anys i mig sembla que, en un dia modern, això seria suficient, però aquí teniu un projecte d'alt risc i tot ha resultat malament, "Va dir Bloor.
Va ser el més sincer sobre la manera de realitzar les proves d’integració per a HealthCare.gov.
"L'últim que em va fer, gairebé em va fer riure, no és fer proves d'integració fins a dues setmanes abans de sortir a viure; i així és com, com ho podries fer mai amb una cosa així? Com podríeu?" Va dir Bloor.
Geoffrey Malafsky, de Phasic Systems Inc., Malafsky, va oferir recentment una avaluació detallada durant una hora i detallada de HeathCare.gov, i va comentar sobre les decisions estratègiques i tàctiques que es van prendre. . Per sobre de tot, assenyala el dit cap al protocol d'adquisició del govern federal.
"Un dels punts crítics de fracàs que impregna especialment els projectes informàtics del govern és aquesta noció antiga, arcaica i obsoleta, que podeu articular tota la lògica empresarial necessària amb un procés de requeriments lineals. Això fonamentalment no funciona amb grans sistemes informàtics", va dir.
El seu punt és que els grans sistemes informàtics malmetran els planificadors més intel·ligents. No sabeu mai d'on sortiran els problemes, on haureu de proporcionar suport addicional o quin tipus de resolució de problemes us trobareu involucrats. Per tant, és una mala idea limitar el procés de disseny obligant els enginyers de projecte a preveure-ho tot. necessitaran per endavant.
Malafsky, afirma, és complicat el fet que els funcionaris de contractació del govern federal ara s'han convertit en tan poderosos, a causa de les grans quantitats de diners que controlen, que controlen fonamentalment el desenvolupament de grans projectes de TI. Això fa que els funcionaris departamentals tinguin la funció de suplicant i insereix un element de risc en un procediment crucial al centre de qualsevol iniciativa informàtica significativa: triar les eines, tecnologies i contractistes adequades.
"La gent que no estarà més d'acord amb aquesta afirmació s'anomenen professionals de l'adquisició i els animo a presentar-se a casa meva i ens asseurem i debatrem, perquè tinc moltes proves empíriques per donar-hi suport", va dir Malafsky. dit.
Estratègia del lloc
Una de les grans preguntes és per què el govern va abraçar una arquitectura tan completa per a aquest lloc web.
"Si el programa de govern general es configura de manera que les companyies d'assegurances siguin propietàries del client després que es comprometin, aleshores, per què no només cal empènyer el trànsit al canal d'entorn d'interacció amb el client existent? Necessiten augmentar els seus, però això seria una raó comercial vàlida perquè ara obtindran nous clients ", va dir Malafsky.
El pioner del programari de seguretat de renom mundial (i ara una mica infamant), John McAfee, també va comentar aquesta estratègia recentment, fent algunes observacions controvertides al "Neil Cavuto Show" de Fox News:
"Oh, està molt malament", va dir McAfee. "Algú va cometre un greu error, no en dissenyar el programa, sinó simplement en implementar-ne l'aspecte web. Vull dir, per exemple, que tothom pugui crear una pàgina web i afirmar ser un agent per a aquest sistema … qualsevol hacker pot posar un lloc web, fan que sembli extremadament competitiu i, a causa de la naturalesa del sistema, i aquesta és l’atenció sanitària, al cap i a la fi, poden fer-te les preguntes més íntimes i, lliurement, els respondràs ".
Pel que fa a la pròpia arquitectura web, Malafsky assenyala l'objectiu: que Internet no estava construït per executar aplicacions complexes. Aquesta era la feina del mainframe en aquells temps en què la web era a la seva infància. Més aviat, el punt de disseny d'Internet era el simple intercanvi d'informació a través de pàgines individuals distribuïdes en una àmplia xarxa d'ordinadors. En el disseny de sistemes, l'objectiu és construir alguna cosa que funcioni. La incorporació de la complexitat pel seu propi compte és desaconsellada, sacrílega i gairebé sempre una recepta per al desastre.
El Washington Post va publicar un famós gràfic que mostra els diversos reptes que experimenta el lloc. El llenguatge que utilitza el document per descriure el lloc és realment revelador, sobretot quan es considera que es tracta del diari establert de Washington, DC, l'epicentre del govern federal dels Estats Units:
HealthCare.gov, construït per 55 contractistes, és una de les peces més complexes de programari mai creades per al govern federal. Es comunica en temps real amb almenys 112 sistemes informàtics diferents a tot el país. Segons l’administració Obama, va rebre 14, 6 milions de visites úniques en els primers deu dies.
Font: The Washington Post
Sens dubte, per definició, perquè algú afirmi que té un programari, deu ser el cas que el programari funcioni realment. En cas contrari, teniu una recopilació de codi que encara no constitueix un programari. A banda de fer aquesta nota, tingueu en compte els números que s'enumeren, especialment la part sobre la comunicació "en temps real" amb 112 sistemes informàtics diferents a tot el país. Aquest és un exemple perfecte de glorificar la complexitat per compte propi.
"Sabem que una altra possibilitat és haver creat un sistema de intermediació web senzill, molt senzill, que tot el que fa és que hi hagi un codi de servidor d'aplicacions molt senzill i un Javascript encara més senzill, crea una interfície molt agradable que produeix dades enrotllades per a persones. ", Va dir Malafsky. "Aquí podeu fer: passeu per això; passeu per això. A continuació, qualsevol acció que es produeixi es pot fer en un punt de selecció i ser enviada a algú que realment posseeixi el programa." Per descomptat, aquell "algú" fa referència a les companyies d'assegurances que, de totes maneres, posseiran les pòlisses.
El gràfic gràfic
Els dissenyadors de sistemes de tot el món han d’haver-se esvaït en veure aquest gràfic. Mirem els diferents passos exposats i, en particular, els problemes greus que sorgeixen amb una arquitectura tan ambiciosa. En primer lloc, considerarem el nombre de possibles transaccions que han fracassat fins ara, la majoria a causa del temps d'espera de programari, casos en què una part del procés de transacció no rep les dades necessàries en un període de temps acceptable.
"Cada programari en aquest gràfic tenia un temps d'espera i no és ni un temps d'espera. Pot ser més", va dir Malafsy. "La caducitat de qualsevol d'aquestes matarà tota la transacció. Algunes d'aquestes són fàcils de configurar i controlar, com els fitxers de registre. Són com els temps de espera al servidor web i al servidor d'aplicacions. Alguns són més opacs. bases de dades amb concurrència i desencadenants, però són multi-interacció. Si realment feu una immersió profunda en el funcionament de les bases de dades, no és una bona vista. " (Obteniu informació bàsica sobre com funcionen les bases de dades al nostre tutorial de bases de dades.)
"Els servidors de bases de dades els agrada dir:" Ho mantenim tot ordenat. " No és realment ", va dir Malafsky. L'única manera com poden obtenir el rendiment i gestionar-lo veritablement és que hi ha una sèrie de fitxers segellats amb temps que es creen a l'emmagatzematge, emmagatzematge persistent i no s'enrotllen en un. un conjunt complet i complet de dades que està disponible per a qualsevol persona en qualsevol moment, ja que triga massa, cosa que mataria la latència transaccional. Heu de mirar aquests detalls i, després, es transmeten a través d'una interfície de gestió. noms com els desencadenants i la concurrència, però bàsicament significa que es triga un temps per obtenir les dades, actualitzar les dades, i si no puc fer-ho abans que arribi una altra sol·licitud, només us ho diré ", Ho oblideu. Estic tancat per negocis. ""
- "La porta frontal"
El gràfic del Washington Post inclou una informació molt curiosa a la primera secció "problema", on es diu que "l'administració Obama va decidir a finals de setembre excloure per ara una funció que hauria deixat la gent comprar. plans de salut sense abans crear un compte en línia. "
Wow En primer lloc, és realment una "funció" que va ser exclosa? Estem parlant de flux fonamental de llocs. Originalment, el pla era deixar que la gent comprés, i en el moment oportú, plantejar-se el registre d’un compte.
Alguns crítics han especulat que aquest canvi d’última hora (i per si mateix, un moviment increïblement arriscat amb un projecte tan important), demostra que l’administració sabia que el lloc no funcionava bé les darreres setmanes fins al llançament de l’1 d’octubre. . En lloc d'això, es va convertir la idea de captar tota la informació dels que necessitaven assegurança, de manera que es podrien fer esforços de màrqueting en algun lloc de la línia un cop el lloc fos funcional.
Des d’una perspectiva d’usabilitat i capacitat, aquest moviment d’última hora va posar un gran esforç sobre qualsevol base de bases de dades que tenia el lloc. Això explica totes les anècdotes de les persones que no es podien registrar o que es veuen obligades a canviar les seves contrasenyes. I siguem sincers aquí. Hi ha algun problema més resolt a tot el World Wide Web que el procés de creació d’un compte d’usuari? Yahoo, Google, Microsoft, YouTube, Twitter, LinkedIn, fins i tot la classe de teixit de la teva àvia, té avui dia el seu propi formulari d’inscripció dinàmica, amb desinscripció al forn al forn, altres funcions fonamentals. - Inscripció
Quan va arribar el moment de registrar-se a HealthCare.gov, els contractistes diuen: "La comunicació entre alguns d'aquests sistemes no funcionava correctament, cosa que significa que molts usuaris no van poder crear un compte amb èxit".
Què? Quins sistemes? Estem parlant d’una base de dades de clients! Els "sistemes" serien llavors el client web i la base de dades de clients. Quins altres sistemes van participar? Aquesta "explicació" particular no té sentit. - Prova d’identitat
A continuació, prova d’identitat. Per a aquest pas, no es mostren problemes, cosa que també és curiosa. Experian es classifica com el agent de tercers que "verificarà" la identitat d'algú. Sens dubte, la resolució d’identitat és un problema greu que s’ha d’abordar. La majoria de les companyies d’assegurances utilitzen el vostre número de Seguretat Social, així com venedors de tercers com Experian. Realment no hi ha cap problema amb aquest pas?
Sabem amb seguretat de nombroses anècdotes, verificades per la documentació presentada, que HealthCare.gov ha experimentat definitivament violacions d’informació confidencial. Malafsky assenyala que els problemes de qualitat de les dades són molt més greus que els problemes de capacitat. (I Bloor remarca que si els problemes de capacitat eren realment els problemes, haurien d'haver estat resolts en dies, no en setmanes. Podeu afegir maquinari, virtualitzar, fer qualsevol cosa per problemes de capacitat.)
No, els problemes de qualitat de les dades són realment perillosos. I l’aspecte més preocupant de tots és el tipus de problemes de qualitat de les dades que han sorgit. Hi ha històries de persones que s’inscriuen i, a continuació, reben documents d’elegibilitat confidencials que pertanyen a altres inscriptors! Això té un disseny absolutament terrible a les portades. No fan servir algun tipus de codi d’identificació universal per a cada persona?
"El moviment intel·ligent seria crear un identificador universal (UUID), emmagatzemar valors xifrats (nota plural) del que podria ser informació única (SSN, DOB, edat, biometria), i després avaluar-los com a evidències de personalitat única", Va dir Malafsky.
Que algú pogués rebre els documents confidencials d’una altra persona és indiscutiblement dolent, i demostra alguns problemes molt seriosos de mapeig al ventre de la bèstia. - Elegibilitat
D'acord, persones. Aquí és on la vida es fa interessant! Si la vostra transacció no s’havia tancat fins ara, gairebé segur que es va fer en aquest pas. Segons el gràfic de The Washington Post, "El sistema ha de determinar l’elegibilitat per a l’ajuda financera enviant informació personal del consumidor a un Data Hub que contracti desenes d’agències federals i estatals".
Intentar executar una transacció en tres o quatre sistemes clau és un autèntic repte. Tractar de colpejar "desenes" d'agències estatals i federals "en temps real" queda fora dels gràfics i no és necessària. Malafsky va prendre només un punt d'interacció per presentar el seu cas:
"Un dels més obvis aquí és obtenir dades financeres per persona per determinar si mereixen una subvenció o quin seria el seu punt de preu, de manera que anem a l'IRS. Ara, tenim algun enllaç per aquí, però aquest enllaç és directe. . Això vol dir que l’usuari s’asseu allà esperant a la pantalla de l’ordinador, que ha de fer un enllaç als sistemes IRS. En un món perfecte, aquest enllaç passa, els ordinadors parlen, obtinc el meu resultat i torno.
"Què passa amb el món real? Què passa quan es sobrecarreguen els sistemes IRS? Què passa amb quan tenen capacitat? Què passa amb potser si fan manteniment? Què passa amb una xarxa entre el centre operatiu de la xarxa del nivell d'entrada. Pàgina web que el client veu al centre de l’IRS? Potser hi ha problemes, potser hi ha un virus, potser hi ha un cavall de Troia corrent i les telecomunicacions han tancat les coses per solucionar aquest problema, que matarà la transacció des del punt de vista de l'usuari. Aquest és només un dels molts punts d'aquesta arquitectura ", va dir Malafsky.
El seu punt és que tots aquests sistemes (com aquesta arxiu web va ser dissenyat per a HealthCare.gov), cadascun d'ells és un taló potencial d'Aquil·les. Aquesta és una situació sense guanys. I de nou, és innecessari des d'una perspectiva de flux de treball. Hi ha diversos punts al llarg del camí en què es podria augmentar el flux de treball amb marts de dades a temps real, marts de dades a temps adequat, fins i tot intervenció humana per abordar els principals punts de fallada de l’automatització.
El gran error estratègic, per tant, era intentar aconseguir un lloc tan increïblement complex. - Compres per un pla
Recordeu-ho: suposadament va ser el flux original del lloc. Els internautes primer comprarien un pla d’assegurança. Aleshores, quan trobessin alguna cosa d’interès, van poder registrar-se en un compte, buscar si hi havia subvencions si ho volien i, finalment, comprar un pla.
Segons el gràfic, "a algunes persones amb ingressos baixos se'ls diu que no són elegibles per a subvencions o que no tenen la qualificació de Medicaid, tot i que ho han fet". La pregunta aquí passa: Per què apareix aquest problema al pas 5 en lloc del pas 4? Aquest és un problema associat al fet que no es calcula adequadament al pas anterior i, per tant, no es contempla correctament al pas 5. - Traducció d’assegurances
Al nostre món, en diem aquesta part ETL. El problema és com el registre del lloc.
- Matrícula d’assegurances
El Sant Grial! Però espera, hi ha un últim "glitch", segons els contractistes de HealthCare.gov: "Els informes, coneguts com a 834, de vegades són confusos i duplicatius, cosa que dificulta que les companyies d'assegurances sàpiguen qui són realment els seus nous clients".
Fem un moment de silenci per apreciar-lo …
Així, sí, de fet, una companyia d’assegurances ha de saber qui és realment assegurador. És un component força crític. El mateix passa amb un treballador d’emergències que sap quina persona ha de tractar, o un metge que sap al pit una capa de trasplantar-li un cor. En el sector dels mitjans de comunicació, podríem caracteritzar aquest ximple com un cas dels nostres contractistes federals amb enterrament amb èxit de la cadera. - Cobertura
Per últim, però no per això menys important, el gràfic afirma que "els funcionaris de l'administració asseguren que els compradors han presentat més de 700.000 sol·licituds d'assegurança mèdica. Algunes d'aquestes han arribat a través de HealthCare.gov i d'altres a través dels mercats estatals. Però els funcionaris es neguen a dir quantes persones s'han inscrit en un planificar ".
Sustitució manual
Potser la bola de curva més nítida llançada a la barreja fa poc va ser la decisió de promoure les aplicacions de paper a causa dels reptes de funcionalitat del lloc. Malauradament, fins i tot els formularis en paper s’han d’enviar al lloc que no funciona. Per definició, no és una substitució manual. Per definició, una substitució manual ha de permetre que algú o alguna cosa anul·li manualment el sistema automatitzat.
I ara, en el moment de publicar-se aquest article, sentim que per al rellançament de HealthCare.gov, l’administració confia més que les companyies d’assegurances per solucionar els problemes. Endevineu què vol dir: aposto que us donaran dòlars a dòlars (sí, abans ho era al revés), que el que passa ara mateix és un cas de remodelació generalitzada. Concretament, programadors i enginyers probablement han destrossat moltes de les "connexions en temps real" i altres programes intermedis intensament costosos que han entusiasmat els editors del Washington Post. Substituir tot aquest codi complex són connexions de senzilla latència molt més senzilla i alimentades per una sèrie de marts de dades enllaçats a través d'un entorn d'un lot als diversos sistemes estatals i federals.
És a dir, el tipus de solució que suggereixen Malafsky, Bloor i McAfee és cap a on anem. I tot aquest fantàstic codi d’espagueti que aquests contractistes federals van gastar mig milió de dòlars en la construcció dels últims tres anys i mig? Al contenidor dels punxons.
Plom enterrat
I una nota final: segons el testimoni abans del Congrés de Henry Chao, el subdirector d'informació dels centres per a Medicare i Medicaid Services, el sistema de pagament que reemborsarà a les companyies d'assegurances totes aquelles subvencions federals? Encara no s'ha creat Això vol dir que potser sigui el primer lloc de comerç electrònic a gran escala mai llançat sense un mitjà de treball per transferir diners.
