Skip to main content

E2B(R3) generation

E2B(R3) XML files can be generated from and attached to an Adverse Event record. They are attached as Files or as Attachments depending on the “Use Files” Global Setting value configured within the instance.

The following file formats are supported:

  • Portable network graphics (.png)

  • Bitmap image format (.bmp)

  • Graphics interchange format (.gif)

  • Word processing document format (.wpd)

For additional details regarding the E2B(R3) support, see E2B(R3) support.

Enablement

To enable the ability for users to generate E2B files, add one of the Generate E2B buttons or Quick Actions to the Adverse Event page layout.

Configuration

Medical Information Cloud Inquiry Management ships with a default mapping of Adverse Event (and child object) fields to nodes in the E2B(R3) XML specification. These mappings can be modified using the E2B Field Mapping and E2B Setting custom metadata types. The field mapping maps the Data Element Identifiers (e.g., C.1.2) to fields in the Medical Information Cloud Inquiry Management data model. Currently, only data elements with a default mapping are supported in the output E2B file.

If Medical Information Cloud Inquiry Management is configured to use Salesforce Files instead of attachments, additional documents attached to the Adverse Event are also included in the E2B file.

Custom labels

This component makes use of the following labels that can be configured within the Salesforce translation workbench to change display text values.

#

Label Name

Description

1

MED_E2B_Download_Button

2

MED_E2B_Error

3

MED_E2B_Field_Required

4

MED_E2B_Generate_Button

5

MED_E2B_Generator_Header

6

MED_E2B_Generator_Instruction_Text

7

MED_E2B_Invalid_Document_Format

8

MED_E2B_Success

Customization

Customers can override how E2B XML documents are generated through the use of the E2B customization framework. This framework is intended to be utilized by a Salesforce.com developer to alter how E2B XML files are generated. This can be useful should an XML element attribute require a localized value that differs from the standard XML schema that is supported.

The high-level process of customizing an XML node generation is as follows:

  1. Review the documentation within the MED_E2B_MCCI_IN200100UV01_Batch apex class within the Medical Information Cloud Inquiry Management source code.

  2. Create a new Apex Class that extends the MED_E2B_MCCI_IN200100UV01_Batch apex class, and implement the desired implementations of the relevant virtual methods from the MED_E2B_MCCI_IN200100UV01_Batch class. As a best practice appropriate test code should also be written to offer unit test coverage for the customization.

  3. Deploy the new Apex Class to the appropriate environments.

  4. Create an E2B Custom Generator Customer Metadata Type to register the new Apex Class with the E2B generation process.

  5. Test the custom functionality by generating test E2B documents.

For developers seeking to customize how an XML element within the E2B file is generated, visit How to Contact Customer Support to contact Komodo Health Customer Support for sample code and additional developer details.

NullFlavors

As a general rule, Medical Information Cloud omits the node instead of using a nullFlavor. For example, if a field does not have a value, it is not included and nullFlavor is not used. However, if a value of UNK or NI is in the mapped field, this will be converted to a nullFlavor attribute. Finally, if D.1 or D.10.1 is null, they will be sent as a nullFlavor of MSK.

Integration

Customers that intend to integrate generated E2B files with 3rd party systems are recommended to explore facilitation via an integration service provider. The Salesforce.com platform is optimized to support multi-tenancy, which includes limits placed on the amount of computing resources any one tenant can consume from shared platform resources. Specifically, there exist several limits on the size and duration of outbound HTTP/S requests that can be made natively on the Salesforce.com platform.

Given the nature of E2B files and the potentially large number and large size of related source materials, it is recommended that Customers use an external integration solution, such as a middleware provider, to ensure E2B files are transmitted in a reliable and scalable fashion.

For more information on the relevant platform governor limits, see Salesforce's documentation.

E2B(R3) support

Medical Information Cloud Inquiry Management can now generate E2B files that comply with the R3 specification, available here: https://www.fda.gov/downloads/Drugs/GuidanceComplianceRegulatoryInformation/Guidances/UCM275638.pdf

It should be noted that not all elements supported within the comprehensive E2B(R3) specification are supported currently. While efforts have been made to cover the portions of the specification most relevant to medical information, there may exist certain scenarios that are not presently covered. For this reason, it is highly recommended that sufficient time be allocated to properly define the requirements specific to a particular implementation of E2B within Medical Information Cloud Inquiry Management and rationalize them against the supported field set to ensure no gaps exist. Fields that are not explicitly listed below should be considered unsupported.

Supported E2B(R3) elements

The current set of E2B(R3) elements supported within Medical Information Cloud Inquiry Management is defined in the tables below.

Case safety report elements

Element number

Element name

C.1.3

Type of Report

C.1.4

Date Report Was First Received from Source

C.1.6.1

Are Additional Documents Available

C.1.6.1.r.1

Documents Held by Sender

C.1.7

Does This Case Fulfill the Local Criteria for an Expedited Report?

