This recent Frost and Sullivan study (requires registration to access) has been making the healthcare IT and EMR blog rounds lately. The parts of the study that are most interesting to consider is their estimated EHR market size.

A study by Frost & Sullivan predicts that revenue for the U.S. ambulatory electronic health record (EHR) market will double from $1.3 billion in 2009 to an estimated $2.6 billion in 2012. Further, by 2013, the market will reach its peak, posting revenue of $3 billion. However, by 2016 market saturation will have occurred and revenue is expected to fall to $1.4 billion.

That’s right. They estimate in 2013 the ambulatory EHR market will be $3 billion. Now compare that number with the $36 billion of EHR stimulus money that’s available (or whichever ARRA EMR stimulus projection you prefer). Are hospitals really going to take that much of the EHR stimulus money? Something just doesn’t feel right about these numbers.

Other salient points from the study I wrote about in my posts about Complex Reimbursement as the Real Driver in EHR Adoption and the reshuffling of providers favoring Large EHR vendors.

Today I came across some really crazy news that one of the senators that helped write the healthcare reform bill hadn’t ever even read the entire bill. Here’s a section of the article:

During the debate over what later became the health care bill that was recently signed into law by President Obama, a number of federal representatives and senators both admitted that they had not read it. Some, including Rep. John Conyers (D-Mich.) even boasted of this fact. House Speaker Nancy Pelosi (D-Calif.) famously stated that “we have to pass the bill so that you can find out what is in it.”

Presumably the actual people who wrote the bill might have at least some idea what was in it. Unfortunately that isn’t the case with Max Baucus (D-Mont.), lead sponsor of the Senate bill that became law. He admitted as much Monday during a constituents meeting in the small Montana town of Libby, as reported by the Flathead Beacon, a local newspaper.

According to Baucus, the idea of him reading a bill allocating nearly $1 trillion of federal funds is “a waste of time:”

There’s just something that feels really wrong about the idea that even the senator that helped write the bill hasn’t read it all. Although, it’s not really all that surprising.

I’ve thought that the same thing happened with the HITECH Act. No doubt it was thrown together by a few people and the majority of senators had no clue what it really included or meant.

Can’t you imagine it? They kind of throw together this EHR certification term tey’ve heard. Yeah, certification sounds good. Also, let’s make them accountable by making sure they’re using the EMR. Ok, the rest of the details are up to you.

I’m sure that no senators or even junior staff actually thought much about the impact of requiring a certified EHR and how they might measure a doctor’s use of an EHR.

Of course, why should they “waste their time” on a mere $20-30 billion. They can’t waste their time on a trillion dollar ill, so why would they waste it on a so much smaller amount?

My previous post about imagining an EMR that didn’t include billing certainly has driven a lot of conversation. Actually, that was the purpose of the post. I indulge in great conversation with multiple perspectives. It’s the beauty of blogging and of life.

However, please don’t let that post confuse you. Billing is an absolute essential part of an EMR software. There’s a very good reason why most EMR software out there amounts to little more than a big billing machine. The demand for healthcare software was initially to solve the challenges associated with medical billing. Markets are great at satisfying demands and that’s why the EMR software is the way it is today.

This means that EMR vendors CANNOT ignore billing. Rightfully so, doctors want to get paid for their work.

Of course, the point of the previous post was to try and expand the conversation beyond billing. Basically, the goal was to try and imagine an EMR software world where patient care was the focus instead of billing. What kind of good could we accomplish if this was our goal?

This follow up post was prompted by this somewhat disturbing email I received:
“I have built just such an EMR product for the iPhone and iPad. I am struggling with financing it because everybody wants billing. They really don’t care about the quality of the EMR.”

I’d make one qualification. No one cares about the quality of the EMR, if you don’t satisfy their billing needs too. Reminds me of HIPAA. No one would purchase an EMR that didn’t meet the HIPAA standards. However, once they hear it meets those standards, they move on to other things like the quality of the EMR.

Long time readers will know that I’m not a fan of EMR certification. It seems quite pointless since it provides no assurance to the doctor of anything of value. EMR Certification doesn’t ensure a higher implementation success rate. EMR Certification doesn’t improve patient care. EMR Certification doesn’t improve doctor’s bottom line.

