Is there an inherent risk in DSCSA’s approach to verifications?

A constant battle which has waged since the beginning of serialization regulations in pharma is the notion of “Spirit of the Law” vs “Letter of the Law”.  In the case of DSCSA companies have, undoubtedly, aligned their strategy and implementations on the “Letter of the Law” more-often-than-not.

If the law doesn’t say I have to aggregate- I’m not aggregating. 

If the law doesn’t say I have to randomize serial numbers- I’m using sequential.   

Which brings us to our next “Spirit” vs “Letter” debate- how to support verifications under DSCSA.  Verifications are an intriguing component because while so much focus has been on what has to be done for DSCSA- generating serial numbers, printing barcodes on products, capturing data- verifications are really the industry’s first foray into actually using DSCSA.

Let me start by providing what I think the “Spirit” and “Letter” of verifications are under DSCSA

Spirit

Members of the pharma supply chain, the FDA and ultimately patients themselves should gain value from the presence of a unique identifier (and other associated data) on their prescription drugs and subsequently should have tools to use that data to request feedback whether, to the greatest degree of certainty feasible, the unique identifier is legitimate or not.   

Of course, even the purest supporters of serialization/traceability must recognize that a unique identifier (and associated data) alone can never be trusted to say with 100% certainty whether a product is legitimate or not.  The only way to truly verify a product is with scientific testing or other evaluation of the product itself (Thanks John Keogh).

But in the “Spirit” of verifications under DSCSA the industry should strive to put in place processes and systems that use all information available to them to provide the most accurate verification responses possible.  Verifications are, after all, at the heart of why DSCSA even exists.  If we are not making every effort to ensure verifications provide value (e.g. accurate responses) then in fact DSCSA may actually hinder product security by forcing a unique identifier onto items that can be easily exploited by counterfeiters.

Letter

Under DSCSA, the term “`verification' or `verify' means determining whether the product identifier affixed to, or imprinted upon, a package or homogeneous case corresponds to the standardized numerical identifier or lot number and expiration date assigned to the product by the manufacturer or the repackager, as applicable in accordance with section 582.”

In the simplest terms, DSCSA requires that when presented with a product identifier (GTIN, SN, Lot, Expiry) someone or some system must provide a response whether those data values match with the values assigned to a product that is, to the best of their knowledge, still a valid product.   Any burden of proof as to how the verification response was determined is entirely on the industry and individual vendors to define.

For most companies the required product identifier verification will be done by their serialization systems.  Thus, in functional terms, serialization systems have some procedure that can take in a product identifier, do some checks, and spit out a response.  

At that point every company will have to decide for themselves whether the product identifier check, the only one required by DSCSA, is the only check that will be performed.    

History says most pharma companies will take that approach and proof of that is already apparent with the rapid adoption of VRS.  VRS was built to support the needs of large wholesalers who have to deal with the highest volumes of saleable returns, which now under DSCSA must be verified before they can be sold again. VRS itself is a great accomplishment, building a standards-based approach which facilitates the routing and communication of verification requests and responses- all done in a matter of seconds. However, that alone tells me all I need to know- the industry is rallying around the “Letter of the Law”- do the product identifier verification, provide a response quickly and move on.

But even when inclined to follow the “Letter of the Law” companies must surely recognize that the product identifier verification, which will often be the only check done, has a tremendous amount of importance and responsibility placed on it, right?    And serialization vendors, recognizing the same criticality and importance, must be investing significant R&D and leveraging advanced algorithms and technologies like AI to ensure the most accurate verification responses are provided, right?   (Do you sense my sarcasm?)

Here’s where things get intriguing- take a poll of the 5 major serialization system vendors and ask them how, systematically, they verify a product identifier?  You’re likely to get 5 different answers.

That alone is cause for concern-but again doesn’t mean any one vendor is more-or-less compliant under DSCSA.  More intriguing is to dig deeper and question how robust are these ‘checks’ being done by the serialization systems to determine if a product identifier is verified or not?

Unfortunately, serialization vendors have never been a model of transparency when it comes to demonstrating how their platforms work, but nonetheless, I welcome all vendors to state their position on how they perform verifications. (and actually show it working).  I hope I get some replies!!

Given my experience with serialization implementations here is what I would *hope* is a feasible set of checks which serialization systems use to verify a product identifier.   To be clear, I am a “Spirit of the Law” guy so I don’t consider the checks below to necessarily be adequate, I simply think this is a feasible set given the maturity of serialization implementations/systems I’ve seen to date.  At the same time, I also know some serialization systems are not capable of these checks.

