2021.02.10 EQRS Working Group - Meeting

• No date as of yet to open up submission of Clinical Data.  Estimates at least a month or two.  But nothing concrete.
• Feedback:  Clinical Files themselves did not have issues; only admission and treatment data.  Extension to get clinical data in is necessary.  
• FKC - not submitting is alleviating stress from field since not able to view the data. 
• Is there a reason why clinical data can not be submitted?  

• Shared spreadsheet of all error messages. 
• Last few tabs in pink - these are the errors that were turned off or turned into warnings.  111 total.
• Request for LDOs to review the tabs and provide the following information:
  →  value on error provides to the system
  →  level of effort - high, medium, low (with testing incorporated).
• If the change includes a major change to the XML, mark as high impact activity (requires coding in EMRs and testing with XML structure).
• Goal is to start with high value, low effort items on first. 
• 11232 - Invalid Discharge Reason for a Transplant Facility Admission
  →  EDI submitters are do not submit data electronically for transplant facilities.
  →  Clarification - Invalid discharge reason for a subsequent transplant facility admission or the admission the discharge is tied to does not align?
  →  Lisa to research to determine why this code is on the list.
• Request from EDIs - Report on count of how many patients are receiving each error code.  Would like to gauge how frequent these errors occurs.
• Some validation rules can affect benefits and payments, but CMS will need to take a closer look to determine why 11232 is on the validation list of codes.
• Validations rules also align with single user interface.  Applying the same edits to both UI and EDI.
• EDI's position is that if errors forced an error before 11/1, then should be able to switch back to an error again.
  Example:  11221, 11225.
• 11222, 11233, 11324 - Currently errors that are being received by EDIs.  DCI received error 11222 about 400 times from January 2020 thru today.  DCI continues to resubmit the patient over and over again so the 400 might only reflect 40 patients.
• NRAA - Want to look over the list to determine impact to single interface users.

• Are EDIs able to turn back on the discharge reason codes:  11231, 11232, 11233, 11234 ?
• DCI - Yes
• NRAA - If it was an error before 11/1, okay with turning them ALL back on.  Go back thru the problematic ones and determine if they add any values or not.
  Edits and validations should be exactly the same prior to cutting over to new EQRS.
• Davita - Agrees.
• FMC - Yes if EQRS behaves the same as CROWNWeb did.  Already set up to handle errors that existed before.  Okay with turning them all back on and go back on the ones that are not working as they should or no longer needed.

• EDI's are fully prepared to deal with errors that were on prior to new EQRS - allow to streamline and identify the problems more easily.
• If no changes to how the system operates with how it did in CROWNWeb - EDIs are prepared to turn them all back on if they existed prior to 11/1.
• Turn all back on or methodically in chunks?  CMS to discuss internally to take consideration from ManTech.  
• If turn on in phases - extends the amount of bad data that may be getting in for an error code.
• There are dependencies on errors with different types of admit and discharge codes that are used (interconnected).  If turn on a few, could prevent other data from updating since there are business logic wrapped around all of these.
• EDIs are setup to run files the "old" way in CROWNWeb.
• Are admit/discharge reasons still being used?  Are they still valuable to the program?  
• Resetting to what they were prior to 11/1 may be different than what is actually in the requirements for new EQRS.  Davita clarified to state that they want to "reset" what was in the system as of 10/30/2020.  

• What needs to be in EQRS and what doesn't.
• Davita - submitting vaccinations monthly closure file when they are not given monthly.  Will start here to discuss vision for vaccinations.
• DCI - Separate data elements.  Be able to submit a new phone number without submitting anything else for a patient.  Currently, need to submit extra information about patient including what actually is changing.  Instead of rejecting all the data because of error on one data element, separate the data elements.
• Delete data thru page submissions.  Currently, can add and modify, but can not delete (i.e. delete treatment record).  Needs to delete thru UI today instead.  

• Start discussions around vision for vaccinations.
• NRAA proposed that EDIs provide sample XML data structure on new transaction on vaccinations.
• Program expressed concerns.  Example:  PPSD can get vaccination up to 3 in life time.  Be able to tell when a patient had vaccination and if they are current on it and do they need to have it.  Received in 20's and five years later, get the booster.  Should get 3rd one at 65. Be able to determine who needs what and when they need it.  
• NRAA expressed that the system should simply take in the data (data dump) instead of building in business rules and edits about the patients treatment needs (i.e. system should accept vaccination data and do data analytics after the fact.

• Open up the pathway for EDIs to do it themselves rather than being reliant on others.

• System instability (processing timeouts, micro service reliability, security key failures)
• Unexplained processing results (incomplete response files, random data issues that are not re-creatable, data not showing up in UI).
• High data submission errors (e.g. 10x increase of 401s, receiving errors CMS thinks are turned off).
• No access to bulk data/operational reports.
• CMS forms (triggering when not needed, not pulling in accurate data, submitted forms missing causing expired pts. to show as active).

System instability (processing timeouts, micro service reliability, security key failures)

• Time outs in the gateway.
• Overall average for feedback files are 2 minutes.  Usually 30 seconds.
• Microservice - Turned off.  Why did it stop working?
• Security keys - emails to notify for replacement did not work.
• No operational maturity.

High data submission errors (e.g. 10x increase of 401s, receiving errors CMS thinks are turned off).

• Good progress, but not able to test since not able to submit clinical data.
• Error 99999 has been resolved.
• Experiencing higher levels of errors than what was prior to new EQRS.  About 10-15%.

No access to bulk data/operational reports.

• Reports help improve data and able to know what is missing.
• NCC is working on Clinical Comply - almost ready.
• Would like to get ahead of paper work that needs to be signed in order to get data from NCC when it's ready to ship.