The first developer previews of InterSystems IRIS^® data platform, InterSystems IRIS^® for Health, and HealthShare^® Health Connect 2025.1 have been posted to the WRC developer preview site. Containers can be found on our

Introduction

What's in a name? That which we call a rose
By any other name would smell as sweet

William Shakespeare, "Romeo & Juliet"

In this article, we will describe a set of naming conventions for ObjectScript code.

Starting out with ObjectScript, it is really exciting, but it can also feel a little unusual if you're used to other languages. Many beginners trip over the same hurdles, so here are a few "gotchas" you'll want to watch out for. (Also few friendly tips to avoid them)

NAMING THINGS RANDOMLY

We have all been guilty of naming something Test1 or MyClass just to move on quickly. But once your project grows, these names become a nightmare.

Hi Developers,

We are happy to announce the new InterSystems online programming contest dedicated to all things health-related:

🏆 InterSystems FHIR and Digital Health Interoperability Contest 🏆

Duration: May 12 - June 1, 2025

Prize pool: $12,000

I have started working on utilizing Epic on FHIR about a month ago.

Creating a Public Private Key Pair

mkdir /home/ec2-user/path_to_key
openssl genrsa -out ./path_to_key/privatekey.pem 2048

For backend apps, you can export the public key to a base64 encoded X.509 certificate named publickey509.pem using this command...

I joined InterSystems less than a year ago. Diving into ObjectScript and IRIS was exciting, but also full of small surprises that tripped me up at the beginning. In this article I collect the most common mistakes I, and many new colleagues, make, explain why they happen, and show concrete examples and practical fixes. My goal is to help other new developers save time and avoid the same bumps in the road.

InterSystems FAQ rubric

If you want to raise an arbitrary custom error in a TRY block, you can pass an exception with a throw as follows. In the following example, a custom error is raised if Stcount is less than 1.

Interoperability on Python (IoP) is a proof-of-concept project designed to showcase the power of the InterSystems IRIS Interoperability Framework when combined with a Python-first approach.IoP leverages Embedded Python (a feature of InterSystems IRIS) to enable developers to write interoperability components in Python, which can seamlessly integrate with the robust IRIS platform. This guide has been crafted for beginners and provides a comprehensive introduction to IoP, its setup, and practical steps to create your first interoperability component. By the end of this article, you will get a clear understanding of how to use IoP to build scalable, Python-based interoperability solutions.

FHIR repositories, applications and servers typically serve clinical data in small quantities, whether to return data about a patient, their medications, vaccines, allergies, among other information. However, it is common for a large amount of data in FHIR/JSON format to be requested to be used to load into Data Lakes, identifying study cohorts, population health, or transferring data from one EHR to another. To meet these business scenarios that require large extractions and loads of data, it is recommended to use the FHIR Bulk Data Access feature provided by HL7 institution.

Since the introduction of Embedded Python there has always been doubt about its performance compared to ObjectScript and on more than one occasion I have discussed this with

The Istio Service Mesh is commonly used to monitor communication between services in applications. The "battle-tested" sidecar mode is its most common implementation. It will add a sidecar container to each pod you have in your namespace that has Istio sidecar injection enabled.

I know that people who are completely new to VS Code, Git, Docker, FHIR, and other tools can sometimes struggle with setting up the environment. So I decided to write an article that walks through the entire setup process step by step to make it easier to get started.

I’d really appreciate it if you could leave a comment at the end - let me know if the instructions were clear, if anything was missing, or if there’s anything else you'd find helpful.

The setup includes:

✅ VS Code – Code editor
✅ Git – Version control system
✅ Docker – Runs an instance of IRIS for Health Community
✅ VS Code REST Client Extension – For running FHIR API queries
✅ Python – For writing FHIR-based scripts
✅ Jupyter Notebooks – For AI and FHIR assignments

Before you begin: Ensure you have administrator privileges on your system.

In addition to reading the guide, you can also follow the steps in the videos:

For Windows

https://www.youtube.com/embed/IyvuHbxCwCY
[This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]

When we create a FHIR repository in IRIS, we have an endpoint to access information, create new resources, etc. But there are some resources in FHIR that probably we wont have in our repository, for example, Binary resource (this resource returns a document, like PDF for example).

I have created an example that when a Binary resource is requested, FHIR endpoint returns a response, like it exists in the repository.

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