# Modelling Business Agreements in the Multimodal Transportation Domain
through Ontological Smart Contracts

Mario Scrocca Corresponding Author. E-mail<EMAIL_ADDRESS>Marco
Comerio  Alessio Carenini  Irene Celino<EMAIL_ADDRESS>Cefriel –
Politecnico di Milano
Viale Sarca 226, 20126 Milano, Italy

###### Abstract

The blockchain technology provides integrity and reliability of the
information, thus offering a suitable solution to guarantee trustability in a
multi-stakeholder scenario that involves actors defining business agreements.
The Ride2Rail project investigated the use of the blockchain to record as
smart contracts the agreements between different stakeholders defined in a
multimodal transportation domain. Modelling an ontology to represent the smart
contracts enables the possibility of having a machine-readable and
interoperable representation of the agreements. On one hand, the underlying
blockchain ensures trust in the execution of the contracts, on the other hand,
their ontological representation facilitates the retrieval of information
within the ecosystem. The paper describes the development of the Ride2Rail
Ontology for Agreements to showcase how the concept of an ontological smart
contract, defined in the OASIS ontology, can be applied to a specific domain.
The usage of the designed ontology is discussed by describing the modelling as
ontological smart contracts of business agreements defined in a ride-sharing
scenario.

###### keywords:

business agreement ontological smart contracts multimodal transportation

, , , and

##  1 Introduction

In the context of multimodal transportation, a wide set of stakeholders should
cooperate to provide passengers with a seamless travel experience. The
Shift2Rail Innovation Programme 4111Shift2Rail IP4, https://rail-
research.europa.eu/research-development/ip4/ (IP4) investigated the design and
implementation of an ecosystem of transportation stakeholders relying on an
_Interoperability Framework_ to support the communication among them and the
definition of new services for the users. In this context, the Ride2Rail
project222Ride2Rail, https://ride2rail.eu/, focused its attention on the
integration of ride-sharing alternatives.

The introduction of new transportation modes, such as ride-sharing, poses
additional challenges related to a business environment blending companies and
private actors. For this reason, Ride2Rail investigated the usage of
blockchain technology to offer suitable guarantees for trust in a multi-
stakeholder scenario involving the definition of business agreements.
Ride2Rail developed a specific software module for the definition of business
agreements as smart contracts, i.e, executable software applications that
implement self-executing logic in a blockchain. A smart contract could be
implemented as a tool to automate the execution of an agreement that will run
when certain conditions are met.

To foster the semantic interoperability of the developed module within the IP4
ecosystem, we designed and adopted an ontology to model the defined agreements
through a shared semantic and decoupling the specification of the agreements
from its technological implementation. This paper describes the development of
such ontology and its application within the Ride2Rail project to describe
business agreements in the considered ride-sharing scenario. The main
contributions of the paper are: (i) analysis of the literature surveying
approaches for an ontological representation of smart contracts, (ii) design
and development of an ontology for the definition of business agreements in a
multimodal transportation scenario, and (iii) validation of the ontology and
exemplification of its usage.

The developed _Ride2Rail Ontology for Agreements_ leverages the concept of
_Ontological Smart Contract_ defined in the OASIS ontology [1] and
investigates how it can be extended to model the semantic of business
agreements. Although we focused our work on the transportation domain, the
proposed approach can be generalised to model ontological smart contracts in
different domains.

The remainder of the paper is structured as follows: Section 2 discusses
preliminaries regarding the context, terminology and methodology followed;
Section 3 frames the work considering the state-of-the-art; Section 4
describes the ontology engineering process and the implemented ontology;
Section 5 exemplifies the usage of the ontology reporting how it is used to
describe the agreements defined within the Ride2Rail project; Section 6 draws
the conclusions, discusses how the proposed approach can be generalised and
future work.

##  2 Preliminaries

This section presents a preliminary introduction to the context and
terminology analysed in the paper and the methodology adopted.

###  2.1 Context

The Ride2Rail project investigated the specific requirements of ride-sharing
for its integration in the multimodal transport ecosystem defined in IP4. The
idea behind Ride2Rail is to consider each driver (i.e., a user offering a
shared ride with her/his car) as a private transport service provider (TSP)
offering transportation services on a specific route. The challenges of such
an integration are multiple, for example, the need for a user application that
could allow passengers to become a driver offering a ride with their own
vehicle, or the need for a dynamic update of shared rides published by drivers
for the multimodal journey planning. Moreover, a major challenge is related to
how to guarantee trust in an environment where private actors can offer, along
with companies, a paid transportation service to passengers. For this reason,
the _Agreement Ledger Module_ was designed and developed in Ride2Rail
exploiting the blockchain technology to guarantee trust in the definition of
agreements between parties (TSPs, drivers and passengers). The _Agreement
Ledger Module_ is a software module exposing through an API a set of
functionalities relying on smart contracts deployed on a distributed ledger
for the digital representation and execution of business agreements. The
overall design and implementation of the _Agreement Ledger Module_ is
documented in the project deliverable [2].

The objective of the ontology engineering activity described in this paper is
not to transpose ontologically the content of the ledger, but to identify and
provide a _semantic description_ of the contracts implemented so that they can
facilitate interoperability within IP4 and their comprehension from IP4
stakeholders.

For this purpose, the _Ride2Rail Ontology for Agreements_ aims at identifying
a set of classes and properties to represent the agreements between parties
that could be implemented through the _Agreement Ledger Module_. In this
paper, we demonstrate how the following agreements could be described using
the ontology:

  * •

The _Ridesharing Booking_ , as an agreement between a driver and a passenger.

  * •

The _Incentive_ , as an agreement between different parties to grant,
according to a set of conditions, a reward that could promote more sustainable
transportation alternatives.

###  2.2 Terminology

In the IP4 scenario, a user with a mobility need can interrogate an
application for passengers that is able to process a mobility request and
return a set of multimodal offers to cover the itinerary between the required
origin and destination. Each _offer_ is associated with a _trip_ and a set of
_offer items_ that the passenger can book to be entitled to travel according
to the proposed trip. In the general case, a trip is composed of multiple
_travel episode_ s, i.e., multimodal trip legs, offered by different _travel
expert_ systems, provided by different operators and combined to generate a
trip.

In this context, the following terminology is introduced for the considered
scenario:

  * •

a _lyft_ is defined as a ride-sharing leg in the (multi-modal) trip of a
passenger, therefore, it is a travel episode for ridesharing;

  * •

a _ride_ is the transportation service offered by a _driver_ that enables a
travel episode for one or more passengers;

  * •

a _ridesharing booking_ represents the booking made by a passenger of an offer
item associated with a ride offered by a driver;

  * •

a _Crowd-based Travel Service Provider_ is a travel expert system handling
offer items for the rides offered by a set of drivers;

  * •

an _incentive_ is an agreement between parties that is offered by an
_incentive provider_ defining the _incentive mechanism_ and _incentive
conditions_ for granting it.

A more detailed discussion of the presented terminology can be found in the
Ride2Rail deliverables [3, 4, 5].

###  2.3 Methodology

The methodology adopted for the definition of the ontology is based on _Linked
Open Terms_ (LOT) [6], a consolidated industrial method to develop ontologies
and glossaries. The LOT methodology is divided into four steps: ontology
requirements specification, ontology implementation, ontology publication and
ontology maintenance. In the following paragraphs, we briefly discuss the
first three steps of the methodology performed to design and implement the
_Ride2Rail Ontology for Agreements_.

The ontology requirements specification consists of the definition of the
ontology requirements considering the purpose and scope of the ontology,
domain analysis and an investigation of the existing data flows. The activity
starts with the identification of a set of _use cases_ and _user stories_ for
the ontology. A _use case_ should answer the following questions: _Who will be
the actors interested in querying the ontological data? What are the expected
usages of data modelled through the ontology?_

Considering the _use cases_ and _user stories_ defined and the domain analysis
performed, then the ontological requirements are specified in the form of
_competency questions_ and _facts_. The set of _competency questions_ defines,
in the form of hypothetical questions associated with a _user story_ , the
information that should be possible to retrieve from data modelled using the
ontology. The set of _facts_ describes the semantics and the requirements
associated with the domain-specific terminology (e.g., attributes describing a
specific term, etc.). In this phase, domain experts and stakeholders, are
involved to ensure a comprehensive set of ontological requirements is
specified.

The second step is the implementation of the ontology. Considering the
requirements, a first conceptual model is produced with the required set of
classes and properties. Then, in line with the best practices of ontology
engineering, the relevant and already existing vocabularies are analysed to
assess the possibility of reusing them.

Finally, the actual ontology is coded in the OWL language and it is validated
with the support of automatic diagnosis tools and by manually assessing it
with respect to the ontological requirements specified.

The third step is the documentation and publication of the ontological model.

##  3 Related work

Blockchain-based solutions and Semantic Web technologies are complementary and
may benefit each other. Many researchers are investigating how to combine
these technologies and also the European Commission is supporting this
research area. As an example, we cite the H2020
ONTOCHAIN333https://ontochain.ngi.eu/ project financed under the Next
Generation Internet initiative.

Different approaches combining these two areas are reported in the literature.
J. Cano-Benito et al. discuss in [7] six different scenarios: (a) blockchain
with semantic meta-data, (b) blockchain with RDF content, (c) blockchain and
virtual RDF service to publish its content, (d) blockchain with external
pointers to RDF data, (e) blockchain referencing another blockchain through
RDF, (f) semantic blockchain implemented relying on Semantic Web.

The implementation of the mentioned scenarios relies on the definition of
ontologies to model the content of the blockchain. In Ride2Rail, we were
interested in investigating how smart contracts implemented on the blockchain
could be described using an ontology. This approach addresses two
interoperability needs: (i) the description in an implementation-independent
way of the smart contracts defined according to a specific blockchain-based
solution, and (ii) the adoption of proper and shared terminology to describe
domain entities and their relationships. Moreover, even if out of scope for
the Ride2Rail project, it can foster the implementation of virtual RDF
services to query the content of the blockchain using the ontology (scenario
_c._).

In the following paragraphs, we analyse existing vocabularies that were
considered to evaluate their re-use in the implementation of the ontology.

###  3.1 Smart Contracts and Ontologies

In the analysis of the literature, we found relevant related work regarding
the definition of ontologies for smart contracts.

The paper _Ontologies for Commitment-Based Smart Contracts_ [8] defines a
platform-independent conceptualization of smart contracts, however, as
mentioned also by the authors in their conclusions, it represents an initial
model that should be refined and evaluated before being finally implemented
and published as an ontology.

