IoT2Wallets: A Blockchain-Based Access Control and Consent-Auditing Architecture for Patient-Controlled Health IoT...

Health data generated by Internet of Things (IoT) devices outside institutional boundaries-consumer wearables and home-based clinical monitors-expands the attack surface for unauthorized access and complicates patient-side control over data sharing, a problem that conventional, centrally gated Electronic Health Record (EHR) architectures do not solve. Regulations such as the GDPR and the forthcoming European Health Data Space (EHDS) increasingly require auditable, revocable, patient-controlled access. This paper presents IoT2Wallets, a permissioned blockchain access-control and consent-auditing architecture combining decentralized identifiers (DIDs), W3C verifiable credentials, and two Solidity smart contracts (ConsentManager and AccessLog) on a four-node Hyperledger Besu network running IBFT 2.0 consensus (f = 1 of 4 nodes). We define a STRIDE-organized threat model describing the smart-contract-enforced mitigations in place and the threats left unaddressed. The architecture was implemented and evaluated across patient-controlled and institution-controlled consent scenarios, integrating HL7 FHIR R4 clinical and wearable data from a Parkinson's disease remote-monitoring pilot (18 patients, 20 healthcare professional evaluators). Across 200 test transactions per operation, verifiable credential verification averaged 95 (SD 12) ms, and end-to-end access logging latency averaged 3840 (SD 490) ms, with 0/200 observed failures across consent-verification and revocation tests (Wilson 95% CI upper bound ≈ 1.8%) and complete access log fidelity relative to the independently maintained gateway request log. We discuss the scope and limits of the security guarantees established-access control and auditability rather than comprehensive cryptographic protection, formal verification, or independent smart-contract audit-and outline the hardening work required before production deployment. These results are contingent on the current implementation, which has undergone internal code review only; no independent smart-contract audit or formal verification has yet been performed, and this absence should be read as the primary limit on the security claims that follow, not a minor caveat. In addition, all four ledger nodes in the pilot were operated by the research team, so the pilot does not test the multi-institution trust argument for using a blockchain rather than a signed log.