1 Introduction

South Africa plans on implementing the National Health Insurance (NHI) scheme to provide cost effective access to healthcare for all citizens. Once the scheme is in place, it is believed that the focus of the healthcare industry will shift towards preventative care and health promotion. This would require the industry to become patient-centred. Paper-based filing has major risks such as being vulnerable to damage by elements such as fire and water and medical records being lost [7]. In addition, backups are time and resource intensive and security of paper-based filing is limited to locked storage, with minimal capabilities of logging access to medical records. Various types of electronic records exist, each having a different purpose [13]. For example, an electronic medical record (EMR) typically contains detailed patient encounter information such as an encounter summary, medical history, test results, and allergy details. EMRs are owned and managed by professionals from a single institution. An electronic health record (EHR) is an aggregated collection of a patient’s health information collected from multiple professionals at multiple institutions [19]. It ensures that a patient’s complete medical record is available to an authorised practitioner during patient encounters. No country in Africa has been successful in implementing a nationwide EHR system [21]. EHR and EMR are used interchangeably in the literature but the term EHR is used to refer to all electronic records for health information in this study.

2 Literature Overview

Paper-based filing has major risks such as being vulnerable to being damaged by elements such as fire and water; medical records being lost and creating backups requiring time and intensive resources [7]. The security of paper-based filing is limited to locked storage, with minimal capabilities of logging access to medical records. A major issue with paper-based filing is illegibility. Illegibility causes delays in treating patients as time is wasted by trying to understand what is written, contacting the author or redoing the procedure to reproduce the results. The problems associated with paper-based filing are solved with electronic records. Electronic records such as EHR use secure information systems to store and access patient health information and to ensure that the information contained is up-to-date and available when needed [13].

The challenges of implementing EHR systems are a lack of consistent supply of electricity, governmental support and the required infrastructure [21]. Despite these challenges, various vendors in SA have attempted to implement their own EHR systems, built on differing architecture which fail to interoperate with each other [21]. Disinterest stems from the belief that measurable benefits (such as finances) are better realised within their own organisation. Thus, to gain the benefits of an EHR system, patients are limited to clinical encounters with organisations that utilise the specific EHR system. This devalues the effectiveness and efficiency of patients managing their own healthcare. The biggest challenge preventing the adoption of EHR systems in the health industry is the resistance from practitioners [22].

An Accenture study on SA patients clearly indicated that electronic records are viewed as being more reliable than paper-based records [13]. It was indicated by 51% of respondents that time was wasted when having to recount their medical history to all the practitioners that they visited. Surprisingly, those with medical aid are willing to spend up to R100 extra per month to have their health records maintained electronically [13]. Muchangi and Nzuki [24] revealed that patients are not confident in using EMR systems that do not comply with established standards as they fear that their medical confidentiality and security might be compromised. Currently, the SA government lacks legislation and regulations regarding EMR implementation which has led to misuse and poor compliance by organisations [21]. Until the government develops standards for EMR, common guidelines must be followed in developing such systems.

Various technologies can be utilised to create patient-centred healthcare systems but blockchain offers a unique solution. Blockchain makes use of features (security, stability, fault-tolerance) to allow a network to remain fully functional even if a node has failed [16]. For example, each time a transaction occurs, a transaction request is transmitted to all the nodes, making each node aware of the fact as well as the time the event took place. Nodes then validate the authenticity of the block through a majority consensus and then several transactions are put together into a block. The block is then inserted into the ledger by linking to the last block that was inserted into the ledger. Thus, as blocks are continuously inserted to the ledger, a long series of blocks is formed, hence the term blockchain. Each block is marked with a timestamp and a hash of the previous block, preventing alterations from being made to the previous block [10]. An example of blockchain is the cryptocurrency Bitcoin.

Centralised systems exhibit at least one of the following shortcomings: instability due to having a central point of failure, security shortages due to being more vulnerable to central attacks and greater potential of unethical operations due to the presence of a central authority [16]. Decentralised systems do not have a central authority. Instead, authority is shared amongst each computer (node), with each of them having equal authority [25]. Distributed systems divide computations into smaller computations to be performed by multiple nodes. Distributed and decentralised systems are highly secure as a central point to attack is lacking. This feature also makes them stable and fault-tolerant. Since each node has equal authority, unethical operations are unlikely to be performed [16]. Blockchain makes use of these features and benefits to allow the network to remain fully functional even if a node has failed.

The purpose of this paper is to report on an investigation into patient-centered healthcare and the potential of blockchain technology for supporting this system. Its contribution is the development of a blockchain technology and lessons learnt that can support other research into patient-centered healthcare.

The structure of the paper is as follows: The next section provides an overview of the design methodology adopted in the research. Section 4 illustrates the proposed requirements and design of the prototype whilst Sect. 5 discusses the design and development thereof. In Sect. 6 the pilot study protocol is explained. The formative evaluation that was conducted is highlighted in Sect. 7. In Sects. 8 and 9 a discussion of the findings and conclusions are presented.

3 Methodology

The project made use of the Design Science Research (DSR) methodology as proposed by [3]. This methodology creates new knowledge in a given domain through the design and creation of an innovative system that solves relevant problems or achieves substantial improvements [18]. In this study, DSR was used to examine the shortcomings of existing EHR systems and to design a mobile system that utilises blockchain technology. The five steps of DSR were iteratively conducted namely, problem awareness, suggestion, development (circumscription), evaluation and conclusion (operation and goal knowledge). A prototype was designed and developed as a proof-of-concept and the usability of the system was formatively evaluated in a pilot study.

4 Proposed Design

Documentation analysis is a requirement elicitation technique that collects, reviews and analyses existing documentation to gather requirements [14, 15]. These two activities formed part of the problem awareness stage of DSR in this project.

4.1 System and Data Requirements

The system requirements were identified from a literature review and an extant systems analysis of existing systems and then grouped into core and support components. The requirements of the first core component was to facilitate the storage of and access to a patient’s health-related information. This information consists of a patient’s personal information, medical practitioner information and health information. Personal information includes full name, date of birth, family history, emergency contact person(s), allergies and medical aid. The practitioners’ information includes the full name of the practitioner, the profession, the medical practice number, place of work, years of experience and any malpractice claims. Information related to the patient’s health consists of diagnoses, prescriptions, treatment plans and medical test results.

The requirements for the second core component is to facilitate medication adherence for patients. The purchase of prescribed medication should be logged. The data generated from the medication adherence component should be aggregated and form part of a patient’s health information. The system should be able to interface with an external medication website that provides details of active ingredients, pricing etc.

The support component should facilitate communication between the two parties (patients and medical practitioners), which is achieved through a personal health community (PHC). Using a PHC gives patients control over who is a member of the community. This prevents any unwanted entities from contributing or collecting information for their own purposes. This component should also provide functionality for an Online Health Community (OHC). OHCs are an example of how social media can be incorporated into healthcare [20]. OHCs unite individuals with a shared goal or interest in healthcare. OHCs comprise of patients with a condition (such as ALS patients), a group of practitioners with a shared medical interest (such as neurologists), or a mixture of both. OHC members interact using modern communication technologies such as blogs, chats, forums, and wikis. OHCs can be classified into open and closed communities. Open OHCs are public and its contents can be accessed by anyone. All members of the community can contribute to its content.

For the data design, the data classes were based on those of the Fast Healthcare Interoperability Resources (FHIR) standard, which is a draft standard describing data formats and elements (known as “resources”) and an API for exchanging electronic health records [4, 5]. The standard was created by the health level seven international (HL7) healthcare standards organisation.

In the extant systems analysis conducted in this paper, six systems were reviewed. Nine criteria were used in reviewing each system namely database, multiple users, communication, notifications, data sharing, flexible scheduling, community type, visual aids and statistics and charts. AidIT was the only system identified that provides data storage and access and is a mobile EMR system that allows patients to manage their records and facilitates the exchange of these records between patients and practitioners [8]. The AidIT system provides patients with a personal health folder that organises a patient’s data into five separate categories namely: the patient’s personal information (e.g. address, date of birth, photograph and information regarding his/her insurance profile); the patient’s general medical history (e.g. past injuries, chronic conditions, allergies and healthcare encounters); the patient’s past examinations and relevant diagnoses along with ordered lab tests and their results; the patient’s current and past medication prescriptions, along with the quantity and dosage instructions required for each medication; and the patient’s care plan. The patient’s care plan is designed by the patient’s practitioners as a list of actions to be carried out by the patient. AidT’s shortcomings includes non-functionality for tracking and monitoring a patient’s adherence to their medication schedule. In addition, EMR presentation does not indicate what is important and professionals can amend prior medical records which can create inconsistencies.

4.2 System Architecture

The system used a three-tier architecture, which consists of three layers: the application, storage and logic layer. The benefits to using a three-tier architecture is to provide security, performance and code maintenance [2]. The architecture is illustrated in Fig. 1.

Fig. 1.
figure 1

System architecture.

Full size image

The application layer is where users (patients and professionals) interact with the system to perform tasks such as registering to the system and posting messages. How the information is presented to users is also handled in this layer. The storage layer was split between a database and a blockchain network. The variability, relevance (null voids) and design of blockchain complexity of the structure of health records can limit how they would be stored in a blockchain environment. Each node in a blockchain has a replica of all information stored in the ledger. It would be impractical to have each node store all the health records as they can consume a considerable amount of space, require intensive bandwidth usage and would be wasteful on network resources.

Rather, in the adopted design, the blockchain functions as an access-control manager for health records. Only the personal and professional information of patients and professionals is stored on the blockchain and the patients’ health data is stored on a database with the blockchain having encrypted index pointers to the data contained in the database.

The logic layer is spread across the separate components (application, database and blockchain network). For this layer to function seamlessly, the three components must communicate with each other effectively, which is achieved by using a combination of APIs, and private-public key encryption protocols.

5 Design and Development

Design is iterative in nature, cycling through design–evaluation–redesign activities [15]. In DSR, iteration is an important part of the process. In this study the design and development of the system (the artefact), was iteratively designed, developed and evaluated. Two alternative wireframe prototype designs were proposed. A walkthrough evaluation was conducted on both wireframes by an expert reviewer as proposed by [1]. AdobeXD was chosen to prototype the two alternative designs as the software is a free, simple to use platform that allows for designing high fidelity wireframes that can be interacted with to simulate the system’s usage. The feedback received indicated that the first wireframe was too cluttered while the second wireframe had a professional feel and made better use of hand gestures for navigation. The second wireframe design was therefore selected for further development and sample screenshots are shown in Fig. 2. A second walkthrough of the second wireframe was undertaken by a second expert reviewer. The primary feedback received was to limit the viewing of the professionals’ information to only those that have been referred to by one of the professionals in their community. The choice of expert reviewers was because of their availability within short notice as opposed to a typical end-user (patient) and medical practitioner which requires lengthy ethics clearance application and approval.

Fig. 2.
figure 2

Wireframe design.

Full size image

Android was the chosen mobile platform for developing the system because it has the largest market share of smartphones [6], and allows for a wide audience to be reached. Java was selected as the programming language since the Android development kit is best suited to Java’s libraries and Java’s previous release for mobile environments makes it well suited for developing for different devices [11]. The medical information is stored in a MongoDB database, which is a NoSQL document-based database that stores its records in a JSON-like document where fields in each document may differ [23]. Flexibility in the structure of a document is required for the system as some data may not always be present in certain circumstances; such as there being no end date in a period object. The FHIR API, which the system makes extensive use of, provides support for mapping its data objects to JSON files, and vice-versa.

6 Pilot Study

