Health Informatics — Requirements for a knowledge base for clinical decision support systems to be used in medication-related processes

This document specifies the requirements for developing a knowledge base for drug-related problems that cohere with the intended drug use, to be used in rule-based clinical decision support systems (CDSS), such as the criteria for selecting a raw data source and the quality criteria for the development and maintenance for the rules or clinical rules for drug safety. It also describes the process of how to develop a knowledge base, the topics to be considered by the developers of a knowledge base, and it gives guidance on how to do this. This document gives guidelines for the development of a knowledge base: — with rules to enhance decisions and actions in drug-related problems that cohere with the intended drug use; — which can be used by all kinds of healthcare professionals, such as those who prescribe, dispense, administer or monitor medicines; — which can be used in every care setting, including chronic and acute care, primary and specialized care; — which is a repository of evidence/practice bases rules, assessed by experts; — which is meant to be used in conjunction with a medicinal product dictionary; — whose knowledge is structured in rules and therefore to be used in the type of rule-based CDSS. This document does not: — describe the exact content of a knowledge base i.e. the outcome of the process of developing rules. — provide the requirements for a clinical decision support system, the software that uses the knowledge base combined with the patient's data, and presents the outcome of the rules to the healthcare professional. These requirements are described in ISO/DTS 22703[1]. — give the requirements for non-medication knowledge bases. Some aspects of the requirements in this document are general in nature and applicable to other kinds of knowledge bases, but this document does not address all of the requirements of non-medication knowledge bases. [1] Under preparation. Stage at the time of publication: ISO/DTS 22703.

Informatique de santé — Exigences relatives aux bases de connaissances pour systèmes d’aide à la décision clinique à utiliser dans le cadre des processus liés aux médicaments

General Information

Status
Published
Publication Date
20-Sep-2020
Current Stage
9093 - International Standard confirmed
Start Date
05-Jun-2024
Completion Date
07-Dec-2025
Ref Project
Technical specification
ISO/TS 22756:2020 - Health Informatics — Requirements for a knowledge base for clinical decision support systems to be used in medication-related processes Released:9/21/2020
English language
31 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


TECHNICAL ISO/TS
SPECIFICATION 22756
First edition
2020-09
Health Informatics — Requirements
for a knowledge base for clinical
decision support systems to be used in
medication-related processes
Informatique de santé — Exigences relatives aux bases de
connaissances pour systèmes d’aide à la décision clinique à utiliser
dans le cadre des processus liés aux médicaments
Reference number
©
ISO 2020
© ISO 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2020 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviations. 4
5 Positioning of a CDS knowledge base . 5
5.1 Knowledge in healthcare . 5
5.2 Knowledge for drug-related problems that cohere with the intended drug use . 5
5.3 The structure of the knowledge . 6
5.4 Knowledge base in relation to the healthcare information system . 7
5.4.1 Introduction . 7
5.4.2 Relation with EHR . . 7
5.4.3 Relation with medicinal product data . 8
5.4.4 Relation with a CDSS . 8
6 Requirements for the development of a knowledge base . 8
6.1 Introduction . 8
6.2 The governance of a knowledge base . 8
6.3 Structure of the rules . 9
6.4 Scoping of the knowledge base content . 9
6.5 Evidence for the rules . 9
6.6 Medicinal product data used in the rules .10
6.6.1 Medicinal product dictionary .10
6.6.2 IDMP .10
6.6.3 Interface with an MPD or with IDMP .11
6.7 Dosage data used in the rules .11
6.8 Patient data variables used in the rules .12
6.8.1 Introduction .12
6.8.2 Interface with the EHR .12
6.9 Right information at the right time .13
6.10 Quality of the rules .13
6.11 Relation with a CDSS .14
6.12 Maintenance .14
Annex A (normative) Identifying IDMP fields in relation to a knowledge base .16
Annex B (informative) Example of a knowledge base rule .25
Bibliography .30
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso .org/
iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 215, Health Informatics, in collaboration
with the European Committee for Standardization (CEN) Technical Committee CEN/TC 251, Health
informatics, in accordance with the Agreement on technical cooperation between ISO and CEN (Vienna
Agreement).
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
iv © ISO 2020 – All rights reserved

