SNOMED CT and the NucLex niche

Definition and scope

SNOMED CT (Systematized Nomenclature of Medicine, Clinical Terms) is a clinical terminology maintained by SNOMED International, a not-for-profit association owned by its member countries. It is distributed as a set of release files that encode several hundred thousand active concepts, the human-readable terms attached to them, and the logical relationships that connect them. It is used to record findings, disorders, procedures, body structures, substances, products, and many other kinds of clinical content in electronic health records, and it is the terminology that the NucLex discussion chose, from its first minutes, as the foundation to build on rather than to replace (discussion record, section 1).

This monograph has three jobs. The first is to explain what SNOMED CT is made of, in enough detail that a reader can understand what "reuse" and "extension" mean concretely. The second is to describe the proposed NucLex scope within SNOMED CT: radiopharmaceuticals, radionuclides, nuclear medicine procedures, and theranostic treatments, with reuse preferred over creation. The third is to be honest about boundaries. NucLex publishes explanatory prose about terminology; it does not yet hold a SNOMED CT extension, a namespace, or a terminology server, and the official authoring rules that would govern an extension were not worked through in the originating discussion. They must be verified separately against SNOMED International's current documentation before any concept is authored.

Throughout, identifiers of the form NX-L-nnn are local teaching identifiers invented for this page. They are not SNOMED CT identifiers and they do not claim to correspond to any.

Key distinctions

Four distinctions carry most of the weight in what follows.

Concept, description, relationship. SNOMED CT's logical model has three component types (SNOMED International, Starter Guide, chapter 5). A concept is a unit of clinical meaning with a numeric identifier. A description is a term, in a particular language, attached to a concept; every concept has one fully specified name and at least one synonym per language. A relationship is a directed link from a source concept to a destination concept via a relationship type, itself a concept. "Lutetium-177" the term, the concept it names, and the statement that the concept is a kind of radioactive isotope are three different things, held in three different files.

Terminology and ontology. SNOMED CT is often called an ontology because its relationships are formal and a reasoner can compute the hierarchy from them. It is more cautious to say that it is a terminology with an ontological backbone expressed in a Description logic fragment. Schulz, Cornet, and Spackman (2011) analyze how far its ontological commitment extends and where it is inconsistent. The Controlled vocabularies monograph develops the general distinction; here it matters because "reuse a SNOMED CT concept" means reusing both its identifier and its logical definition, and the latter may not say what a reader assumes.

International edition, national edition, extension. SNOMED International publishes the International Edition. A member country may publish a national edition that bundles the International Edition with its own extension (the United States Edition is distributed by the National Library of Medicine). Any organization with a namespace can author an extension that depends on an edition. NucLex, if it ever authors content, would be an extension, not an edition.

Source terminology and explanatory prose. The strings that SNOMED International releases are the source terminology. What NucLex writes about them, including this page, is explanation. The two must never be confused, and in particular an explanation of a concept on NucLex must never be presented as if it were the concept's definition in the release.

Historical development

SNOMED CT has a long lineage. The Systematized Nomenclature of Pathology (SNOP) was published by the College of American Pathologists in 1965 and grew into SNOMED, a multiaxial nomenclature in which a clinical statement was assembled from codes in separate axes such as topography, morphology, and etiology (Spackman, Campbell, and Côté 1997 summarize this history). In the late 1990s the College developed SNOMED RT (Reference Terminology), which introduced a description logic foundation so that concepts could be defined by their relationships and classified by machine rather than placed in a hierarchy by hand.

SNOMED CT was formed by merging SNOMED RT with the United Kingdom's Clinical Terms Version 3 (the Read Codes), a project described by Stearns and colleagues (2001). The first release of the merged terminology appeared in 2002. In 2007 ownership transferred to the International Health Terminology Standards Development Organisation (IHTSDO), which later adopted the trading name SNOMED International. The release format changed from Release Format 1 to Release Format 2 (RF2), which is the format described below, and the stated definitions of concepts migrated from a simple relationship file into an OWL (Web Ontology Language) axiom reference set, which allows richer definitions than the earlier relationship-only form (Bodenreider, Cornet, and Vreeman 2018 review these developments).

Two papers from the same era frame the design problems that SNOMED CT inherited. Cimino's desiderata (1998) set out properties a controlled medical vocabulary should have: concept orientation, concept permanence, nonsemantic identifiers, polyhierarchy, formal definitions, and explicit version management among them. Rector (1999) asked why clinical terminology is so hard and answered with the tension between what clinicians say, what a formal model can express, and what an implementer can maintain. Both papers are useful tests for any proposed NucLex content: if a proposal violates one of the desiderata, the proposer should know why.

Philosophical or technical account

Components and their fields

