In two of my last blog posts, I have interviewed people and companies working in the support and implementation of decision support. With this blog post, I have the honor of interviewing Robert A. Greenes, MD, PhD, one of the first and leading researchers in clinical decision support (CDS) and my former CDS professor. He started as a co-developer of MUMPS in the 1960s while at Harvard Medical School and from there has been and continues to be involved in all aspects of CDS. One of his latest works has been editing and writing chapters for the first and second editions of Clinical Decision Support, The Road to Broad Adoption. He also was a practicing radiologist at Brigham and Women’s Hospital in Boston until 2007, when he became chair of the Department of Biomedical Informatics, Arizona State University. He stepped down as chair in 2014, and is still a professor at ASU as well as on the staff of the Mayo Clinic. He states that his passion is the use of information technology in health care to make "the right thing the easy thing to do.”

Bridget: In Clinical Decision Support, the Road to Broad Adoption, you define computer based clinical decision support (CDS) as “the use of information and communications technology to bring relevant knowledge to bear on the health care and well-being of a patient.” The FDA has recently released some draft preliminary guidance on clinical decision support and in that document, they have further clarified the types of CDS they consider a medical device and will regulate and for the most part only those CDS systems that use medical device sensor based input have been listed as under their regulatory purview. What are your thoughts regarding this device definition and CDS separation in the guidance? How does this affect the overall implementation and adoption of CDS systems from your perspective?

Dr Greenes: I found the document a bit confusing.  From a historical perspective, the FDA has been toying with the idea of regulating CDS since the 1970’s and 1980’s with an organized effort. They tried again in 2007/8 and this draft guidance is the latest effort. My main reaction is to their definition of what a device is. It seems as though the distinction is if medical data is sent and integrated into a CDS then it is a medical device, with an emphasis on images. In addition, this feature extraction seems to be tied to the digital output from all devices. We can reduce any analog signal to discrete digital data.

I don’t think that the device/non-device is a good line to draw for this regulatory decision.  To me the safety/criticality of the use of the product seems to be better criterion.  One example is with a ventilator where the software auto regulates air flow. This is a closed looped situation for CDS and therefore we would want to regulate these situations where there is no human intervention. However, it becomes grayer when a CDS is performing intermediate calculations. As another example, when determining genomic pathways, there is a reliance at times on machine learning and intermediate calculations. Currently this functionality is not considered a device and therefore not regulated; however, the complexity and impact of an incorrect calculation could possibly be fatal. (Note: The Clinical Decision Support Coalition has expressed similar sentiments formally to the FDA)

Should a CDS be subjected to some evaluation process before being unleashed? Yes, however, the question should be how to draw the line between a regulated versus non-regulated CDS.  My main concern has to do with the opaqueness of the recommendation with regard to what is under the purview of control by the FDA.  I am hesitant to have them regulate the decision-making process in a CDS that is more complex and usually recommending or suggesting an action by a clinician and not necessarily dictating it.

Figure 1: The Clinical Decision Making Process (Greenes, 2015)

Interestingly, in another forum in which I am involved that deals exclusively with CDS matters, the draft guidance was posted on their discussion group and there was virtually no discussion. Perhaps they don’t see this guidance as a threat to CDS development. Right now the biggest movement or area in CDS development is in data analytics and population management. The FDA is not involved in that and the guidance does not reflect that, so the CDS industry does not currently see any impact.

Bridget: Again, in your clinical decision support book, you identify five necessary components for a CDS structure: an inferencing method, a knowledge base (KB), an information model, a result specification and an application environment.  (Figure 1 shows the clinical decision making process and Figure 2 shows the CDS components and relationships)  Where do you see the patient sensor systems interfacing with those components?

Figure 2: Conceptual Model of the Components of Clinical Decision Support (Greenes, 2014)

Dr Greenes:

Figure 1 shows the typical clinical decision making process and in this process, which is actually an iterative cycle, the patient data (sensor system output) is part of the information obtained and evaluated by the user. This evaluation is based on rules or algorithms in the knowledge base, and an execution engine is responsible for the processing of the logic or mathematics or other inference model. This new state of the assessment of the patient is then used to evaluate the patient data and incorporate decision support, as a precursor to further testing or treatment. Figure 2 shows the functional components in the conceptual model of a CDS.  Figure 2 does not show explicitly the data sources. The decision support result comes from convergence of the externally sourced data and the knowledge base content interpreted by an inference method run by the execution engine. In this case the EHR is acting as an intermediary. So to answer the question, in this conceptual model of a CDS (Figure 2), the patient sensor systems are interfacing to the EHR or directly to the CDS as a separate source to the CDS. We essentially isolate the CDS environment from the source data that is provided and have the CDS act on the data in accord with the relevant knowledge in the KB to produce a recommendation.

Bridget: When we spoke before about your idea regarding the future of CDS you had talked about the provision of a ‘development sandbox’ that would allow developers to build ‘CDS’ software modules for healthcare organizations to download or distribute as needed. You had an analogy of the GPS systems being available across platforms and easily updated. What do you believe would be required to effect this vision, i.e. what would a healthcare organization or developer need in terms of underlying systems to take advantage of this type of CDS development and delivery model?

Dr Greenes:

The sandbox concept is for envisioning future CDS prototypes, models or products. It allows the testing of use cases to show the value of CDS outside of or to augment a specific EHR application. Currently, most of the data as well as CDS functionality is locked up in proprietary EHRs. However, in a particular use case, there may be a sensor reading or an application that is used by MDs not reflected in the EHR. For example, in managing a patient with chronic disease, many times the patient comes to an MD’s office to have certain physiological information measured, however, what the patient does at home with commercial sensors is often lost as a data source. Yet, ideally, that data source should be part of the database for CDS to act on.

