Project Summary

• Primary mentor: Jeremy Keiper
• Backup mentor: Wyclif Luyima
• Intern: Ruwan B. Egodawatte

Abstract

Computers (and therefore databases) understand dates very well; however, dates are often treated as a specific data type that does not allow for any fuzziness. In clinical practice, we often are only able to estimate dates. For example, many patients showing up to clinic in developing countries do not know their exact date of birth. They may know the month and year, they may only know the year, or they may only know an approximate year.

We would like to be able to represent these "fuzzy" dates more flexibly than we do now. Currently, OpenMRS stores a person's birthdate along with a boolean flag to indicate whether or not the date is estimated. This project would aim to give us more flexibility in specifying exactly which parts of the date are estimated. See Ticket #430 for more details.

Some ideas for this project:

• Examine the data model for where we store dates AND an estimated flag — these would be the initial targets for the "new" more flexible date handling (e.g., person.birthdate).
• Simply converting the existing column from boolean to a small integer would probably suffice to store the additional information.
• You'd need to work through how these changes would affect the user interface wherever these dates are entered or displayed. In some cases, this additional flexibility in estimating dates may allow for improvements in the user interface.
• Patient search results could be improved so the birthdate displayed reflects what is actually known — i.e., we could display month and year if only the day is unknown.

Informative Links

• archive:Nabble discussion on Ticket #430
• Original Ticket #430 in Trac
• GSoC 2010 Project Description

Goals

Successful completion of this project would allow OpenMRS to store and render approximate dates for patient birth dates and date of death. Bonus points for patching the HL7 processor to accept approximate dates for these values. Super-duper bonus points for enabling approximate dates within other aspects of the system — e.g., observation dates.

Main areas of concern:

• UI widget
  • Should be easy and painless for the user to use as much as possible
  • Should have a text-box as the main input
• Under the hood concerns
  • storage and usage of approximate dates
  • see discussion below
• HL7 support
  • should easily follow "under the hood" concerns

Schedule

By mid of May

First I will publish the project goals to the OpenMRS community and get feedback on my plan. While getting feedback and fine tuning the plan, I will familiarize myself more with the OpenMRS (probably by contributing to the code base with small bug fixes etc.) with the help of the community and my mentor. I will examine and study the existing data model which is used to store the approximate dates and will also read on the discussions that has so far conducted among the members of the community on the matter. This will give me an understanding of what others think of what solution should look like. It is a probability that the approach will have to be slightly changed after getting feedback from the community and my mentor.

By the end of May

I will decide on the best solution to the problem (depending on the feedback I get from the community), and prepare myself for the new technologies that I might use (JQuery, XForms, InfoPath, OpenMRS tag-lib etc.). During this period I will also,

• Work on the changes to be made to the data model (Database).
• Figure out necessary changes to be made in the applicable classes of OpenMRS to fit to the data model.
• Start a discussion on how to address the backward compatibility issue.
• Research on the JQueryUI widgets (slider, calendar, etc.) that are necessary for the Date entry user interface.

By the end of June

• make changes to the data model
• modifying the OpenMRS to fit the changed data model
  • re-factoring the domain classes to support the enhanced Approximate Date representation.
  • modifying database mappings
  • testing for compatibility

By end of July

• create the prototype for the user interface using JQuery UI
• Integrate the user interface with the enhanced date representation in the back-end
• testing the user interface and back-end integration functionality

By 10th August

• Evaluate and improve code quality
• Finish final code scrub/clean-up and documenting the code
• Finish enhancing test code/develop tests

11th to 15th August

• Conduct a final code walk-through

Additional Information

Representing estimated date

• Timestamp & modifier
  • Pros: Allows researchers & people using SQL to use the timestamp as a reasonable proxy
  • Cons: We have to define the modifiers right up front – hard to change the enum later
• Two dates
  • Pros: Can represent a single date, a date range (estimation), and before/after date
  • Cons: More difficult for people accessing data underneath the API

What do we store for estimated values?

• Average (middle of minute, hour, day, month, year, decade)
• A pre-defined proxy like 1st – e.g., estimated year as 1/1/2010

Levels

• Exact timestamp
  • 0, 29-April-2010 10:04:12.123
• To second
  • 1, 29-April-2010 10:04:12.5
• To minute
  • 2, 29-April-2010 10:04:30.5
• To hour
  • 3, 29-April-2010 10:30:30.5
• To date
  • 4, 29-April-2010 12:30:30.5
• To week
  • 5, 28-April-2010 12:30:30.5 (because 28th is a Wednesday)
• To month
  • 6, 15-April-2010 12:30:30.5 (14th of February, 15th of all other months)
• To year
  • 7, 1-July-2010 12:30:30.5 (1st of July is midway through year)
• To a fuzzy year (e.g. guessing age)
  • 10, 1-July-2010 12:30:30.5
• To decade
  • 11, 1-July-2005 12:30:30.5 (midpoint of decade)

Modifiers

• Before
  • Add 32 to modifier
  • 00100000 mask
• After
  • Add 64 to modifier
  • 01000000 mask

Diagrams

Class Diagram

previous version

Flow of Events

UI Widget

The UI element will change according to the value in the slider.