Created Variables

Created_Variables_Table is a table in Centralized_data_front_end.mdb which is populated by the query Created_Variables in the same .mdb when the button "calc created variables" on the front screen of the app is pressed. It is used by the statistician for reporting and data extracts.

List of values

• Age in years - see details in Date of Birth
• Length of Stay in days - see details in LOS
• Transfer Delay in days
• APACHE - see details in APACHE Scoring table
  • Total APACHE SCORE
  • Mean Blood Pressure
  • Glasgow Coma Scale - (Glasgow Coma Scale)
  • Acute Physiological points
  • Age points
  • Chronic Health points

Testing...

Template:Potential Change See: Prioritized List of Changes Julie/Trish, let's track testing information for created_variables here... Template:Discussion

• “Transfer_Delay must be blanks instead of large negative values”
  • Got it, I’ll fix that. Well, maybe we should decide if we want to keep to Ed’s std for missing transfer time. I could import/change the actual …3000… dates to nulls, I think. Should I try to change the actual data? That would also make it consistent with how new data will arrive.
    • Sure, I agree that we change those dummy dates to null.
      • I have created update query “1use_only_update_3000_transfer_dates_to_null” in centralized_front_end to update all records in centralized_data.mdb that have a 3000 transfer date and their corresponding transfer times to null. Since this will change much data it should probably be run by Pagasa on a master version of the data after creating a specific backup of the data. Trish, could you please coordinate with Pagasa once the newest front end that includes this is rolled out?

• Is 1/1/3000 9:45 your DEFAULT transf ready date time?
  • It’s not mine, it’s how it shows in Ed’s data when I import it.
    • OK, I am just surprise that there is time – I thought they are all zeroes.
      • I just tried to find a record that has that transfer date time combination and can’t. Could you provide a D_ID?

Calculation error due to dummy year and dummy times from blanks

D_ID	R_age	adm	trans	dis	R_LOS	Transfer_Delay
HSC_MICU--1366	55	7/11/1988	1/1/3000 9:45	7/13/1988	2.427	-369431.771
HSC_SICU--22	83	7/21/1988	1/1/3000 9:45	7/25/1988	3.667	-369419.851
HSC_SICU--34	75	7/28/1988	1/1/3000 9:45	7/28/1988	0.117	-369416.675
HSC_MICU--1383	67	7/29/1988	1/1/3000 9:45	7/30/1988	0.931	-369414.924
HSC_SICU--32	64	7/27/1988	1/1/3000 9:45	8/3/1988	6.865	-369410.802
HSC_MICU--1406	62	8/21/1988	1/1/3000 9:45	8/22/1988	1.062	-369391.802
HSC_SICU--115	63	9/19/1988	1/1/3000 9:45	9/26/1988	7.455	-369356.469
HSC_MICU--1446	85	9/30/1988	1/1/3000 9:45	10/1/1988	0.896	-369351.969
HSC_SICU--127	75	9/28/1988	1/1/3000 9:45	10/1/1988	3.201	-369351.538
HSC_MICU--1439	69	9/24/1988	1/1/3000 9:45	10/2/1988	8.573	-369350.729
HSC_SICU--149	79	10/9/1988	1/1/3000 9:45	10/9/1988	0.292	-369343.531
HSC_SICU--160	65	10/13/1988	1/1/3000 9:45	10/14/1988	0.854	-369338.865
HSC_SICU--153	76	10/11/1988	1/1/3000 9:45	10/21/1988	10.403	-369331.844

Transfer Delay

• As per Julie: Transfer delay should not occur to those who move to another ICU. Transfer_Delay must be blanks instead of large negative values – see Created_variable table below.
  • Tina: Is that a part of the definition of Transfer Delay? I had never heard of it and it’s not in Transfer_Delay . So generally, is it the following?

Transfer delay = 
iif(location = <an ICU>, 
iif(discharge_to <> <other ICU>, 
dischargedttm – transferdttm, 
0), 
dischargedttm – transferdttm,)

• Julie: Transfer delay is derived from transfer ready date_time and discharge date_time. For CC, only transfer to HSC IICU requires transfer ready date_time (or delays) , other ICUs (MICU,SICU,CCU) don’t require it Transfer_Ready_date_and_time

Background

The system replaces Created Variables in TMSX or Med TMS that were created by TMSX and MedTMS.