Not all problems involving the electronic health record can be addressed by the help desk or level 2 or even level 3, level 4 support. That's where physician, nurse, pharmacist, and analyst-lead committees come in. Each organization has its own governance structure in meeting schedule for these committees. When it comes to clinical decision support, alerts, reminders, configuration of order sets, there are clinical decision support committees that a hospital or health system level that are responsible for reviewing the way the clinical decision support is functioning in practice. When there are issues that arise, these committees are tasked with making a decision on how best to modify the clinical decision support to ensure that the electronic health record is helping providers provide the best care. You'll now hear more about what goes beyond the scope of the help desk, the role of CDS committees. Hi, I'm Dr. Amy Knight. I'm the Co-chair of the Clinical Decision Support Committee at Johns Hopkins. I'm going to talk today about some of the steps needed to develop a clinical decision support or CDS committee, some of the processes that committee will go through, and then an example of an alert that wasn't performing as expected in our system. When you're starting a clinical decision support or CDS committee, it's important to define the scope upfront. Will you be dealing with both inpatient and ambulatory CDS or only one or the other? Will you deal with both adult and pediatric or just one or the other? Will you be dealing with medication alerts, banners, order sets, all of which are examples of CDS? Additionally, will you be incorporating proprietary content, such as that sold by your EMR vendor or by other businesses, or will you solely be developing content on your own? You should also define the meeting frequency. You might want to meet weekly to start, and then biweekly once you're established, and there are fewer new requests coming in. You'll need to define who the members of your CDS committee will be. The member should include clinical stakeholders, most importantly, including physicians, staff, nurses, and pharmacists. Other key players will be the clinical informatics staff from your institution who will be experts of both the build for your EMR and how clinical care functions at your hospital, and also the CDS builder or analysts for your EMR. You should develop some process for users to request new CDS. At our institution, we used a three-page new request form that spelled out exactly what information we're looking for. This includes the definition of the purpose for the CDS and also the text that the user would like displayed in a new alert. The parameters for one of the alert should display need to be spelled out by the user who's requesting the CDS, such as which patients the alert should display for, and which users or providers the alert should display for. Who will the target audience be for the alert, will it appear for just providers, just nurses, or everyone? When should it display, should it display when the user opens the patient chart in the EMR? Should it display when they go to place orders? There are many other potential circumstances when the alert can display. The user requesting the new alert should also indicate what would be the appropriate color for the alert. At our institution, we use green for research and suggestions, we use yellow for care, guidance and quality-related alerts, and we use red for extremely critical alerts. The requester will also need to indicate what the appropriate actions will be in response to the alert, and they'll need to have some plan for monitoring the alert and how it performs. The committee needs to ensure that new requests meet some guiding principles. The new request needs to meet a significant need, it needs to be the only option available, it needs to be feasible within the confines of the EMR being used, and needs to target the correct audience, it needs to be intuitive to use and make good use of design principles such as color, it needs to provide a next step for the user, the user needs to be able to opt-out of the alert if it's not appropriate for them. Sometimes heart stops are appropriate. In other words, alerts that the user must respond to before he or she can move on in the system. It's always most important to make sure that the new alert won't contribute to alert fatigue, which is detrimental to user responses to all alerts. When deploying new CDS, the CDS committee will need to prioritize the build which alerts are most important to get done first and which can be done later. All new alerts should be run in the background for 1-2 weeks. This means that they'll be turned on in the live system, but users won't be seeing them, and then you can see how often the alerts are firing and for which users. Any data from this running in the background can be presented to the committee, and then the committee can decide if it's ready to be put into production for viewing or if it needs further work. It's important to communicate to your planned recipients that the alert is coming so they'll have an idea of how to respond to it. Once an alert is deployed, it's important to have some oversight of the alert, how it performs. Much of this feedback comes from users as they experience the alert, and many changes are made in response to users saying that an alert is not performing the way they think it should. Additional reports come from patient safety reports and from regular performance reviews. This is best done using a dashboard such as the one shown below, which can show user responses to various features in the alerts, such as clicking on different buttons or clicking on activity links within the alert.
