PatientFollow Project: Difference between revisions
Ttenbergen (talk | contribs) |
Ttenbergen (talk | contribs) m →EMIPs |
||
Line 46: | Line 46: | ||
=== EMIPs === | === EMIPs === | ||
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. | |||
== Entering into the laptop == | == Entering into the laptop == |
Revision as of 17:15, 2020 August 27
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
Which patient ID to use
We would not want to add additional Service/Location entries to allow each laptop its own serial pool. So, we would likely want to finally change our patient ID scheme so we don't need to keep track of this. Likely something along the lines of including a laptop ID, or doing away with this and instead using something like last x digits of MRN + ArriveDtTm. Details to come. See also Facilitated Management of Serial numbers.
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. We are currently developing the EPR Reports Integrator that will help facilitate this (aside from making dealing with reports easier in the first place).
What would be the process for picking up new patients
See Using Cognos Report Integrator to keep track of patients; there would be a filter to limit the list to your location.
If we split by chart number, how do we ensure no pts are missed or duplicated?
- duplication - there could only be duplication if you enter a chart number that is someone else's; you will be able to filter to make sure you don't, and you will be able to see the chart number, so can confirm manually
- missing a patient - we have been testing the Cognos tool to make sure patients are not missed from it; for PatientFollow we will simply filter that list, so if all patients were on it, they should still all be on the split list
- main office can run a check between Cognos Data and our data for the first few weeks to make sure all Cognos data is also in our data
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.
See Regional Server\Documents\PatientFollowDistributionEstimator.xltx for an estimate of a split and an explanation of how it is calculated.
The last two digits of chart numbers are evenly distributed and can be used for this. |
|
Would the LOS have any impact on this sharing plan?
This would not be a problem. |
|
Medical Records requests
Split of shelves would need to become based on Laptop identifier (it may already be...); update HSC Medical Records requests.
EMIPs
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.
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 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.
|
- 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)
Programming that would need to be updated to be able to use a laptop across programs
- cross checks have been checked as part of previous project, should work
- Generupdate / query check_tmp_generate_allowed
- Hider
- Converter functions Hosp, Loc, Prog
- not for cross-programs, but still needs doing: need to make sure the workload splitter takes into account the start and end dates in case the workload assignments have recently changed.
Background
|