Test EHR-integrated referral management the way you would test any clinical interface: with written entry and exit criteria, synthetic data only, a traceability matrix from requirement to test to evidence, and acceptance tests that each name their expected artifact. Demonstrations prove the happy path. Acceptance testing proves the exception paths, the write-backs, and the recovery behavior you will actually live with.
Quick answer
A go-live-ready test plan has five parts: entry and exit criteria, a non-production environment with safe synthetic data, a traceability matrix, a catalog of acceptance tests covering both interfaces and exceptions, and a no-go scorecard signed by named owners. Nothing advances on a verbal confirmation — every test closes with an artifact: a screenshot, an interface log excerpt, a stored message, or a report row.
This article is the execution companion to what to know about EHR referral software, which covers architecture and evaluation. Workflow stages and ownership are mapped in prior auth and referral workflows. Nothing here is legal advice, and no test in this plan should ever use real patient data or live credentials.
Definition — acceptance test: a scripted scenario with defined preconditions, steps, an expected result, and a named evidence artifact, executed by the accountable business or technical owner rather than the vendor.
Entry criteria
- Signed scope with the field-level workflow map: every read, every write, method by method.
- Interface inventory: FHIR endpoints, HL7 v2 message types, document exchange paths, secure fax fallback.
- Non-production environment refreshed and reachable, with named test accounts per role.
- Synthetic patient, coverage, provider, and payer test sets loaded and reviewed.
- Metric definitions published: denominators, exclusions, attribution windows.
- Test owners assigned per catalog section, with a defect triage path and severity definitions.
- Rollback and contingency plan documented and approved.
Exit criteria
- 100% of severity-1 and severity-2 tests passed, with evidence stored.
- No open severity-1 or severity-2 defects; severity-3 defects have owners and dates.
- Interface logs demonstrate retry and recovery for each channel.
- Security, audit, and role tests passed and signed by security and compliance.
- Analytics reconciliation within an agreed tolerance against source counts.
- Downtime and recovery rehearsal completed.
- Go-live scorecard signed by clinical, operations, IT, integration, security, and analytics owners.
Test environment and safe synthetic data
Use a non-production EHR environment and vendor sandbox. Generate synthetic patients with deliberately awkward properties: hyphenated and single-character names, duplicate name-and-date-of-birth pairs, mid-period coverage changes, dual coverage, terminated coverage, missing phone numbers, non-English language preference, and out-of-area addresses. Include synthetic providers with subspecialty variation, closed panels, and stale attested availability.
Rules: no production PHI copied down, no real credentials in scripts or tickets, no real payer endpoints, no live outbound patient messaging or fax numbers, and secrets held in a managed store rather than in test artifacts. Document the data-generation method so results are reproducible.
Traceability matrix
| Requirement area | Tests | Evidence type | Owner |
|---|---|---|---|
| Referral creation | T1–T2 | EHR screenshot + stored order payload | Clinical operations |
| Patient and coverage data | T3–T4 | Eligibility response log | Revenue cycle |
| Network verification and matching | T5–T7 | Ranked-options screenshot + factor log | Network operations |
| Authorization | T8–T10 | Request/response with reference number | Prior auth lead |
| Document exchange | T11–T12 | Stored document + receipt acknowledgement | Integration |
| Status and write-back | T13–T14 | EHR field screenshot + interface log | Integration |
| Outreach and scheduling | T15–T16 | Outreach log + confirmed appointment record | Referral coordination |
| Result return | T17–T18 | Matched result in chart + acknowledgement | Integration + clinical |
| Exceptions and retry | T19–T20 | Queue record + retry log | Operations + IT |
| Security and audit | T21–T22 | Permission denial log + audit export | Security |
| Resilience and performance | T23 | Recovery log + timing report | IT |
| Analytics and accessibility | T24 | Reconciliation report + accessibility findings | Analytics + UX |
Acceptance test catalog
| # | Test | Expected result and evidence |
|---|---|---|
| T1 | Create a referral in the EHR for a standard specialty | Referral appears in the platform within the agreed interval with specialty, diagnosis, urgency, and ordering provider intact; screenshot plus stored payload |
| T2 | Create an urgent referral | Urgency preserved and prioritized in the work queue; queue screenshot showing precedence |
| T3 | Verify active coverage on the date of service | Payer, product, member ID, and effective dates returned and displayed; eligibility response log |
| T4 | Verify terminated or mid-period-changed coverage | Referral routed to coverage-resolution queue, not advanced; queue record with reason |
| T5 | Confirm network status for a candidate destination for the specific product | In-network status shown at the point of selection with source and vintage; screenshot |
| T6 | Generate ranked destination options | Options ranked with visible factors including clinical fit, network, access, geography, and language; factor log |
| T7 | Override the recommendation and record patient preference | Override accepted in one step with structured reason stored; audit entry |
| T8 | Discover authorization requirement for a code, product, and place of service | Requirement determination with documentation list, or explicit ambiguity routed to a human; screenshot and log |
| T9 | Submit an authorization request with assembled documents | Complete submission with tracking reference; request/response artifact |
| T10 | Receive approval, pend, and denial responses | Each state parsed correctly with reason codes and approved scope; three stored responses |
| T11 | Send a clinical document package to a destination | Package delivered with receipt acknowledgement; transmission log |
| T12 | Receive an inbound referral document and extract fields | Extracted fields presented for confirmation, never silently accepted; before/after screenshot |
| T13 | Write referral status back to the EHR | Status visible in the agreed EHR field within the agreed interval; EHR screenshot plus interface log |
| T14 | Write authorization reference and appointment back to the EHR | Both present in the named fields; screenshot plus log |
| T15 | Execute a patient outreach sequence across channels | Attempts logged with channel, timestamp, and outcome; outreach log |
| T16 | Confirm an appointment inside the approved date range | Appointment recorded as confirmed with evidence, and rejected if outside the authorization window; two records |
| T17 | Return a consult note from an organization on a different EHR | Result matched to the originating referral and filed; matched result in chart |
| T18 | Acknowledge the result and close the referral | Loop marked closed with acknowledging user and timestamp; audit entry |
| T19 | Simulate a downstream interface failure | Message queued and retried per policy, no silent loss, alert raised; retry log and alert record |
| T20 | Simulate an unmatched inbound result | Item lands in an exception queue with owner, clock, and terminal state; queue record |
| T21 | Attempt access outside role permissions | Access denied and logged for each role tested; permission denial log |
| T22 | Export the audit trail for one referral end to end | Complete record of actions, users, timestamps, versions, and overrides; audit export |
| T23 | Planned downtime and recovery rehearsal, plus peak-volume timing | Queues drain in order with no duplication; response times within agreed thresholds; recovery log and timing report |
| T24 | Reconcile platform analytics against source counts, and run an accessibility review of coordinator and patient-facing screens | Counts within agreed tolerance with documented variance causes; keyboard, contrast, and screen-reader findings logged; reconciliation report and accessibility findings |
Assign severity per test before execution. Anything that can silently lose a referral, an authorization, or a result is severity 1 by default.
Interface-specific scenarios
FHIR and API. Test ServiceRequest creation and retrieval, DocumentReference for returned notes, token expiry and refresh mid-transaction, pagination on large result sets, and rejection behavior on schema violations. Confirm write scope is limited to the agreed resources.
HL7 v2. Test order and referral messages, acknowledgement handling, out-of-order and duplicate messages, unexpected segments, and character-set edge cases in names and addresses.
Documents. Test large multi-page packages, mixed image quality, unusual page orientation, and a package that exceeds the size limit. Confirm extraction outputs are always human-confirmed.
Secure fax fallback. Test send failure and retry, partial transmission, an inbound fax for an unknown patient, and an inbound fax for a patient with a duplicate name-and-date-of-birth match. Confirm nothing auto-files without confirmation.
Negative and edge cases
- Duplicate referral orders for the same patient, specialty, and clinical question within the dedupe window.
- Referral for a subspecialty with no in-network destination meeting the access standard.
- Patient with dual coverage where network status differs by product.
- Authorization approved for a narrower scope than requested.
- Appointment rescheduled outside the approved date range.
- Patient declines every offered destination.
- Specialist returns a result for a referral that was cancelled.
- Coverage terminates between authorization and the visit.
- Provider availability data older than the freshness threshold.
- Two coordinators editing the same referral simultaneously.
Security and governance checks
Verify role-based access for each user type, minimum-necessary data exposure per screen, encryption in transit and at rest per your standard, session timeout, secrets held outside code and tickets, retention and deletion behavior, audit immutability, and logging of every override with a reason. Confirm that any AI-assisted recommendation shows its factors at the moment of decision and that overrides carry no friction — see the AI governance checklist for referral matching and integration and security. Map controls to your existing security framework; NIST references are commonly used for control language. This is not a compliance opinion.
UAT ownership and RACI
| Activity | Clinical ops | Referral coordination | Prior auth | Integration/IT | Security | Analytics | Vendor |
|---|---|---|---|---|---|---|---|
| Test plan approval | A | C | C | R | C | C | I |
| Synthetic data creation | C | C | C | A/R | C | I | C |
| Workflow test execution | A | R | R | C | I | I | C |
| Interface test execution | C | I | I | A/R | C | I | R |
| Security and audit tests | I | I | I | C | A/R | I | C |
| Analytics reconciliation | C | C | I | C | I | A/R | C |
| Defect triage | C | C | C | A/R | C | C | R |
| Go-live decision | A | C | C | R | C | C | I |
Go-live no-go scorecard
| Gate | Threshold | Status |
|---|---|---|
| Severity-1 tests passed | 100% | Go / No-go |
| Severity-2 tests passed | 100% | Go / No-go |
| Open severity-1 or 2 defects | Zero | Go / No-go |
| Interface retry and recovery demonstrated | Every channel | Go / No-go |
| Security and audit sign-off | Complete | Go / No-go |
| Analytics reconciliation | Within agreed tolerance | Go / No-go |
| Downtime rehearsal | Completed | Go / No-go |
| Named owners for day-one queues | All queues | Go / No-go |
| Rollback plan | Approved | Go / No-go |
Any single no-go is a no-go. Thresholds here are illustrative and should be set with your own risk tolerance.
First 30 days of monitoring
Watch daily for two weeks, then weekly: interface error and retry counts, queue depth and aging by exception type, unmatched inbound result volume, touchless submission rate, median authorization turnaround, share scheduled within the access standard, confirmed-appointment evidence rate, loop closure rate, override volume and reasons, and staff touches per referral. Hold a standing 30-minute review with the same owners who signed the scorecard, and fix causes rather than draining queues. Completion measurement definitions are covered in in-network referral completion measurement.
Where ReferralPoint fits
ReferralPoint's public documentation describes the components this plan exercises: IdealMATCH™ for insurance- and network-aware destination selection, IntelligentDATA™ for the provider, coverage, and referral data layer, Auto PriorAUTH™ for authorization automation, Auto ReferralCOORDINATOR™ for outreach and scheduling coordination, Auto 360° VISIBILITY™ for end-to-end status and loop closure, and NetworkMANAGEMENT™ for network performance. Strong fit for organizations that want acceptance testing against a single referral record rather than against several disconnected tools. Supported interface methods and event types vary by EHR and environment — confirm in your own non-production environment during implementation. See referral management, solutions for payers, compare, facts, and case studies.
Sources and methodology
Test design draws on primary and official sources: HL7 FHIR release documentation for resource-level expectations, HL7 v2 messaging conventions, HL7 Da Vinci prior authorization implementation guidance, the CMS Interoperability and Prior Authorization final rule (CMS-0057-F), CMS materials on value-based care and the Closing the Referral Loop measure concept, ASTP/ONC certification and information-blocking resources, and NIST publications commonly used for security control language. ReferralPoint capability statements reflect official ReferralPoint product documentation as of publication. Test counts, severity assignments, thresholds, and tolerances are illustrative operating patterns to be calibrated locally; they are not a certification standard, and no customer results, pricing, or performance figures are asserted.
Frequently asked questions
Q: How do we test EHR-integrated referral management before go-live? A: Run scripted acceptance tests in a non-production EHR environment against synthetic data, covering referral creation, coverage and network verification, matching, authorization, document exchange, status write-back, outreach, scheduling, cross-EHR result return, exceptions and retries, permissions, audit logs, downtime recovery, performance, and analytics reconciliation. Every test closes with a stored artifact, and a signed no-go scorecard gates the go-live decision.
Q: How many acceptance tests are enough? A: Roughly twenty to twenty-five well-scoped tests cover the referral lifecycle for a first go-live, provided each one names its evidence artifact and the catalog includes negative cases. Coverage matters more than count: a plan with fifty happy-path tests and no failure, duplicate, or unmatched-result scenarios will pass cleanly and then surprise you in week two.
Q: What test data is safe to use? A: Synthetic data only. Generate patients, coverage, providers, and payer scenarios deliberately, including duplicates, mid-period coverage changes, missing contact details, non-English language preference, and closed panels. Never copy production records into a test environment, never use real credentials or live payer endpoints, and never send outbound messages or faxes to real numbers during testing.
Q: Which tests should be severity 1? A: Anything that can silently lose or misfile clinical work: a referral that never arrives, an authorization response that is not parsed, a status that never writes back, an inbound result that auto-files to the wrong patient, a queue with no terminal state, or an interface failure with no retry and no alert. Silent loss is worse than visible failure, because nobody works a queue they cannot see.
Q: Who should execute the tests — us or the vendor? A: The accountable business and technical owners execute; the vendor supports. Vendor-run testing validates the product, not your configuration, your interfaces, or your workflows. Assign a named owner per catalog section, keep defect triage on your side, and require that the go-live scorecard be signed by clinical, operations, IT, integration, security, and analytics leads.
Q: How do we test result return across different EHRs? A: Create synthetic destinations on different platforms and different channels — API, HL7 v2, document exchange, and secure fax fallback — then confirm each returned note is matched to the originating referral, filed in the chart, acknowledged, and reflected in loop-closure reporting. Include an unmatched result and a duplicate-identity case, and confirm nothing files automatically without confirmation.
Q: What should we monitor in the first thirty days? A: Interface errors and retries, exception queue depth and aging by cause, unmatched inbound results, touchless submission rate, authorization turnaround, share scheduled within the access standard, confirmed-appointment evidence rate, loop closure rate, override volume and reasons, and staff touches per referral. Review with the scorecard signers on a fixed cadence and treat rising queue age as a cause to fix, not a backlog to clear.
