Data User Portal for the Manitoba Critical Care and Medicine Databases: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
Line 12: Line 12:
*Previously, a single database record represented a patient under the care of a single ICU service, regardless of physical location.  Thus when a patient moved from one ICU servie to another (e.g. MICU to SICU at HSC) a new record was begun, and the same for when an IM ward patient moved from service to service (including even moving from teaching to non-teaching and vise versa).  But this is artificial, because from the patient perspective, such moves are really parts of a single ''episode'' of inpatient care.  
*Previously, a single database record represented a patient under the care of a single ICU service, regardless of physical location.  Thus when a patient moved from one ICU servie to another (e.g. MICU to SICU at HSC) a new record was begun, and the same for when an IM ward patient moved from service to service (including even moving from teaching to non-teaching and vise versa).  But this is artificial, because from the patient perspective, such moves are really parts of a single ''episode'' of inpatient care.  
*Our eventual goal is to have a single record include all such changes and comprise all direct ICU-to-ICU changes (and all ward-to-ward changes) even across different Winnipeg hospitals.  We are not there yet though.
*Our eventual goal is to have a single record include all such changes and comprise all direct ICU-to-ICU changes (and all ward-to-ward changes) even across different Winnipeg hospitals.  We are not there yet though.
*Beginning 10/1/2020 for Grace Hospital, and 10/15/2020 for Health Sciences Centre and St. Boniface Hospital, we moved part-way in this direction by: (a) having all moves within IM ward services in a single hospital be a single record, (b) having direct movement back and forth between MICU and SICU at Health Sciences Centre being a single record. See [[PatientFollow Project]] for details on the transition.
*Beginning 10/1/2020 for Grace Hospital, and 10/15/2020 for Health Sciences Centre and St. Boniface Hospital, we moved part-way in this direction by: (a) having all moves within IM ward services in a single hospital be a single record, (b) having direct movement back and forth between MICU and SICU at Health Sciences Centre being a single record. See [[PatientFollow Project]] for details on the transition.  Thus, the period on any of these ICU services: IICU at HSC, ICMS as St. B, CICU at St. B, and the ICU at Grace Hospital --- is represented in a single record in the database.


== Using this Wiki ==
== Using this Wiki ==

Revision as of 11:36, 2021 November 10

Welcome to the external user's portal for the Manitoba Critical Care and Internal Medicine Ward Databases. Updated 2021-11-10.


You will probably want Database Request Process, but not sure where in here.

  • SMW


  • Cargo


  • Categories

Brief History

  • Using identical data structure, and stored together, these data include two aspects of inpatient medicine:
    • The ICU database (ICUDB) began in 1988, including the Medical ICU and Surgical ICU at Winnipeg Health Sciences Centre. Starting in 1998 it has included all adult ICUs in the Winnipeg Health Region of the province of Manitoba. The number of the number of hospitals containing adult ICUs, the number of adult ICUs, and the number of beds within the ICUs have fluctuated over time. As of October 2021 it includes ICUs in 3 Winnipeg hospitals: Health Sciences Centre (HSC MICU, HSC SICU and Intermediate ICU [IICU, a chronic ventilator unit]), St. Boniface Hospital ( MSICU, Cardiac Surgical ICU, CCU), and Grace Hospital (MSICU). See Database Anniversary Dates for start dates of specific units.
    • The Internal Medicine Ward database (IMWDB) began in 2003, including such wards in hospitals within the Winnipeg Health Region. The number of wards included increased over time and starting January 2005 includes all Internal Medicine wards in Winnipeg hospitals. See Database Anniversary Dates for start dates of specific wards.
  • The delineation of ICU versus Medicine ward records is by the Program field, which is either "CC" or "Med".

What Constitutes a Single Record of Data

  • Previously, a single database record represented a patient under the care of a single ICU service, regardless of physical location. Thus when a patient moved from one ICU servie to another (e.g. MICU to SICU at HSC) a new record was begun, and the same for when an IM ward patient moved from service to service (including even moving from teaching to non-teaching and vise versa). But this is artificial, because from the patient perspective, such moves are really parts of a single episode of inpatient care.
  • Our eventual goal is to have a single record include all such changes and comprise all direct ICU-to-ICU changes (and all ward-to-ward changes) even across different Winnipeg hospitals. We are not there yet though.
  • Beginning 10/1/2020 for Grace Hospital, and 10/15/2020 for Health Sciences Centre and St. Boniface Hospital, we moved part-way in this direction by: (a) having all moves within IM ward services in a single hospital be a single record, (b) having direct movement back and forth between MICU and SICU at Health Sciences Centre being a single record. See PatientFollow Project for details on the transition. Thus, the period on any of these ICU services: IICU at HSC, ICMS as St. B, CICU at St. B, and the ICU at Grace Hospital --- is represented in a single record in the database.

Using this Wiki

  • This Wiki is the master source of all information about these databases. These databases have experienced a continuous evolution over time, with numerous changes in what is collected, how it is collected, and how it is stored. Discontinued, "legacy" items are indicated as such in the Wiki.
  • Consequently, the Wiki is highly complex.
  • We have divided this introductory portal page for external users into 2 segments, which overlap:
    • The first segment will help you understand the data contained within the databases
    • The second segment addresses the actual structure of how the data is stored

Understanding the Data Elements

  • Many, but not all of the conceptual data elements are stored in their own, named data field. Those that do have their own fields are listed in Auto Data Dictionary.
  • The others are listed either in Projects or Indicators or Created Variables CC table. Extracting some of these concepts requires taking multiple individual data elements and combining them.
  • Also note that while there are many data elements common to the ICU and Medicine databases, there are some elements that are only obtained for ICU patients (e.g. TISS elements, and some that are only obtained for the IM ward patients (e.g. ADL) Note that Wiki pages for any data element says explicitly whether it's included in the ICU and/or Medicine ward data.

How the Data is Stored

  • Although once upon a time this was a single "flat table", it is now a relational database including many separate data tables linked together, including 1-to-1 linkages, 1-to-many linkages and the Entity–attribute–value model of the L Tmp V2 table. The master record identifier for all table linkages is the D ID field.
  • The master list of all included tables can be found in: CCMDB_Data_Structure. Clicking on any of the tables in that Wiki page will take you to it's own page, which includes what data is contained in it.
  • Many data elements containing categories of information are coded. Example: for the discharge location (disposition) field Dispo what is stored is not words (e.g. home, other hospital, death etc) but numbers. The tables holding the translation for such codes are "S-tables", which are listed in the "support tables" item in CCMDB_Data_Structure.
  • One of the hardest tables to comprehend is L_TmpV2 table which we often refer to as the "temp table".
    • While each entry into this table links to a single database record, a single record can have any number of entries in this table, and furthermore, those entries may contain a variety of different types of data. Each entry includes some variables that identify the nature of the data element stored in that entry, and then the element itself. See Entity–attribute–value model of the L Tmp V2 table for more info on this data model. The types of data included can be found in Projects.

Related articles

Related articles: