# An Embedded System for Monitoring Industrial Air Dehumidifiers using a
Mobile Android Application for IEEE 802.11 Networks

Erik de Oliveira Rosa, Lincoln Grabarski,
Marcos F. Fragoso, Allan C. Krainski Ferrari  University Center of Araucária
(UNIFACEAR)1
Araucária, Paraná, Brazil
<EMAIL_ADDRESS>
<EMAIL_ADDRESS>Jefferson Rodrigo Schuertz and
Carlos
Alexandre Gouvea da Silva1 Electrical Engineering Department (DELT)
Federal University of Paraná (UFPR)
Curitiba, Paraná, Brazil
<EMAIL_ADDRESS><EMAIL_ADDRESS>
###### Abstract

The constant technological evolution allowed signi-ficant advances and
improvements in the processes of industries, mainly in areas that demand
greater control and environmental air efficiency. In this way, Embedded
Systems allow the deve-lopment of products and services that aim to solve or
propose solutions in these industrial environments. This article presents the
development of an Embedded System with a Programmable Logic Controller (PLC)
and Arduino for industrial air dehumi-difier, which allows the monitoring of
failures remotely from a reliable data communication in a mobile application
for Android operating system (OS) on a wireless network IEEE 802.11. As
result, a prototype of the test bench for the Embedded System is presented in
which the main parameters of temperature sensors and operating conditions of
the dehumidifiers are checked.

###### Index Terms:

Air Dehumidifier, Android OS, Embedded System, Industrial Machines.

##  I Introduction

Air quality is one of the decisive factors in the control of environments that
require specific care, e.g. in hospitals or outpatient clinics for the
isolation of microorganisms and mitigation of the occurrence of infections.
Several pathogens found in air conditioning units highlighting the need for
air quality control measures in air-conditioned hospital environments [1].
However, air control isn’t limited to biological environments, but also to
residential and industrial environments using specific equipment, such as
dehumidifiers.

Industrial automation of air quality has evolved and provided an increasing
number of techniques to control temperature, humidity and removal of polluting
waste industrial environments. There are many consequences of poor air quality
and can cause respiratory diseases in people. In an industrial environment
this quality can generate a greater number of absences due to illness or
reduction in work capacity of employees. The dehumidifiers are generally
important to maintain proper humidity in the environment, especially in those
where such control is required by technical standards and external regulatory,
or internal procedures of industries. Usually, the air dehumidifier is used to
generate air at low relative humidity (RH) and ensure quickly and suitably the
cooling process [2].

In industrial environments, dehumidifiers represent an ally in temperature and
RH control. In many industrial processes, the control of these air conditions
can affect the quality of the products produced and also in the way they are
stored. In food industries, these conditions are important to dry some types
of food [3][4], supermarket applications [5], thermal comfort of people [6],
among other. For humidity sensitive applications such as pharmaceutical, and
chemical industries it is required very dry air dehumidifiers because is
difficult to achieve and energy inefficient using conventional systems [7].
However, these machines also are used in agricultural process [8], greenhouse
projects [9], among other. At industrial sector, the main type of
dehumidifiers are based at desiccant materials in which are used for
absorption of water (humidity) of air.

The objective of this work is to implement an embedded monitoring system for
industrial air dehumidifiers that helps users to reduce downtime in their
process in cases of corrective maintenance. This embedded system assists in
the control and verification of the need for preventive maintenance, so that
can plan a programmed shutdown of the dehumidifier. The monitoring is done
through a mobile application developed for smartphones with Android OS and to
be used in wireless local area networks (WLAN).

##  II Related Works

Even existing since the 1980s’ the air dehumidifiers are receiving varied
updates and applications through simple or sophisticated embedded systems.
These embedded systems make the monitoring and process control more effective
and efficient in which: it is possible to check the status of dehumidifiers
remotely through mobile devices, send notifications of failures in these
equipments, improve the performance and efficiency of dehumidifiers and
control the levels of air quality through remote systems.

In [10] the authors suggests an industrial dehumidifier automatic controlling
system that automatically maintains optimized humidity using smart phone
connected under a wireless network, in which it provides optimized temperature
and humidity environment in growing environment of plants and animals. The
system is based a small-scale sensor network with temperature and humidity
sensor installed in air dehumidifier. A mobile application allow turn on or
turn off the equipment and also verify the temperature in real-time, humidity
of air, luminosity inside the environment where the equipment is working, and
an information indicative of working of dehumidifier.

