Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

The Impact of Meaningful Use on EHR Development

I’ve been getting a really strong response to my post calling for EHR vendors to expand their definition of customer service. Although, the title doesn’t do the post justice since I also talk about the impact of meaningful use on EHR development. Many of the readers of EMR and HIPAA (and if you don’t read EMR and HIPAA you should go subscribe to the emails now) have highlighted some important points I wanted to share with a broader audience.

First, Peggy Salvatore provides this insight about the impact of billions of dollars of EHR incentive money:

Almost 15 years ago, I wrote material for Intel (the computer chip company) based on research they were doing on physician workflow to make EHRs more usable. It was one of the early efforts to tackle this issue. I mention this to say that a lot of spade work has been done in this field but (in my humble opinion) government regulation has gotten in the way of software businesses trying to build electronic patient record products that work for the end users. Experience has shown time and again that customers will drive product improvements, and the same is true in the healthcare industry as in all others. The government has wasted tens of billions of dollars requiring systems be installed to meet timelines that were not realistic given the budgets and time available, or, to this point, to install products that were not really ready for prime time. Let the customers – in this case – the providers and the patients – drive development and you will end up with products that solve problems, not create them.

Brenden Holt, CEO of Holt Systems, offers this startling commentary on the EHR industry:

To me it is more clear. EHR Vendors, large and small and all points in between are currently working on the support nightmare (R&D and Direct Support) of Meaningful Use. It is the same when CCHIT was coming out, and not much different then the 100′s, if not 1000′s, of current copy cat products, all in one way or another a copy of the master Logician (GE).

Innovation does not bring in customers in the current environment. Government Adherence and more importantly relationships (Marketing and Sales) accomplish this. That is to say products need to be improved upon, but only to the extent of meeting the Government Regulatory Demands and the demands of the Large Organizations that are buying these things in bulk.

Innovation is available, but more then likely will take some time, as will thinking of how we document patient care as a whole, which is antequated methodology.

So as a CEO of a software company, one in the sea of many, I will say, innovation will happen when the phones get off the hook form highly demanding end users who want to make sure the MU is met and a Government Final Ruling that will get Government out of Development. Government is a terrible manufacture of innovation. One other major issue is that the end users don’t really want to pay for the innovation, if the EHR is working they are happy with the LOB application. That in and off itself is a issue, new features don’t translate to higher fees, the opposite is the case, less features in a Free Package can be much more attractive as both meet the basic LOB requirements.

We are the US, as much as the rest of the world tries, inguinity is what makes us great, our leading export, but in this vertical it is all but dead.

Catherine Huddle offered this insight about MU not just derailing EHR development innovation, but also possibly making things worse:

As for MU, as an EHR vendor I would agree that it and related government programs such as PQRS and PCMH have significantly derailed most other product development. Not only was Stage 2 a development “hog” but it brought in required changes that are often unnatural in a practice’s workflow and overly complicated.

MU has changed the goal from delivering what providers need to finding the best way to deliver MU to make it easiest for the providers and other staff – while still trying to make other improvements to the EHR. Unless the government repeals MU and the Medicare penalties the winning EHRs will be the ones that make MU as easy as possible.

While there’s plenty to be pessimistic about what’s happened with EHR, I’m still optimistic that we’ve passed through the meaningful use waters and that the future will bring forth opportunity for EHR development innovation. I’m hopeful (although not 100% certain) that the people in Washington have seen the toll that meaningful use has paid on the industry and they’ll lighten the load so that EHR vendors can start listening to end users instead of regulators.

July 22, 2014 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 15 blogs containing almost 6000 articles with John having written over 3000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 14 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John launched two new companies: InfluentialNetworks.com and Physia.com, and is an advisor to docBeat. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and Google Plus. Healthcare Scene can be found on Google+ as well.

EHR Programmer Shadows Physician

I was recently browsing through blogs and came across this post on the Elation EMR blog about their practice of having developers shadow a physician as part of their hiring process. What an amazing idea! I loved this paragraph which says a lot about the health IT industry:

I was terrified. I’d worked in healthcare IT for years, but even when I worked at startups I’d been three or four steps removed from the patients and even the clinician users. Being at the point of care, watching someone’s grandfather discuss his current prescriptions with his longtime primary care provider was revolutionarily human to me—and incredibly intimidating. Add to that the pressure that I didn’t have the job yet; this was one of the final stages of my job interview.

I think if we did a survey of healthcare IT programmers, we’d be saddened to know how many of them have never been part of a clinical interaction. I bet a huge percentage of these programmers’ only point of reference for healthcare was when they went to the doctor themselves.

At TedMed I ran into a former Epic programmer who confirmed what I describe above. They were there to program something to spec. They weren’t there to understand the clinical context of what they were creating. There is something very different between a programmer involved in the design process and one just designing to spec.

Obviously, Elation EMR takes the opposite focus on their approach to EHR development. The above policy adds some depth to Elation EMR Founder Kyna Fong’s post asking “Is You EHR Clinically Valuable?“. I love when a company doesn’t just talk about something, but their actions reflect their values.

I bet many EHR vendors would be embarrassed to ask their staff if they have ever shadowed a physician. No doubt, the number would be very low.

August 16, 2013 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 15 blogs containing almost 6000 articles with John having written over 3000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 14 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John launched two new companies: InfluentialNetworks.com and Physia.com, and is an advisor to docBeat. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and Google Plus. Healthcare Scene can be found on Google+ as well.

Developing Safety Critical Healthcare Software

The Healthcare IT Guy, Shahid Shah, has a great post up on his blog about writing safety critical software using an agile, risk-based approach. Here’s a portion of the blog post where Shahid really hits the nail on the head:

Much of that [every software being custom] changed in the 90’s and then upended even further in the early part of the 21st century; we should no longer weighed down by the baggage of the past.These days even our hardware is agile and extensible, real-time operating systems are plentiful, software platforms are malleable, mHealth is well established, and programming languages are sophisticated so we need to be open to reconsidering our development approaches, especially risk-based agile.

Why should we use “risk-based” agile? Because not every single line of code in software can or should be treated equally – some parts of our medical device software can kill people, many parts merely annoy people, but most other parts simply aren’t worth the same attention as the safety-critical components. When you treat every line of code the same (as is often true in a plan-driven approach) and you have a finite amount of resources and time you end up with lower quality software and less reliable medical devices. It’s not fair to blame the FDA for our own bad practices.

I’m always amazed by Shahid’s knowledge and ability to describe something in simple terms. I should know since I’m often on calls with Shahid since he’s my partner in Influential Networks and Physia.

The irony is that in the EHR and mHealth world you could argue that many have taken too much of a lean approach to building their applications while the medical device world treats every part of the software as a patient safety issue. Now if we could just bring the two together into a more reasonable balance of what’s important from the safety side and what’s not.

As far as I can tell, the FDA is planning to mostly stay out of regulating the general mHealth and EHR side of healthcare IT and will stick to the medical devices and mHealth devices that fit under the medical device term. I think this is generally a good thing for a number of reasons. Not the least of which is that the FDA doesn’t have the expertise needed to regulate EHR software. However, I wouldn’t mind a touch more patient safety concern from EHR vendors. Maybe the EHR Code of Conduct will help add a little more to this concern.

Of course, as Shahid points out, you don’t have to sacrifice agile software development to develop safety critical software. This is true in medical device development, EHR development, and even mHealth development.

June 21, 2013 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 15 blogs containing almost 6000 articles with John having written over 3000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 14 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John launched two new companies: InfluentialNetworks.com and Physia.com, and is an advisor to docBeat. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and Google Plus. Healthcare Scene can be found on Google+ as well.

Physician Guidance for EHR Success

I want to take a look at the complaint I hear over and over and over again when it comes to EHR software. I’ve heard this comment said about every single EHR vendor out there. I’ve also heard it from doctors in every specialty and from every size organization. It comes in a few different forms, but all communicates the same idea. This is the doctor complaint I’m talking about:

Did the EHR vendor even talk to a practicing doctor when they developed this EHR?

Yes, the complaint is usually voiced as a question, but the question is lathered up with an unbelievable shock that an EHR vendor could misunderstand a doctor’s workflow needs so terribly. Plus, it’s reinforced with the belief that if the EHR vendor had somehow just talked to a doctor, any doctor, that this wouldn’t be the result.

