It reads the study. The surgeon still makes the call.
Computer vision over DICOM studies, supporting orthopaedic preoperative planning and intraoperative guidance. In production with a practice in Boston.
The problem this was built for
Preoperative planning and intraoperative guidance both start from imaging, and both depend on how carefully each study is read. The volume arrives faster than careful reading scales, and careful is the only setting that counts.
Two competent clinicians reading the same study will plan slightly differently. That variance is invisible unless something is looking for it, and it is not a problem software can be allowed to solve by deciding instead.
What the platform does, and what it refuses to do
Computer vision over DICOM studies, surfacing structure and measurement to support the plan a surgeon builds. It runs with an orthopaedic practice in Boston.
The constraint shaped the product rather than being added to it. It complements the surgeon and never makes the decision, and everything it surfaces traces back to the image it came from. A number a clinician cannot resolve to a region of a specific study is not usable here whatever its accuracy, and that requirement shapes the data model rather than the interface.
What it does today.
Everything listed is something the software does now. Nothing on this page is a roadmap item, and there is no roadmap on it either.
DICOM ingestion
Works from the imaging the practice already produces, in the format it already produces it in.
Computer vision
Structure and measurement extracted from the study, evaluated against a held-out set rather than against a demo.
Traceability
Every output resolves to the image and the region it was derived from. This is a hard requirement, not a feature.
Preoperative planning
Support for the plan the surgeon builds, rather than a plan generated in place of one.
Intraoperative guidance
The same record available at the point the decision is actually made.
Clinical workflow fit
Sits where the work already happens, rather than adding a system somebody has to remember to open.
Access and audit
Who saw what, when, and on whose authority, because a clinical setting will eventually be asked.
The human boundary
No automated clinical decision, no silent override, and nothing the clinician cannot dismiss.
How it is put together.
A model belongs where the decision repeats, the data already exists, and being wrong is recoverable. The third of those is not true in a clinical setting, which is precisely why the system stops at support and why the boundary is drawn in the architecture rather than in interface copy.
The integration map, the model evaluation method and the deployment topology are covered in technical review under NDA rather than on a public page.
What actually gets attacked.
Clinical imaging is the most sensitive data this company touches. The design assumption is that it does not leave the environment the client controls unless they have agreed in writing that it may, and to where. DevTechGuru holds no healthcare certification and this page claims none: HIPAA and its equivalents are obligations that sit with the practice. What we do is build inside them, and tell you exactly what the system stores, what it transmits and to which third party, before the build rather than during a security review.
Ownership, handover and AI governance covers what a procurement or security reviewer usually asks next.
Why there is no figure here.
No accuracy figure, sensitivity or specificity number, or clinical outcome claim appears on this page. Those need a study, a method and a date. Publishing one without all three would be the most damaging overclaim available to a company working in healthcare, and it is the reason this page reads more cautiously than a competitor’s.
Technology
- AI
- LLMsRetrieval augmented generationComputer visionMachine learning
- Backend
- PythonDjangoFastAPINode.js
- Cloud
- AWSDockerCI/CDInfrastructure as code
Questions we get asked.
What buyers of this platform ask before a demo.
Does the system diagnose?
No. It presents what it found from the study and a clinician decides. That boundary is in the architecture, signed before the build, which is a different thing from a disclaimer at the bottom of a screen.
Where does the imaging go?
It stays in the environment the client controls unless they have agreed in writing otherwise. If a third-party service is in the path we name it, say what reaches it and say what it retains, before the build.
Where to go next
You do not need to arrive with a perfect technical specification.
Start with the problem. Tell us what is slowing the business down, what you want to build, or where the current system is failing. We will tell you the shortest path forward, including when that path is not us.
Start your build