4.1 Policy context

The central part in defining many healthcare policies is the specification of constraints on the actions of the parties who participate in interactions defined by some legislative, jurisdictional or regulative context. This is an important for providing legal clarity as to the situs of interactions, that is, applicable laws to apply to resources, data or interactions under question. For example, under various legal regimes, it is necessary to identify the location of an asset or contract to determine the applicable legal jurisdiction for various legal questions relating to it (ISDA Linklaters, 2017).

Policy context specifies rules that can identify the applicable jurisdictions or organizational policies, all of which govern interactions of the parties. There is thus a need to model wide range of healthcare policy contexts and for that purpose the precise semantics of the RM-ODP concept of community can be used to describe the organizational or social environment for the participants as introduced next.

4.2 Deontic constraints

There are three fundamental types of policy constraints that reflect rules of any normative system, namely obligations, prohibitions and permissions. Their formal expression is the subject of deontic logic and these are often referred to as deontic constraints.

An obligation is a prescription that a particular behaviour is required. An obligation is fulfilled by the occurrence of the prescribed behaviour.

A permission is a prescription that a particular behaviour is allowed to occur. A permission is equivalent to there being no obligation for the behaviour not to occur.

A prohibition is a prescription that a particular behaviour must not occur. A prohibition is equivalent to there being an obligation for the behaviour not to occur.

The above definitions have been the subject of standard deontic logic, but their application in the realm of enterprise distributed computing requires explicit association with the agent to which these constraints apply. This is also needed to take into account an agent’s goal-seeking behaviour, which may result in their willingness to violate the policies with the expected benefit of reward from doing so. This violation and the need to develop a broader view of enterprise behaviour was identified in (Linington, Reference Linington, Milosevic and Raymond1998). These developments resulted in a revised version of the ODP-EL standard that provides a pragmatic way of specifying deontic constraints for the purpose of building enterprise distributed systems, as described next.

The way that deontic constraints are associated with the agents (i.e. active enterprise objects in ODP speak) is through the concept of deontic tokens. These are enterprise objects which encapsulate deontic constraint assertions. The holding of the deontic tokens by active enterprise objects constrains their behaviour. This modelling approach provides a basis for manipulating deontic tokens, for example, passing them between parties to model delegations, and activation or de-activation of policies that apply to the active enterprise objects in the context of their enterprise interactions. There are three types of deontic tokens that represent deontic constraints. These are called burden, representing an obligation, permit, representing permission and embargo, and representing prohibition.

In the case of a burden, an active enterprise object holding the burden must attempt to discharge it either directly by performing the specified behaviour or indirectly by engaging some other object to take possession of the burden and perform the specified behaviour. In the case of permit, an active enterprise object holding the permit is able to perform some specified piece of behaviour, while in the case of embargo, the object holding the embargo is inhibited from performing the behaviour.

In order to support the dynamics of deontic tokens, the concept of a speech act is further introduced. This is a special kind of action that is used to modify the set of tokens held by an active enterprise object. The name was chosen by analogy to the linguistic concept of speech act, which refers to something expressed by an individual that not only presents information but performs an action as well. Thus, a speech act changes the state of the world in terms of the association of deontic tokens with active enterprise objects, such as patient giving permit to a researcher to access their health record. Further, this modelling feature fits well with the nature of AI-enabled digital health applications. It allows the specification of actions that can be performed by both people and AI systems, as will be elaborated in Section 5.4.

In fact, deontic constraints and tokens provide foundations for expressing many types of policy constraints across enterprise objects in a system, including both human actors and automated agents, such as AI systems. ODP-EL provides added formalism to express traceability of obligations of parties, according to their broader responsibilities derived from ethical, social or legal norms. This formalism is referred to as accountability concepts, as described next.

4.3 Accountability concepts

The first concept from the set of ODP-EL accountability concepts is that of party, introduced informally earlier. Party is defined as an enterprise object which models a natural person or any other entity considered to have some of the rights, powers and duties of natural person, for example, company. ODP-EL introduces two other concepts which are useful to describe many forms of delegation in enterprise systems. Principal is defined as a party that has delegated something (e.g. authorization or provision of service) to another, and Agent is defined as an active enterprise object that has been delegated something (e.g. authorization, responsibility of provision of service) by, and acts for, a party (e.g. in exercising the authorization, carrying out responsibility).

Delegation is an action that assigns something (e.g. authorization, responsibility of provision of service) to another object. It is through this mechanism that deontic tokens can be passed across different active enterprise objects, with one example being a delegation from principal to agent, as mentioned above. Delegation is one action type in ODP-EL related to accountability, but there are several other action types to capture important business events in any organizational system, and reflect the dynamics of communication amongst parties, and broadly, active enterprise objects. These action types are listed next (ISO ODP-EL, 2015).

Commitment is defined as an action resulting in an obligation by one or more participants in the act to comply with a rule or perform a contract. This effectively means that they will be assigned a burden. Examples include commitments by clinicians to deliver safe, reliable and effective healthcare to patients.

Declaration is defined as an action by which an object makes facts known in its environment and establishes a new state of affairs in its environment. This can, for example, be performed by an AI system (or a party managing it), for example, informing the interested parties about the result of some analysis.

Evaluation is defined as an action that assesses the value of something. Value can be considered in terms of various variables such as importance, preference, usefulness. In digital health, variables can be performance parameters used, through research applications for example, to either express administrative performance or some accuracy or reliability measures. They can be used to assess the fairness of training data or as part of mechanisms to measure the impact of AI algorithms as part of their explainability requirements.

Prescription is defined as an action that establishes a rule. Prescriptions provide a flexible and powerful mechanism for changing the system’s business rules at runtime, enabling dynamic adaptation to respond to business changes and new needs. This ability is important in any digital health system, to establish the applicability of new policies reflecting new legislations for example, or after the adoption of recommendations from AI system components.

Authorization is defined as an action indicating that a particular behaviour shall not be prevented. Unlike a permission, an authorization is an empowerment. In terms of deontic tokens, the enterprise object that has performed authorization will issue a required permit and will itself undertake a burden describing its obligation to facilitate the behaviour. For example, the authorization for the consumer to challenge AI decisions is giving them permit to do so by the AI system (or its creator/manager) who has the burden to do so.

4.4 Implications for smart contracts: legal extensions

The community, deontic and accountability constraints provide the foundation for expressing many legal aspects that characterize various legal instruments, including organizational, regulative or legislative policies. Considering that current smart contract proposals are a form of a basic behaviour, specifying a sequence of events or state changes that reflect agreements between parties (Hyperledger, 2019; Solidity, 2019), deontic and accountability constraints can be superimposed on smart contracts to support legal expressions (Berry & Milosevic, Reference Berry and Milosevic2005). We refer to such augmented smart contracts as smart legal contracts, as introduced in Section 1.

We note however that, although smart legal contracts provide an increasing level of support for legal expressions to be automated and enforced through computer code, the ultimate legal enforcement will require decisions by legal structures. For this reason, a link to the legal prose is likely to be required in foreseeable future, in particular for complex contracts, which is the approach also currently adopted by Corda DLT (Brown et al., Reference Brown, J., Grigg and Hearn2016).

5.1 Privacy consent community: stakeholders

Privacy consent is essentially a pattern applicable to many situations and can be formalized as a consent community template. When instantiated, the template can be parameterized with specific variables related to the situation, for example, the specific purpose for which consent was given. This community template specifies the following community role types (see Figure 2):

Figure 2 Privacy consent community example

• Grantor, to be fulfilled by any individual giving a consent; an individual is a party that models a person giving consent under a set of permission rules, such as being of legal age. There may be a constraint on a number of role instances that satisfy this role type, because at most one enterprise object can fulfil a community role instance at a point in time.

• Grantee, which can be of either a clinician or researcher role type, expected to be fulfilled by professionals with the required credentials, namely:

  • – Clinician, who has permission to access grantors individual health information for care purposes, covered by the patients consent for primary use, for example, covering access to all of the patient information in an emergency situation, with the associated constraints, such as certain time interval from the emergency event.

  • – Researcher, who has permission to access grantors de-identified health information for research purposes; researcher is obliged not to try to re-identify data about patient, as for example may be prescribed through the rules of a National Data Protection Authority; this is however hard to enforce unless all data in/out of their research are monitored, which is difficult to do when a researcher can access third-party data, so some monitoring mechanism may be required, such as tracking of actions of the researcher.

• Consent Authority as a trusted party responsible for storing individuals’ consent agreements and overseeing the consent agreement rules; a trusted authority can be established by government and operated as a government entity to increase customers’ trust in using their information for research purposes, as per their preferences; its function can also be to facilitate ethics approvals to govern the secondary use of data.

• Research Broker, a commercial entity authorized to search patient health information and consent data to identify patients suitable for research projects. The Broker might also be responsible for validating/verifying ethics approvals for research projects. The Broker is responsible to ensure that consumer preferences are enforced; thus it is accountable to the Consent Authority, and ultimately to the National Data Protection Authority, represented as a controlling object in this community (in fact, a Domain community, see Section 4).

• National Data Protection Authority, which is responsible for defining and enforcing data protection policies, as legislated.

• Automated Decision-Maker, performing analytics, recommendations and in some cases, active decision-making; this role guides and augments activities of clinicians, researchers and other stakeholders, such as population health experts; this role can be fulfilled by active enterprise objects, typically clinical decision support systems or AI systems.

• Audit Tracker, which logs events associated with actions of both clinicians and researchers, in support of building audit trails; this is to enable subsequent analysis of activities, including detecting breaches such as of clinicians accessing healthcare records outside of them providing care, or researchers accessing linked data provided by third parties; both of these are forbidden; in some cases breach detection can be implemented in real time, by a separate role of a monitor as we have used extensively in the context of business contracts monitoring (Linington et al., Reference Linington, Milosevic, Cole, Gibson, Kulkarni and Neal2004; Berry & Milosevic, Reference Berry and Milosevic2005).

• Auditor, which provides analysis of event traces to support activities such as performance analysis or forensic investigations, to detect breaches and their consequences; this is needed because, in spite of the implemented preventative mechanisms, breaches can happen and these need to be detected, as part of applying subsequent enforcement measures; note that the enforcer role was not included in this community model for simplicity.

• Electronic Health Record (EHR) provider, who is custodian of individuals’ personal health data in their EHR records.

Note that the privacy consent community should specify, as part of its objective, the purpose for which the grantor will give consent (see Figure 2), such as cancer research support. We believe that a well-defined ontology capturing different purpose for consent directive may support individuals in better transparency and trust in how their personal data are handled and enforced.

5.2 Privacy consent community: process scenario

There are many interactions and processes in this community, and we use the following scenario to illustrate key enterprise interactions and deontic and accountability concepts. The following are normal sequences of activities involved from the time an individual gives consent to the point their data are used by researchers to inform and contribute to the new medical treatments.

1. 1. Grantor updates their consent directive at the Consent Authority to indicate that they are willing to disclose de-identified genomic data for cancer research, as part of their individually identifiable health data, but excluding data related to mental health. This requirement is in line with the recent GDPR directions to better support personalized and fine-grained controls over access to individual information.

2. 2. Grantor permits matching on their de-identified health data by a Research Broker, allowing the Broker to discover accessible patient data for research matching purposes. Essentially, this is permission for the Research Broker to search the data and consent directives of patients and retrieve identifiers for patients whose consent matches the research requirements. It does not give them access to the health data, just search and retrieve identifiers.

3. 3. Researcher, on some event for example, award of grant funding, would like to access health records of all patients who have consented to participate in cancer research. To this end, they contact the Research Broker stating that they are interested in conducting this research across all patients who have given consent for cancer research; this includes access to their medications, treatment and genomic information; the researcher also provides evidence of ethical and clinical approvals for the research.

4. 4. Research Broker provides a de-identified list of eligible patients to the researcher and an authorization for them to access de-identified patient data from the EHR provider, but highlights the potential exclusion of medication data related to mental health treatment. The authorization requires the researcher to maintain an audit trail of all access to the data (i.e. obligation). Note that the list might be encrypted using the public key of the EHR provider, meaning that the researcher cannot access patient identifiers.

