
tor communicate with it to get real-time data about
the progress of an analysis. The choice of using the
STDIO transport, instead of TCP or other common
transport mechanism was heavily inspired by the Mi-
crosoft’s Language Server Protocol (LSP) implemen-
tations, where the most of the implementations use
the STDIO to communicate with an editor using a
JSON-based based protocol to send information about
a project. With this, we get a RESTful APIs commu-
nicating with JSON protocol and the model commu-
nicating also with a JSON protocol but via STDIO
with the Model’s API, this is illustrated in Figure 3,
where it shows the type of communication between
the components.
The model’s API is the entrypoint to access the
stochastic model capabilities, is responsible to spawn,
schedule, and managing the request for analysis us-
ing the model. It’s implemented as a RESTful API
that communicates with the client API for data man-
agement to provide real-time updates on the dis-
ease spread predictions and the impact of intervention
strategies. Its main concern is to bridge client APIs
and the disease spread model. It does that by manag-
ing a pool of workers for the model, where when an
analysis request is made, the job is dispatched to this
pool, where each work is run as a Docker container.
The API spawns and monitor this container STDOUT
stream, parsing its log messages containing JSON in-
formation, with this the API gets real-time data about
the progress of the model. Another important role of
this API is to aggregate the result of multiple workers.
Some analysis requests will need to dispatch hundreds
of instances of the model, and the result of the con-
tainer needs to be aggregated in representation of the
mean result of the all model instances. THe API does
that by persisting the data about the running models
in a relational database, where later will be queried to
provide the results for the client APIs. With this, it
provides a scalable model to run the stochastic mod-
els, where the work can be dispatched into a Docker
cluster to run.
With all components together, an analysis can be
made starting from the client API, where it will send
data to be analyzed to the model’s API, together with
the parameters to run the model. The model’s API
will spawn N workers to run this analysis, monitoring
and aggregating its output. In the meantime, the client
can query the API to get real-time progress about the
analysis, and when it’s done, will have full access to
the output of the model. This flow of the process is
illustrated in Figured 4
In conclusion, the proposed solution combines
multiple technologies, to provide a scalable solution
to running a stochastic model. This system offers
valuable insights for controlling the spread of dis-
eases and allocating resources for research and devel-
opment.
5 CASE STUDY SCENARIO
To evaluate the feasibility of the approach, and im-
plementation developed, a case study was developed,
This case study aims to demonstrate the use of our
application in a scenario where there’s a suspect of
a disease outbreak on premises. This application has
the main goal of helping veterinaries combat and con-
trol outbreaks proactively.
This fictional scenario is based in the everyday
work of state veterinaries in Brazil, that aims to as-
sess the effective of the application in helping the vet-
erinary control and identify other farms that could be
affected.
For the case study, the following scenario was
considered for describing the approach supported by
the developed application. Imagine ”John”, John
is official Veterinary of the State, in Brazil. As a
State Veterinary, ones of this many tasks is to audit
premises and certify that they are clean from common
diseases that could be detrimental to the livestock pro-
duction ecosystem.
One day, while conducting routine audits, John is
notified that there is simptons of a disease in Arnold’s
premises. Suspicious symptoms in some animals and
unusual mortality rates raise concerns. Recognizing
the urgency of the situation, John swiftly takes sam-
ples and sends them for testing to confirm the pres-
ence of a contagious disease.
Upon receiving the test results, John logs into the
PDSA-RS’s (Descovi et al., 2021) system to use the
disease control module to help him plan his actions.
The system provides a user-friendly interface where
he inputs the confirmed case and the relevant details.
Leveraging the application’s advanced algorithms, it
quickly analyzes the data, considering factors such
as geographical proximity, animal movement records,
and environmental conditions.
In a matter of minutes, the application generates a
comprehensive report outlining the potential risk and
identifies other premises at high risk of being affected
by the outbreak. The predictive modeling algorithms
take into account various factors, including animal
transportation networks, wind patterns, and historical
disease spread data. This gives John various infor-
mation, showing how this disease will spread infect
premises around even from other species, this is illus-
trated in Figure 5.
John is presented with a map highlighting the
A Distributed Processing Architecture for Disease Spread Analysis in the PDSA-RS Platform
317