I think I know the answer to this already but I figued I would ask anyway. Is there a way to create a note close or note sign handler similarly to the way you can create a page close handler on an individual form?
Basically, can you prevent a doctor from signing or placing a note on hold if certain sections of the note are not filled out?
Signing - No. Several processes are invoked to sign a note and no data symbol exists currently to prohibit it the action. It would be highly difficult to create one external of the native EMR code as well.
On hold? Yes, at the data entry point form using close page.
I personally have a like-hate relationship with close page. As an administrator, I liked it, as a clinician, I hate it, and as a content engineer/manager, I despise it.
I liked it because it ensured that all the boxes were checked and that meant the checks were coming in and not going out. - The administrator in me
I hated it because I often need to look up something on a form that also has the handler but I am not ready to enter valid data in that field, forcing me to either enter trash data to get out of the chart or open task manager and kill the EMR process. - the clinician in me
I despised it because when running reports, I would see so much trash that never got 'fixed' because the user forgot to go back and correct it later on (no reminder!). End result BAD DATA not to mention hung licenses. - the engineer in me
So, if you are planning on using close page, seriously consider using a warning with an option to bypass vs. forcing with no opt out. This will allow the user to actually use the EMR to care for patients, not just enter data. Warnings earn more accurate information in the long run.
My favorite is the user yesno(Would you like to enter required info now?) where a 'yes' takes them back to the spot while a 'no' does nothing. I typically place this on the last form I know the provider uses (i.e Assessment/Plan) as well, giving them one last reminder if the information is not present. Using 'get form list' and a series of checks, you can dynamically expand the check as needed. 🙂
I have actually had this discussion quite often regarding 'required' data elements. The first time I embedded these into a form, I was so happy and content, until the angry phone calls from users. They (similar to Lee's comments) needed to lookup something or get out of the screen for a moment, that the hard rule created headaches.
I now use the soft close rules - or warnings - that certain fields should be completed. Not perfect from a data perspective since not every instance will have the field completed, but at least we are at 95% or better compliance and the data that exists is good.
We use close page handlers in our current configuration. I was looking for something that would evaluate all the data in all of the forms, even ones that were never opened, before a note is signed.
No 'global close page' exists, but you could come close to this by creating a function that evaluates the targeted obsterms and global* document variables. Using get_form_list, you could then 'bypass' sections of the function for forms that do not exist in the current update. You could then put the function call in a close page statement on the 'last form' a user uses (this form is required to be opened in order to invoke a close page routine). Since you would be working with globalized variables, you should be able to store the function in a library making it rather versatile and scalable, indeed.
Not exactly what you are looking for, but it gets you close.
* If working in VFE, to make a document variable 'global', check the box named 'Make available to other forms' in the item's properties dialogue. This check box only exists when document variable is the selected connection.
Unfortunately, the problem we are trying to solve is certain providers don't visit all of the forms in the note, they jump around so there is no "Last Form" in our situation. (our OV notes have ~20 different forms in them)
I think you may be misunderstanding my recommendation. What I am suggesting is that the code be placed on the one form all providers visit (i.e. assessment or plan or something similar). If written as I suggested, it would not require that they visit any other form in the update, just the one that is universally part of their normal update workflow. If such a form does not currently exist, you might want to evaluate your current content and identify where you could leverage a common build that funnels all providers into your snare. 🙂