A residential application developed by [11] implemented a coordination of two
dehumidifiers based on humidity sensor information in the distributed manner,
but other devices also are controlled using a smart outlet network. A novel
remote-controlled system for use with air-conditioning units based in solid
desiccant dehumidifiers which can be employed to create low carbon emission
buildings is proposed by [12]. The system employs multiple information
technologies such as sensor fusion, digital input/output communication and
mobile technologies to monitor and control the internal conditions of
buildings. A mobile applicative is employed by [13] provides a control system
to adjust parameters of air conditioners, humidifiers, dehumidifiers, air
purifiers and light via extended interfaces. An Internet of Things (IoT)
application proposed by [14] monitors regularly six Arduino sensor in order to
trigger dehumidifier, humidifier, and air purifier to maintain air quality
using a mobile device.

Although the previous works present a set of solutions for controlling and
monitoring air dehumidifiers through mobile applications, it still lacks work
for embedded systems for industrial environments.

##  III Proposed System

The proposed Embedded System to monitor the air quality and work conditions of
dehumidifiers is based at a set of machines from the Munters Company. Munters
is a global leader in energy-efficient air treatment and climate solutions.
Munters industrial dehumidifiers provide to clients a set of essential
dehumidifying functions, with additional modules or other functions, such as
filtration, cooling, heating and air mixing. These additional modules
integrate with other components of the air dehumidification process, requiring
connections, such as cooling pipes, ducts and sensors.

Fig. 1 presents the diagram of proposed system, and is described as follow.

Figure 1: Monitoring Dehumidifier System Diagram.

###  III-A Programable Logic Controller (PLC)

The main element to monitor and verify the operating conditions of the
dehumidifier is the PLC ELIWELL AVC126006I500 developed by Scheneider Company.
It is connected to the dehumidifier and is responsible for reading the various
operating parameters of the equipment through the 12 analogical and 12 digital
input ports. The configuration of the reading parameters of inputs and outputs
is done through proprietary software from the manufacturer of the PLC. The
different connectivity modes allow the PLC to communicate with other important
devices in the development of this work. The PLC is connected on the Ethernet
interface to the Man Machine Interface (MMI), via an unshilded twisted pair
(UTP) cable. Through the MMI (Fig. 2) with 8”, the local network parameters
are configured, such as the PLC device IP address, the local network address,
the mask address and the TCP/IP port number (502) for access via the mobile
application. In this work the interaction with MMI is just for maintenance
support people and not by common users.

Figure 2: Man Machine Interface (MMI).

One of the two RS485 interfaces (Modbus RTU) is used, the PLC is connected to
the arduino through a MAXRS485 module. The MAX485 module allows communication
via a serial cable between the PLC and an Arduino Uno microcontroller in which
it will have the embedded monitoring system.

The arduino is not used to read information of sensor because the main device
to read and receive these informations is the PLC. PLC had a set of solution
in order to provide an improved controlling and management of dehumidifier.
Still, the PLC do not provide support to connect communication devices for
wireless IEEE 802.11 interface in order to allow connecting mobile devices.

###  III-B Embedded System at Arduino Uno

An application developed using C programming language was stored on the
microcontroller Arduino in order to receive the information from the
dehumidifier sensors through the PLC. The information received by PLC is
stored in memory elements named registers and within these registers, there
are subsets that perform a function depending on their characteristic. In this
work, holding registers were used, where their main function is to read and
write data with a 16-bit data message at a logical address between 40001 to
49999.

For programming it was added to the modbusslave library, in which it
represents an excerpt of the previously ready modbus software. Then, all lines
of code were written via the programming line in which the necessary parameter
values were requested. For each type of data accessed, the correct register
for accessing that data is associated, as shown in Table I. Each register code
represents the address of data register in PLC with information about
dehumidifier conditions.

TABLE I: Register Code List Register code | Register PLC | Read information
---|---|---
MB_4000 | A0 | Test register
MB_4001 | SRT | Reactive outlet temperature
MB_4002 | PA | Reactive post-heating temperature
MB_4003 | ST1 | Process input temperature
MB_4004 | SU1 | Moisture Intake Process
MB_4005 | ST2 | Process output temperature
MB_4006 | SU2 | Process output humidity
MB_4007 | PRE | Pre-cooling temperature
MB_4008 | POS | Post-cooling temperature
MB_4009 | PST1 | Pressure Sensor

In industrial plants there are a lot of machinery and processes that naturally
generate high noise that can result in high packet loss rates [15]. For this
reason it was used for communication Arduino Ethernet module to the
application, the back more reliable cable for data transmission than other
types. The module is fitted over the Arduino and for this reason does not need
any external connection. An Access Point (AP) configured as bridge mode is
connected to the Arduino Uno via UTP cable in order to operate only as a data
transmission antenna. The AP is configured to match the IEEE 802.11b/g/n
standard. IEEE 802.11, known as WiFi, has become the main standard for WLAN
and was chosen due to ease of configuration and become is one of the most
important ways to connect devices to the Internet, therein improving
productivity and encouraging information sharing [16]. Including WiFi
communication, it is possible to use alternative technologies such as
Bluetooth or ZigBee (IEEE 802.15.4) [17].

