Thursday, March 4, 2010

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.


  1. Hi Margalit,

    Wishing you a warm welcome to the blogosphere!

    I think you're in spot on in pointing out the practical challenges in integrating diverse modules, yet concluding "Does that mean that we should shy away from modular innovation in HIT? Not at all."

    You're also right in noting that 1) ONC is putting the burden on the buyer to figure out whether modules interoperate, and 2) buyers don't want to deal with this.

    ONC has asked for commentary whether the certification rules should include certifying interoperability between/among modules.

    While I see the problem here, I'm not sure I want ONC taking on this next level of challenge. I mean that literally...I'm not sure.

    Perhaps this challenge is better addressed in the private sector by standards groups and/or industry alliances, e.g., the Clinical Groupware Collaborative've been discussing exactly this issue).

    I'd welcome yours and others' thoughts.

  2. Thank you, Vince. You posted my first comment ever and will therefore be forever etched in my memory :-)

    As to the modules, I think even ONC would find it next to impossible to test and certify each module for all possible combinations.

    I think the notion of an open platform, which I believe is what Clinical Groupware is all about, is the most logical way to proceed. I was very happy to see Eclipsys announcing the open Helios platform, and I intend to do some more research on that, but it will always be the platform owner that has the ultimate responsibility for integration. A module vendor with strong core competency in a particular area could create versions for various platforms, or if our standards are rock solid, maybe just one version for all.
    In any case, the physician has the assurance that the modules work on his chosen platform, in this case Eclipsys.
    I can't think of another way, but I am definitely open to suggestions....

  3. A couple other thoughts:

    "Platform" does not necessarily equate to product (or offering). Think "Internet as platform". NHIN Direct will be a platform but there won't be any one vendor controlling it.

    "Platforms" will need to be interoperable as well. The HIT market won't be like Windows vs. Apple OS where each offering is self contained. At a minimum, platforms from different vendors will need to exchange data.

    Going even further...people are getting the glimmer that data exchange interoperability will be necessary, but not sufficient. The next layer of interoperabilty will involve process/workflow interoperabilty. This will be another level of challenge to coordinate within one platform and/or across multiple platforms.

    Despite the challenges, your conclusion is worth repeating:

    "Does that mean that we should shy away from modular innovation in HIT? Not at all."