Each module of an #EHR can, and should be an app of its own. Regulations favor big clunky systems vs small smooth ones. #EHRbacklash
— Bharat Bhardwaj (@bhardybhard) February 10, 2013
I love this approach. The challenge is that this likely has to be built from the ground up with this in mind. Is any EHR on that trajectory now?
Shoutout to Dr @salvolpe from @farzad_onc @onc_healthit for being #NYChealthIT early adopter when #EMR wasn’t norm & not reimbursed.
— Wen Dombrowski MD (@HealthcareWen) February 7, 2013
I applaud all the early adopters of EMR (yes, if you were an early adopter it was EMR and not EHR). I’d love to hear more from those who were adopting EMR early on. I started with EMR 8 years ago. So, I wasn’t really early in adoption, but I was one of the early EMR bloggers.
This nascent movement even has a name. #EHRbacklash. Let’s fix this. RT @techguy The Coming Physician EHR Revolt dlvr.it/2vTnJH
— Bob Brown (@ReasObBob) February 5, 2013
I think the concept of EHR Backlash is interesting. The link in the above tweet is to a post I did on EMR and HIPAA that’s been one of my most popular posts ever. I really think it’s a look into the future of the EMR environment. I think most doctors will appreciate that post.
this is partially due to the fact that EHR are architected poorly see blog below why and how http://qrs3e.com/architecture-of-healthcare-systems/
Re: “Each module of an #EHR can, and should be an app of its own”.
Half way there. We’ll need something to glue the modular apps into usable intramural and intermural workflows. The current best candidates are executable process models, such as found in workflow management systems, business process management suites, and, at a high level, dynamic/adaptive case management systems.
A couple years ago “clinical groupware” was a popular phrase. I think it should be resuscitated. Three years I ago I predicted (and still stand by):
“Future extensible clinical groupware will coordinate delivery of EHR functionality to teams of users by combining modular components with executable process models whose usability (effectiveness, efficiency, and user satisfaction) will be systematically improved using business process management techniques.”
From:
Usable Clinical Groupware Requires Modular Components and Business Process Management
http://chuckwebster.com/2010/02/ehr-workflow/usable-clinical-groupware-requires-modular-components-and-business-process-management
Chuck,
It’s true. I wonder why the clinical groupware term went out of style. I thought it was a good description as well.
I think a lot of EHR’s do this but it’s often mistaken for “nickel and diming” the customer. A lot of EHR’s offer a core package, and then a plethora of modules on top of that depending on the doctor’s needs.
Don’t do in-house X-Rays? Then you don’t need our Imaging/Radiology module.
You’re not an eye doctor, surgeon, or product-driven practice? Then you don’t need our Inventory module.
After all, why should all consumers be forced to pay for and subsidize features that they’ll never use?
But as soon as you expand your practice and have a need for a new module that you didn’t previously, you suddenly feel like you’re being nickel and dimed because you’re being asked to pay the additional fee that you would have paid in the first place if you needed said feature in the first place.
I suppose I’m probably just ranting at this point, and I have no doubt there are some unscrupulous vendors out there that are truly nickel and diming their customers but I think there’s also a case to be made for modular software, and I also think that modular software suffers unfairly from the above elaborated stigma.
Andrew,
That is a potential problem that’s exacerbated by the fact that many EHR vendors do use it to nickle and dime and mislead customers when it comes to pricing. Although, it’s not always the case if the pricing is structured properly.