ここでは、HL7メッセージで受け取った情報を活用して、検索テーブルをいかに簡単に作成できるかを紹介したいと思います。IRISが提供するHL7メッセージ検索テーブルは、実施したい検索のほとんどに対応できていますが、HIS、LIS、RISなどには、どうしても検索対象にしたい特別なフィールドが常に存在します。 しかし、それはそのルックアップテーブルの範囲外のセグメントにあります。そのフィールドがあるため、拡張された検索条件を使って特定の検索を実行せざるを得ません。メッセージは多数あるでしょうし、タイムアウトにならないよう、日時でフィルタリングする必要もあります。
 

この問題をどう解決すればいいでしょうか？

独自の検索テーブルを作成することで解決します。

では、その検索テーブルはどのように作成すればいいのでしょうか？

私たちのような「天才ではない者」がいつもそうしてきたように、コピーしましょう！人生において、私たちは3～4人の天才に出会うでしょう。彼らは発明し、創造し、来世を視覚化するような人々です。もしあなたがその一人なら、すでに行うべきことは分かっているはずです。あなたは世界の巨匠トップ100に入り、IQは50万ポイントを超え、自宅にはInterSystems製品の豪華なコレクションが揃っていることでしょう。

開発者コミュニティの皆様、こんにちは！

今回の記事では、IRISインスタンス向けに製品に追加された最新のリモートモニタリング機能の一つをご紹介します。それは、OpenTelemetryのサポートです。

OpenTelemetryは何ですか？

OpenTelemetryは、システムやアプリケーションにオブザーバビリティを実装するために必要なSDKや標準など、必要なツールを提供するオープンソースのフレームワークです。

このオブザーバビリティは、以下の3種類のデータに及びます：

1. トレース : ソリューション内を流れる情報の流れを管理し、情報がどこを通過し、どのような条件下で処理されているかを特定できるトレースを含みます。
2. メトリクス : システムの状態、パフォーマンス、応答遅延、リソース使用状況など。
3. ログ : 発生したイベントをより深く理解するためにシステムに組み込まれています。

OpenTelemetryは、オープンなOTLP標準を採用しており、これによって、これまでに定義されたすべてのテレメトリのシリアライズおよび転送方法が規定されています。このテレメトリは、HTTPまたはgRPC経由で送信できます。

IRISは、CCDAおよびFHIRの変換機能を標準でサポートしていますが、これらの機能にアクセス・閲覧するには、かなりの設定時間と製品知識が必要となります。IRIS Interop DevToolsアプリケーションは、そのギャップを埋めるために設計されており、導入担当者がすぐに使い始め、製品の組み込み変換機能を閲覧できるようにします。 

IRIS XML、XPath、およびCCDA変換環境に加え、Interop DevToolsパッケージでは現在、以下の機能を提供しています：

• FHIR-SDA 変換設定
• SDA-FHIR 変換設定
• FHIR 検証エラーの伝播
• FHIR 変換に必要なコンテキストの読み込み

ダッシュボードの見た目と操作感が刷新され、より直感的で使いやすくなりました。 実行はIRIS内で行われますが、UIは可視性と再現性を確保しつつ、テストのために変更点やモジュールを個別に切り離すことも可能です。

以下の5つのユーティリティがあります：

1. XPathエバリュエーター：入力CCDに対してXPathを評価し、結果を返します

2. CCDAからSDAへの変換：入力CCDに対して選択された基本XSL変換を実行し、SDAの結果を表示します。 

3. XSLテンプレートテスター：入力CCDに対して単一のXSLテンプレートを適用し、結果のCCDを表示します。 

4.

LangGraph を使用して、推論、ベクトル検索、ツール統合を組み合わせた、スケーラブルで自律的な AI エージェントの設計方法を学びましょう。

長すぎるので読み飛ばしました

• AIエージェントとは、メモリ・コンテキスト・主体性を組み合わせ、単なるチャットボットを超えたタスクを自動化する能動的なシステムです。
• LangGraphは、組み込みの状態管理機能を備えたノード（タスク）とエッジ（接続）を活用し、複雑なAIワークフローを構築できるフレームワークです。
• このガイドでは、優先度を分類し、関連するトピックを特定し、エスカレーションを行うか自動返信するかを判断する、AI搭載のカスタマーサポートエージェントの構築手順をご説明します。

では、一体、AIエージェントとは何でしょうか？

率直に言って、「AIエージェント」と聞くと、まるで役員室を乗っ取ろうとするロボットのように聞こえるかもしれません。しかし実際には、複雑なワークフローを効率化し、反復的な作業を排除してくれる、先を見越した頼もしい相棒なのです。チャットボットをさらに進化させた存在だと考えられるでしょう。AIエージェントは単に指示を待つだけでなく、自らアクションを開始し、複数のステップを調整し、状況に応じて適応していくのです。

Intersystems IRIS プロダクションは、さまざまなプロトコルやメッセージ形式を持つ異種システム間を、信頼性が高く、可観測性があり、スケーラブルな方法で接続するための強力なフレームワークです。intersystems_pyprodは、 InterSystems Python Productionsの略称は、開発者がこれらの相互運用性コンポーネントをPythonで完全構築できるようにするPythonライブラリです。柔軟性を重視して設計されており、ハイブリッドなアプローチをサポートしています。つまり、既存のObjectScriptベースのコンポーネントと新しいPythonベースのコンポーネントをシームレスに組み合わせ、確立されたIRISインフラストラクチャを活用することができます。一度定義されると、これらのPythonコンポーネントは他のコンポーネントと同様に管理されます。つまり、[IRIS プロダクション構成]ページを使用して、追加、構成、接続を行うことができます。

InterSystems IRIS プロダクション：簡単な入門書

プロダクションの主要な要素

画像提供：ラーニング・サービス研修資料

通常、IRISプロダクションは外部インターフェースからデータを受け取り、調整したステップを通じて処理を行い、宛先へと転送します。

INTRO

Barricadeは、InterSystems OMOP向けのFHIRからOMOPへの変換を効率化し、そのサポートをスケールアップするために、ICCA Opsが開発したツールです。当社のクライアントは、InterSystems OMOPを使用してFHIRデータをこのOMOP形式に変換することになります。マネージドサービスとして、当社の役割は変換プロセスに伴うあらゆる問題のトラブルシューティングを行うことです。Barricadeは、さまざまな理由から、このプロセスを支援する理想的なツールです。第一に、効果的なサポートには、FHIR標準、OHDSI OMOPモデル、そしてInterSystems特有の運用ワークフローにわたる専門知識が必要ですが、これらはすべて高度に専門化された分野です。Barricadeは、大規模言語モデルを活用してFHIRやOHDSIに関する専門知識を提供することで、知識のギャップを埋めるお手伝いをします。さらに、特定の変換問題を解決するために詳細な説明が行われたとしても、その知識はメールやチャットの中に埋もれてしまい、将来的に活用できなくなることがよくあります。Barricadeなら、その知識を収集・再利用し、類似のケースにスケールさせることも可能です。最後に、多くの場合、ソースデータにアクセスできません。

午前10時47分 — ホセ・ガルシアさんのクレアチニン検査結果が、病院のFHIRサーバーに届きました。 2.1 mg/dL — 先月と比べて35%の上昇です。

次に何が起こるのでしょうか？

• ほとんどのシステムでは： ❌ 結果は、臨床医が手動で確認するまでキューに留まります。確認されるまでには数時間から数日かかることもあります。
• This system: 👍 AIエージェントが傾向を評価し、臨床ガイドラインを参照して、エビデンスに基づいた推奨事項を生成します — 数秒で、自動的に。

チャットボットも、手動でのプロンプトも、ブラックボックス的な推論もありません。

過去数ヶ月間、私はCSIROのオープンソースアプリケーションであるSMART-EHR-LauncherとSMART Forms Appの2つを用いて、IRIS for Healthの機能性を検証するため、SMART on FHIR EHR Launchに取り組んでまいりました。この取り組みは非常に興味深く、この課題に携わり、IRIS for Healthの可能性をさらに探求する機会を賜りましたことに、心より感謝申し上げます。

HL7 AU FHIR Connectathonにおいて、多数の外部SMARTアプリのシームレスな起動を成功裏に実証いたしましたことを受け、学んだ知見をコミュニティの皆様と共有できることを大変嬉しく存じます。私の知見が、同様のプロジェクトを迅速に開始されるお役に立てれば幸いです。

本タスクでは、SMART-EHR-Launcher を電子カルテ（EHR）として使用しSMART Formsアプリを起動しました。同時に、IRIS for Health をEHRのFHIRリポジトリとして活用し、そのOAuth2 サーバーを認証サーバーとして使用いたしました。

