I have attached a document that describes the product I have developed called NiPaRobotica Pharmacy. This is an interface I developed that accepts Pharmacy Dispense Requests and converts the line items on the order into dispense dialogues which it sends to pharmacy robots. I deployed the interface into 3 Hospital pharmacies two of which had 6 robots that were arranged in such a way that the dispense chutes channelled medications to desks by the pharmacists sitting in windows serving 1200 patients a day. The robots cut the average waiting time from 2 hours down to one hour.

One of the pain points for maintaining HL7 interfaces is the need to run a reliable regression test upon deployment to new environments and after upgrades. The %UnitTest class allows unit tests to be created and packaged alongside interface code. Test data can also be maintained within the unit test class, allowing for quick and easily repeatable smoke-testing and regression testing.

Resources:

• Standard %UnitTest class

I was working on a DTL but kept getting ERROR #5002... MAXSTRING errors. The problem was that most of the DTL GUI action steps only support the string data type when working with the segments. A %String has a limit of 3,641,144 characters and my OBX5.1 was 5,242,952 characters long as the example provided. Of course PACS admin stated ultra high quality up to and including 4K resolution files were needed, so we could not get the vendor to compress or reformat these files to compressed jpg or something similar.

Do you ever spend an age entering criteria in the message viewer page, trying to find a message just to realise you're in the wrong instance of IRIS?

Or get lost in a sea of message tabs struggling to spot that Visual Trace page your were JUST looking at?

Well, have you tried the IRIS WHIZ browser extension and its suite of tools designed to help you avoid such unpleasantness?

Hi Community,

In this article, I will introduce my application iris-HL7v2Gen .

IRIS-HL7v2Gen is a CSP application that facilitates the dynamic generation of HL7 test messages. This process is essential for testing, debugging, and integrating healthcare data systems. The application allows users to generate a wide variety of HL7 message types, validate their structure against HL7 specifications, explore the message hierarchy, and transmit messages over TCP/IP to production systems. These features are particularly useful in settings where compliance with HL7 standards is mandatory for interoperability between different healthcare organizations or systems.

Application Features

• Dynamic HL7 Message Generation: Instantly create HL7 messages for a range of message types, facilitating comprehensive testing.
• Message Structure Exploration: Visualize the structure of generated messages based on HL7 specifications.
• Value Set Visualization View predefined sets of allowable coded values for specific fields.
• Message Validation: Validate messages against HL7 standards to ensure compliance.
• TCP/IP Communication: Easily transmit messages to production using TCP/IP settings.
• Broad Message Type Support: Supports 184 different HL7 message types, ensuring versatility for various healthcare integration needs.
• ClassMethod: Generate a Test Message by Invoking a Class Method
• Version Support: Currently Supports HL7 Version 2.5

Background:

This guideline provides an overview of how to design and implement a REST API interface for querying patient demographic data from an Electronic Patient Record (EPR) system using HealthConnect. The process involves sending a query request with the patient's identification number, retrieving the response from the EPR system, extracting the required patient demographic data from the HL7 message, and sending it as a JSON response to the supplier. The high-level process diagram is shown below (Screenshot 1).

Like many others probably find themselves, we were stuck doing live data mapping in our Interface Engine that we really didn't want to do, but had no good alternative choice. We want to only keep mappings for as long as possibly needed and then purge expired rows based upon a TTL value. We actually had 4 use cases for it ourselves before we built this. Use cases:

Overview