Epic Bridges Exam Prep

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

Reasons to search for messages

- if there is an error on a message for a patient -if there is a problem with a given procedure

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 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

Incoming Message Flow with Interconnect

-Exists within the firewall; -constantly listening for messages coming into the system -most incoming interconnect interfaces don't require a separate Comm Daemon, since the Interconnect server handles all of the communication in this direction.

With Haiku, you can access what details about an interface?

-ID and name -Daemon status -Date and time of last message activity -Queue depth

Resequencing

-a record is locked when a user or process is updating it -IF a filer daemon receives a message for a patient, but that patient's record is already being updated with an active lock, then the Filer stores the instruction for that message on another queue- the Holding Queue. -the message remains on the Holding Queue until the lock is released, so that the Filer Daemon can move onto the next message in the Control Queue for processing The filer Daemon checks messages on the Holding Queue periodically to determine whether messages on the Holding Queue are ready to file If the Filer Daemon encounters a message on the Control Queue that needs the same locks as a message already on the Holding Queue, that message is also added to the Holding Queue. This ensures that the messages always file into Chronicles in the same order they were received for a patient

If you are running a message search, what best practices could you use to reduce the amount of messages returned by your search or finish your search quicker?

-limit the time period searched -search for unique identifiers (CSN, MRN, order ID) as opposed to patient name -include multiple search values in your search criteria

Comm Daemon (Incoming Message Flow)

-listens constantly for messages coming into the system -validates MSH-11 and MSH-12 before accepting it, storing it in the data queue, and adding instruction to the control queue -sends or receives acknowledgments over a TCP/IP connection

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

Message Purging Hierarchy

1) Interface Level 2) Background Monitor Level 3) System Default of 30 Days If purge days are not specified for a given interface, the number of days in the Background moniotr will be used. When neither of those purge days are specified, then a system-wide default of 30 days is used.

When the filer daemon attempts to process a message, there are three things that can happen

1) it files the message into Chronicles, possibly with one or more warning or notification errors 2) its unable to file the entire message because there is something critically wrong with the message. This is indicated by a fatal or critical error 3) it's unable to file the message because part of the record to which the message needs to file is locked

Three options for starting interfaces after planned downtime

1) manually start your interfaces in the order you desire 2) automatically start all of your interfaces at once when the backgroun monitor is started 3) automatically start all of your interfaces with rules to determine the order that interfaces are started

An interface requires interconnect if one or more of the following are true:

1) the message uses an XML framework 2) communication requires HTTPS (web) protocol to reach securely outside your firewall 3) the interface handles a job in a windows .NET framework, such as extracting an embedded PDF from an HL7 v2 message and storing it to a BLOB server

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

Holding QUeue

Acts as a waiting area for messages that cannot get a lock to store information to the database

After you create an alert rule you need to....

Add it to the Background Monitor alerts

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

Autostart Blocking Conditions in the Background Monitor

Allows you to specify additional criteria that delays the startup of some interfaces Path: Epic>Admin>Interface Admin>Background Monitor Definition> Autostart

Interface Monitor Definition

Allows you to specify which interfaces should be displayed in the Interface Monitor activity

Message Viewer

Allows you to view the contents of an interface message in the Data Queue

Outgoing Message Flow with Interconnect

Comm daemon sends the content of the data queue to Interconnect, wehre the message is packaged and sent

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

An interface message contains....

Data about an event (like a patient being admitted to the hospital)

Bridges Error Codes

Each error logged by bridges includes a discrete numeric error code that allows us to group multiple occurrences of the same problem Errors sharing the same error code also include additional information specific to the occurrence of that error

Time since last message( Interface Monitor Column)

Elapsed time since a message was last sent (for an outgoing interface) or received (for an incoming interface)

Bridges Error Severities

Epic supports five error severities: critical, fatal, warning, notification, and none

Interconnect

Epic's web services framework -enables Epic applications to initiate and receive web service requests with an external application -sometimes used as an alternate communication method to TCP/IP for interfaces -communicates messages securely using an HTTPS framework

Path to create an alert rule

Epic>Admin>Interface Admin> Background Monitor Definition