Kruijff and Weigand in _Understanding the Blockchain Using Enterprise
Ontology_ [9] adopt an ontology-based approach to formalise the terminology
related to the blockchain, including smart contracts, but the proposed
modelling considers a higher level of abstraction and doesn’t allow for the
detailed description of a specific smart contract. Moreover, the authors
mention that the presented ontology is still an initial model to be validated
and finalised.

Similarly, the _Ontology for Smart Contracts_ proposed by McAdams [10]
identifies the basic terminology for a conceptualisation of smart contracts
that could aid in implementing formal reasoning over their behaviour. The
proposed contribution is, however, not implemented as an ontology yet.

Finally, the paper _Ontological Smart Contracts in OASIS_ [1] defines the
concept of Ontological Smart Contract extending the OASIS ontology for agents,
systems, and integration of services [11]. The proposed ontology defines the
concept of a smart contract as an entity to define agreements between agents
and specify their terms, independently from the specific blockchain
implementation. Differently from the other work in the literature, the OASIS
ontology is fully implemented in OWL, published online and its usage is
documented and exemplified by the authors. Moreover, we contacted the authors
that provided us with additional documentation to re-use the vocabulary and
confirmed that a plan for the maintenance of the ontology is in place. For
these reasons, we decided to adopt this vocabulary as a basis for our work.

In this paper, we discuss how the OASIS ontology can support the modelling of
ontological smart contracts considering different blockchain technologies, and
how it can be extended and leveraged to model business agreements in different
domains. Indeed, the usage of the OASIS ontology is exemplified in [1]
considering a trading agent selling stocks and the Ethereum platform, while,
in Section 5, we consider agreements in the transportation domain implemented
through the Hyperledger Fabric API444https://github.com/hyperledger/fabric-
contract-api-go.

###  3.2 IP4 Ontologies

To support the definition of domain-specific classes and properties, and to
support interoperability within IP4, we analysed the current status of the
ontologies for the multimodal transportation domain defined in the context of
IP4.

The IP4 ontology is currently undergoing an in-depth process of modularization
and extension [12] considering already standardized formats (e.g.,
Transmodel555https://www.transmodel-cen.eu/,
OSDM666https://unioninternationalcheminsdefer.github.io/OSDM/,
TRIAS777https://github.com/VDVde/TRIAS, GTFS-
RT888https://developers.google.com/transit/gtfs-realtime etc.). A preliminary
release of the new modules of the IP4 ontology, currently under finalisation
is available on Github999Working repository https://github.com/oeg-
upm/mobility. The two already available modules of the IP4 ontologies address
the _Transmodel_ concepts (Core, Commons, Fares, Facilities and Journeys
submodules) [13] and the _Open Sales and Distribution Model_ (OSDM)
specification to model the booking process.

##  4 Ontology for Agreements

The objective of the _Ride2Rail Ontology for Agreements_ is to provide a
conceptualization of the basic terms for the description of the business
agreements defined in the multimodal transportation context discussed in
Section 2.1. The ontology takes into account the terminology (Section 2.2) and
the ontologies already defined within IP4 (Section 3.2) to support
interoperability through shared semantics.

The following sections describe the application of the presented methodology
(Section 2.3) for the design, implementation and publication of the _Ride2Rail
Ontology for Agreements_.

###  4.1 Ontological Requirements Specification

This section describes the ontological requirements identified for the
_Ride2Rail Ontology for Agreements_. The collection of requirements leveraged
the analysis of the overall requirements defined for the Ride2Rail project and
the specific ones identified for the implementation of the Agreement Ledger
Module. Furthermore, additional stakeholders from the transportation domain
were involved to take into account additional considerations from the project
consortium and other IP4 actors.

Two use cases were identified to support the definition of the ontology.

UC1 – Dispute Resolution about Ridesharing
_Description_ : in case of a dispute between a driver and a passenger
regarding a booked ride, the responsible authority wants to access trusted
data to resolve it.
_Stakeholders_ : Driver, Passenger, Authority
_Workflow_ : The responsible authority analyses the details of the booking
agreement between the driver and the passenger obtaining trusted information
that can help in solving the dispute.

UC2 – Incentives to promote Ridesharing
_Description_ : travellers (both drivers and passengers) are given incentives
to involve ride-sharing in their multimodal rides.
_Stakeholders_ : Passenger, Driver, Travel Service Provider
_Workflow_ : Incentives are represented as ontological smart contracts and can
be queried to get information about the conditions and mechanisms of available
incentives within IP4.

For each use case, different user stories considering the stakeholders
involved were identified. Finally, a set of facts and competency questions was
defined considering: (i) the use cases and user stories defined, (ii) the
analysis of the business agreements modelled on the blockchain, and (iii) the
relevant terminology in the considered domain.

Table LABEL:tab:cqs contains the competency questions identified for the two
use cases, terms starting with a capital letter are concepts described in
facts. The complete list of user stories, facts and competency questions is
reported in the ontology
repository101010https://github.com/Ride2Rail/agreement-ledger-
ontology/tree/main/requirements.

Table 1: Competency Questions identified for the Ontological Requirements Specification Competency Question |  Expected Result | Use case
---|---|---
What is the origin/destination of the Ridesharing Leg offered by the Driver and booked by the Passenger? |  Origin/Destination of the Ridesharing Leg involved in the Ridesharing Booking | UC1
What is the price agreed upon between the Driver and the Passenger? |  Price agreed for the Ridesharing Leg involved in the Ridesharing Booking | UC1
What is the number of seats declared by a Driver offering a Ride? |  Number of seats associated with a Ride | UC1
What are the incentive agreements involving a TSP as an incentive provider? |  Incentives involving a TSP in the agreement | UC2
What are the conditions defined for a given Incentive? |  Conditions defined for the applicability of the Incentive | UC2
Is there a tangible good or benefit associated with a given Incentive? |  Benefit associated with the Incentive | UC2

###  4.2 Ontology Implementation

To support the ontology implementation phase, we adopted the _Chowlk_
111111https://chowlk.linkeddata.es/ notation and converter [14] that allows
building the conceptual model graphically and then to directly obtain a first
serialization of the ontology in OWL.

The design of the conceptual model, starting from a glossary of terms
extracted from the ontological requirements, went through several iterations
considering also the outcomes of the review of already available ontological
and non-ontological data formats.

To facilitate the description of the final conceptual model, we first discuss
the reused vocabularies to model the ontological smart contracts and the
domain terminology. Then, we present the final version of the ontology through
the _Chowlk_ notation. Using the diagram, we motivate our design decisions by
describing the introduced classes and properties and the alignment with the
re-used vocabularies.

####  4.2.1 Ontological Smart Contracts

The Ontology for Agents, Systems, and Integration of Services (OASIS) is
published online121212OASIS ontology
https://www.dmi.unict.it/santamaria/projects/oasis/oasis.php with the
namespace http://www.dmi.unict.it/oasis.owl# (oasis: prefix).

An ontological smart contract in OASIS (_oasis:SmartContract_) is modelled
defining the set of entries involved in the agreement
(_oasis:SmartContractEntry_) and the set of conditionals
(_oasis:ConditionalSet_) specifying the terms of the agreement. Agreement
instances are modelled through the class _oasis:SmartContractInstance_ and
they are associated with a specific _oasis:SmartContract_.

A _oasis:SmartContractEntry_ can be of class
_oasis:SmartContractEntryParticipant_ , describing a participant involved in
the agreement, or class _oasis:SmartContractEntry
Value_, describing values involved. Each _oasis:SmartContractEntry_ can be
described using the property _oasis:refersExactlyTo_ , if it refers to a
specific individual for each instance of the described agreement, or using the
property _oasis:refersAsNewTo_ , if it describes an individual through an
_oasis:EntryTemplate_. An _oasis:EntryTemplate_ allows to specify the features
that an _oasis:SmartContractEntry_ should have in an
_oasis:SmartContractInstance_ of the modelled _oasis:SmartContract_.

The terms of the agreements are modelled using _oasis:Conditional_ , which
represent an implication between an antecedent (_oasis:ConditionalBody_) and
consequent (_oasis:ConditionalHead_). Whenever the conditions specified in the
antecedent hold, then the conditions specified in the consequent must also
hold. Both an _oasis:ConditionalBody_ and an _oasis:ConditionalHead_ can
specify multiple conditions modelling different _oasis:ConditionalAtom._ All
the _oasis:ConditionalAtom_ should be satisfied to satisfy the
antecedent/consequent. A _oasis:ConditionalAtom_ can be described through:

  * •

_oasis:ConditionalSubject_ : representing the subject;

  * •

_oasis:ConditionalObject_ : representing the object;

  * •

_oasis:ConditionalOperator:_ representing actions (_oasis:Action_) from
subject(s) to object(s);

  * •

_oasis:ConditionalParameter_ : representing a parameter of the action
described by the operator (the two subclasses
_oasis:ConditionalInputParameter_ and _oasis:ConditionalOutputParameter_
representing an input and an output parameter, respectively);

  * •

_oasis:ConditionalOperatorArgument_ : representing operator arguments for a
subordinate characteristic of the operator

Also in the modelling of conditionals, an _oasis:EntryTemplate_ can be
leveraged to specify the features that the entities involved in the
conditional.

####  4.2.2 Domain Terminology

For the definition ontology, considering the elicited requirements, we focused
mainly on the _OSDM_ module of the IP4 ontologies. The namespace for the
considered ontology is https://w3id.org/mobility/
osdm/core# (osdm: module), but the publication process is not finalised yet.
In particular, we reused classes and properties related to the concepts of:

  * •

_osdm:Offer_ : defined as “a response to a customer mobility request as a
result of the travel shopping process, it is composed of offer item(s) for
service(s) designed to cover each proposed journey, and, optionally, ancillary
services”.

  * •

_osdm:Booking:_ defined as “an operational process as part of the sales
process to commit to a sales transaction binding the customer and supplier to
the offer”.

To complement the set of classes and properties already available in the IP4
ontologies, the MaaSive Glossary and the conceptualisation effort made in
Ride2Rail WP2.1 (Deliverable D2.1 [3] and D2.4 [4]) and WP3.1 (Deliverable 3.1
[5]) were taken into account as non-ontological resources to improve the
semantic interoperability of entities modelled in our ontology.

####  4.2.3 Ride2Rail Ontology for Agreements

The implementation of the _Ride2Rail Ontology for Agreements_ is based on the
decision to reuse the _oasis:SmartContract_ as the class to model a business
agreement. Our claim is that concept of _oasis:SmarContract_ is modelled in
the OASIS ontology using a generic approach that can be extended and applied
to different domains once identified a suitable vocabulary for the
representation of the domain terminology. An _oasis:SmarContract_ not only
enables the representation of the agreement and the entities involved a
_oasis:SmartContractEntry_ , but also a detailed model of the terms of the
agreements as _oasis:Conditionals_. The main objective of the ontology is to
complement the current IP4 ontologies and extend the OASIS ontology providing
the needed terminology to model ontological smart contracts in the multimodal
transportation domain.

Figure 1 adopts the Chowlk notation to describe the classes and properties
modelled and their relations with reused vocabularies. The namespace selected
for publication is https://w3id.org/ride2rail/terms# (r2r: prefix).

Figure 1: Chowlk diagram for the Ride2Rail Ontology for Agreements

To support the modelling of the _oasis:SmartContract_ for a ridesharing
booking, the class _r2r:RidesharingBooking_ is defined as a subclass of
_osdm:Booking._ An _osdm:Booking_ is associated with the booked _osdm:Offer_
and the _osdm:Price_ paid for the offer. _An osdm:Offer_ represents the pair
between a computed _osdm:Trip_ and the set of products (_osdm:OfferPart_)
offered to an _osdm:Passenger_ and required to perform the trip.

The ontology extends the concept of _osdm:Offer_ defining an _r2r:OfferItem_
to model the corresponding term in the IP4 glossary (an offer item is part of
an offer, which is provided by a single TSP). As a result,
_r2r:RidesharingBooking_ is associated with an _r2r:OfferItem_ provided by a
ridesharing TSP, i.e. the Crowd-based TSP in the ride-sharing scenario.
The ontology also defines two classes, _r2r:TravelEpisode_ and
_r2r:TransportationService_ to model, respectively, the IP4 concepts of
_travel episode_ (”part of a trip operated with the same vehicle”) and
_transportation service_ (”service that provides transportation on a travel
episode”). An _osdm:Trip_ may include multiple _r2r:TravelEpisode_ (possibly
aligned with the concept of _osdm:Segment_), an _r2r:TravelEpisode_ may be
operated by an _r2r:TransportationService_.
An _r2r:OfferItem_ for an _r2r:RidesharingBooking_ , is associated with an
_r2r:RidesharingLeg_ (subclass of _r2r:TravelEpisode_) that is made possible
through an _r2r:Ride_ (subclass of _r2r:TransportationService_) operated by an
r2r:Driver. In this sense, _r2r:Driver_ extends the concept of
_tmorg:Operator_.

As specified in the requirements, an _r2r:Ride_ may specify an
_r2r:InventoryAllocation_ that indicates a given quantity of available
consumables (_r2r:Consumable_). The ontology defines _r2r:Seat_ as an
individual of the class _r2r:Consumable_. An _r2r:InventoryReservation_
(subclass of _osdm:Reservation_) can be associated with an _r2r:OfferItem_
defining the number of consumables reserved by the corresponding booking.

To support the modelling of incentives, the class _r2r:IncentiveSmartContract_
is defined as subclass of _oasis:SmarContract_. The ontology also models the
concept of _r2r:Voucher_ to define a redeemable good issued by a
_tmorg:Organisation_. Two subclasses are defined for _r2r:Voucher_ to model
the mechanisms of the incentives implemented in Ride2Rail: a
_r2r:DiscountVoucher_ allowing to model a certain percentage of discount
granted to the beneficiary of the voucher, and a _r2r:SeatUpgradeVoucher_
granting an upgrade of seat class for the beneficiary.
To express the incentive conditions defined in the requirements, the ontology
also defines two _oasis:Action_ individuals, _r2r:issue_ and _r2r:book_ , that
can be used as _oasis:ConditionalOperator_ in the modelling of conditionals
for an _oasis:SmartContract_.

Finally, to model the events that can be associated with a ridesharing booking
we decided to implement a SKOS131313https://www.w3.org/2004/02/skos/ Concept
Scheme.

As defined in the requirements, five events are identified in the first level
of the taxonomy: _RidesharingStarted_ for the start of the ride associated
with the ridesharing booking, _RidesharingCompleted_ for the completion of the
ride associated with the ridesharing booking, _RidesharingCancelled_ for the
cancellation of the ridesharing booking by the passenger or by the driver,
_RidesharingDelayed_ for a delay in the ride due to the passenger or to the
driver, _RidesharingNoShow_ for a passenger or a driver not showing as
expected for the booked ridesharing.

The modelled ontology was validated against the ontological requirements and
using OOPS! [15] as the state-of-the-art tool for automatic diagnosis of
anomalies in the ontology141414A report of the validation is available in the
ontology repository https://github.com/Ride2Rail/agreement-ledger-ontology.

###  4.3 Ontology Publication

The _Ride2Rail Ontology for Agreements_ is published online following the best
practices for ontology publication at https://w3id.org/ride2rail/terms# (r2r:
prefix). We adopted the _w3id_ service for permanent
identifiers151515https://w3id.org/, and we implemented content negotiation to
serve the ontology in different human-readable and machine-readable
formats161616Recipe 3 from https://www.w3.org/TR/swbp-vocab-pub. The Widoco
[16] tool was used to generate the ontology documentation, then complemented
through diagrams and the description of the main design decisions. The SKOS
taxonomy for ridesharing booking events is published at
https://w3id.org/ride2rail/rb-events# (rbe: prefix) using a similar approach.

