It’s a recommendation – not a standard!

Experiences with GS1 Standards for Data Exchange in Germany for Healthcare Industry

Like your navigation system in the car warning you to stick to traffic regulations and not follow the instructions blindly, the same applies if you enter unknown territories in IT. In our MDM world I was asked to cross an “unknown territory”, namely doing GS1 GDSN compliant item data transformation for healthcare industry.

Starting with that it looked pretty straightforward: The data provided was CSV, the result expected GS1 XML item messages. The customer told me there’s a GS1 Germany “Healthcare Implementation Recommendation on Item Data Exchange”. Good, well documented area.

But stop: The document is based on version GS1 XML version 2.3. Version 2.3? That was issued in 2008 – meanwhile we’re five versions ahead at 2.8! Lucky I was – only a few uncritical attributes seemed to be missing. No problem, for such cases GDSN defines some kind of backdoor to the highly standardized data model, so called “attribute/value pairs” to transport individual data.

But stop again: Where is this attribute value pair structure described in the “Healthcare Implementation Recommendation”? Nowhere! So, no backdoor, no attributes – the customer dropped them from his data model mapping requirement list.

I continued mapping the data: Healthcare industry uses eCl@ss classification extensively to categorize products and add additional attributes. Categorization is ok – GDSN allows for lots of additional classifications. But again, more attributes to transport – having the missing attribute/value structure still in mind? The “Healthcare Implementation Recommendation” gives a helping hand, the solution described is creative: The GDSN “Classification Description” field is used to transport the eCl@ss attributes. As repeated structure. Defining a CSV usage style for this misused “Classification Description” attribute. What?

There are two comments on that: 1) My personal preference: We’re in a XML world – I don’t like mixing that up with CSV-style values. 2) The hard fact: GDSN validation rule 108 (“For each supported classification agency a GTIN may only have one classification code”) would disallow such item data to go into a GDSN pool.

Stop again: The customer required this eCl@ss data to be transported. That was put on the issue list – maybe the GDSN data pool provider de-activates validation rule 108 to get that data stored in the data pool…

Some first tests against a GDSN data pool with transformed single items showed another smaller problem: The recommendation does not define any date or timestamp related to the item. GDSN defines four mandatory dates and timestamps. Remained stuck again. However, this hurdle was taken pragmatically by adding some generated dates and timestamps, the date of transformation will do!

With the data model mapping done, the final step was assembling the item hierarchies. Another look into the “Healthcare Implementation Recommendation” explained that as “…Due to the fact there’s no hierarchy being built, the CIN should contain the base item and then the next higher level.” Did I say “What?” before? Think so! The GDSN standard defines item hierarchies always being set up top-down: Starting e.g. with a pallet and then “unpacking” the contained items until the base item is reached. With the recommendation implemented, the hierarchy is set up vice versa. A first test against a GDSN data pool resulted in weird error messages: It looked like no one on the pool provider side expected data suppliers to send hierarchies turned around.

Final stop for this blog post: I added the wrong hierarchy to the issue list where the eCl@ss problem already resided… this needs to be sorted out with the customer and GS1 as this blows pragmatic solutions. Keep posted for an update on this.

So, be careful, if the standard travel guide describes a bridge to be used, but your navigation system recommends using a rowing boat ferry where your car can be transported upside down easily.