SALUS ADE Detection and ICSR Reporting Tools

Download Report

Transcript SALUS ADE Detection and ICSR Reporting Tools

Supporting ADE Detection
and Reporting
using EHR data
SALUS Advisory Board Meeting, Paris (January 17, 2013) –
Gunnar Declerck (INSERM), Tobias Krahn (OFFIS)
ADE Notification process (1/2)

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
January 17, 2013
SALUS Advisory Board Meeting, Paris
2
ADE Notification process (2/2)
January 17, 2013
SALUS Advisory Board Meeting, Paris
3
Current status



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
January 17, 2013
SALUS Advisory Board Meeting, Paris
4
ADE Detection Rules

Different types of ADE detection rules

Rules based on laboratory parameters

3 concepts:

1. muscle-, liver- and kidney-parameters, e.g.



2. bone marrow-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
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.


January 17, 2013
natrium, normal range: 134-145 mmol/l
ADE Detection Rule: At least 20% change of normal value after drug
prescription
SALUS Advisory Board Meeting, Paris
5
ADE Detection Rules

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:
January 17, 2013
SALUS Advisory Board Meeting, Paris
6
ADE Notification – specific questions to AB

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
January 17, 2013
SALUS Advisory Board Meeting, Paris
7
SALUS ICSR reporting tool
Secondary use of EHR data to support the
ADE reporting process
January 17, 2013
SALUS Advisory Board Meeting, Paris
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
January 17, 2013
SALUS Advisory Board Meeting, Paris
9
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.
January 17, 2013
SALUS Advisory Board Meeting, Paris
10
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.)
January 17, 2013
SALUS Advisory Board Meeting, Paris
11
The E2B(R2) data model and protocol to
report ADE
 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.
January 17, 2013
Extracting data describing ADE from a
CDA based EHR
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>
Description of the
reaction
Description of the substance
causing the reaction
Clinical status of the concern
(resolved, in remission, active...)
<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>
January 17, 2013
SALUS Advisory Board Meeting, Paris
14
Extracting data describing ADE from a
CDA based EHR
CDA section describing the reaction
<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=' '/>
 code for the allergy or adverse reaction
being observed
 using a given coding system
January 17, 2013
SALUS Advisory Board Meeting, Paris
15
Extracting data describing ADE from a
CDA based EHR
CDA section describing the reaction
<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.
January 17, 2013
SALUS Advisory Board Meeting, Paris
16
Extracting data describing demographics
from a CDA based EHR
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) »
January 17, 2013
SALUS Advisory Board Meeting, Paris
17
Extracting data describing demographics
from a CDA based EHR
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>
Value and unit for the weight measured
e.g. value="52" unit="kg"
January 17, 2013
SALUS Advisory Board Meeting, Paris
18
Extracting data describing demographics
from a CDA based EHR
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>
“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
January 17, 2013
SALUS Advisory Board Meeting, Paris
19
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.
January 17, 2013
SALUS Advisory Board Meeting, Paris
20
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.
January 17, 2013
SALUS Advisory Board Meeting, Paris
21
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.
 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
January 17, 2013
SALUS Advisory Board Meeting, Paris
22
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) is currently in
progress.
 If E2B(R3) comes to be used, for future implementation of SALUS
platform, an update will be necessary.
January 17, 2013
SALUS Advisory Board Meeting, Paris
23
Thank you for your attention
« It’s better not to disturb drug
regulatory authorities for such
a ridiculous reaction!»
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.
January 17, 2013
SALUS Advisory Board Meeting, Paris
24