For another example think of the ventilator management CDS referred to earlier. In that case, the device is monitoring something discrete and fairly isolated. The CDS can be integrated into the device and work in isolation.  Even in this case lab results such as arterial blood gas and electrolytes need to be considered.  There are more complex cases that depend on context, i.e., the CDS that is most relevant depends on the setting, user, and tasks being performed – e.g., in an office, on the phone, in an emergency department, or an ICU. That is where the idea of a “GPS-like” approach would be beneficial for the delivery of CDS most suitable to the particular setting.

This platform would enable invocation of CDS recommendations/suggestions without requiring specific workflow-embedding or event triggering. The invocation would be by matching of context with context attribute-indexed knowledge resources. Currently, most CDS is wedded to a specific workflow or event processing invocation model, and if we change a workflow, we have to figure out all of the places to insert or de-insert the CDS which ends up creating a lot of customization.

One idea is to envision ‘axes of context’, like a snowflake diagram which describes user setting, role, action, patient characteristics, task, and other attributes of the user as he/she does various activities. * This allows a de-coupling of the CDS to a specific workflow while still acknowledging the inter-related and time series nature of clinical decision making.

Bridget: As follow-on to this idea, the deployment of ‘edge’ computing capability has and can dis-aggregate the more monolithically and/or centrally developed and deployed CDS capability by providing more computing and analysis at the point-of-care. What do you see as the benefits and/or constraints (pros/cons) with this idea?

Dr Greenes:

This gets to the question of how to deploy CDS. As expressed above in the discussion of the ‘GPS-like’ platform, the idea is for the user to be able to receive the right options based on context, i.e. CDS delivery that is a user based response with awareness of where the CDS user and patient are in the continuum of care. Another way to state this would be to present the knowledge or CDS based on the state of need. How to represent the knowledge and provide this level of coordination requires more than ‘edge-computing’ capability. It needs large infrastructure to support the GPS-like vision. There is tracking of the patient state and provider expertise, role, and activities in time, understanding the workflow, understanding the nuances of the particular issue as well as any other relevant factors to be able to provide proper context-based knowledge delivery. While an ‘applet’ may be deployable at the edge, the back-end infrastructure to provide context awareness is currently too complex to be deployed at the edge.

Bridget: What three things you would like to see happen to improve the adoption of CDS systems? Is there anything that the medical device sensor and/or patient sensor systems industry could do to help with that?

Dr Greenes:

First, I want all relevant data from any source to be available to the user for CDS to be effective.  Second, I want all of the knowledge to be accessible in an interoperable format and third, which might be a corollary to the first idea, I would also like the ability to design applications that can view data in different ways, to support cognition and decision making. Right now, through technology such as SMART on FHIR we can only launch CDS capability by invoking it from an EHR application. This often consists of a separate tab that is customized by the user. It may not get invoked if the user is either overwhelmed by or not aware of the CDS capability. This is where CDS context awareness would be useful. One intermediary step would be how to manage the EHR environment such that the user is aware of the tools, perhaps providing a dashboard of CDS available based on the context or some helpful hints based on the context. Obviously, sensor systems must deliver good quality data. I like Eric Topol’s ideas of the patient becoming the primary source of the data on which the MD relies. We need to find a way to take advantage of consumer/commercial health sensors and devices. The healthcare-controlled environment and the consumer-controlled environment need to collide. We’ve found that data quality has greatly expanded in the consumer/commercial world and such good data needs to move into the mainstream of healthcare services. It will make healthcare delivery more efficient. For example, right now we have Ultrasound imaging available on a smartphone, which makes it more accessible to different levels of health professionals and able to be deployed in the home or minute clinic. A user can be trained to interpret the image with CDS assistance.

With regard to the improvement of CDS adoption, I was much more optimistic a few years ago. The Affordable Care Act (ACA) tried to create movement toward continuity of care and payment based on care value, which is greatly enhanced by and needs CDS. In response to the ACA, healthcare providers formed accountable care organizations (ACOs), in which there was a movement to value-based reimbursement with the sharing of risks and resources and a movement away from the fee-based approach to healthcare services.

With the gradual dismantling of ACA, the incentives have changed again towards the fee-based approach and that has slowed or tamped down the resources available to build the shared infrastructure required for effective CDS. In order for CDS to more fully penetrate healthcare delivery, there needs to be shared databases across healthcare providers and resources and accurate quality measures. We need a network where the risk base is broader to support the adoption of CDS.

Bridget: As a clinical engineer, my hope is to ensure that any technology I buy, implement or maintain for use by a clinician enables them to provide safe quality healthcare. I studied informatics to make sure I understood the systems that were downstream of the patient sensing systems that are traditionally in the clinical engineering milieu. What advice would you give someone with my biomedical engineering background to ensure I understood the context of CDS systems and how patient sensing systems affect and/or interact with CDS systems?

Dr Greenes:

I would suggest that while clinical engineers think in terms of modular subsystems, i.e., smart apps, edge systems and other ways to distribute the knowledge, they need to also think about how all the different source and delivery systems need to interact or ‘play’ with each other. What and how should the overall architecture and flow of information occur in a health system; not just the EHR and institution-based medical device systems but how would you include other disparate sources of date and information such as patient-generated information? Right now the problem is trying to keep an eye on how to do this while you’re shoehorned into an existing infrastructure that may not support the integration needed for the future.

Thank you, Dr Greenes, for your time and insight regarding CDS systems and how they interact with medical device systems.

*Also, discussion with M Burton, MD, Mayo Clinic and Arizona State University.