Quick answer
Match certification evidence to the exact proposed product and version, then inspect the applicable criteria, status and relied-upon software in CHPL. Keep certification evidence separate from local workflow acceptance. Published rule changes and their effective dates can change the meaning of a certification requirement during a long procurement.
Identify the exact claim
A proposal says the platform is certified. The buyer needs to know which module, version and criteria that statement describes, whether required supporting software is included and what status applies when the system will be used.
The October 2026 CHPL Public User Guide explains product listings, versions, certification criteria, status, relied-upon software and corrective-action information. Use the public listing and scoped supplier evidence together. A logo or old certificate in a proposal is not a substitute for checking the actual configuration.
Build a claim-to-evidence record
This original comparison makes the buyer's inference visible:
| Proposed claim | Evidence to capture | What remains unproven |
|---|---|---|
| “Certified EHR” | Exact CHPL listing and version | Every SNF workflow and optional module |
| “Certified API” | Specific criteria, standards and API documentation | Local app authorization and data completeness |
| “Includes required functionality” | Criteria and relied-upon software | Whether dependencies are licensed and deployed |
| “Current certification” | Status and review date | Status throughout a future contract term |
| “Ready for our program” | Applicable program's requirements for the relevant period | Eligibility from certification alone |
Record the proposed commercial SKU alongside the certified module. Ask the supplier to explain any version mismatch and provide evidence rather than assuming that a higher product number necessarily inherits every relevant certification.
Examine dependencies and exceptions
Relied-upon software may be needed for the certified function. Establish which party supplies, licenses, updates and supports it. If the proposal excludes that component, the buyer may not receive the configuration represented by the certification evidence.
Review listed nonconformities and corrective-action status in context. A historical resolved issue differs from an open issue affecting the proposed workflow. Ask for the relevant facts and disposition rather than treating the presence of any recorded issue as either automatic rejection or irrelevant history.
Real-world testing material can provide another view of supported behavior where applicable. Examine its setting, version and limitations. It does not replace the SNF's own representative acceptance cases.
Account for HTI-5's published transition
The HTI-5 final rule published October 28, 2026 removes or revises certification requirements. Its general effective date is December 28, 2026; specified instructions take effect January 1, 2027. Some transitions-of-care requirements have a later January 1, 2030 expiration. As of November 10, 2026, publication and effectiveness are different states.
For each requirement material to the purchase, record the current criterion, published future change, applicable date and contractual capability the facility needs. For example, the rule retains a functional reconciliation criterion while changing specified format references. A buyer needing a particular C-CDA exchange should contract and test that capability explicitly rather than assuming a future certification label proves it.
Similarly, changes to decision-support certification requirements do not eliminate the buyer's need to understand a predictive tool's intended population, performance and limitations. Do not promise a future regulatory result based on today's listing.
Decide certification and fit separately
A fictional proposal includes a certified clinical module, a separate analytics module and a third-party exchange component. The evaluation can find the clinical certification claim supported while still requiring additional evidence for analytics, exchange licensing and local configuration. That is a more precise result than one pass/fail badge for the entire proposal.
The final procurement record should state supported claims, unresolved scope, required dependencies and local acceptance tests. Recheck status and applicable requirements at material contract and deployment milestones. Certification can be valuable evidence when its boundaries are preserved.
Questions & answers
Does certification cover every module in a vendor’s proposal?
No. Confirm the specific listing, version, certified criteria and dependencies. An uncertified optional module does not inherit certification merely through a shared brand.
Can a removed certification criterion still be a purchasing requirement?
Yes. The buyer can specify needed functionality and evidence independently. Removal from certification does not establish that the workflow is unnecessary or already supported.
Primary sources
Use the cited source and its applicable version when making a facility-specific decision. These guides explain operational evaluation methods; they are not individualized clinical, coding, or legal advice.