Someone has been submitting claims to PBMs pretending they are part of our pharmacy. We're not the only affected pharmacy. I want it to stop.
I do the claims reconciliation for our family pharmacy. This means that I match up records of claims submitted to pharmacy benefit managers (PBMs) with remittances from PBMs to ensure that we actually got paid for the services we rendered. One day about a year ago, while reconciling a paper check from a large PBM, I noticed that there were prescription numbers that were billed and then reversed that didn’t match with any record in our system. Our prescription numbers are sequential – If you get prescription 12345, the next prescription to come into the pharmacy will be number 12346, then 12347 and so on. So when I saw a prescription number 8718632 and another for prescription 8248691, I was very confused and concerned. In looking at the remittance more closely, I noticed that the NDC number of the drug and the member ID of the patient on the submitted claim did not match any records that we had in our database either of cardholder IDs or of NDCs in inventory. I informed the PBM and heard nothing back.
I’ve heard of similar situations happening with at least 4 other pharmacies across the country. All of them have noticed it on the same PBM’s remittance advice, as that PBM charges a fee to the pharmacy even when claims are reversed or even rejected.
In looking into this a little further, I discovered an interesting factoid. So far as I can tell, there is no identity verification or IP address of origin verification or public/private key validation of prescription claims (I’d be curious to know if this is also the case for X.12 837 medical claims). The claims are simply accepted based on the National Provider Identifier (NPI) listed on the claim. It is entirely possible for a pharmacy to submit a claim to a PBM with a different pharmacy’s NPI listed on the claim through a relatively simple process of editing the claim transmission manually. I regularly edit claim submissions manually for a variety of reasons – mainly to do with errors in coordination of benefits claims not accepting the data that the computer system generates from the primary claim. Through the same process, it’s possible to use a different NPI number than the pharmacy’s normal NPI. In fact, this process is even a usual practice and necessary for pharmacies which operate a long term care (LTC) pharmacy and a community pharmacy in the same building. In order to tell the PBM which contract to process the claim under (the LTC contract or the retail contract), the pharmacy will apply “overrides” to submit their LTC taxonomy NPI number or their retail taxonomy NPI depending on various rules in their system (generally – if patient is marked admitted to a long term care facility, submit LTC NPI, otherwise, submit retail NPI).
Unfortunately, this means that a malicious actor wishing to investigate the benefits for a given patient can submit a B1 claim transaction under an entirely different pharmacy’s NPI in order to determine the price point paid, to determine any prior authorizations needed, and do so on the other pharmacy’s dime (literally a dime, since that’s the typical cost of a B1/B2 transaction pair, or more if the PBM charges a fee per transaction – which was the case for me, which is how I discovered this odd discrepancy in my remittance advice - $1.12 in fees charged against our other claims payments). A particularly malicious actor could probably overwhelm a pharmacy with false claims submissions without submitting correlating B2 reversal transactions and then sic a PBM’s fraud investigator onto that pharmacy, potentially leading to the unsuspecting pharmacy being dismissed from a PBM network, allowing the bad actor to gain market share (maybe from a victim local competitor). This might be rather obvious if the PBM fraud investigator were smart, especially if the bad actor did not also modify the prescription number in the claim transaction (resulting in the claim submission being in sequence with the rest of the attacker’s prescription numbers).
I’ve heard of similar cases to mine popping up across the country. I’m really curious if I’m right that some bad actor is out there submitting claims posing as another pharmacy. I’m also curious how sloppy they were – claims submissions usually can contain a pay to address as well as an NPI, but those are only submitted if the PBM’s payer sheet allows them.
If I’m right, I believe that there is a fairly simple technical solution to this issue – encryption. Specifically public/private key pairs. Pharmacies could publish their public keys to the NCPDP resQ database, and then all claims submissions would have to be signed with the pharmacy’s private key. This would allow the receiving PBM to decrypt the claim and validate that the pharmacy that sent the claim was in fact the originator of the claim. If the claim was sent from another source than the actual pharmacy matching the NPI, when attempting to decrypt the claim, the PBM would simply have a garbled mess as the public key would not match the claim transmission.
On the other hand, while this is a fairly simple TECHNICAL solution, it is an entirely different matter from a business perspective. Here are some problems:
1) no software systems on either end of these transactions currently has the capability to encrypt/decrypt transactions
2) there is no registry of public keys currently (though NCPDP resQ would be the obvious location to host this)
3) any time a pharmacy underwent a software conversion, they would likely have to issue a new key pair.
4) a decent amount of current business processes of intermediaries are dependent on claims transmissions being sent in the clear. Evouchers/vouchers on demand, for example, as well as pre/post claim edits by switching companies would not work if claims were transmitted encrypted (particularly if they were encrypted with both the pharmacy’s private key and the PBM’s public key to ensure no intermediaries could read anything more than the message header’s routing instructions – i.e. the BIN/PCN/Group and pharmacy NPI).
5) The telecom standard itself, most likely, as well as pretty much every payer sheet would have to be reworked to allow/require encryption.
Now I presume that the actual data transmissions between pharmacy software companies, the switches and the PBMs do use secure protocols to ensure that a middleman hacker can’t just grab claims data in the clear in transit. I don’t actually have the technical chops to be able to validate that, but I can’t imagine that HIPAA and HITECH would allow for transmissions to be in the clear. (please correct me if I’m wrong!) But the fact remains that as far as I can tell there is no identity verification in the content of claims transmissions, not even IP address verification.
Comments