Emne 5.4 — Sundhedsøkonomi i softwareudvikling

Hvorfor det er vigtigt i sundhedsøkonomi

Enhver moderne sundhedsorganisation er, uanset om den indrømmer det, en softwareoperatør. Patientjournaler, ordination, planlægning, laboratoriesvar, betalingskrav og befolkningsovervågning kører alle på kode – købt fra leverandører, bygget internt, arvet fra forgængere eller syet sammen på tværs af alle tre. De involverede penge er store og tilbagevendende: nationale elektroniske patientjournalprogrammer har forbrugt milliarder af dollar af offentlige midler, og driftsomkostningerne ved sundhedssoftware – vedligehold, integration, opgraderinger, sikkerhed – dværger typisk den pris, der stod i den oprindelige business case. Alligevel siger det meste sundhedsøkonomisk uddannelse intet om, hvordan software opfører sig som et økonomisk aktiv, og det meste softwareudviklingsuddannelse siger intet om alternativomkostning i et system, der også køber sygeplejersker og lægemidler.

Hullet betyder noget, fordi software svigter økonomisk på karakteristiske måder, som almindelige indkøbsreflekser ikke fanger. Et system købes på sin købspris og demonstrationsfunktioner; integrations-, datamigrerings- og vedligeholdelsesbyrden ankommer senere, mod budgetter der aldrig blev hørt. Et leverandørforhold hærder til afhængighed, så hver fornyelse forhandles fra svaghed. Genveje taget under deadlinepres akkumuleres usynligt, indtil det system, der driver hospitalet, ikke længere kan ændres sikkert – og så står organisationen over for en moderniseringsregning, den aldrig planlagde, og som den ikke kan udskyde, fordi softwaren nu bærer klinisk risiko. Historien om store sundheds-IT-programmer, herunder Det Forenede Kongeriges National Programme for IT (nedlagt i 2011 efter en estimeret omkostning på omkring 10 mia. pund), er en historie om disse dynamikker i national skala.

For en direktør er indsatsen tredobbelt. For det første penge: software er en hele-livs-forpligtelse, og den billige mulighed ved køb er rutinemæssigt den dyre mulighed over et årti. For det andet sikkerhed: i en klinisk setting er et nedbrud, en datafejl eller et ikke-vedligeholdeligt system ikke en ulejlighed, men en fare, med omkostninger, der lander i Emne 3.11 — Økonomi i kvalitet og sikkerhed. For det tredje suverænitet: valgene mellem at bygge og købe, mellem proprietære og åbne systemer og mellem standard- og skræddersyede grænseflader afgør, hvor megen frihed organisationen vil have til at handle om fem år – og handlefrihed er, som denne bog argumenterer gennemgående, et økonomisk aktiv.

Centrale begreber

Softwareudvikling er den disciplinerede udformning, konstruktion og vedligeholdelse af software – og ordet vedligehold bærer det meste af økonomien. I modsætning til en bygning er software aldrig færdig: krav skifter, regler ændrer sig, afhængigheder ældes, og sikkerhedstrusler udvikler sig. Softwarevedligeholdelse – korrigerende, adaptivt og forebyggende arbejde på et system i drift – absorberer almindeligvis størstedelen af et systems livstidsomkostning. Den økonomiske analyseenhed er derfor aldrig købet; det er de samlede ejeromkostninger: anskaffelse plus integration, datamigrering, uddannelse, hosting, support, opgraderinger, sikkerhed og eventuel afvikling, over systemets realistiske levetid.

Det andet begreb er teknisk gæld: den implicitte fremtidige omkostning ved at vælge et belejligt design nu i stedet for et solidt. Metaforen er præcis nok til at bruge i et finansmøde. Gæld er ikke i sig selv dårlig – en bevidst genvej, der leverer en nødvendig kapabilitet tidligere, kan være et rationelt lån – men den påløber renter: hver fremtidig ændring af systemet koster mere på grund af den, og uhåndteret gæld vokser med renters rente, indtil forandring bliver uoverkommeligt dyr eller farlig. En sundhedsorganisation, der ikke kan se sin tekniske gæld, bærer en ubogført forpligtelse, præcis som havde den uregistreret låntagning.

