One of my all time favorite posts I’ve done was called “Develop Your Own EMR….Are you Crazy?” Hard to believe that was back in May of 2006. I should go back and check out the content of that post, but the title still rings very true to me. Of course, every entrepreneur that I know is a little bit crazy, so it should come as no surprised that I’m hearing all the time about new EMR software getting ready to hit the market.

Today’s encounter has to be one of the most unique. I was going to church in another state (visiting family for the Holidays) and I ran into one of my high school friends at church. We caught up and I learned that he’s the owner of a software development company. Then, as he learned what I was doing he just mentioned off hand that they were developing an EMR.

After I picked myself up off the floor, the meeting at church started so I didn’t really get a chance to talk to him. Since he’s my friend on Facebook (you know, a real friend that I know in real life type of Facebook friend), I sent him a message and hopefully we can connect. I’m really intrigued that his software development house is doing an EMR for someone. Obviously, now I have a ton of questions for him about the project. He did say before the meeting started that “it’s a BIG project.”

Of course, the message here is that there are a lot of people out there that are crazy (no offense intended) enough to start building another EMR. The problem is that there are so many doctors that are dissatisfied with the EMR software that’s out there, I’m sure until that’s resolved we’ll see more and more EMR software entrants. Oh, if only these brave souls knew what they were getting themselves into. I guess maybe that’s the beauty and key to entrepreneurship and why I love it so much.

David Swink wrote an interesting comment on my previous post in which he lists a number of reasons why he thinks the EMR effort is proceeding so slowly. Since many of you don’t read all the comments on this site (I’ll forgive you this time), I thought I’d highlight his comments here to see what people think of his comments and what more they might add to the list.

Thought on why the EMR effort is proceeding so slowly:

1) EMR is much more complex than a simple inventory control system. The “human resources” apps probably come closest to the mark, but there are hundreds of separate HR apps out there, but they don’t have to talk to other HR apps.

2) Government is not good at organizing complex efforts. The government-sponsored HDTV effort took some 30 years to implement, and the results were largely irrelevant in that we’d moved beyond the concept of “broadcast”.

3) The medical community has no “IEEE” standards group to represent their interests and get various vendors to pull together towards a well-defined goal. The AMA could maybe assume this role, except that it is mostly a political organization, with only 17 percent participation by physicians.

4) Large medical groups are not likely to encourage mutual cooperation in EMR development. To them, small physician groups are competition. (Likewise, Sarbanes-Oxley works to the benefit of large corporations who can afford the accounting red tape, to the detriment of Mom-n-Pop organization, where red tape is a meaningful expense.)

I think David missed a number of other important reasons. Like the 300+ EMR and EHR vendors for a start. What else do you think is slowing the EMR effort? And more importantly, what can be done to overcome these challenges?

I came across a little bit older article from the Health Care Blog that asks the question, “What if I Had to do HIT All Over Again?”

I must admit that I was pretty struck by the thought of what could be done with an EMR that was built from scratch. Don’t get me wrong, I still think you’re crazy to develop your own EMR. However, I couldn’t help but wonder what might be done differently today knowing what we know about EMR now and the technology advances that have been made.

My mind then drifted off to think about what it would be like to build an EMR without any special interests. For example, you were building an EMR that focused on improving patient care. You were building an EMR that focused on improving doctor productivity. You were building an EMR that made everyone’s lives easier.

Contrast this with an EMR vendor who develops their software in order to sell more product. There’s a wide gap between the two methodologies. Unfortunately, I’ve heard too many stories of EMR vendors focused on building their EMR software to sell more of it. In the short term, this might be a great business strategy. Long term it will catch up with them.

How does someone selecting an EMR vendor identify this in the company?

One of the huge challenges that an EMR software vendor has is the long lists of enhancement requests that they receive from end users. Managing these requests has got to be one of the most challenging jobs of any EMR vendor’s development and support teams.

