HAKEEM 国家電子カルテシステム

2010年、Node.js v0.4 がリリースされてインターネットはサーバーサイド JavaScript がジョークかどうかについて一年中議論していた。その間、22歳の時、Electronic Health Solutions（EHS）—ヨルダン政府とヘルスケアプロバイダーコンソーシアムの官民パートナーシップ—のチームは、最終的にヨルダン全土の四病院にサービスを提供することになる国家 EHR の薬局調剤モジュールの MUMPS ルーティンを書いていた。

それが HAKEEM だ。チームの役割は2010年から2013年まで開発者兼システムアナリスト。三年間。四病院。モダンなエンジニアに顔をしかめさせる—が、次の十年への最適な準備となることが判明した—テクノロジースタックの上に構築された一つの国家規模システム。

HAKEEM が何の上に構築されたか

HAKEEM は VistA—1980年代からアメリカの退役軍人病院に導入されている米国退役軍人省が開発した Veterans Information Systems and Technology Architecture—の上に構築された。VistA は地球上で最も長く動いている EHR システムの一つで、商業 EHR がなかなか匹敵できない方法でバトルテスト済みだ：薬局モジュール、臨床決定支援、スケジューリング、請求、これらすべてが一つのまとまったデータモデルの下にある。オープンソースはヨルダンが国家展開のためにプロプライエタリなソフトウェアをライセンスする必要がないことを意味した。GT.M（階層型 NoSQL データベース）上で動くという事実は、MUMPS を読めて40年物のスタックを恐れないエンジニアが必要であることを意味した。

実際の作業がどう見えたか

タイトルは開発者/システムアナリストだった。実際には、並列で動く三つの異なる作業ストリームだった。

MUMPS ルーティン。 チームは三つのパッケージでMルーティンを書いた：薬局、請求、HL7 メッセージング。MUMPS での薬局調剤ロジックは美的感覚を傷つけて、それから40年間正しく動き続けるものの一つだ。変数はデフォルトでグローバルだ。データベースが言語だ—グローバル（MUMPS の永続変数の用語）は階層型データベース構造に直接マッピングされる。ルーティンはファイルだ。現代的な意味での関数はない；構造化プログラミングの人々を不快にさせるラベルと GOTO 相当があるだけだ。それでも：HAKEEM の薬局モジュール向けに書かれた調剤ロジックは今日でも何らかの形でヨルダンの病院で動いている可能性が高い。それはほとんどの JavaScript フレームワークについては言えないことだ。

C# GUI アプリケーション。 主なものは二つ：患者情報管理 GUI とスケジューリング GUI で、どちらも VistA バックエンドと RPC Broker プロトコル経由で通信していた。退屈に聞こえる。そうじゃなかった。国家 EHR での患者情報管理は、登録看護師のインターフェースがすべてのダウンストリームシステムへのデータエントリーポイントであることを意味する—薬局、ラボ、請求、報告。ゴミを入れることを許すGUIを構築すると、ゴーライブから6か月後に Prince Hamza Hospital で患者 ID の不一致をデバッグしている。スケジューリング GUI には同様の重みがあった：アンマン総合クリニックでの外来クリニックスケジューリングは複数の部門にまたがる予約枠、キャンセル処理、スタッフィングレポートを意味した。壊れたときに非常に重要な退屈なソフトウェア。

モバイル GUI。 2012年に。ヘルスケア EHR 向けに。Android は Java、iOS は Objective-C。2012年のモバイルヘルスケアは成熟した空間じゃなかった—Android はバージョン4.0、iOS 6 は数か月先で、モバイルデバイスで患者記録にアクセスする臨床家のための UX 規約はまだ存在しなかった。チームは、モバイルデバイスでの患者記録の読み間違いがツイートの読み間違いとは異なる患者安全上の意味を持つという制約の下でそれを解決していた。

Bash バックアップスクリプト。 これも仕事の一部だった。GT.M データベースは Linux サーバーで動いていて、信頼性の高いバックアップとタスク管理が必要だった。華やかじゃない。完全に荷重を担っている。データを失う病院は間違った理由で見出しになる。

四病院、四つのデプロイストーリー

HAKEEM は四施設に展開され、それぞれが独自のプロジェクトだった。

Prince Hamza Hospital は大規模な総合病院だった—高ボリューム、複数の専門診療科、EHR の機能全体にわたる。患者登録とスケジューリングが一日数百人の外来患者でスケールするかどうかがわかる場所。

アンマン総合クリニック は外来モデルだった。入院ケアは少なく、予約管理と慢性疾患のフォローアップが中心。スケジューリング GUI はここで本領を発揮した。

Prince Hussein Hospital は、デフォルトの VistA 設定にクリーンにマッピングされない臨床ワークフロー要件を持っていた。MUMPS レイヤーでのカスタマイズ。1993年のルーティンを読んで、ダウンストリームのすべてを壊さずにどの行を変えるかを決める種類の作業。

キング・フセイン・がんセンター はインテグレーションプロジェクトだった—KHCC は独自の EHR、独自の患者記録、独自のワークフローを持ち、HL7 v2 で HAKEEM と接続する必要があった。そのインテグレーションはチームが構築し、別途文書化されている；短いバージョンは二つの MRN スペースをまたいだ患者アイデンティティ解決、イベント順序付け、パイプ区切りメッセージのパースと変換だ。

国家規模インフラが教えてくれること

HAKEEM での三年間が教えてくれて、それ以降のすべてのプロジェクトで持ち続けていること：「動くソフトウェア」と「国が依存するインフラ」のギャップは技術的な問題じゃなく組織的な問題だ。

コードは難しかった。MUMPS は正当な意味で、美的だけじゃなく難しい。HL7 は難しい。誰もプレイブックを持っていない前にモバイル EHR GUI を2012年に書くことは難しかった。

でも、難しい問題にはデバッガーがなかった。次のカスタマイズスプリントはどの病院が受けるか？同じ MUMPS ルーティンに矛盾する変更が必要な二つの病院があるとき誰が決断を所有するか？翌朝患者を診ている施設で展開の途中にいるときロールバックは何を意味するか？

あの三年間の技術スキルは価値があった。組織レイヤーで複雑なシステムがどう失敗するかの理解はより価値があった。MUMPS で薬局ロジックを書くことは、どちらも同時に学ぶかなり良い方法だったと判明した。