Integrated Trial Matching for Cancer Patients and Providers

| | Integrated Trial Matching for Cancer Patients and Providers Phase 1 Planning Draft for Discussion (2 July 2020) HL 7® FHIR® is a registered trademark owned by Health Level Seven International®

Integrated Trial Matching for Cancer Patients and Providers Clinical trial matches for the patient are returned in a standard FHIR Research Study format, viewable by: 1. The patient and provider via the EHR 2. The patient via the patient portal 3. The patient via a Patient Data Manager platform Clinical Trial Matches Investigators want to find eligible patients to enroll in clinical trials. Clinical Trial Matches m. CODE++ Clinical Trial Matches Patient Treatment Data Clinical Trial Matches Third Party Trial Matching Services Retrieve Map Clinical Trial Information m. CODE++ FHIR m. CODE++ Extraction (as needed) Patients want to identify clinical trials for which they may be eligible. |2| Patient data is entered into the EHR, extracted and transformed into m. CODE++ format, and then sent via FHIR to clinical trial matching services – an interim solution until the time when EHRs natively support m. CODE and FHIR. m. CODE++: leveraging m. CODE with possible extensions

Multi-Phased Approach Phase 2: Prospective Pilot § Patient m. CODE Data § 2+ Matching Services § Integrated Patient UI o Demonstration of value of P-CT matching service to patients, providers, and trial investigators Phase 1: Retrospective Study Phase 0 – Near Completion § De-Identified m. CODE Data § 2+ Matching Services § Standalone Patient UI Phase 0: Standards Development § Synthetic m. CODE Data § Single Matching Service § Standalone Patient UI o o m. CODE Patient Records m. CODE Matching Service API Open Source POC Implementation Standardized match outputs/results o Demonstration of m. CODE-enabled interoperable Matching Services o Evaluation of minimal eligibility criteria to support P-CT matching q ↑ # of trials identified outside of a patient’s treating institution q ↑ ability to meet trial enrollment targets at a participating site q ↑ # patients enrolled in trials from sites where trial options do not exist q user experience (e. g. , survey) q ↑ or comparable quality of matches relative to traditional patient-facing matching options when using minimal criteria q (initial indications) sensitivity analysis – impact of additional criteria on quality of matches q ability for other matching services (beyond initial matching service) to implement this capability Scale to widespread adoption of m. CODEbased Patient-Clinical Trial Matching standards / open API Key Phase Required artifacts/activities o Outputs q Notional success measures POC: Proof of Concept P-CT: Patient – Clinical Trial UI: User Interface API: Application Programming Interface

Filters Needed to Support Minimal Eligibility Criteria • Cancer Type • • Cancer Subtype Biomarker Status Stage Presence of Metastases • Age • Treatments Required Filters and m. CODE Mapping 1. 2. 3. 4. 5. 6. Primary. Or. Uncertain. Behavior. Cancer. Disorder. VS Histology. Morphology. Behavior. VS HGNCVS Tumor. Marker. Test. VS TNMStage. Group. VS Secondary. Cancer. Disorder. VS 7. Age derived from birthdate in Cancer. Patient profile (filter already exists) 8. Radiation. Procedure. VS 9. Cancer Related Medication Statement 10. Cancer-Related. Surgical. Procedure. VS

Phase 0: Artifacts § m. CODE Patient Records § https: //confluence. hl 7. org/display/COD/m. CODE+Test+Data § m. CODE Matching Service API § https: //github. com/mcode/clinical-trial-matching-engine/wiki § Open Source Proof of Concept Implementation § https: //github. com/mcode/clinical-trial-matching-engine (User Interface) § https: //github. com/mcode/clinical-trial-matching-service (Wrapper for Trial. Scope) § Standardized Match Outputs / Results § https: //www. hl 7. org/fhir/researchstudy. html |5|

|6| Phase 0: Proof of Concept Implementation Web Application Additional Search Criteria Synthetic Patient Records (in m. CODE) Clinical Trial Matches Third Party Trial Matching Services m. CODE++ (including Minimum Eligibility Criteria) • Trial. Scope • …

Multi-Phased Approach Focus of this presentation Phase 2: Prospective Pilot § Patient m. CODE Data § 2+ Matching Services § Integrated Patient UI Phase 1: Retrospective Study § De-Identified m. CODE Data § 2+ Matching Services § Standalone Patient UI Phase 0: Standards Development § Synthetic m. CODE Data § Single Matching Service § Standalone Patient UI o o m. CODE Patient Records m. CODE Matching Service API Open Source POC Implementation Standardized match outputs/results o Demonstration of m. CODE-enabled interoperable Matching Services o Evaluation of minimal eligibility criteria to support P-CT matching o Demonstration of value of P-CT matching service to patients, providers, and trial investigators q ↑ # of trials identified outside of a patient’s treating institution q ↑ ability to meet trial enrollment targets at a participating site q ↑ # patients enrolled in trials from sites where trial options do not exist q user experience (e. g. , survey) q ↑ or comparable quality of matches relative to traditional patient-facing matching options when using minimal criteria q (initial indications) sensitivity analysis – impact of additional criteria on quality of matches q ability for other matching services (beyond initial matching service) to implement this capability Scale to widespread adoption of m. CODEbased Patient-Clinical Trial Matching standards / open API Key Phase Required artifacts/activities o Outputs q Notional success measures POC: Proof of Concept P-CT: Patient – Clinical Trial UI: User Interface API: Application Programming Interface

