Smart contracts, deployed on blockchains, can automate decision logic found in legal contracts, organizational rules, or guidelines such as clinical practice guidelines. High-level decision logic tends to be encoded by domain experts or knowledge engineers, using high-level domain formalisms such as Symboleo (legal contracts) or PROforma (clinical), or general-purpose rule-based formalisms such as Notation3 (N3) or SWRL. This initial work studies the translation of high-level decision logic related to clinical decision support, encoded by a Knowledge Graph (KG) with N3 rules and a domain ontology, into an imperative programming language. Currently, targets include Solidity for the Ethereum blockchain, and JavaScript for Hyperledger Fabric and Web-based deployments. Although many limitations must currently be placed on input KG, we believe this is a first step towards making clinical decision support logic within KG executable on blockchain and other platforms in order to improve healthcare delivery.
Blockchain technology is a secure, transparent, and decentralized solution. It is trustless in that the validation of transactions, such as financial transactions and execution of smart contracts, does not require placing trust in a single centralized provider. All transactions are further recorded into an immutable and tamper-proof ledger, allowing for trustworthy audits.
Smart contracts are blockchain programs for securely and transparently automating decision logic. Clients issue transactions with input data to execute smart contracts, with the assurance that (a) smart contract execution will not be not tampered with, since all transactions, including contract execution, are validated by a proven consensus mechanism; and (b) all transactions will be kept in an immutable log for auditing. A classic example includes legal contracts that automate decision logic pertaining to legal and financial interactions between parties [ 1]. Recently, researchers have been studying the deployment of clinical decision logic on blockchain [2]. At the same time, blockchain technology introduces latency that is unrelated to the decision logic, but rather the availability of nodes, consensus mechanism (e.g., proof-of-work or -stake), and other blockchain properties, such as the use of interactive zero knowledge proofs in preserving privacy. Hence, a use case should meet certain requirements to make it worthwhile to deploy on blockchain. We discuss these requirements, and our chosen clinical use case, in Section 2.
Decision logic found in legal contracts or clinical guidelines is typically encoded by domain experts or knowledge engineers, using a domain-specific, declarative formalism. Such formalisms include Symboleo (legal contracts) [3], PROforma [4] or GLEAN [5] (clinical guidelines), or more general-purpose rule-based formalisms. Manually coding smart contracts that implement the high-level decision logic, using an imperative blockchain language (e.g., Solidity), requires technical expertise that is typically beyond the purview of these stakeholders. Indeed, representing decision logic using imperative programming languages is far more involved: it requires determining the ordering of imperative commands, the impact of triggers on the internal state, and propagating state changes accordingly [6]. An alternative involves embedding a third-party engine within the smart contract to execute the particular formalism. For instance, Symboleo, PROForma, and GLEAN implementations are based on Finite State Machine (FSM) execution semantics: Rasti et al. [7] manually implemented the Symboleo formalism with its FSM in terms of base classes within smart contracts. These works are useful to support decision logic as per the particular domain, such as legal contracts. However, to support general-purpose decision logic, as found in Knowledge Graphs (KG), we found it unfeasible to deploy (rule-based) reasoners within smart contracts—we discuss this in Section 4. A third option involves the automated translation of high-level decision logic directly into the imperative blockchain programming language, obviating the need for third-party engines or manual coding.
This initial work studies a code generation approach that translates high-level decision logic, encoded by a Knowledge Graph (KG) with N3 rules [8] and a domain ontology, into imperative programming code. Currently, many restrictions must be placed on the input KG; however, we show that suficient expressivity is ofered to implement our running example. Our graph-based approach recursively traverses a KG to generate intermediate (bridge) abstractions in terms of Abstract Data Types (ADT) and imperative application logic. These bridge abstractions serve as the glue between (a) KG, which describes decision logic in a high-level declarative way (what); and (b) imperative programming languages, which list a series of commands to execute the decision logic (how). From these bridge abstractions, executable programs such as smart contracts can be generated in a target imperative language (currently, Solidity and JavaScript).
The National Institute of Standards and Technology (NIST) ofers a flowchart that determines the suitability of blockchain technology for a particular use case [9]. These requirements include the need for a shared dataset, with multiple entities contributing data; the need for an immutable and tamper-proof log of all transactions; and trust issues over who runs the dataset or smart contracts (i.e., need for a trustless setting)1. In line with these requirements, we present a public health use case, in particular, a diabetes risk screening policy, where regional healthcare organizations forward patient data to a region-wide platform to determine diabetes risk. To establish diabetes prevention and treatment programs, healthcare organizations receive funding based on these diabetes risk screenings, which consider modifiable risk factors (e.g., weight)
combined with non-modifiable factors (e.g., ethnicity). Diabetes prevention and treatment programs include incentives for patients to keep their BMI below 26, walking 150 minutes or more per week, or perform an equivalent exercise depending on their medical condition [10].
By using blockchain as a platform to deploy this screening policy, we gain the following benefits: (a) avoiding trust issues (trustless property): healthcare organizations may benefit from falsification or perceive falsification by others, but blockchain ensures that smart contract execution will not be tampered with; (b) trustworthy audit capabilities (immutable transaction ledger): audits of the diabetes screening event log, i.e., part of the ledger that keeps events emitted by the smart contract, will accurately reflect screening outcomes; audits of the transactions executing the smart contract will reflect all input patient data 2 provided by the organizations.
Our running example recommends diabetes screening based on risk factors including Body Mass Index (BMI) and ethnicity, taken from the American Diabetes Association’s 2022 Standards of Medical Care in Diabetes (Table 2.3 in [11]). We selected this straightforward use case as it meets the current restrictions of our code generation approach; it further involves easy-tounderstand decision logic that does not require domain expertise.
Example Case: Diabetes Screening. Testing should be considered in adults with overweight or obesity (BMI ≥ 25 kg/m2 or ≥ 23 kg/m2 in Asian Americans) who have one or more of the following risk factors: - High-risk race/ethnicity (e.g., African American, Latino, Native American, Asian American, Pacific Islander) [..]”
Intermediary abstractions are used to capture core data structures and imperative application logic. The high-level declarative decision logic found within KG will be translated into these ADT and application logic abstractions via a translation process described in Section 3.3.
Figure 1 shows the bridge abstractions used for Abstract Data Types (ADT).
A ModelADT instance represents a concrete ADT (e.g., Patient in Code 1) corresponding
to an ontology type, and consists of a set of ModelProperty fields (e.g., has_ethnicity). ModelConstants represent concrete instances and sub-types of the ontology type (e.g., Asian_American, Overweight). A separate type property will characterize an ADT instance using one of these constants (type property). The ADTModel keeps the set of generated ModelADTs.
For statically typed languages (e.g., Solidity), a ModelProperty keeps a ModelType that either represents an XSD datatype3 or an object type in the form of another ModelADT. Each of these ModelElements keeps as unique name a term URI found in the rule or ontology , and a human-readable label, if any.
Figure 2 shows the bridge abstractions used for imperative application logic.
The application logic is structured as a set of IfThen instances keeping an “if” Condition and a “then” Block that acts as a container of Statements. A Condition can be a Comparison between operands, or a set of conditions as a conjunction (AND) or disjunction4 (OR). An Assignment assigns an operand (e.g., literal) to another operand (e.g., variable). An Operand can be a Literal (e.g., string or number), Variable, or a PropertyPath. A PropertyPath starts from an operand (typically a variable) and keeps a sequence of ModelProperties to navigate through nested ModelADTs—examples are shown in Code 2, such as patient.hasPatientProfile.hasEthnicity . Finally, a CreateADT instance represents the invocation of a ModelADT constructor, possibly with a set of parameters represented as Assignments.
N3 is a semantic rule language that can be used to capture complex decision logic [8], supporting quoted graphs of statements, a range of built-ins, and (scoped) negation as failure. Rule 1 encodes our running example (diabetes screening) using N3 rules, with terms from the Diabetes Mellitus Treatment Ontology (DMTO) [12], an OWL 2 ontology for modeling type 2 diabetes treatment plans. DMTO extends the Diabetes Diagnosis Ontology (DDO) [13] with treatments and
4A very limited type of disjunction is supported based on the list:in builtin. integrates the Drug Target Ontology (DTO) [14]. In the code below, we replace alphanumeric identifiers (e.g., DMTO_0000021) with their human-readable labels for legibility.
Rules 1: Rules encoding the Example Case
Variables are indicated as ?x, and quoted graphs are indicated between braces “{ }”. A rule is expressed in terms of a statement with a quoted graph (rule body) as subject; the log:implies term (shorthand ⇒) as predicate; and another quoted graph (rule head) as object. Given a rule { body } ⇒ { head }, statements in head will be inferred in case statements in body evaluate to true. For existential rules (i.e., including a blank node in the rule head, indicated by “[ ]”), under existential instantiation, a new node will be created5. Since N3 rules are triple statements, the rule body (i.e., subject quoted graph) can be further described using extra triples to guide the translation process (e.g., lines 35-36): the cg:functionParam predicate indicates that ?patient will be passed as input data in the transaction executing the smart contract; cg:loadParam variables (not shown) will be loaded from memory or storage; and cg:event indicates the event to be emitted (RecommendDiabetesScreening) by the smart contract when all conditions are met.
5This is also in line with N3 semantics, where variables are first grounded to ensure referential opacity [15]
Figure 3 shows the Directed Acyclical Graph (DAG) corresponding to the first rule in Listing 1
(lines 2-13). Our graph-based approach will leverage this DAG to generate intermediary bridge
abstractions (Section 3.3). We point out that our approach currently places multiple restrictions
on N3 rules: (
In the first step, to structure the input data and subsequent application logic, we instantiate a set of ModelADTs based on the KG. In contrast to other work such as RDFReactor [16], which generates ADTs (Java classes) for an entire OWL ontology, our process is guided by the “needs” of the N3 rules, to increase readability and reduce the resulting program size 6. Below, we show the pseudocode for several of the ModelADT abstractions for our running example (Code 1).
To generate these ADT instances, our approach recursively traverses the extracted rule graph(s) (e.g., Figure 3) starting from their input parameter (e.g., patient). For any graph node, the domain ontology is consulted to establish its type, as indicated by property domains/ranges or its given type. E.g., node ?profile has object type PatientProfile , as that is the range of the has_patient_profile property. For each distinct ontology type, a new ModelADT will be instantiated; in our case, Patient, PatientProfile , PhysicalExamination, Ethnicity, and Demographic (latter two not shown). Subsequently, for each node’s outgoing edges 7 within the rule, a new ModelProperty is added to its ModelADT. E.g., for PatientProfile , properties hasPhysicalExam
7Not including rdf:type or an N3 builtin.
Code 1: ADT Pseudocode For Example Case 1 ADT : 2 hasPatientProfile: PatientProfile 3 ADT : 4 hasPhysicalExamination [0..*]: PhysicalExamination 5 hasEthnicity [0..1]: Ethnicity 6 hasDemographic [0..*]: Demographic 7 ADT : 8 type [0..1] 9 hasQuantitativeValue [0..1]: double 10 constant BMI ination, hasEthnicity, and hasDemographic are added. The cardinality of the ModelProperty is based on the OWL maximum cardinality constraint [17] and functional property type of the edge. The property’s ModelType is based on edge’s target node, i.e., either its associated ModelADT or XSD datatype (in case of a datatype value). E.g., the hasPatientProfile property has ModelType PatientProfile , whereas hasQuantitativeValue has ModelType xsd:double. URI terms, and types indicated with rdf:type edges, are added as ModelConstants: e.g., the URI AsianAmerican and type BMI will be added as constants to the Ethnicity (not shown) and PhysicalExamination ADTs, respectively. The ModelADT can then be characterized using any of these constants, using the special ‘type’ ModelProperty (as illustrated in Code 2).
Secondly, we generate a set of Statements that represent the declarative decision logic as imperative application logic, referencing the ModelADT elements instantiated above. Code 2 shows the pseudocode of the Statement instances for our first rule.
Code 2: Imperative Logic Pseudocode For Example Case 1 1 if patient.hasPatientProfile.hasEthnicity.type == Ethnicity.AsianAmerican 2 and patient.hasPatientProfile.hasPhysicalExamination.type == 3 PhysicalExamination.BMI 4 and patient.hasPatientProfile.hasPhysicalExamination.hasQuantitativeValue 5 ≥ 23 then 6 v1 ← create PatientDemographic(type: 7 PatientDemographic.Overweight) 8 patient.hasPatientProfile.hasDemographic ∪← v1
Similar to before, our approach recursively traverses the rule graph(s). Each rule graph is
expected to be structured as a set of “property paths”, i.e., sequences of variables connected
by concrete predicates, ending at a concrete URI or literal term. These are represented using
PropertyPath. E.g., the property path starting at ?patient and ending at AsianAmerican will be
represented using patient.hasPatientProfile.hasEthnicity (line 1), utilizing the ModelProperties
constructed before. In case the concrete term is a URI, we further append the ‘type’ property
to the property path. In case the final edge (e.g., hasEthnicity) was found in the rule body,
meaning it is part of the condition, we will instantiate a Comparison. The comparison’s two
Operands will include (
From the instantiated bridge abstractions, concrete programming code can be generated in diferent imperative languages; currently, Solidity and JavaScript are supported.
Here, we describe noteworthy aspects on the limitations of blockchain languages, how they informed our choice for a code generation approach, and how they complicate the process.
Idelberger et al. [6] outline an important technical challenge for logical reasoning on blockchain: aside from computational eficiency, algorithms also have to be cheap, measured as per the economic rules of the blockchain. Each transaction, such as smart contract execution, will require the expenditure of the blockchain’s cryptocurrency: on Ethereum, computational work invoked by a transaction costs ‘gas’, i.e., a certain amount of cryptocurrency, and transactions are reverted once the ‘gas limit’8 is reached. Loops and large arrays are thus highly discouraged as they run the risk of hitting unexpected Out-Of-Gas Exceptions (each iteration may consume a diferent amount of gas). Rule-based reasoners tend to rely heavily on loops—to iterate over newly generated triples and match them to rule bodies (forward-chaining), or trying alternative choice points to resolve a statement (backward-chaining). In practice, we found this makes it unfeasible to deploy rule-based reasoners directly within smart contracts.
An additional limitation of Solidity, likely informed by the need to avoid large gas costs, is that elements can only be inserted or removed at the end of arrays, making them unsuitable for large sets of elements. At the same time, the alternative use of mapping constructs is complicated by the fact that a struct (ADT) cannot keep a reference to another struct that keeps a mapping. Currently, to circumvent this nesting limitation, we recursively merge the properties of all nested structs with mappings (e.g., PatientProfile) into the ‘root’ struct (e.g., Patient), and update property paths from the application logic correspondingly.
In 2016, Idelberger et al. [6] reported that logic-based languages have hardly been explored to implement smart contracts—to the best of our knowledge, this has not changed much since then. Choudhury et al. [18] automatically instantiates placeholders in manually, a-priori authored “smart contract templates”, using values found in SWRL rules. The authors expect that the involved criteria and ADTs will be common within particular domains, such as clinical trial eligibility. Instead, we target the deployment of general-purpose decision logic, which may vary greatly case-per-case. Alternatively, rule-based reasoning could simply be deployed of-chain using oracles: in this case, the smart contract emits events (e.g., data), to which an external (of-chain) oracle responds with a set of inferences. However, this requires an extra transaction which requires validation (and thus cryptocurrency) and setting up a secure and scalable oracle.
Our ultimate goal involves deploying the declarative decision logic within KG on blockchain. We described work towards a graph-based approach to generate imperative code based on KG with N3 rules and a domain ontology. Our approach is centered on instantiating bridge abstractions that capture the core ADTs and application logic within KG; from these abstractions, code can be generated in diferent imperative languages. The code generation tool is available online together with multiple generated smart contracts at this GitHub repository9.
As mentioned, there are many constraints on the currently supported N3 rules; a major avenue of future work involves increasing the expressivity of our approach. Importantly, we will explore the diferent types of clinical reasoning that are addressable by our approach from a clinical practice perspective. We will perform a comprehensive evaluation of our approach on an Ethereum testnet to (a) check consistency, by comparing recommendations from generated smart contracts and the source KG; and (b) ascertain scalability, by measuring the execution times of the generated smart contracts. The use of a testnet for evaluation, as a type of side-chain, is in line with the likely deployment target of smart contracts in healthcare. The “mainnet” is the public blockchain where public cryptocurrency and transactions take place; a side-chain operates independently and can verify transactions at a much lower latency. A side-chain between hospital nodes can further be made private to add an extra layer of security.