• Unique identifier (SGTIN) must be commissioned and associated to the corresponding lot and expiry
• Unique identifier must not have reached an ‘end-of-life’ (e.g. decommission, destroyed, etc.)
• Unique identifier must not be associated to a lot or itself directly marked in any status which should prevent further distribution (e.g. quarantine, recall, suspect)
• If verification request is from a trading partner, unique identifier must have been shipped and associated to a DSCSA transaction

I was fortunate to gain experience with a solution provider who had in-depth serialization and authentication solutions in use by companies outside of pharma who leveraged the tools for brand protection purposes.  What I can say with the utmost confidence is if those companies were presented a solution that used the criteria noted above, they would swiftly dismiss it- identifying it as an inadequate solution.  The reason being is such a set of criteria would result in more false positives than acceptable within their margin of error- meaning it would too often provide ‘verified’ responses when in fact the item was not legitimate.   

In fact, the authentication solutions used outside of pharma leveraged no less than a dozen different rules and data checks to determine, with the highest degree of certainty feasible, whether the unique identifier was legitimate.  Beyond the surface checks noted above, true authentication systems consider other factors such as request source, frequency and dispersion of requests over time, evaluation of traceability history relative to expected supply paths and, in some cases, even automated visual packaging inspections.

So, if these types of solutions exist and are used outside of pharma- in industries which have no regulatory requirements- why should the bar be set any lower in pharma?  Ah yes…. “Spirit of the law” vs “Letter of the Law”.

Now let’s address the risk that pharma companies face.  I certainly would not want to be the serialization lead at a manufacturer who is getting questioned why items, which ended up harming patients, were given the ‘thumbs up’ by their serialization system’s verification response.  If anything, I would want my systems to error on the side of caution- offering any number of false negatives over even a single false positive.  Of course, that’s the last thing wholesalers want to hear- as a spike in failed verifications means a major hit to their efficiency.  But back to the original point- “Spirit” vs “Letter”- is DSCSA in place to make sure the industry’s efficiency stays in tact or is it to protect patients?  So much focus has been on VRS and the battle between who’s VRS solution is better/faster/more widely used- but who’s paying attention to the actual content of the verification responses that will be flying all over the place- and more importantly the significant impact those verification responses have on the downstream flow of legitimate and illegitimate product.

Outside of the DSCSA text itself, guidance from other key organizations clearly indicates that the product identifier check is only one of the checks that should be done.  Over 2 years ago the FDA put out a guidance entitled “Identification of Suspect Product and Notification” (Link) which explicitly laid out several additional checks that should be done in order to determine if a product is suspect or not. (product sourcing, current supply/demand, visual appearance).  More recently GS1’s Verification Messaging standard (Link) did its best to ensure they are not liable for verification responses by stating “It should be noted that verification of product identifiers is only one element of ensuring security of products; further checks may involve physical inspection of the product and its packaging, including the integrity of any tamper-evident seals.”

So, you have some key organizations saying, “Yea the law requires you verify the product identifier but you reaaallly should do these other basic checks as well”.   Where will the industry fall?  “Spirit of the Law” vs “Letter of the Law”?

As always, maintain oversight of your serialization/traceability programs and ensure your implementation meets DSCSA verification requirements.   Challenge your vendors to provide hard evidence of how their systems are performing DSCSA verifications.   Manufacturers are now solely responsible for the verification responses they provide.

Jennason has the experience and solution offerings to help.  In addition to evaluating and testing serialization platform’s verification capabilities, Jennason also offers the DSCSA Verification Manager- a workflow solution ensuring companies complete all required verification tasks, retain required verification records and generate required FDA and trading partner notifications.  To Learn more, click here.

What to Expect in 2019 (Caution: Marketing Material Ahead)

I hope everyone had a great holiday season and found time to spend with family and friends.   I am looking forward to a great 2019.

Towards that end I wanted to offer a few of my own personal insights for the pharma serialization space in 2019 followed by an update on new consulting, solution and service offerings from Jennason.

Predictions for pharma serialization in 2019

With the Nov 2018 DSCSA serialization milestone having passed the industry is in a unique position.   As more and more companies enter a fully serialized world, we will experience the first true test of how well implementations are performing.   

Some bumps have already been experienced- the question is whether it will become a trend?

Some bold predictions for 2019

1.    As the industry starts to tackle aggregation and integration with distribution/3PL operations (on a mass scale) the robustness of enterprise serialization platforms will be tested- and many will recognize their solutions are not up to par.

