The Healthtech Podcast · 2026-07-08 · 1h 7m
Key moments - from our scoring
Substance score
59 / 100
Five dimensions, 20 points each
At Babylon, Jamie encountered a critical bottleneck: while medical software could be built iteratively in theory, the regulatory process forced a waterfall approach. Rather than shipping weekly updates to their triage chatbot, regulatory ambiguity around what changes required new submissions created months of delays before any code could deploy. This insight led to Scarlet, a notified body founded by Jamie and James specifically designed for iterative medical device development. Unlike legacy notified bodies optimized for established product categories like Medtronic pacemakers, Scarlet targets the emerging landscape of software-based devices - clinical AI, triage tools, diagnostic software - where existing regulatory frameworks create uncertainty and slow innovation. The company spent three years navigating Dutch regulation (with support from the Netherlands' Ministry of Health) to become the first notified body built from the ground up for modern software development practices. Scarlet's competitive advantage isn't against other notified bodies in their domains; it's providing an optimized pathway for next-generation devices where regulatory precedent doesn't yet exist. The conversation covers how regulatory ambiguity compounds delays beyond simple processing time, why LLM-as-a-component (rather than LLM-as-a-product) represents the near-term regulatory reality, and how companies can navigate conformity assessment when building innovative healthcare software.
A notified body is an organization designated by a member state to assess whether medical devices (including software and AI devices) conform to regulatory standards before they can be marketed, ensuring safety and efficacy.
Before submitting any application, companies must consult with regulators or notified bodies about what changes (e.g., new indications, patient population changes) require new regulatory work - this pre-submission uncertainty, not post-submission review, creates months of delay.
Scarlet doesn't compete in categories where legacy notified bodies have strong precedent (like pacemakers); instead, it provides optimized processes specifically for emerging medical device categories like clinical AI and iterative software where existing regulatory pathways don't fit well.
In practice, LLMs are regulated as components within larger systems (e.g., clinical scribes, triage agents, diagnostic support tools), not as standalone products - the entire workflow and how the LLM integrates with other controls is what gets assessed for conformity.
Three years of working with Dutch regulators (the Ministry of Health, Youth and Sport in the Netherlands), involving several thousand pages of documentation, before issuing the first certificates in 2024.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode contains substantive content about medical device regulation and iterative development, but is heavily diluted by extended personal asides, office comparisons, recruitment messaging, and tangential stories (retinal implants, doctors' career paths). While Jamie's core insights about notified bodies, QMS systems, and regulatory ambiguity are valuable, they occupy perhaps 25-30 minutes of a 67-minute episode, leaving significant filler.
there's this artificial constraint on iterative development and deployment that Scala is today, which is to build a notified body, the ground up, oriented around, providing a process that makes iterative medical device development possible.
the ambiguity creates a lot of delay. And I think it's reasonable. If you actually look at the medical device regulations, they have a really hard job to do
Jamie presents solid, non-obvious insights about how regulatory ambiguity (not just timeline delays) slows innovation, and the novel idea of building a notified body from first principles for iterative software. However, the core framing - that existing regulation is slow and new tech companies should lower barriers - is well-trodden B2B ground. The quality management system / factory metaphor is established regulatory doctrine. Limited counterintuitive thinking.
I think like a common misunderstanding when you talk about what the problems are, ah. Or have been dealing with notified bodies is like you assume that the problem is, oh, uh, the delay is you have a complete application, you hand it in and then you wait for six months
The goal of Scarlet is to try and pull medical technology from the future into the present.
Jamie is a co-founder and CTO with directly relevant credentials: medical training, software engineering background, data science experience at Babylon, and three years of grinding through regulatory approval to launch Scarlet. He has built something genuinely difficult at scale. However, he's also a founder using the podcast partly as a recruiting and brand-building platform, which slightly dilutes pure operator credibility vs. someone with no skin in promoting themselves.
I originally did the medicine, um, and then became a software engineer and then ended up doing a bunch of data science.
we took three years to get through the process and several thousand pages of documents later
Jamie provides concrete examples (Babylon triage chatbot, Floy's opportunistic screening, Science Corp retinal implants) and specific regulatory details (quality management systems, notified body designation, Netherlands Ministry approval). However, most customer wins are vague or protected by NDAs; no financial metrics, exact timelines, or quantified impact are shared. The episode relies heavily on abstract discussion of regulatory principles rather than detailed case studies.
One that we were talking about at our recent event, um, was Floy, who builds um, um, computer vision models for radiology. But the insight is for opportunistic screening.
we signed quite a few customers, we issued a bunch of certificates, we started getting devices under our belt
The host asks reasonable setup questions but rarely pushes back or dig deeper into contradictions. When Jamie makes bold claims (e.g., "you have to have a really good reason not to choose Scarlet"), there's no critical follow-up. The host spends disproportionate time on office descriptions, weather, podcast metrics, and recruitment messaging rather than rigorous interrogation. Missed opportunities to challenge assumptions about market size, competitive positioning, or regulatory risk.
Um, should we talk about the weather? That's pretty standard to do in the uk, isn't it, like, complaining that it's hot.
I've got up here, like, even, even the Wikipedia page for notified body says that one of the main criticisms of notified bodies is the varying levels of expertise among them
Computed from the transcript - who did the talking, and the words that came up most.
In this episode of The Healthtech Podcast, James is joined by Jamie Cox, Co-Founder and CTO of Scarlet - Europe's only notified body specialised in software and AI medical devices. Jamie shares how a frustrating experience building AI triage software at Babylon Health led him and co-founder James Dewar to a radical idea: build a notified body from the ground up, designed specifically for iterative software development. They explore why the current regulatory system creates artificial bottlenecks for health tech founders, what it actually means to regulate an LLM as a medical device, and why making certification faster and cheaper could fundamentally reshape who gets to bring products to market.
Transcribed and scored by The B2B Podcast Index.
Speaker A: Everyone knows that the only way to build good software is to build it iteratively to climb the hill week by week. Can't climb the hill because there's this, like, artificial constraint on iterative development and deployment that Scala is today, which is to build a notified body, the ground up, oriented around, providing a process that makes iterative medical device development possible.
Speaker B: Hey, everyone. This week I've got Jamie with me, co founder and CTO of Scarlet. Uh, Jamie, how you doing, man?
Speaker A: I am well. Thanks for having me on.
Speaker B: You're very welcome. You're very welcome. Um, should we talk about the weather? That's pretty standard to do in the uk, isn't it, like, complaining that it's hot. Should we just do that for, like, 30 seconds and then we've just got it out the way? Uh, it's really hot, isn't it? I'm sweating loads.
Speaker A: Look at this background. The sky is blue. It looks like you're in the basement, though.
Speaker B: Are you in the office in your, uh, office?
Speaker A: And this is why everyone should come and join Scarlet, because we have a beautiful office here in Fitzrovia. We got a wraparound balcony at the top. The sun is shining.
Speaker B: Fitzrovia.
Speaker A: Look at that. This is the place to be.
Speaker B: Honestly, it looks. It does look glorious.
Speaker A: And if there's ever a candidate that's weighing up an offer from somax or Scarlet, they'll look at your basement there, they'll look at this beautiful tower, and they'll say, this is the easiest choice ever made.
Speaker B: I know. Honestly. Honestly, they'll be like, uh, I'm trying to sell them on this underground bunker, which is actually just a spare bedroom in my house that's, like, got a barely painted room, like, enough that you can just make this podcast background look good. And there's you in Fitzrovia on some rooftop. Um, Honestly. Unbelievable. Just one of the many reasons why Scarlet is a glorious place to work a Jamie.
Speaker A: Exactly.
Speaker B: Well, listen, looking forward to getting to this. I've had James on the podcast previously. So, um, we've. We've heard the story of Scarlet before, I guess for those people that have listened to it. Um, not expecting everyone to listen to, uh, every episode of this podcast. Although I did meet a guy, Ali, yesterday at an event, who had actually listened to every episode of the podcast. First person I've ever met that has done so.
Speaker A: How many have you done?
Speaker B: Um, 400 and something. Almost 500, basically.
Speaker A: So he's your whale. Have you. Do you know that idea? Like, like, uh, people on Only OnlyFans have very skewed distributions of who watches them. And it's just one guy.
Speaker B: Yeah, interesting.
Speaker A: Just doing all of it.
Speaker B: This expl explains the watch hours. The 10,000. The 10,000 downloads a month are just.
Speaker A: Ali is your whale Ali.
Speaker B: Well, you are. I was gonna say, if you're listening. You are listening. But thank you for saying that to me last night because actually that gave me a real boost. Um, and I love that. And you know what he said as well, it's just really nice. He's like, it's just good content. Just enjoy it. Oh, it doesn't need to be that deep. Like you just, just enjoy it. Lovely. So, Scarlett, Jamie, you tell me your founder story because, um, you guys were at Babylon together, weren't you? You and James?
Speaker A: Yes, we were at Babylon. Was this like 20, 2019. Um, so we're at Babylon. We were working on the triage, the chatbot. And um, we were in the same team. We were trying to make the chatbot better. I'd actually, I was there and like, big part of my role. So my background, I originally did the medicine, um, and then became a software engineer and then ended up doing a bunch of data science. Um, we can go into that if you want. Um, so when I landed at Babylon, these problems at, uh, the intersection of bit of medical domain knowledge, bit of data science, bit of software engineering, that was really my wheelhouse. So the problem of interest was trying to measure the performance of this triage app. So you're asking questions like, do you have a headache? How bad is the headache? Where is it? And so on. You try and ask few enough questions, they don't abandon the flow and enough so you can come to a high confidence triage decision. Like, this doesn't sound serious, you should stay at home. Or like this does sound serious, go to any this kind of thing. And the problem I was interested in is like, how do we measure the performance of this thing? Um, um, which is obviously an interesting question. There are various angles on that question, like what is the clinical performance? But then what's the user experience? You could get very good clinical performance if you have very long flows potentially. And this is all the efficient. But in reality, you ship that thing, no one's going to get to the end. So you have to penalize a bit for that. And figuring out what's uh, a good way to measure whether this is good or not and if it's safe and if it performs as we intendable was what I was doing. So I built out a bunch of benchmarks and built a bunch of automations so that those would run um, in our continuous integration uh, environment. And um, and the idea was we make changes, we get results, we hit the button, we ship the software. And that turned out to be a fantasy because you can do all of that, you can automate away all of the admin part of running those kinds of things and figure out what numbers you want. And then at the end you have to go through ah, a regulatory process. Um, and part of the automations involved trying to inject bits of that data into Google Documents and then those documents going into a sort of vortex. You don't know what's happened for a long time and before you know it, it's been a long time before you've shipped any software. Um, so that was really the insight that I had at Babylon was that I was surprised by how hard it was to build medical software software iteratively. Everyone knows that the only way to build good software is uh, to build it iteratively, to climb the hill week by week. And this is kind of counterintuitive to some people, um, particularly from the medical device world, um, there's this assumption um, that if you change things frequently maybe you're going to break it. It's safer to leave things alone. Um, turns out not to be the case with software. The analogy I used to use when I was talking to people um, about the importance of doing iterative software development and particularly through the lens of safety, was remember um, when there was this artificial constraint on um, how often you could ship your software because we used to have to burn it onto CDs and then you'd mail the CDs out and be like how many bugs were in that software and how long did it take to get it fixed? And right now that's kind of where we are with medical software because you can't get the reset, you can't climb the hill because there's this artificial constraint on iterative development and deployment. So it really limits what you can build. Um, and um, so that was really the insight was like how can we make it possible to build great products in healthcare um, that need to be built iteratively? Um, turned out that when you scratch away at the surface of that our background, uh, James and I wasn't like we weren't from regulatory backgrounds. We were um, technical people like with software and um, data science and some domain knowledge, medicine. And um, we scratched away at the problem and eventually um, we found the solution that skull is today, which is um, to build a Notified body, a new one, um, that is from the ground up oriented around providing a process that makes iterative medical device development possible. So you want to ship an MVP quickly, then you want to iterate fast. Um and building a native body from the ground up today you don't have to do it the same way as it's been done before. You can get new kinds of people with new ideas that aren't um, from the legacy industry and have different various biases around how it should be done. Um, you can build technology uh, and you can have a process that anticipates that you are going to build technology for your process. You can build your notified body iteratively itself um, and figure out what works. Um, so we're able to do something quite different. Um, and it wasn't easy. Uh, I think at the beginning it's one of those stories where naivety can be um, a benefit. Like when we landed on this solution, we're going to start one of these things. I remember taking phone calls and just like the um, day to day was just hustling trying to talk to anyone who knew anything about that, who'd done a notified body before or was close to that or knew someone who had. Ah and the universal message was like uh, why would any regulatory agency invest time in two bozos in a basement who don't have any hard experience in testing inspection certification. Um and I think we were naive enough to think well we're just going to kind of go for it anyway. Um and it took three years to get through the process and several thousand pages of documents later, ah, and many learnings uh later and um, we were lucky to find some great people who helped us do that. Um, some very um, um forward minded people particularly in the Dutch regulatory, um in the Ministry of Health, Youth and Sport in the Netherlands, um, who really wanted to do this the right way and saw the problem. Um and so we were able to make progress and get there. And that was really the big first milestone in the company. It's kind of a weird company to build. The normal story of building a company is you're trying to find product market fit at the beginning. Can I offer something that someone wants and how will I know when I have um really iterating fast even on the problem you're trying to solve, not just the solution. Um and for us the problem was always the same and we knew that a part of the solution was going to be getting uh, becoming a notified body. So we weren't in the first three years like flicking around then, we didn't have any customers. Our customer that we were trying to delight were the regulators, um, who had to approve us. Um, and that was the first three years of the company's life. And then after that the next. That was like 20. Was that like 2020 to 2023? Something like that. Um, then the next big milestone was issuing our first, uh, certificates. And that, that was the story of, of 2024. It's all very well to have things down on paper, but when the rubber meets the road, uh, when you're actually trying to do this thing and to get through a process with a customer and set a fire medical device and meet, um, all the requirements and do it the right way and do it in most transparent way for the regulator, um, there are some surprises there and it takes a lot longer than you think it will. That was the story of our first certifications in 2024. We learned a bunch from that. And then last year, um, we'd done it. We knew that the process that we had, there were a lot of improvements we can make on the customer side to make the customer's life easier on what we required from them to make it easy for them to submit stuff to us and make it very clear upfront what they needed to submit. Um, so to make the process go faster. And we worked on a bunch of product features to help customers do that well. And then 2025 was like the first year where we really ramped up. We signed quite a few customers, we issued a bunch of certificates, we started getting devices under our belt. And that brings us to today where I think you have to have a really good reason not to choose Scarlet, but you want to build a medical device iteratively. Um, that's what we're here for. Um, and increasingly we see that the most innovative companies choosing us because they, because they see the value in that.
Speaker B: I want to ask you about the, I guess notified bodies in general, because just to give people a bit of the lie of the land here, notified bodies obviously assess the conformity of products before they then go to market. So you're assessing does this device, and it could be software as a medical device, that even that could be AI as a medical device, or it could be a hardware device. But you're assessing does this conform to a set of standards in order to be safe to hit market. And that's broadly what you are doing as a notified body. So you are given that power by, uh, a member state to do that, I guess is broadly how you'd define Uh, a notified body. But it's really interesting because even on I was looking earlier, actually, before you joined, I've got up here, like, even, even the Wikipedia page for notified body says that one of the main criticisms of notified bodies is the varying levels of expertise among them, including differences in test results. And it's like you said, you know, there's not, not all, not all are created equally. And actually a problem to solve was to create a notified body in what you described is solving a problem that we have at the time, which is the iterative nature of software. And actually that being quite front of mind. And it's interesting, isn't it, because, I mean, how, how, how did, how did you see. I mean, like you said, it's really bold to be like, I'm going to start a notified body. Like that is a, that is a bold thing to do. And, and, but at the same time, if you see a gap, then there's a gap. Right? So when you were looking at it and initially making that decision that this is what you were going to do, is it that you looked at it and went, okay, in the innovation pipeline, the biggest bottleneck that I can see, or the biggest enabler of innovation broadly that I can see as a notified body that gets this. Was it that way round? Or, or did you then look at all of the notified bodies that existed and go, well, actually, they all lack expertise in this specific thing and we want to be, you know, we want to be specific in this thing and that's how we're going to, we're going to go to it. Like, how did you think about the. Go to market for like, developing a notified body?
Speaker A: Yeah, I think this story is actually kind of a typical one for a new company, which is we just experienced the problem ourselves. We were trying to build a software medical device. We wanted to build it iteratively. We wanted to incrementally add new features to it. Um, and how that would be handled by Notify Body was quite ambiguous. So I think like a common misunderstanding when you talk about what the problems are, ah. Or have been dealing with notified bodies is like you assume that the problem is, oh, uh, the delay is you have a complete application, you hand it in and then you wait for six months and then you get the results. And that's the delay. That's the difficulty is that it's just in their courtroom time. And that may be true sometimes, but I think it's much more nuanced than that. When you get into the details of what actually slows down the process. For example, if you're building um, say the chatbot and you want to add new indications to it or change the patient population, um, there's a question in the development process, what does this imply for the regulatory work that this will require for us to do this? And it's not always objective. It's like a kind of consultation, like well let's go and talk to a regulatory team about that or let's get an opinion from someone else. Maybe we can try and get in contact with the notified body and align with them on their interpretation of this. And all of that's happened before you've created any paperwork. And it's just this ambiguity creates a lot of delay. And I think it's reasonable. If you actually look at the medical device regulations, they have a really hard job to do, the people who write those, because the puzzle they have to solve is they don't want to rewrite it every six months. So it has to be very general. So it has to cater to the diversity of all kinds of medical device. They have a bit of an escape hatch which is they can provide without changing regulation these guidance documents afterwards. But this is how to interpret these in the context of for example new technology. But there's a limit to how quickly they can do that and there remains often ambiguity for the most innovative devices. Um, so that's the gap. You can have a notified body, like a storage notified body that's got some great devices on their books. If you look at some of the, the all time classic medical devices like Medtronics pacemakers that are probably on the books at the bsi, they've I would imagine built an in house assessment team for that product family. It has a lot of compounding context on those products and has done for decades. Um, and they probably anticipated that and over time warped a process around that. But then if you have a new kind of product family or a new category, people trying to build software that addresses new problems, it's not obvious how you talk about the indications because they're quite general, um, and they have new considerations or require reinterpreting the requirements of regulation. It's quite natural that existing bodies might not have uh, catered their process to that or have built teams around those. And that's the gap. And so that was the gap we identified and the gap we experienced. Um, um, and that was our go to market, that was our beachhead. It was like, well for projects like these and we think that what we're building here could be valuable. It's kind of obvious the value to the healthcare system. If you could do a uh, really good medical triage people um, could do that without going and making A's more and more busy or having unnecessary appointments with gps. The benefit of that is obviously, and it's kind of obviously a problem that it's difficult to develop software like that. Let's go and see if we can provide as a go to market uh, a service that's really great, that's what you're doing. And that category turns out to be quite large like um, the other classics in that category like you mentioned earlier, like radiology software. So um, um, like computer vision on radiographs, that's been around for a while as well. But I think that relative to the magnitude of the medical device industry incentives maybe haven't played out for anyone at the legacy notified bodies to sit down and really say what does an excellent process look like for the people who bought products like this? Who are these people? What are their expectations, um, and what would help them with what they're trying to achieve? Um, and that's what we did. Um, so we don't really try and compete with the other notify bodies in the categories that they serve their customers well in. That's not the name of the game. The name of the game is to provide an optimized pathway for the next generation devices, um, where there isn't a good prick test that's coming yet and we can do that for them.
Speaker B: So the big question then is are you in the game of regulating AI? Yes, I assume, but LLMs specifically and are you in that game? And I guess what I'd like to understand is there must be people trying to get LLMs regulated. I believe it has happened in Europe that an LLM has been regulated. Um, and I know people like, well there's some AI mental health chat bots that have got you know, an LLM being or a signal being monitored on the way into the LLM and then checked on the way out of the LLMCLM is a small part of a larger stack and that getting regulated. Um, so it's being regulated as part of lots of different things. But I guess the conversation has moved on somewhat. I think I might, you know, I think I chatted to James about this last time about, you know, do you see the day where an LLM will be regulated? And the answer then was yes. I think it's actually moved even more nuanced now in terms of it's definitely being regulated as part of different stacks. Um, but what are you seeing who's coming to you from an AI LLM perspective and asking for regulation as a medical device? And, and I guess, do you have any feelings on it as to what good looks like or, you know, is that more or less intensive for you guys? Do you have to do extra checks and balances in your process? I'm just interested in your process when it comes to that.
Speaker A: Obviously there's a, like, there's a lot of like, um, like it's tempting to frame the question in that way. Like LLM is a medical device, AI is a medical device. But I wonder if it's necessarily the most, uh, helpful framing of the question. Um, at their best, companies that are trying to build products that solve healthcare problems, they don't define themselves by whatever. Like the details of the solution they're building are like technically they care about the problem they're solving. And um, what does LLM as a medical device mean? I think it can mean a lot of different things to different people. Like there are companies that are interested in problems where an LLM is going to be like a part of the solution. But it's rare that the LLM, the actual token generator is uh, is the product. It's not going to be. Right. It's like a component in a much bigger, uh, architecture that solves a particular problem. So I think LLM as a medical device is like, it's useful to the extent that people, um, there is a conversation around that. So it provides some anchor. But uh, really with what we see that there are a bunch of workflows. Um, normally the architectures involve lots of different components and um, LLM is a helpful component in many ways and there's lots of useful problems in healthcare where people are applying them successfully. Right now, you see, the scribes, um, clinicians love the scribes, um, and they're having explosive growth. Um, and companies in the US and Europe are building products that clinicians love. Um, but it's a component, right? If you're recording a conversation, yes, you can generate a note. Um, it wouldn't be a very good note if it was just a direct subscription. So you can do a bit of summarization. That's interesting. LLMs probably have something to say about that. Um, then maybe you're interested in um, suggesting a differential probably. Um, quite interesting, uh, shape for that as well. Um, that the input is text and the output is something more categorical. It's not continuous. Right. You're just picking items from a discrete set for the differential. Um, but Then maybe there are other parts of the workflow where say you want to automate um uh, uh a triage flow which involves phone calls and you want the model to make some decisions. You have more of an agent set up there where you have a harness for the model and you provide some tools that enable it to take actions like call patients, um, order tests, um, these kinds of things. And then there's a component in our architecture, um, I think that these things are obviously valuable. There's no debate about that. Ah, um, and it's not the final thing. I don't know if you saw um, the demos. I think it was a couple of weeks ago DeepMind put out some, some nice demos of um, these models that show um, um. So it's like a teleconsultation and um, there's um, a uh, person who's like oh I feel like my eyelid's drooping and the um, system is passing the video feeds. Yeah, come a bit closer. Um, and then starts giving instructions like can you look upwards? Can you look to left? Can you look right? And this is not like um, like a turn based um text in, text out, text in, text out. It's like a fully continuous um video uh, in uh, audio in uh and then video out, audio out. Not turn based like what can interrupt you. And this is like. So we're not talking about what we currently consider when we mean LLMs. I think when we say LLM right now most people mean like some turn based textual exchange is what most people call mean when they say that uh, I see it more continuous. I wouldn't want to draw a massive distinction between ah, architecture which involves an LLM and um, some other things and an architecture like the DeepMind demo, um, which is quite different um, and involves a um, multimodal model. Um, I think really it's about the best productive framing is the problems they solve and then the technologies are ah, interesting. But then I think zooming in on a particular component and being like how are we going to regulate that Is the wrong frame for the question. You need to look at the aggregate and the architecture and the problem it solves and the risks inherent in the aggregate and how you could test the aggregate which is all the components and the system and the way it behaves at an input output level for the system, not just this component that you draw the box around and say that's the AI.
Speaker B: Yeah, I understand. I have a question which is. So when you're. In fact I have a couple of questions on this is There anything when you, when you see an LLM involved where it sparks you to apply, ah, any extra rigor, uh, in any areas that you're looking at. Um, and does it force you to think about things in any kind of different ways you would anything else? Or is it just the same line of questioning and evidence as everything else? Um, and I think the second part of this question is what's your motivation as you are assessing something like that? Because I'm wondering, what are you on the hook for? Like, are you on the hook if something goes wrong? Uh, do they look at, uh, what notified body passed this in the first place? Like, let's say it's used on a patient and a patient dies. Like, what does that process then look like? And where does. Where do you fit into that? Where's your liability in this whole process? Like what, what's your kind of. What are you being paid to act? What risk are you being paid to hold? If that makes sense.
Speaker A: Yeah, I mean, there are examples, um, about like, where medical devices have had, um, problems like, um. And the notified bodies who certified them have been like, uh, taken through a legal process as a result.
Speaker B: Interesting.
Speaker A: Okay, the two most recent, the ones that I remember, uh, like a few years back, there was the, um. It was in the news a bunch. There was the. There was a vaginal mesh, um, implant. I think it might have been bsi they involved. I don't want to slander them, so maybe it wasn't them, but, um, um. Did they injured a lot of women? Like, there were some bio. Um. And there was another example. I think actually this example might have motivated some of the. The changes between the previous medical device regulation in Europe and the current one. There was the metal on metal, um, um, uh, hip implants or something like that. And these things like on the articulating surfaces, you'd actually get like particles of the metal kind of like slamming off and it would cause like local inflammation and then even like the ions, like leaching into blood and accumulating like distant tissues and metal. People were uh, injured from those as well. And um, the way the liability breaks down, there are, um. If you're, um, um, making a medical device and you're submitting information to a notified body, like technical information about how you built it and the tests you've run. If you're dishonest, if there's evidence that you're synthesizing data, this is a lie. There's criminal liability there. This is, um, just like it's fraud, basically. You can't do that. Um, so particularly if you're submitting data and it's falsified, that's where it sits on the notified body side, as notified bodies. Um, uh, one of the things that's hard about it is you have to have a kind of on proof system of record and you have to document everything like crazy. And um, um, you have to designate the people in the company that have responsibility for these kinds of decisions and on what basis they're qualified to make those and they have to have the right training and there has to be a review of everything. Uh, and there are lots of steps and there's a lot of documentation along the way. So if something like that was to happen, um, um, heaven forbid to Scarlet, um, our regulator would come to our office and they would say, let's go through this and all of that and we would come through all the details and we would determine whether or not there had been a breach in our process. Like, well, it says here that for devices in these category, you should, there should be someone with this experience who um, um, documents these aspects. Um, and that's not here. So this is, this is your liability. Um, so that would be on the notified body.
Speaker B: That makes loads, that makes loads of sense actually. And that actually makes me start to understand more why the innovation here is you getting comfortable with a new technology or a technology doing something new. So like you said, you know, you guys wanting to get comfortable with regulating software that can be iterative. It then makes loads of sense that why two guys that are building this software and understand the process of building it would then be best placed. That starts to make a lot more sense now. Um, and that really being the innovation here, which I think is great. Um, I have one more question which is, um, on that actually we saw, was it a year or two ago humor came out and said they'd regulated, they'd regulated a thing, uh, software that was then going to create loads of things and de facto they were going to be regulated. They were going to create lots of software as medical device things, uh, that automatically were regulated because the central thing that made them is regulated. And I believe now other companies are doing something similar and regulating, you know, the factory, so to speak. Can you explain that to me and explain, I think for a lot of people wondering, like, how that's even possible, like, surely you need to apply the same level of rigor to everything it creates and how that could even be possible and not to say that you guys regulated that with humor. Um, I don't know if you did or not. But, um, we didn't.
Speaker A: And I do remember the story. I didn't actually spend too much time with this. I don't remember the details, but something that's quite surprising and interesting about medical device regulation and, um, the way it's designed is that idea that you described that you're kind of approving the factory and then it can produce whatever. That idea is actually kind of a core idea in medical device regulation.
Speaker B: Oh, interesting.
Speaker A: Okay, so I don't know if you've heard of, uh, I'm sure a bunch of people who listen to this podcast will have. But this idea of a quality management system. Yeah, exactly. Like a central concept in all medical device regulations. But that's the idea. Right? You should have a quality management system which is kind of like the factory in this analogy, which documents a bunch of processes and procedures for, uh, how you make the sausage. Um, and then the idea of that as a regulatory mechanism is that then, um, you might be able to say something about the sausages being good if the process for producing the meat's particular characteristics.
Speaker B: Got it.
Speaker A: Then in addition to that, of course, depending on the risk class of the device, um, sausages that are produced from the sausage maker, in this case the qms are, are also, um, scrutinised. You make a technical file submission for those as well, and that is scrutinised. Um, but that idea of there being merit in not just assessing the artifact, but assessing the system that produces it is an accepted idea in medical device regulation. Um, and actually in the European regulations, um, the way it works is that, um, there's an assessment of the quality management system. And then depending on the risk class of the device, you might actually be able to put multiple devices on one certificate and they're assessed on a sampling basis. So you can have a certificate with a bunch of devices on it. And, um, the rules will be that say It's a Class 2A device, like a low risk classification, and within the period of the certificate, each of them will be sampled. Um, but you could add a new device to that certificate and it wouldn't have a full device assessment. And the reason the regulator's comfortable with that is because something's been said about the sausage maker.
Speaker B: Got it. Understood. Um, so with all that in mind and everything going on at the minute, what are you excited about? Like, what's going on for you guys? What have you got cooking? Um, it's all the talk of sausage now has got me onto kitchen metaphors, but, um, a little bit hungry. What's going on in the. Yeah. Scarlet kitchen. I don't know, we're stretching this now, but um. Yeah. What are you excited about? What's going on? What are you guys regulating at the moment of what you can say?
Speaker A: Yeah, um, I tried to stay with things that are in the public domain. I've lost track of all of the NDAs I've signed, so it's easier to just keep with things that I know. Ah, it's pretty safe.
Speaker B: That's good.
Speaker A: We really, like I kind of said at the beginning of the podcast, like, you really do have to have a good reason not to not to pick Scala if you're planning on building like devices iteratively. Um, now we, um, we have, I think some, some of the, some of the stories I'm most proud of are actually like you in answering this question. You would think that the best stories would be like who we, who did we sign this week? And like, are they representative of like the latest, greatest, the current buzz, the most exciting. Some of the stories I'm most proud of are the companies we've been working with for, for a couple of years now. And um, they came to us um, with a, with a device and we were able to give them a great timeline on that device that enabled them to raise a bit more money, um, than they were able to grow their team, they were able to build more products, they were able to relatively, uh, early on in the company's life, assume an iterative development process. So they're not trying to retrofit that into a process that's been running for a while. And these companies there are having a lot of success and really, really proud that we caught them on the way up. And many of them now have large numbers of medical devices serving large numbers of people, um, and category wise or theme wise, I wouldn't put them in buckets of. They're in anesthesiology or cardiology or whatever. They're a mixture. We see successful companies that are building um, um in all those categories. To pick a few examples, um, one that we were talking about at our recent event, um, was Floy, who builds um, um, computer vision models for radiology. But the insight is for opportunistic screening. So if you come in and you've had an accident and you've had an X ray or a CT scan or even a routine like a mammogram, to use that as an opportunity, uh, um, to screen. So, um, for example, screening for um, uh, bony lesions, um, in X rays, that's not the Indication for the X ray.
Speaker B: Sure.
Speaker A: Um, um, cardiovascular risk scores, um, for um, on mammograms from calcifications in the vessels, these kinds of things. Um, I recently learned, actually I think you have more recent medical experience than me. Is it the case that most lung cancers are actually picked up incidentally on routine CTs rather than being indicated because they turn up with a cough?
Speaker B: I don't know. Classic medical school exam answer. I don't know. I would have to go away and look it up. Um, but early, early stage cert, I mean you can imagine that being the case in the early stage. I was actually at, uh, guy called Jack Kreineler who does a lot of expedition medicine and is very involved in longevity stuff and does a great chrono futuristic healthcare conference. Um, I was actually at his house. He kind of invited Justin I around for dinner and he was talking about, we were talking about full body MRIs and the controversy around full body MRIs and you know, him actually saying, you know, anecdotally on an N equals one basis, like he, he knows someone, um, the, you know, lung nodules picked up there. So, so, so it's like it, it. Yes, I, I am aware of the cases where um, yes, incidental findings can discover things early and that genuinely being a force for good. It's just that, you know, in the wider full body MRI conversation that can uh, uh, a lot of philosophical and ethical and moral questions start creeping in. But avoiding those. Yes, yes, yes, I sort of get it is what I'm saying.
Speaker A: Yeah. And so like, I guess why I like this example is like this is kind of a cool idea. Like, I think it's an interesting idea that it has merit and um, I think in a, in a, in a pre scarlet world, like pursuing this idea would have been relatively a lot harder because like you probably need like many devices because you want to do not just the uh, opportunistic screen on the mammogram for calcifications, but you also want to do the CT for any bony lesions. You want to do um, brain mri. You basically want to do them all. All of these things are going to be uh, new devices. So it's not like a kind of product where it's like, I'm going to raise much money. I have this flagship, I'm going to raise a bunch of money. It's going to get me through this tunnel of difficulty where out the end I might have a product. This one was much more about you need traction, you need to be iterative, you need to figure out which ones are going to be valuable and which ones aren't. Um, you need to experiment a bit and explore which ones are good and which ones aren't and which ones provide the most value in the healthcare system. And they've been able to do that and they're very successful. We really enjoy working with them. And um, I'm proud that they've been able to achieve that. And I think it's a nice story because I think that what I'll be most proud of, of Scarlett's legacy, is in a fear's home, we look and we can see all of these examples of companies that exist that otherwise might not have or like products that exist otherwise might not have or that are way further along because they've been able to be built iteratively where previously that wouldn't have been possible. And I had this line like, what's Scarlet trying to do? What's its goal? The goal of Scarlet is to try and pull medical technology from the future into the present. And then. And that's the way we're going to solve healthcare, by trying to hasten the arrival of the technology that's going to solve the problems. And I think these stories, um, when you see that and you get a sense that it would have been a harder time if we hadn't been there for them, um, I find this very motivating.
Speaker B: Yeah. And I was actually going to say very similar thing. I actually wrote down that you're basically responsible for a whole load of new health tech stuff reaching market. Because if you extrapolate what you've just said and not treating regulation and notified bodies like the examiner, uh, and actually treating them more like the tutor who then kind of guides you through and assesses you on the fly, then it becomes far more of a, uh, like a horses for courses. Like it makes more sense to me then that notified bodies that specialize in certain areas then guide certain people through and crucially drop the cost. And I think that's the thing is that I think in health tech at the moment it could be really daunting looking at uh, the, the cost of bringing a product to market. And what that generally means is that people have to raise money and they have to raise lots of money. When they've raised lots of money, they now need lots of scale because especially if you've raised venture capital money, you now need venture capital size scale. And that now pulls you into a region of doubling revenues every year and all this exponential growth stuff and blitz scaling and this other like, you know, war type terminology.
Speaker A: I remember it well. I was at Babylon, remember?
Speaker B: Of course. Yeah, well, of course. And you'll know the sites of environments that, that, that, that sets up. Um, and I can't, I, I can't see that always being a good thing in a new version of healthcare. Because if in a new version of healthcare we've got more local problems solved by more local solutions that didn't need that level of scale. If companies like Lovable are dropping the price of, you know, bringing software to market, people like you guys are then dropping the amount that it takes to actually get this stuff regulated. I can see a world where far more things are brought to market with far less kind of massive raises needed and therefore it just being a better market for solutions. I don't think it happens overnight by any means, but I'm starting to see those signs and it being, I don't know, less scary, I think, for people to imagine software as a medical device into the world and then to go about a process. And uh, so I think you're very much part of that, that very much part of the, you know, can we drop the ridiculously high barrier to entry? Um, that does kind of currently exist. And I think, I genuinely think that's, that can only be a good thing.
Speaker A: Spoken like a true bootstrapper.
Speaker B: Yeah. The bias is clear, isn't it? The bias is very clear.
Speaker A: I, uh, don't think that we necessarily have the opinion on that. I think in general, I celebrate, um, when we meet customers and they're very ambitious and they sincerely tell you that what they're building is going to be important for every person on the planet. And they want to do that as soon as possible because they see every minute that someone doesn't, uh, have their technology available to them is limiting their life in some way. And I find that inspiring and compelling. Um, so do I believe that there's space for local solutions? Maybe, but I don't know if I have a strong opinion on that. I think that what's important is that people who want to build things, um, have a shot at that. Um, and I think creating the conditions in which that's celebrated and becomes easier is very important. And we were saying before the podcast, I admire the work you do with somx because you're part of that. You tell the story of innovation in healthcare. And that's very important because it has been hard for people to get, um, returns, uh, whether it's investors getting returns or whether it's people with their careers joining companies, investing five years of their career in that and then sometimes ending up with a product that didn't make it to market in the end, um, or that it was in research and the thing they worked on never impacted um, a real patient. And that's a kind of investment as well. And it's like really deeply unsatisfying um, when that happens and it creates a very um, um, um, well, to frame it positively if you can do that the other way around so people can come and innovating in healthcare. It's commonly understood that this is um, an attractive thing to do, that there are opportunities for outsized returns, that there is money available there to go and pursue those opportunities. And as a talented person you're going to be able to rapidly see the impact of your work. That's the thing flowing in the right direction. And um, you're a part of that. With somex telling the story. I know we're a part of that as well. By trying to clear the obstacles to make it possible for people to realize their ambitions and to innovate in healthcare and to make that a thing that um, you don't need to be such a masochist, uh, uh, to try and attempt. Building companies in any category is hard. Building new products inside companies is hard and we don't need additional obstacles to that.
Speaker B: I think you're right. Very, very much aligned on that. Very much feels like we're in the same game for a lot of that. It's just people don't, you're right with the massacres, people don't need to suffer like they don't need to suffer through this. And anything that you're doing along those lines is, is I just think making a better health tech ecosystem. It is an inspiring mission and spoken like a true leader and I imagine that does galvanize people. And you guys, you guys are seeing a lot of success at the moment. Um, with more and more people coming to you. You're, you've got lots of, lots more work to do, um, which in an economy like this is only a good thing but you need lots of people to do that as well. Um, so how do you guys uh, where are you guys at in terms of, I mean your raising cycle and your growth and what you guys need and how you're growing as a business?
Speaker A: We're growing quickly. Um, like um, um, we have new uh, custom projects kicking off every week. Um, we um, are growing the team quite quickly. An important heuristic for us having lived through the Babylon Blitzscaling experience. Um, a Heuristic that I keep in mind is I think what you want to do um to preserve the things you like about um a culture or working in a team. You want to look left and you want to look right and you want on average to find someone who kind of knows what's going on rather than everyone looking left and right and they're both like I don't know, I've been here for five minutes as well.
Speaker B: Right.
Speaker A: That doesn't help you to compound a productive culture. So in general we have been growing the team at about 2x year on year um but not exceeding that and if you go too much faster than that on average, if you look left and look right and your odds start to diminish on at m least finding someone who's who's been in the team for a year and knows which way is up. Um that's the kind of speed um that we grow the team at. Um we have um, like. We have a bunch of teams um with every team in the company is like um I have the privilege of having and they've been there from the beginning so going through in the last six years. So I've kind of um had a spin at most of the things um and I don't think there's a single thing that we do that isn't surprising and interesting. We have go through some of the teams maybe um, interesting to listeners because where we are hiring um and talk a little bit about the kinds of things that we do and why it's interesting and surprising. Um if we start with um, um the customer we have an amazing customer experience team and um so in customer experience what we're trying to do is obviously we have um account uh managers who's like a point person for our customers. We also have um what we call evangelists. Some of you might have seen Mr. Stephen Byrne on some of our content. Um, people who can um, um you should have them on here actually. People who are very um um uh deep in the details of the domain and can go and uh evangelize the work that um our customers do with us. Um but as an account manager in the team it's like the day to day is one of the best things about what we do is we have amazing customers. You can't say that about every company. If you're selling ah risk software uh and your ICP is like SMBs in dash it's like, like you're going to get a real mixture there. And I'm sure there are some great companies but they're not like thematically aligned enough for you to build this compounding sense of um, what people are doing and to build knowledge in that domain. And all of our customers are building bleeding edge medical technology and you get to meet these people and talk to them m understand what they're building because to serve our customers well you have to understand what they're building. And the domain is very interesting. You have the, the medical domain obviously. What diseases is this thing going to solve and how does it work and who's in your team that works on that and what are the plans for the next release? These are all very interesting questions. And you also have the regulatory domain next though as well. How risky is this thing? What risk class is it going to be in? What's your strategy? Are you going to go with a product here and then ascend the risk class? This is a fantastically interesting conversation to have and to be able to have that with all these um, different customers who are building different things and to see that to be on the front line I think is amazing. And I still get to um, spend our time with our customers and it's always a huge pleasure to do that. So that's like a customer experience team as an example. Um, and then we have um, some teams in the company that are our domain experts who are really um, uh responsible um, for the decisions we make that hold regulatory weight. So we have a devices team should they buy. Sandy. Do you know Sandy? You met Sandy?
Speaker B: Don't think so.
Speaker A: Sandy. Okay. He's been around for. You should have him on as well. But um, um he's the player coach in our team of um, um clinicians and um, um we call them software safety engineers. People in the team who have um, experience in safety critical software systems. Um, and these folks are very interested in the puzzle of what is the most efficient way to make high quality judgments about the data that customers submit to us. And we designed that process. We're constantly iterating on it. Um, and um, again uh, what an amazing role that is. You actually get to see the action. Most customers who send a technop file, this is something that's quite privileged. It's got architecture diagrams of how their thing actually works. It's got the clinical data they've generated from the studies they've done or how they think about measuring safety for these things. This is fascinating. Um, and very privileged I think uh, the roles we have in those teams as well. Uh, it's very rare to be able to go to, to go and do that. Um Um a bunch of folks in those realms have clinical uh backgrounds um so that's also I think a very interesting place to go for folks with a portfolio ish clinical background. Um did some clinical medicine but then kind of got the data science bug. Um did a bit of that um maybe worked at um ah a health technology company. I think that those people really enjoy um the opportunity to come in here and get into the details of what's happening on the bleeding edge of medical technology. Scrutinizing the detail. Um I won't go through all the teams because we have a few of them but I'll give a couple of other examples. Um, we have um a uh product organization so um, uh design engineering, applied machine learning product um and we work together and this team um provides the technology um in our processes. I describe Scala as a bit of an ICEBERG in that 20% of it's above the water. That's what our customers see which is the um materials we provide. We call it the knowledge base which help resolve ambiguity and what we're expecting. We have some tools there where people can um, uh upload um submissions and get um automated feedback um and so on. But that's really just like above the water really like Scala as like a technology company. What we're doing here is the 80% below that which is um we have uh, uh we want to, we have a devices team that want to make high quality judgments on ah documents and data. That's Smith by our customers. What is the optimal experience for doing that? Ah, like what technology can we bring to bear to make that experience like really fun, um and really fast and very accurate and that's an amazing puzzle for us to solve And I think one of the fun things about working in our product optimization is that um because 80% of what we're building for is kind of internal, you can just sit next to the people using your software and that's an amazing feedback loop. You're just in the mixer uh um and um, you can build things that are good quite quickly in the feedback loop like that sitting next to people who are smart, have domain expertise in the problem you care about and you're building things that they can use immediately. So this is also a very fun uh, uh very iterative dynamic that we have. Um I think there are other product roles where um, maybe you don't have that and it's harder to really connect with your user and you have to I don't know, use tons of analytics rather than just sitting next to them all Day, um, which is kind of a bit more like fumbling around in the dark than really knowing what it is you're trying to solve. It's kind of obvious to everyone in the team that what we're doing is important. It's easy to leap out of bed, um, for our customers because who doesn't want the technology from the future to be available sooner so they can help people who, with diseases that currently don't have good solutions, it's very easy to leap out of bed for that. Um, so that's the foundation of why it's attractive to work at Scala. And we also have all these kind of interesting nuances about the kinds of work we do because we have lots of interesting data from our customers. We build technology for ourselves which we get to use on the same day.
Speaker B: Um, well, I think that last line that you said, the work's important, I love that because I say this. Well I, I, I understand this from even just like speaking to my friends in different sectors that one thing that we, we don't have to worry about, we didn't have to worry about it at all as, as clinical medics, but we certainly hardly have to worry about it now is that purpose side of it. And it's funny that, you know, the most of my close friends at some point or another will turn around and be like, hold on a minute, like I'm just making rich people richer. This isn't really fulfilling, fulfilling. And we've never had to worry about that. And actually it, that in itself is a really privileged position to be in. And so I can only, I can only think back to when as well. Uh, like I don't know when you trained, but like when, when back when we were doctors or certainly when I was like, I, I can, you know, hearing about this type of job be even being available to me, you know, dragging the technology of the future into the today, like I, I, it just would have, it just would have like lit me up. And I can't believe that, you know, our generation has managed to now create a world where this is actually possible for, for people over. And they say that, you know, entrepreneurs will solve the problems that they had so that the next generation doesn't have to go through them. And I do kind of feel the same way of what we've built. So actually it's kind of the place for, if you, if you love health, tech and health care, but you're also a creative. And that's kind of the position that I was in, you know, and I wanted to solve things creatively and help people out with, you know, the commerce, marketing side. So it's funny how, you know, we have managed to create that world. But the final thing that I just want to say as well is that it's also, it's also really nice and actually makes things very easy to work for people that are passionate. And, you know, your passion for this comes through, and I'm a firm believer in that. Passion isn't something that you say, it's something that you show. And I'm glad that you haven't used the word because it's kind of backed up that point of view. Um, I don't, I don't want to hear that you're passionate. I want to see that you're passionate. And that's very difficult for people not to hear or see that, depending on how they're absorbing this podcast. So, um, that's also really nice that those problems still and will continue to light you up. Because you're right that you've got one eye. Well, you've got both eyes on the future. When that technical file comes through, when that architecture comes through, you've got an eye on the future and you're the one, I guess, choosing to some regard or certainly helping into reality what that, ah, future actually is. Um, and you're right, it's an incredibly privileged position. It's also a really cool position to be in. For the people that think that is cool and for those people that are on the front line, frustrated with tech and they want to bring it into the now, I think that's an incredible position to be. Be in. So all that is to say, I understand and I get it, and I think it's a great position to be in that you're able to give those people as well, that feel like ducks out of water to give them a home, to give them somewhere where they can feel lit up to go to work. So, yeah, it's an awesome position to be in.
Speaker A: I think times are good enough. I remember when I was doing medicine, medicine is obviously this very interesting subject. It's like, it's like a very broad field. It's a very deep field. It's full of like, surprises and interesting historical stories. Uh, and, um, it has a technological aspect to it. But remember going through medical school and then you hit like the, uh, like the years when you're in the hospital and you get struck by like, the vocation of being a doctor.
Speaker B: Yeah.
Speaker A: And it's like, it's quite. Yeah, it's like trying to Reconcile like an enjoyment, like an intellectual appreciation uh, of the domain and of medicine as a subject with some of the difficulties of the vocation of being a doctor in an nhs, um, uh, hospital, um, which is what you get experience to. You go to medical school in the uk. Um, it's quite challenging because you have to make a decision which is, I love the subject that there are many things about the vocation which, which then, which are unattractive and um, in other careers or of interest in other subjects there might be more alternatives but you're quite railroaded because medicine in this country at least, I don't know if it's different in other countries but it is vocational training, there's a job at the end. Um, and I think we're going to enter into a golden age um, for the biomedically curious people because there are really a lot more options now. You don't have to go and go through the foundation program and then do specialist training and then, and then do whatever. There are other ways to have um, like a high impact um, uh, career and um, to explore your genuine intellectual curiosity a bit more railroad into service delivery.
Speaker B: I've got an 18 month old and like I get asked the question, you know, by fellow doctors or ex doctors and I've got a lot of friends that still practice, you know, would you want your, would you want your kid to do medicine? And for a long time it was like oh God, absolutely not. Like there's no way I want them to, you know, experience load different stuff. Actually you're right. And um, and this is what I'm starting to feel now is that the, the medical shoe. Some medical students that I speak to and it's, it's a, you know, it's a self selecting group because they've in the same arena as me at that particular point in health tech, but they see the medical degree not as the path to automatically being a doctor, they just see it for what it is. They just see it as a really good degree and actually in the medical sphere and they can do other things and actually they're starting to plot other things. The unfortunate thing I think for a lot of them is that they sort of feel like they have to do that and I think that's where it's tricky with training numbers and competition and all the rest of it that they're kind of being forced into looking at other careers which is a position that we didn't also certainly I didn't have to be in. It was one that I fortunately chose to be in but yeah, it's a, it's, it's an interesting time. But I think you're right. As a result, I think all of it ends in the same place, which is that actually I think people can, can be more, uh, they can, they can find jobs and careers that are more aligned to them and their personality. Because it is just a, it's a self awareness game, isn't it? Like knowing what you are, knowing what you like, knowing what you want to do, knowing how you want to spend your time and then just trying to find like, okay, what skills have I got, what qualifications have I got and how closely can I align those things? And that is like wading through treacle for our generation as to like taking this risk of leaving and then trying to force yourself into a career and then you end up becoming an entrepreneur because it doesn't exist. You want to create it into the world and that is just wading through more treacle. So it's been historically very difficult, but at, uh, the same time we've benefited from not many people doing it. So the competition in what we were doing was actually a lot less. It's a lot more now. So there's positive negatives. But that is all to say that if anyone is lit up by what you just said, they've got a route straight into it at Scarlet. So that's kind of ideal.
Speaker A: Yes, yes, definitely. Um, drop me an email. Um, I think also maybe a footnote on that one is we wouldn't want, uh, anyone who's listening to get the impression that, oh, it's great that you don't have to be a doctor when you finish medical school. I think that doctors are like, uh, we obviously need large numbers of doctors. And I think being a doctor is also about to get a lot better. Um, yes, you have the scribes and so on. We had a bunch of folks at our summit event and exclusively, you know, I might go back because Heidi's getting pretty good.
Speaker B: It's interesting, isn't it, that it's having that much of an effect. That is fascinating.
Speaker A: And there's that. But then there's also, um, uh, like just. I really, really believe that in the coming years we're going to see new technologies that offer options for doctors for their patients that previously just weren't possible. There's an amazing, There's a company I really admire. They're called the Science Corporation. You go to their website, it's a great company name. I think it's Science xyz. But they have, um, a device Coming. It's a retinal implant, um, and there's an amazing video on their site and you can uh, look at the product called Prima. And um, they have an interview uh, with an ophthalmologist and he's talking about one of his patients who participated um, in the study. And um, it's a retinal implant, it sits at the back of the eye. It's for diseases where you lose the rods and cones. So like amd, like macular generational retinitis pigmentosa. These diseases put the retinal implant in the back of the eye and it kind of sits there and then you put a pair of glasses on. Glasses have a camera, there's a laser beam that shines onto the retinal implant and the retinal implant um, will activate the neural cells that are downstream of cones. And in their trial they had ah, patients who had complete loss of central vision from age related macular degeneration, couldn't see their grandkids faces. They put them on, they can read again, they can see their grandkids faces. And in the video you should watch it. Um, there's an amazing interview at the end with the ophthalmologist and, and um, he talks about this patient, um, this patient, um, older lady with a huge family and he just has to wipe away the tears because he goes uh, and we could do that for her. And being a doctor today and throughout history where a lot of the stories you have are, you have no options for your patients, that's really hard. And as we have more and more technology and more and more great options for patients, it's going to be such a fulfilling role to be able to have just better tools to practice this craft of medicine that can solve problems like blindness for patients. Giving someone back their sight is such an incredible thing to be able to do for someone. And who wouldn't want to be a doctor who could go and do something like that for one of the patients? Um, so I think being a doctor is still going to be a great job too.
Speaker B: Love it. Um, Jamie, it's been a pleasure. Thanks for coming on mate. Um, for people that want to learn more, particularly if they're interested in joining you guys, what's the best way for them to get in touch with you?
Speaker A: Send me an email. Uh, JamieCarlot CC pretty straightforward.
Speaker B: Um, any final thoughts Jamie, or should I let you go?
Speaker A: Uh, this has been fun. Thank you, um, for having me on and yeah, again thank you for what you're doing with somx. I really Think it's important that we, uh, have, uh, as many stories as possible so people can see, um, that building new things in healthcare is not only possible, but actually a great thing to go and do. And, uh, you are a great champion of that. So thanks for what you're doing with somax.
Speaker B: I've managed to articulate this, I think relatively, uh, recently, which is that I think the thesis running through everything that I do, which is Sommex and this podcast and health tech pigeon, it's that I'm trying to solve the information problem for people. And I think there's a huge lack of innovation because information doesn't get from A to B quick enough or at the right time or early enough or whatever it is. And I think through all these different mechanisms, what I'm trying to do is just get the right information to the right place as soon as physically possible. And it's great. Like last night, like going to that event and hearing that people, I've been listening to the podcast for the last like 100 episodes and because of, uh, that I've done blah and it's like, that's, that's excellent. That, that's exactly what this is for. That's exactly what this is for. That you've got some information that was locked into an entrepreneur's head, that they said it out loud on here, they listened to it, and then they went and did a thing that was different to the thing they'd have done had they not have heard that. And I think that is, that's this working. So I appreciate you saying that. Thank you.
Speaker A: And I, I think you're going to be really busy. If what our customers are doing has anything to say about innovation that's coming, you're going to have to do a lot of events. There are going to be a lot of, uh, people from very successful, um, out there. You're going to want to get the message out.
Speaker B: Well, I look forward to it, mate. I look forward to it. It's been a pleasure.
Speaker A: You're in the pocket.
Speaker B: Thank you.
Speaker A: Um, thanks so much. See y.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.