> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.emtelligent.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.emtelligent.com/_mcp/server.

# Overview of Relations Table Schemas

## JSON Data Model

Before working with the NLP API relations, it is helpful to have an understanding of the data model of the NLP API JSON result format. In the NLP API JSON output, you will find a `relations` object. The following excerpt shows an empty `relations` object generated by a processing request where no feature relations were selected:

```json
{
   "documents": [
      {
         "relations": {
            "measurements": [],
            "medications": [],
            "experiencers": [],
            "qualifiers": [],
            "temporalities": [],
            "anatomicsites": [],
            "followups": [],
            "reportedevents": [],
            "imagelinks": [],
         }
      }
   ]
}
```

Note the following:

* Each relation type (e.g. experiencer, or follow-up relations) is represented by a child attribute which is an array containing relation-specific objects.
* The JSON example above has empty arrays because it was generated by processing request where no feature relations were selected. Typically, however, patient records will contain many instances of experiencer relations. For example, the `experiencers` array will contain many instances of experiencer relations when the `experiencer-relation` feature is enabled during document processing.
* The data model of relation objects varies depending on the feature relation type. For more information, refer to the specific documentation for the feature relation of interest.

## Relation Tables Overview

> The **relation** table represents the relation between instances of extracted relations, their types, and the document from which they were extracted. The following ER diagram shows the data schema of relations tables.

![Relation between primary relation table and type-specific relations](/_fern-img/68eb71d2ef430fabc5bc2c1f84b36d36e5ee5aa807e1b6b46aca6f9f3ed96cbd.webp)

In the table above, notice the following:

* Each type of relation is stored in its own table.
* The **relation** table is related to child tables, each representing a specific relation type. The reference is a boolean condition on the **relation_id** and the **type\_** column. The **relation_id** references the primary key in a child table as specified by the value in the **type\_** column. For example, when the **type\_** value is `followup`, the **relation_id** is the primary key in the **followuprelation** table.
* The **type\_** column stores one of the following labels: `experiencer`, `measurement`, `medication`, `qualifier`, `anatomic-site`, `temporality`, `follow-up`, `imagelink`, and `reportedevent`.
* The **document_id** is a foreign key reference to the **document** table, see [Document-level Tables](/nlp/database/schema/core/document-tables).

### Query: List feature relations types

To find what types of relations and how many instances are present in your data set, simply query the **relation** table, and group by the **type\_**.

```sql
SELECT type_ AS relation_type, count(*) AS count
  FROM relation
 GROUP BY type_
 ORDER BY count DESC;
```

| relation_type | count |
| ------------- | ----- |
| experiencer   | 7034  |
| qualifier     | 2373  |
| temporality   | 1003  |
| anatomic-site | 984   |
| measurement   | 602   |
| medication    | 348   |
| imagelink     | 77    |
| follow-up     | 46    |
| reportedevent | 9     |