In the previous post I asserted that to accomplish our objective of creating an application that can serve as a trusted advisor to a provider it must be a true clinical platform that understands what is going on with the patient.
By true clinical platform I mean the software must have an understanding of the patient’sexplicitmedical information on par with or better than (a fella can dream) that of the provider and be able to engage with that information in a meaningful way. Second, the application must have an idea as to the provider’s objectives with the patient in order to provide useful advice. Finally, it should possess general information about medicine enabling it to provide valuable relevant insights that might have otherwise gone unnoticed. The first pillar that holds up this platform is terminology.
Consider our GPS metaphor. GPS gathers information about where we are, as well as our direction, speed and preferences. Once it knows that, we can tell it where we want to go and it will provide us with an optimal route. On the way, it can tell us what the speed limit is, advise us about points of interest and route us around bad traffic.
Imagine how ineffective GPS would be if it did not know where we are and could not tell us what direction we are moving and was only aware of the major highways... Welcome to Healthcare IT.
How does software “understand” the patient?
Software is not a Human
When we talk about understanding the patient it is important to remember we are talking about software, not humans. Software understands the world around it by modeling it. Software has a data model it uses to represent a patient, the other entities in the care process and its inherent knowledge of medicine. It cannot contemplate beyond the constraints of these data models. As a result, the limitations of the model constrain the software’s ability to understand.
The fundamental building blocks of data models are terminology. By “terminology” I mean discrete, stable coded values that represent concepts that are important to the data model. Regardless of whether the terminologies being used are standard, commercial or proprietary become an integral part of the model and constrain applications accordingly.
The whole pre or post coordinated thing (again?!?)
术语有不同的样式和格式ed on editorial policies. Pre-coordinated terminologies are those terminologies where a single code typically represents multiple things that have been “pre-coordinated” together into a single phrase.
An example of this would be ICD-10-CM code (D31.12) ‘Benign neoplasm of the left cornea’.
In this case I have the disorder, its type, the location and laterality and combined it into a single coded term. Most of the terminologies deployed in healthcare today are of the pre-coordinated variety. In fact, when you consider the standards we are supposed to use in healthcare today, most of them (RxNorm, LOINC, ICD9, ICD10, CPT to name a few) are pre-coordinated. There is a reasons for this; many of them relate to the way we have historically used terminology in software and in some use cases, pre-coordination makes sense (see thisblog post).
There is also the concept of "post-coordination”. In post-coordinated terminologies the codes are assigned to the elements of the concepts we care about and those coded elements are assembled together after they are assigned to represent a complex concept when needed (hence “post” coordinated).
An example of post coordination would be the SNOMED-CT codes (126997008) ‘Neoplasm of the Cornea’ + (30807003) ‘Benign’ + (7771000) Left.
In this case I have constructed a completed notion from distinct and separate parts. Post coordinated terminologies are less common in healthcare. SNOMED-CT, Radlex and the Healthcare Data Dictionary have been used to represent post-coordinated concepts in some applications.
The MRE is easier to use...as long as you want what is in the tin foil bag.
Most system designs have avoided leveraging post-coordinated terminologies. “Why?” you might ask. I believe there are a few reasons:
- Well-built, post-coordinated terminologies are rare. As stated previously we need good post-coordinated terminologies and models for using them effectively.
- It is not the way we did it before. Using post-coordinated terminologies requires a more sophisticated design pattern that is not just a dictionary table with an ID and description.
- "It's just terminology” syndrome. Historically, terminology is the second-class citizen of application design effort. We often hear “we want to keep it simple to start and we will come back and put better support for terminology in later” Which is similar to saying “lets built the house now and we will come back later and put in the electrical and plumbing.”
In a nutshell, pre-coordinated terminologies are easier. Easier is better... Right?Not necessarily.
Smarter is Better
Even though they are easier to use when building the application, their rigidity and seemingly capricious granularity limit how we are able to describe (1) the patient’s state, (2) the circumstances of the encounter and (3) medical knowledge as we know it.
Remember, terminology limits what the model can represent and the model limits what the software can understand. This limitation constrains our ability to trust that the software can provide us with useful information.
为了创建足够波形的软件rstands the patient, we must first address the architecture we use to represent information. Post-coordination, while challenging, will allow healthcare applications to represent what we know about the patient and surrounding context with accuracy and virtually unlimited variability. If done properly, it could actually free the provider from the yoke of terminology completely. Establishing a more accurate and complete expression of information within Healthcare IT will create a backbone that we can build amazing things upon.
At Clinical Architecture we have given this concept a great deal of thought and are working to provide software and tooling to facilitate this quantum leap in design. Our first product, Symedical, was designed to be a platform for managing and integrating terminology into healthcare applications. We did not do this because we love terminology, we did this because we understand that terminology is the first pillar of a true clinical application.
As always, you comments are welcome.
Next week we are going to talk about interoperability.
P.S. If you have ever eaten a MRE... thank you for your service!
