Clinical Research Data Capture - (CRD)

Introduction

This is a draft of the Clinical Research Data Capture Profile (CRD) from the QRH Domain.

Profile Abstract

Clinical Research Data Capture Profile (CRD)

CRD describes the content and format to be used within the prepop Data transaction described with in the RFD Integration Profile. The purpose of this profile is to support a standard set of data out of the ehr system for Clinical Research. In addition this profile will also describe the ability to convert this standard set of data into the Clinical Research native format of ODM and CDASH.

Glossary

ODM

Operational Data Model (ODM)

CDASH

Clinical Data Acquisition Standards Harmonization (CDASH)

Issue Log

Open Issues

1. Issue
2. Issue

Volume I

Add the following bullet to the list of profiles

• Clinical Research Data Capture (CRD) - This content profile describes the content and format to be used within the prepop Data transaction described with in the RFD Integration Profile

Dependencies

Add the following row(s) to the list of dependencies

Integration Profile	Dependency	Dependency Type	Purpose
Clinical Research Data Capture

Profile Name

The Clinical Research Data Capture Profile (CRD)

CRD describes the content and format to be used within the prepop Data transaction described with in the RFD Integration Profile. The purpose of this profile is to support a standard set of data out of the ehr system for Clinical Research. In addition this profile will also describe the ability to convert this standard set of data into the Clinical Research native format of ODM and CDASH.

Use Case

The setting for the clinical research use case is a physicians’ practice where patient care is delivered side-by-side with clinical research activities. The site, Holbin Medical Group, is a multi-site physician practice, employing over 100 physicians in a variety of specialties. Holbin’s CEO encourages the physicians to participate as site investigators for pharmaceutical-sponsored clinical trials; Holbin provides support for clinical research activities in the form of a Research Department of twelve dedicated study coordinators, mostly RNs, along with clerical and data-entry support personnel. Holbin Medical Group uses an Electronic Health Record (EHR) and a number of sponsor-provided Electronic Data Capture (EDC) systems for documenting clinical trial activities. EDC is a system for documenting clinical trial activities. EDC is a remote data entry system, provided by the research sponsor, which uses either a laptop (thick or thin client) or a web site. For our purposes, an EHR is any application which is the primary site for documenting patient care, and retrieving patient care information. Thus we include in our span of interest many systems installed today that are not quite EHRs in the strictest sense, but which would still benefit from this approach.

Holbin’s involvement in a clinical study begins when the Research Department receives a request for proposal (RFP) or a request for a feasibility assessment (EU) from a study Sponsor. The Investigator or the Study Coordinator, Patricia Zone, RN, evaluates the RFP to assess if their facility has the required patient population (clinical condition and required numbers required by the study protocol) as specified in the clinical study protocol, as well as the business viability. A major issue that must be addressed is the time needed to perform the clinical study and whether or not the site has the time to perform the study appropriately. Once these concerns are addressed satisfactorily and the site is selected for the trial, the financial aspects are addressed and the site then sends the required regulatory documentation to the Sponsor. The Sponsor then provides Protocol-specific training to the Physician Investigator and other study personnel.

During the trial set-up period, Patricia, together with the Investigator ensures that the appropriate system security is in place for this protocol, recruits patients to participate as subjects according to inclusion and exclusion criteria described in the study protocol schedules patient visits, manages data capture and data entry, ensures that IRB approval has been obtained, maintains required regulatory documents and performs all the attendant financial tasks.

Patricia, under the supervision of the Investigator contacts Corey Jones, a patient at Holbin, about participating in the trial, and Corey agrees to participate as a subject. Patricia registers Corey in the EHR as a subject in trial #1234, using the EHR’s patient index. She schedules Corey’s study visits using the EHR scheduling module, and flags the visits as pertaining to the trial #1234. After the set-up stage, the site initiates clinical trial care and trial-specific documentation.

The use case continues with current state and desired state scenarios, which describe data capture utilizing EDC technology during a patient clinical trial visit before and after the RFD implementation.