2.    The major players in the enterprise serialization space will see some shakeup-   with both current players losing steam and new players entering the mix

3.    The progression towards "value beyond compliance" will be slowed by efforts to resolve issues with current implementations

Jennason Consulting in 2019

As always Jennason continues to provide the pharmaceutical industry with expert consulting support and purpose-built solutions based on over 10 years of serialization and commercial supply chain experience.  

At the end of 2018 Jennason consulting engagements could generally be put into 3 categories:  

1.    Emerging biotech/pharma manufacturers looking to launch products in the next 12-24 months and needing to be serialization compliant.

2.    Manufacturers who have had an ongoing serialization project/program for 1+ years but need additional support to resolve vendor issues to ensure compliance with DSCSA is achieved.

3.    Manufacturers with an interest to extract further value out of their serialization investments- but to do so first need an assessment on the current state of their implementations.

Jennason looks forward to an intriguing 2019- the consistent goal remains the same- making sure pharmas are educated on serialization/traceability/compliance while promoting proper use of GS1 standards to ensure best, long-term implementations.

New/Updated Solution Offerings

Jennason Master Data and Workflow Manager- As a company's commercial supply chain demands grow so too does the importance of master data management.   The Jennason MD&W Manager provides a cost-effective and robust alternative to spreadsheets and manual processes.  More information

Jennason DSCSA Verification Manager- Last fall the FDA released guidance for Verification Systems under DSCSA.    The Jennason DSCSA Verification Manager provides a workflow for companies to ensure compliance with all required tasks (verification, quarantine, investigations) as well as manages required FDA and trading partner notifications.  More Information

EU FMD EMVO Gateway Translation Tool - Built in collaboration with Be4ward Consulting, the EMVO Gateway Translation Tool is geared towards companies needing an immediate EU FMD compliance solution.  The Tool is capable of translating serialization data files from packaging sites/CMOs into the EMVS format which can then be manually uploaded via the EMVO Gateway web portal.  More Information

Jennason Serialization Test Tool- Launched over 4 years ago the Serialization Test Tool continues to be the leading off-the-shelf testing solution specifically designed for pharma serialization implementations.  The Tool is capable of simulating common serialization scenarios (commissioning, aggregation, shipping, end of life) and generating the corresponding EPCIS test data.  All major L4/L5 serialization platform vendors are supported.    More Information

New Service Offerings  

In late 2018 Jennason launched Jennason Design Services.  The purpose of Design Services is to support companies in need of building custom applications which supplement or enhance their serialization and commercial supply chain operations. Design Service engagements range from developing implementation tools to reporting dashboards to proof of concepts for companies looking to unlock additional value from their serialization investments.    More information

Thank you again and look forward to hearing from you in 2019.

EU FMD: Leveraging the ‘EMVO Gateway’ option for manual serialization data entry/file upload to the EMVS.

With just over a month until the EU FMD deadline pharma manufacturers should be putting the final touches on their compliance solutions- most integral of which is how they will communicate serialization and related data to the European Medicine Verifications System.

For manufacturers of any significant size/scale this communication of data is being handled by 3rd party vendors who directly integrate with the EMVS.   This enables a largely ‘hands off’ approach for the manufacturers- as their product gets serialized at packaging sites/CMOs the data flows to their 3rd party vendor system who, in turn, re-formats and communicates to the EMVS (at least this is how it should work :))

Another, fairly under-publicized, option exists however- known as the EMVO Gateway.    The Gateway is a web user interface which manufacturers can access and perform all the necessary data communications to the hub.   The Gateway generally provides two options for uploading data- manual entry (via typing or scanning of a barcode into the web user interface) or file upload (uploading a pre-populated file)

The EMVO Gateway is an intriguing option for the following use cases:

1. For companies whose 3rd party vendor is having issues and/or not on track to meet the upcoming deadline.
2. Companies who wish to maintain a secondary (back-up/fallback) solution to reduce overall compliance risk or dependency on a 3rd party vendor.
3. For companies who serialize product infrequently and/or at low volumes such that a more manual option is feasible.

A few key insights about the EMVO Gateway:

1. The Gateway connection can be maintained in parallel to a 3rd party vendor connection.  Credit to the EMVO for recognizing that most manufacturers would see the value in having two connections enabled at the same time.  This means there is little to no risk (and cost) for a manufacturer to enable the EMVO Gateway as a backup option.
2. The file formats which can be uploaded via the Gateway are NOT the same as files sent directly to the EMVS interfaces.  Don’t assume you can simply take files from your 3rd party vendor and upload them via the Gateway in case your 3rd party vendor fails.
3. EMVO Gateway supports all necessary functions (master data upload, pack upload, pack update, batch update, recall, report requests).

