Auto Data Dictionary

From CCMDB Wiki
Revision as of 14:50, 2016 June 27 by Ttenbergen (talk | contribs) (just a start)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

L_Log

Pat_ID

Data Element (edit)
Field Name: Pat_ID
CCMDB Label: Serial
CCMDB tab: Top Row
Table: L_CCI_Picklist table, L_CCI_Component table, L Como table, L Dxs table, L ICD10 table, L_Labs_Flowsheet table, L Log table, L PCH table, L_PHI table, L_Pharm_Flowsheet table, L TISS Form table, L TISS Item table, L TmpV2 table
Data type: number
Length: Long Integer
Program: Med and CC
Created/Raw: Raw
Start Date: 1988-07-11
End Date: 2300-01-01
Sort Index: 1

The Pat_ID field contains a unique-per-laptop identifying number for patient ward admissions. See Serial number.

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


Pat_ID is used in CCMDB.accdb. In CFE / Centralized_data.mdb, D_ID is the equivalent. D_ID is the combination of the Service/Location and the Pat_ID.

Tables

Related Articles

Related articles:

=== LastName === LastName === FirstName === FirstName

PHIN

Data Element (edit)
Field Name: PHIN
CCMDB Label: PHIN
CCMDB tab: Top Row
Table: L_Log table, L_PHI table
Data type: number
Length: Long Integer
Program: Med and CC
Created/Raw: Raw
Start Date: 1988-07-11
End Date: 2300-01-01
Sort Index: 4

The patient's PHIN .

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


The PHIN (Personal Health Information number) is a unique nine-digit numeric identifier assigned by Manitoba Health to every person registered for health insurance in Manitoba. For patients who are not registered with Manitoba Health we assign a Pseudo PHIN.

MB Health PHINs only

Manitoba Health PHIN numbers only.

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

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

Possibility of adding other Province's PHINs

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

Related articles

Related articles:

=== Birth === Birth

Chart

Data Element (edit)
Field Name: Chart
CCMDB Label: Chart
CCMDB tab: Top Row
Table: L_Log table, L_PHI table
Data type: string
Length: 8
Program: Med and CC
Created/Raw: Raw
Start Date: 1988-07-11
End Date: 2300-01-01
Sort Index: 6

The number used by medical records to uniquely identify a patient's chart; it is different for the same patients at different hospitals.

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


The number is assigned to a patient by Admitting. This is done once the patient has been seen by Triage in ER or new to the hospital for clinics, testing and various workups. This number remains the patient's chart number for all hospital visits, admissions, tests, etc.

Collection instructions

Leading Zeros

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

Dashes near the end of the number

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

Unclear or changing chart numbers

See

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

Related articles

Related articles:

=== start_Time === Start Time === start_Date === Start Date

Notes

Data Element (edit)
Field Name: Notes
CCMDB Label: Notes
CCMDB tab: Top Row
Table: L_Log table
Data type: memo
Length: not stated
Program: Med and CC
Created/Raw: Raw
Start Date: 1988-07-11
End Date: 2300-01-01
Sort Index: 9

Used by data collectors to keep notes during collection.

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


The notes field expands to a bigger form when you double-click on it.

Usage of the notes field

The notes field was set up to be a free-for-all where collectors can store any info they want. This resulted in non-standardized collection practices which result in problems during vacation coverage or on shared wards.

Guidelines

  • Please do not write copious history notes from charts into this note section. This is only for reminders or points needed to do your work, dates where you left off at or any follow up of info, test etc., that need to be done by yourself or for others who help collect on your laptop. Notes have to be clear to others.

Patients being sent

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)

Related articles

Related articles:

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

_dev_CFE_Data

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


  • Categories

Legacy Content

This page contains Legacy Content.
  • Explanation: stopped collection in Medicine
  • Successor: various tmp and dx codes relating to palliative care and End-of-life related data

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.

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


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

Defined as terminal withdrawal with expectation of death of:

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

See Also

See: Comfort Care

Log

  • 2022-05-10 removed from collection screen

Related articles

Related articles:

=== R_AdmitFrom === Admit from is a legacy field that used to encode the hospital and ward from where a patient was admitted. See Previous Location field. The Discharge to is a legacy field that used to encode the hospital and ward that a patient was discharged to. See Dispo field. === R_DischargedTo === Admit from is a legacy field that used to encode the hospital and ward from where a patient was admitted. See Previous Location field. The Discharge to is a legacy field that used to encode the hospital and ward that a patient was discharged to. See Dispo field. === R_HospitalPrevious === The Hospital previous field contains the previous hospital for patients who were admitted from another hospital outside of Winnipeg. === R_Province === R Province === R_Sex === R Sex === R_Type === R Type === R_SurviveExpire === The Survive / Expired field used to track if a patient survived to be discharged. Options are Survive, Expire. === R_AdmDate === The concept of "Admit date and time" is not as simple as it might seem due to the way we use it in reporting, and how it has been stored over time.

Current definition as of 2021-04-21

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

Previous definitions

Legacy Content

This page contains Legacy Content.

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

See also

=== R_AdmTime === The concept of "Admit date and time" is not as simple as it might seem due to the way we use it in reporting, and how it has been stored over time.

Current definition as of 2021-04-21

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

Previous definitions

Legacy Content

This page contains Legacy Content.

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

See also

R_TRDate

 
 
 
 

Legacy Content

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

Click Expand to show legacy content.

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

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

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See Transfer Ready DtTm tmp entry

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


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

Collection Instruction

Entering a Transfer Ready DtTm

Follow the instructions in Transfer Ready DtTm tmp entry.

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

Cross Checks

Data Integrity Checks (automatic list)

none found

Legacy

Similar to the old Transfer Ready date and time, but we eliminated special cases and differences between medicine and critical care. Going forward the entry will be collected even if pt dies or goes to ER etc. It's the intent that counts, not what ended up happening. Resp. field names L_Log.R_TRDate and L_Log.R_TRTime

