gnumed-devel
[Top][All Lists]

## Re: [Gnumed-devel] estimated dob

 From: Busser, Jim Subject: Re: [Gnumed-devel] estimated dob Date: Sun, 22 Jan 2012 21:44:10 +0000

```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

```

reply via email to