A Database to Support Development
And Evaluation of Intelligent Patient Monitoring
by
Christine Lieu
Submitted to the Department of Electrical Engineering and Computer Science
in Partial Fulfillment of the Requirements for the Degrees of
Bachelor of Science in Electrical [Computer] Science and Engineering
and Master of Engineering in Electrical Engineering and Computer Science
at the Massachusetts Institute of Technology
MASSACHUSETTS INSTITUTE
OF TECHNOLOGY
May 24, 2002
JUL 3 1 2002
Copyright 2002 Christine Lieu. All rights reserved.
LIBRARIES
The author hereby grants to M.I.T. permission to reproduce and
distribute publicly paper and electronic copies of this thesis
and to grant others the right to do so.
Author_
Department of Electrical Engineering and Computer Science
May 24, 2002
Certified
by
Roger G. Mark, M.D., Ph.D.
Distinguished Professor in Health Sciences and Technology, HST
Professor of Electrical and Bioengineering,
Department of Electrical Engineering and Computer Science, MIT
Thesis Supervisor
Accepted
by
Arthur C. Smith
Chairman, Department Committee on Graduate Theses
A Database to Support Development
And Evaluation of Intelligent Intensive Care Monitoring
By Christine Lieu
Submitted to the Department of Electrical Engineering and Computer Science
May 24, 2002
In Partial Fulfillment of the Requirements for the Degree of
Bachelor of Science in Computer Science and Engineering
And Master of Engineering in Electrical Engineering and Computer Science
Abstract
Advances in medical observation equipment have allowed hospital caregivers to
collect a wealth of information about a patient's condition. Automated data collection
systems make it easy to store multiple clinical notes, lab results, and physiological
waveforms electronically. Organizing this data and making it useful to researchers is
a complex problem that requires a solution that is easily accessible, intuitive to use,
and versatile. The major aim of this project is to develop a framework for the
automated acquisition of patient data from clinical information systems and patient
monitors, and the subsequent storage, indexing, and presentation of patient records
using web and relational database technologies.
Thesis Supervisor: Roger G. Mark, M.D., Ph.D.
Distinguished Professor in Health Sciences and Technology, HST
Professor of Electrical and Bioengineering,
Department of Electrical Engineering and Computer Science, MIT
2
1
Problem Statement
Researchers in intelligent patient monitoring need large amounts of data to test and
validate hypotheses about patient care. The data test set must be sufficiently large
to ensure that results are not the artifacts of a specific group of patients, and that
hypotheses can be applied to the general patient population. One scientist notes that
data collection is one of the most complex and resource-intensive stages in clinical
research. He writes, "One of the difficulties facing researchers in clinical informatics
has been 'getting the data in.' In particular, the costs of acquiring detailed and
structured data from the clinical care process have been daunting."i
Advances in patient care monitoring have allowed physicians to track an Intensive
Care Unit (ICU) patient's physiological state more closely and with greater accuracy.
Modern computerized clinical information systems can take information from multiple
data sources and store it in a central location. To be useful to researchers, the data
collected from patient monitors and clinical information systems must be indexed
and presented in a user-friendly interface. It should be searchable so that
researchers studying a specific problem or pattern can locate relevant records.
This paper describes a utility, called MIMIC, which uses a relational database to
organize real patient data and makes it widely available to the general research
community. The MIMIC (Multi-parameter Intelligent Monitoring for Intensive Care)
database takes advantage of the data collection systems installed at a partner
hospital to collect large numbers of real patient records. This utility also organizes
the data and makes it searchable on multiple dimensions and provides an intuitive
user interface to view and browse data.
3
2 Background
Our partner hospital uses the CareVue Clinical Information System, developed by
Philips Medical Systems 2, to store clinical data in its ICU units. Each patient's room
and nursing station is equipped with a CareVue terminal where nurses may enter
notes, medications information, fluid balances, and more. CareVue also stores and
collects data from other sources, such as bedside monitors and results from lab
tests. The data collected by CareVue is also stored in the hospital's Information
Support Mart (ISM), which is built around Oracle database technology.
WaveformTe
Collection
System
p rt o
MIMIC
emwaveform
Data
"
""
CareVue
Terminal
ICU Roo
ICU Room
CareVue
Central
Repository
mimic
Figure I DataCollection at the PartnerHospital
The data in the ISM includes nursing notes, medication dosages and durations, fluid
balances, and vital signs. Real-time waveform data, such as blood pressure, pulse
oximetry, and ECG signals, are recorded in bedside monitors and collected in a
separate system that is not connected to CareVue.
We have access to the data stored in the ISM and the data collected in the waveform
4
collection system. The CareVue system ISM system is presently connected to 42 ICU
beds, which in a year can collect more than 15,000 patient days' of records.
3 Current Research
There are currently several alternate solutions to the problem of collecting and
organizing real patient data for research. Many are targeted toward solving specific
research problems, while others have less complete data or are not yet published.
3.1
Previous Solutions
MIMIC1 3 is a small-scale set of records that provides some support for research in
intelligent patient monitoring for ICU patients. MIMIC1 was developed by George
Moody and Roger Mark and is stored in Microsoft Access and contains data from the
same partner hospital's ICU. It contains only about 100 records and was entered
manually from paper records, leaving room for inconsistencies and errors. MIMIC1
contains both waveforms and clinical data. It provides search capabilities and a neat
user interface but is severely limited by the lack of automated data collection.
MIMIC1 is the precursor to the solution described in this paper.
3.2
Other Databases
Clinical Informatics is an exciting area that has made many advances in recent
years. This section describes other available databases of clinical data.
One interesting solution being explored by the Medical Informatics group at Columbia
University is to create an online support system based on a set of common clinical
questions.
"The aim of this study was to examine a method for creating an online support system for
developers of a clinical information system (CIS) from existing documentation and
question-answer exchanges (Q-A's). A question answer exchange consisted of a user's
question and an expert's corresponding answer. The study was motivated by the need to
improve online support systems for system developers using locally developed programs
within complex information systems. "
5
This is an innovative approach to a similar problem but lacks the flexibility of being
able to answer questions not included in a pre-determined set of frequently asked
questions.
The IMPROVE (Improving Control of Patient Status in Critical Care) 5 database was
constructed from records from intensive care patients in Kuopio, Finland. IMPROVE
stores comprehensive records, including ECG waveforms, hemodynamics, respiratory
signals, lab tests, and annotations for 59 patients. For this project, a "physician
observed the patient state and monitored signals online and annotated any changes
in patient state or possible external causes for artifacts." 5 This provides useful
information that would be missing if annotations were made afterwards, but requires
extra effort by clinicians. IMPACT stores detailed records for ICU patients, but needs
more records to be useful in clinical research.
There are many clinical databases that have been developed to support research in a
specific problem. The HIV Information Infrastructure Program is developing a Central
Research Database (CRD) to record clinical data on HIV patients. The CRD will
"provide HIV researchers with access to real-time clinical data on a large number of
patients, creating unprecedented research opportunities."
6
The CRD provides are
similar to but are targeted toward HIV and AIDS patients.
There are several other databases similar to the CRD and the FAQ. The Penguin
project 7 at Stanford is a database intended to support biomedical applications for
experimental data. The University of Virginia is developing an Echocardiogram data
collection system' to build up a database of records to support research) Duke
University's Clinical Informatics group is working on TMR (The Medical Record) 9 that
6
provides a solution to the problem of organizing and indexing patient records, but it
is in early stages of development. The MGH/MF Waveform Database5 is a collection
of ECG and hemodynamic waveforms, annotations, and relevant clinical data that
was collected from the Massachusetts General Hospital. The MGH project is only a
waveform database, so it does not process trends or contain other supporting data.
4 Solution
Our solution distinguishes itself from other currently available databases and search
engines by providing real high-quality patient data that is searchable through a
general-purpose search engine. It is different from other databases that were
created for research in only a specific problem, or lack search capabilities or data
collection facilities.
MIMIC is a utility that uses relational database technology to organize and index
large amounts of multidimensional patient data. The MIMIC RDBMS (Relational
Database Management System) is used to administer this database and create table
definitions. Data can be downloaded from the hospital's ISM and entered into the
MIMIC database. Once the MIMIC database is populated, the MIMIC Application
dynamically generates HTML pages that allow any researcher with a web browser to
access the records stored in MIMIC. The MIMIC application also provides search
capabilities on multiple dimensions and presents records in an intuitive interface.
The use of real patient data from the partner hospital and the development of this
project were approved by the Institutional Review Board (IRB), a review board for
clinical research studies. Since it is not feasible or convenient to request patient
consent for all data collected in the CareVue system, approval to archive the data
was contingent on removal of all patient identifiers from the database. The de-
7
identification measures are described in detail in Section 12.2.
5 Design Requirements
To useful in a research context, MIMIC needs to scale to large numbers of records. It
should take advantage of data collection resources at the partner hospital as a
source of data. The following sections describe other design ideals and requirements
specified for this project.
5.1
Provide Easy Access
MIMIC should be easily accessible to researchers. Scientists seeking real patient data
should not have to download the entire database or install specialized software to
view records. Instead, MIMIC is intended to be immediately available to any
researcher, free of charge, and have the flexibility to be useful for a wide range of
research problems.
5.2
Protect Patient Confidentiality
The partner hospital allows MIMIC access to its ISM under the condition that all data
in MIMIC must be sanitized to protect patient identities. "The Hippocratic oath
incorporated the principle of medical confidentiality into doctors' professional
ethics." 8 MIMIC has the responsibility of de-identifying the data so that patients are
not identifiable by the records available in the MIMIC database. Patient records often
contain identifiers such as names, phone number, Social Security Number (SSN),
Medical Record Number (MRN). These must be removed from patient records before
they are added to MIMIC.
5.3
Data Accuracy
MIMIC must assure that data is downloaded and displayed accurately. "If information
is corrupted, clinicians may take incorrect decisions which harm or even kill patients.
If information is unreliable, in the sense that it could have been corrupted, then its
8
value as a basis for clinical decisions is diminished."' 0 In order to be useful, the data
in MIMIC must be accurate. Because the data in MIMIC is collected from the primary
source, a higher level of accuracy is achieved than databases that require
transcription from paper records.
6 Overall Architecture
The MIMIC utility
consists of two major
parts: the RDBMS
and the application.
The MIMIC server
refers to the machine
MIMIC
Database
(Postgre)
Browsing
Users
- - -
-
------ -- -
-
-
--
- - - --
-
-
- - ---
on which these parts
reside. MIMIC utilizes
the hospital's ISM is
e
Hospital
ISM*
(Oracde)
Text data files
the source of data.
There are also other
.......-- . . .
-.....
. -.-.
-.
7.GETT! G'THE DA IA
Figure2: Architecture of MIMIC
minor components to
MIMIC and modules that support MIMIC, that select, de-identify, parse, and upload
new data. These modules are described in more detail in the following sections.
7 Tools
A Postgres relational database was chosen for the MIMIC database because it is
open-source and free of charge. AOLServer is used for the MIMIC Application
because it has been successfully used with Postgres to create large-scale databasebased web sites". The Tcl scripting language is used to dynamically generate HTML
pages and interface the web server and database.
9
-
8 Data Collection
As described in Section 2, the partner hospital has 42 Intensive Care Unit (ICU) beds
in that are presently connected to the CareVue system. Nursing notes, medications,
fluid input and output, updates to patient charts, lab results, and more are stored in
the CareVue System. Waveforms such as ECGs, blood pressure, and pulse oximetry
are stored in a separate waveform collection system. MIMIC downloads clinical data
from the hospital ISM and stores it in a new database, the MIMIC database.
Waveform data is downloaded from the waveform collection system at the hospital
and stored in a separate database, which is the waveform counterpart to MIMIC.
System
mimic
CareVue
rI
J :
Unifiedz
MI
Research Lab
os-
al
Figure3 MIMiC and Data Collection
In the future, these two projects will be merged to create a unified utility to view and
search through clinical and waveform data.
9 Types of Users
Two classes of users will interact with MIMIC. Regular users include normal
researchers who are looking for interesting data to support their research.
Administrators will generally have some technical knowledge, be familiar with the
Administrator's manual for MIMIC (see Appendix E) and have administrative
privileges on the MIMIC Server. Administrators have access to the MIMIC RDBMS
and are able to upload new data.
10
10 MIMIC RDBMS
The MIMIC RDMS allows administrators to create,
update, and administer the Postgres relational
database that stores records for MIMIC. It provides
a user interface to access the database without
Dta
RDM
Figure 4 The MIMIC RDBMS
requiring the user to know SQL or specific data
models. The MIMIC RDMS itself consists of a few metadata tables that store the table
definitions and a set of Tcl pages that modify and display table definitions. The
complete data models for these metadata tables appear in Appendix A
10.1 Managing Tables
The MIMIC RDMS allows users to define tables and columns within tables and specify
how they are used and displayed. Users can specify the database data type for the
entry, i.e. integer or varchar (100). The field for extrasql can be used to
specify whether this column references another table. An order sort key is used to
order the elements in a table. Administrators can also specify whether the column
should be included in the text search, and whether the column should be hidden.
Once the tables are defined, users can use the MIMIC RDMS to generate SQL CREATE
TABLE
and DROP TABLE statements. These scripts can be cut and pasted into
Postgres to perform these operations. This process is described in step-by-step detail
in the Administrator's Manual in Appendix E.
11
Add ma Elaored to test-tble
SQL CQd TWide
Please enie, the followingfibl
You aq cut mad pasta the Edftlw
deeothat
a eleee (oohnn) oftert table
Pireae
"annmet for tesd-table
to creat dae tcsLjAbe table.
table (Lchartite
lbelo
beseslo(.10
Names
Abstract
Doletatp
of hotrn
te.ewaw(200)-v%1egcc'
Datasypa
e melchr(20)**mtrde
EVIVa SQL
one column
ieae'wbs(to).
aceraeyt
iee
e i el
ae~3t
roedt "'check foobp
Co bo
twe Tor fret coltuto
Owe
osogsy
oot~eoryO '.orob~ctatt
hcuI~
-
Emery
Emosaaas
Teext Speh
VacbsoISZ).
var~c~(S2t,
boclean-uoser,
Dats atyp
OrereSor
Ke
cat*"ct"
Gat.gocyb
"
Figure 5 CreatingTable Definitions
10.1.1 MIMIC Table Definitions
There are currently 34 table definitions entered into the MIMIC RDBMS. These are
based on the CareVue ISM data models. There are slight differences between the
data types defined in ISM and those used for MIMIC due to differences in Postgres
and Oracle. The values entered for these tables can be found in Appendix B.
The ISM classifies tables into two types: dimension tables and fact tables.
Dimension tables "provide details around the who, what, where, and how of the
data."
2
For example, the d-patients table contains the patient's sex, dob, and a
database-generated pid (patient ID). Other tables that chart patient data will contain
a value for the pid of the patient.
Fact tables are used to "contain the raw data charted in <the> CareVue system.
These properties contain the actual values being charted. The fact table also contains
other properties which point to dimension tables."8 In general, dimension tables are
used to support fact tables and fact tables contain patient data. MIMIC stores both
types of tables.
12
10.2 Managing Indexes
The MIMIC RDMS also includes a module to create and modify table indexes. SQL
indexes are used to improve the performance of common queries. Indexes can be
created on a column or a collection of columns in a table based on the structure and
usage of data. Users are able to use the MIMIC RDMS to define indexes and generate
SQL CREATE INDEX and DROP INDEX statements. A list of indexes created for MIMIC
tables can be found in Appendix C.
10.3 Creating Views
A SQL view is used to provide an additional layer of abstraction between the way
data is presented and its underlying data structures. MIMIC uses views to present
data in a form that is intuitive to the user. For instance, tables that use an Item ID to
reference a value in a dimension table will contain numerical values. However, the
view created for this table (named viewfortablename in MIMIC) will replace Item
Ids with their corresponding text. Views are automatically generated based on table
definitions and created and dropped at the same time as tables.
Postgres does not support materialized views, but their capability is imitated through
creating of tables that act as views. When new data is entered into mimic, these
table views are dropped and re-created to assure that new data is included.
13
itemid
36
loitem Id
42
42
42
Itemid
36
36
36
charttime
10/1/2001 1:00
10/1/2001 1:00
10/1/2001 1:00
Itemid
label
Morphine Sulfate
1
42
amount
100
100
100
label
D5W 100.Oml +
100mg Morphine
Sulfate
1
loitem ld
D5W 100.Oml +
100mg Morphine
Sulfate
10/1/2001 1:00 Morphine Sulfate
D5W 100.Oml +
100mg Morphine
Sulfate
10/1/2001 1:00 Morphine Sulfate
D5W 100.Oml +
charttime
dose units
mg
mg
mg
Itemid
route
IV Drip
IV Drip
NVDrip
culd
2
12
amount dose units route
culd
1
1
2
id
936
1092
1759
unitname
MICU-A
SICU
culd
cgld
100
mg
IV Drip MICU-A 936
100
mg
IV Drip MICU-A 1092
100
mg
IV Drip MICU-A 1759
100mg Morphine
10/1/2001 1:00 Morphine Sulfate
Sulfate
Figure 6 Sample View Createdfor the Additives Table
10.4 More Metadata
In addition to the metadata defined in the table creation process, the MIMIC RDMS
also uses other metadata for managing and displaying tables.
10.4.1 Display Keys
A Display Key for a table is the column that should be used as a label for this table.
In some views where only one column for a table is displayed, this label is used. For
example, in the dmeditems table, the label is the display key. Other tables will
reference the dmeditems table. When it does, the label for dmeditems is used to
display that value.
10.4.2 Time Keys
Time Keys are used to select and order data. These are generally columns with the
timestamp
data type. Each fact table is ordered by a time key so that results can be
displayed in chronological order.
14
10.4.3 Date Keys
Date Keys are also used to select and order data. These are columns with integers
that denote which day the item was stored. These date keys reference the ddays
table, which has entries for every day from January 1, 1970 to December 30, 2030.
Date keys are helpful in finding records for a specific day.
10.4.4 Menu Keys
Menu Keys are used in displaying data in a menu fashion. Administrators can
specify a column for each table and whether this menu key should be visible. This
controls the menus that are displayed to normal users. For instance, the Total
Balance Events table has Item ID as its menu key. This means that the values of this
column are available as menu options. One value for an Item ID is '24 Total Out.' A
user could click on this item to view only entries in the column with that menu value.
For this example, the result would be a table of only '24 Total Out' entries. Figure 13
shows and example of a menu for a table.
Current values for the keys described above can be found in Appendix D. These can
be modified and managed using the key management module in
/ server-path/admin/mimic /keys.
11 Data Extraction and Migration
This section describes the process of obtaining new data from the hospital system for
upload to MIMIC. MIMIC uses a simple ETL (extract, transform, and load)
architecture to add new data to the database.
11.1 Connecting via CareWeb
We obtain access to the hospital's data collection system by connecting remotely via
a virtual private network (VPN). In this way we are able to access the hospital's ISM
without having to be on-site. MIMIC contains records only for those patients who
15
have been discharged from the ICU, to assure that each record is a complete picture
of a patient's stay.
11.2 Choosing Records for Download
Data is chosen to be included in MIMIC based on available waveform data. Another
project, the waveform counterpart to MIMIC, computes wavelet coefficients for
analysis and trending. MIMIC is intended to complement that project by organizing
clinical records for the patients with corresponding waveforms. Data is chosen to be
included in MIMIC based on the waveform data that is collected and processed.
11.3 Extracting Data
To extract data from the hospital system, a user needs administrative privileges on
MIMIC, a web browser (such as Netscape), access to the MIMIC Server, access to the
hospital ISM (Oracle), and a list of patients. The list of patients should be in the
form:
case-idl last name
lfirst
namelMRN
The MRN is optional. An example appears below.
35511 LADEN JOSEPHI
35491STEELEIREMINGTON112428752
35461 FIELDSIANDREWI
35411COLE KENNETHI
35421 PIERFORIANTHONYI
35451YOUSEFFIANITHOMAS1 35408266
35641WALDEN LAMARI
3565 GARCIA ANDY
This file is then uploaded in the data update page to generate a script to extract
patient IDs for these patients. Patient IDs are integers used in the ISM as private
keys for each patient. Patient IDs are not associated with MRN or any other
identifying information for the patient and are only used internally.
With this list of Patient IDs, another script is run on the hospitals Oracle system to
extract data for these patients.
16
11.4 Reading from the Legacy Format
Postgres and Oracle are largely similar, but have a few
differences with respect to data types and how values
connect via
CareWeb .
Hospital
ISM
are formatted. MIMIC uses Oracle's formatting
functions to select data in a format that Postgres can
recognize, based on metadata from table definitions.
For instance, Oracle has one data type for storing
dates, date. The default format for selecting the date
Figure 7 DownloadingData
from the HospitalISM
data type returns a string as 'YYYY-MM-DD.' MIMIC
tables are largely concerned with dates that are associated with times that an event
was charted and use the timestamp type to store these dates. To extract the full
timestamp of a date column in Oracle, we can formulate the select statement to
select the column as a full timestamp. A similar approach can be applied to other
data types to obtain data in the desired format.
Data is downloaded into a plain text file, which takes more time than simply dumping
tables from Oracle, but allows more flexibility in choosing only desired records. This
also prevents having to convert from an Oracle format to one that Postgres can
recognize.
110212001-07-18 22:00:0012001-07-19 18:42:001271111242111011
110212001-08-30 00:00:0012001-09-09 23:00:0012711115780111011
110212001-09-24 14:00:0012001-10-05 21:56:0012711116316111011
110212001-10-10 23:00:0012001-11-01 11:10:0012711130970111011
110212001-07-18 22:00:0012001-07-19 18:42:001311111242111011
110212001-08-30 00:00:0012001-09-09 23:00:0013111115780111011
110212001-09-24 14:00:0012001-10-05 21:56:00131111163161110t1
110212001-10-10 23:00:0012001-11-01 11:10:0013111130970111011
Figure 8 Sample Text Data File
The output is saved as .csv (comma spaced values) files that can later be parsed and
inserted into the MIMIC database. A sample of one of these files appears in Figure 8.
This process also allows us to perform some preliminary de-identification of the data,
17
which is described more in Section 12.2.
11.5 Migration
Since the files containing the data for the new records are large (75 MB for 100
patients), we use ftp to transfer them to the local server before parsing and inserting
into the MIIMC database. The text format of the files avoids compatibility issues with
versions of Oracle or Postgres by avoiding proprietary or database-specified formats.
The data extraction script is generated each time new data is requested so that
updates to data models (table definitions) do not disrupt the data migration process.
12 Adding New Data
Once the data is selected and downloaded from the hospital ISM and written to text
files, these files must be uploaded to the MIMIC database.
12.1 Uploading New Data
When these text files are transferred to the local system, they are ready to be
parsed and entered into the MIMIC
database. The administrator specifies
MIMIC
the location of the data files using the
'atabass
data update page located at
/server-path/admin/mimic/data/.
Text data files
Figure9 UploadingNew Datato MIMIC
The MIMIC server then searches for a
.csv file for each table defined in its data model. If a tablename.csv file exists, the
indexes for that table are dropped in the database to speed the insertion of new
data. More about index management can be found in the Administrator's Manual in
Appendix C. MIMIC reads the text files and creates new files that are formatted
according to the Postgres specification by getting rid of extraneous white space,
18
formatting null values, and putting each row on a separate line. The newly formatted
file overwrites the original file. Once each file is formatted, MIMIC uses a 'COPY'
statement to add that data to the corresponding table. The indexes for this table are
re-created and the update for this table is complete. This process is repeated for
each table defined in the MIMIC RDBMS.
12.2 De-Identification
Part of the de-identification process is built into the data migration process. Much of
the confidential patient information is simply not selected to be in the data files, so
fields such as patient name and caregiver name are not included in the download.
They are part of the hospital's ISM, but not defined for MIMIC.
Another way to protect patient identities is by using a unique key called a patient ID
to identify each patient.
"Unique Patient Identifier eliminates the need for the repetitive use and disclosure of an
individual's personal identification information (i.e. name, age, sex, race, marital status,
place of residence, etc.) for routine internal and external communications (e.g. orders,
results, medication, consultation, etc.) and protects the privacy of the individual. It helps
preserve the patient anonymity while facilitating communication and information
sharing."
13
The pid (patient ID) is assigned by the ISM. New patient IDs are assigned for each
new admission, even for the same patient. MIMIC uses a Case ID to identify patients.
Each patient is assigned a Case ID, and the Case ID is reused for repeat admissions.
The second line of defense for patient de-identification uses a function to replace
patient names before writing the data to a file. This function runs on the hospital
system when new data is being requested and works by looking up the patient name
and replacing any instances of that name with 'patient.' The result is that data files
do not contain any patient names. This function does not make any changes to the
records on the hospital system, but only modifies the results of a query.
19
The resulting data files may still contain some personal information that must be
removed before the new entries can be published. Part of the data upload process
SELECT fullname INTO temp-lastname from d_patients WHERE pid
=
find&pid;
new-string := replace(lower(replace-string),
lower(templastname), patient);
tempnum:=instr(temp_lastname, );
temp_firstname:=substr(temp_lastname, 0, tempnum);
temp-lastname:=substr(temp-lastname, temp-num);
newstring := replace(new-string, temp-firstname, patient );
new-string
replace(new-string, temp-lastname, patient );
Figure 10 Function to Replace Names
includes a script that deletes entries that contain personal information such as
Spokesperson Phone Number and Insurance Number. We have identified 13 such
fields for deletion: "Attending MD", "Spokesperson", "Spokesperson Home Phone #",
"Spokesperson Work Phone #", "Religion", "Martial Status", "Home Phone No.",
"Work Phone No.", "Page Phone No.", "Pt. Name", "PIN", "Cell Phone No.", and
"Account #'.
Some of the free text fields may also contain phone numbers, Social Security
numbers, or medical record numbers. Before new data is uploaded, a script looks for
patterns (for example, a series of numbers of the form xxx-xxx-xxxx) that could be
an identifying number and replaces it.
12.3 Logging
Once all new data has been uploaded and entered into the MIMIC database, the
update is stored in a data log. The log records the date, location of .csv source file,
and the results of the update. This can be useful to administrators in evaluating
when updates were made and outcome of the update.
20
13 The MIMIC Application
Now that the data is loaded into the MIMIC Database, it is ready to be presented to
users. Each patient can have multiple days' worth of data, stored in multiple tables,
each containing thousands of entries. The pages of the MIMIC Application were
designed to provide a unified and intuitive user interface that presents a great deal
of data in a way that is easy to navigate and comprehend.
MIMIC
Database
(Postgres)
Brows n
users
Figure 1] The MIMIC Application
The MIMIC Application consists of .tcl pages that interact with the MIMIC database to
dynamically generate html pages to present to the end user. The MIMIC Application
consists of two main sections: data pages and search pages. The data pages present
patient data in an intuitive and easily browsable manner. The search pages provide
facilities to formulate queries on multiple dimensions.
13.1 General Presentation
In creating a user interface to MIMIC, we tried to keep the design as simple and
utilitarian as possible. The result is a user interface that is clean, compact, and
allows users to browse through records using several different approaches.
13.1.1 Hiding internals
One way MIMIC makes data more easily viewed is by hiding the internals of how
data is stored and accessed. MIMIC includes metadata about whether columns or
categories should be hidden or presented to users. Fields such as caseid or
date-key are numeric values that are meaningless to end-users and have no clinical
21
significance. These are not presented in normal user views. MIMIC also uses SQL
views to decode references to other tables and provide a level of abstraction
between the raw data and a format that is easily understood by the end user.
13.1.2 Utilizing data types (metadata)
Another way that MIMIC improves upon the appearance of raw data is through
utilization of data types stored in metadata. MIMIC uses this metadata to format
data for display. Time stamps are passed through a conversion function to format
them as text instead of ANSI format. Columns that are integers are truncated to
leave out insignificant figures. MIMIC uses time keys to present data in chronological
order. Other keys are used to view data based on category, table, or item type.
These different types of views are described in more detail in the next section.
13.2 Viewing the Data
MIMIC views organize data into three basic views. A patient record can be viewed
by table, which presents the first 25 entries of each table in one page. The record
can be viewed by day, which presents the first 25 entries of each table for that day
in one page. The category view presents the first 50 entries of each table in that
category in one page. It is not reasonable to present more than a few entries for
each table on the same page, so MIIMC presents a limited number from each table
and adds a menu to browse the rest of the entries. In addition to these views, MIMIC
provides the capabilities to concentrate on specific types of data
13.3 Viewing Medications
MIMIC currently uses five different tables to store medications information:
a_medurations,
dmeditems,
solutions,
additives,
and medevents. All
of
these reference the dmeditems table for medication names. The MIMIC Application
includes a medications section to view all medications information for a given
patient, or concentrate on a specific medication for a given patient. This provides a
22
useful summary that can be
used in determining how a
medication was part of a
Paftntrmard for Muphm Swat@s
Thwse an Me recoaftfog p*W
Vou can dso'ic
patient's course of care or how
NN6O and Uapin U~te.
jj
Additives
it affected his prognosis.
O4ol2tM
.
hIoqbi.
SUg.
Moq %Sm
DWW0+W0Ag
JaMW3Y 12.2
Pebruy22,22
Mxqphin
DsWM .z+103g
01mm4
t4W aM-W
MuhIl, 302
patient information reference
0oe.,e,
IV
Maca
Op
1Y
5
Me.phr.304k.
sufa"
13.4 Menus for Browsing
Most of the tables containing
1W
mapesumLbE
M-W
&"
Macphme
"m.i""W"0
V CU
1
DroCM13
M
0tv
U9**,",
D5W|M.
A 936
k8CU A 1W2
IV
D"
+250mgg
174
Med Durations
.
M.ee
O*~w~2g1 316G4Ss4
Octobrw62001 13.0
"
dimension tables for the items
*bZ213
.,
.. 1.. qSto4~a
4 Marph~aSU&Otob
'
D1e 11meO04 hlcOI
373Om
S.a2M I4c.4 U1CUA
Z1W
I""
Figure 13 Viewing Medications
they store. Because they
reference dimension tables, these items are standardized across different entries. A
column that references the dchartitems table will contain multiple entries for the
same
Item ID.
MIMIC utilizes the normal form of this data to create menus to view
and browse all items with the
same Item ID. In practice,
this means this means there
are menus to concentrate on
-
""
Total
But-ance Events Tsbisxt0-25f1
er7ntdeooftis
2a
_Iye ,
tym
P5t
c
[2
T
H
TWtIA
1hutej Q
1 In
day
at
v
s
tnoa
a specific type of entry to a
table. For instance, the Total
IL
0
U
24
1 39
noa
0
33
aau2
0
33013
nn$
0
330
04
Balance Events table has
menus for '24 Total Out' and
users can click on a value to
8.uIsbcr,,
1 20
04
r,02To
00WI3
04
0
2
1
39
In
view all entries for that
specific item for a given
Figure12 Menufor Total Balance Events
patient.
23
21
14 Search
The interesting capabilities in MIMIC lie in the search engine. MIMIC uses an
incremental search to merge the results of criteria on multiple dimensions. This
search allows users to view incremental results at each step of the search.
Incremental search can further help the researcher pinpoint interesting results from
the collection of records stored in MIMIC.
When the user gets to the initial search
page, he can choose to add a search term
--
based on a text search, medications
- --
I
4
a
MIMIC Complex Search
new seach
search, or patient demographics. These
Enter sechtemutoprformacoplexsearchontheMimic
Datbae.
types of searches are described and defined
in more detail in the following sections.
So far:
DateofrBkth:afer1906-Jan-10
Contating Text: AND "SOB" AND
"albuterol"
Once the user enters the search criteria,
Medicadom:ANDHeparin>5U
There we 9 patients in your results
the search terms are sent to be processed.
A,1O3u3 414
4148416742043786.5223 1i48
The user can then see the number of
Figure 14 Search Results
results in MIMIC that satisfy these criteria,
and opt to perform the search or enter additional search terms. When no records
satisfy the search criteria, the criteria are removed from the search and a notification
message appears to the user.
More on these types of searches and a few details about their implementation are
described in the following sections.
14.1 Patient Demographics
The first and simplest search is based on patient demographics, namely age and sex.
Age is specified by denoting a date of birth (DOB) greater than or less than a given
24
date. Obviously, the choices for sex are male or female. All patients in MIMIC have
data for DOB and sex. MIMIC performs searching based on patient demographics by
simply scanning the d-patients table, which contains this information.
14.2 Text Search
One of the options for managing columns in MIMIC is whether the column should be
in included in a text search. In general, this field should be turned on for text fields
that are relevant to the patient record. Only these fields are considered for a text
search.
The text search facility allows users to enter in text search terms and searches free
text for these fields. Users may enter simple logic, such as 'patients AND doctors.
MIMIC parses the input to the text search and searches for these search terms. It
automatically detects key words for logic 'AND' and 'OR' and generates SQL for these
cases.
The design of the text component of the MIMIC Search engine is similar to the
specifications for an early version of the bboard search on http://www.photo.net. It
uses a Tcl ranking function to sort results and presents the most relevant result first.
"It does a simple ranking based on a list of keywords - it is not phrase-based. The
more keywords that are matched, the higher score you get."14 Ranking is based on
items matched for each patient record. For instance, a user may search for Atrial
Fibrillation. A patient whose record contains 5 instances of Atrial and 3 instances of
Fibrillation would receive a score of 8 in the search results.
MIMIC uses a Tcl-based ranking function and SQL 'like' comparison statements to
perform the search. SQL 'like' statements match each element of the input string.
The results are stored and ranked in a Tcl script. In text-only search, results are
25
returned in order of number of relevance. For more complex searches, results are
returned in an arbitrary order based on multiple search terms.
14.3 Medications Search
Medications are stored in the dmeditems table, which helps standardize spelling and
notation associated with medications. Patient records reference dmeditems. itemid
to record that a patient received a medication. Figure 6 shows an example of viewing
medication records. Since we know which tables reference the dmeditems table and
therefore contain medications information, we can limit the medications search to
these tables. Since searching for medications is based on an integer key, it is faster
than a text search because numerical comparison is faster than text comparison.
15 Design Issues
In the course of designing the components of MIMIC, there were many decisions and
tradeoffs considered. In general, design decisions were made according to efficiency
and simplicity.
15.1 Performance
Early versions of the MIMIC Application were extremely slow. Page views took about
6 seconds to load, due to the time to process queries to the database. Most web
users are unwilling to wait more than 2 seconds for a page to load. A great deal of
time was spent on creating indexes to speed up queries and reduce the amount of
time to retrieve data.
Another optimization measure used was to move some of the processing for queries
to the data upload process. When new data is added to the MIMIC database, new
table views are created and updated at the same time. These views perform the
costly JOIN operations needed to generate the materialized user views described in
26
Section 10.3. This increased data upload time up to 100%, but once the data was
processed, page views took 2 seconds. The alternative would be to create simple
SQL views, instead of tables that act as materialized views, and perform the JOIN
operations whenever a page was requested. The data upload process was much
faster, but pages took 6-8 seconds to load. The end decision was to move the JOIN
latency to the upload process to assure that page loads were fast. This makes MIMIC
more convenient for end users who are browsing records, and adds only start-up
costs to adding new data.
A few other approaches to optimization were also considered, including query
caching and warehousing strategies. In the end, a combination of creating indexes,
utilizing integer comparisons when possible, and an ad-hoc version of materialized
views were used to optimize the MIMIC Application.
15.2 Scalability
The MIMIC database will have hundreds of new records every few months. The
partner hospital currently has 42 beds connected to the CareVue system. Over the
course of a year, over 10,000 patient days' worth of data is available to MIMIC.
MIMIC must scale efficiently to handle these records. Relational databases have been
proven to handle scaling to thousands of records efficiently. MIMIC takes advantage
of this by using Postgres for its database.
The MIMIC Application is designed to scale to large numbers of records. The search
engine returns incremental results, but stores only the different search terms.
Storing incremental results for the search (instead of search terms) and recalculating only new terms as they are added becomes more complicated as the
number of records increases. As MIMIC grows to thousands of records, it becomes
27
more efficient to store search terms and perform the entire search at each step.
The user interface for MIMIC was also designed with large numbers of patient-days
in mind. The average stay for an ICU patient can vary greatly, so the user interface
was designed to display varying-length records efficiently. This is achieved through
menus to browse menus and a range of display options.
15.3 Versatility
The difference between MIMIC and similar databases is that MIMIC was not
developed for a specific application or problem. Some similar databases that were
developed for more specific research problems were described in Section 3.2. The
MIMIC database contains all available records from patients in one of the partner
hospital's intensive care units. Data is recorded from multiple data sources and can
be browsed based on medication, type of event, or category. The search utility is
intended to help researchers locate data that is relevant to their research. Unlike
other databases, MIMIC does not target specific problems, but aims to be a generalpurpose source of ICU patient data.
16 Evaluation of Current Design
16.1 De-Identification
The de-identification measures taken in the data upload process assure that no
patient names, phone numbers, medical record numbers, or social security numbers
appear in data for MIMIC. However, MIMIC does not handle other possibly identifying
information, such as doctor names or names of family members. Nursing notes
occasionally contain references to a patient's "sister Mary" or "home in Bedford."
Nursing notes may also contain misspellings that go undetected. MIMIC will replace
"Robert" but will not find "Robret." MIMIC lacks the sophisticated facilities to remove
such information. In future versions, natural language processing algorithms can be
28
applied to solve these problems.
16.2 Scalability
MIMIC currently contains about 300 patients, with a total of over 1,000 patient days.
MIMIC should easily scale to contain several hundred more patients. We are unsure
of how MIMIC will handle tens of thousands of records. The MIMIC server, which is
currently on a machine with a 1500Mhz Athlon AMD processor and 512MB memory,
would have to be upgraded to be a server for thousands of patient records. Once
MIMIC is merged with its waveform counterpart and regular data updates are made
to the MIMIC Database, the database should be backed up regularly and the MIMIC
Server used as a dedicated server for the MIMIC Application.
16.3 Usability
There are many possible additions to MIMIC that would make it more useful to
researchers. Once MIMIC has been merged with its waveform counterpart, complex
trending and analysis of those waveforms can be combined with searches on clinical
records. Currently, MIMIC does not support any conversion of units of measure for
medications searches, due in part to lack of available data. Units conversion may be
possible for future versions of MIMIC.
The display for MIMIC varies slightly across different web browsers. MIMIC was
tested mostly using Internet Explorer, Netscape, and Mozilla. Future versions of
MIMIC could add to the current design by using HTML elements that are displayed
uniformly across different browsers.
16.4 The Future of MIMIC
This project is the second version of an effort to solve the problems or collecting and
organizing real patient data for clinical research. However, there can still be
improvements and functionality added to MIMIC that could improve its value.
29
MIMIC only contains a portion of the data recorded from the ICU. The hospital also
collects discharge summaries, pathology reports, ECG signals, more detailed lab
reports, records for surgeries, X-rays, EEGs, outpatient care, and more. This data is
not currently stored in the ISM, but is stored on other hospital systems. In the
future, we could gain access to their records and add them to MIMIC. The MIMIC
RDBMS would have to be extended to include new table definitions and a different
extraction system to access the hospital information system. The richer content of
the resulting database would widen the range of research problems that MIMIC
supports.
In the future, MIMIC and its waveform counterpart will be integrated into a unified
resource for patient data. New versions of MIMIC could also include more
sophisticated patient de-identification procedures and add different user views. The
search facilities could allow for more complex searches, including searches on
waveform patterns. The current framework for MIMIC leaves the ability to extend to
include these capabilities. Even without these improvements, MIMIC will be a useful
utility to researchers looking for real patient data.
17 Conclusion
MIMIC provides a solution to some of the problems of protecting patient
confidentiality, migrating data to a new server, and presenting data in a usable
interface. It utilizes web and database technologies to create an application that
makes real hospital records available and searchable by researchers. Regular
updates from the hospital ISM will populate MIMIC with real patient data. All of these
elements are combined to create a useful utility for researchers looking for real
patient data.
30
18 Bibliography
Kohane, Isaac "The Imperative to Collaborate" Journal of the American Informatics
Association Volume 7 Number 5 Sep/Oct 2000
2
Product Description for Philips Medical Systems CareVue Clinical Information
System http://www3. medical.philips.com/enus/product home/product/carevuecis detail.asp
3
Moody, George and Mark, Roger "A Database to Support Development and
Evaluation of Intelligent Intensive Care Monitoring" Computers in Cardiology
23:657-660 1996
4 Wilcox, Adam, et al. "Developing Online Support for Clinical Information System
Developers: The FAQ Approach" Computers and Biomedical research, 31 112-121
(1998) Article No. CO 981470
5 Korhonen, Ilkka. vanGils, Mark. Gade, Jon. "The Challenges in Creating Critical
Care Databases" IEEE Engineering in Medicine and Biology May/June 2001
6 The
HIV Central Research Database http://www.ohtn.on.ca/5 central hiip.html)
7
Stanford Penguin Project http://smi-web.stanford.edu/projects/penauin.html
8
"A Model Electronic Patient Record System for Clinical Echocardiography
http://hsc.virginia.edu/hs-library/newsletter/1994/november/echocard.html
9 Duke Medical Informatics Research
http://dmi-www.mc.duke.edu/dukemi/research/research.html
10
Anderson, Ross , "Security in Clinical Information Systems" Computer Laboratory
University of Cambridge - January 1996)
"Greenspun, Philip, "Phil and Alex's Guide to Web Publishing"
http://www.arsdiita.com/books/panda/
CareVue Clinical Data Management Information Support Mart User's Guide.
Agilent Technologies, 2000
12
Unique Patient Identifier
13
http://www.hipaanet.com/upin4.htm
Idea for doing Site-Wide Search
http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msgid=000OSy&topicjid=11
14
31
--
APPENDIX A: Metadata Tables
create table mimic-tableelements (
metadata id
integer
tablename
varchar(21)
column-name
varchar(30)
pretty-name
varchar(100)
abstractdatatype
varchar(30)
oracle-data-type
varchar(30)
extra-sql
varchar(4000)
presentation-type
varchar(100)
presentation-options
varchar(4000)
entry-explanation
varchar(4000)
help-text
varchar(4000)
include-in view-p
char(l)
mandatory-p
char(1)
sort-key
integer
formsort-key
integer
form-number
integer
includeinctxindex-p char(1)
defaultvalue
varchar(200)
order-sort-key
integer
postgresdatatype
varchar(80)
not
not
not
not
not
for display of tables by menu item
create table mimic-item_keys (
table name
varchar(21),
item-key
varchar(30),
includeinview-p
varchar(l)
null,
null,
null,
null,
null,
--
for display
create table mimic displaykeys
tablename varchar(100) primary key,
display-key varchar(100)
not null,
--
data log for updates
create sequence mimicindexessequence;
create table mimicdata log (
integer,
update-id
timestamp with time zone,
enterdate
tablename
filename
filestatus
extrac tkey
extrac tkey-start
extract keystop
insertstatus
character varying(40),
character varying(100),
character varying(400),
character varying(40),
numeric(30,6),
numeric(30,6),
character varying(400)
- for management of indexe
create table mimic-table-categories (
varchar(100) not null,
category-name
cat-pretty-name varchar(100) not null,
description
varchar(400),
include in view-p varchar(l),
order-sort-key
integer
create table
indexname
tablename
columnname
primary key
mimic indexes
varchar(100),
varchar(21),
varchar(30),
(index-name, tablename, column-name)
create table mimic timekeys
tablename varchar(100),
varchar(100)
time-key
create table mimic date keys
tablename varchar(100),
date-key
varchar(100)
32
APPENDIXA: Metadata Tables
category4
category5
category6
APPENDIX B: MIMIC Table Definitions
---
SQL create table statements for all tables
You may cut and paste the following to create tables.
varchar(32),
varchar(32),
varchar(32)
create table d-ioitems
numeric,
itemid
label
varchar(256),
varchar(32),
categoryl
varchar(32),
category2
varchar(32),
category3
varchar(32),
category4
varchar(32),
category5
-tables for Dimensions
create table d-caregivers
cgid
numeric,
employeeno
varchar(20),
varchar(6)
proftitle
category6
create table dcareunits
numeric,
cuid
unitname
varchar(20)
varchar(32)
create table dmeditems
numeric,
itemid
varchar(20),
label
create table d-chartitems
itemid
numeric,
varchar(110),
label
categoryl
varchar(32),
varchar(32),
category2
varchar(32),
category3
varchar(32),
category4
varchar(32),
category5
category6
varchar(100)
categoryl
category2
category3
category4
category5
category6
varchar(32),
varchar(32),
varchar(32),
varchar(32),
varchar(32),
varchar(32)
create table d-outcomeitems (
numeric,
itemid
label
create table d-days
dayid
numeric,
timestamp,
calDay
month
numeric,
numeric,
dayofmonth
numeric,
year
varchar(20),
monthText
numeric,
dayofweek
varchar(20)
holiday
varchar(60),
categoryl
varchar(32),
category2
category3
category4
category5
category6
varchar(32),
varchar(32),
varchar(32),
varchar(32),
varchar(32)
create table d-patients
integer,
caseid
numeric,
pid
varchar(8),
sex
date
dob
create table d-interventionitems
numeric,
itemid
varchar(80),
label
varchar(32),
categoryl
varchar(32),
category2
varchar(32),
category3
create table d&problemitems
numeric,
itemid
33
APPENDIX B: MIMIC Table Definitions
label
varchar(60),
categoryl
varchar(32),
category2
varchar(32),
category3
varchar(32),
category4
varchar(32),
category5
varchar(32),
category6
varchar(32)
create table viewforcensusevents
as select censusevents.oid as oid forcensusevents,
d-patients.caseid, round(censusevents.pid, 0) as pid,
censusevents.intime as intime, censusevents.outtime as outtime,
d_careunits.unitname as careunit, censusevents.careunit as
key-for-careunit, d careunits.unitname as destcareunit,
censusevents.destcareunit as keyjfordestcareunit,
censusevents.dischstatus as dischstatus,
round(censusevents.los, 0) as los, dsources.hospitalname as
sid, censusevents.sid as keyjfor-sid,
round(censusevents.indayid, 0) as indayid,
round(censusevents.outdayid, 0) as outdayid from censusevents,
d-patients, d careunits, dsources where
d-patients.pid=censusevents.pid and
d-careunits.cuid=censusevents.careunit and
d-careunits.cuid=censusevents.destcareunit and
d_sources.sid=censusevents.sid ;
create table d&primarycodes
label
varchar(50),
code
varchar(32),
numeric
pcode
create table d-sources
systemid
numeric,
siteid
numeric,
sourceid
numeric,
schemaRev
numeric,
hospitalname
varchar(60),
addressl
varchar(30),
address2
varchar(30),
varchar(30),
address3
sid
numeric
create table chartevents
pid
numeric,
timestamp,
charttime
timestamp,
realtime
numeric,
itemid
valuel
varchar(110),
numeric,
valuelnum
varchar(20
valueluom
varchar(110),
value2
numeric,
value2num
varchar(20
value2uom
varchar(20),
stopped
varchar (20)
resultstatus
varchar(5 00),
annotation
numeric,
cgid
numeric,
cuid
numeric,
scode
numeric,
pcode
numeric,
chartdate
numeric,
sid
numeric,
elemid
numeric
txid
create table d-secondarycodes
varchar(50),
label
varchar(32),
code
numeric
scode
-tables for Events
create table censusevents
pid
numeric,
intime
timestamp,
outtime
timestamp,
numeric,
careunit
destcareunit
numeric,
varchar(20),
dischstatus
numeric,
los
numeric,
sid
indayid
numeric,
outdayid
numeric
create table view for chartevents
as select chartevents.oid as oid forchartevents,
d-patients.case-id, round(chartevents.pid, 0) as pid,
chartevents.charttime as charttime, chartevents.realtime as
realtime, d-chartitems.label as itemid, chartevents.itemid as
34
APPENDIX B: MIMIC Table Definitions
formevents.subsectiontitle as subsectiontitle,
key for itemid, chartevents.valuel as valuel,
round(chartevents.valuelnum, 2) as valuelnum,
chartevents.valueluom as valueluom, chartevents.value2 as
value2, round(chartevents.value2num, 2) as value2num,
chartevents.value2uom as value2uom, chartevents.stopped as
stopped, chartevents.resultstatus as resultstatus,
chartevents.annotation as annotation, round(chartevents.cgid,
0) as cgid, d careunits.unitname as cuid, chartevents.cuid as
key_forcuid, round(chartevents.scode, 0) as scode,
round(chartevents.pcode, 0) as pcode,
round(chartevents.chartdate, 0) as chartdate,
d_sources.hospitalname as sid, chartevents.sid as keyforsid,
round(chartevents.elemid, 0) as elemid, round(chartevents.txid,
0) as txid from chartevents, dpatients, d chartitems,
d_careunits, d-sources where d-patients.pid=chartevents.pid and
d-chartitems.itemid=chartevents.itemid and
d-careunits.cuid=chartevents.cuid and
d-sources.sid=chartevents.sid ;
d chartitems.label as itemid, formevents.itemid as
keyjfor_itemid, formevents.value_ as value_,
formevents.valuenum as valuenum, formevents.uom as uom,
round(formevents.cgid, 0) as cgid, dcareunits.unitname as
cuid, formevents.cuid as key-for-cuid, round(formevents.scode,
0) as scode, round(formevents.pcode, 0) as pcode,
d_sources.hospitalname as sid, formevents.sid as key-for-sid,
round(formevents.elemid, 0) as elemid, round(formevents.txid,
0) as txid, round(formevents.chartDay, 0) as chartDay,
round(formevents.formid, 0) as formid from formevents,
d_patients, d chartitems, d-careunits, d-sources where
d-patients.pid=formevents.pid and
d_chartitems.itemid=formevents.itemid and
d_careunits.cuid=formevents.cuid and
d-sources.sid=formevents.sid ;
create table medevents
numeric,
pid
timestamp,
charttime
numeric,
itemid
numeric,
elemid
numeric,
chartdate
timestamp,
realtime
numeric,
volume
numeric,
dose
varchar(20),
doseuom
numeric,
solutionid
numeric,
solvolume
varchar(20),
route
varchar(20),
site
varchar(20),
stopped
varchar(500),
annotation
numeric,
cgid
numeric,
cuid
numeric,
pcode
numeric,
scode
numeric,
sid
numeric
txid
create table formevents
numeric,
pid
timestamp,
chartTime
timestamp,
realtime
varchar(40),
formtitle
varchar(40),
sectiontitle
varchar(40),
subsectiontitle
numeric,
itemid
value_
varchar(500),
varchar(100),
valuenum
varchar(20),
uom
numeric,
cgid
numeric,
cuid
numeric,
scode
numeric,
pcode
numeric,
sid
numeric,
elemid
numeric,
txid
chartDay
numeric,
numeric
formid
create table view for medevents as select medevents.oid as
oidfor medevents, d-patients.case-id, round(medevents.pid, 0)
as pid, medevents.charttime as charttime, d-meditems.label as
itemid, medevents.itemid as key-for-itemid,
round(medevents.elemid, 0) as elemid,
round(medevents.chartdate, 0) as chartdate, medevents.realtime
create table viewforformevents as select formevents.oid as
oid for formevents, dpatients.case-id, round(formevents.pid,
0) as pid, formevents.chartTime as chartTime,
formevents.realtime as realtime, formevents.formtitle as
formtitle, formevents.sectiontitle as sectiontitle,
35
APPENDIX B: MIMIC Table Definitions
as realtime, round(medevents.volume, 0) as volume,
0) as elemid, round(noteevents.txid, 0) as txid from
round(medevents.dose, 2) as dose, medevents.doseuom as doseuom,
noteevents, d-patients, d_careunits, d-sources where
d-meditems.label as solutionid, medevents.solutionid as
key-for-solutionid, round(medevents.solvolume, 2) as solvolume,
medevents.route as route, medevents.site as site,
medevents.stopped as stopped, medevents.annotation as
annotation, round(medevents.cgid, 0) as cgid,
d_careunits.unitname as cuid, medevents.cuid as key-forcuid,
round(medevents.pcode, 0) as pcode, round(medevents.scode, 0)
as scode, d-sources.hospitalname as sid, medevents.sid as
keyjfor sid, d secondarycodesl.scode as txid, medevents.txid as
key fortxid from medevents, dpatients, d meditems, d-meditems
d_meditems0, d-careunits, dsources, d-secondarycodes
d-patients.pid=noteevents.pid and
d_careunits.cuid=noteevents.cuid and
d-sources.sid=noteevents.sid
create table resultevents
pid
numeric,
resultid
numeric,
timestamp,
chartTime
chartDate
numeric,
cgid
numeric,
cuid
numeric,
varchar(1000),
resulttext
timestamp,
sourcetime
numeric,
firstresult
numeric,
nextresult
status
varchar(20),
numeric,
sid
txid
numeric
d_secondarycodesl where d-patients.pid=medevents.pid and
d-meditems.itemid=medevents.itemid and
d_meditems0.itemid=medevents.solutionid and
d-careunits.cuid=medevents.cuid and d sources.sid=medevents.sid
and d-secondarycodesl.scode=medevents.txid ;
create table noteevents
pid
numeric,
charttime
timestamp,
realtime
timestamp,
category
varchar(26),
title
varchar(52),
notetext
varchar(4000),
correction
varchar(2),
cgid
numeric,
cuid
numeric,
chartDate
numeric,
sid
numeric,
noteid
numeric,
elemid
numeric,
txid
numeric
create table viewforresultevents
as select resultevents.oid as oid forresultevents,
dpatients.case id, round(resultevents.pid, 0) as pid,
round(resultevents.resultid, 0) as resultid,
resultevents.chartTime as chartTime,
round(resultevents.chartDate, 0) as chartDate,
round(resultevents.cgid, 0) as cgid, d-careunits.unitname as
cuid, resultevents.cuid as keyjfor-cuid,
resultevents.resulttext as resulttext, resultevents.sourcetime
as sourcetime, round(resultevents.firstresult, 0) as
firstresult, round(resultevents.nextresult, 0) as nextresult,
resultevents.status as status, d sources.hospitalname as sid,
resultevents.sid as key_forsid, round(resultevents.txid, 0) as
txid from resultevents, dpatients, d-careunits, d-sources
create table viewfornoteevents as select noteevents.oid as
oidfornoteevents, d-patients.caseid, round(noteevents.pid,
0) as pid, noteevents.charttime as charttime,
noteevents.realtime as realtime, noteevents.category as
category, noteevents.title as title, noteevents.notetext as
notetext, noteevents.correction as correction,
round(noteevents.cgid, 0) as cgid, d careunits.unitname as
cuid, noteevents.cuid as key-for-cuid,
round(noteevents.chartDate, 0) as chartDate,
d_sources.hospitalname as sid, noteevents.sid as keyforsid,
round(noteevents.noteid, 0) as noteid, round(noteevents.elemid,
where dpatients.pid=resultevents.pid and
d-careunits.cuid=resultevents.cuid and
d_sources.sid=resultevents.sid
create table totalbalevents
pid
numeric,
charttime
chartdate
itemid
realtime
pervolume
36
timestamp,
numeric,
integer,
timestamp,
numeric,
APPENDIX B: MIMIC Table Definitions
itemid
numeric,
altid
numeric,
numeric,
volume
varchar(20),
volumeuom
unitshung
numeric,
unitshunguom
varchar(20),
newbottle
numeric,
dressingchanged
numeric,
numeric,
tubingchanged
numeric,
assessment
varchar(20),
stopped
varchar(20),
estimate
varchar(500),
annotation
cgid
numeric,
numeric,
cuid
numeric,
scode
pcode
numeric,
chartdate
numeric,
sid
numeric,
elemid
numeric,
txid
numeric
cumvolume
numeric,
accumperiod
varchar(20),
approx
varchar(10),
reset-p
integer,
varchar(20),
stopped
annotation
varchar(500),
cgid
numeric,
cuid
numeric,
numeric,
scode
numeric,
pcode
numeric,
sid
txid
numeric,
elemid
numeric
create table viewfortotalbalevents
as select totalbalevents.oid as oidfortotalbalevents,
d-patients.case-id, round(totalbalevents.pid, 0) as pid,
totalbalevents.charttime as charttime,
round(totalbalevents.chartdate, 0) as chartdate,
d ioitems.label as itemid, totalbalevents.itemid as
key_forjitemid, totalbalevents.realtime as realtime,
round(totalbalevents.pervolume, 0) as pervolume,
round(totalbalevents.cumvolume, 0) as cumvolume,
totalbalevents.accumperiod as accumperiod,
totalbalevents.approx as approx, round(totalbalevents.reset-p,
0) as resetp, totalbalevents.stopped as stopped,
totalbalevents.annotation as annotation,
round(totalbalevents.cgid, 0) as cgid, d careunits.unitname as
cuid, totalbalevents.cuid as keyjforcuid,
round(totalbalevents.scode, 0) as scode,
round(totalbalevents.pcode, 0) as pcode, d sources.hospitalname
as sid, totalbalevents.sid as key-forsid,
round(totalbalevents.txid, 0) as txid,
round(totalbalevents.elemid, 0) as elemid from totalbalevents,
dpatients, d ioitems, d-careunits, dsources where
dpatients.pid=totalbalevents.pid and
d_ioitems.itemid=totalbalevents.itemid and
d_careunits.cuid=totalbalevents.cuid and
d_sources.sid=totalbalevents.sid ;
--
create table viewfor-ioevents
as select ioevents.oid as oidforioevents, d-patients.case-id,
round(ioevents.pid, 0) as pid, ioevents.charttime as charttime,
ioevents.realtime as realtime, d ioitems.label as itemid,
ioevents.itemid as key-for-itemid, dioitems0.label as altid,
ioevents.altid as keyforaltid, round(ioevents.volume, 0) as
volume, ioevents.volumeuom as volumeuom,
round(ioevents.unitshung, 0) as unitshung,
ioevents.unitshunguom as unitshunguom,
round(ioevents.newbottle, 0) as newbottle,
round(ioevents.dressingchanged, 0) as dressingchanged,
round(ioevents.tubingchanged, 0) as tubingchanged,
round(ioevents.assessment, 0) as assessment, ioevents.stopped
as stopped, ioevents.estimate as estimate, ioevents.annotation
as annotation, round(ioevents.cgid, 0) as cgid,
d careunits.unitname as cuid, ioevents.cuid as key-for-cuid,
round(ioevents.scode, 0) as scode, round(ioevents.pcode, 0) as
pcode, round(ioevents.chartdate, 0) as chartdate,
d sources.hospitalname as sid, ioevents.sid as keyjfor-sid,
round(ioevents.elemid, 0) as elemid, round(ioevents.txid, 0) as
txid from ioevents, dpatients, d ioitems, djioitems
d-ioitems0, d-careunits, d-sources where
d-patients.pid=ioevents.pid and
tables for IOEvents. Solutions, Additives, and Deliveries
create table ioevents
numeric,
pid
charttime
timestamp,
realtime
timestamp,
37
APPENDIXB: MIMIC Table Definitions
numeric,
chartdate
charttime
timestamp,
numeric,
ioitemid
varchar(20),
site
rate
numeric,
numeric,
cgid
cuid
numeric,
numeric,
sid
numeric,
elemid
numeric
txid
d_ioitems.itemid=ioevents.itemid and
d ioitemsO.itemid=ioevents.altid and
d_careunits.cuid=ioevents.cuid and dsources.sid=ioevents.sid
create table additives
pid
numeric,
charttime
timestamp,
chartdate
numeric,
itemid
numeric,
ioitemid
numeric,
amount
numeric,
doseunits
varchar(20),
mperunit
numeric,
route
varchar(20),
cuid
numeric,
cgid
numeric,
scode
numeric,
pcode
numeric,
sid
numeric,
elemid
numeric,
txid
numeric
create table viewfordeliveries as select deliveries.oid as
oidfordeliveries, d-patients.case id, round(deliveries.pid,
0) as pid, round(deliveries.chartdate, 0) as chartdate,
deliveries.charttime as charttime, dioitems.label as ioitemid,
deliveries.ioitemid as key-for-ioitemid, deliveries.site as
site, deliveries.rate as rate, round(deliveries.cgid, 0) as
cgid, d careunits.unitname as cuid, deliveries.cuid as
keyjfor-cuid, dsources.hospitalname as sid, deliveries.sid as
keyfor-sid, round(deliveries.elemid, 0) as elemid,
round(deliveries.txid, 0) as txid from deliveries, dpatients,
d_ioitems, d-careunits, dsources where
dpatients.pid=deliveries.pid and
d-ioitems.itemid=deliveries.ioitemid and
d_careunits.cuid=deliveries.cuid and
dsources.sid=deliveries.sid ;
create table viewforadditives
as select additives.oid as oidfor additives,
d-patients.case-id, round(additives.pid, 0) as pid,
additives.charttime as charttime, round(additives.chartdate, 0)
as chartdate, dmeditems.label as itemid, additives.itemid as
key_forjitemid, dioitems0.label as ioitemid,
additives.ioitemid as keyforioitemid, round(additives.amount,
0) as amount, additives.doseunits as doseunits,
round(additives.mlperunit, 0) as mlperunit, additives.route as
route, d careunits.unitname as cuid, additives.cuid as
keyfor-cuid, round(additives.cgid, 0) as cgid,
round(additives.scode, 0) as scode, round(additives.pcode, 0)
as pcode, d sources.hospitalname as sid, additives.sid as
key_forsid, round(additives.elemid, 0) as elemid,
round(additives.txid, 0) as txid from additives, dpatients,
dnmeditems, d-ioitems d-ioitems0, dcareunits, d-sources where
d-patients.pid=additives.pid and
d-meditems.itemid=additives.itemid and
d_ioitems0.itemid=additives.ioitemid and
d_careunits.cuid=additives.cuid and d-sources.sid=additives.sid
create table solutions
numeric,
pid
timestamp,
charttime
numeric,
itemid
numeric,
ioitemid
numeric,
volume
varchar(20),
doseunits
varchar(20),
route
numeric,
cgid
numeric,
cuid
numeric,
scode
numeric,
pcode
numeric,
chartdate
numeric,
sid
numeric,
elemid
numeric
txid
create table deliveries
numeric,
pid
38
APPENDIX B: MIMIC Table Definitions
create table view-for solutions
as select solutions.oid as
oidfor
problems.itemid as key-for-itemid, problems.charttime as
charttime, round(problems.chartdate, 0) as chartdate,
round(problems.cgid, 0) as cgid, round(problems.addcgid, 0) as
addcgid, dIcareunits.unitname as cuid, problems.cuid as
keyjfor-cuid, problems.startdate as startdate,
problems.stopdate as stopdate, d-days.calDay as dateadded,
problems.dateadded as keyjfor-dateadded,
round(problems.problemnum, 2) as problemnum, problems.status as
status, problems.etiology as etiology, round(problems.scode, 0)
as scode, round(problems.pcode, 0) as pcode,
d sources.hospitalname as sid, problems.sid as key-for-sid,
round(problems.elemid, 0) as elemid, round(problems.txid, 0) as
txid from problems, dpatients, d_problemitems, dIcareunits,
d_days, dIsources where dpatients.pid=problems.pid and
dproblemitems.itemid=problems.itemid and
d&careunits.cuid=problems.cuid and
d&days.dayid=problems.dateadded and dsources.sid=problems.sid
solutions,
d-patients.caseid, round(solutions.pid, 0) as pid,
solutions.charttime as charttime, d meditems.label as itemid,
solutions.itemid as keyjfor-itemid, djioitemsO.label as
ioitemid, solutions.ioitemid as keyforioitemid,
round(solutions.volume, 0) as volume, solutions.doseunits as
doseunits, solutions.route as route, round(solutions.cgid, 0)
as cgid, d-careunits.unitname as cuid, solutions.cuid as
key_forcuid, round(solutions.scode, 0) as scode,
round(solutions.pcode, 0) as pcode, round(solutions.chartdate,
0) as chartdate, d-sources.hospitalname as sid, solutions.sid
as keyjfor-sid, round(solutions.elemid, 0) as elemid,
round(solutions.txid, 0) as txid from solutions, d-patients,
d-meditems, d-ioitems d ioitems0, d-careunits, d-sources where
d-patients.pid=solutions.pid and
d_meditems.itemid=solutions.itemid and
dioitemsO.itemid=solutions.ioitemid and
d_careunits.cuid=solutions.cuid and dsources.sid=solutions.sid
--
create table outcomes
pid
numeric,
itemid
numeric,
charttime
timestamp,
chartdate
numeric,
cgid
numeric,
cuid
numeric,
comments
varchar(600),
targetdate
numeric,
dateadded
numeric,
addcgid
numeric,
evaltime
timestamp,
evalcgid
numeric,
shift
varchar(20),
variancetype
varchar(20),
variancecause
varchar(40),
status
varchar(20),
problem
numeric,
probtime
timestamp,
scode
numeric,
numeric,
pcode
sid
numeric,
elemid
numeric,
txid
numeric
tables for Care Plan/Pathway
create table problems
pid
numeric,
itemid
numeric,
charttime
timestamp,
chartdate
numeric,
cgid
numeric,
addcgid
numeric,
cuid
numeric,
startdate
timestamp,
stopdate
timestamp,
dateadded
numeric,
problemnum
numeric,
status
varchar(60),
etiology
varchar(600),
scode
numeric,
pcode
sid
elemid
txid
numeric,
numeric,
numeric,
numeric
create table view for-problems
as select problems.oid as oid for-problems, dpatients.case-id,
round(problems.pid, 0) as pid, d-problemitems.label as itemid,
create table viewforoutcomes
39
APPENDIX B: MIMIC Table Definitions
as select outcomes.oid as oid for outcomes, dpatients.caseIid,
probtime
round(outcomes.pid, 0) as pid, d-outcomeitems.label as itemid,
guidelinename
outcomes.itemid as keyjfor-itemid, outcomes.charttime as
charttime, round(outcomes.chartdate, 0) as chartdate,
round(outcomes.cgid, 0) as cgid, d careunits.unitname as cuid,
outcomes.cuid as key_forcuid, outcomes.comments as comments,
d-days.calDay as targetdate, outcomes.targetdate as
keyjfor-targetdate, d days.calDay as dateadded,
outcomes.dateadded as key_for_dateadded, dIcaregivers0.cgid as
addcgid, outcomes.addcgid as keyfor_addcgid, outcomes.evaltime
as evaltime, d caregiversl.cgid as evalcgid, outcomes.evalcgid
as keyfor-evalcgid, outcomes.shift as shift,
outcomes.variancetype as variancetype, outcomes.variancecause
as variancecause, outcomes.status as status,
guideline
varchar(2000),
chartstatus
varchar(20),
shift
varchar(60),
variancetype
varchar(20),
variancecause
varchar(40),
scode
numeric,
pcode
numeric,
sid
numeric,
elemid
numeric,
txid
numeric
timestamp,
varchar(80),
create table viewforinterventions
d-problemitems2.label as problem, outcomes.problem as
key-forproblem, outcomes.probtime as probtime,
round(outcomes.scode, 0) as scode, round(outcomes.pcode, 0) as
as select interventions.oid as oidforinterventions,
keyforsid, round(outcomes.elemid, 0) as elemid,
round(outcomes.txid, 0) as txid from outcomes, dpatients,
d_outcomeitems, dcareunits, d days, d-caregivers
dpatients.case id, round(interventions.pid, 0) as pid,
d interventionitems.label as itemid, interventions.itemid as
key-for-itemid, interventions.charttime as charttime,
round(interventions.chartdate, 0) as chartdate,
round(interventions.cgid, 0) as cgid, d careunits.unitname as
d_caregiversO, d caregivers d-caregiversl, d problemitems
cuid, interventions.cuid as keyjfor_cuid,
d-problemitems2, dsources where d-patients.pid=outcomes.pid
round(interventions.ordercgid, 0) as ordercgid,
interventions.ordertime as ordertime, interventions.dateadded
pcode, d-sources.hospitalname as sid, outcomes.sid as
and d outcomeitems.itemid=outcomes.itemid and
d careunits.cuid=outcomes.cuid and
d-days.dayid=outcomes.targetdate and
as dateadded, round(interventions.addcgid, 0) as addcgid,
d-days.dayid=outcomes.dateadded and
key-for-targetdate, interventions.instructions as instructions,
d_caregiversO.cgid=outcomes.addcgid and
d-caregiversl.cgid=outcomes.evalcgid and
as problem, interventions.problem as keyjfor-problem,
ddays.calDay as targetdate, interventions.targetdate as
interventions.orderstatus as orderstatus, dproblemitems0.label
d-problemitems2.itemid=outcomes.problem and
interventions.probtime as probtime, interventions.guidelinename
d_sources.sid=outcomes.sid
as guidelinename, interventions.guideline as guideline,
interventions.chartstatus as chartstatus, interventions.shift
as shift, interventions.variancetype as variancetype,
interventions.variancecause as variancecause,
create table interventions
pid
itemid
numeric,
numeric,
charttime
round(interventions.scode, 0) as scode,
timestamp,
round(interventions.pcode, 0) as pcode, d-sources.hospitalname
as sid, interventions.sid as keyfor-sid,
round(interventions.elemid, 0) as elemid,
round(interventions.txid, 0) as txid from interventions,
chartdate
numeric,
cgid
numeric,
cuid
numeric,
ordercgid
numeric,
d_patients, d interventionitems, d careunits, d days,
ordertime
timestamp,
d_problemitems d-problemitems0,
dateadded
timestamp,
d-patients.pid=interventions.pid and
d_interventionitems.itemid=interventions.itemid and
addcgid
targetdate
instructions
orderstatus
problem
numeric,
numeric,
d-sources where
d_careunits.cuid=interventions.cuid and
d-days.dayid=interventions.targetdate and
varchar(250),
varchar(20),
d-problemitems0.itemid=interventions.problem and
d_sources.sid=interventions.sid ;
numeric,
40
APPENDLXYB: MIMIC Table Definitions
--
create table view-for driporders
as select driporders.oid as oidfor driporders,
dpatients.case-id, round(driporders.pid, 0) as pid,
dmeditems.label as itemid, driporders.itemid as
keyjfor_itemid, driporders.charttime as charttime,
round(driporders.chartdate, 0) as chartdate,
d_careunits.unitname as cuid, driporders.cuid as key-for-cuid,
driporders.verifiedtime as verifiedtime, d caregivers.cgid as
verifiedby, driporders.verifiedby as keyjforverifiedby,
driporders.addtime as addtime, d-caregiversO.cgid as addby,
driporders.addby as keyjfor-addby, driporders.addverifytime as
addverifytime, d caregiversl.cgid as addverifyby,
driporders.addverifyby as keyjforaddverifyby,
round(driporders.duration, 0) as duration,
driporders.durationtype as durationtype, driporders.orderedby
as orderedby, driporders.starttime as starttime,
driporders.stoptime as stoptime, driporders.schedcomments as
schedcomments, driporders.discontinuecomments as
discontinuecomments, driporders.mdinstr as mdinstr,
driporders.rninstr as rninstr, driporders.phinstr as phinstr,
driporders.mdcosign as mdcosign, driporders.rnreview as
rnreview, driporders.phreview as phreview, driporders.freqlabel
as freqlabel, driporders.action as action, driporders.state as
state, driporders.stopstate as stopstate, driporders.education
as education, d-meditems2.label as base, driporders.base as
keyjfor-base, round(driporders.basevol, 2) as basevol,
round(driporders.rate, 2) as rate, round(driporders.dosemin, 2)
as dosemin, round(driporders.doseminuom, 2) as doseminuom,
round(driporders.dosemax, 2) as dosemax,
round(driporders.dosemaxuom, 2) as dosemaxuom,
driporders.doseunits as doseunits, round(driporders.scode, 0)
as scode, round(driporders.pcode, 0) as pcode,
d-sources.hospitalname as sid, driporders.sid as key_for_sid,
round(driporders.elemid, 0) as elemid, round(driporders.txid,
0) as txid from driporders, dpatients, d-meditems,
d careunits, d-caregivers, d-caregivers d&caregiversO,
d caregivers d-caregiversl, d-meditems d-meditems2, d-sources
where d-patients.pid=driporders.pid and
d_meditems.itemid=driporders.itemid and
d-careunits.cuid=driporders.cuid and
dcaregivers.cgid=driporders.verifiedby and
d-caregiversO.cgid=driporders.addby and
d_caregiversi.cgid=driporders.addverifyby and
d-meditems2.itemid=driporders.base and
d-sources.sid=driporders.sid ;
tables for orders
create table driporders
pid
numeric,
itemid
numeric,
charttime
timestamp,
chartdate
numeric,
cuid
numeric,
verifiedtime
timestamp,
verifiedby
numeric,
addtime
timestamp,
addby
numeric,
addverifytime
timestamp,
addverifyby
numeric,
duration
numeric,
durationtype
varchar(20),
orderedby
varchar(30),
starttime
timestamp,
stoptime
timestamp,
schedcomments
varchar(60),
discontinuecomments
varchar(60),
mdinstr
varchar(500),
rninstr
varchar(500),
phinstr
varchar(500),
mdcosign
varchar(30),
rnreview
varchar(30),
phreview
varchar(30),
freqlabel
varchar(16),
action
varchar(20),
state
varchar(20),
stopstate
varchar(20),
education
varchar(20),
numeric,
base
basevol
numeric,
rate
numeric,
dosemin
numeric,
doseminuom
numeric,
dosemax
numeric,
dosemaxuom
numeric,
doseunits
varchar(20),
numeric,
scode
numeric,
pcode
sid
numeric,
elemid
numeric,
numeric
txid
create table freeformorders (
41
APPENDIX B: MIMIC Table Definitions
pid
numeric,
itemid
numeric,
charttime
timestamp,
chartdate
numeric,
cuid
numeric,
verifiedtime
timestamp,
verifiedby
numeric,
addtime
timestamp,
addby
numeric,
addverifytime
timestamp,
addverifyby
numeric,
duration
numeric,
durationtype
varchar(20),
orderedby
varchar(30),
starttime
timestamp,
stoptime
timestamp,
schedcomments
varchar(60),
discontinuecomments
varchar(60),
mdinstr
varchar(500),
rninstr
varchar(500),
phinstr
varchar(500),
mdcosign
varchar(30),
rnreview
varchar(30),
phreview
varchar(30),
freglabel
varchar(16),
action
varchar(20),
state
varchar(20),
stopstate
varchar(20),
education
varchar(20),
order_
varchar(900),
scode
numeric,
pcode
numeric,
sid
numeric,
txid
numeric
keyfor-addby, freeformorders.addverifytime as addverifytime,
d caregiversl.cgid as addverifyby, freeformorders.addverifyby
as keyjfor-addverifyby, round(freeformorders.duration, 0) as
duration, freeformorders.durationtype as durationtype,
freeformorders.orderedby as orderedby, freeformorders.starttime
as starttime, freeformorders.stoptime as stoptime,
freeformorders.schedcomments as schedcomments,
freeformorders.discontinuecomments as discontinuecomments,
freeformorders.mdinstr as mdinstr, freeformorders.rninstr as
rninstr, freeformorders.phinstr as phinstr,
freeformorders.mdcosign as mdcosign, freeformorders.rnreview as
rnreview, freeformorders.phreview as phreview,
freeformorders.freqlabel as freqlabel, freeformorders.action as
action, freeformorders.state as state, freeformorders.stopstate
as stopstate, freeformorders.education as education,
freeformorders.order_ as order, round(freeformorders.scode, 0)
as scode, round(freeformorders.pcode, 0) as pcode,
d_sources.hospitalname as sid, freeformorders.sid as
keyfor-sid, round(freeformorders.txid, 0) as txid from
freeformorders, dpatients, d-chartitems, dccareunits,
d_caregivers, d-caregivers d-caregivers0, dcaregivers
d&caregiversl, d sources where
d_patients.pid=freeformorders.pid and
dchartitems.itemid=freeformorders.itemid and
d_careunits.cuid=freeformorders.cuid and
d_caregivers.cgid=freeformorders.verifiedby and
d_caregiversO.cgid=freeformorders.addby and
d-caregivers1.cgid=freeformorders.addverifyby and
dsources.sid=freeformorders.sid
create table infusionorders
pid
numeric,
itemid
numeric,
charttime
timestamp,
chartdate
numeric,
cuid
numeric,
verifiedtime
timestamp,
verifiedby
numeric,
addtime
timestamp,
addby
numeric,
addverifytime
timestamp,
addverifyby
numeric,
duration
numeric,
durationtype
varchar(20),
orderedby
varchar(30),
starttime
timestamp,
stoptime
timestamp,
create table view for freeformorders
as select freeformorders.oid as oidforfreeformorders,
d-patients.case_id, round(freeformorders.pid, 0) as pid,
d_chartitems.label as itemid, freeformorders.itemid as
key_forjitemid, freeformorders.charttime as charttime,
round(freeformorders.chartdate, 0) as chartdate,
d careunits.unitname as cuid, freeformorders.cuid as
key_for_cuid, freeformorders.verifiedtime as verifiedtime,
d caregivers.cgid as verifiedby, freeformorders.verifiedby as
key-for-verifiedby, freeformorders.addtime as addtime,
dccaregiversO.cgid as addby, freeformorders.addby as
42
APPENDIXB. MIMIC Table Definitions
action, infusionorders.state as state, infusionorders.stopstate
schedcomments
varchar(60),
discontinuecomments
varchar(60),
mdinstr
varchar(500),
rninstr
varchar(500),
phinstr
varchar(500),
mdcosign
varchar(30),
rnreview
varchar(30),
phreview
varchar(30),
freqlabel
varchar(16),
action
varchar(20),
state
varchar(20),
stopstate
varchar(20),
education
varchar(20),
base
numeric,
basevol
numeric,
rate
numeric,
scode
numeric,
pcode
numeric,
sid
numeric,
elemid
numeric,
txid
numeric
as stopstate, infusionorders.education as education,
d_meditems2.label as base, infusionorders.base as key_forbase,
round(infusionorders.basevol, 2) as basevol,
round(infusionorders.rate, 2) as rate,
round(infusionorders.scode, 0) as scode,
round(infusionorders.pcode, 0) as pcode, d sources.hospitalname
as sid, infusionorders.sid as keyjforsid,
round(infusionorders.elemid, 0) as elemid,
round(infusionorders.txid, 0) as txid from infusionorders,
d_patients, d chartitems, d-careunits, d-caregivers,
d_caregivers d caregivers0, dtcaregivers dcaregiversl,
dmeditems d-meditems2, dsources where
d-patients.pid=infusionorders.pid and
d_chartitems.itemid=infusionorders.itemid and
dcareunits.cuid=infusionorders.cuid and
d-caregivers.cgid=infusionorders.verifiedby and
d_caregiverso.cgid=infusionorders.addby and
d-caregiversl.cgid=infusionorders.addverifyby and
d-meditems2.itemid=infusionorders.base and
d_sources.sid=infusionorders.sid
create table medorders
numeric,
pid
numeric,
itemid
create table viewforinfusionorders
as select infusionorders.oid as oid for infusionorders,
d-patients.caseid, round(infusionorders.pid, 0) as pid,
d-chartitems.label as itemid, infusionorders.itemid as
keyfor_itemid, infusionorders.charttime as charttime,
round(infusionorders.chartdate, 0) as chartdate,
d careunits.unitname as cuid, infusionorders.cuid as
key_forcuid, infusionorders.verifiedtime as verifiedtime,
d_caregivers.cgid as verifiedby, infusionorders.verifiedby as
key-forIverifiedby, infusionorders.addtime as addtime,
d-caregivers0.cgid as addby, infusionorders.addby as
keyjfor-addby, infusionorders.addverifytime as addverifytime,
d_caregiversl.cgid as addverifyby, infusionorders.addverifyby
as keyfor_addverifyby, round(infusionorders.duration, 0) as
duration, infusionorders.durationtype as durationtype,
infusionorders.orderedby as orderedby, infusionorders.starttime
as starttime, infusionorders.stoptime as stoptime,
infusionorders.schedcomments as schedcomments,
infusionorders.discontinuecomments as discontinuecomments,
infusionorders.mdinstr as mdinstr, infusionorders.rninstr as
rninstr, infusionorders.phinstr as phinstr,
infusionorders.mdcosign as mdcosign, infusionorders.rnreview as
rnreview, infusionorders.phreview as phreview,
infusionorders.freqlabel as freqlabel, infusionorders.action as
charttime
chartdate
cuid
timestamp,
numeric,
numeric,
timestamp,
verifiedtime
numeric,
verifiedby
timestamp,
addtime
numeric,
addby
timestamp,
addverifytime
numeric,
addverifyby
numeric,
duration
varchar(20),
durationtype
varchar(30),
orderedby
timestamp,
starttime
timestamp,
stoptime
varchar(60),
schedcomments
varchar(60),
discontinuecomments
43
mdinstr
rninstr
phinstr
mdcosign
varchar(500),
varchar(500),
varchar(500),
varchar(30),
rnreview
phreview
varchar(30),
varchar(30),
APPENDIX B: MIMIC Table Definitions
freqlabel
varchar(16)
action
varchar(20),
state
varchar(20),
varchar(20)
stopstate
education
varchar(20)
timestamp,
renewtime
dosemin
numeric,
doseminuom
numeric,
numeric,
dosemax
dosemaxuom
numeric,
numeric,
scode
pcode
numeric,
sid
numeric,
elemid
numeric,
numeric
txid
round(medorders.txid, 0) as txid from medorders, d-patients,
d_ioitems, d-careunits, d-caregivers, d-caregivers
d_caregiversO, d-caregivers dcaregiversl, dsources where
dpatients.pid=medorders.pid and
d ioitems.itemid=medorders.itemid and
d_careunits.cuid=medorders.cuid and
d_caregivers.cgid=medorders.verifiedby and
d-caregiversO.cgid=medorders.addby and
d_caregiversi.cgid=medorders.addverifyby and
d_sources.sid=medorders.sid
--
tables for Duration
create table achartdurations
pid
numeric,
starttime
timestamp,
endtime
timestamp,
create table viewformedorders
as select medorders.oid as oidformedorders,
d_patients.caseid, round(medorders.pid, 0) as pid,
d ioitems.label as itemid, medorders.itemid as key-for itemid,
medorders.charttime as charttime, round(medorders.chartdate, 0)
as chartdate, dcareunits.unitname as cuid, medorders.cuid as
keyforcuid, medorders.verifiedtime as verifiedtime,
d-caregivers.cgid as verifiedby, medorders.verifiedby as
key-forverifiedby, medorders.addtime as addtime,
d_caregiverso.cgid as addby, medorders.addby as key-for-addby,
medorders.addverifytime as addverifytime, d-caregiversl.cgid as
addverifyby, medorders.addverifyby as keyjfor-addverifyby,
round(medorders.duration, 0) as duration,
medorders.durationtype as durationtype, medorders.orderedby as
orderedby, medorders.starttime as starttime, medorders.stoptime
as stoptime, medorders.schedcomments as schedcomments,
medorders.discontinuecomments as discontinuecomments,
medorders.mdinstr as mdinstr, medorders.rninstr as rninstr,
medorders.phinstr as phinstr, medorders.mdcosign as mdcosign,
medorders.rnreview as rnreview, medorders.phreview as phreview,
medorders.freqlabel as freqlabel, medorders.action as action,
medorders.state as state, medorders.stopstate as stopstate,
medorders.education as education, medorders.renewtime as
renewtime, round(medorders.dosemin, 2) as dosemin,
round(medorders.doseminuom, 2) as doseminuom,
round(medorders.dosemax, 2) as dosemax,
round(medorders.dosemaxuom, 2) as dosemaxuom,
round(medorders.scode, 0) as scode, round(medorders.pcode, 0)
as pcode, d sources.hospitalname as sid, medorders.sid as
key forsid, round(medorders.elemid, 0) as elemid,
itemid
cuid
duration
scode
pcode
sid
elemid
numeric,
numeric,
numeric,
numeric,
numeric,
numeric,
numeric
create table view for a chartdurations
as select a chartdurations.oid as oid-for-a-chartdurations,
d-patients.case-id, round(a-chartdurations.pid, 0) as pid,
a chartdurations.starttime as starttime,
a chartdurations.endtime as endtime, d chartitems.label as
itemid, a chartdurations.itemid as key_for_itemid,
dcareunits.unitname as cuid, a-chartdurations.cuid as
keyjforcuid, round(achartdurations.duration, 2) as duration,
round(a chartdurations.scode, 0) as scode,
round(a chartdurations.pcode, 0) as pcode,
d-sources.hospitalname as sid, achartdurations.sid as
keyfor-sid, round(a-chartdurations.elemid, 0) as elemid from
a-chartdurations, d patients, d-chartitems, dcareunits,
d_sources where d-patients.pid=a-chartdurations.pid and
d_chartitems.itemid=achartdurations.itemid and
d-careunits.cuid=achartdurations.cuid and
d_sources.sid=a_chartdurations.sid
create table ajiodurations
pid
numeric,
itemid
numeric,
44
APPENDIX B: MIMIC Table Definitions
starttin e
timestamp,
endtime
timestamp,
cuid
numeric,
duratior
numeric,
scode
numeric,
pcode
numeric,
sid
numeric,
elemid
numeric
itemid, a meddurations.itemid as key-for-itemid,
a_meddurations.endtime as endtime, d-careunits.unitname as
cuid, a-meddurations.cuid as key-forcuid,
round(a meddurations.duration, 2) as duration,
round(ameddurations.scode, 0) as scode,
round(a meddurations.pcode, 0) as pcode, d sources.hospitalname
as sid, a meddurations.sid as keyjforsid,
round(ameddurations.elemid, 0) as elemid from ameddurations,
d-patients, d-meditems, dcareunits, d-sources where
d-patients.pid=ameddurations.pid and
dmeditems.itemid=a meddurations.itemid and
d_careunits.cuid=ameddurations.cuid and
d_sources.sid=a meddurations.sid ;
create table viewfor_a_iodurations
as select aiodurations.oid as oidfor_a_iodurations,
d-patients.caseid, round(a-iodurations.pid, 0) as pid,
d ioitems.label as itemid, aiodurations.itemid as
key-forjitemid, aiodurations.starttime as starttime,
a-iodurations.endtime as endtime, dcareunits.unitname as cuid,
a-iodurations.cuid as keyjforcuid,
round(aiodurations.duration, 2) as duration,
round(aiodurations.scode, 0) as scode,
round(aiodurations.pcode, 0) as pcode, d-sources.hospitalname
as sid, aiodurations.sid as keyjforsid,
round(aiodurations.elemid, 0) as elemid from a iodurations,
d_patients, d-ioitems, d-careunits, dsources where
d-patients.pid=aiodurations.pid and
dioitems.itemid=aiodurations.itemid and
d_careunits.cuid=aiodurations.cuid and
dsources.sid=aiodurations.sid ;
create table ameddurations
numeric,
pid
startrealtime
timestamp,
starttime
timestamp,
itemid
numeric,
endtime
timestamp,
numeric,
cuid
duration
numeric,
numeric,
scode
numeric,
pcode
sid
numeric,
elemid
numeric
create table viewfor_a_meddurations
as select a-meddurations.oid as oidfor_a_meddurations,
d-patients.case-id, round(a meddurations.pid, 0) as pid,
a_meddurations.startrealtime as startrealtime,
a-meddurations.starttime as starttime, d-meditems.label as
45
APPENDIX B: MIMIC Table Definitions
APPENDIX C: MIMIC Index Definitions
--
indexes for all tables in MIMIC
-for metatdata
create index mimictablecolumns on mimictable-elements (column-name);
create index mimictabletables on mimictable elements (table-name);
create index mimic table cats on mimictable categories (category-name);
create index mimictable-index on mimic-tableelements (table-name, includeinview-p);
create index mimicdisplaykeysindex on mimic-displaykeys(table-name);
create index mimictime-keysjindex on mimic-time-keys(table-name);
create index mimic elementview on mimictableelements (table-name, includeinview-p);
create index mimicelement search on mimictableelements (tablename,
include in-ctx-index-p);
create index mimic-display-keys-index on mimic-display-keys (tablename);
--
for data log
create index mimic-updateid on newdatalog (update-id);
-- for
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
--
patient fact tables
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
caseidfor-problems on d-patients (caseid);
key-index-for_problems on problems (pid);
key-indexforresultevents on resultevents (pid);
key-indexfor_a_meddurations on ameddurations (pid);
keyindexfor_a_chartdurations on achartdurations (pid);
key-indexjfor-d-patients on dpatients (pid);
key-indexfor_a_iodurations on ajiodurations (pid);
key-indexforchartevents on chartevents (pid);
key-indexfordeliveries on deliveries (pid);
key-indexjfor-driporders on driporders (pid);
key-indexjforformevents on formevents (pid);
key-indexjforfreeformorders on freeformorders (pid);
key-indexforinfusionorders on infusionorders (pid);
key-indexforinterventions on interventions (pid);
key-indexforioevents on ioevents (pid);
key-indexformedevents on medevents (pid);
key-indexformedorders on medorders (pid);
key-indexforoutcomes on outcomes (pid);
keyindexforcensusevents on censusevents (pid);
key-indexforsolutions on solutions (pid);
key-indexjfor-additives on additives (pid);
key-indexfornoteevents on noteevents (pid);
key-indexfortotalbalevents on totalbalevents (pid);
for dimension tables
create
create
create
create
create
create
create
create
create
create
create
create
create
create
index
index
index
index
index
index
index
index
index
index
index
index
index
index
-- for
create
create
create
create
create
create
time elements
index timeindexfor_a_chartdurations on a_chartdurations (starttime);
index time-index for additives on additives (charttime);
index time-indexforaiodurations on a-iodurations (starttime);
index timeindexfor_a_meddurations on ameddurations (starttime);
index timeindexforcensusevents on censusevents (intime);
index time indexforchartevents on chartevents (charttime);
key-index for-d-caregivers on d&caregivers (cgid);
key-indexfor_d_careunits on dcareunits (cuid);
key-indexfor_d_chartitems on dchartitems (itemid);
key-index for-d-days on d-days (dayid);
key-index for-d-days on d-days (calday);
cal-key-indexfor_d-days on ddays (calday);
key-indexfor_d_interventionitems on d interventionitems (itemid);
key-indexfor_d_ioitems on dioitems (itemid);
key-index for_d_meditems on dmeditems (itemid);
key-indexfor_d_outcomeitems on doutcomeitems (itemid);
key-index-for-d-primarycodes on d_primarycodes (pcode);
key-index-for-dproblemitems on d-problemitems (itemid);
key-index-for-d-secondarycodes on dsecondarycodes (scode);
key-indexfor-d-sources on d-sources (sid);
46
APPENDIX C: MMC Index Definitions
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
--
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
time index for deliveries on deliveries (charttime);
timeindex for driporders on driporders (charttime);
timejindexforformevents on formevents (charttime);
time index-for freeformorders on freeformorders (charttime);
time index for infusionorders on infusionorders (charttime);
timeindex-for interventions on interventions (charttime);
timeindexforioevents on ioevents (charttime);
timeindex-for-medevents on medevents (charttime);
time index for medorders on medorders (charttime);
time index for noteevents on noteevents (charttime);
timeindex for outcomes on outcomes (charttime);
timeindex-for-problems on problems (charttime);
time indexforresultevents on resultevents (chartTime);
timeindexforsolutions on solutions (charttime);
timeindexfortotalbalevents on totalbalevents (charttime);
time and key elements
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
time key-index-a_chartdurations on a-chartdurations (starttime, pid);
time key-indexadditives on additives (charttime, pid);
time-key-index_a_iodurations on ajiodurations (starttime, pid);
time-key-index_a_meddurations on ameddurations (starttime, pid);
time-key-indexcensusevents on censusevents (intime, pid);
time-key-indexchartevents on chartevents (charttime, pid);
time-key-indexdeliveries on deliveries (charttime, pid);
time-keyindex-driporders on driporders c(harttime, pid);
time-key-indexformevents on formevents (charttime, pid);
time-key-index_freeformorders on freeformorders (charttime, pid);
time-key-indexinfusionorders on infusionorders (charttime, pid);
time-key-indexinterventions on interventions (charttime, pid);
time-keyindex_ioevents on ioevents (charttime, pid);
time-keyindexmedevents on medevents (charttime, pid);
time-key-indexmedorders on medorders (charttime, pid);
time-key-indexnoteevents on noteevents (charttime, pid);
time-key-index-outcomes on outcomes (charttime, pid);
time-key-index-problems on problems (charttime, pid);
time-key-indexresultevents on resultevents (chartTime, pid);
time-key-indexsolutions on solutions (charttime, pid);
time-key-index-totalbalevents on totalbalevents (charttime, pid);
for search display
create index itemidindexchartevents on chartevents (itemid);
--
--
for
create
create
create
create
create
create
create
create
create
create
create
create
menu item display
index menuitem totalbalevents on totalbalevents(itemid);
index menuitemcensusevents on censusevents (careunit);
index menuitemchartevents on chartevents (itemid);
index menuitem_a_chartdurations on a-chartdurations (itemid);
index menuitem a iodurations on a-iodurations (itemid);
index menuitem deliveries on deliveries (ioitemid);
index menuitem-formevents on formevents (sectiontitle);
index menuitem ioevents on ioevents (itemid);
index menuitemmedevents on medevents (itemid);
index menu item noteevents on noteevents (category);
index menu item solutions on solutions (itemid);
index menu item totalbalevents on totalbalevents (itemid);
for
create
create
create
create
create
create
create
create
create
create
create
create
create
create
datekeys
index viewdate for additives on view for-additives (chartdate);
index view-date-for-censusevents on viewforcensusevents (indayid);
index viewdatejfor-chartevents on viewforchartevents (chartdate);
index viewdate for deliveries on viewfordeliveries (chartdate);
index view-datejfor-driporders on viewfor_driporders (chartdate);
index viewdate-for-formevents on viewforformevents (chartDay);
index viewdate-forjfreeformorders on viewforfreeformorders (chartdate);
index viewdateforinfusionorders on viewforinfusionorders (chartdate);
index view-date for interventions on viewforinterventions (chartdate);
index viewdateforioevents on viewforioevents (chartdate);
index viewdateformedevents on viewformedevents (chartdate);
index viewdateformedorders on viewformedorders (chartdate);
index viewdatefornoteevents on viewfornoteevents (chartDate);
index viewdateforoutcomes on viewforoutcomes (chartdate);
--
47
APPENDIX C: MMC Index Definitions
viewdate-for-problems on viewjfor-problems (chartdate);
view date for resultevents on view for resultevents (chartDate);
viewdate_forsolutions on view_forsolutions (chartdate);
view datefortotalbalevents on view for totalbalevents (chartdate);
create
create
create
create
index
index
index
index
-- for
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
create
case-ids
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
index
caseidforchartevents on viewforchartevents (caseid);
caseidfor_a_meddurations on viewfor_ajmeddurations (case-id);
caseidfor_a_iodurations on viewjfor-a-iodurations (caseid);
case id-for_a_chartdurations on viewfor-a-chartdurations (case-id);
caseidforinterventions on view for interventions (caseid);
caseidforoutcomes on view for outcomes (case-id);
caseidfor-problems on viewfor-problems (case-id);
caseidformedorders on view for medorders (case-id);
caseidforinfusionorders on viewforinfusionorders (case-id);
case id-forfreeformorders on viewforfreeformorders (case-id);
case id-fordriporders on viewjfor-driporders (case_id);
case id forsolutions on viewforsolutions (case-id);
caseidfordeliveries on viewfordeliveries (case-id);
case-id-forioevents on viewforioevents (case-id);
case id-fornoteevents on viewfornoteevents (case-id);
caseidfor formevents on viewforformevents (case-id);
caseid-for censusevents on viewforcensusevents (case id);
caseidforadditives on viewforadditives (case-id);
case id for-resultevents on viewforresultevents (case-id);
caseidformedevents on viewformedevents (case-id);
caseidfortotalbalevents on viewfortotalbalevents (case-id);
case id-for-d-patients on viewjfor-d-patients (case-id);
48
APPENDIX C: MMC Index Definitions
f
f
freeformorders itemid
infusionorders itemid
APPENDIX D: MIMIC Keys
mimic-date keys
"tablename"
"date-key"
additives
censusevents
chartevents
deliveries
driporders
formevents
freeformorders chartd
infusionorders chartd
interventions
totalbalevents chartd
ioevents
medevents
medorders
noteevents
outcomes
resultevents
problems
solutions
mimic-item keys
"table-namen
"itemkkey"
"include in view-p"
d-secondarycodes
d sources
d caregivers
d careunits
d interventionitems
d ioitems
d meditems
d outcomeitems itemid
d-problemitems itemid
additives
a meddurations itemid
d chartitems
d days
interventions
medorders
outcomes
problems
resultevents
a-iodurations
deliveries
ioevents
medevents
solutions
totalbalevents itemid
censusevents
formevents
chartevents
a-chartdurations
noteevents
chartdate
indayid
chartdate
chartdate
chartdate
chartDay
ate
ate
chartdate
ate
chartdate
chartdate
chartdate
chartDate
chartdate
chartDate
chartdate
chartdate
mimic-timekeys
"tablename"
"time-key"
month
d_days
chartTime
resultevents
charttime
deliveries
charttime
driporders
freeformorders charttime
infusionorders charttime
f
code
siteid
cgid
cuid
itemid
itemid
itemid
medorders
charttime
problems
outcomes
charttime
charttime
interventions
charttime
starttime
a_iodurations
ameddurations starttime
intime
censusevents
charttime
solutions
f
f
f
f
f
f
f
f
itemid
itemid
itemid
itemid
itemid
resultid
itemid
ioitemid
itemid
itemid
itemid
t
careunit
sectiontitle
itemid
itemid
title
f
f
a_chartdurations
starttime
chartevents
charttime
formevents
charttime
ioevents
charttime
medevents
charttime
noteevents
charttime
f
totalbalevents charttime
f
d-patients
itemid
dayid
pid
d-patients
additives
dprimarycodes code
driporders
itemid
f
f
49
pid
charttime
APPENDIX D. MMC Keys
mimic-display-keys
"tablename"
"displaykey"
pid
d-patients
d careunits
unitname
d_chartitems
label
d-days
calDay
d_interventionitems label
label
d ioitems
label
d_meditems
d outcomeitems
label
d-problemitems
label
d_sources
hospitalname
d caregivers
d-primarycodes
d_secondarycodes
censusevents
cgid
pcode
scode
pid
chartevents
formevents
medevents
noteevents
resultevents
totalbalevents
ioevents
itemid
itemid
itemid
pid
objectid
pid
itemid
additives
deliveries
solutions
driporders
itemid
ioitemid
itemid
itemid
freeformorders
itemid
infusionorders
medorders
itemid
itemid
problems
itemid
outcomes
interventions itemid
a_chartdurations
a-iodurations
a-meddurations
itemid
itemid
itemid
itemid
(34 rows)
50
APPENDIX D: MIMJC Keys
Appendix E MIMIC Administrator's Manual
Background on MIMIC
The Mimic Relational Database Management System (RDBMS) is designed for patient
records taken from a hospital's clinical information system called CareVue. This
automated system consolidates patient data and stores it in an Oracle database.
Those records have been available to MIMIC through a partnership with a local
hospital.
The purpose of the MIMIC RDBMS is to provide an interface to define tables and
manage how they are accessed, displayed, and presented to the end user. The
MIMIC RDBMS is used to select data to be downloaded from the partner hospital,
parse, upload, and organize these records, and present them to the end user.
51
Manualfor MIMIC Administrators
Administrative Modules for MIMIC
Administrators to MIMIC have the ability to manage table definitions, add new data
to the database, and control parameters that affect how data is displayed and
managed.
Administrative tasks can be divided into two categories: making table definitions,
and adding new data to the database. Table definitions need to be made only once,
and updated as necessary. New data can be added at anytime. It is likely that there
will be regular updates to add new data as it is collected.
Log In
Curreut
m eue: Please enter your emil and password below.
New woes: Welcome to 8ystemName. Please begin the registration process by entering a valid 0mail address and a
password for signingimto the system We will direct youtto anotherform to complete yourregisration.
Your emai address: user _acunt
Your password-
1
Remember this address and password?(
)
Ifyoukeep getting thrown backhee, it is probablybecause yourbrowser does not accept cookies. We're socy for
the inconvenience but it really is impossible to program a system like this withodtkeeping track of who is posting
what
In Netscape 4. you can enable cookies from Edit-> Preferences -> Advanced. In Microsoft Internet Explorer 4A you
can enable cookies from View-> lnteotetOptions -> Advanced-> Security.
Administrators will need a username and password to log into MIMIC before being
able to perform any of the administrative tasks described in this section.
52
ManualforMIMIC Administrators
The administrative database management module located in
/server path/www/admin/mimic/ allows administrators to enter table definitions for
tables in MIMIC. These definitions are then used to generate SQL CREATE TABLE
statements that the administrator can cut and paste into Postgres to create tables.
The administrator does not need to have previous knowledge of SQL.
Tables are stored in categories and consist of a number of elements (columns) for
that table.
Category
Category
table
el
el
table
table
table
table
el
Hierarchyof Metadata
Step 1: Creating a Catenory
Tables are organized into categories. The section for normal users describes how
category definitions affect how data is viewed. The administrator first needs to define
a category for the table by clicking on "Create a New Category" link in
/server path/www/admin/mimic/. The administrator can then enter the attributes
associated with this category.
The Category Name is the
name used in SQL for this
-
category. Category names
must be unique and should
not contain any white space.
Create a New MhN&c Table Category
The Pretty Name is the name
used when displaying this
category name to normal
users.
Cagory Nama
(optional) The Description
field may be used to enter a
short description about the
usage or contents of this
category.
OrdrSatK e
1uehad iUer Viw tvyes
PrettyNote
s
ITst
F
7
In a test category created for our
demonstration
This
r no
~ ~-:4
The Order Sort Key is an
integer used in sorting
categories. For instance, a category with an Order Sort Key of 1 would appear first in
53
ManualforMiMIC Administrators
the list of categories. Order
sort keys are constrained to be
unique. The default value for
order sort keys is the next
largest value order sort key.
Lastly, the administrator may
specify whether this category
should be Included in the
User View. This allows
categories to be defined, but
hidden from normal users. This
is useful for administrative or
dimension tables.
OG
rn&et SQL statmnts to
Le
or k
these tables.
T" Name
the. re
am o tAb43 in s zcategory
Ad'
"o
Once these attributes are entered, the administrator can create this category by
clicking on the "create" button.
Once a category is created, the
administrator is taken to a page that
lists the tables for that category. To
create a new table, click on "Add a
New Table."
Figure 1 New Category
54
Manualfor MIMIC Administrators
Step 2: Creating a
Table
Now that a category has been
defined, tables can be added
to that category. The
attributes for tables are
similar to those for
categories.
Creat, a New mie Table fur t
TAIW Nime Itebe
PruyNm
The Table Name is the name
used in SQL for this table. The
Table Name is constrained to
be unique should not contain
any white space.
Test cate.y
lTestTable
this is a test table
this table is used for de onstrational
purposes.1
U...
The Pretty Name is the
name used when displaying
this table to normal users.
The Description field is used to store information about the table.
The Usage field is used to describe how this table should be used.
Once these attributes have
been defined, the
administrator can click on the
"create"button to create this
table. The table is not actually
created on the database
system at this time. Step 4
describes how to actually
create the table in the
database.
TacT"TWr
.... b.off T.t.T.
Qq
SQL,,,s1,fob"ta
,,
thee we no elswntz in th taNble
Now the administrator has
defined a category and a table
in that category. He can now
add elements (columns) to
that table by clicking on "Add a New Element."
55
ManualforMIMIC Administrators
Step 3: Adding Elements to a Table
Administrators can then enter attributes
for an element in this table.
The Column Name is the name used in
SQL for this table and should not
contain any whitespace. The Column
Name is constrained to be unique for
this table.
Ad -n Elemat to Tes Table
Psese entas thea Moowwi"s
The Pretty Name is the label used for
displaying this column to normal users.
The Abstract Data Type specifies what
type this column is, i.e. "boolean" or
"integer" or "text." This value is used in
formatting this column for display.
CGSII
l'et
Warn
Aitract
ITest One
wx
i.e. "tA"
DeaP-leraar~ 00
Ke
or "shorttex"
-.
'vochuM"5
O )
VWIa
IM.
of TestTable
LO.Ivteeba(2Ci)*
adre L
The Postgres Data Type is the type
used for Postgres, i.e. "numeric" or
"timestamp." This value is used in
generating SQL to create and select
from tables in Postgres.
The Oracle Data type is the type used
in Oracle, i.e. "integer" or "date." This
value is used in selecting data from
hospital tables that are stored in Oracle.
deacibisig an seemct (cohmas)
boolean'
"istegee
inte?"-
g.."notnu"
.ox -chekfoobarin
1
s'
lF
ie. 1 forfnt esh=a
Fj~lma~*
isinthe f irst teet cniun.
I~
jqae~
i.ia
Teta t
es
Wno
r,
Search
T"~View
141
,
90"
, ,
-
7
is.r
,
.-- " '
I
I
!*?
77777'7 7
_tMkPidt
F
(optional) The Extra SQL field can be
used for any extra SQL that should be
included when creating this table, such
as "not null" or "references
d_tests.test."
The Order Sort Key is used to sort
elements in this table. An element of
order sort key of 1 would appear first in
this table. The default value for this
attribute is the maximum value +1 for
this table.
Test Table Table
Elemnts of Table Test Table
'ewvr
te SQL create table statemen for tis
tables
Comm Name Petty Name
1I testi
edit 2 test2
edit 3 test3
(optional) The Entry Explanation field
can be used to give a description of this
column.
Test One
Test Two
Test Three
this is the frst test column
2nd test colum
3rd test con
Adda New Element
~n4
Administrators can specify whether this
column should be included in a text
56
Manualfor MIMIC Administrators
search of this table in the Include in Text Search field. Typically, this value is turned
on for free text fields and turned off for fields that contain date or numeric
information.
The Include in Table View field controls whether this field is visible to normal
users. Some fields may not be significant to the end user and should be hidden.
Step 4: Generating SQL
Once all elements are defined for this
table, the administrator can generate
SQL to create this table by clicking on
"Generate."
A code sample generated by this step
appears below.
Cee
o
ll
SQL Create Table stateumt far Test Table
Youay"cut ndpa'te the fo"ow
create.the
.gto TetTable t
.
create table test-table
teati
vazchax (100),
teat
varchar(1) ,
Test Three
integer
ZYME5C
This will generate SQL create table
statements that the administrator can
cut and paste into the Postgres
command line.
::::een
L
fltZ
bash-2.05$ peqi openac4
Welcome to peql, the PostreSOL interactive terminal.
Two:
\cop~fright for distribution terms
\ii for help with SOL commands
\? for help on internal slah commands
\g or terminate with semicolon to execute q.jerg
\q to qpdt
j
apnes4ee* create table test-table
opwnce(* teeti varchar(lOO).
operwcs4(e teat.2 varcherti).
oees(# tast3 integer
oees(C )
C~TE
openecs4=0
6-4*
MMtM|MfT
MMi:1
-_lM
Note: These administrative table management pages are also used to modify category,
element, and table definitions. Each time an element's column name, Oracle data type,
or Postgres data type is updated, the Administrator should first drop and then re-create
the table in Postgres for the changes to take affect. Other modifications to columns take
effect without having to recreate the table.
Currently, MIMIC contains table definitions for those tables defined in the CareVue
ISM. A description of these table definitions appears in Appendix B.
57
ManualforMIMIC Administrators
Index Management
SQL indexes are used to speed common queries for tables with indexable columns.
The index management module in /server path/admin/mimic/indexes allows users
to create and manage indexes for tables defined in the table management module
and created in Postgres as described in Step 4. Indexes are optional but can provide
added performance.
Administrators can create new
indexes by clicking on "Add a New
Index." He can then add
attributes to define the index.
The Name for the Index is the
name used in SQL for this index.
It is constrained to be unique and
should not contain any white
space and.
Name fr this
The Table for this Index is the
table that this index is created on.
This can be selected from a pulldown menu of tables defined
using the table management
module. Once the index name and
table have been chosen, click on
ltesundex
(please do not include any whitespace in the
ajcoduratons
-
*~2~
ajiiedduratons
censusevents
c-days
7,
"next."
The next step in creating a new
index is to choose columns for the
index. Columns can be chosen
from a pull-down menu of
previously defined columns
(elements) for this table.
Clicking "next" will add a column
to the index. Repeat to add more
columns. Once all columns have
been added, the Administrator can
click on the link to "Create this
index." The index will be added to
the index management system and
also created in the database.
Creindex test-idex on a_chardurabons (
ld-
C7-at
Please choose choose coluans(s) to add to this index
scods
pc-depid
sid
elemid
cuid
itemid
esdtfime
stWme
-
.. 7
duration
MIMIC contains indexes for the
tables for tables that are currently defined. These indexes are described in more
detail in Appendix C.
58
Manualfor MIMIC Administrators
Key Management
Keys store more information about how to display the data in tables. The key
management module is in /server path/admin/mimic/data/keys/. These keys are
simply columns of a table that are designated for a specific use.
A Display Key for a table is the column that should be used as a label for this table.
In some views where only one column for a table is displayed, this label is used. For
example, the dmeditems table, the label is the display key. Oftentimes other tables
will reference the dmeditems table. When it does, the label is used to display that
value.
Menu Keys are used in
displaying data in a menu
fashion. Administrators can
specify a column for each
---
___-
table and whether this menu
key should be visible. This
Total Balance Events
controls the menus that are
L4=Tr4§
.
T1l7.1aufottb.
displayed to normal users.
For instance, the
totalbalevents table has
Ss0
itemid as its menu key. This
MM0(&3
04
means that the values of this
column are available as menu
4
03
o
3
Tota
[Wi
8
24
.M
03M01
39
1
04
1s3
o
options. One value for
11,2001 24TOW
40
3W 1
3
in
1u'vA
itemid is "24 Total Out." A
user could click on this item
to view only entries in that
column with that menu value.
For this example, the result would be a table of only "24 Total Out" entries.
Time Keys are used to select and order data. These are generally columns with
timestamps. Each table is ordered by a time key so that results can be displayed in
chronological order.
Date Keys are also used to select and order data. These are generally columns with
integers that denote which day the item was stored. These date keys generally
reference the d days table, which has entries for every day from January 1, 1970 to
December 30, 2030. Date keys are helpful in finding records for a specific day.
Current values for the keys described above can be found in Appendix D.
59
Manualfor MIMIC Administrators
Once tables have been defined in the table management module and created in
Postgres, the system is ready to be populated with data. This section describes the
steps involved in adding new data to MIMIC.
Overview
The data comes from a hospital's Information Support Mart (ISM) that is stored in
Oracle. Through a special partnership with the hospital, we are able to connect
remotely to the hospital's network to download data.
:'
Hospital
ISM
(Oracle)--.
network
*
O
.:
'''
'-
o
-sMIMIC
Database
(Pbstgres)
Connected via
CareWeb
Currently, a separate system is used to initially collect and store waveform data.
Patients are each assigned a case id (case-id). The hospital's ISM uses a different
patient ID (pid) for each admission. Caseids are assigned to be the same for each
patient and reused for readmissions. The data download process for MIMIC consists
of the following steps:
1. Find the hospital's patient ID for each patient by matching their names and/or
MRN
2. Extract data with these patient ID's and de-identify records.
3. Upload data to the MIMIC database
Tools Needed
*
*
*
"
*
Web browser (i.e. Netscape or Internet Explorer)
Access to hospital network (i.e. via CareWeb)
Access to the hospital ISM (Oracle)
Access to local server that MIMIC is on (pc44)
List of patients
This should be of the format:
case-id last-name l firstnamelMRN
The MRN (Medical Record Number) is optional.
Samples of all files needed for and generated by the data update process can be
found at the end of this document
60
Manualfor MIMIC Administrators
Getting New Data
1. Connect to the CareGroup (eurkea.caregroup.org) system at the partner hospital
via the CareGroup VPN Dialer.
lCxGiwVPNU
CJ&-
2. Start Oracle SQL*Plus and connect to the hospital ISM. You should enter your
username, password, and 'ISM' as the host string. You are now connected to the
hospital network and have access to patient records.
SQL*Plus: Release 0.U.5.8.8
-
Production on Wed Kay I
(c) Copyright 1998 Oracle Corporation.
Connected to:
Oracle$ Enterprise Editiol Release 6.3.5.6.6
PL/SQL Release B.6.5.8.6 - Production
SQL>
15:24:12
2682
All rights reserved.
-
Production
I
61
Manualfor MIMIC Administrators
Go to the data upload page at /server path/admin/mimic/data.
Upload a file containing the list of patients for Step #1.
The list of patients should be a text file of the format:
Getting new data
Step 1:
Input file should contain rows of case-id, firstname,
last_name, mm with whitespace
as null
Fenama:C-TEMPnarms.csvyd
This generates a script that extracts hospital pids for each patient.
Run this script by typing 86s cz.p name at the Oracle prompt
caseid| last-name first_name jmrn
where each patient is listed on a separate line. A sample appears below.
35511 LADENIJOSEPHI
35491STEELEIREMINGTON112428752
35461FIELDSIANDREWI
62
Manualfor MIMIC Administrators
Here is a sample of a script generated by this step. Save this file as scriptname.
Pet heading off;
set feedback off;
set termout off;
spool C:/teap/data/d patients.cxv;
select
'3551
111I1 p.pid 1III'11p.sex 1'1I1l to-char(p.dob,
(upper(p.firstname) like upper(14;JCSEPH3%) and
upper (p.lastname) like upper(' %LADENI))
or (upper(p.fullname) like upper(1 JOSEPM)
and
upper(p.fullname) like upper(' LADEN1)) ;
from d_
'Vy-rmo-dd')
select '3549' 111I111 p.pid 1111''1 p.sex 11''l1 tochar(p.dob, lyyyy-in-dd') from d_
(upper(p.firstnae) like upper('9RENINGTON%') and
upper (p. lastname) like upper(' %STEELE%'))
or (upper(p.fullname) like upper('RENINGTCM') and
upper(p.fullnme) like upper('%STEELE')) or p.mrn-12428'752;
select
'35461 I
I111
'
p.pid I I ' I' I I p.sex I1'I 'I I to-char (p.dob,
(upper(p.firstname) like upper('!ANDREW') and
upper (p. lastneme) like upper(' %FIELDS' ))
or (upper(p.fullname) like upper(' ANDREWV') and
upper(p.fullname) like upper('%FIELDSV'));
41
Fa H*e
~ 9~,
pixm
F1
'
yyyy-=m-dd') from d_
I
A~
4
3. Take the script generated by the previous step and run it on the hospital system
by typing: @@©scriptname at the Oracle prompt.
SQL*Plus: Release
8.6.5.0.8
-
on
011
Production
(c) Copyright 1996 Oracle Corporation.
Connected to:
OracleS Enterprise Edition Release I.4.5.8.8
PL/SQL Release 3.1.5.D.6 - Production
SQL>
-
Thu
May
2 11:22:8 2682
rights reserved.
-
Production
C:/temp/scriptname.txt
This step generates a file called dpatients.csv. This file will be of the format
caseidipidlsexldob
A sample appears below:
35051 592IF11936-09-09
35051 2316IF11936-09-09
35091 1901IMI1927-07-05
No Patient names are used from this point forward.
63
Manualfor MIMIC Administrators
4. Take the d-patients.csv file generated in the previous step and upload it in Step
#2. This step generates a file that will extract complete patient records for the
Once you have a list ofpadients (dpaents.csv) you generate a script to extract
complete records.
Filanum: lCij1116\d-'paOw-nts.csvyI
LAE
Use the "Browse"button to locate the dpafients.csv fie generated by step
click 'Open".
1 and then
Step 3:
er ate a . cnpt to download support (d&nension) tables ifyou haven't already done
I
so.
To run these scripts, log into the hospital system
here for more mfotnation.
and type ne
r.2.enmwe at the Oracle prompt. Go
desired patients. Save this file as scriptname.
5.
Run the script generated by the previous step by typing
@@
scriptname
at the Oracle prompt. This will
create several .csv files in
C:/temp/data on the local
filesystem.
6. (optional) Mimic uses some
support tables in storing
patient data. If you have not
already done so, you can
generate a script to download
support tables in Step #3 .
Save this file as
scriptname.
Run this script by typing
@@ scriptname
at the Oracle prompt. This will generate more .csv files in C:/temp/data.
64
Manualfor MIMIC Administrators
7. Move all .csv files generated by the previous steps to the local server (i.e. by
ftp). Next, upload the data in Step 4 by specifying the location of the .csv files.
Note that the files must be stored in a folder that is readable and writeable by the
Postgres user..
The next screen will ask for confirmation to begin the data upload process. The
1. Transfer the files generated by the above steps to some folder on the local system (Le. via fip
or sep).
2. Enter the location of the directory of where the data files are located on the local system.
Diepagod
Download
you can download data as a text file to process. by ngbt-cickeg on the links below and savig to file.
medicatons
Case IDIChart Timeitem IDIO Item ID Amount|Dose UnitsptoutelCare Unit IDiCare Giver ID
Case IDIChart Trnetem IDPenodic volumelCumiaive VolumeAccunulafion
Periodlapproximatefreset|Care Giver IDiCare Unit IDlrransaction IDlOement ID
-j
~%
time to upload new data depends on the number of records being downloaded
and the size of each record.
~..
Enter New Data
Are you sure you want to update the database now?
This may take a while and slow the system down
The results of your update can be viewed in the log page.
Please wait untl you are redirected to the log page to view the results of the update.
The data will then be parsed, de-identified, and entered into the database.
Once this process is complete, the browser will be redirected to the data log
where the results of the update can be viewed.
65
Manualfor MIMIC Administrators
Normal users can now view these records in /server path/mimic.
to CdMe.-
Record for April 29, 2002 17:19:51-04
ile Stats pdate Result
Table Name
[acbartdaaons
addshves
fm/daa/04_25_02/a_chartdurahons csv
/mmcdata042502/addkives csv
ajodurahons
a meddurabons
censusevents
/lic/data/04_25_02/a_iodrahons
file found
update successful
e found_ [pdate successful
ie found
fie found
ile found
fie found
file found
fie found
Sle found
file fo d
update successful
fe found
knmc/data/04_25_02/dehvenes.csv
k
cdta0202d, terventontew scv fie found
Id..mtervenkonatem5
update successful
[paescesu
chateveits
csv
tnc/data042502/ameddurations cov
/mnecdata/04_25_02/censusevents
/rm
sv
c/datal04_25_02/chartevents sv
vercv
frnnIdata4 25_02 d_c
f idata/0425_02/d-careuntscsv
dcaregver
dcareunts
d-chartms
data025_02/d.chatitemscsv
~d~days
/f/data/425~_2tddays -v
-
dehvenes
dioitems
doutcometesen
dpaients-
-m
update successful
dupate successful
update successful
update successful
update successful
unpd ae successful
mic/data/042502/dioteiscov
file found
update successful
icdata/0425_02/dmeditems.csv
fle found
update successfU
fanmcdata/04-25_02/d-oucometems.csv
fe found
dat042502/dpaents.csv
file found
udate successful
[update successfi
/
dkmeditems
upate successUl
66
Manualfor MIMIC Administrators
Sample Files
Sample input file of names for Step 1
12661BROWNIJAMES10033085
21061 THOMAS ISARAHI
Sample Script generated by Step 1
set heading of f;
set feedback off;
set termout of f;
spool C: /temp/data/dpatients.csv;
select
'1266'
11 ' ' 1 p-pid I I' I ' I p-sex I|I |'
to-char(p.dob,
from d-patients p, dual where
'yyyy-mm-dd')
(upper(p. firstname) like upper( '%JAMES% ') and
upper (p. lastname) like upper ( '%BROWN% '))
or (upper (p. fullname) like upper ('%JAMES%') and
upper (p. fullname) like upper ('%BROWN%'))
or p.mrn='0033085';
select
'2106'
II''
p.pid II'I' I p.sex IIl
to-char(p.dob,
from d-patients p, dual where
'yyyy-mm-dd')
and
(upper (p. f irstname) like upper( '%SARAH%')
upper(p.lastname) like upper( '%THOMAS%'))
or (upper(p.fullname) like upper('%SARAH%') and
upper (p. fullname) like upper( '%THOMAS%'));
spool off;
Sample dpatients.csv file generated by script from Step 1.
126611210IM11912-11-05
2601111721F11917-01-28
67
Manualfor MIMIC Administrators
Sample script generated by Step 2
spool off;
set heading off;
set feedback off;
set termout of f;
spool C:/temp/data/additives.csv;
CREATE OR REPLACE FUNCTION replace-names
(find-pid in number,
replace-string in char)
RETURN varchar
IS newstring varchar(5000);
tempjlastname varchar(100);
tempfirstname varchar(100);
temp num number;
BEGIN
SELECT fullname INTO tempjlastname from d-patients
WHERE pid =
findpid;
new-string := replace(lower(replace-string),
lower (templastname),
'patient');
tempnum:=instr (temp-lastname, '
tempfirstname:=substr (tempjlastname, 0, tempnum);
temp-lastname:=substr(tempjlastname, temp-num);
newstring := replace(new-string, tempjfirstname,
'patient ');
new_string
replace(new-string, temp-lastname,
'patient ');
RETURN (new string);
END replace-names;
cuidi 'I'll
duration I 'I'll
sidi
'I'll
replace_names(pid, route)
cuid
cgid
I
|
''l
'I'll
scodell'I'II
pcodell'I' I
sid 'I'll
elemid I' 'I
txid
from ism.additives where
pid=1266 or pid=2106;
spool off;
spool C: /temp/data/ajiodurations.csv;
select pid ''l|
itemid 'I'll
tochar(starttime, 'YYYY-MM-DD HH24:MI:SS') 1|'1'1
tochar(endtime, 'YYYY-MM-DD HH24:MI:SS') II|'
|'
'I'll
pcode I I
sidi iI'
I
''l
I
I
'
elemid
from ism.a iodurations where
pid=1266 or pid=2106;
spool off;
spool C: /temp/data/a-meddurations .csv;
'I'll
select pidi 'I'll
to-char (startrealtime, 'YYYY-MM-DD
'I'll
'I'll
elemid
from ism.a-chartdurations where
replace-names(pid, doseunits) | |
mlperunitI
duration
scodel I'!'
select pidi li'll
tochar(starttime, 'YYYY-MM-DD HH24:MI:SS')I| I '
'
to char(endtime, 'YYYY-MM-DD HH24:MI:SS') II'
itemidi 'I'll
pcodel
itemid 'I'll
ioitemid 'I'll
amount j'
'1
cuidl
spool C: /temp/data/a-chartdurations.csv;
scodel
select pid1 'I'||
tochar(charttime, 'YYYY-MM-DD HH24:MI:SS')11'
chartdatel 'I'll
HH24:MI:SS')
pid=1266 or pid=2106;
11111
to-char(starttime, 'YYYY-MM-DD HH24:MI:SS') |'
|'|
itemidi l il
tochar(endtime, 'YYYY-MM-DD HH24:MI:SS')jj'j'
cuidI'I'l l
chartdateI'I'l l
sid
'1'||
elemidi 'I'l l
txid
from ism.chartevents where
l
duration| I ' l
scodel||I
I
pcodel 'I'll
sidi
'
I'l l
pid=1266 or pid=2106;
spool off;
elemid
from ism.ameddurations where
pid=1266 or pid=2106;
spool C:/temp/data/deliveries.csv;
'I'll
chartdatel' I'l
spool off;
select pid
l
to-char(charttime, 'YYYY-MM-DD HH24:MI:SS')11'1'11
spool C:/temp/data/censusevents.csv;
ioitemid|l'I'll
select pid1|l
replacenames(pid, site)'11111
rate ' I'll
I
'
tochar(intime, 'YYYY-MM-DD HH24:MI:SS')11'1'11
to-char(outtime, 'YYYY-MM-DD HH24:MI:SS')jj'|'j
careunit!11
cgid
lii
I 'l
destcareunitI1l' I
cuid|l 'I'll
sid|l 'I'll
replace-names(pid, dischstatus)11'1'||
elemid
losI|' ' II
sidil'I '|
indayidl
outdayid
'I'll
txid
from ism.deliveries where
pid=1266 or pid=2106;
I'|'l
spool off;
from ism.censusevents where
pid=1266 or pid=2106;
spool C:/temp/data/driporders.csv;
spool off;
select pid|'|'I
l
itemid
'I'lI
to_char(charttime, 'YYYY-MM-DD HH24:MI:SS')1|'|'||
chartdatel 'I'
|
spool C:/temp/data/chartevents.csv;
select pidil'i ' I
tochar(charttime, 'YYYY-MM-DD HH24:MI:SS')II'I'II
tochar(realtime, 'YYYY-MM-DD HH24:MI:SS')II''I1
itemid|'I'l|
replacenames(pid, valuel) I' I'll
valuelnumi|'l II
replace-names(pid, valueluom) I ' I
replace-names(pid, value2)11' li
value2numl
I''
replace names(pid,
replace-names(pid,
replace-names(pid,
replace-names(pid,
cgidj j'j'
cuidi
cuidi l'I'I
tochar(verifiedtime, 'YYYY-MM-DD HH24:MI:SS')||'1'11
verifiedbyl
l'I'l l
to-char(addtime, 'YYYY-MM-DD HH24:MI:SS')1|
addbyl l'I'l l
tochar(addverifytime, 'YYYY-MM-DD
HH24:MI:SS')11'
I'I
I'I
addverifybyll'I'll
duration ''
replacenames(pid, durationtype)I'I'l l
I
replacenames(pid, orderedby) 1''I
' I'll
to char(starttime, 'YYYY-MM-DD HH24:MI:SS')
tochar(stoptime, 'YYYY-MM-DD HH24:MI:SS')j|''j
replacenames(pid, schedcomments)11 I'l
replacenames(pid, discontinuecomments)11'1'11
value2uom)11''
II
II I
stopped)''
resultstatus) I' I'|
annotation) I'
I'l|
l'I'l l
scodel 'I' I
pcodel'i'll
replacenames(pid, mdinstr)11'I'll
69
Manualfor MIMIC Administrators
replace names(pid,
replace names(pid,
replace names(pid,
replace-names(pid,
replace-names(pid,
replace names(pid,
replace-names(pid,
replace-names(pid,
replace-names(pid,
replace-names(pid,
base I'
'|I
basevoll ' 'l|
rate|| 'l
dosemin 'I' I
doseminuoml|'I'l
dosemaxi 'I' II
dosemaxuoml'I' I
replacenames(pid,
scodel 'I' I
pcode
|'|
formid
from ism.formevents where
rninstr)
phinstr)
mdcosign)l
l
rnreview)l
l
phreview)l I, l
freqlabel) II I'
ll
action)
state) I'
stopstate)
I' II
education) II Ill|
spool off;
spool C:/temp/data/freeformorders.csv;
select pidiiI'lI
itemidil'I'll
tochar(charttime, 'YYYY-MM-DD HH24:MI:SS')||' 'l
chartdate 'I'll
cuidllI'I'll
tochar(verifiedtime, 'YYYY-MM-DD HH24:MI:SS')11'1'11
verifiedbyl
replace-names(pid, durationtype) I'I'll
replace_names(pid, orderedby)|I'I'l l
to-char(starttime, 'YYYY-MM-DD HH24:MI:SS')
tochar(stoptime, 'YYYY-MM-DD HH24:MI:SS')l 1'1'
replace-names(pid, schedcomments) I'l'll
replace-names(pid, discontinuecomments)ll'l II
replace_names(pid, mdinstr)l ''lI
replace-names(pid, rninstr)11'1'I
replace-names(pid, phinstr) I 'll
'll
replace-names(pid, mdcosign)l'I
replacenames(pid, rnreview) I '' I I
replace_names(pid, phreview)I|'1'1I
replacenames(pid, freqlabel)ll'|' |
replace-names(pid, action) l'IlII
replace-names(pid, state) I 'II
replace_names(pid, stopstate) |' 'l l
replace-names(pid, education)1I'1'11
replace-names(pid, order_)||'I'I
|
scodel 'I 'l l
pcodeI|'I 'l l
sidi'il li
txid
from ism.freeformorders where pid=1266 or pid=2106;
pid=1266 or pid=2106;
spool C:/temp/data/formevents.csv;
I
tochar(chartTime, 'YYYY-MM-DD HH24:MI:SS')l'l'l1
to-char(realtime, 'YYYY-MM-DD HH24:MI:SS')11' 1'1|
replace-names(pid, formtitle)1Il'1i
replace-names(pid, sectiontitle)111''11
replace-names(pid, subsectiontitle)1I'1'11
itemidil''ll
I
replace-names(pid, value_)11'I'I
replace-names(pid, valuenum)
replace-names(pid, uom) I ' I '
'
|'I|'
' '
HH24:MI:SS')
addverifyby
I 'l
duration|
lil
spool off;
I'1 I
I
scode I'I'l
l
pcodel|'I'l
sidiI'l'II
'l I
elemid I
txidI Il
lI
chartDayl
l
II
doseunits)1''LI
II
cgidil'I'I|
cuid I' 'l l
'I'l
to-char(addtime, 'YYYY-MM-DD HH24:MI:SS')
addbyl' I'll
to_char(addverifytime, 'YYYY-MM-DD
sidi 'l'I
elemid '|'||
txid
from ism.driporders where
select pidiI'l'
pid=1266 or pid=2106;
spool off;
l'i'
spool C:/temp/data/infusionorders.csv;
70
Manualfor MIMIC Administrators
to_char(charttime, 'YYYY-MM-DD HH24:MI:SS')II'I'l
select pidi
lI
chartdatel'I'l
'l
itemidl lI'll
tochar(charttime, 'YYYY-MM-DD HH24:MI:SS')
chartdatel
cuidl i' l l
' I 'l
cgidi 'I'I
cuidl l''|
I'll|
ordercgidll'I'll
l
tochar(ordertime,
to char(dateadded,
addcgidl'I'l l
targetdatel 'I'll
replacenames (pid,
replacenames(pid,
problemI II'l
to-char(probtime,
to-char(verifiedtime, 'YYYY-MM-DD HH24:MI:SS')'ll
verifiedbyl ' 'll
to-char(addtime, 'YYYY-MM-DD HH24:MI:SS')Ill
addbyl l'I'I I
tochar(addverifytime, 'YYYY-MM-DD
HH24:MI:SS')
IIII
addverifybyl
durationi
i'l
l'I'|
l
replace-names(pid, durationtype)''
l1l
replace-names(pid,
replacenames(pid,
replace-names(pid,
replacenames(pid,
rninstr) II'll
phinstr) II''
I
mdcosign)11 I'II
rnreview)1I''
I
phreview) I'I'll
freqlabel) ll' I
action)I 'I'11
state)II' 'l|
stopstate)1'1'1|
education)||'I'|l
'II II
YYYY-MM-DD HH24:MI:SS')II''ll
II'll
chartstatus)II'l
shift)l|'l'
l
variancetype)ll'I'll
variancecause)lI'l'
|
txid
from ism.interventions where
pid=1266 or pid=2106;
spool off;
spool C:/temp/data/ioevents.csv;
select pidl l''
to-char(charttime, 'YYYY-MM-DD HH24:MI:SS')Il'l'I|
tochar(realtime, 'YYYY-MM-DD HH24:MI:SS')ll'IIl
itemid 'I'll
altid' I II
I'l l
volumelI'I'l
pcodel|'I'|
sidil'I'||
elemidi l'I'll
txid
from ism.infusionorders where
I 'I'll
scodel|'I'l|
pcode|l I'll
sidl l 'Ill
elemidl 'III'
replace-names(pid, mdinstr)'l'llI
'
instructions)
orderstatus)
replace-names(pid, guideline)11'1'1I
replace-names(pid, schedcomments)ll'i'll
replace-names(pid, discontinuecomments)JI'I'll
scode
'YYYY-MM-DD HH24:MI:SS')II'|'I|
'YYYY-MM-DD HH24:MI:SS')II'I'Il
replace-names(pid, guidelinename)'
replace-names(pid, orderedby)11'1'1
I
II
tochar(starttime, 'YYYY-MM-DD HH24:MI:SS')'II'|
to-char(stoptime, 'YYYY-MM-DD HH24:MI:SS')II'I'||
replace names(pid,
replace-names(pid,
replace-names(pid,
replace-names(pid,
replace-names(pid,
replace-names(pid,
replace-names(pid,
replace-names(pid,
replace-names(pid,
replace-names(pid,
base |' I 'l
basevol|I' '|
rate|I'l||
l
l
replace-names(pid, volumeuom)I|'1'I
|
unitshungli|iI
replacenames(pid, unitshunguom)11'|'1I
newbottlel l'I I
dressingchangedlI'
pid=1266 or pid=2106;
I II
spool off;
tubingchangedlI 'I
spool C:/temp/data/interventions.csv;
assessment|I'll
replacenames(pid, stopped)|I'
replace-names(pid, estimate) I
replace-names(pid, annotation)
select pidlIl'
cgidl I IIl
itemidllili
71
'I
I
Manualfor MIMIC Administrators
cuid l'I'
scodel
l'
tochar(addtime,
'll
addbyl
pcode ' lI I
chartdatel 'I 'l l
sid l ' I'll
elemidiII II
txid
from ism.ioevents where
'YYYY-MM-DD HH24:MI:SS')
to-char(addverifytime,
pid=1266 or pid=2106;
spool C:/temp/data/medevents.csv;
select pidl
' III
tochar(charttime, 'YYYY-MM-DD HH24:MI:SS') I'
'll
itemidI 'I'll
elemid 'IIII
chartdate I I 'l|
to char(realtime, 'YYYY-MM-DD HH24:MI:SS')III'll
replace-names(pid,
replace-names(pid,
replace names(pid,
replace-names(pid,
''ll
'YYYY-MM-DD
rninstr)111''11
phinstr)11'1'11
mdcosign)11''
rnreview)11'I'1
I
IIl
l
replacenames(pid, phreview)11'1'11
replacenames(pid, freqlabel)JI'I 'l
replacenames(pid, action)1j'|' 1
volume|I'l
dose |
I'l
replacenames(pid, state)
1'1'1|
replace-names(pid, stopstate)JI' 'l|
replacenames(pid, education)|j'I'll
to_char(renewtime, 'YYYY-MM-DD HH24:MI:SS')II
dosemin'I'll
doseminuomll I'l
dosemaxIl'I'l l
dosemaxuom'I'l l
scodel' I'l l
pcodel
i'l
doseuom)1I'i'll
route)1 I'|
site)JI'I'l
stopped) I'll
annotation)11'1'1|
cgid|II'l'l
cuidII I I
pcodell'I ' |
scodel 'I I'l|
sidII II
txid
from ism.medevents where
I
HH24:MI:SS') I||''I
addverifybyl l'I'l l
duration i' I'll
replace_names(pid, durationtype)I|'II
replacenames(pid, orderedby)|I''|
tochar(starttime, 'YYYY-MM-DD HH24:MI:SS')I'|'
'I
to_char(stoptime, 'YYYY-MM-DD HH24:MI:SS')'
replace_names(pid, schedcomments)11'1'|1
replacenames(pid, discontinuecomments)I'I'l l
l
replace_names(pid, mdinstr) II' I
spool off;
replace-names(pid,
solutionidI' III
solvolumel' I 'l
replace names(pid,
replace-names(pid,
replace-names(pid,
replace names(pid,
l'I'll
' 1' 11
l
sidi'I'l
elemidl ' I' ll
txid
from ism.medorders where
pid=1266 or pid=2106;
pid=1266 or pid=2106;
spool off;
spool off;
spool C:/temp/data/noteevents.csv;
spool C:/temp/data/medorders.csv;
select pid I I II
itemidl II'l'l
tochar(charttime, 'YYYY-MM-DD HH24:MI:SS')11
chartdate
'I'l|
cuidI I'II
tochar(verifiedtime, 'YYYY-MM-DD HH24:MI:SS')
verifiedbyl l'I'l l
select pidI'II
to-char(charttime, 'YYYY-MM-DD HH24:MI:SS')IlI'|
tochar(realtime, 'YYYY-MM-DD HH24:MI:SS')II'llll
replace_names(pid, category)II'II I
replacenames(pid, title) III' I
replace_names(pid, notetext)11' ' I
I'
correction IIII
I''ll
cgid
72
I' I
Manualfor MIMIC Administrators
cuidi
cuidI 'I'll
'I'll
chartDateII'I'l
sidiI'l'll
to-char(startdate,
tochar(stopdate,
dateadded l I'll
problemnumi I'l l
replace_names(pid,
replace-names(pid,
scodeI 'I 'l l
pcodel i'lI
sidl' 'l l
elemid l'I'll
l
noteidl l'I'll
elemidl l' I'l l
txid
from ism.noteevents where
pid=1266 or pid=2106;
spool off;
spool C:/temp/data/outcomes.csv;
'YYYY-MM-DD HH24:MI:SS')1''
'YYYY-MM-DD HH24:MI:SS')I|''llI
status)|| ' 'l l
'
etiology)|I'
txid
select pid| I I II
itemidilI'l
to-char(charttime, 'YYYY-MM-DD HH24:MI:SS')
chartdatel|I 'l
cgidll''I
from ism.problems where
spool off;
lll
I
spool C:/temp/data/solutions.csv;
cuidII 'lIl
replace-names(pid, comments) 'IIIII
targetdatel 'i'll
dateaddedl il'I
addcgidl l'i'|
tochar(evaltime, 'YYYY-MM-DD HH24:MI:SS')II'I'II
evalcgidl ''ll|
'|
replace names(pid, shift)lI'I
replacenames(pid, variancetype)1'1'1I
replace names(pid, variancecause)11''I I
replace-names(pid, status)||'I' I
problemi lI 'll
tochar(probtime, 'YYYY-MM-DD HH24:MI:SS')III'II
scodelI'I'l
pid=1266 or pid=2106;
select pidi
itemidilI' '
ioitemidl I
volume I I'l
I'II
I
replace-names(pid, dos eunits) I|I
replace-names(pid, rou te)|
liii
cgidl lII'll
cuidI Il I
'l l
'l l
chartdatel'I'l
scodeI|'I
pcodeI|'I
sidIIl Il
elemidil'I'll
l
pcodel|''
sidl'I'l l
elemidi ''I
l
txid
from ism.outcomes where
LI'l
tochar(charttime, 'YY YY-MM-DD HH24:MI:SS')II'I'II
l
txid
from ism.solutions where
pid=1266 or pid=2106;
spool off;
pid=1266 or pid=2106;
spool off;
spool C:/temp/data/totalbalevents.csv;
spool C:/temp/data/problems.csv;
select pidi I'l
to-char(charttime, 'YYYY-MM-DD HH24:MI:SS')I'I'11
chartdatel' I'l l
'l'l
itemidI
tochar(realtime, 'YYYY-MM-DD HH24:MI:SS')I'I'IIl
pervolumelI'I'l l
select pidlI lII
itemidll'I'll
tochar(charttime, 'YYYY-MM-DD HH24:MI:SS')'1111
chartdatel ' I'll
cgidj ''II
addcgidl 'I'll
cumvolumelI' I
Il
replace-names(pid, accumperiod)II'I'l
73
l
Manualfor MIMIC Administrators
replace-names(pid, approx)11''11
reset||'|'||
replace-names(pid, stopped)11'I'II
replace-names(pid, annotation)11'1'11
cgidli'|'
cuid I' ' I
scodel' I'll
pcodel'|'||
sid l' I'll
txid I 'l|
elemid
from ism.totalbalevents where
pid=1266 or pid=2106;
spool off;
spool C:/temp/data/resultevents.csv;
select pidili'|i
resultid l' I'l
l
to char(chartTime, 'YYYY-MM-DD HH24:MI:SS')||'1'
chartDatel|'i'l
cgidl li'l
|
l
cuidi l'|'I
replace names(pid, resulttext)11'1'11
tochar(sourcetime, 'YYYY-MM-DD HH24:MI:SS')11'1'11
firstresultf
i'l
nextresulti I'l
l
replace-names(pid, status) |'ll
sid i| i I
txid
from ism.resultevents where pid=1266 or pid=2106;
spool off;
74
Manualfor MIMIC Administrators