Page 349 - Special Topic Session (STS) - Volume 4
P. 349

STS1080 Asma A. et al.
                Due to data immutability, data can remain accurate on each peer’s ledger
            but fails to comply with the GDPR’s right to be forgotten. Unlike HIPAA, the
            GDPR  states  individuals  have  the  right  to  erasure  which  Purging  data
            Scenario  examines.  Hyperledger  Composer  allows  participants  to  “delete”
            data. Superficially, it seems that Hyperledger complies with the GDPR and can
            delete data. However, Hyperledger Composer is simply a higher-level toolset
            which runs on top of Hyperledger Fabric. Transactions are simply marked as
            deleted  and  appear  that  way  in  Composer  but  on  the  Fabric  level,  the
            transaction remains unchanged. If Fabric is the network level; Composer would
            be  the  application  layer.  To  cooperate  with  regulations,  Hyperledger-built
            applications must not store any sensitive data and it is recommended that all
            personal data should be stored in an off-chain database.
                HIPAA and the GDPR enforce consent through, ‘authorisation’ and ‘right
            to be informed’ respectively. Though the GDPR takes it a step further and
            requires individuals to be notified if there are any changes regarding access
            or  purpose.  Data  type  scenario  demonstrates  this  right  by  recording  the
            reason for referral in each transaction. Patients can see why specific medical
            practitioners  access  to  their  EHR  have  by  checking  their  transaction  list.
            Without this feature implemented, patients who are able to track who has
            access to their EHR but be ignorant of the purpose behind it.
                HIPAA requires safeguards to be put in place in order to protect patients
            from data leaks. However, the shared ledger displayed in the Basic Scenario
            potentially poses a problem for the requirement of physical safeguards. Is it
            possible  to  apply  physical  restrictions  on  each  peer?  In  a  full-scale
            implementation,  it  would  be  impossible  to  ensure  that  each  device  was
            physically secured.

            2.3. Hyperledger test analysis – scalability and flexibility
                Testing  revealed  that  hyperledger  is  not  very  flexible  and  expects
            functionality to be carried out the application side. Hyperledger is designed to
            deal with only text-based data, there is no innate support for images or audio
            as  shown  in  encryption  scenario.  Data  type  scenario  shows  that
            Hyperledger can cope with images but only with some outside interference.
            Within the scenario, a theoretical application on top of the blockchain converts
            the image to base64 which can then be stored on the blockchain. Hyperledger
            does  not  deal  with  data  in  any  unique  way  and  is  unaffected  by  base64.
            Alternatively, an image could be stored in a database and the reference could
            be  stored  within  Hyperledger  but  that  adds  another  layer  of  complexity.
            Hyperledger’s  reluctance  to  support  non-text-based  data  reinforces  the
            notion  that  Hyperledger  wants  data  to  be  stored  in  an  external  database.
            Ultimately, storing images in base64 isn’t a major issue for healthcare. Base64
            does  not  reduce  any  quality  that  physicians  may  need  to  see  but  simply
            changes the way the data is represented whilst compressing data. Hyperledger

                                                               338 | I S I   W S C   2 0 1 9
   344   345   346   347   348   349   350   351   352   353   354