医師の当直表・拘束表問題のフェーズ設定

 この病院では、後述するつなぎ宿直において、複数の診療科を担当することがあり得るので、フェーズモードのタスクにより特定する必要があります。タスクを用いるには、フェーズ設定が必要になります。1日を3つのフェーズに分けています。朝から始まる昼間帯の勤務がフェーズ0になります。本勤務表では、当直・拘束以外は、扱いませんが、通常の勤務は、フェーズ0となります。其のあと、夕方から夜間がフェーズ１、朝までをフェーズ２とします。深夜から翌朝までは、次の日になることに注意してください。つまり、今日のシフトは、明日の分まで含んでいます。

多くのシフトを掲載していますが、その胆は、次の３つです。

宿日直と宿直に関しては、DayNの指定で、DayN＋１の朝まで、働くことに注意してください。休日・診療日によっても朝就業時刻は変わってきます。これは、DayN＋１でも当てはまります。そのために、終了日を＋１して6月1日にしました。制約するのは、あくまで5月ですが、6月1日の祝日・振替祝日の状態によって5月31日のシフトが決まります。

さらに宿日直と宿直は、医局から派遣される医師（非常勤）の都合で、短時間の宿直が必要になる場合もあります。それらは、30分以下の空きや重複がないように、常勤医師によって切れ目なく補間される必要があります。これらの短時間就業時間は、つなぎ宿直として勤怠管理されます。

さらに、これらの要件は、オンコール（拘束時間）についても同様です。そうなると、看護師・介護士の定型パターン、一つのシフトを入り明けに分割する手法では、シフト状態が膨大となるので現実的ではなくなります。医師の当直表・拘束表では、以上のようなフレームワークとする方が、汎用性があり・拡張性があると考えます。

医師の当直表・拘束表問題の期間設定

 医師の当直勤務は、特殊で24時間に及ぶことがあります。そのため、最長でも１６時間ので看護師・介護士の定型パターンで、記述しようとすると無理があります。

そこで新たなフレームワークを作ることにします。最初に行うのは、期間設定です。通常月始め１日に始まり、月末で終わるのですが、区間を1日伸ばし、翌月の１日を制約終了日とします。

開始日は、5月1日

終了日は、6月1日にします。

「今月」は、5月1日ー6月1日を指すので、新たに「今月区間」で、本来の今月を定義します。そのために、まず「次月」の補集合をとります。

それを「今月」とANDを取れば、目的の「今月区間」を得ます。後は、従来の今月を今月区間でReplaceします。

「今月診療日」と、「今月休日」を定義します。

医師の当直表・拘束表問題

 地方病院で特徴的なのは、医局から派遣される医師の勤務体系方と常勤医師の勤務体系異なることがある、ことです。これにより変則的な勤務である、いわゆる「つなぎ宿直」が発生することがあります。

この問題を考える前に、医師の当直表をどのように実装したらよいかを考えてみます。

一言で、当直と言いますが、この言葉は、広い意味があるので、次のように厳密に定義することにします。

日直：休日の昼間時間帯の勤務

宿直：夜間帯の勤務

宿日直：日直と当直を合わせた勤務

拘束：日直、宿直または、宿日直の時間帯の自宅待機等

当直という言葉は出てきませんが、これらを総称、あるいは部分を指している言葉が当直と考えられます。

グラフニューラルネットワーク

 グラフニューラルネットワーク (機械学習プロフェッショナルシリーズ) | 佐藤 竜馬 |本 | 通販 | Amazon

本を買いました。GNNは、あらゆるデータ構造を表現できるのだそうです。中身は、難しい数式のオンパレードですが、いきなり数式ではなく、概念を分かりやすく解説しようという筆者の意思を感じます。まだ、全然理解出来ていません。単にグラフといったとき、ダイクストラ法、２分岐グラフ、BDD、ZDDを思いうかびます。これらは、SATやMIPという組み合わせ最適化における重要なツールや部品であり、実務でもよく使います。一通りのグラフ理論は知っていたつもりでしたが、GNNは、そうしたよく使うグラフと同じとも言えますが、グラフ化する対象が異なりそこに機械学習手法を持ってくることに特徴があるようです。

GNNを勉強しようと思った理由は以下です。

１）組み合わせ最適化での応用

２）日本語→モデリング

１）に関しては、ダイレクトな論文もあり、何とかなりそうな感じではありますが、２）に関しては、未だ雲を掴むような感じです。

Algorithm5のプロセッサ数

 現状、予定しているのは、3個のアルゴリズムを同時に走らせます。なので、少なくとも３個以上のCPUが必要になります。最近新たに発売されているCPUは、全て４コアないし６コアのようですので、何の問題もないと思います。将来的に、4アルゴリズム以上になる可能性がないとは言えないのですが、効果は僅かだと思います。