For det tredje det legacy-system: software, der forbliver i drift ud over det punkt, hvor den kan vedligeholdes økonomisk – ofte fordi den virker, alle afhænger af den, og at erstatte den er skræmmende. Legacy er teknisk gæld i organisatorisk skala, og det præsenterer et ægte vurderingsproblem: omkostningerne ved at beholde det (stigende vedligehold, sikkerhedseksponering, personale der ikke længere kan ansættes, forbedringer blokeret andetsteds) er diffuse og gradvise, mens omkostningen ved udskiftning er koncentreret, synlig og politisk risikabel. Sundhedssystemer verden over kører kritiske ydelser på årtier gammel software netop af denne grund.

For det fjerde afhængighed. Leverandør-lock-in er den tilstand, hvor det koster så meget at skifte væk fra en leverandør – i datamigrering, omskoling, genintegration og klinisk forstyrrelse – at køberen har mistet effektiv forhandlingsstyrke. I sundhed forværres den af data: et årtis patientjournaler holdt i et proprietært format er en gidsel. Lock-in er ikke et uheld; det er en prisstrategi, og tiden til at prissætte den er før underskrift, ikke ved fornyelse. Modvægtene er kontraktuelle (dataeksportrettigheder, escrow, udgangsbistand) og arkitektoniske – frem for alt standarder.

For det femte interoperabilitet: systemers evne til at udveksle information og bruge det udvekslede. Dens økonomi er netværkseffektens økonomi – hvert system, der taler en fælles standard, hæver værdien af hvert andet system, der gør – hvilket er grunden til, at interoperabilitet kronisk underforsynes af markeder: gevinsterne tilfalder systemet som helhed, mens omkostningerne falder på hver leverandør og køber, og en etableret aktør kan tjene på ikke at interoperere. Standarder som Fast Healthcare Interoperability Resources (FHIR), HL7-familien, den tilhører, og openEHR findes for at sænke disse udvekslingsomkostninger, og tilsynsmyndigheder – for eksempel USA gennem 21st Century Cures Acts regler mod informationsblokering og Den Europæiske Union gennem det europæiske sundhedsdataområde – er begyndt at påbyde, hvad markedet ikke leverede.

For det sjette make-or-buy-spektret, herunder open source-software – software, hvis kildekode frit kan bruges og ændres. Open source er ikke gratis: licensomkostningen forsvinder, men implementering, hosting og forvaltning forbliver, og nogen må vedligeholde koden. Dens økonomiske særkende er anderledes – den fjerner lock-in-præmien og omdanner softwaren til et fælles gode, mange købere kan medfinansiere, hvilket er grunden til, at platforme som DHIS2 og OpenMRS bærer meget af sundhedsinformationsbyrden i lav- og mellemindkomstlande. Bygge-versus-købe-beslutningen er ligeledes ikke en teknologipræference, men et porteføljespørgsmål: byg, hvor kapabiliteten differentierer, og organisationen kan opretholde et ingeniørteam; køb, hvor behovet er standardvare; og byg aldrig, hvad du ikke kan vedligeholde.

Endelig pålidelighed som en økonomisk størrelse. Klinisk software kører ydelser, hvor nedetid har en sundhedsomkostning, så de ingeniørdiscipliner, der holder systemer pålidelige – herunder site reliability engineering, som styrer pålidelighed mod eksplicitte mål og budgetterer for acceptabelt svigt – forstås bedst som køb af forsikring, hvis præmie er ingeniørindsats. Pålidelighed ud over, hvad den kliniske setting har brug for, er spild; under det betales underskuddet i hændelser. Vurderingsapparatet for alt dette forbliver Emne 2.1 — Økonomisk evaluering og overkommelighedsdisciplinen fra Emne 2.5 — Budgetkonsekvenser og overkommelighed; dette emne leverer den softwarespecifikke omkostningsstruktur, de metoder skal fødes med. At evaluere et digitalt værktøj som en sundhedsindsats – forbedrer appen eller telesundhedsydelsen udfald til acceptabel omkostning – hører til Emne 5.2 — Sundhedsøkonomi i digital sundhed; økonomien i AI-modeller specifikt til Emne 5.3 — Sundhedsøkonomi i AI.

Bedste praksis

