basys.ai

AI interprets medical documentation and payer criteria across the core authorization and review workflows. The platform correlates patient information with policy requirements, identifies missing evidence, and generates reasoning for review outputs. Related modules apply pattern detection and risk scoring to potential fraud, waste, and abuse. These are the central functions offered to health plans and providers, rather than optional additions to a conventional record system.

Intake channels, audit trails, and communication tools support the workflow, but removing the models would remove the principal automated interpretation and matching capabilities on which the product's value proposition depends.

Provider workflows explicitly retain human control and use AI as a supportive copilot. Payer workflows, however, describe automated approval and denial outputs with reasoning and audit trails. The payer page also promises decisions progressing without delays or gaps, without qualifying that claim. Detailed confidence thresholds, mandatory escalation conditions, prohibited actions, and review requirements before an adverse coverage decision remain unclear.

Oversight language on the provider side does not establish equivalent controls for the payer's automated decision path. The current material therefore combines human review claims with broad autonomous output language whose limits are incomplete.

The architecture describes orchestration around language models, domain-specific agents, containerized execution, and version control intended to limit disruption from upstream model changes. Review outputs are tied to policy criteria and clinical evidence. This explains the broad system design and some operational choices. Specific production model names, algorithms, training datasets, model selection criteria, and evaluation thresholds remain unspecified. The available account therefore describes how the system is organized more clearly than the models that perform its current inference.

The platform uses domain-specific agents and language model orchestration, but the production foundation model providers are not identified. Local containerized execution and version control describe deployment choices rather than a complete list of organizations processing data. Named model suppliers, hosting processors, workflow-specific transfers, and downstream training or retention terms remain unspecified. The architecture therefore offers some insight into how components are arranged without establishing the complete supply chain or proving that every inference step avoids external services.

The current copilot claims 98% clinical accuracy, and the payer product claims a high proportion of automated approvals. The accompanying material does not establish the evaluation population, denominator, comparison method, or current model version behind those figures. Earlier diabetes work with Mayo Clinic and participation in a 2025 CMS competition concern separate contexts.

They do not establish performance for the present release without a link between the evaluated system and current product. A named pilot or competition selection can show engagement, while reproducible current outcome validation and independent confirmation of the headline metrics remain unspecified.

The stated safety approach includes human validation, monitoring, model stress testing, and measures intended to reduce fabricated information and bias. The company also describes evidence trails so reviewers can inspect how an output relates to source records. These controls are pertinent to authorization work, where an incorrect summary can affect a coverage decision.

Customer data retention, model training permissions, healthcare deidentification rules, and detailed procedures for investigating an AI safety incident remain unspecified. The operating claims therefore address review and reliability at a general level without completing the account of sensitive data use or containment of an unsafe output.

The technology page claims HIPAA compliance and pairs it with encryption, access controls, and audit trails. These are relevant assurances for a product handling patient charts and authorization records. The claim is not an accessible business associate agreement or a government certification of the product. A readable customer BAA, service privacy terms, subcontractor obligations, and coverage across deployment options remain unspecified. The available information therefore describes a compliance posture without establishing the complete contractual protections governing customer PHI.

Encryption, permissions based on user roles, and audit trails are part of the stated security design. They address access and traceability for medical records and authorization decisions. A named independent security attestation, auditor, reporting period, or accessible certificate remains unverified. The HIPAA wording on the technology page does not establish one. The current assurance is therefore based on described controls and compliance claims, without an independently inspectable artifact defining the security assessment's scope.

The core products compare medical documentation with coverage policies, assist authorization requests, and support payment integrity reviews. These functions primarily address healthcare administration rather than independently diagnosing a patient or selecting treatment. Utilization management also includes discharge planning and care pathway assistance, making the exact workflow context relevant.

No specific diagnostic device indication or FDA clearance is established for the current products. Clinical information and medical necessity reasoning are part of the review process, but their presence alone does not establish a separate regulated diagnostic function or an authorization for one.

A June 2025 announcement describes a proprietary framework with clinical safety checks, human decision checkpoints, ethical policy enforcement, and model drift monitoring. The company also participates in an NCQA working group concerned with healthcare AI standards. Those statements identify governance activities and an external standards discussion, but participation does not establish product certification.

A current reviewable framework artifact, production release mapping, or comparative subgroup results remain unverified. The available approach therefore goes beyond a generic fairness aspiration in its named processes while leaving their implementation and measurable effect on current model behavior insufficiently specified.

Providers retain review authority, and outputs include reasoning linked to patient information and policy requirements. This traceability can help users identify missing evidence or challenge an authorization recommendation before acting on it. It is an operational review mechanism rather than a binding remedy from the vendor. An enforceable correction obligation, output accuracy guarantee, reimbursement for incorrect decisions, and customer indemnification remain unspecified.

The available material therefore explains how people can inspect the basis of a recommendation without establishing who bears the financial consequences of a mistaken automated review or how a disputed output must be remedied.

The Smart Data Solutions partner brochure identifies a jointly designed prior authorization offering and names Epic integration alongside FHIR support. Its workflow includes intake through fax, APIs, and EHRs, followed by policy analysis and review assistance. This gives a named integration claim and recognizable exchange channels beyond a generic statement that the product connects with other systems.

A named production customer, exact connector functions, and bidirectional chart writeback remain unspecified. The brochure therefore supports an integration pathway without establishing that every deployment has a complete operating read and write connection to the clinical record.

Cloud deployment is offered alongside a local containerized option intended to support data sovereignty. The architecture also describes strict version control to reduce exposure to unplanned changes in upstream language models. These are concrete deployment choices relevant to a healthcare organization's control of its environment. Hosting regions, tenant isolation details, backup geography, and the complete external processing boundary remain unspecified.

Local execution of some agents does not establish that all components, model calls, telemetry, or support access stay inside the customer's infrastructure. The available options therefore provide partial control without a fully defined residency commitment.

Enterprise access begins with a demonstration or sales discussion. The site offers several review modules and requests contact details for additional whitepapers, but it does not provide a current price schedule. Base fees, usage units, implementation charges, minimum commitments, and differences between cloud and local deployment pricing remain unspecified. Claimed reductions in administrative cost describe intended operational value rather than an amount a health plan or provider would pay for the service.

The product targets health plans and providers across prior authorization, concurrent review, retrospective auditing, and payment integrity. A March 2026 announcement identifies an ePathUSA partnership supporting the CMS medical record review pilot, with AI intended to assist human reviewers in interpreting documentation and policy requirements. That is a named engagement in administrative review. It does not supply measured results across specialties or patient groups.

Earlier disease-specific examples address different contexts, while current performance by care setting, clinical specialty, policy type, or population remains unquantified. The breadth is therefore clearer at the workflow level than at the validated clinical population level.