Will late adopters differ from early adopters? NEJM article.

July 3, 2008 issue of NEJM:

Small minority adopt EMRs.

Some of the barriers cited:

Capital needed,

Uncertainity about return of investment,

Concern that system will become obsolete.

http://content.nejm.org/cgi/content/full/NEJMsa0802005

joseph:

Concern that system will become obsolete.

In my office, that is our primary concern.  The current situation is that hundreds of expensive EMR/EHR offerings exist, which are essentially incompatible with each other.  This is like buying a word procesor in 1984 for $50,000 - what if I buy Wordstar?

Bryan

I believe a low cost investment in the software and purchasing hardware is smart.  Buy a solution that actually works for you   The industry and consumer will eventually learn from its failures.

There is a interesting interview with Mark Anderson and Robert on how to distribute all the work of a EMR for Data Collection on essentially a part of the visit, the office note, that took a physician under 1 minute to dictate and never has been the primary issue with speed in a practice.  Expensive to the practice yes, but then again, fast and efficient.  How expensive is it to put in a system that does not prove much benefit and slows the whole practice down.

The primary failure point in this concept of distribution is employee turn over.  It is a fact of life, and getting someone trained on your EMR or already has used EMR XYZ is near imporssible.  So the cost for retraining and employee turnover, never incurred before, becomes a unexpected reality to the practice.  That check in girl quites because her boyfriend got a waiter job in the keys, and boom, you lost the person who starts the note, hands out the tablets, and manages the start of the note.  Loose that highly trained nurse, who tells you to shove it, and you might find yourself between a rock and a hard place.  Spending over a year to find someone able to work the EMR like the former employee.  IT department does a poor job managing space on the server, and you have a Database marked suspect and ran out of space, no problem, 3,000 dollars later in IT expense and you are back up and running.

Hybrid solutions taking advantage of technology to speed up the whole process will rule in the end. (IMHO).

B

Brendon:

I believe a low cost investment in the software and purchasing hardware is smart.  Buy a solution that actually works for you   The industry and consumer will eventually learn from its failures.

[...I agree completely with the middle part...]

Hybrid solutions taking advantage of technology to speed up the whole process will rule in the end. (IMHO).

B

I couldn't agree more.  Personally, I think that the underlying EMR should be standardized, and most likely open-sourced.  Thus, the back end of the EMR would be the same for all hospitals, clinics, etc.  The back-end would be managed by a central authority, taking in bug fixes, security updates, and new features as any open source project would. 

The front-end that the providers deal with could be made completely separate.  EHR companies would put their efforts into creating their own front end to the underlying EMR system.  Providers deal witht he front end anyway, and so the diversity of interfaces would remain, but the hundredfold efforts to remake the underlying database could be consolidated, saving time, money, and increasing compatibility among systems.  In a world where standards are now the norm, it beggars comprehension that such important information as a medical chart has no real standard.  This is as if my office kept paper charts in English, the hospital in German, and the cardiologist in Kannada, and so on.  Digitizing information is supposed to decrease the Balkanization of patient information, not aggravate it.

Providers are much more likely to adopt an electronic record if it would integrate seamlessly with the multiple hospitals, nursing homes, specialists, ancillary services (PT, OT, etc), and other clinics they deal with.  Why should  I spend so much time digitizing my patient data if that digital data can only be used by my clinic?  The value of an electronic record lost when the specialists' EHR does not communicate with mine, resulting in either a simple scanning of a letter (nearly useless) or my re-entering pertinent information (a huge waste of effort which could only lead to errors of information).

This hybrid of an open source, widely compatible backend combined with a diverse front-end is the direction I believe the industry needs to take.

Brendon:

I believe a low cost investment in the software and purchasing hardware is smart.  Buy a solution that actually works for you  

I agree.

The primary failure point in this concept of distribution is employee turn over.  It is a fact of life, and getting someone trained on your EMR or already has used EMR XYZ is near imporssible.  So the cost for retraining and employee turnover, never incurred before, becomes a unexpected reality to the practice.  That check in girl quites because her boyfriend got a waiter job in the keys, and boom, you lost the person who starts the note, hands out the tablets, and manages the start of the note.  Loose that highly trained nurse, who tells you to shove it, and you might find yourself between a rock and a hard place.  Spending over a year to find someone able to work the EMR like the former employee.  IT department does a poor job managing space on the server, and you have a Database marked suspect and ran out of space, no problem, 3,000 dollars later in IT expense and you are back up and running.

Interesting example that I hadn't thought about in full detail. Great Point !

How long does it take to train someone to write on paper  ?

Hybrid solutions taking advantage of technology to speed up the whole process will rule in the end. (IMHO).

Love the Paper Bridges.

The Training issue Brendon pointed out certainly points again to the benefits of less complicated, more intuitive EMRs.

So, the early adopter is the measly 5-7% of docs whom document visits entirely electronic ?

Reminds me of a canary in a coal mine.

martalli:

This hybrid of an open source, widely compatible backend combined with a diverse front-end is the direction I believe the industry needs to take.

I can see lots of problems with this approach.  If you need an enterprise database to run multi-hospital site systems, how is that going to run on a soloc doc's laptop when he goes visiting his patient in the nursing home?

