A provider replacing all of the account numbers assigned by suppliers with GLNs only perpetuates the problems that the industry is trying to correct through global data standards adoption.

For example, during its GLN enablement process, BJC HealthCare found that in some cases, it had between four and six account numbers assigned by the same supplier for the same ship-to locations. With 100 ship-to locations and 4,600 suppliers, BJC faced the possibility of managing over 1 million account numbers. Thomas M. Stenger, Jr., manager of MMIS & Analysis for BJC HealthCare, says these multiple account numbers caused a variety of problems, including products shipped to the wrong locations, increasing costs for both BJC and its suppliers.

BJC engaged its suppliers in a reconciliation process whereby it eliminated any account numbers that did not serve a legitimate business purpose. If there were a case when it was deemed necessary to keep more than one account number for the same location, such as when a supplier needed to identify a unique ship-to/bill-to combination, BJC would assign a new GLN to this account number so that there was always a one-to-one relationship between account numbers and GLNs.

Once a provider has enumerated itself and its active ship-to and bill-to locations within the GS1 US GLN Registry for Healthcare, there are two processes that it must undertake to transact successfully with suppliers using GLNs, each with its own series of steps. The first process involves the provider cross-referencing its GLNs to its other data values, including its ship-to and bill-to locations, group purchasing organization (GPO) membership IDs, supplier account numbers and its e-commerce partner’s facility IDs. The second process involves the provider proactively testing these cross-referenced values in transactions with its suppliers. We have outlined the cross-referencing process below and will address the testing process in the December edition of this column.

The first step in the cross-referencing process is for the provider to build a cross-reference table in which it establishes a one-to-one relationship between its GLNs and its ship-to and bill-to locations. This table will serve as a crosswalk to bridge the ship-to and bill-to locations to the GLNs during electronic transactions with trading partners.

The second step is for the provider to reconcile its GLNs with its group purchasing organization (GPO). It does this by establishing a one-to-one relationship between its ship-to and bill-to locations, GLNs and GPO membership IDs within its cross-reference table and then submitting the table to its GPO to ensure that the GPO is using the correct GLNs for the provider’s locations in its membership roster. During this process, a provider may find that its GPO has locations in its membership roster that the provider did not have in its table. If this is the case, the provider will have to determine if these are legitimate locations, and if so, assign GLNs and update its cross-reference table accordingly.

The third step is for the provider to reconcile its GLNs with its suppliers. For each supplier, the provider adds its supplier-assigned account numbers to the corresponding locations, GLNs and GPO IDs in its cross-reference table and then sends this table to the supplier so that the supplier can verify that its systems contain the same account number/location matching. As referenced earlier, this process provides an ideal opportunity for the provider and its suppliers to eliminate any unused account numbers to improve the accuracy of transactions.

The fourth step is for the provider to reconcile its GLNs with its e-commerce partner. A provider does this by adding the e-commerce partner’s facility ID to its cross-reference table. It is critical that the provider work in close collaboration with its e-commerce partner to ensure that its cross-reference table meets the necessary requirements for e-commerce, e.g., the GLN is in the correct field.

The third and fourth steps must be conducted with each of a provider’s vendors. If a provider does not want to repeat the process numerous times, it can utilize the services provided by GHX or another professional services partner that has similar technology in place to manage these kinds of buyer-seller communications.

To achieve the full potential of standards, including integration with other internal systems, it is ideal for both provider and supplier materials management and/or ERP systems to recognize and process standards-based identifiers, and that is something we recommend you discuss with your technology vendor. However, lack of system capability does not mean you cannot transact with standards-based identifiers. For example, GHX can perform the necessary translation to include the standards identifiers in a purchase order and then, if the supplier cannot accept the identifier, perform a similar translation on the receiving end.

We posed this question to several of the leading MMIS/ERP vendors and received the following responses. (We welcome answers from additional vendors, as we will be including more information from MMIS/ERP vendors in future columns.)

• Lawson: The current release of the Lawson Supply Chain Management Suite supports both GS1 and HIBCC standards and is ready to support the GLN and GTIN sunrise dates. Although previous versions of Lawson included fields to support UPN, UPC, NDC and other identifiers, the current release of Lawson reflects significant investment and enhanced functionality for handling product identification standards.

  In addition, Lawson is designing new applications, where appropriate, to include standards from the beginning.

• McKesson: The McKesson Horizon Enterprise Materials Management (previously Pathways Materials Management) will support the GTIN requirements by the sunrise date, for both EDI and use throughout the functions performed within materials management. This functionality is targeted for inclusion in the Horizon Enterprise Materials Management version 16, scheduled for release in the spring of 2012.

  In addition, McKesson’s Horizon Enterprise Materials Management version 16 will provide support for GDSN connectivity and updates, as well as for UNSPSC codes.

• MEDITECH: The MEDITECH Materials Management system has provided the ability to track UPN information for several years, which can be used for storing GTIN or HIBC-LIC identifiers. MEDITECH’s Magic platform first supported this capability in the late 1990s with the release of version 4.7 and this functionality was added to Client Server in 5.5 SR3.

  Currently, MEDITECH Materials Management system users can only record one UPN identifier (HIBC-LIC or GTIN) but the company is working on future changes that will enable users to define multiple numbers in the event that they want to record both the GTIN and HIBC-LIC. The company will also be making changes to facilitate standard use of the GTIN or HIBC-LIC in EDI transactions.

• Oracle PeopleSoft: Oracle PeopleSoft Enterprise supports the use of GS1 GTINs starting with PeopleSoft release 9.0. The current PeopleSoft Enterprise production release number is 9.1.

  While the vendor GLN is supported today, Oracle PeopleSoft Enterprise will provide enhanced GLN support for the healthcare industry via a feature pack on top of release 9.1 delivery in the calendar year 2011.