We are on the front lines of the healthcare revolution along side our patients and our colleagues in technology. We have firsthand experience of the shortcomings in the healthcare industry, and we know that it’s going to take a concerted effort to upend the system. Those of us who are able to adapt and apply new technology solutions to existing problems will undoubtedly make positive changes.
Barriers to entry into entrepreneurship are falling as tools for innovation are becoming ubiquitously accessible. The next phase in healthcare disruption is taking place as smart doctors with good insights and creative developers/designers/engineers get together to create well-rounded problem solving teams.
Like any battle for change, good communication between all parties makes for a higher chance of success. Good communication starts with an understanding of the languages spoken between industries and herein lies the reason for this article:
Doctors suck at explaining their health IT ideas to the people who can help make them a reality.
It does not have to be this way. If one doctor is able to clearly communicate a complex case to another doctor of a completely different specialty, they can also learn to tell a compelling story about their idea to an engineer, developer, designer, etc.
Think of a technology solution as a patient we are trying to refer to another doctor. In order to give a successful consultation, we must follow specific rules that allow a structured approach to telling the story in a way that makes sense to the other party. We start with a case history to provide context and background, we give specific findings about our patient’s current condition, and we sometimes provide insights and recommendations for future care. This same structure can be applied to a conversation with a technology expert. In technology, we might call this consult structure a framework for presenting a solution. The case history becomes the story, the findings represent the data, recommendations represent insights that reveal the opportunity or solution to be built, and the admission onto the ward represents the successful development of a beta product or service to be tested in a live environment.
Of course, there are some rules of etiquette that should always be followed when giving a consult outside one’s own field. It is important to remain respectful of others’ expertise, but to present the idea clearly, and without jargon. Just because someone majored in computer science at MIT doesn’t mean they’ll understand the inner workings of the central nervous system, for example. There is a delicate balance between speaking over a colleague’s head and speaking down to them. Here’s how we approach it in our space:
1. Case history: the story
When speaking to our developers and engineers, the first conversation starts simply. The goal is to define the product or service in as few sentences as possible. If we accomplish a mutual understanding of the fundamental idea, we’ll have established a framework for moving forward.
Example: I want to create a mobile app that uses a sensor attached to an iPhone to measure saturated oxygen levels in my patients. I then want to take the collected data and create useful insights to give to my patients about their stress levels, in real-time.
This type of a statement should serve to stir up some questions from the tech expert (e.g. what kind of sensor? How is saturated oxygen related to stress?) which help us refine the story and judge their grasp of what we’re trying to accomplish. We use these questions to dig deeper into the experience we’re trying to create for the patient. This is extremely important when the discussion turns towards constructing the product so be sure to give user experience some thought ahead of time. Giving case examples is always a good idea, and having a clear opinion about what you want (as opposed to being vague) is also helpful.
Example: There is a sensor that measures saturated oxygen through infrared light. I’d like to reformat it to fit over the corner of an iPhone (like the Olloclip camera lens). If I can measure saturated oxygen in a person’s fingers, it will tell me a lot about that person’s sympathetic nervous system, and their stress levels. Imagine if we could track saturated oxygen levels at different times of the day, in patients who are dealing with chronic stress. We could use the data to give users insights and tips as to how to control their stress appropriately.
2. Significant findings: the data
Before any actual building of the product takes place, there is one conversation that must happen. The doctor and tech expert (probably the developer in this instance) should discuss in detail how the data is to be collected, presented, and used. This is the single biggest mistake that we see in cross-disciplinary teams and it is easily avoidable. There are a number of translations of data that take place when it is recorded, so planning for the best uses of the data can save time, money, and make for much more useful products.
While it’s not imperative to know the programming language that would work best, it is important to understand that lists and records are preferable. In most cases, we’re used to this type of information gathering because it applies to questions and answers that typically take place in a doctor’s office. Yes or no questions, multiple choice and scales all apply under lists and records. Here’s a little more about the native coding languages that work best for these types of partnerships:
- At our lab the engineers and developers prefer to use modern languages that are highly versatile, like JSON (multi-agent systems development platform, not person) that allow easy customization of the data.
- Think through the various types of data to be collected and how it will be used. In the example of the saturated oxygen iPhone device, we could capture the raw number, or we could place the raw number on a scale of normal ranges, or we could do both. The way we do this matters because it will determine how we can use the data to create insights and tips for the user.
3. Recommendations: the insights
In the delivery of healthcare, treatments are evidence-based, tested rigorously and scrutinized by multiple governing bodies before they are adapted into the mainstream. Healthcare technology does not follow this trend. The market moves too quickly for delays. Prototypes are created, tested and implemented in days or weeks in most cases, and doctors need to be ready to accept that their original assumption about the use of the product might change based on how it is adopted (or not) by users.
In the clinical setting, a consultation to a speciality service often leads to narrowing possible differential diagnoses. The attending doctor must then return to the available clinical data and reformulate a clinical strategy (e.g. order more labs and imaging or test out a treatment strategy). Similarly in tech ventures, doctors must be able to take feedback from both their developer team and end users and adapt or pivot their original idea incorporating the expertise of the team with whom they are working.
4. Admission on to the ward: launching a beta product
Getting a patient admitted to a specialty ward is only the beginning of the treatment plan. Similarly, launching a beta product is just the start of the development process. Doctors need to work even closer with their developer team and learn to iterate various parameters rapidly. The process resembles the decision making in managaing a critical patient. While the responsibility for making rapid product adjustments rest with the developer team, the doctor must be able to interpret the vital signs of usability and product relevance after its launch, leading the team to the correct interventions.
A translational skill
While there is no one secret to a successful team in any entrepreneurial ventures, they generally work best when the members of the team complement each others skills and strengths. In healthcare tech, clinical experience by itself will not suffice in bringing solutions to market. Rather, it is the effective communication of that clinical experience to the technical talent for implementation.
Doctors already round on a ward of patients every day. They break down complex patient histories into succinct presentations and form action plans from numerous specialities and allied health services. If we consider the process of creating and launching a product, the same skills are necessary. Ask questions, find trends, create opportunities, build a team of experts, launch a product, test your assumptions, relaunch, etc. It’s the same process. If we keep that in mind when working with our technical counterparts, rewarding health IT projects will result.
Sean O’Grady is co-founder of Syntropy. Jeeshan Chowdhury is co-founder of Hacking Health.
Submit a guest post and be heard on social media’s leading physician voice.
