How to Check an Integration Claim Before the Demo

“Yes, we integrate with your PMS” is the beginning of a buying conversation, not the answer. The word integration can describe an approved business relationship, a one-way export, a document attachment, or a structured two-way workflow. A practice owner needs to learn which one the vendor means before the contract is signed.

This checklist gives every vendor the same test. It does not rank products. It turns a broad claim into evidence your team can inspect.

1. Check the PMS source first

Start with the partner or integration directory published by your PMS. Record the page, the label used for the vendor, and the date you checked it.

Do not assume every label means the same thing. A September 6, 2026 DentalTechHub review found that PMS partner language served at least three purposes: an authorization or review relationship, a billing or support arrangement, or a general partner list whose label did not describe a validation standard. ¹

The directory can establish that a relationship is listed. It usually cannot establish how much data moves, which workflows are supported, whether the connection is reliable, or whether it fits your practice.

Absence needs the same care. In that snapshot, only 3 of 14 PMS systems published a separate negative-status category. On the other 11 pages, absence was not negative evidence by itself. ²

2. Replace “integrates” with four specific questions

Ask the vendor to answer these in writing:

1. What can the product read? Name the exact records and fields.
2. What can it write? Name the destination fields, notes, documents, or tasks.
3. When does data move? Is it real time, scheduled, or manually triggered?
4. What still requires staff work? Include review, correction, exception handling, and duplicate entry.

A partner-page listing does not answer these questions. Open Dental’s published relationship groups, for example, establish a status group but do not establish workflow coverage, data depth, implementation quality, price, or practice fit for every listing. ³

3. Make the vendor show one complete workflow

Choose a common task before the demo. A useful test has a clear start, finish, and system of record.

For insurance verification, the test might begin with a scheduled patient and end with required benefit fields stored in the PMS. For a phone agent, it might begin with a missed call and end with a correct appointment plus a staff handoff. For payments, it might begin with a balance and end with the payment posted to the correct ledger.

During the demo, ask the vendor to use a sandbox or de-identified record and show:

• where the source data begins;
• each automated and human step;
• the exact PMS screen where the result lands;
• what happens when information is missing;
• how staff see and resolve an error;
• what the audit trail records.

Do not accept a slide that says “seamless.” Ask for the screen, field, and failure path.

4. Put exceptions into the test

The normal path is only half the integration. Add at least three exceptions that your staff handles today:

• a missing or outdated record;
• a task that needs a person;
• a duplicate or conflicting value;
• a payer, provider, or appointment type outside the usual pattern;
• an upstream service that does not respond.

An anonymized DentalTechHub advisory engagement used explicit work buckets, ownership, and escalation rules for insurance verification. The value was not only identifying what software could do. The practice also decided who owned incomplete results and when work moved to a payer call or manual review. ⁴

Use the same principle for any integration: every exception needs an owner, a time limit, and a place where its status can be seen.

5. Save a verification record

Before signing, save a short record with:

Item	What to capture
PMS evidence	Directory URL, published label, and check date
Vendor evidence	Written field and workflow description
Demonstration	Date, people present, and workflow tested
Data movement	Read fields, write fields, timing, and system of record
Exceptions	Failure cases tested and responsible role
Limits	Tasks that remain manual or unsupported
Recheck date	When the claim should be verified again

This record protects the practice from memory drift between the demo, implementation, and renewal. It also gives the implementation team a concrete acceptance test.

A simple pass or hold rule

Move forward when the vendor can show the required workflow in your PMS, document the supported data movement, and explain exception ownership.

Hold the decision when the evidence stops at a logo, partner label, presentation, or verbal assurance. A hold is not a rejection. It means the integration claim has not yet been specific enough to verify.

Read what PMS partner labels actually mean and how Open Dental publishes integration relationships for two examples of why the label is only the first check.

Frequently asked questions

Does “authorized” mean the integration works well?

Not by itself. It can establish a defined relationship or process. Ask separately about fields, workflows, reliability, implementation, and support.

Is a vendor missing from a PMS list incompatible?

Not necessarily. The meaning of absence depends on the PMS page and its publication rules. Ask both companies and verify the workflow directly.

Should we test with real patient information?

Use a vendor sandbox or properly de-identified test record unless your organization has approved a secure production test. Do not put patient information into an unapproved demonstration environment.

How often should we recheck an integration claim?

Recheck before signing, before implementation acceptance, and before renewal. Also recheck when either vendor changes its API, partner status, or supported workflow.

Sources and methodology

1. DentalTechHub classification of PMS partner-page labels, checked September 6, 2026
2. DentalTechHub review of negative-status publication across 14 PMS systems, checked September 6, 2026
3. DentalTechHub review of what the Open Dental relationship page does and does not establish
4. DentalTechHub de-identified advisory verification protocol

Try Mola →