#InterSystems IRIS for Health

インターシステムズは、InterSystems IRIS data platform、InterSystems IRIS for Health および HealthShare Health Connect のバージョン 2026.1 をリリースをしました。2026.1 は、拡張メンテナンス（EM）リリースです。
 

リリースハイライト

1. データベース・スケーラビリティの強化

   データベースの容量制限が撤廃されました。これにより、従来の容量制限をこえてもデータ移行が必要なく、円滑にシステム拡張できるようになりました。また低レベルパフォーマンスも改善され、大規模運用がさらに最適化されています。

2. テーブル・パーティショニング

   ユーザー定義の論理キーに基づきテーブルと関連インデックスデータを分割し、データベース間で簡単にマッピングできるようになりました。これによりストレージの階層化が可能となり、大容量テーブルにおけるクエリパフォーマンスと運用効率が向上しました。この機能は早期アクセス・プログラムで提供されている実験的な機能です。早期アクセス・プログラムに参加いただくと、機能のアップデートを受け取ったり、フィードバックを送信することが可能となります。

相互運用プロダクションでは、HTTPクライアントとして動作するビジネスオペレーションを常に設定することが可能です。このオペレーションはOAuth 2.0による認証を利用しますが、この認証方式に対応するためにはオペレーションのカスタマイズが必要でした。 最近リリースされた v2024.3以降では、 この処理をより容易に行うための新機能が追加され、新たな設定オプションが提供されています。

HTTPアウトバウンドアダプターをご利用のビジネスオペレーションにおいて、OAuthグループの下に新しい設定項目が追加されております。

例えば：

• アクセストークンの配置 (ヘッダー | 本文 | クエリ)
• グラントタイプ (パスワード | JWT認証 | クライアント認証情報)

新しいOAuth関連の 設定に関するドキュメントはこちらでご覧いただけます。 

関連するオペレーションのスクリーンショットの例を以下に示します：

カスタムロジック内でのグローバルのSetおよびKillがジャーナルに記録されない問題を修正しました。修正対象となったカスタムロジックは、%CSP.SessionEvents のサブクラスを介して実装された CSP セッションイベント用に実行されるカスタムロジックです。

この問題は、カスタムロジックがミラーリングされたデータベースに対して行ったSetおよびKillでは発生しません。この条件下では、操作は通常どおりジャーナリングされます。

根本原因は、当該ロジックを実行するデーモンプロセスがプロセスごとのジャーナリング状態を、起動元プロセスから受け継いでいることにあります。

監査はサーバーのセキュリティを確保する上で極めて重要な機能であり、かなり 以前から、サーバーで実行されるSQL文を監査する機能を提供しております。

v2024.3 が既にリリースされておりますが、監査すべきこれらイベントを定義するためのより詳細なオプションを提供しております。

