Requirements for Patient review of their medical record audit trail

Context: This proposal describes a target for a patient-accessible audit trail for implementation in a 2 to 5 year time frame. It is not expected that any organization would be able to implement this proposal immediately or in the near-term. The near-term impact of this proposal is to (1) stimulate discussion of this subject, (2) provide a benchmark for gap analysis of projects, and (3) provide a basis for policy development within and external to, our organizations.

Background: Many security/privacy breaches are a result of individuals in the covered entity with legitimate access rights who view patient information that they should not be viewing as it is not needed to perform their official duties related to treatment, payment or health care operations or other legal authority to view the information does not exist. Typically, they are viewing information on a personal acquaintance who is not under their care. It is extremely difficult to reliably detect all such security/privacy breaches.

Though the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule does not mandate that covered entities provide copies of audit trails to patients, the most plausible way to detect the above described security/privacy breaches is to allow patients to review the audit trails of their chart, and they will be able to recognize individuals who they do not believe have a legitimate need to access their chart. Patients will not be able to detect these breaches in an audit trail, unless that audit trail is designed to clearly indicate the who, what, when, where, and why of each individual accessing their chart. If this information is not presented to the patient in a very usable format, it will generate many needless questions and both the patient and the auditor will be frustrated with a very low specificity of the information.

Following are the proposed requirements for the audit trail and processes to support patient viewing of that audit trail:

  1. Patients should be able to review (in-person or online through web access) each of the following elements of the audit trail as it relates to their record: viewing only, editing, or electronically transferring all or part of their record. (Audit trails of these patient-initiated access to their personal audit trails will also be required).
  2. Clear indication of who accessed their record.
    a) Name of the user
    b) Title of the user at the time of access, e.g. MD, RN, medical student, RN, pharmacist, QA, call center agent, etc.
    c) A role description that includes a brief patient friendly summary of the role, e.g. pathologist: studies biopsy results under a microscope
  3. From what location they accessed my record (i.e. which facility)
  4. Which parts of the record they viewed/printed/transferred (in layman’s terms: e.g. “doctors notes”, “lab results”, etc.)
  5. When did the access occur including date and time?
  6. Why the record was viewed/printed/transferred (in layman’s terms: e.g., treatment, payment for services, quality review, training, etc.)
  7. Ability to provide the patient with a digital or paper copy of this audit information
  8. Ability to answer patient requests for further clarification of specific audit events
  9. These audit trails should be retained for a minimum of XX years by all legal record maintenance guardians.
  10. Provide patient with a well documented process to escalate any perceived inappropriate accesses.
  11. Documented policies within the covered entity on how to investigate and mitigate any security/privacy breaches resulting from the patient review of the audit trail.

Leave a Reply

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax