Skip to main content

3. Claims Preprocessing

View Code on GitHub

Claims preprocessing is the step that makes claims data analytically usable before the Core Data Model is built. In practice, it is very difficult to do meaningful claims analytics without this preprocessing layer.

The Claims Preprocessing layer handles four foundational tasks:

  • Service categories: Assign every claim and claim line to a service category that represents the type of service and care setting.
  • Encounter grouping: Group claims into encounters (visits). An encounter means a distinct visit in a distinct care setting (for example acute inpatient, emergency department, skilled nursing facility, and office visits). Most encounters are made up of multiple claims, so grouping is required to analyze utilization and outcomes at the visit level.
  • Member months: Calculate member months so population-normalized metrics can be produced (for example spend per 1,000 members per month or ED visits per 1,000 members). Tuva expands finite and open eligibility spans only through the calendar month containing the date portion of tuva_last_run; future runs add later covered months when coverage remains active.
  • Provider attribution: When enabled, attribute members to providers for panel management, quality measurement, cost measurement, and other claims-based attribution workflows.

Binary Flag Contract​

Public binary _flag fields in Claims Preprocessing are integers. Their value domain is 1, 0, or null: 1 means true or present, 0 means false or absent, and null means unknown or not applicable. A derived field may require a non-null value when its logic fully determines the result; its field description states that narrower contract. This makes flags directly usable in filters and aggregations without warehouse-specific Boolean handling.

This public model-field contract also applies to the Input Layer, Normalized Layer, Core Data Model, and standalone package outputs. Internal working flags and Data Asset or terminology seed attributes are outside its scope.

These outputs are produced ahead of the Core Data Model and are used throughout the rest of the platform.