> 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/snomed-ct-ehr-requirements-guide/appendixes/procurement-checklist-by-maturity-level.md). # Procurement Checklist by Maturity Level ## Introduction This appendix provides a structured checklist derived from the requirements set out in this guide, reorganised according to the five maturity levels of the [SNOMED CT Implementation Maturity Framework (IMF) for Software Products](https://www.implementation.snomed.org/imf-vendors). While the main body of this guide presents requirements by category (Edition, Language and Content; User Interface; Analytics and Reporting; Maintenance; Storage; and Interoperability), this checklist reframes those same requirements through the lens of maturity. The intent is to give procurement teams and National Release Centers (NRCs) a practical tool for evaluating vendors in a progressive, stage-appropriate way. ## How to Use This Checklist Rather than applying all requirements uniformly, organisations are encouraged to: 1. **Set a target maturity level** appropriate to their national strategy, use case, or procurement context. 2. **Work through the checklist from Level 1 upward**, confirming each requirement is met before moving to the next level. Requirements at lower levels remain in force at higher levels. 3. **Use the checklist as a basis for vendor evaluation**, including request for proposal (RFP) criteria, demonstration scenarios, or contract conditions. 4. **Request evidence of compliance** for each requirement, such as product documentation, live demonstration, or third-party audit results. A corresponding mapping of all requirements to their expected maturity level is available in the [EHR Requirements and Maturity Level Mapping](https://snomed-international.gitbook.io/uat-snomed-international-docs/kdfQQ4zexrP8YsnhBh12/snomed-practical-guides/implementation-maturity-framework-guide) page of the IMF Guide. {% hint style="info" %} **Note on scope:** This guide was designed to define a procurement baseline and naturally concentrates on foundational capabilities. The requirements in this checklist map most directly to Levels 1 through 3, with some reaching into Level 4. To ensure that Levels 4 and 5 are assessed with sufficient depth and clarity, this checklist supplements the guide's requirements with additional 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 %} *** ## Level 1 - Basic *SNOMED CT is present in the system and used for core clinical data, but integration may be limited or isolated.* **Edition, Language and Content** * [ ] SNOMED CT incorporated as the primary clinical terminology, including the international edition, national edition, and relevant local extensions. * [ ] SNOMED CT implemented in the native language of the implementing country or organisation. **User Interface** * [ ] SNOMED CT used for searching, display, storage, communication and querying in core clinical domains: problems/diagnoses, reason for admission, procedures, and allergies. **Storage** * [ ] SNOMED CT concept identifiers stored in the health record. * [ ] SNOMED CT concept identifier (or expression) stored alongside the term selected by the user, for each coded data element. *** ## Level 2 - Emerging *Consistent SNOMED CT capabilities across select clinical areas. Basic update, search and interoperability standards are in place.* **Edition, Language and Content** * [ ] SNOMED CT edition updated within 12 months of a new version being published, including all changed components and derivative artifacts. **User Interface** * [ ] Search supports any preferred or acceptable term from the national language reference set. * [ ] Configurable display options available for the term shown upon concept selection (user-entered, preferred, or institution-specific term). * [ ] Searching restricted to concepts from the SNOMED CT subset bound to the relevant data element. * [ ] Search uses a word-prefix, any-order algorithm with auto-complete when one option remains. * [ ] Shortest matching term displayed first in results. * [ ] Search results returned within acceptable performance thresholds (e.g. less than 1 second). **Analytics and Reporting** * [ ] Maps from local code systems to SNOMED CT available for querying and analysis of legacy clinical data. **Maintenance** * [ ] The deployed SNOMED CT edition is no more than two versions behind the most current release, keeping all components current. For editions released on a monthly basis, the deployed version remains no more than 18 months behind the most current release. **Storage** * [ ] Context of each SNOMED CT concept or expression is clearly represented in the information structure or terminology (but not both). **Interoperability** * [ ] SNOMED CT concept identifiers and/or expressions used to populate coded data elements in all relevant message exchanges. *** ## Level 3 - Advanced *Standardised, well-maintained SNOMED CT implementation across most clinical areas. Mappings, subsets and historical data are actively managed.* **Edition, Language and Content** * [ ] All required SNOMED CT subsets and maps created or sourced, subject to a documented and approved quality assurance process. * [ ] Feedback mechanism in place for submitting new or missing content, including engagement with the NRC where additional content is required. **User Interface** * [ ] Most frequently selected concepts displayed at the top of lists for data elements bound to subsets of more than 20 concepts. * [ ] Code suggestions provided via SNOMED CT maps to other coding systems (e.g. ICD-10), for clinician review and selection. **Analytics and Reporting** * [ ] Maps to national and international classifications (e.g. ICD-10) used for analysis and statistical reporting, including of legacy data. **Maintenance** * [ ] All subsets and maps maintained with each new SNOMED CT release to ensure continued clinical validity. **Storage** * [ ] All inactivated concepts, descriptions and relationships retained and available to support querying over historical clinical data. **Interoperability** * [ ] Data sharing aligned with national and local data standards, using SNOMED CT as the common clinical language. * [ ] Mappings to external terminologies supported (e.g. ICD-10, ICPC2, LOINC, Orphanet), accessible in relevant clinical and reporting contexts. *** ## Level 4 - Integrated *Comprehensive SNOMED CT integration across clinical and administrative functions, with advanced tooling for usability, decision support and analytics.* **User Interface** * [ ] SNOMED CT-enabled NLP used to suggest possible SNOMED CT encoding from free text clinical entries, for user review and confirmation. * [ ] Post-coordinated expressions supported via predefined templates and automatically generated interface terms (e.g. for laterality, allergies, family history). * [ ] SNOMED CT concept identifiers used to surface patient-specific clinical knowledge and test clinical decision support rules. **Analytics and Reporting** * [ ] SNOMED CT defining relationships used in the logic of clinical decision support rules, data extractions and reporting queries. **Integration and Coverage** *(IMF-derived)* * [ ] SNOMED CT is implemented consistently across both clinical and administrative functions, not limited to specific departments or workflows. * [ ] Active metrics are in place to monitor SNOMED CT usability, coverage, and user adoption across the system. * [ ] SNOMED CT update processes are tracked, version-controlled, and applied consistently across all system components. *** ## Level 5 - Optimising *Continuous improvement, full automation, and active contribution to the SNOMED CT ecosystem. The vendor goes beyond compliance to drive ongoing quality and innovation.* **Maintenance** * [ ] SNOMED CT extension authoring is supported in full compliance with SNOMED CT principles: globally unique identifiers, concept permanence (no concept ID reuse), and a robust audit trail for all inactivations including replacement codes. **Automation and Continuous Improvement** *(IMF-derived)* * [ ] SNOMED CT updates are fully automated, with seamless integration and real-time notifications to relevant stakeholders when new releases are available. * [ ] Continuous evaluation mechanisms are in place to assess SNOMED CT integration quality and drive ongoing improvements, informed by real-time user feedback. * [ ] AI-driven features actively improve SNOMED CT usability and encoding quality based on accumulated usage data and feedback. **Ecosystem Contribution** *(IMF-derived)* * [ ] Content gaps and quality issues identified within the system are systematically reported back to the NRC or SNOMED International, contributing to broader terminology improvement. *** ### Related Resources * [Implementation Maturity Framework for Software Products](https://www.implementation.snomed.org/imf-vendors) * [IMF Interactive Self-Assessment Tool](https://ihtsdo.github.io/sct-implementation-demonstrator/#/maturity) * [SNOMED CT Implementation Maturity Framework Guide](https://snomed-international.gitbook.io/uat-snomed-international-docs/kdfQQ4zexrP8YsnhBh12/snomed-practical-guides/implementation-maturity-framework-guide) --- # 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/snomed-ct-ehr-requirements-guide/appendixes/procurement-checklist-by-maturity-level.md?ask=&goal= ``` `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.