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

EMR 9.12 Med update/Refill form crashes

Page 2 / 2 Prev

Trading Post

Last Post by Anonymous 1 second ago

19 Posts

12 Users

0 Reactions

220 Views

RSS

denabottoms

(@denabottoms)

Posts: 12

Eminent Member

Virence placed a script that resolved the issue with Error: 32785 Possibly too much data for field. Retry?" . Reach out to Virence or your VAR to have this placed. Once this has been done, the prescriptions that are in a document on hold, will now go through without issue. This has been confirmed by multiple clinicians at our sites.

Posted : January 3, 2019 4:45 am

gibsonmi

(@gibsonmi)

Posts: 827

Prominent Member

In Michigan this actually started happening to us a long time ago, about a year ago I think. GE didn't help much except give us the thumbs up on a solution we came up with ourselves. We applied the following trigger to the ERXRESPONSE table -
USE [DB_NAME] GO /*** Object: Trigger [dbo].[cus_ERXRESPONSE_INVALID_FID] Script Date: 1/11/2019 2:50:16 PM ***/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO

ALTER TRIGGER [dbo].[cus_ERXRESPONSE_INVALID_FID]
ON [dbo].[ERXRESPONSE]
FOR INSERT, UPDATE
AS
IF TRIGGER_NESTLEVEL() > 1
RETURN
BEGIN
IF (SELECT len(formularyId) FROM inserted)<10
BEGIN
RETURN
END

IF ((SELECT defaultplan FROM inserted)='N' OR (SELECT defaultplan FROM inserted) is NULL)
BEGIN
RETURN
END

UPDATE erxresponse SET defaultplan = 'N' WHERE AsycResponseId = (SELECT AsycResponseId FROM inserted)
END

It worked so well I forgot we even did it after awhile. I only recalled it after we found the script GE just posted that instead truncates the formularyId. If anyone wants to try this, it will not work in conjunction with the GE script, its one or the other. I think the core of the problem started with Surescripts changing their standard to increase the character limit of that field. Even though GE will store more characters in ERXRESPONSE, the limit in PRESCRIB is still 10, so when you write a prescription for a patient where that formulary is the defaultplan, it tries to insert more than 10 characters into a field and the insert fails, hence the message. I hope that helps someone.

Posted : January 11, 2019 8:00 am

EL520

(@el520)

Posts: 1

New Member

K-Marsh:

Our team is experiencing very similar issues with refills coming up in the wrong LOC. Have you found anything to alleviate this issue or do you know if the script GE published alleviates this issue?

Posted : January 17, 2019 5:57 am

kmarsh

(@kmarsh)

Posts: 85

Estimable Member

Topic starter

The SPR number for this is 71235, KM 19881 problem # P-5273. We did get an update this morning that the fix "is included in SP3 (subject to change)...the GA release date is delayed until March due to performance issues".
We have a work around of sorts but it's clunky and makes everyone feel uncomfortable. We have only 2 LOC that this affects. No one except admin has acces to the 2nd LOC so when the MAs try to refill a request (click the Start Renewal Document icon) they get pop-up that tells them they don't have access to that location of care. Then they come to one of the admins, we will start the update in the 'wrong' chart and deny the request and make a note of why (system error). I copy the request and paste it into an email to the MA so that she/he can see the pharmacy and the med info. They then do the refill in the 'correct' chart (click in the Refills button). I'm not sure what the pharmacy thinks of this but it seems to work for us. There are not too many charts where this happens. In our case, the second LOC should probably be made inactive but no one wants to do that at this point for fear of unintended consequences - would we not get the request at all, would it just error out and need to be matched? Virence did recommend making the chart inactive but no one wants to do that either and there are 8,000 of them. It doesn't solve the problem anyway for businesses that need to have more than one active LOC. The refill request drops into whichever chart exactly matches the name in the request (if one LOC has John Smith, one has John Smith Jr, and the pharmacy has John Smith, it will drop into the John Smith chart).

Posted : January 17, 2019 8:33 am

Page 2 / 2 Prev

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