すべての興奮に飛び込む前に、 SMART on FHIR と SMART on FHIR EHR Launchについて詳しく見ていきましょう。私たちの親友であるChatGPTにお尋ねしましょう。

InterSystems IRISは、データ論理構成（ネームスペース）とその物理的保存場所（データベース）を分離するアーキテクチャに構築されています。この分離と、ネームスペースとデータベースの区別を理解することは、効果的なデータ管理、セキュリティ、特には高パフォーマンスなデータ共有において極めて重要です。

本記事では、これらの基盤となる構成要素について解説し、グローバルマッピングを活用して異なるロジカル環境間でネイティブデータ構造（グローバル変数）を共有するための実践的なガイドを提供いたします。

データベース：物理的な現実

データベースは、データがディスク上に保存されている物理的な現実を表現しています。何よりもまず、IRIS.dat というファイルシステム内のファイルです（例： \mgr\user\IRIS.DAT）。 このファイルの最大サイズは32TBです。実際のデータおよびコードのすべてを格納するコンテナとなります。データベースはIRISカーネルによって管理され、物理ファイルレベルでのキャッシュ、ジャーナリング、トランザクションログの処理を担当します。

FHIRプロファイルとは何ですか？

FHIR プロファイル とは、基盤となるFast Healthcare Interoperability Resources（FHIR）リソースをカスタマイズし、洗練させるために用いられる一連の規則と制約の集合体です。プロファイリングは、特定のユースケース、地理的地域、医療機関、または臨床ワークフローの固有の要件を満たすために、基盤となるFHIRリソース標準を適応させる重要なプロセスです。

基本となるFHIRスペシフィケーションでは、リソース（患者、観察、薬剤など）に対して一般的な、柔軟な定義を規定しております。一方、プロファイルはこれらの一般的なリソースをより精密なものへと変換します。これにより、特定のコミュニティや実装に合わせて調整された、一貫性と相互運用性を備えたデータ交換が保証されます。

FHIRは、世界中の様々な医療シナリオをカバーするよう設計されています。プロファイルにより、実装者は標準化の利点を損なうことなく、この総合プラットフォームを適応させることが可能となります。

FHIRプロファイルはどのような場合に使用するのでしょうか？

FHIRプロファイルは、システムがデータを検証するために使用する計算可能なルールとして機能します。

以前のバージョンにおいても、FHIRサーバーをOAuth 2.0経由でのリクエスト受付に対応させる設定が可能でした（例：SMART on FHIRクライアント向け）。しかし、現在では v2024.3, （以前リリースされたバージョン） , では、これをより容易に行える新機能が追加されました。具体的には、OAuth FHIR Client QuickStartが追加されました。

この「QuickStart」は、ウィザード形式の「ヘルパー」ツールであり、わずか5つの簡単なステップ（実際には3ステップのみです...）で、FHIRサーバーをOAuthサーバーに接続し、FHIRリクエストに対するOAuth認証および認可を有効にすることができます。

• ステップ1 - FHIRサーバーの作成または選択

すでに定義済みのFHIRサーバー（エンドポイント）をお持ちの場合もあれば、まだ定義しておらず、このクイックスタートとして今定義したい場合もあるかもしれません。

• ステップ2： FHIRサーバーを選択

ある概念は紙に書かれたままでは完璧に理解できても、他の概念は実際に手を汚すことを必要とすることがあります。 例えば、運転を例に挙げましょう。エンジンの仕組みのあらゆる部品を暗記することはできますが、それが運転が実際にできることを意味するわけではありません。

実際に運転席に座り、クラッチの摩擦点や路面からの振動を身体で感じ取るまでは、その真髄を理解することはできません。 コンピューティングの概念の中には直感的に理解できるものもありますが、インテリジェントエージェントは異なります。それらを理解するためには、運転席に座る必要があるのです。

これまでのAIエージェントに関する記事では、CrewAIおよびLangGraphといったツールについて取り上げてまいりました。しかし、本ガイドでは、AIエージェントのマイクロフレームワークをゼロから構築してまいります。エージェントを構築することは、単なる構文の習得を超えた取り組みであり、開発者にとって実世界の問題を解決に挑戦する貴重な旅と申せます。

とはいえ、経験そのもの以上に、これを行う根本的な理由がもう一つあります。それはリチャード・ファインマンの言葉に最もよく表れています：

