Karolinska-hospitalet ramt af EPJ-nedbrud

hvor ofte papir-journalerne oplevede den klasse af problemer.

Aldrig. Til gengæld hændte det af og til, at journalen var forlagt og skulle findes. Jeg er lidt i tvivl om, et netværksnedbrud kan betegnes som et EPJ-nedbrud. Alt muligt andet må også have været plaget af det.

Man kan godt lave et nødsystem, så de indlagte/indskrevne patienter stadig kan behandles, det har man sikkert også.

Eksemplet rejser naturligvis spørgsmålet: er konsekvenserne af forskellige nedbrud gennemtænkt og afprøvet ?

Antallet af patienter på et hospital gør jo, at backup ikke er triviel - pga. det nødvendige antal arbejdsstationer.

Det åbne spørgsmål kan være: hvis personalet i bedste "bagedyst-stil" træder væk fra arbejdsstationerne, hvad kan så ske / hvad kan så ikke ske ?

De kan næppe starte noget nyt (operationer), men hvad ellers er umuligt ? Medicinering ? ..........

Det er da en tanke værd .....

Eksemplet rejser naturligvis spørgsmålet: er konsekvenserne af forskellige nedbrud gennemtænkt og afprøvet ?

Umiddelbart burde et EPJ system være ganske nemt at sikre høj oppetid på. Man kan replikere information til mange servere - det giver høj oppetid for læsning. Man kan partionere information sådan at man får høj scalability. Og man kan arbejde med eventual consistency, sådan at opdateringer ikke behøver ende i "databasen" før de er committet. De skal blot afleveres et persistent sted (fx. på en form på EMB).

Naturligvis bliver det hele sværere jo mere systemet er integeret med andre systemet, men at sikre at lægen altid kan se data burde være en overkommelig opgave. Såfremt dette er indtænkt i arkitekturen fra start ... ellers kan det selvfølgeligt være en deal-breaker.

Men Michael, det er jo lige præcis det som er min pointe:
- det samlede system, set fra brugeren på en afdeling, består jo af mange komponenter i en daisy-chain.
Du omtaler jo netop kun den første blomst i kæden.
Een af de sidste blomster i kæden er jo netværket på afdelingen.
Og det er koblet til ....., som via en switch er koblet til ...., som .......

Dels er der jo HW fejl, som altid har eksisteret, men med forskellige komponenter i nævnte daisy-chain er der også SW fejl, tilfældige eller fra en mislykket opdatering.
Og eet af de grimme scenarier er jo en mislykket opdatering, en opdatering med fejl, som kræver nyt SW i mange / flere komponenter.
Alene fejlsøgningen ......
Den simple løsning synes en dublering af kabler, switches, ....., helt frem til afdelingen. Måske færre terminaler, måske langsommere, men .....

Nå en kendt, stort, dansk TV-udbyder nu på 5. dagen er delvis nede, så ..... Nørdernes optismisme er stor, og ubegrundet, i systemernes ufejlbarlighed.

Men Michael, det er jo lige præcis det som er min pointe:
- det samlede system, set fra brugeren på en afdeling, består jo af mange komponenter i en daisy-chain.
Du omtaler jo netop kun den første blomst i kæden.

Jeg siger ikke at pålidelighed kommer af sig selv. Jeg siger at man kan designe systemer sådan at de er pålidelige indenfor systemet sfære. Systemet vil have nogle krav til resten af virksomheden: Elforsyning, netværk der virker, internet, køling af datacenter, etc. Hvis der er klare aftaler om hvad man kan forvente, så kan hver enkelt område optimeres for sig. Uden at det behøver blive meget kompliceret.

Det er ret klart at for at læger på et hospital kan fungere så må de have adgang til patientens journal - Et EPJ system kan designes sådan at det har høj oppetid. Et netværk kan designes til at levere høj oppetid. Elforsyning kan designes til høj pålidelighed. På de områder hvor man har brug for høj oppetid, da må systemet designes til at levere samme. På områder hvor man ikke kan garantere høj oppetid, der må man have manuelle workarounds.

Nå en kendt, stort, dansk TV-udbyder nu på 5. dagen er delvis nede, så ..... Nørdernes optismisme er stor, og ubegrundet, i systemernes ufejlbarlighed.

Omvendt kender jeg virksomheder hvor fejlretning påbegyndes efter 15 sekunders downtime og hvor den øverste ledelse begynder at stille spørgsmål efter 10 minutter. Hvis pålidelighed er vigtigt, så gennemsyrer det hele virksomheden. Så kommer nye systemer ikke i drift indtil de er stabile og det er en god ting at være forsigtig. Det kommer ikke af sig selv, det er ikke gratis og det handler hvad man prioriterer højt.

Jeg er ganske sikker på at hospitaler mener oppetid for EPJ systemer er vigtigt. Dermed følger at oppetid for netværk og elforsyning også er vigtig. Måske er extern connectivity mindre vigtigt (det vil jeg umiddelbart mene, men jeg ved det ikke). Arkitekturen bør reflektere deres prioriteter. Mht. til Yousee, så er det min oplevelse på at de kun prioriterer private kunder højt når problemer rammer alle på en gang.