I know IRIS has a built-in testing framework, but I'm not sure how to write tests that validate the full message flow through a Production without depending on external systems. Do you mock Business Operations? Is there a pattern you use to test integration scenarios in an isolated and repeatable way?

Hi folks!

Suppose a new version of your amazing software solution built on IRIS needs some persistence change: some data needs to be converted, some classes get new properties or even renamed, and some data should be prepopulated for newly introduced persistent classes to keep the whole application data consistent.

What are your approaches? 

SQL-based scripts? ObjectScript, or Python? for both directions of migration, up and down? 

Do you autogenerate it with Claude/Codex? What about data-consistency tests?

COuld you please share your thoughts? or libraries?

Abstract

Common Table Expressions (CTEs) provide a structured framework for defining reusable intermediate result sets within SQL statements. InterSystems IRIS implements CTEs via the WITH clause, enabling clearer query composition and modular analytical processing while remaining fully integrated with the IRIS cost-based optimizer.

This article explores the semantics of CTEs in InterSystems IRIS, explains their interaction with query optimization, discusses appropriate deployment scenarios, and presents executable examples illustrating practical patterns for production environments.

Hey All!

I wanted to reach out and get some advice on the best way to interact with a external SQL database, as I'm finding the documentation quite confusing to follow. I'm new to using SQL within InterSystem, and I want to make sure I'm following the best practices.

In essence, what I am trying to achieve, is extracting certain values from a HL7 message and then insert those message field values into an external database. The ODBC, DSN and Credentials details are all setup and working correctly.

When I started building Smart Discharge Navigator, I faced a common challenge: FHIR data is stored as JSON bundles, but the analysis I needed required joining multiple resources together, the kind of thing SQL was built for.

InterSystems FHIR SQL Builder solved this completely. Instead of parsing JSON bundles in application code, I was able to write plain SQL directly against FHIR resource projections inside IRIS for Health. This article shows exactly how I used it to build the population-level readmission risk scoring engine at the heart of the application.

Back when I was a Developer Support Engineer in the InterSystems Worldwide Response Center (WRC), I would occasionally receive cases involving large message backlogs in a production. The customer would discover that a subset of queued messages were no longer useful and would ask a question similar to the following:

Is there an established best practice for mass-aborting messages in a specific component's queue that match a particular set of criteria?

An AI agent reads the FHIR patient record before the consultation, asks the right questions based on what it already knows, detects critical red flags, and writes its findings back — so the physician arrives prepared.

Healthcare Pain Points Addressed

Before a patient walks into a consultation room, a critical failure has already occurred: nobody read their medical history. The physician has 15 minutes. The patient repeats their conditions, medications, and allergies for the third time that year.

I've seen that %JSON.Adaptor makes it easy to serialize and deserialize objects to JSON, but I've also seen people building custom serialization logic. Are there scenarios where %JSON.Adaptor falls short, such as handling nested objects, null values or custom field naming conventions? What has been your experience?

If I need to add or change properties in a message class that is already being used by a running Production, what is the safest way to do this? Are there risks with existing messages in the queue or in the message store? Is there a migration strategy the community recommends?

I understand that Business Rules can be used to route or transform messages without touching code. But I'm not clear on when it's better to use a Business Rule versus handling the logic directly inside a BPL or a custom BP class. What criteria do you use to decide between them?

In .NET projects I usually rely on appsettings per environment. In IRIS Productions, settings are stored per component and seem tied to the namespace. What strategies do you use to manage different configurations across environments without manually changing settings every time you promote a Production?

Hi Community,

We're excited to invite you to the upcoming webinar: 

👉 Can FHIR also serve as input for operational management? 👈

🗓️ Date & Time: Wednesday, June 10th, 10 am CEST

In the previous article, we used pyprod to create production components while relying on the UI for production configuration. That same production can now be defined entirely in Python:

from intersystems_pyprod import Production, ServiceItem, ProcessItem, OperationItem

iris_package_name = "HelloWorld"

class MyProduction(Production):
    services = [
        ServiceItem(
            "MyServiceName",
            "HelloWorld.MyService",
            host_settings={"target": "MyProcessName"},
        )
    ]
    processes = [
        ProcessItem(
            "MyProcessName",
            "HelloWorld.MyProcess",
            host_settings={"target": "MyOperationName"},
        )
    ]
    operations = [
        OperationItem("MyOperationName", "HelloWorld.MyOperation")
    ]

The problem

How many times have we migrated an IRIS Instance to another machine, maybe even another version, and after a few days realized we forgot that one SSL Configuration critical for a Business Operations to work? Or maybe a credential, or a lonely class in a package by itself?

The solution

The simple solution is to make a checklist¹. A checklist of the entities we have to move. But simple checklists on Word documents are often forgotten, or just ignored.

Hi all,

I'm working on a DICOM router in InterSystems IRIS, based on the workshop-iris-dicom-interop (https://github.com/intersystems-ib/workshop-iris-dicom-interop) example on GitHub. I'm using EnsLib.DICOM.Process to route incoming images to different PACS destinations, where the target system is decided at runtime via a database lookup.

I've run into two issues I'd love some guidance on:

1. Dynamically changing the destination without disrupting transactions

Right now, if I want to send to a new PACS target, I'd need to add a new Business Operation and call

In the previous IoP article, I showed how IoP can expose Python messages to DTL by generating JSON schemas. That is useful when the message is primarily a Python object and we want the IRIS tooling to understand its structure.

This time, the direction is a little different.

Starting with IoP 3.7.1, a PersistentMessage can now be a native IRIS message body class. The Python class is still the source code you write, but the generated IRIS class extends Ens.MessageBody

READY is right around the corner, and this year the Application Services team from InterSystems will be hosting a IPM Users GroupMeeting during the conference!This will be held Wednesday, April 29^th during lunch from 12:30 – 1:30 (lunch will be served at the meeting room).

IPM version 0.10.7 was released on May 29th, 2026. As usual, you can check it out on the GitHub page or through the Community Registry.

Highlighted Features

Utility Scripts iriscli and ipm

IPM is now bundled with two convenience scripts that are runnable from a standard terminal. iriscli launches an interactive IRIS terminal and runs IPM commands directly. These are automatically installed to both ~/.local/bin/ and , so they work inside and outside of containers (Unix/Linux only).

Examples:

I have several Business Operations that share similar behavior, like building HTTP headers or parsing a specific response format. In C# I would extract this into a service class or a base class. What is the recommended way to do this in IRIS? Should I use a utility class, a common superclass, or is there another pattern the community prefers?

I have a Business Process that needs to call an external API that may take several seconds to respond. I'm worried that keeping the BP blocked waiting for the response could affect the overall Production throughput. Is there a recommended pattern for handling async calls inside a BPL or custom BP class to avoid this kind of bottleneck?

I'm approaching the need to send notifications through a Microsoft Exchange or Gmail servers. however my last foray into this, I was blocked due to an issue inside my SSL certificate is what I thought after the attempt.

So my attention will be on trying to match the cryptography in the SSL certificate I produce compared to the mail server I'm trying to use.

Has anyone else had an issue with this approach? My other option is Amazon SNS potentially. I do have a functional MS Teams channel for alerts, and can make different notification channels as well.

Any help or insights are appreciated. 

In our previous article, we explored the basics of unit testing in IRIS and the ways to apply it to a REST API. We even figured out how to test logic before finalizing network configurations and authentication, allowing us to focus solely on testing the API contents. Today, we will build upon that foundation and elevate our unit testing strategy by using another tool: %Populate .

At first glance, the %Populate class appears to be very simple. You can create a class that extends both %Persistent and %Populate and inherit a Populate method designed to generate randomized records.