PatientFollow Project

Our database collects patient ward stays, which means the data of a patient may be processed by several collectors during the admission. This leads to extra, wasted work of different collectors familiarizing themselves with the same patient. We are looking at ways to reduce this waste.

Specifically, we are looking into having a single collector/laptop follow a patient for their whole admission, and how our processes would need to change to accommodate this, and what extra tools we might need.

Pilot

• one or two collectors at HSC will do collection like this for specific patients in coordination with main office to better understand how this would work

prerequisites for pilot participation

For a collector to be able to follow to another ward and enter that as a Service/Location we need to add the additional wards to the laptop's S locations allowed collection table entries in CCMDB.accdb, and assign a reasonable order in the dropdown for the locations. This has been done for:

• HSC H4 laptop

Identifying admissions / Starting collection

Currently patients are assigned to collectors/laptops based on where they are admitted. To change to the new system, we would need to identify patients who enter a given site and then assign them to the collector pool equitably. We are planning on a process based on the last two digits of the chart number.

What would be the process for picking up new patients

Details to follow, but it would likely involve Exporting and sorting an admission list from EPR. The list would need to be exported on a regular basis and then made available to collectors. How would this best be done? There was talk about EPR lists to help collectors keep track of their patients. If we use that method then how will we handle it when there needs to be coverage? How do we make sure no pts are missed? How do we make sure no pts are duplicated?

• SMW

• Cargo

• Categories

If we split by chart number, how do we ensure no pts are missed or duplicated?

The one thing which is unclear yet to me is how to make sure we will not miss any patient in a given ward(Med/ICU) using this strategy. Who will be responsible to check or monitor that all patients who were admitted in a given ward are already entered in all laptops? How long will the DC run after that patient who left the ward but still in the hospital? How easy to catch those transfers from other service who haven't been in ICU/Med and now have been admitted to ICU/Med service? For now, these are my thoughts. --JMojica 15:32, 2019 August 6 (CDT)

• The process of picking up patients would need to be very clear, and would need to change from what it is currently. We started this discussion with Val. They now get all of their pts off the EPR. That listing includes Chart numbers. So instead of looking at their ward, they can look at their chart number. The only thing is, we can’t sort that by “last two digits of chart number” to make it easy. I hope we can still do better than that. I think it might be good to chat with someone like Laura or Lisa or someone from Med Records about what else we might be able to do with those lists – if we could export them we could filter them to laptops by last two digits.
• Val showed us that she creates an EPR patient list that includes all of her current patients. This list enables the collector to more easily track patients throughout their stay, as you can have patients from multiple different locations on this one list. The only problem with this list is that it is specific to one collector's login, so if other collectors are cross covering (for vacation or other reasons), they would not have access to this master list. Michelle investigated whether it is possible to share patient lists between collectors and the EPR specialist informed her that it is not possible.

The potential to either, have multitudes of patients duplicated, or more importantly, patients missed seems astronomical. Inadvertently duplicating patients will end up being way more work for data collectors. How will we, as data collectors even know that we have duplicated a patient that another data collector has already done? Or conversely, how will we know if we have missed a patient?

• SMW

• Cargo

• Categories

What would be the actual chart number split per site and per collector

We would essentially take the sum EFTs per program/site and consider them as 100%, and then assign the chart numbers based on that percentage. For example, if a site has 3 collectors that are each a .5EFT, each collector would get 33% of that site's new admissions, so collector A might get charts ending in 00-33, collector B 34-66, and collector C 67-99

As of Sept 2019 we are testing the split between medicine collectors at HSC.

The last two digits of chart numbers are evenly distributed and can be used for this.

Tina has taken a basic look at the distribution of these numbers and emailed Julie and Trish for feedback. Ttenbergen 17:31, 2019 August 1 (CDT) Julie did additional analysis by looking at the distribution of the last two digits numbers from last 5 years 2014 to 2018 as follows: 1) all sites together, 2) each site separately 3) each year from all sites separately and 4) each site and year - the distributions showed similarity with few peaks in some numbers. She grouped the last two digits numbers into a) 10 subgroups (e.g. 0-9,10-19,20-29, …, 90-99 ) and b) 20 subgroups (e.g. 0-4, 5-9, 10-14, 15-19, …, 95-99) and their distributions showed uniformly across subgroups. Each of the 10 subgroups showed counts close to 10% while each of the 20 subgroups showed counts close to 5%. The histograms are in X:\CCMDB_Special_Projects\Project_PatientFollow_ChartNumberDistribution. The results support the viability of using the last two digits of the chart number in allocating patients among the data collectors. Julie also did the distribution of the first two digits numbers and found out that the distribution was skewed to the right. Therefore, this cannot be used as a tool for allocating patients. The distribution is in X:\CCMDB_Special_Projects\Project_PatientFollow_ChartNumberDistribution . I think this is a good starting strategy to allocate patients among the data collectors proportionately in each site.

