Pharmacy organizations have fought against the MAC pricing rules of PBMs for years, but seemingly no one has ever tried to make these prices readily useable to pharmacists. Let's change that.
1. Automate the requesting of the MAC list on a weekly basis.
2. Automate the response back from excel --> a database.
3. layer an API on top of that, where it will automatically give you NADAC (proxy-acquisition) and slightly-outdated MAC (proxy-reimbursement). BOOM! transparency without asking anybody for permission or to be nice to you.
Put drug in, get a reasonable estimate out.
I feel that both the big wholesalers (they should use universally-compatible APIs) and PBM make it hard to price-discover intentionally and they will fight really hard to keep it this way.
(0.832 catalog files and other exotic files formats are really annoying to work with, that's why non-pharmacy wholesalers don't want to touch them. Everyone uses and likes APIs)
Side note: it's worth noting that *prescribers* can access pricing through real-time benefit tools (RTBTs, also called real time pharmacy benefit check tools).
So prescribers have more insight into a pharmacy's pricing than the pharmacy itself does.
Plus, this pricing reflects what phase of the deductible the patient is in.
Agreed, RTBTs don't have comprehensive info, and aren't used much by physicians. But as you say, "[t]here are probably even better technical solutions to this problem of MAC and U&C transparency than transmitting daily .832 files (such as Application Programming Interfaces....)." Might be worth considering whether the standard already adopted/implemented by PBMs to expose pricing (the NCPDP RTPB/RTPBC/RTBT standard) would be a better technical solution in some ways, no?
If you mean - why would a PBM transmit the list at all? regulatory compliance - a state law would require it.
If you mean - why an 832 over another method of transmitting price lists? I don't know - they apparently already do it in some cases with their purchaser clients (see linkedin post recently) so it's not a big technical lift?
832s, 835s, ... AWPs, MACs, AACs, blah, blah blah...these are various ways PBMs devised to make their work seem complicated & important, shock & awe, confuse & distract, to justify the outrageous fees they charge us.
What also infuriates me is all these discount cards stealing from us, as you mentioned, such as GoodRx. What gives them the right or power to jump in as middlemen and dictate to us saying we must give the customer this discounted price? I don't have a contract or an agreement with X-discount card. I don't accept these discount cards, I just give my customers our best cash price, but it still chaps me.
Ok - hear this out.
1. Automate the requesting of the MAC list on a weekly basis.
2. Automate the response back from excel --> a database.
3. layer an API on top of that, where it will automatically give you NADAC (proxy-acquisition) and slightly-outdated MAC (proxy-reimbursement). BOOM! transparency without asking anybody for permission or to be nice to you.
Put drug in, get a reasonable estimate out.
I feel that both the big wholesalers (they should use universally-compatible APIs) and PBM make it hard to price-discover intentionally and they will fight really hard to keep it this way.
(0.832 catalog files and other exotic files formats are really annoying to work with, that's why non-pharmacy wholesalers don't want to touch them. Everyone uses and likes APIs)
Side note: it's worth noting that *prescribers* can access pricing through real-time benefit tools (RTBTs, also called real time pharmacy benefit check tools).
So prescribers have more insight into a pharmacy's pricing than the pharmacy itself does.
Plus, this pricing reflects what phase of the deductible the patient is in.
Why not let pharmacies access RTBTs?
Love the thought, but in my experience, most RTBT is oversold in its capacities, and underused in its implementation.
Agreed, RTBTs don't have comprehensive info, and aren't used much by physicians. But as you say, "[t]here are probably even better technical solutions to this problem of MAC and U&C transparency than transmitting daily .832 files (such as Application Programming Interfaces....)." Might be worth considering whether the standard already adopted/implemented by PBMs to expose pricing (the NCPDP RTPB/RTPBC/RTBT standard) would be a better technical solution in some ways, no?
Benjamin, what's the incentive for PBMs to use 832s in this scenario?
If you mean - why would a PBM transmit the list at all? regulatory compliance - a state law would require it.
If you mean - why an 832 over another method of transmitting price lists? I don't know - they apparently already do it in some cases with their purchaser clients (see linkedin post recently) so it's not a big technical lift?
Okay, yeah, meant the former. Would have to be compliance because it ruins counter to their incentives otherwise
Great article! See also: https://coderxio.substack.com/p/modernizing-pharmacy-drug-procurement?r=ll9x&s=w&utm_campaign=post&utm_medium=web&utm_source=direct
832s, 835s, ... AWPs, MACs, AACs, blah, blah blah...these are various ways PBMs devised to make their work seem complicated & important, shock & awe, confuse & distract, to justify the outrageous fees they charge us.
What also infuriates me is all these discount cards stealing from us, as you mentioned, such as GoodRx. What gives them the right or power to jump in as middlemen and dictate to us saying we must give the customer this discounted price? I don't have a contract or an agreement with X-discount card. I don't accept these discount cards, I just give my customers our best cash price, but it still chaps me.