5. Data Integrity

Owner of this task

ViCarePlus HealthCare IT Services & Support

6559, SpringPath Lane, San Jose, CA, USA

Website: http://www.vicareplus.com

Email: services@vicareplus.com

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
   
   Logging
   
   Concurrent Use

Since the first three features are taken care already in OpenEMR, this document talks about the use of checksums to maintain data integrity. 'Logging' and 'Concurrent Use' are considered as the separate tasks due to the complexity involved.

Types of EPHI to be considered for data integrity (checksum calculation)

a.Encounter

b.Prescription

c.Immunization

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

Proposed Solution

The functions which receives/processes the sql queries in sql.inc are 'sqlStatement', 'sqlInsert', 'sqlQuery' & 'sqlQ'

Note: Seems like DB calls are passed through the database in more ways [sql.inc, adodb etc]. More details would be added after some extensive analysis

For record insertion and updation, a new function named 'findChecksum' is called (after the 'mysql_query' call) in the above mentioned functions with two parameters (1. Table name 2. ID generated). Here, the checksum is calculated for the record that was inserted/updated. The following details are inserted into the 'checksum' (newly introduced) table.

a. Table Name

b. Record ID

c. Checksum

d. Timestamp

Whenever the record is displayed, a new function called 'checkIntegrity' is called. Here, the checksum for the current record is calculated and the same is compared with the already stored checksum (during insert/update). If both checksums doesn’t match (due to data corruption), the contents are displayed in RED color with the note “The information displayed in RED may not be 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.

This will help us to identify the data losses/modifications during accidental data corruptions such as bad disk sector.

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

Verification of the 'Data integrity' is ignored. The calculated checksum is stored in the audit log. The changes will be delivered as part of the audit logging.

Links

• Associated with Sourceforge forum thread: http://sourceforge.net/projects/openemr/forums/forum/202506/topic/3474159
• Certification Standards Recommendations : PRODUCT CERTIFICATION STANDARDS [1]