A workflow for Encounters

zhhealthcare wrote on Tuesday, February 22, 2011:

Guys
I have a client who needs the following feature: 
A patient comes in, he is seen by and associate who enters some encounter forms, then he is seen by another level who makes changes or edits encounter forms(all or some of them), and finally the “big kahuna” accepts or rejects them.  The levels could be many.

From whatever I have seen in OpenEMR so far there is not such option.

We plan to create a workflow section in which each practice/facility can set their workflow levels and authority by encounter.  Still fluid in the thinking stage. 

Any comments.

Shameem

jcahn2 wrote on Tuesday, February 22, 2011:

Shameem,
Another wrinkle here, is could a person at each level “lock” the note?  Could the higher level person edit or only append a “locked” note?
Jack

julialongtin wrote on Tuesday, February 22, 2011:

Brady: please stop me if I’m way out of line:

This sounds a bit like what i’m doing with the (still in review) signatures system… only you need more.

I’m mentioning this, to try and make sure we decide on good archetecture for these kinds of enhancements.

now, what my signatures system did/does, is you can have forms with signature fields. only once all the signature conditions are met, the form would show outside the encounter, like demographics or hisory. we concidered this to be the ‘active form’ of that type for a client.

our vision was to have forms that are in an encounter, but have not yet passed ‘signature’ be visible to the last person who edited it in their notes pane.

Now, what i was doing won’t work for you, because you seem to want multiple levels of ‘signed’ (i am done, send it to the next person). other than that, conceptually, it sounds like we be looking for a featureset that can fulfill both needs.

Julia Longtin

zhhealthcare wrote on Tuesday, February 22, 2011:

Julia
Glad that you posted here because I seem to have missed your work in the similar area. 

We already did something similar to what you are doing.  Here is the workflow of what we did. 

Related to individual forms in the encounter.
We can set several levels of signature capture for each form.
So let say and HPI is made by the junior doctor in the presence of the patient, the patient approves, it first takes the patient signature, then the doctor, then the senior doctor (all per levels set for each document)
Once the first signature (actual signature, not electronic) is attached to the document it becomes  a flat pdf.  From then on everyone can review it and counter sign it. 
If an edit needs to happen, then the form can be edited and a new pdf is created. the old one is in the system for history purposes.

So if you are trying to do something similar we could share notes. 

However in the current case, what we are trying to do is to take this workflow to the entire encounter.

Comments, suggestions, criticisms all welcome….

Jack, with regard to the lock, we should consider that as a feature too.

Regards
Shameem

julialongtin wrote on Tuesday, February 22, 2011:

how are you informing each individual in the chain that they are required to sign?

my system used a sql based ‘signatures’ table to allow us to apply rules like ‘client plus nurse OR doctor’.

what are you using for signature capture?

Yes, we should have stumbled on one anothers work before. all of my work is integrated into the code of the XML form generator, however, we have not had time to pull parts of that out of form generation, and back into openemr (my responsibility…)

Have you published any forms based on your form system?

zhhealthcare wrote on Tuesday, February 22, 2011:

Julia
When each user logs in, he will have a link on the left nav called documents to sign which will display the pending documents.  Much like the messages.

We are using a java applet and perl server side script, which we bought and not open source, for the signature capture.  It is only $25 per server  license and we thought it is better than having to spend time on developing it. It is due to this that we cannot contribute any form we have used it in. If someone can contribute the signature capture applet……………

Regards
Shameem

mukoya wrote on Tuesday, February 22, 2011:

One way I have seen some vendors approach it is to have a button for, say, “Submit for Senior Review” if longed in physician is grouped as “Junior Physician” or “Registrar”.

Each encounter record has to be verified before permanent record and only senior physicians are cleared to verify.

This preliminary visit record can be send to a specific physician e.g. chest physician, thus appearing in his “My Items” or to a pool of senior physicians appearing as “Items for Review” from which any senior physician can pick.

In current state of OEMR, this can be partly achieved though not in a very structured way.

Example:

Clerical staff enters demographics.
>
A nurse, if first visit, enters the history (or edits if necessary for subsequent visits). She also attaches any necessary documents e.g. radiology report, medical records etc. and takes vitals.
>
The first doctor reviews history, documents. He could even summarize history, say in a “Past Medical History” field of an encounter form. He takes his “History of Presenting Illness”, examines, and suggests a diagnosis, investigations and, maybe, prescription.
>
The Big guy then reviews all these and endorses with or without changes.

