Drug Safety Content

1. Proposed Profile: Drug Safety Content

• Proposal Editor: Landen Bain, CDISC Liaison to Healthcare
• Editor: Michael Ibara, Head of Pharmacovigilance Information Management, Pfizer
• Date: January 2008
• Version: 1.0
• Domain: Patient Care Coordination

2. The Problem

Note: This content profile is one of a family of content profiles designed to extend the power and value of RFD

Physicians who encounter adverse drug events are requested to report these events to the FDA. This reporting is voluntary and spontaneous, and, by most estimates, covers less than 1% of reportable events. Spontaneous reporting of drug-related adverse events is a passive system with the following issues:

• Vast under-reporting of drug-related adverse events.
• Lack of awareness by physicians and patients.
• Spontaneous reporting does not fit into the physician’s workflow.
• The denominator is not easily estimated since we do not have comprehensive systems for tracking drug exposure.
• Data are not reported consistently, accurately and completely so integration of data across compounds, therapeutic areas, companies etc. is difficult.
• Follow-up on case reports can be difficult and it can be impossible to retrieve relevant medical information on the case.
• Analysis of the data is difficult to interpret for all the reasons above.
• The pharma industry has lost credibility in its ability and objectivity in monitoring itself for AEs related to its own drugs.
• The FDA has lost some credibility for objectively monitoring/evaluating safety signals for drugs approved by its own staff.
• Each pharma company invests in its own phamacovigilance systems and processes, thereby duplicating infrastructure across the industry.

For all the reasons above, there is growing interest in active surveillance processes and systems.

Despite these problems the spontaneous reporting system (SRS) remains the primary source for identifying potential adverse events. To increase the value of the SRS we need to improve recognition of adverse drug events (ADEs), decrease the burden of reporting, and improve the quality of the data in the report.

The overall goal of this profile is to create a new model for post-market safety reporting by employing the Retrieve Form Data capture (RFD) standard, the HL7 Individual Case Safety Report, and novel design to collect higher quality data directly from electronic medical records (EMR) and to make it easier for physicians to report these events. This can positively impact public health as a whole in our country.

The drug safety use case begins with a trigger event within the EHR which identifies the need to report an adverse event. RFD summons a drug safety data capture form from the appropriate source, and the form is completed by the EHR user, assisted by auto-population scripts within the EHR. This profile addresses the lack of standard content for the auto-population. The proposed content profile will align the data requirements of the RFD data safety report with HL7’s ICSR (E2B) standard. ICSR provides the basis for identifying the data elements required from the EHR, and greatly simplifies the involvement of the EHRs in drug safety reporting. This content profile will also complement the Query for Existing Data profile currently in development. An ICSR-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 drug safety sponsor.

3. Key Use Case

A community-based physician, Dr. Cramp, sees a patient in an outpatient clinic and accesses the patient’s electronic health record which reveals that the patient is on one of the new statin drugs. The physical examination turns up muscle weakness in the patient’s calves, which the physician recognizes as a possible adverse reaction to the statin. He orders a total creatinine kinase lab test to help in diagnosing the problem.

Current State

Dr. Cramp exits the EHR and, using a web browser, goes to http://www.fda.gov/medwatch/. He brings up form FDA 3500, for ‘voluntary reporting of adverse events noted spontaneously in the course of clinical care’. He navigates through several screens of routing and instructions to arrive at the first screen of the actual form, which requests patient identifier, age at time of event or date of birth, sex, and weight; the second screen requests seven entries: a classification of the event, classification of outcome, event date, report date, description, relevant tests (he notes that a test has been ordered), and other relevant history (the last three fields are text entry); the third and fourth screens ask for details about the product; and so forth. In actuality, the current state is that this form is seldom completed.

Desired State

Dr. Cramp sees the patient and accesses the EHR as above. Upon finding the potential problem, he clicks on an ‘Adverse Event Reporting’ button which uses RFD to bring up FDA form 3500, which has been styled to the look and feel of the EHR user interface. [In the Pfizer/Partners ASTER project, the LMR event 'Discontinue Drug for Adverse Event' triggers the form retrieval.] The form is presented with the demographics, product name, and other data elements already completed. Dr. Cramp completes the empty fields of the form and submits directly to the FDA Medwatch site.

When the RFD Form Filler retrieves the XForms from the Forms Manager it automatically provides the data elements specified in the Drug Safety Content Profile which the EHR has retrieved from its database. The forms manager populates the form and returns it to the form filler for display. The physician reviews the partially completed form, and fills in those sections which the content profile did not specify. RFD Form Filler then returns the data to the Forms Receiver.

4. Standards & Systems

Systems

• Participating EHRs, including Partners LMR;
• Participating drug safety systems, including CRIX

Standards

• CDISC standards: ODM, SDTM, CDASH
• IHE: RFD, QED, Drug Safety Data-caputure;
• W3C standards: XForms
• HL7 standards: ICSR.

5. Discussion

IHE has successfully reached the biopharmaceutical industry through a content-free integration profile, RFD. Extending the reach of RFD by binding it to drug safety specific content profiles further reinforces this cross-industry alliance. Benefits achieved will result in greater reporting compliance and improved data quality.

The Pfizer/Partners ASTER project is taking early versions of this work into implementation.

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 within the RFD Integration Profile. The purpose of this profile is to support a standard set of data in CCD format which the Form Filler provides for use in Clinical Research. In addition this profile will reference the ability to convert this output into a standard case report form (Standard CRF) consisting of ODM and CDASH.

Glossary

CCD

ASTM/HL7 Continuity of Care Document (CCD)

CDASH

Clinical Data Acquisition Standards Harmonization (CDASH)

Clinical Research CCD

Refers to the CCD constrained within the Clinical Research Data Capture (CRD) profile.

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.

Form Receiver

The Form Receiver actor receives and processes completed or partially completed forms instance data from a Form Filler. Form Receiver processing is out of the scope of the profile.

Form Archiver

The Form Archiver actor receives completed or partially completed forms instance data and stores these for archival purposes.

ODM

Operational Data Model (ODM)

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.

RFD

Retrieve Form for Data Capture Profile (RFD)

Standard CRF

Refers to a Standard Case Report Form in a ODM format which is mapped to CDASH

Also refer to Glossary of CDISC Terms at http://www.cdisc.org/glossary/index.html