「自分でつくれないものは、本当に理解しているとはいえない」

では…AIエージェントとは何でしょうか？

具体的に説明いたします。エージェントとは、本質的に目的を追求するコードです。

その1 では、MAIS（マルチエージェント相互運用システム）の技術的基盤を構築いたしました。「脳」の配線に成功し、LiteLLMを用いた堅牢なアダプターを構築し、IRIS資格情報でAPIキーをロックダウンし、そしてついにPython相互運用性のパズルを組み立てたのです。 しかしながら、現時点では我々のシステムはLLMへの単なる未加工のパイプに過ぎません。テキストを扱うことはできますが、アイデンティティを欠いているのです。

さて、この第2部では、エージェントの構造についてご説明いたします。単純なAPI呼び出しから、構造化されたペルソナへと進みます。LLMをビジネスロジックの層でラップし、その名称やロールを定義し、そして最も重要な点として、隣接する要素を認識する能力を付与する方法について学んでまいります。

私たちのマシンの「魂」を構築しましょう。

エージェントの構造： ただのプロンプトではなく

「脳」（LLM）との接続が確立したところで、次にその「脳」にパーソナリティを付与する必要があります。よくある誤解として、エージェントとは単に「役立つアシスタントです。」といったシステムプロンプトに過ぎないという見方がありますが、それは単なるチャットボットに過ぎません。

真正なエージェント型AIは、監視を必要としない点で際立っています。それは自律性と、任務を完遂しようとする強い意欲を兼ね備えています。

現代のデータアーキテクチャでは、リアルタイムのデータ収集、データ変換、データ移動、データロードのソリューションを活用し、データレイク、分析用倉庫、ビッグデータリポジトリを構築しております。様々なソースからのデータを、それらを利用する操作に影響を及ぼすことなく分析することを可能にします。これを実現するためには、継続的、拡張的、弾力的、かつ堅牢なデータフローを確立することが不可欠です。そのための最も一般的な方法は、CDC（変更データキャプチャ） 技術によるものです。CDCは小さなデータセットの生成を監視し、このデータを自動的に収集して、分析用データリポジトリを含む1つ以上の受信先に配信します。主な利点は、分析におけるD+1（データ生成の翌日）の遅延が解消される点です。データは生成されるとすぐにソースで検知され、その後、対象の宛先へ複製されるためです。

本記事では、CDCシナリオにおいて最もよく使用される2つのデータソース（データソースおよびデータ宛先として）についてご説明いたします。データソース（元）としては、SQLデータベースおよびCSVファイルにおけるCDCの活用方法について探ってまいります。

InterSystems IRISデータプラットフォームは、InterSystemsの全アプリケーションに加え、ヘルスケア、ファイナンシャルサービスおよびサプライチェーンをはじめとする様々なエコシステムにおいて、数千もの顧客およびパートナーアプリケーションの基盤となっております。これは収束プラットフォームであり、トランザクション・アナリティクスデータ管理、統合された相互運用性、データ統合に加え、統合された分析およびAIを提供します。多様な分散データを管理するInterSystemsスマートデータファブリックアプローチをサポートしております。

当社のアーキテクチャの中核には、コアデータエンジン（別名一般なデータプレーン）における高性能・マルチモデル・多言語データ処理機能がございます。これを基盤として、膨大なデータ量と毎秒10億を超えるデータベース操作に及ぶ高いトランザクションレートに対応する、卓越したスケーリング機能を備えております。

次に、二つの主要なサブシステムが挙げられます。一つは分析と人工知能（AI）に焦点を当てたもので、もう一つは相互運用性とデータ統合に焦点を当てたものです。これらのサブシステムは、データに近接して全てを実行し、最小のフットプリントで高いパフォーマンスを提供する、という当社の基本理念に沿った設計となっております。

序言

極めて高いパフォーマンスが求められるアプリケーションにおいて、企業はしばしばインメモリデータベースやキーバリューストア（キャッシュ層）を採用します。しかしながら、インメモリデータベースは総所有コストが高く、スケーラビリティにも限界があり、メモリ制限を超えた場合には信頼性の問題や再起動の遅延が生じます。インメモリキーバリューストアも同様の制約を抱えるだけでなく、アーキテクチャの複雑さやネットワーク遅延といった新たな課題をもたらします。

