In the past, I’ve written volumes about hospital attempts to lock in doctors by offering them access to a free or deeply-discounted EMR. I haven’t heard much about this strategy of late — either the approach was dropped or it’s gone underground — but it seems that other players are still giving it a shot.

This time, in what seems to be a fairly logical step, Quest Diagnostics has kicked off a program offering medical practices a steep 85 percent discount off of the retail price of its Care360 EMR and practice management bundle.  The announcement follows up on its 2011 regional giveaway program, which Quest says attracted thousands of physicians.

The deal, which reduces the physicians’ out of pocket cost to less than $100 per month,  also includes training, hosting, maintenance and 24/7 support for Care360. The lab giant says physicians can get Care360 up and running in about 45 days.

I can’t think of a reason why this wouldn’t make great sense for Quest; if my contacts are to be believed, it has no better reputation than its key competitors when it comes to customer service and follow-through on clinical testing.

On the other hand, if I were a doctor I’d think long and hard before agreeing to a deal like this, even though the software is just about free. There’s simply too much at stake to plunge in.

Yes, Care360 is CCHIT certified and, intriguingly, has incorporated the Direct Project specs allowing doctors to share information with patients and hospitals. And yes, it seems to have made efforts to support EMR access via mobile devices. This is all good. And of course, the price is right.

On the other hand, I’m not sure I’d want to make this big of a commitment to any particular service provider, be it a reference lab, a radiology provider or the people who stock my vending machines with sodas.

I’d argue that the more important the service is, the less you want to be beholden to the vendor. After all,what if Care360 isn’t your cup of tea?  Do you really want to disrupt your relationship with a critical provider like Quest?

Not only that, it’s risky to lock in an EMR just because it’s cheap. If Care360 takes 45 days to get installed, it’s not going to be possible to uninstall it in a day or two, and that could mean misery on wheels if the product doesn’t work for you.

Besides, it’s possible to get Web-based, easy to adopt or drop EMRs for only a couple hundred dollars a month more. It wouldn’t make sense to go for an EMR that might not work just to save that little. (If your margin is tight enough that a savings of $200 or $300 a month is critical, you have worse problems than finding the right EMR!)

I guess I’m saying that even if the EMR is nearly free, caveat emptor. You don’t want to get saddled with an albatross system just because the price was right.

Could a single, mammoth database solve all our health data needs? Margalit Gur-Arie, whose writing and ideas I greatly admire, has been arguing for one quite passionately on her personal blog in a couple of recent posts (part I, part II).

The crux of her posts is this:
- There should be a single, standardized national database to which physician practises, and ultimately EMR vendors, must submit mandatory data, “in real time”. The requirements will be along the lines of current Meaningful Use requirements.
- This database will be accessible to vendors and entrepreneurs alike, and can have multiple EHRs or apps built atop them.
- Since the patient data is available, and easily accessible (no one “owns” the data, they only own the proprietary bells and whistles they perform on the data), this is a near perfect patient utopia.

It’s a great idea and perfect for an ideal world. Except:
- Massive databases cause massive headaches, as commenter Omowizard pointed out. There is a price to pay for data available at all times, all places, and by everyone. And if I may add, in Gur-Arie’s model, it’s not clear who’s left holding the bag. Presumably the government. Which opens a entirely different can of worms about data ownership.
- Real time updates of data is no joke. At my current place of work, we perform quasi-real time (twice daily) updates of patient visits to client databases from a central repository. The sheer volume is enough to bring down the database servers for a good hour or two.
- We haven’t been able to agree on a standardized schema passed for a healthcare database. What are the odds of this idea ever catching on?
- How are we going to mandate data population? After physicians and care organizations, will EMR vendors be the next recipients of government bribes/largesse/sops to induce them to populate the database?
- Gur-Arie herself points out that American enterprise being what it is, if there are no financial benefits to data ownership, they’re going to be a hard sell.

And while it’s easy for me to write a smart alecky blog post about the infeasibility of the mammoth database idea, I shudder when I think of what we have now: disjoint EHRs that don’t “speak” to one another, walled gardens and proprietary ownership of data that pretty much lock physician office in, PHR offerings from companies like Microsoft who will do God knows what with OUR health data.

