Query Connector

← Back to Documentation

Below is documentation for the Query Connector's implementation of an ONC-compliant audit log.

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 Query Connector (referencing the regulation components in parenthesis), the audit log will need to track

  1. User creation, role demotion/promotion, group assignment / unassignment, and user sign in and sign out(7.1.7)
    1. User, user group CRUD, and log in and out operations were made auditable in this PR and validated by these session management and these user management integration tests
  2. Query creation and deletion (7.11),
    1. Query building creation, updates and deletion were made auditable in this PR and validated by these integration tests
  3. Patient discovery response and viewing patient results (7.1.6, 7.1.9), the user that executed them (7.1.7) and the associated patient query params (7.1.6, 7.1.9)
    1. Patient discovery and patient records were made auditable in this PR and validated by these integration tests
    2. These integration tests validate the identity of the user executing the query and associated patient parameters are present in the final write to the audit log table
  4. The adding of a FHIR server (7.1.8)
    1. FHIR server CRUD operations were made auditable by this PR and validated by these integration tests

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 point at which query results are returned. This means any audit entries can be deleted after ten years.

  • The audit event creation timestamp is synchronously generated by Javascript prior to the write to the database 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.

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 table is prevented from being updated or deleted via a Postgres macro introduced in this PR and validated by this integration test
  • 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