Isolated systolic hypertension in older patients diuretics (preferred), dihydropyridines

Transcription

1 Hypertension encoded Guideline 2 (Based on the hypertension guideline. Simplified (not all contraindications, relative contra-indications, and relative indications are specified). Drug interactions simplified. Contains 2 recommendations). 4) If the patient is not at the goal blood pressure, the response to the initial drug choice for hypertension is inadequate after reaching the full dose, and the patient is tolerating the first choice well, then add a second drug from another class. If a diuretic is not chosen as the first drug, it is usually indicated as a second-step agent because its addition will enhance the effects of other agents. The possible drug classes are: ACE I beta blockers (distinguish between drugs that have intrinsic sympathomimetic activity (ISA) and those that do not) calcium channel blockers (distinguish between dihydropyridines and non-dihydropyridines, and between long-acting (long duration) dihydropyridines and non-longacting dihydropyridines) diuretics (distinguish between thiazide-, loop- and potassium-sparing diuretics) The following compelling indications exist (unless contra-indicated): Indication Drug Therapy Diabetes mellitus (type 1) with proteinuria ACE-I Heart failure ACE-I, loop-diuretics Isolated systolic hypertension in older patients diuretics (preferred), dihydropyridines Myocaridal infarction non-isa beta-blockers Myocaridal infarction with systolic dysfunction ACE-I Patient does not have co-morbidities that are diuretics, beta-blockers compelling indications of other antihypertensives. /******************************************************************************** The following relative indications exists (unless contra-indicated). Indication Drug Therapy Diabetes mellitus (type 1) with proteinuria ACE-I (preferred), calcium channel blockers The following relative contraindications exist: Indication Drug Therapy Diabetes mellitus (type 1) with proteinuria beta blockers ***************************************************************************/ The following contraindications exist: Indication Drug Therapy asthma or chronic airway disease Beta-blockers second- or third-degree heart block Beta-blockers, non-dihydropyridine

2 Pregnancy ACE-I The following drug interactions exist* Drug class Evidence based combinations Evidence based combinations to avoid ACEI potassium-sparing diuretics Beta-blockers thiazide diuretics non-dihydropyridines Dihydropyridines beta-blockers non-dihydropyridines Non-dihydropyridines beta-blockers, dihydropyridines * This representation of drug interactions is based on interpretation that the VA physicians gave to the drug interactions that were specified in Table 11 of the original guideline. Evidence based combinations are drugs that, when taken together, have synergetic effects. Evidence based combinations to avoid are groups of drugs that should not be taken together. We will make the following assumptions for this example: 1) The history of what other drugs were previously given to the patient is irrelevant. 2) The patient is on a single drug and another drug class will be added. 3) The patient is already taking the maximum dose of the drug 4) The response to the first drug choice for hypertension is inadequate after reaching the full dose, and the patient is tolerating the first choice well 5) There is no need to check if a specific patient is allergic to a specific drug. 6) It will be enough to suggest a drug class; it is not necessary to suggest a specific drug and dose. 7) Never give a contra-indicated drug to a patient. 8) Never choose as a second drug a drug that is in the "Evidence-based combinations to avoid" list. 9) compelling indications outweigh Evidence-based combinations and relative indications. Please model the decision to add another antihypertensive drug in a modular way, which will take into account that there may be other indications, contraindications, and drug interactions that may later be added into the model. The model should be constructed in such a way that will enable adding these without changing the way the decision model is represented. The guideline model should show not only one possible drug set that can be given, but show sets of drugs, based on contraindications, relative contraindications, Evidence-based combinations, compelling indications, and relative indications. For example: One set can be the set of drugs that can be given (not contraindicated or a Evidence based combinations to avoid), have compelling indications and are Evidence-based combinations. Another set can be the set of drugs that can be given (not contraindicated or a drug partner to avoid) and have compelling indications but are not Evidence-based combinations. A third set can be the set of drugs that can be given (not contraindicated or a drug partner to avoid), do not have compelling indications and are not Evidence-based combinations. There is no need to model the criterion the checks whether the BP goal is maintained, the patient is taking the full dose, the patient is taking only one anti-hypertensive drug, the response to the initial drug choice for hypertension is inadequate after reaching the full dose, and the patient is tolerating the first choice well. (dimensions 1, 2, 3, 9, 10) 5) The goal of the (new) anti-hypertensive treatment discussed in recommendation (1) is to control blood pressure to < 140/90 mm Hg (systolic BP below 140 mm Hg and diastolic BP below 90 mm Hg). For patients with Diabetes Mellitus, the blood pressure should be controlled to below