|8| Phase 1: Retrospective Study • Identify a cohort of patients and associated clinical trials • Curate m. CODE records for these patients Automated Clinical Trial Matches • Match patients with clinicals trials: • Manually via clinician / researcher • Automatically via m. CODE-enabled matching services • Compare results • Are the trials for which a patient is eligible for included in the screened trials based on minimum eligibility criteria? m. CODE++ Clinical Trial Matches Patient Treatment Data Retrieve Map FHIR m. CODE++ Extraction (as needed) m. CODE++ Clinical Trial Matches Third Party Trial Matching Services Manual Clinical Trial Matches

|9| Phase 1: Proposed Approach § Instantiate P-CT matching proof-of-concept implementation as a cloud service § Continue on-boarding additional matching services – In progress: Breast. Cancer. Trials. org – Potential: IBM Watson, Be. The. Match, Trialjectory § Conduct retrospective study in two incremental, parallel steps: – Phase 1 a: Evaluate matching patients with trials based on “patient initiated” data pull from the EHR (patient platform) – Phase 1 b: Evaluate matching patients with trials based on “clinician initiated” data pull from the EHR (health center)

| 10 | Phase 1 a: Patient Platform • Map patient platform data model to m. CODE Automated Clinical Trial Matches • Send m. CODE patient records to m. CODE-enabled trial matching services m. CODE++ • Match patients with clinicals trials: • Manually via clinician / researcher • Automatically via m. CODEenabled matching services • Present matches back to patients and compare results Patient Treatment Data Retrieve Map FHIR m. CODE++ Extraction (as needed) m. CODE++ Clinical Trial Matches Third Party Trial Matching Services Manual Clinical Trial Matches

| 11 | Phase 1 b: Health Center • Generate m. CODE patient records, focused on minimal eligibility criteria • Send m. CODE patient records to m. CODE-enabled trial matching services • Match patients with clinicals trials: • Manually via clinician / researcher • Automatically via m. CODEenabled matching services • Present matches back to patients and providers and compare results Automated Clinical Trial Matches Patient Treatment Data Retrieve Map FHIR m. CODE++ Extraction (as needed) m. CODE++ Third Party Trial Matching Services Manual Clinical Trial Matches

| 12 | Benefits of Approach § Phase 1 a allows us to build and validate infrastructure and components that will support Phase 1 b while engaging health centers – P-CT matching cloud service – m. CODE mappings § We could possibly validate the minimum eligibility criteria sooner (with Phase 1 a) enabling us to move into Phase 2 with a health center sooner to pursue patient and provider-facing pilot § We have an engaged and willing patient platform partner (Cancer Insights) to pursue Phase 1 a

| 13 | Discussion

Phase 1: Advantages of Using a Cloud-hosted P-CT Matching Service | 14 | § Enable ease of adoption, simplify the ask from providers, and create a collaborative ecosystem § Bring patients and providers on board seamlessly by enabling out-ofbox integration with existing workflows § Create value-add for patients and providers by helping populate missing m. CODE elements in EHR § Simplify the onboarding of Trial Matching Services by providing them consistent API and hosting environment for integration

Phase 1: Logical component architecture (hosted on Cancer Insights) Clinician Smart*- Login and profile mgmt. UX/UI Services P-CT Related Services Data Services Infrastructure *new/ongoing development Request missing data elements as questions Patient login and profile mgmt. (clinician initiated) Cloud Hosted P-CT UI API to request matches *Deidentification EMR Data Pull P-CT Components EMR Data Pull (patient initiated) Secured: SSL, HTTPS. . Response from Trial Services Mapping data to m. Code* HIPAA, HITRUST | 15 | Cancer Insights Components

| 16 | Phase 1 a: Patient Platform § Phase 1 a: Work with patient data management platform to: – Establish means to consent patients electronically – Map patient platform data model to m. CODE, addressing gaps with patient questionnaire – Send de-identified m. CODE records for each patient to a P-CT matching cloud service hosted within secure Amazon cloud environment – Send de-identified m. CODE records to m. CODE-enabled matching services and retrieving resulting clinical trials that match for patient record – Compare clinical trial matches with matching trials identified by manual, human-driven process – Present resulting clinical trials (human and possibly machine) back to the patient § Patient Platform Partner: Cancer Insights § Questions: – What is the patient consent process? – How do we architect and implement the capability in a vendor / platform agnostic manner?