I don’t think there are any easy answers. I’m leaning more towards an open source health “OS” platform rather than a single database. But at the very least, Gur-Arie offers some great food for thought.

For quite some time now, I’ve nursed my own doubts about:
- how effective EMRs are (disastrous in the short term, long term they’re supposed to make life easier, but we haven’t seen any evidence of that yet)
- why physicians are being paid to implement something that makes logical sense (you need something to nudge people out of status quo. And probably in the government’s thinking, what better use for taxpayer dollars, right?)

I came upon this blogpost, provocatively titled Why EMR is a four-letter word to most physicians. Adam Sharp, Par8o (“pareto”, not “par 80″) founder references this post from the Healthcare Blog. The discrepancy in the rates between adoption of any EMR is mind-boggling. It was projected to be close to 56.9% in 2010, vs. adoption of a fully functional EMR (projected to be close to 10.1% in 2010). (I’m not using the 2011 rates because the rates for fully functional EMR adoption in 2011 are not listed).

A reason Sharp gives for incentives and threats of decreased payment are “the industry and physicians have known for years that EMRs do not improve productivity and that it is highly questionable that EMRs lead to better patient outcomes”. While I would agree that in the short term, there is decreased productivity, I’m not so sure you can dismiss there is no productivity increase over the long term. This report about a UC Davis study for example, shows that the loss of productivity was just one month for internal medicine, and that productivity increased to pre-EMR implementation levels in the next six months. The not-so-good news is that productivity levels declined for pediatricians and family practices.

I interpret these findings like this: for specialties where there is loss of productivity, sure, the whole exercise needs a rethink. But in cases where your productivity is at par with your pre-EHR levels, I think there is a hidden benefit that detractors are more than willing to gloss over – the availability of patient data. Data is the holy grail – it’s up to us to figure out whether and how we use it.

Sharp also imagines some doomsday scenarios – of EMR vendors with uncanny abilities to do as they please.

“The goal of EMRs is to wrestle control of healthcare away from the doctor-patient relationship into the hands of third parties who can then implement their policies….by simply removing a button or an option in the EMR.”

Maybe I’m turning turncoat here and letting you guys in on the best kept secret of the IT industry, but every vendor I’ve worked for, past and present, figuratively quakes in his IT boots when it comes to contract renewal. Even for COTS products, vendors actually customize things here and there for customers, till you have 25 versions of the same code, all just to keep their customers happy and paying. While I’m pretty sure there are rogue vendors who can give you the best EMR nightmares money can buy, I also do think customers can, and do, help rein in errant ideas. In other words, vendors can’t simply remove buttons and options or randomly start charging you for stuff, not unless you let it happen. And you, the customer, hold the purse strings, ergo YOU, not the vendor, call the shots.

I don’t quite find myself agreeing with the cynical conclusion of the post which is that the point of EMRs is to wrest control away from doctors and patients into the hands of third parties who wish to regulate choice and eligibility. But there’s plenty there that’s food for thought. Go check it out.

Dr. Sullivan is a practicing cardiologist who joined DrFirst in 2004, just after completing his term as President of the Massachusetts Medical Society. He is known throughout the healthcare industry as the father of the Continuity of Care Record (“CCR”) and a leader on the future of healthcare technology. He is assisting DrFirst in ensuring that Rcopia continues to add the functionality necessary to maintain its leadership position both in electronic prescribing and in the channel of communication between various sectors of the healthcare community and the physician. Dr. Sullivan is active in organized medical groups at the state and national level, and is both a delegate to the AMA and the Chairperson of their Council on Medical Service as well as past Co-Chair of the Physicians EHR Consortium.

The buzz surrounding Electronic Health Records (EHR) is nothing short of constant.  The daunting task of selection, purchase and implementation is quite confusing, technical, and expensive, with many physicians, clinics and health systems uncertain of their needs and questioning how the technology is going to impact the way they practice medicine and their bottom line. It’s all about workflow and productivity.

