Partial preview of the text
Download Epic Bridges Exam Latest....... and more Exams Nursing in PDF only on Docsity!
Epic Bridges Exam 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 those 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 processed 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 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 Chart Such interfaces, Research Protocol interfaces, Real Time Location System Tracking, [HE interfaces, country-specific interfaces 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. Are messages ever manually deleted from the Data Queue? - No, never. They are purged only by an automated purge job. Communication Status (Interface Monitor Column) - whether the comm daemon is stopped or running Total Rav’d/Sent (Interface Monitor Column) - total number of messages sent (outgoing) or received (incoming) i.e. count Last Rav’d/Sent (Interface Monitor Column) - Number of the Last message sent (outgoing) or received (incoming) i.e. message number 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) Queued Messages (Interface Monitor Column) - number of messages waiting to be sent (outgoing) or processed (incoming) Queued Events (Interface Monitor Column) - number of events waiting to be processed from the Event Queue (outgoing only) Waiting Messages (Interface Monitor Column) - Number of messages waiting to be processed from the Holding Queue Filer/Event Status (Interface Monitor Column) - Whether the Event Daemon (outgoing) or Filer Daemon (incoming) is stopped or running Background Monitor - takes care of many tasks including determining whether interfaces are running Interface Monitor Definition - Allows you to specify which interfaces should be displayed in the Interface Monitor activity 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 evident -queued messages -queued events -waiting messages -communication status -filer/event status -time since comm start -time since filer/event start 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. Message Viewer - Allows you to view the contents of an interface message in the Data Queue 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 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 Epic App for monitoring interfaces on mobile device - Haiku With Haiku, you can access what details about an interface? - -ID and name -Daemon status -Date and time of last message activity -Queue depth 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 Message Viewer - allows you to view the contents of an interface message in the Data Queue Path: Epic>Tools>Interface Utilities>View Messages 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. 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 session history) Message Editor - similar to the Message Viewer but has the additional power of allowing you to make changes to the message and submit your edited version path: Epic>Tools>Interface Utilities>Edit Message Create new message option - only available for HL7 version 2 interfaces 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 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 Resubmit feature - submits your new copy of the interface message 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 criterion 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 1) daemon, 2) message 3) local The majority of errors logged by interfaces are in scope - message-scoped Local-scope error - error applies only to part of the message, and the rest of the message might have been processed successfully daemon-scoped error - indicates problem with the interface configuration, and might require that the interface be stopped so that the problem can be addressed Error Log Report - allows you to search for logged errors, display them, and take actions to resolve them Path: Epic>Tools>Interface Utilties>Error Log PID-7 - patient date of birth Each type of error can be gathered into one of three possible actions: 1) Fix 2) Work 3) Suppress "Fix" errors - problems that can be eliminated by a change to the system to permanently eliminate the problem "Suppress" errors - some errors are benign and require no further action, so those you can simply suppress "Work" errors - errors you expect to happen periodically and will require manual intervention as part of the ongoing maintenance of the interface Possible steps one might take to resolve a "Fix" or "Work" error - - correct a data mapping issue within Epic -resubmit or retrigger the message in Bridges -edit the message content in Bridges and then resubmit it -update a value or setting in the sending system and retrigger the message to Epic -change the handling of messages in your interface engine -manually change a data value in Chronicles -search for messages filed to the same patient Deleting an Error - marks the error as resolved; happens if: you already made a change in the system to correct the issue, the error is innocuous -a later message has filed and rendered the message with the error obsolete Deleted error - still exists in a resolved state can always access details about the error in Bridges, so long as the corresponding message exists in the Data Queue Error Work queues - tool for managing and assigning errors that fall into the ongoing maintenance category -each we has a list of rules that describes the kinds of errors it should collect -whenever an interface logs an error that meets one of those rules, the error is automatically assigned to that wq -proactively collects all errors that meet criteria from pre-built rules path: epic>tools>interface utilities>workqueue list To make an error step visible - you must LINK the step group to a specific interface (link button on the tool bar of the error step) Error step groups linked on a specific interface take precedence over.... - step groups linked to the system definitions What are two actions you can take on the message associated with an error when running an Error Log Report - Resubmit and retrigger Can you delete a message in the Error Log Report activity? - No- you can never manually delete a message from the data queue with any Bridges Activity What are three additional actions that only a work queue provides compared with the Error Log Report? - Add a note, transfer, and release an error What types of errors should be added to a work queue? - IF an error requires ongoing maintenance and has a defined resolution path it should be an error that can be assigned to a user and is not already being collected by another, we What build is required to assign error resolution steps for a particular error? - You need to create a group and add one or more steps to it. Finally, you will need to link the group to an interface for a particular error Interfaces are primarily configured using... - profile variables Profile variable - single configurable option in an interface specification that allows you to control how an interface behaves -record in the AIV master file What is contained in the System Definitions? - -triggers for outgoing interfaces, system-wide profile variables, and system-wide error handling INTF_USER profile variable - it is the user associated with the interface audit trail entries if no user is present in the message interface will not start without this py added What must be done once you have made changes to a custom override to ensure the changes will take effect? - Compile the custom override and restart the interface Profile variable usage report - compares settings of profile variables across interfaces Profile variable audit report - tracks the changes to a profile variable within a specific interface If you change a profile variable in one interface specification, does it affect the profile variable in other interfaces? - No, just the one interface specification in which the change was made Editing the system definitions profile variables requires that you...... - stop all interfaces that are listed in the Background Monitor Inherited profile variables - profile variables that are in use by an interface that are defined in the system definitions one of the easiest types of custom overrides - skipping a field T/F: A single custom override can be used across multiple interfaces of the same type - T 
