Skip to main content

Encounters

Methods

Code on Github

The Tuva encounter grouper organizes claims into encounters, assigning each claim and claim line to exactly one encounter. An encounter represents the interaction between a patient and a healthcare provider. For inpatient encounters, this encompasses the entire duration of an inpatient stay, which spans multiple days. Tuva consolidates all claims billed intermittently throughout a patient's stay into a single encounter, regardless of the number of claims involved. In most outpatient and office-based settings, an encounter typically spans a single day and groups together all claims that occurred on that day within that specific care setting.

Encounters are summarized into encounter groups for organizational purposes. Below is an overview of the available encounter types and groups.

ENCOUNTER_GROUPENCOUNTER_TYPE
inpatientacute inpatient
inpatientinpatient hospice
inpatientinpatient psych
inpatientinpatient rehabilitation
inpatientinpatient skilled nursing
inpatientinpatient substance use
outpatientambulatory surgery center
outpatientdialysis
outpatientemergency department
outpatienthome health
outpatientoutpatient hospital or clinic
outpatientoutpatient hospice
outpatientoutpatient injections
outpatientoutpatient psych
outpatientoutpatient pt/ot/st
outpatientoutpatient radiology
outpatientoutpatient rehabilitation
outpatientoutpatient substance use
outpatientoutpatient surgery
outpatienturgent care
office basedoffice visit
office basedoffice visit injections
office basedoffice visit pt/ot/st
office basedoffice visit radiology
office basedoffice visit surgery
office basedoffice visit - other
office basedtelehealth
otherambulance - orphaned
otherdme - orphaned
otherlab - orphaned
otherorphaned claim

The output of the encounter grouper is the Encounter table in the Core Data Model. The core.encounter table has flags associated with each encounter making it easy to find specific claims or claim lines that occurred during that encounter. Some flags apply only to specific encounter types, like delivery, which applies only to acute inpatient. The available flags are:

  • observation
  • lab
  • dme
  • ambulance
  • pharmacy
  • emergency department (for example an acute inpatient encounter where the patient came in through the ED)
  • delivery
  • delivery_type (cesarean or vaginal)
  • newborn
  • nicu

To count the number of inpatient encounters where the patient was in observation status during the stay, you can sum the observation flags and count the encounter IDs.

select sum(observation_flag) as encounters_with_observation
,count(encounter_id) as total_encounters
from core.encounter
where encounter_type = 'acute inpatient'

The start of an encounter is defined by an anchor claim that has been assigned to the same service category as the encounter type. An anchor can be either professional or institutional depending on the encounter type.

The date field used in the encounter algorithm is determined using the following priority of date fields (resulting in the first non null value):

  • start_date -> admission_date / claim_line_start_date / claim_start_date
  • end_date -> discharge_date / claim_line_end_date / claim_end_date

Inpatient

Inpatient encounters are created when an institutional claim with the service category corresponding to one of the inpatient encounter types occurs. The Date/NPI continuity algorithm checks if a claim overlaps with another claim, with the same facility NPI, patient_id, and data_source. It also adds a specific check for the case where the end date and start date of two claims are within a day, checking if the discharge disposition code is 30 (still patient). This logic is in place to avoid grouping together claims where a patient is discharged and readmitted on the same day.

Each inpatient encounter type is listed below with the algorithm, anchor, and anchor claim type.

ENCOUNTER_GROUPENCOUNTER_TYPEAlgorithm TypeService Category AnchorAnchor Claim Type
inpatientacute inpatientdate/npi continuityacute inpatientinstitutional only
inpatientinpatient hospicedate/npi continuityinpatient hospiceinstitutional only
inpatientinpatient psychdate/npi continuityinpatient psychiatricinstitutional only
inpatientinpatient skilled nursingdate/npi continuityskilled nursinginstitutional only
inpatientinpatient substance usedate/npi continuityinpatient substance useinstitutional only
inpatientinpatient rehabilitationdate/npi continuityinpatient rehabilitationinstitutional only

A simplified example of the algorithm is shown below. These 3 claims would be joined together into one encounter:

patient_nameclaim_idstart_dateend_datedischarge disposition codeencounter_id
john smith11/1/20201/31/2020301
john smith22/1/20202/28/2020301
john smith33/1/20203/14/2020011

These claims that overlap would also be grouped together:

patient_nameclaim_idstart_dateend_dateencounter_id
john smith11/1/20201/31/20201
john smith21/14/20201/28/20201
john smith33/1/20203/14/20202

These claims would not be joined together since the discharge code indicates the patient was discharged to home:

patient_nameclaim_idstart_dateend_datedischarge disposition codeencounter_id
john smith11/1/20201/31/2020011
john smith22/1/20202/28/2020302

Outpatient

Most outpatient encounters are formed with the combination of a patient_id, data_source, and date, with the exception being radiology, which contains only the claim lines associated with a specific imaging code. This will group together the institutional claim for the imaging event, and the professional claim with the read. This can then be used for rate analysis and compared to other sites of service (including professional locations).

