Indonesian J our nal of Electrical Engineering and Computer Science V ol. 41, No. 3, March 2026, pp. 1025 ∼ 1039 ISSN: 2502-4752, DOI: 10.11591/ijeecs.v41.i3.pp1025-1039 ❒ 1025 A smart-contract framew ork f or patient identity management in digital health platf orms Cah y o Prihantor o 1 , Dany Candra F ebrianto 1 , Maie Istighosah 1 , Ahmad Uf Lestrasi Ma’ ruf 2 , Angger T auqur Rohman W inar no 1 , Y udha Islami Sulistya 2 1 Informatics of Engineering Study Program, T elk om Uni v ersity , Purw ork erto Campus, Purw ok erto, Indonesia 2 Softw are Engineering Study Program, T elk om Uni v ersity , Purw ork erto Campus, Purw ok erto, Indonesia Article Inf o Article history: Recei v ed Sep 14, 2025 Re vised Jan 13, 2026 Accepted Mar 4, 2026 K eyw ords: Blockchain FHIR interoperability P atient identity management Self-so v ereign identity Smart contract ABSTRA CT A smart -contract frame w ork for patient identity management in digital health platforms. A major g ap in current digital health ecosystems is the absence of a portable and v eriable patient identit y layer across fr agmented electronic health record (EHR) systems. The problem addressed is the lack of a portable, v eriable, and patient-centric identity layer across fragmented electronic health record systems, which weak ens access accountability and pri v ac y . The proposed solution couples f ast healthc are interoperability resources (FHIR ) with self-so v ereign identity (SSI), storing FHIR payloads of f-chain in the InterPlanetary le system (IPFS) and committing only encrypted pointers and policies on Polygon smart contracts. P atient identiers and content addresses are protected with AES-256- GCM authenticated encryption and elliptic-curv e k e y wrapping (ECIES) for both the healthcare administrator and the patient. A web implementation in Ne xt.js using thirdweb automates w allet creation, k e ystore handling, encryption, and on-chain commits. In e v aluation with 50 synthetic re gistrations, success reached 100 percent, median end-to-end latenc y w as 5.86 seconds, mean on-chain late nc y 3.77 seconds, a v erage transaction fee 0.0401 POL/MA TIC, encryption time 13.9 milliseconds, and all decryptions v alidated. The results indicate practical feasibility for portable identity and auditable access, with on-chain latenc y as the main bottleneck to be reduced through batching, cheaper layers, and broader eld trials. Ho we v e r , this study is limited because the e v aluation uses only synthetic data and singlepro vider testing, without real-w orld patients or multi-institutional en vironments. Zero-kno wledge proofs (ZKP) are discussed conceptually as future inte gration and are not implemented or benchmark ed in this w ork. This is an open access article under the CC BY -SA license . Corresponding A uthor: Cah yo Prihantoro Informatics of Engineering Study Program, T elk om Uni v ersity , Purw ok erto Campus Street of DI P anjaitan No.128, Purw ok erto 53147, Central Ja v a, Indonesia Email: cah yop@telk omuni v ersity .ac.id 1. INTR ODUCTION Digital health ecosystems increasingly rely on the seamless e xchange of patient data across hospitals, laboratories, insurers, and home de vices. Ho we v er , identity remains a fragile link that determines who may access which data, when, and for what purpose. Centralized identiers embedded within siloed electronic health records (EHRs) and cloud platforms introduce risks of breaches, opaque pro v enance, and une v en trust across inst itutions [ 1 ], [ 2 ]. Interoperability standards such as f ast healthcare interoperability resources (FHIR) J ournal homepage: http://ijeecs.iaescor e .com Evaluation Warning : The document was created with Spire.PDF for Python.
1026 ❒ ISSN: 2502-4752 f acilitate data e xchange b ut, by themselv es, do not ensure system trustw orthiness or strong identity assurance in heterogeneous internet of medical things (IoMT) en vironments [ 3 ], [ 4 ]. As a result, a recurring tension arises between timely care and pri v ac y preserv ation, especially when medical records are shared across or g anizations and cross jurisdictional boundaries [5], [6]. Ho we v er , a fundamental g ap persists: current digital health infrastructure s lack a portable and v eriable patient i dentity layer capabl e of bridging the fragmentation across di v erse EHR systems, creating a clear g ap that this study aims to address. The problem to be addressed is the absence of a patient identity layer that is truly portable, v eriable, and patient-centric within a fragmented healthcare architecture. Identity remains tied to EHR silos and institutional accounts, making access dependent on central authorities and e xposing systems to single points of f ailure and pri vile ge misuse [ 2 ]. Data-e xchange standards such as FHIR f acilita te interoperability b ut do not automatically ensure reliability , trust, and identity assurance in heterogeneous, IoMT -rich en vironments [ 3 ]. At the operational le v el, patient portals and record-sharing mechanisms often lack genuinely ne-grained authorization, rob ust audit trails for e v ery identity e v ent, and consent e vidence that can be easily v eried across pro viders [ 1 ], [ 7 ]. In the security domain, the Health-IoT ecosystem e xpands the attack surf ace and requires a consistent c yber -risk e v alua tion frame w ork for identity o ws, which is not yet established in man y implementations [ 8 ]. In smart-city and cloud settings, crossservice authentication demands a transparent shared trust model; current centralized approaches do not meet this need [ 9 ]. Meanwhile, self-so v ereign identity promises direct patient control, b ut practical deplo yments that unify portability , pri v ac y , and dynamic consent remain limited [ 5 ], [ 10 ]-[ 12 ]. T oget her , these barriers dri v e service delays, duplicati v e v erication, potential data leakage, identity mismatches, and weak access accountability as data mo v e across f acilities, jurisdictions, and platforms. Prior w ork across digital health highlights recurri ng needs for secure patient identity , cryptographically enforced access, and standards-based interoperability across institutions [ 10 ], [ 13 ]-[ 20 ]. Although decentralized identity models such as SS I and v eriable credentials of fer promising foundations [ 21 ]-[ 23 ] real deplo yments remain fragmented and rarely inte grate FHIR’ s structured data model with patientcontrolled decryption. While se v eral studies discuss adv anced mechanisms such as dynamic consent or zerokno wledge proofs, these concepts mostly remain theoretical and are not implement ed in practice—including in this study [ 17 ], [ 24 ]-[ 27 ]. These g aps moti v ate the need for a practical, inte grated frame w ork that unies identi ty , encrypted metadata management, and interoperable clinical data o ws. The proposed approach combines the FHIR standard, self-so v ereign identity frame w orks, smar t contracts on the Polygon netw ork, end-to-end encryption, and zero-kno wl edge proofs so that data fragmentation, access control, and interoperability can be handled in a systematic and auditable w ay; patient and authority identities are managed with sel f-so v ereign identity and v eriable credentials, while o wnership proofs or sensiti v e attrib utes can be demonstrated without re v ealing full identity using zero-kno wledge proofs to uphold minimal disclosure [ 5 ], [ 28 ]-[ 31 ]; clinical data are represented as FHIR resources with patient as the k e y entity so tha t each observ ation, encounter , or prescription carries a consistent identity reference across systems, FHIR artif acts are stored in encrypted form in of f-chain storage such as IPFS, and the blockchain records only hashes, content addresses, and access-polic y pointers to preserv e inte grity , pro v enance, and an audit trail without e xposing record contents [ 1 ], [ 3 ], [ 10 ], [ 15 ]-[ 17 ], [ 32 ]-[ 34 ]; access is go v erned by patient-centric smart contracts that enforce attrib ute-based policies and purpose- and time-bound dynamic consent, enabling patients to grant, constrain, or re v ok e permissions, pro viding a fully logged emer genc y mode, and issuing third-party-v eriable proofs of access without re v ealing patient data through proof-based cryptograph y [ 13 ], [ 14 ], [ 35 ]-[ 37 ]; Polygon is selected for EVM compatibility and lo w transaction costs for polic y operations and metadata logging, with prior w ork indicating ef cient smartcontract use at modest a v erage costs suitable for day-to-day healthcare operations [ 24 ], [ 38 ], [ 39 ]; resilience is enhanced by v alidating all contracts that interact with health data through a proxy-v erication layer before deplo yment to lter malicious contracts and preserv e b usiness-logic inte grity , while reliability metrics and security risk assessments are appli ed in line with best practices for FHIR systems and BC-IdM e v aluation frame w orks in health-I o T settings [ 3 ], [ 8 ], [ 23 ]; operationally , a service pro vider submits a request with proofs of rele v ant attrib utes, the smart contract e v aluates consent and polic y and if v alid issues purpose- and time-bounded access rights, and the client retrie v es the encrypted FHIR payload from IPFS and decrypts it using a session k e y wrapped with the patient’ s k e y , ensuring that access remains under the data o wner’ s control, interoperable across f acilities, and auditable end-to-end [1], [10], [17] The main contrib uti on of this w ork is the inte gration of FHIR interoperability , self-so v ereign identity , and encrypted of f-chain IPFS storage into a smart-contract frame w ork that enables patientcontrolled access and Indonesian J Elec Eng & Comp Sci, V ol. 41, No. 3, March 2026: 1025–1039 Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian J Elec Eng & Comp Sci ISSN: 2502-4752 ❒ 1027 v eriable auditability . In this design, FHIR payloads are encrypted end-to-end before being stored of f chain, while the blockchain records only hashes, encrypted pointers, and polic y metadata. Decryption is performed solely by authorized clients using patient-controlled k e ys, and each access e v ent is logged on chain. The smart contracts support v ersioned pointers and polic y-based access control, while Polygon reduces operational cost and latenc y . A proxy-v erication layer further enhances contract inte grity . Zero-kno wledge proofs are noted as future w ork for pri v ac y-preserving attrib ute v erication. Ov erall, the frame w ork pro vides portable identity , patient-centric access control, and auditable data e xchange across fragmented health systems. The no v elty of this w ork lies in the inte gration of FHIR-based interoperability , SSI-dr i v en patient identity , and dual-recipient encrypted pointers recorded on the Polygon blockchain, implemented in a fully operational prototype. Unlik e prior studies that remain conceptual or focus s olely on data sharing, this frame w ork deli v ers v eriable auditability , patient-controll ed decryption, and empirical performance e v aluation across a complete re gistration and access w orko w . 2. METHOD Methodology co v er design, implementation, and e v aluation across architecture mapping, HL7 FHIR modeling, polic y/consent access control, cryptographic k e y management for encrypted pointers, Polygon smart contracts with audit/v ersioning, and tests of performance, reliability , accurac y , and cost. 2.1. Logic ar chitectur e Figure 1 illustrates the system’ s logical architecture, which i s di vided i nto four layers: client & trust, g ate w ay , on-chain, and of f-chain. The client & trust layer manages the patient’ s SSI w allet, credentials, and cryptographic operations, while pro viders use the console to re gister and access patient data. The Gate w ay layer v alidates API calls and forw ards standardized FHIR requests to SA TUSEHA T , coordinat ing re gistration and access w orko ws. On-chain, Polygon smart contracts store encrypted pointers with v ersion history and record consent metadata for auditability . Of f-chain, IPFS holds the encrypted FHIR p a yload and SA TUSEHA T pro vides the authoritati v e P atient resource. During re gistration, the system creates a w allet, encrypts patient identiers, uploads the encrypted payload to IPFS, and records references on-chain. F or access, the system v eries credentials, checks consent metadata, retrie v es the encrypted payload, and decrypts it for authorized users. This design enables multi-pro vider onboarding and gi v es patients cryptographically v eriable control o v er their data. Conceptual ZKP components are included as future enhancements for pri v ac y-preserving attrib ute v erication. Figure 1. The logical architecture A smart-contr act fr ame work for patient identity mana g ement in digital health platforms (Cahyo Prihantor o) Evaluation Warning : The document was created with Spire.PDF for Python.
1028 ❒ ISSN: 2502-4752 2.2. Data design and metadata The data design in this study adopts the HL7 FHIR (F as t Healthcare Interoperability Resources) standard with the Indonesian Ministry of Health National proles to maintain interoperability and schema consistenc y across systems. Element structures are represented with FHIRP ath so that attrib ute locations, primiti v e data types, and terminology bindings can be traced deterministically . The metadata scope includes patient identity and status, terminology coding, timestamps, and administrati v e re gion e xtensions. All elements are prepared for schema v alidation, serialization, encryption, polic y-bas ed access control, and auditing, which enables safer and more scalable automation of ingestion, storage, and information e xchange. As the modeling and v alidation reference, T able 1 FHIR patient summarizes element paths using FHIRP ath together with the primiti v e data types used in the P atient resource according to the national prole. This or g anization simplies deterministic na vig ation of attrib ute positions (for e xample identity , demographics, clinical status, emer genc y contacts, and communication language) while ensuring type consistenc y during serial- ization, schema v alidation, and service-to-service mapping. Methodologically , the FHIRP ath list serv es as an operational reference for b uilding input forms, dening v alidation rules including terminology , performing ETL transformations, and conducting inte gration testing, so the ingestion and data e xchange pipeline is standardized and lo w in ambiguity . T able 1. FHIR path mapping and data types FHIR P ath [1] FHIR P ath [2] T ype [1] T ype [2] P atient.resourceT ype P atient.maritalStatus.coding[0].system code uri P atient.meta.prole[0] P atient.maritalStatus.coding[0].code canonical code P atient.identier[0].use P atient.maritalStatus.coding[0].display code string P atient.identier[0].system P atient.maritalStatus.te xt uri string P atient.identier[0].v alue P atient.multipleBirthInte ger stri ng inte ger P atient.acti v e P atient.contact[0].relationship[0].coding[0].system boolean uri P atient.name[0].use P atient.contact[0].relationship[0].coding[0].code code code P atient.name[0].te xt P atient.contact[0].name.use stri ng code P atient.gender P atient.contact[0].name.te xt code string P atient.birthDate P atient.contact[0].telecom[0].system date code P atient.deceasedBoolean P atient.contact[0].telecom[0].v alue boolean string P atient.address[0].use P atient.contact[0].telecom[0].use code code P atient.address[0].line[0] P atient.communication[0].language.coding[0].system stri ng uri P atient.address[0].city P atient.communication[0].language.coding[0].code st ring code P atient.address[0].postalCode P atient.communication[0].language.coding[0].display st ring string P atient.address[0].country P atient.communication[0].language.te xt code string F or cryptographic identity and national health identity tracking, T able 2. P atient w allet and IHS number response species the data paths and types related to the patient w allet (w allet address, public k e y , k e ystore structure) and the IHS Number that appears in responses. This sequence supports access control and auditing: the patient w a llet go v erns decryption and authorization k e ys, the k e ystore describes k e y protection mechanisms (cipher , KDF , parameters), and the IHS Number pro vides a unique identier within the health system. The table therefore guides implementation for binding on-chain and of f -chain identities, recording consent, and tracing transaction and access e v ents, without repeating the P atient structure already co v ered in the pre vious table. T able 2. P atient w allet k e ystore path and data types P ath [1] P ath [2] T ype [1] T ype [2] response.id patientW allet.k e ystoreJson.Crypto.kdfparams.dklen inte ger string patientW allet.address patientW allet.k e ystoreJson.Crypto.kdfparams.p inte ger string patientW allet.publicK e y patientW allet.k e ystoreJson.Crypto.kdfparams.r inte ger he x (secp256k1 compressed) patientW allet.k e ystoreJson.address patientW allet.k e ystoreJson.Crypto.mac he x he x (lo wercased) patientW allet.k e ystoreJson.id patientW allet.k e ystoreJson.x-ethers.client string uuid patientW allet.k e ystoreJson.v ersion patientW allet.k e ystoreJson.x-ethers.gethFilename string inte ger patientW allet.k e ystoreJson.Crypto.cipher patientW allet.k e ystoreJson.x-ethers.path string string patientW allet.k e ystoreJson.Crypto.cipherparams.i v patientW allet.k e ystoreJson.x-ethers.locale string he x patientW allet.k e ystoreJson.Crypto.cipherte xt patientW allet.k e ystoreJson.x-ethers.mnemonicCounter he x he x patientW allet.k e ystoreJson.Crypto.kdf patientW allet.k e ystoreJson.x-ethers.mnemonicCipherte xt he x string patientW allet.k e ystoreJson.Crypto.kdfparams.salt patientW allet.k e ystoreJson.x-ethers.v ersion string he x patientW allet.k e ystoreJson.Crypto.kdfparams.n patientW allet.k e ystoreP assw ord string inte ger Indonesian J Elec Eng & Comp Sci, V ol. 41, No. 3, March 2026: 1025–1039 Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian J Elec Eng & Comp Sci ISSN: 2502-4752 ❒ 1029 2.3. Roles and access contr ol In this model, pro vider administrators re gister patients in b ulk, and the system generates a crypt o w allet and JSON k e ystore for each patient. These are deli v ered securely to the patient and not retained by administrators. P atients v erify o wnership by supplying the k e ystore and passw ord, which allo ws a temporary local k e y decryption and a standard challenge–response signature. The v eried w allet is then link ed to the patient’ s DID or v eriable credential and to the corresponding F HIR P atient resource, while administrators operate only on metadata and encrypted pointers—not pri v ate k e ys. Access control follo ws polic y-based e v aluation using purpose, time, a nd attrib ute constraints. When clinicians request access, the Orchestrator v eries credentials, checks consent metadata, and enforces f acility scoping. If appro v ed, the system returns encrypted pointers, and the FHIR data are decr y pt ed only by authorized k e y holders. Polic y updates, re v ocation, and audit logging are supported, and each decryption e v ent is recorded on-chain for accountability . Conceptual ZKP components are reserv ed for future w ork. 2.4. Cryptograph y and k ey management Building on the cryptograph y and k e y-management architecture (Figure 2 cryptograph y and k e y management), the o w be gins at the k e y holders. The system generates a patient w allet using secp256k1 and packages the pri v ate k e y into a JSON k e ystore protected by a random Base64 passw ord. The administrator’ s symmetric k e y v ersion is stored in a k e y v ersion re gistry to support k e y rotation. In the entrop y & secrets stage, the k e ystore passw ord, K admin (32 bytes), and other random v alues such as 96-bit nonces or initialization v ectors (IVs) are produced by a cryptographically secure ps eudorandom number generator (CSPRNG). In the crypto service stage, HKDF-SHA256 deri v es tw o content k e ys, K CID and K IHS , from a random base k e y K rec . Each plainte xt, nam ely the CID (IPFS pointer) and the IHS or patient identier , is encrypted using AES-256-GCM with associated authenticated data (AAD) that binds the recordId andw alletAddress, and for the admi nistrator also includes the k e y v ersion. The content k e ys are then wrapped for tw o recipients: for the administrator , AES-GCM is used with K admin and AAD carrying the k e y v ersion; for the patient, ECIES o v er secp256k1 is used with the patient’ s public k e y . The results are packaged as encCid and encIhs objects containing { alg, i v , cipherte xt, recipients, aad } . In the packaging & persistence stage, the encrypted FHIR payload is stored of f-chain in IPFS, producing a CID, while encCid and encIhs are stored on-chain in the P atientInde x contract on Polygon as encrypted pointers together with their recipient lists. Duri ng access, tw o decryption paths are a v ailable. The administrator unwraps the content k e y using K admin based on the k e y v ersion and decrypts the data with AES-GCM. The patient unlocks the k e ystore using the passw ord to obtain the pri v ate k e y , performs ECIES unwrapping to reco v e r the content k e y , and decrypts the data using AES-GCM . Each successful decryption triggers an on-chain audit e v ent, DecryptEv ent, which records the recordId, t he e x ecutor’ s address, and the timestamp. Figure 2. Cryptograph y and k e y management A smart-contr act fr ame work for patient identity mana g ement in digital health platforms (Cahyo Prihantor o) Evaluation Warning : The document was created with Spire.PDF for Python.
1030 ❒ ISSN: 2502-4752 2.5. Smart contract framew ork Figure 3 sho ws the smart contract o v ervie w . The P atientIPFSMana g e r contract deplo yed on Polygon (EVM) stores only v eried IPFS pointers rather than clinical data. These pointers are maintained through a re gistry implemented as a mapping<string, PatientPointer[]> , which is v ersioned per patient identier . The P atientPointer struct contains the CID, patient type, identier , timestamp, createdBy , and acti v ation status. The P atientT ype enumeration ( WITH NIK , WITHOUT NIK , BABY NEWBORN ) is used to classify the identity source associated w ith each record. State updates are protected by the onlyOwner modier , ensuring that all data-mutating operations can be e x ecuted e xclusi v ely by the contract o wner . Core contract functions include addPatient(...) to append a ne w v ersioned record, deactivatePatient(...) to disable an e xisting entry , and query functions such as getLatestPatient(...) , getPatientByVersion(...) , and getHistoryCount(...) to support retrie v al and his torical inspection of patient pointers. F or on-chain auditing purposes, the PatientAdded and PatientDeactivated e v ents re cord essential k e y parameters, including the identier , CID, patient type, creator address, timestamp, and status. This contract design preserv es data inte grity , traceability , and minimal on-chain storage, where the blockchain maintains only cryptographic proofs and immutable change history , while the actual clinical content remains stored of f -chain in IPFS. Consequently , the architecture aligns with methodological requirements for implementing a secure and v eriable change log. Figure 3. Smart contract o v ervie w F or data addition, Algorithm 1 add patient describes the o w when the contract o wner (onlyOwner) writes a ne w IPFS pointer for a patient. The algorithm constructs a P atientPointer object containing cid, patientT ype, identier , timestamp, and createdBy , marks it as acti v e = true, and appends it to re gistry[identier] as the latest v ersion. The P atientAdded e v ent is emitted for on-chain audit, so e v ery ingest is recorded with k e y parameters and remains traceable. This mechanism enforces v ersion inte grity , author traceability , and the separation of medical content (of f chain) from historical proofs (on chain) within a secure and minimalist method. F or logical access termination, Algorithm 2 deacti v ate patient presents the procedure for soft deacti v ation of the most recent patient entry . Only the contract o wner is authorized to e x ecute the operation. The algorithm v eries that history e xists, conrms the entry has not already been deacti v at ed, and then s ets acti v e to f alse. The patient deacti v ated e v ent is recorded together with the v ersion inde x and timestamp so that the change log can be audited. This soft deacti v ation preserv es v ersion records without deleting history and enables safer access policies and reco v ery paths. Indonesian J Elec Eng & Comp Sci, V ol. 41, No. 3, March 2026: 1025–1039 Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian J Elec Eng & Comp Sci ISSN: 2502-4752 ❒ 1031 Algorithm 1 Contract add patient Data: identier: string, cid: string, patientT ype: P atientT ype, caller: address Result: A ne w P atientPointer is appended to re gistry[identier] and e v ent P atientAdded is emitted (state acti v e = true). 1: Begin 2: Require caller == o wner; otherwise reject as unauthorized 3: Construct ptr ← P atientPointer { cid, patientT ype, identier , timestamp = no w , createdBy = caller , acti v e = true } 4: Append ptr to re gistry[identier] 5: Emit e v ent P atientAdded(identier , cid, patientT ype, caller , no w , true) 6: r etur n success 7: End Algorithm 2 Contract deacti v ate patient Data: identier: string, caller: address Result: Latest pointer for identier is mark ed inacti v e; e v ent P atientDeacti v ated is emitted. 1: Begin 2: Require caller == o wner; otherwise reject as unauthorized 3: Let l en ← length(re gistry[identier]); if l en == 0 , reject (no record) 4: Let ptr ← re gistry[identier][ l en − 1 ] 5: if ptr .activ e == f al se then 6: reject (already deacti v ated) 7: end if 8: Set ptr .activ e ← f al se 9: Emit e v ent P atientDeacti v ated(identier , v ersion = l en − 1 , timestamp = no w) 10: r etur n success 11: End F or read and administrati v e needs, Algorithm 3 query and o wnership operations summarizes three read-only operations (getLatestP atient, getHistoryCount, and getP atientByV ersion) and one administrati v e operation (transferOwnership). The algorithm retrie v es v ersions determi nistically with v alidity checks (for e xample, it rejects empty histories or in v alid v ersion indices), while o wnership transfer requires the caller to be the current o wner and ne wOwner to be a nonzero address. T ogether , these operations pro vide a consistent observ at ion path o v er v ersioned data and strict contract go v ernance to maintain inte grity and a ccountability during the methodological phase. Algorithm 3 Read and o wnership operations Data: identier: string, caller: address Result: Latest pointer for identier is mark ed inacti v e; e v ent P atientDeacti v ated is emitted. 1: Begin 2: Switch on op: 3: Case GetLatest: 4: Let l en ← length(re gistry[identier]); if l en == 0 , reject (no record) 5: r etur n re gistry[identier][ l en − 1 ] 6: Case GetHistoryCount: 7: r etur n length(re gistry[identier]) 8: Case GetByV ersion: 9: If v er sion ≥ length(re gistry[identier]), reject (in v alid v ersion) 10: r etur n re gistry[identier][v ersion] 11: Case T ransferOwnership: 12: Require caller == o wner; otherwise reject as unauthorized 13: Require ne wOwner ̸ = address(0); otherwise reject (in v alid address) 14: Set ow ner ← ne wOwner 15: r etur n success 16: Def ault: reject (unkno wn operation) 17: End 2.6. Implementation setup The system is implemented entirel y as a web-based application using a single Ne xt.js codebas e that serv es both the user i nterf ace and the API layer through route handlers in app/api . Smart contracts are deplo yed using the Thirdweb deplo yment frame w ork, and the contract address is stored as the NEXT - PUBLIC CONTRACT ADDRESS en vironment v ariable. All conguration parameters are loaded through the .env.local le, including the Polygon netw ork conguration ( NEXT PUBLIC CHAIN ID , NEXT PUB- LIC RPC URL ), SA TUSEHA T credentials ( SATUSEHAT CLIENT ID , SATUSEHAT CLIENT SECRET , SA- A smart-contr act fr ame work for patient identity mana g ement in digital health platforms (Cahyo Prihantor o) Evaluation Warning : The document was created with Spire.PDF for Python.
1032 ❒ ISSN: 2502-4752 TUSEHAT URL ), IPFS endpoints ( IPFS API URL , GATEWAY URL ), a 32-byte base encryption k e y ( ENC - MASTER KEY BASE64 ), and the ADMIN PRIVATE KEY , which is accessible e xclusi v ely within the serv er - side e x ecution conte xt. On the client side, the Pro vider Console is u s ed by healthcare pro vider administrators to re gister multiple patients, while the P atient Portal enables patients to import a JSON k e ystore and enter a k e ystore passw ord for on-de vice v erication and decryption. The implementation relies on tw o primary Ne xt.js APIs. First, t he POST / a p i / r e g i s t e r- p a t i e nt endpoint forw ards the request body to the SA TUSEHA T /Patient API. Upon recei ving the SA TUSEHA T response, the system generates a secp256k1 w allet for the patient, creates a JSON k e ystore protected by a randomly generated passw ord, assembles a combined payload consisting of the original request, the SA TUSEHA T response, and a patientW allet block, and uploads the encrypted payload to IPFS to obtain a CID. Subsequently , the system performs separate encryption for the IHS and CID using HKDF-SHA256 for k e y deri v ation and AES -25 6- GCM for authenticated encryption, with k e y wrapping applied for tw o recipients (administrator and patient) using AES-GCM and ECIES o v er secp256k1 , respecti v ely . The resulting encIhs and encCid objects are then submitted to the smart contract via the Thirdweb SDK to be processed by the addPatient function. Second, the POST / a p i / r e q u e s t - a c c e s s endpoint v eries authorization, retrie v es encrypted pointers from the blockchain, and fetches the encrypted payload from IPFS. The system then performs client-side decryption using the patient’ s JSON k e ystore and the k e ystore passw ord that w as pre viously pro vided by the administrator , enabling the reco v ery of the content k e y and the subsequent decryption of the payload.During de v elopment, the system utilizes the Cardano or Amo y test netw orks. In production, all secrets are stored as serv er -only en vironment v ari ables, all connections are secured using HTTPS, Cross-Origin Resource Sharing (CORS) policies are strictly enforced, and request rates are limited to mitig ate ab use. End-to- end testing conrms that patient re gistration, IPFS upload, encryption, on-chain commitment, access requests, and decryption e x ecute consistently without requiring a separate back end component. 2.7. T est scenarios and metrics T est scenarios and quantitati v e metrics are dened to e v aluate the design’ s performance across six areas: end-to-end (E2E) o w , e xternal inte grations (SA TUSEHA T and IPFS), cryptograph y (encryption and decryption), identity and k e ys (w allet and k e ystore), and on-chain operations (Polygon). All metric s address three e v aluation obje cti v es: ef cienc y and reliability of service o ws (1–6); ef cienc y and correctness of cryptograph y on the client and recipient sides, co v ering k e y deri v ation, encryption, k e y wrapping or unwrapping, decryption, and accurac y (7–9); and identity o v erhead together with on-chain latenc y and transaction costs that af fect operational feasibility (10–11). M easurements are tak en directly at e x ecution Points are measured in code and summarized using the mean µ and the 95th percentile ( p 95 ) to capture both ef cienc y and rob ustness ag ainst outliers. First, E2E patient re gistration functionality is measured by total latenc y from the start of processing to the nal response: E2E i = t resp i − t 0 i (1) The mean and percentile are computed as: µ E2E = 1 n n X i =1 E2E i , p 95 E2E = inf { x : F E2E ( x ) ≥ 0 . 95 } (2) In addition, the end-to-end success rate e v aluates process reliability: Succ E2E (%) = N success N total × 100 (3) where t 0 i denotes the handler start timestamp for trial i , t resp i is the timestamp immediately before sending the response, n is the number of trials, F E2E ( · ) denotes the empirical distrib ution function, N success is the number of o ws that completed without error , and N total is the total number of trials. Second, e xternal inte grations are e v aluated separately . Request latenc y to SA TUSEHA T is dened as LA T SA TU ,i = t doneSA TU i − t callSA TU i , Succ SA TU (%) = N 2 xx N SA TU × 100 (4) Indonesian J Elec Eng & Comp Sci, V ol. 41, No. 3, March 2026: 1025–1039 Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian J Elec Eng & Comp Sci ISSN: 2502-4752 ❒ 1033 While IPFS upload performance is e v aluated as LA T IPFS ,i = t doneIPFS i − t callIPFS i , Succ CID (%) = N v alidCID N uploads × 100 (5) The uploaded payload size is also recorded as SIZE pa yload ,i = b yteLen JSON(pa yload i ) (6) where t call and t done denote the timestamps immediately before and after the fetch call, N 2 xx counts HTTP 2xx responses from SA TUSEHA T , N SA TU is the number of SA TUSEHA T calls, N v alidCID is the number of IPFS uploads that produced a v alid CID, N uploads is the total number of uploads, and b yteLen( · ) denotes the byte length of the JSON string. Third, cryptograph y and encryption are e v aluated by measuring HKDF k e y deri v ation for each label ℓ ∈ { CID , IHS } , AES-256-GCM encryption per eld, and k e y wrapping operations for both the administrator and the patient. The sizes of the resulting encrypted objects are then recorded. T l HKDF ,i = t hkdf , done i,l − t hkdf , start i,l , T AESenc ,i = t enc , done i − t enc , start i , T wrapA ,i = t wrapA , done i − t wrapA , start i , T wrapP ,i = t wrapP , done i − t wrapP , start i . (7) SIZE encCID ,i = b yteLen JSON(encCid i ) , SIZE encIHS ,i = b yteLen JSON(encIhs i ) (8) F ourth, cryptograph y: decryption. Measure content k e y unwrapping for administrator and AESGCM decryption per eld, then compute accurac y: T un wrapA ,i = t un wrap , done i − t un wrap , start i , T AESdec ,i = t dec , done i − t dec , start i , A CC dec (%) = N matc h N tests × 100 , (9) with a match if d CID = CID IPFS and d IHS = IHS SA TUSEHA T . Fifth, identity and k e ys. Measure w allet creation, k e ystore creation, and k e ystore size: T w allet ,i = t w , done i − t w , start i , T k eystor e ,i = t ks , done i − t ks , start i , SIZE k eystor e ,i = b yteLen(k eystoreJson i ) . (10) LA T tx ,i = t hash i − t prep i , Cost ETH tx ,i = gasUsed i × eectiv eGasPrice i , Cost Fiat tx ,i = Cost ETH tx ,i × P ETH . (11) 3. RESUL TS AND DISCUSSION Empirical results and discussion for the smart contract frame w ork for patient identity are presented, co v ering cryptographic artif acts, the k e ystore v erication w orko w , end-to-end and per -stage latenc y distrib u- tions, on-chain cost and g as characteristics, and a statistical summary from 50 re gistration cases, aligned with the test scenarios and metrics specied in Methods. T able 3 sho ws that both pointers, namely the identier (IHS) and the cid (IPFS address), use v ersion 1 ( v1 ) encryption based on AES-256-GCM combined with ECIES o v er secp256k1 . Each encrypted object includes a unique 96-bit initialization v ector (IV) and a 128-bit GCM authentication tag, along with identical associated authenticated data (AAD) that binds the cipherte xt to the r ecor dId and walletAddr ess . Each object contains tw o wrapped k e ys for distinct recipients: an administrator wrap encrypted using AES-256-GCM with k e yV er sion 1 , which protects a Base64-encoded record k e y ( K rec ) to support controlled k e y rotation, and a patient A smart-contr act fr ame work for patient identity mana g ement in digital health platforms (Cahyo Prihantor o) Evaluation Warning : The document was created with Spire.PDF for Python.
1034 ❒ ISSN: 2502-4752 wrap that encrypts the same K rec using the patient’ s secp256k1 public k e y deri v ed from the pubK e yHash . Per -eld content k e ys, K CID rec and K IHS rec , isolate compromise risk such that disclosure of one pointer does not re v eal the other . The encrypted artif acts are stored on-chain as compact JSON objects containing the Base64- encoded IV , authentication tag, cipherte xt, wrapped k e ys, and AAD. This representation remains ABI-friendly and audit-ready . Successful decrypt ion requires a v alid wrapped k e y for either recipient, matching AAD, and a v eried GCM authentication tag, thereby ensuring condentiality , inte grity , auditability , patient-centric access control, and readiness for master -k e y rotation without requiring re-encryption of historical records. T able 3. Encryption artif act summary (encIhs & encCid): AES-256-GCM + ECIES Object identifier cid alg v1(aes- 256- gcm+ecies- secp256k1) v1(aes- 256- gcm+ecies- secp256k1) cipher .i v a2ROJi3SqqNqakMW WBQj/gMmsCvYkgx1 cipher .tag biR+5au15iNSdIhEIJL/VA== s91GE5AQujoEi2TLML3wYg== cipher .cipherte xt HcN/PgDdwt9QfHWT bxxvGMKpYJ5DS7Pn0dYYg8FyqZwkA3/xC2+8 TOSPOL0kgy8Mo88zixZudkV7ekSdztbvSHBf 0n7XyN8= aad UDIwMzk1MzU0OTY4fDB4YmZDRmZkOWU1NmY2 MUVjNDNhRkZhMjgyMzU4NTVjRWM2MTUwMTMz Qg== UDIwMzk1MzU0OTY4fDB4YmZDRmZkOWU1NmY2 MUVjNDNhRkZhMjgyMzU4NTVjRWM2MTUwMTMz Qg== admin-aes (k e yV ersion, i v , tag, cipherte xt) kv=1, iv=eyfC0PwCZsrQDE0j, tag=3Bz0VkL ISMCinButBZ53vg==, ct=Qb4rmodoRbLaJLU PF+2AJ1U4g7zBlhvIT9np0Qbe9PGc3fOa393 xksvTcec= kv=1, iv=jwlm bI7QCRZRYOPR, tag=tKmrXJH WEKM/s4pm+ijRxA==, ct=cNCG5j 6KMjhqDPp I5KVzGxD2kjm6cJpADDu3S2O+YDdjZkNYRpC 7I2+G6WM= patient-ecies (pubK e yHash, payload) 0x5ba2d6bb...f08ba, payload=d9f1e0a80 6f40d91...12b29480 0x5ba2d6bb...f08ba, payload=211ceb822 a75c3a5...35b1c7c Figure 4 sho ws the end-to-end tim e distrib ution: most o ws nish within 4 to 7 seconds, the median is about 6 seconds, the 95th percentile is about 7.5 seconds, and a single outlier around 13 seconds suggests sporadic spik es from netw ork v ariability , e xternal service response s, or on-chain conrmation delays. Consistent with this, Figure 5 reports a v erage stage contrib utions to E2E, where the on-chain path is the dominant bottleneck at roughly tw o thirds of the total time, follo wed by SA TUSEHA T at about 17 percent, w allet creation at about 12 percent, IPFS at about 3 percent, and encryption near zero. Stage-wise boxplots conrm the lar gest spread for on-chain time with a long upper tail, SA TUSEHA T sho ws moderate v ariance with a fe w outliers, and IPFS and encryption are small and stable. The practical implication is to focus impro v ements on the on-chain path through priority-fee tuning, RPC optimization, or batching, and to reduce SA TUSEHA T and w allet-creation latenc y; cryptographic components are not performance limiting. Figure 4. End-to-end latenc y histogram and ECDF Figure 5. Mean stage contrib ution to E2E (bar) and per -stage latenc y boxplots Indonesian J Elec Eng & Comp Sci, V ol. 41, No. 3, March 2026: 1025–1039 Evaluation Warning : The document was created with Spire.PDF for Python.