また、PC選びで重要なのは、コア数よりも2次・3次キャッシュサイズです。1コアあたりのキャッシュが大きければ大きいほど、マルチCPUによる性能の劣化は小さくなるからです。

Algorithm5をリリースした後は、INRC2とSchedulingBenchmarksの記録更新に再び挑みますが、その際は、3次キャッシュのもっとも大きいRyzen３Dにしようと思っています。

スタッフ数20－30人程度ならば、普通のPCで十分ですが、ICU70人程度のNSP問題を扱うなら、上記に鑑みたPCとすることをお勧めします。

Algorithm5の時間定義の変更

 今まで、時間は、そのままの定義でしたが、Algorithm5では、時間の定義を変えています。今までは、高性能PCの１０秒と、低性能PCの１０秒では、目的関数値の値が変わることはありました。しかし、１０秒は１０秒でどちらも同じです。Algorithm５では、それが変わります。

ソルバを決定的にするには、Decision数もしくは、Conflict数をLimitにする必要があります。Decisionというのは、変数に「えいや！」と当てずっぽうで０か１に割り当てることです。全ての変数を矛盾なく割り当てられたときに解があります。当てずっぽうなので、大抵どこかで矛盾が生じます。矛盾が生じたら、問題となる原因のところまで戻って変数の割り当てをやり直します。戻ることをバックトラック、矛盾が生じたことをConflictと呼びます。

基本的には、Decision数と秒の関係を一定とみなして、対応するDecision数をLimitにします。そうすると、いわばClock数でLimitにすることに対応するので、遅いPCと速いPCでは、実行時間に差が生じることになります。しかし、どちらも同じ目的関数値になることが期待できることになります。

残念ながら、Decision数と時間との関係は一定ではなく最大で２０倍程度の差があることが分かっています。なので、あまりにも目標の時間に到達していない場合は、積み増ししてなるべく目標時間になるような実装としました。その結果として、必ずしも決定的にはなりません。しかし、プロジェクトファイルが同じならば、時間のかかり具合はPCで変わろうとも、ほぼ同じ結果となることが期待できます。

新しいAlgorithm1のアーキテクチャ

 従来のAlgorithm1のアーキテクチャは、パラレルSATソルバです。ポートフォリオと呼ばれる形態を取っています。これは、同一の問題を異なるパラメータで解く方式です。この方式の問題は、

■決定的にならないこと

■大して高速化しない。良い場合もあるが、シングルスレッドの方が良い場合もある

内部のソルバ間は、学習節を交換しながら進みます。マルチスレッドであっても、基本的にアルゴリズムは、一つです。つまり多様性に乏しく、実使用時の様々な問題に対して常に最適なアルゴリズムであるとは言い切れない、という問題がありました。

そこで新しいアーキテクチャは、次のようにします。複数のアルゴリズムを並列に走らせます。問題の形態によっては、得意なアルゴリズムは変わってきます。複数のアルゴリズムを一機に走らせます。アルゴリズムを選びません。どの問題に対して、どいうアルゴリズムが親和性があるか？判定するのも時間がかかってしまうからです。アルゴリズム間では、情報を交換しません。先に着いた者勝ちという、単純な構想です。

懸念としては、駆動インスタンス分のメモリがどうしても必要になります。キャッシュヒット率が下がり、シングルスレッドよりも遅くなることが考えられます。この傾向は、規模が大きければ大きい程顕著になります。

これによる効果としては、

■安定度が高い。プロジェクトが決定的になる確率が高い

■求解速度向上

デメリットとして

■解は、一つのみ

■原因解析機構は、後回し

■リニア解の最適値には、必ずしも合致しない（準最適解）

■環境によっては、遅くなる懸念（メモリキャッシュ問題）

なので、Algorithm5として実験的に実装する予定です。Algorithm1は、そのままとします。

目標は、

１）解を決定的にする

２）ICU70人問題の求解時間6分を2分以下にする

３）SchedulingBenchmarksの記録更新

４）INRC2の記録更新

にありますが、これにより１）２）について、ほぼ達成見込みとなりました。

実使用時の改善となります。しかし、本題の３）４）の改善には、全く寄与しません。

学術問題のベンチマークと実使用時の問題とでは、問題の性質が全く異なるからです。言い換えるならば、Algorithm1/5は、実使用時の問題用、ということです。

学術問題には、学術問題用のアプローチが必要であり、Algorithm5では歯が立ちません。

しかしながら、そこも含めて改善しておかないと、記録更新に到底届くものではありません。今回の改善もそのために必要なステップです。