And who is going to pay for this open source development?  Just not going to happen in our lifetimes.

What is also interesting from this survey is that the users with an EMR which they were using was only just larger than the group who had purchased an EMR but had not got round to implementing it!

Also, the users with the non-lite EMRs appear to have been largely funded by hospitals.

gchiu:

martalli:

This hybrid of an open source, widely compatible backend combined with a diverse front-end is the direction I believe the industry needs to take.

I can see lots of problems with this approach.  If you need an enterprise database to run multi-hospital site systems, how is that going to run on a soloc doc's laptop when he goes visiting his patient in the nursing home?

And who is going to pay for this open source development?  Just not going to happen in our lifetimes.

I see Linux being developed out of the OSDL with only a few employees, but development coming out of corporations like Red Hat, IBM, and Novell, who are profiting from the use of Linux.  In a similar fashion, this backend could be developed by a non-profit foundation or governmental body.  This would be a major project, but it is the only way to ensure that EMRs from different vendors could fully exchange information.  Clinics like ours have been very skeptical of moving to EMRs for the very reason that we are a small, independent rural clinic, with multiple referral centers.  All these centers use different EMR products, so we really cannot choose an EMR product that will properly share information between our specialists and our clinic.

My c2d laptop can run MySQL...I suspect any c2d laptop could run this backend for a clinic, although it could certainly run off the client-server model as long as internet access was available (cell phone broadband or local 802.11x as one of my local NH has).  Given that any wireless network is essentially at risk for compromise, I believe that client-server communications should be run through ssh-type connections to maintain security.

Bryan

While a laudable goal for exchange of information, there are many problems.

From a programmers standpoint, who will design the database schema?  A hospital? A vendor? A consortium?  How granular in clinical details?  Do we go to a federated patient ID system?  Who maintains the ID system? What are the boundaries for each datacenter?

From a patient's perspective, who owns and who has access to the data?

Better, at least until more issues are settled, are standards that allow exchange of information, particularly when that exchange allows "computability" so that specific information can be found.  The CCR started in that direction, but I fear it did not go far enough.  Interestingly, the greatest interest we see in the CCR is for the transfer of encounters but the CCR is not an encounter-based approach. A specialist cannot send back a CCR to a primary care doc to represent his consult, for example. 

Google's and Microsoft's initiatives excited us but on the development side, things have been slow in getting inforrmation from them.  Someone here at Medtuity actually used one of the services in an attempt to track a script filled at Walgreens and it was not terribly automated......not ready for the masses.

I totally agree with Matt on this one. The database schema is completely irrelevant and should be vendor's choice, as long as we can all communicate adequately. Actually, those envisioned monster databases that store everybody's records are quite scary as far as I'm concerned.

Maybe if CCHIT, or any other body, would concentrate on creating an agreed upon standard of interoperability, instead of nickeling and diming everybody on minute functionality, maybe then we could make some headway.

Most of the data elements stored in an EMR are already included in accepted standards of communication. Claims data cannot be transmitted to payers in anything but X12 837 and all varieties of vendors and databases found a way to do that because they had to - there's no other way to get payed. Same goes for lab orders and results - you have to use HL7 because all reference labs mandate it. There is still an issue with compendiums, but that should also be resolved when everybody adopts LOINC and I believe that one is imminent. Prescriptions and med histories have yet another standard (NCPDP) that any EMR that wants to do ePrescribing must adhere to, and they all do.

The 800 lb gorilla in the room is the encounter documentation, the same one that used to be dictated and it is now collected in a variety of forms from the good old dictation, to chunks of typed-in text, to discrete data elements, or a mixture of all of the above. A standard terminology is a must, but it is not in itself a complete solution. If every EMR and every physician documented only discrete data elements, a common terminology would be enough. However, that is not what physicians want to do and we as technology vendors need to come up with a solution to this dilemma. There is also no one compelling reason or organization to enforce a standard either. This is the last hurdle to interoperability. A rather large hurdle ....

Of course, we can keep exchanging full documents, or images, electronically and call that interoperability, but in that case, I personally do not see any added value to the paper\fax system.

Margalit

mchasemd:

While a laudable goal for exchange of information, there are many problems.

From a programmers standpoint, who will design the database schema?  A hospital? A vendor? A consortium?  How granular in clinical details?  Do we go to a federated patient ID system?  Who maintains the ID system? What are the boundaries for each datacenter?

An independent body like the OSDL, or governmental body.  Even a private corporation could manage an open source project - Novell, Red Hat, and MySQL all profit from open source projects.

mchasemd:

From a patient's perspective, who owns and who has access to the data?

I wouldn't doubt there is already a large amount of legal principals already developed to define who owns the medical record.  One benefit of a good EMR is that it can properly track who created a record and who accessed it.  Frankly, I am not sure how my suggestion is any different from any other large-scale EMR (like the VA, Mayo, etc).

mchasemd:

Better, at least until more issues are settled, are standards that allow exchange of information, particularly when that exchange allows "computability" so that specific information can be found.  ....

Until the standards are developed to properly share information between different providers, much of the true promise of electronic health records will go unrealized for primary care providers like myself. 

Bryan

Also curious as to why they excluded DOs from the survey.

Is there something about what DOs do that makes them different??