Use the information contained in this chapter and related learning activities to prepare a brief outline of what needs to be incorporated into the design and functionality of the clinical decision support system. The outline should include the following:

Question

• aim(s) of the clinical decision support system (e.g. reduce hypoglycaemic events)
• target patient population and potential users of the system
• features that will be important to the success of this particular system
• methods for evaluating its effectiveness.
What will be an ideal response?

Answer 1

Suggested response: Aim: To reduce hyper- and hypo-glycaemic events in general medical ICU patient population Target population: Patients over the age of 16 admitted to the general medical ICU Potential users: Nursing, medical, pharmacy staff Clinical decision support system features: Communication content – customisable blood glucose limits that define hyper- and hypo-glycaemia and insulin and dextrose/glucose dosing calculators are built into the system (use evidence-based CPGs to inform default values); system registers and processes blood glucose values and recommends an insulin rate based on the trend over several hours; when blood glucose values are high, recommendation is to order insulin infusion; insulin infusion order is generated; once verified order is sent to pharmacy; when blood glucose values are low, recommendation is to stop the insulin infusion and administer dextrose; if any recommendation is rejected, the system requests that the user enters a reason for why the recommendation was not followed; system sends follow-up prompt (alarm sound) at pre-defined time or time interval (which can be customised). Clinician–system interaction – the system either automatically takes values from a continuous glucose monitor then asks the user to validate the value or prompts the user to enter the patient's blood glucose value at pre-defined times or time intervals (e.g. at an interval predicted to prevent the blood glucose level from dropping below an acceptable limit; when blood glucose values are stable the intervals can be increased to a pre-set maximum interval) throughout the day; system must be in close proximity to the patient; user enters the patient's blood glucose value (and other patient information if not automated, e.g. the reason for admission, history of diabetes, weight, enteral nutrition); user accepts or rejects the system recommendation based on the overall clinical situation; if the recommendation is accepted, the user must review the order prior to sending for second sign-off; verifier must review the order prior to finalising and sending to pharmacy; if the recommendation is rejected, the user must enter a reason
for why the recommendation was not followed; user can disable or discontinue the glucose management module if not clinically appropriate; prior to commencing drug administration the user must first validate infusion rate/bolus amount. General features – patient-level blood glucose values and dosing information are stored in a database; insulin infusion orders are generated and sent to pharmacy via CPOE; reasons for not following recommendations or disabling/discontinuing glucose management module are recorded; alarm sounds are used to alert clinicians when: to enter blood glucose values, running low on insulin, to check order for insulin, a system malfunction/error has occurred. Auxiliary features – provide results including average blood glucose levels, insulin infusion rate, amount of insulin and/or dextrose delivered for pre-defined time periods (e.g. 6/12/24-hourly). Data are recorded and stored in a database and weekly performance feedback reports are generated at the unit level.