医療情報男の日記

病院で医療情報システムの保守運用の仕事をしています。

第1回中国医療情報技師会に参加しました。

f:id:tkt0314:20160827173003j:plain

 

8月27日土曜日、岡山の川崎医科大学附属病院で、中国医療情報技師会が開催され、参加しました。

これまでは地元の研修会しか参加していませんでしたが、複数の県にまたがる(四国の人も来ていたようです)規模の学会は初でした。

 

午前中はレセプト処理業務があったため、会場に到着した頃には、最初の5演題が終わっており、席もほぼ満席状態。なんとか座れてよかった・・・。

 

最後は、広島大学の津久間先生による、1時間を越す大規模な演題でした。

これからの医療情報技師が果たすべき役割は何かを、ときにユーモラスに、ときに辛辣に、会場の皆さんに熱弁を振るっておられました。

 

 

医療情報技師について

企業所属の医療情報技師という視点では、今回の講師の方々の演題はうなずける点が多々ありました。

お客様である医療機関へ、医療情報技師としてどのような貢献ができるのか。

それは資格を習得した後も考え続けなければならない課題です。

「医学・医療」、「医療情報システム」、「情報処理」の3つの試験科目に合格し、資格証明書をもらうことは、ゴールではなく、むしろスタートなのだと思います。

さらに上級医療情報技師を目指す人はもちろん、医療情報技師の取得後は、いろいろな研修会に参加し、時には自身が演者となって発表し、技師ポイントを集めていかなければ、5年後に失効してしまいます。(5年後に受験し直す手もありますが・・・) 常に自己研鑚し、知識向上を促すシステムになっているわけです。

 

今回の演題で、同じ医療系SEの方が演者で発表されていました。

そのなかで、次の言葉が印象に残っています。

「医療機関が、企業の医療情報技師に求める役割としては、「知識・理解力」「調整・提案力」を持ったSEによるサポートである。」

 

僕は「知識・理解力」も、「調整・提案力」も、まだまだスキル不足だと実感しています。それでも、顧客先に常駐している院内SEという立場上、必ず求められるスキルです。

 

 

「知識・理解力」を強化する

病院業務の知識の習得は、実際にその業務に携わっている人に聞くのがいちばんの近道だと思います。

診療部門の業務となると、全くわからないことも未だにあります。

さらにその部門システムのこととなると、ブラックボックスが多く、こちらでは何も手を出せないケースもあります。

そのような場合もやはり、素直に部門担当者に訊くか、部門ベンダーに訊くのがいちばんです。

すべての院内システムに精通するのは不可能ですから。

 

病院業務については、「わからないことは分かる人に訊く」ができますが、情報処理技術となると、そうはいきません。

逆に院内から毎日いろんな問合せがあり、ググって調べながら対応、ということも多いです。

同じ課の人に訊けば良い話かも知れませんが、自分で調べて答えを導き出すことは、それが知識として定着することにつながるはずなので、「まずは自分で調べてみる」というアプローチは大切だと思います。

 

「調整・提案力」を強化する

業務委託として現場に入らせていただいているからには、通常のシステム保守・運用業務のほかに、新たな提案や問題解決へのサポートもできるようにならねば、と考えています。(通常の業務だけで手一杯なのが現状ですが・・・)

 

「他部門・他職種の利害関係を超え、俯瞰的な視野で物事をとらえ、常に全体最適化を考えて行動できる人材を期待している」と、最後の講演で津久間先生がおっしゃっていました。

また、津久間先生は、医療情報技師育成部会の前部会長である、内藤先生が示された「医療情報技師の3C(Communication、Collaboration、Coordination)」の重要性を説いています。

 

Communication  = 友好的な態度で、他者を理解・許容する

Collaboration  = 組織の枠にとらわれず、協力体制を築く

Coordination  = 他部門・他職種・他企業との調整・折衝を経て、全体最適化を目指す

 

部門や職種が違うと、どうしても他人事のように物事をとらえがちです。

