Skip to content Skip to navigation

One-on-One With The Drummond Group CEO Rik Drummond, Part II

November 19, 2009
by root
| Reprints
In this part of our interview, Drummond says turning out interoperable EHRs that users want, at a price vendors can afford, takes a village of input.

For years now, CCHIT has been the only certification game in town. Pre-HITECH, the organization both created certification criteria and tested vendors against that criteria. Post-HITECH, everything has changed. Recommendations from the federal HIT Policy Committee indicate that CCHIT will not be able to perform its dual roles, leaving it to only handle the testing function. The committee also encouraged others to get into the testing game, injecting market dynamics and competition into this new niche of healthcare IT. After a few months of silence, CCHIT’s first competitor has emerged – the Austin, Texas-based Drummond Group. Recently, HCI Editor-in-Chief Anthony Guerra had a chance to chat with CEO Rik Drummond about his decision to enter this evolving market.


(Part I)


GUERRA: Do you see an issue with the fact that CCHIT has a substantial degree of vendor involvement? Is that something you will try to avoid?

DRUMMOND: We always try to have a really good mix of vendors and end users because they have different points of view, and you need to satisfy them both. You need to satisfy the vendors so they can make money on developing product. You also need to satisfy the users so they can buy a reasonably priced product.

Often, because each side has a different perspective, unless you have both of those perspectives in place, you will not end up with a well-priced quality product, which is also reasonably easy to produce. So you must have both of those involved, and if you don’t have them both as part of your stakeholder group, it doesn’t work. Of course, if your stakeholder group is only vendors, quite often you get too focused on what the vendors want versus what the end users want. If your stakeholder group is all end users without involvement from the vendors, you get what the end users want, and they often want things which the vendors can’t do in a cost competitive manner. So it’s a very sensitive balance to have those two involved, and we always work very hard to bring both to the table.


GUERRA: You said it would be important to collaborate with CCHIT in some ways. In what ways will you collaborate versus compete?


DRUMMOND: We might compete, for example, on things like the length of the test, whether it’s a thorough test, whether the output of the test actually produces conformant products. It can’t just say they’re conformant, but it’s about whether the output of the test actually produces interoperable products.

When I say interoperable, I should be able to buy it off the shelf and install it, and it should be able to talk to another product of the same type really, really easily. I shouldn’t have to debug it. It should just start working, and we have a depth of experience in commercial off the shelf products in this area.

So we will compete on the quality of output of the tests, and the pricing of the tests. But again, the feeder for the whole test is the vendor/user stakeholder groups determining the functionality that’s required.

At that point, testing agencies can take those things, break them down to more detailed tests, and go through and verify that the software actually does what it’s supposed to do. If you don’t do it that way, what you have is a group over here testing ambulatory care with a slightly different ilk than a group over there. When those two products have to communicate, they may not work because you’ve chosen different functional things, because you didn’t all choose exactly the same piece of detailed functionality to test on.


GUERRA: So the real value of a “Drummond Group” stamp might not be known until the user, not the vendor, has to exchange information with another EHR in a real-world situation?


DRUMMOND: Right. What you want to have them do is buy the product, the other guy buy another product (which both say they’ve been tested and they’re interoperable and conformant), they both install them, they say, “Let’s communicate,” and the user says, “Oh, this is working really smoothly. I’ve just got to read the manual and click the right configuration buttons. I don’t have to debug it.”


And that’s the key to this whole thing and, of course, that takes massive amounts of planning. And the way you have to attack this whole problem is to work backwards. You go out and ask yourself the question: What does the end-user market want when they install this product? And you start working backwards to get to that.

The next question really is, once these things are in place, how do I maintain that these products stay true to this standard as they go through versions over the years – and we call that life cycle issues – which you have to think about upfront or you start having major problems. So you start working backwards.