Clinical Research Data Capture - (CRD)

From IHE Wiki
Jump to navigation Jump to search

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 Prepopulation 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 Form Filler for use in Clinical Research. In addition this profile will also reference the ability to convert this format into the Clinical Research native format of ODM and CDASH.

Glossary

ODM
Operational Data Model (ODM)
CDASH
Clinical Data Acquisition Standards Harmonization (CDASH)


Volume I

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

Dependencies

Content Profile Dependency Dependency Type Purpose
Clinical Research Data Capture RFD Integration Profile This is a content profile that will be used in the context of the RFD Integration profile.

Profile Name

The Clinical Research Data Capture Profile (CRD)

CRD describes the content and format to be used within the Prepopulation 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 reference the ability to convert this format 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

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 prepopulation 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 prepopulation 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.

Options

Actor Option
Clinical Research Data Capture Options
Form Filler CCD Option (1)
Form Manager CCD Option (1)

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

Form Filler Options

CCD Prepopulation Data Option

This option defines that the Form Filler can produce a valid CCD as content for the prepopulation data transaction as defined in RFD. This valid CCD will be further constrained in volume 2 of this profile.

Form Manager Options

CCD Prepopulation Data Option

This option defines that the Form Manager can recieve a valid CCD as content for the prepopulation data transaction as defined in RFD. This valid CCD will be further constrained in volume 2 of this profile. Note the reference implementation that then supports conversion of this CCD into ODM/CDASH.

Process Flow

Clinical Research Data Capture Process Flow for CCD Option

In this CCD option, the Form Filler knows which form it wants to retrieve from the Form Manager. In addition the Form Filler wants to also send the prepopulation data for this form. The CRD Profile in addition to this CCD option requires that this prepopulation data conform to the CRD CCD. The Form Manager if they adhere to this CCD option are required to accept this CRD CCD format. Inside the Form Manager there is a reference implementation that then describes how the Form Manager could transform this CRD CCD into ODM/CDASH. The data that was sent to the Form Manager is then bound to the form and returned to the Form Filler.

Actor Definitions

Form Manager
The Form Manager actor provides the store of forms ready for use by a Form Filler.
Form Filler
The Form Filler actor retrieves forms from a Form Manager as and when required. When requesting a form, the Form Filler actor can optionally provide context information by providing pre-population xml data in the request for use by the Form Manager. The Form Filler may also specify a Form Archiver actor. The Form Archiver actor specified by the Form Filler is in addition to any Form Archiver actors specified by the Form Manager.

Transaction Definitions

Retrieve Form
The Retrieve Form transaction carries the form identifier from a Form Filler to a Form Manager. The transaction also allows a Form Filler to optionally specify a Form Archiver actor as well as optionally containing context information in the form of xml data to be used in the selection and pre-population of the requested form prior to the form being returned to the Form Filler.

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

CDASH has defined domains and elements within these domains. The CCD that is described in detail below overlays as best possible these domains. This Data Element Index is an attempt to describe which sections are intended to cover which domains.

CDASH Domains CCD Reference
Clinical Research Data Capture Data Elements
Demography CCD Header Information
Medical History Active Problems, Resolved Problems, Past Medical History, and Procedures and Interventions
Concommitant Medication Current Medications
Substance Use Social History
Vital Signs Vital Signs
Physical Exam Physical Exam
Adverse Events Allergies
Lab Test Results Coded Results
ECG Test Results Coded Results

Maybe more detailed element to element mapping table????

Document Specification

Data Element Opt Template ID
Clinical Research Data Capture Constraints
Date of Birth R patient/dateOfBirth
Gender R patient/genderCode
Ethnicity O patient/ethnicityCode
Race R2 patient/raceCode
Active Problems R 1.3.6.1.4.1.19376.1.5.3.1.3.6
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 and Other Adverse Reactions R 1.3.6.1.4.1.19376.1.5.3.1.3.13
Coded Results R2 1.3.6.1.4.1.19376.1.5.3.1.3.28


Header Sample

In order to ensure sufficient coverage to the Demography Domain within CDASH there are some constraints that have been applied to the CCD header. Specifically the Birthdate, Sex, Ethnicity, and Race are specified. 

  <recordTarget>
    <patientRole classCode="PAT">
      <id root="27143B24-E580-4F47-9405-3D0DC2BF1223" extension="1022"/>
      <addr>
        <streetAddressLine/>
        <city/>
        <state>FM</state>
        <postalCode/>
        <country>Canada</country>
      </addr>
      <telecom nullFlavor="UNK" use="HP"/>
      <patient classCode="PSN" determinerCode="INSTANCE">
        <name>
          <prefix/>
          <given>Christine</given>
          <family>Smith</family>
          <suffix/>
        </name>
        <ethnicGroupCode code="364699009" displayName="ethnic group" 
          codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
        <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>
        <birthTime value="20040725"/>
        <raceCode code=”2106-3” codeSystem=”2.16.840.1.113883.5.104”/>
      </patient>
      <providerOrganization classCode="ORG" determinerCode="INSTANCE">
        <id root="2.16.840.1.113883.19.5"/>
      </providerOrganization>
    </patientRole>
  </recordTarget>
Active Problems Sample 1.3.6.1.4.1.19376.1.5.3.1.3.6
<component>
  <section>    
    <templateId root='2.16.840.1.113883.10.20.1.11'/>
    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.6'/>
    <id root=' ' extension=' '/>
    <code code='11450-4' displayName='PROBLEM LIST'
      codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>
    <text>
      Text as described above
    </text>   
    <entry>
         :
      <!-- Required Problem Concern Entry element -->
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.5.2'/>
         :
    </entry>
       
  </section>
