We all know that having a set of proper test data before deploying an application to production is crucial for ensuring its reliability and performance. It allows to simulate real-world scenarios and identify potential issues or bugs before they impact end-users. Moreover, testing with representative data sets allows to optimize performance, identify bottlenecks, and fine-tune algorithms or processes as needed. Ultimately, having a comprehensive set of test data helps to deliver a higher quality product, reducing the likelihood of post-production issues and enhancing the overall user experience.

In this article, let's look at how one can use generative AI, namely Gemini by Google, to generate (hopefully) meaningful data for the properties of multiple objects. To do this, I will use the RESTful service to generate data in a JSON format and then use the received data to create objects.

InterSystems IRIS has quite a few different kinds properties. Let’s put them in order so that they make better sense.

First of all, I would divide them into categories:

• Atomic or simple properties (all those %String, %Integer, %Data and other system or user datatypes)
• References to stored objects
• Built-in objects
• Streams (both binary and character)
• Collections (which are divided into arrays and lists)
• Relationships (one-many and parent-children)

Some of these kinds of properties are quite straightforward. For example, atomic properties:

Property Name As %Name;
Property DoB As %Date
Property Age As %Integer

Because I had no idea how to build an integration solution for HL7 and didn't know where to start, I decided to follow the course Building Basic HL7 Integrations with InterSystems on Learning portal to get at least the idea of where to begin. After I studied all of it, I decided it might be a good idea to share my thoughts and reflections about it with everyone.

In the previous article, we've seen the structure of one of the most used types of HL7 message - ADT (Admit, Discharge, Transfer) and an example of ADT^A04 with the description of all its fields. Now let's look at another flow of data having to do with ordering and fulfilling the orders of tests. I'm talking about ORM (as of version 2.5 you should use specific messages to order tests, like OMG, OML, OMD, OMS, OMN, OMI, and OMP), ORL and ORU messages. In a very simplified case, the exchange of data may look like this.

Let's look at these messages in more detail.

HL7 (Health Level 7) is a set of technical specifications for computerized exchanges of clinical, financial and administrative data between hospital information systems (HIS). These specifications are variously integrated into the corpus of formal American (ANSI) and international (ISO) standards.

The L7 of HL7 indicates that it is a standard that operates at layer 7, in other words at the application layer, of the OSI model. This means that HL7 does not have to take into account exchange security considerations, or those of message transport (this being ensured by lower-level layers such as SSL/TLS for security or TCP for the transport of data for example). To be more precise, layer 7 supports communications for end-user processes and applications and the presentation of data for user-facing software applications. As the highest layer of the OSI model, and the closest to the end user, layer 7 provides application-specific functions such as identifying communication partners and the quality of service between them, determining resource availability, considering privacy and user authentication, and synchronizing communication, as well as connecting the application to the lower levels of the OSI model.

Returning to the HL7 standard, the HL7 version 2 standard (also known as Pipehat) was originally created in 1989 but is still being used and updated regularly, resulting in versions 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1, 2.6, 2.7, 2.7.1, 2.8, 2.8.1, 2.8.2 and 2.9. The v2.x standards are backward compatible (e.g., a message based on version 2.3 will be understood by an application that supports version 2.6) and in higher versions, you will see some fields are left just for it.

Despite it being more than 30 years old, HL7v2 remains the most widely used healthcare interface standard by a large margin according to the HL7.org portal that tells that:

As you can see in my profile I teach at a university and I wanted to share my take on teaching IRIS (or Caché before it).

It’s been some time but I remember seeing a series of articles by @Yuri Marx earlier this year about the course “Developing with InterSystems Objects and SQL”. He actually gave a brief description of what’s done on Day 1, Day 2, and Day 3 with comments from instructor @Joel Solon. And I thought to myself, it may be interesting to share my experience.

In the first installment of this article series, we discussed how to read a “big” chunk of data from the raw body of an HTTP POST method and save it to a database as a stream property of a class. Now let’s look at how to save such data and metadata in JSON format.

Some readers of my previous article, Caché eXTreme for .NET - direct access to globals from C#, wondered if you could access information not just from the same instance in which you’re working, but also from another instance on the same computer, or from an instance located on another computer in the same local network. Some theorized, correctly, that this would be possible using the Enterprise Cache Protocol (ECP). In this article I’m going to show how it can be done.