An OEM or VAR shopping for cloud PACS vendors is not buying software for a radiology department down the hall. They are choosing the imaging stack their own customers will depend on, under their own logo, backed by a support line their own team answers first. That distinction changes which questions matter.
A practice buying a PACS for itself can walk away from a bad fit in a year. A partner who embeds the wrong platform has sold that dependency to every customer on it, and walking away means migrating all of them at once, on a timeline the partner does not fully control.
That is the premise of this framework: white-label depth, API access, who answers when a partner’s customer calls, and how deployment holds up across dozens of sites instead of one. The framework also asks what happens to those customers if the relationship ends, whose regulatory clearance covers what, and whose roadmap the partner’s product is actually riding on. None of it ranks one vendor over another. It is the list worth putting to any cloud PACS vendor before a product team signs a partnership agreement, not just a purchase order.
Evaluating Cloud PACS Vendors as a Partner, Not a Buyer
A single-site practice evaluating a PACS is scoping its own five-year cost, its own outage risk, and its fit with the RIS it already runs. That is a real evaluation problem with its own framework built around a practice’s constraints: no dedicated IT staff, a limited capital budget, one site with no failover.
A partner’s evaluation does not inherit that framing, because a partner is not the one reading studies. It is assembling a product or service line that other organizations will depend on, sight unseen, under a brand that is not the platform vendor’s.
Underneath all of this, the platform itself still has to be built to real depth, and a component-by-component checklist is what confirms it: archive, worklist, viewer, routing. But a feature checklist alone does not say what happens when a partner’s own customer calls with a problem, or what the partner’s exposure looks like the day the platform relationship ends. The seven questions below assume that seat: OEM or VAR, not radiology department.
What the White-Label Surface Actually Covers
“White-label” on a partner program page describes an outcome, not a mechanism, and the gap between the two is usually discovered after signing. A genuinely white-label surface replaces the vendor’s name, logo, and color scheme everywhere a customer looks: the viewer, the worklist, the mobile experience, and the automated emails the system sends on its own. A thinner version swaps the logo on a login screen and leaves the vendor’s name inside error messages, exported PDF headers, or a support link that lands a customer somewhere the partner never intended.
The viewer a customer opens is usually the easiest surface to demo as white-label and the hardest to fully rebrand. Rendering, calibration, and measurement tools sit deep in the viewer application, while the chrome around them is what a demo shows first. Ask specifically: does white-label extend to reports, exported files, and notification emails, or only the primary screen? And who controls that branding once it ships: configured once at onboarding, or updatable without a vendor support ticket every time the partner’s brand guidelines change?
API and SDK Depth, Not a Configuration Checkbox
Every platform on a partner shortlist will claim an API. What matters is whether that API is deep enough to embed acquisition, viewing, and reporting directly inside a partner’s own product, or whether it only exposes configuration options inside the vendor’s own interface. A configuration-only integration means the partner is skinning someone else’s application. An API and SDK deep enough to embed means the partner is building its own application on top of someone else’s imaging engine, a materially different product to sell and support later.
The DICOM services underneath that API are not optional context. Every imaging product still has to speak DICOM at the wire level. A partner touching modalities, a RIS, or an EHR on the far side of the platform is really scoping three separate integration surfaces, not one. An API that wraps only the first of those three, and leaves the other two as a professional services engagement, is thinner than a partner’s own roadmap probably assumes.
Ask specifically: can a partner’s own engineers ingest, route, and display a study using only the documented API, without ever opening the vendor’s own interface? Is there a sandbox environment to prove that before a contract is signed, and does the API surface cover the RIS and EHR seams, or stop at the modality connection alone?
Who Supports Your Customer, and How Escalation Actually Works
When a partner’s customer calls with a broken study, that call reaches the partner first, under the partner’s own brand, whether or not the partner’s own team can actually fix the problem. The platform vendor sits one layer removed from that relationship, and the escalation path between the two is exactly what a partner program’s marketing page tends to gloss over.
Partner programs often tier support, and the tier a partner sits in tends to decide how fast an escalation moves. So the question worth asking is not which tier is on offer but what the response commitment is inside it, in writing, and what it takes to move up. Ask any vendor to confirm their current program structure directly rather than reading it off a page, since published tier descriptions are often illustrative rather than contractual.
Ask: what is the contracted response time by severity level, not just the word “priority”? Can a partner’s own first-line team escalate directly to engineering, or does every ticket route through a general queue first, adding latency to a problem already on the partner’s own support line?
Deployment and Updates Across Every Site You Sell Into
A single-practice buyer asks what happens on installation day once. A partner asks the same question multiplied by every site it will ever sign, on a schedule set by its own sales pipeline rather than one procurement cycle. How a platform’s architecture handles that, edge hardware at each site, a hybrid cache, or fully centralized, decides whether deployment scales by adding staff or by pushing a repeatable, mostly remote process.
A vendor’s stated deployment timeline is worth pressure-testing at partner scale the same way it would be at single-site scale. Is the figure a contractual commitment, or a typical number drawn from a smaller footprint than the one a partner is about to build? Updates carry the same question in the other direction. A platform that needs a site visit for every patch is a very different maintenance calendar across fifty sites than one where updates push remotely on a schedule the vendor controls.
Ask: does the deployment and update mechanism scale by adding installation staff, or by automating what one technician can push across many sites at once? What is the actual time from a newly signed site to a live one, at the partner’s real volume, not a single-site demo timeline?
Data Ownership and What Exit Looks Like for Your Customers
A partner’s exposure here differs from a single buyer’s, because reselling a platform to a customer that is itself a HIPAA covered entity typically makes the partner that customer’s business associate. The platform vendor underneath becomes a subcontractor business associate, one link further down the chain. Federal guidance is direct: a subcontractor handling protected health information on a business associate’s behalf is itself a business associate, and a written agreement has to be in place before any PHI changes hands.
That chain matters most at the moment it breaks. A single practice’s exit from a vendor neutral archive is its own migration project, painful but contained to one organization. If a partner’s platform relationship ends, or the vendor is acquired, or a product line is discontinued, every one of that partner’s customers is exposed to the disruption at once, not just the partner. Each downstream business associate agreement then has to be addressed individually.
Ask: can every customer’s data be exported in standard DICOM format without the vendor’s own tooling, on the partner’s own initiative rather than a professional services queue? And does the head agreement specify what happens to the subcontractor business associate relationship, and to every downstream customer’s access, if the partnership itself terminates?
Regulatory Boundaries: Whose Clearance Covers What
White-labeling a cleared device does not require the partner to hold its own clearance. The FDA’s own guidance on distribution is direct on this point: distributing a manufacturer’s device under a private label does not by itself require the distributor to submit a separate 510(k). What does travel with a private label is a specific labeling duty, under 21 CFR 801.1(c). The label has to carry wording that reveals the actual manufacturing relationship, such as “Manufactured for” or “Distributed by” the partner’s name, rather than presenting the partner as the device’s originator.
The distributor also takes on a duty to forward product complaints back to the manufacturer for evaluation, not to resolve them independently.
Underneath that distribution question sits a narrower one: which specific component carries a clearance in the first place, and whether that clearance extends to the platform around it. On EBM mAIn PACS®, that clearance belongs to UDE alone, 510(k) clearance, as a Class II medical device, for that specific mobile workstation. It does not extend to the platform as a whole. The same discipline applies to any platform a partner is evaluating: ask which specific component, if any, carries a clearance, not whether “the platform” is cleared as a single claim.
Ask: which specific component holds a 510(k) clearance, and does a private-labeled version of that same component keep it, or does relabeling reset the question? Who owns complaint handling and adverse-event reporting once the product carries the partner’s own name instead of the manufacturer’s?
Roadmap Dependency: Whose Priorities Ship Next
A partner’s product roadmap is downstream of the platform vendor’s own roadmap the moment it embeds rather than builds. A feature a partner’s customers are asking for ships on the vendor’s timeline, not the partner’s, unless the partnership agreement gives the partner some real voice in that sequencing. That voice tends to correlate with tier level. A co-engineering relationship, the kind that typically sits at the top of a partner program, gives a partner more direct input into what gets built next than a standard reseller agreement does.
“Co-engineering” is worth pressure-testing the same way “white-label” is. Does it mean a partner can request and help fund a specific feature, or that a partner submits ideas into the same backlog everyone else uses?
A capability a vendor holds is not the same as one it ships and supports in this market. Asking which category a feature falls into, shipped here, built but not promoted here, or on a roadmap with no committed date, says more than asking whether a vendor generically “supports” something. IHE and XDS-I cross-enterprise components are a concrete example of that middle category on EBM Fabric™: present in the platform’s technical capabilities, not part of what EBM offers in this market today. That is a deliberate product decision rather than a technical gap.
That distinction, capability that exists versus capability currently offered, is worth asking about any roadmap item still on paper.
Ask: what is actually committed on the roadmap with a date, versus discussed as a direction? And does the specific partnership tier on the table come with any real mechanism to influence that sequencing, or only visibility into it after a decision is already made?
What This Means for Your Evaluation
None of the seven questions above rank one cloud PACS vendor against another, and none substitute for the component-level checklist every platform still has to pass. What they add is the layer a practice-side evaluation never has to ask: what happens to a partner’s own customers, at scale, when white-label branding turns out shallow or an API stops at configuration. The same question applies when a support escalation stalls, when a relationship ends, or when a roadmap promise never gets a date.
EBM Fabric™ is built for a partner asking these questions: an edge-to-cloud platform an OEM or VAR can put its own brand on. It comes with open APIs for embedding rather than configuring, and a partner program built around partners owning the customer relationship. Whichever platform a product team ultimately builds on, the honest way to choose is the same. Ask each question above of every vendor on the shortlist, and expect a specific mechanism in the answer, not a feature name.