Using the Error Management Console

Owned by Ryan Crichton
Last updated: Sept 04, 2012Version comment
5 min read

Login

This works like any other login screen. Enter your username and password and hit 'Login' :)

Browsing Transactions

Once you have logged in you will be presented with a screen showing a list of latest transactions that have been executed through the interoperability layer. These transaction are sorted by date with the latest transaction at the top. At the top of the screen in the grey box there are a number of options to filter the transactions that are displayed. Each of these is explained below:

  • Show only flagged - Clicking this check box filters the transaction list so that only transaction that are flagged are displayed. (see more about flagging in the view transactions section)
  • Show only un-reviewed - Clicking this check box filters the transaction list so that only transaction that have not been reviewed are displayed. (see more about reviewing transaction in the view transactions section)
  • Status - This drop-down-box allow you to filter by the following transaction status':
    • Processing - Transaction that are still being processed by the Interoperability Layer.
    • Completed - Transactions that have been completed successfully.
    • Error'd - Transaction that have encountered an error and could not be processed.
  • Endpoint - This drop-down-box allow you to filter by the different transaction types.
  • Date From - This field allows you to filter by transactions from a specific date onwards.
  • Date To - This field allows you to filter by transactions up until a specific date
  • Refresh - This button allows the user to refresh the page in case new transactions have arrived.

You can click on any row of the grid that displays the transactions to view details about that transaction. This will take you to a new screen. This screen is described below in the view transaction section.

Viewing Transactions

This page shows various details about a specific transaction. This includes the request that initiated this transaction, the response that was sent back to the client and an errors that occurred during processing of the transaction.

You may click on boxes labels 'Request Body', 'Response Body' or 'Stacktrace' to view a larger pop-up view of that box. This is useful when trying to identify problem or errors in the messages or when trying to find the cause of an error.

There are a number of button in the top right hand corner of this page. Each of these are described below:

  • Re-run the transaction - This button allow you to re-run this transaction through the interoperability layer. This is useful in case the transaction encountered and error that have since been fixed. The transaction can then be re-run to ensure that information isn't lost.
  • Mark transaction as reviewed - This marks a transaction a reviewed. This is to show that this transaction has been inspected by a user and does not need to be looked at again. Transaction are automatically marked as needing review when they encounter an error. This is so that a person can later know to inspect the transaction to see why it failed. Once the transaction has been inspected and dealt with it can be marked as reviewed using this button.
  • Flag transaction - This button allows the user to flag a transaction. This shows a flag icon next to the transaction in the transaction list and allows you to easily find it again by filtering for flagged transactions. This is useful for keeping track of certain transactions.
  • Next and Previous - These buttons allow you to easily go to the next or previous transaction in the transaction list.

Identifying Errors

The key purpose of the Error Management Console is so that you can identify and fix errors that have happened within the Health Information Exchange. To do this you can view error messages and the stacktraces for the errors that occurred for each error'd transaction. These can be viewed on the view transaction page described above.

There should be an descriptive error message or exception that should help identify what failed in the interoperability layer or one of the infrastructure services (eg. Client Registry, Provider Registry, Terminology Service or Shared Health Record). These can be viewed in the error description or stacktrace fields in the trasaction view page. Often the original error can be right at the bottom of the stack trace so make sure to check all the way bottom.

A few of the common errors are listed below with a description of what to do in each case:

  • Invalid provider ID
    • This means that the ID that was sent in the HL7 message does not match a provider in the Provider Registry. This could be caused by either the OpenMRS health facility not having the correct NID for a provider mapped in their system or that provider in new and should be added to the Provider Registry. To solve this problem you would have to figure out which these cases are true. This could be done by getting in contact with the health facility and checking up on the provider in question and either rectifying the record in OpenMRS or the Provider Registry.
  • Invalid client ID
    • This means that the ID that was sent in the HL7 message does not match a client in the Client Registry. This could be caused by a client not being registered in the Client Registry for some reason, maybe the registration message failed to go through. There is nothing you can really do to rectify this other than attempting to find out why the client 's registration message didn't go through and maybe re-running it so that that record can be created.
  • Invalid location ID
    • This means that the ID that was sent in the HL7 message does not match a facility in the Facility Registry. This is likely a mis-configuration of the OpenMRS system at a facility and that facility should be contacted to rectify that issue.
  • Unknown term used in ORU_R01, please use only RHEA codes. Unknown code: <code_sys> <code>
    • This means that the code used in the HL7 message could not be validated by the Terminology Service. This means either a mapping in the OpenMRS system is incorrect or the Terminology Service does not contain a code that needs to be used in the messages. This will more often than not be a problem in the OpenMRS systems mappings. This can be rectified by correcting the mapping.

If you cannot determine what is causing the error you should get in contact with the software developers that are in charge of maintaining the interoperability layer to see if they can identify what is causing the error.

Re-running Transactions

Transaction should be re-run as described above when the errors causing the problem are believed to have been fixed. Re-running a transaction will create a new transaction that is identical to the current transaction and attempt to run it through the system. Check for the new transaction in the transaction list to see if it was this time successful.