> For the complete documentation index, see [llms.txt](https://help.form.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.form.io/how/using-termhub-with-form.io.md).

# Using TermHub with Form.io

In many modern systems, patient intake data is often captured as free text, with no guarantee it aligns with the representation currently in use across systems.

For example, a patient’s gender might be stored as ‘Male’ in one system, ‘M’ in another, and ‘1’\
in a third. Each system defines and maintains its own representations for common demographic\
fields. That same data is then exchanged across internal systems and with external partners,\
even though each system stores it differently.

## The Problem

This inconsistency in data collection creates friction and overhead everywhere the data moves.

Internally, analytics and reporting systems have to interpret and reconcile those differences.

Externally, partners and exchange networks receive values that are technically valid according to the source but semantically inconsistent with the native application.

Using the gender example, every downstream system requires logic that recognizes ‘Male,’ ‘M,’\
and ‘1’ as having one single meaning. This work may be repeated at every integration point. Normalization becomes an ongoing operational burden rather than a one time fix at a single point of processing.

## The Solution

A viable solution to this problem requires incorporating internationally recognized and utilized healthcare data standards (such as HL7 value sets and SNOMED CT Concepts) as the single source of truth used to propagate that standardized date to all inputs; as the patient enters information each field is captured at the time of input as structured, standards-aligned data.

Fields such as Gender, Marital Status, Race, Ethnicity, and Language are sourced directly from [HL7](https://www.hl7.org/implement/standards/index.cfm) value sets, ensuring data consistency across different systems.

When the form is submitted, the gender value is stored as a [SNOMED CT](https://www.snomed.org/what-is-snomed-ct) Identifiers which in turn point to the concept definition rather than freeform text. As a result, data is captured using a stable identifier from the first entry into the system on submission, and remains stable on the way out. Every system now receives the same standardized concept, even if intake and downstream systems display the value differently.

FHIR based workflows can use the data immediately without downstream transformation.\
From the patient’s perspective, this is just a simple intake form. Behind the scenes though,\
complexity is removed at the source and data is ready for internal and external exchange.

## The Workflow

<figure><img src="/files/5YfSx6wgOGCbSJiLmQIL" alt=""><figcaption></figcaption></figure>

1. **The patient** fills in a simple intake form
2. A **Select Component** configured with a URL data source captures input.
3. **TermHub** provides the latest version of HL7/SNOMED coded values to the Select Component, but presents to the end user as a plain text representation of the concept.
4. The **submission** contains data adhering to international healthcare data standards enabling interoperability automatically.

## Example Value Sets

This pattern works with all available HL7 or SNOMED value sets that are available through TermHub's FHIR endpoints. The following fields are a selection of commonly used in healthcare forms:

<table><thead><tr><th width="163.8984375">Field</th><th width="248.16796875">Standard</th><th>Example Codes</th></tr></thead><tbody><tr><td>Gender</td><td>HL7 Administrative Gender</td><td><em>male, female, other, unknown</em></td></tr><tr><td>Marital Status</td><td>HL7 Marital Status</td><td><em>M, S, D, W, ...</em></td></tr><tr><td>Race</td><td>CDC Race &#x26; Ethnicity</td><td><em>2106-3, 2054-5, 2076-8, ...</em></td></tr><tr><td>Ethnicity</td><td>CDC Race &#x26; Ethnicity</td><td><em>2135-2, 2186-5, 2149-3, ...</em></td></tr><tr><td>Language</td><td>BCP-47 Language Tags</td><td><em>en-US, es-MX, fa, ...</em></td></tr></tbody></table>

## Example Implementation

To provide the form user with HL7/SNOMED component:

1. Within the Form Builder, drag a **Select Component** from the Basic Component palette to the canvas.
2. Open the Component Settings and select the **Data** tab.
3. In the **Data Source Type** menu, select **URL**.

<figure><img src="/files/WqAA7TurOigY09ML6y3e" alt="" width="375"><figcaption></figcaption></figure>

1. Provide the URL for the TermHub FHIR R4 ValueSet `$expand` endpoint.
2. Configure the component to parse the FHIR response appropriately:
   1. **Data Path** - `expansion.contains`
   2. **ID Path** - `code`
   3. **Value Property** - `display`
   4. **Item Template** - `<span> {{ item.display. }</span>`
3. Verify the data using the live preview. Ensure the correct options are populating the selectable options. The below example showcases Communication Language when searching, "En".

<figure><img src="/files/us16y2bdPGa147h6I6c1" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://help.form.io/how/using-termhub-with-form.io.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.