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