What a structural planning platform actually touches
Five things, and it is worth being precise about each because the vague version is what turns a scoped integration into a project.
Image sources. CT for planning, and in most cardiac departments CMR as well. Studies arrive by standard DICOM transfer from the modality or from the archive. No modality-side change is required, and no proprietary acquisition format is involved.
The archive. The platform reads from PACS or VNA and writes results back as DICOM objects. If it cannot write back in a form the archive already understands, results end up living only inside the application, which is the failure mode that turns a clinical tool into a data silo three years later.
The reporting environment. Measurements have to reach the report without anyone retyping them. This is the integration that determines whether the platform saves the department time or costs it time.
Identity. Who can open the application, how they authenticate, and how access is revoked when someone leaves. If this is a local user database, it is a finding waiting for an audit.
The EMR. Order context in, results out, through the interface engine that already exists.
That is the whole surface. It is a software layer that reads from systems you run and writes back into them. It does not replace PACS, it does not replace the reporting platform, and it does not require a parallel archive.
Where the data lives
This is the first question in most institutions now, and increasingly the one that settles the evaluation before anything else is discussed.
cvi42 deploys on-premises. Studies are read inside the institution's own infrastructure and patient data does not leave it. For organizations operating under data residency obligations, institutional policy against cloud processing of identifiable patient data, or a security posture that treats egress as the control point, this removes the question rather than answering it.
It also changes what the security review is about. An on-premises deployment is reviewed as infrastructure inside a perimeter you already control, rather than as a data transfer agreement with a third party.
Identity and access
Authentication runs through your authentication provider with SSO and MFA. In practical terms that means user provisioning and deprovisioning follow the same path as every other enterprise application, group membership drives access, and there is no separate credential store for someone to forget about.
The reason this matters more for a structural planning tool than for a general viewer is the concentration of what it holds. A planning application accumulates the measurement record behind procedural decisions. Access to it should be governed by the same directory that governs everything else, and revocation should be a single action.
The reporting path
Measurements generated during structural planning reach the reporting environment through PowerScribe One, DICOM Structured Reporting, or HL7, depending on what the institution already runs.
DICOM SR is the relevant mechanism for anyone who wants the measurements to remain queryable rather than flattened into narrative text. A structured object carries each measurement as a discrete, coded value that the archive stores and later systems can read. That is the difference between a measurement that can be audited, trended and compared across time, and one that exists as a sentence.
HL7 covers the order and result messaging through the interface engine, which means the integration work sits with the engine the institution already operates rather than with a new point-to-point connection.
The work involved here is real but it is bounded, and it is the same category of work the department has done for every other reporting integration.
The OEM question
Most cardiac imaging departments are not building from nothing. They are running GE or Siemens infrastructure, and the honest question is whether a third-party planning platform fits alongside it or fights it.
cvi42 has more than 600 OEM deployments worldwide and integrates with both GE and Siemens environments. That history matters less as a credential than as evidence about the integration model: a platform with that many OEM deployments has been through the process of coexisting with vendor infrastructure repeatedly, which is a different thing from having done it once.
The framing to hold onto is that this is a vendor-neutral software layer. It reads standard DICOM from whatever acquired it, writes standard objects back to whatever archives them, and authenticates against the directory you already run. Nothing about adopting it requires displacing the modality vendor, the archive vendor, or the reporting vendor.
Why consolidation is an IT argument, not just a clinical one
The clinical case for one platform across cardiac CT, CMR and structural planning gets made in terms of reading consistency and training. The IT case is simpler and arguably stronger.
Three planning applications means three sets of the integration surface described above. Three archive connections, three reporting integrations, three identity configurations, three security reviews, three upgrade cycles to schedule around, three vendors to manage through renewal, and three separate answers when someone asks where a given measurement came from.
It also means three sets of the same measurement. Two established planning packages reading the same 100 patients
produced significantly different mean annulus areas. From an IT governance perspective that is not a clinical nuance, it is an unreconciled data quality problem living across two systems with no single source of truth.
Consolidating does not reduce the integration work to zero. It reduces it to one instance of each kind, which is the difference between a stack you can document and a stack you maintain from memory.
What a scoped conversation looks like
The useful version of this evaluation is short and specific. Which archive, and does it accept the objects the platform writes. Which reporting platform, and which of the three paths applies. What's your authentication identity source, and which groups map to which access. Whether on-premises deployment satisfies the data handling policy as written. Which OEM environments are in play and at which sites.
Five questions with five factual answers. cvi42 runs in more than 2,100 hospitals across more than 90 countries, which means none of these are being worked out for the first time.
If the clinical decision has been made and the request has landed on your desk, that conversation is the fastest route to a defensible answer.
Request the architecture detail for your environment →
Stay tuned for more on Structural Heart from the perspective of procurement and administration.
