1. Introduction

2. Related Work

3. Proposed Architecture

3.3. System Instantiation

The proposed architecture design aims to store healthcare data on the cloud and access it for legitimate purposes while protecting privacy. This section uses a scenario to show how the suggested architecture accomplishes this goal. The instantiation is provided in two parts: the first shows a patient enrolling in the system and storing their information on the cloud, while the second section shows how this information can be accessed for medical treatment.

Storing patient information on the cloud - Scenario

Let’s assume that Bob visits a system authorized doctor and requests to enroll in the system. The doctor enters Bob's information through the user application (UA). The doctor clicks on the ENROL button. The process of storing Bob's information on the cloud involves 3 stages: information preparation, authentication and authorization, and storage.

Stage 1: Information Preparation (Searchable Symmetric Encryption): Prior to forwarding the information to the RA, Bob’s information undergoes a number of pre-processing algorithmic operations performed by the UA as preparation for storage. The operations aim to encrypt Bob’s information for storing it on the cloud in a searchable manner.

• A random secret root key (SkR) is generated for Bob’s information using KeyGen algorithm.
• A number of keywords from each document are selected, and a secret key (S_k) for encrypting them is generated using KeyDer algorithm.
• The IndexGen algorithm encrypts selected keywords for every document using their corresponding S_k. The goal in this step is to create an encrypted index for each document to identify it while encrypted.
• After encrypted indexes are generated for all documents, the ciphertexts of keywords with their corresponding S_kfor each document is grouped to be the documents’ trapdoors.
• The last step in the information preparation process involves encrypting the patient’s documents and their corresponding trapdoors. Each document is encrypted using the S_k that is included in its corresponding trapdoor, and trapdoors are encrypted using the S_kR which was generated in the first step.

Stage 2: Authentication and Authorization: When Bob’s information is pre-processed, it is forwarded to the Requesting Agent (RA) in a form of Request of Enroll (ROE). Table 5 presents information contained in the request of enroll (ROE).

The ROE includes three sections that include different information as the following: Section 1 includes information that is required to identify a) the doctor (organization id and user id), b) Bob and practitioners who have permanent consent to access Bob’s information, and c) method of obtaining Bob’s consent to access his information. Section 2 includes information required to identify and decrypt Bob’s information, and section 3 includes Bob’s encrypted Bob’s information (3 encrypted documents).

When the RA receives the request, it authenticates the doctor and forwards his information (contained in the first section of the ROE) and Bob’s phone number to the cloud service registry (CSR) for authorization. The CSR then sends a text message to Bob requesting consent to store his information on the cloud, the content of the message includes:

Please reply YES to authorize (doctor name) from (organization name) to enroll you and store your health information on the system. Upon receiving a YES reply from Bob, the CSR sends a confirmation of authorization to the RA.

Stage 3: Information Storage

When the RA receives confirmation of authorization from the CSR, it does the following actions:

1.

Generates a unique code for the patient referred to as (System ID).

2.

Sends Bob’s encrypted information labelled by Bob’s system ID to the cloud service provider (CSP).

3.

Sends the encrypted trapdoors to the secret key agent (SKA) for storage. Information sent to the SKA is also labelled by Bob’s system ID.

4.

The information sent to both CSP and SKA is deleted from the RA.

5.

The RA stores the following information:

• Bob’s identification information
• Bob’s system ID,
• Bob’s SkR,
• Document indexes
• Names of users who have permanent consent to access Bob’s information (if Bob has provided any)
• Information required for obtaining Bob’s temporary consent

Below is the state-of-the-art of Bob’s information while stored in the cloud:

• Bob’s information is stored in encrypted form and labelled by Bob’s system-generated ID. The cloud provider is not able to learn the content of the information.
• The trapdoors are encrypted using Bob’s SkR and stored on the SKA labelled by Bob’s system ID. The SKA is unable to learn the content of the trapdoors without having Bob’s SkR that is stored on the RA.
• The RA is the only entity in the system that can identify Bob in the system and his SkR. The RA stores all the information that is required to access Bob’s information as presented in Figure 2.

Therefore, accessing Bob’s information can only happen through collaborative interactions among CSP, SKA, and the RA. Compromising 1 or 2 of these architectural components will be fruitless to any disparate party in terms of accessing Bob’s information.

