Notifications
Clear all
Topic starter
Good afternoon, just wanting to reach out to see if anyone else has experienced some strange behavior of the HTML Family History form. It has been reported that randomly, when staff complete the Family history form, either by adding new information or checking the "Family history reviewed in Encounter" checkbox and moves on to other forms, the information doesn't populate into the document text. They have to either go back to the form and then click on the Text button, sometimes having to do this several times to get it to populate the document text.
Has anyone seen this behavior? It is very random and as of yet, have not found a pattern to it. We are currently on CPS 12.3.2.
Thanks,
Linda
Posted : January 6, 2020 9:25 am
Not specifically with that form, but in general with custom HTML form translation I did see that. I ended up moving the text translation of the form to a text component to avoid the issue. It did seem pretty random, if I remember correctly it seemed to affect about 1 in 20 documents. I never spent the time to try to nail down what the issue was though.
Posted : January 7, 2020 12:53 am
Linda,
there is a known issue related to the HTML forms. I have been able to replicate it with our own custom developed HTML forms as well. The issue I believe has to do with the text translation engine and how it gets triggered when a form is interacted with. For example, if you click inside a text entry field on an HTML form, enter some information, and then advance to another form immediately (i.e. by clicking on the form in the navigation tree), then the content that was just entered in the text entry field will not appear in the text translation. In contrast, if you click inside a text entry field on an HTML form, enter some information, and then interact with another control on the form, the text translation is triggered and the information will appear in the note. It appears to be a random behavior because it is impossible to replicate how every provider interacts with an HTML form. We actually hacked the family history HTML form to trigger the text translation every time a key was depressed on the keyboard to try and avoid this problem. That has solved our problem for the most part, but it adds overhead to the form because the text translation routine is getting fired with every key press. We tried to make it where the text translation function would fire every time a control on the form lost focus (this would be the most efficient strategy), but unless you can train your providers to always tab out of a text entry control or click on a blank area of the HTML form before advancing to another form, then you could still lose information.
Posted : January 7, 2020 1:04 am
Topic starter
By chance did you report this behavior to Athena?
Linda
Posted : January 13, 2020 7:45 am
Yes. They are very aware of the issue. It is supposed to be remedied by the upcoming version of CPS (version 20) when they move to a client that's based on Chromium rather than Internet Explorer. #fingerscrossed
Posted : January 13, 2020 9:30 am
