2015-12-11

「リアルタイムOSから出発して組込みソフトエンジニアを極める」のその後

このブログを始めたのは、日経BP社から「組込みソフトエンジニアを極める」を2006年に出版したことがきっかけだった。

「組込みソフトエンジニアを極める」は初版が4000部で、約5年半で在庫がなくなった。しかし、このくらいの売れ行きのスピードでは日経BP社としては増版できないという判断になったため、出版社をエスアイビーアクセスに変えて元原稿から編集し直してタイトルも「リアルタイムOSから出発して組込みソフトエンジニアを極める」として2011年10月に改めて出版し直した。

日経BP版の定価が2900円で、エスアイビーアクセス版が1800円。

エスアイビーアクセス版の「リアルタイムOSから出発して組込みソフトエンジニアを極める」は初版1000部で、2016年の上半期(出版したから4年と少し)で在庫がなくなりつつある。

現在、技術書は増版されるかされないかの判断は厳しいらしく、ギリギリまで増版の決定はしないので在庫が少なくなると Amazon でも中古本でしか手に入らないという状況が生まれる。

現在の「リアルタイムOSから出発して組込みソフトエンジニアを極める」がまさのその状態で、Amazon で見ると 中古で4000円台の値が付いている。

それでも楽天ブックスの方ではまだ定価販売されている。

