The SNOMED International Implementation Guide for the Global Patient Set (GPS) provides practical guidance for the use of SNOMED CT concept identifiers and terms to support international interoperability of clinical information. By making all SNOMED CT concepts accessible for global use, the GPS enables consistent exchange, storage, and interpretation of SNOMED CT–encoded data across health systems, including in non-Member countries. This guide supports safe and predictable use of the GPS while clearly distinguishing it from semantic use of the full SNOMED CT terminology.

This chapter describes how the GPS may be accessed, deployed, and used in practice, while remaining within its intended scope and respecting SNOMED CT licensing requirements.

The guidance in this chapter focuses on safe, predictable, and license-compliant use of SNOMED CT identifiers and terms.

Accessing the Global Patient Set

The GPS is made available by SNOMED International for download under a Creative Commons -NoDerivatives 4.0 International Public License (CC BY-ND 4.0).

Access to the GPS:

• does not require SNOMED CT Membership

• does not require a SNOMED CT Affiliate License

The GPS is accessed via the

This distribution mechanism allows SNOMED International to:

• publish authoritative GPS releases

• notify users of updates and changes

The GPS is distributed as a standalone release artifact and may be used independently of the full SNOMED CT release.

The GPS is designed to enable global access to SNOMED CT identifiers and terms, while preserving the licensing model for SNOMED CT as a semantic terminology.

Implementers should clearly distinguish between:

• identifier-level use, which is supported by the GPS, and

• semantic or ontology-based use, which requires licensed access to the full SNOMED CT release

Using the GPS, systems may:

• receive and exchange SNOMED CT identifiers

• store SNOMED CT identifiers with associated terms

• display SNOMED CT terms for human interpretation

• validate identifiers against an authoritative list

These uses are permitted in all jurisdictions, including non-Member countries.

Any use that depends on knowledge of SNOMED CT concept semantics requires licensed access to the full SNOMED CT release.

This includes, but is not limited to:

• use of subtype (IS-A) hierarchies

• querying parent, child, or ancestor concepts

• creating subsets or value sets based on hierarchical inclusion

• subsumption testing or reasoning

These capabilities must not be implemented using the GPS alone.

When deploying the GPS, systems should treat it as a flat collection of identifiers and terms, without semantic structure.

Recommended practices include:

• treating each SNOMED CT identifier as an opaque, standalone code

• avoiding assumptions about relationships between concepts

• not inferring broader, narrower, or related meanings

• storing the GPS release version alongside stored identifiers

Where systems operate in both licensed and unlicensed environments, GPS-based functionality should be clearly separated from functionality that relies on the full SNOMED CT release.

This separation supports:

• licensing compliance

• predictable system behaviour

• clear communication of system capabilities

Operational use of the GPS should take the following into account:

Systems should track which GPS release is in use, particularly when storing data long-term.

Concepts may become inactive between GPS releases. Systems should define local policies for the display and handling of inactive identifiers.

GPS identifiers may coexist with local codes or classifications to support continuity of care and local workflows.

The GPS supports the use of SNOMED CT identifiers in situations where clinical information needs to be shared, interpreted, or retained across organisational, national, or licensing boundaries. The following use cases describe what the GPS enables, rather than how it is implemented.

Across all use cases, the GPS enables:

• Use of SNOMED CT identifiers in non-Member countries

• Consistent interpretation of shared clinical information

• Interoperability across licensing and national boundaries

The GPS supports continuity of care in global contexts by providing a common, license-safe representation of clinical information.

This use case applies when:

• Patients receive care from multiple organisations or countries

• Clinical information must remain understandable over time

• Data needs to be exchanged across heterogeneous systems

The GPS supports shared understanding of clinical information while respecting the SNOMED CT licensing model.

Clinical information recorded in a SNOMED CT Member country is shared with a healthcare provider or organisation in a non-Member country.

This use case applies when:

• A patient moves between countries

• Care is transferred from a licensed environment to an unlicensed one

• Clinical summaries or referrals are exchanged internationally

The GPS enables the receiving organisation to access and understand SNOMED CT identifiers included in the shared data without requiring a SNOMED CT license.