しかし、医療情報技師、院内でシステム担当という立場ならば特に、三次元的な視野で組織全体を俯瞰し、院内全体の問題と捉え、解決していかなければいけません。

 

これらをすぐに実行に移すのは容易ではありません。しかし、「医療情報技師の3C」の理念を忘れず、日々の仕事で少しずつ3Cを実践していきたいと思います。

2016年夏セールの戦利品 その2

今週のお題「セールの戦利品」

Dell Inspiron 13.3型 2in1ノート

今週のお題で、2回目の投稿です。

今回は楽天お買い物マラソンではなく、Amazonプライムセールでの戦利品です。

f:id:tkt0314:20160719074129j:plain

通常119980円のところ、32000円値引きの、87980円で購入できました!

ポチった後で分かったのですが、実は型落ちモデルでした…残念…

スペックは、
CPU Core i 7 6500u
メモリ 8GB
SSD 256GB
FHD光沢モニタ タッチパネル バッテリー駆動時間 8時間

とのこと。

お馴染みのAmazon段ボール箱。 f:id:tkt0314:20160719075538j:plain

デルの箱。 f:id:tkt0314:20160719075735j:plain

取り出してみたら、意外と重量があります。 f:id:tkt0314:20160719075858j:plain

さっそく、Windowsの初期設定。
待機中の画面には、「必要なものがすべてここに」というメッセージ。
なんという万能感。
f:id:tkt0314:20160719075951j:plain

Windowsの初期設定が完了。
f:id:tkt0314:20160719080254j:plain

この後、Visual Studio Community 2015やFirefoxなどをインストールしました。

もともと東芝の中古ノートをメインノートとしていましたが、今後は簡易サーバ的なポジションにします。
部屋にあったタブレットスタンドを使い、傾斜をつけ、スニーカー箱2箱の上に設置。

そして、メインのデルノートを机の中央に設置。

f:id:tkt0314:20160719080812j:plain

今度からは、このデル製ノートで、プログラミングの勉強をしていこうと思います。

ていうか、まだ肝心のOfficeを買ってなかったな…。

2016夏セールの戦利品

今週のお題「セールの戦利品」


アディダス スタンスミスを衝動買い


f:id:tkt0314:20160717112815j:plain


7月上旬、楽天で「お買い物マラソン」という企画をやっていて、そこで衝動買いしてしまったのが、この「アディダス スタンスミス」です。


僕は足のサイズが25.5cm。男性にしては小さい方だと思います。
楽天Amazonでスニーカーを選ぶとき、僕はメンズだけでなく、レディースもチェックします。
メンズで25.5cmで限定して探すと、たいていの場合売り切れていたりします。
レディースの25.5cmなら売れ残っていることが結構あるので、人気商品でも手に入れられる可能性が高いのです。

この「アディダス スタンスミス」は、シンプルなデザインでありながら、非常に頑丈な作りが魅力。
街中でもよく若い人が履いていて、人気があるアイテムだと思います。


商品到着


f:id:tkt0314:20160717111346j:plain

17日の日曜日に商品が到着。


f:id:tkt0314:20160717112815j:plain


シンプルですっきりしたフォルムです。


f:id:tkt0314:20160717112721j:plain


早速はいてみました。しっかりしたホールド感。やはりレザースニーカーはこうでないと。


早速、履いて外に出てみた



f:id:tkt0314:20160717164718j:plain


日曜日の夕方は、県営のスポーツジムに行くことにしています。この日もジムに出かけたので、そこで「アディダス スタンスミス」を初出動させました。Tシャツとジーンズでオーソドックスに。


やっぱり、買いたての靴で外に出るとテンションが上がりますね。

真っ白なこのスニーカーは、夏の強い日差しでよりいっそう白さが映えています。


セールで半ば衝動的に買ってしまったのですが、たとえブームが過ぎてしまったとしても、大事に、長く履いていこうと思います。


2016上半期

今週のお題「2016上半期」


2016年上半期を振り返る


