Patient Information

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 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 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 will be sent 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 is matched, or if not matched, send the same result as unsolicited.


An eLearning interface from an LMS/HRIS eliminates errors and omissions associated with this manual entry 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 testing (POCT) systems need information from both of these and often this information has to be manually entered into the POCT system.

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

  • Automatically certify operators based on samples performed along with competencies completed in order to manage exceptions only through the CertificationQ.
  • Expand competencies beyond quizzes if you can define these within the LMS and import those 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.

Result Interface

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 offered as well.

QML provides the 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. Each of the two components offer proprietary mapping capabilities that allow format changes through configuration options in order to vary the output.

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 is matched; if not matched, send the same sample’s results as unsolicited.