EPIC BRIDGES COMPREHENSIVE UPDATED EXAM
QUESTIONS AND ANSWERS GUARANTEE A+
✔✔Detailed Message Report - ✔✔provides all the information related to a message in a
single location
-can also be viewed in the bottom report pane of the Message Search results
-there are many links DMR to perform actions or jump to records, including the table
associated with a table mapping error, or the patient to which the message is
associated
✔✔How to get the most out of Message Search - ✔✔- limit the time period of your
search to as small of a window as possible
-use unique identifiers like MRN, CSN, or order ID for your message content criteria as
opposed to non-unique values like patient name
-include multiple search values to limit your results even further
✔✔Reasons why an interface daemon might stop unexpectedly - ✔✔1) there is a major
problem going on with the system in general
2)there is one unique message that the interface is unable to handle
✔✔When a single message causes an interface daemon to stop unexpectedly... -
✔✔you are presented with two problems
1)the bad message cannot file
2)none of the messages after that message can file
✔✔Skipping Messages - ✔✔Allows you to solve the problem of messages being
blocked by one bad message by removing the bad message from the Control Queue so
it will no longer be considered as a message to be processed and it logs a fatal error
indicating which user skipped the message
✔✔True/False: There is no action that a user can take to remove a message from the
Data Queue - ✔✔True
✔✔When can a message be skipped? - ✔✔If the Waiting? column has a "yes" value in
the message search results
✔✔Message Search "Waiting" Column - ✔✔indicates whether or not the message still
exists on the Control or Hold Queue
✔✔Reasons why a message might still exist on the Control Queue for an outgoing
interface - ✔✔- the communication daemon is turned off
-there are communication issues with the engine or external system
, -there is a high volume of messages
✔✔Reasons why a message might still exist on the Control or Holding Queue for an
incoming interface - ✔✔-the filer daemon is turned off
-the message is in the holding queue due to record locks
-there is a high volume of messages
✔✔Resubmitting a message (incoming or outgoing) - ✔✔creates a new message on the
data queue and also places an entry on the Control Queue
✔✔Resubmitting a message (incoming) - ✔✔forces the filer daemon to reprocess the
message that was resubmitted, which allows a user to attempt to file changes made
directly to the message
✔✔Resubmitting a message (outgoing) - ✔✔Control Queue is after the Event Daemon,
so message gets processed by the comm daemon and sent out exactly as it appears
when re-submitted.
Any changes to the data in Chronicles or to interface configuration will not be reflected
in the resubmitted message
✔✔Retriggering Messages - ✔✔- copies the original event and puts it back on the event
queue.
-the event is then processed by the event daemon, applying any changes made in
Chronicles or through interface configuration modifications
-the event daemon will generate a new message that will be put on the data queue as
well as an instruction for the control queue for the communications daemon to process
-only outgoing interface messages can be retriggered
✔✔Can resubmitted messages be retriggered? - ✔✔No because they no longer have
an event string to put pack on the event queue
✔✔XML Bridges Utilities - ✔✔The following bridges utilities also support interfaces that
use an XML message structure:
-message search
-message viewer
-message editor
✔✔Does the message editor perform validation to ensure that the value entered is
appropriate? - ✔✔No. The message editor is a free text editor. It has no idea how the
message should look
✔✔In message viewer, what information is available besides the text of the message? -
✔✔You can see errors associated with that message, message submission details such
as timestamps of when the message was added to the data queue and processed
QUESTIONS AND ANSWERS GUARANTEE A+
✔✔Detailed Message Report - ✔✔provides all the information related to a message in a
single location
-can also be viewed in the bottom report pane of the Message Search results
-there are many links DMR to perform actions or jump to records, including the table
associated with a table mapping error, or the patient to which the message is
associated
✔✔How to get the most out of Message Search - ✔✔- limit the time period of your
search to as small of a window as possible
-use unique identifiers like MRN, CSN, or order ID for your message content criteria as
opposed to non-unique values like patient name
-include multiple search values to limit your results even further
✔✔Reasons why an interface daemon might stop unexpectedly - ✔✔1) there is a major
problem going on with the system in general
2)there is one unique message that the interface is unable to handle
✔✔When a single message causes an interface daemon to stop unexpectedly... -
✔✔you are presented with two problems
1)the bad message cannot file
2)none of the messages after that message can file
✔✔Skipping Messages - ✔✔Allows you to solve the problem of messages being
blocked by one bad message by removing the bad message from the Control Queue so
it will no longer be considered as a message to be processed and it logs a fatal error
indicating which user skipped the message
✔✔True/False: There is no action that a user can take to remove a message from the
Data Queue - ✔✔True
✔✔When can a message be skipped? - ✔✔If the Waiting? column has a "yes" value in
the message search results
✔✔Message Search "Waiting" Column - ✔✔indicates whether or not the message still
exists on the Control or Hold Queue
✔✔Reasons why a message might still exist on the Control Queue for an outgoing
interface - ✔✔- the communication daemon is turned off
-there are communication issues with the engine or external system
, -there is a high volume of messages
✔✔Reasons why a message might still exist on the Control or Holding Queue for an
incoming interface - ✔✔-the filer daemon is turned off
-the message is in the holding queue due to record locks
-there is a high volume of messages
✔✔Resubmitting a message (incoming or outgoing) - ✔✔creates a new message on the
data queue and also places an entry on the Control Queue
✔✔Resubmitting a message (incoming) - ✔✔forces the filer daemon to reprocess the
message that was resubmitted, which allows a user to attempt to file changes made
directly to the message
✔✔Resubmitting a message (outgoing) - ✔✔Control Queue is after the Event Daemon,
so message gets processed by the comm daemon and sent out exactly as it appears
when re-submitted.
Any changes to the data in Chronicles or to interface configuration will not be reflected
in the resubmitted message
✔✔Retriggering Messages - ✔✔- copies the original event and puts it back on the event
queue.
-the event is then processed by the event daemon, applying any changes made in
Chronicles or through interface configuration modifications
-the event daemon will generate a new message that will be put on the data queue as
well as an instruction for the control queue for the communications daemon to process
-only outgoing interface messages can be retriggered
✔✔Can resubmitted messages be retriggered? - ✔✔No because they no longer have
an event string to put pack on the event queue
✔✔XML Bridges Utilities - ✔✔The following bridges utilities also support interfaces that
use an XML message structure:
-message search
-message viewer
-message editor
✔✔Does the message editor perform validation to ensure that the value entered is
appropriate? - ✔✔No. The message editor is a free text editor. It has no idea how the
message should look
✔✔In message viewer, what information is available besides the text of the message? -
✔✔You can see errors associated with that message, message submission details such
as timestamps of when the message was added to the data queue and processed
