Software Engineer Pascal Brandt on How Commure is Hacking Health Care
As the first employee of a global health NGO working in Africa and Asia, Pascal Brandt learned directly how tech innovation can be a game-changer for doctors and their patients. Now, he and his teammates at Commure are giving other developers a platform to create groundbreaking tools and help transform health care. Below, he explains why he joined Commure, what sets the company apart from other startups in the space, and what he values in new team members.
What does Commure do?
We’re building a platform to help developers more easily create health care apps. We do this by offering a nice API layer to work within and handling all the legacy integrations. Right now, doctors spend a lot of time fighting technology instead of helping patients, in part because most hospital records systems are built to accommodate billing departments rather than health care providers. Developers who want to help fix that are often blocked because the data they need is siloed in individual hospitals. Our team speaks both languages — health care and tech — so we can help engineers and entrepreneurs build better tools, which will ultimately make health care work better for everyone.
What were you doing before Commure?
I spent a couple of years as an engineer building backend systems for a big financial company in South Africa, where I’m from. After that experience, I knew I was not going to be happy unless I worked on a problem I felt was important. So I took a job as the first employee of an NGO that did donor-funded global health projects. We built and installed open-source tools for hospitals and clinics all over sub-Saharan Africa and part of Asia. It was really rewarding work, and it taught me a lot about how doctors think and what they need.
“Our team speaks both languages — health care and tech — so we can help engineers and entrepreneurs build better tools.”
Eventually, I decided to come to the U.S. to study Biomedical and Health Informatics, which is like a crossover between computer science and medicine. While I was waiting to start my Ph.D. program, I participated in Stripe’s open-source retreat, which basically pays engineers to work on projects that Stripe thinks are important. I developed an open-source system for electronic health records. Then John Collison, one of Stripe’s founders, put me in touch with Diede, who was about to leave their team to start Commure.
Why did you want to join the team?
I’d been in health care for 10 years at that point, and I’d seen doctors getting burned out and depressed. They got into medicine because they loved to care for patients, but they were spending hours in front of computers dealing with various compliance requirements. It was kind of a nightmare. I knew Commure could have a positive impact. I wanted to work on something meaningful while I got my Ph.D., something closer to my experience at the NGO, versus working on some new social media app that encourages people to spend more time on their phones.
I could also tell Diede not only understood the problem well, but had surrounded himself with co-founders and advisors and a team who understood it, too. These were people who had been in the health care industry and cared deeply about the problem Commure was solving. We have two doctors on the team, for example. They help us understand providers’ workflows so we can build the tools to match. We also have hospital and health care partners advising us who will be the first to use Commure. That they believe what we’re doing is worthwhile was a big part of the reason I decided to join. They understood the space and said, “Oh, what you’re building is exactly what we need.”
What sets Commure apart from other companies in this space?
A lot of startups pivot and completely change their plan, but we’ve stayed pretty focused on the same product scope and deliverables over time. Our initial vision has been validated, and I think that’s a really good sign. We also have a longer-term strategy than most companies. Selling an app to a hospital can take years, and we knew that up front. We’re well-funded, and we’re looking at least 10 years out. We don’t have to worry about achieving crazy growth, because it’s not part of our strategy.
I think our other big strength is the diversity and commitment of the people on our team. We have doctors and CS grads, but we also have people from boot camps who used to be chefs and accountants. That variety of perspectives is valuable. And everyone here is empathetic and extremely dedicated. We’re all driven to improve the lives of patients and the people who care for them.
Tell us about the challenges you’re facing.
There’s a pace differential that can be frustrating between a startup environment like ours and an established health care system. Hospital CIOs and CMIOs are often conservative about change, whereas we want to move more quickly. But for Diede, that’s a fun challenge. He enjoys convincing people that there’s a better way.
“We’re well-funded, and we’re looking at least 10 years out. We don’t have to worry about achieving crazy growth, because it’s not part of our strategy.”
What’s fun for me is the nitty-gritty technical problems we get to solve. There are lots of interesting deployment and DevOps challenges, because we’re balancing the need to make data access simple for developers with the need to make the platform ultra-secure. For example, you have to be able to record and audit every event, like when someone logs in or updates a patient’s record. But at the same time, you can’t store protected health information on public servers. Plus, health care privacy regulations like HIPAA are notoriously vague and inconsistent. So we implement solutions that go far beyond their minimum requirements, to make sure patients’ information is safe.
Data exchange is another interesting engineering problem, because we’re integrating all these non-standardized legacy APIs. It’s way more complicated than simple data-mapping, because medicine itself is super complicated. You have tens of thousands of codes that hospitals use to charge insurers, and different health systems often interpret the same codes in different ways. That makes mapping between hospitals really difficult, but figuring it out is how we’ll make it possible for engineers to build new apps.
What do you look for in new hires?
Everyone who joins should be willing to at least be exposed to every part of the system. That may change as we scale, but right now I think it’s important for our engineers to have the entire context before they start working on a specific piece. That said, people do gravitate toward individual areas of interest, and we do have clearly defined buckets of work. There’s a lot of UI and UX to be done, for example. Or a systems engineer can focus on our core API server, which we’re writing in Rust. Rust is a relatively new language and comes with quite a learning curve. But it’s increasingly popular and pretty sweet, so we decided it was worth the investment.
We also want people who can collaborate with a variety of stakeholders in health care and in tech. You have to be able to talk with a doctor, an IT person, and someone in billing, and then synthesize that information to help build something that will work for the entire hospital system. You have to empathize with the developers who will build on top of our platform, and understand the frustration they feel in the current environment when they can’t get answers to basic questions. Our job is to understand both worlds and be the bridge between them.