> 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/snomed-ct-practical-guides/implementation-maturity-framework-guide/ehr-requirements-and-maturity-levels.md).

# EHR Requirements and Maturity Levels

## Introduction

This page maps each requirement from the [SNOMED CT EHR Requirements Guide](https://docs.snomed.org/snomed-ct-practical-guides/snomed-ct-ehr-requirements-guide) to a corresponding maturity level in the Implementation Maturity Framework (IMF) for Software Products.

The EHR Requirements Guide defines what a SNOMED CT-enabled EHR system should be capable of across six areas: Edition, Language and Content; User Interface; Analytics and Reporting; Maintenance; Storage; and Interoperability. The IMF for Software Products assesses how comprehensively and effectively those capabilities have been implemented, on a scale from Level 0 (None) to Level 5 (Optimising).

By aligning these two resources, this page helps:

* Vendors understand which requirements are expected at each stage of maturity, and plan a progressive implementation roadmap.
* National Release Centers (NRCs) frame procurement requirements in terms of the maturity level they wish to mandate or target, rather than applying all requirements uniformly.
* Assessors using the IMF tool to verify that a vendor's declared maturity level is substantiated by the corresponding EHR requirements being met.

Each requirement below is labelled with the IMF maturity level at which it is expected. Requirements at lower levels are foundational; they should be in place before higher-level capabilities are pursued.

{% hint style="info" %}
**Note on scope:**

The EHR Requirements Guide was designed to define a procurement baseline and naturally concentrates on foundational capabilities.

As a result, the guide's requirements map most directly to Levels 1 through 3, with some reaching into Level 4. Levels 4 and 5 are supplemented below with criteria drawn from the IMF's own descriptions of those levels for Software Products; these are marked (IMF-derived).

For a full assessment at Levels 4 and 5, refer to the [IMF for Software Products](https://www.implementation.snomed.org/imf-vendors) and the [IMF Interactive Self-Assessment Tool](https://ihtsdo.github.io/sct-implementation-demonstrator/#/maturity).
{% endhint %}

***

## Edition, Language and Content

<table><thead><tr><th width="87.11431884765625">Ref</th><th width="469.78338623046875">Requirement</th><th>Expected Level</th></tr></thead><tbody><tr><td>2.1</td><td>Incorporate SNOMED CT as the primary clinical terminology, including the international edition, national edition, and any relevant local extensions.</td><td>Level 1 - Basic</td></tr><tr><td>2.2</td><td>Update SNOMED CT within 18 months of a new version of the deployed edition being published, including all changed components and derivative artifacts.</td><td>Level 2 - Emerging</td></tr><tr><td>2.3</td><td>Implement SNOMED CT in the native language of the implementing country or organisation.</td><td>Level 1 - Basic</td></tr><tr><td>2.4</td><td>Create or source all SNOMED CT subsets and maps required by the customer, subject to an approved quality assurance process.</td><td>Level 3 - Advanced</td></tr><tr><td>2.5</td><td>Provide a feedback mechanism for submitting new or missing content, including engagement with the NRC where additional content is required.</td><td>Level 3 - Advanced</td></tr></tbody></table>

***

## User Interface

<table><thead><tr><th width="96.38641357421875">Ref</th><th width="471.38140869140625">Requirement</th><th>Expected Level</th></tr></thead><tbody><tr><td>3.1</td><td>Use SNOMED CT for searching, display, storage, communication, knowledge linkage, querying and analytics in core clinical domains (problems/diagnoses, reason for admission, procedures, allergies).</td><td>Level 1 - Basic</td></tr><tr><td>3.2</td><td>Support searching for SNOMED CT concepts using any preferred or acceptable term in the national language reference set.</td><td>Level 2 - Emerging</td></tr><tr><td>3.3</td><td>Provide configurable display options for the term shown upon concept selection (user-entered term, preferred term, or institution-specific term).</td><td>Level 2 - Emerging</td></tr><tr><td>3.4</td><td>Restrict searching and selection to concepts from the SNOMED CT subset bound to the relevant data element.</td><td>Level 2 - Emerging</td></tr><tr><td>3.5</td><td>Display the most frequently selected concepts at the top of the list, for data elements bound to a subset of more than 20 concepts.</td><td>Level 3 - Advanced</td></tr><tr><td>3.6</td><td>As the user types, filter concepts using a word-prefix, any-order algorithm; auto-complete when only one option remains.</td><td>Level 2 - Emerging</td></tr><tr><td>3.7</td><td>Display the concept with the shortest matching term first in the results list.</td><td>Level 2 - Emerging</td></tr><tr><td>3.8</td><td>Use SNOMED CT-enabled NLP to suggest possible SNOMED CT encoding from free text clinical entries, for user confirmation.</td><td>Level 4 -Integrated</td></tr><tr><td>3.9</td><td>Support capture of SNOMED CT post-coordinated expressions using predefined templates and automatically generated interface terms.</td><td>Level 4 - Integrated</td></tr><tr><td>3.10</td><td>Use SNOMED CT concept identifiers stored in the EHR to suggest patient-specific clinical knowledge and test clinical decision support rules.</td><td>Level 4 - Integrated</td></tr><tr><td>3.11</td><td>Use SNOMED CT maps to other coding systems (e.g. ICD-10) to suggest appropriate codes for clinician selection.</td><td>Level 3 - Advanced</td></tr><tr><td>3.12</td><td>Return search results within acceptable performance thresholds (e.g. less than 1 second for initial results).</td><td>Level 2 - Emerging</td></tr></tbody></table>

***

## Analytics and Reporting

<table><thead><tr><th width="97.11431884765625">Ref</th><th width="460.25921630859375">Requirement</th><th>Expected Level</th></tr></thead><tbody><tr><td>4.1</td><td>Use maps from local code systems to SNOMED CT to enable ad hoc querying, reporting and analysis of legacy clinical data.</td><td>Level 2 - Emerging</td></tr><tr><td>4.2</td><td>Use maps to national and international classifications to enable analysis and reporting, including of legacy data.</td><td>Level 3 - Advanced</td></tr><tr><td>4.3</td><td>Use SNOMED CT defining relationships in the determination of correct outcomes for data reporting, extractions and clinical decision support rules.</td><td>Level 4 - Integrated</td></tr></tbody></table>

***

## Maintenance

<table><thead><tr><th width="103.1051025390625">Ref</th><th width="463.67962646484375">Requirement</th><th>Expected Level</th></tr></thead><tbody><tr><td>5.1</td><td>Ensure the deployed SNOMED CT edition is kept within 18 months of the most current release.</td><td>Level 2 - Emerging</td></tr><tr><td>5.2</td><td>Maintain all subsets and maps used in user interfaces, reports and queries with each new version of SNOMED CT to ensure continued clinical validity.</td><td>Level 3 - Advanced</td></tr><tr><td>5.3</td><td>Where a SNOMED CT extension is required, follow SNOMED CT principles: globally unique identifiers, concept permanence, and a robust audit trail for all inactivations.</td><td>Level 5 - Optimising</td></tr></tbody></table>

***

## Storage

<table><thead><tr><th width="97.5120849609375">Ref</th><th width="478.1356201171875">Requirement</th><th>Expected Level</th></tr></thead><tbody><tr><td>6.1</td><td>Store SNOMED CT concept identifiers in the health record.</td><td>Level 1 - Basic</td></tr><tr><td>6.2</td><td>Store the SNOMED CT concept identifier (or expression) together with the term selected by the user, for each SNOMED CT coded data element.</td><td>Level 1 - Basic</td></tr><tr><td>6.3</td><td>Ensure the context of each SNOMED CT concept identifier or expression is clearly represented in the information structure or the terminology (but not both).</td><td>Level 2 - Emerging</td></tr><tr><td>6.4</td><td>Ensure that all inactivated concepts, descriptions and relationships remain available to support querying over historical clinical data.</td><td>Level 3 - Advanced</td></tr></tbody></table>

***

## Interoperability

<table><thead><tr><th width="99.436767578125">Ref</th><th width="456.727294921875">Requirement</th><th>Expected Level</th></tr></thead><tbody><tr><td>7.1</td><td>Use SNOMED CT concept identifiers and/or expressions to populate SNOMED CT coded data elements in all relevant message exchanges.</td><td>Level 2 - Emerging</td></tr><tr><td>7.2</td><td>Share data based on national and local data standards, using SNOMED CT as the common clinical language.</td><td>Level 3 - Advanced</td></tr><tr><td>7.3</td><td>Support mappings to other terminologies and classifications (e.g. ICD-10, ICPC2, LOINC, Orphanet) where available, making them accessible in relevant contexts.</td><td>Level 3 - Advanced</td></tr></tbody></table>

<br>

<a href="https://docs.google.com/forms/d/e/1FAIpQLScTmbZIf0UEQwYDkY27EEWBkaiYkHSbR0_9DmFrMLXoQLyL7Q/viewform?usp=pp_url&#x26;entry.1767247133=snomed-implementation-maturity-framework-guide&#x26;entry.670899847=EHR%20Requirements%20and%20Maturity%20Levels" class="button primary">Provide Feedback</a>


---

# 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, and the optional `goal` query parameter:

```
GET https://docs.snomed.org/snomed-ct-practical-guides/implementation-maturity-framework-guide/ehr-requirements-and-maturity-levels.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.