Whatever the use case may be there are some key hurdles which must be cleared in order to properly register and initially set up the EMVO Gateway access- and even more importantly these tasks can be time-consuming.  To ensure your EMVO Gateway access is available come Feb.9 it is strongly advised that you begin the process ASAP.

If you need help getting access to your EMVO Gateway or have questions as to how the EMVO Gateway option may be best positioned in addition to, or in place of, a 3rd party vendor connection reach out to Be4ward for expertise.  Jennason is proud to have developed a solution in collaboration with Be4ward (Link) which ensures companies can use the EMVO Gateway option effectively and efficiently.

A New Normal...

For many of us who have worked in the pharma serialization space for many years today represents a unique milestone- for the first time the US market will be operating under a "live" serialization regulation.   

I put "live" in quotations for the simple fact that the industry is largely unaware of how the FDA and other governance bodies are going to enforce the regulation going forward.   Just last week I received great input from a 30+ year FDA auditor who noted the agency tends to have a policy of "educate while you regulate".   Interpret that as you may.

I likely take an unpopular viewpoint which is I hope the FDA enforces DSCSA to the fullest-swiftly and forcefully.  While I don't fully expect this to be the reality, I firmly believe that after a decade+ of regulatory delays, including the most recent year delay of the DSCSA serialization deadline, the FDA needs to give some indication that serialization is the 'new normal' in the pharma industry.   Conversely, I think it’s time for the industry to be held responsible (or maybe better said- liable) for the efforts put forth and decisions made about how to best meet these regulations.   

And so, waking up this morning I didn’t quite know what to expect- the chatter on LinkedIn seems to be fairly minimal in fact.  For most in the industry knowing if they would be in a compliant position today was something determined long ago- so it makes sense that today is largely a non-event.  Undoubtedly there will be packaging runs done today/tomorrow/...  which are not serialized.  It's not out of pure ignorance for the regulation but likely folks who simply couldn't get batches done in time and are willing to take the risk the FDA will show leniency.  

Certainly, the true measure of how well the industry has achieved serialization compliance will be measured from this point forward.   Eventually the FDA can't turn a blind eye to unserialized batches and, moreover, if the FDA does want to make an example of some manufacturers, they won't have to look too hard for findings.    For example, we know the state of DSCSA-compliant barcoding is still woefully bad based on the most recent GS1/Big 3 surveys.   And I have often stated, and still happy to be viewed in the minority with this opinion, that the data being gathered by companies in their serialization solutions is woefully inadequate- and what we will soon find out- is if in some cases will also lead to compliance issues under DSCSA.   Of course, going back to my opening point, this is only a problem if the FDA decides to enforce and, moreover, knows how to interpret the data. (e.g. if a tree falls in a forest and no one is around to hear it, does it make a sound?)   

So, I'll toss an easy one out there for the FDA to look for and for manufacturers to check in their own systems in case they are concerned someone will come looking.     

Look at the instances in your serialization data where you indicate a 'change of ownership' has occurred.  This is often veiled under the labels "From Business" and "To Business" but make no mistake, the underlying data shows a change from a source owning party to a destination owning party.    Of course, we all know under DSCSA that 'change of ownership' also requires the existence of a T3 document- which for years now has tracked the sale of items from seller to buyer at a lot level (and still is required even once your product is serialized).   So, the simple question becomes- do you have, or can retrieve, a T3 document for every instance where your serialization data is showing a 'change of ownership' occurred?  I'm quite intimately aware that many manufacturers out there would not be able to produce corresponding T3s if they paid attention to all of the occurrences where their serialization data claims a change of ownership- and the reason for this is because their data will erroneously claim a change of ownership when one never actually happened, and thus no T3 will ever exist.

So now If I'm the FDA and I want to give my auditors an 'easy' intro question to interrogating a manufacturer's serialization data it wouldn’t be far-fetched for them to say, “Provide all serialization data for product X or Lot Y and all corresponding DSCSA T3s where you show a change of ownership has occurred."  In that one question an auditor would get a very clear idea of where a manufacturer stands with both the new serialization requirements as well as the long-standing Lot Level T3 requirements.

Why is this important?   As the industry now moves past this big milestone of DSCSA which largely centered around the ability to physically apply a unique identifier to items, attention will increasingly turn to data- as data is the single most important component to ensuring compliance with all future DSCSA milestones- whether it be product verifications, saleable returns or eventually full supply chain serialized data exchange. The example above is not likely to stop product supply, but it does represent the importance of having consistent and accurate data (and certainly most manufacturers will want to avoid FDA findings whenever possible)

