Ember Copilot

Models are the engine of the coding, denial and appeal work, and a conventional revenue cycle platform sits underneath them.

What needs a model is real and it is what the company sells on. Reviewing every encounter against coding standards, payer policy and the practice's own contracts. Reading denial codes and reasoning to a root cause. Drafting appeal packets with clinical evidence. Evaluating orders against medical necessity criteria. Completing payer and employer forms from chart data with the source excerpt attached to each statement. None of that exists without a model, and the published architecture is three engines, data, coding and appeal, with the models doing the reading in all three.

What would remain is not a remnant. Several of the named agents are functions this market has bought as conventional automation for years: checking coverage and patient responsibility in payer portals, matching remittance advice to claims and reconciling payments against deposits, checking claim status and resolving holds, and comparing remits against contracted fee schedules to flag variances. Alongside those sit the record system and clearinghouse connections, a payer policy and contract repository, reporting, and a public payer directory.

Strip every model out and a practice still holds an eligibility, payment posting, claim status and contract benchmarking platform wired into its record system. Practices buy those without artificial intelligence.

So the model is the engine of core modules while the platform carries other value, which says nothing either way about how good the models are.

Which modules a given contract is actually priced on is not published.

Oversight is described in detail, and the one thing missing is the threshold that decides when it applies.

What is published is substantial. Exceptions and anomalies route automatically to staff with full claim and payer context before anything is submitted. Outputs carry the rule behind them and cite its source, so a reviewer can evaluate the proposal against the rule it claims to apply rather than accepting an unexplained flag. Drafted documents cite the chart excerpt behind each statement, and missing information is raised as a query rather than filled in. Version histories record what changed and who approved it, and every review, edit and approval is logged. On the documentation workflow a clinician reviews, edits and signs before anything is filed or sent.

That is an override path, an audit trail and a routing rule.

What is not published is what makes something an exception. Nothing states the confidence level, dollar value, code type or payer condition at which the system stops and hands over, and nothing states who sets that line or whether a customer can move it. The gap matters because the same platform is sold as autonomous coding and audits, and one page says human review is built into every workflow before anything reaches a payer while another says exceptions route to staff. Those are not the same statement: the first means nothing is automatic, the second means most things are. Nothing says which describes the contract.

The output is traceable and the thing producing it is not described at all.

What is published sits on the output side, and it is real. Determinations cite the rule they rest on, from the national coding initiative, coverage determinations or payer policy. Drafted documents cite the chart excerpt behind each statement. Version histories record what changed and who approved it. A buyer can follow any single recommendation back to the authority it claims, which is the practical form of transparency for a coding product.

None of that describes the model. No foundation model or provider is named, no architecture is characterized, no training data is described, and no versioning or update practice is published for the models themselves rather than for the documents they produce. Nothing tells a practice how it would learn that model behavior had changed between one month's flags and the next, which matters on a platform whose form mapping is said to get smarter over time.

No evaluation methodology exists for any agent. The ninety eight percent coding accuracy claim the company once made is gone from its site, and no figure has replaced it, so there is currently no published measure of how often the citations point at the right rule.

Citing a rule is not the same as disclosing a model.

The company says plainly that customer derived data improves its models, and names nothing that touches the data.

The disclosure stands out even though what it discloses is not the commitment a buyer would prefer. The terms state that aggregated or de-identified analytics are generated to improve model accuracy and platform reliability, subject to applicable law and the customer's agreement, and the published business associate agreement separately permits aggregation of protected information for the company's own purposes. The qualifier makes it negotiable rather than assumed. De-identification is tied to the regulation at 45 CFR 164.514(a) to (b) rather than defined by the company, which closes the gap that usually leaves an entire commitment resting on one word.

What is missing is the chain itself. No model or model family is named, no foundation model provider, no hosting arrangement and no published sub processor list. The company states a current sub processor list is available on request and that it can walk a security reviewer through the architecture, which is a document behind a request rather than a published one.

The content moving through that unnamed chain is broad: clinical notes, charge files, diagnoses, medication and provider data pulled from a dozen record systems, drafted clinical documents, and credentials for payer portals the agents log into on the practice's behalf. The business associate agreement also permits that information to move outside the United States.

Eight quantified outcome figures are published and none of them carries a method, a denominator or a named site.

The figures are specific: fifty seven percent fewer denials, a twenty three percent improvement in clean claim rate, five percent more net collected revenue, 3.1 times faster appeal turnaround, 3.3 times return on investment in month one, over a hundred full time equivalent hours saved per month, 9.3 percent more net revenue per appointment, and all denials worked. They are presented under a heading stating that these are numbers from live deployments, not projections and not modeled estimates, but measured customer outcomes.

That framing is the part to weigh, because measured is a strong word and nothing published says over what period, against what baseline, across how many practices or in which specialties. No customer is named anywhere. Two case studies are linked and their subjects are not identified in the page itself, and the quoted endorsements are attributed to job titles rather than organizations.

A ninety eight percent coding accuracy figure the company used to publish no longer appears on its site. Nothing has replaced it, so the platform currently publishes operational and financial figures and no measure of whether its coding output is correct, which for a product that reviews every encounter is the number a buyer most needs.