従来は、アクセスメカニズムに準じてSQL文の監査を決定することができました。例えば、JDBC/ODBCからの文の実行と、埋め込みSQL (例えば： コード内で&&sqlを使用する場合など) と、ダイナミックSQL(例えば：コード内で%SQL.Statement%SQL.Statementを使用する場合や、Mgmt. ポータルのSQLクエリ実行、あるいはターミナルのSQLシェルからの実行など）、そして今回、これに 加えて、 特定の種類のステートメントのみを監査対象とすることも可能です（アクセス制御機構に基づき、従来と同様に）。対象となる種類は以下の通りです：

• DDL （データ定義言語） - 

データベースの要素や設定、その他のデータ以外のものを変更する文です。例：CREATE / ALTER TABLE

• DML (データ操作言語) - 

データを変更する文です。

最近あるお客様にIRIS for Healthをご紹介する機会があり、技術者の方向けのデモを交えた説明をするためにIRIS for Healthのデモ環境の準備をしました。

元ネタは @Mihoko Iijima がポストした以下の投稿です。

FHIR R4 リソースリポジトリを簡単にお試しいただける開発環境テンプレートのご紹介

非常にわかりやすい動画での説明もあるのでご覧ください。

これから試す方向けに、新しいバージョン（2025.3）でお試しいただけるよう若干の修正をしましたので、紹介します。

https://github.com/TomoOkuyama/iris4h-demo

主な修正点は以下です。

• IRIS for Health 2025.3 に対応 — ベースイメージを最新バージョンに更新
• JsonAdvSQL ストレージ戦略を採用 — 2024.1 で導入された新しい FHIR サーバーのデフォルトストレージ戦略です。従来の JSON ストレージ戦略と比べ、FHIR REST API の検索性能・標準準拠性・スケーラビリティが大幅に向上しています。
• 電子カルテ UI を今風にアップデート — FHIR API だけで動作する患者サマリ画面に刷新しました。

メッセージを 簡単に再送信する機能は、相互運用性における当社の強力な特徴の一つであります。

v2024.3 がまもなくリリースされます（（開発者プレビュー版は既に利用可能です）  既に 公開済みです。これにより、さらに簡単になりました！

Visual Trace 内から、メッセージヘッダーの横に「再送信」ボタンを見つけられます。こちらをクリックすると、通常の「メッセージ再送信エディター」が表示されます（メッセージビューアーを経由して特定のメッセージを 検索する必要はありません）。

以下に、その例を示します：

関連するリリースノートもご覧ください。

[概要]

[発生する問題]

上記で指定されたバージョンでは、データベースキャッシュが 2,097,152MB(2TB) 以上の場合、インスタンスの起動が失敗したり、稼働中にシステムがハングする可能性があります。キャッシュ値を手動で設定していないインスタンスの初期データベースキャッシュは、システム物理メモリの 25% になるため、物理メモリが 8TB 以上ある場合は、キャッシュ未設定のインスタンスでは本障害が発生する可能性があります。詳細については、以下のドキュメントをご参照ください。

InterSystems IRIS for Health v2024.3 は、すでにしばらく前より 開発者向けプレビュー版として 提供されており、今回導入された FHIR 検索に関連する新しいサポートについてご紹介いたします。

以下の2つの修飾子 のサポートが追加されました：-

• not
• missing

これにより、 より柔軟で洗練された、より豊富な検索クエリが可能になります。

また、検索結果のパラメータ -

• _maxresults

を使用すると、よりコンパクトな（そしておそらくより効率的な）結果を得ることができます。

関連するリリースノートもご覧ください。

今回は、プログラミングというほどのこともないですが

IRISのフロントエンド開発ツールとしてReactを利用しています。

Reactに限らずWeb開発のフレームワークを利用する場合のポイントとしてCSSフレームワークをどうするかというのがあります。

今までは、定番というか一番とっつきやすいBootStrapを使用してきました。

利用が簡単な分、カスタマイズの幅が少ないかなということを感じていました。

とはいえ、他のCSSフレームワークを使うにしても、それをまた学習して、１から書き直すのも大変だなということでそのままにしてきました。

今回、Claude Codeという最強のツールを得たことで、BootStrapをMaterializeに変更するように依頼してみました。

結果は、一発で修正完了

実行確認まで5分もかからないスピード感で終了しました。

もし自分でMaterializeを自習して、実装した場合は、少なくとも２、3日はかかったのではないかと思います。

BootStrapの画面

Materializeの画面

すっかりClaude Codeにはまってきてしまいました。

前回はIRISデベロッパーらしくObjectScriptプログラミングの話ですが、今回は、Pythonプログラミングです。

私は、個人会社を持っていまして、経理の細かいことは、当然税理士さんにお任せなのですが、とはいえ日々の経費の管理は自分でやる必要があります。

基本はエクセルに経費情報を入力するというオペレーションなのですが、入力を省力化するためにIRISデータベースを使用したPythonプログラムを作っていました。

その中で本当はやりたいのだけれども、非常に煩雑で面倒臭い処理(決して難しい処理ではないですが)を先延ばしにしてきました。

そこでこれはClaude Codeの格好の題材だと思い、依頼してみることにしました。

結果は、三回のやり取り（実際には、二回目の依頼の際に間違えて送信ボタンを押したので、実質的に二回）で10分もかからずに修正が終わり、期待した通りの結果を得ることができました。

もし自分でコーディングをした場合、おそらく半日仕事、下手をすれば1日仕事だったかもしれません。

この経験を通して感じたのは、既存プログラムの修正には非常に使えるということです。

多少依頼内容に曖昧な点があっても、既存のコードを非常に高速かつ完全、網羅的に理解してくれるので、そういう曖昧性をある意味埋めてくれます。

最近話題のClaude Codeを使って、ObjectScriptプログラミングをトライしてみました。

もちろんClaude CodeにObjectScriptのコードを書かせるにはそれなりの指示が必要ですが、適切なプロンプトを与えると想像以上にちゃんとしたObjectScriptコードを書いてくれます。

今回試したのは、少し前に投稿したCSPの#server問題に対応するため、#serverをREST APIに書き換えるというものです。

元のソースは、

https://github.com/wolfman0719/shopdemo

これはCSPのデモアプリケーションですが、しっかりと#server機能を使用しています。

結論をいうと、%sessionがRESTとCSP間で共有できないという根本問題があって、実行成功までには至っていませんが面倒なコーディングをかなりカーバーしてくれることがわかります。

(REST APIをCSPクラスで実装することで%session共有の問題を回避でき、Claude Codeが生成したロジックの正しさは証明されました)

そして、Claude Codeは、 ObjectScriptのことかなり理解してくれています。

ObjectScriptプログラマーが少ない問題を大きく改善してくれる可能性があります。
 

それでは、私がどのようなことを行ったか説明します。

はじめに

あるお客さんから、ワークフローの待受画面での新着通知方法についてご相談がありました。

• 単純なポーリングだと、通知の遅延や、サーバリソースを消費する
• ロングポーリングは、待ち受け画面のためにIRISのライセンスを消費する
• MQTTなどを使うと専用のサーバプロセスが必要

何か良い方法は無いでしょうか。 といった内容です。

この課題に対して調査したところ、以下の方式が見つかりました。

• ブラウザからSSE(Server-Sent Event)方式を使い、nginx上にアクセス
• IRIS側から通知が必要なクライアントのIDに対してnginxにメッセージをPOST
• nginxがルーティングを行い、当該クライアントにメッセージを通知

今回は以下の点について手順や設定等解説していきたいと思います。

• nginx のソースビルドと Web Gateway のインストール
• nginx-push-stream-module を使った SSE (Server-Sent Events) 通知
• ブラウザ受信 (/subscribe) とサーバ送信 (/publish) の最小実装

全体構成

まずは全体像です。データの流れをシンプルに分けることで、役割が明確になります。