The license adopted is the Creative Commons with Attribution right (CC-BY),
which allows licensees to copy and distribute the work and make derivative
works, giving the authors proper credits.

All the material related to the ontology and the artifacts produced during the
ontology engineering process are hosted on Github under the Ride2Rail
organisation in the repository https://github.com/Ride2Rail/agreement-ledger-
ontology.

##  5 Modelling Business Agreements

In this section, we exemplify the usage of the defined _Ride2Rail Ontology for
Agreements_ discussing the RDF representation of the business agreements
implemented through the Agreement Ledger Module in the Ride2Rail project,
i.e., the ridesharing booking and the incentives. We decided to distinguish
between the ontology and the agreements since the definition of different
business agreements (e.g. different conditionals and incentives) is made
possible by relying on the implemented ontology.

The RDF dataset is published at https://w3id.org/ride2rail/agreements# (ag:
prefix) and hosted on Github171717https://github.com/Ride2Rail/agreement-
ledger-ontology/tree/main/agreements. A Chowlk diagram is provided in the
ontology documentation for each _oasis:SmartContract_ 181818The Chowlk
diagrams for the defined _r2r:IncentiveSmartContract_ s are available also in
the repository https://github.com/Ride2Rail/agreement-ledger-
ontology/tree/main/docs/diagrams. In the following, we discuss the defined
agreements and the expected usage of the terms in the considered scenario.

Figure 2: Diagram describing the _RidesharingBookingSmartContract_ agreement.

The first agreement is the _ag:RidesharingBookingSmartContract_ that defines
the entities associated with a ridesharing booking and their relations. Figure
2 represents the Chowlk diagram describing the modelled _oasis:SmartContract_.
An _ag:RidesharingBookingSmartContract_ involves an _r2r:Driver_ and an
_osdm:Passenger_ as participants in an _r2r:RidesharingBooking_. The agreement
specifies that the _r2r:RidesharingBooking_ is associated with an
_r2r:OfferItem_ for the passenger, that has a specific _osdm:Price_ , is
associated with an _r2r:RidesharingLeg_ , and includes an
_r2r:InventoryReservation_. The _r2r:RidesharingLeg_ has as transportation
service an _r2r:Ride_ offered by the driver with a specific
_r2r:InventoryAllocation_.

The _ag:RidesharingBookingSmartContract_ does not define any
_oasis:Conditional_ since the terms of the agreement are not directly modelled
through the Agreement Ledger Module. Table LABEL:tab:conditionals defines
examples of _oasis:Conditional_ that can be defined exploiting the ontology,
in particular, leveraging the ride-sharing booking events taxonomy. Example 1
describes the fact that the money from the passenger should be transferred to
the driver if the ride is correctly started and ended, examples 2 and 3
describe potential refund policies if the driver doesn’t show up or cancels
the ride.

The Agreement Ledger Module implemented in Ride2Rail defines three agreements
related to incentives, i.e., three _r2r:IncentiveSmartContract_ : Ride with
other passengers (_ag:RideWithOtherPassengersIncentive_), Multimodal discount
(_ag: MultimodalDiscountIncentive_), Multimodal repetition discount
(ag:_MultimodalDiscountIncentive3_).
Table LABEL:tab:incentivesm summarises the defined agreements reporting the
_oasis:SmartContractEntry_ involved and the modelled _oasis:Conditional_. All
the agreements are between an _osdm:Passenger_ and a _tmorg:Operator,_ then:

  * •

_ag:RideWithOtherPassengersIncentive_ defines a conditional specifying that if
the passenger books a ride also booked by another passenger, then the TSP
issues an _r2r:SeatUpgradeVoucher_ to the passenger;

  * •

_ag:MultimodalDiscountIncentive_ defines a conditional specifying that if the
passenger books a multimodal ride involving an _r2r:RidesharingLeg_ and at
least another leg, then the TSP issues an _r2r:DiscountVoucher_ of 10% to the
passenger;

  * •

_ag:MultimodalDiscountIncentive3_ defines a conditional specifying that if the
passenger books a multimodal ride involving an r2r:RidesharingLeg and at least
another leg for three times, then the TSP issues an r2r:DiscountVoucher of 20%
to the passenger.

