ＲＦＤとは Retrieve Form for Data Capture (RFD)は、医療機関にある

Presentation on theme: "ＲＦＤとは Retrieve Form for Data Capture (RFD)は、医療機関にある"— Presentation transcript:

0 2009年度 JCG eCTチーム 活動報告 March 27, 2009 eCT Members The CDISC ODM
これまでは、ＲＦＤの理解と米国での現状をスタディしました。 August 22, 2007

1 ＲＦＤとは Retrieve Form for Data Capture (RFD)は、医療機関にある
The CDISC ODM ＲＦＤとは 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）は、病院情報の相互運用性普及プロジェクトに参画し、 　　　　　システム間の相互接続性を確立すべく活動している。） 補足として、 ・2次利用についての説明→重複してデータを入力しないで済むことを説明。 ・ＥＨＲの外部にＲＦＤをおいて、外部（製薬会社）が使うデータとしての担保（バリデーションなど）の必要性をＥＨＲから外したことを説明。 August 22, 2007

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

3 Secondary Use Primary Use Clinical Trials Trial Registry Safety
The CDISC ODM Biosurveillance Safety Trial Registry Clinical Trials Secondary Use EHR RFDを利用すると、EHRにすでに入力されているデータを自動的に再利用することができる。 そして、外部機関にEHRからデータを収集することを許可することができる。 Primary Use 実証実験の規模、結果は？期間 2008年インターチェンジで発表 ＣＤＩＳＣ２００８年インターチェンジ で発表された実証実験のケース August 22, 2007

4 ＲＦＤの構造 ＲＦＤ EHR Form Filler Form Manager ①Retrieve Form ②Pre-Population
The CDISC ODM ＲＦＤの構造 ＲＦＤ 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 ①Retrieve Form:フォームフィラが、フォームマネージャに対して該当するフォーム（FormID指定）の書式を要求し、フォームマネージャからの応答として書式（XFormで記述されたxhtml）を受け取る。 ②Ｐｒｅ-Population：XFormのデータモデルのインスタンスに対してEHR内部データを読み込んで値を自動付与する。 ③Supplementary Data Entry：付加情報を入力する。 ④Submit Form: フォームフィラが、ユーザまたはEHRにより入力・付加されたデータ(書式に定められているXFormデータモデルのインスタンスとなるxml)をフォームレシーバに対して受け渡す。 ⑤Archive Form: （Submit Formと同様に）フォームフィラが、フォームアーカイバに対してデータを受け渡す。フォームアーカイバに格納されたデータが、ＳＤＶのソースデータとなる。 Source Data for SDV Form Archiver August 22, 2007

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

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

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