Current State

Corey Jones arrives at the clinic for a scheduled trial visit and meets with Patricia Zone for a face-to-face interview. Patricia logs into the EHR and documents the visit with a terse entry: ‘Mrs. Jones comes in for a clinical trial visit associated with study #1234.’ Patricia interviews Mrs. Jones, makes some observations, and records her observation on a source paper document. She looks up recent lab results in the EHR and records them in the Case Report Form (CRF). The EHR provides only a portion of the data required to complete the form, the rest comes from the interview and observations. (Estimates on the percentage of data required for a clinical trial that would be available in an EHR vary from 5% to 40%. Even in the best case, the EHR typically captures only a subset of the data required by a study protocol.)

The completed source document is forwarded to Bob, the data entry person. Bob identifies the CRF as belonging to trial #1234, and selects the trial #1234 EDC system, which may be housed on a dedicated laptop provided by the sponsor or may be accessible via a browser session connected to the Sponsor’s EDC system via the Internet. He takes a three ring binder off the shelf and refers to his ‘crib sheet’ to get the instructions for how to use this particular system. He logs into the EDC application, using a user name and password unique to this system, and enters the data into the correct electronic case report form (eCRF) for that trial visit. Once the source document has been processed, Bob files it in a ‘banker’s box’ as part of the permanent source record of the trial (in order to meet the requirements of the Federal Code of Regulations 21CFR 312:62).

In addition to trial #1234, Bob performs data entry on eight additional EDC systems, five on dedicated laptops and three that are web-based. The web-based EDC systems save on table space, but still require entries in the three ring binders where Bob puts his ‘crib sheets’. It is a chore to make sure that data from a particular trial gets entered into the corresponding laptop with its unique login ritual and data capture form, so Bob experiences much frustration in dealing with this unwieldy set of systems. Bob is a conscientious employee, and stays current in his work. But in many other sites the data entry person holds the CRF for a period of time before entering the data, perhaps entering data twice a month, or entering the data the week before the monitor visit occurs.

Desired State

Mrs. Jones arrives for a visit and Patricia logs into the EHR, pulls up Mrs. Jones’s record, and identifies the scheduled clinical trial visit. Because of the patient identification and scheduling steps that took place in the set-up stage, the EHR recognizes Mrs. Jones as a subject in Trial 1234, and requests an electronic case report form from trial #1234’s, using RFD. If the trial is sufficiently complex, the retrieved form may contain a list of relevant forms from the RFD Forms Manager system from which Patricia may choose. Patricia selects the appropriate form, the EHR checks Patricia’s credentials, confirms that she is empowered to view the form, and displays the form. (The data capture form is essentially the same form that an EDC system would offer for this visit, and its presentation may take on some of the look and feel of the EHR’s user interface.)

Nurse Patricia interviews Mrs. Jones and enters data into the clinical trial form as presented in the EHR. The clinical site personnel will be well acquainted with the basic data collection variables* that appear on the clinical trial form as they are consistently collected in all types/phases of clinical trials. Applicable data from the EHR database are now used to pre-populate some of the clinical trial data fields. Additional data may need to be captured interactively via the forms (which may have built-in edit checks). Upon completing the form, Patricia hits the submit button, and the EHR returns the complete form to the EDC system, using RFD. A copy of the document is archived in the site clinical trial document vault as part of the permanent source record of the trial.

*These clinical trial forms or domain modules are comprised of data collection variables identified by the Clinical Data Acquisition Standards Harmonizaation (CDASH) Initiative. The CDASH initiative identifies data collection fields that are applicable to all clinical trials regardless of therapeutic area or phase of trial. Addition data collection fields will have been added to the CDASH collection variables to capture the required therapeutic area or required fields by the study Sponsor.

Actors/Transaction