What are stored in the Event Queue, Data Queue, and Control Queue?

Event Queue: info needed to build a message (i.e. patient ID, encounter date, type of message, etc.) Data Queue: text of HL7 message and additional metadata Control Queue: to-do list with instructions to send or file messages stored in the Data Queue

Epic App for monitoring interfaces on mobile device

Haiku

When can a message be skipped?

If the Waiting? column has a "yes" value in the message search results

Is it necessary to send empty fields following the last valued field?

No

Can resubmitted messages be retriggered?

No because they no longer have an event string to put pack on the event queue

Are messages ever manually deleted from the Data Queue?

No, never. They are purged only by an automated purge job.

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

Are you deleting a message from the data queue with the Skip message feature?

No. You can never manually delete a message with any bridges utility. This utility removes the entry only from the Control Queue

Waiting Messages (Interface Monitor Column)

Number of messages waiting to be processed from the Holding Queue

Last Recv'd/Sent (Interface Monitor Column)

Number of the Last message sent (outgoing) or received (incoming) i.e. message number

Within a field do you need to send all components?

Only as many as are valued

Trigger

Serves as the integration point between the application workflow and Bridges -generally an action in Hyperspace, like clicking a button or closing an activity -a single, clearly defined action that a user or process can take that results in an interface message being created and sent

What are two ways that interface messages are sent and received

TCP/IP with an interface engine is the most common. Interconnect is used for HTTPS or other communication outside your local network

XML Bridges Utilities

The following bridges utilities also support interfaces that use an XML message structure: -message search -message viewer -message editor

Segment Identifier

Three character code that identifies what kind of data that segment contains

True/False: There is no action that a user can take to remove a message from the Data Queue

True

Filer/Event Status (Interface Monitor Column)

Whether the Event Daemon (outgoing) or Filer Daemon (incoming) is stopped or running

Other standards supported by Bridges

X12, FHIR, NCPDP, DICOM, and Direct

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

Control Queue (Outgoing Message Flow)

a to-do list and contains very little data -processed by the Communications Daemon -maintains a list of messages waiting to be processed

Rule Editor

allows you to create conditions that are best for your organization. Also contains an alert email message section to configure what text is included in the body of the email sent for the alert.

Message Search

allows you to specify an interface, a string to look for, and a time period. The activity then returns all messages that match that criteria -allows you to take action on messages that are returned in your search: edit, resubmit, save search path: epic>tools>interface utilities>message search

Message Viewer

allows you to view the contents of an interface mesage in the Data Queue Path: Epic>Tools>Interface Utilities>View Messages

NTE segment

can follow many different segments

Chronicles

contains all the information for a patient in the form of records

Data Queue (Outgoing Message Flow)

contains the full text of the message along with some additional metadata (i.e. timestamp) about message processing

Resubmitting a message (incoming or outgoing)

creates a new message on the data queue and also places an entry on the Control Queue

Resubmit feature

creates a new message that is added to the data queue and the control queue to be processed -marks any errors on the original message as resolved. If an error still holds true on an incoming message, then a new instance of that error will be logged on the new message as it is processed by the Filer Daemon

Z-segment

custom segment for a specific implementation

Interface Monitor

displays the interfaces from the definition. There are several pieces of information available about each interface displayed: -AIP ID -Interface -Queue -Time since last message -Total recv;d/sent -Last recv'dsent -queued messages -queued events -waiting messages -communication status -filer/event status -time since comm start -time since filer/event start

Blank fields...

don't file anything

Delete character HL7

double quotes " "--- tells the receiving system to delete a piece of info it has

Common uses of interconnect include

e-Prescribing, Care Everywhere, Meaningful Use interfaces to state registries (i.e. immunizations, results and cancer reporting), Eligibility and X12 interfaces, EMFI and CHart Sunch interfaces, Research Protocol interfaces, Real Time Location System Tracking, IHE interfaces, country-speciifc interfaces

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

When a rule is checking for a time, use the___operator

greater than . If you use equal, the rule will be true only if the the rule is evaluated at exactly the correct time interval

Critical error

