Epic Bridges Exam Prep 2023 Questions and Answers
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
An interface message contains....
Data about an event (like a patient being admitted to the hospital)
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
Segment Identifier
Three character code that identifies what kind of data that segment contains
PID-5
patient name
NTE segment
can follow many different segments
Z-segment
custom segment for a specific implementation
Is it necessary to send empty fields following the last valued field?
No
Within a field do you need to send all components?
Only as many as are valued
Blank fields...
don't file anything
Delete character HL7
double quotes " "--- tells the receiving system to delete a piece of info it has
FHIR
specifies RESTful exchange method via HTTPs to access data
Other standards supported by Bridges
X12, FHIR, NCPDP, DICOM, and Direct
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
Queue
storage location outside of Chronicles database structure
Event Queue is procesed by...
the Event Daemon
Daemon (Outgoing Message Flow)
process that runs in the background without any direct user action
,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
Data Queue (Outgoing Message Flow)
contains the full text of the message along with some additional metadata (i.e.
timestamp) about message processing
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
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
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
Control Queue (Incoming Message Flow)
processed by the Filer Daemon
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
, 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
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
Holding QUeue
Acts as a waiting area for messages that cannot get a lock to store information to the
database
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
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
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
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
An interface message contains....
Data about an event (like a patient being admitted to the hospital)
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
Segment Identifier
Three character code that identifies what kind of data that segment contains
PID-5
patient name
NTE segment
can follow many different segments
Z-segment
custom segment for a specific implementation
Is it necessary to send empty fields following the last valued field?
No
Within a field do you need to send all components?
Only as many as are valued
Blank fields...
don't file anything
Delete character HL7
double quotes " "--- tells the receiving system to delete a piece of info it has
FHIR
specifies RESTful exchange method via HTTPs to access data
Other standards supported by Bridges
X12, FHIR, NCPDP, DICOM, and Direct
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
Queue
storage location outside of Chronicles database structure
Event Queue is procesed by...
the Event Daemon
Daemon (Outgoing Message Flow)
process that runs in the background without any direct user action
,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
Data Queue (Outgoing Message Flow)
contains the full text of the message along with some additional metadata (i.e.
timestamp) about message processing
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
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
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
Control Queue (Incoming Message Flow)
processed by the Filer Daemon
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
, 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
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
Holding QUeue
Acts as a waiting area for messages that cannot get a lock to store information to the
database
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
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
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
