PokitDok takes on Pharmacy Claims and Eligibility

After releasing three pharmacy APIs, the pharmacy team at PokitDok decided to take on the NCPDP telecommunication standard (hereafter just called NCPDP), the pharmacy industry standard for electronic transactions such as eligibility and claims.

In addition to filing claims, Pharmacies use NCPDP to gain information about their customers’ benefits, like whether a particular drug is covered on their plan or whether prior authorization is needed.  There is an NCPDP message called a “Predetermination of Benefits”, also called a D1, which is designed to transmit this kind of benefit information, but unfortunately we have not found anyone that supports it.  What pharmacies have to do to get this information is submit a claim (a B1 message) and quickly reverse it (a B2 message).  If the claim gets paid out, then clearly the drug was covered and the out-of-pocket cost is discovered.  Otherwise, if the claim is rejected, issues like prior authorization will surface in the rejection message. It’s a bit convoluted in a way that Tweedledee would appreciate, “Contrariwise, if it was so, it might be; and if it were so, it would be; but as it isn't, it ain't.” The pharmacy team at PokitDok set our first NCPDP goal to be sending and reversing a claim.


For a low-level protocol, NCPDP is fairly easy to work with. It is not, however, without its warts. Take, for instance, how it encodes dollars amounts. A price value of ten dollars is encoded using a signed overpunch as 100{, where the { tells us that the last digit is 0 and that the number is positive. This format originates from an IBM punch card code designed in 1928, which also makes an appearance in EBCDIC (a format we've written about before). It's strange that such an encoding is used in a format which is otherwise not so stingy with bytes. Another oddity is how NCPDP handles repeating field groups. It has not one, but two different ways of encoding these groups, each with its own logic.

Warts or not, PokitDok is in the business of simplifying healthcare, and as such the first thing that we did with this pharmacy spec was to model it with friendly JSON-like Python structures. Fortunately, much of what we have learned about eligibility and claims in another domain, namely X12, transferred to pharmacy. We wrote Python generators which take streams of raw NCPDP messages and yield cleaned-up segments. These segments can then be given to a modeler, which yields our friendly JSON-like models. This design has served us well with X12 and allows us to plow through messages while still maintaining flexibility and a small memory footprint.

Our modeler turns this eligibility request from the official telecommunications guide:

Screen Shot 2016-06-30 at 7.40.14 AM

(where \x1c, etc, is an unprintable character.)


Moreover, our models can be constructed using the friendly JSON-like format (in addition to the low-level protocol), validated against the NCPDP spec (and payer specific requirements as well), and then converted into the raw message, which is ready for transmission. This allows us to forget about NCPDP all together and focus on the data.

Writing to the spec is fine, but processing a real claim is the true test. To that end, our first real test used information from a PokitDok employee's prescription. All of our testing was able to be done from inside a simple, easy to use Python notebook.

We learned a lot attempting to file this claim. Different payers provided different error messages, some much clearer than others, so by bouncing around a couple of times we were able to quickly find the errors in our initial implementation. Our first claim, however, eventually hit a payer specific wall.

Soon after this test, one of our team members had his yearly physical. His doctor told him he needed to take an over-the-counter Vitamin D supplement. He had mentioned what we do at PokitDok to the doctor prior to the visit, so he only smiled when asked if there was any way to get a prescription for Vitamin D. Script in hand, we headed back to test. Using the information on our colleague’s insurance card and the new prescription, we formed our next claim.

Replacing certain PHI (personal health information) with variables, we sent this:

Excitingly, the claim was accepted:

The next thing to do was to reverse the claim, which also worked:

So the lessons learned and the wisdom gained in processing medical eligibility and claims was able to be transferred in large part to pharmacy.

About jaredcorduan

Ph.D. From Dartmouth in mathematical logic with a passion for all things Charleston.

View All Posts