-
Notifications
You must be signed in to change notification settings - Fork 35
New Data Element: O2 Device (Tier 1)
In service of our goal to provide the richest possible dataset to support COVID-19 and long-COVID research, we are seeking sites willing to add new data elements to their common data models (and therefore N3C payloads). It is unlikely that you are supporting any of the below data elements already (though let us know if you are!); for this reason, we are providing guidance for extracting and mapping data elements and templates that you can use to store these data in your local CDMs, which will then flow through to your N3C payloads.
So that we can process everyone’s payloads consistently, we ask that you use these design templates if you are going to provide these data elements.
Have questions? Need to discuss how to apply this guidance at your site? Please reach out via the PASC Slack in the #data-enhancements channel.
Important Note on Privacy & Source/Raw Fields: These specifications require the inclusion of source/raw fields in some instances. Sites should verify these data fields do not include personally identifiable information before submitting data to N3C.
Why is this important?
This is an important element for N3C research as a significant number of hospitalized COVID patients required oxygen supplementation and/or ventilation support from an oxygen device and/or a ventilator. Current CDM data do not capture oxygen supplementation with the necessary granularity.
What sites should implement this?
Sites that have inpatient units with non-invasive and invasive O2 supplementation/ventilator capacity.
Scope and Description
- N3C will add oxygen supplementation and ventilator in a phased approach. This guidance describes the first phase, referred to here as “Tier 1”.
- The Tier 1 Variable of O2 device will answer the question “At a given time during an inpatient stay, which O2 device was the patient placed on to receive oxygen support?”. This encompasses any kind of O2 device used for oxygen supplementation and/or respiratory support from oxygen cannulas to invasive ventilators.
- When a patient is on an O2 device, it is recorded at regular intervals. Please capture all of the date and time stamped values where appropriate. If the size of the resulting dataset at your site becomes a concern, please contact us for help.Sites will map O2 devices to a corresponding code in the SNOMED vocabulary or one of two custom codes. Details on the mapping process can be found below.
- For one of the custom codes (“other oxygen device”), sites will need to bring in the raw/source value so that the N3C team can evaluate and review the mappings and to provide further guidance to sites (if need be).
Sourcing and defining O2 Device data for N3C
For sites that have Epic as their source system, much of the O2 device data will be found within flowsheets. We recommend searching for flowsheets named in the following list: '%vent %', '%O2%', '%oxy%' (or synonyms for this). Then, restrict to a flowsheet measure name of “O2 Device” (or synonyms for this at your site). However, you are not limited to this list and should investigate to make sure you are capturing most if not all of the O2 devices of interest from the table below.
In order to ensure usability in the N3C Enclave, O2 devices must be mapped to standardized codes. The SNOMED class type “Physical Object” works well to describe O2 devices, and therefore SNOMED will be used as the standardized codeset for O2 devices. Two exceptions to this will require custom codes outside of SNOMED. If you have any questions along the way or are unsure about a mapping, please reach out via the PASC Slack in the #data-enhancements channel.
Each site must try to map to the most granular code possible, and we recommend the following multi-step approach to mapping:
- Start with the list of suggested mappings shown below and available in this spreadsheet. This list is not exhaustive, rather it is meant to be a starting place.
- If the source data contains values not captured in the list, sites should (a) look for alternative, valid SNOMED codes and (b) add the selected code to the spreadsheet.
- We recommend using the Athena tool to find additional SNOMED codes. If using Athena, your search should include the following criteria in order to ensure the code is valid: Domain ID = Device, Concept = Standard, Class ID = Physical Object, Vocabulary ID = SNOMED, Validity = Valid.
- If, after reviewing the suggested mappings and looking for alternative SNOMED mappings, you cannot find a valid mapping, you may use the custom code for “other oxygen devices”. Sites should only resort to the “other oxygen device” code if nothing else matches. The N3C Data Harmonization team will evaluate the source/raw values mapped to this code to determine if they can be harmonized. See data model specific instructions below.
- Finally, “room air”, which is often captured in the context of O2 device data, particularly when a patient may be transitioning off of O2 supplementation, requires a custom code. See data model specific instructions below.
Suggested O2 SNOMED Mappings for N3C (Source: N3C Tier 1 Oxygen SNOMED Codes Spreadsheet)
| O2 Device | VOCAB | CODE |
| Aerosol oxygen mask | SNOMED | 426851007 |
| Aerosol Tent, adult | SNOMED | 468450007 |
| Aerosol Tent, pediatric | SNOMED | 701256005 |
| Air-entrainment mask | SNOMED | 428285009 |
| AMBU mask | SNOMED | 371785003 |
| Basic nasal oxygen cannula | SNOMED | 466713001 |
| BiPAP oxygen nasal cannula | SNOMED | 425826004 |
| Blow by oxygen mask | SNOMED | 425478008 |
| Continuing positive airway pressure unit | SNOMED | 37874008 |
| Continuous positive airway pressure/Bilevel positive airway pressure mask | SNOMED | 706226000 |
| CPAP nasal oxygen cannula | SNOMED | 467645007 |
| Face tent oxygen delivery device | SNOMED | 426294006 |
| High Flow Nasal Cannula, HFNC | SNOMED | 426854004 |
| Low Flow Nasal Cannula | SNOMED | 466713001 |
| Nasal Cannula (L) | SNOMED | 466713001 |
| standard nasal cannula | SNOMED | 466713001 |
| Non-rebreather oxygen mask | SNOMED | 427591007 |
| Non-rebreathing oxygen face mask | SNOMED | 463225005 |
| Oxygen administration face tent | SNOMED | 464578003 |
| Oxygen mustache cannula | SNOMED | 720744009 |
| Oxygen pendant cannula | SNOMED | 720743003 |
| oxygen reservoir cannula | SNOMED | 720742008 |
| Oxygen Ventilator | SNOMED | 426160001 |
| Oxyhood | SNOMED | 427594004 |
| Oxymask | SNOMED | 336602003 |
| Oxymizer | SNOMED | 720742008 |
| Partial rebreather oxygen mask | SNOMED | 425926003 |
| Partial-rebreathing oxygen face mask | SNOMED | 464233000 |
| Oxygen mask | SNOMED | 336602003 |
| T-Piece with bag | SNOMED | 415698007 |
| T-Piece without bag | SNOMED | 415700003 |
| Trach Collar, Tracheostomy Collar | SNOMED | 465839001 |
| Tracheostomy mask, aerosol | SNOMED | 465256000 |
| Tracheostomy mask, oxygen | SNOMED | 465839001 |
| Transtracheal oxygen catheter | SNOMED | 426129001 |
| Ventilator | SNOMED | 706172005 |
| Venturi Mask | SNOMED | 428285009 |
| Venturi oxygen face mask | SNOMED | 465433006 |
Example: Using the Custom Codes
The items in the table below do not have a valid matching SNOMED code. It is possible that a clinician may recognize one of these times as being substantially similar to an existing, valid SNOMED code. However, we know that not all sites will have the ability to consult with a subject matter expert, so the custom Other O2 Device code may be used.
| O2 Device | Code (See data model for specific instructions below ) |
| Bag Mask | Custom Other O2 Device Code |
| Bubble CPAP | Custom Other O2 Device Code |
| Face Bucket | Custom Other O2 Device Code |
| Manual Ventilation Bag | Custom Other O2 Device Code |
| NIV (non-invasive ventilator), Non-Invasive Positive Pressure | Custom Other O2 Device Code |
| optiflow | Custom Other O2 Device Code |
| Vapotherm | Custom Other O2 Device Code |
| Room Air | Custom Room Air Code |
We have separate instructions for each data model below.
OMOP sites will follow the standard ETL process of mapping source codes extracted from the Flow Sheets to a standard vocabulary. It is the preference of the initial data enhancements for ventilation data to use terms with a Concept Class ID = Physical Object and Domain ID = Device. The table above provides guidance on the way to map Flow Sheet terms that do not map to a standard OMOP concept. In addition to the suggested mappings above, there may be additional values observed in your data that you wish to map. We suggest using the “Other oxygen device” code to start and report these values to the N3C DI&H team for consideration in this documentation. Values you map will correspond to a record in the CONCEPT table, which dictates a DOMAIN_ID. The DOMAIN_ID will tell you which domain to place the content into. Specifications for domains can be found in the OMOP CDM Wiki (https://ohdsi.github.io/CommonDataModel/cdm53.html).
We have created a custom N3C concept_id to reflect custom concepts requested by clinicians. Below is an example of the CONCEPT records for representing these codes. At a minimum, use the concept_id specified in the first column to custom map your values into your OMOP CDM. The table below can be used to amend insert into your local CONCEPT table to include these custom mappings.
| concept_id | concept_name | domain_id | vocabulary_id | concept_class_id | standard_concept | concept_code | valid_start_date | valid_end_date | invalid_reason |
| 2004208004 | Other oxygen device | Device | N3C | Physical Object | NULL | OT_O2_DEVICE | 1/1/1970 | 12/31/2099 | NULL |
| 2004208005 | Room air (in the context of a device) | Device | N3C | Physical Object | NULL | ROOM_AIR | 1/1/1970 | 12/31/2099 | NULL |
This concept_id will be added to the N3C OMOP vocabulary tables inside the enclave. The ID number chosen was arbitrary. If it collides with a custom concept_id that you use locally, please let us know. Questions? Strike up a thread on the OHDSI Forum (https://forums.ohdsi.org/) and tag in the OMOP Vocabulary Team (@Dymshyts @Christian_Reich @Alexdavv @krfeeney).
A DEVICE_EXPOSURE record with a custom ROOM_AIR record would look like this:
| device_exposure_id | person_id | device_concept_id | device_exposure_start_date | device_exposure_start_datetime | device_exposure_end_date | device_exposure_end_datetime | device_type_concept_id | unique_device_id | quantity | provider_id | visit_occurence_id | visit_detail_id | device_source_value | device_source_concept_id |
| 123456 | 007007007 | 2004208005 | 01-01-2022 | NULL | NULL | NULL | 32817 | NULL | NULL | 008008008 | 1234777 | 1234678 | ROOM_AIR | 2004208005 |
Assumption is that if populated, values in PROVIDER_ID would be information from the PROVIDER domain, VISIT_OCCURRENCE_ID would link to a record in the VISIT_OCCURRENCE domain, VISIT_DETAIL_ID would link to a record in the VISIT_DETAIL domain.
PCORnet sites will use the OBS_GEN table to store Tier 1- O2 device related flowsheet_ _information. To provide this data element, adjust your ETL to include the O2 device variables as described above, and use those data to fill in an OBS_GEN row as shown below. (Fields not shown in the example are not required for N3C and may be null.) Note that these visits should also appear in your ENCOUNTER table
- If the O2 device maps to a SNOMED code, OBSGEN_TYPE should equal ‘SM’ and OBGEN_CODE should include the SNOMED code.
- If using either of the custom codes, OBSGEN_TYPE should equal ‘UD_N3C_O2_DEVICE’ and OBSGEN_CODE should include either ‘OT_O2_DEVICE’, or ‘ROOM_AIR’.
- Please include the source O2 device name in the RAW_OBSGEN_NAME field. We will be reviewing the source names for any O2 device that has been mapped to the Custom code for OT_O2_DEVICE and then will help sites map to a more granular SNOMED code if one is available.
OBS_GEN Template for Tier 1: O2 Devices
| OBSGENID | PATID | ENCOUNTERID | OBSGEN_START_DATE | OBSGEN_START_TIME | OBSGEN_STOP_DATE | OBSGEN_STOP_TIME | OBSGEN_TYPE | OBSGEN_CODE | OBSGEN_TABLE_MODIFIED | OBSGEN_ID_MODIFIED | OBSGEN_SOURCE | RAW_OBSGEN_NAME |
| {generated by your ETL} | {patient attached to the visit} | {visit id of the clinic visit} | {start date} | {start time} | {stop date, if available} | {stop time, if available} | UD_N3C_O2_DEVICE {custom type} | {Custom code} | ENC | {whichever option is appropriate for your site} | {souce value} | |
| {generated by your ETL} | {patient attached to the visit} | {visit id of the clinic visit} | {start date} | {start time} | {stop date, if available} | {stop time, if available} | {vocabulary used, most often will be SNOMED} | {SNOMED code for O2 Device} | ENC | {whichever option is appropriate for your site} | {souce value} |
OBS_GEN Example for Tier 1: O2 Devices
| OBSGENID | PATID | ENCOUNTERID | OBSGEN_START_DATE | OBSGEN_START_TIME | OBSGEN_STOP_DATE | OBSGEN_STOP_TIME | OBSGEN_TYPE | OBSGEN_CODE | OBSGEN_TABLE_MODIFIED | OBSGEN_ID_MODIFIED | OBSGEN_SOURCE | RAW_OBSGEN_NAME |
| 1 | P11 | E1 | 5/11/2021 | 00:00 | NULL | NULL | UD_N3C_O2_DEVICE | ROOM_AIR | ENC | E1 | DR | None (Room air) |
| 2 | P12 | E12 | 5/11/2021 | 00:00 | NULL | NULL | UD_N3C_O2_DEVICE | OT_O2_DEVICE | ENC | E12 | DR | Face Bucket |
| 3 | P25 | E3 | 5/11/2021 | 06:05 | NULL | NULL | SM | 428285009 | ENC | E3 | DR | Venturi mask;Other (Comment) |
ACT sites will use the OBSERVATION_FACT table to record ventilator flowsheet facts. Follow the instructions above for mapping to SNOMED code (see Mapping O2 Devices). When mapping please place the SNOMED CT code in the concept_cd field with the namespace/prefix ‘SNOMED:’. If you are unable to find an appropriate SNOMED code to match your source value, please map to N3C specific code ‘N3C:OT_O2_DEVICE’, set the modifer_cd to RAW and place the non-PHI source value in your observation_blob field. This will help the N3C DI&H team determine if further harmonization is possible. If the source value indicates ‘Room Air’ please map to N3C specific code ‘N3C:ROOM_AIR’. Again remember for any row where you supply raw source data in the observation blob field be sure to set the modifier_cd to ‘RAW’.
All other i2b2 ETL fact rules apply including corresponding visit_dimension and patient_dimension row entries.
[OBSERVATION_FACT] Template for Oxygen Supplementation and Ventilator Facts
| encounter_num | start_date | end_date | patient_num | concept_cd | valtype_cd | valueflag_cd | modifier_cd | observation_blob |
| {visit num} | {date of event} | {patient attached to the visit} | {ventilator type SNOMED code} | T | {answer LOINC code} | {‘RAW’ when data is placed in the observation_blob field, otherwise NULL} | {raw source value for ventilator type OTHER only} |
[OBSERVATION_FACT] Example for Oxygen Supplementation and Ventilator Facts
| encounter_num | start_date | end_date | patient_num | concept_cd | valtype_cd | valueflag_cd | modifier_cd | observation_blob |
| 12345678 | 12-NOV-21 | 3456789 | SNOMED:466713001 | T | NULL | |||
| 23456789 | 12-NOV-21 | 4567890 | N3C:OT_O2_DEVICE | T | RAW | other O2 Device name from source | ||
| 34567890 | 12-NOV-21 | 5678901 | N3C:ROOM_AIR | T | NULL |
If you are populating your TriNetX data from one of the data models above, the best approach would be to use one of the above approaches in your upstream data, and then allow those data to flow through to TriNetX. If you are populating TriNetX directly from your EHR or a custom data warehouse, please load Hospital Oxygen Supplementation and Ventilator Data into the Procedure table. The code representing the O2 Device should be stored in the Code field.
If you have any questions, please reach out to {n3c at trinetx dot com}. It is also helpful if you let the N3C team know via Slack if and when you plan to add this enriched data, so that we know to look out for it.