With that said, we’re still stuck with the term “certified EHR” in the HITECH Act EMR stimulus money legislation. So, EMR certification is going to be around for the foreseeable future.

CEO Mike from Medscribbler EMR posted an interesting look at the cost of CCHIT EMR Certification and the impact that it could have on EMR vendor selection and long term viability of EMR vendors. I’ve included his comments below:

Note: See my post about whether you have to use a CCHIT Certified EMR vendor before reading Mike’s comments.

Using the CMS’s own data and report a CCHIT EMR will spend between $125,000 to $350,000 in programming costs to be certified (add at least $20,000 for actual certification) An existing EMR not CCHIT certified they predict will spend $175,000 to $700,000 to meet the standards (plus the $20,000.)

Certification has to be done for each year, for three, so a 2011 certification does not guarantee MU certification for 2012.

Self certifying for Open Source are not exempt from requirements so it stands to reason they will have the same expense.

What does this mean:

1. Forget collecting MU with Open Source software.

2. If you are using no CCHIT software it is unlikely the software will be qualified by the vendor.

3. Even fewer EMR vendors will certify than those that did so for CCHIT.

4. Innovation is dead if MU certification becomes generally why an EMR is purchased as this will also set the preception of useability. Vendor design resourcess will go to MU not useability.

5. If MU EMRs fail to get widespread purchase, those EMRs who certify are dead (including some current larger market share ones, as they will undoubtably spend a ton on marketing to maintain their share.) The MU EMRs will also then presummably be left behind by the innovators for useability.

6. Certifying bodies, especially CCHIT may be in trouble because there will be fewer takers, or they will charge a lot more pushing EMR prices up.

7. Regardless everyone is going to pay a lot more for an EMR making the MU payment mote.

Medscribbler could be certified, we are still evaluating this, because there are a lot of CCHIT EMRs now dead in the water – certification is no guarantee of success – we believe useability is – and how do we balance useablity which will guarantee success with certification which may or may not?

Miguel sent me the following email about local server EHR and Web Based (SaaS) EHR:

A lot of vendors in Puerto Rico are selling their local server application over the web application. In fact, to my view, they have very weak arguments when selling Local Server vs Web based application.

Can you direct me where to get additional information regarding the comparison of the two? Do you have an estimate, from the 100% physicians that are using EMR in US, what is the proportion of physicians using local server? What would you recommend?

This is a tricky question and the question that really divides many EMR vendors into their various camps. The tricky part is that both camps are right in their assertions. So, there is no clear winner. From my perspective you can make the case for either solution.

However, in certain situations one type of EMR might win over another. For example, if you’re in a place where your internet connectivity is not reliable, then you probably should go with an in house EMR instead of a web based EMR. Many doctors who don’t have formal IT support avoid an in house server and go with a web based hosted EMR to avoid the lack of IT support of the in house server.

I’ve written quite a few times about SaaS EMR and so a scroll through my previous posts will provide insight on a number of other topics including this post discussing the SaaS vs Client Server EHR. I should take the info and add it to this EMR and EHR wiki page. Maybe someone else can help with that too.

I don’t think anyone has an idea of the percentage of user who use a local server vs a web based EMR. I did do this EMR poll back in June, 2009 that showed a split decision between SaaS EMR and the 2 different style of client server EMR.

Finally, here’s the section from my EMR selection e-Book (which everyone should buy) that talks about the SaaS (web based) EMR vs. the Client Server (local server) EMR:

SaaS (hosted/web based) EMR versus Client Server (in house) EMR

This is one of the most heated questions you can ask EMR vendors when considering an EMR.  For an EMR vendor, choosing one or the other becomes like a religion.  My personal belief is that either model is reasonable.  Certainly the SaaS EMR people are correct that web based systems are the major trend in technology and that EVERYTHING is going web based.  However, it is also true that there are some things you can do with a client server EMR that still aren’t as effective with a web based system (ie. complex document workflow).  Some EMR vendors are combining the two models by having an in house server that is web based.  Others are putting their client server EMR in a data center also so they get the advantages of a SaaS EMR while still having some of the client server benefits.  For those that do not know the differences in SaaS versus client server, here’s a high level summary of the advantages and challenges of each model.

