Hi,
In one of our implementations, we have a requirement to capture the time of birth for a patient.
Would it make sense to change the column type of Person.birthdate to datetime? Its date right now.
-Shruthi
Hi,
Unfortunately this requirement is a little urgent. We could implement this as a migration in the bahmni omod and merge this back to openmrs-core at a later point.
I just wanted to make sure the approach is right for now. 
-Shruthi
We’d need to define when time should be ignored, since 99.9% of birthdates will not include time. If, for example, we define midnight as “null”, then we cannot record time of birth for someone born at midnight. Since the vast majority of use cases for date of birth is a date, it might be more pragmatic to store “time of birth” as a separate attribute rather than assuming that date of birth will be precise to the minute.
Adding a person attribute for birthtime as a optional (nullable) time of day would allow for capturing time of birth without changing the definition of birthdate.
1 Like
I agree that given limitations of SQL datatypes (and java.util.Date) it’s better to separate these into birthdate and birthtime fields. (FHIR defines Patient.birthDate as a dateTime datatype, but their dateTime is allowed to include partial dates.)
Any reason we would be opposed to adding person.birthtime in the next OpenMRS platform release? (@Burke, I can’t tell from your email if you’re literally suggesting a person_attribute, or just an attribute of a Person. I would think that if the Bahmni team wants to add this feature to openmrs-core, we’d be happy to have it.)
The registration page is generated based on the person attribute types defined. If we have to add time of birth as a person_attribute then we’ll need to treat this specially.
It would be preferable to add this as an attribute on Person. Its also quite standard.
And yup, we can make that change.
-Shruthi
I was suggesting a person_attribute could be used to meet immediate needs. I’d agree that this would be fine to put into core so, in the future, a custom person_attribute would not be necessary.
As an aside, this reminds of our prior idea of replacing patient.birthdate_estimated with patient.birthdate_partial, where the “partial” flag could identify which parts of the birthdate were known. I thought we had a GSoC or someone try working on this but it never saw the light of day. Probably way too complicated to try to introduce it now compared to simply adding an optional patient.birthtime. 
Great! Can we make this change in 1.10 and it can be merged upstream?
-Shruthi
I recall too a GSoC project where someone worked on estimated dates, i think @jeremy mentored it or was involved in it, so he might give an update on how that went.
In practice, we develop against master and backport to prior version branches and try to avoid developing directly in version branches. You might have better luck making a pull request against master and then requesting it be backported to 1.10.x.
1 Like
Also, technically this is a new feature, and not a bugfix, so it wouldn’t be backported to the release branches.
However, given that this will be very small, and should not affect anything else (i.e. it’s a single, optional field, which doesn’t affect validation), I don’t see a problem backporting it.
I would expect that this must be added to the webservices.rest module in a backwards-compatible way, which I think is supported by this:
… there’s no need to add this to the 1.x UI in openmrs-core, but that once the field is added you should create a ticket for someday letting people access it in the reference application.
Thanks Burke, Darius!
We are picking this up right away.
-Shruthi