Rod,
In broad strokes it goes like this. There are designations allocated to users. Each designation can be defined levels 1,2,3,4 etc. There is a workflow GUI where you can define which level is approved by which level so on and so forth. So if a document or form is prepared by one level then the next allocated level can either approve, reject or edit it.
There is more to explain and I wanted to do it in our time and make some documentation. We are not there yet. Since you asked I offer to show you a demo which shouldn’t take me ten minutes.
Again, it is still a work in progress as I need more complete features added to it before it comes in to the community.
Has there been any progress on this? I have our worthless billing company telling us that we have to lock/close/disallow editing/ of a soap note when it is completed. Basically they want the NP or Doc to mark it as being completed and then if there are any changes that need done they have to put in another soap note as an addendum to the original.
Probably if we can just make it simple for now and add the bells and whistles later. What is important is at the end of the exam the signing doctor has to sign to approve the notes/orders. So, I guess, what is important is:
1. Locking the visit, a "locked by " message should show in the patient chart for the encounter. If somebody else need to add annotations then just walk to the user who has it locked and ask them to free it up (its a small world). If the user who locked it up left it locked for some reason, then make some feature to get it unlocked with some accountability automatically recorded by the EMR; example - forcefully unlocked by on .
2. Give the signing doctor the privilege of being able to sign a document and close it (uneditable). If they need to re-open it then they need to make an “encounter addendum”.
Ahoy JP,
I feel signing off a note should lock only the portion of the note completed by the particular clinician. If you wanted e.g. the nurse could sign off on the vital signs. The doctor could alter them with an addendum. The doctor could sign off his note and later addend the note with some fact that he/she recalls or perhaps adding lab followup, etc. All entries are logged for date and time. These could be stored hidden or could become a part of the final note (which is very distracting when I have had notes from consultants that include this garbage). A signature should suffice to indicate a note cannot be altered without stating it is “locked” per se. N.B. the patient also will have the right and the opportunity to addend the medical record after reviewing the entries. Requiring one to track down the original clinician who locked the note in order to make further entries will be quite a handicap to record keeping.
Jack Cahn MD oemr.org BOD
Alfonso,
I have been working on a revamped clinical documentation interface which includes a feature where by when an author is ready to “sign off” on their note, they are prompted for their password. The document is then marked as locked and can no longer be altered. I also generate a hash code from the document so that I can determine if somehow the document is altered from it’s state at the time it is signed.
If folks are interested in a demo, I would be happy to point you to a URL privately. I don’t want to post the URL publicly as I don’t want my server getting hammered.
All of the code for this is shared on github.
-Kevin Yeh
I was asking about signatures in another thread and did not see this one. Would the Drawbox plugin be any help on the signature issue since it is open source?
So, when will a consensus be made as to how an encounter’s workflow should work ? I’ve been dying to see a mechanism to “close an encounter”. I see this issue pop up every now and then. Please consider this.
Can someone show me how to create a system that replicates the Report generation (History | Report | Documents | Transactions | Issues menu) the link from the top of the Patient Demographics ? I want to place an on-click button on a provider approval encounter form that pacakges all the patient information regarding the patient - checks all the boxes that can be chosen including family history, medications, allergies, present and previous encounter, etc. then dumps the report onto a pdf file on the database and shows it on the provider approval encounter form as a link.
The idea here is once the provider approves the current encounter, he must have reviewed and read all the past medical information about the patient including the present encounter and locks all of that information on a pdf file.