HL7 Message Processing and Queuing, Exams of Nursing

Download HL7 Message Processing and Queuing and more Exams Nursing in PDF only on Docsity!

EPIC

BRIDGES

EXAM

Question

Bank Latest

Update

Combined

Verified Exam

Sets

Bridges Epic With

Solution

What are the 4 types of Error Severities - ANSWER Critical, Fatal, Warning, Notification What is a profile Variable - ANSWER single configurable option, that lets you control how the interface will behave.. It's a record in the AIV master file. what is a Interface Specification - ANSWER is a record in the AIP master file INTF_USER Profile Variable - ANSWER this is required variable for every interface in order for the interface to process messages. An Interface will NOT start without INTF_USER. If this is missing a Bridges error will be generated.

Define ID Type (Mapping) - instituions that uses it (library) - ANSWER This represents what type of ID the number is - providers, medications, departments, procedures etc.. List of some Master Files - ANSWER SER (Provider), EAP (Procedue), DEF (Department), EAF (Facility) , DEV (Device), ERX (Medication) - these are just a few. Translation Tables - ANSWER Used to map values between Epic and another system. This is also a record in AIF master file, which is enabled for Data Courier. Translates one value to another. Incoming Tables - ANSWER used to map data being received from an external system into values Epic can store into Chronicles Outgoing Tables - ANSWER used to map data stored in Epic to external Systems. IMPORTANT** Translation Tables should NOT be used to map Record ID - ANSWER Identity is nearly always used to map record -level identifiiers, such as procedures, patients, providers and medications. describe how patient validation works - ANSWER be able to draw diagrams describe how duplicate prevention works - ANSWER be able to draw diagrams True/False - once you delete the ID there is now way to see the ID in the ID maintenance activity - ANSWER False - they appear on the bottom section

what are 3 ways to migrate data from test to production environment - ANSWER data courtier tool, Interface Moving Utility and Manual Migration. Data Courier objects that are enabled - ANSWER tables (translation& general), error workqueues, radar dashboards, profile variables and custom colums. EDI User - ANSWER designed for users working the error logs or monitoring interfaces, resubmit messages etc EDI Administrator - ANSWER for Interface Admins, has full access to all utilities and config screens. EDI Programmer - ANSWER can create new interfaces in Bridges what is a Security Point - ANSWER like a key; allows access to one specific feature what is a Security Class - ANSWER like keychain; contains many security points and gives acess to host of features. The Encoding Characters of an MSH message are always received in which order - ANSWER Field, Component, Repitition, Escape, Subcomponent NTE Segment - ANSWER must always look at preceding segment to determine the context of the note. What will delete a message from the Data Queue? - ANSWER Nothing other than Purge job will do this. Messages will not be deleted from Data Queue

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

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, IHE interfaces, country-specific interfaces Outgoing Message Flow with Interconnect - Comm daemon sends the content of the data queue to Interconnect, where the message is packaged and sent 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. Chronicles - contains all the information for a patient in the form of records 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

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 Radar - provides a centralized location for important reporting tools and metrics inside Hyperspace Dashboard - screen of information that pulls data from multiple sources into one centralized location for a group of end users Components - units of content that compose a dashboard Dashboards present information from multiple components in one location instead of multiple activities After you create an alert rule you need to.... - Add it to the Background Monitor alerts 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 Path to create an alert rule - Epic>Admin>Interface Admin>

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 -allows you to take action on messages that are returned in your search: edit, resubmit, save search path: epic>tools>interface utilities>message search 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 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

-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 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 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 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 Bridges Error Severities - Epic supports five error severities: critical, fatal, warning, notification, and none 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