Vurdér samlede ejeromkostninger over systemets realistiske levetid, aldrig købsprisen. Kræv, at hver softwarebusiness case omkostningsfører anskaffelse, integration, datamigrering, uddannelse, hosting, support, sikkerhed, opgraderinger og afvikling over en angivet horisont – som regel et årti eller mere – og nævner, hvilket budget der bærer hver tilbagevendende linje. Et licensgebyr sammenlignet med intet er ikke en business case; det er den synlige spids af en forpligtelse.
Sæt teknisk gæld i regnskabet. Lad ingeniørledere vedligeholde et register over de væsentlige genveje og aldrende komponenter i ejendommen, med et ærligt estimat af den rente, hver opkræver – langsommere ændringer, højere hændelsesrisiko, blokerede forbedringer. Gennemgå det med samme alvor som en finansiel forpligtelse, og budgetter en stående andel af ingeniørkapaciteten (almindeligvis en femtedel til en tredjedel) til afdrag, for udskudt gældsbetjening er vokset med renters rente gæld.
Finansiér vedligehold som en driftsomkostning fra dag ét. Software, der er "færdig", er software, der forfalder: afhængigheder ældes, trusler udvikler sig, regler ændrer sig. Byg vedligeholdelsesstrømmen ind i den oprindelige vurdering og det tilbagevendende budget, og behandl et forslag uden en vedligeholdelseslinje som ufuldstændigt – pengene vil blive brugt uanset, og det eneste spørgsmål er, om de var planlagt eller udvundet af en krise.
Prissæt lock-in før du underskriver, ikke ved fornyelse. For hvert større køb: omkostningsfør udgangen, mens du stadig har alternativer: hvem der ejer dataene, i hvilket format de kan eksporteres, hvilken udgangsbistand leverandøren skal yde, og hvad en migrering plausibelt ville koste. Forhandl dataeksportrettigheder og åbne grænseflader ind i kontrakten, og behandl en leverandørs modstand mod dem som information om den fornyelsesforhandling, der kommer.
Køb interoperabilitet bevidst, fordi markedet underforsyner den. Kræv understøttelse af åbne standarder – FHIR og dens slægtninge – som betingelse for køb, verificér påstået overholdelse mod jeres faktiske dataflow frem for en brochure, og afvis skræddersyede grænseflader, hvor en standard findes. Hver proprietær grænseflade, du accepterer, er en skifteomkostning, du har skænket leverandøren, og en skat på hver fremtidig integration.
Beslut bygge-versus-købe som en portefølje, afstemt efter jeres ingeniørkapacitet. Byg kun, hvor kapabiliteten differentierer jeres ydelse, og I realistisk kan rekruttere, fastholde og finansiere et team til at vedligeholde, hvad I bygger – et internt system uden et vedvarende team er et legacy-system med ekstra trin. Køb standardbehov; overvej open source-platforme, hvor et fællesskab eller offentligt konsortium opretholder dem; og skriv opretholdelsesplanen ind i beslutningen, uanset hvilken vej den går.
Behandl open source som en indkøbsmulighed med sin egen omkostningsstruktur, ikke som gratis. Sammenlign den på samlede ejeromkostninger: ingen licensafgift, men reelle implementerings-, hosting-, support- og forvaltningsomkostninger, uanset om de bæres internt eller gennem en supportleverandør. Vej dens særlige fordele – ingen lock-in-præmie, inspicerbar kode, evnen til at medfinansiere et fælles gode med andre sundhedsorganer – og dens særlige forpligtelse: hvis du afhænger af den, så bidrag til at opretholde den.
Fastsæt pålidelighedsmål ud fra klinisk konsekvens, og brug penge til målet. Beslut, ydelse for ydelse, hvad en times nedetid faktisk koster – i forsinket pleje, usikre omgåelser og tabt tillid – og fastsæt tilgængeligheds- og genoprettelsesmål derefter. Hold så ingeniørudgiften til målet fra begge sider: at betale for mindre pålidelighed, end klinikken har brug for, køber hændelser, og at betale for mere, end den har brug for, køber forgyldning.
Planlæg legacy-udskiftning, før den bliver tvunget. Gennemgå alder og vedligeholdelighed af kritiske systemer på en cyklus, og begynd udskiftning, mens det eksisterende stadig virker – en migrering udført under svigt er den dyreste slags. Foretræk inkrementel migrering (at kvæle det gamle system grænseflade for grænseflade) frem for big-bang-overgange, hvis svigtmåde i sundhed måles i aflyste klinikker og tabte journaler.
Gør datamigrering til en førsteklasses linje i hver vurdering. Patientdata overlever hvert system, der holder dem, og at flytte dem – rent, fuldstændigt, med klinisk sikkerhed sikret – er rutinemæssigt blandt de største og mest undervurderede omkostninger ved enhver overgang. Omkostningsfør det eksplicit, test det tidligt med reelle journaler, og behold forvaltningen af dine data i eksporterbar form gennem et systems liv, så migreringen aldrig er gidsel for den afgående leverandør.
Hold klinisk sikkerhedsingeniørarbejde inden for økonomien. Sundhedssoftware er sikkerhedsrelevant software: ændringer skal testes, udgivelser skal have tilbagerulningsveje, hændelser skal undersøges, og jurisdiktioner pålægger i stigende grad formelle kliniske risikostandarder på sundheds-IT. Disse discipliner koster ingeniørtid og hører hjemme i business casen – en "billigere" levering, der springer dem over, overfører omkostning til patienter som risiko (skadens omkostning er Emne 3.11 — Økonomi i kvalitet og sikkerhed).
Led softwarebeslutninger gennem den samme værdigranskning som enhver anden sundhedsinvestering. Et softwareprogram konkurrerer om det samme begrænsede budget som lægemidler og personale, så det skylder den samme disciplin: en angivet gevinst, et reelt sammenligningsgrundlag (herunder "forbedr det, vi har"), en overkommelighedsprofil over tid og efterimplementeringsgennemgang mod de løfter, der blev givet (apparatet er Emne 2.1 — Økonomisk evaluering og Emne 2.5 — Budgetkonsekvenser og overkommelighed, og indkøbshåndværket er Emne 3.10 — Strategisk indkøb og bestilling).

