Computer Science
Computer Science-2021.gz:143202
Computer Science
a1d20d06c848c4f0102058398a37b2c9a5fb6803
MEDCOD: A Medically-Accurate, Emotive, Diverse, and Controllable Dialog System

We present MEDCOD, a Medically-Accurate, Emotive, Diverse, and Controllable Dialog system with a unique approach to the natural language generator module. MEDCOD has been developed and evaluated specifically for the history taking task. It integrates the advantage of a traditional modular approach to incorporate (medical) domain knowledge with modern deep learning techniques to generate flexible, human-like natural language expressions. Two key aspects of MEDCOD's natural language output are described in detail. First, the generated sentences are emotive and empathetic, similar to how a doctor would communicate to the patient. Second, the generated sentence structures and phrasings are varied and diverse while maintaining medical consistency with the desired medical concept (provided by the dialogue manager module of MEDCOD). Experimental results demonstrate the effectiveness of our approach in creating a human-like medical dialogue system. Relevant code is available at https://github.com/curai/curai-research/tree/main/MEDCOD


Introduction
The development of natural language (NL) understanding and dialogue systems, both spoken and textbased, has over 30 years of history and can be divided into three generations according to the disparate styles of system design: (1) use of expert systems based on symbolic-rules and templates (Allen * NYU. Work done while research intern at Curai † Drexel University. Work done while intern at Curai et al., 1996; Rudnicky and Xu, 1999), (2) use of (shallow) statistical learning (Wang et al., 2005;Tur and Deng, 2011;Wang et al., 2011), and (3) use of deep learning (Tur et al., 2018;Dhingra et al., 2016). The earlier two generations of dialogue systems were usually designed with a number of separate modules: textual (or spoken) natural language understanding (NLU), dialogue manager, natural language generation (NLG), and (optionally) spoken language generation. The main advantage of modular designs is their ability to easily incorporate domain knowledge. The main disadvantage is their weakness in generating flexible, human-like responses. The thirdgeneration language understanding and dialogue systems, driven by deep learning technology (Hinton et al., 2012;Huang et al., 2013;Deng and Yu, 2014;Deng, 2016;Deng and Liu, 2018), adopt the endto-end neural network architecture approach. This provides the opportunity to learn all parts of the dialogue system jointly and the ability to produce more human-like responses (Vinyals and Le, 2015;Chen et al., 2016;Hosseini-Asl et al., 2020). The main weakness, however, is that end-toend learned systems require large amounts of training data to implicitly acquire domain knowledge and suffer from poor control over the system's output.
In this paper, we present a hybrid modular and deep learning approach to designing a medical dialogue system targeted for the history taking task called MEDCOD, which integrates domain knowledge and controllability from a modular design with human-like NLG of a deep learning system. Medical dialogues between patients and doctors are one key source of information for diagnosis and decision making Soltau et al., 2021). No-tably, the task of history taking in such medical dialogues is an important, time consuming but, in many circumstances, low-complexity part of a medical encounter as it involves asking a series of closed-ended questions to ascertain the patient's current condition; this makes it a prime target for automation, decreasing the clerical load on physicians and allowing them to practice at the top of their scope. Other clinical use cases include AI-driven online symptom checkers and automatic patient triaging.
In our history-taking dialogue system, the dialogue manager uses both an expert system and a machine learned emotion classifier to control a deep-learningbased NLG module. The expert system uses a medical knowledge base (KB) (c.f. Miller and Masarie Jr. (1989)) that contains rich medical domain knowledge to identify which patient-reportable medical finding should be asked next. The emotion classifier then predicts the emotion with which the NLG module should ask the question. The NLG module is implemented using a deep learning approach to generate variable medical questions while maintaining medical consistency with the expert-system-derived finding, while containing emotion-classifier specified emotion.
The technical contributions of this paper are as follows. First, we developed a novel method of using "control codes" (Keskar et al., 2019) to within the medical dialogue data for training DialoGPT (dialogue generative pre-trained transformer) (Zhang et al., 2020), which serves as the NLG model in our dialogue system. This use of control codes aims to maintain medical consistency in the generated questions while creating diversity that exhibits humanlike attributes. Second, we train an emotion classifier for use in the inference stage of NLG. This gives our system the ability to generate emotive sentences simulating human doctors' behavior. Finally, to overcome the problem of sparsity in the dialogue training data, we made effective use of GPT-3 (Brown et al., 2020) to augment finding-NL paired data jointly for both diversity and emotion while maintaining medical consistency in the NL output. With these technical innovations, we have built MEDCOD, the first medically consistent and controllable history taking dialogue system with human-like NL expression as the system output in each dialogue turn.