3 130/85 mm Hg. Blood pressure should be controlled to 125/75 in patients with proteinuria in excess of 1 gram per 24 hours, and to 130/85 mm Hg in patients with proteinuria with at most 1 gram per 24 hours with whatever anti-hypertensive therapy is necessary. (dimensions 5, 10) Choosing a second drug GLIF:

4 See Error! Reference Patient state step See Error! Reference NESTED Action step Case step Choice step

5 Figure 1. The top-level Algorithm. Not shown in the figure are the name and first_step slots of the algorithm object. Algorithm: 1) Queries for specific anti-hypertensive medications and see if the patient is on them. Each query returns the concept that stands for the medication, or null. 2) Create a list of current anti-hypertensive medications. 3) Queries for specific indications and see if the patient has them. Each query returns the concept that stands for the indication, or null. 4) Create a list of current comorbidities. 5) Taking the concept relationship medical knowledge, and the patient s medications and comorbidities as inputs, compute medical knowledge relevant to the patient: a. List of contraindicated medications for the patient b. List of compelling medications for the patient c. List of relatively-contraindicated medications for the patient d. List of relatively-indicated medications for the patient e. List of good drug partners for current drug f. List of bad drug partners for current drug 6) If the patient does not have any compelling medications, add to them a list of Diuretics and Beta-Blockers 7) For each drug there are 4 identical rules for and against choosing it. The rules break the drugs into 4 categories: a. Contraindicated drugs or a bad drug partner of first drug b. Not (a) and (compelling drug or a good drug partner of first drug) c. Relatively indicated d. Relatively contra-indicated Representing contraindications and drug interactions medical knowledge: Concept_Relationships: Medication has-contraindication Indication Medication has-compelling-indication Indication Medication has-relative-contraindication Indication Medication has-relative-indication Indication Medicaiton1 is-a-good-partner-of Medication2 Medicaiton1 is-not-a-good-partner-of Medication2 The Queries (of medications and indications) - Specify a complex data item from which we query - Chooses latest element that is current

6 The GEL expression used to extract the Asthma Concept from the Asthma Query_Result, and assign it to the AsthmaIndication variable, is: selectattribute("service_cd", latest asthma where time of it >= now) Unite comorbidities into one list {AsthmaIndication, DMindication, heartfailureindication, systolichypertensionindication, MIIndication, MIWithSystolicDysfunctionIndication, chronicairwaydiseaseindication, seconddegreeheartblockindication, thirddegreeheartblockindication, pregnancyindication} It forms a list of concepts from the single concepts. This expression is written in GEL. Figure 2. A contraindication concept relationship. ACEI and Pregnancy are concepts, defined by UMLS codes The next step is to extract from these contraindication relationships the relationships that involve indications that the patient has (are in the comorbidities list of concepts). This is done by the Assignment_Actions of the action step Get patient-specific medical knowledge. These Assignment_Action use GEL expressions to assign the patientspecific knowledge to variables. For example, Assign contraindicated drugs for the patient assigns to a variable called contraindicateddrugs a GEL expression that computes the list of drugs that are contraindicated by the patient s comorbidities. The GEL expression used is: selectattributefromlist("concept_from", contraindicationlist where (containsvalues(comorbidites, selectattributefromlist ("concept_to", contraindicationlist)) )) containsvalues accepts two list arguments, l 1 and l 2. The function returns a list of Booleans of length equal to the length of l 2. The value of the Boolean in position i of the returned result is TRUE if in position i of l 2 there exists a value that is contained in l 1.

7 By now we have all the patient-specific information that is needed to make the decision on a second drug choice: contraindications, compelling indications, relative indications and contraindications, and good and bad drug partners that all apply to the patient s current comorbidities and current anti-hypertensive medications. Figure 3. A didactics for choosing appropriate second drug Figure 4 shows the 4 rules for selecting ACEI. Figure 4. the rule in choice for selecting ACEI The details of the strict rule-in are shown in Figure 5

