The Road to Precision Medicine – Part V – Sharing Knowledge

In an earlier post we asserted that in order to support the provider in a significant way, a clinical platform will need to share information.  We called this capability the second supporting pillar of this platform.  The first aspect of sharing we focused on was the ability to share patient information.  This is what we currently refer to as ‘clinical interoperability’.  It is essential to share what we know about the patient so the platform and the provider, have a complete and accurate picture of the patient’s current state.   In addition, if we expect the platform to assist the provider when it comes to decisions about the patient’s care, we must have a mechanism that allows the platform to share or learn other types of knowledge as well.   This ability for a platform to assess the patient’s current state against a set of curated knowledge is what we typically refer to as ‘decision support’.

Decision Support versus Decision Making

Sorrydave

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?

smalllearning

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?

As humans we integrate facts, beliefs and policies into our cognitive processes over time from various sources.  Our experiences with this information leads us to fill gaps in our knowledge of the facts, re-examine our beliefs and revise our policies dynamically.  This process allows us to get smarter, become more efficient and improve our results.  These characteristics should also be present for decision support in a clinical platform.

We should be able to select the knowledge we want from the sources we feel are the best with regards to the needed subject.  We should be able to acquire the knowledge in manageable chunks and should be able to adjust it to best meet our needs without breaking the update mechanism.

In general, the ‘brain’ in the clinical platform should have a number of characteristics that provide its stewards with the ability to choose, modify, monitor and manage how it helps the provider.

In the next post we will talk about what these characteristics are and why they are crucial if we want the platform to play a meaningful role in the care process.

Please share any thoughts or comments you might have.

Leave a Reply

Your email address will not be published. Required fields are marked *

18 + = 26