業務システム開発において、すべてのテーブルの主キーを{id}とする「単独主キー主義」ではデータ項目間の「関数従属性」を見落としやすい、と何度か警告してきたが、その大規模な失敗事例を紹介しよう。
英国NHS国家ITプログラム（National Program for IT: NPfIT）は、世界最大規模の医療DXプロジェクトとして2002年に開始されたが、2011年に中止・解体された。最終的な支出額は127億ポンド（当時のレートで１兆6,600億円）に膨らんだ。失敗原因として、中央集権的な設計の破綻、ユーザ不在のシステム設計、ベンダーロックインなど複数の問題が指摘されている[1]。
意味が不明瞭な「中央集権的な設計の破綻」について詳しく見ると、データベースの設計方針に関する問題であったことがわかる。中核となる電子カルテのデータモデルであるHL7 v3 RIM（Reference Information Model）は、医療情報をたった5つの抽象概念で統一的に表現しようとした「きわめて野心的だが実装困難なデータモデル」とみなされている。具体的には、Entity（患者・医師・組織・機器など）、Role（患者役割・医師役割・保険者役割など）、Participation（診療行為への関与）、Act（診療行為・検査・処方・予約など）、ActRelationship（行為間の関係）の5個のクラスと、それらに付随する大量のサブタイプで構成されていた。典型的なオブジェクト指向開発におけるクラス構造である。
中止プロジェクトの仕様書が公開されているわけではないのだが、開発言語がオブジェクト指向言語(Java J2EE)であったこと、そして、HL7 v3 RIMを忠実に実装したという説明からわかるように、テーブルの主キーはすべて機械的に付与される識別子(id)であったことがうかがえる。結果的に、実際の医療業務を支援できないだけでなく、現行システムからのデータ移行がほぼ不可能であることがわかった。
この事例から単独主キー主義の問題がわかるのだが、厚生労働省はその修正版であるHL7 FHIRにもとづいて我が国の医療DXを進めることを、2026年に表明している[2]。
それはどんなモデルなのか。既存の業務キー値を取り込めなかったHL7 v3 RIMへの反省から、HL7 FHIRにおいて主キーはそのままで、各テーブルの業務上の識別子を業務ID（identifier）という属性項目として含めるスタイルに変わった。業務IDが複合主キーであることは許しているが、そのユニーク制約はテーブルに組み込まれていない。これは意図的で、業務IDのユニーク性についてはアプリや業務側の管理責任としている。
「いや、それでホントに大丈夫？」と困惑せざるを得ない。ようするに「業務キー値を取り込めなかったので、それを移行先に属性項目として含めた」だけの、旧バージョンから本質的には変わっていない設計方針である。
このやり方の利点として「業務IDの国別多様性や制度変更への対応容易性」と説明されるが、筆者には「業務要件の見落としにともなう改修を容易にするための消極的工夫」、つまり、関数従属性の識別が中途半端であるゆえの逃げにしか聞こえない。しかもそのやり方で改修が楽になるわけではなく、むしろ改修にともなう影響の広がりが見えにくくなる。これを「対応容易性」と言ってはいけない。
そもそも、行政DXが未達の段階で、その上に展開されるはずの医療DXがうまくいくとも思えない。最大の懸念はJavaでゴリゴリ実装するという非効率さなのだが、まあそこは最新のAIでいい感じに合理化します、なんてことになっていなければいいのだが。
[1] ･National Audit Office (NAO). The dismantling of the National Programme for IT in the NHS. 2013.
･Greenhalgh, T. et al. The Devil’s in the Detail: Final report of the independent evaluation of the NPfIT. University College London, 2010.
･Beale, T. What’s wrong with HL7 version 3? openEHR Foundation, 2004.
[2]厚生労働省 令和8（2026）年度 総括研究報告書（FHIR 利活用）
