minor edits

content/en/docs/mimic-nw/_index.md

@@ -8,7 +8,7 @@ cascade:
   _target:
     path: "/**"
 ---
-MIMIC-Fed is a large, freely available federated COVID-rich ICU database comprising deidentified health-related data from Beth Israel Deaconess Medical Center (BIDMC) and Northwestern Memorial Health Center (NHMC) from 2020 to 2022. The federated database adopts a similar data structure as MIMIC-IV v2.2.
+MIMIC-Fed is a large, freely available federated COVID-rich ICU database comprising deidentified health-related data from Beth Israel Deaconess Medical Center (BIDMC) and Northwestern Memorial Health Center (NHMC) from 2020 to 2022, capturing the evolving distribution shifts in data over this critical time period. The federated database adopts a similar data structure as MIMIC-IV v2.2.
 
 Notably, Northwestern Memorial Health Center (NHMC) uses the Epic electronic medical records (EMR) system. To make the EMR data available for research and quality assurance, the NM EMR systems transfer selected data into a relational Enterprise Data Warehouse (NM EDW). 
 
@@ -18,7 +18,7 @@ The NM EDW also includes auxiliary tables not directly related to patient care,
 
 MIMIC-Fed is currently organized into two distinct modules to highlight the source of the data:
 
-- [hosp](/docs/mimic-nw/modules/hosp/) - Hospital level data including patients, admissions, labs, ICD diagnoses for billing purposes, prescriptions, and electronic medication administration records.
-- [icu](/docs/mimic-nw/modules/icu/) - ICU level data including icu stays, procedure events, chartevents (vital signs). 
+- [HOSP](/docs/mimic-nw/modules/hosp/) - Federated hospital level data including patients, admissions, labs, ICD diagnoses for billing purposes, prescriptions, and electronic medication administration records.
+- [ICU](/docs/mimic-nw/modules/icu/) - Federated ICU level data including icu stays, procedure events, chartevents (vital signs). 
 
-The tables structures adopted to align with MIMIC's data structure for each module are detailed in the respective sections.
+The tables structures adopted to align with MIMIC's data structure for each module are detailed in the respective sections. Additionally, we have incorporated COVID-related concepts and standard terminologies (LOINC, RxNorm, SNOMED, ICD-9/10) and derived mappings (for drug administration) into the dataset. This integration not only facilitates current federation efforts, but also facilities interoperability, allowing for seamless data exchange and collaboration across healthcare systems.

content/en/docs/mimic-nw/modules/hosp/_index.md

@@ -4,9 +4,11 @@ linkTitle: "Hosp"
 date: 2023-09-18
 weight: 20
 description: >
-  The Hosp module comprises data sourced from the comprehensive Electronic Health Record (EHR) systems of both BIDMC and NMHC hospitals. Information covered includes patient and admission information, laboratory measurements, billed diagnoses, prescriptions, and electronic medication administration records.
+  The Hosp module comprises data sourced from the comprehensive Electronic Health Record (EHR) systems of both BIDMC and NHMC hospitals. Information covered includes patient and admission information, laboratory measurements, billed diagnoses, medication orders, and electronic medication administration records.
 ---
 
-The hosp module contains data derived from the hospital wide EHR. These measurements are predominantly recorded during the hospital stay, though some tables include data from outside the hospital as well (e.g. outpatient laboratory tests in labevents). Information includes patient and admission details (patients, admissions), laboratory measurements (labevents, d_labitems), hospital billing information (diagnoses_icd, d_icd_diagnoses), medication prescription (prescriptions), and electronic medication administration records (emar).
+The HOSP module contains data derived from the hospital wide EHR of BIDMC and NHMC. These measurements are predominantly recorded during the hospital stay, though some tables include data from outside the hospital as well (e.g. outpatient laboratory tests in *labevents*). 
+
+Information includes patient and admission details (*patients*, *admissions*), laboratory measurements (*labevents*, *d_labitems*), hospital billing information (*diagnoses_icd*, *d_icd_diagnoses*), medication orders (*prescriptions*), and electronic medication administration records (*emar*).
 
 

content/en/docs/mimic-nw/modules/hosp/admissions.md

@@ -44,7 +44,7 @@ The *admissions* table defines all hospitalizations in the database. Hospitaliza
 
 ### `hadm_id`
 
-Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. It is possible for this table to have duplicate `subject_id`, indicating that a single patient had multiple admissions to the hospital. The ADMISSIONS table can be linked to the PATIENTS table using `subject_id`.
+Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. It is possible for this table to have duplicate `subject_id`, indicating that a single patient had multiple admissions to the hospital. The ADMISSIONS table can be linked to the *patients* table using `subject_id`.
 
 ### `admittime`
 
@@ -142,4 +142,4 @@ The date and time at which the patient was discharged from the emergency departm
 
 ### `hospital_expire_flag`
 
-This is a binary flag which indicates whether the patient died within the given hospitalization. `1` indicates death in the hospital as noted in the `dod` column as part of the patient table, and `0` indicates survival to hospital discharge. 
+This is a binary flag which indicates whether the patient died within the given hospitalization. `1` indicates death in the hospital as noted in the `dod` column as part of the *patient* table, and `0` indicates survival to hospital discharge. 

content/en/docs/mimic-nw/modules/hosp/d_icd_diagnoses.md

@@ -42,11 +42,11 @@ ICD-11 became the official [WHO standard](https://www.who.int/standards/classifi
 
 ### `long_title`
 
-The `long_title` provides a description of the ICD code. For example, the ICD-10 code U07.1 has `long_title` "COVID-19 (confirmed by laboratory testing)".
+The `long_title` provides a description of the ICD code. For example, the ICD-10 code U07.1 has a `long_title` of 'COVID-19 (confirmed by laboratory testing)'.
 
 In the tables below, we provide ICD-10 codes related to covid or long covid.
 
-ICD-10 COVID markers terminologies:
+Terminologies related to COVID markers in the ICD-10:
 
 | icd_code | long_title                                                |
 | -------- | -------------------------------------------------------- |
@@ -56,13 +56,13 @@ ICD-10 COVID markers terminologies:
 | J12.81   | Pneumonia due to SARS-associated coronavirus           |
 
 
-ICD-10 Long COVID markers terminologies:
+Terminologies for Long COVID markers in ICD-10:
 
 | icd_code | long_title                                      |
 | -------- | ---------------------------------------------- |
 | U09.9    | Post COVID-19 condition, unspecified            |
 
-ICD-10 Other COVID related terminologies:
+Terminologies related to other COVID aspects in ICD-10:
 
 | icd_code | long_title                                                                                               |
 |----------|-----------------------------------------------------------------------------------------------------------|

content/en/docs/mimic-nw/modules/hosp/diagnoses_icd.md

@@ -31,7 +31,7 @@ Name | Postgres data type
 
 ### `hadm_id`
 
-Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. It is possible for this table to have duplicate `subject_id`, indicating that a single patient had multiple admissions to the hospital. The ADMISSIONS table can be linked to the PATIENTS table using `subject_id`.
+Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. It is possible for this table to have duplicate `subject_id`, indicating that a single patient had multiple admissions to the hospital. The ADMISSIONS table can be linked to the *patients* table using `subject_id`.
 
 ### `icd_code` 
 

content/en/docs/mimic-nw/modules/hosp/emar.md

@@ -9,7 +9,7 @@ description: >
 
 ## *emar*
 
-The EMAR table is used to record administrations of a given medicine to an individual patient.
+The *emar* table is used to record administrations of a given medicine to an individual patient.
 Records in this table are populated by bedside nursing staff scanning barcodes associated with the medicine and the patient.
 
 ## Links to
@@ -18,10 +18,10 @@ Records in this table are populated by bedside nursing staff scanning barcodes a
 
 ## Important considerations
 
-* In the clinical process, a doctor prescribes the medication, a pharmacist fills the prescription, and a nurse administers it through the electronic Medication Administration Record (eMAR). Therefore, it is important to note that not all 'eMAR pharmacy_id’ entries should necessarily appear in the prescription table.
+* In the clinical process, a doctor prescribes the medication, a pharmacist fills the prescription, and a nurse administers it through the electronic Medication Administration Record (eMAR). Therefore, it is important to note that not all 'eMAR pharmacy_id’ entries should necessarily appear in the *prescription* table.
 * It's possible for discrepancies to occur in the transition from left to right in this process, where a wrong prescription might be detected and corrected by the pharmacist before the medication is filled.
 * Similarly, many prescriptions don’t have a corresponding eMAR entry, usually because the prescription is intended for outpatient use following discharge.
-* It is typical for one prescription to have multiple eMAR entries; for example, a medication order “BID for 7 days” would be expected to have 14 eMAR entries.
+* It is typical for one prescription to have multiple eMAR entries; for example, a medication order 'BID for 7 days' would be expected to have 14 eMAR entries.
 
 ## Table columns
 
@@ -44,11 +44,11 @@ Name | Postgres data type
 
 ### `hadm_id`
 
-Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. It is possible for this table to have duplicate `subject_id`, indicating that a single patient had multiple admissions to the hospital. The ADMISSIONS table can be linked to the PATIENTS table using `subject_id`.
+Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. It is possible for this table to have duplicate `subject_id`, indicating that a single patient had multiple admissions to the hospital. The ADMISSIONS table can be linked to the *patients* table using `subject_id`.
 
 ### `emar_id`, `emar_seq`
 
-Identifiers for the eMAR table. `emar_id` is a unique identifier for each order made in eMAR. `emar_seq` is a consecutive integer which numbers eMAR orders chronologically. `emar_id` is composed of `subject_id` and `emar_seq` in the following pattern: '`subject_id`-`emar_seq`'.
+Identifiers for the *emar* table. `emar_id` is a unique identifier for each order made in eMAR. `emar_seq` is a consecutive integer which numbers eMAR orders chronologically. `emar_id` is composed of `subject_id` and `emar_seq` in the following pattern: '`subject_id`-`emar_seq`'.
 
 ### `charttime`
 
@@ -69,4 +69,4 @@ If present, the time at which the administration was scheduled.
 
 ### `storetime`
 
-The time at which the administration was documented in the eMAR table.
+The time at which the administration was documented in the *emar* table.

content/en/docs/mimic-nw/modules/hosp/patients.md

@@ -27,22 +27,22 @@ Name | Postgres data type
 
 ### `gender`
 
-The patient's administrative `gender`, sourced from the NW EDW and stored in the patient table, is represented as follows: F (Female), M (Male). 
+The patient's administrative `gender`, sourced from the NW EDW and stored in the *patient* table, is represented as follows: F (Female), M (Male). 
 
 ### `anchor_age`
 
 `anchor_age` is the age of the patient as of their admission date (earliest admission date if more than one). If a patient’s `anchor_age` is over 89 in the anchor_year then their anchor_age is set to 91. 
 
 This ensures that the statistical anonymity of a patient is maintained and that the  data shared complies with the [HIPPA](https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html) standards, specifically:
 
-"(C) All elements of dates (except year) for dates that are directly related to an individual, including birth date, admission date, discharge date, death date, and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older."
+'(C) All elements of dates (except year) for dates that are directly related to an individual, including birth date, admission date, discharge date, death date, and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older.'
 
 ### `anchor_year`,
 `anchor_year` is the shifted year based on the patient's shifted earliest admission date.
 
 ### `anchor_year_group`
 
-`anchor_year_group` is the sequence of three years including the the year in which a patient was admitted. For example, if a patient was admitted in 2020, 2021, or 2022,  the `anchor_year_group` will be "2020-2022."
+`anchor_year_group` is the sequence of three years including the the year in which a patient was admitted. For example, if a patient was admitted in 2020, 2021, or 2022,  the `anchor_year_group` will be '2020-2022'.
 
 ### `dod`
 

content/en/docs/mimic-nw/modules/hosp/prescriptions.md

@@ -56,7 +56,7 @@ Name | Postgres data type
 
 ### `hadm_id`
 
-Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. It is possible for this table to have duplicate `subject_id`, indicating that a single patient had multiple admissions to the hospital. The ADMISSIONS table can be linked to the PATIENTS table using `subject_id`.
+Each row of this table contains a unique `hadm_id`, which represents a single patient's admission to the hospital. It is possible for this table to have duplicate `subject_id`, indicating that a single patient had multiple admissions to the hospital. The *admissions* table can be linked to the *patients* table using `subject_id`.
 
 ### `pharmacy_id`
 
@@ -104,13 +104,13 @@ The amount of the medication which is contained in a single formulary dose.
 
 ### `form_unit_disp`
 
-The unit of measurement used for the formulary dosage. Examples include “mg”, “Units”, “mL”, “mEq”, “tablet”, “mcg/min”, “mcg/kg/hr”, etc.
+The unit of measurement used for the formulary dosage. Examples include 'mg', 'Units', 'mL', 'mEq', 'tablet', 'mcg/min', 'mcg/kg/hr', etc.
 
 
 ### `doses_per_24_hrs`
 
-The number of doses per 24 hours for which the medication is to be given. A daily dose would result in `doses_per_24_hrs`: 1, bidaily (BID) or twice a day would be 2, and so on. Within NHMC, if the medication order couldn’t be converted to doses_per_24_hrs (such as “Once”, “PRN”, “Continuous”, “Weekly”’, or “Q 90 days”) the value would be missing.
+The number of doses per 24 hours for which the medication is to be given. A daily dose would result in `doses_per_24_hrs`: 1, bidaily (BID) or twice a day would be 2, and so on. Within NHMC, if the medication order couldn’t be converted to `doses_per_24_hrs` (such as 'Once', 'PRN', 'Continuous', 'Weekly', or 'Q 90 days') the value would be missing.
 
 ### `route`
 
-The route of administration for the medication, such as “Oral”, “Intravenous”, “Injection”, “Subcutaneous”, “Inhalation”, “Topical”, etc. May be missing.
+The route of administration for the medication, such as 'Oral', 'Intravenous', 'Injection', 'Subcutaneous', 'Inhalation', 'Topical', etc. May be missing.

content/en/docs/mimic-nw/modules/icu/_index.md

@@ -4,7 +4,9 @@ linkTitle: "ICU"
 date: 2023-09-18
 weight: 30
 description: >
-  The ICU module contains information collected from the clinical information system used within the ICU. Information covered includes icu admissions, procedures, and vital signs charted information.
+  The ICU module contains information collected from the clinical information system of both BIDMC and NHMC used within the ICU. Information covered includes icu admissions, procedures, and charted vital sign data.
 ---
 
-The ICU module contains data sourced from the clinical information system at the BIDMC: MetaVision (iMDSoft). MetaVision tables were denormalized to create a star schema where the icustays and d_items tables link to a set of data tables all suffixed with "events". Data documented in the icu module includes  icu admissions (icu stays) procedures (procedureevents, d_items), and vital signs charted information (chartevents, d_items). All events tables contain a stay_id column allowing identification of the associated ICU patient in icustays, and an itemid column allowing identification of the concept documented in d_items.
+The ICU module contains data sourced from the clinical information system at the BIDMC (MetaVision (iMDSoft)) and NHMC. MetaVision tables in BIDMC were denormalized to create a star schema where the icustays and d_items tables link to a set of data tables all suffixed with *events*.
+
+Data documented in the ICU module includes icu admissions (*icu stays*), procedures (*procedureevents*, *d_items*), and charted vital sign data (*chartevents*, *d_items*). All events tables contain a `stay_id` column allowing identification of the associated ICU patient in *icustays*, and an `itemid` column allowing identification of the concept documented in *d_items*.

content/en/docs/mimic-nw/modules/icu/chartevents.md

@@ -53,7 +53,7 @@ Date and time when the vital sign was measured, deidentified.
 
 ### `itemid`
 
-Identifier for a single measurement type in the database. Each row associated with one `itemid` (e.g. 220045) corresponds to an instantiation of the same measurement (e.g. Heart Rate) for Routine Vital Signs `category`, and 'bpm' `unit_name`.
+Identifier for a single measurement type in the database. Each row associated with one `itemid` (e.g. 220045) corresponds to an instantiation of the same measurement (e.g. Heart Rate) within the `category` of 'Routine Vital Signs', and `unit_name` of 'bpm'.
 
 ### `value`, `valuenum`
 
@@ -63,7 +63,7 @@ Identifier for a single measurement type in the database. Each row associated wi
 
 ### `valueuom`
 
-`valueuom` is the unit of measurement for the `value`, if appropriate. Either missing or “%”.
+`valueuom` is the unit of measurement for the `value`, if appropriate. Either missing or '%'.
 
 ### `warning`