###  III-C Android Applicative Mobile

For the development of the mobile application, Android Studio was used as an
integrated development environment (IDE) and a smartphone with Android 9.0
version. The construction of the app started with the login screen, where the
user and password data are inserted, as a form of reliability so that only
authorized users can access the system. In order to improve the usability of
users, usual rules for creating screen designs based on software quality
standards such as ISO 9126 were considered. API sockets were used to establish
a secure connection via TCP/IP protocols for communication between the mobile
application and the Arduino.

##  IV Results

The results are presented in terms of the application and testing of the
system in the plant created to present the embedded system in operation. In
this work it was not possible to carry out the tests in a real scenario,
however the same PLC was used, which is generally used in the control of this
equipment in the industrial plant. In this case, the results in a controlled
scenario is expected they will be adequate.

The Fig. 3 presents the bench developed for the Embedded System air
monitoring. This bench consists of five main parts: the MMI (1) showing the
equipment data; the set of LEDs, potentiometers and keys (2) which have the
function to simulate failures and alerts the machine; the circuit breakers (3)
which protect the system against overload and short circuit; PLC (4) being fed
by supply 110 $\text{V}_{\text{AC}}$ to 24 $\text{V}_{\text{DC}}$, is
responsible for all the logic of the equipment; finally the Arduino (5)
contains all logic charge to receive PLC data and transmit to the smarthphone
along with the MAX485 (5) that converts the RS485 signal to TTL.

Figure 3: Front view of Bench.

For the validation of the monitoring system of industrial air dehumidifier,
data transmission tests were performed between the PLC and the Arduino through
the MAX485 module. The data received in the Arduino using the Ethernet shield
are sent packets to the Android application. As expected, the application has
received the information that was requested from the PLC and operating tests
were performed a dehumidifier. These results are presented below.

|  |
---|---|---
(a) | (b) | (c)
Figure 4: Application Mobile View: (a) ideal condition of dehumidifier, (b)
conditions with fails and (c) measures parameters of dehumidifier.

In Fig. 4a was simulated the initial test with the equipment in perfect
working order, in which the equipment does not show any failure or active
alarm. When the machine detects a fault, automatically the equipment goes into
shutdown mode, in Fig. 4b were simulated equipment failures in which
activating the keys was caused the triggered emergency errors, safety
thermostat, overhead motor and increasing the resistance of pot, generate the
error sensor reactivation and post heater. The reactivation in the air flow is
operating for the reason that it only comes into fault with the connected
equipment is failure refers to the differential pressure switch, equal to the
filters, but it a failure because it is considered is located after the
resistance and Therefore it is very important for the safety of equipment.
Another function performed by the application is monitoring in real time Fig.
4c shows the values received from the PLC through temperature and humidity
sensors, which are simulated by means of resistance change, which was used
potentiometers.

The Fig. 4c shows the values in real time, as the process input is 54.50∘C
temperature and after passing through the dehumidifier reaches the setting
cylinder with a humidity of 51.90%, the same applies to the process output the
reactivation output reading sensor directly affects the process input
moisture, as its basis that the PLC using as a reference for PID control. This
information is important for the user to know how is the operation of the
equipment and make the necessary changes according to the needs of the
process.

##  V Conclusion

In this paper was proposed an Embedded System for monitoring the conditions of
industrial dehumidifiers. The working and test of system was made at a bench
created with the original materials and connections of the proposed system.
Based in results, we analyses and validate the operation conditions of
equipments, programing softwares and communication data.

As it has not been tested the embedded system at a real industrial
environment, it is suggested to apply its on a real scenario on further works.
In addition to suggesting to create a iOS version of mobile application.

