Anmol Satija – Hi everyone, welcome back to the unthinkable tech podcast, the go-to source for the pulse on technology shaping our future. I’m your host Anmol Satija and today we are heading into the world of healthcare technology. One of the most promising yet more complex spaces for software innovation. We all know, health tech is booming, but building a successful software product in this space, it’s not for the faint of heart.

Between strict compliances, high expectations from users and the real impact on patient lives. There’s a lot that can go wrong before anything goes right. So to help us make sense of it all, I am joined by someone who’s been through the trenches. I am joined by Michael Wingrigen, head of engineering at PhysiTrack group.

Michael brings over 15 years of experience leading cross-functional teams, balancing quality, security, and delivery, and has been behind some of the most mission critical projects in digital health. So whether you are building, investing in, or leading a health tech solution, stick around. This conversation might save you a few missteps along the way. So hi, Michael. Welcome to the show.

Michał Węgrzyn – Hello and thanks for having me and extra kudos for pronouncing my last name at least trying because that’s that’s X five points for that Nice beautiful

Anmol Satija – Yeah, I did my homework well.

Yeah. All right, Michael. So before we dive into the tough stuff, that is the regulation, scaling challenges and all the moving parts, I want to zoom out for a moment. know, health tech is one of those domains where the stakes are so high, but so is the potential for real impact. It is not a very easy space to work in.

So I am very excited and I’m curious to know about your story. So what actually drew you to this space, like the healthcare industry? Was it something you actively sought out or did the industry kind of find you along the way?

What makes building healthcare software so different?

Michał Węgrzyn – So the answer is pretty straightforward if you know me as a person. I’ve been involved in sports all my life and if you do sports, I’ve played basketball, I got injured, I taught my ACL, then I’ve done powerlifting and bodybuilding, I’m doing boxing right now. And if you do sports, you get injured. And when you get injured, you’re facing healthcare, you’re facing physiotherapy.

So once I started on a journey like, I want to change jobs and what I want to do, there are a couple of factors to take under consideration. when, after years of working in different industries, from enterprise software to building CRMs to building different fun things. I’ve learned the craft. I’ve worked with great teams, but I had to answer question like, what do I want to do? I also reached the time on my age scale when you’re not only asking question like, does the compensation make sense or do you have a great team? But like, what are you building? Are you contributing to something that makes sense?

So when the opportunity to work for PhysiTruck emerged, the tool that like, helps people we’re working for with physiotherapists. have like million people a month that we help. Like that was a natural thing. Like I know so much about physiotherapy that building that from the other side, building software that supports it, just a perfect setup.

Anmol Satija – Yeah, kind of connected through your life and what you have been through. So you already know the pain points, right? Okay. Yeah. So, Michael, there must be like, as we talked earlier, you said that you have been working with different industries before coming to healthcare space. And At some point of time, right now that you just mentioned, what you are building starts to matter as much as how you build it, especially in this space, right? So as you have had the chance to work in different industries, so I’m curious from your experience at PhysiTrek and elsewhere, how does developing software for healthcare differ from other industries?

Michał Węgrzyn – That was actually one of the questions that I had in my head because like if you’re changing kinderest, you work with telecom, I work with enterprise software and there was not a big changes than the differences when it comes to like day to day building software because at the end of the day you write code, you work with a product managers, you have some designs, you test the shit out of it and I swear, I can’t swear. You’re gonna have to be lippid.

You test it and you want to ship the best possible product. But in case of healthcare, there’s so many other factors that come into play. What is also interesting that when I joined the company as a head of engineering, it was a new responsibility for me to also work with InfoJS security team. So I’ve learned so much from my team.

Because once you reach a certain level, you’re working with people who are much better than you at the role. So I’ve learned so much. have a great team of information security experts.

Why compliance in health tech can’t be an afterthought?

So when you connect the dots, back to your question, so many differences. But I think the biggest one that everyone needs to face is you have to manage your expectations in terms of…

How complicated would it be in terms of security and compliance? That’s a big point. It’s not a commercial application where everything is fine. The patient data is one of the most heavily protected and regulated. Even, like we’re working with physiotherapy, which still falls under the same regulation and rules. It’s patient health information.

