Marvix AI

Ambient capture, pre charting synthesis, note generation, letter production and coding are all model output, with no services layer or platform business underneath.

The oversight model is published in the governing instrument rather than only implied by the product, and one part of it is missing.

An explicit sign off gate is published. The privacy policy states that outputs are drafts, that they are designed to require review, validation and affirmative acceptance by a licensed healthcare professional before clinical, billing or disclosure use, and that Marvix does not automate the signing, locking or finalization of clinical notes. That is a published statement of what the system may not do.

The coding path is the more transparent part. Evaluation and management levels, modifiers and add on codes are presented with the medical decision making rationale supporting them, so a clinician sees the basis for a suggestion rather than accepting a bare code. Traceability of that kind lets a reviewer disagree with the reasoning rather than only with the result.

One limit remains. The policy also states that once a draft reaches the customer's record system, the customer owns the configuration and downstream behavior, including any automatic signature, finalization, billing or propagation to portals and exchanges. So the commitment not to finalize is a commitment about this product's boundary, not a guarantee that an unreviewed note cannot become authoritative. The control that would prevent that sits in the customer's own system, and configuring it is the customer's work.

What is not published is what happens after an output is wrong. No acceptance rate, no edit burden figure, no confidence threshold and no described handling when a level recommendation or a note is incorrect.

Names its techniques rather than gesturing at them. Personalization is attributed to neural style transfer, a specific method rather than a claim that the system learns your style. Coding output carries explicit medical decision making rationale, so the reasoning behind an E/M level is inspectable rather than asserted. Specialty behavior is described concretely, including laterality propagation in orthopedics, which is the kind of detail only a team that has worked the specialty would name.

No accuracy figure, model card or evaluation methodology is published.

The categories are disclosed, and no party in the clinical path is named.

The privacy policy enumerates the kinds of third parties involved: hosting and infrastructure providers, AI and machine learning processing providers, transcription, analytics, customer support, security, billing, communications and integration partners. Categories are not names, and a category cannot be vetted the way a named party can.

The policy is easy to misread on one point. Google and Microsoft are named in it, and they are not the model layer. They appear as website analytics providers, Google Analytics 4, Google Tag Manager and Microsoft Clarity, and the policy states explicitly that the customer portal and authenticated areas do not use those tools. Nothing names the provider performing transcription or generation.

On training, the policy is specific: protected health information is not used to train shared models, and separately the vendor may retain a deidentified service improvement dataset used for large language model evaluation and model improvement. De-identification is stated to be designed to meet the Safe Harbor standard at 45 CFR 164.514(b)(2). So data does reach a training and evaluation path, by a route the protected health information commitment does not cover, and the vendor discloses it rather than obscuring it.

Volume raises the stakes of that gap. Pre-charting ingests prior notes, laboratory results, imaging and medications across a stated three years of history, so the unnamed parties in this chain handle far more historical content than a capture-only scribe would send them.

There is no published study, controlled evaluation, accuracy benchmark, third party rating, named customer or deployment count. The vendor publishes specialty depth and product detail rather than outcomes, and the 30-day trial including full features and integration is a commercial term rather than evidence.

A substantial share of the comparison content that surfaces when competitors are searched by name is published by Marvix itself. That is a legitimate marketing choice, but it is not evidence of adoption, and visibility in search is not market presence.

The coding surface is where evidence would matter most and where none exists. The product generates evaluation and management levels, diagnosis and procedure codes, and hierarchical condition category and risk adjustment scores. Each of those has a correct answer that could be measured against a reference standard, and none has been.

De identification and training use are stated precisely, and retention is deferred to a document that is not published.

De identification is the strongest element and it is named to a legal standard. The vendor states its de identification process is designed to meet the Safe Harbor standard at 45 CFR 164.514(b)(2), including removal of direct identifiers and measures against re identification from the retained dataset. Naming the rule rather than asserting that data is anonymized is specific enough to be argued with.

Training use is disclosed, including the part that works against the vendor. Protected health information is not used to train shared models. Separately, the vendor may create and retain a de identified, aggregated dataset used for analytics, quality assurance, large language model evaluation and model improvement, service improvement, security and benchmarking. Because de identified content is not protected health information, the first commitment does not reach the second path. That is a real route from clinical content into model improvement work, and the vendor publishes it rather than obscuring it.

The two statements do not combine into a permission gate over all training: the privacy policy conditions the service improvement dataset on agreements and customer settings rather than on permission, and the de identification route sits outside the protected health information commitment entirely.

