Medical Imaging Software Development: 2026 Playbook

Why Fora Soft wrote this playbook

We have shipped HIPAA-adjacent healthcare and video software since 2005, across 250+ projects in telemedicine, clinical collaboration, medical training, and medical imaging. Our imaging work includes real-time AI that reads CT, MRI, ultrasound, and endoscopy feeds and wires into DICOM and PACS pipelines through our AI medical imaging development team. We built CirrusMED, a HIPAA-compliant telemedicine platform with secure video consults and clinical chat, and Cloud Doctors, an online medical advisory network with a built-in clinician workflow. Each lived under the same regulatory pressure a DICOM platform does: Business Associate Agreements, ePHI storage, audit logging, access control, and breach response.

This is what we would hand a CTO or product lead about to greenlight a medical imaging software development project in 2026. It swaps vague “HIPAA-compliant” marketing for the specific technical guardrails, vendor trade-offs, and cost shapes we see on real builds. We run AI integration and custom software development in-house, and we use agent-assisted engineering that compresses the scaffolding work. So our numbers sit below the 2024-era baselines in most market reports, and we keep them conservative on purpose.

Medical imaging software in 2026 — the market snapshot that matters

The medical imaging software market is tracking from about $8.75B in 2025 to $12.76B by 2030, a 7.84% CAGR (Mordor Intelligence, 2025). The AI slice inside it grows far faster — roughly 30%+ a year through 2030 by most house estimates — which is the number that matters when you build a business case. You are not pitching into a niche; you are pitching into the fastest-growing corner of healthcare software.

The regulatory signal is just as loud. As of March 2026 the FDA had authorized 1,524 AI-enabled medical devices, and 1,164 of them — about 76% — are in radiology (The Imaging Wire, 2026). In the first quarter of 2026 alone, 69 of 92 new authorizations were radiology. Clinical-grade imaging AI is no longer experimental; it is table stakes for anyone selling to hospitals, imaging centers, or teleradiology networks. A platform that cannot host or plug in AI reads as legacy on contact.

What HIPAA really requires in 2026 — and what is still just proposed

The current HIPAA Security Rule is still the one in force in 2026; the 2025 rewrite that would harden it is proposed, not final. HHS published the Notice of Proposed Rulemaking in January 2025, the comment window closed that March, and OCR is still working through roughly 4,745 comments. HHS has since moved final action to its long-term agenda with a 2027 target, and the new administration may soften or drop parts of it. Do not wait for it. The proposed controls are already how careful teams build, and OCR is already fining teams that skip them under the current rule.

What the proposed rule would make explicit

1. Encryption of all ePHI at rest and in transit. AES-256 at rest, TLS 1.3 in transit. The draft moves encryption from “addressable” to required. Every DICOM blob, every audit log, every column that carries a patient identifier is in scope.

2. Multi-factor authentication on every ePHI endpoint. The clinician web app, the radiologist workstation, the admin console, and any API client that can fetch a study. The draft names MFA explicitly, with narrow, documented exceptions for systems that technically cannot support it.

3. Current risk analysis and asset inventory. This one is not theoretical. OCR’s Risk Analysis Initiative has already produced a run of settlements against providers with no documented risk assessment. The draft would require the risk analysis, the asset inventory, and a network map to be current and signed off — not a PDF rotting in a forgotten wiki.

4. Tested incident response and fast restoration. The draft sets recovery-time expectations for critical systems (PACS and viewers usually qualify) and annual testing of the incident response plan.

5. Verified Business Associate controls. Every BAA-covered subcontractor — cloud provider, AI inference vendor, logging platform — would have to attest to its own compliance annually. “We have a BAA on file” stops being enough; you need a documented attestation chain.

DICOM is where ePHI actually hides

A DICOM file looks like an image, but its header carries dozens of patient identifiers, and a careless pipeline leaks them without ever touching the pixels. DICOM (Digital Imaging and Communications in Medicine) is the format every scanner speaks — CT, MRI, X-ray, ultrasound, pathology — and it is the format most often mishandled when PHI is on the line.

Figure 1. PHI lives in DICOM header tags and burned-in pixels; PS3.15 alone leaves three gaps, so de-identify in four passes.