It needs to be protected. Each country has their own regulation. This is also complicated because you’re going to have a different framework in US that the one is here, what you’re asking called HIPAA. You’re going to have different frameworks in Europe, in different parts of the world. And if you build a product, you have to be compliant with customers that could be anywhere and that might have different expectations. So that’s a big one. ⁓

Also, when it comes to the actual product building, I was always wondering why are all the health related products look so bad? Because we’re users, we’re customers, right? We’re looking at Instagrams, Facebook, TikToks, and all the amazing B2C products that we’re looking at, but this is a different market. You can’t move so fast. You have to be careful with what you’re doing. There are just different stakes.

Designing health tech products for every type of user

Actually, when you think about it, when you build a product for healthcare, especially like what we’re doing, have, our model is pretty interesting because our customers, people who pay us, our hospitals, our clinics, our physiotherapists, but they’re only one actor in the product setup because they are creating training plans, they’re creating rehabilitation plans for their patients.

But we have like a million-ish patients a month and they’re also using our software. They’re using mobile app, they’re using web app and the software is mainly for them. They don’t care about fireworks. They don’t care about like fancy animation. It should work. It should be reliable and should give them what they’re looking for. If it’s beautiful, that’s an added bonus, but it has to do what it’s supposed to do first. Also, if you think about it, like in healthcare, like if you’re building a product, you have some targeted demographics, who your customers are.

We have all the demographics, all the people in the world. Like it could be 70-ish year old woman who just had her knee replaced. And it could be like 20 year old athlete who just for his ACL. Like we can’t target for one group. Like we have to make it unique, universal for all the groups.

Michał Węgrzyn – So it’s so much fun, so much fun to build it. what makes it even more complicated that if you cross-reference the customer group, so users, and you cross-reference this with the people who pay, like when you have a big hospital or big insurance company, they will have very specific requirements. Like they will have enterprise level requirements, regards to security, to interoperability with other system, with their systems. And it’s such an interesting space when you think about it, because at the end of the day, you’re doing something super productive and super useful, but the hoops that you need to jump are like so many of them.

Anmol – That’s quite an intense list that you have on your plate. And I think each of those on its own can be a full time challenge, you know, to manage it all around effectively and to keep everything in sync, especially the compliance part, which is the, I think, most critical aspect of the healthcare space, wherein you want to be global and at the same time, you want to, you know, fulfill each aspect of the country specific compliances.

So, and it also involves dealing with sensitive patient data. And that doesn’t exactly move at a startup speed, as you mentioned that you kind of need to work a little in a slower pace. So now this brings me to something that I’ve always wanted. So,

How do you really balance the need of rapid iteration and innovation in software development with this slow moving compliance heavy nature of healthcare?

The tug of war between compliance and innovation

Michał Węgrzyn – It’s a great question and I can’t obviously answer for the whole industry. I can answer for us. How do we balance this?

I’d start with the first principles. What are we doing here? Regardless of the industry, regardless of the compliance, we’re building products that should be good, that people would like to use, that make money. So that’s the first thing. If you work around that, those guiding principles, so you should be building nice things, build them fast.

It’s not about like, oh, we have a lot of compliance issues and how will we deal with it? It’s a, it makes it a little bit more difficult, but the guiding principle stays the same. want to build right things in the right way. And we know how to build good software. Like after what it’s like 50 years of building software already, since you started us as a human kind, we know what works. We know what the best practices are. So we’re using that. I’m super lucky that we have a great product people in the team.

It’s so important for my role as a head of engineering to have a great counterpart, head of product. We have that person, person who changed how we think about product, who embraces product operating model. So this is yin and yang. Like we’re making sure that we’re the right things, that we have the right attitude to build good stuff. And yes, we have to take some things under consideration while building like compliance thing, the data security, but we want to build the right things. So when it comes to actual implementation.

So first of all, we’re trying to make sure that we’re not overthinking things because there’s a lot of regulation in different countries that make they are either mutually exclusive. Like you can’t be compliant with everything.

