Patient Access AI Tool Shortlist Guide

Patient Access AI Tool Shortlist Guide

A useful shortlist is not a list of vendor names. It is a buyer-owned record of which product, module, version, workflow, population, data flow, and decision were evaluated, what evidence was observed, and why a candidate may advance or must stop.

Patient access can describe several different jobs: scheduling an appointment, completing intake, checking eligibility, routing a referral, receiving a reminder, requesting a health record, connecting a third-party app, or escalating a potentially clinical message. Those jobs do not share one legal definition or one evidence standard. Define the job before comparing tools.

Use this guide before an RFP, during due diligence, before a controlled pilot, and at renewal. It is not medical, legal, billing, coding, reimbursement, procurement, or compliance advice. Qualified local owners must determine which rules, contracts, clinical controls, and accessibility duties apply to the actual organization and configuration.

The output should let a reviewer reconstruct the decision without attending the vendor demo. Record pass, conditional, stop, or unknown; the evidence owner; product and module version; source and observed date; limitation; expiry; and next action. If a required fact is missing, record unknown — local owner/evidence required. Never convert silence into a passing answer.

Start with the AI for Patient Access solution guide to define the workflow owner and handoffs. Use the patient access buyer guide for broader category research and the scheduling and intake guide when those are the only intended functions.

Define the patient-access lane first

The following four lanes are an editorial taxonomy for buyer research, not a legal definition. A suite may cross lanes, but an artifact supporting one lane does not automatically support another.

Access-to-service operations

This lane includes self-scheduling, rescheduling and cancellation, digital intake, insurance or eligibility input, referral receipt and routing, reminders, contact-center assistance, patient messaging, and escalation to staff.

Record the trigger, authoritative schedule or record, user, input, output, downstream write, correction path, and person who may pause the workflow. Identify included and excluded locations, specialties, payers, languages, devices, and patient groups.

Do not treat a faster front end as proof that a patient reached the right service. Test bad or missing data, identity conflicts, unavailable slots, wrong specialty, duplicate referrals, delayed eligibility responses, inaccessible steps, message delivery failures, and return to a human channel.

Access-to-records and portal

This lane covers viewing, downloading, transmitting, or requesting records and receiving a response, partial grant, or denial. It is distinct from scheduling convenience.

The HIPAA right of access in 45 CFR 164.524 applies to covered entities, designated record sets, and defined request facts. HHS explains the response timing and one written extension in its access timeliness FAQ.

HHS also explains that designated-record-set PHI held by a business associate may remain within the individual's access right in its business-associate access FAQ. A portal feature does not by itself prove that request intake, identity or representative verification, format choice, deadline controls, fees, BA handoff, delivery, denial, and audit duties are satisfied.

Interoperability and third-party apps

This lane covers patient-authorized apps, FHIR or SMART interfaces, payer APIs, certified health IT modules, and exchange with EHR, practice-management, referral, or eligibility systems.

The CMS Patient Access API is a defined requirement for specified impacted payers, not a synonym for every portal or scheduling product. The CMS Patient Access API FAQ, CMS-9115-F final rule, and CMS-0057-F fact sheet describe different data, actors, and dates.

The CMS interoperability policy and standards page can identify referenced standards and implementation guides. Record the exact rule, payer type, API, standard, implementation guide, version, authorization flow, data scope, compliance date, and test result. A FHIR endpoint does not prove local interoperability.

Clinical or safety-sensitive functions

Symptom collection, urgency classification, triage, care routing, diagnostic suggestions, and treatment-specific recommendations may create a different risk and regulatory branch from ordinary scheduling or form completion.

Use the FDA Digital Health Policy Navigator for function-by-function questions and the January 2026 Clinical Decision Support Software guidance for its stated scope. A product-wide administrative label, AI label, or human-review claim cannot classify every function.

If intended use, user, output, failure harm, or regulatory status is unresolved, keep that function outside the administrative shortlist until qualified owners complete the review.

How to use the eight mandatory gates

Run the gates before comparing price or projected value. Later evidence depends on earlier scope: a security report cannot identify the wrong workflow, an API certificate cannot prove a write-back was reconciled, and a polished accessibility statement cannot prove a patient completed the configured task.

Keep three evidence classes separate:

• A vendor assertion records what the supplier says a function or control does.
• A buyer-observed result records what happened in the configured environment and named scenario.
• An authority record identifies the accountable person's decision, conditions, scope, and expiry.

Record the source, version, observed date, limitation, owner, and expiry for every material claim.

Confirm every mandatory result against the proposed module, configuration, population, channel, and workflow.

Test the configured product with ordinary cases, difficult exceptions, downtime, correction, and exit scenarios.

Compare implementation effort, support, pricing, and value only after all applicable mandatory gates have acceptable evidence.

Document negative findings and abandoned approaches so the next reviewer can reconstruct the approved boundary.

Privacy, security, identity, data integrity, accessibility, clinical safety, audit, recovery, and exit failures cannot be offset by price, demo experience, adoption, projected savings, or a weighted score. Compare preferences only after every applicable mandatory gate has an acceptable result.

Gate 1: bound the workflow and decision authority

Create one inventory row for each proposed function. Name the product, module, build, configuration, organization, location, specialty, population, language, channel, source systems, downstream systems, and intended action. List exclusions with the same precision.

For scheduling or intake, identify who controls templates, availability, registration rules, referral criteria, and escalation. For messages, identify which content is purely administrative and which language requires clinical review. For eligibility, identify whether the tool stores a response, interprets it, or changes a downstream action.

Map who may request, configure, approve, monitor, pause, correct, and retire the function. A steering committee without a named role responsible for the local workflow is not an authority map.

Evidence request:

• Product, module, build, configuration, deployment pattern, and evidence date.
• Intended workflow, included cohort, exclusions, prohibited uses, and system of record.
• Trigger, input, output, downstream action, human decision, override, and pause owner.
• Responsibility matrix for vendor, buyer, integrator, and support teams.
• Approval conditions, expiry, renewed-review trigger, and known limitations.

Pass when another reviewer can reconstruct the exact workflow and decision boundary. Mark conditional only when the unresolved item has an owner, due date, interim control, and limited use.

Stop when the team cannot identify the function, authoritative record, downstream action, decision owner, excluded use, or person able to stop processing. A roadmap promise is not current evidence.

Gate 2: map data, identity, and rights paths

Trace the minimum data from collection through correction, downstream use, retention, export, and deletion. Include identifiers, appointment requests, intake answers, insurance information, referrals, messages, eligibility responses, call records, model inputs and outputs, logs, support tickets, analytics, and backups.

For every field, label the authoritative source, derived value, user who may correct it, systems that receive it, and effect of a mismatch. Test patient and proxy identity, duplicate records, changed contact details, merged charts, stale eligibility data, and incorrect referral attachments.

If the product handles record-access requests, map intake timestamp, scope, requested format, identity or representative verification, BA handoff, deadline and extension logic, partial grant or denial, fee calculation, delivery receipt, and audit evidence. Do not impose this branch on a product that does not perform that function.

Evidence request:

• Field-level data-flow and identity map with authoritative and derived fields.
• Correction, merge, unmerge, duplicate, proxy, consent, and authorization procedures.
• Record-access request and deadline evidence when that capability is in scope.
• Retention, export, deletion, backup, and downstream reconciliation evidence.
• Scenario results for missing, conflicting, stale, delayed, and misrouted data.

Pass when the buyer can trace a record or request end to end and can correct downstream effects without losing the audit history.

Unknown rule: if the authoritative record, identity decision, access-request clock, correction path, or retention boundary is unclear, record unknown — local owner/evidence required. Stop if the ambiguity can create uncontrolled disclosure, denial, or downstream action.

Gate 3: verify privacy and security controls

Determine the legal entities, roles, data classes, purposes, and transfers before asking whether a contract or control applies. Product category and hosting model do not establish covered-entity, business-associate, or consumer-app status.

The HHS current HIPAA Security Rule summary describes safeguards and distinguishes current requirements from proposed changes. The technical safeguard text in 45 CFR 164.312 addresses access control, audit controls, integrity, person or entity authentication, and transmission security.

HHS cloud computing guidance supports role, BAA, risk, service-level, data return, and shared-responsibility questions. A willingness to sign a BAA is not a product certification and does not prove the configured deployment is secure or compliant.

Patient-directed third-party apps may create a different privacy boundary after data leave a regulated payer or provider environment. CMS publishes privacy and security best practices for payers and app developers, and the FTC maintains the Health Breach Notification Rule for its defined non-HIPAA scope. Neither source makes every app subject to the same rule.

