# \`sct\` - a fast, free set of local SNOMED-CT tools **URL:** \ **Category:** Technology & Software\ **Created:** [April 4, 2026, 9:34pm UTC](https://forums.snomed.org/t/sct-a-fast-free-set-of-local-snomed-ct-tools/1129 "2026-04-04T21:34:53Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![pacharanero](https://dub1.discourse-cdn.com/flex014/user_avatar/forums.snomed.org/pacharanero/32/423_2.png) [@pacharanero](https://forums.snomed.org/u/pacharanero)\ **Post date:** [April 4, 2026, 9:34pm UTC](https://forums.snomed.org/t/sct-a-fast-free-set-of-local-snomed-ct-tools/1129/1 "2026-04-04T21:34:53Z")
Hi SNOMED forums > **[GitHub - pacharanero/sct: SNOMED-CT tooling, brought into the 21stC. RF2 -\>...](https://github.com/pacharanero/sct)** > > SNOMED-CT tooling, brought into the 21stC. RF2 -\> ND-JSON, SQLite, Vector, Parquet, LLM-friendly I’m a clinical informatician, software developer and clinician based in the UK, and although I’ve had a lot of exposure to SNOMED-CT over the years, I’ve always found the tooling for local development, exploration, and learning of SNOMED to be quite sparse. I decided to see if I could build simple SNOMED tools that use files on disk - no Java, no Docker, no REST API, just simple deterministic tooling, modern file-based formats, normal developer workflows. Here’s what I made. Feedback most welcome. ---
**Author:** ![pacharanero](https://dub1.discourse-cdn.com/flex014/user_avatar/forums.snomed.org/pacharanero/32/423_2.png) [@pacharanero](https://forums.snomed.org/u/pacharanero)\ **Post date:** [April 4, 2026, 9:35pm UTC](https://forums.snomed.org/t/sct-a-fast-free-set-of-local-snomed-ct-tools/1129/2 "2026-04-04T21:35:33Z")
Here’s a video which walks through the key features of the `sct` toolset. [![](https://europe1.discourse-cdn.com/flex014/uploads/snomed/original/1X/8feab3deb9d90b47c2a11f0e7c9f27b4be985fbd.jpeg "Introducing `sct` - fast, free, open-source SNOMED-CT tools for your CLI") ](https://www.youtube.com/watch?v=f-gz-MKtU44) ---
**Author:** ![rdavidson](https://dub1.discourse-cdn.com/flex014/user_avatar/forums.snomed.org/rdavidson/32/3_2.png) [@rdavidson](https://forums.snomed.org/u/rdavidson)\ **Post date:** [April 10, 2026, 12:10pm UTC](https://forums.snomed.org/t/sct-a-fast-free-set-of-local-snomed-ct-tools/1129/3 "2026-04-10T12:10:21Z")
Hi @pacharanero , this is really interesting, thank you for submitting this. I’ve not had a chance to set it up and have a play, but will definitely be doing so after our conference. It’s good to see other open source tools to make access to SNOMED CT more accessible, especially ones that take a different approach from others we have seen. Thanks, Rory ---
**Author:** ![pacharanero](https://dub1.discourse-cdn.com/flex014/user_avatar/forums.snomed.org/pacharanero/32/423_2.png) [@pacharanero](https://forums.snomed.org/u/pacharanero)\ **Post date:** [April 10, 2026, 12:26pm UTC](https://forums.snomed.org/t/sct-a-fast-free-set-of-local-snomed-ct-tools/1129/4 "2026-04-10T12:26:37Z")
Thanks @rdavidson - at this stage it’s been as much a learning and experimentation tool for me, but I’m trying to build it to be performant and robust, such that it could be included in my other software projects to give me fast, local-first SNOMED autocomplete, searches, etc. Please do feed back here with anything you notice such as bugs etc. And feature requests! ---
**Author:** ![pacharanero](https://dub1.discourse-cdn.com/flex014/user_avatar/forums.snomed.org/pacharanero/32/423_2.png) [@pacharanero](https://forums.snomed.org/u/pacharanero)\ **Post date:** [April 15, 2026, 7:44am UTC](https://forums.snomed.org/t/sct-a-fast-free-set-of-local-snomed-ct-tools/1129/5 "2026-04-15T07:44:56Z")
Does anyone here know if it would be acceptable for `sct` to include the IPS SNOMED-CT subset, which has been openly released under Creative Commons license? > **[The IPS Terminology | SNOMED International](https://www.snomed.org/international-patient-summary-terminology)** > > The IPS Terminology at SNOMED International I would like `sct` to have some SNOMED terms in the repo, to make it easier for new people to get started with SNOMED, without having to separately obtain a SNOMED Edition from somewhere else (eg TRUD in UK or MLDS) Is the IPS subset actually **openly** published anywhere? Having to register on the SNOMED website in order to be emailed a link to download it is not actually what the technology world considers ‘open’. ---
**Author:** ![pacharanero](https://dub1.discourse-cdn.com/flex014/user_avatar/forums.snomed.org/pacharanero/32/423_2.png) [@pacharanero](https://forums.snomed.org/u/pacharanero)\ **Post date:** [August 14, 2026, 5:49pm UTC](https://forums.snomed.org/t/sct-a-fast-free-set-of-local-snomed-ct-tools/1129/6 "2026-08-14T17:49:30Z")
Hi all - a massive and belated update on [`sct`](https://github.com/pacharanero/sct), the local-first SNOMED CT toolkit I posted in April. You can now run it on a Raspberry Pi 🤣 `sct` is now at [v0.23.1](https://github.com/pacharanero/sct/releases/tag/v0.23.1). It’s getting close to what I’d consider a reasonable 1.0 release. It will always be a free, open-source, single-binary toolchain that works from RF2 data stored locally. There is no hosted service dependency at runtime: it creates NDJSON (newline delimited JSON), SQLite, Parquet, Markdown, FST, and optional embedding artefacts on your own machine. It’s particularly useful for giving the power of SNOMED to your AI agents via CLI or MCP. I benchmarked the `sct` terminology server against a number of other termservers, and, well, it’s not _slower_, put it that way… At this stage I’m not getting into ‘mine is faster than yours’ but I did want to at least know that a file-backed system doesn’t perform _worse_ than a Java/DB stack. ## Getting hold of SNOMED CT and building local artefacts - [`sct trud`](https://pacharanero.github.io/sct/commands/trud/) can authenticate with NHS TRUD, download the UK Monolith release, verify its SHA-256 checksum, and run the build pipeline. It now supports storing the API key with `sct trud auth`, avoiding secrets in shell history and process listings. - The pipeline can carry through [inactive concepts, reference sets, and locale selection](https://pacharanero.github.io/sct/commands/trud/#pipeline) rather than forcing a separate manual build for those needs. - The canonical [`sct ndjson`](https://pacharanero.github.io/sct/commands/ndjson/) artefact now preserves release provenance, language-refset-aware preferred terms, simple and payload reference-set data, inactive concepts, and layered RF2 input correctly. - RF2 loading and NDJSON writing are now streamed. In a documented UK Monolith comparison, this reduced peak memory from 6.42 GiB to 3.73 GiB and allowed the full pipeline to complete on an 8 GB Raspberry Pi 5. The exact figures are workload and machine specific, but the [method and measurements are published](https://pacharanero.github.io/sct/benchmarks/#sct-ndjson-memory-improvement-in-v0201). - Every build records enough [provenance](https://pacharanero.github.io/sct/commands/ndjson/#output-format) to identify the source release later from SQLite-backed commands, codelists, embeddings, and MCP results. ## Local exploration, search, and hierarchy work - [`sct lookup`](https://pacharanero.github.io/sct/commands/lookup/) now validates SNOMED CT identifiers using the Verhoeff check digit, and shows inactive-concept context where the loaded data supports it. - [`sct history`](https://pacharanero.github.io/sct/commands/history/) is a new focused view for retired concepts: why a concept was inactivated and the appropriate historical-association target(s), rather than leaving users to reconstruct that story themselves. - [`sct ecl`](https://pacharanero.github.io/sct/commands/ecl/) now provides a local ECL parser and evaluator for hierarchy, refset membership, boolean operations, and attribute refinement. It can feed results straight into codelist workflows. - The optional [transitive closure table](https://pacharanero.github.io/sct/walkthrough/transitive-closure/) accelerates hierarchy-heavy work. Commands remain correct without it by falling back to recursive SQL, and explain how to build or repair it when appropriate. - [`sct size`](https://pacharanero.github.io/sct/commands/size/) estimates a concept’s hierarchy/subtree size, including when a closure table is unavailable. - [`sct diagram`](https://pacharanero.github.io/sct/commands/diagram/) (experimental) renders hierarchy and definition views, making stated relationships easier to inspect than raw RF2 rows. - [`sct fst`](https://pacharanero.github.io/sct/commands/fst/) index supports compact memory-mappable exact, prefix, typo-tolerant, and word-intersection search. - [`sct sayt`](https://pacharanero.github.io/sct/commands/sayt/) adds search-as-you-type over that FST index: as an interactive terminal UI, a line-based standard-input protocol, or an HTTP autocomplete endpoint for a web interface. - [`sct proximal-primitives`](https://pacharanero.github.io/sct/commands/proximal-primitives/) and the SDK can find a concept’s proximal primitive supertypes. ## Reference sets and reproducible codelists - [`sct refset`](https://pacharanero.github.io/sct/commands/refset/) gained `compare` and `profile` commands to show differences between reference sets and group their members by hierarchy. - `.codelist` files are now [composable](https://pacharanero.github.io/sct/commands/codelist/#composing-codelists-includes): one list can include others, with explicit exclusions and provenance retained in readable, version-controllable text. - [`sct codelist`](https://pacharanero.github.io/sct/commands/codelist/) gained an interactive concept picker, imports from CSV, OpenCodelists CSV, and FHIR ValueSets, and can export FHIR R4 ValueSets. - It can now export an active codelist as a compact, exact [ECL expression](https://pacharanero.github.io/sct/commands/codelist/#sct-codelist-export-file-format-fmt), so a selected list can round-trip between explicit concepts and a semantic rule where that is possible. - Codelist export can include [cross-terminology mappings](https://pacharanero.github.io/sct/commands/codelist/#export-with-cross-terminology-maps) for downstream reporting or migration work. - The background and rationale for treating codelists as reviewable source material is in [Why code lists?](https://pacharanero.github.io/sct/why/why-codelists/). ## Legacy coding and cross-terminology mapping - [`sct map`](https://pacharanero.github.io/sct/commands/map/) unifies mapping previously split across `transcode` and `crosswalk`: SNOMED CT can be mapped to and from ICD-10, OPCS-4, CTV3, and Read v2 when the relevant source data has been loaded. - SNOMED CT RF2 map refsets are retained natively, including map metadata and historical forwarding from inactivated concepts. - ICD-10 input accepts both dotted and undotted forms, for example `I21.9` and `I219`. - [`sct read2`](https://pacharanero.github.io/sct/commands/read2/) supports importing TRUD item 9 Read v2 material to provide the Read v2/CTV3 side of the mapping story. - [`sct dmwb`](https://pacharanero.github.io/sct/dmwb/walkthrough/) can inspect DMWB `.mdb` files and supports the FHIR translation route used by the DMWB Excel add-in. This is not a claim of completed universal DMWB import support; the documented Read v2 import gate remains deliberately explicit about its limits. ## FHIR terminology service - [`sct serve`](https://pacharanero.github.io/sct/commands/serve/) is now included in released binaries and the default source build. It runs a local, read-only FHIR R4 terminology server over a single SQLite database, without Java, Elasticsearch, or a network dependency at query time. - The server provides [`$lookup`, `$validate-code`, `$subsumes`, and `$expand`](https://pacharanero.github.io/sct/commands/serve/#operations-phase-1), including FTS5 text search, ECL, and stored codelist ValueSets. - It supports [FHIR `TerminologyCapabilities`](https://pacharanero.github.io/sct/commands/serve/#operations-phase-1), FHIR batch Bundles, and a non-FHIR low-latency [`/autocomplete`](https://pacharanero.github.io/sct/commands/serve/#search-as-you-type-endpoint) endpoint when an FST is available. - Codelists can be [served as named, read-only FHIR ValueSets](https://pacharanero.github.io/sct/commands/serve/#stored-valuesets-from-codelist-files), including composed lists, expansion, and membership validation. - [`ConceptMap/$translate`](https://pacharanero.github.io/sct/commands/serve/#cross-terminology-translation-conceptmaptranslate) exposes local SNOMED CT, ICD-10, OPCS-4, CTV3, and Read v2 mappings, including RF2 correlation-derived equivalence where available. - Recent `$expand` work adds [`activeOnly`, `includeDesignations`, `displayLanguage`, `includeDefinition`, and `check-system-version`](https://pacharanero.github.io/sct/commands/serve/#expand-and-ecl). Requests that cannot be honoured now fail explicitly rather than silently broadening an expansion. - The server uses [warm, read-only SQLite connection pooling and bounded work](https://pacharanero.github.io/sct/performance/#tuning-sct-serve), while retaining a correct recursive fallback if the optional closure table is missing. - Important scope note: this remains a Phase 1, single-edition FHIR R4 server. It has no built-in authentication, SMART support, XML, FHIR R5, or multi-version routing. The [documented deployment guidance](https://pacharanero.github.io/sct/deploy/) puts an authenticated reverse proxy in front of any non-local service. ## SDKs, AI, and integration - The public [Rust SDK](https://pacharanero.github.io/sct/sdk/rust/) gives Rust applications typed, local read-only access to lookup, search, ECL, hierarchy, refsets, mappings, codelists, and lifecycle context without shelling out to the CLI. - The [`sct-py` Python package](https://pacharanero.github.io/sct/sdk/python/) makes the same local engine available to Python users through FFI. - [`sct mcp`](https://pacharanero.github.io/sct/commands/mcp/) provides Model Context Protocol tools for local terminology lookup, hierarchy navigation, refset comparison/profile, and direct terminology mapping. Input sizes and in-flight work are bounded so an MCP client cannot make the server consume unbounded memory. - [`sct embed` and `sct semantic`](https://pacharanero.github.io/sct/walkthrough/semantic-llm/) support local embedding and semantic search workflows. All of this is experimental. Embedding artefacts now record the model and text scheme used, and queries check that they are compatible instead of pretending a mismatched model is safe. The embeddings do work, but I was surprised at actually how unhelpful they were in real life usage. ## Install, package, and deployment options - Current releases provide checksum-verified binaries for [Linux x86\_64 and ARM64, macOS Intel and Apple Silicon, and Windows x86\_64](https://pacharanero.github.io/sct/walkthrough/getting-started/#installation). - There are native [Debian/Ubuntu `.deb` and Fedora/RHEL/openSUSE `.rpm` packages](https://pacharanero.github.io/sct/walkthrough/getting-started/#installation), macOS `.dmg` downloads, a standalone Windows `.exe`, and shell/PowerShell installers. - Package-manager routes now include [crates.io, cargo-binstall, Homebrew, Scoop, and the AUR](https://pacharanero.github.io/sct/walkthrough/getting-started/#installation). The AUR package is `sct-rs-bin`. - There is a [Nix flake](https://github.com/pacharanero/sct#nix) for `nix run`, profile installation, and development shells. - The multi-architecture [`sct` container image](https://pacharanero.github.io/sct/deploy/docker-image/) is published on Docker Hub and GHCR. The deployment walkthrough covers Docker Compose with Caddy for HTTPS, optional basic auth, and CORS. - `sct` also runs under [Termux on Android](https://pacharanero.github.io/sct/android-termux/), built from source. The docs explain the static-musl DNS limitation that means this is not currently a supported Android binary target. - Shell completions can be generated and [installed from the command](https://pacharanero.github.io/sct/commands/completions/), rather than maintained as stale hand-written scripts. ## Performance, reliability, and documentation - Published [benchmarks](https://pacharanero.github.io/sct/benchmarks/) now cover a UK Monolith release on a Lenovo laptop, Raspberry Pi 5, and OnePlus 13 under Termux. The page states the measurement conditions and cautions against treating single runs as universal figures. - [`sct bench`](https://pacharanero.github.io/sct/commands/bench/) is a new user-facing self-benchmark for CLI and SDK query paths. It emits text, Markdown, JSON, or standalone HTML, and avoids putting host-identifying information into reports. - The [performance and tuning guide](https://pacharanero.github.io/sct/performance/) explains the trade-offs between cold and warm storage, transitive closure, FTS, FST, and server pool sizing. - Read-side commands now open the SQLite database read-only; commands consistently keep machine-readable data on stdout and progress/warnings on stderr; and single lookup misses exit non-zero for reliable scripting. - ECL parsing, TRUD downloads, RF2 archive handling, FHIR request handling, MCP framing, and FST loading have all had explicit resource limits and validation work. These are less glamorous than new commands, but matter for running large terminology releases safely on ordinary machines. - The documentation has expanded into a [task-focused walkthrough](https://pacharanero.github.io/sct/walkthrough/), a concise [SNOMED CT primer](https://pacharanero.github.io/sct/primer/), a [UK edition guide](https://pacharanero.github.io/sct/uk-edition-structure/), [GPS and IPS notes](https://pacharanero.github.io/sct/gps-ips/), and detailed command references. The project is licensed AGPL, and contributions, bug reports, and feedback from people who work with SNOMED CT in practice are very welcome, in fact you’re the very people who will be able to tell me what bugs are there, and what features are missing! > **[GitHub - pacharanero/sct: SNOMED-CT tooling, brought into the 21stC. RF2 →...](https://github.com/pacharanero/sct)** > > SNOMED-CT tooling, brought into the 21stC. RF2 → NDJSON → SQLite | Vector | .arrow, | .parquet | .md | refsets | .codelist | MCP | CTV3 & ReadV2 - ready