Training use and deidentification are answered specifically enough to be contradicted; retention is not.

Training use is stated affirmatively rather than left silent. The terms say the company generates aggregated or de-identified analytics to improve model accuracy and platform reliability, subject to applicable law and the customer's agreement, and the published business associate agreement separately permits it to aggregate protected information for its own purposes. That is a plain statement that customer derived data improves the models, and the qualifier makes it negotiable rather than assumed, so a buyer who reads it knows there is something to ask to switch off.

De-identification is named to a standard rather than asserted. The agreement ties it to the regulation at 45 CFR 164.514(a) to (b), which is the recognized route rather than a method the company defines for itself, and that is the difference between a de-identification claim and a de-identification method.

Retention is where it stops short. The published position is that data is held only as long as necessary to provide the service, meet legal obligations or as specified in the customer's agreement, which is a posture rather than a period. No number of days or months appears for any data type the platform holds, and those differ sharply: a chart excerpt pulled for a draft, a generated appeal packet and a submitted claim have very different lifespans. What is published is the end state, since on termination the company must return or destroy everything it holds and keep no copies.

Alongside this sit AES-256 encryption, least privilege access and audit logging.

The business associate agreement is published in full and can be read before contracting.

Status is stated plainly: the company signs business associate agreements with all covered entities before any protected health information is exchanged, and the agreement itself is attached to the terms of service as a schedule. There is no tier gate, no enterprise only qualifier and nothing to request.

What the published agreement contains is the substance. Subcontractors are bound: the company may pass protected information to a subcontractor only after that subcontractor executes a binding written agreement holding it to substantially similar terms, with the company required to vet the subcontractor and a pattern of subcontractor violation treated as the company's own breach. Breach notification runs to sixty calendar days from discovery. On termination the company must return or destroy all protected information held by it, its agents or its subcontractors at the customer's direction, and may keep no copies unless told to. De identification is tied to the regulation rather than asserted, naming the standard at 45 CFR 164.514(a) to (b). Books, records and internal policies are available to the regulator on request, and privacy and security officials are appointed.

One clause in the same document matters: the agreement expressly permits the company to use and disclose protected information outside the United States to provide the service.

Two recognized attestations are named with their type, and a trust center exists.

The company states it holds a SOC 2 Type II attestation covering security, availability and confidentiality, validated through regular third party audits, and that it is HITRUST e1 certified. Both are the company's own rather than its cloud provider's, and a dedicated security page presents them alongside links to a hosted trust portal and to the assessment itself. Encryption is specified concretely at AES-256 in transit and at rest, with least privilege role based access, detailed audit logging and continuous monitoring described, and the terms of service carry the same commitments contractually rather than only as marketing.

The hosted trust center may hold the observation period, audit window and scope; none of them appears in the rest of the published material. HITRUST e1 is the foundational tier of that framework, and the company states that security documentation and a current subprocessor list are available on request.

Scope is open. The platform spans coding, documentation drafting, payer portal submission and payment posting across a dozen record systems.

No device claim is made and the product is scoped accordingly, which is the ordinary and appropriate position for coding and revenue cycle software.

The company states plainly in its terms that it provides software and workflow automation, that it does not give medical, legal, billing or coding advice, and that customer personnel remain responsible for final coding, billing and clinical decisions. Its outputs cite the rule they rest on, from the national coding initiative, coverage determinations or payer policy, and drafted documents cite the chart excerpt behind each statement, so the basis of a recommendation is reviewable by the person who signs it. Nothing is marketed as diagnosing, triaging or treating a patient. Assigning a diagnosis code is coding rather than clinical diagnosis, and the company does not blur the two.

Naming the rules it answers to is not a regulatory pathway. No pathway is stated or in progress, and no clearance exists.

The real exposure is not a device question. Liability for what is submitted sits with the practice that submits it under the false claims framework, not with the software that suggested it, and the medical necessity workflow evaluates orders against payer criteria while the practice carries the consequence of the submission.

One thing published here stands out, and it is not a bias evaluation.

The direction question is the one that matters for a coding product, and this vendor answers it. A system reviewing every encounter and proposing corrections is changing what gets billed, and a platform sold on revenue recovery has an obvious incentive to push one way. The company states that undercoded and overcoded claims are both flagged before the claim goes out, which names both directions rather than only the profitable one. That candor counts in its favor, and it is a claim rather than a measurement: no ratio is published between codes added and codes removed, and that ratio is what would show whether the practice holds.

What exists alongside it is process rather than evaluation. Every action is explainable and auditable, determinations cite their sources, version histories capture what changed and who approved it, and human review is described as built into the workflow. Those are controls over how the system is operated, not evidence of how the models behave.

The published material carries no bias or fairness evaluation, no subgroup performance, no monitoring or drift disclosure and no independent audit of model behavior. The mechanism worth testing is specialty and payer skew rather than speaker demographics: coding rules and payer policy differ sharply by specialty, and a platform covering two dozen of them with published workflows for a handful will not perform evenly across the rest.

