Грешката в счетоводството на болницата, която никой не забеляза в продължение на три седмици

Въведение

Миналата пролет една регионална болнична система в Средния Запад приложи корекция в графика чрез обичайния си процес за промени. Нищо драматично — рутинна актуализация на синхронизацията между времето на изписване и модула за фактуриране. Три седмици по-късно някой от отдела за вземания забеляза група отхвърлени искове поради несъответстващи времеви отметки. Докато ИТ отдела проследи проблема, корекцията вече беше засегнала застрахователните заявления за над четиристотин пациенти. Никой не беше направил нищо погрешно, строго погледнато. Актуализацията беше преминала всички тестове от контролния списък. Просто не беше правилният контролен списък.

Тази история ми е останала в паметта, защото всъщност не става дума за болници. Става дума за това какво се случва, когато системите, които тихо работят на заден план в дадена организация, се третират като готови продукти, вместо като жива инфраструктура, която се нуждае от редовен контрол.

Автоматизацията, която сте настроили преди две години, не е тази, за която я мислите

Повечето компании създават първите си автоматизации на работни потоци, за да решат конкретен, очевиден проблем. Екипът по човешки ресурси се уморява да препраща ръчно заявките за отпуск. Сътрудник от отдела за продажби автоматизира разпределянето на потенциални клиенти, за да спрат търговските представители да си избират най-лесните случаи. Тези автоматизации се създават с инструменти, подобни на Power Automate — бързи за конфигуриране, лесни за предаване на всеки, който е готов да поеме отговорността за тях, и до голяма степен невидими, след като започнат да работят.

Проблемът е, че „след като заработят“ това става постоянно. Никой не планира преглед. Човекът, който я е създал, сменя екипа или напуска. Междувременно бизнесът се променя около автоматизацията — нови полета в CRM, различна йерархия на одобрение, сливане, което удвоява обема, преминаващ през система, създадена за половината натоварване. Автоматизацията продължава да работи точно както е проектирана, което е именно проблемът. Тя е проектирана за компания, която вече не съществува в точно същия вид.

Виждал съм как една логистична фирма открива, че автоматизиран поток за пренасочване на изключения е работил неправилно в продължение на единадесет месеца, без никой да забележи, защото един доставчик е променил името на поле в API. Какво е било решението? Някой ръчно е въвеждал отново случаите с грешки, без да каже на никого, като е предполагал, че това е еднократен случай. Това не е провал на инструментариума. Това е организационен провал да се преразгледа нещо, за което всички са приемали, че е стабилно.

Болниците носят същия риск, но залогът е много по-висок

Вземете същия модел и го приложете към клиничната и административната инфраструктура на болницата, и маржът за грешка се срива. Разработката на софтуер за болници обикновено е давала приоритет на съответствието с изискванията и непрекъснатостта на работата пред адаптивността — което е разбираемо, като се има предвид, че неуспешно внедряване може да означава, че медицинска сестра няма да може да извлече историята на медикаментозното лечение в 2 часа сутринта. Но същата тази предпазливост означава, че старите системи често остават в експлоатация много по-дълго, отколкото би трябвало, като се поправят с кръпки, вместо да се преизграждат, защото никой не иска да бъде този, който ще счупи нещо, което носи основната тежест.

Резултатът е архитектура, в която се натрупват решения, които никой не си спомня да е вземал. Модулът за график комуникира с модула за фактуриране чрез интеграция, създадена през 2016 г. за доставчик, с когото болницата е престанала да работи през 2019 г. Все още работи, до голяма степен. „До голяма степен“ не е израз, който искате да чувате в контекста на данните за пациентите.

Това, което се променя, макар и бавно, е осъзнаването, че устойчивостта в ИТ сектора на здравеопазването не се състои в избягването на промените — а в изграждането на системи, които са достатъчно гъвкави, за да поемат промените, без да се налага да се чуди на малки чудеса всеки път, когато се промени някое правило или се добави нов модул към електронната здравна документация.

Защо „ако не е счупено“ е грешен критерий

Ето какво е общото между двата сценария: системите не бяха счупени. Те работеха точно така, както бяха конфигурирани. Именно затова никой не им обърна внимание.

Счупените системи по дефиниция привличат внимание – някой се оплаква, нещо спира, подава се заявка. Опасните системи са онези, които на пръв поглед работят добре, докато тихо се разминават с това, от което организацията всъщност се нуждае. Автоматизация на работния процес, която все още се изпълнява, но пренасочва към грешния отдел. Болничен интерфейс, който все още предава данни, но премахва поле, от което сега зависи система по-надолу по веригата.

Одитът не е бляскав, но нито пък е алтернативата

Решението не е сложно като концепция, макар и да е досадно на практика: планирайте периодични прегледи на всичко, което работи без надзор, независимо колко добре е функционирало в миналото. Попитайте кой отговаря за него сега. Попитайте какво се е променило нагоре и надолу по веригата, откакто е било създадено. Попитайте дали някой би забелязал, ако утре то тихо спре да работи.

Повечето организации пропускат това, защото им се струва по-скоро поддръжка, отколкото напредък, а поддръжката рядко получава бюджет или аплодисменти. Но цената на пропускането ѝ не изчезва — тя просто чака, тихо, момента, в който някой от отдела за вземания забележи, че цифрите не съвпадат.