Epic is a big system, with literally thousands of database fields that can influence the behavior of your system. Sometimes, a person will change a field, and unintended consequences will create issues. This can happen even with Data Courier and the best change approval processes. Epic has many tools to help you track what has been changed, by whom, when, and sometimes even what the field used to be, which can prove crucial to restoring order, but these systems won’t help unless they are turned on and understood by your IT staff.
Change History is one system built into Chronicles, it can be turned on at the masterfile level, though it’s prohibited from being used on any “dynamic” masterfiles like EPT (Patient). When a user edits a record, the system will record into a cache file global the record, name, time and list of fields “potentially” edited. This information is indexed making it easily searchable, whether through Chronicle’s own functions or the Lookit global viewer, but not Clarity. The reason the feature isn’t enabled automatically is that you must decide how exactly you will purge old unneeded data from the file. Epic provides two Chronicles Batch Templates: one that lets you remove data based on age of the edit event (remove data older than 6 months), the other based on number of edit events per record (only retain the last 5 change audits per record). You can set up multiple batch jobs in order to enforce different or overlapping rules across the masterfiles you track with this system. Each edit event is less than 500 bytes in size, so it’s fairly manageable to watch over nearly every non-dynamic masterfile for months