Copient Health
Operating room block time optimisation built around a machine learning prediction. The platform, ARDEN, forecasts which allocated surgical block time is likely to go unused and reallocates it according to the facility's financial objectives, clinical priorities and individual surgeon preferences, making recovered time available to surgeons looking for capacity. Modules are separately installable. Buyers are hospitals and ambulatory surgery centres. Founded by Michael Burke, chief executive, and Keyton Weissinger. Based in the Atlanta area, with sources giving both Atlanta and Alpharetta, and disagreeing on founding year between 2019 and 2021.
The design combines machine learning with behavioural economics, which is an unusual pairing and the more interesting half of the proposition. Predicting an unused block is a modelling problem; persuading a surgeon to release time they have been allocated and may want to keep is an incentive problem, and the company treats both as part of the product rather than assuming the prediction is sufficient.
This record sits deliberately alongside the two perioperative vendors built immediately before it, because the three together show the range in one narrow lane. LiveData has thirty five years of workflow software and a conversational query layer three months old, so its intelligence is peripheral. Apella raised 101 million dollars to put computer vision in the room, so its intelligence is the entire product. Copient is a six person company whose intelligence is also the entire product. Scale and centrality are independent, and a buyer comparing the lane should see that.
Scale and viability are the material risk on this record. Funding is 3.2 million dollars raised in a single Series A in January 2022 led by Atlanta Ventures with First Trust Capital Partners and Atlanta Seed Company, with no subsequent round located more than four years later. Headcount was reported at six in July 2024 with no more recent figure found. A hospital signing a multi year agreement for a system that reallocates surgeon block time should weigh continuity alongside capability.
Disclosure is minimal. A dedicated pass located no named customer, no outcome figure, no security certification, no trust page, no integration specification and no pricing information. Published material consists of product description and a marketing blog. The grades below reflect that and are a finding about what a buyer can verify rather than a judgement about whether the model works.
Capability Axes
An AI Health Index grade measures what a buyer can verify from public sources on the date shown. It is not a rating of how good the product is. A vendor can build an excellent system and grade low on an axis because it publishes nothing an outsider can check. How grades read
The prediction is the product. ARDEN forecasts which allocated surgical block time will go unused, and everything downstream, the reclamation, the redistribution and the analytics, depends on that forecast being right. Remove the model and there is no product, only a scheduling calendar the hospital already has.
That places a six person company in the same band as Fathom, Nym Health and Apella, which is the point worth recording. Centrality measures whether the model is the labour, not whether the company is large or well capitalised. Copient is one of the smallest records in this index and one of the most model dependent.
The behavioural economics component is product design rather than intelligence and does not dilute this. Persuading a surgeon to release time is an incentive problem the company solves in the interface; predicting that the time will go unused is the part only the model can do.
The decision structure is described and the boundary is not. Block time is identified as likely to go unused, then reallocated according to configured facility financial objectives, clinical priorities and individual surgeon preferences. Configuration by the customer is a real oversight mechanism, since the hospital sets the rules the reallocation follows rather than accepting a vendor's judgement about what matters.
What is unstated is who acts. Whether the system releases and reassigns time automatically, or presents a recommendation a perioperative manager approves, is not described anywhere, and those are very different products from a governance standpoint.
No prediction accuracy is published, which is the number that determines whether the tool is usable. A model that wrongly predicts a block will go unused, triggering release of time a surgeon intended to use, creates a scheduling conflict and a damaged relationship. The false positive cost here falls on named individuals rather than on an aggregate, which makes its absence more conspicuous than usual. Ask for prediction accuracy and whether release is automatic or approved.
The function is described clearly and the mechanism is named only at category level. Machine learning and predictive analytics are identified, the platform carries a product name, and what it predicts is stated precisely: which allocated block time will go unused, using historical data to anticipate future release.
Stating the prediction target that specifically is more useful than most vendors manage, because it lets a buyer reason about whether their own data would support it.
Nothing sits beneath that. No model class, architecture, feature set, training approach or version is described. No accuracy, precision or lead time figure is published for the forecast, and no statement addresses how much historical scheduling data a facility needs before predictions become reliable, which is the practical first question for a modular product sold to individual sites.
The behavioural economics element is asserted without content, with no description of what incentives are applied or how surgeon preferences are captured and weighted. Graded C for a well specified problem with an unspecified solution.
No party in the chain is named. No cloud platform, no model or analytics framework, no sub processor list, and no statement on whether customer scheduling data contributes to model development.
The last question has a competitive edge specific to this product that no other record in the index presents. The model learns from historical block utilisation, which is a facility's own operational performance data, including which surgeons routinely fail to fill their allocated time. If that data improves a shared model, a hospital is contributing commercially sensitive information about its own physicians to a product its competitors also buy. Whether models are trained per facility or pooled across customers is therefore a business question as much as a privacy one, and it is unaddressed in either direction.
Graded D because nothing in the chain is identified. Ask whether models are tenant isolated or pooled, what the training data consists of, and for a sub processor register.
Evidence is absent across the board. A dedicated pass found no named customer, no case study, no reference site, no outcome figure, no utilisation improvement measurement, no third party research assessment, no buyer survey placement, no award and no peer reviewed work.
Published material consists of product description and a marketing blog discussing operating room utilisation concepts in general terms rather than reporting results from deployments.
That is unusual even among small vendors in this index. Several companies of comparable size publish at least one named reference or a customer quoted outcome. This record has neither, which means a prospective buyer has no way to establish whether the prediction works at any facility, let alone one resembling theirs.
The funding history is the only external validation available, and it is dated: a single 3.2 million dollar round in January 2022 led by a regional venture firm, with nothing since. Graded D because there is nothing to assess. One named site with a utilisation figure would move this grade further than any other single disclosure.
Nothing was located. No retention schedule, encryption statement, access control description, data ownership or deletion position, data minimisation commitment, or statement on whether customer data contributes to model development.
As on the privacy axis, the sensitivity of what is held is lower than most records here, and that should be said plainly rather than left implied. Scheduling metadata is not clinical narrative, and this product captures no audio, no video and no physiological data.
The stewardship question that does bite is about people rather than patients. The model necessarily builds a picture of individual surgeon behaviour, specifically who reliably fills allocated time and who does not, which is performance data about named physicians. Whether that is retained, who inside the vendor can see it, whether it leaves the facility, and whether surgeons are told a model is scoring their utilisation are all unaddressed. Physician block allocation is contractually and politically sensitive at most institutions.
Graded D because nothing is published to assess. Ask what surgeon level data is retained and who can access it.
No health privacy material was located in a dedicated pass: no compliance statement, no control enumeration, no de identification position, and no business associate agreement posture, template or execution requirement.
Graded D rather than the conservative C applied to the large incumbents in this lane, and the distinction is the same one drawn for Semantic Health. A conglomerate's product scoped pass is genuinely partial. A six person company with a single web property and a blog is not a large estate to search, so a targeted pass returning nothing is meaningful evidence of non publication rather than of incomplete looking.
One mitigating point belongs on the record for accuracy. The data this product requires is operational rather than clinical: block allocations, scheduled and actual case times, surgeon identities and utilisation history. It does not need clinical notes, images or diagnoses. The privacy surface is therefore genuinely narrower than for most records in this index, even though surgeon level performance data carries its own sensitivity.
Ask what patient identifiable data the product touches, if any, and for the agreement position.
No credential was located. A targeted pass found no controls report, no information security certification, no health specific framework certification and no cloud authorisation. There is no trust center, no security page, no report availability process, no penetration testing disclosure and no vulnerability disclosure policy.
The cost barrier noted for LiveData applies with more force here. Formal certification routinely runs into six figures, which is a substantial fraction of a 3.2 million dollar total raise, and a six person company will have prioritised product over audit. That is an explanation and not a defence, and it does not change what a buyer can verify before contacting sales.
It does change what a buyer should do about it. For a vendor of this size the practical route is the hospital's own vendor risk assessment rather than a published report, and a prospective customer should plan for that process rather than expecting artefacts to exist.
Graded D consistently with the rest of this lane. Ask what security assessments have been completed for existing customers and whether any documentation can be shared.
No device pathway applies and none is claimed. Predicting whether allocated operating room time will be used, and reallocating it, is a scheduling and resource management determination with no clinical content. The model never sees a patient.
The governing constraints here are contractual and institutional rather than regulatory, and they are real. Block time allocation is typically embedded in surgeon employment or privileges arrangements, and automated release of allocated time touches agreements between a hospital and its physicians. A prediction that triggers release of time a surgeon was entitled to and intended to use is a contractual dispute rather than a regulatory event, but it is the failure mode that would end a deployment.
Nothing published addresses that dimension: no description of appeal or override, no statement of what notice a surgeon receives, and no reference to the governance body that would normally arbitrate block allocation at a hospital.
Graded C because the regulatory classification is correct and the institutional governance the product operates inside is undocumented. Ask how disputes over automated release are handled.
Nothing is published. No bias or fairness testing, no model validation methodology, no monitoring output, no distribution reporting and no external audit was located.
The fairness question here is unusually direct, because the model's output is an allocation of a scarce and valuable resource among named individuals. A system predicting which surgeons will not use their block time, and redistributing that time to others, is making decisions with consequences for physician income, case volume, training opportunity and patient access to particular specialists.
Systematic error would not appear as a visible mistake. A model that under predicts utilisation for surgeons with irregular but legitimate patterns, for lower volume specialties, for part time or academic surgeons with research obligations, or for those whose case mix is harder to forecast, would quietly and repeatedly take time from the same people. Nothing published describes what the model optimises for, whether allocation outcomes are examined by specialty or surgeon characteristics, or whether any fairness review exists.
Graded D because a product allocating operating room time among physicians publishes nothing about how it decides. Ask for the objective function and the distribution of reallocations by surgeon and specialty.
No performance figure is published, so there is no stated level against which a shortfall could be measured. No prediction accuracy, precision, false positive rate or lead time appears for the block utilisation forecast.
No service level agreement, warranty, indemnity or remediation commitment was located, and no pilot or trial terms were found.
The exposure created by an error is operational and relational rather than clinical, and should be described accurately. A wrong prediction releases time a surgeon intended to use, producing a scheduling conflict, a displaced case and a damaged relationship with a physician whose goodwill the hospital depends on. It does not harm a patient directly, though a cancelled or delayed case has consequences for the patient in it.
The viability dimension belongs here rather than being left unsaid. A single funding round in January 2022 with nothing since, and six reported staff, means continuity risk is a material part of what a buyer is accepting, particularly for a system embedded in surgeon block allocation. Ask for prediction accuracy, and for contractual provisions covering support continuity.
No integration material was located. No record or surgical scheduling system is named, no interface standard is described, no connection mechanism is specified, no marketplace or certification listing was found, and nothing states whether the platform reads the schedule only or writes reallocations back to it.
That last point is the substantive gap. A product that reclaims and redistributes block time must ultimately change the surgical schedule, and whether it does so directly in the scheduling system of record or produces changes staff enter manually determines both the integration burden and the operational risk. Nothing addresses it.
Graded D rather than the C given to vendors whose integration capability is evidenced by scale even when unspecified. Those records had deployments demonstrating that the integration works; this one has no named customer, so there is neither specification nor evidence.
Ask which scheduling systems are supported, through what mechanism, and whether reallocation writes back automatically.
The delivery model is stated at the highest level and nothing beneath it. The product is described as a software as a service platform with separately installable modules, which tells a buyer it is hosted rather than installed and that components can be adopted incrementally.
Modularity is a genuine deployment characteristic worth crediting, since it lowers the commitment required to start and lets a facility take block prediction without adopting a wider suite.
Beyond that nothing. No cloud provider, region, tenancy model, residency commitment or customer controlled option was located, and no statement addresses whether facility scheduling data leaves the hospital environment.
Graded C consistent with how a bare hosted or cloud based statement has been treated elsewhere in this lane. Ask where the platform runs, the tenancy model, and whether scheduling data is processed in a shared environment.
Nothing about cost is published. A dedicated pass located no pricing page, no unit of charge, no range, no implementation fee position, no minimum commitment, no pilot terms, no return calculator and no percentage improvement figure attached to any deployment.
The modular architecture makes the omission more consequential than for a single product. Modules are described as separately installable and working together, which implies tiered or component pricing, and nothing indicates what a single module costs, what the minimum viable configuration is, or how price scales with operating room count.
The economic argument the company makes in its own marketing is that operating rooms generate the majority of hospital revenue and margin, so idle time is a large opportunity cost. That framing invites a return calculation and the company supplies none of the inputs: no typical recovered hours, no realised utilisation lift, no revenue per recovered block.
Ask for the pricing basis, the minimum configuration, and what recovered utilisation a reference facility actually achieved.
Narrow, coherent and stated without overreach. The setting is perioperative block management in hospitals and ambulatory surgery centres, and the company addresses both explicitly, including published material examining whether the surgery centre dynamic differs from the hospital one. That is a more careful treatment of segment fit than most vendors offer, since block management economics genuinely differ between a hospital where the operating room funds the institution and a centre built around a smaller surgeon group.
Within that setting nothing is enumerated. No surgical specialty breakdown, no facility size range, no statement of how many operating rooms a site needs for the model to be worthwhile, and no named deployment from which any of it could be inferred.
Nothing addresses markets outside the United States, and block scheduling conventions are sufficiently national that the product likely does not travel without rework.
Graded C for a clearly bounded setting with no internal detail and no evidenced deployment inside it. Ask for the minimum facility profile and whether specialty mix affects prediction quality.
Pricing
Vendor-published figures are labeled as such. Figures labeled “Estimated” are derived from third-party sources and have not been confirmed by the vendor.
| Entry Price | Pricing Basis | BAA Tier | Implementation | Source |
|---|---|---|---|---|
|
Not published
|
Not disclosed. No unit of charge is described. Whether pricing is per operating room, per facility, per module or per recovered block is unstated, and the separately installable module structure implies component pricing that is nowhere explained. | Not disclosed. No business associate agreement posture, template or execution requirement was located. Note that the data the product requires is operational rather than clinical, comprising block allocations, scheduled and actual case times, surgeon identities and utilisation history, so the patient identifiable surface may be narrow. Whether it touches patient identifiable data at all is unstated and worth establishing directly, since the answer materially changes the agreement required. | Not disclosed. No implementation, integration or onboarding fee position was located and no implementation timeline is published. Nothing addresses how much historical scheduling data a facility must supply before predictions become reliable, which is a practical onboarding cost for a prediction product sold site by site. | Vendor Published |
Nothing about cost is published. A dedicated pass located no pricing page, no unit of charge, no range, no implementation fee position, no minimum commitment, no pilot terms, no return calculator and no percentage improvement figure attached to any deployment. The modular architecture makes that omission more consequential than it would be for a single product.
Modules are described as separately installable and designed to work together, which implies component or tiered pricing, and nothing indicates what a single module costs, what the minimum viable configuration is, or how price scales with operating room count. There is a particular gap between the company's own argument and its disclosure.
Its published material rests on the premise that operating rooms generate the majority of hospital revenue and margin, so idle block time is a large opportunity cost, and that framing directly invites a return calculation. The company supplies none of the inputs: no typical recovered hours, no realised utilisation lift at any site, and no revenue per recovered block. A buyer cannot model the case the vendor is asking them to accept.
Two further questions follow from the company's size and stage. Funding is a single 3.2 million dollar round from January 2022 with nothing located since, and reported headcount was six in July 2024, so contractual provisions covering support continuity, source code escrow and transition assistance deserve more attention than they would with a larger vendor.
And because the product reallocates surgeon block time, the commercial conversation should establish who at the institution owns that decision before pricing is discussed at all. Ask for the pricing basis, minimum configuration, recovered utilisation at a reference site, and continuity provisions.