2022.05.18 EQRS Program Working Group Meeting

This session will be recorded for the purpose of documenting the meeting minutes and action items. If there are any objections to the recording of this session, please make it known now. Absence of an objection to the meeting being recorded will count as consent to recording this meeting

https://us06web.zoom.us/rec/share/RRLOHAFSqf0MTGuIumQ6y13QwjaZRtpCN8PB969FKr9Ff4UfaaaYxH80YfD4liqa.GiQaRyhChgCNRytM
Passcode: htix4s!M 

What should a report from the Vaccination module look like?

Note: these are not requirements; these are recommendations/suggestions/wish lists

Recording for this discussion:  3:12 - 33:04

Nathan (DaVita)

• Interested in seeing a complete data set 
  • For example, if you have 40 fields, it would be an updated status of all of their patients 
  • Any patient that is actively admitted to a DaVita clinic and have all of the data points; if they are not filled in then it's just a blank cell so the structure of the report stays the same
  • It's all vaccinations in one; not separate reports for each vaccination; it's everything in one giant data set
• The landing page of EQRS should show the overall vaccination rate by each vaccine at the time the user logs in
• It should be an actionable link; clickable link that takes the user to a page that can take them to another page that shows them all of their patients and their current vaccination status for the one they clicked on
• The user should not have to choose a patient from a list
• Should allow filtering for who's missing
• There should be an actual downloadable report that provides the same information (above)
• As the user looks at that data it is a consistent data set
• Also, the listing of patients should also be actionable in the sense that it can be updated
• The data set provided will depend on whether its a facility user or at the organization user level
• The report should allow filtering and clickable to get the data as a whole or get specific data
• Further discussion should take place around what data points to be able to include in the report
• Suggest the ADO build a framework where adding something new to it isn't a custom built effort and adding something does not require extra effort
• The report should be flexible, similar to the NHSN reports; they have pre configured reports that can be run b/c they may be useful but also allow the user to build their own custom reports and save them so they can be rerun at a later time
• From an EDI perspective, it would be nice to be able to automate getting the data out of the system
• In stead of depending on the NCC to get reports, it would be nice for someone from the EDI's organization to be able to log in and generate the reports

Kathleen (FKC)

• Preference is similar to what Nathan described above
• A full data set would be nice but also users can select what they want to run
• In the report it would nice to have the EDI Patient ID so the clinicians can easily find patients

Chris Brown

• From a network perspective, agrees with Nathan's suggestions above
• Would like to see a top-down approach that's always actionable
• Would like to be able to see what the networks rate is; then the facilities rate, etc.; be able to drill down more until finally get to a patient list
• Be able to see all the patients and their vaccination status on the screen in real time (for example, be able to tell a facility which patients do and do not have the vaccine)

Leah Skrien

• When looking at building more reports into EQRS, its still a concern based on how reports were run in the past, to make sure that the system has the capacity to run the reports without slowing everything down or impacting performance
• Per Lisa, we will definitely flag that concern as something to take into account

Nathan has a meeting with the EDIs next Monday and will discuss the topic of future reports

• • Nathan will bring back to the group the feedback or anything that comes out of the meeting that was not covered in today's meeting

Recording for this discussion:  33:09 - 49:38

The four feature pages that will be discussed have been added to the Resources and References public facing confluence page:  Resources and References

Clinical warnings/errors ranges

• • This was a conversation that started last year
  • Email with Yvette were we were clarifying some of the ranges
  • Input from the EDIs, based on your physicians on what error and warning thresholds should be so we can have better data quality, reduce false errors and better capture values that fit out beneficiaries within ESRD
  • This would allow the development process to be easier for the EQRS/ADO
  • EQRS/ADO needs to provide an updated spreadsheet for this feature

Validations

• • Back to phases 1, 2, and 3 for enabling clinical validation
  • Some adjustments were made between what is an error and what is a warning in EQRS
  • Back then everything was hardcoded so changing what those were was a significant lift from a development stand point
  • The ADO was asked how to get it done better the next time if validations change in EQRS
  • That is the purpose of this feature
  • The team determined this could be worked on at the same time the Clinical warnings/error ranges feature was worked on

Part B Immunosuppressive Drug (PBID)

• • This has been in the pipeline for about 1 - 1 1/2 years
  • It will provide ESRD beneficiaries with immunosuppressive drug coverage after the 36 months terminations limit assuming that they have no other form of insurance coverage
  • From an EDI perspective, it should be transparent
  • What is being done on the development side is that the EQRS/ADO is changing the frequency of when they send that terminations file to the social security administration
  • Today it is done roughly the 35th or the end of the 35th month and EQRS will be pulling that into the 36th month
  • There will be more changes on the CMS side; for example from the registry standpoint

Peritonitis

• • This is a research enabler and exploration enabler around Peritonitis
  • Peritonitis is in the network contract to work on for patients that are receiving PD in the nursing home
  • Want a way to capture if patients are experiencing Peritonitis
  • CDC has talked about also collecting this in NHSN
  • Lisa would prefer to see it captured in EQRS not NHSN
  • Whichever way it gets decided, EDIs will only have to report it only once; they will not have to double report
  • Per Lisa, the EDIs would not be asked to report it in both the NHSN and EQRS systems
  • It won't just be for nursing home patients, practitioners have mentioned this is a fairly significant issue so it has become a concern
  • Some of the EDIs may not be familiar on the data collection of Peritonitis so it is requested for the Program to provide them with a distinct set of questions to start
    • Per Lisa, they will come up with a set of questions (action item: Lisa)
  • Question from Nathan - under the acceptance criteria section it mentions "create a data sheet as well as final UI for development".  What is a data sheet?
    • Per Scott, he believes it's a user guide similar to what was created for the vaccination module; understanding of the requirements, what questions came up during research

Open Forum

DaVita - When will PTH be live in prod preview and available for testing?

• • • • Per Michael, not sure at this time but it can be discussed in Thursday's meeting

FKC  - Question from Revathy - when can they expect the finalized documents for PTH?

• • • Michael confirmed with development what they received this week was good enough for them to start and there's not going to be any changes
    • Per Revathy, several of their developers found discrepancies between all the documentation
    • Kathleen will send to Michael for him to address

DCI - not available on the call today

RHA - not available on the call today