indicates that the problem is serious enough to prevent the content from being processed

Fatal error

indicates that the problem is serious enough to prevent the content from being processed

Error Scope

indicates the context of a given error. 3 levels at which an error can be logged: 1) daemon, 2) message 3) local

Message Search "Waiting" Column

indicates whether or not the message still exists on the Control or Hold Queue

Queued Events (Interface Monitor Column)

number of events waiting to be processed from the Event Queue (outgoing only)

Queued Messages (Interface Monitor Column)

number of messages waiting to be sent (outgoing) or processed (incoming)

Create new message option

only available for HL7 version 2 interfaces

PID-5

patient name

Notification error

presents information that might be of interest; logs an error but content is still processed

Daemon (Outgoing Message Flow)

process that runs in the background without any direct user action

Control Queue (Incoming Message Flow)

processed by the Filer Daemon

Radar

provides a centralized location for important reporting tools and metrics inside Hyperspace

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

Event Daemon (Outgoing Message Flow)

pulls an event off the Event Queue, uses the information in the event to build the message and finally deletes the event from the event queue. The event daemon puts the message it has built onto the data queue and adds an instruction to the Control Queue builds an HL7 message based on data pulled from Chronicles

Filer Daemon

pulls an instruction from the Control Queue, retrieves the corresponding message from the Data Queue, and then attempts to file the message. Filing means that the Filer Daemon attempts to store the data in Chronicles. If the filer daemon is successful, the data is added to the appropriate records in Chronicles. When there is a problem, and the data in the message cannot be filed, an interface error message is logged Translates HL7 data into something that can be stored to the database

Comm Deamon (Outgoing Message Flow)

reads an instruction from the Control Queue and copies the appropriate message off the Data Queue -sends the message out of Epic and waits for an ACK to be reutrned -deletes instruction from the Control Queue and proceeds to the next instruction -sends or receives acknowledgments over a TCP/IP connection

Dashboard

screen of information that pulls data from multiple sources into one centralized location for a group of end users

Resubmitting an Outgoing message

sends the message directly out the Communications Daemon, and no additional validation is done on the message content. If a problem still exists on an outgoing message the error on the original message will be marked as resolved, but a new error will not reappear on the new message

Message Editor

similar to the Message Viewer but has the additional power of allowing you to make changes to the message and subit your edited version path: Epic>Tools>Interface Utilities>Edit Message

Event (in context of outgoing message flow)

small set of values with the necessary info to build the message: patient ID, patient contact, type of message, and additional info -contains directions for where the interface should pull the information it needs from the database

Warning error

something went wrong, but not enough to prevent content from being processed

FHIR

specifies RESTful exchange method via HTTPs to access data

Queue

storage location outside of Chronicles database structure

Resubmit feature

submits your new copy of the interface message

Lower half of Message Viewer

tabbed display window that can show you several things about the message (i.e. message text, logged errors, message submission details, and sesion history)

Background Monitor

takes care of many tasks including determining whether interfaces are running

Event Queue is procesed by...

the Event Daemon

MSH-11 and MSH-12 are...

the HL7 processing ID and version; Epic checks these values on an incoming message and rejects the message if they do not match the expected values

For an interface to be eligible for either auto-start option:

the autostart on system startup must be checked on the startup.shutdown tab of the interface specification

What does it mean for an interface to process a message?

the incoming interface's Filer Daemon tries to find the correct patient and file the data in the message into Chronicles the outgoing interface's Event Daemon creates an HL7 message, based on information in Chronicles, and sends it out through the port defined in the Comm Daemon.

Message Viewer Tree

the interface message selected is displayed in a tree in the upper half of the Message Viewer. Each segment in the message is displayed in its own branch of the tree.

Total Recv'd/Sent (Interface Monitor Column)

total number of messages sent (outgoing) or received (incoming) i.e. count

Components

units of conent that compose a dashboard Dashboards present information from multiple components in one location instead of multiple acitivities

Data Queue

used to store messages that are received by Bridges or that are created by Bridges to send out contains the full text of the message along with some additional metadata

Communication Status (Interface Monitor Column)

whether the comm daemon is stopped or running

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