HIStalk Mobile Interviews Paul Brient

Paul Brient is President and CEO of PatientKeeper

Paul Brient

How does PatientKeeper help organizations achieve meaningful use?

The evolution of PatientKeeper has been very much about automating a day in the life of a physician. We got started much like MercuryMD did, although we started on the charge capture side, which is a small piece of what physicians do. Over the last 10 years we have built applications that support just about everything that a physician does.

Before the ARRA was passed and meaningful use was defined, the one product area we had not taken on was physician order entry. Now, with the definition of meaningful use and the acceleration of that market – or at least the proposed acceleration of that market – we have gone full force into building a CPOE solution which we actually had already designed and had “in our back pocket”. We raised a bunch of money and are going forward with building it. We signed our first customer and hopefully we will sign several more before HIMSS. We will be deploying it in the October-November time-frame.

So, the short answer is about 80 percent of the meaningful use measures are physician-facing; that is they require the physicians to do something; to use it. We will supply our clients with the ability to meet all of those physician-facing requirements of meaningful use.

I know that if you were to go in and run reports showing the frequency of direct physician interaction with legacy systems in the HIS environment, a lot of vendors – not to mention hospital CIOs – would be very embarrassed.

Yes they would. We have run those in fact. It’s a small number.

Clearly, the meaningful use criteria require direct clinician interaction, and ultimately adoption of the technology. If you told me that your adoption rates were 3 or 4 times greater than those legacy systems, I would think you were being extremely conservative. Having said that, how do you build a business model around being the "adoption layer" of technology?

Well, we’re more than the adoption layer. We now have 12 different applications. With CPOE we’ll have 13. We are fundamentally all about technology that supports physician workflow.

It isn’t just about looking at results, or just about trying to expose legacy systems in clever ways. We have a full stack of applications that do all of the functions that meaningful use requires. Now, CPOE is obviously about physicians putting in orders. We push those back to a back-end system, but the full order workflow for physicians and their supporting staff like nurses and ward clerks is all in the PatientKeeper system.

This is quite similar to our sign-out product, which is a little more straightforward. That’s an application that mostly stays in PatientKeeper to keep it distinct from the legal medical record. Sign-out is a proper application with business logic, and all that good stuff, that automates the sign-out process between physicians.

So, our business model is very much around selling applications to hospitals and enabling them to meet meaningful use criteria.

You know, you first have to get physician adoption, and most hospitals are still struggling to get doctors to use any technology. We’ve been very successful at getting adoption rates into the 70-80-90 percent rate, which is well more than double what the current HIS system has. Then, we also add to that functionality; for example, active problem list management. We have a problem list application which many organizations don’t have. Forget about the fact that the physicians wouldn’t use it if it were part of the core system – because they’re not using the core system – it’s not even available.

We add net application functionality. We look very much like – I won’t say a traditional application vendor because our technology approach and the fact that we’re a layer on “top of” is a little unique – but we sell software and create a tremendous amount of value for our clients. If you think of being able to meet meaningful use requirements without ripping and replacing your existing systems, to do so for a fraction of the cost of going out and buying a new system- in a half or a third of the time – then that’s a lot of value creation. So, we’re pretty excited about that.

Is it typically assumed by a hospital that their CPOE system is going to be provided by their core system, or are they attuned to the fact that no, they’re not going to get it from Cerner, or McKesson, or whoever it might be and that they need to talk to PatientKeeper?

Well, traditionally there really was only one choice. You had to buy a core system in order to get CPOE, and you got it from the core vendor. Obviously, given the adoption rates of core systems – and even worse, the adoption rates of CPOE, especially in the community setting, which are very low, single digits – that hasn’t been a very successful strategy.

I think we are one of the only… I’m sure HIMSS will tell us whether there are others that are approaching it this way. There aren’t any other systems that I know of that allow you to buy CPOE as an application to run on top of your current core system.

We think it is very important to decouple those two because you’re talking about automating physicians and not automating hospitals. So, let’s automate the physician. Obviously we have to send that data to the hospital system so they can fill the orders and do all that workflow, but that’s a well established workflow and if you try to just expose that to the doctors, it doesn’t work for the doctors. The doctors don’t use it. It’s really not going to help you on the meaningful use criteria since they were clever enough to say that meaningful use means people really use it, and not that you just have it.

It is not something that if you call up 100 CIOs, they’re going to go: “Oh, yeah, we have these two options. We can buy an add-on physician workflow, CPOE system or we can go to our core vendor.” Part of our big push at HIMSS is very much to let people know that we’re an option.