Introduction
0.1  Safe and effective usage of medicines is important
When a patient gets his/her medicines prescribed and dispensed, it is not only important that the
patient gets the correct medicine and that ordering and reimbursement is supported by using a
Medicinal Product Dictionary (MPD), but it is also important that the medicine is safe and effective with
respect to the specific situation of the patient.
Because an MPD contains just the identification of the medicines, it is important that an MPD is enriched
with clinical decision support (CDS). The aim of CDS is to help prescribe and dispense the medicine
that fits the patient’s personal situation in respect of effectiveness and toxicity of the medicine.
Based on a knowledge base combined with the patient's situation such as comedication, comorbidity,
age, laboratory values, diet, allergy, a healthcare professional can be warned for likely side effects or
ineffectiveness, and change the therapy.
0.2  Need for a standardized knowledge base
To achieve the aim described in Clause 0.1, there are several success factors, in literature, referred to as
[28]
the ‘five rights’ :
— The right information: the information should be evidence based and give concrete guidance for action.
— To the right person: the alerts should be presented to the person who is the most likely one to take
action (e.g. the clinician, the pharmacist, the caretakers).
— In the right CDS intervention format: such as an alert, a request to measure certain laboratory
parameters, or an answer to a clinical question.
— Through the right channel: this can be the clinical information system like the pharmacy information
system, or a web-browser that makes available the data of the knowledge base.
— At the right time in workflow: for example, during prescription or dispensing, or in batch at night to
have certain data available the next morning.
To provide the right information, a knowledge base is necessary; and also providing the knowledge to
the right person, the right format and at the right time in the workflow is part of a knowledge base, as far
as it concerns the ‘knowledge’ of it.
There are clinical decision support systems (CDSSs) that provide this knowledge, but Helmons stated
that there are several barriers for implementing a CDSS, one of them being ‘content issues’ like:
‘Typically installed without any validated decision rules, which have to be developed and/or validated
[26]
in each individual institution (also called ‘having to reinvent the wheel’)' .
Therefore, a (technically) validated, standardized knowledge base is the recommended basis for CDS.
The needs for a standardized knowledge base are as follows:
— There is an overwhelming amount of data in the summary of product characteristics (SPC),
guidelines, literature and handbooks. Prescribers, physicians and pharmacists cannot easily find
what to do for a certain drug combination or drug-disease combination. The most relevant data and
accompanying recommendations are curated from literature and put in rules in a knowledge base.
— Information about the availability, safety and efficacy of medication to be used for the prescription
by physicians is often outdated even when the information is available electronically (e.g. in the drug
interaction management system in a doctor's office). Linking the information from the Medicinal
Product Dictionary to a CDSS that uses a validated, standardized knowledge base makes sure that
during prescribing/dispensing up-to-date information is always used.
— While the population is still growing, people become older and have more comorbidity and
polypharmacy, the need for smart knowledge base rules that provide the basis for generating alerts
with a high specificity and sensitivity, is increasing.
— Besides assuring that the most precise and current information is to be used in the knowledge base
for the benefits of the patient, this specification will also provide a basis or 'handles' how to map the
information to the MPD, the IDMP vocabulary and their own local data in EHR and pharmaceutical
domains.
0.3  Focus — A knowledge base for drug-related problems that cohere with the intended drug use
This document is about a standardized knowledge base to be used in medication-related processes. In
the context of this document, this means a knowledge base that has its focus to enhance decisions and
actions in drug-related problems that cohere with the intended drug use, namely once a drug has been
chosen, in any domain of prescribing, dispensing, administering of the drug and monitoring the patient.
Aspects like choosing the right drug according to guidelines and patient coaching for the correct usage
are not included in the scope of this document (which does not mean that the requirements that are
described in this document are not useful for knowledge bases with such kind of scopes).
0.4 Why this document: general principles versus medication specific aspects for developing a
knowledge base
Describing how a structured, standardized knowledge base should be developed, what are the criteria
to take into account, is a rather general process. As such it is not specific for medication processes.
Assessing literature and developing rules is also applicable for other domains.
In this respect, this document contains two sorts of requirements. First, there is the overarching
level, not specific for medication processes. This includes, for example, the requirements for selecting
and assessing literature, updating the knowledge base. Secondly, there is a medication-specific level
in this document. This includes the area to which the requirements are applied: if the requirement
is to determine which kind of people will assess the rules, the document mentions the disciplines in
healthcare: such as pharmacists, physicians.
0.5  Use cases
The use cases for a knowledge database for drug-related problems are primarily decision support based
on validated, standardised rules to enhance decisions in the process of:
— prescribing
— dispensing
— administering
— monitoring the therapy of the patient.
Besides that, decision support based on a standardised knowledge base can also be useful for (not
exhaustive):
— travel medicines
— health counselling.
0.6  Target users of this document
The target users of this document for a knowledge base in medication-related processes include:
— Academic organisations in the field of pharmaceutical healthcare, that develop knowledge bases for
medicines;
vi © ISO 2020 – All rights reserved

— Vendors and other parties developing CDSSs (based on knowledge bases as described in this
document), like (not exhaustive):
— clinical or pharmacy information systems
— hospital ward information system
— doctor‘s office information systems
— decision aids for patients.
TECHNICAL SPECIFICATION ISO/TS 22756:2020(E)
Health Informatics — Requirements for a knowledge
base for clinical decision support systems to be used in
medication-related processes
1 Scope
This document specifies the requirements for developing a knowledge base for drug-related problems
that cohere with the intended drug use, to be used in rule-based clinical decision support systems
(CDSS), such as the criteria for selecting a raw data source and the quality criteria for the development
and maintenance for the rules or clinical rules for drug safety. It also describes the process of how to
develop a knowledge base, the topics to be considered by the developers of a knowledge base, and it
gives guidance on how to do this.
This document gives guidelines for the development of a knowledge base:
— with rules to enhance decisions and actions in drug-related problems that cohere with the intended
drug use;
— which can be used by all kinds of healthcare professionals, such as those who prescribe, dispense,
administer or monitor medicines;
— which can be used in every care setting, including chronic and acute care, primary and
specialized care;
— which is a repository of evidence/practice bases rules, assessed by experts;
— which is meant to be used in conjunction with a medicinal product dictionary;
— whose knowledge is structured in rules and therefore to be used in the type of rule-based CDSS.
This document does not:
— describe the exact content of a knowledge base i.e. the outcome of the process of developing rules.
— provide the requirements for a clinical decision support system, the software that uses the
knowledge base combined with the patient’s data, and presents the outcome of the rules to the
1)
healthcare professional. These requirements are described in ISO/DTS 22703 .
— give the requirements for non-medication knowledge bases. Some aspects of the requirements in
this document are general in nature and applicable to other kinds of knowledge bases, but this
document does not address all of the requirements of non-medication knowledge bases.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 11615, Health informatics — Identification of medicinal products — Data elements and structures for
the unique identification and exchange of regulated medicinal product information
ISO/TS 19256, Health informatics — Requirements for Medicinal Product Dictionary Systems for Healthcare
1) Under preparation. Stage at the time of publication: ISO/DTS 22703.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1
clinical decision support
type of service that assists healthcare providers in making medical decisions, which typically require
input of patient-specific clinical variables and provide patient-specific recommendations
[SOURCE: ISO/TR 14639-2:2014, 2.8, modified — Note 1 to entry has been deleted.]
3.2
clinical decision support system
software designed to be a direct aid to clinical decision-making, in which the characteristics of an
individual patient are matched to a computerized clinical knowledge base, whereafter patient-specific
assessments or recommendations are presented to the clinician or the patient to aid in the process of
making evidence based clinical decisions
[SOURCE: Ida Sim e.a., Clinical decision support systems for the practice of evidence-based medicine, J Am
Med Inform Assoc. 2001 Nov-Dec; 8(6): 527–534, modified]
3.3
dispensing
process by which an individual healthcare provider takes in a prescription, assesses that prescription,
selects the prescribed medicinal product and delivers that medicinal product to the subject of care
or their representative
Note 1 to entry: In most cases, but not necessarily always, the individual healthcare provider concerned will be a
Pharmacist.
[SOURCE: ISO/TS 19256:2016, 3.9]
3.4
dispense record
record of dispensed medicinal product and dispense process
Note 1 to entry: Note 1 to entry: Dispensed medicinal product includes the actual product dispensed identifiers,
brand, type, form, quantity etc. Dispense process record includes details of the delivery method, date and
recipient (where this is not the subject of care) and the dispenser. The ability to record a comment where
assessments of prescriptions are undertaken might also be part of this record.
[SOURCE: ISO/TS 19256:2016, 3.10]
3.5
dose instructions
instructions pertaining to the medication, which describe the amount of medication per dose, method
of administration, the frequency or interval of dose, associated instructions for dosing or skipped doses,
and other associated parameters necessary for appropriate administration of the medication
[SOURCE: ISO/TS 17251:2016, 2.1]
3.6
drug-related problem
occurrence related to the drug therapy of the patient which (can) lead to a suboptimal outcome of the
treatment
2 © ISO 2020 – All rights reserved

3.7
electronic health record
repository of information regarding the health of a subject of care, in computer processable form
[SOURCE: ISO/TR 20514:2005, 2.11, modified — Note 1 to entry has been deleted.]
3.8
identifier
sequence of characters, capable of uniquely identifying that with which it is associated, within a
specified context
[SOURCE: ISO/TS 19256:2016, 3.15]
3.9
knowledge base
facts, information and skills acquired through research, experience, reasoning or education on a
specific topic as a set of declarative, hierarchical organization of such statements, and relationships
between declarative statements, which serves as the underpinning of decision support systems
[SOURCE: ISO/TS 19256:2016, 3.19 modified]
3.10
medicinal product
substance or combination of substances that may be administered to human beings (or animals) for
treating or preventing disease, with the view to making a medical diagnosis or to restore, correct or
modify physiological functions
Note 1 to entry: A medicinal product may contain one or more manufactured items and one or more
pharmaceutical products.
Note 2 to entry: In certain jurisdictions a medicinal product may also be defined as any substance or combination
of substances which may be used to make a medical diagnosis.
Note 3 to entry: Medicinal Product MPID XXXX87456 Slaapdiep tablet / Slaapdiep20 mg tablets National – has a
name dedicated to a specific jurisdiction (the code number is just an illustration, not a real identifier).
[SOURCE: ISO/TS 19256:2016, 3.24]
3.11
medicinal product dictionary
consistent representation of medication concepts (set of identifiers) at various levels of detail and with
meaningful relationships between the concepts, in order to support use cases in healthcare in which
medication plays a role
[SOURCE: ISO/TS 19256:2016, 5.5, modified]
3.12
pharmaceutical product
qualitative and quantitative composition of a medicinal product in the dose form authorized for
administration by a regulatory authority, and as represented with any corresponding regulated
product information
Note 1 to entry: A medicinal product can contain one or more pharmaceutical products.
Note 2 to entry: In many instances, the pharmaceutical product is equal to the manufactured item. However,
there are instances where the manufactured item undergoes a transformation before being administered to the
patient (as the pharmaceutical product) and the two are not equal.
[SOURCE: ISO/TS 19256:2016, 3.30, modified — Note 3 to entry has been deleted.]
3.13
prescribing
process of creating a prescription
[SOURCE: ISO/TS 19256:2016, 3.33]
3.14
prescription
direction created by an authorized healthcare person, to instruct a dispensing agent regarding the
preparation and use of a medicinal product or medicinal appliance to be taken or used by a subject of care
Note 1 to entry: The term “prescription” alone is best avoided as it is colloquially used at random for the following
terms: new prescription message, prescription set and prescription item. Further, it is also used to describe a
prescription form. The use of the terms prescription set, prescription item and new prescription message where
appropriate is recommended.
[SOURCE: ISO/TS 19256:2016, 3.34]
3.15
decision rules
logic used to represent the facts to support a logical decision based upon knowledge
[SOURCE: Handbook. Guide to the principles and desirable features of clinical decision support systems,
Council of Standards Australia, Sydney 2007]
3.16
substance
matter of defined composition that has discrete existence, whose origin may be biological, mineral or
chemical
Note 1 to entry: Substances can be single substances, mixture substances or one of a group of specified substances.
Single substances are defined using a minimally sufficient set of data elements divided into five types: chemical,
protein, nucleic acid, polymer and structurally diverse. Substances may be salts, solvates, free acids, free bases
or mixtures of related compounds that are either isolated or synthesized together. Pharmacopeial terminology
and defining characteristics will be used when available and appropriate. Defining elements are dependent on
the type of substance.
Note 2 to entry: Discrete existence refers to the ability of a substance to exist independently of any other
substance. Substances can either be well-defined entities containing definite chemical structures, synthetic (i.e.
isomeric mixtures) or naturally occurring (i.e. conjugated oestrogens) mixtures of chemicals containing definite
molecular structures, or materials derived from plants, animals, microorganisms or inorganic matrices for which
the chemical structure may be unknown or difficult to define. Substances may be salts, solvates, free acids, free
bases and mixtures of related compounds that are either isolated or synthesized together.
[SOURCE: ISO/TS 19256:2016, 3.41]
4 Abbreviations
For the purposes of this document, the following abbreviations apply.
CDS clinical decision support
CDSS clinical decision support systems
EHR electronic health record
HL7 Health Level Seven
ICD international classification of diseases
4 © ISO 2020 – All rights reserved