Evidence request:

• Entity, role, purpose, data-flow, BAA or contract applicability, and qualified owner decision.
• Permitted use, secondary use, model training, subprocessors, location, retention, return, and deletion terms.
• Configured identity, access, authentication, audit, integrity, transmission, incident, backup, and recovery evidence.
• Analytics, tracking SDK, advertising, support-access, and telemetry inventory.
• Incident notification, investigation, evidence preservation, and responsibility matrix.

Pass when technical configuration, architecture, contract, subprocessor record, and operational ownership agree for the proposed use.

Stop when material data movement is unknown, prohibited reuse cannot be disabled, a required agreement is unresolved, deletion cannot be tested, access cannot be audited, or a subprocessor remains undisclosed.

For adjacent due diligence, use what to check before using AI with PHI and the HIPAA-compliant AI tools guide. Those guides still do not replace local facts.

Gate 4: prove interoperability and certification scope

Separate marketing compatibility from a tested transaction. Record interface direction, resource or message, profile, required and optional fields, terminology, identifier, authorization, provenance, error behavior, retry, duplicate handling, write-back, and reconciliation.

The information-blocking rules in 45 CFR Part 171 apply to defined actors, EHI, practices, and knowledge standards. The ONC information-blocking page explains current resources and exceptions. A delay, fee, security control, or failure to meet an exception is not automatically an information-blocking determination.

For certification claims, capture product and module name, version, CHPL identifier, criterion, status, standard versions, and production differences. The HTI-1 final rule page, standardized API criterion, and enforcement discretion notices must be read in their exact scope and date.

ONC publishes all USCDI versions, while particular certification and CMS rules adopt specified versions on their own timelines. The newest published USCDI version does not automatically become the required version for every module, payer API, contract, or deployment.

Evidence request:

• Interface, standard, implementation guide, profile, version, endpoint, and authorization documentation.
• CHPL module, certification criterion, status, date, dependencies, and production configuration.
• Field mapping, terminology, identifier, provenance, error, retry, duplicate, and deletion behavior.
• Conformance results plus buyer-observed end-to-end read, write, correction, and reconciliation tests.
• Actor, EHI, practice, exception, and documentation analysis for information-blocking claims when applicable.

Pass when the exact data exchange works in the proposed configuration and the buyer can reconcile each downstream effect.

Unknown rule: a statement such as FHIR supported, USCDI compliant, or ONC certified without module, criterion, version, and observed test remains unknown. Stop when a critical write or correction cannot be detected and reconciled.

Gate 5: test accessibility and language access

Evaluate the complete patient task, not a landing page score. Include discovery, authentication, form completion, error recovery, document access, booking or submission, confirmation, cancellation, help, and return to a person.

The Section 504 web and mobile provisions in 45 CFR Part 84 Subpart I apply within their recipient and program scope. HHS announced a one-year change in dates in its May 2026 accessibility deadline notice. Do not convert those dates into a universal deadline for every private vendor or buyer.

Use the W3C WCAG-EM evaluation methodology to structure scope, exploration, representative sampling, evaluation, and reporting. An automated scan, VPAT or ACR may inform the review but cannot establish that the configured workflow works for representative users and assistive technologies.

Test keyboard-only operation, screen readers, magnification and reflow, zoom, contrast, focus, labels and instructions, time limits, errors, authentication, documents, mobile behavior, and recovery after interruption. Test the languages, reading needs, relay or alternate channels, and interpreter handoffs relevant to the local population.

Evidence request:

• Standard and version, evaluation scope, date, evaluator, product build, and known exclusions.
• Representative full tasks across web, mobile, embedded content, documents, and third-party steps.
• Manual, keyboard, screen-reader, zoom, reflow, error-recovery, and user evidence.
• Language coverage, content owner, terminology review, alternate channel, and escalation path.
• Defect severity, workaround, remediation owner, target date, retest, and release evidence.

Pass when representative users can complete every critical task and defects have owned, time-bound remediation and retest evidence.

Stop when a critical task cannot be completed and no acceptable alternate path exists. Unknown rule: scan-only or document-only evidence remains unknown — local owner/evidence required.

Gate 6: test exceptions and safety escalation