Related Work
The task-oriented dialog system is one of four major types of dialogue systems in common use, the other three types being for non-goal-oriented applications in information consumption, decision support, and social interactions; see a review in (Celikyilmaz et al., 2018). This paper is devoted to task-oriented systems only, for the task of medical history taking.
The classic task-oriented dialog systems incorporate several components including Speech Recognition, Language Understanding, Dialog Manager (consisting of State Tracker and Dialog Policy), NLG, and Speech Synthesis. In the preliminary development, MEDCOD has not yet incorporated the speech components, although this would have a positive impact on further usability Huang and Deng, 2010;He et al., 2011;Deng and O'Shaughness, 2003;.
Until recently, a majority of task-oriented dialogue systems were based primarily on hand-crafted rules (Aust et al., 1995;Simpson and Eraser, 1993) or (shallow) machine learning techniques for all major components of the systems (Gorin et al., 1997). This work formulated the dialogue as a sequential decision making problem based on Markov decision processes and reinforcement learning (Young et al., 2010). With the introduction of deep learning in speech recognition, spoken language understanding, and dialog modeling, incredible successes were demonstrated in the robustness and coherency of dialog systems, especially in the NLU component of the system. (Tur et al., 2012;Mesnil et al., 2015;Hakkani-Tür et al., 2016;Li et al., 2016;Lipton et al., 2016).
The approach we take in developing our current medical dialogue system has been motivated by successes in the related work discussed above. Our work is also inspired by Paranjape et al. (2020), who demonstrated an open-domain, non-target-oriented dialogue system capable of empathetic conversations with emotional tone. Further, we have benefited from the work of (Keskar et al., 2019), which proposed the use of "control codes" to construct a generic language model for controllable NLG. We have used a similar mechanism to train the NLG module of our domainspecific medical dialogue system to maintain medical accuracy while generating diverse NL sentences. Finally, the approach to few-shot NLG using structured knowledge by Chen et al. (2019) relates to our work in that we have also made use of a specific medical knowledge base (KB) (as part of our dialogue manager) to provide control over the NLG model; one key difference is that our KB is used to create medical concepts for their diverse NL expressions rather than to provide better generalization across domains.
Medical dialogue systems have been reported in the literature only in recent years, with focus on NLU for clinical documents. Prior to the work presented in this paper, however, there does not appear to be any previous work that focused on NLG for medical dialogue systems. Enarvi et al. (2020) developed a system to generate NL medical reports based on patient-doctor dialogue transcripts but they did so from speech recognition outputs instead of from the semantic representation of a dialogue manager as in our work presented here. Below we briefly review the related work on NLU, which can be considered as complementary work to our current focus.
In the area of mapping extracted medical concepts in conversations to a knowledge base, (Du et al., 2019a,b) introduced a hierarchical two-stage approach to infer clinical entities (e.g., symptoms), their properties (e.g., duration), and relationships between them.Selvaraj and Konam (2019) focused on the problem of treatment regimen extraction while Khosla et al. (2020) studied the problem of extracting relevant task-relevant utterances from medical dialogues. The problem of intent detection in doctorpatient interactions is a new area and was recently explored in (Rojowiec et al., 2020). Further, Soltau et al. (2021) recently reported a spoken medical dialogue system aiming to extract clinically relevant information from medical conversations between doctors and patients. But the work did not proceed further to use the extracted information as input to a dialogue manager and then to produce the NL response, which our MEDCOD approach does. Bo et al. (2019) introduces a medical knowledge-based dialogue system that acts as a health assistant.  explored a natural paradigm for low-resource medical dialogue generation using very small amount of data for adaptation. Finally, Liu et al. (2019) presented a domain-aware automatic chest X-ray radiology report generation system. All the above work benefited the design of the NLG module of our MEDCOD system.