5. 5. Researcher retrieves de-identified patient data from the EHR provider, as per the authorization supplied by the Research Broker. The EHR provider filters the data as required to comply with individual patient consent directives and lodges an audit record relating to the released data with the Auditor.

   Note that the EHR provider will usually be prohibited by law from releasing patient data without consent, except when a clinician is providing care for the patient in an emergency setting. As such, the Broker cannot be responsible for retrieving/releasing the data unless the Broker is an agent for the EHR provider, appointed under agreed indemnity conditions. The EHR provider would still be subject to reasonable care provisions in their choice of a Broker.

6. 6. Researcher accesses the EHR data to support their research, lodging an audit record for each access with the Audit Tracker. This includes access by an AI system in the role of Automated Decision-Maker, as an agent acting on behalf of the researcher using the authorization from the researcher (e.g. a research permit token).

7. 7. Researcher publishes the result of the research and informs all relevant parties.

8. 8. At a later point, there is a suspicion by a patient that some of their mental health data were used by a health insurer and patient then contacts the Consent Authority to lodge a complaint.

9. 9. Consent Authority then engages Auditor who accesses audit trail produced by the audit tracking system to perform forensic investigation of patients data access by Grantees. Upon detection of specific violation, it notifies an enforcer role to apply penalty to either of the parties. Note that this role is not depicted in the diagram, and it can be fulfilled by a separate community, that is, enforcer community, with a number of constituent roles, including court. Further details about various roles in this community can be found in our earlier work (Dimitrakos et al., Reference Dimitrakos, Djordjevic, Milosevic, Josang and Phillips2003).

The above is a normal sequence of activities, in which each participant acts according to the expected behaviour but the privacy protection mechanisms need to be established to cover a range of possible breaches that can be envisioned at design time, that could include:

1. 1. Broker incorrectly identifies the nature of the research, leading to inappropriate release of information.

2. 2. EHR provider failed to apply access controls correctly, in spite of Research Broker correct implementation of consent preferences in the access token.

3. 3. Broker does not adequately vet the research approvals, leading to inappropriate release of information for example to an insurance company.

5.3 Privacy consent community: deontic constrains

The privacy consent community defines a number of deontic constraints that apply to the active enterprise objects, including:

• Permission of the Grantor given to the Consent Authority to store consent agreements, for example, valid for a specified time period defined by the Grantor.

• Permission of the Grantor to the Broker to search patients data and if it satisfies researcher criteria include a link to this data in a data set for the researcher.

• Obligation on the Audit Tracker to log data access by the Grantee reliably and on-time and provide access to the audit trail by the Auditor; the tracker may also have an obligation to log actions of Research Broker which may be needed for forensic purpose.

• Authorization of the Grantor to the Grantee to access the Grantor’s individual health information; this is realized through this chain of authorization:

  • – Grantor issues permit to the Research Broker for searching their data to establish whether they satisfy research question criteria.

  • – Research Broker issues a research permit to the researcher which includes a list of Grantors that provided consent to access their de-identified health data and whose data satisfy the research question.

  • – EHR provider provides access permit to the researcher to access health records of specific patients, provided researcher satisfies KYC condition, that is, it has credentials requested by the EHR provider; the possession of such permit is an example of ODP conditional action that applies to the researcher.

• Authorization of the researcher to the Automated Decision-Maker to perform necessary calculations on personal health data, after obtaining authorization by the Research Broker; this may be machine learning over a set of medications to predict its impact in terms of the percentage of patients with full recovery within certain time period that can be considered by Clinician, as an ultimate, legally accountable decision-maker.

5.4 Privacy consent community: accountability concepts

The machinery of deontic tokens can be exploited to define, implement, monitor and enforce various policy aspects associated with managing consent. As noted in Section 4.3, authorization is modelled using a combination of permit and burden deontic tokens. For example, authorization of the Grantor to the Broker involves both the permit being passed from the Grantor to the Broker to search its record but also places an obligation on the Grantor itself, through the corresponding burden, to ensure that access to its record is ultimately enabled.

This authorization action is also a speech act because it changes the deontic state of both the grantor and grantee. The effect of this speech act is that the existing grantor’s permit to the Broker to search its healthcare data is passed on to the grantee, as shown in Figure 3. In this example, we assume that the consent directive gives permission to the researcher to access the Grantors health data but prohibits access to the Grantor’s mental health data (if it exists). The use of speech acts and deontic tokens is a convenient means for describing the dynamics of deontic constraints and passing of tokens, including to the parties with ultimate legal responsibility.

