Notifications
Clear all
Topic starter
I am trying to set a couple of specific OBS Terms when a form is opened. I'm trying to learn about Watcher Expressions and/or Functions a bit more as I suspect one of these will be the way to go. I thought that, in order to do either, you simply wrote it in the right-hand space (the 'Function View')? I have tried the following:
{!OBSNOW("Pharm Name", Pyxis)}
{!OBSNOW("Rx_Type", W)}
I have a Qvera Interface Engine that is looking for the PHARM NAME value of 'Pyxis' and the prescription needs to change from the provider's default (usually fax to pharmacy) to hand-written.
Posted : September 11, 2018 5:56 am
I have had success with this by creating a document variable to control the kick off of the watcher.
{! DOCUMENT.INITALLDONE}
{! if DOCUMENT.INITALLDONE == "" then
OBSNOW("X","Y")
OBSNOW("A", "B")
DOCUMENT.INITALLDONE = "Done"
else "" endif}
The ! tells the compiler to run that line at initialization of the form.
Watchers with ! will still be evaluated after initialization, so setting the DOCUMENT.INITALLDONE = "Done" ensures the watcher runs once.
I'd love to see others' input on watcher controls.
Posted : September 11, 2018 6:12 am
This is the way I set defaults as well. I would also like to point out that the original question seems to indicate that you are trying to save the string 'Pyxis' and not the content of a variable names Pyxis. If that is the case then you need quotes around 'Pyxis, like this -
OBSNOW("Pharm Name", "Pyxis")
Posted : September 11, 2018 6:16 am
Topic starter
Thank you both. The Pyxis part seems to be working, but the form still tries to send the medication with the user preference for the method. I thought I had read elsewhere on the forum where that was found in the OBS Term 'RXTYPE' or perhaps 'RX_TYPE' and the value 'W' was for handwritten. Do you know anything about that?
Posted : September 11, 2018 9:45 am
Chris,
a watcher expression will fire when the form first opens (in most circumstances) and also whenever the variable or Obs Term you are "watching" changes (e.g. if you interact with a control on the form that is bound to that variable or Obs Term).
As Sandy Jo alludes, you have to be careful with watcher expressions, because they can fire unnecessarily if you don't keep track of the state of your form. For your purposes, it sounds like you want to define your watcher expressions with a conditional statement, especially if you only want it to execute one time. The quick fix is to incorporate a conditional statement into your watcher expression like this:
{!if OBSNOW(“Pharm Name”) == "" then OBSNOW(“Pharm Name”, "Pyxis")}
{!if {!OBSNOW(“Rx_Type”) == "" then OBSNOW(“Rx_Type”, "W")}
The above statements will likely accomplish your objective, however you might consider a standard solution to accommodate what other "event driven" languages do a much better job of than MEL. A common thing folks like to do is initialize variable values/OBS terms on a form the first time the form loads, and retain any changes to those variable values/OBS terms (if made) after the document is put on hold. While this might be overkill for your particular case, I use a hybrid strategy similar to Sandy Jo's which I've outlined below:
First, you need to create a variable that is tied/bound to a control on the form. This allows you to retain the form's state, even if it is put on hold. Since you don't want this control to be seen on the form, I recommend setting up a visibility region that will never display, and then include the control in that region. I typically name this variable IS_INITIALIZED.
Then I include a watcher expression at the top of the function view window as follows:
{!if DOCUMENT.IS_INITIALIZED == "" then
<insert code to initialize variables and OBS terms>
DOCUMENT.IS_INITIALIZED == "Yes"
endif
}
You can then insert whatever code you want to initialize variables, initialize OBS terms, or whatever code you want to run when the form first opens. You can use a similar strategy to keep track of other "form states" you want to track. For example, you could use other variables in the hidden visibility region to keep track of how many times a form has been opened, type of user that has opened the form, name of user that has opened the form, etc. and fire watcher expressions based on a particular condition.
The above strategy is what I consider best practice for keeping track of the form's state or the status of certain events.
I hope this provides more insight into the use of watcher expressions.
Greg
Posted : September 11, 2018 9:45 am
Chris, I am wondering if you are wanting to set the values of some specific parameters for a prescription. Your mention of a Qvera interface is also an indication (to me at least) that I might not be fully understanding your question. Prescription parameters that are captured in the prescription module are not stored in OBS terms. Have you built a custom form to collect prescription parameters? If you are wanting to intercept prescription orders from the prescription module, and then change some parameters based on the value of other parameters, that is a whole different ballgame. Perhaps you can provide a description of the workflow you are trying to accomplish. Posting a screenshot of your form might be helpful too.
Greg
Posted : September 11, 2018 10:00 am
I would not think that the EMR would even permit something seemingly as simple as setting the Rx Method outside of its Prescription Module using native approaches. The prescription module itself is heavily regulated by various agencies to include state boards of medicine and pharmacy, as well as the DEA and certifying organizations. As I understand it, it is required to be a 100% closed system with no ability to inject into or extract from the workflow. While I have never heard of a method of changing the Rx Method using code, I cannot say that one does not exist, however I would carefully and thoroughly research the legality of employing such a measure to ensure it does not land your organization/providers/IT department in hot water (recommend using legal rep for validation).
Posted : September 11, 2018 7:04 pm
I agree. An understanding of the workflow would be helpful.
Posted : September 12, 2018 3:00 am