| 17 | Phase 1 a: Patient Platform Clinical trial matches for the patient are returned in a standard FHIR Research Study format, viewable by the patient via a Patient Data Manager platform. • Patient platform data model is mapped to m. CODE, addressing gaps with patient questionnaire • De-identified m. CODE records are sent to a P-CT matching cloud service hosted within secure Amazon cloud environment • De-identified m. CODE records are sent to m. CODE-enabled matching services Retrieve Map Patient Treatment Data Patients consent and want to identify clinical trials for which they may be eligible. FHIR m. CODE++ Automated Clinical Trial Matches P-CT Matching Cloud Service m. CODE++ Third Party Trial Matching Services Manual Clinical Trial Matches The automated clinical trial matches are compared against the manual clinical trial matches.

| 18 | Phase 1 b: Health Center § Phase 1 b: Work with partner health center to: – Develop study protocol, obtain IRB approval and consent patients – Generate m. CODE records for patient cohort, focused on the minimum eligibility criteria needed to support matching – Send de-identified m. CODE record for each patient to a P-CT matching cloud service hosted within secure Amazon cloud environment – Send de-identified m. CODE record to m. CODE-enabled matching services and retrieving resulting clinical trials that match for patient record – Send resulting clinical trials back to the health center to compare with matching clinical trials identified by manual, human-driven process § Health Center Partner: TBD § Questions:

| 19 | Phase 1 b: Health Center Clinical trial matches for the patient are returned in a standard FHIR Research Study format, viewable by the provider or patient via the EHR. • m. CODE patient records are generated, focused on the minimal eligibility criteria • De-identified m. CODE records are sent to a P-CT matching cloud service hosted within secure Amazon cloud environment • De-identified m. CODE records are sent to m. CODE-enabled Clinical Trial Matches matching services Automated Clinical Trial Matches Retrieve Map FHIR Patient Treatment Data A study protocol is developed, IRB approval is obtained, and patients consent and want to identify clinical trials for which they may be eligible. m. CODE++ P-CT Matching Cloud Service m. CODE++ Third Party Trial Matching Services Manual Clinical Trial Matches The automated clinical trial matches are compared against the manual clinical trial matches.

| 20 | Phase 1: Matching Service Engagements § Trial. Scope (near-complete) § Breast. Cancer. Trials. org (initiating early July) § Be. The. Match (TBD) – Many members on the CIBMTR team working with the Registry Reporting Code. X use case are from Be. The. Match § IBM Watson (follow-up discussion being scheduled) § Trialjectory (initial discussion scheduled)

| 21 | Phase 1 b: Health Center Engagements § University of California San Francisco (Lead: Elly Cohen) § Atrium Health (Lead: Mark Fleury) § University of Texas Southwestern (Lead: Salim Semy) Overview document, including ”the ask” of health centers, drafted and shared with candidate health centers

| 22 | Vision: Cloud hosted Clinical Trial Orchestration

| 23 | Data elements and their status *https: //www. hhs. gov/hipaa/for-professionals/privacy/special-topics/de-identification/index. html#zip Element Definition Is m. CODE Value Set Name Standard Reference Is PHI De-identify approach Is available in EHR Cancer Type Y Primary. Or. Uncertain. Behavior. Cancer. Disord er. VS ICD-10/SNOMED N Y Cancer Type Y Histology. Morphology. Behavior. VS ICD-10/SNOMED N N Cancer Subtype Y HGNCVS ICD-10/SNOMED N N Biomarker Status Y Tumor. Marker. Test. VS LOINC N N Presence of Metastases Y Secondary. Cancer. Disorder. VS ICD-10/SNOMED N N Stage Y TNMStage. Group. VS AJCC/SNOMED Age N Treatments Y Radiation. Procedure. VS SNOMED N Treatments Y Cancer Related Medication Statement Rx. Norm? ? /SNOMED Y Treatments Y Cancer-Related. Surgical. Procedure. VS SNOMED/CPT/ICD-10 Y Zipcode N N N; Except if >89 Y; Except if population <20 k Setup to 90 for anyone >89 Use first 3 digits except 17* restricted ones Y, but as DOB Y

| 24 | Assumptions, Challenges and Possible Solutions User Assumptions Challenges Possible Solution Provider Instantiate Trial Matching from within EMR Trial Matching needs integration with EMR Use SMART on FHIR to instantiate the Trial Matching Service Provider Leverage FHIR data from existing EMR system Extract data from EHR Use FHIR integration to pull EMR data Provider Use m. CODE elements in FHIR for trial matching m. CODE may not be populated completely for the patient Present a questionnaire to provider to fill up missing m. CODE elements Provider Patient FHIR data may contain PHI data Providers may not want to move PHI data to Trial matching UI De-identify or use only non-PHI data Patients Use the same workflow except launch the Web app Need to have Hospital EHR have FHIR endpoint Present a questionnaire to fill up missing m. CODE elements May not have m. CODE elements Provide a published API so each Service can use it to integrate their API Trial Use m. CODE elements to Matching find trial matches Service

| 25 | Use cases for retrospective pilot • Provider & Patients • SMART enabled login (providers only) • EHR data integration • Missing m. CODE elements as question prompts • Save relevant trials for patients • Generate PDF / forward as email • De-identification for trial search • HIPAA • Select trial services to for match requests • Trial Service • Published API for integration • Ability to set filters for hospitals • Provide summary metrics on trial matches