A radiology department runs on two standards at once, DICOM for the image and HL7/FHIR for everything else, across three systems that all need to talk to each other correctly. Here's what that actually requires, and where Indian DICOM adoption still has real gaps.
Most hospital modules move text and numbers around — a vitals reading, a bed status, a bill line item. Radiology moves large binary image files that have to arrive intact, tagged with the correct patient and study metadata, and remain viewable years later on whatever workstation happens to open them. That's a fundamentally different technical problem, and it's why radiology has its own dedicated international standard rather than relying on general hospital data formats.
A filmless radiology department runs on three core systems that need genuine bidirectional communication, not a one-way handoff:
The imaging modality — a CT scanner, an MRI, an X-ray unit, an ultrasound machine — has to send images and patient demographic data to the PACS, and the PACS has to acknowledge receipt back to the modality. The RIS, which manages orders, scheduling and the reporting worklist, needs to talk to both. Every one of these connections is a place where a mismatch — a wrong patient ID, a dropped acknowledgment, an unsupported image format — turns into a scan that technically exists somewhere but that nobody can locate when it matters.
None of this is exotic engineering by 2026 standards, but it's also not automatic just because a hospital has bought "PACS software" and "a CT scanner" separately. The connection between the two has to be configured, tested, and maintained as equipment ages or gets replaced, and a hospital that treats this integration as a one-time setup task rather than an ongoing operational responsibility is the hospital most likely to discover a gap during an actual emergency, not during a calm afternoon test.
The Digital Imaging and Communications in Medicine standard traces back to 1985, when the American College of Radiology and the National Electrical Manufacturers Association jointly published the ACR-NEMA Standards Publication 300-1985, the first attempt at a common method for transmitting digital medical images and their associated data. Siemens Healthineers India's own technical reference on DICOM covers this history and the standard's current conformance framework in more depth. That early version didn't achieve real standardisation in practice; it took until 1993, when ACR-NEMA published Version 3 and renamed it DICOM, for the standard to actually deliver on its promise. Before DICOM existed, every piece of imaging equipment used proprietary formats, meaning a CT scanner from one manufacturer often couldn't produce an image any other manufacturer's workstation could read.
DICOM governs the image itself — format, storage, transfer, display — across radiology, cardiology, and increasingly dentistry and pathology wherever imaging is part of diagnosis. A technical breakdown of the DICOM/PACS relationship covers the practical distinction in more depth than a summary can. HL7, and its more modern FHIR variant, governs everything DICOM doesn't: patient demographics, orders, and the non-image clinical data that needs to move between the imaging system and the rest of the hospital's electronic health record. A mature radiology architecture uses both, in their separate, complementary roles — treating DICOM as the imaging-native layer and HL7/FHIR as the enterprise integration layer, not interchangeable options for the same job.
This distinction matters directly for ABDM compliance. A hospital's imaging data eventually needs to surface inside a patient's ABHA-linked health record, and that handoff happens through HL7 FHIR resources referencing the underlying DICOM study, not by treating the image file itself as the interoperable unit. Software that only speaks DICOM internally, with no FHIR-level export, has a real gap when it comes time to actually link imaging into the national digital health ecosystem.
A published survey of Indian oral and maxillofacial radiologists — a specialty that depends heavily on digital imaging — circulated 500 survey instruments and received 318 usable responses, representing roughly 22.7% of that specialty's population in India at the time. The full study is available through PubMed Central. The survey asked about current DICOM use, how long respondents had used it, which imaging modalities it covered, and how images were actually transferred and received in practice. The exact finding worth citing precisely rather than summarising loosely: this was a direct measurement of real-world DICOM awareness and adoption patterns among a working Indian radiology specialty, not a vendor's marketing claim about standards compliance.
The practical lesson for a tier-2/3 hospital evaluating radiology software: DICOM support isn't a settled, universal baseline across every piece of imaging equipment and software already in the Indian market. It's worth confirming explicitly, for your specific modalities, rather than assuming every system speaks the same DICOM dialect out of the box.
Part of why this gap persists is genuinely structural, not a matter of manufacturers ignoring the standard. DICOM defines conformance statements that specify exactly which parts of the standard a given device or software implements — a scanner can be fully DICOM-compliant while only supporting a subset of the storage, query, and print service classes DICOM defines. Two "DICOM-compliant" systems can therefore still fail to interoperate cleanly if their conformance statements don't overlap on the specific service classes both sides actually use. This is exactly the kind of detail a vendor's marketing slide flattens into a single reassuring checkbox, and exactly the kind of detail worth asking for in writing — the actual conformance statement document, not just a verbal assurance of "full DICOM support."
It's common for a hospital to end up with a PACS from one vendor and a RIS from another, integrated after the fact rather than designed together — and this is precisely where the worklist mismatch problem shows up most often in practice. A radiologist's reporting queue in the RIS is supposed to reflect exactly what's sitting in the PACS archive, ready to read. When these are separate products bolted together, a study can land in the PACS without triggering the corresponding worklist entry in the RIS, or a reporting status update in the RIS can fail to sync back to the PACS's own record of what's been read. Neither failure is dramatic on its own — a study just sits unreported a little longer than it should — but in a busy tier-2/3 radiology department running dozens of studies a day, "a little longer than it should" across enough studies becomes a real, systemic reporting delay that's genuinely hard to diagnose after the fact, because each individual system's logs look correct in isolation.
The Integrating the Healthcare Enterprise initiative, an industry effort separate from DICOM and HL7 themselves, exists specifically to define how systems like PACS and RIS should actually work together in practice, beyond just both claiming standards compliance individually. A vendor that can speak to IHE profiles specifically, not just DICOM and HL7 in the abstract, is signalling a more mature answer to exactly this integration problem.
A radiology archive isn't just a workflow tool for the day a scan is taken — it's a long-term clinical record, often the single most storage-intensive record type a hospital generates. A single CT study can run into hundreds of individual DICOM image instances; a hospital running meaningful imaging volume accumulates a genuinely large, growing archive that has to remain both accessible and intact for as long as the underlying medical record retention obligation requires. We've covered the general statutory retention picture in detail in our guide to medical records retention rules for Indian hospitals, and the same principle applies directly to imaging: a retention obligation on a patient's clinical record extends to the imaging studies tied to that record, not just the text-based chart notes.
This has a direct storage-architecture implication that's easy to underweight during initial vendor selection: a PACS system that performs well on day one, with a small initial archive, needs a real growth plan for what happens at year three or year five, once the archive has grown by an order of magnitude. Ask any vendor specifically how storage scales and what happens to retrieval speed for older studies as the archive grows, rather than assuming initial performance during a demo represents performance years into real use.
Not just receiving images — acknowledging receipt back to the scanner, so a technician knows a study actually reached the archive before the patient leaves.
A radiologist's reporting queue should reflect what's actually been received and is ready to read, not a separate list maintained by hand against what the PACS shows.
Imaging findings need to surface in a patient's ABHA-linked record through FHIR resources, not stay locked inside a DICOM-only silo.
Any facility running obstetric ultrasound needs Form F captured against the specific study, not as a separate paper process disconnected from the PACS record. We cover the full PC-PNDT compliance picture in PC-PNDT Act compliance for hospital ultrasound.
CT, X-ray and fluoroscopy fall under AERB licensing and safety requirements independent of the PACS question — see our guide to AERB radiation safety and hospital licensing.
OneCity's own Radiology (RIS/PACS) module, including its PACS & DICOM viewer and radiology reporting components, covers this workflow directly — this page is the standards and compliance context behind why each piece exists.
For a very large share of Indian tier-2/3 hospitals, radiology reporting outside standard daytime hours — nights, weekends, subspecialty reads — runs through a remote, teleradiology-based radiologist rather than an on-site one. That's not a workaround; it's the standard operating model, and it depends entirely on the PACS and DICOM infrastructure described above actually working, since a remote radiologist can only report a study that reached them intact and correctly tagged. We cover the specific legal and compliance requirements governing this arrangement — the Telemedicine Practice Guidelines, registration requirements, and record-keeping obligations — in teleradiology reporting compliance in India.
The technical requirement this creates is specific: a teleradiology setup needs a cloud-accessible PACS, or a properly configured VPN tunnel into an on-premises one, that a remote radiologist can reach securely without the hospital exposing its entire imaging archive to the open internet. Getting this wrong shows up as either a security gap or a reliability gap — a radiologist who can't reliably reach the archive at 2 AM on a genuine emergency case is a system that has technically satisfied the "teleradiology capable" checkbox without actually delivering the reliability the arrangement depends on.
A hospital group running imaging at more than one facility faces a specific architectural choice: a single, centralised PACS archive serving every site, or separate archives per facility with some mechanism to share studies across locations when a patient's imaging history needs to follow them. Centralisation makes cross-facility access to a patient's full imaging history straightforward, at the cost of every site depending on network connectivity to a central archive for day-to-day operations. Separate per-facility archives keep local operations independent of network reliability, at the cost of real friction when a patient who was imaged at one facility needs that history reviewed at another. Neither answer is universally correct; it depends on the group's actual network infrastructure and how often patients genuinely move between facilities. Our note on multi-location hospital ERP for chains and groups covers this same local-speed-versus-group-visibility tradeoff as it applies to bed management and OT scheduling, and the underlying logic transfers directly to imaging architecture.
Given how uneven DICOM implementation still is across Indian imaging equipment, confirm compatibility with your specific CT, MRI and ultrasound units before committing.
Order a test study and watch it appear correctly in the reporting queue, not just in the image archive.
If ABDM integration matters to your hospital, DICOM alone doesn't get you there — ask specifically about HL7 FHIR-level export.
If you rely on remote reporting for any shift, confirm the remote radiologist's workflow end to end, not just that images can technically be viewed off-site.
For the wider evaluation, our guide to choosing a hospital ERP for tier-2 and tier-3 hospitals covers the full checklist beyond this one module.
DICOM is the standard that governs how medical images are formatted and transmitted. PACS is the actual system — the archive and network — that stores, retrieves and displays those images using the DICOM standard. DICOM is the rulebook; PACS is the system that follows it.
Its roots trace to 1985, when the American College of Radiology and the National Electrical Manufacturers Association published ACR-NEMA Standards Publication 300-1985. Real standardisation didn't arrive until 1993, when Version 3 of the standard was published and renamed DICOM.
Not uniformly. A published survey of Indian oral and maxillofacial radiologists, covering roughly 22.7% of that specialty's population in India, measured real variation in DICOM use, duration of use, and transfer methods across respondents. DICOM support should be confirmed for specific equipment rather than assumed as a universal baseline.
DICOM handles imaging data specifically — image format, storage and transfer. HL7 and its modern FHIR standard handle non-image data: patient demographics, orders, and clinical information exchanged with the broader electronic health record. A complete radiology architecture needs both, used in their separate roles.
Imaging data reaches a patient's ABHA-linked health record through HL7 FHIR resources referencing the underlying DICOM study, not through DICOM alone. Software that only stores images in DICOM format without a FHIR-level export has a real gap for ABDM integration.
Yes, it's the standard operating model for a large share of hospitals, particularly for after-hours, weekend and subspecialty reporting. It depends entirely on PACS and DICOM infrastructure working correctly, since a remote radiologist can only report a study that arrives intact and correctly tagged.
Want a RIS-PACS worklist that actually reconciles, not two separate lists staff cross-check by hand?
Book a demo