Kļūda slimnīcas rēķinu izrakstīšanā, ko trīs nedēļas ilgi neviens nepamanīja

Ievads

Pagājušajā pavasarī kāda reģionālā slimnīcu sistēma Vidējos Rietumos savā parastajā izmaiņu procesā ieviesa grafika labojumu. Nekas dramatisks — tikai ikdienišķs atjauninājums, lai saskaņotu izrakstīšanas laikus ar rēķinu izrakstīšanas moduli. Trīs nedēļas vēlāk kāds no debitoru grāmatvedības darbiniekiem pamanīja virkni atgriezto prasību sakarā ar nesakritīgiem laika zīmogiem. Kad IT nodaļa izsekoja problēmas cēloni, izrādījās, ka labojums bija ietekmējis apdrošināšanas pieteikumus vairāk nekā četriem simtiem pacientu. Neviens nebija izdarījis neko nepareizu, ja precīzi ņem vērā. Atjauninājums izturēja visus pārbaudes saraksta testus. Vienkārši tas nebija pareizais pārbaudes saraksts.

Šis stāsts man ir palicis atmiņā, jo tas patiesībā nav par slimnīcām. Tas ir par to, kas notiek, ja sistēmas, kas klusi darbojas organizācijas fonā, tiek uzskatītas par gataviem produktiem, nevis par dzīvu infrastruktūru, kurai nepieciešama regulāra pārbaude.

Automatizācija, ko jūs ieviesāt pirms diviem gadiem, nav tā automatizācija, par kādu jūs to uzskatāt

Lielākā daļa uzņēmumu izveido savas pirmās darba plūsmu automatizācijas, lai atrisinātu konkrētu, acīmredzamu problēmu. Personāla nodaļas komanda ir apnikusi manuāli virzīt atvaļinājuma pieprasījumus. Pārdošanas operāciju speciālists automatizē potenciālo klientu piešķiršanu, lai pārstāvji vairs neizvēlētos tikai vislabākos klientus. Tās tiek veidotas ar automatizācijas rīkiem, kas līdzinās „Power Automate“ — ātri konfigurējamas, viegli nododamas ikvienam, kurš vēlas par tām rūpēties, un lielākoties nemanāmas, kad tās sāk darboties.

Problēma ir tā, ka „kad tie sāk darboties”, tas kļūst par pastāvīgu stāvokli. Neviens neplāno pārskatīšanu. Cilvēks, kurš to izveidoja, pāriet uz citu komandu vai pamet uzņēmumu. Tikmēr uzņēmumā notiek izmaiņas, kas ietekmē automatizāciju — jauni CRM lauki, atšķirīga apstiprināšanas hierarhija, apvienošanās, kas divkāršo apjomu, kas plūst caur sistēmu, kura tika izveidota pusei no šīs slodzes. Automatizācija turpina darboties tieši tā, kā tika izstrādāta, un tieši tas ir problēmas cēlonis. Tā tika izstrādāta uzņēmumam, kas vairs nepastāv tieši tādā formā.

Esmu redzējis, kā loģistikas uzņēmums atklāja, ka automatizētā izņēmumu maršrutēšanas plūsma jau vienpadsmit mēnešus klusi nedarbojās pareizi, jo piegādātājs bija mainījis API lauka nosaukumu. Kāds bija risinājums? Kāds bija manuāli atkārtoti ievadījis neveiksmīgos gadījumus, neko nevienam nepasakot, pieņemot, ka tas ir vienreizējs gadījums. Tas nav rīka kļūme. Tā ir organizācijas nespēja pārskatīt kaut ko, ko visi uzskatīja par stabilu.

Slimnīcām ir tāds pats risks, taču ar daudz augstāku likmi

Pārnesiet šo pašu modeli uz slimnīcas klīnisko un administratīvo sistēmu kopumu, un kļūdu pielaide kļūst niecīga. Slimnīcu programmatūras izstrādē parasti ir dota priekšroka atbilstībai un nepārtrauktai darbībai, nevis pielāgojamībai — tas ir saprotams, ņemot vērā, ka neveiksmīga ieviešana var nozīmēt, ka medmāsa plkst. 2 naktī nevarēs apskatīt zāļu lietošanas vēsturi. Taču šī pati piesardzība nozīmē, ka novecojušās sistēmas bieži paliek ekspluatācijā daudz ilgāk, nekā vajadzētu, tās tiek laistas ar lappusēm, nevis pārbūvētas, jo neviens nevēlas būt tas, kurš sabojā kaut ko, kas ir sistēmas pamats.

Rezultātā rodas arhitektūra, kurā uzkrājas lēmumi, kurus neviens vairs neatceras. Plānošanas modulis sazinās ar norēķinu moduli, izmantojot integrāciju, kas izveidota 2016. gadā piegādātājam, kura pakalpojumus slimnīca pārtrauca izmantot 2019. gadā. Tas joprojām darbojas — lielākoties. „Lielākoties” nav vārds, ko vēlaties saistīt ar pacientu datiem.

Lēnām mainās izpratne, ka noturība veselības aprūpes IT jomā nav saistīta ar izmaiņu izvairīšanos — tā ir saistīta ar pietiekami elastīgu sistēmu izveidi, kas spēj pielāgoties izmaiņām, neizmantojot nelielu brīnumu katru reizi, kad mainās regulējums vai tiek pievienots jauns EHR modulis.

Kāpēc „ja tas nav salūzis” ir nepareizs kritērijs

Abos scenārijos ir šāda lieta: sistēmas nebija salūzušas. Tās darbojās tieši tā, kā bija konfigurētas. Tieši tāpēc neviens tām nepievērsa uzmanību.

Nesakārtotām sistēmām pēc definīcijas tiek pievērsta uzmanība — kāds sūdzas, kaut kas apstājas, tiek iesniegts ziņojums. Bīstamas ir tās sistēmas, kas virspusēji darbojas labi, bet klusi novirzās no tā, kas organizācijai patiesībā ir nepieciešams. Darba plūsmas automatizācija, kas joprojām darbojas, bet novirza uz nepareizo nodaļu. Slimnīcas saskarne, kas joprojām pārraida datus, bet izlaiž lauku, no kura tagad ir atkarīga nākamā sistēma.

Revīzija nav glamour, bet arī alternatīva nav

Risinājums koncepcijas ziņā nav sarežģīts, lai gan praksē tas ir nogurdinošs: plānojiet periodiskas pārskatīšanas visam, kas darbojas bez uzraudzības, neatkarīgi no tā, cik labi tas ir darbojies vēsturiski. Jautājiet, kam tas pieder tagad. Jautājiet, kas ir mainījies augšup un lejup pa ķēdi kopš tā izveides. Jautājiet, vai kāds pamanītu, ja rīt tas klusi pārstātu darboties.

Lielākā daļa organizāciju to izlaiž, jo tas šķiet drīzāk kā uzturēšana, nevis attīstība, un uzturēšanai reti tiek piešķirts budžets vai aplausi. Taču izlaišanas izmaksas nekur nepazūd — tās vienkārši klusi gaida brīdi, kad kāds debitoru grāmatvedībā pamanīs, ka skaitļi nesaskan.