Notifications
Clear all
Topic starter
Hi there,
We have a VFE form with a "previous observation" data field. When this form in a new chart update is put on hold, and the observation date and value is changed in a later signed chart update, the original chart update 'previous observation" presented does not pull in the new date and value.
Is there a way to view this new observation and date when going back in to edit the original update that was on hold?
I've tried adding a new data field using OBS_LIST_CHANGES - that didn't pull in anything at all. I've tried adding a flowsheet view to the form, but even that gets stuck on the previous observation when going back in to edit.
Is there a way to do view the changed observation date and value when going back into the original chart update to edit?
Any solutions?
The obsterm causing us trouble is the previous date and value for the PMP report for controlled substances. The PMP report is often documented in a new update while the provider's note is on hold. The provider would like to see the new date and value for the PMP report when he goes back into his note to complete his note and potentially do the refill.
Posted : July 25, 2017 4:11 am
Based on your description, it appears that the OBS term (PMP) is getting updated and signed by someone else through the use of a different encounter form, and once that other encounter form is signed, you are wanting the data in the original form that was put on hold to reflect the updated value and date. I initially though OBSANY() would be the function to use, but since the data is getting updated by a separate form altogether, I don't believe this will work. I have seen issues with the standard MEL functions because they often function relative to the date/time associated with the document rather than when the data was actually captured (hope that makes sense). In any event, you may need to use a function such as LIST_OBS() to pull all the OBS term occurrences for PMP and then parse out the most recent value. You could use a button or watcher expression that could fire this function. If you find that LIST_OBS() will only display the observation terms that were recorded on or prior to the document date, you may have to resort to a third party solution that can query the database directly and return the latest value and date for that OBS term.
Posted : July 25, 2017 5:29 am
This is normal behavior for the EMR. While it MIGHT seem logical to reference the most recently entered value in any update, it is important to look beyond the data and into the realm of medical decision making.
Example:
One morning, Dr. X prescribes penicillin to the patient but does not finish the note until later in the day. Inside the same EMR data base, Dr. Y sees the patient for an allergic reaction to penicillin and documents/signs the note before Dr. X signs their note.
If Dr. Y's note updated Dr. X's note, it would appear that Dr. X ignored the fact that the patient was allergic to penicillin and prescribed it any way, which is not the case at all, but the very solid case the malpractice attorney would push for the ultimate payout (little of which the patient would actually receive, of course).
Alternatively, what if Dr. Y entered erroneous information (wrong chart) and Dr. X based their ongoing medical decision making on that 'new info'? Patient harm could result from this scenario.
Lastly, what if Dr. Y was seeing the patient while Dr. X signed their note. Dr. Y. was nearing the end of their visit and signed the note, not noticing that immediately prior to signing, the patient's potassium was 'updated' to 6.8 (medical emergency) and let them walk out the door? What if they called an ambulance to take them to the ER (needs heart monitor during transport) and the patient actually had a normal potassium today?
Hopefully you get the picture. It SOUNDS ideal to share information in documents during the udpate, but the reality should be clear - it is a terrible idea.
In an effort to mitigate the risk involved to all parties, the EMR takes a snap shot of the data at the time the update was started and does not natively interact with any newly stored information outside of the update regardless of the data's date. It is a very important safeguard whose only real downside is as you describe.
Fortunately, there are workarounds, such as one mentioned in Greg's post. Hope this further's understanding as to why it is the way it is. Likewise, by understanding the above, the use of the workaround should be employed only after careful consideration of the impact and potential increase in risk liability for both the patient and the provider.
Posted : July 26, 2017 2:13 am
Lee, I absolutely love your response, and very helpful when trying to explain to physicians that only seem to care about what their progress note looks like. Thanks for posting!
Posted : July 26, 2017 4:46 am
It is not possible in standard MEL to pull in observations which were entered external to the encounter after the encounter was opened. I encountered this problem when importing scanned data after the encounter was opened.
The value can be retrieved using the following function call:
/*Enter with Obs Term, HDID string. Use _MELCurObs to retrieve most recent value of term to be placed in document value. Note, strObsTerm is for documentation only*/
{ fn Get_Obs_Term(strObsTerm, strHDID)
{
local lResult=find("_MelCurObs","ObsValue","HDID",strHDID)
if lResult<>"" then
//replace "," with ""
lResult=replacestr(lResult,",","")
return lResult
else
return ""
endif
}
}
Posted : August 1, 2017 3:40 am
Topic starter
Thank you everyone for your feedback on this.
Posted : August 1, 2017 3:54 am
Topic starter
The obsterm I would like to pull in the value for is OSAREVIEW, and this will be view only for the provider and not documented into the chart at all.
Can you show me what the function would look like, and would this be entered into a data field, using MEL function? Or, how would this be triggered to be displayed into a data field?
Posted : August 1, 2017 3:56 am
Please send me your email and I will show you approach to issue.
Posted : August 1, 2017 4:40 am
