Published by Shaun Behrens
Last updated on July 23, 2026
•
9 minute read
In a previous post, we looked at the DICOM and HL7 sensors built into PRTG, used to monitor parts of a hospital's infrastructure such as the Picture Archiving and Communication System (PACS) or the interfaces moving patient details between departments. But interfaces and systems don't run in isolation. What you really want, as the IT admin holding it all together, is the big picture: what is the status of entire clinical workflows, from patient registration through to diagnosis?
That question has only gotten harder to answer. Hospitals now run on a patchwork of EHR systems, EMR platforms, appointment scheduling tools, and some flavor of healthcare workflow automation humming in the background: RPA chewing through repetitive data entry, machine learning feeding clinical decision support, AI nudging patient scheduling and flagging patients at higher risk of readmissions. All of it promises less administrative burden and fewer human errors. None of that changes what keeps the lights on underneath, though: a mesh of interfaces and network links, and if one breaks, the automation on top breaks with it.
This is where PRTG fits in, not as a replacement for any clinical tool, but as the infrastructure and interface monitoring layer telling you whether the systems behind patient registration, patient intake, and daily clinical workflows are actually up and talking to each other.
PRTG Network Monitor provides a Business Process Sensor to help with this, but how exactly does it work?
A Typical Hospital Workflow
To demonstrate, it helps to walk through a specific example. A patient, let's call him Flynn, fell badly while playing football last week, and his right arm has been hurting ever since. His doctor sent him to the local hospital to get checked out. Take a look at the graphic below for a simplified version of Flynn's patient journey, then we'll get into the technology behind it, and what has to work for Flynn's patient journey is not interrupted.
Flynn registers at reception, then goes through to the doctor. By the time he sits down, his details are already in front of the doctor, usually through a web interface tied to the EHR. The doctor books an MRI scan. Flynn gets scanned, the images land in the PACS, and the doctor pulls them up to figure out what's going on with that arm.
Behind each of these steps, different systems talk to each other over different interfaces. If any one of them fails, Flynn's diagnosis and treatment gets delayed. Which means every step needs close monitoring to make sure it's doing what it should.
Monitoring the Steps
So how do you keep watch over this? Here's what's happening behind each step, and which PRTG sensors cover it.
1. Register the patient and send details to the attending doctor
Upon arrival, Flynn is registered in the Hospital Information System (HIS). His details are sent to the Radiological Information System (RIS), where the doctor can access them. The data is transferred between systems using the HL7 protocol.
How to monitor it:
Use the HL7 Sensor in PRTG to make sure each interface is working. A small thing, checking that this pipe stays open, but it's the difference between smooth patient intake and Flynn wondering why nobody has his file yet.
2. Set up an MRI appointment
The doctor places an order request with RIS to set up the MRI scan, again over HL7.
How to monitor it:
Monitor the HL7 interface of RIS using the HL7 Sensor in PRTG.
3. Store MRI images to the PACS
When Flynn goes for his scan, the images are automatically saved to a PACS. This is done using the DICOM C-STORE request.
How to monitor it:
PRTG has two sensors for this: the DICOM C-ECHO Sensor regularly "pings" DICOM devices, while the DICOM Bandwidth Sensor stores test images to check bandwidth and response time. Each MRI machine also has a worklist, watched with the DICOM Query/Retrieve Sensor, which flags trouble querying it.
4. Retrieve the MRI images
The doctor accesses Flynn's MRI images on the PACS to make a diagnosis, using the DICOM C-FIND request.
How to monitor it:
The DICOM Query/Retrieve sensor can query the PACS for the number of images stored, or search for a specific study series, flagging any issues along the way. The DICOM C-ECHO sensor keeps "pinging" the PACS to confirm it's available.
You could stack multiple HL7 and DICOM sensors across each step to keep every interface honest, and this is just the radiology workflow. A typical hospital runs dozens of these across departments, and some corners of healthcare IT still haven't caught up, referrals limping along on faxes being one stubborn interoperability gap in an industry otherwise racing toward EHR modernization. PRTG won't fix that relic, but it will tell you the moment the e-fax gateway behind it goes down. Even for a small hospital, it's easy to end up with dozens of sensors and lose the overview.
Monitoring the Patient Journey With PRTG
The Business Process Sensor in PRTG pulls information from multiple sensors into a single view, building a status summary of a complete business process. You already have sensors watching the interfaces and systems above. All that's left is setting up a Business Process Sensor, call it "Radiology Process", that watches the whole workflow together.
How the sensor works, in short:
- Create the Business Process Sensor and select which sensors belong to the workflow you're watching. This can include all the interfaces and systems mentioned above, plus any "traditional" IT elements like routers or servers.
- Set warning thresholds for each sensor you selected.
If any sensor falls outside its configured range, the Business Process Sensor throws a warning. Here's what that looks like in practice:
In the screenshot, the sensor pulls together modalities, the network, PACS, and the DICOM worklist. Each shows green, so the global state reads green too. Safe to say this workflow is running fine. If the gauge turned yellow, you'd know Flynn's treatment was about to hit a snag, and you could drill straight down to the step causing trouble instead of combing through every sensor by hand.
Set this up for each major workflow in the hospital, and you've got one dashboard showing the status of every process and the overall health of your hospital workflow infrastructure. That's real visibility, not a guess based on how many tickets landed in the helpdesk queue this morning.
Uptime alone isn't the whole story either. Every interface carries protected health information (PHI), and HIPAA compliance depends partly on knowing where that data travels and whether the systems moving it are secure. PRTG won't police policy on its own, but network security monitoring, unusual traffic spikes, or failed logins feed into the broader data security picture.
Rolling out this kind of monitoring is its own small change management exercise: IT teams need buy-in on which sensors matter, and user adoption goes smoother when the first Business Process Sensor is built around a workflow everyone recognizes, radiology being a natural start. The same logic applies past the clinical side: revenue cycle management, patient communication, and appointment scheduling tools sit on that same network, and a stalled billing interface chips away at operational efficiency just as much as a PACS outage
Which means Flynn's doctor gets to spend energy diagnosing Flynn, not chasing down which system broke overnight. Good for Flynn, good for the doctor, and good for your friendly neighborhood PACS admin who'd rather be doing workflow optimization and process improvement than firefighting.
Do you have experience working with healthcare infrastructure? Let us know in the comments below.
You there!
