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 HIPAA for FREE!!

Health IT & EHR State Summaries

Posted on June 18, 2013 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

I’m always happy to look at data. Certainly data can lie, but it can also inform if you are looking at the right data and considering the biases of the data. I applaud ONC for being as transparent as possible with the EHR incentive program data. They have an entire Health IT Dashboard for analyzing the data. I think this is a great step towards accountability for how the EHR incentive money is being spent.

ONC recently announced a set of Health IT Quick Stats and even created a widget (embedded below) that lets you download a 3 page health IT and HITECH summary for your state. I think a few states are missing from the widget and why they grouped them by area I don’t know, but there’s some interesting data in the reports.

I downloaded my home state of Nevada to see how we’re doing with Health IT and HITECH. Here are a few thoughts I had when looking at EHR use in Nevada.

I was amazed that so many REC assisted providers were live with an EHR, but less than half of those had demonstrated meaningful use. We’ll see if that changes after this years attestations.

I do have to question some of the data since it shows the overall access to view lab results electronically as 0% for Nevada. Something is wrong with their data there. They did show office based EHR adoption in Nevada at 23% (39% nationally). I’m not sure how that national EHR adoption number meshes with the $60% I’ve heard thrown around. Different sources of data.

For hospital adoption of EHRs they show Nevada at 36% EHR adoption (35% nationally). It’s nice to see Nevada ahead of the national average in something.

I’ve always told people there were about 700,000 providers in America, so I was glad to see they listed 715,984 health care providers.

Lots more data in there, but those were a few of the things that stood out for me in the Nevada Health IT and EHR report. Take a look at your state and let us know what numbers stand out for your state in the comments.

What a Real Open EHR API Should Accomplish

Posted on June 17, 2013 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

There’s been a lot of talk in the EHR world about APIs and most of the time they talk about it as an open API. The problem is that there’s been a lot of talk about EHR APIs and not a lot of action. Having an open API is more than just giving a couple people access to some really small subset of your EHR. We need truly open EHR APIs that are more than just a nice press release.

A successful EHR API requires two core elements: Access to EHR Data and a User Base.

The first element is the obvious one and the one that everyone focuses on. An API needs to have access to the data in the EHR. This includes accessing that data for display in an outside application. Plus, it requires that an EHR accept data from an outside application. EHR APIs seem to fall short on both of these areas. Most only give you access to some really small portion of the EHR data. Even fewer let you write any sort of data to the EHR.

If you don’t give an outside application the ability to access the EHR data and write data to the EHR, there are very few applications you can build on top of it. Is it any wonder that the third party EHR developer community isn’t doing more things with EHR software? If they had these two things, EHR vendors would be amazed at what they’d build. I love Jonathan Bush’s idea of “every surface area” of athenahealth being available in an API. If he achieves this vision, third party developers will flock to that EHR and enhance it in ways that would have never been possible for athenahealth to do on their own.

The second piece is just as important to an API. EHR API developers need to get access to your existing EHR user base. This doesn’t mean you have to give them a list of all your clients. It does mean you need to feature the work of these third party developers to your existing user base. This can be in your application, in an email list, at your user conference, etc.

Think about the message you’re sending to your developer community and your existing user base when you do this. The developer community wants to build even more functionality into your product. Your EHR users get more value out of your EHR application thanks to the development efforts of an outside party. Plus, ambitious EHR users can even create their own functionality using the EHR API.

I can’t wait for the day that EHR vendors fully embrace the idea of a third party EHR API. There are so many outside companies that would benefit from an EHR API, but the EHR vendor will benefit just as much. Plus, the real winners will be the EHR users and patients who get the functionality they’ve been wanting from their EHR that the EHR vendor couldn’t deliver.

An Example of EHR as Database of Healthcare

Posted on December 13, 2012 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