Having discussed the process of storing Bob’s information on the cloud, the following subsection presents the process of accessing Bob’s information for genuine reasons such as providing healthcare to a patient. For this, the scenario presented in the following subsection involves the same patient (Bob) requiring healthcare assistance by a different medical practitioner who also has access to the system.

• Accessing stored patient information – Scenario

Bob visits a hospital for urgent medical treatment. He walks into the emergency department and meets one of the nurses in charge. The nurse requires accessing Bob’s information and updating his records to include information about Bob’s visit, medical condition, and other information related to his visit.

3.3.1. Protocol to access information stored in the cloud

The process of accessing Bob’s information comprises 4 stages as the following:

Stage 1: Generating user request

The nurse enters Bob’s basic information into the user application and clicks on the REQUEST button to generate a user request that is forwarded to the RA. The user request includes information about both Bob and the nurse.

Stage 2: Authentication and Authorization

When the RA receives the request from the user (nurse), it authenticates the user and forwards the request to the CSR for authorization. For this, the RA does the following actions:

1.

It searches for Bob’s information using his basic information and finds his System ID.

2.

It sends a request of authorization to the CSR. The request includes the following information:

• Information that is required to identify the nurse (user ID);
• List of users who have permanent consent to access Bob’s information;
• Bob’s mobile number for requesting his consent if required in this particular instance.

When the CSR receives the request from the RA, it does the following actions:

• It searches for the nurse information to identify her access rights to patient information. This happens by searching through the list of users that is stored locally on the CSR.
• It checks if the nurse is permanently consented to access Bob’s information using the list of users who have permanent consent to access Bob’s information.
• The CSR finds out that the nurse is allowed access doc-1 and doc-2 (Em_V) of patients’ information, but she is not permanently consented to access Bob’s information, therefore, Bob’s consent is required.
• The SCR sends a request of consent to Bob in the form of a text message. The content of the message includes:

Please reply YES to temporarily authorize (nurse name) at (organization name) to access your health information.

Upon receiving a YES from Bob, the nurse becomes temporarily authorized to access Bob’s information. The CSR sends a confirmation of authorization to the RA. The confirmation of authorization includes the information category that the nurse can access (doc-1 and doc-2), and confirmation of obtaining Bob’s consent to access his information. The nurse is then added temporarily to the list of authorized users (stored on the RA) as a temporarily authorized user. However, any authorization granted by the CSR remains valid for 1 hour, after that it is automatically deleted from the list of authorized users.

Stage 3: Releasing Information

Upon receiving confirmation of authorization from the CSR, the RA forwards requests to both, the CSP and the SKA to send Bob’s information to the nurse. As illustrated in Figure 3, the request to the CSP includes:

• Bob’s system ID
• Indexes of doc-1 and doc-2
• The nurse’s application address

While the information included in the request to the SKA includes:

• Bob’s system ID and S_kR
• Trapdoor-1 and Trapdoor-2 tags
• The nurse’s application address

Figure 3. Figure 3. Requesting information from CSP and SKA

Figure 3. Figure 3. Requesting information from CSP and SKA

As presented in Figure 4, when the RA requests are received by the CSP and the SKA, they do the following actions:

The CSP:

• Searches for Bob’s information using Bob’s system ID
• Searches for the doc-1 and doc-2 using their indexes.
• Sends the identified documents (doc-1 and doc-2) to the nurse using her application physical address.

The SKA:

• Searches for the encrypted trapdoors using Bob’s system ID
• Decrypts the trapdoors using Bob’s SkR
• Sends trapdoors for doc-1 and doc-2 to the nurse application using her application physical address.
• Re-encrypts the trapdoors using the same Sk_R and drops the SkR (deletes it).

Figure 4. Releasing information to the nurse application

Figure 4. Releasing information to the nurse application

Sage 4: Decrypting Information

When the information from CSP and SKA is received by the nurse’s application, doc-1 and doc-2 are identified and decrypted using their corresponding trapdoors. When information is decrypted, files in each document appears in their predetermined fields on the nurse’s UA. Fields that belong to the files contained in doc-3 remain blank. The nurse application stores the trapdoors temporarily to be used for re-encrypting the information which is further explained in the following subsection.