Other Considerations for OEMR.

Prescription/procedure order cannot be tagged as “Preliminary” and will therefore be indistinguishable from a “Final”. This may not be such a big problem as the patient will be directed to next office and will only be directed to pharmacy/procedure area after seeing the physician at the top of the chain, preventing performance/dispensation of “preliminary” procedures/prescriptions.

If procedure performer has access to clinical encounter notes, then he can view procedure status. This list can be altered to include “Preliminary”, “Verified” etc.

New statuses can be entered in the “Appointment Statuses” list e.g. “At Reception”, “On Level 1 Queue”, “In Level 1”, “On Level 2 Queue” etc. Each provider changes statuses appropriately on the calendar e.g. a level 1 provider changes patient status from “On Level 1 Queue” to “In Level 1” when client enters his office and then to “On Level 2 Queue” when patient leaves office to go to level two queue etc.

All physicians can then be updated in real time by refreshing calendar. This will need physicians to be allowed to view calendar for all providers and/or creation of “virtual providers” like “Diabetic Clinic”, “Room 6”, “Thomson Clinic Downtown Branch”, “Level 2 Physicians”  etc.

To make sure this works fine, one may need to play around with ACL.

About signatures, the user level security can be relied on to assume that if changes are made under a certain account, then its user/owner must have made the changes. However, it seems Brady, Julia, Shameem are taking it to a new exciting level!!

You can also make use of office notes and messages.

Hey, I am not a developer, so I am used to twisting software to suite my needs without having to code. This issue might be better fixed development.

Mukoya.

tmccormi wrote on Tuesday, February 22, 2011:

I have seen this demonstrated by a Dr in Houston (Charles Garcia).  It was not a signature, specifically, but it was a free form drawing and markup form using only HTML5 and java script on a touch screen monitor.   the base API would be applicable.  I have am trying to get his programmer to share it with us. They are willing, just busy, like everyone else.
-Tony

zhhealthcare wrote on Tuesday, February 22, 2011:

Let us try to clearly identify our goals here.

We are not trying to create workflow for accurate data entry for the demo, or history and such, which I think should be done through privileged users set by the ACL.

Signature capture though important is not a deal breaker for the workflow cycle because we can set status as approved, not approved, rejected et cetera.

What we are trying to do (either as a complete encounter or as individual form) is to set a review process in place.  Am I right?

Of the above we have set in place the individual forms.  What we may need to add here in the display of these forms in the encounter page is its status.  In the case of encounter based workflow then the encounter itself has to reflect the status and stage in the cycle. 

Regards

Shameem C Hameed
Z&H Healthcare Solutions, LLC.
2010 Corporate Ridge, Suite 700
McLean VA 22102

ph:  571-766-8074

tmccormi wrote on Tuesday, February 22, 2011:

A while back I proposed a method for creating a authorization chain at the user level.   Each user would be assigned one or more “supervisor users” that are required to signoff/authorize their encounters, etc.   If the user does not have a supervisor and DOES have authorization for ‘ALL’ then they are the top of a chain.
-Tony

bradymiller wrote on Wednesday, February 23, 2011:

hey,

I generally think of it in terms of intern, resident, attending levels of hierarchy. So the intern writes a note and ask the fellow and attending to sign it. Then the fellow signs it (usually adds addendum but can modify any part of note if needed). Then the attending signs it (usually adds addendum but can modify any part of note if needed). Once the user signs it that user can no longer modify the note, but can add an addendum. Once the Attending signs it, then the note is considered Authenticated. This mechanism can also then be used to forward notes just for review rather than signing.

Julia, could your mechanism handle the above (with mods of course; if above could be supported, then pretty much any situation could be supported)  If so, then better to get your signatures table in there sooner (rather than later). The nice thing about your mechanism also is it can support saving vs signing because it save multiple versions of the same note.

-brady

julialongtin wrote on Wednesday, February 23, 2011:

brady:

It sounds to me like we’re all clamoring for more ‘framework’ around the encounters system.

signature pad functionality (we all want it, i have something, but its windows-only, so i can’t even use it…)

The concept of ‘person having a queue of encounter forms to look at’. I want to accomplish this by adding the ability to link to an encounter form that needs editing from a note. it sounds like zhhealthcare has acomplished this by adding another queue next to notes…

