Glossary

A case presentation is a structured communication among health care professionals that summarizes a patient’s clinical information. Health care professionals use case presentations to share key details needed for diagnosis, care planning, and clinical decision-making. 

A case presentation typically includes identifying information, reason for care or consultation, and the patient’s chief complaint. It also summarizes relevant history, active medical problems, medications, allergies, social factors, physical exam findings, test results, clinical assessment, and treatment plan.

Clinical Decision Support (CDS) Connect is a freely available web-based platform, including an authoring tool and a repository, enabling the CDS community to identify evidence-based care, translate and codify information into an interoperable health information technology standard, and leverage tooling to promote a collaborative model of CDS development.

*Note: On April 28th, 2025, AHRQ’s CDS Connect went offline. An updated, likely final version of its authoring tool has been developed by the HL7® community as CDS Connect Community Edition. A newer set of tools, the open source CQL Studio, is an integrated web application suite for developing, testing, and publication of CQL- and FHIR-based artifacts that can be developed into computable guidelines, CDS, or dQMs, providing a functional superset of capabilities.

Clinical Decision Support (CDS) Hooks is a specification developed by Health Level Seven International® (HL7®) and managed by its CDS Work Group. It enables near real-time decision support to be integrated directly into a clinician’s electronic health record workflow.

When a specified event occurs within the clinician’s workflow, it triggers a CDS service. The service then securely retrieves the necessary data elements using HL7 Fast Healthcare Interoperability Resources® (FHIR®) services. By leveraging FHIR standards, CDS Hooks supports interoperability among stakeholders operating across different systems and platforms.

The Certified Health IT Product List (CHPL) is a comprehensive and authoritative listing of all certified health information technology that have been successfully tested and certified by the ONC Health IT Certification program. All products listed on the CHPL have been tested by an ONC-Authorized Testing Laboratory (ONC-ATL) and certified by an ONC-Authorized Certification Body (ONC-ACB) to meet criteria adopted by the Secretary of the Department of Health and Human Services (HHS). For additional information on how to navigate the CHPL, please refer to the CHPL Public User Guide.

ClinFHIR is an open-source tool providing an educational environment and also allows health information technology developers to create or search for Fast Healthcare Interoperability Resources® (FHIR®)-based resources. It serves as a training tool to help people wanting to learn more about FHIR visualize how the parts combine to represent clinical information in a structured and coded manner. It also serves as a development tool with features to build some of the required artifacts, particularly as an aid to learning.

Clinical decision support (CDS) is health information technology that helps care teams make better decisions. It provides general and patient‑specific information that the system organizes and delivers at the right time in the care process.

CDS builds on electronic health records to present clear, relevant information—such as alerts, reminders, or guidelines—that supports clinical judgment and improves care quality. 

a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; }

Common clinical decision support (CDS) alerts notify clinicians about potential issues, such as drug‑allergy, drug‑drug, and drug‑disease interactions, or provide dosing guidance. Passive CDS includes tools such as order sets, patient data reports, and documentation templates. Active CDS uses rules and alerts, which electronic health record systems deliver during workflows such as order entry.

A clinical decision support (CDS) developer is a person or organization that translates clinical knowledge into structured or executable tools that support evidence‑informed care decisions. CDS developers may not be the original authors of the knowledge or the final implementers. 

CDS developers ensure that the tools accurately reflect the source knowledge and use appropriate standards and coding systems, such as Clinical Quality Language, Current Procedural Terminology, and SNOMED CT. They also address intellectual property and licensing requirements.

Clinical decision support (CDS) implementation activities include the steps needed to configure and customize health information technology for a specific organization or group of users. 

For CDS, implementation teams align the system with local workflows, identify when and where to present CDS, map local data fields to the data used by the CDS, and train users on key features. These activities often include adapting guideline recommendations to local systems and needs (for example, translating higher‑level guidance into executable formats or local configurations) (See Levels of knowledge representation for CPG). 

