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

From CCMDB Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 6: Line 6:
*The delineation of ICU versus Medicine ward records is by the [[Program]] field, which is either "CC" or "Med".  
*The delineation of ICU versus Medicine ward records is by the [[Program]] field, which is either "CC" or "Med".  


=Previously, a single database record represented a patient in a single location.  Thus when a patient moved from ICU to another ICU a new record was begun, and the same for when an IM ward patient moved from place to place (including even moving from teaching to non-teaching).  But this is artificial, because from the patient perspective, such moves are really parts of a single EPISODE of inpatient care.  
== What Constitutes a Single Record of Data ==
*Previously, a single database record represented a patient in a single location.  Thus when a patient moved from ICU to another ICU a new record was begun, and the same for when an IM ward patient moved from place to place (including even moving from teaching to non-teaching).  But this is artificial, because from the patient perspective, such moves are really parts of a single EPISODE of inpatient care.  
*Accordingly, our eventual goal is to have a patient's entire hospitalization be a single record.   
*Accordingly, our eventual goal is to have a patient's entire hospitalization be a single record.   
*But 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 wards in a single hospital being a single record, (b) having direct movement between MICU and SICU at Health Sciences Centre being a single record.
*But 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 wards in a single hospital being a single record, (b) having direct movement between MICU and SICU at Health Sciences Centre being a single record.
Line 22: Line 23:
*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. '''ALLAN NEED ONE HERE''').
*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. '''ALLAN NEED ONE HERE''').


== The Structure of the 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, and 1-to-many linkages.  The master record identifier for all table linkages is the [[D ID field]].
*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, and 1-to-many linkages.  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.
*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.

Revision as of 16:08, 2021 October 27

Welcome to the external user's portal for the Manitoba Critial Care and Internal Medicine Ward Databases. Updated October 27, 2021.

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 (MICU, SICU and Intermediate ICU [IICU, a chronic ventilator unit]), St. Boniface Hospital (MSICU, Cardiac Surgical ICU, CCU), and Grace Hospital (MSICU).
    • 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.
  • 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 in a single location. Thus when a patient moved from ICU to another ICU a new record was begun, and the same for when an IM ward patient moved from place to place (including even moving from teaching to non-teaching). But this is artificial, because from the patient perspective, such moves are really parts of a single EPISODE of inpatient care.
  • Accordingly, our eventual goal is to have a patient's entire hospitalization be a single record.
  • But 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 wards in a single hospital being a single record, (b) having direct movement between MICU and SICU at Health Sciences Centre being a single record.

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 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 in Indicators. 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. ALLAN NEED ONE HERE).

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, and 1-to-many linkages. 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, for that record it may include 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. The types of data included can be found in Projects.