本記事では、高パフォーマンスのSQLおよびNoSQLアプリケーションにおいて、InterSystems IRIS™データプラットフォームがインメモリデータベースやキーバリューストアに比べ優れた選択肢である理由についてご説明いたします。

パフォーマンスと効率性のレベルアップ

InterSystems IRISは、同時データ取り込みおよび分析処理において、インメモリデータベースやキャッシュ層の性能に匹敵、あるいはそれを上回る唯一の永続データベースです。市販されているハードウェア上において、ネットワーク遅延を発生させることなく、1マイクロ秒未満で着信トランザクションの処理、データのディスクへの永続化、分析のためのインデックス作成を実現します。

インターシステムズ アイデア ポータル（InterSystems Ideas Portal）で最も多くの賛同を得た提案（74票）は、IRISの軽量バージョンを要望するものです。プラットフォームは強力なデータエンジンに成長していますが、多くのプロジェクトではSQLデータベース機能のみが必要とされています。本記事では、コアなデータベース機能にのみ焦点を当てた非公式なコンパクトなIRIS Community Editionイメージを構築する方法を示し、イメージサイズを80％以上削減する方法を説明します。

⚠️ Disclaimer

このプロジェクトは、InterSystems IRIS Community Editionの非公式な実験的なイメージを生成します。

• InterSystemsによるサポートまたは推奨はされていません。
• 使用は自己責任です。これらの変更により、プラットフォームの中核機能が削除され、ツールやAPI、想定される動作との互換性が損なわれる場合があります。
• 確証または保証 なしに生は、産用途への適合性を含みます。
• 上級ユーザーによる教育および実験目的のみに供するものです。

データベースを確認したところ、巨大な^rINDEXSQLグローバルが存在しているようですが、これはなぜでしょうか？ 😬

管理ポータルのSQLページにおいて、「SQLステートメント」の下に「古いデータをクリーンアップ」ボタンがおりますが、これはどのような機能でしょうか？ 🤔

ステートメントのリストにおいて、一部のステートメントには「Location」値が設定されていますが、他のステートメントには設定されていないようです。これはどうしてでしょう？ 🤨

そうですね、確かにこれらはすべて関連しています。

一般的に、実行されたSQLクエリに関する基本的な統計情報 は保持しております。 キャッシュされたSQLクエリを削除する際、ステートメントリスト内のステートメントエントリ自体は削除せず、統計情報は保持いたします（将来の比較に役立つ可能性があるためです）。ただし、ロケーション列は「クリア」します（既存のキャッシュ済みクエリを指さなくなるためです）。 これらの「古い」ステートメント（もはやどこも指していないもの）をクリーンアップしたい場合は、「古いステートメントをクリーンアップ」ボタンを押することができます。

以下のような表示になります（システムエクスプローラー -> SQL -> SQLステートメント）：

[注記：旧バージョン（例：v2020.

FHIR検索を、あらかじめ定義されたリソースの「リスト」ごとに制限することは、場合によってはより便利で、より効率的であり、より安全です。

バージョン2025.1より、当社のFHIRサーバーでは複数のリスト関連機能をサポートしております。

こちらでそれらを重点的にご説明し、いくつかの サンプルをご提供いたします。

一般的には、公式のFHIRドキュメントよりリストリソースの詳細について利用できます。

しかしながら、上記に基づいた簡単な 説明を以下に示します：

FHIRのリスト リストリソースは、フラット（オプションとしてオーダー付き）レコードの集合体を表し、臨床リスト（例：アレルギー、薬剤、アラート、病歴）やワークフロー管理（例：患者追跡、教育ケース）に使用されます。 リストは均質（単一のリソースタイプ）または 不均質（混合タイプ、例：状態、アレルギー・不耐性、処置にまたがる問題リスト）である場合があります。 リストは、単純なクエリでは取得できないキュレート・抽出されたデータセットが必要な場合に使用します（例：現在のアレルギーと全記録アレルギーの比較）。 リストをクエリすると、ポイント イン タイム スナップショットが得られます。 一方、リソースエンドポイントをクエリすると、通常はより広範でキュレートされていない「現時点での」データセットが返されます。

最新バージョン（2025.

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

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

例えば：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• not
• missing

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

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

• _maxresults

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

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

はじめに

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

• 単純なポーリングだと、通知の遅延や、サーバリソースを消費する
• ロングポーリングは、待ち受け画面のために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) の最小実装

全体構成

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