ICH international council for harmonization of technical requirements for
pharmaceuticals for human use
ICPC international classification of primary care
ICSR individual case safety report
IDMP identification of medicinal products
LOINC logical observation identifiers names and codes
MPD medicinal product dictionary
S[m]PC summary of product characteristics
SNOMED-CT systematized nomenclature of medicine – clinical terms
5 Positioning of a CDS knowledge base
5.1 Knowledge in healthcare
In healthcare, there are a lot of different processes that can be supported by CDS. ‘CDS’ is therefore a
broad term that includes all kinds of support for enhancing health-related decisions and actions, with
pertinent, organized clinical knowledge and patient information to improve health and healthcare
delivery.
Examples are CDS for overall efficiency, identifying disease early, aid in accurate diagnosis, for preventive
care, for treatment or monitoring and follow-up, or for optimization of drug therapy from different
perspectives like quality, cost-efficiency or preventing drug-related problems. CDS for optimising drug
therapy often support the check for known drug allergies of patients, comparison of drug and diagnostic
test results to ensure that the right drug at right doses are prescribed, alerts in case of drug–drug
interactions, suggest medical alternatives, drug doses, routes, and frequencies, duplicate orders.
5.2 Knowledge for drug-related problems that cohere with the intended drug use
As mentioned in 5.1, one of the scopes of a CDS can be to prevent drug-related problems.
In literature, there are different descriptions of what belongs to ‘drug-related problems’. Mostly issues
like adverse reactions, drug choice problems, dosing problems, drug use problems and interactions are
mentioned. Others classify drug-related problems as ‘intrinsic’ (belonging to the drug) or ‘extrinsic’
(errors concerning prescribing, transcription, dispensing, administration [including non-compliance])
and ‘across settings’ (errors occurring on the interface between different healthcare settings), with
several sub divisions per class). This shows that these definitions are ambiguous.
For this document, a general definition of ‘drug-related problems’ is chosen which has its focus on
problems once a drug has been chosen, in any domain of prescribing, dispensing, administering of the
drug and monitoring the patient.
A drug-related problem is an occurrence related to the drug therapy of the patient which (can) lead
to a suboptimal outcome of the treatment. The aim of detecting drug-related problems is firstly to
minimize the risk of unintended harm or discomfort associated with the use of a product and secondly
to maximize the effectiveness of the drug used by the patient. This includes not only rules about how to
optimize the therapy of the drug once it will be used, but also recommendations if the drug itself is non-
optimal (either obsolete, or not effective enough given the patients’ characteristics).
This definition has its focus on drug-related problems that cohere with the intended use of a drug.
Aspects like choosing the right drug according to guidelines (efficacy) and patient coaching for the
correct usage are not included in this definition.
Beside drug-related problems, also the costs of a medicinal product can be a real issue. If there are
therapeutically equal choices between medicines, the costs for the patient can influence the choice. If
the developer of a knowledge base would like to take this into account, this should be clearly separated
from the knowledge that deals with the drug-related problems. In order to distinguish which outcome of
a rule supports the optimal therapeutic usage of a drug and which outcome has just to do with the costs.
5.3 The structure of the knowledge
CDS can be expressed in four ways:
— Type one provides categorized information that requires further processing and analysis by users
before a decision can be made.
— Type two present the clinician with trends of a patient’s changing clinical status and alerts clinicians
to out-of-range assessment results and intervention.
— Type three use deductive inference engines to operate on a specific knowledge base and automatically
generate recommendations based on changing patient clinical condition, with the knowledge and
inference engines stored in the knowledge base. These systems require computer readable rules
and an underlying computer electronic health record system that is also computer processable.
— Type four use more complex knowledge management and inference models than the other three
decision support types. These systems include case management reasoning, neural networks, or
statistical discrimination analysis to perform outcome or prognostic predictions.
The focus of this document is on a knowledge base that contain rules which are assessed by a team of
experts, based on criteria to ‘digest’ the general references, handbooks, guidelines or whatever sources
are chosen, into useful rules (type three).
The focus of this document is depicted in Figure 1.
NOTE Depicted in grey is within the scope of this document.
Figure 1 — Knowledge base for drug-related problems to be used in rule-based CDSS
6 © ISO 2020 – All rights reserved

