Immunify: Decentralized Healthcare on Cartesi-rollup

Cartesi Grants Program CGP Pilot
1

New proposal

Immunify Health V1
(Winner of the 2023 online Cartesi hackathon)

A Decentralized permissionless health protocol on Cartesi Rollups. The Immunify platform leverages blockchain technology to establish a patient-centric electronic health record system that maintains a single, immutable version of patient data.

Project Description

Immunify is a decentralized platform that enables secure, efficient and transparent access and usage of medical data. Using Blockchain technology, we provide a user-focused electronic health record and maintain a single true version of user data.
Immunify will enable users to give conditional access to different healthcare agents such as doctors, hospitals, laboratories, pharmacists and insurers to interact as they see fit. Each interaction with their medical data is auditable, transparent and secure, and will be recorded as a transaction on Immunify’s distributed ledger. During this process, the patient’s privacy is protected at all times. Immunify is built on the Permissionless-based Cartesi Architecture with implementations allowing varying access levels; users control who can view their records, how much they see and for what length of time.
The Decentralized Health Management system will enable health institutions better manage user data enabling a shift from inefficient centralized storage to Distributed Ledger Systems. Health Credential Verification system will enable Health Professionals to have access to verifiable identities validated by Hospital and Graduating Medical Institutions. The telemedicine application will enable users to consult a real doctor remotely (for example, on their phone) for a small fee payable directly to the doctor. Vaccine distribution chain trackers will enable companies to efficiently track their entire drug production process from procurement of raw materials to the delivery of finished vaccines. The Marketplace enables Immunify users to negotiate commercial terms with third parties for alternative uses or applications of their personal health data which will be issued as ERC721 tokens respectively. For example, putting forward their data to be used in medical research. It is intended that Immnuify and others will contribute more applications to the platform - helping bring value to all stakeholders.

Value proposition

Immunify offers a unique solution for individuals and healthcare providers who seek a secure and efficient way to access and manage medical data. By leveraging the power of Blockchain technology, Immunify can offer a decentralized and user-focused electronic health record that maintains a single true version of user data.

The platform provides users with complete control over their medical data, allowing them to securely and efficiently share their information with healthcare providers and researchers as they see fit. Additionally, Immunify enables healthcare providers to seamlessly access and update patient records, leading to improved care and outcomes.

In terms of value to the Cartesi ecosystem or tech stack, Immunify can offer a crucial piece of the puzzle for the development of decentralized healthcare solutions. By providing a secure and reliable platform for medical data management, Immunify can facilitate the development of cutting-edge healthcare applications that leverage the power of Blockchain technology. Additionally, Immunify’s decentralized approach aligns well with Cartesi’s overall vision of democratizing access to decentralized solutions while maintaining the security and efficiency of the underlying technology.

How you will use Cartesi, specifically?

Cartesi is a blockchain project that aims to make it easier for developers to build and deploy decentralized applications that can handle complex computations. The Cartesi network is designed to provide a high level of scalability and interoperability by leveraging off-chain computation and side chains.
One of the key features of the Cartesi blockchain is its integration of a Linux-based virtual machine (VM). This enables developers to use familiar software stacks and tools, such as Docker, to build and test their applications off-chain. Once an application is ready, it can be verified and committed to the blockchain using a zero-knowledge proof (ZKP) mechanism, which ensures that the computation was performed correctly without revealing the actual data processed.
Cartesi’s smart contracts are unique in that they allow developers to build applications using familiar programming languages, such as C++, and execute them off-chain, without requiring developers to learn new blockchain-specific languages. This feature enhances the accessibility of the platform to developers, making it easier to build and deploy decentralized applications.
Cartesi’s innovative approach to smart contracts represents a significant step forward in the evolution of blockchain technology. By enabling complex computations to be performed off-chain, Cartesi addresses one of the main challenges facing decentralized applications today. Smart contracts provide a robust mechanism for verifying the results of these computations on the blockchain, ensuring their trustworthiness and security.
The back-end application will be running on the Cartesi VM. Immunify aims to develop a data ingestion engine that performs mainly 2 tasks namely:

  1. Data Encryption and Decryption
  2. Decentralized SQLite

Immunify implements a “Dual data encryption” strategy to ensure maximal security of data. Once data is sent from the frontend it will first be hashed with its checksum calculated. The ingestion engine further hashes this data using the patient and doctors private keys, applying compression and then persisting it to the decentralized database.