「リアルタイムOSから出発して組込みソフトエンジニアを極める」の今後の増刷は出版社と相談して、オフセット印刷ではなく、オンデマンド印刷にすることとなった。(オフセット印刷とオンデマンド印刷の違い

おそらく1回200部くらいの少量印刷で細々とつないでいくことになる。

印刷費が上がるので、定価は若干高くなる予定だ。

インターネットでかなりの情報が入手できる時代になったが、本を書く側から考えてみると、リアルな技術書として仕上げるということによって掲載される情報が洗練されると思う。

インターネットに挙げる情報はとりあえずでもいいかという気になるが、本にするにはちゃんと裏を取らないとまずいと思って慎重になるので、それだけ信頼性が高い情報になる。

電子書籍もやってみたけれどやはりリアル本がいいなと思うようになってきた。

リアル本を所有して手にとってパラパラめくっているといいアイディアが浮かんだりする。説明するのが難しいが、インターネットで検索して見つけたというのとは何かが違う。

リアル本もまだまだ生き残って欲しいと思う。そのためには読者がリアル本を買い続けてくれなければいけない。

そう考えると自分も最近リアル技術書を買っていないなと思い反省している。

2015-10-18

USのヘルスITの取り組み(11) アメリカのヘルスIT戦略

今回はFDASIA Health IT Report を翻訳するのはお休みして、アメリカのヘルスIT戦略についてまとめてみた。

米国が国民皆保険ではないことはご存じのことだろう。では、米国民はどのような医療保険に入っているのか。

まず、連邦政府が運用主体の保険は、65歳以上の高齢者や身体障害者向けのメディケアと、低所得者向けのメディケイドと、軍隊保険がある。これらの加入率は約27%だ。

軍隊保険についてひとつトピックスがある。2014年に退役軍人病院で待機患者を実際よりも少なく見せるという不正が発覚した。政府はこの問題を受けて退役軍人省の改革法案を成立させ、163億ドルの予算をかけて退役軍人病院の予約システムを改善し遠隔医療サービスの提供を行うこととした。

連邦政府が運用主体の保険制度についてはトップダウンでの改革がやりやすい。退役軍人病院の予約システムの不正の発覚は、ヘルスIT改革を進める上ではちょうどよいきっかけだったのかもしれない。

米国でもっとも加入率が高い医療保険はマネージドケア組織による保険だ。HMO、PPOといったマネージドケア組織は多数の保険加入者を抱えており、グループ内でかかれる医療機関に縛りをかけるなどして患者を抱え込むことで利益を確保している。マネージドケア組織の保険の加入者は約50%である。

次いで、一般保険者が7%、無保険者が16%と続く。無保険者はオバマ大統領の肝いり政策で極力減らす方向に傾いている。

アメリカの診療報酬の支払い方は、1983年より疾患別定額払い制となっており、オバマケアで政府が支払う医療費は治療開始から完治まで一定額で、かつ、その分配さえも医療の供給体制の関係者で決めることになった。

これにより、患者の疾患に対して平均以上の治療効率を挙げなければ病院は利益が出ないようになった。また、疾患に対する診療報酬の分配も自分達で決めなければいけないので、必然的にオペ室も病棟も薬局も協力して無駄を減らし効果を挙げなければいけなくなった。

日本はまだまだ診療報酬点数に基づいた出来高払いが主流だから、やったらやっただけ請求できるのに対し、アメリカでは同じ疾患に対して無駄な診療行為をやればやるほど病院が損するようになっている。

どうしてそこまでやらないといけないのかは、米国の医療関係費用を見れば分かる。アメリカでは2010年の時点で医療関係費用が2.6兆ドルにも達している。

この金額がいかに大きいか日本と比べてみると分かる。先日2013年度の日本の医療費がはじめて40兆円を超えたというニュースが流れた。

米国の2.6兆ドルは今のドル円レートで約310兆円だ。日本の人口はアメリカの1/3くらいだから、日本の人口比でいれば、米国は年間103兆円の医療費がかかっていることになる。
単純計算で日本の約2.5倍だ。GDP比で計算しても、日本の医療費は約6.8%であるのに対し、米国はGDPの約18%だから、日本の2.5倍という数字はだいたい合っていて、アメリカの医療費がいかに高額であるかが分かる。

ちなみに、安倍政権が掲げている新3本の矢の一つ目GDP600兆円を達成した場合、国民医療費40兆円はGDP比で6.6%となり、現状から0.2%しか改善しない。40兆円の医療費は米国よりは小さい数字だけども、この費用を稼ぎ出すのは容易ではないことが分かる。

さて、米国の国民医療費 2.6兆ドルは莫大な金額であることがお分かりいただけただろう。その状況を鑑みてブッシュ政権は2004年に 医療ITイニシャチブを立ち上げた。
  1. 医療の質向上
  2. 医療費の削減
  3. 医療ミスの防止
  4. 医療データの管理コストの削減
そして、国民のほとんどが電子健康記録(EHR)を持つと共に、各自が自分のEHRにアクセスできるようにすることを目標とした。

上記の4つも目標のうち、米国政府が本気で達成しないとまずいと思っているが2の医療費の削減と4の医療データの管理コストの削減だろう。

共和党から民主党に政権が交代しオバマ政権になっても、この方針は引き継がれた。そして、2010年には、退役軍人省とメディケア向けに患者個人が自分の健康記録をダウンロードする仕組みである「Blue Button」が始まっている。1600万人が利用できる。(退役軍人省とメディカとった連邦政府管轄の部分からトップダウンで実現させたところがアメリカらしい)

アメリカの電子健康記録(EHR: Electronic Health Record)を普及させる取り組みは本気も本気で相当気合いが入っている。

2009年に制定されたHITECH法では、医療データの標準化を含めた全米の医療機関におけるEHRの普及を目指している。

その普及のための方法がなかなかすごい。

まず、EHRの導入にあたり、各医療機関や医師を対象にインセンティブ制度を導入し、詳細な要件をクリアした場合、医師では4~6万ドルを、医療機関では200~600万ドル相当を受領できるようにした。これは飴と鞭の飴にあたる。

次に、インセンティブ制度に参加した医療機関と医師には、「有益な活用(Meaningful Use:MU)」という要件を満たすことが求められ、MUの要件を満たさなかった場合にはペナルティが課される。これが飴と鞭の鞭にあたる。

この飴と鞭作戦により、米国の電子カルテの年間成長率は7.1%で世界一位となっている。

有益な活用(Meaningful Use:MU)のステージは3段階あって、現在はMU2まで来ている。2015年度は18億ドルの予算をかけて推し進めている。

MUステージ1の具体的な内容は左記のようになっている。EHRに対する電子カルテソフトに対して、さまざまな要件を満たすことを求め、MUステージ1ではその達成率を低くしておいて、ステージ2、3となるごとに達成率の目標を高めている。

この取り組みを支えるもう一つの仕組みとしてMUのチェックシステムがある。

それがこれだ。一番上にあるONCは医療IT全米調整官室で、ONCが元締めとなり、NIST NVLAP や ONC-AA を使いながら、MUの達成をチェックしている。

デベロッパーは製品を提出し、MUの達成度を調べ、製品認証を行う。

そしてパスした製品はONCによってリストされる。ユーザーとなる医療機関はここにリストされた電子カルテ製品を選択することになる。

興味のある方は、こちらのONCのページの右下に製品リストがダウンロードできるので見てみるとよい。(107Mbyteもあるので注意)

このチェックシステムは ISO 17000シリーズ(適合評価の国際標準)に従っており、勝手に独自の評価方法でテストしているのではない。

この飴と鞭とチェックシステムの戦略と、予算とトップダウンのアプローチにより、米国ではEHRの普及が加速度的に進んでいる。

現在の米国でのEHRソフト(日本の電子カルテソフトとは様相が違うかもしれない)のシェアナンバー1と2はフリーソフトだそうだ。

フリーソフトで広告収入のモデルとなっている。まさに今どきのスタイルだ。

そして小規模な病院ほどWEBベースの電子カルテシステムを選択している。

どのEHRソフトを選択しても、MUの達成率は確保されている(正確にはMUが達成されている製品をユーザーは選ぶ)ので、小規模病院は迷わずフリーソフトを選択するのだろう。

ちなみに、FDSIA Health IT Report にあった、左記のヘルスIT重点分野の外観のうち、3つめの Leverage Conformity Assessment Tools (適合評価ツールの活用)が具体的にどんなものを指すのかずっと疑問だったが、MUのチェックの仕組みを知って、これのことを言っているのだと確信した。

品質マネジメントなどプロセス基準に対する適合評価を推奨しているのだとしたら嫌だなと思っていたが、そうではなく、医療ITの標準を評価するツールのことを指していたのだ。

実際にアメリカで医療ITの標準化のしくみが戦略的に進んでいるところを見ると、このMUのチェックと適合審査のしくみは医療IT標準化の要の役割をしているように見える。

大事なのは、このチェックシステムは主観が入らず、出来ているかどうかを客観的に数字で示すことができることだ。プロセス規格の審査、監査はそもそも合格、不合格のクライテリアが明確でなく、監査管の主観が入るので公正な審査がしにくいし、何しろ時間がかかる。

自動でチェックする仕組みを構築できれば、審査もスムーズだ。逆に言えば、自動でチェックできるようなチェック項目や判定基準を作り出せるかどうかがポイントなのだろう。

そこで、ああでもないこうでもないと議論ばかりしていると、標準化は進まない。それができるかできないかの違いは、リーダーシップを発揮できる国か否かの違いなのだろうかと・・・

さて、米国では今流行りのIoTならぬ IoHT(Internet of Healthcare Things)によって、あらゆるものが医療情報でつながる時代になりつつある。

ちなみに IoT って何でもかんでもインターネットにつなげばいいってもんじゃないと常々感じている。

目的がなくちゃダメだ。つないでから何に使うかは後で考えましょうなんていうのでは大きな社会的な成果にはつながらない。

左の図では医療情報をつなぐことが医療費の削減につながるという目的と結び付いている。

その結果、アメリカではBlue Button を押せば自分の医療データをダウンロードできるようになりつつある。

これはこれから出来ることを考えるとさまざまなサービスにつながる可能性を秘めている。人間、自分の健康には誰もが真剣だ。特に年を取って資産が増えた頃に病気になったりする。過去の医療データが自分の手元にあれば、自分で自分の病気のことを調べることもできるし、病院や医師を選択する元となる情報となる。

また、普段の食事や生活習慣について、適切なアドバイスを専門家にインターネット経由で尋ねることもできる。健康という目的は健康を損なったときにはじめて真剣に考えるテーマだと思う。

これは個人の健康管理の流れをかかる費用との関係で示したモデルだ。

人は年を取っていくと病気になる。症状が現れるまでは、健康管理は自己負担で行っており、症状が出てくるとかかりつけのクリニックや病院で外来の診察を受ける。

その後、病気が悪化すると入院し、手術をしてリハビリし、退院する。

退院後は再発防止のため、通院をする。

国は入院時の医療費を削減するため疾患別支払いを推し進めたいと考えるだろう。そうなると、米国の場合と同様に、医療機関は治療効果のある機器やソフトウェア、運用効率を高めるシステムに投資をするようになる。

安ければ売れるのではない。疾患別で報酬が決まってしまうのなら、早期退院に貢献できる機器、システムの方が選ばれる。なんちゃって製品は買われない。実力が伴う製品が買われる。

左の図は、健康寿命以上の人口比率の推移を世界標準と各国で比べたものだ。

健康寿命とは介護の手助けの必要がなく自立して生活できる年齢だから、それ以上ということは、介護が必要な人口の比率ということになる。

一番左が世界の平均で、2015年段階では世界平均の約12%が介護が必要な人口の比率である。

日本の介護が必要な人口比率は今は世界平均に近いが、今後2020年、2030年、2040年と進むにつれて、その比率はどんどん高まっていく。

アメリカの伸びは緩やかだが、中国を見て欲しい。中国は2020年以降、急激に介護が必要な人口の比率が高まる。

国民の医療費の問題は先進国だけの問題ではない。新興国ほど今後の負担が深刻になる。新興国は人口が多いから介護が必要な絶対数が飛躍的に増えることになる。

 今、Health IT絡みで新規参入を画策している企業がたくさんあるが、そういう企業には左の図を見て欲しいと思う。

各国は医療費の削減が命題となっている。介護が必要な人の割合が増大することは分かっているから、各国とも国の診療報酬は診断群別の包括支払いに移行していくことはまず間違いない。

さらに、米国はインセンティブやペナルティを使って、医療費を削減するシステムに投資が進むように相当な国家予算をかけて導いている。

国民の医療費の削減は国家最優先の課題になっている。今後のヘルスIT業界にとっての最大のステークホルダは国だと思う。

次に医療機関は国の政策により、患者の在院日数を削減させ、かつ病医院運営を効率的にする危機やシステムに投資することになる。

予算は国家予算ほどではないが、医療機関の予算規模はそこそこ大きい。ただし、仮に安価なシステムを導入しても、治療効果が低い、また、実質的な運用効率が高まらないと、診療報酬が一定なので病院がつぶれてしまう。病気が治らないまま患者を放り出すことはできないので、治療効果が高く、運用効率が上がる機器やシステムでなければ、受け入れられないようになる。

最後に、個人としてステークホルダを考える。個人の予算は国や医療機関の予算に比べて極めて小さい。Nが大きく、5億人が医療モバイルアプリを利用すると言われているが、健康な人や大きな疾患を持っていない人がどれだけ医療モバイルアプリに投資をするだろうか。

数百円のアプリをいくつか買ったことがある。それっきりで使っていない。血圧や体重を管理するアプリは使われるだろうがそのアプリの利益を集めても大きなものになるような気がしない。

数は多いが数百円、数千円のヘルスアプリに投資する個人は、ゲームのアプリを買うのと同じ程度の利益にしかならないように思う。射幸心の代わりに健康に対する危機感を煽ってみても爆発的には売れず、しばらくするうちに使われなくなるのがオチだろう。

ヘルスケア、ヘルスIT産業に首を突っ込もうと考えている人々は、はやり国や医療機関といったステークホルダが何を目指しているのかをよく考えた上で、個人へのサービスとして何を提供すべきかを考えた方がよいと思う。

これから求められるヘルスIT・ヘルスソフトウェアとは、やはり基本は治療効果に貢献するソフトウェア、医療費削減に貢献するソフトウェアシステムだと思う。

それを実現するためのキーポイントはリスクベースドアプローチとインターオペラビリティ(相互運用性)であり、アメリカはそれをMUのステージを設定することでトップダウンで推し進めている。

インターオペラビリティが進み、IoHT が普及すると、自分の健康情報をダウンロード出来るようになり、それがきっかけになってさまざまなサービスが生まれる。

個人が持っているスマホやタブレットに搭載するヘルスアプリと、特定企業が提供するクラウドサービスといったちまちました範囲のビジネスは、世界で増大する医療費の削減目標から考えると何の効果ももたらさないように思える。

活動量計とスマホで健康管理というが、それが国民の医療費削減にどれだけ貢献するのだろうかと思う。

介護人口が20%を超えるような時代に必要とされる機器やヘルスソフトウェアを考える必要があると思う。

なお、必要な技術として掲げたリスクベースドアプローチをソフトウェアで実現するときに、一般的なソフトウェアの品質向上技術と同じだと思っていると大間違いなので注意が必要である。

【今回の記事の参考文献】

米国における医療ITと関連分野における取り組みの現状
ニューヨークだより 2014年11月, JETRO/IPA New York, 八山 幸司
http://www.ipa.go.jp/files/000042853.pdf

米国における医療分野のIT導入に係る動向
ニューヨークだより 2012年5月, JETRO/IPA New York, 和田 恭
https://www.ipa.go.jp/files/000001951.pdf

日医工ジャーナル 2014.10-2015.1
米国の医療保険制度の現状と日本の保険制度、医療機器開発の行方、渡辺 幸子

新訂版 医療情報システム入門, JAHIS, 社会保険研究所

FDASIA Health IT Report http://www.fda.gov/downloads/AboutFDA/CentersOffices/OfficeofMedicalProductsandTobacco/CDRH/CDRHReports/UCM391521.pdf

2015-10-09

機能安全のバカ

機能安全は安全について間違った認識を植え付ける元凶となっている。これは事実だ。だから、表題で機能安全のバカと書いた。

先日、あるソフトウェアミドルウェアメーカーがソフトウェアを売り込みに来た。営業技術という肩書きだったと思う。

「この商品はISO26262の機能安全の認証を取っているんですよ。」という。そして、IEC62304の認証も取る予定ですと来たから、「IEC 62304 の対象は医療機器ソフトウェアだから、部品で認証を取ることはできない。」と指摘した。

寝耳に水だったようで、キョトンとされてしまった。IEC 62304 医療機器ソフトウェア-ソフトウェアライフサイクルプロセスは、ISO 13485 と ISO 14971 を引用規格としている。引用規格というの参照しているという意味ではなくて、IEC 62304 に適合するということは、引用規格にも適合していることを求めるということだ。

ISO 13485 は ISO 90001 の医療機器バージョンだから、まあよいとして、ISO 14971 は医療機器のリスクマネジメントの規格であり、医療機器の世界で誰もが知っている規格だ。

ISO 14971 のリスクマネジメントでは、当該医療機器に関して意図する使用を定め、そこから想定される危害や危険状態を分析し、リスクを評価して、対策する。

要するに何をするものかを最初に定義せずして、リスク分析はできない。それなのに機能安全バカは、何に使うものかを想定せずに IEC 62304 に適合できると言う。

ようするに、ペースメーカに使うも体温計に使うのも同じように安全を実現できると言っているのと同じだ。じゃあ、車の場合は、どんな部分に使っても認証取っていれば安全で事故には結び付かないのかと思う。

これは、IEC 61508 や ISO 26262 が高いSIL, ASIL に対して、ツールやソフトウェアアイテムの認証を推奨したことの弊害だ。

その結果、信頼性と安全性を混同する輩を生み出し、「信頼性が高ければ安全なんです」とのたまう営業員を作り出した。

このしっぺ返しは、自動車業界で5年後、10年後に必ずやってくる。電気自動車や自動運転が実用化されるようになれば、信頼性と安全性が異なることから来る複雑で原因が分かりにくい事故が増えてきて、機能安全が誤解を生む弊害を作ってきたことが分かるに違いないと思っている。


これに関連する話題で IPA が「つながる世界のセーフティ&セキュリティ設計入門」という冊子を出した。ダイジェスト版が公開されている。

ここにも機能安全に偏った記述がある。

p20  (3) セーフティ機能とセキュリティ機能の高信頼化の重要性
前述のリスク低減プロセスにおいて、STEP1の本質的安全設計やリスク回避後、STEP2 でセーフティ機能とセキュリティ機能によりリスク対応する場合、その機能自体が故障したり、誤動作したりするようではリスクを低減できません。そのため、セーフティ機能セキュリティ機能に対しては、より品質の高い設計が必要となります。
セーフティをセキュリティを分けていることはよいとして、セーフティやセキュリティの対策を機能と捉え、それらは高品質設計で実現できるように書いてある。それが機能安全かぶれの思考だ。

セーフティは目標や状態のことであって機能ではない。この冊子はIEC/ISO Guide 51 を参照しているにもかかわらず、セーフティの定義が正しく理解されていない。

セーフティ(安全)とは,〔ISO/IEC GUIDE 51:1999〕※1 によれば,『受容できないリスクがないこと』と定義される。すなわち,セーフティ(安全)は受け入れ不可能なリスクから解放されていることであり「受容できないリスクがない」または「許容可能リスク」が達成されていることをもって「安全」と規定される。

安全はリスクを経由して定義され,リスクはその時代,社会の情勢,環境によっても変化するため安全の尺度を一定にすることはできず,絶対的な安全を定義することはできない。そのため,製品,プロセスまたはサービスは相対的に安全であるとしか言えない。

安全は,リスクを許容可能なレベルまで低減させることで達成される。許容可能なリスクは,使用者の利便性,目的適合性,費用対効果,並びに関連社会の慣習のように諸要因とのバランスで決定される。したがって,許容可能なリスクは常に見直す必要がある。技術及び知識の両面の開発が進み,製品,プロセスまたはサービスの使用と両立して,最小リスクを達成できるような改善が経済的に実現可能になったときは,特に見直しが必要である。

これを説明するのにいつも上記のスライドを使っている。

機能安全に毒されている人間は安全を機能で実現できるという方向に持って行こうとしていて、得意のソフトウェアの品質向上プロセスのアプローチに引き込もうとする。

p12 のペースメーカの誤動作の例では、、「健康や生命に関わるために故障時にも止まることが許されないものも存在します。その場合は通常のセーフティよりも強化された二重、三重の対策が求められることもあります。」などと書かれているが、通常のセーフティよりも強化された・・・というところが、セーフティとリスクの関係について理解できていない。

「健康や生命に関わるために故障時にも止まることが許されないものも存在します。」これは正しい。しかし、その後の「その場合は通常のセーフティよりも強化された・・・」がいけない。

医療機器のリスク分析では最初に意図する使用(Intended Use)を定義し、それを元に Hazard(危害の潜在的な源) や Hazardous Situation(危険状態) や Harm(危害) を想定する。

この際にペースメーカが止まるという危険状態の危害として、患者の死が想定され、設計上の対策として問題発生時には定時ペーシングを確保するような対策が取られる。

「健康や生命に関わるために故障時にも止まることが許されないものも存在する。」というフレーズは、リスクに対する対策は想定されたリスクによって変わるので、リスク対策を決め打ちしてはいけないことを注意するために使うフレーズなのに、その意味を十分に理解せずに、「対策は足らなければ強化すればよい」と言ってしまっている。

リスクは危害の重大度や危険状態が発生したり、危険状態が危害に至る頻度(確率)で評価するのであって、リスク対策を先に考えてはいけない。なぜなら、リスクが許容できるかどうかは「使用者の利便性」「目的適合性」「費用対効果」などの諸要因のバランスで変わってしまうからだ。最初に機能を持ってくると、進化した技術の適用やアーキテクチャを見直す対策などが飛んでしまう危険性がある。

「通常のセーフティ」とか「二重、三重の対策」といった言葉が出てくるのは、安全は機能で実現できるという思い込みがあり、リスク分析の概念が十分に理解されていないからだと思われる。

原発も同じ。安全対策に焦点を当てるのではなく、危害の重大度と危険状態や危害に至る発生確率を考えないといけない。安全対策を強化すれば、安全が実現できると主張することで、結果的に危害の大きさから、人びとの目をそむけてしまう。

まず考えなければいけないのは、危害の大きさと、危害状態に至る確率や危険状態が危害に至る確率だ。

原発の場合、危害が破滅的であることが分かっている。危険状態に至る、危険状態から危害に至る確率はゼロでないことが実際に事故が起こったことで分かった。まずは、初心に返って危害がいかに大きいかということと、危害の発生確率、頻度が変わったことをどう考えるのかを評価しなければいけない。

安全対策に焦点が当たってしまうと、事故が起こったら安全対策を強化すればよいと考えてしまい、危害の潜在的源を取り除くという思考を遠ざけてしまう。

安全対策にばかり視点がいくと、危害の大きさの認識が薄れてしまうことがお分かりだろうか。

だから、機能安全はたちが悪いのだ。

リスクコントロール手段はそれを追加したことによって発生するリスクを考慮をリスクマネジメントの中で求められる。(ISO 14971より) 

実際にそういうことがあるからだ。よかれと思ってリスクコントロール手段を追加したら、別な問題が起こってしまうということがある。

リスコントロール手段を冗長設計だけしかないと思っているとこういう思考になる。冗長設計はシステムの複雑性を生み、テストケースを増やし、システマティック故障を起こしやすくなるため、場合によっては冗長設計はやめてシンプルな構造にして信頼性を高める設計を採る場合もある。

総じて、ソフトウェアの品質向上プロセスで推そうと考える人達は、リスク分析やリスクベースドアプローチの概念が抜け落ちている。

p6 セーフティとセキュリティの設計の見える化の必要性
本書でいう「セーフティとセキュリティ設計の見える化」とは、複雑になりがちな安全対策やセキュリティ対応などを、第三者にエビデンスを使って論理的に説明できるようにすることを指します。見える化の目的としては、設計開発支援、第三者認証や国際規格の取得などが挙げられます。
結局、この人達は、利用者の安全が真の目的ではなく、設計開発支援や段三者認証をやりたいからこういう読み物を作ったんでしょということだ。

安全やリスクマネジメントとソフトウェアを絡めて研究する学問が成熟していないから、こういうものが出てくるんだなと思う。

アカデミアの皆さんにはそういう研究分野を立ち上げて欲しいと切に願う。

P.S.

本文と全く関係ない話・・・

10年前に書いて日経BP社から出した本「組込みソフトウェアエンジニアを極める」は絶版になり、「リアルタイムOSから出発して組込みソフトエンジニアを極める」として再版した。

Amazon の読者感想で下記のような記述があり、著者としてそういう風に考えてもらえたのがとてもうれしかった。
開発年数の浅い私(2年目)ですが、少しずつ出来ることから実戦していこうと思いました。
また、上手くいかなかったときや落ち込んだとき、この本を読み返して、モチベーションを高めています。
そう思ったら、最初の本を書いたときに、この本を紹介するサイトを作って日経BPのサイトにおいてもらったものがまだ残っていることを思い出した。

たまたま、読み返したら良く出来ていたので、みなさんにも紹介したい。

この紹介サイトは登場人物が本の物語の中で、それぞれ視点で何を考えていたのかをザッピングできるような仕掛けや、本を出版するまでの著者の日記などが書かれていて、今考えるとよくこんなサイト作ったなと我ながら関心した。(本の紹介サイドは全部自作で制作費はかかっていない)

2015-08-26

要求分析と安全設計との関係(機能安全の致命的な欠陥)

日本の組込み系のソフトウェアエンジニアに担当製品に対するユーザー要求は何かを聞くとすぐさま答えられないことが多い。

顧客の要求に基づき日々ソフトウェアを開発しているIT系のソフトウェア技術者には驚きかもしれないが、事実そうなのだ。

なぜ、組込み系のソフトウェアエンジニアは自分の製品のユーザー要求を答えられないのか。それは、過去の製品のソフトウェアを追加、修正しながら新しい製品を作っているから、大元のユーザー要求を把握していなくとも、製品開発が出来てしまうからだ。

継承するソフトウェアの中に基本機能、基本性能がすでに入っているから、付加機能を付け足すぶんには元の要求を知らなくても作業はできるのだ。

さながら、老舗旅館の旧館、新館、別館、アネックスといったようなもので、結果、継ぎ足しで成り立っている迷路のような構造になることもしばしばだ。

継ぎ足し、修正ばかりやっているソフト技術者はユーザー要求は即答できなくても、機能については詳しいし、饒舌に説明できる。

さて、この機能仕様ドリブンのソフトウェア設計は、安全を考慮しなければいけない機器にとっては、致命傷になる危険がある。

なぜか。ひとつはソフトウェアシステムが複雑化していった際に、機能同士が背反する関係になる可能性があるからだ。よかれと思って付けた付加的な機能が、基本機能に悪い影響を与えることがある。

医療機器の世界では、リスクコントロール手段を設計する際には、リスクコントロール手段によって生まれる新たばリスクを分析せよという規格要求がある。

例えば、異常を検出するハード・ソフトを追加して、異常検知したら装置を停止するようにしたとする。異常は滅多に起こらないから問題ないと考えて、十分な負荷試験をせずにリリースする。確率は低いものの、異常の誤検知が起こり正常なのにシステムが止まることがあったとすると、ユーザーからの大クレームになる。リスクコントロール手段を追加すると、何かしら別のリスクが生まれるのだ。

多くの自動車の部品屋さんは、自分の部品に故障検出回路を付けることが機能安全に貢献し、ASIL-D を満たせるのだと言っているようだが、それって本当に木を見て森を見ずだと感じる。故障検出回路という山火事検知装置に対処するソフトウェアを大量に追加することによって、森の複雑度はどんどん上がっていき、本当に火事が起こったときに消防隊が現場に行くための経路が分かりにくくなる、これが機能安全の致命的な欠陥だ。(何の危害を防止するためのリスコントロール手段か分かっていないで安全に貢献するはずだと思い込んで機能を追加しようとするとこうなる)

「これからは故障検出を追加してシステムを冗長にし、動作し続けることが重要だ」といった意見を聞くことがある。冗長設計は安全設計の方法のうちのフォールトトレランスに分類される。安全を実現するための方法の一つだが、欠点はシステムを複雑にする点だ。システムが複雑になると、レアなテストケースが出てきて、滅多に起こらないシーケンスで不具合が作り込まれる危険性が生まれる。ハードウェアならば安い部品を冗長化するよりも高信頼性部品を使って、シンプルな構造にする方を選ぶこともあるだろう。ソフトウェアならば、シンプルなアーキテクチャにして、テストしやすくするという選択肢もある。冗長化すればいいというもんではない。何を防ぎたいのかを頭に置いた上で、ハード・ソフト含めどんな安全設計が最適かを選ばないといけない。フォールトトレランスだけが解決策だと思っていると、システムの複雑化からくるリコールのリスクを負うことになる。

こういったシステムの複雑化に伴う問題を最小限に抑えるためには、システムに対するユーザー要求をしっかりと優先順位を付けて分析しておく必要がある。重要な要求とあってもなくてもよい付加的な要求は分けて認識しておかないといけない。そして安全に関する要求など、重要な要求は常に優先度の高い要求として認識しておく。要求の優先度を十分に理解した上で、アーキテクチャ設計を行い、安全アーキテクチャは機能を付加しても崩さないようにしないといけない。

複雑化の影響を自動車で言えば、プリクラッシュセーフティをエンジニアが基本機能に対する付加機能だと考えていると危ないなあと思う。

「障害物を認識したら、自動でブレーキを働かせるという機能を基本機能に付け加えて実装すればよい」と考えるのは危ないと思うのだ。

ユーザーが自動車に求めていることは何か。移動や物の運搬が真の目的なら、どこでもドアが発明されたら、自動車は必要なくなる。(論理が飛躍していると思ったらこちら「洗濯機メーカーは洗濯機を開発してはいけない」を参照のこと)

移動する(安全に移動する)ということはどういったことか。移動したいというユーザー要求はある。ただ、その裏側には安全に移動したいという潜在的な要求がある。移動する時に10回に1回怪我をするようなことはゴメンだと誰もが思うだろう。

安全に移動するという要求を実現する手段に自動車があると考えておくと、システムが複雑化して難しい判断に迫られたときに、答えが見えてくる。

さて、どこでもドアはまだ発明されないとして、移動、運搬をする際に、自分や他人や他の車、設備に損害を与えたくないと誰もが考える。特に、自分自身や他人を傷付けたくない。自動車は運動エネルギーを持って動くのでリスクの潜在的な源(ハザード)を持つ。

プリクラッシュセーフティ機能が稼働するシーンはさまざまある。自動ブレーキを働かせたことで、後続車両から追突されたら、結果的に搭乗者の安全は確保されないかもしれない。(「ISO 26262との向き合い方 (11) ASILの分解は本当に可能か」を参照のこと)

このケースでは「プリクラッシュセーフティ」という機能を実装することを目的にしてはいけない。安全に移動するという要求を満たすために何をすればよいのか、今の技術で何ができるのかを考える。機能より要求は上位にあり、要求はよっぽどのことがないと変わらないが、時代とともに技術は変わっていくので、要求を満たす技術はその時々で変化していく。技術やユーザーの意識の変化によって要求を満たせるレベルも変わっていく。

機能だけに着目していると、その上位にある要求が満たせていなかったり、要求のレベルが変わっていることに気が付かない。

また、機能を追加すればよいと考えていると、安全に対する優先順位が分からなくなってしまう。「機能」のことだけ考えていると、そのシステムに求められる本質的な要求が飛んでしまい、本質的な要求に背反するようなシステムを作り込みかねない。

障害物を発見したらブレーキを作動させるという機能を追加しようとすると、搭乗者の安全を確保するという要求が飛んでしまう。(通常は安全に寄与するが、別な条件では安全を脅かすというケースで、大抵は確率が低いから、事故が起きてから分かる。)

だから、ユーザー要求に基づいたバリデーションが大事なのだ。分業が進んでいる欧米のソフトウェア開発では、バリデーション、バリデーションとこればっかり言われることがある。少人数で人の入れ替わりがほどんどない日本の伝統的な組込みソフトウェア開発では、プロジェクトメンバーみんなが言われなくてもユーザー要求は常に頭の中にあるので、何を確認すれば妥当性を確認できるのか分かっていた。

問題が起こる確率は低いから、漏れなく妥当性を確認することに超したことはないが、必ず漏れはあるので、最も起きてはいけない問題から順にそれらが起きないことを確認していく。そうすれば、問題が起きても大問題ではなく、小問題に押さえ込むことができる。ゼロにしようと思うと穴が生まれる。

私は私、あなたはあなた、私が作った物の責任は私が取るが、あなたが作ったものは知らないというシステムでは、ユーザー要求に基づいた、妥当性確認を行わないと、要求と背反するような物になっている危険性がある。

大規模化したソフトウェアシステムにおいて、日本の多くの組込みソフトがトップダウンで十分な要求分析を経て開発されていないとすると、その危険性が増大する。

じゃあ、どうすれば良いかと言えば、今ある機能や性能を整理しながら、ボトムアップで要求がなんであったかを分析し、概ね要求が洗い出せたら、今度はトップダウンで機能を見直してみる。

こうすれば、アーキテクチャのリファクタリングもできる。

安全に関係しないところであれば、複雑になろうが結合が強かろうがいいだろう。しかし、安全に関わるアーキテクチャは要求がキチンと分析されていないと、機能追加で崩される危険がある。

崩そうと思って崩すのではないからたちが悪い。自動ブレーキの命令をソフトウェアが出せるようになったことで、ネットワーク越しでの自動ブレーキが可能になり、ハッカーにつけ込まれるかもしれない。

ナビの情報と自動ブレーキを組み合わせれば、便利な機能を付加できるかもしれない。しかし、そのお陰で自動車の基本機能や基本性能に悪い影響を与えるかどうかを考えないといけない。

その判断をするためには、システムに対する要求を正確に分析し、要求分析内容が常に確認されている(バリデーションされている)状態にしておかないといけない。

機能を追加してリリースすることがソフトウェア開発だと思っていると、システムが複雑化する中で安全を確保することはできない。

2015-08-15

USのヘルスITの取り組み(10) インターオペラビリティ(相互運用性)

5.2 Identify, Develop and Adopt Standards and Best Practices
5.2 識別と開発、標準の採用とベストプラクティス

 The identification, development, and adoption of standards and best practices are a key aspect of a health IT framework that promotes innovation and protects patient safety.
 識別と開発、標準の採用とベストプラクティスは革新を促進し、患者安全を保護するヘルスITフレームワークのキーとなる側面です。

Consensus standards, developed through a collaborative, evidence-based, fair, open, and impartial process, provide requirements, specifications, guidelines or characteristics that can be used consistently to ensure that products, processes and services are fit for their purpose.

協力的で、証拠に基づいた、公正で、オープンで、公平な過程で開発された合意基準は製品、プロセス、およびサービスがそれらの目的に適しているのを保証するのに一貫して使用できる要件、仕様、ガイドラインまたは特性を提供します。

Best practices are processes or methods that have been demonstrated to deliver consistently superior results.
ベストプラクティスは、一貫して優れた結果を提供するために示されたプロセスまたは方法論です。

Like standards, best practices can be used to promote and maintain consistency and quality.
規格のように、ベストプラクティスは一貫性と品質を促進して、維持するの使うことができます。

Importantly, both standards and best practices allow health IT developers to vary their product design, function, features and development approach, and organizations to tailor their methods and processes to their needs.

重要なのは、規格とベストプラクティスの両方がヘルスIT開発者に彼らの方法とプロセスを彼らのニーズに適合させるように、プロダクトデザイン、機能、特徴、開発方法、および組織を変えることを許すということです。

Standards and best practices can set the minimum expectations necessary to achieve an acceptable level of performance and can serve as a guide for achieving performance excellence.

規格とベストプラクティスは(組織の)能力のレベルの受け入れを達成する必要な最小の期待をもたらすことができ、(組織の)能力の優れているところを達成するためのガイドとして役立ちます。

Many existing domestic and international consensus standards address key aspects of product quality, performance and safety, are relevant to health IT, and have been developed with the participation of FDA, ONC, FCC, AHRQ, other government agencies, and key health IT stakeholders.

多くの既存の国内的、そして、国際的な合意基準は、製品品質、性能、および安全といった重要側面に立脚しており、ヘルスITに関連していて、FDA、ONC、FCC、AHRQ、他の政府機関、および主要なヘルスITステークホルダが参加して開発しています。

A number of additional existing standards may be applicable to health IT including but not limited to those pertaining to quality management systems, risk management, interoperability, and software development, validation and lifecycle management.

いくつかの既存の標準は、品質管理システム、リスクマネジメント、インターオペラビリティとソフトウェア開発、バリデーションとライフサイクル管理に関係しているそれらを含むがこれに限らずヘルスITに適用できる場合があります。

ONC has responsibility for advancing the development, adoption, and implementation of health IT standards nationally through public and private collaboration.

ONCは公共のまた個別の協業を通して、全国においてヘルスIT標準の採用と実現を進めることに対する責任があります。

The HITECH Act established the Health IT Standards Committee, which serves as a forum for the participation of a broad range of stakeholders to provide input on the development, harmonization, and recognition of standards, implementation specifications, and certification criteria necessary for the development and adoption of a nationwide health IT infrastructure that allows for the electronic use and exchange of health information.

HITEC法は、ヘルスIT標準委員会を設立しました。そして、委員会は健康情報の電子使用と交換を考慮に入れる全国的健康IT基盤の開発と採用のために標準、実施仕様と必要な証明基準の開発、調和化と認知に関して入力を提供するステークホルダの幅広い範囲の参加のためのフォーラムとして用いられます。

5.2.1 Interoperability
5.2.1 相互運用性(インターオペラビリティ)

Interoperability supports improvements in safety, encourages innovation and facilitates new models of health care delivery by making the right data available to the right people at the right time across products and organizations in a way that can be relied upon and used by recipients.


相互運用性(インターオペラビリティ)は安全の実現を支えて、革新を促して、利用者が使い信頼できる方法で、製品や組織を超えて、適切な時刻情報で適切な人々に対して適切なデータを作ることによって、新しいヘルスケアを提供するモデルを促進します。

Interoperability permits electronic communication between software applications and across medical devices and electronic health records thereby supporting innovation that can only occur when the data is not “siloed” in one product, technology or system.

インターオペラビリティは、データが製品や技術やシステムに貯蔵されないということに対する革新を助けて、ソフトウェアアプリケーションと医療機器や電子健康記録を横断して電子的なコミュニケーションを可能にします。

In addition, it promotes system integration even when products from different vendors are used, and can improve data portability and patient safety.
これに加えて、異なるベンダーの製品が使われるときでも、システム・インテグレーションを促進して、データ携帯性と患者安全を改善することができます。

Errors in communication due to inadequate interoperability, such as the transmission of test results inaccurately or for the wrong patient, do occur and can lead to patient harm.

不十分なインターオペラビリティ(例えば不正確に、または、患者間違いの検査結果の伝送)のためのコミュニケーションにおけるエラーは、発生して、患者の有害事象につながる可能性があります。

Improved interoperability among health management health IT systems, medical devices and administrative systems could catalyze innovation in the health IT marketplace, better support emerging care models, and create greater marketplace competition and responsiveness to end-user needs.


健康管理健康ITシステム、医療装置と行政システムの間の改良されたインターオペラビリティは、ヘルスT市場で革新の触媒となることができて、よりよい新しいケアモデルをサポートし、より大きな市場競争とエンドユーザーニーズの反応を作り出すことができます。。

The Agencies have actively fostered the secure and seamless exchange of health information, but challenges remain.
関係政府機関は健康情報の安全でシームレスな交換を精力的に促進しましたが、まだ課題は残っています。

This risk-based health IT framework should promote interoperability and electronic information sharing between health IT products and across organizational boundaries.
このリスクベースのヘルスITフレームワークは組織境界を超えてヘルスIT製品との間で、共有される相互運用性と電子情報を促進するべきです。

The FDASIA Workgroup recommended that interoperability of health IT could be addressed, in part, through adoption of standards.
FDASIAワーキンググループは 標準の採用を通して、部分的に、ヘルスITのインターオペラビリティを推奨しました。

Standards-based interoperability could facilitate new and innovative health IT products and solutions tailored to address users’needs.
標準に基づいたインターオペラビリティは新しく革新的なヘルスIT製品とユーザーニーズに根ざして適合させたソリューションを提供することができます。

Fostering the development of interoperable products and systems, in part, requires the creation, validation, and recognition of common standards across product categories.
相互運用できる製品やシステムの開発の発展は、新たな創造、バリデーション及び製品カテゴリを横断した共通基準の認識を一部必要とします。

ONC has broad responsibility for adopting standards, implementation specifications, and certification criteria for health IT in conjunction with its voluntary certification program, as well as leading policy efforts to effectively encourage and coordinate nationwide health information exchange activities.
OCNには、全国的なヘルスインフォメーソンの情報交換活動を効果的にコーディネイトし、奨励するための政策活動と同様に、標準の採用、仕様の実装、自己認証プログラムに関連したヘルスITの適合の判定に対する広い責任があります。

ONC adopts standards for health IT through regulations and leverages public-private collaboration to identify and specify standards and implementation specifications that could be used through the Standards & Interoperability Framework activity.

ONCは、規制を通してヘルスITのための基準を受け入れ、標準化や相互運用フレームワーク活動を通して使うことのできる仕様の実装や、標準や実装仕様の特定のために公共と私企業のコラボレーションを促進します。

In 2012, FDA and the Association for the Advancement of Medical Instrumentation (AAMI) organized a summit that brought together hundreds of experts from many disciplines to further the goal of improving patient care and fostering innovation through interoperability.

2012年にFDAと医療器具開発協会(AAMI)は、インターオペラビリティを通した革新の促進と患者ケアの改良を目標として、多くの領域から何百人もの専門家を集め、サミットを開催しました。

FDA has since recognized a set of voluntary standards pertaining to interoperability and cybersecurity that will help medical device manufacturers create secure devices that work well together and with other health IT products and systems.

FDAは、以後、医療機器製造業者が他のヘルスIT製品やシステムとともに上手く働くセキュアなデバイスを作成するのを助ける、インターオペラビリティとサイバーセキュリティに関係する1セットの自主基準を推奨しました。

In February 2014, ONC co-hosted Health Care Innovation DC:
2014年2月に、ONCはHealth Care Innovation DCを共同開催しました:

Igniting an Interoperable Healthcare System, a conference to provide a venue for stakeholders to collaborate and partner on solutions to achieve interoperability in ways that improve patient care.

相互運用ヘルスケアシステム、患者ケアを発展させる方法において相互運用を達成するソリューション上の協業や提携のためのステークホルダの場を提供するカンファレンスでした。

The Agencies recommend that entities be identified to develop tests to validate interoperability, test product conformance with standards, and transparently share results of product performance to promote broader adoption of interoperable solutions.

関係政府機関は、相互運用の妥当性を確認するテストを開発し、規格に適合する検証プロダクツや、相互運用のソリューションを受け入れ基準を満たす製品性能結果の透明性高く共有することを推奨します。

Conformance with recognized consensus standards can be used to meet certain regulatory requirements.
認知された合意標準への適合は、規格要求を満たすことで表すことができます。

The concept of conformity assessments is discussed in more detail in Section 5.3.
さらに詳細にセクション5.3で適合性評価の概念について議論します。

2015-07-26

サイバーセキュリティで初の自動車のリコール

ロイターの記事によると、24日にフィアット・クライスラー・オートモービルズが米国で140万台をリコールしたそうだ。

高速道路を走行中のフィアット・クライスラー車両のテレマティクス(自動車のコンピューターと無線通信を組み合わせたカーナビなどのサービス)にハッカー攻撃を加え、エンジンやステアリング、ブレーキを遠隔操作ができたので、そのままにしておくのは危ないからリコールしたのだ。

サイバーセキュリティが原因で自動車がリコールされたのは、これが始めてだという。

最近、どこもかしこもサイバーセキュリティのことが話題になっており、サイバーセキュリティの対策をしないと危ないぞと、「親切に」教えてくれる正義の味方の方達があちこちにいる。

多くの製造業者は時代の流れで機器をネットワークにつないで多様なサービスを提供しようとしており、利便性の裏でネットワーク越しのサイバー攻撃を受けるリスクが高まるというわけだ。


ところで、医療機器ドメインでは、左図のようにリスク評価を行う。

ハザード(危害の潜在的な源)が一連の事象により危険状態となり、危険状態が危害に結び付く。

このとき、ハザードが危険状態に至る確率をP1、危険状態が危害にむつび付く確率をP2とおき、リスクは危害の重大さとP1とP2を考慮した危害の発生確率の両方で評価する。

人の死に至るほどの大きな危害であっても、危害の発生率が極めて低い場合は、リスクの評価が低くなることもある。

例えば、地球に大きな隕石が衝突したときの危害は甚大だが、発生する確率は極めて低いのでリスク評価はそれほど気にしなくてもよい。(ただ、過去に一回はあったので確率ゼロではない)

原子力発電所の事故は甚大な被害を及ぼすが、発生確率はどうだろう。低いと言えるだろうか。

それはさておき、上記のポットのお湯の例で見ると、ポットが倒れてお湯がこぼれている状態は危険状態だが、これだけでは危害には結び付かない。お湯に子供が触ってしまうことで危険状態から危害に結び付く。

したがって、機器の製造業者はP1を下げるアプローチとP2を下げるアプローチの両方の側面でリスク対策を行う。

P1を下げる対策として、ポットは倒れにくくする方法がある。また、P2を下げる対策としては、お湯がこぼれたときにアラームを鳴らして注意を促す方法がある。

サイバーリスクの評価で一番頭が痛いのは、例えばマルウェアや悪意のあるハッカーをハザード(危害の潜在的な源)と置いたときに、危険状態が発生する確率P1を推定することが難しいということだ。

人間はヒューマンエラーを起こすので、オペレータのミスは合理的に予見可能な誤使用としてP1を推定する。しかし、悪意のあるハッカーは、何かしらその企業に恨みがあれば徹底的攻撃してくるかもしれないし、ただ単にその商品がよく売れている、その企業がみんなに知られているというだけで攻撃の対象にするかもしれない。

だからP1が読めない。別な言い方をするとP1が低いと推定されるから対応をしなくていいという論理が通じにくい。

ソフトウェアが起因の故障(システマティック故障)もP1が推定しにくいのでしようがないから1と置いたりする。

ただ、サイバー攻撃やソフトウェア起因の故障でも、P2を下げる対策を考えることはできる。

これは多分にソフトウェアシステムのアーキテクチャと関係する。簡単に言えば、あるソフトウェアアイテムに故障が起こったとしても、その機器の基本機能や基本性能を担うソフトウェアアイテムに影響を与えないようなアーキテクチャにするということだ。

フィアット・クライスラー・オートモービルズのリコールに当てはめると、ネットワークの機能とエンジンの起動や停止、ステアリング、ブレーキの機能は分離して、独立するアーキテクチャにすることがそれに相当する。

だいたい、自動車ドメインでない自分でも、このリコールは「バカじゃないの」と思う。どうして、ネットワーク越しにエンジンやステアリング、ブレーキを操作できるようになっているのかと。

おそらく、システム設計の段階で、ネットワークと自動車の基本機能を切り離そうという意図はなく、未来の遠隔運転仕様のためにつなげておいたのかもしれない。

ISO 26262 は本当に役に立っていないなと思う。(セキュリティは対象外か?人のドメインのことは言えないが・・・)

まあ、それはそれとしてサイバーセキュリティの問題は本当に頭が痛い。P1を1と置いてしまうと、結局何かしらの設計上の対策をしなければいけないので、機器のコストアップにつながる。

サイバーセキュリティで金儲けしたいと考えている企業や論文通したいと考えている先生方には、よい時代なのかもしれない。

オープンソースの時代と言われて久しいが、サイバーセキュリティの確保が必要な時代になってきて、オープンソースの時代は潮目を迎える可能性がある。

なぜなら、ハッカーはまずオープンソースなどの既知の脆弱性情報を元にセキュリティの穴を見つけ、見つけた穴から中へ中へと入り込んでいくからだ。

公開されていないソフトウェアを解析するのはたいへんだから、攻撃する意欲が減る。そう考えるとオープンソースのソフトウェアを使っているソフトウェアシステムのサイバー攻撃に対するP1は高いと言えるかもしれない。

どっちにしても、ネットワークで機器がつながっている以上、サイバーセキュリティを考慮しなければいけなくなったことは事実だ。

しかし、確率が読めないサイバー攻撃を無理に想定して、危害を発生させられるという状況を作り上げて大騒ぎし、脅威を煽るのは本当の勘弁して欲しい。

サイバーセキュリティの専門家は、知っていることを端から順番に押しつけるのではなく、P1やP2を下げるのに有効な手段を優先順位を付けてアドバイスして欲しい。

また、製造業者はサイバーリスクも考慮して、システムの安全アーキテクチャを意識して設計をしないとダメでしょ。

P.S.

このブログでは事故やリコールの事例があるごとに、その情報をインプットとして安全を実現するためには何をすればよいか分析している。医療機器ドメインではいつものことなのだが、最初から完全を目指そうとすると、そうはいかない。まず、機能から入り安全を実現するために、できることを端から順番にやっていこうとする。志は高いのだが、その割には漏れが出たり、時間切れになったりして、残念な結果になることがある。今回のフィアット・クライスラー・オートモービルズのリコールはそういうことではいのだろうか。

別な言い方をすると、その機器の最大の危害や危険状態は何かを考えて、そうならないようにするにはどんな安全装置やアーキテクチャが必要かを考えるようにしている。

自動車の場合の最大の危害は、運転手、搭乗者、周りの人々の負傷であり、その危害に至るような危険状態にならないようにするにはどうするか考える。そのリスク低減の安全設計の方針は、利便性の追求よりも遙かに重要と考える。

日本のメーカはみんなそうしているので心配ないと思うけど。


2015-06-14

USのヘルスITの取り組み(9) 品質マネジメントの原則の利用促進


5.1 Promote the Use of Quality Management Principles
5.1 品質管理の原則の利用促進

Quality management principles and processes, as part of a quality system, have been adopted and implemented by more than 1 million companies and organizations worldwide to improve quality, efficiency, safety and reliability.
品質管理の原則とそのプロセスは、品質システムの一部として品質、効率、安全、および信頼性を向上させるために世界的な100万以上の企業や組織によって採用されて、実行された。

The selective adoption and application of existing quality management principles and processes to health IT has been advocated by the IOM, the FDASIA Workgroup, and numerous health IT stakeholders including developers, implementers and users.

ヘルスITの対する既存の品質管理の原則及びプロセスの選択的採用は、開発者、実装者、およびユーザを含む、IOM、FDASIA Workgroup、および多数のヘルスITのステークホルダによって支持された。

Some, but not all, health IT developers and healthcare facilities already adopt quality management principles.

全てではないが、いくつかのヘルスIT開発者及びヘルスケア機関も品質管理の原則をすでに受け入れている。

A number of different approaches to quality management exist;
品質管理のアプローチは数多く存在する。

however, they share certain common, underlying principles.
しかしながら、それらはある一般的で、基本的な原則を共有する。

Quality management principles help to identify, prevent, track, and monitor safety hazards and to reduce risks.
品質管理の原則は、安全上の問題を特定して、防御し、追跡して、モニターして、リスクを低減させるのを助ける。

They can be applied throughout the product lifecycle to design and development activities, to implementation, customization, integration, upgrades, maintenance, and operations, as well as to surveillance, reporting, risk mitigation and remediation.

それらは、実装し、カスタマイズし、インテグレート、アップグレート、保守、オペレーション、調査、報告、リスク対策、改善といった、設計と開発活動のための製品ライフサイクルを通して適用することができる。

Importantly, quality management principles are flexible, scalable and adaptable so organizations (e.g. health IT developers, healthcare facilities, etc.) can tailor the application of these standardized processes to their individual circumstances and needs.
重要なことは、組織(例えば、ヘルスIT開発者、ヘルスケア施設など)がこれらの標準化されたプロセスのアプリケーションを彼らの個々の事情とニーズに適合させることができるように、品質管理の原則は、フレキシブルで、スケーラブルで融通がきくということである。

Ultimately, quality management principles and processes provide a quality framework for companies and organizations to ensure that their products and services consistently meet their customers’ needs and requirements, that risk management principles are applied to identify, evaluate, mitigate and remediate hazards, and that overall quality is continually improved.

結局は、品質管理の原則とプロセスは、彼らの製品やサービスが一貫して、顧客ニーズと要求に合致し、リスクマネジメントの原則がハザードを識別し、評価し、対策し、修正し、そして、すべての品質が絶えず向上させるために適用されていることを確かにするために、企業や組織のために品質フレームワークを提供する。

The judicious application of quality management principles and processes by health IT stakeholders can promote the safe design, development, implementation, customization, integration, and use of health IT while fostering an environment that promotes innovation and continual improvement.
ヘルスIT利害関係者による品質管理の原則とプロセスの上手な適用は、革新と継続的改善を促進する環境を育成している間、ヘルスITの安全設計、開発、実装、カスタマイズ、インテグレーソイん、およびヘルスITの利用を促進できる。(訳注:品質管理を上手く適用すれば、イノベーションや継続的改善は阻害しないという意味)

However, because health IT represents a broad spectrum of products and services, health IT developers and organizations must have flexibility to determine the necessity of individual quality elements and to tailor the development and implementation of quality management processes appropriate for their products and services.
しかしながら、ヘルスITが広い製品の、そして、サービスの領域を示すので、ヘルスIT開発者と組織は個々の上質の要素の必要性を決定して、品質管理プロセスの開発と実現を合わせる柔軟性を彼らの製品とサービスに適切にしなければならない。

As part of the 2014 Edition Standards and Certification Criteria final rule, ONC adopted two safety-related certification criteria for EHRs:
2014年版の標準と証明評価基準最終規則の一部として、ONCは EHRの2つの安全関連の評価基準を採用した。

one that focuses on the application of user-centered design to medication- related certification criteria and another that focuses on the quality management system (QMS) used during the EHR technology design.

一つは評価基準に関連して医薬品のための人間中心設計の適用に焦点を当てたもので、もう一つはEHR(Electronic Health Record)の技術的設計で使用されるQMS(品質管理システム)に焦点を当てたものである。

In general, the Agencies believe that additional value to health IT purchasers and users could be realized if greater transparency existed around the quality management principles that were applied in the design and development, customization and implementation, and post-deployment use of health IT.
もしも、設計、開発、カスタマイズ、実装、ヘルスITの市販後使用で適用される品質マネジメントの原則に高い透明性が存在するなら、関係機関(規制当局)はヘルスITの購入者に対しての付加価値になると信じる。

Summary and Conclusion:
概要と結論:

The application of quality management principles, including a quality systems approach by health IT stakeholders, is necessary for the safe design, development, implementation, customization, and use of health IT.
ヘルスIT利害関係者による品質システムアプローチを含む品質マネジメントの原則の適用がヘルスITの安全設計、開発、実現、改造、および使用に必要である。

The Agencies will work with health IT stakeholders to identify the essential elements of a health IT quality framework, leveraging existing quality management principles and identifying areas where quality management principles can or should be applied.
関係機関(規制当局)は、すでに存在する品質マネジメントの原則を活用し、品質マネジメントの原則が適用できる、または適用すべき領域を特定し、ヘルスIT品質フレームワークの本質的な要素を特定するためにヘルスIT利害関係者と協力するだろう。

The Agencies view this strategy, rather than a formal regulatory approach, as the appropriate method for advancing a health IT quality framework.
関係機関(規制当局)は、正式な規制アプローチよりもむしろ、ヘルスITの品質フレームワークを進めるための適切な方法として、この戦略(品質マネジメントの取り組み)を見る。

The Agencies seek input on the following questions related to promoting the use of quality management principles in health IT:
関係機関はヘルスITにおける品質マネジメントの原則の利用を促進するために関連する以下の質問への回答を求める。:

+What essential quality management principles should apply to health IT?
+ どんな不可欠の品質マネジメントの原則がヘルスITに適用されるべきか?

How should they apply to different stakeholders and at different stages of the health IT product lifecycle?
品質マネジメントの原則は異なった利害関係者と、そして、ヘルスIT製品ライフサイクルの異なった段階でどのように適用するべきか?

+How do we assure stakeholder accountability for adoption of quality management principles?
+ どのように、品質マネジメントの原則の採用によって、利害関係者の説明責任を明かにするのか

Is there a role for a non-governmental, independent program to assess stakeholder adherence to quality management principles?
品質マネジメントの原則の利害関係者の順守を評価する、非政府または独立した仕組みのための役割はあるか?

Is there a role for government?
政府の役割があるか?

2015-05-23

ソフトウェアの規格に翻弄されている日本のエンジニアに告ぐ!

ソフトウェアの規格に翻弄されている日本のエンジニアに告ぐ!
今こそ「それは本当に役に立つのか」と問いかけろ!

自分達が作っているソフトウェアの品質は十分に高いのに、余計な要求を突きつけられて無駄なことをやらせていると思っているエンジニアはいないか。

そもそも、ソフトウェアの不具合は発見しにくいし、どの工程でも入り込んでくる可能性がある。だから、プロセスアプローチで相対的に対処しようとするのは分からないでもない。

でも考えて欲しい。それは、ルールと責任を重んじ、システムやツールを使いこなすことを得意とする欧米のやり方ではないか。

品質を心配する意識が強く、製品のライフサイクルを通じて同じ技術者が考え、問題にすばやく対処し、ルール化せずとも不具合の再発防止を継続的に実現できる日本のソフトウェアエンジニアに、もっとも有効なやり方か?

そして、規格適合の実態のばかばかしさ。本当に役に立つのかどうかの根拠が明白でないままに、規格のその要求に適合できないことは悪だとばかりに、責める認証機関やコンサルがいる。

彼らには、規格は金を生む宝であり、バイブルなのだ。

問題は規格そのものよりも、規格を認証する制度の問題だ。プロセス規格の場合、規格に適合できているかどうかの判定の白黒が付きにくい。だから、プロセス規格の適合を取ると決まったら、監査管、審査官のさじ加減で各要求のレベルが上がったり下がったりする。試験方法が明白な電気的安全性の試験などと違って、監査管、審査官の裁量に委ねられることも多く、適合している、していないで攻防をする結果、適合していることを示す明確なエビデンスがないことが不適合の根拠となる。

その結果、日本の企業では監査で実質的に出来ているのに、ルールやシステムの整備が十分でなく、承認されたエビデンスがないことがよく指摘される。

そういう状態で是正事項を指摘されると、表面的に取り繕うことが目的になっていく。中身はどうでもいいから手順と証拠があればいいという方向に流れていく。

だが、待て! そもそも、その指摘は手順があって、ルールに縛られないと品質を担保できない者達へのアプローチではないか。

手順やルールがなくても、上司に言われなくても、問題があれば自助努力で解決できるチームには余計なお世話ではないのか。

ソフトウェアの規格に翻弄されている日本のエンジニアに告ぐ!もしも、その疑問が心の中に浮かんでいるのならば、今こそ、「なぜ」それが必要なのかを考えろ。

納得できる答えを見つけてから、動こう。「なぜ」それが必要なのかをチームでディスカッションしよう。

認証機関にも聞いてみよう。(認証機関はコンサルしてはいけないルールになっているので、答えることができないという言い訳をするかもしれないが)

コンサルにも聞いてみよう。この取り組みはどうして品質向上につながるのか。もしも、「規格で要求されているから」と答えたら、張り倒そう。

なぜなぜ分析って、知ってる? 問題が起こったときの根本原因を掘り下げるときによく使うけれど、今こそ、使うべきだ。なぜ、その規格を適合すると品質が向上するのか、安全になるのか?

無駄だと思ってやっていると、日本の組織では力にならない。最初の図にある「品質を心配する意識」に語りかけないとダメだ。今やっていることが役に立つという確信を持てれば、ガチガチのルールにしなくても、チームは率先して受け入れて効果も上がる。

ルールや責任ばかり強調して、システムやツールに頼ろうとするのは、欧米ではうまくいくかもしれないが、日本ではうまくいかないだろう。

なぜなら、ソフトウェアを作っているのは人間であり、人間や人間の集まりであるチームはその気質によって考え方や慣習が異なるからである。

欧米中心で作られた国際規格が日本のプロジェクトにフィットしないシーンはたくさん見てきたし、欧米振興の日本人が国際規格を神格化しているケースもある。

みんな、自分達のソフトウェアの品質が諸外国のそれらより劣っていると思っている? そう思っていないのに、いいなりなんだ。

人が働ける時間には限りがある。「あの人はいい仕事をした」と後々言われるような仕事をしよう。

誰にも誇れる仕事、自分にも他人にも嘘をつかない仕事、エンドユーザーに役に立つ仕事をしよう。エンドユーザーにとっての価値が下がるような結果にしては絶対にいけない。(品質は上がらず、コストだけが上がったというのもその一つ)

コメント募集中!

2015-05-04

USのヘルスITの取り組み(8) 提案されたヘルスIT重点領域の外観

今回より、FDASIA Health IT Report の第5章に入る。第5章は原文で12ページとボリュームが大きく、今回は第5章の全体を説明する前文を紹介する。

5. PROPOSED STRATEGY AND RECOMMENDATIONS FOR A HEALTH MANAGEMENT HEALTH IT FRAMEWORK
5. ヘルスマネジメント・ヘルスITフレームワークのための提案された戦略と推奨

Health IT has the potential to reduce medical errors, increase the efficiency of healthcare delivery, reduce costs, and improve the quality of healthcare for Americans.
ヘルスITには、医療ミスを抑制し、ヘルスケアの提供の効率化し、コストを削減して、アメリカ人のためにヘルスケアの品質を向上させる可能性がある。

However, shortcomings in health IT design, development, implementation, customization, integration and use may result in adverse health consequences.
しかしながら、ヘルスITの設計、開発、実現、カスタマイズ、インテグレーション、利用における不十分な点は健康被害をもたらすかもしれない。

We propose that a framework intended to promote innovation and protect patient safety should adhere to the following principles:
私たちは、革新を促進して、患者の安全を保護することを意図する枠組みが以下の原則を固く守るべきであるよう提案する:

1) Employ a risk-based approach to appropriately mitigate patient safety risks while avoiding unnecessary regulatory oversight;
2) Leverage private sector knowledge, experience, and expertise;
3) Facilitate, rather than impede, innovation;
4) Promote transparency of product performance and safety;
5) Create/support an environment of learning and continual improvement.

1) 不必要な規制監視を避ける間、リスクベースアプローチを患者安全リスクの適切な対策のために使いなさい。
(訳注:過剰な規制監視はしないから、リスクベースアプローチで患者安全の対策を取ることに集中せよという意味だと思われる)
2) 民間の部門の知識、経験、専門技術を活用しなさい。(訳注:ヘルスITは様々な領域を結合するため、それぞれの専門領域の知識や経験を活用せよという意味)
3) 革新を妨げるよりも、むしろ促進することを考えなさい。
4) 製品の性能と安全の透明性を促進しなさい。
5) 学習と継続的改善の環境を構築し、保持しなさい。

The proposed framework is based on the health IT product lifecycle and the complex sociotechnical system in which these products are developed, implemented, and used, and the extent of risk posed by health IT products.
提案されたフレームワークはヘルスIT製品のライフサイクル及び、これらの製品が開発されて、実行され、使用される複雑な社会技術システム、およびヘルスIT製品によって引き起こされたリスクの影響範囲に基づいて考えられている。

We recommend a limited, narrowly-tailored approach that primarily relies on ONC-coordinated activities and private sector capabilities.
私たちは限定的で狭義に最適化されたアプローチ、それは主としてONCとの強調活動と民間セクターの能力に依存するアプローチを推奨する。