Spørgsmål at drøfte med dit team

Hvad koster vores softwareejendom egentlig om året, og hvor stor en andel af det planlagde vi? De fleste organisationer kan nævne deres licensgebyrer, men ikke deres integrations-, vedligeholdelses-, sikkerheds- og omgåelsesomkostninger, som gemmer sig i driftsbudgetter og personaletid på tværs af organisationen. Bed teamet samle det sande årlige tal for de øverste håndfuld systemer og sammenligne det med, hvad de oprindelige business cases lovede. Spændingen er, at de diffuse omkostninger ikke har nogen enkelt ejer, så ingen er ansvarlig for deres vækst, og de mennesker, der godkendte købet, sjældent er dem, der betaler for vedligeholdet. Et ærligt svar frembringer et hele-livs-tal, nævner hvilke budgetter der bærer det og indrømmer, hvor udgiften er uplanlagt – fordi en omkostning, du opdager årligt bagud, er en omkostning, du ikke kan styre.
Hvor er vores tekniske gæld, og hvilken rente betaler vi på den? Ingeniørteams ved som regel præcis, hvor gælden er – modulet, ingen tør røre, grænsefladen holdt sammen af manuelle trin, platformen to versioner bagud på sikkerhedsstøtte – men viden når sjældent bestyrelsen i økonomisk sprog. Bed om registeret: de væsentlige gældsposter, hvad hver bremser eller bringer i fare, og hvad det ville koste at afdrage. Spændingen er, at gældsafdrag konkurrerer med synlige nye funktioner og altid taber på optik, hvilket netop er, hvordan gæld vokser med renters rente. Et ærligt svar kvantificerer renten (langsommere levering, hændelseseksponering, blokerede projekter), forpligter en stående andel af kapaciteten til reduktion og accepterer, at noget gæld er rationelt at bære – forudsat at den bæres bevidst.
Hvis vi måtte forlade vores hovedsystemleverandør om tre år, kunne vi det – og hvad ville det koste? Dette spørgsmål bringer lock-in frem, mens der stadig er tid til at reducere den. Undersøg, hvem der ejer dataene, og i hvilket format de kan forlade, hvad kontrakten siger om udgangsbistand, hvor mange skræddersyede grænseflader der skulle genopbygges, og hvilken omskoling og klinisk forstyrrelse en migrering ville pålægge. Spændingen er, at alle håber aldrig at skulle udøve udgangen, så ingen vil betale for at holde den åben – men en udgang, der er umulig, er en fornyelsesforhandling, der allerede er tabt. Et ærligt svar prissætter udgangen, identificerer de to-tre handlinger, der ville gøre den billigere (dataeksportrettigheder, standardgrænseflader, dokumentation) og behandler den pris som en forhandlingsposition, organisationen aktivt vedligeholder.
Hvilke systemer bør vi bygge, hvilke bør vi købe, og matcher vores ingeniørkapacitet det svar? Bygge-versus-købe-opdelingen er en porteføljebeslutning, mange organisationer træffer ved akkumulation frem for ved valg og ender med at bygge standardvarer og købe, hvad der differentierer dem. Spørg, hvilke af jeres systemer der reelt indlejrer noget særegent ved jeres ydelse, og hvilke der er standardbehov, et marked eller et open source-fællesskab allerede betjener. Test så kapacitetspåstanden: for alt bygget internt, findes der et finansieret, rekrutterbart team, der er forpligtet til at vedligeholde det i dets levetid – ikke blot projektet, der skabte det? Spændingen er, at bygning smigrer ambition, og køb smigrer forsigtighed, og ingen af instinkterne er en analyse. Et ærligt svar nævner differentiatorerne, indrømmer, hvor tidligere byggerier bør afvikles eller erstattes med standardprodukter, og nægter at starte noget byggeri, hvis vedligehold er ufinansieret.
Hvad koster en times nedetid i vores mest kritiske system faktisk, og er vores pålidelighedsudgift afstemt til det? Pålidelighedsbeslutninger træffes ofte af ingeniører uden kliniske omkostningsoplysninger eller af bestyrelser uden ingeniøromkostningsoplysninger, så udgiften matches til vane frem for konsekvens. Gennemgå et konkret scenarie: den elektroniske journal er nede på tværs af en travl dag – hvad forsinkes, hvilke usikre omgåelser dukker op, hvilken skade følger plausibelt, hvad koster genopretning? Sammenlign så det med, hvad I bruger på modstandsdygtighed, backup, failover og hændelsesindsats. Spændingen går begge veje: underudgift køber hændelser, men forgyldning af et lavrisikosystem spilder penge, en anden ydelse har brug for. Et ærligt svar fastsætter et eksplicit tilgængeligheds- og genoprettelsesmål pr. kritisk ydelse, afledt af klinisk konsekvens, og kan vise den ingeniørudgift, der opfylder det – hverken mere eller mindre.
Hvad er vores plan for de legacy-systemer, alle er bange for at røre? Enhver moden sundhedsorganisation har dem: systemer forbi økonomisk vedligeholdelighed, holdt i live, fordi de virker, og udskiftning er skræmmende. Nævn jeres. Spørg, hvad hver blokerer – integrationer ikke bygget, forbedringer ikke foretaget, sikkerhedseksponering båret – og hvad udskiftningsvejen er: inkrementel migrering, fuldstændig udskiftning eller bevidst, planlagt fastholdelse med indeholdt risiko. Spændingen er tidslig: omkostningerne ved at beholde legacy er diffuse og årlige, mens omkostningen ved at erstatte den er koncentreret og karrieresynlig, så rationelt udseende udskydelse er standarden, til svigt tvinger sagen til den værst mulige pris. Et ærligt svar planlægger udskiftning, mens det eksisterende stadig virker, foretrækker kvæle-stil inkrementel migrering frem for big-bang-overgang og behandler "vi beslutter næste år" som den beslutning, den faktisk er.

