Skip to main content

Version 5

eSDScom V5 covers safety data sheets for various legal areas in a product-based, enhancable structure.

Previous versions (SDScom, EuPhraC and ESCom)

The eSDScom Version 4 package was made for the European legal area. SDScom, EuPhraC and ESCom are predecessors and have been joined to form eSDScom.

How to get started?

Download the XML and phrase parts via the links above. A lot of implementation hints are written in the XML schema annotations. 

You might want to look at the eSDScom wiki pages for some high-level information, and if you come from ESCom, especially this page will help you to migrate. More resources are under Tools, and you can consult the FAQ below. If nothing does help, please send an email to info--at--esdscom.eu .

Frequently Asked Questions (FAQ)

The latest, of course. eSDScom usually provides two releases per year to keep up with legal changes and include user change requests. But we understand that not every company is ready to upgrade twice a year, thus there are long-term support (LTS) releases which are guaranteed to receive only legal changes that are implemented in a compatible fashion, so that changing the implementation is easy to upgrade and can still receive older files of the same LTS release.

eSDScom strives to cover all product-related data which is necessary in the chemical supply chain for regulatory reasons. It started with safety data sheets for the EU, now covers more regions and also product notifications. If you miss anything within this scope, open an issue on GitHub or or propose a phrase or send an email to info--at--esdscom.eu

eSDScom version numbers consist of three parts:

  1. part: The paradigm - Version 4 refers to a document-based approach, where one XML record covers exactly one safety data sheet. Version 5 extends this to a product-based approach where one XML record can cover multiple legal regions (thus multiple SDSs) for the same product to facilitate systems integration.
  2. part: The compatibility - If this version number part changes, then changes to earlier versions are not fully downwards compatible.
  3. part: The update - If this part is higher, it means that additions took place, compared to earlier versions with the same first two parts. (For Version 4, there sometmes was a forth part to indicate such updates while compatibility of changes in the third part was limited too.)

Yes, absolutely. Phrases and XML are developed to work together, but it is absolutely possible to use the phrases with other software systems, and you can use the XML schema with other phrases.

Absolutely. eSDScom proposes a phrase catalogue, but can be used with any phrase catalogue you have. Or with eSDScom phrases plus your catalogue, because phrases are identified by their catalogue ID and phrase ID. Or without any catalogue, because you can send the full text of phrases in one language.

When importing, your software can use the Phrase IDs if you share a catalogue with the SDS creator. Otherwise your software should maintain a mapping of other phrases to your phrases, so that they will be matched automatically if a phrase is mapped onced and then appears in an updated or different SDS.

Both parts are mapped and developed in sync. A software using the eSDScom phrase catalogue with the XML can offer just the phrases that make sense in the context that you are editing, and you are sure to have phrases for all data fields in the XML. 

No. Think of it as an alternative to entering safety data sheets manually. Import replaces the typing, and exporting data in eSDScom works just as exporting/printing it to a PDF file. All actions between that remain unchanged - you might just have more data from the data import than you would bother to enter manually.

eSDScom (both XML and the phrases in English and German) are free - no royalties, no obligations if you don't modify anything. 

More than a dozen software systems support SDScom or eSDScom, many of them since the SDBtransfer project (German), but many do not advertise this feature. Due to the variety of IT infrastructure, there is not just one solution, and there is no single solution that fits all software. IF your softwar supports XML as a technology, the task is to match the XML fields to internal data fields. Please consult with your software provider.

Yes to both. Regulations require product suppliers to send safety data sheets as human-readable documents. So currently, XML data improves quality and efficiency. It is good customer service and might be required in the procurement conditions of your customer, but will become sufficient/compliant (in Europe) only with the revision of REACH or at least the ECHA Guidance 

Please consult the Tools page.

Most standard XML tools (including free ones) support to load a “schema definition” and offer a simple user-firendly editor to create and fill an XML file. Because SDScom is structured like a safety data sheet, this is good enough for numerical data, but specialized software provides support for regulatory data, for phrase catalogues, and for consistent data on mixture ingredient data. Please consult your hazmat management or EHS or OSH software provider for eSDScom support.

The procurement conditions of your customer (especially in the automotive supply chain - might require you to send eSDScom data. Even if not, offer eSDScom to demonstrate innovation and your focus on efficiency. ou would not forward a Word file via fax, would you? And since eSDScom allows to submit additional info for example for European Poison Center Notifications (PCN), you also save communication and support effort with your customer.

It saves time on retyping - Service providers charge a three-figure amount per safety data sheet they enter. It also avoids errors from retyping when using supplier data. Potentially your system will have more info than you would retype manually, allowing you to implement additional checks on data quality, on acceptable classifications or storage classes, depending on your needs.