Would the LOS have any impact on this sharing plan?

This would not be a problem.

We discussed whether different LOS will cause problems with this distribution of patients. We would expect LOS to be equally distributed across Chart Numbers; if it is we should be able to ignore it in distributing patients, since the “average” patient with an “average” chart number would have an “average” LOS.

How would patients be equitably shared across diffrent EFTs?

I do not see how this way of splitting patients can be done on a fair and equitable basis. We do not all have the same EFT, and we don't all have nice simple .5 eft's. My eft is .65. Not quite as easy to fairly and equitably split. The division of workload should actually be easier using this method. If you are a .65 as opposed to a .5, then the chart numbers that are assigned to you would be equivilant to your EFT, so a .65 EFT would be assigned more of the chart numbers than a .5 EFT would be.Mlagadi 12:24, 2019 September 5 (CDT)

• SMW

• Cargo

• Categories

How about EMIPs?

• What about the emip's? How will they be handled? The number of emip's that I do are variable. I had 29 emip's in a 10 day time frame last month, and 40+ emip's for the month of August. Other months I'll have half of that for the entire month.
  • EMIP's will be collected in the same way as we collect ward patients, using the assigned MRN's, so over time, they should have an equal distribution based on your EFT.Mlagadi 12:24, 2019 September 5 (CDT)

Entering into the laptop

The initial ward would need to be entered as usual. For stays on subsequent wards the Patient copier button can be used to create the next record.

Additional things we might be able to copy in the future are (not implemented now to allow general use of the copier button):

• Visit Admit Date and time
• import dispo and dispo_dttm (+ 5 min) into the previous location and arrive_dttm automatically

Thoughts?

As usual, if you have thoughts or ideas about this, please post them here.

Follow between medicine/critical care or just within one program

For now we are testing this just following patients within the same program, eg if a patient were admitted to a medicine ward, then ICU, and then back to the same medicine ward, then the medicine collector would get the two med admissions, and the CC collector would collect the ICU stay. This may change in the future but would require fairly significant changes to CCMDB.accdb Data Integrity Checks and other settings in CCMDB.accdb.

Process to identify Medicine patients from EPR at STB

• For any collection unit for example, STB E6 four EPR reports have to be run (that is 4 EPR reports per unit) to ensure there are no duplicate patients, incorrectly enter disqualified patients or patients entered in error by MR staff. So in the instance of laptops that have two units (B5/IMCU) that means 8 reports. All 4 lists must be checked because no one list is inclusive of all admission/discharge/transfer activity for a unit from date of last collection. These lists must be reconciled with each other and compared to the unit census. Collectors may use a different methodology/approach to collection that works best for them.

Breakdown per unit:

• 1. The admission list
• 2. The discharge list
• 3. The transfer list
• 4. The unit census

Simply looking at and entering patients from lists is not enough, list entries may require further analysis:

On the transfer list for example there may be entries made in error that patient A was admitted to a unit. The error is usually followed by a “transfer to another unit” a few minutes later. My understanding is that when an entry error is made by MR staff once entered, the entry cannot be deleted, so to reconcile the error another entry is made to “transfer” the patient to the correct unit location. Additionally, sites and units may have certain “idiosyncrasies” for example chemo only admissions for STB E6 are not included in the data base. This can only be ascertained by entering the profile and taking a closer look at the information contained within to determine whether the patient should/should not be included in the database. Simply looking at/using entries found on a list is not always sufficient or indeed accurate. The issue would be exacerbated by a random chart number assignment for no information at all can be gleaned from a record number.

In fact, there is a fair amount of “investigative” work involved in data collection such as running and reconciling 4 EPR lists per unit, and follow up of patient list entries as necessary to ascertain “true/legitimate” patient admissions so as to avoid entry error, duplication, or missing patients.

concerns about patient follow due to this complicated process

The process to identify patients for collection in our database is currently ill defined, complex and different between collectors and sites.

It should be questioned then whether amalgamating all data collection units within a site for example there are 4 medicine collection units at STB + EMIPs how to possibly track and reconcile all these lists with any semblance of accuracy. This would be a very labor/time intensive and complicated process, as well as a significant logistical challenge. Use of EPR lists to create further lists/spreadsheets in Excel seems redundant and a risky proposition in terms of inclusion and accuracy. There are also potential PHIA considerations whereas patient information on laptops is currently stored/accessed through a separate program, what are the implications for "personal" and/or redundant storage of patient information on data collector accounts? Pamela Piche 10:19, 2019 September 5 (CDT)

• SMW

• Cargo

• Categories

• This does represent a fairly big change in the way that we are used to collecting. This concept warrants an in-person explanation, where questions and concerns can be discussed. It is hard to read the WIKI page and get a full understanding of the intent of this project.Mlagadi 12:32, 2019 September 5 (CDT)