The eCR Viewer has implemented an ONC-compliant audit log. It is only populated when using the DUAL or NON_INTEGRATED configurations of the viewer. In INTEGRATED mode, it is the responsibility of the integrating tool to log accesses to the eCRs.
Standards Referenced
As noted in paragraph (d)(2)(i)(A) of the ONC Standards Referenced, the following are data the audit log needs to include
7.1.1 Date and Time of Access Event—The exact date and time of the access event and the exit event.
7.1.2 Date and Time of Activity—The time to which the data entered refers, if not contemporaneous with user’s data entry
7.1.6 Patient Identification—Unique identification of the patient to distinguish the patient and his/her health information from all others.
7.1.7 User Identification—Unique identification of the user of the health information system.
7.1.8 Type of Action (for example: creations, additions, deletions, changes, queries, accesses, copy, print, and copy and paste)—Specifies inquiry, any changes made (with pointer to original data state), and a delete specification (with a pointer to deleted information).
7.1.9 Identification of the Patient Data that is Accessed— Granularity should be specific enough to clearly determine if data designated by federal or state law as requiring special confidentiality protection has been accessed. Specific category of data content, such as demographics, pharmacy data, test results, and transcribed notes type, should be identified.
There are subprovisions in paragraphs (d)(2)(i)(B) and (d)(2)(i)(C) for cases when the audit log is disabled and when exported. Since these functions are optional, we’ll leave them out of the initial implementation unless there’s sufficient user demand in subsequent research.
Translating these standards into actions within the eCr Viewer (referencing the regulation components in parenthesis), the audit log will need to track
User creation, updates, deletion, and user sign in and sign out(7.1.7)
Program area creation, updates, deletion (7.1.7)
Listing of eCRs and the filters that resulted in that list (7.1.6, 7.1.9)
Creation of eCRs (7.1.6)
Viewing of eCRs (7.1.6)
All of the above need to be labeled with a timestamp accurate within 5 seconds of the event occurring to comply with 7.1.1 / 7.1.2. The log would need to keep information for ten years past the lifetime of the medical record, which in our case, is the length of time the eCR is available in the viewer.
The audit event creation timestamp is synchronously generated by the database at the time of write to the database, in the same transaction as the audited action, within 5 seconds of the event occurring
These messages will need to be exposed according to the regulations set forth in the audit reports regulation, which mandate the audit log be sorted chronologically and with the ability to filter by start and end date.
An index is added on the date column to ensure fast chronological access. The typical tool the deployment site uses for database access can be used to query and view the audit log.
The audit log must be able to determine when information has been tampered with in accordance with subpoint v) of regulation 170.315 (d)(2). ONC recommends using a hashing standard with strength equal or greater than SHA-2 to determine when unauthorized changes to the database may have occurred.
The audit log generates a SHA-256 checksum based on author, timestamp, and message contents to determine if there are any changes to the written audit log data