Of course, the situation is much more complicated than that statement supposes. In fact, there’s a great thread on the HIMSS LinkedIn group that has a bunch of deep discussion on how to create a healthy partnership between providers and EHR companies.

One key to understanding this relationship is first that every single EHR company has consulted doctors (usually many many doctors) in the development of their EHR software.

Many doctors will then wonder how they could have an experience like the one I described above if the EHR vendor consulted a practicing doctor (and I assure you many many doctors have had the experience above). The answer to that question has multiple layers. The first layer that most practicing doctors see is that “most doctors that consult EHR companies aren’t really practicing doctors.” In many cases, this is definitely the case. Many Chief Medical Officers at EHR companies have made EHR their full time job and no longer practice medicine. Many physician founded EHR companies have a physician leading the company that no longer practices medicine. Certainly some portion of the EHR workflow disconnect could be related to non-practicing providers driving the EHR development process, but that’s just one layer.

The second layer is that in every case I’ve seen there’s always been practicing providers involved in the EHR development process as well. They are active in user groups. They sit in focus groups. EHR vendors go to the practicing physician’s office to learn from them first hand. Most EHR companies really do make a sincere effort to understand the practicing physicians and not just try and guess at what the practicing physicians want.

Another layer to this problem is translating what the practicing physician requests into the EHR workflow. Now imagine that two practicing physicians request the polar opposite feature (yes, this happens a lot too). How then do you translate that feature into something that’s going to satisfy both physicians. That’s not an easy thing to accomplish.

The next challenge to consider is that many physicians aren’t technically astute enough to know what they want. When this is the case, they don’t know what they should even be asking for. I’m sure many doctors will scoff at this idea, but it’s the same concept for programmers. Many programmers aren’t technically astute enough to understand the medical world well enough to develop what the doctor wants. It’s a two way street and is why it’s so important for EHR companies to create an amazing collaboration between the right doctors and the right programmers. That’s a special breed of person that is not easily found.

Of course, I haven’t even mentioned the specialty layer. A technically astute practicing physician in cardiology will likely do a terrible job designing an EHR workflow that works well for pediatrics, OB, and general medicine. If you thought it was hard creating an EHR workflow that works for all the doctors in one specialty, now try and do that across 40+ medical specialties.

If you remember back to the paper chart world (which many of you are still living in), how come we didn’t have a standard paper form that every doctor used to document the visit? In fact, it was pretty rare that any 2 non-affiliated clinics used the same form at all. Sure, some forms were exchanged at the medical societies, but in most cases each clinic wanted to modify the form to fit their own clinic’s needs and desires. This happens in the EMR world to some extent, but it takes more training and skill to modify an EHR workflow than the Word document you got from your colleague. Plus, many don’t want to invest the time to make those modifications.

I’m not trying to put the blame for this on anyone in particular. Plus, I don’t want to make this sound like an excuse for EHR vendors to be lazy in how they approach their EHR development. We can be sure that some of the issues I describe above aren’t because the doctors didn’t provide good requirements and not because the programmer didn’t know how to meet those requirements. Some of the problems we see have to do with a combination of rushed release times or lazy programming (which are related). When this is the case, EHR vendors should take it on the chin and deal with the issues rather than trying to blame someone else.

With that said, hopefully I’ve made clear that it’s not enough for an EHR vendor to just consult a practicing physician. If that was the case, then all 300+ EHR companies would have beautifully designed EHRs that physicians’ love. Instead, I think the fact that so many of the 300+ EHR vendors have this issue, it illustrates how hard it is to get a technically astute practicing physician that can get programmers to make a beautiful interface that applies across all specialties.

From now on, I hope to hear physicians who have this problem change their question to, “Did the EHR vendor even talk to a technically astute practicing doctor in my specialty that works the way I like to work and practices medicine the way I like to practice medicine and bills the way I bill and in the region I live when they developed this EHR?” Then, we’ll all be able to easily answer “No, it seems like not.

February 14, 2013 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 15 blogs containing almost 6000 articles with John having written over 3000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 14 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John launched two new companies: InfluentialNetworks.com and Physia.com, and is an advisor to docBeat. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and Google Plus. Healthcare Scene can be found on Google+ as well.

