Léonard Lys

Maria Potop-Butucaru

Distributed Blockchain Price Oracle

Keywords: Blockchain oracle, price oracle, Decentralized finance. L. Lys et al

come   L'archive ouverte pluridisciplinaire

Introduction

Decentralized finance (DeFi) is a term that emerged during the past few years to describe financial instruments that do not rely on centralized intermediaries such as brokerages exchanges or banks. In order to implement those instruments, DeFi protocols make use of smart contracts hosted on blockchain systems. Those smart contracts are programs that implement the logic of classical financial instruments. A wide range of applications is already in production, from interest-earning saving accounts to lending protocols to synthetic assets or trading platforms, etc. This industry is quickly gaining in popularity both in terms of the number of users and in market capitalization.

In order to function, a lot of those DeFi protocols make use of what is called blockchain oracles and more specifically blockchain price oracles. A price oracle is a system that provides exchange rates or prices to DeFi protocol's smart contracts. They gather data from off-chain sources, such as an API, and feed it to a smart contract on-chain. For example, a popular DeFi application consists in issuing a number of tokens to a user in exchange for collateral that will be locked in a smart contract, until the user pays back his debt. Obviously, for the for the following reporters. Our approach based on proof-of-work can be used in asynchronous settings it allows us to better sample the probability of finding a valid report.

In this paper, we follow the line of research opened by [START_REF] Breidenbach | Chainlink offchain reporting protocol[END_REF]. Differently from their approach, we consider an asynchronous communication model. In [START_REF] Breidenbach | Chainlink offchain reporting protocol[END_REF], Chainlink presents the "Off-chain Reporting Protocol", an oracle system designed, among other goals, to minimize transaction fees. Transaction fees for some blockchains have become quite prohibitive, motivating the need for such systems. The system consists of n Oracles that exchange messages through off-chain communication channels. The Oracles and their respective public keys are listed in a smart contract C. Time is divided into epochs, and a leader taken from the list of oracles is associated with each epoch. Epochs are mapped to leaders through a deterministic function. A simple modulus that can be calculated by anyone in the network. The Oracles make observations (such as price observations), sign them with their private keys, and submit them to the leader. When he received a sufficient amount of observations, the leader builds a report that lists them all, as well as the signatures, and submits it to a transmission protocol. Finally the transmission protocol hands out the report to the smart contract C. A new epoch associated with a new leader starts whenever the oracles think that the current leader does not perform correctly. While this protocol shows good resilience and low transaction fees, they assume a partially synchronous model. Formally, they assume that clocks in the system are not synchronized until a point in time called global stabilization time (GST). Afterward, all correct nodes behave synchronously. Outside those synchronous periods of time, the liveness of the protocol is not ensured. We think that by using proof-of-work for leader election, we could ensure similar properties in a fully asynchronous timing model.

Our contribution

In this paper, we formalize the distributed price oracle problem in the context of decentralized finance applications. Furthermore, we propose a protocol and prove that it verifies the specification of the problem in asynchronous communication environments prone to Byzantine failures. The protocol combines a gossip module with a light proof-of-work module and incentives oracles via a simple reputation mechanism to have a correct behavior.

Model

We consider a similar model as the one used by the chainlink off-chain reporting protocol [START_REF] Breidenbach | Chainlink offchain reporting protocol[END_REF]. The main difference is the communication model which is partially synchronous while in our system it is asynchronous.

Oracle network. The system consists in a set of n Oracles P = {p 1 , ..., p n } that are referred to as nodes. Each oracle node p i makes time-varying observations over the price of an asset pair. The set of oracles is determined by an oracle smart contract C that records the public keys of the nodes. The owner of the smart contract has administrative powers which allow him to update the list of oracles. As we are working with time-varying quantities, there is no proper way to evaluate if an observation is correct or not. Thus the protocol only guarantees that the report contains a sufficient number of observations signed by honest oracle nodes.

Nodes exchange messages through peer-to-peer, bi-directional communication channels. Nodes are identified by unique identifiers and authenticated by digital signatures. All communications are authenticated and encrypted, which means any node can authenticate any other node based on the oracle list recorded in the smart contract C. We consider an asynchronous communication model, which means that there is no global clock shared among the nodes. Moreover, we make no assumption over the reliability of the network, meaning that messages can be delayed or lost. Furthermore, messages can be delivered in a different order than the order they were sent. In the following, we assume that the network does not partition.

Failures. We consider that any f < n/3 nodes may exhibit Byzantine faults, which means that they may behave arbitrarily and as if controlled by an imaginary adversary. All non-faulty nodes are called honest or correct. We consider that these faults can occur adaptively meaning an adversary can choose and control the faulty nodes on the fly.

Cryptographic primitives. The protocol uses public-key digital signatures. We assume an idealized public-key infrastructure: each process is associated with its public/private key pair that is used to sign messages and verify signatures of other nodes. A message m sent by a process p i that is properly signed with the private key of p i is said to be properly authenticated. We denote by m σi a message m signed with the private key of a process p i . In practice, we would use the standard EdDSA and ECDSA schemes for digital signatures. It is assumed that signatures cannot be forged.

Oracle smart contract and report. The goal of the system is to produce reports containing a sufficient number of signed observations from the oracle nodes when a client requests them. Differently from Breidenbach et. al in [START_REF] Breidenbach | Chainlink offchain reporting protocol[END_REF], the reports are submitted to the oracle smart contract C by some node during a proof-of-work inspired cryptographic race. The smart contract C corresponds to a single asset pair (e.g. BTC/USD). When submitted a report, the oracle smart contract C verifies the signatures of each observation as well as the proof-ofwork. If they are valid, the oracle smart contract updates its variable lastP rice to the median of observation values contained in the report. Using the median value among more than 2f observations guarantees that the reported value is plausible in the sense that malicious nodes cannot move the value outside the range of observations produced by honest nodes. The value lastP rice can then be consumed by the requesting client or by any other user. The requesting client pays a fee for each new report he requests, which will be distributed equally among the observant nodes.

Decentralized price Oracle problem

In this section, we will define the decentralized oracle problem and review major threats and constraints that must be taken into account when designing a decentralized oracle system.

The blockchain Oracle problem is well known in the ecosystem and the grey literature. It is also described in [START_REF] Caldarelli | The blockchain oracle problem in decentralized finance-a multivocal approach[END_REF] by Cardelli et al. The oracle problem describes the ambivalence between blockchain systems that are supposed to be immutable through decentralization and oracles that, by definition, input outside world data that cannot be verified by the blockchain itself. A blockchain is a self-contained environment with its own validation rules and consensus mechanism. This isolation is what makes blockchain transactions safe and immutable. However, when data is inputted from off-chain data sources, the said data cannot be verified by the blockchain itself. A piece of software, in this case an oracle, is required to guarantee the veracity of the inputted data. As the safety of a system is limited by its weakest element, in a system where the execution of a smart contract depends on the data provided by an oracle, the oracle may be a single point of failure. This oracle problem has already led to several exploits. In 2019, an oracle reported a price a thousand times higher than the actual price [START_REF] Connell | Sophisticated trading bot exploits synthetix oracle, funds recovered (7 2019)[END_REF], which led to a one billion U.S. dollars loss. Funds have then been recovered but it shows how crucial is it to have reliable oracles. To be best of our knowledge there is no formal definition of the blockchain price oracle problem.

The price oracle smart contract can be seen as a particular single-writer multi-reader shared register. The variable of this particular shared register, lastP rice, can be read by any client of the system. This variable can be modified only by the smart contract C, and the modification is triggered each time clients invoke requestN ewP rice(). We propose below a definition of the blockchain price oracle problem in terms of liveness, integrity and uniformity. Definition 1 (Decentralized blockchain price oracle) A decentralized blockchain price oracle should satisfy the following properties :

-∆-Liveness: There exist a ∆ > 0 such that if a client invokes a price request to the smart contract C at time t > 0 then a corresponding report r will be retrieved from C within t + ∆ time. -Observation integrity: If a report with v is declared final by C, then v is the observation of a correct oracle or in the range of the observations of the two correct oracles in the system. -Uniformity: If two clients, c 1 and c 2 read the oracle lastP rice at time t > 0 then the same price report will be retrieved by both of them.

The price oracle smart contract can be seen as a shared register. The variable of this particular shared register, lastP rice, can be read by any client of the system. This variable can be modified only by the smart contract and the modification is triggered each time clients invoke price requests.

Designing distributed price oracles is not an easy task. In the following, we discuss several difficulties.

Freeloading attacks

