Monitoring Details

Resources are categorized in a purpose-built hierarchy making it easy to apply business rules and common characteristics to any level in the hierarchy. This approach makes it easy to adjust settings as your footprint changes.

Resources have different characteristics and therefore need to monitored differently. The same type of resource should be monitored differently depending on it's environment. For example: Your production DICOM router should be monitored differently than your DICOM router used in your test environment.

End-users with appropriate credentials can easily pause entire environments, a specific resource, or even a feature of one resource. As an example: You know your PACS test environment is going off-line due to server maintenance. With one click you can pause monitoring for your entire PACS test footprint, and then with one click, resume monitoring.

Sometimes a visual is needed to quickly assess an issue. In this case maps can be created  to suit your needs. As a PACS administrator you may only be interested in a map showing PACS servers and DICOM routing components. An office manager may want a visual showing connectivity to all remote sites. Maps are HTML based and can be displayed on an individual's workstation or on a large display in an operations area.

Our approach lets you monitor resources from within your network, but also lets us monitor from outside. As an example: You need to know quickly if your patient portal is not accessible from the public internet.

Not all alarms are resolved by your IT department; in fact many alarms require knowledge of clinical systems where a super user needs to be the first one notified. Our notification approach not only lets us notify the correct individuals, but also lets us customize the message that is sent. Two examples: 

* An alarm implies your WAN connection between your corporate office and a remote site is down. This alarm needs to go to IT. The content of the message could contain a link to your WAN provider's home page so a ticket could quickly be opened. 

* An alarm implies your HL7 engine is no longer accepting messages on a specific port. The server is on-line, but the application is confused. In this case the message may first need to go to one or several super users for triage.