Allscripts Integration initial version

gutiersa wrote on Thursday, October 20, 2011:

Ok done. Thanks for the instructions.

works very nicely. here are some comments.

openemr must have date format of yyyy-mm-dd. Otherwise, selecting a patient that is the active patient in openemr and that is already entered in allscripts does not work.

uploading a new patient into allscripts from openemr, works, but DOB still needs to be entered manually. DOB is required by allscripts in order to save a new patient. The DOB is not getting transferred from openemr.

Don’t try to change the date format default in openemr to mm/dd/yyyy because it still does not get transferred when uploading new patient information into allscripts (ie. DOB still has to be entered manually in allscripts). Furthermore, selecting the established active patient from openemr to become the active patient in allscripts becomes non functional.

These issues are probably related to the way mysql handles date formats. I believe my version only allows the yyyy-mm-dd format. It looks like the allscripts database uses mm/dd/yyyy as default.

sandra

yehster wrote on Thursday, October 20, 2011:

@Sandra,
The DOB issues have nothing to do with underlying mysql date formats as all the dates are being passed around as text as far as the greasemonkey script is concerned.

Yes, the code all makes the assumption that the date format for patients in OpenEMR is YYYY-MM-DD as greasemonkey script is just scraping the text off of the web pages, it doesn’t have access to formated date object.

The DOB transfer issue has to do with javascript validation code on Allscripts side.  If you notice, although the field gets populated on the AddEdit.aspx page, as soon as you click the DOB field, it gets blanked out.  Getting this part to work is about understanding the event model on Allscripts.

-Kevin

gutiersa wrote on Thursday, October 20, 2011:

OK

gutiersa wrote on Monday, October 24, 2011:

Hi:

I have been using the above and like it. it works very nicely.

FYI- I tried it with Trixie and Internet explorer, did not work.

thanks a lot

yehster wrote on Monday, October 24, 2011:

Support for Trixie does not seem to be possible out of the box.  The greasemonkey feature of allowing  includes/require of outside scripts (I use jQuery in addition to my own code) was added in 2008. 

http://ecmanaut.blogspot.com/2008/07/fun-with-greasemonkey-require.html

Trixie does not seem to have had an update since 2005! So getting it to work with IE would likely be difficult.

I don’t think it would be worth my effort to try and get this working for IE.

yehster wrote on Wednesday, October 26, 2011:

http://userscripts.org/scripts/show/116438

Updated version of the script.  DOB should load correctly on AddPatient screen.
Link from OpenEMR should work better as well.

cverk wrote on Wednesday, October 26, 2011:

Very cool.  Seems to work perfectly.  Any ideas on getting the prescription back from there into openemr. It seemed to be started at this link, but seemed to be kind of dropped for 4.1.

https://github.com/mdsupport/openemr/commit/5cfe09b97d27d953827b8f5fa77439927420c121

bradymiller wrote on Wednesday, October 26, 2011:

Hi,

Very nice to have this option. Do you have control over your userscripts.org page (just want to ensure that anybody can’t plop another malicious script on top of yours)?

Are there any changes to the HOWTO document you placed in the first post. Gonna get this on the wiki at:
http://www.open-emr.org/wiki/index.php/OpenEMR_4.1_Users_Guide
(plan to also go further in describing the two different e-prescribing methods and what it means for MU).

cverk, when you applied for MU, were you able to find the modular Allscripts thingy on the MU website?

thanks for yet another awesome contribution,
-brady

cverk wrote on Thursday, October 27, 2011:

Yes, I put both openemr and allscripts in the basket and it gave me a number which I successfully registered with.  I am not totally sure if I am going to make all the stuff to achieve attestation for 2011, but we will see. This little script thing may really help. Even if it takes into 2012, you can eventually get the same total incentives. If they don’t fix the sustained growth medicare thing at the end of the year, I don’t think I will be able to afford to even see medicare patients anyway, so it would become a mute point.

yehster wrote on Thursday, October 27, 2011:

@Brady,
No changes in the instructions.
Yes, Userscripts requires a login to update a particular script.   I put it there so we could track number of downloads. I’ve also be trying to think of additional ways to improve validation/authenticity of the script to help prevent malicious versions of the script.

@cverk,
I’m curious as to what you feel the next big barrier to achieving meaningful use is for you in particular?  Is it the portal/clinical summary issue?
I’ve been giving the import back into OpenEMR some thought, but it’s not a high priority on my task list right now.

-Kevin

bradymiller wrote on Thursday, October 27, 2011:

Hi Kevin,

As long as you control access to the script, that’s fine. It’s a nice page on Userscripts because it tracks number downloads and also provides clear instructions on greasemonkey.

Here’s the wiki documentation page:
http://www.open-emr.org/wiki/index.php/OpenEMR_ePrescribe

Placed it on the User Manual 4.1 page here in the Supplemental section and in the FAQ section:
http://www.open-emr.org/wiki/index.php/OpenEMR_4.1_Users_Guide

Please feel free to modify docs as you wish.

-brady

cverk wrote on Friday, October 28, 2011:

I think my biggest issue is to provide a clinical summary of each office visit.  It just does not work into my office flow to complete the record and print a summary before a patient leaves, or print one later and mail it to them.  Either way it is a ridiculous way to approach making an electronic record. I met with CFMC , the government contractors for helping primary care offices reach meaningful use,  today, and they said the only other way to make the requirement is to have an active updated portal, and they agreed my security concerns were valid. A patient does not have to access the portal or even have to be given a password without asking for it to count. As long as the information is there by 3 business days you can count them 100%. They seemed to think that my use of openemr with allscripts would make the e-scripts requirement, but that the need to manually enter the scripts back into openemr was kind of a pain and may make tracking numbers difficult for attestation. You do not have to have an office visit with the patient to count an eprescription as valid.  So an electronic refill does count.

bradymiller wrote on Friday, October 28, 2011:

Hi cverk,

Can I get some quick clarification on how we are calculating the AMC’s for the portal related stuff. Check out number 13 and 14 and 15 of the following wiki section (focus on the ‘Numerator Criteria’):
http://open-emr.org/wiki/index.php/Description_AMC#AMC_Measures

In you post above, I think you are talking about item number 15. But, from what you are saying, can we simply just check to see if a portal is turned on for items 13, 14 and 15?

-brady

yehster wrote on Friday, October 28, 2011:

Brady,
http://www.cms.gov/EHRIncentivePrograms/Downloads/13_Clinical_Summaries.pdf
I’m pretty sure that we still have to generate a specific numerator and denominator even if the method of choice to deliver summaries is via portal.  Just stating that a portal is turned on is certainly not sufficient.  We still have to count how many summaries were actually created and accessible from the portal. The “easier” part of having the portal is that it still counts for the numerator even if the patient doesn’t actually go to the portal to view his results. The denominator still needs to be computed (total number of encounters.)

Just as an example.  Suppose that the Provider creates an encounter (sees a patient) but never gets back to fill out the clinical documentation that would appear on the portal in the summary.  That needs to count in the denominator but not the numerator.

Cverk,
I would like to work with you to try and accomplish meaningful use if you are interested.
I believe that the general approach of making patient portal data available by replication should address security concerns about exposure to “all of the internet.”
See my post in this thread:
https://sourceforge.net/projects/openemr/forums/forum/202505/topic/4769926
Your “work system” would still be under “lock and key” on your local LAN, while only the portal would be exposed to the rest of the world.  In this configuration if the portal were compromised, it shouldn’t affect your “work system.”  I  only say “shouldn’t” rather than “won’t” because there are no absolutes in security.

Is it really necessary to manually transfer all  the prescription details back into OpenEMR?  The end goal for meaningful use is to count the number of prescriptions submitted electronically versus the total number of prescriptions. I’m guessing/hoping that your current workflow doesn’t involve the “prescribe” widget/dialog  in OpenEMR itself. Do you hand write any scripts these days or do you print them through allscripts?  (Maybe you are/were hand writing scripts for folks that weren’t entered in your Allscripts system yet.)  If we were to tally the number of times you pressed the “submit electronically” button in Allscripts (numerator) and compared that to the total number of prescriptions submitted (numerator + any paper scripts printed from AS + any handwritten scripts (not sure how you track that)) we would then have appropriate measures to submit for attestation.

-Kevin Yeh, MD

woesau wrote on Friday, October 28, 2011:

The end goal of meaningful use is to improve patient care. All you do here is to get the numbers. What a shame! And you are a physician. Double shame! Maybe your patients should see this.

I see yet another dumb attempt to break OpenEMR certification. If you don’t have prescription data passed back to patient, a number of the meaningful use requirements are affected: medication list, patient Lists, auto measures, and possibly a few more.

Your action will likely cause OpenEMR users to fail meaningful use this year.

bradymiller wrote on Friday, October 28, 2011:

Hi Woesau,

Please be respectful towards others on this forum. As a physician and a developer, there is absolutely no shame in people contributing their time towards 1) helping other physicians attain MU and 2) in the improvement of the OpenEMR software package with new features, such as a free e-prescribing option.

I do agree it would be very useful to have a method to pass the information back to OpenEMR, which has been discussed above (see link in post 27 above).

Thanks,
-brady

zhhealthcare wrote on Friday, October 28, 2011:

@Woesau

I think this attempt at the very least help those practices who do not want MU or are willing to try new things.  After all that is what Open source is all about.  OpenEMR maybe the only one with a lot of eRx options available: phyaura, MMF, ensoftek, ZMG so on and so forth.  So many choices, to me, is a good thing.  The doctor’s will not get short changed.

I, for one, support this effort, as long as everything is legal.  Go tigers or whatever……!!

Shameem

woesau wrote on Friday, October 28, 2011:

Well, who is disrespectful here? I see two people disrespecting the foundation who has contributed money and effort to get e-prescribing into OpenEMR. At the least, they should cover their cost.

There is no respect shown in terms of getting agreement from Allscripts.

There is no respect shown to the community as you make changes without consulting ICSA to see if they will affect certification.

sunsetsystems wrote on Friday, October 28, 2011:

Woesau, did you join SourceForge just to comment on this topic?  You seem to have strong feelings about it.  What is your connection to it and to OpenEMR?

Rod
www.sunsetsystems.com

woesau wrote on Friday, October 28, 2011:

I already post my concerns. Don’t change the topic. Focus on the issues.

OpenEMR is open source, the certification is not. You cannot just make changes and assume that it’s ok.