Last fall, Henry, one of Flatiron's product designers, wrote a blog post about how you can be successful at a healthcare company even if you don't have any experience working in a healthcare system. It made me reflect on how I've been able to transition in the opposite direction, taking what I thought was a huge leap from bedside patient care to successfully working at a tech startup. When I joined Flatiron in 2016, we had a very small Clinical Oncology team - the team was made up of myself, one nurse practitioner, one physician assistant and a practicing oncologist. I was overwhelmed by a new environment, new people and feeling the pressure to quickly learn the ropes. What I soon realized was that the knowledge and skills I have gained in my clinical career were highly transferable to my work at Flatiron and have helped shape a framework for the way our team operates today. Here's how.
Sitting on a product team is just like conducting patient rounds in the hospital.
I distinctly remember one of the first rotations I had as an oncology pharmacy resident at a large academic institution in Houston. Each day, we saw 20-30 patients during morning rounds with a multidisciplinary team comprised of the attending, a fellow, medical residents and students, a pharmacist, a pharmacy resident, nursing staff, a nutritionist, and a social worker. Every member of this team held a unique role in caring for the patient. It was my job to scrutinize each patient's medication profile, evaluate the appropriateness and effectiveness of each drug, recognize untreated health problems that could be improved or resolved with medication therapy, and advise the healthcare team and the patient on how best to administer their medications. I would spend hours preparing for rounds to ensure that I didn't miss anything and could make an impactful intervention for each patient. Sometimes I was able to make small interventions, like discontinuing a stool softener after a patient developed diarrhea. Other times, my contributions were much larger, focused on therapeutic drug monitoring and pharmacokinetic analysis of trough levels on conditioning regimens, immunosuppressants and antibiotics. What I learned from this experience was that cross-functional collaboration is not only crucial but necessary for successful patient-centered, comprehensive care. By working as a team we could collectively anticipate and ensure that all the needs of our patients were met.
This is not unlike how our product teams at Flatiron operate today, comprised of product managers, software engineers, designers, quality assurance specialists, product operations, product marketing, medical informatics and clinicians. As a clinician on one of the product teams, it is my responsibility to make certain that the products we develop are clinically safe and appropriate, as well as to collaborate with this multidisciplinary team to implement features that meet the goals and needs of our end users — doctors, nurses, pharmacists, ancillary staff, and administrators at oncology practices across the country. During team meetings, our contributions may be small (like changing the copy in the UI from "flowsheet" to "regimen" to ensure clarity) or large (such as creating and implementing a new disease model for leveraging clinical data), but both can have significant and long-lasting impact for patient safety and customer satisfaction. Ultimately the goal is to ensure the development of healthy and successful products so that our practices can ensure the health and success of their patients.
One of our internal Clinical-Product-Design workshops
Patient case-based learning is as effective during user research and usability testing as it is in clinical training.
Using patient cases as a teaching tool is a long-standing practice in medical education and training. A student is tasked with solving a problem or answering a question for a specific patient scenario. This provides a starting point for clinicians-in-training to think through how they would manage care in the real world.
When I first started sitting in on user research and usability testing sessions at Flatiron, I noticed that our users weren't always able to provide effective feedback to our user research and design teams. This was because the examples they were receiving from our teams were more conceptual, so it was hard to give tangible feedback. Keeping in mind how we used patient cases in my medical training, I thought we could bring realistic examples to our users so that they could test new features and effectively inform our solutions. To do this, I created realistic patient cases, using dummy data as shown below, within the user research guide.
After creating this case, we then create the data for this patient in the OncoEMR¬Æ testing environment so that our end-users have a "real-life" prototype to navigate through as we conduct user research for new features and products like our recently-released regimen selection workflow (images below).
We found that this process became an extremely helpful tool for bringing theory to practice for our end-users to test new features and validate whether we were meeting our stated objectives in the design process. We also repurpose these patient cases to conduct internal beta testing with Flatiron clinicians to ensure a consistent method for evaluating our products before we release them to our customer base.
It is equally important to ensure the engineering team has a full understanding of clinical concepts in order to proceed with software development as it is to educate your patients of the clinical concepts related to their diagnosis so that they can proceed with treatment and care management.
One of my primary responsibilities while in clinical practice was to educate patients about the chemotherapy they were about to start. Because of the complex nature of chemotherapy, the stress related to the patient's diagnosis, and potential cultural or language barriers, this can often be quite challenging. Not too long before transitioning to Flatiron, I was in clinic seeing a recently-widowed, elderly patient learning that his indolent cancer had progressed and that he would now require treatment. Due to his age, we decided to treat him with a less aggressive therapy, combining an oral drug with a targeted intravenous agent. We prescribed the patient 60 milligrams of the oral drug, but because it is only available in a two milligram tablet formulation, our patient would be required to take 30 tablets all at once every two weeks. In addition to going over the patient's disease with him and ensuring he understood the side effects to expect, I knew that I would need to find multiple ways to help this patient understand how to take his medication. We do this in a number of ways, including through conversations with the patients, written communications, visualizations, and reinforcement with follow-up phone calls and in-person visits. Despite using all of these tools, when I called the patient to check in a few days after starting treatment, I discovered that he had taken all 60 tablets that were in the pill bottle -- double his prescribed dose -- on day 1. We had to bring him back to the clinic to closely monitor him for toxicities, but eventually with more coaching and reinforcement, we were able to ensure he understood how to best take his oral therapy.
I have found that teaching our engineers at Flatiron about clinical concepts and workflows in order to successfully build out features are not unlike my experiences teaching patients similar concepts. Many of the problems we are trying to solve are quite complex and there can be a huge learning curve for an engineer to feel like they have a grasp on the clinical context.
One of the first projects I worked on after joining Flatiron was to update OncoEMR¬Æ to meet AJCC version 8 requirements , including developing new content and working with our engineers to build a new staging workflow. Shortly into the product and technical scoping of this work, it became apparent that a foundational understanding of cancer staging had not yet been set for the team. To tackle this, I developed a comprehensive presentation on the elements of cancer staging, including terminology definitions, workflow considerations, and other important clinical information. During the session, one of the engineers on the team said "I wish we had done this before we started this project." Now, our Clinical Oncology team provides a baseline clinical knowledge session at the kickoff of every project to ensure our engineers are fully equipped to be successful.
Taking the time to help our engineers develop a foundational understanding and knowledge of things like how chemotherapy doses are calculated or the significance of cancer staging is equally as important as educating a patient on their diagnosis and treatment. I use the same tools to guide these conversations, and just like with our patients, I've learned that this requires patience, that it might not stick the first time, and documentation and reinforcement are always helpful in the learning process.
When in doubt, use evidence-based data and expert opinion to make decisions.
All of my education and training to become a clinical pharmacist was centered around the utilization of evidence-based medicine to support decisions for patient care. I was taught that if you want to recommend a particular treatment for a patient, it needed to be backed up by primary literature. If I was creating a chemotherapy admixture, I should reference the package insert and appropriate tertiary sources for compatibility and stability. In reality, treating patients is not always black and white; there's an exception to almost every rule. We do our best to take the known data and literature as well as guidance from well-respected peers to make patient care decisions.
Being new to the technology space, I rely on this same principle when making decisions for content and features in OncoEMR¬Æ. In redesigning our disease list and staging workflow, I found it extremely important to utilize best practices, industry guidance and standardized content in order to carry out this project. Today, our Clinical Oncology team works hard to ensure that all content in OncoEMR¬Æ is also curated based on evidence and with the guidance from experts in the industry. As an example, through a partnership with the National Comprehensive Care Network¬Æ, Flatiron's Clinical Oncology team provides standardized, evidence-based regimen content to our network. When the prevailing evidence is vague and there's not clear guidance on how to move forward, we proceed just as we would in clinical practice. Regular tumor board meetings at oncology centers are a way to bring together the expert opinions of healthcare providers to determine the best possible decisions for a patient's care. In a similar way, I have implemented an internal Clinical Oncology Review Board, where our team brings together our individual knowledge and expert opinion to form consensus on design and functionality, especially when the decision is not obvious. During a review board, we answer questions like "What is the ideal content source to leverage for diagnosis synonyms?" or "Have we accounted for all the workflow scenarios for adjusting a patient's dose through these mock designs?" We then take the answers back to our product teams so that they can execute confidently.
Above all else, patients come first.The one thing that ultimately made my transition to Flatiron the easiest was that our mission aligned with the oath I took as a clinician to do no harm and always put patients first. At Flatiron, our mission to improve lives by learning from the experience of every cancer patient resonates for me, as our team aims to drive the clinical accuracy and safety of our OncoCloud products. We challenge the definition of "done" so that we account for the edge cases where providers most often need technology to assist them in providing safe and effective care for patients.
Since the time I've started, our Clinical Oncology team has grown to 12 oncology-trained clinicians who all believe in our mission, are passionate about bridging the healthcare and technology industries, and above all else, hold patient care at the center of their work. We now have a standard framework to help other clinicians make the same transition from bedside care to tech startup. Today, we are integrated into all of our clinical product teams to carry forward our mission. This is now how we clinical.