What actually sits in a DICOM header

These are the tags a privacy engineer should worry about, roughly in priority order:

• (0010,0010) Patient Name
• (0010,0020) Patient ID / MRN
• (0010,0030) Patient Birth Date
• (0008,0020) Study Date
• (0008,0090) Referring Physician’s Name
• (0008,1070) Operator’s Name
• (0020,000D) Study Instance UID — often derived from the MRN at capture time
• (0008,0080) Institution Name
• Private tags (odd group numbers): vendor-specific, often carrying operator notes or IDs the vendor never documented
• Pixel burn-in: ultrasound and legacy X-ray machines frequently print the patient’s name and DOB directly into the image

The de-identification standard that still leaks

DICOM Part 15 (PS3.15) defines the Basic Application Level Confidentiality Profile, the baseline de-identification standard. It is necessary and not sufficient. It strips standard identifiers, but teams routinely keep private tags through the Retain Safe Private option, it cannot touch burned-in pixel text, and a reversible UID map still leaves a re-identification path. A production pipeline runs the profile first, then a private-tag sweep, then OCR-assisted pixel inspection for ultrasound and chest X-ray, then UID remapping with an irreversible hash. The standard itself is published by NEMA and worth reading in the current DICOM standard.

Reference architecture for a 2026 HIPAA imaging platform

The stack we deploy for most greenfield imaging builds is five cloud-native layers, each with one job and its own compliance controls, so no single component is load-bearing for compliance. That is defense in depth: a bug in one layer is an incident, not a breach, because the next layer still holds.

Figure 2. Five-layer reference stack — ingest, storage/VNA, metadata/FHIR, AI, and viewer, each under a signed BAA and audit-logged.

Our default greenfield stack is OHIF and Cornerstone.js on the front end, Orthanc or AWS HealthImaging as the archive, PostgreSQL plus a dedicated FHIR server (HAPI FHIR or Azure Health Data Services) for metadata and clinical context, and a thin Python / FastAPI AI layer running MONAI or third-party inference. That covers most of the functional surface of a commercial PACS at near-zero license cost, and it stays compliant because every layer sits inside a BAA-covered cloud footprint.

Choosing the cloud — AWS vs GCP vs Azure for medical imaging

All three major clouds sign a BAA and run a managed DICOMweb service, so the choice comes down to imaging archive economics, FHIR interoperability, and which cloud contract you already hold. None is universally best. The differences that matter show up in their managed imaging services and pricing shape, not in whether they can be made compliant.

Open-source building blocks you should not ignore

For most medical imaging software development projects the right move is neither “build from scratch” nor “license a closed PACS” — it is assembling production-grade open components and adding the AI, workflow, and compliance glue that is actually yours. Here is the shortlist we reach for.

OHIF Viewer (MIT)

A zero-footprint, browser-based DICOM viewer in React and TypeScript, extensible through modes, DICOMweb-native, and used across research and commercial deployments. The license is commercially permissive. For most projects it is a 6–8 week head start on a viewer that would take six months to build from Cornerstone.js alone.

Cornerstone.js (MIT) and dcmjs (MIT)

The JavaScript primitives OHIF sits on. Reach for them directly only when you need a bespoke viewer — a kiosk interface, a tumor-board review tool, or an embedded viewer inside a third-party EHR with strict UI constraints.

Orthanc and dcm4chee

Production DICOM servers and image managers. Orthanc is lighter, easy to run in Docker, and highly customizable through plugins and Lua scripts; it is GPLv3, so check the obligations before you redistribute a derivative. dcm4chee is the heavier, enterprise-grade Java option, open-source and already in production across many hospital systems. Both are proven; the pick is operational taste.

MONAI and TotalSegmentator

MONAI is the PyTorch framework for medical imaging AI. TotalSegmentator, built on the nnU-Net lineage, labels 117 anatomical structures in a whole-body CT in its version 2 release (2025) and runs in seconds per scan on a modern GPU. Either one replaces months of custom AI engineering when the job is segmentation. Neither is FDA-cleared, so treat them as tooling or decision support, not a primary diagnostic.

