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)

To do

R_dc_treat

The concept encoded by this is slightly different than other End-of-life related data so it can not be transferred into new fields that encode related concepts, so we will keep it in the Centralized data.mdb's L Log table. It has been removed from CCMDB.accdb.

	_dev_CFE_Data The field has a length of 50 and should be reduced to 2 now that that's the longest content.	added: 2022-06-30 action: 2023-05-04

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

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

Collection instructions

What is Transfer Ready

The status of "transfer ready" is about the date/time of an intent to transfer a patient to lower level of care in the Level of care hierarchy if there was a bed available. Whether or not the patient actually moves does not matter, just that at some point there was an intent to move the pt. It also does not matter whether after such a determination the care team changed their minds about such a desired transfer.
Obviously we don't always know the team's intentions, but if they do write them down, then use that info.
- In making this delineation, except as for the exceptions listed immediately below, only consider a clearly written intent that the team now desires the patient to be transferred to such a lower level of care.
  - In particular, when a ward patient is transferred (e.g. home) without any notes stating the team’s intention to do so in advance or even an order to discharge, collectors should not attempt to make educated guesses from the notes of when the patient was probably clinically ready to leave and the checkbox is checked.

See Level of care hierarchy for further information.

Specifically for ICU

In an ICU, take the following to indicate transfer ready to a lower level of care even if they have not written that explicitly:

Care is stepped down to ward frequency (q4hrs or less) of vitals AND off all forms of life support except possibly intermittent dialysis
HSC_IICU consult is written
patient is made ACP-C
for organ donors, see Guideline for coding organ donation after death
if the patient is a potential organ donor and then deemed not to be, the Transfer Ready tmp DtTm will be when that determination is made
for those patients who are declared brain dead, and do not become actual or potential organ donors, use the time of Brain death as the Transfer Ready DtTm tmp entry, and the time of cardiac death as the Dispo DtTm

Specifically for Medicine

On a medicine ward, take the following to indicate transfer ready to a lower level of care even if they have not written that explicitly:

For SBGH If there is no discharge order, then the DC summary date/time that the attending signs off can be used, however if the date and time is after the DC time then it may be documented in a nursing or allied health IPN. Also, for SBGH often bed utilization will document when they are waiting on a transfer to an LAU or other facility, or rehab services will document when they are on the central wait list, or long term care (LTC) will document when they are approved for a PCH bed.
For HSC if there is no discharge order, then check the IPN notes (nursing, allied health etc), often bed utilization will document when they are waiting on a transfer to an LAU or other facility, or rehab services will document when they are on the central wait list, or long term care (LTC) will document when they are approved for a PCH bed.
Order is written to change all iv meds to po AND monitor discontinued/vital sign frequency is reduced
Patient is made ACP-C
If a discharge order is written during the preceding day(s) prior to discharge:
- and a specific date and time for discharge is documented in that order, the transfer ready date and time would be the date and time specified in the order.
- and If the order is to discharge after a specific test or procedure/treatment ie. dialysis or last dose of antibiotics, then the transfer ready date and time would be the time they finish the treatment or procedure.
- and there is no specific date and time documented for discharge or another order for discharge is written, then check the checkbox or use that new discharge order date and time

The discharge medication reconciliation form should NOT be used as transfer ready date and time.

PT/OT Assessment: Before going home, some ward patients get a home safety evaluation from PT and OT, and if deemed safe for home get a homecare evaluation before going home. The transfer ready date/time in such a situation should be only after the PT/OT evaluation has deemed them safe to go home, i.e. before homecare has seen them. The rationale is that homecare evaluation can occur after discharge, but a hospitalized patient who “fails” their home safety evaluation will end up going to LTC, not home.
exception to this would be for those patients that are waiting for transfer to a rehab ward (Geri, stroke, amp, neuro etc) The date and time they are placed on the wait list for rehab can be used as their transfer ready date and time

Data entry instructions

A "Transfer Ready" line is automatically created for each Boarding Loc entry.
- Project: Transfer Ready DtTm
- Item: the only available item is "Transfer Ready DtTm", just like the project entry.
- Date and Time vs checkbox:
  - Collector needs to enter one of the following:
    - First Date and Time during the stay at this Boarding Loc that patient became transfer ready as per #What is Transfer Ready above

OR

checkbox checked if a clear transfer ready date and time are never documented, both must be present to be considered a valid Transfer Ready DtTm

Combining Transfer Ready DtTm tmp entry and Boarding Loc records