The first iteration of developing the system began with developing the two wireframes and the second wireframe was selected for implementation. The selected wireframe was able to artificially simulate how the final system could work and provided a good reference point for the development of the system. The second iteration followed soon after selecting the development environment. The major changes from the first iteration were the use of floating action buttons, making extensive use of native mobile features and incorporating labelled tabs for grouped items and efficient login credential persistence. Floating action buttons perform a primary action on a given screen [12]; these buttons appear in front of the screen’s content for clear visibility and use menu icons that the user is familiar with to assist in identifying what the button’s purpose is.

Android’s native contacts and calendar features were utilised as a service to simplify adding emergency contacts and including reminders for medication adherence. Efficiently persisting the login credentials of the user was accomplished by incorporating Google’s smart lock feature which is accessible by using permissions on Android smartphones. Persisting user credentials is very important, as the system will make use of blockchain addresses and private keys as the credentials. Blockchain addresses and keys are very lengthy and stored as hexa-decimal values which are not user-friendly. Thus, the burden of having to remember login credentials is absorbed by Google smart lock from the user. The updated system after these changes were made and the benefits are for registering and creating a new medical record while smart lock is for registration and login.

The third iteration occurred during the implementation of the blockchain related aspects. Notifying users of important events (include invites to a community; receiving messages and medication schedules, being informed of non-adherence to medication) were a problem. The solidity development environment supported functionality for logging events, such as medication adherence and invites, which play an integral part of the notification functionality; not all blockchain networks support this functionality (logging events). The workaround to this was to restrict the medication schedule to a patients’ native calendar; thus, removing the functionality of viewing a patient’s adherence to the medication schedule. A second solution workaround is using the QR codes which was embedded with the smart contract’s details and used to send invites to a patient’s PHC. The QR codes could also be used to save a user’s blockchain credentials for when they first register on the systems database.

7 Formative Evaluation

A formative usability study is an almost scientific process where test users evaluate the system by interacting with it in a controlled environment [1]. Users are given a specific set of tasks to accomplish, preferably without the assistance of the facilitator.

7.1 Evaluation Objectives

The goal of the evaluation was to assess the user interaction of the system to identify any shortcomings that could be modified to provide an engaging experience for the user. Evaluation of the system served three objectives. Firstly, to identify which functionalities of the system were implemented correctly or cause the system to fail completely. The second objective was to quantify the usability of the system and gain feedback from the evaluators. The third objective was to use the feedback to make improvements to the system. The tasks to be completed by the users cover all the system’s requirements. These tasks were chosen to evaluate functionality completeness, navigability, users’ subjective satisfaction and user performance; such as comprehension and learnability. The users could directly interact with the system’s interface by tapping buttons, swiping to move between screens or scrolling to view lists or enter data.

7.2 Evaluation Methodology

An expert panel of two participants was used; both were researchers in the field of Computer Science. An expert panel utilises participants who were specifically chosen to be part of the formative study [15]. The first expert was a post-doctoral researcher with a PhD in Computer Science and the second expert was a doctoral candidate. The evaluation was conducted inside a computer laboratory, which is a controlled environment allowing for the capturing of data in an accurate way without the users being distracted or interrupted by external factors, while also ensuring that the predefined tasks are performed and completed within a reasonable time frame. The participants were separated from each other and only interacted with each other when necessary. Each expert was provided with an Android smartphone to complete the tasks. One expert completed tasks related to the practitioner use cases and the other the tasks related to a patient’s use cases.

The instrument used was the Post-Study System Usability Questionnaire (PSSUQ) as proposed by Lewis [9], which is a comprehensive questionnaire that provides a host of insightful information from analysing the results of the usability study. PSSUQ is comprehensive in that it provides a set of selected questions and the user does not have to add in extra comments if he/she does not want to, since the questions provide sufficient information. The questionnaire is reliable, free and addresses the usability characteristics of system usefulness, information quality, interface quality and overall satisfaction [17]. Additional questions were included to obtain the experts’ views of interacting with the system. PSSUQ was the more available questionnaire during the study period because of its ability to meet the researchers study objective. A new questionnaire known as the mHealth app usability questionnaire (MAUQ) was recently developed by [26] after the completion of this study and so could not be used.

Dummy blockchain accounts were created and provided for each expert so that they were able to register their details on the system. Additional patient and practitioner accounts were provided for the experts in case of a failure of registration, creating and joining a community. The background, goals and tasks of the system were explained to the panel and they were encouraged to ask questions. Support were provided to the participants if they struggled to complete a task, and a note was made of which tasks required assistance.

8 Results

The results revealed that the primary concern for the system were the register (practitioner), accept community invite and update details use cases. The code that performs these use cases needs to be re-examined and may require recreating the circumstances for the failure to identify the cause of the problem and then making relevant changes to solve the problem without requiring massive changes to the remaining aspects of the system. The majority of the errors made occurred when the participants attempted a new task without a reference point as to how to successfully complete it; this is also where the facilitator was required to assist the participants in completing the task, which increased the task time. However, as the participants got used to the system, fewer errors were made, and the task times were reduced when attempting tasks that have similar steps, indicating that the system can be learnt over time.

The user satisfaction results indicated that the user interface for the patient use cases had higher satisfaction levels than that of the practitioner use cases. The patient expert perceived the consistency in the layout of the system’s user interface to be the most helpful component in successfully completing tasks and found the use of icons helpful in understanding the meaning of some of the information presented to the screen. The practitioner expert perceived the system to provide poor user satisfaction due to the user interface being dis-organised and the icons being too domain specific resulting in some confusion. The practitioner expert also found it hard to keep track of the current position in the system which resulted in errors being made. The panel both mentioned that the system takes too long to respond, and that more feedback should be provided to the user when performing actions.

The major problems related to providing clarity on how to navigate the system to complete tasks, a lack of feedback from the actions the participants performed and the system’s slow response time. The slow response of the system was due to having to query both the blockchain network as well as the database that stores the data. The smart contract hosted on a blockchain network contains the indices of the patient’s medical records which are stored in the database. Thus, the smart contract is first queried to obtain the correct indices and then the indices are used to retrieve the medical records from the database. Converting the data from its representation in the data layer to its representation in the system layer, and vice-versa, also contributed to the lag in response from the system.

The system design made use of tabs, whereby, when a screen that requires data from the database is opened, a query to obtain all the necessary data is performed. This affected the community screen the most as all the patient’s medical data must be queried before displaying the screen. A redesign of the system should thus restrict the queries to only be executed when necessary. The system’s layout needs to be improved to emphasise frequently performed tasks by making the components used to complete those tasks the most prominent on the screen. Related functionality needs to be grouped together to avoid complex navigation steps being performed by users.

The system’s redesign emphasised the incorporation of dialogs to the layout of the user interface while reducing the focus of using tabs. Dialogs provide a convenient method for solving most of the issues affecting the system. Dialogs are modal windows that appear at the forefront of a system’s content to provide users with important information or requesting decisions that need to be made [12]. By utilising dialogs instead of tabs, only the selected type of medical information will be retrieved from the database; thus, reducing the response time as well as saving the amount of memory required to store the retrieved data. Also, all options will be clearly seen by users instead of having to scroll through tabs to get to the appropriate screen.

9 Discussions and Future Research

Having piloted the system and taking notes of issues experienced by the expert panel, future research study will conduct a summative usability evaluation of the system as well as provide a discussion of the results. Summative evaluations assess the success of the system accomplishing its functional requirements [17]. Unlike a formative evaluation, test users are given a list of all the tasks that can be performed using the system, which serves as a primary criterion for evaluating the system. The results will be discussed in future research output(s) where the blockchain technology app will be applied to a broader community of a larger population.

For future research and improvements, this system will be tested again on a sample population of larger size within an academic institution community. This will enable the researcher(s) assess users’ satisfaction with an understanding of what patients’ and medical practitioner’s perceptions are of the system. All ethical considerations, applications and approvals are in processing for this second test.