Съдържание:
Първо, не вреди! Този едикт - перифразиран от Хипократовата клетва - прониква в професионалното здравеопазване, какъвто е от зората на западната медицина преди около 2500 години. Всеки може да оцени простотата и смисъла на тази мантра. Ако не правите нищо друго като медицински специалист, поне не наранявайте пациента си.
Вписан в подценката на тази фраза, можете да намерите безспорно смирение. Всъщност, за всички различни и разнообразни пътища на науката има критична аксиома: винаги бъдете готови да поставите под съмнение вашите предположения. Ние знаем само това, което знаем, и сме сигурни, че все още не знаем всичко, нито някога ще бъдем. Нека тази мъдрост служи като предпазливост за най-силните ви предписания.
Тогава е частта за правене. Във всяко начинание на живот човек се надява да знае нещо за вноса, след което да предприеме подходящи действия. Вниманието е също толкова внимателно, а когато се грижи за живота на другите, се изисква сериозност. С тази перспектива като нашето платно и разбирането на информационните технологии (ИТ) под нашите колани, нека да разгледаме представянето на HealthCare.gov, често характеризираната водеща позиция на Закона за достъпна грижа, известна още като "Obamacare."
Поддръжка на живота
Колко тъп мога да бъда? HealthCare.gov беше мъртъв при пристигането си. Сега колективната прозрачност гласи, че всички шестима души са се регистрирали в първия си ден, 1 октомври. Шест. Само 32, 994 къса от целта от 33 000 за деня. И докато проблемите с "капацитета" бяха рекламирани като безотказно признание на търсенето, всеки, който познава динамиката на мрежата, знаеше по-добре.
„Това не е нерешен проблем“, отбелязва д-р Робин Блур, учен по данни и съосновател на The Bloor Group. "Холандия има такава размяна."
Всъщност холандците изпреварват играта вече две десетилетия с много поуки. Швейцарците също имат известен опит и разбира се, Масачузетс има MAHealthConnector.org, така наречения „RomneyCare“.
Bloor продължи да казва, че 40 години опит в ИТ са доказали, че големите проекти винаги носят голям риск.
"Направете голям проект, с висок риск висок риск от провал. Да имаш три години и половина звучи като в модерен ден, това би било достатъчно, но ето един високорисков проект и всичко се оказа лошо, - каза Блур.
Той беше най-откровен за начина, по който се извършва тестване за интеграция за HealthCare.gov.
"Последното нещо, което ме направи, почти ме избухна в смях, е интеграционно тестване до две седмици, преди да отидете на живо - и това е точно така, как бихте могли да направите това с нещо подобно? Как бихте могли?" - каза Блор.
Споделяйки тази перспектива е ветеранският федерален изпълнител и колега-научен работник, д-р Джефри Малафски от Phasic Systems Inc. Малафски наскоро предложи едночасова подробна оценка на внедряването на HeathCare.gov и коментира както взетите стратегически и тактически решения., Преди всичко, той сочи с пръст протокола за придобиване на федералното правителство.
"Една от критичните точки на неуспех, която прониква особено в правителствените ИТ проекти, е това наследствено, архаично, остаряло схващане, че можете да формулирате цялата необходима бизнес логика с някои линейни изисквания. Това по принцип не работи с големи ИТ системи", каза той.
Смисълът му е, че големите ИТ системи ще победи дори и най-умните планиращи. Просто никога не знаете откъде ще възникнат проблеми, къде ще трябва да осигурите допълнителна поддръжка или какъв вид отстраняване на неизправности ще се окажете ангажирани. Следователно е лоша идея да ограничите процеса на проектиране, като принудите инженерите на проекти да предвиждат всичко те ще се нуждаят отпред.
Малкофски казва, че усложняващият въпрос е фактът, че служителите за обществени поръчки във федералното правителство вече са станали толкова мощни - поради огромните суми пари, които те контролират - че по същество контролират напредъка на големите ИТ проекти. Това поставя служителите на ведомствата в ролята на молител и вмъква елемент на риск в решаваща процедура в центъра на всяка значима ИТ инициатива: избор на правилни инструменти, технологии и изпълнители.
"Хората, които най-гласно не са съгласни с това твърдение, се наричат професионалисти по придобиване. Аз ги насърчавам да се появят в моята къща и ние ще седим наоколо и ще обсъждаме това, защото имам много емпирични доказателства, които да подкрепят това", каза Малафски казах.
Стратегия на сайта
Един голям въпрос, който трябва да се зададе, е защо правителството използва такава цялостна архитектура за този уебсайт.
"Ако всеобхватната правителствена програма е създадена така, че застрахователните компании всъщност са собственик на клиента, след като поемат ангажимент, тогава защо не просто да насочите трафика към съществуващия канал за взаимодействие с клиента, който застрахователните компании вече имат? Да, те могат трябва да увеличат своите собствени, но това би било валидна причина за бизнеса, защото сега те ще получат нови клиенти ", каза Малафски.
Световно известният (и сега донякъде скандален) пионер на софтуера за сигурност Джон Макфей също коментира тази стратегия съвсем наскоро, като направи някои противоречиви забележки по повод „Шоуто на Нийл Кавуто“ на Fox News:
"О, сериозно е лошо", каза Макафи. „Някой е направил сериозна грешка, не при проектирането на програмата, а просто в прилагането на уеб аспекта от нея. Искам да кажа, например, всеки може да създаде уеб страница и да твърди, че е брокер за тази система … всеки хакер може да постави уебсайт, направи го да изглежда изключително конкурентен и поради естеството на системата - а в крайна сметка това е здравеопазването - те могат да ви зададат най-интимните въпроси и вие свободно ще им отговорите. "
Що се отнася до самата уеб архитектура, Малафски посочва очевидното - че Интернет не е създаден да изпълнява сложни приложения. Това беше работата на мейнфрейм през дните, когато Мрежата беше в начален стадий. По-скоро, дизайнерската точка за Интернет е била за просто споделяне на информация чрез отделни страници, разпространени в широка мрежа от компютри. При проектирането на системи целта е да се изгради нещо, което работи. Включването на сложността заради себе си е несъобразено, откровено прелюбодейно и почти винаги е рецепта за бедствие.
В своето дълбоко гмуркане за това, което се обърка с HealthCare.gov, The Washington Post публикува вече известна графика, изобразяваща различните предизвикателства, преживени от сайта. Езикът, използван от хартията за описание на сайта, всъщност е доста показателен, особено когато смятате, че това е утвърденият вестник на Вашингтон, окръг Колумбия, епицентър на федералното правителство на САЩ:
HealthCare.gov, построен от 55 изпълнители, е един от най-сложните парчета софтуер, създаван някога за федералното правителство. Тя комуникира в реално време с поне 112 различни компютърни системи в цялата страна. През първите 10 дни той е получил 14, 6 милиона уникални посещения, според администрацията на Обама.
Източник: The Washington Post
Може би, по дефиниция, някой да твърди, че има част от софтуера, трябва да е така, че софтуерът действително работи. В противен случай имате компилация от код, който все още не представлява софтуер. Отстрани, обърнете внимание на изброените номера, особено частта за комуникация в реално време със 112 различни компютърни системи в цялата страна. Това е перфектен пример за прославяне на сложността заради себе си.
„Ние знаем, че друга възможност е да се създаде проста, много проста система за уеб-брокерство, която всичко, което прави, е чрез много прост код на сървъра за приложения и дори по-опростен клиентски Javascript, създава много приятен интерфейс, който произвежда навити данни на хората ", Каза Малафски. "Ето какво можете да направите: стъпка през това; стъпка през това. Тогава всяко действие, което се случи, може да се извърши в точка за избор и да бъде изпратено до някой, който действително ще притежава програмата." Разбира се, че "някой" се отнася до застрахователните компании, които така или иначе ще притежават полиците.
Графичната графика
Системните дизайнери по целия свят трябва да са разбрали, че са видели тази графика. Нека да разгледаме различните очертани стъпки и по-специално сериозните проблеми, които възникват при такава амбициозна архитектура. Първо и най-важното, ще разгледаме броя на потенциалните транзакции, които са се провалили досега, повечето поради софтуерни изчаквания - случаи, когато една част от процеса на транзакцията не получи необходимите си данни в рамките на приемлив период от време.
"Всяко парче софтуер в тази графика имаше свои таймаути и дори не е еднократно изчакване. Може да бъде и повече", каза Малафси. "Изтичането на който и да е от тях ще убие цялата транзакция. Някои от тях са лесни за настройване и наблюдение, като лог файлове. Те са като тайм-аутите на уеб сървъра и сървъра на приложения. Някои са по-непрозрачни. Имате бази данни с едновременност и задействания, но те са мулти взаимодействие. Ако наистина се задълбочите в това как работят базите данни, това не е хубава гледка. " (Научете основите на това как работят базите данни в нашия урок за бази данни.)
„Сървърите на базата данни обичат да казват:„ Поддържаме всичко в ред. “ Всъщност не ", каза Малафски. Единственият начин, по който те могат да повишат производителността и наистина да я управляват, е, че има поредица от файлове с печат във времето, които се създават в хранилището, постоянното съхранение и те не са превърнати в едно изчерпателен точен набор от данни, който е достъпен за всеки по всяко време, защото това отнема твърде много време. Това би убило латентността на транзакциите. Трябва да се вгледате в тези подробности и след това да се навие през интерфейс за управление - и това минава от някои много приятни сложни имена като задействания и съвместимост - но това всъщност означава, че отнема доста време, за да получите данните, да актуализирате данните и ако не мога да го направя, преди да постъпи друга заявка, просто ще ви кажа. " Забравете. Затворен съм за бизнес. "
- "Предната врата"
Графиката на "Вашингтон пост" включва много любопитна информация точно в най-горния раздел в първия й "проблемен" раздел, където се казва, че "администрацията на Обама реши в края на септември да изключи функция, която би позволила на хората да пазаруват за здравни планове, без първо да създавате онлайн акаунт. "
Еха. На първо място, наистина ли това е "функция", която беше изключена? Говорим за фундаментален поток на сайта. Първоначално планът беше да се даде възможност на хората да пазаруват, а след това в подходящия момент да обмислят регистрация на акаунт.
Някои критици спекулират, че тази промяна в последната минута (сама по себе си невероятно рисков ход с голям проект) показва, че администрацията знае, че сайтът не работи добре през последните няколко седмици, водещи до старта на 1 октомври, Вместо това се появи идеята да се събере цялата информация на тези, които се нуждаят от застраховка, така че маркетинговите усилия да бъдат положени за тях някъде по линията, след като сайтът функционира.
От гледна точка на използваемост и капацитет, този последен момент постави огромно напрежение върху каквато и основа на базата данни да има сайтът. Това обяснява всички анекдоти на хора, които не могат да се регистрират или са принудени да променят паролите си. И нека бъдем честни тук. Има ли някакъв проблем по-щателно решен в цялата мрежа от процеса на настройка на потребителски акаунт? Yahoo, Google, Microsoft, YouTube, Twitter, LinkedIn - дори класът за плетене на баба ви - има своя собствена динамична форма за регистрация в наши дни, с отпечатана регистрация, пренасочване и други основни функции. - Регистрация
Когато дойде време да се регистрирате на HealthCare.gov, изпълнителите казват: „Комуникацията между някои от тези системи не работи правилно, което означава, че много потребители не са успели да създадат акаунт.“
Какво? Кои системи? Говорим за клиентска база данни! След това "системите" ще бъдат уеб клиентът и клиентската база данни. Кои други системи са участвали? Това конкретно "обяснение" няма смисъл. - Доказателство за идентичност
Следващо, доказателство за самоличност. За тази стъпка не са посочени никакви проблеми, което също е любопитно. Experian е посочен като агент на трета страна, който ще "провери" нечия самоличност. Без съмнение, разрешаването на идентичността е сериозен проблем, който трябва да бъде решен. Повечето застрахователни компании използват вашия номер за социално осигуряване, както и доставчици на трети страни като Experian. Наистина ли няма проблеми с тази стъпка?
Ние знаем със сигурност от многобройни анекдоти, проверени от представената документация, че HealthCare.gov определено е имал редица поверителна информация. Малафски посочва, че проблемите с качеството на данните са много по-сериозните от проблемите с капацитета. (И Bloor отбелязва, че ако проблемите с капацитета наистина са били проблемите, те би трябвало да бъдат решавани за дни, а не седмици. Можете да добавите хардуер, да виртуализирате, да правите всякакъв брой неща за проблеми с капацитета.)
Не, проблемите с качеството на данните са наистина опасните. И най-тревожният аспект от всички са възникналите проблеми с качеството на данните. Има истории за хора, които се регистрират, след което получават поверителни документи за допустимост, принадлежащи на други регистранти! Това смрад на абсолютно страховит дизайн под завивките. Не използват ли някакъв универсален идентификационен код за всеки човек?
„Умният ход би бил да се създаде универсален уникален идентификатор (UUID), да се съхраняват криптирани стойности - забележете множествено число - от това, което може да бъде уникална информация (SSN, DOB, възраст, биометрия), и след това да ги оцените за доказателства за уникална личност“, - каза Малафски.
Това, че някой може да получи поверителни документи на различен човек, е неописуемо лошо и демонстрира някои много сериозни проблеми с картографирането дълбоко в корема на звяра. - приемливост
Добре, хора. Ето къде животът става интересен! Ако транзакцията ви не е изтекла до този момент, тя почти сигурно е направила тази стъпка. Според графиката на The Washington Post "системата трябва да определи допустимостта за финансова помощ, като изпрати личната информация на потребителя до Data Hub, който сключва договори за десетки федерални и държавни агенции."
Опитът да се извърши транзакция в три или четири ключови системи е истинско предизвикателство. Опитът да ударите "десетки" държавни и федерални агенции "в реално време" е извън класациите и напълно ненужен. Малафски взе само една точка за взаимодействие, за да направи своя случай:
„Едно от очевидните тук е получаването на финансови данни на човек, за да се определи дали те заслужават субсидия или каква би била цената им, така че ние преминаваме към IRS. Сега, ние имаме някаква връзка там, но тази връзка е на живо Това означава, че когато потребителят седи там и чака на екрана на компютъра си, той трябва да направи връзка към системите за IRS. В перфектен свят тази връзка се случва, компютрите говорят, получавам резултат и се връщам.
"Какво ще кажете в реалния свят? Какво ще кажете, когато IRS системите са претоварени? Какво ще кажете, когато те са на капацитет? Ами кога може би правят поддръжка? Какво става с мрежа между мрежовия операционен център на входното ниво Уеб страница, която клиентът вижда в центъра на IRS? Може би има някакви проблеми там. Може би има вирус. Може би има троянски кон, който тича наоколо и телекомите са затворили нещата, за да решат проблема. Това ще убие транзакцията от гледна точка на изглед на потребителя. Това е само една от много такива точки в тази архитектура, "каза Малафски.
Неговата идея е, че всяка една от тези системи - тъй като тази уеб архива е създадена за HealthCare.gov - всяка от тях е потенциална ахилесова пета. Това е ситуация без печалба. И отново това е ненужно от гледна точка на работния процес. По пътя има много точки, по които работният процес може да бъде допълнен с данни от данни в почти реално време, данни за правилното време, дори човешка намеса за справяне с основните точки на отказ в автоматизацията.
Следователно голямата стратегическа грешка се опитваше да постигне толкова невероятно сложен сайт. - Пазаруване за план
Запомнете: Това трябваше да е оригиналният поток на сайта. Уеб сърфистите първо ще пазаруват за застрахователен план. След това, когато намерят нещо интересно, те могат да се регистрират за сметка, да проверят за субсидии, ако желаят и в крайна сметка да закупят план.
Според графиката, „на някои хора с ниски доходи се казва, че нямат право на субсидии или не отговарят на условията за Medicaid, въпреки че трябва“. Въпросът тук става: Защо този проблем е изброен под стъпка 5, вместо на стъпка 4? Това е проблем, свързан с това, че предишната стъпка не е изчислена по подходящ начин и по този начин не е правилно включена в стъпка 5. - Застрахователен превод
В нашия свят наричаме тази част ETL. Това е толкова решен проблем, колкото регистрацията на сайта.
- Записване за застраховане
Светият Граал! Но изчакайте, има един последен "проблем", според изпълнителите на HealthCare.gov: "Докладите, известни като 834s, понякога са объркващи и дублиращи, което затруднява застрахователните компании да разберат кои са всъщност новите им клиенти."
Нека да вземем малко време за мълчание, за да оценим този …
Така че, да, всъщност застрахователната компания трябва да знае коя е наистина застрахователната. Това е доста критичен компонент. Същото важи и за спешния работник, който знае кой човек да лекува, или лекар, чийто гръден кош трябва да бъде трансплантиран. В медийния бизнес можем да характеризираме това малко парче като случай на нашите федерални изпълнители, които доста успешно погребват залога. - обхват
Не на последно място, графиката гласи, че "служителите на администрацията казват, че купувачите са подали повече от 700 000 заявления за здравно осигуряване. Някои от тях са постъпили през HealthCare.gov, а други чрез държавни пазари. Но служителите отказват да кажат колко хора са се записали на планираме. "
Ръчно заменяне
Може би най-рязката крива топка, хвърлена в сместа съвсем наскоро, беше ходът за популяризиране на хартиени приложения поради предизвикателствата с функционалността на сайта. За съжаление, дори хартиените формуляри трябва да бъдат изпращани в не функциониращия сайт. По дефиниция това не е ръчно отмяна. По дефиниция ръчното отмяна трябва да позволи на някого или нещо ръчно да отмени автоматизираната система.
И сега, в момента на публикуването на тази статия, чуваме, че за възобновяването на HealthCare.gov администрацията разчита по-силно на застрахователните компании, за да отстрани проблемите. Познайте какво означава това - ще се обзаложа, че сте понички в долари (да, беше и обратното), че това, което се случва в момента, е случай на широко разпространени рип-и-замени. По-конкретно, програмистите и инженерите вероятно са изтръгнали много от "връзките в реално време" и други изключително скъпи междинни програми, които така вълнуват редакторите на Washington Post. Замяната на целия този сложен код е много по-опростена, по-висока латентна връзка, която се захранва от набор от данни, свързани с повече от пакетна среда към различните държавни и федерални системи.
С други думи, решението, което Малафски, Блор и Макафи предлагат, е накъде отиваме. И целият този фантастичен код за спагети, който тези федерални изпълнители са изразходвали половин милиард долара за строеж през последните три години и половина? В контейнера за остри части.
Погребан олово
И една последна забележка: Според свидетелствата пред Конгреса от Хенри Чао, заместник-началник на информационния център на Центъра за Medicare и Medicaid Services, платежната система, която ще възстановява застрахователните компании с всички тези федерални субсидии? Все още не е построен! Това означава, че това може би е първият мащабен сайт за електронна търговия, стартиран някога без работещи средства за превод на пари.