Table 2: Example of _oasis:Conditional_ for a ride-sharing booking smart contract.  Conditional | example-1 | example-2 | example-3
---|---|---|---
Entities | Participant |  | Passenger
---
Driver
| Passenger
---
Driver
| Passenger
---
Driver
Value |  | Ridesharing
---
Booking
| Ridesharing
---
Booking
| Ridesharing
---
Booking
Body | Subject |  | Ridesharing
---
Booking
| Ridesharing
---
Booking
| Ridesharing
---
Booking
Operator |  | is associated
---
with
| is associated
---
with
| is associated
---
with
Object | Start Event, End Event |  | Cancelled
---
Driver
| No Show
---
Driver
Head | Subject | Passenger | - | -
| Input
---
Parameter
Price | - | -
Operator | pay | refund | refund
| Output
---
Parameter
- | Price | Price
Object | Driver | Passenger | Passenger
Table 3: _IncentiveSmartContract_ s implemented in Ride2Rail Incentive Smart Contract |  | Ride
---
With Other
Passengers
Incentive
| Multimodal
---
Discount
Incentive
| Multimodal
---
Repetition
Discount
Incentive
Entities | Participant |  | Passenger P1
---
Travel Service
Provider TSP
| Passenger P1
---
Travel Service
Provider TSP
| Passenger P1
---
Travel Service
Provider TSP
Body | Subject |  | Passenger P1,
---
Passenger P2
Passenger | Passenger
Operator |  | makes
---
a booking
| makes
---
a booking
| makes
---
a booking
| Operator
---
Argument
- | - | 3 times
Object | Ride R1 |  | Offer for a
---
Trip involving a
Ridesharing Leg
and another Leg
| Offer for a
---
Trip involving a
Ridesharing Leg
and another Leg
Head | Subject | TSP | TSP | TSP
Operator | issue | issue | issue
Object |  | Seat Upgrade
---
Voucher for
Passenger P1
| 10% Discount
---
Voucher for
Passenger
| 20% Discount
---
Voucher for
Passenger

The described _oasis:SmartContract_ s not only enable the sharing of the
modelled business agreements between the IP4 stakeholders, but also the
representation of smart contract instances stored on the blockchain to support
the use cases defined.

##  6 Conclusions

In an ecosystem comprehending various stakeholders, the implementation of
business agreements through a distributed ledger provides several benefits
regarding information trust and the automatic execution of the agreed terms
modelled as smart contracts. This approach, however, doesn’t provide any
guarantee about the interoperability of the defined agreements from a
technological and semantic perspective. On one hand, the domain terminology
shared among the involved stakeholders should be referenced by the modelled
entities, on the other hand, other software systems can benefit from a
machine-readable representation of the agreements.

The concept of ontological smart contract, defined in the OASIS ontology,
supports the representation of business agreements independently from their
implementation and relying on standardised vocabularies. The defined
_Ride2Rail Ontology for Agreements_ enables the application of this concept to
support the interoperability of business agreements in the multimodal
transportation scenario considered by the Ride2Rail project. Two use cases
were considered: the representation of the ride-sharing booking as an
agreement between the driver and the passengers for dispute resolution, and
the definition of incentives as agreements between different stakeholders to
promote the usage of multimodal transportation. In the paper, we validated and
exemplified the usage of the ontology by modelling the specific business
agreements implemented in the project on the ledger.

The discussed approach can be generalised to support an ontological
representation of smart contracts in different domains. The following steps
summarise the discussed activities: (i) investigation of the business
agreements to be modelled in the considered scenario (use cases and user
stories), (ii) analysis of the domain terminology covered by the business
agreements (facts and competency questions), (iii) identification of existing
vocabularies covering the relevant domain entities and relationships, and/or
implementation of an ontology supporting their representation, (iv) modelling
of each business agreement as an ontological smart contract identifying the
involved entities and the terms of the agreement, and, optionally, (v)
representation of specific entities of the business agreement stored on the
ledger using the ontology. In this way, different stakeholders are able to
access through uniform terminology a description of the smart contracts and,
possibly, their instances.

In future work, we will investigate the materialisation/virtualisation of
smart contracts and/or related instances from the blockchain to enable
querying according to the defined ontology. In particular, we will explore the
configuration of semantic conversion pipelines [17] and the exploitation of
the obtained knowledge graph. Moreover, we would like to extend the scope of
the defined ontology to enable the representation of heterogeneous agreements
in the multimodal transportation domain, for example, considering requirements
for the sharing and electric mobility [18]. Finally, the evolution of the
suite of IP4 ontologies will be taken into account to extend and update the
defined ontology.

###### Acknowledgements.

The presented research was supported by the RIDE2RAIL project (Grant Agreement
881825), co-funded by the European Commission under the Horizon 2020 Framework
Programme. We would like to thank Daniele Santamaria for his support regarding
the OASIS ontology.

## References

  * [1] Cantone D, Longo CF, Nicolosi Asmundo M, Santamaria DF, Santoro C.  Ontological Smart Contracts in OASIS: Ontology for Agents, Systems, and Integration of Services.  In: Intelligent Distributed Computing XIV. Studies in Computational Intelligence. Cham: Springer International Publishing; 2022\. p. 237-47.
  * [2] Ride2Rail Project. D3.5 - Ride-sharing Agreements Ledger Module; 2022.  Project Deliverable (pending approval by EC).  Available from: https://ride2rail.eu/resources-library/.
  * [3] Ride2Rail Project. D2.1 - First conceptualization of choice criteria and incentives; 2020.  Project Deliverable.  Available from: https://doi.org/10.5281/zenodo.4537031.
  * [4] Ride2Rail Project. D2.4 - Final conceptualization of choice criteria and incentives; 2021.  Project Deliverable.  Available from: https://doi.org/10.5281/zenodo.4607203.
  * [5] Ride2Rail Project. D3.1 - Quantitative Estimate of Service Quality Factors; 2021.  Project Deliverable.  Available from: https://doi.org/10.5281/zenodo.6803935.
  * [6] Poveda-Villalón M, Fernández-Izquierdo A, García-Castro R. Linked Open Terms (LOT) Methodology; 2019.  Publisher: Zenodo.  Available from: https://zenodo.org/record/2539305.
  * [7] Cano-Benito J, Cimmino A, García-Castro R.  Towards Blockchain and Semantic Web.  In: Business Information Systems Workshops. Lecture Notes in Business Information Processing. Cham: Springer International Publishing; 2019. p. 220-31.
  * [8] De Kruijff J, Weigand H.  Ontologies for Commitment-Based Smart Contracts.  In: On the Move to Meaningful Internet Systems. OTM 2017 Conferences. Lecture Notes in Computer Science. Cham: Springer International Publishing; 2017. p. 383-98.
  * [9] De Kruijff J, Weigand H.  Understanding the Blockchain Using Enterprise Ontology.  In: Advanced Information Systems Engineering. Lecture Notes in Computer Science. Cham: Springer International Publishing; 2017. p. 29-43.
  * [10] McAdams D.  An Ontology for Smart Contracts.  IOHK paper; 2017. p. 3.  Accessed online at https://cryptopapers.info/assets/pdf/ontology_for_smart_contracts.pdf.
  * [11] Cantone D, Longo CF, Nicolosi-Asmundo M, Santamaria DF, Santoro C.  Towards an Ontology-Based Framework for a Behavior-Oriented Integration of the IoT.  In: Proceedings of the 20th Workshop “From Objects to Agents”. vol. 2404 of CEUR Workshop Proceedings. Parma, Italy: CEUR; 2019. p. 119-26.  ISSN: 1613-0073.  Available from: http://ceur-ws.org/Vol-2404/#paper18.
  * [12] CONNECTIVE Project. D1.2 – Architectural Principles and Design A-REL; 2020.  Project Deliverable.  Available from: https://projects.shift2rail.org/s2r_ip4_n.aspx?p=MaaSive.
  * [13] Ruckhaus E, Anton-Bravo A, Scrocca M, Corcho O.  Applying the LOT Methodology to a Public Bus Transport Ontology aligned with Transmodel: Challenges and Results.  Semantic Web. 2021 Jan;Pre-press:1-19.  Publisher: IOS Press.  Available from: https://doi.org/10.3233/SW-210451.
  * [14] Feria SC, García-Castro R, Poveda-Villalón M.  Converting UML-based ontology conceptualizations to OWL with Chowlk; 2021. Available from: https://openreview.net/forum?id=u1Vp2y_QE1.
  * [15] Poveda-Villalón M, Suárez-Figueroa MC, Gómez-Pérez A.  Validating Ontologies with OOPS!  In: Knowledge Engineering and Knowledge Management. Lecture Notes in Computer Science. Berlin, Heidelberg: Springer; 2012. p. 267-81.
  * [16] Garijo D.  WIDOCO: A Wizard for Documenting Ontologies.  In: The Semantic Web – ISWC 2017. vol. 10588. Springer International Publishing; 2017. p. 94-102.  Series Title: Lecture Notes in Computer Science.  Available from: http://link.springer.com/10.1007/978-3-319-68204-4_9.
  * [17] Scrocca M, Comerio M, Carenini A, Celino I.  Turning Transport Data to Comply with EU Standards While Enabling a Multimodal Transport Knowledge Graph.  In: Proceedings of the 19th International Semantic Web Conference. vol. 12507. Springer; 2020. p. 411-29.  Available from: https://doi.org/10.1007/978-3-030-62466-8_26.
  * [18] Scrocca M, Baroni I, Celino I.  Urban IoT ontologies for sharing and electric mobility.  Semantic Web. 2021 Jan;Pre-press:1-22.  Publisher: IOS Press.  Available from: https://doi.org/10.3233/SW-210445.


| Arjun Soin111Joint first authors
---
Stanford University
Center for Artificial
Intelligence in Medicine
and Imaging (AIMI)
| Pratik Bhatu111Joint first authors
---
Microsoft Research
| Rohit Takhar
---
CARING Research
| Nishanth Chandran
---
Microsoft Research
Divya Gupta Microsoft Research |  | Javier Alvarez-Valle
---
Microsoft Research
| Rahul Sharma222Corresponding author
---
Microsoft Research
| Vidur Mahajan333Joint senior authors
---
CARING Research
Matthew P Lungren333Joint senior authors Stanford University Center for
Artificial Intelligence in Medicine and Imaging (AIMI)
22footnotetext: Corresponding author

# Production-level Open Source Privacy Preserving Inference in Medical Imaging

###### Abstract

Adoption of artificial intelligence medical imaging applications is often
impeded by barriers between healthcare systems and algorithm developers given
that access to both private patient data and commercial model IP is important
to perform pre-deployment evaluation. This work investigates a framework for
secure, privacy-preserving and AI-enabled medical imaging inference using
CrypTFlow2, a state-of-the-art end-to-end compiler allowing cryptographically
secure 2-party Computation (2PC) protocols between the machine learning model
vendor and target patient data owner. A common DenseNet-121 chest x-ray
diagnosis model was evaluated on multi-institutional chest radiographic
imaging datasets both with and without CrypTFlow2 on two test sets spanning
seven sites across the US and India, and comprising 1,149 chest x-ray images.
We measure comparative AUROC performance between secure and insecure inference
in multiple pathology classification tasks, and explore model output
distributional shifts and resource constraints introduced by secure model
inference. Secure inference with CrypTFlow2 demonstrated no significant
difference in AUROC for all diagnoses, and model outputs from secure and
insecure inference methods were distributionally equivalent. The use of
CrypTFlow2 may allow off-the-shelf secure 2PC between healthcare systems and
AI model vendors for medical imaging, without changes in performance, and can
facilitate scalable pre-deployment infrastructure for real-world secure model
evaluation without exposure to patient data or model IP.

