MU2 Progress

Archived OEMR Non Profit Organization
#41

tmccormi wrote on Thursday, September 24, 2015:

Next available testing dates are Friday afternoon and the following week Mon-Thurs.

Remaining measures to test or re-test

  • §170.314(a)(8) Clinical decision support (finish)
  • §170.314(b)(1) Transitions of care – receive, display and incorporate transition of care/referral summaries
  • §170.314(b)(5)(A) Incorporate laboratory tests and values/results
  • §170.314©(1)-©3 Clinical quality measures
  • §170.314(d)(2) Auditable events and tamper-resistance (attestation doc provided, but testing required)
  • §170.314(e)(1) View, download, and transmit to 3rd party
  • §170.314(e)(2) Clinical summary
  • §170.314(f)(2) Transmission to immunization registries
  • §170.314(g)(2) Automated measure calculation
#42

tmccormi wrote on Thursday, October 01, 2015:

Update: Mixed results in today’s testing:

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.

#43

yehster wrote on Thursday, October 01, 2015:

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.

It might work to inject http://tjvantoll.com/2012/06/15/detecting-print-requests-with-javascript/ onafterprint events globally rather than needing to track down every “print button” in the application.

#44

sunsetsystems wrote on Thursday, October 01, 2015:

Kevin, nice find with onafterprint. What do you think is the easiest way to get it injected into all frames?

Tony: Need more info about what the log should look like in the case of printing.

Rod
http://www.sunsetsystems.com/

#45

tmccormi wrote on Thursday, October 01, 2015:

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.

#46

bradymiller wrote on Thursday, October 01, 2015:

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

On Thu, Oct 1, 2015 at 2:04 PM, Tony McCormick tmccormi@users.sf.net
wrote:

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.

MU2 Progress
https://sourceforge.net/p/openemr/discussion/oemr_501c3/thread/e0c8ffd8/?limit=25&page=1#c93e

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/openemr/discussion/oemr_501c3/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

#47

yehster wrote on Thursday, October 01, 2015:

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.

#48

bradymiller wrote on Friday, October 02, 2015:

Hi Tony,
Regarding B4, is there any new code that is needed to get into the codebase for this?
-brady

#49

zhhealthcare wrote on Friday, October 02, 2015:

Yes, there are modifications that needs to be submitted.

ZH

#50

bradymiller wrote on Friday, October 02, 2015:

Hi Tony and everybody else,

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.

thanks,
-brady
OpenEMR

#51

bradymiller wrote on Friday, October 02, 2015:

Hi ZH,
Just post the modifications whenever your ready with them.
thanks,
-brady

#52

sunsetsystems wrote on Friday, October 02, 2015:

I found 63 scripts that invoke window.print(). They are:

controllers/C_Prescription.class.php
interface/patient_file/front_payment.php
interface/patient_file/letter.php
interface/patient_file/summary/print_amendments.php
interface/patient_file/summary/demographics_print.php
interface/patient_file/summary/create_portallogin.php
interface/patient_file/summary/shot_record.php
interface/patient_file/summary/pnotes_print.php
interface/patient_file/pos_checkout.php
interface/patient_file/printed_fee_sheet.php
interface/modules/zend_modules/public/js/scripts/immunization.js
interface/main/finder/patient_select.php
interface/main/calendar/modules/PostCalendar/pntemplates/default/views/week_print/outlook_ajax_template.html
interface/main/calendar/modules/PostCalendar/pntemplates/default/views/week_print/ajax_template.html
interface/main/calendar/modules/PostCalendar/pntemplates/default/views/day_print/outlook_ajax_template.html
interface/main/calendar/modules/PostCalendar/pntemplates/default/views/day_print/ajax_template.html
interface/main/calendar/modules/PostCalendar/pntemplates/default/views/month_print/outlook_ajax_template.html
interface/main/calendar/modules/PostCalendar/pntemplates/default/views/month_print/ajax_template.html
interface/orders/pending_orders.php
interface/orders/procedure_stats.php
interface/orders/pending_followup.php
interface/forms/care_plan/new.php
interface/forms/aftercare_plan/new.php
interface/forms/note/print.php
interface/forms/treatment_plan/new.php
interface/forms/CAMOS/notegen.php
interface/forms/CAMOS/rx_print.php
interface/forms/LBF/printable.php
interface/forms/vitals/growthchart/chart.php
interface/forms/transfer_summary/new.php
interface/drugs/dispense_drug.php: window.print();
interface/billing/sl_receipts_report.php
interface/billing/indigent_patients_report.php
interface/reports/services_by_category.php
interface/reports/encounters_report.php
interface/reports/chart_location_activity.php
interface/reports/inventory_transactions.php
interface/reports/sales_by_item.php
interface/reports/custom_report_range.php
interface/reports/ippf_daily.php
interface/reports/unique_seen_patients_report.php
interface/reports/immunization_report.php
interface/reports/destroyed_drugs_report.php
interface/reports/clinical_reports.php
interface/reports/non_reported.php
interface/reports/appointments_report.php
interface/reports/ippf_statistics.php
interface/reports/referrals_report.php
interface/reports/cqm.php
interface/reports/inventory_list.php
interface/reports/front_receipts_report.php
interface/reports/ippf_cyp_report.php
interface/reports/insurance_allocation_report.php
interface/reports/collections_report.php
interface/reports/receipts_by_method_report.php
interface/reports/patient_flow_board_report.php
interface/reports/inventory_activity.php
interface/reports/amc_tracking.php
interface/reports/patient_list.php
interface/reports/prescriptions_report.php
interface/reports/appt_encounter_report.php
interface/reports/svc_code_financial_report.php
sites/default/referral_template.html

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?

Rod
http://www.sunsetsystems.com/

#53

sunsetsystems wrote on Friday, October 02, 2015:

Some further thoughs on how to approach this.

  1. 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.

  2. 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.

  3. If the log data argument string is not passed then the common function will hide the element.

Sounds reasonable?

Rod
http://www.sunsetsystems.com/

#54

yehster wrote on Friday, October 02, 2015:

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.

#55

yehster wrote on Friday, October 02, 2015:

As an experiment, adding this code as javascript to a printing page gives a “preview” of the html.

window.onbeforeprint = function()
{
alert(window.document.body.innerHTML);
}

Also, it’s pretty clear that there are pages that are meant to be printed such as
ccr/createCCR.php

that don’t use window.print

#56

sunsetsystems wrote on Friday, October 02, 2015:

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.

Rod

#57

yehster wrote on Friday, October 02, 2015:

The onafterprint approach can just as easily pass data to the logging function instead of simply dumping the full HTML.

The data could be either a simple string as previously proposed or a structured javascript object.

#58

bradymiller wrote on Friday, October 02, 2015:

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

On Fri, Oct 2, 2015 at 2:35 PM, Kevin Yeh yehster@users.sf.net wrote:

The onafterprint approach can just as easily pass data to the logging
function instead of simply dumping the full HTML.

The data could be either a simple string as previously proposed or a
structured javascript object.

MU2 Progress
https://sourceforge.net/p/openemr/discussion/oemr_501c3/thread/e0c8ffd8/?limit=25&page=2#8ae6

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/openemr/discussion/oemr_501c3/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

#59

sunsetsystems wrote on Friday, October 02, 2015:

Agree on both points. I will try to make some progress on this over the weekend. If anyone wants to help, let me know so we can synchronize.

Rod

#60

bradymiller wrote on Friday, October 02, 2015:

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

On Fri, Oct 2, 2015 at 4:35 PM, Rod Roark sunsetsystems@users.sf.net
wrote:

Agree on both points. I will try to make some progress on this over the
weekend. If anyone wants to help, let me know so we can synchronize.

Rod

MU2 Progress
https://sourceforge.net/p/openemr/discussion/oemr_501c3/thread/e0c8ffd8/?limit=25&page=2#7c02

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/openemr/discussion/oemr_501c3/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/