Det tekniska felet i sjukhusets faktureringssystem som ingen upptäckte på tre veckor

Inledning

Ett regionalt sjukhussystem i Mellanvästern genomförde en schemaläggningsuppdatering enligt sin vanliga förändringsprocess förra våren. Inget dramatiskt – en rutinmässig uppdatering av hur utskrivningstiderna synkroniserades med faktureringsmodulen. Tre veckor senare upptäckte någon på kundreskontran att en rad fordringar hade avvisats på grund av felaktiga tidsstämplar. När IT-avdelningen spårade felet visade det sig att uppdateringen hade påverkat försäkringsansökningarna för över fyrahundra patienter. Ingen hade egentligen gjort något fel. Uppdateringen klarade alla tester på checklistan. Det var bara inte rätt checklista.

Den här historien har fastnat i mitt minne eftersom den egentligen inte handlar om sjukhus. Den handlar om vad som händer när de system som tyst arbetar i bakgrunden av en organisation behandlas som färdiga produkter istället för som en levande infrastruktur som behöver regelbunden granskning.

Den automatisering du satte upp för två år sedan är inte den automatisering du tror att den är

De flesta företag bygger sina första automatiseringar av arbetsflöden för att lösa ett specifikt, uppenbart problem. En HR-avdelning tröttnar på att manuellt vidarebefordra ansökningar om ledighet. En person inom försäljningsverksamheten automatiserar tilldelningen av leads så att säljarna slutar att välja ut de bästa. Dessa byggs med automatiseringsverktyg som liknar Power Automate – snabba att konfigurera, lätta att överlämna till den som är villig att ta ansvar för dem, och i stort sett osynliga när de väl fungerar.

Problemet är att ”när de väl fungerar” blir det permanent. Ingen planerar in någon översyn. Den som byggde den byter team eller slutar. Under tiden förändras verksamheten runt automatiseringen – nya CRM-fält, en annan godkännandehierarki, en fusion som fördubblar volymen som flödar genom ett system byggt för halva belastningen. Automatiseringen fortsätter att köras exakt som den är utformad, vilket är precis problemet. Den utformades för ett företag som inte längre existerar i just den formen.

Jag har sett ett logistikföretag upptäcka att ett automatiserat flöde för hantering av undantag hade fungerat felaktigt i elva månader utan att någon märkt det, eftersom en leverantör ändrat namnet på ett API-fält. Lösningen? Någon hade manuellt matat in de misslyckade fallen på nytt utan att säga något till någon, i tron att det var en engångsföreteelse. Det är inte ett verktygsfel. Det är ett organisatoriskt misslyckande att inte se över något som alla antog var stabilt.

Sjukhus löper samma risk, men med mycket högre insatser

Ta samma mönster och placera det i ett sjukhus kliniska och administrativa system, så kollapsar marginalen för fel. Utvecklingen av sjukhusprogramvara har vanligtvis prioriterat efterlevnad och drifttid framför anpassningsförmåga – vilket är förståeligt, med tanke på att en misslyckad driftsättning kan innebära att en sjuksköterska inte kan ta fram läkemedelshistoriken klockan två på natten. Men samma försiktighet innebär att äldre system ofta förblir i drift mycket längre än de borde, lappade istället för att byggas om, eftersom ingen vill vara den som förstör något bärande.

Resultatet blir en arkitektur som ackumulerar beslut som ingen minns att man fattat. En schemaläggningsmodul kommunicerar med faktureringssystemet via en integration som byggdes 2016 för en leverantör som sjukhuset slutade använda 2019. Det fungerar fortfarande, för det mesta. ”För det mesta” är inte ett uttryck man vill ha i närheten av patientdata.

Det som långsamt håller på att förändras är insikten att motståndskraft inom IT för hälso- och sjukvården inte handlar om att undvika förändring – det handlar om att bygga system som är tillräckligt flexibla för att hantera förändringar utan att det krävs ett litet mirakel varje gång en regel ändras eller en ny EHR-modul kopplas på.

Varför ”om det inte är trasigt” är fel test

Här är saken med båda scenarierna: systemen var inte trasiga. De fungerade exakt som de var konfigurerade. Det är just därför ingen tittade på dem.

System som inte fungerar får per definition uppmärksamhet – någon klagar, något stannar upp, ett ärende registreras. De farliga systemen är de som på ytan fungerar bra men som i smyg glider ur synk med vad organisationen faktiskt behöver. En automatiserad arbetsflödesprocess som fortfarande körs men som dirigeras till fel avdelning. Ett sjukhusgränssnitt som fortfarande överför data men som utelämnar ett fält som ett nedströms system nu är beroende av.

Revision är inte glamoröst, men det är inte alternativet heller

Lösningen är inte komplicerad i teorin, även om den är mödosam i praktiken: planera in regelbundna granskningar av allt som körs obevakat, oavsett hur bra det har fungerat historiskt sett. Fråga vem som ansvarar för det nu. Fråga vad som har förändrats uppströms och nedströms sedan det byggdes. Fråga om någon skulle märka det om det tyst slutade fungera i morgon.

De flesta organisationer hoppar över detta eftersom det känns som underhåll snarare än framsteg, och underhåll får sällan budget eller beröm. Men kostnaden för att hoppa över det försvinner inte – den väntar bara, tyst, på det ögonblick då någon på kundreskontran märker att siffrorna inte stämmer.