Richard, would you please get us started with a little of your personal history?
Sure. My name is Richard Grant; I’m a mechanical engineer and have been a project manager through my nearly-forty-year career. I trained at the University of Melbourne and have been working in the cell therapy space for 20+ years now. I started in cell therapy at Invetech with a project for Argos Therapeutics, automating the production of dendritic cells and mRNA for a cancer vaccine, and that project turned into a business offering for Invetech, being the start of their journey as a developer of custom cell therapy equipment and disposables. I ended up leading the cell therapy group during my last six years at Invetech. After that I worked for FloDesign Sonics, a startup company with an ultrasound acoustic-based cell separation and cell selection technology. Two years later FloDesign were acquired by Merck KGaA and folded into MilliporeSigma. I participate in conferences around the world and have written about cell therapy, equipment and disposable design, GMP production techniques and associated automation and technology.
I met Anthony Davies in 2010 when he was at Geron. He and I—along with two other former-Geron employees—got to know each other and would of course see each other at conferences during those intervening years. We always thought it’d be a good idea to work together at some point. This is such a typical reality of the CGT world: we’re a small subset of experts and we tend to all know one another through some avenue or another, and our interactions are often at global conferences. Amusingly, I most often see my fellow Australian CGT experts in other places around the world rather than at home.
To cut a long story short, I’ve been with Dark Horse for over a year and a half now, bringing my device and consumable development experience and expertise to bear in support of Dark Horse clients. My work focuses largely in what we refer to as our “Device Development” core capability, where we have a good-sized group of deeply experienced engineers and experts in device and consumable development, ranging from such items as true ‘medical devices’ under ISO 13485 (such as delivery devices and other device components of combination products) to pieces of custom manufacturing equipment. We’re finding it to be a rapidly growing piece of our portfolio, differing from traditional “Device Development” due to the particular requirements of the CGT space in which our device team have deep experience.
So, if that traditional view of Device Development focuses on building the devices themselves, how does your expertise tie in with any of the other eleven of Dark Horse’s “Core Capabilities?
I would say it’s similar to the way in which we can see threads of Quality Assurance and Project & Program Management (P&PM) in each of those capabilities. Therapy development is such a complex proposition, and those who find themselves with a successful commercial product at the end of the day are those who paid attention to required detail throughout the process.
For example, devices (disposables and equipment) used in manufacturing drug product require their own evaluation before they can be used in development and especially for therapy manufacturing. Sometimes clients—or future investors—need the tires kicked on a range of different options (equipment and consumables) to identify the one(s) most suited to fit their manufacturing operation. The tie-ins with manufacturing are easy connections to see. But even those clients who come to us with regulatory affairs challenges, for example—something seemingly distant from the “device” selection or development—may find their equipment decisions tied to which pieces of equipment have been documented effectively to ensure that they can negotiate their regulatory hurdles more easily, both in terms of expense and schedule impact.
This is why I came to work for DHC: there is no other group out there able to provide clients with expert knowledge across the lifecycle of therapy development and up and down the supply chain. My colleagues and I are able to support any degree of complexity that our clients require, whether they need a development program overview or a deep dive on any element in the process, whether the ask is on behalf of a therapeutic developer or an investor, or in support of tools & tech providers.
Creating safe and effective drug product requires the appropriate equipment, and equipment is run by software and interacts with consumables…all of which need to be documented, tested, and regulated. The work we do in Device Development ties directly back to this.
So you’re saying that even if a client doesn’t think they have a device-specific business need, they may still make use of our engineers’ knowledge base because everything that happens in therapy development is impacted by all of the materials and equipment that are being used to manufacture the drug product?
Correct. In all of these cases, you’ll always circle back to the materials that you use to manufacture the product. The materials question is always also a device question, whether the client is creating something customized or using devices that are readily available. I don’t encourage people to consider devices only in a one-off capacity as a solution for a particular process step, because it’s a much bigger piece of the puzzle than that. Devices used are embedded in every single manufacturing process step and need to connect seamlessly with the upstream and downstream equipment and consumables.
It’s common to think of a device as an individual separate element, but any device’s usage is also connected to all materials of construction of any associated consumable or disposable. For example, regulatory authorities want to understand the leachables and extractables characteristics of all plastics that have product contact that are used in the manufacturing process. This means that anything that comes into contact with the cells or process fluids during the manufacturing process is subject to approval of global regulatory bodies.
That’s a significant impact on the production process regardless of whether the client defines their equipment as GMP manufacturing equipment, or categorizes it as a medical device under ISO 13485 (more on this later).
Let’s think through some common avenues for client support that might connect in some way to device development expertise.
Right. If we explore the ways in which DHC can help our clients using our skills from Device Development, it can take a number of forms. We see device needs come into play when we perform tasks such as reviewing regulatory strategies, doing a gap analysis, URS development, and supporting project management, as well as in creating a full development program.
Let’s start right in the middle of the process, with one of the most common scenarios we experience across the practice: DHC being called in to do a regulatory path assessment. When making regulatory decisions, we’re considering the path that is most reasonable for our client to achieve (depending on their end goals) as well as what barriers to entry the client might be (purposely or otherwise) setting up for competitors in the future. When reviewing a regulatory path, many questions come up, including ones about the devices and equipment used.
Regulatory requirements can be exceedingly granular and preparing for a regulatory review is most effective when clients know what to expect and what documentation will be needed. We have incredibly extensive experience in helping developers walk these approval paths—INTERACT meetings, CATT meetings, IND submissions, etc.—through regulatory agencies around the world. We don’t disclose any clientele (unless they’ve chosen to speak of working with us themselves), but I can say that for a majority of the CGT therapies approved by regulators over the last couple of years the clients have worked with us in some capacity.
So, mapping out the appropriate regulatory path must take into account regulatory requirements for all the materials used to manufacture the process. What about another example you’ve given, of a project gap analysis?
I think of this as our “bad cop” persona. Gap analyses are essentially health checks and are necessary in so many scenarios: as an internal part of the development process, when confirming standards at a third-party manufacturing partner, or if there’s a VC or PE client interested in an investment or acquisition.
When we do this, we come in to assess/review an existing program and pressure-test it—kick the tires, if you will—to provide an unbiased view of readiness of the development program. Outputs can include assessment of design, product cost, product fit to market, development cost, manufacturability, project timeline feasibility, and recommendations for improvement.
We embed with the client for a few weeks, assessing documentation structures, team process and progress, data review, and identify whether the processes in place are executing as they are intended to.
It helps to identify hidden costs as well: does this bring the total cost of therapy down by enough for a difference to be made in the market? Does the product actually fit the market need? What's the development cost? Is the program going to take too long or be too expensive for the client to end up with a successful business case? How manufacturable is it? Are the disposables being used suitable for this business case? Can you make those disposables in the sterile form, at a cost of the market will bear?
We look at the timeline and related feasibility: are the short-term milestones achievable? Is the long-term goal realistic? Obviously, we also recommend improvement in any areas necessary.
Which takes us to your third example, URS development.
In this case, we might be talking about starting by conducting a VoC (Voice of Customer) project to identify needs with prospective users, or maybe we’re reviewing a project concept that’s already relatively locked in from a design perspective.
Once the need is identified, we can build the foundation for the development, generating the requirements necessary to product a suite of foundational documents: URS, PRS, SRS, PDD, program GANTT charts, etc.
Sometimes you have to go right back to the beginning and generate a user requirement specification (URS) for the product. That is a list of the things that the user requires of your product and the performance that you'd like to achieve in that area. In cases where the client is the developer of a piece of manufacturing equipment, the URS is typically written from the perspective of what the client’s client (that’s the end User who is using the piece of equipment to manufacture a therapeutic) needs from the system, and it becomes the foundational document for all other documentation, product design descriptions, etc.
We always say this is a document that should be as short as possible…and as long as it needs to be. It's a tricky balance: especially to not jump to a solution (i.e. assume a design path) when writing the document but instead to clearly specify what will be needed from the product, so that the range of ideas that become the solution (further down the road) take all facets of the design challenge into consideration.
It requires significant experience to provide a document with the right level of detail. Overdoing document specs can lead to unnecessary time and cost being added to the development program and subsequent verification and validation testing whereas oversimplified specs have their own set of downstream negative effects. As with any project, having experts on board can definitely be the difference between doing the project right the first time or having to revisit it at a later, more expensive stage.
Another example of expert knowledge streamlining a process is that of P&PM: project and program management.
And that’s the next example on the list, right?
Right. We can be called on to manage a product development which requires P&PM work. We bring our therapy development expertise to assist the client with management of either their internal resources or a third-party developer, and as previously mentioned, any development process can involve the materials/devices in use for the therapy product development and manufacturing. Those of us who work in Device Development add our engineering experience to assist the client team.
P&PM outsourcing allows clients who don’t have the necessary device/material experience and don’t have the HR budget necessary to recruit a full team to nonetheless be intentional and cost-conscious about the science behind their therapy. Engaging DHC can help accelerate the path to market by providing an honest broker who understands the current and desired future development state and can make accurate estimations of steps needed before the product is ready for market.
So, we’ve touched on several ways in which DHC can support clients’ device development needs, including charting the regulatory path, performing project gap analyses, assisting with URS development, and providing P&PM support. The final example you mentioned was the ‘soup-to-nuts’ example of the full Device Development offering.
Yes, and this is probably the broadest example in terms of how we provide device development support: either fully supporting the development of a device/consumable or creating and then developing that item/product/GMP manufacturing equipment. In this case we pull together a team of people to plan and run the program, often at arm’s length from the client: we do each stage of design and engineering to deliver the final product.
The first decision to be made in terms of device and equipment creation is whether the item in question is GMP manufacturing equipment (developed under GAMP5 guidelines) or a medical device (complying with the ISO13485 standard). Those are two similar but distinct end points with their own profile. The engineering and development processes for these are quite similar on the surface: identifying requirements, mapping those requirements to tests, and then continuing on through the verification and validation V model.
A critical difference comes into play when the equipment will be defined as a medical device, though, which is that the documentation process encompasses the possible creation of a Device Master File (MAF), in which we document the design so that confidential, detailed information about the product and its design can be provided to the FDA. (A MAF allows proprietary information about a particular device or system to be securely held because the sensitive information stored in the MAF is reviewed separately by regulatory bodies and can be referenced by our client’s clients in their regulatory submissions without those confidential details having to be disclosed to them. A therapeutic developer can confidently use a device which has an approved MAF because its regulatory compliance has already been assured.)
An example of a common issue is software documentation, whether for equipment or a medical device. If the initial software design is not documented from the beginning—following a process that maps inputs to outputs and allows for systematic verification and validation—then achieving regulatory approval is very difficult. Software is a complex area, and it’s been proven uncounted times that having to go back and retroactively review, verify, and modify software to comply with standards is often much more expensive and time-consuming than rewriting the code from the beginning.
Does that cover the examples of where you’d see tie-ins between Device Development and common client asks?
Those are five of the most common examples, but they just scratch the surface of the ways in which the internal expertise of one SME dovetails with another. We also see device knowledge being intrinsic to enabling process automation, consumable tooling, and other scaling considerations, in which the use of specialized equipment (remember: all those associated parts must be documented and tested!) can allow for an increase in the quantities of product that can be manufactured. Process automation, consumable tooling, and scaling is how we see small-scale or academic breakthroughs eventually translate into larger-scale manufacturing. As the CGT field matures, this becomes more and more central to client requirements.
On the modeling side of things: our engineers can ensure that the baseline expectations and inputs for quantitative modeling—using our proprietary Pegasi program—are accurate, so that planning and capacity modeling, and the financial decisions that follow, are taking the right elements into consideration. (Read a related analysis on modeling capacity for future blockbuster CGT drugs here.)
From a preclinical perspective, we know that academic institutions and teaching hospitals have historically been excellent incubators for new therapies but are challenged in preparing for clinical trials due to manufacturing considerations: namely, that scientific equipment and GMP-level production equipment are different, so there’s often a translational element at play to ensure comparability when scaling up. One of the most common mistakes we see is companies choosing to enter phase 1 or phase 2 paths without refining the manufacturing process and its associated devices and consumables.
We help to identify all of those sorts of challenges before they become difficult or costly to remediate. In short, our device development experts can provide invaluable insight for any client work that touches on manufacturing at any stage of the process.
.jpg)