## References

  * [1] M. S. M. Afonso, A. F. V. Tipple, A. C. S. Souza, M. A. D. Prado and P. S. Anders, “A qualidade do ar em ambientes hospitalares climatizados e sua influência na ocorrência de infecções,” Revista Eletrônica de Enfermagem, vol. 6, no. 2, pp. 181-188, 2004.
  * [2] H. Faten, M. Abdelkader and B. M. Slah, “Experimental study of the influence of using a dehumidifier on the moisture content of stored wheat,” 7th International Renewable Energy Congress, Hammamet, pp. 1–5, 2016.
  * [3] V. Sosle, G. S. V. Raghavan and R. Kittler, “Low-temperature drying using a versatile heat pump dehumidifier,” Drying Technology, vol. 21, no. 3, pp. 539–554, 2003.
  * [4] J. A. Moses, T. Norton, K. Alagusundaram and B. K. Tiwari, “Novel drying techniques for the food industry,” Food Engineering Reviews, vol. 6, no. 3, pp. 43–55, 2014.
  * [5] A. Capozzoli, P. Mazzei, F. Minichiello and D. Palma, “Hybrid HVAC systems with chemical dehumidification for supermarket applications,” Applied Thermal Engineering, vol. 26, no. 8–9, pp. 795–805, 2006.
  * [6] P. Mazzei, F. Minichiello and D. Palma, “HVAC dehumidification systems for thermal comfort: a critical review,” Applied Thermal Engineering, vol. 25, no. 5–6, pp. 677–707, 2005.
  * [7] M. M. Rafique, P. Gandhidasan and H. M. Bahaidarah, “Liquid desiccant materials and dehumidifiers - A review,” Renewable and Sustainable Energy Reviews, vol. 56, pp. 179–195, 2016.
  * [8] M. T. Yang, C. C. Chen and Y. L. Kuo, “Implementation of intelligent air conditioner for fine agriculture,” Energy and buildings, vol. 60, pp. 364–371, 2013.
  * [9] J. M. Cámara-Zapata, J. A. Sánchez-Molina, F. Rodríguez and J. C. López, “Evaluation of a dehumidifier in a mild weather greenhouse,” Applied Thermal Engineering, vol. 146, pp. 92–103, 2019.
  * [10] Y. J. Lee, K. W. Park and. E. K. Kim, “Automatic Dehumidifier Control System for Greenhouse Using Smart Phone,” In Advanced Multimedia and Ubiquitous Engineering. Lecture Notes in Electrical Engineering, Springer, Berlin, Heidelberg, pp. 257-264, 2015.
  * [11] N. Morimoto, Y. Fujita, M. Yoshida, H. Yoshimizu, M. Takiyamada, T. Akehi and M. Tanaka, “Smart Outlet Network for Energy-Aware Services Utilizing Various Sensor Information,” 27th International Conference on Advanced Information Networking and Applications Workshops, Barcelona, pp. 1630–1635, 2013.
  * [12] W. Peng, D. Su and M. Higginson, “A novel remote control system for air conditioning in low carbon emission buildings using sensor fusion and mobile communication technologies,” Building and Environment, vol. 148, pp. 701–713, 2019.
  * [13] D. Ding, H. Chen, L. Zhang, H. Chen, H. Lin and F. Gao, “An intelligent and telecontrol environmental monitoring equipment with extended interfaces,” 10th International Conference on Computer Science & Education, Cambridge, pp. 917–920, 2015.
  * [14] F. B. P. Prakasa, J. Maiga and Suyoto, “IoT-Based Smart And Healthy Wardrobe System,” International Conference of Artificial Intelligence and Information Technology, Yogyakarta, Indonesia, pp. 119–123, 2019.
  * [15] C. A. G. Silva, E. L. Santos and C. Osinski, “Wireless Industrial Networks under Interference Conditions based on IEEE 802.15.4,” 13th IEEE International Conference on Industry Applications, São Paulo, Brazil, pp. 169–173, 2018.
  * [16] C. A. G. Silva and C. M. Pedroso, “MAC-Layer Packet Loss Models for Wi-Fi Networks: A Survey,” IEEE Access, vol. 7, pp. 180512–180531, 2019.
  * [17] C. A. G. Silva, E. L. Santos, A. C. K. Ferrari and H. T. Santos-Filho, “A Study of the Mesh Topology in a ZigBee Network for Home Automation Applications,” IEEE Latin America Transactions, vol. 15, no. 5, pp. 935–942, 2017.


# Large Language Models Perform
Diagnostic Reasoning

Cheng-Kuang Wu, Wei-Lin Chen11footnotemark: 1, Hsin-Hsi Chen
National Taiwan University, Taiwan
<EMAIL_ADDRESS><EMAIL_ADDRESS>Equal contribution,
authors listed alphabetically.

###### Abstract

We explore the extension of chain-of-thought (CoT) prompting to medical
reasoning for the task of automatic diagnosis. Motivated by doctors’
underlying reasoning process, we present Diagnostic-Reasoning CoT (DR-CoT).
Empirical results demonstrate that by simply prompting large language models
trained only on general text corpus with two DR-CoT exemplars, the diagnostic
accuracy improves by 15% comparing to standard prompting. Moreover, the gap
reaches a pronounced 18% in out-domain settings. Our findings suggest expert-
knowledge reasoning in large language models can be elicited through proper
promptings.

##  1 Introduction

Figure 1: DR-CoT achieves better diagnostic accuracy and converges more
rapidly than standard prompting.

Recently, Chain-of-Thought (CoT) prompting Wei et al. (2022) has lunched a
line of works on eliciting complex reasoning for large language models (LLMs)
(Kojima et al., 2022; Madaan et al., 2022; Chen et al., 2022; Suzgun et al.,
2022). However, they mainly focus on arithmetic, commonsense, and symbolic
reasoning tasks. In this work, we extend the CoT framework to medical
reasoning. Specifically, we investigate the task of automatic diagnosis (AD),
which requires knowledge-intensive, multi-step diagnostic reasoning.