Data encryption, decryption and persistence is computationally intensive. Cartesi offers the advantage of being able to carry out these operations safely in a decentralized way. The backend data encryption engine will be developed in Rust to interact with the Cartesi Rollup.

Milestones

The goal of this project is to develop a secure and efficient encryption engine on Cartesi Rollups, leveraging the decentralized and scalable nature of the Cartesi network. The encryption engine will support various encryption algorithms, ensuring flexibility and compatibility with different use cases. The engine will be designed to execute within the Cartesi Rollup environment, enabling secure and verifiable encryption operations.

***** Milestone 1: Requirement Gathering *****

  • Duration: 1 week
  • Deliverables:
  1. Define the encryption algorithms to be supported by the engine, considering their security, performance, and compatibility.
  2. Identify the necessary features and functionalities, such as key generation, encryption, decryption, and secure key management.
  3. Design the overall architecture of the encryption engine, considering the components and interactions within the Cartesi Rollup environment with documentation.
  4. Define the interfaces for interacting with the encryption engine, ensuring seamless integration with other Cartesi applications with good documentation.
  • Funds request (USD) for milestone 1: 2,800 USD

***** Milestone 2: Ingestion Engine Development *****

  • Duration: 4 weeks
  • Deliverables:
  1. Cryptography Implementation
  • Implement the selected encryption algorithms, ensuring adherence to best practices and security standards.
  • Leverage well-vetted cryptography libraries and tools to minimize security vulnerabilities.
  • Conduct thorough testing and verification of the implemented algorithms to ensure correctness and robustness.

  1. Implementation of a Decentralized SQLite DB with data safety features

  2. Integration with Cartesi Rollups

  • Develop smart contracts or scripts that interact with the encryption engine within the Cartesi Rollup environment.
  • Implement secure communication channels between the encryption engine and other Cartesi applications running on the Rollup.
  1. Key Management and Security
  • Implement secure mechanisms for key generation, storage, and distribution.
  • Design and implement protocols for secure encryption and decryption operations, ensuring protection against potential attacks.
  • Conduct security audits and penetration testing to identify and address any vulnerabilities in the encryption engine.
  • Funds request (USD) for milestone 2: 12,000 USD

***** Milestone 3: Documentation and Testing *****

  • Duration: 2 week
  • Deliverables:
  1. Create comprehensive documentation, including API references, usage examples, and security guidelines.
  2. Perform rigorous testing, including unit tests, integration tests, and stress tests.
  • Funds request (USD) for milestone 3: 3,500 USD

***** Milestone 4: Deployment and Rollout *****

  • Duration: 2 week
  • Deliverables:
  1. Prepare the encryption engine for deployment on the Cartesi Rollup network.
  2. Collaborate with the Cartesi community and network validators to ensure a smooth rollout and integration into the Cartesi ecosystem.
  3. Continuously monitor and maintain the encryption engine, addressing any security vulnerabilities or performance issues that may arise.
  4. Stay updated with advancements in cryptography and adapt the encryption engine accordingly.
  5. Engage with the Cartesi community and participate in discussions to gather feedback and improve the engine over time.
  • Funds request (USD) for milestone 4: 0 USD

****** Total Funds request: [$18,300 USD] *****

About your Team

  1. Akanimoh Osutuk

Medical Doctor and Blockchain Developer. Medical Doctor with over 5 years of experience in Clinical care with a focus on Digital Transformation. Also a blockchain developer with active contributions in open source projects.

Tech Stack: Rust, JavaScript, Solidity.

GitHub: FibrinLab (Doc Akan) · GitHub

Previous Awards:

  • Winner of Avalanche Developer Subnet contest
  • Bloksson/Polkastar 2022 Hackathon winner
  1. Victor Onyeji

Medical Doctor and Backend Engineer. Backend Engineer with over 8 years experience building digital goods for healthcare. He will be responsible for implementing and updating the ingestion engine. Rust, Solidity, Node.js, React.js

Github: davik20 (davik stone) · GitHub

  1. Kosisochukwu Nwigwe

Medical Doctor with a strong passion for digital transformation in healthcare. Experience in developing health digital programmes and audits. Also, skilled in designing clinical workflows and protocols.

Github:

Links and resources (As showcased during the hackathon)

