ヘルスケアでは、相互運用性とは、さまざまな情報技術システムとソフトウェアアプリケーションが通信し、データを交換し、交換された情報を使用する能力です。
午前10時47分 — ホセ・ガルシアさんのクレアチニン検査結果が、病院のFHIRサーバーに届きました。 2.1 mg/dL — 先月と比べて35%の上昇です。
次に何が起こるのでしょうか？
チャットボットも、手動でのプロンプトも、ブラックボックス的な推論もありません。
FHIRプロファイルとは何ですか？
FHIR プロファイル とは、基盤となるFast Healthcare Interoperability Resources（FHIR）リソースをカスタマイズし、洗練させるために用いられる一連の規則と制約の集合体です。プロファイリングは、特定のユースケース、地理的地域、医療機関、または臨床ワークフローの固有の要件を満たすために、基盤となるFHIRリソース標準を適応させる重要なプロセスです。
基本となるFHIRスペシフィケーションでは、リソース（患者、観察、薬剤など）に対して一般的な、柔軟な定義を規定しております。一方、プロファイルはこれらの一般的なリソースをより精密なものへと変換します。これにより、特定のコミュニティや実装に合わせて調整された、一貫性と相互運用性を備えたデータ交換が保証されます。
FHIRは、世界中の様々な医療シナリオをカバーするよう設計されています。プロファイルにより、実装者は標準化の利点を損なうことなく、この総合プラットフォームを適応させることが可能となります。
FHIRプロファイルはどのような場合に使用するのでしょうか？
FHIRプロファイルは、システムがデータを検証するために使用する計算可能なルールとして機能します。
開発者の皆さん、こんにちは！
InterSystems オンラインプログラミングコンテストの次の内容が決定しました！
🏆 InterSystems プログラミングコンテスト：FHIR 対応 AI エージェント🏆
期間： 2026年5月25日～6月14日
賞金総額: $12,000
その1 では、MAIS（マルチエージェント相互運用システム）の技術的基盤を構築いたしました。「脳」の配線に成功し、LiteLLMを用いた堅牢なアダプターを構築し、IRIS資格情報でAPIキーをロックダウンし、そしてついにPython相互運用性のパズルを組み立てたのです。 しかしながら、現時点では我々のシステムはLLMへの単なる未加工のパイプに過ぎません。テキストを扱うことはできますが、アイデンティティを欠いているのです。
さて、この第2部では、エージェントの構造についてご説明いたします。単純なAPI呼び出しから、構造化されたペルソナへと進みます。LLMをビジネスロジックの層でラップし、その名称やロールを定義し、そして最も重要な点として、隣接する要素を認識する能力を付与する方法について学んでまいります。
私たちのマシンの「魂」を構築しましょう。
「脳」（LLM）との接続が確立したところで、次にその「脳」にパーソナリティを付与する必要があります。よくある誤解として、エージェントとは単に「役立つアシスタントです。」といったシステムプロンプトに過ぎないという見方がありますが、それは単なるチャットボットに過ぎません。
真正なエージェント型AIは、監視を必要としない点で際立っています。それは自律性と、任務を完遂しようとする強い意欲を兼ね備えています。
ある概念は紙に書かれたままでは完璧に理解できても、他の概念は実際に手を汚すことを必要とすることがあります。 例えば、運転を例に挙げましょう。エンジンの仕組みのあらゆる部品を暗記することはできますが、それが運転が実際にできることを意味するわけではありません。
実際に運転席に座り、クラッチの摩擦点や路面からの振動を身体で感じ取るまでは、その真髄を理解することはできません。 コンピューティングの概念の中には直感的に理解できるものもありますが、インテリジェントエージェントは異なります。それらを理解するためには、運転席に座る必要があるのです。
これまでのAIエージェントに関する記事では、CrewAIおよびLangGraphといったツールについて取り上げてまいりました。しかし、本ガイドでは、AIエージェントのマイクロフレームワークをゼロから構築してまいります。エージェントを構築することは、単なる構文の習得を超えた取り組みであり、開発者にとって実世界の問題を解決に挑戦する貴重な旅と申せます。
とはいえ、経験そのもの以上に、これを行う根本的な理由がもう一つあります。それはリチャード・ファインマンの言葉に最もよく表れています：
「自分でつくれないものは、本当に理解しているとはいえない」
具体的に説明いたします。エージェントとは、本質的に目的を追求するコードです。
現代のデータアーキテクチャでは、リアルタイムのデータ収集、データ変換、データ移動、データロードのソリューションを活用し、データレイク、分析用倉庫、ビッグデータリポジトリを構築しております。様々なソースからのデータを、それらを利用する操作に影響を及ぼすことなく分析することを可能にします。これを実現するためには、継続的、拡張的、弾力的、かつ堅牢なデータフローを確立することが不可欠です。そのための最も一般的な方法は、CDC（変更データキャプチャ） 技術によるものです。CDCは小さなデータセットの生成を監視し、このデータを自動的に収集して、分析用データリポジトリを含む1つ以上の受信先に配信します。主な利点は、分析におけるD+1（データ生成の翌日）の遅延が解消される点です。データは生成されるとすぐにソースで検知され、その後、対象の宛先へ複製されるためです。
本記事では、CDCシナリオにおいて最もよく使用される2つのデータソース（データソースおよびデータ宛先として）についてご説明いたします。データソース（元）としては、SQLデータベースおよびCSVファイルにおけるCDCの活用方法について探ってまいります。
InterSystems IRIS® データプラットフォーム、 InterSystems IRIS® for Health および HealthShare® Health Connect™ のメンテナンスバージョン 2025.1.4 および 2024.1.6 がリリースされました。今回のリリースでは、最近お知らせした以下の警告や勧告の修正が含まれています。
より良い製品を皆様と共に作り上げていくため、 アイデアポータル 内の リリース後のフィードバック カテゴリからご意見をお寄せください。
詳細な変更リストとアップグレードチェックリストはこちらのドキュメントをご参照ください(すべて英語 2025.
| 警告 ID | 影響を受ける製品とバージョン | リスクカテゴリー & スコア | 発生条件 |
| IF-9262 |
InterSystems IRIS® for Health InterSystems Health Connect™ |
システム安定性に関する懸念 5 (高リスク) |
FHIRおよび医療情報相互運用性の問題により、アップグレードが失敗したり、予期せぬ および 望ましくない製品の挙動が見られる |
インターシステムズは、InterSystems IRIS data platform、InterSystems IRIS for Health および HealthShare Health Connect のバージョン 2026.1 をリリースをしました。2026.1 は、拡張メンテナンス（EM）リリースです。
データベース・スケーラビリティの強化
データベースの容量制限が撤廃されました。これにより、従来の容量制限をこえてもデータ移行が必要なく、円滑にシステム拡張できるようになりました。また低レベルパフォーマンスも改善され、大規模運用がさらに最適化されています。
ユーザー定義の論理キーに基づきテーブルと関連インデックスデータを分割し、データベース間で簡単にマッピングできるようになりました。これによりストレージの階層化が可能となり、大容量テーブルにおけるクエリパフォーマンスと運用効率が向上しました。この機能は早期アクセス・プログラムで提供されている実験的な機能です。早期アクセス・プログラムに参加いただくと、機能のアップデートを受け取ったり、フィードバックを送信することが可能となります。
相互運用プロダクションでは、HTTPクライアントとして動作するビジネスオペレーションを常に設定することが可能です。このオペレーションはOAuth 2.0による認証を利用しますが、この認証方式に対応するためにはオペレーションのカスタマイズが必要でした。 最近リリースされた v2024.3以降では、 この処理をより容易に行うための新機能が追加され、新たな設定オプションが提供されています。
HTTPアウトバウンドアダプターをご利用のビジネスオペレーションにおいて、OAuthグループの下に新しい設定項目が追加されております。
例えば：
新しいOAuth関連の 設定に関するドキュメントはこちらでご覧いただけます。
関連するオペレーションのスクリーンショットの例を以下に示します：
.png)
メッセージを 簡単に再送信する機能は、相互運用性における当社の強力な特徴の一つであります。
v2024.3 がまもなくリリースされます（（開発者プレビュー版は既に利用可能です） 既に 公開済みです。これにより、さらに簡単になりました！
Visual Trace 内から、メッセージヘッダーの横に「再送信」ボタンを見つけられます。こちらをクリックすると、通常の「メッセージ再送信エディター」が表示されます（メッセージビューアーを経由して特定のメッセージを 検索する必要はありません）。
以下に、その例を示します：
.png)
関連するリリースノートもご覧ください。
InterSystems IRIS、特にInteroperabilityを使い始めたころ、最初によく思っていた疑問の一つは「処理を一定間隔やスケジュールで実行するにはどうすればいいのか」でした。 このトピックでは、この問題に対処する2つのシンプルなクラスをご紹介します。 似たようなクラスがEnsLibに見当たらないことに、驚いています。 十分に検索しなかったのかもしれません。 いずれにせよ、このトピックでは複雑な作業を扱うつもりはなく、初心者向けの簡単なスニペットを少し紹介します。
メール送信は、統合シナリオでは一般的な要件です。クライアントへのリマインダー、自動レポート、トランザクション確認などに使用されます。 固定メッセージは、管理やパーソナライズが難しくなりがちです。 そこで登場するのが templated_email モジュールです。InterSystems IRIS InteroperabilityをJinja2テンプレートの機能を組み合わせます。
Jinja2はPythonエコシステムで人気のあるテンプレートエンジンで、完全に動的なコンテンツ生成を可能にします。 次をサポートします：
簡単なメール本文テンプレートの例：
Hello {{ user.name }}!
{% if orders %}
You have {{ orders|length }} new orders:
{% for o in orders %}
- Order #{{ o.id }}: {{ o.amount }} USD
{% endfor %}
{% else %}
You have no new orders today.
{% endif %}
血液検査の結果を見て、何が書いてあるのか全然わからないあの感じ、分かるかと思います。 その問題を解決してくれるのがFHIRInsightです。 そもそも医療データは怖いものや分かりにくいものではなく、誰もが活用できるものであるべきだ、という考えから始まりました。 血液検査は健康チェックではとても一般的ですが、正直なところ、理解するのは多くの人にとって難しく、臨床検査を専門としない医療スタッフにとっても難しいことがあります。 FHIRInsightは、血液検査のプロセスをもっと分かりやすくし、情報をより活用しやすくすることを目指しています。
すべては、シンプルながら強力なこの質問から始まりました。
「なぜ血液検査の結果を読むのは、時には医師にとってもこんなに難しいのか？」
血液検査の結果を見たことがあるなら、大量の数字、意味の分かりにくい略語、そして自分の年齢や性別、状態に合っているかどうかもわからない「基準範囲」を見たことがあると思います。 確かに診断ツールではありますが、状況が分からなければ、結局推測することになります。 経験豊富な医療従事者でさえ、すべてを理解するためにはガイドラインや論文、専門家の意見を照らし合わせる必要があることがあります。
そこで登場するのがFHIRInsightです。
FHIRサーバー
FHIRサーバーとは、FHIR（Fast Healthcare Interoperability Resources）標準を実装するソフトウェアアプリケーションであり、医療システムが標準化された方法で医療データを保存、アクセス、交換、および管理することができるようにします。
Intersystems IRISは、以下のFHIRリソースを保存および取得できます。
Fast Healthcare Interoperability Resources（FHIR）は、HL7 Internationalによって作成された標準化されたフレームワークであり、柔軟かつ開発者に優しい最新の方法で医療データの交換を促進します。
カスタマーサポートの質問は、構造化データ（オーダー、製品 🗃️）、非構造化知識（ドキュメント/よくある質問 📚）、およびライブストリーム（出荷更新 🚚）と多岐にわたります。 この投稿では、以下を使用して、3つすべてに対応するコンパクトなAIエージェントを作成します。
このセクションでは、IRISでPythonを主要言語として使用する方法について紹介します。これにより、IRISの強力な機能を活用しながら、Pythonでアプリケーションのロジックを書くことができます。
開発者の皆さん、こんにちは！
この記事では、Developer Hub にまたまた新チュートリアル：InterSystems IRIS for Health：デジタルヘルスの相互運用性 が追加されましたので、体験内容についてご紹介します。（準備不要でブラウザがあれば試せるチュートリアルです！）
チュートリアルでは、InterSystems IRIS for Health を使用しているのですが、IRIS for Health の持つ機能により以下のような相互運用性シナリオを作成できます。
チュートリアルの中では、あるシステムから入力される HL7 メッセージを他のシステムに送信する流れをご体験いただけます。
また、データ変換が必要な場合の対応方法や HL7 メッセージの一部をテーブルに保存する流れなどもご体験いただけます。
例）HL7 メッセージの一部をテーブルに格納
.png)
アカウント作成やログインも不要で ボタンをクリックするだけで始められます👍
ぜひ、お試しください！
インターシステムズは、InterSystems IRIS、InterSystems IRIS for Health、HealthShare Health Connect のポイントリリース 2025.1 をリリースしました。
新しいバージョン番号は 2025.1.0.225.1 となります。
本リリースは、SDS対応ビジネスホストを利用するユーザに影響を与える、深刻な相互運用性の問題に対応するために行われました。
開発者の皆さん、こんにちは！
次のコンテストの詳細が発表されましたのでご案内します。
🏆 InterSystems FHIR とデジタルヘルスの相互運用性コンテスト 2025🏆
期間：2025年5月12日～6月1日
賞金総額：$12,000
.jpg)
これは、ネイティブウェブアプリケーションとして IRIS にデプロイできる FastAPI アプリケーションのテンプレートです。
git clone
cd iris-fastapi-template
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
docker-compose up
ベース URL は http://localhost:53795/fastapi/ です。
/iris - IRISAPP ネームスペースに存在する上位 10 個のクラスを持つ JSON オブジェクトを返します。/interop - IRIS の相互運用性フレームワークをテストするための ping エンドポイント。/posts - Post オブジェクトの単純な CRUD エンドポイント。/comments - Comment オブジェクトの単純な CRUD エンドポイント。WSGI 導入記事をご覧ください: wsgiサポートの概要。
これは、ネイティブウェブアプリケーションとして IRIS にデプロイできる Flask アプリケーションのテンプレートです。
git clone
cd iris-flask-template
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
docker-compose up
ベース URL は http://localhost:53795/flask/ です。
/iris - IRISAPP ネームスペースに存在する上位 10 個のクラスを持つ JSON オブジェクトを返します。/interop - IRIS の相互運用性フレームワークをテストするための ping エンドポイント。/posts - Post オブジェクトの単純な CRUD エンドポイント。/comments - Comment オブジェクトの単純な CRUD エンドポイント。WSGI 導入記事をご覧ください: wsgi-introduction。
これは InterSystems FAQ サイトの記事です。
インターオペラビリティ機能を使用してビジネスホストのビジネスロジックを実装する際に、デバッグ等の目的でログ出力を行うための専用マクロが用意されているので、ご紹介します。
以下のマクロが用意されています。
$$$LOGINFO"これはログです。"$$$LOGERRORビジネスオペレーション等のコードに上記のコードを書くことにより、インターオペラビリティのイベントログにその内容が表示されます。
以下の様に表示されます。
開発者の皆さん、こんにちは。
Teams ワークフロー Webhook を用意すると、curl コマンドや REST クライアントを利用して Teams チャネルに任意メッセージを簡単に送信できるので、IRIS や IRIS の Interoperability を使って自動的に何か情報を入手＋必要なときだけ Teams チャネル通知ができたら面白いな、と思い試してみた内容をご紹介します。
以下、Teamsワークフローの作成例です。
Teams ワークフローの仕様に合わせたメッセージ用 JSON が用意できれば、こんなメッセージを出すことができます。
Teams チャネルにメッセージを通知するには「Teams ワークフローの Webhook」の用意が必要です。（この用意によってアクセスするために必要なURLが生成されます）詳しくは、「Microsoft Teamsのワークフローを使用して受信 Webhook を作成する」をご参照ください。
通知までの設定などについては、こちらのページを参考にさせていただきました：Teams チャネルへメッセージ送信する方法
以下、試した順でご紹介します。
これは InterSystems FAQ サイトの記事です。
イベントログの削除には、Ens.Util.LogクラスのPurge()メソッドを使用します。実行時以下の引数を指定します。
第1引数：削除数（参照渡し）
第2引数：保持日数（デフォルト7）
メッセージの削除には、2種類の方法があります。
1) 2022.1.2以降の導入されたマルチプロセスで削除する方法
Ens.Ens.Util.MessagePurgeクラスのPurge()メソッドを使用します。実行時以下の引数を指定します。
第1引数：削除数（参照渡し）
第2引数：保持日数（デフォルト7）
第3引数：1を指定（Completeではないメッセージの削除を防止するための指定）
第4引数：メッセージボディも一緒に削除する場合は1を指定
第5引数：デフォルトは500(秒)が設定されていますが、大量のメッセージをパージするとクリアされたビットマップの最適化に時間を要して最適化が完了しない場合があるため、大量削除の場合は 10000000000など大きな値を指定します。
2) Ens.MessageHeaderクラスのPurge()メソッドを使用する方法。
実行時以下の引数を指定します。
開発者の皆さん、こんにちは。
試していたWebAPIでは、POST要求時クエリパラメータとボディの両方を送る必要がありましたので、HTTPアウトバウンドアダプタが提供するメソッド：Post()／PostFormDataArray()／PostURL() 辺りをドキュメントで確認していたのですが、残念ながら両方を渡せるように作成された丁度良いメソッドがありませんでした。
ドキュメント：HTTPアウトバウンドアダプタが提供するメソッド
では、どのように送ったかというと、SendFormDataArray()の第3引数を利用して両方の情報を送付してみました。
具体的には、SendFormDataArray()の第2引数にはHTTPメソッド（GET、POST、PUT、DELETEなど）第3引数に%Net.HttpRequestのインスタンスが渡せる仕様になっていましたので、クエリパラメータとボディを%Net.HttpRequestのインスタンスに設定し、第3引数に指定して実行する方法をとりました。
set..Adapterコミュニティメンバーから、Python 2024 コンテストでの出品に対する非常に素晴らしいフィードバックが届きました。 ここで紹介させていただきます。
純粋な IRIS の 5 倍以上のサイズでコンテナーをビルドしているため、時間がかかっています
コンテナーの始動も時間はかかりますが、完了します
バックエンドは説明通りにアクセス可能です
プロダクションは稼動しています
フロントエンドは反応します
何を説明したいのかがよくわかりません
私以外のエキスパート向けに書かれた説明のようです
出品はこちら: https://openexchange.intersystems.com/package/IRIS-RAG-App
このようなフィードバックをいただけて、本当に感謝しています。プロジェクトに関する記事を書く素晴らしいきっかけとなりました。 このプロジェクトにはかなり包括的なドキュメントが含まれてはいますが、ベクトル埋め込み、RAG パイプライン、LLM テキスト生成のほか、Python や LLamaIndex などの人気の Python ライブラリに精通していることが前提です。
この記事は、IRIS での RAG ワークフローを実証するに当たって、上記の前提事項や、それらが IRIS で RAG ワークフローをこのプロジェクトにどのように適合するかについてを説明する試みです。
CI/CD シリーズの新しい章へようこそ。ここでは、InterSystems テクノロジーと GitLab を使用したソフトウェア開発の様々な可能なアプローチを取り上げています。 今回も相互運用性について説明を続けますが、特に相互運用性デプロイの監視に焦点を当てます。 まだアラートをすべての相互運用性プロダクションにセットアップしていない場合は、それをセットアップしてエラーとプロダクションの状態についての一般的なアラートを取得できるようにしてください。
非活動タイムアウトは、すべての相互運用性ビジネスホストに共通する設定です。 ビジネスホストは、「Inactivity Timeout（非活動タイムアウト）」フィールドに指定された秒数以内にメッセージを受信しない場合に非アクティブステータスになります。 プロダクションの監視サービスはプロダクション内のビジネスサービスとビジネスオペレーションのステータスを定期的に確認し、非活動タイムアウト期間内にアクティビティがない場合にその項目を「非アクティブ」にマークします。
デフォルト値は 0（ゼロ）です。 この設定が 0 である場合、ビジネスホストはアイドル状態がどれほど続いても Inactive にマークされることはありません。
これはアラートを生成し、構成されたアラートと合わせてプロダクションの問題に関するリアルタイム通知を可能にするため、非常に便利な設定です。 ビジネスホストがアイドル状態である場合、プロダクション、統合、またはネットワーク接続に調べる価値のある問題がある可能性があります。 ただし、ビジネスホストには一定時間の非活動タイムアウトを 1 つしか設定できないため、夜間、週末、休日などのトラフィックの少ない既知の期間中に不要なアラートを生成する可能性があります。 この記事では、動的な非活動タイムアウトを実装するためのいくつかのアプローチを説明します。 機能する例（現在ある顧客サイトの本番環境で実行しているもの）を紹介していはいますが、この記事は独自の動的な非活動タイムアウトの実装を構築するためのガイドラインを紹介することを目的としているため、ここに提案するソリューションを唯一の代替手法と見なさないようにしてください。
CI/CD シリーズの新しい章へようこそ。ここでは、InterSystems テクノロジーと GitLab を使用したソフトウェア開発の様々な可能なアプローチを取り上げています。
今回は、相互運用性についてご紹介しましょう。
アクティブな相互運用性プロダクションがある場合、2 つの個別のプロセスフローが存在します。メッセージを処理する稼動中のプロダクションと、コード、プロダクションの構成、およびシステムデフォルト設定を更新する CI/CD プロセスフローです。
明らかに、CI/CD プロセスは相互運用性に影響しますが、 本題は次にあります。
開発者の皆さん、こんにちは！ InterSystems IRIS（以下、IRIS）を使用したアプリケーション開発において、皆さんは環境設定をどうされていますか？ 私は最近になって、「インストールマニフェスト」という機能があることを知りました。 これは、管理ポータルでポチポチしていた作業をコード化・自動化できる強力なツールです！ 最初こそとっつきづらかったものの良いところがたくさんあるなと思ったので、簡単にではありますが皆さんにその良さと始め方をご紹介したいと思います。
なお、私が使用しているIRISバージョンは以下です。
2022.1
バージョンが異なる場合、違う書き方になっているもの等が存在する場合がありますので、 公式ドキュメント等を参照し適宜読み替えていただければと思います。