Project Learning Blog: Beyond Translation

The idea for CareClear came from my own personal experience. My grandparents immigrated from China and do not speak or read Dutch. When they receive letters from the hospital or other healthcare providers, they often rely on my parents to translate and explain them. However, I noticed that translating a letter does not automatically make it easy to understand. This experience made the problem feel very real to me and was the main reason I wanted to explore a solution. I was responsible for the Problem and Opportunity, Business Model, and Final Recommendation part of the project. My role meant that I was particularly focused on defining the problem, understanding how the solution could become a viable business, and ultimately deciding whether the idea was worth pursuing. However, CareClear became much more than just developing a business case. It changed how I think about AI in a high-risk environment like healthcare and what makes an AI opportunity strategically valuable.

Our initial concept was an AI assistant that could translate hospital letters, help explain medical instructions, and support appointment setting and follow-up. At first, implementing all these functionalities made sense to me because they all addressed the difficulties I had seen in my own family. However, as we developed the project and received feedback from the TA, I found that trying to solve everything at once made the proposition too broad. We eventually narrowed CareClear to helping patients understand and act on post-consultation instructions, leaving other features for possible future extensions. Looking back, I think I initially assumed that adding more features would make the product more valuable. Instead, I learned that it is more important to decide which problem to solve first and why AI is useful for solving it.

One of my biggest learning moments came when I realised I had misunderstood the disruption and defensibility framework. I had initially interpreted the question of whether a market was difficult to defend from the wrong perspective. After going back to the lecture material, it became clear that the framework was about whether the incumbent could protect its market, not whether our own product would be difficult for competitors to copy. This changed our conclusion because existing EHR providers could add similar AI features to their systems. However, the course materials helped me understand that we could build a sustainable advantage through defensible complementary assets that would make CareClear harder to replace. We therefore focused on hospital authorisation, verification, and integration into existing workflows, instead of relying on the AI technology alone.

My work on the business model also changed my perspective. Initially, I thought that if CareClear saved hospitals time and reduced unnecessary calls or interpreter use, surely hospitals would want to pay for it. However, I found that, for CareClear, the distinction between users, customers, and payers was more complicated. Patients are the main users and beneficiaries, while hospitals are the proposed paying customer. Hospitals also control the clinical information and the workflows into which CareClear would need to fit. This meant that creating a useful patient-facing application was not enough. We needed to consider why hospitals would adopt it, what risks they would take on, and what would make CareClear difficult to replace.

The biggest surprise for me was how unevenly AI safety risk was distributed. I mostly thought about AI accuracy in terms of whether the translation was correct. After checking this assumption, I found actual evidence that clinically impactful translation errors showed up in most Somali translations, roughly half of Chinese translations, but were statistically no different from professional human translators in Spanish. Through this insight, I noticed that AI safety cannot be assessed using one overall accuracy score because performance can differ between patient groups. It also showed me that safety requirements need to shape the product’s design and implementation from the beginning.

I also learned a lot from my teammates and from the way we collaborated. Although we each had our own parts, I realised that none of them could really be developed independently. This reminded me that dividing the work does not remove the need to think collectively. One discussion that particularly stood out to me was whether personalised insurance guidance should be included as a natural extension of CareClear. I initially saw it as an attractive way to increase the value of the product because patients might want to understand the financial implications of their healthcare. However, discussing this as a team made me recognise the additional requirements for patient-specific insurer data, privacy, and governance. We decided to defer the feature until a genuine insurer data partnership existed. This discussion taught me to distinguish between an idea that sounds valuable in theory and one that makes strategic sense at the current stage. I also learned that good collaboration is not about protecting the idea each person started with, but about being willing to challenge it when another perspective exposes a weakness. I became more comfortable changing my position and saw disagreement as a way to improve our reasoning and credibility.

These lessons shaped the final recommendation. Instead of recommending an immediate launch, we proposed a controlled hospital pilot. Scaling would depend on evidence that CareClear improves patients’ understanding, that no critical medication errors go undetected, that safety requirements are met, and that verification costs are compatible with hospitals’ willingness to pay. That’s when I understood that a prototype can demonstrate that an idea is technically possible, but that does not automatically mean patients will benefit or hospitals will pay for it. I learned that these uncertainties need to be tested rather than addressed through assumptions.

Looking back, my personal experience helped me identify a meaningful problem, but the project taught me that personal conviction is not enough to validate an AI business. We need evidence, experimentation, and collaboration to determine what is worth building. If I approached another AI opportunity now, I would ask not only “Can AI solve this problem?” but also, “Under what conditions can AI solve this problem safely, create measurable value, and support a sustainable business?” This shift in perspective is the most important thing I will take away from the AI Strategy Lab project.