Delphic AP release highlights – new features, enhancements, and fixes

September 2024

We’re excited to bring you up to date with new features released in Delphic AP version 9.3.1.

Key Highlights-

• HCL Notes / Domino 12.0.2 Compatibility
• Palga Mercurius ECU interface

New features & enhancements

HCL Domino 12.0.2 Compatibility

Delphic AP 9.3.1 now supports both HCL Notes / Domino 11.0.1 and 12.0.2, giving you the flexibility to upgrade to the latest HCL Notes / Dominos version.

Palga Mercurius ECU interface

The Delphic AP-Palga Mercurius interface enables pathology reporting to the national PALGA database.

With the Palga ECU (Electronische Consult Uitslag or Electronic Consultation Results) interface, Delphic AP Palga Mercurius users can request and receive second opinions from external laboratories, which are reported to the national Palga database. This further enhances Delphic AP’s compatibility with Palga Mercurius.

More on ECU Reports-

ECU Outbound reports

When Delphic AP users receive a consult request from an external pathologist, they log it as a Report only type request and add the external lab’s details in the Palga ECU section. After completing and signing the request, an ECU Outbound report message is sent to Palga Mercurius.

ECU Inbound reports

When Delphic AP users request a consult from an external pathologist, they use the Delphic AP Referred Out / External Consultation workflow. In the Referred out document, they enter the external lab’s details in the Palga ECU section. These documents are matched with corresponding ECU Inbound messages received by Delphic AP, which appends the details to the associated request. Users can then review consult reports from the Pathologist > All Work and My Work views.

Managing Unmatched ECU Reports: In cases where an ECU Inbound report cannot be automatically matched to a referred-out request, it is flagged as “Unmatched.” Delphic AP provides a dedicated “Unmatched ECU Inbound” view for easy monitoring. This view also offers the functionality to manually assign unmatched reports to the appropriate requests.

Faster Patient History Retrieval from Palga Mercurius

In the Lab Configuration document, the minimum delay time between requesting patient history (cipavraag) and retrieving it from Palga Mercurius (ciparesult) is now 0 minutes, down from the previous 5 minutes. This adjustment means administrators can allow users to retrieve patient history messages from Palga Mercurius without any delay.

Local Patient History Access

Delphic AP systems connected to Palga Mercurius can now access local laboratory patient history. When a new request is logged, the system sends both a Retrieve Local Patient History (vraag) message and a Request Patient History (cipavraag) message for other laboratories in the same agent run. All retrieved patient history is stored with the request and can be viewed via the Summary Reports hotspot.

Additional Laboratory Configuration Fields

The Laboratory Configuration document has been updated with two new fields replacing the previous Palga connection URL field:

1. Palga hostname
2. Palga path

These fields allow more flexibility in configuring the destination for each registering lab’s Palga post messages. For example, in the URL “https://www.example.com/pathname“:

• Hostname: “http://www.example.com“
• Path: “pathname”

Optimisations

Faster barcode searching in Pathologist view

We have improved the Barcode Quick Find agent in the Pathologist > All Work and My Work views. This allows for faster document retrieval when pathologists scan slide label barcodes from these views.

Improved Barcode Searching in Specimen Receipt View

The Barcode Quick Find agent in the Laboratory > Specimen Receipt view has been refined. This improvement enables quicker retrieval of all relevant documents related to external ID orders within the past 10 years when scanning a barcode from this view.

Streamlined Event Processing for Data Warehouse Updates

We have refined the event processing system for patient updates in the Data Warehouse. Previously, each patient information update generated multiple events—one for each affected request—potentially causing processing backlogs.

The new approach:

• Updates to patient data now only modify the PATIENT table.

This change significantly reduces the number of generated events and the overall performance of event processing for the Data Warehouse is improved.

Data management

Consistent processing of patient data from external systems

We’ve enhanced the HL7 Dictionary agent, Request Import agent, ADT Query, and HL7 ADT update process to standardise the handling of patient data received from external systems.

By implementing a common processing method for PID segments in HL7 messages, patient details are no longer unnecessarily updated for sequential HL7 Order and ADT interactions with identical PID segments. Instead, patient details are populated consistently on requests and patient documents, and only updated when necessary, ensuring the correct identification of patients at various stages of the lab workflow.

Enabling Autosaving of request documents

Delphic AP now incorporates autosave capabilities for several form types in the Main database, helping to mitigate data loss during unexpected system shutdowns. When autosave is enabled in your Notes client preferences, the following document types will be automatically saved:

• FISH
• Gynae Request
• Gynae Supplementary Report
• Picture
• Reference Request
• Request
• Supplementary Report

In the event of a system crash, the Delphic AP client will prompt users to recover any unsaved documents upon startup.

These enhancements aim to improve data consistency and reduce the risk of data loss, contributing to a more robust system.

Standardised Processing of External Patient Data

We have implemented a unified approach to handling patient data received from external systems across multiple components:

• HL7 Dictionary agent
• Request Import agent
• ADT Query
• HL7 ADT update process

