lcmaas3 wrote on Saturday, February 16, 2013:
First pass at reports looks great; I pulled them into my branch.
https://github.com/lcmaas/openemr/commit/e5ecf9137e488af7b31ab6a269666033699cd255
It should be straightforward to add a “Run Now” for each row to call execute_background_services.php?background_force=1&background_service=$row. Could even be in a jQuery call that changes running column to “yes” before posting and back to actual table value after the post returns.
bradymiller wrote on Saturday, February 16, 2013:
Hi,
Did some more integration(and bug fix) work (the branch that is based on your current branch with the commit in it is here):
http://github.com/bradymiller/openemr/commits/work-on-directmessaging_2
Here’s the commit comments:
1.Fixed installation mechanism to allow addition of more users (as services)
after the main user has been added.
2.Changed the unknown patient import screen to use patient_id=00 and added
a warning here to only use this upload tool if the patient is not known.
Note the point of this gui is twofold:
a. Allow assigning of patients for documents imported via other services
and tools where the patient was not yet mapped (for example, it will
allow assigning of patients for documents imported via Direct service
that are stored in the 'direct' directory).
b. Allow manual importing of documents where the patient is not yet known
or mapped (and then at a later date, can then assign the patient on
this screen when known)
3.Modified the Reports->Services->Background Services to display more
intuitive results (and incorporated the automatic feature)
The setup script broke because the user is set with a hard-coded id after the database.sql script is converted. To avoid breaking things for folks(keep the first user hard-coded to id of 1, guessing some code in the official/unofficial codebase may depend on this), added a mechanism to add the service users after the intitial user is added.
I completely agree with using your directory ‘direct’. The issue when calling the New Documents with a patient_id of 0 is that users will see this screen and begin importing docs, which will then go into oblivion. By calling New Documents with a patient_id of 00, the imported documents go into directory ‘00’. Note this screen also shows your imported docs from the ‘direct’ directory (I tested this in a wonky fashion by simply moving the file to direct directory and modifying the url to have direct in it rather than 00 and kept the foreign_id of 0). To avoid users from using this screen for all uploads (and then using the move to patient), I placed a warning at the top of this screen(note this doesn’t break anything if users do this, but then all the files manually uploaded for the entire practice may end up in this one directory). You are correct that the directory should not matter (the money is the foreign_id setting along with the fact that we now know trying to use 0 for patient_id bugs out somewhere). Note there is a CouchDB option at Administration->Documents that does not even incorporate the directories since stored on a CouchDB server (I am confident that your method will be compatible with it, but plan to test it when I get developer access to your direct service).
Regarding the execute_background_service discussed above. Agree would be a quick addition. An option could be to make the ajax call, sleep 1-2 seconds and then simply refresh the screen.
-brady
OpenEMR
bradymiller wrote on Saturday, February 16, 2013:
Hi,
The next step (if you are done with main development) will be to rebase all these commits into one and then ask the community to review it considering some of the core changes in code. Since this code makes some core changes in users,pnotes,documents will also be nice to have it all in one commit to ease future debugging. Just let me know that the main development is done (I think it is) and then I will do this (the authorship of the commit will be yours).
When I get the developer authorization to test on your direct server, I’ll also plan further testing on this.
-brady
OpenEMR
bradymiller wrote on Saturday, February 16, 2013:
Just realized,
Something that would be very helpful would be to have a last_run_start timestamp sql_column in background settings table which could just be set when setting the running to 1. Then the report could show this (especially useful for the manual runs, but also nice to know for the automatic runs).
-brady
OpenEMR
bradymiller wrote on Saturday, February 16, 2013:
error above:
meant background_services table
lcmaas3 wrote on Sunday, February 17, 2013:
the last_run_start can reliably be determined by by SELECT (next_run - INTERVAL execute_interval MINUTE) as last_run_start FROM background_services, since next_run is always set to NOW() + INTERVAL execute_interval MINUTE when the function call is made, and next_run is adjusted exactly whenever interval is changed.
bradymiller wrote on Sunday, February 17, 2013:
sorry for the numerous emails,
Another very useful sql column for the report would be a last_run_stop timestamp sql_column in background_services that is just set whenever the running is set to 0. ok, this should be my last post for awhile 
-brady
OpenEMR
bradymiller wrote on Sunday, February 17, 2013:
Hi Luis,
But doesn’t that calculation fall apart:
1. if the settings are changed in automatic mode
2. in manual mode
-brady
bradymiller wrote on Sunday, February 17, 2013:
Actually,
I think it only falls apart if the settings are changed. I guess it would just be nice to be 100% confident of this because this report can be used to debug the services if problems come up (ie. a hanging service). Also would be nice to set them to NULL as default, so know if the service has even been run yet when looking at the report.
-brady
lcmaas3 wrote on Sunday, February 17, 2013:
re: last_run_start: when the settings are changed, we adjust next_run up or down to match any increase or decrease made to the execute_interval. This is done in the edit_globals script, so the computation should always be accurate, unless the interval is changed by some mechanism other than the standard globals interface.
bradymiller wrote on Sunday, February 17, 2013:
Hi,
Then it sounds like the only detail that is missing is whether the service was ever run. This will be very useful information to know (ie. when people ask for support here, will be helpful to know if the service ever ran). Would it be ok to make the next_run default to ‘NULL’ when bring in a new service or would that muck up your engine; then we can figure out the start run time and whether it was ever run very easily without needing to add the last_run_start variables (note the last_run_end isn’t really that important and can always be added on later down the road if a situation comes up that requires it).
-brady
lcmaas3 wrote on Sunday, February 17, 2013:
I just pushed minor changes to address whether service was ever run. I changed default background_services.running value to -1 which means “never run”. I added a column in the report, too. Also, I removed the if/else around the display of “Currently Running” in the report, since a service could still be running even if inactive (if it started before globals were changed) or even if execute_interval=0 (if it was started by cron, etc.)
https://github.com/lcmaas/openemr/commit/c84d57a00addac18f933a561cfa8fce3ed28f73a
Luis
lcmaas3 wrote on Sunday, February 17, 2013:
commit amended to fix unwanted blocking of force when execute_interval=0
https://github.com/lcmaas/openemr/commit/7218234d5883709ad2a2a9fa96847e4f10f14062
bradymiller wrote on Sunday, February 17, 2013:
Hi Luis,
Here’s a rebase of all the commits into one (I also incremented the database counter in version.php, which is done whenever we make database changes). It is the first commit on the following branch:
http://github.com/bradymiller/openemr/commits/rebase-directmessaging_1
After some lightning improvements/bug fixes this seems to be testing very well. It’s my opinion this can likely get committed to sourceforge(after I do a couple sanity tests when I have the Direct developer authentication going). If there’s no more code to be added, just let me know, and then we can request a formal (and hopefully final) review from the community.
thanks,
-brady
OpenEMR
lcmaas3 wrote on Sunday, February 17, 2013:
Hi Brady,
This seems pretty solid to me as a good first release to the community for review. I will get you your credentials shortly. Thanks for your help getting this together,
Luis
bradymiller wrote on Sunday, February 17, 2013:
Hi Everybody,
Requesting a code review on the following(majority of code by Luis Maas At EMR Direct):
http://github.com/bradymiller/openemr/commit/0621077296e58ad7cca2371f4e1d5b5688a30415
Commit comments:
Implement direct message receive and background services manager, take 1.
1. Background Service Manager Framework
-Documentation provided in the main library/ajax/execute_background_services.php script.
-Report at Administration->Reports->Services->Background Services
2. Direct Message Receive
-Service built on top of the Background Service Manager Framework
-Can be set/modified in Administration->Globals->Connectors (bottom section)
-Log can be viewed at Administration->Reports->Services->Direct Message Log
-Added support for importing of documents with no patient mapping. GUI for
this is at Miscellaneous->New Documents.
-Added support for sending pnotes with no patient mapping.
-Added support for service bots to enable storage of documents,
sending of messages and accurate logging by services.
3. Miscellaneous mods: Changed the Administration->Services to Administration->Codes in left_nav menu.
(to avoid confusion with the Services reports)
Also placed a review request in the following tracker item:
http://sourceforge.net/tracker/?func=detail&aid=3605121&group_id=60081&atid=1245239
thanks,
-brady
OpenEMR
bradymiller wrote on Monday, February 18, 2013:
hi,
Got the developer phimail direct credentials and tried the above. It is very nicely integrated (to say the least). Within OpenEMR, I just sent a dummy CCD document to myself(so it got uploaded to phimail direct), collected it on the next service call(is called every 5 minutes), saw the message(pnote) that the document was collect, assigned the CCD doc to the correct patient(and CCD category) at Miscellaneous->‘New Documents’ and then watched the REports->Services->Direct Message Log item go to “Dispatched” (meaning it was delivered) on the next service call.
-brady
OpenEMR
bradymiller wrote on Tuesday, February 19, 2013:
Hi Luis,
As above, on my primary development environment, it is working well with my phimail credentials. However, when I try to transfer (Transfer button in Reports screen) a document on my secondary development environment (which has the CouchDB database set up to test), I am getting the following error message:
“Direct messaging is currently unavailable. EC:3”
I’ve triple-checked my credentials in the globals and, again, my primary development is still working ok.
(The reason for the secondary development environment is to simply test to ensure compatibility with the CouchDB option; I am very confident it will work since documents uploaded at Miscellaneous->New Documents are correctly imported into CouchDB, but I just want to make sure the documents coming in from the direct server mechanism are correctly imported to CouchDB).
thanks,
-brady
OpenEMR
bradymiller wrote on Tuesday, February 19, 2013:
Hi,
I bet it’s related to my using of localhost and http on the secondary environment (whereas the primary environment uses the typical https://ipaddress). looking into it.
-brady
OpenEMR
bradymiller wrote on Tuesday, February 19, 2013:
Hi,
It’s not that. Looks like that for some reason, the following code is erroring out on my second development environment:
$fp=@fsockopen($server,$phimail_server['port']);
if ($fp===false) return("$config_err 3");
Note my second environment supports tcp,ssl streams (it is ubuntu desktop 2.04; fyi my primary environment is ubuntu server 10.04)
Any thoughts here?
-brady
OpenEMR