Originally published on October 30, 2018 by Shaun Behrens
Last updated on January 23, 2024
•
13 minute read
In a previous post, we took a look at the DICOM and HL7 sensors you get out-of-the-box with PRTG. These sensors can be used to monitor various aspects of a typical hospital's infrastructure, such as the Picture Archiving and Communication System (PACS) or the interfaces for transferring patient details between departments. But interfaces and systems don't run in isolation. What you really want is the big picture: what is the status of entire workflows?
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 would help to consider a specific example. A patient — let's call him Flynn — fell badly while playing football last week, and ever since then his right arm has been hurting. His doctor sent him to the local hospital to get checked out. Take a look at the graphic below to see a simplified example of Flynn's patient journey. Then we'll discuss the technology in the background, and what must be done to make sure Flynn's patient journey is not interrupted.
When Flynn arrives at the hospital, he registers at reception and then goes through to the doctor. By this time, Flynn's details are already accessible at the doctor's workstation (usually through a Web interface or an application). The doctor decides Flynn needs an MRI scan. The doctor plans an appointment for the scan.
Flynn gets the scan done, and his images are stored in a central repository (a PACS). The doctor can then access the images in order to diagnose what's going on with Flynn's arm.
Of course, for each step of Flynn's experience in the hospital, different systems are interacting over various interfaces. If one of these fails for whatever reason, Flynn's diagnosis and subsequent treatment is delayed. And this means that each of these steps must be closely monitored to ensure everything is functioning as it should.
Monitoring the Steps
But how? Well, let's consider what's happening in the background during each step, and how you can monitor the steps using sensors provided by PRTG Network Monitor:
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 ensure that each interface is working properly.
2. Set up an MRI appointment
The doctor places an Order Request with RIS to set up the MRI scan. This is also done using the HL7 protocol.
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:
You need to make sure that the C-STORE request is working. PRTG has two sensors that can be used to monitor this: the DICOM C-ECHO Sensor can regularly "ping" DICOM devices (it's not exactly a traditional ping, but works in a similar way), while the DICOM Bandwidth Sensor regularly tries to store test images to the PACS in order to check bandwidth and response time.
Each MRI machine has an associated worklist, and this can also be monitored using the DICOM Query/Retrieve Sensor. This will indicate how many jobs a machine has scheduled, and if there are issues querying the worklist.
4. Retrieve the MRI images
The doctor accesses the patient's MRI images on the PACS in order to make a diagnosis. The DICOM C-FIND request is used for this.
How to monitor it:
The DICOM Query/Retrieve sensor of PRTG can be used to query the PACS for the number of images stored, or search for a specific study series. This will indicate if there are any issues with querying images on PACS. You can also use the DICOM C-ECHO sensor to regularly "ping" the PACS to check its availability.
As you can see, you could have multiple HL7 and DICOM sensors on each of these steps to make sure all interfaces are up, and that data can be transferred and accessed. This is very useful. However, the example here is just the radiology workflow. In a typical hospital, there are many different workflows for each department. Even for the smallest hospitals, you can easily end up with dozens of sensors on your PRTG dashboard for many different parts of various workflows. Truth be told, it's easy to lose the overview.
Which is why you need to be able to look at the related steps as part of a bigger workflow.
Monitoring the Patient Journey With PRTG
The Business Process Sensor in PRTG brings information from multiple sensors into one single sensor. The idea is that you can build a status summary of a complete business process. So in our example above, you already have sensors in place to monitor the interfaces and systems. All you now need to do is set up a Business Process Sensor (perhaps called "Radiology Process", as an example) that monitors everything in that specific workflow.
How the sensor works is as follows:
- Create the Business Process Sensor, and select which sensors are part of the workflow you are monitoring. You can include all the interfaces and systems mentioned above, as well as any other "traditional" IT elements like routers or servers.
- Set warning thresholds for each sensor you selected.
If any of the sensors falls outside of the configured range, the Business Process Sensor sends a warning.
Here's what it looks like in practice:
In the screenshot, you can see that this business process sensor includes sensors for modalities, the network, PACS, and the DICOM Worklist. Each one is green, and so the global state of the sensor is green, too. It's safe to say that this workflow is currently fine.
This way, you have an instant view to an entire process, and will know at a glance if something isn't working. Right now, Flynn will move through the steps of the workflow without a problem. However, if the gauge was yellow, then you would know that Flynn's treatment would be interrupted somewhere. Then you can drill down and find out exactly which step is causing the problem.
If you have a sensor like this for each major workflow in your hospital, you can then have a dashboard where you can immediately check on the status of all your workflows, and see the overall status of your entire hospital infrastructure.
Which means that Flynn's doctor only needs to focus his energy on diagnosing Flynn, and not figuring out where system issues might be. Good for Flynn, good for the doctor, and good for your friendly neighborhood PACS admin...
Do you have experience working with healthcare infrastructure? Let us know in the comments below.
You there!