Every SNOMED CT component is a row in a tab-separated release file with a common set of leading fields: an identifier, an effective time, an active flag, and a module identifier. The effective time and active flag together give SNOMED CT its versioning discipline. A component is never deleted; it is inactivated by a later row with the same identifier and the active flag set to zero. The module identifier says which module, and therefore which edition or extension, is responsible for the row.

A concept row adds a definition status, which records whether the concept is primitive (its stated definition is necessary but not sufficient to recognize instances) or sufficiently defined (the stated definition is also sufficient, so that a reasoner may classify other concepts under it). A description row adds the concept it belongs to, a language code, a type (fully specified name, synonym, or text definition), the term itself, and a case significance flag. Whether a synonym is preferred or acceptable in a given dialect is recorded separately, in a language reference set, rather than on the description. A relationship row adds a source concept, a destination concept, a relationship type, and a relationship group number that binds attributes together (for example a method and the site that method is applied to).

Stated and inferred

Since the move to OWL axioms, the stated form of a concept's definition lives in the OWL axiom reference set, and the relationship file in the release holds the inferred form produced by running a description logic classifier over the stated axioms. The distinction matters to anyone who wants to reuse a concept with understanding. The inferred hierarchy is the one a browser shows; the stated axioms are what an author wrote. An extension that adds concepts has to supply stated definitions that classify correctly against the dependent edition, which is why authoring is not simply "adding a term."

Here is a synthetic illustration of what a stated definition looks like, in words rather than release format. Suppose a local teaching concept NX-L-101, "Radioligand therapy using a lutetium-177 labelled agent (teaching example)," were defined as: a kind of therapeutic procedure; with method, administration; with direct substance, a lutetium-177 labelled radiopharmaceutical. The three attribute roles (method, direct substance, and the parent relationship) are the kind of thing the concept model provides. The precise attribute names permitted on a procedure, the ranges they accept, and whether a given combination is allowed are set out in the SNOMED CT Editorial Guide and the machine-readable concept model reference set, and they must be checked there. Nothing on this page should be read as stating what the current concept model permits.

Reference sets, expressions, and querying

Reference sets are the general mechanism for grouping components: value sets for a form, language preferences, mappings to other code systems, and the concept model itself are all reference sets. Expressions extend the terminology at the point of use. The SNOMED CT compositional grammar lets a system record a postcoordinated expression that combines existing concepts with attributes without authoring a new concept. The Expression Constraint Language (ECL) lets a system query the hierarchy, for example to retrieve all descendants of a concept that have a given attribute value (SNOMED International, ECL specification). ECL is the usual way a value set over SNOMED CT is defined in a FHIR ValueSet, a connection taken up in the FHIR terminology resources monograph.

Release files and versions

RF2 releases come in three types. A Full release contains every row ever published, with every effective time. A Snapshot contains, for each component, only the most recent row as of the release date. A Delta contains only rows changed since the previous release. The International Edition is published on a regular schedule; a national edition is published on its own schedule and declares the International Edition version it depends on. A consumer who writes down "SNOMED CT" without the edition and release date has not identified which terminology they used. The Identifier concept page and the Controlled vocabularies monograph both return to this point: an identifier is only stable relative to a named release.

Extensions and namespaces

An extension is a module, or set of modules, published by an organization that holds a namespace identifier issued by SNOMED International. Component identifiers created in the extension embed the namespace, so that they cannot collide with identifiers from the International Edition or from another extension. The Extensions Practical Guide describes the responsibilities that come with a namespace: dependency on a declared edition version, maintenance when the dependent edition changes, and conformance to the editorial and technical rules. A terminology server such as Snowstorm, the open source server SNOMED International maintains, loads an edition and any extension as separate code systems with declared dependencies and exposes them through SNOMED-specific and FHIR interfaces (Snowstorm repository). The Terminology server concept page describes what such a server does in general.

Biomedical relevance

Why does any of this matter beyond informatics? Because the choice to reuse rather than recreate has consequences that show up in patient records and research datasets.

When two institutions both record a procedure with the same SNOMED CT concept from the same edition, a query over either dataset means the same thing. When one institution records a local code and the other records SNOMED CT, someone must build and maintain a mapping, and that mapping has a quality that must be stated, as the Semantic interoperability monograph argues. When a new concept is authored in an extension for something that already exists in the International Edition, the duplicate silently splits the data. The reuse check that the discussion record (section 6) places among the quality gates for any NucLex governance process exists to prevent exactly that.

The reverse failure also exists. A concept that is reused because its label looks right, without reading its stated definition and its position in the hierarchy, may carry a meaning narrower or broader than intended. A "procedure" concept may be defined with a method that excludes the intended use; a "substance" concept may be distinct from the "product" concept a clinician actually administered. SNOMED CT keeps substances and pharmaceutical products in separate top-level hierarchies precisely because a chemical entity and a medicinal product are different kinds of thing (Starter Guide, chapter on hierarchies). Reuse means reusing the right kind.

