Збій у системі розрахунків лікарні, якого ніхто не помітив протягом трьох тижнів

Вступ

Минулої весни регіональна система лікарень на Середньому Заході впровадила виправлення до системи планування через звичайний процес внесення змін. Нічого надзвичайного — це було рутинне оновлення, яке стосувалося синхронізації часу виписки з модулем виставлення рахунків. Через три тижні хтось із відділу дебіторської заборгованості помітив низку відхилених заяв через невідповідність часових міток. До того часу, як ІТ-відділ виявив причину, виправлення торкнулося страхових заяв для понад чотирьохсот пацієнтів. Ніхто, власне, не зробив нічого поганого. Оновлення пройшло всі тести з контрольного списку. Просто це був не той контрольний список.

Ця історія запам’яталася мені, бо насправді вона не про лікарні. Вона про те, що відбувається, коли системи, які тихо працюють у фоновому режимі організації, розглядаються як готові продукти, а не як жива інфраструктура, що потребує регулярного контролю.

Автоматизація, яку ви налаштували два роки тому, — це не та автоматизація, якою ви її вважаєте

Більшість компаній створюють свої перші автоматизовані робочі процеси, щоб вирішити конкретну, очевидну проблему. Команда HR втомлюється вручну обробляти заявки на відпустку. Співробітник відділу продажів автоматизує розподіл потенційних клієнтів, щоб представники не вибирали лише найпривабливіші проекти. Ці процеси створюються за допомогою інструментів автоматизації, подібних до Power Automate — їх швидко налаштовувати, легко передати тому, хто готовий за них відповідати, і вони стають практично непомітними, щойно запрацюють.

Проблема в тому, що «після запуску» стає постійним станом. Ніхто не планує перегляд. Людина, яка її створила, переходить в іншу команду або звільняється. Тим часом бізнес навколо автоматизації змінюється — з’являються нові поля в CRM, змінюється ієрархія затвердження, відбувається злиття, яке подвоює обсяг даних, що проходять через систему, розраховану на половину навантаження. Автоматизація продовжує працювати саме так, як було заплановано, і саме в цьому полягає проблема. Вона була розроблена для компанії, яка вже не існує в тому вигляді.

Я бачив, як логістична фірма виявила, що автоматизований потік маршрутизації винятків безшумно працював з помилками протягом одинадцяти місяців, оскільки постачальник змінив назву поля API. Як це обходили? Хтось вручну повторно вводив випадки, що завершилися невдачею, не повідомляючи нікому, вважаючи, що це було одноразове явище. Це не збій інструментарію. Це організаційна неспроможність переглянути те, що всі вважали стабільним.

Лікарні несуть той самий ризик, але з набагато вищими ставками

Візьміть ту саму схему та застосуйте її до клінічного та адміністративного стеку лікарні — і маржа помилки різко зменшиться. При розробці програмного забезпечення для лікарень зазвичай пріоритет надається відповідності вимогам та безперебійній роботі, а не адаптивності — це зрозуміло, враховуючи, що невдале розгортання може означати, що медсестра не зможе отримати історію прийому ліків о 2-й годині ночі. Але ця сама обережність означає, що застарілі системи часто залишаються в експлуатації набагато довше, ніж слід, їх латають, а не перебудовують, оскільки ніхто не хоче бути тим, хто зламає щось, що несе основне навантаження.

У результаті утворюється архітектура, в якій накопичуються рішення, про прийняття яких ніхто вже не пам’ятає. Модуль планування взаємодіє з модулем виставлення рахунків через інтеграцію, створену у 2016 році для постачальника, з послугами якого лікарня припинила співпрацю у 2019 році. Це все ще працює — здебільшого. А «здебільшого» — це не те слово, яке ви хотіли б бачити поруч із даними про пацієнтів.

Повільно змінюється усвідомлення того, що стійкість ІТ у сфері охорони здоров’я полягає не в уникненні змін, а в побудові систем, достатньо гнучких, щоб поглинати зміни без необхідності маленького дива щоразу, коли змінюється законодавство або додається новий модуль електронної медичної картки.

Чому критерій «якщо це не зламано» є неправильним

Ось у чому суть обох сценаріїв: системи не були несправними. Вони працювали саме так, як були налаштовані. Саме тому ніхто на них не звертав уваги.

Несправні системи за визначенням привертають увагу — хтось скаржиться, щось зупиняється, подається заявка. Небезпечними є ті системи, які на перший погляд працюють добре, але тихо відхиляються від того, що насправді потрібно організації. Автоматизація робочого процесу, яка все ще виконується, але направляє дані не в той відділ. Інтерфейс лікарні, який все ще передає дані, але вилучає поле, від якого тепер залежить система, що знаходиться нижче за ланцюгом.

Аудит — справа негламурна, але альтернатива теж

Вирішення проблеми не є складним за концепцією, навіть якщо на практиці це нудна робота: заплануйте періодичні перевірки всього, що працює без нагляду, незалежно від того, наскільки добре це працювало раніше. Запитайте, хто зараз за це відповідає. Запитайте, що змінилося на попередніх і наступних етапах з моменту створення системи. Запитайте, чи хтось помітить, якщо завтра вона тихо перестане працювати.

Більшість організацій пропускають цей крок, оскільки він здається скоріше технічним обслуговуванням, а не прогресом, а на технічне обслуговування рідко виділяють бюджет або висловлюють подяку. Але вартість пропуску цього кроку нікуди не зникає — вона просто тихо чекає на той момент, коли хтось із відділу дебіторської заборгованості помітить, що цифри не сходяться.