Revision as of 16:38, 15 August 2016

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.

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.

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.

Minimal Data Set

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

L_PHI vs L_Log

This field is stored in the L_PHI table in CFE but in the L_Log table in CCMDB.accdb. See L_PHI table for details why.

Data Integrity Checks (automatic list)

none found

Legacy info

Legacy Content

This page contains Legacy Content.

Explanation: we used to change names around for consistency but stopped doing this.
Successor: use rules above

Click Expand to show legacy content.

We used to standardize names to make it easier to keep them consistent over time. We decided to stop using our own standards to facilitate comparison with Manitoba Health and similar data. 13:34, 2015 April 27 (CDT) It used to be:

if a name changed we retained the original one and changed new encounters of the patient to the old one.
for first names we decided not to use hyphens if there was more than one, and to preferably only have one first name used
last names that use two names were hyphenated

Data Processing at main office

Name changes over time

When people change names, eg marriage, the Data Processor changes all old records to be consistent with the current one.

If an inconsistency is found between old and current records,

edit only if there is something incorrect, e.g. a typo
use the value in the EPR for the correction
we change the old entries to be consistent with the most current entry

Information about other names for the patient may be available in Alias ID collection.

Minimal Data Set

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

L_PHI vs L_Log

This field is stored in the L_PHI table in CFE but in the L_Log table in CCMDB.accdb. See L_PHI table for details why.

Data Integrity Checks (automatic list)

none found

Legacy info

Legacy Content

This page contains Legacy Content.

Explanation: we used to change names around for consistency but stopped doing this.
Successor: use rules above

Click Expand to show legacy content.

We used to standardize names to make it easier to keep them consistent over time. We decided to stop using our own standards to make it facilitate comparison with Manitoba Health and similar data. 13:34, 2015 April 27 (CDT) It used to be:

if a name changed we retained the original one and changed new encounters of the patient to the old one.
for first names we decided not to use hyphens if there was more than one, and to preferrably only have one first name used
last names that use two names were hyphenated

MB Health PHINs only

Manitoba Health PHIN numbers only.

If patient permanently resides outside of the province of Manitoba the Province field should not be MB and the PHIN field should be left blank.

Please make every effort to obtain this information and call medical records to help.

Possibility of adding other Province's PHINs

old discussion, result: not at this time
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

L_PHI vs L_Log

This field is stored in the L_PHI table in CFE but in the L_Log table in CCMDB.accdb. See L_PHI table for details why.

Cross checks

Data Integrity Checks
Summary:	The minimum age allowed is 10, the maximum age allowed is 120.
Related:	Date of Birth
Firmness:	hard check
Timing:	complete
App:	CCMDB.accdb
Coding:	function Validate_DOB
Uses L Problem table:	not relevant for this app
Status:	implemented
Implementation Date:	2008-01-01
Backlogged:	true

CCMDB.accdb cross checks triggering for correct values

If the actual correct data leads to a cross-check error CCMDB.accdb will not allow you to send. In that case, enter a value that is acceptable and then email the Data Processor using the "generate email" button.

Data Integrity Checks (automatic list)

none found

Collection instructions

Leading Zeros

If your chart number system uses leading zeros, don't enter the leading zeros, start with the first non-zero number.

Dashes near the end of the number

EPR sometimes lists something like MRN 123456-1; in that case, we code 1234561, i.e. leave out the dash, but code the trailing number.

Unclear or changing chart numbers

See

Minimal Data Set

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

Data Processing

The Centralized_data_front_end.accdb has queries that make sure that the chart number for each Hospital site is the same for the same patient and make sure the chart number has valid format.

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

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

We tried to standardize field into a kind of form, but collection practice is too non-standard to come up with a format that worked.
Just being curious if the notes field is a free space for optional additional info....what specific problems did this cause? 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)

Legacy Content

This page contains Legacy Content.

Explanation: stopped collection in Medicine
Successor: various tmp and dx codes relating to palliative care and End-of-life related data

Click Expand to show legacy content.

Legacy Content

This page contains Legacy Content.

Explanation: This is a legacy data field, its DataElementEndDate is in the past.
Successor: No successor was entered

Click Expand to show legacy content.

Data Element (edit)
Field Name:	R_dc_treat
CCMDB Label:	not stated
CCMDB tab:	not stated
Table:	L_Log table
Data type:	string
Length:	50
Program:	CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2022-05-10
Sort Index:	12

"DC" for critical care patients if life-support treatment is terminated, blank for all others.

This field was also collected in Medicine until 2013-07-04. Collection stopped because the distinction is not clear enough for coding on a medicine ward.

Defined as terminal withdrawal with expectation of death of:

invasive mechanical ventilation (ET tube or trach)
vasopressors or inotropes
ECMO, VV, ECMO, VA
VAD (Ventricular assistive device)

Log

2022-05-10 removed from collection screen

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.

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

Legacy Content

This page contains Legacy Content.

Explanation: This is a legacy data field, its DataElementEndDate is in the past.
Successor: No successor was entered

Click Expand to show legacy content.

Data Element (edit)
Field Name:	R_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.

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:

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.

}}

FinalCheck

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.

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

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

Example:

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" for these

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, including those that are in a Chronic Health Facility eg. Riverview, Deer Lodge
- 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

	Hey T/Julie, I recently admitted a pt from day sx and did as the wiki instructions on Previous Location and put HSC_ward, which according to the article is not an inpt location, so put NA for pre admit pt institution, however I got an error saying previous loc and pre-admit must be the same if coming from an inpt location. Should we change the instruction and use HSC ambulatory care instead of HSC ward?, or do we need to rethink this? Lisa Kaita 13:04, 2024 October 16 (CDT) Yes I agree, Ambulatory care seems to be the closest scenario for day-surgery locations. --JMojica 13:38, 2024 October 16 (CDT)