Typical patient-doctor interactions consist of an iterative question-answering
(QA) sessions. In each dialogue turn, doctors inquire patients about clinical
evidence (e.g., their backgrounds, symptoms experienced), and form a
differential diagnosis (DDx), a short list of possible diagnoses, in their
underlying reasoning (Graves, 2002; Rhoads et al., 2017). The DDx then guides
doctors in determining the next questions to ask, and patients’ answers
provide new evidence for refining the DDx. Once the list is sufficiently
narrowed, doctors can establish a final diagnosis. We hypothesize such
diagnostic reasoning process—from evidence to DDx to the next question—serves
as the hidden CoT for AD.

An ideal dialogue system for automatic diagnosis (DSAD) requires the system to
interact with patients in free-text natural language. However, prior attempts
mainly focus on the dialogue management component of DSAD, which only
processes structured information (i.e., takes symptoms as input and output the
next symptom to inquire or choose a diagnosis) (Xia et al., 2020; Liao et al.,
2020; Liu et al., 2022). Moreover, most existing works use reinforcement
learning, and can only predict 4$\sim$5 diagnoses due to the limitation of
large action space for symptoms and the lack of holistic datasets (Wei et al.,
2018; Xu et al., 2019; Zhao et al., 2021).

In this work, we propose: (1) a few-shot LLM-based dialogue system for AD. (2)
a novel Diagnostic-Reasoning CoT (DR-CoT) which elicits reasoning in LLMs
towards better AD. (3) a language-model-role-playing evaluation framework
simulating realistic patient-doctor interactions. To the best of our
knowledge, we are the first to introduce LLMs into DSAD, and present a non-
pipelined approach which in principle, has an unbounded diagnosis label set.
Empirical results show our dialogue system with DR-CoT prompting outperforms
standard prompting by a striking 15% on diagnostic accuracy (Figure 1), and
the improvement holds for out-domain experiments (Figure 2).

##  2 DR-CoT: Diagnostic-Reasoning Chain of Thought

Baseline. We construct our dialogue system based on InstructGPT (Ouyang et
al., 2022). Inspired by Few-Shot Bot (Madotto et al., 2021), we prompt the
model with the template: “[I][S][D]”, where I, S, and D denote the
instruction, shots, and dialogue history, respectively (we provide an example
in Appendix A.1). Each shot in S is a complete doctor-patient conversation,
and D refers to the dialogue history of the current incomplete conversation.
Concretely, given D $=\\{(q_{i},a_{i})\\}_{i=1,...,t-1}$, where $q_{i}$ is the
utterance generated by our dialogue system, $a_{i}$ is the utterance from the
patient, the output response at turn t is $q_{t}$. And for the next turn
$t+1$, we prompt the model with the identical I, S, and an updated D
$=\\{(q_{i},a_{i})\\}_{i=1,...,t}$. Once the model deems the gathered evidence
is sufficient, it generates a last utterance $d$ to establish the diagnosis
and complete the dialogue.

DR-CoT Prompting. To design the DR-CoT prompt, we simply apply two
modifications comparing to the standard (i.e., baseline) prompt (we provide an
example in Appendix A.2): (1) Augment I by instructing the model to first
summarize the current observed evidence and formulate a DDx, then make
inquiries based on the DDx. (2) Replace the $\\{q_{i}\\}_{i=2,...,T}\in$ S by
“Based on the evidence[E], the ranked differential diagnosis is[DDx]. To
narrow down the differential diagnosis, the next question to ask is $q_{i}$.”,
where $T$ is the number of turns and E is the observed evidence in dialogue
history. The DDx guides the model to generate a crucial $q_{i}$ that leads to
better evidence gathering, upon which the model compiles a more focused DDx,
zooming in on the final diagnosis.

Figure 2: The improvement on two out-domain testset suggests the elicited
diagnostic reasoning ability is agnostic to specific exemplars.

Evaluation Framework. Prior works generally evaluate DSAD by interacting with
a lookup-table-like patient, which responds to inquiries in a binary, non-
natural language fashion. Such setting deviates from real clinical scenarios.
For a realistic testbed, we present a language-model-role-playing framework
where the LLM plays both sides of the conversation, and performs evaluation by
self-chat (Li et al., 2019; Ghandeharioun et al., 2019).