The freeloading attack, also known as mirroring is formally described in [START_REF] Murimi | On elastic incentives for blockchain oracles[END_REF]. It refers to the technique employed by malicious oracles, that instead of obtaining data from their data source, replicate the data fetched by another oracle. Since oracle systems are often comprised of a reputation system, a "lazy" oracle could simply copy the values provided by a trusted oracle instead of making the effort of fetching the data itself. By doing so, the lazy oracle maximizes its chances of receiving its payout and avoids the cost of requesting data from sources that might charge per-query fees. As explained in [START_REF]Paradigm: Chainlink: Detailed review on the project (3[END_REF], this freeloading attack weakens the security of the system by reducing the diversity of data sources and also disincentivizes oracles from responding quickly: Responding slowly and freeloading is a cheaper strategy.

Majority attacks Much like in blockchain systems, oracle systems may be threatened by majority attacks. If an entity controls a majority of oracles in a network, it may be able to manipulate the data to provide prices that diverge from the real observable data.

Price slippage Price slippage refers to the fact that the price returned by an oracle may differ from the actual price. This may be intentional or unintentional but the result is the same. Price slippage may be the consequence of delays generated by the transaction validation time. Indeed real-world prices evolve continuously while the events on a blockchain are discrete. The state of the chain only changes when a new block is added.

Data source manipulation

The source which the data is gathered from might also be a vector of attack. Indeed, if the data source or the communication channel between the oracle and the data source can be altered, the resulting observation will ultimately be altered too.

PoWacle Protocol Overview

In this section, we propose first a high-level overview of the PoWacle protocol then propose the protocol pseudo-code.

The goal of the protocol is to publish reports containing price observations from the oracles when a client makes a request. The oracle nodes are connected to external data sources such as a market's APIs where they find their price data. When a client requests a price, the oracles will exchange messages containing hash-signed observations of the asset's price. It is very important to note that the content of the observations exchanged is not readable by the other oracles, as they are hashed observations. This is to avoid the freeloading problem. Each oracle node listens for incoming hash-signed observation messages and much like in a proof-of-work-based blockchain builds a pool of messages in their local memory. The difference with a proof-of-work-based blockchain is that instead of transactions, the pool contains hash-signed price observations, and instead of producing a block of transactions, the goal is to produce a report containing the said observations. To select the oracle that will be responsible for proposing and publishing the report, a proof-of-work protocol is applied. Once they have received hash-signed observations from a sufficient number of nodes, i.e. more than 2f + 1, the oracles start the report mining process. They try to build a report proposal whose hash value is inferior to some target difficulty number. When a node finds a report proposal whose hash value is inferior to the target difficulty number, he broadcasts the report proposal to the network. On receiving the report proposal, the other nodes return the readable pre-image of their hashsigned observations. For each received observation, the proposer verifies that the observation matches its hash. Once he has collected at least 2f + 1 clear observations, he submits the report proposal to the oracle smart contract along with the proof-of-work. The oracle smart contract verifies the proof-of-work, the match between observations and their hashes, and the signatures. Once all verifications are done, the smart contract calculates the median of the received observations and updates the price of the asset. The price can then be consumed by the client. The smart contract calculates the payout and updates the reputation of the oracle nodes.

The incentive mechanism is designed such that each oracle that produced an observation will be paid equally. Thereby, the report proposer, the one that won the proof-of-work and published the report to the chain, has not more incentives than the other oracles. This should help to limit the computing power that the oracles will put in the network, and thus the operating cost of the system. In the meantime, the oracles are still encouraged to find valid reports regularly, as this is the way they get paid. The goal is to have an incentive equilibrium between producing reports regularly and having a low operating cost in terms of computing power.

Let us unfold the main steps of the protocol:

1. The client requests a new price to the smart contract C and pays a fee.

2. The oracles pick up the request and gather price data from their data sources. They create their observations, hash and sign them. They broadcast it to the oracle network through gossiping. 3. On receiving the hashed signed observations, the nodes verify the signatures.

If they are correct, they add the observation to their local memory. Once they have received a sufficient number of hashed signed observations, i.e., above the 2f + 1, the oracles sequentially rearrange their report and a nonce until they find a report proposal whose hash value is below a target difficulty number. 4. The first oracle to find a valid report proposal broadcast it to the oracle network via gossiping. 5. On receiving a valid report proposal, the oracles whose observations were contained in the report return the readable pre-images of their hashed signed observations to the candidate leader. 6. Once he has collected enough pre-images, the proposer verifies that they match their hashes. If they do match, he submits the report to the smart contract C.

7. On receiving a report proposal, the smart contract C verifies the signatures of each individual observation as well as the matching between clear observation and their hash. If everything matches, the smart contract verifies the proof of work. It also verifies that there are at least 2f + 1 clear observations in the report. Once all checks are passed, the smart contract updates the price, making it available to the client. The report becomes final. 8. The smart contract C calculates the payouts and updates the reputations.

Protocol detailed description

We provide a detailed description of the protocols using an event-based notation (e.g. [START_REF] Cachin | Introduction to reliable and secure distributed programming[END_REF] Chap. 1).

The protocol consists of an oracle smart contract hosted on a blockchain presented in Algorithm 1 and an oracle network. The nodes in the oracle network react to events triggered by the oracle smart contract C. The oracle nodes can at any time read the state and the variables of C. Protocol instances that run on the same oracle node (instances of Algorithm 2,3 and 4) also communicates trough events. In the following, Algorithm 1 is the oracle smart contract C, Algorithm 2, executed by every node is a daemon that reacts to events triggered by C. Algorithm 3 is the observation gossip protocol and Algorithm 4 is the report mining protocol.

The Smart Contract (C)

The protocol Algorithm 1 is orchestrated by an oracle smart contract C hosted on a blockchain. Each oracle smart contract represents a price feed for a single pair of assets, for example, USD/BTC for bitcoin versus U.S. dollars. The oracle smart contract C consists of four primitives; identity, proof-of-work, incentive, and reputation. We will review individually each primitive in this section.

Identity. The oracle smart contract is responsible for storing the identity of the oracles nodes. It maintains a list of oracle nodes and their public keys. The set of oracles is managed by an owner with administrative power. How the administrator curates the list of authorized oracles is behind the scope of this document. The oracle list is used to verify signatures.

Proof-of-work. The proof-of-work primitive is responsible for verifying the proof-of-work that is submitted along with each report. It verifies the match between hash-signed and clear observation, verifies that there are more than 2f clear observations, requests the identity primitive to verify the signatures, and finally verifies the proof-of-work. To do so, it checks that the submitted report header hash value is below the target difficulty number. If so, the report is final and the contract updates the last price value, making it available to the client.

The proof-of-work primitive is also responsible for adjusting the difficulty target number. To do so it uses a system similar to Bitcoin's difficulty adjustment [START_REF] Nakamoto | Bitcoin: A peer-to-peer electronic cash system[END_REF]. For each new request, the smart contract C records the time difference between the moment the request was made by the client, and the moment the corresponding report was submitted. Then for every new report, the contract calculates the average report generation time over the last hundred reports. It then adjusts the target difficulty number to have a stable average report generation time. To do so, it multiplies the current difficulty target number by a ratio between observed and desired report generation time. Target report generation time is specified by the owner with administrative power. What value should be chosen is out of the scope of this document and would require further analysis.

Incentive. The incentive primitive calculates and broadcasts the payouts to the oracles. For each final report, the contract C pays an equal share of the total fee to each oracle that produced an observation that was included in the report.

As introduced earlier, the incentive system must be designed to create an incentive equilibrium between producing reports regularly and having a low operating cost in terms of computing power. Thus, the payout received by the report publisher will be equal to the payouts received by the other oracles that produced an observation contained in the report. The only difference is that the report producer gets his transaction fees refunded.

In order to reduce transaction fees, the payout is not automatically transferred at each report. Instead, the smart contract C records the total payout each oracle is eligible to, and they can cash out on request.

Reputation. The reputation system is primarily used by the oracles to prioritize the observation they will include in their report proposal. Indeed, an adversarial oracle could choose not to send back his clear observation at stage 7, thus slowing down protocol execution. To minimize this risk, each oracle is associated with a reputation number corresponding to the number of his observations that have been included in past valid reports. When an oracle tries to find a valid report proposal, it is in his interest to prioritize observations from nodes that have a high reputation number. When a submitted report becomes final, the smart contract increases by one the reputation number of each oracle that produced an observation contained in the said report.

The oracle network

In this section, we detail the algorithms executed by nodes in the oracle network. It consists of three algorithms. Algorithm 2 is a daemon that listens for event triggered by C. Algorithm 3 is instantiated by every p i for each new request by the daemon. Its role is to propagate and collect observations among the network. Algorithm 4 is the report mining protocol. Its role is to build a report proposal out of the delivered observation and eventually submit this report to the oracle smart contract C. The oracle smart contract C maintains a list of oracles, their public keys, and their reputation. C at any time. They can access the list of oracles, their public keys, reputation, current request-id, and current target difficulty number. Those public variables are used implicitly in the pseudo-code presented here. We denote by sign i (m) the function that signs the message m with the private key of process p i producing the signed message m σi . Similarly verif y i (m σi ) verifies the signature of signed message m σi with the public key of process p i .

The daemon. Algorithm 2 is a deamon that is executed continuously by every process. This deamon awaits for newRequest events from C to instantiate the observation gossip protocol presented in Algorithm 3. It is also responsible for stopping instances of Algorithm 3 and Algorithm 4 when a f inalReport event is emitted by C. The observation gossip protocol. Algorithm 3 is the observation gossip protocol. Its goal is for the nodes to propagate observations messages among the network. It is instantiated by Algorithm 2 upon new request event emitted by C. Oracle nodes gather data from sources, hash and sign their observation, and broadcast it to every p i ∈ P . Every oracle p i maintains a list hashSignObs of hashed-signed observations delivered by any p j ∈ P . When a node p i has received at least 2f + 1 hashed-signed observations, he starts the report mining protocol presented in Algorithm 4. For the sake of simplicity and readability, we separated Algorithm 3 and Algorithm 4. In practice, those algorithms will be executed in parallel on a single machine and thus share the same local memory. This means that when Algorithm 3 starts a report mining instance for request requestID, the list of hashed observations hashSignObs can still be updated by the observation gossip protocol. The report gossip protocol continues execution even if the report mining process has started. It is in the interest of the nodes to include as many observations as possible in their report proposal to minimize the chances of an adversarial oracle blocking execution. This will be further developed in the paragraph about the report mining process. Yet it must be noted that the abort condition of the observation gossip process is a f inalReport event from C. rearrange the content of the report until the hash value of the report header is below a target difficulty number. Each report maintains a pool hashSignObs of n pending observations that have not been yet included in a report. An observation has three attributes, the target asset pair, the observed price, and a timestamp. To this observation correspond an observation header that contains the public key of the oracle, the hash of the observation, and the oracle's signature. When oracle nodes try to find a valid report, they don't hash the full report. Instead, much like in a proof-of-work-based blockchain, they only hash the header of the report. This header consists of a timestamp a nonce and most importantly the observations hash. The observations hash would correspond in a proof-ofwork blockchain to the Merkle root. But because we don't need simple payment verification, building a Merkle tree out of the list of observations is unnecessary. Hashing the concatenated list of observations is sufficient in our case.

The way nodes rearrange their hash-signed observation list to find a valid report proposal is not explicitly developed in Algorithm 4. Indeed, similarly to proof-of-work-based mining, it is the responsibility of the nodes to find a strategy that maximizes their rewards and reduces their costs. However, we would advise that they rearrange their list according to the reputation of the other nodes. Indeed, the only way for an adversarial oracle to slow down or block protocol execution is not to respond with an OBSERVATION message on receiving a REPORT-PROPOSAL message. In order not to include dishonest parties in their report proposal, oracles should prioritize observations from oracles that have a good reputation. It is to be noted that to be considered valid by the smart contract C, a report does not need to have a clear observation for every hash-signed observation contained in the hashSignObs list. Indeed, the only requirement is that the report contains at least 2f + 1 clear observations.

Analysis

In this section, we prove that the PoWacle protocol satisfies the properties of the oracle problem definition as presented in Section 3.

Lemma 1. The PoWacle protocol satisfies the liveness property of a decentralized blockchain price oracle.

Proof. Consider a client request made to C at time t. Every correct node is triggered by this event and broadcasts its observation to every p j ∈ P . Recall that correct oracles resend every message until the destination acknowledges it.

Even if an adversary coalition can choose faulty nodes on the fly, they can not control more than f < n/3 process. Thus every correct oracle should eventually deliver a hash-signed observation from every correct node. This also holds for the process where nodes send clear observations to the proposer. Consequently, every correct node should be able to start the mining process. Let d > 0 be the difficulty target number. Due to the uniformity and non-locality properties of hash functions (outputs should be uniformly distributed), for each trial, there is a non-zero chance of finding a report whose hash value h is less or equal than the difficulty d. Consequently, there is a finite ∆ within which an oracle should find and submit a valid report to C. Because the observations contained in the report are from correct nodes, C should declare the report final. Thus the protocol satisfies the ∆-Liveness property of a decentralized blockchain price oracle.

Lemma 2. The PoWacle protocol satisfies the observation integrity property of a decentralized blockchain price oracle.

Proof. Consider a protocol execution where a report with value v has been declared final by C. To be considered final by C, a report must contain at least 2f + 1 observations that have been individually signed by each oracle. The value v is the median of those observations. Since there are at most f faulty nodes, out of the 2f +1 observations, more than half have been produced by a correct node.

Trivially, the median of those observations is either the one of a correct node or the one of a faulty node but in the interval between a larger and a smaller value provided by honest nodes. Thus, the protocol satisfies the observation integrity property of a decentralized blockchain price oracle.

Lemma 3. The PoWacle protocol satisfies the uniformity property of a decentralized blockchain price oracle.

Proof. Recall that the value lastP rice of C can only be updated by the smart contract itself when requestN ewP rice is invoked by a client. Thus trivially, if two clients c 1 and c 2 read this value at some time t > 0, the value they will read corresponds to the same report.

Conclusions

Price oracles are at the core of various applications in Decentralized Finance. It should be noted that due to security attacks these oracles are difficult to design in a distributed fashion. In this paper, we propose and prove correct the first distributed price oracle designed for asynchronous Byzantine prone environments.

Price oracles have some similarities with classical distributed shared registers however, the presence of smart contracts (pieces of code) that automatically execute on an underlying blockchain make their particularity. In future works, we would like to investigate how price oracles can benefit from the existing distributed system literature. In the same vein, we will like to investigate new distributed abstractions that encapsulate the blockchain technology specificity.

▷

  Adjust the difficulty by a factor of the ratio between observed and desired report generation time function registerOracle(publicKey) ▷ Function restricted to administrator oracles.append([publicKey, 0]) ▷ Register new oracle and set reputation to 0 function setT argetReportT ime(time) ▷ Function restricted to administrator targetReportT ime ← time

Algorithm 2

 2 Oracle daemon executed continuously by every p j ∈ P Upon event newRequest(requestID) from C do initialize instance (requestID) of observation gossip protocol Upon event f inalReport(requestID) from C do abort instance gossip protocol (requestID) abort instance report mining (requestID)

  The client makes his request to the smart contract C. The instances of Algorithm 3 and Algorithm 4 can read the state of

	Algorithm 1 Oracle smart contract
	state
	lastP rice ← ⊥ : last valid reported price
	reports ← [⊥] : table of valid reports
	oracles ← [⊥] n : list of oracles' public keys and their reputation
	targetDif f iculty ← 0 : current difficulty target number
	tergetReportT ime ← 0 : Target report generation time
	function requestN ewP rice()
	reports[requestID].requestSubmitted ← time.now
	Emit event newRequest()
	function verif yP roof Of W ork(reportHeader)
	return hash(reportHeader) ≤ targetDif f iculty
	function verif ySignatures(hashSignObs)
	return ∀ hσ reputation + 1|
	adjustDif f iculty()
	Emit event f inalReport(requestID)
	end if
	function adjustDif f iculty()
	l = reports.length
	sum ←	l i=l-100 reports[i].requestF ulf illed -reports[i].requestSubmitted
	averageReportT ime ← sum/100	▷ Calculate the average report generation time
	over the last 100 reports
	targetDif f iculty ← targetDif f iculty * averageReportT ime targetReportT ime

i ∈ hashSignObs|verif yi(hσ i )| function verif yHashes(hashSignObs, observe) return ∀oi ∈ observe|hash(hashSignObs[i] = hash(oi))| function submitReport(requestID, [reportHeader, hashSignObs, observe]) if verif yP roof Of W ork(reportHeader) ∧ verif ySignatures(hashSignObs) ∧ verif yHashes(hashSignObs, observe) ∧ observe.length ≥ 2f + 1 then reports[requestID] ← [reportHeader, observe, hashSignObs] reports[requestID].requestF ulf illed ← time.now lastP rice ← median(observe) ∀oi ∈ observe|oracles[i].reputation ← oracles[i].

  The report mining protocol Algorithm 4 presents the report mining process. Much like in a proof-of-work-based blockchain the principle is for the oracles to Algorithm 3 Observation gossip protocol instance requestID (executed by every oracle p i )

	state
	observe ← [⊥] n : table of observations received in OBSERVATION messages
	hashSignObs ← [⊥] n : table of hashed signed observations received in HASHED-
	OBSERVATION messages
	Upon initialization do
	v ← gather price value from data source
	observe[i] ← [time.now, assetP air, v]
	hashSignObs[i] ← signi(hash(observe[i]))
	send message[HASHED-OBSERVATION, hashSignObs[i]] to all pj ∈ P
	Upon receiving message [HASHED-OBSERVATION, hσ j ] from pj do
	if verif yj(hσ j ) then
	hashSignObs[j] ← hσ j
	end if
	Upon |{pj ∈ P |hashSignObs[j] ̸ = ⊥}| = 2f + 1 do
	initialize instance report mining (requestID)
	Upon receiving message [REPORT-PROPOSAL,hashSignObs ′ ,reportHeader]
	from p l do
	if hashSignObs[i] ∈ hashSignObs ′ then
	if {∀ hσ j targetDif f iculty ∧ hashSignObs ′ .length ≥ 2f + 1 then ∈ hashSignObs ′ |verif yj(hσ j )|} ∧ hash(reportHeader)	≤
	send message[OBSERVATION, observe[i]] to p l
	end if
	end if

  Algorithm 4 Report mining algorithm instance requestID executed by every p i that has delivered more than 2f + 1 hash-signed observation

	state
	reportHeader ← ⊥
	Upon initialization do
	loop
	nonce ← 0
	hashSignObs to
	all pj ∈ P
	break
	end if
	nonce ← nonce + 1
	end while
	end loop
	Upon receiving message [OBSERVATION, oj] from pj do
	if hash(oj) = hashSignObs[j] then
	observe[j] ← oj
	end if
	Upon observe.length ≥ 2f + 1
	C.submitReport(requestID, [reportHeader, hashSignObs ′ , observe]

′ ← prioritize(hashSignObs) ▷ Create a prioritized copy of the hash-signed observation list while reportHeader = ⊥ ∨ nonce ̸ = 2 32 do if hash(time.now, nonce, hash(hashSignObs ′ )) ≤ targetDif f iculty then reportHeader ← [time.now, nonce, hash(hashSignObs ′ )] send message[REPORT-PROPOSAL, hashSignObs ′ , reportHeader]


Joanna Kedra

Thomas Davergne

Ben Braithwaite

Hervé Servy

Laure Gossec

Machine learning approaches to improve disease management of patients with rheumatoid arthritis: review and future directions

Keywords: (4-10): artificial intelligence, artificial neural networks, deep learning, diagnosis, machine learning, monitoring, prediction, random forests, rheumatoid arthritis, support vector machine

published or not. The documents may come

Machine learning approaches to improve disease management of patients with rheumatoid arthritis:

review and future directions

Introduction

Rheumatoid arthritis (RA) is the most frequent autoimmune rheumatic disease, leading to extensive arthritis involving small joints, and ultimately to joint destruction [START_REF] Sparks | Rheumatoid Arthritis[END_REF]. Early diagnosis, appropriate management of the disease and identification of factors associated with poor outcomes are therefore key issues to avoid functional impairment and deleterious consequences of the disease [START_REF] Aletaha | Diagnosis and Management of Rheumatoid Arthritis: A Review[END_REF]. During the last two decades, the development of targeted disease modifying anti-rheumatic drugs such as biologics, combined with paradigm shifts such as treat-to-target strategies, have contributed to the improvement of short-and long-term outcomes in RA [START_REF] Aletaha | Diagnosis and Management of Rheumatoid Arthritis: A Review[END_REF][START_REF] Smolen | EULAR recommendations for the management of rheumatoid arthritis with synthetic and biological disease-modifying antirheumatic drugs: 2019 update[END_REF].

Nevertheless, this disease still represents an important burden for patients and for society in terms of costs, and there is a need to develop more personalized approaches, in order to enable patients to receive the treatment that will best suit their situation, as quickly as possible.

We are living in the era of Big Data (i.e., extremely large data sets that are accumulating rapidly, from various sources, and characterized by their Volume, Value, Veracity, Velocity and Variability). Novel statistical approaches are increasingly used to analyze these data [START_REF] Topol | The big medical data miss: challenges in establishing an open medical resource[END_REF]. These methods specifically involve Artificial Intelligence (AI), i.e., the ability of a machine to mimic certain human abilities, such as calculation, learning or problem solving [START_REF] Abidi | Intelligent health data analytics: A convergence of artificial intelligence and big data[END_REF]. AI includes several types of algorithms, of which the best known and most used to date are Machine Learning (ML) methods [START_REF] Noorbakhsh-Sabet | Artificial Intelligence Transforms the Future of Health Care[END_REF]. These consist in models which, after "training" on a sample dataset, allow the development of predictions or decisions without being explicitly programmed to do so [START_REF] Koprowski | Machine learning and medicine: book review and commentary[END_REF]. ML includes different algorithms such as: artificial neural networks, deep learning, decision trees, support-vector machines, or Bayesian networks [START_REF] Doupe | Machine Learning for Health Services Researchers[END_REF][START_REF] Baştanlar | Introduction to machine learning[END_REF] (Table 1).

These methods have several applications in our daily lives, such as email filtering, speech recognition or computer vision, and are also applied to health research [START_REF] Esteva | A guide to deep learning in healthcare[END_REF]. Indeed, ML makes it possible to extract patterns within patient data and exploit these patterns to predict patient outcomes for improved clinical management [START_REF] Stafford | A systematic review of the applications of artificial intelligence and machine learning in autoimmune diseases[END_REF]. Even if applications of ML in rheumatology are currently hindered by the heterogeneity and complexity of rheumatic diseases, small cohort sizes and varying effect sizes of different molecular and clinical factors [START_REF] Pandit | Machine learning in rheumatology approaches the clinic[END_REF], ML studies in RArelated research are increasingly being published and provide promising potential answers to the unmet needs in this disease.

The aim of the present narrative review is therefore to describe the applications of ML methods in RA, for diagnosis, monitoring and prediction of response to treatments, and to explore future directions for AI research in RA (Table 2).

To ground our review, a scoping literature search in PubMed Medline was performed using the following MeSH terms: "arthritis, rheumatoid" and "machine learning" until September 2021. We will present the results of this literature review, combined with the authors' opinion, in different sections below.

Usefulness for diagnosis

Detecting RA early is a key issue in rheumatology, given that the first months of the disease's course determine the short-and long-term outcomes [START_REF] Aletaha | Diagnosis and Management of Rheumatoid Arthritis: A Review[END_REF]. ML may be particularly helpful to establish a diagnosis of RA, particularly in situations when other diagnoses, such as osteoarthritis or psoriatic arthritis are plausible.

Diagnosis based on Electronic Health Records

Clinical data sources are the most commonly used source of data in "big data" studies in the field of rheumatic and musculoskeletal diseases (RMDs), representing 47% of publications [START_REF] Kedra | Current status of use of big data and artificial intelligence in RMDs: a systematic literature review informing EULAR recommendations[END_REF]. Electronic Health Records (EHRs) are one of the most important sources of clinical data. Such data sources are interesting for healthrelated research, given that these data are collected routinely, and therefore reflect real-world care, which allows assessment of the benefits and risks of different medical treatments in real life conditions. Moreover, as these data are collected automatically, studies based on so called "real-world data" are faster to conduct than random controlled trials. As they gather data from thousands to millions of patients (for national healthcare EHRs) and are not formatted explicitly to provide precise clinical information (such as the severity of a given disease), ML methods may be helpful to identify patients with a given disease. Moreover, ML methods may be timesaving, given that these algorithms usually run in several seconds or minutes, whereas tens to hundreds of hours would be necessary for a physician to check the files of thousands of patients.

A first study in the Netherlands and Germany, based on Leiden and Erlangen EHRs, aimed to compare the ability of 6 different ML algorithms and a naïve wordmatching algorithm to accurately identify patients with RA [START_REF] Maarseveen | Handwork vs machine: a comparison of rheumatoid arthritis patient populations as identified from EHR free-text by diagnosis extraction through machine-learning or traditional criteria-based chart review[END_REF]. A support vector machine method performed well, with an area under the receiver operating characteristic curve (AUROC) of 0.98, and a positive predictive value (PPV) of 0.94. This means that almost all RA patients were identified by the algorithm [START_REF] Maarseveen | Handwork vs machine: a comparison of rheumatoid arthritis patient populations as identified from EHR free-text by diagnosis extraction through machine-learning or traditional criteria-based chart review[END_REF]. This method was able to identify 2,873 patients with RA from 23,300 patients in the EHR in less than 7 seconds. Another study by the same Dutch team compared the performance of a support vector machine model and manual chart reviewing in identifying RA patients; here again, the ML model performed well, with sensitivity=0.85, specificity=0.99, PPV=0.86, and negative predictive value=0. 99 (15).

A Welsh study aimed to use data-driven methods to develop and validate a disease phenotyping algorithm for RA using primary care EHRs [START_REF] Zhou | Defining Disease Phenotypes in Primary Care Electronic Health Records by a Machine Learning Approach: A Case Study in Identifying Rheumatoid Arthritis[END_REF]. In this study, data were available for 2,238,360 patients aged 16 or more, and of these, 20,667 patients were also linked in the secondary care rheumatology clinical system.

Overall, 900 predictors (out of a total of 43,100 variables) in the primary care record were discovered more frequently in those with RA versus those without. Among these 900 predictors, 37 variables were selected to develop a decision tree model.

The final algorithm identified 8 predictors related to diagnostic codes for RA, medication codes, such as those for disease modifying anti-rheumatic drugs (DMARDs), and absence of alternative diagnoses such as psoriatic arthritis [START_REF] Zhou | Defining Disease Phenotypes in Primary Care Electronic Health Records by a Machine Learning Approach: A Case Study in Identifying Rheumatoid Arthritis[END_REF]. The proposed data-driven method performed as well as the expert clinical knowledgebased methods. Thus, ML methods may be useful in accurately and quickly identifying patients with RA from EHRs, in order to consider them in clinical research studies.

Diagnosis based on biological samples

So-called "omics data" (proteomics, genomics, metabolomics, metagenomics and transcriptomics) are an important data source, and may be helpful for the diagnosis of rheumatic diseases [START_REF] Kedra | Current status of use of big data and artificial intelligence in RMDs: a systematic literature review informing EULAR recommendations[END_REF]. RA is characterized by the presence of auto-antibodies, such as rheumatoid factor (RF) and anti-citrullinated peptide auto-antibodies (ACPA) [START_REF] Derksen | The role of autoantibodies in the pathophysiology of rheumatoid arthritis[END_REF]. However, RF can also be positive in other conditions, such as Sjögren's syndrome, as well as in some infectious diseases, such as endocarditis [START_REF] Fayyaz | Autoantibodies in Sjögren's Syndrome[END_REF][START_REF] Ghosh | A Study of Clinical, Microbiological, and Echocardiographic Profile of Patients of Infective Endocarditis[END_REF].

Conversely, around 20% of RA patients are seronegative for antibodies, which raises the question of the accuracy of the diagnosisas other inflammatory rheumatic conditions may have clinical patterns similar to RA [START_REF] Park | Prognostic Factors for Radiographic Progression in Patients with Seronegative Rheumatoid Arthritis[END_REF]. For all these reasons, identification of additional biomarkers is necessary to improve the diagnosis of RA and also other RMDs. A study identified a set of 12 chemokines (TGFα, EGF, CD40L, IFNγ, MIP-1β, eotaxin, TNFα, IL-1α, GRO, G-CSF, fractalkine) with levels significantly different between patients with RA, patients with osteoarthritis, and patients with no rheumatic condition [START_REF] Heard | A computational method to differentiate normal individuals, osteoarthritis and rheumatoid arthritis patients using serum biomarkers[END_REF]. Based on this set, 2 artificial neural networks were developed, each diagnosing 100% of test set patients correctly.

Another study revealed that serum proteins measured by multiple reaction monitoring significantly differed between patients with RA and those with psoriatic arthritis; the random forest model built for this purpose had an area under the curve (AUC) of 0.79 in a first phase and 0.85 in a second phase of validation, reflecting good performances to distinguish RA from psoriatic arthritis patients [START_REF] Mc Ardle | Identification and Evaluation of Serum Protein Biomarkers Which Differentiate Psoriatic from Rheumatoid Arthritis[END_REF].

The analysis of genomics data with ML methods may be also helpful in RA diagnosis [START_REF] Pratt | A CD4 T cell gene signature for early rheumatoid arthritis implicates interleukin 6-mediated STAT3 signalling, particularly in anticitrullinated peptide antibody-negative disease[END_REF][START_REF] Xiao | Coupling of Co-expression Network Analysis and Machine Learning Validation Unearthed Potential Key Genes Involved in Rheumatoid Arthritis[END_REF][START_REF] Yeo | Expression of chemokines CXCL4 and CXCL7 by synovial macrophages defines an early stage of rheumatoid arthritis[END_REF][START_REF] Rychkov | Cross-Tissue Transcriptomic Analysis Leveraging Machine Learning Approaches Identifies New Biomarkers for Rheumatoid Arthritis[END_REF][START_REF] Chaerkady | Characterization of Citrullination Sites in Neutrophils and Mast Cells Activated by Ionomycin via Integration of Mass Spectrometry and Machine Learning[END_REF][START_REF] Ahmed | Protein oxidation, nitration and glycation biomarkers for early-stage diagnosis of osteoarthritis of the knee and typing and progression of arthritic disease[END_REF][START_REF] Zhang | Predicting Citrullination Sites in Protein Sequences Using mRMR Method and Random Forest Algorithm[END_REF][START_REF] Negi | A genome-wide association study reveals ARL15, a novel non-HLA susceptibility gene for rheumatoid arthritis in North Indians[END_REF]. Based on random forest models, a study identified a set of 9 mRNAs (CFL1, COTL1, ACTG1, PFN1, LCP1, LCK, HLA-E, FYN, and HLA-DRA) enabling to distinguish RA samples from healthy samples, with AUCs between 0.95 and 1.00 according to the models [START_REF] Liu | A 9 mRNAs-based diagnostic signature for rheumatoid arthritis by integrating bioinformatic analysis and machine-learning[END_REF]. Another study, based on a panel of micro-RNAs (miR-22-3p, miR-24-3p, miR-96-5p, miR-134-5p, miR-140-3p, and miR-627-5p), used ML methods to differentiate RA patients from systemic lupus erythematosus (SLE) patients and healthy subjects; these methods differentiated RA from control subjects in discovery (AUC=0.81) and validation cohorts (AUC=0.71), seronegative RA (AUC=0.84), RA patients in remission (AUC=0.85), and patients with SLE (AUC=0.80) versus controls [START_REF] Ormseth | Development and Validation of a MicroRNA Panel to Differentiate Between Patients with Rheumatoid Arthritis or Systemic Lupus Erythematosus and Controls[END_REF]. Random forests, k-nearest neighbors, support vector machine, naïve-Bayes and a tree-based method applied to a set of 16 genes (TMOD1, POP7, SGCA, KLRD1, ALOX5, RAB22A, ANK3, PTPN3, GZMK, CLU, GZMB, FBXL7, TNFRSF4, IL32, MXRA7, and CD8A) were used to distinguish RA from osteoarthritis, with a good accuracy for each of these methods (0.91 to 0.96) [START_REF] Long | Efficacy of Integrating a Novel 16-Gene Biomarker Panel and Intelligence Classifiers for Differential Diagnosis of Rheumatoid Arthritis and Osteoarthritis[END_REF].

Genomics data have also been used to identify RA sub-types in patients based on histologic data from synovial tissue samples. The severity of RA symptoms is variable from patient to patient, and it has been reported that this may be the result of distinctive gene expression profiles [START_REF] Zhang | Defining inflammatory cell states in rheumatoid arthritis joint synovial tissues by integrating single-cell transcriptomics and mass cytometry[END_REF][START_REF] Stuhlmüller | Genomic stratification by expression of HLA-DRB4 alleles identifies differential innate and adaptive immune transcriptional patterns -A strategy to detect predictors of methotrexate response in early rheumatoid arthritis[END_REF]. To investigate these findings, a study applied consensus clustering techniques to gene expression data in order to identify different synovial sub-types. 129 synovial samples were used to identify 20 histologic features, which were used to cluster the gene expression data from a subset of 45 samples 1000 times each into 2, 3, or 4 groups. The ML algorithm was able to identify 3 subgroups: a high inflammation subgroup characterized by extensive infiltration of leukocytes (AUC=0.88), a low inflammation subgroup characterized by enriched growth factor , glycoprotein, and neuronal gene pathways (AUC=0.71), and a mixed subgroup (AUC=0.59) [START_REF] Orange | Identification of Three Rheumatoid Arthritis Disease Subtypes by Machine Learning Integration of Synovial Histologic Features and RNA Sequencing Data[END_REF].

Thus, these studies indicate the value of ML methods to improve diagnosis based on -omics, and ultimately, to potentially enable the development of novel biological tests to diagnose RA [START_REF] Long | Efficacy of Integrating a Novel 16-Gene Biomarker Panel and Intelligence Classifiers for Differential Diagnosis of Rheumatoid Arthritis and Osteoarthritis[END_REF][START_REF] O'neil | Association of a Serum Protein Signature With Rheumatoid Arthritis Development[END_REF][START_REF] Chocholova | Glycomics meets artificial intelligence -Potential of glycan analysis for identification of seropositive and seronegative rheumatoid arthritis patients revealed[END_REF]. Moreover, apart for diagnosis, novel systems for disease phenotyping from mild to severe by means of and on terms identified by ML could be of utmost importance for basic research (disease pathophysiology), clinical management (e.g. patients at-risk for fast versus slow progression) and ultimately for deciding how tightly the control of the disease should be pursued.

Diagnosis based on imaging and image recognition

Numerous big data studies in RMDs are based on imaging data [START_REF] Kedra | Current status of use of big data and artificial intelligence in RMDs: a systematic literature review informing EULAR recommendations[END_REF]. Given that a single imaging exam compiles a huge amount of data, this field is particularly conducive to the use of ML methods [START_REF] Morris | Reinventing Radiology: Big Data and the Future of Medical Imaging[END_REF][START_REF] Landewé | Big Data » in Rheumatology: Intelligent Data Modeling Improves the Quality of Imaging Data[END_REF].

In a study based on 1000 hand photographs from 280 patients with hand arthritis, ML algorithms were developed to classify those patients as having RA, osteoarthritis or psoriatic arthritis [START_REF] Reed | A pilot study of a machine-learning tool to assist in the diagnosis of hand arthritis[END_REF]; the reference diagnosis was provided by a physician after a 45-minutes consultation. These algorithms were able to classify inflammatory arthritis with an accuracy of 96.8% and a precision of 97.2%.

It has been established that some imaging techniques, and particularly ultrasonography (US), depend on the examinator's experience [START_REF] Chung | Interreader Concordance of the TI-RADS: Impact of Radiologist Experience[END_REF][START_REF] Klara | Reliability and Accuracy of Cross-sectional Radiographic Assessment of Severe Knee Osteoarthritis: Role of Training and Experience[END_REF]. In this context, ML may aid diagnosis by automatically analyzing US images. A literature review identified 11 main ML methods currently used in ultrasound computer-aided diagnosis systems, and RA was one of the 4 rheumatic conditions for which these innovative systems were used the most, with an overall accuracy of more than 75% [START_REF] Gutiérrez-Martínez | Key example of the use of machine learning for the diagnosis of rheumatoid arthritis based[END_REF]. Combining US images with clinical and biological information may also allow a faster and more accurate diagnosis of RA; a Japanese team used a pretrained convolutional neural network algorithm, AlexNet, to classify patients as RA or non-RA, based on US images and clinical settings (45). The accuracy of this method was of 90 to 98%, and agreement between this algorithm and clinical diagnosis was satisfactory (Cohen's kappa=0.79 to 0.87).

ML methods may also be applied to other imaging techniques. A study based on diffuse optical tomography of proximal interphalangeal joints showed that the use of a polynomial SVM classifier helped for diagnosing RA with a sensitivity of 100.0% and a specificity of 97.8% [START_REF] Montejo | Computer-aided diagnosis of rheumatoid arthritis with optical tomography, Part 2: image classification[END_REF]. Other studies developed automated algorithms to detect synovitis on magnetic resonance imaging (MRI), and compared results from the algorithm with the semi-quantitative RAMRIS scoring system [START_REF] Czaplicka | Automated assessment of synovitis in 0.2T magnetic resonance images of the wrist[END_REF][START_REF] Yang | Computer-aided and manual quantifications of MRI synovitis, bone marrow edema-like lesions, erosion and cartilage loss in rheumatoid arthritis of the wrist[END_REF]. The correlation between automated algorithms and RAMRIS was good, with r=0.70 to 0.90. These results indicate the potential of ML methods applied to MRI for clinical applications in RA.

Diagnosis based on sensors

RA symptoms may fluctuate over the day, and clinical examination may be normal if the patient comes to the clinic after the flare has resolved. Sensors are devices such as accelerometer or thermal infrared cameras, that may be wearable, and that are more and more used to gather data from RA patients [START_REF] Sharon | Development of Rheumatoid Arthritis Classification from Electronic Image Sensor Using Ensemble Method[END_REF]. Such devices may be helpful for early RA diagnosis. Thermal imaging enables the detection of inflammation in a joint, by detecting variations of temperature in specific joints, and therefore may help in diagnosing RA at an early stagein other terms, in the first weeks after symptoms onset, before the occurrence of structural damage. An Indian team proposed a ML method called modified multi-seeded region growing, to classify knees as having arthritis or not based on thermographs, with 91% accuracy, then to classify arthritis as RA or other kind of arthritis [START_REF] Bardhan | 2-Stage classification of knee joint thermograms for rheumatoid arthritis prediction in subclinical inflammation[END_REF]. This method allowed the diagnosis of RA at an early stage with 73% accuracy, and an AUC of 0.72.

Another team proposed using wearable sensor-enabled gloves, also based on thermal infrared camera technologies, to measure finger movements and then assess the presence of stiffness, which is a clinical sign of RA [START_REF] Condell | Finger movement measurements in arthritic patients using wearable sensor enabled gloves[END_REF]. However, the glove is a complex device, which is not easily implementable in patients' daily lives.

Different ML methods may be applied to analyze data from sensors, such as knearest neighbors or decision trees (50).

Usefulness for monitoring

Monitoring the disease

After RA is diagnosed, proper monitoring of the disease is key. To this end, ML methods may provide interesting tools, to assess disease activity or structural progression on imaging and/or detect flares.

Wearable activity trackers continuously register a patient's movements and may therefore capture changes reflecting the evolution of symptoms or the occurrence of a flare. From the raw accelerometer data, the use of machine learning makes it possible to deduce the types of physical activity performed [START_REF] Andreu-Perez | Developing Fine-Grained Actigraphies for Rheumatoid Arthritis Patients from a Single Accelerometer Using Machine Learning[END_REF]. Recent methodology allows to automatically apply a threshold to predictions by confidence levels, in addition to a logical filter to correct for infeasible sequences of activities. An example of the use of trackers in RA patients is to automatically correlate task performance with symptom level. In one study, patients were asked to perform a specific exercise several times a week without any supervision, such as standing up from a chair and sitting down five times. The activity tracker was used to remotely collect the time taken to perform the five repetitions. Varying the time taken to perform this exercise provided passive and automatic information about a patient's pain and stiffness [START_REF] Perraudin | Observational Study of a Wearable Sensor and Smartphone Application Supporting Unsupervised Exercises to Assess Pain and Stiffness[END_REF]. In the French Study ActConnect, activity tracker was used to detect flares in patients with RA or spondyloarthritis based on the variation in the number of steps taken during the day [START_REF] Gossec | Detection of flares by decrease in physical activity, collected using wearable activity trackers, in rheumatoid arthritis or axial spondyloarthritis: an application of Machine-Learning analyses in rheumatology[END_REF]. Overall, data from 155 patients [START_REF] Sparks | Rheumatoid Arthritis[END_REF]339 weekly flare assessments and 224,952 hours of physical activity assessments) were analyzed using multiclass Bayesian methods, which performed well when compared with patient-reported flares (mean sensitivity 96%, mean specificity 97%, mean positive predictive value 91% and negative predictive value 99%). In another study, wrist and walking movements were tracked by a smartphone sensor to detect symptoms. This study used the gyroscope and the accelerometer of a smartphone to measure movement, with pattern recognition using unsupervised machine learning algorithms including Gaussian mixture model. A link was observed between objective measurements and the participant-reported information on pain, discomfort, and mobility (55).

Wearable devices may also be used to monitor a specific joint. A study proposed a wearable device to monitor patients' hand movements during a game aiming to help the rehabilitation of the wrist [START_REF] Varga | Serious Gaming and AI Supporting Treatment in Rheumatoid Arthritis[END_REF]. Data were then computed and analyzed by an artificial neural network, which provided a score determining if the patient performed well or not. The results were also transferred to the patient's rheumatologist and physiotherapist, to guide her/him to improve rehabilitation.

Beyond the analysis of sensor data, the use of machine learning is also found with imaging. Indeed, a regular assessment of RA patients also involves repeated imaging, and particularly radiographs or ultrasonographs of the joints. However, the comparison of radiographs or MRI images may be time-consuming [START_REF] Pedoia | Segmentation of joint and musculoskeletal tissue in the study of arthritis[END_REF], and US exams may depend on the physician's experience. Thus, automatic analysis of the images may be helpful to monitor the disease in RA patients. The ML methods used to this end are mostly artificial neural networks [START_REF] Cupek | Automated assessment of joint synovitis activity from medical ultrasound and power doppler examinations using image processing and machine learning methods[END_REF][START_REF] Andersen | Neural networks for automatic scoring of arthritis disease activity on ultrasound images[END_REF], and especially deep learning [START_REF] Hirano | Development and validation of a deep-learning model for scoring of radiographic finger joint destruction in rheumatoid arthritis[END_REF][START_REF] Hemalatha | Automatic localization of anatomical regions in medical ultrasound images of rheumatoid arthritis using deep learning[END_REF].