More recently, Providers are faced with the intimidating task of deciding which kind of system to install. There are all inclusive systems, often referred to as fully paperless or standard EHRs and there are so called a la carte systems known as modular EHRs.

The Case for Modular

Modular EHR systems allow providers to take a stepping stone approach to health IT clinical documentation and order writing, by choosing the tools and functions which make the most sense in their practices and clinics; improving specialized workflow and efficiency.  Going the modular route can gradually ease the provider and the office staff into a more paperless environment without having to make a full and often-times difficult transition to a fully paperless workspace.

There is need for caution however. The sheer volume of modules available can make selecting appropriate ones an overwhelming task.  Not only do clinicians need to be wary of which modules they are choosing, but also what functions have been certified by an authorized organization.

By combining specific modular systems, it can become “qualified,” making the user eligible for the monetary reimbursements set forth by Title IV of the American Recovery and Reinvestment Act of 2009 (ARRA).

At DrFirst, our Rcopia-MU^TM has taken all of the guess work out of this process and is a completely certified Modular EHR that physicians can implement and start earning incentive money directly out-of-the-box.

The implementation of a complete EHR system can be confusing and time consuming.  Herein lays some distinct advantages of implementing a modular EHR.  Practices that have already implemented e-prescribing or registry modules may not need to relearn a different system, or move their data from one to another (as long as the current module is certified).

Providers who are considering going the modular route can check the certification status of their options at Certified Health IT Products List. The cost for a modular approach is often much less expensive and providers can select the modules from various vendors to meet their financial and practice-based needs.  Upon implementation, providers must show they’re using certified EHR technology in measureable ways to receive their incentive monies from the Federal Government.  With this very high ROI, many providers see the advantage of using the modular approach to postpone the decision process in selecting a complete EHR and yet at the same time earn Meaningful Use incentive money to put towards the cost of  the much more expensive system.

According to the Centers for Medicare and Medicaid Services, doctors who have not adopted an EHR (either modular or complete) by 2015 will be penalized by Medicare — a 1% penalty to begin, then up to 3% within three years. Many providers are banking on the reimbursement that has been made available by the ARRA to help offset the initial costs.

What is your practice considering, complete EHR or modular? Do you see benefits of one over the other?

John’s recent post about ONC trained participants finding it difficult to find jobs struck a chord. A different post over at HIMSS had me thinking in overdrive.

Dr. Noam Arzt has a post on Meaningful Use and public health reporting. In it he discusses the problems faced by providers in submitting health information to public health bodies in ways that are also Meaningful Use Stage 1 compliant.

Health records in provider offices are sometimes stored in disparate silos that are cannot/do not communicate with one another. As Dr. Arzt explains with an immunization records example, there is no demonstrable Meaningful Use if an uncertified system makes the data submissions to public health.

Of course, adding additional functionality to the EHR system with a simultaneous revamping of uncertified system to provide Meaningful Use share data with one another is one (costly) solution. Getting the secondary data system certified is another one. A third approach, which Dr. Arzt touches on, is for Health Information Exchanges to act as/provide for certified intermediaries that bridge the data flow between an uncertified system and one that is Meaningful Use certified.

Here’s what HHS had to say about the subject a month ago:

If an intermediary performs a capability specified in an adopted certification criterion and a provider intends to use the capability the intermediary provides to satisfy a correlated meaningful use requirement (submission to public health according to adopted standards), the capability provided by the intermediary would need to be certified as an EHR Module

This intermediary need can be filled, especially by innovative software vendors or those looking to break into the EHR IT industry. From plain data conversions to web services, IT companies have plenty of tricks up their sleeve to assist HIEs. The technology is there, all we need are savvy techies (companies, people) to see the opportunity this presents and act on it.

Guest Post – Amit Trivedi – As the healthcare program manager for ICSA Labs, Amit Trivedi spearheads the lab’s overall efforts in the healthcare industry, including launching and managing the 2011/2012 Office of the National Coordinator (ONC) Authorized Testing and Certification Body (ATCB) certification program.

We all know there is no such thing as perfect security. All we can do is try to mitigate as many risks as possible. In this regard, there are areas related to information security that the current ONC-ATCB 2011/2012 (commonly referred to as meaningful use) certification testing does not yet address and that the health IT community should be aware of when implementing systems.