- Any ward, from Deer Lodge or Riverview, including the rehab wards, Riverview LTV or Riverview palliative care unit

	We have Template:PCH Riverview Deer Lodge, but we have also discussed lately that we might want to become more nuanced about those locations. We really need to keep the info consistent, and I think the way to do it would be to put it into that template. Right now, some related info is also at Chronic Health Facility, Pre acute living situation field, Dispo field, Awaiting/delayed transfer to lower acuity site in Winnipeg other than home or LTC/PCH, Awaiting/delayed transfer to long-term care/PCH inside or outside of Winnipeg, Previous Location field.

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.

Example:

 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.

query of what is currently available

SQL

SELECT s_dispo.location_name, s_dispo.Site, s_dispo.active, s_dispo.inpatient, s_dispo.previous_location, s_dispo.s_location, s_dispo.dispo
FROM s_dispo
WHERE (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.inpatient)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.previous_location)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.s_location)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.dispo)=True));

Query of what is currently used

query z_s_dispo_inactivatable

Data Use / 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.

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 Chronic Health Facility see Pre-admit Inpatient Institution field for 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>_Ward, e.g. HSC Ward (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, 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.

query of what is currently available

SQL

SELECT s_dispo.location_name, s_dispo.Site, s_dispo.active, s_dispo.inpatient, s_dispo.previous_location, s_dispo.s_location, s_dispo.dispo
FROM s_dispo
WHERE (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.inpatient)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.previous_location)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.s_location)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.dispo)=True));

Query of what is currently used

query z_s_dispo_inactivatable

Data Use

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

Legacy Content

This page contains Legacy Content.

Explanation: This is a legacy data field, its DataElementEndDate is in the past.
Successor: No successor was entered

Click Expand to show legacy content.

Data Element (edit)
Field Name:	Previous_Service
CCMDB Label:	Previous Service
CCMDB tab:	Dispo
Table:	L_Log table
Data type:	number
Length:	long integer
Program:	Med and CC
Created/Raw:	Raw
Start Date:	2016-07-01
End Date:	2022-09-07
Sort Index:	38

The most recent "originating service" which sends the patients to their current service location.

Collection Instruction

For each patient enter the option that most closely matches
- For medicine ward-to-ward moves, code "medicine" as previous service
- For ICU-to-ICU moves, code "Critical Care" if no other specific service is documented
- For pt from ER, code "Emergency Medicine" unless a different service had accepted them and is handing them off to Medicine
- For pt direct from ambulatory not via ER, code "not applicable" if no other specific service is documented
Patients admitted after having a problem during an outpatient procedure are more complicated:
- Such procedures include outpatient: GI endoscopy, bronchoscopy, cardiac cath, invasive radiology, procedures done at surgicentres, etc.
- If the patient goes DIRECTLY from the outpatient procedure area to a Medicine ward or an ICU, then code the type of physician who was doing the procedure:
  - if, for example, it was a GI endoscopy, then the previous service was "GI", but as GI is not specifically listed in the dropdown list of services, then list it as "other"
- If before being admitted to hospital the patient was sent from the procedure area to the ED:
  - if the patient was actually an ED patient (under the care of the ED docs) then code "Emergency Medicine"
  - if, for example, it was a GI endoscopy and the patient was not actually under ED care, but instead was directly admitted to the ED on the Medicine ward service, then the previous service was "Medicine"
If the service is not listed, code "other (known but not on list)"
- in these cases we don't care about the details; if we see too many others we may add additional options in future (as of January 2022 we checked and these account for <1% of all previous services)

From HD / From hemodialysis

Came to dialysis from being an outpatient:
- Previous Location =dialysis
- Previous Service=Nephrology
- Pre-admit Inpatient Institution=n.a.
Came to dialysis from ED:
- Previous Location=dialysis
- Previous Service=ED
- Pre-admit Inpatient Institution=n.a.
Came to dialysis from a prior, different, inpatient location:
- Previous Location=dialysis
- Previous Service=service of that prior inpatient location
- Pre-admit Inpatient Institution=that prior inpatient location

From Cardiac Cath Lab

A patient goes to emergency, then is sent to the cardiac cath lab for an angiogram. Julie would like the sending service to be Emergency Medicine in these cases (not cardiology). Discussed at the task group meeting on July 20, 2017.
Most patients come to CCU or ICU via the heart cath as a code stemi, in which case the previous service is cardiology because they bypass ER and go direct to the heart cath lab.

The previous service is who was looking after the pt before the heart cath in some situations. For example, if ECMO is done in the heart cath lab : If the pt was on a ward or unit prior to the procedure, the service is whatever ward or unit it was that sent the pt there. If ER sends a pt for a VV ECMO, the ER is the sending service, unless ICU takes over the pt prior to the ECMO. (They would need to consult cardiac surgery for the ecmo procedure but it would be the ICU that takes over the care ultimately).

This was discussed at the task group meeting on June 21, 2017.

from OR

If a patient comes from an OR/RR, code the responsible surgical service as previous service.

Nursing Home Wards (HSC/GRA)

We treat patients that went through the HSC/GRA Nursing Home as having been discharged. So, admission from there should be as if admitted from home, so put "not applicable" into the Previous Service field. This does not affect the Visit Admit DtTm field definition - remember, that is defined by EPR entry.

Admit from home