The concept of “a form has been filled out past this point, route it to someone else”. this is conceptually similar to what i call ‘signatures’ below.

History style revision history. I don’t like losing edits.

The concept of “an encounter form is DONE being edited, promote it to ‘master’, and stop accepting edits”. i didn’t bother implementing “stop saving” for debuging reasons(which is easy), but have completed ‘a form fits all these conditions, make it visible outside the encounter’. I’m assuming I have everyone’s agreement that this is a good idea, and i should be comitting it. :slight_smile:

now, that last feature i named ‘the signatures system’, which i now consider a bad name, as it actually is a form promotion function. i just don’t have a good easy-to-understand analogy better than “when a form is signed properly, i promote it!”. signing via signature pads is something completely different.

Its something similar to what i’m understainding is the origional feature request that started this thread. we are talking about 5 things now.

I propose my signature table could be expanded to instead of returning a ‘TRUE’ or ‘FALSE’ , instead return a provider ID to route the form to, by sending a note, with a link that logs you into the encounter and into the form, to edit on it. i believe this would cover both the origional feature request, and what i’m doing.

This will require someone writing up an administration interface for handling ‘signatures’. I just haven’t done it, and don’t have the funding to put together ‘polish’ like that. Currently i’m behind on too much paying OpenEMR work to afford to commit to a project like this.

I can try to put together a better xmlformgen to spit out forms like this… But I’m too busy chasing money right now to commit to anything resembling the note enhancement, or an administrative interface for handling this table.

Julia Longtin

jcahn2 wrote on Wednesday, February 23, 2011:

Ahoy team.
There should be a concensus on the meanings of “signed”, “authenticated”, and “locked” which I believe is emerging here.  Also Julia, when a form is promoted from an encounter (to something else, perhaps a “visit”) would it still be found for future reference , cloning, etc under the encounter menu by date?
Thanks,          Jack

julialongtin wrote on Wednesday, February 23, 2011:

Jack,

Being promoted doesn’t change anything, except that now the ‘signed’ version of the form that is good enough to use becomes available with one click, from the left hand menu, like history.

you’re absolutely right, we should be defining our terms closer. Want to take a shot at it?

Julia Longtin

tmccormi wrote on Wednesday, February 23, 2011:

I thins this is a good proposal… -Tony

I propose my signature table could be expanded to instead of returning a ‘TRUE’
or ‘FALSE’ , instead return a provider ID to route the form to, by sending a
note, with a link that logs you into the encounter and into the form, to edit
on it. i believe this would cover both the original feature request, and what
i’m doing.

bradymiller wrote on Wednesday, February 23, 2011:

Agree with Tony (regarding Julia’s proposal),
Best way to begin working on this would be to commit the signature table along with a extremely simple form created by xmlformgenerator with signature. I suggest the form only have one text area (including the signature section) basically equivalent to another dictation form. Then can go from there.
-brady

sunsetsystems wrote on Thursday, April 21, 2011:

I take it not much has happened with this recently?

On a related note, I have a client wanting the simple ability to “lock” an encounter to protect against further changes.  Doing billing sort of does that on the coding side (Fee Sheet), but billing is not a clinical operation and also doesn’t affect the clinical forms.

So, looks like I need to design something for this but don’t want to mess up anyone’s work in progress.  Any comments?

Rod
www.sunsetsystems.com

zhhealthcare wrote on Saturday, April 23, 2011:

Rod
We did some work on this for a client who absconded without paying for it…… ha ha ha … Now I’ve learned that it is better to be a jerk when it comes to payments. I digress…  Would you like to see a demo so that you can decide if this is what you have in mind?

Shameem

sunsetsystems wrote on Saturday, April 23, 2011:

Shameem, if you could just briefly describe it that would surely be of general interest.

In the meantime it looks like what the client really wants is to remove the ability to change an existing encounter form.  What I may do is add a “global” option for that, and then let individual forms decide how to implement it.  Still mulling this over.

Rod
www.sunsetsystems.com

mukoya wrote on Saturday, April 23, 2011:

This is an invaluable functionality to some practices especially for medico-legal reasons. As proposed before on this forum, if one must add info, it can be done as a separate note appended to the original without changing the original or the original can be saved as version 1 and edited version, with a date and editor (and reason for editing) as a subsequent version.

Alternatively, to reduce editing, forms can be locked so many hours after signing e.g 6 hours.

Waiting for Shameem’s response.

Mukoya.