| EQRS Feature Updates (EDI facing) | Lisa | Features Planned for PI22 Corporate Role - Completion Business Objective/Description: - Create the capability for corporate role users (corporate POC and corporate Viewer) to run reports for all of their facilities by adding corporate role permissions to the reports module.
- Add corporate role access for viewing and editing default preferences.
- Adding corporate role capabilities provides access for individuals at the corporate level to view and work with information for all of the facilities under their organization's umbrella. This feature includes the last remaining EQRS functions that have been planned for corporate role.
- PER Report
- PRR Report
- View Default Preferences
- Edit Default Preferences
EQRS Reporting: AWS Quicksight Reports and Dashboards for EQRS - PI22 Business Objective/Description: - The purpose of this feature is to build new reporting capabilities into EQRS using the newly implemented AWS Quicksight architecture. The team's goal is to build at least two reports each PI but may set up more if able. If blocked on any particular report the team may move to the next report in the list in order to maximize the potential output for any given PI. This initiative is expected to be ongoing throughout the next few PIs.
- Build reports from the prioritized list starting with the Clinical Data Report and Vaccination Report.
- Final Reports List from Enabler:
- Vaccination Report
- Clinical Data Report
- Missing Forms Report
- UNOS Waitlist Report
- Clinical Compliance
- Nursing Home Report
- Facility Dashboard Report (NW and Corporate level users)
- Transplant Facility Dashboard Report (Facility and NW level users)
- Facility Summary Report
- Personnel Report indicating active/inactive
- Admit/discharge report reflective of transplant or home modality
- Depression Screening Report
- Audit Reports
- HARP/EQRS Roles Report
- Hoping to develop a minimum of 2 reports a month; depends on capacity/resources
- Is Quicksight going to allow for bulk downloads or is it still going to be individual reports, one clinic at a time?
- As the ADO begins development, we can have someone speak to the group and explain
- Need to have someone provide an answer to the question above and respond in an email or add to today's meeting minutes (Action item Adrienne/Lisa)
- Per Adrienne, the ADO is not ready to present as bulk reports.
- Adrienne does know that the requirements were to have reports for all different types of users including the EDIs
- Will the current dashboards be replaced with something more robust or easily configurable? Will the dashboards stay the same?
- Per Adrienne, the dashboards will be new and flexible; still in the early stages right now; the look and feel of the dashboards should be out for the EDIs soon
- Nathan recommends that when you logged in, the user is taken straight to the summary like dashboard; today the user lands on the access page. This will be brought up with the ADO team (Action item Adrienne)
- This item is on the backlog. The HCD team has an enabler to research where each EQRS role will land when accessing the application.
- HCD team will be on the next Program call, 4/19
Exploration Enabler: Emergency Preparedness/Response Module in EQRS Business Objective/Description: Explore how EQRS can provide a centralized, location for dialysis facilities and transplant centers to report facility and patient status in near real time during a disaster as well as receive communication from CMS and other stakeholders. Emergency operations will enhance the capabilities of KCER (emergency preparedness contractor: Kidney Community Emergency Response), ESRD Networks, CMS, and facilities, during an emergency. Determine how to track the admission and discharge of patients during a disaster as they may receive treatment at multiple facilities during the disaster. This functionality will: - Modernize the emergency response process workflow.
- Retire the current paper processes.
- Identify a better way to capture information types that KCER and the Networks require from dialysis centers to prepare for and respond to a disaster.
- Identify the optimal solution for delivering or making available emergency details for KCER and the Networks need.
Additional Info: - Investigate to determine current state for emergency response and the role(s) that availability of EQRS information plays in any related recovery and assistance efforts.
- Determine how various pieces of the emergency response workflow can be modernized and manual/paper processes can be retired.
- Identify a better way to capture the types of information that KCER and the Networks require from dialysis centers in the wake of a disaster.
- Identify an optimal solution for delivering/making available emergency details for KCER and the Networks.
- A few other options were explored but it was determined that EQRS would be the best option to collect the information and interact with the system
- This will be a whole new module. Not part of the admissions/discharge information that is submitted
- Will this module be based on a location and not patient specific?
- Still an open conversation but the level of expectation is that facilities report all patients as being safe and being located after emergencies
- When the exploration meetings do happen with the HCD team, it is suggested to give the EDIs a couple of weeks' notice so the EDIs can invite the appropriate resources to attend (Action item Adrienne)
- Agreed. The HCD team will coordinate with Lisa on the appropriate meetings to attend.
- Each of the EDIs Each of the EDIs should send Arnie names of people they would like to attend the exploration meetings for the Emergency Preparedness/Response module (Action item All EDIs)
Portal HCD: Exploration Enabler - Update patient details for Forms: 2728 & 2746 Business Objective/Description: - Determine the updates needed to the medical evidence form 2728 & 2746
- Update the Forms 2728 & 2746 within the EQRS UI and EDSM.
- Lisa has returned everything for the 2728 but has not seen it move after public comment
- The 2746 should be going out for public comment soon
- They have been trying to be proactive and get them ready for when they go live
- There is work being done to the 2728
- Kathleen did ask the ADO in the past for the patient date of death on the attribute page and the cause of death. They do not currently have a cause of death tag in the patient xml. She is asking if the ADO can add the cause of death tag to the patient xml? (Action item Adrienne)
- The team is working on this update. If possible it will be pulled in as part of this PI. Worst case it will be done next PI.
- Nathan also suggests the flexibility of the fields whether optional or required, when it comes to patient demographics changes. It will allow them additional time to collect the data (Action item Adrienne)
- A discussion will take place with the EDIs, developers, and SMEs to determine which fields if any can be revised.
- Lisa mentioned that Geraldine provided information this week pointing out that when the deaths are being entered, its not triggering the 2746. This issue is being looked into but need to make sure this is looked at all angles. The ADO needs to look into this (Action item Adrienne)at all angles. The ADO needs to look into this (Action item Adrienne)
- The team is going to continue the work on the Patient Repository to gather requirements to make the EDB the source of truth for Date of Death.
- Geraldine asked if they will ever have the option of getting the death updates from the Social Security Administration like they used to with the action items?
- Per Lisa, she can look into it as part of the enabler for 2746
- Per Geraldine it was really helpful because sometimes patients leave and then they don't know what happens to them and so they don't follow up. They just transfer them out to the hospital and then find out they actually passed away within that 30 days
- They would get action item alerts that would tell them that the patient's Social Security Administration identified the patient as having a death date; clinics would go in and update the information based on the action item alert. They do not get the alerts anymore, they only get accretions as a data extract (weekly or monthly) (Action item Adrienne)
- The team is working on an enabler to determine what can be automated from the legacy Accretions and Alerts and what items will need to continue to be manual efforts.
Update Form 2728 Business Objective/Description: - Update the 2728 form that is used to collect information about patient deaths.
- To maintain the patient registry with accurate information.
- The Program is aware the EDIs may need additional time on their side
Portal HCD: Exploration Enabler - UX for Transplant Dashboards (Transplant Center Staff) Business Objective/Description: - Dialysis Facility staff and staff need the ability to view a summarized list of their patients and see basic information about them, such as name, id, date of birth, the patient was listed for a transplant, listed transplant center statuses, date and reason when a patient is de-listed, name and contact information for transplant centers, and information about the patient's medical coverage.
- This will improve the communication between facilities and the transplant centers
- Thank you to the facilities that have been involved in the discussions and providing their input
- Hoping to continue this work and getting it down in this PI
- Thank you goes out to Chris Brown for providing this idea
Transplant Dashboard for Transplant Center Staff Business Objective/Description: - Transplant Center users need the ability to view a summarized list of their patients and see basic information about them, such as name, id, date of birth, date of admission to dialysis unit, modality, setting, and whether the patient is cross listed with other transplant centers.
- This feature implements a specific dashboard for transplant center users who are provisioned with the new "Transplant Editor" role in EQRS.
- HRSA agreed to start including the reasons that a patient is made inactive on the waiting list. This is important patient information they don't necessarily receive; hopefully their contractor will start providing that data to us in the new future then hopefully the facilities will be able to see it too
- If the NCC can pull this information, they should also be able to include it in the extract the EDIs get from the NCC
- Per Dianna, if the information is in EQRS, the NCC should be able to pull it. Further investigation will need to take place
Removal of REMIS roles from Manage Access Business Objective/Description: - When the 3 legacy applications were consolidated into the one EQRS all of the existing roles were brought over to EQRS. There is an opportunity to remove duplicate roles by consolidating roles across EQRS (formerly CROWNWeb), REMIS and QIP. The first step is to move the MSP role from under CMS Support-REMIS to CMS Support-EQRS. Then remove all the remaining roles from under REMIS since they are no longer being used.
|
| Open Forum |
| DaVita - Thank you for walking through the PI features, it is very insightful
- How did the vaccination data transformation that took place go?
- Per Adrienne, the data transformation was successful and not additional work needs to be done on moving the historical data
- Functionality of the depression screening module - What is the status of the research if it was applying exclusions. Whether or not is was supposed to be applying exclusions or not?
- Lisa did speak to Ahmar. Patient exclusions:
- Patients who are younger than 12, as of October 31st of performance period
- Patients who are treated at facilities for fewer than 90 days during the performance period
- The days do not have to be consecutive
- The facilities do not have to report on patients that are not 12 as of October 31st
- Nathan thinks there may be a defect and will open a ticket with examples
- EQRS is not excluding patients that were there less than 90 days so it is telling users you should report something for this patient
- What is the status on the Peritonitis implementation?
- It is close to being done and going to demo it to the CDC this Friday
- After it has been reviewed by the CDC, need to speak to the EDIs in the next Program Working Group meeting on where Peritonitis will go moving forward (Action item Lisa)
- What is the status of Vlad's request to make the cell counts and the other fields optional instead of required?
- Per Lisa, they still need to have a discussion with the CDC
FKC Peritonitis: - The provided documentation has a pdCatheterUsageDayCount tag, which “indicates the number of days the catheter was used,” with available values of 1-31; what is CMS/CDC looking for here? The available values seem to indicate you don’t want a cumulative count of days in use since the access was placed. Is this asking how many days of the event month was the catheter used? How many days in the event month prior to the event? After the event? Just looking for some clarity on what I need to count.
- Count the days of the month that the incident happened; use the entire month the patient used the catheter
- What is the reporting window for peritonitis events? When should they first be reported? At what point can they no longer be updated? I remember discussions about an event being closed after a period of time and it can’t be updated, but I don’t remember the final outcome.
- Reporting should be the following steps: Incident > a month > report
- For example: an incident occurred in January, took the rest of January and int February to resolve, then reporting would take place in March
- What happens if a incident takes a "long" time to resolve, is there a point at which the EDI can no longer report it?
- Per Lisa, she does not think they put a close on it but would have to check (Action item Lisa)
Accretions: - UPIs for patients missing waitlist data on EQRS extract with identified accretion records: 2105485938 and 2105556491
- UPIs for patients triggering 20002 “exact match error merged patient” errors for patient and clinical XMLs: 3103582890 (accretion UPI 3103828124) and 2105466226 (accretion UPI 3103590222)
- The “accretion UPIs” are the UPIs returned to us in the EDSM feedback files, but they do not exist in EQRS. We have many more examples of this issue.
- Per Adrienne, the meeting to discuss Accretions is this afternoon and will provide Kathleen with information after the meeting
- Kathleen sent an email this morning to the helpdesk around 7:30am. She has not received a response that the ticket has been successfully open (Action item Adrienne)
DCI - Per Geraldine - For Peritonitis, will EQRS have the same rules as NHSN?
- The networks are looking at peritonitis so it would be nice if the EDIs could enter the initial events so EQRS would know as soon as possible and work with the facilities
- If it is entered, you would continue to work off that entry to follow it through the course and not enter a second one
- You could also enter it all at once after the incident is completed
- Peritonitis will have a beginning and end date
RHA US Renal |
ISG Playbook
APIs