I praksis: et sundhedsøkonomisk eksempel

Sundhedsministeriet i et fiktivt østafrikansk land står over for en fornyelsesbeslutning. I ni år har dets regionale hospitaler kørt et proprietært hospitalsinformationssystem leveret af en udenlandsk leverandør. Systemet virker, men fornyelsestilbuddet er steget kraftigt, hver ny grænseflade – til den nationale forsikringsordning, til laboratorienetværket – er et skræddersyet, leverandørprissat projekt, og kontrakten er tavs om dataeksport. Samtidig kører ministeriets distriktssundhedskontorer allerede DHIS2, den open source-platform, der bruges til national sundhedsstatistik, og et nabo-land har implementeret en open source-patientjournalplatform med et regionalt supportkonsortium.

Ministeriets sundhedsøkonomiske enhed omformulerer beslutningen fra "forny eller ej" til en hele-livs-sammenligning af tre muligheder over ti år: forny det eksisterende, forny kortvarigt, mens man bygger udgangsrettigheder, eller migrer inkrementelt til open source-platformen. Omkostningsføringen af mulighederne afslører den reelle økonomi. Det eksisterendes licens er kun en tredjedel af dets sande årlige omkostning, når skræddersyede grænseflader, obligatoriske opgraderingsprojekter og udenlandsk supportrejse tælles med. Open source-muligheden bærer ingen licens, men kræver, at ministeriet finansierer et nationalt supportteam, regional hosting og et bidrag til platformens fællesskab – reelle, tilbagevendende penge, som "gratis software"-retorikken havde skjult. Den afgørende linje er dog hverken af disse: det er datamigrering. Ni års patientjournaler ligger i et proprietært skema, og leverandørens pris for udtræksbistand er i realiteten prisen for at forlade.

Enheden prissætter udgangen alligevel, og tallet ændrer forhandlingen. Bevæbnet med et omkostningsført alternativ forhandler ministeriet en toårig fornyelse til en lavere pris, der inkluderer kontraktuel dataeksport i et dokumenteret format og standard FHIR-grænseflader til forsikringsordningen og laboratorienetværket – købt, økonomisk set, som en option på en billigere fremtidig udgang, værdisat på samme måde som Emne 3.12 — Økonomi i pandemi og beredskab værdisætter enhver option på fremtidig handlefrihed. I løbet af de to år migrerer et pilotprojekt tre distriktshospitaler til open source-platformen og tester supportkonsortiet, datamigreringsværktøjerne og – afgørende – om ministeriet kan rekruttere og fastholde de ingeniører, platformen kræver, med brug af arbejdsstyrkeøkonomien fra Emne 3.6 — Sundhedsarbejdsstyrke og arbejdsmarkeder.

Pilotprojektet lykkes på to hospitaler og kæmper på det tredje, hvor bemandingshuller gør hver hændelse til en krise – en advarsel om kapacitet, ikke software. Ministeriet går videre med en faseopdelt national migrering over fem år, hospital for hospital, og holder det eksisterende kørende parallelt, indtil hvert steds data er verificeret. Den endelige evaluering gør lærdommen eksplicit: det vindende træk var ikke at vælge open source frem for proprietær, men at prissætte hele livet af hver mulighed, købe udgangsrettigheder før afhængigheden hærdede yderligere og afstemme ingeniørforpligtelsen med, hvad ministeriet faktisk kunne opretholde.

Fire sektorperspektiver

Startup

En sundhedssoftware-startup lever dette emnes økonomi fra sælgersiden: dens værdiansættelse belønner leveringshastighed, hvilket netop er, hvordan teknisk gæld akkumuleres, og dens indtægtsmodel kan i stilhed afhænge af den lock-in, dens kunder burde modstå. Disciplinen er at tage gæld bevidst – en genvej, der vinder en afgørende kunde, kan være rationel – mens man holder et register og en afdragsplan, fordi en kodebase, der ikke kan ændres, er en virksomhed, der ikke kan pivotere. Interoperabilitet er strategi, ikke overholdelse: standardgrænseflader (FHIR frem for alt) er, hvordan et lille produkt gør sig fortjent til en plads inde i ejendomme domineret af etablerede aktører. Og klinisk sikkerhedsingeniørarbejde er ikke bureaukrati, der skal udskydes til skala; én dataintegritetshændelse i en klinisk setting kan ende en ung virksomhed.

Lille virksomhed

En lille, men etableret udbyder – en klinikgruppe, en apotekskæde, et diagnostisk laboratorium – køber næsten al sin software og har ingen ingeniørstab til at kompensere for et dårligt køb, så dens økonomi er afhængighedens økonomi. Samlede ejeromkostninger og udgangsrettigheder betyder mere her end noget andet sted, fordi et fejlprissat system forholdsmæssigt er en større andel af budgettet, og en mislykket migrering kan standse virksomheden. Den fornuftige holdning er standardisering: mainstream-produkter, åbne standardgrænseflader, hostede ydelser frem for egendrevne servere og kontrakter læst for dataeksportklausuler før pris. Dens særlige risiko er stille legacy – praksisstyringssystemet, der ældes på stedet, til dets leverandør går konkurs – så selv en lille køber bør hvert år vide, hvad det ville koste at forlade hvert system, den afhænger af.

Virksomhed

En stor hospitalskoncern eller forsikrer kører hundredvis af systemer, så dens problem er porteføljen: overlappende produkter købt af forskellige afdelinger, et integrationsvæv ingen fuldt kortlægger, og teknisk gæld fordelt over en ejendom, der er for stor til, at noget enkelt team kan se den. Den modne virksomhed styrer ejendommen, som den styrer en investeringsportefølje – en fortegnelse over systemer med ejere, hele-livs-omkostninger, gælds- og risikovurderinger og planlagte udskiftningshorisonter – og finansierer en stående ingeniørkapabilitet til integration, pålidelighed og afdrag frem for at behandle hver forbedring som et projekt, der skal byde på. Skala giver den også indkøbsmagt, den mindre køber mangler: den kan kræve standardgrænseflader, dataeksportrettigheder og escrow som adgangsbetingelser, og dens arkitekturvalg disciplinerer dens leverandører frem for omvendt.