• Hospital discharge summaries sent to community care services abroad

• International patient summaries accompanying travellers or migrants

• Cross-border referrals for specialist care

Healthcare organisations in non-Member countries record and share clinical information using SNOMED CT identifiers provided through the GPS.

This use case applies when:

• SNOMED CT licensing is not available

• A common clinical language is needed for exchange

• Systems are being developed or modernised incrementally

The GPS allows SNOMED CT identifiers to be used for consistent representation of clinical information, even where full SNOMED CT access is not available.

• Primary care or outpatient services in low- and middle-income countries

• Community or mobile health services

• National programmes adopting international standards progressively

A healthcare organisation in a non-Member country receives clinical data encoded using SNOMED CT identifiers.

This use case applies when:

• Clinical information is received from international partners

• Patients present with records from other countries

• Emergency or humanitarian care is provided across borders

The GPS enables the receiving organisation to store, display, and interpret the identifiers safely and consistently.

• Emergency care for international patients

• Humanitarian or disaster response

• Ongoing care based on records from external health systems

Information Model Agnostic Use

The GPS is information model agnostic.

The GPS is not designed to align with any specific information model, message standard, or data context. It may be used with a wide range of information models and exchange formats, including but not limited to HL7 FHIR, CDA, openEHR, and proprietary models.

The GPS supports the use cases described in Use Cases by enabling the exchange, storage, and interpretation of SNOMED CT identifiers and terms, independent of the underlying data structure.

Limitations for Data Input and Constructive Terminology Binding

While the GPS supports interoperability across information models, its use for data input and authoring is inherently limited.

The GPS provides access to SNOMED CT identifiers and terms only. It does not provide access to concept definitions, subtype hierarchies, attribute relationships, or logical models. As a result, the GPS offers limited support for constructive terminology binding, where knowledge of concept semantics is required to guide correct data entry.

In GPS-only implementations:

• Systems cannot determine whether a selected concept is clinically appropriate for a specific data element

• Input cannot be constrained using SNOMED CT subtype hierarchies

• Terminology-driven validation of user input is not possible

• Expression-based or post-coordinated authoring is not supported

This limits the ability to provide context-aware user interfaces, semantically constrained pick lists, or terminology-driven data quality controls.

The GPS is therefore primarily intended to support:

• Exchange of SNOMED CT–encoded data

• Storage and display of SNOMED CT identifiers

• Interpretation of received clinical information

• Simple data-entry based on small value sets

Where systems require semantic guidance, constrained data entry, or terminology-driven validation, access to the full SNOMED CT release under an appropriate license is required.

Semantic Tag–Based Filtering

SNOMED International makes available a tool to filter the downloaded GPS files based on a concept's fully specified name (FSN), which allows implementers to restrict GPS content to a specific clinical domain:

https://ihtsdo.github.io/snomed-gps-extractor/

Semantic tags are derived from the FSN and can be used to:

• Include or exclude concepts based on high-level meaning (e.g. disorders, findings, substances)

• Produce domain-specific GPS subsets

• Reduce dataset size for constrained or focused implementations

Your file is processed locally in the browser and is never uploaded to any server.

1. Upload: Drag and drop the downloaded SNOMED CT GPS file (TSV format).

2. Configure:

   • Toggle "Active Concepts Only" to exclude inactive records.

   • Select the desired Semantic Tags from the categorized list.

There is also a Command-Line Interface (CLI) included in the , intended for automated and repeatable processing, such as CI/CD pipelines or scheduled dataset builds.

This is a utility tool for extracting and processing SNOMED CT terminology data from an RF2 release. It produces the SNOMED International GPS (Global Patient Set) format and offers advanced filtering capabilities via both a command-line interface (CLI) and a modern web interface.

Implementers may need to recreate the Global Patient Set (GPS) from an existing SNOMED CT Edition RF2 distribution into formats suitable for runtime use in applications, such as value sets, lookup tables, or terminology service artifacts. The snomed-gps-extractor tooling supports this process by providing a repeatable way to extract, normalize, and package GPS content from official SNOMED CT RF2 release files.

