Notifications
Clear all
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
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
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
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