One of my favorite interviews at mHealth Summit was with Alan Portela, CEO of AirStrip Technologies. I’d definitely heard good things about AirStrip, but I must admit that before our meeting I didn’t have a very good understanding of what AirStrip was really all about. I was pleased to learn that they are well deserving of the hype. I believe AirStrip will do wonderful things to help make healthcare data mobile and AirStrip is lucky to have Alan Portela leading the company. Alan is unique when it comes to healthcare IT leaders in that he understands the healthcare culture, but also has a unique vision for how healthcare can embrace the future.

The core of what AirStrip has done to date has been in OB and Cardiology. In fact, each of those areas is worthy of their own post and look into how they’ve changed the game in both of those areas. The OB side speaks to me since we recently had our fourth child. I can imagine how much better the workflow would have been had my wife’s OB had access to the fetal waveforms (CTGs) on her mobile device. Instead, it was left to the nurse to interpret the recordings and communicate them to the OB. There’s real power for an OB to have the data in the palm of their hand.

Similar concepts can be applied to cardiology. Timing is so huge when it comes to the heart and there’s little doubt that mobile access to healthcare data for a cardiologists can save a lot of time from when the data is collected to when the cardiologist interprets the results.

The real question is why did it take so long for someone like AirStrip to make this data mobile. The answer has many complexities, but it turns out that ensuring that the data displays to clinical grade quality is not as easy as one might think. An ECG waveform needs to be much more precise than a graph of steps taken.

While both of these areas are quite interesting, since I’m so embedded in the EHR world I was particularly interested in AirStrip’s move into making EHR data mobile. They’ve started with Meaningful Use Tracker, but based on my conversation with Alan Portela this is just the beginning. AirStrip wants to make your important clinical information mobile.

I pushed Alan on how he’ll be able to do this since so many EHR companies have created big barriers to being able to access their data. Turns out that Alan seems to share my view that EHR is the Database of Healthcare. This idea means that instead of the EHR doing everything for everyone, a whole ecosystem of companies are going to build amazingly advanced functionality on the back of the EHR data and functions.

In AirStrip’s case, they want to take EHR data and make it mobile. They don’t want to store the data. They don’t want to do the advanced clinical decision support. Instead, they want to leverage the EHR data and EHR functionality on a mobile device.

One key to this approach is that AirStrip wants to be able to do this for an organization regardless of which EHR you use on the backend. In fact, Alan argues that most hospital organizations are going to have multiple EHR systems under their purview. As hospitals continue to consolidate you can easily see how one organization is going to have a couple hospitals on Epic, a couple on Cerner, a couple on Meditech, etc. If AirStrip can be the consistent mobile front end for all of the major EHR companies, that’s a powerful value proposition for any hospital organization.

Of course, we’ll see if AirStrip gets that far. Right now they’re taking a smart approach to mobilizing specific clinical data elements. Although, don’t be surprised when they work to mobilize all of an organization’s healthcare data.

AirStrip is just one example of a company that’s using EHR as their database of healthcare data. I’m sure we’re going to see hundreds and thousands of companies who build powerful applications on the back of EHR data.

Blue Button Access to EHR Data

Posted on September 20, 2012 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.


What great news that we got this month about the Blue Button having 1 million users. That’s a big number for what really amounts to a rather simple idea. The idea being that when you click on a simple blue button you can download your patient record.

The article in the tweet above points out how the technology of the Blue Button is simple, but it’s had a much larger impact than the technology would suggest. Here’s portions of what Peter Levin, VA’s chief technology officer, said about the Blue Button:

“There was no nuclear physics here. It’s not that hard to strip out all of the things on the back end that make a bold font and a blue background and put raw health data out.” he said. “Once we got the directive from the Secretary of Veterans Affairs himself, from a technical perspective it was really simple to implement.”

Levin said the more important hurdle Blue Button wound up overcoming was ingrained cultural notion that one’s own medical information should only be available to medical professionals.

“It was a big step in terms of attitude,” he said. “Providers now understand that it’s OK to make that data available, and patients now understand it’s OK to get that data. Both parties now understand in that conversation that they should be talking.”

Within VA, Levin said, providers have mostly embraced the idea. But holdouts do exist.

