2009 年度 JCG eCT チーム 活動報告

1. 2009年度　JCG eCTチーム活動報告 March 27, 2009 eCT Members

2. ＲＦＤとは Retrieve Form for Data Capture (RFD)は、医療機関にある 医療情報システムのデータを外部で要求される様式（フォーム） で収集する方法である。例えば、電子カルテ（ＥＨＲ）のデータか ら各種報告書を効率よく作成するために使われる。 このRFDは、CDISCとIHEとの共同によりその技術的な仕様が 議論されている。 （注）　EHR: Electronic Health Record 　　　　（通常、EMR（Electronic Medical Record)を電子カルテと呼び、EHRは生涯電子カルテといい区別されるが、 　　　　　ここでは、EHRを一般的な電子カルテと呼ぶ。） IHE: Integrating the Healthcare Enterprise (IHEは放射線部門で培った病院情報の連携をベースにして、医療情報システムの普及による 情報連携の世界的な展開を目標にしています。 　　　　　日本IHE協会 （IHE-J）は、病院情報の相互運用性普及プロジェクトに参画し、 　　　　　システム間の相互接続性を確立すべく活動している。）

3. Trial Registry Clinical Trials Secondary Use Safety Biosurviellance RFDを利用しない場合、医師は各種の用件に合わせて複数回データの再入力を行う必要があり、データそのものが再利用されることはない。 Primary Use EHR

4. Clinical Trials Trial Registry Secondary Use Safety Biosurveillance EHR RFDを利用すると、EHRにすでに入力されているデータを自動的に再利用することができる。 そして、外部機関にEHRからデータを収集することを許可することができる。 Primary Use ＣＤＩＳＣ２００８年インターチェンジ で発表された実証実験のケース

5. ＲＦＤの構造 ＲＦＤ EHR Form Filler Form Manager ①Retrieve Form ②Pre-Population XForm Not for SDV Form Receiver ④Submit Form ③Supplemental Data Entry ⑤Archive Form Certified Copy Sponsor Source Data for SDV Form Archiver

6. ＲＦＤのフロー 出典：「Retrieve Form for Data Capture」 CDISC, Dave Iberson-Hurst氏資料より

7. ＲＦＤのフロー 出典：「Retrieve Form for Data Capture」 CDISC, Dave Iberson-Hurst氏資料より

8. Site Site Site ＲＦＤは複数のＥＨＲと連携可能 Sponsor 出典：「Retrieve Form for Data Capture」 CDISC, Dave Iberson-Hurst氏資料より

9. ＥＨＲとＣＤＩＳＣの関係（ＲＦＤを使わない場合）ＥＨＲとＣＤＩＳＣの関係（ＲＦＤを使わない場合） Electronic Health Record =ODM(トランスポート) =SDTM、解析データ（コンテンツ） 被験者情報 施設 =プロトコールの情報（コンテンツ） 臨床試験データ =ソースデータ（SDTM/CRFデータ以外） =HL7(トランスポート) ODM XML スポンサー ODM XML CRF,解析データ ODM XML ODM XML Define.xml CRFor eCRF (CDASHより定義) ODM XML (e)ソース ドキュメント オペレーショナル＆ 解析データベース 規制当局への 申請 臨床試験 プロトコール 臨床試験 メタデータ 再入力 被験者情報 EDC 臨床試験データ 統合された レポート 被験者情報 管理、 トラッキング、Lab 収集情報 Protocol Representation SDTMデータ、 解析データ、 メタデータ 試験デザイン (SDTM) 解析計画 臨床試験データ (SDTMにより定義)

10. ＥＨＲとＣＤＩＳＣの関係（ＲＦＤ導入後） Electronic Health Record =ODM(トランスポート) =SDTM、解析データ（コンテンツ） 被験者情報 =プロトコールの情報（コンテンツ） HL7 臨床試験データ =ソースデータ（SDTM/CRFデータ以外） 施設 Archive =HL7(トランスポート) ODM XML or HL7 ODM XML orHL7 ODM XML or HL7 スポンサー ODM XML or HL7 CRF,解析データ ODM XML ODM XML Define.xml CRFor eCRF (CDASHより定義) ODM XML (e)ソース ドキュメント オペレーショナル＆ 解析データベース 規制当局への 申請 臨床試験 プロトコール 臨床試験 メタデータ RFD 統合された レポート 被験者情報 Protocol Representation 管理、 トラッキング、Lab 収集情報 SDTMデータ、 解析データ、 メタデータ 試験デザイン (SDTM) 解析計画 臨床試験データ (SDTMにより定義)

11. ＲＦＤの適用ユースケース例 1. Investigational New Drug Clinical Trial Use Case • 新薬臨床試験ユースケース 2. Public Health Reporting Use Cases ・Public Health Scenario 1 • 感染症サーベイランス・シナリオ ・Anthrax & Avian Influenza Scenarios • 炭疽病、鳥インフルエンザ・シナリオ 3. Pharmaco-vigilance Scenario • 医薬品安全性情報シナリオ 4. Cardiology Research Use Cases • 心臓病研究ユースケース 5. Radiology Use Case – Clinical Impact Registry • 放射線ユースケース

12. ＲＦＤの米国の現状（実証実験の事例） IHE Interoperability Showcase Clinical Trial Scenario: utilizing the RFD (Retrieve Form for Data Capture) Profile to streamline the flow of clinical trial data from the clinical site to the sponsor … Scenario Stakeholders (RFD Actor Role): = Trial Sponsor = EHR system at a clinical trial site (Form Filler) = CRO responsible for data aggregation and data management using Clintrial data management system (Data Receiver) = Repository for the forms (Form Manager) and the site’s clinical trial data (Data Archiver) 出典：「Electronic Health Records - Streamlining Data Collection」 　　　　　　クインタイルズ社ＧａｒｙＷａｉｋｅｒ氏資料より

13. ＲＦＤの米国の現状（実証実験の事例） 出典：「Electronic Health Records - Streamlining Data Collection」 　　　　　　クインタイルズ社ＧａｒｙＷａｉｋｅｒ氏資料より

14. ＲＦＤの米国の現状（実証実験の事例） 出典：「Electronic Health Records - Streamlining Data Collection」 　　　　　　クインタイルズ社ＧａｒｙＷａｉｋｅｒ氏資料より

15. Defining the Value of RFD ＲＦＤの米国の現状（実証実験の事例） • Flexible RFD will accommodate different site functionality (manual data entry to hybrid to fully electronic environments) • User Friendly Minimizes data transcription Integrates research into the EHR workflow Utilizes standard process across sponsors/studies • Efficient Minimizes data transcription Leverages existing EHR systems at sites Changes the focus of site monitoring …RFD has the potential to be disruptive as well as transformational to clinical research …. 出典：「Electronic Health Records - Streamlining Data Collection」 　　　　　　クインタイルズ社Ｇａｒｙ　Ｗａｉｋｅｒ氏資料より

16. 統計解析ソフト ＊CDISC SDTM, ADaM でデータ蓄積・統計解析 CDISC標準対応医療系 臨床・疫学研究支援システム CDISC LAB CDISC ODM 臨床検査会社 CDISC ODM CDISC ODM 既存Web（HTTP） で通信 CDISC標準クライアントのHIS/EMR組込み 単独型CDISC 標準クライアント ＊CDISC CDASH、 PR等でデータ入力 画面作成 ＊CDISC CDASH、PR等でデータ自動抽出、 データ入力画面作成 ＊各医療機関内で 診療科別DB自動作成 CDISC ODM 医療機関内 各診療科別 研究用DB 日本でのＣＤＩＳＣ対応状況（ＲＦＤは未使用） ～東大病院（ＵＭＩＮセンター）でのCDISC標準に基づく治験電子化の全体イメージ～　

17. 日米における電子カルテの現状 １．米国での電子カルテの状況 P4P（Pay for Performance：特定の疾患に対する薬剤の投与率など、医療のプロセスやアウトカムの評価に応じて診療報酬を支払う制度）の広がりが普及を促進。 a） 保険会社からの強いコスト削減圧力を受け、医療そのものの効率化を情報化の第一目的としている。例えば、検査や投薬などについて治療ごとに原価計算を行なう機能や、医師単位で収益評価をおこなう機能などを重視している点が特徴的である。また、治療の標準化を念頭においた診療プロセスモデルの開発にも重点を置いている。 b） 各病院はデータ交換の標準規格であるHL7（Health Level7）に従って電子カルテシステムを構築しているので、技術的には病院間のシステムの連携が可能となっている。標準化の観点では、わが国よりも先行している。 　 c） わが国では医師本人がデータの入力をおこなっているが、米国では医師の口述に基づき病院の事務員や外部のDictation Centerの職員が入力している。　 また、近時の動向としては、院内だけのネットワークにとどまらず、地域内の医療機 関で一つの情報ネットワークを構築する動きが見られる。

18. 日米における電子カルテの現状 ２．日本での電子カルテの状況 　　　経済的インセンティブが少ないため、国が主導して普及を促している。目標通りには 　　　進捗していないが、着実に普及が進んでいる。 a）電子カルテ普及状況（２００７年データ株式会社シードプランニング調査結果より） 　・４００床以上のベッドを有する大病院での電子カルテ導入普及率は３７．７％ 　・１００〜３９９床の中規模病院での普及率は１４．８％ 　・診療所での電子カルテの普及率は、１０％を超えた。新規開設の診療所では 　　７０％以上が導入 b）連携における標準化への取り組み 　・経済産業省主導で、「医療情報システムにおける相互運用性の実証事業(H17年～19年）」を実施。「相互運用性を確保した医療情報システム導入ガイド」(H20.３)が提示。 　・厚生労働省「電子的診療情報交換推進事業（SS-MIX：Standardized Structured Medical Information eXchange）」 SS-MIX：標準的な診療情報の交換を可能にするための厚生労働省電子的診療情報交換推進事業。 　　施設の申請があれば、ゲートウェイソフトを無償提供。

19. A. 一般事項 質問A-1 A-1: なぜRFDとの新しい手法を採用したのか？PRやODMの定義から入力Formを作成することは可能だと思われるが？ • CDISC chose RFD because it provides capability that adds value to CDASH and ODM. ODM and CDASH provide the structure for the case report form. But ODM and CDASH do not provide a mechanism for displaying the case report form within an electronic medical record. RFD provides that mechanism. RFD is of very little value by itself. RFD’s value increases as it is implemented in cooperation with ODM and CDASH. In our demonstration of RFD, the case report forms use ODM and CDASH to structure the document and to define the content. • RFD add the important capability for the electronic medical record to access the case report form and to display the case report form. An EDC system can create the case report form using ODM and CDASH. Then the EDC system can set up an RFD Form Manager server which allows the electronic medical record’s Form Filler to retrieve that form. The only difference between this use case and the traditional EDC set up is that the site user sees the case report form inside of the electronic medical record rather than on a separate laptop. • So, in summary, RFD is a way to extend the use of ODM and CDASH by taking the case report form into the electronic medical record.

20. A. 一般事項 質問A-2, A-3 A-2:Form Archiver （内のデータ）は施設側とスポンサー側のどちらで管理 すべきものなのか? • In order for the archive to function as the electronic source document, it must remain under the purview of the site. • Note that the archiver is an optional actor. If there is no need for a site-base eSource document, the archiver can be eliminated. A-3:Form Archiver （システム）は誰が管理するものなのか？ • The Form Manger would typically done by the same agency as the Form Receiver. Usually this would be an EDC system, or a sponsor system. • The Form Archiver must be under the stewardship of the site, and must be free of the sponsor. Within that construct, the Archiver could be physically done by the site itself, or by a trusted third party on behalf of the site.

21. B. セキュリティ関連事項 質問B-1, B-2, B-3 B-１: ユーザー管理機能はどのようになるのか？ • Currently, the EHR must maintain two ‘identities’ in the patient index. The idea is that the user’s account and password serve for access to the form. The user should not have to identify himself just to access the form, but the EHR should pass the identity forward. • In future we will look at PIX, a IHE profile for patient identity exchange. B-2: 各スポンサーの各試験に事前に登録されたUserがデータを送信したことを 検証する手立てはあるのか？ • Since the forms pop up in the context of the EHR, filling out the form should be expected.⇒　質問を誤解？　　再質問要。 B-3: 臨床試験よりは安全性報告に向いていると思われるが？ （臨床試験ではクリアしないといけない事項がいろいろとある） • Yes. A site in Boston, Partners hospital, has used RFD to capture MedWatch reporting, and has now captured 100 reports. The site went live in November 2008.

22. C. AUDIT関連事項 質問C-1 C-１:Queryやその回答，回答した理由，変更しなかった理由などはどのように 管理できるのか？ • The use case for clarification is still under development. I am going to forward this question to Jane Griffin of Cerner, who has more experience than I do in this matter.

23. D. SDV関連事項 質問D-1, D-2 D-１:SDVはどのように実施するのか？　ＳＤＶは本当に不要になるのか？ • Source Data Verification should be greatly improved by RFD. If the Archive is accepted as source document (still under consideration by RFA), then verification is simply a matter of comparing the data received by the Forms Receiver to the data retained at the site in the Forms Archiver. D-2:どのように Form Archiver と元資料の内容が同一であると検証し， 保証するのか? • In the best case, the Forms Archiver will contain the Source Document, pure and simple, and there will be no need to visit the EHR at all. Since the data from the EHR are pre-populated and then reviewed by the user before submittal, we have a strong case that the data submitted are freed from the EHR and begin a new life in the Manager/Archiver.

24. D. SDV関連事項 質問D-3, D-4 D-3: EHR内のコメントから抽出したデータがForm Archiverに保存されるが？ • We simply don’t knowwhat the regulators will decide. But the use of the narrative data to feed the additional data for the form is interpreted by the user, not copied. One could argue that the interpretation creates new data, and that the chain of custody begins at that point. D-4: EHRの内容にロジカルエラーがある場合、どのように検出される？ • It is the responsibility of the user to clarify any inconsistencies before submitting the form. The data from the EHR should be seen as suggested data for submission, and only accepted if the user reviews and approves them.

25. Members

26. Strength through collaboration. THANK YOU!