Some of those regulations are very general. And if you go into the rabbit hole of like, we shouldn’t be doing this because someone somewhere might say this is bad. You’re not going to be able to build anything and you will be out of business because someone else will just build it and make it make a better product. So we’re doing whatever we can to be compliant, to make good stuff but don’t overthink it. Don’t always have this principle that product should be good, product should be people want to use it. And obviously the compliance and information security are non-negotiable. Also, we have a fun setup.

When we talk about technical setup and infrastructure, because of the industry we’re in, our product is the same everywhere, but each time, like if you’re in the US, if you’re in Europe, if you’re in Australia, you will be working with our local instance on AWS that is closest to you. Because like people want to have their patient data close as possible, not only because of technical things, you don’t want to be talking to APIs, the servers across the world, but also do the compliance. And that gives us lot of flexibility into exploring features in different markets.

Because we can enable something in one country that has fewer users, see how it goes, and then roll it out to everyone else. that’s helpful. Because when you think about it, Europe, from all our customer base, has the most strict, especially the Nordic countries, they have the most strict rules. So we’re obviously not exploring new features on their markets first. We can check smaller markets. We can check.

Anmol Satija – Yeah, that’s an interesting approach, right.

Michał Węgrzyn – Also what’s also important because like I mentioned PhysiTrack. PhysiTrack is not only tool for physiotherapists. PhysiTrack is a company that would have two product lines. We have one for physiotherapists which is like a strict medical device but we also have Champion Health that’s more of a well-being cup that gives you a meditation, it gives you courses on diets and sleep and stuff like that and it’s a completely different level of complexity and regulations and the way we think about it.

Because when you have a system that’s business critical, like you go to your physio and your physio is sitting in front of you, the system must work and it should be bulletproof. When you have a well-being app and meditation loads a little bit slower, that’s okay. That’s going to make a big difference. Also, when your question was like, how do we deal with that?

Do whatever we can to follow the best practices. have a lot of, we’ve made a lot of investments into observability. So we know what’s going on with the system into our team. have a senior team of engineers who know how to deal with that and they don’t panic. Actually like we’re at the stage in our company that brilliant engineering leader that we have in our team mentioned recently that we had so many, so few.

Production incidents recently that team is losing the focus and we need to do some drills on things going bad. So it’s a fun problem to have that the system is so stable that we need to force the team back or simulate some issues. it’s an outcome of a lot of hours of work and a lot of great work from engineering and DevOps.

Anmol Satija – Yeah, definitely.

Yeah, yeah, sure, sure. That was a really thoughtful breakdown, Michael. And I like the examples that you gave along the way. And specifically the approach that you guys follow of moving country-wise testing with small groups of features and how you are not treating all health care products like the you said that there are two segments within your product.

For instance, like you mentioned, what works for a weatherless app doesn’t fly in a clinical setting and your approach reflects that kind of nuance. So now on top of the tech and regulatory challenges that we just discussed, there’s also the human side. So healthcare is full of voices, patients, doctors, admin staff, insurers, sometimes all pulling in different directions. So how do you kind of make sense of that complexity and decide whose needs to be prioritized in your product development?

Michał Węgrzyn – So the answer again comes back to the principles. Here it’s a great question because we have to balance the principles. First of all, you want to make people who pay happy, which is our physios, our hospitals, insurance companies, but they are just a subset. The ratio of in-physi-trak for physio to their patients, it’s like one physio might have 20, 30 patients. So you have to balance that. Like the person who pays is just a tiny subset of all the user base.

So we have to balance people who pay and people who use it. But at end of the day, the person who pays will never pay us if his patients don’t use the app, are not happy, and they’re going to say like, this is crap, just write it on paper. That’s not going to happen. So we’ve invested a lot of time.

Over the last couple of years into making patient experience much better. We’ve completely redesigned the mobile app to make it much better. We’re investing into additional features that allow us for additional messages that we can convey to the patients. Simple things like exercise more, drink more water. It’s things that are useful if you already opened the app make it reusable.

We have a lot of ideas how to make it even better and we will over the next time. So that’s a patient experience on the practitioner side. So the physios, all the paying customers, we’re following a product operating model. So we are listening to their voices, we are listening to their feedback. And it’s also fun because like we have small physio clinic that has five physios, but we have massive chain of hospitals in US that has hundreds or thousands of users, same in the Nordic countries, and they have different requirements.

If you think about it, small physio will use the full flat version of fizzy truck in the browser, but the enterprise customer would only use like an embedded part of our fizzy truck inside their EMR system. And both should look good, both should be reliable, both should be secure. it’s a lot of heavy lifting on the product side to balance those and they’re doing an amazing job.

If you think about our reviews, like one of the, one of the brightest points of my day and also the whole team mentions that is that we have a channel in Slack that is linked directly to the reviews that we get into an app store and play store. And it’s so heartwarming. Like you’re getting five star reviews. This is great. It helped me. My knee stopped hurting. The doctor is great. I feel so much better.

This is why we do it. And this is one of the prime examples, like if where you work and what you do makes a difference at the end of the day.

Anmol Satija – Yeah, definitely. I think that’s the whole agenda, whole point of building a healthcare product to make a difference in a patient’s life. So, and I like that you have a balanced out approach to it and listening actively, but still steering the product with a bigger picture in mind. Of course, the enterprise customer would have different choices, different demands. And the smaller group of, you know, the customers will have different set of requirements. But to keep it all balanced out is what is required.

The hidden challenges of medical device certification

So now let’s just zoom in on something that you hinted at earlier while we had our earlier conversations, that is the medical device certification, right? So I think it is one of those things that can really slow down your teams, but it is also absolutely essential in this space. So.

Why is this such a critical and often painful process in health tech?

Michał Węgrzyn – So I’m learning. We’re all learning as a company. We’re not a medical device yet. We’re in the process. We’re being guided by a third party company that done that before they’ve helped other companies. So they’re helping us to understand what’s, what do we need to do? What are the, what are the guardrails around our system that we need to implement? What are the regulations that we need to follow? It all starts like the first question is why?

Why does it make sense? should we, like when you think about what we do, a physiotherapy tool that like, I sprained my ankle, my physio gives me a couple of exercises. Why should it be a medical device? Every country has their own response because regulations in Europe, US, Australia, you name it, will be different. But some countries have more strict regulations and they just require companies that, uh, provides, uh, software for, uh, medical professionals.

Especially if you start into the path that you help with the productivity of that person. So you want to automate some stuff. You want to advise something. This becomes a slippery slope because this is not just a tool. It’s a tool that enhances them. And this is why medical regulations, medical device must be there in place because you’re interfering with the process. So why is it so complicated and what’s hard about it? When we started on this journey,

First thing I’ve started doing is reading more about it. There’s a podcast that you can find that has like 500-ish episodes just on medical device. That’s what they do. The only thing. And when you start listening to it and you think about it, you figure out that this is such a complicated field even for experts because the regulations are very blurry. It’s a lot of like, maybe this, maybe that, it depends.

The amount of cost, hidden cost, it’s cause it’s like, there’s obviously an open cost. Like we need to pay the third party company that supports us. We need to have people in the team that work on that. We have a great person that helps us with that process. That’s, that’s her full-time job. And she just makes sure that we progress. She reminds us about doing so, so doing good work, but the process is costly.

Like I’ve read somewhere that it costs between 500 K and 1 million to get through that process and get certified is crazy. That’s a lot of money. If you’re a company, we’re 20-ish million ARR company. So for us, costs up like 500 to 1 million. That’s a lot if you think about it. We could invest in so many other things, but we decided to invest in this because those are the regulations. So the biggest pain points from my perspective that needs to be addressed, and there’s no other way.

It’s the insane amount of documentation that needs to be there in place about the system, about the architecture, about the features. Like you need to have every single feature documented. Everything needs to be in place. So after each release, a team can highlight what was changed, what were the risks, the teams that work on the risk need to assess that before each release.

So it’s complicated. It’s really complicated and it slows down. When you think about it, like we already know that shipping little changes often is the way to go because that gives the system a lot of resilience. know what you’ve changed. Unfortunately, medical device process has a different view on this because of the amount of documentation you can’t document every single release. So it has to be bashed like every week or so.

You need to gather all the changes. You need to document it. You need to have a board of people who look into this. Is it safe? Does it impact our patients? So if you think all about it, it will slow us down because there’s no other way. But we’re clever. We have great people, great advisors, so we will minimize the damage. But on the flip side, when you think about it, it’s going to be great asset because the medical device is a mode.

Like a lot of companies, a lot of our competitors won’t be able to provide that. We’ll be able to go through that certification. So when you’re a big enterprise customer and you have choices and this company is a medical device, like we’ll take that and we can pay premium. So at the end of the day, it makes sense. It’s just art to comprehend the amount of additional paperwork that needs to happen to make that work. But on the flip side, I also understand why is it this way.

Because there has to be guardrail and you, not everyone can like, this is a medical device and it’s not regulated. It’s not checked. What if something happens? Like not every tool is a physiotherapy tool that could be real software.

Anmol Satija – Yeah, kind of build on the credibility of your product. Yeah, of course. I get that. and I would say that, of course, I can imagine how intense it must be and the engineering engineering team that you have, they they are used to, you know, fast iterative cycles and now all they have to do is heavy documentation. So it’s kind of a complex scenario to be in. with all this, yeah.

Michał Węgrzyn – Yeah, like you were in the room, like the moment when you had a conversation about engineering them that this will happen and they need to think about the changes in the infrastructure, like the set faces. It is what it is.

How certification processes impact software development cycles?

Anmol Satija– Yeah,

yeah, I can imagine that. So with all this complexity around, how do you think that how early in the development cycle do you need to start thinking about the certification? And how much does it shape your design choices from the start?

Michał Węgrzyn– So based on what I already know, and I think I know enough, is that once we… It’s a fun process because from the moment when you actually apply to become a medical device, it takes around a year for the governing body to process your request, to review all the documents. So it takes some time. So the moment when we will file for becoming a medical device, we should change the process a bit.

This is the point where like everything new already needs to be done in that way. So a little bit more documentation or a little bit more testing, especially it’s not more testing. It’s better documented tasting. So I’m going to phrase it right. We do all the right things already. We just need to add more layers of documentation snapshot that it was actually test, have proofs, artifacts, all that stuff.

We are at this point that we’re contemplating couple of features that will really be a medical device. So that’s why we’re also doing this because like right now we’re supporting, but there’s so many cool things that we can build that will make a big difference. So once we’re on this path, it’s going to be right away. And we know like from the design perspective, from the documentation, nothing changes on like the actual building of software. It’s red tape around that.

Strategies for achieving global healthcare interoperability

Anmol Satija – Okay, got it. So, okay, and I think that designing with rules in mind from kind of day one or, you know, starting it earlier in the process saves a lot of pain down the line. And now, now if I talk about the evolving aspect of the healthcare requirements and has the increasing focus on interoperability that is like one of the most crucial aspect in healthcare changed the way you think about architecture and development.

Michał Węgrzyn – Yes, because like, especially with the larger customers, the bigger enterprise customers, they have their special requirements. They already have a bunch of systems that they operate. Their EMRs, electronic records. And our job is to integrate seamless with those. Luckily, it’s not rocket science. Like most of those systems do have a pretty simple API, so it’s not complicated.

Balancing enterprise buyers and patient needs

What we’re trying to do is make sure that when you have an enterprise customer, each customer thinks that they’re the most important one and they can order whatever they want. This is the nature of working with enterprise. So we’re very selective in what do we want to build? Because if we build something, we want to reuse it with other customers. That’s something that we’ve done a couple of years ago with Epic integration. Like Epic is the largest.

Michał Węgrzyn – EMR provider in the world, especially powerful in the US. So we have a great integration with Epic. We’ve invested some time into building that. We’ve invested more time this year and the last year into adding additional features to be able to import export data from Epic. And this pays dividends like other customers, like when we have new customers, we can just enable this for them and it’s good. We have a similar challenge in front of us with one of the bigger systems in UK. That’s called system one.

And it’s been, I think a year that we’re still in a process of discussion. The fun thing about it is that there’s one company that holds the keys to allowing companies to integrate. And they’re not super responsive. So it takes some time to figure out like, do we want to use them? Is there another way? One of our product managers is handling that. And it’s just a great story to build that. Especially like everything moves slow in enterprise.

