This post was originally posted on Jessica’s personal blog, Jessica’s TechBio Adventures, on December 19, 2022.

At the beginning of this year, I joined a small, mostly-academic team tasked with getting an Australia-wide phage therapy system up and running. We had a fridge full of Sharpie-labeled Eppendorf tubes with phages (bacteria-killing viruses) inside, and a box of bacterial isolates from about 20 patients who’d been failed by antibiotics. We also had a freshly approved clinical trial protocol that would let us treat each patient with their own set of phages (as long as we could work out how to make them and prove they were pure enough). Oh, and just under a year of remaining grant funding.

Fast forward to now (December 2022) — we’ve set up a ‘minimum viable phage production/purification/QC system’, and it’s actually working. We treated our first patient in mid-October, our second in early November, and our third last Tuesday. Each was infected by a different bacterial strain, in a different part of their body, and each required their own personalized set of phages, but all are being dosed and monitored in the same way. All patients are doing well, with the first two showing clinical improvements and no trace of their infections. (I can hardly believe it!)

With this post, I wanted to try to distill what I’ve been learning from the process of going from 0 to 3 patients treated, using a phage production pipeline we set up from scratch, set up by a few part-time scientists fresh out of (or still in) academia, on a tiny budget. I hope it can be helpful to others building in bio, considering joining a bio startup, or just curious about the behind-the-scenes of how your infections might one day be treated 🤓.

I would also love to start exchanging notes with others building in bio, because I think the main things we’re all learning could probably apply across the board. Maybe you’re making cell therapies, or viral vectors, or cultured meat, or synthetic cheese, or trying to make bacteria do cool things like eat pollution… there is no shortage of fields I am crushing on these days! (And a ton of incredible people sharing learnings and doing the work to bring it to the surface — see especially the Founder-led Biotech Summit recordings from this year — so much gold).

Here’s my attempt to contribute to that conversation!

The trouble with phages

Phages are amazing bacteria-killing snipers, and can pick out any bacteria in a crowd and kill it. But for phages to work, they need to be matched to a patient’s specific bacterial strain. Because of the need for this personalization, it’s been hard to get them through large scale clinical trials. This means there are pretty much no phage drugs on the market. So the only option is to do phage therapy on ‘compassionate’ grounds (which is allowed in many countries when everything ‘standard’ has been tried).

The trouble is, even if you have this ‘compassionate use’ channel available, you still need the other half of the equation, which is the phage itself. Unless you can convince a biotech company making phages (there are a few, but not that many) to give you some of theirs (assuming they have the right one you need), you have to arrange to have it made (and matched to the specific bacteria causing the infection) yourself.

What we set out to do

Long story short, Phage Australia is a new academic-medical consortium that got a grant to set up a phage-matching and phage-making system so Australians dying of infections could get safe phage therapy. I joined that team early this year, after our startup, Phage Directory, helped them source phages that saved a little girl. Their team had a bunch of phages, and was ready to figure out how to do the rest.

Even though I’d been ‘in’ the phage therapy field for years, from research to organizing crowd-sourced phage treatments, I was not prepared for the challenge I was signing up for — actually getting a phage therapy center off the ground, where there wasn’t one before.

Scaling phage therapy is hard (but not because of the phages)

Right now, there’s a narrow window when a patient can have phage therapy — sick enough that they qualify for phage therapy, not so sick that they won’t die while waiting for phages. How do we respond to patients fast, without compromising the quality of our product, with limited personnel, equipment and funds? How do we do error-free work in a scaleable way?

The main thing I’ve learned over the last 9 months is that phage therapy is hard, but what makes it hard has very little to do with the phages or the science. When I reflect, it’s really all about communication, documentation, process design, prioritization, and overwhelm-reduction. Why? Probably because it’s a high-stakes environment (patients’ lives on the line, AND we’re always running out of funding), and it involves other people (both internal team, external collaborators, and people from completely different worlds, like the medical system). Entering this world has given me a bit of whiplash, but it’s also been a refreshing change from the last time I was at the lab bench doing academic research. This stuff matters right now, and there’s no time to lose.

Here are my top 10 learnings from this wild and crazy year:

1. We can make all the phages we want, but if we don’t know who gets which, we fail

