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!

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 5000 articles with John having written over 2000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 9.3 million times. John also recently 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.

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 5000 articles with John having written over 2000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 9.3 million times. John also recently 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.

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 5000 articles with John having written over 2000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 9.3 million times. John also recently 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.

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 5000 articles with John having written over 2000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 9.3 million times. John also recently 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.

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.