Bring a small, consistent test pack
Prepare fictitious HCFs, several collection events, a duplicate upload, a receipt difference and one rejected submission. Ask the supplier to show each item through the relevant workflow. Use anonymized or sample records so a demonstration does not disclose patient, employee or customer information. Score observed behavior rather than promises about future releases.
Test offline work and permissions
Disconnect a collection device, capture sample events, reconnect it and inspect the resulting server records. Check whether staff can see pending and failed uploads. Test what happens if the device clock is wrong. Ask a restricted user to edit a closed record, export data and reprint a label. The system should apply the permissions you agreed and record authorized changes.
Examine integration and exit options
Ask for the applicable integration specification, onboarding requirements and a demonstration of acknowledgement handling. Separate successful transmission from acceptance by the receiving system. Request an export containing identifiers, event history and attachments where relevant. Ask how you would retrieve data at contract end and how much assistance costs.
Compare the whole operating cost
Include implementation, migration, devices, printing, connectivity, training, renewals, support and future changes. Record which party owns each dependency. Seek written acceptance criteria and response arrangements before committing. This site is published by e-Planet, developer of CBWTF SmartCare; the checklist is an evaluation aid, not an independent vendor ranking.
Worked example: accept a pilot on evidence
Fictional training scenario. A team evaluates a supplier using four agreed tests. Two pass, one is blocked and one has not been tested. The pilot is not ready for acceptance merely because the successful demonstrations looked convincing.
| Scenario | Observed evidence | Review outcome |
|---|---|---|
| Offline capture | Five sample events reconnect as five distinct server events | Pass |
| Uncertain submission | Only a sent flag shown; acceptance cannot be established | Blocked |
| Permission control | Restricted edit denied; authorized correction retains history | Pass |
| Export and restoration | Export demonstrated; restoration not demonstrated | Not tested |
Agree the decision rule before testing
Identify which scenarios must pass for your planned rollout and what evidence demonstrates success. Avoid deciding these thresholds after seeing the supplier’s result. Mark each scenario Pass, Fail, Blocked or Not tested, and describe why. A feature claimed in a proposal is not the same as a demonstrated test result.
A Fail is an observed mismatch with the acceptance criterion. Blocked means an unavailable dependency or missing evidence prevents a decision. Not tested means the scenario has not been run. These distinctions help assign the next action without treating unknowns as successes.
Keep the retest attached to the original result
Record the tested version, environment, sample inputs, observed behavior and evidence references. For each issue, assign a responsible person and an agreed retest date. After a fix, retain the earlier result and the new evidence so the acceptance decision has a history.
In this example, the submission and restoration tests require follow-up before the team can sign off if they are must-pass scenarios. An overall percentage would hide that decision. The worksheet therefore uses evidence and explicit outcomes rather than a weighted vendor ranking.
Separate product interest from evaluation
e-Planet publishes this toolkit and develops CBWTF SmartCare. You can explore the product and request a demonstration on cbwtf.in. Apply the same test pack to any supplier you consider, including us.
Take this to your team review
A working prompt, not a compliance score. Selections last only while this page is open.
Have a correction or a question about this workflow? Contact the publisher.