Monitoring comorbidities

RA is associated with comorbidities, which are related to the disease itself (particularly, cardiovascular comorbidities) or may be to the consequences of RA treatments (e.g., DMARDs increase the risk of infection, and glucocorticoids the risk of osteoporosis) [START_REF] Dougados | Comorbidities in rheumatoid arthritis[END_REF]. Consequently, identifying and monitoring such complications is a cornerstone of global care in RA. ML methods may be helpful for this purpose.

Several studies used ML and especially deep learning algorithms to better characterize arterial tissue and the atherosclerotic plaque in RA patients [START_REF] Khanna | Rheumatoid Arthritis: Atherosclerosis Imaging and Cardiovascular Risk Assessment Using Machine and Deep Learning-Based Tissue Characterization[END_REF]. These methods analyze morphology and texture features extracted from US images, and can detect atherosclerotic changes in the arterial wall [START_REF] Christodoulou | A Comparative Study of Morphological and Other Texture Features for the Characterization of Atherosclerotic Carotid Plaques[END_REF][START_REF] Christodoulou | Texture-based classification of atherosclerotic carotid plaques[END_REF][START_REF] Acharya | Atherosclerotic risk stratification strategy for carotid arteries using texture-based features[END_REF]. Recently, Lekadir et al. used a deep learning model to characterize US images of the carotid into three classes: lipid, fibrous, and calcified plaques [START_REF] Lekadir | A Convolutional Neural Network for Automatic Characterization of Plaque Composition in Carotid Ultrasound[END_REF]. Thus, ML methods are relevant to assess patients' cardiovascular risk, ensure their US follow-up, monitor the effectiveness of the management of cardiovascular risk factors, and thus may help to prevent the occurrence of cardiovascular events.

