GS1 Distribution and Shipping of Biologicals Guideline

1 Introduction – Guideline: ISBT and GS1

• 1.1 Introduction

Medical Product of Human Origin (MPHO), which uses the ISBT 128 standards, are increasingly being distributed through the general supply chain, where GS1 standards for logistics are widely used. It is necessary to provide guidance on how the two standards can complement each other. This document describes how to identify consignments of blood and other biologics from human origin with a GS1 SSCC, capture the information using the GS1 logistics label and share this information securely using EDI messages.

• 1.2 Purpose of this document

To provide guidance for the distribution of ISBT 128 labelled products through a supply chain using GS1 Standards. This will allow labellers and end-users to utilise the specialist information carried by the ISBT 128 data structures, and the supply chain intermediaries to use GS1 identifiers. This document also provides general information and specifications for data sharing via the GS1 XML message standard for the Despatch Advice message. Correct identification of MPHO consignments will allow these product’s barcodes to be read alongside other barcodes in the healthcare environment such as those on medical devices and patient wrist bands, thereby enabling Healthcare Professionals to significantly increase traceability and reduce the risk of adverse events.

• 1.3 Who will use this document?

Healthcare supply chain partners that encode/decode AIDC data carriers on products from the origin and supply of MPHO products to the point of care:

■ Blood Centres

■ Tissue Banks

■ Cellular Therapy Facilities

■ Hospitals and other sites of clinical application

■ Group purchasing organisations (GPO)

■ Software vendors

• 1.4 Definitions, abbreviations

■ Barcode: in this document barcode is meant to be either GS1-128 or GS1 DataMatrix

■ GLN: Global Location Number (see section A.2)

■ MPHO: Medical Product of Human Origin

■ SBDH: Standard Business Document Header

■ SSCC: Serial Shipping Container Code (see section 2.1)

• 1.5 References

■ ISBT 128 ST-001 Technical Specification

■ ISBT 128 ST-003 Labelling of Tissues

■ GS1 General Specifications

■ GS1 Functional User Guide – EDI Release 3.3

■ GS1 Guideline - Identification Keys in Transport and Logistics

■ GS1 Logistics Label Guideline

• 1.6 Business Scenario Overview

Organisations processing and labelling MPHO identify their products using ISBT 128 labels that identify the labelling organisation, standardised product type, serial (division) number, and unique donation identification number.

Distribution may occur through dedicated supply chains equipped to handle ISBT 128 labelling or may enter the more general supply chain where GS1 identification is the recognised standard. Prior to entering the general supply chain, the labeller identifies the consignment using a SSCC and may provide supporting information in a GS1 EDI Trade Message – Despatch Advice.

Receiving hospitals and other sites of clinical application record the GS1 information on receipt of the product and the ISBT 128 information is captured into the clinical records at the time of clinical application.

2 GS1 Identification

• 2.1 What is an SSCC

An individual Serial Shipping Container Code (SSCC) is a unique number, which remains the same for the life of the logistic unit to which it is assigned. When assigning an SSCC, the rule is that an individual SSCC number must not be reallocated within one year of the shipment date from the SSCC assignor to a trading partner. However, prevailing regulatory or industry organisation specific requirements may extend this period.

The Serial Shipping Container Code (SSCC) provides functionality to support the management (tracking, tracing, storage, etc.) of logistic units through the supply chain. To ensure global uniqueness and traceability, the physical builder of the logistic unit or the brand owner of the logistic unit is responsible for the allocation of the SSCC.

Figure 2‑1. Format of the SSCC element string



• 2.2 How to assign a SSCC identifier to a consignment

When a shipment of MPHO products is picked, the individual identifiers must be recorded in the shipping manifesto. The whole consignment is then allocated a globally unique identifier (SSCC) which is also recorded in the manifest, printed on the label in both human and machine-readable form and used as an identifier in the electronic despatch advice message send to the recipient using the respective EDI infrastructure.

The SSCC consists of the following components:

1. GS1 Application Identifier (AI) (00) indicates that the data field in the barcode symbol contains an SSCC (Serial Shipping Container Code). The SSCC is used to identify logistic units (see the GS1 General Specifications).
The AI(00) is not part of the SSCC itself, but 00 has to be encoded in the barcode symbol.

2. Extension digit A digit is used to increase the capacity of the serial reference within the SSCC. It is assigned by the company that constructs the SSCC. The extension digit ranges from 0-9.

3. GS1 Company Prefix Allocated by GS1 Member Organisations to the company that allocates the SSCC – here the physical builder or the brand owner of the logistic unit. It makes the SSCC unique worldwide but does not identify the origin of the unit.

4. Serial reference The structure and content of the serial reference is at the discretion of owner of the GS1 Company Prefix to uniquely identify each logistic unit.

5. Check digit Calculated using the modulo 10 algorithms (explained in the GS1 General Specifications)

The number should be stored and referenced in databases as a complete 18-digit number, right justified.

2.2.1 Allocating SSCCs sequentially

The following section details how to allocate Instrument Tray SSCCs sequentially from a GS1 Company Prefix.

Table 2‑1 Sequential allocation of SSCCs

3 E-Commerce Despatch Advice

• 3.1 Introduction

The GS1 XML Despatch Advice described in this section shall be created based on the received order during the packing of the delivery consignment. Once the full shipment information is completed, it should be sent via the agreed communication channel prior to the physical shipment.

The following guidance assumes an existing knowledge of the Despatch Advice structure and use. It explains how to incorporate ISBT 128 identifiers into the despatchAdviceLogisticsUnit element. A more detailed explanation can be found in chapter Despatch Advice Semantic Data.

• 3.2 Despatch Advice Semantic Data

The Despatch Advice mirrors the traditional paper delivery note. It details the contents of a delivery as well as the shipping details and makes cross references to the originating order sent by a data recipient. The data set for the Despatch Advice, compared to paper delivery note, is significantly reduced by using GS1 identifiers and by pre-aligning static data. The message includes only the necessary transactional data.

The Despatch Advice, in addition to detailing the actual items to be delivered, allows the supplier to inform the receiver on how the delivery will be configured, i.e., the number of boxes/pallets and the identification of each transport unit. This functionality is a desired goal to enable back door scanning.

3.2.1 The Despatch Advice data requirements are:

3.2.1.1 Header Level

■ Despatch Advice Number

■ Despatch Advice Date

■ Estimated Delivery Date

■ Cross reference to the originating Purchase Order Number (if the delivery relates to a single order – which is recommended)

