A Comparative Study of Bluetooth SPP, PAN and GOEP for Efficient Exchange of Healthcare Data

Objectives: Current research aims to address the challenges of exchanging healthcare information, since when this information has to be shared, this happens by specifically designed medical applications or even by the patients themselves. Among the problems that the Health Information Exchange (HIE) initiative is facing are that (i) third party health data cannot be accessed without internet, (ii) there exist crucial delays in accessing citizens’ data, (iii) the direct HIE can only happen among Healthcare Institutions. Methods: Towards the solution of these issues, a Deviceto-Device (D2D) protocol has been specified, running on top of the Bluetooth protocol for efficient data exchange. This research is focused on this D2D protocol, by comparing the different Bluetooth profiles that can be used for transmitting this data, based on specific metrics considering the probabilities of transferring erroneous data. Findings: An evaluation of three Bluetooth profiles takes place, concluding that two of the three profiles must be used to respect the D2D protocol nature and be fully supported by the main market vendors’ operating systems. Novelty: Based on this evaluation, the specified D2D protocol has been built on top of state-of-the-art short-range distance communication technologies, fully supporting the healthcare ecosystem towards the HIE paradigm.

Furthermore, the northern European countries (Finland, Sweden, Denmark, and Estonia) are among the first ones in the transformation of their administrations to a digital form [5]. Through services which can be found online, or the identity card which is connected everywhere, almost all the different citizen are able to use the Internet connection for procedures including cases of administration, as well as health services. In Denmark, the Medcom [6] initiative took place in 1994 as a network for health information in a national level, including a portal connected over the Internet for managing healthcare information among healthcare practitioners and citizens. Sweden included at national level a strategy towards electronic healthcare in 2006, namely the Swedish Medical Record (NPÖ). The Swedish Medical Record [7] gives authorization access to specific healthcare personnel, and consequently it can receive connections from any existing computer system. In Spain, it has been launched the Diraya program [8] having as a goal to ensure continuous healthcare of high value through the harmonization of the ingested data for being easily accessible to every stakeholder, including both citizens and healthcare personnel. It is undeniable that a system in the EU for exchanging healthcare data would provide many benefits since it would facilitate EU citizens to easily travel among the different countries without thinking the challenges of not having along with them their personalized medical prescriptions or treatments. Furthermore, in the case that an emergency occurs abroad, the citizen's medical records would be accessed in a faster and easier way. Hence, citizens would receive faster and more efficient treatment in a more secure manner, including also appropriate and personalized care. Nevertheless, this is not only the case for the EU Member States, since the need for exchanging health information among healthcare practitioners is rapidly growing along with multiple challenges and efforts at national and worldwide level, with the overall goal to improve the quality, safety, and efficiency of health care delivery [9,10].
Among the various implementations and initiatives towards the Health Information Exchange (HIE) paradigm, some of them can lead to a time-consuming process which can result in inaccurate information, with increased inefficiencies, leading to care of low value. Additional issues are (i) that third party health data cannot be accessed without internet connection -which cannot be always available, (ii) that there exist crucial delays in accessing current citizens' data, while (iii) a major obstacle is that direct exchange of health information can only happen among Healthcare Institutions, without the active participation or involvement of the current data owners (i.e., citizens). Moreover, there exist several smart devices' applications that are offering the ability to exchange health information between citizens and healthcare practitioners, which are however using vendor-specific and non-interoperable protocols, without respecting any common data representation or terminology structures. Finally, the usage of multiple credentials to authenticate citizens and Healthcare Institutions -even in the same countries, could be also a major barrier towards this objective. Nevertheless, most of these research projects and initiatives are using different protocols, facilitating the process of long-range and short-range distance communication towards health data exchange.
In this paper, a newly specified protocol is being taken into consideration, the Device-to-device (D2D) Protocol [9], in the form of a secure communication protocol for exchanging messages and healthcare-related data between two nearby devices, adopting short range communication technologies, and in particular Bluetooth v4.0. Shortly, the D2D protocol is being specified as an open specification protocol that can give the ability to EU citizens to exchange health information stored in their smart devices, directly with Healthcare Institutions. This health information is structured in a common format with respect to the widely adopted Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR) standard [12], whereas the D2D protocol can check the conformance of the exchanged information based on specifically parameterized HL7 FHIR interoperability profiles. Furthermore, the D2D protocol provides a fully encrypted communication channel with easily usable symmetric key authentication, supporting data encryption and decryption mechanisms [13], without allowing any third-party access to this communication. Hence, taking into consideration the D2D protocol and its Bluetooth-based communication, three different Bluetooth profiles will be used and compared for securely exchanging health data between a citizen and a Healthcare Practitioner, to understand the Bluetooth profiles' nature and identify their strengths and potential cases of usage. It should be mentioned that these Bluetooth profiles form the definitions of possible applications that provide the specification of the overall behaviors that Bluetooth-enabled devices use for communication with other Bluetooth devices, in a specific application area.
The rest of the document is structured as follows. Section 2 presents the related work regarding techniques, implementations, and research projects supporting data and health data exchange, concluding to the needs for using the Bluetooth protocol for the cases of HIE. In Section 3, it is presented the evaluation scenario under which the overall comparison will take place, Section 4 involves the discussion of the derived results, while Section 5 concludes with our next steps.

