I am having an issue where the provider documents an HPI and places the document on hold. In the DOCUMENTS view in the patient's chart, the preview window shows the HPI twice. They are in alternating colors (one translation is blue, one is green) and when you print, the translation appears twice. When you open the update, the translation is only in there once. There is no duplicate form component. Any idea on why this would happen????
The separate colors say that they are in two different forms. I think if it were a text component it would be red. There may be some MEL code triggering the extra translation that is being reset when the document goes on hold (I know I have coded things and didn't account for it being put on hold and obs terms/variables have gotten reset). Do they each have an HPI translation when they are loaded into empty updates separately?
Ken,
Is your HPI form an HTML form perchance? If so, there is a quirk with how Centricity renders text translation with HTML forms. Here are the conditions that I have found will cause the duplicate text translation.
- You have an HTML form in a multi-form encounter template which includes text translation
- There is a form (HTML or MEL form) in the encounter template that appears below the HTML form AND there is no text translation being generated by this form
When you have the scenario above, the text translation for the HTML form referenced in step 1 will fire twice and appear duplicated in the document. As you pointed out, you cannot see this duplication during an update (when on the "Text" tab), but if you put the document on hold or sign it, you can see the duplicated text translation in the document viewer.
To solve the problem, I typically do one of the following:
- Make sure the form below the HTML form will always have text translation (this can be a single period character or some other character that would be unnoticeable.
- Incorporate the data collection features of the form that has no text translation into the HTML form.
- Have the user remove the data collection form (the one that has no text translation) from the encounter template prior to signing the document.
Items 1 and 2 are obviously preferred because the last option would have to rely on the end user to remember to remove the problem form.
Hope this solves your problem.
Thank you! This is helpful!
Yes, the form that is creating duplicate text translation is an HTML form. However, the problem is somewhat "flipped" from your description. The text translation comes from the MEL form while the HTML form is for data collection and has no text translation. We have found that the duplication DOES NOT occur if the HTML form is the first form in the encounter template. However, I need functions in the MEL form to fire first in order to pull in certain observation values. In other words, once the document is created, the first form (the MEL form) is automatically launched. In that form, I have display fields which contain functions that need to fire. At the end of those, I used OPEN_FORM_COMP to launch the second form (the HTML form) because it also needs to launch.
If I could get the MEL form to fire off my functions without having to be opened first, it would solve the problem
Ken, I am sure I can help you with this if you wanted to take a look at it later today. It sounds like you need some functions to fire when the form loads. Based on your description, there might be a better way of accomplishing this and avoid the duplication issue as well. If you want to connect via Microsoft Teams or Zoom, I could possibly do it later this afternoon. Feel free to shoot me an email if you want to try and connect. I am available at 3:30pm today or tomorrow morning (EST).
Greg
Here is some additional information on duplicate text translations for HTML forms I received from the developer of Clinical Forge.
This is a known issue, and has been for a while. It is also, as you mentioned, not limited to Clinical Forge forms, but also affects the stock Prescriptions form and other HTML forms. This is fixed in v19 and v20, but is not slated for a fix in any 12.x versions unfortunately. ( I fought long and hard to get it fixed in 12.x, but to no avail…) Basically, to work around the issue, each HTML form needs to push something to the chart note if used.
Hi Greg, sorry for the delay in my response!! Thank you so much for the offer. After piecing together some information from you and from the others on the forum, we found that the translation issue was only occurring when the HTML form was in the second position. Once we moved it to third, it removed the duplicate translation. I have no idea why, but because it has no text translation, it doesn't matter too much!