> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corti.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# FHIR & Snowstorm comparison

> How Corti's /predict filter maps to FHIR ValueSets and Snowstorm ECL

If you already know FHIR ValueSets or Snowstorm ECL, the tables below map the concepts you are familiar with to Corti's filter model. For the full filter documentation, see [Code filtering](/coding/code-filtering).

## Comparison with FHIR

The `filters` field on `/predict` restricts which codes the model may return. It implements a subset of FHIR ValueSet `compose` semantics as inline, ephemeral constraints: you pass the constraint in the request body, and the model returns only codes that satisfy it. No stored ValueSet resource is needed.

| FHIR R4 `ValueSet.compose` | Corti `filters` | Notes |
| - | - | - |
| `include` (1..\*) | `include` (ConditionGroup, optional) | FHIR requires at least one include; Corti treats omitted include as "all codes eligible" |
| `exclude` (0..\*) | `exclude` (ConditionGroup, optional) | Same semantics: subtract from include set |
| `include.filter.property` | `condition.property` | Direct mapping |
| `include.filter.op` (`FilterOperator`) | `condition.op` | Corti supports a subset: `=`, `is-a`, `descendent-of`, `exists`, `in` |
| `include.filter.value` | `condition.value` | Same: a code, boolean, or list depending on op |
| All filters in an include must be true | `match: "all"` | ANDs conditions within a group |
| (no FHIR equivalent) | `match: "any"` | Corti extension for OR logic across conditions |
| `include.concept` (enumerated code list) | code-string shorthand or `op: "in"` | Simpler for the common case |
| `ValueSet.url` (stored, versioned resource) | inline in request body | Ephemeral: no persistence, no expansion operation |
| `$expand` operation | automatic on every `/predict` call | The model returns only codes it can predict from the clinical text, already filtered |

## Comparison with Snowstorm ECL

Common Snowstorm ECL patterns and their Corti equivalents:

| Snowstorm ECL | Corti filter |
| - | - |
| `<< 73211009` (Diabetes mellitus and descendants) | `{ "filters": [{ "system_id": "snomedctint", "include": { "conditions": [{ "property": "code", "op": "is-a", "value": "73211009" }] } }] }` |
| `<< 73211009 MINUS 73211009` (descendants only) | include `is-a` + exclude `=` |
| `*` (all codes) | omit `filters` entirely |

## Where Corti extends FHIR

* `match: "any"` for OR within a single include or exclude (FHIR only ANDs within one include)
* Nested groups up to depth 3 for mixed AND/OR logic

## Where Corti is narrower

* No ECL (Expression Constraint Language): use JSON conditions instead
* No stored ValueSets, refsets, or map-based expansion
* No `regex` operator
* Properties are limited to the loaded coding system's code model fields (not arbitrary FHIR concept properties)

## Using Corti and Snowstorm together

Corti predicts codes from unstructured clinical text (which Snowstorm cannot do), and Snowstorm can validate or expand those codes as a post-step. A typical pipeline runs Corti first, then Snowstorm to validate the predictions against a full terminology server.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.