8 Figure 5. The details of the strict rule-in The proposeddrug variable is assigned with an ACEI concept using Get_Knowledge, as shown in Figure 6.

9 Figure 6. Assigning an ACEI concept to the variable proposeddrug Finally, after choosing a drug, an appropriate Action is carried out to prescribe the appropriate medication, as shown in Error! Reference source not found.. Each of these actions has a medically oriented action specification task. Error! Reference source not found. shows the details of ordering an ACEI.

10 EON Evaluate_Choice_Step used to evaluate new drug to prescribe. This step has a list of candidates, and a combined rule_in and rule_out that acts together on all the candidates. The candidates are Activity_Specifications, which can be Prescribable_Items, Activity_Procedure, or Drug_Usage classes. For hypertension, we work at the Drug_Usage level, which deals with drug classes. Representing drug classes Each drug class contains information about absolute_containdications, compelling_indications, relative_indications, relative_containdications, bad_interactions, synergetic_effects, complications, synonyms, and the preferred formulary drug in that drug class. All of these attributes are of type concept_relation or one of its sub-classes. Drug_Medical_Condition_Relation, and Drug_Drug_Interaction. In Drug_Medical_Condition_Relation the attributes are: Drug (Medication_Class), dosetype and age limit. In addition, in the subclasses Drug_Indication_Relation and Drug_Contraindication_Relation there is the Medical_Conditions_Class that represents the indication or contraindication, and in the sub-class Drug_Complication_Relation there is a Diagnostic_Class that represents the complication. The Drug_Drug_Interaction class contains the two drugs (Medication_Class) and the interaction type (i.e., drug_partners_to_avoid, drug_partner). The Medication class can be a Drug_Categories_Metaclass or a Medications_Metaclass. The Diagnostic_Class can be a Diagnostic_Term_Metaclass or a Diagnostic_Procedures_Metaclass. A Medical_Conditions_Class specifies the name of the condition, its ICD-9 code, the disease category to which the condition belongs, and the body-system that is affected.

