By: Charlie Harp
Over the past few years, there has been a lot of talk about concepts like precision medicine, population health, personal health records and other technological concepts. The hope is that one or all of these ideas will enable us to improve patient outcomes, reduce costs and reveal clues that will lead to breakthroughs in patient care.
The challenge for all of these, and any other initiatives around health information, is that software applications are not built to be truly aware of the patient’s clinical situation. There are a number of reasons for this, but first let’s talk about human clinical awareness.
Human Clinical Awareness
Human clinical awareness is a process we go through when presented with the abundance of information that exists for a given patient. This information could include medical records from multiple EHRs, medication history, procedure notes, encounter notes, images, lab reports and personal interaction with the patient.
When treating a patient, a human provider integrates information from all of these sources into their own mental reference model. While building this model, a provider will likely see information that is duplicated, outdated, obviously incorrect or missing, and they will adjust the model accordingly. The resulting model (coupled with the providers own training and experience) is used in a combination of intuitive and deductive processes for diagnosing and/or determining the best course of action given the patient’s current state.
In the past, this cognitive process was fairly straight forward. Providers had more time to consider each patient, there were fewer sources of information and the information was designed for providers to quickly and easily understand the patient’s situation in the form of notes dictated in provider-speak.
If you think about it, our efforts to help the provider by insisting that the information be entered into software applications has actually made their job more difficult. This is true in terms of effective, meaningful patient interactions as well as assessing and integrating the overwhelming and often confusing information that our loose confederation of healthcare applications typically provides.
Now I realize that software applications, having the ability to store and actualize amazing amounts of information, have the potential to deliver untold benefits in the form of clinical decision support and population analytics. The trick will be achieving this without impeding or completely disenfranchising the provider, a critical part of the very ecosystem we are trying to improve.
The question is, what can we do through software, that could actually help the provider help their patients – to easily and accurately tell the provider something meaningful that they don’t already know that can measurably improve patient care. One of the answers to this question is artificial clinical awareness.
Artificial Clinical Awareness
Artificial clinical awareness is a pattern that mimics the human cognitive process. It is a series of mechanisms that normalizes, sifts and summarizes available patient information into a reference model – similar to the mental reference model described above. Once the information is in the model, it can be evaluated using applicable content models (or ontologies if you prefer) and appropriate clinical reasoning logic to provide a variety of benefits to the care process.
If we simplify this process into four steps they would be: acquisition, summarization, reasoning and reporting.
In order to reason and evaluate for any situation, you need information. When it comes to health care and patient information, you are acquiring everything you can possibly get your hands on relative to the patient you are considering. Much of this information is available as structured data (information that is organized in a structured manner making it computer “processable” and identifiable for data mining and analytics purposes) in the patient’s medical record. Commonly, structured data is captured by the use of standard vocabularies. A key element in maximizing the value of structured data is to use codified, standardized vocabularies, such as LOINC or SNOMED CT. Acquiring standardized structured data can be challenging in and of itself. This is especially true when a patient’s information is spread out across multiple systems. To successfully bring this data together into your reference model requires a semantic normalization strategy which ensures the proper meaning of the data is understood and able to be aggregated and further analyzed to reveal greater insights about the patient. This strategy must not only account for code system variances across the vocabularies used by the source systems, but also variances in specificity.
Coping with structured data is only part of the acquisition puzzle. Additional information, often critical, is also embedded in unstructured notes. Having a mechanism that can extract targeted relevant information from unstructured text and convert it into structured information can play a large role filling in many of the missing pieces of the puzzle.
Once you have acquired all of the data from structured and unstructured sources into your reference model, the next step is to summarize the data and organize it chronologically. This reduces the likelihood that whatever reasoning logic you employ will not become confounded with duplication, old information or other “noise”. For example, knowing the ‘when’ for a given concept, like “pregnancy” would allow you to ignore it as irrelevant in the patient’s clinical context if the time frame for pregnancy is no longer relevant to the patient’s current state.
In some cases, semantic normalization will assist with the summarization step, as much of the structured information from disparate systems will normalize to the same concept in the reference model. In other cases, differences in granularity may require an ontology or content model to broaden or narrow the structured information into a single relevant piece of information. There may also be cases where neither of these approaches will suffice and specific summarization relationships may be necessary to support the construction of a useful reference model.
The goal of artificial clinical awareness is to enable software to evaluate patient scenarios and bring things to our human attention. To accomplish this requires units of logic that are designed to evaluate the reference model with a particular focus and to return information to us that we can consume and act upon. For the sake of definition, let’s call these units of logic a reasoner. In practice, an enterprise would have many reasoners that could be used individually or chained together to accomplish a goal. These reasoners could be focused on an individual patient or run against a very broad population of patients. They should be able to evaluate information over time and support vector reasoning like trends, medians and other aggregate functions on value-oriented patient data like lab results and vitals.
Since some of the use cases for artificial clinical awareness are urgent and often involve regional or local practices, it is critical that the platform supporting artificial clinical awareness accommodates those situations. This means that not only does the platform have to allow for centralized best practice-based reasoning, but it must also allow for the creation of local customized reasoning.
In the end, reasoners are not just units of logic for evaluation, they are also units of action. Reasoners could be used to identify patients with undocumented conditions, recommend interventions, suggest diagnoses, identify patients in a specific patient population or even evaluate patient records for incorrect or conflicting information.
These actions should be extensible, allowing the enterprise to create their own actions as needed. The actions should also allow the reasoner to communicate with the calling system using terminologies and formatting that the calling system understands. Included with the actions should be evidence providing a clear and accurate basis that the action being asserted is warranted. This evidence should be quick and easy to consume by a provider so they can quickly adjudicate the recommended action.
Programmers should build applications not reasoning logic
When dealing with artificial clinical awareness, it’s not good enough to have a static collection of hardwired reasoners if you really want to leverage the information that is moving through your enterprise. Just like the providers who work in our healthcare system, artificial clinical awareness needs to be agile, dynamic and responsive. We should be able to deploy a reasoner without involving a team of business analysts and engineers. A clinical subject matter expert should be able to create, test and deploy a reasoner in a matter of hours not weeks or months.
It takes a village
When we build these units of awareness, we also need to have mechanisms that allow us to share and distribute them as we see fit.
It’s time for something new
If you are intrigued by what I just described, you will be pleased to know that Clinical Architecture is now prepared to deliver it. The Advanced Clinical Awareness Suite, which employs a combination of “human clinical awareness” and “artificial clinical awareness” to bring critical insights to the forefront of the provider is now available as part of the latest release of Symedical® (1.8.2). Symedical is easily the most sophisticated healthcare specific, commercial grade terminology and content management platform available in the healthcare market today. It is our hope that the addition of the Advanced Clinical Awareness Suite will enable our clients and partners to quickly and easily learn something meaningful they didn’t already know about their patients thereby enabling them to provide the best care possible.
Watch this space
We always have new things cooking at Clinical Architecture. In the days ahead you’ll be hearing more from us about innovations we feel could make a big difference in the evolution of healthcare.