2-1-Information Exchange Techniques
With regards to the research conducted using a mix of distance communication protocols for exchanging data of any type (i.e., not only health data), Mochel et al (2007) [14] present a Bluetooth scatternet protocol (SNP) that gives the ability to the user to have a serial link to all the connected members in a transparent wireless Bluetooth network. The authors show how their software layer makes several tasks simpler, such as the synchronization of central pattern generator controllers for actuators, the collection of sensory data and the construction of modular robot structures. In Qiu et al. (2020) [15], the authors propose a method for securely storing and exchanging data that consists of a specific encryption algorithm along with fragmentation and dispersion for data safety and privacy protection, even when both transmission media and keys are compromised. Furthermore, Chong et al. (2017) [16] describe a system consisting of an "image beacon" with the ability of broadcasting color images over a very long period using a set of devices with Bluetooth Low Energy (BLE) technology. To this end, Chung et al. (2015) [17] proposed an information exchange method among devices at short-range distances, through inaudible frequencies and Wi-Fi.

2-1-1-Long-range Distance Health Information Exchange Techniques
Among the research projects which are using long-range distance wireless communication technologies to exchange health information, there exist several solutions. The Direct Secure Messaging [18] is a digital messaging tool which is used in healthcare for such communication and can be used with multiple interfaces such as an email client, or healthcare Information Technology (IT) portals. Carequality [19] provides a national-level framework of interoperability to facilitate information exchange among specifically designed networks. Through using cloud fax [20], documents and reports in digital format can be stored into folders and arranged in such a way, without the need of any physical paper. KONFIDO [21] is a research project with the goal to construct a way for cross-border health information exchange in the most secure manner, being built on top of existing and continuously evolving EU frameworks, (OpenNCP, epSOS, eIDAS). Another research is from Gavrilov et al. (2018) [22] where the authors propose a model for an Electronic Health Record (EHR) for Health Data Exchange based on a SaaS (Software as a service) service model developed on top of cloud computing technology. Furthermore, in Masud et al. (2018) [23] it was implemented an anonymous, query-based, on the fly secure data exchange protocol between two clouds for collaborative cloud-based healthcare environments.

2-1-2-Short-range Distance Health Information Exchange Techniques
As for the research projects aiming in short-range distance communication protocols for exchanging healthcare data, in Basjaruddin et al. (2017) [24], it was developed a medical record system based on Near Field Communication (NFC). The authors developed an electronic medical record (EMR) application where it is used by healthcare practitioners and patients. The patients use the application only for reading the content while the healthcare practitioners can view and change the EMR content, even add a new patient EMR. De Almeida et al. (2020) [25] performed a research in Wi-Fi Direct in which WPA2 devices, such as smartphones, laptops etc. can establish a direct Wi-Fi connection without using a wireless access point for exchanging health data. In the same context, Fuliang et al. (2020) [26] also did a research in Wi-Fi Direct and they proposed a real-time data transmission system by using Wi-Fi Direct for the transfer of healthcare data. The results of the research showed that the healthcare data are transported with greater reliability through Wi-Fi Direct than through Wi-Fi.

