This page describes how collection of incoming patients is split across data collectors
Identifying admissions / Starting collection
Patients are assigned to laptops by the last two digits of their Chart number. Cognos2 Service Starter automatically filter them, just follow Using Cognos2 to keep track of patients. Special considerations apply to John or Jane Doe patients.
Entering into the laptop
The initial ward would need to be entered as usual. For stays on subsequent wards, Cognos2 Service Starter and Patient Viewer Tab Cognos ADT2 can be used to create another line in the Boarding Loc and Service tmp entry.
Data would go into one profile unless a patient leaves the service. For example, if a pt starts in medicine, then goes to ICU, and then comes back to medicine, then coming back to medicine would mean starting a new profile.
Medical Records requests
Actual chart number split per site and per laptop
The split is automatically reflected in Cognos2 Service Starter, no additional filtering needed.
Viewing the numbers assigned to a given laptop
The assignment is a matter of laptop, chart number ending and the date at which point a specific distribution started. We don't want to store it here on the wiki because it is kind of messy and hard to keep updated. Use "Show PatientFollow allocation" button to see which numbers are assigned to the laptop you are working on during which timeframe.
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.
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
- Converter functions Hosp, Loc, Prog
|old process and questions that were addressed|
Our database used to collect patient ward stays, which meant the data of a patient could be processed by several collectors during the admission. This lead to extra, wasted work of different collectors familiarizing themselves with the same patient. PatientFollow Project was set up to change to a system where one collector keeps following a patient.
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).
If we split by chart number, how do we ensure no pts are missed or duplicated?
Would the LOS have any impact on this sharing plan?
EMIP's will be distributed to collectors/laptops 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. Further, there will no longer be special collection instructions for EMIPs under Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry.
How was the distribution initially defined and validated?
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.
Process to identify Medicine patients from EPR at STB
Breakdown per unit:
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.
We needed to implement PatientFollow Project in order to be able to streamline collection. Doing it by location meant multiple records per admission, Coordination of data between collectors, and other issues. Also, it prevented flexible re-allocation of workload according to differing collector EFTs - under the new scheme we can split patient load according to EFT.
Patient Follow one record one episode model
GRA Med & GRA_CC
HSC Med & HSC CC (MICU) (SICU)