Date Display - Short Date (EHR convention)
Too often on paper medical documents and digital health record, it is unclear what the date is. Sometimes the day is written dd/mm/yy, other times mm/dd/yy, and even on the same form.
Spending time to figure out what the date reads is a waste of time and clearly dangerous.
The following rules are a suggested approach to the display of dates in health care.
I think these make the most sense for English speaking countries. Please see the post (Date Display - variations by country & language) to understand why these guidelines may not transfer one-to-one in other languages.
This post is based heavily on the NHS Common User Interface Guidelines. That project looked at existing standards and best practices to date (last updated in 2015), as well as took into consideration patient safety issues in the NHS. They prioritize display that confers: certainty, clarity, and readability.
The original NHS, User Interface Guidelines (June 2015, Version 5.0.0.0) Date Display PDF is located here.
Short date format: summary
The short date format should be used to display the date on materials designed for consumption by healthcare workers. This guideline is suggested by NHS' CUI.
NHS CUI advises the long date format only for patient facing materials. This definitely simplifies things, and so I agree with this recommendation as a way to simplify the UX too. See further, Date Display - Long Date (EHR Convention).
Short date format
MM-DDD-YYYY
09-Sep-2008
Short date format, with day of week
Tue 09-Sep-2008
Day-of-week: written as three-letter abbreviation. Starts with a capital. Has a single space between the day-of-week and the day. Wherever reasonable, the day of the week should be included.
Day: always written as two digits. If the number is under 10 a leading zero is used.
Month: written as a three-letter abbreviation. Never as a number.
Year: always written as a four-digit number.
Separator: a single hyphen sits between the day, month, and year elements.
Sequence: the order is always day-month-year
Short Date Format - Conventions
These rules are written in the order that I think arguments for each are the strongest.
Rule 1: always write the month with letters
Different countries represent the entities of day, month, year in varying order, and sometimes with multiple acceptable orders. See date format by country on Wikipedia.
Furthermore, from my experience in Canada, paper-based and digital forms frequently mix up and use both the dd/mm/yyyy and mm/dd/yyyy digits. I've even seen this happen within the same form, and frequently within the same institution. [This is partially why]
The use of only numbers to represent the date leads to further confusion when the date is read by health workers who come to a country from a variety of different background. Or when the software is designed to work across international boundaries.
Therefore, the NHS CUI guidelines mandate that the month never is displayed as a two-digit number.
Writing the month as text, either with an abbreviation or in full text both reduce the ambiguity when reading a date.
In the short date format, the date is abbreviated.
Only the first letter is capitalized. (Again, these guidelines are suggested in English. Other languages I realize do not capitalize the months.)
How many characters the date should be abbreviated to, is another rule…
Rule 2: write the year with four numbers, not two
It is important to write the full year for two reasons.
First, it removes all ambiguity which of the two numbers associated with the written month is the day and which is the year. If only two digits are used, the date 10-May-12 could be misinterpreted as :
The twelfth of May 1910
The tenth of May 1912
The twelfth of May 2010
The tenth of May 2012
Instead, there is no potential for confusion when written as
10-May-2012.
Second, we have now entered the decade where patient dates may either be the 1900s or 2000s. This will only increasingly cause confusion over time. The display of the year with four digits will mitigate this confusion.
Rule 3: Include the day of the week whenever appropriate
The day of the week is an important construct when thinking about time. For instance, the day of the week is helpful when discussing events in patient handover, or related to the patient's care sequence.
The day of the week also provides a 'second check' to ensure the correct date has been entered.
For instance, staff may have intended to book the patient into the clinic for "next Thursday." Accidentally the wrong day is selected in the date picker. (Perhaps the staff clicked on a wrong date with the mouse. Or perhaps they are used to the week starting on Monday, rather than Sunday.) The display of the day of the week associated with the chosen date-month-year provides an additional check and balance.
There are definite exceptions when it does not make sense to display the day of the week. For instance, with the patient's date of birth or death.
CUI recommends in the short date format that the three-digit day of week abbreviation is used. The first letter is capitalized. There is a single space to the date-block.
Day abbreviations: Mon, Tue, Wed, Thu, Fri, Sat, Sun
Example: Mon 02-Sep-2019
Rule 4: Use a hyphen as the separator
There are many options for separators to choose from
12 May 1988 space
12.May.1988 . period
12/May/1988 / forward slash or stroke
12-May-1988 - hyphen (the shortest)
12–May–1988 – en dash (the middle)
12—May—1988 — em dash (the longest)
Why use the hyphen?
(Discussed in worst, to best option)
The forward-slash has several problems. The elements of the date are too close together. The forward-slash makes it visually difficult to separate the date elements for those with reading or vision impairments. There is also a small chance that the slash may be misinterpreted as a 1.
The em dash is simply too long. 12—May—2011. In practice, an em dash is not used to separate numbers. (See further, Hyphens and Dashes—The Long and the Short of It from the Government of Canada website)
The single period does look kind of nice. However, it doesn't adequately separate the date elements as much as the other options. More separation = easier to read. The single period also gets confusing when you start incorporating this short date in the content of letters, with commas and periods. It also becomes confusing when looking at other languages (like German) that do use a period and space to separate their date elements.
We now get to the single space. At first, I liked this format. Less is more, isn't it? However, CUI presents some compelling examples of why this date format lacks distinctiveness. The components of the date can become confused with other nearby numbers on the screen. The example below clearly shows this problem.
Because of the potential to lead to confusion from a lack of distinctiveness, a single space is not advised.
e.g. from NHS CUI
The en dash is traditionally used to replace the word "to" in joining entities. Such as chapters 4–10, or Chicago–Vancouver. 12–May–2011. I don't mind it, but it has slightly too much space between the day, month, year element.
We are left now with the single hyphen: The use of the hyphen ensures the date is seen as a single block of content. The hyphen has a long history of being used to join/separate entities - such as the ISBN number, ISO 8601.
Rule 5: do not separate the elements
When displayed in a paragraph, if a line break is required, it should not divide the day, month, and year elements.
The exception to this is if the elements are being displayed together in a block (such as the day-month on the first row, and the year directly underneath).
This rule is not in CUI document, but makes sense to me from a safety perspective to ensure there is not missing data. I got the idea from Army Regulation 25-50, which states to "avoid separating any of the three date elements."
Rule 6: Display the date as two digits
Initially, I didn't fully understand this rule, but it now makes sense to me.
Standardizing the date to display as 01-May-1998 rather than 1-May-1988 has a few benefits.
First, when displaying in a column, using mono-space fonts, the day-month-year block will line up regardless of how it is aligned.
Second, displaying the leading zero in digits under 10 ensures that all information has been communicated to the reader. There is a small, potential that a date may be cut-off. For instance, another user interface element may be sitting above it obscuring the date. In this case, the readout to the user may be 1-May-2003, when in fact the preceding "2" is cut-off on screen and should have read 21-May-2003.
There is also a small chance people could 'write in' an extra number.
There is also a small chance of a misread, especially if forward slashes are being used to separate the elements. For instance, 1/May/2003 could accidentally be read in quick passing as the 11th of May 2003.
On old machines, no longer an issue, two numbers needed to be filled in order to fill the date space in the user interface. Though, this is no longer an issue.
The International Civil Aviation Organization (ICAO) passport standards also specify two digits are used.
I suspect there may be other reasons for this standard, but my opinion on this has been changed, and I now support two digits at all times.
Rule 6: Sequence day-month-year
The sequence of placing the year last follows English convention in speech (both American and British).
If the year goes at the end, we are left with the options of
01-May-1955
May-01-1955
British English tradition and most of the English speaking world follow Day-Month-Year as their standard. America exclusively uses Month-Day-Year. If we were trying to derive a principle from existing practice, we'd use Day-Month-Year.
The Day-Month-Year format is also used by the International Civil Aviation Organization (ICAO) on the human-readable section of passports.
I think there may be another reason to use Day-Month-Year. This has to do with the physical separation of entities. I have no evidence for this, but separating the day and year with a three-letter month separates the last digit of the day and the first digit of the year further apart. In my opinion, this may reduce the chance that May-01-1955 in quick passing could accidentally be read as the 11th of May 1955.
Rule 7: Abbreviate the month to three characters
This rule is at the end, because I have the last evidence for it.
In English, we can easily abbreviate the month to three letters. Therefore, specifying that the date is abbreviated to three characters makes sense.
In English:
Use sentence case (Capitalize only the first letter)
Jan, Feb, Mar, Apr, Jun, Jul, Aug, Sep, Oct, Nov, Dec
However, if one tries to adopt these principles and apply them to other languages, they may require another letter (or two) for abbreviation. Or potentially even less letters.
For instance, the ICAO on its human-readable section of the passport abbreviations states that countries can abbreviate the month to four or fewer letters. They present examples from English, French, and Spanish. In English, the abbreviations are all three letters. In French and Spanish, it varies between three and four.
When you review the Yale University Library abbreviations of the names of months by language, you note that some languages only use two letters. They also show some abbreviations to five letters (even though ICAO restricts the limit to four).
The take-away is that in English let us always abbreviate to three letters with a capital first letter. However, as other languages may use between 2 and 4 letters for their abbreviation the way this is designed in the EHR cannot be to rigid and likely needs to accommodate a longer text string.
Rule 8: Missing information & non-dates
At this time, I don't feel too strongly about how to show missing information and non-dates.
This is obviously complicated, because the reason data is missing may not be known.
In general, I like the idea of using words to specify why the data is missing, such as:
When no date is recorded display: not recorded
When the date is recorded as not known, display: not known
When the date is active through today display: present.
On the other hand, the ICAO suggests the use of an "X" wherever data may be missing. In that case a date of birth that only contains the year would be: XX-XXX-1975.
Handling of approximate dates and estimated dates is another article.
The handling of approximate dates (e.g. born in 1970s) is outside the scope of this document....(also mostly because I'm not sure this can be represented in most EHR databases at this time).
Discussion thread on date display
https://ux.stackexchange.com/questions/16095/how-to-display-date-and-time
Exceptions
At times, it does not make sense to follow this convention.
For instance, when displaying lab data from the prior day, it is sufficient to note the day and month in the overview screen. The year is not required in that case.
A case-by-case list of exceptions will be added here over time.
From the series Building the EHR
Section: Conventions / Date Display