Specifically, after the DSAD generates a $q_{i}$ at turn $i$, we construct a
patient bot by prompting LLM with the template: ”[I][S][P][D]”, where P is the
patient profile (e.g., background information, symptoms, and medical history)
and the last utterance of D is $q_{i}$ (we provide an example in Appendix
A.3). The LLM is instructed to act as a patient and generate a response
$a_{i}$ faithfully, namely, to answer $q_{i}$ based on the script provided in
P. 111We invite a physician to evaluate 100 sampled ($q_{i},a_{i}$) pairs,
where 95 $a_{i}$s are considered faithful w.r.t. P. We then append $a_{i}$ to
D for prompting our DSAD. In summary, the evaluation is fully automated by
prompting LLMs to switch between a doctor role (i.e., the DSAD) and a patient
role, and the interaction ends once the DSAD generates $d$.

Results. We adopt the DDXPlus (Tchango et al., 2022) dataset for our
experiments. Using two shots (i.e., exemplars), we conduct experiments with
in-domain (ID) setting (the exemplars and test data share the same initial
evidence; Figure 1) and out-domain (OD) setting (with different initial
evidence; Figure 2). Both settings exhibit substantial performance gain with
our DR-CoT prompting. To evaluate the accuracy in each dialogue turn $T$
(Figure 1), if the final diagnosis has not been reached, we instruct the model
to make the final diagnosis in turn $T$’s prompt (see in Appendix B.3 for
details). In addition, we conduct a small-scale human evaluation (see Appendix
C for details and results) supporting our hypothesis that DR-CoT enables LLMs
to ask more critical questions for establishing the correct diagnosis. Details
of other experimental setups including the DDXPlus dataset and the selection
of in-domain and out-domain test sets are provided in Appendix B.

##  3 Conclusion

In this work, we propose DR-CoT prompting, which elicits the diagnostic
reasoning ability in LLMs with striking empirical improvement, and introduce
the first LLM-based DSAD along with a novel language-model-role-playing
evaluation framework. Our findings suggest through proper prompting, the
potential expert-knowledge reasoning in LLMs can be unlocked for promising
applicability.

#### URM Statement

The authors acknowledge that at least one key author of this work meets the
URM criteria of ICLR 2023 Tiny Papers Track.

#### Ethics and Reproducibility Statement

In this work, we aim to provide a preliminary exploration into the diagnostic
reasoning ability of large language models. Note that the results are not
validated in any real-world clinical settings. Though with great potential of
assisting clinicians in scenarios like telemedicine services (e.g., the
doctors can review the interaction history and associated diagnosis
predictions, before making final decisions or perform further inquiries), the
current prototype of our dialogue system for automatic diagnosis is not yet
directly applicable and requires thorough investigation. To facilitate future
research, the source code for conducting the experiments will be provided via
a GitHub link in the camera-ready version upon acceptance.