2-2-Bluetooth Protocol
Based on the extensive list of methodologies that are using both short-range and long-range distance communication technologies, it becomes clear that several research tasks and methodologies are offering solutions to solve the challenge of exchanging healthcare information. These methodologies do not consider however challenges such as the fact that third party health data cannot be accessed without internet connection, that there exist crucial delays in accessing current citizens' data, or that there exist several smart devices' applications which are using vendor-specific and noninteroperable protocols to exchange data. In our work in [11], the D2D protocol has been specified, serving the purposes of exchanging healthcare information, providing an open specification protocol for transferring health information that is structured in a common format with respect to the widely adopted HL7 FHIR standard, providing a fully encrypted communication channel, and being functional even in cases where internet connection is not available. Among the different protocols and research projects, in [27] we have made a thorough research with regards to which protocol is most suitable for transferring health data, according to specific data transmission and security requirements, in shortrange distances. Based on this research, we have concluded that the Bluetooth protocol is the most suitable candidate for such requirements, hence in the current paper this research is being expanded on identifying the most suitable Bluetooth profile to be used for such cases. In general, Bluetooth can be best described as a packet-based short-range wireless communication technology consisting of an architecture with both masters and slaves, where the involved devices can exchange roles using their applications, upon specific agreement. Prior to explaining and analyzing the Bluetooth profiles to be compared, there should be analyzed some Bluetooth-related terminologies [28], regarding the Bluetooth controller, Bluetooth Logical Link Control and Adaptation Protocol (L2CAP) and the Bluetooth profiles, which will be thoroughly used on the overall comparison.

2-2-1-Bluetooth Controller
The Bluetooth controller consists of the baseband and the radio that is responsible for the link management functionality, to store data in specific packets, to decode and encode the channel, as well as to determine the frequency of operations.
Channels: A channel consists of a frequency with a pseudorandom nature with the ability of hopping sequence, slot timing, and an access code. In Bluetooth Channels, specific transports take place which can be either asynchronous (ACL) or synchronous (SCO). Moreover, the Logical links which are used on top of the transports create the connection between the master and the slave.
Packets: A Bluetooth packet consists of three parts: an access code, a payload, and a packet header, where additionally the payload has a specific payload header and a data unit at a higher layer. This payload header has specific information regarding the link control, as well as an error check. This standard defines several packet types, while data transmission is using different packet types. All the different kinds of transports use common packets, being usually called as control packets. In that case, the POLL packet is used by the master for polling the slaves, whereas the NULL packet is used for data packets acknowledgment.
Automatic Repeat Request (ARQ): Bluetooth uses an ARQ for the retransmission of baseband packets that includes errors. It should be taken into consideration that ARQ tries packet transmission until it either succeeds or a timeout occurs, leading to the L2CAP packet flushing.

2-2-2-Bluetooth L2CAP
The L2CAP defined a data link layer with the ability to provide connection-oriented, as well as connectionless services, to protocols and applications that can be found in upper layers. In L2CAP, the flush timeout describes the time needed to transmit a packet before it is dropped by the controller. Moreover, the retransmission timeout describes the total time needed in order for the L2CAP to wait for receiving an acknowledgement for an information frame before its retransmission. The mode of the L2CAP channel specifies its configuration, and the way it must behave, consisting of the (i) Basic mode without any support of retransmissions, and as a result it has low reliability, and the (ii) Streaming mode that is only used for data with isochronous nature.

2-3-Bluetooth Profiles
In the case of Bluetooth, a device should understand specific Bluetooth profiles, in the form of definitions of specific applications which have a pre-defined nature that Bluetooth devices use to communicate with each other. In these profiles it can be found the settings to change and to manage the overall communication from the start. Through using a Bluetooth profile, it saves time for transmitting the parameters anew before the bi-directional link becomes effective. As a result, for two devices to communicate to complete a specific task, both devices must use a common profile. As depicted in Figure 1, there exist several Bluetooth Profiles, according to the task that must be performed and the domain in which they should be applied. These domains are categorized into five (5) main categories, with regards to the Medical domain (i.e., Medical Group) that deals with medical devices supporting Bluetooth connection, the Serial Port Profile domain (i.e., SPP Group) that consists of devices that emulate serial cable data transfer, the Telephony domain (i.e., Telephony Group) that deals with smart Bluetooth connected devices that support mobile phones and communication devices, the Personal Access Network domain (i.e., PAN Group) consisting of devices that have the ability to create local network groups to communicate over Bluetooth, and the Audio/ Video domain (i.e., A/V Group) that supports Bluetooth devices that deal with audio and video files, which in most cases are of large data size and complexity. Some

