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ライフサイクルと社会技術システムの考慮 に入る。