Medical Imaging Software Development: DICOM, PACS Integration, AI and FDA Scope
Key Takeaways
- Medical imaging software development ranges from $60K for a web DICOM viewer to $300K–800K+ for AI analysis software headed for FDA clearance, before clinical validation costs.
- Once software analyzes medical images, FDA’s clinical decision support exemption no longer applies, so image analysis tools are regulated devices in almost every case.
- Build on DICOMweb (QIDO-RS, WADO-RS, STOW-RS) and open-source foundations like Orthanc, OHIF Viewer, and MONAI rather than writing a viewer or archive from scratch.
- Burned-in patient text inside pixel data is the de-identification failure most teams miss; header scrubbing alone doesn’t meet HIPAA Safe Harbor.
- Audit trails, version-locked algorithms, and a traceable intended use statement are what make an imaging app “auditable” when a regulator or hospital security team asks.
Consider this scenario. A physician uploads a scan, the software returns a report, and the team that built it asks one question: “Is this compliant?” We hear of this in many medical imaging projects, more often after the product is already working. It’s the right question, but it is being asked late.Â
In medical imaging, the answer depends on decisions made in the first weeks of the build. This includes what the software claims to do, how images enter the system, and what happens to them afterward.
Medical imaging software development includes viewers, archives, workflow tools, integrations with hospital PACS, and AI models that detect, measure or triage findings. Each of these carries different regulatory weight. Tech Exactly’s medical device software work runs under IEC 62304 processes. The FDA pathway questions for imaging overlap heavily with the broader medical device software development costs and timelines most teams underestimate.
This guide explains the imaging standards to use, how to choose the right setup for viewers and archives, where AI fits in, how to make the product auditable, and what each level costs.
What Does Medical Imaging Software Include?
Medical imaging software is any application that acquires, stores, transmits, displays, processes or analyzes medical images such as X-ray, CT, MRI, ultrasound, mammography, nuclear medicine or digital pathology slides.
| Category | Examples | Typical regulatory weight |
|---|---|---|
| Archive and exchange | PACS, vendor neutral archive (VNA), image sharing portals | Lower when limited to storage and transfer |
| Viewing | Diagnostic viewers, referral and patient viewers, mobile viewers | Diagnostic viewers are regulated devices |
| Workflow | Worklists, reporting tools, peer review, teleradiology routing | Varies with clinical function |
| Processing and analysis | Segmentation, measurement, 3D reconstruction, quantification | Regulated devices |
| AI detection and triage | CADe, CADx, triage and prioritization tools | Regulated devices, usually Class II |
Most startups use a combination of two or three of these. For example, a remote reading platform needs an archive, a diagnostic viewer, a worklist, and a reporting tool. This combination decides your compliance scope, so write it down before writing code.
Which Standards Does DICOM Software Development Rely On?
DICOM (Digital Imaging and Communications in Medicine) is the standard for medical image files and the network services that move them. The full specification is published by NEMA on the DICOM standard site, and every serious imaging product depends on it.
What DICOM software development involves in practice:
- DICOM objects and metadata. Each file carries patient, study, series and instance identifiers plus modality-specific tags. Parsing is easy with libraries like pydicom or dcmtk. Handling vendor quirks and private tags is where time goes.
- Classic DICOM networking (DIMSE). C-STORE, C-FIND, C-MOVE and Modality Worklist are still how many hospital PACS and scanners communicate.
- DICOMweb. QIDO-RS for search, WADO-RS for retrieval and STOW-RS for upload over HTTPS. New products should expose and consume DICOMweb wherever possible.
- HL7 and FHIR for orders and results. Orders usually arrive as HL7 v2 ORM messages and reports go back as ORU messages, with FHIR ImagingStudy and DiagnosticReport resources growing in use. The tradeoffs are the same ones covered in HL7 vs FHIR for other clinical data.
- IHE profiles. Scheduled Workflow (SWF), Invoke Image Display (IID) and AI Results (AIR) describe how systems should cooperate, and hospital IT teams often ask whether you follow them.
How Should PACS Software Development and DICOM Viewer Development Be Approached?
Very few teams need to build a PACS or DICOM viewer from scratch. There are mature open-source and cloud components that already handle much of the complex work. Your engineering budget is usually better spent on the clinical workflow that makes your product different.
Archive options
- Orthanc: lightweight open-source DICOM server with a REST API and DICOMweb plugin, good for startups and edge deployments.
- dcm4chee-arc: full open-source archive used in hospital-scale deployments.
- Cloud DICOM stores: AWS HealthImaging, Google Cloud Healthcare API and Azure Health Data Services DICOM service offer managed storage with DICOMweb endpoints and sign BAAs.
Viewer options
- OHIF Viewer: open-source, web-based, built on Cornerstone3D, with support for measurements, segmentation display and hanging protocols. Most custom DICOM viewer projects we’d recommend start as an OHIF extension.
- Cornerstone3D directly: for embedded viewers inside your own application.
- Commercial SDKs: when you need FDA-cleared diagnostic viewing without taking on that clearance yourself.
Using the OHIF viewer can save months of development time, but you also have to keep up with its updates. Pin your versions, keep your extensions separate from the core code, and set aside time for upgrades. For browser-heavy products, a team with web app development experience in WebGL rendering and large file streaming matters more than general imaging knowledge.
Performance
CT and MRI studies can contain hundreds or even thousands of images. Load them progressively, starting with lower resolution images. Use HTJ2K or JPEG 2000 where supported, cache images close to users, and test performance on real hospital network speeds instead of your office connection.Â
A cloud healthcare computing setup with regional storage and CDN caching of de-identified data keeps viewer load times acceptable.
Where Does AI Medical Imaging Fit, and What Does It Take?
AI medical imaging is the most active area in medical device AI. Radiology accounts for roughly three-quarters of the devices on FDA’s AI-enabled medical device list. This also gives you a working view of what competitors have cleared.
Radiology AI software development follows a different path from most AI features:
- Define the intended use first. “Measures lesion diameter on chest CT for review by a radiologist” and “detects lung nodules” are different products with different evidence requirements.
- Assemble representative data. Multiple sites, scanner manufacturers, protocols, and patient populations. Single-site models fail in the field.
- Label with clinical experts. Budget for board-certified readers and inter-reader agreement measurement.
- Train with established tools. MONAI (PyTorch-based, backed by NVIDIA and King’s College London), nnU-Net for segmentation, and SimpleITK for preprocessing are common starting points.
- Validate on held-out sites. Report sensitivity, specificity, and performance by subgroup.
- Lock and version the model. Every deployed model version needs traceability to its training data and validation results. FDA’s final guidance on predetermined change control plans (PCCPs) sets out how pre-authorized model updates can work.
An experienced AI app development company can build the pipeline and product around a model. However, the clinical validation study is its own project with its own budget and clinical partners. Treat it this way from the start.
When Does Medical Image Analysis Software Need FDA Clearance?
Image analysis software needs clearance in nearly every case where it serves a clinical purpose. FDA’s clinical decision support guidance, which was reissued in January 2026, excludes software intended to acquire, process, or analyze medical images from the non-device CDS category.
So an app that takes uploaded scans and produces analytical reports for physicians is very likely to be considered a device, regardless of whether a physician reviews the output.
Where software lands:
- Storage and transfer only. The lightest oversight, similar to other data-handling software.
- Viewing, processing, and measurement. Generally Class II under medical image management and processing systems (21 CFR 892.2050), usually requiring a 510(k).
- Detection, diagnosis, and triage. Class II computer-assisted detection, diagnosis, and triage classifications, with 510(k) or De Novo depending on predicates.
Pathway selection and predicate searches should be handled as part of a regulatory plan through a qualified consultant.
For engineering, ensure your intended use statement strictly matches both the UI and marketing claims. Teams must also follow design controls under the Quality Management System Regulation (QMSR, aligned with ISO 13485), manage risk under ISO 14971, and maintain required cybersecurity documentation—including an SBOM under Section 524B of the FD&C Act.
A team already running an IEC 62304-compliant development process will produce most of this documentation as a by-product of normal work.
How Do You Make Medical Imaging Software Secure and Auditable?
For imaging software to be auditable, you should be able to track who accessed a study, what happened to the image, and which algorithm version produced the final result. Hospitals ask for this in security reviews, and FDA expects it in design history files.
- Immutable audit logs for every view, upload, download, share and report, with user, timestamp, study UID and source IP.
- Algorithm provenance on every output: model version, input series, processing parameters and timestamp stored alongside the report.
- De-identification at the pixel level. Header scrubbing following the DICOM PS3.15 confidentiality profiles is necessary but not enough. Ultrasound, screenshots and secondary captures often carry burned-in names and dates in the image. Use OCR-based detection and masking, then verify with human review on a sample. The same principles apply as for any data de-identification for healthcare AI pipeline.
- Access control by role and relationship. A referring physician should see their patients’ studies, not the whole archive database.
- Encryption in transit and at rest, signed URLs with short expiry for image retrieval and BAAs with every cloud vendor.
- Threat modeling for DICOM endpoints, which are frequently exposed to the internet by mistake. Put DICOM ports and DICOMweb endpoints inside the same security architecture for healthcare apps that protects the rest of your PHI.
A HIPAA-compliant software development process covers the privacy side. The FDA side needs the design controls above on top.
How Do You Choose a Medical Imaging Software Development Partner?
Ask any partner the questions below before you sign:
- Which DICOM toolkits and archives have you shipped with, and how did you handle vendor-specific private tags?
- Have you integrated with a hospital PACS over DIMSE and DICOMweb, and who ran the hospital-side testing?
- What does your design history file look like, and can you show a redacted example?
- How do you version and trace models from training data to deployed output?
- Who on your side reviews de-identification, and how do you test for burned-in text?
A partner should also be clear about what they haven’t worked on. Tech Exactly hasn’t built or cleared a radiology AI product. Our closest work is an IEC 62304-compliant mobile app for test interpretation, a Safety Class B app that uses OpenCV image processing to read home test kits from phone photos, with capture guidance that rejects poor-quality images before analysis.
The same approach to image quality, documentation, and traceability can be applied to imaging products. Clinical partners and reviewers bring the medical knowledge needed for labeling and validation.
How Much Does Medical Imaging Software Development Cost?
Below are illustrative planning ranges for engineering work. The actual quotes highly depend on integrations, clinical requirements, and delivery assumptions. Clinical validation studies, regulatory consultants, and FDA user fees are separate.
| Build | Scope | Planning estimate | Timeline |
|---|---|---|---|
| Image sharing portal or non-diagnostic viewer | Upload, DICOMweb archive, OHIF-based viewer, sharing, audit logs | $60K–150K | 3–5 months |
| Clinical imaging workflow product | Diagnostic viewing, PACS and HL7 integration, worklists, reporting, measurement tools | $150K–300K | 6–10 months |
| AI analysis software toward FDA clearance | Data pipeline, model training infrastructure, inference service, locked versions, design controls, 62304 documentation | $300K–800K and above | 12–24 months |
Cloud storage and egress are substantial ongoing costs for imaging. A single CT study can exceed 500 MB, so plan your storage tiers and retention rules before launch.
Frequently Asked Questions
A non-diagnostic DICOM viewer or image sharing portal costs around 60K–150K. A clinical imaging workflow product with PACS integration runs 150K–300K, and AI analysis software headed for FDA clearance typically costs 300K–800K or more before clinical validation.
In most cases, yes it does. Software that processes or analyzes medical images for a clinical purpose is a medical device and is not eligible for the non-device clinical decision support exemption. Most imaging software is cleared through 510(k) clearance.
OHIF Viewer is the most widely used open-source web DICOM viewer and a common base for custom products. Weasis and 3D Slicer are popular desktop alternatives.
DICOMweb is the RESTful part of the DICOM standard. It specifies QIDO-RS for searching studies, WADO-RS for retrieving images and STOW-RS for storing them over HTTPS.
Yes, you can. AWS HealthImaging, Google Cloud Healthcare API, and Azure Health Data Services all provide DICOM storage with DICOMweb endpoints and will sign a business associate agreement.
A viewer or sharing portal takes 3 to 5 months, a clinical workflow product takes around 6 to 10 months, and AI analysis software for FDA submission takes 12 to 24 months, including design controls.
