Den fejl i hospitalets fakturering, som ingen bemærkede i tre uger

Indledning

Et regionalt hospitalsystem i Midtvesten gennemførte sidste forår en opdatering af planlægningssystemet via sin sædvanlige ændringsproces. Intet dramatisk – blot en rutinemæssig opdatering af, hvordan udskrivningstidspunkter blev synkroniseret med faktureringsmodulet. Tre uger senere bemærkede en medarbejder i debitorbogholderiet en række afviste krav på grund af uoverensstemmende tidsstempler. Da IT-afdelingen havde sporet fejlen, havde opdateringen påvirket forsikringsanmeldelser for over 400 patienter. Ingen havde egentlig gjort noget forkert. Opdateringen bestod alle testene på tjeklisten. Det var bare ikke den rigtige tjekliste.

Den historie har sat sig fast i min bevidsthed, fordi den ikke egentlig handler om hospitaler. Den handler om, hvad der sker, når de systemer, der stille og roligt kører i baggrunden af en organisation, behandles som færdige produkter i stedet for som en levende infrastruktur, der har brug for regelmæssig kontrol.

Den automatisering, du satte op for to år siden, er ikke den automatisering, du tror, den er

De fleste virksomheder opretter deres første automatiseringer af arbejdsgange for at løse et specifikt, synligt problem. Et HR-team bliver træt af manuelt at videresende ansøgninger om ferie. En medarbejder i salgsafdelingen automatiserer tildelingen af kundeemner, så sælgerne holder op med at udvælge de bedste. Disse opbygges med automatiseringsværktøjer, der ligner Power Automate – hurtige at konfigurere, nemme at overdrage til den, der er villig til at tage ansvaret for dem, og stort set usynlige, når de først fungerer.

Problemet er, at »når de først fungerer«, bliver det en fast tilstand. Ingen planlægger en gennemgang. Den person, der oprettede den, skifter team eller forlader virksomheden. I mellemtiden ændrer forretningen sig omkring automatiseringen – nye CRM-felter, et andet godkendelseshierarki, en fusion, der fordobler mængden, der strømmer gennem et system, der er bygget til halvdelen af belastningen. Automatiseringen kører videre nøjagtigt som designet, og det er netop problemet. Den blev designet til en virksomhed, der ikke længere eksisterer i helt den form.

Jeg har set et logistikfirma opdage, at en automatiseret undtagelsesrute havde fungeret forkert i elleve måneder uden at nogen bemærkede det, fordi en leverandør havde ændret navnet på et API-felt. Løsningen? Nogen havde manuelt indtastet de fejlramte sager igen uden at fortælle det til nogen, idet vedkommende antog, at det var en engangsforeteelse. Det er ikke en fejl i værktøjet. Det er en organisatorisk fejl, hvor man undlod at genvurdere noget, som alle antog var stabilt.

Hospitaler bærer den samme risiko, men med langt højere indsats

Tag det samme mønster og sæt det ind i et hospitals kliniske og administrative systemer, og fejlmargenen bliver minimal. Softwareudvikling til hospitaler har typisk prioriteret overholdelse af regler og oppetid frem for tilpasningsevne – hvilket er forståeligt, da en mislykket implementering kan betyde, at en sygeplejerske ikke kan hente medicinhistorikken kl. 2 om natten. Men den samme forsigtighed betyder, at ældre systemer ofte forbliver i drift langt længere, end de burde, og bliver lappet sammen i stedet for genopbygget, fordi ingen ønsker at være den, der ødelægger noget bærende.

Resultatet er en arkitektur, der akkumulerer beslutninger, som ingen kan huske at have truffet. Et planlægningsmodul kommunikerer med faktureringssystemet via en integration, der blev bygget i 2016 til en leverandør, som hospitalet holdt op med at bruge i 2019. Det fungerer stadig – for det meste. »For det meste« er ikke et udtryk, man ønsker i nærheden af patientdata.

Det, der langsomt er ved at ændre sig, er erkendelsen af, at robusthed inden for sundheds-IT ikke handler om at undgå forandring – det handler om at opbygge systemer, der er fleksible nok til at absorbere forandringer uden at kræve et lille mirakel, hver gang en regulering ændres, eller et nyt EHR-modul bliver boltet på.

Hvorfor »hvis det ikke er i stykker« er den forkerte test

Her er pointen med begge scenarier: Systemerne var ikke i stykker. De fungerede præcis som konfigureret. Det er netop derfor, ingen kiggede på dem.

Systemer, der er i stykker, får per definition opmærksomhed – nogen klager, noget går i stå, der oprettes en supportanmodning. De farlige systemer er dem, der på overfladen kører fint, mens de stille og roligt glider ud af trit med det, organisationen rent faktisk har brug for. En automatisering af arbejdsgange, der stadig kører, men dirigerer opgaverne til den forkerte afdeling. En hospitalsgrænseflade, der stadig overfører data, men udelader et felt, som et efterfølgende system nu er afhængigt af.

Revision er ikke glamourøst, men det er alternativet heller ikke

Løsningen er ikke kompliceret i teorien, selvom den er kedelig i praksis: Planlæg periodiske gennemgange af alt, der kører uden opsyn, uanset hvor godt det historisk set har fungeret. Spørg, hvem der har ansvaret for det nu. Spørg, hvad der er ændret opstrøms og nedstrøms, siden det blev bygget. Spørg, om nogen ville lægge mærke til det, hvis det i morgen lydløst holdt op med at fungere.

De fleste organisationer springer dette over, fordi det føles som vedligeholdelse snarere end fremskridt, og vedligeholdelse får sjældent budget eller ros. Men omkostningerne ved at springe det over forsvinder ikke – de venter bare stille og roligt på det øjeblik, hvor nogen i debitorbogholderiet opdager, at tallene ikke stemmer.