2-3-1-Bluetooth Serial Port Profile (SPP)
The Bluetooth SPP profile [30] defines the requirements for Bluetooth devices that are necessary for creating emulated serial cable connections using the RFCOMM protocol between the involved devices. The requirements can be described as services which are provided to the involved applications, as well as through the definition of the features and processes that are needed for communication among the interacting devices. In the Bluetooth SPP profile, the following roles are defined:  Initiator: it initiates a connection to another device.

2-3-2-Bluetooth Personal Area Network (PAN) Profile
The Bluetooth PAN profile [31] describes the way that two or more Bluetooth devices can create an ad-hoc network and how it can be re-used for accessing a remote network through a network access point. For the PAN profile, two general scenarios are usually discussed: (1) the Network access points, and (2) the Group Ad-hoc Networks. Each case has unique network architecture and requirements, creating multiple combinations of a PAN profile. In the Bluetooth PAN profile, the following roles are defined:  Group Ad-hoc Network (GN) and GN service can be considered as a Bluetooth device that supports the GN service for forwarding Ethernet packets to each of the connected Bluetooth devices, speaking about the PAN users, as needed.
 PAN User (PANU) is the Bluetooth device that can use either the NAP or the GN service. PANU supports the client role for both the NAP and GN roles. Figure 3 shows the protocols and entities used in the Bluetooth PAN profile. The Baseband, LMP and L2CAP are the parts of the Bluetooth protocols that reside in the OSI layer. As in the previous case, SDP is the Bluetooth Service Discovery Protocol, while the Management Entity (ME) is the entity that coordinates the procedures for the initialization, parameterization, and connection management. The required procedures that should be defined in the Bluetooth PAN profile are divided in two categories, following different steps based on whether the PANU wants to connect to a GN or the GN wants to connect to a PANU in order to finally create an ad-hoc network. More details regarding the usage of this Bluetooth profile can be found in Kuijpers et al. (2002) [31].

2-3-3-Generic Object Exchange Profile (GOEP)
The Bluetooth GOEP profile [32] describes the protocols and procedures that the involved applications must use, providing the usage models for facilitating the overall object exchange capabilities. Such models can be a Synchronization, File Transfer, or Object Push model. In the Bluetooth GOEP profile, the following roles are defined:  Server: it provides an object exchange server to and from which data objects have the ability to be pushed and pulled, respectively.
 Client: it can push or/and pull data object(s) to and from the Server.  Figure 4 shows the protocols and entities used in the Bluetooth GOEP profile. The Baseband, LMP and L2CAP are the OSI layer 1 and 2 Bluetooth protocols. RFCOMM is the Bluetooth adaptation of GSM TS 07.10. SDP is the Bluetooth Service Discovery Protocol, while OBEX is the Bluetooth adaptation of IrOBEX. The Application Client layer gives the ability to send and retrieve data object from the side of the Server using the OBEX operations. The application Server is offering storage capabilities for the data to and from which the data object can be sent or retrieved. More details regarding the usage of this Bluetooth Profile can be found in [32].

