Home Forums Discussions General Discussion Would AC do ok in courtrm c respect to reliability

Hi I am a user for a about a year-never posted anything but was reading an article in one of the FP throw-away type newspapers talking about making sure your EMR will be considered an unalterable reliable record in a court of law. They suggested that an emr should have a clear audit record of times and dates of access by whom and proof that its data is consistent and unadulterated. I couldn't find old discussions about this but are there back side aspects of AC that can be accessed to prove this stuff- does this concern anyone else- just dont want to have my record thrown out or seen as unreliable. Thanks- tim

Once you sign a record, it is locked. You can update it, but it will have a second entry with a different date/time stamp. You cannot (easily) get into the databases to change this. This should hold up in a court of law, but then ...

Sometimes, this is cumbersome, since you might have forgotten to add something, or at the end there is a "Oh, by the way..." But I'm sure it was done for that very reason.

I'm not quite sure this is the case, with regards to the Audit Trail. From a database management perspective, each time a record it changed there should be a record of:
1) the change that was made
2) who made the changes

I may be wrong, but this is not something that is easily done in MS-Access. I know with SQL Server these are managed by database triggers. Triggers are programming constructs that exist at the database level and fire in response to some change in a record. A trigger can fire;
1) for update - when a record is changed
2) for insert - when a new record is created
3) for delete - when a record is deleted.

In order to produce an audit trail a trigger (for each action) is created on each table to be audited and that trigger then creates a record in another table(s) of what was changed or deleted.

The reason I don't believe AC currently does this is because a few months ago someone raised the issue of how it handles a patient with a name change: You have to create a new record...or something to that effect, which gives me pause.

If this were in SQL Server a "PriorNames" table would exist and every time there is a patient name change, an Update Tigger would fire and write the old name and the patientID to the PriorNames table. A name search would then search both the current patient table and the PriorNames table to find the patient no matter the name change.