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,
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.
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.
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.
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
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.
@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.
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.
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.
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, 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.
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.
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).
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……!!
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.
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?