Setup and Inventory
Write down what is actually running before any test is executed. Compatibility gets an integration into testing. Evidence gets it through go-live.
- Fill the setup tab first. Every test result below is only valid for the version and environment recorded here.
- Test compatible and proven as separate claims. A vendor listing your PMS is not a test result.
- Mark a test Pass only when you can point to evidence another reviewer can inspect: a screenshot, a log entry, a record ID, or a ticket.
- A verbal vendor confirmation is not test evidence.
- Anything you cannot test in this environment belongs in the failure log with an owner, not in the pass column.
- Run the failure cases before the happy path. Failures are what the demo did not show you.
Practice and test reference
System, version and environment
Environment match check
A test result carries over to go-live only when the test environment matches the live one. Record each difference.
Test ran on the exact version that will be live.
Cloud, on-site, or mixed setup matches.
Custom fields and provider setup match.
Record count and load are representative.
User roles and write rights match.
Integration version and configuration match.
Questions to ask the vendor before testing starts
| Question | Answer received | Vendor response on record |
|---|
Security and Access
Acceptance should cover the technical control plane, not only data movement. Record authentication, permissions, auditability, and PHI exposure boundaries.
Authentication and connection
Permissions and access scope
Audit, logs, and PHI exposure
Security review status
- Who or what authenticates to the PMS and with what permissions?
- Can the practice independently inspect logs, audit actions, and access changes?
- Does the production configuration expose any avoidable PHI or overly broad write rights?
- Has someone explicitly approved the access model used for go-live?
Source-of-Truth and Read/Write Matrix
For every data type, document which system owns it, which direction it should move, what you expected to happen, what actually happened, and what evidence proves it.
| Data type | Owning system | Direction | Expected behavior | Observed behavior | Evidence status | Conflict rule as tested | Version tested | Evidence reference |
|---|
Fields not in scope
Test Log
Eight test groups. Mark Pass only where evidence exists. Record the location or environment tested so another reviewer can verify the result without rerunning the test.
Failure log
Every failure needs an owner, a next action, a due date, and a retest result before go-live is discussed.
| Failure type | Status | Severity | Owner | Next action | Due date | Evidence / ticket | Retest required? | Retest result |
|---|
- Testing the happy path only, then discovering cancellations and retries in week three of live use
- Accepting a demo on a clean database as proof against a live database with years of records
- Treating a silent write failure as a pass because no error appeared
- Testing in a sandbox that does not carry your custom fields or permissions
- Leaving edge-of-system failures unassigned because two vendors are involved
- Signing off before anyone confirms who gets the alert at 7 a.m. on a Monday
PMS-Specific Appendix
The general frame does not capture how each system handles versions, permissions, custom fields, or connection limits. Record those here per system and per version.
| System | Version tested | Integration build | Last tested date | Environment tested | Supported workflow / data type | Direction verified | Known limitation | Retest trigger | Evidence reference |
|---|
Multi-site rollout
A result proven at one location does not automatically carry to another running a different version, deployment, permission set, or customisation profile.
| Location | PMS and version | Deployment | Customisations that differ | Permissions that differ | Rollout wave | Retest needed | Evidence inherited? | Why inheritance is valid | Owner |
|---|
Go/No-Go Acceptance Gate
Every section rolls up into one decision. Treat it as a gate, not a suggestion.
Gate criteria
Required criteria must be met. Mark a criterion Not applicable only when the related workflow is formally out of scope and the exclusion is documented.
Acceptance decision
Record the decision, the owner, and the date it was made. Approved for go-live should only be used when required criteria are met, required tests are not failed or blocked, no blocker failures remain open, and security review is complete.
Where this connects
Each test group maps to the part of the platform it exercises. Open these when a test needs context or a failure needs a route to someone who can fix it.
Want a second set of eyes on this before go-live?
Bring your completed sheet to a structured integration-readiness review and we will walk the failures, the ownership gaps, the exclusions, and the retest list with you.
