Welcome to the NEW CHUG— your ultimate destination for cutting-edge insights and discussions at the intersection of healthcare and technology.

Our platform is dedicated to exploring the dynamic landscape of healthcare technology, empowering professionals, enthusiasts, and innovators alike with the knowledge and resources to navigate the rapidly evolving field.

From telemedicine revolutionizing patient care to the transformative potential of artificial intelligence in diagnostics, we delve into a myriad of topics shaping the future of healthcare delivery. Whether you’re a seasoned healthcare IT professional, an aspiring entrepreneur in the digital health space, or simply curious about the latest innovations, our curated content, expert interviews, and thought-provoking articles provide a comprehensive exploration of healthcare technology’s most pressing issues.

Join us as we navigate the forefront of innovation, driving forward the transformation of healthcare for a healthier, more connected world.

Have questions or suggestions? Please use the contact button below.

Notifications

Clear all

New Rx Text Translation when using HTML Prescription Form

MEL, SQL, Oracle

Last Post by Anonymous 1 second ago

3 Posts

2 Users

0 Reactions

62 Views

RSS

virtualHITman

(@virtualhitman)

Posts: 319

Reputable Member

Topic starter

We have a provider that reports that when using the HTML Prescription form, the text translation that should appear in the note (displaying the new Rx details) does not work consistently. About 5 -10% of the time, when they use this form, no text translation will appear displaying the newly prescribed meds. This seems to be a cut and dry workflow issue, but we have not been able to replicate the behavior. Has anyone else experienced this issue, and if so, have you come up with a workaround to have the text translation work consistently? I have already brought up the idea of using a quick text to include the appropriate text translation in the note instead of relying on the form, but that would require the provider to manually remove the Prescription form from the encounter template to keep the text translation from duplicating in the note. Because of that, the provider wasn't keen on the idea. In their words, "if it can work properly 90+ % of the time, it should be able to work all of the time." While I see their point, I have no control over GE's form, and I have no way of policing the provider's workflow. Any suggestions welcomed.

Thanks in advance,

Greg

Posted : March 12, 2018 1:50 am

gibsonmi

(@gibsonmi)

Posts: 827

Prominent Member

I am curious to hear what GE's response to this is. I found it very odd that with the new HTML forms they built for 12.3, they went back to using text components for text translations rather than using the HTML translation themselves. I found in a custom form I built that we had about the same thing, 5-10% where no matter what I did I could not get the translation to come up. If I started a new encounter and documented the same thing, and messed around and tried to break it, I couldn't do it. The workaround was to follow GE's lead and place the text translation in a text component.

I would not be surprised if the GE prescription form had the same issue, although I haven't had any reports of it. The 'Fix' for the prescription form would be to do the same thing I suppose. There is an HTML example form that inserts a text component on open that you could copy, and you would have to comment out the javascript that writes the text translation, that should be pretty easy to find. But like I said I would like to hear what GE has to say about this.

Posted : March 12, 2018 2:18 am

virtualHITman

(@virtualhitman)

Posts: 319

Reputable Member

Topic starter

Mike, thanks for the response. I haven't had any issues with text translation with the HTML forms I have developed, but I have noticed that if you enter text into a text field or multi-line edit control on GE's HTML forms (including the Social and Family Hx forms provided by GE) in version 12.2.x, and then navigate to another form without first clicking outside of the text-based control that you just entered information into, then the information entered will not translate to the note. This obviously has to do with the fact that there must be some kind of trigger for javascript to execute the text translation function. I suspect something like this might be happening with this particular provider and their use of the Prescription form. Of course there is no way for me to figure out what is going on unless their workflow can be recorded. I believe this is something GE will need to address as they migrate there content over to HTML. It is my experience (generally speaking) that providers care more about what the finished note looks like than what discrete data is being captured. After all, that's the document that they are attaching their signature to and I understand their frustration when new HTML forms don't behave the way the old style CCC forms behaved (i.e. just enter text and it magically appears in the text translation; no saving or clicking outside of a form control necessary to commit the data). Based on your experience, it sounds like GE may be taking a different approach to text translation in version 12.3 (albeit a workaround) and I would be interested in connecting sometime to discuss your experiences. We are looking at updating to 12.3.x later this year, so it would be nice to know what to expect with regards to our custom content. I'm also very interested in connecting with others who are creating content in HTML as there aren't very many of us out there at this point. If you have any interest, send me an email and we will schedule a time to connect offline.

Cheers,

Greg

Posted : March 13, 2018 2:42 am

Share:

24 Forums
9,940 Topics
39.9 K Posts
0 Online
6,470 Members

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed

Powered by wpForo Powered by wpForo version 2.4.0