Back to Home

精密医学之路——第四部分's About Time

Written by Charlie Harp

February 17, 2015 at 7:00 AM

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 thesecond 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…

Mainframe

Historically, in healthcare, the way we have dealt with patient information was highly episodic. In many cases patient information for the visit, accession, encounter or claim was entered (or re-entered) at the time of that episode and was promptly archived or purged after a pre-defined interval. This made sense, since the primary purpose of those systems was to generate an invoice after the transaction (and disk space was at a premium).
Please understand I am NOT saying this as a criticism. This approach was not a design oversight, it was a valid design pattern that satisfied the business requirements at the time. Any software engineer that can't look in the historical rear view mirror and recognize some horrible atrocity they created, that did not have the good sense to die, is not being self-honest.
Many systems that we use today are evolved from those ancient titans from our collective past. As a result, these systems are clinically limited by the very DNA that made them successful administration platforms. You might ask “Why, after all these years, would they still have those limitations?” This is because complex, mission critical application are incredibly difficult to change in fundamental ways. Despite being overused, the “fixing a 747 while it is still in flight” metaphor is fairly appropriate.

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在这里.

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.

In the next post we are going to talk more about the shared information pillar with a focus on expert knowledge and advice.

Comments, kudos and criticism are all welcome. There might even be fabulous prizes for thought provoking insights.