Describe an observable problem
“The system is frustrating” is a starting point, not a requirement. Name a specific failure: a booking needs re-entry, a follow-up task has no owner, a payment record is hard to reconcile or a report cannot answer a recurring operating question.
Map the steps, systems and roles involved. Then describe the result you need to see. For example: a test inquiry can become a booking without duplicate entry, with a visible owner for follow-up. Use anonymous or synthetic scenarios; a sales demonstration does not need patient-identifying information.
HealthIT.gov recommends defining organizational needs and goals before selecting or upgrading health IT. Its selection guidance is a useful starting point. The comparison structure below is a NuWays planning framework.
Give each vendor the same demonstration brief
Ask each team to demonstrate a common set of tasks. A polished tour of features can leave the difficult handoffs unexplored. Write down what was shown, what was described but not demonstrated, and what needs confirmation.
- Inquiry to booking: assign a follow-up, make an appointment and identify the information that carries forward.
- Booking to visit: review the team’s preparation, documentation and role-specific access questions.
- Visit to payment: examine the requested payment workflow and the way transactions are recorded.
- Payment to follow-up: show how the next action is assigned and how completed work is visible.
- Monthly review: reproduce a report your practice actually uses and trace its definitions.
Separate must-have capabilities from preferences. A requirement is more useful when it has an observable pass condition than when it is a broad label such as “good reporting.”
Compare the whole change
| Decision area | Evidence to request | Question for your team |
|---|---|---|
| Workflow fit | Demonstration of your required tasks. | Which workarounds remain? |
| Integrations | Specific supported connections and data behavior. | What remains manual, and who owns it? |
| Data migration | Scope, responsibilities and validation process. | What history must remain accessible? |
| Implementation | Training, configuration and support plan. | Who has time to lead the transition? |
| Contract & exit | Written fees, renewal, export and termination terms. | What obligations need qualified review? |
Plan how the transition will be checked
Identify the information that must move, the information that must remain accessible and who is responsible for each step. Ask what the vendor will do, what the practice must do and how discrepancies will be resolved.
Plan a validation process using representative test cases before relying on the new workflow. Agree on how the team will confirm access, reporting and key handoffs. Keep the transition responsibilities visible rather than treating migration as a single checkbox labeled “included.”
The Health IT Playbook includes EHR selection, workflow and data-migration resources. Its migration guidance emphasizes planning for continued access to historical information. A vendor’s general migration claim still needs to be evaluated for your particular data and contract.
Keep the process-only option in the comparison
Document what could improve through configuration, training or clearer ownership in the current setup. Comparing a software change with doing nothing can hide a practical third option: fixing the process without replacing the system.
If a change remains worthwhile to investigate, record the expected improvement, open questions and next evidence needed. Do not turn a promising demo into a commitment before the full workflow and transition questions have been answered.
Bring one clear brief to every demo.
The worksheet organizes workflows, requirements, integrations and migration questions.