</component>
Past Medical History Sample
<component>
  <section>
    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.8'/>
    <id root=' ' extension=' '/>
    <code code='11348-0' displayName='HISTORY OF PAST ILLNESS'
      codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>
    <text>
      Text as described above
    </text>   
    <entry>
         :
      <!-- Required Problem Concern Entry element -->
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.5.2'/>
         :
    </entry>
       
  </section>
</component>
Procedures and Interventions Sample
<component>
  <section>
    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11'/>
    <id root=' ' extension=' '/>
    <code code='X-PROC' displayName='PROCEDURES PERFORMED'
      codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>
    <text>
      Text as described above
    </text>      
    <entry>
      Required and optional entries as described above
    </entry>
       
  </section>
</component>
Social History Sample
<component>
  <section>    
    <templateId root='2.16.840.1.113883.10.20.1.15'/>
    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.16'/>
    <id root=' ' extension=' '/>
    <code code='29762-2' displayName='SOCIAL HISTORY'
      codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>
    <text>
      Text as described above
    </text>  
       
  </section>
</component>
Current Medications Sample
<component>
  <section>    <templateId root='2.16.840.1.113883.10.20.1.8'/>
    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.19'/>
    <id root=' ' extension=' '/>
    <code code='10160-0' displayName='HISTORY OF MEDICATION USE'
      codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>
    <text>
      Text as described above
    </text>   
    <entry>
         :
      <!-- Required Medications element -->
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.7'/>
         :
    </entry>
       
  </section>
</component>
Vital Signs Sample
<component>
  <section>    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.25'/>
    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2'/>
    <id root=' ' extension=' '/>
    <code code='8716-3' displayName='VITAL SIGNS'
      codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>
    <text>
      Text as described above
    </text>   
    <entry>
         :
      <!-- Required Vital Signs Organizer element -->
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.13.1'/>
         :
    </entry>
       
  </section>
</component>
Physical Exam Sample
<component>
  <section>    
    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.24'/>
    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.15'/>
    <id root=' ' extension=' '/>
    <code code='29545-1' displayName='PHYSICAL EXAMINATION'
      codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>
    <text>
      Text as described above
    </text>  
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.25'/>
        <!-- Optional Vital Signs Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.16'/>
        <!-- Optional General Appearance Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.48'/>
        <!-- Optional Visible Implanted Medical Devices Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.17'/>
        <!-- Optional Integumentary System Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.18'/>
        <!-- Optional Head Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.19'/>
        <!-- Optional Eyes Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.20'/>
        <!-- Optional Ears, Nose, Mouth and Throat Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.21'/>
        <!-- Optional Ears Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.22'/>
        <!-- Optional Nose Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.23'/>
        <!-- Optional Mouth, Throat, and Teeth Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.24'/>
        <!-- Optional Neck Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.25'/>
        <!-- Optional Endocrine System Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.26'/>
        <!-- Optional Thorax and Lungs Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.27'/>
        <!-- Optional Chest Wall Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.28'/>
        <!-- Optional Breasts Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.29'/>
        <!-- Optional Heart Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.30'/>
        <!-- Optional Respiratory System Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.31'/>
        <!-- Optional Abdomen Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.32'/>
        <!-- Optional Lymphatic System Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.34'/>
        <!-- Optional Musculoskeletal System Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.35'/>
        <!-- Optional Neurologic System Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.36'/>
        <!-- Optional Genitalia Section content -->
      </section>
    </component>
    <component>
      <section>
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.9.37'/>
        <!-- Optional Rectum Section content -->
      </section>
    </component>
       
  </section>
</component>
Allergies and Other Adverse Reactions Sample
<component>
  <section>    
    <templateId root='2.16.840.1.113883.10.20.1.2'/>
    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.13'/>
    <id root=' ' extension=' '/>
    <code code='48765-2' displayName='Allergies, adverse reactions, alerts'
      codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>
    <text>
      Text as described above
    </text>   
    <entry>
         :
      <!-- Required Allergies and Intolerances Concern element -->
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.5.3'/>
         :
    </entry>
       
  </section>
</component>
Coded Results Sample
<component>
  <section>
    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.28'/>
    <id root=' ' extension=' '/>
    <code code='30954-2' displayName='STUDIES SUMMARY'
      codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>
    <text>
      Text as described above
    </text>   
    <entry>
         :
      <!-- Required Procedure Entry element -->
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.16'/>
         :
    </entry> 
    <entry>
         :
      <!-- Required if known References Entry element -->
        <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.4'/>
         :
    </entry>
       
  </section>
</component>

Reference Implementation

CCD to ODM/CDASH Crosswalk

This section is intended to be a guide as to how a Form Manager might take the CRD CCD structure and crosswalk that to produce a CDASH compliant ODM structure. The adopted format for this transformation from one structure to the other is an XSLT. The intent is to have this XSLT not be presented here within the CRD profile and remain static, but to further develop and refine this XSLT. The goal would also be to potentially not just have one version of this transformation, but to allow different Use Cases drive different flavors of transformations all of which might be available to be referenced. IHE is developing processes which aren't ready at time of this publication to help maintain source control and facilitate sharing and updating of this as well as other reference transformations. When the IHE process and procedures are determined this section will refer to those documents.

Retrieved from "http://wiki.ihe.net/index.php?title=Clinical_Research_Data_Capture_-_(CRD)&oldid=18954"