I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).
I wrote this piece in December 2006.
Embrace FDA Oversight If You Want Clinical — not Clerical — Systems
By Mr. HIStalk
Most hospital information systems are old. Faded pictures of the original system architects feature bushy-haired guys wearing plaid pants, wide ties, and leisure suits. 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 just good enough to support those first two items.
Today’s so-called “clinical” systems mostly sit atop 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 being keypunchers.
Eventually, some company will actually design a new inpatient clinical 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: that no-man’s land between “information systems” and FDA-approved medical devices.
Clinicians gripe that systems are user-unfriendly, do little to help them perform their jobs, and add minimal value to personal productivity or patient outcomes. They’re just accounting systems whose widgets are clinical. 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.
Clinicians are overwhelmed by too much raw data whose presentation can’t be individualized, i.e. they insult bone marrow docs with low platelet warnings (if they have alerting capability at all, that is.) That picture that’s worth 1,000 words can’t be included because 1980s-era programmers didn’t see cheap multimedia and storage coming. Failure to rescue can’t be detected in crashing patients. Systems deliver data like an obedient mailroom clerk, adding equally unimpressive value. The average automobile, riding on even older design, has better data aggregation and presentation capabilities, replacing data lists with idiot lights, navigation capability, and easy-to-comprehend gauges.
It’s like Lucy working on that candy assembly line – reams of often irrelevant information are unceremoniously dumped faster and faster into the laps of physicians and nurses, who are expected to manually figure out what’s useful 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, which 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 to develop and cheap (both debatable) doesn’t seem like much of a bargain.
A smart clinical systems vendor would include 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 invade the IT space, and build systems that improve patient care, not just turn paper forms into on-screen forms.
Today’s software was designed around old constraints and its design shows it. Someone should get clinicians together (no programmers allowed) to design the systems of tomorrow, software whose effect on patient care is less interruptive and more assistive. Doing that right will require FDA approval. For that reason, the industry should welcome it.