5.4 Knowledge base in relation to the healthcare information system
5.4.1 Introduction
The knowledge base (see Figure 2) is the basis for a CDSS to be used in healthcare. The CDSS uses drug
data (medicinal product dictionary, MPD) and patient information (electronic health record, EHR) and
is part of (or at least linked to) the clinical or pharmacy information system.
Figure 2 — The knowledge base in relation to the prescribing/dispensing modules
(computerized physician order entry system and pharmacy information systems, the clinical
practice cycle, and the regulation process cycle)
5.4.2 Relation with EHR
For rules that aim to detect/prevent drug-related problems, it is important to include patient data from
the EHR, including the medication record, dispense record and/or medication administration record
(eMAR). For example, if there is a drug choice problem because of a wrong drug for a certain disease, it
is necessary to know the disease of the patient.
This means that a knowledge base has a relationship with the EHR such that the EHR uses some of the
knowledge base's information. The data used by the EHR is described in 6.8.
For a proper outcome of a rule, the EHR needs to be accurate. Inaccurate or incomplete patient data can
lead to false positive decision support (i.e. irrelevant advice) or false negative decision support (i.e. no
advice for patients who are at risk). Frequent inaccurate alerts can lead the clinicians to ignore all of the
CDS advice. The problem of knowledge maintenance is important for all types of CDS, not just the alerts
and reminders. For this reason, it is important to monitor the accuracy of the patient’s record and to
address problems encountered.
To ensure the link between the EHR and the knowledge base, both should use the same controlled
vocabulary.
5.4.3 Relation with medicinal product data
A knowledge base to be used in medication processes, should be based on the Medicinal Product
Dictionary (MPD) of that country or jurisdiction. The (groups of) medicines mentioned as a trigger for
or as a variable in the rule have a direct link to the identification in the MPD.
Through the MPD, the knowledge base has also a link to the international standards (i.e. IDMP). See 6.6
for a more detailed description of the linkage to the MPD or IDMP.
5.4.4 Relation with a CDSS
As mentioned in 5.4.1, CDS consists of a knowledge base and the CDSS, which is the program that
combines that knowledge with patient specific information base and a communication mechanism
towards the user of the system. Both parts are distinct, but they are tightly connected.
On the one hand, all information in a knowledge base needs to be usable in CDSS. For example, if a
rule describes that for a certain drug for creatinine clearance between 30 ml/min/1,73 m and 50 ml/
min/1,73 m the dosage should be reduced to 50 %, the rule has to include the codes for creatinine
clearance, but the CDSS should be able to search and find the creatinine clearance of the patient (if
available) based on this rule.
On the other hand, some of the functions of a CDSS should be fed by the knowledge base, although
not all of them. For example, where the ‘five rights’ as described in Clause 0.2 mention presenting the
information in the right format as an alert and at the right time in the workflow, this demands that a
CDSS support that there can be a pop-up after the right trigger but it demands from the knowledge base
attributes in the rules that tells whether this rule should be a pop-up or not, and the trigger-moment in
the workflow.
6 Requirements for the development of a knowledge base
6.1 Introduction
Optimal decision making by healthcare professionals starts with a knowledge base that is relevant to
the information needs of the users. This clause describes key points for such a knowledge base, that
helps to develop a knowledge base that meets this need.
6.2 The governance of a knowledge base
Developing a knowledge base that is relevant, evidence based and up to date, is a huge task and requires
substantial amounts of resources. It requires an ongoing process with an appropriate governance
infrastructure, for which resources are indispensable. In this light, the organization that develops a
knowledge base shall have the following characteristics:
— Shall be a centralized organizer, such as an academic unit or a professional organization or association
with staff to serve as the driving force to assemble the panel and disseminate information.
— Shall make sure that the decision rules are assessed by a consensus panel of experts to create and
maintain a standard set of rules, with oversight by an organization that can ensure that the process
is transparent, systematic, evidence-based and that has the resources to do so; this means that the
development and maintenance of a knowledge base is preferably hosted by a national or scientific
organization. Key elements for developing trustworthy clinical recommendations include that
relevant stakeholders are involved. Relevant stakeholders are at least experts with a background
in clinical experience in relevant clinical subspecialties and health IT, as well as experts in clinical
pharmacology, pharmacokinetics, pharmacoepidemiology and medication safety.
— Governance rules shall be defined for the expert panel which assesses rules: the appointment process,
terms of membership, procedural rules (e.g. voting policies and procedures), the framework for
executing the steps involved in grading recommendations, policies for managing potential conflict
8 © ISO 2020 – All rights reserved