Figure 3 Deontic token manipulation – the dynamics of authorization

Many data protection rules defined by a National Data Protection Authority set accountability and legal responsibility expectations for actions of researchers involved in using grantor’s data. These data protection rules were established through prescription actions (see Section 4.3), performed by the National Data Protection Authority, which essentially establishes obligations and permissions for all the parties involved in accessing patient data.

Further, one needs to precisely specify the distinction between actions of autonomous decision-makers (e.g. Clinical Decision Systems and AI systems) and carers, because typically the latter can be legally responsible in a particular jurisdictionFootnote 2. This distinction is shown in the example (see Figure 2) whereby the researcher acting as a principal can be thought of as ‘delegating’ machine learning activities to an AI system as an agent in this relationshipFootnote 3. Note that researchers have their own responsibility to the National Data Protection Authority, to comply with general data protection principles.

6.1 Example 1: privacy consent policy

Privacy consent policy would thus look like:

〈ConsentContext〉 〈consentCreation〉 〈grantor〉 〈permission〉 〈accesPatientInfo〉 〈grantee〉 〈violation〉

In the above, accessPatentInfo specifies an event pattern, such as the period for which the consent was given and its purpose, for example, access to a specific IT or physical resource (not included in the policy expression for simplicity). This general consent statement can be instantiated for a specific consent policy instance. Consider a simple example for a personally controlled EHR:

‘A consumer Bob grants permission to an emergency clinician to access his EHR record, in case of emergency.’

‘〈EDcare〉 〈emergencyPresentation〉 〈Bob〉 〈permission〉 〈accesEHRRecord〉 〈accreditedEmergencyClinician〉 〈〉

This policy is activated by emergencyPresentation event, selected from a set of possible triggering events that can be defined at an organizational, state or national level, possibly as part of a personal health record. The policy assumes the existence of patient identifier framework, for example, Individual Health Identifier in Australia, which would identify the patient Bob in this case.

6.2 Example 2: advance care directive

Another example is advance care directive policy that authorizes a substitute decision-maker, that is, a person permitted under the law to make decisions on behalf of someone who does not have capacity, namely:

〈AdvancedCareContext〉 〈AdvancedCareDirectiveCreation〉 〈Grantor〉 〈authorize〉 〈MedicalDecision〉 〈SubstituteDecisionMaker〉

〈Legislation〉 〈obligation〉 〈Grantor〉 〈actResponsibly〉 〈violationCondition〉

The example illustrates the use of a care policy and include authorization for the Grantee to make a medical decision for the Grantor. The example also illustrates one obligation that applies to the Grantor, as defined by the other community referred to as Legislation, as well as a number of violation conditions, that may either activate some other policies or generate alarms that may involve human decision-makers, with potential escalations actions.

6.3 Example 3: research consent directive

This example is applicable in cases where an individual wishes to give permission to a research organization to access their data, typically de-identified, for specific research purposes. This is one of the number of policies that was discussed in more in detail in Section 5.

〈ReserachConsentContext〉 〈ResearchConsentDirectiveCreation〉 〈Patient〉 〈authorize〉 〈usePatientData〉 〈ResearchOrg〉

〈ResearchOrg〉 〈obligation〉 〈payForDataAccess〉 〈Patient〉 〈violationConditions〉

For simplicity, we do not specify the purpose element of the policy expression but we note that audit trails can be used to infer the purpose based on the trace of events.

7.1 Business Contract Language (BCL)

BCL semantics (Linington et al., Reference Linington, Milosevic, Cole, Gibson, Kulkarni and Neal2004) is based on the formally defined concepts from the RM-ODP standard, particularly the ODP-EL concepts, introduced in Section 4 and thus it has a similar style of expression as abstract policy language, due to their common ODP underpinnings. BCL includes the concept of community template, serving as a context for the definition of roles, which specify expected behaviour of parties, including the applicable deontic constraints. BCL uses event patterns to specify triggering, behavioural and violation conditions for the policy languageFootnote 4. BCL supports the concept of state, defining the data of relevance for the contract and which may be required to evaluate policies. BCL back-end components are implemented in Java and use contemporary software to implement interfaces, including Web-based technologies.

