Download Electronic Yellow Card Reporting Integration into GP Systems

Director
Owner
Author
Alison Davis
June Raine
Mick Foy
Paul Barrow
Status
Version
Version Date
Draft
0.3
22/08/11
Electronic Yellow Card Reporting Integration into
GP Systems
General contact:
Subject Matter contact:
Mick Foy
Medicines and Healthcare products
Regulatory Agency (MHRA)
Paul Barrow
Medicines and Healthcare products
Regulatory Agency (MHRA)
Tel: 020 3080 6633
[email protected]
Tel: 020 3080 6655
[email protected]
Yellow Card reporting in GP Systems
Page 1 of 22
Commercial in Confidence
Amendment History
Version
0.1
0.2
0.3
Change Summary
First Draft
Updated draft
Updated draft
Date
05/07/2011
07/07/2011
22/08/2011
Change author
Paul Barrow
Paul Barrow
Paul Barrow
Reviewers:
This document must be reviewed by the following (delegated as necessary).
Name
Title / Responsibility
Date
Version
Approvals:
This document requires the following approvals:
Name
Signature
Title / Responsibility
Date
Version
Date
Version
Distribution:
Reviewers and approvers plus:
Name
Title / Responsibility
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 2 of 22
Commercial in Confidence
Acronyms
Acronym
ADR
CHM
CQC
dm+d
DTD
E2B(R2)
EC
EMA
FOIA
GP
ICH
ICSR
NHS
NPSA
MHRA
SNOMED CT
XML
Term
Adverse Drug Reaction
Commission on Human Medicines
Care Quality Commission
Dictionary of Medicines and Devices
Document Type Definition
(Not an acronym) International messaging standard for
adverse drug reactions
European Commission
European Medicines Agency
Freedom of Information Act
General Practitioner
International Conference on Harmonisation of Technical
Requirements for Registration of Pharmaceuticals for Human
Use
Individual Case Safety Report
National Health Service
National Patient Safety Agency
Medicines and Healthcare products Regulatory Agency
Systematized Nomenclature of Medicine Clinical Terms
eXtensible Mark-up Language
Executive summary
The Medicines and Healthcare products Regulatory Agency (MHRA) is the
agency responsible for ensuring the safety of medicines, and runs the Yellow
Card Scheme which receives reports of suspected adverse drug reactions. A
new requirement to improve reporting rates is for GP systems to include a
Yellow Card reporting function enabling users to report of suspected adverse
drug reactions identified in primary electronically. This is to address a
reducing contribution of Yellow Cards received from GP reporters. Increased
numbers of Yellow Cards received ultimately increases the data available for
identification of possible drug safety issues, and so allows the MHRA to take
prompt action to project public health.
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 3 of 22
Commercial in Confidence
Contents
1.
INTRODUCTION ...................................................................................... 5
1.1
1.2
1.3
1.4
2.
Purpose ............................................................................................. 5
Audience............................................................................................ 5
Scope ................................................................................................ 5
Definitions .......................................................................................... 5
BACKGROUND ....................................................................................... 6
2.1
About the MHRA ................................................................................ 6
2.2
Yellow Card Scheme and reporting of Adverse Drug Reactions ....... 6
2.3
Using Yellow Card data ..................................................................... 7
2.4
Adverse Drug Reaction reporting requirements ................................. 8
2.5
Under-reporting of Adverse Drug Reactions and Strengthening the
Yellow Card Scheme .................................................................................... 8
2.6
Developments in electronic Yellow Card reporting ............................ 9
3.
BENEFITS .............................................................................................. 10
4.
REQUIREMENTS ................................................................................... 11
4.1
Overview.......................................................................................... 11
4.2
Message format ............................................................................... 11
4.2.1 Medical terminologies .................................................................. 11
4.2.2 Medicines terminologies............................................................... 11
4.2.3 Parsing and Validation ................................................................. 11
4.3
Workflow .......................................................................................... 12
4.4
Audit Requirements ......................................................................... 13
4.5
Frequency of transmission............................................................... 14
4.6
Data items to be returned ................................................................ 14
4.6.1 Patient data .................................................................................. 14
4.6.2 Reporter data ............................................................................... 15
4.6.3 Drug/vaccine data ........................................................................ 15
4.6.4 Reaction data ............................................................................... 16
4.7
Yellow Card Webservice and Webservice security .......................... 16
4.8
Testing ............................................................................................. 17
APPENDICES................................................................................................ 19
4.9
Impact of the Yellow Card Scheme ................................................. 19
4.10 Yellow Card Data Privacy ................................................................ 21
4.10.1 Data provision .......................................................................... 21
4.10.2 Access to Yellow Card data within the MHRA .......................... 22
4.10.3 Potential for cross-linkage of Yellow Card data ........................ 22
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 4 of 22
Commercial in Confidence
1.
Introduction
This Document specifies the requirements for electronic Yellow Card reporting
of suspected adverse drug reactions (ADRs) from GP systems to the
Medicines and Healthcare products Regulatory Agency (MHRA).
1.1 Purpose
Individual suppliers of GP systems have been encouraged to develop
electronic Yellow Card reporting functionality in order to help improve access
to Yellow Card reporting in primary care. Improving access to reporting is one
route currently pursued to strengthen reporting to the Yellow Card Scheme,
and hence to help the MHRA better protect public health.
The improvement in numbers of reports received from primary care resulting
from introduction of such a system has been demonstrated. There is a need
for Yellow Card reporting to be included in the GP System of Choice
requirements to a consistent implementation across multiple GP systems.
1.2 Audience
The audience for this document is primarily system architects, system
developers and other supplier staff involved with the design, build and test of
GP systems.
1.3 Scope
The scope of this document covers workflow, data and message format
requirements required to enable Yellow Card reporting of suspected adverse
drug reactions from GP systems.
1.4 Definitions
Where used in this document set, the keywords MUST, SHOULD and MAY
are to be interpreted as follows:
MUST: This word, or the terms "REQUIRED" or "SHALL", means
that the definition is an absolute requirement of the specification.
SHOULD: This word, or the adjective "RECOMMENDED", means
that there may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications MUST be
understood and carefully weighed before choosing a different
course.
MAY: This word, or the adjective “OPTIONAL”, means that an item
is truly optional. One implementer may choose to include the item
because a particular implementation requires it or because the
implementer feels that it enhances the implementation while another
implementer may omit the same item. An implementation which
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 5 of 22
Commercial in Confidence
does not include a particular option MUST be prepared to
interoperate with another implementation which does include the
option, though perhaps with reduced functionality. In the same vein
an implementation which does include a particular option MUST be
prepared to interoperate with another implementation which does not
include the option (except, of course, for the feature the option
provides).
2.
Background
2.1 About the MHRA
The Medicines and Healthcare products Regulatory Agency (MHRA) –
www.mhra.gov.uk – is an executive agency of the Department of Health. Its
role is to „enhance and safeguard the health of the public by ensuring that
medicines and medical devices work and are acceptably safe‟.
The MHRA has the following aims:
Protecting public health through regulation, with acceptable benefit-risk
profiles for medicines and devices.
Promoting public health by helping people who use these products to
understand their risks and benefits.
Improving public health by encouraging and facilitating developments
in products that will benefit people
The agency therefore has a regulatory and licensing role for both medicines
and medical devices; it issues advice and guidance and monitors suspected
adverse drug reactions and adverse incidents involving medical devices.
2.2 Yellow Card Scheme and reporting of Adverse
Drug Reactions
Before a medicine is granted a licence so that it can be made available in the
United Kingdom, it must pass strict tests and checks to ensure that it is
acceptably safe and effective. All effective medicines, however, can cause
side effects (also known as adverse drug reactions), which can range from
being minor to being very serious. For a medicine to be granted a licence, the
expected benefits of the medicine must outweigh the possible risks of the
medicine causing adverse effects in patients. Sometimes it is difficult to tell
whether a suspected adverse drug reaction is due to a medicine or another
underlying reason. Even if it is only a suspicion that a medicine or
combination of medicines has caused a side effect, the MHRA asks patients
and health professionals to report this on a Yellow Card.
The MHRA (and its predecessor organisations) have collected reports of
suspected adverse drug reactions through the Yellow Card scheme for over
40 years. Since the establishment of the Yellow Card scheme in 1964 over
600,000 UK reports have been collected. Currently approximately 25,000
Yellow Card reports are received each year, with about half of these being
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 6 of 22
Commercial in Confidence
from the pharmaceutical industry, and the remainder from health
professionals and patients.
The Yellow Card Scheme meets data protection requirements for collecting
and storing confidential patient information, as well as having appropriate
access controls in place.
2.3 Using Yellow Card data
Information gathered from Yellow Card reports made by patients and health
professionals is continually assessed at the MHRA by a team experts made
up of doctors, pharmacists and scientists who study the benefits and risks of
medicines. Yellow Card reports on suspected side effects received by MHRA
are evaluated, together with additional sources of information such as clinical
trial data, medical literature or data from international medicines regulators, to
identify previously unidentified safety issues or side effects. If a new side
effect is identified, information is carefully considered in the context of the
overall side effect profile for the medicine, and how the side effect profile
compares with other medicines used to treat the same condition. The MHRA
takes action, whenever necessary, to ensure that medicines are used in a
way that minimises risk, while maximising patient benefit.
Where an issue is identified the agency can take a range of regulatory actions
to protect public health. This most commonly involves changes to the product
information (the patient information leaflet, or summary of product
characteristics); although in extreme cases a medicine can be withdrawn
where risks are considered to outweigh the benefits.
In assessing the safety of medicines, the MHRA is advised by the
Commission on Human Medicines (CHM), which is the Government‟s
independent scientific advisory body on medicines safety. The CHM is made
up of experts from a range of health professionals and includes lay
representatives.
Spontaneous adverse reaction reporting schemes, such as the Yellow Card
Scheme is common source for identification of drug safety signals, and often
provides and early warning of possible hazards. The value of the scheme has
been demonstrated many times and it has helped to identify numerous
important safety issues. For example, warnings were added to the product
information for the smoking-cessation drug varenicline after we received
Yellow Cards reporting patients experiencing suicidal thoughts. Advice was
issued that patients taking varenicline who develop suicidal thoughts or who
develop agitation, depressed mood, or changes in behaviour that are of
concern for the doctor, patient, family, or caregiver should stop their treatment
and contact their doctor immediately. Further examples are provided in
Appendix 4.9.
The MHRA publishes cumulative and anonymised summary information on
adverse drug reactions collected from the Yellow Card Scheme. Anonymised
data is also shared with the European Medicines Agency – the European
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 7 of 22
Commercial in Confidence
regulatory agency, and with the pharmaceutical industry under the MHRA‟s
legal obligations.
2.4 Adverse Drug Reaction reporting requirements
Health professionals and patients submit Yellow Card reports on a voluntary
basis, whereas there is a regulatory requirement on the MHRA to collect them
and disseminate the information in an anonymised form to other regulators
and the pharmaceutical industry.
Article 106 of Directive 2001/83/EC specifically requires the European
Commission in consultation with the European Medicines Agency (EMA – “the
Agency”), Member States and interested parties to draw up guidance on the
collection, verification and presentation of adverse reaction reports in order to
facilitate the exchange of information about human pharmacovigilance within
the Community. Similarly, Article 26 of Regulation (EC) No 726/2004 includes
a requirement for the Commission, in consultation with the Agency, Member
States and interested parties to draw up a guide. This guidance document is
„Volume 9A (Human Pharmacovigilance)1‟
New pharmacovigilance legislation, due to be implemented by July 2012,
states that national medicines agencies such as the MHRA should work to
strengthen spontaneous adverse drug reaction reporting systems:
“Article 102 The Member States shall: (1) take all appropriate
measures to encourage patients, doctors, pharmacists and other
health-care professionals to report suspected adverse reactions to the
national competent authority…”
The Care Quality Commission criteria for assessing core standards in primary
care (2009-2010)2 include a requirement for reporting – in the first domain:
safety, element one states:
“Incidents are reported locally and nationally via the appropriate
reporting route/s to the National Patient Safety Agency (NPSA), Health
and Safety Executive, Medicines and Healthcare products Regulatory
Agency (MHRA)…”
The Yellow Card Scheme is therefore vital in helping the MHRA monitor the
safety of medicines and vaccines used in the UK.
2.5 Under-reporting of Adverse Drug Reactions and
Strengthening the Yellow Card Scheme
The scheme does not provide comprehensive coverage of adverse drug
reactions – many studies have investigated this and it is estimated that less
1
2
http://ec.europa.eu/health/documents/eudralex/vol-9/index_en.htm
Accessed at http://www.cqc.org.uk/publications.cfm?fde_id=12757 on 23/06/2011
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 8 of 22
Commercial in Confidence
than 10% of adverse drug events are recorded through the scheme.
Additionally there is evidence that the number of reports from general practice
is falling, perhaps because of GP workload issues. A recent analysis of
Yellow Card data showed that for the first time since the establishment of the
Yellow Card Scheme, in 2010 GPs were no longer the largest reporter group.
The Yellow Card strategy aims to strengthen reporting of suspected adverse
drug reactions to the Yellow Card Scheme. To achieve this, activities to
increase both the number and quality of Yellow Cards received from healthprofessionals, patients, parents and carers are required. Increased numbers
of promptly received and well-completed Yellow Cards received ultimately
makes more data available to the MHRA for the identification of possible drug
safety issues.
The ranges of activities aim to address the four main elements outlined in the
original strategy. These are also listed in the Heads of European Medicines
Agencies strategy document from 20103:
Facilitation - making reporting easy and accessible
Education - raise understanding of the purpose and value of the
scheme
Motivation - making reporters more likely to report
Promotion - developing and maintaining promotion and communication
strategies for the scheme
2.6 Developments in electronic Yellow Card reporting
Amongst a range of activities to improve reporting, one of the most significant
efforts under „facilitation‟, is in the development of methods for health
professionals to report ADRs electronically through healthcare information
systems. Much of the information required for a Yellow Card is held within a
clinical system such as patient information, medical history and drugs. These
data could therefore quickly be populated onto an electronic Yellow Card at
the touch of a button reducing effort for the reporter. It is anticipated that
making reporting as simple and quick as possible will help increase the
number of Yellow Cards received.
In 2010, the MHRA developed a system for receiving electronic Yellow Cards
in an electronic format through a web-service. Electronic Yellow Cards
created using the ICH E2B(R2) international standard format within a clinical
system can be securely transmitted to the MHRA through the web-service.
The data can also be promptly populated automatically into the MHRA
pharmacovigilance database reducing the need for manual data entry.
Currently two systems are transmitting Yellow Cards electronically to the
MHRA using this system. SystmOne, developed by The Phoenix Partnership
is used in approximately 15% of GP practices across the UK. This was the
3
A Strategy for the Heads of Medicines Agencies, 2011-15. Accessed at
http://www.hma.eu/fileadmin/dateien/HMA_joint/HMA_Strategy_Paper_II/HMA_Strategy_final_version_
_2_.pdf on 28 April 2011.
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 9 of 22
Commercial in Confidence
first system to include an electronic Yellow Card reporting feature and over
1000 Yellow Cards have been received since late November 2010. Testing of
electronic reporting with MiDatabank, a medicines information hospital based
database, has also been completed. Work continues on nationwide
implementation of the software.
Discussions on introducing similar electronic Yellow Card reporting methods
into other clinical systems used by health professionals and discussions with
other systems suppliers are continuing.
3.
Benefits
GPs have historically been the largest contributor of Yellow Cards but the
proportion they contribute has been reducing and it is of concern that a recent
trends analysis showed that in 2010 nurses contributed more than GPs. It is
anticipated that introducing electronic Yellow Card reporting into GP systems
will significantly improve reporting from GPs; introducing this function makes
reporting significantly easier and quicker for this key reporter group.
Defining Yellow Card reporting within the GP System of choice requirements
will allow us to ensure MHRA requirements are met including that data
provided meets validation requirements through involvement in data provision
requirements. Experience of developing Yellow Card reporting with
SystmOne, where this was completed at no cost to the MHRA, meant MHRA
input into development was limited and scope for further even minor changes
are extremely limited. This will:
Improve ease of access to reporting - known to be a major factor
leading in under-reporting. Underreporting is estimated at 10% means
the significant majority of ADRs are not reported.
Improve ease of Yellow Card completion –automatic population of
information directly from the system.
Improve ease of transmission of data – transmitted quickly and
securely via an electronic link prevents need for posting paper forms
and enables prompt electronic acknowledgment of receipt.
Lead to development of electronic Yellow Card reporting in greater
numbers of GP systems.
Improve consistency of adverse drug reaction data provision in
electronic Yellow Cards.
Have the potential to improve completeness of data provided on Yellow
Cards (e.g. including patient medical history, drug indications).
Receipt of greater numbers of Yellow Cards allows earlier detection of
drug safety issues, therefore enabling the MHRA to take more prompt
action to protect public health.
Improved data quality may mean fewer Yellow Cards are required to
provide enough evidence for the MHRA take action to protect public
health, and also can reduce false positive or false negative drug safety
issues detected.
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 10 of 22
Commercial in Confidence
4.
Requirements
4.1 Overview
The requirement is for GP systems to provide a function by which an
electronic Yellow Card can be populated and transmitted to the MHRA. A
user of a GP system must be able to request that a Yellow Card is created
when they suspect an adverse drug reaction has occurred. The Yellow Card
created must have the majority of information automatically populated from
within the GP system/patient record. A number of additional fields may
require the user to specify information, for example selecting a reaction
term(s) and entering an optional free text description. The system should also
provide a prompt to the user as to when it might be appropriate to complete a
Yellow Card – for example when a medication is being stopped or sensitivity
to a drug recorded. Once completed the Yellow Card would then be
transmitted to the MHRA using the secure web-service.
4.2 Message format
Yellow Card must be created as an ICH E2B(R2) Individual Case Safety
Report format xml file. Please see the ExampleICSR.xml file for example
content.
Field definitions for the ICSR xml can be found in the spreadsheet
E2BX_CfH.xls and E2B_ICSR.dtd provides the document type definition
(DTD).
4.2.1 Medical terminologies
Medical terms, including suspected reactions, patient history, and medicine
indications should be coded using SNOMED CT term IDs or term names.
READ terms should be mapped to SNOMED CT.
Comment [b1]: Yet to be
decided/discussed with DS&P
4.2.2 Medicines terminologies
GP systems are recognised as using the Dictionary of Medicines and Devices
(dm+d) for coding medicines. Medicines should be reported using the most
detailed level term from dm+d available i.e. Actual Medicinal Product (AMP)
names. If AMP is not available, then Virtual Medicinal Product is preferable,
followed by Virtual Therapeutic Moiety. Field length restrictions of 70 or 100
alphanumeric characters defined in the field definitions spreadsheet should be
complied with.
4.2.3 Parsing and Validation
All Yellow Cards transmitted as an xml file to the Yellow Card webservice
must parse against the DTD in order to be accepted.
Data provided in the xml is also compared against a number of „common
sense‟ validation rules to ensure a Yellow Card is a valid report. The MHRA
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 11 of 22
Comment [b2]: We will not reject
values exceeding this, but it is most
helpful it entries met this limit. We are
investigating whether we will be able to
receive dm+d term ids as an alternative
Commercial in Confidence
reserve the right to reject YCs which do not meet these requirements. A list of
validations is included in the field definition spreadsheet.
Req ID
CR101
CR102
CR103
CR104
CR105
Requirement Text
The system MUST create an electronic Yellow Cards
using the ICH E2B(R2) xml format
Medical terms MUST be populated using SNOMED
term IDs
Medicines MUST be populated using DM+D entries,
using the most detailed term level available
(AMP>VMP>VTM) and observing field length
restrictions (of either 70 or 100 alphanumeric
characters depending on whether the
<medicinalproduct> or <activesubstance> field is
populated)
Yellow Cards transmitted as an xml file to the Yellow
Card webservice MUST parse against the DTD
Data field values MUST meet data validation
requirements
Status
Must
Must
Must
Comment [b3]: See above
Must
Must
4.3 Workflow
A typical workflow for creation and transmission of an electronic Yellow Card
is as follows:
1. A user records a drug side-effect or sensitivity in a patient record upon
which dialog is displayed, asking if they want to submit a Yellow Card
OR
2. A user manually requests a Yellow Card to be created for a patient
3. If the user wants to submit a Yellow Card, a further dialog or dialogs
are shown to capture the Yellow Card details which cannot be derived
automatically from the patient record
4. The user completes dialog(s)
5. The clinical system then creates an XML document from the fields on
the dialog and the patient record
6. The XML is then transmitted to the MHRA via the webservice
7. The clinical system then detects the web-service response code and
can tell the user whether the Yellow Card submission was successful
or failed as appropriate.
8. If successful, the XML sent is added to the patient record to form part
of an audit trail.
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 12 of 22
Commercial in Confidence
Figure 1 - Workflow for creation and transmission of an electronic Yellow Card
Start
Manual request
to create
Yellow Card
MHRA
webservice
loads XML
Drug stopped on
patient record
Dialog displayed
to user
Parse ok?
Yes
Create
No End
Yellow Card?
Validate ok?
Yes
Dialog displayed
for entry
of additional data
Send to
administrator
No
Yes
Load code
received
Load code
received
+ warnings
Transmission
confirmed to
system user
Transmission
confirmed to
system user
XML added
to patient record
for audit trail
XML added
to patient record
for audit trail
XML created
from dialog fields
and patient record
XML transmitted
to the MHRA
via webservice
Fail code
received
No
User advised to
report online
at eYC
End
NB If an xml fails validations a user will receive a positive acknowledgment
accompanied by warnings of the validations which the file has failed. No
further action is required by the user in this instant.
Req ID
CR201
CR202
CR203
CR204
Requirement Text
A user MUST be able to request a Yellow Card is
created for a specific patient at any time.
The system SHOULD prompt a user to report a Yellow
Card when a medication is stopped for a patient or
when drug side effect or sensitivity is recorded on the
patients record
The Yellow Card MUST have the patient details and
reporter details automatically populated from the
patient record/GP system
After the user has requested a Yellow Card be created,
the system MUST provide a dialog or series of dialogs
for user entry of information which cannot be populated
automatically from the patient record/GP system
Status
Must
Should
Must
Must
4.4 Audit Requirements
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 13 of 22
Commercial in Confidence
The fact that a Yellow Card has been completed, transmitted and successfully
received should be recorded within the GP system.
Req ID
CR301
Requirement Text
When a Yellow Card has been processed and
transmission to the MHRA webservice acknowledged,
the local audit trail MUST include an entry reflecting
this, including a timestamp
Status
Must
4.5 Frequency of transmission
Electronic Yellow Cards are sent to the web-service individually and should be
sent the same day as completed by the reporter in order that the information
is available for analysis and assessment as quickly as possible.
Req ID
CR401
CR402
Requirement Text
A Yellow Card MUST be transmitted to the MHRA
webservice immediately once it is created.
The transmission MUST be reattempted if an
acknowledgement or rejection code is not received
Status
Must
Must
4.6 Data items to be returned
Mapping of data fields from GP systems to the electronic Yellow Card must be
completed individually for each system. A Yellow Card requires four main
areas of data to be included in order for the report to be considered valid –
patient, reporter, drug and reaction. Detailed information on data field
requirements and validations are provided in the field definition spreadsheet.
4.6.1 Patient data
At least one of the following patient data must be required in order for a
Yellow Card to be considered a valid report.
Age (at time of reaction)
Sex
General Unique Identification (GUID) – this would be a unique ID
generated specifically for the Yellow Card and patient which maps to
the patient ID using a local database mapping table. Access to this
table will be restricted to local system administrators only.
Where available the following may also be provided:
Weight
Height
Name, date of birth and NHS number are not collected and it is not
considered that the patient information above is sufficient to identify an
individual (See Appendix 4.10 for information on Yellow Card data
confidentiality). Inclusion of a local identification number allows follow-up for
additional information if required for assessment of the case.
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 14 of 22
Commercial in Confidence
Req ID
CR501
CR502
4.6.2
Requirement Text
A Yellow Card MUST be automatically populated with
patient age, sex and a General Unique Identification
A Yellow Card MAY automatically populate patient
weight and height when this is available in the patient
record
Status
Must
May
Reporter data
Contact details of the reporter are required. The MHRA consider reporter
confidentiality to be important and data is not shared with any other
organisation without explicit permission from the reporter.
Reporter name
Reporter address (surgery address, including ONS GP practice code)
Reporter telephone
Reporter email
Req ID
CR601
CR602
4.6.3
Requirement Text
A Yellow Card MUST be automatically populated with
reporter name, address, telephone and email from the
information held within the system.
A Yellow Card MAY include GP practice LSOA code in
the reporter details where this is available.
Status
Must
May
Drug/vaccine data
One or more drug or vaccines suspected to have caused a reaction are
required. Additional information including dates of treatment, indication (as
MedDRA LLT), and concomitant medications are also useful.
Suspect drug(s)
Where available:
Concomitant drug(s) given in the last three months
Routes of administration
Doses
Indications
Start dates
Stop dates
Req ID
CR701
CR702
Requirement Text
A Yellow Card MUST include at least one suspect
drug/vaccine entry using DM+D. The user MUST be
able to select a suspect drug or drugs from listed on
the patient record, given in the last three months.
A Yellow Card SHOULD automatically populate route
of administration, dose, start and stop dates, and
indications for the selected suspect drug when
available
Yellow Card reporting in GP Systems
Version 3.0 draft
Status
Must
Should
Page 15 of 22
Commercial in Confidence
Req ID
CR801
CR802
4.6.4
Requirement Text
A Yellow Card MUST automatically populate
concomitant drugs from the patient record when
available
For concomitant drugs populated, a Yellow Card
SHOULD automatically include route of administration,
dose, start and stop dates, and indications when
available from the patient record
Status
Must
Should
Reaction data
One or more reactions suspected to be caused by a drug or vaccine are
required as well as the outcome. Reactions should be provided using
SNOMED CT IDs.
Reaction
Reaction outcome
Where available:
Reaction start date
Reaction stop date
Reaction narrative (free text)
Req ID
CR901
CR902
Requirement Text
Status
A Yellow Card MUST include at one or more suspect
Must
reactions and reaction outcome(s) as selected by the
user
A Yellow Card SHOULD include reaction start and
Should
stop dates and reaction narrative when provided by the
user
4.7 Yellow Card Webservice and Webservice security
The webservice has been implemented using Simple Object Access Protocol
(SOAP). Two operations are supported:
ValidateE2B – validation rules are applied to the Yellow Cards submitted,
however the Yellow Card is not saved by the webservice into the MHRA
system.
UploadE2B – Yellow Cards submitted are first passed through the validation
steps after which the data is saved into the MHRA system.
Secure Sockets Layer (SSL) cryptographic protocol is used to encrypt the
network connection over which the Yellow Card data is transmitted, via
HTTPS. Systems providers must access the webservice using a username
and password.
(Please see https://ehr-services.mhra.gov.uk/default.asmx?op=UploadE2B
and https://ehr-services.mhra.gov.uk/default.asmx?op=ValidateE2B for
example SOAP 1.1 and SOAP 1.2 requests and responses.)
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 16 of 22
Commercial in Confidence
The URLs are as follows:
Testing - http://mhra-ehr-uat.web10.redantdev.com/default.asmx
Production - https://ehr-services.mhra.gov.uk/default.asmx
4.8 Testing
A period of testing with the MHRA is required from each individual system.
This includes checking Yellow Card messages are correctly formed and meet
data validation requirements, transmission to the MHRA webservice as well
as ensuring messages receive an acknowledgment code.
An E2B ICSR test form is available for testing validation and parsing at
http://mhra-ehr.web10.redantdev.com/test.aspx. After pasting xml content
into the form, any errors resulting from a failure to parse, or warnings from
failed validations are displayed.
Screenshot showing warnings received due to failed validations – a
‘load’ response would be received by the sender
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 17 of 22
Commercial in Confidence
Screenshot showing errors received due to a failure to parse – a ‘fail’
response would be received by the sender
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 18 of 22
Commercial in Confidence
Appendices
4.9 Impact of the Yellow Card Scheme
The following table shows some of the safety issues which Yellow Card
reports have helped identify:
Year
Medicine
June
2010
Dec
2009
Adverse Reaction
Rivastigmine
(Exelon)
Finasteride
(Proscar,
Propecia)
Jun 2009 Antipsychotics
Medication errors
Apr 2009
Adverse effects on
bone
Antiepileptics
Potential risk of male
breast cancer
Venous
thromboembolic events
Jan 2009 Tacrolimus
/Dec
(Advagraf and
2008
Prograf)
Risk of serious
medication errors
Dec
2008
April
2008
Hedrin
(dimeticone)
Unlicensed
herbal
product
marketed for
diabetes
Hair fire accident
Feb
2008
Varenicline
(Champix)
Depression, suicidal
thoughts and behaviour
Nov
2007
St John‟s
wort,
Hypericum
perforatum
Interaction with all
antiepileptics
Nov
2007
Aristolochia in
Chinese
herbal
remedies
Renal failure,
transitional-cell
carcinoma
Yellow Card reporting in GP Systems
Version 3.0 draft
Resulting action or
advice
Warning issued in Drug
Safety Update (DSU)
Product
information for
prescribers updated
Product
information for
prescribers updated
Vitamin D
supplementation should
be considered for at risk
patients
Prograf and Advagraf
are not interchangeable
and should not be
substituted
without careful
therapeutic monitoring
Warning to keep hair
away from fire
Dangerous advice
to patients to stop
taking prescribed
medication
Warnings issued and
monitoring of patients
with history of
psychiatric illness
advised
current warnings about
interactions should
extend to include all
antiepileptic
medicines
Reminder of warnings,
and ban
Page 19 of 22
Commercial in Confidence
2006
Linezolid
(Zyvox)
Optic neuropathy
2006
Chinese
herbal
remedy:
Polygonum
multiflorum
Black cohosh
(Cimicifuga
racemosa)
Rosuvastatin
(Crestor)
Hepatotoxicity
Improved warnings and
monitoring
recommendations
Warnings
Hepatotoxicity
Improved warnings
Rhabdomyolysis
2003
Warfarin
2003
Aspirin
2003
Kava-kava
(Piper
methysticum)
Ergot derived
dopamine
receptor
agonists;
pergolide
(Celance),
bromocriptine
(Parlodel),
cabergoline
(Cabaser),
lisuride
Bupropion
(Zyban)
Interaction with
cranberry juice leading
to changes in INR
values and bleeding
episodes
Reye‟s Syndrome in
children under 16 years
Hepatotoxicity
Revised dosing
instructions and
improved warnings
Warnings
2006
2004
2002
2001
Yellow Card reporting in GP Systems
Version 3.0 draft
Statutory label warning
Supply prohibited in the
UK
Fibrotic reactions
Class warnings added
to product information
Seizures
Improved warnings and
revised dosing
instructions
Page 20 of 22
Commercial in Confidence
4.10 Yellow Card Data Privacy
4.10.1
Data provision
Information at patient level, i.e. a report about a patient who has experienced
an adverse drug reaction, is routinely provided to pharmaceutical companies
under the MHRA's statutory obligations. This information is considered
anonymised, and may include, if reported, initials, age, sex, and an
identification number. This local identification number is requested so the
original reporter can identify the patient if further information is sought, but is
not a recognisable patient ID otherwise.
Requests from health professionals and the public for adverse drug reaction
data is subject to a data provision policy. Following the 2004 Independent
Review of Access to the Yellow Card Scheme systems were established to
ensure that any information included in the database is subject to release
under the Freedom of Information Act (FOIA) while at the same time
protecting the confidentiality of individuals and their personal data as the Data
Protection Act (DPA) require.
Requests for provision of data are divided into a number of categories.
Category 1a data is cumulative listings and these are publicly available from
the MHRA website. Category 1b data case details listed below are releasable
under the Freedom of Information Act (FOIA). Provision of these data will
depend on the number of cases held by the Agency. The MHRA will not
release any data subset in which there are five or fewer cases per cell. This
is necessary to prevent identification of patients and/or reporters. Where
there are less than five cases per cell the data will be aggregated with
adjacent cells with any aggregation clearly marked on the dataset. Category
1b data fields are:
Patient age categories (<18, 18-24, 25-34, 35-44, 45-54, 55-64, 6574, 75-84, >85 years)
Patient gender (number of female and male patients)
Suspect drug(s)
Dose of suspect drug
Route of administration
Duration of treatment
Suspected adverse drug reaction(s)
Reaction outcomes
Onset times
Patient medical history
Year of report (if requested)
If more detailed information than can be provided under category 1b, or there
are 5 or fewer cases, then the request is classed as a Category 2 request.
For Category 2 requests a form must be completed for consideration by
the Independent Scientific Advisory Committee for MHRA database
research (ISAC). This includes questions on what purpose the data is for,
how it is to be used and how it is to be securely stored.
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 21 of 22
Commercial in Confidence
4.10.2
Access to Yellow Card data within the MHRA
Yellow Card data is securely stored at the MHRA and user access rights and
permissions are maintained on an individual user basis, and only users with
appropriate access and training are able to access Yellow Card data. The
users who have access to this information are those who use the data for
drug safety monitoring or the associated supportive system administration. All
users are signatories of a declaration acknowledging and accepting the
restrictions dealing in securities and other assets and disclosure of
information.
4.10.3
Potential for cross-linkage of Yellow Card data
It is not possible to link ADR data from the MHRA to other datasets, as no
cross-linkable case level identifier is recorded. A local identifier can be
completed on a Yellow Card; however this is only interpretable by the original
reporter and is recommended to only be an arbitrary reference. If an NHS
number is reported, this is not entered into the database.
Yellow Card reporting in GP Systems
Version 3.0 draft
Page 22 of 22