PatientFollow Project: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
 
(42 intermediate revisions by 4 users not shown)
Line 1: Line 1:
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.
This page describes how collection of incoming patients is split across data collectors


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.  
== 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 patient#PatientFollow Project considerations|John or Jane Doe patient]]s.
 
== 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.
 
== Fallback process when Cognos data is unavailable ==
See [[Cognos downtime procedure]]
 
== Medical Records requests ==
Shelf split based on [[Laptop identifier]], see [[HSC Medical Records requests]] for details.
 
== Actual chart number split per site and per laptop ==
The split is automatically reflected in [[Cognos2 Service Starter]], no additional filtering needed. The corresponding data is stored in [[S PatientFollow distribution table]].
 
=== 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.
 
=== Assignment changes ===
See [[Processes around changing a PatientFollow assignment]]
 
=== Exception: HSC_IICU ===
See [[HSC_IICU_Collection_Guide#Workload_Sharing_for_HSC_IICU]]
 
== 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]].


== Roll-out ==
=== Programming that would need to be updated to be able to use a laptop across programs ===
This will be rolled out
* cross checks have been checked as part of previous project, should work
* at the Grace starting 2020-09-01
* Generupdate / query check_tmp_generate_allowed
* at HSC starting 2020-10-15 (Thursday after Thanksgiving)
* Hider
* Converter functions Hosp, Loc, Prog