Related Articles

Related articles:

R_TRTime

 
 
 
 

Legacy Content

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

Click Expand to show legacy content.

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

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

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See Transfer Ready DtTm tmp entry

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


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

Collection Instruction

Entering a Transfer Ready DtTm

Follow the instructions in Transfer Ready DtTm tmp entry.

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

Cross Checks

Data Integrity Checks (automatic list)

none found

Legacy

Similar to the old Transfer Ready date and time, but we eliminated special cases and differences between medicine and critical care. Going forward the entry will be collected even if pt dies or goes to ER etc. It's the intent that counts, not what ended up happening. Resp. field names L_Log.R_TRDate and L_Log.R_TRTime

Related Articles

Related articles:

=== R_DisDate === The Discharge date and time is the time that a patient leaves the unit or dies. === R_DisTime === The Discharge date and time is the time that a patient leaves the unit or dies.

=== R_Filter ===

_CFE_Data_reconsolidate

  • added:
  • action: 2023-07-13
  • Cargo


  • Categories

_after

  • removed field from sending
  • removed field from sending
  • removed field from ccmdb_data
  • remove field from CFE data
  • delete wiki page when done
  • added:
  • action: 2023-07-13
  • Cargo


  • Categories


 
 
 
 

Legacy Content

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

Click Expand to show legacy content.

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

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

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


Conversion from our old diagnosis schema to ICD10/CCI

Legacy Data

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

B, H, BH

HSC-CCU Only.

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

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

CC, CCN

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

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

H1C, H1S, H1N

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

Other values

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

translation into other fields

Based on Julie's review 2017-04-18

LTV (Long Term Ventilated patients)

– 463 records from 1988 to present at all sites ICUs --> to Chronic dependence on mechanical ventilator
    • INSERT INTO L_ICD10 ( L_ICD10_ID, D_ID, ICD10_code, Dx_Type, Dx_Priority )
SELECT [D_ID] & "_LTV" AS L_ID, L_Log.D_ID, " Z99.1" AS ICD10, "Comorbid" AS tp, 28 AS Pr
FROM L_Log
WHERE (((L_Log.R_Filter)="LTV"));

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

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

    • INSERT INTO L_TmpV2 ( D_Tmp_ID, D_ID, Project, Item, comment_var )
SELECT [D_ID] & "_H1N1_s" AS L_ID, L_Log.D_ID, "H1N suspect" AS tmp_p, "H1N suspect" AS tmp_i, "from R_Filter" AS c
FROM L_Log
WHERE (((L_Log.R_Filter)="H1S"));
  • INSERT INTO L_TmpV2 ( D_Tmp_ID, D_ID, Project, Item, comment_var )
SELECT [D_ID] & "_H1N1_s" AS L_ID, L_Log.D_ID, "H1N confirmed" AS tmp_p, "H1N confirmed" AS tmp_i, "from R_Filter" AS c
FROM L_Log
WHERE (((L_Log.R_Filter)="H1C"));

Delete

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

All Done PTorres 14:48, 2022 August 29 (CDT)

Project Legacy Co-managed

  • R_Filter values CC or CCN
  • 633 records from 1989-2004 at STB/HSC MICU
  • Based on the D_ID, the physical location-service involves, CCU, MICU,SICU
  • transitioned into Project Legacy Co-managed, see details there

turn into Project Legacy HSC CCU Loc

  • R_Filter values H/B/HB/BH
  • (HSC CCU at H7, B3 or both) – 1100 records from 2003 – 2006 at HSC CCU
  • See Project Legacy HSC CCU Loc for details

Related articles

Related articles:

=== Var1 === Var1 === Var2 === Var2 === Var3 === Var3 === Var4 === Var4 === Var5 === Var5 === Var6 === Var6 === PostalCode === PostalCode === LastOpened_DtTm === LastOpened DtTm === Pre_Acute_Living_Situation === Pre Acute Living Situation === Pre_admit_Inpatient_Institution === Pre admit Inpatient Institution

Previous_Location

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