I used to think rapidly making a pure phage preparation was the main important work we were doing. I took it for granted that we’d be able to keep track of which phage was for whom. And in the beginning, we had no issue with this — a patient sample came in, we got to work figuring out which phages to make for that patient. But as we started accepting more and more patient samples, we realized our system of tracking samples was straining, and thus we were at risk of preparing the wrong phage for a given patient. And it wasn’t just a matter of internally tracking what we were doing. Doctors would call us, asking if we’d found phages yet for ‘that chap with the Pseudomonas’. Pretty soon, we had several Pseudomonas isolates, and we couldn’t be certain we were both talking about the same chap.

Hence my realization that keeping track of patient samples and phage batches is not just a nice-to-have, it’s actually just as important (or more) than the quality of the phages we make. Even with the cleanest phage batch, if we give the patient the wrong one, the patient could die. So we need to devote just as much attention to our internal sample tracking systems and communication systems as we do to our systems for checking our phage preparations are sterile and safe.

(Apparently we’re not the only ones to hit this realization later than we’d like — I recently heard an interview with Emily Leproust, founder and CEO of Twist, talking about how in the early days, they could make lots of DNA, thousands of genes synthesized for their clients, on-time, perfectly done — but they couldn’t figure out how to keep track of which to send where. They quickly identified the need to prioritize building internal software to track their samples, and we’re going through the same thing now.)

2. Write protocols for the tired and distracted version of yourself

I used to think I was a great pipettor, with great attention to detail; I trusted myself to catch mistakes if I made them before they caused problems. I’ve come to realize that I’m only ‘great’ under certain conditions (e.g. evenings as a PhD student with the lab to myself, no one bothering me, a reasonable number of samples, low enough stakes that I know I can repeat it the next day if I screwed up, etc…). Unfortunately, those conditions are almost never reality anymore. Once I started pipetting for hours, pipetting a LOT, and needing NOT to screw up, things changed. More errors started to happen.

If we’re going to go from treating 3 patients to 10 or 30, we need our protocols to be iron-clad. We need to design them so it’s hard to make mistakes even when we’re tired, sleep deprived, and distracted. And eventually, if we’re going to scale, our protocols need to be hard to screw up even when done by people who didn’t write them, who are less aware of what is important, or even who have never worked with phages before.

Ultimately what this requires is separating the person (and their ‘skill’) from the task at hand. If errors happen, it’s the protocol that’s not good enough, not the scientist.

3. If you get annoyed by interruptions, your protocol is error-prone

I’ve learned that the processes I need to replace, redesign or automate are the ones where I feel a twinge of annoyance if someone talks to me while I do them. For example, pipetting into a 96-well plate. With colourless samples, it’s all about watching where I’ve pipetted and repeating numbers in my head so I know which sample I’ve just put where. That just won’t do anymore. I’ve since taken steps to add visual aids, like writing on the lid, and physically moving the lid over to mark which column or row I’m on. It’s not perfect (and really, we need liquid handling robots here in the near future), but I’m trying to get to a point where I can be interrupted or answer a colleague’s question without messing up what I’m doing, and using that as a benchmark for whether my protocols are where I want them. And the bonus is, even if I don’t get distracted, having more visual aids and fail-safes helps my brain stay relaxed and ready to anticipate other issues, and I don’t lose stamina as quickly. So now anytime I get the sense that I’m annoyed it’s not quieter in the lab, I take that as a signal that I’m doing something error-prone, and I need to look at my process.

4. Write protocols as if you might be hit by a bus at any time (then practice getting hit by that bus)

Team science is not something I knew how to do in grad school. It was just me, doing independent work, beside other people. I thought I was on a team, but I wasn’t really. If I was sick, my experiments would wait. Now, we’re driven by a larger purpose — the patients are waiting, the medical team is starting treatment on a certain day. If I’m sick, or I’m dealing with something else, someone else on our team needs to be able to jump in. They not only need to know what to do, but they need to know things like which version of which protocol to use, where it is, where and how to input information about how it went and what data was collected, etc. In other words, protocols need to include not just the stuff that happens at the bench — but what comes before and after too — almost like each protocol has a ‘meta’ layer that connects it to the larger picture of the work being done. I think the latter is often what is missing when you’re not doing team science (probably since we do that part in our heads when in single-player mode).

