dob in creation widget phrasewheel offers current and recent dates
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
GNUmed |
Fix Released
|
Wishlist
|
ncq |
Bug Description
Presently when creating a new patient, I seem forced to input in a format which I do not like (e.g. 1/13/60 ... which I do not like because it is ambiguous) the phrasewheel will offer 1900.01.13 however if I try to type 1900.01.13 my entry will be rejected or will trigger an error... auto-generated report coming via gnumed-bugs.
If I type only a few characters, the phrasewheel seems to offer as choices
9/2008
8/2008
today etc
days from today
Also when I did select 9/2008 to see what would happen, the actual value that was input for the patient's dob must have been the current system time (to the very second) because when I completed creation of the patient I noted in the EMR that the patient was at that moment 37 seconds old.
The phrasewheel-offered dates, when based on minimal input, by being assumed to be so recent are not really suitable values for a dob so I wonder if what is offered can better require at least 3 sets of numeric characters or 6 characters before reacting to the user's input.
Changed in gnumed: | |
importance: | Undecided → Wishlist |
status: | New → Confirmed |
Changed in gnumed: | |
status: | Fix Committed → Fix Released |
I had a similar problem until I got used to the "european" ;-) (**here comes
flames**) way to make Januaray 29, 1981 look like "1981-01-28"
(year-month-day) and now it works great :)
Just thouhgt I´d mention how I am using it in production :)
Rogerio
2008/9/16 Jim Busser <email address hidden>
> Public bug reported: /bugs.launchpad .net/bugs/ 270755
>
> Presently when creating a new patient, I seem forced to input in a
> format which I do not like (e.g. 1/13/60 ... which I do not like because
> it is ambiguous) the phrasewheel will offer 1900.01.13 however if I try
> to type 1900.01.13 my entry will be rejected or will trigger an error...
> auto-generated report coming via gnumed-bugs.
>
> If I type only a few characters, the phrasewheel seems to offer as choices
> 9/2008
> 8/2008
> today etc
> days from today
>
> Also when I did select 9/2008 to see what would happen, the actual value
> that was input for the patient's dob must have been the current system
> time (to the very second) because when I completed creation of the
> patient I noted in the EMR that the patient was at that moment 37
> seconds old.
>
> The phrasewheel-offered dates, when based on minimal input, by being
> assumed to be so recent are not really suitable values for a dob so I
> wonder if what is offered can better require at least 3 sets of numeric
> characters or 6 characters before reacting to the user's input.
>
> ** Affects: gnumed
> Importance: Undecided
> Status: New
>
> --
> dob in creation widget phrasewheel offers current and recent dates
> https:/
> You received this bug notification because you are a member of GNUmed
> development, which is subscribed to GNUmed.
>
> Status in GNUmed - electronic medical record: New
>
> Bug description:
> Presently when creating a new patient, I seem forced to input in a format
> which I do not like (e.g. 1/13/60 ... which I do not like because it is
> ambiguous) the phrasewheel will offer 1900.01.13 however if I try to type
> 1900.01.13 my entry will be rejected or will trigger an error...
> auto-generated report coming via gnumed-bugs.
>
> If I type only a few characters, the phrasewheel seems to offer as choices
> 9/2008
> 8/2008
> today etc
> days from today
>
> Also when I did select 9/2008 to see what would happen, the actual value
> that was input for the patient's dob must have been the current system time
> (to the very second) because when I completed creation of the patient I
> noted in the EMR that the patient was at that moment 37 seconds old.
>
> The phrasewheel-offered dates, when based on minimal input, by being
> assumed to be so recent are not really suitable values for a dob so I wonder
> if what is offered can better require at least 3 sets of numeric characters
> or 6 characters before reacting to the user's input.
>