Large scale simulations of polymer flow through porous media provide an important tool for solving problems in enhanced oil recovery, polymer processing and biological applications. In order to include the effects of a wide range of velocity and density fluctuations, we base our work on a coarse-grain particle-based model consisting of polymers following Brownian dynamics coupled to a background fluid flow through momentum conserving interactions. The polymers are represented as Finitely Extensible Non-Linear Elastic (FENE) dumbbells with interactions including slowly decaying transient forces to properly describe dynamic effects of the eliminated degrees of freedom. Model porous media are constructed from arrays of parallel solid beams with circular or square cross-sections, arranged periodically in the plane perpendicular to their axis. No-slip boundary conditions at the solid–fluid interfaces are imposed through interactions with artificial particles embedded within the solid part of the system. We compare the results of our simulations with those of standard Smoothed Particle Hydrodynamics simulations for Newtonian flow through the same porous media. We observe that in all cases the concentration of polymers at steady state is not uniform even though we start the simulations with a uniform polymer concentration, which is indicative of shear-induced cross-flow migration. Furthermore, we see the characteristic flattening of the velocity profile experimentally observed for shear-thinning polymer solutions flowing through channels as opposed to the parabolic Poiseuille flow profile for Newtonian fluids. We present large scale Brownian dynamics simulations of polymer solutions flowing through complex geometries, with hydrodynamic interactions mediated through explicit solvent. Simulations like these provide an important research tool for various applications.Polymer flooding for Enhanced Oil Recovery (EOR) is one such application where large scale simulations of polymer solutions through porous media are very important. To understand the need for polymer flooding, it is important to understand the different stages of oil recovery from an oil reservoir. The first stage of oil recovery, known as primary recovery, typically involves the digging of production wells, through which the oil naturally comes out of the reservoir due to the high pressure of the oil in the reservoir and simultaneous rock decompression. This results in the recovery of 5–25% of the Oil Originally In Place (OOIP) depending on the type of oil reservoir. Light oils typically respond well to primary recovery whereas heavy oils and particularly tar sands respond very poorly . The secBesides its relevance for oil recovery, flow of polymer solutions and polymer gels in complex geometries is interesting in its own right . The intTraditionally, theoretical work mainly concentrates on constitutive modeling. Early work on polymer systems has been summarized in the books of Doi and Edwards  and GraeThe science of eliminating ‘irrelevant’ degrees of freedom from particle based simulations is called coarse graining. As a simple example, we mention the use of united atoms to simulate –CH, –r groups ,30. For r groups ,32. Arour groups , and in r groups . The latr groups . On the r groups  the blobr groups ,38 and tr groups ,40.All particle based models mentioned so far are too detailed to serve our purpose of performing large scale simulations of flow through large channels. We will have to resort to models in which every polymer is represented by one or two particles or blobs. Representing large but rather low density structures, such particles will severely overlap, resulting in every polymer having many neighbors within its radius of gyration. With the correct potential of mean force, i.e., the free energy of all eliminated degrees of freedom for the given configuration of the coarse degrees of freedom, the thermodynamics of such systems can still be simulated with great accuracy, provided the potential of mean force at hand can be represented in a tractable way. The dynamics of such particles, however, will not be captured with any accuracy at all. The reason for this is that the eliminated degrees of freedom in an all-atom simulation, as a result of the high degree of entanglement of the overlapping particles, would have given rise to a bunch of slow modes on a wide range of time and length scales, which we generically call disentangling. Tube models and corresponding disengagements as presented in the book of Doi and Edwards  describeA second aspect that is absent in most coarse grain polymer models but is important in the flow of low density polymer solutions is the possibility of hydrodynamic interactions. This is the transport of momentum resulting from movements of one polymer mediated through the solvent and imparted to another polymer. In this paper, we include the presence of the solvent through the simulation of explicit fluid blobs as in Smoothed Particle Hydrodynamics (SPH) . In ordeThus, in this paper, we give a proof of principle that our Hydrodynamically Coupled Brownian Dynamics (HCBD) model can be used to perform large scale simulations of polymer solution flow through channels with sharp boundary elements, with only limited computational effort. To this end, we study the flow of such systems through model porous media, which are constructed using periodic arrays of solid beams arranged on a square grid, the plane of which is perpendicular to the axes of the beams. We study the flow of our model polymer solution across two different types of beams—one with circular cross-sections which we call cylindrical beams and another one having square cross-sections which we call cuboidal beams to simulate both the curved and sharp interfaces found in naturally occurring porous media. Furthermore, we study two extreme angles of attack—one parallel to one of the Cartesian directions of the plane of the square grid of beams and another at an equal angle (45°) from either Cartesian directions of the same plane. Thus, we study four different cases—two model porous media geometries and two flow directions. We also compare the results with the flow of pure Newtonian solvent, which we have simulated using standard SPH simulations.Before embarking on a description of our model, we cite some other work in this field , as wellIn this section, we present the equations of motion of all particles present in our simulation boxes. These encompass the blobs that constitute a polymer, and those that make up the SPH based solvent.a at time t is updated according to: The position a as a result of the interaction with other such blobs, in addition to any force field that may have been applied. a. The third term on the right hand side of Equation  dumbbells obeying Brownian dynamics were coupled to the SPH fluid particles in a momentum conserving way using our Hydrodynamically Coupled Brownian Dynamics (HCBD) technique, thus guaranteeing correct hydrodynamic interactions. With all these physical aspects correctly represented in our model, it turned out that large scale simulations of tens of thousands of particles could easily be run, even in geometries that pose severe difficulties to constitutive model simulations.The model porous media were made of periodic arrays of (1) cylindrical beams with circular cross-sections and (2) cuboidal beams with square cross-sections. The axes of the beams were perpendicular to a plane, on which they are arranged with a square pitch. Two extreme angles of approach were studied in both cases. In all cases, it was easy to impose no-slip boundary conditions at the boundaries of the systems using embedded particles inside the solid regions.We have compared our results of polymer solution flows with those of Newtonian flows through the same geometries, modeled by simple SPH simulations. We observed that there are significant quantitative and qualitative differences between the Newtonian flow of the solvent and the non-Newtonian flow of our model polymer solution through the same porous media for the same applied pressure drop. The addition of the polymers to the solvent increases the viscosity of the solvent, which leads to a reduction in the velocity of the flow of the polymer solution through the porous media. Furthermore, this increased viscosity of the polymer solution is not constant but rather shear dependent. In this paper, we see how this leads to a flatter velocity profile of the shear-thinning polymer solution in the channels as compared to the parabolic Poiseuille flow profile of the Newtonian solvent.As scope for future research, we envisage that a hybrid model may be constructed where our technique could be used to feed information from the scale of pore throats to larger scale Computational Fluid Dynamics (CFD) simulations of oil reservoirs. In this initial study, we did not model the oil phase but rather focused on the single phase flow of polymer solution through the porous media, as that in itself is a complex subject. In principle, it should not be very difficult to add another Newtonian oil phase to our non-Newtonian polymer solution simulation but it will still require tuning the interaction between the aqueous and the oil phase in order to produce the proper thermodynamic interaction between the two phases.


Current literature lacks a comparative analysis of different motion capture systems for tracking upper limb (UL) movement as individuals perform standard tasks. To better understand the performance of various motion capture systems in quantifying UL movement in the prosthesis user population, this study compares joint angles derived from three systems that vary in cost and motion capture mechanisms: a marker-based system (Vicon), an inertial measurement unit system (Xsens), and a markerless system (Kinect). Ten healthy participants  were trained with a TouchBionic i-Limb Ultra myoelectric terminal device mounted on a bypass prosthetic device. Participants were simultaneously recorded with all systems as they performed standardized tasks. Root mean square error and bias values for degrees of freedom in the right elbow, shoulder, neck, and torso were calculated. The IMU system yielded more accurate kinematics for shoulder, neck, and torso angles while the markerless system performed better for the elbow angles. By evaluating the ability of each system to capture kinematic changes of simulated upper limb prosthesis users during a variety of standardized tasks, this study provides insight into the advantages and limitations of using different motion capture technologies for upper limb functional assessment. Motion analysis is a useful method to quantitatively and objectively assess human motion by providing kinematic information  during task performance. A large proportion of studies investigating human motion use 3D optoelectric motion capture systems. These systems track the position of markers placed on anatomical landmarks of the body to relate the position and orientation of body segments. These systems are advantageous given their high resolution and accuracy, as well as their long history of use in research ,5,6,7,8 Barriers to the use of optoelectric motion capture systems have prompted interest in other systems that have less restrictive operating environment requirements ,23. The There have been several previous studies comparing motion capture systems that have focused on one-to-one comparisons of a single test system and a gold standard system ,39,40,41To better understand the performance of various motion capture systems in quantifying upper limb movement in the prosthesis user population, this study compares kinematics  derived from three systems that vary in cost and motion capture mechanisms: a marker-based system, an IMU system, and a markerless system. Able-bodied individuals using a bypass prosthesis device performed several tasks as movement of the upper body was tracked simultaneously across all three systems. The results of this study can be used to identify consistencies and limitations of various motion capture systems in tracking movements similar to those performed by the upper limb prosthesis user population, which could facilitate the wider adoption of motion capture into rehabilitation. Ten able-bodied participants with no upper limb disability or impairment were included in this study. All subjects provided written informed consent prior to participating in the study. The study was conducted in accordance with the Declaration of Helsinki, and the protocol was approved by the U.S. FDA Institutional Review Board (Protocol #16-071). The participants were selected through convenience sampling . Nine of the ten participants were right-hand dominant , one was left-hand dominant  per the Edinburgh handedness survey . TM app on an iPod TouchTM   B. This aFollowing the protocol specified in Bloomer et al., 2019, all participants were trained with the right-hand MYO Bypass until a learning plateau of 90% peak performance had been achieved .When fully trained, participants performed the Targeted Box and Blocks Test (tBBT)  as well A brief description of each task used in this study can be found in Motion analysis involved the simultaneous recording of motion data from three systems: optical marker-based system , an inertial measurement unit (IMU)-based system , and a markerless system . The Vicon optical marker-based system was selected as the reference system based on its popularity and usage in the literature ,66,67,68TM motion analysis system consisting of eight Bonita B10 and two Vero v1.3 cameras was used to acquire and pre-process motion data . The motion capture cameras were set to a sampling rate of 100 Hz. Prior to each data collection session, the system was calibrated according to manufacturer guidelines. Twenty-seven retro-reflective markers were placed on the upper body of each participant at bony anatomical landmarks of the upper body in accordance with the Vicon Upper-Body Plug-In-Gait body model documentation. The Plug-In-Gait upper body model was then calibrated to the dimensions of the participant to create the wrist, forearm, upper arm, head, neck, thorax, and pelvic model segments. The Vicon was set as the primary recording system and controlled the initiation and termination of IMU recordings with a voltage duration sync pulse output. A ten-camera passive marker ViconFive IMUs for the Xsens Awinda were placed either at bony anatomical landmarks or the midpoints of moving body segments on the head, right arm, and torso. The head sensor was placed in the center of the subject’s forehead. The torso sensor was on the xiphoid process of the sternum. The pelvis sensor was placed at the midpoint between the left and right posterior superior iliac spines. The upper arm sensor was placed on the lateral midpoint of the upper arm. The forearm sensor was placed on the anterior midpoint of the bypass. The system was set to a sampling rate of 100 Hz. Prior to each data collection session, all accelerometry and gyroscope sensor outputs were set to zero at the origin of the recording volume on the floor, as defined by the Vicon calibration to ensure consistent initial sensor outputs. The Xsens was set as the secondary recording system with initiation and termination of recordings automatically controlled through a voltage duration sync pulse from the Vicon system, leading to the synchronization of two data streams from these systems.Two Kinect V1 cameras  were used with the iPi Soft markerless motion capture software  to acquire and pre-process motion data. The Kinect V1 was selected due to the limitations of the native Microsoft SDK which did not allow for multiple Kinect V2 data streams into a single computer. This limitation did not apply to the Kinect V1, which allowed for larger capture volumes and improved capture results when multiple Kinect V1 sensors were used . Additioresample was achieved through a post-processing automated MATLAB script. This was done to create time series data that were sampled at the same rate to compare each distinct time point across systems. The system was set to 30 Hz, the maximum sampling rate of the cameras. Prior to each data collection session, the system was calibrated according to the software manufacturer’s guidelines. Initiation and termination of recordings were manually controlled by the operator of the motion analysis systems. Data synchronization and resampling to 100 Hz with the built-in MATLAB function i is the index for each frame in a given joint movement trajectory.Joint angles over time were generated for all three systems. The joint angle dataset from the Vicon system was set as the reference system given its high resolution and accuracy ,5,6,7,8,A description of the joint angle calculations from each system used in the above equations is provided below.To assess consistency of measurements from each system, the intraclass correlation coefficient (ICC) was calculated using a two-way mixed effects model ). Each participant performed three trials of the same task. These three trials were used to determine the ICC of discrete kinematic parameters derived from the joint trajectory (range of motion) for each task/DoF combination and for each motion system evaluated in our study. The use of discrete kinematic parameters, such as RoM, was used to avoid artificially low ICC values due to slight misalignments in the trajectories across trials within a subject. Joint angles were calculated from the Vicon upper body model using YXZ Euler angles derived from relative orientation comparisons of two segments . Joint angles analyzed in this study include right elbow flexion/extension; right shoulder flexion/extension, abduction/adduction, and internal/external rotation; torso flexion, lateral flexion, and rotation; and neck flexion, lateral flexion, and rotation. The recorded data from each task were processed and manually segmented in Vicon Nexus into object interactions with the beginning of a segment defined as when the terminal device approached the object, and the end of a segment when the terminal device released the object. For tasks with multiple objects, such as the six objects in JHFT—Small Objects, this resulted in multiple segments. Although the locations of the task objects are standardized with placement templates, the individual objects may be distributed in the task space. Therefore, to reduce variability introduced in joint kinematics due to object distribution, the analysis was limited to the last segment, or last object interaction, within each trial.The joint angles for the IMU-based system were calculated based on relative sensor orientation. To generate joint angles, the IMUS proximal and distal to each joint were paired: one sensor was defined as the parent sensor and used to establish a local coordinate system and the other sensor was defined as the child sensor and provided the orientation data necessary to generate the joint angles. The right elbow flexion/extension was calculated between the forearm and upper arm sensors. Right shoulder angles were calculated between the sternum and upper arm sensors. Neck angles were calculated from the head and sternum sensors. Torso angles were calculated between the sternum and pelvis sensors. A brief description of the IMU joint angle calculation process is described below, with further details in The IMU sensor orientations were output as quaternions and decomposed into axial vector components that corresponded to the three axes of the sensor units in unit quaternions. Then, the axial vector components were used to generate the individual Euler joint angle components through decomposition. The decomposition used the known initial orientations of the sensor unit locations on the body to define a superior-inferior axis for each sensor, with the other two axes defined through orthogonality. The angles defined through the pairs of sensors sought to mimic the output of the Vicon YXZ Euler angle outputs. However, the shoulder angles suffered from computational errors and the XYZ rotation order was used instead to best match the Vicon outputs. This approach matched what was found in a recent study . The plaSince the data from the optical marker-based and IMU systems were synchronized, the IMU data were segmented for analysis using the segmentation event markers from the optical marker-based system. As previously mentioned, analysis was limited to the last segment of each task.The joint angles for the dual Kinects were calculated with the Biomech add-on toolbox for iPi studio using YXZ Euler angles derived from the relative orientation comparisons of two skeletal rig segments . To derive joint angles comparable to those generated from the Vicon marker-based system, re-zeroing operations were performed on the outputs of the Biomech toolbox. In some instances, joint angles from the Kinect system were inverted to match the conventions of the Vicon reference system angle values. For the right elbow angles, due to the obscuration of the MYO Bypass device caused by the actual right arm, the Kinect prioritized arm tracking over bypass tracking. An offset of 15°, equal to the medial offset of the bypass device, was applied to these elbow angles to provide a more accurate estimate. The data from the markerless system were synced with the optical marker-based and IMU systems post-capture with an automated MATLAB script. To aid in this synchronization, all subjects started each trial with their hands at their side and subsequently moved their arms into a “motor-bike” pose before performing the task. The transition to the motor-bike pose caused a predictable spike in the right shoulder angle. The MATLAB script detected time points in each system where the joint angle rate of change, or joint angle derivative, in the right shoulder exceeded a preset threshold (determined through pilot experiments). The data from each system were aligned to this detected time point and the first data point of the markerless system was adjusted to match the Vicon data point to be consistent. As previously mentioned, analysis was limited to the last segment of each task.The distributions of RMSE and bias values across all trials and subjects for the two comparison systems relative to the reference system are shown as boxplots for each joint in The markerless system tended to slightly overestimate the right elbow angle while the IMU system was inconsistent and greater in magnitude in the bias measurement B. LargerConversely, with the right shoulder, the IMU system had lower median RMSE values and tended to have lower variance for RMSE and bias compared to the markerless system A,B. The With the neck angle measurements A,B, the With the torso angle measurements A,B, the In this study, joint kinematics derived from three motion capture systems of varying costs and mechanisms were compared through simultaneous motion capture of able-bodied participants using an upper limb myoelectric bypass device. By evaluating the ability of each system to capture kinematic changes of simulated upper limb prosthesis users during a variety of standardized tasks, this study provides insight into the advantages and limitations of using different motion capture technologies for upper limb functional assessment. Two established metrics of precision and accuracy (RMSE and bias) were calculated as a function of ten different joint degrees of freedom and ten different upper-limb tasks for every time point to assess inter-subject variability and inter-system agreement. Because differences are calculated for every time point, the RMSE values would reflect unstable system-related influences given the simultaneous capture setup. Similarly, the bias values would indicate systematic influences on differences over time—allowing for an assessment of joint angle stability. In addition, ICC values were calculated for each system and each task/DoF combination using a two-way mixed effects model  to further assess consistency of measurements from each system. A discussion of advantages and limitations of each system is presented along with considerations for clinical implementation. Based on the results presented in this study, the IMU system yields more accurate kinematics for shoulder, neck, and torso angles over all DOFS  comparedFor both systems, the tasks requiring the greatest amount of movement  resulted in the largest RMSE and variability values over the DOFs examined. This implies that both systems struggled with precision during large gross movements, a result in line with the previous literature that suggests the markerless system overestimates large motions and underestimates small motions .For DOFs parallel to the recording plane of the cameras , the markerless system had the best results. Given the mechanism of movement capture for the Kinect V1, which measures infrared reflectivity and subtracts changes from a predefined static background ,46,73, tThe precision of the IMU system was best in the shoulder , which iIn terms of the system stability as measured by the ICC values, the IMU and marker-based systems showed comparable moderate to strong correlations across trials for all subjects. The markerless system generally showed weaker correlations compared to the IMU system and marker-based reference system. Due to the lack of any trends based on the task or DoF, these results can be considered to support the general performance of the three systems. However, it should be noted that the participants were free to choose their own approaches to achieve the tasks and often used different approaches between trials. As such, it is difficult to draw more specific conclusions based on the ICC values due to the inherent variability of the base data. Overall, the marker-based reference system and IMU system showed the greatest stability per the ICC metric.In terms of capturing environment restrictions and operating stability, the IMU system proved more robust and less demanding compared to the markerless system. The IMU system did not require the consideration of issues such as the color and reflectivity of the capture background and was not vulnerable to issues of obscuration from task objects or body parts. The IMU system had comparable costs for the number of sensors used, and less strenuous requirements for data processing, data storage, and data export procedures compared to the markerless system. The markerless system incorporated established calibration procedures, while there exist many approaches for effective calibration of the IMU system. The impact of IMU calibration procedure on derived joint angles was not the subject of this study but may need further investigation regarding the most effective calibration approach. However, both systems proved lacking in data annotation abilities—with the markerless system holding a slight advantage due to the visual review allowed by the video-based capture data. Overall, the IMU system may be best for clinical and remote monitoring purposes.The generalizability of the joint kinematics observed here with able-bodied individuals to those of upper limb prosthesis users is uncertain. However, the movements elicited by able-bodied individuals using a bypass prosthesis are close approximations to the movements of interest, making the results obtained in this study relevant to understanding the utility of different motion capture systems for tracking upper limb prosthesis user movement. The limitations and advantages discovered about each system in this study can be used to inform clinical implementation of motion analysis for research and rehabilitation. The focus on unilateral tasks performed with the MYO Bypass device may not be fully representative of device use patterns in daily living and may also be considered a limitation of the current study. While a bilateral task was included, , the task required symmetrical use of the two upper limbs. Motion analysis of tasks with independent use of both upper limbs has yet to be performed under these simultaneous capture conditions and is a future avenue of investigation. Given the current results with unilateral tasks, and other results in the literature , it is lThis study is the first that simultaneously compares multiple mechanisms of motion capture using a simulated upper limb prosthesis user population. It can serve as a starting point for minimum technical requirements in motion capture systems for use in clinical rehabilitation and highlights the current state of commercially available technology in terms of technical and capture environment requirements that may be barriers to the clinical adoption of motion capture. The results from this study can also be used to guide improvements in the design and algorithms of low-cost, portable motion capture systems to facilitate the wider adoption of these tools in clinical practice.


Real-time monitoring of the liquid core position during the continuous casting of steel has been demonstrated using low-cost distributed optical-fiber-based strain sensors. These sensors were installed on the containment roll support structures in the segments of a production continuous caster to detect the position of the solid–liquid interface and monitor the strand condition during the continuous casting. Distributed Fiber Bragg Grating sensors (FBGs) were used in this work to monitor strain at six roll positions in the caster. The sensor performance was first validated by comparing optical strain measurements with conventional strain gauge measurements in the lab. Next, optical strain measurements were performed on an isolated caster segment in a segment maintenance facility using hydraulic jacks to simulate the presence of a liquid core under the roll. Finally, the sensors were evaluated during caster operation. The sensors successfully detected the load increase associated with the presence of a liquid core under each instrumented roll location. Incidents of bulging and roll eccentricity were also detected using frequency analysis of the optical strain signal. The liquid core position measurements were compared using predictions from computer models  in use at the production site. The measurements were in good agreement with the model predictions, with a few exceptions. Under certain transient caster operating conditions, such as spraying practice changes and SEN exchanges, the model predictions deviated slightly from the liquid core position determined from strain measurements. Modern continuous casting technology has many features to improve throughput, quality, and safe operation of the process ,3,4,5,6.There are several ways that the position of the liquid core has been determined in the past, such as through the use of load cells , strain Strain measurements on the support structures of continuous caster support rolls have been shown to be an effective method for detecting the presence of the liquid core under a roll  during cThe application of Fiber Bragg Gratings (FBGs) in structural health monitoring of civil engineering structures , industrIn this paper, for the first time to our knowledge, the Fiber Bragg Gratings were employed for strain measurements in a steel plant by embedding the FBGs onto a continuous caster strand to monitor liquid core position during the continuous steel casting process. In the current work, the caster support beams at six roll positions in three segments of a continuous caster were instrumented with distributed optical fiber-based FBG sensors to measure the strain experienced when the liquid core passed the specific instrumented roll locations in the caster during normal caster operation as casting speed was varied. The resultant measured strains were used to identify the presence or absence of liquid in the core at these six roll locations during caster operation. The observed liquid core positions were compared with liquid core position predictions from the production sites’ on-line solidification models . In addition, a more detailed analysis of the strain signals was conducted to identify anomalies in the caster operation related to shell bulging and roll warpage events during caster operation.The structure of a Fiber Bragg Grating (FBG) is shown in B), termed the Bragg wavelength, is defined in Equation (1) [eff is the effective refractive index of the core of the optical fiber and Λ is the grating period.The wavelength of the reflected light (λtion (1) ,23,26:(1B introduced by a strain or a temperature change can be described in Equation (2) [e, acte, and acto are the strain-optic coefficient, thermal expansion coefficient, and thermos-optic coefficient, respectively. Therefore, by continuously monitoring the wavelength of reflected light, the Bragg wavelength shift can be determined, and the applied strain or temperature change experienced by the FBG sensor can be calculated.When an FBG sensor is subjected to an applied strain or temperature change, the refractive index of the core of the optical fiber and the grating period will experience changes, which results in a shift of the Bragg wavelength. Assuming that an applied strain or temperature change to the FBG sensor is uniform, the Bragg wavelength shift Δλtion (2) ,23,26: [TM) [A three-point bend test was performed in the lab to compare the strain measurements obtained using a commercially supplied optical FBG strain gauge (AuroraTM) , shown iTM) [TM) . A rectaTM) [TM)  using stAn additional test was conducted in the lab with the FBG sensors to evaluate the method used to compensate the strain measurements for varying environment temperatures. To perform temperature compensation, a second strain gauge was applied adjacent and perpendicular to the primary strain gauge that was parallel to the bending direction to allow for temperature compensation, as shown in The temperature compensation concept was evaluated in the laboratory load frame using a chamber to heat the instrumented beam in the bend tester. The steel beam was heated to create a uniform temperature of 150 °C distributed over the entire block. A three-point bend test was then performed to check the sensor performance at varying strain and temperature.To evaluate the robustness of the FBG strain gauges on a caster segment and to demonstrate the ability to measure deflection strains under industrial conditions, additional testing was performed on an isolated caster segment in the industry partner’s segment repair shop. To simulate the loads during caster operation, hydraulic jacks were placed close to the split-roll bearings located near the center of the segment cavity, as shown in As noted previously, pairs of orthogonally oriented FBG sensors were installed at six roll locations in the caster at the industry partner’s facility during a 12 h maintenance outage, and data were collected over two days of caster operation. Supplemental caster operating data were also collected for the trial period, such as casting speed, tundish level, mold width, etc., as well as liquid core position predictions from two on-line caster models . The instrumented locations were selected based on the expected liquid core position in the caster, as shown in Two sensors were placed on the top side of each roll support beam at each roll location, one parallel to the support beam and one perpendicular to the support beam, to measure strain and deconvolute the ambient temperature effects on the sensor measurement, as shown in The FBG sensor and strain gauge measurements from the laboratory three-point bend test were well correlated. However, the signal-to-noise ratio (SNR) for the FBG sensor was much higher than for the strain gauge. The estimated resolution of the strain gauge and the FBG sensor was 50 microstrain and 0.5 microstrain, respectively, as shown in The primary oriented sensor exhibited a positive change in strain with load, while the perpendicularly oriented sensor experienced a negative strain due to the Poisson effect during beam bending, as expected. The strain measured by the transverse sensor was approximately −12% of that measured by the strain sensor that was oriented in the direction of beam bending. However, the effect of temperature on the output of both FBG sensors was positive and comparable. As a result, subtraction of the transverse sensor signal output from the longitudinal sensor signal output can be performed to compensate for the temperature effect on the sensor outputs and isolate the strain measurements, as shown in The FBG strain gauges were tested in an off-line segment to check its ability to withstand the environment and resistance to vibration. As the load was applied to the caster rolls using hydraulic jacks, the strain experienced was measured by the FBG strain gauge. A maximum load of 8000 psi was applied by the hydraulic jacks. The clamping cylinders applied a pressure of 2000 psi to the segment to hold the segment closed. The load was applied individually to each caster roll, as shown in Further analysis of the strain data was conducted and the strain variation with load (psi) was determined. A near linear trend in strain was observed with increasing loads at each roll location, as shown in The loads were also applied to the caster rolls by simultaneously placing a single hydraulic jack next to the roll bearing at Roll-1 as well as Roll-2, and the strain was measured with varying applied load, as shown in The position of hydraulic jacks was also changed to the center of rolls between the bearings from positions adjacent to the bearing. The strain measured with varying loads was observed for this loading configuration in The strain trend observed before and after the clamping pressure was applied is also shown in Strain measurements and caster operating data were collected over two days of operation. An example of the data collected in the trial is shown in The raw strain signals for all six sensor sets for this cast sequence are shown in The net strains for all six roll locations for the 20-heat cast sequence are shown in An example of model predictions for liquid core position for two on-line continuous caster models employed in the test plant site is shown in The FFT analysis of the transverse strain sensor signal from the eighth heat in the cast sequence identified two frequency peaks that appear to correspond with two distinct disturbance conditions in the caster.At a steady-state casting speed of 44.7 ipm, a peak is observed in the disturbance frequency spectrum at 0.0234 Hz and a second peak at 0.0429 Hz. The peak at 0.0234 Hz matches closely with the calculated frequency for a bent or warped roll of 249–250 mm in diameter. The peak at 0.0429 Hz matches very closely with slab bulging in area 14 of the caster, which is the non-segmented part of the caster with a 436 mm roll pitch. The frequency analysis of the strain signals at Roll-75 identified two potential conditions that could affect slab quality: (1) a bent or warped roll condition in Segment 1, 5, or 6, and (2) a bulging condition in the non-segmented portion of the caster, resulting from running the liquid core beyond the segmented portion of the caster.The highly distributed optical strain measurement technique provides a low-cost method for continuously monitoring the casting process on a large number of rolls and segments for liquid core tracking and metallurgical length monitoring.The optical strain signals can also provide information about the strains experienced by the caster during various events, such as at startup, at operating transients such as speed and width changes, at strand cap-off, and during steady-state operation.In combination with other caster data, the strain signals can also be used to calibrate and validate continuous caster model predictions. These models can then be used with a higher degree of confidence to enhance control of the continuous casting process.FFT analysis of the strain data provides an on-line real-time system to monitor the condition of the rolls and the solidified strand during caster operation. The signals from the optical strain gauges have been shown to be capable of detecting the presence of bent or warped rolls and shell bulging during caster operation.Optical-fiber-based sensors have been used successfully for the first time ever to measure the strains that affect the roll loads in the segments of a continuous caster in a working steel plant. The measurement technique can be employed for several possible objectives:The viability of this optical fiber measurement method has been demonstrated in this short trial for identifying liquid core position movement for productivity tracking, soft reduction control, and model tuning along with other caster condition indicators that can be used to detect potential quality events, such as roll eccentricity and slab bulging. By monitoring the magnitude of these critical frequencies, critical thresholds can be set to identify internal quality issues before they become application-critical.


The lack of data outsourcing in healthcare management systems slows down the intercommunication and information sharing between different entities. A standard solution is outsourcing the electronic health record (EHR) to a cloud service provider (CSP). The outsourcing of the EHR should be performed securely without compromising the CSP functionalities. Searchable encryption would be a viable approach to ensure the confidentiality of the data without compromising searchability and accessibility. However, most existing searchable encryption solutions use centralised architecture. These systems have trust issues as not all the CSPs are fully trusted or honest. To address these problems, we explore blockchain technology with smart contract applications to construct a decentralised system with auditable yet immutable data storage and access. First, we propose a blockchain-based searchable encryption scheme for EHR storage and updates in a decentralised fashion. The proposed scheme supports confidentiality of the outsourced EHR, keyword search functionalities, verifiability of the user and the server, storage immutability, and dynamic updates of EHRs. Next, we implement a prototype using JavaScript and Solidity on the Ethereum platform to demonstrate the practicality of the proposed solution. Finally, we compare the performance and security of the proposed scheme against existing solutions. The result indicates that the proposed scheme is practical while providing the desired security features and functional requirements. Ever since the beginning of the Covid-19 pandemic, the healthcare industry has been the core and focus of the world to cope with the widespread of the disease. In fact, the pandemic has exposed the weaknesses of the current centralised approach for healthcare management  conducteThe emergence of blockchain technology with smart contract applications created a newly found decentralised platform for auditable yet immutable data storage and data access. In recent years, several studies proposed blockchain-based decentralised data storage systems –9. HowevWe propose a practical yet secured scheme called Blockchain-based Healthcare Management System with Two-side Verifiability (BHMV) that utilises SSE and blockchain network for EHRs management. Our proposed scheme uses smart contracts on the blockchain for EHR’s index storage and the searching process. BHMV supports confidentiality of the outsourced EHR and its index, keyword search functionalities, verifiability of the user and the server, storage immutability, and dynamic updates of EHRs. All these properties are supported throughout the EHR searching and retrieving phases. In particular, to achieve storage immutability, the encrypted search index is stored in the blockchain network, whereas the encrypted EHR data is stored in the Interplanetary File System (IPFS)—a peer-to-peer cloud storage platform. Advanced Encrypt Standard (AES) is used for the encryption purpose and digital signature is used for the verification of the authorised entities. A bitmap index is implemented in BHMV that supports dynamic data updates.A set of comprehensive simulations are conducted for performance assessment and security analysis of the proposed scheme. In terms of performance, the proposed scheme requires low developer effort to implement the system; hence, matching the objective of implementing a practical scheme for blockchain-based healthcare management system. Additionally, the encryption performance is efficient against a large set of EHR even with the simple and straightforward system design. Next, the BHMV scheme is relatively efficient during the EHR indexing phase in which the time required for indexing is approximately linear to the increasing EHR’s size. BHMV is a compact yet feature-packed scheme that can support two-side verifiability without compromising the performance and accessibility aspects of the outsourced EHR on the third-party storage. Overall, the proposed solution satisfies the desired security goals with a minimum trade-off in performance.The rest of the paper is organised as follows: Section 1.1 and 1.2 introduce the background of SSE and blockchain. Section 2 compares the related works in the area of blockchain-based data storage. Section 3 and 4 discuss the details of the proposed solution and its implementation. Section 5 provides the security and performance analyses of the proposed scheme. Finally, Section 6 concludes the paper.In traditional encryption, once the data is encrypted into ciphertext, it will limit the functionality and practicality of the data usage as the user cannot efficiently search or access the data. Hence, searchable encryption (SE) has been the interest to many researchers lately. SE allows users to perform a keyword search on the encrypted data by using a search token without exposing the content and search information. In a searchable encryption scheme:The data owner extracts useful information from the data before encrypting the data with the secret key.Constructs the index lookup table and encrypts it using the secret key.Upload the encrypted index and data/ciphertext to the cloud storage.The data owner can submit an encrypted query with a search token to search on the cloud server.The cloud server will perform the search process without learning the keyword and the data being searched.Encrypted data that satisfies the search function will be retrieved and returned back to the data owner.According to the definition given by Curtmola et. al. , SSE invp and returns a symmetric key K.Key generation algorithm that takes user’s security parameter I from the outsourced document D and the secret key K.Generates an encrypted index T as the search query by taking the generated symmetric key K and the user-input keyword w.Generates a trapdoor D that contain the keyword w defined in the trapdoor T. The search function takes the index I and the trapdoor T as the input and returns the search result R in the form of document pointer to the user as the output.Executes at the outsourced environment to search for the document The constructed index contains a pointer that can be used for locating the document after obtaining the search results. Additionally, SSE should protect the confidentiality of the outsourced documents, index, search query, search pattern and access pattern . SE is mBlockchain is formed by an open distributed ledger, in which the data is distributed and validated across the nodes based on a peer-to-peer (P2P) network . The datThe decentralised and distributed nature reduces the need for a trusted third party (TTP) as the participating nodes must reach a consensus for transaction verification and validation before storing it on the blockchain. There are mainly two types of consensus protocols: Proof-of-Work (PoW) and Proof-of-Stake (PoS) .Proof-of-Work: A block of transactions is validated by the miners competing to solve the cryptographic puzzle (hash function) by finding the random nonce and the block that holds the hash. The puzzle is considered solved if the calculated hash value of the next block starts with similar numbers of zero as the previous hash. Else, the miner will repeat the puzzle with different nonce values. The first miner who solved the puzzle will be awarded accordingly. This protocol requires immense computational power to solve the cryptographic puzzle since it is based on a trial-and-error approach.Proof-of-Stake: A block of transactions is validated by randomly chosen validators. The validators have to deposit an amount of stake in order to take part in the validation process. The validators with a higher amount of stake will have a higher chance of being chosen as the validators. The validators will be rewarded with the transaction fees inside the block and penalised if they validate a fraudulent transaction [nsaction .A single point of failure can be avoided as the P2P network acts as a redundant resource once any part of the system becomes unavailable. In addition, any transaction that happens on a blockchain is stored alongside immutable hash values from the previous block and the current block. A cryptographic hash function produces the hashes, and the purpose is to form a chain of the blocks that support non-repudiation and tamper-proof.With the emergence of smart contracts, the application of blockchain extends beyond just cryptocurrency. According to Iredale , many inBlockchain application research in the healthcare industry has been increasingly popular because blockchain storage can provide a durable medium for the EHR. This is because the data storage on the blockchain network is immutable, and any data modification can be easily detected by the new block created upon modification. Hence, data stored on the blockchain will subsequently become tamper-proof and support non-repudiation. In general, this section describes two different approaches of the blockchain implementation for data outsourcing.Storing the entire EHR on the blockchain network.Storing the EHR metadata on the blockchain network and outsourcing the EHR to third party cloud storage.SHAREChain was first proposed in 2019 . The ideGuo et al.  proposedAndola et al.  proposedChen et al.  proposedIn 2020, Asad et al.  proposedParameswari and Mandadi  proposedChelladurai and Pandian’s  scheme aWe emphasize that several other works propose schemes –23 that We introduce the model of the proposed scheme, Blockchain-based Healthcare Management System with Two-side Verifiability (BHMV). In the below sections, we discuss the functions and methods used in BHMV.In BHMV, we mainly focus on the implementation of Searchable Symmetric Encryption (SSE) in the healthcare management sector to secure the confidentiality of the Electronic Health Record (EHR) without compromising its usability and accessibility. For enabling searchability over encrypted EHR, a bitmap index is constructed in the data pre-processing stage. The searchable encryption implemented in BHMV uses the Cipher-Block Chaining (CBC) encryption mode of the Advanced Encryption Standard (AES) algorithm.To realise two-side verifiability, Elliptic Curve Digital Signature Algorithm (ECDSA) is used to safeguard the authenticity of the searched query or returned result. However, ECDSA requires a digitally signed certificate issued by a Trusted Third Party (TTP) or a Certificate Authority (CA). The purpose of the digital certificate is to vouch for the validity of the ECDSA public key. Generally, the certificate contains the user’s public key, user ID, the certificate issue date and the expiration date. This approach is not optimal as it increases the degree of point of failure since the TTP or CA might be a constant primary target for the attacker to compromise the whole system. Furthermore, the renewal or revocation of a certificate is relatively inefficient if the system is required to process a large number of datasets .To limit the number of entities involved in the system, the TTP is replaced by a blockchain network such as Bitcoin or Ethereum. Authorised users can share their ECDSA public keys using the smart contracts on the blockchain. Modifying any block of the data on the blockchain will not overwrite the previous data. Instead, a new block is being mined and chained to the previous block. Any metadata such as account address, timestamp, and previous hash value will be stored in the new block. Therefore, any malicious attempt carried out by the attacker will be recorded in the blockchain forever. As a result, the details of the attacker are traceable for further investigation or access blacklisting. Hence, the ECDSA public key is immutable from intentional corruption and the recorded malicious block can be used as the proof of attack against the attacker’s blockchain account.Additionally, BHMV is using the blockchain distributed ledger to store the encrypted bitmap index and verify the search requests from the authorised user. Blockchain storage can ensure the integrity of the index and consequently ensure the search result to be accurate. The returned search result is also authenticated using the ECDSA signature.In our proposed scheme, all the uploaded EHRs will be indexed before encryption takes place. A bitmap index is implemented in BHMV to store the extracted keyword with its corresponding EHR unique pointer or identifier. A bitmap index is an index matrix that allows the system to search among the encrypted keywords and locate the EHR. The extracted keyword represents the row key of the matrix while the EHR identifier represents the column key of the matrix. The values stored are Boolean values, consists of only “0” and “1”; where “0” stands for the absence of a particular keyword in a particular EHR while “1” represents the presence of the keyword. As illustrated in A smart contract is a self-executable program that can be deployed on the blockchain network. In fact, the smart contract is firstly used for the transaction of cryptocurrencies, a newly found digital representation of the monetary system. Transaction will be executed automatically when a predefined set of conditions are met. The execution of transactions via smart contract is reliable because all the transactions are recorded and irreversible. In our scheme construction, a smart contract is used for uploading and searching the bitmap index aforementioned. The smart contract used for index searching also supports ECDSA digital signature verification to prevent any malicious party from gaining access or altering the search token and its corresponding result. To reduce the single point of failure in the scheme, blockchain implementation can minimise the entities involved in the system.The framework of the proposed BHMV scheme is depicted in EHR owner: The entity that holds the original data of EHR. The EHR owner is responsible for extracting the keywords and building the corresponding index from the EHR. After that, the owner will encrypt the EHR and its index and upload them to the cloud storage and blockchain network, respectively. The smart contracts used in the blockchain must be deployed by the owner beforehand.EHR user: The entity that generates the search token as a query to search and access the EHR. EHR users must be authorised by the EHR owner unless the EHR owner and EHR user are the same entity.Cloud service provider (CSP): This entity is responsible for storing the encrypted EHR that is outsourced by the EHR owner. The search result obtained is used to retrieve the EHR from the cloud service provider.Blockchain network: Smart contract is used for public key management and index searching. The index is uploaded by the EHR owner and stored safely inside the blockchain as a block of data. Any entity who wishes to search the EHR needs to get access information from the smart contract owner, i.e., the EHR owner.The proposed model of BHMV consists of five stages of operation: System Setup, EHR Pre-processing, EHR Storage, EHR Searching and Access, and Access Revocation.System setup: This stage initialises all the components or parameters required before the EHR is being outsourced to the CSP. First of all, the EHR owner initiates the key generator to generate a pair of secret keys  for EHR encryption in the data storage stage. EHR owner and users generate a pair of ECDSA public and private keys  for the usage of entity authentication. At the same time, CSP will also generate a pair of ECDSA public and private keys  for authentication purposes.EHR pre-processing: EHR owner has to build an index and encrypt the EHR before uploading it to the offshore storage space. In this stage. the owner extracts the keywords set from each EHR and indexes the EHR accordingly so that the EHR user can search for the EHR later on in the searching stage. The index in this scheme is created using the bitmap index as it can efficiently support dynamic data updates. Note that the bitmap index built in this stage is temporary and not in the final form yet.EHR storage: The owner encrypts the EHR with the symmetric key K1 and then uploads the EHR ciphertext to Interplanetary File System (IPFS), which is a peer-to-peer cloud storage platform. The bitmap index is encrypted using another symmetric key K2 and uploaded to the blockchain for immutable storage.EHR searching and access: The authorised users have the authority to access the blockchain network and use the smart contract to search the particular keyword they are interested in. The search token generated needs to be authenticated with the digital signature before searching the bitmap index matrix. The returned result requires to pass the authentication test to realise the two-side verification process proposed in this scheme.Access revocation: In the case of revoking user access from EHR, the data owner deletes the user’s ECDSA public key pair from the blockchain. Since the search token requires ECDSA authentication, the search token from the revoked user will fail the test. As a result, the revoked user loses access to the EHR and the index stored on the blockchain.The processes involved in the proposed scheme are illustrated in Step 1: The EHR owner compiles and migrates the smart contracts to the blockchain and receives the contract address and Application Binary Interface (ABI) for access usage.Step 2: The EHR owner uploads the established ECDSA public keys to the blockchain for sharing and ensuring the integrity of the public key.K1 and uploads the EHR ciphertexts to the IPFS.Step 3: After indexing the EHR, the owner encrypts the EHR with the symmetric key Step 4: The hash value from IPFS is recorded as the identifiers for each EHR. Hence, the temporary bitmap index from the previous stage will be updated by replacing the matrix’s column with the file hash.K2 and uploaded to the blockchain for immutable storage.Step 5: The bitmap index is encrypted using the other symmetric key Step 6: The EHR user acquires permission from the EHR owner by sending an access request to the owner alongside his or her ECDSA public key.Step 7: If the owner approves the request, the smart contract address and ABI will be sent to the user.Step 8: The EHR owner stores the approved user’s ECDSA public key in the authorised user control list via smart contract.K1, K2) used for search token generation and EHR decryption.Step 9: The owner will then retrieve the user’s ECDSA public key and encrypt the EHR and index’s symmetric keys using the user’s ECDSA public key. Then, the owner sends the symmetric keys ciphertext to the user. The EHR user decrypts the received ciphertext with his or her ECDSA private key to obtain the symmetric keys  user’s ECDSA public key pair from the authorised user list on blockchain.This section provides a detailed look at the construction of the Blockchain-based Healthcare Management System with Two-side Verifiability (BHMV). Sect. 4.1 introduces the notations and symbols used to describe our construction. Sect. 4.2 discusses the operations involved in system setup; while Sect. 4.3 elaborates the electronic healthcare record (EHR) pre-processing. Next, Sect. 4.4 describes the EHR storage in an outsourced environment. Sect. 4.5 discusses the specific design and algorithms used for EHR searching and access. Then, Sect. 4.6 provides technical details on the verification of the digital signatures. Finally, Sect. 4.7 discusses the implementation details.A list of all the notations and symbols used in this paper with its corresponding description is provided below.KeyGen: Cryptographic key generatorK1, K2: Searchable symmetric encryption keysp1, p2: Randomly generated passphrasesiv: Initialisation vectorENC: Searchable symmetric encryptionDEC: Searchable symmetric decryptionPKU, SKU: User’s public and secret keyPKS, SKS: Server’s ECDSA public and secret keyM: Bitmap index matrixcij: Matrix’s cell at row i column jhj: File hash value at column j in the bitmap matrixw: Encrypted keywordW: Encrypted keywords set stored on the BlockchainCEHR: EHR ciphertextCM: Bitmap index matrix ciphertextH: Hash functionHASH: Hash value output from the hash functionSIGN: ECDSA signature functionTw: Search tokenTag: ECDSA signature/verification tagR: Search resultECREC: ECDSA signature recovery functionRecTag: Recovered value of ECDSA signatureε: An empty stringSince searchable symmetric encryption is used for preserving EHR’s confidentiality, the EHR owner initialises the security parameters as two randomly generated passphrases. Next, the owner passes the passphrases into the key generator for generating two unique symmetric encryption keys. Two different symmetric keys are assigned for EHR file encryption and index encryption, respectively.For realising two-side verification, EHR owner and cloud service provider (CSP) generate their pair of Elliptic Curve Digital Signature Algorithm (ECDSA) public and private key and initialise a Keccak-256 hash function.After initialising all the required security parameters, the EHR owner will migrate and deploy the smart contracts on the Ethereum blockchain network. The owner will in turn receive the smart contracts metadata that is required to access and communicate with the contracts on the blockchain network.To realise searchability, the EHR has to be indexed first before being encrypted and outsourced to a third-party storage. EHR owner generates the index according to the steps shown in Algorithm 1. Firstly, the keyword extractor will be initialised and configured based on different criteria such as the input text language and the removal of digits and the stop word set. After the configuration, the tokeniser scan and tokenise the EHR content into a collection of discrete text strings known as token. After that, the keyword extractor filters the unnecessary tokens by comparing the token with the pre-configured stop word set. The stop word set consists of common texts, clauses or numbers that are not necessary for indexing the EHR.Algorithm 1: BuildBitmapIndex1 Initialise index writer2 Configure the analyser for the index writerM for bitmap index3 Initialise a matrix foreach EHRdo4 5  Breakdown the text field into tokens6  Extract and index the tokenw to the matrix row7  Attach keyword hj to the matrix column8  Attach file hash ifwi ∈ EHRjthen9  cij in M = 110   cell else11  cij in M = 012   cell returnM13 Next, Algorithm 1 initialises a two-dimensional array as a matrix for storing the information about the EHR’s index. The encrypted keywords are attached to the first column of the matrix; while the hash value of the EHR returned by the Interplanetary File System (IPFS) storage is attached to the column of the matrix, representing the column identifier. Lastly, the algorithm will check the presence of each keyword in the particular EHR and fill the cells with “1” if the keyword is present in the file; otherwise, it will remain “0”.iv as the input for the encryption to prevent the repetition of ciphertext generated from the similar plaintext encryption. The iv generated consists of 16 bytes of randomised block. CryptoJS library is used to generate the iv as well as the 256-bit symmetric keys K1, K2. Next, the EHR owner encrypts the EHR with the iv and the symmetric key K1 generated during the system setup phase.The application converts the EHR to Uint8Array buffers and passes the file buffers to the encryption function for encryption. The encryption function encrypts the EHR buffers with the iv and K1. The ciphertext is generated in word arrays format and the word arrays are converted back to Uint8Array buffers before returning to the application. After the EHR encryption, the owner uploads the EHR ciphertext CEHR to IPFS for storage outsourcing. IPFS returns the file hash as the EHR identifier. The EHR owner completes the construction of bitmap index M by inserting the file hash to the first row as the document identifier. The keyword encryption encrypts the keywords with another symmetric key K2. The keywords inside the bitmap index are encrypted one by one by looping through the keyword’s arrays. That is, the encryption of the EHR and the bitmap matrix are computed as:AES-CBC mode is used as the underlying encryption algorithm. Therefore, the EHR owner generates an initialisation vector CEHR is uploaded to the IPFS. The bitmap index ciphertext CM is then uploaded to the distributed ledger on the blockchain.Next, the owner accesses the Ethereum blockchain network by smart contract using the contract address and Application Binary Interface (ABI). The EHR ciphertext CM on the blockchain, the user needs to generate a search token first. Firstly, the user enters a keyword w to search the EHRs containing the keyword w. The steps of search token generation are illustrated in Algorithm 2. The algorithm encrypts the query keyword with secret key K2 to generate the search token. Next, the search token is hashed with the Keccak256 hash function to generate a fixed length of 64-byte hash. The algorithm generates the search token tag Tagw by signing the output hash value with the user’s ECDSA secret key SKU. Lastly, the search token Tw and search token tag Tagw are returned to the user.In a single-user use case, the owner and the user of the EHR are the same entity. In a multi-user use case, the EHR user has to obtain permission and authorisation from the EHR owner before searching and accessing the outsourced EHR data. For searching the encrypted bitmap index Algorithm 2: Search Token GenerationInput: The query keyword w, EHR encryption key K2, and user’s ECDSA secret key SKUOutput: Search token Tw and search token tag TagwTw = ε and Tagw = ε1 Initialise 2 HASHw ← HKeccak256(Tw)3 4 returnTw and Tagw5 R for storing the search result temporarily. If the search token signature Tagw is valid, the algorithm will compare the search token Tw to the encrypted keyword w in the bitmap index M. If the search token Tw appears in the list of encrypted keywords set W, the index searching module iterates the bitmap index at that particular keyword row to identify which EHR contains the searched keyword. If the value for a particular cell cij is “1”, the corresponding column identifier value is added to the array of search result R. At the end of the searching, the smart contract will hash and sign the search result R to realise the two-side verifiability.After obtaining the search token, the user accesses the search function in the smart contract to query the EHR index stored on the blockchain. The smart contract will verify the validity of the search token signature first before initiating the index search function. Only search tokens from valid or authorised users can be used to search the index and return the corresponding result. The steps for index searching are illustrated in Algorithm 3. The algorithm initialises an empty array Algorithm 3: IndexSearchInput: Encrypted bitmap index CM, search token Tw and tag token Tagw generated by the EHR userOutput: Search result R and search result tag TagRTw using Tagw1 Verify the validity of R and TagR2 Initialise an empty array for storing ifvalidthen3 foreach keyword w in keywords set Wdo4  ifand cell cij == 1 then5   R ← R∪hj6    set HASHR ← HKeccak256(R)7  8  returnR and TagR9 m and stores it as HASHm. Next, it uses the hash output and the signature as the parameter for the elliptic curve recovery function ECREC. The ECREC function is the class function provided in the Solidity cryptographic library. The purpose of using this function is to recover the signature’s origin public address in order to verify whether the message signer is administered inside the user access list. The recovered value returned from the ECREC function is compared with the sender’s public key/address for verification. The verification function will return true  if matches and proceed to search or EHR decryption depending on the use case. On the contrary, the verification function will return false  if the value returned does not match, reject the search token or the search result.For verifying the authenticity of the search token signature and search result signature, we use the ECDSA verification function. Algorithm 4 demonstrates the steps in the verification function for achieving the purpose of message origin validation. At first, the algorithm hashes the input message Algorithm 4: VerificationInput: The input message m (search token Tw or search result R) and the corresponding message tag Tagm (Tagw/TagR)Output: Boolean value of true or falseRecTag1 Initialise recovered signature variable HASHm ← HKeccak256(m)2 RecTag ← ECREC3 ifRecTag == sender’s addressthen4 return true5  else6 return false7  The proposed BHMV scheme is implemented on a Windows 10 (64-bit) machine with an Intel Core i5-7300HQ processor, NVIDIA GeForce GTX 1050 graphic card, and 8 gigabytes (GBs) of random-access memory (RAM). The programming languages used for the implementation are JavaScript, Hypertext Markup Language (HTML), and Solidity.The environment is set up using Node.js, which is a run-time environment for compiling and executing the written JavaScript programs. The libraries used in the project are installed using Node Package Manager (NPM) in the form of an NPM registry. NPM is an open-source platform for software distribution and dependencies management. For EHR storage outsourcing, IPFS is used as the peer-to-peer distributed storage solution. IPFS hashes the uploaded EHR and stores the hash values using a distributed hash table (DHT). Then, IPFS distributes the hash keys to participating peers’ nodes on the distributed network. In the proposed scheme, the hash keys are stored on the blockchain as the EHR index, making the hash keys immutable and traceable for any malicious modification attempt. Ethereum is used as the medium for the blockchain network implementation in BHMV. Our scheme develops the smart contracts using Remix IDE with Solidity programming language. The smart contracts are compiled and deployed using the Truffle Suite framework.Dummy Ethereum accounts with free test Ether (ETH) cryptocurrency are created using the Ganache component provided inside the Truffle Suite package. Ether is the virtual currency used in Ethereum for the transaction to monetise the miner nodes. Ganache is a personal blockchain network that supports efficient Ethereum decentralised application development. Each account is credited with 100 test ETH and the address is the account identifier, also the public key for digital signature verification during the Ethereum transaction. To spend and use the Ether coin, Metamask cryptocurrency wallet is used to finance the transaction. The users can connect their account with the Metamask wallet using the Ethereum account private key. Whenever the owner wants to upload or search an EHR, a transaction is called from the smart contract to store or search the bitmap index on the Ethereum blockchain. Hence, all these transactions are recorded with the transaction hash, sender’s account and contract’s address.This section assesses the security level and the performance evaluation of the proposed Blockchain-based Healthcare Management System with Two-side Verifiability (BHMV) scheme. Security analysis discusses the properties that can be satisfied in the proposed scheme for achieving the security goals. Performance evaluation tests the BHMV implementation to assess the performance-related results for system efficiency analysis. In feature comparison section, we compare the features of BHMV against the different solutions proposed in the existing literature.Security is the utmost important aspect when the patients are sharing their healthcare records. The confidentiality and integrity of the Electronic Health Record (EHR) need to be protected at all costs against the attack from malicious parties. Hence, we inspect the security level of BHMV based on the three security goals and the corresponding proof of work.The cloud storage and server should not gain any knowledge from the outsourced EHR on their premises. Apart from that, suppose an adversary breaches the cloud storage and obtains the EHR, the adversary should not be able to read or carry out a known ciphertext attack to obtain any knowledge from the EHR.In the BHMV scheme, symmetric encryption is used to encrypt all the EHRs before outsourcing them to third-party online storage. The EHRs are encrypted with a user-defined secret key using a 256-bit Advanced Encryption Standard Cipher-Block Chaining (AES-CBC) encryption algorithm. As a result, the adversary cannot decrypt and read the EHR ciphertext without the EHR owner’s symmetric key. Additionally, the initialisation vector used for encryption can hide the ciphertext pattern by adding the random factor to each block of the cipher. Therefore, encrypting an identical block of plaintext will not result in the identical ciphertext that may reveal the ciphertext pattern to the adversary.Notice that the entries of the bitmap index are computed with a different secret key. The separate keys prevent any similarities between the encrypted keyword matrix and the EHR ciphertext. The document identifiers in the bitmap index are created from the file hash values, preventing leaking any information about the document. The search of the encrypted keyword is done in the blockchain—a separate network from the database where the EHR ciphertext is stored. As a result, the cloud service provider would not gain any information between the search token and search result. Finally, the underlying communication channel is assumed to have additional protection in place under the protocol level, such as SSL/TLS. This will prevent adversaries from obtaining any link between the searches and the search results from different sessions, even if they were aware  of the past searched keyword and search results. As a result, the BHMV scheme should be secure against adaptively chosen keyword attacks. Under the circumstances, the confidentiality of the outsourced EHR is safeguarded against the adversary.T or the search result R transmitted from the user-side or the server-side. The man-in-the-middle adversary tampers with the message and signs a new Elliptic Curve Digital Signature Algorithm (ECDSA) digital signature based on the hash value of the modified message. Upon receiving the modified message, the digital signature will fail the verification test and the message will be discarded.Consider an intermediate party intersects and modifies the search token HECDSA used is collision-resistant, the adversary is unable to forge an ECDSA digital signature under a chosen message attack. Therefore, the adversary cannot carry out a man-in-the-middle attack for spoofing as a legitimate user due to the two-side verifiability.In the EHR searching phase, the search request from the user and the search result from the server are needed to be verified and authenticated with an ECDSA signature. If the signer’s ECDSA public key is not present in the access list on the blockchain, the recovered ECDSA signature will automatically fail the verification process. Moreover, if the hash function BHMV provides a durable medium for storing the EHR safely even in the outsourced environment. Assuming an adversary gains access and tries to modify the EHR on the Interplanetary File System (IPFS) storage, the malicious modification attempt of the EHR can be easily identified and prevented. The EHR index used for searching is also tamper-proof from any malicious party who tries to breach the search result accuracy by tampering with the EHR index.HIPFS used by IPFS storage, any minor modification in the EHR will result in an extensively new hash value. By comparing the modified EHR hash value to the original EHR hash value stored on the Ethereum blockchain, the attempt of EHR modification can be easily identified. In addition, the hash function used is collision-resistant, in which it is infeasible for the adversary to compute the same hash value with the modified EHR′. Given EHR ≠ EHR′, it is computationally infeasible to find H(EHR) = H(EHR′). Since the index of the EHR is stored on the distributed ledger of the Ethereum blockchain, the index storage is inherently supporting tamper-proof and non-repudiation properties from the characteristics of the blockchain storage. Consequently, the data storage of the EHR and its corresponding index satisfies the storage immutability property.Given the hash function Personal healthcare records are considered as highly sensitive data, the availability of EHR datasets in public is limited due to the permission required from relevant ethical bodies. Due to such constraints, this research only uses publicly available dummy EHR datasets that are artificially generated from the EMRBOTS website . Inside We tested the implemented system to determine the efficiency of the propose searchable encryption scheme. The encryption algorithms used in both this work and the work of Wang, Zhang and Zhang use the AES encryption algorithm. The results show that BHMV has comparatively better performance; we believe this could be due to several factors, including the implementation environment and the modes of operation of the cipher. For reference, the system implementations of the comparing schemes were implemented in a computing environment with an Intel Core i5-7200U processor, 4 gigabytes (GBs) of random-access memory (RAM). The Java programming language was used for the implementation of these two schemes. In contrast, our system was implemented using JavaScript; the computing environment details of our implementation are provided in Section 4.7. Therefore, the result is partially subject to the CPU parameters, programming language and encryption algorithm variables. Additionally, the performance of both our scheme and the scheme of Wang, Zhang and Zhang is significantly high compared to the scheme of Wang and Song, especially when the file size is large. This is because Wang and Song’s approach uses an attribute-based encryption (ABE) algorithm that is computationally more expensive and requires a longer encryption time. This comparison also shows the general performance advantage of using symmetric cipher compared to asymmetric cipher such as the ABE algorithm.The performance recorded from the execution of the index builder module is shown in We compare the functionalities of our proposed scheme against the existing Blockchain-based cloud storage solutions. The comparison details provided in All of the schemes support a certain level of user-side verifiability in terms of the EHR retrieved from the third-party storage. However, the verification is solely based on the assurance of integrity provided by the hash value from the blockchain. Man-in-the-middle or spoofing attempt is still plausible to be deployed to deceive the user. Our proposed scheme, BHMV mitigates the issue by adding another layer of security using the ECDSA signature. Both server-side and user-side can verify the message they received from each other.Even though the schemes proposed by Al Asad et al. and Parameswari et al. , 8 suppoMost of the studied schemes do not address the support for dynamic EHR update. In the scheme proposed by Chelladurai and Pandian , EHR updWe proposed a Blockchain-based healthcare management system with two side verifiability (BHMV) to reduce the gap between the proposed existing solutions and real-life implementation. The proposed solution is lightweight yet secured. BHMV combines the benefits provided by blockchain technology with the cryptographic system to construct a secure and convenient platform for EHR storage and sharing.The encryption algorithm for the proposed system uses a state-of-the-art encryption algorithm: Advanced Encryption Standard. For implementing the two-side verifiability feature, Elliptic Curve Digital Signature Algorithm (ECDSA) is used to sign and verify the signature’s authenticity. ECDSA verification is required during the EHR searching and access phases. A private blockchain network is implemented in the BHMV scheme to eliminate a Trusted Third Party (TTP) requirement. The construction of the bitmap index allows for a dynamic searchable symmetric encryption in which the index can be updated easily by changing the tuple’s value of a particular keyword. The process of splitting the storage by storing only the bitmap index on the blockchain is aimed to reduce the transaction fee that may incur if we include large datasets, such as the whole EHR on the blockchain ledger. The results obtained from the prototype developed are promising with efficient indexing and encryption rate against large EHR files. The high-efficiency performance complies with the security goals of confidentiality, immutability and two-side verifiability.To conclude, blockchain application in the healthcare industry is plausible and practical. It natively support various security requirements. We have incorporated the notions of searchable symmetric encryption (SSE), ECDSA digital signature, and blockchain technology to implement a secure yet practical prototype to be deployed in the healthcare industry.