EHR/EMRプラットフォームを構築した年月 — 最初はHAKEEMで、その後AFAQの創業者として — が教えてくれたのは、可視プロダクト（UI、ボタン、チャートビュー）は、システムが 病院の中で実際に機能する理由の多分15%に過ぎないということだ。残りの85%は見えない 書類仕事だ：規制、監査、インターオペラビリティ、そして薬局プリンターが午前3時に 期待する正確なワイヤーフォーマット。私がトレーニングしてきたヘルスケアエンジニアは 皆、出荷前に85%を過小評価し、出荷後に理解した。

氷山

ジュニアエンジニアが「バイタルサイン画面」を最初にデモする場面を想像してほしい。 心拍数、血圧、体温、きれいなグラフ。素晴らしい。一スプリントで出荷する。

そして現実が来る：

  • バイタルは三つの異なるプロトコル（TCP上のHL7 v2、ベンダー固有のバイナリ、 新しいもの向けのFHIR REST API）で六種類の異なるメーカーのデバイスから 来る必要がある。デバイスの半分はFHIR以前のもので、アップグレードされることは 決してない。
  • 医師が手動入力した数字はデバイスの数字と共存しなければならない。 どちらが 正規か？答え：誰のシフトか、どの病院か、どのデバイスモデルか、どの病棟の プロトコルドキュメントかによる。値フィールドではなく、出所フィールドが必要だ。
  • 画面は六年後の監査を乗り越えなければならない。 「同じ数字を表示する」 だけでなく — 誰が何をいつ見て、それを確認したかを証明する。 つまり上書き ではなく不変ログが必要だ。
  • 同じ画面がテナント間でリークしてはならない。 クリニックAのバイタルは クリニックBのスタッフに表示されない — クリニックAとクリニックBに両方所属する スタッフが存在するとしても。権限モデルはロール列挙型ではなくリレーションシップ グラフだ。
  • 規制標準は変わる。 HL7 v2が2010年の本命だった。FHIRが2025年の本命だ。 2035年の本命は何であれ、チャートビューを書き直さずに組み込めなければならない。

これらの箇条書きのそれぞれが、誰もビルしなかった一週間の作業だ。ほとんどは 延期できない — 初日から契約上、法的に、あるいは患者の安全上重要だからだ。

役に立つフレーミング

ジュニアエンジニアと仕事するとき、ヘルスケアプロジェクトの冒頭に明示的に 氷山を描くとうまくいった。可視プロダクトは15%だ。可視スコープは15%だ。 スプリント計画は15%についてだ。残りの85%は最初に設計しなければならない。 後付けにするとコストが二倍になるから。

具体的に、新しいヘルスケアビルドに私が最初にやることが五つある：

  1. 不変監査ログ。 患者に関連するあらゆるものへの書き込みは追記し、更新しない。 行レベルの台帳テーブルでも、イベントストリームでも、フラットファイルでもいい — ただし機能1が出荷される前にそこにある必要がある。ヘルスケアコードベースで 最も高くついたのが、これの後付けだ。
  2. 値ではなく出所。 すべてのフィールドは（値、ソース、observed_at、 信頼度）を持つ。フィールドがスカラーだというふりは銀行では構わない。二人の 臨床医が二つの異なるモニターから異なる数字を入力したシステムでは構わない。
  3. クエリレベルでのテナント分離。 PostgresでのRow Level Security、 または同等のもの。「アプリはtenant_idでフィルターする」ではない — いつかアプリは しなくなり、その日は侵害になるから。
  4. 直接統合ではなく、インターオップ層。 HL7 v2 + FHIR + 任意のベンダー バイナリを話し、アプリの残りの部分に対してクリーンな内部形式を公開する 小さなサービス。フォーマットは追加する。削除することは決してない。
  5. 規制レビューのケイデンス。 ゲートではなく、ケイデンスだ。四半期ごとに、 HIPAA / GDPR / ローカル同等物を気にすることが仕事の誰かが、出荷されたものを 見て懸念を提起する。これがなければ、ローンチ六ヶ月前に一つの巨大なパニック ゲートを持つことになる。

CVの行が隠しているもの

私のCVでは、AFAQは二行だ：「病院向けEHR/EMRプラットフォームを構築。」HAKEEMは 二行：「公立病院向け国家EHR。」

これらの行が言っていないこと：

  • AFAQで、薬局システムが入力として求めたMUMPS隣接コードで薬物相互作用チェックの 最初のバージョンを書いた。それを出荷した週、ある臨床医が感謝してくれた。前の プロセスは机に置いておかなければならなかった印刷PDFだったから。
  • HAKEEMで、複数の病院にまたがるデプロイの安定化を見守った。ブロッカーは コードではなかった — 六人の異なるメディカルディレクターがデータモデルで 「入院」が何を意味するかについて合意することだった。コードは数週間で出荷した。 合意には数ヶ月かかった。合意が本物の成果物だった。
  • 両方のシステムは今もどこかで動いている。2012年に私が書いたコードが今もヨルダンの 病院でバイタルをルーティングしている。これは自慢ではなく — ヘルスケアシステム はそれを設計した人と契約よりも長く生き続けるというリマインダーだ。初日からそれを 念頭に計画しろ。

2026年の展開

静かな部分を言おう：AI支援エンジニアリングは85%の驚異的なアクセラレーターだ。 見えない書類仕事はほとんどパターン作業だ — 監査の配線、出所変換、インターオップ アダプター、テナントフィルター。これらはフレーミングがうまくいけばLLMが得意な 生成物だ。15%の可視プロダクトはまだ人間の判断が最も重要な場所だ。臨床ワークフロー がUIと出会い、間違った選択が人々の午後を台無しにするからだ。

2026年のチームが犯す間違いは逆だ：AIを使って派手なダッシュボードを生成し、 監査層を曖昧にする。正しい順序はその逆だ。AIを使って85%を素早く正確に組み込む。 人間の注意を看護師が実際に触れる15%に使え。

すべてのヘルスケアエンジニアが学ぶべき一つのこと

明日新しいエンジニアをヘルスケアプロジェクトにオンボードするなら、最初の一週間を 実際の病院ITシステムからのインシデントレポートを読むことに費やさせる。HIPAA 侵害申告ではない（あれは弁護士向けだ）。病院ITコミュニティからの実際のポストモーテム — 間違った用量を印刷した薬局システム、ラボ結果の半パーセントを落としたインターオップ アダプター、三年前の患者記録をリストアして一週間誰も気づかなかったバックアップ。

その一週間が85%が存在する理由を教えてくれる。すべての「それは必要ない」ショートカット は他の誰かの前の火曜日だ。十分に読めば、監査ログをスキップしてくれと頼むのをやめる。