For example, we do not recommend the need for any new or additional areas of FDA oversight.
例えば、私たちはFDAのいかなる新規のまたは追加の監督領域も推奨しようとは考えていない。

Rather, we believe a better approach is to foster the development of a culture of safety and quality, leverage standards and best practices, employ industry-led testing and certification, and selectively use tools such as voluntary listing, reporting, and training to enable the development of a transparent learning healthcare environment that fosters continual health IT improvement.
むしろ、私たちは、安全と品質の文化の開発の促進や、標準やベストプラクティスの実践や、産業界主導のテストや認証、自動表生成やレポート支援などの選択的に使用するツールの使用や、継続的なヘルスITの発展を育成する透明性の高い、ヘルスケア環境の開発を可能にするトレーニングなどが、よりベターなアプローチであると信じている。

We do not believe that regulation should be, or needs to be, the first approach used to reach this outcome.
私たちは、規制があるべきとか、必要であるとか、この結果に達するための最初のアプローチであるとは考えていない。(訳注:規制ありきでは目的は達しないという意味)

This section identifies the four key proposed priority areas for a risk-based framework for health management health IT functionality and outlines potential next steps for each (FIGURE 3):
このセクションでは、ヘルスマネジメント・ヘルスITの機能性のためのリスクベースフレームワークの4つの主要な重点分野を特定して、それぞれ(図3)の施策のために次に進むためのステップについて概説する:

I. Promote the Use of Quality Management Principles
II. Identify, Develop, and Adopt Standards and Best Practices
III. Leverage Conformity Assessment Tools
IV. Create an Environment of Learning and Continual Improvement

I. 品質管理原則の使用を促進すること。
II. 利用可能な規格類とベストプラクティスを定義し、開発し、導入しなさい。
III. 適合性評価ツールを活用しなさい。
IV. 学習と継続的改善の環境を構築しなさい。

These priority areas share three critical characteristics:
これらの重点分野は3つの重要な特性を共有する:

1) their application can be tailored using a risk-based approach;
2) they have relevance at all stages of the health IT product lifecycle and to all health IT stakeholders;
and 3) they support both innovation and patient safety.

1) これらの利用は、リスクベースアプローチを使用することでテーラリングすることができる。(訳注:合わせ込むことができるという意味)
2) これらは、ヘルスIT製品ライフサイクルのすべての段階においてすべてのヘルスIT利害関係者に関連性を持っている。
そして、3) これらは革新と患者安全の両方を支援する。

In addition to the four key priority areas listed in FIGURE 3, the Agencies have identified an additional key component to the health management health IT framework - the creation of a Health IT Safety Center.
図3に記載された4つの主な優先領域に加えて、関係機関はヘルスマネジメント・ヘルスITフレームワークにキーコンポーネントとしてHealth IT Safetyセンターの創設を追加して定義した。

This public-private entity would be created by ONC, in collaboration with FDA, FCC, and AHRQ, and with involvement of other Federal agencies and health IT stakeholders.
この公立の民間会社はFDAと、FCCと、AHRQ、および他の連邦政府の機関とヘルスITのステークホルダ達のかかわり合いと共同作業のもとでONCによって創設されるだろう。

The Health IT Safety Center would serve as a trusted convener of health IT stakeholders in order to focus on activities that promote health IT as an integral part of patient safety with the ultimate goal of assisting in the creation of a sustainable, integrated health IT learning system that avoids regulatory duplication and leverages and complements existing and ongoing efforts.

Health IT Safetyセンターは、二重規制を避けて、現存しそして進行中の努力を補完する、統合されたヘルスIT学習システムの創造を助けるという究極の目標のもと、患者の安全の不可欠の部分としてヘルスITを促進する活動に焦点を合わせるためにヘルスIT利害関係者に信頼された召集者として機能するだろう。

The Health IT Safety Center could enable a deeper understanding of how these four priorities can and should be integrated into the programs and activities of stakeholders in health IT safety.
Health IT Safetyセンターはこれらの4つのプライオリティがどう統合できて、ヘルスIT安全における、利害関係者のプログラムと活動と統合されるべきであるかに関する、より深い理解を可能にすることができるだろう。

