Multiple Encounter: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
m (Text replacement - "Re-admission" to "Readmission")
 
(25 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Patients may show up in our database repeatedly either during the same hospital stay or at a later time. If they show up at a later time, but soon after the last hospital stay, they may qualify as "readmission", which we report in '''<in which, monthly, quarterly, annual or all?>'''
Patients may show up in our database repeatedly. Our [[L_Log]] records are patient-ward-stay based. Once the [[data processor]] completes the [[centralized data Vetting Process]] (i.e. [[PHIN field|PHINs]] are checked and PseudoPHINs are generated) the PHIN field can be used for linking L_Log records for the same patient. This combining data is stored in [[L Person table]] by [[Encounter processing]].


== Multiple Encounters ==
If a patient is never discharged in between L_Log entries it may be a '''[[Continuous Stay]]'''.
<details>
What is the cut-off for continuous stay detection when moving between ICUs and/or wards? E.g. if patient is discharged from one ward at 0800, how late can he arrive at the next ward and still be considered a continuous stay?


What are the fields that have to match to consider two encounters the same patient?
If a patient is discharged and then admitted again at a later time, but soon after the last hospital stay, they may qualify as '''[[Readmission]]'''.


== Continuous Hospital Stay ==
== Multiple encounter longitudinal consistency checks ==
The [[statistician]] uses data from [[Admit From & Discharged To]], [[Med Var 1 - Admit-from Ward]] and [[Med Var 2 - Discharge-to Ward]] to
For patients encountered repeatedly some data should be consistent between stays.  
* link profiles from one ward to another when both wards are within the database program
* detect a likely continuous stay when a pt is discharged from one of our wards to a non-collected ward and then re-admitted to one of our wards from the same non-collected ward.  


== Readmissions ==
The [[data processor]] runs a set of checks during vetting that attempts to find and make consistent the records for patients encountered previously.  
For our purposes, readmissions are admissions of patients who were recorded by our database recently.  


=== ICU Definition ===
{{Data Integrity Check List}}
For ICU, a readmission is a patient where
* (admit date/time) - (most recent ICU discharge date/time) <= 72 hours
* is '''not''' admitted for planned and scheduled surgery
* might be readmitted from Ward or outside hospital
====Discussion====
* why are we considering the most recent ICU discharge date/time only?[[User:Ttenbergen|Ttenbergen]] 11:36, 28 May 2008 (CDT)


=== Medicine Definition ===
== Related Articles ==
For medicine, a readmission is a patient where
{{Related Articles}}
* (admit date/time) - (most recent discharge date/time to the hospital) <= 7 days after their most recent discharge time to the hospital
* is admitted from outside hospital
* (Legacy: planned surgery used to be excluded, but this stopped because of insufficient data when we stopped collecting some APACHE elements in the medicine program '''<when?>''')


 
[[Category: Statistical Analysis]]
{{stub}}
[[Category: Multiple Encounter | * ]]
[[Category:Statistical Analysis]]
[[Category: Questions_General_Collection]]

Latest revision as of 22:10, 2021 April 29

Patients may show up in our database repeatedly. Our L_Log records are patient-ward-stay based. Once the data processor completes the centralized data Vetting Process (i.e. PHINs are checked and PseudoPHINs are generated) the PHIN field can be used for linking L_Log records for the same patient. This combining data is stored in L Person table by Encounter processing.

If a patient is never discharged in between L_Log entries it may be a Continuous Stay.

If a patient is discharged and then admitted again at a later time, but soon after the last hospital stay, they may qualify as Readmission.

Multiple encounter longitudinal consistency checks

For patients encountered repeatedly some data should be consistent between stays.

The data processor runs a set of checks during vetting that attempts to find and make consistent the records for patients encountered previously.

Data Integrity Checks (automatic list)

 AppStatus
Check VAP acquired only first encounterCentralized data front end.accdbdeclined

Related Articles

Related articles: