• 医薬連携とシステムに関する考察

    とある薬剤師による、レセプト、処方せん等の病院と薬局との連携や、そこに介在する電子システムなどに対する考察というかぼやき。
    システム屋として (そして現在病院関係のシステムに片足程度には関わっている者として) も気になる話題だったので、個人的メモとして拾い上げてみました。
    by T_MURACHI
    1 fav 716 view
    このエントリーをはてなブックマークに追加
Fav
  • ALPHA_DRK
    昨今のレセプト請求のオンライン化など、積極的なIT化(これもちと死語だが)が推進されてきたが、それは既存システムの否定という側面が致命的だった。これでは対応できない高齢の医療従事者を切り捨てることになり、実際危ぶまれたので特例免除措置が採られた。
  • ALPHA_DRK
    従来処方せんは手書きだったが、これにはメリットデメリットが多く含まれる。私のような新参者にはデメリットしか享受してないのだが。
  • ALPHA_DRK
    今なお手書き処方せんは健在だ。平素はこれほど面倒なものも無いが、此度の震災のようなケースだと、手書きで処方せんを作成できないとダメ。無論書くだけなんだが、適切に正しく書くというのは、Drからしてみれば面倒で難しいのかもしれない。これは意思疎通の問題も含むが。
  • ALPHA_DRK
    もしシステムを新たに構築するならば、それは「利用者が確実に運用できる」事が大前提だ。どんなに優れたシステムも、使われなければ意味が無い。
  • ALPHA_DRK
    恐らく技術者の方々は一生懸命に優れたシステムを作っているとは思うが、同じぐらいの労力でSOPを作成していかなければならない。そのことの重要性は果たしてどれだけ(技術者側に)理解されているだろうか?
  • ALPHA_DRK
    あらゆるケースを想定するというのは難しい。だが、せめて出てきたエラーダイアログが何を意味するのかぐらいは、説明書に書いておいて欲しい。
  • ALPHA_DRK
    手書き処方せんに話を戻せば、とかく医薬品名がまともに書かれない。剤形が無い、規格が無い、投与日数が無い、挙句の果てには略号使って意味不明。
  • ALPHA_DRK
    「そんな事常識だ。分からないそっちの不勉強だ」と言うDrには、私は掛かりたくないな。致命的にコミュニケーション能力が欠落している。
  • ALPHA_DRK
    手書きだとこういう、「自由度という悪徳」が横行する。やっぱり将来的にはPCを前提としたシステムに移行せざるを得ない。
  • ALPHA_DRK
    医療機関ごとのレセコンシステムのバージョンにも依存させたくないので、ネットワーク更新を自動化出来れば理想的だ。常に新しい医薬品のデータが、正しく入力できる。ありもしない剤形や規格を書く事も無くなる。
  • ALPHA_DRK
    香川で病院と薬局との連携システムを試運転中との事だが、こういった取り組みは是非とも全国的に広がって欲しい。
  • ALPHA_DRK
    もっとも、それは薬剤師の責務が一層大きくなることを意味するが。特に個人情報の秘匿における責任が重くなる。
  • T_MURACHI
    とりあえず SOP を作成するための工数下さい!(当方切実 / Togetter - 「医薬連携とシステムに関する考察」 http://htn.to/AhbNeh
  • T_MURACHI
    ぶっちゃけ、正常な競争原理の働く市場であれば、システム屋はどんなことでも依頼されればやるよ。もちろん、作業に見合った報酬は請求するけれども。
  • T_MURACHI
    手順書つーかマニュアルに求められる品質っていうのも、システム屋がシステム屋の文脈で考える物と、ユーザーがユーザーの文脈で考える物とで齟齬が生じる、なんてのは、どの業界であっても日常茶飯事で、それこそシステム屋からの積極的なヒアリングも、ユーザーからの積極的な主張も、相互に必要。
  • T_MURACHI
    これは例え、オーダーメイドではなく、パッケージ製品であっても本来同じ事で、メーカーはできる限りユーザーの声を吸い上げる努力をすべきだし、ユーザーも「わかりにくいマニュアルだなー」と愚痴って終わるだけで無しに、積極的にクレームをぶつけるべきなんだよね。もちろん限度はあるけど…。
  • T_MURACHI
    (この限度ってのが、難しいんだけどね…) (-_-メ)
  • T_MURACHI
    システムの自由度に対する態度、っていうのも議論がある。これは主に UI の問題なんだけど、自由奔放で困るのはシステムからユーザーに対する「出力」の部分であって、逆にユーザーからシステムに対する「入力」の部分については、極力自由であることが求められたりする。通常はその方が便利だし。
  • T_MURACHI
    例えば処方する薬を入力する場合に、手書きにおいては、一般名で書く人もいれば、商品名で書く人、略名で書く人もいて、分量についても、mg単位だったり ml単位だったり個数、セット数だったりでばらばらだったりする。
  • T_MURACHI
    これ、注文を受ける側としては、ばらばらだと非常に困るんだけど、その一方で、注文する側としては、自分が慣れた以外の方法での記述を強要されると、それはそれで困ってしまう、という物なのだと思う。そこに介在するシステムは、本来それを吸収しうる物でなければならない筈。
  • T_MURACHI
    以上、とりあえず一システム屋の視点で一般論的なことをちろちろ書き連ねてみました。
  • T_MURACHI
    とりあえず目下の問題は字が汚いのをどうにかすることと、停電してもどうにかなる運用ルールの確立なんだろうなぁ… (←いろいろと逆戻り
  • T_MURACHI
    もうちょっと実践的な話としては、薬品名を電子的な識別子 (よーするに ID) に落とし込む方法論として標準的な物に、日本標準商品分類番号とか、薬価基準収載医薬品コードなんてものがあったりするんだけど、 http://bit.ly/gUm4l5
  • T_MURACHI
    これ、少なくとも今おいらが関わっている麻酔記録システムの分野においては、分類のされ方が実際の運用、即ちその薬品が用いられる現実的な用途・目的とは一致していないことが多くて、ID をそのまま分類のための情報として活用しようとすると痛い目見ることになったりする。w
  • T_MURACHI
    まぁ、元より ID と分類を紐づけるようなシステムってのは、運用を不当に束縛する危険性の高いものになってしまうわけで、そういう考え方自体 NG なんだろうけんども、それにしたって…みたいな話。
  • Content from Twitter

コメント

まとめを作成する