システム導入時こそ、病院とベンダの協力体制が不可欠 ～ある裁判記事を見て～
日経コンピュータの記事で、個人的にとても印象に残る記事がありました。
病院側と電子カルテベンダ側が、電子カルテシステムリリース失敗の責任の所在について、裁判で争ったと、のことです。
一審の判決では、ベンダ側の責任が８割との結果でしたが、これを不服としたベンダは上告。今回の札幌高等裁判所の判決では、病院側の責任が１０割という、一審の判決を大きく覆すものでした。
終わらない追加要望
大きな論点のひとつに、「プロジェクト進捗管理」がありました。
今回の件では、追加要望の凍結をしたにもかかわらず、病院側はシステム追加項目を１００件以上も要求していました。これにより、ベンダ側の開発スケジュールは大きく狂わされていたようです。 追加要求によって、当然、納期は遅れてしまいます。しかし、病院側はこれを「ベンダ側のプロジェクト進捗管理の不手際」と主張。結局、電子カルテシステムのリリースが困難となり、契約解除となりました。
電子カルテは基本的にパッケージ仕様を大幅に変更せずに納品されることが多いと思いますが、病院独自の運用に合わせたカスタマイズ案件も、少なからず存在します。今回の場合は、後者の案件が通例以上に多かったのだと思われます。
システム導入後のメンテナンス性や、費用面から考えても、病院側がパッケージ仕様に合わせた運用に切り替えたほうが良かったのでしょうが、事情があったのでしょう。
それにしても、ここまで追加要求をねじ込むのは、やはり少々強引だったと思います。
断れない状況
記事によると、病院側の担当者は、「追加の要望を反映しないシステムは検収で合格させない」とベンダ側に伝えたそうです。これにより、ベンダは追加要望を断れない状況になっていたようです。ベンダ側も相当追い詰められていたはずです。エンジニアを増員するなどして対応したものの、納期は守れませんでした。最後のほうの現場はおそらく、「デスマーチ」（死の行進）の状況だったのではないでしょうか・・・。
マスタ作成に非協力的
マスタデータ作成は、電子カルテシステム導入時には、ものすごく労力が必要です。単純にボリュームが大きいのもありますが、電子カルテシステム、医事会計システム、部門システムなど、システムごとにマスタは存在し、それぞれのシステム間でマスタが連携しているかも確認しなければなりません。他にもありますが、とにかく、マスタデータ作成というのは手間のかかる作業なのです。
記事では、「マスターデータ作成の協力姿勢が不十分だった」と書かれています。属性にもよりますが、電子カルテシステムのマスタ整備は、ユーザ側が行うことが多いはずです。なぜなら、リリース後のマスタメンテナンスは、ユーザ側の仕事だからです。日々更新されるマスタを、いちいちベンダ側に作業依頼していては、保守費用がいくらあっても足りません。電子カルテシステム導入時にマスタ担当者を決め、その人にマスタの作り方を覚えてもらったほうが、その後のメンテナンスも任せやすいし、新規マスタの追加作業もしやすくなるでしょう。
今回のように、マスタデータ作成に非協力的では、病院内のマスタ担当者も経験値が上がらないでしょうし、ただでさえ忙しいベンダ側のエンジニアも疲弊してしまうのではないでしょうか。
最後に
僕はまだ電子カルテシステム導入や、ベンダ入れ替えに立ち会った経験がないので、あくまで推測の域を出ないのですが、医療業界でここまで「デスマーチ的な」案件は滅多にないと思います。
電子カルテ業界では、ベンダ側が提示したパッケージ仕様に運用を合わせる病院のほうが多いように感じます。標準パッケージになるべく近くしたほうが、２年ごとの診療報酬改定に伴うシステム改修のときにスムーズにいきますし、標準パッケージを採用した他院のノウハウをそのまま活かせることもできます。
確かに、今回の病院も、より良い医療サービスを実現するため、使いやすい電子カルテシステムを望んていたはずです。ですが、その目的を果たすために、ベンダに無理な要求を突きつけるのは、やはり間違いだと思います。電子カルテベンダもビジネスでやっている以上、仕様書や契約書の内容を守ってもらわないと困るでしょうし、なにより立場的に病院側より弱いのですから。
電子カルテシステム導入という大イベントのときにこそ、病院とベンダは互いに歩み寄り、助け合って進めていかないと駄目ですね。（実際に立ち会ったことないから、理想論で言い放題・・・）
ひとまず、最高裁の判決を待ちましょう。
WEBサービスのご紹介「調整さん」
ここ１年、飲み会の幹事などをする機会が増えました。そこで重宝しているのが、この「調整さん」というWEBサービスです。とても便利なので、ご参考までに紹介しようと思います。
■「調整さん」とは・・・
リクルート社が制作した、出欠表ツールです。ログイン不要で、無料で誰でも使えるようになっています。
■使い方
イベント名や、メモ、候補日程を選択し、「出欠表をつくる」を押します。
イベントページのURLが生成されます。
「イベントページを表示」を押すと、出欠表が表示されます。参加者が候補日を入力したとき、この票に反映されます。
実際に、最初の一人目を入力してみます。表示名、候補日に◯△✕、コメントを設定します。すべて設定したら、「更新する」を押します。記載した本人なら、後から修正も可能です。
出欠表に、反映されました。
複数の入力があった場合、いちばん皆の都合が良い日に、緑の網掛けが付きます。
ちなみに、イラストのON・OFFが選べるようになっており、ONにしておくと、参加者のアバターが自動生成され、テーブルを囲んでくれます。（男女の判断はしないはずですが、うまいこと合致していますね）
■利用場面
やはり、飲み会のイベントに丁度いいと思います。そのほか、お弁当発注を担当したとき、「お弁当が要る人、要らない人」を分けるために使ったこともあります。
URLのリンクを、メールやSNSで相手に送るだけなので、とても簡単ですし、なにより会員登録がいらないのが良いですね。
機会があれば、是非使ってみてください。
業務委託と派遣の両方を経験して感じたこと
210日ぶりの更新です・・・。
今の常駐先の病院も、早いもので半年が過ぎました。
今の常駐先と、前の常駐先で何が違うかというと、やはり「雇用形態の違い」です。
今の常駐先は、「派遣契約」、
前の常駐先は、「委託契約」（業務委託）です。
半年間、派遣契約の縛りのなかで働いてみて、両方のメリット・デメリットが多少見えたように思えます。
派遣契約のメリット
指揮命令系統が分かりやすい
病院のシステム担当職員さんが指揮命令権を持っています。他部門の職員さんから、もし無理難題を言われたとしても、システム担当職員さんの権限で、お断りすることができます。
よく言えば、「守ってもらえる」ということでしょうか。
派遣契約のデメリット
個人的にやりたい仕事が通りにくい
自分のやりたい仕事があったとしても、それはシステム担当職員さんの許可がないと任せてもらえません。自部門で完結できる業務は、わりと通りやすいのですが、特に他部門と関わる業務となると、あとでシステム部門に責任を押し付けられる可能性もあり、なかなか難しいところです。
委託契約のメリット
ある程度、個人の采配で動ける
規模の大きな業務はもちろん難しいでしょうが、日常のシステムトラブルの対応であったり、簡単なプログラムやツールを使って、他部門の業務を助けたりなどは、前の病院でよく行っていました。
委託契約のデメリット
業務を遂行することに責任を負う
個人の采配で動くぶん、その責任は当然自分で追わなければいけません。個人の判断で深追いした仕事があり、その障害対応の泥沼にハマってしまったこともありました。深みにハマりそうな案件があったら、危険を察知し、周囲に相談するようにしないといけません。
新年から常駐先が変わります
新年早々、異動になります。
2017年がスタートしました。
年明け早々、僕は異動となります。
1月10日が、今の常駐先の病院の最終日。1月11日から、新しい客先に常駐です。
異動の話なんて、あるとしても年度末だろうと思っていましたが、まさかこんな年明けが異動のタイミングとは思いませんでした…。
まあでも、前任者からの引き継ぎや、新年度からの新規常駐案件のことを考えると、こういうこともあり得る訳ですね。
振り返ってみれば、今の客先に常駐してから、いつの間にか二年と八ヶ月も経っていました。
新たな環境でも、やはり病院情報システムの保守運用がメインになります。
良い機会なので、この二年と八ヶ月で良かったこと、逆に反省すべきことをリストアップしてみました。
良かったこと
- プログラミングの実務が経験できたこと
- 電子カルテのメンテナンス全般を学んだこと
- 医事会計や多くの部門システムに触れられたこと
- FileMakerの作成やメンテナンスを経験できたこと
- 資格試験の勉強が以前より苦しくなくなったこと
反省すべきこと
- 仕事を抱えすぎたこと
- 医事課的な業務に興味が持てなかったこと
- システム開発の技術力向上がほんの僅かしかなかったこと
- 自分の評価を上げたいという意欲がなくなったこと
良かったこと、反省すべきこと、それぞれの詳細を、下記に述べていきます。