Usefulness for prediction 4.1. Prediction of response to treatment

The early initiation of a DMARD is key in the management of RA, but this early initiation does not guarantee an accurate response to the treatment, and intensification of therapy may be required to achieve remission. It is therefore crucial to predict patients' response to a given treatment, to adapt the management of RA proposing the best therapeutic option. Register aimed to predict the 1-year persistence to MTX initiated as the first ever csDMARD in new-onset RA [START_REF] Westerlind | What Is the Persistence to Methotrexate in Rheumatoid Arthritis, and Does Machine Learning Outperform Hypothesis-Based Approaches to Its Prediction?[END_REF]; in this study, data on phenotype at diagnosis, demographics, medical disease history and medication use were analyzed by four different ML methods (LASSO, support vector machine, random forest and XGBoost). Among these methods, LASSO regression performed best (AUC=0.67) to predict the persistence to MTX. Finally, to predict the response to csDMARD (MTX, hydroxychloroquine, leflunomide and sulfasalazine) at 6 months, a study used random forest and support vector machine methods to identify predictors among serum biomarkers [START_REF] Gomez | Blood pro-resolving mediators are linked with synovial pathology and are predictive of DMARD responsiveness in rheumatoid arthritis[END_REF]. This work demonstrated that baseline plasma concentrations of resolvin D4, 10S, 17S-dihydroxy-docosapentaenoic acid, 15R-Lipoxin (LX)A4 and n-3 docosapentaenoic-derived Maresin 1 were predictive of csDMARD responsiveness at 6 months.

