markleeds wrote on Saturday, October 06, 2007:
I guess that the policy is that form data can be altered at any time.
Should this be changed?
Maybe it should be like the billing table. Do not alter or delete, just save new data and set activity=0 of ‘deleted/altered’ entry.
Not that every form table should have an activity field. This could be in the forms table.
sunsetsystems wrote on Saturday, October 06, 2007:
I agree. Altering the patient record with no audit trail is not good. This can be addressed in an ugly way with suitable backup procedures, but as you say it’s much better to save the old data as “inactive” (including timestamps).
Looks like most forms already have a timestamp and an activity flag, though the activity flags seem to be mostly unused. My initial poorly-considered thoughts regarding design are:
(1) Let the forms table point only to the currently active forms.
(2) Add pid and encounter, where missing, to existing form_* tables, so that detaching them from the forms table does not lose critical information.
(3) Implement suitable logic moving forward, and change logic for old forms as we are able to get to it.
One thing that would need special attention is the "date" timestamp in form_encounter, as this is actually the encounter date and not a creation timestamp.
This may not be the most perfect design, but it seems workable without being unduly disruptive to existing code. One thing I have learned is that grandiose plans never get implemented. 
drbowen wrote on Saturday, October 06, 2007:
Dear Mark and Rod:
I have never liked the existing form policy. It is horribly insecure and improving the audit trail is definitely desirable. In my mind there ought to be two "views". The current active view and a view that shows all revisions. The usual practitioner will almost always want to see the current active "view". The database administrator / office manager show be able to "view" all versions of the audit trail, the original version, any edits that occur after "authorization", when the edits occurred, and who created the edits.
There should be a limited period where all edits during the initial creation should be "free" with no audit trail. After the form is in its final format and gets "authorized" further edits need to show the revision history with date:time stamps and user that initiated the change.
For HIPPA compliance, edits that occur after the date of creation, need to be logged with a narrative reason for the edit to occur. A valid reason would be a request by the patient that the medical information be corrected.
Proving that the medical record has not been altered becomes important in legal cases where a sharp opposing attorney might want proof that the record had not been altered. If this cannot be proven, then the attorney and plaintiff could allege that certain statements had been made and that they had been removed from the medical record. This would then be very bad for a defending physician and practice. The plaintiff could claim that record was altered to hide damaging information. The Physician and Practice would be hard pressed to prove that this was not the case. A late entry / modification of the record is always very damaging in court.
I have seen a number questions and answers about OpenEMR in this forum and in others that presumed the data can not be altered except by using OpenEMR as is it designed. We have discussed in the past removing PHPMyAdmin. Simply removing PHPMyAdmin does not prevent a database admin from adding PHPMyAdmin to OpenEMR as an addon and then manipulating the data or by directly accessing the data using SQL commands from the mysql command line.
Herb Horst (of GnuMed) has proposed a way of solving this problem:
http://www.gnumed.net/gnotary/tampering.html
http://www.gnumed.net/gnotary/methods.html
His method may be a bit cumbersome for our purposes, however it should be easy to run a md5sum on the original version of a forms content and the md5sum can be stored as a separate field. Subsequent edits would then have another md5sum stored with each revision of the form.
I think going to the trouble of forging a date:time stamp and matching the original md5sum is way beyond the skills of any doctor that I know. Simply recording an md5sum digest of the forms content and providing evidence that the md5sum is unaltered, would be adequate proof for most courts.
In terms of Rod’s Simplicity Score I agree. Complex, grandiose plans never come to fruition.
What I am am proposing is that the normal user would have access only to the "current version" with activity of 1. Normal printing would occur on forms with an activity level of 1.
Under the administrative section, the database administrator (and possibly others as granted in the privileges under phpGACL) would have the ability to view all versions of the form (including date:time stamp of the edit, editing user) with a log entry describing why an edit was made. Edits on old "authorized" forms would require administrative access to make.
Add an additional field to the table for each form to hold an md5sum digest of the form’s content at the time it is authorized.
A way to print all versions including the md5sums to prove that the forms had not been altered outside the context of the OpenEMR program. Administrative access would be required to print these older versions.
I don’t think this is too cumbersome to implement and hopefully will pass Rod’s Simplicity Score. The flip side of this is that these changes are not a luxury but are required for full HIPPA compliance.
Sincerely,
Sam Bowen, MD
drbowen wrote on Saturday, October 06, 2007:
As a separate but equally important issue. Some forms contain exquisitely sensitive health information. I have no method to lock this type of form information "for my eyes only". As an example:
My wife works in the practice with me as a physician assistant and currently has access to all the forms regardless of their content. We go to the same church. My wife is on excellent terms with a number of other ladies in the church. A man goes on a trip and has an inappropriate relationship while he is away. He comes to me. He pays in cash to have certain tests run and does not want have his insurance billed. Neither does he want a bill showing up at his house. He does not want any one to have access to the medical record that I am generating, not even after his death. Later he approaches me to expunge the record so that it can not be discovered.
Some time later. The same man comes in for evaluation of a cold. He is seen by my wife in her capacity as a physician assistant. She reviews the old record that is “For my eyes only”. Now my wife is aware of a situation that she was specifically never supposed to find out about. While she does not and never would reveal this information, it does change how she interacts with this man and her friend, the man’s wife.
Currently, my only option is to 1) Hope I get lucky that the material is not compromised. 2) Create a separate medical record in a directory that only I have access to and provide access to the office manager in the event of my incapacitation.
This a significant deficit that needs to addressed.
Perhaps the simplest solution is a separate field on the form called "private". This can be toggled on by the creator of the form. If the "private" flag is on then the only user who can view the form is the user who created of the form. This would also be simple to implement.
Of course there still needs to be an administrative escape. If the practitioner leaves the practice, dies or becomes incapacitated, the database administrator / manager can still access this record. Again this should be dome from the administrative area. Also access of this type of record needs to be logged just as an edit is logged.
Sincerely,
Sam Bowen, MD
drbowen wrote on Saturday, October 06, 2007:
Part Three,
Personally, I am shocked that any table would not contain the pid. Perhaps I am still too new to this but how could anyone expect to maintain database referential integrity without including the pid?
The existing forms hopefully could be made more uniform in their content and function.
All forms will include the following:
pid
timestamp
activity flag
encounter
md5sum
privacy flag
This also means improving the location of these fields hopefully at the front of the tables to improve uniformity. Addition of the xml() for multilanguage capacity for all forms.
Modification of Mark Leeds formscript to make sure all new forms have at least these fields so that the pid, timestamp, activity flag, encounter, md5sum, privacy flag, multilanguage xml() works in a similar fashion for all forms.
It would be great if the formscript was rewritten in PHP to allow it to become the standard way forms are added to OpenEMR.
Sincerely,
Sam Bowen, MD
sunsetsystems wrote on Saturday, October 06, 2007:
Sam, we actually do have access control support for encounters that are unusually sensitive (or unusually non-sensitive). This is a fairly new feature.
In order to use it, you need an ACO section in phpGACL (or via equivalent customization of acl.inc) called "sensitivities". This section would contain ACOs (Access Control Objects) with names like "Normal", "High" and "Low". Then you would assign the associated permissions to users or groups of users, depending on their role.
Once the sensitivities section and its ACOs are defined, they will be selectable in the New Encounter form. And of course you can get creative with your own definitions of sensitivities, such as "Dr. Bowen Only".
By the way Brady Miller recently contributed some updates to acl_setup.php, as well as an upgrade script called acl_upgrade.php) which add some sample ACO items to phpGACL for this. These are in CVS.
See the tail end of library/acl.inc for more comments about this.
drbowen wrote on Saturday, October 06, 2007:
I think I understand.
The problem I have is that that occasionally I have an single object that should be available to the creator only. I see this as an attribute of this single object. The rest of the objects in the container (other forms) would have normal or low sensitivity.
To me, the attribute associated with this level of sensitivity is the content of the form and is most often associated at most one sometimes two office visits. Establishing a separate ACO group policy for what amounts to a single problem visit seems to be
If I understand you correctly, I would have to a high sensitivity ACO requestor group that would contain the practitioner, the database admin, and the practice manager. To accomplish this I would have to systematically set up a group for each separate practitioner to accomplish this.
Using phpGACL is not intuitive especially for new admins / new users. The situation I am describing comes up in all practices. The default installation needs to have the ability to do this for OpenEMR to be competitive. It should be "already available" and not require extra configuration.
Sam Bowen
sunsetsystems wrote on Sunday, October 07, 2007:
OK, well, what we have now is at the encounter level and not the form level. Many should find it useful. There’s nothing to prevent makers of individual forms from doing a similar thing at the form level, or from making a special ACO that is treated as “for the originating doctor’s eyes only”.
sunsetsystems wrote on Sunday, October 07, 2007:
The form_* tables can get away with omitting pid and encounter because they are accessed via the forms table, which does have these. However they usually include the pid anyway.
andres_paglayan wrote on Monday, October 08, 2007:
the only way to adress this is having a non-destructive system for data update
I’ll explain with an example,
if you are updating a record, isntead a new one is created and the old one depreciated, e.g. with an inactived at "time stamp" flag, then the new one, without the flag becames active.
For a state of the art EMR this should apply to everything, from any aspect of demographics to any aspect of data input.
markleeds wrote on Tuesday, October 09, 2007:
So we need time stamp, activity and md5 field. If done at the level of individual forms, it might cause problems with running sql updates for some people.
If we decide to do it in individual forms, I can make the change to formscript.pl easily for future forms.
If it is done in the forms table, I think it would work fine also.
Dr. Bowen, the md5 field is a great idea.
Andres, I agree with it applying to every aspect of the program.