WhitePaper: https://drive.google.com/file/d/1OvKDHFv9M518PRhFEM9xFrmwv2oO5wTX/view?usp=share_link

Demo Site Website: https://immunify-dapp.netlify.app/

Github: https://github.com/Immunify-DAO

ERC-20 Payee address

0x3EFFe91C62d1864C3B791Bc7bbD43b68B899d12A

2 Likes
2

Great proposal and good luck with the project! Here is an interesting software that can be useful for your project https://www.medplum.com/

3 Likes
3

Hello!

Thank you for submitting your proposal, and congratulations on your hackathon win! :blush:

Your project is indeed intriguing, and I wholeheartedly support the goal of enhancing transparency in health data management and fostering more convenient, private patient-doctor relationships.

Regrettably, my opinion is that this proposal does not align with the project guidelines set forth for the grant program. Upon review, it appears more like a comprehensive DApp proposal rather than reusable infrastructure. Specifically, the UI design and development, front-end development, and deployment/testing milestones appear to be beyond the scope of a community grant. I’m interested in hearing whether others share this viewpoint.

However, the first milestone might still be a suitable candidate. If the Data encryption, decryption, and compression modules are developed in a generalizable and reusable fashion, they could potentially be deemed eligible for the program, in my opinion. I do have some questions regarding these modules’ functionality, such as how the ingestion engine would hash data using the private keys (sk) of patients and doctors within the Cartesi Machine without exposing those keys. Moreover, I’m curious about why data compression would take place on-chain rather than off-chain before entering the Cartesi Machine. A more detailed explanation or specification of these modules could help address these concerns and provide better insight into their implementation.

Let’s see what the others say,
Cheers!

2 Likes
4

@felipeargento is correct that although the project has great promise, the CGP program aims to fund reusable components that other devs in the community can use in their project. Can you please consider his feedback and rework the proposal to focus on a single reusable component that you wish to develop?

2 Likes
5

Thanks for the review. I am updating the proposal

1 Like
6

@felipeargento @joe-cartesi The proposal has been modified. Looking forward to a review.

1 Like
7

Kudos for your hackathon win! :smiley:

Can you elaborate more on the Dual Encryption part? I understand the need of having statistically indipendent keys for dual encryption so when you further hash the data you are using both the patients and the doctors private keys. The problem is that now you need both keys to decrypt the data. Does this go against the principle that the users/patients should have full ownership of their data?

Having in mind that the CGP program aims to fund reusable components, the components you are creating can also be reused, for example, to create a decentralized content sharing platform! :ok_hand: so please keep in mind that generalized approach :slight_smile:

3 Likes
8

@Paolo Thank you for your question! While the focus of our ingestion engine is primarily on single encryption, let me clarify the aspect of dual encryption for better understanding.

In the context of dual encryption, the use of statistically independent keys is indeed essential. The process involves encrypting the data using two separate keys, one associated with the patient and the other with the doctor. This approach enhances security by ensuring that both keys are required to decrypt the data.

However, it’s important to note that the dual encryption aspect may not conflict with the principle of users/patients having full ownership of their data. The ownership aspect primarily pertains to controlling access and determining who can view or modify the data. In our case, even though both keys are required for decryption, the patients still retain full ownership of their data.

By employing dual encryption, we provide an additional layer of security to safeguard sensitive information. It ensures that even if one key is compromised, the data remains protected as the attacker would still need access to the second key for decryption. The intention is to strengthen data privacy and protect against unauthorized access.

We understand the importance of balancing security and user ownership of data. Our approach aims to strike that balance by implementing robust encryption while ensuring that patients maintain control and ownership over their data. Additionally, appropriate access control mechanisms can be put in place to allow authorized individuals, such as patients or designated healthcare providers, to access and decrypt the data when necessary.

If you have any further questions or concerns, please feel free to let us know. We are committed to addressing any inquiries and providing a secure and user-centric solution for data encryption and ownership.

2 Likes
9

Thanks. Can you please describe how the decentralized SQLite database you propose to implement is different from the one already available in the Cartesi Rollups Examples repo?

1 Like
10

Query and Indexing Mechanisms. We are considering implementing efficient query and indexing mechanisms can enhance the performance of your decentralized SQLite DB. Also will include caching mechanisms, or optimized query execution strategies to enable fast and scalable data retrieval.
@joe-cartesi

