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

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. Despite this low reporting rate, the spontaneous reporting system (SRS) remains the primary source of 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 effort is to create a new business 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 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

The point of departure for this use case is a patient care site which currently reports drug safety information using RFD without a content profile. The ‘before’ state shows the use of RFD without a content profile. The ‘after’ state describes the use of RFD in concert with the proposed content profile.

Pharmaco-vigilance Scenario

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 365 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. The form is presented with the demographics already completed. The product name is part of the working context of the EHR session, and is automatically loaded into the appropriate field. Dr. Cramp completes the empty fields of the form and submits directly to the FDA Medwatch site.

RFD retrieves the form from MedWatch, displays it, and returns the data to FDA. The EHR extracts relevant data from its database, as specified in ICSR.

4. Standards & Systems

Systems

• Participating EHRs;
• Participating drug safety systems.

Standards

• CDISC standards: ODM, SDTM
• IHE: RFD, QED
• W3C standards: XForm
• 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.