電子カルテシステムの開発会議は水曜十九時から。発注主の医師が訪問診療から帰ってくるのは十七時頃のはずだが、診療はしばしば延びる。帰えると待ち構えている看護師や事務スタッフにつかまり、開発会議はなかなか始まらない。そして、患者の急変で再び飛び出して行くこともあった。試作した画面を改善しつつ、四月にオープンするクリニックから新しい電子カルテを利用することになり、患者を既存の電子カルテから移行。始めてみると問題が次々見つかる。（まあ、よくあることだ）
　ところで、新規クリニックに既存の患者を移行って、普通の外来クリニックで、オープン前に患者がいることはない。新クリニックの診療圏に既存クリニックから出向き、診療を始めているのだ。在宅ならではだ。クリニックの申請に院長は必須だが、オープンまで様々な手続きがあり、期間がかかる。医師や看護師を遊ばせておくわけにはいかない。そこで、既存クリニックとして診療を始め、オープン後に患者を移す。移すと言っても、患者は寝たきりである。やって来る医師は変わらない。変わるのは請求書のクリニック名。これを「クリニック異動」と呼ぶことにした。
　開発を受託していた会社の一つが運用も受託することになっていたのだが、担当者が辞めてしまい、新たな人に上京してもらった。二十台の寡黙な青年は、朝、オフィスに来るなりヘッドホンをつけ、パンを食べ始める。
　在宅医療のクリニックは朝が早い。準備して九時には患者宅に出発する。その前に事務スタッフは患者宅に電話して、当日の訪問を確認する。だから、問い合わせやクレームも朝からだ。電話は私がとることになる。（パン食べてる場合じゃない）
　私は三月に渡英する予定だった。帰国するのは六月。そのときどうなっているか、心配になってきた。私も彼も電子カルテは初めて。だが、私には納入・導入・運用の経験がある。安定するまで見届けよう。飛行機はキャンセルした。予感は当たり、四月は戦場になった。
　「処方せんを印刷しようとしたら画面がぐちゃぐちゃ」画面が奇妙な文字で埋め尽くされている。よく見ると先頭にスペースが一文字。これでブラウザはＰＤＦと認識できなかったのだ。ＰＨＰ言語のソースコードを検索して、スペースを吐き出す犯人プログラムを捜す。
　「急に画面が重くなった」サーバには特に問題はない。遅くなった画面を調べていると、月を選択するプルダウンメニューがすごいことになっていた。０年０月から２０１２年４月まで２万行以上ある。カルテの日付を基にプルダウンメニューを作っていた。ははあん、誰かが０年０月のカルテを作ったのだ。
　月を選択させるのに、存在するカルテを基にするのは合理的な気がする。しかし、日付を指定しないでカルテを作成すると、０年０月０日ができてしまう。誰がなぜ？医師やスタッフが新しい電子カルテの操作を試していた。消しても消しても０年カルテができてくる。
　０年カルテは阻止した。今度は「明日のカルテ」が見つかる。看護師に訊くと、診療前にカルテを用意するのだという。診療中にゼロから書くのは時間がかかる。クリニックに戻って思い出しながら書く医師もいるが、事前に書いておき、変化のあった部分だけ修正するほうが早い。安定している患者なら、二週間前と大差はない。
　もっと未来、三カ月先とか一年先のカルテを書く医師もいた。忘れないよう備忘録として書いていた。いろいろな使い方があるものだ。
　処方せんも事前に用意する。現地で処方せんを手書きするのは大変だ。（保険番号や薬剤名を畳の上で書くことになる）様態が安定していれば薬は継続でいい。もし変更する場合は、電子カルテの処方を修正し、薬局にＦＡＸするほうが間違いがない。
　そのＦＡＸ送信プログラムも事件を起こした。薬局から「ＦＡＸがずっと専有されて困る」とクレームが来た。調べると数百ページも送っている？本来たった数枚の処方せんだが、ＰＤＦが文字化けし、奇妙な文字で埋め尽くされた頁がＦＡＸからあふれている。すぐＦＡＸ業者に頼んで送信をキャンセルする。
　夕方、「処方せんにコーヒが印刷されない」と電話があった。コーヒ？「原爆症の公費」認定患者は医療費が補助される。水俣病や石綿などがあり、それぞれ保険番号が付与される。
　処方せんの上に「公費欄」があるって知ってましたか。「〇〇さんは下にもお願いします」下にも公費欄があった。二つ持っている患者さんがいるからだ。プログラムの改修もだが、制度の理解に時間がかかる。「上下出ました」と電話したのは２１時、お待たせしました。
　「電波切れになる」４Ｇは始まったばかりで、郊外ではまだまだ３Ｇだった。パソコンから電波を飛ばし、インターネットを経由してサーバに通信するが、応答時間が五秒を越えるとパソコンは電波切れと判断していた。応答待ちを十秒に延ばしてみる。「まだ切れるぞ」ええい二十秒だ。
　「書類に文字化けがある」「ミリグラムが表示されない」ミリグラムやミリリットルには一文字の外字があるが、ＰＤＦのライブラリが外字に対応していなかった。ｍｇやｍｌの二文字に置き換えるプログラムを追加する。
　毎日、このようなクレームと改修の繰り返し。当日受けたクレームは当日解消するのが基本だ。そうしないと積滞していく。たった二人の保守運用チームだ。
　数日かかる場合もある。処方に麻薬を含む場合、発行できるのは麻薬取扱者免許を持つ医師だけだ。処方せんに免許番号を記載しなければならない。診療に同行した際、医師がクリニックに電話して「ぼくの麻薬番号教えて」とやっていたのだ。都道府県が発行するから、クリニックの住所で番号は異なる。一日に異なるクリニックの患者を回るから、誰にどれを記載すればいいか難しい。麻薬のありがたさは、末期ガン患者の家で目の当たりにした。しかも、免許は一月一日に更新され、番号が変わる。
　「うおー」ヘッドホンでパンを食べていた彼が突然大声をあげた。パンにゴキブリでも？データベースのバックアップをとるつもりで、コマンドを間違え、逆に前日のバックアップを本番に書いてしまった。つまり、きのう１日分のカルテと処方を消してしまったのである。まだ利用者は少なかったが、罵声を浴びた。ログから一部は復元したが、処方せんは薬局に頭を下げ、送付した処方せんをコピーさせてもらい、カルテに書き戻した。ヘッドホンの彼は、手が震えて、コマンドが打てなくなった。
　導入一カ月で敗戦・撤退か。そこへ神風が吹いた。既存の電子カルテシステムがダウンしたのである。（ＲＡＩＤ５の二重障害）連休にかかり、修理に一週間以上かかった。まだ大半の患者は既存だったが、在宅医療に連休はない。クラウドへの移行を、みな渋々だったけれども受け入れてくれた。

　交換機の開発に携わった新人のときは「いずれ新しい交換機を創ってみたい」と思った。しかし、新規のハードソフト開発は千億円。一方、維持管理に毎年百億、こちらのほうが改善効果がある。生産性が上がれば、より多くの機能追加もできる。だが、改良を拝命したのは開発から七年後、すでに全国導入されていた。日本の四大メーカが作ったプログラムを改良、さらに機能追加も自前。四十人でスタートしたプロジェクトは、三年で千三百人に膨らんだ。
　さあ、今度は電子カルテだ。またも新規でなく改良、いや導入も運用も自前。交換機では新バージョン開発に１年かかったが、ＰＨＰ言語のＷｅｂシステムは毎日バージョンアップできる。
　しかし、他人が書いたプログラムを直すのは、新規に書くより難しい。先人はどう考えて作ったのか推測し、問題を見つけ、どう改良するか練る。駅を新規に造るより、営業中の既存を改修するほうが数段難しいのと似ている。（渋谷駅はすごかった）
　小手先で改善できる箇所もあれば、抜本的作り直しが必要な問題もある。技術者としては抜本を考えがちだが、工数が大きく、失敗のリスクもある。冷徹な費用対効果の判断が要る。
　スキルも問題だ。電話局で保守していた若者を集めたプロジェクトだったから、交換機は熟知していたが、プログラマとしては素人だった。今度は、医療に素人の二名だけだ。
　ヘッドホンの彼はＪａｖａの経験があるというので、看護師に頼まれた画面を一つ作ってもらった。リリースするとすぐ注意された。「血圧が逆ですよ」最低血圧、最高血圧の順に表示される。ソースを覗くが問題なさそう。それじゃあ表示プログラムが逆？あ、入力プログラムも逆になっているではないか。入出力両方が逆だから問題ないように見えていた。ということは、データベースに血圧は高低逆に記録されている。こんなノウハウ、今後何十年も継承するのは嫌だ。
　「僕のプログラムは正しく保存してしまっています。だからデータベースもう混在に」彼は泣きそうだ。そんなの簡単、大きいほうを最高に、小さいほうを最低に、データベースを訂正しちゃえばいい。「でも、データベースを直すと表示が逆になってしまいます」もちろん、入力プログラムも表示プログラムも差し替える。「それやってる最中、おかしいとクレームが」では夜中にささっとやってしまおう。クレームを怖がる余り、もっと大きな禍根を残したくはない。今は二人でも、やがて千人で維持管理するようになるかもしれないのだ。
　在宅医療専用と銘打つポイントは予約だ。外来の予約は患者がするが、在宅では医師がする。全く違う。
　訪問診療は基本月二回だから「第一と第三月曜」という風に覚えやすいよう決めるクリニックが多い。主治医が決まると、できるだけ効率のよい、訪問先が固まっている曜日を選ぶ。そして、電子カルテに「第一と第三月曜」と登録する。これは計画、まだ予約ではない。
　計画を基に翌月の予約を入れる。このとき、主治医や患者の都合で調整が入る。計画は一三月曜でも、第三月曜は検査入院という患者もいる。容態が悪化し、訪問を毎週に増やしたほうがいい場合もある。そのとき計画を毎週に変更してもいいが、「第二と第四月曜」を追加する手もある。主治医は二四月曜、訪問先が別エリアなので、他の医師に頼む。精神科や歯科などの専門医に応援してもらうこともある。一人の患者を複数医師で柔軟に診る、システムはそれに応える。
　計画は月単位だが、予約は即決で変更したい。医師が患者を診て「危ない、明日も来よう」と判断することがある。カルテから端的に登録できるようにした。計画を見直したり、予約を入れ直すのではなく、「次回〇月〇日」とダイレクトに入力、それが予約になるようにした。
　カルテや処方や車の準備、すべて予約をベースにしている。主治医が常勤とは限らない。特定曜日の非常勤医師も多い。明日誰に行ってもらうか、さっそく調整しなければならない。
　患者宅を訪問する件数は一日二十件くらいが限界だ。それが老人ホームなら四十人でも可能。すると「四十人？」看護師が私をにらんだ。一人ずつ予約ボタンを押すだけなのだが「毎月こんなことやってられません」翌月の予約を一人一人登録するのは、たしかに退屈だ。しかも、老人ホームは「予定表を早く送って」とプレッシャーをかけてくる。ホームのスタッフも予約をベースに動いているからだ。
　まとめて予約できる画面を試作したら「医師もまとめて変更できません？」インフルエンザにかかった医師が出たのだ。他の医師に代わってもらうが、５日分の予約は百件もある。一つ一つ医師を変更するのは大変だ。
　医師は、自分の患者の訪問カレンダーを要望する。事務スタッフは、いつどの医師がどの老人ホームを訪問するか。老人ホームは、いつ医師が来て、どの患者を診るか。看護師は、患者ご家族に「来月はこの日に来ますからね」とカレンダーを渡したいという。そのうえ「患者さんのカレンダーに誕生日を表示して」バースデーカードを用意するのだという。とりあえず赤丸を表示してみたら喜ばれた。（そんなんでいいんだ）
　ＦＡＸ送信プログラムは、文字化け事件を起こしてから誰も使ってくれない。クリニックが一日に送るＦＡＸは数十件にもなる。いちいち印刷し、複合機にセットし、電話番号を押す。ちゃんと送れたか、しばらく待って確認する念の入れようだ。
　ＦＡＸ機は送信失敗を「ピー」と知らせ、エラーリストも出る。通話中でリトライしてもダメだったのか、紙が切れているのか、理由も表示される。そこまでやらねば使ってくれない。ＮＴＴに問い合わせたが、失敗の詳細理由を送り返すサービスがない。悔しいがＫＤＤＩを利用することにした。
　ＦＡＸ送信が完了すると、送信者の携帯にメッセージを送るようにした。ケアマネージャーや訪問看護ステーションでは紙切れが多い。夕方、ＦＡＸが集中するので通話中ビジーも多い。
　患者を病院に搬送するとき、患者の情報を病院にＦＡＸする必要がある。往診後、クリニックに戻って書類を書き、印刷してＦＡＸしていたが、往診帰りの車中から送れるようになった。病院側も患者到着前に情報が届くのはありがたい。
　ＦＡＸの番号を間違えていると、いくらリトライしてもエラーになる。大きな病院にはＦＡＸが何台もあり、どこに送るか、電話で当直医に訊くのだが、聞き間違いや入力ミスが起こる。
　ＦＡＸリトライエラーが発生すると、当直医に電話をかけ、番号の再確認をお願いする。電子カルテ上に「送信完了」が出ると、私もホッとして眠ることができた。
夜間も毎日往診があり、緊急搬送がある。患者のご家族にとっては一大事だ。支える医療スタッフを、さらに陰から支えるＩＴである。