“You’re going to find some providers in our enormous national system that haven’t gotten the memo yet,” he said. “They’re going to say, ‘Why would you want that data? All a patient’s going to do is go to the Internet and start asking questions that make them more anxious and use more of my time.’ Those folks exist. But they’re in the minority.”

The article also suggests that between the VA, DoD, CMS and private insurers, 100 million American have access to their Blue Button patient records.

I really like this video that I found on the Markle website about the Blue Button. Putting some names, faces and stories with something always makes it more real to me. You’ll have to visit their website to see the video since they’ve disabled embedding of the video (which is a shame).

The Blue Button has been a good initiative to help liberate healthcare data. I’m sure we’ll see more of it in the future. Although, we could still use some better tools to do something with the data we download.

What SaaS EHR Users Can Learn from the Megaupload Takedown

Posted on July 5, 2012 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

It’s time to talk about a subject near and dear to my readers hearts: SaaS EHR. In this article, we’re going to take a serious look at some of the risks associated with the pure SaaS EHR model. I’m sure this will leave many concerned about SaaS EHR software. Before I get into that, I want to be clear that I can (and probably will) make a future post about client server EHR software that will likely leave you just as concerned.

The point isn’t that SaaS EHR or client server EHR is better than the other. I take a much more “switzerland” approach to the topic. I think both approaches to EHR have their risks, challenges, benefits and advantages. To me it’s much more important that users are educated on the risks of each so that they can address them properly.

With that in mind, I was recently reading one of my favorite venture capital bloggers, Brad Feld, who posted a guest post by Dave Jilk about what SaaS software vendors can learn from the Megaupload and its impact on the future of Multi Tenant Services. For those not familiar with the Megaupload situation, the Feds basically took down Megaupload and seized everything they had in response to copyright infringement violations. Wired has an interesting article about the case.

What then can we learn from the Megaupload case that applies to SaaS EHR companies. I think Dave Jilk describes the SaaS risks better than I could:

What this particular case illustrates is that a company that provides your online service is a single point of failure. In other words, simply offering multiple data centers, or replicating data in multiple locations, does not mitigate all the risks, because there are risks that affect entire companies. I have never believed that “availability zones” or other such intra-provider approaches completely mitigate risk, and the infamous Amazon Web Services outage of Spring 2011 demonstrated that quite clearly (i.e., cascading effects crossed their availability zones). The Megaupload situation is an example of a non-technical company-wide effect. Other non-technical company-wide effects might be illiquidity, acquisition by one of your competitors, or changes in strategy that do not include the service you use.

So again, while this is a striking and unfortunate illustration, the risk it poses is not fundamentally new. You need to have an offsite backup of your data and a way to use that backup. The situation where the failure to do this is most prevalent is in multi-tenant, shared-everything SaaS, such as Salesforce.com and NetSuite. While these are honorable companies unlikely to be involved in federal data confiscations, they are still subject to all the other risks, including company-wide risks. With these services, off-site backups are awkward at best, and more importantly, there is no software available to which you could restore the backup and run it. In essence, you would have to engage in a data conversion project to move to a new provider, and this could take weeks or more. Can you afford to be without your CRM or ERP system for weeks? By the way, I think there are steps these companies could take to mitigate this risk for you, but they will only do it if they get enough pressure from customers. Alternatively, you could build (or an entrepreneurial company could provide) conversion routines that bring your data up and running in another provider or software system fairly quickly. This would have to be tested in advance.

As many of you know, I’ve been quite interested in this topic and risk for quite a while. I’m sympathetic to those doctors that want at least a copy of their data stored somewhere that they control. Yes, most SaaS EHR vendors have a good set of backup, disaster recovery and business continuity plans. However, as the above quote points out so well, that doesn’t deal with the “non-tecnical company-wide effects.”

I’ve long considered the idea of creating a set of standards that SaaS EHR vendors could adopt. Things like making a practice’s entire EHR data available in an easily downloadable XML format. That could be the starting point. I think it would also create a real competitive advantage to those EHR vendors that adopted these type of common sense, good customer service practices.