3.3.2. Updating patient information

Assuming that the nurse has made an update on Bob’s information such as information related to current medication. The nurse clicks on the UPDATE button on her UA interface. As illustrated in Figure 5:

Stage 1: The nurse’s UA encrypts doc-1 and doc-2 using their secret keys obtained from the trapdoors. The encrypted information (doc-1 and doc-2) is forwarded to the RA.

Stage 2: The RA receives the request from the nurse and does the following:

• It searches for Bob’s information to identify him.
• It searches through the list of authorized users to access Bob’s information and finds the nurse listed as temporarily authorized users to access doc-1 and doc-2 of patients’ information.
• It forwards the encrypted information, indexes for doc-1 and doc-2, and Bob’s system ID to the CSP.

Stage 3: When the CSP receives the information from the RA, it does the following actions:

• It searches for Bob’s encrypted documents using indexes and system ID.
• It identifies the documents using the indexes and replaces them by the new ones
• It deletes the indexes received from the RA.

Figure 5. Updating patient information

Figure 5. Updating patient information

3.4. Architecture Implementation

Having discussed the components and protocol of the proposed architecture, the architecture is further implemented and adapted to data sharing use. The proposed architecture was built using Amazon Web Services (AWS) which provides cost-effective cloud computing solutions [62]. AWS Software Development Kit (SDK) was used with Java language to implement and test the proposed architecture design and validate its concept. The implementation of the proposed architecture aimed to elaborate on how the proposed architecture enables for collaborative use of patients’ information in a privacy-preserving manner. The main objective of the implementation was twofold: firstly, to elaborate on how patients’ information can be collaboratively shared and used in the proposed architecture with assurance to its privacy protection, and secondly to illustrate on how patients’ information is protected from a number of privacy-related threats including confidentiality and unauthorized access.

The elaboration is presented in two parts: the first part presents a scenario that involves a patient who walks into a hospital for urgent medical treatment and is seen by a nurse. The goal of this part is to show how a user (nurse) can access a patient’s information according to certain access rights without questioning the privacy of the information. The elaboration also aims to validate the concept of information separation in real cloud-based application contexts.

The second part of the elaboration presents the results of tests that have been performed on the implemented architecture. The architecture was tested in terms of its ability to preserve the privacy of information while it is stored on the cloud. Four tests were performed which covered the following aspects:

• The ability of the cloud provider to access and read the information that is stored in the cloud
• The ability of unauthorized users to access patients’ information stored in the cloud

The following section presents information about the implementation of the cloud architecture in terms of its architectural components and the privacy-preserving techniques. The implementation aims to mirror the proposed architecture design in terms of the employed components and the privacy-preserving techniques for the goal of validating the concept of the proposed architectural design.

3.4.1. Implementation setup

For the implementation of the proposed architecture, a virtual private cloud (VPC) was created. The VPC represents the entire proposed system architecture, and it is completely isolated from the internet. The VPC has two subnets: the first subnet does not allow access from the internet; it is only accessed locally. The second subnet enables internet access to allow for communication with the user application.

The public subnet has limited access and could be communicated with through the internet; however, only registered IP addresses can communicate with it. The EC2 represents the RA in the proposed design. Access to it happens only through a particular port. Moreover, the database in the implemented design only accepts SQL traffic. Patients’ documents and their associated trapdoors are stored in two different places that are not accessible through the internet as seen in Figure 6. Access to them can only happen locally.

Access to patients’ documents can only happen by requests from the CSR, while the trapdoors can only be accessed through the SKA. Documents stored on the cloud are all encrypted.

Accessing Patientinformation – Scenario

For the goal of testing the architecture, dummy information about 3 patients was used. Each patient had three documents in the system. Documents were all encrypted and stored in the cloud database. Encrypted documents were stored on one database (CSP) and their trapdoors were stored on a different database (SKA). The illustration involved a patient (Bob) who walked into the hospital for urgent medical treatment. The nurse wishes to access Bob’s information to update information regarding Bob’s visit and current medication.

The nurse needs to login to the system for authentication purposes. The user is required to have username and password which are entered through the standard user application. Access to the system only happens through the user application. When the RA receives the user credentials (username and password), it searches for the user information in the list of registered users. The RA in the implemented architecture had a database that contains names of registered users, this database was used for authenticating users. When the user is found, authentication is confirmed.

