![]() ANSI/HL7 V3 ICSRP1, R2-2012 HL7 Version 3 Standard: Pharmacovigilance - Individual Case Safety Report, Part 1: The Framework for Adverse Event Reporting, R2 (revise and partition ANSI/HL7 V3 RRCS, R1-2005) 1/31/2012 |
Content Last Edited: 2012-02-20T17:13:56
Foreword
This standard is published as a SDO Joint Harmonization International Standard ISO 27953 and was prepared by Technical Committee ISO/TC 215, Health Informatics, CEN TC 251 Health Informatics and HL7 Patient Safety Workgroup.
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
Further information about this Standard:
Questions or comments about this standard should be addressed to the ISO TC 215 Secretariat:
Audrey E. Dickerson RN, MS
ISO/TC 215 Health Informatics, Secretary
US TAG for ISO/TC 215 Health Informatics, Administrator
Staff Liaison for Nursing Sub-committee to IHE-Patient Care Coordination Domain
Manager, Standard Initiatives
HIMSS
230 East Ohio Street, Suite 500
Chicago, Illinois 60611
TEL: +01-1-312-915-9233
Mobile: +01-1-630-544-0378
FAX: +01-1-312-915-9511
adickerson@himss.org
www.himss.org
Copyright ISO/HL7 2010 All rights reserved
IntroductionTo enhance patient safety, it is noted that many countries have strong needs to exchange product safety information between varieties of stakeholders in the healthcare domain. Currently many regulatory agencies collect safety reports of adverse drug reactions, adverse events, infections, contamination and other incidents from consumers, pharmaceutical companies and healthcare professionals. This standard consolidates content and messaging requirements based upon: 1) ISO New Work Item Proposal N545: Health Informatics - Pharmacovigilance - Structure and Data Elements of Individual Case Safety Report (reclassified as ISO 27953), 2) Health Level Seven (HL7) Individual Case Safety Report (ICSR) Release 1 Normative Standard, and 3) HL7 ICSR Release 2 Draft Standard for Trial Use (DSTU).
Readers should note that because of the significant differences in use cases and content requirements across these work items, this standard is published as a multi-part standard. Part 1 of the standard (ISO 27953-1) has been specifically designed to address areas of overlap across the work items and form a messaging framework reference. This framework can be applied to support data exchange requirements described in the many different use cases presented as storyboards in the standard. This framework allows for future development work to be carried out so that additional use cases that are not addressed in this release can be added as new parts to this standard in the future.
International vocabulary harmonization for ISO 27953-1 is out of scope for this release and implementers may use existing vocabularies that are unique to their reporting requirements within their organization or region. However, it is recommended that implementers create and publish their implementation guides to help inform and assist other implementers in applying the standard to other use cases and encourage terminology harmonization across SDOs. The sponsoring committees may address vocabulary harmonization in subsequent releases of this standard. Finally, this release of the standard is to establish a common, international messaging framework and should be used to facilitate future SDO harmonization efforts for other product reporting profiles for animal drugs, medical devices, combination products and food safety.
Part 2 of this standard (ISO 27953-2) has been created as a conformance profile to support human pharmaceutical reporting to global regulatory authorities and is based upon the International Conference on Harmonisation's (ICH) Revised Guideline E2B(R3): Data Elements for Transmission of Individual Case Safety Reports (version 3.96), November 2008. However, these initial requirements have been extended to take into account additional non-ICH requirements. Conformance for this part of the standard is dependent upon the related ISO vocabulary harmonization work items: Data Elements and Structures for the Exchange of Regulated Product Information for Drug Dictionaries (see ISO 11615, 11616, 11238, 11239 and 11240) and Structures and Controlled Vocabularies for Laboratory Test Units for the Reporting of Laboratory Results (see ISO 11595).
Ballot Considerations
This draft standard document is harmonized between ISO, CEN and HL7. It is jointly balloted in all three organizations. In ISO/TC 215 and CEN/TC 251, this is currently a Draft International Standard (DIS). Readers will notice that this document is formatted differently from other HL7 V3 specifications because of the need for consistency with ISO/TC 215 and CEN/TC 251 publications. Ballot reviewers should focus on the content and not submit comments related to the publication format. Ballot comments should be submitted in accordance with the appropriate SDO ballot governing rules, i.e., through ISO National Member Body (NMB) representative, CEN National Member Body (NMB) representative, or through appropriate HL7 membership voting. To help reduce duplication or conflicts in ballot responses among SDOs, HL7 International Affiliates are encouraged to coordinate with their ISO/CEN NMB representatives for submitting comments to this document. The sponsoring ISO, CEN and HL7 committees will jointly consolidate and reconcile all comments per ISO/CEN Vienna Agreement and the ISO/HL7 pilot agreement requirements.
HL7 Version 3 ContentsThe format of the document follows the publication standards used by ISO and the standard publishing format for HL7 Version 3 (V3) standards. This hybrid format makes it possible to present the ICSR Refined Message Information Models (RMIMs) and schema files in a seamless way, and to produce material that can be consistently balloted in the CEN, ISO, and HL7 environments. It should be noted that the content for HL7 V3 Messaging Infrastructure (Transmission and Control Act) are included as separate annexes for this ballot to demonstrate support for ISO requirements related to message attachments, batch submissions and acknowledgements. Note that this material is provided as reference only and is not subject to changes or comment as part of the ICSR ballot. Any comments received for this content will be forwarded to HL7 for future consideration.
SDO HarmonizationThe Joint Initiative on SDO Global Health Informatics Standardization has been formed to enable common, timely health informatics standards by addressing and resolving issues of gaps, overlaps, and counterproductive standardization efforts. The Joint Initiative Charter provides the basis, purpose and structure of the Joint Initiative on SDO Global Health Informatics Standardization. The Individual Case Safety Report (ICSR) Standard was approved as a Joint Initiative project February 2008. The ICSR standard is a candidate for SDO harmonization because of the global interest to improve patient safety by the electronic exchange of high quality, unambiguous, structured data that will support regulatory and patient safety requirements and efficient safety signal detection for patient protection. This standard is generally referred to as the ICSR.
The standard's message specification is based upon the current release of HL7's Reference Information Model, including its Release 1 data types. The sponsoring committees are aware of the current Joint Initiative Project, ISO/FDIS 21090 Health Informatics -- Harmonized Data Types for Information Interchange (commonly referred in HL7 as Release 2 Data Types.) The standard will be updated in subsequent releases to incorporate use of the new data type specification once appropriate vendor tools are available to facilitate conversion for implementers.
AnnexesAnnexes are provided to facilitate ISO/CEN review of the HL7 V3 content. Readers should note that this content is provided and fully accessible as part of HL7's normal ballotting process. The annexes are provided as background reference material and are not subject to ballot comments. Note that the annexes for the HL7 Reference Information Model (RIM), Data Types, and Vocabulary specifications are also provided as annexes for Part 2 of this standard. Within Part 1, this content is available via hyperlinks within the appropriate sections.
Annex A (Normative) HL7 Transmission Infrastructure: This annex provides information about HL7 V3 message headers, acknowledgements and attachments.
Annex B (Normative) HL7 Control Act Infrastructure Topic. This annex provides information about the HL7 V3 Control Act and its relationship to the ICSR message payload.
Annex C (Informative)HL7 Version 3 Guide: This annex contains information about The HL7 Version 3 standard, and discusses the process by which specifications are developed.
Annex D (informative) HL7 Reference Information Model: This annex provides background on the reference model used for developing all HL7 V3 specifications.
Annex E (informative) HL7 Data Type Specifications: This annex describes the data types used to implement attributes in the specifications.
Annex F (informative) HL7 Vocabulary Specifications: The annex describes the principals behind HL7 Version 3 vocabularies, and includes the concept domains, code systems and value sets defined by HL7.
1 Scope: Individual Case Safety Report (ICSR)
Part I Scope
Part 1 of this standard seeks to establish an international framework for data exchange and information sharing by providing a common messaging format for transmission of ICSRs for adverse drug reactions (ADR), adverse events (AE), product problems and consumer complaints that may occur upon the administration or use of one or more products. The messaging format is based upon the HL7 Reference Information Model (RIM) and can be extended or constrained to accommodate a variety of reporting use cases described in the storyboard section of this ballot. It should be noted that Part 1 will be harmonized over time with other HL7 public health and patient safety reporting standards to help insure messaging constructs and vocabulary are harmonized in the HL7 Public Heath and Regulatory Reporting domains. Furthermore, Part 1 of this standard does not govern or dictate reporting requirements for any product. However, the regulatory use cases (storyboards) described in this standard were derived from a variety of data sources including draft and final versions of internationally harmonized guidelines from the International Conference on Harmonisation, the International Cooperation on Harmonization of Technical Requirements for Registration of Veterinary Medicinal Products (VICH) GL 42, and the Global Harmonization Task Force (GHTF) Study Group 2 N87 guideline. The storyboards are for demonstration purposes only and help demonstrate the standard's scalability and interoperability across multiple stakeholders and product types. Future releases of this standard may be developed to include conformance profiles (templates) and vocabulary for all or a limited subset of the use cases.
Note that the data elements used in Part 1 were identified as consistent across many of the use cases and can be applied to a variety of reporting scenarios. Specific reporting requirements within organizations or regions may vary and the standard does not specify a vocabulary subset for these data elements in this release.
2 Normative referencesThe following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
HL7/ANSI Approved Individual Case Safety Report Release 1 Normative Standard 2005
HL7 2007/2008 Normative Edition: Safety Reporting Topic: Individual Case Safety Report Release 2 Draft Standard for Trial Use
ISO/HL7 21731:2006 Health informatics -- HL7 version 3 -- Reference Information Model -- Release 1 2006-08-03
ISO/TS 22224:2007, Health Informatics -- Electronic Reporting of Adverse Drug Reaction
ISO/FDIS 21090:Health Informatics -- Harmonized Data Types for Information Interchange
Terms and DefinitionsNote that there are many different terms used to describe basic concepts in healthcare for different purposes available from ISO, CEN, HL7 and various national and international organizations. Therefore, this standard does not attempt to force adoption of terms described in this document. Detailed terms and definitions relevant to the HL7 messaging specification are provided in the Hierarchical Message Definition (HMD) file and other related sections in HL7's V3 Message Specifications.
Abbreviated termsFor the purposes of this document, the following abbreviated terms apply:
CEN: Comite Europeen de Normalisation (European Committee for Standardization, a federation of 28 national standards bodies that are also ISO member bodies)
EU: European Union
HL7: Health Level 7
HMD: Hierarchical Message Description
ICH: The International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use
ICSR: Individual Case Safety Report
ITS: Implementable Technology Specification
MedDRA: Medical Dictionary for Regulatory Activities
RIM: Reference Information Model
RMIM: Refined Message Information Model
SGML: Standardized generalized markup language. An ISO standard for describing structured information in a platform independent manner
SNOMED: The Systematized Nomenclature of Human and Veterinary Medicine
SNOMED-CT: Systematized Nomenclature of Medicine-Clinical Terms
UML: Unified Modelling Language
W3C: World Wide Web Consortium
XML: eXtensible Markup Language
BibliographyRemoval of ICSR Release 1 Content within the ICSR Topic (HL7 Public Health Reporting Publishing Domain)
The Individual Case Safety Report Release 2 Draft Standard for Trial Use (DSTU) formally announced the deprecation of all ICSR Release 1 material from subsequent releases of this standard. The committee received no negative comments or feedback about this decision, and all ICSR Release 1 content was carried over and harmonized with ICSR Release 2 DSTU. ICSR Release 2 Normative supports all ICSR Release 1 content, and therefore future Normative Edition releases of this standard will refer only to the most current version.
Revocation of Safety Reporting Management Topic Content within the HL7 Public Health Reporting DomainThe Safety Reporting Management Topic introduced in the HL7 2007/2008 Normative Edition is being deprecated and removed with ICSR Release 2 Normative. The Safety Reporting Topic was created in the PORR domain to facilitate balloting for ICSR Release 2 DSTU and the Generic Incident Notification (GIN) Message. GIN will be retained in the publishing domain as a separate topic and Safety Reporting will be removed to eliminate redundancy with the ICSR Topic.
ICSR Part 1 Data Elements
The data elements and concepts presented in Part 1 of this standard reflect the areas of overlap between ISO and HL7. In the previous release of this standard, these data elements were referenced in support of "Generic Transmission Use Cases". However, the concept of a generic transmission use case is not an SDO harmonized concept and is confusing for reviewers. Therefore this concept is removed from this publication. However, the sponsoring committees identified a core set of common data elements that are consistent across all use cases. Due to significant differences in national and international requirements that govern the release and exchange of safety data, this standard does not enforce adoption of these data elements. Note that the standard supports both coded attributes and free text entries for many of the data elements and readers should use the hyperlinks to the Hierarchical Message Definition (HMD) files to view detailed information about the attribute level descriptions for all data elements
ICSR Basic Pattern
The diagram below provides a high level summary of the core class components of the ICSR. It is desirable that each ICSR have a minimum data set in order to process and evaluate the report:
The following points should be noted:
Readers should note that this model is actually a CMET (R_ProductReportable COCT_RM630000UV) derived from the Common Product Model (CPM). This CMET may adjust over time as updates are made to the CPM. The ISO and HL7 committees will continue work to harmonize requirements for the ISO Identification of Medicinal Products work items. The data elements reflected in this release of CPM DSTU Release 1 support the current pharmacovigilance requirements of ISO 27953-1 and ISO 27953-2. Readers should note that ISO 27953 will use the most current version of CPM in its final international standard publication set for early 2011. Navigation to the CMET content is through the ICSR base model Investigation Component Choice box and the consumable, product, and device participations in the A_ProductReportingRelatedInformation CMET.
High Level Description of the ICSR Content
The ICSR is comprised of two models defined directly in the PORR (public health reporting domain) and two CMETs:
ICSR and the Act State Machine
The focal class for the ICSR Refined Message Information Model (RMIM) is InvestigationEvent. Messaging related to the reporting of adverse events, product problems or consumer complaints is directly associated with the notification, initiation and/or progress of an investigation into an event. The diagram below provides a summary view of the states and state transitions that are relevant to the ICSR.
Note that the the dynamic behavior being modeled is quite simple. Messaging takes place when the discovery of an event or new information is "complete", and the reporter or sender determines that it is necessary to report to a receiving party (e.g., regulatory authority, manufacturer, public health or patient safety organization.) The decision to report may be based upon specific business processes, regulations or statutory requirements, and the process for information flow is repeated when there is a need to revise or retract a previous report.
|
||||||
|
For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.
The storyboards provided for Part 1 of this standard help to describe the reporting situations where the ICSR message could be used. Note that Part 1 also supports all of the use cases presented in Part 2 of this standard. However, not all Part 2 storyboards are listed in Part 1 in an effort to help streamline publication and reduce the amount of redundant material. Several of the referenced use cases were provided by a variety of sources including:
Individual Case Safety Report Create | ![]() |
Individual Case Safety Report Revise | ![]() |
Individual Case Safety Report Retract | ![]() |
Mrs. Mary Patient visited her General Practitioner/Family Physician, Dr. Greta Provider last week because she was suffering from a severe urinary tract infection (UTI). Dr. Provider prescribed a course of Ciprofloxacin 250mg tablets to be orally taken twice a day for 5 days. Mrs. Patient's only other regular medication is hormone replacement therapy, for which she takes Prempak C 625micrograms.
After three days, Mrs. Patient's UTI is resolving well, but she is experiencing increasing soreness of her left ankle. She has no recollection of injuring her ankle in any way. On the fourth day, her ankle is so sore that she makes another appointment to see Dr. Provider later that day. Dr. Provider examines Mrs. Patient and observes that her left ankle is red, stiff, hot and swollen. Mindful of Mrs. Patient's comments that she has no recollection of doing anything that might have injured her ankle, Dr. Provider wonders what other causes there might be for these symptoms. Remembering that she prescribed an antibiotic for a urinary tract infection on Monday for Mrs. Patient, she checks her clinical software for Mrs. Patient's medication record and sees the prescription for Ciprofloxacin. She then checks the electronic drug formulary for information on Ciprofloxacin and Quinolone antibiotics as a family, and it reminds her that Quinolones are known to have an adverse effect of tendonitis, especially of the Achilles tendon. The formulary advises that the medicine should be stopped immediately and the affected joint rested.
Dr. Provider's clinical judgment leads her to be confident that Mrs. Patient is experiencing an adverse drug reaction to her treatment for her UTI. She explains this to Mrs. Patient, and that she must stop the Ciprofloxacin (she feels that the UTI has resolved well), and rest her ankle, and that the ankle soreness will resolve. She may take some painkiller medication (paracetamol/acetaminophen) if she would like to. However, she would like to see her again in a week just to be sure all is well. One week later, Mrs. Patient sees Dr. Patient again. Her ankle is improving nicely and she feels that in a couple of days she will be back to normal. After she has left, Dr. Provider thinks through this incident, and decides that, due to the severity of the event she should report it to a patient safety/quality improvement organization, the relevant drug manufacturer, and regulatory authority. She logs into her clinical support system to complete an electronic Individual Case Safety Report form. The electronic form already includes many of the details of Mrs. Patient's adverse drug event. The form appears on the screen, with some of her relevant information already filled in e.g., Mrs. Patient's demographic information, relevant medical history, lab tests and results and current medications. The form includes Dr. Provider's progress notes and other sections ready for her input. When Dr. Provider is satisfied that the form is complete, she then authorizes her clinical support system to send the electronic report to the appropriate organization(s).
Interaction: Individual Case Safety Report Create(PORR_IN049006)
Product Problem Reporting
This storyboard is provided to help illustrate how the ICSR can be used for product problem reporting. Note that the ICSR interactions are the same as those used to support adverse event reporting.
Rebecca Pharmacist is preparing a solution to be used in chemotherapy for patients in General Hospital's outpatient cancer clinic. She notices, as she holds up a bottle from storage, that the solution appears cloudy and has particles floating in it. This physical property is not according to specification and she sets the bottle aside. At the end of the day, a more thorough inspection reveals that half the bottles in a case of Solution X contain contaminated or defective solution. She reports the problem to the medical supply department and the hospital risk manager sends a product problem report to the regulatory authority and to the manufacturer.
Interaction: Individual Case Safety Report Create (PORR_IN049006UV)
This storyboard is a revised report based upon the storyboard for PORR_SN040001UV01)
Last week, Dr. Greta Provider submitted an Individual Case Safety report that referred to Mrs. Mary Patient's adverse drug experience with Ciprofloxacin as a treatment for UTI. As she reviews the records of the case, it seems to her that perhaps the fact that Mrs. Patient was an ardent runner could be a relevant factor in evaluating the cause of her recent tendonitis. Dr. Provider decides to send a revised ICSR so that this additional information will be considered when Mrs. Patient' case is evaluated by the appropriate organization(s).
Interaction: Individual Case Safety Report Revise: (PORR_IN049007)
Request for Nullification
This storyboard is not based on any real world event and is being provided to help demonstrate support of the use case.
Mr. Law, JD is an attorney specializing in private injury work. He has recently been putting together a class action suit seeking damages for patients who had been taking the drug, CureAll, as a treatment for lower back pain. However, in a fraction of cases, while the back pain had improved, patients had experienced severe headaches. Mr. Law, and his clients, believe that CureAll is responsible and they are seeking damages.
As Mr. Law's office signs up users of CureAll as parties to this lawsuit, they also file an ICSR for each new client. This report includes the relevant information regarding the individual case. Such a report was filed when the office agreed to represent Patient A, who stated that he was a long time CureAll user and headache sufferer.
After further discussions with Patient A, it emerges that had started experiencing headaches long before his use of CureAll, and may be related to trauma he experienced as a child when he was kicked by a horse. Once it becomes clear that CureAll cannot reasonably be involved, Patient A is informed that he is being dropped from the suit. Mr. Law's office also sends an ICSR retraction to the local regulatory agency to nullify this report.
Interaction: Individual Case Safety Report Retraction (PORR_IN049008UV)
Shortly after the submission of the ICSR product problem report for Solution X (storyboard PORR_STN040002UV01), General Care Hospital receives a call from the Acme Supply Company, whom also received a copy of the ICSR product problem report. The Acme representative informs the hospital that based upon the lot number reported in the ICSR, this product could not be one of theirs because the product lot number in the report violates Acme's lot number convention for assigning lot identifiers. The hospital's medical supply department representative reviews the paperwork for deliveries from Acme Supply, and locates the correct bill of lading for the product delivery in question. With the proper lot information in hand, the medical supply department informs the hospital risk manager that a corrected ICSR product problem report needs to be sent to the regulatory authority and manufacturer.
Interaction: Individual Case Safety Report Revise: (PORR_IN049007)
Request for Nullification: Product Problem Report
This storyboard uses the same ICSR nullify interaction used for adverse event reporting..
RealFixit Corporation, a medical device manufacturer, reports a serious injury to the FDA for a patient who underwent major abdominal surgery. This manufacturer learned later that their product did not cause or contribute to the patient's injury; however another company's product caused the patient's injury. The RealFixit Corporation forwards a request to retract their original device problem report since their product did not contribute to the injury. The manufacturer of the other suspected problem device submitted a serious injury report also.
Interaction: Individual Case Safety Report Retraction (PORR_IN049008UV)
Device Adverse Event Report
This storyboard provides an example of the submission of a medical device adverse event report or a device-related procedure. The storyboard was created by FDA Center for Device and Radiological Health (CDRH) to illustrate the reporting of device-related events using a fully electronic, two-way communication ICSR process between senders and receivers of ICSR reports. Some FDA capabilities described in this storyboard are not currently available.
The Event
On December 12, 2005 Eve Everywoman, a 54 year old female was admitted to the Outpatient Surgery Center for the placement of a Portman Medical Corporation, Model LS 4700, implantable pain pump. In surgery, the pain pump was implanted without difficulty and was determined to be functional. After the procedure the patient was referred to the recovery area for stabilization. In the recovery room, the anesthesiologist Dr. Sally Sleeper initiated the programming of Ms. Everywoman's implanted pump. During this set-up procedure the pump stopped functioning and the pump's visual display went blank. The anesthesiologist was unable to troubleshoot the cause of the device failure, nor restore its function. The patient was informed of the device failure and opted to return to the O.R. the next day for the removal of the defective device and placement of a new pain pump. The patient was scheduled to return to the O. R. for the repeated procedure. The second Model LS 4700 implantable pain pump was implanted and completed its programming process without difficulty.
Creation of the Initial Primary Source Report
Dr. Sleeper decided to complete an electronic Individual Case Safety Report, using the hospital's Incident Reporting System because he felt his patient had suffered a serious injury. She logged into the incident reporting system and completed the necessary fields required to populate a device adverse event. The form appeared on the computer screen with a great deal of Ms. Everywoman's patient demographics, medical history and many details of her surgical case already populated because the incident reporting system references data already stored in the patient's electronic medical record. The event information was obtained from the surgeon's and the anesthesiologist's progress notes and automatically populated into the appropriate fields in the form. Once the report of the incident was completed, Dr. Sleeper clicked the submit key. This sent the incident report to the risk manager, Patient Safety Committee, the device manufacturer and the regulatory authority. Mr. Randy Riskers, the hospital risk manager, reviewed the incident report, made some edits and gave approval that this was a reportable event that could be sent to FDA. He clicked a 'Submit SMDA Event' button that electronically forwarded the ICSR report to the manufacturer. Additionally, the hospital returned the pain pump to the manufacturer for evaluation three days after the event.
Interaction: Individual Case Safety Report Create (PORR_IN049006UV)
Manufacturer Response to Reported Event - Note that this demonstrates how the Related Report class is used in the ICSR
Two weeks after the implantable pain pump was returned to Portman Medical for failure analysis, the manufacturer sent an update for the ICSR to the hospital and to the FDA. The manufacturer was able to store the hospital's source report and create a new related report in their internal Adverse Event Reporting System using the User Facility (hospital) Report as a primary source document.
Interaction: Individual Case Safety Report Complete (PORR_IN049007UV)
FDA Request for Additional Information
FDA electronically returns the ICSR report with an attached document. This correspondence is in response to information received at the Center for Devices and Radiological Health (CDRH) involving the Portman Medical Corporation, Model LS 4700 implantable pain pump implanted on December 12, 2005. The FDA requested additional information about the software issue described in the medical device report, including the steps taken to address the stated problem. The manufacturer will be given 30 days to respond to the Center's request for additional information.
Interaction: Individual Case Safety Report Create (PORR_IN049006UV)
Manufacturer Response to Request for Additional Information
Manufacturer sends new, changed or updated information via ICSR. This follow up serves to respond to CDRH's request for additional information about the software issue described in a report involving a Portman Medical Corporation, Model LS 4700 implantable pain pump implanted on December 12, 2005. The Center requested information as to the software issue described as part of the root cause analysis of the implanted pain pump's failure. The responses to the issues posed are as follows: The software issue described in this report was a result of an event that would take place only in the rare instances of high resistance of the motor, causing an excessive back EMF (Electromotive Force). This would ultimately lead to an inadvertent timeout of the internal watchdog times of the microprocessor, causing the pump to turn off prematurely. A revision to the software of the Model LS 4700 implantable pain pump has completed Portman's Engineering Design Change Process. Additionally, testing has been conducted on the software revision and no further instances of this failure have been detected. It is felt no further risk can be associated with this release of the software. Once approved, new pumps being built will contain the new software revision. FDA stores all of the information related to this event and completes appropriate review of the event.
Interaction: Individual Case Safety Report Revise (PORR_IN049007UV)
FDA Reportable Food Registry Reporting
Great Cracker Company's Plant in St Cloud, MN produces two box sizes of Great Crackers--a 12 ounce box and a family-size 18 ounce box. On July 3rd, 2008, a routine QA inspection of lots produced from July 1st through July 3rd detected a strange odor during a tasting of samples from each box. Upon further testing, it was determined that the products had been contaminated with a very deadly pesticide. The quantity of production during this time frame was 10,000 boxes of the 12 ounce size (5,000 in lot # 2008-0701-200, and 5,000 in lot # 2008-0702-201) and 8,000 boxes of the 18 ounce size Box (lot # 2008-0703-202).
Before the problem was discovered, 6,000 of the 12-ounce (5,000 from lot # 2008-0701-200 and 1,000 from the other lot) and 6,000 of the 18-ounce Boxes were shipped to a local grocery warehouse in St Paul and 1,000 of the 18-ounce boxes were shipped to another local grocery warehouse in Richmond, VA. It was determined that the adulteration was unintentional and happened at the St Cloud facility and was not due to adulterated raw materials from suppliers.
The two retail warehouses were notified on 3 July in time for the warehouses to quarantine the reportable food products.
The remaining Great Crackers were disposed of on 3 July at the St Cloud plant.
The company's risk manager and (the person who is in the FDA food facility registration database for the plant) logs into a Federal AE Portal and enters this report the evening of 3 July in compliance with 1005 legislation. His report includes the following information:
Interaction: Individual Case Safety Report Create(PORR_IN049006)
Dietary Supplement Adverse Event Storyboard
Mrs. Nuclear, an 86 year old female consumed 400 IU of vitamin D made by Supplement Company IOP. Four hours later she fell to the floor and had a seizure. When she stopped seizing, her husband noted that she did not awake, and called the 911-Emergency Dispatcher. When the paramedics arrived, Mrs. Nuclear was still unconscious and she was taken to the hospital. When she arrived at the hospital, Mrs. Nuclear regained consciousness in the examination room, and the emergency room attending physician, Dr. Attend ordered a series of tests to be performed to obtain a more precise diagnosis of Mrs. Nuclear condition. Mr. Nuclear informed the attending physician that they starting taking a new vitamin D supplement, and that he suspects that Mrs. Nuclear is having an adverse reaction to the supplement. Dr. Attend responded to Mr. Nuclear that he does not suspect this to be the case, but informs Mr. Nuclear that he can report the incident to the dietary supplement company or FDA to help alleviate his suspicion. Mr. Nuclear called the FDA's Consumer Complaint hotline to report the problem, and provided a contact number for Dr. Attend for follow up once the laboratory results are final. The FDA Consumer Complaint hotline technician data entered the complaint into the system, and sent the case electronically to the FDA Center for Food and Applied Nutrition (CFSAN) for further analysis and follow up.
Interaction: Individual Case Safety Report Create (PORR_IN049006UV)
The FDA CFSAN medical officer reviewed the adverse event report submitted by Mr. Nuclear. The medical officer contacts Dr. Attend and requests that the laboratory results and discharge summary be sent to FDA for review. The medical officer provides Dr. Attend with the consumer complaint number for the case. Dr. Attend queries his clinical system and notes that Mrs. Nuclear was diagnosed as having a low potassium level and an abnormal heart beat. The discharge summary reflects that she was placed on a Potassium supplement and Digoxin. Dr. Attend updates the patient's record to include the dietary supplement Mrs. Nuclear ingested to search for drug interactions related to the ingredients of the dietary supplement. The system returned no information about drug/supplement interactions with the product made by Supplement Company IOP. Dr. Attend generates an incident report and sends the requested information to FDA electronically, noting that he does not suspect that Mrs. Nuclear hospitalization was related to the dietary supplement she ingested prior to her arrival. FDA reviews the laboratory results and discharge summary and determines that no further action is required on the case.
Interaction: Individual Case Safety Report Create (PORR_IN049006UV)
Cosmetics Adverse Event Reporting: Multiple Suspected Cases
The following two adverse events involved the same cosmetic face paint product. They occurred within a few days of each other, from different areas of the country
Wallace Wackyford, a Fun Store employee, submitted an adverse event report to the FDA to report an incident after being contacted by the principal of the Central Z Middle School. A black color face paint (item# 5), produced by Coverings Corporation, as listed on the label, was applied to the students as part of a special theme day. Approximately 300 students received an application of face paint with different brushes. The following day, approximately 70 - 80 students reported having a rash on their face. Later the number of rashes had accumulated to approximately 173. A dozen or so students sought medical treatment. Medical information was not included in the report from Mr. Wackyford. The report was sent electronically using a web-based form. The web-based form translates the information into an HL7 ICSR and routes the report to the appropriate FDA safety evaluator for analysis.
Interaction: Individual Case Safety Report Create(PORR_IN049006)
A counselor of a boy's organization called the state FDA Field Office to report an incident that occurred at their annual banquet. The counselor reported that several colors of face paint from Company Y were used to mark the cheek of each boy. A total of about 40 boys were marked in this manner using one of three colors: blue, red, and green. Of the 18 boys which received the blue face paint, a total of 16 experienced a skin reaction. This reaction ranged from a red, 'burnt' appearance which lasted about 48 hours to a raised, bright red rash which still remained 5 days later when the incident was reported to the counselor. To the knowledge of the reporter, no boy received care from a medical doctor for the problem. The FDA Field Office employee data entered the report into the Consumer Complaint System and the report was sent electronically to the FDA headquarters office for further analysis and follow up.
Interaction: Individual Case Safety Report Create(PORR_IN049006)
Parent/Child Reports: Related ICSR Reports
On 12th of July, 2003, a male child was born at full term (40 weeks gestation) with polydactyl feet (1 extra toe each foot). The mother of the child had been taking oral Propylthiouracil 200 mg once a day for Hyperthyoridism before and during early pregnancy (therapy dates 20th April 2003 to 28th June 2006). However the 30 year old mother stopped taking the drug at 12 weeks gestation as she experienced a severe skin eruption that was attributed due to the propylthiouracil. The mother's adverse event was reported to the authorities at that time and was assigned the case identifier US-Nobel-MT99101.
The obstetrician contacted the marketing authorisation holder of the medicinal product (Nobel Company) and informed them of the child's congenital anomaly due to exposure in-utero as he believed the child had receiving the drug transplacentally.
Creation of Related Child Report
The company collected all the details of the event within their own records system. An assessor from the pharmacovigilance group within the company reviewed the data and made the following comments:
Company comment: Propylthiouracil is known to cross the placental barrier in low quantities when used by the mother sometime during pregnancy. Studies have shown that the frequency of congenital malformations is higher in patients not treated for hyperthyroidism than those treated for it. The alternative treatments for hyperthyroidism of radioactive iodine and surgery are not recommended for pregnant patients.
The company completed an electronic ICSR, using their own IT system, which included a reference to the mother's related AE report id US-Nobel-MT99101, and submitted the report electronically to the regulatory agency on the 20th July 2003.
Regulatory agency response - Note that this function is outside of the ICSR standard and refers to HL7's accept acknowledgement interaction ID (MCCI_IN000002UV01)
The electronic report is received by the agency from Nobel company and it was checked against their requirements for a valid report. The report is found to be valid and a positive acknowledgement is returned to Nobel Company to confirm receipt and acceptance of the report.
Interaction: Individual Case Safety Report Create(PORR_IN049006)
The Event
In the UK a multi-centre clinical trial with the EU Clinical trial authorisation number (EUDRACT No. 2004-09102-03) is being conducted to evaluate the efficacy and tolerability of Danthium, a new substance, in post-menopausal women with breast cancer hormone receptor positive tumours. The sponsor of the trial assigned the protocol No 0105798/01.
A 50 year-old female patient was enrolled in this trial with the patient ID 125-0871 and one week after the third cycle of chemotherapy treatment with intravenous Danthium 20 mg/kg once a week, the patient developed a fever (38o C) and diarrhoea (11th May 2003). The patient was hospitalised. Blood tests were performed and the patient was discovered to have neutropenia. This adverse event was considered as serious and unexpected. Specific lab test information such as the lab test date, name, results (including structured units of measurement) and an indication of whether or not the lab test was within the normal range were included in the ICSR report. The patient was treated with G-CSF and recovered a week later. The patient is a smoker and has a family history of breast cancer. The patient was also concomitantly taking oral domeridone for Nausea.
Interaction: Individual Case Safety Report Create(PORR_IN049006)
Creation of the Clinical Trial Initial Report
The investigator responsible for the patient (Dr. Davis at Cardiff University hospital, Cardiff, Wales) informed the sponsor (Big Company) of the event and the sponsor in turn created an electronic report to submit to the appropriate regulatory authorities using their own IT system.
The company also provides their causality assessment of the case, which reflects that it is likely that the investigational medicinal product caused the reaction.
Regulatory Authority response (outside of the ICSR functionality and refers to HL7 accept acknowledgement interaction ID (MCCI_IN000002UV01)
The electronic report is received by an agency from Big Company and it is checked against their requirements for a valid report. The report is found to be valid and a positive acknowledgement is returned to Big Company to confirm receipt and acceptance of the report.
The Event
In the EU a multi-state clinical trial with the EU Clinical trial authorization number (EUDRACT No. 2004-09102-03) is being conducted in Germany and Netherlands to evaluate the efficacy and tolerability of Danthium, a new substance, in post-menopausal women with breast cancer hormone receptor positive tumors. The sponsor of the trial assigned the protocol No 0105798/01. The clinical trial authorization number assigned by the German authorities is '12345678' and the authorization number assigned by the Dutch authorities is 'NL12345.001.07'
A 50 year-old female patient with the patient ID 125-0871 was enrolled in this trial in a German centre and one week after the third cycle of chemotherapy treatment with intravenous Danthium 20 mg/kg once a week, the patient developed a fever (38o C) and diarrhea (11th May 2003). The patient was hospitalized. Blood tests were performed and the patient was discovered to have neutropenia. This adverse event was considered as serious and unexpected.
Lab Test Results:
Date________Test Name___________Test Result___Test Units____Normal Range
12/05/2003___Neutrophil Count______4.0 x10e9_____cells/l_______2.0 - 7.5
12/05/2003___WBC_______________6.8 x10e9_____cells/l_______4.0 - 11.0
19/05/2003___Neutrophil Count______0.8 x10e9_____cells/l_______2.0 - 7.5
19/05/2003___WBC_______________4.5 x10e9_____cells/l_______4.0 - 11.0
26/05/2003___Neutrophil Count______3.8 x10e9_____cells/l_______2.0 - 7.5
26/05/2003___WBC_______________6.3 x10e9_____cells/l_______4.0 - 11.0
The patient was treated with G-CSF and recovered a week later. The patient is a smoker and has a family history of breast cancer. The patient was also concomitantly taking oral domeridone for Nausea.
Interaction: Individual Case Safety Report Create(PORR_IN049006)
Creation of Initial ReportThe investigator responsible for the patient (Dr B. Bernard at Berlin University hospital, Berlin) informed the sponsor (Big Company) of the event and the sponsor in turn created an electronic report to submit to the concerned regulatory authorities using their own IT system. The company provides the following assessment of the case: It is likely that the investigational medicinal product caused this reaction.
Regulatory Authority response - note this is outside of ICSR functionality and refers to HL7 accept acknowledgement interaction ID (MCCI_IN000002UV01)
The electronic report is received by an agency from Big Company and it is checked against their requirements for a valid report. The report is found to be valid and a positive acknowledgement is returned to Big Company to confirm receipt and acceptance of the report.
|
||||||||
|
For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.
|
||||||||||
|
For details on the interpretation of this section, see the discussion of trigger events in the Version 3 Guide.
Type: |
Indicates that a report containing notification of an eligible case associated with a regulated or suspect product is ready for transmission to an eligible receiver. The notification may include the report of an adverse reaction, of a product problem, or include information related to both adverse events and product problems.
|
||||||||
|
For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.
Parent: | Public Health Reporting (PORR_DM000000UV) |
Model Overview
The ICSR Base Model RMIM is designed to support two aspects of product reporting within a single structure. These include:
The RMIM is oriented around the following concepts:
This message, as with all HL7 V3 specifications, includes a Control Act structure which contains information about the actual report transmission. (The reader should refer to the HL7 V3 Infrastructure Management Domain for more details on this structure.)
Please refer to the HMD documentation for more detailed information on classes and attributes.
IndividualCaseSafetyReport | PORR_HD049006UV01 |
Parent: | Public Health Reporting (PORR_DM000000UV) |
Model Overview
The A_ProductReportingRelevantInformation RMIM captures information about the acts that describe how a product was used by an investigative subject or a person related to that subject. The information includes use of the product (substance administration and device procedures) and any associated clinical or laboratory information directly related to the product's use at a particular point in time, e.g., related to an adverse event, or as part of a subject's medical history. The model also supports other patient care or healthcare related processes such as actions taken to mitigate or reduce harm. A choice box structure is used (based upon HL7's A_SupportingClinicalInformation CMET) to capture the relevant information needed to evaluate the case. It is expected that implementers will need to provide the appropriate code sets needed to distinguish between the various kinds of acts or observations used in the CMET. Examples include Organizer codes to group medical or medications history, Observation codes for patient specific observations such as age and weight, and clinical diagnosis or conditions such as Diabetes.
The information model supports:
Please refer to the HMD documentation for more detailed information on classes and attributes.
Product Reporting Relevant Information | PORR_HD049013UV01 |
|
||||||||
|
For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.
This HMD includes the data needed to submit an ICSR report about an adverse event, product problem or consumer complaint.
A_ResearchStudyEnrollmentUniversal | COCT_MT970000UV |
R_ProductReportableUniversal | POCP_MT020200UV01 |
A_RelevantInformationForProductReportingUniversal | PORR_MT049013UV01 |
ICSR | PORR_MT049006UV01 | ![]() ![]() ![]() |
The A_ProductReportingRelevantInformation HMD contains the serialized elements from the corresponding RMIM.
R_SpecimenUniversal | COCT_MT080000UV09 |
E_PlaceUniversal | COCT_MT710000UV07 |
R_ProductReportableUniversal | POCP_MT020200UV01 |
R_ProductReportableUniversal | POCP_MT020200UV01 |
ICSR A_ProductReportingRelevantInformationHMD | PORR_MT049013UV01 | ![]() ![]() ![]() |
|
||||||||||
|
For details on the interpretation of this section, see the definition of Interactions in the Version 3 Guide.
The interaction supports revisions or amendments to previously sent individual case safety report messages.
Trigger Event | ICSR Revise Notification | PORR_TE049007UV01 |
Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
Message Type | ICSR | PORR_MT049006UV01 |
Sender | ICSR Notification Sender | PORR_AR040001UV01 |
Receiver | ICSR Notification Receiver | PORR_AR040002UV01 |
The interaction supports the communication of a new individual case safety report. Note that this interaction supports both initial and follow up reports.
Trigger Event | ICSR Complete Notification | PORR_TE049006UV01 |
Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
Message Type | ICSR | PORR_MT049006UV01 |
Sender | ICSR Notification Sender | PORR_AR040001UV01 |
Receiver | ICSR Notification Receiver | PORR_AR040002UV01 |
The interaction supports the cancellation of a previously sent individual case safety report. Note that this is commonly referred to as a nullification report.
Trigger Event | ICSR Withdraw Notification | PORR_TE049008UV01 |
Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
Message Type | ICSR | PORR_MT049006UV01 |
Sender | ICSR Notification Sender | PORR_AR040001UV01 |
Receiver | ICSR Notification Receiver | PORR_AR040002UV01 |
Return to top of page |