To be successful, the Health IT Safety Center will require a strong governance mechanism and involvement by participants in programs and activities that:
これがうまくいくために、Health IT Safetyセンターは次のような問題と活動の関係者によって強いガバナンスメカニズムと関与を要求するだろう:
  • Establish a broad and engaged stakeholder membership and leadership base;
  • Focus on high-value issues affecting the promotion of innovation and the protection of patient safety related to health IT;
  • Build upon and improve the evidence-based foundation for health IT safety by analyzing the best available data and evidence and by identifying interventions and opportunities for improvement based on the data and evidence;
  • Create or inform health IT safety priority goals and measures that align with broader patient safety goals and initiatives;
  • Provide education on health IT safety, including on best practices regarding risks, mitigation strategies, usability, workflow, etc. to improve the commitment and capabilities of participant organizations to improve their health IT safety efforts and evaluate the effects of that education.
  • 広く連動した利害関係者間のメンバーシップとリーダーシップベースを確立する。
  • ヘルスITに関連した患者安全の保護と革新の推進に大きく影響する問題に焦点を当てる。
  • ヘルスITの安全のためのエビデンスベースの基盤を、最も良い有効データ及び証拠を分析して、また、データとエビデンスに基づいて改善する介入と機会を特定することによって改良し構築する。(訳注:自分達のやり方でいいがデータとエビデンスに基づいて基盤を整備し改善せよと言っている)
  • 広い意味での患者安全のゴールと問題解決に向けた新たな取り組みに合致するヘルスIT安全の優先的な目標と対策を作成し周知させる。
  • リスク、対応戦略、ユーザビリティ、ワークフローなど、彼らのヘルスIT安全の努力を改善する参加組織の深い関与と能力の向上に関連したベストプラクティスを含むヘルスIT安全の教育を提供する。(訳注:Health IT Safetyセンターは、ベストプラクティスを含みヘルスITの安全教育を提供すべきと言っている)
The Agencies believe this type of collaborative public private effort is critical to the successful implementation of the strategy and recommendations contained in this report.
関係機関は、このような公共と民間の努力のコラボレーションがこのレポートに含まれた戦略と推奨の成功実現に重要であると信じている。
(訳注:規制当局が一方的に規制するのではなく、官民のコラボが本レポートの実現のカギだと言っている)

The Agencies seek input on whether the focus areas identified in this report are the appropriate ones - and whether the proposed next steps, described below, will lead to an environment where patient safety is protected, innovation is promoted, and regulatory duplication is avoided.

関係機関はこのレポートで確認される焦点領域が適切なものであるかどうか、以下で説明された次のステップが患者安全が保護される環境に導かれるのか、革新が促進されるのか、二重規制が避けられるのかを示すインプットを探している。
(訳注:このレポートの主張が正しい根拠が欲しいと言っている。パブリックコメントで賛同してくれということではないか。)

The Agencies also seek comment on what steps should be taken to encourage and foster private sector participation in the identified priority areas and in the Health IT Safety Center.

関係機関はまた、特定された重点分野の中で、Health IT Safetyセンターへの民間部門の参加を奨励して、後押しするために、どんな方法が採られるべきであるかに関するコメントを求める。

The Agencies believe such participation could help otherwise avoid the need for a more active regulatory approach while assuring that health IT risks are minimized and patient safety protected.

関係機関は、そのような民間の参加がヘルスITリスクの最小化と患者安全の保護を保障するより活発な規制アプローチの必要性を避けるのを助けると信じている。

(訳注:民間がHealth IT Safetyセンターに積極的に参加することでヘルスITリスクを最小化し患者安全を保護できると規制当局は考えている。裏を介せば、民間が積極的に関与しなければ、規制当局が規制を強めるしかないという意味)

Summary and Conclusion:
概要と結論:

The Agencies'strategy and recommendations for a risk-based framework for health management health IT include four key priority areas:

関係機関が推奨するヘルスマネジメント・ヘルスITのための戦略は、4つの優先領域を含んでいる。

promote the use of quality management principles;
identify, develop, and adopt standards and best practices;
leverage conformity assessment tools;
and create an environment of learning and continual improvement.

品質管理原則の使用を促進しなさい。
関係する標準とベストプラクティスを特定して、開発して、採用しなさい。
適合評価のツールを活用しなさい。
そして、学習と継続的改善の環境を構築しなさい。

The Agencies also recommend the creation of a Health IT Safety Center as a public-private entity with broad stakeholder engagement, that includes a governance structure for the creation of a sustainable, integrated health IT learning system that avoids regulatory duplication and leverages and complements existing and ongoing efforts.

関係機関はまた、広い利害関係者が関わり官民によるHealth IT Safetyセンターが創設されることを推奨する。それは、二重規制を避け、現存し進行中の努力を補完し活用するための継続可能で、統合されたヘルスIT学習システムの創設のための管理構造を含む。(訳注:Health IT Safetyセンター は、ヘルスITの安全に有効な標準やベストプラクティスを学ぶためのヘルスIT学習システムの創設と管理の責任を担っているという意味。)

FIGURE 3:Overview of Proposed Health IT Priority Areas
図3:提案されたヘルスIT重点分野の概観


The proposed risk-based framework for health IT identifies four key proposed priority areas and outlines potential next steps that could be taken to help more fully realize the benefits of health management health IT functionality.

ヘルスITのための提案されたリスクベースフレームワークは、4つのキーとなる重点領域を特定し、ヘルスマネジメント・ヘルスITの機能性の有益性をより完全に実現することを助ける潜在的な次のステップを概説する。

Promoting the use of quality management principles, including a quality systems approach, by health IT stakeholders is necessary for the safe design, development, implementation, customization, and use of health IT.

ヘルスITの利害関係者達が安全設計、開発、実装、カスタマイズ、そしてヘルスITの利用のために必要とする品質システムアプローチを含む品質管理の原則の使用を促進すること。
The identification, development, and adoption of applicable health IT standards and best practices can help to deliver consistently high quality health IT products and services to consumers.

ヘルスITの標準とベストプラクティスを定義し、開発し、採用することは、高品質なヘルスIT製品とサービスを顧客に提供し続けることを助ける。

Conformity assessment tools (e.g. product testing, certification, accreditation) can provide assurance that health IT products, services, systems, and organizations meet specified standards or fulfill specified requirements.

適合性評価ツール(例えば、製品試験、認証、認証評価)はヘルスIT製品、サービス、システム、および組織が指定した標準を満たすか、または規定要求事項を実現していることの保証を提供できる。

These tools should be used and applied in a risk-based manner to distinguish high quality products and organizations from those that fail to meet basic performance standards or requirements.

これらのツールは、基本性能規格または要求の適合を満たさないものと高品質の製品や組織を識別するために、リスクベースの方法で使用され、適用されるべきである。

The creation of an environment of learning and continual improvement, including transparent reporting, aggregation, and analysis of safety issues is central to a health IT framework that promotes innovation and protects patient safety.

透明性の高い報告、集積、安全問題の分析を含む、学習と継続的改善の環境の創設は、革新の促進と患者安全の保護のヘルスITフレームワークの中心的存在である。

The Agencies recommend the creation of a Health IT Safety Center that includes broad representation from public and private sector stakeholders to establish a governance structure for the creation of a sustainable, integrated health IT learning system that avoids regulatory duplication and leverages and complements existing and ongoing efforts.

関係機関はHealth IT Safetyセンターの創設を推奨する。Health IT Safetyセンターは、二重規制を避け、現存し進行中の努力を活用し補完するための統合された継続維持できるヘルスIT学習システムの創設のための統治構造を創設し、官民領域のステークホルダーからの広い権益を含む。

【訳者考察】

今回 FDASIA Health IT Report 第5章の前文で明らかになったことは、規制当局である関係機関(FDA, FAA, ONC)は図3に示された4つの重点領域において、規制規制とゴリゴリに締め付けるのではなく、官民が協力して創設するHealth IT Safetyセンターにて、活動を進めようと考えていることだ。

また、レポートは繰り返し、ヘルスITを使った革新を妨げずに促進したい、二重規制するつもりはないと言っている。

ただし、患者の安全を念頭においたリスクベースのアプローチを使って、患者安全の対策を行うことが条件となっている。

ヘルスITは利用される段階で様々な製品やサービスが連携することでITとしての能力を発揮する。個々の製品やサービスはそれぞれ専門領域が異なることもあるので、関連する標準(規格)や業界や組織におけるベストプラクティスを使い、品質管理の原則を使用することを推奨している。

ちゃんと出来ているかどうかの判定に適合性評価ツールを活用したり、継続的な改善や学習の環境も構築することが必要と解いている。

そうなると、ここで言うHealth IT Safetyセンターの動きが気になる。調べてみたところ、Health IT Safetyセンターはまだ正式には発足していないものの、ONC(the National Coordinator for Health Information Technology)の指導下の元、RTI International がHealth IT Safetyセンター設立のためのロードマップを作成するタスクフォースがあることが分かった。(Health IT Safety Center Road Map

こちらがHealth IT Safetyセンターのロードマップを作るタスクフォースのレポート。(Health IT Safety Center Road Map Task Force) この資料を見ると2015年の4月に最終ロードマップを完成させる予定となっている。そこがスタートラインになるので、Health IT Safetyセンターができるまでには、まだまだ時間はかかりそうだ。

ただし、ロードマップのサイト(http://www.healthitsafety.org/) すでに5回ぶんのWebinarのビデオと資料が掲載されており、 研究資料としてヘルスITが患者安全を向上された最近のエビデンスも掲載されている。(Recent Evidence that Health IT Improves Patient Safety

図2 意味のあるユーザビリティ機能はヘルスケアの品質、安全、効率にプラスの影響を与える。ヘルスITに関する2007-2013の出版された研究結果の一部
Health IT Safety Task Force Members には28人が名を連ねており、それぞれヘルスITに関連する分野の専門家のようだ。見たところ、学者や公的機関の方ばかりで商売気はなく、アメリカの懐の深さ、底辺の広さを感じさせる。

ところで、ヘルスITに関して、関連する標準(規格)を参照し、ベストプラクティスを定義して、開発し、採用し、継続的な教育を行い、透明性を高めた上で認証を有効に活用する・・・と言えば、日本ではGHSがそのものズバリの活動を2014年8月から始めているではないか。

FDASIA Health IT Report を意識したことはなかったが、結果的に向いている方向性が似ていることがヘルスITドメインにおいて「間違っていなかった」と確信した。

FDASIA Health IT Report を翻訳し始めて、このことを発見したのは大きかった。ただ、GHSの方で課題になるのは、現在は製品単独でのリスクマネジメントに焦点を当てているのだが、今後は製品やサービスがネットワークでつながって機能した際のリスクマネジメントについても取り入れる必要があるというこだ。

2015-04-12

USのヘルスITの取り組み(7) リスクベースの規制フレームワーク

4. REPORT SCOPE AND FOCUS OF THE PROPOSED STRATEGY AND RECOMMENDATIONS FOR A RISK-BASED REGULATORY FRAMEWORK

4. リスクベースの規制の枠組みのための提案された戦略と推薦のレポート範囲と焦点

Health IT incorporates a wide range of products, technologies, and services designed for use by health care entities, health care providers, and consumers, to electronically maintain, access, and exchange health information.

ヘルスITは、電子的に健康情報を保存し、アクセスして、交換するために、健康管理のデバイス、健康管理のプロバイダー、および消費者によって設計された、さまざまな製品、技術、サービスを包含している。

Throughout the report, the Agencies’ proposed strategy and recommendations are based on the premise that risk and corresponding controls should focus on health IT functionality - not on the platform(s) (e.g. mobile, cloud-based, installed) on which such functionality resides or the product name/description of which it is a part. Further, the Agencies’ strategy and recommendations seek to advance a framework that is relevant to current functionalities and technologies yet sufficiently flexible to accommodate the future and rapid evolution of health IT.

レポートを通して、関係機関が提案する戦略及び推奨はリスクとヘルスITの機能性に焦点を当てるべき相当な管理の前提に基づいている。それは、モバイルかクラウドベースかといったプラットフォームには依存せず、また、その機能が製品名や製品のスペックの一部であるか、属するものかではなく、ヘルスITの機能性に焦点を当てることを意味する。

さらに、関係機関の戦略と推薦はヘルスITの未来と急速な進化に適応するために十分にフレキシブルな現在の機能性と技術に関連している枠組みを進めようとしている。

The Agencies’ proposed strategy and recommendations identify three categories of health IT functionality:
関係機関が提案する戦略及び推奨はヘルスITの機能性を3つのカテゴリに定義する。

1) administrative health IT functions, 2) health management health IT functions, and 3) medicaldevice health IT functions (See FIGURE 2). This paradigm creates health IT functional categories with important distinctions in both risk and proposed corresponding risk controls, although each of the three proposed categories can be designed for use by health care entities, health care providers, patients, and consumers. It is also important to note that the systems that healthcare organizations and consumers are purchasing, implementing and using, often contain functionalities that bridge all three of these categories. For example, electronic health records (EHRs) may have functionality that spans one or more of these categories. Similarly, some functionalities, such as privacy and security, cannot be placed in a single category.


1) 行政上のヘルスIT機能、2)健康管理ヘルスIT機能、および3) 医療機器ヘルスIT機能 (図2参照)。 このパラダイムはリスクと対応するリスク・コントロールの両方における重要な特徴でヘルスITの機能的なカテゴリを作成する。提案された3つのカテゴリ、健康管理を実施する実体、健康管理プロバイダー、患者、および消費者によって設計される場合がある。また、ヘルスケア組織と消費者が購入して実行し使用しているシステムが、しばしばこれらのすべての3つのカテゴリに跨がる機能性を含むことに注意するのも重要である。 例えば、電子健診記録(EHRs)には、これらのカテゴリの1つ以上にかかる機能性があるかもしれない。同様に、プライバシーやセキュリティなどのいくつかの機能性はただ一つのカテゴリに置くことができない。

Ultimately, the Agencies recognize that any categorization scheme will be imperfect and may need to adapt over time.

結局、関係機関は、どんな分類スキームも、不完全であり、時間がたつにつれて修正する必要であるかもしれないと認める。

Nevertheless, we believe that this proposed functional categorization can both assist the Agencies in avoiding regulatory duplication and prompt meaningful policy discussions with stakeholders to identify and clarify unresolved areas of ambiguity (e.g. instances where categorization into “administrative” vs. “health management” or “health management” vs. “medical device” health IT functionality is unclear).

