プロジェクト · 2016 · リード · アーカイブ

AFAQ ヘルスケアスイート

サウジアラビアの Prince Sultan Cardiac Centre に導入した全病院向け EHR/EMR プラットフォーム。12名チームを率いて 2014 年から 2017 年まで Mo が開発・リードした。

Client-server architecture diagram showing request-response flow, hero image for architecture topic posts.

2014年8月、私は27歳で、あらゆる分別のある人間が止めることをやった:アンマンでヘルスケアソフトウェア会社を共同創業した。ランウェイ計画とピボットオプションを持つSaaSサイドプロジェクトじゃない。生きた心臓病院—サウジアラビアの、本物の患者と本物の臨床ワークフローと本物の失敗代償がある場所—に完全な電子カルテシステムをリリースするコンサルタンシーだ。

AFAQ と名付けた。エンジニア12名。私は創業者、CTO、プリンシパルエンジニア、プロダクトマネージャー、代理CEO、IT マネージャー、開発マネージャーを同時に、同じ名刺に、最初の一年間は事実上ゼロの給与でやっていた。「Chief Everything Officer」が人間を犬年で老けさせることは誰も教えてくれなかった。

スイートが実際に何だったか

AFAQ のコア製品は全病院向け EHR/EMR プラットフォームだった:臨床、管理、財務モジュールと完全な ERP 機能付き。ピッチはコヒーレンス—病院が七つの異なるシステムに七つの異なるベンダーを使う必要はないはずだ。一つのプラットフォームをリリースする、ヨルダン製、紙とレガシーからモダンへのアップグレードサイクルの途中にある湾岸ヘルスケア施設向けに。

スタックは最小限じゃなかった。Java EE。Spring Boot、Spring MVC、Spring Security、Spring WS。Hibernate と JPA。管理インターフェースに AngularJS と Bootstrap。データ変換に Talend ETL。アプリケーションサーバーに Tomcat と WildFly。インテグレーションレイヤーに Symfony と Yii の PHP。プライマリデータベースに MySQL と Oracle。相互運用性に HL7 と FHIR。そして GT.M—これは後で説明する。

12名チームには多すぎる?そうだ。それでもリリースした、なぜならコントラクトに署名したのは自分だからスコープについて文句を言う権利がない。

誰も書いていなかった GT.M コネクター

これは十年経った今でも誇りに思う部分だ。

GT.M は階層型 NoSQL データベース—1980年代からアメリカの退役軍人病院で動いている VA のオープンソース EHR、VistA の下にあるストレージエンジンだ。MUMPS(現在は M と呼ばれる)上で動く。ツールは少ない。ドキュメントは40年前にさかのぼる文脈を知っていることを前提にしている。

2015年、GT.M のモダンなデータベースコネクターを書いている人はいなかった。AFAQ には必要だった—薬局と請求データが GT.M インフラの中に住んでいる病院システムとインターフェースしなければならず、クライアントが心臓センターでデータが臨床上の荷重を担っているときに「迂回する」という選択肢はなかった。

だから GT.M プログラマーズガイドを読んで、MUMPS の仕様を読んで、GT.M をモダンな Java サービスから呼べるように振る舞わせるコネクターを書いた。ほとんどのエンジニアはキャリアでデータベースコネクターをゼロ本書く。書く人のほとんどは Postgres か MySQL 向けに一本書く、そこではすべての質問に Stack Overflow の答えがある。2015年に GT.M コネクターを書くことは、自分が生まれる前からこれをやっている人々のソースコードとメーリングリストを読むことを意味した。すべての時間が価値があった。

サウジアラビアの心臓専門病院への導入

フラッグシップデプロイは、サウジアラビアのアルアフサにある Prince Sultan Cardiac Centre—専門的な心臓施設で、KPI が四半期ごとの成長数字じゃなく、door-to-balloon time(患者が胸痛を訴えてから処置が始まるまでの間隔)、投薬調整エラー率、重複検査オーダー数といったものだ。

これらは生命と安全の KPI だ。ゴーライブ前に AFAQ チームはセンターの臨床ワークフロー全体にわたって KPI 分析を実施した—紙ベースとレガシーのプロセスをマッピングして、数字が最も重要な場所を特定して、EHR 内に適切なデータを適切な場所に表示するレポートパイプラインを構築した。Talend ETL が変換負荷を担い、HL7 メッセージがシステム間の相互運用性レイヤーを処理した。

ゴーライブは火曜日だった。数名の看護師がボタンの移動場所を聞いてきた。うまくいったサインはこれだ。

12名のエンジニア、月に1回のアーキテクチャ決断

同じプロダクトのプリンシパルエンジニアでありながら12名のエンジニアを管理することは、きれいな答えのない調整問題だ。技術的な決断を委任することになっている。でも、コントラクトの責任を担っているからチームの誰よりも速くそれを決めなければならない。その二つは毎週ぶつかる。

うまくいったのは:極端な所有権の具体性。すべてのエンジニアが一つのものを所有した。請求エンジニアは請求を所有した。薬局エンジニアは薬局を所有した。クロスドメインの決断は私を通して、月に最大2つ—なぜならクロスカッティングな決断は全員へのコンテキストスイッチ税だから。

ブログポストのコンセプトになる前にリーンなドメイン所有権を実践していた。オリジナルのアイデアじゃない;スコープが広くてチームが小さいときにスモールコンサルタンシーを一貫した状態に保つための方法だ。

アーカイブが意味すること

AFAQ は2014年8月から2017年1月まで動いた。2年半。2017年初めに離れた;スイートはその時点で本番稼働中だった。Prince Sultan Cardiac Centre で今でも何らかの形で動いているかどうか—正直わからない。ヘルスケアソフトウェアは元の作者よりずっと長生きする傾向がある。GT.M コネクターは特に:あの種のインフラは誰かの望むタイムラインで置き換えられない。

会社は会社というより鍛冶場だった。12名のエンジニアが Java か PHP を知って入ってきた。医療データモデルがどう機能するか、HL7 がなぜ存在するか、12層の調達承認を持つ病院 IT 部門とどう交渉するか、そしてプロダクションデータベースが Oracle でクライアントが心臓 ICU を運営しているときにデータモデル層での前提を間違えることがいくつかかかるかを知って出ていった。

私も同じ知識を持って出てきた、プラスヘルスケアソフトウェアを難しくするものについての非常に具体的な意見のセット—そしてそれはコードとほとんど関係がない。