早いもので、もう2016年も折り返し地点。今回は、院内情報システム担当としてだけでなく、私生活も交えて、この2016年の前半を振り返ってみたいと思います。

続きを読む

【C#】作業依頼書システム案件が頓挫した件

はじめに

 
 昨年5月から、ひとりで少しずつ作っていたC#の作業依頼書システムというものがあります。
 この度、その作業依頼書システム作成案件を、いったん凍結することとなりました。
ひとりで開発していくには、色々と足りないものが多かったのです。
 
 

経緯

 
 作業依頼書システムの作成に着手して早1年が経ちました。着手当初は特に明確な納期もなく、業務の隙間時間や、片手間で少しずつ作っていました。
 
 しかし、ついに先日の情報企画課内ミーティングの場で、明確なタイムリミットが提示されることとなりました。
 
 「8月1日までに課内リリース・テスト検証報告が間に合わなければ、この案件は凍結する」とのこと。
 
 もともとは6月1日にリリースする予定で課内には話をしていましたが、5月末時点で、設計の甘さ、保守性の低さが発覚したことや、システムテスト未実施などで、リリースするには至らないと判断。課内ミーティングの場で、課内レビューの中止とリリース延期を伝えました。課内4名には少なからず迷惑をかけてしまったことと思います。
 
 最終的に、院内全体リリースを9月1日とし、先行して8月1日から課内リリースを実施ということが決まりました。課内リリースでは、4名によるテストで、バグや改善箇所の発見・報告をしてもらう予定でした。
 

 

課内リリースまでにやる予定だったもの

 
 課内リリースまでに、「仕様書の作成」・「テスト報告書の作成(テストケースの作成と実施報告)」・「既存コードを共通ライブラリ化」を完了させる必要があります。
 しかしながら、定型業務である毎月のレセプトオンライン請求業務、6月22日締切の厚労省DPC再提出業務、7月下旬締切の厚労省DPC4・5・6月分提出業務の作業ボリュームが相当大きく、近日にはDPC業務システムのアップデート作業、7月1日のシステム委員会と8月19日の電子カルテシステムレベルアップ等、イベントがひかえています。これに加え、毎日の問い合わせ案件の対応があり、作業依頼書システム関連の作業を業務時間内に行うのはかなり難しい状況でした。
 

 

そもそもなぜ作業依頼書をシステム化しようとしたか

 
①手書き作業依頼書の問題
 
 2015年1月に、作業依頼書運用をスタートしました。当初は、紙ベースのままの運用で良いかと思われましたが、下記の問題が発生、これらの解消のために、システム化を計画することとなりました。
 
<問題点>
・手書きの依頼書をいちいちExcel台帳に入力するのが手間
・依頼者は共有フォルダの依頼書Excel原本を操作するので、意図せずレイアウトを変更されてしまう
・依頼書の記入漏れが多い
・そもそも依頼書を書くのを面倒がり、書かずに案件依頼する人が後を絶たない
 
②システム化によるメリット
 
 問題点の解消だけでなく、メリットも多くあります。
 
<メリット>
・依頼者が依頼案件の作業過程・成果物を把握できる
・問い合わせ案件を公開することで、情報企画課の業務を見える化できる
・問い合わせ内容を集計し、ナレッジデータベースへ発展が可能となる
・依頼者が添付資料を紙で印刷・持参する必要がなくなる(添付ファイル保存フォルダで代用可能)
 
③プログラミングスキル習得
 
 開発者である自分にとっても、プログラミングを学ぶ良い機会です。業務システム開発は全くの未経験ですが、実際に手を動かしていくことで、多くのことを学びました。
 
<自分自身にとってのメリット>
SQL Server Management Studio で新規テーブルやフィールドを作成、データ型を決める作業を通じて、データベースの概念、構造を(おぼろげながら)理解しはじめた
Visual Studioを使用したC#プログラム作成の初歩的な部分が(おぼろげながら)理解しはじめた
・DataGridViewを使用した表作成の基礎を(おぼろげながら)理解しはじめた
・データベース接続・テーブル操作の書き方を(おぼろげながら)理解しはじめた
オブジェクト指向を(おぼろげながら)理解しはじめた
・関数、変数、引数の意味を(おぼろげながら)理解しはじめた
・使いやすいユーザインターフェースについて考えるようになった
など・・・
 

 