11 Now back to the description of the Evaluate_Choice_Step. For all the candidate drugs, there is one rule in and one rule out. One rule out is: find contraindicated drugs in candidates. Other rule outs consider bad drug partners of the first drug. Rules are expressed as PAL queries that has a range and a statement, expressed in PAL s first order logic. For example, the statement for the above find contraindicated drugs in candidates ruleout is: The statement is: (find-all?med_class ( exists?evaluateadd (and (name?evaluateadd "Evaluate Add to Monotherapy")) (candidtes?evaluateadd?med_class) (exists?concept_relation (and (absolute_contraindications (drug_class_name?med_class)?concept_relation) (or (exists?contraindication (and ( contraindication?concept_relation?contraindication) (exists?problem (and (isa-classname (domain_term?problem) ) (subclass-of (coerce-to-class (domain_term?problem)) contraindication))))) (exists?derived_contraindication (and ( contraindication?concept_relation?derived_contraindication) (is-derivable?derived_contraindication)))) ))) The statement uses variables, functions, and relations. Variable names start with a?. The range of the variables is defined as follows. Functions accept a single variable as a parameter and return a result. For example, the function (domain_term?problem) returns the value of the domain_term attribute of the?problem instance. Relations return true is the relation holds and false otherwise. For example, the relation (name?evaluateadd"evaluate Add to Monotherapy") returns true if the name slot of the?evaluateadd frame which is an Evaluate_Add_Step has a value that is equal to "Evaluate Add to Monotherapy". (defrange?evaluateadd :FRAME Evaluate_Add_Step) (defrange?problem :FRAME Note_Entry) (defrange?med_class :FRAME Drug_Usage) (defrange?contraindication :FRAME Medical_Conditions_Class) (defrange?derived_contraindication :FRAME Diagnostic_Term_Metaclass) (defrange?concept_relation :FRAME Drug_Contraindication_Relation) Following is an explanation of the above PAL criterion that finds contraindicated drugs in candidates.

12 Find all candidates, which are Drug_Usage instances that will be referred to as?med_class, of the Evaluate_Add_Step whose name is "Evaluate Add to Monotherapy, where the candidates have contraindications that are absolute contraindications and 1) The contraindications of the candidates are medical conditions that are documented as Note Entries in the patient s record. The note entries refer to domain terms that are subclasses of the medical condition, including the medical condition itself, OR 2) The contraindications of the candidates are diagnostic terms that are derived contraindications that are derivable. find-all is a function. It accepts one argument, of the form?med_class(a), where A is a where statement that defines the values of the?med_class that must hold for it to be returned by the find-all function. A is of the form (exists?evaluateadd B). This is a relation that returns true if there exists an?evaluateadd whose values are defined by B. B is a very complex expression: (and (name?evaluateadd "Evaluate Add to Monotherapy") (candidates?evaluateadd?med_class) (exists?concept_relation (and (absolute_contraindications (drug_class_name?med_class)?concept_relation) (or (exists?contraindication (and ( contraindication?concept_relation?contraindication) (exists?problem (and (isa-classname (domain_term?problem) ) (subclass-of (coerce-to-class (domain_term?problem)) contraindication))))) (exists?derived_contraindication (and ( contraindication?concept_relation?derived_contraindication) (is -derivable?derived_contraindication))))) It is of the form (and A B C) A The value of the name slot?evaluateadd should be "Evaluate Add to Monotherapy" B?med_class is a value of the candidates slot of?evaluateadd C Exists?concept_relation, of type Drug_Contraindication_Relation where D D (and (absolute_contraindications (drug_class_name?med_class)?concept_relation) // the?concept_relation is an absolute_contraindications relation that involves value of the // drug_class_name slot of?med_class AND (or (exists?contraindication

13 // there is a Medical_Conditions_Class which we will refer to as?contraindication where (and ( contraindication?concept_relation?contraindication) // the?concept_relation contains the?contraindication // Medical_Conditions_Class as a contraindication AND (exists?problem // there is a Note_Entry which we name?problem, where (and (isa-classname (domain_term?problem) ) // the value of the domain_term attribute of the?problem note entry // is a class name AND (subclass-of (coerce-to-class 1 (domain_term?problem))?contraindication))))) // the domain_term class is a subclass of the contraindication (exists?derived_contraindication // OR there is a Diagnostic_Term_Metaclass which we call (since it serves as a) //?derived_contraindication where (and ( contraindication?concept_relation?derived_contraindication) // the?derived_contraindication is a contraindication referenced by the //?concept_relation AND (is -derivable?derived_contraindication))))) // the?derived_contraindication is derivable The same PAL expression can be simplified as below: (find-all?med_class (and (exists?add ;; is a candidate (and (label?add "Evaluate Add to Monotherapy") (candidtes?add?med_class))) (exists?concept_relation ;; there is a contraindication (and (absolute_contraindications (drug_class_name?med_class)?concept_relation) ;; contraindication is mapped to a known problem or can be derived (or (exists?problem (and (isa-classname (domain_term?problem) (subclass-of (coerce-to-class (domain_term?problem)) (contraindication?concept_relation)))) (is-derivable ( contraindication?concept_relation)))) ))) EON can also model the second drug choice as PRODIGY does. And there is also a third way, by using an action step with a task that presents the information of drug-indication and drug-drug relationships of the different drug candidates to the user. Such an action step has a task of Evaluate Start Activity.. Following the Evaluate_Choice_Step there is a consultation guideline: 1 This function turns a String into a Protégé class

14

15 Representing goals:

16

17 PRODIGY Goal BP: There are 3 subguidelines for adding a second drug, one for each different BP goal. An example of one of the subguidelines follows. It has the following attribute values: Trend_prompt: BP >= 140/90

18 This is a prompt to the user, which answers yes or no. Greyed_out_condition: Hyp <140/90 most recent, which is and AND combination of a criterion on SBP and a criterion on a DBP. The criterion on the SBP is shown below. Second drug choice The top-level guideline has an EPR_Summary slot which holds the following value:

19 For each BP goal there is a different subguideline. Following is an example of the algorithm for the subguideline for goal BP of < 140/90. As shown below, each first drug has a different scenario. Each first drug has a different scenario. For example, the scenario of add to ACE inhibitor is defined by the flowing precondition:

20 The drug regimes are enumerated as different prescriptions, containing multiplex and emis codes. The alternative preconditioned actions of adding a second drug to a first drug are organized around the first drug scenario in the same order for all scenarios, which helps in managing complexity. Drug partners to avoid are not represented as options and simply cannot be chosen. For each action there are rule in/out and greyed in/out condition. The example below shows a rule out for giving ACEI as a second drug, is if the patient is pregnant, which is a contraindication to giving ACEI.

21 A compelling indication for giving ACEI can be diabetes with protenuria, which is modeled as a rule in.

22 A relative indication is modeled in a similar way, using greyed-in condition. A relative contra-indication is modeled in a similar way, using greyed-out condition. Drug partners are modeled by indicating the second drug as the preferred option for a good drug partner.

23 After the user selected a second drug, a start regime action is executed, for example: Decision Model in PRODIGY Criteria: Presence/absence of an abstract term (with a Read code) N-ary criteria (OR-ed, AND-ed, XOR-ed)

24 Asbru The second drug decision in the hypertension guideline is handled in Asbru by a function call to an external function. The medical knowledge of drug-indication and drug-drug is also external to the guideline encoding and is used by the function. The function is called DrugReasoner. It returns the name of the proposed second drug. It receives two parameters of type string that represent the indication and first-drug of the patient-record. The patient-record is a record that holds two strings: indication, and first-drug that are entered by the user. Representing the BP Goals:

25 The plan Hypertension-treatment has an intention of type achieve overall-state of normal of the parameters systolic-blood-pressure and diastolic-blood-pressure. The time range for achieving this intention can also be specified. For example, they specify that the latest start time (start-shift latest) of achieving this constraint should be 1 month after the activation of the plan. Since the BP is a parameter, new values can be entered at any time. To explicitly demand regular input, a "any-repeat-specification" can be given in the raw-data-def of numerical-systolic-bloodpressure and numerical-diastolic-blood-pressure to specify the times at which the user is expected to enter new data. When abstracting qualitative abstractions from numerical raw data, you take two-step in Asbru. First, you define a "qualitative scale" (e.g., blood-pressure), which declares all the values, such a entity can take. In our case, these are high and normal only, in practice at least low should be added. Secondly, you define a qualitative parameter of that type (i.e., blood-pressure) and detail the limits between the qualitative regions for various contexts. There must be one limit more than qualitative regions of course. Through this two-step process, qualitative parameters obtained from different sources can be compared, given their definition refers to the same qualitative scale. The specification defines a qualitative-scale-def called blood-pressure, that has two values: normal and high. The parameters systolic-blood-pressure and diastolic-blood-pressure are of the qualitative blood-pressure type. They assume a value of normal or high, abstracted from the numerical-systolic-blood-pressure and numeric-diastolic-blood-pressure (parameters of type pressure, measured in the units of mmhg and entered by the user), depending on context. For example, in the context of diabetes-mellitus = true and proteinuria = high (the values are entered by the user) the normal systolic-blood-pressure is <= 130 mm Hg and the normal diastolic-blood-pressure is <= 85 mm Hg. The hypertension guideline is handled in Asbru by a function call to an external algorithm. The medical knowledge of drug-indication and drug-drug is external to the guideline. PROforma Goal:

26 Figure 1 : The component tasks of the top level plan, Hypertension. Figure 2 : The two tasks contained within the Assess response plan. Goals are currently treated in PROforma as attributes of plans. If, whilst a plan is in progress, the logical expression described in that plan s goal slot becomes true, the plan will transit to the performed state. Any tasks within the plan at that point in time will be terminated. In this model, the plan Assess response has the goal : DBP < targetdbp and SBP < targetsbp

27 The plan is set to cycle continuously until that goal is met. Thus the two component tasks, the action Await adequate response and the enquiry Monitor BP, are repeatedly executed until the plan s goal is met. This may not be medically or logistically plausible (there ought perhaps to be a time limit on the how long the one waits for a satisfactory response before trying another drug), but illustrates the way goals are currently use in PROforma. DBP and SBP are integers, entered by the user, which represent the patient s latest BP values in mmhg. TargetDBP and targetsbp are integers that are set by the targetbp decision Decision Task. This decision task receives the comorbididities of the patient, which are entered by the user. The user is asked about each possible comorbidity and prompted to give the possible value, which is usually yes or no, but for Age_group it is younger or older and for Proteinuria it is none, < 1 g/24 h, or >1 g 24 h. The decision on the TargetDBP and targetsbp is done by a set of if-then-else statements that determine the values of the target blood pressures should be standard, medium, or low, depending on comorbidities. The post-condiiton of the decision task sets the target blood pressures with the appropriate numerical values for standard, medium, or low. For example, the argument for the candidate standard is: candidate :: Standard ; argument :: for, ( Proteinuria = None and Type_1_Diabetes = No ) ; recommendation :: Netsupport( Target_BP_decision, Standard ) >= 1 ; The argument for the candidate Standard is that there is no proteinuria and there is no diabetes. In that case, the Netsupport for the Target_BP_decision being equal to standard is >= 1 (true). Then, the postcondition of the Target_BP_decision sets numeric values for the TargetSBP and TargetDBP in the following way: postcondition :: TargetSBP = if( result_of( Target_BP_decision) = Standard, 140, if( result_of( Target_BP_decision) = Medium, 130, 125)) and TargetDBP = if( result_of( Target_BP_decision) = Standard, 90, if( result_of( Target_BP_decision) = Medium, 85, 75)) ; Second Drug Choice: This step is done after the queries for comorbidities and current therapy are executed, as expressed by the scheduling constraints of the Additional_drug_choice Choice: component :: Additional_drug_choice ; schedule_constraint :: completed(current_therapy) ; schedule_constraint :: completed(comorbidities) ; The PROforma decision model has the following components:

28 A variable number of candidates A variable number of arguments relating to each candidate A support mode, describing how arguments are to aggregated A recommendation rule for each candidate, describing under what circumstances that candidate is to be considered recommended A choice mode, describing whether single or multiple candidates can be simultaneously committed to. (plus a few other functions not used here) To model the decision on which second drug to add, one candidate has been created for each of the possible drug choices. The decision uses the symbolic support mode; each argument can thus be set to for, against, confirming or excluding the candidate it relates to. The candidates and corresponding arguments are listed in table 1. Compelling indications have been given the support level confirming. Contraindications have been given the support level excluding. Relative indications and contraindications have been given the support levels for and against respectively. Evidence based combinations to avoid have been given the support level excluding Beneficial evidence based combinations have been given the support level for Under the symbolic decision model used in PROforma, the number of arguments for each candidate is summed, and the number arguments against subtracted. Any arguments with a confirming support level carry an effectively infinite amount of support for that candidate, although this is overridden if any excluding arguments are true. For example, the following table summarizes the arguments for giving Non_ISA_beta_blocker as the second drug. The medical knowledge is represented as part of the decision model. Non_ISA_beta_blocker Asthma = Yes or COPD = Yes Heart_block = Yes MI = Yes Type_1_Diabetes = Yes and Proteinuria = Yes Current_Rx = Ca_blocker_non_DHP Current_Rx = Thiazide_diuretic Current_Rx = Ca_blocker_DHP_long or Current_Rx = Ca_blocker_DHP_short Current_Rx = Beta_blocker_non_ISA or Current_Rx = Beta_blocker_ISA

29 Using PROforma s syntax this is expressed as: candidate :: Non_ISA_beta_blocker ; argument :: excluding, ( Asthma = Yes or COPD = Yes ) ; argument :: excluding, ( STD_Heart_block = Yes ) ; argument :: confirming, ( MI = Yes ) ; argument :: excluding, ( Current_Rx = Ca_blocker_non_DHP ) ; argument :: for, ( Current_Rx = Thiazide_diuretic ) ; argument :: for, ( Current_Rx = Ca_blocker_DHP_long or Current_Rx = Ca_blocker_DHP_short ) ; argument :: excluding, ( Current_Rx = Beta_blocker_non_ISA or Current_Rx = Beta_blocker_ISA ) ; argument :: against, ( Type_1_Diabetes = Yes and Proteinuria <> None ) ; recommendation::netsupport( Additional_drug_choice, Non_ISA_beta_blocker )>=1 ; The decision task recommends any candidate with a net positive amount of support, and will by default select whichever candidate has the most support. The user is able to interact with the decision to review the arguments for and against each candidate and make the final selection (if the decision is set to execute manually ).