Blogs Home
Thursday, April 27, 2017 12:00 PM

PHI and MEDITECH’s Data Repository

Written by Joe Cocuzzo, Senior VP of Report Writing Services - iatricSystems

To address HIPAA, MEDITECH added logging of access to PHI via reports and all applications, and added that level of detail to MIS user activity logs. So, if you run an NPR, RD, or standard report and the report contains PHI, the run user and the set of patients in the output is logged. MEDITECH has a field in their “programmer” NPR Report Writer routine where they can defeat logging, and that makes sense for big exports where the run user just set up the scheduled report run, but otherwise MEDITECH has fairly comprehensive tracking of access to PHI via most reports.

But what about Data Repository (DR) reports? 

In my experience, hospitals typically don't add any kind of PHI access logging to their Data Repository reports. This seems like a significant gap in PHI monitoring. It may be true that HIPAA provides an exemption from “disclosure reporting” for access to PHI for treatment, billing, or government reporting. However, protection of PHI should involve monitoring of access, and if you do not have any monitoring in place in your MEDITECH DR reports, you may have a significant gap in your patient privacy monitoring.

In our DR Resource Center product, available in a low-cost subscription basis, we have a library of reports, and each of them that contain PHI has code that writes to a custom database to log user, report, date, time, and patient identifiers. This logging can then be fed to Security Audit Manager™ (SAM) or some other patient privacy product, and it seems like a sensible practice to build PHI monitoring for reports written in the DR. You could omit such logging for mass exports (for example, if you send every account to an analytics tool, logging the run user is a waste of space and might trigger false alerts about the massive access to PHI of some IT staffer who set up the data exports). Other reports, though, that prompt for selection criteria and could be used for PHI snooping should have monitoring, just as their cousins in NPR and RD have.

Help is available

If you have questions about our DR Resource Center product, please let me know. If you need assistance with setting up monitoring in your own SSRS/SQL, Crystal/SQL, or other reporting out of the DR, one of my SQL folks could advise you. If you follow our “best practice” of using stored procedures for all report logic and use Crystal or SSRS as just the presentation mechanism, adding code to log user access is just a matter of adding logging to the appropriate SQL procedures. If you start now with a standard practice of including logging whenever appropriate, you won’t create a growing hole in your PHI user monitoring practices.