> For the complete documentation index, see [llms.txt](https://docs.snomed.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.snomed.org/implementation-guides/gps-implementation-guide/information-models-and-terminology-binding.md).

# Information Models and Terminology Binding

## 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](/implementation-guides/gps-implementation-guide/use-cases.md) 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.snomed.org/implementation-guides/gps-implementation-guide/information-models-and-terminology-binding.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.