AI in medical imaging — what actually works in production

With 1,164 FDA-cleared radiology AI devices on the market, the question is no longer whether imaging AI works — it is which models you build, which you buy, and which you integrate. On most programs the answer is all three, segmented by use case.

Build when the model is your product

If the model is the thing users pay for — a proprietary pathology detector, a bespoke orthopedic measurement tool, a dataset-specific classifier — you build it. Budget heavily on data curation and clinical validation, often 40–60% of the AI program cost, and budget for the FDA pathway (De Novo, 510(k), or PMA) if you sell into US healthcare.

Integrate when the model is table stakes

Triage (Aidoc, Viz.ai), chest X-ray screening (Qure.ai), report drafting (Rad AI, Nuance PowerScribe), and bone-age assessment are commodity use cases where integration beats a rebuild. Integration usually runs $20K–$60K per vendor including the BAA, data routing, and UX polish — well under the $500K+ clinical validation bill for a home-grown equivalent. Our companion piece on AI software for medical imaging and video analysis goes deeper, and our AI medical imaging development team does this integration work in production.

Open-source when you need speed

TotalSegmentator, nnU-Net, MONAI bundles, and the Hugging Face medical-imaging zoo cover organ segmentation, landmarking, and measurement for most research and decision-support work. They are not FDA-cleared, so keep them as intermediate tooling or decision support, never a primary diagnostic.

DICOMweb and FHIR — the interop layer that prevents lock-in

Commit to open standards end to end: DICOMweb moves the images, FHIR R4 moves the orders, reports, and clinical context, and together they are what makes real EHR integration possible in 2026. Skip them and you are bolting imaging onto a healthcare stack with proprietary adapters, re-doing the integration for every hospital.

DICOMweb in three routes

QIDO-RS is query — “find every study for this patient since 2022.” WADO-RS is retrieve — “give me the pixel data for this series.” STOW-RS is store — “here is a new study.” Every serious viewer and every major cloud imaging service speaks all three. Building on DICOMweb instead of the older DIMSE / C-FIND protocol saves weeks of firewall and VPN work per customer deployment.

FHIR ImagingStudy and the clinical thread

FHIR R4’s ImagingStudy resource references the DICOMweb endpoints and ties an image to a Patient, Encounter, ServiceRequest, DiagnosticReport, and Observation. That is what lets your platform sit cleanly inside an Epic or Oracle Health workflow instead of re-doing integration work per site. SMART on FHIR gives you an OAuth-based launch in the clinician’s EHR context; learn how the same standards power video care in our telemedicine engineering guide.

Implementation roadmap — the 16-week build

A HIPAA-compliant imaging MVP takes about 16 weeks with a three-engineer pod (backend, frontend, DevOps plus compliance) and part-time PM and QA. Agent-assisted engineering compresses the timeline by roughly 30% on familiar ground.

Cost model — what a HIPAA imaging platform actually runs

A compliant imaging MVP lands at $35K–$65K, a full platform with AI and EHR at $180K–$450K, and third-party AI integration at $20K–$60K per vendor. The bands below are conservative for a Fora Soft engagement with agent-assisted engineering. Market averages run higher; a vendor quoting $80K+ for an MVP is usually building from scratch or carrying heavy offshore overhead.

Figure 3. Fora Soft cost bands with agent-assisted engineering; solid marks the low end, lighter the high end. Cloud infra is separate.

Cloud infrastructure lands on top. For a pilot with 10–50 TB of archive and moderate AI inference, expect $1,500–$4,500 a month on AWS HealthImaging or GCP Healthcare API. GPU inference is the wild card: a single always-on G5 / G6 instance runs $800–$1,800 a month, while serverless inference keeps costs to a few cents per study. Work an example: 30 TB archive at roughly $0.023/GB-month is about $700 in storage, add ~$1,000 for compute and retrieval, and a serverless AI job at 2 cents a study across 20,000 studies is $400 — call it $2,100 a month before support.

Mini-cases — CirrusMED and live imaging AI

CirrusMED is a HIPAA-compliant telemedicine platform we built for secure video consults, clinical chat, and a provider workflow for care coordination. It is not a DICOM viewer, but the regulatory spine is identical: ePHI, BAAs, encrypted media, audit logs, access control.

