Challenge
Accuracy drops on images from a different scanner vendor or protocol.
Agnotic approach
Datasets are sampled across vendors, models and protocols, and results are reported per subgroup.
Medical Image Analysis Software
Medical image analysis software development
A model that segments or measures images in a notebook is not yet software a radiologist can use. Agnotic Technologies builds medical image analysis software that returns results as DICOM objects the reading workflow can store, trained on de-identified, well-labelled data and scoped to the claim you intend to make.
DICOM SEG and SRGround truth pipelinesPS3.15 de-identification21 CFR 892 claim mapping
Trusted by global innovators
Quantitative imaging
What is medical image analysis software?
Medical image analysis software measures, segments, detects or quantifies findings in CT, MRI, X-ray, ultrasound and other medical images, and returns the results in a form clinical systems can store and display. Agnotic Technologies builds this image analysis software for imaging startups, device makers and hospital research teams.
The algorithm is only part of the product. The rest is getting images in, writing results back as standard DICOM objects, building the labelled data the algorithm learns from, and documenting what it was tested on.
Storage, viewers and image transport are separate builds, covered on our medical imaging PACS and DICOM integration pages. This page is about the analysis layer and the evidence behind it.
Output objects
Which DICOM object does each type of analysis write back?
Results written as standard DICOM objects can be stored next to the source study and shown in existing viewers, instead of living in a separate app.
| Code | Name | Typical use |
|---|---|---|
| DICOM SEG | Segmentation | Labelled regions such as an organ, tumour or vessel, stored as binary, fractional or label map frames that reference the source images |
| SR TID 1500 | Measurement | Lengths, areas, volumes and derived values in a Measurement Report, each tied to the region and image it was taken from |
| SR TID 1500 | Detection | Findings with their location and tracking ID, so a viewer can list them and jump to each one |
| Parametric Map | Quantification | Per-pixel real-world values, such as perfusion or diffusion parameters, stored as an image the viewer can overlay |
| Secondary Capture | Fallback display | A rendered image for viewers that cannot display SEG or SR, never the only copy of the result |
Claim to classification
Which FDA classification fits what your software claims?
The claim you make decides the regulation, and the regulation decides what the validation study must show. This table is a planning aid for the conversation with your regulatory advisors, not a regulatory determination.
| What the software claims | 21 CFR section | Output it writes back | What the validation must show |
|---|---|---|---|
| Displays, processes and measures images for a trained practitioner to interpret | 892.2050, medical image management and processing system | Segmentations and semi-automated measurements (SEG, SR) | Measurement accuracy against reference values and correct handling of DICOM inputs |
| Marks parts of an image that may show an abnormality during the read | 892.2070, medical image analyzer (CADe) | Marks or regions with locations (SR, SEG) | Standalone performance and whether readers perform better with the device, by relevant subgroup |
| Flags time-sensitive studies and notifies clinicians, without marking the image | 892.2080, computer aided triage and notification | A notification and worklist priority, not image marks | Effective triage, such as faster time to review for prioritized studies |
| Characterizes a lesion as suspicious for cancer | 892.2060, computer-assisted diagnostic software | A characterization for each lesion (SR) | Improved reader performance and standalone performance in the intended population |
| Detects, locates and characterizes findings such as fractures | 892.2090, computer-assisted detection and diagnosis | Findings with locations and characteristics (SR, SEG) | Standalone testing including localization accuracy, plus assisted-read performance |
A research tool that makes no clinical claim may sit outside these sections, but its output must then be labelled for research use and kept out of clinical reports.
Ground truth
How do we build the annotation and ground truth pipeline?
The labels an algorithm learns from and is tested against decide what its results are worth.
Write the labelling protocol
What counts as the structure or finding, on which series, at which window settings, and what to do with unclear cases.
De-identify before export
Images are de-identified inside the hospital using a DICOM PS3.15 Annex E profile, and pixels are checked for burned-in text before anything leaves.
Annotate with qualified readers
Each case is labelled by more than one qualified reader working independently, in an annotation tool that writes DICOM SEG or SR.
Measure reader agreement
Agreement between readers is measured per case, and cases below the agreed threshold go to adjudication.
Adjudicate
A senior reader resolves disagreements, and the decision and its reason are recorded with the case.
Freeze and version the datasets
Training, tuning and test sets are split by patient and site, versioned, and the test set is locked before final testing.
Failure points
Why do image analysis models fail after they leave the lab?
Problems we design against from the first sprint.
Challenge
The same patient appears in training and test data.
Agnotic approach
Splits are made by patient and by site, checked automatically before every training run.
Challenge
Patient details survive in private tags or burned into pixels.
Agnotic approach
De-identification covers private attributes and runs a pixel check, with failed studies held back.
Challenge
Segmentations do not line up with the source images in the viewer.
Agnotic approach
Every SEG object keeps the Frame of Reference and source image references, tested in the viewers your users run.
Challenge
Nobody can say which model version produced a result.
Agnotic approach
Each output records the algorithm name and version, and every release has its own test report.
Challenge
Results arrive after the radiologist has finished the read.
Agnotic approach
Processing time is measured on realistic study sizes, and the result routing is agreed with the reading team.
Research or clinical
Research use or clinical use: what changes?
Many image analysis products start as research tools. Planning for the clinical version from the start saves rework later.
- A research use only build can run on retrospective, de-identified data without a clinical claim, but its output stays out of patient reports
- A clinical build needs a written intended use, a claim and the matching 21 CFR section agreed with your regulatory advisors
- Clinical builds need requirements, risk analysis, traceability and test records produced during development, not rebuilt afterwards
- Datasets used in research can only support a clinical submission if their labelling protocol and provenance were recorded
- Clinical builds need version control of the model and its training data, so every result can be traced to a release
- We design the research build so the same pipeline, outputs and records carry over to the clinical one
How does the result reach the radiologist?
The analysis service receives studies from the PACS or a router, processes them and sends the SEG, SR or parametric map back to be stored with the original study. The radiologist opens the results in the viewer they already use.
Transport, worklists and DICOMweb are covered on our DICOM and PACS integration page. Worklist triage and radiologist notification are covered on our diagnostic imaging AI page.
For pathology slides, the same principles apply with whole slide images, which are covered on our digital pathology page.
What sizes this build
What drives the cost of image analysis software?
We do not publish prices or use a calculator. These are the inputs we size an image analysis build from on the scoping call.
Modalities and body regions
Each modality, body region and protocol adds data to collect, label and test.
Study volume and size
How many studies per day the service must process and how large they are, which sets compute and storage needs.
Analysis type
Measurement, segmentation, detection or quantification, and whether results need a reader in the loop.
Ground truth effort
How many cases need labels, how many readers per case and how specialized the readers must be.
Model validation
Whether the build is research use only or needs a validation study shaped by a clinical claim.
PACS and viewer integration
Which archives, routers and viewers must receive and display the results.
Who it is for
Who builds image analysis software with us?
Teams that have the clinical idea or the algorithm and need the software, data and evidence around it.
Image analysis software for startups
Founders with an algorithm or a clinical question who need a product that runs on real hospital data.
Medical device makers
Companies adding analysis features to scanners, ultrasound systems or imaging software.
Hospital research groups
Radiology and research teams turning an internal model into a tool other sites can run.
Orthopedic and specialty practices
Specialties that measure anatomy on images every day, such as alignment, joint space or bone density.
Clinical trial imaging teams
Teams that need consistent, repeatable measurements across sites and timepoints.
Engagement
How does an image analysis engagement work?
From the claim you want to make to software running on real studies.
1.
Scoping call
We agree the clinical question, the intended claim, the modalities and the data you can access.
Scope2.
Data and labelling plan
We set up de-identification, the labelling protocol and the dataset splits with your clinical team.
Data3.
Fixed-scope first release
We build the analysis service with DICOM inputs and outputs, tested on a locked dataset, with test records kept as we go.
Build4.
Scale and support
We add sites, modalities or a clinical validation study, and support the software in production.
ScaleStandards
Standards our image analysis software follows
The DICOM parts and FDA regulations the outputs and evidence are built to.
DICOM SEGDICOM SRParametric MapPS3.15 Annex E21 CFR 892
Facts and sources
Facts behind medical image analysis software
The FDA classifications and DICOM parts that shape the outputs and evidence, each linked to its primary source.
21 CFR 892.2050 classifies medical image management and processing systems as Class II, and names image segmentation, multimodality image registration and semi-automated measurements among their advanced processing functions.
Source: 21 CFR 892.2050 (eCFR)21 CFR 892.2070 describes a medical image analyzer (CADe) as a device that marks or highlights parts of a radiology image that may reveal abnormalities, and states it is not intended for triage or to recommend a diagnosis.
Source: 21 CFR 892.2070 (eCFR)For radiological computer-assisted detection and diagnosis software, 21 CFR 892.2090 requires standalone performance testing, and a device with localization output must include localization accuracy testing.
Source: 21 CFR 892.2090 (eCFR)The DICOM Segmentation IOD stores a classification of pixels in one or more referenced images, and a segmentation can be binary, fractional or a label map.
Source: DICOM PS3.3, A.51 Segmentation IOD (NEMA)DICOM PS3.15 Annex E defines Attribute Confidentiality Profiles for removing or replacing identifying attributes, and notes that de-identifying the attributes does not by itself de-identify the whole object.
Source: DICOM PS3.15, Annex E Attribute Confidentiality Profiles (NEMA)
Compliance-First Healthcare App Development Services Backed by Global Standards
01
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
02
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
03
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
04
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
05
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
06
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
07
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
08
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
09
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Frequently Asked Questions
We do not publish a price or use a calculator. Cost follows the modalities, study volume, analysis type, labelling effort, the validation the claim needs and the PACS and viewers to integrate. You get a written proposal after the scoping call.
It depends most on data access and labelling, so we agree a fixed first release once the data plan is clear. The software can be built while labelling is under way, against a small locked test set.
Yes. Results are written as DICOM SEG, SR or parametric map objects that are stored with the original study, and we test them in the viewers your radiologists use. Transport and routing follow our DICOM and PACS integration work.
Either. We can train and test the model with your clinical team, or take a model you already have and build the data pipeline, DICOM outputs, versioning and test records around it.
That depends on what it claims. Software that measures, marks findings, triages or characterizes lesions for clinical use usually falls under a 21 CFR 892 classification. Your regulatory advisors make the determination; we build the documentation and evidence it needs.
Yes. Whole slide images need their own storage and viewing approach, covered on our digital pathology page. The labelling, de-identification and validation practices on this page apply to slides as well.
Engineers may use AI coding assistants for routine code, but DICOM output, de-identification and dataset split code is written and reviewed by an engineer and tested against reference studies. Nothing reaches your main branch without code review.