Retention falls short, and the shortfall is specific. The privacy policy publishes periods for website analytics at fourteen months, marketing contacts at five years of inactivity, account information at the life of the account plus seven years, and system and audit logs at up to six years. For Customer Clinical Content including protected health information it publishes no period at all, deferring to the customer agreement, the business associate agreement and a Data Retention Policy that is referenced repeatedly and is not published. Every category has a number except clinical content. Deletion from the interface also does not remove copies from encrypted rolling backups, and record level deletion from those backups is not generally performed.

The volume point sharpens all of it. Pre charting ingests prior notes, laboratory results, imaging and medications across a stated three years of history, so these terms govern a far larger body of record content than an encounter recording.

Safety engineering is not published: no guardrails, no hallucination mitigation, and nothing on how a safety event is handled.

The vendor's own governing instrument states its business associate status, and the agreement itself is not published.

The privacy policy, version 3.1 of 25 May 2026, states that when Marvix receives or processes protected health information on behalf of a provider, health plan or other regulated entity it generally acts as a business associate and processes that information under the applicable business associate agreement and customer instructions. The policy subordinates itself to that agreement, stating that where the two conflict on protected health information the agreement controls. It also disclaims being a Notice of Privacy Practices, routes patient access and amendment requests to the treating provider, commits to assisting the customer with those requests where the agreement requires it, and ties breach notification to the agreement and applicable law.

That is a materially stronger basis than the compliance statements across its product and store listings. A marketplace listing can carry a statement of posture and can never satisfy a clause requiring the instrument itself; here the vendor's own document does the work instead, and it is specific about the role it occupies.

Three things are still missing. The agreement text is not published, so a counterparty cannot read what governs the relationship before entering a sales process. No tier is stated, so it is not known whether the agreement is offered on every plan or only above a threshold, which is often the detail that matters most. And nothing extends the agreement's obligations expressly to the subprocessors the policy describes, which matters on a product whose chain includes transcription and generation providers that are not named.

A recognized attestation is named in the vendor's own material and the artifact is not retrievable.

The vendor states SOC 2 Type II alongside health privacy rule compliance, and describes encryption at rest and in transit, role based access permissions and logging of all access.

What distinguishes this from a claimed logo is that the vendor's published material shows it understands what the attestation means. It explains that a Type 2 audit covers controls across a full audit period rather than at a single point in time. That distinction is the entire difference between the two report types. The vendor also publishes buyer guidance naming SOC 2 as the test, and states it meets the standard it sets.

Two gaps remain. The marketing material states the attestation is held; the privacy policy describes security processes maintained in alignment with a SOC 2 control environment, which is a looser formulation. Alignment with a control environment and a completed Type II report are different things, and the material does not say which is meant.

Beyond that, no trust center carrying a dated report, an audit period or a scope statement is published, so what the report covers cannot be seen. For a platform spanning documentation, pre charting from historical records and coding, scope is the substantive question rather than a formality. No ISO 27001 or HITRUST is named alongside it.

No clearance is claimed, none attaches to ambient documentation, and no United States device pathway applies. The vendor's own privacy policy states that it does not provide medical advice, diagnosis, treatment recommendations or reimbursement guarantees, and that outputs are drafts requiring affirmative acceptance by a licensed professional. That is close to a scoping statement.

What governs here is payment integrity rather than device regulation, and the coding surface is broader than a documentation product's usually is. The product generates procedural codes, diagnosis codes, evaluation and management levels, hierarchical condition category and risk adjustment factor scores, and the medical decision making rationale, alongside the note.

Two of those deserve separate attention.

Risk adjustment scoring determines payment for a patient population under risk bearing arrangements. A documentation product that calculates the score itself is operating on that mechanism directly rather than incidentally, and whether ambient documentation raises documented risk adjusted diagnoses because coding improves or because coding intensifies is an open question.

Generating the rationale is the sharper item. The rationale is the text that justifies the level selected. Where one system both selects the level and authors the reasoning defending it, the rationale cannot serve as an independent check on the selection, because it was written to support it. Nothing says what the rationale is derived from or whether it can ever fail to support the level chosen.

The product also generates after visit summaries, referral letters and insurance documents. After visit summaries reach patients directly, and nothing says whether a clinician reviews them before they are sent. The privacy policy states the vendor does not automate signing or finalization, and also that downstream automation configured in the customer's own record system is the customer's responsibility, which is where that risk actually sits.

The market is the United States only, stated by the vendor, which also declines to market into the European Economic Area, the United Kingdom or Switzerland.

