Aaron Thompsonx
Adrienne Adkins
Adrienne Ray

Ahmar Wazir

Anitha Chintalapati
Arnie Esparterox
Betina Fletcher
Bridget Calvert
Cheri Jergerx
Chris Brown
Christopher King
Curtis Phillips
Deb Wilsonx
Dianna Christensen
Greg Eccleston
Hari Krishna Pemmasani
Heather Dubendris
Heather Moorex
Howard Thomas
Janet Lea Hutchinson
Jason Bullock
Jason Clemx
Jason Simmington
Jeneita Bell
Jennifer Baileyx
Justyna Sardinx
Karena Sx
Kathleen Prewittx
Kelly Llewellynx
Kelly Mayo
Leah Skrienx
Letty Lamping
Lindsey Clemente
Lisa Reesx
Malik Arsalan
Martha Bean
Mary New
Matt McDonoughx
Melissa Fieldhousex
Michael Kennedyx
Nathan Muzos
Ozlem Tasel
Pandu Muddanax
Rachelle DuBose Caruthersx
Revathy Ramakrishnax
Sarah Fillingx
Seema Sreenivasx
Scott Laughlinx
Shalon Quinn
Susan Cali
Todd Johnson
Tracey Coleman
Vladimir Ladikx
Yvette Brown
Zach Serlethx


  • This meeting will be recorded for the purpose of capturing further meeting notes and action items.  Any objections please inform the host.
Meeting Recording

Passcode: W6v9cf&L 

Definition UpdateLisa
  • Telemedicine:  A visit with a provider that uses telecommunication systems between a provider and a patient. 
  • What telemedicine is not: A brief (5-10 minute) check-in with a practitioner to decide if an office visit or other service is necessary.  Communication with a practitioner via a patient portal.
  • Definition from the ESRD Telemedicine toolkit that was developed back in March of 2020
  • If patient is a dialysis patient and has an in-center rounding session, that would not be counted as a telemedicine visit
  • Looking more for those home patients that are using telemedicine and it's helping to keep them at home or its helping to move patients to home
EQRS Effective DatesLisa
  • Effective dates are important, throughout the system and do matter
  • From a DaVita perspective, effective date is their number one error
  • There is a feature coming up in PI16 that may help some of the effective date issues
  • Medicare effective date specifically (we get from the EDB), Michael has been doing research in finding ways to take that and populate that part of EQRS so you won't have to submit the coverage or the dates
  • FKC already sends effective dates and particularly for their Medicare patients
  • Question: Will there be any conflict with the dates between the dates FKC is sending and dates that will be auto populated? Or will EQRS ignore what FKC is sending?
    • Per Lisa, it will be populated from the EDB which is the source of truth
    • A patient repository will be set up
    • In the place of a conflict, EQRS will ignore FKCs effective date because EQRS has the source of truth
    • If there is a conflict and receive an informational message, FKC should be able to source that from EQRS, ask the network or someone to do it and FKC could update their system to be on the same page
    • It's important that everyone aligns their systems with the source of truth
Slide Presentation
PI16 Features OverviewLisa/Scott/Michael
  • Per Lisa, she will not be presenting any features that has to do with QIP
  • These slides only include information that deals with the network side or any other entity besides QIP
  • QIP cannot share things when they are in rule making or anything that's being updated in the system during rule making
  • These features are being presented to this group right after the shallow dives, plan is to keep this group up to date the next meeting after the shallow dives
  • Keep in mind since these features being presented have only gone through a shallow dive, a decision has not been made on which features will be picked up for PI16; there are other things such as Security and things that do not necessarily affect submission of data that need to be considered for PI16
  • These features are not set in stone
  • After PI planning, the list of PI16 features will be brought back to the EDIs 
  • Trying to include the EDIs earlier in the process to get their input/feedback
  • Also planning on letting the EDIs know what is planned for future PIs, for example PI17
  • There is a risk of letting everyone know things too much in advance because changes can occur
  • It's very important to attend the system demos.  This is an opportunity to see where the ADO is at, their progress, and raise any questions
  • The Program is working on a process (for example, sharing information, getting the EDIs involved, etc) there is currently no process workflow in place, this is trial and error
  • Per Vlad -The sooner they get information about future enhancements or future directions for data collection, the better.  With the understanding there may be changes
  • Question (Vlad): Will this list of features be given to the EDIs to provide their recommendation for prioritization?
    • Lisa will need to get back to the group on a decision

Slide #2 - 2744 Reports - To be able to report on the underlying data for the CMS Form 2744 for the current reporting year and to do a comparison with the totals from the prior reporting year

    • Question: Once the reports are launched, will the NCC still be providing the role out to the networks and the EDIs?
      • This is a conversation that will have to take place once the reports launch and the EDIs determine that what they are getting from NCC reports are still valuable. Do the new reports provide enough information 