##  1 Introduction

While machine learning algorithms for healthcare applications are being
developed at an ever increasing pace, problems associated with lack of
generalisability and bias of these algorithms demand robust pre-deployment
testing on real-world patient data. This dichotomy exposes a critical need for
healthcare providers to have mechanisms for pre-deployment evaluation of
clinical machine learning models to ensure that real-world model performance
is in line with the expectations of the end-user of the model. Practical
barriers exist while implementing such evaluation mechanisms particularly when
access to both patient data and model intellectual property (IP) are
necessary; these include legal, privacy, regulatory, data sharing, and more.
The challenge arises from what is referred to as a “low trust” environment
between model vendors and healthcare systems where confidentiality and
compliance around exposure of patient data or model IP are governed by
technical and legal mechanisms which are generally resource intensive. A
similar scenario unfolds upon running Kaggle-like data challenge competitions
to evaluate machine learning models by various teams because competitions
provide no security to the model owner and model weights are revealed to the
testing authorities [2].

On the technical side, healthcare providers may mandate on-premise deployment
of models, which often leads model developers to run their models as Docker
containers while adopting hardening techniques such as disabling inbound
protocols and ports, encrypting model weight files, disabling the root
account, or compiling the model to C - to ensure that their IP is protected
while deployed in the healthcare provider’s premises. For healthcare systems
with cloud infrastructure, providing anonymized patient data to vendors or
platform providers still requires complex Business Associate Agreements (BAA)
and Institutional Review Board (IRB) clearances, making the process of testing
models time consuming and complex [1, 20]. Given the large number of
commercial models for varying use cases, using different data inputs and model
deployment approaches, applying the technical and legal safeguards described
above becomes extremely daunting particularly as a given platform service
cannot offer all viable models or vendors that would be contenders for use.

Less resource-intensive solutions to address the trust requirements include
secure privacy-preserving machine learning approaches (PPML) to ensure privacy
and confidentiality for both parties (data and model) while still allowing
full analysis via secure inference. Recent advances in cryptography have made
secure inference almost 1000x more efficient than prior state-of-the-art,
thereby making it feasible for production usage [21, 34, 33]. With PPML, the
hospital and the vendor can use 2-party secure inference (see Appendix A and
[34, 27, 22, 18, 25]) to evaluate a model on unseen patient data, paving the
way for the hospital to test the model, while simultaneously ensuring that the
vendor learns nothing about the patient data and the hospital learns nothing
about the proprietary model weights beyond the output prediction values.

This work provides the first evaluation of 2-party secure model testing on
multi-institutional medical datasets. Prior relevant work, PriMiA, [19]
demonstrated the potential for PPML technology to protect the security of both
sensitive patient data and proprietary machine learning models in healthcare
with encrypted inference; however PPML remains largely under-explored in the
field, specifically in medical imaging applications, and work like PriMiA
suffers from limitations such as weaker security guarantees, inability to use
large models (as needed in medical imaging), requirement of domain expertise
for implementation, poor reproducibility, and unsupported code-bases [19].
Furthermore, prior work has failed to outline absolute computation costs of
encrypted inference and explore performance variations between the insecure
and secure executions.

The purpose of this work is to rigorously evaluate PPML technologies for use
in medical imaging applications with real world medical imaging data and
modern computer vision models. We seek to answer the following two research
questions:

  1. 1.

Is there a change in performance between insecure and secure model testing for
clinical computer vision inference?

  2. 2.

What are the trade-offs for secure model testing with regard to computational,
inference time, and communication overheads imposed by secure two-party
computation (2PC)?

##  2 Methods

###  2.1 Secure 2-party computation (2PC)

Secure 2-party computation (2PC), introduced in the seminal works of [43, 15]
considers 2 parties, usually called Alice and Bob in cryptography literature,
having secret inputs $w$ and $x$ respectively. It enables Alice and Bob to
securely compute any arbitrary function $F$ over $w$ and $x$. Furthermore, 2PC
provides a strong mathematical security guarantee that both parties learn
absolutely nothing about the other party’s sensitive input (beyond what can be
deduced from the party’s output itself). It is easy to see that secure model
testing is a special case of 2PC for an iterative computation of $F$ on the
test set, where $F$ is a machine learning model with weights $w$ and input
$x$.

2PC is realized through an interactive protocol run between Alice and Bob. The
parties exchange encrypted values or secret shares [40] with each other and
further compute on them. Intuitively speaking, one can argue that each party
computes on data which is cryptographically guaranteed to be indistinguishable
from random therefore revealing no information about the other party’s
sensitive inputs. We provide a simplified example of a 2PC protocol in
Appendix B. However, this strong security guarantee comes at a cost: computing
on encrypted values or secret shares and executing the multi-round interactive
protocol makes 2PC computationally more expensive to perform than insecure
computations.

(a) Compilation

(b) Runtime

Figure 1: Overview of CrypTFlow2 Compilation and Runtime Flow

###  2.2 Model use case

Although 2PC is applicable to arbitrary ML models, we focus on the following
use case: Automated chest X-ray interpretation both insecurely (using PyTorch
[29]) and securely (using CrypTFlow2 [34]). Chest X-rays are the most common
imaging examination in the world, critical for the diagnosis and management of
many diseases [32]. With over 2 billion chest X-rays performed globally each
year, many healthcare systems around the world lack sufficient number of
trained radiologists to perform timely interpretation [24]. Numerous studies
have shown the competency of Convolutional Neural Networks (CNNs) in achieving
performance matching radiologists [31, 17, 42, 38] and dozens of models are
available in both the research and commercial spaces. However, some major
obstacles to clinical adoption and widespread experimentation remain data
protection required to adequately protect the privacy of patients, and
intellectual property considerations for AI developers to be able to preserve
and protect the IP rights that they assert over their algorithms. Another
noteworthy legal consideration is that of data stewardship and associated
liability [14, 12].

####  2.2.1 Model architecture

We use a 7-million parameter, 121-layer Dense Convolutional Network (DenseNet)
[16] trained on the CheXpert dataset [17]. The model takes as input a single-
view chest X-ray image of size 320 × 320 pixels and outputs the probability of
14 observations - No Finding, Enlarged Cardiomediastinum, Cardiomegaly, Lung
Opacity, Lung Lesion, Edema, Consolidation, Pneumonia, Atelectasis,
Pneumothorax, Pleural Effusion, Pleural Other, Fracture, Support Devices. If
more than one view (a frontal view and a lateral view) is available, the model
outputs the maximum probability of the observations across the views.

The model used in this work is originally implemented in PyTorch and is a
submission to the CheXpert competition [17]. CheXpert’s competition has been
running from January 2019 featuring a strong radiologist-labeled reference
standard. The top 5 model checkpoints from the CheXpert competition under the
U-Ones scheme (where uncertain labels are considered positive) as of November
2020 are first selected. We then use the model checkpoint (weights) that
yields the best performance scores on 5 pathologies with high prevalence in
reports and clinical relevance (Cardiomegaly, Pleural Effusion, Consolidation,
Edema and No Finding). Secure inference is run with this best-performing model
checkpoint using CrypTFlow2 [34] (Section 2.4.1).

###  2.3 Test sets and metrics

To test the model on unseen patient data, we use multi-institutional chest
radiographic imaging datasets on two test sets spanning seven sites across the
US and India, and comprising 1,149 chest x-ray images. With strong
radiologist-annotated ground truth and expert scores against which to compare
algorithms, the test sets serve as strong reference standards to allow for
robust evaluation of models integrated across both, our insecure and secure
deep learning pipelines. Considering clinical importance and prevalence, we
focus on evaluating the following pathologies for the CheXpert test set:
Cardiomegaly, Pleural Effusion, Consolidation, Edema and No Finding. Based on
corresponding clinical relevance, the CARING500 test set is evaluated for
Atelectasis, Cardiomegaly, Consolidation and Pleural Effusion. The accuracy on
both test sets is measured as the standard AUROC score.

####  2.3.1 CheXpert test set

The CheXpert test set comprises 500 studies with 668 images from 500 patients.
Eight board-certified radiologists individually annotated each study in the
test set, classifying each of the 14 observations mentioned in section 2.2.1
into either present, uncertain likely, uncertain unlikely, or absent. The
radiologist annotations were binarized such that every present and uncertain
likely case is treated as positive and every absent and uncertain unlikely
case is treated as negative. The majority vote of 5 radiologist annotations
serves as a strong ground truth.

####  2.3.2 CARING500 test set

This test set comprises of 481 chest X-rays obtained from six sites – three
hospitals and three out-patient imaging centres – annotated by 3 radiologists
at image level for the presence of ten findings - Cardiomegaly, Fibrosis,
Mediastinal Widening, Consolidation, Nodule, Pleural Effusion, Pneumothorax,
Calcification, Atelectasis, Pneumoperitoneum and Overall Abnormal. Consensus
of the 3 readers was taken as ground truth for testing. The data is publicly
available for download (without annotations) from platform.carpl.ai.

###  2.4 Evaluation setup

Both the model owner (ML vendor) and the test set owner (hospital) are virtual
machines (VMs) with commodity class hardware: 3.7 GHz Intel Xeon processor
with 4 cores and 16 GBs of RAM. The ping latency is 0.3ms and the network
bandwidth between the two machines is 3Gbps. Such VMs can readily be obtained
from cloud service providers, e.g. Microsoft Azure.

####  2.4.1 Evaluation process

For insecure execution, we run the PyTorch CheXpert model directly on a given
test set. For secure execution, we export the PyTorch model to an ONNX model,
compile the ONNX model (stripped of model weights) with CrypTFlow2 to generate
an executable for the ML vendor and an executable for the test set owner that
are run on their respective VMs. These two VMs run 2PC which ensures that
sensitive data of a party is never presented in decrypted form outside its VM.
In particular, the executable of the ML vendor reads model weights, the
executable of the test set owners reads an image, and these two executables
run a 2PC for secure inference over the network connection between them. We
run intermediary tests to confirm that the compiled ONNX model uses an
executable by the test set owner that is devoid of any proprietary weights
from the ML vendor. The ONNX computation graph initializer, that is otherwise
used to recover information about model weights, yields an empty value for
each experiment we run, signifying a complete absence of proprietary weights
in the model received by the test set owner. A detailed flow of compilation
and runtime for our experiments is outlined in Figure 1.

