Announcement

Collapse
No announcement yet.

Tools to monitor HL7 messages & redundancy.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Tools to monitor HL7 messages & redundancy.

    * What happens if it goes down? How seamless is the switch-over to a
    secondary system?

    * What tools are available that allow the PACS Admin to monitor the
    HL7 transmission queues within Mirth?

    * Eg, to see if any reports are "stuck" or failed to transfer?
    * Eg, to try resending them?

    How would the PACS Admin fix outbound reports, if for example, it
    was determined that a Patient ID or Accession Number or Patient Name was
    wrong, etc.?
    * Does an audit trail viewing tool exist that allows the history of
    the Order as it is handled in the PACS to be viewed?

    * For example:

    * Order received from the RIS on date/time.
    * Order/Study opened for dictation by Radiologist (name) on date/time.
    * Order/Study promoted to 'dictated' status on date/time.
    * Order/Study promoted to 'prelim' status..
    * ...'Final' (signed) status, signed by (name).
    * Result sent to (destination) (successfully? failed?) on date/time.

  • #2
    Re:Tools to monitor HL7 messages & redundancy.

    We'll get back to you shortly with answers to your questions.
    Chris Lang

    Comment


    • #3
      Re:Tools to monitor HL7 messages & redundancy.

      If Mirth is down, the sending application would have to have the capability to send to another instance of Mirth if the primary instance is down. Either that or have the sending app queue up the requests/messages. Not sure if Mirth is the best target for that responsibility. There is also an option to cluster Windows 2003 server to increase reliability.

      There is an issue on the issues list to add queues to every channel in Mirth. Hopefully when this is added, it will have the option to retry messages and keep failed messages in the queue until the destination can receive the message.

      Mirth keeps track of all the messages that it processes. This can be queried as necessary.

      Since Mirth supports JavaScript, almost any design is possible. It is a matter of how much code is needed to support the requirements.

      Comment


      • #4
        Re:Tools to monitor HL7 messages & redundancy.

        If Mirth is down, the sending application would have to have the capability to send to another instance of Mirth if the primary instance is down. Either that or have the sending app queue up the requests/messages. Not sure if Mirth is the best target for that responsibility. There is also an option to cluster Windows 2003 server to increase reliability.

        There is an issue on the issues list to add queues to every channel in Mirth. Hopefully when this is added, it will have the option to retry messages and keep failed messages in the queue until the destination can receive the message.

        Mirth keeps track of all the messages that it processes. This can be queried as necessary.

        Since Mirth supports JavaScript, almost any design is possible. It is a matter of how much code is needed to support the requirements.

        Comment

        Working...
        X