Clinical Document Architecture (CDA) is a popular, flexible markup standard developed by Health Level Seven International® defining the structure of certain patient medical records, such as discharge summaries and progress notes, as a way to better exchange this information between health care providers and patients. Wallask, S. (n.d.). Clinical document architecture (CDA). TechTarget: Health IT. Retrieved March 12, 2024, from https://searchhealthit.techtarget.com/definition/Clinical-Document-Architecture-CDA

Clinical information systems "are computer systems that provide immediate access to current patient data regarding clinical notes, medication history, laboratory reports, images, and reports either directly or via data networks. They are parts of a hospital information system, which facilitates direct patient care." Islam, M. M., Poly, T. N., & Li, Y-C. J. (2018). Recent advancement of clinical information systems: Opportunities and challenges. Yearbook of Medical Informatics, 27(1), 83–90. https://www.thieme-connect.com/products/ejournals/abstract/10.1055/s-0038-1667075

Clinical practice guidelines (CPGs) are systematically developed statements to assist clinician and patient decisions about appropriate health care for specific clinical circumstances. CPGs are statements that include recommendations intended to optimize patient care. They are informed by a systematic review of evidence and an assessment of the benefits and harms of alternative care options. Committee on Standards for Developing Trustworthy Clinical Practice Guidelines. (2011). Clinical practice guidelines we can trust. Institute of Medicine. https://www.ncbi.nlm.nih.gov/books/NBK209539/pdf/Bookshelf_NBK209539.pdf  

A clinical quality measure (CQM) is a mechanism used for assessing the degree to which a clinician competently and safely delivers clinical services appropriate for the patient in an optimal time frame. CQMs are a subset of the broader category of quality measures.

CMS Measures Inventory Tool (CMIT) is the repository of record for information about CMS quality measures. CMS and its partners use the inventory to inform stakeholders, manage its measure portfolio, and guide measure development. The functions allow users to find measures quickly, compile and refine sets of related measures, identify measures across the continuum of care, and help coordinate measurement efforts across all conditions, settings, and populations.

The CMS consensus-based entity (CBE) assigns the CMS CBE identification number to a measure that has successfully gone through the CBE endorsement process. The CMS CBE Submission Tool and Repository (STAR) is the database of record of CBE-endorsed measures. 

The Medicare Improvements for Patients and Providers Act of 2008 requires the U.S. Department of Health and Human Services to work with a consensus-based entity (CBE) on performance measurement. The CMS CBE endorses quality measures through a transparent process that uses input from a range of stakeholders to support health care quality improvement. 

The CBE also brings together stakeholder groups to review the Measures Under Consideration (MUC) List as part of pre-rulemaking. In addition, it reviews CMS’s current measure portfolio and recommends updates when needed.

The CMS Data Element Library (DEL) is a central resource for data elements used in CMS assessment tools, such as questions and response options. It also includes the related health information technology standards. The DEL currently covers CMS post-acute care assessment instruments.

When a measure developer creates a new electronic clinical quality measure in the Measure Authoring Development Integrated Environment (MADiE), the system assigns a CMS eCQM ID to the measure. The CMS eCQM ID is required when submitting eCQM data to CMS.

A CMS Electronic Health Record (EHR) Certification ID is a number created by the Certified Health IT Product List (CHPL). Providers use this number when reporting to CMS. It identifies either a single certified product or a group of products used in the CHPL. This CMS EHR Certification ID is different from a CHPL product number. If the product or product combination changes, a new CMS EHR Certification ID is created. The ID reflects the product setup, not the organization. This means different providers can have the same ID if they use the same products.

CMS requires a CMS EHR Certification ID for some quality reporting programs. Check each program’s requirements to confirm when it is needed.

The Centers for Medicare and Medicaid Services Measures Under Consideration Entry/Review Information Tool (CMS MERIT) is a web-based system used by CMS to collect, manage, and review quality measures submitted for consideration in CMS quality reporting and value-based programs. The tool guides submitters through a structured process to provide required measure information. Each submitter has access to a dashboard to track the status of their submission and communicate with CMS through a built-in comment feature. CMS MERIT also provides a consolidated view of all measures submitted for the current review year. In addition, the tool supports federal officials, consensus-based entity multi-stakeholder groups, and other stakeholders by providing access to detailed measure information during the review and evaluation process.

