We presented SharedSDS publically for the first time at Hazmat 2015 in Sydney on 16 June. Afterwards, nine or ten people approached me with congratulations. One said it is a "brilliant" concept but most were favourably impressed if slightly less effusive! A few asked specific questions. I'll only deal with two here and save the others for subsequent blog posts.
Q: Can SharedSDS handle lots of very similar substances in a time-efficient way for the user?
A: Yes - two ways at the moment.
The "correct" way to do it is to take a complete substance and [Save as new] under the other name. Then you would go into the new substance and make any (presumably) minor changes and you would have an easily entered new substance with its own SDS - the components of which you would need to separately confirm.
The easy way but not necessarily the most rigorous is to tag some synonyms to appear in Section 1 as product names as well as in Section 3. That makes the SDS apply to all the products named. That may currently cause problems if you want to nominate a synonym-product as an ingredient in a mixture - it would appear as the substance not the synonym. To change that would require an enhancement ticket.
Both ways will also work for products which are themselves mixtures ... but the easy way should not really be used with mixtures if the ingredient proportions are different between similar products. Although, if you do take the easy way it might be valuable to document your reasons in a substance note so that future generations of maintainers can see why you took that path. In such a note it would be useful to draw a line invoking best practice at the time.
Q: Do we really need a SharedSDS Foundation?
A: Absolutely. For two reasons. Firstly, proprietary software has a proprietor to own and support it on behalf of shareholders. Open source software needs a Foundation to own and support it on behalf of the users. Users of open source software deserve nothing less.
The second reason we need a Foundation is that someone has to develop compelling cases for changing unsatisfactory regulations in the direction of world's best practice. The International Council of Chemical Associations (ICCA) has produced a set of model regulations for adoption by emerging jurisdictions which have no current chemical regulations. The different problem to be addressed by the Foundation is to identify and prioritise regulatory disharmony. This currently exists as genuine and distributed pain points. In the presentation I explained how that will happen relying on feedback from the SharedSDS database about actual differences.
At the moment everyone seems to assume the GHS will automatically lead to regulatory harmonisation. I don't think so. Within every jurisdiction in the world, the majority of the chemical industry is entirely local. Chemical industry associations are duty bound to operate on behalf of their majority membership. The cost of complying with actual change means local industry is usually opposed and their association must support that or lose their membership. Therefore there is an active association bias against change which translates into a political bias against regulatory change. The ICCA cannot force its member associations to operate against their member interests.
Now consider the multi-nationals. No single company no matter how big can afford to divert its attention to changing regulations everywhere. It is easier to pay the extra costs and pass them on. There is therefore no corporate imperative to improve things. There are more profitable things to do than battle local regulators.
The only lever for change is well argued business cases developed by the industry itself and targeted at industry itself. That is the Foundation's remit. Regulators will usually respond to their locally regulated industry if they want a change towards best-practice.
Next: The next blog post will address "Can I see the raw data for my supplier's products which are ingredients in my mixtures?" and there are more to come ...Share on Twitter Share on Facebook