Now for part two: practice. I’ve found that the best way to check if your protocol works is to get it into the hands of a second person asap. Pretend you really have been hit by that bus. As soon as a protocol is written, get it in the hands of a second person who’s never done it and see if it actually works. Have them duplicate it, mark it up, then discuss it together and make changes — now save that as a new version, and use that going forward. This practice has really helped our team highlight the invisible assumptions hiding in our protocols. It’s been hard to get used to, but it’s the best feeling in the world when you can truly hand a piece of work over to someone else. (And it’s also definitely necessary if you’re going to scale up your operations).

5. If you want to help someone, spend a few hours as their shadow

With a small team doing high-stakes, time-sensitive stuff, someone is bound to get overwhelmed. Periodically. And bad things happen if the whole operation depends on that person. But we all know the feeling — someone asks ‘how can I help’ and now the overwhelmed person has yet another job to do — trying to delegate. One thing I’ve found effective is to offer to be the overwhelmed person’s personal assistant for a few hours. Just be there, ready to take direction if needed.

I wouldn’t have thought this would work, but one day I was overwhelmed — our manager had been asking for things she could take off my plate. Coming up with something to delegate became yet another thing on my unending to-do list. One day, she showed up in the lab and just quietly watched me do what I was doing for a while. Soon enough, she’d found about 5 things she could do to help me. (Things like ‘I’ll replenish this box of syringe filters’ or ‘aliquoting into vials takes longer than I thought, here’s a way we can expedite it’).

Another time, I offered myself up as an assistant to a swamped team member. She said she didn’t need it, but I told her I was there for her anyway. She eventually threw me some tasks as they came up (things like labeling tubes, putting away materials, washing glassware, etc). Much like helping someone in the kitchen — just being there with them for a while and making yourself available can be a big help.

Also, I think spending time as the ‘assistant’ puts you in direction-taking mode, not leadership mode, so your brain ends up with extra capacity to come up with time-saving solutions and shortcuts. (You can then bring them up later when the swamped person has brainspace to talk about it!)

6. If it works, go with it — you can innovate later

When I started, part of the team was working at a university core facility across the city to do phage purification using modern, ‘state-of-the-art’ ultrafiltration and chromatography methods. They’d figured out a way to purify phages for patients using the tools the pharmaceutical companies use for other products like RNA and antibodies. But there was one problem — no E. coli phages were allowed in that facility (they had some valuable E. coli strains for clients they didn’t want getting phage-infected). Well, the first patient we needed to treat was an E. coli patient, and that was our only purification setup. What to do?

The team contemplated getting the phage-making outsourced to collaborators in another state, or not treating that patient and waiting until we had a different patient ready with a different species infecting them. Or, we could set up a wholly different phage purification system in our home lab, but we’d have to use ‘quick and dirty’ phage purification methods like cesium chloride or octanol. There was hesitation from the team to use these methods — I think in part there was a sense that it would take away from the innovative, higher-tech methods the team had been using. If we had success, we’d have to tell people it was just with the old/low-tech methods. People might think we weren’t innovative.

In the end, I gave the ‘old-school’ methods a try, and they unexpectedly worked beautifully. Endotoxin levels in our phage preparations were reduced almost to zero — we could actually treat this patient. Suddenly, it seemed so obvious it was the right thing to do.

Will we move back to our fancy chromatography setup when we can? Yes. There are advantages to it, especially related to being able to automate and monitor the process. But by swallowing our pride and temporarily moving to an ‘old school’ technique for the purification step, we were able to treat our first patient months earlier — we got our first win! Not only was this motivating for the team, it also meant we could start working through the post-purification parts our process (like quality control, formulation, regulatory approval, and therapeutic monitoring of the phage within the patient) months earlier. It meant we were able to present on our successful production of an approved phage product (and successful treatment of a patient with it) months sooner. By letting go of the need to be/appear innovative, we accelerated our learning process and hit key milestones faster.

7. Don’t be afraid to scale down to scale up