## References

  * Chen et al. (2022) Wenhu Chen, Xueguang Ma, Xinyi Wang, and William W Cohen.  Program of thoughts prompting: Disentangling computation from reasoning for numerical reasoning tasks.  _arXiv preprint arXiv:2211.12588_ , 2022.
  * Ghandeharioun et al. (2019) Asma Ghandeharioun, Judy Hanwen Shen, Natasha Jaques, Craig Ferguson, Noah Jones, Agata Lapedriza, and Rosalind Picard.  Approximating interactive human evaluation with self-play for open-domain dialog systems.  _Advances in Neural Information Processing Systems_ , 32, 2019.
  * Graves (2002) Rebecca S Graves.  Users’ guides to the medical literature: A manual for evidence-based clinical practice.  _Journal of the Medical Library Association_ , 90(4):483, 2002.
  * Kojima et al. (2022) Takeshi Kojima, Shixiang Shane Gu, Machel Reid, Yutaka Matsuo, and Yusuke Iwasawa.  Large language models are zero-shot reasoners.  _arXiv preprint arXiv:2205.11916_ , 2022.
  * Li et al. (2019) Margaret Li, Jason Weston, and Stephen Roller.  Acute-eval: Improved dialogue evaluation with optimized questions and multi-turn comparisons.  _arXiv preprint arXiv:1909.03087_ , 2019.
  * Liao et al. (2020) Kangenbei Liao, Qianlong Liu, Zhongyu Wei, Baolin Peng, Qin Chen, Weijian Sun, and Xuanjing Huang.  Task-oriented dialogue system for automatic disease diagnosis via hierarchical reinforcement learning.  _arXiv preprint arXiv:2004.14254_ , 2020.
  * Liu et al. (2022) Wenge Liu, Yi Cheng, Hao Wang, Jianheng Tang, Yafei Liu, Ruihui Zhao, Wenjie Li, Yefeng Zheng, and Xiaodan Liang.  “my nose is running.” “are you also coughing?”: Building a medical diagnosis agent with interpretable inquiry logics.  In Lud De Raedt (ed.), _Proceedings of the Thirty-First International Joint Conference on Artificial Intelligence, IJCAI-22_ , pp. 4266–4272. International Joint Conferences on Artificial Intelligence Organization, 7 2022.  doi: 10.24963/ijcai.2022/592.  URL https://doi.org/10.24963/ijcai.2022/592.  Main Track.
  * Madaan et al. (2022) Aman Madaan, Shuyan Zhou, Uri Alon, Yiming Yang, and Graham Neubig.  Language models of code are few-shot commonsense learners.  In _Proceedings of the 2022 Conference on Empirical Methods in Natural Language Processing_ , pp. 1384–1403, Abu Dhabi, United Arab Emirates, December 2022. Association for Computational Linguistics.  URL https://aclanthology.org/2022.emnlp-main.90.
  * Madotto et al. (2021) Andrea Madotto, Zhaojiang Lin, Genta Indra Winata, and Pascale Fung.  Few-shot bot: Prompt-based learning for dialogue systems.  _arXiv preprint arXiv:2110.08118_ , 2021.
  * Ouyang et al. (2022) Long Ouyang, Jeff Wu, Xu Jiang, Diogo Almeida, Carroll L Wainwright, Pamela Mishkin, Chong Zhang, Sandhini Agarwal, Katarina Slama, Alex Ray, et al.  Training language models to follow instructions with human feedback.  _arXiv preprint arXiv:2203.02155_ , 2022.
  * Rhoads et al. (2017) Jacqueline Rhoads, Julie C Penick, et al.  _Formulating a Differential Diagnosis for the Advanced Practice Provider_.  Springer Publishing Company, 2017.
  * Suzgun et al. (2022) Mirac Suzgun, Nathan Scales, Nathanael Schärli, Sebastian Gehrmann, Yi Tay, Hyung Won Chung, Aakanksha Chowdhery, Quoc V Le, Ed H Chi, Denny Zhou, et al.  Challenging big-bench tasks and whether chain-of-thought can solve them.  _arXiv preprint arXiv:2210.09261_ , 2022.
  * Tchango et al. (2022) Arsene Fansi Tchango, Rishab Goel, Zhi Wen, Julien Martel, and Joumana Ghosn.  Ddxplus: A new dataset for automatic medical diagnosis.  _Proceedings of the Neural Information Processing Systems-Track on Datasets and Benchmarks_ , 2, 2022.
  * Wei et al. (2022) Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Ed Chi, Quoc Le, and Denny Zhou.  Chain of thought prompting elicits reasoning in large language models.  _arXiv preprint arXiv:2201.11903_ , 2022.
  * Wei et al. (2018) Zhongyu Wei, Qianlong Liu, Baolin Peng, Huaixiao Tou, Ting Chen, Xuanjing Huang, Kam-fai Wong, and Xiangying Dai.  Task-oriented dialogue system for automatic diagnosis.  In _Proceedings of the 56th Annual Meeting of the Association for Computational Linguistics (Volume 2: Short Papers)_ , pp. 201–207, Melbourne, Australia, July 2018. Association for Computational Linguistics.  doi: 10.18653/v1/P18-2033.  URL https://aclanthology.org/P18-2033.
  * Xia et al. (2020) Yuan Xia, Jingbo Zhou, Zhenhui Shi, Chao Lu, and Haifeng Huang.  Generative adversarial regularized mutual information policy gradient framework for automatic diagnosis.  In _Proceedings of the AAAI conference on artificial intelligence_ , pp. 1062–1069, 2020.
  * Xu et al. (2019) Lin Xu, Qixian Zhou, Ke Gong, Xiaodan Liang, Jianheng Tang, and Liang Lin.  End-to-end knowledge-routed relational dialogue system for automatic diagnosis.  In _Proceedings of the AAAI conference on artificial intelligence_ , pp. 7346–7353, 2019.
  * Zhao et al. (2021) Xinyan Zhao, Liangwei Chen, and Huanhuan Chen.  A weighted heterogeneous graph-based dialog system.  _IEEE Transactions on Neural Networks and Learning Systems_ , 2021\.

## Outline of Appendix

We provide additional details in this appendix for our work entitled “Large
Language Models Perform Diagnostic Reasoning”. The content is organized as
follows:

  * •

Section A contains examples of standard prompting (i.e., baseline) (Section
A.1), DR-CoT prompting (Section A.2), and patient bot prompting (Section A.3).

  * •

Section B contains details of DDXPlus and the selection for in-domain and out-
domain samples (Section B.1), the model (Section B.2), and the dialogue turn
setting (Section B.3).

  * •

Section C contains human evaluation results for qualitative assessment of DR-
CoT.

##  Appendix A Example Prompts

###  A.1 An Example of Standard Prompting (Baseline)

