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.

• Overview
• How should we structure the data?
  • OMOP
  • PCORnet
  • i2b2/ACT
  • TriNetX

What are ADT Transactions?

ADT Transactions encompass any event, transition, or change in a patient’s location, department, level of service, or accommodation that would be recorded in a Health System’s Admission, Discharge, and Transfer hospital information system. ADT Transactions are recorded when a patient presents to a health care system, and tracked during a patient’s stay until departure.

Why is this important?

Researchers investigating outcomes for hospitalized COVID patients need more granular data on patient movement within a visit than is currently available in CDMs. Of highest interest are ADT transactions related to the Emergency Department and Intensive Care Units.

What sites should implement this?

Sites with inpatient data who have the ability to add ADT transaction data to their CDM.

Scope and Description

• ADT transaction data should include all ADT transactions for patients in your N3C cohort.
• Sites will need to specifically identify ED and ICU-related transactions using the vocabulary described in the section How should we structure the data?** **All other transactions can be labeled generically as inpatient.
• While sites are not expected to map every inpatient unit to a standardized vocabulary, we ask that sites include the local unit or department name in a relevant source/raw field.

Sourcing and Defining ADT Transactions

We are aware that health systems represent these data differently and many had to make adjustments during the pandemic (e.g., providing ICU-level care in a non-ICU location). To determine the best source of this information, start by considering how your site could most accurately determine the intervals in which a patient was in an ICU setting. Sites should evaluate using the following sources (or combination of sources) for populating their ADT transaction data:

• Department specialties - Look for relevant names such as Emergency Medicine or Intensive Care
• Patient service - A patient service may be a generalized categorization of service provided by a unit or department, such as Radiology, Surgical ICU, or Medical ICU.
• Accommodation code/levels - Accommodations are typically associated with a room in a hospital that has an associated accommodation code. This code is based on the conditions in that room or bed, which may be indicative of changing patient condition as well. Category values include private, semi-private, and telemetry. There are usually codes specific to Intensive Care and Emergency.
• Level of care - A level of care is broader than patient service and represents the ratio and acuity of nursing care provided to the patient, examples include Intensive Care, Emergency, Skilled, or Acute.

Consider plausible synonyms for Intensive Care, such as Critical Care Units, or any specialized Intensive Care, such as cardiology, neurology, or pediatric intensive care units.

Note, that levels of service and Emergency Room acuity are not generally tied to ADT activity. Unless a site can link periods of time to these measures, they are not recommended to use these data elements to populate this field.

Though specifics vary by data model, the following apply to all sites completing the ADT transaction data enhancement.

• ADT transaction data does not require changes to your visit occurrence/encounter tables.
• ADT transaction data must be mapped one of three designated codes to represent ICU, Emergency Department, and all other inpatient transactions.
• Sites should include raw/source values in the appropriate fields in their CDM. These fields will be used for validation and harmonization purposes and will not be exposed to end users in the N3C Enclave.
• If your site has observation visits captured in your ADT transaction data, the related transactions do not need to be included in your N3C data. Should you choose to include them, please choose an appropriate code other than the three chosen for N3C's ADT data.

See below for specific instructions for each data model.

OMOP sites will use the VISIT_ DETAIL table to store this information. For VISIT_DETAIL_CONCEPT_ID, sites are asked to map their data as follows:

• ICU maps to OMOP concept ID 581379 "Inpatient Critical Care Facility"
• ED maps to OMOP concept ID 8870 "Emergency Room - Hospital"
• OMOP concept ID 8717 "Inpatient Hospital" is to be used as the default classification if the ADT transaction is not one of the above.

To provide this data element, adjust your ETL to capture ADT transactions, and use those data to fill in a VISIT_DETAIL row as shown below. (Fields not shown in the example are not required for N3C and may be null.) Please place the source value in the VISIT_DETAIL_SOURCE_VALUE field. This field will be used for validation and harmonization purposes and will not be exposed to end users in the N3C Enclave.

Note that these visits should also appear in your VISIT_OCCURRENCE table.

VISIT_DETAIL Template for ADT Transactions

visit_detail_id	visit_detail_start_datetime	visit_detail_end_datetime	visit_occurrence_id	person_id	visit_detail_concept_id	visit_detail_source_value
{generated by your ETL}	{datetime start of ADT record}	{datetime end of ADT record}	{FK to visit_occurrence record of the encompassing visit }	{patient attached to the visit}	{Relevant OMOP code as described above}	{verbatim source data}

VISIT_DETAIL Example for ADT Transactions

visit_detail_id	visit_detail_start_datetime	visit_detail_end_datetime	visit_occurrence_id	person_id	visit_detail_concept_id	visit_detail_source_value
1	‘2021-12-15 06:10:00’	‘2021-12-15 15:15:00’	1234	999	8870	‘ED’
2	‘2021-12-15 15:15:00’	‘2021-12-15 21:50:00’	1234	999	581379	‘ICU’
3	‘2021-12-15 21:50:00’	‘2021-12-18 09:34:00’	1234	999	8717	‘MedWing 2’

When exporting the OMOP VISIT_DETAIL table for your N3C payload, you will need to use the ADT Extract Scripts. Instructions for using multiple extract scripts can be found in the Python Exporter and R Exporter documentation.

PCORnet sites will use the OBS_GEN table to store this information. All ADT transactions should be mappable to one of the three following codes:

• ICU maps to OMOP concept ID 581379 "Inpatient Critical Care Facility"
• ED maps to OMOP concept ID 8870 "Emergency Room - Hospital"
• OMOP concept ID 8717 "Inpatient Hospital" is to be used as the default classification if the ADT transaction is not one of the above.

