The Healthcare IT Guy, Shahid Shah, has a great post up on his blog about writing safety critical software using an agile, risk-based approach. Here’s a portion of the blog post where Shahid really hits the nail on the head:
Much of that [every software being custom] changed in the 90’s and then upended even further in the early part of the 21st century; we should no longer weighed down by the baggage of the past.These days even our hardware is agile and extensible, real-time operating systems are plentiful, software platforms are malleable, mHealth is well established, and programming languages are sophisticated so we need to be open to reconsidering our development approaches, especially risk-based agile.
Why should we use “risk-based” agile? Because not every single line of code in software can or should be treated equally – some parts of our medical device software can kill people, many parts merely annoy people, but most other parts simply aren’t worth the same attention as the safety-critical components. When you treat every line of code the same (as is often true in a plan-driven approach) and you have a finite amount of resources and time you end up with lower quality software and less reliable medical devices. It’s not fair to blame the FDA for our own bad practices.
I’m always amazed by Shahid’s knowledge and ability to describe something in simple terms. I should know since I’m often on calls with Shahid since he’s my partner in Influential Networks and Physia.
The irony is that in the EHR and mHealth world you could argue that many have taken too much of a lean approach to building their applications while the medical device world treats every part of the software as a patient safety issue. Now if we could just bring the two together into a more reasonable balance of what’s important from the safety side and what’s not.
As far as I can tell, the FDA is planning to mostly stay out of regulating the general mHealth and EHR side of healthcare IT and will stick to the medical devices and mHealth devices that fit under the medical device term. I think this is generally a good thing for a number of reasons. Not the least of which is that the FDA doesn’t have the expertise needed to regulate EHR software. However, I wouldn’t mind a touch more patient safety concern from EHR vendors. Maybe the EHR Code of Conduct will help add a little more to this concern.
Of course, as Shahid points out, you don’t have to sacrifice agile software development to develop safety critical software. This is true in medical device development, EHR development, and even mHealth development.
Someone needs to regulate EHR software. There are so many implementations out there that seem quite frankly to have been written in haste by system designers that simply had no concept of what open doors they left everywhere in poorly designed software.
It is pathetic that not only are most EHR implementations written without regard to streamlining workflow, but are also written without it seems any security concerns.
Robert,
The problem is that you’re assuming that regulation of EHR software will somehow improve the workflow and the security of EHRs. The MU regulations have done the opposite for workflow at least.