Supporting ADE Detection and Reporting using EHR data SALUS Advisory Board Meeting, Paris (January...

Supporting ADE Detection and Reporting

using EHR data

SALUS Advisory Board Meeting, Paris (January 17, 2013) – Gunnar Declerck (INSERM), Tobias Krahn (OFFIS)

SALUS Advisory Board Meeting, Paris 2

ADE Notification process (1/2)

January 17, 2013

Two main objectives regarding ADE detection 1. Notification of suspected, already known ADEs 2. Notification of suspected, unknown ADEs

ADE detection process If new data is relevant for ADE detection…

The EHR is checked for known ADEs Via Databases and ADE detection rules

If no known pattern is found Data Mining process to discover new patterns


ADE Notification process (2/2)

January 17, 2013


Current status

January 17, 2013

Access to databases containing information about ADEs have been requested

First version of ADE detection rules is ready Data Mining approach to detect suspected

ADEs is currently in development First draft will be shared by the end of January

2013


ADE Detection Rules

January 17, 2013

Different types of ADE detection rules Rules based on laboratory parameters

3 concepts: 1. muscle-, liver- and kidney-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 after

drug prescription


ADE Detection Rules

January 17, 2013

Rules based on the prescription of specific antidotes 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:


ADE Notification – specific questions to AB

January 17, 2013

Alternative databases containing information about known ADEs that could be useable

Other detection rules or sources for existing ADE detection rules

Other ADE detection approaches that could be taken into consideration

SALUS ICSR reporting tool

Secondary use of EHR data to support the ADE reporting process

January 17, 2013 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: underreporting phenomenon (Cullen et al. 1995, Bates et al. 2003, Hazell & Shakir 2006)

Potential causes: Identifying ADE is difficult HPs not sufficiently aware of the importance of ADE reporting Reporting procedure too costly in time, too many data are requested

Possible solution: reusing EHR of the patient to ease the ADE reporting process

Although not reported, ADE frequently described in EHR (Linder et al. 2010)

Some of the data needed to complete ADE forms (demographics, past drug history, etc.) available in EHR


10

SALUS european project Objective: build a tool facilitating the ADE reporting process and reducing time necessary to fill ICSR:

(1) enabling automatic pre-population of ICSR using patient data available in EHR

(2) providing assistance for completing manually the data that couldn’t be automatically prefilled

(3) and for transmitting the ICSR to regulatory authorities

Challenge Current EHR systems use heterogeneous information model and different

terminologies ADE must be reported using

o E2B data model – WHO standard supported by European Medicines Agency (EMA) in Europe and Food and Drug Administration (FDA) in US

o or local data models (e.g. AIFA forms in Italy, Cerfa forms in France)

Þ Need technical and semantic interoperability between EHR and ICSR data models and terminologies to enable automatic prepopulation of reporting forms.


11

SALUS interoperability platform Enables converting the EHR information model (e.g. HL7 CDA templates) to the data model requested by ADE reporting form (E2B).

Includes mappings between:a) standard EHR information model and E2B information model; b) terminologies used to encode data in EHR and E2B forms

(MedDRA, CIM, LOINC, SNOMED-CT, etc.)


The E2B(R2) data model and protocol to report ADE

January 17, 2013

E2B is (1) a data model describing what

information in what format should be provided when reporting an ADE;

(2) a protocol describing how the report should be transmitted electronically to regulatory authorities.

Huge data model (235 fields) but only a few are mandatory others are optional and depend on

(a) the nature of the case reported (e.g. is it a mother-fœtus ADE?)

(b) the decision of the reporter: free to provide or not provide some data.

January 17, 2013

The E2B(R2) data model and protocol to report ADE

For each E2B data item potentially prepopulable (i.e. for which relevant data could be available in the EHR), a mapping has been defined with standard EHR data models : CDA templates EN 13606 archetypes (ERS)

E2B data items have also been mapped with SALUS Common Data Elements, which are used as a bridge between data models in SALUS core ontology.

Such mappings enables automatic prepopulation of part of the E2B-compliant ADE reporting form using patient data stored in the EHR.

14

Allergies and Intolerances entryRelationship CDA section <entryRelationship typeCode='SUBJ'> <observation classCode='OBS' moodCode='EVN'/> […] <code code='ALG|OINT|DALG|EALG|FALG|DINT|EINT|FINT|DNAINT|ENAINT|FNAINT' codeSystem='2.16.840.1.113883.5.4' codeSystemName='ObservationIntoleranceType'/> <text><reference value='XXX'/></text> <value xsi:type='CD' code='XXX' codeSystem='XXX' displayName=' ' codeSystemName=' '/>

<participant typeCode='CSM'> <participantRole classCode='MANU'> <playingEntity classCode='MMAT'> <code code='XXX' codeSystem='XXX'> <originalText><reference value='XXX'/></orginalText> </code> <name></name> </playingEntity> </participantRole> </participant>

<entryRelationship typeCode='REFR' inversionInd='false'> <observation classCode='OBS' moodCode='EVN'> <templateId root='2.16.840.1.113883.10.20.1.57'/> <templateId root='2.16.840.1.113883.10.20.1.50'/> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.1.1'/> <code code='33999-4' displayName='Status' codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC' /> <text><reference value=' '/></text> <statusCode code='completed'/> <value xsi:type='CE' code='XXX' codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMEDCT'/> </observation> </entryRelationship> </observation> </entryRelationship>

Description of the reaction

Description of the substance causing the reaction

Clinical status of the concern (resolved, in remission, active...)

Extracting data describing ADE from a CDA based EHR


16

<code code='ALG|OINT|DALG|EALG|FALG|DINT|EINT|FINT|DNAINT|ENAINT|FNAINT' codeSystem='2.16.840.1.113883.5.4' codeSystemName='ObservationIntoleranceType'/>

<text><reference value='XXX'/></text>

<value xsi:type='CD' code='XXX' codeSystem='XXX' displayName=' ' codeSystemName=' '/>

Problem: ADE needs to be coded with MedDRA in E2B report

Þ If codeSystem used in CDA document is different from MedDRA (e.g. Snomed-CT), a conversion must be made.


Extracting data describing ADE from a CDA based EHRCDA section describing the reaction

17

Vital Signs CDA Section <code code='46680005' displayName='Vital signs' codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED CT'/>

<component typeCode='COMP'> <observation classCode='OBS' moodCode='EVN'> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.13'/> <templateId root='2.16.840.1.113883.10.20.1.31'/> <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.13.2'/> <code code=' 3141-9' codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/> <value xsi:type='PQ' value='XXX' unit='XXX'/> </observation> </component>

LOINC code for « BODY WEIGHT (MEASURED) »


Extracting data describing demographics from a CDA based EHR

18



Value and unit for the weight measurede.g. value="52" unit="kg"



19



“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



20

Graphical User Interfaces ADE form filling GUI To complete manually prepopulated ADE reporting forms and send them to the regulatory authorities.

One single window with dynamic mechanisms and tab systems (vs step-by-step). Only E2B (or AIFA) mandatory data are requested. Only requested and most relevant fields are displayed on the screen – and only the ones that are contextually relevant. Dynamic system of conditionnal opening of section windows. Back-office GUI used to enter non case-specific and permanent data.


21

ADE report manager GUIUsed to access and manage (a) already completed and previously sent ADE reports and (b) waiting to be completed ADE reports.

Graphical User Interfaces


22

Only some EHR data available in a structured format, other being only available in free text.Þ Sometimes not usable for prepopulation.

Only partial mappings between EHR information models (or value sets) and E2B data elements.

Difficulties to map terminologies used in 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

Some challenges for successful implementation


23

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) is currently in progress.

Þ If E2B(R3) comes to be used, for future implementation of SALUS platform, an update will be necessary.


Some challenges for successful implementation

24

Thank you for your attention

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.

« It’s better not to disturb drug regulatory authorities for such a ridiculous reaction!»


Supporting ADE Detection and Reporting using EHR data SALUS Advisory Board Meeting, Paris (January...

Documents

Transcript of Supporting ADE Detection and Reporting using EHR data SALUS Advisory Board Meeting, Paris (January...