Approach
We present details of MEDCOD, our medical dialogue system for history taking which combines expert-system-driven structured history taking (i.e. generate "Next Finding" using a medical KB) with deep-learning-driven emotion classification and controllable NLG. This integration allows us to use the expert system to determine "what" to ask (by the system to the user) in an explainable and auditable way, Figure 1: An overview of MEDCOD system presented in this paper, with main contribution areas highlighted in red.
and to use the deep-learning components to determine "how" to ask with human-like natural language. To enable this separation of "what" and "how" we developed a NLG module in the dialogue system that uses control codes provided by the expert system and the emotion understanding component to guide the formation of the NLG module's output. Figure 1 provides overview of MEDCOD. Its Dialogue manager consists of three components: 1. Conversation tracker: this component tracks patient demographic information, reason for encounter, what findings have been reported by the patient, the text of the previous questions, and the text of patient responses.
2. Next Finding: this expert-system component takes patient demographics and patient findings and generates the target finding (next finding control code) to be asked next by the NLG.
3. Emotion Classifier: this model takes the conversation context and predicts the appropriate emote (emote control code) to be used by the NLG model ( § 3.1). This component was trained using the Emote dataset ( § 4.3.1).
NLG component uses previous findings as well as control codes for the target finding and emote to generate a human-like NL question about the target finding ( § 3.2). This component was trained using the Medical Conversations dataset ( § 4.3.2).

Emotion Classifier
During medical history taking, the patient may provide sensitive or emotionally charged information (e.g. severe pain); it is imperative that an automated dialogue system reacts and emotes appropriately to this information, similarly to how a human doctor would (e.g. "Oh that's unfortunate..."). When analyzing patient-provider medical conversations, we identified four broad classes of emote control codes that reflect emotional phrasing medical professionals use when talking with their patients. The control codes are Affirmative, Empathy, Apology, and None (see § 4.3.1 for more details). The goal of the emotion classifier is to predict the emote control code based on the conversational context. The conversational context contains three pieces of information: (1) previous question (2) patient response, and (3) target finding (which is the output of Next Finding module). The model consists of embedding the contexts independently (using a pretrained model) to capture the semantics of the entirety of text, and then learning a linear layer of predictors, on reduced dimensionality, over the emote control codes. We first independently embed the three pieces of context using Sentence-BERT (SBERT) (Reimers and Gurevych, 2019) that takes as input a variable-size string (up to 128 tokens) and outputs a fixed-size vector containing semantically-meaningful feature values. We then apply principal component analysis (PCA) (Pearson, 1901;Hotelling, 1933) to the embeddings of each input type independently and then concatenate the embeddings. Finally, we train a logistic regression classifier over the four emote control code classes. The model is trained on the Emote dataset ( § 4.3.1).

Natural Language Generator
We developed the domain-specific NLG module of MEDCOD with three key constraints and goals: 1. Medical Consistency: Generated questions by the system must ask only about the target finding (e.g. if the target finding is "abdominal pain" then an acceptable question would be "Is your belly hurting?" while an unacceptable question would be "Do you have severe abdominal pain?"). 2. Phrasing Diversity: Generated questions must present phrasing variability, a major improvement over using templated questions (e.g. if the target finding is "abdominal pain", instead of asking every time "Is your belly hurting?", the model can generate alternative paraphrases such as "Do you have pain in your belly?") 3. Emotional Awareness: Generated questions must be empathetic when appropriate. When gathering pertinent findings from the patient, we would like the NLG output to emote appropriately based on the context: did the patient say anything particularly difficult that we should empathize with (e.g. a patient complaining about severe pain)? Are we about to ask a highly relevant (for a presenting symptom) but sensitive question (e.g. checking with the patients if they have multiple sexual partners)?
We achieve these three goals simultaneously by fine-tuning a pretrained DialoGPT model (Zhang et al., 2019). In the fine tuning process, we use control codes for dialogue prompts to help guide the NLG output (Keskar et al., 2019) at inference-time. Apart from the control codes, we also prompt with the previous findings, patient's age and gender, as well as patient's reason for visit. The full control codes consist of the next finding control code and the emote control code. At training time, we use the Medical Conversations dataset ( § 4.3.2). At inference time, the control codes are generated by the dialogue manager: next finding control code comes from the Next Finding module while the emote control code comes from the Emotion Classifier.

