In my experience, hospitals typically don't add any kind of PHI access logging to their Data Repository reports. This seems like a 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 gap in your patient privacy monitoring.
In our DR Resource Center™ product, available on 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), 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’ would trigger false positives 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 be monitored, 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 program.
Stop by and see us at International MUSE.
Tim Burris and I will be available in our booth to discuss this very important topic.