Test the cases most likely to disappear from a curated demo. Include unavailable appointments, incorrect specialty or location, duplicate referrals, missing authorizations, conflicting eligibility responses, proxy access, message misdelivery, sensitive content, repeated automation loops, staff overload, and emergency or clinical language.

For each scenario record expected behavior, observed behavior, detection method, reviewer, correction, downstream effect, severity, evidence link, and retest. Verify that the team can stop new processing, preserve evidence, correct the authoritative record, and reconcile every affected system.

Do not use the phrase human in the loop unless the design identifies what the person sees, what decision remains theirs, time available, ordinary workload, permitted override, recorded rationale, and escalation when they disagree.

Evidence request:

• Patient-access-specific scenario library and configured test data.
• Detection, alert, queue, escalation, override, correction, and pause evidence.
• Sensitive or urgent message policy with clinical and operational ownership.
• Complaint, abandonment, inaccessible-flow, misrouting, and repeated-contact review process.
• Incident severity, affected records, downstream reconciliation, corrective action, and retest.

Pass when consequential failures are detectable, containable, correctable, and reconstructable under ordinary workload.

Stop when a failure can create an uncontrolled appointment, referral, message, disclosure, denial, or clinical action; when staff cannot pause the workflow; or when correction depends on an undocumented vendor action.

Gate 7: prove continuity, recovery, and exit

Document what happens when the vendor, interface, identity service, eligibility source, notification channel, or buyer system is unavailable. A status page is not a continuity plan for the local patient journey.

Identify the manual path, staffing, queue protection, duplicate prevention, restored-data ordering, notification, reconciliation, and criteria for resuming automation. Test partial failure, delayed events, replay, duplicate writes, stale caches, expired authorization, and vendor support unavailable.

Exit planning begins before contracting. Specify export formats, metadata, attachments, logs, configuration, documentation, deletion, backup expiry, subprocessor handling, transition support, and verification. A screenshot or summary report is not a usable export of an operational record.

Evidence request:

• Dependency inventory, recovery objectives, downtime roles, manual workflow, and communication plan.
• Backup, restore, replay, duplicate prevention, queue handling, rollback, and reconciliation tests.
• Support coverage, severity definitions, escalation contacts, response commitments, and evidence access.
• Export format, completeness, provenance, documentation, transition assistance, deletion, and verification terms.
• Renewal, termination, price-change, product-change, and approval-resetting triggers.

Pass when the buyer can continue essential access work, recover the authoritative record, and exit without an unrecorded dependency.

Stop when there is no viable manual path, no reconciled recovery test, no usable export, no deletion verification, or a critical step depends on an undocumented vendor action.

Gate 8: classify clinical-sensitive functions

Apply this gate whenever a function collects symptoms, infers urgency, prioritizes care, recommends a service, produces diagnostic or treatment-specific content, or routes a patient based on health risk. Do not hide a clinical branch inside a general patient-engagement description.

Record the function, intended use, user, input, output, patient population, failure harm, decision owner, review evidence, override, monitoring, and authoritative regulatory source. Evaluate each function separately when one product combines administrative and clinical features.

NIST's AI Risk Management Framework can help organize lifecycle risks, and the Cybersecurity Framework can help structure cybersecurity outcomes. Both are voluntary resources, not approval, legal applicability, local validation, or a product certification.

Evidence request:

• Function-specific intended use, user, output, exclusions, and failure-harm analysis.
• FDA or other status rationale tied to the exact product, module, version, and configuration.
• Clinical owner, decision authority, validation population, threshold, limitations, and monitoring.
• Escalation, override, disagreement, pause, incident, and change-control evidence.
• Local configured tests for ordinary and difficult cases with downstream reconciliation.

Pass when qualified owners can explain the function, status, patient and user boundary, validation evidence, failure controls, and monitored use.

Unknown rule: if intended use, status, decision authority, validation population, or failure harm is unresolved, do not continue under an administrative assumption. Mark the function unknown or stop it until qualified review is complete.

Procurement questions by accountable owner

Each answer must point to an artifact, version, observed result, decision owner, and expiry. A yes or no without evidence is not an answer.

Patient-access operations

• Which exact patient journey, location, specialty, channel, and cohort is in scope, and what is explicitly excluded?
• Which schedule, referral, registration, eligibility, or messaging system is authoritative, and who may correct it?
• Who can pause the workflow, what triggers escalation, and which benefit and harm measures govern expansion?

