drpwayne wrote on Wednesday, September 30, 2009:
Hi. I entered an encounter on 9/28 for a patient, with vital signs, review of systems, and physical exam. However I can still edit the findings today and I can’t find any way of "locking" the findings so that they can’t be altered. How are notes secured against subsequent modification?
Thank you.
bradymiller wrote on Thursday, October 01, 2009:
hey,
This would be a nice feature (does not exist yet), and shouldn’t be that time-consuming for somebody to program in (likely putting a ‘signed’ flag in the forms table and supporting it throughout the codebase). Then would also likely need a system to addendum the notes after signed; this is generally how emr’s behave that I have worked with. Does anybody know if a feature like this is gonna be included in the planned CCHIT changes?
-brady
sunsetsystems wrote on Thursday, October 01, 2009:
Changes via the Fee Sheet are already disabled after the encounter is billed. So one option might be to extend that policy to other areas of the code that can change encounters. Not sure if that is adequate, or if a separate flag is more appropriate.
drpwayne wrote on Thursday, October 01, 2009:
From the CCHIT certification documents:
> The system shall record the identity
> of each user contributing to a note
> and will associate the identity of
> each to his/her entire contribution to
> all versions of the note (from
> intermediate and final versions of the
> note).
>
> PC 01.11 PC FN 1. Access Control
> Authorship and Documentation The
> system shall provide the ability to
> identify the full content of a
> modified note, both the original
> content and the content resulting
> after any changes, corrections,
> clarifications, addenda, etc. to a
> finalized note, and retain amendments
> and corrections made to the patient’s
> document for edit trail.
>
> N Current requirement allows
> certification of EHRs that do not
> preserve the original (intermediate
> versions) documentation of a finalized
> note. Definition of terms for the
> Privacy recommendation: Edit Trail -
> when edits are made to finalized
> documentation that are part of the
> patient record - these types of
> changes are retained in the edit
> trail. Audit trail - refers to "behind
> the scenes" tracing of access which
> are Security criteria.
>
> PC.8a PC 01.12 PC FN 1. Access Control
> Authorship and Documentation The
> system shall record date and time, and
> display the identity of the user who
> addended or corrected a note, as well
> as the reason for the change
> (amendment).
I think the only reasonable way of handling this is to force the note to be finalized at some point. After it is finalized, an addendum can be made but nothing can be deleted.
The part where it becomes tricky is if part of the encounter is done by one person and another part by a second person. For example, what if a medical assistant does the review of systems and reviews the medication and allergy list, but then the clinician does the physical and the plan. These are all part of the same encounter. By CCHIT criteria, the medical assistant should be identified as the author of the review of systems, and the clinician the author of the physical and plan. It gets even trickier if the clinician corrects or otherwise modifies the review of systems that was originally taken by the medical assistant. Again by CCHIT standards, the original ROS should be preserved and the modifications performed by the clinician are then part of the audit trail - so even though the final encounter document includes only the final ROS, the audit trail must identify what the ROS looked like when the medical assistant prepared it. Personally I think that’s a little over the top .
bradymiller wrote on Thursday, October 01, 2009:
hey,
Probably better to have a separate granular flag (per form), that requires the user to sign (or finalize) it. Then only way to change it is by adding an addendum to it (to do this would require a new flag in forms and creation of a new new form titled ‘addendum’; these addendums could then be mapped it to their respective note note; could use this mechanism also when delete a note to place why deleted; ie "wrong patient"). When this is in place, could then think about allowing multiple signers (ie. NP, residents) of which the main physician or attending is allowed to modify the previously signed note by underlings, but changes are recorded in database; and when the main MD signs the note it is then fixed (of course can always add addendums).
Note the addendums also get signed, so can have multiple addendums per note.
Another issue is the encounter form itself; this doesn’t need to be signed/finalized, right?
So if go with this strategy,the first steps would be:
1) Add a sign/finalize flag to forms table
2) Add an addendum form (via traditional method or the LBF method maybe?)
3) Modify sourcecode for above to work. The sign/finalize button needs to send a verify prompt warning that it can’t be modified after signing… Some systems (the VA) actually have a separate signing password, but I always thought that was ridiculus and likely a VA bureaucracy thing.
-brady
whimmel wrote on Thursday, October 01, 2009:
brady,
What about creating a new "signed_forms" or similarly named table instead of just a column in "forms"? This would accommodate multiple signatures:
**form\_id** (int) FK to forms.id, <br>
**signed\_by** (int) FK to users.id, <br>
**signature\_type** (varchar) enum from list_options<br>
**date** (timestamp)
Where signature_type might show that it was signed by a PA vs. the MD. You’d insert a 2nd row in this table when the MD countersigns the note.
bradymiller wrote on Thursday, October 01, 2009:
Now we’re getting somewhere. Whimmel, your mechanism looks great. Would a flag(meaning actually signed) in there also be useful. For example, the NP/nurse signs it and could then request other co-signers (create the row with the flag off, so would show up in the MD message box to view and sign it). Also have another column for more functionality (ie. is this a co-sign or is this just a "hey, look at this message and officially record you looked at it"; this is nice way to send notes to other physicians/nurses and ensure they see it).
Rod, would it be best to make a traditional addendum form or leverage the LBP, since it’s simply one text box? Also, would this mechanism work with the LBP created forms?
Also good to start thinking about a default list of signature_types.
If just focus on the addendum technique (ie. no modifications, only allowed to add addendums), then above would seem to work nicely. It, of course, will get more complicated if allow modifications to forms; would be nice to think about this now to ensure what we choose would be compatible with this in the future.
Also, as an aside are all form_id’s unique? If not, then would need another column with the formdir or LBP name.
-brady
drpwayne wrote on Thursday, October 01, 2009:
One more point, let me know what you think about it.
I believe a note should be locked by the end of the day, even if the user does not sign it. So, for example, if I write a note on pt brady miller today, but don’t sign it, I should not be allowed to change it tomorrow or next week. "Not signing" should not be a way to get around the legal requirements of not altering notes.
The reason I would let a user leave a note unsigned until the end of the day is that it gives the user an opportunity to write a note and then modify it within a few minutes or hours. Let’s say I make an obvious typo, or after interviewing brady and writing my initial note, I call brady’s doc and ask for recent labs, which are then faxed to me and which I review a few hours later. I want to preserve the ability to write a sensible note with complete information. In a hospital setting, notes obviously have to be frozen as soon as they are written, but in an ambulatory setting, I think it is permissible to write notes later (think of dictation where someone dictates their notes at the end of the day. We don’t want to penalize people who type their own notes.)
In my current system, notes can be signed by the clinician, at which point the clinician can "unsign" the note that same day to correct typos or other errors, but nobody else can unsign the note, not even another clinician. And notes, when signed or unsigned, cannot be altered come the next day.
The security hole here, of course, is that if a user can change the date on the server, the user can modify an unsigned note. So perhaps a better way would be to "autosign" all unsigned notes at midnight.
- Peter
whimmel wrote on Thursday, October 01, 2009:
Don’t confuse **forms.id** with **forms.form\_id**. "id" is unique to forms, but form\_id is only unique to the form\_name.
bradymiller wrote on Thursday, October 01, 2009:
drpwayne,
I’ve never seen this function in any EMR I’ve used (probably used about 10 or so throughout training). Generally, I’ve been able to work on a note (or dictate a note), and then get all the time I need to save it as needed. Then when ready, sign it; the important part is that when you sign it, it gets permanently time stamped at the bottom of the note with the signer/position. I’m having a hard time figuring out why your system would force a sign? I’ve also never been able to unsign a note, when it’s signed that’s it; only way to modify is to add an addendum or call the admins to remove the note.
-brady
drpwayne wrote on Thursday, October 01, 2009:
Brady,
I think my malpractice carrier would have a lot of difficulty with my notes if I could edit my notes over an indefinite period of time before signing them. Example: I see Mrs. X who c/o heartburn made worse by climbing stairs or walking, and relieved by stopped and sitting down (yes. I’ve had referrals like this). I think it’s reflux and give her a PPI. The next week she is found dead. I realize I’ve made a major misdiagnosis and I go back and alter my note to say "Pt denies shortness of breath, exertional dyspnea or chest pain and says she can walk up hills and climb stairs without difficulty." Since the note was not signed there is no record (I think) of the original note, but in fact the patient took a copy of the encounter with her when she left. Now I’m in deep doo-doo, to put in mildly. Notes should be concurrent as much as possible with the service.
It may not be a requirement of OpenEMR, but I think it should be an option.
- Peter
sunsetsystems wrote on Thursday, October 01, 2009:
I think what might work better than locking out changes at any particular time is to maintain a history of changes. That way corrections can be applied at any time, but users are still accountable, and there are no odious restrictions. This should be do-able with relatively minor surgery on the code.
Also, Patient Notes might be useful, or adaptable, as a signoff system. They are already a capable interoffice messaging system whose entries are attached to patient records, so a practitioner could simply address a PN to another practitioner to request approval of entries for a visit.
bradymiller wrote on Thursday, October 01, 2009:
Agreed. Could make this an option; would be minor change to do this relative to the large undertaking of getting this sign/co-signing system in place. To avoid your situation above, emrs generally don’t let you make an official printed note unless signed. If not signed they either mark it as rough draft or some emr’s won’t allow printing until signed (An EMR that I have used that does allow printing unsigned notes stores every single save of the note with timestamp, so always have the trail).
bradymiller wrote on Thursday, October 01, 2009:
To clarify, my above message was in response to drpwayne’s note.
balanson wrote on Saturday, October 03, 2009:
I am a new member here. I downloaded the software and have ‘kicked the tires’ and I’m impressed with OpenEMR. Congrats to all involved and I hope I can contribute to the effort going forward.
On this particular topic, I think the issue is that once a document is digitally signed, it needs to be maintained unaltered, and be retrievable in it’s original form. There also needs to be some sort of assurance that it has not been altered outside of the application (i.e by directly changing the database via a mysql client or other method).
I would suggest that when a form or other electronic document is ‘signed’ it should be locked and a checksum (or other authentication value) be generated as part of the signature to ensure that it cannot be (easily) tampered with. If the form/document needs to be modified, a duplicate can be created, changes applied, then a new digital signature/checksum be applied to the modified form/document. This way changes are possible, they are well documented, and each version is retrievable…
drpwayne wrote on Saturday, October 03, 2009:
I don’t think it’s possible to prevent a user with enough MySQL sophistication and the appropriate privileges from altering a note outside of the application. The checksum sounds like a good idea but someone coming in from a MySQL command line can just as easily generate a new md5 checksum, with a command as simple as
UPDATE documents SET freeText='new replacement text",
checksum=md5(‘new replacement text’)
WHERE documentID=17765;
- Peter
whimmel wrote on Saturday, October 03, 2009:
You could use OpenSSL and generate public/private keys for each user. Then sign the note with the user’s private key and store the signature in another column. Only that user would know the passphrase. Each time the note is displayed, verify the signature against the public key. If someone made a change in MySQL, the signature wouldn’t match.
markleeds wrote on Monday, October 05, 2009:
Dr. Bowen once posted a link to an excellent article on this subject about the difficulties of developing a foolproof system for proving that records have not been altered. If I recall correctly, it involved something like printing out the result of a one way hash function on paper and having an attorney notarize it daily. The point of the article was that it is next to impossible to do this in such a way that has no loopholes.
If the EMR is maintained by a trusted company and the physician has no direct access to the database, this might not be as much of a problem. Then, the main issue is protecting the interface with appropriate protocols.
ideaman911 wrote on Tuesday, October 06, 2009:
Folks;
I presume that any system can be overcome by a knowledgeable person. Even twin towers, remember? That said, I also believe OpenEMR currently timestamps and user stamps every input once saved. How is that different from what you are describing above? As to when it "autosigns", that effectively happens as soon as a SAVE occurs. More critical may be the fact that you can write the History of Western Civilization, but if you forget to save, it is lost without a prompt!
As to who holds and their relative trust, you obviously don’t have a credit card balance. I think that most ultimate users will want to hold their own data rather than trusting it to someone who can go belly up without bothering to tell them. It happens. And OpenEMR was developed with stand-alone capability, so it is a selling feature, at least until Orwell the Optimist and HIPAA are overridden for "connectivity" and EHR.
My point is that we must as much as possible guard against presuming any way WE do something is the universe of possible ways of doing it with our software. As CCHIT has already demonstrated, it is incapable of dealing with the reality of home care in rural (non-fast internet capable) areas. Lets not design for exclusion.
I daresay most small providers will be far more trusting of their own users’ data than any central holder. That they will select a central holder anyway will say more about their internal confidence in their IT capabilities than the security of their data. And I agree with Dr. Bowen.
That all said, I believe an "electronic signature" is important, especially for Notes, SOAP, and any other open-ended text inputs. I do wonder where the threshold exists, though. Most of the database fields are capable of 255 chars. That’s a lot of text. Will each field have to be signed? Where does important end and ridiculous begin?
Joe Holzer Idea Man
http://www.holzerent.com
10 years later!!!
unfortunately for me. I leaped before I looked and now. I have egg on my face. Side note. The lock feature does not show up unless all the boxes are checked. If toggle lock is not selected, encounter lock is not an option.