{"id":"f94da047-b1b8-417d-bd67-910017a22af6","arxiv_id":"2504.20700","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":0,"one_line_summary":"The authors present and measure an Ethereum smart contract based consent management system, integrated with cloud storage, that records, queries, and withdraws patient consent for the NewbornTime video research project.","lead":"This paper describes a blockchain-based consent management system for the NewbornTime project, which records maternal consent for birth and resuscitation videos using an Ethereum smart contract and a cloud dashboard. It is a systems paper reporting gas costs and scalability measurements, relevant to researchers building compliant digital consent pipelines for sensitive medical video data.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The supplied smart contract stores motherName, nationalID, and phoneNumber in plaintext on-chain, directly contradicting the central claim that PII is never stored on the blockchain.","rationale":"The reader's verdict of CONDITIONAL identifies an important GDPR issue, but the weaker point is internal inconsistency in the central claim. The paper's headline privacy contribution is that PII is not stored on-chain, yet the provided smart contract stores motherName, nationalID, and phoneNumber as plaintext struct fields, and the query procedure explicitly uses the mother's personal number as a lookup key. This is not a matter of regulator interpretation; it is a direct contradiction between the stated architecture and the supplied source code. Because the central claim fails on the evidence within the paper itself, the appropriate outcome is REJECT rather than CONDITIONAL: the authors must either remove PII fields from the contract and show encrypted off-chain references, or provide a complete artifact demonstrating an actual encryption layer. Without that correction, the system as described cannot be considered privacy-preserving or GDPR-compliant. I agree with the reader that the concept is not novel enough to justify unconditional acceptance and that the missing artifacts are a serious limitation, but the on-chain PII contradiction is more fundamental and moves the verdict to REJECT.","tokens_in":10698,"tokens_out":2195,"duration_ms":25791,"concrete_test":"Compile the supplied HealthcareConsent.sol with solc, deploy it to a local testnet, and submit a consent transaction with known values for motherName, nationalID, and phoneNumber. Inspect the transaction calldata, event logs, and storage slots; if the plaintext values appear in any of these, the on-chain PII is confirmed, refuting the 'no PII on blockchain' claim. Also grep the full contract source for any encryption/decryption library calls or use of the patient's personal number as a mapping key; if none are found, the encryption claim in Section 4.6.1 is unsupported.","verdict_should_be":"REJECT","load_bearing_attack":"The paper's central privacy claim is that 'PII is not stored on the blockchain; instead, the blockchain records only consent-related metadata' (Section 4.6). This is directly contradicted by the paper's own code and formalization. Listing 1 defines the Consent struct with fields 'address patient', 'address healthcareProvider', 'string motherName', 'uint256 nationalID', 'string phoneNumber', and 'uint256 timestamp'. Section 4.4 repeats these as the attributes of every consent record. The cryptographic privacy claim in Section 4.6.1 says sensitive information is encrypted before being stored, but the contract code contains no encryption or decryption calls and stores these fields as plaintext struct members. Algorithm 1 says to 'Encrypt consent record and send to smart contract', but the smart contract interface implied by the struct cannot receive an encrypted blob without changing the code. Moreover, QueryConsent in Algorithm 1 and Section 4.2 uses the mother's personal number as a key parameter to retrieve the consent record, which requires the personal number to be searchable on-chain (e.g., as a mapping key or indexed field), making plaintext PII part of the on-chain state. The ConsentChanged event also exposes indexed patient and healthcareProvider addresses on a public ledger. Therefore the strongest claim is internally inconsistent with the presented implementation. The additional GDPR erasure problem raised by the reader is real, but it is secondary: even if off-chain data is deleted, the on-chain plaintext PII and the immutable audit trail persist, and Article 17 erasure cannot be satisfied for public blockchain data. The absence of a complete deployment or artifact means these contradictions cannot be dismissed as a partial code listing.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript describes a blockchain-based patient consent management system developed for the NewbornTime project. The system uses an Ethereum smart contract (HealthcareConsent.sol) to record consent events, a web portal for mothers to submit and withdraw consent, cloud storage for video data, and a statistics dashboard. The paper claims that PII such as names and national IDs are never stored on-chain because consent records are encrypted before submission, and that consent revocation immediately deletes off-chain personal data, yielding GDPR compliance. The experimental section reports gas costs, transaction throughput, and scalability tests, including a comparison of full vs. minimal consent records.","tokens_in":10925,"tokens_out":5452,"duration_ms":55952,"significance":"The main value of the manuscript is its end-to-end architectural description of an applied blockchain-based e-consent workflow and its straightforward gas-cost measurements for consent operations. However, the central privacy contribution rests on a claim—'PII is not stored on the blockchain'—that is directly contradicted by the smart contract code and formal record definitions provided in the paper. Because the privacy guarantee is the paper's headline contribution and is also the basis for the claimed regulatory compliance, the manuscript in its current form cannot be considered sound. No machine-checked proofs or reproducible artifact is provided beyond a partial contract listing, and the experimental setup is not described in enough detail to verify the performance claims.","major_comments":[{"comment":"The smart contract stores motherName, nationalID, and phoneNumber as plaintext struct fields and contains no encryption or decryption operations; therefore the statement in Section 4.6 that 'PII is not stored on the blockchain; instead, the blockchain records only consent-related metadata' is false relative to the provided implementation. Algorithm 1's 'Encrypt consent record and send to smart contract' step has no counterpart in the contract code shown in Listing 1.","section":"Sections 4.3, 4.4, 4.6.1; Listing 1"},{"comment":"The query procedure takes the mother's personal number as the key parameter to retrieve consent records. This requires the personal number to be stored in a searchable on-chain form (e.g., as a mapping key or indexed event parameter), which conflicts with the claim that only encrypted metadata is stored. The ConsentChanged event additionally exposes indexed patient and healthcareProvider addresses on a public ledger, further contradicting the broad privacy statement.","section":"Section 4.2, Algorithm 1, QueryConsent"},{"comment":"The GDPR compliance claim is unsupported. The paper states that revoking consent deletes associated data from off-chain storage, but the on-chain consent records and consent-change events remain permanently. The manuscript does not analyze whether these on-chain artifacts—especially the consent record containing motherName, nationalID, and phoneNumber—are personal data subject to erasure, nor does it reconcile immutable ledger storage with the right to erasure under GDPR.","section":"Sections 4.6, 6.1, and 7"},{"comment":"The experimental measurements lack essential reproducibility information: no Ethereum client or network type, no compiler version, no optimizer settings, and no number of repetitions or error bars. Table 3 lists repeated identical gas values for Add Consent without explanation. Listing 1 is incomplete (it ends at the onlyOwner modifier), so the full contract under test is not available. These omissions prevent independent verification of the quantitative performance claims.","section":"Section 5, Tables 3–6"}],"minor_comments":[{"comment":"The gas cost for 10 records is exactly 10 times the single-record cost, but the execution time does not scale proportionally; the text should clarify how batches are submitted and whether execution times are measured serially or in parallel.","section":"Section 5.3, Table 4"},{"comment":"The terms 'BitUnitor' and 'BitYoga' appear without explanation or references; the relationship between these systems and the proposed architecture should be clarified.","section":"Sections 1 and 4.1"},{"comment":"Several sentences are grammatically incomplete or awkward, for example 'These measures are critical and maintaining compliance with healthcare data protection regulations' in Section 4.6, and 'building data integrity, and patient confidence' in Section 4.6.3; the manuscript would benefit from a careful language edit.","section":"Throughout"},{"comment":"The Keywords field is empty; the authors should add appropriate keywords describing the system, such as blockchain, smart contracts, consent management, healthcare privacy, and GDPR.","section":"Metadata"}],"recommendation":"reject","confidential_remarks":"The contradiction between the smart contract source and the paper's central privacy claims is severe. The authors would need to redesign the contract to avoid storing PII (or provide a working encryption scheme), rerun all gas and throughput experiments on the corrected contract, and add a substantive GDPR erasure analysis. I would be open to reconsidering a substantially revised manuscript that addresses these issues."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a workmanlike application of a known pattern—Ethereum smart contract for dynamic research consent—to the NewbornTime video collection pipeline, with a dashboard and gas cost measurements. The integration story is concrete and the authors are honest about low portal usage and scalability. The problem is that the paper's central privacy claim is contradicted by its own code. The Consent struct in Listing 1 stores motherName, nationalID, and phoneNumber as plaintext fields; Section 4.4 repeats those attributes; Algorithm 1 says to encrypt the consent record before sending it, but the contract has no encryption calls and the query path uses the personal number as a key. So the statement that PII is not stored on the blockchain is not supported by the presented implementation. The GDPR argument is also shaky: even if off-chain data is deleted on withdrawal, the immutable on-chain audit trail and the plaintext identifiers remain. That is a load-bearing flaw, not a missing polish item.\n\nWhat is worth keeping: the system architecture is clear, the integration with the Liveborn Observation app and BitYoga study IDs is specific, and the dashboard is sensible. The gas measurements are direct observations, and the data-minimization gas comparison is consistent with storing fewer bytes, though it is not used to prove a separate conclusion. The citation pattern is fine; they cite the relevant dynamic-consent and blockchain-health literature.\n\nSoft spots in proportion: no deployment environment is described, the contract listing is partial, and no artifacts are provided. Gas numbers have no error bars, but they are measurements, not fitted claims. The scalability discussion is honest about linear growth in gas costs.\n\nWho gets value: researchers working on e-consent or blockchain-based health data governance, and the NewbornTime team itself. I would not desk-reject. Send it to peer review with a major revision requirement: reconcile the contract with the privacy claims, either by removing PII from the struct, adding genuine encryption, or reframing the claim to match the code. If the authors can do that, the paper becomes a useful case study for consent management in birth-video research.","headline":"Internal contradiction between the code and the central privacy claim makes this a major-revision paper, but the architecture and measurements are worth a serious referee.","tokens_in":11510,"tokens_out":2016,"would_cite":false,"duration_ms":21949,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper proposes an Ethereum-based consent system for the NewbornTime project that records only encrypted consent metadata on-chain while keeping personal data off-chain, aiming to make consent management transparent, tamper-proof, and…","keywords":["blockchain","consent management","Ethereum","smart contract","GDPR","healthcare data privacy","NewbornTime","cloud computing"],"falsifier":"A GDPR-oriented audit could settle the central claim: request a copy of all on-chain records for a test subject after withdrawing consent and check whether the encrypted fields containing the mother's name, national ID, and phone number are still present and decryptable. If they remain accessible to any authorized party with the private key, the claim that 'PII is not stored on the blockchain' and that withdrawal ensures GDPR compliance is false.","tokens_in":10504,"feed_emoji":"🔒","tokens_out":2254,"duration_ms":24307,"temperature":0.7,"pith_summary":"The paper argues that a blockchain-based consent platform can give patients verifiable control over how their sensitive health data is used in research, using the NewbornTime project as a test case. It claims that storing only consent metadata on Ethereum, not personal information, preserves privacy while making consent records immutable and auditable. The system is designed to check consent in real time before any birth or resuscitation video is uploaded to the cloud. If the architecture works as described, it would give researchers and healthcare providers a trustworthy, automated way to honor consent across a data's full lifecycle.","feed_headline":"Ethereum consent system keeps patient data off-chain","feed_subtitle":"A smart-contract design for newborn research stores only consent metadata on-chain, enabling real-time verification before video upload.","key_machinery":"The load-bearing mechanism is the HealthcareConsent.sol Solidity smart contract, which maintains a mapping of patient Ethereum addresses to arrays of Consent structs, each holding patient address, provider address, consent status, mother's name, national ID, phone number, and timestamp. The contract exposes functions for submitting, querying, and revoking consent, enforces access control via an onlyOwner modifier, and emits ConsentChanged events to produce an audit trail. The paper pairs this with a cloud layer that performs ETL and an interactive dashboard, but the on-chain contract is what carries the transparency, immutability, and automation claims.","core_discovery":"The central claim is that a healthcare consent record can be managed securely and immutably on the Ethereum blockchain while the underlying personal data never appears on-chain: the smart contract HealthcareConsent.sol stores only encrypted consent-related metadata (status, timestamps, and encrypted identifiers such as name, national ID, and phone number), and the paper states that 'PII is not stored on the blockchain; instead, the blockchain records only consent-related metadata, ensuring privacy while maintaining transparency.' Consent withdrawal is handled by recording a new transaction and deleting associated personal data from off-chain storage, which the paper argues satisfies GDPR obligations. The system links this to the NewbornTime project by requiring valid consent before video data is uploaded to Azure cloud storage, with study IDs generated only after consent is confirmed.","pith_inferences":["The paper does not demonstrate that on-chain encrypted fields (name, national ID, phone number) are truly hidden from all authorized parties; if any party holds the decryption key, those fields are personal data, and GDPR's right to erasure may apply to the blockchain itself, not just off-chain storage.","A likely testable extension is to compare the system against a zero-knowledge or hash-based consent design where no encrypted personal fields are stored on-chain, to see whether the audit trail can be preserved without any personal data residue.","The real-time consent check before upload could be generalized into a policy engine that gates any data transfer to a research archive, which the paper only sketches for the delivery-room scenario."],"forward_implications":["If the system works as claimed, consent verification becomes a real-time, auditable step before any sensitive video is uploaded, reducing the risk of collecting data without valid consent.","Patients gain a transparent, self-service way to give, edit, and withdraw consent, with every change permanently logged, which could strengthen trust in research participation.","The measured gas costs show that storing minimal consent data roughly halves on-chain cost compared to full records, suggesting that a data-minimizing design is also the economically efficient one.","The architecture is modular enough that the same consent portal and smart contract could be reused in other clinical research projects, not just newborn care, once regulatory and usability assessments are done."],"supporting_citations":[{"why":"The NewbornTime study protocol defines the project context and the need for consent for birth and resuscitation video data.","marker":"[5]"},{"why":"The Ethereum white paper supplies the platform's smart contract and decentralized application capabilities that the system builds on.","marker":"[12]"},{"why":"Prior work on dynamic consent management via private blockchain provides the approach the paper extends to a public Ethereum setting.","marker":"[13]"},{"why":"The ConsentChain architecture demonstrates a blockchain-based dynamic consent system for clinical data sharing, serving as a related design baseline.","marker":"[15]"},{"why":"MedShare shows how blockchain can support trusted medical data sharing among cloud providers, justifying the decentralized-storage rationale.","marker":"[16]"},{"why":"The gas-cost measurement methodology comes from performance analysis of blockchain platforms under varying workloads.","marker":"[17]"}],"fun_headline_variants":["Ethereum consent: PII stays off-chain","Smart contract keeps newborn data private","Consent metadata on-chain, data off-chain","Blockchain consent for GDPR-safe videos","Verify consent on-chain before upload"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The system assumes that deleting personal data from off-chain storage upon consent withdrawal is enough to satisfy GDPR, even though the blockchain permanently retains encrypted consent records that still include a mother's name, national ID, and phone number; if regulators treat those encrypted fields as personal data subject to erasure, the central privacy claim collapses.","fun_headline_variants_meta":{"raw":{"variants":["Ethereum consent: PII stays off-chain","Smart contract keeps newborn data private","Consent metadata on-chain, data off-chain","Blockchain consent for GDPR-safe videos","Verify consent on-chain before upload"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000222,"raw_usage":{"total_tokens":1382,"prompt_tokens":799,"completion_tokens":583,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":415,"completion_tokens_details":{"reasoning_tokens":519}},"tokens_in":415,"tokens_out":583,"duration_ms":6825,"temperature":1.0,"reasoning_tokens":519,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T05:22:03.074727+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A GDPR-oriented audit could settle the central claim: request a copy of all on-chain records for a test subject after withdrawing consent and check whether the encrypted fields containing the mother's name, national ID, and phone number are still present and decryptable. If they remain accessible to any authorized party with the private key, the claim that 'PII is not stored on the blockchain' and that withdrawal ensures GDPR compliance is false.","supporting_citations":[{"cited_title":"Engan, S","cited_arxiv_id":null,"evidence_quote":"The NewbornTime study protocol defines the project context and the need for consent for birth and resuscitation video data."},{"cited_title":"Buterin, et al., A next-generation smart contract and decentralized application platform, white paper 3 (2014) 2–1","cited_arxiv_id":null,"evidence_quote":"The Ethereum white paper supplies the platform's smart contract and decentralized application capabilities that the system builds on."},{"cited_title":"Albanese, J.-P","cited_arxiv_id":null,"evidence_quote":"Prior work on dynamic consent management via private blockchain provides the approach the paper extends to a public Ethereum setting."},{"cited_title":"Albalwy, A","cited_arxiv_id":null,"evidence_quote":"The ConsentChain architecture demonstrates a blockchain-based dynamic consent system for clinical data sharing, serving as a related design baseline."}],"review_version":1}