EHR design: A mold in need of breaking
Apparently I struck a nerve with last week's commentary on making the transition to electronic health records. The editorial generated quite a few comments, and every one of them were against EHRs. They're expensive, become a crutch for the lazy or less-trained, and deter from direct patient-physician communication.
There also was a recurring theme in the comments, which were thought-provoking and insightful: EHRs are designed poorly. Here are a few:
"EMRs are plagued by problems and inefficiencies that harm [patient] care and potentially, security and privacy--some day when they are perfected and work the way physicians work, we will flock to them. That time is not now! Data access can be more convenient, but data entry is terrible."
"I won't even discuss … the HORRIBLE reports and documentation that are generated creating pages of useless gobbly-gook to wade through, in the name of documenting for billing and coding purposes, that muddle the important points that are truly medically pertinent--and make gleaning important data or medical reasoning like finding a needle in a haystack!"
"EHRs sound like a good idea, but ... are still essentially an unfinished product. They cannot communicate with each other in any significant way."
"Someday- a useful EMR that does what is important to the physician and patient will be developed, but we are nowhere near that time now."
Kenneth Mandl, associate professor at Harvard Medical School and Boston Children's Hospital Informatics Program, and one of two authors of an article published this week in the New England Journal of Medicine, agrees. He points out that we're in an EHR "trap": vendors, he says, have perpetuated a falsehood that EHRs must use specialized IT software, and that the EHR must have all-in-one functionality.
The article points out that only some components of an EHR need to be specific to healthcare, and that others, such as documentation tools and cloud storage, can be generic and often are better than what is being offered. Mandl recommends that the industry should rely on a standard database format and standard apps, and use technologies that are common in other industries.
"It's a myth that using EHRs with other products would lead to problems with safety and security," Mandl tells FierceEMR in an exclusive interview. "There's no reason we can't integrate different software systems into EHRs. We can use different platforms and software; we do it every day. Our EHRs don't need specialized email. Most EHRs can't search a text string. Why can't EHRs integrate with Google or a similar search engine?"
Mandl acknowledges that some vendors will be resistant to design change, although a few are experimenting with innovation.
"Vendors need to take a close look at their product with consumers and look at functionality," he says. "You can leave some EHRs in place and work around them."
He also warns that what currently works for vendors today isn't likely to work in the future.
So what should providers do in the meantime?
Mandl says, for one thing, that providers need to think carefully about their needs and evaluate all options.
"Get together with a coalition and demand that products be allowed to integrate, get data in and out and exposed through different interfaces," he says. "If you already have a system, think of ways to integrate with emerging technologies. We'll see more technologies that work side by side or export data."
Sounds like we're at a crossroads. The providers have been vocal. Vendors, government--I know you're reading this: Perhaps you should take heed and consider making a turn. - Marla