未定稿走り読み（４）―更に突っ込んで…：公務員叩きに物申す！

2006

1201

５　インターフェース仕様
６　導入スケジュール
　読むの面倒くさくなったからやめた。

以上。終わり。

　いや、文句を言わないでいただきたい。
　これは「走り読み」なのだから。概要とはいえ、精査するには時間がかかるというものである。

　とはいえ、特集記事を謳っているにも関わらず、（１）～（３）程度の内容は、多少電算の心得があるものなら誰でも思いつくことであろう。
　これではさすがに芸が無いので、筆者の手持ち情報から、更に突っ込んで分析したいと思う。

　まず特集記事の（１）で、市町村と広域間のデータ転送について触れた。
　幸い、参考になる資料が手元にある。

　「後期高齢者医療制度に係る広域連合電算処理システム調達仕様書Ver１．０（平成１８年８月４日）」というものだ。

　どうやって手に入れたかというと、マンションの敷地の草むしりをしているときに、地面に埋まっているのを見つけたのである。古めかしい壺に厳重に封をされて埋まっていた。
　偶然とはいえ、こんな資料が自分のマンションの敷地に埋まっているとは、幸運としか言いようが無いが、なにぶんにもマンションの敷地に埋まっていた資料であるから、広域連合電算処理システムの開発に名乗りを上げたベンダ各社が国保中央会から渡された調達仕様書と同一かどうかは定かではない。
　
　さて、この資料の34ページ、「２．６．２　市町村連携」から引用すると、

　市町村と広域連合間の連携は窓口処理サーバと連携サーバを介して行う。窓口処理サーバは各市町村の本所に設置し、連携サーバは各広域連合に設置する。窓口処理サーバと連携サーバの機能としては下記二点を有する。
　一つ目は市町村から提供される広域連合電算処理システムに必要な住基、税務所得、収納システムからのデータを受け取り、LGWANを介して広域連合へ送信する機能であり、同時に広域連合電算処理システムからＬGWANを介して送信されてくる資格、保険料賦課データ等を市町村システムに提供する機能も有する。市町村システムヘのデータ授受方法はオンラインだけではなく、媒体での授受も考えられる。データ授受は日次での処理を想定している為、SOAP機能を使用した手作業連携方式を想定している。
　二つ目は市町村（本所）、支所出張所に設置されている窓口端末からの広域連合電算処理システムヘのアクセス要求を受付け、各種申請、照会、発行業務を行う機能である。また、窓口業務は即時性を必要とする為、連携サーバにWeb機能を持たせたブラウザ連携方式を想定している。
　尚、市町村との連携はLGWAN-ASPサービスを利用し、窓口処理サーバと連携サーバの「文書取得機能」、「文書配信機能」によって行う。

　要するに、使用するプロトコルは、一方通行でアプリケーションサーバの利用に用いる、ポート番号の小さい「アレ」である。
　市町村は文書配信機能により文書データとして広域連合に住基、
所得、収納情報を送信する。
　広域から市町村への資格、賦課、給付等情報については、文書取得機能によって市町村側から文書取得要求を出し、その空きっぱなしのポートからデータを引き入れるのである。
　サーバのヴァージョンアップモジュール等も同様な方法でのやり取りするのであろう。

　即ち、これらのデータ転送は「自動連携」ではなく人手が必要なオペレーションが発生するということである。
　しかも日次だから、毎日である。
　（なんと、オペレータを雇う予算も必要だ！）
　どうせオペレーション工数が発生するなら、住基や税のシステムと窓口サーバを接続する意味は余り無いのかもしれない。

　とりあえずこの方法がそのまま採用されるのなら、筆者の市のポリシーもクリアできるかもしれない。
　もちろんこの接続方法では依然、広域側からの遠隔操作や遠隔監視については困難である。

　もう一つの重大なトピックは、特集記事の（２）で取り上げた、証の即時交付の仕組みであろう。
　幸い、参考になる資料がもう一つ手元にある。

　「第２回高齢者医療実務研究会資料」というものだ。