■ Identification of the Supplier/Seller, also referred to as the “Shipper GLN”

■ Identification of the Buyer as detailed in the Purchase Order, also referred to as the “Receiver GLN”

■ Identification of the Delivery Point as detailed in the Purchase Order, also referred to as the “Ship To GLN”

3.2.1.1.1 Logistics

■ Logistics Unit Identification (SSCC)

■ Ultimate Consignee (GLN)

3.2.1.1.2 Detail Level

■ Line Item Number

■ Quantity Requested in the purchase order

■ Quantity Despatched to fulfil the order

■ Identification of the traded unit (GTIN) – product identification (for example for alignment via GDSN

■ Additional Trade Item Identification according to ICCBBA (as detailed above)

■ Batch Number - if applicable

■ Lot Number - if applicable

■ Serial Number - if applicable

■ Expiry Date - if applicable

■ Purchase Order – originating purchase order number

■ Purchase Order Line Number - originating purchase order line number

• 3.3 Despatch Advice Overview

The diagram illustrates the layout of the Despatch Advice which is to be found in chapter Sample Instance File below.



• 3.4 Implementation

This sections below describes the GS1 XML Instance, Standard Business Document Header and the Message Standards.

• 3.5 Message Structure Overview

<?xml version="1.0" encoding="UTF-8"?>

<despatch_advice:despatchAdviceMessage

xmlns:sh="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:despatch_advice="urn:gs1:ecom:despatch_advice:xsd:3"

xsi:schemaLocation="urn:gs1:ecom:despatch_advice:xsd:3

../Schemas/gs1/ecom/DespatchAdvice.xsd">

   <sh:StandardBusinessDocumentHeader>

 

     <!—SBDH CONTENT-->

  </sh:StandardBusinessDocumentHeader>

  <despatchAdvice>

 

     <!—DESPATCH ADVICE DOCUMENT CONTENT-->

  </despatchAdvice>

</despatch_advice:despatchAdviceMessage>

• 3.6 Standard Business Document Header (SBDH)

This specification uses the Standard Business Document Header (SBDH) which enables integration of documents between internal applications, enterprise applications, and business-to-business infrastructure by providing a consistent interface between applications. The standard header can provide semantic information needed for the routing, processing and business domain context of documents, regardless of the data format of the document – XML, classic EDI or another format.

The SBDH schema is specified by UN/CEFACT and used by GS1 to envelope the business documents such as the Despatch Advice message. GS1 has specified additional constraints to those in the UN/CEFACT schema when being used in the GS1 XML context. Local GS1 Member Organisations, such as GS1 Ireland, have further specified additional constraints and values for use in supply chain messaging.

Note: For further information about the SBDH, please refer to:

- GS1 Standard Business Document Header (SBDH),

- Technical Implementation Guide, Version 1.3, Issue 3, July 2012

3.6.1 SBDH Requirements

The SBDH is a critical part of the GS1 XML message transaction. The SBDH provides references to the standards used, and data that manages the overall process and information exchange (the payload).

GS1 has defaulted values and has made recommendations about the usage of selected elements of the SBDH. Your data recipient may have also made user definable recommendations appropriate for their processing needs.

The SBDH data requirements are:

Requirement	Value
Version number of the SBDH as published by UN/CEFACT	“1.0”
Sender	GLN of the message Sender (recommended) Alternatively, the sending party’s name can be entered (not recommended)
Receiver	GLN of the message Receiver (recommended) Alternatively, the sending party’s name can be entered (not recommended)
Document Identification: Standard	“GS1”
Document Identification: Version	“3.3”
Document Identification: Instance Identifier	A unique reference for the entire message
Document Identification: Type	“despatchAdvice”
Document Identification: Multi-type	“false”
Creation Date and Time	Date and time of the document
Business Scope: Type	Optional see below
Business Scope: Instance	Optional see below

 

Business Scope Type and Instance Usage

The Business Scope allows users to indicate the message’s functional status. Whether it is “Live” or “Test”. For some data recipients there may be a third status: “QAS”, meaning the message is in a Quality Assurance stage. QAS is a stage between Test and Live. It is critical to route a message correctly according to the appropriate status. The receiver of a message is informed of the message status and how to process the message based on this status.

Also, the Business Scope allows users to reference a schema (message format) that supports a specific business process. The schema details the message data requirements needed to execute the specific transaction. There may be more than one business process associated with the “Ordering Process”. For example, orders for normal deliveries, orders for cross-docking or orders for consignment products. Therefore, there may be different schema required with additional information.

The recommend format for the SBDH

<sh:StandardBusinessDocumentHeader>

  <sh:HeaderVersion>1.0</sh:HeaderVersion>

  <sh:Sender>

    <sh:Identifier Authority="GS1">5391234567892</sh:Identifier>

    <sh:ContactInformation>

      <!--this group of attributes is optional, details can be found in the sample file in the Appendix -->

    </sh:ContactInformation>

  </sh:Sender>

  <sh:Receiver>

    <sh:Identifier Authority="GS1">5391234567885</sh:Identifier>

    <sh:ContactInformation>

      <!--this group of attributes is optional, details can be found in the sample file in the Appendix -->

    </sh:ContactInformation>

    </sh:Receiver>

    <sh:DocumentIdentification>

      <sh:Standard>GS1</sh:Standard>

      <sh:TypeVersion>3.3</sh:TypeVersion>

      <sh:InstanceIdentifier>10001a</sh:InstanceIdentifier>

      <sh:Type>despatchAdvice</sh:Type>

      <sh:MultipleType>false</sh:MultipleType>

      <sh:CreationDateAndTime>2019-02-18T09:18:47Z</sh:CreationDateAndTime>

  </sh:DocumentIdentification>

  <sh:BusinessScope>

      <!--this group of attributes may be relevant to distinguish between Live and Test messages. It is only applicable if the business requirements demand this section and the IT systems are capable of handling different environments on the same communication channel!
      Details can be found in the sample file in the Appendix -->

  </sh:BusinessScope>

</sh:StandardBusinessDocumentHeader>

 

 

 

 

 

• 3.7 Despatch Advice Message Content

The table below details the message content of a Despatch Advice that will be processed by data recipients.

The table shows the requirements, guidance and the XML DD which can be used to reference the instance file following the table.

 

Requirements	Guidance	XML DD
Header
Despatch Advice Date	The date the despatch advice has been issued (mandatory)	creationDateTime
Status of the Despatch Advice	“ORIGINAL”, “ADDITIONAL_TRANSMISSION” or “COPY” (mandatory)	documentStatusCode
Despatch Advice Identification	A unique number assigned to the despatch advice by the seller/supplier (mandatory)	despatchAdviceIdentification entityIdentification
Identification of the Receiver	GLN of the Buyer / data recipient (recommended)	receiver gln
	Optional address & contact information consisting of relevant attributes	receiver address and/or contact
Identification of the Shipper	GLN of the Shipper may be the same as the seller (recommended)	shipper gln
	Optional address & contact information consisting of relevant attributes	shipper address and/or contact
Identification of the Ship To point	GLN of the delivery point as detailed in the Order Message Delivery Point (recommended)	shipTo gln
	Optional address & contact information consisting of relevant attributes	shipTo address and/or contact
Identification of the Ship From point	Optional information of the Ship From as above (GLN, Address & Contact)	shipFrom gln address and/or contact
Identification of the Carrier	Optional information of the carrier as above (GLN, Address & Contact)	carrier gln address and/or contact
Estimated delivery Date/Time	The date/time on which the delivery will be made at the recipient (recommended)	despatchInformation estimatedDeliveryDateTime
Estimated delivery Period	The period in which the delivery can be expected (optional alternative to the above)	despatchInformation estimatedDeliveryPeriod beginDate beginTime endDate endTime
Cross reference to the originating Order Identification	The Purchase Order number that originated the transaction. This number may be omitted if different orders are referenced. Use the line reference below to detail referenced order numbers (Conditional mandatory)	purchaseOrder entityIdentification
Each Logistics Unit may be identified and its contents detailed below using the nested structure. This may be repeated multiple times for all multiple logistics units.		despatchAdviceLogisticUnit
Identification of the Logistic Unit	The SSCC is used to identify the Logistics Unit. (recommended)	logisticUnitIdentification sscc
Ultimate Customer	This is intended to indicate the party that will ultimately receive the goods. It may be a patient or doctor (Optional)	ultimateConsignee gln address contact
Detail – the line detail can be repeated multiple times		despatchAdviceLineItem
Line number	Line number of the Despatch Advice (mandatory)	lineItemNumber
Despatched Quantity	Quantity despatched with unit of measure code based on UN/ECE Recommendation 20 Revision 6 Code list values (mandatory)	despatchedQuantity codeListVersion="UN/ECE Recommendation 20–revision 6" measurementUnitCode="EA"
Requested Quantity	Quantity ordered with unit of measure code based on UNECE Recommendation 20 Revision 6 Code list values If split quantities are used the value must equal total of the split values (optional)	requestedQuantity measurementUnitCode "EA" codeListVersion="UN/ECE Recommendation 20 revision 6"
Identification of the item	GTIN of the ordered Item. Must be the GTIN of the aligned trade item. (recommended)	transactionalTradeItem gtin
Additional Trade Item Identification	In addition to the recommended GTIN or instead of it (not recommended) Mandatory for ISBT 128 compliance	transactionalTradeItem additionalTradeItemIdentification additionalTradeItemIdentificationTypeCode="ICCBBA"
Trade item description	Free text field with respective language code of the description (optional)	transactionalTradeItem tradeItemDescription languageCode="en"
Batch number	If applicable, the Batch Number for the items may be detailed	transactionalItemData batchNumber
Expiry Date	If applicable the expiry date for the items may be detailed	transactionalItemData itemExpirationDate
Lot number	If applicable, the Lot Number for the items may be detailed	transactionalItemData lotNumber
Serial Number	If applicable, the serial number(s) for the items may be detailed	transactionalItemData serialNumber
Purchase Order Reference	Cross reference to the Purchase Order. This number must be the same at the PO number in the header above, if detailed there. (mandatory)	lineItemNumber purchaseOrder entityIdentification
Purchase Order Line Number	Cross referenced to the Line number in the Purchase Order (mandatory)	lineItemNumber purchaseOrder lineItemNumber

• 3.8 Message Design Rules

The GS1 XML messages contain embedded design rules that optimise the messaging process and ensure consistent implementation. These notes are added to provide detailed clarifications that have arisen during development and testing and reflect the business processes determined by the users.

1. A “Copy” of an “Original” Despatch Advice may be sent to confirm a previous transmitted Despatch Advice.

2. Where quantities are referenced, they are qualified by a code indicating the Unit of Measures, i.e., Pack, Each, Grams, Kilograms, Litres. The Codes to represent these qualifiers are detailed in UNECE Recommendation 20 Version 6.

3. Each message uses a line number “lineItemNumber” that is unique for each line. This is used to uniquely identify the line and may be cross-referenced in subsequent messages (e.g. Order, Receiving Advice and Invoice). Typically, it is numerically sequential
(1, 2, 3, …) and is often generated by the application software.

4. It is critical to ensure that the identification of the item is aligned, and the trade item status is defined for that item, i.e., that status is defined as the order unit. For fixed measure items, the qualifiers can be misinterpreted due to the different perspectives of packaging and implementation in software applications.

5. Where prices and monetary amounts are stated, they are qualified by the reference currency based on ISO 4217 “EUR = Euro, USD = US Dollar, GBP = Sterling”.

6. It has been agreed to provide cross references between the messages, for example, a cross reference from the ASN (Despatch Advice) to the originating Purchase Order subject the following detailed rules.

Rule a: The originating referenced message is detailed in the header along with the message date. The line number of the originating message is also detailed in the line detail of the message along with originating referenced message number, message date and line number.

Rule b: If there is more than one of the same message type, e.g., Purchase Order referenced in a message then:

- The referenced messages details are omitted from the header (Rule 1) and

- The line reference detail includes the message number, message date and line number in the detailed section for each referenced message.

Rule c: Multiple referenced message types and instances will require multiple cross references for each referenced instance.

3.8.1 ISBT 128 specifics on detail level

The despatchAdviceLogisticsUnit element is a repeating element that is identified by the logisticsUnitIdentification. For each logistic unit in the consignment the SSCC located on the logistic unit is used to identify the corresponding despatchAdviceLogisticsUnit.



Figure 3‑1 Schema Structure for LogisticUnitType

Within the despatchAdviceLogisticUnit element a repeating element of despatchAdviceLine occurs. This carries information on each individual product type in the logistic unit. Typically, these items are identified in the transactionalTradeItem element using a GTIN. However, the message structure does permit the use of an alternative transactionalTradeItem identifier.



Figure 3‑2 Schema Structure for transactionalTradeItem

 

3.8.1.1 AdditionalTradeItemIdentification element

The additionalTradeItemIdentification element has two associated attributes, the additionalTradeitemidentificationTypeCode and the codeListVersion.

the additionalTradeItemIdentificationTypeCode attribute shall be set to “ICCBBA”. This value corresponds to an entry in the GS1 GDD Code List. The codeListVersion is not required.

The additionalTradeItemIdentification shall be populated with a data string comprising the following three elements:

Element	Description	Example
FIN(P)	Identification of the organisation processing/Labelling the product	A9999
FPC	Facility-defined Product Code	000037
PDC	Internationally standardised Product Description Code	T0122

Using the above examples, the additionalTradeItemIdentification would be:

<additionalTradeItemIdentification additionalTradeItemIdentificationTypeCode="ICCBBA">A9999000037T0122</additionalTradeItemIdentification>

This data content shall be derived from the ISBT 128 label information in one of the following ways:

3.8.1.1.1 Method 1

If the product label carries an ISBT 128 Processor Product Identification Code (PPIC – Data Structure 034) these three elements shall be taken directly from the PPIC data structure.

e.g.

PPIC data: =/A9999000037T0122

DIN data: =A99971812345600

AdditionalTradeItemIdentification: A9999000037T0122

3.8.1.1.2 Method 2

If the product label carries an ISBT 128 Processing Facility Information Code (PFIC – Data Structure 033) the FIN(P) and FPC shall be taken directly from this data structure and the PDC shall be the first five characters from the Product Code PC (Data Structure 003)

e.g.

PFIC data: &+A9999000003

DIN data: =A99971812345600

PC data: =<T0122001

AdditionalTradeItemIdentification: A9999000003T0122

3.8.1.1.3 Method 3

Where the ISBT 128 label does not carry either a PPIC or a PFIC the data elements shall be derived as follows:

   FIN(P) shall be the first five characters of the DIN (Data Structure 001)

   FPC shall be set to six zeros

   PDC shall be the first five characters from the Product Code PC (Data Structure 003)

e.g.

DIN data: =A99971812345600

PC data: =<T0122001

AdditionalTradeItemIdentification: A9997000000T0122

3.8.1.2 Other Elements

Other elements within the tranactionalTradeItem/transactionalItemData element may be populated and where these relate to ISBT 128 information the following associations are recommended:

Element	ISBT 128
transactionalItemData/batchNumber	Donation Identification Number (The first 13 data characters from the DIN (Data Structure 001)
transactionalItemData/serialNumber	Division Number EITHER the two- or three-character division identifier from the Product Code (Data Structure 003) OR the six-character division identifier from the Product Divisions (Data Structure 032)
transactionalItemData/itemExpirationDate	Expiration Date

3.8.1.3 Example

The following example show a segment of the despatch advice message for a logistic unit containing a single MPHO product labelled with ISBT 128. It illustrates how the ISBT 128 information is incorporated into the transactionalTradeItem.

The product is an aortic heart valve categorised by the ISBT 128 Product Description Code T0122 (VALVE,AORTIC|Cryopreserved) and with an additional Facility-defined Product Code (FPC) of “000037”. The processor/labeller is identified by the ICCBBA Facility identification Number of A9999. The product is identified with a Donation identification Number of A999918123456, and a division code of 001 and has an expiration date of 31 Aug 2019.

<despatchAdviceLineItem>

   <lineItemNumber>1</lineItemNumber>

   <despatchedQuantity measurementUnitCode="PCE" codeListVersion="UN/ECE

Recommendation 20–revision 6">1</despatchedQuantity>

   <transactionalTradeItem>

     <additionalTradeItemIdentification additionalTradeItemIdentificationTypeCode="ICCBBA">A9999000037T0122</additionalTradeItemIdentification>

     <transactionalItemData>

      <itemExpirationDate>2019-08-31</itemExpirationDate>

      <batchNumber>A999918123456</batchNumber>

      <serialNumber>001</serialNumber>

    </transactionalItemData>

  </transactionalTradeItem>

</despatchAdviceLineItem>

 

 

 

 

A Overview of ISBT 128 and GS1 standards

• A.1 Overview of GS1 Standards

The GS1 System is an integrated system of global standards that provides for accurate identification and communication of information regarding products, assets, services and locations. It is the most implemented supply chain standards system in the world (GS1 Website: www.gs1.org).

The GS1 System is the foundation of a wide range of efficiency-building supply chain applications and solutions. Based on GS1 Identification Keys, a common recurring set of identification keys, the GS1 System is composed of four key product areas:

■ Global data and application standards for bar codes that use the globally recognised GS1 Identification Keys to automatically identify things such as trade items, locations, logistic units, and assets.

■ Global standards for electronic business messaging that allow rapid, efficient and accurate automatic electronic transmission of agreed business data between trading partners. Based on two components: GS1 EANCOM and GS1 XML.

■ The Global Data Synchronisation Network™ (GDSN™) is an automated, standards-based, global environment that enables secure and continuous data synchronisation, allowing all partners to have consistent item data in their systems at the same time. Global Product Classification (GPC) is a key component of GDSN, enabling effective category management.

■ A new global standards system that combines RFID (radio frequency identification) technology, existing communications network infrastructure and the Electronic Product Code (a number for uniquely identifying an item) to enable immediate and automatic identification and tracking of an item through the whole supply chain globally, resulting in improved efficiency and visibility of the supply chain.

• A.2 GS1 Identifiers

Global Trade Item Numbers

Global Trade Item Numbers (GTIN) are assigned to any item (product or service) that may be priced, or ordered, or invoiced at any point in any supply chain. The GTIN is then used to retrieve pre-defined information about the item. The key benefit is that information about the item can be retrieved about the product from the GTIN whether it is read in a GS1 Barcode symbol, exchanged via a GS1 eCom message or accessed from the GDSN™

Global Location Numbers

Global Location Numbers (GLN) are used to identify physical locations and legal entities where is a need to retrieve pre-defined information to improve the efficiency of communication with the Supply-Chain. Global Location Numbers are a prerequisite for GS1 eCom message or to access information from the GDSN™.

Serial Shipping Container Code

The Serial Shipping Container Code is the GS1 Identification Key for an item of any composition established for transport and/or storage which needs to be managed through the supply chain. The SSCC is assigned for the life time of the transport item and is a mandatory element on the GS1 Logistics Label using Application Identifier (00).

GS1 and the SSCC and Despatch Advice GS1 XML standards

GS1 develops and maintains global standards for business communication to improve the efficiency and visibility of supply and demand chains internationally. The GS1 system of standards is the most widely used supply chain standard system in the world and encompasses automatic identification of products; locations; parties; assets; logistic units; document types; and service relations.
GS1 also develops and maintains Electronic Data Interchange (EDI) standards such as EANCOM and GS1 XML for the efficient data sharing within the supply chains.

ICCBBA and GS1 are both neutral not-for-profit organisations. ICCBBA is a nongovernmental organisation in official relations with the World Health Organization.

A Memorandum of Understanding has been in place between ICCBBA and GS1 since 2007 and the organisations acknowledge the important roles played by their respective standards in supporting safe and efficient practices in healthcare. They work together to ensure compatibility between their standards, and well-defined interfaces.

• A.3 ICCBBA And the ISBT 128 Information Standard

ICCBBA develops and maintains the ISBT 128 global standard for the coding and labelling of Medical Products of Human Origin (MPHO). This standard was introduced in 1994 and is in widespread use internationally. ISBT 128 has been specifically designed to meet the special traceability requirements of MPHO (see section A7 of this appendix). GS1 and ICCBBA recommend that products that contain an MPHO should be identified using the ISBT 128 Standard.

Distribution of many of these MPHO products has traditionally been carried out along dedicated distribution paths, for example direct blood service to hospital blood bank supply line. However, the use of a more general supply chain is required for products such as some human tissue products.

• A.4 Managing ISBT 128 Labelled Products in a Supply Chain using GS1 Standards

Implementation Procedures

Implementation procedures refer to both GS1 and ISBT 128 Standards. The business scenario is best addressed by a combination of ISBT 128 and GS1 coding.

This guideline is built on the assumption that the user has access to the appropriate documentation from both standards organisations. Therefore, the guideline is limited to essentials for users and implementers, who are invited to consult ISBT 128 Standard Technical Specification and GS1 General Specifications in their latest versions.

Note: For assistance with the GS1 General Specification please contact your local GS1 Member Organisation. In addition, they will be able to provide you with further information on all GS1 standards. Full details can be found on: http://www.gs1.org/contact/worldwide.php

Note: For assistance with ISBT 128 standard, consult www.iccbba.org or contact iccbba@iccbba.org.

The GS1 Key used in this implementation is the Serial Shipping Container Code (SSCC). The SSCC is used to identify logistic units. A logistic unit is an item of any composition established for transport and/or storage that needs to be managed through the supply chain. The SSCC is used in the supply chain to easily identify logistics shipping units consisting of multiple products, enabling quick and easy identification, tracking of deliveries and receipt of goods. This key is used with a data carrier for AIDC and in electronic commerce (eCom). In addition, the SSCC acts as a consignment identifier in the GS1 EDI trade message Despatch Advice. This message carries full details of a despatch load including details of the constituent elements at the consignment and individual product type level. This allows shippers to identify constituents of a consignment without having to encode long detailed consignment information on individual logistic unit labels.

The ISBT 128 Identifiers used in this implementation are the Donation Identification Number (DIN), Product Description Code (PDC), Processor Identifier (FIN(P)) and Division Number (DIV). Together these elements uniquely identify an individual MPHO graft and provide the necessary traceability links to the donor and processor. An additional element, the Facility-defined product Code (FPC) provides additional product characterisation assigned at the processor level and is included to support inventory management. These identifiers are used with a data carrier for AIDC. They can also be used in electronic messages and are assigned ISO/IEC Object Identifiers (OIDs).

Traceability

Traceability requires the trading partners to base their processes on common product identification and other keys, which are used in their processes for internal and external traceability.

Electronic Commerce

EDI Trade Messages support business processes by providing mechanisms to allow organisations to communicate trade information in a seamless manner. GS1 provides a comprehensive range of trade messages covering all aspects of the trade relationship. The Despatch Advice is one such message that carries information about a shipment and all the items it contains.

• A.5 Labelling Medical Products of Human Origin

Primary Labelling

MPHO should be labelled using the ISBT 128 system as described in the ISBT 128 Standard. Key identifiers included in the ISBT 128 information include:

■ Donation Identification Number (DIN) – Identifier of the donation event that provides traceability back to the donor. Contains the Facility Identification Number (FIN) of the organisation issuing the DIN;

■ Product Description Code (PDC) – A code that identifies the type of product according to ISBT 128 international terminology

■ Division Code (DIV) – An identifier that uniquely identifies each item carrying a specific DIN and PDC;

■ Processor Identifier (FIN(P)) – Identifier of the organisation responsible for processing and Labelling the product (may be the same as the organisation assigning the DIN and therefore correspond to the FIN);

■ OPTIONAL Facility-defined Product Code (FPC) – a processor defined element to provide additional granularity to product descriptions to support inventory management.

• A.6 SSCC Aggregated/Nested Logistic Units

Logistic units may be aggregated or nested into other logistic units for part of the journey to the final destination. For example, parcels may be combined onto pallets. In that case the SSCC of the higher logistic unit may be used to track and trace the contained logistic units. GS1 EDI and EPCIS support the electronic communication of such aggregations or nestings by enabling to specify links between the child SSCCs and parent SSCC.

When dealing with aggregated/nested logistic units in AIDC applications, the following rules apply to ensure correct identification of the higher logistic unit:

■ Only the barcode of the higher logistic unit SHOULD be readable. The barcodes of the lower level logistic units should be obscured or otherwise prevented from being read (e.g., by instructing those scanning through a standard operating procedure).

■ When using EPC/RFID tags, the filter value used for the higher logistic unit SHALL be different from the filter value used for the lower logistic units.

Note (informative): See the GS1 Logistics Label Guideline^[1] for examples of the way to deal with nested/aggregated logistic units. Appendix

• A.7 Traceability of Medical Products of Human Origin (MPHO)

Medical Products of Human Origin (MPHO)

The term Medical Product of Human Origin (MPHO) embraces all products donated by a human donor with the specific intent of clinical application to a human recipient. MPHO are biologic products and can transmit disease. Enhanced traceability, with specific reference to traceability to the donor, is essential in the investigation and prevention of disease transmission.

Examples of MPHO include but are not limited to: blood and blood products; organs; bone; ligament; skin; heart valve; cornea; hematopoietic stem/progenitor cells; demineralised bone products; milk; faecal microbiota; and semen or other reproductive tissue.

MPHO may be provided by living donors or from deceased donors through advanced directives and/or by the consent of grieving family members. Blood Centres, tissue banks, eye banks and cellular therapy laboratories carefully handle these products from the time of donation and recovery to distribution. It is important that the same level of care is maintained throughout the supply chain to the moment of implant, transplant, infusion, or transfer to a human recipient.

Traceability using GS1 GTINs

The hierarchy model for traditional supply chain goods can be represented as a sequence of one to many relationships with the product manufacturer as the highest element in the chain. Thus, a manufacturer will make multiple products each uniquely identified within the organisation by a product number (catalogue number, identifying a product class) and Global Trade Item Number (GS1 GTIN). Each product will typically be produced in batches identified by a batch or lot number. In situations where serialisation is required, each item will carry its own serial number, which together with the GTIN identifies that item uniquely (product instance).



Good manufacturing practice, supported by effective regulation, controls the manufacturing process and ensures segregation between product classes and their respective batches. Therefore, when product recall or follow up is required it is almost exclusively contained within one of the grouping levels of the model. Most commonly this occurs at the batch/lot level, or the product level.

Traceability using ISBT 128

In the case of MPHO, the hierarchy model is different because most recall/follow up events are associated with a specific donor. A single donor may provide MPHO donations on one or many occasions, to more than one MPHO processor. The donated MPHO will be distributed across multiple product lines. In some special cases MPHO from different donors may be pooled to produce a single end product. Good laboratory practice and supporting regulation/standards ensures appropriate segregation between MPHO from different donors.

The highest element in the hierarchy is therefore the MPHO donor. Subsequent levels include the identification of the donation event, the processor, and the product/catalogue number of the individual products prepared together with serialisation where required.



Recall and follow up activities are generally associated with a specific MPHO donor. A donor related recall may require identification of all the MPHO associated with the single donor. This will often comprise specific items under a wide range of product lines from different organisations (organ procurement organisation, eye banks and tissue processors). For example, one donor may donate solid organs (kidney, liver), corneas, skin, heart valves and vessels, bone (further processed to a range of products including shaped grafts, and demineralised bone), and tendons. This range of products spreads across multiple regulatory paradigms (organs, medical devices, biologics) but needs to be traced and recalled in an efficient and seamless manner.

The ISBT 128 Standard is specifically designed to address these special traceability requirements and is widely accepted by scientific and professional societies for the coding and labelling of MPHO.

• A.8 Managing ISBT 128 Labelled Products in a Supply Chain using GS1 Standards - Implementation Guide

Introduction to the full DESPATCH ADVICE message

This specification is for those wishing to trade electronically with their trading partners using e-Commerce and to comply with recognised best practice for supply chain management. The GS1 e-Commerce supply chain management solution is end-to-end.

■ Data about products are aligned between the supplier and the receiver prior to trading

■ Orders are electronically generated and transmitted to suppliers

■ Suppliers electronically communicate shipping data in advance to receivers

■ After the goods have been received the receiver electronically acknowledges receipt of the delivery

■ Finally, the supplier generates the Invoice

Payments are made as per the existing processes.

The receiver uses GS1 Global Standards for identification, barcodes and e-Commerce. The GS1 Standards are globally, the most widely used supply chain standards for e-Commerce.

For future details about GS1 and the GS1 Global Standards, please link to websites below

www.gs1.org

or contact your local GS1 Office

Purpose of this Section

This document explains how the electronic messages are implemented for a “Goods for Stock” process. This document specifically describes the syntax and semantic data elements of the GS1 XML Despatch Advice message (version 3.3) and is sometimes referred to as Advanced Shipping Notice or ASN.

The link below provides full access to all the GS1 XML 3.0 standards and other technical support documentation.

https://www.gs1.org/standards/gs1-xml/3-3

Business Set-Up

It is recommended that the supplier should:

1. Agree with the recipient the products included in the e-Commerce process.

2. Set-up the IT applications to import/export the required messages. This will require appropriate e-Commerce software or the services of a GS1 Certified solution provider.

3. Establish the network connection. Depending on the above (3), the following options are possible:

a. Value Added Network,

b. Internet AS1/AS2 secure solution or

c. a secure service provided by the chosen solution provider.

4. Implement the messages as per these guidelines for data mapping. It is recommended each message be validated prior to transmission. Validation can be performed by using validation software tools such as Altova XML Spy. Local GS1 Member Organisations, such as GS1 Ireland will also perform independent validations, if requested.

5. Complete a series of message tests with the data recipient using their test environments. Your solution provider may also provide test environments.

6. Complete an end to end quality assurance test to the satisfaction of your trading partner.

7. Go-live

Global Location Numbers (GLNs) are used to identify the precise companies and organisational entities involved in the end to end processing. It is necessary to ensure that they are correctly implemented in each message. The Purchase Order message will communicate the GLN of who has ordered the items and the GLN of precisely where the goods are to be delivered to.

Some trading partners are happy to accept multiple despatch advices for the same order, but they may not accept multiple orders referenced in the same despatch advice.

Business Rules

The following Business Rules will apply and will be embedded in the messages.

■ There may be more than one Invoice per Purchase Order

■ There may be multiple deliveries per Order therefore there will be an ASN (Despatch Advice) for each delivery.

■ There will be one Receiving Advice per ASN (Despatch Advice)

■ An Invoice can cross reference to one or more Purchase Orders, ASNs and each associated Receiving Advice.

B Barcode Symbols and Labelling

• B.1 Barcodes for use with an SSCC

The following section outlines the barcode symbol types that shall be used to encode the SSCC.

Note: Some scanning systems may be able to handle 2D barcodes as well as 1D barcodes. In these environments, 2D symbols may be used in addition to linear symbols.

A barcode consists of the barcode symbol, also known as data carrier, and the associated and encoded data value of the identification key printed in the so called Human Readable Interpretation (HRI) below or next to the symbol.

A data carrier is a means of representing data in machine readable form. Data carriers that are endorsed by GS1 and are suitable for the ISBT 128 are described below in sections B.2 and B.4.

Further information can be found in the GS1 General Specifications

• B.2 GS1-128

The GS1-128 barcode is a subset of the Code 128 barcode symbology. Its use is exclusively licenced to GS1 and supports GS1 system data structures, including Function 1 Symbol Character (FNC1). This extremely flexible symbology encodes element strings using GS1 Application Identifiers, in this case AI(00) for a SSCC.

Figure 3.8‑1. GS1-128 barcode



• B.3 GS1 DataMatrix

Data Matrix ISO version ECC 200 is the only version that supports GS1 system data structures, including Function 1 Symbol Character (FNC1). This extremely flexible symbology encodes element strings using GS1 Application Identifiers, in this case AI(00) for a SSCC.

Implementation of GS1 DataMatrix SHALL be done per approved GS1 system application standards, such as those for regulated healthcare retail consumer trade items.

Figure B.5.1‑1 GS1 DataMatrix barcode



• B.4 Symbol Size and Quality Specifications

The table to be used to specify the dimensions, sizes and qualities of the barcode symbols referenced in these guidelines is “Symbol specification table 5 – logistic units scanned in general distribution” in the GS1 General Specifications.

• B.5 Labelling Specifications

B.5.1 Introduction

This section gives a general overview of how to create logistics labels.

Using logistics labels to track pallets and other logistic units is an effective and essential part of supply chain management. Within the label, the SSCC is a unique serial number that is used to identify each individual pallet or other logistic unit.
GS1 logistics labels enable you to present information in a standard format that is recognised internationally. It uses GS1-128 barcodes to represent the SSCC for a logistic unit as well as certain types of information about the contents of a logistics unit.
These labels can also be used on any units that are transported between companies. For example, part pallets, individual traded units, or consignment of blood containers.

Note: Full details on the recommended best practice for Logistics Labels can be found in the GS1 Logistics Label Guideline. This guideline provides an overview of the normative rules and best practice recommendations based on GS1 Logistics Label implementations around the world.

Note: What does a GS1 compliant logistic label look like? A multilingual webtool helps visualising this http://www.gs1-labelview.at/front.php

B.5.2 Labelling of Consignments

In order to support transfer of ISBT 128 labelled products through the supply chain groups of items or individual items can be brought together as a logistic unit and identified using a SSCC (Serial Shipping Container Code). The SSCC shall be allocated in accordance with the GS1 General Specifications as described above.

B.5.3 Label Size

Any label may be used as required, the GS1 General Specifications do not specify a standard size.

According to the GS1 Logistics Label Guideline, the physical dimensions of the label are determined by the labeller, but the size of the label should be consistent with the data requirements for the label.
Factors influencing label dimensions include;

■ the amount of data required,

■ the content and

■ X-dimension of the barcodes used, and

■ the dimensions of the logistic unit to be labelled.

The business requirements for most users of GS1 Logistics Labels are met by using one of following;

■ Compact labels:
A6 (105 mm x 148 mm) or 4 x 6 inch, which is particularly suitable when only the SSCC, or the SSCC and limited additional data, is encoded. Applied for example on case label


■ Large label:
A5 (148 mm x 210 mm) or 6 x 8 inch, suitable when additional data such as trade item data are needed. Applied for example on pallet label


B.5.4 Label Location

Two labels should be attached to adjacent sides; one short side and the other on the long right hand side.

For units taller than 1,000 mm, place the label so that the barcodes are no higher than 800 mm and no lower than 400 mm above the floor.



For units lower than 1,000 mm, place the label as high as possible but make sure that the barcodes are no higher than 800 mm and no lower than 32 mm from the base of the unit.



The edge of a barcode (including the light margins) should also be no closer than 50 mm to a vertical edge of the logistics unit

Note that the transport container may be identified as such with a Global Returnable Asset Identifier (GRAI). This identification captures the (empty) container for inventory or maintenance processes. SSCC is to be attached to the container as above for traceability purposes.

C Sample Instance File – Assumed Minimum

D Extended Sample File

• D.1 Remark

The below sample file contains all mandatory and optional attributes that GS1 assumed to be relevant on required prior to an actual requirement gathering.

<?xml version="1.0" encoding="UTF-8"?>

<!-- Sample Dispatch Advice for ISBT 128 application -->

<despatch_advice:despatchAdviceMessage xmlns:sh="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:despatch_advice="urn:gs1:ecom:despatch_advice:xsd:3" xsi:schemaLocation="urn:gs1:ecom:despatch_advice:xsd:3 ../Schemas/gs1/ecom/DespatchAdvice.xsd">

<sh:StandardBusinessDocumentHeader>

<sh:HeaderVersion>1.0</sh:HeaderVersion>

<sh:Sender>

<sh:Identifier Authority="GS1">5391234567892</sh:Identifier>

<sh:ContactInformation>

<!--this group of attributes is optional -->

<sh:Contact>John Smith</sh:Contact>

<sh:EmailAddress>John@MyCompany.ie</sh:EmailAddress>

<sh:FaxNumber>011234546</sh:FaxNumber>

<sh:TelephoneNumber>011234567</sh:TelephoneNumber>

<sh:ContactTypeIdentifier>Blood Sender</sh:ContactTypeIdentifier>

</sh:ContactInformation>

</sh:Sender>

<sh:Receiver>

<sh:Identifier Authority="GS1">5391234567885</sh:Identifier>

<sh:ContactInformation>

<!--this group of attributes is Optional-->

<sh:Contact>Jane Smith</sh:Contact>

<sh:EmailAddress>Jane@yourCompany.ie</sh:EmailAddress>

<sh:FaxNumber>04021234554</sh:FaxNumber>

<sh:TelephoneNumber>04021234550</sh:TelephoneNumber>

<sh:ContactTypeIdentifier>Customer Support</sh:ContactTypeIdentifier>

</sh:ContactInformation>

</sh:Receiver>

<sh:DocumentIdentification>

<sh:Standard>GS1</sh:Standard>

<sh:TypeVersion>3.3</sh:TypeVersion>

<sh:InstanceIdentifier>10001a</sh:InstanceIdentifier>

<sh:Type>despatchAdvice</sh:Type>

<sh:MultipleType>false</sh:MultipleType>

<sh:CreationDateAndTime>2019-02-18T09:18:47Z</sh:CreationDateAndTime>

</sh:DocumentIdentification>

<sh:BusinessScope>

<!--this group of attributes may be relevant to distinguish between Live and Test messages. It is only applicable if the business requirements demand this section and the IT systems are capable of handling different environments on the same communication channel! -->

<sh:Scope>

<sh:Type>MESSAGE_STATUS</sh:Type>

<sh:InstanceIdentifier>LIVE</sh:InstanceIdentifier>

</sh:Scope>

<sh:Scope>

<sh:Type>SCHEMA_GUIDE</sh:Type>

<sh:InstanceIdentifier>ISBT 128_Identification and barcoding specification_Rel_1.0</sh:InstanceIdentifier>

</sh:Scope>

</sh:BusinessScope>

</sh:StandardBusinessDocumentHeader>

<despatchAdvice>

<creationDateTime>2019-02-18T09:18:47Z</creationDateTime>

<documentStatusCode>ORIGINAL</documentStatusCode>

<despatchAdviceIdentification>

<entityIdentification>0000000001</entityIdentification>

<!-- this can be any unique ID consisting of characters and digits -->

</despatchAdviceIdentification>

<receiver>

<gln>5391234567885</gln>

<address> <!-- This is optional and should only appear if a GLN is not available-->

<city>Dublin 4</city>

<countryCode>IE</countryCode>

<countyCode>D4</countyCode>

<name>Jane Smith Hospital</name>

<postalCode>D04KF62</postalCode>

<streetAddressOne>2nd Floor, The Merrion Centre</streetAddressOne>

<streetAddressTwo>Nutley Lane, Donnybrook</streetAddressTwo>

</address>

</receiver>

<shipper>

<gln>5391234567892</gln>

<address> <!-- This is optional and should only appear if a GLN is not available-->

<city>Greystones</city>

<countryCode>IE</countryCode>

<countyCode>Wicklow</countyCode>

<name>John Smith &amp; Co.</name>

<postalCode>A63RW51</postalCode>

<streetAddressOne>175 Church Lane</streetAddressOne>

<streetAddressTwo>Killincarrig, County Wicklow</streetAddressTwo>

</address>

</shipper>

<shipTo>

<gln>5391234567878</gln>

<address> <!-- This is optional and should only appear if a GLN is not available-->

<city>Delgany</city>

<countryCode>IE</countryCode>

<countyCode>Wicklow</countyCode>

<name>John Doe PLC</name>

<postalCode>A63RW51</postalCode>

<streetAddressOne>Higher Tower, 38 THe Tower</streetAddressOne>

<streetAddressTwo>Delgany, Killincarrig, County Wicklow</streetAddressTwo>

</address>

</shipTo>

<shipFrom>

<gln>5391234567861</gln>

<address> <!-- This is optional and should only appear if a GLN is not available-->

<city>Arklow</city>

<countryCode>IE</countryCode>

<countyCode>Wicklow</countyCode>

<name>Jane Doe Inc.</name>

<postalCode>Y14 P200</postalCode>

<streetAddressOne>ABERCORN HALL</streetAddressOne>

<streetAddressTwo>Ferrybank</streetAddressTwo>

</address>

</shipFrom>

<despatchInformation>

<estimatedDeliveryDateTime>2019-02-28T12:00:00Z</estimatedDeliveryDateTime>

<!-- it is recommended to use either the "estimatedDeliveryDateTime" or the "estimatedDeliveryPeriod" -->

<estimatedDeliveryPeriod>

<beginDate>2019-02-25</beginDate>

<beginTime>09:00:00</beginTime>

<endDate>2019-02-28</endDate>

<endTime>17:30:00</endTime>

</estimatedDeliveryPeriod>

</despatchInformation>

<purchaseOrder> <!--- May be omitted if different orders are referenced on line level below -->

<entityIdentification>Order number XYZ 123</entityIdentification>

</purchaseOrder>

<despatchAdviceLogisticUnit>

<logisticUnitIdentification>

<sscc>053912340000000016</sscc>

</logisticUnitIdentification>

<ultimateConsignee>

<gln>5399876543212</gln>

<address> <!-- This is optional and should only appear if a GLN is not available or detailed enough-->

<city>Dublin</city>

<countryCode>IE</countryCode>

<countyCode>Dublin 24</countyCode>

<name>Tallaght University Hospital</name>

<postalCode>D24 NR0A</postalCode>

<streetAddressOne>Tallaght</streetAddressOne>

</address>

<contact> <!-- This is optional and should only appear if a GLN is not detailed enough-->

<contactTypeCode>Patient</contactTypeCode>

<personName>Joseph Maria O'Patient</personName>

</contact>

</ultimateConsignee>

<despatchAdviceLineItem> <!--This whole group needs to be repeated for each item in the Delivery-->

<lineItemNumber>1</lineItemNumber>

<despatchedQuantity measurementUnitCode="EA" codeListVersion="UN/ECE Recommendation 20–revision 6">20</despatchedQuantity>

<requestedQuantity measurementUnitCode="EA" codeListVersion="UN/ECE Recommendation 20–revision 6">30</requestedQuantity>

<!-- the "requestedQuantity" is optional if all ordered items are delivered -->

<transactionalTradeItem>

<gtin>05391521130006</gtin> <!-- although this is an optional attribute it is Best Practice used in multiple sectors -->

<additionalTradeItemIdentification additionalTradeItemIdentificationTypeCode="ICCBBA">A9999000037T0122</additionalTradeItemIdentification>

<transactionalItemData>

<batchNumber>A999918123456</batchNumber>

<itemExpirationDate>2019-08-31</itemExpirationDate>

<lotNumber>ABC123-2019-02-</lotNumber>

<serialNumber>001</serialNumber>

</transactionalItemData>

</transactionalTradeItem>

<purchaseOrder>

<entityIdentification>PO number ABC123</entityIdentification>

<lineItemNumber>16</lineItemNumber>

</purchaseOrder>

</despatchAdviceLineItem>

<despatchAdviceLineItem> <!--This whole group is repeated for demonstration purposes-->

<lineItemNumber>2</lineItemNumber>

<despatchedQuantity measurementUnitCode="EA" codeListVersion="UN/ECE Recommendation 20–revision 6">30</despatchedQuantity>

<transactionalTradeItem>

<gtin>05391521130013</gtin> <!-- although this is an optional attribute it is Best Practice used in multiple sectors -->

<additionalTradeItemIdentification additionalTradeItemIdentificationTypeCode="ICCBBA">W0000123456T0480</additionalTradeItemIdentification>

<transactionalItemData>

<batchNumber>A999917123456129</batchNumber>

<itemExpirationDate>2019-08-31</itemExpirationDate>

<serialNumber>001</serialNumber>

</transactionalItemData>

</transactionalTradeItem>

<purchaseOrder>

<entityIdentification>PO number 321ZYX</entityIdentification>

<lineItemNumber>1</lineItemNumber>

</purchaseOrder>

</despatchAdviceLineItem>

</despatchAdviceLogisticUnit>

</despatchAdvice>

</despatch_advice:despatchAdviceMessage>

• D.2 Notes to the SBDH – sh:BusinessScope à sh:Scope

The MESSAGE_STATUS can have in the instance identifiers “TEST”, “QAS” or “LIVE” as appropriate to the implementation Life Cycle for the given message

The SCHEMA_GUIDE could be omitted or contain the respective and relevant Specification.







[1] https://www.gs1.org/docs/tl/GS1_Logistic_Label_Guideline.pdf

Contributors & Change Log