Maybe we’re not the right option for everybody, but we’re certainly at least worth thinking through as an option to, you know: “I’m a Meditech shop. I can either try to deploy Meditech Magic POM – which we know doesn’t work. I can try to upgrade to Meditech 6.0 – which might work. Or, I can rip it out and put in a Cerner or a McKesson – which several of those systems haven’t worked terribly well either.”

We’re all about an alternative. Here’s a different approach. Our CPOE product is not just a “me-too” product. It was designed for community physicians and based on a whole bunch of design principles that in some ways fly in the face of what a lot of traditional, more academic medical center- based CPOE systems do.

Do you have confidence that when the dust settles, meaningful use will be based on actual clinical adoption and not simply whether an organization purchased the prescribed laundry list of certified systems?

Certainly they’re going about it in the right way. The stage one criteria for CPOE is very much around 10 percent of the orders have to be put in directly by doctors. The government originally thought phase two would be a hundred percent, but they’ve signaled that they are backing off of that.

Let’s say its 50 or 60 percent. You and I both know that around the country in community settings, well less than 50 percent of physicians ever sign in to the core HIS system. Well less… like 10 percent. You look at the 10 percent hurdle and you go, I can probably somehow get there. That’s not a very big hurdle.

But, if it get’s anywhere north of that these systems aren’t going to support it unless they do something radical with their doctors, which in a community setting, you don’t have a lot of levers to pull. Doctors aren’t getting paid to do it. They’re voluntary physicians. In the academic world, or if you’ve employed all of your doctors, you can have a different argument. In the community world, it’s a non-starter.

We’ve got a lot of clients that have tried CPOE and have failed miserably. Just doing it again, now because the government said so, isn’t really going to produce a different result, right? We are very confident, first off that our CPOE will save doctors time, so they’ll want to use it. At the end of the day, if you’re going to give me some technology and it doesn’t save me any time, and doesn’t benefit me, why would I use it? And, that’s kind of what the old CPOE strategy is – well, it’s maybe time-neutral, at best, and it really isn’t.

What if I gave you a CPOE product that cut your rounding time in half? Now would you use it? So far the answer from the doctors that we’ve engaged in with our product is “Absolutely, thank God.”  What we are doing is a big change. It’s a significant departure from the approaches in the past. We’re all about that non-employed physician in the community that maybe goes to a couple of hospitals, who’s trying to make a living in an increasingly difficult-world. Slowing them down is just a non-starter.

I understand that you have been fairly involved with HIE through the PatientKeeper Community Connector solution that you offer. How important is HIE to PatientKeeper’s overall strategy?

Our approach to HIE, in some ways, is philosophically similar to the approach of the rest of our applications, which is “let’s make sure that we solve a problem with HIE that helps the physician”. So many HIE efforts have failed, just look at what happened in California and many other parts of the country.  Even where people have been successful with building an HIE or RHIO or a CHIN, or whatever you want to call it, physicians don’t really use it because it is separate from their core workflow. 

Our approach to HIE certainly involves exchanging clinical data –we do that all the time, so that’s not a big technological challenge for us. The real question is how do you do that in a way that is meaningful to the doctors and doesn’t slow them down and works in the context of their workflow.   Consequently, we prefer to work on HIE projects that are at the community level, where you have a couple of hospitals and the physicians in the community and start moving data there. Since most of the care that people receive is in their community this has most relevance and the most impact.

To the extent that people want to build HIEs that connect the country and allow me to go to Colorado and break my leg and get my medical records – that’s great. That’s useful to the patient, and will be useful to whatever doctor saw me down there, too. We, PatientKeeper, don’t necessarily want to play in that world, per se.

At PatientKeeper we are much more about connecting communities. We’re doing that in most of the places where we have clients. So, it really depends on how you define HIE. On almost every deployment that we do, we’re connecting something to something, and increasingly we’re focused on connecting EMRs as more and more physicians get EMRs.  One of the unexpected challenges we encountered is that we are finding that a lot of the EMR systems that are in production can’t connect. Physicians have to upgrade to the latest version or a version that’s coming out in 3 or 4 months before they can really plug-in nicely into the HIE world.

What is your view of a sustainable HIE? What is a business model that will work?

One of the things I like to remind our company is the simple fact that if our customers have no business model, we have no business model. So with much of the HIE activity (and the CHIN and RHIOs before them), one has to ask what problem are you solving? And it’s really expensive to solve the problem of – I go to Colorado skiing and break my leg and a physician can get my medical records. Is it really that useful? The doctor still has to take an H&P. It’s hard to really get excited about that as a way to spend billions of dollars, and operate a big enterprise.

