eLearning

An eLearning interface from an LMS/HRIS automates the manual entry of test and quiz results eliminating errors and omissions and also automatically provides a consolidated view of each operator’s testing performed, competencies completed, along with updated employee information.

Most health care organizations manage employees and competency in disparate systems, for example, an LMS for learning and education and an HRIS for employee records. Point of care (POC) systems need information from both and often this information must be manually entered into the POC system.

The QML eLearning interface can perform some or all the following tasks that are vital to managing your point of care operators.

  • Automatically certify operators based on samples performed and competencies complete, allowing you to manage only exceptions through the CertificationQ.
  • Expand competencies beyond quizzes, if you can define these within the LMS, and import them as well. Examples could include any of the following:
    • Direct observation
    • Monitoring
    • Recording and reporting test results
    • Review of intermediate test results or worksheets
    • Quality control
    • Proficiency testing
    • Preventive maintenance
    • Direct observation of instrument maintenance and calibration
    • Problem-solving skills as appropriate to the job
  • Automatically add new operators and inactivate existing operators.
  • Automatically update operator demographics such as name and location changes.
  • All recertification data, such as competencies and samples performed, requested of sites by accrediting agencies will now be within your QML system.

Patient Information (ADT)

With patient information, the ADT (admission, discharge, transfer) messages can be received directly from the HIS/EMR, an engine or the LIS. Multiple ADT feeds can be configured for simultaneous receipt of data from multiple systems. Patient information received through the ADT feed is used to:

  • Validate the patient ID received from the device
  • Select an episode/account when the patient ID received from the device is the medical record number
  • Provide account number, medical record number and other patient information in the result message sent to the LIS/EMR, for those that require more than just a single patient identifier
  • Provide data for positive patient ID by:
    • Sending data back to devices in response to host query messages sent to QML
    • Passing the same ADT message received to device software that can accept information for creating patient lists in their devices
    • Formulating patient lists for sending to device software or directly to the devices that can accept this type of data

Orders

Orders messages can be received directly from the HIS/EMR or an LIS. As with the ADT interface, multiple order feeds can be configured for simultaneous receipt from multiple systems. Order information received through the feed is used to:

  • Validate the order number entered into the device
  • Select the appropriate order if the patient ID was entered into the device
  • Use the patient information for reference range processing and flagging when sending results directly to the EMR

This interface is not required if the order/accession number was scanned into the device. The results send as a solicited result with the sample ID entered/scanned.

A single QML system can be configured to process both unsolicited and solicited results, with or without ADT or orders interfaces. In addition, a single process can be defined to send a solicited result when an order matches, or if not matched, will send the same result as unsolicited.

Unsolicited and Solicited Results

The result interface can be HL7 unsolicited (no order exists in the receiving system) or solicited (an order does exist in the receiving system). Scripted (aka terminal emulation, screen scraping) interfaces for receiving systems that cannot accept HL7 unsolicited result messages are also offered.

QML provides flexibility by offering custom functionality, but eliminates the need to maintain individual interfaces for each customer. The QML Result Interface is a single component of each of the output types (EDI or Script), even though different LIS/EMR vendors require different message formats. Propriety mapping capabilities are available with each component to vary the output as required by the LIS/EMR.

QML was designed to allow multiple, simultaneous outputs to one or multiple LIS/EMRs. The EDI and Script components are independent from each other and can coexist on the same system. Multiples of the same output type can also be configured, all without additional hardware. This allows an IDN with multiple facilities that might have different LIS/EMRs to maintain a single QML for all facilities, yet provide result interfaces to their respective LIS/EMRs.

The EDI component is a POCT1-A compliant HL7 result interface with optional receipt of an Application Acknowledgement containing the LIS-assigned accession number or reason for rejection. When the LIS/EMR cannot process unsolicited results via the EDI, results can be entered via a Script (aka Terminal Emulation) customized for each result entry screen. Both the EDI and Script options can send unsolicited and solicited results.

QML can accommodate a combination of solicited and unsolicited results, with or without ADT or orders interfaces. This is beneficial in situations where some testing is performed using the patient ID, but other testing is performed using an order/accession number. Configuration options, not custom code, identify results as either solicited or unsolicited and then mapped/entered accordingly. In addition, a single process can be defined to send solicited results when an order matches; if it does not match, send the same sample’s results as unsolicited.