2014年8月、私は27歳でアンマンに住んでおり、常識的な誰もがするなと言うことをやった：ソフトウェア会社を設立した。SaaSのサイドプロジェクトではない。サウジアラビア、アル・アフサーのPrince Sultan Cardiac Centreに完全なElectronic Health Recordシステムをデプロイすることになるヘルスケアソフトウェアのコンサルタンシーだ。
私たちはそれをAFAQと呼んだ。十二人のエンジニア。本物の病院。本物の患者。私はFounder、CTO、Principal Engineer、Product Manager、Acting CEO、IT Manager、Development Manager — 同時に、同じ名刺で、同じ給与（最初の年は事実上ゼロだった）だった。
誰も「Chief Everything Officer」は犬の年で老いさせる職務記述だとは警告してくれなかった。
AFAQが実際に構築したもの
EHR/EMRプラットフォームを構築した — 臨床、管理、財務モジュール、完全なERPの機能を追加して。アイデアは、病院が七つの異なるシステムのために七つの異なるベンダーを必要とするべきではないということだった。一つの一貫したプラットフォームを出荷し、ヨルダン製で、紙とレガシーから現代的なものへのアップグレードサイクルの途中にあるGulfのヘルスケア施設にデプロイする。
スタックは最小ではなかった。Java EE。Spring Boot、Spring Security、Spring WS。HibernateとJPA。フロントエンド：重い臨床インターフェース用GWT（Google Web Toolkit）、管理向けAngularJSとBootstrap。ETL用Talend。アプリサーバーとしてTomcatとWildFly。インテグレーション用PHPとSymfonyとYii。主要データベースとしてMySQLとOracle。相互運用性にHL7とFHIR。
それは多い。十二人チームには多すぎる。それでも出荷した。なぜなら、コントラクトを売った人間は範囲について文句を言える立場にないからだ。
誰も書いていなかったDBコネクター
ここが私がまだ誇りに思う部分だ：fis GT.Mの新しいDBコネクターを書いた。
GT.Mを聞いたことがなければ — あなただけではなく、それがポイントだ。GT.Mは、1990年代からアメリカの退役軍人病院全体にデプロイされているVAのオープンソースEHRシステム、VistAの内部で動く階層型NoSQLデータベースだ。MUMPS（今はMと呼ばれる）と呼ばれる言語で動く。アクセスパターンは古く、ツーリングは乏しく、ドキュメントは四十年のコンテキストをすでに知っていることを前提とする。
2015年にGT.Mのモダンなデータベースコネクターを書いていた人はいなかった。私たちがやった。なぜならAFAQのプラットフォームはGT.Mインフラを動かす病院システムとのインターフェースが必要だったからだ — 「回避する」はクライアントの薬局と課金データがその中に存在するときにはオプションではなかった。それでGT.Mプログラマーズガイドを読み、MUMPS仕様を読み、GT.MをモダンなJavaサービスから呼び出せるように振る舞わせるコネクターを書いた。
キャリアの中でDBコネクターを書くエンジニアのほとんどはPostgresまたはMySQLのために書く。すべての質問にStack Overflowの答えがある。2015年にGT.Mのコネクターを書くことは、私が生まれる前からこれをやっていた人々のソースコードとメーリングリストを読むことを意味した。
十二人のエンジニア、意味をなさない一つの組織図
プロダクトの主任エンジニアであると同時に十二人のエンジニアを管理することは、クリーンな答えがない調整問題だ。技術的決定を委任するべきだ。そしてまたコントラクトに責任を持つ立場だからチームの誰よりも速くそれを行うべきだ。二つのことは常に互いに戦う。
学んだこと：小さなコンサルタンシーで最も重要な制約は技術的なものではなく、一人あたりの範囲の特定性だ。すべてのエンジニアが所有して責任を持つ単一のものが必要だ。二人のエンジニアが両方とも「臨床モジュールを作業している」瞬間、マージ問題とスプリントを食い尽くすコミュニケーションオーバーヘッドが生じる。
ブログポストのコンセプトになる前に、リーンなドメイン所有権を行っていた。課金エンジニアが課金を所有した。薬局エンジニアが薬局を所有した。私はそれらの境界線を越えるアーキテクチャ上の決定を所有し、最大月に二つ行った。なぜなら、すべてのクロスカッティングな決定は全員へのコンテキストスイッチ税だからだ。
心臓病院デプロイでのKPI分析とはどんな様子か
Prince Sultan Cardiac CentreでのGO-LIVE前に、臨床ワークフロー全体でKPI分析と実装を実行した。これは抽象的に聞こえる。具体的に何を意味するかを説明しよう。
心臓センターが気にするのは：door-to-balloon時間（胸痛から介入までどれくらいか）、薬物調整エラー、重複検査オーダー、部門間の患者IDミスマッチ。これらは理論的なKPIではない。生命と安全のKPIだ。報告を間違えても悪い四半期レビューにはならない — 名指しされたくない臨床監査になる。
それで臨床リードと座り、既存の紙ベースとレガシーシステムのワークフローをマッピングし、EHRに正しい場所に正しい数字を表示するレポートパイプラインを構築した。TalendのETLがレガシーデータと私たちのモデル間の変換の重労働を担った。HL7メッセージが相互運用性レイヤーを担った。
GO-LIVEは劇的な瞬間ではなかった。火曜日だった。数人の看護師がボタンがどこに移ったかを尋ねた。それがうまくいったことを知る方法だ。
AFAQが本当に何のためだったか
AFAQは2014年8月から2017年1月まで続いた。二年半。出荷した。クライアントがいた。本番の病院で動いているシステムがいた。
しかしAFAQは会社というより鍛冶場だった。JavaまたはPHPを知って入ってきてヘルスケアデータモデルがどう機能するかを知って去った十二人のエンジニア。HL7がなぜ存在するか。十二層の承認がある病院のIT部門とコントラクトをどう交渉するか。Oracleが本番データベースでクライアントがサウジアラビアの心臓病院のとき、データモデルレイヤーでの仮定を間違えることが何を犠牲にするか。
私はAFAQから非常に特定の意見セットで出た。ヘルスケアソフトウェアはコードとは何も関係ない方法でエンタープライズソフトウェアより難しい。十二人チームは本物のシステムを生み出すのに十分な大きさで、百人の会社とは異なる方法で依然として脆弱なほど小さい。1980年代の階層型データベースのDBコネクターを書くことは受けるどんなコースよりもデータモデリングについての良い教育だ。
六つの職名を持つ名刺はカオスだった。私たちが出荷したシステムはそうではなかった。それがすべてのポイントだった。