If you are a manufacturer and happen to check your data and find yourself in an unfavorable position- I will say it’s likely not entirely your fault.   The data scenario described above is most often seen due to limitations in enterprise serialization platforms- whether it be the one you are using or even the one a partner, like your CMO, is using.  Said another way- its more than likely your vendor made a data decision without you even knowing.  Up until yesterday that didnt cause any issues.  Today and going forward you are now solely liable.

You don't need to know every nitty-gritty data detail but, as of today, you are now responsible for what that data says.  The only interpretation of DSCSA that matters is your own- not your vendors.  And starting today, a system limitation is certainly no excuse for being put in an unfavorable compliance position. And thus, my longstanding mantra remains-   maintain oversight of your serialization/traceability programs and leverage the readily available (and often free) tools and services to help ensure your serialization implementation is on track (and now- meets DSCSA compliance).

Finding the proper ‘center’ of your master data management capability

When frequently asked for my top ‘lessons learned’ from the dozens of serialization deployments I have supported my answer is always the same:

• Serialization is not a ‘project’ because it’s not something that ends.  When done properly serialization must be structured so that it becomes ingrained in your everyday business operations
• Initial serialization deployments always take longer than people expect them to
• Serialization will expose the need for more formal master data management- almost always to the point it becomes its own program/project

This article focuses on item #3 and attempts to provide some critical points as companies recognize the need for more formal master data management.  Additionally, I’ll highlight some misconceptions regarding vendor offerings in the master data management space.

To start- a quick mention as to the intended audience of this post.   Those at big pharma/biotech likely already have formal master data strategies, systems and processes not to mention entire teams dedicated to the practice.    This article is geared towards the small to medium pharma/biotech who often have no formal master data management prior to their serialization journey.  Many of these companies have recognized (or will soon) the need for such capabilities- even companies that have just a single SKU.

 

Recognizing the need for formal master data management often comes as a result of feeling the pain from:

• An increase in the number of product SKUs and/or locations a company must manage (the obvious one)
• An increase in the number or geographic disbursement of internal teams which require access to master data.
• An increase in the frequency which master data must be shared with partners/ customers, industry groups and government agencies

The reason serialization is so often the catalyst for further master data efforts is because it touches on at least 2, if not all 3, of the items above.

• Serialization can be directly attributed to an increase of SKUs managed within an organization, most commonly, as a result of needing to re-organize SKU’s association to the markets they can be distributed into (see EU FMD as an example)
• Serialization requires the need for consistent master data to be shared across supply chain, planning, manufacturing, trade/distribution, techOps, quality and other internal teams
• Serialization requires master data to be shared with partner organizations (CMO, 3PL), customers (DSCSA T3s and others), industry groups (HDA Origin) and government agencies (EU EMVS and others).

It’s not surprising then when companies recognize the need and are looking for a quick fix- they often turn to their serialization providers.    I completely understand the mindset and thus will cut right to the key point of this post (if you take nothing else away from this article remember this)- Your serialization system, at any level L3/4/5, should NEVER be your master data management system.   While I applaud organizations which have taken on master data activities I too often see them lean on their serialization systems and think they “are good.”

Here are the long-term problems with that approach:

• Serialization solutions serve the narrow need of serialization compliance for (often) a subset of a pharma/biotech’s commercial products.
• The breadth of master data elements managed by serialization solutions are directly tied to serialization compliance requirements which again is a subset of the total master data elements needed to support internal and external business operations.
• Serialization solutions are not built to be master data managers- often lacking the basic ability to perform data validations, data look-ups and version control.

Said another way, serialization solutions should always be a consumer of master data which originates from some other source(s) of truth (A ‘source of truth’ is simply a system, document or process which is recognized as being responsible for managing a piece of data).   These sources of truth represent the center of your master data management strategy from which data can be consistently shared to other systems, teams and processes.

The other challenge for small/medium organizations is often master data capabilities are tied to enterprise systems like ERPs which can be prohibitively expensive and require extensive implementations.  While ERPs are well suited for providing master data management- having visibility across functional areas within an organization- they just simply are not an option for many small companies.   

Seemingly out of options companies turn to a myriad of manual processes and the dreaded spreadsheet.    Over time data gets siloed among the various functional teams and, even worse, data fields are duplicated across teams but with different values.   I’ve seen pharmas have 4 different product descriptions for the same item- finance uses one value, supply chain creates its own, then planning modifies to reflect target market and finally regulatory pulls from the FDA NDC database. 