=== Implementation discussions ===
{{Collapsable
If there are questions or problems with the change, please put a discussion here.
| always= old process and questions that were addressed
| full=


== Identifying admissions / Starting collection ==
=== Old Process ===
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).  
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. {{PAGENAME}} was set up to change to a system where one collector keeps following a patient.  


=== What would be the process for picking up new patients ===
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.  
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? ===
=== 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
* '''duplication''' - there could only be duplication if you enter a chart number that is someone else's; your [[Cognos2 Service Starter]] will only show your patients, so you would not duplicate someone else's, and any risk of duplicating your own is no higher than it was with the old process.
* '''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
* '''missing a patient''' - we have been testing the [[Cognos EPR Report]] 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
** 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


Line 26: Line 54:
| always= This would not be a problem.  
| always= This would not be a problem.  
| full= * 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.}}
| full= * 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.}}
=== Medical Records requests ===
Split of shelves would need to become based on [[Laptop identifier]] (it may already be...);
{{Discuss |
* Could an HSC collector please have a look at [[HSC Medical Records requests]] to make sure it is consistent with these changes? Once you have dealt with that, please take out this discussion. Ttenbergen 21:34, 2020 October 15 (CDT)
}}


=== [[EMIP]]s ===
=== [[EMIP]]s ===
[[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.
[[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]].


== What would be the actual chart number split per site and per collector ==
=== 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.  
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.  
The actual split is implemented using the [["Mine! Mine!" button]]. See [[s_PatientFollow_distribution table]] for master version of current distribution.
The excel sheet with Julie's analysis is at S:\MED\MED_CCMED\ChartLastDigitAnalysis\NormalizedCounts_Comparison\2_Paired T-Test and Data.xlsx
{{Collapsable  
{{Collapsable  
| always= The last two digits of chart numbers are evenly distributed and can be used for this.
| always= The last two digits of chart numbers are evenly distributed and can be used for this.
| full= * 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)
| full= * 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 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. Additional analysis info is in S:\MED\MED_CCMED\ChartLastDigitAnalysis\NormalizedCounts_Comparison\2_Paired T-Test and Data.xlsx
*** Additional analyses were done separately for Medicine and Critical Program for each site and 1) each year, 2) each quarter and 3 )each month to determine any seasonal variation across time. The distributions are generally uniform across subgroups with relatively few peaks.  However, there seems to be some seasonal variation  which is observed more in Critical Care than Medicine Program. The histograms are also in  in ''X:\CCMDB_Special_Projects\Project_PatientFollow_ChartNumberDistribution''.
*** Additional analyses were done separately for Medicine and Critical Program for each site and 1) each year, 2) each quarter and 3 )each month to determine any seasonal variation across time. The distributions are generally uniform across subgroups with relatively few peaks.  However, there seems to be some seasonal variation  which is observed more in Critical Care than Medicine Program. The histograms are also in  in ''X:\CCMDB_Special_Projects\Project_PatientFollow_ChartNumberDistribution''.
** 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'' .
** 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.}}
* I think this is a good starting strategy to allocate patients among the data collectors proportionately in each site.}}
== Entering into the laptop ==
The initial ward would need to be entered as usual. For stays on subsequent wards, [[Cognos Admitter]]/[[Patient Viewer Tab Cognos ADT]] and if need be the [[Patient copier button]] can be used to create the next record.
== Fallback process when Cognos data is unavailable ==
{{Discuss |
* Discussing this with Grace now, details to follow. }}
== 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
* 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.


== Process to identify Medicine patients from EPR at STB ==
== Process to identify Medicine patients from EPR at STB ==
Line 83: Line 82:


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.
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 ===
=== 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.  
The process to identify patients for collection in our database is currently ill defined, complex and different between collectors and sites.  


{{Discuss |
*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? [[User:Ppiche|Pamela Piche]] 10:19, 2019 September 5 (CDT)
*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? [[User:Ppiche|Pamela Piche]] 10:19, 2019 September 5 (CDT)}}
** There would be no extra lists, the allocation would happen automatically within Cognos, so the processes you guys have now would just go away, you would simply enter the patient that show up on your [[CSS]], and you wouldn't even see the ones that are not yours. RE concerns about patients that may be missing from Cognos, that is a separate issue: if pts are missing from Cognos, and still don't show up on the 2nd day after their admission, you need to tell me so we can troubleshoot that. If those are addressed then this should no longer be relevant to patientFollow. If this answers the concerns, please remove this discussion. If not, please elaborate. Ttenbergen 21:41, 2020 October 15 (CDT)
}}
 
== Background ==
We needed to implement {{PAGENAME}} 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.
 
=== Transition dates ===
Since this demarcation comes up repeatedly, use [[query created_PatientFollow]] so this is done consistently.


*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.[[User:Mlagadi|Mlagadi]] 12:32, 2019 September 5 (CDT)
{{Collapsable
| always= Transition dates
| full=


== Background ==
Patient Follow one record one episode model
{{Discuss |  
====GRA====
* need to write up reasons why we need to do this; one would be to reduce / eliminate [[Coordination of data between collectors]]
GRA Med & GRA_CC
*patient allocation by Chart last two digits starting 2020-Oct-01;  All patients who have an ''Accept DtTm'' or [[Dispo DtTm field | Dispo DtTm]] ON or AFTER 2020-Oct_1, the collector will apply the patient follow model
====HSC====
HSC Med & HSC CC (MICU) (SICU) 
*(Excludes HSC IICU)
**All patients who have an ''Accept DtTm'' or [[Dispo DtTm field | Dispo DtTm]] ON or AFTER '''2020-Oct-15''' the collector will apply the patient follow model
** In the Task meeting '''Nov 30,2021''', it was decided that HSC CC has to go back to the old system, continuous admissions at HSC MICU and HSC SICU had been changed and made into 2 separate records onwards.  From '''2020-Oct-15''', there were  only 11 vetted  records  having such case  and they were un-winded.
====STB====
STB Med
*All patients who have a ''Accept DtTm'' or [[Dispo DtTm field | Dispo DtTm]] ON or AFTER '''2020-Oct-15''', the collector will apply the patient follow model


}}
STB ICU's
* S7-STB MICU & S9-STB ACCU >= '''2020-10-15'''
* S8-STB_CICU - Stephanie Cortilet: since Steph pre-enters, start with Patients with ''Accept DtTm'' >= 2020-10-16
** [[STB_CC#Decision to not combine collection of STB CC on one laptop]] but some of the [[Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry]] still apply.
}}


== Related articles ==  
== Related articles ==  

Latest revision as of 15:14, 2023 May 31

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.

Fallback process when Cognos data is unavailable

See Cognos downtime procedure

Medical Records requests

Shelf split based on Laptop identifier, see HSC Medical Records requests for details.

Actual chart number split per site and per laptop

The split is automatically reflected in Cognos2 Service Starter, no additional filtering needed. The corresponding data is stored in S PatientFollow distribution table.

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.

Assignment changes

See Processes around changing a PatientFollow assignment

Exception: HSC_IICU

See HSC_IICU_Collection_Guide#Workload_Sharing_for_HSC_IICU

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
  • Hider
  • Converter functions Hosp, Loc, Prog
old process and questions that were addressed   

Old Process

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.

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; your Cognos2 Service Starter will only show your patients, so you would not duplicate someone else's, and any risk of duplicating your own is no higher than it was with the old process.
  • missing a patient - we have been testing the Cognos EPR Report 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

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.

EMIPs

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.

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. Additional analysis info is in S:\MED\MED_CCMED\ChartLastDigitAnalysis\NormalizedCounts_Comparison\2_Paired T-Test and Data.xlsx
      • Additional analyses were done separately for Medicine and Critical Program for each site and 1) each year, 2) each quarter and 3 )each month to determine any seasonal variation across time. The distributions are generally uniform across subgroups with relatively few peaks. However, there seems to be some seasonal variation which is observed more in Critical Care than Medicine Program. The histograms are also in in X:\CCMDB_Special_Projects\Project_PatientFollow_ChartNumberDistribution.
    • 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.

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)
    • There would be no extra lists, the allocation would happen automatically within Cognos, so the processes you guys have now would just go away, you would simply enter the patient that show up on your CSS, and you wouldn't even see the ones that are not yours. RE concerns about patients that may be missing from Cognos, that is a separate issue: if pts are missing from Cognos, and still don't show up on the 2nd day after their admission, you need to tell me so we can troubleshoot that. If those are addressed then this should no longer be relevant to patientFollow. If this answers the concerns, please remove this discussion. If not, please elaborate. Ttenbergen 21:41, 2020 October 15 (CDT)

Background

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.

Transition dates

Since this demarcation comes up repeatedly, use query created_PatientFollow so this is done consistently.

Transition dates   

Patient Follow one record one episode model

GRA

GRA Med & GRA_CC

  • patient allocation by Chart last two digits starting 2020-Oct-01; All patients who have an Accept DtTm or Dispo DtTm ON or AFTER 2020-Oct_1, the collector will apply the patient follow model

HSC

HSC Med & HSC CC (MICU) (SICU)

  • (Excludes HSC IICU)
    • All patients who have an Accept DtTm or Dispo DtTm ON or AFTER 2020-Oct-15 the collector will apply the patient follow model
    • In the Task meeting Nov 30,2021, it was decided that HSC CC has to go back to the old system, continuous admissions at HSC MICU and HSC SICU had been changed and made into 2 separate records onwards. From 2020-Oct-15, there were only 11 vetted records having such case and they were un-winded.

STB

STB Med

  • All patients who have a Accept DtTm or Dispo DtTm ON or AFTER 2020-Oct-15, the collector will apply the patient follow model

STB ICU's

Related articles

Related articles: