Notifications
Clear all
Topic starter
I know, the very title of this post is an explanation of exactly how OBSPREV is supposed to work but hear me out!
I have a form in which OBSPREV is a button to pull in the data from the previous appointment. The problem is my provider is complaining that sometimes it pulls in data that is too old. Sometimes it will pull in data from a couple visits ago and completely ignore the last appointment. I figured it was something I did incorrectly but all this button is, is a SETVALUES type and in the multi-line text edit box the value is set to {OBSPREV("A&P#2")} and the existing values set to "do not overwrite". Anyone have any thoughts?
Posted : October 21, 2016 5:50 am
The first thing I would check on would be to see if the documents were signed. That would keep OBSPREV() from pulling those values. We ran into an issue where patients would go to our walk-in clinics and since the Family Practice docs didn't sign their documents timely, the walk-in clinic couldn't pull obsterms from those visits.
The next thing would be to look at how the obs data is stored in the flowsheet or OBS table to see if something happened with the datetimes.
Posted : October 21, 2016 6:03 am
obsprev() pulls in the last signed data. You want to overwrite the existing data. I know it is just a typo, but need "" around obs term.
Posted : October 22, 2016 2:20 am
Some hints about how obsnow, obsprev, and obsany functions work, plus the often misunderstood obsnow (default previous) connection setting.
1) OBSANY - returns either the current value in the update or the last signed value from a previous update. The key here is the signed part, meaning if you have a chart with one or more unsigned documents, it may be possible to not bring forward the most 'recent' value. This is by design as unsigned data is not permanent and can be changed in the associated update until it is signed. If data is not a permanent part of the chart, in most circumstances it should not be allowed to be brought forward into a later update. There are exceptions, of course, but I would suggest running it by your legal team before employing them, especially with forensic database auditing being added to malpractice investigations.
2) OBSPREV - returns the last signed obsterm value, similar to obsany - same concerns apply.
3) OBSNOW - returns the current value assigned to the obsterm in an unsigned status.
4) OBSNOW (default previous) - behaves like OBSANY with one critical difference - if the OBSNOW value is exactly the same as OBSPREV value, the obsterm is NOT updated meaning the OBSPREV value remains the last data of record. This connection is popular since it permits review of the previous data without user interaction, however it makes documenting collected but unchanged data a bit more involved. There are two common methods of forcing the value to update using the same value via MEL code:
- Use an OBSNOW connection and an action button to push the obsprevious value to it. This is the simplest approach but does not offer easy review of the previous value. Adding a data display or additional code that permits review prior to insertion may be desired.
- When storing the new value in the connection, also send a 'OBSMODIFIERNOW' command along with it. Care must be taken to only send this command once and it is a tedious manual process to remove it, so care must be taken to activate it. Due to the challenges associated with this approach, it is less desirable, but it is a viable option in some instances.
Hope this helps.
Posted : October 24, 2016 1:09 am
