Notifications
Clear all
Topic starter
I know I posted previously about creating a Results Letter encounter that would have options and nicely format output. Well, I built a prototype.
The problem is with the call to get the last signed OBS values.
1. create/open the encounter, and it sees last signed LDL on 2/1/18 of 50
2. Save/hold encounter
3. new value for LDL on 5/10/18 posts for 60
4. reopen the form, and the display is still showing the 50 from February
The data display is coded as "MEL expression" and the code is:
{LAST_SIGNED_OBS_DATE('LDL')}
Is this a bug in VFE - not executing the MEL upon form open?
p.s. Happy to share, for anyone who wants a look. I tried to post the .dlg here, and was getting an error.
Posted : May 10, 2018 3:29 am
This is not a bug in VFE, but is how Centricity handles new data coming in after a note is started. Here is what GE has told us in the past, using your example scenario.
---1. create/open the encounter, and it sees last signed LDL on 2/1/18 of 50
Once created, the document is only able to look backwards form the time it was made. any changes made later will not be visible to it.
---2. Save/hold encounter
---3. new value for LDL on 5/10/18 posts for 60
Since this lab result was posted after the document was created, it will not show up in the document even after a refresh.
---4. reopen the form, and the display is still showing the 50 from February
I believe GE said this is to prevent conflicting data from being in old notes. Say a doctor is examining the patient, and has the old LDL of 50, and makes Diagnoses, prescribes meds, and gives medical advice based on that LDL. if a new lab comes in before the Dr. has signed the note, and the note displays LDL is actually super high, but the clinical note does not address it, the provider could easily be liable in court, and the documentation will make it look like he ignored the high LDL.
Hopefully this clears things up. We had providers who wanted to see new data in old notes, but after GE explained why that is not allowed, they were OK with it.
Thank you,
Daniel C
Posted : May 10, 2018 5:19 am
Joe,
We have the same issue you are having. As Daniel points out, the last signed OBS function returns results relative to the date/timestamp of the document you are charting under vs the current date/time. For example, if the provider opens up an encounter and starts a document for the patient visit on May 10 at 8:00am; and then lab results become available and are signed off at 8:30am on the same day, the LAST_SIGNED_OBS_DATE will identify the most recent date/time prior to May 10, 8:00am. In other words, you are not going to get the results and date for the lab results that were signed off at 8:30am, because the document that was started at 8:00am uses the document's date/timestamp as its reference point. While this is not necessarily a bug, it does surface a functional limitation in my opinion. The current workarounds include the following:
1) either the provider doesn't start their charting for the visit until all of the supporting lab data has been signed off; while this would work, it is a ridiculous workaround that I've never seen anyone adopt in the real world 🙂
2) sign off on the note without the most recent lab data, and then once the lab results have been signed, go back to the original note and append the lab results. This is better than option 1, but most providers I work with complain about how this looks in their note (i.e. the lab values lose their context when they appear at the end of the note); they also don't want to have to remember to go back to a previous note to append the labs
3) utilize a custom program that can read the most recent lab results directly from your LIS or extract the appropriate OBS terms (read only mode of course) from your database in order to document the results in the note
Using the OBSNOW() function is often not an option for lab results because many practice's rely on a third party or internal lab to deliver the lab results via an HL7 interface.
I have found from experience that providers prefer option 3, but it typically requires some coding experience and/or an investment in a tool that will allow you to pass a query to the database server and have it return results in a delimited string (usually pipe delimited) that you can then parse out and display on the form and/or in the note.
FYI, I have brought this limitation up in the past with the Northstar team when they were defining requirements for the new orders module. It will be interesting to see if and when this gets addressed. If anyone out there would like to see enhanced functionality around capturing and presenting lab data in an office visit note; PLEASE VOTE UP THIS RESPONSE. While there are third parties that provide enhanced functionality around lab data, I feel this is something that should be native to the software. It's hard for me to believe that our workflows are that "unconventional" when I see posts like this.
Posted : May 10, 2018 7:01 am
An additional comment - I always have to sign my lab results BEFORE I append my VFE Lab Results letter. It won't work otherwise (for reasons stated above). Has always been that way as far as I know.
Posted : June 5, 2018 3:59 am
We have just ran up against this shortcoming.
Thanks for sharing this on CHUG so at least we know this is the way it is. We were trying all sorts of Mel functions and none of them were delivering what we were wanting.
We are implementing the Phreesia product into our clinic. Phreesia provides an iPad like tablet to allow patients to check in and fill out a significant part of their medical history that is then automatically entered into the patients chart.
This particular shortcoming manifested itself when we tried to implement the work flow as follows:
1) Patient arrives at check in desk
2) Patient given 2 page paperwork intake form (items that are not integrated between Phreesia and CPS and also makes more sense to gather on paper)
3) Patient returns paperwork to check in desk
4) Patient given Phreesia tablet to complete medical information input
It is after step 3 that our Intake person would open a note and begin to type in the paperwork information. This was an attempt to optimize the throughput as we could be using the time that the patient is working on the tablet to input their paperwork portion.
The intake person would then put the note on hold and wait until the patient completes their input on the Phreesia pad. Once the patient completes the Phreesia part the Intake person would reopen the Note that was on hold to "pull in" the data that was entered by the patient on the Phreesia pad.
Because the obs terms written by the Phreesia interface were AFTER the original intake note was started VFE will not bring in the most recent obs terms thus our dilemma.
We are going to have to do a workaround that is not the end of the world, but if there had been a MEL function that would allow bringing in the most recent Obs Term (i.e. ones created after the start time of the note) that would have been our 1st choice.
Mike McWilson
Regional Brain and Spine, Missouri
Posted : August 22, 2018 1:44 am
