| Return to Domain Table of Contents |
4.1 Storyboards
4.2 Application Roles
4.3 Trigger Events
4.4 Refined Message Information Models
4.5 Hierarchical Message Descriptions
4.6 Interactions
Introduction
The Individual Case Safety Report (ICSR) topic area captures the information needed to support the reporting of adverse events or product problems associated with the use of drugs, therapeutic biologics, vaccines and devices. Over time, the scope of the messaging may be expanded to support other types of products such as food, dietary supplements, cosmetics or veterinary products and services. The message is specifically designed to support individual case safety reports, and not support population-based case reporting for disease surveillance or outbreak events. In addition, the message is designed to support international safety reporting between public health organizations such as the World Health Organization, and regulatory authorities in the US, Canada, Europe and Japan using the International Conference on Harmonisation (ICH) E2B M2 ICSR message transmission standard.
|
Reference
For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.
Purpose
The storyboards provide examples of situations in which the Public Health Individual Case Safety Report message would be used.
Diagram
| Individual Case Safety Report |  PORR_IN040001UV01 |
Mrs. Mary Jones visited her General Practitioner/Family Physician, Dr. Greta Greene last week because she was suffering from a severe urinary tract infection (UTI). Dr. Greene prescribed a course of Ciprofloxacin 250mg tablets to be orally taken twice a day for 5 days. Mrs. Jones' only other regular medication is hormone replacement therapy, for which she takes Prempak C 625micrograms.
After three days, Mrs. Jones' 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. Greene later that day. Dr. Greene examines Mrs. Jones and observes that her left ankle is red, stiff, hot and swollen. Mindful of Mrs. Jones' comments that she has no recollection of doing anything that might have injured her ankle, Dr. Greene 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. Jones, she checks her clinical software for Mrs. Jones' 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. Greene's clinical judgment leads her to be confident that Mrs. Jones is experiencing an adverse drug reaction to her treatment for her UTI. She explains this to Mrs. Jones, 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. Jones sees Dr. Greene 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. Greene 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. Jones' adverse drug event. The form appears on the screen, with some of her relevant information already filled in e.g., Mrs. Jones' demographic information, relevant medical history, lab tests and results and current medications. The form includes Dr. Greene's progress notes and other sections ready for her input. When Dr. Greene 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 (PORR_IN040001)
Last week, Dr. Greta Greene submitted an Individual Case Safety report that referred to Mrs. Mary Jones' 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. Jones was an ardent runner could be a relevant factor in evaluating the cause of her recent tendonitis. Dr. Greene decides to send a follow-up ICSR so that this additional information will be considered when Mrs. Jones' case is evaluated by the appropriate organization(s).
Interaction: Individual Case Safety Report Revise: (PORR_IN040002)
[Note, this storyboard is not based on any real world event.] Reginald Witherspoon, 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. Witherspoon, and his clients, believe CureAll is responsible, and they are seeking damages.
As Mr. Witherspoon'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 George Gould, who stated that he was a long time CureAll user and headache sufferer.
After further discussions with Mr. Gould, 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, Mr. Gould is informed that he is being dropped from the suit. Mr. Witherspoon's office also sends an ICSR retraction to the local regulatory agency.
Interaction: Individual Case Safety Report Withdraw (PORR_IN040003)
Pharmacist Rebecca Rogers 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 files a product problem report with the regulatory authority and the manufacturer.
Interaction: ICSR Product Defect Report (PORR_IN040004)
Shortly after the submission of the ICSR product problem report for Solution X, General Hospital receives a call from the Acme Supply Company - which had 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. The product lot number in the report could not have applied to one of their products, because it violates Acme's convention for assigning lot numbers. The hospital representative checks the paperwork for deliveries from Acme Supply, and is able to find the bill of lading for the delivery in question. With the proper lot information in hand, a follow up ICSR product problem report is submitted to the regulatory authority and the manufacturer.
Interaction: Product Defect Report Revise (PORR_IN040005)
A device manufacturer reports a serious injury to a patient who underwent major abdominal surgery. This manufacturer learned later that its product did not cause or contribute to the patient's injury, but another product made by a second manufacturer caused the patient injury. The manufacturer that initially reported the event retracted the report about its device. The manufacturer of the problem device submitted a serious injury report, too.
Interaction: Product Defect Report Withdraw (PORR_IN040006)
| ||||||||||||||||||||||||||||||||||||||||||||||
Reference
For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.
| Structured Name: | ICSR Event Comprehensive Receiver |
Indicates the party that receives notification of the adverse event or product problem.
| Structured Name: | ICSR Event Comprehensive Informer |
Indicates the party that provides notification of the adverse event or product problem.
|
Reference
For details on the interpretation of this section, see the discussion of trigger events in the Version 3 Guide.
| Structured Name: | ICSR Event Create Notification |
| Type: | State-transition based |
| State Transition: | Investigation (PORR_RM040001UV01) |
Indicates that notification of an eligible case, e.g., report of a drug reaction, is ready for transmission to an eligible receiver.
| Structured Name: | ICSR Event Create Notification |
| Type: | State-transition based |
| State Transition: | Investigation (PORR_RM040001UV01) |
Indicates that notification of a product defect, is ready for transmission to an eligible receiver.
| Structured Name: | ICSR Event Cancel Notification |
| Type: | State-transition based |
| State Transition: | Investigation (PORR_RM040001UV01) |
| Structured Name: | ICSR Event Cancel Notification |
| Type: | State-transition based |
| State Transition: | Investigation (PORR_RM040001UV01) |
Indicates that the creating institution has cancelled a previously issued product defect report.
| Structured Name: | ICSR Event Revise Notification |
| Type: | State-transition based |
| State Transition: | Investigation (PORR_RM040001UV01) |
Indicates that the creating institution has made changes to the material covered in a previous individual case safety report, and is transmitting a revised version.
| Structured Name: | ICSR Event Revise Notification |
| Type: | State-transition based |
| State Transition: | Investigation (PORR_RM040001UV01) |
Indicates that the creating institution has made changes to the material covered in a previous product defect report, and is transmitting a revised version.
|
Reference
For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.
Diagram
Click thumbnail above to open larger graphic in a new window
| Parent: | Public Health Reporting Domain Information Model (PORR_DM180001UV01) |
Model Overview
The Individual Case Safety Report (ICSR) Refined Message Information Model captures the information needed to support the reporting of individual case safety events and product problems to public health, patient safety/quality improvement organizations or regulatory agencies. Initially, it is intended that the message support reporting of this type from healthcare providers; however the content of the message is designed to support a broader spectrum of reporters such as hospitals, contract research organizations, or clinicians. The ICSR is also compatible with the ICH E2B M2 ICSR message transmission specification. The initial development of this HL7 specification has been most particularly oriented towards reporting of reactions to regulated drugs. At the same time, this model is designed to support therapeutic biologics, vaccines, and related reporting for medical devices if a device failed. It is also intended that the messaging support the reporting of possible product problems - whether these be drug or device related. Over time, the scope of the messaging may be expanded to include possible vaccine related incidents and problem reports as well as supporting other types of reporting needs for food, dietary supplements, cosmetics, or veterinary products and services.
The RMIM is oriented around the following concepts:
a) Adverse events/experiences: Any adverse event associated with the use of a product in humans, whether or not considered product related, including the following: An adverse event occurring in the course of the use of a product in professional practice, an adverse event occurring from over dose of the product whether accidental or intentional, an adverse event occurring from withdrawal of the product, and any failure of expected pharmacological action. Note that these events result in unintended harm to the patient by an act of commission or omission rather than by the underlying disease or condition of the patient.
b) Suspected Adverse Drug Reaction: A noxious and unintended response to any dose of a drug product for which there is a reasonable possibility that the product caused the response. In this definition, the phrase "a reasonable possibility means that the relationship cannot be ruled out.
c) Suspected medical product problems or defects: A problem that is detected before a substance is given to a patient, or a device is used for treatement.
d) An affected person, e.g., patient.
e) Substance administrations: drugs, therapeutic biologics, vaccines.
f) Medical devices or procedures related to devices.
g) Supporting clinical information: The notion of supporting clinical information includes additional detail such as relevant observations, procedures, substance adminstrations and encounters. These are included if the reporting party thinks them relevent, whether referring to the same point in time as the suspect event or as part of the patient history.
The model walk through below provides more information on the way these topics are represented within the ICSR.
This RMIM is designed to support two kinds of messages. The first type of message consists of a report on the investigation into the adverse event(s) or reaction(s) suffered by an affected person who has experienced an intervention or interventions in a therapeutic context. The suspect event may or may not have a causal relationship with the administration of one or more pharmaceutical products, or it could be associated with a device. The second type of message consists of a report on the investigation into a reported problem associated with a drug, biologic, vaccine or a device.
It is important to note that an actual message also includes a Control Act structure. That area of the message includes information about the actual report transmission. (The reader should refer to the Infrastructure Management Domain for more details.)
InvestigationEvent
The InvestigationEvent serves as the entry point for the messaging model (as noted above, this entry point links back to the control act). The investigation class captures information directly related to the investigation, and pulls together the rest of the relevant information. Depending on the situation, the investigation will be associated either with information possibly related to a device or drug related reaction suffered by a subject, or with information related to a product (drug or device) problem.
Note; the attributes associated with an investigation are captured within the InvestigationEvent class in the RMIM. In particular, activityTime is used to record the time that the report is completed, while availabilityTime is used to record the time on which the most recent information included within the investigation report was received. For the sake of completeness, it is worth mentioning that the date on which the report is transmitted is captured within the Control Act structure.
InvestigationEvent Associations
The following associations - act relationships and participations - are defined for the investigation event itself. Each association captures the relationship between the investigation and an entity or another type of act that plays a significant part in the investigation. (Note, the discussion of the associations has been ordered by "walking" around the central class in a clockwise direction, and that the association role text is recorded for each. Also, as in the ultimate XML schema, the association text is used as the tag for referring to the individual asociation.).
-
document: This act relationship provides a way of capturing primary source documents and literature references that the report sender feels are relevant to the investigation, and considered part of the report.
-
caseSeriousness: The act relationship provides a way to capture information regarding the seriousness of the suspected reaction - that is to say the extent to which the patient was injured.
-
product: The participation captures information related to a drug or device that is the subject of a product report. (Note, this association will not exist in an event related individual case safety report.) The detailed product report is captured in the R_Drug and R_Device message element types that are defined within the PORR domain.
-
intervention: The act relationship provides information for those interventions that are most significantly related to the suspected reaction(s) covered by the report. This includes suspect and comcommitant interventions, as well as those performed to mitigate the effect of a suspected reaction. This assoication also makes it possible to record the priority of each intervention for those reports in which multiple interventions are included within a single report. This includes mitigating interventions as well as suspect ones.
-
reaction: This act relationship relates the investigation to the reaction or reactions that are the subject of an individual case safety report. (Note, this act relationship will not exist in a product report.) See below for a more detailed discussion of reactions and the items of information related to a reaction.
-
secondaryCaseNotification: A secondary case notification is a report created by another party - such as another regulatory agency or a manufacturer - that conveys information about the event, suspected event, or possible product problem that is the subject of this report. The report is labeled a "secondary" report to distinguish it from the initial report of the event or problem.
-
investigation Event: The act relationship records information, most notably the assigned identifier, for individual case safety investigations that are related to this one.
-
assignedEntity: As is usual within HL7 messaging, there may be information that captures the author and/or performers of an act. In this case, the participation is linked to the Assigned Role. The author or performer (whichever is being specified) is captured as the player of this role. Information about the controlling jurisdiction, is captured as the scoper of the role
Reaction
A reaction is the consequence, perhaps strongly indicated, perhaps only possibly related, of the substance administration or device procedure. It constitutes the core of the individual case safety report since, without a reaction or event, there would be no perception of an adverse reaction, and no report at all.
Reaction associations
The following associations - act relationships and participations - are defined for the reaction. Each association captures the relationship between the reaction and an entity or another type of act that plays a significant part in the individual case safety report. (Note, the discussion of the associations has been ordered by "walking" around the central case in a clockwise direction.)
-
interventionStub: The act relationship makes it possible to record the time interval between an intervention (adverse drug or device event) and the reaction. It can also be used to identify the list of different interventions that are associated with the individual reaction. The intervention stub choice box includes stub classes - containing just an id - that allow linkage to substance administration(s) or procedure(s) that have already been referenced. Note, identifiers should be assigned which are only relevant within the context of a single ICSR in order to support cases in which patient confidentiality must be maintained.
-
reactionRelatedness: The act relationship captures the assessment or assessments of the relatedness between an intervention and the reaction. That is to say, it records judgments - made by the party indicated by the author or performer participation - about the extent to which the intervention caused a particular reaction.
-
reactionEmphasis: The act relationship records the emphasis, e.g., Highlighed, that the reporter placed on the reaction. The possible values for reaction emphasis are drawn from the ICH E2B M2 transmission message specification.
-
outcome: The act relationship records the outcome of the reaction. The possible values for outcome are drawn from the ICH E2B M2 transmission message specification.
-
concurrentObservation: The act relationship captures clinical observations about the patient suffering the reaction that are directly tied to the reaction itself. For example, age at the time of exposure.
-
serviceDeliveryLocation: The participation captures the location at which the patient received care related to the reaction.
-
investigativeSubject : The participation captures information about the person who, by virture of the suspected reaction, is the subject of the report. This is person plays the role of investigated subject. All of the clinicial statements related to an investigation are associated with the investigation subject, or with a person - typically mother or sibling associated with the investigated subject. The identifier in the investigated subject role is intended for disambiguating the subject of clinical statements, and for keeping track of the clinical statements linked to a particular investigation. It should not be used to carry information that could identify the subject in any context external to the investigation.
-
primarySourceReport: The primary source report captures information about the original report of the reaction. This report could be from a health care provide, the patient or relative of the patient, or from another party such as a lawyer. You should note that the primary source report could also be associated to the secondary case notifications.
Affected Person
This is the person directly affected by the event(s) or reaction(s). Other parties who are directly related to the substance administration or device procedure may also be included. In the case of safety reports that involve drug administrations, it is possible for the patient to be a nursing infant or a fetus who is harmed by drugs administered to the patient's mother. Similarly, information may be captured for siblings (this is done in the case of vaccine reactions) or other persons related to the affected person.
Affected Person Roles
The following associations are defined for the person or persons affected by the possible adverse event. (Note, the discussion of the roles has been ordered by "walking" around the central affected person class in a clockwise direction.
-
asResearchSubject: This association is relevant when the person suffering the reaction is also part of a clinical trial. In that case, the cluster of classes related to ResearchSubject and Clinical Trial serves to identify the clinical trial and to provide the patient's id within that trial. The person may be the research subject of either a pre-market or post-market clinical trial.
-
subjectAffectedPerson: This association provides the linkage - mentioned above - to the reaction suffered by the investigated person. It is also important to note that a wide range of information may be recorded about the patient. This information is managed through the Clinical Statement Choice data structure, which is modeled on the emerging HL7 consensus for supporting clinical statements.
-
relationshipHolder: In those cases in which information is collected about persons other than the person suffering the reaction, that person plays the role of the associated person scoped by the patient. Today, these cases include mothers who ingested drugs that affected a fetus or nursing child, and siblings of persons suffering vaccine reactions. The relationship between the associated person and the patient is indicated by AssociatedPerson.code.
-
associatedPerson: In the situation discussed above, the patient, scopes the role of AssociatedPerson.
-
asIdentifiedEntity: This association makes it possible to record identifiers the patient or associated person is known by. The party issuing the identifier is indicated as the scoping entity for the IdentifiedEntity role.
-
asPersonalRelationship: This associatiion makes it possible to record the relationship between the investigative subject and the reporter of the reaction in cases where this is relevant.
Drug/Device
The interventions that led to (perhaps) patient reactions or adverse events currently fall into two categories: substance administrations (drugs, biologics or vaccines), and the use of devices or device procedures. The specific information for each suspect intervention is captured in the A_DrugIntervention and A_DeviceIntervention message element types that are associated with the InvestigationEvent through the intervention association. These message element types are defined elsewhere within the PORR domain. Note, interventions deemed concomitant or historical are captured directly within the ICSR RMIM as supporting clinical information, as discussed below.
Supporting Clinical Information
The ClinicalStatementChoice structure and all its associations captures a range of relevant clinical or contextual facts that are captured for the report. Among other items, this includes observations from the patient's medical history, and other observations that are entered in order to provide context to the suspect event. The attribute, ActCode, plays a key role for the obesrvations and other acts recorded within this structure. It identifies the type of act that is being recorded or requested. (Note, LOINC will be used for coding observations wherever possible). As with interventions, the subject of the observation may not be the patient, but could be a person related to the patient. Supporting clinical information could include substance administrations, procedures, encounters and supply acts as well as observations. Within this structure is is worth noting that observations can be supported by reference ranges - as indicated by the related Observation Criterion act, that the consumable substance for a substance administration is captured as a Medication entity playing the role of administered drug, and that the product distributed in a supply act is captured in a similar fashion. Also, the sourceOf act relationship can be used to link multiple instances of any of the acts within the choice structure.
The reader should note that the committee intends the use of supporting clinical information within the ICSR (as shown by the ClinicalStatementChoice structure) to follow the pattern supported by the general HL7 consensus for modeling clinical statements. If that consensus is manifested in the creation of a CMET, the CMET will be used if possible. However, the requirements of ICSR reporting have led the committee to make additions to the current clinical statement draft model. These additions are represented by two sets of acts related to the clinical statement choice:
- interventionCharacterization: This act makes it possible to for a reporter to indicate the role that the primary reporter felt that the suspect intervention - either a substance administration or a device related procedure - played in the incident being reported
- indication: This act allows the reporter to identify the indication - the reason - for an act that was performed on the subject of the act.
Relationship to the ICH E2BM
Another perspective on this HL7 Refined Message Information Model is to compare it with the International Conference on Harmonisation (ICH) E2B M2 ICSR transmission message standard. A mapping to the ICH standard was prepared in the course of creating this model, and will be made available once it has been updated to reflect the current model contents.
| ICSR Event Individual Case Safety Reaction Report HMD | PORR_HD040001UV01 |
| ICSR Event Product Report HMD | PORR_HD040006UV01 |
Diagram
Click thumbnail above to open larger graphic in a new window
| Parent: | Public Health Reporting Domain Information Model (PORR_DM180001UV01) |
Model Overview
The A_DrugIntervention message element type captures the substance administration related information that is relevant for drug administrations possibly related to an adverse reaction. The relevant information includes items related to the substance administration itself, to component parts of a more general administration act, as well as to ancillary information related to the substance administration. This message element type is being used to capture substance administrations for drugs, therapeutic biologics, and vaccines. In the basic ICSR model, this information is associated with the InvestigationEvent class through the Intervention association.
The SubstanceAdministrationEvent class captures information directly related to the administration of the drug that is possibly related to a reaction/event. If it is necessary to introduce component substance administrations, this initial administration will provide the overall context for the adverse event.
The following list goes through the different participations and act relationships that are specified for the substance administration. These associations are ordered by taking a clockwise walk around the base class within this model.
- drug: This participation indicates which drug has been administered, and provides a link to other relevant information regarding that drug. That information is discussed in the description of the R_Drug message element type.
- assignedEntity: The participation provides relevant information about parties responsible for authoring and/or performing the substance administration.
- serviceDeliveryLocation: The participation provides relevant information about the location at which the drug was administered.
- interventionCharacterization: This act relationship makes it possible to characterize the substance administration as either suspect, concomitant, interacting, or historical as required by the ICH E2BM message specification. This characterization offers a judgment of how the intervention was related to the reaction suffered by the patient.
- actionTaken: This act relationship makes it possible to characterize the action taken with regard to the substance administration as either drug withdrawn, dose reduced, dose increased, etc. as required by the ICH E2BM message specification. This characterization offers a judgment of practitioner's response to the patient's problem.
- (pertinent)substanceAdministrationEvent: This recursive act relationship makes it possible to provide information about other substance administrations that are related to the original one. This makes it possible, for example, to capture information about drugs given to mitigate the effects of the suspect drug.
- (component)substanceAdministrationEvent: This act relationship makes it possible to identify components of a more general substance administration. The creation of multiple components is needed to record, for example, multiple routes of administration used for a single drug within the context of a more general administration regime.
- clinicalStatementChoice: This act relationship makes it possible to refer to clinical statements that are relevant to the substance administration. Please refer to the description of the base ICSR model for a brief discussion of the clinical statement choice structure.
- subjectChoice: This participation indicates the subject of the substance administration. That subject is either an investigated or associated person for which information was captured in the base ICSR model. The reference to the investigated person or investigated person roles contains an ID which should only be valid within the context of this ICSR in order to preserve patient confidentiality. This ID is not used for or intended to reference an organization's unique patient identifier.
| ICSR Event A_Drug Interventionhmd | PORR_HD040002UV01 |
Diagram
Click thumbnail above to open larger graphic in a new window
| Parent: | Public Health Reporting Domain Information Model (PORR_DM180001UV01) |
Model Overview
The A_DeviceIntervention message element type captures the procedure related information that is relevant to medical device adverse event reporting. The relevant information includes items related to the procedure itself, to component parts of a more general procedure act, as well as to ancillary information related to the procedure.
The following list goes through the different aspects of the message element type.
-
device: A device related adverse event has to be related to a procedure - the purpose that the device is supposed to serve. This class collects the information directly related to the procedure. If it is necessary to introduce component procedures, this procedure will provide the overall context for the adverse event. Note, it is assumed that the person identified as the patient for the overall ICSR is the person using the device.
-
assignedEntity: The association provides relevant information about parties responsible for authoring and/or performing the device intervention procedure.
-
serviceDeliveryLocation: The association provides relevant information about the location at which the device was used for patient care.
-
interventionCharacterization: This association makes it possible to characterize the procedure (device related) as either suspect, concomitant, interacting, or historical. This characterization offers a judgment of how the device intervention was related to the reaction suffered by the patient.
-
actionTaken: This association makes it possible to characterize the action taken with regard to the device related procedure. This characterization offers a judgment of practitioner's response to the patient's problem.
-
(component)procedureEvent: This association makes it possible to identify components of a more general procedure. The creation of multiple components is needed to record, for example, information about device implantation and explantation.
-
clinicalStatementChoice: This association makes it possible to identify clinical statements that are associated with the device procedure or other relevant medical history. Please refer to the description of the base ICSR model for a brief discussion of the clinical statement choice structure.
-
subjectChoice: This association makes it possible to identify the person on whom the procedure was performed. That person will be an investigated person or an associated person for whom information was collected in the base ICSR model. The identifier used for the person should only be valid within the context of a single ICSR in order to preserve patient confidentiality.
| ICSR Event A_Device Interventionhmd | PORR_HD040003UV01 |
Diagram
Click thumbnail above to open larger graphic in a new window
| Parent: | Public Health Reporting Domain Information Model (PORR_DM180001UV01) |
Model Overview
The R_Drug message element type captures the drug information that is relevant for drug related* adverse event and product reporting. The relevant information includes items related to the drug itself, and to its manufacture and sale. *Note: This message element type is being used to capture information for drugs, therapeutic biologics, and vaccines. The model also captures financial information for mass immunization programs, such as military, school, or state/local immunization programs.
The following list summarizes the different aspects of the message element type. The reader should note that, while expressing the requirements of public health reporting, the model follows, as much as possible, the structure used in the pharmacy/medication related domain model and CMETs.
The central class in this model - Medication - captures information about the substance that was administered to the subject of the substance administration, either an investigated person or a person related to the investigated person. The information associated with the medication is described by walking, as ususal, clockwise around this central class.
-
asRetailedProduct: It is relevant, for drug related adverse events, to collect information about the location where the drug was sold, in particular to identify the country of sale.
-
ingredient: This association makes it possible to identify the ingredients contained within a drug. This is particularly important for multi-ingredient formulations.
-
asEntityWithGeneric: In some cases it is relevant to identify the generic name that is used for a drug.
-
asManufacturedProduct: The model captures the site at which the drug is manufactured - at the most detailed level known to the reporter (if at all). If, in addition to the manufacturing site, it is important to be able to identify the drug manufacturer (the corporate entity that organizes and carries out drug development, production, and distribution); this information is captured as an organization scoping the agent role played by the manufacturing site. This agency role can be traversed as many times as necessary to capture the organization responsibility for manufacturing the product.
There are associations of the manufacturer that should be noted.
- contactParty: In some cases, it is important to be able to contact a manufacturer representative in order to follow up on a report of a drug adverse event.
- representedManufacturer: This association is valued to indicate the organization that scopes the Agent role played by the direct manufacturer of the product.
- asAgent: It is possible for the organization manufacturing the product to do so as an agent of another party. In that case, the manufacture plays the role of agent - which is scoped by another instance of the manufacturer class
-
partMedication: This association captures the fact that the medication is relevant for the ICSR as an AdministeredDrug (a substance that either was administered or was going to be administered to a subject). The AdministeredDrug role also provides the entry point to the message element type.
There is an assocation of the AdministeredDrug that deserves attention.
- approval: The approval association captures information about the process of approving a substance for therapeutic use. The relevant items include the identifier (often known as NDA number in the US) that is assigned to the approval, the country in which this approval was issued - shown as the Country that plays the role of Territorial Authority for the regulatory Agency issuing the approval, and the date on which the approval was granted.
| ICSR Event R_Drug HMD | PORR_HD040004UV01 |
Diagram
Click thumbnail above to open larger graphic in a new window
| Parent: | Public Health Reporting Domain Information Model (PORR_DM180001UV01) |
Model Overview
The R_Device message element type captures the device information that is relevant for device related adverse event and product reporting. The relevant information includes items related to the device itself, and to its manufacture and sale.
A device, in this context, refers to a manufactured item that is used directly in treating and/or caring for the patient. The model captures information about devices by using one class - Device - to capture descriptive information directly related to the particular device, and another - DeviceModel to capture information related to the kind of device.
Device
The following list provides a review of various roles and act relationships associated with the Device entity. Note, the descriptions are ordered by taking a clockwise walk through the data structure.
- identifiedDevice: This associatiion makes it possible to record
identifiers for the device, along with the role played by the identifier
(Role.code), and the organization responsible for the identifier.
Associated with the identifiedDevice role is the Approval act. This act captures information about the process of approving a substance for therapeutic use. The relevant items include the identifier (often known as NDA number in the US) that is assigned to the approval, the country in which this approval was issued - shown as the Country that plays the role of Territorial Authority for the regulatory Agency issuing the approval, and the date on which the approval was granted.
- asLocationLocatedEntity: The association between the device and the location role CMET captures the location at which the device was located.
- asManufacturedProduct: The scoper for this role
(ManufacturerOrReprocessor) captures the site at which the device is
manufactured and/or reprocessed - at the most detailed level known to the
reporter (if at all). If, in addition to the device manufacturing site, it is
important to be able to identify the device manufacturer (the corporate entity
that organizes and carries out the medical device development, production, and
distribution); this information is captured as a
representedManufacturerOrReprocessor scoping the agent role played by the
manufacturing or reprocessing site. This agent role can be traversed as many
times as necessary to capture the organization responsibility for
manufacturing or reprocessing of the product. The scoper for the
ManufacturedProduct may also be the site at which the drug is manufactured -
at the most detailed level known to the reporter (if at all). If, in addition
to the drug manufacturing site, it is important to be able to identify the
drug manufacturer (the corporate entity that organizes and carries out drug
development, production, and distribution); this information is captured as a
representedManufacturerOrReprocessor scoping the agent role played by the
manufacturing site. This agent role can be traversed as many times as
necessary to capture the organization responsibility for manufacturing the
product. In the situation where the device is a single use device that has
been reprocessed, it is relevant to identify the re-processor instead of the
original manufacturer.
The associations related to the manufacturing entity (ManufacturerOrReprocessor) are sufficiently rich to deserve their own discussion:
- contactParty: It is important to be able to contact a manufacturer representative in order to follow up on a report of a device adverse event.
- asRole: In some cases, a device will be retured to the manufacturer or re-processor for evaluation. This evaluation is captured as an act in its own right. The items of information collected as a result of this evaluation, Evaluation Method, Evaluation Result, and Evaluation Conclusion, are collected as acts related to an Investigation Event. This structure makes it possible to record information about the evaluation, about observations recorded during the evaluation, and about the final conclusions of the evaluation process.
- asIdentificiedOrganization: In some cases the report on the device includes identifiers for the manufacturing organization.
- asAgent: The Agent role was described above, and makes it
possible to specify the organization that is ultimately responsible for
manufacture of the medical device (the manufacturer as opposed to the
manufacturing site). This makes it possible to identify the country and
other relevant information about that responsible party.
representedManufacturerOrReprocessor: The reader should note that the entity ManufacturerOrReprocessor both plays and scopes the agent role. That is to say, the same class in the model is used to capture information about the manufacturer and the manufacturing site. When the party fabricating the device (aka manufacturer) is captured as the Agent for another organization, that organization scopes the Agent role as shown by the association that as labeled as "representedManufacturerOrReprocessor".
- inventoryItem: This association indicates the device type related to this device instance.
Device Model
The following list provides a review of various roles and act relationships associated with the Device Model. Note, the descriptions are ordered by taking a clockwise walk through the data structure
- manufacturedDeviceModel: As noted, above, the DeviceModel class represents the device instance related to this device type.
- asRegulatedProduct: Provides a link to the regulatory authority that is relevant when we need to record identifiers assigned by the authority which are used to identify the device as it moves through the stages of development, testing, and production.
| ICSR Event R_Device HMD | PORR_HD040005UV01 |
|
Reference
For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.
Description
The Device InterventionHMD includes the information related to medical device related procedures that are referred to in an ICSR. Note, this structure is essentially a PORR internal message element type.
At this time there is no content for this section.
| Icsr Event Create A_deviceinterventionmt | PORR_MT040003UV01 | |
Description
The Drug InterventionHMD includes the information related to drug related subtance administrations that are referred to in an ICSR. Note, this structure is essentially a PORR internal message element type.
At this time there is no content for this section.
| Icsr Event Create A_druginterventionmt | PORR_MT040002UV01 | |
Description
This HMD includes the data that may be needed to file an ICSR report on an adverse event or reaction to a drug, biologic, vaccine, or device that has been implanted or is otherwise providing services to a patient.
At this time there is no content for this section.
| ICSR Event Create | PORR_MT040011UV01 | |
| ICSR Event Cancel | PORR_MT040012UV01 | |
Description
This HMD includes the data that may be needed to file an ICSR report on a drug or a device that has not been involved in a patient related reaction.
At this time there is no content for this section.
| Icsr Event Create Product Report | PORR_MT040061UV01 | |
| ICSR Event Cancel Product Report | PORR_MT040062UV01 | |
Description
The Device HMD includes the information related to medical devices that are referred to in an ICSR. Note, this structure is essentially a PORR internal message element type.
At this time there is no content for this section.
| Icsr Event Create R_devicemt | PORR_MT040005UV01 | |
Description
The Drug HMD includes the information related to drugs that are referred to in an ICSR. Note, this structure is essentially a PORR internal message element type.
At this time there is no content for this section.
| Icsr Event Create R_drugmt | PORR_MT040004UV01 | |
|
Reference
For details on the interpretation of this section, see the definition of Interactions in the Version 3 Guide.
| Structured Name: | Icsr01 Event Create Individual Case Safety Report |
The interaction supports the communication of a new individual case safety report.
| Trigger Event | ICSR Notification | PORR_TE040001UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | ICSR Create Reaction Report | PORR_MT040011UV01 |
| Sender | ICSR Notification Sender | PORR_AR040001UV01 |
| Receiver | ICSR Notification Receiver | PORR_AR040002UV01 |
| Structured Name: | Icsr02 Event Revise Individual Case Safety Report Revision |
The interaction supports revisions to previously sent individual case safety report messages.
| Trigger Event | ICSR Revise Notification | PORR_TE040002UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | ICSR Create Reaction Report | PORR_MT040011UV01 |
| Sender | ICSR Notification Sender | PORR_AR040001UV01 |
| Receiver | ICSR Notification Receiver | PORR_AR040002UV01 |
| Structured Name: | Icsr03 Event Cancel Individual Case Safety Report Retraction |
The interaction supports the cancellation of a previously sent individual case safety report.
| Trigger Event | ICSR Withdraw Notification | PORR_TE040003UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | ICSR Cancel Reaction Report | PORR_MT040012UV01 |
| Sender | ICSR Notification Sender | PORR_AR040001UV01 |
| Receiver | ICSR Notification Receiver | PORR_AR040002UV01 |
| Structured Name: | Icsr04 Event Create Product Defect Report |
The interaction supports the communication of a new product defect report.
| Trigger Event | Product Defect Report Notification | PORR_TE040004UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | ICSR Create Product Report | PORR_MT040061UV01 |
| Sender | ICSR Notification Sender | PORR_AR040001UV01 |
| Receiver | ICSR Notification Receiver | PORR_AR040002UV01 |
| Structured Name: | Icsr05 Event Revise Product Defect Report Revision |
The interaction supports revisions to previously sent product defect messages.
| Trigger Event | Product Defect Report Revise Notification | PORR_TE040005UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | ICSR Create Product Report | PORR_MT040061UV01 |
| Sender | ICSR Notification Sender | PORR_AR040001UV01 |
| Receiver | ICSR Notification Receiver | PORR_AR040002UV01 |
| Structured Name: | Icsr06 Event Cancel Product Defect Report Retraction |
The interaction supports the cancellation of a previously sent product defect report.
| Trigger Event | Product Defect Report Withdraw Notification | PORR_TE040006UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | ICSR Cancel Reaction Report | PORR_MT040012UV01 |
| Sender | ICSR Notification Sender | PORR_AR040001UV01 |
| Receiver | ICSR Notification Receiver | PORR_AR040002UV01 |
| Return to top of page |