Userauthorization

When the user is authenticated by the RA, another window pops up on the user application for entering Bob’s basic information. Bob’s information is used by the RA to identify him in the system. When information is entered by the nurse and forwarded to the RA, the RA searches for the patient in the list of the registered patients in the system. The RA in the implemented system had another database that contains information about all patients enrolled in the system. When the patient is found, the CSR is called for authorization. The RA sends Bob’s information to the CSR along with the users’ information.

The CSR searches for the user in the list and finds out that the user is a nurse and is allowed to access Doc-1 and Doc-2 of patients’ information. Table 6 is the table used by CSR to authorize users. The CSR confirms to the RA that the user is allowed to access Doc-1 and Doc-2 of Bob’s information. The assumption made here was that Bob’s has received a text message from the CSR and has granted consent for the nurse to access his information.

Releasing Information

When the RA receives confirmation of authorization from the CSR to access Doc-1 and Doc-2 of Bob’s information, it does the following:

• It sends Bob’s system ID and indexes of Doc-1 and Doc-2 to the CSP.
• It sends Bob’s system ID and trapdoor tags to the SKA.

Decrypting Information

In response to the requests received from the RA, the CSP searches for Doc-1 and Doc-2 using their indexes and send them to the user. And the SKA does the same for the trapdoors and sends them to the user. The user then has two encrypted documents and two trapdoors. The user application associates trapdoors to their corresponding documents using the string exact match mechanism. And the secret keys in the trapdoors are then used to decrypt the documents.

3.4.2. Testing the architecture

One of the main requirements of storing healthcare information on the cloud is the protection from unauthorized users. The cloud architecture was tested in terms of its ability to prevent unauthorized cloud users from accessing the information. Four tests were performed against the implemented system, summary of the tests and results is presented in Table 7.

Table 7. Summary of architecture test results

Table 7. Summary of architecture test results

Test	Description	Result	Pass/Fail
Unauthorized System Access	Un authorized user made request to download a trapdoor that is stored on the cloud	Access Denied	Pass
Getting access to documents stored on the cloud	A document downloaded without having the secret key.	Document was viewed in its encrypted form	Pass
Unauthorized operations	Attempt made to access the server or the database by sending queries	Access Denied	Pass
Unknown users	Unregistered user attempted to log in to the system	Login failed	Pass

4. Discussion

5. Conclusion

References