Datasets
The development of our medical dialogue system relies on a number of datasets. The process for constructing these datasets is presented in Figure 2(  (b) Examples illustrating training set construction. We append control codes during training to condition the models on them, which can then be used for guiding NLG during inference.   (1989)) that is kept up-to-date by team of medical experts. Currently, it contains 830 diseases, 2052 findings (F) (covering symptoms, signs, and demographic variables), and their relationships. It also contains human generated patientanswerable questions for ascertaining the presence for every finding. Finding-disease pairs are encoded as evoking strength (ES) and term frequency (TF), with the former indicating the strength of association between the constituent finding-disease pair and the latter representing frequency of the finding in patients with the given disease. The inference algorithm of KB computes differential diagnosis and also facilitates the next finding to ask using Next Finding module.

Doctor Edits dataset
This is a small in-house dataset containing 3600 instances of doctor-edited questions as well as doctor and patient dialogue turns preceding the doctor-edited questions. For training the emotion classifier, we perform a random 80/20 train/test split.

Structured Clinical Cases dataset
Structured Clinical Cases dataset contains simulated cases that consist of patient demographic data (age, sex), the chief complaint also known as reason for encounter (RFE) and a set of findings with "present" or "absent" assertion. The data is produced using an in-house simulator, Structured Clinical Case Simulator (SCCS). SCCS uses the KB as a clinical decision support system. Unlike previous works that simulate clinical cases for a desired diagnosis (Parker and Miller, 1989;Kao et al., 2018;Ravuri et al., 2018;Kannan et al., 2020), SCCS starts with a finding and goes through the process of history taking to lead up to a diagnosis: It first samples demographic variables and a finding f ∈ F that serves as the chief complaint/RFE. Then, it computes the differential diagnosis (distribution over the diseases given the finding) using the underlying expert system and then samples findings taking into account the differential diagno-sis. The newly sampled finding is asserted randomly to be present f pos or absent f neg with a slight bias to absent. If asserted as present, then the findings that are impossible to co-occur are removed from consideration (e.g. a person cannot have both productive and dry cough). The next iteration continues as before: computing differential diagnosis and then identifying next best finding to ask. The simulation for a case ends when a random number (5-20) of findings are sampled or the difference in score between the first and second ranked diagnosis is at least 20 (a desired minimum margin under expert system). Simulated samples with margin higher than that are added to the Structured Clinical Cases dataset. See § A for an example simulated clinical case.

Paraphrased Questions dataset
The Paraphrased Questions dataset contains findings and an associated set of questions, these questions being different ways (paraphrases) to ask about the finding (for examples see Table B.1). The goal of this dataset is to imbue variability into the NLG model with examples of different question phrasings. We use carefully primed GPT-3 (Brown et al., 2020) to generate a large number of candidate questions for each finding. We curate a small but diverse set of thirty findings and manually paraphrase the expert-written question already available from the KB. We randomly sample 10 findings for priming Chintagunta et al., 2021) GPT-3 to paraphrase new unseen findings. See Appendix I for example invocations. To restrain the generations but still acquire a diverse set of paraphrases, we limited the output to a single paraphrase at a time. We repeatedly invoke GPT-3 (temp=0.65) until we have the desired number of distinct paraphrases, each time priming GPT-3 with random sample of ten findings.
The key strength of this approach is the minimal human effort required; only a single manually-written paraphrase is required for each finding in our small set, which is then used as guidance for GPT-3 to mimic the task on new findings. We manually validate the candidate questions using in-house medical professionals by asking them to label if the candidate question is medically consistent with the target finding, and keep only those that are. We achieved 78% correctness of finding-question pairs. Analysing the failure cases, we found that the error was either due to minor grammar issues or bad timing (i.e., "Are you sleepy?", which implies right now as opposed to intermittently throughout the day). We collected question paraphrases for the 500 most frequent findings in the Structured Clinical Cases dataset.

