For the average application, IT professionals strive to minimize downtime. But when it happens – as it inevitably will – the users are simply forced to wait until the system is once again available.
In a clinical setting, this strategy is not acceptable. Regardless of whether the system unavailability is caused by an outage in your server or the hospital’s connectivity to it, the hospital must address the question: How will we continue to care for patients until the system comes back up?
A typical fallback strategy is paper. Today’s hospitals are being pushed to cut costs and go paperless, though, and having everything printed from the system, just in case there’s an outage, does not sit well with those working toward these goals.
One recent application built by NVISIA solved this problem in a very straightforward way. Each hospital department using the application configured a daily report, including an FTP location on their own LAN where the report should be sent. Each night in batch, the application generates and sends the downtime reports to their respective locations. Each morning, the department managers review their downtime report and copy it to their local machine. In the event of a system downtime, the local daily downtime report is available to continue department operations.
This strategy allows the hospitals to remain paperless, while adequately accounting for downtime. Unless the system, the FTP server and the department manager’s computer are simultaneously unavailable, patient care is uninterrupted.
Related posts
No related posts.
Courtney Palit
Dan Christopherson
Dave Kurzynski
Dru Henke
Erik Gfesser
Jim LoVerde
Kevin Crosby
Matt Warren
Roman Kuzmik
Tracey Barrett
One Comment
… definitely a difficult scenario to plan for. From your post, it seems as though you are explaining how NVISIA solved the read-only part of the application. Interesting approach, but what about data capture?
One of the ways that we solved the data capture piece in our clinical environment was by developing data acquisition applications that were able to maintain more state on the client EDC (electronic data capture) system when needed. Once the client application determined that the server (or network for that matter) was not available, data was temporarily stored locally. Then, once it was determined that the server / network was back online, a synchronization with the server was able to occur. Grant it, this strategy will not work for the ‘Net at large (for public facing applications), but for highly controlled clinical environments, latency and the amount of data being captured per visit is predictable, and re-synchronizing isn’t that huge of a challenge. We were able to do this with a slightly thicker client (Java Web Start)… but for the web purists, I’m guessing there is some sort of slick JavaScript framework somewhere that will allow for acceptable levels of serialization in intranet environments.