We have a strange issue. Most times, when a referral is created, they are set to a 90 day duration and the date automatically sets to 90 days in the future. We have hundreds of thousands of referrals in our system that state 90 days for the duration BUT the Start and end date is only 1 day apart.
When looking at our orders in SQL... we get this message in the INDICATIONS column on the orders table:
Auto update of signed by user and/or order end date on Sep 15 2016 8:00PM by Encounter Patch. Old pubuser = 1767871760510160
Does anyone know what is doing this? We've opened a ticket with GE, InDxLogic and CallPointe but no one knows how this is happening.
Thank you for any guidance...
Hi, we had the same thing happen to us. The reason the 90 day duration got changed to one day is because the user completed the referral. As soon as they complete the order, the end date is the signature date.
I thought that was fixed in the last Service Pack. I just tested this on our system and the end date of the referral didn't change. I guess it depends on what version of Service Pack you are on.
I'm not certain that's our issue. Our users aren't completing the referrals. There are referrals that are put in today... and tomorrow the date is changed and that indication is added in the column.
That "Signed by Encounter Patch" is strange. Do you have a GE SQL script that was used to fix something for CQR that is set up as a scheduled task and running every day?
David,
I was able to find a job that is causing this. Here is the stored procedure:
/* ==Scripting Parameters==
Source Server Version : SQL Server 2008 R2 (10.50.2500)
Source Database Engine Edition : Microsoft SQL Server Standard Edition
Source Database Engine Type : Standalone SQL Server
Target Server Version : SQL Server 2017
Target Database Engine Edition : Microsoft SQL Server Standard Edition
Target Database Engine Type : Standalone SQL Server
*/
USE [centricityps]
GO
/*** Object: StoredProcedure [dbo].[upMUOrdersPubuserEnddate] Script Date: 12/29/2017 8:13:57 AM /
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[upMUOrdersPubuserEnddate]
AS
BEGIN
-- *************************************************************
-- Purpose: MU2 2015 SPRs
-- 3. Update the orders table to set the signing provider to be the same
-- as the authorizing provider and set the end date to the order date + 1
-- for all signed or completed service orders that have a specific SNOMED code
-- Author: Mike Cohen and Alaine Warfield
-- Date: 14-Feb-2015
-- Upgrade Required?: Yes, just for the trigger.
set nocount on
Update orders set pubuser=authbyusrid, enddate=orderdate+1, db_updated_date=getdate()
,indications = 'Auto update of signed by user and/or order end date on ' + cast(getdate() as varchar(20)) + ' by Encounter Patch. Old pubuser = '
+ cast(pubuser as varchar)
where (code like 'SCT-%'
or code like 'SCT:%'
or code like 'SNO:%'
or code like 'SNO-%'
or substring(code, charindex(':', code) +1, len(code))
in (select concept from cqm_valuesetcode where code_system='SNOMEDCT')
or substring(code, charindex('-', code) +1, len(code))
in (select concept from cqm_valuesetcode where code_system='SNOMEDCT'))
and STATUS in ('S','C') AND xid = 1E18 /* only the active row */
--!!! and authbyusrid in (1234567890123450,1234567890123460,1234567890123470)
and (pubuser<>authbyusrid /* wrong pubuser */
or (enddate is null and pubtime is null) /* null enddate */
-- A valid End Date includes midnight on the last day of the order month.
or coalesce(enddate,dbo.convert_id_to_date(pubtime)) > dbo.last_day(orderdate)+1) /* wrong enddate */
and db_updated_date >= '2014-01-01';
END;
The problem I see here is it's not looking at an order type of "S". It's looking at a status of "S" or "C" which is any completed or In Process order, even though the comments state it's for services only. Would there be any harm in shutting this job off? I honestly don't even see the point of what it's doing.
Thank you!
Cliff, I think I remember a big problem a couple of years ago with the dates and users being "wrong" on orders with SMOMED codes so CQR wasn't picking them up correctly for MU reporting. Might have had something to do with the encounter wasn't counted if it didn't have an order with certain SNOMED codes and then there was the issue with who signed the order and the end dates. I don't know if that is still the case and if that SPROC is even needed any more. I'd hit GE up and see if it could be removed. You can see this is for MU 2015 and the start date it is looking at is Jan 1 2014.