HIStalk Interviews G. Cameron Deemer, CEO, DrFirst

G. Cameron “Cam” Deemer is CEO of DrFirst of Rockville, MD.

Tell me about yourself and the company.

I’ve been with the company for 21 years, as CEO for the last two and a half years. I started my career in the ministry, where I worked many years with churches in Arizona and did some time in Papua New Guinea working with Bible translation. I got into healthcare IT totally accidentally during the recession in 1992, when I came back to the US. I grew up here in the PBM industry. I worked for the old PCS Health Systems in Scottsdale and then building what eventually became Surescripts while I was at NDC Health. I have been with DrFirst ever since.

DrFirst is celebrating its 25th anniversary this year. It has been a really interesting ride. The company was originally founded to eliminate what I would call technology friction for the doctor. I was the first product manager for this little 30-person company when I came here. The CEO and founder, Jim Chen, sat down with me and said, “Look, Cam, you need to understand one thing. Here’s what I need you to do. I need you to make sure that DrFirst is number three in the e-prescribing space. That’s your target.”

I was like, “Why would you want to be number three?” He said, “Any industry always ends up with three players. I don’t care if we’re number one or two, I just want to be number three.” With that challenge, I started my career at DrFirst. 

We have developed a huge footprint over time. We are handling scripts for about 550,000 doctors a quarter. We provide the e-prescribing back end for 275 EHRs. We are actively engaging 6 million patients a week for various programs, most of them adherence related. We have always been an innovative company that is trying to solve what we think are the real, gritty problems in healthcare.

You said in a recent article that the pharmacist’s role in patient care was limited by the original design of the electronic prescribing network. Do you see that changing, particularly given the struggles of the drugstore chains?

When I joined PCS in 1992, the company was already experimenting with e-prescribing. They were doing some of the early seminal work of getting some doctors to use the system. I believe at the time that they were using email to send prescriptions to Walgreens, and then the pharmacist would pick it up from the email. In those days, there were a lot of early attempts to do e-prescribing in different ways and PCS wasn’t the only company involved. That was eventually all destroyed by a patent troll who went through the industry suing everybody. Then that industry had to reinvent itself. 

While that was all going on, PCS selected me to be their representative on the script task force at NCPDP when it was first put together. I was one of the three original co-chairs working on SCRIPT 1.0 and continued to be loosely involved with e-prescribing at PCS. I was thrilled to death when we announced the creation of RxHub in collaboration with ESI, Medco and PCS at the time. We built that system based on technology that already existed, the pharmacy claims switching technology. 

It made all the sense in the world. The PBMs had already transformed pharmacy, and healthcare IT around pharmacy, by fully digitizing the claims process. It worked great. We went from paper claims to terminals and then PC or mainframe-based transmission of claims through a central switch. It was great, so you can imagine that when they turned their attention to e-prescribing and said let’s digitize that, they had every belief they could do it. They had what they believed was the right technology, and they built it. 

When Surescripts saw what was happening, they decided they had to do the same thing and not let the PBMs cut them off from the doctors. So they also implemented e-prescribing based on claims switch technology, which I had been helping develop while I was at NDC Health. When I came to DrFirst, RxHub was already there. Surescripts was already there. DrFirst was working to get the doctors to adopt e-prescribing. None of us had any time to really think about it.

This just seemed like the right solution. It did what it was supposed to do. It let 600 participants on the EHR side talk to 600 participants on the pharmacy side and solved that many-to-many problem. It converted the prescription from writing into a digital format so it could be picked up on the other end and imported into systems. It accomplished its goals. 

We are 20 years down the road now, and it is just now that the cracks are starting to show, as people are saying, “This doesn’t quite work right. This isn’t quite what we need.” It has become a real cap on innovation in the industry, the way the e-prescribing network works. Fundamentally, the problem is that it’s a technology that was designed for pharmacy claims.

A pharmacy claim is a financial instrument. It’s a request for reimbursement from the pharmacy, an accounts receivable, essentially. It goes to a PBM, who runs it against a contract in the adjudication process and promises to pay. They send back an accounts payable transaction to the pharmacy so they can reconcile that to the accounts receivable that they sent forward. So it’s basically two participants, a pharmacy and a PBM. It’s based on a contract, and it’s a mathematical process. There’s nothing more to it than how it matches against the contract.

