First, make 'integration' name a mechanism
The word can be accurate and still tell you almost nothing. One product may receive resident demographics and orders in real time from a named dispensing system. Another may accept a spreadsheet. A third may perform one conversion during onboarding. A fourth may be 'HL7 ready' while still needing a partner before any live connection exists. Those mechanisms carry different costs, timelines, risks, and daily work.
Start the scorecard with named public evidence, then test the account-specific gap. Vendor silence is not a 'no,' and category-level language is not proof that your pharmacy, facility, systems, and data will work on day one.
The sources for this guide are official vendor pages. They are useful for establishing what each vendor publicly describes, but they are not independent implementation evidence and do not prove that a named connection is live for a buyer's account. Treat the pages as the start of the question set, then preserve what the vendor demonstrates and confirms in writing.
Draw the data boundary before anyone opens the demo
Sketch the proposed flow on one page: source system, target system, data objects, direction, update cadence, and owner. Mark every point where a person exports, uploads, maps, reviews, corrects, or re-enters information. A manual step is not automatically unacceptable, but it should be visible because it changes staffing, timing, error handling, and the meaning of an integration claim.
Then name the source of truth for each field. If a resident identifier, medication order, allergy, document, or status differs between systems, which value wins and who investigates? Ask how rejected and duplicate records appear, whether later corrections update prior reports, and how the team knows a feed has stopped. These are workflow questions, not assumptions about any product in the source list.
Use seven fields that a logo wall cannot answer
Send the questions before the meeting and ask the vendor to answer them for the versions and account in scope. A generic architecture slide may be useful context, but it cannot replace a demonstration of the buyer's proposed route, responsibilities, and exceptions.
- Which named version of our pharmacy, eMAR, EHR, HIE, or lab system is connected today?
- Which records and fields move: demographics, ADT, medication orders, lab values, allergies, documents, or something else?
- Is the flow one way or two way, and which system is the source of truth when values disagree?
- How quickly does it update, and what happens when an interface fails or returns incomplete data?
- Is this a live supported connection, a one-time conversion, an import/export, an API, or a future partnership?
- Who pays for implementation, testing, mapping, maintenance, and changes to the source system?
- Can we see the exact connection in a sandbox or reference environment before we sign?
Run the resident, break the flow, inspect the evidence
Use a representative synthetic resident and follow the data from its source into review, recommendation, facility report, follow-up, and archive. Then break the happy path: change an order, transfer the resident, introduce a duplicate, or correct a note. Inspect the queue, error message, audit history, report, and export. A logo slide cannot show any of that.
Record the result in four states: live and demonstrated; available with scoped work; not available; or still to confirm. Attach the observed system version, date, and evidence. That gives the buying team something testable and prevents one broad marketing word from deciding the scorecard.
Keep one artifact from the exercise when permission and data handling allow: a completed test sheet, vendor response, scoped diagram, or sample output. Reconcile it with the proposal and contract language for implementation, testing, support, changes, fees, and exit. A successful demonstration shows observed behavior on that date; it does not guarantee production performance or expand the written scope.