Human Factors in System Design

This paper discusses the importance of human factors in system design, specifically in the context of healthcare and medical research. It explores the use of blockchain technology to manage electronic health records (EHRs) and introduces MedRec, a decentralized record management system. The system aims to provide patients with easy access to their medical information across providers and treatment sites, while ensuring authentication, confidentiality, accountability, and data sharing. The paper also discusses the components of the system and its potential impact on healthcare and research.

Running head: HUMAN FACTORS IN SYSTEM DESIGN
HUMAN FACTORS IN SYSTEM DESIGN
Name of the Student:
Name of the University:
Author Note:

1HUMAN FACTORS IN SYSTEM DESIGN
Executive Summary
A long-standing focus on compliance has traditionally constrained development of fundamental
design changes for Electronic Health Records (EHRs). We now face a critical need for such
innovation, as personalization and data science prompt patients to engage in the details of their
healthcare and restore agency over their medical data. In this paper, we propose MedRec: a
novel, decentralized record management system to handle EHRs, using blockchain technology.
Our system gives patients a comprehensive, immutable log and easy access to their medical
information across providers and treatment sites. Leveraging unique blockchain properties,
MedRec manages authentication, confidentiality, accountability and data sharing—crucial
considerations when handling sensitive information. A modular design integrates with providers'
existing, local data storage solutions, facilitating interoperability and making our system
convenient and adaptable. We incentivize medical stakeholders (researchers, public health
authorities, etc.) to participate in the network as blockchain “miners”. This provides them with
access to aggregate, anonymized data as mining rewards, in return for sustaining and securing
the network via Proof of Work. MedRec thus enables the emergence of data economics,
supplying big data to empower researchers while engaging patients and providers in the choice to
release metadata. The purpose of this paper is to expose, in preparation for field tests, a working
prototype through which we analyze and discuss our approach and the potential for blockchain in
health IT and research.

2HUMAN FACTORS IN SYSTEM DESIGN
Table of Contents
Introduction......................................................................................................................................3
Discussion:.......................................................................................................................................4
What is Blockchain? How it works?...........................................................................................5
Use cases or components of the system.......................................................................................6
1. Registrar contract (RC).................................................................................................6
2. Patient Provider Relationship contract (PPR)...............................................................7
3. Summary contract (SC).................................................................................................8
4. System node description................................................................................................9
5. Backend API library......................................................................................................9
6. Ethereum client............................................................................................................10
7. Database keeper...........................................................................................................10
8. EHR Manager..............................................................................................................11
9. MedRec blockchain mining.........................................................................................11
Usability requirements...............................................................................................................11
Evaluation of the software (Methods and Procedure)...............................................................13
Conclusion and Findings...............................................................................................................15
References:....................................................................................................................................17

3HUMAN FACTORS IN SYSTEM DESIGN

4HUMAN FACTORS IN SYSTEM DESIGN
Introduction
Today’s e-hospital management environment requires that interactive systems exhibit abilities
such as autonomy, adaptive and collaborative behavior, and inferential capability. Such abilities
are based on the knowledge about users and their tasks to be performed. To adapt users’ input
and tasks an interactive system must be able to establish a set of assumptions about users’
profiles and task characteristics, which is often referred as user models. However, to develop a
user model an interactive system needs to analyze users’ input and recognize the tasks and the
ultimate goals users trying to achieve, which may involve a great deal of uncertainties.
The interactive system chosen in this report is the use of blockchain in healthcare used for
accessing data in electronic health records (EHR) and medical research. The data is easily
available to patients and is high protected and securely kept via the blockchain security
measures. EHRs were never designed to manage multi-institutional, life time medical records.
Patients leave data scattered across various organizations as life events take them away from one
provider's data silo and into another. In doing so they lose easy access to past data, as the
provider, not the patient, generally retains primary stewardship (either through explicit legal
means in over 21 states, or through default arrangements in the process of providing care).
Through the HIPAA Privacy Rule, providers can take up to 60 days to respond (not necessarily
to comply) to a request for updating or removing a record that was erroneously added. Beyond
the time delay, record maintenance can prove quite challenging to initiate as patients are rarely
encouraged and seldom enabled to review their full record. Patients thus interact with records in
a fractured manner that reflects the nature of how these records are managed.

5HUMAN FACTORS IN SYSTEM DESIGN
Our blockchain implementation addresses the four major issues highlighted above: fragmented,
slow access to medical data; system interoperability; patient agency; improved data quality and
quantity for medical research. We build on the work of Zyskind et al. to assemble references to
data and encode these as hashed pointers onto a blockchain ledger. We then organize these
references to explicitly create an accessible bread crumb trail for medical history, without storing
raw medical data on the blockchain. Our system supplements these pointers with on-chain
permissioning and data integrity logic, empowering individuals with record authenticity,
auditability and data sharing. We build robust, modular APIs to integrate with existing provider
databases for interoperability. A novel data-mining scheme is proposed to sustain the MedRec
network and bring open, big data to medical researchers. We present MedRec not as the panacea
for medical record management, but as a foray into this space to demonstrate innovative EHR
solutions with blockchain technology.
Discussion:
For MedRec, the block content represents data ownership and viewership permissions shared by
members of a private, peer-to-peer network. Blockchain technology supports the use of “smart
contracts,” which allow us to automate and track certain state transitions (such as a change in
viewership rights, or the birth of a new record in the system). Via smart contracts on an
Ethereum blockchain, we log patient-provider relationships that associate a medical record with
viewing permissions and data retrieval instructions (essentially data pointers) for execution on
external databases. We include on the blockchain a cryptographic hash of the record to ensure
against tampering, thus guaranteeing data integrity. Providers can add a new record associated
with a particular patient, and patients can authorize sharing of records between providers. In both
cases, the party receiving new information receives an automated notification and can verify the

6HUMAN FACTORS IN SYSTEM DESIGN
proposed record before accepting or rejecting the data. This keeps participants informed and
engaged in the evolution of their records.
MedRec prioritizes usability by also offering a designated contract which aggregates references
to all of a user's patient-provider relationships, thus providing a single point of reference to check
for any updates to medical history. We handle identity confirmation via public key cryptography
and employ a DNS-like implementation that maps an already existing and widely accepted form
of ID (e.g. name, or social security number) to the person's Ethereum address. A syncing
algorithm handles data exchange “off-chain” between a patient database and a provider database,
after referencing the blockchain to confirm permissions via our database authentication server.
What is Blockchain? How it works?
Originally designed for keeping a financial ledger, the blockchain paradigm can be extended to
provide a generalized framework for implementing decentralized compute resources. Each
compute resource can be thought of as a singleton state-machine that can transition between
states via cryptographically-secured transactions. When generating a new state-machine, the
nodes encode logic which defines valid state transitions and upload it onto the blockchain. From
there on, the blocks journal a series of valid transactions that, when incrementally executed with
the state from the previous block, morph the state-machine into its current state. The Proof of
Work consensus algorithm and its underlying peer-to-peer protocol secure the state-machines'
state and transitioning logic from tampering, and also share this information with all nodes
participating in the system. Nodes can therefore query the state- machines at any time and obtain
a result which is accepted by the entire network with high certainty.
This transaction-based state-machine generalization of the blockchain is informally referred to as
smart contracts. Ethereum is the first to attempt a full implementation of this idea. It builds into

7HUMAN FACTORS IN SYSTEM DESIGN
the blockchain a Turing-complete instruction set to allow smart-contract programming and a
storage capability to accommodate on-chain state. We regard the flexibility of its programming
language as an important property in the context of EHR management. This property can enable
advanced functionality (multi-party arbitration, bidding, reputation, etc.) to be coded into our
proposed system, adapting to comply with differences in regulation and changes in stakeholders
needs.
We utilize Ethereum's smart contracts to create intelligent representations of existing medical
records that are stored within individual nodes on the network. We construct the contracts to
contain metadata about the record ownership, permissions and data integrity. The blockchain
transactions in our system carry cryptographically signed instructions to manage these properties.
The contract's state- transition functions carry out policies, enforcing data alternation only by
legitimate transactions. Such policies can be designed to implement any set of rules which
govern a particular medical record, as long as it can be represented computationally. For
example, a policy may enforce that separate transactions representing consent are sent from both
patients and care providers, before granting viewing permissions to a third party.
Use cases or components of the system
1. Registrar contract (RC)
This global contract maps participant identification strings to their Ethereum address identity
(equivalent to a public key). We intentionally use strings rather than the cryptographic public key
identities directly, allowing the use of already existing form of ID. Policies coded into the
contract can regulate registering new identities or changing the mapping of existing ones.
Identity registration can thus be restricted only to certified institutions. The RC also maps

8HUMAN FACTORS IN SYSTEM DESIGN
identity strings to an address on the blockchain, where a special contract described below, called
the Summary Contract, can be found.
2. Patient Provider Relationship contract (PPR)
A Patient-Provider Relationship Contract is issued between two nodes in the system when one
node stores and manages medical records for the other. While we use the case of care provider
and patient, this notion extends to any pairwise data stewardship interaction. The PPR defines an
assortment of data pointers and associated access permissions that identify the records held by
the care provider. Each pointer consists of a query string that, when executed on the provider's
database, returns a subset of patient data. The query string is affixed with the hash of this data
subset, to guarantee that data have not been altered at the source. Additional information
indicates where the provider's database can be accessed in the network, i.e. hostname and port in
a standard network topology. The data queries and their associated information are crafted by the
care provider and modified when new records are added. To enable patients to share records with
others, a dictionary implementation (hash table) maps viewers’ addresses to a list of additional
query strings. Each string can specify a portion of the patient's data to which the third party
viewer is allowed access.
Our prototype demonstrates this design with SQL data queries. In a simple case, the provider
references the patient's data with a simple SELECT query conditioned on the patient's address.
For patients, we designed a tool which allows them to check off fields they wish to share through
our graphical interface. Under the hood, our system formulates the appropriate SQL queries and
uploads them to the PPR on the blockchain. Note that by using generic strings our design can
robustly interface with any string queried database implementation. Hence, it can conveniently
integrate with existing provider data storage infrastructure. At the same time, patients are

9HUMAN FACTORS IN SYSTEM DESIGN
enabled with fine-grained access control of their medical records, selecting essentially any
portion of it they wish to share.
3. Summary contract (SC)
This contract functions as a bread crumb trail for participants in the system to locate their
medical record history. It holds a list of references to Patient-Provider Relationship contracts
(PPRs), representing all the participant's previous and current engagements with other nodes in
the system. Patients, for instance, would have their SC populated with references to all care
providers they have been engaged with. Providers, on the other hand, are likely to have
references to patients they serve and third-parties with whom their patients have authorized data
sharing. The SC persists in the distributed network, adding crucial backup and restore
functionality. Patients can leave and rejoin the system multiple times, for arbitrary periods, and
always regain access to their history by downloading the latest blockchain from the network. As
long as there are nodes participating in the network, the blockchain log is maintained.
The SC also implements functionality to enable user notifications. Each relationship stores a
status variable. This indicates whether the relationship is newly established, awaiting pending
updates and has or has not acknowledged patient approval. Providers in our system set the
relationship status in their patients' SC whenever they update records or as part of creating a new
relationship. Accordingly, the patients can poll their SC and be notified whenever a new
relationship is suggested or an update is available. Patients can accept, reject or delete
relationships, deciding which records in their history they acknowledge.

10HUMAN FACTORS IN SYSTEM DESIGN
4. System node description
We design the components of our system nodes to integrate with existing EHR infrastructure.
We assume that many nodes, and in particular care providers, already trustfully manage
databases with patient data stored on servers with network connectivity. Our design introduces
four software components: Backend Library, Ethereum Client, Database Gatekeeper and EHR
Manager. These can be executed on servers, combining to create a coherent, distributed system.
We provide a prototype implementation of these components that integrates with a SQLite
database and is managed through our web user interface.
5. Backend API library
We construct multiple utilities, bundled in a backend library, to facilitate the system's operation.
Our library abstracts the communications with the blockchain and exports a function-call API.
Record management applications and their user interfaces can thus avoid the hurdles of working
directly with the blockchain. One such hurdle is verifying that each sent transaction is accepted
with high confidence by the network. Our library automatically handles the uncertainty of when
transactions are mined and deals with cases when they are discarded. The backend library
interacts with an Ethereum client to exercise the low-level formatting and parsing of the
Ethereum protocol.
Steps 1 and 2 in Figure 2 illustrate our backend implementation of a scenario where a provider
adds a record for a new patient. Using the Registrar Contract on the blockchain, the patient's
identifying information is first resolved to their matching Ethereum address and the
corresponding Summary Contract is located. Next, the provider uploads a new PPR to the
blockchain, indicating their stewardship of the data owned by the patient's Ethereum address.
The provider node then crafts a query to reference this data and updates the PPR accordingly.

11HUMAN FACTORS IN SYSTEM DESIGN
Finally, the node sends a transaction which links the new PPR to the patient's Summary Contract,
allowing the patient node to later locate it on the blockchain.
6. Ethereum client
This component implements the full functionality required to join and participate in the
Ethereum blockchain network. This handles a broad set of tasks, such as connecting to the peer-
to-peer network, encoding and sending transactions and keeping a verified local copy of the
blockchain. For our prototype implementation we use PyEthereum and the PyEthApp client.
We modify the client to be aware of our mapping of identity and addresses. We then implement a
service to locate the node's Summary Contract (SC), via Registrar Contract address lookup. This
service runs continuously within the client to monitor real-time changes to the SC. In the event
of an update, the service signals the EHR Manager to issue a user notification and, if necessary,
sync the local database..
7. Database keeper
The Database Gatekeeper implements an off-chain, access interface to the node's local database,
governed by permissions stored on the blockchain. The Gatekeeper runs a server listening to
query requests from clients on the network. A request contains a query string, as well as a
reference to the blockchain PPR that warrants permissions to run it. The request is
cryptographically signed by the issuer, allowing the gatekeeper to confirm identities. Once the
issuer's signature is certified, the gatekeeper checks the blockchain contracts to verify if the
address issuing the request is allowed access to the query. If the address checks out, it runs the
query on the node's local database and returns the result over to the client.

12HUMAN FACTORS IN SYSTEM DESIGN
8. EHR Manager
We tie together all the software components previously mentioned with our EHR management
and user interface application. The application renders data from local SQLite databases
(designed to be interchangeable with other DB software) for viewing, and presents the users with
update notifications, and data sharing and retrieval options. Our user interface prioritizes
intuitive, crisp, and informative design, as recommended by the Department of Veteran Affairs
and ONC’s Blue Button design competition. Our application is conveniently accessed through a
web interface, built on a python backend framework. We are especially cognizant of
compatibility for mobile devices, as modern users expect easy access and high quality
experiences while on-the-go.
9. MedRec blockchain mining
We incentivize “miners” to participate in the network and contribute their computational
resources to achieve a trustworthy, gradual advancement of the chain. We propose a model that
engages the healthcare community in network stewardship—MedRec brings medical researchers
and health care stakeholders to mine in the network. In return, the network beneficiaries, i.e.
providers and patients, release access to aggregate, anonymized medical data as mining rewards.
We explore this idea in our prototype by implementing a special function in the PPR contract. It
requires care providers to attach a bounty query to any transaction they send updating the PPR.
For example, this bounty query can be formulated to return the average iron levels in blood tests
done by the provider, across all patients, in the previous week.

13HUMAN FACTORS IN SYSTEM DESIGN
Usability requirements.
Most importantly, the MedRec model restores comprehensive patient agency over healthcare
information—across providers and treatment sites, empowering citizens with the data they need
to make informed decisions around their care. By giving patients a long-term, trusted log of their
information with data sharing functionality built-in, the MedRec system directly addresses the
ONC Interoperability Roadmap’s first Outcome: “Individuals have access to longitudinal
electronic health information, can contribute to the information, and can direct it to any
electronic location”. Patients can build a holistic record of their medical data and authorize
others for viewership, such as physicians providing a second opinion or family members and
care guardians.
MedRec data can also feed into emerging technologies for predictive analytics, allowing patients
to learn from their family histories, past care and conditions to better prepare for healthcare
needs in the future. By employing open APIs like MedRec, machine learning and data analysis
layers could be added to repositories of healthcare data to enable a true “learning health system”.
Due to the linked interoperability between provider databases in a MedRec network, better-
unified access to data could facilitate a wide range of trend discovery. MedRec’s modularity
could support an additional analytics layer for disease surveillance and epidemiological
monitoring, physician alerts if patients repeatedly fill and abuse prescription access (e.g. part of
the national problem with narcotics abuse), personal dashboards that show patients emerging
trends in their own health, etc. In this respect, MedRec enables a service-oriented architecture
(SOA) as outlined in the ONC Roadmap’s “Secure, Standard Services”.
The MedRec smart contract structure serves as one model for a “Health Care Directory and
Resource Location,” secured with public key cryptography and enabled with crucial properties of

14HUMAN FACTORS IN SYSTEM DESIGN
provenance and data integrity. This blockchain directory model supports the ability to “grow and
change dramatically throughout its lifetime— adding new participants and changing
organizational relationships” through stateful updates to the smart contracts. A blockchain log
could provide clarity for communicating authorization “across the Health IT ecosystem,” and an
audit log for subsequent inquiries into use of such permissions and access patterns. With this
functionality, the system would serve as a “Consistent Representation of Authorization to Access
Electronic Health Information”.
Fundamentally, the MedRec project strives to enable Precision Medicine and holistic
understanding of patient medical status without creating a centralized repository of data.
Centrally-stored data has often proved disastrous in our modern age of cyberattacks and data
leaks. Therefore, MedRec leverages a decentralized, blockchain architecture to enable local,
separate storage but coordinated viewing of the data from the patient perspective.
Evaluation of the software (Methods and Procedure)
MedRec gives patients an immutable log of their medical history, which is not only
comprehensive, but also accessible and credible. This restores patient agency, as participants are
now more fully informed of their medical history and any modifications to it. Through
permission management on the blockchain, we enable patient-vetted data exchange between
medical jurisdictions and an interoperable content management system for the physicians
supervising these records. The blockchain ledger keeps an auditable history of medical
interactions between patients and providers, likely relevant for regulators and payers (e.g.
insurance) in the future. Below, we consider the security, privacy and interoperability
implications of this project and discuss our in-situ deployment testing.

15HUMAN FACTORS IN SYSTEM DESIGN
First, on robustness and security: our blockchain implementation enjoys several key properties of
decentralization. MedRec enjoys a strong failover model, relying on the many participating
entities in the system to avoid a single point of failure. Medical records are stored locally in
separate provider and patient databases; copies of authorization data are stored on each node in
the network. Because both the raw medical data and global authorization log stay distributed, our
system does not create a central target for content attack—a crucial consideration in an age of
cyberattacks and data leaks.
Regarding privacy, use of blockchain technology introduces several limitations. The
pseudonymous property of transactions currently allows for data forensics, or inferring patterns
of treatment from frequency analysis. Without any disclosure of name or PII, one could infer that
some entity has repeatedly interacted with another network entity through analysis of network
traffic. Improving obfuscation while preserving auditability on the blockchain is an ongoing area
of exploration. One potential solution is to make the blockchain a “permissioned” structure,
where only pre-approved, white- listed nodes are allowed read access to the ledger. This would
prevent rogue actors from extracting frequency-based insights from the blockchain records.
Furthermore, encryption can be introduced in the off-blockchain data syncing steps to safeguard
against accidental or malicious content access. While outside the scope of the initial prototype
(but unarguably crucial for future development), a rigorous k- anonymity analysis of privacy-
preserving query construction is needed, for release of the aggregated research data to medical
research “miners.”
Regarding interoperability: by integrating with providers' existing data storage infrastructure, we
facilitate continued use of their existing systems. We believe this will ease adoption and aid
compliance with HIPAA regulations. Building on the principle of interoperability, we have

16HUMAN FACTORS IN SYSTEM DESIGN
designed the system with flexibility to support open standards for health data exchange—be that
FHIR or other flavors of HL7 proposals in the future. In addition, MedRec is source agnostic, i.e.
able to receive data from any number of endpoints (physician offices, hospital servers, patient
home computers, et cetera). We have developed MedRec not as a proprietary system, but as a set
of open APIs to facilitate EHR review and exchange. MedRec is a layer that can be added to
existing provider backends (see discussion below of integration with EPIC and Cerner systems)
with minimal orchestration, thanks to the embedded logic in our Database Gatekeeper utility.
To test our system’s interoperability with an in-situ provider’s backend systems and data files,
we have partnered with Beth Israel Deaconess Medical Center (Harvard Medical School
Teaching Hospital). We are evaluating MedRec’s ability to smoothly intake and parse a standard
clinical document, link our Database Gatekeeper utility to the relevant Beth Israel endpoint and
test an end-to-end system flow from the hospital’s existing user interface for physicians through
our backend and out to a sample patient node.
Conclusion and Findings
The MedRec prototype provides a proof-of-concept system, demonstrating how principles of
decentralization and blockchain architectures could contribute to secure, interoperable EHR
systems. Using Ethereum smart contracts to orchestrate a content-access system across separate
storage and provider sites, the MedRec authentication log governs medical record access while
providing patients with comprehensive record review, care auditability and data sharing. We
demonstrate an innovative approach for integrating with providers’ existing systems, prioritizing
open APIs and network structure transparency. We look forward to continued work on the

17HUMAN FACTORS IN SYSTEM DESIGN
MedRec project infrastructure, following the ONC’s call for policy and technical components of
an interoperable health IT stack. We remain committed to the principles of open source software
and will release our research framework on GitHub as a platform for further development in the
fall of 2016. As we look to take MedRec from a research prototype to a meaningful tool for
enterprise, government and patient use, we have identified several thrusts of future work. First,
we continue our process of actively engaging with healthcare stakeholders across the industry,
from hospitals and provider offices, to pharmaceutical companies, to insurance companies, to
healthcare startups, U.S. Government institutions and more. We are currently in the process of
gathering functionality requirements and additional use-case scenarios from the Department of
Veterans Affairs, Kaiser Permanente, Merck & Co., Beth Israel Deaconess Medical Center and
others to improve the design of all aspects of the MedRec system. In future months, we hope to
complete additional rounds of security testing, including third-party penetration testing and a bug
bounty program, as outlined in the ONC Roadmap’s guidelines for “Ubiquitous, Secure Network
Infrastructure”. MedRec’s community model, where medical researchers (and potentially other
regulated stakeholders in the healthcare industry) can obtain insightful, population-wide data on
medical treatment offers an unprecedented opportunity to achieve goals for precision medicine
and evidence-based research. Such a system would facilitate the Patient-Centered Outcomes
Research Institute’s goals for comparative clinical effectiveness research, by linking the patients
within a particular clinical cohort with both granular and long-term medical history, thus
enabling a better understanding of patient outcomes across treatment groups and over time. By
leveraging a data orchestration system like MedRec where the records would already be
gathered, organized and available for analysis, this type of research can be achieved with
significantly less overhead than traditional research trials, which often require expensive

18HUMAN FACTORS IN SYSTEM DESIGN
recruitment procedures and in-person access to patients. This ability to carry out longitudinal
studies on MedRec user cohorts directly addresses both the ONC Interoperability Roadmap
stated Outcomes and the PMI’s goal for a national research cohort.
Though the MedRec backend is already designed to be flexible with many database
architectures, we are exploring custom integration requirements for InterSystems Caché
technology, which underpins many hospital backends across the nation and supports EPIC’s
record management platform. Our goal is to make MedRec an interoperability layer that can be
seamlessly added to existing EPIC, Cerner, et cetera deployments, building on the open
standards development collaboration “Sync for Science” between the NIH and ONC.

19HUMAN FACTORS IN SYSTEM DESIGN
References:
Alonso, S.G., Arambarri, J., López-Coronado, M. and de la Torre Díez, I., 2019. Proposing
New Blockchain Challenges in eHealth. Journal of medical systems, 43(3), p.64.
Anderson, J., 2018. Securing, standardizing, and simplifying electronic health record audit
logs through permissioned blockchain technology.
Angraal, S., Krumholz, H.M. and Schulz, W.L., 2017. Blockchain technology: applications
in health care. Circulation: Cardiovascular Quality and Outcomes, 10(9), p.e003800.
Azaria, A., Ekblaw, A., Vieira, T. and Lippman, A., 2016, August. Medrec: Using
blockchain for medical data access and permission management. In 2016 2nd International
Conference on Open and Big Data (OBD) (pp. 25-30). IEEE.
Badr, S., Gomaa, I. and Abd-Elrahman, E., 2018. Multi-tier Blockchain framework for IoT-
EHRs systems. Procedia Computer Science, 141, pp.159-166.
Cano, I., Alonso, A., Hernandez, C., Burgos, F., Barberan-Garcia, A., Roldan, J. and Roca,
J., 2015. An adaptive case management system to support integrated care services: lessons
learned from the NEXES project. Journal of biomedical informatics, 55, pp.11-22.

20HUMAN FACTORS IN SYSTEM DESIGN
Cao, S., Zhang, G., Liu, P., Zhang, X. and Neri, F., 2019. Cloud-assisted secure eHealth
systems for tamper-proofing EHR via blockchain. Information Sciences, 485, pp.427-440.
Catarinucci, L., De Donno, D., Mainetti, L., Palano, L., Patrono, L., Stefanizzi, M.L. and
Tarricone, L., 2015. An IoT-aware architecture for smart healthcare systems. IEEE Internet
of Things Journal, 2(6), pp.515-526.
Dubovitskaya, A., Xu, Z., Ryu, S., Schumacher, M. and Wang, F., 2017. Secure and trustable
electronic medical records sharing using blockchain. In AMIA Annual Symposium
Proceedings (Vol. 2017, p. 650). American Medical Informatics Association.
Ekblaw, A., Azaria, A., Halamka, J.D. and Lippman, A., 2016, August. A Case Study for
Blockchain in Healthcare:“MedRec” prototype for electronic health records and medical
research data. In Proceedings of IEEE open & big data conference (Vol. 13, p. 13).
Esposito, C., De Santis, A., Tortora, G., Chang, H. and Choo, K.K.R., 2018. Blockchain: A
panacea for healthcare cloud-based data security and privacy?. IEEE Cloud Computing, 5(1),
pp.31-37.
Kshetri, N., 2018. Blockchain and Electronic Healthcare Records [Cybertrust]. Computer,
51(12), pp.59-63.
Li, P., Nelson, S.D., Malin, B.A. and Chen, Y., 2019. DMMS: A Decentralized Blockchain
Ledger for the Management of Medication Histories. Blockchain in Healthcare Today.
Lok, D., Bartrem, K. and Chiu, G., 2017. Blockchain-Enabled Multisensor Clinical
Laboratory Information System. Asian Journal of Business and Management (ISSN: 2321-
2802), 5(06).

21HUMAN FACTORS IN SYSTEM DESIGN
Ma, L., Zhao, H., You, S.J. and Ge, W., 2018, May. Analysis and design of hospital
management information system based on UML. In AIP Conference Proceedings (Vol. 1967,
No. 1, p. 040012). AIP Publishing
Miotto, R. and Weng, C., 2015. Case-based reasoning using electronic health records
efficiently identifies eligible patients for clinical trials. Journal of the American Medical
Informatics Association, 22(e1), pp.e141-e150.
Muinga, N., Magare, S., Monda, J., Kamau, O., Houston, S., Fraser, H., Powell, J., English,
M. and Paton, C., 2018. Implementing an Open Source Electronic Health Record System in
Kenyan Health Care Facilities: Case Study. JMIR medical informatics, 6(2).
Peters, A.W., Till, B.M., Meara, J.G. and Afshar, S., 2017. Blockchain technology in health
care: A primer for surgeons. Bulletin. facs. org.
Quaini, T., Roehrs, A., da Costa, C.A. and da Rosa Righi, R., 2018. A MODEL FOR
BLOCKCHAIN-BASED DISTRIBUTED ELECTRONIC HEALTH RECORDS. IADIS
International Journal on WWW/Internet, 16(2).
Ratwani, R.M., Fairbanks, R.J., Hettinger, A.Z. and Benda, N.C., 2015. Electronic health
record usability: analysis of the user-centered design processes of eleven electronic health
record vendors. Journal of the American Medical Informatics Association, 22(6), pp.1179-
1182.
Reimer, A.P., Milinovich, A. and Madigan, E.A., 2016. Data quality assessment framework
to assess electronic medical record data for use in research. International journal of medical
informatics, 90, pp.40-47.

22HUMAN FACTORS IN SYSTEM DESIGN
Sabahein, K., Reithel, B. and Wang, F., 2018. Incorporating Delegation into ABAC:
Healthcare Information System Use Case. In Proceedings of the International Conference on
Security and Management (SAM) (pp. 291-297). The Steering Committee of The World
Congress in Computer Science, Computer Engineering and Applied Computing
(WorldComp).
Santoso, H.B., Nisa, A.K. and Fitriansyah, R., 2017. Usability evaluation of the Hospital
Management Information System: Case study of an emergency installation application of a
regional public hospital. Int. J. Adv. Sci. Eng. Inf. Technol, 7(6), pp.2294-2301.
Srivastava, S., Soman, S., Rai, A., Cheema, A. and Srivastava, P.K., 2017, March. Continuity
of care document for hospital management systems: an implementation perspective. In
Proceedings of the 10th International Conference on Theory and Practice of Electronic
Governance (pp. 339-345). ACM.
Talukder, A.K., Chaitanya, M., Arnold, D. and Sakurai, K., 2018, October. Proof of Disease:
A Blockchain Consensus Protocol for Accurate Medical Decisions and Reducing the Disease
Burden. In 2018 IEEE SmartWorld, Ubiquitous Intelligence & Computing, Advanced &
Trusted Computing, Scalable Computing & Communications, Cloud & Big Data Computing,
Internet of People and Smart City Innovation
(SmartWorld/SCALCOM/UIC/ATC/CBDCom/IOP/SCI) (pp. 257-262). IEEE.
Thangaraj, M., Ponmalar, P.P. and Anuradha, S., 2015, December. Internet of things (iot)
enabled smart autonomous hospital management system-a real world health care use case
with the technology drivers. In 2015 IEEE International Conference on Computational
Intelligence and Computing Research (ICCIC) (pp. 1-8). IEEE.

23HUMAN FACTORS IN SYSTEM DESIGN
Tyagi, S., Agarwal, A. and Maheshwari, P., 2016, January. A conceptual framework for IoT-
based healthcare system using cloud computing. In 2016 6th International Conference-Cloud
System and Big Data Engineering (Confluence) (pp. 503-507). IEEE.
Vuokko, R., Mäkelä-Bengs, P., Hyppönen, H., Lindqvist, M. and Doupi, P., 2017. Impacts of
structuring the electronic health record: Results of a systematic literature review from the
perspective of secondary use of patient data. International journal of medical informatics, 97,
pp.293-303.
Wang, H. and Song, Y., 2018. Secure cloud-based EHR system using attribute-based
cryptosystem and blockchain. Journal of medical systems, 42(8), p.152.
Weber, G.M., Adams, W.G., Bernstam, E.V., Bickel, J.P., Fox, K.P., Marsolo, K., Raghavan,
V.A., Turchin, A., Zhou, X., Murphy, S.N. and Mandl, K.D., 2017. Biases introduced by
filtering electronic health records for patients with “complete data”. Journal of the American
Medical Informatics Association, 24(6), pp.1134-1141.
Wehbe, Y., Al Zaabi, M. and Svetinovic, D., 2018, November. Blockchain AI Framework
for Healthcare Records Management: Constrained Goal Model. In 2018 26th
Telecommunications Forum (TELFOR) (pp. 420-425). IEEE.
Xu, Y., Li, N., Lu, M., Myers, R., Dixon, E., Walker, R. and Quan, H., 2017. Developing and
Validating Electronic Medical Record Based Case Definitions for Liver Diseases and
Comorbidities. International Journal of Population Data Science, 1(1).
Yang, G. and Li, C., 2018, December. A design of blockchain-based architecture for the
security of electronic health record (EHR) systems. In 2018 IEEE International Conference
on Cloud Computing Technology and Science (CloudCom) (pp. 261-265). IEEE.