Home » News » Currently Reading:

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

January 16, 2008 News 1 Comment

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.

View/Print Text Only View/Print Text Only

HIStalk Featured Sponsors


Currently there is "1 comment" on this Article:

  1. Dealing with SOA platforms in the clinical arena of data, I often feel that any federated view of legacy data called for a lack of better term, “post-transactional” is a process primarily for disclosure.

    Transmitting bi-directional clinical immunohematology data through an electronic conduit including group, type, compatibility findings, HLA typing and UNOS over the enterprise SOA platform should be verified and authenticated consistent with FDA 510(k) compliance. I believe that voluntary accreditation of clinical portals with national agencies such as URAC might serve as “deemed” status to that long auguous road to FDA dreamland – Area 510.

    A functional example of adequate FDA 510(k) compliance was addressed by SCC Soft Computer Genetic Information System Suite, the last of the best-of-breed clinical software companies in the United States.

Subscribe to Updates



Text Ads

Report News and Rumors

No title

Anonymous online form
Rumor line: 801.HIT.NEWS



Founding Sponsors


Platinum Sponsors





























































Gold Sponsors
















Reader Comments

  • SteveS: I’d like to hear more from Ed about his perspective on the current state of “Professional Organizations” – in te...
  • Brian Too: Nice to hear from a small hospital for a change. We hear lots from the large players and consolidation has meant that b...
  • Sam Lawrence: Except in this case, coding = medical billing, not development. Though the same warning may be true...
  • BeenThere: Partners will find the savings from their cuts of coders as fools gold. There are a lot of hidden costs running an outs...
  • JC: If there is not there can be. VistA has a reference lab interface that can create the manifests/labeling and such as we...
  • Tom Cornwell: Great stuff from Dr. Jayne as usual. One small typo, last sentence of second-to-last paragraph: should be 'who's' not 'w...
  • HIT Observer: What I find most interesting here, is people defending their common practices rather than truly taking this as invaluabl...
  • Bob: There's no incentive for the provider to spend time doing a price comparison for the patient. Nor is it a good use of th...
  • Peppermint Patty: Veteran - can you clarify what was "fake "? Was something made up (definition of fake) or did you disagree with Vapo...
  • Pat Wolfram: Such a refreshing article. Thanks -- there really can be a simpler version of an acute HIT implementation. But I do ...

Sponsor Quick Links