Supporting ADE Detection and Reporting using EHR data

1. Supporting ADE Detection and Reporting using EHR data SALUS Advisory Board Meeting, Paris (January 17, 2013) – Gunnar Declerck (INSERM), Tobias Krahn (OFFIS)

2. ADE Notificationprocess (1/2) • Twomainobjectivesregarding ADE detection • 1. Notificationofsuspected, alreadyknown ADEs • 2. Notificationofsuspected, unknown ADEs • ADE detectionprocess • Ifnewdatais relevant for ADE detection… • The EHR ischeckedforknown ADEs • Via Databasesand ADE detectionrules • Ifnoknownpatternisfound • Data Mining processtodiscovernewpatterns SALUS Advisory Board Meeting, Paris

3. ADE Notificationprocess (2/2) SALUS Advisory Board Meeting, Paris

4. Currentstatus • Access todatabasescontaininginformationabout ADEs havebeenrequested • First versionof ADE detectionrulesisready • Data Mining approachtodetectsuspected ADEs iscurrently in development • First draft will besharedbythe end ofJanuary 2013 SALUS Advisory Board Meeting, Paris

5. ADE Detection Rules • Different typesof ADE detectionrules • Rules based on laboratoryparameters • 3 concepts: • 1. muscle-, liver- andkidney-parameters, e.g. • ALAT (Liver), normal range: male: 10-50 U/l; female: 10-35 U/l • ADE Detection Rule: 2x normal value after drug prescription • 2. bone marrow-parameters, e.g. • Number of leukocytes, normal range: adults: 4,4-11,3 x 1000/µl • ADE Detection Rule: Shrinkage of more than 30% of reference value after drug prescription • 3. major electrolytes, e.g. • natrium, normal range: 134-145 mmol/l • ADE Detection Rule: At least 20% change of normal value afterdrug prescription SALUS Advisory Board Meeting, Paris

6. ADE Detection Rules • Rules based on theprescriptionofspecificantidotes • 42 ingredients, e.g. acetylcysteine • Rules based on drug discontinuation • Published rules • ADE detection rules from the PSIP project • 236 validated rules • Perhaps reusable for the SALUS project • Example: SALUS Advisory Board Meeting, Paris

7. ADE Notification – specificquestionsto AB • Alternative databasescontaininginformationaboutknown ADEs thatcouldbeuseable • Other detectionrulesorsourcesforexisting ADE detectionrules • Other ADE detectionapproachesthatcouldbetakenintoconsideration SALUS Advisory Board Meeting, Paris

8. SALUS ICSR reporting toolSecondary use of EHR data to support the ADE reporting process SALUS Advisory Board Meeting, Paris

9. Background • Starting point: • Post-market drug surveillance based on “spontaneous reports” of suspected adverse drug events (ADE) to the regulatory bodies by healthcare professionals (ICSR = Individual Case Safety Reports) • Only around 1 to 5% of ADEs reported: underreportingphenomenon(Cullen et al. 1995, Bates et al. 2003, Hazell & Shakir 2006) • Potential causes: • Identifying ADE isdifficult • HPsnot sufficiently aware of the importance of ADE reporting • Reporting procedure too costly in time, too many data are requested • Possible solution: reusing EHRof the patientto ease the ADE reportingprocess • Although not reported, ADE frequently described in EHR (Linder et al. 2010) • Some of the data needed to complete ADE forms (demographics, pastdrughistory, etc.) available in EHR SALUS Advisory Board Meeting, Paris

10. SALUS europeanproject • Objective: build a tool facilitating the ADE reporting process and reducing time necessary to fill ICSR: • enabling automatic pre-population of ICSR using patient data available in EHR • providing assistance for completing manually the data that couldn’t be automatically prefilled • and for transmitting the ICSR to regulatory authorities • Challenge • Current EHR systems use heterogeneous information model and different terminologies • ADE must be reported using • E2B data model – WHO standard supported by European Medicines Agency (EMA) in Europe and Food and Drug Administration (FDA) in US • or local data models (e.g. AIFA forms in Italy, Cerfa forms in France) • Needtechnical and semantic interoperability between EHR and ICSR data models and terminologies to enable automatic prepopulation of reporting forms. SALUS Advisory Board Meeting, Paris

11. SALUS interoperabilityplatform • Enables converting the EHR information model (e.g. HL7 CDA templates) to the data model requested by ADE reporting form (E2B). • Includes mappings between: • standard EHR information model and E2B information model; • terminologies used to encode data in EHR and E2B forms (MedDRA, CIM, LOINC, SNOMED-CT, etc.) SALUS Advisory Board Meeting, Paris

12. The E2B(R2) data model and protocol to report ADE • E2B is • a data modeldescribingwhatinformation in what format shouldbeprovidedwhenreporting an ADE; • a protocoldescribinghow the report shouldbetransmittedelectronically to regulatoryauthorities. • Huge data model (235 fields) • but only a few are mandatory • others are optional and depend on • the nature of the case reported (e.g. isit a mother-fœtus ADE?) • the decision of the reporter: free to provide or not providesome data.

13. The E2B(R2) data model and protocol to report ADE • For each E2B data item potentiallyprepopulable (i.e. for which relevant data couldbeavailable in the EHR), a mapping has been definedwithstandard EHR data models : • CDA templates • EN 13606 archetypes (ERS) • E2B data items have also been mappedwithSALUS Common Data Elements, which are used as a bridge between data models in SALUS coreontology. • Suchmappingsenablesautomatic prepopulation of part of the E2B-compliant ADE reportingformusing patient data stored in the EHR.

14. Extracting data describing ADE from a CDA based EHR Description of the reaction Description of the substancecausing the reaction Clinicalstatus of the concern (resolved, in remission, active...) SALUS Advisory Board Meeting, Paris

15. Extracting data describing ADE from a CDA based EHR CDA section describing the reaction • code for the allergy or adverse reactionbeingobserved • using a givencoding system SALUS Advisory Board Meeting, Paris

16. Extracting data describing ADE from a CDA based EHR CDA section describing the reaction • Problem: ADE needs to becodedwithMedDRA in E2B report • If codeSystemused in CDA document isdifferentfrom MedDRA (e.g. Snomed-CT), a conversion must be made. SALUS Advisory Board Meeting, Paris

17. Extracting data describing demographics from a CDA based EHR LOINC code for « BODY WEIGHT (MEASURED) » SALUS Advisory Board Meeting, Paris

18. Extracting data describing demographics from a CDA based EHR Value and unit for the weightmeasured e.g.value="52" unit="kg" SALUS Advisory Board Meeting, Paris

19. Extracting data describing demographics from a CDA based EHR • “Patient Weight” must be specified in kg in E2B • If weight unit is different than "kg" in CDA (e.g. pounds in UK), a conversion must be made SALUS Advisory Board Meeting, Paris

20. Graphical User Interfaces • ADE form filling GUI • To complete manually prepopulated ADE reporting forms and send them to the regulatory authorities. • One single windowwithdynamicmechanisms and tab systems (vs step-by-step). • Only E2B (or AIFA) mandatory data are requested. • Onlyrequested and most relevant fields are displayed on the screen – and only the onesthat are contextually relevant. • Dynamic system of conditionnalopening of section windows. • Back-office GUI used to enter non case-specific and permanent data. SALUS Advisory Board Meeting, Paris

21. Graphical User Interfaces • ADE report manager GUI • Used to access and manage (a) already completed and previously sent ADE reports and (b) waiting to be completed ADE reports. SALUS Advisory Board Meeting, Paris

22. Some challenges for successful implementation • Only some EHR data available in a structured format, other being only available in free text. • Sometimes not usable for prepopulation. • Onlypartial mappingsbetween EHR information models (or value sets) and E2B data elements. • Difficulties to map terminologies usedin EHR (LOINC, ICD10, SNOMED-CT, etc.) with MedDRA (used in E2B): • Different granularity levels • Terminologies are evolving • Automatic mappings used in prepopulation will probably need to be checked by the user SALUS Advisory Board Meeting, Paris

23. Some challenges for successful implementation • Access to EHR data poses some ethico-legal difficulties. • ADE forms needs to be de-identified before being sent to regulatory authorities. • Sometimes no possibility to export patient data (except if aggregated) beyond the care zone (e.g. hospitals’ servers). • We have made the choice to use E2B(R2), but E2B(R3) iscurrently in progress. • If E2B(R3) comes to beused, for future implementation of SALUS platform, an update willbenecessary. SALUS Advisory Board Meeting, Paris

24. Thankyou for your attention « It’sbetter not to disturbdrugregulatoryauthorities for such a ridiculousreaction!» Bates, D.W., Evans, R.S., Murff, H., Stetson, P.D., Pizziferri, L., Hripcsak, G.: Detecting adverse events using information technology. Journal of the American Medical Informatics Association 10(2), 115-128 (2003) Cullen, D.J., Bates, D.W., Small, S.D., Cooper, J.B., Nemeskal, A.R., Leape, L.L.: The incident reporting system does not detect adverse drug events: a problem for quality improvement. Jt. Comm. J. Qual. Improv. 21, 541-548 (1995) Linder, J. A., Haas, J. S., Iyer, A., Labuzetta, M. A., Ibara, M., Celeste, M., Getty, G., Bates, D. W.: Secondary use of electronic health record data: spontaneous triggered adverse drug event reporting. Pharmacoepidemiol Drug Saf. 19(12), 1211-5 (2010) Hazell & Shakir (2006). Under-Reporting of Adverse Drug Reactions: A Systematic Review. Drug Safety, 29(5), 385-396. SALUS Advisory Board Meeting, Paris