Our company’s stance is – and I feel this same way personally – that we’re reasonably skeptical of what we call “standalone” HIEs. You know, go build an organization, go try to put all of this data in one place, and then ask people to go look at it – because I don’t think that solves enough of a problem to create any economic value for anyone to pay for it. Almost all of them have been funded through grants, which are one time grants. The grant runs out, and now you go out of business.

We’re more excited, though… at the local level, there really is value. That’s where most of the patients are – obviously if you’re in a community – and where most of the healthcare is delivered. There’s a lot of need for moving data around and understanding what medications people have, and just the simple thing of, if I do a referral to somebody, it’d be nice to do it electronically. So, there is some real value that is created locally.

The problem still remains – who pays for it? Where we’re seeing some good traction and some sustainability is where someone’s deployed our technology – and once you deploy either our Web product or our portal, or our handheld products, or both –they’ve solved all of these integration challenges that are in many ways the same integration challenges that you would solve in an HIE. A lot of our customers are saying, “Didn’t we already do this? And, if we just agree to work with the hospital across town, or with these 5 large practices and have them just link in, and do the integration just one more time for small dollars, don’t we have an HIE?”

And the answer is – Yes. I don’t know what the definitions out there are, officially. Someone out there might say, “No, it doesn’t count.” But it solves a lot of problems, and it doesn’t really cost anything more. You put it on the same servers, and it’s some incremental services work to do the integrations, which in some ways, in the outpatient world are significantly easier than in the inpatient world. It’s not even a particularly challenging problem technologically. It’s more operationally and politically getting everyone to agree. Once you get everyone to agree to do it, it’s pretty straight forward. Then, you do it in the context of something that’s already there. The incremental cost is low and the value is high. You know, it’s not going to change the world – but it’s kind of nice if I’m a doctor and I’m using a PatientKeeper system and I can whip out my iPhone when I get a new patient and I can see their meds and allergies from the other doctors in the community.

You know, that’s actually useful. Still have to take an H&P, so I don’t really save any time, per se, but it’s a more accurate H&P. If a patient comes in and says, “Yeah, I’m on 3 medications… the blue one. And, what’s the red one I take?” If you get those kinds of things, you’re going to be in trouble. With an HIE you’re able to solve that problem and make sure you don’t create any more problems for the patient.

One of the other big bonus things about this is – there’s a lot of drug-seeking behavior out there – and the HIE really nails that. Depending on what kind of physician you are, that can be a consideration in your practice. It takes a lot of the stress out of that, if you pull someone up and say, “Oh, geez, you’ve had Oxycontin from six different providers in the last six months.” And the patient’s presenting with some weird symptoms, you can feel confident about saying this person has drug-seeking behavior, and send them along. They don’t talk a lot about that, but it’s one of the things we’ve seen that is of real value.

I’d really love to see vendors, who are in the position of putting together HIEs, go the opposite direction of traditional – “guess what, now that’s our data; let’s lock it up” – and instead find a way to serve that up and to lend their platforms to actual application developers, to foster more rapid development of high-value applications. Do you see an opportunity to open up access to some of that information so that other, next-in-line developers now don’t have to go through that same integration learning curve?

It’s a really interesting question. I think it’s a great idea. The thing that I struggle with a little bit on all of this is the potential value lit up against all of the privacy and security regulations that are being put in place.

As you know, HIPAA was just re-tightened and we’re going through various audits and making sure that we are compliant with everything for our clients. It would be really great to get some guidance around this. Certainly from a technology perspective, given our architecture, opening up access to all the data in our system to third parties would not be difficult and I think others are in the same boat.  But if I went to one of our clients and said, “Hey, I know you put all your clinical data in our system, wouldn’t it be great if we could expose that data (obviously de-identified) to a bunch of people so they could do some analysis and research on it and learn stuff?”

I think there would be a crater in the ground when their compliance department heard about that. Whereas, if we get the government to say, “Hey, look, as long as you aggregate and de-identify the data this specified way, you can publish this data all you want.” That, I think, would be really powerful.

Other than a handful of new contracts, what would make HIMSS ’10 a successful event for PatientKeeper?

HIMSS 2010 is all about ensuring that community hospitals understand that they have an “an alternative path” to achieving meaningful use – that doesn’t involve ripping and replacing their core IT system. We’re trying to have some fun with this message and you’ll see some brightly colored vehicles around Atlanta offering to provide an alternative path from local hotels to HIMSS. So I’m hoping that we can at least help with HIMSS logistics if nothing else.

Any final thoughts?

I have spent my career in the Healthcare IT space and I can say without question that this is the most exciting and challenging time to be in the industry. We have the opportunity to dramatically expand the scope of IT use in healthcare but also improve its ultimate impact on physicians, nurses, and of course, patients.

↑ Back to top

Founding Sponsors

Platinum Sponsors