The Advent of EHR Modules

Today, I decided to take the plunge and post on my very own, brand new blog. So let's start with something equally new and rather interesting. Certified EHR Modules.

******

With an eye to encouraging innovation by new entrants to the EHR market, ONC has introduced the notion of certifying not just comprehensive, or monolithic EHR products, but also various smaller pieces of software that can show capability of facilitating at least one of ONC's many Meaningful Use criteria.
Before the advent of HITECH, when CCHIT was the sole certifying body for EHRs, an EHR would either be certified for 100% of the CCHIT defined functionalities, or not be certified at all. That did not mean that an EHR was necessarily built by a single vendor, but it was the vendor's responsibility to assemble all the pieces together into one comprehensive solution for certification, marketing, sales and support purposes.
Leaving aside the merits, or lack thereof, associated with CCHIT certification, physicians looking to purchase an EHR had a very simple choice before them: buy a CCHIT certified EHR guaranteed to have a long list of features, or buy a non-certified solution, in which case it's caveat emptor.
Under the new ONC IFR, a third option is added. A physician can now also purchase a bunch of Certified pieces of EHR and assemble them together in his/her office. The ONC is explicitly placing the burden of such assembly (integration) on the purchasing physician.

The change may appear subtle to some, but it is not an insignificant change. While in the past it was the vendor's responsibility to integrate all pieces prior to presenting a solution to the market, it is now the customer's responsibility to perform the integration. CCHIT, which is currently the only active certifying body and may not remain so for very long, has identified 25 possible standalone modules that could be certified under ONC's definition of an EHR module. Theoretically speaking, a practice, or hospital, could be talked into purchasing 25 products from 25 different vendors in an attempt to achieve Meaningful Use.

For illustration purposes, let's look at a rather simplistic example. One of the possible modules would be a piece of software (or service) that has the ability to record and maintain patient problem lists using ICD9 or SNOMED CT terminology. Let's imagine that I buy this module from Vendor X who has the cheapest price and a very nice user interface and uses a lovely SNOMED CT encoding scheme. I take my new module home and try to fulfill my responsibility to integrate my new bargain with my existing spiffy web based lab ordering module from Vendor Y, which I got for free from my Lab vendor. Hmm, how do I do that? Let's take another leap of faith and assume that both vendors provide some instructions on setup. I set it all up and everything looks good. I now try to order a lab and to my dismay, after multiple failed attempts and several calls to both Vendor X and Vendor Y, I realize that my Lab ordering module only supports ICD9 and I have my problem list  in SNOMED CT. Not going to work. Do I get a refund? Not really, because the problem list module was indeed ARRA certified, and so was my lab ordering module. Certification does not include assurances of integration with other vendors.

Here is another tidbit of information gleaned from many years of systems integration. Unless the integrated system is thoroughly tested, it is possible to have integration looking very good on the surface, while data integrity is consistently compromised (overwritten, deleted, lost) behind the scenes. This of course is a potential patient safety issue.

If the above example looks complex, just imagine the possible combinations when there are 25 pieces that can be combined together in all sorts of fashions.
Also, if there are several hundred of comprehensive EHR products on the market today, how many module vendors will be sprouting up at very short order, considering that it takes only a few weeks of programming to create a module, compared to a few years of programming to create a full EHR?
If physicians have difficulties sifting through EHRs today as they are being bombarded by marketers with Meaningful Use guarantees, how would they navigate the thousands of "Certified" modules?
Are we setting the average physician, in the average practice, up for failure?
Are we about to expose physicians to an emerging "aggressive" marketing environment that will be spinning out of control as we get closer to the Meaningful Use implementation deadlines?
What will the repercussions be?

I wrote this article as I listened to the public meeting of the ONC Standards Committee and I was very encouraged to hear various members raising questions regarding certification of modules. Obviously they are perceiving some difficulty there, particularly regarding security and standards of communications. I am very hopeful that through continued deliberations, the committees will eventually reach a solution favorable to physicians.

Does that mean that we should shy away from modular innovation in HIT? Not at all. It is important to allow small and new vendors to enter the market with new products and new ideas. However, the incorporation of such ideas into a final "EHR solution" should not be delegated to the physician buyer. EHR modules should be integrated by vendors and presented to both certifying bodies and physician buyers as a complete, thoroughly tested and guaranteed solution. The average physician needs to have assurances that whatever he/she is buying will actually work, and at the very least, will not harm patients.