Architecture
helex-tx is the standalone home for the terminology-server-facing terminology suite — the React rewrite of reference-editor, built on the Helex platform’s shared libraries.
Modules (target)
The canonical org.helex.tx.* family (names/handles/mascots also in the auto-memory tx-module-family):
| Module | Name | Handle | Package | Mascot | Scope |
|---|---|---|---|---|---|
| Editor | TEDY | tx-edit | org.helex.tx.tedy | 🧸 | terminology editor — code/value/map sets, naming systems, association types, defined properties, observation/specimen definitions, sequences; server-management (spaces, servers, ecosystems, releases); landing/search |
| eXplorer / aggregator | Teagle | tx-vision | org.helex.tx.teagle | 🦅 | multi-server terminology aggregator — server registry, multi-source $expand fan-out, editable in-memory server; built on Flint |
| FHIR API | Flint | tx-fhir | org.helex.tx.fhir | 🔥🦎 | FHIR façade + terminology $operations engine + conformance. A published library (org.helex.tx:tx-fhir) that TEDY and Teagle embed — replaces Kefhir. See dev/flint.md. |
| UCUM | Ucumber | tx-ucum | org.helex.tx.ucum | 🥒 | UCUM utility API (convert / canonicalise / analyse) over Flint’s native UCUM engine |
| Wiki | Owlexicon | tx-wiki | org.helex.tx.wiki | 🦉 | wiki (DB-authored), rendered/published |
| Publisher | Catticus | tx-pub | org.helex.tx.pub | 🐱 | Implementation Guides / publishing |
Built so far: TEDY (authoring engine + /fhir facade over Flint), Flint (tx-fhir library, general-mode
FHIR conformance 1194/1194), Teagle (aggregator on Flint), Ucumber. TEDY currently also carries basic
Structure Definition / Structure Map authoring and import until dedicated modules exist. Reused from EMR (not
rebuilt): uma (privileges), flow (tasks). info/health → shell.
TEDY currently also ships basic Structure Definition and Structure Map authoring (list · create · TxResource detail with Content view) — the modeling resources that ultimately belong to DMO; they live in TEDY until DMO is stood up.
Layers
modules/<ns>/frontend— a self-contained React 19 / Vite SPA that is BOTH a standalone app (main.tsx→App.tsx→AppRoutes.tsx) AND a Module-Federation remote (federated.tsxexposes./App). Mirrors the EMRmodules/tx/frontendblueprint.libs/<name>— domain libraries.@helex/tedy= the terminology-server client (txApi→/txapi), hooks, types, and TEDY-owned components (TedyResourceForm).- Shared
@helex/*foundation (from EMR core/frontend):@helex/ui(App* widgets +ResourceList/ResourceForm),@helex/core(auth, http,useDataController),@helex/state,@helex/i18n,@helex/mfe-setup. Consumed via source aliases today; published as packages in Phase 3 (then this repo builds standalone).
Backend
terminology-server (/ts/*, /structure-definitions, /transformation-definitions, /wiki/*, /space/*, /file-importer/*, /fhir/*). The @helex/tedy client uses a dedicated axios instance on a /txapi prefix — deliberately off @helex/core’s /api (the EMR platform backend).
TEDY’s /fhir façade + terminology $operations are served by the embedded Flint engine
(org.helex.tx:tx-fhir) over a TEDY-DB-backed ResourceStore (org.helex.tx.tedy.fhir.TedyDbResourceStore,
flint.store=tedydb), composed in via org.helex.tx.tedy.config.FhirEngineComposition and gated by
FhirAuthorizationInterceptor. The frontend’s @helex/tx widgets ($expand/$lookup) resolve against this local
/fhir when TEDY_TX_FHIR_TARGET points at the TEDY backend. See dev/flint.md.
No deployment-specific URLs are committed. The dev proxy target is set via VITE_TX_TARGET (required; neutral default), and backend FHIR canonicals (publisher value sets/code systems) via VITE_TX_PUBLISHER_{VS,CS}_URL, read through src/config/tx.ts. See modules/tedy/frontend/.env.example.
Conventions
Follow the EMR frontend contract (AGENTS-frontend.md): lists → ResourceList, detail/edit → ResourceForm (TEDY wraps it as TedyResourceForm), no raw antd / <a> / message.*, everything via t() with locale files, App*/Fhir*/Tx*/Emr* per-lib naming. Tx* widgets bind to the EMR registry backend — not reused for the reference platform /ts/* data.
Deploy (target, Phase 3)
Three modes, all present in EMR today: per-module static-nginx Dockers behind an edge nginx; a monodocker; and MFE via Module Federation (shell host mounts each remote’s remoteEntry.js).