Nuclear medicine relevance

Consider the concrete question that the NucLex discussion started from (discussion record, sections 1 to 3): how should a record describe the administration of a radioligand therapy so that the radionuclide, the targeting agent, the product given, and the procedure performed are each identifiable and each connected to the others?

Here is a synthetic worked example. Everything in it is invented for teaching, the identifiers are local, and no claim is made that any of these concepts exists or is modeled this way in a SNOMED CT release.

A department wants to record that a patient received a therapeutic administration of a lutetium-177 labelled prostate-specific membrane antigen (PSMA) targeting radioligand. At least four distinct things are in play:

Teaching ID	Kind of thing	What it names	Where SNOMED CT would place it
NX-L-201	Substance	The radionuclide lutetium-177 as a chemical and physical entity	Substance hierarchy
NX-L-202	Substance	The radiolabelled ligand as a chemical entity	Substance hierarchy
NX-L-203	Pharmaceutical or biologic product	The medicinal product containing that substance, as something that can be prescribed and administered	Product hierarchy
NX-L-204	Procedure	The administration of that product as a therapeutic act, with method and route	Procedure hierarchy

Synthetic example: a teaching decomposition of one radioligand administration into four candidate concepts of different kinds.

The reuse check runs in this order. First, does a concept for the radionuclide already exist in the dependent edition? Radionuclides are substances and the International Edition contains many; the department should search the Substance hierarchy before proposing NX-L-201. Second, does the radiolabelled ligand exist as a substance? For an agent that has been through regulatory approval in a member country, a national edition may already have added it; for an investigational agent it likely does not exist anywhere. Third, does a product concept exist? Product content in SNOMED CT is modeled with attributes that connect the product to its active ingredient substance, and national editions often extend it with their own medicinal product content, so the answer depends on which edition the department depends on. Fourth, does a procedure concept exist for administration of this class of agent? A general concept for radionuclide therapy may exist while a specific one for this agent does not, in which case the question becomes whether a postcoordinated expression combining the general procedure with the specific substance serves the record better than a new precoordinated concept.

Only after those four questions are answered does authoring begin, and authoring begins with a stated definition, not with a label. For NX-L-204 the author would have to decide the parent (a therapeutic procedure of some kind), the method, the route, and which substance or product attribute carries the agent, and would have to check each decision against the Editorial Guide's rules for the Procedure hierarchy. The guide, not this page, is the authority.

Two further points come from the discussion record. The seed scope named in the Requirements Master (section 2) was radiopharmaceuticals, radionuclides, nuclear medicine procedures, and theranostic treatments. Each is a different SNOMED CT hierarchy with its own concept model, which means a nuclear medicine extension would need authors who understand four concept models, not one. And the discussion was explicit that SNOMED CT is one source among several (section 3): chemical identity would be anchored in PubChem or the FDA Global Substance Registration System, protein targets in UniProt, observations in LOINC. A SNOMED CT extension would hold the clinical concepts and point outward to those authorities for the rest; it would not try to be a chemistry database.

Disagreements and limitations

The authoring rules were not established in the originating discussion. Babak asked, twice, how SNOMED CT creates new concepts and what its authoring principles are (discussion record, section 5). The recovered answer described a NucLex governance process and did not supply SNOMED International's actual rules. This monograph has described the general shape of authoring (stated definitions, concept model, namespace, dependency) from the public documentation, but it has not verified the specific rules that would govern any particular concept. That verification is a separate task with its own evidence record, and until it is done, no NucLex page may state that a given concept "would be modeled" in a given way.

NucLex holds no extension, namespace, or terminology server. The discussion proposed Snowstorm, a namespace, RF2 distribution via the US Edition, and FHIR endpoints (section 2). None of these exists at the time of writing. Every reference on this page to what an extension "would" do is a description of SNOMED International's published mechanisms, not of a NucLex capability.

Licensing is territorial and must be checked. SNOMED CT is licensed under the SNOMED International affiliate license. Use within a member country is covered by that country's membership; use elsewhere, and any redistribution of SNOMED CT content, is governed by the license terms. The discussion record notes Babak's statement that licensing was "not a problem" for a United States nonprofit; that is a reasonable expectation, not a legal determination, and the distinction the opening proposal drew between public and licensed endpoints (section 1) exists because of this.

SNOMED CT's ontological commitment is uneven. Schulz, Cornet, and Spackman (2011) and the broader description logic literature (Baader and colleagues 2007) make clear that a terminology built incrementally over decades contains primitive concepts, modeling patterns that changed over time, and areas where the formal definition and the intended clinical meaning diverge. Reuse therefore requires reading definitions, not matching labels.

