I have started a crowd funding pledge process for the e-sign class. Take a look and make a pledge. This has been asked for many, many times. Will community support this project?
Glad to see this initiative. We will definitely contribute towards this effort. We would like to move away from save as PDF solution. As this is proving to be not a good solution in terms of dynamic note creation to send it to other physicians. I would like to get your thoughts on this.
Thanks Venkat. The save as PDF option, I think should be just an option. Once the form is implemented with the sign-off adding locking and amendments makes it a more usable process.
Thoughts from the audience on how to do amendments to a form would be interesting to hear. The last customer I worked with just wanted an “Amendment Notes” text box at the end of each form which would be the only thing that could be written too after a form is signed/locked.
Other models might be a standardized “form_amended_FORM-NAME” table that duplicates the original form an keeps a form_id pointer back to the original, or just has that text box with notes riding along instead of inside the original. That would only work for external forms, not LBF based ones though. Maybe LBF needs a ‘amendment-text’ datatype?
I think this is an essential feature. And, I thought that getting pledges using catincan was a great idea. I hope this model can be used to fund other projects. During the OpenEMR committee meeting, there was a great deal of interest in Kevin’s tab project. I think that he should also try to do this also. However, it seems to be falling flat.
If you are targeting users to fund this, perhaps you should also post in the “Users” forum. There are probably many users who won’t read the developer forum.
Albeit, if you had posted it in “Users” and not “Developers”, I might not have seen it–so, it needs to go in BOTH!
More ideally than an amendment text box, we could make a new note with the original “hidden” behind then new one so that it could be viewed if necessary by clicking something. If we accidentally document a large portion of the note incorrectly, or there are parts of the note that add data to a part of the database that triggers something else, like fulfilling a quality measure, the amendment notes won’t trigger/count for this quality measure.
When we choose to amend a document, it would be nice if it brought up the old form filled-in, and then we make changes as needed.
Hi All - we’ve crossed the mid-point and this is 55% Funded at $1,650 Pledged.
There are only 13 Days left!!
There must be a few more users and development vendors and re-branders out their that would like a standard digital signature process as part of the project!
Regarding Dr Kay’s post “When we choose to amend a document, it would be nice if it brought up the old form filled-in, and then we make changes as needed.”
Actually it does that now. If you edit and existing form, it loads the contents. When you change it the specific changes are logged in the audit log files. That’s part of the reason that “locking” could be considered not needed. ALL changes are logged and audit-able.
An “amendment”, in this case, is an Additional Note about the record, not a direct change of the original recorded data.
Oh, you’re correct! I hadn’t noticed that it works that way. Great!
I think, eventually, there needs to be a way to view the change history of a form that is viewable by us “mortals” who don’t know how to review audit log files, though. It would probably be a big project, but useful, especially if a provider ends up in court.
Good News a few more folks stepped up and the Pledge goal was reached! Thanks, so much for your support. We’ll start do the work right away and posting interim code as we go.
We will be starting the coding on this next week, which is mostly creating reference examples for various forms models and getting through code review. We had a few other projects on the books that came first.
Thanks for the support! It will be there very soon.
–Tony
updated the code to work with the new user/password formats
modularized the esign code: We grouped as much stuff as possible into the library/esign folder. There are still a couple lines that have to be added where it gets used, but that’s unavoidable.
removed the need for an unsigned signature to be on file: This was a gigantic pain, and we can’t believe we implemented it this way the first time around. Now it just spins up a new signature and signs it when the signature request is made.
added the new column to the registry table: This gives us the ability to move forward or backward (database to directory) from anywhere in the form process using the form directory and form id. We just manually added the values for the default forms, so we’ll need to figure out how to make that a more robust process. Currently the forms are only really findable by their directory location which was not reliable.
if esignature is turned on for encounters or individual tables, the signature log is displayed. If it’s turned off, the log is not displayed. Signatures are still in the database, just not displayed.
re-worked the
masking method and signature process. It’s one form now and everything has been refactored into a new ajax strategy. All esign calls to the server are handled via a dedicated esign javascript object which pairs with a dedicated ajax page that handles all incoming requests for eSign data. This gives us a really neat, compartmentalized structure and goes hand-in-hand with the modularized point we mentioned earlier.
Form “locking” logic implemented
At this point the signature process is working well we are working on an ammendment function.
We should be pushing a branch out for code review by Monday