それにもかかわらず、我々はこの提案された機能性分類は規制の重複を避け、曖昧な未解決領域のクラス分類(例えば、行政上の機能か健康管理かや、健康管理か医療機器か、またはヘルスITの機能性が不明瞭など)と特定するためにステークホルダーと意味のある方針協議を促すと信じる。

4.1 Administrative Health IT Functionality
4.1 業務管理上のヘルスITの機能性

Administrative functionalities, including but not limited to software intended to facilitate admissions, billing and claims processing, practice and inventory management, scheduling, general purpose communications, analysis of historical claims data to predict future utilization or cost-effectiveness, determination of health benefit eligibility, population health management, reporting of communicable diseases to public health agencies and reporting on quality measures pose limited or no risk to patient safety.

業務管理上の機能とは、ソフトウェアに限らず、(医療機関への)入館や請求、要求処理、出庫、在庫管理、スケジューリング、一般的目的の通信、将来の利用予測のための病院内要求データの分析や、コスト効果や、健康利益適格性の決定、人工健康管理、衛生行政機関への伝染病の報告、患者安全に対する限定的またはリスクがないことの品質計測の報告を含む。

As such, the Agencies recommend that no additional oversight of these types of products is necessary to protect patient safety and promote innovation.

関係機関はこれらのタイプの製品の患者安全の確保と革新の推進のために追加監視は必要でないと考えている。

4.2 Health Management Health IT Functionality
4.2 健康管理ヘルスITの機能性

Health management health IT functionalities (sometimes referred to as “clinical software”) include, but are not limited to:
  • Health information and data management;
  • Data capture and encounter documentation;
  • Electronic access to clinical results;
  • Most clinical decision support;
  • Medication management (electronic medication administration records);
  • Electronic communication and coordination (e.g. provider to patient, patient to provider, provider to provider, etc.);
  • Provider order entry;
  • Knowledge (clinical evidence) management;
  • Patient identification and matching.
健康管理IT機能(時に「臨床のソフトウェア」と呼ばれる)下記を含むが、それに限定されない:
  • 健康情報とデータ管理。
  • データの受け取りと文書作成支援
  • 臨床結果への電子アクセス。
  • 臨床の意志決定支援。
  • 薬物療法管理(電子薬物療法管理記録)。
  • 電子連絡調整(例えば、プロバイダーから患者へ、患者からプロバイダーへ、プロバイダーからプロバイダーなど)。
  • プロバイダー受注。
  • 知識(臨床上の証拠)管理。
  • 患者の識別とマッチング。
The Agencies believe the potential safety risks posed by health management health IT functionality are generally low compared to the potential benefits and must be addressed by looking at the entire health IT ecosystem rather than single, targeted solutions.

潜在的なリスクは、ヘルスITの機能性が、単位一の、目標にしている解決策より、ヘルスITの系全体を見ることによって取り組まれなければならず、潜在的利益と比べて一般的に低いヘルスITの機能性健康管理によってもたらされると関係機関は信じている。

(訳注:ヘルスIT単独ではリスクが低く見えても、ヘルスIT全体で起こる問題があるため、ヘルスIT全体= the entire health IT ecosystem を見ることによって取り組まなければいけないという意味)

If such health management health IT functionality meets the statutory definition of a medical device, FDA does not intend to focus its regulatory oversight on such functionality because the Agencies’ proposed strategy and recommendations for a risk-based framework for health management health IT, outlined in Section 5, can help to assure a favorable benefit-risk profile of these functionalities.

もしも、そのような健康管理ヘルスIT機能性が医療機器の法的な定義に合致するなら、FDAは機能性に基づいた行政監視に焦点を合わせることを目的とはしない 

なぜなら、第5章に概要がある関係機関が提案する健康管理ヘルスITのためにリスクベースフレームワークの戦略と推奨は、このような機能性の好ましいリスク効用分析結果を明らかにすることにが目的であるからである。

Section 5 articulates specific proposed priority areas and potential next steps that could help more fully realize the benefits of health IT.

第5章はヘルスITの利益をより完全に実現するのを助ける特定の重点分野と次の潜在的ステップを明確にする。

4.3 Medical Device Health IT Functionality
4.3 医療機器ヘルスITの機能性

Health IT with medical device functionality is currently the focus of FDA’s oversight.
現在、医療機器の機能性を持つヘルスITはFDAの監視の焦点である。

Examples include computer aided detection/diagnostic software, radiation treatment planning, and robotic surgical planning and control software.

例はコンピュータ支援の検出/診断しているソフトウェア、放射線療法計画、ロボットの外科計画、および制御ソフトウェアを含んでいる。

ONC and FCC may have complementary activities in certain areas (e.g. interoperable data exchange between a medical device and EHR, use of wireless spectrum for wireless medical devices, etc.).

ONCとFCCはある一定の領域(例えば、医療機器とEHRの間の共同利用できるデータ交換、無線のスペクトルの無線の医療機器の使用など)に補足的な活動に関与しているかもしれない。

The strategy and recommendations for a risk-based health IT framework do not propose the need for new FDA authorities or additional areas of oversight.

リスクベースのヘルスIT枠組みのための戦略と推薦は、新しいFDA組織または監視の追加領域の必要性を提案しない。

The FDASIA Health IT Working Group did recommend that the FDA provide greater clarity related to several aspects of medical device regulation involving health IT, including:

FDASIA Health ITワークグループは、FDAが次を含むヘルスITに関連する医療機器規制のいくつかの視点に関係したよりはっきりした明確性を提供することを推奨した。

1) The distinction between wellness and disease- related claims;
2) Medical device accessories;
3) Medical device clinical decision support software;
4) Medical device software modules;
and 5) Mobile medical apps.

1) 主張に関連したウェルネスと疾病との差異
2) 医療機器のアクセサリー
3) 医療機器臨床決定支援ソフトウェア
4) 医療機器ソフトウェアモジュール
5) モバイルメディカルアプリケーション

These items are discussed in more detail in Section 6.
さらに詳細にセクション6でこれらの項目について議論する。

FIGURE 2 Categories of Health IT Functionality
図2 ヘルスITの規制性の分類

Health IT functionality can be broadly grouped into three categories:
ヘルスITの機能性を3つのカテゴリに広く分類できる:

1) administrative health IT functionality, 2) health management health IT functionality, and 3) medical device health IT functionality.

1) 業務管理上ヘルスITの機能性、2)健康管理ヘルスITの機能性、および3) 医療機器ヘルスITの機能性。

Each of the three proposed categories can be designed for use by health care entities, health care providers, patients, and consumers.

それぞれの3つの提案されたカテゴリが使用のために健康を管理する実体、健康管理プロバイダー、患者、および消費者によって設計される場合がある。

Administrative functionalities, including but not limited to admissions, billing and claims processing, practice and inventory management, scheduling, general purpose communications, analysis of historical claims data to predict future utilization or cost-effectiveness, determination of health benefit eligibility, population health management, reporting of communicable diseases to public health agencies and reporting on quality measures pose limited or no risk to patient safety.

業務管理上の機能とは、ソフトウェアに限らず、(医療機関への)入館や請求、要求処理、出庫、在庫管理、スケジューリング、一般的目的の通信、将来の利用予測のための病院内要求データの分析や、コスト効果や、健康利益適格性の決定、人工健康管理、衛生行政機関への伝染病の報告、患者安全に対する限定的またはリスクがないことの品質計測の報告を含む。

The Agencies believe no additional oversight of these types of products is necessary.

関係機関は、これらのタイプの製品のどんな追加管理も必要でないと信じている。

Health management functionalities include but are not limited to health information and data exchange, data capture and encounter documentation, electronic access to clinical results, some clinical decision support, medication management, electronic communication and coordination, provider order entry, knowledge management, and patient identification and matching.

健康管理機能性には、健康情報、データ交換、データキャプチャ、ドキュメンテーション支援、臨床結果への電子アクセス、何らかの臨床決定サポート、薬物療法管理、電子連絡調整、プロバイダー受注、ナレッジ・マネジメント、患者識別、およびマッチングが含まれる。(限定はされない)

Health management health IT functionalities are the primary focus of the framework described in this report.

健康管理ヘルスITの機能性は、このレポートで説明された枠組みの焦点である。

If a product with health management health IT functionality meets the statutory definition of a medical device, FDA does not intend to focus its oversight on it - - because the Agencies’ proposed strategy and recommendations for a risk-based framework for health management health IT can help to assure a favorable benefit-risk profile of these functionalities.

もしも、そのような健康管理ヘルスIT機能性が医療機器の法的な定義に合致するなら、FDAは機能性に基づいた行政監視に焦点を合わせることを目的とはしない 

なぜなら、第5章に概要がある関係機関が提案する健康管理ヘルスITのためにリスクベースフレームワークの戦略と推奨は、このような機能性の好ましいリスク効用分析結果を明らかにすることにが目的であるからである。

FDA would focus its oversight on medical device functionality because, in general, these functions, such as computer aided detection software and remote display or notification of real-time alarms from bedside monitors, present greater risks to patient safety than health IT with administrative or health management functionality.

ベッドサイド・モニタからのリアルタイムのアラームのコンピュータ支援の検出ソフトウェアや遠隔表示か通知などのこれらの機能が管理があるヘルスITか健康管理の機能性より一般に患者の安全により大きなリスクを提示するので、FDAは医療機器の機能性に監視の焦点を合わせるだろう。

【訳者感想】

ヘルスITの機能性を、1) 業務管理上の機能、2) 健康管理の機能、3) 医療機器の機能の3つに分類している。1がリスクが低く、3に向かうに従ってリスクが高くなる。Administrative health IT functionality は医療を遂行するために必要な業務に関連するITソフトで見るからにリスクも低そうで規制する必要もないように見える。難しいのは2の健康管理の機能と医療機器の機能の区別であろう。FDASIAレポートでは機能性が分類すると言っているが、機能が同じでも製造業者の意図によってリスクが変わることがある。例えば、心電図を表示するという機能があったとして、それが保管された過去のデータの閲覧を目的としているのか、それとも診断や処置の判断に使うのかによってはリスクが変わってくる。

ただ、製品単独の場合は、製造業者の意図によってリスクを分類できていたが、ヘルスITになってソフトウェア同士が連携して、新たな機能を生み出せるようになったことで、個々の製造業者の意図とは別のところで、ヘルスITがヘルスITの生態系(Health IT ecosystem)として新しい機能を持つようになったのかもしれない。

そうなると、製造業者の意図ではなく、ヘルスITやヘルスIT全体として実現する機能や機能性に着目しないと、リスク分析ができなくなってきたのだろう。

もし、そうだとすると規制するしないの問題とは別に、事故が起こったときの責任の所在がどこにあるのか特定しにくくなったのかもしれない。

2015-03-15

USのヘルスITの取り組み(6) ヘルスITライフサイクルと社会システム

3.HEALTH IT:LIFECYCLE AND SOCIOTECHNICAL SYSTEM CONSIDERATIONS
3.ヘルスIT:ライフサイクルと社会技術システム問題

An understanding of the health IT product lifecycle is critical to the development of a narrowly- tailored, predictable regulatory framework that fosters the development of novel technologies, permits timely deployment of iterative product improvements, and routinely identifies underperforming products in a timely fashion.

ヘルスIT製品のライフサイクルを理解することは次のようなことにとってに重要である。狭い意味での適合した開発、今までにない技術の開発を発展させる予測可能な規制の枠組み、タイムリーな製品の反復的な製品改善の許可、流行のように現れてくる基準以下の製品の定期的な特定。

Furthermore, it is important to recognize that health IT products and technologies are not used in isolation.
さらに、ヘルスIT製品とヘルスIT技術が分離できないと認識することは重要である。

Rather, they are part of a larger sociotechnical system that includes people (e.g. patients and healthcare providers), healthcare organizations, health IT developers and vendors, processes (actions and procedures performed during the delivery of health care), and the environment of use.
むしろ、それら(ヘルスIT製品と分離できないもの)は、使用の人々(例えば、患者と医療サービス提供者)を含んでいるより大きい社会技術システムの一部と、ヘルスケア組織と、ヘルスIT開発者と、業者と、プロセス(健康管理の配送の間に実行された動作と手順)と、環境である。

3.1 Health IT Product Lifecycle
3.1 ヘルスIT製品ライフサイクル

Stages of the health IT lifecycle include:
ヘルスITライフサイクルのステージは:

1) design and development, 2) implementation and customization, and 3) post-deployment (including upgrades, maintenance, and operations, as well as surveillance, reporting, risk mitigation and remediation) (See FIGURE 1). The safety of health IT relies not only on how it is designed and developed, but also on how it is customized, implemented, integrated and used.

1)設計と開発、2)実現、改造、および3) 配置後(アップグレード、維持、操作、監視、報告、リスク緩和、および改善を含んでいる)(図1参照)
ヘルスITの安全はそれがどう設計されていて、開発されるかだけではなく、それがどうカスタマイズされて、実行されて、統合されて、また使用されるかが重要である。

図1
<図1の説明>
The health IT product lifecycle is depicted. Each stage is characterized by its own distinct considerations for assuring the safe design, development, implementation, customization, integration, and post-deployment use by health care professionals and consumers.
ヘルスIT製品ライフサイクルは表現される。各ステージは、安全設計、開発、実現、改造、統合、およびポスト展開使用を保証するためにそれ自身の異なった問題によってヘルス・ケアの専門家と消費者によって特徴付けられる。
3.2 Sociotechnical system
3.2 社会技術システム

Health IT fits within a complex sociotechnical system.
ヘルスITは複雑な社会技術システムとの相性がよい。

Its successful design, development, implementation, customization and post-deployment use often relies on the integration of many technologies, products, and components by numerous stakeholders.
うまくいく設計、開発、実現、改造、および運用後の(ヘルスITの)使用は、多くの技術、製品および多くの利害関係者によるコンポーネントのインテグレーションに依存する。

Health IT is designed and developed with varying degrees of quality and rigor by many different developers.
ヘルスITは、多くの異なる開発者によって、異なる品質と規格によって設計、開発される。

It is implemented and customized by organizations with heterogeneous experience and expertise, which poses challenges to the seamless integration of health IT into clinical work flows, and for monitoring, identifying, mitigating, and resolving post-deployment issues in a timely manner.