For an admission directly from home bypassing the ER enter Previous Service = 'Not applicable'.

from EMIP via ER

The case of VIC ER to STB EMIP to VIC ER to VIC Ward is a bit tricky because STB EMIP signify being an inpatient under Medicine service before going to VIC ER. WIKI defines Previous Service as the "originating service" for those patient's who where already in a prior inpatient location. It would be easier to define the previous service if this is a case of direct transfer to VIC Medicine service and parked only in VIC ER. This is a good question - which to use, Emergency Medicine or Medicine? Since it is known that there is prior inpatient service, I am more on the second one 'Medicine'. This can be a similar case when the previous location is Operating or Recovery and the responsible surgical service is coded as previous service. If coming from home to another ER to own ER to own Ward, then previous service is clearly Emergency medicine.

admission from a unit partly collected by us

see Previous_Location_field#from_a_unit_that_is_partly_collected_by_us.2C_and_partly_not.

admission from a nursing station

For a direct admission to a collection unit from nursing stations, put "other (known, but not on list)".
If from a nursing station, patient dropped by ER , put "Emergency Medicine".

Direct admit

For a direct admit via the ER, the Previous Service will be the primary service looking after the patient, prior to admission at your facility.

Example:

testcontent

Urgent Care

For patients directly admitted from urgent care, code previous service as "Emergency Medicine".

Clinical Assessment Units

Specific instructions apply for coding previous service for the specific CAUs. See

Data Use

Sending service to ICU will be reported to the Critical Care Director whose interest is to determine the sending services for patients who where already in a prior inpatient location before coming to ICU (refer to minutes of Task Meeting dated 13 April 2015 and 11June 2015). The data to be reported will be filtered to include only those in-patients prior to ICU.

Integrity checks

Data Integrity Checks (automatic list)

none found

Implementation

The field is populated with options from the s_previous_service table.

Legacy

For medicine this concept is related to ER Wait.

For critical care this concept is related to Service Sending to ICU - refer to Task Meeting minutes dated June 11, 2015.

see updated minutes dated August 24, 2017.

Legacy Content

This page contains Legacy Content.

Explanation: This is a legacy data field, its DataElementEndDate is in the past.
Successor: No successor was entered

Click Expand to show legacy content.

Data Element (edit)
Field Name:	off_ward
CCMDB Label:	Off Ward
CCMDB tab:	Dispo
Table:	L_Log table
Data type:	number
Length:	long integer
Program:	Med and CC
Created/Raw:	Raw
Start Date:	2016-07-01
End Date:	2020-01-29
Sort Index:	39

Checked/true if the patient who meets the Definition of a Medicine Laptop Admission or Definition of a Critical Care Laptop Admission spent any time in a bed that is not at their actual collection location between "Arrive DtTm" and Dispo DtTm. The patient must be covered by the attending of the service of the home unit that is credited with the "off ward" designation.

Legacy

Allan suggested this OFFWARD field for some reasons related to outcome. you are right the tmp Boarding will indicate patients staying in offward locations. Offward started July 2016. CC started tmp Boarding July 2018 while Med on Sept2019. since offward start date was before any of these BL dates, we need to keep those data in prior dates. --JMojica 16:18, 2022 August 12 (CDT)

- Here is a query with counts by send time:

TRANSFORM Count(L_Log.D_ID) AS CountOfD_ID
SELECT Format([SentDtTm],"yy-mm") AS send_month
FROM L_Log
GROUP BY Format([SentDtTm],"yy-mm")
ORDER BY Format([SentDtTm],"yy-mm"), L_Log.off_ward
PIVOT L_Log.off_ward;

It actually looks like we used this from 2014 onward, even if the data definition on this page says from 2016.

There is a weird spike in Jan 2018, other than that numbers in a similar range between 16-07 and 20-03. So from when until when would we consider this data reliable? We should likely clean up values outside that range so no one thinks records are reliably tagged outside that range. Ttenbergen 11:23, 2022 August 23 (CDT)

- For the pre2016 profiles, the OFFWARD field is pre-populated by the old VAR3, VAR4,VAR5 (see below) and therefore they are reliable. Actually Var3 to Var5 specify the units they are overflowing (similar with tmp Boarding but only with location and no start dates). If I remember right, when Allan introduced OFFWARD, he was thinking of the specific location but the idea was not received well and so decided just to be binary code YES/NO. For research project needing historical data, I think binary data would still be useful. we can either keep it AS IS or be saved as tmp project. --JMojica 15:38, 2022 August 29 (CDT)

Old instructions

This includes patients who spend part or all of their admission located on an off service ward, but not #EMIPs.

How to enter patient into CCMDB

Collection Instructions - current ward

If the patient meets the definition at the top, check the "off ward" checkbox located underneath the Service/Location field.

Enter the laptop's regular collection location into the Service/Location field, not the off-ward location.

Collection Instructions - next ward (if applicable)

The Pre-admit Inpatient Institution field and Previous Location field of the next encounter would use the Service/Location field of the previous collection location where available, not the off-ward location.

Collection Instructions - previous ward (if applicable)

The Dispo field of the previous encounter would use the Service/Location field of the next collection location where available, not the off-ward location.

Not intended for off-ward tests

see Bed holds

EMIP

EMIPs are in their collection location, e.g. GRA_EMIP, so they are not off ward. Don't check the field.

Parked in ER

Parked in ER is before Arrive DtTm, so they are not "off ward". Don't check the field.

find patients as per off ward field article
Write down a list of these patients with their chart numbers on a paper.
Place this list on the bulletin board in the medicine office so that both medicine data collectors are aware that there are medicine service patients on off-service wards in the hospital.

