How centralized ATP repositories complicate DSCSA-regulated product verifications

… or how too many cooks can make the broth expensive

Published in

Spherity

10 min readMar 9, 2023

Lately, I have come across a few misconceptions around DSCSA-related Authorized Trading Partner (ATP) checks that I’d like to address here. If you are affected by the impending full-blown DSCSA enforcement by November 2023 and have already looked into compliance solutions, this article is for you.

If you’ve heard of the Open Credentialing Initiative (OCI), Verification Router Services (VRS), PDG Blueprint, Spherity, or Legisym before, this article is especially for you.

If you are unfamiliar with the topic, these are good places to start before reading on:

Quick recap: What’s an ATP check?

The Drug Supply Chain Security Act (DSCSA) defines the criteria for a pharmaceutical supply chain actor to be considered duly authorized, i.e. to be considered an ATP in the eye of the law. Before exchanging any potentially sensitive information as happens in certain product inquiries, so-called Product Identifier (PI) Verifications, trading partners are supposed to make sure they are dealing with an ATP at the other end. This applies both ways — for responding to an inquiry and for accepting the response. A proper check does not only involve inspecting such things as license numbers but also ensuring that the examined party does indeed own the license and is the one sending the inquiry.

If you don’t check, how can you be sure the other side is legitimate?

Centralized repositories as license and registration data lookups

Centralized ATP repositories are helpful for interactions between trading partners that do already have a direct business relationship. For example, if a manufacturer needs to know whether the license of a pharmacy that is a direct customer is in good condition, they can use products offered by Legisym (License Verify™), NABP (NABP Verify), or MedPro.

These kinds of look-ups work very well when trading partners need license information about their already established business partners. However, these established solutions have their limits when transactions between Trading Partners are facilitated by VRS and executed between trading partners having no commercial relationship. This article will explain why.

Interactions between trading partners without commercial relationship

Imagine Pharmacist Peter needs to investigate a suspicious product. By scanning the box Peter triggers a product verification request with his solution provider Sarah Scan&Verify. According to DSCSA requirements, all suspicious products need to be verified against their source. Peter doesn’t know where exactly to send the request because he had procured the drugs from a secondary wholesaler. So, Sarah Scan&Verify’s job is to figure out the correct manufacturer by using a look-up directory and route the inquiry to them or, more specifically, the manufacturer’s solution provider.

Following extensive testing over the course of a few years, pharma solution providers, like Sarah Scan&Verify, have aligned on using the GS1 Lightweight Messaging Standard for DSCSA Verification of Product Identifiers to handle PI Verifications between any two trading partners. Agreeing on this standard means that any service provider can participate in this ecosystem and rely on their PI Verification messages to be compatible with their competitors’ systems. Consequently, the use of this shared standard does not only create an open market, but also the foundation for true service interoperability, a key requirement in an ecosystem as decentralized as the U.S. pharmaceutical industry.

The problem with GLNs

The GS1 Lightweight Messaging Standard used by Sarah Scan&Verify does not support having any other electronic identifiers in verification request messages but the Global Location Number (GLN). Herein lies the crux of the matter. The GLN does neither provide any indication of Peter’s Pharmacy’s authorization status nor whether Peter is indeed the one submitting the request (and not an imposter). Thus, Peter or Sarah needs to provide additional information to the manufacturer for complete due diligence. Considering the two electronic options discussed in this article, the additional proof could theoretically come from either of these sources:

OCI-specified verifiable credentials or
a centralized ATP repository.

“When using VRS initially, we utilized the Global Location Number to identify a trading partner. We discovered GLNs that were not active or not associated with the requesting entity. GLNs also do not inform about authorized status. Additionally, we had no proof that the provided GLN actually came from the trading partner.”

Dave Mason, Supply Chain Compliance and Serialization Lead at Novartis

OCI verifiable credentials top up GS1-specified messages