システム化が頓挫した理由

 
①自分自身で非現実的な納期を設定していた
 
 納期を9月1日としていましたが、今から考えても、相当無理な設定をしてしまったなと思います。
 ただでさえ、レセプト業務とDPC業務で手一杯なのに、さらにこんなカツカツな納期で仕上げようとしていたのですから…
 あと二ヶ月で、既存のクラスの共通モジュール化、ゼロから仕様書を作り、各種テストを終わらせテスト報告書を作り、課内リリースをしようと意気込んでいました。
 しかし、通常業務をこなすだけですぐ夕方になるような毎日です。しばらくは、業務時間外に、終電間際まで自主的にこの残案件を消化していきましたが、すぐに「これはもうダメかもわからんね」と気づいたのです。
 
 
②独りよがりな作りになっていた
 
 最初から、ひとりでC#で作ることは課内に伝えていました。
 しかし、開発手法やスケジュールなどを全く意識せず、いきなりコードを書き始め、Windowsフォームも後先考えず、なんでもとりあえずペタペタ貼り付けていきました。
それがいけなかったのです。
 
今回の件で、後悔したことは下記の五つ。
・もっと早期の段階から課内レビューすべきだった
・まず要件定義書や設計書を作るべきだった
・いきなりコードを書かず、フローチャート画面遷移図などを紙に描いてみるべきだった
・もっと周りに聞けばよかった
・そもそもC#の基礎的な理解が出来ていなかった
 
 ひとまず五つを挙げましたが、実際にはもっと多く出てきます。
 
 これまでC#で業務システムを作ったことがなく、そもそもシステム開発技法を学校で習ったわけでもない、全くの素人です。
 そんな素人が、いきあたりばったりで開発しようとしたわけですから…
 
 それ以上にいけなかったのは、C#の勉強が目的になっていた」ということです。
 
 本来はユーザにとって何の必要もない機能なのに、「自分が使ってみたいから」という身勝手な理由で、どんどん追加していったのです。
 その結果、ユーザにとって非常に使いづらいシステムになってしまったわけです。
 課内レビューではあっという間に50箇所以上の修正箇所が見つかり、いかに自分が好き勝手に作ってきたかが分かりました…
 
 
基本情報技術者試験に合格したことで無駄に勢いづいてしまった
 
 基本情報技術者試験の合格によって、「自分はプログラミングができるんだ」と勘違いしてしまい、その勢いに乗って、無理な納期を乗り切ろうとしていました。
 根性論や精神論を振りかざすのではなく、ロジカルに考えて計画性のある納期設定をすべきでした。
 
 
 

今後の展開

 
①作業依頼書システムのことから離れる
 この案件は会社全体として引き継ぐこととなりました。おそらくいちから作り直しになることでしょう。
 一年もかけてコツコツ作ってきたものを手放すのは惜しいのですが、ここでいったん線を引きます。
 
②既存のVBAやVB6プログラムのメンテナンスを怠らない
 
 今回の案件にタスクを振りすぎて、今動いている既存プログラムのメンテナンス対応が遅れ気味になっていたのは、正直なところあります。
 本来の業務は、既存システムの保守運用のはずです。それらを疎かにしていては院内SE失格です。
 
③自分用の小さなプログラムから始める
 
 C#の基礎すら理解できていないのに、いきなり院内数百人に向けた業務システムを作ろうとした事が間違いでした。
 まずは、自分自身の業務を助けるための、小さなプログラムから作ろうと思います。
 自分しかユーザがいないので、いつでも好きなようにソースコードやフォームを変更できます。
 
 勉強し、力をつけたら、いつか院内向けの業務システムにチャレンジさせてもらえるかも知れません。
 
 今は地道にプログラミングの学習をする期間です。