Information Systems:Pharmacist license validation issue

Overview

It's about time a wiki page was started for this issue.

In August 2016, it was discovered that there were a lot of narcotics orders being processed with an invalid or completely missing pharmacist license number. Querying order history files showed various patterns regarding pharmacist license number transmission, and it was quickly realized that this problem was multi-faceted and quite large in scope. This page attempts to log everything we know about this issue.

The discussion here is meant to be technical; if a more generic page becomes warranted, we'll cross that bridge... -norwizzle (talk))

Technical notes

Known facts

General

• The system (i.e. CNS,IOP) was designed to validate pharmacist numbers against the store number (customer number) only. CNS does have records linking individual users to their pharmacist license numbers, but the line-level checking in IOP and Web Orders checks against customer number only.
• Exempted codeine products brought this issue to light. This is a class of drugs that, by Health Canada regulations, requires the wholesaler to sell to pharmacies as if it were a narcotic, but allows the pharmacies to sell to the general public as an OTC/BTC product. This two-faced regulation is one of the main reasons this issue came to light and is also the cause of difficulties in the logistical processing/management of these products.

Kroll

• Orders for C/T (controlled/targeted) drugs are not transmitted with the pharmacist license number in Kroll. This is the reason benzos ordered through Kroll showed up in the query report.

• The N2 EDI segment where the pharmacist number should be is completely blank in the file for these orders. It is likely (but remains to be proven) that the presence of one of these C/T drugs in the order wipes out the N2 field (so the entire order is transmitted without the pharmacist license).

It was discovered that Kroll was aware of this in late 2014; it was a deliberate move to take it out of their code due to massive customer complaints that orders were being stopped due to issues with the pharmacist license number. This was before my time, there are few details regarding this.

Kroll is making an update to reverse this change, it will be implemented in V10 SP9, and will be made effective January 2017.

Web Orders

• Comments in the code suggest that attempts to checkout a web order containing a narcotic but without a pharmacist license number should throw an alert but can be bypassed and eventually processed. However, this was never implemented. Thus Web Orders does not allow placing an order with an invalid or missing pharmacist number.

• Web Orders stores the pharmacist license number along with the user account information in its own table (WSUSERP), separate from CNS. That is, there is a pharmacist number field in the users table.

• For an order containing a narcotic, Web Orders will use the pharmacist number associated with the user account (i.e. in the users table). If one is not present, it will use the one entered on the cart page prior to final checkout/order submission. If one is not entered, an error is thrown.

• There seems to be a glitch when Web Orders validates a manually entered number on the checkout/cart page (where it prompts you to enter a license number if one isn't associated with your user account and there is a narcotic in the order). According to IOPERRP (the log of IOP errors), we've received web orders that shouldn't have been allowed to be submitted in the first place due to a missing/invalid number. See section WSPHARMVAL below for a more detailed discussion.

WSPHARMVAL - Validation program

WSPHARMVAL is the black-box program responsible for validating pharmacist license numbers. It was made by Sheila circa 2010. This is the program that is called when IOP does its item-level checks (called by IOPEDT01), and the outcome of this routine is used to determine the error code, if any, for the OMS alert (either missing or invalid number). WSPHARMVAL is also called by Web Orders to check the manually inputted number in the cart checkout page (see Web Orders section above). This is a form validation check and will not allow the submission of the order if the response returned is "invalid".

The program is quite simple:

1. The program takes in both the pharmacist number and customer number as parameters.
2. The program first checks if the pharmacist number exists anywhere in CNS (as a PHAR# user data element).
3. If a record exists, the program then checks the CNS links (customer/vendor linkages) to see which store this pharmacist number is linked to.
4. If the store that the pharmacist number is linked to matches the customer number passed to the program, the program returns "Y" as a response (valid). Otherwise, it returns and "N".

Web Orders glitch

It is important to emphasize that the same program is used to validate pharmacist numbers during IOP checking and Web Orders checkout. The check in IOP only sends an error message; the order is not stopped. However, in Web Orders, this program is called as part of a form validation check, and the order cannot be submitted if the program returns an "N". Having said this, we're currently observing a glitch (as noted in the previous section) where a web order passes the Web Orders check but fails the IOP check. Recall that web orders are funneled through IOP as well, so pharmacist license numbers are actually validated twice for web orders. In the instances where there's a glitch, this suggests that the same validation produced two different results. This needs to be further investigated, but there have only been a handful of instances since August 2016.

The problem may lie in the retrieval of default values using smurfs ("USERINFO") and this HTML form field: <input type="text" name="IHPHAR" value="<field name=WSUSERP.USPH#>. It also could have something to do with WSPHARMVAL returning a "Y" if the pharmacist number (passed parameter) is blank. To be continued...