Over the course of my career, working in a variety of industries, I have developed certain patterns of modeling data that dictate my approach to implementing various aspects of any particular data domain. One classic example is storing boolean (true/false) values. While it may sound simple on the surface, interesting complexities quickly arise that illustrate the value in creating a meaningful semantic foundation to correctly describe the use case. In other words, we all have to figure out how to speak the same language.
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 physicians must report to Centers for Medicaid and Medicare Services (CMS) because it correlates with both patient outcomes and healthcare costs. As I analyzed the anesthesia paper record used to collect this data by one of our early beta customers, 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 model out the various attributes I identified. For the antibiotics checkbox, I interpreted it as a standard boolean value, and I named it Antibiotics Indicator (or, in abbreviated form, abx_ind). See, to me, that simply indicated that either antibiotics were administered (true), or they weren’t administered (false). It was a simple indicator. Right?
Well, what I eventually learned was that a clinician interprets this as an “indication for antibiotics”, meaning antibiotics were or were not identified 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 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. Semantics are important!
This illustration highlights the importance of having both functional (i.e., the doctors) and technical (i.e., the technologists, programmers, engineers, data architects, etc.) perspectives present and engaged when modeling a data domain. A purely technical survey of a data domain will be valuable and in some cases may provide decent coverage in terms of establishing the foundation necessary to model that domain. In most cases, however, a functional perspective will also be required to complete the picture and add the necessary insight required to deliver a high quality implementation with an intuitive user experience for the clinician.
In fact, healthcare may serve as the poster child for just how challenging, complex, and unforgiving accurate data modeling can be. Current clinician dissatisfaction with existing EHRs is well documented, and the explanations are plentiful: failed interoperability, difficult user experience, inefficiency with simple tasks, etc. Perhaps the common denominator is a failed understanding of complex, 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. In fact, those mistakes may lead to even more problems as increased regulatory requirements become more onerous.
For example, consider the recently released 2015 PQRS QCDR compliance measures. As an engineer, I can read through the QCDR Measure documentation with a technical eye and attempt to arrive at a conclusion in terms of how to appropriately capture the necessary data that allow our users to sufficiently report clinical outcomes. I can assure you, however, that I’ll also need help deciphering the functional components of that documentation in order to implement a quality technical solution. Things are seldom black and white, and healthcare is no exception. And, let’s be honest, the CMS compliance measure definitions are not without ambiguity. Such ambiguity only increases the necessity of having strong clinical representation as a data domain is modeled.
Here are 3 reasons why functional insight plays an important role in healthcare software design:
1. Understanding
First, it will establish a proper 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 design. Unfortunately, I failed to understand an important nuance of antibiotic administration in the surgical setting. The clinical experience offered by my colleague closed that gap in my understanding.
2. Vocabulary
Secondly, proper functional insight will establish a vocabulary that facilitates communication within the delivery team about the data domain. Since the data domain serves as the foundation for any software product, accurate communication at this level of the design is absolutely critical. Now, you may argue that the creation of such an ontology, even in the lighter form of a simple vocabulary, is not a passive act. I believe, however, that this vocabulary is a natural byproduct of the product evolution that will materialize in lock step with the overall product.
3. Efficiency
Lastly, functional insight is critical in order to efficiently react to a dynamic market. Like the finance industry, healthcare is no stranger to imposition of regulatory compliance. Without the proper ability to interpret such regulation in a credible and agile fashion, no company can expect to stay competitive. As we have observed with recent CMS regulations, the challenges of hard deadlines and penalties for non-compliance mean the market demands timely solutions.
That is just one value proposition offered by Graphium Health, and one of the reasons I feel we have been successful at designing an intuitive and effective solution. Our functional subject matter experts have been engaged from day one in the development of Graphium’s data domain. We’ve created a successful partnership between the deep technical expertise of our engineering team and the seasoned functional expertise of our practicing clinical providers, and this partnership has delivered a one-of-a-kind experience for a very complex workflow.