An EMR vendor has so many often conflicting motivations related to which enhancement requests they add to their product. I won’t go into all the details of their job here, but let’s just say they’re walking a very small tight rope. On one side, they want to be able to create enhancements that will sale more product. On another they want to keep their current users satisfied. On the other, they don’t want to make their product to specific to one area, region, specialty (unless it’s specialty specific), insurance plan, provider type, etc etc etc. Another side wants to be able to keep innovating the product in ways that weren’t suggested by the end users. Then of course each EMR vendor wants to keep some of their enhancement plans private as part of their “competitive advantage.”

Honestly, none of this is new to software or EMR. We’ve been dealing with this for a long time. However, I don’t know of any EMR company that really manages this process well. That said, I’d love to hear about other EMR vendors approaches to collecting, managing and implementing software enhancement requests.

Here are just a few of the components that I think a good EMR software enhancement request system should have:

• Simple, but complete method for requesting ehancements
• Translation of the enhancement request into actionable enhancement (this is also important for helping to filter out repeats and other such noise)
• Feedback to the end user of what was done with their request
• System for users of the EMR to see all the enhancement requests
• Method for users to be able to support enhancement requests that are already made (this helps an EMR vendor prioritize the requests)
• Method for users to provide comments on already created enhancement requests (ie. refine and improve the existing requests)
• Internal enhancement plans are part of the system
• Completed enhancement requests are noted for those interested in following the progress

As I was listing these things I think that my view of enhancement request is partially clouded by open source projects (maybe there’s an open source EMR that does the above well?). However, I think that a number of open source projects do a really good job of managing enhancement requests. The non open source software world can learn a lot from open source software in this area.

I think one of the key things I’d love to see an EMR vendor do well is involving the “crowds” of EMR users (coined “crowdsourcing”) in the prioritizing and planning of future enhancements. Users of an EMR have a wealth of knowledge related to the product and I’ve yet to see an EMR vendor tap that knowledge really well.

I think doing the above would solve a common phrase I’ve heard after doing an EMR software update: “Why did they add that feature?” followed by the question “Why don’t they add this?”

I’ve had a huge interest in the open source EMR and Free EMR movement.  Turns out my readers are just as interested in a Free EMR as I am.  However, we probably have different reasoning.  I think the power of open source is in having a crowd of people that are all contributing and sharing in the software development.

The problem I’ve had with most open source EMR projects is that I haven’t seen any that have had a large and committed enough community to really sustain development.  Granted, it’s been a few months/years since I’ve really looked into most of the open source EMR packages, so please correct me if there are some open source EMR communities that I should consider looking at again, but I digress.  My point is that without a strong developer community, open source is not a very good alternative.

I recently came across elementalClinic which I believe is using the open source EMR development model correctly.  I’ve never used the elementalClinic EMR so I can’t comment on its featureset (although it looks like it’s a mental health EMR), but what I do find interesting is how their funding development of their open source EMR.

In a recent comment on EMR and HIPAA, Alex said that elementalClinic has 150 paying customers that are using the software with somewhere around 500 people downloading the software.  This seems like the perfect model for developing an Open Source EMR.  150 paying customers that provide a solid foundation development team for the open source project.  Now, I think that 500 is a rather small number of downloads, but is a good start to creating a vibrant community of open source developers that will build on top of the foundation 150 paying customers.

Many would wonder why the 150 paying customers would fund everyone else downloading it for free.  There are a number of different reasons as far as premium support, custom features, etc that they might be paying to receive.  However, the best reasons is because by leaving it open source they can utlize the development and feedback from those using the free, open source download of the EMR.

Plus, having the license be open source means that any one of those 150 paying customers could decide to take the code from their current EMR install and take it in another direction.  In open source they call it a fork in the development.  How easy would it be to create a foundation EMR with a fork for every specialty: pediatrics, oncology, urology, etc.  Would be pretty neat and a great reason to do open source.