スケジュールナース 外部サーバ廃止

匠シフタ（モバイル用）のリリースに伴い、スケジュールナースの外部サーバは廃止になりました。

旧バージョンをお使いの方は、「外部サーバ使用」のチェックを外してお使いください。

自動勤務表の使い方

病棟勤務表事例でみる実践的使いこなし術　というレクチャノートを書きました。

業務システム向けスケジューリングシステム

ここに書きました。

Pythonによる設計した制約の検証

設計した制約が、目論見通り動くかは、解を目視でチェックすれば分かります。しかし、多人数の場合や、複雑な制約の場合、目視で解を全部チェックするのはつらいです。そこで、チェックをスクリプトで行ってしまおうという考え方です。幸いスケジュールナースは、GUIで定義した全ての集合の定義をPythonソースコードとして吐きますので、これを利用すれば、簡単にチェック可能です。
ここに書きました。

で、検証のPythonソースがちゃんと動くか、またそこに戻ってくるのですが、これは、別にエラーを意図的に作って、検証プログラムがちゃんとそれを拾うかどうかを見てみるしかありません。

言語による制約記述のチュートリアル

をここに書いています。

数独を題材にして、制約プログラミングの仕方について述べています。途中なので、ソフトは未だリリースできませんが、来年早々にソフトはリリースします。

制約プログラムというのは、答えを求めるアルゴリズムを記述することではありません。制約を課すことで、答えは自動的に求まります。ですから、その記述は、一通りではありません。が、出来れば、直感的に分かりやすく、なおかつ短い記述が求められます。

今回、そのための言語を設計したのですが、なるべく短い行数で、狙った仕様が記述できるように心がけました。　その結果ですが、かなり短く書けているのではないかと思います。数独のプログラミングは、他のサイトで散見されますが、その中でもかなり短い方ではないかと思います。

以下は、数独の全記述(34行）です。

//数独列制約
for (day in 全日){
 for (シフト in 全シフト){
  vector V;
  for (人 in 全スタッフ){
   V.push_back(X[人][day][シフト]);
  }
  $Onlyone(V);
 }
}
//数独行制約
for (人 in 全スタッフ){
 for (シフト in 全シフト){
  vector V;
  for (day in 全日){
   V.push_back(X[人][day][シフト]);
  }
  $Onlyone(V);
 }
}
//ブロック制約
for (人 in スタッフブロックトップ){
 for (シフト in 全シフト){
  for (day in ブロックトップ日集合){
   vector V;
   for (i=0 to 2){
    for (j=0 to 2){
     V.push_back(X[人+i][day+j][シフト]);
    }
   }
   $Onlyone(V);
  }
 }
}
dayは、本当は”日”にしたかったのですが、そうすると　日曜が、日として使われていたのでエラーとなってしまいます。

なお、ＷＥＢ版でも制約言語は動作しますが、Ｊａｖａｓｃｒｉｐｔのセキュリティ上、テキストファイルを呼び出すという風にはできないので、ＴＥＸＴＢＯＸに貼り付けになってしまいます。（デバッグについては、ＰＣ版の方が便利そうです。）

スタッフプロパティでフレキシブルな勤務表にする

下は、ある看護師長（ICU)のスタッフプロパティテーブルです。

各スタッフには、12個も属性があり、その属性を変更するだけで月々の些細な変更を吸収できるようにしています。このテーブルは、未だ作りがけであり、これから数ヶ月をかけて、看護師長共々、ブラッシュアップしていく予定です。（永久ライセンスをご購入頂きました。）

スタッフプロパティは、その病棟に固有な属性だと思います。同じスタッフプロパティは、この世に二つとないでしょう。それ故、自身の職場については、自身の言葉で制約を語れることが必要条件になります。それをお伺いして、私が制約化した結果が下のテーブルです。数ヶ月の後、安定してきたときには、中身は殆どいじくることなく、大体このテーブルだけでできるようになります。（経験則）

注目していただきたいのは、単に各スタッフの個人の要望を聞くだけではなくて、中々夜勤ができないスタッフも、可能な条件を聞いて、その中でも最大限、夜勤をしてもらっている事です。また、SS（深夜深夜）　JJ（準夜準夜）等、スタッフの好みや可否を入れて配置をしていることです。

個人の要望を受けつつも、なおかつ組織全体のバランスやQOLを考えていることが伺える内容になっていると思います。素晴らしい看護師長さんですね。
　
　

特許証が届きました。

どちらもスケジューリングに関する特許です。

早期審査制度を使っても、特許出願から特許査定が届くまでには、1年と6ヶ月かかりました。
図面作成、出願、審査請求、補正書、意見書、審判まで長い道のりでした。

 

経緯は　以下の通りです。


震災の日から3年目に出願しました。

出願　　　　　　　　　　　平成２６年３月１１日

審査請求　　　　　　　　平成２６年５月１１日

拒絶理由の通知（発送日）　平成２６年８月１９日
意見書（提出日）　　　　　平成２６年１０月８日
手続補正書（提出日）　　　平成２６年１０月８日
拒絶査定（起案日）　　　　平成２７年１月８日
同謄本到達（送達日）　　　　平成２７年２月３日
手続補正書（提出日）　　　平成２７年４月２７日
前置移管通知　　　　平成27年6月3日
特許査定受領　　　平成27年　8月26日
減免申請書提出　平成27年8月27日
特許証受領　　平成27年10月7日

教訓として、

1. 特許提出の前に特許性を押さえておくこと。
2. 特許提出の前に信頼できる専門の弁理士さんに見てもらうこと。

が挙げられます。

特許図面や、特許調査は、全て自分で行ない、それなりの特許性を持っているという
自信はあったのですが、審査官に理解してもらわなくてはいけないというハードルが結構高かった、という印象です。拒絶査定通知のとの対話　という本に、大事なポイントが書かれているので出される前に、一読されることをお勧めします。

2番めの点は、弁理士さんです。拒絶査定通知を受けてから、慌てて弁理士さんを探したのですが、ソフトウェアに関する高度な専門性な為、中々受けて頂ける弁理士さんが見つかりませんでした。幸いにも仙台市内で専門の弁理士さんおられたので、指導を頂くことができました。数々のご指摘を受けたので、特許を出す前から見てもらったほうがよかった、と思いした。早期審査制度を使っても、拒絶査定不服審判は、普通に費用がかかります。最初から弁理士さんに相談していたら審判までは行く必要はなかったかどうかは分かりませんが、折角、膨大な時間と費用を使って特許が落ちなかった（弁理士さん用語？）では、泣くになけません。勿論、弁理士さんに見てもらえば、必ず落ちるという保証はありませんが、確度が上がることは間違いないでしょう。

今回の一連の経験を通じて、特許成立の可否は、補正書や意見書を通じて、1人の審査官との対話にある、と感じました。拒否の理由を色々言ってくるのですが、その真意や理解度を推し量りながら書いていく必要があります。特許特有の言い回しもあり、その点でもやはり弁理士さんに見てもらうことをお勧めします。


最後に、特許庁とのやりとりは、通知を除いて書留めで送られてくるのですが、最後の特許証だけは普通郵便です。特許証の性格を考えるとそれも納得です。（ただ、法律上は、1ヶ月以内に特許料を納めることになっています。減免申請が通れば、問題ないのですが、減免申請後一ヶ月経っても音沙汰がないのであせりましたが、無事到着しました。）

仙台のソフトウェア関係の特許に強い弁理士さんでしたら紹介できます。メールでお問い合わせください。