Two vendors can quote the same total cost of ownership for the same deployment and still leave a partner carrying completely different risk. A total is a snapshot. A metering basis is a mechanism, and cloud PACS pricing is built on three of them: the study processed, the seat licensed to a reader, and the terabyte held in the archive. Each one answers a different question about what makes the bill move, and that answer matters more than the number attached to it on day one.
The full total, once every line item is on the table, is already covered in what a PACS costs. This piece stays a level below that total: not what the bill adds up to, but how it is calculated, and what that calculation does as a partner’s own book of business changes shape. A partner who understands the mechanism can model their own growth curve against it before signing. One who only reads the number at signing finds out how the mechanism behaves at the renewal after their busiest quarter.
The Three Units Cloud PACS Pricing Counts
A metering basis is the one thing a vendor counts and multiplies by a rate. Everything else in a cloud PACS contract, the support tier, the onboarding fee, the storage class, sits on top of that single decision. Three units cover most of the market: the study processed, the seat licensed to a reader, and the terabyte held in the archive.
Each basis ties the bill to a different part of a partner’s business, and each one is indifferent to the parts it does not measure. A per-study contract does not care how many readers touch the platform. A per-seat contract does not care how many studies those readers move through it. A per-terabyte contract cares about neither, only about what is currently sitting in storage.
Choosing a metering basis is choosing which part of the business a vendor gets to watch grow, and which parts grow at no extra cost.
Per Study: The Bill Follows Volume
A per-study model counts a billable event, usually a study ingested into the archive, and charges a rate for each one. The bill moves in lockstep with volume. A quiet month produces a quiet bill. A month where a partner’s customer wins new referral volume produces a larger one, on the same day that customer’s own revenue grows.
That symmetry is the model’s real character. It costs a site close to nothing to sit idle, which suits a new deployment, a seasonal practice, or a pilot a partner is not yet ready to commit volume to. It also means growth, the exact outcome a partner is selling their customer on, shows up as a cost increase before it shows up as anything else. A partner marking up a per-study rate for resale margin needs that markup to hold at ten times the pilot’s volume, not only at the volume in the pilot.
The definition of a study is where this model’s fine print lives. DICOM’s own standard ties a study to a Study Instance UID, a single required identifier carried by every object that belongs to that study. A billing system is free to count differently from that: at ingest, at storage, or per additional processing pass run against the same UID later. Two vendors both quoting per study can be metering different events, and the gap only shows up on an invoice.
A second ambiguity sits next to the first. Reading a current study against its priors means retrieving studies that were already billed once, when they were first stored. Whether that retrieval triggers a second charge is a contract term, not a behavior fixed by the standard, and it is exactly the kind of clause a headline rate does not show. Ask directly whether querying or retrieving an already-stored study counts as a billable event a second time.
Per Seat: The Bill Follows Readers, Not Studies
A per-seat model counts something else entirely: a licensed reader, workstation, or named user, and charges a flat rate per seat no matter how much volume moves through it. Ten studies a day and ten thousand studies a day cost the same, provided the same handful of people are reading them.
That indifference to volume is the model’s advantage for a specific shape of business. A high-volume, few-reader teleradiology operation, where a small panel of radiologists reads a large and growing study volume, sees its bill stay flat while its business scales. The effective cost per study falls as volume rises, the opposite of what a per-study model does to the same growth curve.
The same indifference punishes a different shape. A multi-site network suffers it in reverse. It carries many occasional readers: referring physicians who log in a few times a month, plus a rotating pool of on-call radiologists. Every one of those light logins prices out at the same seat rate as a full-time reader.
What exposes this before signing is the definition of a seat itself. Named-user licensing counts every person provisioned, whether or not they log in that month. Concurrent-session licensing counts simultaneous logins instead, which can serve a much larger nominal user base on far fewer seats. A vendor’s seat count and the number of people a partner has to provision are not the same thing until that definition is on the table.
Per Terabyte: The Bill Follows the Archive
A per-terabyte model bills against what is stored, not against what moves. Of the three bases, it is the only one tied to a number that only goes in one direction. A site can go quiet on volume and flat on readers. It cannot go backward on an archive still inside its retention window.
What drives that byte count, modality mix, protocol, slice count, is arithmetic rather than pricing policy, and belongs to sizing medical imaging storage rather than to a pricing decision.
That one-way property is what makes a per-terabyte model compound. Every year of stored studies keeps billing alongside every year that came before it, so this year’s growth rate is not the number that predicts next year’s bill. The accumulated total is. A contract priced against today’s footprint is pricing a snapshot of a number that has never once gotten smaller.
Two contract terms decide how sharply that compounding bites. The first is whether the rate is flat across the whole archive or tiered, cheaper for older studies moved to a colder storage class and full rate for anything recently written. A flat rate on a growing archive is a bill that rises every year even at zero new volume.
The second is what happens to the accumulated data at exit. HIPAA’s own business associate rules require that a contract with a cloud vendor provide for returning or destroying protected health information once the relationship ends, where that is feasible. A vendor who cannot answer what happens to the archive at termination has not actually priced the exit.
Neither term shows up in a headline per-terabyte rate. Both decide what the archive costs a partner by year three.
Grows With, Stays Flat When
| Metering basis | Grows with | Stays flat when | Favors |
|---|---|---|---|
| Per study | Studies processed | The site goes quiet | A new or seasonal deployment |
| Per seat | Readers licensed | Volume rises, reader count does not | A high-volume, few-reader operation |
| Per terabyte | Data already in the archive | Never, within the retention window | Rarely stands alone |
Why Most Real Contracts Mix Two or Three
Few vendors price on a single basis alone. A common structure pairs a per-seat base fee, covering the platform and a set number of readers, with per-study charges once volume crosses an included threshold. Another pairs per-study processing with per-terabyte storage billed separately, so moving a study and holding it are two different line items entirely.
The blend itself is not the problem. The surprise lives in how the pieces interact, and in one term that a pure per-study or per-seat model does not need on its own: the minimum commitment. A contract can be structured per-study and still guarantee the vendor a floor, a minimum charge that applies regardless of actual volume. A quiet month then costs the floor anyway, which defeats the appeal of paying only for what gets used.
A tiered structure creates its own version of the same surprise. Crossing a volume or storage threshold can move an entire contract onto a different rate, not just the units above the line. A partner who has modeled their cost at a steady per-unit rate can find the whole bill re-rated the month a single customer’s volume crosses a breakpoint nobody flagged at signing.
What This Means for a Partner’s Margin
Asking a vendor what their pricing model is does not answer any of this. It gets answered by mapping a partner’s own customer base against each basis and watching where the curve bends. A partner selling mostly to high-volume teleradiology groups with small reading panels is looking at a different optimal basis than one selling to multi-site networks with many light users and slow-growing archives.
The model that looks cheapest in a demo is the one priced against the volume in the demo. The model that protects margin is priced against the volume a partner actually expects three years in. That is the volume once the customers this pricing was supposed to win are using the platform the way it was sold to them.
For a partner packaging EBM Fabric™ underneath their own brand, metering basis is one piece of a larger evaluation. API depth, support escalation, and exit terms round out the rest, covered in the broader framework for evaluating cloud PACS vendors.
EBM publishes no pricing, and nothing above is a quote. These are the questions worth putting to any vendor, including whichever one ends up running the platform underneath a partner’s own product. Ask them before a metering basis chosen for today’s volume turns out to be the wrong one for the volume that arrives.