Raidho
Retrieval-Augmented Generation ecosystem built on adaptive LLM and embedding of terminology sets from vocabulary provider backends including NIH UMLS and DICOM Concept Groups and Templates (DCMR)
Query Code
Select Code
Edit Report
Settings
Abstract
Raidho is an application system for generating clinical seed reports aligned with the HL7 FHIR Diagnostic Module, grounded by a Retrieval-Augmented Generation backend that fetches and embeds medical vocabularies from authoritative reference sources.
The primary use case is terminology and concept lookup — resolving natural language clinical terms to standard codes (ICD-10-CM, SNOMED CT, RxNorm, LOINC, CPT), exploring concept hierarchies, and augmenting LLM-generated clinical text with citable, source-attributed medical codes.
Corpus Architecture
One PostgreSQL database with two dedicated schemas: a primary raidho_substrate for NIH UMLS concepts and a secondary antenna_rag sharding DICOM DCMR code concepts and templates. Both share the same 768-dimensional vector space enabling cross-schema similarity queries.
______ ______
/ \ / \
/ \ / \
/ NIH \______/ DICOM \
\ UMLS \ DCMR /
\ \ /
\______ corpus \______/
\ /
\ /
\______/
Embedding Model
BAAI/bge-base-en-v1.5 — BERT-base encoder (Beijing Academy of AI General Embeddings), 768-dimensional output. Cosine similarity distance metric; normalize_embeddings=True so vectors are unit-length and cosine reduces to a dot product, compatible with pgvector's HNSW <=> operator. Appears as BertModel LOAD REPORT from: BAAI/bge-base-en-v1.5 in server output on first request; subsequent requests reuse the in-process singleton.
Query Latency
| Mode | Latency | Notes |
|---|---|---|
| Local Corpus, KNN only | Less than a second per term | HNSW lookup once model warm; first-request cold-start ~1–2 s on M3 Pro |
| UMLS via backend | 60–100 seconds per term | UMLS REST API called once per search hit for atoms, relations — synchronous. Best for deliberate seeding, not live search |
Backend Component Node: RAG Corpus
The user can configure the system to query the NIH UMLS directly and only - as per screens above. Alternatively, a RAG Corpus can be built up, sourced from coding scheme results passed through embedding and saved in a PostgreSQL database. The blueprint is illustrated below.
┌─────────────────────────────────────────┐
┌──────────────────────▷│ RAIDHO SUBSTRATE API │
│ └─────────────────────────────────────────┘
│ │ │ │
│ ▼ ▼ ▼
│ ┌───────────────────┐ ┌─────────────────┐ ┌───────────────┐
│ ┌──────│ UMLS Concept │ │ RAG Pipeline ├─┐ │ Refine Engine │
│ │ │ Resolver │ └─────────────────┘ │ └───────────────┘
│ ▼ └───────────────────┘ │ ▼ │
│ ┌──────────────┐ ▼ ┌─────────────────┐ │
│ │ UMLS API │ ┌──────────────────┐ │ Context Builder │ │
│ │ Client │ │ Provenance Mapper│ └─────────────────┘ │
│ └──────────────┘ └──────────────────┘ │ │
│ │ │ ▼ │
│ ▼ │ ┌──────────────────┐ │
│ ┌──────────────┐ │ │ LLM Backend │ │
│ │ NIH UMLS │ │ │ (Claude / Qwen) │ │
│ │ REST API │ ▼ └──────────────────┘ │
│ └──────────────┘ ┌──────────────────────────────────────────────┐ │
│ │ Embedding Layer │◁────┘
│ └──────────────────────────────────────────────┘
│ │
│ ▼
└──────────────────▶ ┌──────────────────────────┐
│ Session Layer │
└──────────────────────────┘
│
▼
┌──────────────────────────┐
│ Data Persistence │
│ [PostgreSQL + pgvector] │
└──────────────────────────┘
Vocabulary Coverage
| Source | Abbreviation | URI |
|---|---|---|
| SNOMED CT (US) | SNOMEDCT_US | http://snomed.info/sct |
| ICD-10-CM | ICD10CM | http://hl7.org/fhir/sid/icd-10-cm |
| LOINC | LNC | http://loinc.org |
| RxNorm | RXNORM | http://www.nlm.nih.gov/research/umls/rxnorm |
| MeSH | MSH | http://www.nlm.nih.gov/mesh |
DICOM DCMR Coverage
There was a selective chunk, ingest and embed cycle based on DICOM Standard parts PS3.3, PS3.4, PS3.5, PS3.6, and PS3.16 (DCMR). Content was parsed via BeautifulSoup from structured HTML/CHTML — not PDF. DCMR Context Groups serve as starter sets, enabling bridged queries against NIH UMLS fetched results.
Torro: Data Radiator: HL7 Generator and FHIR Receiver
The Torro Data Radiator is a medical informatics test fixture with both HL7 and FHIR workflow features, native macOS but coordinates Python nodes for the heavy lifting.
On the leading edges of the workflow, the radiator coordinates the generation of HL7 messages such as ADT, ORM, ORU, etc. - driving an external Python utility.
For the trailing edge of the workflow, coordination is done with a backend FHIR endpoint component node that can receive and save FHIR resource instances such as Diagnostic Report. The endpoint can also return resource instances when queried. The Python endpoint for the FHIR receiver is the data sink that receives report instances generated by the Raidho reporting vertical iOS mobile application.
The data flow path and steps for the trailing edge of the workflow are illustrated below. Note that the Raidhoreporting vertical mobile application could extend to source Service Requestsas products of upstream ADT and ORM/ORU messages to set Encounter contexts.
Raidho → FHIR Diagnostic Report → FHIR Receiver → Torro Data Radiator (HL7 V2.5.1 OR FHIR R4)
NOTE: The origin of the name Torro is from the Latin word for roast, toast or burn - a riff on FHIR terminology.
References
- NIH UMLS REST API — primary vocabulary service
- HL7 FHIR Diagnostics Module — report and document framework
- DICOM Standard Part 16 — Content Mapping Resource (DCMR)
- DICOM Standard — especially Parts PS3.3, PS3.4, PS3.5, PS3.6 and PS3.16
- HL7 Code System V2
- HL7 FHIR Value Set