The question of response prediction is also important for biologic DMARDs (bDMARDs). Artificial neural networks were used to predict response to infliximab and identified 9 clinical predictors of good to moderate response: ESR, tender joint count, albumin level, monocyte level, red blood cell level, prednisone intakes, MTX intakes, HbA1c and previous bDMARD intakes [START_REF] Miyoshi | A novel method predicting clinical response using only background clinical data in RA patients before treatment with infliximab[END_REF]. This method displayed good performances, with 92% accuracy, 96.7% sensitivity and 75% specificity. A random forest algorithm was used to predict the response at 6 months for adalimumab and etanercept, based on gene expression and/or DNA methylation profiling on peripheral blood mononuclear cells (PBMCs), monocytes, and CD4+ T cells prior to anti-TNF treatment [START_REF] Tao | Multiomics and Machine Learning Accurately Predict Clinical Response to Adalimumab and Etanercept Therapy in Patients With Rheumatoid Arthritis[END_REF]. The models using differential genes reached an accuracy of 85.9% for adalimumab and 79.0% for etanercept, and models using differentially methylated positions reached an overall accuracy of 84.7% and 88% for adalimumab and etanercept, respectively. Thus, analyzing molecular signature in RA by the means of ML methods can predict patients' response to TNF-inhibitors, prior to treatment initiation. Another study, using a Gaussian process regression model to analyze data on patient demographics, baseline disease assessment, treatment, and single-nucleotide polymorphism array, showed this method performed well to predict response to TNF inhibitors [START_REF] Guan | Machine Learning to Predict Anti-Tumor Necrosis Factor Drug Responses of Rheumatoid Arthritis Patients by Integrating Clinical and Genetic Markers[END_REF]; baseline DAS28 score could better predict response to therapy than genetic biomarkers, but genetic biomarkers improved the predictive accuracy of the model. Genes such as EPPK1 (75), HMMR, PRPF4B, EVI2A, RAB27A, MALT1, SNX6 and IFIH1 [START_REF] Kim | Compendium of synovial signatures identifies pathologic characteristics for predicting treatment response in rheumatoid arthritis patients[END_REF] were identified thanks to ML methods as potential predictors of the response to TNF inhibitors.

Thus, it appears that both clinical and -omics data are relevant predictors of response to biologics, and ML methods are interesting tools to identify them [START_REF] Luque-Tévar | Integrative Clinical, Molecular, and Computational Analysis Identify Novel Biomarkers and Differential Profiles of Anti-TNF Response in Rheumatoid Arthritis[END_REF][START_REF] Johansson | Predicting Response to Tocilizumab Monotherapy in Rheumatoid Arthritis: A Real-world Data Analysis Using Machine Learning[END_REF].

However, these methods are not yet implemented in clinical practice.

Prediction of outcomes

Accurately predicting patients' outcomes in RA can allow to anticipate the potential complications of the disease and adapt the treatment strategy if needed. Regarding radiographic progression, a study used a support vector machine classifier to identify SNPs predicting structural damage progression on X-ray [START_REF] Joo | Biological function integrated prediction of severe radiographic progression in rheumatoid arthritis: a nested case control study[END_REF].

Overall, the ML model identified [START_REF] Lezcano-Valverde | Development and validation of a multivariate predictive model for rheumatoid arthritis mortality using a machine learning approach[END_REF] Finally, LASSO and random forests were used to explore the risk factors for osteopenia or osteoporosis in RA patients [START_REF] Hu | Prevalence and risk factors for bone loss in rheumatoid arthritis patients from South China: modeled by three methods[END_REF]. These models identified higher serum 25-hydroxyvitamin D3 level and using tumor necrosis factor inhibitor in the last year as protective factors, whereas aging, lower body mass index, and increased serum uric acid were risk factors for bone loss.

Limitations of machine learning and future directions

-Limitations of machine learning methods

Although promising, ML methods have several limitations which is slowing down their implementation in daily practice.

As ML methods used to date are mostly "supervised", large datasets are needed to train the models adequately. Additionally, the accuracy of these data must be guaranteed, as poor quality data could lead to erroneous results and therefore, to erroneous conclusions; nevertheless, implementing data quality control can be time consuming, expensive, and laborious [START_REF] Davergne | Wearable Activity Trackers and Artificial Intelligence in the Management of Rheumatic Diseases, Where are We in 2021?[END_REF]. Moreover, standardization of data (especially imaging data) acquisition is still challenging.

A model based on ML methods is only able to answer a specific question based on a given dataset, but is currently unable to solve a multitude of different problems. Human expertise and intervention are therefore still required to build, train and validate ML models. Furthermore, most models do not pass external validation when applied to other datasets. Moreover, most studies focus on the "performances" of the models, but do not consider or discuss the clinical relevance of their findings.

This explains why, even though the number of publications related to ML is increasing, only a few models are implemented in daily practice.

In this review, we presented some models which achieve a performance of 1 or 100% in terms of AUC, accuracy or precision for example. This may indicate either that the model is perfect and classifies groups without error, or that the model is overloaded and may lead to poor implementation of cross-validation strategies [START_REF] Stafford | A systematic review of the applications of artificial intelligence and machine learning in autoimmune diseases[END_REF].

ML methods are complex, and the process leading to the findings is often unclear: this "black box" phenomenon constitutes a scientific and ethical issue, given that results from medical research have consequences on patients' health and lives.

In this context, it seems crucial to be able to explain and justify the decisions taken by the machine.

This naturally leads to the question of the integration and real-world use of ML methods [START_REF] Kelly | Key challenges for delivering clinical impact with artificial intelligence[END_REF]. Indeed, as with any new technology, this requires an initial transitional period for professionals to get used to it. Conversely, the lack of understanding, coupled with a certain degree of complacency which may appear, can lead to an over-reliance on ML for decision making. These two aspects mandate to clearly define prerogatives and clinical best practices when using ML, and AI systems more generally in clinical situations. Indeed, the efficiency and accuracy of ML methods do not preclude the involvement of a human healthcare professional: this "human guarantee" is even mandatory by law in some countries (90).

Another ethical issue raised by ML is the consequence of such methods on a patient's daily life. Indeed, care should be taken to ensure that patients identified by these new technologies as being at greater risk of a poor prognosis do not suffer deleterious consequences, particularly in economic terms (for example, by paying higher insurance costs). The guarantee of data anonymity and medical confidentiality is therefore crucial.

-Future directions

The limitations mentioned above should not be seen as unsolvable problems.

On the contrary, they pave the way for directions to be taken in machine learning research. Thus, to enable the creation of large databases while ensuring quality control of these data, data collection methodology should be standardized; moreover, standardization could facilitate research results to be interoperable and reliable. A possibility would be using existing core outcome measurement sets, as proposed for example by the OMERACT (91).

