B4 - Passed!
D2 - failed - they require that all “SELECTS” get logged but the log has to say “QUERY” instead of select and they require all PRINT actions be logged WITH the data that was printed. That is a big issue.
The most straight forward way to implement the print logging would likely be to create a table for print specific logging. There can be a text column where the full HTML can be stored. PDFs could be stored as blobs.
Javascript could be added which scrapes the HTML from browser prior to printing, then submits using AJAX back to the server for logging.
There are security ramifications with this approach as a malicious client can avoid the log by modifying the javascript, but there isn’t really a way to prevent a malicious user from creating a hard copy that is unlogged in a client server environment like OpenEMR.
I think if the log table entry showed the normal event info as PRINT and the data element (what currently usually has SQL) was a link to the “blob” or even a imagefile/pdf/html file etc stored in the patients document tree that would do it.
Can’t we just disable the javascript auto print in the pertinent places?
And leave it up to the user to click Print on the browser at those places?
-brady
I think of the log table entry showed the normal event info as PRINT and
the data element (what currently usually has SQL) was a link to the “blob”
or even a imagefile/pdf/html file etc stored in the patients document tree
that would do it.
Hopefully the “global javascript” hook being proposed would take care of both a manualy print from the browser and any auto fired print events from javascript.
Regarding the “Select” issue in the log report (Administration->Other->Logs), here’s a quick fix that will convert the “select” terms to “Query”. It doesn’t touch the logging engine internals at all, which I think is ideal:
Please review/test and let me know if this will fix this issue.
It seems somewhat reasonable to have a global setting to disable those print functions, that will later become a global setting to log what they do.
I really hate the idea of copying all printouts to a log and would like some more clarification as to what is really required. For example, perhaps the previously-logged SELECTs that retrieved the data could be referenced instead?
The screens that are in a separate window with no browser menu can be printed with Ctrl-P.
The ones that are in a frame or iframe can be printed from Firefox with Right Click -> This Frame -> Print Frame. With some other browsers you’ll be SOL.
For PDFs, the “Print” buttons cause a PDF download with no direct reference at all to printing other than the button label. Tony, do we need to do anything about those?
For each button or link that invokes window.print(), make a call from document.ready to a common function in the top-level frame. The call passes a reference to the element in question as well as an optional string that contains the data to be logged.
If the log data is present then the common function sets an onclick handler for the element which will cause the data to be logged (with an ajax handler) and printing to occur.
If the log data argument string is not passed then the common function will hide the element.
The big question is do the requirements specify if print requests that are initiated by the user hittting control-P need to be logged or not?
Putting the print logging ajax handler in the top level frame seems like a good approach, but, onafterprint might be cleaner than using document.ready and an additional onclick handler, as with this approach all of the setup could be put into one javascript file that is included on every screen that needs to be printed as a single change rather than needing to add document.ready events to all of those pages.
Thanks Kevin. My understanding from Tony is that if they go through the browser menus or Ctrl-P then we don’t have to log anything because that print operation is not “part of the EHR”.
Yes, onafterprint may be better and cleaner. But the document.ready approach allows for passing an argument indicating what to log, which I think will be more usable than dumping entire HTML pages to a log.
In any case it seems about the same amount of work either way, and it will be nice to have an approach that is as flexible as possible. If we change something about it later, better to change one module instead of 63.
Probably then makes sense to store the html “string” as a new sql text
column in the log table. Then when empty/backup the log in
Administration->Backup gui, this would also get included also without any
additional work.
-brady
Actually, I just realized it will be better to store it in the ‘comments’
column in the log table which is already a long text. Doing this will then
maintain the MU2 encryption requirement with minimal work(ie. no additional
work).
-brady