ICSA Labs is an Office of the National Coordinator-Authorized Testing and Certification Body (ONC-ATCB), designated to test both complete and modular electronic health record (EHR) technologies under the auspices of the federal government’s Temporary Certification Program. ICSA Labs has a history rich in the certification of security products. We have been testing security products and developing test criteria for more than two decades and we understand the importance of raising security awareness in the health IT community and helping Eligible Providers and Hospitals understand what meaningful use EHR certification testing does and doesn’t cover.

It is important to remember that regardless of the number of security features a product has, an incorrect or incomplete implementation can introduce vulnerabilities or compromise the security of the system. Certification testing can really only demonstrate that a product is capable of being used securely, not that its security can never be compromised.

Testing bodies must test products within the scope of approved test procedures. As an organization that has developed testing procedures and methodologies, we understand that there is a delicate balancing act when developing requirements so that general concepts and capabilities are covered by the testing, but the testing process is not designed so specifically as to stifle innovation in new products. As such, we recommend that end users and implementers be aware of these requirements when deploying ONC-ATCB 2011/2012 certified products.

Encryption Requirements Do Not Address the “What”

Consider the encryption requirements (criteria 170.302.u and 170.302.v). The current testing criteria require FIPS 140-2 level encryption. This an excellent way to require products to support some of the best levels of encryption available today, and that they are also in line with other federal encryption requirements.

One could compare encryption to a bank vault. You might purchase the most secure, unbreakable vault in the world, but if you don’t put your valuables in the vault, it won’t be of any help when there is a break-in. The current meaningful use testing procedures do not dictate what must be encrypted. Ultimately it falls to end users to make a determination as to how they want to implement security – hopefully basing the decision on a risk-based approach. Fortunately, meaningful use testing and certification follows a staged approach to getting from where we are today to where we’d like to be in the future. The meaningful use certification is planned to be rolled out in three stages. Right now, we are in the midst of Stage 1. Some recommendations to the ONC for Stage 2 security criteria include addressing things like encrypting data at rest (including data in datacenters and mobile devices) – something that is not part of the Stage 1 requirements.

Negative Testing Examines the Unexpected

Another area to highlight is related to negative testing, which is currently out of scope for ONC-ATCBs. The testing performed today relies on giving the EHR an expected input and verifying that the expected result is met. Negative testing, however, is the concept of giving unexpected or invalid inputs to a system and verifying receipt of an expected result (typically, that the data is not accepted or an error is generated that does not crash the system). Negative testing is common throughout ICSA Labs’ proprietary security testing programs and something we feel should be incorporated into future testing of EHR technologies under the ONC Certification program.

Consider the authentication and access control requirements (criteria 170.302.t and 170.302.o). Some of you may be aware of an old Unix bug that resulted in the operating system being unable to correctly support passwords over eight characters. If the password was 12 characters long, a user only needed to enter the first 8 characters to be allowed to login. This made password cracking on Unix servers much easier, and because the system allowed the entry of a longer password, most users were unaware of this limitation.

ICSA Labs has discovered the same or similar problems when testing products in our proprietary security certification programs, and the primary way we discover this is by negative testing. For example, we configure a password greater than eight characters, and then we attempt to login to the system using only the first eight characters. This should be treated as invalid by the system and rejected. However, the meaningful use EHR testing only tests that the system accepts valid passwords. There is no testing done on the system’s acceptance or rejection of invalid passwords.

The Future of EHR Testing Must Increase Security, Privacy

As we progress to the next stages of meaningful use certification, the requirements should begin to look at other areas of security, such as application testing for vulnerabilities like buffer overflows, SQL Injection, and cross-site scripting attacks. These are all examples of security testing best practices. In many instances, ONC has signaled its flexibility in allowing third-party products to complement functionality of EHR technologies, which means that not all of the functionality needs to be native to the product. This can allow EHR developers to focus on functionality that their customers are looking for, while at the same time keeping security as an important consideration in the product life cycle development.