BCL has been formally analyzed in terms of its deontic logic foundations and this led to the development of the FCL (Governatori & Milosevic, Reference Governatori and Milosevic2005). In FCL, a legal contract is expressed in terms of deontic modalities such as obligations, permissions and prohibitions, with additional support for the expression of and reasoning about violations of such deontic modalities and the subsequent actions that need to be taken to deal with violations. FCL has a well-developed mapping to BCL and it continues to serve as a logic-based counterpart to BCL, which can be used to detect inconsistencies in contracts such as contract gaps or duplicate statements.

7.2 Contract Specification Language (CSL)

Another candidate for mapping of the abstract policy language is CSL (Andersen et al., Reference Andersen, Elsborg, F., Simonsen and Stefansen2006), a functional language for specifying contracts in terms of event composition, where events can be specified sequentially or concurrently, in similar manner as with BCL event patterns mentioned in Section 7.1. Formally, in CSL, a contract denotes a set of traces of events, each of which is an alternative way of concluding the contract successfully, in a style similar to communicating sequential processes denotational semantics (Andersen et al., Reference Andersen, Elsborg, F., Simonsen and Stefansen2006). Further, its denotational semantics provided input into the development of operational semantics, where a contract is executed by interpreting events that arrive to the observer, and if matched, process them, followed by the similar analysis for the remaining events, which are regarded as remaining contractual commitments, or residual contract.

CSL does not have explicit language support for expressing deontic constraints, but can be extended, as per our analysis carried out with Deon, Digital, a Swiss company further developing CSL as a contract language agnostic of any DLT. We believe that it is of particular value that CSL provides DLT adapters for R3 Corda and IBM Hyperledger DLTs, so that it can be used as a smart contract language for those two DLTs (Deon Digital, 2019).

7.3 Corda distributed ledger option

The consent community model (see Section 5) introduced a number of peer-to-peer enterprise interactions between individual entities involved in different steps of the scenario. The first step, for example, involves a patient (in Grantor role) and Consent Authority, which manages consent directives of patients. One of the requirements in any instance of the consent community is to ensure privacy and non-repudiation of this interaction, so that only these two peers can share information about this particular transaction and have consistent view about it. In addition, the consent directive can be updated and removed from the consent directory, and again, it is only these two parties that can verify to this fact. Further, there is a requirement to record history of consent updates, thus producing an audit trail of these changes that may need to be accessed by a third-party Auditor role. Similarly, many of the other enterprise interactions in the scenario and the data involved have the requirements of privacy and consistent view on the shared data involved in their interactions. In addition, each of the pairwise interactions between parties forms a step in a larger process in the community that describes the overall scenario.

Much of this functionality can be supported using the concepts of Corda DLT (Brown et al., Reference Brown, J., Grigg and Hearn2016). Corda is a DLT initially developed for the needs of finance industry to facilitate collaboration between potentially distrusting parties while supporting them to maintain consensus about shared facts associated with their interactions. Corda is a permissioned DLT, whereby parties join the Corda network, after their identity is checked (KYC principle), similar like the checks needed for an enterprise object to join a community role. Corda supports direct, secure (TLS encrypted), communication between parties on a peer-to-peer basis, as opposed to the gossip style of consensus adopted by Bitcon or Etherium. This allows communication on a ‘need to know’ basis, so while the patient need to communicate for example with the Consent Authority or clinician, they do not need to communicate with researcher or Auditor.

The consensus in Corda is achieved by both parties in the interaction verifying state updates, where state captures a shared fact of interest for the parties, for example, update of consent directive. This verification involves first the evaluation of a contract which specifies valid business transitions between states, after which both parties need to digitally sign the new state, making old state part of the chain of state history. This mechanism ensures consensus between the parties but also ensures non-repudiation, provenance and immutability of records and thus facilitates subsequent audit trail as required.

Finally, Corda supports definition of process style of behaviour through the concept of flow. In fact, the flow, contract and states represent elements for building a business logic or interactions between parties, and these are combined into CorDaps (Corda Distributed Applications).