There needs to be one Transfer Ready DtTm tmp entry for each Boarding Loc and vice versa. To mark which entries belong together, use the same integer number in the "combiner" field in Patient Viewer Tab Cognos ADT2 for both records and in sequential order according to Boarding start_dt and start_tm. The presence of matching records is validated by query s_tmp_check_combined_Boarding_Loc_and_TransferReadyDtTm, and their sequential status by query s_tmp_check_combined_BL_and_TRDtTm_nonsequential.
the integer number should be entered at the time that the paired Boarding Loc and Transfer Ready DtTm tmp entry are entered, as Julie uses this data early to report on

Collection for each Boarding Loc

We currently only use the first entry per Level of care to calculate Transfer Delay, but we collect both because:

It gives us the flexibility to report per location if requested
To make it easier for data collectors. This way, collectors don't have to try and go back and figure out if there was or was not a transfer ready in a prior location. They only need be concerned about the notes and orders from THIS boarding loc.

Start DtTm/Legacy

We used the old Transfer Ready DtTm field for transfer ready dttms before 2020-10-15, and use this new entry for dttms after.

The data during the transition period for PatientFollow Project is inconsistent, so we use all the new and the old in Created TransferReady query.

Data Use / Purpose

Critical care and Medicine programs want to know this to better understand patient flow and bed utilization.

Used via Created_TransferReady query and Created_transferDelay table to generate Transfer Delay and Avoidable Days (Critical Care).

Background

This isn't so much a project as a change to Transfer Ready DtTm collection to allow us to collect more than one Transfer Ready DtTm per patient-program-stay. See Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry for why we needed to change to this.

Data Integrity Checks (automatic list)

none found

Log

2021-07-08 - Change from Awaiting/delayed dx codes to Transfer Ready DtTm for data back to 2021-07-01

Legacy

Similar to the old Transfer Ready DtTm field and Transfer Ready date and time, but we eliminated special cases and differences between medicine and critical care.

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

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.

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

Projects
Active?:	active
Program:	CC and Med
Requestor:	internal
Collection start:	2020-10-15
Collection end:

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:	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:	ADL_Bathing
CCMDB Label:	Bathing
CCMDB tab:	ADL
Table:	L Log table
Data type:	string
Length:	15
Program:	Med
Created/Raw:	Raw
Start Date:	2003-10-01
End Date:	2300-01-01
Sort Index:	49

Data Element (edit)
Field Name:	ADL_Dressing
CCMDB Label:	Dressing
CCMDB tab:	ADL
Table:	L Log table
Data type:	string
Length:	15
Program:	Med
Created/Raw:	Raw
Start Date:	2003-10-01
End Date:	2300-01-01
Sort Index:	50

Data Element (edit)
Field Name:	ADL_Transfering
CCMDB Label:	Transfering
CCMDB tab:	ADL
Table:	L Log table
Data type:	string
Length:	15
Program:	Med
Created/Raw:	Raw
Start Date:	2003-10-01
End Date:	2300-01-01
Sort Index:	52

Data Element (edit)
Field Name:	ADL Continence
CCMDB Label:	Continence
CCMDB tab:	ADL
Table:	L Log table
Data type:	string
Length:	15
Program:	Med
Created/Raw:	Raw
Start Date:	2003-10-01
End Date:	2300-01-01
Sort Index:	53

Data Element (edit)
Field Name:	ADL_Feeding
CCMDB Label:	Feeding
CCMDB tab:	ADL
Table:	L Log table
Data type:	string
Length:	15
Program:	Med
Created/Raw:	Raw
Start Date:	2003-10-01
End Date:	2300-01-01
Sort Index:	54

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

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

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

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

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

Auto Data Dictionary

what is this?

L_Log

Pat_ID

Tables

Related Articles

LastName

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

FirstName

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

PHIN

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

Birth

L_PHI vs L_Log

Cross checks

CCMDB.accdb cross checks triggering for correct values

Data Integrity Checks (automatic list)

Related articles

Chart

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

start_Time

Related articles

start_Date

Related articles

Notes

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

To do

R_dc_treat

Legacy Content

Legacy Content

See Also

Log

Related articles

R_Province

R_Sex

R_Type

FinalCheck

LastOpened_DtTm

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

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

Data Element (edit)
Field Name:	RecordStatus
CCMDB Label:	Status
CCMDB tab:	Top Row
Table:	L_Log table
Data type:	string
Length:	20
Program:	Med and CC
Created/Raw:	Raw
Start Date:	2013-04-24
End Date:	2300-01-01
Sort Index:	80