Apr 29
2021
Healthcare Interoperability: Three Reasons Technologists Must Engage With Doctors When Designing
By Matthew Oldham, vice president of engineering, Graphium Health.
Over the course of my career, working in a variety of industries, I have developed certain design patterns when modeling data that guide my approach to tackling a new data domain. One simple example is how I choose the right data type for a given value an application will capture.
While it may sound straightforward, interesting nuances can quickly surface during the data modeling step that necessitate a shared language and vocabulary between the functional experts and the software engineers. In other words, we need to figure out how to work together and speak the same language in order to solve the problem well.
The importance of nuanced semantics may be illustrated with the example of how an anesthesiologist documents the administration of an antibiotic. . The type and timing of antibiotic administration is a key metric that anesthesia providers have historically had to report to Centers for Medicaid and Medicare Services (CMS) since it correlates with both patient outcomes and healthcare costs.
As I analyzed the paper anesthesia record used, I noticed an “antibiotics” checkbox, accompanied by an antibiotic name, an amount, a unit of measure, and the route of administration. These all made sense to me, and I proceeded to incorporate these concepts into my data model. For the antibiotics checkbox, I naively interpreted it as a simple boolean value, and I named it Antibiotics Administered Indicator. In my mind, that simply indicated that the antibiotic denoted on the form was either administered (true), or not administered (false).
During a review of the model, I learned that a clinician interprets this checkbox to mean an “indication for antibiotics”; in other words, antibiotics were or were not determined as a necessary course of action given other clinical conditions. A true value didn’t mean that antibiotics were administered, only that they were indicated, and thus needed to be given. That is obviously a completely different understanding than the one at which I had arrived. Needless to say, this was eye opening for me, even having been down the road of developing a functional understanding of data domains many times before.
The illustration highlights the importance of having both functional (i.e., the doctors) perspectives and technical perspectives present and engaged during software design. A purely technical survey of a subject area will certainly be valuable, and in some cases may provide decent coverage in terms of establishing a foundational understanding of that domain. In most cases, however, a functional perspective will also be required to complete the picture and add the necessary insight required to create an accurate and intuitive user experience.
In fact, healthcare may serve as the poster child for just how challenging, complex, and unforgiving software design can be. Clinician dissatisfaction and fatigue with existing electronic health report software is well documented, and the explanations are plentiful: failed interoperability, difficult user experience, inefficiency with simple tasks, onerous data capture burden, etc. Perhaps the common denominator is a failed understanding of complex and poorly defined clinical workflows being interpreted and standardized in software by technical experts working in isolation. The real issue here is that foundational errors propagate as the software evolves, and there is no easy way to reverse course once construction begins.