By: Charlie Harp
Precision Medicine – Promoting Healthcare Through Clinical Interoperability
The term “Precision Medicine” has been in the news of late. For those of you who missed it, here is a blurb from the whitehouse.gov website:
For many of us who have been in this industry for years, the idea of individualized medicine is not an epiphany. It is the promise of any electronic medical record and a vision that could not be realized without the help of computers and software, as the amount of information and orchestration would not be possible for a human care provider alone. We have been building software systems in healthcare for decades trying to harness the power of technology to improve how we care for patients and yet the dream of individualized care has eluded us.
So the question is, what has been stopping us? The answer is not a simple one.
On one hand, computers and software have been leveraged in healthcare in several significant ways. Computers allow for smart pumps, MRIs and other amazing diagnostic and monitoring tools. They allow us to move information around, store it in a digital format for quick retrieval and analysis; to some degree, over various populations. But all of these things still require a human operator to use them in a trusted way. In other words, they are “tools” that we can use like a hammer to drive a nail. How does a tool become something more than a tool you might ask? Consider an anachronistic little tool some of us used to use quite a bit, the paper map.
Using a paper map is a good metaphor for healthcare. It is difficult to use a map and drive at the same time, dangerous in fact. Maps need to be understood and you have to figure out the shortest way and guess where the traffic might be good or bad. At some point in our recent history we replaced the paper map with something that does all of this for us, a personal global position system or GPS. We tell the GPS where we want to go and the GPS tells us when to turn, routes us around traffic and knows exactly when we will get there. Every now and then there is a road block or we forget to update our maps and we have to take over, but by and large we rely on this technology to guide us while we drive the car.
Any early adopter that bought a GPS when they were “new” has stories of GPS misadventures.
When you were trying to find a Starbucks and ended up at a person’s house in a residential neighborhood. (I thought about ringing the doorbell and demanding a Caramel Macchiato…). Or you are late for a meeting because the GPS took you to an address 45 minutes in the wrong direction. But for each misadventure there were hundreds of successes and today the GPS (whether a standalone device or an app on our smart phone) is, barring operator malfunction or poor reception, nearly infallible. As a result we have grown to trust the GPS. Trust that it knows what’s going on and will provide us with guidance that will drive (pun intended) us toward our desired outcome.
What will it take to build software that healthcare providers can rely on in a similar manner?
It will require that we create a software ecosystem that delivers highly relevant clinical and administrative guidance that can be trusted by human providers. Like GPS, this ecosystem should support care delivery, not seize control, so providers are still in the driver’s seat.
For a software application to earn this level of trust, it will need to be a true clinical application. The goal of this series of posts is to describe the characteristics of a true clinical application and discuss what it will take to move our industry into the future.
When we started Clinical Architecture over seven years ago, we chose the name of the company based on our belief that the healthcare industry needed someone that was dedicated to establishing foundational components for healthcare, a “clinical architecture” for others who share our vision to leverage. Our product Symedical®, which was designed to allow software systems to “understand” information they acquire, host, share and exchange, regardless of the format or terminology, was a fundamental first step in this process. And, there is more where that came from. We are committed to be a catalyst for change and, like any catalyst, we are aware that we cannot do it alone.
The first step towards getting somewhere is to decide that you are not going to stay where you are.
If the first pillar of a next generation clinical platform is the ability to understand what it knows, the second pillar is the ability to increase the applications knowledge by adding information from elsewhere. Accumulating meaningful and actionable information from external sources is essential if we are to create clinical platforms that augment the abilities of the provider in a significant manner.
There are several aspects to this accumulation mechanism that can be especially impactful. A well-designed clinical platform should be able to ingest and leverage the following types of information.
- Patient information from other venues
- Explicitly curated clinical facts
- Explicitly curated clinical guidelines, advice or reference information
- National, regional and local population trend information
- Other ancillary clinical or administrative information
While all of these types of information are important, this post will focus on acquiring patient information from other venues. This ability to exchange patient information between systems is commonly referred to as “clinical interoperability”.
What is “Clinical Interoperability”?
Simply put clinical interoperability is the ability for the applications we use to share information about the patient. In order to be meaningful, the information we share must be understandable, actionable and trusted. If this is true, the information can be incorporated into receiving application and used to help the provider with clinical decisions.
Think of the clinical application as a human assistant to the provider. The interface is like a conversation between two assistants. If the assistant on the receiving end is going to supply information to the provider that is critical to the patients care, you would want to ensure the conversation is complete and facts discussed are well understood.
When you think of the applications in this way, the manner in which we interoperate today (to a large degree) would seem comical. Imagine a human assistant calling another human assistant and having the following conversation?
| Sending Assistant | Receiving Assistant |
|---|---|
| I am calling about Fred Smith | |
| Great! We are about to see Mr. Smith | |
| He is taking a medication called <gibberish> in my language He said he is very allergic to Advicor, but let’s call it Alticor He has a condition that might be similar to ‘heart disease’ There is some other things I can’t tell you because the words I need to explain them are not available over this phone line | |
| Yeah… That’s not terribly useful | |
| Hey, I am only required to call you and tell you what I can | |
| I am going to have to ignore this conversation | |
| I understand, I do the same thing when you call me. Good luck with Mr Smith |
Obviously, this conversation between humans would never happen this way. When two providers talk in real life information is expressed by the sharing provider in terms they use and the receiving provider interprets the information into the terms they understand. During this process they ask questions about things that might be uncertain and they don’t spend a lot of time sharing information that is not relevant to the care of the patient.
I often wonder how much of the information applications receive from other applications is ignored by the receiving application until it has been assessed by a human. In other words, is this incoming information not trusted by default? I would bet that is isn’t. This is not because the receiver believes the provider that collected the information in the sending application was incompetent or dishonest. It is because most systems do not follow the golden rule when it comes to interoperability. “Share information with others as you would have them share information with you”. Many system do what they can to satisfy the letter of the law, which is likely to prove inadequate relative to the spirit of clinical interoperability.
The Semantic Tango
In many environments the current best practice is as follows:
- The sender starts with a complex, pre-coordinated terminology
- They then map that the closest term you can find in a complex, pre-coordinated standard terminology and send that out in a message.
- The receiver then maps the standard to the closest term they can find in the third complex pre-coordinated terminology in a target system.
Even if we do our best to share information by translating to an accepted standard, there are issues that make this process questionable at best. Not to mention that the mapping is traditionally done by humans at different institutions that do not have a common set of rules when it comes to mapping these terminologies. It is almost inevitable that the information we send will undergo a semantic drift and change in the process.
Is it any wonder that our default position is to distrust the information we receive in this way? Information that is not trusted requires human intervention to be included. If the current process requires human intervention, then it is not really helping us to be more efficient.
In order to allow a system to expand its understanding about what is going on with the patient we need to have a mechanism for sharing information without losing or changing it. The current approach of using a pre-coordinated terminology as a semantic pivot makes this difficult. Using this approach often requires that we make our information fit into the list of standard predefined terms. If it doesn’t, we either add information (by selecting a more specific or “narrower” term), lose information (by selecting a less specific or “broader” term) or give up and send free text.
How do we improve the fidelity of shared information?
Some might suggest the answer is to mandate that providers enter patient information using the ordained standards at the point of care. It doesn’t take much mental calculus to determine all that does is force the provider to cope with the same specificity issue, except now they are doing it in their head… which is even more dangerous.
Post coordination, as discussed in the previous post, allows the data model to embrace differing levels of specificity. This goes a long way in resolving the issue because it allows for dynamic assembly of information. This would also accommodate inbound pre-coordinated terms as well, since most could be rendered into a post-coordinated data set.
Another option would be an intelligent mapping engine that renders pre-coordinated terms into post-coordinated expressions in order to find the best fit (and I know where you can get one…).
The bottom line is we need to recognize that the reason we should do it is not to satisfy some edict from on high but rather to provide information that helps the patient, our patient, get better care.
In this post I have been focusing a lot of attention on the core notion of semantic interoperability, the ability transform concepts from one coding system into another without changing it. This is because that is relevant to the mechanisms and approaches we have today. Even if we are able to get the “Semantic Interoperability” mechanism right, that is only part of the puzzle. There are other aspects of sharing patient data that will be just as relevant once we are good at it. Let’s spend a little time talking about some of those.
Electronic Hearsay
When one venue sends information to another venue there is likely baggage that goes along with it.
This could be:
- – Semantic drift introduced in the mapping
- – Information that the sender had received from another venue
- – Information asserted by the patient based on what they googled the previous week
- – Information introduced by a “work-around” in the source application
This baggage takes the form of misinformation on the receiving end. This misinformation undermines our ability to trust any assistance the application might render. In order to mitigate this effect, we need a way to gauge the confidence level of each piece of information, to calibrate uncertainty.
Calibrating Uncertainty
Determining the certainty of each piece of information about the patient will result in better advice for the provider and a natural mechanisms that helps us cleanse the patient record of junk information that is not correct. The mechanisms that we use to calibrate uncertainty will need to examine the information asserted about the patient. They will assess contextual contradictions that cast doubt or contextual entanglement that reinforces the validity of an assertion. Once a piece of information is flagged as uncertain it should be routed to a human for review and leveraged with caution.
What should we do with a piece of information if it is determined that it is incorrect or junk? Should we delete it? Only if you like deleting over and over again…
Orbiting Junk Data
Since we are living in a “connected” ecosystem, removing the information will not be enough. Once introduced into the ecosystem, bad information will likely find its way back to a receiving system over and over again. In order to avoid having the provider delete it repetitively we will need to have mechanisms that shield us from the re-introduction of this data. This is harder than you might think and might not be possible without the cooperation of the ecosystem itself.
What about that other stuff over there?
When we talk about sharing information we tend to focus on terminological data and results. No matter how sophisticated healthcare platforms become there will likely be a need for narrative, unstructured information. This information has inherent value (some would argue more value than discrete terms) and should also be processed in a meaningful way. (Processing clinical language into a computable form is a worthy topic that would extend this already overly long post so I will address it the future.)
Human Contingency
Even in our utopian future sharing information will not be without exceptions. The mechanism that consumes patient data will need to know when to ask for help from a more sophisticated and expensive mechanism… us. Since we are counting on this information, the process will have to be quicker than it has been historically.
Sharing Patient Information – Nutshell version
In order to share information in a manner that meets our trust requirement the clinical platform will need to be able to do the following:
- – Support high fidelity semantic interoperability for discrete information
- – Calibrate uncertainty to identify and quarantine junk information
- – Shield the patient record from the re-introduction of junk information
- – Support the ability to consume and use narrative (non-discrete) information
- – Know when it needs help and get that help fast
Over the last few weeks I have written about what it will take to establish a clinical platform that is capable of supporting the delivery of precision medicine. The clinical platform has at its foundation several architectural pillars. The first pillar, described in the second post, is the ability for the platform to model information and knowledge in a way that provides a stable and trusted representation of the patient for the provider. In that post we focused on how terminology can hinder this requirement. In this post we will talk about an aspect of the data model that can also play a significant part in providing a meaningful representation. This aspect is how the data model handle the patient and their motion through time.
Back in My Day…
The net result is that generally we have not designed healthcare systems to handle the flow of time, at least not in a way that will support a true clinical platform.
The Introduction of “Temporality”
A clinical platform that can provide a comprehensive, trusted view of the patient will have to provide a mechanism that accurately represents the patient’s information as it flows through time. This is the notion of the sequencing of past, present and future relative to an entity is known as “temporality”.
A fun, informative 4 minute video on temporality, from yours truly, can be found here.
This temporality mechanism will need to processes episodic data (from provider interaction and data exchange) and funnel relevant information into a new type of data model that provides temporal (time-based) frames of reference on the patient’s clinical continuum.
The “Current State”
While all of these frames of reference are relevant, the most relevant is the frame that represents the present. This frame of reference, that I will call the “Current State”, is the most dynamic as it is constantly changing as the patient moves through time. What makes it the most relevant is that it lives on the cutting edge of the decision making process for a given patient.
Unlike episodic data, that is a memorialized snapshot from a moment in time, the current state must be capable of grooming itself, regardless of external influence. For example, if a patient has a visit where they have a broken arm the episodic data will always show the patient with a broken arm. When this episode is introduced into the current state, the current state will show that the patient has a broken arm as well. At some point in the future, regardless of whether and subsequent episode is experienced, the broken arm will move from the current state into a historical state.
The impact of the episodes on the patient’s clinical continuum do have a permanent effect on continuum but some of them naturally fall out of the current state and are left to history as the patient moves forward through time. The episodes themselves are not necessarily part of the continuum – they are more like the receipts that show where the patient’s clinical continuum came from.
This clinical continuum is more than about showing the patient’s history. It will enable a new kind of clinical decision support that will provide a more relevant clinical summary for the patient at the point of care and allow us to factor time into our reasoning in ways we can only imagine. It also makes it possible to establish frames for probabilistic future scenarios for the patient so that we can predict and, hopefully, influence outcomes in a more meaningful way.
A Word of Caution
Our past is written in episodic data and the easy path is one where we disable our monthly purge routines and accumulate this episodic data into a “pseudo current state”. This approach will result in a cacophony of useless information. Each time we try to take the easy path and it fails we undermine our credibility and increase the cynicism and resistance of the provider population.
Earlier in the 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
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?
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.
On September 12, 1962, President John F. Kennedy delivered a memorable speech at Rice University in Houston, Texas. It is sometimes referred to as the “We choose to go to the moon” speech.
The speech was made during the Cold War and “Space Race” with the Soviet Union. The president explained to the American people his reasons for supporting a manned expedition to the moon. It is a good speech and I recommend giving it a listen.
I am referencing it for two reasons.
The first is because the speech contains several great lines that speak personally to me, specifically when I think about why I put down roots in this challenging and frustrating industry. Here are a few of them:
“All great and honorable actions are accompanied with great difficulties, and both must be enterprised and overcome with answerable courage.”
“We set sail on this new sea because there is new knowledge to be gained, and new rights to be won, and they must be won and used for the progress of all people. For space science, like nuclear science and all technology, has no conscience of its own. Whether it will become a force for good or ill depends on man”
And the most famous Quote:
“We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.”
My favorite quote:
“But if I were to say, my fellow citizens, that we shall send to the moon, 240,000 miles away from the control station in Houston, a giant rocket more than 300 feet tall, the length of this football field, made of new metal alloys, some of which have not yet been invented, capable of standing heat and stresses several times more than have ever been experienced, fitted together with a precision better than the finest watch, carrying all the equipment needed for propulsion, guidance, control, communications, food and survival, on an untried mission, to an unknown celestial body, and then return it safely to earth, re-entering the atmosphere at speeds of over 25,000 miles per hour, causing heat about half that of the temperature of the sun–almost as hot as it is here today–and do all this, and do it right, and do it first before this decade is out–then we must be bold.”
That brings me to the second reason I am referencing this speech… they did it.
That speech was made in 1962. The Apollo landing on the moon took place in July of 1969. The last Apollo Mission was launched in 1972.
This herculean undertaking was completed and they landed men on the moon before the end of that decade. Granted, it was a priority of a galvanized nation that was willing to spend $25.4 billion on it over 10 years, but it is still an amazing achievement.
Fun fact: In 2015 dollars, that would be $155 billion over 10 years or $15.5 billion a year. According to the Government Accountability Office, duplication of federal programs and services costs taxpayers $45 billion annually.
A few more interesting facts about project Apollo:
- The Apollo program was before personal computers and electronic calculators. Slide rules were used extensively to perform the calculations for mission planning.
- The Apollo Guidance Computer (or AGC, pictured at right) was more basic than the electronics in modern toasters. The ACG had approximately 64 KB of memory and operated at 0.043MHz and sported and intuitive user interface called the DSKY (which stood for Display and Keyboard… see told you it was intuitive).
- The Goddard Space Flight Center used IBM System/360 Model 75s (with over 1 MB of RAM!) for communications across NASA and the spacecraft.
- At the time, IBM described the 6 MB programs it developed, to monitor the space crafts’ environmental and astronauts’ biomedical data, as the most complex software ever written.
- At its peak, the Apollo program employed 350 engineers.
Essentially, a 1 GB USB memory stick is more powerful than the computers that put us on the moon.
Perspective
In a span of less than 10 years, a team of engineers did something amazing. They invented technologies that did not exist. They solved problems that could only be speculated about; like what it would take to land on the moon surface…
It begs the question…why is it so difficult to create a clinical platform with the characteristics necessary to assist a provider in a meaningful way?
Is it money?
According to a 2013 report by Technology Business Research, spending on Healthcare IT in that year exceeded $30 billion dollars. That seems like a lot of money to me.
Is it technological limitation?
Of course not. I have a super computer in my back pocket that knows where I am, how many flights of stairs I have climbed and if it is supposed to rain tomorrow.
Is it the people?
I have worked in other industries. My empirical assessment is that the people who work in our industry are some of the most innovative, brightest, passionate and dedicated people I have encountered in my professional career.
Is it the subject matter?
Healthcare is difficult and scary, it’s true; but I have to say that I have seen people more upset about a banking application losing a penny than a healthcare application losing a critical patient allergy. Part of this is due to the fact that we still rely on the human provider to do all of the heavy lifting and the human patient to remind the provider by filling out forms…over and over again.
Building smarter and more helpful solutions in healthcare is a solvable problem. I am not talking about software practicing medicine. I am talking about software that can accurately store, share and represent patient information in a useful way and periodically give the provider advice and help them avoid critical mistakes. This is not rocket science (you see what I did there…).
Is it momentum?
Change is difficult. Change in an environment where you are always “on” is even more difficult. I have worked in hospitals and to say they are complex orchestrations of systems and software would be an understatement. It is also easy to take comfort in the known, even if the known is antiquated and limited.
Is it incentives?
Perhaps. Historically we built systems in Healthcare that were driven by revenue; charge capture and billing for services. This resulted in less than wonderful clinical capabilities because the clinical aspect of healthcare was not our focus. That was a problem for the human provider in the equation.
Today, I fear we are doing something similar. We are providing incentives for things like specific outcomes and mandating “meaningful use” standards based interoperability. These things are done with the belief that the tail can, in fact, wag the dog. I am not so sure. I think our priority should be assisting the provider in caring for patients and helping them scale their ability to provide that care. Directing our intention elsewhere is a distraction, even if it is a lucrative one. I believe if we do our jobs well and providers do their jobs well, patients will have better outcomes. I am not sure this is something we can legislate.
The Road to Precision Medicine
Regardless of what barriers have stopped us, it is time we begin our journey down the road that leads to a clinical platform that can assist providers. It will be difficult, and innovation will require periodic failure to work its magic. If we could land a man on the moon in less than 10 years, we should be able to have smarter clinical platforms in five. (Technically, we have been talking about CPOE since 1998…).
All of us, in Healthcare IT, have an opportunity and an obligation to create solutions that usher in a new era of provider efficiency, patient satisfaction, clinical understanding and improved outcomes.
At Clinical Architecture we will do our part. Our mission is building foundational components for smarter clinical platforms that will enable our partners to accomplish amazing things.
If you are interested in exploring how Clinical Architecture could work with your team to continue your journey, we would love to hear from you. Contact us and let’s see what we can accomplish together.
I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I—
I took the one less traveled by,
And that has made all the difference.
Frost, Robert. “The Road Not Taken.”
The Norton Anthology of Poetry. 4th edition.
Charlie Harp