Serious Weight Issues with BioTrack & Washington State Traceability
In Washington all marijuana producers and processors are required to report details about their business to the State. Some of this data includes weights. Washington State has, effectively, zero control or accuracy with the weights recorded in this system. The inconsistencies in the operation of this software points to an even larger problem: A core function of tracking this inventory, the weight, is not handled consistently or correctly.
In the BioTrack built web-application, these values can be input using a form that allows the user to select a unit of measure such as Grams or Ounces but, in the UI this is converted. Pounds and milligrams are converted to grams and ounces are kept as ounces. WTF.
The API provided by BioTrack allows the API calls to specify a unit of measure using: 'g', 'oz', 'mg', 'lb', 'each' notations. However, no conversion is executed on this. We've shown this to be true on Harvest and Modify executions where input of “1.815” in pounds is kept as “1.815” and not converted at the API level to the proper weight of “823.27015” grams.
The entire traceability system is falling apart if the weight values cannot be trusted to be accurate. The unit of measure is not stored in the database – this can be shown with a public records request and there is a web-viewable archive here: http://openthc.com/data/ If the unit of measure is not stored then it could be assumed that some conversion would happen before the data is stored – for example – convert everything to grams on storage. This business rule should be applied at a core level – not some logic that works in one UI but not in the API calls that claim the unit of measure is respected.
When this same data is pulled out of the system through the provided APIs, no unit of measure specifier is included, because the unit of measure is never stored. In short, one enters. “1.815 lb” into the system but later, when the data is returned it's still “1.815” but what unit? The critical data is lost. We can see the issues with this by simply looking at the data provided in public records access and looking a how improbable some weights are – 200000 grams of harvest from one plant? I don't think so.
In summary: the units are inconsistently converted, the units themselves are not stored and therefore not reported. This makes the data close to useless. It's for sure not usable for any accurate tracking of the inventory in this system. How did this software with such serious, core level bugs make it past the QA process? Is this a reflection of the quality of service we expect from our government?
Update – June 24th
After a few days of waiting for a response from the state vendor they have reported that they cannot duplicate the issue. We've run tests today (June 24th) and it appears now the issue is fixed – but for 100s of historical records the problem still exists.