Most RxTrace readers are at least aware of GS1 standards. GS1 is an international non-profit membership organization that facilitates the development and maintenance of technical standards that are intended for use within supply chain operations and interactions. GS1 standards are used in many supply chains including pharma. GS1 standards are playing an indispensable role in the implementation of pharma serialization, including their GTIN, GLN, SSCC, Datamatrix, application identifier and EPCIS standards. I have written frequently about GS1 and these specific standards (see “GS1”).
But today I want to draw your attention to a different standards development organization that could become very important to drug manufacturers and their contract partners who are implementing pharma serialization systems. The organization facilitating this development is the OPC Foundation and the standard they are developing with their pharma supply chain members is called the Open Serialization Communication Standard, or “Open-SCS”. Anyone can join the effort and help contribute to the design of the standard by contacting Michael Bryant, Admin Director of the OPC Foundation.
At this point, I hope you are asking questions like “why do we need another standards development organization?” and “as a communications standard, won’t Open-SCS compete with GS1’s EPCIS interface standard?”. I asked those questions too. In fact, the group of drug manufacturers and solution providers who began the effort to create a new standard first approached GS1, but they apparently declined to get involved since the resulting standard is not intended for use between trading partners. That means the Open-SCS standard will fall outside of GS1’s normal territory. And don’t worry, Open-SCS will not compete with any GS1 standard. In fact, it will complement and make use of GS1 standards whenever appropriate.
WHAT EXACTLY WILL OPEN-SCS BE?
Open-SCS is intended to standardize the communications between the layers of functionality necessary to implement a serialization solution following the ISA-95 model for an automation interface between an enterprise and its control systems. The ISA-95 model defines a set of “layers of functionality” necessary for a properly constructed solution to any kind of manufacturing system. A layered approach to solution design offers benefits to both the solution developer and the end-user, like:
- Faster implementation
This is all well-established. In general, for manufacturing systems, ISA-95 establishes a set of functional layers that should be included in the typical solution. For our purposes, these can be generalized as (from top down):
- Level 4 (L4): Enterprise (this is your corporation)
- Level 3 (L3): Site (this is a single site within your corporation or a CMO/CPO)
- Level 2 (L2): Line (this is a single production or packaging line within a given site)
- Level 1 (L1): Devices (printers, scales, conveyors, scanners, vision components, etc.)
Existing serialization solutions out there today already implement functions like this, but to get the benefits I listed above, the functional layers must be able to communicate with the other layers in a standard way. This is the goal of Open-SCS. The communications that go on between layers L2 and L3, and L3 and L4 will be standardized by Open-SCS. Communications between L1 and L2 will be included in a future version. Here is a drawing that shows how Open-SCS will fit within the ISA-95 layers in a pharma serialization packaging solution.
Large-scale systems will usually implement these functional levels in separate executable applications. Once the Open-SCS standard is complete and incorporated into the solutions offered by multiple solution providers, these systems could be composed of components from multiple vendors. For example, a given end-user company might incorporate line-level solutions (L2) supplied by Vendor A, B, C and D, site-level components (L3) from Vendors B and C, and an enterprise component L4 from Vendor C. Today this would require custom and proprietary interface software which opens the door to higher costs and brittle implementations. In fact, over time, it could eventually become a real mess.
For smaller-scale systems, these functional layers will still exist but they may be combined within fewer executable applications. For example, for a small site with only a single packaging line, the line- and site-level functions might be implemented within a single executable provided by a single vendor. Or, the line-level functions might be in a separate executable, but if the enterprise is composed of a single site, the site- and enterprise-level components might be combined into a single executable provided by a single vendor, and so on.
The Open-SCS group has constructed the drawing below to document six different ways a single end-user solution might be implemented.
WHAT EXACTLY WILL OPEN-SCS DO FOR YOU (WHY YOU SHOULD CARE)?
Today’s global pharma manufacturing landscape is very complex and it changes all the time through mergers and acquisitions, the use of contract manufacturers (CMOs) and contract packages (CPOs) and changing regulations in multiple markets around the world. No drug manufacturer can expect to end up using a single vendor’s components in their serialization solution for very long. Open-SCS will make it much easier to retain investments in existing components and allow the overall solution to evolve naturally as the business changes. Components may not be true “plug-and-play”, but they should be much more “pluggable” than they were before. End-user drug manufacturers should be able to combine the assets from multiple acquisitions, and interface with existing systems owned by different CMO/CPOs easily, efficiently, and predictably. This flexibility will be possible through the magic of standard interfaces offered by multiple vendors.
Will this dream be realized? Probably not if you don’t get involved. Standards development is a totally uncharted path littered with the distractions that come from competing interests and biases. Whether GS1 or OPC Foundation, a successful standard can only be achieved if end-users—drug manufacturers and CMO/CPOs—participate in the entire process. Don’t expect this standard to be successful without that participation.
I am an active participant in the Open-SCS development work group through my work at Systech International. If you see the same value I do in this type of standard, I recommend you join. We need more end-users ASAP. Come and see me at the Systech booth at Pack Expo and we can talk about it further.
See you there.