Repeated guidance by Washington State LCB reduces the ability of licensees to keep their reporting data accurate and makes it easier to game the system. Data visibility and reporting ability are reduced leading to increased burden on licensees and increased risk to consumers.

This guidance give more room for folks to work-around the reporting system; it provides zero-good and creates an environment for non-zero harm.

Background

They sent this email on Friday May 1. The intro/summary reads as follows:

This message is to provide clarity regarding a repeated LCB request for labs to provide the Lab Result (LR) code to licensees and third-party commercial integrators. Please note that the LR code is not the test results themselves but the unique software identifier connected to the lab record that is generated when a lab enters the test results.

To date we have verbally instructed labs and third-party integrators that this is not an approved practice as it undermines the integrity of the labs results.

And then, they have the real directive near the bottom.

In no way is the Certificate of Analysis or related system identifier (LR Code) to be used to apply results to other product or edit existing results.

There are additional notes in the email which will be quoted and addressed below.

Technical Background

In Washington State we use Akerna / LeafData software for the track-and-trace reporting system. In this system identifiers are created and managed including IN codes for Inventory Lots and LR codes for Lab Results.

When a licensee sends an IN type item to a laboratory they input results and create this LR type item. Additionally the IN item from the licensee is linked to this LR item in the system -- this linkage is visible in both the WebUI and API. When the material is converted or sold the LR linkage should remain intact -- this part works. This alows other licensees (eg Retailer) to verify the information and also transfer the details electronically.

There is another case, where materials get attested type lab results: WAATTESTE. This value indicates an assertion by a licensee that the material was tested -- however there is no data-linakge at all to lab results.

Occasionally LeafData will have an issue and Lab Results may need to be corrected. This occurs on some conversion failures, some incoming materials and when processing returns. If one knows the proper LR number, which you can lookup in the system, then you can make necessary corrections to keep the LCB reporting system accurate.

Materials in the system are required to be linked to some lab results before they can be sold. This is to maintain the integrity of the reporting sytem the LCB has put in place.

However, LeafData also allows the sale of material that is simply marked as "attested". In this scenario there is no data in system to point to for either LR or COA -- since those to items are linked. For these attested products there are no results linked in the system that were entered by a lab -- they depend on the licensees all agreeing that it's OK -- no way for them (or the LCB) to verify/cross-reference.

Directive

Labs should not share the **LR** code with licensees.

The system already exposes the value the LCB is trying to hide, the lab just cannot share it.

A Lab, who's entered the data into the reporting system and generated an identifer like *LR1234* cannot tell their client, or anyone, that the number is LR1234. If you look at the IN item that was sent to the lab, it will show the linkage to LR1234*. There is the data, right there, one click away, in the LCBs own system.

If a licensee calls a lab and asks "can you confirm the results on IN1111 are LR1234 with that COA?". The lab could say: "no, that's wrong". They would not be able to help you find the correct results.

A example using Twitter: I can't tell you who my followers are - it's not allowed. You can click to see my list of followers. So it's right here, we can both see it together!? Me: these are not followers you are looking for /waves jedi hand/

Why would the lab be restricted from sharing a data-value that is inevitebly discoverable and can be used for validation/verification?

Assertion #1

LR code is not the test results themselves but the unique software identifier connected to the lab record

The LR item in the system contains the lab result data, like THC and CBD which are required. These items can also have the COA directly associated with them. The use of LR item is enforced by the system to ensure that only tested products are sold.

The LR Code is linked to an IN number and metrics in LeafData, and also has the COA linked to it in their system. If you have the LR Code then you can get a copy of the COA -- a very handy ability when you want to verify your material is tested.

And, of course this LR code and metrics (THC/CBD) should of course match the CoA that is linked in the system.

When the system is working as intended there is a very tidy data-relationship between the IN, LR and COA items -- both in the database and in the physical universe.

