  |
はてなキーワード: バッチ処理とは
マイナンバー保険証の期日も迫ってきたところで、医療事務ちょっとだけわかる増田が保険請求についてつらつら書いてみる。
病院にかかると患者は一部の負担金だけを払い、残りは保険から病院に直接支払われる。
というのが皆さんご存じの保険医療で、どこの病院でもそんなものと思っているけど、実は保険医療は登録された医療機関で登録された医師・歯科医師・薬剤師によってしか行うことができない。
登録なので、登録自体は比較的簡単に行うことができるが、逆に言うと登録抹消も医師免許取り消しなんかに比べ簡単に行われる。
国民皆保険の体制下で医師が登録抹消されれば、もうまともな病院で働くことは出来ないし、医療機関が登録抹消されれば、もう廃業しかない。
やばい医師があちこちの病院で不正を行うことと、やばい医療機関が医師を使い捨てにして不正を行うことの両方に網がかけられているわけだ。
保険医療機関が診療した費用のうち、患者の自費負担分を除いて保険者（保険会社の公的なやつ）に請求する。この請求をレセプトという。
このレセプトを処理するコンピューターを略してレセコンである。
医療事務が入力する端末に対してサーバー、保険者のサーバーに対してクライアント。日々入力されたものを月一のバッチ処理で保険者へ送る。
保険医療制度は膨大で複雑である。使える薬だけでも1万5千種以上、それぞれに使える病気・処方できる量・価格が決まっている。当然検査や手術などもそうだ。費用負担の割合は一定ではなく、老人・結核・難病など負担割合が変わり、乳幼児・一人親家庭など自治体によって補助が変わるものもある。これらは定期的に更新される。
また、病院の会計待ちでイライラした人もいるかもしれないが、これらは可能な限り速く正確に入力されなければならない。病院ごとに採用医薬品は異なり（大規模病院で1000種ぐらい）ショートカット、記号割り当て、約束処方、Do処方などカスタマイズの限りを尽くすことになる。ベテランと新人の医療事務で100倍くらい（は言い過ぎか）処理速度が変わる。ITにつよいはてなー諸氏はもうワクワクしてきたのではないか。
レセコンの歴史は古い。古くは1970年代初頭から導入が始まったと言われ、増田が入職した2000年初頭には、Cobolを使うサーバーで巨大な磁気保存装置がぶんぶん回り懐かしい穴あき用紙を使う高速プリンターが毎月段ボール何箱ものレセプト（保管用）を吐き出していた。大規模な医療機関ほど人件費から導入の圧力は強く、保険請求周りの電子化の進展はかなり速かった（一方、零細診療所は設備投資が重く今だ紙である）。
保険の請求はだいたい3ヶ月くらいで支払われるが、支払われないこともある。これこれの理由で支払えません、と戻ってくるそのことを返戻（へんれい）という。
不正請求600万件！！とか盛り上がってるその600万件は返戻のことである。なお、この不正は、違法を意味するのではなく、コンピューター用語で使われる不整合くらいの意味である。
内訳は圧倒的に保険番号の間違いが多い。なぜかというと世の中には種々の都合で保険が変わる人がいるが、病気は手続きを待ってくれないので、前の保険証で病院にかかることになるからだ。結果として、そんな加入者いないよという返戻が来るので、患者さんに新しい保険証を確認して請求しなおすことになる。マイナ保険証でこの手間がなくなるのだが、正直なところ、毎月の定型事務作業なので大した手間ではないのに対し、マイナ保険証周りの患者対応は相手が人間なのでそれなりの手間である。読み取り機など設備投資も、前述のレセコンとは全く別建ての話となる。患者対応からの残業や種々のコストで病院の経営は悪化し、それを救済するためにあちこちの数字をいじって、まわりまわって医療費増ということになりかねない。
閑話休題、医師の権限は強いので、医療上必要となれば何でもできる。電カルがエラー吐こうが無視すれば何でもできる。結果として返戻をもらう。
病院が原因の返戻というのはとても痛い。本屋で万引き一件の損害を取り戻すためには大量に売らないといけないのと同じで、利益率が極薄の病院で返戻を食らうと経営に大きなダメージがある。
病院長は毎月青筋を立てながら返戻率とにらめっこして、やらかした医師をシバキ上げることになる。
湿布の出し過ぎなどなら実際には金額的に大したことはないのだが、最近怖いのは抗体医薬品など超高価な抗がん剤だ。超高価だから保険でも使用できるがんの種類は厳格に制限されている。しかし、ほかに手立てがなくて小さな子供が「ママ死なないで」って縋り付いてたりして… それで一線を越えてしまい、その上効いてしまい「先生は命の恩人です」みたいになってしまったら… 病院の存続にかかわることになる。
集団指導は、毎年行われるもので、制度の新設や変更の説明や、返戻となりやすいものの注意など、運転免許の更新講習をイメージしていただくとそんな感じである。
個別指導が当たるのは、新設された病院、大規模病院、しばらく当たってない病院、それと怪しいことをした病院である。
個別指導に当たると、ある一定期間のカルテなど全資料を持って出頭するように命じられる。そのうえで、保険者があらかじめリストアップしてきた怪しい処方について片っ端から問い詰められることになる。
この時の基準は明確なものだけではなく、医療の進展により諸説出てきたものや、場合によっては指導員（偉い医師）の個人的な判断にもよる。
指摘を受けたものに対し、カルテなどを示し、医療的に必要なものであったことをその場で即答しなければいけない。奇跡が起きれば、問題なしということで支払いされる。だいたいは、医療的に間違いとまでは言えないけれど、保険診療の枠内ではないと言われて返戻となる（大ダメージ）。舐めた対応をとると、最悪保険医療機関登録取り消しで廃業である（即死）。
個別指導に当たると、事務長が禿げあがるとか入院するとか言われる極めてストレスフルな行事である。
そのため、普通の病院は患者によるものも含め不正に対して見た目よりかなり敏感である（片言の外国人が日本人の保険証を出したりしたら即通報）。
クリックデータの集計において、毎回全データに対して集計SQLを実行すると時間がかかりすぎ、一方でバッチ処理で集計結果を保存すると、その後に発生したクリックをリアルタイムで反映できないという問題があります。この課題を解決するためには、以下の方法を検討すると効果的です。
---
---
---
### **3. データウェアハウスとマテリアライズドビューの利用**
---
---
### **5. キャッシュとインメモリデータグリッドの使用**
---
---
---
---
### **まとめと提案**
---
1. **要件の明確化**: リアルタイム性の程度、データ量、システムリソースなどを考慮して要件を定めます。
2. **プロトタイプの構築**: 小規模なデータでインクリメンタル集計やストリーミング処理のプロトタイプを作成し、性能を評価します。
3. **システムの実装**: 選定した方法とツールを用いて、実際のシステムを構築します。
4. **モニタリングと最適化**: システムのパフォーマンスをモニタリングし、必要に応じて最適化やスケールアップを行います。
---
---
ご質問の課題に対して、リアルタイム性とパフォーマンスを両立する方法として、インクリメンタル集計やストリーミング処理の導入を強くお勧めします。これにより、新しいクリックデータを即座に集計結果に反映しつつ、全データに対する集計処理の負荷を大幅に削減できます。
ここ１週間Cloudflare Workersを触ってるぞ。
とは言っても無料分でもめちゃ早くて快適だぞ。Cloudflare上の管理画面も軽いし好きになっちゃったぞ。
でも無料分だと1リクエスト10ミリ秒のCPU時間しか使えないのがちょっとね…。
Cron Triggerで定期実行できるのも10ms制限だから悲しい。
まぁDBからデータ取ってくるとかの時間はカウントされないから7ms以下で済んでるけどね。
バッチ処理的なあれが必要になったときはGitHub ActionsでCloudflareのREST API経由でやるのがお金がかからなくて良さそう。
あれってパブリックリポジトリだと無料でなんぼでも使えちゃうんだよね。（もちろんビットコイン掘削とかは駄目だろうけど。）スゴいね。
ChatGPTも無料だし、世の中のどえらいサービスがたくさん無料で良いね。
このまま何もかもが無料になれば良いのに。
いい区切りだったので乱文になるけど吐き出させてほしい
8年ほど前、まだ20代後半だった自分が今の会社に中途採用された際に同時入社の同期が１人いた
自分とは歳の離れた40代後半であった同期である彼こそが後に、時限爆弾を仕掛ける人物である
入社した会社はその時期に基幹システムの刷新を考えていたらしく
その募集でシステム部として採用されたのが自分とその同期であった
当時のシステム部の社員は2名体制で1人が60代で定年間近の上司A、もう一人は50代の上司B
2人でなんとか基幹システムの維持だけを行っている状態であった
会社としては基幹システムの刷新以外にも社員の世代交代を徐々に行っていくための採用だったと入社直後に言われた記憶がある
60代の上司A、50代の上司B、40代の同期、そして20代の自分
確かにそのまま行けば年齢層は順調に推移して、10年単位で20代を採用することを繰り返せばいい感じにも思えた
入社してからの仕事としては60代上司Aの定年退職が控えているため、まずは稼働中の基幹システムの仕様理解に日々の業務の引継ぎ
そんな多忙な業務をこなすなか同期と話すうちに彼の人柄が徐々にわかってきた
箇条書きでまとめるとこんな感じだったと思う
・今の会社に採用される前、同じような職を転々として現在8社目であること
・受託システム開発ばかりやっていたが、そろそろゆっくり仕事ができる社内SEでまったり過ごしたいこと
・年齢と経歴の割にプログラムが雑なこと（※これは自分視点だがそう的外れではないと思う
また、今の会社に対してのスタンスや不満が溜まってきていることも伝わってきた
・システムを作る自分たちのチームが上で、運用するチームを下だと見下していること
・その運用チームから稼働テストの際にミスを指摘されると不機嫌になること
中々怪しい気配が漂ってきたと当時の自分は思った
残業に関しては、毎日という程ではないが20時頃までは働いていたと思う、遅くても21時までだったはずだ
ただこれはシステムの刷新が終わるまでという明確なゴールがあったのでそれまでは申し訳ないが対応してほしいと事前に説明があったし残業代もきっちり出ていた
自分は前職が完全にブラックで終電帰り、残業代なしが当たり前という環境もあったため特に問題なく仕事ができていたが同期はかなりストレスだったようだ
給料については会社の方針として勤続給ではなく年齢給であったため同時入社であるものの同期は自分よりかなり貰っていたはずであるが、それでも不満だったようだ
トラブルといってもただ上司Bが打ち合わせ中の同期の態度について不真面目だと切れて説教したのだ
この上司Bと同期の彼は相性が悪いようで度々小さな衝突はあったが上司Bが声を荒げて説教するのは始めてのことであった。
しかしこのことがきっかけで上司Bは同期に対して我慢がきかなくなったのかこの後もおよそ2ヶ月に1度のペースで業務のミスといったことから朝に挨拶をしなかったといった細かいことまで説教は続いた
この状態に嫌気が差した同期はある時を境にプライベートの予定があるからと基本残業はしなくなった
たまにどうしても必要がある際は業務命令という形で残業を依頼していたが、それでも19時くらいまでであった
しかし同期はそれもかなり不満だったらしく
残業した日は会社の最寄り駅と会社の間にあるビジネスホテルに泊まり
翌朝、ホテルの前を出勤中の社長や役員の前を偶然を装ってチェックアウトして遭遇し上司Bが無茶な残業を強要するせいでホテルに泊まる羽目になったとアピールするということもあったという
そのため、ちょくちょくシステム部にたいして過度な残業に関する指導が入っていたと後に上司Aから聞いたことがある
そして入社からおよそ3年が過ぎ、なんとか新システムも完成に近づいた時
しかしこの時は同期も相当機嫌が悪かったのか、それとも今まで積もり積もったストレスが限界だったのか、もしくは両方か分からないが
上司Bも同期もお互いに売り言葉に買い言葉で収集が付かず、上司Bが一旦頭を冷やすといって席を離れた際に同期はPCを少しいじると私物をまとめ無断で早退として帰っていった
なおこの時、上司Aは有給で休み、自分は電話応対中であったため止める者がおらず気がついたら終わっていたといっていいスピード感だった
そして同期は翌日、人事部に退職すると電話するとその後出社することはなかった
新システムの作成中データを取り出すために起動したがそれ以降はそのまま一度も起動することなく放置という状態であった
上司Bは撤去したい様子ではあったが、ある役員から戻って来るかもしれないからとりあえずそのままにしておくようにと指示があったので触れることもしなかった
その後、同期の担当分を自分が引継ぎ新システムの作成にとりかかるが彼の担当していた機能はなんとなく察してはいたが、かなり雑な作りな上
運用部門の要望をまったく聞かなかったため、とてもリリースできる状態でないことが発覚
改めて要望に沿った形で修正をする方針で進めると彼が作成したコードで残った部分は30％も残らなかった、ほとんど作り直しと言っていいレベルだ
そのときには定年から雇用延長となっていた上司Aは区切りがついたと退職
会社の業績もあまり安定しない時期でもあったため追加人員の採用は見送られシステム部は上司Bと自分の2名体制となった
その際に新システム作成が評価されたのと2名体制で苦労をかける事情からか自分は課長に昇進した、4年目のことである
新システムはその後、小さなトラブルはあるものの順調に稼働を続ける
なお小さなトラブルの大半は同期の彼が作った部分が関わっていることが多く
その度に彼が作ったコードは修正され、今では機能の殆どに彼のコードは残っていない
残っているのはせいぜい彼が名付けた関数名や変数名くらいである、中身はもう別物だ
そして6年目のある日、上司Bが突然亡くなった
腹痛を訴え病院へ、で即入院してそのまま復帰することなくという形だ
癌だったらしい
その時の会社の上層部はかなり大慌てであったらしいがシステム部としては正直あまり変わりがなかった
というのも新システムを作る際に運用部門の要望をほぼ取り込んだ結果
システム部の基幹システムに関する仕事はほとんどなくなったといっていいレベルとなったのだ
しかし周りはそうは思っていないらしく、システム部は1人しかいないのだから極力負担をかけないようにと各部門には通達がいったらしい
しかし実態はあれだけ忙しく残業していた日々が嘘のように毎日定時で帰っても問題ないのだ
同期の彼が望んでいたゆっくり仕事ができる環境がここに完成していた
そんな中、同期のPCを残しておくよう指示を出した役員も退職する時期となり
そこで改めてPCを起動して中をいろいろ確認していったのだが、そこであることに気づく
起動回数は1回限りで未実行、起動予定はかなり過去の日付が指定されており、とっくにその日付は過ぎていた
バッチ処理の内容を詳しく見てみるとPCの全ドライブの消去コマンドが書かれていた
同期の嫌がらせだったらしい
起動予定の日付を良く確認すると彼が退職を連絡した日の翌月が指定されていた
しかし実際は彼が退職した翌日以来、PCを起動した事はないしバッチも動作していない
※今回は不発だったから良いけど実際にやると損賠賠償になるから
このことは報告していないが、業務でバッチ処理に関わる度に同期のことを思い出す
もし彼が残っていたら昇進したのは自分ではなく同期となり、彼の言う満足いく給料を貰えたかもしれない
もし彼が残っていたら上司Bがいなくなりストレスがない職場で彼は働けたかもしれない
もし彼が残っていたら運用部門からの要請はなくなり、残業とは無縁な仕事が出来たかもしれない
いや最後のは無理かな
作ってたコード雑だったし、人の話聞かなかったし
ふと彼のその後が気になって調べてみたことがある
世間話で同期がSNSをやっていると聞いたことがあり検索してみたのだ
アカウントは知らなかったが彼の話していた世間話の内容で検索してみると意外なほど簡単に見つけることができた、アイコンも自身の顔写真にしており間違いないと思われた
また次（の次？）の職場で残業がらみのトラブルを起こした愚痴が書いてあった
うちの会社を退職したときの事は何を書いていたのか過去の在職期間の投稿を見てみると大半は案の定愚痴の羅列が並んでいた
そして、その連続した投稿の中で退職直後の時期に面白い投稿があった
要約するならこうだろうか
社内システム作っている自分に無茶ぶりばかり、データ全部消去して退職してやった
直してくれと謝罪の連絡してももう遅い、既に新しいホワイトな職場でまったり仕事中です
彼の中でうちの会社は有用スキルを持った人間を無能と決めつけ追放したギルドのように写っていたらしい
しかし実際はデータ削除の時限爆弾は不発であったし、仮に成功していても
現在彼の書いたコードはほぼ残っていないから直してくれと依頼することもない
そして彼の新しい職場は現在のSNSの投稿を見るに彼基準ではホワイトな職場ではないと自白をしている始末だ
ところで実際彼に連絡した人がいたのかという話だが
上司Bは既に亡くなっているので分からないが、おそらく連絡はとらなかっただろう
彼が退職の連絡をしてきた後、残っていた有給を消化したくらいのタイミング（大体1か月後）で退職に伴う書類の送付先の確認で何度か電話をしたが繋がることはなかったという
どうやら彼はこの連絡を会社からの謝罪の連絡だと思っていたのかもしれない
無限のリソースがあるならともかくデータ検証に実行リソースを払いたくないバッチ処理もたくさんあるからなあ
ランタイムサイズやフットプリントのことも1㍉も考えてなさそうだし
cronでなく…という文脈的に複数のサーバーのバッチ処理を一元管理するJP1とかJenkinsとかRundeckとかそういうメジャーなやつを想像したんだけど、君は何ていう製品を想像したの？
そういえばインフラエンジニアやってた頃Hinemosっていうのが話題になったけどその後とんと話を聞かないな。データのプロジェクトだと使うのかな
別に高級なスクリプト言語でも標準ライブラリやインタプリタのバグは踏むときは踏むし
マイクロタスクな標準コマンドは高級言語のインタプリタほど頻繁なセキュリティアップデートは必要ないので使うバージョンはだいたい決まってるし
「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンドと高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし
バッチ処理は大抵2,3の条件分岐と数行のコマンドでできているので検証も難しくはありません
を書いてはや1年。生成AIの進歩によって凄いことになった。早々に使うのをやめてしまったStable diffusionでもface swapが簡単にできるようになった。その上、この1年でNVIDIAはドライバ更新やTensorRTによりStable diffusionを劇的に高速化した。さらに、先日リリースされたReActor extensionがやばい。その結果、とんでもなく自炊が捗ることとなった。
次の処理をスクリプト化した。
去年の手法よりも生成にやや時間がかかるものの、クオリティが比べるまでもなく高いので許容できる。当然ながら実用性の高い動画はできなかったし、生成した動画はすべて抹消したが、本当に捗っている。
来年はどうなっているんだろうか。
会社のみんなが少しでも効率的な業務を遂行できるよう、平日も土日もPythonやJavaやエクセルマクロやローコードアプリやノーコードアプリ等々を勉強しまくって、ITやDXを一つでも多く実現すべく努力してきました。
組んだシステムに不具合が起きて会社のみんなの業務が滞らないよう、日中緊張感をもって対応してきました。
いっつもパソコン睨みつけて、誰とも話してない。
休暇開始の前日、すべてのバッチ処理を停止させました。
発注状況システムや納期遅延情報システム、取引先買入情報システムや経営財務状況システム等等々、全部全部、全部止めました。
今、スマホを見てみたら会社から60件ほどの着信がありました。
空気には手なんかありませんよね？
あってもなくてもよくわからないものの例えとして「空気」などと言います。
では、空気がなかったらどうなるのか、やってみればいい。
生きていけるのか。
死んでしまうのか。
やってみればいい。
空気がなくて、テメェらは生きていけるのか。
やってみろ。
ICOCA周りのWeb系にしても他のいろんなところでITシステムがひどい
会計とか資産管理のITシステムがDBを直接編集するようなUIになってた
資産登録しようとしたらカラムを全部手打ちで埋めないとダメ、みたいな感じ
おまけにDBの制約条件をチェックしてくれない上にバッチ処理なので
実際に投入してみて次の日に「エラーで登録できませんでした」って返ってくるとか
ユーザーに提供してるようなシステムでも使いにくいの多いよね スシローとかまさにそれ
たまに良く出来てる奴があるんだけど大体が東日本、というか東京側の会社のプロダクト
西日本側の開発でもコンサルが入ってるものはそれなりにちゃんとしてるんだけど
自社開発とか子会社開発のプロダクトは、「学生の卒業研究か？」っていうぐらいヒドイ
スマホのアプリで出来が悪いアプリあったら会社調べて見ると大体が西日本だよ（というか大阪近辺）
JRとかNTTとかITシステムに苦手な会社の西日本側の支社になると輪をかけて酷くなる
もともとモバイルSUICAのアプリもヒドイ出来だったよね（最近はそうでもないが）
総務部長の甥っ子の大学の後輩を縁故採用、というルートで正社員の事務職をしている男性が社内にいる。
社内で派遣で事務をしているのは全員女性。彼女たちは家族のせいでパフォーマンスを制限されているが、
子供を産む前は正社員として働いていた人たちで、能力的には優秀。
派遣労働という待遇であっても1枠に対して40名50名の応募があるので、上澄みを採用できる。
有名企業の事務職枠であればもっと激戦であろうと思う。勝ち残るのは優秀な女性ということになる。
事務職に対して男性の応募は少ない。また、女性と比べて男性で事務職を希望する人はやる気がない。
同じ作業はバッチ処理できるようになってきているので、今の事務職は「気づくこと」が求められる。
営業には不注意な人間がやけに多い。気づくこと、おせっかいをやくこと、みたいなスキルが事務職に求められたりする。
性格的な適性みたいなもので、このスキルは資格や経験で明確に示すことができない。
向いている人は向いてるし、できない人はできない。コミュニケーション能力が低いタイプはたいていできない。
正直なところ、遺伝や、きょうだいの世話をした経験、部活の後輩の世話をした経験など、
男性の事務職希望者はコミュニケーション能力が低い。
縁故採用の男性社員はコミュニケーション能力が高く、フットワークが軽いタイプだが。
男性の事務職希望者は、コミュニケーション能力が低いため営業などの仕事には就けず、
理系的素質もないので開発職にも就けず、事務職に求められる「気づき」「おせっかい」といったソフトスキルもない。
「営利団体では使い道がない感じの男性」が、事務職という仕事を小馬鹿にした雰囲気を醸し出しながら、
事務職希望で応募してくる。そして応募してくる人数自体も少ない。
当然、採用されるのは「子供のせいでパフォーマンス制限されてるけど本来は優秀な女性」になる。
それを男性差別といわれても。言葉を正確にして、「能力差別」と言ってくれ。
事務職に向いている男性は、事務職に応募してこない人々の中にいる。
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 1558 | 25歳で年商40億円の株式会社アルゴリズム、事業実体はサイト貸しを活用したアフィリエイター集団か。過激化するSEOハックの実態に迫った。 | suan.tokyo |
| 1252 | 収納の基本講座｜DAIKEN－大建工業 | www.daiken.jp |
| 1234 | 人事制度ハンドブック - kaneda blog | kaneda3.com |
| 1086 | クマが上から飛んでくる衝撃動画「登山中に熊に襲われた」 現場の真相を取材 ｜ PEAKS, 関東 | funq.jp |
| 1045 | バッチ処理 プラクティス | www.yamarkz.com |
| 987 | 月5ドルの自作サービスで最初の500人を集めるまでにやったこと | blog.craftz.dog |
| 874 | 映画『Winny』｜公式サイト | winny-movie.com |
| 855 | 三井住友カードからの脱出先の検討メモ - 職業プログラマの休日出勤 | tmotooka.hatenablog.jp |
| 853 | [PDF] 雑踏警備の手引き | www.police.pref.hyogo.lg.jp |
| 768 | 懸垂のできる公園リスト（場所別） | kensui-to-watashi.com |
| 709 | 人気スパイスカレー店「魯珈」のレシピを大公開！ 「豚スペアリブの薬膳赤カレー」の作り方 ｜ 360LiFE [サンロクマル] | 360life.shinyusha.co.jp |
| 690 | 三浦瑠麗氏、山上容疑者母の高額献金に「競馬でスったって同じじゃないですか」 | asagei.biz |
| 679 | プロトコルスタックを写経してネットワークを完全に理解したかった日記 | sititou70.github.io |
| 600 | 乗換案内1872 - ジョルダン | www.jorudan.co.jp |
| 582 | Twitterを4ヶ月凍結されて、弁護士に依頼して凍結解除してもらった話 - gecko655のブログ | gecko655.hatenablog.com |
| 575 | 画像生成AIによって生成されたイラストの見分け方 | blog.oimo.io |
| 502 | LINE Seed | seed.line.me |
| 472 | エキサイト翻訳終了のお知らせ ｜ エキサイト翻訳・オフィシャルブログ | blog.excite.co.jp |
| 468 | NURO光ネットワークに関する調査結果のご報告および今後の取り組みについて 2022年10月12日 ソニーネットワークコミュニケーションズ株式会社 | www.nuro.jp |
| 457 | 32歳、新しい技術を習得する余裕がなく昔取った杵柄でいつまで食えるか不安です - star__hoshi's diary | starhoshi.hatenablog.com |
| 446 | 「設計」で大事なのはこれだった！半年間で40本レビューして分かった 5つのポイント - Link and Motivation Developers' Blog | link-and-motivation.hatenablog.com |
| 438 | ナナイ・ミゲルからシャア・アズナブルへの質問と確認と安堵と絶望 ＜映画『機動戦士ガンダム 逆襲のシャア』でのすれちがい宇宙＞ | highlandview.blog.fc2.com |
| 434 | 機動戦士ガンダム 水星の魔女 公式サイト | g-witch.net |
| 434 | リモートワークによる孤立から結束へと向かうチームビルディング | research.sakura.ad.jp |
| 403 | 『ソフトウェアアーキテクチャ・ハードパーツ』 - Don't Repeat Yourself | blog-dry.com |
| 395 | 美しい姉弟 - 堤翔 / 美しい姉弟 ｜ くらげバンチ | kuragebunch.com |
| 382 | 「副業300万円問題」大幅修正へ 通常の70倍の反対意見が殺到：朝日新聞デジタル | digital.asahi.com |
| 381 | Envader ｜ インフラエンジニアを目指すための学習サイト | envader.plus |
| 366 | 井伊商店さんの麦味噌が味噌と名乗れない問題についてちょっと解説 - 醤油手帖 | shouyutechou.hatenablog.com |
| 364 | 推し推しうるせぇな、ちょっと黙っとけよ - 夢中で君に恋してる | muchudekoishiteru.hatenablog.com |
薬局に勤めるしがないおっさんだけど、マイナンバー化のメリットが全く見えないんだけど、教えてもらえるだろうか。
これに関してわかる唯一のメリットかな。
保険の請求というのは、いまでも窓口でレセコン（たぶんレセプト処理用コンピュータみたいなもの）に打ち込むと患者さん用の請求書が出てくるほかに保険者に請求する用のデータが作成されて月一のバッチ処理で専用回線でレセプト（請求書）データが送られ、３か月ぐらいすると保険からお金が振り込まれるようになっている。ここで、このレセプトの分は払えないよ、と差し戻されるのが「返戻」。なかには湿布たくさん出して普段使いするみたいな不正請求がはねられる（病気に対して使っていい薬とその量はきっちり決まっていて、怪しまれると個別指導が来る）というのもあるけど、あるあるなのが、そんな加入者いない、という保険番号の誤り。世の中には夏は農業で国保、冬は建設会社で社保みたいな人が結構いて、頻繁に保険を切り替えるため間違って古い保険証をもってきてしまったりする。そこで、患者さんに確認して正しい保険番号をゲットして請求しなおすというのがあるけど、正直、大した量の事務ではない。
で、すでにレセコンあるのに、それとは別回線用意して、別PC用意して、特に連携もなしで、何が事務処理の効率化なの？
このデータはすべて保険者が持っているわけで、そちらにマイナンバーで請求できるようにすればいいだけだよね？各医療機関にデータ置いとく意味ないよね？現状保険が複数ある以上（国保や弱小社保救済のため統合しようという話はある）保険番号がマイナンバー以外に存在することは変わらないし。
現状すぐできるわけではないし将来的にの話としても。問診票書いてもらう手間は減るかもだけど、ボトルネックはそこじゃないので待ち時間は変わらない。そして、データは全開示か全否定くらいしかできない。自分の必要な情報だけ「私は糖尿病の治療中で低血糖の可能性があります」みたいなカードを持っていたほうが意識がなくても開示できて便利な気もする。災害対応という意味でも、電子化されても紙のお薬手帳は持っておいたほうがいいと思う。
受益者負担でお願いしたい。