11

I have pinged others to give their feedback. Thanks for your patience.

1 Like
12

Hi there, could you kindly explain how users’ data privacy would be protected if the encryption is carried out on the backend?
Also, it will help if you elaborate on the topology and security assumptions involving rollup nodes. Are you willing to run nodes in a permissioned setup? How much should patients trust node runners that they won’t disclose their data?
Thanks!

13

I appreciate your interest and important queries regarding the data privacy, security measures, and the use of rollup nodes in our Immunify Health project.

Immunify makes use of a decentralized architecture, meaning there isn’t a central authority that has control over user data. User privacy is a top concern for us, and our project has multiple layers of protection for users’ data privacy.

Data Encryption: We implement a “Dual Data Encryption” strategy to ensure maximum security of the data. Once data is sent from the front end, it is first hashed and its checksum is calculated. The ingestion engine further hashes this data using the patient’s and doctor’s private keys, applying compression, and then persisting it to the decentralized database. The use of these private keys ensures that only authorized parties (those in possession of the corresponding public keys) can access the encrypted information.

Role of the Back-End: Our back-end mainly carries out the tasks of data encryption and decryption, as well as managing the Decentralized SQLite. Although the encryption process is handled at the back-end, the data that reaches there is already hashed and the actual personal data is never exposed, thereby adding another layer of security.

Role of the Cartesi Rollups: In regards to the use of rollup nodes, Cartesi Rollups provide a Layer-2 solution that performs heavy computations off-chain while retaining the security guarantees of the Layer-1 blockchain. Rollups essentially bundle or “roll up” sidechain transactions into a single transaction and generate a cryptographic proof, known as a SNARK (succinct non-interactive argument of knowledge). This SNARK is then posted to the Ethereum mainnet. As a result, the data is kept secure, and the nodes that process this data do not have access to the original data content.

Regarding your question about whether we are willing to run nodes in a permissioned setup, currently, the Immunify Health system will be built on a permissionless setup, as per Cartesi’s architecture. The advantage of this design is that it increases the decentralization of the network, making it more robust and secure.

The trust of patients in node runners is of utmost importance. In our model, it’s not necessary for patients to trust node runners with their data because node runners do not have access to unencrypted personal health data. Furthermore, every interaction is auditable, transparent, and secure, and recorded as a transaction on Immunify’s distributed ledger, ensuring accountability and trust.

Hope this explanation addresses your concerns @erick.demoura .

1 Like
14

Hi @FibrinLab ! First congratulations on the Online Hackathon and thanks for submitting a proposal on such an important topic as handling sensitive medical records (and taking the time to think about the problem).

I do have some doubts/concerns about the proposed architecture achieving the desired result in a trustless and unpermissioned setup. Your double encryption is happening within the Cartesi Machine but the user data is ingested into the Cartesi Machine coming from a blockchain input (whatever the chain you are deploying your application on - Ethereum, a private chain, etc) so the user data is still “available” to 3rd parties before going through the double encryption.

Please let me know if my understanding/assumptions are incorrect and I’d like to make myself and the rest of my team (Prototype and Support Unit) available for discussing your idea in more details of you wish.

2 Likes
15

Hello and thank you for your insightful question!

You’ve brought up a critical point about data privacy during the transmission phase before encryption. We understand the concerns about potentially exposing patient data before it enters the Cartesi Machine for encryption. However, please allow us to explain our proposed solution to this issue.

We plan to implement a client-side encryption method to protect data before it is transmitted. This encryption will take place on the user’s device (for example, a smartphone, computer, etc.) before the data is sent through the blockchain. By employing this approach, the patient’s data will already be encrypted before it reaches the Cartesi Machine. The Cartesi Machine will then perform another layer of encryption (as described in the proposal) for additional security.

This ensures that the data is never exposed in an unencrypted form during transmission, providing robust privacy protection. Also, given that encryption keys are managed at the user level, no third parties would be able to decrypt the data without user consent.

We are aware that this methodology adds an additional layer of complexity, but we believe it’s necessary to guarantee the highest level of privacy and security for our users.

We appreciate your offer to discuss our project in more detail. We’re eager to address any additional concerns and explore ways we can further enhance our platform’s security and privacy.

Thank you once again for your keen interest and support in our project! @joe-cartesi @carlofragni

2 Likes