ENCOUNTER_GROUPENCOUNTER_TYPEAlgorithm TypeService Category AnchorAnchor Claim Type
outpatientambulatory surgery centerdate continuityambulatory surgery centerboth prof and inst
outpatientdialysispatient/datedialysisboth prof and inst
outpatientemergency departmentdate/npi continuityemergency departmentboth prof and inst
outpatienthome healthpatient/datehome healthboth prof and inst
outpatientoutpatient hospital or clinicpatient/dateoutpatient hospital or clinicboth prof and inst
outpatientoutpatient hospicepatient/dateoutpatient hospiceboth prof and inst
outpatientoutpatient injectionspatient/datehcpc codes beginning with Jboth prof and inst
outpatientoutpatient psychpatient/dateoutpatient psychiatricboth prof and inst
outpatientoutpatient pt/ot/stpatient/dateoutpatient pt/ot/stboth prof and inst
outpatientoutpatient radiologypatient/date/hcpcoutpatient radiologyboth prof and inst
outpatientoutpatient rehabilitationpatient/dateoutpatient rehabilitationboth prof and inst
outpatientoutpatient substance usepatient/dateoutpatient substance useboth prof and inst
outpatientoutpatient surgerypatient/dateoutpatient surgeryboth prof and inst
outpatienturgent carepatient/dateurgent careboth prof and inst

Office-Based

Office-based encounters use only professional claims as the anchor. Most use the patient/date combination to form an encounter, with the exception being radiology. The reason for this is so that radiology contains only the claim lines associated with a specific imaging code, which can then be used for rate analysis and compared to other sites of service.

ENCOUNTER_GROUPENCOUNTER_TYPEAlgorithm TypeService Category AnchorAnchor Claim Type
office basedoffice visitpatient/dateoffice-based visitprofessional only
office basedoffice visit injectionspatient/datehcpc codes beginning with Jprofessional only
office basedoffice visit pt/ot/stpatient/dateoffice-based pt/ot/stprofessional only
office basedoffice visit radiologypatient/date/hcpcoffice-based radiologyprofessional only
office basedoffice visit surgerypatient/dateoffice-based surgeryprofessional only
office basedoffice visit - otherpatient/dateremaining office-based claimsprofessional only
office basedtelehealthpatient/datetelehealth visitprofessional only

Other

Ambulance, DME (durable medical equipment), and lab are typically part of a higher level encounter (such as inpatient or emergency department). If an ambulance claim occured outside the dates of the inpatient encounter it isn't joined and doesn't become associated with the encounter. In this case, an encounter is created for the orphaned ambulance claim.

Other orphaned claims are claims that don't produce an anchor event on their own, and weren't attributed to one that does. This bucket is usually small, and if it is large is an indication of a data quality issue.

ENCOUNTER_GROUPENCOUNTER_TYPEAlgorithm TypeService Category AnchorAnchor Claim Type
otherambulance - orphanedpatient/dateambulanceboth prof and inst
otherdme - orphanedpatient/datedurable medical equipmentboth prof and inst
otherlab - orphanedpatient/datelabboth prof and inst
otherorphaned claimno groupingn/aboth prof and inst

Data Dictionary

The output of the encounter grouper is the Encounter table in the Core Data Model, which we reproduce below for convenience.

ColumnData TypeDescriptionTerminology

Example SQL

Since the core.encounter table is at the encounter grain already, calculating paid per encounter is straightforward.

Encounter Summary
select
encounter_group
, encounter_type
, sum(paid_amount) as paid_amount
, count(*) as encounter_count
, sum(paid_amount) / count(*) as paid_per_encounter
from core.encounter
group by
encounter_group
, encounter_type
order by encounter_count desc

We can use the delivery type and delivery flag to analyze labor and deliveries.

Labor and Delivery
select 
delivery_type
, sum(paid_amount) as paid_amount
, count(*) as encounter_count
, sum(paid_amount) / count(*) as paid_per_encounter
from core.encounter
where delivery_flag = 1
group by
delivery_type

We will typically see observation on both inpatient and outpatient encounters.

Observation
select   
encounter_type
, sum(observation_flag)/count(*) percent_with_obs
, sum(observation_flag) total_obs_encounters
, count(*) as total_encounters
from core.encounter
where observation_flag is not null
group by
encounter_type
order by
total_encounters desc

Similarly, we can view the encounter flags across all encounters.

Encounter Flags
select   
encounter_type
, sum(observation_flag)/count(*) percent_with_obs
, sum(lab_flag)/count(*) percent_with_lab
, sum(dme_flag)/count(*) percent_with_dme
, sum(ambulance_flag)/count(*) percent_with_ambulance
, sum(pharmacy_flag)/count(*) percent_with_pharmacy
, sum(ed_flag)/count(*) percent_with_ed
, count(*) as total_encounters
from core.encounter
group by
encounter_type
order by total_encounters desc

Since encounters merge together claims that were intermittantly billed during a long stay, we can accurately calculate the length of stay for encounter types where it is applicable.

Length of Stay
select   
encounter_type
, avg(length_of_stay) as avg_los
, count(*) as encounter_count
from core.encounter
where length_of_stay is not null
group by
encounter_type
order by
encounter_count desc