投稿者: yamamoto

投稿日:

久しぶりの障害

FMS17にしてから、本当に安定していて再起動自体があまりない。安定していることはよいことなのだが、いざ障害が発生した特の手順やノウハウがあまりないというのも事実。昨日はまさにそんな瞬間だった。

原因は単純。連携用VMのハードディスク領域が一杯になった。ということで、復旧が大変なんですが対応は簡単。だったはず。でもそうじゃなかった。まず、受け取れていない大量のジャーナルがあるため、送り元にジャーナルの再送を依頼する必要がある。これは避けて通れないので、帰宅途中のSEにお願いした。

しかし、ハードディスク領域がそれほどまでに消失されたのは、実は数百件にもおよぶ電文が何千回もリトライしていたからである。さて、このリトライの原因がわからない。十数本あるJDBCのラインの一本が滞留し一個もデータが流れない。

よく観察すると、正常と思われる電文さえ流れずどんどん滞留してリトライしている。これはデータベース本体の損傷？を疑い、バックアップからデータベースをデプロイし直して試すもだめ。データベースサーバーの再起動（データベース再起動は、起動後２回目という珍しさ）までしたが、全く反応しない。

さらにログの解析をしつつ、データなしのデータベースをアップロードして試すも動かず。すると、一瞬xDBCインターフェースが起動するがすぐに落ちるというのが繰り返されていることも気付く。たった一つの電文がインターフェースをクラッシュさせ、それが復旧しても、最初のリトライで再びクラッシュ。延々と何千ものリトライが続く流れになっていた。その連続するクラッシュがさらなるエラーログを発生させ、半端ない性能のVMが大量のハードディスク領域を消費して、電文欠落が発生したと。

さらに、この原因電文が半年前の障害と同じ原因であることも判明。（FileMakerのxDBCにはSQL長の限界があるみたいで、それを超えるとクラッシュする）しかも、その対処用の新バージョンのミドルウェアの納品を受けているのに、それをアクティベートするプログラム側の更新を怠り、古いまま動き続けていたと。

とにかく自分の間抜けを思い知った一瞬である。なので、対応昨として失敗ブログにしてみた。

文章化することは、いろいろな意味で記憶の強化となる。たとえ失敗でも。

投稿日:

httpsへの対応メモ

whois情報の確認を怠りレジストラからお預けを食らったことを反省。レジストラの諸々の情報の見直しを掛けたついでに、レンタルサーバへDNSを移管した。それを機にレンタルサーバー側の設定の見直し。

サーバー側が常時SSLに対応を掲げていたため、試しにSSLアクセスへ変更。デフォルトの証明書はサーバーの素のドメイン名であるため、medicalmacドメインでアクセスすると証明書に不備があると（当然）して、手動で通さないと通信できない。ただし、通信自体はレスポンスも問題無く、画面遷移も若干のhtmlの書き直しでリンク切れなども発生しないことを確認。

2日ほどデバッグを行い、1年前にセッティングしたwordpressも最新版へアップデートをかけ、phpもアップデート。

サーバーコンソールをよく観察するとLet’s encriptの設定タブがあったので、デフォルトの証明書からこちらへ切り替え。最初はワイルドカードを選択し、DNSへのtxt追加が出来ないためはじかれたが、単純なドメイン認証だけにしたらあっさり通過。ものの10秒程度の作業だった。

実はこのドメイン2001年ぐらいから。その前はso-netのページだったがこちらに移管して18年が経過していた。なので、googleの検索から飛ぶと当然httpになる。そこで、サイト直下の.htaccessファイルに

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

を書き込んで設置することで無事、googleからのリンクでもhttpsへ飛ぶことを確認した。特に商売をするわけでもなく、アクセスも極端に減った現在、ランクの高い証明書をインスルトールする必要もないと判断した。

投稿日:

電子カルテ1.0

現在の電子カルテの現状は「Death by thousand of clicks」というショッキングな題名の論文に代表されるのかもしれない。Obama政権ですすめられた電子カルテ化政策で、米国での2008年の普及率4％が2018年時点で96％まで急峻に推し進められた一方で、電子カルテが利用体験が悪く医療事故も起き、医師の負担も増えている。一回のER勤務で医師は4000回もマウスをクリックし、検査データが伝わらず医療事故の原因となっている。電子化された後でも90％の病院が連携接続しておらず、変わらず紙とFAXを継続している状況であるという。

さらに問題の根は深い。訴訟大国である米国では、電子カルテの不具合に対して、不具合の共有が守秘義務契約によって阻まれるという。また政府主導の急速な電子化ルテ化が未曾有の電子カルテベンダーの乱立という結果となり、利用者側の習得も難しいだけで無く、分断したシステム間の標準的通信規約がおろそかになり、カスタマイズに伴うコード変更一つで連携エラーを容易に起こすという。

誤警報も多く、一人の臨床医がICUで一日に最大7000件の警報を受ける状況のなか、実に85％〜99％が誤警報であるという報告もある。誤警報には訴訟を回避するだけとしか思えないものもある。例えば年齢を考慮せず性別だけから妊娠を考慮しているかどうかのアラート画面を、処方のたびに出すシステムは医師の疲弊を誘導しているとしている。医療システムへの訴訟リスクの高まりが、医師の負担に直結しているという皮肉な状況である。

翻って現在の電子カルテの現状を俯瞰した場合、それは電子的に清書された紙カルテに過ぎず、「真正性、見読性、保存性」を満たすが、データの二次利用、活用は人的労力でしかなしえず、機械処理に向いていない。すなわち電子カルテではなく「紙カルテ2.0」にとどまると指摘するものもいる。

京都大学の小林先生は真の電子カルテを、まだ見ないパーソナルコンピュータの理想像の一つであるダイナブックを例に示した。ダイナブックは「ダイナミックメディアを扱うことが出来る本のようなデバイス」であり、人間の思考能力を高め、子供でもプログラムが可能なものであるとされた。それを真似るなら、診療を支援し、医者がプログラム可能で、ガイドラインは自動で取り込まれ、医療機関横断的に情報を示すことが出来るように、データが患者の管理下にあるようなものが想定されるという。

電子カルテ1.0に至るマイルストーンとして、インターフェースをしっかりと解析できる基盤が必要であり、処理速度も高速でなくてはならない。治療ガイドラインを示す、関連文献を見せる、アドヒアランスを評価できるなどの機能が必要かもしれない。業務手順を最適化できる、プログラマブルな機能も必要だ。

そこを目指すには、ガイドラインは機械処理出来る形での提供が理想だし、単純な医療情報標準化を超えた次のレベルが必要ともしてきた。電子カルテのパッケージ化は、企業収益という意味では正しいが、利用者側からは正しくない。ただし機能改善とカスタマイズの切り分けも重要。電子カルテ1.0に向けた行動として、理想的で高度かつ明確な目標を立てることも重要だが、過去の多くの議論のなかにも既に多くのヒントがあるのだから、まず出来るところからしっかりと進めていくことも重要であるとした。