The concept of time in a clinical context

A medical record must take care to properly represent times and dates of events. Ordering data represented on screen will reveal different aspects of the health care process. Traditionally, in a paper record, there is two places where times are mentioned - in the chronological order of entries and within progress notes themselves.

Electronic records allow for (not require) better granularity of time capture.

Time of ...

... clinical occurrence

Or: When did a clinical event actually happen ?

This is the time when a clinical event actually occurred in meatspace. In many cases the exact point in time is unknown (eg. onset of diabetes), in others it is quite well defined (time of impact in a car accident as the cause for a broken rib) or even known fairly exactly (time of appendectomy).

In GNUmed this time is stored in fields of the name .clin_when which are accessible by means appropriate to the actual clinical data.

... the care process

Or: When did the clinician become aware of information relevant to the care of a patient ?

This is the time(span) during which an encounter happened. Clinical data is transmitted from patient to doctor, or more generically, from the outside world into the care process. Thus all clinical data logically "belongs" to a certain encounter. Such data describes certain (often past) aspects of the health of the patient and the care process.

GNUmed does not store this time directly with clinical items. It rather links items to the encounter they were created under. The encounter contains a start and end timestamp.

... data capture

Or: When was an item of data committed to the database ?

This is the exact point in time when clinical data was actually technically entered into the database and may happen well beyond the encounter to which it belongs.

In GNUmed this time is stored in fields of the name .modified_when which are part of the change auditing framework.

Example "Tetanus booster"

• the patient received a booster shot on 2001-04-24 13:45
  • this is the time of clinical occurrence

• upon queried the patient relates this information during the encounter on 2006-11-18 16:04 - 17:36
  • this is the time of the care process

• three patients later the clinician notices that she forgot to document the tetanus status so she adds a *S*oap entry to that effect on 2006-11-18 19:17
  • this is the time of data capture

Other times

There seem to be more times for certain clinical items. Consider a lab result:

• when was the sample drawn
• when was the sample analyzed
• when was the result reported to the doctor
• when was the result entered into the database
• when did the result become known to the doctor
• when did the doctor acknowledge (and possibly act on) the result

However, careful consideration seems to support the theory that such things are indicative of insufficiently granular modelling of the care process.

Timezone handling

In a world of travel and global information links a patient may actually receive care in different parts of the world, that is to say in different time zones.

Time zones define what a particular timestamp means in relation to other timestamps such that absolute values for real world intervals can be established. Time zones exist so that we can all sort of agree on "7am, oh, that's when the sun is just about up." (within reasonable limits, that is).

Time zones are important to clinical care because the human body adjusts its circadian rhythm to the light cycle. As an example, assume a cortisol level of 5ng/ml measured at 7:00 am Central European Daylight Savings Time. If the result is displayed to a doctor in Tokyo under her local time zone it will appear to have been sampled at 14:00 in the afternoon. The cortisol level will appear to be off the normal range. In reality the value is not off-range. It is simply misrepresented in the context of the time zone the patient's circadian rhythm was adjusted to.

UTC ("Greenwich Mean Time") is used as an international reference time zone.

GNUmed internally stores all timestamps in UTC. It takes care to explicitely remember the time zone a certain encounter took place in (clin.encounter.source_time_zone). Thus clinical events can always be correctly related to each other. This approach is not without flaws but is a good compromise until PostgreSQL starts supporting a timestamp with time zone datatype which remembers the insertion time zone.

Clinical data is presented to the user mapped to her local time zone which is detected at client startup but can be explicitely configured in the configuration files. In relevant cases the time at the time zone of insertion is also provided.

Ensuring time consistency among systems

During startup the GNUmed client queries the local machine and the database server each for their notion of the current time. It then calculates the skew between server machine and client machine taking into account the roundtrip time on the wire and the respective time zones. If the delta between the both machines is "too large" it refuses to connect to that database and advises the user to take appropriate steps to synchronize the clocks. If this precaution would not be taken it could happen that data thought to be inserted with the time the clinician sees on his machine is actually timestamped with an entirely different value in the database.

Any GNUmed system is thus well advised to keep its clocks in sync with atomic time using the network time protocol or other means such as a locally connected DC7FF receiver.

Input and display of timestamps

As per the old adage ("Be strict in what you emit, liberal in what you accept.") GNUmed tries to support a multitude of input formats for date entry while displaying timestamps in unambigous formats. This is achieved by sending the input through several parsers and displaying a pick list if several matches would apply. On display either the YYYY-MM-DD date format of ISO 8601 is used or the month part is spelled out.