In a typical GPS implementation, the term extractor is used to:

• Produce a flat list of SNOMED CT concepts and terms without hierarchical or relational semantics

• Enable implementers to tailor GPS datasets to specific clinical or interoperability use cases

The extractor acts as a bridge between the full GPS and implementation-friendly artifacts, such as value sets or lookup tables.

The SNOMED CT GPS Term Extractor provides the following capabilities to support GPS content preparation:

• Term extraction from RF2

• Semantic tag–based filtering

• Interactive web-based processing

• Active status filtering

The extractor provides a controlled mechanism for deriving GPS-ready datasets from SNOMED CT RF2 releases by standardising how concepts and terms are selected and represented. This supports repeatable dataset generation across releases and reduces the need for custom RF2 processing logic within implementations.

The extracted output is designed to be stable and comparable over time, enabling consistent downstream use in exchange, indexing, and validation scenarios.

The extractor supports handling of concept lifecycle status, enabling implementations to:

• Include both active and inactive concepts where historical traceability is required

• Restrict outputs to active concepts only for current-state exchange and display use cases

This allows implementers to align GPS datasets with their data governance and clinical safety requirements.

The extractor produces GPS-compatible tab-separated files (TSV) designed to be:

• Easy to inspect and validate

• Simple to load into databases or terminology services

• Straightforward to transform into other representations (e.g. FHIR ValueSet resources)

The GPS term extractor does not generate:

• Concept hierarchies

• Attribute relationships

• Subsumption or inference logic

Implementations requiring full semantic reasoning or advanced terminology services should use a licensed SNOMED CT edition and a dedicated terminology server instead of GPS-derived artifacts.

Detailed operational guidance for installation, command-line usage, web interface operation, and configuration options is maintained in the GitHub repository for the SNOMED CT GPS Term Extractor. Implementers should refer to the repository documentation for the most current and authoritative instructions.

The Global Patient Set (GPS) may be used as a content source for a FHIR terminology server in environments where licensed access to the full SNOMED CT release is not available. In such configurations, the GPS supports identifier-level terminology services only and must not be treated as a substitute for a full SNOMED CT terminology server.

GPS content used by a terminology server is typically prepared in advance from SNOMED CT RF2 releases using tooling such as the SNOMED CT GPS Term Extractor, which derives a flat, GPS-compatible dataset suitable for loading into terminology services.

Supported Terminology Server Capabilities

When configured with GPS-derived content, a FHIR terminology server may support a limited set of operations that rely solely on identifiers and human-readable terms, including:

• $lookup for SNOMED CT concept identifiers

• $validate-code to confirm identifier validity and active status

• $expand for value sets uploaded by the user

Responses are limited to concept identifiers and associated term information and must not include semantic relationships, hierarchies, or inferred data.

A FHIR terminology server configured with the GPS must not support terminology services that require access to SNOMED CT semantics.

This includes, but is not limited to:

• subsumption testing

• hierarchical navigation or expansion

• $expand operations based on SNOMED CT hierarchies

• use of Expression Constraint Language (ECL)

All such capabilities require licensed access to the full SNOMED CT release.

As the primary focus of the GPS is interoperability and data exchange, the examples in this section use HL7 FHIR to illustrate how GPS content may be applied in practice. These examples are illustrative and not normative.

Receiving SNOMED CT Identifiers in a Non-Member Country

Systems in non-Member countries may receive SNOMED CT–encoded data using identifiers included in the GPS.

SNOMED CT identifiers may be exchanged using standard information models that support coded elements.

General Principles

When receiving SNOMED CT identifiers using the GPS:

• The identifier must be treated as an opaque code

• Only the identifier and associated term may be used

• No assumptions may be made about:

  • Parent or child concepts

  • Concept definitions

  • Logical relationships

SNOMED CT identifiers included in the GPS may be exchanged using standard information models that support coded data elements. In HL7 FHIR, SNOMED CT concepts are embedded within CodeableConcept data items.

