bradymiller wrote on Saturday, October 03, 2015:
Hi,
I just committed the above commit to the codebase, which converts the “select” terms to “Query” on the Administration->Other->Logs GUI.
-brady
OpenEMR
bradymiller wrote on Saturday, October 03, 2015:
Hi,
I just committed the above commit to the codebase, which converts the “select” terms to “Query” on the Administration->Other->Logs GUI.
-brady
OpenEMR
sunsetsystems wrote on Saturday, October 03, 2015:
I’ve got code for initial work and proof of concept here:
https://github.com/sunsetsystems/openemr/commits/printlog
You must go to Administration -> Globals -> Logging and select a choice for Printing Log Option. ‘Log entire document where not implemented’ will be the most interesting choice. Then log out and in again to make it effective.
So far this implements logging only for the Patient List report. Other areas will be numerous but straightforward to implement if only the HTML is logged. The opportunity remains to log data that is more succinct.
Comments and suggestions appreciated. No I have not tried out onafterprint yet. Send me a note if you’d like a link to my test site.
Interesting that the log viewer renders the logged HTML.
bradymiller wrote on Saturday, October 03, 2015:
Hi Rod,
Did a quick test on this. The print out and the log picture do not look the same. It appears your method is not collecting what is printed. Or maybe it’s a css thing?
-brady
OpenEMR
sunsetsystems wrote on Saturday, October 03, 2015:
Hi Brady, I expect there will be differences due to css and JS files not being found. I only had 1 patient in my test site and the basic info for them was there. Are you missing important stuff?
sunsetsystems wrote on Saturday, October 03, 2015:
I think we need to change the log viewer to not render from the comments column. It’s pretty funny how the user interface elements can still be clicked on and do odd stuff.
sunsetsystems wrote on Saturday, October 03, 2015:
I have re-created my printlog branch on github. This changes the log viewer to display raw HTML from the comments column, and also implements print logging (or not) for prescriptions.
For prescriptions, there is a “Print (HTML)” button that opens a new window that does not have a Print button but does invoke the Print dialog when it opens. If you have chosen “Hide print feature where not implemented” then what’s different is that the Print dialog is not automatically opened.
Nothing has been done with the prescription PDF print options, since as noted before they do not invoke any print dialog.
Tony, I need to know if these treatments are acceptable.
sunsetsystems wrote on Sunday, October 04, 2015:
Printlog branch replaced again. I’ve been plodding through the scripts, 29 to go.
I found the PHP function strip_tags() and applied it to the logged HTML to make it shorter and more readable. There are some HTML-to-text classes out there that will probably to a better job, can look into those down the road. Also the log viewer should probably be updated to respect line breaks.
sunsetsystems wrote on Sunday, October 04, 2015:
Finished changes to the reporting scripts, so am tentatively done with what I expect is usable for cert testing. Not all reports are tested so be sure to check in advance anything that matters.
Tony - Brady raised a question about encrypting the log comments. Do we need to do something about that for print logging? I don’t understand the requirement there.
bradymiller wrote on Sunday, October 04, 2015:
Hi Rod,
I placed a commit here that will support the encryption of comments in the standard log function, which tests well:
-brady
OpenEMR
sunsetsystems wrote on Sunday, October 04, 2015:
Thanks Brady. Note that my branch was replaced again last night.
Would still like Tony to comment on what the requirement is for encryption.
I’m looking into a HTML-to-text converter.
sunsetsystems wrote on Sunday, October 04, 2015:
I added a commit to do HTML-to-text conversion. This replaces the strip_tags method and should improve readability of the logged print actions.
bradymiller wrote on Sunday, October 04, 2015:
Although a minor issue, I am having a tough time figuring out what the globals selections mean? specifically the “where not implemented” ?
-brady
sunsetsystems wrote on Sunday, October 04, 2015:
Brady, apologies for the poor communication. The print logging interface allows a page to specify what its log message should be. It can do this either by passing a second argument to the printLogSetup() function, or by setting its window variable “printlogdata” before calling printLogPrint(). If it does one of these things then it has “implemented” the message.
I expect this is something we’ll want to do in the future. For example it will be much more helpful to say “User X printed the medications list for patient Y” than just dumping the text of the printed page.
In the meantime the second global selection will be useful if Infogard decides that page dumps are not acceptiable log entries and we are forced to disable Print buttons.
sunsetsystems wrote on Sunday, October 04, 2015:
I have replaced the printlog branch again. This merges with current master, and includes Brady’s encryption fix. If there are no objections I’ll push to SF sometime tomorrow.
tmccormi wrote on Monday, October 05, 2015:
Sorry, I’ve been out all weekend. From what I can tell this will do the job. The encrypt-ability is a requirement for all logged data.
I agree, in the long run it will be better to log a more “succinct” representation of the printed data. It’s only the DATA the needs to be logged not the image of the print as far as I can tell. Capturing the output just seemed easier than figuring out the “final” select statements, but Rod seems to have provided for both / either down the road.
Agree with Brady on needing a better way to describe the “Where not implemented”, it will confuse users. Not sure this is needed at all, since we have to all ALL prints whether they have special implementation or not. So, just the Print log on and off should be fine.
sunsetsystems wrote on Monday, October 05, 2015:
Tony, just to clarify, it was my understanding that printing needs to be logged only if our code initiates the request. I.e. via a Print button or otherwise auto-opening the browser’s print dialog. If the user types Ctrl-P or goes through the browser’s menu then it’s not required. That’s why the “hide print feature” option exists, in case for any reason Infogard does not like what we are putting into the log – I want you to be able to get through certification.
In any case I will remove the “if not implemented” wording, and the final appearance of global settings can depend on the outcome.
tmccormi wrote on Monday, October 05, 2015:
Yes - only if our code initiates the request is correct.
sunsetsystems wrote on Monday, October 05, 2015:
Did some cleanup and pushed to SF. If anyone wants to improve it please be my guest.
tmccormi wrote on Monday, October 05, 2015:
Well, I turned on print logging and tried a report Patient->List and
collections report but nothing got logged
the Hide feature seems to hide print buttons
CCR/CCD say Print/View and should probably just say View
Not a clue how ZHH portal will handle this requirement, however.
Tony McCormick, CTO
Support: 866-735-0897, Direct: 713-574-6709
My Calendar: http://bit.ly/XznvDo
“It makes me feel young again to be wrong so often now.” - paraphrased from
Greg Bear
On Mon, Oct 5, 2015 at 9:14 AM, Rod Roark sunsetsystems@users.sf.net
wrote:
Did some cleanup and pushed to SF. If anyone wants to improve it please be
my guest.Rod
http://www.sunsetsystems.com/MU2 Progress
https://sourceforge.net/p/openemr/discussion/oemr_501c3/thread/e0c8ffd8/?limit=25&page=3#373aSent from sourceforge.net because you indicated interest in
OpenEMR / Discussion / OEMR Non Profit OrganizationTo unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net
–
Please be aware that e-mail communication can be intercepted in
transmission or misdirected. Please consider communicating any sensitive
information by telephone. The information contained in this message may be
privileged and confidential. If you are NOT the intended recipient, please
notify the sender immediately with a copy to hipaa-security@mrsb-ltd.com and
destroy this message.
tmccormi wrote on Monday, October 05, 2015:
Take that back, Hide does not hide the print buttons on the reports