I’d even be happy to lead the EHR agnostic team that it would take to make this happen. Client Server EHR software vendors could be involved as well. Not to mention I’d be happy to provide a voice to the movement on my network of EMR websites. I think the key to success would be getting a couple EHR vendors to get on board with the idea and fully invested in seeing this happen. The challenge is that too many EHR vendors are blinded by the meaningful use lights.

Let’s just imagine for a minute that doctors that select an EHR didn’t have to worry about their data being safe. They knew that they could have their data available to them when they needed it where they needed it regardless of what happened to the vendor. I have that with my blog data. Although, instead of that making me wanting to change blogging platforms, it’s endeared me to WordPress even more.

I wonder if Todd Park could add this idea to his concept of EHR Data Liberacion.

Common EHR Implementation Issue – EMR Upgrade Problems

Posted on September 29, 2011 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

I’m really excited that this Common EHR implementation issues series has been so popular. If you missed it, you can see the previous posts in the series: Unexpected EHR Expenses, EHR Performance Issues, a little follow up to avoiding the EHR performance issues altogether, and inadequate EHR templates.

This weeks common EHR implementation issue is: EMR Upgrade Problems

I’d like to categorize this EHR implementation issue into two areas. One is upgrading to an EHR from an old legacy EHR and/or PMS. The second is upgrading your existing EHR that’s just outdated. I’ll take them in reverse order.

Upgrade of Existing Outdated EHR
In this world of your web browser and operating system auto updating at regular intervals it’s sometimes hard to remember that not all software does that. In fact, it turns out that most software doesn’t auto update (often for good reason). Of course, this problem doesn’t apply to a SaaS based EHR software since those updates are applied whether you like it or not. The nice part is that the SaaS EHR updates appear to the user to just happen automatically with little to no intervention on their part. Of course, we’ll save what happens when a SaaS EHR update causes you problems for another post. In the client server world of EHR (or hybrid EHR as some like to call themselves when they’re web based on an in house server) you will have to deal with updating your EHR.

I think with rare exception, it’s a huge mistake to not keep your EHR software up to date (goes for most other software as well). I’m not suggesting that even client server software should auto update. Considering the deployment and upgrade model of most EHR software, it’s almost essential to review the new feature list before doing an update to ensure that the update won’t cause you unnecessary heartache. Understanding the changes that will happen with the EHR Upgrade will let you warn your users about it so that they don’t come running into your office after the upgrade wondering why their favorite feature was changed.

What’s the problem with not upgrading? Many might just think that they don’t need to update their EHR software since they don’t want/need the extra features that are part of the upgrade. This is a bad strategy for a couple reasons. First, there are often security fixes that are part of the EHR upgrade that you’ll be missing out on if you don’t upgrade. Second, a bunch of relatively minor updates is much better on a clinic than one massive one that requires a ton of change. Third, when a future update comes that has a feature you do want, it’s not always pretty to go through multiple upgrades at the same time. Fourth, try calling the EHR support when you’re on an old version. Most of the time they’re going to say you need to upgrade for them to appropriately support you.

One other suggestion on EMR Upgrades now that I’ve supported the idea of upgrading. Just because I suggest you upgrade to the latest version of your EHR, doesn’t mean you have to be the beta tester for the company. Do the upgrade early in the process, but not necessarily so early that you’re going to be the bug tester for the company.

Upgrading an EHR from a Legacy EHR or PMS
This situation happens most often when either a clinic decides to switch from their old hasn’t been updated legacy PMS (which might include some basic EHR features) or when a clinic decides to move off their existing EHR to a new one.

Upgrading from a legacy PMS could easily be a whole series of blog posts. Suffice it to say that the biggest challenge with the upgrade from the old legacy PMS system is often getting the data out of it. Some legacy PMS systems don’t provide that data willing. In fact, many will even charge you to get access to it. They’ve basically lost you as a customers, so they’re trying to maximize whatever revenue they can get. It’s not pretty.