3-1-Evaluation Scenario and Working Environment
For the purposes of the D2D protocol, six (6) different programming libraries have been designed, implementing the functionality of the protocol. In more detail, the first set of libraries implements the functionality of the D2D protocol using the Bluetooth SPP profile, the second set of libraries implements the functionality of the D2D protocol using the Bluetooth PAN profile, whereas the third set of libraries implements the functionality of the D2D protocol using the Bluetooth GOEP profile.
In all cases, apart from the programming libraries two applications were designed and implemented in order to be used for invoking the functions and operations offered by the implemented programming libraries. Having in mind that the D2D protocol aims in transferring health data over Bluetooth between a citizen and a Healthcare Practitioners (HCP), these two applications (i.e., Citizen Application, HCP Application) are serving the needs of the citizen and the HCP accordingly. These applications were designed and implemented for Android OS devices, using Android Studio [33]. The reason that it was implemented Android OS applications instead of iOS/iPadOS applications is two-fold: (i) Android offers easier usage of the Bluetooth technologies, and (ii) the reason of this paper is to compare the specification of the D2D protocol on top of different Bluetooth profiles, and not the implementation of the end-users' applications.  5 depicts a flowchart of the scenario which was followed to compare the Bluetooth SPP, the Bluetooth PAN, and the Bluetooth GOEP profiles, using the D2D protocol paradigm, in which a citizen and an HCP are securely exchanging health data structured in HL7 FHIR format over Bluetooth, using the implemented applications. Shortly, during the Bluetooth Connection step, the two involved parties have to connect to each other over the Bluetooth Protocol, supporting one of the three different Bluetooth profiles. As soon as the HCP and the Citizen are connected, in the next step (Demographic Data Exchange) the two parties must identify each other by exchanging over Bluetooth, through the D2D protocol, identification data from the side of the supporting Healthcare Organization (for the HCP), and personal data (i.e., Personal Identity for the Citizen). The next step includes the exchange of Healthcare Data (Healthcare Data Exchange), in which the identified interacting parties are exchanging the requested data to be securely transferred through the D2D protocol and be visualized and examined from the side of the HCP. The overall process is then terminated, where in the last step (Bluetooth Connection Closure), the overall connection between the Citizen and the HCP terminates, and both parties stop the overall interaction. In Figure 6a, a medical image is depicted that was exchanged through the D2D protocol having the size of 35 Mbytes and is depicting a random hand X-ray result. What is more, in Figure 6b, an instance of the exchanged healthcare dataset that was used for evaluation is provided, including the demographic details of a random citizen structured in HL7 FHIR format (i.e., name, address, contacts, and identity number), having the size of 6 Kbytes.

3-2-Device-to-Device Protocol over Bluetooth
In order for the Bluetooth pairing and connection between the devices that host the Citizen app and the HCP app to be realized, a specific process between the client and the server application must be followed. In our case, both the Citizen app and the HCP app will behave as a true peer-to-peer endpoint by exposing both server and client behavior. Typically, the pairing process that is being followed is based on the Figure 7.
In general, for Bluetooth-enabled devices to exchange data, they must create a communication channel through a specific process of pairing. One of the devices has the role of the discoverable device, which is made available for receiving requests of incoming connection. The other device identifies the discoverable device through a process for service discovery. After the acceptance of the pairing request by the discoverable device, the devices bond to each other through exchanging security keys, which are cached for later use. As soon as these processes are completed, the two devices can interact and exchange data. When the overall communication is completed, the initiator device frees the communication channel that had linked it to the discoverable device. The two devices have a bonded status, in order to be easily reconnected in a future session. This process can be summarized as follows:  Initialization: The Bluetooth enabled applications initialize the Bluetooth stack.
 Client: A client consumes the remote services. This is done by first discovering any nearby devices, and afterwards for each discovered device it searches for services of interest  Server: A server makes all the services available to the previous clients. It registers these services in the SDDB, and it then waits for receiving connections, and accepts them, serving the clients that make them. In the case that the service is not needed anymore, the application removes it from the SDDB.
As described before, to use Bluetooth, a device must be compatible with the subset of Bluetooth profiles.