Coding optimization language is present, with marketing about improving E/M accuracy and capturing modifiers, and modifier and add on coding is where billing scrutiny concentrates. Against that, every code is delivered with explicit medical decision making rationale, which is the single most useful control here because it converts a coding suggestion into an argument a clinician or auditor can evaluate rather than a number to accept. No fairness statement, subgroup analysis or accent and dialect disclosure is published, and no language coverage is claimed.

Mechanisms to challenge an output are well developed here, and nothing stands behind the output.

The mechanisms are real and now documented in the governing instrument rather than only in marketing. Coding output arrives with explicit medical decision making rationale, so the basis for a recommended evaluation and management level can be examined rather than accepted, and a coder or clinician can refuse a recommendation on its reasoning. The privacy policy states that outputs are drafts, that they may be inaccurate or incomplete, and that they are designed to require review, validation and affirmative acceptance by a licensed professional before clinical, billing or disclosure use. It states that the vendor does not automate the signing, locking or finalization of clinical notes. That last one is an architectural commitment rather than a disclaimer, and it is the reason the vendor can argue its outputs are not solely automated decision making under state privacy law.

The policy also allocates what happens after delivery, and the allocation runs away from the vendor. Once a draft reaches the customer's record system, the customer owns the configuration and downstream behavior, including any automatic signature, finalization, billing, claim submission or propagation to portals and exchanges. That is a defensible position: the control preventing an unreviewed note becoming authoritative sits in the customer's own system, not in this product.

What is absent is anything falsifiable or answerable. No accuracy figure, error rate or evaluation methodology is published for either the note or the coding output. No warranty, indemnity or remediation commitment is published, and the vendor disclaims medical advice, diagnosis, treatment recommendations and reimbursement guarantees. The service is sold only in the United States, so no enforceable correction right of the kind some other jurisdictions provide reaches the patient.

The coding surface makes the gap consequential. A wrong evaluation and management level is a billing exposure carried by the practice, and the rationale that would justify it is authored by the same system that chose it.

Named, broad and two way. Integrations are listed across athenahealth including Athena Flow and Athena Practice, Veradigm, AdvancedMD, eClinicalWorks, ModMed, DrChrono and NextGen, and the direction of travel is both ways: the product pulls patient history, prior notes, labs, imaging and medications to build the pre charting recap, then pushes structured notes, letters and codes back. Read access at that depth is a harder integration than note push and is what makes the longitudinal proposition work. Release notes show integrations being actively extended rather than listed once.

The privacy policy states that production data is stored in the United States, and that support, engineering, configuration, security, administrative and service operations may involve access or processing from locations outside the customer's jurisdiction. The vendor also states it does not market to or knowingly contract with organizations in the European Economic Area, the United Kingdom or Switzerland, so the service is sold into one jurisdiction.

Residency is committed in writing. There is one hosted option rather than a choice, and nothing published describes tenant isolation, so the processing path is partly open.

The offshore operational access disclosure is the useful part. Where production data rests and where staff may reach it from are different questions, and both matter for a business associate. Naming the second without being asked is a real disclosure.

The integration mechanism is better established than the residency position. Data exchange with the record system runs through secure application interfaces with section level field mapping, schedule synchronization and structured note delivery into named systems. That is a permissioned integration rather than a browser extension or robotic process automation driving the interface, so its actions carry their own identity and the record system's access controls apply.

The flow is bidirectional and the inbound volume is the larger half: prior notes, results and medications spanning a stated three years of history. So the question is not only where today's conversation is processed but where a multiyear extract of a practice's records sits while summaries are generated, and for how long.

Encryption in transit and at rest, role based access and access logging are described. The privacy policy places these in alignment with a SOC 2 control environment, which is a looser formulation than an attestation covering them.

No rate card. Pricing is described as customized by practice size and specialty, which is a quote process. What is published and notable is the trial: 30 days with full feature access and full bidirectional EHR integration included. Those are the advanced workflow features that determine whether a product works in a specialty practice, and Marvix points out that other trials often withhold them. A trial that includes the integration is the closest thing to an honest evaluation a buyer can get without a contract.

Deep specialty coverage, specific about what depth means. A claimed 135 or more specialties and subspecialties, with named deep support for neurology, oncology, orthopedics and nephrology, and capabilities that only matter inside those specialties: laterality propagation for orthopedic documentation, oncology staging and treatment plan handling, and composite notes for patients whose history spans years rather than one visit.

It also covers multi user workflows across medical assistants and providers with parallel rooming, vitals and pre charting, which reflects how specialty clinics actually run. Output extends to after visit summaries, referral letters and patient instructions.