Resource:  Timothy Cook: Global Medical Research.org Member Submission

Where The Context Lies

Author:  Timothy W. Cook
This work is copyright Timothy W. Cook, 2008.
http://www.linkedin.com/in/timothywaynecook
23 September, 2008

This process has proven robust and reliable over many years and millions of
software applications being deployed when sound software engineering principles
are adhered to in the entire process.

Looking into the information management aspect a bit more to see how an
application like this actually manages information; we see that we store data
elements persistently and the software and/or data management layer manages the
relationships between the data elements.

Remembering that data elements are simply data elements. It is their relationship
to each other and their relationship to the user, via input and output design in each
application, that gives them their semantic context in order to create information
from their existence. As an example of the data versus information conundrum; let
us say that we have a data element of the integer 102. That integer can represent
many things. Is it a systolic blood pressure measurement, a heart rate, a body
temperature? It all depends upon the context that includes the units of
measurement. The validity and clinical significance also depends upon patient
position, point of measurement, device used, who the patient is, etc.

To be sure, there are certain elements of a database management system that lend
to this context. But do not forget that this is a part of the software layer not the
actual persistence of the data. While it is often conceived that table names and
column names in SQL databases provide this functionality. I ask the reader to
consider what happens when this data needs to be exchanged with an application
that uses a hierarchical or object or XML database? There is no standard way to do
this translation. In fact, even between applications based on SQL databases, the
migration of data must be performed on a casebycase basis where the table and
column names are not the same and a custom translation must be built for every
case.

Certainly the development of standardized HL7 messages was a big leap forward in
information exchange in healthcare. Two big drawbacks to this approach are that
the message formats had to be made very generic in order to accommodate systems
that may or may not have all of the data elements in a specific message and this
exchange process requires a manual mapping on both the sending and receiving
ends for each message to their local database. An entire industry developed
around providing these mapping engines and the expertise to setup the complex
mapping routines. Even if the development of the message formats were defined by
domain experts, the mapping is typically performed by software experts, not
clinicians.

Healthcare information can be and should be used by many people. From the
stream of healthcare providers involved in the care of one patient all the way up to
epidemiologists and healthcare provisioning experts such as policy makers and
economists. Scanning the literature the reader will find many many calls for various
standardized data sets to be built into applications. These data set calls are almost
entirely made based on the interests of the people making this call. Common sense
and indeed experience shows that there is no way for every healthcare application to
incorporate all the “minimum data sets” being requested by these competing
interests. Even if there existed this magical cover all minimum data set, remember
that the real semantic context of collected data that results in information is in the
software of the original application not in the data itself.

Completely controlled environments like the U.S. Veterans Administration and
KaiserPermanente have demonstrated that a centrally controlled approach to
healthcare information systems development and management using current
approaches does work and does reduce adverse events as well as improve access to
patient information at the point of care. The evidence exists that interoperable
healthcare information systems are a benefit to those organizations as well as to
their patient population. However, even in countries with nationalized healthcare
services it is improbable if not impossible to mandate a common data set for all
healthcare information systems that meets the needs of all healthcare information
users.

What is needed is a new way of thinking about complex information systems. I'd like
to begin with an analogy. Thinking about the very popular children's (and adult's)
toys, Lego® blocks. A box of these blocks contains various sizes and shapes of
components designed to work together to form objects. The kit comes with
instructions so that a certain subgroup of the blocks can be used to build a truck.
Some of those same blocks can be used maybe in combination with additional ones,
to build a helicopter according to a different set of instructions. There are other
instructions to build various other objects all based on the same set of common
blocks all according to the restrictions described in the instructions.

What if we had a common set of healthcare blocks that were implemented in
software such that given instructions about any clinical concept they could
represent that concept as an information instance? We can call this set of
healthcare blocks a common reference model (CRM). We can also call the
instructions for each concept a Clinical Knowledge Model (CKM).

If the CRM is abstract enough then it could be implemented in any objectoriented
language on any hardware platform. It therefore provides the freedom of use and
creativity to meet the needs and desires of application developers. The CKM units
(instructions) can be described by the domain experts for each concept because they
exists as constraint descriptions of the very broad based CRM. They do not exist in
software themselves. They simply tell the software what they are representing. In
fact they describe themselves completely with all of their semantic context. Since
they exist as data instances and not lines of software code; they can be be
exchanged with other applications based on the CRM without any loss of semantics.

They can be persisted in any type of data management system. They can be queried
with a standardized query language so that even the queries only have to be built
one time because of the standardized data structures. Best of all, when the ever
changing science of healthcare comes to call. A new version of a specific CKM can
be adapted from the existing CKM and there is no need to change the software nor is
there any loss to the semantic integrity of the existing data.

By now I hope that the reader is asking; when and how do we get started on building
this comprehensive, futureproof model for healthcare applications? Just think of
the implications. A blood pressure instance collected in a simple disease registry
can be transferred to a patient's electronic health record and/or to a public health
policy research application without translation and without loss of semantics. Of
course real world applications would include larger extracts than this and may
include components that describe the geographic area of the patient and the
location and setting of the measurement as well as who performed the
measurement. All of the context of this information exists in data instances and not
in software defined relationships.

But to answer the question above. The model is already designed. It is not only
designed but it has been proven in multiple programming languages using multiple
persistence layers on multiple hardware platforms. Of course the reference model
and knowledge model are not sufficient to build complete applications. There are
also definitions for service and support layers.
Healthcare information has many complex temporal and spatial components and
then mix in the fact that medical and healthcare knowledge changes rapidly. This is
the crux of why healthcare information systems are so complex and typically
'purposebuilt' without any real interoperability built into them.

There are health information experts that have looked at these specifications and
walked away because they believe that they are too complex. The fact is that the
specifications may be a little difficult to understand at first because the approach is
different. The reality is that health information management is complex. Better said
by a man that knew a little about complexity though:

“Everything should be made as simple as possible, but not simpler.”
Albert Einstein

Conclusion:
This new approach requires the reader to adopt a new way of thinking about
information system design. It does not require letting go of sound software
engineering principles. In fact this approach enforces the sound principles of
separation of software and data.

In the words of the great satirist Samuel Clemens;
“Don't let schooling interfere with your education.”
Mark Twain

It is this author's opinion that continuing with the insanity of doing the same thing
and expecting different results as if by magic, borders on being criminal. This
repetition is taking valuable resources from the global healthcare funds pool that
could be better spent delivering much needed services everywhere.
Of course high quality, rapidly delivered information is needed by decision makers in
order to provision those services. But we have proven that our current approach
leads to wasted time and effort and even poor quality results due to a lack of
interoperability across applications causing misinterpretation of existing data. We
must begin the change now.

The context currently lies in the software where we cannot exchange it. We need
to put it into the data where it belongs.

Recommendation:
You should begin with an educational process in order to understand this approach.
It is based on almost two decades of research, development and real
implementations of the principles. It will take time and effort to understand and
begin your own transitional process. It will take careful planning so that you do not
abandoned your existing information systems and the data that they contain.
I suggest that you contact myself or one of the other experts in this area to begin
your planning process. More information about these openly available
specifications, the community of people and the general principles of the concepts
are available at http://www.openehr.org/


Timothy W. Cook
http://timothywayne.cook.googlepages.com/
Email: timothywayne.cook@gmail.com