3-3-Evaluation Metrics
To compare the Bluetooth SPP profile, the Bluetooth PAN profile, and the Bluetooth GOEP profile, the following evaluation metrics were considered for the three profiles, for their further comparison with regards to the purposes of the D2D protocol [34].
Transmission time: This metric refers to the transmission time (transfer rate), in which a data exchange process takes place with each different Bluetooth profile.
Power Consumption: This metric refers to the power that the devices consume when using the Bluetooth profiles.
Probability of packet flush: A specific flush timer is initiated when a packet enters the transmit buffer of the controller. In the case of timeout, the packet is flushed. Each data packet must have a specific number of slots in order to have a successful data exchange. Generally, the Bluetooth baseband uses an ARQ in order to send again baseband packets that contain errors. ARQ retransmissions can happen for a specific number of times, denoted by the number of transmissions The probability of packet flush is given by Equation 2: Probability of L2CAP retransmission: A L2CAP retransmission happens in the case that there is a timeout in the retransmission timer. Such thing can happen if the original packet or its acknowledgment is flushed. Consequently, when both packets are transmitted without any errors, no other retransmissions take place. The probability of L2CAP retransmission is given by Equation 3: where and _ are the threshold values for the number of retransmissions of measurement packets and acknowledgments, respectively. The probability distribution of the random variable , in accordance to the number of L2CAP retransmissions is given by Equation 4: Probability of packet loss: Packets which are not retransmitted by L2CAP are lost in the case of flushing. This can happen to all streaming packets and packets that use the Bluetooth SPP and Bluetooth GOEP profiles. Hence, for these profiles the loss probabilities are equal to the flushing probabilities, while for the Bluetooth PAN profile, the loss probabilities are the L2CAP retransmission failure probabilities. Hence, for SPP and GOEP packets the probability of packet loss is provided by Equation 5 : Furthermore, for PAN packets the probability of packet loss is given by Equation 6:

4-Results and Discussion
The overall process described by the scenario was followed for the three (3) different Bluetooth profiles, while it was repeated ten (10) different times, calculating the results for the different evaluation metrics for each case. Furthermore, in order to perform the overall testing scenario, and test the overall specification of the D2D protocol, there have been developed two different applications with a basic User Interface (Citizen application and HCP application), for invoking the operations offered by the D2D protocol, and serving the needs of the citizen and the HCP. The Citizen application has been developed in Android Studio using Java for Android (Android v4.3.1), while the HCP application has been developed in NetBeans using Java (Java v8.0). For both applications, an initial dataset was loaded (structured in XML HL7 FHIR format) in order to be exchanged following the overall process defined by the D2D protocol in Section 3. Figure 8 depicts an instance of the basic user interface of these two applications, showcasing that the two applications are paired, while the interacting parties are successfully connected. For each case, the different Bluetooth profiles were used, for the same data types and sizes.

Figure 8. Basic user interfaces of the interacting applications.
The average mean of the results of the ten (10) iterations are depicted in Table 1, for each one of the different evaluation metrics. Based on the results of Table 1, among the different evaluation metrics, the Bluetooth SPP profile can be considered as the best candidate for the purposes of the D2D protocol. It performs much better in the provided scenario, achieving higher transmission time with decreased probabilities of packet loss, flush and L2CAP retransmission. In more detail it can be seen that with regards to the Transmission time, the Bluetooth SPP profile performs better since its average mean was almost 6 sec., in comparison with the Bluetooth PAN profile which was 7 sec. and the Bluetooth GOEP profile which was 8 sec. Such a difference is caused due to the fact that the Bluetooth SPP profile follows a different protocol stack than the other two, minimizing the overall obligatory pairing and data exchange interactions (Figure 9).