HIM and privacy

• Which data belong to a designated record set, and does this tool receive, store, or fulfill an access request?
• How are patient and representative identity, requested format, correction, BA handoff, retention, and delivery recorded?
• Which uses, disclosures, analytics, training, secondary uses, and deletion duties remain conditional on local review?

Security

• What configured evidence supports access, authentication, audit, integrity, transmission, incident, backup, and recovery controls?
• Which subprocessors and support personnel can access data, under what purpose, location, logging, and contract terms?
• How will the buyer detect, contain, investigate, notify, correct, and preserve evidence after a security event?

Interoperability and IT

• Which interface, direction, FHIR or other version, profile, terminology, identifier, and authorization flow is implemented?
• Which module, CHPL identifier, criterion, standard version, and production difference supports any certification claim?
• How were read, write, error, duplicate, provenance, correction, deletion, and downstream reconciliation tested locally?

Accessibility and language

• Which complete tasks, builds, devices, assistive technologies, languages, and representative users were evaluated?
• Which findings remain open, what alternate path exists, and who owns remediation, retest, and release evidence?
• How do users recover from timeouts, errors, authentication barriers, inaccessible documents, failed translation, or channel interruption?

Clinical safety

• Does any function collect symptoms, infer urgency, prioritize care, or provide diagnostic or treatment-specific output?
• What intended use, status rationale, validation population, threshold, limitation, and failure-harm analysis applies?
• What does the reviewer see, what remains their decision, and how are override, disagreement, escalation, and pause recorded?

Legal, compliance, and procurement

• Who confirms covered-entity or BA status, CMS payer scope, ONC actor or module scope, accessibility duties, and other applicable laws?
• Which vendor claims are contractual, which remain marketing assertions, and which have buyer-observed verification?
• Which quote date, modules, usage assumptions, services, term, renewal, termination, data return, and change rights are documented?

Implementation, support, and data governance

• Which configuration, mapping, migration, training, monitoring, support, and change-control tasks belong to each party?
• How will downtime, delayed events, replay, rollback, manual continuity, export, deletion, and downstream reconciliation work?
• Which product, model, rule, language, integration, pricing, or subprocessor changes reset approval and require renewed review?

Buyer-owned shortlist artifacts

The buyer should own these records and keep links to source evidence. Their purpose is to preserve scope and unknowns, not to create a decorative scorecard.

Patient Access Tool Evidence Matrix

Create one row per candidate product and module. Include workflow lane, version, intended use, evidence date, claim, source, buyer verification, gate result, limitation, owner, open item, expiry, and next action.

Use pass, conditional, stop, or unknown. Keep vendor assertion, buyer-observed result, and authority record in separate fields. This is not a named vendor ranking, and blank cells never default to pass.

Workflow and authority map

Map trigger, user, source of truth, input, output, downstream write or message, human decision, correction, escalation, pause, rollback, and explicit exclusions.

Attach configured screenshots or logs only when they are current, permitted, and tied to product version. A generic architecture diagram does not replace the local map.

Data and applicability map

List data fields, authoritative or derived status, legal entity, role, purpose, transfer, storage, correction, retention, secondary use, subprocessor, export, and deletion.

Record HIPAA, CMS, ONC, FTC, accessibility, clinical, contract, and other applicability as confirmed, not applicable with rationale, or unknown. Product category does not decide the result.

API and certification dossier

Store interface documentation, profiles, resources or messages, versions, authorization, service base URLs, CHPL module and criteria, certification status, conformance results, production differences, field mapping, provenance, and local tests.

Keep publication, rule adoption, certification baseline, vendor implementation, and buyer deployment dates separate.

Accessibility evaluation record

Record evaluation scope, standard and version, build, evaluator, representative tasks, manual and assistive-technology methods, user evidence, findings, severity, alternate path, remediation, retest, and release.

Do not convert a scan percentage, VPAT, ACR, or isolated page test into complete-workflow approval.

Scenario and decision packet

Combine configured scenarios, expected and observed behavior, owner, severity, evidence, correction, retest, downstream reconciliation, gate results, unresolved risks, commercial assumptions, decision rationale, scope, conditions, expiry, and renewed-review trigger.

The packet should let an absent reviewer reconstruct why a candidate advanced, remained conditional, or stopped.