The lessons transfer directly. Do the audit logging early — every read of a patient record, every session joined, every admin action — because retrofitting logs after a customer’s first SOC 2 review always costs more than building them in the first sprint. Isolate tenants at the data store, not just the API: a bug in an API filter is an incident, but a row-level security rule in Postgres is a backstop. And make MFA mandatory for every role, including internal admin, because hospitals will ask and the answer needs to be “yes, already,” not “on the roadmap.”

Closer to pixels, our AI medical imaging work runs real-time inference on live surgical and endoscopy video and on CT, MRI, and ultrasound studies. The pattern repeats: custom-trained models (U-Net, EfficientNet, ResNet) behind a sub-500ms WebRTC pipeline, wired into DICOM/PACS and HL7/FHIR so findings land in the worklist and the report, not a side tool. On endoscopy that means polyp and lesion detection in the 90–95% sensitivity range; on radiology triage it means auto-prioritized worklists that help a department clear 2–3× more studies per shift and cut missed critical findings by up to 30%. Same compliance spine as CirrusMED, applied to pixels instead of a video call.

If you want the same 12-week assessment applied to your imaging program — what is compliant today, what would fail the proposed HIPAA bar, and what it costs to close the gap — book a call with Vadim and we will come prepared with a template.

Vendor options — when to buy, when to build

Buy a commercial PACS if you are a single hospital with standard workflow, integrate AI-first vendors if you already run a PACS, and build custom when the imaging workflow itself is your product. Enterprise PACS vendors (Sectra, Visage by Pro Medicus, Philips, Agfa, GE, Fujifilm) dominate the hospital market and quote seven-figure implementations. AI-first entrants (Aidoc, Qure.ai, Rad AI, Subtle Medical, Viz.ai) are SaaS, priced per study or per seat, plugging into an existing PACS. Custom development sits between and wins when your product is a workflow that does not exist off the shelf.

Buy commercial PACS when

You are a hospital with predictable imaging workflow, no product ambition, and you value support over flexibility. Sectra or Visage is a decade-proven pick.

Integrate AI-first vendors when

You already run a PACS and want triage, measurement, or reporting AI without replacing it. Budget $0.50–$5 per study for most AI services, plus $20K–$60K for the integration.

Build custom when

The imaging workflow is the product: teleradiology networks, cardiology review platforms, pathology slide review, veterinary imaging, clinical-trial imaging, longitudinal patient-portal viewers. Anything that is not a generic hospital PACS. This is the Fora Soft sweet spot.

A decision framework — build vs buy in five questions

Answer these five and the build-vs-buy call usually makes itself: differentiation, tenancy, proprietary AI, EHR posture, and lock-in tolerance. The tree below walks the first three; the last two break ties.

Figure 4. Take the first branch that fits: workflow as product, multi-tenant network, or proprietary AI all point to build; otherwise buy or integrate.

Q1. Is the imaging workflow differentiated or commodity? If it is how your users read, annotate, and share images, build. If it is a standard radiologist read, buy.

Q2. How many sites and tenants? One hospital points to buy. Five tenants or a network points to build; commercial per-seat pricing compounds badly past the first tenant.

Q3. Are you bringing proprietary AI? If yes, custom gives you a first-class place to host, version, and monitor the model. Commercial PACS treat AI as a second-class plug-in.

Q4. What is your EHR posture? If you must live inside Epic or Oracle Health as a native extension, FHIR-first custom wins. If you are a separate clinical product, either path works.

Q5. How allergic are you to lock-in? Every commercial PACS locks you into a proprietary data model and a five-to-ten-year migration problem. Open-standards custom stacks keep your data portable.

Five pitfalls that sink HIPAA imaging projects

1. Treating the BAA as a compliance guarantee. A signed BAA with AWS or GCP does not make your app HIPAA-compliant. Shared responsibility means you still own encryption configuration, access control, key rotation, and audit logging. OCR fines flow to you, not the cloud vendor.

