What is the difference between a total outage and degraded mode?
A total outage is binary. Power is gone, the network is gone, and everyone knows to open the downtime binder. Degraded mode is the state that follows and lasts far longer: generator power on a schedule, a circuit that carries a fraction of its usual throughput, intermittent phone service, and a department that is technically open.
Total outage plans are common because they are easy to write. The building loses power, the plan says stop scheduling, run the emergency load, hold everything except what the emergency department needs, and document on paper. Nobody argues with it. Degraded mode is harder, because the department is still working and the pressure to behave normally is real. Studies keep being ordered. Patients keep arriving. The generator holds the scanner, but the plan never said whether it holds the archive, the interface engine, and the air conditioning in the server room at the same time. Write the load list down. If the facilities engineer knows it and the imaging manager does not, it is not a plan.
The second difference is duration. A total outage tends to be measured in hours. Degraded operation can run for weeks after the weather clears, because commercial power comes back in sections and the link carrying your images may depend on infrastructure somebody else repairs in somebody else's order. In Puerto Rico that is the ordinary planning assumption rather than the worst case, since grid and circuit interruptions happen outside storm weeks too. Plans written for hours are the wrong shape for weeks. Fuel deliveries, generator servicing, staff who cannot reach the building because a road is out, a technologist who has been on shift far longer than anyone intended: none of that shows up on the first night.
Name the state so that someone can declare it. A plan that describes degraded operation without giving it a name and a trigger cannot actually be invoked; the shift supervisor is left deciding at four in the morning whether things are bad enough to start doing something different, and different from what exactly. Give the condition a name, list what triggers it, say who declares it, say who ends it, and post it where the technologists work rather than in a binder in an administrative office. The declaration matters to the reading side too, because it tells them the queue they are watching is not going to behave the way it usually does.
What does reduced bandwidth actually do to image transfer?
It turns a queue that used to drain in the background into a queue that has to be managed by hand. Large studies occupy the circuit for long stretches; a single thin-slice CT can hold the line while an urgent chest radiograph sits behind it. Somebody has to decide the order, and that somebody should be named in advance.
Most routing is configured to send everything as soon as it exists, in whatever order it finished, because on a normal circuit that works and nobody has to think about it. Take the circuit down to a fraction of its capacity and the same configuration becomes the problem. Studies queue behind each other by accident of acquisition time. Automatic retries make it worse: a transfer that fails partway through starts over and consumes the same scarce capacity a second and a third time, and a badly tuned retry can occupy a link almost continuously while delivering nothing at all. The queue looks busy. Nothing is arriving.
Priority has to be settled in advance, because the decision is clinical and the people awake at three in the morning are not the ones who should be making it fresh. The ordering below is a starting point rather than a rule; what matters is that your version exists on paper and that the person who can act on it knows where it is. It also has to be actionable. If the priority list says emergency department work moves first, but the only way to make that happen is a vendor console nobody at the facility can log into, the list is a wish.
The awkward part is who holds the controls. At many facilities the queue, the routing rules, and the compression settings are administered by a vendor under a support contract, and the local team can watch the backlog without being able to touch it. During ordinary weeks that is fine. During a week when the vendor support line is answering slowly and your circuit is carrying a trickle, it is a single point of failure with a business relationship attached to it. Ask now, before the season, which of these settings a named person at the facility can change, and test that access by having them change something harmless.
- Studies for patients still in the building, ahead of anything for a patient who has already gone home.
- Emergency department and inpatient work ahead of scheduled outpatient work.
- The series the clinical question depends on, where the acquisition can be sent in parts.
- Report delivery back to the facility, which is small and often gets stuck behind image traffic in a badly ordered queue.
- Prior studies last. They are useful and they are heavy.
When does a facility fall back to local reading, and who decides?
When images cannot reach the reading environment within the time the clinical question allows and the study cannot wait. The fallback is a clinical decision made at the facility by a named role, not a technical decision made by whoever noticed the queue was stuck. Write the role into the plan, with a backup who is always available.
Local reading means a physician who is physically present reviews the images on the modality console or a local workstation and answers the immediate question. It is an old arrangement and it works, within limits. The console is not a diagnostic display, priors are usually unavailable, and the physician doing it may be an emergency physician rather than a radiologist. That can still be enough for the on-site team deciding whether a patient goes to the operating room tonight. None of it removes the need for the study to be formally interpreted once systems recover, and the record has to show plainly which document is which.
Who may invoke the fallback is the question plans get right. Who may end it is the question they leave blank. Facilities stay in fallback longer than they need to, sometimes days after the link recovered, because nobody was assigned to declare the situation over and nobody wants to be the person who called it too early. Put both roles in writing with named backups, and give the person ending it a short checklist: the queue draining, report delivery confirmed in both directions, alternate contact routes tested, and the reconciliation list started. Ending the state is also the moment the reconciliation work becomes visible, which is part of why people are slow to do it.
Privileging and licensure sit underneath all of this, and neither can be arranged in the middle of an event. Whether a particular physician may render an interpretation at a particular facility is a matter of that facility's medical staff process and the applicable licensure requirements, settled long before anyone needs it. The same is true of workstation credentials, remote access accounts, and door badges. Every facility that has been through a long outage has a story about a physician who was authorized in every sense that mattered clinically and could not log in.
What actually gets written down while the systems are down?
Less than the plan assumes. Downtime forms get filled in partially, identifiers are handwritten, and the record of which studies were performed lives on a clipboard at the front desk. This is the point where the archive starts to diverge from what actually happened, and almost nobody notices until reconciliation weeks later.
Here is what usually goes wrong, and it goes wrong in nearly the same sequence every time. The scanner is on generator power. The archive and the interface engine are on a different circuit, or the server room cooling was never on the generator at all, so those systems are down. Studies are acquired and stored on the modality. The worklist is unavailable, so the technologist types the patient information by hand. Nothing errors, because a modality accepts whatever is typed into it. Two studies for the same patient, acquired on two machines by two technologists on the same night, end up under two spellings and two temporary record numbers.
The paper log is what makes recovery possible, and a blank sheet will not produce it. Print the downtime log with the fields reconciliation will need, keep a stack with the forms rather than in a supply closet, and say in the plan who takes custody of the completed sheets at the end of each shift. The log itself is the next thing to go wrong. It gets left at a workstation, gets wet, or goes home in somebody's bag. Name one place the sheets go, and at the end of the event check that the number of sheets matches the number of shifts worked.
If a physician read a study on site, that reading has to exist as a document with a name and a time on it. Verbal only is the same problem the rest of radiology solved decades ago: it cannot be audited, it cannot be compared against the eventual formal report, and the clinician who acted on it has nothing to point to. A handwritten note on the downtime form, signed, is enough. Remembering it is not. Whatever form it takes, it needs to be identifiable later as a downtime reading rather than getting quietly absorbed into the chart as though it were a final report.
- The local study identifier the modality assigned.
- Exactly what was typed into the demographic fields, character for character, including any temporary record number.
- Acquisition date and time, and the technologist who performed the study.
- The order it belongs to, or a note that the order was given verbally and by whom.
- Whether the study was read on site, by which physician, and where that reading is written down.
- Whether the study has been transferred to the archive, with a space to mark the date the transfer was verified.
How does a study acquired during downtime get back into the archive correctly?
Somebody exports it from the modality or the local workstation, corrects the identifiers to match the permanent record, sends it to the archive, and then verifies that it arrived and is attached to the right patient and the right order. Each of those is a separate step with its own way of failing quietly.
The identifiers are the whole job. A DICOM study carries the patient name, the patient identifier, and the accession number as attributes set when the images were acquired, which during downtime means set to whatever was typed. Correcting them is a deliberate operation, done with a tool that logs the change, by someone permitted to do it. Editing fields by hand on the modality before export, with no log, is how a study ends up correctly labeled and untraceable. If the exported study no longer matches any line on the paper log, you have lost the ability to show which acquisition it was.
Reconciliation gets handed to IT and scheduled for after things settle down. That is the mistake, and it is close to universal. The people who can match a handwritten log line to an exported study are the technologists who were there, and their memory of that night is a perishable asset. Assign the work to someone who worked the downtime, pair them with whoever holds the archive permissions, and set the deadline in the plan rather than leaving it as a general intention. Studies that miss the first pass tend not to get a second one. They surface months later, when someone requests a comparison and finds nothing under the patient's record.
Then verify, study by study, against the log. Transferred is not the same as attached to the right record, and a study can arrive in the archive under a temporary identifier and sit there indefinitely without generating a single alert. Mark each log line when the study has been confirmed under the permanent record and linked to its order. Watch for the duplicate read: a study already interpreted on site, transferred later, then picked up by a normal worklist as though it were new. Two interpretations of one acquisition in the same chart, written days apart with different information available, is a conversation nobody enjoys.
What belongs in the agreement before the season rather than during it?
The parts that need somebody's signature: who declares degraded operation and how the other party is told, what the transfer priority is, what happens to studies already in the queue, and what each side owes on reconciliation. None of that gets settled by email during an event. These are points to raise with your own counsel, not language to copy.
A plan that has never been run is a document, not a capability. Testing does not take an elaborate exercise. Pick a quiet weekday, tell everyone, disconnect the primary route for a defined window, and watch what people actually do. The useful part is never the failover link. It is whether the technologist on shift can find the downtime forms, and whether the alternate contact number reaches a person or a voicemail box set up by somebody who has since left. Check the local workstation account while you are there. It has to still work after months of nobody logging into it. Contact routes fail together, so rehearse those too. A directory that lives in email is not a directory during a connectivity loss. A phone tree that depends on one carrier depends on one carrier.
The agreement is where the arguments get settled in advance, and there is a date attached. The Atlantic hurricane season runs from June 1 through November 30 every year, so planning before the season has an actual date behind it. Put in the agreement how each party tells the other that degraded operation has been declared and how that notice is confirmed, what the transfer priority is and who may change it, what happens to studies already in the queue when the state begins, which alternate contact routes both sides will maintain, what each side owes on reconciliation and by when, and what the facility is expected to handle locally on its own. Write it while the weather is fine and everyone is reasonable. The version negotiated during an event is worse, and it is negotiated by tired people.
Sources and scope
- DICOM Standards Committee, Digital Imaging and Communications in Medicine standard
- IHE International, profiles for imaging workflow and patient information reconciliation
- American College of Radiology, practice guidance on teleradiology and on communication of diagnostic imaging findings
- HL7 International, standards for order and result messaging between clinical systems
- The Joint Commission, standards on emergency management and on continuity of information management processes