It is our hope that future stages of meaningful use testing will raise the bar and specify how and when features like encryption should be used and the scope of testing will be expanded to include things like negative testing. As the meaningful use criteria evolve, it is critical that both the criteria and testing procedures are developed in ways that consider the long-term security and privacy of patient health records.  

Time for the next entry covering Shawn Riley’s list of 101 Tips to Make your EMR and EHR More Useful. I hope you’re enjoying the series.

If you want to see my analysis of the other 101 EMR and EHR tips, I’ll be updating this page with my 101 EMR and EHR tips analysis. So, click on that link to see the other EMR tips.

60. Reporting, reporting, reporting, reports
What’s the point in collecting the data if you can’t report on it? I’ve before about the types of EMR reports that you can get out of the EMR system. The reports a hospital require will be much more robust than an ambulatory practice. In fact, outside of the basic reports (A/R, Appointments, etc), most ambulatory practices that I know don’t run very many reports. I’d say it’s haphazard report running at best.

Although, I won’t be surprised if the need to report data from your EHR increases over the next couple years. Between the meaningful use reporting requirements and the movement towards ACO’s, you can be sure that being able to have a robust reporting system built into your EHR will become a necessity.

59. Are the meaningful use (MU) guidelines covered by your product?
Assuming you want to show meaningful use, make sure your EHR vendor is certified by an ONC-ATCB. Next, talk to some of their existing users that have attested to meaningful use stage 1. Third, ask them about their approach for handling meaningful use stage 2 and 3. Fourth, evaluate how they’ve implemented some of the meaningful use requirements so you get an idea of how much extra work you’ll have to do beyond your regular documenting to meet meaningful use.

58. It they aren’t CCHIT certified take a really really hard look
Well, it looks like this tip was written pre-ONC-ATCB certifying bodies. Of course, readers of this site and its sister site, EMR and HIPAA, will be aware that CCHIT Has Become Irrelevant. Now it’s worth taking a hard look if the EHR isn’t an ONC-ATCB certified EHR. There are a few cases where it might be ok, but they better have a great reason not to be certified. Not because the EHR certification provides you any more value other than the EHR vendor will likely need that EHR certification to stay relevant in the current EHR market.

57. What billing systems do you interface with?
These days it seems in vogue to have an integrated EMR and PMS (billing system). Either way, it’s really important to evaluate how your EMR is going to integrate with your billing. Plus, there can be tremendous benefits to the tight integration if done right.

56. How much do changes and customizations cost?
In many cases, you can see and plan for the customization that you’ll need as part of the EHR implementation. However, there are also going to be plenty of unexpected customizations that you don’t know about until you’re actually using your EHR (Check out this recent post on Unexpected EHR Expenses). Be sure to have the pricing for such customizations specified in the contract. Plus, as much as possible try to understand how open they are to doing customizations for their customers.

Check out my analysis of all 101 EMR and EHR tips.

I’ve been writing about the various open source EHR software options for about 5.5 years right now. I’ve been intrigued with open source for much longer, so it just made natural sense for one of the first things for me to look at would be the various open source EHR options.

5.5 years ago the open source EHR market (although EHR really wasn’t in vogue yet back then) had a solid foundation, but still had quite a ways to go for it to be a great option for doctors interested in an open source EHR option.

I haven’t done an in depth look at the various open source EHR options for a while (I should), but I think the fact that many open source EHR software are now certified EHR and can help physicians show meaningful use and receive EHR incentive money is a good sign. Most of you know that I’m not a big fan of EHR certification, but I do believe that EHR certification takes a certain level of commitment to be able to achieve. Therefore, I think it’s a great sign that the open source EHR options have enough steam and commitment behind them to become certified EHR.

A recent Open Health News post listed the following certified open source EHR:
Ambulatory Open Source EHR
ClearHealth
OpenEMR
Tolven eCHR
Vista (inpatient) Open Source EHR
WorldVistA EHR
OpenVistA
vxVistA
Other (inpatient) Open Source EHR
Indian Health Services’ RPMS

I’d love to hear reviews and experiences that people have working with open source EHR software.