of interest, and the policies and procedures of a comprehensive and transparent rule selection
process.
The principles and processes that should be considered by developers of knowledge bases in support
of proper application of international healthcare terminology standardization are outlined in
ISO/TR 12309 and should be respected.
6.3 Structure of the rules
As mentioned in Clause 1, the scope of this document is the requirements for a knowledge base to be
used in rule based CDSS. This means that the knowledge base shall be suitable for or shaped as ‘rules’.
See Annex B for an example. Concerning the structure of the rules, the following is applicable:
— The structure of the rules shall be flexible in order that no limitation in the amount of patient data
can be included.
— The rules should be published in a structured/standardized format, so that they can be used by
software systems.
6.4 Scoping of the knowledge base content
Define the scope when developing a knowledge base: covering many types of drug-related problems is
tempting, but can soon become overwhelming. At least the next categories shall be considered (these
categories are overlapping):
— The type of target users: healthcare professionals (e.g. physicians, pharmacists, nurses), patients,
patient environment (e.g. inpatient, outpatient, post-acute care) or any combination thereof.
— The type of drug-related problems: drug-drug interactions, contraindications, allergy, dose
checking, duplicate therapy, checking of laboratory values, or another kind within the whole field of
drug-related problems.
— The type of data the rules will be based: just the characteristics of the medicine or medication data
combined with patient data (which is described more in detail in 6.8). The first category (rules
based on the characteristics of the medicine) means rules that are just based on properties of the
medicine, apart from the situation of the patient. Whether this type of rules can be developed,
depends on whether these data are included in the Medicinal Product Dictionary or can be directly
derived from the IDMP data. See Annex A for the data concerning approved indication (including
paediatric use) and adverse effects that are available in IDMP.
EXAMPLE Rules just based in the characteristics of the medicine are rules that detect off-label use or
whether a symptom can be an adverse effect of a medicine.
Scoping decisions shall be made transparent for the target users of the knowledge base.
6.5 Evidence for the rules
An organization that develops a knowledge base, shall decide on which kind of data or evidence the
rules will be based. This means the following:
— Decision rules shall be based on the best current evidence available. This can vary from case reports
to randomized clinical trials, meta-analyses, and practice guidelines or knowledge that is already
assessed internationally that meet standards of quality. Information that has a certain legal status,
like the SPC, should be taken into account in that process. Adopting rules from other organisations
who meet the requirements of this technical specification is also a possibility. The developers of a
knowledge base shall decide which types of evidence and literature will be included and shall make
these decisions transparent for the knowledge base users.
— Decision rules may include consensus opinion of the experts who assess the rules. Use of expert
advice is particularly important because the quality of evidence can differ between the topics
for which a decision rule will be developed. Consensus opinion of experts shall not be instead of
evidence, but added to the evidence to assess the clinical relevance of it.
See Annex B for an example.
6.6 Medicinal product data used in the rules
6.6.1 Medicinal product dictionary
For the reference to medicines, the knowledge base shall refer to standardised terminology.
In case there is an MPD, the reference for the identification of medicines will be to the MPD. The MPD
should be based on ISO/TS 19256, which in its turn is based on IDMP.
Around the world there are many knowledge bases for drug-related decision support in use. Some will
be linked already to existing MPDs. Maybe these MPDs do not already completely adhere to IDMP. In case
a knowledge base developed according to this document will be linked to an MPD that is not completely
IDMP compatible, the requirements for the developing the knowledge base are still valid and relevant.
The ‘would be’ situation is that the knowledge base is linked to an MPD based on IDMP. As described in
ISO/TS 19256, there can be a migration period for existing MPDs to comply with IDMP. The next best
situation is that a knowledge base is linked to an
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.