Alistair E.W. JohnsonpersName, Tom J. PollardpersName, Lu ShenpersName, Li-wei H. LehmanpersName, Mengling FengpersName, Mohammad GhassemipersName, Benjamin MoodypersName, Peter SzolovitspersName, Leo Anthony CelipersName, Roger G. MarkpersName (2016date). “MIMIC-III, a freely accessible critical care database.” Scientific Datatitle·j.
Object of study — the structure, provenance, privacy processing, access model, and research uses of the MIMIC-IIIterm critical-care database
Research question — how a comprehensive deidentified critical-care database can be assembled, validated, documented, and made broadly usable for reproducible research
Contribution — releases and documents MIMIC-IIIterm, a linked twenty-six-table clinical database with deidentification, controlled access, validation, and collaborative code infrastructure
Cross-disciplinary analysis
content-tags & facets:
phenomenon · claim-type · cross-domain-transfer · mechanism · claim-relation · replication-status · limitation — grounded in the full text| phenomenon | the unrealized research value of fragmented hospital data and the reproducibility benefits of accessible integrated clinical data — “Despite this advance, interoperability of digital systems remains an open issue, leading to challenges in data integration. As a result, the potential that hospital data offers in terms of understanding and improving care is yet to be fully realized. In parallel, the scientific research community is increasingly coming under criticism for the lack of reproducibility of studies 2 .” | |
| claim-type | method — “The MIMIC-III database was populated with data that had been acquired during routine hospital care, so there was no associated burden on caregivers and no interference with their workflow. Data was downloaded from several sources, including:” | |
| method — evidence | — “Before data was incorporated into the MIMIC-III database, it was first deidentified in accordance with Health Insurance Portability and Accountability Act (HIPAA) standards using structured data cleansing and date shifting. The deidentification process for structured data required the removal of all eighteen of the identifying data elements listed in HIPAA, including fields such as patient name, telephone number, address, and dates. In particular, dates were shifted into the future by a random offset for each individual patient in a consistent manner to preserve intervals, resulting in stays which occur sometime between the years 2100 and 2200. Time of day, day of the week, and approximate seasonality were conserved during date shifting. Dates of birth for patients aged over 89 were shifted to obscure their true age and comply with HIPAA regulations: these patients appear in the database with ages of over 300 years.” | |
| object of study — evidence | — “MIMIC-III (‘Medical Information Mart for Intensive Care’) is a large, single-center database comprising information relating to patients admitted to critical care units at a large tertiary care hospital. Data includes vital signs, medications, laboratory measurements, observations and notes charted by care providers, fluid balance, procedure codes, diagnostic codes, imaging reports, hospital length of stay, survival data, and more. The database supports applications including academic and industrial research, quality improvement initiatives, and higher education coursework.” | |
| research question — evidence | — “Here we report the release of the MIMIC-III database, an update to the widely-used MIMIC-II database (Data Citation 1). MIMIC-III integrates deidentified, comprehensive clinical data of patients admitted to the Beth Israel Deaconess Medical Center in Boston, Massachusetts, and makes it widely accessible to researchers internationally under a data use agreement ( Fig. 1 ). The open nature of the data allows clinical studies to be reproduced and improved in ways that would not otherwise be possible.” | |
| contribution — evidence | — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | |
| mechanism | integration of deidentified clinical data with international researcher access makes studies reproducible and improvable — “Here we report the release of the MIMIC-III database, an update to the widely-used MIMIC-II database (Data Citation 1). MIMIC-III integrates deidentified, comprehensive clinical data of patients admitted to the Beth Israel Deaconess Medical Center in Boston, Massachusetts, and makes it widely accessible to researchers internationally under a data use agreement ( Fig. 1 ). The open nature of the data allows clinical studies to be reproduced and improved in ways that would not otherwise be possible.” | mechanisms[0] |
| mechanism | source-specific suffixes preserve data that cannot be safely merged across CareVue and MetaVision — “With exception to data relating to fluid intake, which differed significantly in structure between the CareVue and MetaVision systems, data was merged when building the database tables. Data which could not be merged is given a suffix to denote the data source. For example, inputs for patients monitored with the CareVue system are stored in INPUTEVENTS_CV, whereas inputs for patients monitored with the Metavision system are stored in INPUTEVENTS_MV. Additional information was collected from hospital and laboratory health record systems, including:” | mechanisms[1] |
| mechanism | concept mappings to LOINC, RxNorm, and common data models support standardized analysis — “Several projects are ongoing to map concepts within the MIMIC database to standardized dictionaries. For example, researchers at the National Library of Medicine National Institutes of Health have mapped laboratory tests and medications in MIMIC-II to LOINC and RxNorm, respectively 4 . Efforts are also underway to transform MIMIC to common data models, such as the Observational Medical Outcomes Partnership Common Data Model, to support the application of standardized tools and methods 5 . These developments are progressively incorporated into the MIMIC database where possible.” | mechanisms[2] |
| mechanism | structured cleansing removes HIPAA identifiers while consistent per-patient date offsets preserve intervals — “Before data was incorporated into the MIMIC-III database, it was first deidentified in accordance with Health Insurance Portability and Accountability Act (HIPAA) standards using structured data cleansing and date shifting. The deidentification process for structured data required the removal of all eighteen of the identifying data elements listed in HIPAA, including fields such as patient name, telephone number, address, and dates. In particular, dates were shifted into the future by a random offset for each individual patient in a consistent manner to preserve intervals, resulting in stays which occur sometime between the years 2100 and 2200. Time of day, day of the week, and approximate seasonality were conserved during date shifting. Dates of birth for patients aged over 89 were shifted to obscure their true age and comply with HIPAA regulations: these patients appear in the database with ages of over 300 years.” | mechanisms[3] |
| mechanism | dictionary lookup and regular-expression pattern matching remove protected information from narrative fields — “Protected health information was removed from free text fields, such as diagnostic reports and physician notes, using a rigorously evaluated deidentification system based on extensive dictionary look-ups and pattern-matching with regular expressions 6 . The components of this deidentification system are continually expanded as new data is acquired.” | mechanisms[4] |
| mechanism | table identifiers connect patient, admission, and ICU-stay records across the relational schema — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | mechanisms[5] |
| mechanism | joining CHARTEVENTS and D_ITEMS on ITEMID recovers the concept represented by an identifier — “Tables prefixed with ‘D_’ are dictionary tables and provide definitions for identifiers. For example, every row of CHARTEVENTS is associated with a single ITEMID which represents the concept measured, but it does not contain the actual name of the measurement. By joining CHARTEVENTS and D_ITEMS on ITEMID, it is possible to identify the concept represented by a given ITEMID. Further detail is provided below.” | mechanisms[6] |
| mechanism | version control, collaborative development, and feedback support readable shared scientific code — “Best practice for scientific computing was followed where possible 7 . Code used to build MIMIC-III was version controlled and developed collaboratively within the laboratory. This approach encouraged and facilitated sharing of readable code and documentation, as well as frequent feedback from colleagues.” | mechanisms[7] |
| mechanism | issue tracking records limitations and supports minor corrective database releases — “Issue tracking is used to ensure that limitations of the data and code are clearly documented and are dealt with as appropriate. The research community is encouraged to report and address issues as they are found, and a system for releasing minor database updates is in place.” | mechanisms[8] |
| mechanism | datathons assemble clinical, data-science, and domain expertise around reproducible research — “A series of 'datathons' have been held alongside development of the MIMIC database. These events assemble caregivers, data scientists, and those with domain-specific knowledge with the aim of creating ideas and producing clinically relevant, reproducible research 14 . In parallel the events introduce new researchers to MIMIC and provide a platform for continuous review and development of code and research.” | mechanisms[9] |
| introduces | the international release of the deidentified MIMIC-III clinical database — “Here we report the release of the MIMIC-III database, an update to the widely-used MIMIC-II database (Data Citation 1). MIMIC-III integrates deidentified, comprehensive clinical data of patients admitted to the Beth Israel Deaconess Medical Center in Boston, Massachusetts, and makes it widely accessible to researchers internationally under a data use agreement ( Fig. 1 ). The open nature of the data allows clinical studies to be reproduced and improved in ways that would not otherwise be possible.” | claim_relations[0] |
| extends | MIMIC-II with a third, broader major database release — “The Laboratory for Computational Physiology at Massachusetts Institute of Technology is an interdisciplinary team of data scientists and practicing physicians. MIMIC-III is the third iteration of the MIMIC critical care database, enabling us to draw upon prior experience with regard to data management and integration 3 .” | claim_relations[1] |
| supports | reproducible and improvable clinical studies through accessible underlying data — “Here we report the release of the MIMIC-III database, an update to the widely-used MIMIC-II database (Data Citation 1). MIMIC-III integrates deidentified, comprehensive clinical data of patients admitted to the Beth Israel Deaconess Medical Center in Boston, Massachusetts, and makes it widely accessible to researchers internationally under a data use agreement ( Fig. 1 ). The open nature of the data allows clinical studies to be reproduced and improved in ways that would not otherwise be possible.” | claim_relations[2] |
| qualifies | the claim that analysis is unrestricted — “To recognize the increasingly broad usage of MIMIC, we have renamed the full title of the database from ‘Multiparameter Intelligent Monitoring in Intensive Care’ to ‘Medical Information Mart for Intensive Care’. The MIMIC-III critical care database is unique and notable for the following reasons: it is the only freely accessible critical care database of its kind; the dataset spans more than a decade, with detailed information about individual patient care; analysis is unrestricted once a data use agreement is accepted, enabling clinical research and education around the world.” | claim_relations[3] |
| validates | fidelity of MIMIC-III to raw hospital data — “The number of structural changes were minimized to achieve the desired level of deidentification and data schema, helping to ensure that MIMIC-III closely represents the raw data collected within the Beth Israel Deaconess Medical Center.” | claim_relations[4] |
| recommends | keeping structurally different source tables independent and constructing research-specific views — “In some cases it would be possible to merge tables—for example, the D_ICD_PROCEDURES and CPTEVENTS tables both contain detail relating to procedures and could be combined—but our approach is to keep the tables independent for clarity, since the data sources are significantly different. Rather than combining the tables within MIMIC data model, we suggest researchers develop database views and transforms as appropriate.” | claim_relations[5] |
| supports | collaborative, iterative, and self-checking analysis-code development — “Our experience is that many researchers work independently to produce code for data processing and analysis. We seek to move towards a more collaborative, iterative, and self-checking development process where researchers work together on a shared code base. To facilitate collaboration, a public code repository has been created to encourage researchers to develop and share code collectively: https://github.com/MIT-LCP/mimic-code .” | claim_relations[6] |
| qualifies | freely accessible critical-care data — “MIMIC-III is provided as a collection of comma separated value (CSV) files, along with scripts to help with importing the data into database systems including PostreSQL, MySQL, and MonetDB. As the database contains detailed information regarding the clinical care of patients, it must be treated with appropriate care and respect. Researchers are required to formally request access via a process documented on the MIMIC website 8 . There are two key steps that must be completed before access is granted:” | claim_relations[7] |
| sense | MIMIC-III - a large single-center database integrating deidentified clinical data from critical-care admissions — “MIMIC-III (‘Medical Information Mart for Intensive Care’) is a large, single-center database comprising information relating to patients admitted to critical care units at a large tertiary care hospital. Data includes vital signs, medications, laboratory measurements, observations and notes charted by care providers, fluid balance, procedure codes, diagnostic codes, imaging reports, hospital length of stay, survival data, and more. The database supports applications including academic and industrial research, quality improvement initiatives, and higher education coursework.” | senses[0] |
| sense | Medical Information Mart for Intensive Care - the renamed full title chosen to reflect MIMIC's increasingly broad use — “To recognize the increasingly broad usage of MIMIC, we have renamed the full title of the database from ‘Multiparameter Intelligent Monitoring in Intensive Care’ to ‘Medical Information Mart for Intensive Care’. The MIMIC-III critical care database is unique and notable for the following reasons:” | senses[1] |
| sense | interoperability - the unresolved capacity of hospital digital systems to support integration across sources — “Despite this advance, interoperability of digital systems remains an open issue, leading to challenges in data integration. As a result, the potential that hospital data offers in terms of understanding and improving care is yet to be fully realized. In parallel, the scientific research community is increasingly coming under criticism for the lack of reproducibility of studies 2 .” | senses[2] |
| sense | reproducibility - the ability to repeat and improve clinical studies using openly available underlying data — “Here we report the release of the MIMIC-III database, an update to the widely-used MIMIC-II database (Data Citation 1). MIMIC-III integrates deidentified, comprehensive clinical data of patients admitted to the Beth Israel Deaconess Medical Center in Boston, Massachusetts, and makes it widely accessible to researchers internationally under a data use agreement ( Fig. 1 ). The open nature of the data allows clinical studies to be reproduced and improved in ways that would not otherwise be possible.” | senses[3] |
| sense | date shifting - a consistent random offset per patient that obscures dates while preserving clinical intervals — “Before data was incorporated into the MIMIC-III database, it was first deidentified in accordance with Health Insurance Portability and Accountability Act (HIPAA) standards using structured data cleansing and date shifting. The deidentification process for structured data required the removal of all eighteen of the identifying data elements listed in HIPAA, including fields such as patient name, telephone number, address, and dates. In particular, dates were shifted into the future by a random offset for each individual patient in a consistent manner to preserve intervals, resulting in stays which occur sometime between the years 2100 and 2200. Time of day, day of the week, and approximate seasonality were conserved during date shifting. Dates of birth for patients aged over 89 were shifted to obscure their true age and comply with HIPAA regulations: these patients appear in the database with ages of over 300 years.” | senses[4] |
| sense | relational database - twenty-six tables linked by patient, hospital-admission, and ICU-stay identifiers — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | senses[5] |
| sense | dictionary tables - cross-reference tables that turn identifiers such as ITEMID into named clinical concepts — “Tables prefixed with ‘D_’ are dictionary tables and provide definitions for identifiers. For example, every row of CHARTEVENTS is associated with a single ITEMID which represents the concept measured, but it does not contain the actual name of the measurement. By joining CHARTEVENTS and D_ITEMS on ITEMID, it is possible to identify the concept represented by a given ITEMID. Further detail is provided below.” | senses[6] |
| sense | data model - a deliberately minimally transformed representation balancing interpretation against ground-truth fidelity — “Developing the MIMIC data model involved balancing simplicity of interpretation against closeness to ground truth. As such, the model is a reflection of underlying data sources, modified over iterations of the MIMIC database in response to user feedback. Table 4 describes how data is distributed across the data tables. Care has been taken to avoid making assumptions about the underlying data when carrying out transformations, so MIMIC-III closely represents the raw hospital data.” | senses[7] |
| sense | datathons - cross-disciplinary events for producing clinically relevant reproducible research and onboarding new users — “A series of 'datathons' have been held alongside development of the MIMIC database. These events assemble caregivers, data scientists, and those with domain-specific knowledge with the aim of creating ideas and producing clinically relevant, reproducible research 14 . In parallel the events introduce new researchers to MIMIC and provide a platform for continuous review and development of code and research.” | senses[8] |
| sense | shared code base - a collaborative, iterative, self-checking alternative to independent one-off analysis code — “Our experience is that many researchers work independently to produce code for data processing and analysis. We seek to move towards a more collaborative, iterative, and self-checking development process where researchers work together on a shared code base. To facilitate collaboration, a public code repository has been created to encourage researchers to develop and share code collectively: https://github.com/MIT-LCP/mimic-code .” | senses[9] |
| note | the international release of the deidentified MIMIC-III clinical database — The paper explicitly reports the release. — “Here we report the release of the MIMIC-III database, an update to the widely-used MIMIC-II database (Data Citation 1). MIMIC-III integrates deidentified, comprehensive clinical data of patients admitted to the Beth Israel Deaconess Medical Center in Boston, Massachusetts, and makes it widely accessible to researchers internationally under a data use agreement ( Fig. 1 ). The open nature of the data allows clinical studies to be reproduced and improved in ways that would not otherwise be possible.” | claim_relations[0] |
| weight | the international release of the deidentified MIMIC-III clinical database — 0.99 — “Here we report the release of the MIMIC-III database, an update to the widely-used MIMIC-II database (Data Citation 1). MIMIC-III integrates deidentified, comprehensive clinical data of patients admitted to the Beth Israel Deaconess Medical Center in Boston, Massachusetts, and makes it widely accessible to researchers internationally under a data use agreement ( Fig. 1 ). The open nature of the data allows clinical studies to be reproduced and improved in ways that would not otherwise be possible.” | claim_relations[0] |
| note | MIMIC-II with a third, broader major database release — MIMIC-III is stated to be the third iteration built from prior experience. — “The Laboratory for Computational Physiology at Massachusetts Institute of Technology is an interdisciplinary team of data scientists and practicing physicians. MIMIC-III is the third iteration of the MIMIC critical care database, enabling us to draw upon prior experience with regard to data management and integration 3 .” | claim_relations[1] |
| weight | MIMIC-II with a third, broader major database release — 0.99 — “The Laboratory for Computational Physiology at Massachusetts Institute of Technology is an interdisciplinary team of data scientists and practicing physicians. MIMIC-III is the third iteration of the MIMIC critical care database, enabling us to draw upon prior experience with regard to data management and integration 3 .” | claim_relations[1] |
| note | reproducible and improvable clinical studies through accessible underlying data — The stated rationale for open data. — “Here we report the release of the MIMIC-III database, an update to the widely-used MIMIC-II database (Data Citation 1). MIMIC-III integrates deidentified, comprehensive clinical data of patients admitted to the Beth Israel Deaconess Medical Center in Boston, Massachusetts, and makes it widely accessible to researchers internationally under a data use agreement ( Fig. 1 ). The open nature of the data allows clinical studies to be reproduced and improved in ways that would not otherwise be possible.” | claim_relations[2] |
| weight | reproducible and improvable clinical studies through accessible underlying data — 0.95 — “Here we report the release of the MIMIC-III database, an update to the widely-used MIMIC-II database (Data Citation 1). MIMIC-III integrates deidentified, comprehensive clinical data of patients admitted to the Beth Israel Deaconess Medical Center in Boston, Massachusetts, and makes it widely accessible to researchers internationally under a data use agreement ( Fig. 1 ). The open nature of the data allows clinical studies to be reproduced and improved in ways that would not otherwise be possible.” | claim_relations[2] |
| note | the claim that analysis is unrestricted — Unrestricted analysis begins only once a data-use agreement is accepted. — “To recognize the increasingly broad usage of MIMIC, we have renamed the full title of the database from ‘Multiparameter Intelligent Monitoring in Intensive Care’ to ‘Medical Information Mart for Intensive Care’. The MIMIC-III critical care database is unique and notable for the following reasons: it is the only freely accessible critical care database of its kind; the dataset spans more than a decade, with detailed information about individual patient care; analysis is unrestricted once a data use agreement is accepted, enabling clinical research and education around the world.” | claim_relations[3] |
| weight | the claim that analysis is unrestricted — 0.99 — “To recognize the increasingly broad usage of MIMIC, we have renamed the full title of the database from ‘Multiparameter Intelligent Monitoring in Intensive Care’ to ‘Medical Information Mart for Intensive Care’. The MIMIC-III critical care database is unique and notable for the following reasons: it is the only freely accessible critical care database of its kind; the dataset spans more than a decade, with detailed information about individual patient care; analysis is unrestricted once a data use agreement is accepted, enabling clinical research and education around the world.” | claim_relations[3] |
| note | fidelity of MIMIC-III to raw hospital data — Minimal structural change is the stated technical-validation strategy. — “The number of structural changes were minimized to achieve the desired level of deidentification and data schema, helping to ensure that MIMIC-III closely represents the raw data collected within the Beth Israel Deaconess Medical Center.” | claim_relations[4] |
| weight | fidelity of MIMIC-III to raw hospital data — 0.95 — “The number of structural changes were minimized to achieve the desired level of deidentification and data schema, helping to ensure that MIMIC-III closely represents the raw data collected within the Beth Israel Deaconess Medical Center.” | claim_relations[4] |
| note | keeping structurally different source tables independent and constructing research-specific views — The paper states this design recommendation directly. — “In some cases it would be possible to merge tables—for example, the D_ICD_PROCEDURES and CPTEVENTS tables both contain detail relating to procedures and could be combined—but our approach is to keep the tables independent for clarity, since the data sources are significantly different. Rather than combining the tables within MIMIC data model, we suggest researchers develop database views and transforms as appropriate.” | claim_relations[5] |
| weight | keeping structurally different source tables independent and constructing research-specific views — 0.95 — “In some cases it would be possible to merge tables—for example, the D_ICD_PROCEDURES and CPTEVENTS tables both contain detail relating to procedures and could be combined—but our approach is to keep the tables independent for clarity, since the data sources are significantly different. Rather than combining the tables within MIMIC data model, we suggest researchers develop database views and transforms as appropriate.” | claim_relations[5] |
| note | collaborative, iterative, and self-checking analysis-code development — The public repository is presented as infrastructure for this process. — “Our experience is that many researchers work independently to produce code for data processing and analysis. We seek to move towards a more collaborative, iterative, and self-checking development process where researchers work together on a shared code base. To facilitate collaboration, a public code repository has been created to encourage researchers to develop and share code collectively: https://github.com/MIT-LCP/mimic-code .” | claim_relations[6] |
| weight | collaborative, iterative, and self-checking analysis-code development — 0.95 — “Our experience is that many researchers work independently to produce code for data processing and analysis. We seek to move towards a more collaborative, iterative, and self-checking development process where researchers work together on a shared code base. To facilitate collaboration, a public code repository has been created to encourage researchers to develop and share code collectively: https://github.com/MIT-LCP/mimic-code .” | claim_relations[6] |
| note | freely accessible critical-care data — Access requires training and a signed data-use agreement. — “MIMIC-III is provided as a collection of comma separated value (CSV) files, along with scripts to help with importing the data into database systems including PostreSQL, MySQL, and MonetDB. As the database contains detailed information regarding the clinical care of patients, it must be treated with appropriate care and respect. Researchers are required to formally request access via a process documented on the MIMIC website 8 . There are two key steps that must be completed before access is granted:” | claim_relations[7] |
| weight | freely accessible critical-care data — 0.99 — “MIMIC-III is provided as a collection of comma separated value (CSV) files, along with scripts to help with importing the data into database systems including PostreSQL, MySQL, and MonetDB. As the database contains detailed information regarding the clinical care of patients, it must be treated with appropriate care and respect. Researchers are required to formally request access via a process documented on the MIMIC website 8 . There are two key steps that must be completed before access is granted:” | claim_relations[7] |
| note | MIMIC-III —is-a→ relational database — Direct categorical statement. — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | concept_edges[0] |
| relation | MIMIC-III —is-a→ relational database — MIMIC-III is a relational database. — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | concept_edges[0] |
| note | MIMIC-III —is-a→ MIMIC critical care database — Direct lineage classification. — “The Laboratory for Computational Physiology at Massachusetts Institute of Technology is an interdisciplinary team of data scientists and practicing physicians. MIMIC-III is the third iteration of the MIMIC critical care database, enabling us to draw upon prior experience with regard to data management and integration 3 .” | concept_edges[1] |
| relation | MIMIC-III —is-a→ MIMIC critical care database — MIMIC-III is the third iteration of the MIMIC critical care database. — “The Laboratory for Computational Physiology at Massachusetts Institute of Technology is an interdisciplinary team of data scientists and practicing physicians. MIMIC-III is the third iteration of the MIMIC critical care database, enabling us to draw upon prior experience with regard to data management and integration 3 .” | concept_edges[1] |
| note | INPUTEVENTS_CV —contrasted-with→ INPUTEVENTS_MV — Explicit whereas contrast tied to distinct source structures. — “With exception to data relating to fluid intake, which differed significantly in structure between the CareVue and MetaVision systems, data was merged when building the database tables. Data which could not be merged is given a suffix to denote the data source. For example, inputs for patients monitored with the CareVue system are stored in INPUTEVENTS_CV, whereas inputs for patients monitored with the Metavision system are stored in INPUTEVENTS_MV. Additional information was collected from hospital and laboratory health record systems, including:” | concept_edges[2] |
| relation | INPUTEVENTS_CV —contrasted-with→ INPUTEVENTS_MV — CareVue input events are stored in INPUTEVENTS_CV, whereas MetaVision input events are stored in INPUTEVENTS_MV. — “With exception to data relating to fluid intake, which differed significantly in structure between the CareVue and MetaVision systems, data was merged when building the database tables. Data which could not be merged is given a suffix to denote the data source. For example, inputs for patients monitored with the CareVue system are stored in INPUTEVENTS_CV, whereas inputs for patients monitored with the Metavision system are stored in INPUTEVENTS_MV. Additional information was collected from hospital and laboratory health record systems, including:” | concept_edges[2] |
| weight | INPUTEVENTS_CV —contrasted-with→ INPUTEVENTS_MV — 0.95 — “With exception to data relating to fluid intake, which differed significantly in structure between the CareVue and MetaVision systems, data was merged when building the database tables. Data which could not be merged is given a suffix to denote the data source. For example, inputs for patients monitored with the CareVue system are stored in INPUTEVENTS_CV, whereas inputs for patients monitored with the Metavision system are stored in INPUTEVENTS_MV. Additional information was collected from hospital and laboratory health record systems, including:” | concept_edges[2] |
| relation | interoperability → data integration — Unresolved interoperability creates data-integration challenges. — “Despite this advance, interoperability of digital systems remains an open issue, leading to challenges in data integration. As a result, the potential that hospital data offers in terms of understanding and improving care is yet to be fully realized. In parallel, the scientific research community is increasingly coming under criticism for the lack of reproducibility of studies 2 .” | unhoused_relations[0] |
| weight | interoperability → data integration — 0.95 — “Despite this advance, interoperability of digital systems remains an open issue, leading to challenges in data integration. As a result, the potential that hospital data offers in terms of understanding and improving care is yet to be fully realized. In parallel, the scientific research community is increasingly coming under criticism for the lack of reproducibility of studies 2 .” | unhoused_relations[0] |
| relation | MIMIC-III → MIMIC-II — MIMIC-III updates the widely used MIMIC-II database. — “Here we report the release of the MIMIC-III database, an update to the widely-used MIMIC-II database (Data Citation 1). MIMIC-III integrates deidentified, comprehensive clinical data of patients admitted to the Beth Israel Deaconess Medical Center in Boston, Massachusetts, and makes it widely accessible to researchers internationally under a data use agreement ( Fig. 1 ). The open nature of the data allows clinical studies to be reproduced and improved in ways that would not otherwise be possible.” | unhoused_relations[1] |
| weight | MIMIC-III → MIMIC-II — 0.99 — “Here we report the release of the MIMIC-III database, an update to the widely-used MIMIC-II database (Data Citation 1). MIMIC-III integrates deidentified, comprehensive clinical data of patients admitted to the Beth Israel Deaconess Medical Center in Boston, Massachusetts, and makes it widely accessible to researchers internationally under a data use agreement ( Fig. 1 ). The open nature of the data allows clinical studies to be reproduced and improved in ways that would not otherwise be possible.” | unhoused_relations[1] |
| relation | Medical Information Mart for Intensive Care → MIMIC-III — The expanded title of MIMIC was changed to Medical Information Mart for Intensive Care. — “To recognize the increasingly broad usage of MIMIC, we have renamed the full title of the database from ‘Multiparameter Intelligent Monitoring in Intensive Care’ to ‘Medical Information Mart for Intensive Care’. The MIMIC-III critical care database is unique and notable for the following reasons:” | unhoused_relations[2] |
| relation | simplicity of interpretation → closeness to ground truth — The data model balances simplicity of interpretation against closeness to ground truth. — “Developing the MIMIC data model involved balancing simplicity of interpretation against closeness to ground truth. As such, the model is a reflection of underlying data sources, modified over iterations of the MIMIC database in response to user feedback. Table 4 describes how data is distributed across the data tables. Care has been taken to avoid making assumptions about the underlying data when carrying out transformations, so MIMIC-III closely represents the raw hospital data.” | unhoused_relations[3] |
| weight | simplicity of interpretation → closeness to ground truth — 0.95 — “Developing the MIMIC data model involved balancing simplicity of interpretation against closeness to ground truth. As such, the model is a reflection of underlying data sources, modified over iterations of the MIMIC database in response to user feedback. Table 4 describes how data is distributed across the data tables. Care has been taken to avoid making assumptions about the underlying data when carrying out transformations, so MIMIC-III closely represents the raw hospital data.” | unhoused_relations[3] |
| relation | SUBJECT_ID → adult patients — SUBJECT_ID refers to a unique patient represented in MIMIC-III. — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | unhoused_relations[4] |
| weight | SUBJECT_ID → adult patients — 0.95 — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | unhoused_relations[4] |
| relation | HADM_ID → hospital admissions — HADM_ID refers to a unique hospital admission. — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | unhoused_relations[5] |
| weight | HADM_ID → hospital admissions — 0.95 — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | unhoused_relations[5] |
| relation | ICUSTAY_ID → hospital admissions — ICUSTAY_ID refers to a unique intensive-care-unit admission. — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | unhoused_relations[6] |
| weight | ICUSTAY_ID → hospital admissions — 0.9 — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | unhoused_relations[6] |
| relation | CareVue Clinical Information System → INPUTEVENTS_CV — CareVue input events are stored in INPUTEVENTS_CV. — “With exception to data relating to fluid intake, which differed significantly in structure between the CareVue and MetaVision systems, data was merged when building the database tables. Data which could not be merged is given a suffix to denote the data source. For example, inputs for patients monitored with the CareVue system are stored in INPUTEVENTS_CV, whereas inputs for patients monitored with the Metavision system are stored in INPUTEVENTS_MV. Additional information was collected from hospital and laboratory health record systems, including:” | unhoused_relations[7] |
| relation | MetaVision ICU → INPUTEVENTS_MV — MetaVision input events are stored in INPUTEVENTS_MV. — “With exception to data relating to fluid intake, which differed significantly in structure between the CareVue and MetaVision systems, data was merged when building the database tables. Data which could not be merged is given a suffix to denote the data source. For example, inputs for patients monitored with the CareVue system are stored in INPUTEVENTS_CV, whereas inputs for patients monitored with the Metavision system are stored in INPUTEVENTS_MV. Additional information was collected from hospital and laboratory health record systems, including:” | unhoused_relations[8] |
| relation | LOINC → laboratory measurements — MIMIC laboratory tests were mapped to LOINC. — “Several projects are ongoing to map concepts within the MIMIC database to standardized dictionaries. For example, researchers at the National Library of Medicine National Institutes of Health have mapped laboratory tests and medications in MIMIC-II to LOINC and RxNorm, respectively 4 . Efforts are also underway to transform MIMIC to common data models, such as the Observational Medical Outcomes Partnership Common Data Model, to support the application of standardized tools and methods 5 . These developments are progressively incorporated into the MIMIC database where possible.” | unhoused_relations[9] |
| weight | LOINC → laboratory measurements — 0.95 — “Several projects are ongoing to map concepts within the MIMIC database to standardized dictionaries. For example, researchers at the National Library of Medicine National Institutes of Health have mapped laboratory tests and medications in MIMIC-II to LOINC and RxNorm, respectively 4 . Efforts are also underway to transform MIMIC to common data models, such as the Observational Medical Outcomes Partnership Common Data Model, to support the application of standardized tools and methods 5 . These developments are progressively incorporated into the MIMIC database where possible.” | unhoused_relations[9] |
| relation | RxNorm → MIMIC-III — MIMIC medications were mapped to RxNorm. — “Several projects are ongoing to map concepts within the MIMIC database to standardized dictionaries. For example, researchers at the National Library of Medicine National Institutes of Health have mapped laboratory tests and medications in MIMIC-II to LOINC and RxNorm, respectively 4 . Efforts are also underway to transform MIMIC to common data models, such as the Observational Medical Outcomes Partnership Common Data Model, to support the application of standardized tools and methods 5 . These developments are progressively incorporated into the MIMIC database where possible.” | unhoused_relations[10] |
| weight | RxNorm → MIMIC-III — 0.95 — “Several projects are ongoing to map concepts within the MIMIC database to standardized dictionaries. For example, researchers at the National Library of Medicine National Institutes of Health have mapped laboratory tests and medications in MIMIC-II to LOINC and RxNorm, respectively 4 . Efforts are also underway to transform MIMIC to common data models, such as the Observational Medical Outcomes Partnership Common Data Model, to support the application of standardized tools and methods 5 . These developments are progressively incorporated into the MIMIC database where possible.” | unhoused_relations[10] |
| relation | structured data cleansing → protected health information — Structured cleansing removes HIPAA identifying elements from clinical data. — “Before data was incorporated into the MIMIC-III database, it was first deidentified in accordance with Health Insurance Portability and Accountability Act (HIPAA) standards using structured data cleansing and date shifting. The deidentification process for structured data required the removal of all eighteen of the identifying data elements listed in HIPAA, including fields such as patient name, telephone number, address, and dates. In particular, dates were shifted into the future by a random offset for each individual patient in a consistent manner to preserve intervals, resulting in stays which occur sometime between the years 2100 and 2200. Time of day, day of the week, and approximate seasonality were conserved during date shifting. Dates of birth for patients aged over 89 were shifted to obscure their true age and comply with HIPAA regulations: these patients appear in the database with ages of over 300 years.” | unhoused_relations[11] |
| weight | structured data cleansing → protected health information — 0.99 — “Before data was incorporated into the MIMIC-III database, it was first deidentified in accordance with Health Insurance Portability and Accountability Act (HIPAA) standards using structured data cleansing and date shifting. The deidentification process for structured data required the removal of all eighteen of the identifying data elements listed in HIPAA, including fields such as patient name, telephone number, address, and dates. In particular, dates were shifted into the future by a random offset for each individual patient in a consistent manner to preserve intervals, resulting in stays which occur sometime between the years 2100 and 2200. Time of day, day of the week, and approximate seasonality were conserved during date shifting. Dates of birth for patients aged over 89 were shifted to obscure their true age and comply with HIPAA regulations: these patients appear in the database with ages of over 300 years.” | unhoused_relations[11] |
| relation | date shifting → ground truth — Date shifting preserves intervals while intentionally changing calendar dates. — “Before data was incorporated into the MIMIC-III database, it was first deidentified in accordance with Health Insurance Portability and Accountability Act (HIPAA) standards using structured data cleansing and date shifting. The deidentification process for structured data required the removal of all eighteen of the identifying data elements listed in HIPAA, including fields such as patient name, telephone number, address, and dates. In particular, dates were shifted into the future by a random offset for each individual patient in a consistent manner to preserve intervals, resulting in stays which occur sometime between the years 2100 and 2200. Time of day, day of the week, and approximate seasonality were conserved during date shifting. Dates of birth for patients aged over 89 were shifted to obscure their true age and comply with HIPAA regulations: these patients appear in the database with ages of over 300 years.” | unhoused_relations[12] |
| weight | date shifting → ground truth — 0.99 — “Before data was incorporated into the MIMIC-III database, it was first deidentified in accordance with Health Insurance Portability and Accountability Act (HIPAA) standards using structured data cleansing and date shifting. The deidentification process for structured data required the removal of all eighteen of the identifying data elements listed in HIPAA, including fields such as patient name, telephone number, address, and dates. In particular, dates were shifted into the future by a random offset for each individual patient in a consistent manner to preserve intervals, resulting in stays which occur sometime between the years 2100 and 2200. Time of day, day of the week, and approximate seasonality were conserved during date shifting. Dates of birth for patients aged over 89 were shifted to obscure their true age and comply with HIPAA regulations: these patients appear in the database with ages of over 300 years.” | unhoused_relations[12] |
| relation | dictionary look-ups → protected health information — Dictionary look-ups help remove protected health information from free text. — “Protected health information was removed from free text fields, such as diagnostic reports and physician notes, using a rigorously evaluated deidentification system based on extensive dictionary look-ups and pattern-matching with regular expressions 6 . The components of this deidentification system are continually expanded as new data is acquired.” | unhoused_relations[13] |
| weight | dictionary look-ups → protected health information — 0.95 — “Protected health information was removed from free text fields, such as diagnostic reports and physician notes, using a rigorously evaluated deidentification system based on extensive dictionary look-ups and pattern-matching with regular expressions 6 . The components of this deidentification system are continually expanded as new data is acquired.” | unhoused_relations[13] |
| relation | pattern-matching → protected health information — Regular-expression pattern matching helps remove protected health information from free text. — “Protected health information was removed from free text fields, such as diagnostic reports and physician notes, using a rigorously evaluated deidentification system based on extensive dictionary look-ups and pattern-matching with regular expressions 6 . The components of this deidentification system are continually expanded as new data is acquired.” | unhoused_relations[14] |
| weight | pattern-matching → protected health information — 0.95 — “Protected health information was removed from free text fields, such as diagnostic reports and physician notes, using a rigorously evaluated deidentification system based on extensive dictionary look-ups and pattern-matching with regular expressions 6 . The components of this deidentification system are continually expanded as new data is acquired.” | unhoused_relations[14] |
| relation | SUBJECT_ID → 26 tables — Identifiers such as SUBJECT_ID link tables in the relational database. — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | unhoused_relations[15] |
| weight | SUBJECT_ID → 26 tables — 0.99 — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | unhoused_relations[15] |
| relation | CHARTEVENTS → D_ITEMS — Joining CHARTEVENTS to D_ITEMS on ITEMID reveals the name of the measured concept. — “Tables prefixed with ‘D_’ are dictionary tables and provide definitions for identifiers. For example, every row of CHARTEVENTS is associated with a single ITEMID which represents the concept measured, but it does not contain the actual name of the measurement. By joining CHARTEVENTS and D_ITEMS on ITEMID, it is possible to identify the concept represented by a given ITEMID. Further detail is provided below.” | unhoused_relations[16] |
| weight | CHARTEVENTS → D_ITEMS — 0.99 — “Tables prefixed with ‘D_’ are dictionary tables and provide definitions for identifiers. For example, every row of CHARTEVENTS is associated with a single ITEMID which represents the concept measured, but it does not contain the actual name of the measurement. By joining CHARTEVENTS and D_ITEMS on ITEMID, it is possible to identify the concept represented by a given ITEMID. Further detail is provided below.” | unhoused_relations[16] |
| relation | database views → INPUTEVENTS_CV — Researchers can combine independent source tables through database views and transforms. — “In some cases it would be possible to merge tables—for example, the D_ICD_PROCEDURES and CPTEVENTS tables both contain detail relating to procedures and could be combined—but our approach is to keep the tables independent for clarity, since the data sources are significantly different. Rather than combining the tables within MIMIC data model, we suggest researchers develop database views and transforms as appropriate.” | unhoused_relations[17] |
| weight | database views → INPUTEVENTS_CV — 0.9 — “In some cases it would be possible to merge tables—for example, the D_ICD_PROCEDURES and CPTEVENTS tables both contain detail relating to procedures and could be combined—but our approach is to keep the tables independent for clarity, since the data sources are significantly different. Rather than combining the tables within MIMIC data model, we suggest researchers develop database views and transforms as appropriate.” | unhoused_relations[17] |
| relation | version controlled → reproducibility — Version-controlled collaborative development facilitates readable shared code and feedback. — “Best practice for scientific computing was followed where possible 7 . Code used to build MIMIC-III was version controlled and developed collaboratively within the laboratory. This approach encouraged and facilitated sharing of readable code and documentation, as well as frequent feedback from colleagues.” | unhoused_relations[18] |
| weight | version controlled → reproducibility — 0.9 — “Best practice for scientific computing was followed where possible 7 . Code used to build MIMIC-III was version controlled and developed collaboratively within the laboratory. This approach encouraged and facilitated sharing of readable code and documentation, as well as frequent feedback from colleagues.” | unhoused_relations[18] |
| relation | Issue tracking → data integration — Issue tracking documents and manages limitations in the data and code. — “Issue tracking is used to ensure that limitations of the data and code are clearly documented and are dealt with as appropriate. The research community is encouraged to report and address issues as they are found, and a system for releasing minor database updates is in place.” | unhoused_relations[19] |
| weight | Issue tracking → data integration — 0.95 — “Issue tracking is used to ensure that limitations of the data and code are clearly documented and are dealt with as appropriate. The research community is encouraged to report and address issues as they are found, and a system for releasing minor database updates is in place.” | unhoused_relations[19] |
| relation | public code repository → shared code base — The public repository enables researchers to develop and share code collectively. — “Our experience is that many researchers work independently to produce code for data processing and analysis. We seek to move towards a more collaborative, iterative, and self-checking development process where researchers work together on a shared code base. To facilitate collaboration, a public code repository has been created to encourage researchers to develop and share code collectively: https://github.com/MIT-LCP/mimic-code .” | unhoused_relations[20] |
| weight | public code repository → shared code base — 0.75 — “Our experience is that many researchers work independently to produce code for data processing and analysis. We seek to move towards a more collaborative, iterative, and self-checking development process where researchers work together on a shared code base. To facilitate collaboration, a public code repository has been created to encourage researchers to develop and share code collectively: https://github.com/MIT-LCP/mimic-code .” | unhoused_relations[20] |
| relation | common data models → integration with complementary datasets — Common models may facilitate integration with complementary datasets. — “Alongside work on the centralized codebase, we support efforts to transform MIMIC into common data models such the Observational Medical Outcomes Partnership Common Data Model (OMOP-CDM) 5 . Developing these common models may help to facilitate integration with complementary datasets and to enable the application of generalized analytic tools. Important efforts to map concepts to standardized clinical ontologies are also underway.” | unhoused_relations[21] |
| weight | common data models → integration with complementary datasets — 0.6 — “Alongside work on the centralized codebase, we support efforts to transform MIMIC into common data models such the Observational Medical Outcomes Partnership Common Data Model (OMOP-CDM) 5 . Developing these common models may help to facilitate integration with complementary datasets and to enable the application of generalized analytic tools. Important efforts to map concepts to standardized clinical ontologies are also underway.” | unhoused_relations[21] |
| relation | common data models → generalized analytic tools — Common models may enable application of generalized analytic tools. — “Alongside work on the centralized codebase, we support efforts to transform MIMIC into common data models such the Observational Medical Outcomes Partnership Common Data Model (OMOP-CDM) 5 . Developing these common models may help to facilitate integration with complementary datasets and to enable the application of generalized analytic tools. Important efforts to map concepts to standardized clinical ontologies are also underway.” | unhoused_relations[22] |
| weight | common data models → generalized analytic tools — 0.6 — “Alongside work on the centralized codebase, we support efforts to transform MIMIC into common data models such the Observational Medical Outcomes Partnership Common Data Model (OMOP-CDM) 5 . Developing these common models may help to facilitate integration with complementary datasets and to enable the application of generalized analytic tools. Important efforts to map concepts to standardized clinical ontologies are also underway.” | unhoused_relations[22] |
| no type for this | interoperability → data integration — Unresolved interoperability creates data-integration challenges. — “Despite this advance, interoperability of digital systems remains an open issue, leading to challenges in data integration. As a result, the potential that hospital data offers in terms of understanding and improving care is yet to be fully realized. In parallel, the scientific research community is increasingly coming under criticism for the lack of reproducibility of studies 2 .” | unhoused_relations[0] |
| no type for this | MIMIC-III → MIMIC-II — MIMIC-III updates the widely used MIMIC-II database. — “Here we report the release of the MIMIC-III database, an update to the widely-used MIMIC-II database (Data Citation 1). MIMIC-III integrates deidentified, comprehensive clinical data of patients admitted to the Beth Israel Deaconess Medical Center in Boston, Massachusetts, and makes it widely accessible to researchers internationally under a data use agreement ( Fig. 1 ). The open nature of the data allows clinical studies to be reproduced and improved in ways that would not otherwise be possible.” | unhoused_relations[1] |
| no type for this | Medical Information Mart for Intensive Care → MIMIC-III — The expanded title of MIMIC was changed to Medical Information Mart for Intensive Care. — “To recognize the increasingly broad usage of MIMIC, we have renamed the full title of the database from ‘Multiparameter Intelligent Monitoring in Intensive Care’ to ‘Medical Information Mart for Intensive Care’. The MIMIC-III critical care database is unique and notable for the following reasons:” | unhoused_relations[2] |
| no type for this | simplicity of interpretation → closeness to ground truth — The data model balances simplicity of interpretation against closeness to ground truth. — “Developing the MIMIC data model involved balancing simplicity of interpretation against closeness to ground truth. As such, the model is a reflection of underlying data sources, modified over iterations of the MIMIC database in response to user feedback. Table 4 describes how data is distributed across the data tables. Care has been taken to avoid making assumptions about the underlying data when carrying out transformations, so MIMIC-III closely represents the raw hospital data.” | unhoused_relations[3] |
| no type for this | SUBJECT_ID → adult patients — SUBJECT_ID refers to a unique patient represented in MIMIC-III. — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | unhoused_relations[4] |
| no type for this | HADM_ID → hospital admissions — HADM_ID refers to a unique hospital admission. — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | unhoused_relations[5] |
| no type for this | ICUSTAY_ID → hospital admissions — ICUSTAY_ID refers to a unique intensive-care-unit admission. — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | unhoused_relations[6] |
| no type for this | CareVue Clinical Information System → INPUTEVENTS_CV — CareVue input events are stored in INPUTEVENTS_CV. — “With exception to data relating to fluid intake, which differed significantly in structure between the CareVue and MetaVision systems, data was merged when building the database tables. Data which could not be merged is given a suffix to denote the data source. For example, inputs for patients monitored with the CareVue system are stored in INPUTEVENTS_CV, whereas inputs for patients monitored with the Metavision system are stored in INPUTEVENTS_MV. Additional information was collected from hospital and laboratory health record systems, including:” | unhoused_relations[7] |
| no type for this | MetaVision ICU → INPUTEVENTS_MV — MetaVision input events are stored in INPUTEVENTS_MV. — “With exception to data relating to fluid intake, which differed significantly in structure between the CareVue and MetaVision systems, data was merged when building the database tables. Data which could not be merged is given a suffix to denote the data source. For example, inputs for patients monitored with the CareVue system are stored in INPUTEVENTS_CV, whereas inputs for patients monitored with the Metavision system are stored in INPUTEVENTS_MV. Additional information was collected from hospital and laboratory health record systems, including:” | unhoused_relations[8] |
| no type for this | LOINC → laboratory measurements — MIMIC laboratory tests were mapped to LOINC. — “Several projects are ongoing to map concepts within the MIMIC database to standardized dictionaries. For example, researchers at the National Library of Medicine National Institutes of Health have mapped laboratory tests and medications in MIMIC-II to LOINC and RxNorm, respectively 4 . Efforts are also underway to transform MIMIC to common data models, such as the Observational Medical Outcomes Partnership Common Data Model, to support the application of standardized tools and methods 5 . These developments are progressively incorporated into the MIMIC database where possible.” | unhoused_relations[9] |
| no type for this | RxNorm → MIMIC-III — MIMIC medications were mapped to RxNorm. — “Several projects are ongoing to map concepts within the MIMIC database to standardized dictionaries. For example, researchers at the National Library of Medicine National Institutes of Health have mapped laboratory tests and medications in MIMIC-II to LOINC and RxNorm, respectively 4 . Efforts are also underway to transform MIMIC to common data models, such as the Observational Medical Outcomes Partnership Common Data Model, to support the application of standardized tools and methods 5 . These developments are progressively incorporated into the MIMIC database where possible.” | unhoused_relations[10] |
| no type for this | structured data cleansing → protected health information — Structured cleansing removes HIPAA identifying elements from clinical data. — “Before data was incorporated into the MIMIC-III database, it was first deidentified in accordance with Health Insurance Portability and Accountability Act (HIPAA) standards using structured data cleansing and date shifting. The deidentification process for structured data required the removal of all eighteen of the identifying data elements listed in HIPAA, including fields such as patient name, telephone number, address, and dates. In particular, dates were shifted into the future by a random offset for each individual patient in a consistent manner to preserve intervals, resulting in stays which occur sometime between the years 2100 and 2200. Time of day, day of the week, and approximate seasonality were conserved during date shifting. Dates of birth for patients aged over 89 were shifted to obscure their true age and comply with HIPAA regulations: these patients appear in the database with ages of over 300 years.” | unhoused_relations[11] |
| no type for this | date shifting → ground truth — Date shifting preserves intervals while intentionally changing calendar dates. — “Before data was incorporated into the MIMIC-III database, it was first deidentified in accordance with Health Insurance Portability and Accountability Act (HIPAA) standards using structured data cleansing and date shifting. The deidentification process for structured data required the removal of all eighteen of the identifying data elements listed in HIPAA, including fields such as patient name, telephone number, address, and dates. In particular, dates were shifted into the future by a random offset for each individual patient in a consistent manner to preserve intervals, resulting in stays which occur sometime between the years 2100 and 2200. Time of day, day of the week, and approximate seasonality were conserved during date shifting. Dates of birth for patients aged over 89 were shifted to obscure their true age and comply with HIPAA regulations: these patients appear in the database with ages of over 300 years.” | unhoused_relations[12] |
| no type for this | dictionary look-ups → protected health information — Dictionary look-ups help remove protected health information from free text. — “Protected health information was removed from free text fields, such as diagnostic reports and physician notes, using a rigorously evaluated deidentification system based on extensive dictionary look-ups and pattern-matching with regular expressions 6 . The components of this deidentification system are continually expanded as new data is acquired.” | unhoused_relations[13] |
| no type for this | pattern-matching → protected health information — Regular-expression pattern matching helps remove protected health information from free text. — “Protected health information was removed from free text fields, such as diagnostic reports and physician notes, using a rigorously evaluated deidentification system based on extensive dictionary look-ups and pattern-matching with regular expressions 6 . The components of this deidentification system are continually expanded as new data is acquired.” | unhoused_relations[14] |
| no type for this | SUBJECT_ID → 26 tables — Identifiers such as SUBJECT_ID link tables in the relational database. — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | unhoused_relations[15] |
| no type for this | CHARTEVENTS → D_ITEMS — Joining CHARTEVENTS to D_ITEMS on ITEMID reveals the name of the measured concept. — “Tables prefixed with ‘D_’ are dictionary tables and provide definitions for identifiers. For example, every row of CHARTEVENTS is associated with a single ITEMID which represents the concept measured, but it does not contain the actual name of the measurement. By joining CHARTEVENTS and D_ITEMS on ITEMID, it is possible to identify the concept represented by a given ITEMID. Further detail is provided below.” | unhoused_relations[16] |
| no type for this | database views → INPUTEVENTS_CV — Researchers can combine independent source tables through database views and transforms. — “In some cases it would be possible to merge tables—for example, the D_ICD_PROCEDURES and CPTEVENTS tables both contain detail relating to procedures and could be combined—but our approach is to keep the tables independent for clarity, since the data sources are significantly different. Rather than combining the tables within MIMIC data model, we suggest researchers develop database views and transforms as appropriate.” | unhoused_relations[17] |
| no type for this | version controlled → reproducibility — Version-controlled collaborative development facilitates readable shared code and feedback. — “Best practice for scientific computing was followed where possible 7 . Code used to build MIMIC-III was version controlled and developed collaboratively within the laboratory. This approach encouraged and facilitated sharing of readable code and documentation, as well as frequent feedback from colleagues.” | unhoused_relations[18] |
| no type for this | Issue tracking → data integration — Issue tracking documents and manages limitations in the data and code. — “Issue tracking is used to ensure that limitations of the data and code are clearly documented and are dealt with as appropriate. The research community is encouraged to report and address issues as they are found, and a system for releasing minor database updates is in place.” | unhoused_relations[19] |
| no type for this | public code repository → shared code base — The public repository enables researchers to develop and share code collectively. — “Our experience is that many researchers work independently to produce code for data processing and analysis. We seek to move towards a more collaborative, iterative, and self-checking development process where researchers work together on a shared code base. To facilitate collaboration, a public code repository has been created to encourage researchers to develop and share code collectively: https://github.com/MIT-LCP/mimic-code .” | unhoused_relations[20] |
| no type for this | common data models → integration with complementary datasets — Common models may facilitate integration with complementary datasets. — “Alongside work on the centralized codebase, we support efforts to transform MIMIC into common data models such the Observational Medical Outcomes Partnership Common Data Model (OMOP-CDM) 5 . Developing these common models may help to facilitate integration with complementary datasets and to enable the application of generalized analytic tools. Important efforts to map concepts to standardized clinical ontologies are also underway.” | unhoused_relations[21] |
| no type for this | common data models → generalized analytic tools — Common models may enable application of generalized analytic tools. — “Alongside work on the centralized codebase, we support efforts to transform MIMIC into common data models such the Observational Medical Outcomes Partnership Common Data Model (OMOP-CDM) 5 . Developing these common models may help to facilitate integration with complementary datasets and to enable the application of generalized analytic tools. Important efforts to map concepts to standardized clinical ontologies are also underway.” | unhoused_relations[22] |
| limitation | the database is single-center, so its institutional coverage is narrower than a multi-center resource — “MIMIC-III (‘Medical Information Mart for Intensive Care’) is a large, single-center database comprising information relating to patients admitted to critical care units at a large tertiary care hospital. Data includes vital signs, medications, laboratory measurements, observations and notes charted by care providers, fluid balance, procedure codes, diagnostic codes, imaging reports, hospital length of stay, survival data, and more. The database supports applications including academic and industrial research, quality improvement initiatives, and higher education coursework.” | limitations[0] |
| limitation | digital-system interoperability remains unresolved and impedes integration of hospital data — “Despite this advance, interoperability of digital systems remains an open issue, leading to challenges in data integration. As a result, the potential that hospital data offers in terms of understanding and improving care is yet to be fully realized. In parallel, the scientific research community is increasingly coming under criticism for the lack of reproducibility of studies 2 .” | limitations[1] |
| limitation | the potential of hospital data for understanding and improving care had not yet been fully realized — “Despite this advance, interoperability of digital systems remains an open issue, leading to challenges in data integration. As a result, the potential that hospital data offers in terms of understanding and improving care is yet to be fully realized. In parallel, the scientific research community is increasingly coming under criticism for the lack of reproducibility of studies 2 .” | limitations[2] |
| limitation | fluid-intake records from CareVue and MetaVision differ enough in structure that they remain source-specific — “With exception to data relating to fluid intake, which differed significantly in structure between the CareVue and MetaVision systems, data was merged when building the database tables. Data which could not be merged is given a suffix to denote the data source. For example, inputs for patients monitored with the CareVue system are stored in INPUTEVENTS_CV, whereas inputs for patients monitored with the Metavision system are stored in INPUTEVENTS_MV. Additional information was collected from hospital and laboratory health record systems, including:” | limitations[3] |
| limitation | physiological waveforms are available for only a subset of patients — “Out-of-hospital mortality dates were obtained using the Social Security Administration Death Master File. A more detailed description of the data is shown in Table 1 . Physiological waveforms obtained from bedside monitors (such as electrocardiograms, blood pressure waveforms, photoplethysmograms, impedance pneumograms) were obtained for a subset of patients.” | limitations[4] |
| limitation | deidentification changes calendar dates and obscures ages over eighty-nine, requiring careful interpretation — “Before data was incorporated into the MIMIC-III database, it was first deidentified in accordance with Health Insurance Portability and Accountability Act (HIPAA) standards using structured data cleansing and date shifting. The deidentification process for structured data required the removal of all eighteen of the identifying data elements listed in HIPAA, including fields such as patient name, telephone number, address, and dates. In particular, dates were shifted into the future by a random offset for each individual patient in a consistent manner to preserve intervals, resulting in stays which occur sometime between the years 2100 and 2200. Time of day, day of the week, and approximate seasonality were conserved during date shifting. Dates of birth for patients aged over 89 were shifted to obscure their true age and comply with HIPAA regulations: these patients appear in the database with ages of over 300 years.” | limitations[5] |
| limitation | the free-text deidentification system requires continuing expansion as new data arrives — “Protected health information was removed from free text fields, such as diagnostic reports and physician notes, using a rigorously evaluated deidentification system based on extensive dictionary look-ups and pattern-matching with regular expressions 6 . The components of this deidentification system are continually expanded as new data is acquired.” | limitations[6] |
| limitation | access is restricted by required human-subjects training and a signed data-use agreement — “MIMIC-III is provided as a collection of comma separated value (CSV) files, along with scripts to help with importing the data into database systems including PostreSQL, MySQL, and MonetDB. As the database contains detailed information regarding the clinical care of patients, it must be treated with appropriate care and respect. Researchers are required to formally request access via a process documented on the MIMIC website 8 . There are two key steps that must be completed before access is granted: the researcher must complete a recognized course in protecting human research participants that includes Health Insurance Portability and Accountability Act (HIPAA) requirements. the researcher must sign a data use agreement, which outlines appropriate data usage and security standards, and forbids efforts to identify individual patients.” | limitations[7] |
| limitation | approval takes at least a week and download occurs through a restricted PhysioNet component — “Approval requires at least a week. Once an application has been approved the researcher will receive emails containing instructions for downloading the database from PhysioNetWorks, a restricted access component of PhysioNet 9 .” | limitations[8] |
| limitation | MIMIC-III data must be handled with appropriate care because it contains detailed clinical information — “MIMIC-III is provided as a collection of comma separated value (CSV) files, along with scripts to help with importing the data into database systems including PostreSQL, MySQL, and MonetDB. As the database contains detailed information regarding the clinical care of patients, it must be treated with appropriate care and respect. Researchers are required to formally request access via a process documented on the MIMIC website 8 . There are two key steps that must be completed before access is granted:” | limitations[9] |
Concepts
terms this paper carries, each with the sentence it was cut from — the layer that joins one paper to another. Terms with no quote yet are on CONCEPTS.html.
| concept | MIMIC-III — not defined in this paper's own words; the third major release of a deidentified single-center critical-care database — “MIMIC-III (‘Medical Information Mart for Intensive Care’) is a large, single-center database comprising information relating to patients admitted to critical care units at a large tertiary care hospital. Data includes vital signs, medications, laboratory measurements, observations and notes charted by care providers, fluid balance, procedure codes, diagnostic codes, imaging reports, hospital length of stay, survival data, and more. The database supports applications including academic and industrial research, quality improvement initiatives, and higher education coursework.” | concepts[0] |
| concept | Medical Information Mart for Intensive Care — not defined in this paper's own words; the broadened expansion of the MIMIC name adopted for the database — “To recognize the increasingly broad usage of MIMIC, we have renamed the full title of the database from ‘Multiparameter Intelligent Monitoring in Intensive Care’ to ‘Medical Information Mart for Intensive Care’. The MIMIC-III critical care database is unique and notable for the following reasons:” | concepts[1] |
| concept | critical care database — not defined in this paper's own words; an integrated collection of detailed patient and hospital data from intensive-care admissions — “The Laboratory for Computational Physiology at Massachusetts Institute of Technology is an interdisciplinary team of data scientists and practicing physicians. MIMIC-III is the third iteration of the MIMIC critical care database, enabling us to draw upon prior experience with regard to data management and integration 3 .” | concepts[2] |
| concept | MIMIC critical care database — not defined in this paper's own words; the database lineage whose third iteration is MIMIC-III — “The Laboratory for Computational Physiology at Massachusetts Institute of Technology is an interdisciplinary team of data scientists and practicing physicians. MIMIC-III is the third iteration of the MIMIC critical care database, enabling us to draw upon prior experience with regard to data management and integration 3 .” | concepts[3] |
| concept | digital health record systems — not defined in this paper's own words; hospital information systems whose adoption increased while interoperability remained unresolved — “In recent years there has been a concerted move towards the adoption of digital health record systems in hospitals. In the US, for example, the number of non-federal acute care hospitals with basic digital systems increased from 9.4 to 75.5% over the 7 year period between 2008 and 2014 ( ref. 1 ). Despite this advance, interoperability of digital systems remains an open issue, leading to challenges in data integration. As a result, the potential that hospital data offers in terms of understanding and improving care is yet to be fully realized. In parallel, the scientific research community is increasingly coming under criticism for the lack of reproducibility of studies 2 .” | concepts[4] |
| concept | interoperability — not defined in this paper's own words; the ability of digital systems to work together, identified here as an unresolved integration issue — “Despite this advance, interoperability of digital systems remains an open issue, leading to challenges in data integration. As a result, the potential that hospital data offers in terms of understanding and improving care is yet to be fully realized. In parallel, the scientific research community is increasingly coming under criticism for the lack of reproducibility of studies 2 .” | concepts[5] |
| concept | data integration — not defined in this paper's own words; combining information across hospital digital systems — “Despite this advance, interoperability of digital systems remains an open issue, leading to challenges in data integration. As a result, the potential that hospital data offers in terms of understanding and improving care is yet to be fully realized. In parallel, the scientific research community is increasingly coming under criticism for the lack of reproducibility of studies 2 .” | concepts[6] |
| concept | reproducibility — not defined in this paper's own words; the capacity for scientific studies to be repeated, improved, and checked — “Despite this advance, interoperability of digital systems remains an open issue, leading to challenges in data integration. As a result, the potential that hospital data offers in terms of understanding and improving care is yet to be fully realized. In parallel, the scientific research community is increasingly coming under criticism for the lack of reproducibility of studies 2 .” | concepts[7] |
| concept | MIMIC-II — not defined in this paper's own words; the previous major release that MIMIC-III updates — “Here we report the release of the MIMIC-III database, an update to the widely-used MIMIC-II database (Data Citation 1). MIMIC-III integrates deidentified, comprehensive clinical data of patients admitted to the Beth Israel Deaconess Medical Center in Boston, Massachusetts, and makes it widely accessible to researchers internationally under a data use agreement ( Fig. 1 ). The open nature of the data allows clinical studies to be reproduced and improved in ways that would not otherwise be possible.” | concepts[8] |
| concept | data use agreement — not defined in this paper's own words; the signed agreement governing appropriate use, security, and non-reidentification — “the researcher must sign a data use agreement, which outlines appropriate data usage and security standards, and forbids efforts to identify individual patients.” | concepts[9] |
| concept | clinical studies — not defined in this paper's own words; research uses of the database that open access allows to be reproduced and improved — “Here we report the release of the MIMIC-III database, an update to the widely-used MIMIC-II database (Data Citation 1). MIMIC-III integrates deidentified, comprehensive clinical data of patients admitted to the Beth Israel Deaconess Medical Center in Boston, Massachusetts, and makes it widely accessible to researchers internationally under a data use agreement ( Fig. 1 ). The open nature of the data allows clinical studies to be reproduced and improved in ways that would not otherwise be possible.” | concepts[10] |
| concept | adult patients — not defined in this paper's own words; patients aged sixteen or above represented in the database — “MIMIC-III contains data associated with 53,423 distinct hospital admissions for adult patients (aged 16 years or above) admitted to critical care units between 2001 and 2012. In addition, it contains data for 7870 neonates admitted between 2001 and 2008. The data covers 38,597 distinct adult patients and 49,785 hospital admissions. The median age of adult patients is 65.8 years (Q1–Q3: 52.8–77.8), 55.9% patients are male, and in-hospital mortality is 11.5%. The median length of an ICU stay is 2.1 days (Q1–Q3: 1.2–4.6) and the median length of a hospital stay is 6.9 days (Q1-Q3: 4.1–11.9). A mean of 4579 charted observations (’chartevents’) and 380 laboratory measurements (’labevents’) are available for each hospital admission. Table 1 provides a breakdown of the adult population by care unit.” | concepts[11] |
| concept | neonates — not defined in this paper's own words; newborn patients represented for the 2001-2008 period — “MIMIC-III contains data associated with 53,423 distinct hospital admissions for adult patients (aged 16 years or above) admitted to critical care units between 2001 and 2012. In addition, it contains data for 7870 neonates admitted between 2001 and 2008. The data covers 38,597 distinct adult patients and 49,785 hospital admissions. The median age of adult patients is 65.8 years (Q1–Q3: 52.8–77.8), 55.9% patients are male, and in-hospital mortality is 11.5%. The median length of an ICU stay is 2.1 days (Q1–Q3: 1.2–4.6) and the median length of a hospital stay is 6.9 days (Q1-Q3: 4.1–11.9). A mean of 4579 charted observations (’chartevents’) and 380 laboratory measurements (’labevents’) are available for each hospital admission. Table 1 provides a breakdown of the adult population by care unit.” | concepts[12] |
| concept | hospital admissions — not defined in this paper's own words; hospital episodes linked to adult and neonatal patient records — “MIMIC-III contains data associated with 53,423 distinct hospital admissions for adult patients (aged 16 years or above) admitted to critical care units between 2001 and 2012. In addition, it contains data for 7870 neonates admitted between 2001 and 2008. The data covers 38,597 distinct adult patients and 49,785 hospital admissions. The median age of adult patients is 65.8 years (Q1–Q3: 52.8–77.8), 55.9% patients are male, and in-hospital mortality is 11.5%. The median length of an ICU stay is 2.1 days (Q1–Q3: 1.2–4.6) and the median length of a hospital stay is 6.9 days (Q1-Q3: 4.1–11.9). A mean of 4579 charted observations (’chartevents’) and 380 laboratory measurements (’labevents’) are available for each hospital admission. Table 1 provides a breakdown of the adult population by care unit.” | concepts[13] |
| concept | physiological measurements — not defined in this paper's own words; time-stamped nurse-verified bedside observations — “Data available in the MIMIC-III database ranges from time-stamped, nurse-verified physiological measurements made at the bedside to free-text interpretations of imaging studies provided by the radiology department. Table 3 gives an overview of the different classes of data available. Figure 2 shows sample data for a single patient stay in a medical intensive care unit. The patient, who was undergoing a course of chemotherapy at the time of admission, presented with febrile neutropenia, anemia, and thrombocytopenia.” | concepts[14] |
| concept | laboratory measurements — not defined in this paper's own words; laboratory observations included among the database's clinical data — “MIMIC-III (‘Medical Information Mart for Intensive Care’) is a large, single-center database comprising information relating to patients admitted to critical care units at a large tertiary care hospital. Data includes vital signs, medications, laboratory measurements, observations and notes charted by care providers, fluid balance, procedure codes, diagnostic codes, imaging reports, hospital length of stay, survival data, and more. The database supports applications including academic and industrial research, quality improvement initiatives, and higher education coursework.” | concepts[15] |
| concept | ICD-9 — not defined in this paper's own words; the ninth-edition diagnosis coding system included in discharge and billing data — “With exception to data relating to fluid intake, which differed significantly in structure between the CareVue and MetaVision systems, data was merged when building the database tables. Data which could not be merged is given a suffix to denote the data source. For example, inputs for patients monitored with the CareVue system are stored in INPUTEVENTS_CV, whereas inputs for patients monitored with the Metavision system are stored in INPUTEVENTS_MV. Additional information was collected from hospital and laboratory health record systems, including: patient demographics and in-hospital mortality. laboratory test results (for example, hematology, chemistry, and microbiology results). discharge summaries and reports of electrocardiogram and imaging studies. billing-related information such as International Classification of Disease, 9th Edition (ICD-9) codes, Diagnosis Related Group (DRG) codes, and Current Procedural Terminology (CPT) codes.” | concepts[16] |
| concept | CareVue Clinical Information System — not defined in this paper's own words; one critical-care source system used during the collection period — “Two different critical care information systems were in place over the data collection period: Philips CareVue Clinical Information System (models M2331A and M1215A; Philips Health-care, Andover, MA) and iMDsoft MetaVision ICU (iMDsoft, Needham, MA). These systems were the source of clinical data such as:” | concepts[17] |
| concept | MetaVision ICU — not defined in this paper's own words; the second critical-care source system used during the collection period — “Two different critical care information systems were in place over the data collection period: Philips CareVue Clinical Information System (models M2331A and M1215A; Philips Health-care, Andover, MA) and iMDsoft MetaVision ICU (iMDsoft, Needham, MA). These systems were the source of clinical data such as:” | concepts[18] |
| concept | INPUTEVENTS_CV — not defined in this paper's own words; the table retaining CareVue fluid-input records — “With exception to data relating to fluid intake, which differed significantly in structure between the CareVue and MetaVision systems, data was merged when building the database tables. Data which could not be merged is given a suffix to denote the data source. For example, inputs for patients monitored with the CareVue system are stored in INPUTEVENTS_CV, whereas inputs for patients monitored with the Metavision system are stored in INPUTEVENTS_MV. Additional information was collected from hospital and laboratory health record systems, including:” | concepts[19] |
| concept | INPUTEVENTS_MV — not defined in this paper's own words; the table retaining MetaVision fluid-input records — “With exception to data relating to fluid intake, which differed significantly in structure between the CareVue and MetaVision systems, data was merged when building the database tables. Data which could not be merged is given a suffix to denote the data source. For example, inputs for patients monitored with the CareVue system are stored in INPUTEVENTS_CV, whereas inputs for patients monitored with the Metavision system are stored in INPUTEVENTS_MV. Additional information was collected from hospital and laboratory health record systems, including:” | concepts[20] |
| concept | Physiological waveforms — not defined in this paper's own words; continuous bedside-monitor signals available for a subset of patients — “Out-of-hospital mortality dates were obtained using the Social Security Administration Death Master File. A more detailed description of the data is shown in Table 1 . Physiological waveforms obtained from bedside monitors (such as electrocardiograms, blood pressure waveforms, photoplethysmograms, impedance pneumograms) were obtained for a subset of patients.” | concepts[21] |
| concept | LOINC — not defined in this paper's own words; a standardized dictionary to which MIMIC laboratory tests were mapped — “Several projects are ongoing to map concepts within the MIMIC database to standardized dictionaries. For example, researchers at the National Library of Medicine National Institutes of Health have mapped laboratory tests and medications in MIMIC-II to LOINC and RxNorm, respectively 4 . Efforts are also underway to transform MIMIC to common data models, such as the Observational Medical Outcomes Partnership Common Data Model, to support the application of standardized tools and methods 5 . These developments are progressively incorporated into the MIMIC database where possible.” | concepts[22] |
| concept | RxNorm — not defined in this paper's own words; a standardized dictionary to which MIMIC medications were mapped — “Several projects are ongoing to map concepts within the MIMIC database to standardized dictionaries. For example, researchers at the National Library of Medicine National Institutes of Health have mapped laboratory tests and medications in MIMIC-II to LOINC and RxNorm, respectively 4 . Efforts are also underway to transform MIMIC to common data models, such as the Observational Medical Outcomes Partnership Common Data Model, to support the application of standardized tools and methods 5 . These developments are progressively incorporated into the MIMIC database where possible.” | concepts[23] |
| concept | common data models — not defined in this paper's own words; standard representations intended to support reusable analytic tools and integration — “Several projects are ongoing to map concepts within the MIMIC database to standardized dictionaries. For example, researchers at the National Library of Medicine National Institutes of Health have mapped laboratory tests and medications in MIMIC-II to LOINC and RxNorm, respectively 4 . Efforts are also underway to transform MIMIC to common data models, such as the Observational Medical Outcomes Partnership Common Data Model, to support the application of standardized tools and methods 5 . These developments are progressively incorporated into the MIMIC database where possible.” | concepts[24] |
| concept | Observational Medical Outcomes Partnership Common Data Model — not defined in this paper's own words; a common data model targeted for transformation of MIMIC — “Several projects are ongoing to map concepts within the MIMIC database to standardized dictionaries. For example, researchers at the National Library of Medicine National Institutes of Health have mapped laboratory tests and medications in MIMIC-II to LOINC and RxNorm, respectively 4 . Efforts are also underway to transform MIMIC to common data models, such as the Observational Medical Outcomes Partnership Common Data Model, to support the application of standardized tools and methods 5 . These developments are progressively incorporated into the MIMIC database where possible.” | concepts[25] |
| concept | standardized tools and methods — not defined in this paper's own words; reusable analytical resources supported by common-model transformation — “Several projects are ongoing to map concepts within the MIMIC database to standardized dictionaries. For example, researchers at the National Library of Medicine National Institutes of Health have mapped laboratory tests and medications in MIMIC-II to LOINC and RxNorm, respectively 4 . Efforts are also underway to transform MIMIC to common data models, such as the Observational Medical Outcomes Partnership Common Data Model, to support the application of standardized tools and methods 5 . These developments are progressively incorporated into the MIMIC database where possible.” | concepts[26] |
| concept | HIPAA — not defined in this paper's own words; the privacy standard governing removal of identifying elements — “Before data was incorporated into the MIMIC-III database, it was first deidentified in accordance with Health Insurance Portability and Accountability Act (HIPAA) standards using structured data cleansing and date shifting. The deidentification process for structured data required the removal of all eighteen of the identifying data elements listed in HIPAA, including fields such as patient name, telephone number, address, and dates. In particular, dates were shifted into the future by a random offset for each individual patient in a consistent manner to preserve intervals, resulting in stays which occur sometime between the years 2100 and 2200. Time of day, day of the week, and approximate seasonality were conserved during date shifting. Dates of birth for patients aged over 89 were shifted to obscure their true age and comply with HIPAA regulations: these patients appear in the database with ages of over 300 years.” | concepts[27] |
| concept | structured data cleansing — not defined in this paper's own words; one method used to deidentify structured clinical data — “Before data was incorporated into the MIMIC-III database, it was first deidentified in accordance with Health Insurance Portability and Accountability Act (HIPAA) standards using structured data cleansing and date shifting. The deidentification process for structured data required the removal of all eighteen of the identifying data elements listed in HIPAA, including fields such as patient name, telephone number, address, and dates. In particular, dates were shifted into the future by a random offset for each individual patient in a consistent manner to preserve intervals, resulting in stays which occur sometime between the years 2100 and 2200. Time of day, day of the week, and approximate seasonality were conserved during date shifting. Dates of birth for patients aged over 89 were shifted to obscure their true age and comply with HIPAA regulations: these patients appear in the database with ages of over 300 years.” | concepts[28] |
| concept | date shifting — not defined in this paper's own words; per-patient random temporal offset that preserves intervals while obscuring real dates — “Before data was incorporated into the MIMIC-III database, it was first deidentified in accordance with Health Insurance Portability and Accountability Act (HIPAA) standards using structured data cleansing and date shifting. The deidentification process for structured data required the removal of all eighteen of the identifying data elements listed in HIPAA, including fields such as patient name, telephone number, address, and dates. In particular, dates were shifted into the future by a random offset for each individual patient in a consistent manner to preserve intervals, resulting in stays which occur sometime between the years 2100 and 2200. Time of day, day of the week, and approximate seasonality were conserved during date shifting. Dates of birth for patients aged over 89 were shifted to obscure their true age and comply with HIPAA regulations: these patients appear in the database with ages of over 300 years.” | concepts[29] |
| concept | protected health information — not defined in this paper's own words; identifying information removed from structured and free-text records — “Protected health information was removed from free text fields, such as diagnostic reports and physician notes, using a rigorously evaluated deidentification system based on extensive dictionary look-ups and pattern-matching with regular expressions 6 . The components of this deidentification system are continually expanded as new data is acquired.” | concepts[30] |
| concept | deidentification system — not defined in this paper's own words; a continuously expanded system for removing protected information from free text — “Protected health information was removed from free text fields, such as diagnostic reports and physician notes, using a rigorously evaluated deidentification system based on extensive dictionary look-ups and pattern-matching with regular expressions 6 . The components of this deidentification system are continually expanded as new data is acquired.” | concepts[31] |
| concept | dictionary look-ups — not defined in this paper's own words; one mechanism used by the free-text deidentification system — “Protected health information was removed from free text fields, such as diagnostic reports and physician notes, using a rigorously evaluated deidentification system based on extensive dictionary look-ups and pattern-matching with regular expressions 6 . The components of this deidentification system are continually expanded as new data is acquired.” | concepts[32] |
| concept | pattern-matching — not defined in this paper's own words; regular-expression-based detection used in free-text deidentification — “Protected health information was removed from free text fields, such as diagnostic reports and physician notes, using a rigorously evaluated deidentification system based on extensive dictionary look-ups and pattern-matching with regular expressions 6 . The components of this deidentification system are continually expanded as new data is acquired.” | concepts[33] |
| concept | relational database — not defined in this paper's own words; a database of linked tables connected by identifiers — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | concepts[34] |
| concept | 26 tables — not defined in this paper's own words; the table set comprising the MIMIC-III relational database — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | concepts[35] |
| concept | SUBJECT_ID — not defined in this paper's own words; an identifier referring to a unique patient — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | concepts[36] |
| concept | HADM_ID — not defined in this paper's own words; an identifier referring to a unique hospital admission — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | concepts[37] |
| concept | ICUSTAY_ID — not defined in this paper's own words; an identifier referring to a unique intensive-care-unit admission — “MIMIC-III is a relational database consisting of 26 tables (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_ID refers to a unique patient, HADM_ID refers to a unique admission to the hospital, and ICUSTAY_ID refers to a unique admission to an intensive care unit.” | concepts[38] |
| concept | OUTPUTEVENTS — not defined in this paper's own words; an events table holding measurements of patient output — “Charted events such as notes, laboratory tests, and fluid balance are stored in a series of ‘events’ tables. For example the OUTPUTEVENTS table contains all measurements related to output for a given patient, while the LABEVENTS table contains laboratory test results for a patient.” | concepts[39] |
| concept | LABEVENTS — not defined in this paper's own words; an events table holding patient laboratory-test results — “Charted events such as notes, laboratory tests, and fluid balance are stored in a series of ‘events’ tables. For example the OUTPUTEVENTS table contains all measurements related to output for a given patient, while the LABEVENTS table contains laboratory test results for a patient.” | concepts[40] |
| concept | dictionary tables — not defined in this paper's own words; tables that cross-reference identifiers against definitions — “Broadly speaking, five tables are used to define and track patient stays: ADMISSIONS; PATIENTS; ICUSTAYS; SERVICES; and TRANSFERS. Another five tables are dictionaries for cross-referencing codes against their respective definitions: D_CPT; D_ICD_DIAGNOSES; D_ICD_PROCEDURES; D_ITEMS; and D_LABITEMS. The remaining tables contain data associated with patient care, such as physiological measurements, caregiver observations, and billing information.” | concepts[41] |
| concept | ITEMID — not defined in this paper's own words; an identifier representing the concept measured in a charted event — “Tables prefixed with ‘D_’ are dictionary tables and provide definitions for identifiers. For example, every row of CHARTEVENTS is associated with a single ITEMID which represents the concept measured, but it does not contain the actual name of the measurement. By joining CHARTEVENTS and D_ITEMS on ITEMID, it is possible to identify the concept represented by a given ITEMID. Further detail is provided below.” | concepts[42] |
| concept | CHARTEVENTS — not defined in this paper's own words; the charted-events table whose rows link to measurement concepts through ITEMID — “Tables prefixed with ‘D_’ are dictionary tables and provide definitions for identifiers. For example, every row of CHARTEVENTS is associated with a single ITEMID which represents the concept measured, but it does not contain the actual name of the measurement. By joining CHARTEVENTS and D_ITEMS on ITEMID, it is possible to identify the concept represented by a given ITEMID. Further detail is provided below.” | concepts[43] |
| concept | D_ITEMS — not defined in this paper's own words; the dictionary table joined to CHARTEVENTS to recover measurement names — “Tables prefixed with ‘D_’ are dictionary tables and provide definitions for identifiers. For example, every row of CHARTEVENTS is associated with a single ITEMID which represents the concept measured, but it does not contain the actual name of the measurement. By joining CHARTEVENTS and D_ITEMS on ITEMID, it is possible to identify the concept represented by a given ITEMID. Further detail is provided below.” | concepts[44] |
| concept | data model — not defined in this paper's own words; the table organization balancing interpretability with fidelity to source data — “Developing the MIMIC data model involved balancing simplicity of interpretation against closeness to ground truth. As such, the model is a reflection of underlying data sources, modified over iterations of the MIMIC database in response to user feedback. Table 4 describes how data is distributed across the data tables. Care has been taken to avoid making assumptions about the underlying data when carrying out transformations, so MIMIC-III closely represents the raw hospital data.” | concepts[45] |
| concept | ground truth — not defined in this paper's own words; the underlying source data that the model seeks to remain close to — “Developing the MIMIC data model involved balancing simplicity of interpretation against closeness to ground truth. As such, the model is a reflection of underlying data sources, modified over iterations of the MIMIC database in response to user feedback. Table 4 describes how data is distributed across the data tables. Care has been taken to avoid making assumptions about the underlying data when carrying out transformations, so MIMIC-III closely represents the raw hospital data.” | concepts[46] |
| concept | simplicity of interpretation — not defined in this paper's own words; the understandability objective balanced against source fidelity — “Developing the MIMIC data model involved balancing simplicity of interpretation against closeness to ground truth. As such, the model is a reflection of underlying data sources, modified over iterations of the MIMIC database in response to user feedback. Table 4 describes how data is distributed across the data tables. Care has been taken to avoid making assumptions about the underlying data when carrying out transformations, so MIMIC-III closely represents the raw hospital data.” | concepts[47] |
| concept | closeness to ground truth — not defined in this paper's own words; the fidelity objective balanced against interpretability — “Developing the MIMIC data model involved balancing simplicity of interpretation against closeness to ground truth. As such, the model is a reflection of underlying data sources, modified over iterations of the MIMIC database in response to user feedback. Table 4 describes how data is distributed across the data tables. Care has been taken to avoid making assumptions about the underlying data when carrying out transformations, so MIMIC-III closely represents the raw hospital data.” | concepts[48] |
| concept | database views — not defined in this paper's own words; researcher-defined combinations of independent source tables — “In some cases it would be possible to merge tables—for example, the D_ICD_PROCEDURES and CPTEVENTS tables both contain detail relating to procedures and could be combined—but our approach is to keep the tables independent for clarity, since the data sources are significantly different. Rather than combining the tables within MIMIC data model, we suggest researchers develop database views and transforms as appropriate.” | concepts[49] |
| concept | version controlled — not defined in this paper's own words; a development practice used for the database-building code — “Best practice for scientific computing was followed where possible 7 . Code used to build MIMIC-III was version controlled and developed collaboratively within the laboratory. This approach encouraged and facilitated sharing of readable code and documentation, as well as frequent feedback from colleagues.” | concepts[50] |
| concept | Issue tracking — not defined in this paper's own words; a process for documenting and addressing limitations in data and code — “Issue tracking is used to ensure that limitations of the data and code are clearly documented and are dealt with as appropriate. The research community is encouraged to report and address issues as they are found, and a system for releasing minor database updates is in place.” | concepts[51] |
| concept | comma separated value — not defined in this paper's own words; the flat-file distribution format for MIMIC-III — “MIMIC-III is provided as a collection of comma separated value (CSV) files, along with scripts to help with importing the data into database systems including PostreSQL, MySQL, and MonetDB. As the database contains detailed information regarding the clinical care of patients, it must be treated with appropriate care and respect. Researchers are required to formally request access via a process documented on the MIMIC website 8 . There are two key steps that must be completed before access is granted:” | concepts[52] |
| concept | PhysioNetWorks — not defined in this paper's own words; the restricted PhysioNet component from which approved researchers download the database — “Approval requires at least a week. Once an application has been approved the researcher will receive emails containing instructions for downloading the database from PhysioNetWorks, a restricted access component of PhysioNet 9 .” | concepts[53] |
| concept | datathons — not defined in this paper's own words; events joining caregivers, data scientists, and domain experts around reproducible clinical research — “A series of 'datathons' have been held alongside development of the MIMIC database. These events assemble caregivers, data scientists, and those with domain-specific knowledge with the aim of creating ideas and producing clinically relevant, reproducible research 14 . In parallel the events introduce new researchers to MIMIC and provide a platform for continuous review and development of code and research.” | concepts[54] |
| concept | public code repository — not defined in this paper's own words; a shared repository intended to support collective development of MIMIC analysis code — “Our experience is that many researchers work independently to produce code for data processing and analysis. We seek to move towards a more collaborative, iterative, and self-checking development process where researchers work together on a shared code base. To facilitate collaboration, a public code repository has been created to encourage researchers to develop and share code collectively: https://github.com/MIT-LCP/mimic-code .” | concepts[55] |
| concept | shared code base — not defined in this paper's own words; the common code resource around which collaborative and self-checking work is organized — “Our experience is that many researchers work independently to produce code for data processing and analysis. We seek to move towards a more collaborative, iterative, and self-checking development process where researchers work together on a shared code base. To facilitate collaboration, a public code repository has been created to encourage researchers to develop and share code collectively: https://github.com/MIT-LCP/mimic-code .” | concepts[56] |
| concept | severity of illness scores — not defined in this paper's own words; commonly used critical-care variables calculated by seeded repository code — “The repository has been seeded with code to calculate commonly utilized variables in critical care research, including severity of illness scores, comorbidity scores, and duration of various treatments such as mechanical ventilation and vasopressor use. We encourage users to incorporate this code into their research, provide improvements, and add new contributions that have potential to benefit the research community as a whole. Over time, we expect the repository to become increasingly vital for researchers working with the MIMIC-III database.” | concepts[57] |
| concept | comorbidity scores — not defined in this paper's own words; patient comorbidity variables calculated by seeded repository code — “The repository has been seeded with code to calculate commonly utilized variables in critical care research, including severity of illness scores, comorbidity scores, and duration of various treatments such as mechanical ventilation and vasopressor use. We encourage users to incorporate this code into their research, provide improvements, and add new contributions that have potential to benefit the research community as a whole. Over time, we expect the repository to become increasingly vital for researchers working with the MIMIC-III database.” | concepts[58] |
| concept | mechanical ventilation — not defined in this paper's own words; a treatment duration calculated by seeded repository code — “The repository has been seeded with code to calculate commonly utilized variables in critical care research, including severity of illness scores, comorbidity scores, and duration of various treatments such as mechanical ventilation and vasopressor use. We encourage users to incorporate this code into their research, provide improvements, and add new contributions that have potential to benefit the research community as a whole. Over time, we expect the repository to become increasingly vital for researchers working with the MIMIC-III database.” | concepts[59] |
| concept | vasopressor use — not defined in this paper's own words; a treatment duration calculated by seeded repository code — “The repository has been seeded with code to calculate commonly utilized variables in critical care research, including severity of illness scores, comorbidity scores, and duration of various treatments such as mechanical ventilation and vasopressor use. We encourage users to incorporate this code into their research, provide improvements, and add new contributions that have potential to benefit the research community as a whole. Over time, we expect the repository to become increasingly vital for researchers working with the MIMIC-III database.” | concepts[60] |
| concept | clinical ontologies — not defined in this paper's own words; standard terminologies to which MIMIC concepts are being mapped — “Alongside work on the centralized codebase, we support efforts to transform MIMIC into common data models such the Observational Medical Outcomes Partnership Common Data Model (OMOP-CDM) 5 . Developing these common models may help to facilitate integration with complementary datasets and to enable the application of generalized analytic tools. Important efforts to map concepts to standardized clinical ontologies are also underway.” | concepts[61] |
| concept | integration with complementary datasets — not defined in this paper's own words; one prospective benefit of common-model transformation — “Alongside work on the centralized codebase, we support efforts to transform MIMIC into common data models such the Observational Medical Outcomes Partnership Common Data Model (OMOP-CDM) 5 . Developing these common models may help to facilitate integration with complementary datasets and to enable the application of generalized analytic tools. Important efforts to map concepts to standardized clinical ontologies are also underway.” | concepts[62] |
| concept | generalized analytic tools — not defined in this paper's own words; reusable tools whose application common models may enable — “Alongside work on the centralized codebase, we support efforts to transform MIMIC into common data models such the Observational Medical Outcomes Partnership Common Data Model (OMOP-CDM) 5 . Developing these common models may help to facilitate integration with complementary datasets and to enable the application of generalized analytic tools. Important efforts to map concepts to standardized clinical ontologies are also underway.” | concepts[63] |
Full text — tagged
MIMIC-IIIterm, a freely accessible critical care databaseterm Abstract MIMIC-IIIterm (‘Medical Information Mart for Intensive Careterm’) is a large, single-center database comprising information relating to patients admitted to critical care units at a large tertiary care hospital. Data includes vital signs, medications, laboratory measurementsterm, observations and notes charted by care providers, fluid balance, procedure codes, diagnostic codes, imaging reports, hospital length of stay, survival data, and more. The database supports applications including academic and industrial research, quality improvement initiatives, and higher education coursework.
Subject terms: Outcomes research, Health care, Prognosis, Diagnosis, Medical research Background & Summary In recent years there has been a concerted move towards the adoption of digital health record systemsterm in hospitals. In the US, for example, the number of non-federal acute care hospitals with basic digital systems increased from 9.4 to 75.5% over the 7 year period between 2008 and 2014 ( ref. 1 ).
Despite this advance, interoperabilityterm of digital systems remains an open issue, leading to challenges in data integrationterm. As a result, the potential that hospital data offers in terms of understanding and improving care is yet to be fully realized. In parallel, the scientific research community is increasingly coming under criticism for the lack of reproducibilityterm of studies 2 .
Here we report the release of the MIMIC-IIIterm database, an update to the widely-used MIMIC-IIterm database (Data Citation 1). MIMIC-IIIterm integrates deidentified, comprehensive clinical data of patients admitted to the Beth Israel Deaconess Medical Center in Boston, Massachusetts, and makes it widely accessible to researchers internationally under a data use agreementterm ( Fig. 1 ). The open nature of the data allows clinical studiesterm to be reproduced and improved in ways that would not otherwise be possible.
Overview of the MIMIC-IIIterm critical care databaseterm.
Based on our experience with the previous major release of MIMIC (MIMIC-IIterm, released in 2010) we anticipate MIMIC-IIIterm to be widely used internationally in areas such as academic and industrial research, quality improvement initiatives, and higher education coursework.
To recognize the increasingly broad usage of MIMIC, we have renamed the full title of the database from ‘Multiparameter Intelligent Monitoring in Intensive Care’ to ‘Medical Information Mart for Intensive Careterm’. The MIMIC-IIIterm critical care databaseterm is unique and notable for the following reasons: it is the only freely accessible critical care databaseterm of its kind; the dataset spans more than a decade, with detailed information about individual patient care; analysis is unrestricted once a data use agreementterm is accepted, enabling clinical research and education around the world.
Patient characteristics MIMIC-IIIterm contains data associated with 53,423 distinct hospital admissionsterm for adult patientsterm (aged 16 years or above) admitted to critical care units between 2001 and 2012. In addition, it contains data for 7870 neonatesterm admitted between 2001 and 2008. The data covers 38,597 distinct adult patientsterm and 49,785 hospital admissionsterm. The median age of adult patientsterm is 65.8 years (Q1–Q3: 52.8–77.8), 55.9% patients are male, and in-hospital mortality is 11.5%. The median length of an ICU stay is 2.1 days (Q1–Q3: 1.2–4.6) and the median length of a hospital stay is 6.9 days (Q1-Q3: 4.1–11.9). A mean of 4579 charted observations (’charteventsterm’) and 380 laboratory measurementsterm (’labeventsterm’) are available for each hospital admissionterm. Table 1 provides a breakdown of the adult population by care unit.
Details of the MIMIC-IIIterm patient population by first critical care unit on hospital admissionterm for patients aged 16 years and above.
The primary International Classification of Diseases (ICD-9term) codes from the patient discharges are listed in Table 2 . The top three codes across hospital admissionsterm for patients aged 16 years and above were: Distribution of primary International Classification of Diseases, 9th Edition (ICD-9term) codes by care unit for patients aged 16 years and above.
414.01 (‘Coronary atherosclerosis of native coronary artery’), accounting for 7.1% of all hospital admissionsterm; 038.9 (‘Unspecified septicemia’), accounting for 4.2% of all hospital admissionsterm; and 410.71 (‘Subendocardial infarction, initial episode of care’), accounting for 3.6% of all hospital admissionsterm.
Classes of data Data available in the MIMIC-IIIterm database ranges from time-stamped, nurse-verified physiological measurementsterm made at the bedside to free-text interpretations of imaging studies provided by the radiology department. Table 3 gives an overview of the different classes of data available. Figure 2 shows sample data for a single patient stay in a medical intensive care unit. The patient, who was undergoing a course of chemotherapy at the time of admission, presented with febrile neutropenia, anemia, and thrombocytopenia.
Classes of data available in the MIMIC-IIIterm critical care databaseterm.
Sample data for a single patient stay in a medical intensive care unit. GCS is Glasgow Coma Scale; NIBP is non-invasive blood pressure; and O2 saturation is blood oxygen saturation.
Methods The Laboratory for Computational Physiology at Massachusetts Institute of Technology is an interdisciplinary team of data scientists and practicing physicians. MIMIC-IIIterm is the third iteration of the MIMIC critical care databaseterm, enabling us to draw upon prior experience with regard to data management and integration 3 .
Database development The MIMIC-IIIterm database was populated with data that had been acquired during routine hospital care, so there was no associated burden on caregivers and no interference with their workflow. Data was downloaded from several sources, including: archives from critical care information systems.
hospital electronic health record databases.
Social Security Administration Death Master File.
Two different critical care information systems were in place over the data collection period: Philips CareVue Clinical Information Systemterm (models M2331A and M1215A; Philips Health-care, Andover, MA) and iMDsoft MetaVision ICUterm (iMDsoft, Needham, MA). These systems were the source of clinical data such as: time-stamped nurse-verified physiological measurementsterm (for example, hourly documentation of heart rate, arterial blood pressure, or respiratory rate); documented progress notes by care providers; continuous intravenous drip medications and fluid balances.
With exception to data relating to fluid intake, which differed significantly in structure between the CareVue and MetaVision systems, data was merged when building the database tables. Data which could not be merged is given a suffix to denote the data source. For example, inputs for patients monitored with the CareVue system are stored in INPUTEVENTS_CVterm, whereas inputs for patients monitored with the Metavision system are stored in INPUTEVENTS_MVterm. Additional information was collected from hospital and laboratory health record systems, including: patient demographics and in-hospital mortality.
laboratory test results (for example, hematology, chemistry, and microbiology results).
discharge summaries and reports of electrocardiogram and imaging studies.
billing-related information such as International Classification of Disease, 9th Edition (ICD-9term) codes, Diagnosis Related Group (DRG) codes, and Current Procedural Terminology (CPT) codes.
Out-of-hospital mortality dates were obtained using the Social Security Administration Death Master File. A more detailed description of the data is shown in Table 1 . Physiological waveformsterm obtained from bedside monitors (such as electrocardiograms, blood pressure waveforms, photoplethysmograms, impedance pneumograms) were obtained for a subset of patients.
Several projects are ongoing to map concepts within the MIMIC database to standardized dictionaries. For example, researchers at the National Library of Medicine National Institutes of Health have mapped laboratory tests and medications in MIMIC-IIterm to LOINCterm and RxNormterm, respectively 4 . Efforts are also underway to transform MIMIC to common data modelsterm, such as the Observational Medical Outcomes Partnership Common Data Modelterm, to support the application of standardized tools and methodsterm 5 . These developments are progressively incorporated into the MIMIC database where possible.
The project was approved by the Institutional Review Boards of Beth Israel Deaconess Medical Center (Boston, MA) and the Massachusetts Institute of Technology (Cambridge, MA). Requirement for individual patient consent was waived because the project did not impact clinical care and all protected health informationterm was deidentified.
Deidentification Before data was incorporated into the MIMIC-IIIterm database, it was first deidentified in accordance with Health Insurance Portability and Accountability Act (HIPAAterm) standards using structured data cleansingterm and date shiftingterm. The deidentification process for structured data required the removal of all eighteen of the identifying data elements listed in HIPAAterm, including fields such as patient name, telephone number, address, and dates. In particular, dates were shifted into the future by a random offset for each individual patient in a consistent manner to preserve intervals, resulting in stays which occur sometime between the years 2100 and 2200. Time of day, day of the week, and approximate seasonality were conserved during date shiftingterm. Dates of birth for patients aged over 89 were shifted to obscure their true age and comply with HIPAAterm regulations: these patients appear in the database with ages of over 300 years.
Protected health informationterm was removed from free text fields, such as diagnostic reports and physician notes, using a rigorously evaluated deidentification systemterm based on extensive dictionary look-upsterm and pattern-matchingterm with regular expressions 6 . The components of this deidentification systemterm are continually expanded as new data is acquired.
Code availability The code that underpins the MIMIC-IIIterm website and documentation is openly available and contributions from the research community are encouraged: https://github.com/MIT-LCP/mimic-website A Jupyter Notebook containing the code used to generate the tables and descriptive statistics included in this paper is available at: https://github.com/MIT-LCP/mimic-iii-paper/ Data Records MIMIC-IIIterm is a relational databaseterm consisting of 26 tablesterm (Data Citation 1). Tables are linked by identifiers which usually have the suffix ‘ID’. For example, SUBJECT_IDterm refers to a unique patient, HADM_IDterm refers to a unique admission to the hospital, and ICUSTAY_IDterm refers to a unique admission to an intensive care unit.
Charted events such as notes, laboratory tests, and fluid balance are stored in a series of ‘events’ tables. For example the OUTPUTEVENTSterm table contains all measurements related to output for a given patient, while the LABEVENTSterm table contains laboratory test results for a patient.
Tables prefixed with ‘D_’ are dictionary tablesterm and provide definitions for identifiers. For example, every row of CHARTEVENTSterm is associated with a single ITEMIDterm which represents the concept measured, but it does not contain the actual name of the measurement. By joining CHARTEVENTSterm and D_ITEMSterm on ITEMIDterm, it is possible to identify the concept represented by a given ITEMIDterm. Further detail is provided below.
Data tables Developing the MIMIC data modelterm involved balancing simplicity of interpretationterm against closeness to ground truthterm. As such, the model is a reflection of underlying data sources, modified over iterations of the MIMIC database in response to user feedback. Table 4 describes how data is distributed across the data tables. Care has been taken to avoid making assumptions about the underlying data when carrying out transformations, so MIMIC-IIIterm closely represents the raw hospital data.
An overview of the data tables comprising the MIMIC-IIIterm (v1.3) critical care databaseterm.
Broadly speaking, five tables are used to define and track patient stays: ADMISSIONS; PATIENTS; ICUSTAYS; SERVICES; and TRANSFERS. Another five tables are dictionaries for cross-referencing codes against their respective definitions: D_CPT; D_ICD_DIAGNOSES; D_ICD_PROCEDURES; D_ITEMSterm; and D_LABITEMS. The remaining tables contain data associated with patient care, such as physiological measurementsterm, caregiver observations, and billing information.
In some cases it would be possible to merge tables—for example, the D_ICD_PROCEDURES and CPTEVENTS tables both contain detail relating to procedures and could be combined—but our approach is to keep the tables independent for clarity, since the data sources are significantly different. Rather than combining the tables within MIMIC data modelterm, we suggest researchers develop database viewsterm and transforms as appropriate.
Technical Validation The number of structural changes were minimized to achieve the desired level of deidentification and data schema, helping to ensure that MIMIC-IIIterm closely represents the raw data collected within the Beth Israel Deaconess Medical Center.
Best practice for scientific computing was followed where possible 7 . Code used to build MIMIC-IIIterm was version controlledterm and developed collaboratively within the laboratory. This approach encouraged and facilitated sharing of readable code and documentation, as well as frequent feedback from colleagues.
Issue trackingterm is used to ensure that limitations of the data and code are clearly documented and are dealt with as appropriate. The research community is encouraged to report and address issues as they are found, and a system for releasing minor database updates is in place.
Usage Notes Data access MIMIC-IIIterm is provided as a collection of comma separated valueterm (CSV) files, along with scripts to help with importing the data into database systems including PostreSQL, MySQL, and MonetDB. As the database contains detailed information regarding the clinical care of patients, it must be treated with appropriate care and respect. Researchers are required to formally request access via a process documented on the MIMIC website 8 . There are two key steps that must be completed before access is granted: the researcher must complete a recognized course in protecting human research participants that includes Health Insurance Portability and Accountability Act (HIPAAterm) requirements.
the researcher must sign a data use agreementterm, which outlines appropriate data usage and security standards, and forbids efforts to identify individual patients.
Approval requires at least a week. Once an application has been approved the researcher will receive emails containing instructions for downloading the database from PhysioNetWorksterm, a restricted access component of PhysioNet 9 .
Example usage MIMIC has been used as a basis for coursework in numerous educational institutions, for example in medical analytics courses at Stanford University (course BIOMEDIN215), Massachusetts Institute of Technology (courses HST953 and HST950J/6.872), Georgia Institute of Technology (course CSE8803), University of Texas at Austin (course EE381V), and Columbia University (course G4002), amongst others. MIMIC has also provided the data that underpins a broad range of research studies, which have explored topics such as machine learning approaches for prediction of patient outcomes, clinical implications of blood pressure monitoring techniques, and semantic analysis of unstructured patient notes 10–13 .
A series of 'datathonsterm' have been held alongside development of the MIMIC database. These events assemble caregivers, data scientists, and those with domain-specific knowledge with the aim of creating ideas and producing clinically relevant, reproducible research 14 . In parallel the events introduce new researchers to MIMIC and provide a platform for continuous review and development of code and research.
Documentation for the MIMIC database is available online 8 . The content is under continuous development and includes a list of studies that have been carried out using MIMIC. The website includes functionality that enables the research community to directly submit updates and improvements via GitHub.
Collaborative research Our experience is that many researchers work independently to produce code for data processing and analysis. We seek to move towards a more collaborative, iterative, and self-checking development process where researchers work together on a shared code baseterm. To facilitate collaboration, a public code repositoryterm has been created to encourage researchers to develop and share code collectively: https://github.com/MIT-LCP/mimic-code .
The repository has been seeded with code to calculate commonly utilized variables in critical care research, including severity of illness scoresterm, comorbidity scoresterm, and duration of various treatments such as mechanical ventilationterm and vasopressor useterm. We encourage users to incorporate this code into their research, provide improvements, and add new contributions that have potential to benefit the research community as a whole. Over time, we expect the repository to become increasingly vital for researchers working with the MIMIC-IIIterm database.
Alongside work on the centralized codebase, we support efforts to transform MIMIC into common data modelsterm such the Observational Medical Outcomes Partnership Common Data Modelterm (OMOP-CDM) 5 . Developing these common models may help to facilitate integration with complementary datasetsterm and to enable the application of generalized analytic toolsterm. Important efforts to map concepts to standardized clinical ontologiesterm are also underway.
Additional Information How to cite this article: JohnsonpersName, A. E. W. et al. MIMIC-IIIterm, a freely accessible critical care databaseterm. Sci. Data 3:160035 doi: 10.1038/sdata.2016.35 (2016).
Supplementary Material Acknowledgments This research and development was supported by grants NIH-R01-EB017205, NIH-R01-EB001659, and NIH-R01-GM104987 from the National Institutes of Health. The authors would also like to thank Philips Healthcare and staff at the Beth Israel Deaconess Medical Center, Boston, for supporting database development, and Ken Pierce for providing Fig. 1.
Footnotes Data Citations References Associated Data Data Citations Supplementary Materials