短く言うと： 病院では数十のシステムが稼働しており、統合とは、それらのシステムが1人の患者について合意できるようにすることです。中心にはHIS（病院情報システム）またはEHRがあり、患者のID、入院、臨床記録を管理しています。その周りには、検査室システム（LIS）、放射線科（RISおよびPACS）、薬局、手術室、救急、請求、デバイス（モニター、輸液ポンプ）、そしてますます増えている患者アプリ、ウェアラブル、遠隔医療があります。中間に位置するインターフェースエンジンはメッセージを受信、変換、ルーティングし、各システムが他のすべてのシステムに接続するのではなく、一度だけ接続されるようにします。トラフィックの大部分は、イベント（入院、注文、結果）のためのMLLP経由のHL7 v2メッセージ、画像のためのDICOM、文書のためのCDAまたはPDF、そして新しいもの、患者向けのもの、外部のものすべてに対するREST経由のFHIRです。
システムと交換されるもの
病院の統合システムは、患者のID、診察、臨床記録を管理するHISまたはEHRに加え、検査システム、放射線科（RISおよびPACS)、薬局、デバイス、患者アプリ、遠隔医療、地域システムで構成されています。これらは、ADT、オーダー、ORU結果などのHL7 v2メッセージ、DICOM画像、CDA文書、FHIRリソースを交換します。
| システム | 管理 | 送信 | 受信 |
|---|---|---|---|
| HIS / EHR | 患者ID、受診、注文、臨床記録 | ADT（入院、転院）、ORM/OML注文、SIUスケジュール | ORU結果、MDM文書、DFT請求 |
| LIS（検査室） | 検体、検査、結果、基準範囲 | ORU^R01結果、ORR注文応答 | ORM/OML注文、ADT（人口統計情報用） |
| RIS / PACS | 画像注文、ワークリスト、レポート、画像 | ORUレポート、DICOM（ビューア用）、SIU | ORM/OMI注文、ADT；DICOM MWL（モダリティ用） |
| 薬局 | 処方箋、調剤、在庫 | RDS調剤、RAS投与 | OMP/RDE薬剤注文、ADT |
| デバイスとモニター | バイタルサイン、波形、アラーム | ORU^R01観測値（IHE PCD）、独自形式 | ADT（患者コンテキスト用） |
| 患者ポータル / アプリ | 患者入力データ、アクセス | FHIR観測値、アンケート、メッセージ | FHIR（結果、予約、文書の読み取り） |
| 遠隔医療 | ビデオ診察、遠隔モニタリング | FHIR Encounter、Observation、DocumentReference | 予約、患者コンテキスト、SMART起動 |
| 地域および国のシステム | 共有記録、登録簿、電子処方箋 | CDA文書（XDS）、FHIR、国内メッセージ | クエリ、通知 |
インターフェースエンジン
インターフェースエンジンは病院のメッセージングハブです。各システムからHL7 v2、FHIR、ファイル、データベースのトラフィックを受信し、必要とする他のすべてのシステムに変換してルーティングし、キュー、リトライ、監視、監査を管理します。これがない場合、N個のシステムには最大N×(N−1)/2個の手作業で作成されたインターフェースが必要になりますが、これがあれば、各システムは一度だけ接続すれば済みます。
エンジン（Mirth Connect / NextGen Connect、Rhapsody、InterSystems HealthShareおよびIRIS for Health、Infor Cloverleaf、Qvera QIEなど)は、リスナー（MLLP、HTTP、ファイル、データベース)、変換（フィールドのマッピング、コードの修正、v2からFHIRへの変換)、ルーティング（ADTを8つのフィルターで8つのシステムに送信)、キューとリトライ、監視、監査を提供します。また、システム間で患者IDに不一致がある場合に患者IDを照合する場所であり、レガシーデータベース上にFHIRファサードが構築されることもよくあります。インターフェースエンジンについてをご覧ください。
最も重要なフロー
最も重要な病院の統合フローは、ADT（HISからの入院、退院、転院、および人口統計情報の更新)、EHRと検査室または放射線科間のオーダーと結果、薬剤オーダーと調剤、退院証明書などの文書、モニターからのデバイスデータ、そしてFHIRを介した結果、予約、自宅での測定値の患者向け交換です。
- ADT: すべての入院、退院、転院、登録、人口統計情報の更新（A01、A03、A02、A04、A08、A40マージ）は、HISから他のすべてのシステムに展開されます。ADTが遅れたり間違っていたりすると、すべての下流システムが間違った患者または受診の下にデータを保存します。HL7 v2メッセージについてを参照してください。
- 注文と結果: ORM/OMLが送信され、ORUが返信され、プレースホルダーとフィラー番号で関連付けられます。結果にはLOINCとUCUMが使用されます。HL7 v2注文メッセージと検査システムとEHRの統合を参照してください。
- 画像: RISへの注文、スキャナーへのDICOMワークリスト、PACSへの画像、ORUとしてのレポートの返信、DICOMweb経由のビューア。PACS vs RIS vs VNAを参照してください。
- 薬剤: 薬局への注文、調剤と投与の返信、安全目標としてのクローズドループ（ベッドサイドでのバーコード）。
- 文書: 退院サマリー、手術記録、スキャンされた文書をMDMメッセージ、CDAまたはPDFとして文書リポジトリに保存し、地域の登録簿に公開します。
- デバイス: IHE PCDプロファイルまたはベンダーゲートウェイを介して、バイタルサインを記録にフィードするモニター。アラーム管理は別の分野です。
- 患者向け: 結果、予約、文書をFHIR経由でポータルとアプリに送信します。アンケート、自宅での測定値、ウェアラブルデータを再度取り込み、出所を明記して患者報告とします。FHIRによる遠隔患者モニタリングを参照してください。
うまくいくパターン
うまく機能する病院の統合パターンは以下の通りです。患者IDのマスターシステムを1つにし、他のすべてのシステムがADTを購読する。LOINC、SNOMED CT、ATCへのコードマッピングをエンジンで一度だけ行う。すべてのメッセージに対する確認応答、キュー、リトライ。冪等性のある結果と文書。患者アプリおよび外部パートナー向けのFHIRレイヤー。本稼働前の合成患者を使用したテスト環境。
- IDのマスターを1つにする。 HIS（またはマスター患者インデックス）がIDを管理し、他のすべてのシステムはADTを購読し、患者を新規作成しません。
- 境界でのコード化。 エンジンでローカルコードをLOINC、SNOMED CT、ATCに一度マッピングし、ローカルコードを並べて保持します。
- 確認、キューイング、リトライ。 すべてのv2メッセージにはACKが返されます。エンジンは永続化して再試行します。システムが再起動したために結果が失われることはありません。
- 冪等性。 結果と文書にはIDが含まれています。再送信は重複ではなく更新を行います。
- 新しいものすべてにFHIRレイヤーを。 患者アプリ、遠隔医療、研究抽出、外部パートナーは、HISに直接ではなく、ファサードまたは内部フローから供給される専用FHIRサーバーとFHIRで通信します。
- 合成患者を使用したテスト環境と、本番環境に適用する前の適合性テスト（IHE Connectathonプロファイル、国内テストスイート）。
あらゆる場所で見られる障害モード
ほぼすべての病院の統合で見られる障害モードは、登録時の入力ミスによる重複患者、マージ後の誤った診察への結果の記録、マッピングされていないローカルコード、タイムスタンプにおけるタイムゾーンと夏時間のエラー、自由形式の単位、監視なしで静かに停止するインターフェース、パーサーを破損させるベンダーのZセグメント、そして決して廃止されない一時的なCSVフィードです。
登録時の入力ミスによる患者の重複。マージ後の誤った受診への結果の保存。マッピングされていないローカルテストコード。メッセージタイムスタンプにおけるタイムゾーンと夏時間。自由形式の単位。サイレントに停止し、誰も監視しなかったインターフェース。パーサーを破損させるベンダー固有のZセグメント。そして、10年後も稼働している「一時的な」CSVフィード。
FHIRが状況を変えている場所
FHIRは、病院の統合の中核ではなく、周辺部で変化をもたらしています。建物内では、アナライザー、スキャナー、レガシーモジュールがHL7 v2とDICOMを使用しているため、これらが引き続き使用されます。FHIRは、患者アクセス、SMART on FHIRアプリ、CDS Hooksの意思決定支援、サブスクリプション、EHDSおよびTEFCAの下での地域および国家レベルの交換、研究抽出などを担当します。
内部的には、すべての分析装置、スキャナー、レガシーモジュールがそれらを話すため、HL7 v2とDICOMは何年も続きます。FHIRはエッジで勝利します：患者アクセス、EHR内で起動されるアプリ（SMART on FHIR）、意思決定支援（CDS Hooks）、イベント駆動型統合のためのサブスクリプション、EHDSとTEFCAの下での地域および国の交換、そして研究抽出。多くの病院では現在、エンジンによって供給されるFHIRサーバーを、建物の外にあるすべてのものの統合レイヤーとして実行しています。ヘルスケア相互運用性標準：マップを参照してください。
Anpherosにて
Anpheros Platformは、病院の統合のFHIRエッジに位置しています。これは、病院またはクリニックが患者の同意を得て読み書きできるFHIR R4レコードであり、ラボコネクタ（HL7 v2 ORU、CSVまたはJSON)を介して病院自身の統合から供給され、ソースごとにWebhookとプロビナンスを備えています。HISやエンジンを置き換えるものではありません。
Anpheros Platformは、そのエッジに位置しています。これは、病院またはクリニックが患者の同意を得て読み書きできるFHIR R4レコードであり、病院自身の統合（ラボコネクタはHL7 v2 ORU、CSVまたはJSONを受け取ります）によって供給され、変更通知のためのWebフックとソースごとの出所情報があります。HISやエンジンを置き換えるものではなく、患者が建物を出ても持ち運べる記録を提供します。
関連ページ
- インターフェースエンジンについて
- 検査システムとEHRを統合する方法
- HL7 v2メッセージについて：ADTとORU
- PACS vs RIS vs VNA
- FHIRによる遠隔患者モニタリング
- ヘルスケア相互運用性標準：マップ
- クリニックシステムをFHIRと統合する（開発者サイト）
資料
- HL7 Version 2 製品スイート
- IHE IT Infrastructure 技術フレームワーク
- IHE Devices ドメイン（Patient Care Device プロファイル）
- HL7 FHIR R4：メッセージングとワークフロー
- HL7 v2からFHIRへの実装ガイド
よくある質問
新しい病院はすべてをFHIRと統合すべきですか？
すべてではありません。分析装置、スキャナー、ほとんどの部門システムはHL7 v2とDICOMを使用しており、これはすぐに変わることはありません。FHIRは患者向け、外部向け、新しい統合に使用し、ブリッジとしてエンジンを使用してください。
HISとEHRの違いは何ですか？
国によって使用法が異なります。HISは多くの場合、管理および臨床病院システムを合わせたものを指し、EHRは臨床記録を強調します。統合の観点からは、どちらもID、受診、記録を管理するシステムです。
中規模病院にはいくつのインターフェースがありますか？
通常、エンジンを通過するメッセージフローは50から数百に及び、各方向と各受信システムをカウントします。エンジンの監視画面は、統合チームが日常的に使用する場所です。
病院で統合を所有するのは誰ですか？
通常、病院のIT統合チームが、エンジベンダーのサポートを受け、各部門ベンダーがその側面を担当します。国のプログラムとIHEプロファイルはプロジェクト作業を減らしますが、なくすことはありません。
サンドボックスで無料で試す
5分で最初のFHIR呼び出し. 患者さんの同意が組み込まれたHL7 FHIR R4 APIです。サンドボックスでお試しいただき、ご自身のアプリやクリニックのシステムを接続してください。
無料・合成患者30人・カード不要
Anpherosは、患者が管理し、あらゆるクリニックと共有できる医療記録を、EUを拠点とするHL7 FHIR R4プラットフォーム上で構築しています。これらのガイドは、ご自身の健康を理解し整理するのに役立ちますが、医師の代わりになるものではありません。
Anpherosについて →