Slide #3 - Admission in Support of a Transplant - To update the Coverage Calculator logic for dialysis in support of transplant admissions to ignore the admissions for coverage. To add a discharge reason of delayed transplant function resolved for these admissions.

    • This feature will not discharge the patient from the transplant center
    • Per Kathleen - EQRS has a current behavior that is similar to how this feature will work.  A discharge can currently be removed, even though there's a subsequent visit and what happens is that admission that's open, they can still see the patient and everything but the little edit button that allows to change an address or something wrong in the UI, goes away.  This behavior could also happen when this feature is launched as well.

Slide #4 - Enable ESRD Network Patient Editors to correct erroneous form data - Enable the ESRD Network Patient Editors the ability to manage and update submitted data to reduce additional support requests.

    • Question: Are there plans to put a process around it for the networks to follow?
      • For example the networks will agree to the change.  It may become frustrating if asking one network to make a correction and they do not require documentation, then ask another network to make another correction but that network request for multiple pieces of documentation proving that the correction is legitimate
      • There needs to be a standardized process among the networks
      • There may be a need for a standard operating procedure established within the network data managers on how these issues will be addressed
      • Will these fixes/corrections go through the helpdesk?  This will be discussed with the team that will be addressing this feature

Slide #5 - Enabler: Implement clinical warnings/error range thresholds and validations - To be able to identify ranges for clinical values based on physician input for warnings and error ranges.

    • Question: Current behavior is if one lab errors, the entire XML is rejected; would that be part of that process to accept the other values and just reject that one that actually has the error or would that have to be a separate piece of work?
      • Per Scott - An error would be so far outside of the norm that yes, it could cause the entire submission to be rejected
      • This feature originated from the EDSM implementation strategy where we talk about creating that new warning threshold first then the error threshold
      • Kathleen is asking to refine the process for errors where it would reject a single error, not an entire file
        • Per Lisa - Not sure if this could be done, but this idea could possibly be put on the backlog as an exploratory enabler

Slide #6 - EQRS HARP Role - All roles necessary for appropriate UI access must exist in HARP/EQRS.  Individual facility users, LDO's, CMS and its representatives need to have appropriate access to EQRS to have the ability of viewing data and reports, as well as have the ability to submit, review and finalize inquiries.

    • Primary purpose of this feature is to consolidate and realign the roles that are in the system today
    • Want to reduce the number of roles; improve performance of the system to make it easier for the users of the system to know what access they need to accomplish their work and from a security standpoint to not grant any individuals more access than they require
    • Corporate Role functionality is a separate feature that is currently in development.  The goal is to have it completed by the end of PI15

Slide #7 - Exploration enabler: Transplant - To enhance transplant data availability and display in EQRS.  Exchange (ideally, by CDR) transplant data with other organizations (e.g., SRTR, UM-KECC, HRSA, UNOS, TAQIL) to better support patients and facilities in achieving a kidney transplant for the patient.

Slide #8 - Hepatitis Vaccination Data - Implement a method to obtain Hepatitis B vaccination data for dialysis patients. There will be vaccinations for COVID-19, flu, hepatitis and other illnesses and the administration should be able to see how many of these patients are getting these vaccinations.

Slide #9 - Patient Registry - Data Identifiers - To define and align patient attributes (what the data is) and which of those attributes we need for our definition of a patient and identify the source of truth for those attributes.

    • EDB being the main source of truth, planning on when a patient is entered you can edit and use those fields for key patient identifiers, including date of death and Medicare status.  It will prevent the override of the data with nulls like removing the dates of death, removing discharges
    • Once they get the Medicare status and effective date and populate it that will be locked
    • Once the fields are locked that are from EDB, it won't reject or give an error, it will give a warning message saying this is a locked field, we ignored that data
Round TableAll

Next meeting scheduled for  

Note: EQRS PI16 Planning is 10/6 and 10/7

Action Items:

  • The definition for "Telemedicine" will be further clarified when Lisa takes the feedback to the team Lisa Rees 
    • 9/8/21 - Lisa is still looking into getting a definition for the EDIs
  • Leah Skrien asked if aside from Telemedicine if there is anything tied to treatment? Lisa will have the other PO's put together something explaining if anything is tied to treatment and bring to the next meeting Lisa Rees
    • 9/8/21 - Per Lisa, her understanding is yes, that Telemedicine was the only thing tied to treatment
  • Anitha will update the "new?" column field with the date the Kt/V "standard" option was moved into production Anitha Chintalapati
  • Nathan request since the Kt/V "standard" option is already in production, can they have the updated data dictionary, XSD, XML examples, error codes and any associated documentation.  Anitha will send the documentation Anitha Chintalapati
  • EDIs would like to understand how, if or when the Kt/V "standard" option will be used as part of the QIP adequacy measures and same for five-star. When will the standard Kt/V be included in QIP and five-star calculations? Need to get something out to the community/EDIs Ahmar Wazir Jason Clem
    • 9/8/21
      • Per Jason, there is no discussion to bring that it
      • On they post a muck list every December of new measures that might be implemented
      • At this time no plans to update the Kt/V measure
      • Per Howard they have a Kt/V with two methods, both are eligible and used in QIPs
      • If not going to use Kt/V, they need to tell people b/c Kt/V is being reported using standard methodology
      • Per Jason, an announcement was sent out on the standard method to all EQRS users - They are still just looking at the UKM two methods for QIP
      • Howard suggest to review the announcement again
      • Per Lisa, they will take this back to the QMVIG team for clarification and to get a definite answer