Why claim they are not related when they these items are so clearly related and hard dependencies of the system? So direct that they are nearly the same thing in the LCB/LeafData system in the API and WebUI.

Asserttion #2

have been no business needs presented to overturn

Case #1 - Correcting LeafData Issues, Re-Linking Results

There are numerious occiaions where LeafData has incorrect lab result linkage. When one knows the LR then, many times, one can correct this mistake.

The business case of keeping your data accurate in the reporting system is not enough?

Case #2 - Cannot Verify Records sent with WAATESTE

The LCB has no method to verify if these WAATESTE type items have actually been tested or not. If all items were at least required to have a proper LR linked then the LCB would have some method of verification.

Also by shipping WAATESTE type items it's much easier to show any COA at all with the material. Since there is no other linked data, and no way to cross reference the COA to the LR presented by LeafData anyway.

Verifing product integrity in the reporting system is not a good case for sharing data-truth?

Case #3 - Identify mis-use / Abuse of Lab Results

If labs are allowed to confirm LR codes, then those legit LRs would be used in place of the bogus WAATTESTE values. And if one LR code was used too many times, or had some other anomalous pattern it could be detected.

The business case of reporting on abuse of the system is not enough? Isn't the LCB required to do this?

Case #4 - Product Saftey

By removing the ability to properly use LR as the technology intended, this drives folks to use WAATTESTE in the LCB system. Then leaving a large number of untrackable, un-reportable phantom data and has no way link to related product on these test results. The licensee will be breaking the linkage and are not permitted to repair it.

The business case of using LRs to identifiy groups of tainted product in a recall scenario is not enough?

Case #5 Second-Level Reporting of Licensees Own Data

When one can clearly and simply share the known-good-values then it's possible to have the state reporting system match with a licensees own records -- to the extent that LeafData can manage. It seems useful to have most of a licensees local records match the reporting system.

That is not business case enough?

Assertion #3

undermines the integrity of the labs results.

No. It's not possible for a licenee to manipulate the Lab Result data record -- with or without the LR (see back to #1).

Firstly, as shown above, the LR code is known/shared by the LCB system. If this code could be used to falsely manipulate these results then the code should not be shared EVER. If a licensee was able to update the data in an LR record that would be a serious data-integrity problem for their reporting engine.

Secondly, only Labs can manpiulate these records. If a licensee was able to update the data in an LR record that would be a serious data-integrity problem for their reporting engine.

If however, there could be an issue. A problem that has existed since at least July 2019. A problem that the prevous platform (BioTrack) did NOT have. A problem that could be solved with an update to their technology plaform. A problem that is being papered over with a flawed directive which works against the system currently in place.

Outcome

• Lost Ability to track mis-use / abuse of LR.
• Increased Usage of WAATTESTE type results
• Increased Paperwork Retention on Retail and Processor side.
• Increased Audit Burden on R-License and P-License in case of audit -- no back-stop data.
• Increased Risk to Consumer
• Decreased ability to track tainted product up-stream in case of recall.

These assertions by the LCB are internally inconsistent. They are built on mis-understanding of both real issues in the system, and perceived fixes for issues that never existed.

A Summary

The LCB/LeafData system is perfectly functional to use with IN to LR data-relationship. The LCB/LeafData system is known to block sales that require an LR so some value is needed. Sharing LR codes allows the LCB and all licensees to only ship product linked to a legit data record. If we cannot share LR to correct/repair data then we are forced to use entirely bogus WAATTESTE data. More use of WAATTESTE reduces data-visibility, reportability, verifiablity and normalizes bogus data. This increase in bogus data makes it easier to hide/fake results. Fake results increase danger to the general public.

A Solution

Fortunately the solution already exists, in LeafData system as it exists today. The LCB could/should simply take two easy steps.

• Backtrack on this guidance and allow interested parties to share true-data with each other (ie: LR values).
• Remove the ability for attested only materials to be sold which will further improve their data-reporting integrity.

Fixing the system would only harm folks who are not reporting properly.