Prevent “Un-Magical” -Magical Thinking about Software in Medicine by Walking Miles In Physicians’ Shoes
Everyone loves to talk about cross functional work but how many times do you see this happening successfully? In software and medicine? Hardly ever and why? The main reasons I see are fear of the unknown, fear of not looking your smartest, over-valuing what one has focused on in the past, and lack of focus on meeting others where THEY are. Technologists love to complain about healthcare, but how many technologists do you suppose can name every single step and minute of every patient encounter, coding, and billing action from a physician’s perspective? Similarly, there are some physicians that can code and are great programmers, but how many of them are concurrently developers or actual engineers? In both cases, practically 0 and that’s why software has not so far “revolutionized” medicine. Somehow the gaps between these disciplines need to be defined and translated. How does this start? It starts with TEAMS and by meeting each where they are.
Here is a post on how to generally define the differences between the scope of what programmers, developers, and engineers do in software: https://qr.ae/TWyTPh
Why Did This Clinical Team Have to Develop This WhiteBoard Workaround? It competes with the computer screen for attention:
For the last couple of years at Medigram, we’ve been focusing scarce time exclusively with those technical and physician leaders who have tried EVERYTHING to solve the same problem we’re working on. This is to rapidly compress time to mutual understanding in multiple areas. Doctors still can’t get information quickly on mobile and as one result, someone still dies every 9 minutes according to the Institute for Healthcare Improvement. Wondering if it is possible to reach software related alignment specific to mobile with physicians, we asked. “ Is it possible for physicians to gain deeper knowledge of database types and use cases, technical networking details, and how data moves over the internet to the endpoint?” If it is possible, how would that be achieved? We concluded that it would involve describing essential technologies and technical decisions in terms analogous to medical devices and classes of therapeutics they use. These are discernments they make between products in every patient encounter.
Having spent 15 years in healthcare and with the privilege to be mentored by, to mentor, and be friends with a number of physicians, I had recently become curious about what appeared to me to be a lack of their interest in software; specifically in the details that underpin the technology that they use every day. I asked many of them in not so many words, if it’s true that they are not curious or don’t care about software. Many of them admitted that just as they wouldn’t over-assert a clinical opinion into a different specialty than their own (as a primary care physician to cardiologist) or as a specialist to another specialist (such as cardiologist to neurologist), they also frequently didn’t feel comfortable challenging technologists; this is even though software frequently frustrated them or got in their way of treating patients.
After speaking with hundreds of them, a few things occurred to me:
- Physicians are so pressed for time, they hardly have time for the things they’re legally required to do, let alone train themselves in the inner workings of software.
- Physicians are looked to as “experts” in the context of their every day work; therefore many aren’t comfortable “not knowing” with software. They can seem inhibited to asking the “why” questions that frequently arise with every other category of technology or therapeutic they use to treat patients.
- The technology most people use today as consumers and that dominates much of the economy is frequently “planets away” from the mark in medicine. This is in the distance from not just the clinical requirements, but also the business, functional, and non functional requirements of software to be truly useful in medicine.
- As a consequence of huge industries being built on “one size fits most” consumer and B2B use cases, most engineers (and University computer science programs) do not focus on understanding, for example how information as bits get processed and delivered between endpoint (computer) to endpoint (mobile phone). As one rare truly “full stack” Medigram technical advisor puts it “Most programmers and developers have an expectation of network resources being available when they open their web browser of choice. They have some understanding of HTTP headers, but not much beyond.”
Web/desktop basics; most programmers and developers basically understand this concept:
In reality, to be an effective technologist, particularly in medicine it’s also about relating and communicating, not just coding. It’s not just effectively communicating what you’re building today. If you really need to connect with customers, investors, users, and a range of stakeholders required to build a business, not just a product you also need to understand yesterday’s models. This is even if you are pioneering today’s models. While many technologists wouldn’t themselves leverage the OSI model for example (pictured below), many other people still do. It’s about meeting them where they are.
This fuller stack understanding is required to solve for mobile and goes much deeper than familiarity with just HTTP headers and the knowledge of some presence of some network resources from the web browser.
As one example, the current dominant electronic health system used in California is built on a programming language called MUMPS. Imagine yourself back in the mainframe era and in a Disk Operating Systems, DOS context which is leveraging a complex spreadsheet-like layout and this is what physicians work with today in what many coin “desktop medicine.” It’s obvious to me as a technologist, why this database structure doesn’t accommodate high velocity reads and writes that define mobile communication. If you haven’t studied database types and use cases though, how would one know what’s appropriate? To understand the gravity of the situation, we highly recommend reviewing this report on EHR’s and watching all the embedded videos: https://khn.org/news/death-by-a-thousand-clicks/
Most “Digital Health Solutions” don’t address functional, let alone non-functional requirements. Software design frequently ends at UI-level user requirements and “Business objectives.”
Over the next weeks, we’ll be looking at the key parts of the stack required to enable mobile and intelligence through mobile data. This will be through analogies of common clinical decisions made by physicians when evaluating efficacy and safety of a range of products they use for patient care. Have any great ideas or analogies? Feel free to share them!
By: Sherri Douville CEO & Board Member at Medigram, Inc. https://www.linkedin.com/in/sdouville/