When I started this work, our purification process was losing a lot of phages. So we started trying to increase the number of phages going in, so we’d end up with enough for the patient at the end. My brain instantly went to scaling from mLs to Ls. I set out to make a few litres of phages, and that went well. But then, I started realizing that these larger volumes were actually causing new downstream problems, as we now needed additional equipment (or a lot more manual labour using our current equipment) to concentrate that volume to prepare it for our purification steps.

For a while I tried to solve this by getting our phages to grow to higher titres, so I could start with a smaller culture and remove the need for additional concentration equipment. But coaxing phages to grow at higher titres proved to be much more difficult than the concentration woes.

Around this time I realized that the ‘low-tech’ purification system I had recently started using (see lesson #6) actually showed much less phage loss than our more modern purification system, meaning we actually could get away with much smaller cultures if we used the old-school method. We could actually get a few thousand doses of phage from just a 100 mL culture! At this point it dawned on me — why are we scaling up volume? Let’s stick to ~100-mL cultures and keep using the old-school purification method for now. It’ll give us more than enough phages given the patient volumes we currently have (~1 at a time).

This shift has served us well; by staying open to temporarily going down in scale, rather than up, we were able to get unstuck with our process, leaving us with more capacity to move forward and address the next issues in our pipeline.

8. Only make as much as you can use

Around the time we started treating our second patient, I realized again that our phage batches, even though small, were too big — this time for a new reason. The ‘expiry date’ the hospital drug committee was comfortable with was 30 days (unless we could prove it lasted longer). Since we haven’t had time to collect that data yet for most of our phages, we have to stick with that default for now. So suddenly our ‘2000 doses’ that lasts 30 days is actually 60 doses, because after the first 60, we have to throw the rest away.

I used to think studying phage storage stability sounded like a nice-to-have, but wasn’t really an issue. So we hadn’t prioritized those studies. Then I realized, wait — we have to repeat a ton of work when our phages expire. And if we have to discard a bunch, we effectively didn’t make it in the first place. We were excitedly touting that we were making 2000-4000 doses of phage per batch. But with our number of patients needing that phage (generally, 1), and our 30 day expiry window, we effectively only had 60 doses. I now have a new appreciation for the need to collect phage storage stability data — the longer we can store our phages, the bigger our batches become without any increase in volume of production. Also, when we have to remake phage every 30 days, that adds so much labour (both in the phage-making and in the keeping-track-of-which-phage-expires-when work/coordination labour that suddenly exists). In other words, your big batch is actually small if your storage time (expiry window) is small.

For now, until we have >30 day stability data, and we’re only treating ~1 patient at a time during a single month with any given phage, I’m now contemplating having us only make 60-dose batches (2 doses per day x 30 days, which is the max that one patient would need in a month). If we get 2000 doses from 150 mL, maybe we should be making 5- or 10-mL batches? Seems kind of wild, but this might actually help us scale to more patients by temporarily giving us back more of our time (so we can actually go collect that stability data!).

9. Work with regulators early; if there are no rules, write them yourself

There isn’t currently a regulatory framework for phage therapy in Australia. One day the TGA (Therapeutic Goods Administration) asked our team to tell them how they should regulate phages. Otherwise, they’d do it themselves. First instinct: we’re busy setting up our process, we don’t know what to write — let’s get to this eventually, once we’re further along. Luckily Jon, Phage Australia’s fearless leader, emphasized that this was an unmissable opportunity, and we needed to prioritize this ahead of anything else.

Over a series of conversations we brainstormed how we would address each aspect of risk we could see with our phage products. We looked at what others did around the world (Sciensano in Belgium had approved a document based on phage batch safety; a US military team had published a phage genomic safety paper) and relied heavily on Jon’s opinions (as an ID physician himself) of what would be relevant and reassuring to Australian physicians and hospital ethics boards.

After this, I opened a blank word document and started drafting out the structures of four reports: a ‘Phage Safety Data Sheet’, a ‘Host Safety Data Sheet’, a ‘Phage Batch Report’ and a ‘Phage Susceptibility Report’. Our team populated the first version of each with fake data and showed it to Jon, who told us which aspects were irrelevant or missing.

Eventually we had a draft of each we were happy with. These documents went through another iteration once we populated with our first set of real data. We realized some of our defined ‘requirements’ were overly cumbersome for us to meet. We quickly redefined those to match what was practical, while minimizing any compromises on safety. And then we submitted the package to our hospital drug committee. Lo and behold, it satisfied them — they gave us the go-ahead to start treating our first patient with our first phage product in October of this year. Now, it’s the document package we’re submitting every time. There’s still a ways to go to actually get this set of standard documents adopted by the TGA, but for now, it’s sufficient to reassure our local hospital drug and ethics committees, as well as our treating physicians and hospital pharmacists, and that’s huge.

If we had waited, or shied away from this task of helping define the rules for regulating our own phages, we would have been stuck satisfying standards written by those without an understanding of the practicalities of therapeutic phage production (or the real safety risks, for that matter). And because of our knowledge of the product and risks, we were undoubtedly able to get this done much faster than any external committee might have. If we hadn’t written them when we did, chances are we’d still be waiting for approval and our patients would still be waiting for their phages.

10. Aiming for perfection can cause more harm

Often it’s hard to think that the patients we’re trying to help might not get a perfectly clean phage. What if there are questionable genes in the genome of the host strain? What if the residual endotoxin is a bit higher than our instrument suggests? We constantly puzzle over these feelings, but are then reminded that these patients have no other options. While we’re discussing the safety of our phage products and the lab strains we produce them in, the patients are actively infected with bugs that are actually, demonstrably choc-full of harmful genes. Their bodies are already filled with endotoxin. So at a certain point, we need to set a reasonable safety standard for our products, meet it, and move on. Our lab strain that may or may not have a few genes that technically line up with virulence factors is probably safer than the strain burrowing deeper into their bone tissue the longer we discuss it.

(Of course, this thinking can easily go too far — that’s why we ultimately defer to the doctors to make the decisions to administer our phages, who are trained to first do no harm).

A work in progress

This is all a work in progress, and it’s felt like fires have been burning since about March. But our cycles are getting shorter, and we went from taking three months to make one batch of phage for one patient, to treating 2 patients at once with multiple phages for each, on a few weeks’ turnaround.

Our phages are passing sterility and endotoxin testing, regulators and hospital ethics/drug committees are giving us passing grades on the paperwork, and our patients are doing well!

In the lab, we’re cutting down on the brainpower it takes to keep track of things in our heads, and we’re making fewer errors. Now when we’re asked by the big bosses/hospital pharmacists/drug committees what we’re doing or what we’ve done, we’re able to (more or less) serve up the data with a few clicks without too much stress. And when one of us (me!) went on vacation recently, the remaining team didn’t even need to call me once; the protocols worked, and the decision-making and data-recording systems we put in place held water. What a dream!

There’s of course so much left to do, but we’re moving confidently into the scaling phase now, and it’s still feeling completely surreal to have gotten to this point.

Thanks for reading this far! I hope you’ve enjoyed a window into some of our trials and tribulations. Would love to hear what resonated, what didn’t, what spaces you all are building/working in, and what you’ve been learning as you build in bio.

Wishing you all a lovely re-charging season — see you back in the new year!

—Jessica

THANK YOU to Stephanie Lynch, Ali Khalid, Ruby Lin, Jon Iredell, Nouri Ben Zakour, Jan Zheng, and the rest of the Phage Australia team. Incredibly grateful to have gotten to work with you all, & still pinching myself that we’re actually building this.

If you want to learn more…

I’ve been sharing some of the nitty-gritty of our phage-making adventures on the Phage Australia blog (also cross-posted on our weekly phage community newsletter, Capsid & Tail):

• How to start making phages for therapy — I write about my process for setting up a new phage-making system in the lab, including making sense of a dizzying array of options, managing overwhelm, and resisting ‘optimization creep’.
• Therapeutic phage-making: how my first batch measured up — I share results from the first batch of therapeutic phages I made.
• How do we prove our phages are safe? — I share my foray into learning about phage quality control and working toward setting up a basic phage QC system.
• I gave a talk on some of our challenges on the manufacturing side at the Bioprocessing Network Conference (Sydney, Australia) (Oct 2022)
• I presented a poster on our phage therapy pipeline at the Australasian Virology Society conference (Gold Coast, Australia) (Dec 2022)