Entering off ward patients

If these patients ultimately get transferred to one of the medicine wards, then the data collector that does that ward will enter those patients on their laptop, reflecting their entire stay from the admission from ER. In the dispo tab the Off ward field must be ticked off as they were off ward for part of their stay.
If these patients get discharged from the off service ward to home or out of hospital location, then these are considered Off ward field that must be entered on one of the medicine laptops, because their entire stay was on an off service ward.(There may be individual hospital differences on which laptop is used for these entries).
This patient list can be posted on the bulletin board of the medicine office. If they are admitted to one of the medicine wards, then that data collector will cross that person off the list. Once a week check if the pt is still in the hospital, if they have left and were never admitted to one of the medicine wards, then a designated data collector will enter them on her laptop. --LKolesar 12:54, 2017 March 2 (CST)

Patients who are on a off wards for part of their stay only

When a pt comes to one of the medicine wards from an off-service ward, the data collector must go to the original presentation of the pt to see if this pt was accepted to medicine on the off-service ward prior to their arrival on their own ward. If you see that the pt was looked after by internal medicine prior to their arrival from the other ward, make sure you start your profile on the original date that medicine accepted them (usually in ER).
On occasion, medicine patients are transferred to off service wards, but are still admitted under the internal medicine service. ie. patient transferred from a medical ward to a surgical ward but still are admitted under internal medicine service. The attending may be different than the admitting service but it is still an internal medicine attending. Please continue to follow these patients (new profile is not required) until they are discharged or transferred to an off service ward under family medicine or any other service other than internal med. Please note the location in the RECORD box to indicate where the pt is currently located. --LKolesar 13:05, 2017 March 2 (CST)

How to determine when a patient is no longer under an internal medicine service

In the EPR the patient list will show the "provider" which should identify which service the attending physicians is from. However, because this is not always consistently kept up to date when services change, the following checks can help to determine if a patient remains under internal medicine or switches to another service.

1. In EPR,Check the orders under transfers/care directives, to see if there has been an order to switch from internal medicine to another service. Use the time transferred to the other ward as the discharge time or use the time in the order when the other service took over care if the pt remains on the off-service ward. (orders are currently only available to view at STB).

2. In EPR, go to the patient info tab, select care providers from the left hand column, a list should come up with providers and their discipline with a date. If you see that the most recent attending is no longer an internal medicine physician then there has likely been a change of service. You may be able to confirm this by checking under the documents tab, sort by discipline, and then check the medicine notes that correspond to the date found in the care providers list. The progress notes from different services will be identified as such in the notes section. If you determine that they are in fact now under a new service (with no corresponding order), use the date and time of the attending switch in the care provider list as your discharge date and time.

Data Use

Relevant to Bed occupancy and some patient risks.

As of 17:13, 2017 November 9 (CST) we don't use it in reports but it is used to explain such things as over-census situations.

Cross Checks

Legacy but still implemented: ACCU_borrow#If_ACCU_entry_then_off-ward_should_be_checked

Legacy

initial mis-connection

From 2016-07-01 to 2016-08-?? the control for this field had been incorrectly connected to the pharm_complete field. Since medicine doesn't use that field we could reclaim data for medicine from there. CC uses the field so could not reclaim data for them. Data for CC will be reported starting 2016-09-01.

pre-2016 fields for similar content

We used to collect related information in multiple places. Once we are comfortable with the new dispo fields we want to stop collection of the old fields. The fields are:

Old data would be transferred to new fields where the translation is not ambiguous. We can keep a snapshot of Centralized with the data pre-translation in case we ever want to go back to it.

Collection Instruction

see Change_from_Service_Location_to_Service,_Boarding_Loc_and_Transfer_Ready_DtTm_tmp_entry#The_change for how to code during the transition to the new scheme

When entering from CSS or "Add Patient with Serial Helper" button, or in Patient Viewer Tab Dispo, under Auto Data Dictionary select the generic site/program entry:

GRA_Med, HSC_Med, STB_Med for medicine
GRA_CC, HSC_MICU, HSC_SICU, HSC_IICU, HSC_IICU, STB_MICU, STB_ACCU, STB_ICCS for critical care (see STB_CC#Decision to not combine collection of STB CC on one laptop)

Bed Borrow

When a service borrows a bed in another unit/ward but still follows them the Service Location should be the location where the patient would have been had there been enough beds/space for them. example. ACCU patient, followed by ACCU service but physically located in CICU, service location=ACCU. The Boarding Loc in the Tmp will identify that they are "borrowing" a bed in CICU. If this patient is then transferred to their normal unit, ACCU, add this location as a Boarding Loc in the tmp, this would be a single profile. If the patient was NOT followed by ACCU but by CICU, see ICUotherService for instructions on how to collect.
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

The concepts that used to be stored in this are essentially now stored as:

Service tmp entry for the service
Boarding Loc for the physical location

"Can we remove the items that are no longer Service/Locations, Previous Locations, Pre-admit Inpatient Institutions or dispo locations from the dropdowns?"

We can and will remove them, but that can only happen once no more laptops use them. We will need to keep track of this and then remove them when ready. If I removed them now, then any box that currently has them enter would misbehave.

query of what is currently available

SQL

SELECT s_dispo.location_name, s_dispo.Site, s_dispo.active, s_dispo.inpatient, s_dispo.previous_location, s_dispo.s_location, s_dispo.dispo
FROM s_dispo
WHERE (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.inpatient)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.previous_location)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.s_location)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.dispo)=True));

Query of what is currently used

query z_s_dispo_inactivatable