Figure 3: The initial prompt includes the instruction I, the shots S, and the
input D. The generated question $q_{i}$ of the prompted model (i.e., the DSAD)
and the answer $a_{i}$ from the patient bot is presented in the remaining text
in black.

###  A.2 An Example of DR-CoT prompting

Figure 4: The initial prompt includes the instruction I, the shots S, and the
input D. The generated question $q_{i}$ of the prompted model (i.e., the DSAD)
and the answer $a_{i}$ from the patient bot is presented in the remaining text
in black. We invite a physician to write the DDx part of the two DR-CoT
exemplars.

###  A.3 An Example of Patient Bot Prompting

Figure 5: The initial prompt includes the instruction I, the shot S, and the
input P and D. The generated answer $a_{i}$ of the prompted model (i.e., the
patient bot) and the inquired question $q_{i}$ from the DSAD is presented in
the remaining text in black.

##  Appendix B Details of Experimental setups

###  B.1 Dataset

Details of DDXPlus. Compared with other AD datasets with only 4$\sim$5
diagnoses and 40$\sim$70 types of evidence (Wei et al., 2018; Xu et al.,
2019), the DDXPlus dataset includes 49 diagnoses and 223 types of evidence.
Each instance of DDXPlus (Tchango et al., 2022) represents a patient, and we
use the following attributes of the patient for our experiments, : AGE, SEX,
INITIAL_EVIDENCE (IE), EVIDENCES (i.e., the symptoms or other clinical
findings experienced by the patient), and PATHOLOGY. The AGE, SEX, IE, and
EVIDENCES are used to construct the patient profile P based on a rule-based
template, and the PATHOLOGY is the ground truth diagnosis for computing the
diagnostic accuracy. At the beginning of each dialogue session, AGE, SEX, and
IE are provided to the doctor model to kick-start the dialogue.

In-domain and Out-domain. We refer to the test samples that share the same IE
with our two exemplars as in-domain, and the ones that do not as out-domain.
The rationale behind this notion is that the LLM only sees in-domain
exemplars’ IE, thus, other IEs are considered to be out-domain. For the
selection of in-domain (ID) and out-domain (OD) IE, we choose cough, dyspnea,
and runny nose (i.e., toux, dyspn, and rhino_clair in DDXPlus) as the IEs for
ID, OD1, and OD2 respectively. These three symptoms is the most frequently
occurred IE in the testset of DDXPlus with 618, 11305, and 6270 instances,
respectively. As accessing LLMs is costly, especially with our limited budget,
we randomly sample 200, 100, and 100 instances for ID, OD1, and OD2 to conduct
our experiments.

###  B.2 Model

For the model choice, we adopt the text-davinci-003 version of the InstructGPT
via OpenAI API222https://platform.openai.com/docs/models/gpt-3. To the best of
our knowledge, it is the most capable version of publicly available GPT-3 at
the time we conduct our experiments. As for hyperparameters, we set the
maximum tokens to 384 and the temperature to 0 (since diversity is not of
necessity for our task). The remaining hyperparameters are kept as the default
values.

###  B.3 Dialogue Turn

To evaluate the diagnosis accuracy of dialogue turn $T$, if the final
diagnosis has not been generated, we instruct the DSAD to make the final
diagnosis by inserting a prefix “[inform]” in turn $T$’s prompt (see Appendix
A.1, A.2). And to avoid lengthy dialogue, we set a pre-defined $T_{max}$ as
the maximum number of turn allowed for making the final diagnosis. We
determine $T_{max}$ by inviting a physician to interact with our patient bot,
and find that 6$\sim$8 turns are required on average. Thus, we set $T_{max}=8$
for our experiments. Similarly, if the DSAD fails to give a diagnosis before
the 8-$th$ turn, the prefix “[inform]” will be given to the DSAD to force the
prediction.

##  Appendix C Human Evaluation

One of our hypotheses is that DR-CoT guides LLMs to generate a better $q_{i}$
for collecting crucial evidence, which ultimately leads to a more accurate
final diagnosis. Establishing an accurate final diagnosis depends on two
abilities: (1) asking critical questions to collect evidence, and (2)
predicting the diagnosis based on the collected evidence. To verify that DR-
CoT prompted LLMs indeed ask better questions, we invite a physician to
evaluate the dialogues as there is no ground truth for $q_{i}$. During the
evaluation, only the $(q_{i},a_{i})$ pairs are revealed to anonymize the
promptimg methods. Table 1 summarizes the results, which show that DR-CoT
prompting enables LLMs to ask questions which are more critical for
establishing the correct diagnosis.

Table 1: Number of dialogues where the $q_{i}$s are deemed more critical for diagnosing the patient. Method | ID | OD1 | OD2
---|---|---|---
Standard | 2 | 2 | 1
DR-CoT | 18 | 8 | 9
Total | 20 | 10 | 10