DateMilestone (M) / Task (T)DescriptionPhaseStatus
2/28/2021MCode deployed to pre-prod for testing.1Complete
3/15/2021 - 3/24/2021TEDIs perform integration testing.1Complete


MEDIs sign-off on integration testing.1Complete

3/24/2021 - 3/25/2021

TADO prepares for coding deployment.1Complete


MProduction deployment.1Complete
3/31/2021MProd-Preview environment contains refreshed prod data 2Complete
2/24/2021 - 3/10/2021 TReview of phase 2 codes and finalize list of codes.  Complete
3/11/2021 - 4/30/2021TADO perform coding updates and regression testing - Phase 2 (Patient Codes) 2Complete


MProd-Preview environment data refresh.2Complete


MRemaining Phase 2 (Patient Codes) deployed to pre-prod for testing.2Complete

5/4/2021 - 6/1/2021


EDIs performs integration testing - Phase 2 (Patient Codes) 
Starting 5/4 - EDIs submit prod file in prod environment and PP2-3.  This should be the SAME file for both environments.  Review discrepancies between the feedback files and validate codes.



MEDIs sign off-on integration testing - Phase 2 (Patient Codes) 2Complete

6/2/2021 - 6/4/2021

TADO prepares for coding deployment - Phase 2 (Patient Codes) 2Complete


MProduction deployment - Phase 2 (Patient Codes) 2Complete
6/4/2021MPhase 2 (Patient Codes) live in production.2Complete
3/10/2021 - 3/17/2021TReview of phase 3 codes and finalize list of codes.  3Complete
5/12/2021 - 06/08/2021TADO perform coding updates and regression testing - Phase 3 Clinical Codes/27283Complete


MProd-Preview environment data refresh.
6/4/2021 - 6/6/2021T

EDIs SHOULD NOT submit any PATIENT files during this time period in production (to ensure same patients are in PP2-3).


EDIs to drop file into PP2-3 to establish a baseline.



MCode deployed to pre-prod for testing - Phase 3 (Clinical Codes/2728).
Reopening September 2020 to March 2021 Clinical months for submission.

6/9/2021 - 7/6/2021

TEDIs performs integration testing.

Starting 6/9 - Re-drop same file from 6/7/2021 into PP2-3.  Review feedback files from PP2-3 and validate codes.



MEDIs sign-off on integration testing - Phase 3 (Clinical Codes/2728).3


7/7/2021 - 7/11/2021

TADO prepares for coding deployment - Phase 3 (Clinical Codes/2728).3Complete
7/12/2021MPhase 3 (Clinical Codes/2728) live in production.3Complete


MEDSM Implementation Complete (Phase 1 - 3).n/aComplete

7/12/2021 - 9/15/2021


Resubmission of Clinical Data Files (September to December). 

Open July 12, 2021 at 5 a.m. Pacific (8 a.m. Eastern) and close September 15, 2021 at 11:59 p.m. Pacific Daylight Time

9/15/2021 is the official closure date for the clinical months of September, October, November, and December 2020.

CMS highly recommends completing large data submissions prior to the official clinical closure date.





Data fully submitted and ready for measure and scoring calculations.

09/20/2021 - 02/28/2022T

Submit January-September 2021 EQRS Clinical Data, ICH CAHPS Attestations, and Clinical Depression Screening and Follow-Up Plan reporting in EQRS. Additionally, all subsequent months in 2021 will open for data submission on the first day of each month (i.e., October opens October 1; November opens November 1; and December opens December 1). 

02/28/2022MThe clinical closure date for all months in 2021 is February 28, 2022 at 11:59 PM PT.n/a

Data Submission (Errors & Warnings) Milestone Dates - By Phase

Phase No.

File Type

Code Bucket Name


ADO Completion Date

LDO Testing Start Date

Testing Completion Date

Production Date



Admit Reasons

11221, 11222, 11223, 11224, 11225







Patient Codes







Clinical Codes







2728 Codes





  • No labels
Write a comment...