Building while learning
“It takes months just to figure out how to search the [medical record] data to find the right patients for our research”, a clinical researcher from Weill Cornell Medical Center told our team over a conversation about their research process. We’d hear the same issue echoed by nearly all dozen of the clinical research experts we’d meet with over fall semester, pushing us to focus on how we could speed up this process and improve outcomes.
That was the start of the product development journey my Cornell Tech Product Studio team and I went through this past semester. Each fall at Cornell Tech, Cornell’s technology focused graduate studies campus in NYC, students across masters degree programs (CS, MBA, LAW, Design, etc) are matched on to cross-functional teams and given a challenge proposed by a prominent local company to solve. Through the semester, teams zig and zag along the product development process and end up with working products that solve a real need. In the spring, the process repeats with Startup Studio, however students self organize into teams and focus on building a viable startup of their choosing. These opportunities to learn and build at the same time are what make Cornell Tech a truly special place for those who want to make their mark on the world.
For Product Studio, my team partnered with Weill Cornell Medical Center to focus on “how we might help clinical researchers visualize and explore the extent and availability of EHR data”. Our journey started as the intro mentioned, talking to as many clinical researchers as we could to understand the root of our proposed challenge. We learned that clinical research using EHR data was slow due to the transactional nature of the data and the antiquated regulatory hurdles required to gain access. Our initial analysis concluded that the transparency of EHR data was the crux of the problem.
Cool ≠Valuable
Focused on speeding up the process by improving data transparency, we built a quick prototype using Adobe DX and InVision to show how data could be represented better if it were stored in a graph based database and displayed more intuitively. Testing this solution with a number of practitioners resulted in mixed reviews, suggesting that while our solution was more appealing than existing ones, it wasn’t solving the core of the problem. It was cool but not valuable.
Not convinced we were on the right path, we revisited the problems we’d heard along the way and how our solution aligned. It became clear that while data transparency was an issue, an adjacent problem was that there are many ways to express clinical terms as EHR data elements. This results in it being really hard for researchers to search for a certain topic and be comfortable that they are returning all of the qualified patients. At about the same time, we stumbled upon the concept of “computable phenotypes”, which are essentially definitions of clinical terms but described in data elements from EHR data, but found that they were really difficult for researchers to find and use.
This confluence of problems led us to pivot our product to focus on creating, aggregating, and easily applying computable phenotypes (CP) to clinical data. With Hubble (our product name), clinical researchers could simply search a condition they want to do research on, compare how the different CPs apply to their data, then easily add that CP to a broader query of patients for their research. By making this initial definition step easier and instantly applying it to their data, we could take a large chunk out of this currently laborious process of query definition.
We built the initial version of Hubble (no live data, try searching Asthma) using Flask(Python), MySQL, and Material and created CPs by manually standardizing a number of phenotypes we found online.
Initial feedback on the concept was positive and, although the semester is winding down, we’re actively investigating where we could take the product from here.
Takeaways
While we may or may not continue our work on Hubble in the longterm, our work in Product Studio this semester has been insightful in a lot of ways. Here are some of the things we learned and/or think would be useful for others.
- Clinical research is a powerful resource to improve and create new healthcare treatments, but in many cases is understaffed or has antiquated resources. Many steps in the process are slow, sometimes for good reason, but need more attention from technologists.
- Much of the data collected from patients is transactional and structured for billing, not for gaining clinical insights. We believe this contributed to many of the transparency issues we saw, overall making the data less valuable. My opinion: If we’re going to put so much time and effort into recording clinical data, we should find a way to make it more useful for improving care.
- Throughout the semester we presented our challenge and product idea dozens of times and to very mixed crowds. Since we had a very niche and somewhat technical problem to solve, we found it difficult at times to get the impact of our product across to an audience. The art and importance of storytelling became acutely apparent. After trying a few failed analogies and spotty storylines, we landed a simple yet relatable example which showed why our product mattered. Focusing on relatable human impact helped us tell a better story.
- We had a number of conversations and brainstorming sessions before we even drew up a potential solution or prototype. While we learned from these conversations, it was nothing compared to how much we learned from showing someone a mock up of an idea that we had for a solution. We could have moved and learned even faster had we “built” something earlier. In essence, if you think you’re moving quickly, you can probably move more quickly (and cheaply).
Thanks for reading! Check out the Hubble code on GitHub. I’d also like to thank my teammates Hanbing Wang (ORIE 19), Yimeng Wu (CS 19), and Rehan Rasool (CS 19) for being killer teammates and people!