By using ONNX (Open Neural Network Exchange) [4] as a frontend, CrypTFlow2 is
applicable to models expressed in various ML platforms like Keras [10],
TensorFlow [5], PyTorch [29], etc. It first converts the models to ONNX using
existing converters and then compiles the ONNX model to 2PC protocols. Our
model is converted using the in-built ONNX converter from the Torch library
(see Appendix D).

####  2.4.2 Evaluation metrics

We evaluate the average time and data communication needed for secure
inference on each image and compare it to the time and communication needed
for the insecure inference.

The performance or accuracy on these tests is measured as the standard AUROC
score. It is a discrimination measure which demonstrates how well the model
can classify patients in two groups: those with and those without a given
pathology of interest. The AUROC is calculated as the area underneath a curve
that measures the tradeoff between true positive rate (TPR) and false positive
rate (FPR) at different decision thresholds. A test with no better accuracy
than chance has an AUROC of 0.5, and a test with perfect accuracy has an AUROC
of 1.0. Accordingly, an AUROC = 0.90 indicates that 90% of the time we draw a
test X-ray from the disease group and non-disease group, the output value from
the disease group will be greater [9]. We use nonparametric bootstrap to
estimate 95% confidence intervals for the AUROC scores.

To confirm that model output results from secure and insecure inference are
distributionally equivalent, a two-sample Kolmogorov-Smirnov (K-S) test is
calculated (Tables 3 and 3 ). The K-S test is a nonparametric test of the
equality of continuous, one-dimensional probability distributions that can be
used to compare a sample with a reference probability distribution [23]. We
use inference results from insecure PyTorch inference as reference data and
results from CrypTFlow2-based secure inference as the sample distribution to
compare with. Under the null hypothesis, there is no difference between the
two (secure and insecure) distributions. If the K-S statistic is small or the
p-value is high (> 5%), we do not reject the hypothesis that the distributions
of secure and insecure model outputs are sampled from identical populations.
Conversely, we reject the null hypothesis if the p-value is low (< 5%) and
conclude that CrypTFlow2 introduces distributional shift in model outputs.

##  3 Results

Secure and insecure model accuracy and classification performance comparisons
for the two test sets can be found in Tables 3 and 3. For all diagnoses across
test sets, we observe that the accuracy (AUROC) of secure testing matches the
accuracy (AUROC) of insecure testing. Our model is also shown to be well-
calibrated with significantly low and matching Brier scores [36] across both,
the secure and insecure outputs. We provide these scores in Appendix E. Model
outputs from CrypTFlow2-based secure and insecure inference methods have
matching distributions for all diagnoses across both test sets.

Resources needed for insecure and secure model testing to understand the
trade-off is shown in Table 3. Each secure inference task (per image) takes 15
minutes to run and communicates 60GB data between the two machines. Since each
secure inference can be done in parallel, the time taken to do secure
inference on a test set can be reduced to time taken for a secure inference on
a single image by using many VMs. The insecure run takes ≈ 0.3s per image and
the size of an X-ray is 0.3MB.

Secure model testing overheads Model Time (s) Communication (GB) CheXpert
U-Ones 900 60

[H] Insecure vs. Secure AUROC on CheXpert test set Pathologies AUROC scores
(95% CI${}^{\text{a}}$) Insecure inference Secure inference No Finding 0.90
[0.87 - 0.93] 0.90 [0.87 - 0.93] Cardiomegaly 0.88 [0.84 - 0.9] 0.90 [0.87 -
0.93] Edema 0.89 [0.85 - 0.92] 0.89 [0.85 - 0.92] Consolidation 0.81 [0.73 -
0.88] 0.82 [0.74 - 0.89] Pleural Effusion 0.95 [0.93 - 0.97] 0.95 [0.93 -
0.97] Average AUROC${}^{\text{b}}$ 0.89 [0.84 - 0.92] 0.89 [0.85 - 0.93]

  * •

a. AUROC scores with 95% Bootstrapped Confidence Intervals

  * •

b. Average AUROC reports the arithmetic mean of pathology-wise AUROC scores
presented. Micro and Macro average AUROC scores are also presented in Figure 2

[H] Insecure vs. Secure AUROC on CARING500 test set Pathologies AUROC scores
(95% CI${}^{\text{a}}$) Insecure inference Secure inference Atelectasis 0.83
[0.78 - 0.87] 0.83 [0.78 - 0.87] Cardiomegaly 0.95 [0.93 - 0.97] 0.95 [0.93 -
0.97] Consolidation 0.88 [0.83 - 0.92] 0.88 [0.84 - 0.92] Pleural Effusion
0.97 [0.96 - 0.98] 0.97 [0.96 - 0.98] Average AUROC${}^{\text{b}}$ 0.90 [0.88
- 0.94] 0.90 [0.88 - 0.94]

  * •

a. AUROC scores with 95% Bootstrapped Confidence Intervals

  * •

b. Average AUROC reports the arithmetic mean of pathology-wise AUROC scores
presented. Micro and Macro average AUROC scores are also presented in Figure 3

[H] K-S test for insecure vs. secure output distributions on CheXpert Task
Test Statistic (K-S) p-Value (K-S test) Null hypothesis (secure $\equiv$
insecure) No Finding 0.014 0.99 Accepted Cardiomegaly 0.076 0.11 Accepted
Edema 0.034 0.94 Accepted Consolidation 0.058 0.37 Accepted Pleural Effusion
0.036 0.90 Accepted

  * •

a. Test performed with model output probabilities rounded off to two decimal
places

  * •

b. Accepted hypotheses indicate matching secure and insecure model output
distributions

[H] K-S test for insecure vs. secure output distributions on CARING500 Task
Test Statistic (K-S) p-Value (K-S test) Null hypothesis (secure $\equiv$
insecure) Atelectasis 0.002 0.99 Accepted Cardiomegaly 0.004 1.0 Accepted
Consolidation 0.002 0.99 Accepted Pleural Effusion 0.004 1.0 Accepted

  * •

a. Test performed with model output probabilities rounded off to two decimal
places

  * •

b. Accepted hypotheses indicate matching secure and insecure model output
distributions

(c) Insecure PyTorch inference

(d) Secure CrypTFlow2 inference

Figure 2: CheXpert test ROC curves

(a) Insecure PyTorch inference

(b) Secure CrypTFlow2 inference

Figure 3: CARING500 ROC curves

##  4 Discussion

The purpose of this study was to rigorously evaluate the accuracy and
feasibility of PPML technology for use in medical imaging machine learning
applications. We used secure 2-party model testing for chest xray use cases in
a multi-institution evaluation with readily available commodity hardware. We
found no significant difference in performance compared to insecure model
testing. The average performance metrics yielded were as follows: 0.89 AUROC
(95% CI, 0.84 to 0.92) secure, 0.89 AUROC (95% CI, 0.84 to 0.93) insecure on
CheXpert test set and 0.9 AUROC (95% CI, 0.88 to 0.94) secure, 0.9 AUROC
insecure (95% CI, 0.88 to 0.94) on CARING500 test set. Moreover, we obtained
distributional equivalence between secure and insecure output, with the K-S
test null hypotheses being accepted for all diagnoses across both the test
sets. Model calibration (as measured by the values and parity of Brier scores)
was also maintained between the secure and insecure methods.

Other systems for encrypted inference either have not been evaluated with
real-world scale models [27, 25, 18, 8, 22], lack sufficient security
guarantees [11, 7, 21], or both [8, 19, 3, 35, 26, 41, 37] (Section 1). In
particular, works in the latter two categories introduce a non-colluding third
party to simplify the problem of secure inference at the expense of weakening
the security by introducing a dependency on a third party. Involving such a
third party might prove counterproductive by increasing the legal and
compliance overhead, thereby slowing down the process of testing and
deployment of machine learning models in healthcare settings. Note that 2PC is
compatible with differential privacy [6, 30] and they can be combined for the
scenarios that require masking the predicted output.

CrypTFlow2 is open-source, backed by unit tests, and is actively maintained
with both TensorFlow and PyTorch models, and previous preliminary work found
feasibility for use with both 2D Chest X-rays and 3D CT scans [28, 7]. This
work found that, in contrast to prior efforts, CrypTFlow2 is an end-to-end
production ready open source solution with important but manageable tradeoffs
between security and inference time for real-world clinical use cases in
medical imaging applications. Technologies such as CrypTFlow2 can possibly
remove the requirement for de-identification and anonymisation of medical
imaging data for the purposes of model inference; removing the substantial
privacy-related barriers to large-scale testing of multiple models by
healthcare providers without the technical hurdles of deploying models on-prem
and the requirement for complicated legal safeguards will not just enable
hospitals to evaluate and adopt machine learning solutions faster, but also
allow for more efficient feedback loops between model users and developers.

While insecure inference took approximately 0.3 seconds to process a single
image, it is critical to remember that to arrive at the stage where a model
deployed through insecure inference can truly be validated on real world data,
countless legal agreements need to be signed, which can take several weeks, if
not months, to become actionable. On the other hand, while secure inference
took about 15 minutes (900 seconds) per image, the fact that each party
(healthcare provider and model developer) does not have access to the other’s
proprietary data or IP can significantly speed up the process of executing
model validation. Overall, while secure inference takes $3000\times$ longer
than insecure inference in computation time, the absolute time to validation
results can be reduced dramatically. Additionally, the legal costs saved can
offset the higher data transfer and compute requirements of secure inference.

There are several limitations worth highlighting. First, while this work
reports results on real world clinical data with measurements of real-time
inference, the validation was run retrospectively with well qualified and
curated data. Real-world prospective deployment in clinical settings would
give insights into the feasibility of using secure inference not just for
testing but also for deployment. Second, the feasibility of running secure
inference on large multi-slice and multi-parametric datasets such as CT, MRI
and PET were not explored but are expected to increase time and computation.
Third, a detailed costing analysis that measures the cost of computation and
bandwidth required for secure inference and compares it with the legal and
compliance costs of signing multiple agreements for testing AI is out of the
scope of this work, but is especially important in a scenario where data
sharing may become more difficult for hospitals [20].

In conclusion, CrypTFlow2 demonstrated state-of-the-art encrypted model
inference for multi-class chest radiograph classification, with performance
matching native deployment. This work, an open-source production-ready
supported solution, offers a viable approach toward AI-enabled clinical
imaging model inference analysis while preserving patient data and model
privacy. Future work may leverage CrypTFlow2 on clinical machine learning
platforms to allow for secure inference results on clinical data, affording
scalable comparison across a growing variety of vendors and models, obviating
the need for resource intensive legal and data sharing complexities.

