新しい記事を書く事で広告が消せます。
新しい記事を書く事で広告が消せます。
補助金関係ではクリスマスから年始にかけて一波乱あったみたいだが、電算関連では何ら進展が無い。
そして今厚労省にQAを投げかけても、貝のように「検討中」という言葉しか返ってこない。
時間が無いのになす術が無いという、焦りも出てくるであろう。
幸い、事態を僅かながら打開する資料が手元にある。
「後期高齢者医療広域連合電算処理システム概要(未定稿)」に関する質問・回答、というものだ。
どうやって手に入れたかというと、元旦に初詣に行った際、突然茂みからイノシシが現われて(以下略)。
偶然とはいえ、初詣の際にこんな資料をイノシシが(中略)だったのは、幸運としか言いようが無いが、なにぶんにもイノシシが運んできた資料であるから(以下略)。
中身を見ていくと、各都道府県から寄せられたQAを集約したもののようで、132問までとボリュームたっぷりだ。
いろいろ分かることがあるが、今回は証交付のことに焦点を当ててみたい。
以下、誤字と思われる部分も含めて原文のままの引用である。
なんと、市町村住基システムとの即時連携が考慮されていたとは驚きだ。
Q3 本システム概要11頁3.2.1資格管理業務機能概要(1)資格管理において、「窓口端末より登録した内容にて、即時に、被保険者証の引渡しを行う」旨の記載があり、一方、49頁5.2データ授受周期癸韻瞭時において、「当日の業務終了後に一括送付」と記載されており、どのように即時引渡しを行うのか。
即時に交付する被保険者証の住所や氏名は、その場で窓口端末に入力するのか。
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集だけでも早く横三回(#゚Д゚)ゴルァ!!









COMMENTS