Request Type(s)/ Metric

Consent Check

When a request for clinical data or biospecimen information of patients as part of cohort determination is received, the Honest Broker algorithm is used to find the patient’s consent or dissent to data and/or blood tissue research based on active protocols 07047 (General Consent). Detailed report is released to PI.

Toward an IRB Protocol/Aggregate Data for Grant

User can request aggregate patient counts to determine feasibility for research projects and/or grants. This does not require an approved IRB protocol.

Specimen Availability: To determine the number of specimens available, Honest Broker can provide the counts using Virtual Biospecimen Management System. This is an estimate, and the final accurate numbers of specimens can only be given by the biorepository team. Please take note that the Honest Broker is not engaged in the specimen retrieval process. For inquiries related to specimen retrieval, please reach out to the Biorepository team.

Cohort List

Honest Broker will review the intake form, ensure that the request matches the study application and criteria, prepare cohort, check consent/waiver eligibility status, remove ineligible patients/specimens from cohort, create de-identified or limited data sets when applicable, and releases appropriate data set to PI via a secure SharePoint link.

Request Type

Example

Process 

Output Data

Consent Check (Simple Request) 

User provides a set of MRNs (Medical Record Number) and asks HB to check if patients have Consent records against a specified protocol or the 07047 protocol (General Consent) 

a). Business Analyst Review to check whether an existing report can be utilized or if it is necessary to cross-reference data in backend tables to confirm consent. This task is assigned to the developer.

b). Developed checks to see if this can be done using an automated report. If not, they check in Oncore / Midas or EPIC to see if there are any Consent -Dissent records. We focus mostly on Oncore, but some cases like Refusals for 07047 are captured in EPIC as well.

c). Share the query with teammates for review. Code is reviewed, some of the data is reviewed to make sure it’s correct.

Report is provided in a SharePoint folder accessible only by the user, along with information on what logic and data sources were used for this request.

Feasibility/ Aggregate (Moderate Request)

User asking for count of patients receiving CAR T cell therapy and have WHO Oral Mucositis score – last 2 years or 100 patients sufficient to examine this.

a). Intake form is reviewed by HB Business Analyst and determines that it only calls for patient counts and does not need to include an IRB letter. This request is then assigned to the developer.

b). Developer builds a query to pull data for patients who had CAR- T therapy. The developer found this in EPIC with Infusion Date and Type of CAR-T in the Smart text fields. Upon searching in EPIC, the developer found that ORAL Mucositis score is captured for inpatients in the Flowsheets.

 c). Developer shares the query with teammates for code review. Sample set of the data is checked against the data source in Epic/flowsheets and reviewed for accuracy. Then final output report is reviewed for completeness.

Patients count along with information on what logic and data sources were used for this request is shared with PI.

Cohort Data

(Complex or Extensive Request)

User wants a Cohort of Hematology patients from 2013-2023 who had Fungal infections.

For this Cohort user needs Age of diagnosis, gender, Fungal Labs, Specimen Type, ANC/WBC for 14 days from positive Fungal test and if Patient was in ICU (Intensive Care Unit) during the fungal test.

a). Business Analyst reviews the request, ensuring the presence of the requisite IRB letter for data provision. Additionally, they perform a check to confirm the availability of all necessary components, such as ICD Codes for Diagnosis and Lab names, before assigning the request to the developer.

b). Developer looks at some data from two sources (Allscripts prior to 2018 and EPIC from 2018).

Reaches out to user to for ICD 9/10 codes for diagnosis and Lab Component names by providing the complete list. User selects what they need.

c). Builds query to get patient Race, Gender and excludes patients who dissented to 07047.

d). Gets labs, specimen type from Allscripts and EPIC by filtering the lab names user wants.

e). Reviews lab results to see if there are any written values with False positives or not detected cases which are to be excluded. Marks positive lab results based on certain terms in the result.

f). Gets all ICD9/10 CM diagnosis codes assigned to patient and stuffs them into one record per patient to reduce number of rows in final report.

g). Checks for ICU Data in EMR, this is not straight forward - so checks to see if any patient was present in 3 EAST room or was admitted in different room and transferred to 3 EAST during the inpatient stay.

h). Compares ICD Dates to Lab Dates to see if patient has Positive labs between ICU admit and Discharge dates.

I). Check for Radiation data from Cancer registry and ARIA in EPIC.

j). Code sent to review and data sent to QC team as this is a more complex report.

k). Meet with User to explain data and logic used. Data provided to User in SharePoint folder, accessible only to them.

l). User reviews the data and will reach out for any questions or updates. This process continues until data is accepted by user.

Provided in SharePoint folder, accessible only to user.

Metrics

Request Type Request Definition CY 2020 CY 2021 CY 2022 CY 2023 YTD* Total  
Simple Simple Feasibility/Consent Check 27 26 33 27 113  
Moderate Feasibility /Grants 67 87 136 116 406  
Complex Project Based 32 52 65 39 188  
Extensive NLP Assisted 9 17 22 18 66  
Total   135 182 256 200 773  
               
* As of 9/12/23