If Peter held an OCI-specified verifiable credential representing his ATP status, Sarah would package it into an electronic presentation format and append this to her verification message. The GS1 Lightweight Messaging Standard allows this specific addition. The packaged verifiable credential proves two essential pieces of information to the manufacturer independently of the GLN.

Peter’s Pharmacy is an ATP.
Peter’s Pharmacy is the sender of the inquiry.

Peter would not need to provide any further evidence, as Sarah’s automated message covers all the bases. The ATP check and PI Verification would happen within the blink of an eye. Peter would know he can trust the response message because Sarah has checked the manufacturer’s appended ATP credential presentation. Of note, PDG has approved this approach as the only feasible option to automate ATP checks in VRS-facilitated exchanges.

Both, Peter’s Pharmacy (“you”) and Sarah Scan&Verify (“VRS”) exchange OCI-specified verifiable credentials appended to the request and response messages regarding Peter’s product inquiry. A swift process. (*source*)

Proprietary centralized ATP repositories are detached from the interoperable flow

Let’s take a look at what would happen if Peter relied on a proprietary centralized ATP repository service. Let’s call this service Carl Central. Let’s further assume Carl also offers a service to route product verifications to manufacturers.

First, one crucial thing must be understood — Carl Central runs his own proprietary solution to verify ATP licenses. Compatibility or communication with other solution providers is not a given by design. This is in stark contrast to the OCI framework which invites interested service providers to follow its recommendations to enable all participants to be interoperable by design.

Back to Peter’s PI Verification. The manufacturer receiving Peter’s inquiry would need to get a hold of some proof of the pharmacy’s valid ATP status, as none is attached to Carl Central’s GS1-specified verification message. To this end, Carl Central’s system is set up to allow the manufacturer’s solution provider an automated search for Peter’s Pharmacy’s license information in Carl Central’s centralized ATP repository. However, this represents the first significant challenge: The manufacturer’s solution provider does not know that the request comes from Carl Central’s service. This is because the PI verification request is routed via a lookup directory (e.g. MediLedger) and Carl Central’s message contains no information identifying his service as the sender due to the message structure. Consequently, the manufacturer’s solution provider does not know that they have to query Carl Central’s ATP repository.

Now, let’s assume there was a way for the manufacturer’s solution provider to know that they need to check Peter’s Pharmacy’s ATP status in Carl Central’s ATP repository. Here is the second challenge: The only identifier the manufacturer’s solution provider receives in the GS1-specified message is Peter’s Pharmacy’s GLN. So, they’d ping Carl Central with a check request to verify the ATP status associated with the GLN. But how can the manufacturer be sure that the requester is really Peter’s Pharmacy? GLNs are publicly available. Anyone could have found Peter’s Pharmacy’s GLN and sent the inquiry to the manufacturer. Thus, from this check, the manufacturer merely obtains assurance over the license status of the received GLN, but not the legitimacy of the sender.

And what about Peter? How would he find assurance over the trustworthiness of the response? He faces the same critical challenge as the manufacturer. Of course, the same ATP check of the received GLN can be performed, but it leaves the same open question about the sender’s identity.

What if a service provider does not send GS1-specified messages?

To circumvent the constraints of GS1-defined messages, it may seem an obvious alternative for Carl Central to design its own message format that delivers all the information in a way that differs from verifiable credentials.

This brings up two key questions for the manufacturer’s solution provider.

Can my service read Carl Central’s off-standard messages?
How will my service send a response to Carl Central?

A couple of options for the manufacturer’s solution provider come to mind:

Do not perform ATP checks on PI Verification requests received from Carl Central. However, due to the reasons mentioned above, such selectivity may not be possible to enforce as soon as an intermediary look-up directory obfuscates the message originator. In addition, this would weaken the manufacturer’s due diligence and regulatory compliance and, thus, leave the pharma supply chain vulnerable, defeating the intent of DSCSA.
Build the system capability to cater to Carl Central’s proprietary message format. This could entail further software development to automate the processing of these off-standard messages or the introduction of manual processes.

