# Technical Explanation

**Participants Definitions and Permissions**

With a plethora of different actors, identity management and access to data is key to HealthLink’s solution. A dynamic system has been developed that identifies actors and gives them the appropriate scope over a health record, contingent on the patient’s permission. Below are some examples of read/write permission:

**Table: Read / Write Permission**

<figure><img src="/files/p2Zei6IRHaNiZIxZZwhW" alt=""><figcaption></figcaption></figure>

**Encryption Cryptography**

To ensure privacy, health records are encrypted using symmetric key cryptography. The record will be encrypted and stored in a data store within the appropriate regulatory jurisdiction. The symmetric key will be encrypted with the public key of a 2048-bit RSA key pair. Each time an entity is given permission to access the patient’s record:

1. The record is decrypted with the owner’s private key
2. The symmetric key is encrypted with the public key of the authorised user If a user is authorised to access a health record and requests access then the following process takes place:

In the case that a participant’s access is removed from a health record:

1. The symmetric key is decrypted with the private key of the owner of the EHR
2. The EHR is decrypted using the symmetric key
3. The record is re-encrypted with a new symmetric key
4. The symmetric key is encrypted with all the remaining authorised users’ public keys

<figure><img src="/files/d8z4n8OzAh5kx6hIaFdd" alt=""><figcaption></figcaption></figure>

1. The private key of the requesting user is used to decrypt the symmetric key for the EHR
2. The decrypted symmetric key is used to decrypt the patient’s EHR

Any interactions with health records are recorded as transactions on the network. Transactions are viewable only to the participants associated with the transaction. Here are examples of how transactions take place on HealthLink.

<figure><img src="/files/Cq58jV8bLP90nqiyd9Rc" alt=""><figcaption></figcaption></figure>

**Data Structure**

Hyperledger’s modelling language will be used to define the domain model for the network. Below are some examples from the .CTO file of how models will be defined and stored on the chain. These are subject to change depending upon different regulations and requirements in order to make the HealthLink platform HIPPA and GDPR compliant.

Participants

<figure><img src="/files/e0x1jqeY9IWOjDEchiuf" alt=""><figcaption></figcaption></figure>

Assets&#x20;

Personal Details&#x20;

Relationship: Patient (Participant)

<figure><img src="/files/FPpnfWEX5MwQUKIz7DY5" alt=""><figcaption></figcaption></figure>

Practitioner’s public profile&#x20;

Relationship: Practitioner (Participant)

<figure><img src="/files/TSCY3uFV3jtjddrGcErH" alt=""><figcaption></figcaption></figure>

Medical Record

<figure><img src="/files/MAKq93nSf8DsIHl593KO" alt=""><figcaption></figcaption></figure>

<mark style="color:blue;">**Concepts**</mark>

Address

<figure><img src="/files/ixTDmUSUXOi08gzGJoDG" alt=""><figcaption></figcaption></figure>

**Permission Definitions**

Hyperledger Fabric includes an access control language (ACL), which defines access over the elements of the .CTO domain model above. By defining ACL rules we are able to control which resources participants have access to on the network’s domain model. Some examples of these access rules are shown below:

HealthLink **API Platform**

HealthLink will offer an API that will permit third parties to obtain and interact with EHRs with the user’s permission. All endpoints available in the UI will be available to developers. We hope to cultivate a robust ecosystem of applications and services.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://healthlink-1.gitbook.io/untitled/technical-explanation.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.