Offentlig sektor

Et ministerium eller en national betaler former denne økonomi for alle andre. Det fastsætter de interoperabilitetsregler, der afgør, om markedet belønner eller straffer åbenhed – som USA gjorde med 21st Century Cures Acts bestemmelser mod informationsblokering og Den Europæiske Union med det europæiske sundhedsdataområde – og dets egne indkøbsteams lærer leverandører, hvad købere vil tolerere. Dets særlige fejlmønster er det nationale megaprogram: centraliseret, big-bang, politisk tidsplanlagt softwarelevering, hvis kollaps måles i milliarder, som Det Forenede Kongeriges National Programme for IT demonstrerede. Disciplinen er den modsatte holdning – standarder og platforme centralt, levering inkrementelt, med open source- og lokalt vedligeholdelige muligheder vejet seriøst, hvor kommercielle markeder er tynde (det politiske apparat er Emne 3.2 — Sundhedspolitik, og indkøbshåndværket Emne 3.10 — Strategisk indkøb og bestilling).

Almindelige fejlmønstre

At købe licensen, ikke livet. At godkende software på købspris, mens integration, migrering, vedligehold og udgang forbliver uomkostningsført. Løsning: kræv hele-livs samlede ejeromkostninger, med navngivne budgetter for hver tilbagevendende linje, i hver business case.
Usynlig gæld, indtil den vokser med renters rente. At lade teknisk gæld akkumulere uregistreret, til ejendommen ikke kan ændres sikkert. Løsning: hold et gældsregister, rapportér det i økonomiske termer, og forpligt stående kapacitet til afdrag.
At sovende glide ind i lock-in. At acceptere proprietære formater og skræddersyede grænseflader, til udgang er uoverkommelig, og fornyelser dikteres. Løsning: forhandl dataeksportrettigheder og standardgrænseflader ved køb, og prissæt udgangen årligt.
At bygge, hvad man ikke kan vedligeholde. At bestille interne systemer uden et finansieret team for hele deres liv. Løsning: intet byggeri uden en opretholdelsesplan; køb eller adoptér open source-platforme, hvor kapaciteten er tynd.
At behandle open source som gratis. At adoptere fællesskabsplatforme uden at finansiere hosting, support og forvaltning. Løsning: vurdér open source på samlede ejeromkostninger, og budgetter den opretholdelse, den kræver.
Pålidelighed ved håb. At lade tilgængelighedsmål være uangivet, til et nedbrud afslører den kliniske omkostning ved nedetid. Løsning: fastsæt tilgængeligheds- og genoprettelsesmål pr. kritisk ydelse ud fra klinisk konsekvens, og brug penge til målet.
Big-bang legacy-udskiftning under tvang. At udskyde modernisering, til svigt tvinger en forhastet, total overgang. Løsning: planlæg udskiftning, mens det eksisterende virker, og migrer inkrementelt med parallel drift og verificerede data.
Software uden for værdidisciplinen. At lade IT-programmer springe den granskning over, der anvendes på lægemidler og ydelser. Løsning: samme regler – angivet gevinst, reelt sammenligningsgrundlag, overkommelighedsprofil, efterimplementeringsgennemgang.

Modenhedsmodel

Dimension	Igangsætte	Udvikle	Standardisere	Styre	Orkestrere
Hele-livs-omkostningsføring	Software købt på licenspris; driftsomkostninger opdaget bagud	Større køb omkostningsført over flere år; tilbagevendende linjer delvis identificeret	Samlede ejeromkostninger over systemets levetid kræves i hver business case, med navngivne budgetter	Omkostninger for hele ejendommen følges mod prognose, afvigelser undersøges, prognoser rekalibreres	Hele-livs-økonomi styrer porteføljen: investeringer, fornyelser og afviklinger rebalanceres løbende
Teknisk gæld	Usynlig; opdaget gennem hændelser	Kendt uformelt af ingeniører; ingen fælles registrering	Gældsregister vedligeholdt og rapporteret i økonomiske termer; stående afdragskapacitet	Gældstendenser styret med grænser og prioriteter; rente målt i leveringshastighed og hændelseseksponering	Gæld taget og afviklet bevidst som strategi, prissat ind i hver leveringsbeslutning
Leverandør og udgang	Vilkår accepteret som tilbudt; udgang uprissat	Lock-in erkendt; nogle eksportklausuler søgt	Dataeksportrettigheder og standardgrænseflader kontraktfæstet som regel; udgange omkostningsført ved køb	Udgangspositioner vedligeholdt og øvet; fornyelser forhandlet mod et levende alternativ	Leverandørportefølje formet over tid; afhængighed en valgt, prissat position, aldrig et uheld
Interoperabilitet	Skræddersyede grænseflader akkumulerer sag for sag	Åbne standarder foretrukket, hvor det er belejligt	Standardoverholdelse (f.eks. FHIR) en verificeret betingelse for køb	Integrationsejendom kortlagt og styret; proprietære grænseflader afviklet efter plan	Organisationen former standardindførelse på tværs af partnere og sit marked
Pålidelighed og sikkerhed	Nedetidsomkostning ukendt; genopretning improviseret	Backup og hændelsesindsats findes; mål implicitte	Tilgængeligheds- og genoprettelsesmål fastsat pr. kritisk ydelse ud fra klinisk konsekvens	Pålidelighed konstrueret og målt mod mål; hændelser undersøgt økonomisk	Modstandsdygtighed orkestreret på tværs af ejendommen og leverandører, øvet og løbende forbedret