These challenges are also not things that present themselves but eventually go away on their own- instead they compound over time as more products/teams/regulations are introduced.   I don’t believe every small/medium pharma needs a full-blown master data management team- but if you fall into that bucket I do believe there is merit in looking at your current processes and capabilities (or lack thereof) and identifying some quick wins.  The first goal should always be to identify a centralized master data management solution upon which standardized processes for adding/maintaining the master data can be developed.  Shameless plug- one easy quick win could be this:  Jennason Master Data Manager.

While nobody likes to add projects at the end of the year and so many will be heads-down over the coming months ensuring US and EU compliance my suggestion is don’t let master data fall too far out of focus.   The reality is there are opportunities to instill robust systems and processes in a short time which can then serve as your long-term solution or can act as a proof of concept for a more formal master data strategy down the road.

Hope everyone enjoys the HDA Traceability Forum next week where I'm sure master data will be a big topic.

Blockchain: Grounded Optimism

I considered a number of angles for how to approach this post on blockchain and what I realized is that my thoughts on blockchain are conflicted- I simultaneously have a sense of both immense potential and immense apprehension when considering this trend-worthy technology.  What I concluded is that my polarity in thoughts is actually a reflection of the technology itself- one that seeks to provide the function of a highly secure, centralized ledger in a highly decentralized manner.  My goal for this post isn’t to be ‘for’ or ‘against’ blockchain, but rather provide an opinion of how best to approach the concept and the vendors which provide blockchain offerings.

First and foremost, I am not a blockchain expert.  As someone with a technical background I understand its basic concepts and its place in an overall solution stack but I should not be pegged to give a presentation on the topic anytime soon-  and yet I worry I could- and therein lies my first conflicting thought…

I feel there are extremely intelligent and well-intentioned people putting massive amounts of time and effort into developing solutions leveraging blockchain…….

And I also feel there are many ill-intentioned people putting massive amounts of time and effort into marketing blockchain solely for financial gains….

The problem is:  I can’t always tell the difference between the two.  Part of this is caused by the ambitious, and sometimes downright confusing, claims made about blockchain’s potential.  In the span of a week I saw articles claiming blockchain could solve the refugee crisis, the worlds water problem, and fly a rocket ship.   It’s not that I dismiss the claims, but the marketing is so beyond saturated that the well-intentioned initiatives are at risk of getting lost in the sea of opportunity-chasers. There is immense marketing value in using the word ‘blockchain’ right now.    Even in writing this post I wondered “Will people think I’m talking about blockchain just because it will attract ‘clicks’?”   That’s unfortunate.

The other challenge of such wide-ranging claims is ensuring we don’t lose sight of the reality that blockchain by itself cannot do any of those things…

As a distributed ledger technology blockchain offers tangible security and redundancy benefits, while creating a common data repository that can span across organizations.

As a distributed ledger technology blockchain isn’t a solution by itself, it requires business logic and presentation layers to ultimately make the data relevant and valuable to users

Take the example of diamonds tracked by a solution leveraging blockchain (Everledger).  The headlines you’ll see about that project read something like “Diamonds tracked from mine to customer using blockchain”.   Here’s an interesting observation- I’m not sure in my career I’ve experienced a scenario in which such a highly technical concept (blockchain), usually reserved for the IT department to swoon/debate over, is almost always put front-and-center as the singular driver for making such functional innovation possible. Hence why so many C-suites now have something-blockchain-related on their strategic agenda (yet- with all due respect- most probably couldn’t explain what it does)

It therefore warrants a bit of caution-  back to the diamond example- when diving into the project itself you find that blockchain is just one component in a total solution (e.g. business logic, reporting tools).  Take a look at the sample traceability report provided- http://mydtl.io/t/QSLIS013. It’s clean, elegant, user-focused- but again blockchain by itself doesn’t magically generate that report.  Can you say because blockchain is used as part of the solution the data is more secure and transparent? Absolutely - the overall solution is ‘better’ because of the benefits blockchain provides.  But again, the key phrase there is ‘overall solution’.

The importance of making this point is to ensure industries and those responsible for procuring solutions within organizations recognize when vendors are simply using the term ‘blockchain’ in hopes of gaining a marketing bump vs vendors who actually understand how the technology fits into an overall solution.   To put it more succinctly-  An inadequate or immature technology platform can’t ‘add blockchain’ and all-of-a-sudden become a viable solution.