Meaningful Use Solidifies EHR as the Database of Healthcare

Earlier this month I wrote a post describing EHR as the Database of Healthcare. I believe this is a powerful and important thing to understand. It also led to some good conversation in the comments. As an entrepreneur I’m always interested to see the trends in the industry to hopefully better understand what is going to happen in the future. I think that this is one of those trends.

Just to make the case clearer, consider the effects of meaningful use on EHR software. Meaningful use stage 1 and EHR certification has already hijacked at least one EHR development cycle and you can be sure that meaningful use stage 2 and stage 3 will be hijacking another couple EHR development cycles. You heard me right. In order to meet the EHR certification and meaningful use requirements, most EHR vendors have to put a whole development team focused just on meeting those government requirements.

Meaningful use has codified EHRs into a box.

Instead of allowing EHR software to create innovative solutions it requires standards be met for storing and accessing info. Sure it also adds in security and tries to work towards interoperability, but those aren’t innovations that doctors want to see.

I expect many of the best healthcare innovators will build on top of the EHR base, not try and build the base again.

March 20, 2012 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 15 blogs containing almost 6000 articles with John having written over 3000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 14 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John launched two new companies: InfluentialNetworks.com and Physia.com, and is an advisor to docBeat. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and Google Plus. Healthcare Scene can be found on Google+ as well.

Build Or Buy, EMRs Cost A Bundle

Ever wonder whether it would be smart to drop your vendors and grow your own EMR/HIT apps?  Here’s some food for thought.

Today, I ran across a very detailed analysis of the labor costs involved in developing EMR and HIT applications, straight from the blog of the always perceptive Shahid Shah.

Shah, a longtime health IT consultant and former CTO for two EMR companies, just posted a list of the various professionals you’ll need to develop such applications — and the high prices these professionals command:

  • Clinicians and healthcare professionals (HCP) like docs, nurses, etc. – perhaps as consultants
  • Senior project manager – about $150k per year
  • User interaction engineer (UX, usability) – about $120k per year
  • Web design engineers (UI, HTML, JavaScript) – about $60k to $100k per year
  • Web developers (UI, PHP, JavaScript, HTML) – about $80k to $120k per year
  • Mobile app developers (iOS, Android, etc.) — about $90k per year
  • Database modeler and information architect (SQL) — about $150k per year
  • Database administrator (SQL) –  about $120k per year
  • API engineer (REST / SOAP) – about $120k per year
  • Service code engineers (Java, Ruby, etc.) – about $150k per year
  • Security analyst and privacy engineer (HIPAA, HITECH, Sarbox, etc.) — perhaps as consultants, $175k per year
  • Cloud infrastructure admins (Amazon, Eucalyptus) – about $90k per year
  • Network infrastructure admin / engineer (TCP/IP, etc.) – about $120k per year
  • Data integration engineers (ESB / ETL / connectors) – about $90k per year
  • HL7 and healthcare data integration conformance engineers – about $90k per year
  • Technical documentation specialist – about $60k per year
  • Quality assurance directors (test strategy, test planning) — about $120k per year
  • Quality assurance engineers (test planning, manual execution) – about $80k per year
  • Quality assurance automation (automated execution) engineers – about $90k per year
  • Trainers (folks with healthcare office experience plus tech knowhow) — about $60k per year

As Shah notes, this is what U.S. specialists typically cost.  (Working with Indian developers can save you about 35 percent, he estimates.)  Still, either way we’re talking about a bundle on compensation alone.

Despite the expense, there are probably some large institutions which will choose to develop EMRs or related applications internally.

After all, if you have a deep enough IT bench, developing even high-end applications might be cheaper than paying for high-end packaged products.  And of course, there’s always something to be said for apps developed exactly to your own specs.

Ideally, your institution could build its own EMR/HIT apps, then license them to other institutions or co-develop them with partners who can sell them elsewhere. (For an example of how this might work, check out the $400 million partnership deal the University of Pittsburgh Medical Center did with IBM a few years ago.)

Still, Shah’s analysis is more than a little sobering, isn’t it?

March 7, 2011 I Written By

Katherine Rourke is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.