The most recent previous physical location (with #exceptions) of a patient before arriving at the collection location.

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


Collection Instruction

For each patient,

  • enter the option that most closely matches:
  • if you know the situation but nothing on the list matches closely, enter other - known but not listed
  • if the situation is unknown, enter Not known
  • if the patient is in ER under a service we do not collect ie. cardiology, surgery etc use <site>_ER

If you know the location exactly, you can type it, otherwise click on the dropdown button to view the options

Borrowed Bed Or Pt Boarding On Other Unit

For direct transfers within the Winnipeg region, should we enter the Last Boarding Location as the Previous Location ? No because these are only temporary location. Use the service taking care of the patient : <site>_Med, GH-CC, HSC_MICU, HSC_SICU, HSC_IICU, STB MICU, STB_ICCS, STB_ACCU.

Direct Transfers Scenarios

  1. From Outside Winnipeg facilities - whether inpt or not, if they went to <own site> ER (e.g. STB ER) for triage, previous location is <own site> ER (e.g. STB ER). If they just stop by only at <own site> ER, then previous location is the outside facility service - it does not matter if from ICU (e.g. Thompson ICU) or ER (e.g. Thompson ER) service of that outside facility as long as the pre-admit inpt has been filled up correctly (e.g. Thompson ICU) , then in TMP Boarding, put <own site> ER (e.g. STB ER) as first boarding loc.
  2. From Within Winnipeg facilities - For transfers among HSC/STB/GRA, we are linking all the admissions so we need to be specific for the sending and receiving service. If already inpatients, and no in-between procedures, pre-admit inpt is the same as previous location. if there is temporary location in-between, then previous location is equal to the temporary location (e.g. ER, OR, RR, Cath Lab, Dialysis, Radiology). If not yet an inpt and coming from <other site> ER then previous location is <other site> ER.
  3. When to use generic ward - If the patient from our sending service (e.g. HSC SICU) was discharged to a service we are not collecting (e.g. Step down ward) and then transfer again to the service (e.g. HSC Med) we are collecting, having no in-between procedure then the dispo of sending service, pre-admit inpt and previous location are all generic ward (e.g. HSC ward). For the case having in-between procedure, say, sending service is HSC Med to a surgery ward, then OR, then to HSC SICU, the dispo of the sending and pre-admit inpt are generic ward (e.g. HSC ward) and previous location is the temporary location e.g. HSC OR.
  4. For sites no longer collected ie. CON/OAK/VIC - inpatients from CON, OAK, VIC who are direct transfers to HSC/STB/GRA, the pre-admit inpt will not be N/A and the previous location is the same as the pre-admit inpt even if the patient spends time in site's UC prior to transfer. If not yet an inpt from CON/OAK/VIC and transfers only from their UC triage, then previous location is the CON/OAK/VIC UC.


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

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

query of what is currently available

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

Query of what is currently used

query z_s_dispo_inactivatable

Where to find this information

If patient came from a different Winnipeg hospital this should be recorded in the “Visit History” on the EPR, but sometimes it is missing. Can also use paper chart sent to your hospital from the sending hospital for information.

Exceptions

Data collection units that have a mix of different physician serve types

We have a few units in the Region that have a mix of different services (internal medicine, surgical, family medicine etc).

  • HSC_B3 - is a mix of day surgery & internal medicine patients
  • any others?

For patients from these units:

  • If patient was an internal medicine there, enter <site>_Med
  • If not a internal medicine patient, enter the <site>_Ward

from HSC psych unit

Code patient from POU (pysch evaluation unit @ HSC) as "HSC ambulatory care" - it's not an inpatient ward.

Dialysis unit as previous location

For patient from Dialysis unit, use that unit as previous location. Pre acute living situation field would be the unit they came from right before, if applicable.

Heart Cath Lab vs OR as previous location

When a procedure (e.g valve replacement) is done in the cath lab before the pt arrives on your unit, enter Cath Lab if done in Cath Lab and put OR if done in OR.

Patients from day surgery

For patients admitted from day surgery units, enter:

HSC Stepdown Units

Homeless Patients

If a homeless patient is admitted directly then code them as admitted from home. Usually they would be via ER, of course, and you'd code them as that.

Prison / Jail / Correctional Institution

If a patient is admitted from prison, jail or a correctional institution, code this as an admission from "Institution NOS".

See Prison / Jail / Correctional Institution for additional info.

Data Use

This data is used for tracking where most of the traffic on our units/wards comes from. For starters it will be reported to Critical Care (Randy Martin), who was also the requestor of this data.

Cross Checks

Data Integrity Checks (automatic list)

none found

Implementation

The field is populated with options from the s_dispo table.

Legacy

This field is part of the 2016 Time and Place changes.

It a combination of our previous

Related articles

Related articles:

=== Previous_Service === Collection stopping as per Task_Team_Meeting_-_Rolling_Agenda_and_Minutes_2022#ICU_Database_Task_Group_Meeting_–_August_24,_2022. Ttenbergen 16:00, 2022 September 7 (CDT)


 
 
 
 

Legacy Content

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

Click Expand to show legacy content.

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

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

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


Collection Instruction

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

From HD / From hemodialysis

From Cardiac Cath Lab

  • A patient goes to emergency, then is sent to the cardiac cath lab for an angiogram. Julie would like the sending service to be Emergency Medicine in these cases (not cardiology). Discussed at the task group meeting on July 20, 2017.
  • Most patients come to CCU or ICU via the heart cath as a code stemi, in which case the previous service is cardiology because they bypass ER and go direct to the heart cath lab.
  • The previous service is who was looking after the pt before the heart cath in some situations. For example, if ECMO is done in the heart cath lab : If the pt was on a ward or unit prior to the procedure, the service is whatever ward or unit it was that sent the pt there. If ER sends a pt for a VV ECMO, the ER is the sending service, unless ICU takes over the pt prior to the ECMO. (They would need to consult cardiac surgery for the ecmo procedure but it would be the ICU that takes over the care ultimately).

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

from OR

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

Nursing Home Wards (HSC/GRA)

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

Admit from home

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

from EMIP via ER

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

admission from a unit partly collected by us

see Previous_Location_field#from_a_unit_that_is_partly_collected_by_us.2C_and_partly_not.

admission from a nursing station

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

Direct admit

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

Example:   

testcontent

Urgent Care

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

Clinical Assessment Units

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

Data Use

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

Integrity checks

Data Integrity Checks (automatic list)

none found

Implementation

The field is populated with options from the s_previous_service table.

Legacy

For medicine this concept is related to ER Wait.

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

  • see updated minutes dated August 24, 2017.

Related articles

Related articles:

=== off_ward === Are now collected as part of Using Cognos2 to keep track of patients / Boarding Loc


 
 
 
 

Legacy Content

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

Click Expand to show legacy content.

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

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

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms



Legacy

  • Allan suggested this OFFWARD field for some reasons related to outcome. you are right the tmp Boarding will indicate patients staying in offward locations. Offward started July 2016. CC started tmp Boarding July 2018 while Med on Sept2019. since offward start date was before any of these BL dates, we need to keep those data in prior dates. --JMojica 16:18, 2022 August 12 (CDT)
    • Here is a query with counts by send time:
TRANSFORM Count(L_Log.D_ID) AS CountOfD_ID
SELECT Format([SentDtTm],"yy-mm") AS send_month
FROM L_Log
GROUP BY Format([SentDtTm],"yy-mm")
ORDER BY Format([SentDtTm],"yy-mm"), L_Log.off_ward
PIVOT L_Log.off_ward;
It actually looks like we used this from 2014 onward, even if the data definition on this page says from 2016.

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

    • For the pre2016 profiles, the OFFWARD field is pre-populated by the old VAR3, 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.

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

Entering off ward patients

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

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

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

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

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

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

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

Data Use

Relevant to Bed occupancy and some patient risks.

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

See also

Cross Checks

Legacy but still implemented: ACCU_borrow#If_ACCU_entry_then_off-ward_should_be_checked

Legacy

initial mis-connection

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

pre-2016 fields for similar content

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

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

Related Articles

Related articles:

Service_Location

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

Legacy field replaced by Boarding Loc and Service tmp entry

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


Legacy field: the entry is now static on most laptops, and the information that used to be stored in here is now stored in Boarding Loc and Service tmp entry as part of Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry.

  • Hey T, this page is for the Service location field in the demographics Tab correct? not sure why we have this as a legacy field? Or am I misunderstanding this?Lisa Kaita 15:11, 2024 March 6 (CST)
    • I think that was written when we first changed and decided to only have <site>_<program>, ie before we split the CC program back up. In a way it is still legacy as that meaning, because now the meaningful info should live in Service and Unit entries in tmp. Between this and your question below about where that info should live, we may want to make an overarching page for the three concepts. I was wondering if we already have one, but the closest thing is Change from Service Location to Service, Boarding Loc and Transfer Ready DtTm tmp entry and that's not quite it. The cleanest way to to it might be to make a new page of the current Collection instructions for Service/Location vs Boarding Loc vs Service page, interlink it with the change page, and then keep only the current state/collector instruction in the "collection instructions..." page and the history in the "Change..." page. This is one of those things that are difficult to document because we need both the current state for collection and the complete history for interpretation. Having two pages like that should do it. Ttenbergen 16:30, 2024 March 6 (CST)
    • I am not entirely clear on your instructions, or how to go about doing some of this, maybe when you have time we can chat about it, no rush Lisa Kaita 12:25, 2024 March 12 (CDT)
      • Are you in today to chat? Ttenbergen 11:22, 2024 March 21 (CDT)
  • SMW


  • Cargo


  • Categories

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:

Bed Borrow

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


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

"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

Data Use / Purpose

See Site and Location table for possible entries.

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

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

Integrity checks

Data Integrity Checks (automatic list)

none found

Implementation

The field is populated with options from the s_dispo table.

Retiring an available Service/Location field entry

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

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

Legacy

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

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

Related articles

Related articles:

Dispo

Data Element (edit)
Field Name: dispo
CCMDB Label: Dispo
CCMDB tab: Dispo
Table: L Log table
Data type: number
Length: long
Program: Med and CC
Created/Raw: Raw
Start Date: 2016-07-01
End Date: 2300-01-01
Sort Index: 41

The Dispo field contains information about what happens to the patient at the end of their admission.

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


Collection Instruction

surviving patients

HSC Stepdown Units

AMA

Homeless patients

If a homeless patient is discharged, either to a place like Siloam Mission or even without a specific plan, then code them as discharged to home. Consider whether they might have left AMA.

Prison / Jail / Correctional Institution

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

Chronic Health Facility

If a patient is discharged to a PCH bed at Deer Lodge or Riverview, then the option "Winnipeg PCH" should be used in the Dispo field.

Discharged to ER or Urgent Care

If you discharge a patient to the ER or Urgent Care, you can't enter this in the dispo field. The reason is that this should not happen. If it really does happen:

  • enter Not Canada or USA - unknown/other (this is a very rare entry so when we see it, we can question it. Put a note in to the Notes field so Pagasa can check there first.)
  • email Pagasa so she can enter your ER / Urgent Care location as dispo.

We don't want ER to be available in the dropdown because it had been mistakenly entered a number of times. If it turns out there are a lot of legitimate discharges to ER we will make the option available.

Visits to temporary locations

See Visits to temporary locations

Deceased patients

See

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

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

query of what is currently available

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

Query of what is currently used

query z_s_dispo_inactivatable

Data Use

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

Cross checks

Data Integrity Checks (automatic list)

none found

Implementation

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

Related Articles

Related articles:

Legacy

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

It a combination of our previous

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

Related articles:

Very early missing Discharge-tos

There were 6762 very old ICU records who are listed as survived but didn’t have a discharge-to. This is from HSC-only days when there simply were no checks.

When data was brought across from the old discharge to field the dispo fields of these records were set to 'survive(Legacy)'.

Visit_Admit_DtTm

Data Element (edit)
Field Name: Visit_Admit_DtTm
CCMDB Label: Visit Admit DtTm
CCMDB tab: Dispo
Table: L_Log table
Data type: date
Length: not stated
Program: Med and CC
Created/Raw: Raw
Start Date: Jan 1, 2003
End Date: 2300-01-01
Sort Index: 42

This field is used only as an identifier to combine data from the same hospitalization and should not be used as a date.

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


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

Purpose

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

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

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

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

Collection Instruction

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

Related articles

Related articles:
=== Accept_DtTm ===

_ccmdb_dev

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


  • Categories


 
 
 
 

Legacy Content

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

Click Expand to show legacy content.

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

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

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


Collection Instruction

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

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

Planned elimination of this field

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

Data Use

Patient flow

  • medicine program: to monitor delays to move patient from ER to Med ward bed
  • as of July 2016 onward - ICU same purpose

Accept DtTm is used as part of the formula to calculate delay in the transfer of patient from ER bed to Med ward or ICU bed - see ER Delay. This measures the amount of time for the patient already accepted in Medicine or Critical Care service but still using the ER bed and resources.

Data Integrity Checks (automatic list)

none found

Legacy

Click to see legacy info   
  • This field is part of the 2016 Time and Place changes.
    • For medicine this concept is related to admit date and time (when pt is from ER). It does not simply replace the field, so this value still needs to be entered for patients not from ER. Resp. field L_Log.R_AdmDate and L_Log.R_AdmTime
    • For critical care this concept is related to Service Sending to ICU. (There is no comparable field in ICU for this in the old system).

Related articles

Related articles:
=== Arrive_DtTm ===

_after

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


  • Categories


 
 
 
 

Legacy Content

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

Click Expand to show legacy content.

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

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

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


Collection Instruction

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

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

Planned elimination of this field

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

Data Integrity Checks (automatic list)

none found

Legacy

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.

Related Articles

Related articles:

Dispo_DtTm

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

Date and time when the patient changed status from what is documented in Service/Location field to Dispo field..

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


Collection Instruction

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

Discharge at midnight

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

Deceased patients

See Deceased patients#General instructions for deceased patients

Visits to temporary locations

AMA

Data use

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

Data Integrity Checks (automatic list)

none found

Legacy

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

Related Articles

Related articles:

Transfer_Ready_DtTm

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

Collection instructions

What is Transfer Ready

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

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

Collection for each Boarding Loc

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

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

Start DtTm/Legacy

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

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

Data Use / Purpose

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

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

Background

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

Data Integrity Checks (automatic list)

none found

Log

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

Legacy

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

Related articles

Related articles:

TR_info_status

 
 
 
 

Legacy Content

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

Click Expand to show legacy content.

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

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

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


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

Cross Checks

Data Integrity Checks (automatic list)

none found

Related articles

Related articles:

ADL_Bathing

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

Need for help with bathing; component of ADL.

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See also: ADL General Collection Information

Description Unassisted Minor Assistance Major Assistance
Either sponge bath, tub bath, or shower Receives no assistance (gets in and out of tub if tub is the usual means of bathing) Receives assistance in bathing only one part of the body (such as the back or leg) Receives assistance in bathing more than one part of the body (or not bathed)

Related articles

Related articles:

ADL_Dressing

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

Need for help with dressing; component of ADL.

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See also: ADL General Collection Information

Description Unassisted Minor Assistance Major Assistance
Gets clothes from closets and drawers including underclothes, outer garments, and using fasteners, e.g., for braces Gets clothes and gets completely dressed without assistance Gets their clothes and gets dressed without assistance except in tying shoes or buttoning or zipping up items Receives assistance in getting clothes or in getting dressed or stays partly or completely undressed

Related articles

Related articles:

=== ADL_Toileting === ADL Toileting

ADL_Transfering

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

Need for help with transferring; component of ADL

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See also: ADL General Collection Information

Description Unassisted Minor Assistance Major Assistance
Moving from one place to another while performing activities Moves in and out of bed as well as in and out of chair without assistance; may use object for support such as cane or walker Moves in and out of bed or chair with assistance Doesn't get out of bed

Related articles

Related articles:

ADL_Continence

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

Control of urination and bowel movements; component of ADL

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See also: ADL General Collection Information

Unassisted Minor Assistance Major Assistance
Controls urination and bowel movement completely by self, including patients with chronic renal failure; manages Foley at home on own (Foley is inserted solely to keep track of fluid output) Has occasional "accidents" Supervision helps keep urine or bowel control; catheter is used, or patient is incontinent; Foley is used because patient is unable to control bladder function (if it cannot be determined if the patient would be continent without a foley and the patient has a Foley, then score as major)

Related articles

Related articles:

ADL_Feeding

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

Need for help with feeding; component of ADL

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See also: ADL General Collection Information

Description Unassisted Minor Assistance Major Assistance
Preparing and eating food Feeds self without assistance; NPO due to pre-OP, tests or procedures or GI bleeding Feeds self except for getting assistance in cutting meat or buttering bread Receives assistance in feeding of is fed partly or completely by using tubes or intravenous fluids; dysphagia

Related articles

Related articles:

=== Ap_AdmitType === Ap AdmitType === Ap_Chronic === This article is about Chronic Health in the context of the APACHE score, see Comorbid Diagnosis for info on the comorbidities we collect, and Charlson Comorbidity Index for the Charlson comorbidities that are also used for the Alert score.

This value is now derived from ICD10 diagnoses, see Change for Apache Chronic to ICD10 from separate variable for details.


 
 
 
 

Legacy Content

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

Click Expand to show legacy content.

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

Specific chronic pre-existing conditions used for APACHE score.

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


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

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

Chronic Health Table

Dropdown in CCMDB.accdb Orignial APACHE II CH list with definitions
1. Immunocompromized (this category includes the following: Metastatic Cancer, Hematological Malignancy-Lymphoma, Leukemia and also AIDS) (this is applicable to items 1-5. Receiving therapy that suppresses resistance to infection such as: at least one of the following:
  • ≥15mg/kg/day hydrocortisone
  • >3 mg/kg’day of methylprednisolone for >5 days (for entire LOS if pts LOS is less than 5 days).
  • ≥10 mg prednisone
  • Chemotherapy
  • Radiation therapy
  • Post BMT (Bone Marrow Transplant)
  • sufficiently advanced disease to suppress resistance to infection
  • Include patients on methotrexate or cyclophosphamide, etc. (for autoimmune disorders)
  • pt is on immunosuppressive drugs (RA or SLE pts)
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

ICD10

We are moving to derive this concept from APACHE Comorbidities in ICD10 codes.

Change log

  • 2022-02-17 - decided to stop collecting this and apply Change for Apache Chronic to ICD10 from separate variable
  • 2022-02-09 - Julie, Tina and Allan discussed Julie's most recent analysis of this; there are still many differences in dx vs chronic, with higher and lower counts for different components. Allan quotes a paper that acknowledges this difference in count, but that the Apache score ends up similar. Question raised: is the saving of time in no longer collecting this as a field worth the loss of accuracy.
  • 2021-04-22 - preliminary analysis of how deriving this from ICD10 would compare with previous manual collection; many differences; Tina emailed Allan and Julie, more to come
  • 2021-04-19 - Added Drug-induced immunosuppression since that component of this code was not previously collected comprehensively
  • 2021-03-11 - The list of drugs is at Template:List of immunosuppressive drugs.
  • 2021-02-22 - AG sent email to Julie and Tina to get back to this change.
  • 2018-11-28 - AG confirmed that this is an option

Legacy

  • when sent for import into TMSX and MedTMS the chronic health score was translated into yes or no; when we moved to Centralized data.mdb these were imported as "0HasChronic"
  • the fields were made into a pick list of 9 items that belong to one of the five APACHE II Chronic Health categories because Medicine wanted to use both APACHE II and SAPS II on Medicine patients. SAPS II and APACHE II scored these same chronic health items differently. SAPS is no longer collected.

Related articles

Related articles:

=== Ap_Temp === Ap Temp === Ap_SapsSysBP === Ap SapsSysBP === Ap_APSysBP === Ap APSysBP === Ap_APDiasBP === Ap APDiasBP === Ap_HeartRate === Ap HeartRate === Ap_RespRate === Ap RespRate === Ap_Eye === Ap Eye === Ap_Motor === Ap Motor === Ap_Verbal === Ap Verbal === Ap_FIO2 === Ap FIO2 === Ap_PO2 === Ap PO2 === Ap_CO2 === Ap CO2 === Ap_pH === Ap pH === Ap_SerCO2 === Ap SerCO2 === Ap_Na === Ap Na === Ap_K === Ap K === Ap_Hemat === Ap Hemat === Ap_WBC === Ap WBC === Ap_Creat === Ap Creat === Ap_ARF === Ap ARF

R_Complete

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

true when patient registry data is complete

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


started after jan 1 2000

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

ADL_Complete

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

true when patient ADL data is complete

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


started after jan 1 2000

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

Ap_Complete

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

True when patient APACH II data is complete

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


started after jan 1 2000

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

Labs_Complete

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

True when patient Labs data is complete

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


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

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

Related articles

Related articles:

Tmp_Complete

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

True when patient Tmp data is complete

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


started after jan 1 2000

Checkbox is set to true by collector when patient Tmp data (Category:L TmpV2 Data‏‎, Category:Project) is complete. Checking the box initiates Data Integrity Checks relevant for that data.

Como_Complete

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

True when patient comorbid diagnosis data is complete

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


started after jan 1 2000

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

Diag_Complete

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

True when patient diagnosis data is complete

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


started after jan 1 2000

Checkbox is set to true by collector when patient diagnosis data (ICD10 collection and CCI Collection) is complete. Checking the box initiates Data Integrity Checks relevant for that data.

Pharm_Complete

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

True when patient pharmacy diagnosis data is complete

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


started after jan 1 2000

Checkbox is set to true by collector when patient pharmacy diagnosis data (Category:Pharmacy) is complete. Checking the box initiates Data Integrity Checks relevant for that data. === Pharm_Flow_Complete === Pharm Flow Complete

Record

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

Free choice use by collectors to help collection, this field has no consistent meaning.

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


=== Room_nr === Room nr === RecordStatus === if you are looking for the field collectors can use for their own custom designations, see Record field


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

status of the data in the record. Possible values are complete, sent, questioned and vetted.

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


The field can be seen on the Patient Viewer and the Patient List. The setting of the field will affect processing as follows.

Possible Values

incomplete

A patient is automatically set to incomplete when a new record is created.

complete

Once a patient's record is complete and all checkboxes in the Patient Viewer are set, the collector will try to set the patient to "complete". This changes triggers the CCMDB.accdb Data Integrity Checks that are set to run on completion; if any problems are found, the record is set back to "incomplete". Records that are set to complete will be treated differently during the next sending. Ideally the collector will set the field to "complete" as soon as you have entered the last data for a patient, while they still have the chart to be able to fix errors without having to get the chart again. Also, it saves time during sending.

sent

At sending, records that were set to "complete" will be changed to "sent" in both CCMDB.accdb and Centralized_data.mdb. A record that is "sent" can no longer be edited or overwritten by CCMDB.accdb during sending. If a record needs to be re-sent, the data processor needs to change the setting to "incomplete" first. In CCMDB.accdb, the "Delete Sent Patients" button checks for this field to be set to "sent" to delete patients.

discontinued

"Discontinued" is used for the following scenarios:

  • remnants of VIC Family Medicine patients which was collected after the consolidation for a period of one year from Oct 2017 to Oct 27, 2018. There were 30 patients still in the VIC units N4C, N5C and S5C by Oct 27,2018 when the decision to stop collection happened.
  • Lost/missing charts, see that page for details

only in CCMDB.mdb

deleted

We keep some portion of data for profiles that have been logically deleted of the laptop for 90 days (based on Dispo_DtTm). Use the "Previous entry" button to see all logically deleted records, or the Cognos2 Service Starter#"Show records on laptop with same chart number" button to see only records related to that patient.

When the "Delete Sent Patients" button is used, part of the record is actually retained for use by Cognos Report Integrator and collector investigations such as whether a patient had already been entered and deleted. The RecordStatus for these is set to "deleted" and they don't show up in the Patient List.

Names and most registry data and the entries of child tables such as Dxs etc are deleted, but Boarding Loc and Service tmp entry (and all other L TmpV2 entries) are retained.

Logically deleted profiles are eventually actually deleted by the "Delete Sent Patients" button (see time threshold above).

only in Centralized data.mdb

questioned

As part of the Centralized data Vetting Process the data processor runs queries to ensure data is valid. If any "sent" record has problems, she sets the recordstatus to "questioned". In the future a questioned record may be copied back to the collectors laptop automatically at the next send time to facilitate validation; likely the data processor would put an entry into the Notes field to tell the data collector what is wrong. See Questioning data back to collectors.

vetted

At the end of the Centralized data Vetting Process the data processor will press the "Vet all sent" button. At this time, any sent records that have not been flagged as "questioned" should be clean, so the button will set all "sent" to "vetted".

Data Integrity Checks

A lot of Data Integrity Checks are triggered when this field is set to complete.

Data checks that actually check validity of data in this field

Data Integrity Checks (automatic list)

none found

Related articles

Related articles:

=== LastChanged_DtTm === LastChanged DtTm === [pharm_Vitamin K antagonists] === {{: [pharm_Vitamin K antagonists]}} === [pharm_Heparin cont inf] === {{: [pharm_Heparin cont inf]}} === [pharm_Direct thrombin inhibitors] === {{: [pharm_Direct thrombin inhibitors]}}

pharm_Heparinoids

Data Element (edit)
Field Name: pharm_Heparinoids
CCMDB Label: (B2)Heparinoids
CCMDB tab: Pharm
Table: L_Log table
Data type: boolean
Length: not stated
Program: CC
Created/Raw: Raw
Start Date: 2012-01-01
End Date: 2300-01-01
Sort Index: 95

True if drug in field name was given

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See Pharmacy collection for collection info.


Drugs included in this are:

  • danaparoid (Orgaran-DVT, Orgaran (HIT))
  • SMW

Not set up, use Cargo

  • Cargo


=== [pharm_Factor Xa inhibitors] === {{: [pharm_Factor Xa inhibitors]}} === [pharm_Dopamine cont inf] === {{: [pharm_Dopamine cont inf]}} === [pharm_Dobutamine cont inf] === {{: [pharm_Dobutamine cont inf]}} === [pharm_Norepinephrine cont inf] === {{: [pharm_Norepinephrine cont inf]}} === [pharm_Epinephrine cont inf] === {{: [pharm_Epinephrine cont inf]}} === [pharm_Phenylephrine cont inf] === {{: [pharm_Phenylephrine cont inf]}} === [pharm_Vasopressin cont inf] === {{: [pharm_Vasopressin cont inf]}} === [pharm_Milrinone cont inf] === {{: [pharm_Milrinone cont inf]}} === [pharm_Paralytics cont inf] === {{: [pharm_Paralytics cont inf]}}

pharm_corticosteroids

Data Element (edit)
Field Name: pharm_corticosteroids
CCMDB Label: (E2)corticosteroids
CCMDB tab: Pharm
Table: L_Log table
Data type: boolean
Length: not stated
Program: CC
Created/Raw: Raw
Start Date: 2012-01-01
End Date: 2300-01-01
Sort Index: 105

True if drug in field name was given

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See Pharmacy collection for collection info.

Exclude if only route is inhaled.


Drugs included in this are:

  • Exclude if only route is inhaled.
  • betamethasone, cortisone, hydrocortisone (Solu-Cortef), methylprednisolone (Solu-Medrol), prednisone, dexamethasone (decadron), budesonide (Entocort), prednisolone, triamcinolone (tricortone)
  • NOT fludrocortisone (Florinef) excluded because it has no immunosuppressive effects)
  • SMW

Not set up, use Cargo

  • Cargo


Related articles

Related articles:

=== [pharm_amphotericin B] === {{: [pharm_amphotericin B]}}

pharm_macrolides

 
 
 
 

Legacy Content

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

Click Expand to show legacy content.

Data Element (edit)
Field Name: pharm_macrolides
CCMDB Label: <not in CCMDB>
CCMDB tab: Pharm
Table: L_Log table
Data type: boolean
Length: not stated
Program: CC
Created/Raw: Raw
Start Date: 2012-01-01
End Date: 2013-03-17
Sort Index: 107

True if drug in field name was given

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See Pharmacy collection for collection info. === [pharm_1st or 2nd generation cephalosporins] === {{: [pharm_1st or 2nd generation cephalosporins]}} === [pharm_4th generation cephalosporins] === {{: [pharm_4th generation cephalosporins]}} === [pharm_antistaph penicillins] === {{: [pharm_antistaph penicillins]}}

pharm_aminoglycosides

 
 
 
 

Legacy Content

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

Click Expand to show legacy content.

Data Element (edit)
Field Name: pharm_aminoglycosides
CCMDB Label: <not in CCMDB>
CCMDB tab: Pharm
Table: L_Log table
Data type: boolean
Length: not stated
Program: CC
Created/Raw: Raw
Start Date: 2012-01-01
End Date: 2013-03-05
Sort Index: 111

True if drug in field name was given

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See Pharmacy collection for collection info. === [pharm_influenza drugs] === {{: [pharm_influenza drugs]}}

pharm_bosentan

Data Element (edit)
Field Name: pharm_bosentan
CCMDB Label: (E5)bosentan
CCMDB tab: Pharm
Table: L_Log table
Data type: boolean
Length: not stated
Program: CC
Created/Raw: Raw
Start Date: 2012-01-01
End Date: 2300-01-01
Sort Index: 113

True if drug in field name was given

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See Pharmacy collection for collection info.

Drugs included in this are:

  • Tracleer - Oral
  • SMW

Not set up, use Cargo

  • Cargo



broken data

Collection/storage for Bosentan was broken.

We had good data from 2012/Jan/15 until 2012/Jul/02.

Then we did not have data again until 2014/Apr/27, and we have had data since then.

Related articles

Related articles:

=== [pharm_viagra-type vasodilators] === {{: [pharm_viagra-type vasodilators]}} === [pharm_special upper GI bleeding agents] === {{: [pharm_special upper GI bleeding agents]}}

pharm_amiodarones

Data Element (edit)
Field Name: pharm_amiodarones
CCMDB Label: (F2)amiodarones
CCMDB tab: Pharm
Table: L_Log table
Data type: boolean
Length: not stated
Program: CC
Created/Raw: Raw
Start Date: 2012-01-01
End Date: 2300-01-01
Sort Index: 116

True if drug in field name was given

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See Pharmacy collection for collection info. === [pharm_anti-TB drugs] === {{: [pharm_anti-TB drugs]}}

pharm_statins

Data Element (edit)
Field Name: pharm_statins
CCMDB Label: (F4)statins
CCMDB tab: Pharm
Table: L_Log table
Data type: boolean
Length: not stated
Program: CC
Created/Raw: Raw
Start Date: 2012-01-01
End Date: 2300-01-01
Sort Index: 118

True if drug in field name was given

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See Pharmacy collection for collection info.


Drugs included in this are:

  • atorvastatin (Lipitor)
  • fluvastatin (Lescol)
  • simvastatin (Zocor)
  • lovastatin (Mevacor)
  • pravastatin (Pravachol)
  • rosuvastatin (Crestor)
  • SMW

Not set up, use Cargo

  • Cargo


Related articles

Related articles:

pharm_PPI

Data Element (edit)
Field Name: pharm_PPI
CCMDB Label: (A1)PPI
CCMDB tab: Pharm
Table: L_Log table
Data type: boolean
Length: not stated
Program: CC
Created/Raw: Raw
Start Date: 2012-01-01
End Date: 2300-01-01
Sort Index: 119

True if drug in field name was given

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


Drugs included in this are:

  • esomeprazole (nexium)
  • pantoprazole (pantaloc)
  • omeprazole (pilosec)
  • rabeprazole (aciphex, pariet)
  • lansoprazole (prevacid)
  • dexlansoprazole (kapidex or dexilant)
  • SMW

Not set up, use Cargo

  • Cargo


pharm_H2_blockers

Data Element (edit)
Field Name: pharm_H2_blockers
CCMDB Label: (A2)H2 Blockers
CCMDB tab: Pharm
Table: L_Log table
Data type: boolean
Length: not stated
Program: CC
Created/Raw: Raw
Start Date: 2012-01-01
End Date: 2300-01-01
Sort Index: 120

True if drug in field name was given

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


Drugs included in this are:

  • ranitidine (zantac)
  • famotidine (pepcid)
  • cimetidine (tagamet)
  • nizatidine (tazac)
  • SMW

Not set up, use Cargo

  • Cargo


Related articles

Related articles:

pharm_furosemide

Data Element (edit)
Field Name: pharm_furosemide
CCMDB Label: (D5)furosemide cont inf
CCMDB tab: Pharm
Table: L_Log table
Data type: boolean
Length: not stated
Program: CC
Created/Raw: Raw
Start Date: 2012-01-01
End Date: 2300-01-01
Sort Index: 121

True if drug in field name was given

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


Drugs included in this are:

  • Lasix
  • SMW

Not set up, use Cargo

  • Cargo


pharm_heparin_sq

Data Element (edit)
Field Name: pharm_heparin_sq
CCMDB Label: (A5)Heparin SQ
CCMDB tab: Pharm
Table: L_Log table
Data type: boolean
Length: not stated
Program: CC
Created/Raw: Raw
Start Date: 2012-01-01
End Date: 2300-01-01
Sort Index: 122

True if drug in field name was given

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See Pharmacy collection for collection info.

pharm_LMWH

Data Element (edit)
Field Name: pharm_LMWH
CCMDB Label: (A7)LMWH
CCMDB tab: Pharm
Table: L_Log table
Data type: boolean
Length: not stated
Program: CC
Created/Raw: Raw
Start Date: 2012-01-01
End Date: 2300-01-01
Sort Index: 123

True if drug in field name was given

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


Drugs included in this are:

  • dalteparin (fragmin)
  • enoxaparin (Lovenox)
  • tinzaparin (innohep)
  • nadroparin (fraxiparin)
  • SMW

Not set up, use Cargo

  • Cargo


pharm_benzodiazepines

Data Element (edit)
Field Name: pharm_benzodiazepines
CCMDB Label: (B4)benzodiazepines cont inf
CCMDB tab: Pharm
Table: L_Log table
Data type: boolean
Length: not stated
Program: CC
Created/Raw: Raw
Start Date: 2012-01-01
End Date: 2300-01-01
Sort Index: 124

True if drug in field name was given

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


Drugs included in this are:

  • Alprazolam (Xanax®)
  • Clobazam (Onfi®, Sympazan®)
  • Clonazepam (Klonopin®
  • Clorazepate (Tranxene®)
  • Diazepam (Diastat®, Valium®, Valtoco®)
  • Estazolam (ProSom®)
  • Flurazepam (Dalmane)
  • Lorazepam (Ativan®, Loreev®)
  • Midazolam (Nayzilam®, Seizalam®, Versed®)
  • Oxazepam (Serax®)
  • Quazepam (Doral®)
  • Remimazolam (Byfavo®)
  • Temazepam (Restoril®)
  • Triazolam (Halcion®)
  • SMW

Not set up, use Cargo

  • Cargo


pharm_opioids

Data Element (edit)
Field Name: pharm_opioids
CCMDB Label: (B5)opioids cont inf (not PCA)
CCMDB tab: Pharm
Table: L_Log table
Data type: boolean
Length: not stated
Program: CC
Created/Raw: Raw
Start Date: 2012-01-01
End Date: 2300-01-01
Sort Index: 125

True if drug in field name was given

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


Not PCA. PCA is intermittent.

Drugs included in this are:

  • alfentanil (alfenta)
  • fentanyl (sublimaze)
  • hydromorphone (dilaudid)
  • morphine
  • meperidine (demerol)
  • sufentanil(sufenta)
  • SMW

Not set up, use Cargo

  • Cargo


pharm_propofol

Data Element (edit)
Field Name: pharm_propofol
CCMDB Label: (C1)propofol cont inf
CCMDB tab: Pharm
Table: L_Log table
Data type: boolean
Length: not stated
Program: CC
Created/Raw: Raw
Start Date: 2012-01-01
End Date: 2300-01-01
Sort Index: 126

True if drug in field name was given

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See Pharmacy collection for collection info.

pharm_insulin

Data Element (edit)
Field Name: pharm_insulin
CCMDB Label: (D4)insulin cont inf
CCMDB tab: Pharm
Table: L_Log table
Data type: boolean
Length: not stated
Program: CC
Created/Raw: Raw
Start Date: 2012-01-01
End Date: 2300-01-01
Sort Index: 127

True if drug in field name was given

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See Pharmacy collection for collection info.