STD029 - Dictionary of Medicines and Devices (dm+d)

STD034 - Electronic Yellow Card Reporting, Version 3.0

STD029

Dictionary of Medicines and Devices (dm+d)

SCCI0052

0.1

SCCI0052 Guidance (NHS Digital)

Guidance

Alpha

TBC

STD029-1

Health and care organisations MUST ensure that any IT systems that record medicines information comply with the requirements by the next major update, or new procurement, or by 30 June 2017 whichever is sooner.

MUST

STD029-2

Health and care organisations MUST ensure that IT systems use SNOMED CT identifiers specified in dm+d to communicate information between them by the next major update, or new procurement, or by 30 June 2017 whichever is sooner.

MUST

STD029-3

Local or COTS identifiers MAY be used alongside dm+d identifiers when transferring information but only where systems are known to be wholly interoperable and utilise a terminology common to both the sending and the receiving system.

MAY

STD029-4

Health and care organisations SHOULD put in place a process by which medicines not in dm+d can be requested.

SHOULD

STD029-5

Health and care organisations MUST conform to SCCI0160 Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems when deploying an IT system used for medication management, including those that use dm+d by the next major update, or new procurement, or by 30 June 2017 whichever is sooner.

MUST

STD029-6

Health and care organisations SHOULD use dm+d identifiers and descriptions where medicine data is required in secondary uses data sets.

SHOULD

STD029-7

Health and care organisations MUST ensure IT systems suppliers register to obtain a licence to download dm+d data and associated files from TRUD by the next major update, or new procurement, or by 30 June 2017 whichever is sooner. They MUST attribute the use of this standard, dm+d and associated products licensed under the Open Government Licence in product documentation. There is no charge for this licence

MUST

STD029-8

Health and care organisations MUST have processes in place to be able to act on any urgent recalls issued through TRUD in a timely manner by the next major update, or new procurement, or by 30 June 2017 whichever is sooner. These will be communicated to the registered email address for the TRUD account.

MUST

STD029-9

Health and care organisations MUST conform to SCCI0129 Clinical Risk Management: its Application in the Manufacture of Health IT Systems for IT systems that use dm+d by the next major update, or new procurement, or by 30 June 2017 whichever is sooner.

MUST

STD029-10

Health and care organisations MUST ensure that the dm+d release data is updated at least every 6 months by the next major update, or new procurement, or by 30 June 2017 whichever is sooner. However more frequent updates may be driven by a programme requirement or a specific use case

MUST

STD029-11

IT system suppliers:

Additions to the content MAY be made to support local requirements but these MUST NOT use the dm+d identifier namespace.

MAY

STD029-12

IT system suppliers:

dm+d concepts within a component MUST NOT be deleted or amended. However, the system need not use all components.

MUST

STD029-13

IT system suppliers:

dm+d MAY either be used natively, i.e. as the sole medicine terminology, or by accurately mapping between another dictionary and dm+d. If dm+d is mapped, the health and care organisation is responsible for the mapping. They MUST ensure it is fit for purpose and appropriately maintained.

MAY

STD029-14

Health and care organisations MUST ensure that where a SNOMED CT identifier and dm+d description are both used to identify a medicine that the integrity is preserved between them by the next major update, or new procurement, or by 30 June 2017 whichever is sooner.

MUST

STD029-15

IT system suppliers:

Systems MUST be able to output and receive SNOMED CT identifiers specified in dm+d and on receipt of an identifier the system MUST be able to ‘translate’ it to and display the associated human readable text description (whether a dm+d description or mapped to a concept within a local or COTS medicine dictionary) by the next major update, or new procurement, or by 30 June 2017 whichever is sooner.

MUST

STD029-16

IT system suppliers:

SNOMED CT identifiers specified in dm+d MUST be used where information on medicines used in the care of a NHS patient is transferred electronically from one system to another system by the next major update, or new procurement, or by 30 June 2017 whichever is sooner.

MUST

STD029-17

IT system suppliers:

If there is no identifier for a medicine (for example the medicine is new and has not yet been included), the system MUST have an appropriate failure mode by the next major update, or new procurement, or by 30 June 2017 whichever is sooner. This could be, for example, by transmitting a textual description or reverting to a paper process. Where a paper process is deemed appropriate in such instances, considerations must be given so as not to allow segregation of data. System users MUST also be made aware a prescription created in this manner is likely to have been subject to minimal decision support.

MUST

STD029-18

Health and care organisations MUST ensure the system provides an appropriate failure mode if a SNOMED CT identifier is received but not recognised by the next major update, or new procurement, or by 30 June 2017 whichever is sooner.

MUST

STD029-19

IT system suppliers:

Where dm+d concepts are used directly within and in underlying data, then the visual representation of the record/display SHOULD faithfully represent the content in ways that are recognisably and wholly consistent with dm+d concepts and the dm+d model.

SHOULD

STD029-20

IT system suppliers:

Systems MAY either use dm+d descriptions for visual display or map to a local or COTS medicine dictionary and use those descriptions.

MAY

STD029-21

IT system suppliers:

Systems that display dm+d descriptions MUST support a field length of 255 characters with no truncation. Note. String wrapping onto an additional line is permitted by the next major update, or new procurement, or by 30 June 2017 whichever is sooner.

MUST

STD029-22

IT system suppliers:

dm+d identifiers SHOULD NOT be used for human readable display.

SHOULD

STD029-23

IT system suppliers:

The abbreviated name in dm+d MUST NOT be used for display purposes on screen.

MUST

STD034

Electronic Yellow Card Reporting, Version 3.0

DCB1582

0.1

DCB1582 Guidance (Medicines and Healthcare products Regulatory Agency (MHRA))

Guidance

Alpha

STD034-1

IT suppliers systems MUST be able to manually request a Yellow Card is created for a specific patient.

MUST

STD034-2

IT suppliers systems MUST prompt a user to report a Yellow Card when a medication previously on repeat-prescription is stopped when a user confirms a patient experienced an adverse drug reaction/drug intolerance/allergic drug reaction. (See sections 11 and 12 for SNOMED CT triggers)

MUST

STD034-3

IT suppliers systems SHOULD prompt a user to report a Yellow Card when an adverse drug reaction/drug intolerance/allergic drug reaction is recorded using a medical terminology. Systems may provide users the option to record without triggering a Yellow Card, or both record and trigger a Yellow Card (See sections 11 and 12 for SNOMED CT triggers)

SHOULD

STD034-4

IT suppliers systems SHOULD prompt a user to report a Yellow Card when an adverse drug reaction/drug intolerance/allergic drug reaction is recorded in a specific ADR recording area. Systems may provide users the option to record without triggering a Yellow Card, or both record and trigger a Yellow Card (See sections 11 and 12 for SNOMED CT triggers)

SHOULD

STD034-5

IT suppliers systems MAY prompt a user to report a Yellow Card when a fatality due to adverse drug reaction/drug intolerance/allergic drug reaction is recorded using a medical terminology.

MAY

STD034-6

IT suppliers systems MAY prompt a user to report a Yellow Card when a difference between admission and discharge medicine information is recognised (requirement does not apply to primary care systems)

MAY

STD034-7

IT suppliers systems MAY prompt a user to report a Yellow Card when on admission, reason recorded as due to adverse drug reaction/drug intolerance/allergic drug reaction is recorded (requirement does not apply to primary care systems)

MAY

STD034-8

IT suppliers systems SHOULD allow a user to either complete the Yellow Card immediately or be able to record an intention to complete a Yellow Card at a later stage.

SHOULD

STD034-9

IT system suppliers:

If a user selects an option to complete a Yellow Card at a later stage, an automated system for reminding the user MUST be in place.

MUST

STD034-10

IT system suppliers:

After the user requests that a Yellow Card be created, the system MUST provide a method for user entry of information which cannot be populated automatically from the patient record including reaction start and stop dates, additional medications and free-text information on reaction narrative, patient history and relevant tests.

MUST

STD034-11

IT system suppliers:

A user MUST be able to retrieve a Yellow Card previously completed by entering the safety report id so that additional information on the patient or adverse drug reaction may be provided to the MHRA on request. (Responses to follow up information requests are not via transmission of an electronic Yellow Card message). The search function should span across the organisation (e.g. surgery) in order to identify the Yellow Card. The system should list all previously submitted Yellow Cards

MUST

STD034-12

IT system suppliers:

When a Yellow Card has been processed and transmitted to the MHRA webservice and an acknowledgement received, the local audit trail MUST include an entry reflecting this.

MUST

STD034-13

IT system suppliers:

The Yellow Card XML message and a human readable version MUST be either stored in the patient record, or reproducible from data held in the system.

MUST

STD034-14

IT system suppliers:

A Yellow Card MUST be transmitted to the MHRA webservice as soon as possible once it is created.

MUST

STD034-15

IT system suppliers:

If an XML is rejected due to an error, the user MUST be made aware of this fact using a method appropriate to the system. This may be through adding an item to a work queue or by notifying a user, local administrator, or system administrator. The reporter is advised to report on the Yellow Card website or print the Yellow Card to pdf and email to pharmacovigilance@mhra.gov.uk, or post to FREEPOST YELLOW CARD (no other address details necessary)

MUST

STD034-16

IT system suppliers:

The transmission MUST be reattempted if the webservice is not available: transmission should be reattempted at least 3 times over an appropriate time period. This is expected to extend over a time period greater than 24 hours and must take into account system out-of-hours and weekend downtime. If still unsuccessful, the problem is written to the audit log and brought to a user’s attention - this may be through adding an item to a work queue or by notifying a user, local administrator, or system administrator. The user is advised to report on the Yellow Card website or print the Yellow Card to pdf and email it to pharmacovigilance@mhra.gov.uk or post to FREEPOST YELLOW CARD (no other address details necessary)

MUST

STD034-17

IT system suppliers:

A system MUST create electronic Yellow Cards using the defined xml format using the ISO8859-1, UTF-8 or UTF-16 character sets.

MUST

STD034-18

IT system suppliers:

Medical terms MUST be populated using SNOMED CT term concept IDs or MedDRA Lower Level Terms IDs (LLTs). Read V2, Read V3 or CTV3 terms MUST first be mapped to SNOMED CT concept IDs using a NHS TRUD cross-map. Where no mapping exists, the MedDRA LLT code ‘10052538’ for ‘Adverse drug reaction NOS' MUST be populated.

MUST

STD034-19

IT system suppliers:

Yellow Cards transmitted as an XML file to the Yellow Card webservice MUST parse against the DTD in order to be accepted.

MUST

STD034-20

IT system suppliers:

Data field values MUST meet data validation requirements. These are listed in DCB1582 electronic Yellow Card message fields and validations and can be checked using the webservice ValidateE2B function.

MUST

STD034-21

IT system suppliers:

The Yellow Card MUST have the patient age at time of reaction and sex automatically populated from the patient record when this is present in the patient record.

MUST

STD034-22

IT system suppliers:

A Yellow Card SHOULD automatically populate patient weight and height when a current value is present in the patient record.

SHOULD

STD034-23

IT system suppliers:

A Yellow Card MUST automatically populate patient medical history recorded in the past year (i.e. date recorded is within one year of the Yellow Card creation date). The medical history terms MUST be populated using SNOMED CT Concept IDs or MedDRA LLTs. (Refer to requirement 18 for more details).

MUST

STD034-24

IT system suppliers:

A Yellow Card MUST be automatically populated with reporter name, address, telephone and email from the information held within the system.

MUST

STD034-25

IT system suppliers:

All current repeat medications and any discontinued repeat or acute medication prescribed to a patient in the three months prior to the date of the Yellow Card creation date MUST be populated using dm+d entries, using the most detailed term level available (AMP>VMP>VTM>Active substance) . For any repeat medications, this should be limited to one entry with the initiation date.

MUST

STD034-26

IT system suppliers:

A user MUST also be able to enter a suspect or concomitant medicine using free text where dm+d cannot provide a suitable term. For example: an unlicensed medicine purchased on the internet.

MUST

STD034-27

IT system suppliers:

The user MUST select one or more medicines to indicate a suspicion of having caused (i.e. may have caused) the adverse drug reaction. The number of suspect medicines MUST NOT be limited to any number.

MUST

STD034-28

IT system suppliers:

A Yellow Card MUST include at least one or more suspect reactions (coded using SNOMED CT concept IDs or MedDRA LLTs) and a reaction outcome for every reaction as selected by the user. (The list of outcome values is provided in DCB1582 electronic Yellow Card message fields and validations. Reaction outcome MUST be populated as ‘unknown’ if not known or is not available to the reporter). The number of suspect reactions MUST NOT be limited to any number.

MUST

STD034-29

IT system suppliers:

For all suspect and concomitant medicine/drug entries populated, a Yellow Card SHOULD automatically include route of administration, dose, start and stop dates, and indications when available from the patient record.

SHOULD

STD080

UK Edition SNOMED CT

SCCI0034

0.1

SCCI0034 Guidance (NHS Digital)

Guidance

Alpha

STD0080-1

The IT supplier’s system must use SNOMED CT to provide the vocabulary for data elements that need to be:

• Shared outside the organisation,

• Extracted from the EPR,

• recorded in line with national guidelines (for example NICE guidelines) or

• used by national/regional specifications (for example QOF, service commissioning, clinical calculators, decision support rules) where the data elements are in scope of the SNOMED terminology. (For example a postcode is not in scope, but an intervention is).

MUST

STD0080-2

The IT supplier’s system MUST use the standard to support the management of the health and care of the patient in the following, but not restricted to, ways within electronic systems:

• In messages that are used to transfer patient related data from one system to another. • Patient Summaries including Discharge summaries.

• Problem lists.

• Allergy Lists and Allergy Management.

• Decision Support tools.

• Clinical Documentation.

• Care Plans; in particular for clinical content that will be transferred between systems.

• Keyword lists for metadata in care pathways, research documents, evidence based content.

• Reporting from data captured using SNOMED CT: systems will need to enable queries to be constructed that utilise the features and hierarchies within SNOMED CT.

MUST

STD0080-3

The IT supplier’s system MUST allow the end user to be able to enter SNOMED CT terms into the electronic patient record. How those terms are made available is part of the user interface design of the solution, and may vary considerably depending on the application. How terms are stored is also the domain of the application, however the application must be able to process and transmit the concept id and an appropriate description.

Techniques such as:

• searching using the beginning of words in the clinical term, for example ‘fract femur’ for ‘fracture of femur’ (in any order),

• subsets to provide just procedures or just paediatric terms,

• shortcodes, abbreviations, equivalent terms etc. can be used in order to provide a good user experience for data entry.

When SNOMED is provided in an EPR system, users must be able to search on any of the synonyms. It should be possible for the user to select and enter any of the SNOMED CT descriptions, although it is generally advised that systems should not utilise the FSN in a patient record. Some applications may wish to guide the user to only enter the preferred term. Systems should wherever possible, restrict the terms available based on the context of the data item, for example only allow procedures in a procedure field. Care should be taken with diagnosis that this isn’t too restrictive as often symptoms may be entered if a diagnosis has not been possible.

MUST

STD0080-4

As a minimum, the IT suppliers systems that incorporate any of the following data items must be using SNOMED CT to capture their content:

• Symptoms

• Diagnosis

• Procedures (interventions)

• Assessment Scales

• Family History

• Medications Allergies

• Observations such as Blood pressure, weight, height

• Documentation Type and documentation care setting

• Laterality

• Body Site

MUST

Diagnostics Standards