Using TermHub with Form.io
Capture standards-aligned healthcare data.
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 value sets, ensuring data consistency across different systems.
When the form is submitted, the gender value is stored as a 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
The patient fills in a simple intake form
A Select Component configured with a URL data source captures input.
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.
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:
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, 2149-3, ...
Language
BCP-47 Language Tags
en-US, es-MX, fa, ...
Example Implementation
To provide the form user with HL7/SNOMED component:
Within the Form Builder, drag a Select Component from the Basic Component palette to the canvas.
Open the Component Settings and select the Data tab.
In the Data Source Type menu, select URL.

Provide the URL for the TermHub FHIR R4 ValueSet
$expandendpoint.Configure the component to parse the FHIR response appropriately:
Data Path -
expansion.containsID Path -
codeValue Property -
displayItem Template -
<span> {{ item.display. }</span>
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".

Last updated
Was this helpful?
