Page History

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

• https://zoom.us/rec/share/m8Tg-h9PybNDRdINCrMYpxF-PpYX8D4MhHeCyr9uYLX68WkPwixzt8eDAp95M-uQ.vYnwsXVBdDgjccr

Passcode: W6v9cf&L 

• 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

• 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

• 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