The explainability is real and it is the control a buyer would rely on, and nothing is promised if it fails.

Outputs carry the underlying rule and cite its source, so a coder sees why a change was proposed rather than receiving an unexplained flag, and can refuse it on grounds they could articulate to an auditor later. Drafted documents cite the chart excerpt behind each statement, missing information is raised as a query rather than filled in, and version histories record what changed and who approved it. That turns review from acceptance into adjudication, which matters most in coding because the person who signs carries the exposure.

What does not exist is any measurement or any commitment. No accuracy figure, no error rate, no false positive rate on flags, and no warranty, indemnity or remediation term. The vendor once published a ninety eight percent coding accuracy claim; it no longer appears in the vendor's material and nothing has replaced it, so a buyer today has an auditable mechanism with no published evidence of how often it is right.

Neither accuracy against a credentialed coder audit nor the rate at which claims the platform touched are later denied or reversed is published. The second is the one a practice actually feels, and denial reduction is what the platform is sold on.

The allocation of risk runs one way. The platform proposes the code and drafts the appeal, the practice signs and submits, and liability under the false claims framework attaches to the submitter.

Thirteen record and practice management systems are named, with reading and writing both described and nothing published to verify either.

The named list is athenahealth, ModMed, eClinicalWorks, Nextech, Veradigm, NextGen, Epic, Oracle Cerner, HST Pathways, Surgical Information Systems, AdvancedMD, DrChrono and Altera, alongside the Availity and Waystar clearinghouses and major payer portals. That breadth fits the buyer: specialty practices and surgery centers run a long tail of systems that platforms built for large health systems often skip.

The direction of flow is described on both sides. The platform pulls clinical notes, codes, charge files, encounters, diagnoses, medications and providers, and on the documentation workflow it files the completed document back and routes downstream steps once a clinician signs. The agents also submit prior authorizations to payer portals and electronic authorization systems, and post payments and adjustments back against claims.

None of it can be checked. No marketplace listing appears for any of the named systems, no interface documentation, conformance statement or standard is published, and no named site is identified as running any specific connection in production. Integration is said to take days rather than quarters, which is a claim about effort rather than evidence of depth.

The residency question has two published answers, and they point in opposite directions.

The marketing position is United States based cloud infrastructure. The contract position is different: the published business associate agreement states in terms that the company is permitted to use and disclose protected health information outside the United States to provide the service. Those are not the same statement. One implies data stays in the country, the other reserves the right to move it, and the one that governs is the one attached to the agreement a buyer signs.

The exposed buyer is a practice that selected this vendor on the residency line, or a health system whose own policy or state contracting rules restrict offshore processing of patient information, and which would discover the permission only by reading the schedule rather than the product page.

Nothing else about the deployment is published. No hosting provider, no region, no tenancy model and no sub processor list, although the company states a current list is available on request and that it can walk a security reviewer through the architecture. Two sub processor layers are near certain for a product of this shape and neither is named: a language model provider for drafting and code suggestion, and payer portal automation for the agents that log into those portals.

That second one matters most, because the terms also state that deidentified data improves model accuracy.

Pricing is unpublished, and the route to finding out what the product would do for you is unusually concrete.

A prospect can submit thirty days of denial data or a few hundred cases and receive an initial analysis within seven days, with full integration described as taking weeks rather than quarters. For a product whose value depends entirely on a practice's own case mix, payer set and specialty, a measured finding against that practice's own data is more useful than a rate card would be, and it lets a buyer test the claims before committing. A public payer directory is also published and free to use.

What is absent is the unit of charge, and for a product like this that is the commercial question rather than a detail. Nothing states whether the platform is sold per encounter, per provider, per claim, as a flat subscription, or as a percentage of what it recovers. Contingency pricing and subscription pricing put the vendor's incentives in very different places on a product that decides which codes to add, and a buyer cannot tell from published material which model is on offer. No minimum, no term length and no figure of any kind appears.

What can be learned before contact is how the product is sold and how an evaluation starts.

Coverage is stated concretely at the top and broadly at the bottom.

Settings are named as specialty physician practices, surgery centers and health systems. Two dozen specialties are listed, and nine of them carry a described workflow rather than only a name: behavioral health with therapy coding, medication management and parity rule denials; cardiology with catheterization lab coding, device implants and imaging authorization; dermatology with Mohs surgery and biologics; gastroenterology with endoscopy coding; ophthalmology with retina workflows and anti-VEGF injections; orthopedics with surgical bundling, durable equipment and modifier heavy coding; ear, nose and throat with sinus surgery and immunotherapy units; radiology with modifier driven edits; and urology with cystoscopy coding and named prostate procedures. Naming the actual coding problem in each is the right level of specificity, because modifier conventions and payer policy differ sharply between specialties and a general engine tends to be weakest where the money is.

The breadth beyond those nine rests on assertion. The platform is described as specialty agnostic by design, with a statement that any practice with high procedure volume, complex coding and meaningful payer scrutiny can generally be supported. Generally is doing the work in that sentence, and nothing validates the wider list.

Nothing shows what is running in production outside the nine described specialties.