Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: update product registry to product catalog

...

Reasoning for an LMIS to be at the PoS layer:  An LMIS typically will be in use at a clinical location (or an LMIS paper form will originate from one) assisting the clinic in the resupply workflow.  It's possible that an alternative to listing the LMIS in the PoS layer would be to instead assume that 1) another PoS system takes on this capability or 2) that we add another icon more specific to the capability such as "Inventory & Resupply".  At this level an individual clinical location may not have much visibility into the rest of the health supply chain, however this direct data entry is commonly found in many LMIC countries that have an LMIS todayand because of this it could make sense to not confuse the diagram with LMIS in both the component as well as the PoS layers, however many countries which have an LMIS already see it in this dual role - at a component layer as well as a PoS system


Product

...

Catalog


Icon:  ?

Where: Along with the other OHIE Registries (e.g. HWR, TS, etc)


Description:


A Product Registry Catalog serves as the source of truth about what a Product is within an HIE.  It sources the information for this role through two expected means:  1) as the ongoing result of a process of master data management to properly define and categorize medical products and 2) as derived data on the proper definition and categorization of medical products (e.g. GS1 GDSN).


Reasoning for a Product Registry Catalog to be located with the other registries:  In many respects a Product Registry is very similar A Product Catalog serves as the source of truth for defining products and their categorization(s) for the HIE.  This role is similar in kind to other registries which serve as the source of truth for Facilities or Clients such as the Facility or Client Registries.  A Product Catalog does have some similarities to a Terminology Service (TS) in that it 's expected that a primary use-case is to map one product code to other equivalent coding systems for the same product.  It's also expected that the software underlying this registry will add further capabilities to carry out the use-cases described above which go beyond the TSwill map equivalent product codes to one another, however as mentioned above the product catalog adds additional capabilities specific to the nature of how product definitions are created, the roles of the various organizations involved in this process, and the external systems which already hold some of this data.