Using TermHub with Form.io

Capture standards-aligned healthcare data.

In many modern systems, patient intake data is often captured as free text that must be interpreted later.

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 defining a single source of truth and propagating that to all data 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 value sets, ensuring data consistency across different systems. When the form is submitted, the gender value is stored as a SNOMED CT concept 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 downstreams 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

1. The patient fills in a simple intake form

2. A Select Component configured with a URL data source captures input.

3. TermHub provides HL7/SNOMED coded values as options in the Select Component.

4. The submission contains standardized data.

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.

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.

Available Value Sets

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

Field	Standard	Example Codes
Gender	HL7 Administrative Gender	male, female, other, unknown
Marital Status	HL7 Marital Status	M, S, D, W
Race	CDC Race & Ethnicity	2106-3, 2054-5, 2076-8
Ethnicity	CDC Race & Ethnicity	2135-2, 2186-5
Language	BCP-47 Language Tags	en-US, es-MX, fa