Data Governance for OEM Planning Software
Where patient CT data goes and who is responsible when a manufacturer licenses a planning platform: residency, de-identification, and key contract terms.
Key takeaways
Data governance is the first-order question when an implant manufacturer licenses a surgical planning platform, because a CT-based planner runs on patient imaging and someone has to answer where that data goes and who is responsible for it. The core choices are architectural: server-side, client-side, and on-premise processing each move the CT scan to a different place and shift the accountability with it. On top of that sit de-identification, data residency, retention, and audit. For an OEM funding a vendor-neutral, implant-agnostic planner under a manufacturer-pays deal, governance is not an IT footnote: it decides whether the offering is defensible to hospitals, regulators, and the OEM's own quality system. The practical output is a contract that names the processing model, the residency region, the de-identification standard, retention limits, and breach duties in writing. Salnus builds this software for manufacturers to license and is currently Research Use Only (RUO), so governance is designed into pilots and co-development from the start, without any clearance or outcome claim.
Why data governance is a first-order question
When a manufacturer licenses planning software, the instinct is to evaluate the plan: the segmentation, the alignment options, the sizing support. That work matters, but it runs on top of a patient's CT scan, and the moment imaging leaves the hospital PACS the questions that follow are governance questions. Where does the scan travel? Who holds it, and for how long? Under whose legal responsibility does it sit while a plan is computed? A manufacturer that cannot answer these before signing has bought a workflow it cannot actually deploy, because the hospital's data protection office will ask first and the plan quality second.
This is why governance sits ahead of features in any serious OEM evaluation. A vendor-neutral, implant-agnostic planner already keeps the anatomy work independent of the implant library, which is the right commercial posture. But neutrality on the implant side means nothing if the data side is undefined. The OEM is licensing a pipeline that touches protected health information, and its own quality system will inherit whatever governance the platform does or does not enforce.
Where the CT data goes: three processing models
The single most consequential choice is architectural, because it decides the physical and legal location of the patient scan.
Server-side. The CT scan is uploaded to a processing environment and the plan is computed there. This is the most capable pattern for heavy 3D work, and it is how a lot of CT-based 3D planning is delivered. The trade is that patient data now leaves the hospital, so residency, encryption in transit and at rest, retention, and processor responsibility all become explicit contractual items rather than assumptions.
Client-side. Processing happens in the browser or on the user's machine, so the imaging need not leave the local environment at all. This narrows the data-exposure surface considerably and simplifies some residency questions, at the cost of depending on local compute. The broader trade-offs between these two are worth reading in cloud versus client-side medical AI.
On-premise. The software is deployed inside the hospital's own infrastructure and the CT scan never crosses the institution's boundary. This is often the cleanest answer for institutions with strict data-egress rules, and for an OEM it can be the difference between a yes and a no at a conservative account. The cost is deployment and maintenance overhead that has to be planned for.
None of these is universally correct. The point for a manufacturer is to know which model the platform uses, whether it can offer more than one, and to have that written down, because the answer determines every downstream obligation.
De-identification, residency, and retention
Once the processing model is fixed, three further controls define the governance posture.
De-identification. DICOM files carry patient identifiers in their headers. A governed pipeline de-identifies or pseudonymizes imaging before it moves or is stored, so that the data used for a plan is not directly identifying. The contract should name the standard applied and the point in the flow at which it happens, rather than leaving it as an informal practice. This is the same privacy-by-design principle that a hospital will expect to see documented.
Residency. For a manufacturer selling across borders, where data is processed and stored is a live legal question. A platform that can pin residency to a named region lets the OEM meet local rules instead of hoping a single global default satisfies everyone. Cross-border transfer, if it happens at all, has to be lawful and named.
Retention and audit. How long is a scan or a plan kept, and can access be logged and reviewed? Short, defined retention with an audit trail is far easier to defend than indefinite storage. A manufacturer inheriting this platform inherits its retention behavior, so it should be a contract term, not a setting discovered later.
Who is responsible, and what to require in the contract
Governance ultimately comes down to accountability: when patient data is processed to make a plan, who is the controller and who is the processor, and what happens if something goes wrong. For an OEM, the safe posture is to make the roles and duties explicit rather than assume them.
Concretely, a manufacturer licensing a planning platform should require in writing:
- The processing model, named: server-side, client-side, or on-premise, and whether alternatives are available for stricter accounts.
- Residency, pinned to a region, with any cross-border transfer identified and made lawful.
- The de-identification standard and the exact step in the flow where it is applied.
- Retention limits and deletion, with an audit trail for access.
- Roles and breach duties, so controller and processor responsibilities and notification timelines are unambiguous.
- RUO scope, stated plainly, so nobody treats a research-use pilot as a cleared product.
These belong in the same term sheet that defines commercial shape and IP, which is why governance sits alongside the other questions a manufacturer should raise before signing. Whether the engagement is a manufacturer-pays deal or a fuller build, the build versus buy decision for an OEM is incomplete until data governance is one of the answered items. Salnus works with manufacturers on exactly this basis; see how Salnus works with manufacturers for how a governed pilot is scoped.
The RUO caveat holds here as everywhere. Salnus software is Research Use Only and not a cleared device, so an OEM engagement is a pilot and co-development relationship with governance built in and evidence gathered along the way, not a turnkey purchase. Governance discipline in a research phase is exactly what makes a later regulated path credible.
Bottom line
For a manufacturer licensing planning software, data governance is not a compliance afterthought: it is the first question, because the platform runs on patient CT scans and someone must own where that data goes. Fix the processing model (server-side, client-side, or on-premise), then pin de-identification, residency, retention, and accountability in the contract. A vendor-neutral, implant-agnostic planner that answers these cleanly is one an OEM can actually deploy. To scope a governed, RUO pilot, see how Salnus works with manufacturers.
Reviewed by the Salnus biomedical engineering team.