Prescriptions are totally different. A prescription is a clinical order, not a financial instrument. It is initially ordered by a highly trained clinician who has evaluated a patient, considered their current problem, their ongoing problems, their other treatments, and the other medications they’re taking and then making a decision based on what they know about that patient. Not just clinically, but also all the other factors, such as what they can afford and what they are willing to do.

Then they send that clinical order to another highly trained professional at the pharmacy, who would like to be able to evaluate that, add their thinking to it, and interact with the provider who wrote the script in case something needs to change. Eventually that’s filled by the pharmacist and the patient needs to pick it up, so the patient is another participant here who maybe doesn’t know whether their prior auth has been approved, whether it’s ready at the pharmacy, and how badly they really need it.

There’s a lot that the patient also has to think about through this process. There’s also pharma, who really, really, really wants the drug to be filled at the pharmacy once it’s written. And there’s of course the PBM, who’s interested in getting as clean a script that ideally matches what they’re trying to do with the patient as well. You have five key participants in this process, all trying to work around a transaction that is flowing through something that was designed for claims, and it just doesn’t work. 

The biggest failure point is that the script arrives at the pharmacy with no context. The pharmacist can’t really do their job, the job they’ve been trained for, because all they get is the digital version of the script. We’ve been taking a look at that for many years. It was the recent FTC settlement with Surescripts that opened the opportunity for other networks to enter the market, so we have introduced our version, which includes the ability to carry the extra data needed with the transaction to establish rule sets by which we can manage workflow issues.

For instance, some scripts get to a pharmacy that the pharmacist is never going to be able to fill, so they have to call the doctor to get clarification. We can handle that on the front end, just based on a rule that says if you get a script like this, ask the doctor to correct it in these ways before it actually goes pharmacy. It saves the doctor a phone call, saves the pharmacy a phone call, and the patient has access to therapy more quickly.

The solution is freeing up the clinical order to be a clinical order and to have everything it needs to be processed without a lot of friction at the pharmacy.

Early e-prescribing was done on a standalone PC or terminal. How has it progressed to integrate back into the EHR?

You raise a good point that initially e-prescribing was standalone. Now it’s fully integrated into the EHR. It’s just part of the standard EHR workflow. 

What’s been done over the last several years is bringing more of the information the doctor needs to make a decision into that system. One is real-time benefit check, where you’re doing a pre-adjudication of the script to give the doctor an idea of what the impact will be on the patient when they show up at the pharmacy and having to pay for that prescription. Also giving the doctor the same information on alternative drugs that would also be applicable under the therapeutic class so the doc can make a more informed decision based on plan design. That has helped people avoid prior authorizations, so that the doctor can see one drug that requires prior auth, so I’ll go with the one that doesn’t. Along those lines, information about the patient’s plan has been useful.

What’s coming now is more information about the prior authorization question sets that the doctor needs to answer ahead of time. The ability to grab that information from the EHR and send it along with the request for the PA so that you don’t have to have back-and-forth between the doctor and the PBM to get the PA approved. A lot of what’s happening now is pulling information into the doctor’s office that would avoid them having to have phone calls or electronic back-and-forth with pharmacies or PBMs.

How are you looking at AI?

We definitely don’t believe that just slapping a chatbot on top of our existing stuff counts as AI. We’re actually trying to take a much deeper approach to it and go at it from three levels.

Probably most important and foundationally, we’re trying to train every single person in DrFirst to be comfortable with the concepts of AI. Comfortable with interacting with it to help them develop individual visions around how AI can be used to automate processes at the company, as well as be incorporated into our products to improve workflow for other people. So we’re starting with our people first. We move it then into the feature set of our products to make workflow better for the folks who use what we do. In other words, it becomes a feature.

We are just now starting to work on an actual product that is completely AI based. For us, the most important applications of AI are practical. We’ve been using it, actually for quite a while, for interoperability solutions that are e-prescribing. We’ll continue to expand focusing on AI’s ability to help people get work done quicker with more information and fewer redos and stuff like that.

What kinds of medication-related engagement do patients want or need?

Some interesting things are happening right now. Consumer engagement is really hot in healthcare. It has been interesting to watch how that is expressing itself out in the wild. This is one of the areas that we’re intensely interested in, but I probably should have said this earlier. We like to think of ourselves as productively contrarian. It doesn’t matter to us so much what other models are being built right now. We are more interested in what’s the right way to handle the situation. 

