yehster wrote on Friday, July 19, 2013:
What I’m seeing is it looks like sometimes the search happens, but then it gets done a second time with empty values. Is that what it looks like to any of you? Do any of you see a momentary flash where the patient the search was attempted on is displayed in Allscripts?
xiaoanri wrote on Friday, July 19, 2013:
yes, kevin, it seems it attempted the search and found the patient very briefly (patient name showing very briefly on top of the screen, then disappears), then it shows the final result as no patient is found.
yehster wrote on Friday, July 19, 2013:
Here is an updated version.
There is a quirk with the javascript on Allscripts end that I haven’t quite been able to figure out yet. I have a workaround, but it means there is one extra step before the search can happen. You have to click/dismiss a alert box before the search will take place. However I think this minor inconvenience out weighs the need to copy/paste the patient’s name.
I’m not sure if I’ll be able to come up with a proper solution, I spent a lot of time even just characterizing it. However, patient search should be more reliable even if you have to do an extra click.
mdsupport wrote on Saturday, July 20, 2013:
We had same issue as hui zhu. With the attached version, a box appears as Pause and then an error message :
• Please enter at least 2 valid characters for Last Name, First Name or Patient ID or enter a Date of Birth.
Any possibility that Firefox settings cause this problem?
Is timing between filling the value and starting the search an issue?
yehster wrote on Saturday, July 20, 2013:
Unfortunate that you still get the error message even after I added the “pause” box. On my system that seemed to make it work consistently.
I experimented with multiple approaches to timing of when to start filling in the search value, including attaching a javascript timeout of 2 full seconds, and that didn’t work. I also tried doing it on “window.loaded” instead of on “document.ready” which ought to be “later” in the event cycle. The forced “pause” by triggering window.alert seemed to work for me.
I also tried not having the script click the search button at all and doing that part manually, but sometimes Allscripts still “cleared the search fields.” I saw that the fields had the data in them, but if I clicked on them the data got cleared out.
There is some sort of javascript validation code that gets triggered when manually entering the fields which doesn’t happen consistently when greasemonkey programmatic populates the boxes. I suspect that the javascript that needs to fire is part of the .aspx/.NET framework that the Allscripts app is built upon. I was hoping to be able to find a specific javascript function to call directly, but there is a bunch of “minified” javascript on the Allscripts pages that’s very hard to comprehend/trace.
Given that the fields “blanked” out when I clicked in them, I used jquery to fire click and focus events from the script before populating the search field, but that still didn’t seem to work.
I am not aware of a Firefox setting that would cause the problem. If you can think of something specific, it might be worth experimenting. What’s something that you might have changed?
mdsupport wrote on Saturday, July 20, 2013:
Greasemonkey actions can be inconsistent when the target page has its own events. Since the ‘load from emr’ button does not have issue, I wonder if a button added next to search would be more consistent. Your emr button will essentially press your allscript search button. Your allscript search button will fill search info and then call allscripts search button. That will make sure allscript’s page is aware of events happening on that page.