Precoordination versus postcoordination is a live editorial choice. Whether a specific radioligand administration deserves its own concept or should be expressed by combining existing ones is not settled by the logical model. It depends on how the record will be queried, what the dependent edition already provides, and what the authoring body can maintain. Reasonable terminologists disagree, and the answer may differ between an investigational agent and an approved one.

This page is explanatory prose. It explains SNOMED CT; it is not SNOMED CT. A reader who needs the definition of a concept must consult a release of the terminology, with its edition and date, through a licensed browser or server.

Related entries

• SNOMED CT: the lexicon entry, for a short orientation and relationships.
• Concept, Identifier, and Controlled vocabulary: the general building blocks this page assumes.
• Terminology server: what a server such as Snowstorm does, in general terms.
• FHIR terminology resources: how SNOMED CT content is exposed and mapped through FHIR CodeSystem, ValueSet, and ConceptMap.
• Controlled vocabularies: the distinction between a code list, a terminology, and an ontology.
• Description logics: the formal basis of stated and inferred definitions.
• Radiopharmaceutical and Radiopharmaceutical identity: the substance, product, and administered object distinctions the worked example depends on.
• Semantic interoperability: why mapping quality, not identifier presence, decides whether meaning survives exchange.

References

1. SNOMED International. SNOMED CT Starter Guide. https://docs.snomed.org/snomed-ct-practical-guides/snomed-ct-starter-guide. Supports: the three-component logical model, hierarchies, reference sets, and the general description of editions and extensions.
2. SNOMED International. SNOMED CT logical model. In: SNOMED CT Starter Guide, chapter 5. https://docs.snomed.org/snomed-ct-practical-guides/snomed-ct-starter-guide/5-snomed-ct-logical-model. Supports: concept, description, and relationship definitions.
3. SNOMED International. SNOMED CT Editorial Guide. Available through https://docs.snomed.org/. Supports: the existence of hierarchy-specific authoring rules and attribute constraints. Not yet consulted for any specific rule; see the review gate.
4. SNOMED International. SNOMED CT Release File Specification. Available through https://docs.snomed.org/. Supports: RF2 file structure, common fields, and Full, Snapshot, and Delta release types.
5. SNOMED International. SNOMED CT Extensions Practical Guide. Available through https://docs.snomed.org/. Supports: namespaces, modules, dependency, and extension maintenance responsibilities.
6. SNOMED International. SNOMED CT Expression Constraint Language specification. Available through https://docs.snomed.org/. Supports: ECL as a query language over the hierarchy.
7. SNOMED International. Snowstorm terminology server. https://github.com/IHTSDO/snowstorm. Supports: the existence of an open source server exposing SNOMED-specific and FHIR interfaces.
8. National Library of Medicine. SNOMED CT United States Edition. https://www.nlm.nih.gov/healthit/snomedct/. Supports: the US Edition as a national edition distributed by NLM.
9. Spackman KA, Campbell KE, Côté RA. SNOMED RT: a reference terminology for health care. Proceedings of the AMIA Annual Fall Symposium. 1997:640-644. Supports: the SNOP to SNOMED to SNOMED RT lineage and the description logic foundation.
10. Stearns MQ, Price C, Spackman KA, Wang AY. SNOMED clinical terms: overview of the development process and project status. Proceedings of the AMIA Symposium. 2001:662-666. Supports: the merger of SNOMED RT and Clinical Terms Version 3.
11. Cimino JJ. Desiderata for controlled medical vocabularies in the twenty-first century. Methods of Information in Medicine. 1998;37(4-5):394-403. Supports: the desiderata used as tests for proposed content.
12. Rector AL. Clinical terminology: why is it so hard? Methods of Information in Medicine. 1999;38(4-5):239-252. Supports: the tension between clinical language, formal models, and maintenance.
13. Schulz S, Cornet R, Spackman K. Consolidating SNOMED CT's ontological commitment. Applied Ontology. 2011;6(1):1-11. Supports: the claim that SNOMED CT's ontological commitment is uneven.
14. Bodenreider O, Cornet R, Vreeman DJ. Recent developments in clinical terminologies: SNOMED CT, LOINC, and RxNorm. Yearbook of Medical Informatics. 2018;27(1):129-139. Supports: the move of stated definitions to OWL axioms and the general state of the terminology.
15. Baader F, Calvanese D, McGuinness DL, Nardi D, Patel-Schneider PF, eds. The Description Logic Handbook: Theory, Implementation and Applications. 2nd ed. Cambridge University Press; 2007. Supports: background on classification, primitive and defined concepts.
16. HL7. Using SNOMED CT with FHIR. FHIR R5. https://www.hl7.org/fhir/R5/snomedct.html. Supports: the connection between SNOMED CT editions and FHIR terminology resources. Consulted for orientation.