A CodeableConcept may contain one or more Coding elements. When using the GPS, each Coding represents a SNOMED CT concept identifier and term, without any associated hierarchical or definitional knowledge.

In this example:

• The SNOMED CT concept is carried in the code element as a CodeableConcept

• The Coding.system identifies SNOMED CT

• The Coding.code is the SNOMED CT concept identifier included in the GPS

• The Coding.display is the preferred term provided by the GPS

When receiving SNOMED CT concepts in CodeableConcept elements using the GPS:

• Treat each Coding.code as an opaque identifier

• Use the display or text element for human-readable rendering

• Do not attempt to interpret or traverse relationships between concepts

• Do not infer broader or narrower meanings based on the code

A CodeableConcept may contain multiple Coding elements (e.g. local codes and SNOMED CT).

In such cases:

• The SNOMED CT coding may be stored and exchanged using the GPS

• Local codes may continue to be used for internal processing

• No hierarchical or logical processing of the SNOMED CT coding is permitted

The Global Patient Set (GPS) supports simple data entry activities where terminology bindings reference a predefined and relatively small set of SNOMED CT concept identifiers.

This approach is appropriate when:

• The permitted identifiers are explicitly enumerated

• No hierarchical navigation or semantic reasoning is required

• Value set membership is externally defined and governed

Search and data entry across large or open-ended value sets are limited when using the GPS. The GPS does not include:

• Hierarchical relationships

• Attribute relationships

• Ontology services

• Expression Constraint Language (ECL) support

As a result:

• Concepts cannot be browsed by hierarchy

• Subsumption testing cannot be performed

• Intensional value sets cannot be defined or evaluated

• Concept replacements cannot be automatically resolved

Where implementations require hierarchical navigation, dynamic value set expansion, semantic validation, or automated maintenance, licensed access to the full SNOMED CT release is required.

When using the GPS to support data capture:

• Value sets must be explicitly enumerated

• Ongoing maintenance of those value sets must be managed externally

• Concept inactivation and replacement must be handled manually

• Release version alignment must be monitored

Because the GPS does not provide historical associations or ontology services, implementers are responsible for ensuring that captured identifiers remain valid and appropriate across GPS releases.

Use of the GPS for capturing SNOMED CT identifiers may be feasible where:

• An external implementation guide defines fixed value sets

• Terminology bindings are stable and centrally curated

• Semantic processing beyond identifier validation is not required

In such cases, the GPS supports structured data capture and interoperability without requiring full ontology access.

Selecting a Smoker status value from an IPS Value set:

Systems using the Global Patient Set (GPS) may store SNOMED CT identifiers as part of clinical data records.

Permitted Stored Elements

When storing SNOMED CT content using the GPS, systems may store:

• SNOMED CT concept identifier

• Associated term, such as the Fully Specified Name (FSN) or Preferred Term

• GPS release version used at the time of storage

When storing SNOMED CT identifiers using the GPS:

• Each identifier must be treated as an opaque, standalone code

• Stored data must not be interpreted as part of a hierarchy

• Stored identifiers must not be used to infer:

  • Parent or child concepts

A stored diagnosis entry using the GPS may include:

This record supports data exchange and human interpretation, but does not support classification, reasoning, or analytics based on SNOMED CT logic.

Validation of SNOMED CT identifiers using the GPS is limited to syntactic and membership checks.

Using the GPS, systems may:

• Verify that a SNOMED CT concept identifier exists in the GPS

• Confirm the active or inactive status of the concept

• Verify that the identifier is consistent with a specific GPS release version

These checks support basic data quality and interoperability.

When receiving a SNOMED CT identifier:

1. Confirm that the identifier is present in the GPS release in use

2. Check whether the concept is active

3. Apply local handling rules if the concept is inactive (e.g. accept and flag)

Using the GPS, systems can't:

• Perform subsumption testing

• Determine whether one concept is more general or more specific than another

• Validate against value sets defined using SNOMED CT hierarchies

• Use Expression Constraint Language (ECL)

All such activities require licensed access to the full SNOMED CT release.

Scope of the Global Patient Set

