Product Registry & GDSN

As OpenLMIS aims to be as interoperable with other supply chain and health IT systems the need to have a shared understanding on what a Product is, how&who should define it becomes a leading topic.

OpenLMIS supports open standards for interoperability.  When health products are in the supply chain:

• If the product is identified through GS1 (i.e. a GTIN), then the master data should be sourced from a GDSN Data Pool provider.
• If the product isn't identified through GS1, then the master data should be published and cross-referenced in a Product Registry.

Common state of Products and Product Lists

• Most Products are defined in an IT system by the organization that runs the IT system.
• Many Products in these IT systems are a mix of two different concepts:  trade items and product classifications.
• Lessons from Master Data Management are generally not being followed:
  • Sources of Truth either aren't being used (i.e. each org defines the product themselves in some fashion), or aren't well sourced (i.e. one IT system uses another's definition, even though that other system isn't any better a source of truth than any other).
  • Systems of Record aren't being defined - The attributes that define what a product is (brand owner, country of manufacture, active ingredients) as opposed to what it is to me (my national registration number, whether I consider it a tracer or not) not only aren't coming from appropriate sources of truth, but there's no plan to aggregate those sources of truth into a national system of record.

What is a Product Registry?

In simplest terms a Product Registry is a system of record that helps enterprise systems to all agree on the definition of a product while migrating to better sources of truth about products.

• Slide Deck:  https://docs.google.com/presentation/d/12jl5lO_SP3Fl5SCgJKU_jg7VAK66oza4Y0hQgrc5NKU/edit?usp=sharing
• Example Requirements:
  • Enable anchoring of one legacy code to a national / global code.
  • Facilitate the classification of trade items into commodity identifiers.
  • Define trade items and attributes using GDSN formats with the attributes in use in the GHSC Product Master.
  • Allow commodity classifications to be defined.
  • Allow organizations to define and maintain their own product catalogs.
  • Support being a GDSN Broker for GDSN connections to national health IT systems.
  • Web-based interface for managing the definitions and system, with a recommender system to reduce duplication of defined items.
  • Standards based web API and feed to enable other health IT systems in following the Product Registry.

Could OpenLMIS build a general Product Registry?

• The OpenLMIS Reference Data Service contains the v3 commodity model for Products with support for Trade Items, Commodity Types (aka classification system) and Orderables (useful for interoperable product catalogs).
• The Medical Commodity model could be split out of the Reference Data Service to form it's own stand-alone microservice.
• We'd add additional functionality to support the above requirements with a nice web UI.
• This new Product Registry service would be most usefully deployed for use in health enterprise architecture (many systems), though of course it could also be deployed in the OpenLMIS Reference Distribution when such an architecture is still forming.