To limit human intervention in the building, training and validation of ML algorithms (for time-sparing purposes) as much as possible, the development of so called "evolutionary algorithms" might help designing models, in order to find the optimum parameters for the models automatically [START_REF] Stoel | Use of artificial intelligence in imaging in rheumatologycurrent status and future perspectives[END_REF].

Furthermore, after the elaboration of a ML model, validation studies should be performed, on the one hand, to test the reproducibility of the results on other datasets, and on the other hand, to assess the clinical relevance of the findings.

Thus, collaboration between data scientists, health researchers and physicians is key to implement ML tools in rheumatology practice; this point has been raised in the recent EULAR points to consider for the use of big data and AI in rheumatic diseases [START_REF] Gossec | EULAR points to consider for the use of big data in rheumatic and musculoskeletal diseases[END_REF]. To address these different points, a research agenda was proposed by EULAR, with several working points related to data collection, data analyses, training, interpretation, and implementation of findings [START_REF] Gossec | EULAR points to consider for the use of big data in rheumatic and musculoskeletal diseases[END_REF]. The execution of this research agenda is ongoing.

Extending and standardizing the use of ML methods will lead to ever more new and exciting applications in rheumatology. For instance, voice analysis has shown its usefulness in the monitoring of patients with multiple sclerosis, since voice patterns are affected during flares (94). Similarly, changes in the larynx can occur with disease progression in RA patients. Thus, vocal biomarker identification and tracking is being developed as it may be useful for patient monitoring [START_REF] Kosztyła ; Hojna | Parameters of the assessment of voice quality and clinical manifestation of rheumatoid arthritis[END_REF]. ML applied to voice represents a cost effective and efficient way to help monitor certain symptoms of RA patients.

Another potential field is the monitoring and analysis of patient experience using the enormous amounts of data generated on social media platforms. This type of analysis has already been conducted to investigate the perception of DMARD treatments for RA [START_REF] Sharma | Mining social media data to investigate patient perceptions regarding DMARD pharmacotherapy for rheumatoid arthritis[END_REF]. The use of social media, though still in its infancy regarding its use in rheumatology, represents a challenging yet promising endeavour, which may complement traditional approaches, particularly as concerns patient safety and experience (97).

Conclusion

ML methods are numerous and diversified, and lead to applications in health in general, with promising though not yet fully implementable findings in RA management (Table 2). ML models may be used in the diagnosis of RA, based on clinical, radiological and -omics data. These methods may also be applied in the monitoring of RA and its associated comorbidities. Finally, ML algorithms may also help in the prediction of the response to treatment, and of short-and long-term outcomes.

However, the implementation of these methods in rheumatologists' daily practice is still an issue, for technical, methodological, and ethical reasons. These limitations should encourage clinical researchers in the field of RA to standardize their practices, and strengthen collaboration between data scientists, clinical researchers, and physicians to develop relevant tools for the management of RA.

Expert opinion

Artificial intelligence, and particularly ML, is a rapidly growing field in medical research [START_REF] Esteva | A guide to deep learning in healthcare[END_REF][START_REF] Pandit | Machine learning in rheumatology approaches the clinic[END_REF]. ML methods are extremely diverse, each with potentially interesting properties, such as recognition, classification, clustering, or prediction [START_REF] Stafford | A systematic review of the applications of artificial intelligence and machine learning in autoimmune diseases[END_REF]. This explains the growing interest shown by rheumatologists and researchers, as these methods have the potential to impact RA management, including shifting or extending the scope and roles of all those involved in patient carefrom nurses to the patients themselves. The use of ML could augment current practice to provide more personalized care or assist in managing situations outside of the usual context of care while awaiting physicians' decisions.

As discussed above, several models have been developed, based on diverse data sources, to enable an earlier and more accurate disease diagnosis (14-49); as it has been demonstrated that there is a window of opportunity in RA, and that the first months of the disease are crucial for disease prognosis (98), using ML methods may result in sooner treatment initiation and therefore, faster disease activity control, and better long-term outcomes for the patient [START_REF] Van Nies | Evaluating relationships between symptom duration and persistence of rheumatoid arthritis: does a window of opportunity exist? Results on the Leiden early arthritis clinic and ESPOIR cohorts[END_REF]. ML methods may also help monitoring the disease [START_REF] Sharon | Development of Rheumatoid Arthritis Classification from Electronic Image Sensor Using Ensemble Method[END_REF][START_REF] Bardhan | 2-Stage classification of knee joint thermograms for rheumatoid arthritis prediction in subclinical inflammation[END_REF][START_REF] Condell | Finger movement measurements in arthritic patients using wearable sensor enabled gloves[END_REF][START_REF] Andreu-Perez | Developing Fine-Grained Actigraphies for Rheumatoid Arthritis Patients from a Single Accelerometer Using Machine Learning[END_REF][START_REF] Gossec | Detection of flares by decrease in physical activity, collected using wearable activity trackers, in rheumatoid arthritis or axial spondyloarthritis: an application of Machine-Learning analyses in rheumatology[END_REF](55)[START_REF] Varga | Serious Gaming and AI Supporting Treatment in Rheumatoid Arthritis[END_REF][START_REF] Pedoia | Segmentation of joint and musculoskeletal tissue in the study of arthritis[END_REF][START_REF] Cupek | Automated assessment of joint synovitis activity from medical ultrasound and power doppler examinations using image processing and machine learning methods[END_REF][START_REF] Andersen | Neural networks for automatic scoring of arthritis disease activity on ultrasound images[END_REF][START_REF] Hirano | Development and validation of a deep-learning model for scoring of radiographic finger joint destruction in rheumatoid arthritis[END_REF][START_REF] Hemalatha | Automatic localization of anatomical regions in medical ultrasound images of rheumatoid arthritis using deep learning[END_REF][START_REF] Dougados | Comorbidities in rheumatoid arthritis[END_REF][START_REF] Khanna | Rheumatoid Arthritis: Atherosclerosis Imaging and Cardiovascular Risk Assessment Using Machine and Deep Learning-Based Tissue Characterization[END_REF][START_REF] Christodoulou | A Comparative Study of Morphological and Other Texture Features for the Characterization of Atherosclerotic Carotid Plaques[END_REF], and thus detect flares faster, which could also result in quicker treatment adjustment and thus, in achieving remission again. Disease activity control is indeed key in RA management, since chronic inflammation of the joints results in pain, joint destruction, and functional impairment, which impact patients' daily lives, and particularly, their ability to work (100). Achieving remission as fast as possible, with the help of ML methods, could therefore help reduce the economic burden of RA on society (101).

Furthermore, the prediction ability of ML methods could which treatment patients have the best response to, and therefore help find the best therapeutic approach for each patient [START_REF] Christodoulou | Texture-based classification of atherosclerotic carotid plaques[END_REF][START_REF] Acharya | Atherosclerotic risk stratification strategy for carotid arteries using texture-based features[END_REF][START_REF] Lekadir | A Convolutional Neural Network for Automatic Characterization of Plaque Composition in Carotid Ultrasound[END_REF][START_REF] Gosselt | Complex Machine-Learning Algorithms and Multivariable Logistic Regression on Par in the Prediction of Insufficient Clinical Response to Methotrexate in Rheumatoid Arthritis[END_REF](69)[START_REF] Westerlind | What Is the Persistence to Methotrexate in Rheumatoid Arthritis, and Does Machine Learning Outperform Hypothesis-Based Approaches to Its Prediction?[END_REF][START_REF] Gomez | Blood pro-resolving mediators are linked with synovial pathology and are predictive of DMARD responsiveness in rheumatoid arthritis[END_REF][START_REF] Miyoshi | A novel method predicting clinical response using only background clinical data in RA patients before treatment with infliximab[END_REF][START_REF] Tao | Multiomics and Machine Learning Accurately Predict Clinical Response to Adalimumab and Etanercept Therapy in Patients With Rheumatoid Arthritis[END_REF][START_REF] Guan | Machine Learning to Predict Anti-Tumor Necrosis Factor Drug Responses of Rheumatoid Arthritis Patients by Integrating Clinical and Genetic Markers[END_REF][START_REF] Yoosuf | Early Prediction of Clinical Response to Anti-TNF Treatment using Multi-omics and Machine Learning in Rheumatoid Arthritis[END_REF][START_REF] Kim | Compendium of synovial signatures identifies pathologic characteristics for predicting treatment response in rheumatoid arthritis patients[END_REF][START_REF] Luque-Tévar | Integrative Clinical, Molecular, and Computational Analysis Identify Novel Biomarkers and Differential Profiles of Anti-TNF Response in Rheumatoid Arthritis[END_REF][START_REF] Johansson | Predicting Response to Tocilizumab Monotherapy in Rheumatoid Arthritis: A Real-world Data Analysis Using Machine Learning[END_REF][START_REF] Norgeot | Assessment of a Deep Learning Model Based on Electronic Health Record Data to Forecast Clinical Outcomes in Patients With Rheumatoid Arthritis[END_REF][START_REF] Kalweit | Personalized prediction of disease activity in patients with rheumatoid arthritis using an adaptive deep neural network[END_REF][START_REF] Vodencarevic | Advanced machine learning for predicting individual risk of flares in rheumatoid arthritis patients tapering biologic drugs[END_REF][START_REF] Lin | Automatic prediction of rheumatoid arthritis disease activity from the electronic medical records[END_REF][START_REF] Koo | Machine learning model for identifying important clinical features for predicting remission in patients with rheumatoid arthritis treated with biologics[END_REF][START_REF] Joo | Biological function integrated prediction of severe radiographic progression in rheumatoid arthritis: a nested case control study[END_REF]. It has been established that some patients with more severe forms do not respond to the first lines of conventional or biological treatments recommended by the learned societies (3); it is therefore essential to identify these patients as soon as possible, in order to offer them an adapted therapeutic strategy and to improve their short and long-term prognosis. Consequently, identifying new predictive factors could impact treatment management and therefore, treatment guidelines in RA.

Although promising, implementation of ML methods in routine practice is not feasible presently, for technical, methodological, and ethical reasons.

