2021.03.03 EQRS Working Group - Meeting

• Reminder:  ADO transitioning in March.  
• Secured ManTech team to continue to work on Errors/Warning implementation to ensure no lose of velocity.

11297 - Medicare Enrollment Status must be Medicare Coverage when Medicare Claim Number is populated.

• Patient who never had conventional Medicare (i.e. Medicare Advantage Plan).  Patient has MBI (assigned automatically).  In CW or EQRS there could be MBI for the patient, but clinic would never know what the MBI is, so patient would be submitted as "no MBI and NoCoverage at the same time".  This would reject if the batch file submits no MBI and NoCoverage, but the system has an MBI.  
• If it errors out, clinic would not have the information to resolve in future batch submission.
• Sujatha to determine how the error behaves.
  
  

11520 - Admit Reason of _{0} was replaced by the system with _{1} for the submitted Admit/Discharge.

• Should be treated as a warning; not an error.
• Post-save warning - data was saved, but system overwrites the admit reason.
• If the system is overwriting, then there is no action needed by EDI.
• If changing this as an error, then the message should be changed to match.
• CMS concerns is that the EDI system would not match what is in EQRS and a warning would be triggered every time for the patient.  
• Other error codes already exist for wrong admission reasons so why does this error exist?  Why is there functionality to overwrite the EDIs submitted admit reason when the wrong admit reason error codes rejects the data.
• EDIs noted that they have never seen this error in past and would want to understand what changes the system would make and in what scenarios.

11521 - Admit Reason can not be updated to _{0} because the current Admit Reason is _{1}.

• Patient already has admit record in EQRS and ignores admit reason code on submission file because the system believes the admit reason in EQRS is correct one.
• EDIs see the benefit in this, but would like to understand the system behavior.
• Whatever decision made for 11520 would apply to this one as well.

13492 - Medicare Enrollment Effective Date of _{0} already exists in the system for Medicare Enrollment Status.

• EDIs do not believe they should be passing this data to EQRS.  CMS should own this data and populate it based on information that the system already has.  
• Effective date is not tied to a specific data set.  I.E. race, ethnicity, address, Medicare enrollment would all have the same effective date within the EDI schema.  This means that an address change would update the effective date being passed on the file and it would not have anything to do with the Medicare Effective Date.  
• There is a mechanism to update effective date specific to demographics, but EDIs have not been able to implement the coding change.  
• Frequency of warning is low for DCI.  If others are okay if this is an error due to low frequency, than okay to leave as an error.  
• There would be no data correction on EDI side, so would like to leave as a warning.

13559 - Admission Records created prior to _{0} cannot be modified via batch.  Changes to the Admission Data were not processed.  Please use the SUI to make any necessary updates.  

• In 2012, data was converted from other systems into CROWNWeb (i.e. REMIS).  Discovered that there was a discrepancy between admit reason and admit date between EDI and CW.  As a result, decision was made that the record would be accepted but the admit reason and date would not be changed if it is prior to 5/24/2012.  
• This batch limitation on updating admissions with admit date prior to 5/24/2012 should be removed.  For example, if you we have a patient that was admitted on 4/23/2011 and died three days ago and we are trying to submit discharge date and death as a reason for this patient, this would be rejected if it is an error.  

13561 - Treatment Information on records created prior to _{0} cannot be modified via batch.  Changes to the Treatment Information were not processed.  Please use the SUI to make any necessary updates.

• Same as above issue.

• EDIs do not review warnings.  Ignore because data goes in.
• CMS has concerns about this.  Should look at the data so that the data can align.
• EDIs are focused on resolving the errors since the error rates are high.

• Coordinate feedback on clinical codes to determine if phase 3 and phase 4 can combined.  @Nathan Muzos
• Discuss  refresh strategy for test environment.  @EDIs
• Discuss testing meeting cadence and provide suggestions on frequency to review testing results and progress.  @EDIs
• Definition of Done.  @EDIs 
  →  Meeting tomorrow on phase 3 codes and other items.
  
  
• Review 2728 codes feedback.  @NRAA and @FMC 
  →  NRAA does not any customers that submit 2728 via EDSM any longer (done thru UI).
  →  FMC has started looking, but has not finalized.  Should be done by end of week.
  →  Should be able to combine with phase 3 since there are so few.
  
  
• Decide what action items are needed to be taken after completion of testing phase prior to production implementation.  @ Each Individual EDIs

• EDIs continue to experience issues with the reports.
• Running reports are spotty.  
• Pages do not load (system issue)?
• Patient Search screen is hanging as well. 

• Discussion was had on what the clean up effort would look like and ensure data integrity.
• EDIs expressed concerns on the ability to be able to update records via batch process since there are limitations to what can be updated.
• Curt asked if EDIs would need to rerun all files to having all validations rules turned. 
• EDIs expressed that there may be a need to run a backend script in order to update data.  
  →  Involves pulling report to identify records that have data discrepancies.  
  →  EDI would review and provide the corrected data.
  →  ADO would script in the changes.
• Curt expressed concerns and risk around scripting in data changes.
• More conversation to be had around this.