Stream: implementers
Topic: Patient birthdate/deceased
Mirjam Baltus (Oct 07 2016 at 12:33):
Does anyone know why the datatype for Patient.birthDate is 'just' a date, whereas Patient.deceased may be a dateTime? This question just came up during my training course.
Alexander Henket (Oct 07 2016 at 12:40):
I should know as I'm from PA, but I don't know for sure. Here's my best answer:
The full DOB is relevant in the perinatal phase and is then recorded as part of your perinatal observations/background. Immediate thereafter the time is irrelevant and the only thing you need in the rest of your life is the date. This is a defining property of "you".
Deceased time is probably captured during a comparable process to the perinatal phase, but the difference here is that there is no "after period" or "rest of your life". So I guess that once entered it remains that way.
That being said, it would not have harmed anyone if birthDate would have been a dateTime since date is a valid subtype of dateTime.
Mirjam Baltus (Oct 07 2016 at 12:52):
Thanks Alexander, both for the answer, as for a nice demonstration of how this forum works.
Jenni Syed (Oct 07 2016 at 14:46):
Note: birth date *use* to be a dateTime. But it was moved to just the date since you don't need (nor do most people know) the time. There is now an extension for those edge cases that do need the birth time (eg: NICU for first few days)
Jenni Syed (Oct 07 2016 at 14:47):
I'm not sure if they talked about the deceased at the same time or not, but I would have assumed the same use cases apply and maybe it was just missed?
Jenni Syed (Oct 07 2016 at 14:47):
Should be a gforge we can find...
Jenni Syed (Oct 07 2016 at 14:50):
Tada: GF#3731
John Moehrke (Oct 07 2016 at 14:50):
For those that want to record the birth time there is an extension. http://hl7-fhir.github.io/extension-patient-birthtime.html
Bryn Rhodes (Oct 07 2016 at 17:33):
We use that extension in QI-Core, and a question that has come up is why is it modeled as a dateTime? Shouldn't it be a time if all we are capturing is the time?
Jenni Syed (Oct 07 2016 at 17:37):
You need the time zone, I don't know if there is such a thing as a time without a zone. And that would require you to put together the birth date and that extension to calculate age
Jenni Syed (Oct 07 2016 at 17:37):
time zones only really make sense in context of a full date and time
Bryn Rhodes (Oct 07 2016 at 17:44):
I see, yes, that makes sense, because a date can't have a timezone and neither can a time, so to capture timezone, it has to be dateTime.
Bryn Rhodes (Oct 07 2016 at 17:45):
I actually think times should have a timezone, but that's a different issue.
Brian Postlethwaite (Oct 09 2016 at 23:28):
Yes, the timezone issue on times is the issue. Dates can not have a timezone (in the FHIR context) and as such don't confuse things.
The reason this is so important with the birth date is that it is used for identification purposes (which death date isnt) so it is critical that timezones don't interfere with the value, no matter where they were recorded.
Paul Knapp (Oct 19 2016 at 07:48):
There was lively debate around time on birthdate. The only reason there is a birthtime extension is because there is no time on birthdate.
It would have been completely workable to have used a datetime and then have the convention that the birthdate is the date independant of the timezone - just like we actual do today.
Brian Postlethwaite (Oct 20 2016 at 01:45):
Just following up on this topic of why is the patient birth date a date only field, I've written a post on what lead to the current design.
https://brianpos.wordpress.com/2016/10/19/patient-birth-date-no-time/
Last updated: Apr 12 2022 at 19:14 UTC
