KHCC と HAKEEM の HL7 インテグレーション
キング・フセイン・がんセンターとヨルダン国家 EHR 間の HL7 v2 インテグレーション--患者アイデンティティ解決、イベント順序付け、メッセージルーティングの実装記録。
ほとんどのエンジニアは本物の HL7 メッセージを見たことがない。
フィンテックで働いたことがあれば ISO 8583 をパースしたことがあるだろう。ロジスティクスで働いたことがあれば EDI を扱ったことがあるだろう。二つの病院システム間のライブインテグレーションを構築したことがあれば、HL7 v2 を見て、以前はなかった意見を持っている。
Electronic Health Solutions のチームは 2010-2013 年の関与期間中に キング・フセイン・がんセンター（KHCC） と HAKEEM—ヨルダンの国家 EHR—の間の HL7 インテグレーションを構築した。実際にどう見えたかがこれだ。
HL7 v2 メッセージがどう見えるか
ワイヤフォーマットがエンジニアを最初に顔をしかめさせるものだ。
MSH|^~\&|KHCC|KHCC|HAKEEM|MOH|20120315120000||ADT^A01|MSG00001|P|2.3
EVN|A01|20120315120000
PID|1||12345^^^KHCC^MR||AL-MANSOUR^AHMAD^MOHAMMED||19750304|M|||AMMAN^JO||||AR|M||12345
PV1|1|I|ONCOLOGY^101^1^KHCC||||SMITH^JOHN^A^^^DRこれが ADT^A01 だ—入退院転送メッセージで、イベント A01 は患者入院を意味する。すべてのセグメントはパイプ区切り。セグメント内のフィールドはパイプで区切られる。サブフィールドは ^ で。サブサブフィールドは & で。繰り返しフィールドは ~ で。
MSH セグメントはメッセージヘッダー：送信アプリケーション、送信施設、受信アプリケーション、受信施設、タイムスタンプ、メッセージタイプ、メッセージ ID、処理 ID、バージョン。PID セグメントは患者アイデンティティ：ID リスト、名前、生年月日、性別、住所、言語。バージョン—HL7 v2.3—は1997年に確定した。パイプ区切りフォーマットは XML がエンタープライズシステムを征服する前の時代のものだ。美しくない。病院が実際に患者データを保存・交換する方法に直接マッピングする—これが FHIR、CDA、それを置き換えることを意図したすべての標準にもかかわらず、何十年も後の今もヘルスケアで支配的なワイヤフォーマットである理由だ。
KHCC が特定の課題だった理由
キング・フセイン・がんセンターは一般病院じゃない。ヨルダンのフラッグシップ専門腫瘍施設—Princess Ghida Talal の後援の下に設立された卓越センターで、地域にわたる治療、研究、教育をミッションとする。患者は他の病院からの紹介で到着し、その多くはすでに HAKEEM 上にあった。
これは患者の記録が KHCC では始まらないことを意味する。紹介施設で始まる—例えば Prince Hamza Hospital—そこで最初に腫瘍専門知識を必要とする状態と診断された。彼らの人口統計、初期診断、投薬歴、検査結果はすべて HAKEEM に住んでいる。
その患者が KHCC に到着すると、KHCC は独自の EHR を持っている。独自の患者 ID スペース。化学療法プロトコル、放射線治療計画、腫瘍専門ラボパネルのための独自のデータモデル。
課題は「KHCC のデータを HAKEEM に入れる」ことじゃない。課題は 異なる ID を同じ人間に割り当てた二つのシステムをまたいだ患者アイデンティティ解決、続いて重複を作らず臨床コンテキストを失わずに両システムを最新に保つ双方向同期だ。
HL7 v2 はその問題のトランスポートレイヤーだ。解決策じゃない。
実際に難しい部分
患者アイデンティティは解決済みの問題じゃない。 KHCC は独自の医療記録番号を割り当てた。HAKEEM は独自の国家患者識別子スキームを維持した。PID-3 フィールドは患者 ID リストを収容する—患者が複数のシステムをまたいで複数の識別子を持つからだ。でも KHCC の患者 12345 が HAKEEM の患者 98765 であることを知るにはマッピングテーブルが必要で、そのテーブルの構築は名前 + 生年月日 + 性別 + 住所の確率的マッチング、または手動照合、または—実際には—異なる信頼度閾値のために異なるルールを持つ両方の組み合わせが必要だ。
イベントの順序付けは臨床上重要だ。 HL7 ADT メッセージはイベントタイプを運ぶ：A01 は入院、A02 は転院、A03 は退院、A08 は情報更新。これらのイベントは順序通りに到着して処理されなければならない、さもなければ臨床像が間違う。入院、転院、そして退院した患者は、それらのメッセージが順不同で到着して退院した後の部門に転院したとして処理された場合と非常に異なって見える。
大量インテグレーションでは、メッセージは常に順序通りに到着するわけじゃない。TCP は信頼性の高い配信を提供する；非同期でメッセージが生成されるときのアプリケーションレベルの順序保証は提供しない。シーケンス番号、確認（ACK/NAK）、メッセージを失ったり宛先を重複で溢れさせたりせずに NAK を処理するリトライロジックを持つキューが必要だ。
送信システムの実装が本物の仕様だ。 HL7 v2.3 はオプションフィールドと大きな実装バリエーションの余地を持つ標準だ。KHCC の EHR が実際に PID-3 に送ったものが重要だった—仕様がそこにあるべきと言ったものじゃなく。KHCC の技術チームと実際の送信メッセージを分析することに時間を費やした、なぜなら実装ドキュメントが不完全だったから。これは普通だ。すべての HL7 インテグレーションにこの話がある。
ルーティングレイヤーがどう見えたか
インテグレーションは VistA の HL7 メッセージングパッケージを使った—HAKEEM 側でインバウンドメッセージのパースとルーティングを処理する MUMPS ルーティン。チームは特定のイベントタイプのルーティンを書いた：主に患者の動きのための ADT イベント、ラボのオーダーと結果のための ORM/ORU ペア。
紹介フロー：
- 紹介病院（HAKEEM 上）が患者を KHCC に送る。
- KHCC が患者を登録し、MRN を割り当てる。
- KHCC が入院を確認する ADT^A01 を HAKEEM に送る。
- HAKEEM ルーティングレイヤーが A01 を受信し、マスター患者インデックスマッピングで患者アイデンティティを解決し、KHCC エンカウンター情報で患者記録を更新する。
- KHCC の腫瘍パネルからの検査結果が ORU^R01 メッセージで流れ戻り、依然として患者の一次診療関係を持つ紹介医師に見える患者の HAKEEM 記録に着地する。
その最後の点は臨床上重要だ。KHCC の腫瘍医ながんを治療している。紹介病院の一般医は依然として患者の高血圧、糖尿病、その他すべてを管理している。彼らは患者が施設間で紙の記録を運ばなくてもいいように腫瘍の結果を見る必要がある。HL7 インテグレーションがそれを可能にするものだ。
12年後のこれがどう見えるか
HL7 v2 は美しいソフトウェアじゃない。でも、尊重を得る種類の醜さだ—問題ドメインが醜いから醜いのであって、設計者が試みなかったからじゃない。ヘルスケアデータは乱雑だ、なぜならヘルスケアが乱雑だから。患者が複数の識別子を持つのは複数のシステムとインタラクションするからだ。イベントには順序付けが必要なのは臨床タイムラインが診断上重要だからだ。フィールドのオプション性は緩さに見える；実際にはそれを使う必要がある臨床専門分野の幅に対応している標準だ。
FHIR はほとんどの点で本当に優れている。2012年、FHIR はドラフト仕様だった。HL7 v2 は病院システムが話す言語だった。あるものと統合する。
ヘルスケアインテグレーションを構築するエンジニアは、業界のほとんどが見ない作業をしている。ラブシステムから医師の画面のカルテへ検査結果を運ぶ HL7 メッセージは配管だ。誰も壊れるまで配管に気づかない。このパイプはまだ動いている。