Multiple Encounter: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
m (Ttenbergen moved page Multiple Encounters and Readmissions to Multiple Encounter without leaving a redirect: article split out into this, Re-admission and Continuous Stay, re-naming accordingly.)
m (Text replacement - "Re-admission" to "Readmission")
 
(15 intermediate revisions by the same user 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 [[Re-admission]]. If never discharged in between encounters, patient may be a [[Continuous Stay]].
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]]'''.  
* Multiple encounters are considered of same patient if the combination of following fields match:
** PHIN
** Names (First and Last)
** DOB
** Gender
** Hospital Chart# if admitted in the same hospital
* Data quality check programs are being run after every appending of new data to the master database of both Critical Care and Medicine.  The programs find errors in  records not matching in any of the above combination of fields.
** The Data Processor runs the two  programs at her local computer C:\TMSX\CombLookupProof.exe followed by C:\TMSX\CombinedErrorsFinder.exe in that order.
** The Statistician runs the SAS program in the shared folder  X:\Julie\SAS\CriticalCare\chkchartdupCCnMED.sas .
** The Data Processor fixes any errors found ensuring the consistencies in the demographics of same patient on both databases.


== Simplification? ==
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]]'''.
Considering that the vetting process ensures that PHINs are fixed for all patients, why would we match on more than one field? Ttenbergen 13:02, 2014 January 16 (CST) {{discussion}]


== 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 Check List}}
== Related Articles ==
{{Related Articles}}


[[Category: Statistical Analysis]]
[[Category: Statistical Analysis]]
[[Category: Questions Statistician]]
[[Category: Multiple Encounter | * ]]
[[Category: Multi-encounter check | *]]

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: