The Audacity to Audit Managed Regulatory Content Without Fear

“Audit.” It’s a scary word for many people.

The definition of “Audit” from the Oxford Dictionary does little to allay those fears:

Based on its primary definition, an audit does sound a bit scary, or at the very least like a concern or an annoyance. Is this letter from the taxman an audit notice? Even with nothing to hide, the sheer thought of gathering documentation is likely to increase the blood pressure of most (“Where’s that receipt again?” and “Was I really supposed to keep these receipts for 10 years?”).

Sphera’s Managed Regulatory Content clients have a much different perspective on the word. In fact, they believe it has a positive connotation to it. Let me explain what our “Audits” do and why we and our users love them.

But first, let me explain a little bit about who I am.

Elevator Talk: My Work, My Bio?

I manage an expert programming team at Sphera Solutions. When I meet new people and I tell them how I earn a living, I usually get a puzzled look, so I keep concrete examples at the ready so they can better understand.

I explain what a Safety Data Sheet and a Label are (Most people have been exposed to hazardous material labels at one time or another. Happily or not, most people have repainted rooms in their homes at one point or another). I tell them a simplified story: Our customers enter their chemical formulations into our system, they push a button and, presto, out comes an SDS or the Label that they are required to display on packaging to sell products in various markets. My team oversees the inputs and calculations—or “rules” as we like to say—and looks at various properties in formulations to ensure that a proper document is produced to help protect workers, consumers and the environment.

I usually compare the process to using software to fill out tax returns. You enter your data in, and then a document is created after some calculations are performed. You really need that document (the SDS, the Label or, in this example, the tax report), and software to help you with that because the last thing you want to do is do it all by hand. (This would technically be possible for a tax report, but not for an SDS and Labels given the number of formulations involved, languages issues, etc.) What’s more important than the calculations themselves is that the calculations are done properly. One mistake can be truly costly with regard to potential penalties, legal fees and injuries or environmental damage caused by exposure from a mislabeled or unidentified hazardous substance.

I’ve been doing this for almost two decades. Some people would argue that doing the same thing for two decades would get monotonous, but when I look at the road in front of us, I see a complicated regulatory landscape that keeps getting even more complex as the years go by. I see the Globally Harmonized System of Classification and Labelling of Chemicals (GHS); Registration, Evaluation, Authorisation and Restriction of Chemicals (REACH); and various other monuments of potential regulatory exposure for companies. And I think that if we wouldn’t have developed the “Audit” feature, we would have probably gone off the road at some point.

The Birth of the ‘Audit’

In the early days, people would refer to our software authoring rules as a “Black Box.” In a way that should have been enough as all you need is that final SDS and Label, right? Not really. The big issue is that laws require manufacturers or formulators to justify every output given on an SDS or a Label for the products sold. And this is a complicated request to meet. We used to be flooded with questions from our customers such as: “How come this product is classified as toxic by dermal contact?” or “Why is this product considered a skin irritant?”

With a complex formula that contains dozens of raw materials, being able to trace the data from the input stage to the final assessment would basically mean that we would have to get the proprietary formula from the client. It would also allow us to oversee the steps of how our code was used to generate the classification.

After doing that for many years, it became obvious that there had to be a better way.

This is where the “Audit” concept for our authoring suite was born. The idea was that, by following a simple framework, our rules would be able to justify and trace themselves. The framework needed to be simple to avoid having to do a different solution for every business requirement that our team was tasked with. It needed to provide something that a user with domain knowledge would intuitively understand and that could be provided to inspectors or auditors. After all, authorities can at any time request a detailed justification of the SDS or Label output, i.e., an audit.

The Components of our ‘Audit’ feature

To establish the hazards applicable to a finished product, data must be extracted from potentially hundreds of ingredients. This includes published regulatory classifications, toxicity test data and many other properties. To display a justification of each hazard applicable to a finished product in an understandable format could look like a daunting task at first glance.

But when substances are broken down, it suddenly looks much more manageable—and understandable. The key point is that it’s always possible to indicate that a data point originates from one or more other properties. Each of these other data points also originate from one or more properties. Eventually you will get down to an end-point property—typically a toxicity or physical property measurement or a published classification—that does not require further justification.

Here’s an example: Without getting too much into the regulatory details, we will assume that on an SDS intended for the European market we see these classifications for a material:

• Flammable liquid, Category 2
• Acute toxicity (dermal), Category 3

The flammability and dermal toxicity are two hazards that are independent of each other, so we can justify examining each of them separately. So why is our material classified as “Flammable liquid, Category 2”? The first obvious justification is because the material is liquid. The second justification is that it has a measured flash point and boiling points that are compatible with the regulatory boundaries defined for a Category 2 Flammable liquid. For a material to be Category 2 under GHS (and European Union classification, labeling and packaging of substances and mixtures [CLP]) its flash point need to be below 23°C (73.4°F) and its boiling point needs to be greater than 35°C (95°F):

So our audit could look like this:

Now let’s look at the most complicated Acute Toxicity (dermal), Category 3. Typically for a mixture, this will be calculated from its ingredients. Surely, if the mixture is hazardous by dermal contact, then one or more ingredients should also be hazardous by dermal contact. The calculation involves an intermediate called Acute Toxicity Estimate (ATE), so the first line of the justification refers to the ATE:

This still doesn’t tell the whole story, as we do not know the details of the ATE calculation. What was involved in the sum of [Concentration ingredient/ATE ingredient]? To know that, we must request its origins:

We now know that the calculation leading to a dermal classification involved two ingredients: trimethyl borate and strychnine. If we are interested in further details, we can expand their respective traces, which gives us the complete picture of our classification. From that, we see that each ingredient is associated with an ingredient ATE. For each ingredient the ATE is coming from an entered classification. The ATE are different because trimethyl borate is classified as Category 4 while strychnine is classified as Category 1.

With all this information, the acute toxicity dermal classification is fully justified. One could even think about reformulating if the dermal toxicity of the mixture is too high from a safety or marketing standpoint as strychnine is clearly identified as the lead offender. (Note that our next software release that we are working on has a feature called “LCID,” which is dedicated to finding the lead substances with even more ease for all mixtures entered into our software suite.)

The beauty of the Audit concept is that afterward our classification becomes yet another property, which can be used to justify something else. For example, any SDS author knows that the classification is a key piece of information that affects and dictates content of many subsections, such as Section 4 (First aid) and Section 5 (Firefighting measures). Our “Classification” audit can help justify each interpretative statement provided in these sections. We will use the output of Subsection 5.2 (Special hazards arising from the substance or mixture), which for the example used, consists of these statements:

Thanks to the Audit, we can confirm that these statements are all coming from our flammable classification:

Audit to the Rescue of Blurry Requirements

The example used focused on a relatively clear regulatory requirement. Audits are even more useful to explain processes relying on pragmatic assumptions—where a letter-of-the-law reading of the regulation cannot justify the output of a rule. My next blog post will focus on how Audits will be the key to justify the output of precautionary phrases based on EU guidance, a feature that we are currently implementing.

All of this, of course, proves my point: Audits don’t always have to be so scary after all!