## References

  * [1] Guidance Regarding Methods for De-identification of Protected Health Information in Accordance with the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule.  https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html.
  * [2] Kaggle competitions.  https://www.kaggle.com/competitions.
  * cry [2019] Crypten by Facebook, 2019.  URL https://github.com/facebookresearch/CrypTen.
  * onn [2021] Open Neural Network Exchange (ONNX) .  https://github.com/onnx/onnx, 2021.
  * Abadi et al. [2016a] Martín Abadi, Ashish Agarwal, Paul Barham, Eugene Brevdo, Zhifeng Chen, Craig Citro, Gregory S. Corrado, Andy Davis, Jeffrey Dean, Matthieu Devin, Sanjay Ghemawat, Ian J. Goodfellow, Andrew Harp, Geoffrey Irving, Michael Isard, Yangqing Jia, Rafal Józefowicz, Lukasz Kaiser, Manjunath Kudlur, Josh Levenberg, Dan Mané, Rajat Monga, Sherry Moore, Derek Gordon Murray, Chris Olah, Mike Schuster, Jonathon Shlens, Benoit Steiner, Ilya Sutskever, Kunal Talwar, Paul A. Tucker, Vincent Vanhoucke, Vijay Vasudevan, Fernanda B. Viégas, Oriol Vinyals, Pete Warden, Martin Wattenberg, Martin Wicke, Yuan Yu, and Xiaoqiang Zheng.  TensorFlow: Large-Scale Machine Learning on Heterogeneous Distributed Systems.  _CoRR_ , abs/1603.04467, 2016a.  URL https://arxiv.org/abs/1603.04467.
  * Abadi et al. [2016b] Martín Abadi, Andy Chu, Ian J. Goodfellow, H. Brendan McMahan, Ilya Mironov, Kunal Talwar, and Li Zhang.  Deep learning with differential privacy.  In Edgar R. Weippl, Stefan Katzenbeisser, Christopher Kruegel, Andrew C. Myers, and Shai Halevi, editors, _Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, October 24-28, 2016_ , pages 308–318. ACM, 2016b.
  * Alvarez-Valle et al. [2020] Javier Alvarez-Valle, Pratik Bhatu, Nishanth Chandran, Divya Gupta, Aditya V. Nori, Aseem Rastogi, Mayank Rathee, Rahul Sharma, and Shubham Ugare.  Secure medical image analysis with cryptflow.  _CoRR_ , abs/2012.05064, 2020.  URL https://arxiv.org/abs/2012.05064.
  * Boemer et al. [2020] Fabian Boemer, Rosario Cammarota, Daniel Demmler, Thomas Schneider, and Hossein Yalame.  MP2ML: a mixed-protocol machine learning framework for private inference.  In Melanie Volkamer and Christian Wressnegger, editors, _ARES 2020: The 15th International Conference on Availability, Reliability and Security, Virtual Event, Ireland, August 25-28, 2020_ , pages 14:1–14:10. ACM, 2020.
  * Bradley [1997] Andrew P. Bradley.  The use of the area under the ROC curve in the evaluation of machine learning algorithms.  _Pattern Recogn._ , 30(7):1145–1159, July 1997\.  ISSN 0031-3203.  doi: 10.1016/S0031-3203(96)00142-2.  URL https://doi.org/10.1016/S0031-3203(96)00142-2.
  * Chollet et al. [2015] François Chollet et al.  Keras.  https://github.com/fchollet/keras, 2015.
  * Dalskov et al. [2020] Anders P. K. Dalskov, Daniel Escudero, and Marcel Keller.  Secure evaluation of quantized neural networks.  _Proc. Priv. Enhancing Technol._ , 2020(4):355–375, 2020.
  * for Open Data Enterprise [2019] The Center for Open Data Enterprise.  Sharing and utilizing health data for ai applications, 2019.  https://www.hhs.gov/sites/default/files/sharing-and-utilizing-health-data-for-ai-applications.pdf.
  * Gentry [2009] Craig Gentry.  Fully homomorphic encryption using ideal lattices.  In _Proceedings of the 41st Annual ACM Symposium on Theory of Computing, STOC 2009, Bethesda, MD, USA, May 31 - June 2, 2009_ , pages 169–178. ACM, 2009.
  * Gerke et al. [2020] Sara Gerke, Timo Minssen, and Glenn Cohen.  Ethical and legal challenges of artificial intelligence-driven healthcare.  _Artificial Intelligence in Healthcare_ , pages 295–336, 2020.  doi: 10.1016/B978-0-12-818438-7.00012-5.  URL https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7332220/.
  * Goldreich et al. [1987] Oded Goldreich, Silvio Micali, and Avi Wigderson.  How to Play any Mental Game or A Completeness Theorem for Protocols with Honest Majority.  In _Proceedings of the 19th Annual ACM Symposium on Theory of Computing, 1987, New York, New York, USA_ , pages 218–229, 1987.
  * Huang et al. [2018] Gao Huang, Zhuang Liu, Laurens van der Maaten, and Kilian Q. Weinberger.  Densely connected convolutional networks, 2018.
  * Irvin et al. [2019] Jeremy Irvin, Pranav Rajpurkar, Michael Ko, Yifan Yu, Silviana Ciurea-Ilcus, Chris Chute, Henrik Marklund, Behzad Haghgoo, Robyn L. Ball, Katie S. Shpanskaya, Jayne Seekins, David A. Mong, Safwan S. Halabi, Jesse K. Sandberg, Ricky Jones, David B. Larson, Curtis P. Langlotz, Bhavik N. Patel, Matthew P. Lungren, and Andrew Y. Ng.  Chexpert: A large chest radiograph dataset with uncertainty labels and expert comparison.  _CoRR_ , abs/1901.07031, 2019.  URL http://arxiv.org/abs/1901.07031.
  * Juvekar et al. [2018] Chiraag Juvekar, Vinod Vaikuntanathan, and Anantha Chandrakasan.  GAZELLE: A Low Latency Framework for Secure Neural Network Inference.  In _27th USENIX Security Symposium, USENIX Security 2018, Baltimore, MD, USA, August 15-17, 2018_ , pages 1651–1669, 2018.
  * Kaissis et al. [2021] G Kaissis, A Ziller, J Passerat-Palmbach, T Ryffel, D Usynin, A Trask, I Lima, J Mancuso, F Jungmann, M-M Steinborn, A Saleh, M Makowski, D Rueckert, and R Braren.  End-to-end privacy preserving deep learning on multi-institutional medical imaging.  _NATURE MACHINE INTELLIGENCE_ , 2021.  doi: 10.1038/s42256-021-00337-8.  URL http://dx.doi.org/10.1038/s42256-021-00337-8.
  * Kotsenas et al. [2021] Amy L. Kotsenas, Patricia Balthazar, David Andrews, J. Raymond Geis, and Tessa S. Cook.  Rethinking patient consent in the era of artificial intelligence and big data.  _Journal of the American College of Radiology_ , 18(1, Part B):180–184, 2021.  ISSN 1546-1440.  Special Issue: Provocative Issue.
  * Kumar et al. [2020] Nishant Kumar, Mayank Rathee, Nishanth Chandran, Divya Gupta, Aseem Rastogi, and Rahul Sharma.  Cryptflow: Secure tensorflow inference.  In _2020 IEEE Symposium on Security and Privacy, SP 2020, San Francisco, CA, USA, May 18-21, 2020_ , pages 336–353. IEEE, 2020.
  * Liu et al. [2017] Jian Liu, Mika Juuti, Yao Lu, and N. Asokan.  Oblivious Neural Network Predictions via MiniONN Transformations.  In _Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, CCS 2017, Dallas, TX, USA, October 30 \- November 03, 2017_ , pages 619–631, 2017.
  * Massey [1951] F. J. Massey.  The Kolmogorov-Smirnov test for goodness of fit.  _Journal of the American Statistical Association_ , 46(253):68–78, 1951.
  * Mathers and Loncar [2006] Colin D. Mathers and Dejan Loncar.  Projections of global mortality and burden of disease from 2002 to 2030\.  _PLoS medicine_ , 3(11):e442, November 2006.  ISSN 1549-1676.  doi: 10.1371/journal.pmed.0030442.
  * Mishra et al. [2020] Pratyush Mishra, Ryan Lehmkuhl, Akshayaram Srinivasan, Wenting Zheng, and Raluca Ada Popa.  Delphi: A Cryptographic Inference Service for Neural Networks.  In _29th USENIX Security Symposium, USENIX Security 20_ , Boston, MA, 2020.
  * Mohassel and Rindal [2018] Payman Mohassel and Peter Rindal.  ABY${}^{\mbox{3}}$: A Mixed Protocol Framework for Machine Learning.  In _Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS 2018, Toronto, ON, Canada, October 15-19, 2018_ , pages 35–52, 2018.
  * Mohassel and Zhang [2017] Payman Mohassel and Yupeng Zhang.  SecureML: A System for Scalable Privacy-Preserving Machine Learning.  In _2017 IEEE Symposium on Security and Privacy, S &P 2017, San Jose, CA, USA, May 22-26, 2017_, pages 19–38, 2017.
  * Oktay et al. [2020] Ozan Oktay, Jay Nanavati, Anton Schwaighofer, David Carter, Melissa Bristow, Ryutaro Tanno, Rajesh Jena, Gill Barnett, David Noble, Yvonne Rimmer, Ben Glocker, Kenton O’Hara, Christopher Bishop, Javier Alvarez-Valle, and Aditya Nori.  Evaluation of Deep Learning to Augment Image-Guided Radiotherapy for Head and Neck and Prostate Cancers.  _JAMA Network Open_ , 3(11):e2027426–e2027426, 11 2020.  ISSN 2574-3805.  doi: 10.1001/jamanetworkopen.2020.27426.  URL https://doi.org/10.1001/jamanetworkopen.2020.27426.
  * Paszke et al. [2019] Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, Alban Desmaison, Andreas Köpf, Edward Yang, Zachary DeVito, Martin Raison, Alykhan Tejani, Sasank Chilamkurthy, Benoit Steiner, Lu Fang, Junjie Bai, and Soumith Chintala.  Pytorch: An imperative style, high-performance deep learning library.  In Hanna M. Wallach, Hugo Larochelle, Alina Beygelzimer, Florence d’Alché-Buc, Emily B. Fox, and Roman Garnett, editors, _Advances in Neural Information Processing Systems 32: Annual Conference on Neural Information Processing Systems 2019, NeurIPS 2019, December 8-14, 2019, Vancouver, BC, Canada_ , pages 8024–8035, 2019.  URL https://proceedings.neurips.cc/paper/2019/hash/bdbca288fee7f92f2bfa9f7012727740-Abstract.html.
  * Pettai and Laud [2015] Martin Pettai and Peeter Laud.  Combining differential privacy and secure multiparty computation.  In _Proceedings of the 31st Annual Computer Security Applications Conference, Los Angeles, CA, USA, December 7-11, 2015_ , pages 421–430. ACM, 2015.
  * Rajpurkar et al. [2017] Pranav Rajpurkar, Jeremy Irvin, Kaylie Zhu, Brandon Yang, Hershel Mehta, Tony Duan, Daisy Ding, Aarti Bagul, Curtis Langlotz, Katie Shpanskaya, Matthew P. Lungren, and Andrew Y. Ng.  Chexnet: Radiologist-level pneumonia detection on chest x-rays with deep learning, 2017.
  * Raoof et al. [2012] Suhail Raoof, David Feigin, Arthur Sung, Sabiha Raoof, Lavanya Irugulpati, and Edward C. Rosenow.  Interpretation of plain chest roentgenogram.  _Chest_ , 141(2):545–558, February 2012.  ISSN 1931-3543.  doi: 10.1378/chest.10-1302.
  * Rathee et al. [2020a] Deevashwer Rathee, Mayank Rathee, Rahul Kranti Kiran Goli, Divya Gupta, Rahul Sharma, Nishanth Chandran, and Aseem Rastogi.  SIRNN: A math library for secure inference of RNNs.  In _IEEE S &P 2020_, 2020a.
  * Rathee et al. [2020b] Deevashwer Rathee, Mayank Rathee, Nishant Kumar, Nishanth Chandran, Divya Gupta, Aseem Rastogi, and Rahul Sharma.  Cryptflow2: Practical secure 2-party inference.  In _Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security, CCS 2020_. ACM, 2020b.
  * Riazi et al. [2018] M. Sadegh Riazi, Christian Weinert, Oleksandr Tkachenko, Ebrahim M. Songhori, Thomas Schneider, and Farinaz Koushanfar.  Chameleon: A Hybrid Secure Computation Framework for Machine Learning Applications.  In _Proceedings of the 2018 on Asia Conference on Computer and Communications Security, AsiaCCS 2018, Incheon, Republic of Korea, June 04-08, 2018_ , pages 707–721, 2018.  doi: 10.1145/3196494.3196522.
  * Rufibach [2010] Kaspar Rufibach.  Use of brier score to assess binary predictions.  _Journal of clinical epidemiology_ , 63:938–9; author reply 939, 02 2010.  doi: 10.1016/j.jclinepi.2009.11.009.
  * Ryffel et al. [2020] Theo Ryffel, David Pointcheval, and Francis R. Bach.  ARIANN: low-interaction privacy-preserving deep learning via function secret sharing.  _CoRR_ , abs/2006.04593, 2020.  URL https://arxiv.org/abs/2006.04593.
  * Seah et al. [2021] Jarrel C Y Seah, Cyril H M Tang, Quinlan D Buchlak, Xavier G Holt, Jeffrey B Wardman, Anuar Aimoldin, Nazanin Esmaili, Hassan Ahmad, Hung Pham, John F Lambert, Ben Hachey, Stephen J F Hogg, Benjamin P Johnston, Christine Bennett, Luke Oakden-Rayner, Peter Brotchie, and Catherine M Jones.  Effect of a comprehensive deep-learning model on the accuracy of chest x-ray interpretation by radiologists: a retrospective, multireader multicase study.  _The Lancet Digital Health_ , 2021.  ISSN 2589-7500.  doi: https://doi.org/10.1016/S2589-7500(21)00106-0.
  * [39] SEAL.  Microsoft SEAL (release 3.6).  https://github.com/Microsoft/SEAL, November 2020.  Microsoft Research, Redmond, WA.
  * Shamir [1979] Adi Shamir.  How to share a secret.  _Commun. ACM_ , 22(11):612–613, 1979.  doi: 10.1145/359168.359176.  URL http://doi.acm.org/10.1145/359168.359176.
  * Wagh et al. [2019] Sameer Wagh, Divya Gupta, and Nishanth Chandran.  SecureNN: 3-Party Secure Computation for Neural Network Training.  _PoPETs_ , 2019(3):26–49, 2019.
  * Wang et al. [2017] Xiaosong Wang, Yifan Peng, Le Lu, Zhiyong Lu, Mohammadhadi Bagheri, and Ronald M. Summers.  Chestx-ray8: Hospital-scale chest x-ray database and benchmarks on weakly-supervised classification and localization of common thorax diseases.  _2017 IEEE Conference on Computer Vision and Pattern Recognition (CVPR)_ , Jul 2017.  doi: 10.1109/cvpr.2017.369.  URL http://dx.doi.org/10.1109/CVPR.2017.369.
  * Yao [1986] Andrew Chi-Chih Yao.  How to Generate and Exchange Secrets (Extended Abstract).  In _27th Annual Symposium on Foundations of Computer Science, Toronto, Canada, 27-29 October 1986_ , pages 162–167. IEEE Computer Society, 1986.  doi: 10.1109/SFCS.1986.25.