1. M. Gupta, M. Thirumalaisamy, S. Shamsher, A. Pandey, D. Muthiah and N. Suvarna, "Patient Health Monitoring using Feed Forward Neural Network with Cloud Based Internet of Things," in 2022 2nd International Conference on Advance Computing and Innovative Technologies in Engineering (ICACITE), Greater Noida, India, 2022.
2. Mamlin, B.W.; Tierney, W.M. The Promise of Information and Communication Technology in Healthcare: Extracting Value From the Chaos. Am. J. Med Sci. 2016, 351, 59–68. [CrossRef]
3. Neves, A.L.; Carter, A.W.; Freise, L.; Laranjo, L.; Darzi, A.; Mayer, E.K. Impact of sharing electronic health records with patients on the quality and safety of care: a systematic review and narrative synthesis protocol. BMJ Open 2018, 8, e020387. [CrossRef]
4. Kalkman, S.; van Delden, J.; Banerjee, A.; Tyl, B.; Mostert, M.; van Thiel, G. Patients’ and public views and attitudes towards the sharing of health data for research: a narrative review of the empirical evidence. J. Med Ethic- 2019, 48, 3–13. [CrossRef]
5. Kim, E.; Rubinstein, S.M.; Nead, K.T.; Wojcieszynski, A.P.; Gabriel, P.E.; Warner, J.L. The Evolving Use of Electronic Health Records (EHR) for Research. Semin. Radiat. Oncol. 2019, 29, 354–361. [CrossRef]
6. Kitamura, T.; Kiyohara, K.; Matsuyama, T.; Hatakeyama, T.; Shimamoto, T.; Izawa, J.; Nishiyama, C.; Iwami, T. Is Survival After Out-of-Hospital Cardiac Arrests Worse During Days of National Academic Meetings in Japan? A Population-Based Study. J. Epidemiology 2016, 26, 155–162. [CrossRef]
7. Gray, C.S.; Barnsley, J.; Gagnon, D.; Belzile, L.; Kenealy, T.; Shaw, J.; Sheridan, N.; Nji, P.W.; Wodchis, W.P. Using information communication technology in models of integrated community-based primary health care: learning from the iCOACH case studies. Implement. Sci. 2018, 13, 87. [CrossRef]
8. W. Oude, L. v. Velsen, M. Huygens and H. Hermens, "Requirements for and Barriers towards Interoperable eHealth Technology in Primary Care," IEEE Internet Computing , pp. 10-19, 2015.
9. Bélanger, F.; Crossler, R.E. Privacy in the Digital Age: A Review of Information Privacy Research in Information Systems. MIS Q. 2011, 35, 1017-1041.
10. T. White, E. Blok and V. D. Calhoun, "Data sharing and privacy issues in neuroimaging research: Opportunities, obstacles, challenges, and monsters under the bed," Special Issue: The ENIGMA Consortium: the first 10 years, pp. 278-291, 2022.
11. Wirth, F.N.; Meurers, T.; Johns, M.; Prasser, F. Privacy-preserving data sharing infrastructures for medical research: systematization and comparison. BMC Med Informatics Decis. Mak. 2021, 21, 1–13. [CrossRef]
12. Public Law , "HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT OF 1996," Public Law 104-191, 104th Congress, 1996.
13. Gunasekara, G.; Dillon, E. Data Protection Litigation in New Zealand: Processes and Outcomes. Vic. Univ. Wellingt. Law Rev. 2008, 39, 457–486. [CrossRef]
14. A. Gkoulalas-Divanis and G. Loukides, "Introduction to Medical Data Privacy," in Medical Data Privacy Handbook, Switzerland, Springer International Publishing, 2015, pp. 1-14.
15. Meng, S.; Fan, S.; Li, Q.; Wang, X.; Zhang, J.; Xu, X.; Qi, L.; Alam Bhuiyan, Z. Privacy-Aware Factorization-Based Hybrid Recommendation Method for Healthcare Services. IEEE Trans. Ind. Informatics 2022, 18, 5637–5647. [CrossRef]
16. Gürsoy, G.; Li, T.; Liu, S.; Ni, E.; Brannon, C.M.; Gerstein, M.B. Functional genomics data: privacy risk assessment and technological mitigation. Nat. Rev. Genet. 2021, 23, 245–258. [CrossRef]
17. Tanriverdi, M. A Systematic Review of Privacy Preserving Healthcare Data Sharing on Blockchain. 2020, ume 4, 31–37. [CrossRef]
18. S. M. Blackman, "Towards a Conceptual Framework for Persistent Use: A Technical Plan to Achieve Semantic Interoperability within Electronic Health Record Systems," in Proceedings of the 50th Hawaii International Conference on System Sciences, 2017.
19. Shahid, J.; Ahmad, R.; Kiani, A.K.; Ahmad, T.; Saeed, S.; Almuhaideb, A.M. Data Protection and Privacy of the Internet of Healthcare Things (IoHTs). Appl. Sci. 2022, 12, 1927. [CrossRef]
20. Priyanga.P and MuthuKumar.V.P, "Cloud computing for healthcare organisation," International Journal of Multidisciplinary Research and Development , pp. 487-493, 2015.
21. Casola, V.; Castiglione, A.; Choo, K.-K.R.; Esposito, C. Healthcare-Related Data in the Cloud: Challenges and Opportunities. IEEE Cloud Comput. 2016, 3, 10–14. [CrossRef]
22. Svensson, A. Challenges in Using IT Systems for Collaboration in Healthcare Services. Int. J. Environ. Res. Public Heal. 2019, 16, 1773. [CrossRef]
23. E. Griffith, "What Is Cloud Computing?," 03 May 2016. [Online]. Available: http://au.pcmag.com/networking-communications-software-products/29902/feature/what-is-cloud-computing. [Accessed 21 March 2017].
24. Cresswell, K.; Hernández, A.D.; Williams, R.; Sheikh, A. Key Challenges and Opportunities for Cloud Technology in Health Care: Semistructured Interview Study. JMIR Hum. Factors 2022, 9, e31246. [CrossRef]
25. P. Mell and T. Grance, "The NIST Definition of Cloud Computing," in National Institute of Standards and Technology , 2011.
26. Doukas, C.; Pliakas, T.; Maglogiannis, I. Mobile healthcare information management utilizing Cloud Computing and Android OS. 2010 32nd Annual International Conference of the IEEE Engineering in Medicine and Biology Society (EMBC 2010). LOCATION OF CONFERENCE, ArgentinaDATE OF CONFERENCE; pp. 1037–40.
27. Griebel, L.; Prokosch, H.-U.; Köpcke, F.; Toddenroth, D.; Christoph, J.; Leb, I.; Engel, I.; Sedlmayr, M. A scoping review of cloud computing in healthcare. BMC Med Informatics Decis. Mak. 2015, 15, 1–16. [CrossRef]
28. R. Zhang and L. Liu, "Security Models and Requirements for Healthcare Application Clouds," in IEEE 3rd International Conference on Cloud Computing (CLOUD) ,, 2010.
29. Sharma, M.; Sehrawat, R. A hybrid multi-criteria decision-making method for cloud adoption: Evidence from the healthcare sector. Technol. Soc. 2020, 61, 101258. [CrossRef]
30. B. Yüksel, A. Küpçü and Ö. Özkasap, "Research issues for privacy and security of electronic health services," Future Generation Computer Systems, pp. 1-17, 2017.
31. H. Raj, M. Kumar, P. Kumar, A. Singh and O. P. Verma, "Issues and Challenges Related to Privacy and Security in Healthcare Using IoT, Fog, and Cloud Computing," in Advanced Healthcare Systems: Empowering Physicians with IoT-Enabled Technologies, Scrivener Publishing LLC, 2022.
32. H. Aziz and A. Guled, "Cloud Computing and Healthcare Services," Journal of Biosensors & Bioelectronics, 2016.
33. Chenthara, S.; Ahmed, K.; Wang, H.; Whittaker, F. Security and Privacy-Preserving Challenges of e-Health Solutions in Cloud Computing. IEEE Access 2019, 7, 74361–74382. [CrossRef]
34. Weir, C.R.; Hammond, K.W.; Embi, P.J.; Efthimiadis, E.N.; Thielke, S.M.; Hedeen, A.N. An exploration of the impact of computerized patient documentation on clinical collaboration. Int. J. Med Informatics 2011, 80, e62–e71. [CrossRef]
35. E Dixon, B.; Embi, P.J.; A Haggstrom, D. Information technologies that facilitate care coordination: provider and patient perspectives. Transl. Behav. Med. 2018, 8, 522–525. [CrossRef]
36. Bertagnolli, M.M.; Anderson, B.; Quina, A.; Piantadosi, S. The electronic health record as a clinical trials tool: Opportunities and challenges. Clin. Trials 2020, 17, 237–242. [CrossRef]
37. Liu, X.; Wang, Z.; Jin, C.; Li, F.; Li, G. A Blockchain-Based Medical Data Sharing and Protection Scheme. IEEE Access 2019, 7, 118943–118953. [CrossRef]
38. G. Cordovano and S. N. Shah, "Requesting Medical Records," Journal of Ahima, 2020.
39. D. Gupta, S. Malik and A. Rana, "Adopting Semantic Interoperability for Improved Healthcare," SSRN, 2022.
40. Rajkumar, N.; Muzoora, M.; Thun, S. Dentistry and Interoperability. J. Dent. Res. 2022, 101, 1258–1262. [CrossRef]
41. L. Devadass, S. S. Sekaran and R. Thinakaran, "Cloud Computing in Healthcare," International Journal of Students’ Research In Technology & Management, vol. 5, no. 1, pp. 25-31, 2017.
42. T. Quatrani, "Introduction to the Unified Modeling Language," IBM, 2003.
43. T. Górski, "UML Profile for Messaging Patterns in Service-Oriented Architecture, Microservices, and Internet of Things," Applied Sciences, vol. 12, no. 24, 2022.
44. Thramboulidis, K.; Christoulakis, F. UML4IoT—A UML-based approach to exploit IoT in cyber-physical manufacturing systems. Comput. Ind. 2016, 82, 259–272. [CrossRef]
45. R. J. Petrasch and R. R. Petrasch, "Data Integration and Interoperability: Towards a Model-Driven and Pattern-Oriented Approach," Modelling, pp. 105-126, 2022.
46. Pufahl, L.; Zerbato, F.; Weber, B.; Weber, I. BPMN in healthcare: Challenges and best practices. Inf. Syst. 2022, 107, 102013. [CrossRef]
47. Schmidt, M.-T.; Hutchison, B.; Lambros, P.; Phippen, R. The Enterprise Service Bus: Making service-oriented architecture real. IBM Syst. J. 2005, 44, 781–797. [CrossRef]
48. Niknejad, N.; Ismail, W.; Ghani, I.; Nazari, B.; Bahari, M.; Hussin, A.R.B.C. Understanding Service-Oriented Architecture (SOA): A systematic literature review and directions for further investigation. Inf. Syst. 2020, 91, 101491. [CrossRef]
49. Aziz, O.; Farooq, M.S.; Abid, A.; Saher, R.; Aslam, N. Research Trends in Enterprise Service Bus (ESB) Applications: A Systematic Mapping Study. IEEE Access 2020, 8, 31180–31197. [CrossRef]
50. Agbo, C.C.; Mahmoud, Q.H.; Eklund, J.M. Blockchain Technology in Healthcare: A Systematic Review. Healthcare 2019, 7, 56. [CrossRef]
51. Jin, H.; Luo, Y.; Li, P.; Mathew, J. A Review of Secure and Privacy-Preserving Medical Data Sharing. IEEE Access 2019, 7, 61656–61669. [CrossRef]
52. Abdellatif, A.A.; Al-Marridi, A.Z.; Mohamed, A.; Erbad, A.; Chiasserini, C.F.; Refaey, A. ssHealth: Toward Secure, Blockchain-Enabled Healthcare Systems. IEEE Netw. 2020, 34, 312–319. [CrossRef]
53. Guo, R.; Shi, H.; Zheng, D.; Jing, C.; Zhuang, C.; Wang., Z. Flexible and Efficient Blockchain-Based ABE Scheme With Multi-Authority for Medical on Demand in Telemedicine System. IEEE Access 2019, 7, 88012–88025. [CrossRef]
54. Xi, P.; Zhang, X.; Wang, L.; Liu, W.; Peng, S. A Review of Blockchain-Based Secure Sharing of Healthcare Data. Appl. Sci. 2022, 12, 7912. [CrossRef]
55. J. Qu, "Blockchain in medical informatics," Journal of Industrial Information Integration, vol. 25, 2022.
56. F. Alhaddadin, J. A. Gutiérrez and W. Liu, "Privacy-aware cloud-based architecture for sharing healthcare information," Auckland University of Technology, Auckland, New Zealand, 2020.
57. R. Curtmola, J. Garay, S. Kamara and R. Ostrovsky, "Searchable Symmetric Encryption: Improved Definitions and Efficient Constructions," in 13th ACM Conference on Computer and Communications Security, 2006.
58. D. Boneh, G. D. Crescenzo, R. Ostrovsky and G. Persiano, "Public Key Encryption with keyword Search," in International Conference on the Theory and Applications of Cryptographic Techniques, Berlin, Heidelberg, 2004.
59. Y.-C. Chang, "Single Database Private Information Retrieval with Logarithmic Communication," in The 9th Australasian Conference on Information Security and Privacy, Sydney, Australia, 2004.
60. E. Goh, "Secure Indexes," IACR ePrint Cryptography Archive, 2003.
61. Eludiora, S.; Abiona, O.; Oluwatope, A.; Oluwaranti, A.; Onime, C.; Kehinde, L. A User Identity Management Protocol for Cloud Computing Paradigm. Int. J. Commun. Netw. Syst. Sci. 2011, 04, 152–163. [CrossRef]
62. Amazon, "aws," 2019. [Online]. Available: https://aws.amazon.com.
63. Marwaha, J.S.; Landman, A.B.; Brat, G.A.; Dunn, T.; Gordon, W.J. Deploying digital health tools within large, complex health systems: key considerations for adoption and implementation. npj Digit. Med. 2022, 5, 1–7. [CrossRef]