Minimal Data Set

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

Adding a new service/location entry

add to s_dispo table
consider all checks in Category:Service/Location check to see if they need to be modified to work right for the new location.

Data Use / Purpose

See Site and Location table for possible entries.

Used to determine the location or services the patient went during a hospital stay.

Used to categorize/stratify the distribution of patients across hospitals and wards/units when reporting summary statistics.

Integrity checks

Data Integrity Checks (automatic list)

none found

Implementation

The field is populated with options from the s_dispo table.

Retiring an available Service/Location field entry

Sometimes a ward may close or change names, or we may stop collecting somewhere. In that case, an entry for Service/Location needs to be made unavailable by editing the s_locations_allowed_collection table.

If a location is no longer available on a laptop records with that location can't be set to "complete". So, if we transition from one location to a new one, we need to get collectors to change the locations for all existing records to the new one, and change the number to using the new number series. Another option might be to keep old location available, at risk of manual mistakes and continuing to use the old location, and of location-number Pool mix-ups. Either way, needs to be planned.

Legacy

This field is subject to Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry. However, we still need it because of how we decided to collect patients at HSC and STB CC.

This field is part of the 2016 Time and Place changes and corresponds to to the old Location field, resp L_Log.R_Location.

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.

Prison / Jail / Correctional Institution

If a patient is discharged to prison, jail or a correctional institution, code this as a Institution NOS.

Pre acute living situation field should be coded as: Jail/correctional institution.

Chronic Health Facility

use <site>_ward e.g. Riverview stroke rehab, Oaks ward
If the patient is discharged to the PCH portion of Deer Lodge or Riverview use Winnipeg PCH

	you removed {{PCH Riverview Deer Lodge}}; that template is also linked from Chronic Health Facility. The two will now show inconsistent content. When content is driven by a template like that it is always so it stays consistent across the wiki. Pls have a look at Template:PCH Riverview Deer Lodge and Chronic Health Facility to consider if (a) the two should really be inconsistent now or (b) we should re-instate the template and fix its content. Catch me on teams if you want more information or help with this. Ttenbergen 14:05, 2024 October 16 (CDT) Lets set up a time to discuss this, I don't think I knew they were templates, I thought I was editing an article Lisa Kaita 13:16, 2024 October 31 (CDT) we have pts discharged to AIA (alternative integrated accommodation) located at 698portage ave, opened April 15, 2024, should we add this as an option to the dispo dropdown? Lisa Kaita 08:39, 2024 December 17 (CST)

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

Deceased patients

See

"Can we remove the items that are no longer Service/Locations, Previous Locations, Pre-admit Inpatient Institutions or dispo locations from the dropdowns?"

We can and will remove them, but that can only happen once no more laptops use them. We will need to keep track of this and then remove them when ready. If I removed them now, then any box that currently has them enter would misbehave.

query of what is currently available

SQL

SELECT s_dispo.location_name, s_dispo.Site, s_dispo.active, s_dispo.inpatient, s_dispo.previous_location, s_dispo.s_location, s_dispo.dispo
FROM s_dispo
WHERE (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.inpatient)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.previous_location)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.s_location)=True)) OR (((s_dispo.Site)>"") AND ((s_dispo.active)=True) AND ((s_dispo.dispo)=True));

Query of what is currently used

query z_s_dispo_inactivatable

Data Use

Unit Mortality
Intra or Inter Transfer Rate
Discharges out of hospital
Organ donor rate
AMA Rate
Linking admissions

Cross checks

Data Integrity Checks (automatic list)

none found

Implementation

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

Legacy

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

It a combination of our previous

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

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.

The field it is automatically populated from Cognos EPR Report. For reference only, it contains the first entry in the visit location history in EPR for current visit at a hospital site.

Purpose

The field is used as an identifier of a hospital encounter at your site. The info is used to:

link together ICU and Ward admissions during the same hospital visit
uniquely identify patient visits to Manitoba Health when we exchange data with them

We obtain this item from the ADT system (via Cognos) and it does not always accurately identify the timing of hospital admission. THUS, we are only using it as an identifier to link.

The Statistician must not give this field to anyone requesting data from the database to avoid being misused.

Collection Instruction

The field is pre-populated by Cognos2 Service Starter and should not be changed or altered

If a patient needs to be entered other than through Cognos
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

Legacy Content

This page contains Legacy Content.

Explanation: This is a legacy data field, its DataElementEndDate is in the past.
Successor: No successor was entered

Click Expand to show legacy content.

Data Element (edit)
Field Name:	Accept DtTm
CCMDB Label:	Accept DtTm
CCMDB tab:	not stated
Table:	L_Log table
Data type:	date
Length:	not stated
Program:	Med and CC
Created/Raw:	Raw
Start Date:	2016-07-01
End Date:	2022-04-22
Sort Index:	43

First Service tmp entry DtTm for pts who came from the ER department only

Collection Instruction

For each patient, enter First Service tmp entry DtTm for pts who came from the same hospital's the ER department only (i.e. who had an initial Boarding Loc of ER). Follow the instructions at Service tmp entry.

This means the Auto Data Dictionary should be equal to the first Service tmp entry DtTm if it is entered at all.

Planned elimination of this field

see Change to replace Accept DtTm with first Service tmp entry, and Arrive DtTm with first Boarding Loc

Data Use

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

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

Legacy Content

This page contains Legacy Content.

Explanation: This is a legacy data field, its DataElementEndDate is in the past.
Successor: No successor was entered

Click Expand to show legacy content.