ヘルスITは異種の経験と専門知識を持った組織によって、臨床上のワークフローの中でヘルスITのシームレスな統合に取り組み、習慣的にモニタリングし、特定し、是正し、運用後の問題を解決しようと実装されカスタマイズされる。

Importantly, safety is a property of the larger system that takes into account how the product is designed, developed, implemented, maintained, and used.
重要なのは、安全は製品がいかに設計され、開発され、実装され、保守され、使用されるのかを考慮した大規模システムの一つの資産であるということだ。

In considering how a sociotechnical system affects the development of a risk-based regulatory framework for health IT, the Agencies recognize that the success and the safety of the system as a whole cannot be defined only by the “safety” of individual health IT products themselves.

ヘルスITのために社会技術システムがどのようにリスクベースの規定の枠組みの開発に影響するかを考える際に、関係機関(規制当局)は、個々のヘルスIT製品自体の「安全」だけで、全体としてのシステムの成功(安全)は定義できないと認める。

The components of a health IT sociotechnical system include:
ヘルスIT社会技術システムのコンポーネントとは:

the technology (e.g. the hardware and software of health IT), the people (e.g. individuals working within the system including healthcare providers and implementers of health IT), the processes (e.g. the workflow of healthcare delivery), the organizations (e.g. how an organization installs and configures health IT) and the external environment (e.g. the environment in which the organizations operate).
技術(例えば、ヘルスITのハードウェアとソフトウェア)、人々(例えば、ヘルスITの医療サービス提供者と実装者を含むシステムの中で働いている個人)、プロセス(例えば、ヘルスケアの提供の作業フロー)、組織(組織は、どうヘルスITをインストールして、例えば、構成する)、および外部の環境(例えば、組織が作動する環境)。

The IOM found that several key observations and challenges influence the establishment of a successful health IT system, including:
IOMは、いくつかの主要な観測と課題が以下を含むうまくいっているヘルスITシステムの確立に影響を及ぼすのがわかった。
  1. Poorly designed health IT can create new hazards in an already complex system of health care delivery;
  2. Individual health IT components may meet their stated performance requirements, yet the system as a whole may yield unsafe outcomes;
  3. Problematic events involving complex systems often cannot be ascribed to a single causative factor;
  4. Poor human-computer interactions can contribute to serious injury and death;
  5. Significant knowledge gaps exist in our understanding of the benefits and risks to patients associated with different health IT functionalities.
  1. 設計の不十分なヘルスITはヘルスケアを提供する既に複雑なシステムの中にあって、新たなハザードを生み出す。
  2. 個々のヘルスITコンポーネントはそれらが表明している性能必要条件を満たすかもしれない、しかし、システム全体としては危険な結果をもたらすかもしれない。
  3. しばしば複合システムにかかわる問題の多い出来事はただ一つの原因のせいにすることができるというわけではない。
  4. 貧弱な人間とコンピュータ間のインタラクションは重大な傷害や死の原因となりうる。
  5. 著しい知識の差は異なるヘルスIT機能に関連した患者のリスクと効用の理解の中に存在する。
In summary, an appropriate regulatory framework for health IT should be flexible enough to accommodate innovative, continuously-evolving products undergoing rapid product iterations, upgrades, modifications, and customization, and should account for the complex environment in which the products operate and the multiple stakeholders that play key roles in the successful development, implementation and use of health IT.

概要では、ヘルスITのための適切な規制の枠組みは、急速な製品改版、アップグレード、変更、および改造を受けながら革新的で、絶え間なく発展している製品であるほどフレキシブルであるべきであり、ヘルスITをうまくいっている開発、実現、使用で製品が作動する複合環境と重要な役割をプレーする複数の利害関係者が責任を負うべきである。

【訳者感想】

1980年代に放射線治療器 Therac-25 による死亡事故が発生し、その事故の調査を現MITのナンシー・レブソン教授らが行った。そのときのことを含めて書いた本が SAFEWARE だ。今回の翻訳でIOMが認識しているヘルスITの5つの問題は、ナンシーレブソン教授がSAFEWARE で書いた分析結果と共通点がある。例えば、複雑なシステムの中の設計の不十分なコンポーネントがシステム全体に悪い影響を及ぼす点や、ヒューマンインターフェースの問題や、知識の異なる組織が一つにシステムを構築したことによる問題が Therac-25のソフトウェア開発にもあった。

この5つの問題点はおそらく時代に関係なく、大規模な医療用のソフトウェアに共通する問題なのだろう。

今回の翻訳の中で、大規模なシステムにおいて安全は一つの資産である(safety is a property of the larger system)という一節がある。医療機器となるようなソフトウェアはでは、安全は義務なのだが、リスクが低いヘルスITにおいて安全は資産、すなわち価値になると考えられるということだ。

ヘルスITはネットワーク上で異なる組織が開発したソフトウェアをつなぎ合わせることで、その効果が発揮される。そこに強い制限をかけるとヘルスITの発展を妨げることになる。しかし、ヘルスITには確保すべき患者安全も確実に存在する。ヘルスITの特徴が起因となって発生するリスクについてよくまとめられていると感じる。

製品の安全を個々の製品がリリースするまでで終わらせず、製品同士をつなげてカスタマイズし運用保守するところまでのライフサイクル全体を見なければ安全を確保できないといった点が評価できるし、また、それこそが、ネットワークを使ったITソリューションの時代の安全対策の主流となるのだと思う。機能安全の考え方ではIT社会ではついて行けなくなると思う。

2015-03-10

USのヘルスITの取り組み(5) FDASIA に対するパブリックコメント

2章の残りFDASIAに対するパブリックコメントの概要を訳していく。

2.3.2. Summary of Public Comments in Response to Federal Register Notice

As part of the development of this report, the Agencies sought broad public input on issues related to FDASIA Section 618 through a notice published in the Federal Register25. The Agencies also specifically solicited input on topics identified by the FDASIA Workgroup including health IT taxonomy, risk and innovation, and regulation. Specific questions included:

2.3.2 官報通知に対応したパブリックコメントの概要

このレポートの一部として、関係機関は連邦政府の官報で発表された通知でFDASIAセクション618に関連する問題におけるパブリックコメントを募った。
また、関係機関は明確に「ヘルスIT分類」、「リスクとイノベーション」、および「規制」を含むFDASIAワークグループによって特定された話題に関するコメントを求めた。

具体的な質問は以下を含んでいた。
  • What types of health IT should be addressed by the report developed by FDA, ONC, and FCC?
  • What factors or approaches could be included in a risk-based regulatory approach for health IT to promote innovation and protect patient safety?
  • Are there current areas of regulatory overlap among FDA, ONC, and/or FCC and if so, what are they? If there are areas of regulatory overlap, what, if any, actions should the agencies take to minimize this overlap?
  • How can further duplication be avoided?
  • どんなタイプのヘルスITがFDA、ONC、およびFCCによって開発されたレポートに記述されるべきか?
  • ヘルスITが革新を促進して、患者の安全を保護するように、リスクベースの規制アプローチにどんな要素やアプローチを含むのか?
  • FDA、ONC、そして/または、FCCの中に規則のオーバラップの現在の部門があるとすればそれは何か? 規則のオーバラップの部門や具体的なアクションがあるのならば、関係機関はこのオーバーラップを最小にするか?
  • どのように二重規制を避けられることができるのか?
The Agencies accepted public comment from May 30, 2013 until August 31, 2013, and comments received by June 30, 2013 were also forwarded to the FDASIA Workgroup for consideration.

A total of 39 comments were received from a wide range of stakeholders including the health IT industry, standards developing organizations, insurers, healthcare providers, patient advocates, consumers, the medical device  industry,  associations  representing  hospitals, pharmaceutical research and biotechnology companies, broadband  and  telecommunications  companies,  and non-profit policy and medical research organizations. Commenters recognized both the  benefits and risks to patients of health IT. Comments received proposed the following key characteristic requirements for the framework:

関係機関は2013年5月30日から2013年8月31日までパブリックコメントを受け入れた。そして、2013年6月30日までに受け取ったコメントはFDASIA ワークグループにも送り届けられた。

健康情報技術産業、組織、保険会社、医療サービス提供者、患者活動家団体、消費者、医療機器産業、病院を代表する協会、薬学研究、バイオ企業、ブロードバンド通信企業、非営利組織政策、および医学の研究組織を含むさまざまな利害関係者から合計39のコメントを受けた。

評者はヘルスITの患者(利用者)に利益とリスクの両方があることを認めた。コメントはフレームワークのための提案された以下主要な要求を含んでいる:

Public Comments Received on Taxonomy:
  • Health IT should be assigned into one of three categories: administrative software, clinical software, and medical device software.
  • The full range of health IT products should be reviewed to carefully judge the risk to patients.
パブリックコメントは分類に関して受け取られた:
    • ヘルスITは3つのカテゴリの内の1つに割り当てられるべきである。:(健康)行政用ソフトウェア、臨床用のソフトウェア、および医療機器ソフトウェア。
    • ヘルスIT製品の範囲は、患者へのリスクを判断するために慎重に見直されるべき。
    Public Comments Received on Risk and Innovation:
    • Risk assessment for health IT should focus on functionality.
    • A health IT learning environment should be created through the aggregation and analysis of data to identify and monitor trends, mitigate future risk, and facilitate learning and improvement.
    • Health IT should use existing voluntary safety reporting systems, and patient safety adverse events should be reported in a non-punitive environment by leveraging Patient Safety Organizations.
    • Health IT should leverage recognized standards for assuring patient safety.
    パブリックコメントはリスクとイノベーションに関して受け取られた:
    • ヘルスITのためのリスクアセスメントは機能性に焦点を合わせるべきである。
    • ヘルスITの学習環境は、(ヘルスITの)傾向と、将来のリスク対策と学習及び改善環境をモニタしてそして特定するためのデータ分析と集積を通して作成されるべきである。
    • ヘルスITは既存の自発的な安全報告システムを使用するべきある。そして、患者の安全有害事象は、非懲罰的な環境で患者安全関連機関に報告されるべきである。
    • ヘルスITは、患者安全を保証することのために推奨された規格に影響を及ぼさなければならない。
    Public Comments Received on Regulation:
    • The health IT regulatory framework should be flexible, agile and evolving to encompass future technology solutions and capabilities without being narrowly prescriptive.
    • Quality Management Systems should allow manufacturers to apply a single process that satisfies the requirements of all agencies. Existing safety and quality-related processes, systems, and standards should be leveraged for patient safety in health IT.
    • Clinical software development should adopt quality management principles and processes, and apply applicable standards.
    • Agency roles should be clarified and avoid overlap. The Agencies individual focuses, such as ONC’s focus on privacy, security and health IT infrastructure, and FDA’s focus on public health and safety, should be delineated and maintained.
    • Emphasis should be placed on the importance of interoperability. The inability of systems to easily and reliably share data can pose safety risks. Due to the current lack of clear or complete oversight of health IT interoperability, a national strategy should be developed to create efficient, standardized data exchange that promotes the  safe use of the data that has been exchanged; identify funding to support development of standards; and establish interoperability standards that reflect today’s need for rapid development and adoption.
    • +Outreach activities should be conducted to provide opportunities for collaboration and public input.  Examples of outreach would include: ongoing development and dissemination of best practices in the safe design, development, deployment and use of EHRs; creation of useful guidance; and proactive education of developers, through user friendly web-based information and face-to-face educational programs.
    パブリックコメントは「規定」に関して受け取られた:
    • ヘルスIT規制の枠組みはフレキシブルで、アジャイルで、未来の技術解決につながり、狭い規制の概念を排除した可能性に発展させるべきである
    • 品質マネジメントシステムは製造業者にすべての政府機関の要件を満たすただ一つのプロセスを適用させるべきである。既存の安全、品質関連のプロセス、システム、および規格はヘルスITにおける患者の安全のために発出されるべきである。
    • 臨床用のソフトウェア開発は品質管理の原則とプロセスを採用して、適用規格を当てはめるべきである。
    • 政府機関の役割ははっきりさせて、オーバラップを避けるべき。公衆衛生と安全の上のプライバシーとセキュリティとヘルスITインフラストラクチャ、およびFDAの注目点のONCの注目点などの政府機関の個々の焦点は、図で表わされて、メインテナンスされるべきである。
    • インターオペラビリティ(相互運用性)が強調され、重要性を置くべき。システムがデータを簡単に、そして確実に共有できないことがリスクを引き起こす。ヘルスITのインターオペラビリティ(相互運用性)の不完全性のために、交換し合われたデータの安全な使用を促進する、効率的な、標準化されたデータ交換を作成するために、国家戦略は開発されなければならない;
    • 支援活動は、機会を協同と公的な入力に提供するために実行されなければならない。支援活動の例は、以下を含む:
    • 安全な設計、開発、配備とEHR(electronic health record :電子健康記録)の使用、役立つガイダンスの作成、ガイダンスの作成;そして、開発者の率先的な教育(ユーザーフレンドリーなウェブ・ベースの情報と Face to Faceの教育プログラムを通しての)。
    パブリックコメントは訳を飛ばそうかなと思ったが、そうしなくてよかった。パブリックコメントは「ヘルスIT分類」、「リスクとイノベーション」、および「規制」の3つのカテゴリに対して集められた。

    ヘルスIT分類は対象とするヘルスITをどのように分類すべきかということで、規制対象にするのかしないのかその中間が必要かといったことをテーマとしている。この議論の結論は後にFDAがモバイルメディカルアプリケーションガイダンスを正式発行したときに明らかになった。USでは日本では定義することが難しい「医療機器とは認めるがFDAが裁量権を行使して規制しない」というグレーゾーンを作った。このカテゴリはパブリックコメントも考慮してFDASIA ワークグループのディスカッションした結果だと思われる。

    「リスクとイノベーション」はヘルスIT利用者のリスクを重要視する必要性を認めた上で、ヘルスITのイノベーションを阻害しないためにはどうしたらよいかという観点である。「規制」に関するコメントでは、各政府機関が着目する点を図示してくれとか、規制として要求するプロセスはひとつになるようにしてくれといった現実的かつ切実な意見が出ている。

    次回からは3章 ヘルスITライフサイクルと社会技術システムの考慮 に入る。