Cuprins:
În primul rând, nu face rău! Acest edict - parafrazat din Jurământul Hipocratic - pătrunde în asistența medicală profesională, așa cum a fost încă din zorii Medicinii Occidentale în urmă cu aproximativ 2.500 de ani. Oricine poate aprecia simplitatea și semnificația acestei mantre. Dacă nu faci altceva ca medic de sănătate, cel puțin nu-ți face rău pacientului.
Scris în subcurentul acelei fraze, puteți găsi o umilință incontestabilă. De fapt, pentru toate diferitele căi ale științei, există o axiomă critică: fiți întotdeauna dispuși să puneți la îndoială presupunerile dvs. Știm doar ce știm și, cu siguranță, nu știm încă totul și nici nu vom face vreodată. Lăsați ca această înțelepciune să servească drept prudență la cele mai puternice prescripții ale voastre.
Apoi e partea de a face. În orice încercare de viață, cineva speră să știe ceva de import, apoi să ia măsuri adecvate. Atentie este la fel de atentă, iar atunci când aveți grijă de viața altora, seriozitatea este necesară. Având această perspectivă ca pânza noastră și o înțelegere a tehnologiei informației (IT) sub centurile noastre, să aruncăm o privire la dezvăluirea HealthCare.gov, cel mai adesea caracterizat steag al Legii de îngrijire la prețuri accesibile, numit „Obamacare”.
Suport de viață
Cât de neclintit pot fi? HealthCare.gov era mort la sosire. Transparența colectivă spune acum că toate cele șase persoane s-au înscris în prima zi, 1 octombrie. Şase. Doar 32.994 din obiectivul zilnic de 33.000. Și în timp ce problemele de „capacitate” erau oferite ca fiind cereri de mână înapoi, orice persoană cu cunoștințe de dinamică web știa mai bine.
„Aceasta nu este o problemă nesoluționată”, remarcă dr. Robin Bloor, un om de știință de date și co-fondator al grupului The Bloor. „Holland are un astfel de schimb”.
De fapt, olandezii sunt în fața jocului de două decenii acum, cu multe lecții învățate. Elvețienii au, de asemenea, o anumită experiență și, desigur, Massachusetts are MAHealthConnector.org, așa-numitul „RomneyCare”.
Bloor a continuat să spună că 40 de ani de experiență IT a dovedit că proiectele mari au întotdeauna un mare risc.
"Fă un proiect mare, cu risc ridicat de eșec. A avea trei ani și jumătate sună ca, într-o zi modernă, ar fi suficient, dar iată un proiect cu risc ridicat și totul s-a dovedit prost, "A spus Bloor.
El a fost cel mai sincer cu privire la modul în care testele de integrare au fost efectuate pentru HealthCare.gov.
"Ultimul lucru care m-a făcut, aproape că m-a izbucnit să râd, este testarea integrării până la două săptămâni înainte de a pleca în direct - și așa este, cum ai putea face asta vreodată cu ceva de genul acesta? Cum ai putut?" Spuse Bloor.
Împărtășind această perspectivă este un antreprenor federal veteran și un om de știință al datelor, Dr. Geoffrey Malafsky de la Phasic Systems Inc. Malafsky a oferit recent o evaluare detaliată de o oră a proiectului HeathCare.gov și a comentat atât deciziile strategice cât și cele tactice luate. . Mai presus de toate, indică degetul către protocolul de achiziție al guvernului federal.
"Unul dintre punctele critice de eșec care pătrunde în special în proiectele IT guvernamentale este această noțiune moștenită, arhaică, învechită, că poți articula toată logica de afaceri necesară cu un proces de cerințe liniare. Acest lucru nu funcționează fundamental cu sisteme IT mari", a spus el.
Ideea lui este că sistemele informatice mari vor da piept celor mai inteligenți planificatori. Nu știți niciodată de unde vor veni problemele, unde va trebui să oferiți un sprijin suplimentar sau ce fel de depanare vă veți angaja în consecință. Prin urmare, este o idee proastă să constrângeți procesul de proiectare, obligând inginerii de proiect să anticipeze totul vor avea nevoie în avans.
Complicarea problemelor, spune Malafsky, este faptul că oficialii de achiziții din guvernul federal au devenit acum atât de puternici - din cauza sumelor mari de bani pe care le controlează - încât, în esență, controlează modul în care proiectele IT majore merg înainte. Acest lucru pune oficialii departamentali în rolul de suplicant și introduce un element de risc într-o procedură crucială în centrul oricărei inițiative IT semnificative: alegerea instrumentelor, tehnologiilor și antreprenorilor potriviți.
"Persoanele care nu vor fi de acord cu această declarație sunt numiți profesioniști în domeniul achizițiilor, iar eu îi încurajez să se prezinte la mine acasă și o să stăm și să dezbatem acest lucru, pentru că am o mulțime de dovezi empirice pentru a susține acest lucru", a spus Malafsky spus.
Strategia site-ului
O mare întrebare de pus este de ce guvernul a cuprins o arhitectură atât de cuprinzătoare pentru acest site web.
"Dacă programul guvernamental general este instituit astfel încât companiile de asigurări să dețină de fapt clientul după ce își asumă un angajament, atunci de ce nu împingeți traficul către canalul de mediu de interacțiune existent cu clientul pe care îl au deja companiile de asigurări? Da, acestea ar putea trebuie să-și mărească propriile, dar acesta ar fi un motiv de afaceri valabil, deoarece acum vor primi noi clienți ", a spus Malafsky.
Pionierul software-ului de securitate de renume mondial (și acum oarecum infam), a comentat și el recent această strategie, făcând câteva observații controversate cu privire la „Neil Cavuto Show” de la Fox News:
"Oh, este grav rău", a spus McAfee. "Cineva a comis o eroare gravă, nu în conceperea programului, ci doar în implementarea aspectului Web al acestuia. Adică, de exemplu, oricine poate crea o pagină Web și poate pretinde că este un broker pentru acest sistem … orice hacker poate pune un creează-ți un site web, fă-l să pară extrem de competitiv și, din cauza naturii sistemului - și asta este îngrijirea sănătății, până la urmă - îți pot pune cele mai intime întrebări și le vei răspunde liber. "
În ceea ce privește arhitectura Web în sine, Malafsky subliniază faptul că Internetul nu a fost creat pentru a rula aplicații complexe. Aceasta a fost treaba mainframe-ului încă din zilele când Web-ul era încă la început. Mai degrabă, punctul de proiectare pentru Internet a fost acela de partajare simplă a informațiilor prin pagini individuale distribuite pe o rețea largă de computere. În proiectarea sistemelor, scopul este de a construi ceva care să funcționeze. Încorporarea complexității de dragul său este sfătuită, pur sacrilegiu și aproape întotdeauna o rețetă pentru dezastru.
The Washington Post a publicat un grafic de față care ilustrează diferitele provocări pe care le-a avut site-ul. Limba folosită de hârtie pentru a descrie site-ul este de fapt revelatoare, mai ales atunci când considerați că acesta este ziarul consacrat din Washington, DC, epicentrul guvernului federal al SUA:
HealthCare.gov, construit de 55 de contractori, este una dintre cele mai complexe piese de software create vreodată pentru guvernul federal. Comunică în timp real cu cel puțin 112 sisteme informatice diferite din toată țara. În primele 10 zile, a primit 14, 6 milioane de vizite unice, potrivit administrației Obama.
Sursa: The Washington Post
În mod obișnuit, prin definiție, pentru ca cineva să afirme că are o piesă software, trebuie să fie cazul în care software-ul funcționează efectiv. În caz contrar, aveți o compilare de cod care nu constituie încă o componentă software. De asemenea, notează numerele enumerate, în special partea despre comunicarea „în timp real” cu 112 sisteme computerizate diferite din țară. Acesta este un exemplu perfect de glorificare a complexității de dragul său.
„Știm că o altă posibilitate este să fi creat un sistem de brokering Web simplu, foarte simplu, că tot ceea ce face este printr-un cod de server de aplicații foarte simplu și chiar mai simplu din partea clientului, Javascript, creează o interfață foarte plăcută care produce date rulate pentru oameni ", A spus Malafsky. "Iată ce puteți face: parcurgeți acest lucru; treceți prin asta. Apoi, orice acțiune care poate apărea poate fi făcută la punctul de selecție și poate fi trimisă cuiva care va deține efectiv programul." Desigur, acel „cineva” se referă la companiile de asigurări care oricum vor deține polițele.
Graficul grafic
Proiectanții de sisteme din întreaga lume trebuie să fi plâns când au văzut această grafică. Să aruncăm o privire la diferiții pași evidențiați și, în special, la problemele grave care apar cu o arhitectură atât de ambițioasă. În primul rând și în primul rând, vom lua în considerare numărul de tranzacții potențiale care au eșuat până acum, cele mai multe dintre acestea datorită scadențelor software - cazuri în care o parte a procesului de tranzacție nu primește datele necesare într-o perioadă de timp acceptabilă.
"Fiecare componentă software din graficul respectiv a avut propriile perioade de timp și nu este nici măcar un singur interval de timp. Poate fi mai mult", a spus Malafsy. "Expirarea oricăreia dintre acestea va ucide întreaga tranzacție. Unele dintre acestea sunt ușor de configurat și monitorizat, cum ar fi fișierele de jurnal. Acestea sunt ca perioade de timp pe serverul web și pe serverul de aplicații. Unele sunt mai opace. bazele de date cu concurență și declanșatori, dar sunt multi-interacțiune. Dacă într-adevăr faceți o adâncime profundă în modul de funcționare a bazelor de date, nu este o vedere destul de bună. " (Aflați elementele de bază ale funcționării bazelor de date în tutorialul nostru de baze de date.)
„Serverele de baze de date adoră să spună:„ Păstrăm totul ordonat ”. Nu chiar ", a spus Malafsky. Singura modalitate prin care pot obține performanța și o pot gestiona cu adevărat este că există o serie de fișiere timbrate timp care sunt create pe stocare, stocare persistentă și nu sunt rulate într-unul singur un set complet complet de date care este disponibil oricui, deoarece acest lucru durează prea mult, ceea ce ar ucide latența tranzacțională. Trebuie să analizați detaliile, apoi acestea sunt introduse printr-o interfață de gestionare - și asta trece prin niște sofisticate foarte frumoase. nume precum declanșatoarele și concurența - dar, practic, înseamnă că este nevoie de mult timp pentru a obține datele, a actualiza datele și, dacă nu pot face asta înainte de a veni o altă solicitare, o să vă spun, ' Uită-l. Sunt închis pentru afaceri. ""
- "Ușa din față"
Graficul Washington Post include o informație foarte curioasă chiar la tippy-top în prima sa secțiune „problemă”, unde spune că „administrația Obama a decis la sfârșitul lunii septembrie să excludă deocamdată o funcție care ar fi permis oamenilor să facă cumpărături pentru planuri de sănătate fără a crea mai întâi un cont online ".
Wow. În primul rând, este cu adevărat o „caracteristică” care a fost exclusă? Vorbim despre fluxul fundamental al site-ului. Inițial, planul era de a permite oamenilor să facă cumpărături, apoi la momentul potrivit, să ia în considerare înregistrarea unui cont.
Unii critici au speculat că această schimbare de ultimă oră (și în sine, o mutare incredibil de riscantă cu un proiect atât de mare), arată că administrația știa că site-ul nu funcționa bine în ultimele două săptămâni până la lansarea din 1 octombrie. . În schimb, ideea a devenit să captez toate informațiile celor care aveau nevoie de asigurare, astfel încât eforturile de marketing ar putea fi făcute către ei undeva în josul liniei, odată ce site-ul va fi funcțional.
Dintr-o perspectivă de utilizare și capacitate, această mișcare din ultima clipă a pus un efort extraordinar pe orice bază de bază a bazei de date. Acest lucru explică toate anecdotele persoanelor care nu s-au putut înregistra sau care sunt obligate să își schimbe parolele. Și să fim sinceri aici. Există vreo problemă rezolvată mai amănunțit în toată lumea World Wide Web decât procesul de configurare a unui cont de utilizator? Yahoo, Google, Microsoft, YouTube, Twitter, LinkedIn - chiar și clasa de tricotat a bunicii tale - are propriul formular dinamic de înscriere în aceste zile, cu dezabonare la cuptor, înainte și alte caracteristici fundamentale. - Înregistrare
Când a venit momentul să se înregistreze pe HealthCare.gov, contractanții spun: "Comunicarea dintre unele dintre aceste sisteme nu a funcționat corect, ceea ce înseamnă că mulți utilizatori nu au reușit să își creeze un cont".
Ce? Ce sisteme? Vorbim despre o bază de date pentru clienți! „Sistemele” ar fi apoi clientul Web și baza de date a clienților. Ce alte sisteme au fost implicate? Această „explicație” particulară nu are sens. - Dovadă de identitate
În continuare, dovada identității. Pentru acest pas, nu sunt enumerate probleme, ceea ce este, de asemenea, curios. Experian este listat ca agentul terț care va „verifica” identitatea cuiva. Fără îndoială, rezolvarea identității este o problemă serioasă care trebuie abordată. Majoritatea companiilor de asigurare folosesc numărul dvs. de securitate socială, precum și furnizorii terți precum Experian. Chiar nu există probleme cu acest pas?
Știm cu siguranță din numeroase anecdote, verificate prin documentația prezentată, că HealthCare.gov a experimentat cu siguranță încălcări de informații confidențiale. Malafsky subliniază că problemele legate de calitatea datelor sunt mult mai grave decât cele legate de capacitate. (Și Bloor observă că, dacă problemele de capacitate au fost cu adevărat problemele, acestea ar fi trebuit rezolvate în zile, nu în săptămâni. Puteți adăuga hardware, virtualiza, face orice număr de lucruri pentru probleme de capacitate.)
Nu, problemele legate de calitatea datelor sunt cele cu adevărat periculoase. Iar aspectul cel mai tulburător este tipul problemelor legate de calitatea datelor. Există povești despre persoane care se înscriu, apoi primesc documente confidențiale de eligibilitate aparținând altor candidați! Acest lucru are un design absolut îngrozitor sub copertine. Nu folosesc un fel de cod universal de identificare pentru fiecare persoană?
"Mișcarea inteligentă ar fi crearea unui identificator universal unic (UUID), stocarea valorilor criptate - nota plural - a ceea ce ar putea fi informații unice (SSN, DOB, vârstă, biometrie), și apoi să le evalueze pentru dovezi de personalitate unică", Spuse Malafsky.
Că cineva ar putea primi documentele confidențiale ale unei alte persoane este indiscutabil de rău și demonstrează unele probleme foarte grave de cartografiere adânc în burta fiarei. - Eligibilitate
OK, oameni buni. Iată unde viața devine interesantă! Dacă tranzacția dvs. nu a expirat până acum, aproape sigur a făcut acest pas. Conform graficului The Washington Post, „Sistemul trebuie să determine eligibilitatea pentru ajutor financiar, trimițând informațiile personale ale consumatorului la un Hub de date care contractează zeci de agenții federale și de stat.”
Încercarea de a executa o tranzacție pe trei sau patru sisteme cheie este o adevărată provocare. Încercarea de a lovi „zeci” de agenții de stat și federale „în timp real” este în afara listelor și este absolut inutilă. Malafsky a luat doar un punct de interacțiune pentru a-și face cazul:
"Unul dintre cele evidente este obținerea de date financiare de persoană pentru a determina dacă merită o subvenție sau care ar fi punctul lor de preț, așa că mergem la IRS. Acum, avem o legătură acolo, dar această legătură este live. Asta înseamnă că utilizatorul stă acolo așteptând la ecranul computerului, asta trebuie să facă o legătură către sistemele IRS. Într-o lume perfectă, se întâmplă acea legătură, computerele vorbesc, îmi obțin rezultatul și revin.
"Ce se întâmplă în lumea reală? Ce se întâmplă când sistemele IRS sunt supraîncărcate? Ce se întâmplă când sunt la capacitate? Ce se întâmplă când poate face întreținere? Ce este despre o rețea între centrul de operare al rețelei de nivel de intrare? Pagina web pe care clientul o vede către centrul IRS? Poate există probleme acolo. Poate că există un virus. Poate există un cal troian care circulă și telecomunicările au închis lucrurile pentru a rezolva acea problemă. Aceasta va ucide tranzacția din punctul de vedere al vedere a utilizatorului. Acesta este doar unul dintre numeroasele astfel de puncte din această arhitectură ", a spus Malafsky.
Ideea lui este că fiecare dintre aceste sisteme - întrucât această arhitectură Web a fost proiectată pentru HealthCare.gov - fiecare dintre ele este un potențial călcâi Achile. Aceasta este o situație fără câștig. Și din nou, este inutil din perspectiva fluxului de lucru. Există un număr de puncte de-a lungul drumului în care fluxul de lucru ar putea fi mărit cu marts de date în timp real, marts de date la timp, chiar și intervenția umană pentru a aborda principalele puncte de avarie ale automatizării.
Prin urmare, marea eroare strategică a fost încercarea de a realiza un site atât de complex. - Cumpărături pentru un plan
Amintiți-vă: acesta trebuia să fie fluxul original al site-ului. Surferii web ar cumpăra mai întâi un plan de asigurare. Apoi, când au găsit ceva de interes, puteau să se înregistreze pentru un cont, să verifice dacă au dorit și, în final, să cumpere un plan.
Potrivit graficului, „unor persoane cu venituri mici li se spune că nu sunt eligibile pentru subvenții sau nu se califică pentru Medicaid, chiar dacă ar trebui.” Întrebarea de aici devine: De ce această problemă este listată la Pasul 5 în loc de Pasul 4? Aceasta este o problemă asociată cu etapa anterioară, care nu a fost calculată în mod corespunzător și, prin urmare, nu a fost corect luată în considerare în Etapa 5. - Traducere de asigurări
În lumea noastră, numim această parte ETL. Este la fel de rezolvată o problemă ca și înregistrarea site-ului.
- Înscriere în asigurări
Sfântul Potir! Dar așteptați, există un ultim „glitch”, potrivit contractanților HealthCare.gov: „Rapoartele, cunoscute sub numele de 834, sunt uneori confuze și duplicatorii, ceea ce îngreunează companiile de asigurări să știe cine sunt cu adevărat noii lor clienți”.
Să luăm un moment de tăcere pentru a-l aprecia …
Deci, da, de fapt, o companie de asigurări trebuie să știe cine este cu adevărat asigurator. Aceasta este o componentă destul de critică. Același lucru este valabil și pentru un lucrător de urgență care știe ce persoană trebuie să trateze sau un medic care cunoaște în pieptul căruia trebuie să i se transplanteze o inimă. În domeniul mass-media, am putea caracteriza această micuță nebunie ca un caz al antreprenorilor noștri federali care îngroapă cu succes. - Acoperire
Nu în ultimul rând, graficul precizează că "oficialii administrației spun că cumpărătorii au depus peste 700.000 de cereri de asigurări de sănătate. Unele dintre acestea au ajuns prin HealthCare.gov, iar altele prin intermediul piețelor de stat. Dar oficialii refuză să spună câte persoane s-au înscris într-un plan."
Înlocuire manuală
Poate că cea mai puternică curbă aruncată în mix a fost recent demersul de a promova aplicațiile de hârtie datorită provocărilor funcționalității site-ului. Din păcate, chiar și formularele de hârtie trebuie trimise pe site-ul care nu funcționează. Prin definiție, aceasta nu este o înlocuire manuală. Prin definiție, o înlocuire manuală trebuie să permită cuiva sau ceva să înlocuiască manual sistemul automat.
Și acum, la momentul publicării acestui articol, auzim că pentru relansarea HealthCare.gov, administrația se bazează mai mult pe companiile de asigurări pentru a rezolva problemele. Ghiciți ce înseamnă asta - am să pariez că vă fac gogoașe în dolari (da, era până la invers), că ceea ce se întâmplă în acest moment este un caz de extindere și înlocuire. Mai exact, programatorii și inginerii au eliminat probabil multe dintre „conexiunile în timp real” și alte mijloace de calcul intens costisitoare care i-au atras pe editorii de la Washington Post. Înlocuirea tuturor codurilor complexe sunt conexiuni mult mai simple, cu latență mai mare, care sunt alimentate de o serie de marts-uri de date legate prin mai multe medii de lot la diferitele sisteme de stat și federale.
Cu alte cuvinte, genul de soluții pe care le sugerează Malafsky, Bloor și McAfee este acela în care mergem. Și tot acel cod de spaghetă fantezist pe care acești antreprenori federali au cheltuit jumătate de miliard de dolari construind în ultimii trei ani și jumătate? În recipientul pentru ascuțiți.
Plumb îngropat
Și o notă finală: Conform mărturiei dinaintea Congresului de către Henry Chao, ofițerul de șef adjunct al Centrelor pentru Medicare și Medicaid, sistemul de plată care va rambursa companiile de asigurări cu toate subvențiile federale? Încă nu a fost construit! Aceasta înseamnă că acesta ar putea fi doar primul site de comerț electronic pe scară largă lansat vreodată fără un mijloc de lucru pentru transferul de bani.
