Auto Data Dictionary: Difference between revisions
Ttenbergen (talk | contribs) (just a start) |
Ttenbergen (talk | contribs) m (m) |
||
Line 2: | Line 2: | ||
== L_Log == | == L_Log == | ||
===Pat_ID === {{:Pat_ID}} | ===Pat_ID === | ||
=== LastName === {{: | {{:Pat_ID}} | ||
=== FirstName === {{: | === LastName === | ||
=== PHIN === {{: PHIN}} | {{:Last Name}} | ||
=== Birth === {{: Birth}} | === FirstName === | ||
=== Chart === {{: Chart}} | {{:First Name}} | ||
=== start_Time === {{: | === PHIN === | ||
=== start_Date === {{: | {{:PHIN}} | ||
=== Notes === {{: Notes}} | === Birth === | ||
{{:Date of Birth}} | |||
=== Chart === | |||
{{:Chart}} | |||
=== start_Time === | |||
{{:Start time}} | |||
=== start_Date === | |||
{{:Start date}} | |||
=== Notes === | |||
{{:Notes field}} | |||
==todo== | |||
=== FinalCheck === {{: FinalCheck}} | === FinalCheck === {{: FinalCheck}} | ||
=== R_Location === {{: R_Location}} | === R_Location === {{: R_Location}} |
Revision as of 14:59, 2016 June 27
This article transcludes the articles for our data fields, or ideally their <onlyinclude> sections.
L_Log
Pat_ID
Data Element (edit) | |
Field Name: | Pat_ID |
CCMDB Label: | Serial |
CCMDB tab: | Top Row |
Table: | L_CCI_Picklist table, L_CCI_Component table, L Como table, L Dxs table, L ICD10 table, L_Labs_Flowsheet table, L Log table, L PCH table, L_PHI table, L_Pharm_Flowsheet table, L TISS Form table, L TISS Item table, L TmpV2 table |
Data type: | number |
Length: | Long Integer |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 1988-07-11 |
End Date: | 2300-01-01 |
Sort Index: | 1 |
The Pat_ID field contains a unique-per-laptop identifying number for patient ward admissions. See Serial number.
Pat_ID is used in CCMDB.accdb. In CFE / Centralized_data.mdb, D_ID is the equivalent. D_ID is the combination of the Service/Location and the Pat_ID.
Tables
- Used by CCMDB.accdb, where it is the primary identifier.
- Used by Centralized_data.mdb, where it is only kept in L_Log table for reference.
Related Articles
LastName
Data Element (edit) | |
Field Name: | LastName |
CCMDB Label: | Last Name |
CCMDB tab: | Top Row |
Table: | L_Log table, L_PHI table |
Data type: | string |
Length: | 40 |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 1988-07-11 |
End Date: | 2300-01-01 |
Sort Index: | 2 |
Last Name of patient
See also FirstName field.
Enter the patient name as in EPR.
Data Processing at main office
Name changes over time
If an inconsistency is found between old and current records,
- edit only if there is something incorrect, e.g. a typo
- use the value in the EPR for the correction
- we change the old entries to be consistent with the most current entry
Information about other names for the patient may be available in Alias ID collection.
See also: Crosschecking data with Manitoba Health
Minimal Data Set
This entry is part of the Minimal Data Set. Special collection instructions apply, see that page for more info.
L_PHI vs L_Log
This field is stored in the L_PHI table in CFE but in the L_Log table in CCMDB.accdb. See L_PHI table for details why.
Data Integrity Checks (automatic list)
none found
Legacy info
Legacy Content
This page contains Legacy Content.- Explanation: we used to change names around for consistency but stopped doing this.
- Successor: use rules above
Click Expand to show legacy content.
We used to standardize names to make it easier to keep them consistent over time. We decided to stop using our own standards to facilitate comparison with Manitoba Health and similar data. 13:34, 2015 April 27 (CDT) It used to be:
- if a name changed we retained the original one and changed new encounters of the patient to the old one.
- for first names we decided not to use hyphens if there was more than one, and to preferably only have one first name used
- last names that use two names were hyphenated
Related Articles
FirstName
Data Element (edit) | |
Field Name: | FirstName |
CCMDB Label: | First Name |
CCMDB tab: | Top Row |
Table: | L_Log table, L_PHI table |
Data type: | string |
Length: | 40 |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 1988-07-11 |
End Date: | 2300-01-01 |
Sort Index: | 3 |
Last Name of patient
See also LastName field.
Enter the patient name as in EPR.
Data Processing at main office
Name changes over time
When people change names, eg marriage, the Data Processor changes all old records to be consistent with the current one.
If an inconsistency is found between old and current records,
- edit only if there is something incorrect, e.g. a typo
- use the value in the EPR for the correction
- we change the old entries to be consistent with the most current entry
Information about other names for the patient may be available in Alias ID collection.
Minimal Data Set
This entry is part of the Minimal Data Set. Special collection instructions apply, see that page for more info.
L_PHI vs L_Log
This field is stored in the L_PHI table in CFE but in the L_Log table in CCMDB.accdb. See L_PHI table for details why.
Data Integrity Checks (automatic list)
none found
Legacy info
Legacy Content
This page contains Legacy Content.- Explanation: we used to change names around for consistency but stopped doing this.
- Successor: use rules above
Click Expand to show legacy content.
We used to standardize names to make it easier to keep them consistent over time. We decided to stop using our own standards to make it facilitate comparison with Manitoba Health and similar data. 13:34, 2015 April 27 (CDT) It used to be:
- if a name changed we retained the original one and changed new encounters of the patient to the old one.
- for first names we decided not to use hyphens if there was more than one, and to preferrably only have one first name used
- last names that use two names were hyphenated
Related Articles
PHIN
Data Element (edit) | |
Field Name: | PHIN |
CCMDB Label: | PHIN |
CCMDB tab: | Top Row |
Table: | L_Log table, L_PHI table |
Data type: | number |
Length: | Long Integer |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 1988-07-11 |
End Date: | 2300-01-01 |
Sort Index: | 4 |
The patient's PHIN .
The PHIN (Personal Health Information number) is a unique nine-digit numeric identifier assigned by Manitoba Health to every person registered for health insurance in Manitoba. For patients who are not registered with Manitoba Health we assign a Pseudo PHIN.
MB Health PHINs only
Manitoba Health PHIN numbers only.
If patient permanently resides outside of the province of Manitoba the Province field should not be MB and the PHIN field should be left blank.
Please make every effort to obtain this information and call medical records to help.
Possibility of adding other Province's PHINs
old discussion, result: not at this time |
|
Special Cases
Location Manitoba and no PHIN
There are scenarios where a PHIN will not be available for a Manitoba patient, including but not limited to
- immigrants and international students on visas
- some prison inmates
In these and similar cases, use 999999999 as the PHIN. The data processor will assign a Pseudo PHIN.
International Students
Profiles of international students may or may not have a PHIN. At some point, students have at times been covered[1], then been required to get a specific U of M insurance[2], and as of 2021-07 appear to have some choice of how they insure, although insurance is mandatory [3]archive.
Location Outside Manitoba and no PHIN
PHIN must be entered by data collector as blank. A Pseudo PHIN will be entered by the data processor after file is appended to master database.
Canadian Forces patients
PseudoPHIN
Since the PHIN is used as a unique identifier for patients to detect repeat and continuous visits, a "pseudoPHIN" is assigned for patients who don't have a PHIN. At this point, pseudoPHINS are assigned by Pagasa, see see Generating PseudoPHINs.
Use started in 1999 and starts in '1' and as of Mar 18, 2013 our last Pseudo number was 7043.
We observed that there was a drop in the number of PseudoPHINs during the part of COVID. We confirmed that fewer out-of-province patients would have been accepted during this time, so that change is legitimate.
Multiple PHINs or PHIN changes over time
People may change PHINs over time or have multiple PHINs. This can occur in 3 main ways:
- moving from OOP to MB,
- moving from MB to OOP, and
- a single individual having multiple PHINs (usually somethign went wrong in registration with MB Health)
For the purpose of identifying "same person", and uniformity, we will enter the current/most PHIN or PseudoPHIN into the PHIN field of all encounters of that patient in our database. Earlier PHINs or PseudoPHINs will be retained in Alias ID collection. This may mean that we change an existing PHIN to a PseudoPHIN. This may trigger some errors in our cross checks; if so, appropriate records will be added to the L_Problem table so the error goes away.
Minimal Data Set
This entry is part of the Minimal Data Set. Special collection instructions apply, see that page for more info.
L_PHI vs L_Log
This field is stored in the L_PHI table in CFE but in the L_Log table in CCMDB.accdb. See L_PHI table for details why.
Data Integrity Checks (automatic list)
none found
Related articles
Birth
Data Element (edit) | |
Field Name: | Birth |
CCMDB Label: | DOB |
CCMDB tab: | Top Row |
Table: | L_Log table, L_PHI table |
Data type: | date |
Length: | not stated |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 1988-07-11 |
End Date: | 2300-01-01 |
Sort Index: | 5 |
Date of Birth (DOB) is the data a patient was born.
It is used to calculate age. See also John or Jane Doe patients.
L_PHI vs L_Log
This field is stored in the L_PHI table in CFE but in the L_Log table in CCMDB.accdb. See L_PHI table for details why.
Cross checks
Data Integrity Checks | |
Summary: | The minimum age allowed is 10, the maximum age allowed is 120. |
Related: | Date of Birth |
Firmness: | hard check |
Timing: | complete |
App: | CCMDB.accdb |
Coding: | function Validate_DOB |
Uses L Problem table: | not relevant for this app |
Status: | implemented |
Implementation Date: | 2008-01-01 |
Backlogged: | true |
CCMDB.accdb cross checks triggering for correct values
If the actual correct data leads to a cross-check error CCMDB.accdb will not allow you to send. In that case, enter a value that is acceptable and then email the Data Processor using the "generate email" button.
Data Integrity Checks (automatic list)
none found
Related articles
Chart
Data Element (edit) | |
Field Name: | Chart |
CCMDB Label: | Chart |
CCMDB tab: | Top Row |
Table: | L_Log table, L_PHI table |
Data type: | string |
Length: | 8 |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 1988-07-11 |
End Date: | 2300-01-01 |
Sort Index: | 6 |
The number used by medical records to uniquely identify a patient's chart; it is different for the same patients at different hospitals.
The number is assigned to a patient by Admitting. This is done once the patient has been seen by Triage in ER or new to the hospital for clinics, testing and various workups. This number remains the patient's chart number for all hospital visits, admissions, tests, etc.
Collection instructions
Leading Zeros
If your chart number system uses leading zeros, don't enter the leading zeros, start with the first non-zero number.
Dashes near the end of the number
EPR sometimes lists something like MRN 123456-1; in that case, we code 1234561, i.e. leave out the dash, but code the trailing number.
Unclear or changing chart numbers
See
Minimal Data Set
This entry is part of the Minimal Data Set. Special collection instructions apply, see that page for more info.
Data Processing
The Centralized_data_front_end.accdb has queries that make sure that the chart number for each Hospital site is the same for the same patient and make sure the chart number has valid format.
- query PL_SameCHART_Site_Diff_PHIN
- query PL_SamePHIN_Site_Diff_chart
- query PL Chart 9 Digit
The Data Processor fixes any inconsistencies found from these queries by crosschecking from EPR and adds the alias identifier to the tmp project Alias ID collection.
In addition, the Statistician uses SAS to check key identifiers so they are consistent for same patient including Hosp chart etc.
L_PHI vs L_Log
This field is stored in the L_PHI table in CFE but in the L_Log table in CCMDB.accdb. See L_PHI table for details why.
Cross checks
Data Integrity Checks (automatic list)
none found
Related articles
start_Time
Data Element (edit) | |
Field Name: | start_Time |
CCMDB Label: | not stated |
CCMDB tab: | not stated |
Table: | L_Log table |
Data type: | date |
Length: | not stated |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 2011-02-25 |
End Date: | 2300-01-01 |
Sort Index: | 8 |
Time the record was created on the data collector's laptop; created automatically by CCMDB.accdb.
See also Start_Date field. The two are different fields due to technical limitations when it was first created. See Start Date and Time for info on how the combined data is used.
Related articles
start_Date
Data Element (edit) | |
Field Name: | start_Date |
CCMDB Label: | not stated |
CCMDB tab: | not stated |
Table: | L_Log table |
Data type: | date |
Length: | not stated |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 2011-02-25 |
End Date: | 2300-01-01 |
Sort Index: | 7 |
Date the record was created on the data collector's laptop; created automatically by CCMDB.accdb.
See also Start Time field. The two are different fields due to technical limitations when it was first created. See Start Date and Time for info on how the combined data is used.
Related articles
Notes
Data Element (edit) | |
Field Name: | Notes |
CCMDB Label: | Notes |
CCMDB tab: | Top Row |
Table: | L_Log table |
Data type: | memo |
Length: | not stated |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 1988-07-11 |
End Date: | 2300-01-01 |
Sort Index: | 9 |
Used by data collectors to keep notes during collection.
The notes field expands to a bigger form when you double-click on it.
Usage of the notes field
The notes field was set up to be a free-for-all where collectors can store any info they want. This resulted in non-standardized collection practices which result in problems during vacation coverage or on shared wards.
Guidelines
- Please do not write copious history notes from charts into this note section. This is only for reminders or points needed to do your work, dates where you left off at or any follow up of info, test etc., that need to be done by yourself or for others who help collect on your laptop. Notes have to be clear to others.
Patients being sent
- For patients you are ready to send, make sure you note explanations for data values that you think might cause call-backs from the Data Processor or Statistician. For example:
- Extreme data that was confirmed as correct:
- extreme physiological APACHE values, eg Sys BP of 50 valid , see APACHE_Scoring_table and APACHE_physiological_variable_collection#Exceptionally_high_or_low_values
- to verify imaging counts ie. 2 day LOS and 12 CXR's done, you may want to write a short note that the imaging counts are correct or have been double checked
- Upon review of the Notes field, and prior to sending, please delete any data that would not be used to clarify extreme data or outliers. The main office will use this to clarify extreme data, so deleting excess data in this field will help streamline this process for the main office.
Up-to where/when collection is complete
- STB - where we have left off reading in the EPR notes by entering the date/time last read
- HSC- where we have left off checking orders, pharm, counting EPR labs, reading notes by entering the date/time last read.
Diagnoses or other data that needs to be reviewed or checked
Can be used to document suspected diagnoses (which would not be coded in ICD10 even for incomplete records, as per ICD10 collection#"Suspected" Diagnoses.
Supplemental data
- to clearly define some admit diagnoses-the ones that come up as other problems, other problems when you enter them.
- be aware that 99% diagnosis data analysis in the main office will not look at the notes field, as usually there are just filters or counts on the ICD10 dx entries.
- to enter info on base creatinine, bmi, or other tidbits of info that are useful to know.
- to define what exactly needs to be entered, when a profile is only partially completed.
Automatic population of notes field for newly entered patients
We tried to standardize field into a kind of form, but collection practice is too non-standard to come up with a format that worked. |
Just being curious if the notes field is a free space for optional additional info....what specific problems did this cause?
Recently a format was implemented and placed into the notes field. We would like to know if this format is helpful and if you use it. Please indicate here if you use it or not and any comments you would like to make regarding this:
|
Related articles
todo
=== FinalCheck === FinalCheck === R_Location === R Location === R_dc_treat === The concept encoded by this is slightly different than other End-of-life related data so it can not be transferred into new fields that encode related concepts, so we will keep it in the Centralized data.mdb's L Log table. It has been removed from CCMDB.accdb.
![]() |
_dev_CFE_Data
|
|
Legacy Content
This page contains Legacy Content.- Explanation: stopped collection in Medicine
- Successor: various tmp and dx codes relating to palliative care and End-of-life related data
Click Expand to show legacy content.
Legacy Content
This page contains Legacy Content.- Explanation: This is a legacy data field, its DataElementEndDate is in the past.
- Successor: No successor was entered
Click Expand to show legacy content.
Data Element (edit) | |
Field Name: | R_dc_treat |
CCMDB Label: | not stated |
CCMDB tab: | not stated |
Table: | L_Log table |
Data type: | string |
Length: | 50 |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 1988-07-11 |
End Date: | 2022-05-10 |
Sort Index: | 12 |
"DC" for critical care patients if life-support treatment is terminated, blank for all others.
This field was also collected in Medicine until 2013-07-04. Collection stopped because the distinction is not clear enough for coding on a medicine ward.
Defined as terminal withdrawal with expectation of death of:
- invasive mechanical ventilation (ET tube or trach)
- vasopressors or inotropes
- ECMO, VV, ECMO, VA
- VAD (Ventricular assistive device)
See Also
See: Comfort Care
Log
- 2022-05-10 removed from collection screen
Related articles
=== R_AdmitFrom === Admit from is a legacy field that used to encode the hospital and ward from where a patient was admitted. See Previous Location field. The Discharge to is a legacy field that used to encode the hospital and ward that a patient was discharged to. See Dispo field. === R_DischargedTo === Admit from is a legacy field that used to encode the hospital and ward from where a patient was admitted. See Previous Location field. The Discharge to is a legacy field that used to encode the hospital and ward that a patient was discharged to. See Dispo field. === R_HospitalPrevious === The Hospital previous field contains the previous hospital for patients who were admitted from another hospital outside of Winnipeg. === R_Province === R Province === R_Sex === R Sex === R_Type === R Type === R_SurviveExpire === The Survive / Expired field used to track if a patient survived to be discharged. Options are Survive, Expire. === R_AdmDate === The concept of "Admit date and time" is not as simple as it might seem due to the way we use it in reporting, and how it has been stored over time.
Current definition as of 2021-04-21
The most recent version is Admit DtTm as derived by Created_AdmitDtTm query
Previous definitions
Legacy Content
This page contains Legacy Content.- Explanation: Created_AdmitDtTm query
- Successor: Created_AdmitDtTm query
Click Expand to show legacy content.
Arrive DtTm and Accept DtTm
The Admit date and time used to designate the time a patient was admitted to the ward/unit. For critical care it designated the time the patient physically arrived on the unit, the one for medicine when the patient was accepted to the medicine service.
Collection instructions for this article were transferred to Arrive DtTm and Accept DtTm as appropriate and deleted from here to prevent accidental use of outdated information. See 2016-07-03 history of the article for old instructions, such as when this was encoded as field R_AdmDate.
CCMDB Data Integrity Checks
- Minimal_Data_Set#CCDMB_Data_Integrity_Checks for patients with Dispo DtTm before 2016-07-01
Date and time formats
Data use
Among other things, the times are used to generate statistics about
See also
=== R_AdmTime === The concept of "Admit date and time" is not as simple as it might seem due to the way we use it in reporting, and how it has been stored over time.
Current definition as of 2021-04-21
The most recent version is Admit DtTm as derived by Created_AdmitDtTm query
Previous definitions
Legacy Content
This page contains Legacy Content.- Explanation: Created_AdmitDtTm query
- Successor: Created_AdmitDtTm query
Click Expand to show legacy content.
Arrive DtTm and Accept DtTm
The Admit date and time used to designate the time a patient was admitted to the ward/unit. For critical care it designated the time the patient physically arrived on the unit, the one for medicine when the patient was accepted to the medicine service.
Collection instructions for this article were transferred to Arrive DtTm and Accept DtTm as appropriate and deleted from here to prevent accidental use of outdated information. See 2016-07-03 history of the article for old instructions, such as when this was encoded as field R_AdmDate.
CCMDB Data Integrity Checks
- Minimal_Data_Set#CCDMB_Data_Integrity_Checks for patients with Dispo DtTm before 2016-07-01
Date and time formats
Data use
Among other things, the times are used to generate statistics about
See also
R_TRDate
Legacy Content
This page contains Legacy Content.- Explanation: This is a legacy data field, its DataElementEndDate is in the past.
- Successor: No successor was entered
Click Expand to show legacy content.
Data Element (edit) | |
Field Name: | Transfer_Ready_DtTm |
CCMDB Label: | Transfer Ready DtTm |
CCMDB tab: | Dispo |
Table: | L_Log table |
Data type: | date |
Length: | not stated |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 1999-06-01 |
End Date: | 2020-10-15 |
Sort Index: | 47 |
Date and time the intent to discharge a patient to a lower level in the Level of care hierarchy was documented.
See Transfer Ready DtTm tmp entry
The data in this field will be retained in Centralized data.mdb's L_Log table since it doesn't follow the same pattern as the new entry. The field no longer exists in CCMDB data.mdb.
See Transfer Ready DtTm tmp entry for what this field is about, or see the history of this page for how it has been used at different times before moving to the new field.
Collection Instruction
Entering a Transfer Ready DtTm
Follow the instructions in Transfer Ready DtTm tmp entry.
Before 2020-10-15 |
For each patient,
This entry is about the time of an intent, nothing to do with what actually happened to the patient after. |
What is transfer ready?
moved to Transfer Ready DtTm tmp entry#Transfer Ready
Hierarchy of levels of care
We require an entry in this field when the intent is to transfer from higher to lower level of care. See Level of care hierarchy for a list.
Collection Start Dates
- Critical Care: all units on board June 1, 1999
- Medicine : all wards on board Jan 1, 2005
Cross Checks
Data Integrity Checks (automatic list)
none found
Legacy
Similar to the old Transfer Ready date and time, but we eliminated special cases and differences between medicine and critical care. Going forward the entry will be collected even if pt dies or goes to ER etc. It's the intent that counts, not what ended up happening. Resp. field names L_Log.R_TRDate and L_Log.R_TRTime
Related Articles
R_TRTime
Legacy Content
This page contains Legacy Content.- Explanation: This is a legacy data field, its DataElementEndDate is in the past.
- Successor: No successor was entered
Click Expand to show legacy content.
Data Element (edit) | |
Field Name: | Transfer_Ready_DtTm |
CCMDB Label: | Transfer Ready DtTm |
CCMDB tab: | Dispo |
Table: | L_Log table |
Data type: | date |
Length: | not stated |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 1999-06-01 |
End Date: | 2020-10-15 |
Sort Index: | 47 |
Date and time the intent to discharge a patient to a lower level in the Level of care hierarchy was documented.
See Transfer Ready DtTm tmp entry
The data in this field will be retained in Centralized data.mdb's L_Log table since it doesn't follow the same pattern as the new entry. The field no longer exists in CCMDB data.mdb.
See Transfer Ready DtTm tmp entry for what this field is about, or see the history of this page for how it has been used at different times before moving to the new field.
Collection Instruction
Entering a Transfer Ready DtTm
Follow the instructions in Transfer Ready DtTm tmp entry.
Before 2020-10-15 |
For each patient,
This entry is about the time of an intent, nothing to do with what actually happened to the patient after. |
What is transfer ready?
moved to Transfer Ready DtTm tmp entry#Transfer Ready
Hierarchy of levels of care
We require an entry in this field when the intent is to transfer from higher to lower level of care. See Level of care hierarchy for a list.
Collection Start Dates
- Critical Care: all units on board June 1, 1999
- Medicine : all wards on board Jan 1, 2005
Cross Checks
Data Integrity Checks (automatic list)
none found
Legacy
Similar to the old Transfer Ready date and time, but we eliminated special cases and differences between medicine and critical care. Going forward the entry will be collected even if pt dies or goes to ER etc. It's the intent that counts, not what ended up happening. Resp. field names L_Log.R_TRDate and L_Log.R_TRTime
Related Articles
=== R_DisDate === The Discharge date and time is the time that a patient leaves the unit or dies. === R_DisTime === The Discharge date and time is the time that a patient leaves the unit or dies.
=== R_Filter ===![]() |
_CFE_Data_reconsolidate
|
|
![]() |
_after
|
|
Legacy Content
This page contains Legacy Content.- Explanation: This is a legacy data field, its DataElementEndDate is in the past.
- Successor: No successor was entered
Click Expand to show legacy content.
Data Element (edit) | |
Field Name: | R_Filter |
CCMDB Label: | LTV |
CCMDB tab: | Dispo |
Table: | L_Log table |
Data type: | string |
Length: | 10 |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 1988-07-11 |
End Date: | 2019-01-01 |
Sort Index: | 26 |
Critical care patients on a long term ventilator (LTV).
Conversion from our old diagnosis schema to ICD10/CCI
- Chronic dependence on mechanical ventilator
- might be best to move this into a dx field for conversion before ICD10 conversion to not add additional complexity then... Ttenbergen 19:58, 2017 September 16 (CDT)
Legacy Data
For legacy reasons the actual name of the field in ccmdb_data.mdb and Centralized_data.mdb is R_Filter.
B, H, BH
HSC-CCU Only.
- Started: Sept 25, 2003
- Stopped 2005
- B = CCU patient on B3 only
- H = CCU patient on H7-CCU only
- BH = CCU patient on BOTH B3 & H7-CCU during one admission
Purpose was to capture CCU patient location during ICU CCU bed closure and during some renovations.
CC, CCN
HSC & STB-CCU patients only. Tags used for ICU:
- CC - intubated/ventilated patient in MICU under care of cardiology service or co-managed with MICU attending
- CCN - not ventilated but requires inotrope support, IABP or central lines in MICU under the care of cardiology service or co-managed with MICU attending
H1C, H1S, H1N
H1C and H1S are H1N confirmed and suspects when we are doing the H1N audit.
Other values
- 1 22E
- 5 DAN
- 1 GRA
- 1 H3N
- 11 H4H
- 9 HB
- 2 LTR
- 59 MR9
- 130 MRT
- 3 NP
- 2 U
translation into other fields
Based on Julie's review 2017-04-18
LTV (Long Term Ventilated patients)
– 463 records from 1988 to present at all sites ICUs --> to Chronic dependence on mechanical ventilator
- INSERT INTO L_ICD10 ( L_ICD10_ID, D_ID, ICD10_code, Dx_Type, Dx_Priority )
- SELECT [D_ID] & "_LTV" AS L_ID, L_Log.D_ID, " Z99.1" AS ICD10, "Comorbid" AS tp, 28 AS Pr
- FROM L_Log
- WHERE (((L_Log.R_Filter)="LTV"));
H1S, H1C (i.e. H1N suspect and H1N confirm )
- 155 records, 2009 at all sites --> to H1N1
- INSERT INTO L_TmpV2 ( D_Tmp_ID, D_ID, Project, Item, comment_var )
- SELECT [D_ID] & "_H1N1_s" AS L_ID, L_Log.D_ID, "H1N suspect" AS tmp_p, "H1N suspect" AS tmp_i, "from R_Filter" AS c
- FROM L_Log
- WHERE (((L_Log.R_Filter)="H1S"));
- INSERT INTO L_TmpV2 ( D_Tmp_ID, D_ID, Project, Item, comment_var )
- SELECT [D_ID] & "_H1N1_s" AS L_ID, L_Log.D_ID, "H1N confirmed" AS tmp_p, "H1N confirmed" AS tmp_i, "from R_Filter" AS c
- FROM L_Log
- WHERE (((L_Log.R_Filter)="H1C"));
Delete
- U, u (2014) – 2 records only
- NP– 3 records only, 1990-1991, HSC
- MRT, MR9 - 189 records, from 1989-1992, at HSC MICU/SICU ---> can’t remember this, Trish. If needed, move to tmp.
- LTR – 2 records, 2012, at GRA N5
- H4H - 11 records, Apr 2005 at HSC H4 ---> start date of H4H is May2005. Do we want to make the service location= H4H?
- H3N– 1 record, 2010 at HSC MICU
- GRA – 1 record, 2013 at GRA N3
- DAN – 5 records, 1998,2000,2001,2003 at HSC MICU
- 22E – 1 record, 2005 at STB E5
- UPDATE L_Log SET L_Log.R_Filter = ""
- WHERE (((L_Log.R_Filter)="U" Or (L_Log.R_Filter)="u" Or (L_Log.R_Filter)="NP" Or (L_Log.R_Filter)="MRT" Or (L_Log.R_Filter)="MR9" Or (L_Log.R_Filter)="LTR" Or (L_Log.R_Filter)="H4H" Or (L_Log.R_Filter)="H3N" Or (L_Log.R_Filter)="GRA" Or (L_Log.R_Filter)="DAN" Or (L_Log.R_Filter)="22E" Or (L_Log.R_Filter)="H1S" Or (L_Log.R_Filter)="H1C" Or (L_Log.R_Filter)="LTV"));
All Done PTorres 14:48, 2022 August 29 (CDT)
Project Legacy Co-managed
- R_Filter values CC or CCN
- 633 records from 1989-2004 at STB/HSC MICU
- Based on the D_ID, the physical location-service involves, CCU, MICU,SICU
- transitioned into Project Legacy Co-managed, see details there
turn into Project Legacy HSC CCU Loc
- R_Filter values H/B/HB/BH
- (HSC CCU at H7, B3 or both) – 1100 records from 2003 – 2006 at HSC CCU
- See Project Legacy HSC CCU Loc for details
Related articles
=== Var1 === Var1 === Var2 === Var2 === Var3 === Var3 === Var4 === Var4 === Var5 === Var5 === Var6 === Var6 === PostalCode === PostalCode === LastOpened_DtTm === LastOpened DtTm === Pre_Acute_Living_Situation === Pre Acute Living Situation === Pre_admit_Inpatient_Institution === Pre admit Inpatient Institution
Previous_Location
Data Element (edit) | |
Field Name: | Previous_Location |
CCMDB Label: | Previous Location |
CCMDB tab: | Dispo |
Table: | L_Log table |
Data type: | number |
Length: | long integer |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 2016-07-01 |
End Date: | 2300-01-01 |
Sort Index: | 37 |
The most recent previous physical location (with #exceptions) of a patient before arriving at the collection location.
Collection Instruction
For each patient,
- enter the option that most closely matches:
- if you know the situation but nothing on the list matches closely, enter other - known but not listed
- if the situation is unknown, enter Not known
- if the patient is in ER under a service we do not collect ie. cardiology, surgery etc use <site>_ER
If you know the location exactly, you can type it, otherwise click on the dropdown button to view the options
Borrowed Bed Or Pt Boarding On Other Unit
For direct transfers within the Winnipeg region, should we enter the Last Boarding Location as the Previous Location ? No because these are only temporary location. Use the service taking care of the patient : <site>_Med, GH-CC, HSC_MICU, HSC_SICU, HSC_IICU, STB MICU, STB_ICCS, STB_ACCU.
Direct Transfers Scenarios
- From Outside Winnipeg facilities - whether inpt or not, if they went to <own site> ER (e.g. STB ER) for triage, previous location is <own site> ER (e.g. STB ER). If they just stop by only at <own site> ER, then previous location is the outside facility service - it does not matter if from ICU (e.g. Thompson ICU) or ER (e.g. Thompson ER) service of that outside facility as long as the pre-admit inpt has been filled up correctly (e.g. Thompson ICU) , then in TMP Boarding, put <own site> ER (e.g. STB ER) as first boarding loc.
- From Within Winnipeg facilities - For transfers among HSC/STB/GRA, we are linking all the admissions so we need to be specific for the sending and receiving service. If already inpatients, and no in-between procedures, pre-admit inpt is the same as previous location. if there is temporary location in-between, then previous location is equal to the temporary location (e.g. ER, OR, RR, Cath Lab, Dialysis, Radiology). If not yet an inpt and coming from <other site> ER then previous location is <other site> ER.
- When to use generic ward - If the patient from our sending service (e.g. HSC SICU) was discharged to a service we are not collecting (e.g. Step down ward) and then transfer again to the service (e.g. HSC Med) we are collecting, having no in-between procedure then the dispo of sending service, pre-admit inpt and previous location are all generic ward (e.g. HSC ward). For the case having in-between procedure, say, sending service is HSC Med to a surgery ward, then OR, then to HSC SICU, the dispo of the sending and pre-admit inpt are generic ward (e.g. HSC ward) and previous location is the temporary location e.g. HSC OR.
- For sites no longer collected ie. CON/OAK/VIC - inpatients from CON, OAK, VIC who are direct transfers to HSC/STB/GRA, the pre-admit inpt will not be N/A and the previous location is the same as the pre-admit inpt even if the patient spends time in site's UC prior to transfer. If not yet an inpt from CON/OAK/VIC and transfers only from their UC triage, then previous location is the CON/OAK/VIC UC.
"Can we remove the items that are no longer Service/Locations, Previous Locations, Pre-admit Inpatient Institutions or dispo locations from the dropdowns?"
We can and will remove them, but that can only happen once no more laptops use them. We will need to keep track of this and then remove them when ready. If I removed them now, then any box that currently has them enter would misbehave.
query of what is currently available
SQL |
SELECT s_dispo.location_name, s_dispo.Site, s_dispo.active, s_dispo.inpatient, s_dispo.previous_location, s_dispo.s_location, s_dispo.dispo FROM s_dispo WHERE (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.inpatient)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.previous_location)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.s_location)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.dispo)=True)); |
Query of what is currently used
query z_s_dispo_inactivatable
Where to find this information
If patient came from a different Winnipeg hospital this should be recorded in the “Visit History” on the EPR, but sometimes it is missing. Can also use paper chart sent to your hospital from the sending hospital for information.
Exceptions
Data collection units that have a mix of different physician serve types
We have a few units in the Region that have a mix of different services (internal medicine, surgical, family medicine etc).
- HSC_B3 - is a mix of day surgery & internal medicine patients
- any others?
For patients from these units:
- If patient was an internal medicine there, enter <site>_Med
- If not a internal medicine patient, enter the <site>_Ward
from HSC psych unit
Code patient from POU (pysch evaluation unit @ HSC) as "HSC ambulatory care" - it's not an inpatient ward.
Dialysis unit as previous location
For patient from Dialysis unit, use that unit as previous location. Pre acute living situation field would be the unit they came from right before, if applicable.
Heart Cath Lab vs OR as previous location
When a procedure (e.g valve replacement) is done in the cath lab before the pt arrives on your unit, enter Cath Lab if done in Cath Lab and put OR if done in OR.
Patients from day surgery
For patients admitted from day surgery units, enter:
- Previous Location - <site>_Ward, e.g. HSC Ward
HSC Stepdown Units
Homeless Patients
If a homeless patient is admitted directly then code them as admitted from home. Usually they would be via ER, of course, and you'd code them as that.
Prison / Jail / Correctional Institution
If a patient is admitted from prison, jail or a correctional institution, code this as an admission from "Institution NOS".
See Prison / Jail / Correctional Institution for additional info.
Data Use
This data is used for tracking where most of the traffic on our units/wards comes from. For starters it will be reported to Critical Care (Randy Martin), who was also the requestor of this data.
Cross Checks
Data Integrity Checks (automatic list)
none found
Implementation
The field is populated with options from the s_dispo table.
Legacy
This field is part of the 2016 Time and Place changes.
It a combination of our previous
Related articles
=== Previous_Service === Collection stopping as per Task_Team_Meeting_-_Rolling_Agenda_and_Minutes_2022#ICU_Database_Task_Group_Meeting_–_August_24,_2022. Ttenbergen 16:00, 2022 September 7 (CDT)
Legacy Content
This page contains Legacy Content.- Explanation: This is a legacy data field, its DataElementEndDate is in the past.
- Successor: No successor was entered
Click Expand to show legacy content.
Data Element (edit) | |
Field Name: | Previous_Service |
CCMDB Label: | Previous Service |
CCMDB tab: | Dispo |
Table: | L_Log table |
Data type: | number |
Length: | long integer |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 2016-07-01 |
End Date: | 2022-09-07 |
Sort Index: | 38 |
The most recent "originating service" which sends the patients to their current service location.
Collection Instruction
- For each patient enter the option that most closely matches
- For medicine ward-to-ward moves, code "medicine" as previous service
- For ICU-to-ICU moves, code "Critical Care" if no other specific service is documented
- For pt from ER, code "Emergency Medicine" unless a different service had accepted them and is handing them off to Medicine
- For pt direct from ambulatory not via ER, code "not applicable" if no other specific service is documented
- Patients admitted after having a problem during an outpatient procedure are more complicated:
- Such procedures include outpatient: GI endoscopy, bronchoscopy, cardiac cath, invasive radiology, procedures done at surgicentres, etc.
- If the patient goes DIRECTLY from the outpatient procedure area to a Medicine ward or an ICU, then code the type of physician who was doing the procedure:
- if, for example, it was a GI endoscopy, then the previous service was "GI", but as GI is not specifically listed in the dropdown list of services, then list it as "other"
- If before being admitted to hospital the patient was sent from the procedure area to the ED:
- if the patient was actually an ED patient (under the care of the ED docs) then code "Emergency Medicine"
- if, for example, it was a GI endoscopy and the patient was not actually under ED care, but instead was directly admitted to the ED on the Medicine ward service, then the previous service was "Medicine"
- If the service is not listed, code "other (known but not on list)"
- in these cases we don't care about the details; if we see too many others we may add additional options in future (as of January 2022 we checked and these account for <1% of all previous services)
From HD / From hemodialysis
- Came to dialysis from being an outpatient:
- Previous Location =dialysis
- Previous Service=Nephrology
- Pre-admit Inpatient Institution=n.a.
- Came to dialysis from ED:
- Previous Location=dialysis
- Previous Service=ED
- Pre-admit Inpatient Institution=n.a.
- Came to dialysis from a prior, different, inpatient location:
- Previous Location=dialysis
- Previous Service=service of that prior inpatient location
- Pre-admit Inpatient Institution=that prior inpatient location
From Cardiac Cath Lab
- A patient goes to emergency, then is sent to the cardiac cath lab for an angiogram. Julie would like the sending service to be Emergency Medicine in these cases (not cardiology). Discussed at the task group meeting on July 20, 2017.
- Most patients come to CCU or ICU via the heart cath as a code stemi, in which case the previous service is cardiology because they bypass ER and go direct to the heart cath lab.
- The previous service is who was looking after the pt before the heart cath in some situations. For example, if ECMO is done in the heart cath lab : If the pt was on a ward or unit prior to the procedure, the service is whatever ward or unit it was that sent the pt there. If ER sends a pt for a VV ECMO, the ER is the sending service, unless ICU takes over the pt prior to the ECMO. (They would need to consult cardiac surgery for the ecmo procedure but it would be the ICU that takes over the care ultimately).
This was discussed at the task group meeting on June 21, 2017.
from OR
If a patient comes from an OR/RR, code the responsible surgical service as previous service.
Nursing Home Wards (HSC/GRA)
We treat patients that went through the HSC/GRA Nursing Home as having been discharged. So, admission from there should be as if admitted from home, so put "not applicable" into the Previous Service field. This does not affect the Visit Admit DtTm field definition - remember, that is defined by EPR entry.
Admit from home
For an admission directly from home bypassing the ER enter Previous Service = 'Not applicable'.
from EMIP via ER
The case of VIC ER to STB EMIP to VIC ER to VIC Ward is a bit tricky because STB EMIP signify being an inpatient under Medicine service before going to VIC ER. WIKI defines Previous Service as the "originating service" for those patient's who where already in a prior inpatient location. It would be easier to define the previous service if this is a case of direct transfer to VIC Medicine service and parked only in VIC ER. This is a good question - which to use, Emergency Medicine or Medicine? Since it is known that there is prior inpatient service, I am more on the second one 'Medicine'. This can be a similar case when the previous location is Operating or Recovery and the responsible surgical service is coded as previous service. If coming from home to another ER to own ER to own Ward, then previous service is clearly Emergency medicine.
admission from a unit partly collected by us
see Previous_Location_field#from_a_unit_that_is_partly_collected_by_us.2C_and_partly_not.
admission from a nursing station
- For a direct admission to a collection unit from nursing stations, put "other (known, but not on list)".
- If from a nursing station, patient dropped by ER , put "Emergency Medicine".
Direct admit
For a direct admit via the ER, the Previous Service will be the primary service looking after the patient, prior to admission at your facility.
Example: |
testcontent |
Urgent Care
For patients directly admitted from urgent care, code previous service as "Emergency Medicine".
Clinical Assessment Units
Specific instructions apply for coding previous service for the specific CAUs. See
Data Use
Sending service to ICU will be reported to the Critical Care Director whose interest is to determine the sending services for patients who where already in a prior inpatient location before coming to ICU (refer to minutes of Task Meeting dated 13 April 2015 and 11June 2015). The data to be reported will be filtered to include only those in-patients prior to ICU.
Integrity checks
Data Integrity Checks (automatic list)
none found
Implementation
The field is populated with options from the s_previous_service table.
Legacy
For medicine this concept is related to ER Wait.
For critical care this concept is related to Service Sending to ICU - refer to Task Meeting minutes dated June 11, 2015.
- see updated minutes dated August 24, 2017.
Related articles
=== off_ward === Are now collected as part of Using Cognos2 to keep track of patients / Boarding Loc
Legacy Content
This page contains Legacy Content.- Explanation: This is a legacy data field, its DataElementEndDate is in the past.
- Successor: No successor was entered
Click Expand to show legacy content.
Data Element (edit) | |
Field Name: | off_ward |
CCMDB Label: | Off Ward |
CCMDB tab: | Dispo |
Table: | L_Log table |
Data type: | number |
Length: | long integer |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 2016-07-01 |
End Date: | 2020-01-29 |
Sort Index: | 39 |
Checked/true if the patient who meets the Definition of a Medicine Laptop Admission or Definition of a Critical Care Laptop Admission spent any time in a bed that is not at their actual collection location between "Arrive DtTm" and Dispo DtTm. The patient must be covered by the attending of the service of the home unit that is credited with the "off ward" designation.
Legacy
- Allan suggested this OFFWARD field for some reasons related to outcome. you are right the tmp Boarding will indicate patients staying in offward locations. Offward started July 2016. CC started tmp Boarding July 2018 while Med on Sept2019. since offward start date was before any of these BL dates, we need to keep those data in prior dates. --JMojica 16:18, 2022 August 12 (CDT)
- Here is a query with counts by send time:
TRANSFORM Count(L_Log.D_ID) AS CountOfD_ID SELECT Format([SentDtTm],"yy-mm") AS send_month FROM L_Log GROUP BY Format([SentDtTm],"yy-mm") ORDER BY Format([SentDtTm],"yy-mm"), L_Log.off_ward PIVOT L_Log.off_ward;
- It actually looks like we used this from 2014 onward, even if the data definition on this page says from 2016.
There is a weird spike in Jan 2018, other than that numbers in a similar range between 16-07 and 20-03. So from when until when would we consider this data reliable? We should likely clean up values outside that range so no one thinks records are reliably tagged outside that range. Ttenbergen 11:23, 2022 August 23 (CDT)
- For the pre2016 profiles, the OFFWARD field is pre-populated by the old VAR3, VAR4,VAR5 (see below) and therefore they are reliable. Actually Var3 to Var5 specify the units they are overflowing (similar with tmp Boarding but only with location and no start dates). If I remember right, when Allan introduced OFFWARD, he was thinking of the specific location but the idea was not received well and so decided just to be binary code YES/NO. For research project needing historical data, I think binary data would still be useful. we can either keep it AS IS or be saved as tmp project. --JMojica 15:38, 2022 August 29 (CDT)
Old instructions
This includes patients who spend part or all of their admission located on an off service ward, but not #EMIPs.
How to enter patient into CCMDB
Collection Instructions - current ward
If the patient meets the definition at the top, check the "off ward" checkbox located underneath the Service/Location field.
Enter the laptop's regular collection location into the Service/Location field, not the off-ward location.
Collection Instructions - next ward (if applicable)
The Pre-admit Inpatient Institution field and Previous Location field of the next encounter would use the Service/Location field of the previous collection location where available, not the off-ward location.
Collection Instructions - previous ward (if applicable)
The Dispo field of the previous encounter would use the Service/Location field of the next collection location where available, not the off-ward location.
Not intended for off-ward tests
see Bed holds
EMIP
EMIPs are in their collection location, e.g. GRA_EMIP, so they are not off ward. Don't check the field.
Parked in ER
Parked in ER is before Arrive DtTm, so they are not "off ward". Don't check the field.
- find patients as per off ward field article
- Write down a list of these patients with their chart numbers on a paper.
- Place this list on the bulletin board in the medicine office so that both medicine data collectors are aware that there are medicine service patients on off-service wards in the hospital.
Entering off ward patients
- If these patients ultimately get transferred to one of the medicine wards, then the data collector that does that ward will enter those patients on their laptop, reflecting their entire stay from the admission from ER. In the dispo tab the Off ward field must be ticked off as they were off ward for part of their stay.
- If these patients get discharged from the off service ward to home or out of hospital location, then these are considered Off ward field that must be entered on one of the medicine laptops, because their entire stay was on an off service ward.(There may be individual hospital differences on which laptop is used for these entries).
- This patient list can be posted on the bulletin board of the medicine office. If they are admitted to one of the medicine wards, then that data collector will cross that person off the list. Once a week check if the pt is still in the hospital, if they have left and were never admitted to one of the medicine wards, then a designated data collector will enter them on her laptop. --LKolesar 12:54, 2017 March 2 (CST)
Patients who are on a off wards for part of their stay only
- When a pt comes to one of the medicine wards from an off-service ward, the data collector must go to the original presentation of the pt to see if this pt was accepted to medicine on the off-service ward prior to their arrival on their own ward. If you see that the pt was looked after by internal medicine prior to their arrival from the other ward, make sure you start your profile on the original date that medicine accepted them (usually in ER).
- On occasion, medicine patients are transferred to off service wards, but are still admitted under the internal medicine service. ie. patient transferred from a medical ward to a surgical ward but still are admitted under internal medicine service. The attending may be different than the admitting service but it is still an internal medicine attending. Please continue to follow these patients (new profile is not required) until they are discharged or transferred to an off service ward under family medicine or any other service other than internal med. Please note the location in the RECORD box to indicate where the pt is currently located. --LKolesar 13:05, 2017 March 2 (CST)
How to determine when a patient is no longer under an internal medicine service
In the EPR the patient list will show the "provider" which should identify which service the attending physicians is from. However, because this is not always consistently kept up to date when services change, the following checks can help to determine if a patient remains under internal medicine or switches to another service.
1. In EPR,Check the orders under transfers/care directives, to see if there has been an order to switch from internal medicine to another service. Use the time transferred to the other ward as the discharge time or use the time in the order when the other service took over care if the pt remains on the off-service ward. (orders are currently only available to view at STB).
2. In EPR, go to the patient info tab, select care providers from the left hand column, a list should come up with providers and their discipline with a date. If you see that the most recent attending is no longer an internal medicine physician then there has likely been a change of service. You may be able to confirm this by checking under the documents tab, sort by discipline, and then check the medicine notes that correspond to the date found in the care providers list. The progress notes from different services will be identified as such in the notes section. If you determine that they are in fact now under a new service (with no corresponding order), use the date and time of the attending switch in the care provider list as your discharge date and time.
Data Use
Relevant to Bed occupancy and some patient risks.
As of 17:13, 2017 November 9 (CST) we don't use it in reports but it is used to explain such things as over-census situations.
See also
Cross Checks
Legacy but still implemented: ACCU_borrow#If_ACCU_entry_then_off-ward_should_be_checked
Legacy
initial mis-connection
From 2016-07-01 to 2016-08-?? the control for this field had been incorrectly connected to the pharm_complete field. Since medicine doesn't use that field we could reclaim data for medicine from there. CC uses the field so could not reclaim data for them. Data for CC will be reported starting 2016-09-01.
pre-2016 fields for similar content
We used to collect related information in multiple places. Once we are comfortable with the new dispo fields we want to stop collection of the old fields. The fields are:
Old data would be transferred to new fields where the translation is not ambiguous. We can keep a snapshot of Centralized with the data pre-translation in case we ever want to go back to it.
Related Articles
Service_Location
Data Element (edit) | |
Field Name: | Service_Location |
CCMDB Label: | Service Location |
CCMDB tab: | Dispo |
Table: | L_Log table |
Data type: | number |
Length: | long integer |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 2016-07-01 |
End Date: | 2300-01-01 |
Sort Index: | 40 |
Legacy field replaced by Boarding Loc and Service tmp entry
The field was changed as part of Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry.
![]() |
|
- This does not apply to STB_MICU, STB_CICU, STB_ACCU or HSC MICU, HSC SICU, HSC_IICU. Service Location field will not change.
Collection Instruction
see Change_from_Service_Location_to_Service,_Boarding_Loc_and_Transfer_Ready_DtTm_tmp_entry#The_change for how to code during the transition to the new scheme
When entering from CSS or "Add Patient with Serial Helper" button, or in Patient Viewer Tab Dispo, under Auto Data Dictionary select the generic site/program entry:
- GRA_Med, HSC_Med, STB_Med for medicine
- GRA_CC, HSC_MICU, HSC_SICU, HSC_IICU, HSC_IICU, STB_MICU, STB_ACCU, STB_ICCS for critical care (see STB_CC#Decision to not combine collection of STB CC on one laptop)
Bed Borrow
- When a service borrows a bed in another unit/ward but still follows them the Service Location should be the location where the patient would have been had there been enough beds/space for them. example. ACCU patient, followed by ACCU service but physically located in CICU, service location=ACCU. The Boarding Loc in the Tmp will identify that they are "borrowing" a bed in CICU. If this patient is then transferred to their normal unit, ACCU, add this location as a Boarding Loc in the tmp, this would be a single profile. If the patient was NOT followed by ACCU but by CICU, see ICUotherService for instructions on how to collect.
The concepts that used to be stored in this are essentially now stored as:
- Service tmp entry for the service
- Boarding Loc for the physical location
"Can we remove the items that are no longer Service/Locations, Previous Locations, Pre-admit Inpatient Institutions or dispo locations from the dropdowns?"
We can and will remove them, but that can only happen once no more laptops use them. We will need to keep track of this and then remove them when ready. If I removed them now, then any box that currently has them enter would misbehave.
query of what is currently available
SQL |
SELECT s_dispo.location_name, s_dispo.Site, s_dispo.active, s_dispo.inpatient, s_dispo.previous_location, s_dispo.s_location, s_dispo.dispo FROM s_dispo WHERE (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.inpatient)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.previous_location)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.s_location)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.dispo)=True)); |
Query of what is currently used
query z_s_dispo_inactivatable
Minimal Data Set
This entry is part of the Minimal Data Set. Special collection instructions apply, see that page for more info.
Adding a new service/location entry
- add to s_dispo table
- consider all checks in Category:Service/Location check to see if they need to be modified to work right for the new location.
Data Use / Purpose
See Site and Location table for possible entries.
Used to determine the location or services the patient went during a hospital stay.
Used to categorize/stratify the distribution of patients across hospitals and wards/units when reporting summary statistics.
Integrity checks
Data Integrity Checks (automatic list)
none found
Implementation
The field is populated with options from the s_dispo table.
Retiring an available Service/Location field entry
Sometimes a ward may close or change names, or we may stop collecting somewhere. In that case, an entry for Service/Location needs to be made unavailable by editing the s_locations_allowed_collection table.
If a location is no longer available on a laptop records with that location can't be set to "complete". So, if we transition from one location to a new one, we need to get collectors to change the locations for all existing records to the new one, and change the number to using the new number series. Another option might be to keep old location available, at risk of manual mistakes and continuing to use the old location, and of location-number Pool mix-ups. Either way, needs to be planned.
Legacy
This field is subject to Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry. However, we still need it because of how we decided to collect patients at HSC and STB CC.
This field is part of the 2016 Time and Place changes and corresponds to to the old Location field, resp L_Log.R_Location.
Related articles
Dispo
Data Element (edit) | |
Field Name: | dispo |
CCMDB Label: | Dispo |
CCMDB tab: | Dispo |
Table: | L Log table |
Data type: | number |
Length: | long |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 2016-07-01 |
End Date: | 2300-01-01 |
Sort Index: | 41 |
The Dispo field contains information about what happens to the patient at the end of their admission.
Collection Instruction
surviving patients
- Enter:
- see Visits to temporary locations for dispo to temporary locations, ie. OR, dialysis, procedure suites of all types, imaging suites/radiology
HSC Stepdown Units
AMA
Homeless patients
If a homeless patient is discharged, either to a place like Siloam Mission or even without a specific plan, then code them as discharged to home. Consider whether they might have left AMA.
Prison / Jail / Correctional Institution
If a patient is discharged to prison, jail or a correctional institution, code this as a Institution NOS.
- Pre acute living situation field should be coded as: Jail/correctional institution.
Chronic Health Facility
If a patient is discharged to a PCH bed at Deer Lodge or Riverview, then the option "Winnipeg PCH" should be used in the Dispo field.
Discharged to ER or Urgent Care
If you discharge a patient to the ER or Urgent Care, you can't enter this in the dispo field. The reason is that this should not happen. If it really does happen:
- enter Not Canada or USA - unknown/other (this is a very rare entry so when we see it, we can question it. Put a note in to the Notes field so Pagasa can check there first.)
- email Pagasa so she can enter your ER / Urgent Care location as dispo.
We don't want ER to be available in the dropdown because it had been mistakenly entered a number of times. If it turns out there are a lot of legitimate discharges to ER we will make the option available.
Visits to temporary locations
See Visits to temporary locations
Deceased patients
See
- Deceased patients#General instructions for deceased patients
- Guideline for coding organ donation after death
- Visits to temporary locations
"Can we remove the items that are no longer Service/Locations, Previous Locations, Pre-admit Inpatient Institutions or dispo locations from the dropdowns?"
We can and will remove them, but that can only happen once no more laptops use them. We will need to keep track of this and then remove them when ready. If I removed them now, then any box that currently has them enter would misbehave.
query of what is currently available
SQL |
SELECT s_dispo.location_name, s_dispo.Site, s_dispo.active, s_dispo.inpatient, s_dispo.previous_location, s_dispo.s_location, s_dispo.dispo FROM s_dispo WHERE (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.inpatient)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.previous_location)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.s_location)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.dispo)=True)); |
Query of what is currently used
query z_s_dispo_inactivatable
Data Use
- Unit Mortality
- Intra or Inter Transfer Rate
- Discharges out of hospital
- Organ donor rate
- AMA Rate
- Linking admissions
Cross checks
Data Integrity Checks (automatic list)
none found
Implementation
The field is populated with options from the s dispo table.
Related Articles
Legacy
This field is part of the 2016 Time and Place changes and was affected by the PatientFollow_Project.
It a combination of our previous
Data from these fields has been back-populated to the this field so data is available from the beginning of the database.
Related articles:
Very early missing Discharge-tos
There were 6762 very old ICU records who are listed as survived but didn’t have a discharge-to. This is from HSC-only days when there simply were no checks.
When data was brought across from the old discharge to field the dispo fields of these records were set to 'survive(Legacy)'.
Visit_Admit_DtTm
Data Element (edit) | |
Field Name: | Visit_Admit_DtTm |
CCMDB Label: | Visit Admit DtTm |
CCMDB tab: | Dispo |
Table: | L_Log table |
Data type: | date |
Length: | not stated |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | Jan 1, 2003 |
End Date: | 2300-01-01 |
Sort Index: | 42 |
This field is used only as an identifier to combine data from the same hospitalization and should not be used as a date.
The field it is automatically populated from Cognos EPR Report. For reference only, it contains the first entry in the visit location history in EPR for current visit at a hospital site.
Purpose
The field is used as an identifier of a hospital encounter at your site. The info is used to:
- link together ICU and Ward admissions during the same hospital visit
- uniquely identify patient visits to Manitoba Health when we exchange data with them
We obtain this item from the ADT system (via Cognos) and it does not always accurately identify the timing of hospital admission. THUS, we are only using it as an identifier to link.
- The Statistician must not give this field to anyone requesting data from the database to avoid being misused.
Collection Instruction
- The field is pre-populated by Cognos2 Service Starter and should not be changed or altered
If a patient needs to be entered other than through Cognos |
Important NOTE: All collector must look exactly in the same place in the EPR to get this information as indicated in the instructions above. EPR lists the time the pt became an inpatient as this time. |
Data Use
This data is used to understand Length of Stay and for linking.
Data Integrity Checks (automatic list)
none found
Legacy
This field is part of the 2016 Time and Place changes.
It is being added to simplify the old linking - if we have the hospital admit date and time, we are done linking, none of the previous complex process will be needed any longer.
Start date and early data
- at some point before 2021-01-01 we started getting this field directly from Cognos, likely from the beginning of using Cognos.
- July 1, 2016 - Data collectors entering the data from EPR
- Jan 1, 2003 to June 30,2016 - generated Pseudo Visit Date_time
- Julie has generated "pseudo - Visit Admit DtTm" data for records from Jan 1, 2003 until June 30,2016 based on "Accept DtTm" or "Arrive DtTm" to facilitate linking those as well. This data was imported using temporary query 2017-01-17_pseudoVisitAdmit_update in centralized_data.mdb
- before Jan 1, 2003 has a Visit Admit DtTm of null
Related articles
Legacy Content
This page contains Legacy Content.- Explanation: This is a legacy data field, its DataElementEndDate is in the past.
- Successor: No successor was entered
Click Expand to show legacy content.
Data Element (edit) | |
Field Name: | Accept DtTm |
CCMDB Label: | Accept DtTm |
CCMDB tab: | not stated |
Table: | L_Log table |
Data type: | date |
Length: | not stated |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 2016-07-01 |
End Date: | 2022-04-22 |
Sort Index: | 43 |
First Service tmp entry DtTm for pts who came from the ER department only
Collection Instruction
For each patient, enter First Service tmp entry DtTm for pts who came from the same hospital's the ER department only (i.e. who had an initial Boarding Loc of ER). Follow the instructions at Service tmp entry.
This means the Auto Data Dictionary should be equal to the first Service tmp entry DtTm if it is entered at all.
Planned elimination of this field
see Change to replace Accept DtTm with first Service tmp entry, and Arrive DtTm with first Boarding Loc
Data Use
- medicine program: to monitor delays to move patient from ER to Med ward bed
- as of July 2016 onward - ICU same purpose
Accept DtTm is used as part of the formula to calculate delay in the transfer of patient from ER bed to Med ward or ICU bed - see ER Delay. This measures the amount of time for the patient already accepted in Medicine or Critical Care service but still using the ER bed and resources.
Data Integrity Checks (automatic list)
none found
Legacy
Click to see legacy info |
|
Related articles
Legacy Content
This page contains Legacy Content.- Explanation: This is a legacy data field, its DataElementEndDate is in the past.
- Successor: No successor was entered
Click Expand to show legacy content.
Data Element (edit) | |
Field Name: | Arrive_DtTm |
CCMDB Label: | Arrive DtTm |
CCMDB tab: | Dispo |
Table: | N/A |
Data type: | date |
Length: | not stated |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 2016-07-01 |
End Date: | 2022-04-22 |
Sort Index: | 45 |
First non-ER Boarding location date and time, or start of ( Service Location) for legacy records.
Collection Instruction
For each patient enter the First non-ER Boarding Loc date and time as Auto Data Dictionary. Follow the instructions at Boarding Loc.
This means the Auto Data Dictionary should be equal to the first Boarding Loc DtTm.
Planned elimination of this field
see Change to replace Accept DtTm with first Service tmp entry, and Arrive DtTm with first Boarding Loc
Data Integrity Checks (automatic list)
none found
Legacy
Click to see legacy info |
|
Related Articles
Dispo_DtTm
Data Element (edit) | |
Field Name: | Dispo_DtTm |
CCMDB Label: | Dispo DtTm |
CCMDB tab: | Dispo |
Table: | L_Log table |
Data type: | date |
Length: | not stated |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 2016-07-01 |
End Date: | 2300-01-01 |
Sort Index: | 46 |
Date and time when the patient changed status from what is documented in Service/Location field to Dispo field..
Collection Instruction
For each discharged patient enter the date and time when the patient left the unit as found in Cognos2 Ender.
Discharge at midnight
If the patient is discharged at 24:00/midnight, use 23:59 hours as the discharge time.
Deceased patients
See Deceased patients#General instructions for deceased patients
Visits to temporary locations
AMA
Data use
Among other things, the times are used to generate statistics about
Data Integrity Checks (automatic list)
none found
Legacy
This field is part of the 2016 Time and Place changes. Similar to the old Discharge date and time resp the fields L_Log.R_DisDate and L_Log.R_DisTime.
Related Articles
Transfer_Ready_DtTm
Projects | |
Active?: | active |
Program: | CC and Med |
Requestor: | internal |
Collection start: | 2020-10-15 |
Collection end: |
Collection instructions
What is Transfer Ready
- The status of "transfer ready" is about the date/time of an intent to transfer a patient to lower level of care in the Level of care hierarchy if there was a bed available. Whether or not the patient actually moves does not matter, just that at some point there was an intent to move the pt. It also does not matter whether after such a determination the care team changed their minds about such a desired transfer.
- Obviously we don't always know the team's intentions, but if they do write them down, then use that info.
- In making this delineation, except as for the exceptions listed immediately below, only consider a clearly written intent that the team now desires the patient to be transferred to such a lower level of care.
- In particular, when a ward patient is transferred (e.g. home) without any notes stating the team’s intention to do so in advance or even an order to discharge, collectors should not attempt to make educated guesses from the notes of when the patient was probably clinically ready to leave and the checkbox is checked.
- In making this delineation, except as for the exceptions listed immediately below, only consider a clearly written intent that the team now desires the patient to be transferred to such a lower level of care.
See Level of care hierarchy for further information.
Specifically for ICU
In an ICU, take the following to indicate transfer ready to a lower level of care even if they have not written that explicitly:
- Care is stepped down to ward frequency (q4hrs or less) of vitals AND off all forms of life support except possibly intermittent dialysis
- HSC_IICU consult is written
- patient is made ACP-C
- for organ donors, see Guideline for coding organ donation after death
- if the patient is a potential organ donor and then deemed not to be, the Transfer Ready tmp DtTm will be when that determination is made
- for those patients who are declared brain dead, and do not become actual or potential organ donors, use the time of Brain death as the Transfer Ready DtTm tmp entry, and the time of cardiac death as the Dispo DtTm
Specifically for Medicine
On a medicine ward, take the following to indicate transfer ready to a lower level of care even if they have not written that explicitly:
- For SBGH If there is no discharge order, then the DC summary date/time that the attending signs off can be used, however if the date and time is after the DC time then it may be documented in a nursing or allied health IPN. Also, for SBGH often bed utilization will document when they are waiting on a transfer to an LAU or other facility, or rehab services will document when they are on the central wait list, or long term care (LTC) will document when they are approved for a PCH bed.
- For HSC if there is no discharge order, then check the IPN notes (nursing, allied health etc), often bed utilization will document when they are waiting on a transfer to an LAU or other facility, or rehab services will document when they are on the central wait list, or long term care (LTC) will document when they are approved for a PCH bed.
- Order is written to change all iv meds to po AND monitor discontinued/vital sign frequency is reduced
- Patient is made ACP-C
- If a discharge order is written during the preceding day(s) prior to discharge:
- and a specific date and time for discharge is documented in that order, the transfer ready date and time would be the date and time specified in the order.
- and If the order is to discharge after a specific test or procedure/treatment ie. dialysis or last dose of antibiotics, then the transfer ready date and time would be the time they finish the treatment or procedure.
- and there is no specific date and time documented for discharge or another order for discharge is written, then check the checkbox or use that new discharge order date and time
- The discharge medication reconciliation form should NOT be used as transfer ready date and time.
- PT/OT Assessment: Before going home, some ward patients get a home safety evaluation from PT and OT, and if deemed safe for home get a homecare evaluation before going home. The transfer ready date/time in such a situation should be only after the PT/OT evaluation has deemed them safe to go home, i.e. before homecare has seen them. The rationale is that homecare evaluation can occur after discharge, but a hospitalized patient who “fails” their home safety evaluation will end up going to LTC, not home.
- exception to this would be for those patients that are waiting for transfer to a rehab ward (Geri, stroke, amp, neuro etc) The date and time they are placed on the wait list for rehab can be used as their transfer ready date and time
Data entry instructions
- A "Transfer Ready" line is automatically created for each Boarding Loc entry.
- Project: Transfer Ready DtTm
- Item: the only available item is "Transfer Ready DtTm", just like the project entry.
- Date and Time vs checkbox:
- Collector needs to enter one of the following:
- First Date and Time during the stay at this Boarding Loc that patient became transfer ready as per #What is Transfer Ready above
- Collector needs to enter one of the following:
- OR
- checkbox checked if a clear transfer ready date and time are never documented, both must be present to be considered a valid Transfer Ready DtTm
- OR
Combining Transfer Ready DtTm tmp entry and Boarding Loc records
- There needs to be one Transfer Ready DtTm tmp entry for each Boarding Loc and vice versa. To mark which entries belong together, use the same integer number in the "combiner" field in Patient Viewer Tab Cognos ADT2 for both records and in sequential order according to Boarding start_dt and start_tm. The presence of matching records is validated by query s_tmp_check_combined_Boarding_Loc_and_TransferReadyDtTm, and their sequential status by query s_tmp_check_combined_BL_and_TRDtTm_nonsequential.
- the integer number should be entered at the time that the paired Boarding Loc and Transfer Ready DtTm tmp entry are entered, as Julie uses this data early to report on
Collection for each Boarding Loc
We currently only use the first entry per Level of care to calculate Transfer Delay, but we collect both because:
- It gives us the flexibility to report per location if requested
- To make it easier for data collectors. This way, collectors don't have to try and go back and figure out if there was or was not a transfer ready in a prior location. They only need be concerned about the notes and orders from THIS boarding loc.
Start DtTm/Legacy
We used the old Transfer Ready DtTm field for transfer ready dttms before 2020-10-15, and use this new entry for dttms after.
The data during the transition period for PatientFollow Project is inconsistent, so we use all the new and the old in Created TransferReady query.
Data Use / Purpose
Critical care and Medicine programs want to know this to better understand patient flow and bed utilization.
Used via Created_TransferReady query and Created_transferDelay table to generate Transfer Delay and Avoidable Days (Critical Care).
Background
This isn't so much a project as a change to Transfer Ready DtTm collection to allow us to collect more than one Transfer Ready DtTm per patient-program-stay. See Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry for why we needed to change to this.
Data Integrity Checks (automatic list)
none found
Log
2021-07-08 - Change from Awaiting/delayed dx codes to Transfer Ready DtTm for data back to 2021-07-01
Legacy
Similar to the old Transfer Ready DtTm field and Transfer Ready date and time, but we eliminated special cases and differences between medicine and critical care.
Related articles
TR_info_status
Legacy Content
This page contains Legacy Content.- Explanation: This is a legacy data field, its DataElementEndDate is in the past.
- Successor: No successor was entered
Click Expand to show legacy content.
Data Element (edit) | |
Field Name: | TR_info_status |
CCMDB Label: | (label in CCMDB) |
CCMDB tab: | Dispo |
Table: | L_Log table |
Data type: | string |
Length: | 19 |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 2016-05-05 |
End Date: | 2020-10-15 |
Sort Index: | 48 |
Cross-check field that will contain data if Transfer_Ready_DtTm field is empty
This field is used in conjunction with the Transfer_Ready_DtTm field, see there for info on how it is used.
Cross Checks
Data Integrity Checks (automatic list)
none found
Related articles
ADL_Bathing
Data Element (edit) | |
Field Name: | ADL_Bathing |
CCMDB Label: | Bathing |
CCMDB tab: | ADL |
Table: | L Log table |
Data type: | string |
Length: | 15 |
Program: | Med |
Created/Raw: | Raw |
Start Date: | 2003-10-01 |
End Date: | 2300-01-01 |
Sort Index: | 49 |
Need for help with bathing; component of ADL.
See also: ADL General Collection Information
Description | Unassisted | Minor Assistance | Major Assistance |
---|---|---|---|
Either sponge bath, tub bath, or shower | Receives no assistance (gets in and out of tub if tub is the usual means of bathing) | Receives assistance in bathing only one part of the body (such as the back or leg) | Receives assistance in bathing more than one part of the body (or not bathed) |
Related articles
ADL_Dressing
Data Element (edit) | |
Field Name: | ADL_Dressing |
CCMDB Label: | Dressing |
CCMDB tab: | ADL |
Table: | L Log table |
Data type: | string |
Length: | 15 |
Program: | Med |
Created/Raw: | Raw |
Start Date: | 2003-10-01 |
End Date: | 2300-01-01 |
Sort Index: | 50 |
Need for help with dressing; component of ADL.
See also: ADL General Collection Information
Description | Unassisted | Minor Assistance | Major Assistance |
---|---|---|---|
Gets clothes from closets and drawers including underclothes, outer garments, and using fasteners, e.g., for braces | Gets clothes and gets completely dressed without assistance | Gets their clothes and gets dressed without assistance except in tying shoes or buttoning or zipping up items | Receives assistance in getting clothes or in getting dressed or stays partly or completely undressed |
Related articles
=== ADL_Toileting === ADL Toileting
ADL_Transfering
Data Element (edit) | |
Field Name: | ADL_Transfering |
CCMDB Label: | Transfering |
CCMDB tab: | ADL |
Table: | L Log table |
Data type: | string |
Length: | 15 |
Program: | Med |
Created/Raw: | Raw |
Start Date: | 2003-10-01 |
End Date: | 2300-01-01 |
Sort Index: | 52 |
Need for help with transferring; component of ADL
See also: ADL General Collection Information
Description | Unassisted | Minor Assistance | Major Assistance |
---|---|---|---|
Moving from one place to another while performing activities | Moves in and out of bed as well as in and out of chair without assistance; may use object for support such as cane or walker | Moves in and out of bed or chair with assistance | Doesn't get out of bed |
Related articles
ADL_Continence
Data Element (edit) | |
Field Name: | ADL Continence |
CCMDB Label: | Continence |
CCMDB tab: | ADL |
Table: | L Log table |
Data type: | string |
Length: | 15 |
Program: | Med |
Created/Raw: | Raw |
Start Date: | 2003-10-01 |
End Date: | 2300-01-01 |
Sort Index: | 53 |
Control of urination and bowel movements; component of ADL
See also: ADL General Collection Information
Unassisted | Minor Assistance | Major Assistance |
---|---|---|
Controls urination and bowel movement completely by self, including patients with chronic renal failure; manages Foley at home on own (Foley is inserted solely to keep track of fluid output) | Has occasional "accidents" | Supervision helps keep urine or bowel control; catheter is used, or patient is incontinent; Foley is used because patient is unable to control bladder function (if it cannot be determined if the patient would be continent without a foley and the patient has a Foley, then score as major) |
Related articles
ADL_Feeding
Data Element (edit) | |
Field Name: | ADL_Feeding |
CCMDB Label: | Feeding |
CCMDB tab: | ADL |
Table: | L Log table |
Data type: | string |
Length: | 15 |
Program: | Med |
Created/Raw: | Raw |
Start Date: | 2003-10-01 |
End Date: | 2300-01-01 |
Sort Index: | 54 |
Need for help with feeding; component of ADL
See also: ADL General Collection Information
Description | Unassisted | Minor Assistance | Major Assistance |
---|---|---|---|
Preparing and eating food | Feeds self without assistance; NPO due to pre-OP, tests or procedures or GI bleeding | Feeds self except for getting assistance in cutting meat or buttering bread | Receives assistance in feeding of is fed partly or completely by using tubes or intravenous fluids; dysphagia |
Related articles
=== Ap_AdmitType === Ap AdmitType === Ap_Chronic === This article is about Chronic Health in the context of the APACHE score, see Comorbid Diagnosis for info on the comorbidities we collect, and Charlson Comorbidity Index for the Charlson comorbidities that are also used for the Alert score.
This value is now derived from ICD10 diagnoses, see Change for Apache Chronic to ICD10 from separate variable for details.
Legacy Content
This page contains Legacy Content.- Explanation: This is a legacy data field, its DataElementEndDate is in the past.
- Successor: No successor was entered
Click Expand to show legacy content.
Data Element (edit) | |
Field Name: | Ap_Chronic |
CCMDB Label: | Chronic |
CCMDB tab: | Apache |
Table: | L_Log table |
Data type: | string |
Length: | 30 |
Program: | CC |
Created/Raw: | Raw |
Start Date: | |
End Date: | 2022-02-17 |
Sort Index: | 56 |
Specific chronic pre-existing conditions used for APACHE score.
This value is used in conjunction with Admit Type for APACHE II to calculate the Chronic_Health_Score, one of the components of the.
To be considered to be a chronic disease, the chronic condition must have been documented as present before current hospitalization.
Chronic Health Table
Dropdown in CCMDB.accdb | Orignial APACHE II CH list with definitions | ||
1. Immunocompromized (this category includes the following: Metastatic Cancer, Hematological Malignancy-Lymphoma, Leukemia and also AIDS) | (this is applicable to items 1-5. Receiving therapy that suppresses resistance to infection such as: at least one of the following:
| ||
2. Met Cancer
|
|||
3. HematMalign e.g. Lymphoma or Leukemia
|
|||
4. AIDS | |||
5. CRF-severe | Receiving Chronic out-patient hemo- or peritoneal dialysis prior to hospital admission. | ||
6. Liver-severe |
any of:
| ||
7. Lung severe |
any of the following that results in severe exercise restriction (i.e. unable to climb stairs or perform household duties):
or any of the following
| ||
8. CVS min exert | Class 4 Angina - pain @ rest or with minimal exertion | ||
9. No Chronic Health |
Implementation
- Chronic Health is stored as a single-choice dropdown in CCMDB.accdb and Centralized data.mdb
- There is an additional option "0HasChronic"; this can not be selected in CCMDB.accdb but is used in Centralized data.mdb for old records that were imported from TMSX and MedTMS where the detailed data was not collected
ICD10
We are moving to derive this concept from APACHE Comorbidities in ICD10 codes.
Change log
- 2022-02-17 - decided to stop collecting this and apply Change for Apache Chronic to ICD10 from separate variable
- 2022-02-09 - Julie, Tina and Allan discussed Julie's most recent analysis of this; there are still many differences in dx vs chronic, with higher and lower counts for different components. Allan quotes a paper that acknowledges this difference in count, but that the Apache score ends up similar. Question raised: is the saving of time in no longer collecting this as a field worth the loss of accuracy.
- 2021-04-22 - preliminary analysis of how deriving this from ICD10 would compare with previous manual collection; many differences; Tina emailed Allan and Julie, more to come
- 2021-04-19 - Added Drug-induced immunosuppression since that component of this code was not previously collected comprehensively
- 2021-03-11 - The list of drugs is at Template:List of immunosuppressive drugs.
- 2021-02-22 - AG sent email to Julie and Tina to get back to this change.
- 2018-11-28 - AG confirmed that this is an option
Legacy
- when sent for import into TMSX and MedTMS the chronic health score was translated into yes or no; when we moved to Centralized data.mdb these were imported as "0HasChronic"
- the fields were made into a pick list of 9 items that belong to one of the five APACHE II Chronic Health categories because Medicine wanted to use both APACHE II and SAPS II on Medicine patients. SAPS II and APACHE II scored these same chronic health items differently. SAPS is no longer collected.
Related articles
=== Ap_Temp === Ap Temp === Ap_SapsSysBP === Ap SapsSysBP === Ap_APSysBP === Ap APSysBP === Ap_APDiasBP === Ap APDiasBP === Ap_HeartRate === Ap HeartRate === Ap_RespRate === Ap RespRate === Ap_Eye === Ap Eye === Ap_Motor === Ap Motor === Ap_Verbal === Ap Verbal === Ap_FIO2 === Ap FIO2 === Ap_PO2 === Ap PO2 === Ap_CO2 === Ap CO2 === Ap_pH === Ap pH === Ap_SerCO2 === Ap SerCO2 === Ap_Na === Ap Na === Ap_K === Ap K === Ap_Hemat === Ap Hemat === Ap_WBC === Ap WBC === Ap_Creat === Ap Creat === Ap_ARF === Ap ARF
R_Complete
Data Element (edit) | |
Field Name: | R Complete |
CCMDB Label: | not stated |
CCMDB tab: | Top Row |
Table: | L Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 1 Jan 2000 |
End Date: | 31 Dec 2100 |
Sort Index: | 78 |
true when patient registry data is complete
started after jan 1 2000
Checkbox is set to true by collector when patient registry data (Category:Registry Data) is complete. Checking the box initiates Data Integrity Checks relevant for that data.
ADL_Complete
Data Element (edit) | |
Field Name: | ADL Complete |
CCMDB Label: | not stated |
CCMDB tab: | Top Row |
Table: | L Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 1 Jan 2000 |
End Date: | 31 Dec 2100 |
Sort Index: | 79 |
true when patient ADL data is complete
started after jan 1 2000
Checkbox is set to true by collector when patient registry data (Category:ADL) is complete. Checking the box initiates Data Integrity Checks relevant for that data.
Ap_Complete
Data Element (edit) | |
Field Name: | Ap Complete |
CCMDB Label: | not stated |
CCMDB tab: | Top Row |
Table: | L Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 1 Jan 2000 |
End Date: | 31 Dec 2100 |
Sort Index: | 80 |
True when patient APACH II data is complete
started after jan 1 2000
Checkbox is set to true by collector when patient APACHE II data (Category:APACHE II) is complete. Checking the box initiates Data Integrity Checks relevant for that data. === ApLab_Complete === ApLab Complete
Labs_Complete
Data Element (edit) | |
Field Name: | Labs_Complete |
CCMDB Label: | not stated |
CCMDB tab: | Top Row |
Table: | L Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 1 Jan 2000 |
End Date: | 31 Dec 2100 |
Sort Index: | 82 |
True when patient Labs data is complete
All collectors use this checkbox differently. And at this point labs are not even counted in there, so it is most likely used as a "I have finished counting images and blood products"
Checking the box initiates Data Integrity Checks relevant for that data.
Related articles
Tmp_Complete
Data Element (edit) | |
Field Name: | Ap Complete |
CCMDB Label: | not stated |
CCMDB tab: | Top Row |
Table: | L Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 1 Jan 2000 |
End Date: | 31 Dec 2100 |
Sort Index: | 83 |
True when patient Tmp data is complete
started after jan 1 2000
Checkbox is set to true by collector when patient Tmp data (Category:L TmpV2 Data, Category:Project) is complete. Checking the box initiates Data Integrity Checks relevant for that data.
Como_Complete
Data Element (edit) | |
Field Name: | Como_Complete |
CCMDB Label: | not stated |
CCMDB tab: | Top Row |
Table: | L Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 1 Jan 2000 |
End Date: | 31 Dec 2100 |
Sort Index: | 84 |
True when patient comorbid diagnosis data is complete
started after jan 1 2000
Checkbox is set to true by collector when patient comorbid diagnosis data (Category:Comorbid) is complete. Checking the box initiates Data Integrity Checks relevant for that data.
Diag_Complete
Data Element (edit) | |
Field Name: | Diag_Complete |
CCMDB Label: | not stated |
CCMDB tab: | Top Row |
Table: | L Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 1 Jan 2000 |
End Date: | 31 Dec 2100 |
Sort Index: | 85 |
True when patient diagnosis data is complete
started after jan 1 2000
Checkbox is set to true by collector when patient diagnosis data (ICD10 collection and CCI Collection) is complete. Checking the box initiates Data Integrity Checks relevant for that data.
Pharm_Complete
Data Element (edit) | |
Field Name: | Como_Complete |
CCMDB Label: | not stated |
CCMDB tab: | Top Row |
Table: | L Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 1 Jan 2000 |
End Date: | 31 Dec 2100 |
Sort Index: | 86 |
True when patient pharmacy diagnosis data is complete
started after jan 1 2000
Checkbox is set to true by collector when patient pharmacy diagnosis data (Category:Pharmacy) is complete. Checking the box initiates Data Integrity Checks relevant for that data. === Pharm_Flow_Complete === Pharm Flow Complete
Record
Data Element (edit) | |
Field Name: | Record |
CCMDB Label: | not stated |
CCMDB tab: | Top Row |
Table: | L Log table |
Data type: | string |
Length: | 8 |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 1 Jan 1900 |
End Date: | 31 Dec 2100 |
Sort Index: | 88 |
Free choice use by collectors to help collection, this field has no consistent meaning.
=== Room_nr === Room nr === RecordStatus === if you are looking for the field collectors can use for their own custom designations, see Record field
Data Element (edit) | |
Field Name: | RecordStatus |
CCMDB Label: | Status |
CCMDB tab: | Top Row |
Table: | L_Log table |
Data type: | string |
Length: | 20 |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 2013-04-24 |
End Date: | 2300-01-01 |
Sort Index: | 80 |
status of the data in the record. Possible values are complete, sent, questioned and vetted.
The field can be seen on the Patient Viewer and the Patient List. The setting of the field will affect processing as follows.
Possible Values
incomplete
A patient is automatically set to incomplete when a new record is created.
complete
Once a patient's record is complete and all checkboxes in the Patient Viewer are set, the collector will try to set the patient to "complete". This changes triggers the CCMDB.accdb Data Integrity Checks that are set to run on completion; if any problems are found, the record is set back to "incomplete". Records that are set to complete will be treated differently during the next sending. Ideally the collector will set the field to "complete" as soon as you have entered the last data for a patient, while they still have the chart to be able to fix errors without having to get the chart again. Also, it saves time during sending.
sent
At sending, records that were set to "complete" will be changed to "sent" in both CCMDB.accdb and Centralized_data.mdb. A record that is "sent" can no longer be edited or overwritten by CCMDB.accdb during sending. If a record needs to be re-sent, the data processor needs to change the setting to "incomplete" first. In CCMDB.accdb, the "Delete Sent Patients" button checks for this field to be set to "sent" to delete patients.
discontinued
"Discontinued" is used for the following scenarios:
- remnants of VIC Family Medicine patients which was collected after the consolidation for a period of one year from Oct 2017 to Oct 27, 2018. There were 30 patients still in the VIC units N4C, N5C and S5C by Oct 27,2018 when the decision to stop collection happened.
- Lost/missing charts, see that page for details
only in CCMDB.mdb
deleted
We keep some portion of data for profiles that have been logically deleted of the laptop for 90 days (based on Dispo_DtTm). Use the "Previous entry" button to see all logically deleted records, or the Cognos2 Service Starter#"Show records on laptop with same chart number" button to see only records related to that patient.
When the "Delete Sent Patients" button is used, part of the record is actually retained for use by Cognos Report Integrator and collector investigations such as whether a patient had already been entered and deleted. The RecordStatus for these is set to "deleted" and they don't show up in the Patient List.
Names and most registry data and the entries of child tables such as Dxs etc are deleted, but Boarding Loc and Service tmp entry (and all other L TmpV2 entries) are retained.
Logically deleted profiles are eventually actually deleted by the "Delete Sent Patients" button (see time threshold above).
only in Centralized data.mdb
questioned
As part of the Centralized data Vetting Process the data processor runs queries to ensure data is valid. If any "sent" record has problems, she sets the recordstatus to "questioned". In the future a questioned record may be copied back to the collectors laptop automatically at the next send time to facilitate validation; likely the data processor would put an entry into the Notes field to tell the data collector what is wrong. See Questioning data back to collectors.
vetted
At the end of the Centralized data Vetting Process the data processor will press the "Vet all sent" button. At this time, any sent records that have not been flagged as "questioned" should be clean, so the button will set all "sent" to "vetted".
Data Integrity Checks
A lot of Data Integrity Checks are triggered when this field is set to complete.
Data checks that actually check validity of data in this field
Data Integrity Checks (automatic list)
none found
Related articles
=== LastChanged_DtTm === LastChanged DtTm === [pharm_Vitamin K antagonists] === {{: [pharm_Vitamin K antagonists]}} === [pharm_Heparin cont inf] === {{: [pharm_Heparin cont inf]}} === [pharm_Direct thrombin inhibitors] === {{: [pharm_Direct thrombin inhibitors]}}
pharm_Heparinoids
Data Element (edit) | |
Field Name: | pharm_Heparinoids |
CCMDB Label: | (B2)Heparinoids |
CCMDB tab: | Pharm |
Table: | L_Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 2012-01-01 |
End Date: | 2300-01-01 |
Sort Index: | 95 |
True if drug in field name was given
See Pharmacy collection for collection info.
Drugs included in this are:
- danaparoid (Orgaran-DVT, Orgaran (HIT))
=== [pharm_Factor Xa inhibitors] === {{: [pharm_Factor Xa inhibitors]}} === [pharm_Dopamine cont inf] === {{: [pharm_Dopamine cont inf]}} === [pharm_Dobutamine cont inf] === {{: [pharm_Dobutamine cont inf]}} === [pharm_Norepinephrine cont inf] === {{: [pharm_Norepinephrine cont inf]}} === [pharm_Epinephrine cont inf] === {{: [pharm_Epinephrine cont inf]}} === [pharm_Phenylephrine cont inf] === {{: [pharm_Phenylephrine cont inf]}} === [pharm_Vasopressin cont inf] === {{: [pharm_Vasopressin cont inf]}} === [pharm_Milrinone cont inf] === {{: [pharm_Milrinone cont inf]}} === [pharm_Paralytics cont inf] === {{: [pharm_Paralytics cont inf]}}
pharm_corticosteroids
Data Element (edit) | |
Field Name: | pharm_corticosteroids |
CCMDB Label: | (E2)corticosteroids |
CCMDB tab: | Pharm |
Table: | L_Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 2012-01-01 |
End Date: | 2300-01-01 |
Sort Index: | 105 |
True if drug in field name was given
See Pharmacy collection for collection info.
Exclude if only route is inhaled.
Drugs included in this are:
- Exclude if only route is inhaled.
- betamethasone, cortisone, hydrocortisone (Solu-Cortef), methylprednisolone (Solu-Medrol), prednisone, dexamethasone (decadron), budesonide (Entocort), prednisolone, triamcinolone (tricortone)
- NOT fludrocortisone (Florinef) excluded because it has no immunosuppressive effects)
Related articles
=== [pharm_amphotericin B] === {{: [pharm_amphotericin B]}}
pharm_macrolides
Legacy Content
This page contains Legacy Content.- Explanation: This is a legacy data field, its DataElementEndDate is in the past.
- Successor: No successor was entered
Click Expand to show legacy content.
Data Element (edit) | |
Field Name: | pharm_macrolides |
CCMDB Label: | <not in CCMDB> |
CCMDB tab: | Pharm |
Table: | L_Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 2012-01-01 |
End Date: | 2013-03-17 |
Sort Index: | 107 |
True if drug in field name was given
See Pharmacy collection for collection info. === [pharm_1st or 2nd generation cephalosporins] === {{: [pharm_1st or 2nd generation cephalosporins]}} === [pharm_4th generation cephalosporins] === {{: [pharm_4th generation cephalosporins]}} === [pharm_antistaph penicillins] === {{: [pharm_antistaph penicillins]}}
pharm_aminoglycosides
Legacy Content
This page contains Legacy Content.- Explanation: This is a legacy data field, its DataElementEndDate is in the past.
- Successor: No successor was entered
Click Expand to show legacy content.
Data Element (edit) | |
Field Name: | pharm_aminoglycosides |
CCMDB Label: | <not in CCMDB> |
CCMDB tab: | Pharm |
Table: | L_Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 2012-01-01 |
End Date: | 2013-03-05 |
Sort Index: | 111 |
True if drug in field name was given
See Pharmacy collection for collection info. === [pharm_influenza drugs] === {{: [pharm_influenza drugs]}}
pharm_bosentan
Data Element (edit) | |
Field Name: | pharm_bosentan |
CCMDB Label: | (E5)bosentan |
CCMDB tab: | Pharm |
Table: | L_Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 2012-01-01 |
End Date: | 2300-01-01 |
Sort Index: | 113 |
True if drug in field name was given
See Pharmacy collection for collection info.
Drugs included in this are:
- Tracleer - Oral
broken data
Collection/storage for Bosentan was broken.
We had good data from 2012/Jan/15 until 2012/Jul/02.
Then we did not have data again until 2014/Apr/27, and we have had data since then.
Related articles
=== [pharm_viagra-type vasodilators] === {{: [pharm_viagra-type vasodilators]}} === [pharm_special upper GI bleeding agents] === {{: [pharm_special upper GI bleeding agents]}}
pharm_amiodarones
Data Element (edit) | |
Field Name: | pharm_amiodarones |
CCMDB Label: | (F2)amiodarones |
CCMDB tab: | Pharm |
Table: | L_Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 2012-01-01 |
End Date: | 2300-01-01 |
Sort Index: | 116 |
True if drug in field name was given
See Pharmacy collection for collection info. === [pharm_anti-TB drugs] === {{: [pharm_anti-TB drugs]}}
pharm_statins
Data Element (edit) | |
Field Name: | pharm_statins |
CCMDB Label: | (F4)statins |
CCMDB tab: | Pharm |
Table: | L_Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 2012-01-01 |
End Date: | 2300-01-01 |
Sort Index: | 118 |
True if drug in field name was given
See Pharmacy collection for collection info.
Drugs included in this are:
- atorvastatin (Lipitor)
- fluvastatin (Lescol)
- simvastatin (Zocor)
- lovastatin (Mevacor)
- pravastatin (Pravachol)
- rosuvastatin (Crestor)
Related articles
pharm_PPI
Data Element (edit) | |
Field Name: | pharm_PPI |
CCMDB Label: | (A1)PPI |
CCMDB tab: | Pharm |
Table: | L_Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 2012-01-01 |
End Date: | 2300-01-01 |
Sort Index: | 119 |
True if drug in field name was given
Drugs included in this are:
- esomeprazole (nexium)
- pantoprazole (pantaloc)
- omeprazole (pilosec)
- rabeprazole (aciphex, pariet)
- lansoprazole (prevacid)
- dexlansoprazole (kapidex or dexilant)
pharm_H2_blockers
Data Element (edit) | |
Field Name: | pharm_H2_blockers |
CCMDB Label: | (A2)H2 Blockers |
CCMDB tab: | Pharm |
Table: | L_Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 2012-01-01 |
End Date: | 2300-01-01 |
Sort Index: | 120 |
True if drug in field name was given
Drugs included in this are:
- ranitidine (zantac)
- famotidine (pepcid)
- cimetidine (tagamet)
- nizatidine (tazac)
Related articles
pharm_furosemide
Data Element (edit) | |
Field Name: | pharm_furosemide |
CCMDB Label: | (D5)furosemide cont inf |
CCMDB tab: | Pharm |
Table: | L_Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 2012-01-01 |
End Date: | 2300-01-01 |
Sort Index: | 121 |
True if drug in field name was given
Drugs included in this are:
- Lasix
pharm_heparin_sq
Data Element (edit) | |
Field Name: | pharm_heparin_sq |
CCMDB Label: | (A5)Heparin SQ |
CCMDB tab: | Pharm |
Table: | L_Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 2012-01-01 |
End Date: | 2300-01-01 |
Sort Index: | 122 |
True if drug in field name was given
See Pharmacy collection for collection info.
pharm_LMWH
Data Element (edit) | |
Field Name: | pharm_LMWH |
CCMDB Label: | (A7)LMWH |
CCMDB tab: | Pharm |
Table: | L_Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 2012-01-01 |
End Date: | 2300-01-01 |
Sort Index: | 123 |
True if drug in field name was given
Drugs included in this are:
- dalteparin (fragmin)
- enoxaparin (Lovenox)
- tinzaparin (innohep)
- nadroparin (fraxiparin)
pharm_benzodiazepines
Data Element (edit) | |
Field Name: | pharm_benzodiazepines |
CCMDB Label: | (B4)benzodiazepines cont inf |
CCMDB tab: | Pharm |
Table: | L_Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 2012-01-01 |
End Date: | 2300-01-01 |
Sort Index: | 124 |
True if drug in field name was given
Drugs included in this are:
- Alprazolam (Xanax®)
- Clobazam (Onfi®, Sympazan®)
- Clonazepam (Klonopin®
- Clorazepate (Tranxene®)
- Diazepam (Diastat®, Valium®, Valtoco®)
- Estazolam (ProSom®)
- Flurazepam (Dalmane)
- Lorazepam (Ativan®, Loreev®)
- Midazolam (Nayzilam®, Seizalam®, Versed®)
- Oxazepam (Serax®)
- Quazepam (Doral®)
- Remimazolam (Byfavo®)
- Temazepam (Restoril®)
- Triazolam (Halcion®)
pharm_opioids
Data Element (edit) | |
Field Name: | pharm_opioids |
CCMDB Label: | (B5)opioids cont inf (not PCA) |
CCMDB tab: | Pharm |
Table: | L_Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 2012-01-01 |
End Date: | 2300-01-01 |
Sort Index: | 125 |
True if drug in field name was given
Not PCA. PCA is intermittent.
Drugs included in this are:
- alfentanil (alfenta)
- fentanyl (sublimaze)
- hydromorphone (dilaudid)
- morphine
- meperidine (demerol)
- sufentanil(sufenta)
pharm_propofol
Data Element (edit) | |
Field Name: | pharm_propofol |
CCMDB Label: | (C1)propofol cont inf |
CCMDB tab: | Pharm |
Table: | L_Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 2012-01-01 |
End Date: | 2300-01-01 |
Sort Index: | 126 |
True if drug in field name was given
See Pharmacy collection for collection info.
pharm_insulin
Data Element (edit) | |
Field Name: | pharm_insulin |
CCMDB Label: | (D4)insulin cont inf |
CCMDB tab: | Pharm |
Table: | L_Log table |
Data type: | boolean |
Length: | not stated |
Program: | CC |
Created/Raw: | Raw |
Start Date: | 2012-01-01 |
End Date: | 2300-01-01 |
Sort Index: | 127 |
True if drug in field name was given
See Pharmacy collection for collection info.
- L CCI Picklist table
- L CCI Component table
- L Como table
- L Dxs table
- L ICD10 table
- L Labs Flowsheet table
- L Log table
- L PCH table
- L PHI table
- L Pharm Flowsheet table
- L TISS Form table
- L TISS Item table
- L TmpV2 table
- Data structure
- Legacy Content
- Standards and Conventions
- Data Collection Guide
- Registry Data
- Patient Viewer
- Data Processing
- Demographics
- Identification numbers
- Data Integrity Checks
- CCMDB.accdb
- CCMDB.accdb cross checks triggering for correct values
- Registry checks
- Cognos Report Integrator
- AutoTimeStamps
- To do
- End-of-life related data
- Legacy Data structure
- 2016 Time and Place changes
- Admit/Discharge
- Transfer Ready
- Legacy Data Collection
- Legacy Overflow
- Questions
- Dispo
- Multiple Encounter linking
- Length of stay
- Project
- L TmpV2 Data
- PatientFollow Project
- ADL
- APACHE II
- 2013 data upgrades
- Pharmacy