Closer to the Problem

My journey into healthcare technology started with a simple love for building things. When I came to the United States to study computer science at Drexel University, I was drawn to the idea that software could turn an idea into something real. A few lines of code could become a tool, a product, or a system that someone else could depend on. That felt powerful to me.

During my co-op, I found myself working as a developer at a large pharmaceutical company. It was my first real look at how technology works outside the classroom. I learned how large teams build, test, deploy, and maintain software in the real world. More importantly, I saw that the code I was writing was not just code. It supported people doing meaningful work in healthcare.

Before that experience, I mostly thought of technology as building apps, websites, and software products. I had not really been exposed to how deeply technology is used inside the healthcare industry. I began to see that software could support people working on difficult healthcare problems, even when the software itself was not visible to patients.

That experience shaped what I wanted to do next. I did not want my next project to be technology for its own sake. I wanted to work on something where software could help people better understand a real medical problem. For my senior design project at Drexel, I led a team working on digital pathology for sinusitis. We studied medical images that contained far more detail than a person could easily process at once, and we wanted to explore whether machine learning could help identify patterns related to disease severity.

That project pushed me to think beyond code. I had to understand the medical problem, the quality of the data, and the perspectives of the pathologists who diagnose these slides. I also began to see that model performance was not just a technical score. In healthcare, performance is connected to trust, responsibility, and the limits of what technology should claim to know. That project helped me grow from someone who liked building software into someone who wanted to build software that could support clinical understanding.

At the same time, I learned something about myself. In a large organization, it can be hard to see the full impact of your work. Even when the work matters, your piece can feel very small. After a while, I wanted to be closer to the problem. I wanted to build systems where I could understand not only what I was making, but why it mattered and who it helped.

That is where Moberg came into the picture. Moberg was different from the large-company environment I had known before. The team was smaller, the problems were closer, and the connection between engineering decisions and the product was much easier to see. I was not just writing code against a ticket. I was helping make decisions about how systems should work, how data should move, how reliable those systems needed to be, and how the product could support clinicians and researchers in real-world environments.

One of the biggest changes for me was the amount of ownership. At Moberg, engineering decisions were not abstract. Choosing how to collect data, how to store it, how to synchronize it, and how to recover from failures could shape what the product was capable of doing. I had the chance to work on core infrastructure where the details mattered not only to the software, but also to the company’s ability to grow, deploy, and support meaningful clinical work.

I also began to understand how Moberg’s work connected to a larger research and translational ecosystem. Some of the software infrastructure I helped build supported NIH-funded research efforts, where reliable multimodal data can help researchers study complex neurological conditions. I also had the opportunity to contribute to MTEC/DoD-supported projects focused on defense-relevant healthcare and military medicine. That gave the work another layer of meaning for me: the systems we were building were not only part of a commercial product, but also part of efforts to move healthcare technology into environments where reliable data can be difficult and important to capture.

The project that made this clearest to me was the MCP Data aggregator. At a neurocritical care bedside, one patient can be connected to many devices at once. Each device may measure something different, such as brain activity, pressure, oxygenation, blood pressure, or other physiological signals. Each device may also speak a different technical language. The aggregator helps bring those streams together so they can become part of a more complete and synchronized patient story.

To me, the aggregator became more than a data pipeline. It was a foundation for making complex bedside data more usable. It also helps the company move from individual technical demonstrations toward infrastructure that can support real deployments, research workflows, and future product growth.

That ownership changed how I saw myself as an engineer. I was making decisions about architecture, reliability, synchronization, and data flow, but those decisions were connected to something much larger than the code. They affected whether data could be trusted, whether a system could scale, and whether clinicians and researchers could use the information later. The work was often behind the scenes, but it was not small.

Looking back, Moberg gave me the kind of engineering work I had been searching for: work close to the problem, with ownership over decisions that mattered. My path into healthcare technology started with a love for building, but each experience changed what building meant to me. At my co-op, I saw that software could support people doing meaningful work in healthcare. Through my senior design project, I learned that technology in medicine must be approached with responsibility, trust, and humility. At Moberg, those lessons came together. I had the opportunity to help shape core systems, make real product decisions, support research and translational projects, and build infrastructure that could grow with the company. That is why this work has been meaningful to me. It is not just about writing software. It is about taking ownership of systems that can support people working on some of the hardest and most important problems in healthcare.