When considering the notion of decision support in healthcare, it is important to understand the appropriate role of the clinical platform when it comes to making decisions about the care of the patient. Once again, I turn to the GPS as a metaphor. With a GPS we, as the driver, are not required to do what it tells us. We are allowed to leverage our own judgment and alter our course away from the selected route. Granted, we will hear the inevitable “recalculating” and we might even get the “make a left turn followed by an immediate left turn” (which is GPS-speak for “where do you think you are going?”) but eventually the GPS will adapt its route to meet our needs or we will turn it off. My point here is the focus of the platform should be to assist the provider and not assume the mantle of decision maker. Occasionally the platform might stop the provider from taking some action and, arguably, stopping a provider from doing something is a form of decision making. The platform should only interfere in situations where there is absolute certainty the provider’s action would result in a catastrophic outcome; similar to a GPS having the ability to slam on the breaks before you plummet off a cliff. The litmus test for this decision being correct is, when it happens the provider should feel an immense sense of relief with the decision that was made.
Types of Shared Knowledge
Other than the patient information shared between clinical platforms, what are the general types of information needed by the platform to fulfill its purpose?
Reference Terminologies – These are the fundamental building blocks of information the platform uses in its model to represent, reason over and process information. This could include standard, commercial, platform specific or local terminologies.
Master Data – This is information, built from the reference terminologies, that describes the structure, constraints and general information the platform requires to supports its core functionality.
Facts – This information includes generally undisputed and well defined rules which describe how items in the reference terminologies relate to one another. These facts allow the clinical platform to have a fundamental understanding of medicine that can be leveraged during the decision support process. This type of information may grow or get refined over time, but should not change in a fundamental way. Facts do not have a stated outcome, they are just facts.
Beliefs – This information includes evidence or experience-based assertions that are intended to drive or avoid a particular outcome. These ‘beliefs’ are different from ‘facts’ in that they may be disputed or may not be universally applicable. This is the difference between ‘knowing’ something is right and ‘thinking’ something is right. Beliefs should have an intended outcome. If following the belief does not result in the stated outcome the belief should be re-evaluated.
Policies – This information includes rules intended to assist the provider in complying with regulatory, corporate or local policies and procedures. Like beliefs that might have intended outcomes, the outcome of policies are likely to be administrative in nature, not clinical.
These facts, beliefs and policies are involved in medical decision making today. It just happens that the clinical platform that is leveraging them is the provider’s brain.
Some might argue that the conceptual differences between facts, beliefs and policies are negligible and they could be fundamentally modelled and used in a universal way. While this might be technically correct, I would argue that universal patterns by their very nature introduce compromise. I don’t think knowledge is an area where we should compromise. These types of knowledge are separate because each has a distinct function, likely source and unique implementation patterns. Even if we store them in a generic structure we need to acknowledge their differences so that we can manage and leverage them appropriately.
What Is the Source of Shared Knowledge?
Where shared knowledge comes from often depends on the type of knowledge. Typically the basic building blocks a system needs to function, like reference terminologies and master data should be provided by the platform vendor or created and managed locally. Curated facts, beliefs and policies could be provided by the platform vendor, purchased from a commercial content publisher, created locally, created in a community, or some combination of any of these. Considering the possibilities, the real question is, what should be the source of shared facts, beliefs and policies?
Please share any thoughts or comments you might have.