Figure 9. Transmission Time results of the Bluetooth SPP, Bluetooth PAN and the Bluetooth GOEP profiles.
As for the Power consumption, in all cases there was not any significant difference, since for the three Bluetooth profiles there was not calculated any major battery consumption of the interacting devices. In more detail, the BT-Power-Calc [35] was parameterized to calculate the Bluetooth power consumption. This calculator included both advertising and peripheral use cases, having also the ability to configure different use case profile parameters. The estimate of the overall power consumption was provided, depicting that in all three cases the consumption was extremely low to be considered as a metric of high impact. Consequently, this metric was considered to be out of context for the current scenario. With regards to the Probability of packet flush (Figure 10a), the Bluetooth GOEP profile dealt with most packet flushes, since it is built for exchanging binary objects having a nature similar to client-server applications, and as a result the exchanging of roles between the involved parties was leading to more packet flushes, increased L2CAP retransmission (Figure 10a) and as a result, an increased probability of packet loss (Figure 10c). On the other hand, as for the Probability of packet flush ( Figure 10a) the Bluetooth SPP profile was slightly better than the Bluetooth PAN profile, since the nature of the D2D protocol is more identical to the environment created and supported by the Bluetooth SPP profile.
Consequently, by the time that the D2D protocol follows the paradigm of emulating a serial cable data transfer instead of creating a local area network, this resulted into less L2CAP retransmission and packet losses for the Bluetooth SPP profile (Figures 10b and 10c), resulting into being the most appropriate candidate for the overall D2D protocol communication. Nevertheless, it should be considered that the overall implementation was performed mainly for devices supporting Android operating systems. However, it should be also mentioned that the overall purpose of the D2D protocol is to be supported by the top market OS, including the support of the operating systems of Windows and Apple devices. Despite the fact that Windows devices do not have any specific restrictions and requirements, it has been studied that Apple generally supports a short list of Bluetooth profiles, such as the Hands-Free Profile (HFP), the Phone Book Access Profile (PBAP), or the Advanced Audio Distribution Profile (A2DP), which however cannot serve the purposes of the D2D protocol. Among the supported Bluetooth profiles, the Bluetooth PAN profile is considered as the most appropriate for the current D2D protocol specification for Apple devices, since the Bluetooth SPP profile cannot be supported by the latter due to Apple's development restrictions [36]. Consequently, the overall study results that in the case that the D2D protocol would not be considered to be vendor specific but would only be considered to be efficient and effective, then the Bluetooth SPP profile should be the only choice among the different Bluetooth profiles. However, taking into consideration the desired nature of the D2D protocol to be fully supported by the main market OS, it should be specified for also supporting the Bluetooth PAN profile for the cases of Apple devices. Nevertheless, it should be considered that the overall implementation was performed mainly for devices supporting Android operating systems. However, it should be also mentioned that the overall purpose of the D2D protocol is to be supported by the top market operating systems, including the support of the operating systems of Apple devices. To this context, it has been already defined that Apple generally supports a short list of Bluetooth profiles, such as the Hands-Free Profile (HFP), The Phone Book Access Profile (PBAP), or the Advanced Audio Distribution Profile (A2DP), which however cannot serve the purposes of the D2D protocol. Among the supported Bluetooth profiles, the Bluetooth PAN profile is considered as the most appropriate for the current D2D protocol specification for Apple devices, since the Bluetooth SPP profile cannot be supported by the latter due to Apple's development restrictions [26]. Consequently, the overall study results that in the case that the D2D protocol would not be considered to be vendor specific but would only be considered to be efficient and effective, then the Bluetooth SPP profile should be the only choice among the different Bluetooth profiles. However, taking into consideration the desired nature of the D2D protocol to be fully supported by the main market operating systems, it should be specified for also supporting the Bluetooth PAN profile for the cases of Apple devices.

5-Conclusion
The objective of this paper was to deliver a high-level specification of the proposed D2D protocol that is used on facilitating the exchange of healthcare data over Bluetooth, as well as a descriptive evaluation of the different Bluetooth profiles that can implement the overall D2D protocol functionality. For this evaluation, specific metrics were chosen to compare and evaluate the performance and the efficiency of each different Bluetooth profile, trying to present their nature and behavior through exchanging healthcare data between the interacting applications of the involved parties (healthcare practitioners, citizens), without the usage of internet connection. The conclusions to that study are that the D2D protocol could be specified with a more generic nature, being more efficient and effective, through prioritizing the Bluetooth profiles that could be potentially used for its purposes. Nevertheless, as it was already made clear there exist several implementations and research projects that aim towards the goal of securely exchanging health data. Most of them are using either specifically specified or designed vendor-specific protocols, whereas there exist implementations which are trying to solve the aforementioned issue, in a more generic scope. It is within our future goals to perform additional evaluation with several Bluetooth profiles, as well as different short-range distance communication protocols (e.g., Wi-Fi Direct), including additional evaluation metrics whose nature will be changing according to requirements derived from the size of the data to be transferred, the importance of the data transfer, or the circumstances under which the data transfer will take place.

6-2-Data Availability Statement
No new data were created or analyzed in this study. Data sharing is not applicable to this article.

6-3-Funding
The research leading to this result has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 826106 (InteropEHRate project).

6-4-Conflicts of Interest
The authors declare that there is no conflict of interests regarding the publication of this manuscript. In addition, the ethical issues, including plagiarism, informed consent, misconduct, data fabrication and/or falsification, double publication and/or submission, and redundancies have been completely observed by the authors.