5. Data Integrity

Meaningful Use Requirements

AR.FND 07.01: Provide the capability to protect electronic protected health information from improper alteration or destruction.

AR.FND 07.02: Provide electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.

On a broader perspective, the data integrity can be achieved by the combination of the following features:

   SSL Configuration
   
   Client side certificates (CCHIT enhancement)
   
   Proper access control 
   
   Backup
   
   Checksum

Since the first four features are taken care already in OpenEMR, this document talks about the use of checksums to maintain data integrity

Types of EPHI to be considered for data integrity

a.Encounter

b.Prescription

c.Immunization

d.Issues (Problem, Allergy, Medication, Surgery, Dental)

Proposed Solution

A single checksum can be stored along with other details in the database table for PHI like encounters, prescriptions, issues and immunizations. For each ‘insert’ and ‘update’ activities, a new checksum is calculated and the same can be updated. This will help us to identify the data losses/modifications during accidental data corruptions such as bad disk sector.

While displaying the details, the recent checksum can be calculated and this can be compared with the stored checksum. If both checksums doesn’t match (due to data corruption), a red alert would be displayed at the top saying “The displayed information may not correct. Please verify/correct the same and press the submit button”. The user can approve the information for its validity by pressing the “submit” button. This activity calculates the new checksum again and the same would be stored in the table.

Other alternatives discussed & dropped (Just included here for the completeness)

The different approaches analyzed are explained in this section:

1. Using “Lock” & “checksum” & “Addendum” options

We can have the "Lock" feature for some of the important data (like encounter forms, prescription etc). Once the encounter details are finalized, the physician can click the "Lock" button provided near the corresponding encounter. Once the data is locked, a special field in the database called ‘flag’ is set to 1. The checksum of the data is calculated and the same can be stored in the table. When the ‘flag’ is 1, the data will not be allowed for any modification or deletion.

The further changes should be added only via addendums. The addendums should also be locked and saved in the previous manner. For each insertion/updation/deletion, checksum would be calculated and the same is stored in the database table.

Disadvantage

When addendums are used, it would be difficult to provide the consolidated information for any reporting as always the recent information = old information + addendums. And also the users need to spend lot of time in reading all the information to come to a conclusion. Without going for addendums, we can have “Lock” with “Unlock” feature wherein we can prompt the password from the user during “Unlock”. But in reality, the physicians won’t prefer these kinds of hard rules.

2. Using separate “checksum” feature for all transactions and “logging”

Since we have implemented the Client Side Certificates, the users with only the valid username, password and certificate would be able to login.

Here, whenever the change happens, the checksum is calculated and stored in the separate log (database table) along with the “New State”.

Ex: Let us assume that the SOAP encounter is created for a patient. During next time the doctor had modified the encounter with different ‘Plan’. Thus the two entries are created in the log because of these transactions.

Some of the values for the two entries in the log are given below:

Checksum Description

<For the initial SOAP value> The values of S, O, A & P are described here <For the latest SOA P value> New state of ‘P’ is mentioned here

Integrity checking options: On a weekly basis, the administrator can run the "Integrity checker" tool (for all or for the required patient) just to make sure whether any data in the database had altered in the improper way. "Check integrity" option would be provided for each patient for all the defined transactions and the physician can perform the check as and when required.

Disadvantages

Logging the transactions for later use can be considered along with “Audit Logging”.

Status

Implementation Ongoing

Links

• Associated with Sourceforge forum thread: http://sourceforge.net/projects/openemr/forums/forum/202506/topic/3474159