SaaS (hosted/web based) EMR

A SaaS EMR is one that is hosted by the EMR company (or partner of the EMR company).  Access to the EMR is done through a standard web browser. (Note: Client Server EMR can be hosted by the company and accessed using terminal server software as well, but that isn’t usually considered a SaaS EMR for purposes of this description.)  The biggest advantage to a SaaS EMR is a clinic doesn’t have to pay for the server and associated IT help to support a server in the office (ie. server room, tech support, redundant network, UPS, backups, etc).  SaaS EMR vendors reasonably argue that most clinics in house IT support cannot provide reliable and redundant server support the way a SaaS EMR can provide.  Part of this is due to the lack of expertise of in house IT support (or lack of in house IT support altogether) and the other part is due to lack of funds to build a reliable and redundant server environment.  Another advantage of SaaS EMR is that since they are web based they are available anywhere you have an internet connection.  When a SaaS EMR updates its software, you will automatically get the latest and greatest features of the software.  This can be a good and a bad thing depending on whether the latest updates were well tested and if they included features that would help your office.  Since a SaaS EMR uses a standard internet web browser, you will not need to spend time installing special software on each computer in your office.  This is even more beneficial when your SaaS EMR does an upgrade to the software.

The major disadvantages of a SaaS EMR are: internet connection dependence, EMR data not stored on site, and reliance on your EMR vendor.  Access to a SaaS EMR is completely dependent on a clinic’s internet connection.  Since the SaaS EMR is stored offsite in the vendor’s data center, any loss of internet connectivity means the clinic is without an EMR.  The solution to this is to have redundant internet connections (where possible), but also often means an increased cost for your internet connection.  Cellular broadband cards have helped to lower the cost of clinics having a redundant internet connection in many places.  Many rural locations with poor internet connectivity should probably avoid using a SaaS EMR.  Many clinics are also leery of SaaS EMR because the patient data in their EMR is stored in the vendor’s data center instead of on site.  Some SaaS EMR vendors will provide a backup copy of your data which you can store locally, but this is not very common and cannot usually be done at regular intervals.  SaaS EMR vendors argue that there’s no need to store a copy of your data locally since the server where your data is stored uses enterprise level backup to avoid any loss of data.  Ensuring these backups are completed appropriately and your SaaS EMR server is always available means you as a clinic are relying on your EMR vendor’s expertise in setting up those processes and configurations.

Client Server (in house) EMR

As would be expected, the advantages and disadvantages of an in house EMR mirror those of a SaaS EMR.  In house EMR software is traditionally done through a client install on a computer which accesses a server stored in the clinic.  Since the server is stored on site, you are no longer dependent on your outside internet connection.  Access to the EMR is done through your more reliable local network.  This also means that all the data from your EMR is stored in your office.  Many people would argue that client server EMR software is faster and can do more than web based software.  Web based software is making major strides in this regard, but there are still some features of an EMR that are better implemented by a client server EMR.

The biggest challenge associated with an in house client server EMR is that it requires a certain amount of local IT expertise to support your local server.  Many EMR vendors will assist your local IT support, but they still usually require some local IT support.  The quality of your local IT support matters regardless of which EMR you choose, but is more important with a client server EMR.

Another challenge with an in house EMR is that you are the one required to make the backups.  Some people consider this a pro since then you can be sure that the backups are done regularly and properly.  However, most people would argue that this is a problem with an in house server.  The reason for this is that too often making sure the backups are done and done correctly is forgotten or not done at all.  This is very common since backups aren’t appreciated until some major disaster happens and it’s too late.  Some local IT companies will partner with you in this effort and this can help solve this problem.

One of the most irritating parts of a client server EMR is the need to install the client software on each computer.  Certainly this is less of an issue the smaller your clinic, but it still can be a pain to manage.  Remember that this is not just a onetime event.  When your EMR software gets upgraded (usually 2-3 times a year), you will need to make the rounds to upgrade the software.  Certainly many EMR vendors have automated the upgrade process to some degree.  You can also often automate this process using active directory.  However, this upgrade process does create just one more area for something to go wrong with your EMR or require special IT support.  The good part is that this means that you can do the upgrades on your own timetable.

Hybrid Model

Some EMR vendors do a mix of the two options above.  They might have a server stored on site, but still have an EMR that uses web based technologies.  This still means you need the in house IT server support, but means that you don’t have to rely on your external internet connection to access the server.  It does however, usually mean that you can access your EMR from anywhere with an internet connection.  It also means that you can use a standard web browser to access your EMR instead of having to install a client on each computer to access your EMR.

This is not meant to be a comprehensive list comparing SaaS EMR with client server EMR.  Instead it’s meant as an overview of the major differences between the two types of EMR setup, but should give you enough information to choose which option will work best for your office.

UPDATE: Excuse the personal reminiscing. Sometimes I just can’t resist. There will be more great EMR content tomorrow for those who don’t care for this type of post.

Let’s just say that’s a lot of pageviews. It’s pretty humbling and demanding to think how many people have read and will read what I write on this blog. I don’t think I had any clue what I was getting into when I did my first post back on December 11, 2005. A great line from that first post:
“if you find some good information that I haven’t seen and correct me if I’m wrong.”
This has certainly happened plenty of times. Sometimes it hurts a little to be corrected, but mostly it’s a great way to learn.

Then, this little disclaimer from my first post:
“This is my best knowledge from my research and is not guaranteed in anyway.”
This disclaimer is still in effect. Although, I’ve come a long ways since I first started blogging.

I also find it amazing that the stats for the audience for this site is bigger than the most excellent of HIT blogs: HISTalk. They show 3.34 million pageviews since June, 20 2003. That’s a good 1.5 to 2 years before I started my stats tracking. Plus, they posted their July stats as: 97,368 visits, 138,957 page views. EMR and HIPAA did 149,802 pageviews and 97,274 visits in July. I’m not sure what stats program they’re using so maybe it’s off, but it’s nice to think that EMR and HIPAA has a similar size audience to HISTalk.

For those who love stats (like me), EMR and HIPAA has had 830 posts and 3,548 comments since 2005. By comparison, my much younger EMR and EHR site has had 186 posts and 652 comments with getting close to 400,000 pageviews since April 30, 2009.

I could go on forever, but I won’t bore you anymore. Although, some of my EMR and HIPAA advertisers have asked for more details on the stats for EMR and HIPAA. I usually email them the details, but I’m thinking about starting a blog for people to see all the stats. I guess I’m just not sure who would really care to see it.

Either way, I really do appreciate the readers and advertisers of EMR and HIPAA. Hopefully you’ve benefited from my posts as much as I’ve benefited from your comments and insight. Interestingly, I think the question I get asked most often is how I’m able to post so often. I don’t really have a good answer for that question. Although, I do let people in on my little secret called “scheduled posts.” Plus, at this point I have a special blog posting lens where my brain turns everything I read into a blog post. Not to mention my 300 or so draft blog post ideas is useful too.

Now on to the next 3 million pageviews. I predict 3-5 more years of EMR meaningful use blogging and then we start the next era of EMR blogging: switching EMR vendors. As long as people still need healthcare, there will always be plenty of healthcare IT to write about.

I guess kind of like they just had Shark Week on TV, this week on EMR and HIPAA has been ICD-10 week. So far I’ve covered EMR vendors ICD-10 planning, moving to ICD-10 and bridging from ICD-9 to ICD-10.

In response to my previous ICD-10 posts, Gordon Fenton provided this interesting insight about the UK’s experience with ICD-10.

Over in the UK we already use the ICD10 along side the OPCS code to generate our HRG’s which is the currenvy that commissioners and providers use in the billing process.

While I am based on the commissioner side I know that our providers employ coders whose specific job is to translate Doctors notes into ICD and OPCS codes.

The main challenge will be in varifying and validating the codes being applied by providers, the IT is just a small issue. It will be very easy for providers to inadvertantly apply the wrong code simply by the fact that there are so many.

You could do a lot worse than look at the UK model for guidance on how we deal with it

I’m always interested to learn from what other countries are doing with technology and EMR. I’d love to learn more about UK provider’s experience with ICD-10 and how we can improve the eventual ICD-10 implementations in the US.

