> 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.
Provide Feedback
---
# 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.snomed.org/implementation-guides/gps-implementation-guide/information-models-and-terminology-binding.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.