Emote dataset
The Emote dataset contains a set of emote phrases, their corresponding emote control codes, and patient and medical professional dialogue turns that preceded the use of the emote phrase. This dataset is directly used to train the Emotion Classifier ( § 3.1). The emote phrases are directly extracted from medical professional messages, while the emote control codes are manually assigned to each emote phrase.
We mined the Doctors Edits dataset for medical professional messages that express emotion and identified three broad clases of emote control codes: • Affirmative: A neutral confirmation of the user's response, flexible to be used in many conversation situations (e.g. thanks for the input). • Empathy: A more emotionally charged response, implying something negative/painful about the conversation. • Apology: This is an apology for asking a personal or sensitive question (e.g., "Sorry for asking a personal question, do you have multiple sexual partners?").
We also included None as an emotion code to reflect no emotion is added. We associated with each emote code a set of emote phrases that are frequently used by medical professionals to express these codes. We provide additional details on data mining for emotion from conversations and examples of emote phrases corresponding to codes in Appendix C.

Medical Conversations dataset
The Medical Conversations dataset consists of dialogue context, next finding and emote control codes, and medical finding questions with emotional responses; the NLG model is trained on this dataset. Figure 2(b) provides a walk through for constructing Medical Conversation samples. To generate dialogue context we sample from the Clinical Cases dataset. From this we extract the RFE, patient demographic information, target finding, and the structured preceding finding and patient response. The preceding finding and the target finding are converted into a preceding medical professional question and target question in the following manner. We sample from the Paraphrased Questions dataset a question corresponding to the finding. We then randomly choose an emote control code and a random corresponding emote phrase from the Emote dataset. The emote phrase is then prepended to the finding-basedquestion. For the patient response we simply select "Yes" or "No", based on the assertion attached.

Experimental Results
In this section we present both subjective and objective evaluation results which robustly demonstrate the improved output from MEDCOD when compared to counterparts that use the fixed-template approach to asking questions or can not emote.