Even if you can get access to the data, there’s often a lot of data manipulation that will have to occur. A common problem that’s related to this is whether you even want to get the data out of the old PMS. Far too often, the data in the old legacy system has so much junk in it, that it’s worth considering the option of starting from scratch. It’s not pretty to upload inconsistent and ugly data from a legacy system into your nice, new EHR software.

Switching from one EHR software to another is becoming more and more common. In 2-3 years I believe we’re going to see an amazing influx of EHR software switches. It will be the topic du jour. We’re already starting to see it in a number of situations: an EHR that isn’t certified, an EHR that the doctor hates, an EHR that’s gone under, an EHR that’s sold to another company, etc.

The biggest problem right now with switching EHR software is that there’s no standard for the data to be exported and imported into a new EHR company. Some of you might remember my post asking EHR vendors to consider the value of EHR data liberation. In it I describe why not only is it the right ethical thing to do, but it also can make a lot of business sense to do so. Sadly, I’ve only really seen one EHR software that has embraced the concept of really liberating the data in their EHR.

I’d love to support a movement from EHR vendors that embrace the concept of EMR data liberation. I imagine most are too afraid of giving their users an easy option to leave their EHR. It’s too bad EHR vendors are so focused on protecting their business instead of focusing everything they do on the customer experience, but I digress.

Considering the above described state of EHR data export, you can see why moving to an EHR is such an issue. It’s worth mentioning this topic before you even select an EHR. Before purchasing the EHR, ask the question, What if this EHR is terrible and I want to switch? This is water under a bridge if you’re already in a compromising position under contract with an EHR you don’t like.

Unfortunately, I don’t really have very many great suggestions for those in this position. Just some words of comfort. First, switching EHR software can actually be easier than implementing an EHR in the first place. You already have the computers and IT infrastructure. Plus, for some reason second EHR implementations have a much higher success and satisfaction rate from what I’ve seen. Second, while it’s a bitter bullet to bite, everyone that I know that’s done it wishes they’d done it earlier. Although, don’t rush into another EHR just because. Take your time to select an EHR properly if you’re going to switch, but don’t be afraid to switch based on what economists call sunk costs. Third, this is one case where it’s often good to hire someone who’s done these type of EHR switching before. They can be a big help.

EHR Data Extraction and Clinical Conversion

Posted on July 5, 2011 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

I think it’s quite easy to predict that 3-5 years from now, one of the top topics on this blog and in the EHR world as a whole is going to be around EHR data extraction or if you prefer EMR data conversion. I’ve previously predicted that by the end of the EHR stimulus money we’re be lucky to achieve 50% EHR adoption. So, you’d think that in 3-5 years we’d still be talking about EHR selection and implementation. Certainly, that will still be a topic of discussion. Not to mention, which EHR vendor they should go to for their second EHR. However, I am certain that 3-5 years from now we’re going to see a mass of doctors switching EHR vendors.

As part of my EHR blog week challenge (if you’re a blogger, you should participate too), today I’m going to highlight one of the foremost EHR professional and technical services company’s blog, Galen Healthcare Solutions which focuses on EHR data conversion.

I know I’ve written about EMR data conversion a number of times before. Although, I haven’t written about it much for quite a while. I guess meaningful use and the EHR incentive money has kind of dominated the conversation. However, there’s much that can and should be said about EHR data conversion.

The first thing anyone should know about EHR data conversion is that it’s not easy. In fact, it’s quite frankly an incredibly painful experience in almost every regard. Just take a look at this blog post summary of the EHR Clinical data conversion process by Justin Campbell of Galen Healthcare Solutions. He summarizes the steps as follows:
* Data Extraction
* Data Analysis: Cross-Referencing
* Design: Data Filtering, Matching (Provider, Patient Item), and Exceptions/Errors
* Testing
* Go-Live

