Do I or do I not need VRS?

Predictably after the Nov 2018 DSCSA serialization milestone passed serialization vendors needed to find their next marketable offering.   Enter VRS.

The result has been a flood of marketing materials highlighting the advantages and/or readiness of  one VRS service over another.  In turn this has resulted in pharma manufacturers raising questions to me about how best to approach their "VRS requirements".

My immediate response to that question is-  "Are you sure you need a VRS?"

The purpose of this post is to clarify what is required under DSCSA as it relates to verifications and the role VRS plays in meeting those requirements in certain scenarios.   My hope is to help some manufacturers avoid being 'sold' a new solution feature by their provider when its actually not necessary to meet their requirements.  Moreover, I hope to make clear that by simply signing up for a VRS a manufacturer doesn't magically meet all the verification/suspect/illegitimate product handling requirements under DSCSA.

First let's define what DSCSA says about verifications and the upcoming milestone in the regulation that is making this such a hot topic.

Come November of this year wholesalers will be required to perform a verification of any returned  items which they hope to resell. (e.g. saleable returns).    To meet this requirement wholesalers will be reliant on manufacturers to provide the data necessary to decide if the item is 'verified'.    There are generally two ways to achieve this:  Either the manufacturers share their serialization/traceability data (e.g. EPCIS) downstream with the wholesalers or the manufacturers respond to a verification request.

Since many manufacturers are far away from being able to provide serialized/aggregated data to their downstream partners, the focus has largely turned to responding to verification requests.

For manufacturers, the ability to respond to verification requests is nothing new- in fact- the ability to respond to certain verification requests for non-serialized items has been in place since the first milestones of DSCSA went live.   And as of last November, manufacturers are required to respond to verification requests for serialized items.

Most importantly, nowhere in DSCSA does it state that in order to meet the verification requirements one must leverage VRS. While DSCSA does define the timelines for when each segment of the supply chain must be able to respond to verification requests, it does not define how those verification requests may be made nor does it define how the responses must be provided.

Point being, the industry could meet DSCSA verification requirements by leveraging phone calls, emails and carrier pigeons if it wanted to.

But alas, the industry, largely driven by the big wholesalers, recognized the absolute efficiency nightmare such non-automated approaches would have on their operations.  In response VRS was born- a way to systematically submit verification requests to a manufacturer and rapidly receive a response.  VRS meets DSCSA requirements for saleable returns verifications and saves big wholesaler's operational efficiency-  happy days.

But what happens if I'm a small manufacturer who only sells to small specialty wholesalers or skips wholesalers altogether and sells direct to pharmacies... do I need VRS?  The answer is possibly (and probably) no you don't.    It all comes down to your customers because VRS is not a DSCSA requirement, it's a US pharma industry requirement if you do business with customers who require you have a VRS capability in order to ship product to them.

So, if you are unsure the next step is to talk to your customers.  Ask them their plans for meeting the Nov 2019 wholesaler salable returns requirements. Ask them if they will be requiring their suppliers (i.e. you) to leverage VRS.  You might find many of your customers are not even planning to use VRS.  You might find instead they prefer to receive the EPCIS data for the items you ship them (which means aggregation and ensuring your L4/5 system can adequately handle such downstream exchange becomes your top priority).  Or you might find they are perfectly fine relying on emails/phone calls/carrier pigeons as the volumes of saleable returns verifications is anticipated to be quite low.

If none of your customers say they will require VRS then, for the present time, you are safe not having a VRS capability.   What you must do however, no matter what your customers say, is ensure you have the proper processes in place to respond to verification requests and further have the processes to handle suspect/illegitimate product.  (See https://www.jennason.com/dvm)

But if you do have customers that expect/require you to have a VRS capability then shop around.  The very nature of VRS requires it be inter-operable- meaning it doesn't matter who your customer's VRS provider is or your neighbors VRS provider- you can choose whomever you like.  Go with your current provider's VRS feature if you don't want the headache of introducing a new vendor.   Or if you think your vendor is charging an astronomical amount for the service there are plenty of offerings out there that will layer on top of your existing providers system. (but be prepared its not a 'flip of the switch' if you go that route)

As always my message to manufacturers is- maintain oversight of your serialization program, and in the case of VRS-
A) Don't let your vendor simply sell you on a feature that may not be needed
B) Recognize that VRS covers the ability to respond to saleable returns verification requests - it does not satisfy your legal requirements of having processes and systems in place to respond to all types of verification requests and, moreover, it does not satisfy your legal requirements of having the processes and systems in place for handling suspect and illegitimate products.