Tjekliste

Vurdér hver softwarebeslutning på samlede ejeromkostninger over dens realistiske levetid, med navngivne budgetter for hver tilbagevendende linje.
Vedligehold et register over teknisk gæld, rapportér det i økonomiske termer, og forpligt stående ingeniørkapacitet til afdrag.
Finansiér vedligehold som en planlagt driftsomkostning fra den oprindelige business case og frem.
Forhandl dataeksportrettigheder, standardgrænseflader og udgangsbistand ind i kontrakter ved køb.
Prissæt udgangen fra hvert større system årligt, og hold et omkostningsført alternativ i live før fornyelser.
Kræv verificeret overholdelse af åbne standarder (f.eks. FHIR) som betingelse for køb.
Beslut bygge-versus-købe som en portefølje, og start intet byggeri uden en finansieret hele-livs-opretholdelsesplan.
Vurdér open source-muligheder på samlede ejeromkostninger, og budgetter hosting, support og forvaltning.
Fastsæt tilgængeligheds- og genoprettelsesmål pr. kritisk ydelse ud fra klinisk konsekvens, og afstem udgiften til dem.
Planlæg legacy-udskiftning, mens eksisterende systemer stadig virker, og foretræk inkrementel migrering frem for big-bang-overgang.
Omkostningsfør og test datamigrering tidligt, og hold patientdata eksporterbare gennem hvert systems liv.
Led softwareprogrammer gennem den samme værdigranskning som enhver anden sundhedsinvestering, med efterimplementeringsgennemgang.

Centrale kilder

WHO, Global Strategy on Digital Health 2020–2025 – Verdenssundhedsorganisationens ramme for digitale sundhedsinvesteringer, herunder bæredygtigheds- og interoperabilitetsprincipper.
HL7 International – FHIR (Fast Healthcare Interoperability Resources)-standarden, den dominerende åbne standard for sundhedsdataudveksling.
openEHR, DHIS2 og OpenMRS – open source-sundhedsinformationsplatforme og -specifikationer udbredt verden over, eksempler på fællesskabsopretholdt sundhedssoftware.
U.S. Office of the National Coordinator for Health IT (nu ASTP) – 21st Century Cures Acts regler om informationsblokering og interoperabilitet, et regulatorisk svar på underforsynet interoperabilitet.
DORA, Accelerate State of DevOps-rapporter – langvarig forskning, der kobler softwareleverings- og pålidelighedspraksis til organisatorisk præstation.
UK National Audit Office – rapporter om National Programme for IT i NHS, den kanoniske casestudie af svigt i et sundheds-IT-program i stor skala.

Referencer

Software engineering — Wikipedia — https://en.wikipedia.org/wiki/Software_engineering
Software maintenance — Wikipedia — https://en.wikipedia.org/wiki/Software_maintenance
Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
Network effect — Wikipedia — https://en.wikipedia.org/wiki/Network_effect
Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software
Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
World Health Organization — Global Strategy on Digital Health 2020–2025 — https://www.who.int/publications/i/item/9789240020924
HL7 International — FHIR specification — https://hl7.org/fhir/
National Audit Office — The National Programme for IT in the NHS: an update on the delivery of detailed care records systems — https://www.nao.org.uk/reports/the-national-programme-for-it-in-the-nhs-an-update-on-the-delivery-of-detailed-care-records-systems/
National Programme for IT — Wikipedia — https://en.wikipedia.org/wiki/National_Programme_for_IT