I believe the most challenging item on this list is likely the Data Extraction. Sure, the data analysis and design are a pain to do and do well. However, the data extraction is often the most difficult part of an EHR data conversion, because you’re often working with an unfriendly EHR vendor that has lost you as a customer. Unfortunately, many EHR vendors haven’t heeded my call for EHR data independence, and so it can be a miserable experience trying to get the information and access you need to do an EHR data conversion. In some cases the EHR vendors will try and hold that data hostage.

The key for those selecting an EHR software is to be sure that the process for exporting your data from the EHR is part of your EHR contract. If it’s not, then add it to your contract. If they won’t add it to your contract, there are 300+ EHR vendors to choose from. Certainly it’s a part of the EHR contract that you hope to never have to use. Don’t take that risk.

Justin Campbell has also posted a few different data conversion success stories on the Galen Healthcare Solutions blog. Obviously, Galen has a lot of experience with the Allscripts Professional EHR software and so you’ll note this bias throughout the blog. However, the experience of the conversion is very interesting.

Here’s a paragraph from one of their data conversion success stories: Azalea Orthopedics.

To facilitate this conversion, flat-file extracts were obtained from MedManager for dictionaries, demographics and appointments. However, instead of using these extracts to import into Allscripts PM, an alternative approach was taken in which real-time appointment and demographic interfaces were deployed from the client’s existing Allscripts Enterprise EHR to the new Allscripts PM environment. This offered the flexibility of having the PM data populate real-time. Interfaces were also required from Allscripts PM to Allscripts Enterprise EHR. Thus as part of the go-live, existing reg/sched interfaces from MedManager to Allscripts Enterprise EHR needed to be deployed.

I have to admit that this kind of complexity in healthcare is what drives so many doctors nuts. I’m sure there were some functional reasons that they had to do all these interfaces between the systems. What I don’t understand is why the interfaces need to stay in place after the conversion is complete (at least if I understand it correctly). Did Galen really have to implement an interface between Allscripts PM and Allscripts Enterprise EHR? I’m sure there’s some long history for why this has to happen, but it’s such a terrible design. Certainly this isn’t Galen’s fault, but Allscripts. Interfaces are really great….when they work. When they don’t work, they drive a clinic, the IT person and even the EHR vendor absolutely nuts. I’ll be interested to learn more from Galen about why they did what they did.

I did find their report on the number of transactions processed fascinating:
Demographics: 156,900 processed in 491 minutes (8.18 hours)
Appointments; 313,280 processed in 1570 minutes (26.17 hours)

That’s a lot of data being processed. Can you imagine having to run the 26 hour data conversion twice if you messed it up the first time? Yep, data conversion is a tricky thing and can be very time consuming if you’re not really thorough in the process.

Imagine how much data will be collected 5 years from now with all these EHR implementations happening. Plus, the above data was only appointments and demographics. It doesn’t even include the physicians charting and other clinical data.

Value to EMR Vendors of EMR Data Liberation

Posted on February 8, 2011 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

My last post on EMR companies holding practice data for ransom was very popular and had some very interesting discussion in the comments. Honestly, every EMR vendor should be considering the impact of the choice to not liberate the data in the EMR.

No, I’m not talking about being loose with the data. HIPAA will come back to bite you if you do that. Plus, no doctor will want to use your system. What I’m talking about is making the data in the EMR available to the doctor. In fact, if your a doctor or practice manager reading this post, you should make this a requirement of the EMR vendor you select. If you already have an EMR vendor, you should work to have them incorporate this feature in their EMR ASAP.

Lest you think that I’m just being pro doctor and not considering the EMR vendor, let me provide you some business reasons why an EMR vendor would want to create a plan to make the data in their EMR available to their doctor in a liberated format.

As one EMR vendor put it:

Bottom line, its a good business practice to provide the data in an accessible manner to the client when and if he/she wishes to move on to another EHR.

Let me add the following:

If you don’t hold the EMR data ransom then you will have a better image in the community.

1. If someone wants to leave and you make it hard, word will travel that you held them ransom and others will be afraid to choose you because they know they’ll be locked in. We all know how tight the medical community is.