In Corda network, each Corda Node runs Corda software plus CorDapps, which are used by parties that host Corda nodes.

These Corda components can provide good foundations for overlaying the features of ODP concept of community in general, especially when a community needs to support secure and private communications between parties while ensuring their consensus as a way of increasing trust within the community. This is indeed the case with the consent community and the following points illustrate how Corda could be used to implement elements of the consent community.

• Each of the parties in the community can deploy its own Corda node, forming together a Corda network, with a party representing a patient being able to access the network via appropriate CorDapps UI, perhaps offered by an agent who is part of Corda network.

• Corda flow can be used to specify distributed choreography that implements interactions between parties in each of the steps in our scenario and communicates through passing messages between the nodes.

• Corda states can be used to describe shared facts between the parties concerned about data involved in enterprise interactions. Examples are (a) consent directive between the grantor and Consent Authority, (b) EHR record entries (c) EHR individual attributes when the focus is on specific data to be access within EHR record and (d) states associated with deontic token life cycle. In the last case, the states associated with deontic tokens (i.e. deontic facts) capture shared views about mutual obligations, permissions or prohibitions between counterparts in the interactions, and their evolution in response to speech acts.

• The use of Corda contract can be used to verify the state transitions between key parties involved. This verification can apply to both basic behaviour and also deontic behaviour. Examples of the former are update of healthcare data of an individual, such as performed by the clinician. Examples of the latter are transitions from a state modelling an existing obligation to a state modelling the same discharged obligation, further characterized by a specified Corda time windrow.

• Corda transactions, implementing atomic updates of the contained states, can be used to ensure immutable audit trails, such as needed for the role of data tracker in the community.

The use of Corda platform effectively ensures embedding both of the monitoring and enforcement options, which was one of the options described in more in detail in Berry & Milosevic (Reference Berry and Milosevic2005).

7.4 Considerations for use

The use of smart legal contracts and DLTs can enhance the privacy, reliability and trustworthiness of digital health solutions, but their complexity and cost require a decision framework for managers, architects and developers to identify circumstances in which benefits outweigh costs. A good starting point is National Institute of Standards and Technology (NIST) guidelines for determining whether a DLT might be valuable for a development initiative (Yaga et al., 2019) as opposed to database solutions. Many of these guidelines would be useful for healthcare but with relaxed constraints related to trust. This is because in healthcare there are trusted institutions like hospitals or national bodies who can be relied on to verify the integrity of ledgers. This would mitigate the cost of the establishment and maintenance of trusted blockchain infrastructure, including some of the wastefulness of blockchain consensus mechanisms such as proof-of-work mining. We note that the recently established DeepMind verifiable Data Audit project (DeepMind, 2018) is aimed in further improving trust and they are developing their own ledger for data audit.

NIST guidelines are often used in the context of supporting immutable and tamper-proof storage of data. We believe however that there is value in additional guidelines for the use of smart contracts and support for enactment of certain processes in healthcare. The existing efforts to map traditional process languages onto smart contracts can be a useful starting point (Lòpez-Pintado et al., Reference Lòpez-Pintado, Garcia-Bañuelos, Dumas, Weber and Ponomarev2018). This is relevant for those healthcare processes that can be standardized while supporting variability for personalization purposes. Early candidates are financial and supply chain processes, followed by referrals, discharges and care plans.

In doing so however, one needs to carefully consider the impact of non-digital transactions as they prevail in healthcare. In such cases, smart contracts are limited in their ability to control or monitor non-digital transactions. Rather, they can capture a trusted, immutable record of execution, if the transaction is subsequently recorded digitally. This applies to human-initiated actions, but even for a sensor reading, for example, the reading has already occurred and the ledger can only record the occurrence afterwards. A real-time monitoring system cannot wait for consensus before delivering an alert. In fact, there are many situations where a traditional smart contracts approach might not be necessary and can be replaced with process definitions.

In addition, many applications would benefit from guidelines for translating legal contracts into compliant processes (Milosevic et al., Reference Milosevic, Sadiq and Orlowska2006), because current process languages do not support expression of legal constraints over the activities in a process. Our earlier work provides many contributions in this respect (Berry & Milosevic, Reference Berry and Milosevic2005).