That’s history of all my previous roles, but everything moves even slower in healthcare enterprise. Because like when you think about software companies, software is not main role of our customers. Like their hospitals, they’re doing something else. So they have limited budget. They have people who juggle multiple vendors. So it’s fun. It’s It’s complicated. Also, when it comes to interoperability, what’s good? that it’s not complicated.

Modernizing legacy healthcare platforms without losing users

So it’s, have a fun example. One of our companies in our, in our portfolio is a legacy product in Finland called Physio Tools. It’s a, it’s a tool that was built 25, 20ish years ago. Like they’ve been building software at the point when they were sending DVDs to their customers. It’s, fun. And they have a lot of legacy code, a lot of legacy integrations. So right now we’re working on a, just a tool that will allow all integrations built for them to work for fizzy trucks so we can transfer customers.

And it looks really promising. Like we have engineers in Finland who work on that. And I think it’s going to, it’s going to be big for us to just transfer customers and allow everything to work seamlessly because it’s at the end of the, it’s not rocket science, rocket scientists, and it’s going to work.

The one last piece I mentioned that previously about the embedded piece, the more we would like to sell, like ideally we would like to sell the whole experience to our enterprise customers so they can see how nice the system is, use all the features. But they’ve already learned they don’t want to manage so many systems. So they would rather have our tool, PhysiTrack, embedded into something else in just a part of the window, than to have another login, another set of features. So they just log in with SSO, it’s already there and it works. And this is a good indicator for us, what should we be investing in? Because our customers just tell us like, don’t make our lives more complicated, embed your software into something else and we’re going to pay you whatever

Why AI will be the slowest to fully enter healthcare?

Anmol Satija – Okay, got it. So Michael, this has been a great conversation. Like I think we have touched upon a lot of aspects of software development in the healthcare space. So now, now looking ahead a bit. So I want to make like, I really want to end this conversation on a very exciting note. So I want to ask that what’s one prediction that you have for the health tech that
might surprise our listeners.

Michał Węgrzyn – Well, my prediction is like, I’m really engaged and I follow the AI space like everyone right these days. It’s a great tool that enhances our productivity. Like we’re all use chat GPT and all those LLMs right now to help us with writing. It’s great tool that helps engineers build software. ⁓ It’s not from…

It’s not a tool that solves all the problems. It’s not going to replace us in a foreseeable future, hopefully. But my prediction is that AI and healthcare, it will be one of the last spaces where it’s fully adopted. Because look at the self-driving cars. We already know we have a great self-driving capabilities in the Tesla build that other companies are following Google as well. But still, we know that it would probably be safer for all the cars to be self-driving. But yet we, as a society, we have a very low tolerance towards mistakes done by machines. We know that people make mistakes. We’re used to it. That’s why we tell Tesla drivers to keep their hands on the wheel.

But when it comes to healthcare, from the moment when you have AI that is equally good, which is the surveys right now, like the data, it’s not like AI is already as good at the initial triage as sexual humans. Like we’re already there, but still we’re not gonna adopt it so fast because we have very little sense of humor when it comes to health and security. And we would rather have mistakes to be done by humans than by automated systems.

The AI will be used as support, but self-treatment, self-management, I think we’re long way from there and not because technically technical part is not there. We’re not there as a civilization to just trust machines and give them so much trust.

Anmol Satija – Yeah, I think that’s a really strong point. And you know, I’ve had so many conversations with different guests in different industries and everybody is kind of interested in AI, how is it transforming their respective industries? listening to your point, this is kind of a, you know, a different perspective that has come to me. So and I do not completely deny with the fact that we as humans aren’t very, you know, comfortable with the machine treating us.

So of course there’s a long way to go there. Michael, this has been a refreshing conversation. Thank you for pulling back the curtains on what it really takes to build a successful healthcare software. Not just about the tech, but the mindset and the discipline and the patience behind it. So thank you so much for the insights.

Michał Węgrzyn – Thank you so much for having me.

Anmol Satija – Yes. And to our listeners, thank you for tuning in. If you like this episode, share it with your network and do follow our channel for more such conversation. We’ll be back soon with more exciting episodes and until next time, keep listening to the Unthinkable Tech podcast. Take care.