Auto Data Dictionary

what is this?

This article transcludes the articles for our data fields, or ideally their <onlyinclude> sections.

Work in progress, all articles need to be updated for this to work.

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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

Last Name (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

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

Expand

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

First Name(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

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

Expand

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 .

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

Expandold discussion, result: not at this time

With Cognos EPR Report we now get PHINs from out of province with province prefix; do we want to start collecting these for out-of-province patients for cleaner matching, and to enable better matching for external users of our data such as MCHP? sure. will this affect any of the query? the data type will become text if you will add the province prefix. --JMojica 19:03, 2020 April 5 (CDT) We could just import the PHIN without the prefix, the fact it's a different province already shows. However, it would have a trickle-down effect of having to fix old pseudo-PHINs, and of having to update code that links patients across admissions, and likely more. So, let's leave it for now. Ttenbergen 09:21, 2020 June 3 (CDT) Cognos EPR Report does not provide data on a given line about where a pt was in a previous hospital. If the pt was a med or CC pt at that previous hospital in the previous 2 weeks, we would have rows for him from the other location. However, because we use PseudoPhins for many pts, I currently use the chart number for matching lines to a same patient, so records from other sites don't show up. Pro: there is no clutter of irrelevant info from other sites; Con: Even if data would be available for pts status at other site, I am hiding it. Starting to collect PHIN for all would help this for OOP pts, but would still not address it for legit-no-PHIN pts.

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

see 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

Date of Birth(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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

• Cargo

• SMW

• Categories:  

• form:

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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

• Alias ID collection
• John or Jane Doe patient
• Stolen identities

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(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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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(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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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 field(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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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
  • Some are using this for VAP adjudication criteria, these notes can stay in case there are future questions re. VAP
• 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

ExpandWe 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? I actually prefer a blank notes field. The premise was good but turns out to not be all that helpful.--CMarks 11:53, 2018 December 6 (CST) 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: Laura: I find the guidelines written in this article are sufficient information for the notes field to give tips for usage. If anyone has difficulty when they are covering for someone else, they just need to ask what is meant by specific entries. I would like to speak to anyone who has difficulty. I feel that the notes section is not only used differently for different collectors but also in different scenarios. I like that it allows for individual needs and allows some freedom for any use that each collector may require. The current format is not user friendly and I just wonder who actually is using it. I personally would prefer a blank note field. --LKolesar 07:49, 2018 December 6 (CST) I too, would just prefer a blank note field. As good as the idea for dates and times was, the format just wasn't what I use. DPageNewton 07:57, 2018 December 6 (CST) I do not find this useful or user friendly. I much prefer a blank field so we can enter what we need. Lois I modify the format to suit my needs, so I am not using it as intended. It is less convenient than how I was writing in date and time read up to before the change was made. Good idea, but didn't quite work for me.Mlagadi 08:25, 2018 December 6 (CST) While I appreciate the intent to assist data collectors with collection, I find the current format not helpful. I agree with Laura regarding data collectors having differing needs/preferences, and the best way to accommodate all data collectors would be a blank notes field Pamela Piche 08:45, 2018 December 6 (CST) I prefer a blank note field Lisa Kaita 09:39, 2018 December 6 (CST) I also prefer the note field to be blank. It takes just a few seconds to erase but it's a few seconds I don't have to spare. --mvpenner 10:29, 2018 December 6 (CST)

Related articles

DC Treatment (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 The field has a length of 50 and should be reduced to 2 now that that's the longest content.

added: 2022-06-30 action: 2023-05-04

• Cargo

• Categories

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

Expand

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

Expand

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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

Province Field (R_Province)

Data Element (edit)
Field Name:	R_Province
CCMDB Label:	Province
CCMDB tab:	Dispo
Table:	L_Log table
Data type:	string
Length:	2
Program:	Med and CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	16

Province in which the patient is registered with health care. If the patient is not eligible for health care, it records the province that they reside in.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Collection Instructions

Choose the value for the "Province" field from the dropdown lists in CCMDB.accdb. The provincial abbreviations are the same as for mailing. In addition to the provinces you have the following options:

• US United States
• CF Canadian Funded (RCMP, Canadian Forces...)
• NK Not Known / Not available
• OS Outside of North America

Canadian Forces patients

see Canadian Forces patients

Data Integrity Check List

Data Integrity Checks (automatic list)

none found

Data Structure

The field draws its options from the S_Provinces table in CCMDB.accdb.

Related articles

Sex field (R_Sex)

Data Element (edit)
Field Name:	R_Sex
CCMDB Label:	Sex
CCMDB tab:	Dispo
Table:	L_Log table
Data type:	string
Length:	7
Program:	Med and CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	17

Biological sex of the patient at birth; options are "male" and "female".

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Also see Guidelines for coding sex and gender.

Sex changes over time

For those patients who are transgender or transsexual, document what their sex was at birth. This may mean that a record's FirstName field becomes inconsistent with their Sex field. In those cases, the contents of the Alias_ID_collection might shed lights on the reason.

EPR uses the currently used gender, as far as we could tell. We didn’t review what the policies are about this. Our records may therefore be inconsistent with EPR.

Data Integrity Checks (automatic list)

none found

Related Articles

Registry Patient Type (R_Type)

 

 

 

 

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

Expand

Click Expand to show legacy content.

Data Element (edit)
Field Name:	R_Type
CCMDB Label:	Pt Type
CCMDB tab:	Dispo
Table:	N/A
Data type:	string
Length:	10
Program:	Med and CC
Created/Raw:	Raw
Start Date:	1997-04-01
End Date:	2018-05-09
Sort Index:	18

Service of the attending physician for medicine data, and the type of admit diagnosis for critical care patients.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

The use of this field had changed over time, and it was found to no longer contain what was originally intended and was removed 2018-05-09.

Related data we continue to collect is:

• Previous Service field
• ICUotherService

Medicine Wards

The Patient Type on your registry page can take one of two values:

M-Medical Type

Patient who is admitted under the care of a Medical Service attending physician

S-Surgical Type

• admitted from the OR but is under the care of the Medicine Service Attending Physician.
• admitted from the RR and is under the care of the Medicine Service Attending Physician.

NOTE: if there is a surgical patient on an medicine ward bed that is under a Surgical Service care, we exclude from the database. This is not a medicine service care patient.

Critical Care Units

S-Surgical Type

• admit from OR
• admit from RR
• all Trauma (fall, MVA, stabbing, etc)
• all burns
• all upper GI bleeds
• all intracerebral bleeds
• Pt who undergoes a surgery related to primary reason to ICU in the first 48 hrs of admission to ICU.
• Pt admitted from a SURGICAL WARD
• Pancreatitis if surgery < =48 hrs of admission to unit

M-Medical Type

• Cardiac or respiratory arrest
• Cardiogenic shock
• Pancreatitis if surgery >48 hrs of admission to unit
• don't fall into Surgical or Cardiac type category

C-Cardiac Type

• STB in both MICU and CICU - if under the Care of Cardiology Service. This no longer applies when STB ACCU started July 6, 2016.
• HSC in the MICU unit - if under the Care of Cardiology Service

Other ICU's

• MI
• rhythm disturbances
• unstable angina / ACS
• CHF
• post angio/plasty
• pacemaker insertions (temp or perm)

Note for ICU at HSC and STB only

Patients in MICU under MICU attending physician service that have a cardiac diagnosis should always be coded as medical type whether they are stable or not. The only exception is if a patient is a surgical patient, then mark as surgical type.

StB Cardiac patients

Special rules used to apply

Data Use

Population

CCMDB Data Integrity Checks

have been removed when collection discontinued

Removal of field

The discussion at task meeting in past was to wait until we migrate to ICU10 DX code then Julie and Garland can decide on pt type category.

• 2018-May-7: Steering Committee meeting - reviewed and agreed to stop Registry Pt Type. Field removed from CCMDB.accdb. See CCMDB.mdb Change Log 2018#2018-05-09.

}}

Last Opened field (LastOpened_DtTm)

Last Opened field

Pre acute living situation field

Data Element (edit)
Field Name:	Pre_Acute_Living_Situation
CCMDB Label:	Pre Acute Living Situation
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:	35

Info about the living situation of the patient prior to the current hospitalization.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Collection Instruction

For each patient,

• enter the following option that most closely matches:
  • Apartment
  • Personal Care Home- including Riverview PCH and Deer Lodge PCH
  • House - also includes bungalow style condos (if specified)
  • Chronic Health Facility- this includes patients that come from Deer Lodge Rehab ward, Riverview Rehab, Riverview Palliative care, or Riverview LTV, St Amant, Selkirk Mental Health Center. Even if the patient was expected to return home, use this entry if this is where they were physically before the current admission
  • Community Facility with support - includes Assisted Living, Supportive Housing, Group homes, Lennox Bell Lodge
  • Prison / Jail / Correctional Institution
  • Homeless
  • other - known but not listed - if you know the situation but nothing on the list matches closely - for example Mobile homes/parks, rooming house, hotel
  • location missing/unknown - if the situation is unknown
  • legacy empty

Data Use

Some of the concepts were broken down further, such as homeless or institutionalized status, since these questions keep coming up.

Start times

See infobox for med. For the Critical Care program this concept did not get collected prior to the 2016 Time and Place changes.

• 2022-12-29 - added option "Community Facility with support" to replace "Assisted Living" and "Supportive Housing" for patients with Dispo DtTm > 2023-01-01

Data Integrity Checks

Data Integrity Checks (automatic list)

none found

Implementation

The field is populated with options from the s_pre_acute_living_situation table.

Related Articles

Pre-admit Inpatient Institution field

Data Element (edit)
Field Name:	Pre_admit_Inpatient_Institution
CCMDB Label:	Pre-admit Inpatient Institution
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:	36

The most recent previous inpatient location of patients who were already inpatients elsewhere and who have been under medical care continuously before coming to our unit.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Collection Instruction

• For each patient, enter the most recent in-patient location where the patient has been admitted during this continuous episode of hospitalization at this or other hospitals
  • for places where we collect, use the Service/Location used by the counterpart laptop: <site>_Med, GH-CC, HSC MICU , HSC SICU, HSC_IICU, STB MICU, STB_ICCS, STB_ACCU
  • for wards where we don't collect: <site>_Ward or other external entry e.g. home

ExpandExample:

HSC MICU --- family medicine ward at the Vic --- HSC_ER --- STB_ER --- cath lab --- HSC_MICU. Code the Pre-admit Inpatient Institution field as: VIC_Ward

• if you know the situation but nothing on the list matches closely, enter other - known but not listed
• if the situation is unknown, enter location missing/unknown
• if the patient did not come from an inpatient location, enter "not applicable"
  • for example if they came from home or a clinic
  • the ER (at your site or elsewhere) is not an inpatient location, so enter "not applicable"

Where to find this information

If patient came from a different Winnipeg hospital this will be recorded in the “Visit History” on the EPR.

Ambiguous locations

• The following ARE NOT considered inpatient locations, enter "NA / not applicable"
  • Any PCH (see Chronic Health Facility for additional instructions)
  • Grace Nursing Home Ward - We consider admissions from there as readmissions, so would be coded as if they had come from home. Consistent with that we will consider these not inpatient locations, so code them as "NA / not applicable". (As per meeting with Dr Roberts 2016-05-05)
  • Day-surgery locations - use "<hosp> ambulatory care"

Chronic Care Facilities

They are a changing and complicated case, see Chronic Health Facility.

Intra-facility and inter-facility transfers

If a patient gets transferred to another ward in the same or different hospital, enter <site>_Med, <site>_Ward or <site>_CC (as appropriate) as both the Previous Location field and the Pre-admit Inpatient Institution field.

Arrivals from a borrowed bed

See and follow Previous Location field#Borrowed Bed Or Boarding Loc

Several pre-admit locations

If a patient travels through several pre-admit inpatient locations we will only have data on the last one. We understand that. Just to be clear.

ExpandExample:

Pt was on a ward as an inpatient then went to ICU, then was transferred to the ward you are collecting on. Previous location would be ICU and previous inpatient institution would also be ICU.

"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.

ExpandSQL query of what is currently available

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 / Purpose

To document where those patients who were inpatients immediately before arriving on our ward/unit came from.

The detailed information will allow us also to distinguish between patients who were or were not inpatients before arrival. This is relevant to a patient's risk of bad outcomes.

The information will also give our administrators a better idea of which other hospitals are sending us patients, which they will use for planning.

Cross Checks

Data Integrity Checks (automatic list)

none found

Reports

• The information will be part of the Inter-facility transfer report (i.e. inpatients coming from other facility outside the region or within the region). Also the information will be useful for research projects where a patient will be tagged if already an inpatient before arrival to the unit or ward. JMojica 11:45, 2016 June 6 (CDT)

Implementation

The field is populated with options from the s_dispo table.

Legacy

This field is part of the 2016 Time and Place changes and did not previously exist.

Nursing stations

We used to collect nursing stations in hospital previous but would not include them under the new scheme because they are not inpatient locations. Julie and Tina met with Randy Martin 2016-04 and he confirmed he doesn't need them.

Related articles

Previous Location field

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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Collection Instruction

For each patient,

• enter the option that most closely matches:
  • for places where we collect, use the Service/Location used by the counterpart laptop: <site>_Med, GH-CC, HSC MICU , HSC SICU, HSC_IICU, STB MICU, STB_ICCS, STB_ACCU
  • for wards where we don't collect: <site>_Ward or other external entry e.g. home
• if the patient is a direct admission use <site>_UC, <Site>_ER, <site>_ward, <site>_Med, <site>_ICU or temporary location depending on the scenario (see direct admit scenarios below)
• 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

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.

Borrowed Bed Or Pt Boarding On Other Unit

• Use the Boarding Loc of the service taking care of the patient:<site>_Med, GH-CC, HSC_MICU, HSC_SICU, HSC_IICU, STB MICU, STB_ICCS, STB_ACCU.

Direct Admit Scenarios

• inpatients from CON, OAK, VIC who are direct transfers to HSC/STB/GRA, the Pre-admit Inpatient Institution and Previous Location will be <site>_ward, even if the patient spends time in that site's UC prior to transfer. If not yet an inpatient from CON/OAK/VIC and transfer is from their UC, then previous location is the <site>_UC.
• For direct transfers from HSC/STB/GRA, if an inpatient, and no in-between temporary location, the Pre-admit Inpatient Institution is the same as Previous Location (e.g. GH_med, or HSC_MICU)
  • if there is a temporary location in-between, then Previous Location is equal to the temporary location (e.g. OR, RR, Cath Lab, Dialysis, IR or Other procedure location) and Pre-admit Inpatient Institution would be the previous <site>_inpatient location
  • If not yet an inpatient from HSC/STB/GRA and coming from <other site> ER then previous location is <other site> ER, and the Pre-admit Inpatient Institution would be not applicable
• If a homeless patient is admitted directly then code them as admitted from home.
• If a patient is admitted directly from prison, jail or a correctional institution, code this as an admission from "Institution NOS". See Prison / Jail / Correctional Institution for additional info.

Exceptions

• We have a few units in the Region that have a mix of different services (internal medicine, surgical, family medicine etc). For patients from these units:
  • If patient was under internal medicine service, enter <site>_Med
  • If not under internal medicine service, enter the <site>_Ward
• for Riverview and Deer Lodge, see Chronic Health Facility see Pre-admit Inpatient Institution field or the various wards that are considered an inpatient location
• patients from POU (psych evaluation unit @ HSC) as "HSC ambulatory care" - This is not an inpatient ward.
• patients admitted from day surgery units, enter <site>_ambulatory care, e.g. this is not considered to be an inpatient location see Pre-admit Inpatient Institution field

Temporary locations

• for patients from the Dialysis unit, use that <site>_Dialysis as previous location. Pre-admit Inpatient Institution would be the unit they came from right before, if applicable.
• patients from the cardiac cath lab, enter STB Cardiac Cath Lab, Pre-admit Inpatient Institution would be the unit they came from right before, if applicable.
• <site>_Interventional Radiology, Pre-admit Inpatient Institution would be the unit they came from right before, if applicable.
• <site>_OR, Pre-admit Inpatient Institution would be the unit they came from right before, if applicable.
• <site>_recovery (PACU), Pre-admit Inpatient Institution would be the unit they came from right before, if applicable.
• Other procedure location, eg. misericordia eye clinic for procedure, Pre-admit Inpatient Institution would be the unit they came from right before, if applicable.
• see also Visits to temporary locations for more coding instructions

"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.

ExpandSQL query of what is currently available

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

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

• Admit from
• Hospital previous
• Var 1 - Admit-from Ward

Related articles

Previous Service field

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

Expand

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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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.

ExpandExample:

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

• GRA CAU#Collection instructions
• HSC CAU#Collection instructions
• STB CAU#Collection instructions

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 field

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

Expand

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 Program Admission or Definition of a Critical Care Program 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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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, ICU Var 4 - Parked in ER , 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.

1. find patients as per off ward field article
2. Write down a list of these patients with their chart numbers on a paper.
3. 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

• Bed borrow

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:

• ICU Var 3 - Overflow
• ICU Var 4 - Parked in ER
• ICU Var 5 - Overflow

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 field

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

Encodes which program a record is part of.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Collection Instruction

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)

ICU 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.
• second example- HSC MICU often overflows or borrows a bed in SICU, but MICU follows them, the Service/Location would be HSC MICU, the Boarding Loc would reflect the real physical location HSC SICU, and the Service tmp entry should be HSC Critical Care Medicine. If the patient is later transferred to HSC MICU, this location would be added as a Boarding Loc, this would remain a single profile. However, iF the Service changes to an SICU service and they take over care, then a new profile would be started showing the new Service Location and the new Service tmp entry and Boarding Loc

is this section still current? Ttenbergen 11:13, 6 March 2025 (CST) It up for discussion tomorrow at JALT Meeting - Rolling Agenda and Minutes 2025 Lisa Kaita 21:04, 10 March 2025 (CDT)

• SMW

• Cargo

• Categories

Minimal Data Set

This entry is part of the Minimal Data Set. Special collection instructions apply, see that page for more info.

Implementation

The field is populated with options from the s_dispo table.

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.

Expand* the name for a service location must be no longer than 8 characters, ie 3 for the hosp identifier, an underscore, and at most 4 for the local identifier

The Service/Location field is one of the components that make up the D_ID field when a record is sent. That field has a length of 18. For 5 digit identifiers: D_ID field length: 18 H5_SOH_Geriatrics-19866 length: 24 Laptop identifier and Pat_ID for a record, eg H5_-19866, lenght: 10 this is assuming a 5 digit Pat_ID; as of 2025-03 our largest is 43865 so this will be OK for some time so our new s_dispo entry can be max 8 for service_locations 4 of that is always e.g. HSC_, so the local descriptor portion is max 4 e.g. HSC_AAAA will work, HSC_BBBBB will not if a Service_Location is used that results in a D_ID length > 18 the error will be a counterintuitive "Invalid SQL statement; expected 'DELETE', 'INSERT', 'PROCEDURE', 'SELECT', or 'UPDATE'. ".

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.

"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.

ExpandSQL query of what is currently available

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 / Purpose

This essentially only encodes which program and site a record belongs to. It has additional meanings in legacy data, see Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry.

Used to categorize/stratify the distribution of patients across program and site when reporting summary statistics.

Integrity checks

Data Integrity Checks (automatic list)

none found

Log / 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.

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

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 field

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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Collection Instruction

surviving patients

• Enter:
  • for places where we collect, use the Service/Location used by the counterpart laptop: <site>_Med, GH-CC, HSC MICU , HSC SICU, HSC_IICU, STB MICU, STB_ICCS, STB_ACCU
  • for wards where we don't collect: <site>_Ward or other external entry e.g. home
• 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 see also BedHeldEnd DtTm

Homeless patients

• If a homeless patient is discharged, either to a place like Siloam Mission, shelter or even without a specific plan, then code them as discharged to home. Consider whether they might have left AMA.
• If discharged to an Alternative Integrated Accommodation with services use home with support services

Prison / Jail / Correctional Institution

If a patient is discharged to prison, jail or a correctional institution, code this as "TRSF to Correctional Facility" as dispo to be consistent with EPR

See Prison / Jail / Correctional Institution for additional coding instructions that may apply.

Additional options similar to "Home"

We have several "Home" like discharge options that may appear in Cognos2 Unit Starter. If the entry from ADT doesn't align with what is found in the chart then correct the entry to what you think is correct:

• Home with Support Services - Discharged to a private residence or apartment with support from the community at home or referred to services. example home care. Note a patient with instructions to return for follow-up or referral to a specialist (as part of a routine discharge order) is NOT considered discharge home with support service/referral
  • includes people on Home O2, they are part of the Home Oxygen home care program
• TRSF Group/Supportive housing - includes group home

I thought we had decided at JALT to collect this as presented by EPR... do I remember this wrong? I had already added it in CCMDB.accdb Change Log 2025#2025-03-11-1. Ttenbergen 22:52, 11 March 2025 (CDT) Yes, I saw that, come to think of it I don't think we decided, not in my notes, but we can use it and I will change the wiki instructions Lisa Kaita 11:25, 13 March 2025 (CDT)

• SMW

• Cargo

• Categories

• TRSF to Residential Care- Includes transfer to long-term care home (24 hour nursing), mental health and/or addiction treatment center or hospice/palliative care facility.
  • for PCH use Dispo PCH options
  • for hospice, see Hospice
  • for palliative care use the appropriate palliative care options
  • for mental health or addiction treatment center use Dispo Home with Support Services

Chronic Health Facility

This is somewhat messy and fluid, so see Chronic Health Facility

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.

Manitoba Nursing Station

• use "Outside City - unknown/other"

If this is actually done then why don't we just make the nursing stations available? We already have s_dispo table entries for them. 35 entries since 2016, 6 in the last 12 months. Are there other things for which this entry is used? Checked for reasons for this decision but they don't appear documented Ttenbergen 19:42, 13 March 2025 (CDT)

• SMW

• Cargo

• Categories

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.

ExpandSQL query of what is currently available

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 / Indicators

• Unit Mortality
• ICU Interfacility Transfer/Length of Time for Transfer from ED to ICU within same facility/Transfer Delay (Critical Care)/Transfer Delay (Medicine)
• Discharges out of hospital
• Organ donor rate
• AMA Rate
• Linking admissions
• Readmission Rate to ICU/Readmission to MedWard

Cross checks

Data Integrity Checks (automatic list)

none found

Implementation

The field is populated with options from the s dispo table.

Related Articles

Legacy

• 2025-03-11
  • one other option in EPR for discharge to was "TRSF to Residential Care" - we decided not to switch to this because we currently record more detailed information.

That more detailed info included things like HSC Lennox Bell; we discussed whether or not we need to document the details of this. If so, the following is likely a starting point: Home Home with support Institution NOS TRSF Group/Supportive housing TRSF to Correctional Facility any Hospices GH-Transitional care HSC - Transitional care Misericordia - Transitional care STB - Transitional care VIC - Transitional care HSC Lennox Bell Manitoba Adolescent Treatment Center - unknown/other

• SMW

• Cargo

• Categories

• 2025-03-07
  • started to collect "TRSF to Correctional Facility" as dispo to be consistent with EPR; for Previous Location continue to use the old entry "Institution, NOS"

earlier legacy info

This field is part of the 2016 Time and Place changes and was affected by the PatientFollow_Project.

It a combination of our previous

• Discharge To
• Var 2 - Discharge-to Ward
• ICU Var 6 - AMA
• Survive / Expired

Data from these fields has been back-populated to the this field so data is available from the beginning of the database.

Related articles:

• Organ Donor/Braindead

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 field

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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

ExpandIf a patient needs to be entered other than through Cognos

In EPR find Patient Under Patient Info tab in the Summary Views on the left, click on Visit History find the earliest entry of an Inpatient Type for your current hospital admission enter the Admit/Reg date/time from the first column as your Visit Admit DtTm field in CCMDB.accdb for this field, you must use the date/time in the EPR, and not from patient chart notes. 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

Accept_DtTm field

_ccmdb_dev Field is legacy; once no longer used, remove it from sending and then from ccmdb_data. remove from sending remove from CCMDB_data

added: 2022-06-30 action: 2023-05-04

• Cargo

• Categories

 

 

 

 

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

Expand

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

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

Patient flow

• 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

ExpandClick to see legacy info

related info: Change to start collection at accept rather than arrive time 2017_January: also enter lines in TMP for all AcceptDateSources. The source for gathering the accept date/time may vary from site to site see #Possible documentation locations This field is part of the 2016 Time and Place changes. For medicine this concept is related to admit date and time (when pt is from ER). It does not simply replace the field, so this value still needs to be entered for patients not from ER. Resp. field L_Log.R_AdmDate and L_Log.R_AdmTime For critical care this concept is related to Service Sending to ICU. (There is no comparable field in ICU for this in the old system).

Related articles

Arrive_DtTm field

_after Field is legacy; once no longer used, remove it from sending and then from ccmdb_data. Query to check: SELECT L_Log.D_ID, L_Log.RecordStatus, L_Log.Accept_DtTm, L_Log.Arrive_DtTm FROM L_Log WHERE (((L_Log.RecordStatus)="incomplete") AND ((L_Log.Accept_DtTm) Is Not Null) AND ((L_Log.Arrive_DtTm) Is Not Null)); 98 left as of 2022-08-04 None left as of 2023-05-04, field can be removed... remove from sending remove from CCMDB_data

added: 2022-06-30 action: 2023-05-04

• Cargo

• Categories

 

 

 

 

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

Expand

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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

ExpandClick to see legacy info

For Medicine this concept is related to old ER Wait date an time. From June 1, 2011 to June 30, 2016, the Arrive_DtTm in Medicine was in the Tmp project ER Wait and was migrated into the Arrive_DtTm field. For ICU this concept is related to the old Admit date and time. Resp L_Log.R_AdmDate and L_Log.R_AdmTime.

Related Articles

Dispo_DtTm field

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..

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

• LOS
• Multiple Encounter
• Transfer Delay
• bed occupancy

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 field

 

 

 

 

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

Expand

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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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.

ExpandBefore 2020-10-15

For each patient, enter the first date/time of intent to transfer to lower level in the Level of care hierarchy is documented into the Transfer Ready Date and Time Field; see #status changing back and forth if a patient arrives transfer-ready to a lower level of care than the current ward enter the same date into Transfer Ready DtTm field as in Arrive_DtTm field. if not available because the patient was clearly not transfer ready, leave the date/time empty and enter "not transfer ready" into the "TR info status field" if not available but the patient probably was transfer ready and it just wasn't documented, leave the date/time empty and enter "not available" into the "TR info status field" 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
  • Temporary Stopped Date in all wards: May 1, 2010 to Nov 30, 2011

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

TR_info_status field

 

 

 

 

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

Expand

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

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

The Activities of Daily Living (ADL) assesses a patient's capability to perform a certain daily self-care activities.

Collection Instructions

For every Medicine profile, enter the status into the ADL dropdown boxes in the Patient Viewer Tab ADL in CCMDB.accdb.

Timeframe

The ADL assessment (done by allied health or nurses) we utilize is the patient's state of activity on admission (not at home prior to admission). It takes into consideration acute medical issues that resulted in admission to the hospital.

When possible, use an ADL assessment done within 24 hours after the Admit DtTm.

Directed Restrictions

Directed restrictions on a patient's activities should not be assessed as requiring assistance. For example, if a pt is on bed rest restrictions, it does not mean that they are unable physically to get out of bed. If the patient would be able to perform the activity if allowed then they are to be assessed accordingly.

Where to get data

Data to evaluate ADL can be obtained from the following sources:

• OT/PT initial assessment
• Nursing activity flow sheets (if used)
• Nursing database or primary care patient record
• Integrated progress notes
• Risk assessment for falls form (if used)

Specific Activities collected

See the following for specific coding instructions for the different activities.

• ADL Bathing
• ADL Dressing
• ADL Toiletting
• ADL Transfering
• ADL Continence
• ADL Feeding

Data Use

• ADL Score
• ALERT Scale Calculation

References/Background

The evaluation tool used for all Medicine patients is the Katz ADL.

• S Katz et al. Studies of illness in the aged: the index of ADL. American Medical Association, 1963.
• S Katz, SD Downs, HR Cash, RC Grotz. Index of daily living. The Gerontologist 1:20-301.

Related articles

Fields:

• ADL_Bathing
• ADL_Dressing
• ADL_Toileting
• ADL_Transfering
• ADL_Continence
• ADL_Feeding

Apache fields

Admit Type for APACHE II (Ap_AdmitType)

Data Element (edit)
Field Name:	Ap_AdmitType
CCMDB Label:	Admit Type
CCMDB tab:	Apache
Table:	L_Log table
Data type:	string
Length:	10
Program:	Med and CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	55

The Admit Type for APACHE II is a way to classify patients' surgical status and one of the elements used to generate the APACHE score.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Collection Instructions

Code as follows:

• "Surgical Emergency" only if patient meets the criteria in Emergency Surgery (concept)
• "Elective Surgery" only if the patient had surgery that didn't meet criteria in Emergency Surgery (concept), and was admitted directly from the OR or the Recovery Room
• "Medical" for all other patients (even those with recent surgeries)

Relevance

Patients with:

• Chronic Health APACHE + emergent surgery or non operative (medical patient) = 5 points
• Chronic Health APACHE + elective surgery = 2 points
• No Chronic Health APACHE = 0 points

CCI has no concept for emergent

CCI has no way to code the concept of "emergent" so we need to continue to collect this item as is.

Implementation

The possible values are listed in S AP AdmitType table.

Related articles

Chronic Health APACHE (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

Expand

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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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: ≥15mg/kg/day hydrocortisone >3 mg/kg’day of methylprednisolone for >5 days (for entire LOS if pts LOS is less than 5 days). ≥10 mg prednisone Chemotherapy Radiation therapy Post BMT (Bone Marrow Transplant) sufficiently advanced disease to suppress resistance to infection Include patients on methotrexate or cyclophosphamide, etc. (for autoimmune disorders) pt is on immunosuppressive drugs (RA or SLE pts) ExpandList of immunosuppressive drugs    Used to treat an increasing variety of conditions: immune-mediated (RA, UC, Crohn's, lupus, MS, psoriasis, etc); after organ transplant. Only considered immunosuppressive if given systemically (po, im or iv) Corticosteroids (unlike all the others, these only count if > a given daily dose and used for at least 2 weeks prior to admission) Dexamethasone: >0.25 mg/day Hydrocortisone: >40 mg/day Prednisone (methyl-prednisolone): >10 mg/day Prednisolone: >8 mg/day Cancer chemotherapy -- includes any agents, if received within the past 6 months Nonsteroidal immunosuppressives -- includes any of these, if received within the past 1 month Abatacept (Orencia) Azathioprine (Imuran) Adalimumab (Humira) Anakinra (Kineret) Basiliximab (Simulect) Certolizumab (Cimzia) Cyclophosphamide (Cytoxan) Cyclosporine Daclizumab (Zinbryta) Etanercept (Enbrel) Everolimus (Afinitor, Zortress) Golimumag (Simponi) Infliximab (Remicade) Ixekizumab (Taltz) Leflunomide (Arava) Lenalidomide Methotrexate Mycophenolate (CellCept) Natalizumab (Tysabri) Rituximab (Rituxan) Secukinumab (Cosentyx) Sirolimus (Rapasumne) Tacrolimus (Prograf) Tocilizumab (Actemra) Tofacitinib (Xeljanz) Ustekinumab (Stelara) Vedolizumab (Entyvio) Do not include hydroxychloroquine - as per task meeting 2022-04-20 it is an immune modulator, but not very immunosuppressive
2. Met Cancer sufficiently advanced disease to suppress resistance to infection
3. HematMalign e.g. Lymphoma or Leukemia sufficiently advanced disease to suppress resistance to infection
4. AIDS
5. CRF-severe	Receiving Chronic out-patient hemo- or peritoneal dialysis prior to hospital admission.
6. Liver-severe	any of: biopsy proven cirrhosis & previously documented portal hypertension past episodes of GI bleeds related to portal hypertension or varicies hepatic failure or encephalopathy or coma
7. Lung severe	any of the following that results in severe exercise restriction (i.e. unable to climb stairs or perform household duties): COPD-severe Restrictive lung disease-severe Vascular disease-severe or any of the following documented chronic hypoxia or hypercapnia, secondary polycythemia Pulmonary HTN on home O2 (this does not include home bipap or cpap unless the pt also has one of the other listed conditions)Bipap or cpap if only for airway does not imply lung disease. Cpap for obstructive sleep apnea is just constant positive air pressure to keep the airway open during sleep. Not usually used with oxygen. Ventilator dependent Does being on bipap or cpap for obesity be considered restrictive lung disease severe?--MWaschuk 14:31, 2012 May 28 (CDT) There may be an element of restrictive lung disease with obesity as the lung cannot always fully expand related to pressure on the diaphragm of a morbidly obese pt. To be considered true restrictive lung disease however, this must result in impaired ventilatory function. Most obese pts on bipap are only on bipap at night to maximize the airway. To call this severe restrictive lung disease is incorrect. If they are on home O2 during the day as well or have any of the above issues like documented hypoxia or hypercapnea, then this would be considered severe restrictive lung disease. Bipap at night alone is not sufficient evidence of severe restrictive lung disease even if the pt is obese. --LKolesar 07:16, 2012 May 29 (CDT)
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

Temperature (Ap_Temp)

See also Targeted Temperature Management (TTM), Hypothermia, due to exposure/low environmental temperature or Hypothermia, not due to low environmental temperature/exposure

Data Element (edit)
Field Name:	Ap_Temp
CCMDB Label:	Temperature
CCMDB tab:	Apache
Table:	L_Log table
Data type:	number
Length:	single
Program:	CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	57

The patient's Temperature level in °C.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Therapeutic Cooling

Cardiac arrests may having the cooling protocol applied. See Cardiac Arrest Cooling Protocol for more information. If a patient is actively cooled for therapeutic reasons, use the most recent temp just prior to start of cooling.

• If no temp is available before cooling initiated, then use a temp at 4 hours after cooling stopped.

Arrived from OR cold

If a patient is arriving from the OR cold, use the actual worst temperature since this low temp could also be a negative result of "having been open" for a long time.

Apache Physiological Variable
variable name	Temperature
unit	°C
absolute max allowed	42.7
warning max	42.7
high score 4	>=41
high score 3	>=39 and <41
high score 2
high score 1	>=38.5 and <39
score 0	>=36 and <38.5
low score 1	>=34 and <36
low score 2	>=32 and <34
low score 3	>=30 and <32
low score 4	<30
AP phys warnMin	1
AP phys absMin	1

APACHE Score

This value is used to generate the APACHE Score.

Collecting Apache physiological variables

There are some specific rules to follow in choosing which one of several lab results to collect.

See APACHE physiological variable collection for details.

Cross Chcks

Rules described in APACHE_physiological_variable_collection#Exceptionally_high_or_low_values are implemented by Check APACHE physiological variable high low.

Data Integrity Checks

Data Integrity Checks (automatic list)

none found

Related articles

SAPS BP Field (Ap_SapsSysBP)

Legacy Content

This page contains Legacy Content.

• Explanation: no longer collected
• Successor: No successor was entered

Expand

Click Expand to show legacy content.

The legacy field SAPS SysBP used to be used as part of SAPS II.

Data Integrity Rules

The SAPS BP must be >=25 and <=360.

Legacy Data

Medicine - SAP II Systolic BP - stopped collecting Dec 31.06

The field was removed from CCMDB.accdb as of Feb 2009.

The field was removed from CCMDB_data.mdb as of 2017-Dec-11.

AP Sys BP Field (Ap_APSysBP)

Data Element (edit)
Field Name:	Ap_APSysBP
CCMDB Label:	APSysBP
CCMDB tab:	Apache
Table:	L Log table
Data type:	number
Length:	single
Program:	CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	59

Ap_SysBP is the systolic blood pressure.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Different instructions for ICU and Medicine

The details of collection for ICU and medicine are different. For the timing and which value to use, see:

• for ICU: Mean BP
• for medicine: ALERT Scale

Apache Physiological Variable
variable name	Systolic Blood Pressure
unit	mmHG
absolute max allowed	360
warning max	243
high score 4
high score 3
high score 2
high score 1
score 0	as per Mean BP
low score 1
low score 2
low score 3
low score 4
AP phys warnMin	49
AP phys absMin	25

APACHE Score

This value is used to generate the APACHE Score.

Collecting Apache physiological variables

There are some specific rules to follow in choosing which one of several lab results to collect.

See APACHE physiological variable collection for details.

Cross Chcks

Rules described in APACHE_physiological_variable_collection#Exceptionally_high_or_low_values are implemented by Check APACHE physiological variable high low.

Data use

Apache Systolic BP is used for the ALERT Scale score.

Data Integrity Checks

Data Integrity Checks (automatic list)

none found

AP Dias BP Field (Ap_APDiasBP)

Data Element (edit)
Field Name:	Ap_APDiasBP
CCMDB Label:	APDiasBP
CCMDB tab:	Apache
Table:	L Log table
Data type:	number
Length:	single
Program:	CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	60

Ap_DiasBP is the diastolic blood pressure.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

For collection instructions, see Mean BP.

Apache Physiological Variable
variable name	Diastolic blood pressure
unit	mmHG
absolute max allowed	200
warning max	128
high score 4
high score 3
high score 2
high score 1
score 0	as per Mean BP
low score 1
low score 2
low score 3
low score 4
AP phys warnMin	25
AP phys absMin	15

APACHE Score

This value is used to generate the APACHE Score.

Collecting Apache physiological variables

There are some specific rules to follow in choosing which one of several lab results to collect.

See APACHE physiological variable collection for details.

Cross Chcks

Rules described in APACHE_physiological_variable_collection#Exceptionally_high_or_low_values are implemented by Check APACHE physiological variable high low.

For collection instructions, see Mean BP.

Data Integrity Checks

Data Integrity Checks (automatic list)

none found

HR (Ap_HeartRate)

Data Element (edit)
Field Name:	Ap_HeartRate
CCMDB Label:	Heart Rate
CCMDB tab:	Apache
Table:	L_Log table
Data type:	number
Length:	single
Program:	CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	61

The patient's Heart Rate level in beats/min.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Different instructions for ICU and Medicine

The details of collection for ICU and medicine are different. For the timing and which value to use, see:

• for ICU: APACHE physiological variable collection
• for medicine: ALERT Scale timing of assessment

Atrial Fibrillation

When the patient is in atrial fibrillation, do not use the atrial rate use the ventricular rate.

Apache Physiological Variable
variable name	Heart Rate
unit	beats/min
absolute max allowed	205
warning max	250
high score 4	>=180
high score 3	>=140 and <180
high score 2	>=110 and <140
high score 1
score 0	>=70 and <110
low score 1
low score 2	>=55 and <70
low score 3	>=40 and <55
low score 4	<40
AP phys warnMin	10
AP phys absMin	5

APACHE Score

This value is used to generate the APACHE Score.

Collecting Apache physiological variables

There are some specific rules to follow in choosing which one of several lab results to collect.

See APACHE physiological variable collection for details.

Cross Chcks

Rules described in APACHE_physiological_variable_collection#Exceptionally_high_or_low_values are implemented by Check APACHE physiological variable high low.

Data Integrity Checks

Data Integrity Checks (automatic list)

none found

Related articles

RR (Ap_RespRate)

The details of collection for ICU and medicine are different. For the timing and which value to use, see:

• for ICU: APACHE physiological variable collection
• for medicine: ALERT Scale timing of assessment

Data Element (edit)
Field Name:	Ap_RespRate
CCMDB Label:	not stated
CCMDB tab:	Apache
Table:	L_Log table
Data type:	number
Length:	single
Program:	CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	62

The patient's respiratory rate level in breaths/min.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Apache Physiological Variable
variable name	respiratory rate
unit	breaths/min
absolute max allowed	95
warning max	79
high score 4	>=50
high score 3	>=35 and <50
high score 2
high score 1	>=25 and <35
score 0	>=12 and <25
low score 1	>=10 and <12
low score 2	>=6 and <10
low score 3
low score 4	<6
AP phys warnMin	2
AP phys absMin	2

APACHE Score

This value is used to generate the APACHE Score.

Collecting Apache physiological variables

There are some specific rules to follow in choosing which one of several lab results to collect.

See APACHE physiological variable collection for details.

Cross Chcks

Rules described in APACHE_physiological_variable_collection#Exceptionally_high_or_low_values are implemented by Check APACHE physiological variable high low.

Data Integrity Checks

Data Integrity Checks (automatic list)

none found

Related articles

Glasgow Coma Scale

The Glasgow Coma Scale (GCS) ([4], [5]) is a commmon neurological assessment scale used to quantify the level of consciousness in a person following a traumatic brain injury.

Fields:

• Ap_Eye
• Ap_Motor
• Ap_Verbal

FiO2 (Ap_FIO2)

Data Element (edit)
Field Name:	Ap_FIO2
CCMDB Label:	FIO2
CCMDB tab:	Apache
Table:	L Log table
Data type:	number
Length:	single
Program:	CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	67

FIO2 is the fraction of inspired oxygen[6] in the gas mixture breathed by the patient.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

It is an element of the Arterial blood gas (APACHE).

See http://en.wikipedia.org/wiki/FiO2

Collection Instructions

There are special collection instructions for Arterial blood gas (APACHE), refer there for further info. FIO2 collection is impacted by this.

Enter the FiO2 by choosing the type and LPM in the drop-down in CCMDB.accdb.

Once entered, your choice will translate into a number. If you go back to the dropdown later to check what you have entered, the type/LPM may not be what you entered, but they will be something that corresponds to the same percentage FiO2. In other words, you can not go back to this field later to see the type or LPM you entered originally.

Apache Physiological Variable
variable name	fraction of inspired oxygen
unit	percentage
absolute max allowed	100
warning max	100
high score 4
high score 3
high score 2
high score 1
score 0	as per AaDO2
low score 1
low score 2
low score 3
low score 4
AP phys warnMin	20
AP phys absMin	20

APACHE Score

This value is used to generate the APACHE Score.

Collecting Apache physiological variables

There are some specific rules to follow in choosing which one of several lab results to collect.

See APACHE physiological variable collection for details.

Cross Chcks

Rules described in APACHE_physiological_variable_collection#Exceptionally_high_or_low_values are implemented by Check APACHE physiological variable high low.

FiO2 dropdown

See drop-down in CCMDB.accdb.

These FIO2's are estimates only that we use for the collection of arterial blood gas (ABG's) data for APACHE II scoring]] purposes. The actual FiO2 that a patient gets varies due to a number of factors that are not accounted for in these estimates. (breath rate and depth, distance of O2 diffuser from face, resistance to flow etc.)

Here is a link for an article that deals with the relationship between FiO2 and flow rate.

OptiFlow

To get the FiO2 for optiflow

• if available, use the optiflow or "high flow" when initiated by respiratory.
• if that is not available, then as a default use the FIO2 you'd get with that oxygen flow with a regular nasal cannula

Implementation

The field draws its values from the S_FIO2 table.

Data Integrity Checks

Data Integrity Checks (automatic list)

none found

Related articles

PO2 Ap_PO2

Data Element (edit)
Field Name:	Ap_PO2
CCMDB Label:	PO2
CCMDB tab:	Apache
Table:	L_Log table
Data type:	number
Length:	single
Program:	CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	68

PO2 is the partial pressure of oxygen in the patient's arterial blood.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

It is an element of the Arterial blood gas (APACHE).

PO2 and PaO2 are used interchangeably in the context of the Critical Care and Medicine Data.

Collection instructions

There are special collection instructions for Arterial blood gas (APACHE), refer there for further info.

Apache Physiological Variable
variable name	partial pressure of oxygen
unit	mmHG
absolute max allowed	650
warning max	650
high score 4
high score 3
high score 2
high score 1
score 0	>=70
low score 1	>=60 and <70
low score 2
low score 3	>=55 and <60
low score 4	<55
AP phys warnMin	4
AP phys absMin	3

APACHE Score

This value is used to generate the APACHE Score.

Collecting Apache physiological variables

There are some specific rules to follow in choosing which one of several lab results to collect.

See APACHE physiological variable collection for details.

Cross Chcks

Rules described in APACHE_physiological_variable_collection#Exceptionally_high_or_low_values are implemented by Check APACHE physiological variable high low.

Data Integrity Checks

Data Integrity Checks (automatic list)

none found

Related articles

CO2 Ap_CO2

Data Element (edit)
Field Name:	Ap_CO2
CCMDB Label:	CO2
CCMDB tab:	Apache
Table:	L_Log table
Data type:	number
Length:	single
Program:	CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	69

PCO2 (or PaCO2) is the partial pressure of carbon dioxide (CO2) in the patient's arterial blood in mmol/L.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

It is an element of the Arterial blood gas (APACHE).

Collection instructions

There are special collection instructions for Arterial blood gas (APACHE), refer there for further info.

Apache Physiological Variable
variable name	partial pressure of carbon dioxide in arterial blood
unit	mmol/L
absolute max allowed	440
warning max	285
high score 4
high score 3
high score 2
high score 1
score 0	AaDO2
low score 1
low score 2
low score 3
low score 4
AP phys warnMin	2
AP phys absMin	2

APACHE Score

This value is used to generate the APACHE Score.

Collecting Apache physiological variables

There are some specific rules to follow in choosing which one of several lab results to collect.

See APACHE physiological variable collection for details.

Cross Chcks

Rules described in APACHE_physiological_variable_collection#Exceptionally_high_or_low_values are implemented by Check APACHE physiological variable high low.

Data Integrity Checks

Data Integrity Checks (automatic list)

none found

Related articles

pH (Ap_pH)

Data Element (edit)
Field Name:	Ap_pH
CCMDB Label:	ph
CCMDB tab:	Apache
Table:	L_Log table
Data type:	number
Length:	single
Program:	CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	70

The acidity or basicity of the patient's arterial blood.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

It is an element of the Arterial blood gas (APACHE).

Arterial blood gas (APACHE) instructions

There are special collection instructions for Arterial blood gas (APACHE), refer there for further info.

Apache Physiological Variable
variable name	ph
unit
absolute max allowed	7.99
warning max	7.97
high score 4	>=7.7
high score 3	>=7.6 and <7.7
high score 2
high score 1	>=7.5 and <7.6
score 0	>=7.33 and <7.5
low score 1
low score 2	>=7.25 and <7.33
low score 3	>=7.15 and <7.25
low score 4	<7.15
AP phys warnMin	6
AP phys absMin	6

APACHE Score

This value is used to generate the APACHE Score.

Collecting Apache physiological variables

There are some specific rules to follow in choosing which one of several lab results to collect.

See APACHE physiological variable collection for details.

Cross Chcks

Rules described in APACHE_physiological_variable_collection#Exceptionally_high_or_low_values are implemented by Check APACHE physiological variable high low.

History

There have been different collection practices used when selecting the PH value, the original APACHE II user manual (version 1.0) is as above and that is how it should be collected.

Data Integrity Checks

Data Integrity Checks (automatic list)

none found

Related articles

Serum CO2 (Ap_SerCO2)

Data Element (edit)
Field Name:	Ap_SerCO2
CCMDB Label:	not stated
CCMDB tab:	Apache
Table:	L_Log table
Data type:	number
Length:	single
Program:	CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	71

The patient's Serum CO2 level in mmol/L.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Collection instruction

Collect Serum CO2 only if an Arterial blood gas (APACHE) is not available. An ABG is preferred, but if no ABG available during the first 24 hours in ICU then collect serum CO2.

If no ABG and no serum CO2 available assume normal and record serum CO2 as 25.0.

Do not use venous gases.

Apache Physiological Variable
variable name	Serum CO2
unit	mmol/L
absolute max allowed	440
warning max	285
high score 4	≥52
high score 3	>=41 and <52
high score 2
high score 1	>=32 and <41
score 0	>= 22 and <32
low score 1
low score 2	>=18 and <22
low score 3	>=15 and <18
low score 4	<15
AP phys warnMin	2
AP phys absMin	2

APACHE Score

This value is used to generate the APACHE Score.

Collecting Apache physiological variables

There are some specific rules to follow in choosing which one of several lab results to collect.

See APACHE physiological variable collection for details.

Cross Chcks

Rules described in APACHE_physiological_variable_collection#Exceptionally_high_or_low_values are implemented by Check APACHE physiological variable high low.

Background

For APACHE II scoring: the serum CO2 replaces pH and assumes normal oxygenation.

Serum CO2 is really a measure of serum HCO3-, also called bicarbonate. The procedure used to measure HCO3- in the laboratory first converts it to CO2. In the body, 95% of the CO2 is present as HCO3-, so most of what is measured in the laboratory represents HCO3-.

Data Integrity Checks

Data Integrity Checks (automatic list)

none found

Related articles

Na (Ap_Na)

Apache Physiological Variable
variable name	Sodium
unit	mmol/L
absolute max allowed	200
warning max	190
high score 4	>=180
high score 3	>=160 and <180
high score 2	>=155 and <160
high score 1	>=150 and <155
score 0	>=130 and <150
low score 1
low score 2	>=120 and <130
low score 3	>=111 and <120
low score 4	≤111
AP phys warnMin	100
AP phys absMin	70

APACHE Score

This value is used to generate the APACHE Score.

Collecting Apache physiological variables

There are some specific rules to follow in choosing which one of several lab results to collect.

See APACHE physiological variable collection for details.

Cross Chcks

Rules described in APACHE_physiological_variable_collection#Exceptionally_high_or_low_values are implemented by Check APACHE physiological variable high low.

Data Element (edit)
Field Name:	Ap_Na
CCMDB Label:	not stated
CCMDB tab:	Apache
Table:	L_Log table
Data type:	number
Length:	single
Program:	CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	72

The patient's Sodium level in mmol/L.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Data Integrity Checks

Data Integrity Checks (automatic list)

none found

Related articles

K Ap_K

Data Element (edit)
Field Name:	Ap_K
CCMDB Label:	not stated
CCMDB tab:	Apache
Table:	L_Log table
Data type:	number
Length:	single
Program:	CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	73

The patient's Potassium level in mmol/L.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Apache Physiological Variable
variable name	Potassium
unit	mmol/L
absolute max allowed	12
warning max	9.9
high score 4	=>7
high score 3	>=6 and <7
high score 2
high score 1	>=5.5 and <6
score 0	>=3.5 and <5.5
low score 1	>=3 and <3.5
low score 2	>=2.5 and <3
low score 3
low score 4	<2.5
AP phys warnMin	1
AP phys absMin	1

APACHE Score

This value is used to generate the APACHE Score.

Collecting Apache physiological variables

There are some specific rules to follow in choosing which one of several lab results to collect.

See APACHE physiological variable collection for details.

Cross Chcks

Rules described in APACHE_physiological_variable_collection#Exceptionally_high_or_low_values are implemented by Check APACHE physiological variable high low.

Data Integrity Checks

Data Integrity Checks (automatic list)

none found

Related articles

HCT (Ap_Hemat)

Data Element (edit)
Field Name:	Ap_Hemat
CCMDB Label:	HCT
CCMDB tab:	Apache
Table:	L Log table
Data type:	number
Length:	single
Program:	CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	74

The patient's hematocrit level in percentage.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Hematocrit (HCT) is recorded as a percentage, e.g. 0.352 record as 35.2

• hematocrit

Apache Physiological Variable
variable name	hematocrit
unit	percentage
absolute max allowed	3
warning max	3
high score 4	>=60
high score 3
high score 2	>=50 and <60
high score 1	>=46 and <50
score 0	>=30 and <46
low score 1
low score 2	>=20 and <30
low score 3
low score 4	<20
AP phys warnMin	68
AP phys absMin	78

APACHE Score

This value is used to generate the APACHE Score.

Collecting Apache physiological variables

There are some specific rules to follow in choosing which one of several lab results to collect.

See APACHE physiological variable collection for details.

Cross Chcks

Rules described in APACHE_physiological_variable_collection#Exceptionally_high_or_low_values are implemented by Check APACHE physiological variable high low.

Data Integrity Checks

Data Integrity Checks (automatic list)

none found

Related articles

WBC Ap_WBC

Data Element (edit)
Field Name:	Ap_WBC
CCMDB Label:	not stated
CCMDB tab:	Apache
Table:	L_Log table
Data type:	number
Length:	single
Program:	Med and CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	75

The patient's White Blood Count level in x10⁹/L.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Different instructions for ICU and Medicine

The details of collection for ICU and medicine are different. For the timing and which value to use, see:

• for ICU: APACHE physiological variable collection
• for medicine: ALERT Scale timing of assessment

Apache Physiological Variable
variable name	White Blood Count
unit	x109/L
absolute max allowed	517
warning max	301
high score 4	>=40
high score 3
high score 2	>=20 and <40
high score 1	>=15 and <20
score 0	>=3 and <15
low score 1
low score 2	>=1 and <3
low score 3
low score 4	<1
AP phys warnMin	.02
AP phys absMin	0.01

APACHE Score

This value is used to generate the APACHE Score.

Collecting Apache physiological variables

There are some specific rules to follow in choosing which one of several lab results to collect.

See APACHE physiological variable collection for details.

Cross Chcks

Rules described in APACHE_physiological_variable_collection#Exceptionally_high_or_low_values are implemented by Check APACHE physiological variable high low.

Data Integrity Checks

Data Integrity Checks (automatic list)

none found

Related articles

Creatinine (Ap_Creat)

In our context, creatinine can refer to

• Creatinine (APACHE)
• Creatinine (labs)

ARF (APACHE) (Ap_ARF)

Information on this page applies to the APACHE II ARF dropdown only; for the diagnosis code see any one of the several ICD10 codes for types/causes of ARF.

Data Element (edit)
Field Name:	Ap_ARF
CCMDB Label:	ARF
CCMDB tab:	Apache
Table:	L_Log table
Data type:	number
Length:	single
Program:	CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	77

The ARF checkbox is checked/true if patient is in Acute Renal Failure as per the APACHE definition.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

Additional Info

Use the following uniform definition for ARF/AKI everywhere, including for APACHE II.

Terminology related to Acute Kidney Injury

• Nephrologists want us to use the term Acute Kidney Injury (AKI).
  • The reason is that this entity, whatever it's called, includes the full range of levels of kidney injury from minor all the way up to complete renal shutdown needing dialysis.
• Some other terms for it are:
  • Acute Renal Failure
  • Acute Renal Insufficiency (ARI)

KDIGO Guidelines for Acute Kidney Injury (AKI)

• We use the KDIGO criteria for defining Acute Kidney Injury (AKI, Acute Renal Failure and Acute Renal Insufficiency) (starting January 1, 2019)
• The main thing here is identifying that the observed problem with kidney function is acute, rather than chronic - and THIS is the reason that identifying AKI requires trying to find a past/baseline value of serum creatinine
• The KDIGO guidelines delineate several different "levels/degrees" of AKI. You'll note that (at its lowest level) AKI is present even with pretty small rises in serum creatinine. While one MIGHT think that such small rises are inconsequential, indeed they are not. As indicated in the paper "Small Acute Increases in Serum Creatinine Are Associated with Decreased Long-Term Survival in the Critically Ill", even rises in creatinine of 27 mcg/L in ICU patients are associated with higher rates of death. Thus in this new schema we are not overcounting those with significant AKI, but before we probably were undercounting them.
  • After a patient first developed AKI (as indicated by a rise in creatinine) it may continue to rise at a highly variable rate. The importance of this is that we should NOT re-code an AKI-related code each time the creatinine rises by 27 mcg/L if the continuing rise is simply part of the original event.
  • It is possible, however, for a patient to have multiple AKI events. While this would be indicated by creatinine rising again after it stabilized or fell (without dialysis), it requires a medical judgement to determine whether the re-rising is really part of the initial episode or represents a new AKI episode. There is no firm rule about how long creatinine should cease rising to say the first AKI episode is completed.
• These criteria will apply everywhere we need to identify ARF/AKI -- including:
  • Kidney, acute renal failure NOS
  • ARF (APACHE)
  • Kidney, acute tubular necrosis (ATN)
  • Kidney, acute renal failure, postprocedural
• But NOT for Kidney, renal failure/insufficiency/uremia, unspecified as acute or chronic - since as stated this code is for kidney failure or insufficiency when you don't know whether it's acute or chronic.

• In order to reduce the workload for identifying ARF/AKI, we will implement a first stage screening process to try and filter out the majority of people, who will NOT have AKI/ARF.
  • We expect that this screening will misclassify a few people who do have AKI as not having it, but we also expect that most of those who are missed will continue to experience declining renal function and their AKI/ARF will be identified in the following days.

First stage - screening

• Assume at admission that the patient does NOT have AKI/ARF if ALL of the following are true:
  • (1) Creatinine <110 for males and <90 for females AND
  • (2) No mention in chart of acute kidney/renal problems AND
  • (3) No mention in the chart of oliguria
• The source used for these threshold values of serum creatinine are population-based surveys of serum creatinine in people without known kidney problems:
  • Serum creatinine levels in the US population: third National Health and Nutrition Examination Survey (PubMed)
  • The effect of age on serum creatinine levels in an aging population: relevance to vascular surgery. (PubMed)
• If ANY of 1, 2 or 3 are false, then go on to the full evaluation in the Second Stage

Second stage - Full assessment

• Acute Kidney Injury (AKI) is present if ANY ONE OR MORE of the following are true (these are the KDIGO guidelines):
• (a) Urine output < 0.5 mL/kg/hour for 6 hours
  • so, obviously, you can't make this determination until there has been at least 6 hours of observation of urine output
  • also you need a weight -- if there isn't one already measured you have the following options: Wait for one to be done; Ask the nurse to do one; Do your best to estimate the weight, remembering that if the person appears to be of average size, then you could use default values based on average values in the Canadian population, i.e. 85 kg for men and 70 kg for women
• (b) Increase in serum creatinine by 27 micromoles/L or more within 48 hours
  • so, while this may happen quickly and thus this criterion be met before 48 hrs, you cannot make a full determination that it is NOT true until you have at least 2 serum creatinine values separated by at least 48 hours
  • in the case that the creatinine rises by >27, say in the first 12 hours, but then declines back down so that at the end of 48 hrs the net rise is <27, THEN THIS DOES QUALIFY AS AKI
• (c) Increase in serum creatinine to 1.5 times baseline or more within the last 7 days
  • this criterion is important because since many people have some degree of CHRONIC renal insufficiency or failure, a solitary serum creatinine can't tell you if the high value is acute or chronic
  • thus, to evaluate this criterion, seek a serum creatinine value at least 7 days old -- use whatever is the most recent value more than 7 days old that is available, even if it's years old
  • if there ARE NO values >7 days old, then you can use the sex-specific normal value as follows:
    • Men: 100 micromoles/L
    • Women: 85 micromoles/L

Coding Guideline

• For critical care only: The ARF (Acute Renal Failure) dropdown for APACHE defaults to "enter"; you won't be able to send unless you change it to one of the following:
• Choose "no" if the pt
  • does not meet the #KDIGO Guidelines for Acute Kidney Injury (AKI) or
  • has a diagnosis of Chronic kidney disease (end-stage renal/kidney disease, ESRD), Stage 5, GFR LT 15 (with or without dialysis)
    • Special Case- If a patient comes to ICU with a past history of Chronic kidney disease (end-stage renal/kidney disease, ESRD), Stage 5, GFR LT 15 and had a kidney transplant during this admission. As per Allan, unless the transplanted kidney was truly working postop (i.e. didn't need dialysis for at least a week or two) then do not code ARF.
• otherwise choose "yes"

Data Use

ARF is one component used to generate the APACHE II score.

Specifically, double points are assigned for the Creatinine score if the patient has ARF . (see APACHE_II_Background#Weighting_of_scores and APACHE Scoring table#Physiological Variables)

Data Integrity Checks (automatic list)

none found

Historical

• In original APACHE II there were no criteria given for what constitutes Acute Renal Failure. So, from 1988 until 2018 we used a set of simple criteria based only on the admission serum creatinine and absolute urine output. But, when on January 1, 2019 we moved to ICD10 and CCI coding, we decided to use a
• there were criteria for ARF in the APACHE II user manual 1986, from George Washington University, Ver 1.0, that we applied when we started in 1988, they were:
  • creatinine PLUS oliguria. Oliguria was defined as: urine output of less than 135 cc over a consecutive 8 hr period in the first 24 hrs of ICU admission.
  • Copy of this APACHE II User Manual can be found in the article archives library located in HSC JJ387.

Related articles

Administrative fields

Final Check

Legacy only

This field used to do the work of and was replaced by the RecordStatus field

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

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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_* entries

For the following fields see Category:Pharmacy:

• pharm_Vitamin K antagonists
• pharm_Heparin cont inf
• pharm_Direct thrombin inhibitors
• pharm_Heparinoids
• pharm_Factor Xa inhibitors
• pharm_Dopamine cont inf
• pharm_Dobutamine cont inf
• pharm_Norepinephrine cont inf
• pharm_Epinephrine cont inf
• pharm_Phenylephrine cont inf
• pharm_Vasopressin cont inf
• pharm_Milrinone cont inf
• pharm_Paralytics cont inf
• pharm_corticosteroids
• pharm_amphotericin B
• pharm_macrolides
• pharm_1st or 2nd generation cephalosporins
• pharm_4th generation cephalosporins
• pharm_antistaph penicillins
• pharm_aminoglycosides
• pharm_influenza drugs
• pharm_bosentan
• pharm_viagra-type vasodilators
• pharm_special upper GI bleeding agents
• pharm_amiodarones
• pharm_anti-TB drugs
• pharm_statins
• pharm_PPI
• pharm_H2_blockers
• pharm_furosemide
• pharm_heparin_sq
• pharm_LMWH
• pharm_benzodiazepines
• pharm_opioids
• pharm_propofol
• pharm_insulin

pre-2016 Time and Place changes fields

R_Location

R Location

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_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

Expand

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

see Date and Time Format

Data use

Among other things, the times are used to generate statistics about

• LOS
• Multiple Encounter
• Transfer Delay
• Bed occupancy

See also

• Admit date and time
• Discharge date and time
• Transfer Ready date and time
• Minimum data set
• ER Wait

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

Expand

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

see Date and Time Format

Data use

Among other things, the times are used to generate statistics about

• LOS
• Multiple Encounter
• Transfer Delay
• Bed occupancy

See also

• Admit date and time
• Discharge date and time
• Transfer Ready date and time
• Minimum data set
• ER Wait

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

Expand

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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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.

ExpandBefore 2020-10-15

For each patient, enter the first date/time of intent to transfer to lower level in the Level of care hierarchy is documented into the Transfer Ready Date and Time Field; see #status changing back and forth if a patient arrives transfer-ready to a lower level of care than the current ward enter the same date into Transfer Ready DtTm field as in Arrive_DtTm field. if not available because the patient was clearly not transfer ready, leave the date/time empty and enter "not transfer ready" into the "TR info status field" if not available but the patient probably was transfer ready and it just wasn't documented, leave the date/time empty and enter "not available" into the "TR info status field" 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
  • Temporary Stopped Date in all wards: May 1, 2010 to Nov 30, 2011

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

Expand

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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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.

ExpandBefore 2020-10-15

For each patient, enter the first date/time of intent to transfer to lower level in the Level of care hierarchy is documented into the Transfer Ready Date and Time Field; see #status changing back and forth if a patient arrives transfer-ready to a lower level of care than the current ward enter the same date into Transfer Ready DtTm field as in Arrive_DtTm field. if not available because the patient was clearly not transfer ready, leave the date/time empty and enter "not transfer ready" into the "TR info status field" if not available but the patient probably was transfer ready and it just wasn't documented, leave the date/time empty and enter "not available" into the "TR info status field" 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
  • Temporary Stopped Date in all wards: May 1, 2010 to Nov 30, 2011

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 make sure the remaining data transitions are complete: Project Legacy Co-managed Project Legacy HSC CCU Loc and eliminate this field

added: action: 2023-07-13

• Cargo

• Categories

_after removed field from sending removed field from sending removed field from ccmdb_data remove field from CFE data delete wiki page when done

added: action: 2023-07-13

• Cargo

• Categories

 

 

 

 

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

Expand

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).

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

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

• 1. U, u (2014) – 2 records only
  2. NP– 3 records only, 1990-1991, HSC
  3. MRT, MR9 - 189 records, from 1989-1992, at HSC MICU/SICU ---> can’t remember this, Trish. If needed, move to tmp.
  4. LTR – 2 records, 2012, at GRA N5
  5. H4H - 11 records, Apr 2005 at HSC H4 ---> start date of H4H is May2005. Do we want to make the service location= H4H?
  6. H3N– 1 record, 2010 at HSC MICU
  7. GRA – 1 record, 2013 at GRA N3
  8. DAN – 5 records, 1998,2000,2001,2003 at HSC MICU
  9. 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

Postal Code field

Data Element (edit)
Field Name:	PostalCode
CCMDB Label:	Postal Code
CCMDB tab:	Dispo
Table:	L_Log table
Data type:	string
Length:	6
Program:	Med and CC
Created/Raw:	Raw
Start Date:	2012-01-01
End Date:	2300-01-01
Sort Index:	33

The patient's postal code.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

The Postal_Code field can be edited in the Dispo tab. A postal code is collected for all patients admitted to a hospital within the WRHA. The postal code collected is from the address that a person permanently resides in any Province in Canada.

Collection Instruction

Enter the Postal code

• no space
• upper case letters
• example only: X0X0X0

When the postal code is not available (e.g. John or Jane Doe patient or chart doesn't have postal code) enter "N/A" or click the "N/A" button to enter it for you.

Don't trust Postal Codes from Cognos

Don't trust the postal codes that come from Cognos2, we know that the codes in the data dump can be wrong anc change from day to day, and have been unable get a fix from Decision Support Services. Confirm Postal Codes in EPR and enter the code from EPR if different from Cognos.

Special Cases

Homeless with proxy address

If you have a homeless person admitted who lists their address as Siloam Mission or the Salvation Army/Booth's Place, do NOT use that place's postal code as provided, use N/A for postal code

Code "couch surfers" as "N/A".

Institutionalized patients

For institutionalized patients (e.g. Prison / Jail / Correctional Institution inmates, care homes), use the institution's postal code.

Out-of-Country patients

Our cross checks would flag the format of out-of-country postal codes, so enter "N/A" for these.

International Students

If they have an address in the Province, enter it, otherwise treat them as #Out-of-Country patients.

Relationship between Province, PHIN and Postal code

When collecting Postal Code, PHIN number and Province, think about the relationship of this information when you are collecting it.

• if patient has a MB PHIN number, then Province code should be MB and the postal code should be for MB (MB postal codes start with an "R").
• if Province code is not MB then the postal code should not be a MB postal code. Enter "not applicable" or the out of province postal code if available, and also, there should not be a PHIN number.

Data Use

Postal Codes are used group patients geographically for purposes such as:

• distribution of patients by MB RHAs outside of Winnipeg
• linking to Stats Canada for socioeconomic stratification of population by geographic area
• cross-checking our data's Province field for out-of-province patients

Data Integrity Checks (automatic list)

none found

Postal Code Master table

Start/end Dates

Start Date: new admissions on and after January 1, 2012 End Date: None / Permanent Collection

Wikipedia Postal codes listings across Canada

Wikipedia, Postal codes in Canada

Related Articles

Legacy

Data started out being collected in the tmp field until June 1, 2016. The Postal Code from tmp populated the PostalCode field of Centralized_data on Jun 22, 2016.