How should OpenMRS show estimated birthdates?

Community
1

Hi everyone,

Some patients don’t know their exact date of birth. When that happens, staff can register the patient with an estimated age instead, and OpenMRS works out an approximate birthdate from it.

The problem

The same patient’s birthdate is shown differently in different parts of O3. For example, a patient registered on 14 October as “about 33 years old” shows the same age everywhere (33 yrs), but:

  • The patient header shows 1993
  • Patient search results show 14-Oct-1993

image
image1478×284 41.2 KB

The day and month in search results aren’t real. The system fills them in when an age is estimated — in this case with the date the patient was registered; on other records it may be 1 January. The result looks like a genuine birthday (here it even suggests the patient’s birthday is today, 14-Oct), which can mislead staff who use date of birth to confirm they have the right patient. (Tracked in O3-6099.)

Why the two screens disagree

They get the patient’s details from two different places in the system:

  • The patient header uses the FHIR API (/ws/fhir2/R4/Patient/{uuid}). For an estimated birthdate, it only gives the year, e.g. "birthDate": "1993".
  • Patient search (both the search page and the search box in the top bar) uses the REST API (/ws/rest/v1/patient?q=…). It gives the full stored date (1993-10-14) together with a separate “estimated” flag. The search screen shows the full date and doesn’t use that flag.

(Search results are converted to FHIR format in the browser for display, but the underlying data comes from REST.)

Why this isn’t a quick fix

  • OpenMRS stores every birthdate as a full date, plus a simple yes/no flag saying whether it’s estimated. It doesn’t record which part is uncertain — the day, the month, or the year.
  • Earlier design ideas, such as showing question marks for the unknown parts, never made it into the product.

So, we’d like to agree on the right behaviour with the community first.

What we’d like to hear from you

  1. How should an estimated birthdate look? For example:
    • Year only: 1993
    • With a marker: ~1993 or 1993 (est.)
    • Question marks for unknown parts: ??-??-1993 (this would need the data model change in question 3)
    • Age only: ~33 yrs
    • Something else?
  2. Should the age also show it’s estimated (e.g. ~33 yrs)?
  3. Is “estimated: yes/no” enough? Or do you need to record partial knowledge, such as knowing the month and year but not the day?
  4. Where does it need to be consistent? Patient header, search results, registration, printed labels and forms?
  5. How do you handle this today? Paper conventions, local customisations, or national requirements?
  6. Does anything clinical depend on it at your sites, such as children’s dosing or growth charts?
3 Likes
2

Thanks for writing this up, @veronica. A few things I found poking at this locally:

FHIR doesn’t always return just the year. For kids under 6 it returns the month too (2024-03), so the banner shows Mar 2024 (BirthDateTranslatorImpl). A code comment there says the cutoff was picked to line up with the WHO and CDC growth charts, so it’s worth checking with implementers whether it works for them.

On display, I’d probably show whatever precision the API returns plus a marker, e.g. 1993 (est.). The RefApp 2.x header used a ~ for this. I’d skip ??-??-1993 since it suggests we know the year, and an estimated age doesn’t tell us that either.

The age should show it’s estimated too. It’s the number the clerk actually estimated, and it isn’t stable across screens. The banner works it out from the year alone, so it ticks over on 1 January, while the backend uses the full stored date. For someone with an estimated birthdate stored as 01-Dec-1992, the banner says 34 yrs right now while the backend says 33.

Registration asks for the estimated age in years and months, but we don’t keep what was entered, so we’d need to capture the precision explicitly and store it alongside the estimated flag. That would let FHIR return what we actually know. It’s a core change though, so it’s probably better to agree on display first.

#2825 is working on getting search to match the banner. It’s probably best to keep it to that and settle the rest here.

2 Likes
3
  1. How should an estimated birthdate look?
    • I would favor 1993. Showing a year without a specific day implies an estimate. Something like (est.) would need localization support.
    • Birthdate should always show a date (even if it’s a partial/estimated date), so I would never show ~33 yrs for a birthdate. That’s an age, not a birthdate.
  2. Should the age also show it’s estimated (e.g., ~33 yrs)? Yes! Technically speaking, if we do (with item #3) eventually get to a point where we can distinguish ??-May-1993 from ??-??-1993, then the ~ would only be needed in May in the former case.
  3. Is “estimated: yes/no” enough?
    • If we’re going to make an improvement to any partial date support on the backend, I still support my proposal for a permanent fix for managing partial dates for a comprehensive support for partial dates and would suggest we take that approach, even if we tackle it one field at a time.
  4. Where does it need to be consistent? Everywhere. Consistency is a foundation of good UX.
  5. How do you handle this today? I’ll let implementers speak to this. The EMR I use in clinic supports partial dates for diagnoses and it’s great. I can put an exact date, month & year, or just year and it saves whatever I’ve entered, showing 15-May-1993, May-1993 or 1993.
  6. Does anything clinical depend on it at your sites? Birthdate precision matters more for children. It also can affect reporting, which is an argument for storing midpoints instead of defaulting to 1 for missing information (e.g., storing May-1993 as 15-May-1993 and 1993 as 15-Jun-1993 – or 2-Jul-1993 – instead of 1-May-1993 and 1-Jan-1993). Comprehensive support for partial dates would fix – or at least provide reliable & explicit solutions for – all of these problems.
2 Likes