Clinical vs. Clerical Systems – Why FDA Software Regulation is Inevitable

Inside Healthcare Computing has graciously agreed to make previous Mr. HIStalk editorials available from its newsletter as a weekly "Best Of" series for HIStalk. This editorial originally appeared in the newsletter in December 2006. Inside Healthcare Computing subscribers receive a new editorial every week in their Electronic Update.

Most hospital information systems are old. Faded pictures of the original system architects feature bushy-haired guys wearing plaid pants, wide ties, and CPO jackets. Given their unfortunate fashion sense, it’s not surprising that their precognition of today’s healthcare environment didn’t include having physicians and other clinicians use their creations directly. The goals of information technology were simple: capture charges, batch-bill the heck out of Medicare and Medicaid, and maybe provide a simple order entry function.

Today’s so-called “clinical” systems mostly sit on that antique and unsuitable foundation, outdated not because of old programming languages and hardware platforms, but because their original design mindset is now hopelessly obsolete. Clinical applications are really just green-screen type data entry forms that happen to accept clinical information. It’s the mainframe mentality at its worst – the all-knowing system that requires regular data feedings from subservient users who, despite their occupational disposition, are relegated to data entry clerks.

Eventually, some company will actually design a new system from the ground up. We can fervently hope that when they do, they’ll start with a blank slate and not simply port outdated, monolithic thinking to a newer technology platform. With that innovation, though, will come the crossing of a huge chasm: the no-man’s land between “information systems” and FDA-approved systems.

Clinicians gripe that clinical systems are user unfriendly, do little to help them perform their jobs, and add little value to personal productivity or patient outcomes. They’re just accounting systems dealing with clinical widgets. One reason: HIT vendors are terrified of FDA regulation. It’s easier to make sure systems are too dumb to require it than risk exposing sometimes bad software practices to government oversight. No wonder our clinical systems are substandard.

Clinicians are overwhelmed by too much raw data whose presentation can’t be individualized, i.e. don’t insult bone marrow docs with low platelet warnings. That picture that’s worth 1,000 words can’t be included because 1980s-era programmers didn’t see cheap multimedia and storage coming. Systems deliver data like an obedient mailroom clerk, with equally unimpressive value added.

It’s like Lucy working on that candy assembly line – reams of often irrelevant information is unceremoniously dumped in the laps of physicians and nurses, who are expected to manually figure out what’s relevant and then “process” it, often by entering even more on-screen information. Eventually, the administrivia buries someone who ought to be making patient care decisions instead of romancing a keyboard.

IT vendors have good reason to fear the FDA, who won’t be happy to hear about buggy code, poor testing practices, slow updates for known defects that have clinical implications, and head-scratching user interfaces that merited no more than an afterthought. Maybe that level of scrutiny would slow development and increase costs, but accepting possibly dangerous software as long as it’s fast and cheap (both debatable) doesn’t seem like much of a bargain.

A smart clinical systems vendor would build FDA approval into their long-term plans and build killer applications around it, thereby scooping their competition by years. Redesign the first-generation systems, step boldly into the FDA-regulated space before the device vendors instead step over into the IT space, and build systems that improve patient care, not just caregiver data processing skills.

Today’s software was designed around old constraints and its design shows it. Clinicians should get together with no programmers in the room and design the systems of tomorrow. Clinical systems need to interrupt the care process less and enhance it more. Doing that right will require FDA approval.

This editorial is copyright-protected by Algonquin Professional Publishing, LLC., publishers of Inside Healthcare Computing. Please do not copy, forward, or reproduce this material without prior permission.  To obtain permission or for more information about Inside Healthcare Computing’s reprint policy, please contact the Customer Service Department at 877-690-1871 or go to http://insidehealth.com/ihcwebsite/reprints.html.

Mr. HIStalk’s editorials appear each Thursday morning in the subscribers-only version of Inside Healthcare Computing’s E-News Update.  To subscribe, please go to:  https://insidehealth.com/ihcwebsite/subscribe.html or call 877-690-1871.