2. Leaving DICOM metadata un-sanitized. The fastest way to trigger an unreported breach is to email a “de-identified” DICOM file that still has Patient Name in the header, or an ultrasound with the name burned into the pixels. Standardize de-identification before any export.

3. Audit logs as a write-only checkbox. Logs that are never queried, never alerted on, and never retained past 30 days fail both HIPAA and SOC 2. Stream logs to a separate, encrypted, immutable store and add alerts for admin actions, bulk exports, and after-hours access.

4. Mixing production ePHI into staging. Copying prod data into dev for testing is every engineer’s favorite shortcut and the fastest way to turn a laptop into a breach. Use publicly released, de-identified DICOM datasets (the Cancer Imaging Archive) or your own fully de-identified extracts.

5. Skipping the tabletop drill. Tabletops are cheap; breaches are not. Vision Upright MRI (21,778 patients, no risk analysis on file) is the textbook example of what happens when incident response is theoretical rather than tested.

KPIs — what to measure after go-live

Quality KPIs. Time-to-first-pixel in the viewer: target under 2s median for cached studies, under 6s for cold. Inter-site DICOM round-trip success: target above 99.5%. De-identification audit pass rate on exported studies: target 100%.

Business KPIs. Minutes-per-study for the radiologist: every 10% cut is typically worth $100K+ a year at scale. Storage cost per study per year: keep it under $0.25 with lifecycle policies. AI-assisted report turnaround: target 40–60% faster than the unassisted baseline.

Reliability KPIs. 99.95% monthly availability for the viewer, 99.9% for ingest. Recovery time objective under 4 hours, recovery point objective under 15 minutes. Audit-log pipeline SLA of 99.99%; if the log is down, policy should automatically pause high-risk operations.

When NOT to build a medical imaging platform

Do not build if you are a single-site hospital with no product ambition, if a cleared AI plug-in already solves your problem, or if you would need FDA 510(k) without a strategic moat. Buy Sectra, Visage, or a cloud-native PACS and implementation is faster with turnkey support. For a pure AI need, Aidoc for stroke and PE triage or Qure.ai for chest X-ray screening will save millions in clinical validation. And a $500K–$2M regulatory bill is only worth it when the AI is the differentiator, not a feature.

Breach patterns — what keeps costing radiology providers

The 2025 OCR settlements against imaging providers all trace to the same root cause: an unsecured PACS server and no documented risk analysis. Northeast Radiology settled for $350,000 in April 2025 after a breach that exposed ePHI for 298,532 patients and went undetected for about ten months — OCR’s sixth action under its Risk Analysis Initiative. Vision Upright MRI settled in May 2025 over an unsecured PACS server that exposed 21,778 patients; the monetary penalty was only $5,000 for the small provider, but it still came with a two-year corrective action plan and mandatory breach notifications.

The pattern is not sophisticated attackers. It is a PACS exposed to the internet, default credentials never rotated, and a risk analysis that was never done. The fix is operational discipline: infrastructure-as-code for cloud buckets, automated secrets rotation, mandatory encryption with KMS-managed keys, and a weekly configuration-drift check. None of it is expensive; all of it is routinely skipped. That is the whole argument for building compliance in from sprint one, because the extra engineering is cheap next to the corrective action plan, the notification bill, and the reputational hit.

Why Fora Soft for HIPAA medical imaging software development

We are a 50-engineer team that has shipped video, AI, and healthcare software since 2005, across 250+ projects. Our custom software development and AI integration practices have put production inference pipelines into healthcare, EdTech, and video streaming. Relevant healthcare work includes CirrusMED, Cloud Doctors, and MyOnCallDoc.

We use agent-assisted engineering on every project, which compresses scaffolding, QA, and documentation by roughly 30% on familiar ground — the reason our cost bands sit below the 2024-era industry averages. We also run a dedicated development team model for clients who need embedded engineers, and a product planning and analytics practice for greenfield programs that start with discovery rather than code.

FAQ

How long does HIPAA-compliant medical imaging software development take?

A compliance gap analysis runs 2–3 weeks. A functional MVP with a DICOM viewer, archive, OAuth with MFA, and audit logging lands in 10–16 weeks for a three-engineer pod. A full enterprise platform with AI and EHR integration is 9–14 months. Agent-assisted engineering compresses those numbers by roughly 30% on familiar ground.

