ほとんどのエンジニアは本物のHL7メッセージを見たことがない。

フィンテックで働いたことがあれば、ISO 8583を解析したことがあるだろう。物流で働いたことがあれば、EDIを扱ったことがあるだろう。ヘルスケアデータで — 具体的に二つの病院システム間のライブインテグレーションを構築したことがあれば — HL7 v2を見て、以前は持っていなかった意見を持つようになっているだろう。

私はElectronic Health Solutions勤務の2010年から2013年の間に、King Hussein Cancer Centre（KHCC）とヨルダンの国家EHR、HAKEEMの間の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||||||||ONCOLOGY|||V|||||||||||||||||||||||20120315

これはADT^A01 — 入退院/転棟メッセージで、イベントA01は患者入院を意味する。すべてのセグメントはパイプ区切りだ。セグメント内のフィールドはパイプで区切られる。サブフィールドは^で区切られる。サブサブフィールドは&で。繰り返しフィールドは~で。

MSHセグメントはメッセージヘッダーだ：送信アプリケーション、送信施設、受信アプリケーション、受信施設、タイムスタンプ、メッセージタイプ、メッセージID、処理ID、バージョン。PIDセグメントは患者識別子だ：患者IDリスト（多くのシステムから多数ある）、名前、生年月日、性別、住所、言語、婚姻状況、宗教、口座番号。

HL7 v2.3 — 私たちが使っていたバージョン — は1997年に確定した。パイプ区切りフォーマットは、帯域幅が高価でXMLがまだエンタープライズの世界を征服していなかった時代からだ。美しくない。病院システムが実際に患者データをどのように保存して交換するかに直接マッピングされている。だからこそ、FHIRやCDAや置き換えるはずだったすべての他の標準にもかかわらず、数十年後もヘルスケアにおける支配的なワイヤフォーマットだ。

KHCCが特定のインテグレーション課題だった理由

King Hussein Cancer Centreは総合病院ではない。専門の腫瘍施設だ。患者はKHCCに他の病院からの紹介で到着する — ヨルダンの国家システムでは、その多くはすでにHAKEEM上の施設からだ。

つまり、患者のレコードはKHCCから始まらない。最初に腫瘍の専門知識が必要な状態と診断された紹介施設 — 例えばPrince Hamza病院 — から始まる。その患者レコードには人口統計、最初の診断、投薬歴、検査結果が含まれる。そのすべてがHAKEEMに存在する。

その患者がガン治療のためにKHCCに到着するとき、KHCCは独自のEHRを持っている。独自の患者IDスペース。化学療法プロトコル、放射線治療計画、腫瘍特有の検査パネルなどの臨床概念のための独自のデータモデル。課題は「KHCCのデータをHAKEEMに入れる」だけではない。課題は、同じ人間に異なるIDを割り当てた二つのシステムにわたる患者ID解決であり、それに続く、重複レコードを作ることなく、臨床コンテキストを失うことなく、両システムを最新の状態に保つ双方向レコード同期だ。

HL7 v2はその問題のトランスポートレイヤーだ。その問題への解決策ではない。解決策は患者マッチングアルゴリズム、マスター患者インデックス、一方のシステムのどのイベントが他方へのメッセージをトリガーするかを理解するメッセージルーティングレイヤーだ。

実際に難しい部分

「HL7を解析するだけ」が省略することはここだ。

患者IDは解決済みの問題ではない。 KHCCは独自の医療記録番号（MRN）を割り当てた。HAKEEMは独自の国家患者識別子スキームを維持した。PIDセグメントには患者IDリスト用のフィールドがある — PID-3 — まさに患者が複数のシステムにわたって複数の識別子を持つからだ。しかし患者がKHCCで12345、HAKEEMで98765のIDを持つことを知るには、マッピングテーブルが必要だ。そのテーブルの構築には、自動的な確率マッチングアルゴリズム（名前＋生年月日＋性別＋住所でマッチ、信頼度をスコアリング）か手作業の照合プロセス、または — 実際には — 異なる信頼度閾値に異なるルールを持つ両方が必要だ。

