In healthcare, interoperability is the ability of different information technology systems and software applications to communicate, exchange data, and use the information that has been exchanged.
Hi Community,
Let's gather at the online meetup with the winners of the InterSystems Programming Contest: AI Agents for FHIR! It's a great opportunity to chat with the InterSystems Experts team and our contestants.
Winners' demo included!
Date & Time: Thursday, June 18, 11:30 am EDT | 5:30 pm CEST
Hi Community,
It's time to announce the winners of the InterSystems Programming Contest: AI Agents for FHIR!
A big thank you to our 18 fellow members who built
This competition received impressive submissions, each reflecting innovation and creative thinking. With so many strong entries, selecting the best was a true challenge.
Let's meet the winners and look at their projects:
Amazon SQS (Simple Queue Service) is a managed message queue service that provides a simple, durable, and scalable mechanism for exchanging messages between applications. It is particularly well suited for event-driven integration patterns and loosely coupled architectures.
Bear in mind that the AWS SQS adapter is based on InterSystems PEX Network and requires the Java External Server to be enabled.
When using Amazon SQS you can either take the role of a Consumer or a Publisher.
FHIR Patient Snapshot Agent is a small open-source application built for the InterSystems AI Agents and FHIR Programming Contest.
The project implements the suggested Smart Patient Summary Generator idea: it retrieves structured FHIR resources for a selected patient and generates a concise, role-specific patient summary.
The goal is not to diagnose or recommend treatment.
Hi Community,
It's voting time! Cast your votes for the best applications in our InterSystems Programming Contest: AI Agents for FHIR:
Voting period: June 8 to June 14, 2026
How to vote? Details below.
At 4:57 PM on a Friday, a routine laboratory order failed.
The patient's sample was already in transit. The external reference laboratory rejected the request — it could not uniquely identify the patient. The insurance operator rejected authorization for a different reason. Neither system spoke the same language, neither exposed compatible error messages, and the only integration layer in the middle simply forwarded requests.
A laboratory technician spent the next 25 minutes navigating portals, copying identifiers, and manually reconciling data between systems.
Most "AI agent + FHIR" projects end up with the same shape: a FHIR server over here, a vector database over there, and a Python service in the middle whose job is to call an embedding API, marshal float arrays back and forth, and keep two datastores in sync. Three moving parts, two network hops, and an embedding client you now own forever.
Triage Park: our entry for the InterSystems Programming Contest: AI Agents for FHIR, doesn't have any of that. The agent never computes an embedding. It never imports an OpenAI embeddings client. There is no vector database.
Hospital readmissions cost the US healthcare system $17 billion annually. A significant portion of those readmissions are preventable — but only if the right information reaches the right clinician at the right moment: at discharge.
That's the problem I set out to solve with Smart Discharge Navigator, my entry for the InterSystems Programming Contest: AI Agents for FHIR 2026.
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?
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")
]
Hello everyone,
The InterSystems Learning Services Certification Team is pleased to announce the release of the HealthShare Unified Care Record Deployment Specialist Certification exam. The exam is now available for purchase and scheduling in the InterSystems exam catalog.
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
We have a long running InterSystems Engine with an Interface Development Team. We have implemented basic interface and code development processes using mostly manually created helper tasks and functions.
We are looking to upgrade these processes by installing and starting to use Embedded GIT in our DEV spaces first. We will not use it to deploy changes to PRODUCTION at first, keeping our same current process that the team is very comfortable with.
We plan to start by using the BASIC mode in GIT, to avoid confusion over multiple branches and other version control functions.
Hi Developers!
Here are the technology bonuses for the InterSystems Programming Contest: AI Agents for FHIR that will give you extra points in the voting:
Hi Community,
Interoperability metrics were enabled for a production using ##class(Ens.Util.Statistics).EnableSAMForNamespace(). However, after running DisableSAMForNamespace() and DisableStatsForProduction(), the metrics continue to appear in the endpoint output.
Is there a way to completely stop these interoperability metrics from displaying in the API metrics stream? Is there an additional step or cache clear required?
I’m looking for recommendations to improve interoperability performance in InterSystems IRIS, especially when handling large volumes of HL7 or healthcare-related messages.
What are the best practices for optimizing productions, business services, operations, and message processing performance? I’d also like to know if there are recommended monitoring tools or settings commonly used in production environments.
Hello Community!
We’re excited to invite you to our upcoming Hebrew webinar, presented by @Keren Skubach, an InterSystems Senior Sales Engineer:
👉A Practical Guide to Leveraging AWS Adapters and APIs 👈
📅 Date & time: June 2nd, 3:00 PM IDT
Discover how to accelerate cloud-based integration with InterSystems' native AWS adapters for S3, SQS, SNS, and CloudWatch.
This session provides a practical look at building modern interoperability workflows — from secure file ingestion and asynchronous messaging to automated notifications and centralized monitoring.