2. If you free the data, users will trust you more cause they know they can leave at any time. Plus, they see you’re doing what’s best for the customer. This narrow minded focus on the customer’s needs will certainly carry over into other areas of your application and lead to happy customers who can leave, but won’t have any reason to leave.

3. SaaS EHR vendors in particular should offer this service. One of doctors biggest complaints about SaaS EHR is their fear that their EMR data isn’t stored in their office. What easier way to allay this fear than to provide them a regular copy of their data?

Do NOT underestimate the power of your image with the customer. It leads to happy long term customers, but also leads to future customers. I saw a recent study (which I can’t find right now), but it was amazing to see the amount of influence that other colleagues EMR recommendations made on a doctor’s EMR selection decision. Providing doctors their EMR data which may lose you a few customers along the way, but it will retain and find more customers than you lose.

EMR Companies Holding Practice Data for “Ransom”

Posted on January 19, 2011 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

UPDATE: JamesNT sent me an update to his comments in this post. It’s interesting to see the EHR vendors’ evolution on the question of openness.

JamesNT wrote a really interesting forum post recently about how a number of EMR vendors are holding doctor’s patient information “ransom” (his word) from them. Here’s his whole description and he even names a few EMR vendors and the challenges related to getting the EMR data out of their systems:

To many EMR’s lock up the practice’s data and hold it for ransom. The data entered into an EMR belongs to the practice, not the EMR. It is not fair for EMR’s to not provide ways to interface or export data from the database. If a doctor wants to hire an IT person or developer such as myself to write custom reports or export data from the EMR, then it should be possible. Consider the following examples:

Amazing Charts: They use SQL Server 2005 Express as their database but they remove the built-in Administrator account from the SQL instance and change the SQL Server SA password. This means anyone hoping to interface or export data is at a loss – and Amazing Charts will not share the SA password. Amazing Charts also does not publish a database diagram.

eClinicalWorks: Overly complicated database. Does not publish mySQL password (you can find it, though). Does not publish database schema. If you ask them for help, they want to charge $5000 to build an interface.

PODMED (now TrakNet): Kudos for sharing the SQL Server SA password – but does not offer a published database schema.

GE Centricity: Database schema available – if you are willing to tell a bold-faced lie to someone to get it.

Medinotes: Even after sunsetting the product, Allscripts refuses to give out the ODBC driver and database password.

MD Logic: Uses a pathetic HL7 file interface. You can place only one patient demographic in each file – so if you have 200 patients to update that means sending 200 files.

Officemate: Uses SQL Server and it is easy to get to their database – but they do not offer the schema.

I find this situation deplorable. Every EMR should make it easy to get to the data and not try to hide it or charge outrageous amounts for an interface. Seriously – who here would pay $5000 to make an interface?

Of course, he’s just highlighting the EMR software he’s used. I’m sure there are hundreds more EMR vendors like this.

Then, there’s also EMR vendors that don’t hold your EMR data for ransom like Medtuity. Here’s what Matt Chase from Medtuity said about what they provide to users of their EMR:

At Medtuity, we provide open access to the SQL database. We also provide an export facility under Options. You can export each and every encounter, years and years worth if you wish, to a PDF file for each visit, neatly labeled with the date of the encounter and pt’s name to keep it from colliding with other PDF documents. You can also export a CCR for each pt.

We also have our own proprietary format in XML. For a group with a huge number of records, they may wish to hire a consultant to write a program to consume that xml into a new system. Our xml format is most complete and includes the stuff you would not usually wish to transfer (the audit trail on that chart, for example). But it is there. We also have CSV format, but let’s face it, you cannot export sophisticated data in a CSV format. It’s fine for demographics.

How “liquid” is the data in your EMR software? This discussion is a very important one between you and your EMR vendor when you’re selecting an EMR. Make it part of your EMR contract.

More EMR vendors need to voluntarily step up to the plate and provide this type of EMR data liquidity.