電子カルテバージョンアップにおけるStaging環境の有用性
近年の電子カルテは他業界にいくらか遅れをとっていますが「パッケージ型」が主流です。
パッケージ型の最大のメリットは定期的にバージョンアップを行うことにより新しい機能の搭載や陳腐化が防止できるという点においては衆目の一致するところであります。
しかし、病院におけるバージョンアップの管理手法として致命的な欠点があります。
それは「ベンダーまかせ」の一点に尽きると思います。
「いやいや、ウチはテストはちゃんとやっているよ」という病院もいくつかはあるでしょう。しかし、本気で受け入れ試験を行っている病院が果たして全国でいくつあるでしょう?私は圧倒的に少ないと思っています。
なぜなら、「バージョンアップは保守契約の範囲内なのだから、ベンダーさんが責任もってやってくれるんでしょ?」的な論理がまかりとおるからです。
そして、大手ベンダーではそれなりにSEさんを投入して現地テストして、最後に「病院さん、最後の確認お願いしますね」と形ばかりのテストを頼んで、いざバージョンアップ!ってなもんです。
で、バージョンアップ後に不具合が発生したら「報告書を出せ」とか言ってませんか?
それって、完全に責任転嫁ですよね。
企業システムにおいて、システム部門が受け入れテストを行わない企業などほとんど無いと思います。なぜならそれはシステム部門の義務だからです。
なのに、それをさも当然のように放棄して「よろしくね」で済ますのは言語道断です。
とまぁ、大上段から偉そうなことを言いましたが、当院も実は「言語道断」なシステム部門だったのです。
それは大手のベンダーさんに慣らされてしまっていたからなのか、単純に私が面倒くさがりだからか、どちらかあるいは両方が原因です。
そして、電子カルテベンダーを乗り換え、3回ほどのバージョンアップを経験しました。今までのようなありきたりの形ばかりのテストで臨んだ結果は惨憺たるものでした。
特に本稼働後の最初のバージョンアップはひどいものだったと聞いています。当時私は療養休暇中でしたので後から聞いた話ですが・・・。
そして、ユーザー会等で他病院の担当者さんと意見交換をしても「(バージョンアップの)ファーストユーザーにだけはなりたくない」という意見で一致しています。もっと言えば、当院に常駐しているSEさんも「できればやりたくないです」的なオーラを発しています。
とにかくバグ、デグレ、設定ミス等が多すぎるのです。もう少しソフトウェアの品質を向上させて欲しいとは思いますが、なにぶん生まれたての電子カルテです。どうしても機能強化にリソースを振り分けなければならない事情も分かります。
なので、今回は気合いを入れて病院側でもしっかりテストを行いました。
今回はStaging環境というものを用意してみたです。
Staging環境とは何かを話す前に一般的な電子カルテの系統を整理しましょう。
- 『本番系』:言わずもがな実際に業務で使用している環境です。
- 『開発系』:テスト系とも呼びますが、改修PGを適用してテストする環境です。
- 『教育系』:主に操作研修などで使う系統。開発系と一緒の場合もあります。
おそらくどの病院も多くてもこの3系統で運用していると思います。
で、バージョンアップやパッチの適用は開発系で行いますよね?ここで一つの疑問にぶち当たります。
果たして開発系は十分なテストをするに適した環境であるかという疑問です。
- 登録されている患者はテスト用の患者で、本番系に比べてデータ量が不足している(ある意味きれいなデータベースである)
- 実際の運用で発生する様々なデータがないという視点では質的データも不足している。
この環境で果たして十分なテストが出来るかと考えると、不十分であると当院は考えました。
そこで、他のソフトウェア業界ではごくごく当たり前だと思うのですが、Staging環境の登場です。
google先生に聞くと
ステージングとは、システムを公開する手前の段階で、実際にサービスを提供する環境(本番環境)とほぼ同じ環境にシステムを反映させ、動作や表示などの最終確認を行う段階、もしくは環境のことである。
と定義されています
要は、適用バージョンの環境に本番系のデータをごっそり複製してテストを行う手法です。
これを読んで下さっている医療以外のエンジニアの方には「なにを当たり前のことを言ってるんだ」という感想をお持ちになるかと思いますが、前述の通り医療システム業界においてはその「当然」が当然ではないのです。
で、当院は今回のバージョンアップにあたり、ベンダーさんにお願いしてStaging環境を構築して頂きました。幸いにもまだ稼働して1年なのでデータ量が少ないので、そこらへんに空き容量があったサーバに暫定的にぶち込んだだけですけどね。
で、テスト手法もベンダーさんと病院とで切り分けました。
- ベンダーさんは開発系で受け入れ試験を行う。
- ベンダーの受け入れ試験が終了し、試験成績書が提出されたら、病院側はStaging環境で全体テスト及び機能強化項目の個別テストを行う。
これにより、病院側の責任が明確になり、「ベンダーさんがやってくれるだろう」的な考えは排除出来、責任分解点が出来たと思います。
で、先週バージョンアップが行われましたが、過去のような大きな不具合なく、バージョンアップを終えることが出来ました。
ただし、このバージョンアップは実は3週間前に予定されていたバージョンアップなのです。
いざStaging環境でテストをすると出るわ出るわ不具合の山。ひどいのは、この不具合を修正したらこっちに不具合がでたとか、昨日までは正常に動作していたのに今日はダメとか。(笑)
結局バージョンアップ予定日までに当院私たちが発見した不具合が解消されなかったので、2週間ディレイさせたわけです。
最終的に病院が発見した不具合はおよそ100項目。ありえんwwwちゃんとテストしてんのかおまいらwwwなどと草を生やしたくなる気持ち、幾ばくか分かって頂けますでしょうか?
なので、当初の予定ではテスト→不具合修正→最終テストと2回のテストを想定していたのですが、結局テスト4回やりました。電子カルテの全機能テストを4周回すのは本当に苦痛でした。
苦痛だったけど、当日に走り回るのだけはもう勘弁して欲しかったその一念でみんなで頑張りました。
そんな苦労もありましたが、ソフトウェア管理のあるべき姿という理想と、品質的に信頼の置けないという現実、これらを埋めるために試験的に導入したStaging環境ですが、結論としては「やってよかった」の一言に尽きると思います。
今後はベンダーさんに頼んで、ちゃんとしたStaging用のサーバを準備してもらいたいと思います。
最後に、当院の電子カルテベンダーさんのユーザー会で、今年は私が「データの二次利用」について話してくれと言われています。
が、そんなことよりもこのStaging環境の有用性をほかのユーザさんに知ってもらったほうがいいんじゃないかと思っている今日この頃です。
だって、システムの安定稼働があってこそのデータ利用であるのだから。
