We have been using Ankhos in the final stages of beta for a few months now. It is not yet our legal document (we are still charting on paper, as well) but we are very close to ending the beta. Before we do this, however, I want to make sure our legal ducks are in a row.
One main concern that a healthcare practice faces is impending lawsuits and audits. Electronic systems are very powerful and very descriptive. There are timestamps and ‘fingerprints’ associated with every action taken in Ankhos. If there was an accusation that someone had not documented an allergy or reaction correctly, or administered the wrong drug, the record of that incident would be easily accessible with an electronic system and the legal accusation would be quickly resolved.
However, electronic systems also present a great opportunity for fraud and tampering. Yes, fingerprints, access controls and timestamps are strewn throughout the system, but the database administrator has final say about everything that is in the database. A diligent fraudster can easily cover up an audit trail that would otherwise prove malpractice.
Because of this possibility, an astute lawyer could raise doubt about the validity of any claims made with reference to the electronic records, and rightly so. But how do we solve the problem of proving data integrity while at the same time retaining the flexibility of an electronic system?
After some thought and research on best practices, we decided that it was essential to have a third party involved. One whose interests were not co-mingled with those of the practice. We also wanted to have an irrefutable way to use that third party to validate the state of the database. We want to be able to say:
“Yes, Mr. Lawyer, this was the exact state of our database (and application code) at this date and time”
Our process is two-fold:
1. During each daily backup, we hash the backup file using the Unix md5 hash command. We keep local copies of both the hash and database file. This is a common practice across many download sites. At a later date, the file can be hashed again and compared to the hash on file. If the hash strings match, then the file has not been altered or replaced.
2. The first step is great, but if the database admin has complete control of her data, then she has complete control of the hashes, as well (and any backup trail).
To solve this problem, we email this hash value to a number of public email accounts to which office administrators have access. The hash value is a short string of ‘random’ characters derived from the database file and cannot be used to reconstruct a backup file (thus, no patient data is transmitted on the unsecure email format). Doing this allows the hash value to have a timestamp assigned by a third, independent and uninterested party.
This way, when a lawyer asks us how we know that database admin we hired didnt cut out any incriminating data, we can point to the timestamp given by the email provider and show that by the power of our email provider and all the SMTP servers involved in this transaction, THIS was the state of our database at this time.
Hopefully this will satisfy auditors and save the clinic time and money trying to prove the state of their documentation.