　どうやって手に入れたかというと、マンションのベランダにこの資料をくわえた野良猫が侵入しているのを発見し、とっ捕まえて奪い取ったのである。まるまる太った茶と白のぶち猫で、おかげで筆者は３か所も引っかき傷を負ってしまった。
　偶然とはいえ、こんな資料をくわえた野良猫が自分のマンションのベランダに侵入してくるとは、幸運としか言いようが無いが、なにぶんにも野良猫がくわえていた資料であるから、平成18年10月31日の国保中央会での会議で委員に配布された資料と同一かどうかは定かではない。

　さて、「資料５　被保険者証の交付に係る事務分担について」から引用すると、

２　基本的な事務の流れ
（１）交付申請、各種届出の受付 [市町村]
（２）広域連合への申請書、届出書の送付 [市町村]
（３）資格確認と交付決定 [広域連合]
（４）被保険者台帳等への記載 [広域連合]
（５）被保険者証、交付通知書の打ち出し [市町村]
…（中略）…
※転入時等に市町村で証の即時引渡しができるよう、（３）（交付決定）、（４）（台帳等への記載）を市町村に設置された広域連合の端末で行えるようにシステムを構築する。

　（３）（４）を即時で行うのは端末という書き方である。
　とはいえ、Webシステムの端末には何もないから、実際にはブラウザを通して広域連合側のAPサーバで何らかの即時処理を行い、直ちにDBを更新するということであろう。

　敷地に埋まっていた前述の資料にも参考になる記述がある。
　36ページの「１．１．１　資格管理－資格管理－資格取得（広域外）」だ。

　このフロー図によれば、住基情報の転送はあくまで日時であり、即時に情報を交換するわけではない。
　申請情報を広域に送信し、広域側で証番号の採番のみ行って、証を即時に交付する仕組みである。

　この仕様の段階では「仮証」という記載がある。恐らく住所も何もなく保険者番号や記号番号、負担割合等、必要最低限の情報が搭載された証を交付し、後日広域で正式な証を作成、市町村にて交付ということを想定しているのであろう。
　その仮証が現在の仕様では正式な証になっているわけだが、
　もし大きな仕様変更を伴わないとすれば、市町村にて広域システムの窓口端末から申請情報として氏名や住所情報等を手で入力し、あくまで正式な証として交付する。その後、日時処理等で広域のDBが更新され、その際に不整合があれば後日証の差替を行う。
　この形が恐らく一番近いのではなかろうか。

　結局、住民課の職員が住基に入力した後、国保課まで書類を持って走ってもう一度入力しろ、ということのようだ。
　なお、採番を広域で一元管理する仕様であれば、特集記事の（２）で触れた市町村システム側での証交付対応は困難ということになる。

　では、広域内の住所異動の場合はどうであろうか。

　敷地に埋まっていた資料の56ページ「１．１．７　資格管理－資格管理－資格取得（資格変更等）」を参照する限り、
　広域外転入との相違は、負担区分証明書に基づく入力がないとううことと、広域側での証番号採番を行わないということである。
　住所と市町村番号（もしあれば）のみ変更され、証は再度交付されるということなのであろう。

　猫がくわえていた方の「資料２　被保険者証の番号」では、証の番号形態について幾つかの案が出されているが、支持されている案はいずれも広域連合単位で一意となる番号を保持し続けるものである。

　こういった形であれば、医療機関からの広域内旧証によるレセプト請求への修正対応も可能であろう。
　ただし埋まってた資料の193ページ「４．１．２　給付管理業務－レセプト資格確認－日次確認処理」ならびに195ページ「４．１．３　給付管理業務－レセプト資格確認－月次確認処理」では、エラーフラグを立てての手修正を想定している。
　これはそれなりの作業量になるだろう。
　QRコードでの請求が実現できれば、医療機関での入力ミスはほぼ無くなるわけであるから、システムによる自動修正も視野に入れるべきではなかろうか。

　そして広域内住所異動にかかる賦課や収納の処理については依然不明瞭のままである。

　さて、未定稿の分析としてはここまでにしたい。12月4日は目前に迫っているし、そのときに明らかになることも数多くあるだろう。

　くどいようだが、記事の利用は自己責任でお願いしたい。
　参考資料の信憑性についても、敷地に埋まっていたということや、野良猫がくわえていたという事実から、判断していただきたい。

＊＊　追記　＊＊　

12月1日　筆者勘違いによる利用プロトコルの記述を修正しました。