料金表を動かしたい。
そこから始まった話でした。
ところが、実際にプログラムを書くとなると、「料金表」という一枚の表をそのまま動かせばいいわけではありません。
プログラムに計算させるためには、まず人間が料金を判断するときに使っている条件を、一つひとつ入力値として分解する必要があります。
そこで、あらためて「何を入力すれば療養費を計算できるのか」を整理することにしました。
まず、何を入力値にするのか
最初に考えたのは、利用者様の負担割合です。
1割、2割、3割。
そして、全額を表示する場合には10割。
ここまでは比較的分かりやすい。
ところが、療養費の計算は、それだけでは終わりません。
施術する部位はいくつなのか。
同じ建物に何人訪問するのか。
往療はどうなるのか。
マッサージなのか、変形徒手なのか。
鍼灸の場合はどうするのか。
マッサージと鍼灸を併せて行う場合はどうするのか。
こうして書き出してみると、料金表の中に隠れていた条件が、少しずつ見えてきました。
負担割合
まずは、1割・2割・3割です。
ホームページに料金表を掲載するだけなら、1種類の負担割合だけを載せておいて、利用者様に「2割ならこのくらい、3割ならこのくらい」と説明する方法もあります。でもWebサイトであれば条件を元に計算出来て動かせられることを知っている私は、割合を選択できるようにしたかった。
さらに、施術者側が制度上の料金そのものを確認できるよう、10割の表示も必要だと考えました。
「利用者様が実際に支払う金額」と「療養費として計算される金額」は同じものではありません。
ここを分けて扱う必要があります。
部位数
次に、マッサージの部位です。
何部位を施術するのかによって料金が変わります。
つまり、単純に「マッサージをする」という一つの入力だけでは足りません。
プログラムから見れば、
マッサージをするかどうか
ではなく、
何部位なのか
まで入力値にしなければなりません。
訪問人数という条件
そして、今回あらためて制度を読み直していて、かなり重要だと思ったのが、一つの建物に何人訪問するのかという条件です。
訪問施術の現場にいると、一つの建物に複数の利用者様がいるケースは珍しくありません。
私自身、以前の訪問施術の現場で、一つの建物にいる複数の利用者様を担当していました。
当時は、同じ建物への訪問であっても、別の場所との往復を挟んで訪問するような運用も現場にはありました。
昼食などの理由をつけて、いったん別の場所へ移り、また同じ建物へ訪問する。
そういう現場を実際に経験させられていました。
この制度が変わり、一つの建物について、そこへ何人訪問しているのかという考え方が料金計算に入ってくるようになりました。
一人の場合と、同じ建物に複数人訪問する場合では、訪問にかかる料金の扱いが変わります。
つまり、シミュレーターにも、
「この建物には何人訪問するのか」
という入力値が必要になります。
これは、単に「訪問したか、しなかったか」だけでは計算できないということです。
往療
さらに、訪問施術である以上、往療についても考える必要があります。
施術そのものの料金だけを計算して終わり、というわけにはいきません。
どこからどこまで訪問するのか。
その距離によって扱いが変わる部分がありました。
このあたりから、最初に思っていた「料金表を動かす」という話が、だんだん「療養費の計算条件を入力するプログラムを作る」という話に変わっていきました。
マッサージと変形徒手
マッサージの場合も、一種類ではありません。
通常のマッサージと、変形徒手による施術では、計算の仕組みが異なります。
したがって、ここもプログラム上では別の条件として扱う必要があります。
人間が料金表を見れば、
「こっちは通常のマッサージ」
「こっちは変形徒手」
と判断できます。
しかし、プログラムにはその判断をさせなければなりません。
鍼灸
鍼灸になると、さらに別の計算になります。
マッサージと同じ仕組みをそのまま使うことはできません。
鍼灸の施術について必要な条件を整理し、それに応じて計算できるようにする必要があります。
さらに、マッサージと鍼灸を併せて行う場合にはどうするのか。
ここまで来ると、最初に考えていた「料金表を動かす」という言葉が、少しずつ怪しくなってきます。
もはや一枚の料金表ではありません。
そして、10割表示
もう一つ入れておきたかったのが10割表示です。
利用者様に説明する場合には、1割・2割・3割の自己負担額が分かれば十分かもしれません。
一方で、施術者側が制度上の料金を確認するときには、10割の金額があった方が分かりやすい。
そこで、
- 1割
- 2割
- 3割
- 10割
を切り替えて表示できるようにしました。
どこまでをシミュレーターの責任範囲にするのか
ここで、もう一つ考えなければならないことが出てきました。
「何でも計算できるようにすればいいのか？」
という問題です。
プログラムは、入力された条件に従って計算することしかできません。
その入力条件が制度上正しいのか。
医師の同意が必要な条件を満たしているのか。
実際の請求が可能なのか。
個別の保険者でどのような扱いになるのか。
そこまでを、この小さなシミュレーターに判断させることはできません。
そこで、このツールの役割を、
制度上の条件を入力して、料金の目安を計算すること
に絞ることにしました。
請求そのものを行うレセコンではありません。
まして、療養費の支給を保証するものでもありません。
あくまで、訪問施術の料金を考えるときに、その計算を少し楽にするためのフロント用ツールです。
こうして入力項目を一つずつ整理していくと、最初は小さな「動く料金表」だったものが、少しずつプログラムらしい形になってきました。
そして次は、この条件を実際にJavaScriptの中でどう表現するか、という話になります。
