Clinical Research Data Capture Fields

Proposed Profile: Clinical Research Data Capture Fields

• Proposal Editor: Landen Bain, CDISC Liaison to Healthcare
• Editors: Rhonda Facile, Director, CDASH Project for CDISC; Gary Walker, Assoc. Dir Programming Standards, Quintiles
• Date: January 2008
• Version: 1.0
• Domain: Patient Care Coordination

Summary

IHE has successfully engaged the biopharmaceutical industry in the use of a content-free integration profile, RFD, to gather research data during an EHR session. Extending the reach of RFD by binding it to a clinical research specific content profile further reinforces the cross-industry alliance between healthcare and bio-pharma. This content profile will enable automatic population of RFD provided forms, resulting in greater data capture efficiencies between clinical trial sponsors, investigators and research sites.

Leveraging existing or developing standards available from CDISC (SDTM, CDASH, ODM), the content standard will map the clinical research vocabularies to similar term definitions in the healthcare world. The CDISC community can provide content and resources to do the mapping. In fact, a trial implementation of RFD has begun this work already. Individuals from both the CDASH and Vocabulary projects are willing to contribute to this effort.

The Problem

While RFD alone simplifies data capture for investigator sites, content profiles will extend its value. By constraining the use of RFD to a Clinical Research use case, we are able to use CDASH, which defines the data elements common to all case report forms.

The successful demonstration of the IHE ITI integration profile Retrieve Form for Data-capture (RFD) has dramatically increased the level of interest expressed by multiple stakeholders across the healthcare and biopharma value chain. Of these stakeholders, Electronic Health Record (EHR) vendors in particular are seeking to leverage RFD and the domain experience of CDISC to enable more efficient workflow when conducting clinical research within an EHR session.

The current implementation of RFD creates a data export template within an EHR session by importing a Case Report Form (CRF) from the appropriate clinical research system (Forms Manager). While the benefits of RFD have inspired the need for tighter integration, the lack of content profiles that complement RFD forces the EHR vendors to develop custom scripts to auto-populate relevant data available in the EHR into the CRF. The proposed content profile will align the data requirements of the RFD data export template with CDISC’s Clinical Data Acquisition Standards Harmonization (CDASH) effort to standardize the content of the case report form. CDASH, a multi-organizational effort with support from FDA, will complete version 1.0 in first quarter 2008.

This content profile will also complement the Query for Existing Data profile currently in development. A CDASH-based content profile would provide the list of data elements that an EHR should have on hand to respond to an external query from a clinical research system.

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.

Standards & Systems

Systems

• Electronic Health Records(EHR); Electronic Medical Records (EMR)
• Electronic Data Capture (EDC) systems;
• Clinical Data Management Systems (CDMS);
• Data Archiving systems;
• Biopharmaceutical sponsor protocol systems.

Standards

• CDISC standards and guidances:
  • Operational Data Model (ODM);
  • http://cdisc.org/standards/cdash/index.html Clinical Data Acquisition Standards Harmonization (CDASH)]
  • Submission Data Tabulation Model (SDTM);
  • Standard code sets from CDISC's terminology project;
  • Electronic Source Document Initiative (eSDI).
• IHE profiles:
  • Retrieve Form for Data-capture (RFD);
  • Query for Existing Data (QED)
  • W3C standards: XForm

  Technical Approach

  The Clinical Research content profile can be used with either RFD or QED. The essential difference between these two approaches is the need, or lack thereof, for a data capture form. If the research requires data entry de novo , RFD is the best option. If all the data required by the clinical research sponsor are available in the EHR, then a QED-only solution would work. A third technical approach uses both RFD and QED, where QED handles the autopopulation of a data capture form that subsequently gets displayed by the RFD FormFiller actor.

  Clinical Research content profile working with RFD

  The Clinical Research content profile publishes the data elements that are common to all Case Report Forms (CRFs), as defined in CDISC's CDASH specification. CDASH will be further extended using code lists from CDISC terminology project, and data element definitions from CDISC's SDTM. An EHR can use the specification to populate an XML document that accompanies the RetrieveForm transaction, sent by FormFiller to FormManager. The RFD FormManager extracts the data elements and pre-populates the form that is returned to the FormFiller.

  Clinical Research content profile working with QED

  The Clinical Research content profile can augment QED in one of two ways. Based on the terminology specified in the content profile, a QED Clinical Data Consumer can issue a query to the QED repositories, mapping between the Clinical Research profile and the existing QED specifications. Alternatively, a new QED repository could be build based on the Clinical Research profile. In this case, a clinical research based QED Clinical Data Consumer can obtain data from the QED repository with no mapping.

  Clinical Research content profile with both RFD and QED

  A third approach uses QED to pre-populate a form that then gets displayed by the FormFiller. In this case, the RFD FormManger acts as the QED Clinical Data Consumer and obtains the CRF data elements from the appropriate QED repository. The data are bound to the data capture form which is provided to the FormFiller on the FormRetrieve transaction.

  Existing actors

  RFD actors:

  • FormFiller,
  • FormManager,
  • FormReceiver,
  • FormArchiver

  QED actors:

  • Clinical Data Consumer
  • Clinical Repositories

  New actors

  New QED Repository
  ? Gateway actor that maps CDA Medical Summary, for example, to CDASH within ODM.

  Existing transactions

  All RFD and QED transactions.

  New transactions (standards used)

  No new transactions needed.

  Impact on existing integration profiles

  The Clinical Research content profile extends and leverages RFD and QED. A possible modification to QED is described above.

  New integration profiles needed

  No new integration profiles needed.

  Breakdown of tasks that need to be accomplished

  Most of the work of this development is in mapping Clinical Research data elements derived from CDASH, SDTM, and Terminology into existing patient care vocabularies.

  Support & Resources

  Development of the Clinical Research content profile has gained enthusiastic support from groups within CDISC, primarily the CDASH team. CDASH, in turn, links to sixteen organizations within the clinical research industry, and has strong support from FDA. The CDASH Program Manager, Rhonda Facile, has agreed to serve as editor for the Clinical Research content profile. Gary Walker, Quintiles, a CDASH team member and project manager of the Eli Lilly/Cerner/Quintiles trial implementation of RFD, will also serve as editor.

  The CDISC Terminology project also lines up behind the Clinical Research content profile. Bron Kisler, Terminology Program Manager, has agreed to serve as the third editor.

  CDISC has organized three trial implementations of RFD which have engaged with the semantic issues directly. This work will contribute to the clinical research to patient care semantic mapping that is the essence of the profile.

  Risks

  The risks for this content profile development are the same risks that pertain to any semantic mapping endeavor. The risks are in aligning data elements that appear to have the same meaning, but in fact have subtle connotations that can create misunderstandings as the data progress along the chain of custody.

  Open Issues

  The open issues are the relationship among the content profile, RFD, and QED.

  Tech Cmte Evaluation

  ' Effort Evaluation (as a % of Tech Cmte Bandwidth):

  • 35% for ...

  Responses to Issues:

  Candidate Editor:

  TBA