Build one synthetic resident and hold the scenario steady
Create synthetic data for a resident with a facility transfer, medication change, psychotropic follow-up question, pharmacist recommendation, prescriber response, and facility report. Do not use real protected health information. Give the resident stable identifiers and dates so the buying team can distinguish product behavior from mistakes in the test packet.
Provide the same source files and desired outputs to every vendor. Product-specific explanation is useful, but the core test should not disappear into a generic presentation or a different scenario chosen for each product. If the vendor proposes an alternate route, record it beside—not instead of—the shared path.
Name the starting conditions: system versions, modules, integrations, configuration, user roles, and any data prepared before the meeting. A smooth result in a vendor-controlled environment may still be informative, but the team should know what work happened off screen.
Write the expected evidence before the presenter arrives
For each step, define the action, expected output, permitted user, exception, and artifact the team wants to inspect. This prevents a persuasive tour from changing the test halfway through and makes unanswered questions easier to carry into commercial review.
- Input: which file, field, message, or manual entry starts the step.
- Action: what the pharmacist or another authorized user must do.
- Expected state: what should be visible when the step succeeds or remains open.
- Exception: the duplicate, missing value, late response, correction, or access limit to introduce.
- Evidence: the screen, report, history, log, or export the team will inspect.
- Owner: who configures, monitors, corrects, and supports the step in production.
Observe the whole route, including the work between screens
Watch data intake, identity matching, review navigation, prior history, recommendation creation, response tracking, report generation, correction, covering-user access, and export. Include a missing value and a duplicate to expose exception handling. Record every re-entry, download, upload, private note, and vendor intervention needed to keep the scenario moving.
Ask who configures and supports each step and whether an integration is live, a conversion, an import, an API, or future work. Technical possibility, a vendor roadmap, scoped implementation, and a supported production connection are different buying facts.
Pause after the pharmacist sends the recommendation. Can a permitted user see the route and date without assuming verified receipt? Can the response remain distinct from implementation? Can a covering pharmacist find what is still open? Those handoffs reveal more than the speed of the happy path.
Break the scenario in five ordinary ways
These are not claims that every product must handle an exception in the same way. They are repeatable prompts that expose ownership, traceability, and the amount of work a polished demonstration can hide.
- Identity: introduce a possible duplicate or mismatched facility assignment and inspect the resolution path.
- Timing: deliver one source late and check whether completion states preserve the limitation.
- Correction: amend a released note or report and inspect the original, corrected output, author, and date.
- Response: supply a partial answer with rationale and leave a follow-up question open.
- Coverage: have a second authorized pharmacist resume the work without a private handoff from the first.
Score evidence with four states and one citation
Use demonstrated; available with scoped work; unavailable; and still to confirm. For each result, add the observed version and date, a note about what happened, the next owner, the commercial consequence, and the evidence supplied. A claim without a screen, artifact, or written answer can remain pending without being scored as absent.
Reconcile the results with the proposal and contract. If the test relied on a module, interface, service, custom mapping, or vendor action, confirm whether it is included, who pays, who accepts the work, and what happens when a connected system changes.
Use the test to narrow uncertainty, not declare a universal winner
A successful demonstration shows behavior in the observed environment on that date. It does not prove production performance, security, compliance, clinical quality, or a complete implementation. Keep separate diligence for contracts, privacy and security, references, data conversion, support, and total cost.
Do not turn the script into a universal product ranking. Weight the evidence against the practice's own requirements and capacity. The useful result is a shortlist with fewer hidden assumptions and a clear record of what still needs confirmation.