Difference between revisions of "Drug Safety Content"

From IHE Wiki
Jump to navigation Jump to search
 
(29 intermediate revisions by 4 users not shown)
Line 1: Line 1:
−
<h2>1. Proposed Profile: <i>{{PAGENAME}}</i></h2>
+
Drug Safety Content (DSC) describes the content and format to be used to pre-populate data for safety reporting purposes.  DSC is a content profile that uses transactions described within Retrieve Form for Data-capture (RFD).  
  
 +
==Summary==
 +
<p>
 +
DSC is part of a set of profiles that create interoperability between EHRs and specialized research systems, resulting in EHR-enabled research. The purpose of this profile is to support a standard set of data in Continuity of Care Document format which the EHR provides for use in reporting adverse events as it relates to Drug Safety. In addition this profile will reference the ability to convert this output into the ICH E2B(R3) standard.
 +
</p>
 +
 +
__TOC__
 +
 +
 +
==Benefits==
 +
<p>
 +
DSC both saves labor and improves the quality of drug safety data. By eliminating duplicate data entry, the use of DSC saves time in the process of completing a drug safety report form. By using existing EHR data to automatically pre-populate the form, DSC eliminates data entry errors, thus improving data quality.
 +
</p>
 +
 +
==Details==
 +
<p>
 +
DSC is activated by the Retrieve Form for Data-capture (RFD) profile at the point where RFD retrieves a data safety from a safety reporting system. DSC defines the export document based on HL7's Continuity of Care Document, and provides a mapping to the ICH E2B(R3) standard.
 +
</p>
 +
 +
==Systems Affected==
 
<ul>
 
<ul>
−
    <li> Proposal Editor: <i>[[user: landenbain | Landen Bain, CDISC Liaison to Healthcare ]]</i>
+
<li> Electronic Health Record
−
    <li> Editor: <i>Michael Ibara, Head of Pharmacovigilance Information Management, Pfizer</i>
+
<li> Safety Reporting System
−
    <li> Date: <i> January 2008 </i>
 
−
    <li> Version: <i> 1.0 </i>
 
−
    <li> Domain: <i> Patient Care Coordination</i>
 
 
</ul>
 
</ul>
  
−
<h2> 2. The Problem </h2>
+
==Specification==
−
<h4> Note: This content profile is one of a family of content profiles designed to extend the power and value of RFD </h4>
+
 
−
<p> 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.
+
'''Profile Status:''' [[Comments| Trial Implementation]]  
−
Spontaneous reporting of drug-related adverse events is a <i><b>passive</b></i> system with the following issues:
+
 
−
<ul>
+
'''Documents:'''
−
  <li>There is widely agreed vast under-reporting of drug related adverse events.
 
−
<li>There is lack of awareness by physicians and patients.
 
−
<li>It does not fit into the physician’s workflow.
 
−
<li>The denominator is not easily estimated since we do not have comprehensive systems for tracking drug exposure.
 
−
<li> Data are not reported consistently, accurately and completely so integration of data across compounds, therapeutic areas, companies etc. is difficult.
 
−
<li>Follow-up on case reports can be difficult and it can be impossible to retrieve relevant medical information on the case.
 
−
<li>Analysis of the data is difficult to interpret for all the reasons above.
 
−
<li>The pharma industry has lost credibility in its ability and objectivity in monitoring itself for AEs related to its own drugs. 
 
−
<li>The FDA has lost some credibility for objectively monitoring/evaluating safety signals for drugs approved by its own staff.
 
−
<li> Each pharma company invests in its own phamacovigilance systems and processes, thereby duplicating infrastructure across the industry.
 
−
</ul>
 
−
For all the reasons above, there is growing interest in <i><b>active</b></i> surveillance processes and systems. </p>
 
  
−
<p>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.  </p>
+
'' http://ihe.net/Technical_Framework/upload/IHE_QRPH_Suppl_DSC.pdf ''
−
<p> 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. </p>
 
−
<p>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.</P>
 
  
−
<h2>3. Key Use Case</h2>
 
−
<p> 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. </p>
 
−
<h4> Current State </h4>
 
−
<p> 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. </p>
 
−
<h4> Desired State </h4>
 
−
<p> 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. </p>
 
−
<p> 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.</p>
 
  
−
<h2>4. Standards & Systems </h2>
+
'''Underlying Standards:'''
−
<h4> Systems</h4>
 
−
<ul>
 
−
<li>Participating EHRs, including Partners LMR;
 
−
<li>Participating drug safety systems, including CRIX
 
−
</ul>
 
  
−
<h4> Standards </h4>
+
:* HL7 Continuity of Care Document
−
<ul>
+
:* ICH E2B standard
−
<li>CDISC standards: ODM, SDTM, CDASH
 
−
<li> IHE: RFD, QED, Drug Safety Data-caputure;
 
−
<li>W3C standards: XForms
 
−
<li>HL7 standards: ICSR.
 
−
</ul>
 
  
−
<h2>5. Discussion </h2>
+
[[Category:Profiles]]
−
<p>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.</p>
+
[[Category:QRPH Profile]]
−
<p> The Pfizer/Partners ASTER project is taking early versions of this work into implementation.  </p>
+
[[Category:CDA]]
 +
[[Category:RFD]]

Latest revision as of 13:56, 4 November 2019

Drug Safety Content (DSC) describes the content and format to be used to pre-populate data for safety reporting purposes. DSC is a content profile that uses transactions described within Retrieve Form for Data-capture (RFD).

Summary

DSC is part of a set of profiles that create interoperability between EHRs and specialized research systems, resulting in EHR-enabled research. The purpose of this profile is to support a standard set of data in Continuity of Care Document format which the EHR provides for use in reporting adverse events as it relates to Drug Safety. In addition this profile will reference the ability to convert this output into the ICH E2B(R3) standard.


Benefits

DSC both saves labor and improves the quality of drug safety data. By eliminating duplicate data entry, the use of DSC saves time in the process of completing a drug safety report form. By using existing EHR data to automatically pre-populate the form, DSC eliminates data entry errors, thus improving data quality.

Details

DSC is activated by the Retrieve Form for Data-capture (RFD) profile at the point where RFD retrieves a data safety from a safety reporting system. DSC defines the export document based on HL7's Continuity of Care Document, and provides a mapping to the ICH E2B(R3) standard.

Systems Affected

  • Electronic Health Record
  • Safety Reporting System

Specification

Profile Status: Trial Implementation

Documents:

http://ihe.net/Technical_Framework/upload/IHE_QRPH_Suppl_DSC.pdf


Underlying Standards:

  • HL7 Continuity of Care Document
  • ICH E2B standard
Retrieved from "http://wiki.ihe.net/index.php?title=Drug_Safety_Content&oldid=118142"