Scenario packet for local testing

Use empty scenarios and fill them with buyer-observed results. Do not preload a pass rate, routing accuracy, no-show reduction, conversion lift, time saving, patient-satisfaction figure, fairness result, implementation duration, price, or ROI.

• A new patient requests an appointment in the wrong specialty or at a location with no available slot.
• A patient or representative reschedules, cancels, or supplies an identity detail that conflicts with the authoritative record.
• Intake contains a missing field, duplicate record, outdated insurance response, inaccessible control, or interrupted mobile session.
• A referral arrives late, lacks required information, conflicts with another record, or cannot be reconciled after correction.
• A message reaches the wrong recipient, contains sensitive content, signals urgency, or loops without reaching a person.
• A record-access request involves a preferred format, BA-held information, partial denial, extension, fee, or delivery receipt.
• A FHIR authorization is revoked or expires, a response is incomplete or duplicated, or provenance is missing.
• A vendor or buyer service fails, events replay out of order, support is unavailable, or termination requires export and deletion.

For every scenario record expected behavior, observed behavior, build and configuration, tester, timestamp, evidence, detection, severity, correction, retest, downstream effect, reconciliation, and decision owner.

Use the healthcare AI vendor evaluation checklist for cross-category controls, how to run a healthcare AI pilot for controlled local execution, and the healthcare AI ROI and implementation guide for buyer-defined inputs. None provides a benchmark for this shortlist.

FAQs

Is every patient-access tool a CMS Patient Access API?

No. CMS rules define impacted payers, specified APIs, data, standards, and compliance dates. A provider portal, scheduling widget, intake form, contact-center tool, or ordinary patient app is not automatically the CMS Patient Access API. Confirm the payer, rule, API, data, version, and function; otherwise record unknown — local owner/evidence required.

Does a portal automatically satisfy the HIPAA right of access?

No. Portal availability may support access, but the rule involves covered-entity and designated-record-set scope, request facts, identity or representative handling, format, timing, extension, fee, denial, delivery, and records held by a BA. Qualified owners must evaluate the actual process.

Does FHIR or ONC certification prove local interoperability?

No. A standard or certification claim must be tied to a module, criterion, standard and implementation-guide versions, status, production configuration, and tested transaction. Conformance evidence does not prove that local mapping, identity, provenance, errors, write-back, correction, or reconciliation work.

Does a VPAT or automated scan prove accessibility?

No. Those artifacts may identify a declared standard or known findings, but they do not prove that representative patients can complete the configured task across devices, assistive technologies, languages, embedded services, documents, errors, and recovery. Local evaluation must preserve open defects and retest evidence.

Does a BAA make the deployment HIPAA compliant?

No. A BAA may be required for a particular relationship and allocates duties, but it does not prove correct role analysis, minimum data, configured safeguards, lawful use, secure integration, output quality, accessibility, incident readiness, or local workflow fit.

Are patient-access AI functions outside FDA oversight?

Not as a category. Review each software function by intended use, user, input, output, and failure harm. Ordinary administrative functions and clinical-sensitive functions may follow different paths within one product. Human review or an administrative label is not a universal conclusion.

Evidence boundary

This guide applies the 25 official sources scoped in the accompanying research gate. They support buyer questions within their stated actor, function, data, version, and date boundaries. They do not establish that a named product is compliant, certified, approved, accessible, interoperable, safe, effective, fairly priced, or suitable for a local workflow.

USCDI publication, HTI-1 adoption, CMS rule references, certification, vendor implementation, and buyer deployment can use different versions and dates. Preserve those differences rather than silently selecting the newest label.

The Section 504 web and mobile dates cited here are limited to the rule's covered recipients and current federal text. Other disability, language, state, contractual, consumer, communications, or international obligations require separate qualified review.

No named vendor pages, contracts, CHPL entries, FDA records, security reports, VPATs, accessibility evaluations, pricing, customer outcomes, local tests, patient interviews, or fresh analytics were reviewed for this article. No vendor ranking, product performance, legal conclusion, current traffic result, clinical outcome, savings, or ROI is claimed.

Before a real decision, assign qualified local owners, obtain current first-party product evidence, verify every time-sensitive official source, run the configured scenarios, and preserve negative findings. Any unresolved material fact remains unknown — local owner/evidence required.