8 ＥＨＲとＣＤＩＳＣの関係（ＲＦＤを使わない場合）
The CDISC ODM ＥＨＲとＣＤＩＳＣの関係（ＲＦＤを使わない場合） 臨床試験データ CRF,解析データ 被験者情報 規制当局への 申請 (e)ソース ドキュメント オペレーショナル＆ 解析データベース Electronic Health Record (SDTMにより定義) ODM XML ODM XML Define.xml 管理、 トラッキング、Lab 収集情報 SDTMデータ、 解析データ、 メタデータ 統合された レポート 臨床試験 プロトコール 試験デザイン (SDTM) 解析計画 Protocol Representation =SDTM、解析データ（コンテンツ） =ODM(トランスポート) =プロトコールの情報（コンテンツ） =ソースデータ（SDTM/CRFデータ以外） =HL7(トランスポート) スポンサー 施設 CRF or eCRF (CDASHより定義) EDC 再入力 施設では、電子カルテに入力したデータは、システム内だけの利用に留まっている。 医薬品安全性情報報告、または臨床試験で必要なデータが電子カルテ内に既にあっても、再度入力する必要が発生している。 【HERとCDISCの関係】 EHRはHL7を用いて標準化している。スポンサー側はCDISCを用いて標準化している。 しかし、それぞれ独立した関係である。 【図の説明】 CDISC側（スポンサー）の図は、CDISC作成の資料「CDISC標準を用いたデータフロー」を利用している。 追加したのは、「CRF or eCRF(CDASHより定義）」の部分である。 August 22, 2007 8

9 ＥＨＲとＣＤＩＳＣの関係（ＲＦＤ導入後）
The CDISC ODM ＥＨＲとＣＤＩＳＣの関係（ＲＦＤ導入後） 臨床試験データ CRF,解析データ 被験者情報 規制当局への 申請 (e)ソース ドキュメント オペレーショナル＆ 解析データベース Electronic Health Record (SDTMにより定義) ODM XML ODM XML Define.xml 管理、 トラッキング、Lab 収集情報 SDTMデータ、 解析データ、 メタデータ 統合された レポート 臨床試験 プロトコール 試験デザイン (SDTM) 解析計画 Protocol Representation =SDTM、解析データ（コンテンツ） =ODM(トランスポート) =プロトコールの情報（コンテンツ） =ソースデータ（SDTM/CRFデータ以外） =HL7(トランスポート) HL7 スポンサー ODM XML or HL7 施設 RFD CRF or eCRF (CDASHより定義) Archive 医薬品安全性情報報告書、及び臨床試験で必要なデータは、電子カルテから自動で取り出すことが可能になる。 同じデータの2重入力が無くなる。 【EHRとCDISCの関係】 EHRはHL7を用いて標準化している。スポンサー側はCDISCを用いて標準化している。 １．スポンサー側は臨床試験で収集したいデータの情報（メタデータ）を、CDASHで定義する。 ２．RFDはCDASHの定義を解析し、RFD Formを作成する ３．RFD Formに対応する電子カルテ上にあるデータを、HL7を利用して対応する項目に取り出す。 つまり、RFDがHL7（HER：電子カルテ）とCDASH（CDISC：スポンサーデータベース）とのマッピングをすることになる。 （必要な項目を全て埋まったら、サブミットする。このときのデータをArchiveとして保存可能である。） 【懸念事項】 １．CSV　(Computerized　System　Validation） RFDが実現したら全てのデータがオンラインデータ上で作成されることになる。ここで問題になるのが、電子カルテシステムのER/ES指針、CSVの問題である。 CSVは新規導入時も大変であるが、維持がさらに大変である。このコストや労力を施設側が負担するのは現実的ではない。 RFDは、この問題をEHRから切り離す試みである。FormArchiverに格納されるデータがソースデータとなる。 現在FDAは、実証実験の結果を通じて、CSVにおけるRFDの有効性を見ている状況にある。 ２．電子カルテシステムの標準化 電子カルテシステムは、ほとんどのシステムがHL7を利用している。しかし、HL7は細かいところで定義しているわけではない。病院間で簡単にデータのやり取りが出来るわけではない。この問題をいかに解決するかが大きな問題である。 日本においては、SS-MIXが、その解決策の一つと考えられる。 【RFD外の仕様】 Protocol Representationの情報を施設サイトに渡すことが出来たほうが良いが、RFDでは触れていない。 August 22, 2007 9

10 ＲＦＤの適用ユースケース例 1. Investigational New Drug Clinical Trial Use Case
The CDISC ODM ＲＦＤの適用ユースケース例 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 放射線ユースケース 適用例 August 22, 2007

11 IHE Interoperability Showcase
The CDISC ODM ＲＦＤの米国の現状（実証実験の事例） 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」 　　　　　　クインタイルズ社ＧａｒｙＷａｉｋｅｒ氏資料より August 22, 2007

12 ＲＦＤの米国の現状（実証実験の事例） The CDISC ODM ＲＦＤの５つのＲＦＤ実証実験の一つ。
臨床試験におけるＶｉｓｉｔ　ＷｏｒｋＦｌｏｗの実証実験。 他の事例 ・「医薬品安全性情報」　ファイザー ・「臨床試験における臨床検査データと画像データ」　ノバルティス ・「疾病登録」　ジェンザイム（ＧＥＮＺＹＭＥ） ・「バイオサーベイランス」　ザイック（ＳＡＩＣ） 出典：「Electronic Health Records - Streamlining Data Collection」 　　　　　　クインタイルズ社ＧａｒｙＷａｉｋｅｒ氏資料より August 22, 2007

13 ＲＦＤの米国の現状（実証実験の事例） The CDISC ODM データクリーニング
出典：「Electronic Health Records - Streamlining Data Collection」 　　　　　　クインタイルズ社ＧａｒｙＷａｉｋｅｒ氏資料より August 22, 2007

14 Defining the Value of RFD
The CDISC ODM ＲＦＤの米国の現状（実証実験の事例） 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 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」 　　　　　　クインタイルズ社Ｇａｒｙ　Ｗａｉｋｅｒ氏資料より August 22, 2007

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

16 日本でのＣＤＩＳＣ対応状況（ＲＦＤは未使用） ～EDC以外のCDISC標準活用法 ー診療科別電子カルテ運用イメージ～
The CDISC ODM 日本でのＣＤＩＳＣ対応状況（ＲＦＤは未使用） ～EDC以外のCDISC標準活用法　ー診療科別電子カルテ運用イメージ～ 医学研究用データ交換 CDISC標準 診療用データ交換 当面：HL7 Ver. 2（患者基本情報、検査・処方情報交換） 将来：EHR Communication(電子カルテ情報交換）？ 病院情報システム 中央サーバ １）電子カルテ機能（将来＝＞各科別に希望の電子カルテが使えるのが理想） ２）診療科用医学研究データベース機能 ３）多施設研究への参加機能（将来） 診療科別総合 臨床情報システム 多施設医学研究データ収集サーバ （臨床試験、臨床疫学研究、症例登録） 医療機関内 外部 削除 August 22, 2007 16

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

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

19 The CDISC ODM 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. ・ＲＦＤはＥＨＲからのデータを取り込んだＣＲＦを表示する機能を提供できる。 ・ＲＦＤを使うことによって、施設側は、ＥＨＲのシステムからＣＲＦ表示画面を呼び出すことができる。 ・ＲＦＤは、上記のような機能を提供することで、ODM、ＣＤＡＳＨの有用性を広げている。 August 22, 2007

20 The CDISC ODM 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. Ａ－２ ・フォームアーカイバーはソースドキュメントの格納場所なので、施設側の管理下に置かれる。 ・ソースドキュメントを電子的に保管する必要がないのであれば、フォームアーカイバーはいらない。 Ａ－３ ・フォームレシーバーは、フォームアーカイバーを管理する（ＥＤＣなどの）システムに置かれる。 ・フォームアーカイバーは、施設側の管理で、スポンサーから切り離されている必要がある。（物理的にも） August 22, 2007

21 B. セキュリティ関連事項 質問B-1, B-2, B-3 B-１: ユーザー管理機能はどのようになるのか？
The CDISC ODM 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. August 22, 2007

22 C. AUDIT関連事項 質問C-1 C-１: Queryやその回答，回答した理由，変更しなかった理由などはどのように 管理できるのか？
The CDISC ODM 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. Ｃ－１ ・Ｃｌａｒｉｆｉｃａｔｉｏｎの方法はまだ開発中。 August 22, 2007

23 D. SDV関連事項 質問D-1, D-2 D-１: SDVはどのように実施するのか？ ＳＤＶは本当に不要になるのか？
The CDISC ODM 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. Ｄ－１ ・ＳＤＶのプロセスは、ＲＦＤで非常に改善されるはず。 ・アーカイバーをソースデータとして見つめるか否かは、ＦＤＡ？で検討中 Ｄ－２ ・ＥＨＲからソースドキュメントを単純に読み込んで、（アーカイバーに）登録する前にユーザーがレビューしているから、ＥＨＲを検証する必要がない。 August 22, 2007

24 D. SDV関連事項 質問D-3, D-4 D-3: EHR内のコメントから抽出したデータがForm Archiverに保存されるが？
The CDISC ODM D-3: EHR内のコメントから抽出したデータがForm Archiverに保存されるが？ We simply don’t know what 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. Ｄ－３ ・コメント（所見などの自由記述データ）の取り扱いについては、当局の規定はない。 ・自由文書であっても登録前に、フォームフィラーの中でレビューされ、意味づけられるのであれば、そこからソースデータとして位置づけられる。 Ｄ－４ ・ＥＨＲのエラーは、ＥＨＲ側の問題で、ＥＨＲ側で検出されるべき。 August 22, 2007

25 Members 鈴木 康平 SymBio Pharmaceuticals Limited 市山 紀子
The CDISC ODM Members 鈴木　康平 SymBio Pharmaceuticals Limited 市山　紀子 Quintiles Transnational Japan K.K. 羽地　博 Sanofi-aventis K.K. 藤澤　欣一 Baxter Limited 林　正博 NTT Data Business Consulting Corporation 島崎　肇 Medical Front Corporation 井上　晃一 Wyeth K.K. 千葉　吉輝 University hospital Medical Information Network(UMIN) 林　三男 Dainippon Sumitomo Pharma Co.,Ltd. 岩武　敦司 Mitsubishi Tanabe Pharma Corporation 西　基秀 Astellas Pharma Inc. 石田　美里 Astellas Pharma Inc. （議事等） August 22, 2007

26 Strength through collaboration.
THANK YOU! Strength through collaboration. 26