Re: [Gnumed-devel] estimated dob

[Busser, Jim]

On 2012-01-22, at 7:13 AM, Vaibhav Banait wrote:

> Though we may not save age as a field, allowing input as age and then 
> calculating date estimated on first jan will save lot of efforts on 
> receptionist level, where many people are not aware of dob. The age field if 
> attached to the dob by formula current year - age in years may simply should 
> be able to give approximate year. 

It would be possible to do it as follows:

- provide, in the patient creation widget and also the demographic identity 
edit area:

        in addition to Date of birth which already exists

        and in addition to Time (which in the creation widget already exists)
                (and which forms part of the fully specified date of birth in 
the identity edit area)

        the field "or Age"

- while a DOB is null, an entry into this field would be processed

- once the DOB is non-null, an entry into the "or Age" field would be ignored

An appropriate entry into

        "or Age"

could result in a DOB which has year = (January 1 of current year) minus 
interval (age) and which Vaibhav may find sufficient

*** but ***  if the praxis would include any infants then I can easily expect 
the scenario where a parent could bring a child who is known to be

        about 1 month old

or      about 3 months old

or      about 6 months old

and so if it is presently January of 2012 when this child has a record created 
in GNUmed I should think it advisable that age needs to accept some value more 
than just integers. I think it should rather be an interval which 
Python/Postgres can handle.

This is because in the case of a child who is approximately six months of age 
(born approximately July of 2011) inputting

        1

would result in a pseudo-date of birth of January 1 2011 and when this child 
then returns 4 months after the visit of January 2012 (say, in May of 2012) the 
amount of growth we would expect between age 6 months and age 10 months is very 
different from what will be incorrectly suggested by GNUmed if a child had 
truly gone from 12 months of age to 16 which is what GNUmed would make it 
appear.

Therefore, if an infant would be created with an estimated age of

        3 weeks

then GNUmed should assign a date of birth that is 21 days ago and set the 
"estimated" bit to "true" and if an older infant would be created with an 
estimated age of

        6 months

then GNUmed should assign a date of birth that is 6 months ago and set the 
"estimated" bit to "true".

If we would keep this consistent, then when creating a person on October 21 
with an estimated age of 60 years then GNUmed should assign a date of birth of 
October 21, 1952 and set the "estimated" bit to "true".

Now maybe some people (Liz?) will say it is important for "fake" dates of birth 
to be recognizably different from "real" dates of birth and that a choice of 
January 1 "kind of" achieves this but I am not sure that I agree because:

1) some people truly have January 1 as their month and date of birth

2) the praxis software should want to have flagged, anyway, that this was only 
a "fake" (estimated) dob

3) even when it is known in a praxis that a DOB is uncertain, there exists no 
routine way
        to communicate in a letter or report that the enclosed DOB is "fake"
        nor the degree of (in)accuracy in the estimate

4) we want to be careful not to mix clinical and administrative issues. When 
some administration contacts you and says

        "you did not properly identify this patient in your claim for 
reimbursement
                because your praxis says their DOB is January 1 however our
                system records them as having a DOB of January 3"

it is an advantage that GNUmed is not "required" to use January 1 either 
strictly (or even by default) in situations of a date being inaccurately known. 
The bit "estimated = true" can remain set and we may be happy to change this 
date to reduce annoyance complaints when it makes no difference clinically. I 
only do not know how we suggest to handle if different bureaucracies each 
insist that a single person has two different dates of birth. I suppose the 
praxis administrators should have to put the bureaucracies in touch with each 
other while providing any available support in trying to resolve a single date 
in common.

-- Jim