Information Systems:Pharmacist license validation issue

From uniWIKI
Jump to navigation Jump to search

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 the order history log showed various patterns regarding pharmacist license number transmission and order sources, 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 are really what brought this issue to light and they are responsible for half of the entries in the order error log. 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-specific issues

  • 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 and that it was actually 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.
  • (Dec. 9, 2016) Jeff at Medicine Chest reported that as of Dec. 2016, Yukon is implementing a Pharmanet-type system that the MC stores are piloting. This system was recently integrated into Kroll but is currently causing an issue: Kroll is reading the pharmacist IDs of the government system and using those as the license numbers. Thus, Kroll orders from Medicine Chest are generating error messages for all narcotic line items due to these erroneous numbers used as the pharmacist license. Kroll is working on a fix.

Web Orders-specific issues

  • 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.

Assyst-specific issues

  • Exempted codeine products are being ordered and managed via AssystPOS (vs. AssystRx). This makes sense for the store as these class of drugs are OTC/BTC products and thus are not tied to prescriptions. Tracie at Nanoose/Memorial stated that managing this class of product in AssystRx would make it a huge hassle, as well as remove the automation (auto-ordering) from the process.
  • Telus has confirmed that AssystPOS has no awareness of pharmacist license numbers (nor does it need to have), and that narcotics should indeed be ordered via AssystRx, where pharmacist numbers are submitted in the electronic order. For AssystPOS orders, the N2 EDI segment always has '00000'.
  • There are instances of license validation errors with AssystRx as well, where the field contains '00000', but this is nowhere near as prevalent as the errors generated from the ordering of codeine-exempt products through AssystPOS.

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...

Retrieved from "https://owl.unipharm.com/mediawiki/index.php?title=Information_Systems:Pharmacist_license_validation_issue&oldid=6117"