Request for Comments on proposed changes

OpenEMR Development
1

mbrody wrote on Sunday, April 27, 2008:

I have started coding changes that I feel are improvements to the current code.  I wear two hats, I spend half my time practicing medicine, and the other half writing computer code.  There are enhancements I would like to implement based upon each of my hats.

This set of suggested enhancements is based upon my ‘hat’ as a doctor.  I will explain why I feel they are an improvement first.

Currently OpenEMR allows editing of notes after the date they are first entered, and the database reflects the date the note was last updated, not the date the original note was created.  I see this as an issue from a medical / legal perspective.  The program allows me to edit a note after it is completed and the program does not record what the original note was.  This can create all sorts of issues if I am sued and the issue of ‘doctoring’ my records comes up.   Once a note is saved, I believe it needs to be ‘locked’  (yeah ok  anybody can go into phpmyadmin and doctor the record, but the basic php code of the program should not allow this).

To accomplish this, I have played with the ‘Speech Dictation’  Encounter forms.  In my upgrade, once a note is entered, it is not editable via OpenEMR.  I have changed the “Additional Notes” to become “Addendum”,  and rather than appear to the right of the original note, the addendum is appended to the orignial note and the date of the addendum, and user who made the Addendum is automatically inserted into the Addendum.

The other issue I have addressed in my changes is the ability to easily print out the notes for a specific encounter.  This is important because there are times when I get a letter from an insurance company asking for copies of the notes from a patient for specific dates of service, or the patient asks for copies of their records to be forwarded to another doctor (when I refer a patient).

I have added in a feature that will print out the note as a pdf file.

To view my changes you can visit:
http://www.tldsystems.com/OpenEMR3
Username  = admin
Password = soccer

You can create a new patient, or use the one I already have in the system (George Bush).

I have also added in a bunch of Podiatry Specific templates (you will see them at the bottom of the list of encounter forms)  they are all based upon the Speech Dictation template.  Use any of them to create an encounter note for the patient and then make addendums, print them etc.

Please let me know what you think of my ideas for changes to the program and if you feel they are enhancements.   I think they are but since I am a cohort of 1, that has no great significance.  If you feel these enhance the code I will send them to Rod for inclusion in the code.

Thanks for looking.

FYI the following changes were made to the code in this version:

New Files in the interface directory.

forms/dictation/print.php
         causes the encounter to be printed as a pdf.

patient_file/encounter/print_form.php
         links to print.php

forms/dictation/fpdf.php
        support for pdf printing

forms/helvicicab.php
        support for pdf printing

forms/viral_wart
        and many other templates.  These templates automatically include the system date, and the name of the user into the template.  These data elements are needed in the encounter info to support printing of the encounter in a form that can be sent to insurance companies and other entities when medical records are requested.

Mofidied files

patient_file/encounter/forms.php 
    to add in a link to patient_file/encounter/print_form.php
    the view form has been modified to become add an addendum.  The original note should not be editable.  So the link name has been changed appropriately.

  
forms/dictation/view.php
    the ability to edit the encounter has been removed this is to make the program more compliant with CCHIT standards.  The “additional notes has been renamed “Addendum”  for additional changes see save.php notes

forms/dictation/save.php
   when an addendum is made, it is appended to the end of the note, and the date of the addendum, the patients name and the name of the user who made the addendum is added to the note automatically.  The date in the database is NOT reset, the db retains the date of the original note. 

Modified data tables

   Registry to support the new templates.

2

cfapress wrote on Monday, April 28, 2008:

Interesting work.

I completely agree with your notes about OpenEMR lacking some accountability and change tracking. In the latest CVS I’ve made some changes at the appointment level regarding the deletion of appointments. It’s not as detailed as what you’ve done. I feel the ideas and work you have done should be incorporated into future version.

I did find a bug though. When look at George Bush’s encounters some will Print (into a PDF) and some will not (get a blank window).

Specifically the 1st one will print, but the second one with SOAP will not.

Jason

3

mbrody wrote on Monday, April 28, 2008:

No Jason, that is not a bug.

I only wrote the print routine for the Speech Dictation so far.  I am waiting for ‘feedback’ from the other devs and if the consesus is that this is direction the group wants to move in, I will write print routines for each of the existing templates. 

I used Speech Dictation as the first since it is free form text and does not use tables or other special formatting features and only has one data field that is used in the output …  ie the easiset one to use.

Michael

4

sunsetsystems wrote on Monday, April 28, 2008:

Michael, I’m pleased that you are working in this area.

I’m not sure about your method of maintaining changes.  Consider the more complex forms, where there is a lot more than just a text area.  I’d suggest maintaining multiple copies of the row in the form_whatever table for each instance of the note, so that there would be multiple rows, each distinguished by a timestamp or version number.  Then you’d probably also want some mechanism to see a history of these things, with the ability to view an old version.