How much does it cost to build medical imaging software?

A HIPAA-compliant MVP (viewer, archive, auth) runs about $35K–$65K, a full platform with AI and EHR sync $180K–$450K, and third-party AI integration $20K–$60K per vendor. Budget 15–25% of the build cost a year for maintenance and roughly $1,500–$4,500 a month of cloud for a 10–50 TB pilot. These are Fora Soft bands with agent-assisted engineering; market averages run higher.

Is AWS HealthImaging required to be HIPAA-compliant?

No. AWS HealthImaging is convenient at petabyte scale, but you can be fully HIPAA-compliant on GCP Healthcare API, Azure DICOM Service, or a self-hosted Orthanc on S3 with proper encryption, access controls, and audit logging. The compliance burden is on the customer in every case; the cloud just has to sign a BAA.

Can we use open-source components like OHIF Viewer in a commercial product?

Yes. OHIF Viewer, Cornerstone.js, and dcmjs are MIT-licensed and commercially permissive. Orthanc is GPLv3, which imposes obligations on derivative distributions, though most SaaS deployments avoid triggering them because the software runs on your own servers. Always run the exact licenses past counsel before shipping.

Do we need FDA clearance for a DICOM viewer?

It depends on intended use. A diagnostic viewer, one intended for clinical diagnosis, is a Class II device and needs 510(k) clearance. A review or secondary viewer, or a research tool, typically is not. Most commercial diagnostic viewers go through 510(k). Scope the clearance question with regulatory counsel at kickoff.

What is the difference between PACS, VNA, and a DICOM viewer?

A PACS (picture archiving and communication system) bundles storage, workflow, and viewing. A VNA (vendor-neutral archive) is storage only, built for multi-modality and multi-vendor input. A DICOM viewer is the client UI. Modern cloud-native builds tend to decompose the PACS into a VNA plus a decoupled viewer plus a workflow service, so each layer can evolve independently.

How do we integrate with Epic or Oracle Health (Cerner)?

Through FHIR. Both Epic and Oracle Health expose FHIR R4 APIs, and ImagingStudy plus DiagnosticReport are the resources you bind to. SMART on FHIR gives you an OAuth launch inside the clinician’s EHR context, and DICOMweb handles the image transport underneath. Plan 6–12 weeks for a production-grade Epic integration, including marketplace review.

Did the new HIPAA Security Rule take effect in 2026?

No. The rule that would strengthen the HIPAA Security Rule is still a proposal. HHS published the NPRM in January 2025 and has since pushed final action to a 2027 target, so the current Security Rule remains in force in 2026. Build to the proposed controls anyway — MFA, AES-256, TLS 1.3, and a current risk analysis — because OCR already enforces the underlying requirements.

Should we build our own AI models or integrate third-party?

Build only if the model is differentiated and central to your product. For commodity use cases — triage, chest X-ray screening, bone age, report drafting — third-party integration at $0.50–$5 per study is far cheaper than a $500K+ clinical validation program. Open-source (MONAI, TotalSegmentator) covers research and decision-support work without FDA clearance.

What to Read Next

Ready to ship a HIPAA medical imaging platform in 2026?

The 2026 playbook is clear. Build AES-256, TLS 1.3, MFA, a documented risk analysis, and a tested incident-response plan from the first sprint, even though the HIPAA rewrite is still proposed and slipping toward 2027 — that is where enforcement already sits. Lean on open standards, DICOMweb for images and FHIR R4 for clinical context, so your customers stay portable. Pick one BAA-signed cloud and let it own the heavy infrastructure, and keep your engineering budget on the AI, workflow, and UX layers that are actually yours.

Budget realistically: $35K–$65K for a compliant MVP, $180K–$450K for a full platform with AI and EHR, plus 15–25% a year for maintenance. Set that against the 2025 OCR settlements and the un-sanitized-DICOM breaches, and the math answers itself. If you want a second opinion on your roadmap — architecture, compliance bar, timeline, cost — we will run a 30-minute call and come back with a written plan.