This week, federal policymakers gave providers and hospitals a welcome break in complying with Stage 2 Meaningful Use requirements. The Health IT Policy Committee has voted to delay the implementation of Stage 2 for one year, from 2013 to 2014.

The delay, which is relevant for eligible providers and hospitals that already qualified for MU incentives this year, is a welcome reprieve. Since final rules for Stage 2 aren’t likely to emerge until June 2012, many would have missed their deadlines, something that even the Policy Committee admitted.

Now, the matter of getting Stage 2 rules finalized moves to CMS, which will review the draft recommendations and issue final rules. Nobody’s sure what will happen if the agency doesn’t meet the expected deadline in mid-June, but I guess we’ll just have to wait and see.

In the meantime, as blogger Jim Tate correctly notes, the move raises many questions.

For example, will this decision slow down the implementation of Stage 3 MU rules?  Will eligible providers/hospitals actually take advantage of the delay, or get bogged down and burn through the extra time?  If the eligible providers that qualified in Stage 1 stay there for three years will they only get two years of incentives based on meeting those rules?

I would add a few other questions as well:

* Will those providers who qualified for Stage 1 incentives find adopting Stage 2 to be a reasonable, incremental change or a big leap? Is even an extra year enough to make the needed HIT and process changes necessary to meet this goal?

* Over the next two years, will some providers find that it will cost more to meet the added requirements than they’re getting from the government?

* Will the Policy Committee and other federal officials be able to sell Meaningful Use to newly-arriving providers for 2012, or will there be a revolt of some kind?

I suppose you can see from my questions that a) I suspect hospitals and providers would be unlikely to adopt MU-type features on their own and b) that I don’t know if the government’s existing carrot-and-stick approach can keep  them interested.

Honestly, I’ve always been skeptical that a template-like approach like the MU regs is likely to produce the kind of rich data and improvements in care quality that backers hope. I believe there are better ways to foster smart use of the EHRs the government has demanded.

After all, if requiring certain process changes worked seamlessly, they’d work even without digital medicine, and the whole MU issue would be moot. (The EHR system would support those super-cool care processes rather than being replete with specific features set up as proxies for quality care.)

But maybe I’m being a Luddite or a troglodyte or whomever you are when you’re skeptical that something new works. What do you think?

Carl Bergman, from EHRSelector.com, sent me the following email which poses some interesting questions about various certified EHR vendors and the software that they depend on to be certified.

Many of the [certified EHR] products relied on several other software companies to function. Usually this was Dr. First’s Rocopia, Surescripts, etc. However, many others had required several subsidiary modules to work. For example, Pearl EMR lists: MS .NET Framework 3.5 Cryptographic Service Provider; SureScripts; BCA Lab Interface; Oracle TDE.

There is nothing inherently wrong with this, but it raises three questions. Does the vendor include the price, if any, for subsidiary software? More importantly, how well integrated are these programs integrated into the main program? Does the vendor take responsibility if the subsidiary software changes making them incompatible?

He definitely asks some interesting questions. I’d say that in most cases, there will be little issues with the dependent software. Any changes by the dependent software are going to have to be dealt with or in some cases replaced by the EMR vendor. That will just be part of the EMR upgrade process that the EMR vendor does for you.

The only exception might be things like the third party ePrescribing software. Depending on how this is integrated it could be an issue. In most cases, integration with the ePrescribing software can be very much like an interface with a PMS system or even a lab interface. If you’ve had the (begin sarcasm) fun (end sarcasm) of dealing with these types of interfaces you know how it can be problematic and often a pain to manage. I believe the interface with an ePrescribing module is less problematic, but it will exhibit similar issues depending on how the EMR software works with the ePrescribing.

Personally, I don’t have much problem with these types of integrations. As long as the EMR vendor is providing all of the software for you. The reason this is important is because if you get the EMR software from one vendor and the ePrescribing software from another vendor and then tell them to work together, you’re just asking for a lot of finger pointing. However, if your EMR software chooses to integrate a third party software to flesh out the certified EMR requirements and provides you all of the software, then you’re in a much better position. As they say, then you only have one neck to ring if something goes wrong. You don’t want to have to call both vendors and have each vendor point the finger at the other. That’s a position that no one enjoys.