Data Element (edit)
Field Name:	Arrive_DtTm
CCMDB Label:	Arrive DtTm
CCMDB tab:	Dispo
Table:	N/A
Data type:	date
Length:	not stated
Program:	Med and CC
Created/Raw:	Raw
Start Date:	2016-07-01
End Date:	2022-04-22
Sort Index:	45

First non-ER Boarding location date and time, or start of ( Service Location) for legacy records.

Collection Instruction

For each patient enter the First non-ER Boarding Loc date and time as Auto Data Dictionary. Follow the instructions at Boarding Loc.

This means the Auto Data Dictionary should be equal to the first Boarding Loc DtTm.

Planned elimination of this field

see Change to replace Accept DtTm with first Service tmp entry, and Arrive DtTm with first Boarding Loc

Data Integrity Checks (automatic list)

none found

Legacy

Click to see legacy info
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.

Collection Instruction

For each discharged patient enter the date and time when the patient left the unit as found in Cognos2 Ender.

Discharge at midnight

If the patient is discharged at 24:00/midnight, use 23:59 hours as the discharge time.

Deceased patients

See Deceased patients#General instructions for deceased patients

Visits to temporary locations

AMA

Data use

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

Data Integrity Checks (automatic list)

none found

Legacy

This field is part of the 2016 Time and Place changes. Similar to the old Discharge date and time resp the fields L_Log.R_DisDate and L_Log.R_DisTime.

Legacy Content

This page contains Legacy Content.

Explanation: This is a legacy data field, its DataElementEndDate is in the past.
Successor: No successor was entered

Click Expand to show legacy content.

Data Element (edit)
Field Name:	Transfer_Ready_DtTm
CCMDB Label:	Transfer Ready DtTm
CCMDB tab:	Dispo
Table:	L_Log table
Data type:	date
Length:	not stated
Program:	Med and CC
Created/Raw:	Raw
Start Date:	1999-06-01
End Date:	2020-10-15
Sort Index:	47

Date and time the intent to discharge a patient to a lower level in the Level of care hierarchy was documented.

See Transfer Ready DtTm tmp entry

The data in this field will be retained in Centralized data.mdb's L_Log table since it doesn't follow the same pattern as the new entry. The field no longer exists in CCMDB data.mdb.

See Transfer Ready DtTm tmp entry for what this field is about, or see the history of this page for how it has been used at different times before moving to the new field.

Collection Instruction

Entering a Transfer Ready DtTm

Follow the instructions in Transfer Ready DtTm tmp entry.

Before 2020-10-15
For each patient, 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

Legacy Content

This page contains Legacy Content.

Explanation: This is a legacy data field, its DataElementEndDate is in the past.
Successor: No successor was entered

Click Expand to show legacy content.

Data Element (edit)
Field Name:	TR_info_status
CCMDB Label:	(label in CCMDB)
CCMDB tab:	Dispo
Table:	L_Log table
Data type:	string
Length:	19
Program:	Med and CC
Created/Raw:	Raw
Start Date:	2016-05-05
End Date:	2020-10-15
Sort Index:	48

Cross-check field that will contain data if Transfer_Ready_DtTm field is empty

This field is used in conjunction with the Transfer_Ready_DtTm field, see there for info on how it is used.

Cross Checks

Data Integrity Checks (automatic list)

none found

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.

Data Use

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.

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.

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.

Legacy Content

This page contains Legacy Content.

Explanation: This is a legacy data field, its DataElementEndDate is in the past.
Successor: No successor was entered

Click Expand to show legacy content.

Data Element (edit)
Field Name:	Ap_Chronic
CCMDB Label:	Chronic
CCMDB tab:	Apache
Table:	L_Log table
Data type:	string
Length:	30
Program:	CC
Created/Raw:	Raw
Start Date:
End Date:	2022-02-17
Sort Index:	56

Specific chronic pre-existing conditions used for APACHE score.

This value is used in conjunction with Admit Type for APACHE II to calculate the Chronic_Health_Score, one of the components of the .

To be considered to be a chronic disease, the chronic condition must have been documented as present before current hospitalization.

Chronic Health Table

Dropdown in CCMDB.accdb

Orignial APACHE II CH list with definitions

1. Immunocompromized (this category includes the following: Metastatic Cancer, Hematological Malignancy-Lymphoma, Leukemia and also AIDS)

