公務員叩きに物申す!-現職公務員の妄言 システム運用保守に、後期高齢者医療制度に、公務員叩き批判に、行政改革に、福祉行政に、ITに、WEB2.0に、SNS管理に、VBに、Scriptに、情報セキュリティに、IPネットワークに、SEOに、ほんの少し家族サービスなブログ。

  • 未定稿走り読み(

  • Top
SEARCH

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト:
 年も明けた。

 補助金関係ではクリスマスから年始にかけて一波乱あったみたいだが、電算関連では何ら進展が無い。
 そして今厚労省にQAを投げかけても、貝のように「検討中」という言葉しか返ってこない。
 時間が無いのになす術が無いという、焦りも出てくるであろう。

 幸い、事態を僅かながら打開する資料が手元にある。

 「後期高齢者医療広域連合電算処理システム概要(未定稿)」に関する質問・回答、というものだ。

 どうやって手に入れたかというと、元旦に初詣に行った際、突然茂みからイノシシが現われて(以下略)。
 偶然とはいえ、初詣の際にこんな資料をイノシシが(中略)だったのは、幸運としか言いようが無いが、なにぶんにもイノシシが運んできた資料であるから(以下略)。

 中身を見ていくと、各都道府県から寄せられたQAを集約したもののようで、132問までとボリュームたっぷりだ。
 いろいろ分かることがあるが、今回は証交付のことに焦点を当ててみたい。

 以下、誤字と思われる部分も含めて原文のままの引用である。


Q3 本システム概要11頁3.2.1資格管理業務機能概要(1)資格管理において、「窓口端末より登録した内容にて、即時に、被保険者証の引渡しを行う」旨の記載があり、一方、49頁5.2データ授受周期№1の日時において、「当日の業務終了後に一括送付」と記載されており、どのように即時引渡しを行うのか。
 即時に交付する被保険者証の住所や氏名は、その場で窓口端末に入力するのか。

A3 標準システムの推奨運用としては日時連携を想定しているため、即時に被保険者証の引渡しを行う場合は、窓口端末で必要項目を入力することを想定している。
 市町村の住基システムと窓口サーバ間のリアルタイム連携を行い、窓口端末での入力処理を簡素化することも可能である。
 この場合は各広域連合において、市町村住基システムとリアルタイム連携を行う仕掛けを独自に構築する必要がある。(異動情報の前後関係の担保などは市町村システムで行う。)
 また、この場合障害時の復旧に方法などについても、市町村と広域連合で対応する必要がある。



Q47 ○○○(都道府県名)広域連合以外から転入した者の資格取得については、負担区分証明書を元に被保険者証を作成すると思う。
 しかし、住民基本台帳情報などは、日時処理による転送になり、即時にデータとして受け渡されないので、プリンタに即時に被保険者証を印字することはどのようにして可能になるのか。
 さらに、即時交付する場合、「受給者番号」の採番は標準システムで管理することができるか。

A47 即時発行については、窓口端末から必要な情報(住基や負担区分等証明書に記された内容などの情報)を画面入力して、その結果を元に負担区分をシステムにて判定し被保険者証を発行することになる。(ただし、広域連合と構成市町村間で異動情報のリアルタイム連携を行う場合はこの限りではない。)
 (中略)
 被保険者番号の採番は標準システムで管理する。



Q70 49頁関連で転入者の資格取得において、住基情報・転入届で確認して証発行とあるが、住基情報は窓口サーバには直接渡せないので、即時発行は無理だと思うが(日次バッチのようだが)、どうかんがえるか。
 また、市町村で窓口端末で入力とは何の情報を指すのか。住基情報を入力するのであれば無理である。生保、転居、氏名変更も同様。

A70 転入時に被保険者証の即時発行が必要な場合は、市町村で、住民異動届を参照し、窓口端末から転入者の住基情報を入力し、被保険者証の即時発行を行うことを想定している。
 入力が不可能であれば、即時発行はせず、異動データの連携後に被保険者証を発行し後日郵送を行う運用となる。


 なんと、市町村住基システムとの即時連携が考慮されていたとは驚きだ。
 だが、ある意味これは厄介である。

 要するに証交付の方法としては以下の3つの方法があることになる。

1.窓口サーバと市町村住基システムを接続して即時連携が行われるようにし、LGWAN等を経由して広域連合側で被保険者番号等の設定を行い、窓口端末で住基情報等を入力することなく即時に被保険者証を交付する。

2.窓口端末で住基情報等必要項目を全て入力し、LGWAN等を経由して広域連合側で被保険者番号等の設定を行い、即時に被保険者証を交付する。

3.日次で窓口サーバからLGWAN等を経由して広域連合側に住基異動データを転送し、バッチ処理にて被保険者証を作成し、後日郵送等で交付を行う。

 同一広域内で、これらの3つの方法が併用できるかどうかは定かではない。
 どれかの方法に広域下全市町村が統一せねばならないということであれば、1は事実上不可能であろう。

 それにしても1~3によって、窓口サーバの重要度は全く異なってくる。
 1ならば窓口サーバの停止は致命的だから、可能な限りクラスタにした方が良いであろう。
 3ならば、窓口サーバは単なるアップローダ、ダウンローダ程度の役目しかないからシングルでも十分である(下手をするとサーバ無しでも可能だと思われる)。冗長性を確保するにしても、クラスタ構成ではなく予備機を用意することで足りるだろう。
 2は即時処理時に窓口サーバが関わるのならば1と同じこと、そうでなければ3と同じである。

 現在、窓口サーバの構成をはじめとした19年度予算の積み上げに腐心されている広域も多いと思うが、
 要するに同一広域内での異手段併用が可能かどうかが確定し、なおかつ1~3のどの方法を選択するかが確定してからでないと、19年度予算は積み上げ出来ないということですな。
 (゚∀゚)アヒャヒャヒャ \(^o^)/市町村予算オワタ

 くどいようだが、記事の利用は自己責任でお願いしたい。
 参考資料の信憑性についても、初詣の際にイノシシが(中略)という事実から、判断していただきたい。



 おまけ。

Q117 スケジュールに関し、平成19年度11月中旬~準備本番稼動(特徴事務・住基連携開始)となっているが、システムの仕様が確定していないのに、このスケジュールで間に合うとお考えか。
 各市町村で準備する保険料徴収システムは、標準システムの仕様が固まらないと進めないと思うが、保険料徴収システムの準備も含めてこのスケジュールで間に合うのか不安である。

A117 スケジュールについては大変厳しいとは思うが、制度施行にあわせて間に合わせる必要がある。
 標準システムの仕様についてもできる限り早期の公開を行っていくことを考えているが、明確になった部分から開発に着手するなど、市町村ならびに広域連合側のご協力をお願いしたい。

 ならこのQA集だけでも早く横三回(#゚Д゚)ゴルァ!!


はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: 標準システム, 被保険者証,
5 インターフェース仕様
6 導入スケジュール
 読むの面倒くさくなったからやめた。

以上。終わり。


はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: LGWAN, 広域連合, QRコード, 被保険者証, 国保中央会,
4.1 システム構成概要
 ずいぶん贅沢な印象を受けるが、システム構成自体はWebシステムに一般的に見られる三層構造(連携→AP→DB)をベースとしている。
 そして、インターネット利用や外部公開用のWebサーバはこの資料に含まれていないため、別途考慮する必要がある。

 なお、※1でにおわせているが、保険者と国保連合会がオンライン接続する「保険者レセプト管理システム」の構想が水面下で動き始めている。二重投資を避ける意味からも、この構想を視野に入れて、ネットワーク構築の要件定義やポリシー調整を行ったほうが良いだろう。

4.2 ハード
 Webシステム三層構造、SAN&ネットワークバックアップ+Ultrium3。聞くだけでも懐が寒くなりそうである。事実、笑えるぐらい金がかかる。
 広域のハード性能が市町村の窓口端末の台数に依存していることから、市町村窓口サーバは中継的な中身がスカスカのサーバであろう。

 で、件の窓口サーバ、シングルかクラスタかは市町村のポリシーに依存という完全責任放棄の書き方である。これでは事務局は困ってしまうだろう。
 ポリシー云々以前に、広域の事務の均一化という政治的な大義名分からすればクラスタ推奨とすべきであるし、負荷分散や費用対効果から大規模市町村=クラスタという観点ならば、その人口目安を書いておくべきだろう。
 余談だが「別添1の隠しページ」にはクラスタを参照しているセル=大規模と書いてある。要するにそういうことなのだろう。(そもそも小規模市町村は窓口サーバが不要な構成も可能ではないか?) 

 保険証については平成22年度にカード化&QRコード刷り込みが義務付けられることが分かっている。当然それを視野にいれたシステム構成にすべきであろう。
 わずか二年間しか使用しない公印印刷専用カラープリンタという発想は馬鹿げている。
 カード化が時期尚早ならば、公印刷り込みの紙に兼用可能なモノクロプリンタで印刷するほうがはるかに良い。

4.3 ソフトウェア
 2.2.2でソフトウェアの仕様については後日ということだが、現時点でどういったソフトウェアを想定しているかは「別添1の隠しページ」を見れば分かる。隠しページの出し方が分からない人は、blog左のメールフォームからこっそり尋ねられたし。

4.4 ネットワーク
 WANの選択(とりわけLGWAN)については余りに大きな問題であり、別の機会に詳しく触れることとしたい。
 オンラインウェイト5秒というのはWebでは珍しくないが、汎用機の操作性に慣れている窓口職員にとっては耐え難い苦痛であろう。
 WANの冗長化という発想はないのであろうか?(窓口サーバをクラスタにしても、ネットワークにトラブルがあれば意味が無いのだが)

4.5 構築作業及び運用保守
 市町村のウィルスパターンファイル更新はどうするの?

4.6 その他の見積項目
 認証サーバが良く分からないが、指認証用サーバのことであろうか?それともドメインコントローラーのことか?
 リモート操作やリモート保守は、LGWAN基本仕様ではできない。だから「リモート保守用ネットワーク回線」(意地悪く言えば「バックドア」)が別途必要なのである。

(続く)


はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: Webシステム, LGWAN, QRコード, 国保連合会, 要求定義,
3.標準システム概要

3.2.1 資格管理業務機能概要
 誰もが思うことであろうが、被保険者証の即時交付をどうやって実現するかが全く見えてこない。
 広域外転入時に交付される証は、仮の証ではない。その証拠に、未定稿7日版ではここに「仮証」の記述があったが、14日版以降ではその記述が消えている。紛れも無い、本物の証ということである。

 「広域連合による資格確認・被保険者証の交付決定をもとに、市町村において、窓口端末より登録した内容にて、即時に、被保険者証の引渡しを行う」

 この記述から見るに「市町村端末のオンラインで広域連合側のサーバにデータを転送し、その処理結果を元に証交付」というような雰囲気である。
 しかし、市町村からの住基や税情報の転送は5.3.1で日時と指定している。

 あるいは窓口サーバにいろいろ重めのアプリやDBがあって、そこでの処理を広域での交付決定と見なし、日時でその結果を広域に集約するのであろうか?
 しかし4.2.4や4.3.2を見る限り、窓口サーバにはDBもテープバックアップも無い。中身はスカスカに見える。

 「窓口端末より登録した内容にて」というのがクセモノだ。まさか職員にオンラインで氏名から住所情報から全て入力させるつもりか?
 住民課で転出証明書と転入届から住基システムにオンラインでポチポチ入力し、その職員がそのまま書類を持って国保課に走っていって別端末で全く同じ情報をポチポチ入力しろというのであろうか?
 それとも住基システムにオンラインで入力し終えた後、住民課職員がフロッピーディスクを持って窓口サーバまで走るのであろうか?

 とにかく不明瞭であり、本当に証交付が実現できるかどうか疑問だ。あるいは実現できたとしても窓口で多大な労力を強いられることになるやもしれない。
 もし貴方の市において、住基システムと老健システムのオンライン連携が取れているのであれば、証の作成は市町村システムで独自に行うことを前提に設計を進めていくほうが良いかもしれない。

 他にもいろいろあるが割愛。取りあえず証を出せないと話にならない。

3.2.2 賦課業務機能概要
3.2.3 収納業務機能概要
 一番不安であるのは収納と賦課の連携部分、特に広域内転居が絡む場合である。収納情報が広域に反映されるタイムラグの間に転居をした場合等、うまく処理されるのかどうか疑問だ。対応できないから市町村同士が考えてシステム組んでくれ、という話にならなければ良いが。
(そもそも賦課と収納を切り離すこと自体にかなり無理があるのだが、いたし方あるまい)

 特別徴収については、現行、介護では年金保険者から受給額は通知されない。どうやって市町村で1/2判定を超過するか否かの判定をするのであろうか?
 今後年金保険者が受給額を市町村に通知するようになるのであろうか? その場合の個人情報の取扱(本人の同意等)は大丈夫なのであろうか? 

3.2.4 給付業務機能概要
 広域内転居で医療機関が旧証で請求した場合、全て返戻処理となるようでは広域化の意味が無い。自動修正されるような仕組みが求められる。
 給付確認については是非、労力が削減できるような仕組みにしていただきたい。(再審査の大半は診療内容ではなく請求内容に問題があるものが大半であり、こんなものは人の手を煩わすまでもなく、ロジカルチェックで全てはじくべきである)
 療養費については、件数が多い都市の事情も勘案し、オンライン入力だけでなくデータインポート(ならびにエラーつぶし)の機能を設けるべきである。とりわけ、制度上はともかく受領委任行為が常態化している柔道整復や鍼灸マッサージの請求書については、直接広域でインポート処理できるような仕組みにした方が効率的であろう。

3.3 業務帳票一覧
 逐一はチェックしていないが、3.3.4の32「老人保健保険者別医療費給付額通知」が目に付いた。
 現行制度では保険者との拠出金の調整に用いる書類であるが、いったい何を想定した帳票なのであろうか?

3.4 外字処理の方式について
 残存外字の報告用インターフェースや同定処理が不明瞭であるから評価できない部分が多いが、統一文字コードへの変換自体は「市町村住基システム→住基ネット」で用いている変換の仕組みをそのまま流用できれば話は早い。
 業者が違う等、プログラム著作権等の問題が絡んでくると厄介だ。
 外字フォントの関係で、端末はWebシステムでありながらも専用端末とせざるを得ない。他システムとの流用には難が生ずる。

(続く)


はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: 広域連合, 被保険者証, 住基ネット, 外字, インターフェース, Webシステム,
 例の「未定稿」がようやく公になった。
 21日の夜間に全国に公開されるや否や、翌日22日に即差替えという混乱ぶりである。
 変更点は住基ネット外字、いわゆる統一文字コードの利用にかかる部分であり、直前まで総務省との調整が難航していた様子が見て取れる(いや、もしかするとまだ調整中かもしれない)

 21日版に統一文字コードの記述が無いことに気づいたときは正直めまいを覚えた。
 失意のうちにその資料を多量コピーしているときに、22日版のメールが転送されて筆者のパソコンに届いたのである。

 ここで、筆者は厚労省の担当者に二言ほど言いたい。

 1.調整お疲れ様。さぞ苦労されたことと推察します。
 2.紙代カエセヨ(・∀・)コラ!! 21日版たくさん印刷しちゃったじゃないか。

 冗談はさておき、ようやくこのblogでも心置きなく言及することができるようになった。
 せっかくなので数回に分けて中身を見ていきたい。



1.本書の位置づけ
 省略

2.前提条件

2.2 システム構成に関する前提条件
 ざっと見た限り、全般的にハイスペックである印象を受けた。平成23年のレセプトオンラインの時期のリプレイスを見込み、それまでの使用に耐えうる内容と見るのが妥当だろう。
 とはいえ、サーバはともかくWebシステムの端末がこれほど高性能である必要はあるのか?やや疑問である。
 (後ほど触れることになるが、端末についてはWebシステムとしながらも専用端末を想定している。Webシステムで端末性能がボトルネックになるというのは考えにくい。文字通りの専用であるならば、さほど高い性能は必要ないのではないか)

 ソフトウェアのベースは、Win2003+Oracle10gである。UNIXでなくて大丈夫なのであろうか?
 他のソフトの細かい仕様は現段階では示されていないが、他ベンダへの牽制としてJP1やコネズミ…じゃなかったコズミネクサスあたりのミドルウェアをねじ込んでくることは容易に想像がつく。「N」や「F」は頭が痛い部分であろう。
 端末のOSはXP。Vistaは見送りである。

 ネットワークについてはLGWAN前提であるが、それ以外の独自回線も可能である。ただし仕様についてはLGWAN前提で記載されているため、見直しが必要になる可能性がある。
 LGWAN+他回線の混在は不可。確かに運用保守面から混在は避けるべきだろう。

 構築、保守、運用については資料に含まれないし、またサーバが占有するスペースについても言及されていない。
 これらは個別に見積や調査等の対応が必要になる。

 なお、概算費用算出表は国保中央会のHPからダウンロードできるが、内容については未定稿と矛盾する部分もある。(市町村窓口サーバのバックアップソフトの有無等)
 まあ、高めに見積もっておけ、ということなのだろうか。

 広域連合サイドのサーバ設置場所であるが、LGWAN利用に大きく影響するので留意されたい。
 広域連合が自前でセキュリティ設備が整ったサーバ室を確保できるのならばともかく、業者のIDCを利用する場合、その業者がLGWAN-ASPサービス提供業者でなければLGWANには接続できない。
 LGWAN-ASPサービス提供業者の一覧については、LASDECのホームページで確認できる。

 そして当たり前であるが、広域連合サイドのセキュリティポリシー策定が必要になる。

 ここで提言したいが、広域連合サイドでの導入にあたってはコンサルをつけることを強く推奨する。
 コンサルにあてる当年度の予算がないのなら、プロポ形式でベンダやインテグレータを選定しても良いだろう。
 ともあれ、事務局職員がシスアド(+情報セキュアド)とテクニカルエンジニアの精鋭集団であるのならばともかく、素人がこの資料だけを元に競争入札の仕様書を起こすのは不可能に近い。

2.3 インターフェース仕様に関する前提条件
 漢字文字については住基ネット統一文字コード、住所については全国住所辞書コード、金融機関情報については全銀協コードである。
 統一文字コードについては、「市町村住基システム→住基ネット」で用いている変換の仕組みをそのまま流用できれば話は早い。とはいえ、個人情報関連の審議会や「偉い人」に、住基ネットとは直接関係無いことを説明するのは骨が折れる作業になるだろう。

 個人番号については、各市町村で一意なのか、広域内で一意なのか不明瞭である。桁数については16桁と十分に見えるが、このうち何桁かが市町村番号的に充てねばならず、実際にはより少ない桁数しか利用できないとなると、各市町村で対応できなくなる可能性がある。

 市町村と広域間のデータ転送については、面倒なポリシー調整がいろいろと必要になるであろう。
 例えば筆者の市のポリシーでは、中から外は比較的甘いが、(特定のプロトコルを除き)外から中は相当厳しい。広域から本市へのデータ転送は全てダメである。
 そのため、中から外へ定期的にデータを取りに行く仕組みを構築する必要がある。(この費用は誰が負担するのか?)
 もちろん、外部からの遠隔監視や遠隔操作も全てダメ。本市に限ってはJP1を導入する意義は全く無い。
(LASDECが定めるLGWANのFWプロトコルも同様の制約があるということを聞いたことがあるが、そこらへんは大丈夫なのであろうか? 筆者の勘違いならば良いのだが…)

 開発を手がける「この木何の木」さんには、そういう自治体もあるということを是非認識しておいていただきたい。

 そうそう、ある都道府県では税業務が電算化されていない自治体もあるとか。
 日時夜間バッチが始まるまでに、その役場の職員がオンラインで税情報をポチポチ入力するのであろうか?
 ここらへんのケアも是非怠らないようにしていただきたいものである。

2.4 カスタマイズ
 カスタマイズ用のDBを用意してやるから、本体はいじくりまわすな、というスタンスである。
 果たして十分な内容と種類のDBが用意されるのか、少々不安である。

(続く)

** 追記 **

12月1日 ミドルウェアの名前が間違っていたので修正しました。(×コズミネクス→○コズミネクサス)

はてなブックマークに追加 はてなブックマークのコメント livedoorクリップに追加 livedoorクリップ数 niftyクリップに追加  del.icio.usに追加  Yahoo!ブックマークに登録 Yahoo!ブックマーク数 googleに追加 

自由利用マーク
このマークは当blogの記事部分に付けられたものです。
タグリスト: 住基ネット, 外字, LGWAN, 国保中央会, 広域連合, セキュリティ, インターフェース,

ナビゲーション

特集記事

カテゴリー

ブログ内検索

RECENT ENTRYS

RECENT COMMENTS

RECENT TRACKBACKS

プロフィール

現職公務員SE Author:現職公務員SE
 シスアドでセキュアドな後期高齢者医療制度SNS管理人。
 後期高齢者医療制度の資格事務担当だったはずがひょんなことで電算担当に。

HSタグクラウド

Feed Me!

公務員叩きに物申す!-現職公務員の妄言のRSSフィード

後期高齢者医療制度開始カウントダウン





リンク

中の人

FC2カウンター


公務員サイトランキング 現職公務員サイトランキング ビジネスブログランキング 人気ブログランキング - 公務員叩きに物申す!-現職公務員の妄言

スカウター : 公務員叩きに物申す!?現職公務員の妄言 はてなブックマークカウンター
  • seo

FC2 Management
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。