Implant analysis on the patient’s own bone.
We turn a patient’s scan into a working model of their bone — then show you how an implant behaves in it, before it is ever made.
Every element carries stiffness derived from that scan’s own Hounsfield values — calibrated without a phantom, mapped through published density–elasticity laws, and solved as a contact problem between bone and implant.
- HU → ρapp → Eper-element material mapping
- Quadratic tetrahedra10-node elements, bone–implant contact solve
- 76 checksrun before any result is reported
Three ways in. One engine underneath.
The question a visitor arrives with is rarely the same one. What does not change is the analysis sitting behind all three.
An implant designer wants to know whether a geometry survives contact with real bone before the tooling is cut. A researcher wants a method that can be described in enough detail to be repeated, and numbers that can be traced to their assumptions. A clinician is usually being asked for something narrower than either — a scan, a review of whether a placement is plausible, an hour of time.
They are the same pipeline read from different ends. A patient’s CT becomes a bone model with per-element stiffness; an implant is placed against it; the assembly is meshed, given contact, and solved. What differs between the three is only which part of that chain you need to see, and how much of it you want to run yourself.
Validate a design before it is built
See how a specific implant behaves against a specific patient’s bone — while the geometry is still cheap to change.
See the capabilities →For research & academiaA reproducible, citable method
Automated checks, run provenance, and a written case for the approach — read it before you decide whether it fits your work.
Read the white paper →For clinical collaborationWhere engineering needs a clinician
What a clinical partner is actually asked for, and roughly what it costs in time.
Start a conversation →CT Studio
Read the scan, find the bone, and turn it into something you can build on.
Implant Studio
Model geometry and place it against that bone — the path from scan to assembly.
FEM Analysis
Solve the assembly and see where the load concentrates — the diagnostic result.
A scan goes in. An answer comes out.
Between those two sentences are the steps that decide whether the answer is worth anything — and the ones most often skipped.
Finding bone in a CT is where most of the silent errors are made. “Bone is above 300 HU” is true of dense cortical bone and false of the trabecular bone inside it — which is precisely the tissue that fails in aseptic loosening. Threshold alone leaves a hollow shell and quietly deletes the structure you most wanted to look at. The mask here is thresholded, then closed and filled, so each bone becomes the solid object a mesh can be built from. The original Hounsfield values stay untouched underneath, because the stiffness mapping reads those, not the mask.
Femur, tibia, patella and fibula come out as separate connected components once the joint space is respected, labelled by size and position rather than by a hard-coded slice index — a scan that is cropped differently, or a knee that is not where the template expected, does not silently mislabel a bone. Every component is reported with its volume, so a segmentation that has gone wrong is visible rather than inferred three stages later.
Surfaces are then decimated to a triangle budget as part of segmentation, not as a later optimisation. Marching cubes on a 0.5 mm knee produces millions of triangles, one per voxel face, and a mesher cannot undo a surface that was born too dense — an early bone STL sat over two hours in swap before it was killed. The budget is a recorded parameter, and the run reports what it actually hit.
We read the scan
Bone is found and separated automatically — no manual tracing.
We build and test it
The bone becomes a model, the model gets solved, and the result shows where the load actually goes.
Why it answers differently.
Most implant analysis starts from a standard bone. Starting from the patient’s changes the answer — and it is the part that usually gets skipped.
A standard bone is not a neutral choice. It is a specific bone — usually healthy, usually average, usually male — and every result read off it inherits those properties. The cases where an implant is hardest to get right are exactly the ones furthest from that average: thin cortices, low-density metaphyseal bone, prior hardware, deformity. Scaling a template to match a patient’s outer dimensions reproduces their size while keeping the template’s interior.
The interior is what carries the load. Stiffness varies by an order of magnitude between cortical shell and trabecular core, and where an implant seats against that gradient determines whether load is transferred or shielded. Getting the outline right and the distribution wrong is not a small error — it is the error, in the region the design is judged on.
The practical consequence is when you find out. A build-and-test cycle answers after the geometry is expensive to change; solving against the patient’s own bone answers while it is still a parameter. That difference is what turns a prototype into another iteration.
Their bone, not a template
The geometry comes from the patient’s own CT — the metaphysis, the cortex, the trabecular structure — not scaled from a generic model to approximate them.
Real bone, not one number
Bone is not uniform. Cortical and trabecular regions differ in density and stiffness, and that distribution is carried into the model instead of averaged into one number.
Answers before manufacture
A template-based check or a build-and-test cycle tells you the design was wrong after it is expensive to change. Solving against the patient’s own bone tells you sooner — and lets you run another iteration instead of another prototype.
76 automated checks run against every case before a result is reported.
Bone is not one material. The model does not pretend it is.
Geometry from a patient’s scan is the easy half. The half that changes the answer is what stiffness each element is given — and where that number came from.
A CT gives you two things: shape, and attenuation. Shape is the straightforward one — threshold, segment, mesh. Attenuation is where an analysis is won or lost, because attenuation is not stiffness. It becomes stiffness only after a calibration and a material law, and those two assumptions are the ones a result almost never shows you.
The chain here is HU → apparent density → elastic modulus, resolved per element rather than per part. Hounsfield values are converted using a scale fitted from the scan itself, so a protocol change does not quietly rescale every stiffness in the model. Density becomes modulus through published power laws selected by region, not one relationship applied everywhere. The resulting field is written into the solver as fifty binned material cards instead of a single cortical value — and each step records what it did, so a stress number can be traced back to the assumption that produced it.
That distinction bites hardest exactly where implants are judged: the metaphysis, the cortical shell, and the seating zone under a tray or a stem. These are the regions where an averaged stiffness is furthest from the bone actually present, and they are the regions a design decision rests on.
Calibrated without a phantom
Most clinical scans carry no calibration phantom. The scale is fitted from tissues already in the image — air, fat, muscle — with the sampling regions found in the volume rather than assumed from position.
Two laws, resolved per element
Trabecular and cortical bone follow different published power laws. Each element is assigned by the law its own density selects — and which law was used is recorded, never averaged away.
Fifty cards, not one number
The mapped field goes into the solver deck as 50 binned material cards, so the trabecular interior is never left carrying a cortical modulus.
Trabecular law Morgan 2003 · cortical law Keller 1994 via the Schileo 2008 ash factor · 50 binned cards per case
Not one design. All of them.
The right implant is rarely the first one you try. Explore the whole range at once instead of re-running by hand.
The obvious shortcut is to solve two variants and interpolate between them. It does not work here, and it is worth being explicit about why: contact is nonlinear, and so is the polymer bearing, which is modelled elastic–plastic rather than linear. A contact patch does not grow smoothly as a radius changes — it can shift, split, or move onto an edge — and no interpolation between two solved states will reproduce that. The variant that matters is usually the one where the behaviour changed, which is exactly the one an interpolation smooths away.
So every point in a sweep is a complete analysis: its own mesh, its own contact definition, its own solve. Set a range instead of a value on size, thickness or position and the results come back as a set that can be compared directly, with the same checks run against each one. The cost is compute, which is cheap; the thing it buys is knowing which variants are genuinely different rather than assuming they vary smoothly.
Try every size at once
Set a range instead of a value — size, thickness, position — and let it work through the options.
Each one fully solved
Every variant is a complete analysis, not an estimate or an interpolation between two you already ran.
Compare them side by side
The results come back together, so the choice is a comparison rather than a guess.
What this is — and what it is not.
Worth stating plainly rather than leaving to be inferred from what the page does not say.
The boundary is a deliberate one. This is structural analysis software: it answers where load goes in a bone–implant assembly and how that changes when the design changes. It does not interpret a scan for pathology, propose a treatment, or produce anything intended to be acted on clinically for an individual patient. No regulatory clearance is claimed or implied, and the product is scoped to stay outside that category rather than sitting near its edge.
The same honesty applies to the numbers. Automated checks run against every case before a result is reported, and each derived value records the assumption that produced it — but a check is not a validation. The polymer bearing in particular uses a representative bilinear curve, not a validated creep or wear model, so it is a screening result and is labelled as one. A design verdict still needs a validation case against published data. The platform is built to make that comparison straightforward, not to let it be skipped.
Engineering software
Built for implant design, mechanical screening and research. It answers a structural question: given this bone and this implant, where does the load go, and how does that change when the design changes.
Not a clinical device
Nothing here is a diagnosis, a treatment plan, or a patient‑specific clinical recommendation, and no regulatory clearance is claimed or implied. Clinical decisions stay with the clinician.
Screening, stated as such
The polymer bearing uses a representative bilinear curve, not a validated creep or wear model. A design verdict still needs a validation case against published data — the platform is built to make that comparison easy, not to skip it.
One accent, one capability.
Every colour on this page means the same thing everywhere it appears.
The split is not cosmetic — it follows where the data actually changes form. Imaging works in voxels: attenuation, calibration, segmentation. Pathways works in geometry: the implant, its placement, the assembly. Diagnostics works in fields: mesh, contact, solve, and the stress that comes back out.
Each hand-off is a point where something can be checked before the next stage inherits it, which is why they are separate capabilities rather than one opaque button. You can stop at any of them, look at what was produced, and go back.