The CMS Measures Management System (MMS) Hub is a centralized website for quality‑measure guidance, tools, and engagement opportunities across the measure lifecycle from conceptualization, specification, testing, implementation, and ongoing maintenance.

The CMS Quality Reporting Document Architecture (QRDA) Implementation Guides (IGs) are technical documents that define the standards and specifications for reporting electronic clinical quality measures (eCQMs) using Health Level Seven International® (HL7®) QRDA. The guides provide detailed instructions for healthcare providers, health information technology (IT) vendors, and reporting organizations on how to format and submit eCQM data consistently and accurately.

The CMS QRDA Category I guide covers individual patient–level reports and is used by hospitals for quality reporting programs. The CMS QRDA Category III guide covers aggregate-level reports for groups of patients and is used by eligible clinicians for quality reporting programs.

The CMS Quality Reporting Document Architecture (QRDA) Pre-Submission Validation Tools are software resources designed to help healthcare providers, health information technology (IT) vendors, and reporting organizations verify the accuracy and compliance of their electronic clinical quality measure (eCQM) submissions before formally submitting them to CMS. By acting as a pre-submission check, these tools help ensure that eCQM QRDA files meet CMS standards, reducing errors, saving time, and supporting reliable quality reporting.

CMS-supported validation tools include:

• Cypress: Ensures accurate, standardized, and compliant eCQM reporting, reducing the risk of rejected submissions and improving data quality for CMS quality reporting programs. Cypress validates both QRDA Category I (patient-level) and Category III (aggregate-level) files for compliance.
• Hospital Quality Reporting System (HQR): Checks QRDA Category I (patient-level) files for adherence to CMS standards and Health Level Seven International® (HL7®) specifications. It provides reports and guidance to help hospitals identify and correct errors prior to submission.

A code system is a managed collection of concepts with each concept represented by at least one internally unique code and a human readable description, e.g., SNOMED CT.

A comment period is the time the public has to respond to a request for input. These requests may include proposed rules, Requests for Information, or draft measures posted on the Measures Management System Hub. 

Federal law requires agencies to give the public a chance to take part in rulemaking. This requirement comes from the Administrative Procedure Act. Executive Orders 12866 and 13563 recommend a comment period of at least 60 days for rulemaking. For other types of documents, the comment period may be shorter or longer.

A composite measure is a measure containing two or more individual measures, resulting in a single measure with a single score.

A computational artifact is anything created by a human using a computer. An artifact can be, but not limited to a code, program, image, audio, video, presentation, or web page file. 

Concept maps are visual representations of information. They can take many forms, such as charts, graphic organizers, tables, flowcharts, Venn diagrams, timelines, or T-charts.

Source: The Learning Center – University of North Carolina at Chapel Hill. (n.d.). Concept maps. Retrieved March 20, 2024, from https://learningcenter.unc.edu/tips-and-tools/using-concept-maps/

The Clinical Quality Framework (CQF) is a joint effort by the Clinical Decision Support (CDS) and Clinical Quality Information Work Groups who develop standards and guidelines that allow healthcare organizations to reliably measure care quality electronically, ensuring consistency, interoperability, and actionable insights.

The Clinical Quality Framework (CQF) Ruler is a collection of plugins built for the HAPI Fast Healthcare Interoperability Resources® (FHIR®) Java Persistence API (JPA) server that brings the FHIR Clinical Reasoning Module to life. It enables healthcare organizations and developers to process electronic clinical quality measures (eCQMs), evaluate decision logic, and apply clinical rules in real time. Beyond quality measurement, the CQF Ruler acts as a central repository for knowledge artifacts, such as care guidelines and decision support rules, and serves as a clinical decision support service that can provide actionable recommendations at the point of care. By combining measure processing, knowledge management, and decision support, the CQF Ruler helps make quality reporting and evidence-based care more efficient, consistent, and interoperable across FHIR-enabled systems. 