(this is applicable to items 1-5. Receiving therapy that suppresses resistance to infection such as: at least one of the following:

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

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

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

Legacy Content

This page contains Legacy Content.

Explanation: no longer collected
Successor: No successor was entered

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.

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.

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.

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

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

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

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

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

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

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

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.

Data Integrity Checks

Data Integrity Checks (automatic list)

none found

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

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

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	x10⁹/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

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

TODO

todo

R_Complete

Data Element (edit)
Field Name:	R Complete
CCMDB Label:	not stated
CCMDB tab:	Top Row
Table:	L Log table
Data type:	boolean
Length:	not stated
Program:	CC
Created/Raw:	Raw
Start Date:	1 Jan 2000
End Date:	31 Dec 2100
Sort Index:	78

true when patient registry data is complete

started after jan 1 2000

Checkbox is set to true by collector when patient registry data (Category:Registry Data) is complete. Checking the box initiates Data Integrity Checks relevant for that data.

ADL_Complete

Data Element (edit)
Field Name:	ADL Complete
CCMDB Label:	not stated
CCMDB tab:	Top Row
Table:	L Log table
Data type:	boolean
Length:	not stated
Program:	CC
Created/Raw:	Raw
Start Date:	1 Jan 2000
End Date:	31 Dec 2100
Sort Index:	79

true when patient ADL data is complete

started after jan 1 2000

Checkbox is set to true by collector when patient registry data (Category:ADL) is complete. Checking the box initiates Data Integrity Checks relevant for that data.

Ap_Complete

Data Element (edit)
Field Name:	Ap Complete
CCMDB Label:	not stated
CCMDB tab:	Top Row
Table:	L Log table
Data type:	boolean
Length:	not stated
Program:	CC
Created/Raw:	Raw
Start Date:	1 Jan 2000
End Date:	31 Dec 2100
Sort Index:	80

True when patient APACH II data is complete

started after jan 1 2000

Checkbox is set to true by collector when patient APACHE II data (Category:APACHE II) is complete. Checking the box initiates Data Integrity Checks relevant for that data.

ApLab_Complete

ApLab Complete

Labs_Complete

Data Element (edit)
Field Name:	Labs_Complete
CCMDB Label:	not stated
CCMDB tab:	Top Row
Table:	L Log table
Data type:	boolean
Length:	not stated
Program:	CC
Created/Raw:	Raw
Start Date:	1 Jan 2000
End Date:	31 Dec 2100
Sort Index:	82

True when patient Labs data is complete

All collectors use this checkbox differently. And at this point labs are not even counted in there, so it is most likely used as a "I have finished counting images and blood products"

Checking the box initiates Data Integrity Checks relevant for that data.

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

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

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

Current definition as of 2021-04-21

The most recent version is Admit DtTm as derived by Created_AdmitDtTm query

Previous definitions

Legacy Content

This page contains Legacy Content.

Explanation: Created_AdmitDtTm query
Successor: Created_AdmitDtTm query

Click Expand to show legacy content.

Arrive DtTm and Accept DtTm

The Admit date and time used to designate the time a patient was admitted to the ward/unit. For critical care it designated the time the patient physically arrived on the unit, the one for medicine when the patient was accepted to the medicine service.

Collection instructions for this article were transferred to Arrive DtTm and Accept DtTm as appropriate and deleted from here to prevent accidental use of outdated information. See 2016-07-03 history of the article for old instructions, such as when this was encoded as field R_AdmDate.

CCMDB Data Integrity Checks

Minimal_Data_Set#CCDMB_Data_Integrity_Checks for patients with Dispo DtTm before 2016-07-01

Date and time formats

see Date and Time Format

Data use

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

Legacy Content

This page contains Legacy Content.

Explanation: This is a legacy data field, its DataElementEndDate is in the past.
Successor: No successor was entered

Click Expand to show legacy content.

Data Element (edit)
Field Name:	Transfer_Ready_DtTm
CCMDB Label:	Transfer Ready DtTm
CCMDB tab:	Dispo
Table:	L_Log table
Data type:	date
Length:	not stated
Program:	Med and CC
Created/Raw:	Raw
Start Date:	1999-06-01
End Date:	2020-10-15
Sort Index:	47

Date and time the intent to discharge a patient to a lower level in the Level of care hierarchy was documented.

See Transfer Ready DtTm tmp entry

The data in this field will be retained in Centralized data.mdb's L_Log table since it doesn't follow the same pattern as the new entry. The field no longer exists in CCMDB data.mdb.

See Transfer Ready DtTm tmp entry for what this field is about, or see the history of this page for how it has been used at different times before moving to the new field.

Collection Instruction

Entering a Transfer Ready DtTm

Follow the instructions in Transfer Ready DtTm tmp entry.

Before 2020-10-15
For each patient, 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

Legacy Content

This page contains Legacy Content.

Explanation: This is a legacy data field, its DataElementEndDate is in the past.
Successor: No successor was entered

Click Expand to show legacy content.

Data Element (edit)
Field Name:	Transfer_Ready_DtTm
CCMDB Label:	Transfer Ready DtTm
CCMDB tab:	Dispo
Table:	L_Log table
Data type:	date
Length:	not stated
Program:	Med and CC
Created/Raw:	Raw
Start Date:	1999-06-01
End Date:	2020-10-15
Sort Index:	47

Date and time the intent to discharge a patient to a lower level in the Level of care hierarchy was documented.

See Transfer Ready DtTm tmp entry

The data in this field will be retained in Centralized data.mdb's L_Log table since it doesn't follow the same pattern as the new entry. The field no longer exists in CCMDB data.mdb.

See Transfer Ready DtTm tmp entry for what this field is about, or see the history of this page for how it has been used at different times before moving to the new field.

Collection Instruction

Entering a Transfer Ready DtTm

Follow the instructions in Transfer Ready DtTm tmp entry.

Before 2020-10-15
For each patient, 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

Legacy Content

This page contains Legacy Content.

Explanation: This is a legacy data field, its DataElementEndDate is in the past.
Successor: No successor was entered

Click Expand to show legacy content.

Data Element (edit)
Field Name:	R_Filter
CCMDB Label:	LTV
CCMDB tab:	Dispo
Table:	L_Log table
Data type:	string
Length:	10
Program:	Med and CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2019-01-01
Sort Index:	26

Critical care patients on a long term ventilator (LTV).

Conversion from our old diagnosis schema to ICD10/CCI

Chronic dependence on mechanical ventilator
might be best to move this into a dx field for conversion before ICD10 conversion to not add additional complexity then... Ttenbergen 19:58, 2017 September 16 (CDT)

Legacy Data

For legacy reasons the actual name of the field in ccmdb_data.mdb and Centralized_data.mdb is R_Filter.

B, H, BH

HSC-CCU Only.

Started: Sept 25, 2003
Stopped 2005
B = CCU patient on B3 only
H = CCU patient on H7-CCU only
BH = CCU patient on BOTH B3 & H7-CCU during one admission

Purpose was to capture CCU patient location during ICU CCU bed closure and during some renovations.

CC, CCN

HSC & STB-CCU patients only. Tags used for ICU:

CC - intubated/ventilated patient in MICU under care of cardiology service or co-managed with MICU attending
CCN - not ventilated but requires inotrope support, IABP or central lines in MICU under the care of cardiology service or co-managed with MICU attending

H1C, H1S, H1N

H1C and H1S are H1N confirmed and suspects when we are doing the H1N audit.

Other values

1 22E
5 DAN
1 GRA
1 H3N
11 H4H
9 HB
2 LTR
59 MR9
130 MRT
3 NP
2 U

translation into other fields

Based on Julie's review 2017-04-18

LTV (Long Term Ventilated patients)

– 463 records from 1988 to present at all sites ICUs --> to Chronic dependence on mechanical ventilator

- INSERT INTO L_ICD10 ( L_ICD10_ID, D_ID, ICD10_code, Dx_Type, Dx_Priority )

SELECT [D_ID] & "_LTV" AS L_ID, L_Log.D_ID, " Z99.1" AS ICD10, "Comorbid" AS tp, 28 AS Pr

FROM L_Log

WHERE (((L_Log.R_Filter)="LTV"));

H1S, H1C (i.e. H1N suspect and H1N confirm )

- 155 records, 2009 at all sites --> to H1N1

- INSERT INTO L_TmpV2 ( D_Tmp_ID, D_ID, Project, Item, comment_var )

SELECT [D_ID] & "_H1N1_s" AS L_ID, L_Log.D_ID, "H1N suspect" AS tmp_p, "H1N suspect" AS tmp_i, "from R_Filter" AS c

FROM L_Log

WHERE (((L_Log.R_Filter)="H1S"));

INSERT INTO L_TmpV2 ( D_Tmp_ID, D_ID, Project, Item, comment_var )

SELECT [D_ID] & "_H1N1_s" AS L_ID, L_Log.D_ID, "H1N confirmed" AS tmp_p, "H1N confirmed" AS tmp_i, "from R_Filter" AS c

FROM L_Log

WHERE (((L_Log.R_Filter)="H1C"));

Delete

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

@@ Line 4: / Line 4: @@
 Work in progress, all articles need to be updated for this to work.
 == L_Log ==
-===Pat_ID ===
+=== [[Pat_ID]] ===
 {{:Pat_ID}}
-=== LastName ===
+=== [[LastName]] ===
 {{:Last Name}}
-=== FirstName ===
+=== [[FirstName]] ===
 {{:First Name}}
-=== PHIN ===
+=== [[PHIN]] ===
 {{:PHIN}}
-=== Birth ===
+=== [[Birth]] ===
 {{:Date of Birth}}
-=== Chart ===
+=== [[Chart]] ===
 {{:Chart}}
-=== start_Time ===
+=== [[start_Time]] ===
 {{:Start time}}
-=== start_Date ===
+=== [[start_Date]] ===
 {{:Start date}}
-=== Notes ===
+=== [[Notes]] ===
 {{:Notes field}}
 === [[DC Treatment]] (R_dc_treat) ===
 {{:DC Treatment}}
@@ Line 31: / Line 30: @@
 === [[Registry Patient Type]] (R_Type) ===
 {{:Registry Patient Type}}
-=== FinalCheck ===
+=== [[FinalCheck]] ===
 {{: FinalCheck}}
 === [[Last Opened field]] (LastOpened_DtTm) ===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Auto Data Dictionary: Difference between revisions

Revision as of 16:38, 15 August 2016

what is this?

L_Log

Tables

Related Articles

Data Processing at main office

Name changes over time

Minimal Data Set

L_PHI vs L_Log

Data Integrity Checks (automatic list)

Legacy info

Legacy Content

Related Articles

Data Processing at main office

Name changes over time

Minimal Data Set

L_PHI vs L_Log

Data Integrity Checks (automatic list)

Legacy info

Legacy Content

Related Articles

MB Health PHINs only

Possibility of adding other Province's PHINs

Special Cases

Location Manitoba and no PHIN

International Students

Location Outside Manitoba and no PHIN

Canadian Forces patients

PseudoPHIN

Multiple PHINs or PHIN changes over time

Minimal Data Set

L_PHI vs L_Log

Data Integrity Checks (automatic list)

Related articles

L_PHI vs L_Log

Cross checks

CCMDB.accdb cross checks triggering for correct values

Data Integrity Checks (automatic list)

Related articles

Collection instructions

Leading Zeros

Dashes near the end of the number

Unclear or changing chart numbers

Minimal Data Set

Data Processing

L_PHI vs L_Log

Cross checks

Data Integrity Checks (automatic list)

Related articles

Related articles

Related articles

Usage of the notes field

Guidelines

Patients being sent

Up-to where/when collection is complete

Diagnoses or other data that needs to be reviewed or checked

Supplemental data

Automatic population of notes field for newly entered patients

Related articles

DC Treatment (R_dc_treat)

Legacy Content

Legacy Content

See Also

Log

Related articles

Province Field (R_Province)

Collection Instructions

Canadian Forces patients

Data Integrity Check List

Data Integrity Checks (automatic list)

Data Structure

Related articles

Sex field (R_Sex)

Sex changes over time

Data Integrity Checks (automatic list)

Related Articles

Registry Patient Type (R_Type)

Legacy Content

Medicine Wards

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

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

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

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

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

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

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

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

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

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