Theoretically, this point includes further optionality:

The manufacturer’s solution provider builds only a read capability. This means they can automate the processing of incoming messages, but will then reply using the current industry-agreed GS1-specified format with OCI-specified credentials. This means Carl Central will need to be able to process such a response.
The manufacturer’s solution provider caters fully to Carl Central’s proprietary process by building a solution that can read and send based on Carl Central’s message format.

Since such decisions are made by each single solution provider, consistency across the industry cannot be guaranteed.

Many cooks drive complexity & costs

If the manufacturer’s solution provider decided to become compatible with Carl Central’s off-standard service, when would they draw the line? How commercially viable would the adaptation to further proprietary systems be? Would they need to pay for access to each proprietary centralized ATP repository? Any solution provider can only increase service charges for so long until they price themselves out of the market. Eventually, off-standard service providers will not be able to tie in with their competitors anymore and their customers will be left stranded.

Vendor tie-in

Within these last points is a crucial detail. The manufacturer themselves, not just their solution provider, must register with (and pay for) Carl Central’s system entirely because Peter uses it. Neither Peter nor his service provider Carl Central can expect a manufacturer registers their details in a centralized database that potentially captures not only information on trading authorization but also on transactions. This is a classic vendor tie-in model that would lead to a nationwide centralized ATP management system and the accumulation of business intelligence within a single centralized system. Not only can such information potentially be abused by the central party but is also of prime interest to hackers.

In our experience, the US pharmaceutical industry has so far been working hard to avoid centralized data storage and vendor tie-ins like the devil hate holy water.

We discussed at last year’s OCI conference how OCI’s credentialing framework avoids the concentration of data. Besides the separation of duties, the multitude of possible vendors that can participate in the OCI ecosystem leads to distributed data storage. Read more here: How open standards support enhanced drug distribution security — Conference reflections.

In order to enable an effective, efficient, economic, and open interoperable market, basic rules must be agreed upon. The GS1 Lightweight Messaging Standard together with OCI-specified verifiable credentials under the guidance of PDG’s Blueprint provides a common basis for the handling of DSCSA-compliant PI Verifications. When service providers agree on such an open standardized approach, industry-wide interoperability of different solutions is enabled by design.

Adoption of an open standardized approach, not a centralized single software system, that anyone can participate in is key for industry-wide interoperability.

Conclusions & further considerations

To summarize, in the context of DSCSA-governed PI Verifications, I see the following key takeaways that need to be considered before selecting solution providers.

Open standard approach with OCI-specified verifiable credentials

… have enabled competing solution providers to build efficient process automation for DSCSA compliance and supply chain security;
… enable interoperability between solution providers by design, which has been tested extensively;
… create an open, competitive market for the benefit of service buyers.

Centralized ATP repositories fall short of the above because they …

… cause extra technological development and drive costs for everyone who wants to engage with them;
… are a single point of failure and pose a risk of concentration of business intelligence through data correlatability within a single entity;
… have not yet been extensively tested and are unlikely to be sufficiently integrated into tried and tested solutions by the DSCSA deadline in Nov 2023.

Further considerations when evaluating centralized systems include:

Availability: Since Carl Central’s repository is a centralized system, all verification requests will fail if Carl Central’s servers are down, as no ATP checks can be executed.
Performance: Carl Central’s system must be able to respond in milliseconds to any check at all times, as the industry requirement for a verification roundtrip is 1 second.

It is true that a centralized system eliminates the need for interoperability. However, the industry is less flexible and has higher dependencies on single vendors. Whilst the OCI community designs frameworks cooperatively to solve industry challenges, individual solution providers remain competitors at the service level. Such ‘coopetition’ benefits the industry in the long run.

Service pricing is down to each individual solution provider and depends heavily on the nature of their service packages. At Spherity, we have been and will keep on working hard with our integrators to enable affordability across the pharmaceutical supply chain.

If you would like to join the ecosystem using OCI credentialing, check out the Spherity Early Adopter Program.