##  Appendix A Secure 2-party inference

In the problem of secure inference there are two parties, say a patient Bob
and a Vendor Alice. Alice has a pre-trained machine learning model $F$ whose
weights $w$ are sensitive and can’t be revealed to anyone else. Examples of
$F$ include ResNet50 on $224\times 224$ images, DenseNet121 on $320\times 320$
images, etc. Bob has a sensitive input $x$, e.g., a chest X-ray image, that
can’t be revealed to Alice. In secure inference, the goal is for Bob to learn
the output prediction of the model on his input $x$, i.e., $y=F(w,x)$.
Additionally, Alice should learn nothing about Bob’s image $x$, and Bob should
learn nothing about Alice’s weights $w$ beyond what can be deduced from $y$.
Note that here Alice and Bob trust no third party and are mutually distrustful
of each other. The problem defined here is that of 2-party secure inference
between Alice and Bob. Furthermore, $F$ need not be restricted to be an
inference algorithm and could even be a segmentation algorithm (see [28, 7]).

##  Appendix B Secure 2-party computation

A very simple example of a secure 2PC protocol now follows. Say, Alice has two
values $w=(w_{1},w_{2})$ and Bob has $x=(x_{1},x_{2})$ and
$F(w,x)=w_{1}x_{1}+w_{2}x_{2}$. Then, 2PC can be implemented using Homomorphic
encryption [13, 39] which allows one to compute functions over encrypted
values to obtain encrypted outputs. Encryption schemes supporting certain
specific functions (e.g. additions and multiplications) are practical today
and can be securely combined [34] with other cryptographic techniques in order
to obtain secure 2PC protocols for arbitrary functions.

First, Bob encrypts $(x_{1},x_{2})$ into $(E(x_{1}),E(x_{2}))$ and sends the
encryptions to Alice. Then, Alice computes
$e=w_{1}*_{E}E(x_{1})+_{E}w_{2}*_{E}E(x_{2})$ and returns $e$ to Bob. Bob then
decrypts $e$ to get $w_{1}x_{1}+w_{2}x_{2}$. It is easy to see that since
Alice only obtained encryptions of $x$, she doesn’t learn anything about $x$,
i.e., given $(E(x_{1}),E(x_{2}))$, she cannot guess any bit of $x$ (other than
guessing it at random). Note that the encrypted versions of $x_{1}$ and
$x_{2}$, that is, $(E(x_{1}),E(x_{2}))$, is of a larger size than
$(x_{1},x_{2})$ which imposes a communication overhead. Furthermore, the
homomorphic arithmetic operators $(*_{E},+_{E})$ are computationally more
expensive than addition and multiplication of unencrypted numbers and impose a
computational overhead. Hence, encrypted inference has a higher cost than
insecure inference.

##  Appendix C ML frameworks background

PyTorch [29] is an open-source machine learning (ML) framework based on the
Python programming language and the Torch library. PyTorch computes using
tensors that are accelerated by graphics processing units (GPU). Tensors are
arrays, multidimensional data structures that can be operated on and
manipulated with APIs.

ONNX (Open Neural Network Exchange) [4] is a format that helps with
interoperability in deep learning. There are production quality converters
that take ML models written in different formats and convert them to ONNX.

##  Appendix D Intermediary model conversions

We convert the DenseNet-121 used for our experiments using the in-built ONNX
converter from the Torch library. We verify the correctness of computation
graph conversion by also converting using a PyTorch to Keras to ONNX
methodology. Here, the model is first converted from PyTorch to Keras using
pytorch2keras. We then use this intermediary Keras model to get a Tensorflow
Graph which is in turn converted to ONNX using tensorflow-onnx.

##  Appendix E Model calibration and Brier scores

Brier scores are used to calculate a model’s accuracy of predictions, and give
them a score between 0 and 1. A score of 0 indicates that a model predicted
100% certainty for every disease class and got them all correct; a score of 1
reflects a model that predicts 100% certainty for every disease class but is
wrong in all the predictions [36]. Accordingly, we compute brier scores for
both, CrypTFlow2-secure and insecure inference on both our datasets. Tables 6
and 7 present the brier score metric. We find that for all diagnoses across
our multi-institutional test sets, the insecure and secure models are not only
both well-calibrated (the highest recorded brier score for any disease class
is less than 0.17) but also demonstrate matching calibration score values.
This provides yet another additional performance-based confirmation of
CrypTFlow2’s validity to AI-enabled medical imaging inference.

[H] Brier score insecure vs. secure on CheXpert test set Pathologies Brier
scores Insecure inference* Secure inference* No Finding* 0.081 0.081
Cardiomegaly* 0.168 0.168 Edema* 0.103 0.103 Consolidation* 0.061 0.061
Pleural Effusion* 0.01 0.01

  * •

*Scores rounded off to three decimal places

[H] Brier score insecure vs. secure on CARING500 test set Pathologies Brier
scores Insecure inference* Secure inference* Atelectasis* 0.088 0.088
Cardiomegaly* 0.086 0.086 Consolidation* 0.065 0.065 Pleural Effusion* 0.053
0.053

  * •

*Scores rounded off to three decimal places