HomePage

I Love Pharmacy Encounters!

by Daniel J. Dick
phone: 559-903-4694

---

Having worked for a great PBM, I have experienced the joy and challenges of working through many sticky issues creating Medicaid Pharmacy Encounters systems for health plans in several states.

From that experience, I quickly learned

1. Many people don't like developing encounters systems.
2. The ))Helter-Skelter(( School of Hard Knocks is attended by many.
3. Companies struggle to get encounters right.
4. State governments and their contractors often strugle for years.
5. Specifications are often wrong and sudden changes uncoordinated.
6. Errors can go undetected for months.
7. Mistakes can be extremely costly.
8. I thrive on challenges like this, and they can be solved!

Rush! Panic! Guess What! Did You Know We Are Supposed to be Doing Encounters?

Commercial PBMs can be buzzing along fine and suddenly become overwhelmed when they take on Medicaid business. It's easy for the sales folks who tell the world, "We can do anything". But, for the managers and individual contributors who are thrust into doing an entirely new line of work and must suddenly develop systems to deliver pharmacy encounters data to the state, the initial shock can be substantial followed by a sense of false peace and understanding only to be continued with an onslaught of written and unwritten requirements.

What Formate Are We Supposed to Use???

Formats differ from state to state, and although many states require encounters in the NCPDP 5.1 format, the state's don't generally used this specification in the same way.

See Info on State Requiements

Initially, it may seem the biggest challenge is here rather than far down the road. But, it isn't.

Airplanes and Parachutes - Building as we Fly!

If you are already receiving claims online, then creating pharmacy encounter systems can seem like building an airplane while you're flying it or jumping out of an airplane and creating the parachute on the way down. EDS made an excellent video advertisement using that analogy.

Initially, since claims are coming in, pharmacy encounter files are expected. Sometime later, the documentation may arrive, and some of it might be unambiguous. But, this is to be expected. Contractors for the states are also working the kinks out of their systems, too.

Once you have had a chance submit a test file and it passes, the state and/or health plan may want you to begin submitting production files immediately. Voila! You're in production.

If only it were that simple. The trouble is that getting into trouble is the easy part. Getting out of trouble may take months or years.

That's why many people hate pharmacy encounters, but I love challenges, and apparently pharmacy encounters are much simpler than medical encounters.

The Bait - On the Surface, Encounters Appear Trivial

At first glance, encounters appear easy. Assuming your database system has appropriate supporting tables, it may seem you can just create one big SQL join that collects all the matching data, formats it, and sticks it into a file and send it to the state. Piece of cake!

Believe it or not, the first encounters programs I ever saw actually looked something like this. Frightening, isn't it?

Voila! We Have Everything...Except...

Suppose a physician is missing. Or a pharmacy. Or a membership record. Heaven forbid that should happen. But, suppose your pharmacy system's adjudication system accepts claims from the pharmacy with physician DEA numbers but the state requires you to send NPI's. But you don't have an NPI for that physician.

What do you do?

Claim	Pharmacy NABP	Pharmacy NPI	Physician DEA	Physician NPI	Member ID	Drug NDC	Output
Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Yes	Yes	No	Yes	Yes	Yes	Yes	No
Yes	Yes	Yes	Yes	No	Yes	Yes	No
Yes	Yes	Yes	Yes	Yes	No	Yes	No
Yes	Yes	Yes	Yes	Yes	Yes	No	No

Or suppose you have two separate physician records for the same physician — one with a DEA and another with an NPI. If just one record is missing, the pharmacy encounter will go undetected.

One would expect if the Drug NDC and the Member ID were in place at time of adjudication, they would not go anywhere when the encounters are run. But, what if the encounters are on a different system, and what if the membership files get moved to the encounters system late, or a glitch takes place during the transfer? Or, what if a mother has a baby and the baby gets an alternate ID of his or her mother but then later is supposed to get a number of his or her own?

Or, suppose a physician has two records. Or suppose there is an institutional ID shared by ten physicians in the system. Now, the claim will end up being presented 10 times. Unless of course, there are 10 pharmacy records matching. Then you'll see the same claim 100 times.

Contortionist SQL - Backbreaking!

But, that's OK. It's nothing that can't be cured with a few contortions, outer joins, sub-queries selecting the maximum (or minimum?) ID. Right?



So, the queries grow longer and longer and become more error prone and susceptible to serious performance problems. But, that's nothing that can't be fixed with a few database hints. STOP ALREADY!!!

At best, we end up with a huge query pulling a huge amount of data into memory at once. If there is any sorting (ORDER BY) or grouping (GROUP BY) your DBA or system administration may soon be tapping you on the shoulder, or worse, killing your queries. But, then you did not really expect to get ALL your encounters through. Did you? Oh, you did???

Costly Mistakes

Suppose some of your claims are for blood products with GPIs starting with 12? What if a few hundred of those claims which get overlooked are $65,000 blood products and your company has paid the pharmacy for those drugs, and you cannot get reimbursed with reinsurance funds because you have not reported these Medicaid claims to the state? What if you are doing rate setting with the state and they think your costs are not so much? Or what if they slap you with a few million dollars in sanctions for bad reporting?

Well, most of these problems are sorted out up front in testing before going production. Right? Usually not. Most of the testing is there to make sure you have the right format.

Let's say your file passes testing with flying colors. But, your metric quantity is off by a factor of ten or a hundred or a thousand. And, you put through a number of claims for blood products costing $12,000 or $60,000, and they fit the criteria for reinsurance money from the state to cover the higher costs. But, the state thinks you've delivered only 1 tenth of one percent of the metric quantity you think you delivered. When do you find out? When they balk at paying you millions of dollars in reinsurance money.

Correcting Errors

And how do you correct errors? Do you send a void and replace? Do you have to provide a claim response number CRN or Internal Claim Number (ICN) or some claim number internal to the state? Can you submit "rebill" record which void and replace in one fell swoop?

And how can you read the errors back in from a variety of health plans that may send you so many different kinds of response files? Will you get an Excel spreadsheet, or a flat file or an Access database, or an NCPDP style response file? Will it come into your SFTP server or through secure email? Do you have a HIPAA approved way of transferring this personal health information (PHI) from one place to another?

The Eclipse of the SQL Join

Suppose you are producing encounters using this one big SQL join and a piece of the information is missing. Well, the SQL join may very well see there is no match and eclipse the data as though it did not exist. Suppose that's a claim for a $65,000 blood product and your company has paid the pharmacy for that drug and a big portion of that amount is up for reinsurance money. What if all the missing or held encounters result in underreporting to the state and its time for rate setting? What if pharmacy reversals and replacements come into your system and you send the replacement to the state before you send the void, or what if you send them in the right order but the state processes them in the wrong order. The replacement gets rejected as a duplicate and the original gets reversed.

Tracking Data Transfers and Ærorrs

And, how to track the business rules of fixing common errors — eligibility problems. I particularly like the error that says, "Date of Death prior to Date of Service". Zombies walking into drugstores and buying prescriptions? Typically this might happen if certain prescriptions are automatically delivered periodically and delivery is not stopped before the patient passes on. But there are errors for drugs not approved for the plan because that medication is covered by Medicare D and perhaps the claim should never have been adjudicated. Or maybe the drug is obsolete on date of service. And, what about time zone differences where claims end up being filed the day after they are processed by the PBM? It can make the PBM look like a fortune teller and cause the state to reject the claim.

Catywumpus - Changing Encounters Specifications

Suppose you process your claims twice per month, but the state or the health plan want you to deliver your encounters files weekly?

Or suppose the state pulls a switch on you and you have to deliver encounter records with NPI numbers for physicians when the claims came in with Medicaid numbers or DEA numbers or state license numbers? And what if a Medicaid ID is required but the physician or pharmacy is out of state? What if the claim comes in with an institutional ID and you have to deliver an ID specific to the physician?

Priorities - Me First, Me First!

And what if four health plans have problems that are driving them nuts and putting them at risk of sanctions and all want immediate attention? They want to reconcile to the invoice. In fact, they want to reconcile to their payables and their receivables. How? By period end? By date of service? What about pharmacy reversals and replacements? And how do you handle adjustments brought by pharmacy audits?

Add to this database performance issues, security issues, networking issues, management of development, test, and production environments, change control, disaster recovery, and there is a lot of work to be done.

These are the kinds of challenges I enjoy!

---