The GPS includes all active SNOMED CT concepts from a given version of the International Edition of SNOMED CT, provided as a Free Set.

It also includes all SNOMED CT concepts that have been inactive since January 2012.

This means that, for the selected SNOMED CT International Edition version, every concept identifier is present in the GPS, regardless of domain or hierarchy.

For each SNOMED CT concept, the GPS includes:

• SNOMED CT concept identifier

• Concept status (active or inactive)

• Fully Specified Name (FSN)

• Preferred Term (US English)

This content supports the exchange, storage, and human interpretation of SNOMED CT–encoded data in any jurisdiction, including non-Member countries, without requiring access to the full SNOMED CT release.

The following examples illustrate the type of content included for individual concepts:

Each concept is included individually, without any information about how it relates to other concepts.

Although the GPS includes all SNOMED CT concepts, it does not include the semantic structures that define SNOMED CT as a terminology or ontology.

The GPS does not include:

• Subtype (IS-A) relationships

• Attribute relationships

• Logical definitions or expressions

• Concept hierarchies

As a result, the GPS must be treated as a flat collection of identifiers and terms.

Using the GPS alone, a system:

• Can store and display

  22298006 |Myocardial infarction|

• Cannot determine that:

  • Myocardial infarction is a subtype of ischemic heart disease

  • It belongs to the disorder hierarchy

All such knowledge requires licensed access to the full SNOMED CT release.

The GPS is distributed as a tab-separated values (TSV) file with a ".txt" extension, designed for independent use. Each row in the file represents a single SNOMED CT concept and includes:

• Concept identifier

• Active status flag

• Fully Specified Name (FSN)

• Preferred Term (US English)

Example File Row

In this example:

• 22298006 is the SNOMED CT concept identifier

• The FSN and Preferred Term support human interpretation

• 1 indicates that the concept is active

No additional files are required to interpret this record.

The GPS is designed for standalone use and does not require access to other SNOMED CT release files, such as:

• Relationship files

• Description files beyond FSN and PT

• History or association files

This design supports use in environments where licensed access to SNOMED CT is not available.

The GPS is released on a scheduled basis, aligned with updates to the International Edition of SNOMED CT.

Each GPS release reflects changes in the underlying SNOMED CT content, including:

• Addition of new concepts

• Inactivation of existing concepts

• Updates to terms or concept status

• A concept active in one GPS release may be marked inactive in a later release

• The concept identifier remains present, with updated status information

This supports safe long-term storage and interpretation of historical data.

SNOMED International is the authoritative source for:

• Publishing GPS releases

• Defining GPS content scope

• Maintaining alignment with the International Edition of SNOMED CT

Implementers should ensure they use GPS releases obtained directly from SNOMED International to guarantee accuracy and currency.

Background

SNOMED CT is a comprehensive clinical terminology maintained by SNOMED International and used globally to support interoperable clinical data. Access to the full SNOMED CT terminology, including its hierarchies and logical definitions, requires membership or an Affiliate License.

To support global interoperability across licensing boundaries, SNOMED International provides the Global Patient Set (GPS).

The GPS makes all SNOMED CT concepts accessible worldwide, including in non-Member countries, without compromising the SNOMED CT licensing model.

Objective

The objective of this guide is to:

• Describe the scope and purpose of the Global Patient Set

• Clarify permitted and non-permitted uses of SNOMED CT content when using the GPS

• Provide implementation guidance for receiving, storing, validating, and exchanging SNOMED CT identifiers

• Support consistent international implementation of the GPS

This guide applies to:

• Use of the GPS as a standalone, permissively licensed artifact

• Systems that exchange SNOMED CT identifiers without access to the full SNOMED CT release

• Interoperability scenarios involving Member and non-Member countries

This guide is intended for:

• National and regional health authorities

• International health programmes and organisations

• Health information system implementers and vendors

• Terminology, standards, and interoperability specialists

This guide is organised as follows:

• describes key interoperability use cases

• defines the content and structure of the GPS

• provides information model and terminology binding guidance

• describes technical implementation considerations

This guide is subject to ongoing review. Feedback from the international community is encouraged to support continuous improvement.