There are two actors that surround the transaction this content profile is to be applied, the Form Filler and the Form Manager. The Form Filler can request that the Form Filler context information be used by the Form Manager in the selection and/or creation of the returned form. The sharing of content from one actor to the other is addressed by the appropriate use of IHE profiles described below, and is out of scope of this profile. The Retrieve Form for Data Capture embodies the Form Filler Actor and Form Manager Actor. The sharing of content or updates from one actor to the other is addressed by the use of appropriate IHE profiles described by the 2007-2008 Trial Implementation Supplements to ITI-TF v. 4.0 specifically the Retrieve Form for Data Capture (RFD) suplement.

Clinical Research Data Capture Actor Diagram

Options

Clinical Research Data Capture Options

Actor	Option
Form Filler	PrepopData Option (1)
Form Manager	PrepopData Option (1)

Note ¹: The Actor shall support at least one of these options.

Grouping

Content Bindings with RFD

The Retrieve Form for Data Capture Profile (RFD) provides a method for gathering data within a user’s current application to meet the requirements of an external system. RFD supports the retrieval of forms by a Form Filler from a Form Manager optionally using prepop data sent from the Form Filler and then further describes display and completion of a form, and return of instance data from the Form Filler to the Form Reciever as well as optionally to a Form Archiver. This content profile will be bound to the prepop data transaction described in RFD.

For more details on these profiles, see the IHE IT Infrastructure Technical Framework.

Content profiles may impose additional requirements on the transactions used when grouped with actors from other IHE Profiles.

Content Modules

Content modules describe the content of a payload found in an IHE transaction. Content profiles are transaction neutral. They do not have dependencies upon the transaction that they appear in.

Process Flow

[[Image:|frame|center|Clinical Research Data Capture Process Flow]]

More text about process flow

Actor Definitions

Actor

Definition

Transaction Definitions

Transaction

Definition

Volume II

Clinical Research Data Capture Content

Standards

CDAR2

Clinical Document Architecture, Release 2, 2005 HL7

CRS

Implementation Guide for CDA Release 2 – Level 1 and 2 – Care Record Summary (US realm), 2006, HL7.

CCD

ASTM/HL7 Continuity of Care Document (Draft)

Data Element Index

Clinical Research Data Capture Data Elements

Data Elements	Other Reference	LOINC Section or CDA Element
Data Element 1
Data Element 2
Data Element 3

Document Specification

Clinical Research Data Capture Constraints

Data Element	Opt	Template ID
Date of Birth	R	patient/dateOfBirth
Gender	R	patient/genderCode
Ethnicity	O	patient/ethnicityCode
Race	R	patient/raceCode
Active Problems	R	1.3.6.1.4.1.19376.1.5.3.1.3.6
Resolved Problems	R2	1.3.6.1.4.1.19376.1.5.3.1.3.8
Past Medical History	R2	1.3.6.1.4.1.19376.1.5.3.1.3.8
Procedures and Interventions	R2	1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11
Social History	R2	1.3.6.1.4.1.19376.1.5.3.1.3.16
Current Medications	R	1.3.6.1.4.1.19376.1.5.3.1.3.19
Vital Signs	R2	1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2
Physical Exam	R2	1.3.6.1.4.1.19376.1.5.3.1.1.9.15
Allergies	R	1.3.6.1.4.1.19376.1.5.3.1.3.13
Results	R2	1.3.6.1.4.1.19376.1.5.3.1.3.27

Section Template 1

TemplateID	1.3.6.1.4.1.19376.1.5.3.1.3.X
Parent Template	1.3.6.1.4.1.19376.1.5.3.1.3.Y
General Description	This section shall ...
LOINC Code	Opt	Description
#####-#	R	Description
Entries	Opt	Description
1.3.6.1.4.1.19376.1.5.3.1.4.A	O	Description
Sub-sections	Opt	Description
1.3.6.1.4.1.19376.1.5.3.1.3.D	R	Description

Header Template 1

<entry>An XML Example</entry>

entry

Description of the entry element.

Entry Template 1

<entry>An XML Example</entry>

entry

Description of the entry element.