thanks for the link from the weekly conference call,
i checked out the patient list creation by Virginia’s class, and found this at the bottom of page 2 in part 3 of the gap analysis:
“Currently, OpenEMR does not have the ability to record the time a visit occurred, so no sorting or patient lists can occur based on time.”
pretty interesting because there is the calendar which could have status = in exam room, and a datetime field in each of the forms. But maybe they took a look at the date time field of form_encounter of which the time is not being filled?
Technically they are correct. Neither forms or form_encounter tracks time and those are the only ‘mandatory’ indicators of an encounter.
May be form_encounter creation is legacy code that needs change since all other forms use timestamp. If patient has multiple encounters during the day you would end up using system ID to recreate the sequence of events.
table ‘forms’ tracks time just not from table ‘form_encounter’ which uses type datetime but is not populating the time component
from a workflow perspective, how does one record a stuctured data element of the exact time of visit unless the status from the calendar is changed or the soap note is completed in the exam room?
Yes date fields in forms and form_encounter tables are datetime but time is not stored for new patient encounter. Suggested change to store time in addition to date is probably a reasonable approximation of encounter start time.
From workflow perspective tracking times becomes complicated. System timestamps like system ids are important but only for system use. Tying real workflow indicators to system generated indicators will not work for all.
Consider couple of scenarios for starters:
Pt walks in for a flu shot. Recording this activity does not need appointment but needs only form_encounter and by extension, forms.
A practice has a transcribing service enter soap notes for physician to review and sign off.
One concept I’ve been kicking around in my head is to build a generic “events” table to store things like “patient arrived”, “Patient in Room”, “Patient Seen by User,” “Patient Left” etc… which is easier to update than through the calendar “status” and also is a complete history (e.g. advancing to the next state doesn’t destroy all knowledge of previous states as happens by using calendar status.) These sorts of timestamps can be reasonably generated by the system, but overridden manually for scenarios like #2, and wouldn’t require an appointment for scenario #1.
Developers had proposed a more generic 1 step workflow engine along lines of IFTTT to handle same issues. Unfortunately we have exhausted our limited budget so that was deferred.
Have you thought about using CDR structures to handle events? It seems to have many of the necessary trackers.
Hi Kevin,
The generic events table would be very useful for informatics analysis of clinic flow also (ie. time for patient waiting after check in, etc.).
-brady OpenEMR
I wouldn’t require that an encounter ties into a scheduled patient visit. If a timestamp is required on an encounter for MU2, then rec placing it in form_encounter (adding time to the entry should be straightforward).
My approach would be to just create an event in the generic table that corresponds to the encounter. Using a more normalize structure (rather than continuing to add columns to existing tables) will be more flexible and consistent.
My opinion is that the CDR engine is far too heavyweight for this particular purpose. However, CDR rules could be constructed based on these events. Provide specifics and convince me otherwise if you want.
Ambulatory setting only. Patient communication preferences.
Patient preferred language can be added, but not searched for. Also, email/phone, etc.
preferences are not being captured.
i guess this would be addressed by another field in the patient_data table?
It is actually a pretty short, but ambiguous set of criteria:
(14) Patient list creation. Enable a user to electronically
and dynamically select, sort, access, and create patient
lists by: date and time; and based on each one and at least
one combination of the following data:
(i) Problems;
(ii) Medications;
(iii) Medication allergies;
(iv) Demographics;
(v) Laboratory tests and values/results; and
(vi) Ambulatory setting only. Patient communication preferences.
In my mind, what seems to be ambiguous here are the time/date stuff. Here is a paragraph on page 4 of the testing script that describes it somewhat:
The requirement to create “patient lists by date and time”
is intended to represent a date range or timeframe applied
to the generation of the patient list. This may be date
range/timeframe applied to any EHR data element with a
date/time attribution identified by the vendor, which may
include, but is not limited to: past encounters,
future/scheduled encounters, date of entry or ordering of
medications. These examples of date and time are provided
as examples only and are not intended to be prescriptive.
For example, does every search attribute need to have a separate date/time range associated with it on the report search fields (medications, allergies, demographics)??? Thoughts on this?
thanks Brady for the links and the “light” reading, after 14 painful pdf pages i don’t feel any more illuminated
i don’t believe that there is a need for a separate date time range for each searchable field; i think it’s stating that there may be additional fields that have dates associated with that my be searched
plus i don’t see any language leading to what you’re hinting at
