厚生労働省メタボ健診システムの不備を会計検査院の公開資料から読み解いてみる

同種の失敗事例を招かないよう、自戒の意味を込めて今回の事例について自分なりに分析・咀嚼するためにまとめてみました。
5
まとめ 日経コンピュータ誌が取り上げた厚労省メタボ検診データベースシステムの不具合と改修をめぐって あまりに面白いお話でしたので、思わずまとめてしまいました。 日経コンピュータDigital 2014年2月20日号記事「約1600万人のメタボ健診データを生かせず 入力時に全角/半角が混在し、突合不能に」 http://itpro.nikkeibp.co.jp/article/NCD/20140212/536175/ スラッシュドットジャパンIT記事「厚労省の診療データベース、データの不備によってつき合わせできず」(2013年11月6日付け) http://it.slashdot.jp/story/13/11/05/0942255/ 42591 pv 402 75 users 243
まとめ 28億円かけたメタボ検診システム、半角/全角の処理ができず、ほとんど使えてないことが判明 データの8割が活用できない状態に…… 13597 pv 138 4 users 6
sk @sk_exe

とりあえず、テーブル設計の段階でちゃんとフリガナフィールドと氏名フィールドを分けていたのかどうかが気になった。「厚生労働省のメタボ検診システム不備は防げなかったのか」 togetter.com/li/870266#c214…

2015-09-08 13:36:18
sk @sk_exe

@sk_exe 厳密には[姓],[名],[姓のフリガナ],[名のフリガナ]に当たるフィールドが定義されていたか否か、か。「厚生労働省のメタボ検診システム不備は防げなかったのか」 togetter.com/li/870266#c214…

2015-09-08 13:57:56
sk @sk_exe

会計監査院のサイトで公開されている資料を読んでみる。 jbaudit.go.jp/pr/kensa/resul…

2015-09-08 14:53:57

誤:「会計監査院」
正:「会計検査院」

sk @sk_exe

引用:『特定健診等データについては、健診等実施機関が「特定健診の電子的なデータ標準様式特定健診情報ファイル仕様説明書」(以下「仕様説明書」という。)に基づき入力することとなっている。』 jbaudit.go.jp/pr/kensa/resul…

2015-09-08 14:57:41
sk @sk_exe

その「特定健診の電子的なデータ標準様式特定健診情報ファイル仕様説明書」とやらがコレらしい。 mhlw.go.jp/bunya/shakaiho…

2015-09-08 14:58:56
sk @sk_exe

引用:『一方、レセプトデータについては、従来、医療機関等が「オンライン又は光ディスク等による請求に係る記録条件仕様」等(以下「記録条件仕様等」という。)に基づき入力しているものである。』 jbaudit.go.jp/pr/kensa/resul…

2015-09-08 14:59:37
sk @sk_exe

その「オンライン又は光ディスク等による請求に係る記録条件仕様」とやらはここ iryohoken.go.jp/shinryohoshu/r… にある「別添1-1」であると思われる。

2015-09-08 15:01:48
sk @sk_exe

まず前者の「仕様説明書」における「受診者情報」のうち、氏名に関する項目は[受診者の氏名]しかなかった。

2015-09-08 15:06:42
sk @sk_exe

引用:『「受診者カナ氏名」に対応する全角カタカナ文字列で空白を含まない。姓と名の間にも空白をあけないこと。最大40バイトmhlw.go.jp/bunya/shakaiho…

2015-09-08 15:07:27
sk @sk_exe

一方、後者の「記録条件仕様等」における「レセプト共通レコード」のうち、氏名に関する項目は[氏名]しかない。

2015-09-08 15:10:02
sk @sk_exe

[氏名]に関しては、モード「英数または漢字」、最大バイト「40」、項目形式「可変」(続く

2015-09-08 15:14:16
sk @sk_exe

記録内容 「1 姓名を記録する。  2 姓と名の間に1文字分の“スペース”を記録する。  3 モード毎の文字数の上限は、次のとおりとする。   英数:40文字   漢字:20文字  4 英数モードと漢字モードの文字を混在して記録しない。」 とある。

2015-09-08 15:16:59
sk @sk_exe

姓と名、氏名とフリガナが分かれていなかった時点で既にお察しであったが、ここまで仕様が違ってたらそりゃ今回みたいなデータ不一致は起こるべくして起こっただろうとしか言いようがない。

2015-09-08 15:21:17
sk @sk_exe

それ以前に「氏名」や「フリガナ」といった要素は、キー項目に向いていないのである。誰も指摘しなかったのか。

2015-09-08 15:23:12

補記(2015/09/10):

「いずれか一方のシステムにおいて、誤った被保険者証記号、被保険者証番号が入力されたままレコードが保存されてしまった」というケースが含まれることを想定するならば、ベリファイ項目に[氏名]や[フリガナ](や[性別]、[生年月日])を含めること自体は悪い方法ではない。

また(今更言うまでもないことだが)、全角/半角、数値項目のゼロ埋め/スペース埋め、ひらがな/カタカナ、和暦/西暦といった形式の差異はプログラムによって修正、統一可能である。

しかし、「カタカナ(フリガナ)」と「漢字(氏名)」の違いについては、本当にどうしようもない。形式というより属性が異なるのである。

特定健診等データ、レセプトデータのどちらか一方のファイル仕様を変更する(もう一方の属性に合わせる)必要があるだろうが、そうホイホイと仕様変更が出来るものなのかどうか定かではないし、恐らく簡単には解決することが出来ない、何らかの事情があるのかも知れない(と推察する)。

sk @sk_exe

あと、被保険者証番号についてはどちらも全角/半角の両方を許容する(但し混在は認めない)ものとしているようだ。

2015-09-08 15:40:26
sk @sk_exe

ただ「全角/半角の混在」の問題は、テーブル設計の段階では重要ではなく、その後のUI設計やバリデーション機能の実装の段階でどうにかしておかなければならなかったと思う。

2015-09-08 15:45:25
sk @sk_exe

最大の疑問は、「仕様説明書」と「記録条件仕様等」を策定したチームはそれぞれ別だったのか否か、そして両者の内容のすり合わせはちゃんと行われたのか、ということかな。

2015-09-08 15:55:40