In this Sunday’s HUH? news we have a report by Healthcare IT news that Google may be considering using their Google Wave technology for EHR. Of course, I think the writer at Healthcare IT news must have had a deadline or something since the paper written by Google engineers Shirley Gaw and Umesh Shankar about representing “Individual Health Records” that are aggregating from “multiple sources” which sounds a lot more like a PHR to me than an EHR

That minor verbiage aside, it’s hard for me to imagine Google Wave used as a PHR or an EHR. Ok, I get the idea that it would be interesting to see all the clinical data elements added to a patients history in real time (basically what Google Wave does). This is an innovation that is needed. I just think that re-architecting the very consumer focused Google Wave product isn’t going to get us there.

Not to mention, Google has chosen to stop supporting Google Wave. I think Google probably has enough to do with health with Google Health. I’ll be very surprised if we really see the Google Wave technology used in healthcare.

In response to my previous EMR and ICD-10 posts, an EMR vendor recently sent me how they plan to address the transition from ICD-9 to ICD-10. Here’s their plan:

1. We are going to have both the ICD-9 and ICD-10 codes reside in the same file in our application. This will allow the charge entry people to enter either code. There will be a field in the ICD-9 that will map to a single ICD-10.
2. We will provide a report to each doctor showing them the frequency of the ICD-9 codes they used over a period of time that they can specify. This report will show the available ICD-10 codes. The doctor can study it, start to change, or ignore it.
3. The staff can opt to let the software map one ICD-10 to the ICD-9 or manually enter the code of their choice.
4. Our electronic claims software will have a flag per insurance carrier indicating whether or not it will accept ICD-10. For those that will, we will map the ICD-9 to the 10 and send that code. If no map identified, we will generate an error edit.
5. At some point down the road, we will use the information collected from billing to update the doctor’s preferred list of dx codes in the EMR.
6. We will have to augment customized programs at each client site that may be doing reports based on ICD-9.

I’m always interested in the reactions of EMR vendors to various news. Granted, much of it is very predictable. They obviously want to sell more EMR software and so their reaction is usually a positive one when we’re talking about billions of dollars of stimulus money.

This is why I was so interested in hearing Evan Steele, CEO of SRSsoft’s response to the final meaningful use rule. Evan has been a strong proponent of maintaining the productivity of the practice and no doubt government regulations like meaningful use can stand in the way of that goal. The following is Evan’s response to the meaningful use final rule:

While the final rule on meaningful use contained some changes from the proposed rule, these modifications are only deferrals, not permanent changes. Everything that was taken out of the proposed rule will be added back in, according to Farzad Mostashari, and the flexibility granted for Stage 1 will be removed in Stage 2, just two short years away. The bottom line for physicians has not changed:

• Compliance with meaningful use will result in a significant decrease in productivity because the demands on physicians are still onerous and because it requires use of an EMR that is data-driven (traditional, point-and-click EMR) rather than workflow/productivity-driven (like the SRS hybrid EMR).
• The meaningful use measures are still not particularly relevant to specialists, as HIT Policy Committee member Gayle Harrell pointed out during the recent committee meeting.
• Participation in the government program is voluntary, as David Blumenthal made clear during the press conference announcing the release of the final rule. Physicians can choose to follow the compliance path or they can elect to pursue the productivity path.

SRS remains committed to physician and practice productivity and will continue to focus our development resources on our flagship product—the unique, productivity-enhancing hybrid EMR. Most high-performance specialists recognize that the cost of complying with meaningful use far outweighs any incentives that might possibly be earned or any penalties that might be imposed.

As you referenced in a recent post, SRS has entered into an alliance that will ensure that physicians have all the options they need. With SRS, they can reap the significant benefits of the productivity path, with the assurance that if at some point in the future they decide to pursue meaningful use, they will be able to do so as clients of SRS.

Looks like Evan is still preaching the EMR productivity message, but there’s a small sliver of hope for meaningful use with SRSsoft. I’m pretty sure every EMR salesperson is going to be so tired of hearing about meaningful use that Every EMR vendor will need a solid meaningful use strategy. Meaningful Use is here to stay. At least until the EMR stimulus money runs out.