AuraPACS stores every DICOM study on the on-premise node, indexed by patient, study and series so it can be found in seconds years later. An encrypted copy goes offsite through the cloud layer. Retention is on your own disks, planned for your modalities and volume.
The archive is the part of a PACS that keeps the DICOM files and the index that makes them findable. AuraPACS writes every received study to the on-premise node and records it by patient, study and series, so the front desk can search a name, a date or a modality and open the result. An encrypted copy of each study is sent offsite through the cloud layer.
Storage is not the same as a folder of files. A folder cannot tell you which of a patient's four studies is the follow-up, cannot serve a series to a browser viewer, and cannot show a radiologist the prior beside today's scan. The index does that, and the archive is the index plus the files it points to.
A scanner is not an archive, and a folder on a PC is not a backup.
Old studies are deleted from the CT to keep scanning. The only copy left is whatever the patient took home.
Exports sit in folders by month with no way to search by patient, so a prior is found by memory or not at all.
An on-premise server with no offsite backup loses the whole history to one hardware fault.
A provider holds the archive and bills for it monthly. Stop paying and access ends.
CT and mammography studies are large. A disk sized for the first year is full in the second.
How long studies must be kept is not written down, so nothing is ever deleted and nothing is ever verified.
The modality sends the study as DICOM to the node.
Patient, study, series and image records are written to the database.
Files land on the node's disks, on hardware you own.
An encrypted copy syncs offsite through the cloud layer.
The browser viewer reads the series from the node on request.
Search by name, ID, date or modality returns the study and its report.
Workflow: CT and MR studies are multi-slice and large; mammography images are large singles; X-ray is a few images; ultrasound is many small frames.
Result: A rough annual figure per modality, which is what the node's disk is sized against.
Workflow: Recent studies must be instant on the local network; older ones can be slower but must still be findable.
Result: A disk plan that keeps the working set fast without buying for ten years on day one.
Workflow: Decide how many years studies are kept and who may delete, then apply it to the archive.
Result: A policy your advisers can review, rather than an accident.
Workflow: Confirm that a study can be restored from the encrypted offsite copy before you need to.
Result: A backup that has been proven, not assumed.
Years of CT and MR that must stay findable.
Imaging for inpatients and OPD in one archive.
Serial rounds compared over years.
Images on hardware the centre bought, not rented.
A clear answer to where the files are and how they are backed up.
On the on-premise node, a machine on your own network. An encrypted backup copy is kept offsite through the AuraPACS cloud layer so a disk failure at the centre does not lose the archive.
It depends on modalities and daily volume. CT, MR and mammography studies are large; X-ray and ultrasound are smaller. The node is sized against your numbers on a call, and disk can be added as the archive grows.
Yes. Every study is indexed by patient, study and series, so a search by name, ID or date returns it with its report and it opens in the browser viewer. See PACS software.
You do. Retention is on your own hardware and under your policy. Health-record retention rules vary, so confirm the period that applies to you with your advisers and set the archive accordingly.
No. Cloud storage holds files; an archive indexes them, serves them to a viewer, keeps the report with the study and shows priors. See PACS vs cloud storage.
The encrypted offsite copy is used to restore the archive onto replacement hardware, and remote viewing of already-synced studies continues through the cloud layer while that happens.
Tell us how you work today. We will show you what the platform would look like for you, and give you a clear scope and timeline.
Founder-led · Chennai, India · Built and supported by the person who wrote it