イベントのシーケンシングは臨床的に重要だ。 HL7 ADTメッセージはイベントタイプを持つ — A01は入院、A02は転棟、A03は退院、A08は患者情報更新。これらのイベントは順序通りに届いて順序通りに処理されなければならない。でなければ臨床像が間違っている。入院（A01）し、転棟（A02）し、退院（A03）した患者は、それらのメッセージが順序通りでなく到着して、患者がすでに去った部門に入院、退院、転棟という順序で処理された場合とは全く異なって見える。

高ボリュームの病院インテグレーションでは、メッセージは常に順序通りに届くわけではない。TCPは信頼性の高い配信を提供する。異なるシステムが非同期にメッセージを生産するときのアプリケーションレベルの順序保証は提供しない。シーケンス番号、メッセージ確認応答（ACK/NAK）、そしてメッセージを失うことなく宛先をリクエストで溢れさせることなくNAKを処理するリトライロジックを持つキューが必要だ。

送信システムの実装が本当の仕様だ。 HL7 v2.3は標準だ。しかし標準にはオプションのフィールド、オプションのセグメント、実装の変化に対する重要な余地がある。KHCCのEHRがPID-3に実際に何を送るかが重要だった — HL7仕様が何があるべきかを言っているかではなく。KHCCの技術チームと実際のアウトバウンドメッセージを分析するのに意味のある時間を費やした。実装文書が不完全だったからだ。これは正常だ。私が聞いたすべてのHL7インテグレーションにこのストーリーのバージョンがある。

メッセージルーティングレイヤーがどんな様子か

HAKEEM-KHCCインテグレーションはVistAのHL7メッセージングパッケージを使った — そのパッケージのMUMPSルーティンはHAKEEM側でインバウンドメッセージの解析とルーティングを処理した。私は特定のイベントタイプを処理するルーティンを書いた — 主に患者移動のためのADTイベントと検査オーダーと結果のためのORM/ORUペア。

紹介のフロー：

  1. 紹介病院（HAKEEM上）が患者をKHCCに送る。
  2. KHCCが独自のシステムに患者を登録し、MRNを割り当てる。
  3. KHCCが入院を確認するADT^A01をHAKEEMに送る。
  4. HAKEEMのHL7ルーティングレイヤーがA01を受け取り、MIマッピング経由で患者IDを解決し、KHCC遭遇情報でHAKEEMの患者レコードを更新する。
  5. KHCCの腫瘍パネルからの検査結果がORU^R01メッセージ経由でフローバックし、まだ患者の主治医の関係を保持している紹介医師が見えるHAKEEMレコードに着地する。

最後の点は臨床的に重要だ。KHCCの腫瘍医はガンを治療している。紹介病院の一般医はまだ患者の高血圧、糖尿病、その他すべてを管理している。彼らは腫瘍の結果を見る必要がある。HL7インテグレーションは患者が施設間で紙の記録を運ぶことなくそれを可能にするものだ。

十二年後のHL7への見方

HL7 v2は美しいソフトウェアではない。しかし尊重を獲得するような種類の醜さだ：設計者が努力しなかったからではなく、問題ドメインが醜いから醜い。

ヘルスケアデータは混乱している。なぜなら、ヘルスケアが混乱しているからだ。患者は複数の識別子を持つ。なぜなら複数のシステムと相互作用するからだ。イベントは順序要件を持つ。なぜなら臨床タイムラインが診断と治療に重要だからだ。仕様を緩く見せるフィールドの任意性は、異なる臨床専門科が異なるデータ要件を持ち、標準がすべてに対応しなければならないからそこにある。

FHIRはほとんどの点で本当により良い — RESTful、JSONまたはXML、リソース指向、モダンなツーリング。十二年も新しい。2012年、FHIRはドラフト仕様だった。HL7 v2が病院システムが話す言語だった。そこにあるものとインテグレーションする。

ヘルスケアインテグレーションを構築するエンジニアは、業界のほとんどが見ず考えない作業をしている。検査結果を検査システムからあなたのチャートに、そして医師の画面に運ぶHL7メッセージは配管だ。誰も壊れるまで配管に気づかない。

私は配管に気づいた。その一部を作った。パイプはまだ動いている。