NLG:
We use a pretrained DialoGPT-Medium from HuggingFace (Zhang et al., (accessed July, 2021) as our underlying NLG model. We train on 143,600 conversational instances, where each instance has only one previous conversation turn as context. We use a batch size of 16 with 16 gradient accumulation steps for an effective batch size of 64, for 3 epochs with a learning rate of 1e-4 and ADAM optimiser. Emotion Classifier: We apply pretrained paraphrase-mpnet-base-v2 SBERT for embedding the conversational contexts. The Logistic Regression model is trained with C=10 and class re-weighting (to compensate for the data skew of the training data § 4.3.1). PCA is applied down to 70 components.

Ablations of MEDCOD
We ablate MEDCOD by varying data/control codes supplied to each underlying NLG model during training, with all other parameters kept consistent. This allows us to understand the importance of variability, medical consistency and ability to emote. We use Expert to denote the variant of MEDCOD in which the NLG module is trained only on expert questions (single question per finding). MEDCODno-Emote's NLG module is trained on the Medical Conversations dataset ( § 4.3.2) with paraphrases but no emote codes while MEDCOD is our featurecomplete dialog system trained on the entire Medical Conversations dataset including emote.

End2End Evaluation: Main Results
This is our main evaluation that is targeted at understanding if the patient experience on the endto-end system can be improved by providing them with a more natural conversational dialog. For this, we instantiate two identical medical dialog interfaces with different driving systems: Expert and MED-COD. A set of 30 commonly occurring chief complaints along with demographic information such as age and gender were collected from a telehealth platform. We recruited five medical professionals for the labeling task such that each medical professional will go through the conversational flow for 18 chief complaints, giving three labels for each case.
Labeling instruction: While the focus is on patient experience, we engaged medical professionals because of the dual patient/doctor role-play for this evaluation. When they start on a chief complaint, they were to choose a relevant final diagnosis and answer questions to substantiate that final diagnosis; this ensures that the sequence of questions asked during conversation are clinically grounded. While doing so, they were also acting as a patient, answering and responding (e.g., by volunteering extra information) as someone presenting with the symptoms would. The medical professionals converse simultaneously with the Expert and MEDCOD systems (the UI presents an anonymized A/B label) by providing identical answers for each conversation step between the two interfaces (but different answers between steps). Once they perform 10 question responses or the conversation terminates (due to reaching a diagnosis), the encounter is over and they label each instance as follows: Enter a 1 for either Model A or Model B, based on how you think a new patient using the service for an ailment would feel. If you prefer the encounter with Model A, enter a 1 in the Model A column and 0 in the Model B column, and vice versa if you prefer Model B. To avoid spurious ratings when the two models are very similar, we also allowed the same grade to be given to both models if they were equally good/bad, but required a comment explaining the decision. Results: Table 1 shows the evaluation results (refer to Appendix H.1 for a full conversation example). When simply summing up the scores, MEDCOD achieves a score of 63 (max 90) -over twice as high as Expert. When separating scores into instances where one model is picked exclusively over the other or both are rated equally ("Mut. Excl. Pts"), we see a similarly strong result for our model; in over half the conversations enacted, MEDCOD is preferred holistically over Expert, while only 17.8% of the time is Expert preferred. When we inspect the difference, its often the case that MEDCOD emoted with Affirmative when not emoting (None) would have been more appropriate.
We also considered majority voting for each of the patient complaints, which shows an even more exaggerated improvement by our model. Two-thirds of the time (66.7%), MEDCOD is exclusively preferred over Expert, while only 6.6% of the time latter is preferred. In roughly one-fourth of the chief complaints, both models are rated equally.
In the majority of cases, MEDCOD is preferred, indicating that within an automated dialog situation, the contributions discussed in this paper provide a marked improvement to patient experience.

NLG Module Evaluation
The goal is to evaluate MEDCOD and its ablations individually along three important aspects for medical dialog (c.f. (Rashkin et al., 2018)): 1. Medical Consistency: How well does the question capture the clincial implication of the target finding?
2. Fluency: How fluent/grammatically correct is the candidate question?
3. Empathy: How empathetic/emotionally appropriate is the candidate question, given the conversational context and the finding to ask next?
To collect the data for this evaluation, we begin with an in-house dataset of conversations from a tele-health platform. We decompose each conversation into three-turn instances (same form as Emote Dataset §4.3.1), then attach an emote control code to  Table 2: NLG evaluation -MEDCOD shows significant improvement in empathy and added variability without sacrificing other aspects each instance by performing prediction with the Emotion Classifier. To exaggerate the difference between instances, we only keep instances where the predicted class' probability > 0.8. We then randomly sample 25 instances from each of the four predicted classes to create our final set of 100 evaluation instances. Finally, we generate a candidate question for the instances by passing the conversation context to each of the model variants for generation. A team of five medical professionals label each example along each of three axes on a scale of 1 to 5. Results: Table 2 provides the comparative results. MEDCOD scored significantly higher in Empathy, showing that the Emote dataset additions improve human-evaluated empathy in a significant way. This result also indicates that the emote code is appropriately predicted by the Emotion Classifier.
There are many correct ways to query a finding, however the Expert model is trained on data with precisely one way, which is expert-annotated, so is likely to have optimal medical consistency (and also be the most fluent for the same reason). Because of this, we view Expert as close to best performance achievable along Medical Accuracy and Fluency. MEDCOD and MEDCOD-no-Emote are still comparable to Expert indicating that the variations in how questions are framed do not significantly affect medical accuracy or fluency. As expected, given that its impossible to encode empathy preemptively (in the expert-annotated or paraphrased questions), Expert and MEDCOD-no-Emote score low on empathy. Note that it is not always necessary to emote, hence they receive non-zero score.
Appendix G provides qualitative examples of comparing generations from model variants where MED-COD is expressive and incorporates empathy.

Emotion Classifier Evaluation
Evaluating emotion is difficult as it is subjective and can be multi-label: in a situation, there may be multi- Figure 3: Emotion Classifier Evaluation ple "correct" ways to emote so comparing predictions to a single ground-truth label (i.e., physician's emote) is unlikely to give an accurate notion of performance. We instead measure the emotional appropriateness using a small team of medical professionals.
For each instance in the Emote dataset test split, we pass the predicted emote control codes to a team of three medical professionals. They are tasked with labelling whether the emote code is appropriate, given the previous context in a conversation (input to our model). When the emote is not appropriate, an alternate emote is suggested by the labeller. We use majority voting on this data to obtain the final label, creating an alternate human-augmented test set. We evaluate the model's predictions against this humanaugmented test set; Figure 3 shows the confusion matrix on the full Emote dataset test split and Table D in Appendix shows the complete results.
On the human-augmented test set, our Emotion Classifier reached 0.9 accuracy with macro-F1: 0.8 and PR-AUC: 0.69. Looking at precision/recall statistics, each non-None emote class (and the model predictions overall) achieved precision >= recall, which is desired due to the high cost of inappropriate emoting; we want high confidence when we actually emote something, otherwise we should safely emote None. It should be noted that we did not tune the classification boundary but simply took the max-probability class as prediction; a high prediction threshold (e.g., 0.8) would further increase precision.
The confusion matrix ( Figure 3) illustrates a similarly strong picture of our Emotion Classifier's performance; the large majority of non-None predictions are correct. There are 54 'incorrect' None predictions by our Emotion Classifier, however, these are low-or zero-cost mispredictions, as it is always appropriate not to emote (the same cannot be said for Empathy, for example, where it can be very costly to empathise when not appropriate).
We also analyzed how conversational context affects predicted emotion. See Appendix E for complete attribution details. We find that empathy is strongly influenced by the previous patient response, apology by the next question and affirmative by all three parts of the input.

Conclusion & Future Work
We introduced MEDCOD 1 , a novel approach to developing medical dialog systems, which combines the traditional modular design with a deep learning based NLG model. In particular, our approach allows us to incorporate, in a medically consistent fashion, the knowledge of medical findings and an appropriate emotional tone when generating humanlike NL expressions through the use of their respective control codes, both provided by the dialog manager. The highly positive experimental results presented demonstrate the effectiveness of our approach.
Our current approach still leaves a number of open problems. A broad problem for making the dialogue even more human-like is the effective use of implied references; as an example, when a patient mentions they have diarrhea, the system would ask them "Is it bloody?" as a follow-up question, as opposed to "Do you have bloody diarrhea?". Alternatively, historical context references can be used: asking "You mentioned you have headache. Is this recurrent?" instead of "Do you have a recurrent headache?".
Another area of improvement in our current system is increasing the granularity of emotion classes. This may include both the addition of new classes and incorporating a notion of emotional intensity, e.g., "OK" has a different strength than "Thank you!" In the longer term, our dialogue system should accommodate speech recognition and speech generation. This presents a new class of challenges such as emotion detection from speech and synthesis of properly empathetic speech. Multimodal inputs beyond text and speech may further advance the functionality of dialogue systems, especially in the userinterface aspect (Yu and Deng, 2008). For example, the video-feed of a patient may present additional opportunities for refining our dialogue manager module by collecting non-verbal cues from the patient.

Appendix E. Dissecting Emotion Classifier: Emotion Attribution
As we mentioned in § 3.1, we used logistic regression as the final classifer for the emote classifier, where: where p i is the probability of the i th control code and index j represents the input source (previous question, previous patient response, target finding), M ij is the learned coefficient vector corresponding to i th class and j th source, x j is SBERT embedding vector corresponding to j th input source, after dimensionality reduced by PCA, and b are learned biases. We analyzed how conversational context affects predicted emotion. Using eq. 1, we compute the contribution of each input source j for each output control code i by looking at the individual summands M T ij x j . The biases for each of the four classes are the following: None = 3.27, Affirmative = 0.88, Empathy = -1.66 , Apology = -2.49. Figure E.1 shows the mean contribution of each input source to the predicted output control code (i * = arg max i p). We find that the apology and empathy are strongly predetermined by a single input source. For the apology class main contributor is the next question, this is consistent with expectation (i.e we apologize for asking personal and embarrassing questions). For the empathy class the main contributor is the previous response, which again matches intuition that we show empathy if the patient response involves significant negative sentiment. For affirmative class, all three types of inputs are taken into account, with previous question has the largest contribution. Intuitively, this makes sense that we may prioritize responding to the previous answer based on not only what the exchange has been so far, but also what we are going to ask next. For the none class, none of the input sources contribute significantly, this is consistent with the none class being driven by the bias (3.27!) -when the model doesn't predict an emote it is because none of the input sources contributed to an alternative class.