sunsetsystems wrote on Wednesday, January 11, 2012:
Headers in the Vitals form show the data entry dates for historical data. This is not too good since the data entry may be done after the fact. I have created a fix to show the encounter dates instead (and similarly in the growth chart). The data entry dates are preserved as tooltips that you can see my mousing over the header dates.
Github branch is here for any comments:
bradymiller wrote on Wednesday, January 11, 2012:
Hi,
The issue here is twofold:
1. Need the actual timestamp the vitals were taken.
2. Very common to take multiple vitals at one encounter (ie. if BP is too high, then may recheck after the appt), so again need to know the exact time of each vital.
(the time it was entered into the computer is not helpful; propose that the date field in the form_vitals table should represent the exact time the vitals were recorded from the patient)
Wouldn’t it be better to simply allow modification of the date/time field when entering/editing the vitals to allow backdating(Pimm has requested this feature several times).
-brady
sunsetsystems wrote on Wednesday, January 11, 2012:
OK, I’ve not had any client expressing concern with either of those issues (perhaps they just modify a reading thought to be incorrect?), but I’ll see what I can do. Thanks!
bradymiller wrote on Thursday, January 12, 2012:
Hi Rod,
Generally best to think of vitals as labs; very important to know the exact time they were taken from the patient. Lots of situations where want to recheck them on same day and need to then know the ordering/timestamp they were checked (rechecking after ambulating, after standing, after some oral/iv hydration, after a breathing treatment, at end of appointment if wishing for an elevated/depressed bp to miraculously get better, etc.). Others can weigh in here, but I think not timestamping exact time when vitals are taken will limit the scalability of the software.
-brady
bradymiller wrote on Thursday, January 12, 2012:
Also,
I just realized that I think in the past I changed the form_vitals to instead use the date within the form_vitals table rather than the form_encounter table for the above reasons. So, I think your code is basically reverting that feature 
-brady
sunsetsystems wrote on Thursday, January 12, 2012:
It’s not a feature if the timestamp has no meaning.
Now after making it an input field, there’s still a problem with data entered prior to the fix. I think what I’ll do is have the display code check to see if the date portion of the timestamp is the same as the encounter date. If it is, display the timestamp. If not, display the encounter date with no time.
jcahn2 wrote on Thursday, January 12, 2012:
Yes, Rod. That change would make it a feature. Agree with Brady, the timestamp is an important piece of the vital signs data.
Jack
sunsetsystems wrote on Thursday, January 12, 2012:
No disagreement here at all, Jack. Getting this kind of feedback makes me glad that I started the thread.
sunsetsystems wrote on Friday, January 13, 2012:
I modified the commit and re-published the branch on github. This now includes a date/time input field in the form. Note that you can mouse-over the past dates to see their observation times. Testing appreciated!
bradymiller wrote on Friday, January 13, 2012:
Hi Rod,
Being able to back-date the vitals is very nice. Posted some issues on github; quick summary of them is:
1. There will be inconsistencies in the dates if you use the encounter date (when the timestamp does not fall on the encounter date) in the patient summary widget and on the graphing. The vitals have been auto-timestamped in this fashion for the last 1.5 years on OpenEMR with no real complaints; just wonder if the encounter check/fix is needed(and if so, then shouldn’t it be consistent throughout the codebase?).
2. Important to show the entire timestamp on the sheet when providers trend vitals; having to drag over a date to see the time may drive some providers to the brink whom are trending numerous vitals on the same date.
-brady
sunsetsystems wrote on Friday, January 13, 2012:
Re vitals timestamp vs. encounter date - do you think it can ever be correct to have the timestamp not fall on the encounter date? I thought not, but if there are such situations then we could always show the timestamp as you suggest, and construct a one-time SQL script to fix it for the practices that might need it fixed (like my clients!). I can go either way.
Yes I’ll change the headers to include the time.
jcahn2 wrote on Friday, January 13, 2012:
I am trying to picture a situation where vital signs are entered on a date other the timestamp date. We have seen situations where the weight was incorrectly recorded and not discovered until the following visit say 3 months later - could be off by 50 or 100 pounds when we had a (pre-digital) balance with sliding weights. There are also typos (omitted decimal points) sometimes with temperatures etc.
What would it take to have data screening at the time of entry? I’m thinking a comparison to an appropriate range by age and another that looks for a percent variation from the last entry and gives the clinician a warning message. I have seen the former in other software. “986 degrees? Your patient is about to burst into flames!”
Jack
sunsetsystems wrote on Friday, January 13, 2012:
Yeah I think it’s usually about fixing errors. In some practices the vitals may be recorded on paper and then entered into the EMR later, or they forget to put it in and it’s not noticed until the next visit.
Data validation is always good. Just requires someone willing to do or sponsor the work.
bradymiller wrote on Friday, January 13, 2012:
Hi,
For date issue, if it’s an urgent care clinic and the patient comes in a little before midnight. I know that’s really pushing things thought. Why not just make it controlled be a global entitled “Vitals on encounter date only” or something like that, but still need to deal with the inconsistencies in the patient summary screen vital widget and the vital graphing widget (all in all, would be another 20 or so lines of code). Then everybody’s needs would be met
-brady
bradymiller wrote on Friday, January 13, 2012:
Hi,
To further clarify what I stated above:
1. It is ok to force encounter date if the vital date does not match, but just need to make this behavior consistent in the codebase (ie. the patient summary widget and graphing module should then do this also)
2. An potential additional feature would be to give users the option of forcing the vital checks on the encounter dates (ie. this could be done later if requested/sponsored)
-brady
bradymiller wrote on Monday, January 16, 2012:
Hi,
Also realized that the CDR engine uses the date from the form_vitals table. Integrating the form_encounter fix into that will likely be rather tough. Perhaps avoiding the form_encounter fix and instead using a sql_query fix to adjust the dates for clinics, as needed, may make more sense (should be a really simple query that could even include as an easy to use script; like the upgrade/patch script mechanism). Guessing you will run out of sponsored time on this soon; since I kind of started this bug, I am happy to spend some time on it once the direction is agreed upon.
-brady
-brady
sunsetsystems wrote on Wednesday, February 01, 2012:
Back to this. I’ve put the times (omitting seconds) into the headers and removed the form_encounter date fix - will plan to use a sql query as a one-time fix for the client. The github branch has been rebased and replaced in case there are any further comments before I push to SF.
bradymiller wrote on Friday, February 03, 2012:
looks good. Will plan to add this to the next 4.1.0 patch also.
-brady
sunsetsystems wrote on Friday, February 03, 2012:
Committed. In case anyone else is interested, here’s my script to change vitals dates that do not match encounter dates:
UPDATE form_vitals AS fv, forms AS f, form_encounter AS fe
SET fv.date = fe.date WHERE
f.formdir = 'vitals' AND f.form_id = fv.id AND f.deleted = 0 AND
fe.pid = f.pid AND fe.encounter = f.encounter AND
fe.date IS NOT NULL AND fe.date NOT LIKE '0%' AND
SUBSTRING(fv.date, 1, 10) != SUBSTRING(fe.date, 1, 10);