I did something a bit like this with insurance, so that the insurance_data table now includes past versions of insurance data for each patient.  It was a pretty easy approach that was not very invasive.

Perhaps you’ve already thought of that?

Rod
www.sunsetsystems.com

5

drbowen wrote on Monday, April 28, 2008:

Dear Michael,

This has been much discussed about how the existing system needs to be changed in the way you have outlined above.  If you look back, there have been relatively extensive discussions concerning this.  We all agree that something needs to be done.

I like Rod’s idea.  In the past we have all felt that there needs to be an audit trail of changes.  When the audit trail begins has been under discussion.  In my mind the practitioner should be able to make changes until the note is “authorized” at which point it is locked with no further “free edits”.

Subsequent edits should be stored with a few of extra fields.  The first is an MD5 sum of the note to help verify authenticity of the state of the note at the time of creation.  The second field would the reason the edit was being made.  Third a date time stamp of the edit.  As you point out the original date time stamp of creation should remain unaltered.

MD5 sums cam be faked but they take a lot of trouble to do so.  I think the ability to get to the phpmyadmin should only exist the the administration section and only available to the database administrator.

Per HIPPA requirements, any subsequent edits needs to logged, with the date time, who made the edit, and why it was done.

These edits could be assigned to administrators through the phpgacl.  They who should not have direct access to phpmyadmin.

Sincerely,

Sam Bowen, MD

6

mbrody wrote on Tuesday, April 29, 2008:

Well you are getting a bit ahead of me there. 

After I finish making the various templates printable in pdf format, I envision createing the following set of ‘permissions’

Each note would have a new fields

signiture
co signiture required (T/F)
co signiture.

users would have a new field
status - either primary or dependent.

When a note is written by a dependent provider the value of the co sig required would be true.

when a note is signed, it would be locked and not editable

unsigned notes would be flagged for users
uncosigned notes would be flagged and primary providers would have them flagged.

My plan was to allow an addendum of free form text to be appended to any note.  There in prose, corrections could be made with an explanation of why the correction.  I feel that any changes after a note is signed should be accomponied by prose as to why the note was changed, justifying the change.  It makes for a much better medical record than just a corrected value in a table with a time / date stamp. This would involve additional blob field to each note type for the addendum, and a tool to add in the addendum data.

Later on we could allow a strike through of text in the original note with a time / date stamp of the strike through and the addendum would explain the strike through.

These changes are similar to how written medical records have been treated.  But like all projects I want to approach this in a step wise method. 

Phase 1 get pdf printing for all notes implemented and turn off editing after they are originally entered.

Phase 2 - add in an electronic sig feature and turn on editing until the note is signed then turn it off.  Since the code already has the ‘editing on’ feature, and i will be implemeting the ‘editing off’ feature this would be a simple if statement on which form of display to call.  The Electronic Signiture would be a form of an Addendum.

Phase 3 - add in a co-sign feature so that providers who need to co-sign dependent practitioners can do so. The Co Sign would be in the form of an Addendum so that the supervising provider could add in their own notes. 

Phase 4 - adding a new template type - consultation, this would be used in multi specialty groups.  This would allow a referring doctor to add in an additional co-signiture to a consultation report indicating that they have read the report with their own comments.

Please note I am not providing a time frame since I do my coding for this on weekends and evenings, though I do hope to have the pdf printing feature for all existing templates completed by July.

As far as adding additional tools such as checksum to prevent or detect modification of the database, since the code is open source, any decent computer programmer would be able to look at the code, and circumvent those measures.  Therefore I am unsure of the value of those programming measures to allow a doctor to better defend the veracity his records if necessary.  IMHO a tool that provides automated db backup to a data warehouse facility that would give the user third party verification of his db is a better way to go in this case, and just modifying the user interface to not allow accidental edits of the original note would be sufficient. 

There may have been significant discussion of this in forums prior to my becoming involved in using this program, and I admin I have not gone throug the forums very thoroughly…  but I think this is an issue that needs thorough discussion before detailed back end data verification is built in to the program. 

For the moment my personal solution will be to make a cd of the db backup sealing it in an envelope and once a month mailing that to my personal attorney, who can present it at trial if necessary.  My form of third party verification (yeah I may be a bit paranoid but I have seen too many stupid lawsuits luckily I have not been on the receiving end of one yet).

7

mbrody wrote on Tuesday, April 29, 2008:

Jason,
The PDF print now is working for SOAP forms.  I expect to have one ready every other day.

Michael

8

rayaz wrote on Monday, March 02, 2009:

To Micheal Brody
Could you let me please download your new and changed files to enable encounter printing.
Thanks