To provide this data element, adjust your ETL to capture ADT transactions, 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.)

Please place the source value in the RAW_OBSGEN_NAME field. Please use RAW_OBSGEN_TYPE to represent where the source value comes from - i.e., if department name, please enter “Department; if service name, please enter “Service”, etc. These fields will be used for validation and harmonization purposes and will not be exposed to end users in the N3C Enclave.

Note that these visits should also appear in your ENCOUNTER table.

OBS_GEN Template for ADT Transactions

obsgenid

patid

encounterid

obsgen_start_date

obsgen_start_time

obsgen_stop_date

obsgen_stop_time

obsgen_type

obsgen_code

obsgen_source

raw_obsgen_name

raw_obsgen_code

raw_obsgen_type

{generated by your ETL}

{patient attached to the visit}

{visit id of the clinic visit}

{datetime of transfer in event}

{time of transfer in event}

{datetime of transfer out event}

{time of transfer out event}

UD_ADTEVENT {custom type}

{Relevant custom code as described above}

{whichever option is appropriate for your site}

{native value}

{native value}

{native value}

OBS_GEN Example for ADT Transactions

obsgenid

patid

encounterid

obsgen_start_date

obsgen_start_time

obsgen_stop_date

obsgen_stop_time

obsgen_type

obsgen_code

obsgen_source

raw_obsgen_name

raw_obsgen_code

raw_obsgen_type

1

A123

E987

2020-06-01 08:00

08:00

2020-06-01 11:30

11:30

UD_ADTEVENT

8870

HC

Emergency

888

Department

2

A123

E987

2020-06-01 11:30

11:30

2020-06-03 17:00

17:00

UD_ADTEVENT

581379

HC

ICU

777

Department

3

A123

E987

2020-06-03 17:00

17:00

2020-06-05 08:00

08:00

UD_ADTEVENT

8717

HC

Cardiology

444

Service

4

B234

E876

2020-07-01 12:00

12:00

2020-07-01 15:00

15:00

UD_ADTEVENT

8870

HC

Pediatric ER

555

Department

5

C345

E765

2020-08-01 09:00

09:00

2020-08-0211:00

11:00

UD_ADTEVENT

8717

HC

Bedtwoer8

222

Department

ACT sites will use the OBSERVATION_FACT table to store ADT transaction data. Each ADT transaction should be mapped to one of three concept codes :N3C:ADT_ED, N3C:ADT_ICU, N3C:ADT_OTHER.

To provide this data element, adjust your ETL to identify all ADT encounters, and use those data to fill in an OBSERVATION_FACT row as shown below.

• If the ADT encounters link directly to a visit recorded in your VISIT_DIMENSION use the same ENCOUNTER_NUM in the OBSERVATION_FACT table.
• If the ADT records do not share the encounter_num with the VISIT DIMENSION table generate encounter_num for each unique ADT id. Make sure that it is not possible for the visit ids and ADT ids to overlap unless that is by design within your data warehouse. Optionally, to keep VISIT_DIMENSION and OBSERVATION_FACT in sync, you may create corresponding VISIT_DIMENSION records. Review the size impact this will have on your CDM and make the best decision for your environment.
• ADT facts may export the raw source data. The modifier_cd field must be set to the value RAW for these data elements.

Please place the source value in the OBSERVATION_BLOB field. This field will be used for validation and harmonization purposes and will not be exposed to end users in the N3C Enclave.

OBSERVATION_FACT Template for ADT Transactions

encounter_num	start_date	end_date	patient_num	concept_cd	modifier_cd	observation_blob
{visit number or generate if one does not exists}	{start date time of transaction}	{end date time of transaction}	{patient attached to the visit}	{N3C custom ADT concept codes - N3C:ADT_ED, N3C:ADT_ICU, N3C:ADT_OTHER}	RAW	{raw source value, before mapping to concept codes}

OBSERVATION_FACT Example for ADT Transactions

encounter_num	start_date	end_date	patient_num	concept_cd	modifier_cd	observation_blob
12345678	2021-12-15 06:10:00	2021-12-15 15:15:00	3456789	N3C:ADT_ED	RAW	Emergency
23456789	‘2021-12-15 15:15:00	2021-12-15 21:50:00	3456789	N3C:ADT_ICU	RAW	PICU
34567890	2021-12-15 21:50:00	2021-12-18 09:34:00	3456789	N3C:ADT_OTHER	RAW	Pulm Unit

ADT data being fed into N3C is supported through a supplemental file provided to TriNetX. As this is a supplemental file, the formatting of the file is flexible. The following data elements are supported, but we will require patient ID, encounter ID, start datetime, end datetime, and at least one of the supporting ADT fields.

Column	Data Type	Format	Note
Patient ID	varchar		Patient ID should match the patient ID provided to TriNetX through your standard data submission.
Encounter ID	varchar		Encounter ID should match to an encounter provided to TriNetX through your standard data submission.
Start Date Time	datetime	YYYYmmdd HH:mm:ss	Starting date and time of ADT information
End Date Time	datetime	YYYYmmdd HH:mm:ss	Ending date and time of ADT information
Location	varchar		An ID or description of where the patient was. This can be more detailed than the typical location shared to TriNetX (e.g. - department, department specialty, room, bed, etc.).
Service	varchar		A description of the patient or medical service.
Accommodation Code	varchar		This typically flags something to do with the bed or room (e.g. - semi-private, ICU, etc.).
Level of Care	varchar		An indication of the level of care provided to the patient.

Based on the information provided, inform TriNetX what flags an encounter as either ICU or ED.

For additional questions, please reach out to {[email protected]}. 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.