Clinical Quality Language (CQL) is a Health Level Seven International® standard. It supports the use of shared standards for electronic clinical quality measures and clinical decision support. CQL lets users write logic that people can read and computers can process.

The Clinical Quality Language (CQL) Evaluation Engine is an open source Java-based evaluation engine capable of evaluating the result of any CQL expression. Note: this is a component in the CQL translator repository.

Clinical Quality Language (CQL) Execution Framework is the engine that runs the rules and expressions defined in CQL to evaluate electronic clinical quality measures (eCQMs), decision support logic, or other healthcare-related computations.

The Clinical Quality Language (CQL) Formatting and Usage Wiki is a collaborative, community-driven workspace dedicated to the development and sharing of CQL formatting conventions, coding patterns, and best practices. It serves as a central resource for measure developers, health information technology (IT) implementers, and clinical informaticists to standardize how CQL logic is represented within electronic clinical quality measures (eCQMs) and other clinical decision support artifacts. The Wiki provides practical guidance on writing clear, consistent, and maintainable CQL, including examples, templates, and usage recommendations, helping ensure that quality measure logic is accurately interpreted, interoperable, and easier to implement across different health IT systems.

A Clinical Quality Language (CQL) library is a container for artifact logic/expressions. A CQL library contains declarations which specify the items found in the library. Every electronic clinical quality measure (eCQM) has at least one CQL library. For more information, see the Health Level Seven International® CQL Author’s Guide.

Clinical Quality Language (CQL) Runner is an online platform for ad hoc testing of CQL.

The CQL-to-ELM Translator is an open-source reference implementation that translates the high-level Clinical Quality Language (CQL) syntax into the Expression Logical Model (ELM) representation. The reference implementation is used in support of Clinical Quality Framework implementations as a tool to enable CQL output to be uniformly and automatically translated into ELM XML or JavaScript Object Notation (JSON) documents for sharing and distribution to support implementation, integration, translation, and execution of CQL-based artifacts.

For more information or to get involved, visit the Clinical Quality Framework initiative page on the Health Level Seven International® website.

The CQMCommonQDM Library (formerly known as the Global Common Library) is a shared, standardized library of Clinical Quality Language (CQL) expressions built on the Quality Data Model (QDM).

It is used by electronic clinical quality measure (eCQM) developers to:

• Reuse common logic across multiple measures
• Promote consistency and alignment in measure specifications
• Reduce duplication of code and logic
• Improve efficiency during measure development and maintenance

Instead of each eCQM defining similar logic independently, the CQMCommonQDM Library provides centralized, reusable CQL components that can be referenced across measures.

The CQMCommonQDM Library specifications can be found within the eCQMs section in the eCQM Resources tab for the specific program (e.g., Eligible Clinician eCQMs).

A Critical Access Hospital (CAH) is a hospital that participates in a federal program established in 1997 under the Balanced Budget Act. The program supports small, rural hospitals and improves access to care for rural communities. 

CAHs are a separate provider type with their own Medicare Conditions of Participation and payment method. The Conditions of Participation are defined in 42 CFR 485, Subpart F. 

Cypress is an open-source testing platform that health information technology (IT) vendors use to certify their electronic health records (EHRs) and certified health IT modules (CEHRT) for electronic clinical quality measure (eCQM) calculations. It is an official testing tool within the Office of the National Coordinator (ONC) for Health IT Certification Program. As part of certification, Cypress generates synthetic patient data for selected published eCQMs and evaluates whether EHR systems and health IT modules can correctly capture, import, calculate, filter, and report those measures.

Cypress Validation Utility + Calculation Check (CVU+) enables real-world testing by allowing organizations to run tests using their own patient data. It supports validation against CMS Quality Reporting Document Architecture (QRDA) Implementation Guides (IGs) and performs eCQM calculations with highlighted measure logic. 

The Cypress Tech Talks are an open forum for discussing technical implementation and tool issues with the Cypress support team.