短く言うと： インターフェースエンジン（インテグレーションエンジン）は、医療メッセージングのために構築されたミドルウェアです。多くのプロトコル（HL7 v2用のMLLP、FHIRおよびSOAP用のHTTP、ファイル、データベース、キュー）でリスニングし、メッセージを変換（フィールドマッピング、コード変換、HL7 v2からFHIRへのフォーマット変換など）、フィルタリングして1つ以上の宛先にルーティングし、キュー、リトライ、ログ、ダッシュボードを保持するため、メッセージが失われることはなく、すべての障害が可視化されます。病院では、各システムが他のすべてのシステムに接続するのではなく、エンジンに一度接続するように使用します。有名な製品には、Mirth Connect（NextGen Connect、歴史的にはオープンソース）、Rhapsody、InterSystems HealthShare / IRIS for Health、Infor Cloverleaf、Qvera QIE、Orionなどがあり、その他多数あります。クラウドプロバイダーはマネージドな同等品を提供しています。
構成要素
インターフェースエンジンの構成要素は、チャネル（ソースから宛先への1つのフロー）、MLLPやHTTPなどのソースコネクタまたはリスナー、メッセージを続行するかどうかを決定するフィルター、フィールドやコードをマッピングするトランスフォーマー、宛先コネクタ、リトライ付きキュー、アラート付き監視、チャネルの変更とメッセージ履歴の監査証跡です。
どのエンジンも、語彙は異なっても、同じ部品で構成されています。
- チャネル（インターフェース）：ソースから1つ以上の宛先への1つのフローで、独自のセッティングと統計情報を持っています。
- ソースコネクタ / リスナー：MLLP（HL7 v2用のフレーミング付きTCP）、HTTP(S)エンドポイント、SFTPおよびファイルポーリング、データベースクエリ、JMSまたはその他のキュー、一部の製品ではDICOM。
- フィルタ：メッセージが続行するかどうかを決定するルール（この患者クラスにはADT^A01のみ）。
- トランスフォーマー：メッセージを変更するスクリプトまたはマッピング：フィールド名の変更、ルックアップテーブルを介したローカルコードからLOINCへのマッピング、OBXセグメントからのFHIR Observationの構築、レガシーシステムが期待するZセグメントの追加。
- 宛先コネクタ：結果が行き先で、独自のプロトコルとエラー処理を備えています。
- キューとリトライ：メッセージは確認されるまで保持されます。障害はバックオフでリトライされます。ポイズンメッセージは人間のためのエラーキューに入ります。
- モニタリングとアラート：チャネルごとのカウンター、レイテンシ、エラー率、チャネルが静かになったときのアラート（ヘルスケア統合で最も役立つアラート）。
- 監査：誰がどのチャネルを変更したか、トラブルシューティングのためのメッセージ履歴、保持とアクセス制御（患者データであるため）。
一般的なタスク
ヘルスケアインターフェースエンジンの典型的なジョブは、HISから各部門へのADTのファンアウト、複数の受信者への検査結果のルーティング、ローカルコードをLOINC、ATC、UCUMに翻訳すること、HL7 v2、FHIR、CDA、CSVフォーマットのブリッジング、レガシーデータベース上のFHIRファサードの公開、デバイスフィードの正規化、MLLPを内部からHTTPSに外部で適応させることです。
- ADTのファンアウト：HISからの入院情報を受信し、部門ごとにフィルタリング・変換して、検査室、放射線科、薬局、ベッド管理、患者ポータルに配信します。
- 結果のルーティング：LISからのORUをEHR、処方したGPのシステム、地域の記録、患者のFHIRレコードに、それぞれ異なるサブセットとフォーマットで配信します。
- コード変換：ローカルの検査コードをLOINCに、ローカルの薬剤コードをATCに、自由テキストの単位をUCUMに、維持されているルックアップテーブルを介して変換します（検査コードをLOINCにマッピング）。
- フォーマットブリッジ：HL7 v2からFHIRへ、またはその逆、CDAからFHIRへ、古いシステムからのCSVを任意のフォーマットへ変換します。
- FHIRファサード：エンジンはFHIRエンドポイントを公開し、レガシーデータベースにクエリを送信したりv2クエリを送信したりすることで応答するため、アプリは存在しない場所にFHIRサーバーがあるかのように見えます。
- デバイス統合：プロプライエタリなモニターフィードをIHE PCD Observationに正規化します。
- プロトコルアダプテーション：建物内ではMLLP、外部へはOAuthを使用したHTTPS。
選択する際のポイント
インターフェースエンジンの選択は、6つの基準に集約されます。メッセージ量とレイテンシおよび障害の重要度、標準でサポートされているプロトコルと標準（HL7 v2、FHIR R4、DICOM、国内フォーマット）、開発者の経験、クラスタリングやフェイルオーバーなどの運用、ライセンス条件（一部製品では2025年に変更）、チャネルを保守するために利用可能なスキルです。
- ボリュームとクリティカル性：1日あたりのメッセージ数、許容されるレイテンシ、2分間のダウンタイムが許容されるかどうか（ADTと結果の場合は重要です）。
- 標準でサポートされるプロトコルと標準：HL7 v2のバージョンとパーサー、バリデーション付きのFHIR R4サポート、DICOM、米国のX12、各国のフォーマット。
- 開発者のエクスペリエンス：スクリプト言語（MirthではJavaScript、その他は独自）、チャネル定義のバージョン管理、テストツール、複数の環境へのデプロイ。
- 運用：クラスタリング、フェイルオーバー、モニタリング統合、アップグレードパス、サポートモデル。
- ライセンス：オープンソースまたはコミュニティエディション、チャネルごとまたはコアごとのサブスクリプション、マネージドクラウドオファリング。一部の歴史的にオープンな製品のライセンスは2025年に変更されたため、現在の条件を確認してください。
- 利用可能なスキル：エンジンは、チャネルを保守する人々と同じくらい優れています。
安全な運用
インターフェースエンジンを安全に実行するには、チャネル定義をバージョン管理下のコードとして扱い、本番稼働前に合成メッセージでテストし、名前付き所有者でコードルックアップテーブルを管理し、チャネルがサイレントになったときにアラートを発し、患者データであるメッセージ履歴を制限およびパージし、各チャネルの目的を文書化し、エンジンが記録システムになることを決して許さないことが重要です。
チャネル定義をコードとして扱います。バージョン管理に入れ、レビューし、テストおよびステージング環境に合成メッセージでデプロイします。ルックアップテーブル（コードマップ）は、所有者を明確にしてガバナンス下に置きます。エラーだけでなく、サイレンスにもアラートを設定します。メッセージ履歴へのアクセスを制限します（患者データであるため）、定期的にパージします。各チャネルの目的と所有者を文書化します。文書化されていないチャネルは、作成者が退職したときに部門を停止させる原因となります。そして、エンジンを記録システムに決してさせないでください。データは移動・変換しますが、所有はしません。
不要な場合
グリーンフィールドシステムのパートナーがすべてFHIRを話す場合、インターフェースエンジンは不要です。この場合、SubscriptionsとAPIゲートウェイを備えたFHIRサーバーがルーティングと認証をカバーします。または、単一のHL7 v2インターフェースがHAPI HL7v2やhl7apyのようなライブラリで処理できる場合です。エンジンは、多くのシステムとフォーマットでその価値を発揮します。
パートナーがすべてFHIRを話すグリーンフィールドシステムでは、SubscriptionsとAPIゲートウェイ（認証、レート制限、ルーティング用）を備えたFHIRサーバーを使用し、通常のサービスで変換を行うことができます。単一のHL7 v2インターフェースは、アプリケーション内の小さなライブラリ（JavaのHAPI HL7v2、Pythonのhl7apyまたはpython-hl7）で処理できます。エンジンは、多くのシステム、多くのフォーマットがあり、非開発者でも監視できる運用コンソールが必要な場合にその価値を発揮します。
Anpherosにおいて
Anpheros PlatformはエンジンのFHIR側に位置しています。病院は共有したいフロー（結果、ドキュメント、エンカウンター）を、エンジン経由またはラボコネクタ経由でAnpherosにルーティングし、FHIR APIとWebhook経由で読み取ります。開発者サイトには、コネクタが適用するHL7 v2からFHIRへのマッピングが表示されています。
関連ページ
- 病院システム統合の解説
- 検査システムをEHRと統合する方法
- HL7 v2メッセージの解説：ADTとORU
- ローカル検査コードをLOINCにマッピングする方法
- FHIR Subscriptionsの解説
- HL7 v2からFHIRへのマッピング（開発者サイト）
情報源
- NextGen Connect (Mirth Connect)
- Rhapsody Integration Engine
- InterSystems IRIS for Health
- Infor Cloverleaf
- HAPI HL7v2ライブラリ
- HL7 v2-to-FHIR実装ガイド
よくある質問
インターフェースエンジンはESBやiPaaSと同じですか？
同じファミリーですが、特化しています。インターフェースエンジンは、HL7 v2、DICOM、CDA、FHIRサポート、MLLP、ヘルスケア固有のモニタリング、およびチームが使用する語彙統合を備えています。一般的なESBやiPaaS製品は、より多くの構築でそのジョブを実行できます。
エンジンはHL7 v2をFHIRに自動変換できますか？
いくつかのエンジンには、HL7 v2-to-FHIRガイドに基づいたマッピングが含まれており、一般的なセグメントを処理します。ローカルの慣習、Zセグメント、コードマッピングには、常にプロジェクト作業が必要です。
エンジンは患者データを保存しますか？
転送中のメッセージを永続化し、トラブルシューティングのためにメッセージ履歴を保持しますが、これは患者データであり、保護およびパージする必要があります。長期保存または記録システムとしては使用しないでください。
オープンソースか商用か？
どちらも大規模病院で稼働しています。決定は通常、サポート、スキル、クラスタリングのニーズ、および現在のライセンス条件（一部の製品では変更されているため、コミット前に確認してください）によって決まります。
サンドボックスで無料で試す
5分で最初のFHIR呼び出し. 患者さんの同意が組み込まれたHL7 FHIR R4 APIです。サンドボックスでお試しいただき、ご自身のアプリやクリニックのシステムを接続してください。
無料・合成患者30人・カード不要
Anpherosは、患者が管理し、あらゆるクリニックと共有できる医療記録を、EUを拠点とするHL7 FHIR R4プラットフォーム上で構築しています。これらのガイドは、ご自身の健康を理解し整理するのに役立ちますが、医師の代わりになるものではありません。
Anpherosについて →