SQL Table - RADplus_audit_database_tables
Radplus_audit_database_tables is populated when a row of data filed in a form is edited or deleted. Although this table does not track initial entries, it will allow you to track all subsequent edits and deletions.
There is a specific way to use this table when querying data.
First you must identify what types of data you need to review.
Radplus_audit_database_tables tracks every field from every table record, so the data must be filtered to make use of it. The best filter to apply would be for a specific table. If you are reviewing changes to Financial Eligibility, you would need to query all entries from Radplus_audit_database_tables where the field_name is equal to one of the tables that collects data from the Financial Eligibility form. An example of the SQL needed would be:
SELECT * FROM SYSTEM.radplus_audit_database_tables WHERE table_name = 'SYSTEM.billing_guar_data'
This statement will show you all rows in Radplus_audit_database_tables that were the result of changes to Guarantor Data from Financial Eligibility.
Radplus_audit_database_tables will create a row for each field that is audited when a change is made. SYSTEM.billing_guar_data is a table that contains 20 columns, so if an individual record from this table is edited by a user, SYSTEM.Radplus_audit_database_tables will create 20 rows, one to track each field of the record that was edited. This allows you to view every field in the record that was changed, so you will have the current values that can be compared to the original submission to see what was changed, and what stayed the same. You can add filters so that field_name field in SYSTEM.radplus_audit_database_tables shows only the relevant fields that need to be reviewed. An example would be to limit the results to show only PATID, Episode Number, and Guarantor Plan code from SYSTEM.billing_guar_data table. This would allow you to see what guarantor plans were changed for a given patient and episode number. In SYSTEM.radplus_audit_database_tables the audit_data_date will be the date of the change, data_entry_user_id will display the user ID who made the change, and audit_data will capture the value that was entered by the user being audited. Finally the last aspect of RADplus_audit_database_tables to be aware of is the entity_database value and the corresponding ENTITYID. There are many types of entities in myAvatar , including Patient and Staff entities. When a record in RADplus_audit_database_tables lists the entity_database as 'PATIENT' a patient record is being referenced. The ID listed in ENTITYID for that record will be the patient ID in question. If a record is listing entity_database as 'STAFF', then the ENTITYID associated to the record will be the Staff ID number of the staff member who was audited.
The above information should allow you to query any given record that has been edited or deleted in your system and have sufficient information to identify who performed the edit or delete, and in the case of an edit, what specifically was changed.
|
Table Column |
Comment |
|
ID |
Unique row ID. Computed value. |
|
audit_data |
Original data (if not date, or scrolling text column). |
|
audit_data_date |
Original data (if a date column). |
|
audit_data_scrolling |
Original data (if a scrolling text column). |
|
entity_database |
Entity database. |
|
ENTITYID |
Entity database ID. |
|
FACILITY |
Associated facility. |
|
field_name |
Field name in associated table. |
|
field_number |
Field number in associated table. |
|
is_date |
Y (date), or N (not a date). |
|
is_scrolling |
Y (scrolling text), or N (not scrolling text). |
|
table_name |
Associated table name. |
|
table_row_counter |
Counter for unique ID in associated table. |
|
table_uniqueid |
Unique ID in associated table. |
|
data_entry_by_login |
|
|
data_entry_by_option |
|
|
data_entry_date |
|
|
data_entry_option |
|
|
data_entry_time |
|
|
data_entry_user_id |
|
|
data_entry_user_name |
|
