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
- 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.
Post a Comment