Technical issues are related to the fact that huge amounts of validated data are required to properly train "supervised" ML modelswhich represent most ML methods used nowadays [START_REF] Davergne | Wearable Activity Trackers and Artificial Intelligence in the Management of Rheumatic Diseases, Where are We in 2021?[END_REF]. Indeed, depending on the physician or research team, disease parameters are not assessed in the same way (e.g., disease activity can be assessed in 28 or 44 joints, or using erythrocyte sedimentation rate or C reactive protein), which results in heterogeneous data. A crucial and time consuming data management process is therefore required to homogenize the data, and check if the data are adequately computed in the database. A potential solution would be to standardize the way data are computed by the means of recommendations for good research practice [START_REF] Boers | Developing core outcome measurement sets for clinical trials: OMERACT filter 2.0[END_REF][START_REF] Gossec | EULAR points to consider for the use of big data in rheumatic and musculoskeletal diseases[END_REF], or to develop validated "equivalence" scales to homogenize data collected in different ways for a same disease parameter.

Methodological issues are mostly related to the fact that, although providing interesting results on specific datasets, only a few ML models are applicable to other datasets [START_REF] Davergne | Wearable Activity Trackers and Artificial Intelligence in the Management of Rheumatic Diseases, Where are We in 2021?[END_REF]. As a matter of fact, most ML models presented previously have good predictive performances, but this could reflect "overfitting" of the models to the dataset they were trained on. Additional validation studies, not focusing on "technical" performances of the models but rather on their clinical relevance, are therefore required. Consequently, to move this field forward, a strong collaboration between ML experts and RA experts is needed [START_REF] Gossec | EULAR points to consider for the use of big data in rheumatic and musculoskeletal diseases[END_REF].

The ethical issues raised by ML in RA research are linked to the so-called "black box" phenomenon: in other terms, the mechanisms leading from an input to an output are unclear for most ML algorithms (102). Not being able to explain results that will have consequences on the management and therefore the health of patients is a major concern. A better understanding of the theoretical aspects of machine learning algorithms is therefore fundamental in order to have full confidence in these methods.

Another ethical question that arises is the consequences of advances in ML on patients' everyday lives (103). Indeed, patients could suffer deleterious consequences if their health information were to be communicated to their insurance companies or their employers. The guarantee of data anonymity and medical confidentiality is therefore more important than ever. In this perspective, the General Data Protection Regulation, which is in place in Europe (104), should not be perceived as an obstacle to research, but as a way to ensure the confidentiality of patients' data to avoid deleterious consequences on their daily lives.

Future research in the field of machine learning should therefore address all these issues, with a view to implementing these methods in current practice. A research agenda was elaborated by the EULAR task force on Big Data and Artificial

Intelligence use in RMDs, with several working points related to data collection, data analyses, training, interpretation, and implementation of findings [START_REF] Gossec | EULAR points to consider for the use of big data in rheumatic and musculoskeletal diseases[END_REF]. The execution of this research agenda is ongoing.

Future efforts should be inspired by the evolutions of ML in other fields, especially other medical areas. Fields dealing with easily digitizable data or at the very least data which is easily handled by computers (in terms of processing) are of particular interest in this regard. In cardiology and radiology for instance, ML projects are numerous (105,106). Such projects could provide interesting starting points to address some of the concerns that have been raised.

Given its potential, ML is part of the future of medical research, and particularly in RA-related research. Nevertheless, given the current limitations, it is clearly not the only way, and more classical basic and clinical approaches are still relevant to improve the management of the disease. In the years to come, we believe that progress will be made at least regarding the technical and methodological limitations of ML, which will certainly help to implement these methods, and ultimately improve the management of RA patients.

Declaration of interests:

There was no funding source for the present work.

The authors have no disclosure of interest to declare in relationship with the present work.

  Methotrexate (MTX) is the first line DMARD for most RA patients[START_REF] Smolen | EULAR recommendations for the management of rheumatoid arthritis with synthetic and biological disease-modifying antirheumatic drugs: 2019 update[END_REF]. Thus, several studies aimed to predict insufficient clinical response to this conventional synthetic DMARD (csDMARD). A study based on the Dutch REACH cohort aimed to assess the performance of multiple regression and 3 ML methods (LASSO, random forest and XGBoost) to predict insufficient response to MTX at 3 months,[START_REF] Gosselt | Complex Machine-Learning Algorithms and Multivariable Logistic Regression on Par in the Prediction of Insufficient Clinical Response to Methotrexate in Rheumatoid Arthritis[END_REF]. To this end, features related to RA pathogenesis (RF status, ACPA status, and Disease Activity Score 28 [DAS28] components) or to MTX metabolism (e.g., single nucleotide polymorphisms (SNPs) in ATP-binding cassette (ABC) transporter genes and erythrocyte folate) from 355 RA patients were computed to build the models. The 4 models performed well to predict insufficient response to MTX, with AUC=0.77 for multiple logistic regression, AUC=0.76 for LASSO, AUC=0.71 for random forest, and AUC=0.70 for XGBoost. Furthermore, the most important features were baseline DAS28 components. Another study aimed to analyze whole blood samples from RA patients at 2 time points (pretreatment and 4 weeks following initiation of MTX), to identify gene expression biomarkers of the MTX response (69). Data were analyzed by the means of a random forest model. Based on this method, a significant overrepresentation of type I interferon signaling pathway genes in non-responders at pretreatment (p-value < 0.0001) and at 4 weeks after treatment initiation (p-value < 0.0001) was identified. Finally, a study of the Swedish Rheumatology Quality

ML methods may be

  useful to predict outcomes related to RA itself, such as flares or radiographic progression. Deep learning[START_REF] Norgeot | Assessment of a Deep Learning Model Based on Electronic Health Record Data to Forecast Clinical Outcomes in Patients With Rheumatoid Arthritis[END_REF][START_REF] Kalweit | Personalized prediction of disease activity in patients with rheumatoid arthritis using an adaptive deep neural network[END_REF], k-nearest neighbors, naïve Bayes classifier, random forest (81) and support vector machine (82) methods were proposed to predict the evolution of disease activity and the occurrence of flares, based on patients' clinical and biological features. These methods all had good predictive performances, with AUC between 0.75 and 0.91, and identified predictors of flare such as change of bDMARDs, clinical disease activity (DAS28 ESR), disease duration, joint pain, inflammatory markers, age and duration of treatment[START_REF] Norgeot | Assessment of a Deep Learning Model Based on Electronic Health Record Data to Forecast Clinical Outcomes in Patients With Rheumatoid Arthritis[END_REF][START_REF] Kalweit | Personalized prediction of disease activity in patients with rheumatoid arthritis using an adaptive deep neural network[END_REF][START_REF] Vodencarevic | Advanced machine learning for predicting individual risk of flares in rheumatoid arthritis patients tapering biologic drugs[END_REF][START_REF] Lin | Automatic prediction of rheumatoid arthritis disease activity from the electronic medical records[END_REF][START_REF] Koo | Machine learning model for identifying important clinical features for predicting remission in patients with rheumatoid arthritis treated with biologics[END_REF].

  SNPs combined with patients' clinical information as predictors of radiographic progression, with an AUC of 0.79; this model performed

	better than classical approaches such as GWAS (AUC=0.65) and SPOT (AUC=0.74).
	ML methods may also help in predicting morbimortality related to RA. Random
	survival forests were used to identify predictors of mortality in two Spanish cohorts:
	age at diagnosis, median ESR, and number of hospital admissions were shown to
	display the best predictive capacity for this outcome, and the elaborated model had
	specificity and sensitivity of 0.79-0.80 and 0.43-0.48 after 1 year and 7 years of
	follow-up, respectively (85). An American cohort study aimed to identify predictors of
	serious infection risk in RA compared with non-inflammatory rheumatic diseases: the
	LASSO model revealed a major role of moderate and high disease activity (86).

Table 1 : types of machine learning algorithms

 1

	Type of learning	Definition			Examples	of	Examples	of
							algorithms	application
	Supervised learning	The algorithm maps an	Logistic	regression,	Object recognition in
			input to an output,	Bayesian	networks,	computer vision (108),
			based on example	random	forests,	vocal	recognition
			input-output	pairs	support	vector	(Siri…)
			(107).				machine,	artificial
							neural networks, deep
							learning, LASSO, k-
							nearest	neighbors,
							XGBoost
	Unsupervised learning	The algorithm is not	Hierarchical clustering,	Phenotypic
			provided with any pre-	k-means	clustering,	stratification of cardiac
			assigned	labels	or	principal	component	risk (110), personalized
			scores for the training	analysis, deep learning	movie propositions on
			data	and	must		Netflix
			therefore first self-
			discover any naturally
			occurring patterns in
			that	training	data
			set.(109)
	Weak	supervision	This technique uses	Transductive support	Snorkel	(112),	the
	learning		models based on new	vector	machines,	BREXIT tweet classifier,
			generated data which	convolutional	neural	Image recognition
			can be incomplete,	networks,
			inexact, or inaccurate.
			They	typically	use
			programs to de-noise
			or predictively label
			data (111).
	Transfer learning	This focuses on storing	Markov logic networks,	Cancer	subtype
			the knowledge gained	Bayesian networks	discovery	(114),
			while	solving	one		medical imaging, spam
			problem and applying		filtering
			it to a different but
			related problem (113).
	Semi-supervised	This type of learning	Semi-supervised	Analysis of urban flow
	learning		combines	a	small	clustering,	semi-	(116)
			amount of labeled data	supervised	support
			with a large amount of	vector machine
			unlabeled data during
			training (115)
	Reinforcement learning It consists, for the	Monte	Carlo,	Q-	Gaming	(AlphaGo
			machine, in learning	learning, State-action-	Zero) (118)
			the actions to take,	reward-state-action
			from experiments, in	(SARSA)
			order to optimize a
			quantitative	reward
			over time (117).

Table 2 : summary of data sources and machine learning methods used in rheumatoid arthritis for diagnosis, monitoring and prediction

 2

	Application	Data source	Machine learning methods
			used
	Diagnosis	Electronic Health Records	SVM
		Omics	ANN, RF, k-NN, SVN, naive
			Bayes, consensus clustering
		Imaging	CNN, SVM
		Sensors	Modified	multi-seeded
			region	growing,	k-NN,
			decision trees
	Monitoring	Sensors	Bayesian methods, ANN
		Imaging	ANN, deep learning
	Prediction	Clinical data (cohort or	LASSO, RF, ANN, SVM,
		register)	XGBoost
		Omics	RF
		Clinical and omics data	Deep learning, k-NN, naïve
		combined	Bayes, RF, SVM

Footnote: ANN: artificial neural network; CNN: convolutional neural network; n-NN: knearest neighbors; LASSO: Least Absolute Shrinkage and Selection Operator; RF: random forests; SVM: support vector machine