VRS is critical.... but don't ignore the other (and more significant) verification requirements under DSCSA (Marketing Material)

Under DSCSA all segments of the pharmaceutical supply chain are required to have systems/processes which manage requests for product verifications.   For manufacturer’s all DSCSA provisions related to product verifications are live today, meaning not only are manufacturers responsible for meeting the law, but also that the FDA and other agencies may audit these systems/processes.   Such audits have already resulted in 483s (https://www.rxtrace.com/2018/10/mckessons-dscsa-483-explained.html/).

Much attention has been placed recently on the ability for manufacturers to handle saleable returns verifications in advance of the Nov 2019 deadline for wholesalers. While saleable returns and related solutions (VRS) address direct compliance requirements of DSCSA, it is critical for all segments of the pharma supply chain to recognize that the ability to handle saleable returns verification is only one small piece of DSCSA verification management.

Jennason performed a thorough review of verification requirements under DSCSA and related guidance’s and identified the following:

• There are no less than 6 high level quality and regulatory policies which must be developed and/or integrated into existing SOPs.  These polices must cover critical procedures including the handling of verification requests,  FDA requests for information, suspect and illegitimate product handling and trading partner and FDA notifications
• In total the 6 high level policies must define no less than 25 DSCSA required tasks, data capture points, notifications and record retention activities.
• The overwhelming majority of these required tasks/activities are performed outside of your serialization system.  In most cases, your serialization system will only address the requirement to perform product identifier verifications.
• Many verification requirements have strict timing for when responses must be returned to the requestor- often within 24 to 48 hours.
• Verification requirements impact a broad set of functional teams within an organization including, at a minimum, quality, regulatory, supply chain, manufacturing/distribution operations, R&D/testing and legal.

DSCSA Verification Workflow Map
Blurred for confidentiality. 
Reach out to Jennason for a full review

In response to these complex requirements Jennason developed a suite of offerings to help companies understand their total exposure to DSCSA verifications and ensure proper capabilities are in place.

DSCSA Verifications Workshop-  A half day workshop designed to educate internal teams on the full extent of DSCSA verification requirements.  The workshop also facilitates a gap analysis between current quality/regulatory processes impacted by DSCSA verification requirements and desired future state.  Participants are also given a demonstration of the Jennason DSCSA Verifications Manager.

Jennason DSCSA Verifications Manager.   DSCSA Verifications Manager provides an automated workflow solution which ensures companies are completing all required steps in a DSCSA verification process including

• Managing requests for verification from/for trading partners, FDA and saleable returns.
• Capturing verification results and generating response reports to provide to requestors.
• Managing the required suspect product process including quarantine and product investigation.
• Managing the required illegitimate product process including quarantine, sampling and disposition.
• Automated generation of required FDA forms (3911) and trading partner notifications.
• Automated e-mail reminders to ensure verification responses are provided within the required 24hr time period.
• Reporting dashboard which tracks frequency of verification requests, breakdown of requests by product, lot and other attributes and measuring of on-time verification response performance.

More information can be found at https://www.jennason.com/dvm

Jennason Serialization Test Tool.   Jennason’s industry-leading automated testing solution for L3/L4/L5 serialization systems supports DSCSA product identifier verification testing.  Every serialization system has different parameters by which product identifier verification is performed.   To understand how your system operates its critical to test the product identifier verification process with items in a variety of statuses and locations.  Pharma companies leverage the Serialization Test Tool to simulate common serialization use cases, such as commissioning, aggregating, shipping/receiving and end-of-life (e.g. decommissioning, destroying), generate the corresponding test data and communicate that data to their L3/L4/L5 serialization system.  This enables the rapid testing of your system’s product identifier verification process under any business scenario.

More information can be found at https://www.jennason.com/solutions

Contact Jennason today for more information on these offerings.

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.