Electronic Health Reporter

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.

Here are three  reasons why functional insight plays an important role in healthcare software design:

1. Collective Understanding

First, it will establish a well-rounded understanding of the data domain. As was true in the personal anecdote I opened with, I correctly captured important attributes of antibiotic administration in my original data model. Unfortunately, I failed to understand an important nuance of antibiotic administration in the surgical setting. The clinical insight offered by my colleague closed that gap in my understanding.

2. Common Vocabulary

Secondly, a familiar, prevailing vocabulary will develop as clinical and technical teams collaborate. Over and over, I have observed each skillset bring their own terminology to the table, and, in the end, a more thorough vernacular emerged that made it possible to move the software design forward with much greater clarity. Smart teams will recognize this vocabulary and make an effort to document it for the benefit of future team members, marketing collateral, and training materials. Every once in a while, the simplest question: “Is this the term you use here” can make a profound impact.

3. Continued Momentum

Lastly, functional insight is critical in order to respond to a dynamic market. Like the finance industry, healthcare is no stranger to the imposition of ever-evolving regulatory compliance. Without the proper ability to interpret such regulation in an agile fashion, no vendor can expect to stay competitive. With CMS regulations, the challenges of firm deadlines and stiff penalties for non-compliance mean the market demands timely solutions. We must continue to innovate in lock step with these demands.

To develop a successful and effective platform, it is essential to have a partnership between technical experts and clinicians. Having open dialogue between parties and allowing them to share their expertise will deliver a one-of-a-kind experience for a very complex and nuanced workflow.