C.2.r.1.1

Reporter’s Title

C.2.r.1.2

Reporter’s Given Name

C.2.r.1.3

Reporter’s Middle Name

C.2.r.1.4

Reporter’s Family Name

C.2.r.2.1

Reporter’s Organization

C.2.r.2.2

Reporter’s Department

C.2.r.2.3

Reporter’s Street

C.2.r.2.4

Reporter’s City

C.2.r.2.5

Reporter’s State or Province

C.2.r.2.6

Reporter’s Postcode

C.2.r.2.7

Reporter’s Telephone

C.2.r.3

Reporter’s Country Code

C.2.r.4

Qualification

C.2.r.5

Primary Source for Regulatory Purposes

C.4.r.1

Literature Reference(s)

C.5.3

Sponsor Study Number

C.5.4

Study Type Where Reaction(s) / Event(s) Were Observed

Patient elements

Element number

Element name

D.1

Patient (name or initials)

D.2.1

Date of Birth

D.2.2.1a

Gestation Period When Reaction / Event Was Observed in the Foetus (value)

D.2.2.1b

Gestation Period When Reaction / Event Was Observed in the Foetus (unit)

D.2.3

Patient Age Group (as per reporter)

D.3

Body Weight (kg)

D.4

Height (cm)

D.5

Sex

D.6

Las Menstrual Period Date

D.7.1.r.1a

MedDRA Version for Medical History

D.7.1.r.1b

Medical history (disease / surgical procedure / etc.) (MedDRA code)

D.7.1.r.2

Start Date

D.7.1.r.3

Continuing

D.7.1.r.4

End Date

D.7.1.r.5

Comments

D.7.1.r.6

Family History

D.7.2

Text for Relevant Medical History and Concurrent Conditions (not including reaction / event)

D.7.3

Concomitant Therapies

D.8.r.1

Name of Drug as Reported

D.8.r.4

Start Date

D.8.r.5

End Date

D.8.r.6a

MedDRA Version for Indication

D.8.r.6b

Indication (MedDRA code)

D.8.r.7a

MedDRA Version for Reaction

D.8.r.7b

Reaction (MedDRA code)

D.9.1

Date of Death

D.9.2.r.1a

MedDRA Version for Reported Cause(s) of Death

D.9.2.r.1b

Reported Cause(s) of Death (MedDRA code)

D.9.2.r.2

Reported Cause(s) of Death (free text)

D.9.3

Was Autopsy Done?

D.9.4.r.1a

MedDRA Version for Autopsy-determined Cause(s) of Death

D.9.4.r.2

Autopsy-determined Cause(s) of Death (free text)

D.10.1

Patient Identification

D.10.2.1

Date of Birth of Parent

D.10.2.2a

Age of Parent (number)

D.10.3

Last Menstrual Period Date of Parent

D.10.4

Body Weight (kg) of Parent

D.10.5

Height (cm) of Parent

D.10.6

Sex of Parent

D.10.7.1.r.1a

MedDRA Version for Medical History

D.10.7.1.r.1b

Medical History (disease / surgical procedure/ etc.) (MedDRA code)

D.10.7.1.r.2

Start Date

D.10.7.1.r.3

Continuing

D.10.7.1.r.4

End Date

D.10.7.1.r.5

Comments

D.10.7.2

Text for Relevant Medical History and Concurrent Conditions of Parent

D.10.8.r.1

Name of Drug as Reported

D.10.8.r.4

Start Date

D.10.8.r.5

End Date

D.10.8.r.6a

MedDRA Version for Indication

D.10.8.r.6b

Indication (MedDRA code)

D.10.8.r.7a

MedDRA Version for Reaction

D.10.8.r.7b

Reactions (MedDRA code)

Reaction / Event elements

Element number

Element name

E.i.1.1a

Reaction / Event as Reported by the Primary Source in Native Language

E.i.1.1b

Reaction / Event as Reported by the Primary Source Language

E.i.1.2

Reaction / Event as Reported by the Primary Source for Translation

E.i.2.1a

MedDRA Version for Reaction / Event

E.i.2.1b

Reaction / Event (MedDRA code)

E.i.3.1

Term Highlighted by the Reporter

E.i.3.2a

Results in Death

E.i.3.2b

Life Threatening

E.i.3.2c

Caused / Prolonged Hospitalisation

E.i.3.2d

Disabling / Incapacitating

E.i.3.2e

Congenital Anomaly / Birth Defect

E.i.3.2f

Other Medically Important Condition

E.i.4

Date of Start of Reaction / Event

E.i.5

Date of End of Reaction / Event

E.i.6a

Duration of Reaction / Event (number)

E.i.6b

Duration of Reaction / Event (unit)

E.i.7

Outcome of Reaction / Event at the Time of Last Observation

E.i.8

Medical Confirmation by Healthcare Professional

E.i.9

Identification of the Country Where the Reaction / Event Occurred

Test result elements

Element number

Element name

F.r.1

Test Date

F.r.2.1

Test Name (Free text)

F.r.2.2a

MedDRA Version for Test Name

F.r.2.2b

Test Name (MedDRA code)

F.r.3.1

Test Result (code)

F.r.3.2

Test Result (value / qualifier)

F.r.3.3

Test Result (unit)

F.r.3.4

Result Unstructured Data (free text)

F.r.4

Normal Low Value

Note

Enter numeric values for the units described in MED_Unit__c. Numeric values improve reporting per the E2B(R3) specification.

F.r.5

Normal High Value

Note

Enter numeric values for the units described in MED_Unit__c. Numeric values improve reporting per the E2B(R3) specification.

F.r.6

Comments (free text)

F.r.7

More Information Available

Drug elements

Element number

Element name

G.k.1

Characterization of Drug Role

G.k.2.2

Medicinal Product Name as Reported by the Primary Source

G.k.2.4

Identification of the Country Where the Drug Was Obtained

G.k.3.1

Authorization / Application Number

G.k.3.2

Country of Authorization / Application

G.k.3.3

Name of Holder / Applicant

G.k.4.r.1a

Dose(number)

G.k.4.r.1b

Dose (unit)

G.k.4.r.2

Number of Units in the Interval

G.k.4.r.3

Definition of the Time Interval Unit

G.k.4.r.4

Date and Time of Start of Drug

G.k.4.r.5

Date and Time of Last Administration

G.k.4.r.6a

Duration of Drug Administration (number)

G.k.4.r.6b

Duration of Drug Administration (unit)

G.k.4.r.7

Batch / Lot Number

G.k.4.r.8

Dosage Text

G.k.4.r.9.1

Pharmaceutical Dose Form (free text)

G.k.4.r.10.1

Route of Administration (free text)

G.k.4.r.10.2a

Route of Administration TermID Version Date / Number

G.k.4.r.10.2b

Route of Administration TermID

G.k.4.r.11.1

Parent Route of Administration (free text)

G.k.4.r.11.2a

Parent Route of Administration TermID Version Date / Number

G.k.4.r.11.2b

Parent Route of Administration TermID

G.k.5a

Cumulative Dose to First Reaction (number)

G.k.5b

Cumulative Dose to First Reaction (unit)

G.k.6a

Gestation Period at Time of Exposure (number)

G.k.6b

Gestation Period at Time of Exposure (unit)

G.k.7.r.1

Indication as Reported by the Primary Source

G.k.7.r.2a

MedDRA Version for Indication

G.k.8

Action(s) Taken with Drug

G.k.9.i.3.1a

Time Interval between Beginning of Drug Administration and Start of Reaction / Event (number)

G.k.9.i.3.1b

Time Interval between Beginning of Drug Administration and Start of Reaction / Event (unit)

G.k.9.i.3.2a

Time Interval between Last Dose of Drug and Start of Reaction / Event (number)

G.k.9.i.3.2b

Time Interval between Last Dose of Drug and Start of Reaction / Event (unit)

G.k.9.i.4

Did Reaction Recur on Re-administration?

G.k.11

Additional Information on Drug (free text)

Case summary elements

Element number

Element name

H.1

Case Narrative Including Clinical Course, Therapeutic Measures, Outcome and Additional Relevant Information

H.2

Reporter’s Comments

Transmission identification elements

Element number

Element name

N.1.3

Batch Sender Identifier

N.1.4

Batch Receiver Identifier

N.2.r.2

Message Sender Identifier

N.2.r.3

Message Receiver Identifier

Document attachments

Optionally, you can configure whether or not you want documents compressed and included in the E2B file. This can be enabled for any attachments that are included in-line within the E2B file. Medical Information Cloud supports the deflate compression algorithm. For additional details on this configuration, see E2B(R3) support.

To enable file compression:

  • If you are including files, ensure the Use Compression (MED_Use_Compression__c) field on the E2B Setting (MED_E2B_Setting__mdt) custom metadata type is checked.

  • If the files attached to the E2B should be included in the E2B XML file, ensure the Include Files (MED_Include_Files__c) field on the E2B Setting (MED_E2B_Setting__mdt) is checked.

As of Medical Information Cloud V15, the new E2B package, the E2B XML is now always stored as a Salesforce file and never as an attachment as the MED_Global_Settings__.MED_Use_Files__c metadata is no longer supported. As such, you still need to configure these settings for the new E2B package. Reference the Required actions section below.

Required actions

If using the new E2B package, you must complete the following required actions:

  1. Assign the new MED_E2B_User permission set to users who need to generate E2B files. If using permission set groups, as recommended, add this new permission set to the existing group that is assigned to your users.

  2. Make sure MED_E2B_Setting__mdt.MED_Include_Files__c is checked unless MED_Global_Settings__.MED_Use_Files__c was unchecked (rare). The former controls whether files are included in the XML output.