If you think about what happens with patients today, there’s a lot of activity around patient choice of pharmacy. What if the script is written for a patient, and then for some reason, the patient wants to go to a different pharmacy? I’m going to be passing this pharmacy on the way home. I’d rather pick it up there, or I found that I can get a consumer card that would be cheaper at this pharmacy than that pharmacy. There’s a lot of talk of use cases like that that aren’t really all that interesting because they’re probably fairly rare based on how people tend to develop habits and how they pick their pharmacy in the first place. I usually think of that as trying to come up with a solution where there’s no problem.

But there are other more significant things. Patients who have important drugs that they need to receive, but the script has been written to the wrong pharmacy. For instance, a specialty drug that has a limited distribution network is sent to their regular retail pharmacy which may be reluctant to give it up, because if they can special order the drug, they can probably make a decent profit on it. But the patient’s going to have to wait much longer than they would if it just were going to the right pharmacy in the first place. Being able to alert the patient that the drug has been sent to a pharmacy that can’t fill it for them immediately is an issue.

Another example would be that the patient shows up at the pharmacy and the pharmacy says, “We don’t have that in stock. Give us until Wednesday and we’ll have it.” The patient may not want to wait till Wednesday and they need to have it filled at a different pharmacy if they can find one that does have it in stock. The ability to switch that script without having to rely on the pharmacy being willing to give it up, or a doctor being willing to rewrite the script to a different pharmacy, that’s all friction from the patient side.

You see a few different solutions in the industry. For instance, having the doctor write the script to a company that will then show the patient on an app that they’ve downloaded that a prescription has been written for them, then giving them a choice of pharmacies so the patient can pick a pharmacy. Another model might be to persuade the doctor to write the script to a non-dispensing pharmacy, which would then determine the best place for the patient to fill it and then reach out to the patient in different ways to give the patient the option of which pharmacy to use.

These solutions are pretty hot right now. There’s a lot of talk about those. But they suffer from the fact that they require everybody to be out of workflow. The doctor has to not use the default pharmacy, they have to write to a pharmacy that’s not actually going to fill the script, but it’s going to get the patient to fill the script. The patient has to download something and go through an extra step , where otherwise they would just show up at the pharmacy. The physician is out of the workflow and the patient is out of workflow. Typically the folks that are doing these kind of models struggle with volume, and no wonder since everybody’s being required to do something unusual.

Another dirty little secret is why, in the early days of e-prescribing, NCPDP picked this model instead of a more European model, where the script would go to the cloud, the patient would just show up at whatever pharmacy they wanted, and the pharmacy would pull it down from the cloud. That was actually considered in the early days of the SCRIPT standard, and it was promoted at the time by a representative from the University of Alabama.

I remember the meeting where this happened. Everybody else in the meeting disagreed with that approach because they were trying to solve for the adherence problem, that patients are given scripts and are then trusted to deliver that piece of paper to the pharmacy. That creates one more barrier for the patient actually getting the script filled. The pharmacist isn’t doing their job, the doctor’s not getting the results they want, and pharma certainly isn’t getting revenue from the drugs being filled.  So instead, they decided to have it sent to the pharmacy. That will set up an expectation in the patient. They need to go pick it up. It can create a little work for the pharmacist because if the patient doesn’t show up, they have to return it to stock, which is a pain in the neck. 

Nonetheless, it has worked really well. It did in fact improve adherence dramatically. Patients are much more used to picking up their drugs now than they used to be. When we go to a model where the patient becomes the delivery mechanism again, you’re just stepping back into the past to a time when compliance was happening at a lower rate. First-fill adherence was lower than it is today and patients weren’t getting on therapy. We believe the right way to do this is to keep it all in workflow. Let the doctor write the script and let the patient interact with the physician directly whenever the script can’t be filled for some reason. Don’t force the patient into making a selection if they don’t want to make a selection, because if they don’t make one, nothing happens. Make sure the script still gets to the pharmacy.

What will be most important to the company over the next two or three years?

Number one is that we are reinventing the e-prescribing platform. We’re going to give the industry what it deserves. Doing that is very important to us.

We are working to eliminate all the points of friction in the specialty drug workflow. That will become increasingly important with new developments in medicine.

Those are the two challenges we’re taking on right now.