This standardisation ensures:

• Consistent processing of PID segments in HL7 messages
• Reduced unnecessary updates for sequential HL7 Order and ADT interactions with identical PID segments
• Uniform population of patient details on requests and patient documents
• Updates only when necessary, ensuring accurate patient identification throughout the lab workflow

Bug Fixes

Lab Digit Handling in Palga Kern-UDPS Patient Updates

Issue: In multi-site configurations, the Palga Kern-UDPS agent omitted lab digits from request IDs when processing First incidences and follow up retrieval messages. This caused potential mismatches or update failures for patient records.

Resolution: The agent now correctly reinserts lab digits into request IDs.

Administrators must update Lab Configuration documents for any labs using request ID lab digits and interfacing with the Palga Kern-UDPS system in a multi-site environment.

Important Note: This update applies only to the Palga Kern-UDPS interface.

Amended Reports for Gynae Cytology History Requests

Issue: Creating amended reports for Gynae Cytology History requests triggered errors due to process type mismatch.

Resolution: The system now checks both process type and request type, allowing amended reports to be assigned to Screeners for Gynae Cytology History requests.

Incorrect HL7 Patient Query Response Handling

Issue: Incorrect interpretation of HL7 ADR files led to accumulation in the HL7ADR directory. When retrieving patient information from an external system, Delphic AP sends an HL7 QRY (patient query) message and temporarily stores the ADR (patient query response) file in the HL7ADR directory until patient details are extracted. Previously, if the MSA.1 (acknowledgement code) field of the response contained any value other than “AA” (Application Accept), Delphic AP interpreted it as the patient not being found, and the files accumulated in the directory without being deleted.

 Resolution:

• The HL7 ADR file is always deleted from the directory after processing, regardless of the value in MSA.1.
• An MSA.1 value of “AA” (Application Accept) or “CA” (Commit Accept) indicates that the patient was found, and the patient details are extracted and displayed.
• An MSA.1 value of “AE” (Application Error), “AR” (Application Reject), “CE” (Commit Error), or “CR” (Commit Reject) is interpreted as the patient not being found. The resulting dialog box clarifies the response to users and includes any text found in MSA.3 (describing the error condition) for better troubleshooting.

Cancelled Request Identification in Specimen Receipt View

Issue: When Delphic AP processes an HL7 order message with a “CA” (cancel) status, it marks the request as “Cancelled” and displays the message “REQUEST CANCELLED – DO NOT PROCESS” on the main request document. Previously, this message only displayed on cancelled requests that had been receipted.

Resolution: To ensure that cancelled requests can be clearly identified and to prevent accidental processing, the “REQUEST CANCELLED – DO NOT PROCESS” text now also displays on cancelled requests when opened in the Specimen Receipt view.

Ad Hoc Cassette Printing Synchronisation

Issue: The Ad hoc cassettes function in the Printed Cassettes view allows users to print cassette labels on-demand, bypassing the standard workflow. Previously, the No. cassettes field did not automatically update to match the range entered in the Block IDs field. For example, if the default value in the No. cassettes field was “1” and the user entered a block ID range of “A-D” (to print cassettes 1/A to 1/D) without adjusting the number of cassettes, only block 1/A would be printed.

Resolution: With this update, the values in the No. cassettes and Block IDs fields are now kept in sync and automatically adjust each time the user changes one of these fields. For example, entering the block ID range “A-D” updates the number of cassettes to print to “4”, ensuring all required cassettes are printed correctly.

Incorrect processing of patient merge messages from Delphic LIS

Issue: Following an update at v9.2.5, the Request Import agent incorrectly processed patient merge messages from Delphic LIS, resulting in incorrect data being displayed for requests from merged patients in Delphic AP.

Resolution: Unsigned requests for the merged patient are now updated correctly.

Request Details Exclusion Search Formatting

Issue: From the Enquiry or Pathologist > Searches views, via the Request details tab users can create and save searches to find requests that meet specific criteria. They can also exclude certain details from the search parameters using the and do NOT include options. However, when selecting criteria to exclude from a search, the query string incorrectly used | (or) instead of & (and), leading to incorrect search outputs.

Resolution: This function now correctly excludes the specified requests from a request details search.

Re-archived History Request Duplication

Issue: The Archive Request agent, responsible for archiving complete requests into the current archive database, failed to identify previously archived history requests imported via the History Request import agent. As a result, when a history request was copied back into the main Delphic AP database and then re-archived, the agent did not recognise its existence in a prior archive database. This led to the request being duplicated in the current archive database.

Resolution: Existing archived history requests are correctly identified and removed from their previous archive database during re-archiving. Additionally, re-archived history requests in the current archive database include a history line confirming this action.

HL7 Order Import Clinical Details Formatting

Issue: The HL7 order import process incorrectly appended “Source:” to a request’s Clinical details field when the NTE.2 (source of comment) field was blank.

Resolution: The Request Import agent will now only retrieve data from the NTE.3 (comment) field for the clinical details, omitting the unnecessary NTE.2 field and its “Source:” prefix.