Surgical decision support for AvailOrtho

Computer vision over DICOM studies, supporting orthopaedic surgical planning and intraoperative guidance.

Client
AvailOrtho
Location
Boston, United States
Industry
Healthcare and MedTech
Project type
Surgical decision support
Service
AI and Machine Learning Development
Status
In production
Result
Decision support the surgeon stays accountable for.

The client

AvailOrtho is an orthopaedic practice in Boston. Preoperative planning and intraoperative guidance both start from imaging, and both are judgment calls made by a clinician who is accountable for the outcome. That accountability is the design constraint, not a disclaimer added to the end of one.

The challenge

Preoperative planning and intraoperative guidance depended on how carefully each surgeon read each study.

The constraintIt complements the surgeon and never makes the call. Everything it surfaces traces back to the image it came from.

Objectives

  • Support planning and guidance from the imaging that already exists.
  • Keep every output traceable to the image it came from.
  • Leave the clinical decision, and the accountability for it, with the surgeon.

Built on AI Healthcare, a platform we own and operate rather than resell.

What we built

Computer vision over DICOM studies, surfacing measurements and structure to support preoperative planning and intraoperative guidance.

The boundary was drawn before the build rather than argued afterwards. The system presents; a person decides. Nothing it produces is a recommendation the practice cannot open up and check against the source image.

The AI healthcare platform, showing a clinical workspace with patient imaging alongside structured diagnostic information
AI Healthcare, the platform this engagement runs on. Screenshots on this site come from our public demo tenant on generated data, never from a client's live system.

What it does, in production.

  1. DICOM study ingestion

    Works from the imaging the practice already produces, in the format it already produces it in.

  2. Structure and measurement

    Computer vision over the study, surfacing what the plan depends on.

  3. Traceability

    Every output resolves back to the image and the region it was derived from.

  4. Preoperative planning

    Support for the plan the surgeon builds, not a plan generated in place of one.

  5. Intraoperative guidance

    The same record, available at the point the decision is actually made.

  6. Clinician in control

    No automated clinical decision, no silent override, no output the surgeon cannot dismiss.

The shape of the system.

A model belongs where the decision repeats, the data already exists, and being wrong is recoverable. Two of those three are true here and the third is not, which is precisely why the system stops at support and the human boundary is drawn in the architecture rather than in the interface copy.

The integration map, the data model and the deployment topology are covered in technical review under NDA rather than on a public page. The shape of the system is described here; the detail is a conversation, not a download.

How it was delivered.

The clinical constraint was settled first and the model followed from it. A system that reads an image and proposes an action is a different regulatory and engineering object from one that reads an image and shows a clinician what it found.

Architecture was written down and signed by a named engineer before the build. Release approval and production sign-off are people, not pipelines. See how we use AI in delivery.

Engineering challenges

Traceability as a hard requirement

A measurement a clinician cannot resolve back to a region of a specific image is not usable in this setting, whatever its accuracy. That requirement shapes the data model, not just the interface.

Knowing where the model stops

The hardest decision on this engagement was what the system would refuse to do. Deciding it up front is cheaper than discovering it in a review.

What changed.

  • Decision support the surgeon stays accountable for.
  • The system is in production and we are still the ones supporting it.

No accuracy figure, no sensitivity or specificity number, and no claim about clinical outcome appears on this page. Those are claims that need a study, a method and a date, and publishing one without all three would be the most damaging kind of overclaim available to a company working in healthcare.

TechnologyComputer vision · DICOM imaging pipeline · Traceable inference outputs · Human in the loop by architecture, not by policy
Service lineAI and Machine Learning Development

Engagements next to this one.

Public SectorMotijheel, Dhaka

Dhaka South City Corporation

End-to-end digitisation of parking operations, with real-time space utilisation and vehicle movement.

ChallengeKerbside parking in one of the busiest commercial districts in Dhaka ran on manual collection and no record of what was where.
ConstraintPeak is eight in the morning, and it had to work with the access control and payment already installed rather than replace it.
ResultA live record of the district kerbside.
StatusIn production
Read the case study

All case studies

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