Finally, let’s turn our attention to where (in my opinion) blockchain comes into play for pharma serialization/traceability.  I think blockchain in pharma is intriguing- there is definite potential but there are also needs to be a sense of grounding.  While I don’t see myself being involved in actually implementing blockchain solutions in the next 6 months, I believe the work that is being done to determine blockchain’s place in the space is immensely important- primarily so that the pharma industry doesn’t get ‘passed up’ in terms of adoption.

I think the industry, by and large, first has to come to grips with the fact that most of the effort and investment made to date has been on solutions that can only barely be considered traceability solutions and instead recognize they are serialization compliance solutions.  This is the first step to then understanding how true supply chain traceability, leveraging blockchain, can provide serialization compliance and also significant business benefits.

I think blockchain is clearly the leading candidate to create the ‘virtual’ centralized database for US DSCSA 2023 compliance that is so sorely missing today.  It will also help if the FDA provides more strict guidance/requirements on blockchain’s place- even so far as identifying a blockchain provider.  It's likely a pipe dream but I say this because, the pharma ‘blockchain’, as is true for any industry, should be governed by an independent, not-for-profit entity (assuming the FDA doesn’t sign up to do it themselves).  Such a path would also provide the opportunity to more firmly enforce the use of global standards.  I worry in lieu of such a guidance from the FDA we will be left with numerous commercial ‘blockchains’ each with their own rules of engagement and integration requirements- essentially replicating the same data exchange challenges the industry faces today.

How vendors approach blockchain is equally intriguing.  Certainly, a new set of names have recently appeared- companies looking to use their foundation in blockchain as their foray into the space.  In the near term this is likely to bring about some interesting new partnerships but over time it’s only natural for these providers to move more into the traditional L4/L5 arenas- something that should only be viewed as a positive by the industry as more competition is still sorely needed.  We also can’t deny that some of the more traditional track and trace vendors don’t want to see blockchain in pharma succeed (despite what their marketing might say) for the simple reason that the benefit of blockchain- providing a connected ecosystem for the exchange of traceability data between disparate organizations- strikes at the very heart of the singular perceived benefit which millions of dollars has been spent promoting.  Identifying such vendors will be easy.  

• Those who understand blockchain’s role in the space will offer support for blockchain integration- recognizing the need for separation between the ‘open’ data exchange layer (e.g. blockchain) and the applications which can submit/retrieve data from the blockchain and make it relevant to its customers.   
• Those on the defensive will offer ‘blockchain’ as a component of its own solution- continuing the ‘closed’ mentality and ultimately limiting the benefits its customers realize by adding complexity to the data exchange.

If blockchain does revolutionize pharma serialization/traceability and ultimately provide that pan-industry data sharing/management capability then interestingly the differentiators for pharma serialization L4/L5 providers will experience a long-overdue correction.  Focus will shift (as it always should have been) towards items which today are viewed more as nice-to-have intangibles-  platform ease of use, user-centric reporting, analytics, platform stability and customer service.  Remember- simply adding blockchain to your pharma serialization vendor isn’t going to bring about some magical turnaround- if the platform doesn’t work today, it’s still not going to work with blockchain.

As for practical adoption in the industry- I’d love to see more attention on blockchain pilots focused on the capture/exchange of T3 documents as a starting point- if nothing else to ensure there are some ‘quick wins’ realized.   This will eliminate the complexity of trying to capture everything on a blockchain (e.g. all events) and I think will also be a more approachable concept for the industry at-large to comprehend.

I’m interested/curious/excited to witness the next phase of blockchain in pharma.   The next 12 months represent a pivotal point in understanding how the technology will be deployed, how rapidly and who the main players will be.  My consistent message to the industry applies here as well-   maintain oversight of your serialization/traceability programs to ensure your solutions can adopt blockchain when the time is right while also recognizing it’s not the ‘easy button’ for serialization compliance and supply chain traceability.

Integration of serialization into key manufacturing processes

Today's post provides a current assessment of the integration of serialization into common pharma manufacturing processes.  Certainly not a new topic and one that has been covered in numerous articles from colleagues and vendors.  As a point of reference- nearly 18 months ago a great overview was provided by David Colombo of KPMG in Pharmaceutical Online (Read it here). 

How far have we come since then?   Did the industry heed the message or are we still treating serialization 'in a vacuum' and missing integration into key operations?

Let''s dive into two key manufacturing processes where ensuring proper serialization integration is critical.

