Software for clinical decisions a person stays accountable for.

Computer vision over clinical imaging, built so that everything it surfaces traces back to the image it came from and the clinician still makes the call.

EvidenceSurgical decision support with an orthopaedic practice in Boston, reading DICOM studies for preoperative planning and intraoperative guidance.
OutcomeDecision support the surgeon stays accountable for, in production in Boston. No accuracy figure, sensitivity number or clinical outcome claim appears anywhere on this site, because those need a study, a method and a date, and we have not published one.

What is hard about this sector, before anybody writes software.

If a line below would still be true had we never worked in this sector, it is not specific enough to be on the page.

  • The imaging volume outgrew the reading time

    The studies arrive faster than they can be read carefully, and careful is the only setting that matters.

  • Consistency between clinicians

    Two competent people read the same study and plan slightly differently. That variance is invisible until somebody looks for it.

  • Nothing may be a black box

    A number a clinician cannot resolve back to a region of a specific image is not usable, whatever its accuracy.

  • Accountability does not transfer

    The clinician remains responsible for the outcome regardless of what the software said, so the software has to be designed around that fact rather than around it.

Capabilities, in the order they matter.

Computer vision over clinical imaging, supporting a decision a clinician makes and remains responsible for.

  1. Imaging pipelines

    DICOM ingestion from the equipment and systems the practice already runs, in the format they already produce.

  2. Computer vision

    Structure and measurement surfaced from the study, evaluated against a held-out set rather than against a demo.

  3. Traceability by design

    Every output resolves to the image and region it came from. This shapes the data model, not just the interface.

  4. The human boundary

    The system presents and a person decides. That line is in the architecture, signed before the build, not in a disclaimer at the bottom of a screen.

  5. Clinical workflow

    Fitting where the work already happens (preoperative planning and the point of care) rather than adding a system somebody has to remember to open.

  6. Access and audit

    Who saw what, when, and on whose authority, recorded because a clinical setting will eventually be asked.

What changes about security in this sector.

Clinical imaging is the most sensitive data this company touches, and the design assumption is that it never leaves 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, and our job is to build inside them and to tell you exactly what the system stores, what it transmits and to which third party, before the build rather than during your security review.

DevTechGuru holds no security or industry certification, and no page on this site claims one. Where a regime applies it is named as your obligation and as a design constraint we build inside. Ownership, handover and AI governance covers what a procurement reviewer usually asks next.

Technology

AI
LLMsRetrieval augmented generationComputer visionMachine learning
Backend
PythonDjangoFastAPINode.js
Cloud
AWSDockerCI/CDInfrastructure as code

Questions we get asked.

Questions this sector asks that the others do not.

Does the software make a clinical decision?

No. It presents what it found and a clinician decides. On the AvailOrtho engagement that boundary is in the architecture rather than in interface copy, which is the difference between a design constraint and a disclaimer.

Is DevTechGuru HIPAA certified?

No, and we will not say otherwise. HIPAA obligations sit with the covered entity. What we do is build inside them and tell you precisely what the system stores, what it transmits and to which third party, before the build.

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