Galileo Encounter Reconciliation

The Galileo Encounter Reconciliation algorithm implements logic to assign a primary health care setting to rows in several tables in the Unified Model. Subsequently, derived encounters are computed from these tables to represent a real world encounter (ED visit, hospitalization, etc.) as one reconciled row using data collected from one or more data sources.

Computing Primary Care Setting

The following tables have a primarycaresetting column. This column is computed and provides a consistent representation of the caresetting concept across data types and data sources.

• claim: caresetting computed using columns: type, subtype, facilitytype; and procedures related to the claim.
• encounter: caresetting computed using columns: class, type, admitsource.
• condition: caresetting inherited from the related claim or encounter.
• procedure: caresetting computed from columns: code, revenue, location if applicable. Otherwise, inherited from the related claim or encounter.

The primarycaresetting column can have the following values. These codes are an extended set of codes that are based on the FHIR Act Encounter Code.

• IMP (Inpatient)
• OBSENC (Observation Visit)
• EMER (Emergency Department Visit)
• NONAC-SNF
• NONAC-OTH (LTC or Rehab)
• AMB-ASC (Ambulatory Surgery Center)
• AMB-UR (Urgent Care)
• AMB-HOPD (Hospital-based Outpatient)
• AMB-EM (Evaluation and Management Office Visit)
• VR (Virtual Visit)

For traceability, the adjacent primarycaresettingreason column provides the specific reason (i.e subtype in [111, 117]) that was used to compute the primarycaresetting. For entities such as claim which can span several caresettings (i.e. a claim for a hospitalization that began in the ED), the primarycaresetting is selected using a priority order and other caresettings are expressed in the secondarycaresettings column.

See also:

• Configuring the Geneva Transformer
• http://www.hl7.org/implement/standards/fhir/R4/v3/ActEncounterCode/vs.html
• https://www.cms.gov/Medicare/Medicare-General-Information/Telehealth/Telehealth-Codes

A conceptual data flow is described in the diagram below.

Computing Derived Encounters

Derived encounters are computed from claims, EHR/provider encounters, and authorizations to represent a real world visit (ED visit, hospitalization, etc.) as one reconciled row using data collected from multiple data sources.

For example, a single hospitalization may be described by several claims (commonly one facility/institutional claim and several concurrent professional service claims). It may also be described by one or more encounters (one encounter received via ADT from the hospital, also recorded as an encounter received in a CCDA from a separate provider or health information exchange).

For many use cases, it is extremely helpful to gather up-to-date awareness of events using near-realtime data sources such as ADT and authorizations. Historical patterns can be best illuminated with comprehensive data sources such as claims. Derived encounters provide a single resource to reconcile all these data sources without over counting events.

Derived encounters are useful for accurately computing up-to-date utilization metrics such as “ACSC Hospitalizations per 1000 persons per month” across multiple data sources.

Derived encounters are represented in the following tables.

• derivedencounter_ed
• derivedencounter_inpatient
• derivedencounter_nonacutebed
• derivedencounter_officevisit

The algorithm to produce reconciled derived encounters follows the following steps (this example specifically addresses hospitalizations; similar logic is used for other care settings):

1. All claims and encounters annotated with primarycaresetting = IMP are identified. Because several claims from a single claims source may describe the event, only claims designated as “derived encounter anchor claims” (which are typically facility/institutional claims) are used in subsequent steps.
2. Claims and encounters from multiple data sources are tied together to detect unique events using the personid and admitdate columns. Because data sources may use slightly different admit dates for the same event, a date window is applied to group together roughly equivalent admit dates.
3. A primary claim (if available) and a primary encounter (if available) is selected to represent the event using a prioritization algorithm.
4. Properties such as admit and discharge dates, primary diagnosis, and primary provider are assigned to the event using related properties on the primary claim and the primary encounter. If a primary encounter is available, its properties are prioritized over the primary claim.
5. The event is persisted in the derivedencounter_inpatient table.