Serial Number Reconciliation-  No pharma manufacturer (following GMP) would release product without quantity reconciliations being performed and documented in batch records.  Quantity of items packed, quantity of items sampled, quantity of items damaged/destroyed- this is the norm of any packaging operation.  So why should it be any different with serialization?    

With serialization an entirely new data set exists (serial numbers) which must align with the quantities documented in a batch record- So it stands to reason that checking the quantity of SNs against the quantities in batch records each and every time seems like a painfully obvious concept-  many will assume it's being done.    But if you are a manufacturer and have ever experienced mismatches in your serialization data then quite clearly reconciliation was missed somewhere along the way.  (Comment and let me know your experiences!!)

So, what's preventing serial number reconciliations from being a pervasive concept? In many cases it comes down to limitations of serialization solutions.  Many vendor solutions don't support the ability to do serial number reconciliations in two main areas:

• Packaging site/CMO solutions which only allow the collation and communication of serialization data to manufacturers at the time of shipment.    Following good practices- if a manufacturer only receives the serialization data for a batch after the product has been loaded onto a truck it is way too late in the process.  When designing packaging site/CMO integrations identify trigger points during the batch process which will support reconciliation (such as upon lot closure).    If either your CMO's system or your system can only support integration at time of shipment- be prepared to justify the risk of not being able to perform serial number-to-batch record reconciliation until 1) after you've had to provide batch release and 2) after your product is already in transit.  What's the preferred capability in this area? Some solutions are able to take in batch record inputs (even better if they are electronic batch records!!) and automatically compare against processed serialized data- providing alerts when quantities do not reconcile.  

• Solutions which do not support capture/communication of 'end-of-life' data (end-of-life covers any scenario where a serial number is no longer continuing in the commercial supply chain).  This has long been a heated debate within the industry with organizations deeply rooted on both sides of the fence- in regards to DSCSA some choose to follow the regulations and only capture data for the 'good' items that get shipped/sold while others will require tracking of all allocated serial numbers.  For what it's worth- I've always been firmly planted on the latter side.   I summarize the debate like this-  there is no right or wrong answer, but if you are only tracking the 'good' items then the extent of your organization's capability is serialization compliance, not true traceability.   Again, for many organizations there is nothing wrong with that as they're likely still 'checking the box', it just means additional areas will have to be addressed before being able to take advantage of other benefits of true traceability (e.g. brand protection, process/quality efficiency monitoring, etc.)

Serialized Shipments-  For many organizations, capturing serialized shipping information is still a future endeavor.   But as 2019 requirements (both regulatory and industry driven) start to surface the need to track items from manufacturing through distribution arises.   One practice, however, that appears time and again is the concept of 'Ship by Lot'.   In the old, quantity-based world this concept had merit as it was an easy way to update quantities of items in ERP systems.  In a serialized world, however, continuing this practice brings significant risk.   The principle is simple-  You don't ship lots, you ship shipments.   

What allows this practice to continue in a serialized world is that often a shipment equals a lot.  Again, in the old, quantity-based world it was easy to say "Ship Lot 123" and then enter the quantity actually being shipped.  In a serialized world, performing the same action "Ship Lot 123" makes a big assumption that all serial numbers which have been previously associated to that lot are now being shipped.   The problem is that organizations are not going through and actually scanning each serial number as part of an explicit shipping step and therefore systems have to 'infer' which items are now being shipped.   The serialized world relies on inference in situations where aggregations exist (physical product packed and sealed in larger physical containers) but shouldn't rely on inference for creating significant traceability steps (e.g. shipping).    

This practice is most commonly seen at companies who have chosen not to aggregate for the time being but are often 'forced' into generating a shipping step by either their vendor or a downstream customer.    Additionally, certain vendors have made this practice too accessible by making it a standard (and even recommended) capability in their platforms.

My summary:  Wait until you are aggregating before you start capturing serialized shipping information unless your volumes are so small you can warrant doing an explicit shipping step.   Moreover, once you are aggregating there is no reason to continue a practice like 'Ship by Lot'.   Instead perform a true shipping step which includes scanning of parent level containers.    

For companies which DSCSA is the first serialization regulation they are having to meet the key is to anticipate what life will be like once the regulations are actually live. Certainly, the focus needs to be on ensuring you are meeting the 'letter of the law', but don't overlook how properly integrating serialization into key manufacturing processes can help identify issues with your serialization data well in advance of it becoming a compliance item. Ultimately manufacturers are responsible for managing serialization within these common processes on a day-to-day basis- Don't let your vendor push you into practices that are easier for them to support, but introduce risk to your operations.