November 2023 marks the final implementation milestone of
the Drug Supply Chain Security Act. This
final phase of DSCSA represents, arguably, the most complex aspects of the
regulation- requiring the end-to-end traceability of serialized items from
manufacturer through to dispenser.
Central to ensuring the industry can meet these requirements
is the ability to capture traceability data and exchange between partners as product moves through the supply chain. This same data is also the foundation for verification
processes which help the industry root out illegally diverted and counterfeit
products.
Effectively then- with the implementation of DSCSA 2023-
serialization and traceability data becomes as important as the physical items
themselves to ensuring uninterrupted product flow and a secure supply chain. And
that level of importance places a significant emphasis on ensuring data is
accurate and availability- a concept the FDA refers to as data integrity.
Even putting the criticality of DSCSA data aside for a
moment, the FDA has made its position on data integrity explicitly clear with
the release of the ‘Data Integrity and Compliance in Drug
CGMP’ guidance in 2018. The guidance defines the ALCOA
principle which requires data be “attributable, legible, contemporaneously
recorded, original or true copy and accurate.” (We’ll come back to this)
In the past week we crossed a major milestone in the
industry’s march towards DSCSA’s November 2023 deadline- we are officially
under one year to go. The final chapter
in a 10+ year journey to build out serialization capabilities across the
industry. Understanding the importance
of data, a casual observer outside of pharma would reasonably assume the industry,
by this point, has expended significant resources on systems and processes to
ensure the ‘ALCOA’ of DSCSA data.
Certainly the industry wants to avoid the scenario where perfectly
legitimate product can’t reach patients because data is not accurate or data
can’t be exchanged. Seems like a no-brainer,
right?
So how is it then, with less than 365 days to go (255
working days for those keeping track) that I can write a blog post about a data
integrity issue that is so fundamental it affects most (possibly all?)
customers using the supposed ‘leading’ DSCSA serialization L4/L5 system? A data integrity issue so basic that it
raises the potential of supply chain disruption and exposes
impacted customers to a clear audit risk under the FDA’s 2018 guidance.
So what is the issue?
When processing critical traceability events- specifically shipping and
receiving events- the aforementioned system is setting the event date/time equal
to when the data was processed rather than the actual date/time of when the
event happened. In other words, this
system is changing your DSCSA data based on an activity (processing in
their system) that has no correlation to when the actual supply chain event
happened- meaning 100% of your impacted shipping and receiving events are
wrong.
Here’s an example: Your
3PL ships a serialized order to your customer on June 4. The 3PL sends you a data file which correctly
indicates the shipment went out on June 4.
Due to [enter any one of a million reasons here] the data is received and
processed in your system on June 5. Astoundingly,
your serialization system now reflects the shipment occurred on June 5.
But Scott it’s only a day off- who cares? If you’re focusing on how inaccurate
the data is, rather than why the data is inaccurate then you’re missing
the point. A serialization system does
not get to arbitrarily choose the date/time when an event happens. It must record the date/time as provided by
the source system. Otherwise it not only fails the ‘Accurate’ principle of FDA's
guidance but it also fails any measure of being a validated system and subsequently fails one of the most basic operations of any serialization system. Moreover, the system further propagates the issue by including the incorrect date/times in data exchanges with partners which, in turn, diminishes
the validity and effectiveness of DSCSA verification processes which so vitaly rely on this data. In short, this fundamental data integrity
issue endangers the core aspects of DSCSA and a flaw such as this immediately calls
into question the integrity of all other data managed within the system.
Since identifying this current issue I’ve struggled to decide which scenario is worse:
- That an issue of this nature is truly just being discovered now- when hundreds of companies have been using the system, in most cases, for multiple years
Or
- That the issue has been known for some period of time, hasn’t yet been fixed and hasn’t received any publicity across the industry
Either way the outcome is worrisome- either this shows a
clear sign that the industry has been asleep-at-the-wheel when it comes to
understanding and reviewing serialization data OR we are setting a reckless and irreversible precedent by considering this type of data integrity issue as
acceptable.
If I am a customer impacted by this issue, I am dropping everything immediately and:
- Determining the extent of damage this has on my data
- Determining my data integrity audit exposure risk
- Evaluating my compliance approach to DSCSA
After doing so I would be making rapid decisions, while I
still have time, to ensure my systems are capable of the core concepts of serialization
and traceability data management. And
for those who feel a sense of comfort that many others in the industry are
impacted by this same issue, that may not be a responsible position to take
because, keep in mind, regulations and auditors don’t care if you’re 1 of 1 or
1 of a million.
As always, feel free to reach out to learn more about this issue.
