Personal Information Base Case Study
Introduction
The word “personal” keeps coming up whenever people talk about Bluetooth technology. Personal Area Networks, Personal Devices—it’s all about bringing communications down to the local personal level. So the next logical step is to use Bluetooth technology to maintain a personal information base! The example we will be working with in this chapter looks at a hospital environment as a case study for implementing Bluetooth technology.
In the past, medical records were limited to a few salient observations. Today, reams of data can be gathered by complex monitoring systems. A lot of that data is lost because it is difficult to move around and store. By creatively using communication applications, we can send the data with the patient so it’s easily accessible when needed. By making the database personal and transportable, we guarantee its instant availability. By using Bluetooth wireless technology, we provide an open standard for accessing the data, meaning that if a patient moves from one area or clinic to another, all the data required can accompany them and should be instantaneously accessible—anywhere and anytime.
What would such a Personal Information Base (PIB) device for a medical environment be able to do? It could store all the patient information, such as contact details, digital photographs, calendar of appointments with the doctor and hospital, as well as all the information gathered from tests, be they electronic or manual. These are just the basic details that can be stored. The potential to store more data in any form is infinite.
The advantages of a PIB device for both patient and hospital are security, instant access to almost up-to-date information, electronic and efficient transfer, and safe and compact storage over time.
Figure 10.1 shows what a PIB card could look like and how data can be exchanged by a Data Access Terminal (DAT). Both the PIB and DAT can exchange information with the local server. The local server keeps a copy of the data on the PIB and can synchronize data from other departments and DATs. The synchronised data is backed up to the Central Control, which can then distribute the data to all the hospitals and local servers. The aim of the system is to ensure that the patient’s information is stored in at least two places at any one time. Duplicate storage means that data can be recovered if there is a loss of any element of the system.
Most of the elements are standard “off-the-shelf” components enabled with either wireless or wired networking. This helps to keep infrastructure costs down, as the elements can be reused for multiple purposes. The software to run the PIB data synchronization and distribution should have an open nonproprietary interface as well as being reliable and robust. This could be either commercially available or public domain.
The only specialized element in the previous figure is the PIB card, as this has very stringent requirements. It has to be mechanically durable, robust, and water-resistant yet at the same time remain low in cost. Since personal information is sacred for the people to whom it belongs, there will be secure communications established which the owner will control, allowing him/her to manage the amount of data that’s accessible at any given time.
Why Choose Bluetooth Technology?
There are many communications technologies available, and wireless is not always the best solution for every need. This section looks at the requirements of the PIB device for our sample hospital environment as well as the challenges the system imposes, and considers the factors that influence a choice of communications technology for a PIB.
Requirements for PIB Devices
A hospital environment imposes its own requirements on devices, but many of these overlap with requirements for devices you use in an office or home. The PIB for a hospital environment needs to have all of the following characteristics:
Let us examine each of these requirements in more detail.
It must be a low-cost option. The PIB must be affordably priced, otherwise hospitals or patients will not use them. Exactly what is affordable will depend upon the context. For the UK national health system a target price of $20 to $50 would be acceptable, and for a privately run luxury health clinic, a higher price would be acceptable. In both cases the acceptable price will depend upon the features and capability of the device. The cost of the major components of any such device is likely to come down over time. These major components are reprogrammable memory (flash), color liquid crystal displays (LCDs) and robust mechanics. Bluetooth chips are lower cost than other wireless technologies, so they fit well with low-cost requirements.
The PIB must be portable. The PIB should be small in size and comfortable to carry. It needs to be capable of being attached or clipped to the patient, like a name badge. An ideal size is a single slot PC card (100 mm by 50 mm by 4 mm). Bluetooth modules are small in size, so Bluetooth fits well with portable devices. Furthermore, using wireless connections eliminates the need for carrying around bulky cables, and the adapters, which seem to always be needed, to cable different systems together.
It should be mechanically robust. The PIB should be able to take the shock of falling on the floor, being under body weight, and perhaps even being accidentally trodden on! All of the interfaces and the PIB device itself should be durable in everyday uses, and as a target should have a life span of two to three years of constant use. Wires require mechanical connections to be made. Low-cost molded plugs are notoriously unreliable, so wireless technology is ideal for creating a mechanically robust design as all the operating parts can be hidden inside a case.
Communications must be reliable. Transfer of information has to be guaranteed. Radio environments by their very nature are subject to interference, thus making them unreliable. Therefore, it is desirable to have alternative interfaces such as Infrared, which could be used if a radio connection cannot be established for some reason. Such an alternative interface could also be useful for areas where radio operation is not allowed.
The PIB must be hygienic. If the PIB is to be carried around with a patient, it should be easy to clean. By eliminating sockets for wired connectors, crevices which could harbor dirt and germs are removed. This means that wireless technology is ideal for creating a hygienic and easily-cleaned device.
It must conform to medical restrictions. The United States have allowed ISM band within hospitals, for telemetry purposes. However, there may be areas of a hospital where ISM band equipment cannot be used, as it would interfere with sensitive monitoring equipment. Therefore, any devices fitted with Bluetooth wireless technology would have to have an easy way to disable the radio. (This is a requirement for all portable devices, not just medical devices, as airlines do not permit the use of ISM radios on aircraft. In the same way that cellular phones are switched off on aircraft, Bluetooth devices must also have their radios disabled on airplanes.)
It must be user-friendly. Both the PIB device and the Data Access Terminal it connects with must be easy to use. It must be simple to exchange information, add appointments, and enable reminders. Again, this is a requirement that applies to all devices, whether for hospital, home, or workplace.
The PIB device doesn’t really need many interfaces except for wireless connectivity, a button, some indication like an LED, to show connectivity and activity, and perhaps a speaker for audio output. This means that an interfacing device is required for extracting and viewing the data.
Adequate storage must be accounted for. A target might be to store information for 5 years, including: personal information and photographs, visits to a GP, hospital and associated notes and information gathered from any tests. X-rays and CAT scans require extremely high-resolution images, so it would probably not be practical to store these within the PIB. Nevertheless, a considerable amount of storage is required, for example anything from 8 to 32MB (Table 10.1 shows the size of this type of information over five years). This is assuming that a simple compression technique is used. The size of the memory should be extensible, either by using a top of the range PIB or by utilizing the wireless connectivity to access old information that may be required, which may be stored on mass storage in another device.
Table 10.1
Typical Example of Personal Information over Five Years
| Type of Stored Information | Size of Information over Five Years (KB) |
| Personal Information | 10 |
| Personal Photographs | 1,000 |
| Calendar information, including appointments and tasks | 1,000 |
| Notes | 1,000 |
| Blood tests results | 10 |
| Ultrasound scans | 4,000 |
| Total | 7,020 |
Security and access controls must be adequate. The PIB device is likely to carry confidential information, so the device and the system it connects to must provide adequate protection for that information. This implies that there must be different levels of access to the information in order to maintain confidentially, and whenever data is transferred, it must be protected from eavesdropping. Examples of different access levels could be:
Access to all information—general doctor and patient (provided the patient is not a minor)
The reason for multiple access levels is that not all information is required by all medical staff. For instance, the patient may not wish the chiropodist to know that he/she has visited a sexual disease clinic, as it is not pertinent to the chiropodist’s treatment. Bluetooth provides 128-bit security, which can protect data when it is being transferred to and from the PIB. Limiting access to different categories of stored information could be done through a security information based on the PIB which defines those items a particular device can view, as well as those that require authorization. However, security features should be used with caution since the more different the access level required, the more complex the device will be to use.
Implementing Optional Extra Features
There are many more features that would be nice to have but that are not essential to implement a PIB. It would be possible to have basic models available for all patients, and higher cost variants for specialist uses.
An ideal PIB device has many interfaces, some of which would not be necessary when creating a low-cost device. Figure 10.2 shows interfaces that might be used in a high-end system:
Visual devices like LCD and LEDs
Input devices like a keypad or possibly buttons
Alternative communication interfaces, namely: Bluetooth, IrDA, and PC Card
There are a few internal features to the PIB that are very important:
These extra interfaces can provide valuable functionality for high-end devices. This section examines the improved functionality that could be offered.
Not everyone will have a Data Access Terminal, so a low-resolution color LCD could be added to provide an instant means of accessing the information. Such an LCD could also be used to display a photo identifying the patient. It could be used for security purposes to show the patient’s photograph for confirmation of identity. There are other uses—for example, it can be used for quick language phrase translation, to communicate to non-native speaking patients. The PIB device can be used as a medicine reminder: it could describe the look and feel of the medicine, how many tablets should be taken and even show a picture of the medicine. However, a color LCD adds greatly to the cost of the device, so for the lowest cost, this may not be practical.
A keypad is useful to answer any questions or enter PIN codes to authorize access to the device, and to control more complex functions on the device. If the PIB does not have a keypad, it would have to use a pre-programmed fixed PIN code, which prevents the user from easily changing the code if they want to bar somebody who was previously granted access to data.
A speaker enables many multimedia options. A microphone could be used to provide Dictaphone capabilities, enabling doctors to record notes directly into the PIB, or allowing patients to record their own memos. This would require a complete audio input system, and could be quite expensive.
LEDs are useful to provide low battery indication. LEDs can also be used to indicate an active communications link; this could be a very useful indication, acting as a reminder that the device is on when entering areas that do not permit use of radio links.
The possibility of having sensors could make the PIB device more acceptable to nurses and other hospital staff. These sensors could be used to detect movement at low or high sensitivity, and would allow hospital staff to be alerted in case the patient has decided to go on a walkabout. It could also be used to establish if the patient is wearing the device, or if it has fallen off. Temperature sensors could be used to monitor the average temperature of the room, or the environment the patient is in. This could be employed to alert the hospital staff of anything abnormal. The PIB device could also have a pulse rate monitor. The monitoring capability will also ease the need to write down the measurements as they could automatically be transferred to the Data Access Terminal.
Alternative communications interfaces might be provided, to cater for circumstances where the wireless radio cannot be used—for instance, near highly sensitive equipment. However, alternative communications interfaces would raise the cost of the PIB. A backup infrared link could add wire-free communications capabilities in areas where radio cannot be used; here, the cost increment isn’t great since infrared systems are very cheap, but development costs for dual software systems could be high. It would even be possible to add a PCMCIA PC-card interface for high-speed data exchange, although this would greatly add to the cost and would also negate the advantages of hygiene and reliability, which a wire-free design has.
Specialist monitors or interfaces to monitoring equipment could be added. You could view this as adding monitors to the PIB, (although for more complex and expensive monitors it might be better to think in terms of adding PIB functions to the monitor). A PIB device enabled with monitoring capabilities such as temperature or pulse could continuously monitor and record any abnormal variations. Audible alarms could be triggered if the sensor exceeds either upper or lower programmed thresholds. However, caution should be employed when using a PIB for safety-critical purposes. Wireless links are subject to interference, which makes them unreliable.
Choosing a Wireless Technology for the PIB Device
There are various technologies that could be used to achieve the PIB system. See the brief summary in Table 10.2.
The reasons for choosing Bluetooth as the wireless connectivity for the PIB system are:
Its physical size is small, and there are many chip vendors to choose from.
The range is adequate—the lowest power version offers up to a 10 m range, which is sufficient.
The available choice of chip vendors leads to a competitive market, which means the cost will reach less than $5 over the next two to three years.
There is a worldwide acceptance of the ISM band used by Bluetooth, which means that the product design can be sold in markets all over the world.
Products are expected to interoperate if they have been qualified and received a Bluetooth logo. This means that the data terminal side of the Bluetooth link can be implemented with readily available, cost-effective, commercial products.
From Table 10.2, we can see that IrDA is also a good match for the requirements of a Personal Information Base. The advantage of Bluetooth wireless technology is that it is not directional—with infrared technology, the ports on two devices must be lined up, but a Bluetooth device can be accessed while still in the patient’s pocket, for example, greatly increasing convenience of use.
Considering the Cost of the PIB
Once the wireless technology is chosen, it is possible to set some cost targets. Our example PIB device is a specialized design to be used in a hospital environment, and as a result, it could be expensive to produce as a product. A target low-end price would be $20 to $40. At these cost levels it is not going to be practical to support all possible optional features, though different subsets of the possible options could be fitted to create various levels of device.
One way to reduce component cost is to produce a single processor system. This means that the processor must not only be able to handle the whole Bluetooth stack for this application, but also the application including the user interface. It also means that the processor must support additional peripheral interfaces, which will mean that hardly any external support devices will be required.
The rest of the infrastructure is robust: networked and Bluetooth-enabled PDAs or desktop computers and a server for local and central control. The cost of these items (including the software) can be targeted at:
Exploring the Safety and Security Concerns of a Personal Information Base
Access to accurate medical information can be a matter of life and death, so it is important components of a medical information system can’t introduce falsified or corrupt data into the system. It’s also important to ensure data cannot be lost from the system. In addition, patient confidentiality is an important consideration, and one that should be taken seriously in wireless systems, as communications can potentially be intercepted even by somebody outside the room where data is being exchanged. Finally, medical requirements regarding hygiene and regulations concerning radios in hospitals must be kept in mind when considering any device for hospital use.
Enabling Data Duplication
The aim of data duplication is that data for a patient is stored in two places at any given time. This means that after synchronization, the central database will ensure that any loss of patient information, be it PIB device or a doctor’s PDA, can be completely recovered. The reason why this is possible is that no data can be entered in the PIB device on it’s own, except for personal notes using the limited local interface. This means data is added to the PIB device by a Data Access Terminal or a desktop computer (local server) pushing new records to the PIB. The Data Access Terminal has a duplicate copy of the new patient data, and can be synchronized to the local and central server.
Wherever data is stored on small mobile devices there is always more risk of data loss than with desktop systems, so data loss is a general problem where mobile data storage is used. The Bluetooth synchronization profile provides a means to ensure data stored on a mobile device is backed up automatically. The synchronization profile could be used to ensure any data entered directly onto the PIB is backed up.
Synchronization software is sometimes very rigid in the way it behaves, as it expects one part of the system, normally the desktop computer or main server, to be the master of the data while the mobile device is a slave to the information. For example, different appointments made by the secretary for one patient at the same time on the server may overwrite a new appointment made on a mobile device. Another area to be careful about is in the use of Universal Time, as different devices may refer to different time zones.
Figure 10.3 shows how a synchronization system could work. The Data Access Terminal pushes data to the PIB, but keeps its own copy of the data. Both the PIB and the Data Access Terminal can synchronize with a local host, which is connected to a local area network. Once data has reached the network, it is backed up across the network. Should network failures occur, backup modem links can be used.
In addition to providing data security, the central control facility also allows patient mobility. If a patient is moved to another hospital, their records can be retrieved from the central backup facility, and a new PIB can easily be set up with all the patient’s information.
Ensuring Data Integrity
It is very important that data integrity be maintained on the patient record as decisions cannot be made on data that is in error. A well-known technique for doing this is adding an overall checksum to the end of the patient record.
The overall checksum for the data is a number derived from applying some algorithm to each data element (typically at byte level) of the patient’s record. This ensures that if any part of the data is corrupted then the data cannot be trusted and a new copy should be obtained.
Wireless links are prone to errors caused by interference, or by fading of the signal as mobile devices reach the limits of their radio ranges. The Bluetooth baseband implements error checks on data, but these checks will not catch every single error. Therefore, it is a good idea to implement extra error checking on data to be sure any errors that aren’t caught by the Bluetooth protocol stack are flagged at the application level.
Providing Security
A simple LCD on the PIB device could display a photograph for security confirmation that this device belongs to the correct person. Access to data that normally would be on bedside charts is available using the PIB device; only medical information of a current visit is readable, no other data is viewable, without using PIN code access. Detailed information is only accessible with the use of the Data Access Terminal; this allows the PIN code and other levels of access to be enforced, depending upon the patient or the seriousness of the medical condition. The different levels of security can be provided by Object Exchange or by using password-protected files.
Patient confidentiality is very important. One way of protecting confidentiality is to use a reference code to identify the patient in place of their name. Indeed, in the UK (according to the Data Protection Act) the patient’s National Health Service number is used as an indexing method for medical records in order to keep them confidential. Even then, a photograph and other information, such as date of birth, can be used to verify the correct patient. This means that the Data Access Terminal must be able to access a table cross-referencing index numbers to names, so the patient’s information can be obtained.
Whenever dealing with protected information, it is important to retain a sense of proportion. In paper-based systems, folders containing medical information can be picked up and read by anybody. The way this information is protected is by keeping it out of sight of patients and staff. While it is good to have extra security, it is all too easy to implement so much security in a system that it becomes virtually unusable. If data is too difficult to access, doctors and patients will undoubtedly resort to using paper notes, thus bypassing all the useful backup features offered by the PIB system. Therefore, user interfaces should be designed with care so that the entry of PINs does not become an onerous task that effectively bars authorized users from the system.
By deploying Bluetooth sensors near the exit of a hospital, any accidental removal of the PIB device can be detected and reported. This is only possible if the device is Bluetooth-functioning, however, so it would still be possible to deliberately remove a PIB by disabling its Bluetooth transmitter.
Meeting Medical Requirements
Mobile phones would be an ideal PIB device since they have all or most of the capabilities described in previous sections. Unfortunately, they cannot be used in hospitals. However, the use of 2.4GHz within US hospitals has been cleared. The main example used to demonstrate this was the use of wireless telemetry using 802.11 Wireless LAN. This range also covers Bluetooth operation, although it is not explicitly mentioned, in the ruling. Some medical equipment companies have used this to start producing Bluetooth-enabled products.
As noted earlier, hygiene is a very important requirement for hospitals. This means the PIB device should be made of material that can be easily cleaned and must not have crevices where bacteria can accumulate.
Using Bluetooth Protocols to Implement a PIB
So far, we have seen that Bluetooth wireless technology can fulfill the communication requirements of a PIB. In this section, we will look at some of the details of how the communications protocol stack could work. This section briefly explains the hierarchy of different protocols needed to exchange data, and how those protocols are derived from many different specifications. It also provides an overview of Bluetooth packet layering.
Developing & Deploying …Radio Regulations and the ISM Band
The following reference is from the US Federal Register amended in 2000 to harmonize the use of wireless technologies within hospitals.
Page 43999 of Federal Register / Vol. 65, No. 137 / Monday, July 17, 2000 / Rules and Regulations
15.247 Operation within the bands 902 to 928MHz, 2400 to 2483.5MHz, and 5725 to 5850MHz.
Comment: No change was made to §15.247. As noted in ¶35 of the Final Rule: “… we will continue to allow medical telemetry equipment to operate in the ISM bands under Part 15. While such operation will be permissible, manufacturers and users are cautioned that equipment operating in these bands has no protection from interference from ISM equipment operating under Part 18 of the rules or other low power transmitters operating under Part 15 of the rules.”
After this overview, we will go on to explain the details of how the PIM device exchanges information.
Understanding the Bluetooth Specification Hierarchy
The Bluetooth SIG has done a very good job of reusing existing standards and adapting them. This specification reuse means it is possible for protocol stack and applications developers to reuse code. This saves time and improves the robustness and quality of the final system as reused layers have already been tested on other communications systems.
However, there is a drawback to reusing specifications. Reuse means that anyone trying to understand the whole system has many different documents to read: this can become a challenge to understand! To help you find a path through the maze of specifications, this section will summarize all the standards used by the PIB device. Later sections will explain how the standards interact, allowing us to exchange data.
The main aim is to convert the layered (horizontal) approach into a vertical slice so the interaction between the various layers can be easily understood.
The following specifications are used in the PIB device:
Bluetooth Special Interest Group (SIG)
Infrared Data Association (IrDA)
European Telecommunications (ETSI)
Internet Mail Consortium (IMC)
Figure 10.4 shows an overview of the number of packet layers involved in sending an Object Get Response Packet. Please note that this is a summary—in later sections, we will go into packet details and explain every field with reference to the relevant specification.
When writing applications to run across Bluetooth, you are likely to be using a high-level interface at the top of the Bluetooth protocol stack. However, it is often useful to understand what is happening in the rest of the system. The full data exchanges involved in a PIB system are extremely complex, but it is possible to get a good understanding of how the different stack layers interact using the simplest information exchange: a virtual business card or vCard (see Figure 10.5).
Suppose a Data Access Terminal is gathering information on devices in the area, and it wants to get a vCard object from every device that supports vCards. It must go through a three-step process:
1. The Data Access Terminal inquires to find Bluetooth devices in the area. Each device, which is listening for inquiries, will respond with an FHS packet giving information needed to establish a data connection.
2. For each device found, the Data Access Terminal connects and creates a Service Discovery L2CAP channel and performs Service Discovery on that channel. The Service Discovery Protocol tells the Data Access Terminal whether the device supports vCard transfer, and what parameters are needed to transfer cards (for example, the RFCOMM channel number to be used for this service).
3. The Data Access Terminal shuts down the L2CAP channel and establishes a separate L2CAP channel to RFCOMM. An RFCOMM channel to the OBEX layer is then established. Afterward, an OBEX session is started, enabling the Data Access Terminal to act as a client and pull a vCard from the PIB Device, which acts as a server.
The upper part of Figure 10.5 shows the details of the OBEX session. The Data Access Terminal sends an OBEX Connect across this RFCOMM channel, then the PIB device responds with an OBEX OK, which means that objects can be exchanged. The Data Access Terminal requests an OBEX Get of the local vCard and the PIB device responds with a Get Response, which includes the vCard. The Get Response is shown in Figure 10.5 as it traverses the different layers from vCard to OBEX Response, RFCOMM, L2CAP, Optional HCI ACL Data, and finally, on-air data packets.
Initializing the PIB
In the following section, we will spend more time explaining how Bluetooth operates than how the overall PIB system works. Before we explaining how the Bluetooth PIB device is initialized, enabled, and verified for operation, let’s take a look at how the user interacts with it.
Understanding User Interactions
Imagine the following situation. A patient called Mary Clarkson has a check-up scheduled at the hospital. She arrives at the hospital and goes to the receptionist to register herself. The receptionist accesses Mary’s patient records and makes sure that Mary has an appointment. Mary doesn’t have a PIB device of her own, so the receptionist programs one with Mary’s details and gives it to her. If Mary has an out-of-date picture on her records, the receptionist may even take a new photograph and update Mary’s records. The following sequence of events check if the PIB device is operating correctly:
1. Mary checks in for her appointment.
2. The receptionist asks Mary for personal details to program into a new PIB.
3. Mary hands over her appointment letter.
4. The receptionist enters the details into her local Data Access Terminal.
5. The Data Access Terminal sends the records to a central server.
6. The central server accesses appointment records and medical history and returns the information to the receptionist.
7. The records do not include a current photo of Mary, so the receptionist takes a photo of her; this could be transferred across a Bluetooth link to the Data Access Terminal.
8. The receptionist programs up a PIB for Mary.
9. Mary is given the PIB. Since it is the first time the record has been accessed over Bluetooth, Mary is asked to enter a password and verify it. The receptionist informs Mary that she has to remember this password since she may be asked to enter it during her stay.
10. Mary can now go off to the wards carrying her records with her in the PIB.
The steps to access both public and private data look very easy, but there is a considerable amount of initialization and protocol that has to be done in order to achieve this level of transfer.
Without going into too much detail, entering the same password for both sides of the link (in this case, the receptionist and patient) translates to the Bluetooth Personal Identification Number. These have to be the same on both devices, otherwise a link will not be established.
If the PIB has a keypad on it, then the password can be entered simply by using the password. If the PIB does not contain a keypad, then it would come with a default password built in. The matching password would be entered on the Data Access Terminal to establish a secure link; an application running across the secure link could then be used to change the password in the PIB.
Obviously, there is a potential problem in regards to patients forgetting their password. Since the information on the PIB is duplicated elsewhere, one solution would be to have a method of resetting the PIB to remove all information, then it could be reinitialized with information from the central server.
Sending and Receiving Information
The previous section referred to receiving data from the PIB device in order to test if the device was functional and if the information was programmed correctly. This section uncovers exactly what goes on when data is exchanged between the PIB device and the communicating device.
Imagine the following situation, where the PIB device replaces the chart at the end of the bed. A doctor (Dr. Merick), who is doing a daily check to diagnose the next course of action for his patients, visits Mary. Each step is illustrated in Figure 10.6.
1. Dr. Merick asks Mary to activate the PIB device by pressing the red button.
2. Mary presses the red button.
3. The doctor uses his PDA, finds Mary’s PIB device, and selects it. On selection, he and Mary may have to enter the password (for simplicity, the password entry has not been shown).
4. The doctor synchronizes with Mary’s PIB. This is a two-way synchronization that exchanges any new data between the two devices.
5. The doctor reads any new information, and after a conversation with Mary, adds new notes.
6. The doctor enables the medical equipment to take a measurement of Mary’s condition.
7. The doctor uses his PDA and finds the equipment he wants to use. A unique password is entered to use the equipment. This will allow only authorized staff to use the equipment.
8. The doctor gets the control interface on his PDA and remotely controls the device to take the measurements.
9. Blood pressure, temperature measurements, and the doctor’s comments and recommendations are recorded on the PIB device.
10. Before the doctor leaves, he synchronizes with Mary’s PIB, duplicating the data in the overall system.
11. Later on in the day when the doctor goes to his office, the PDA is synchronized with the local server so that data can be backed up and future appointments can be scheduled.
Now that we understand how Mary and her doctor use the PIB, let’s consider what happens at the Bluetooth protocol level.
When Mary presses the button and the Doctor retrieves first Mary’s public information, then her medical records, both the doctor and patient begin by exchanging public information. The doctor uses the information to verify that the correct patient is being treated and the PIB can keep a record of who accessed the information. The public information is transferred using the Object Push Profile (BT Profile Spec Part K:11, page 339) and is known as Business Card Exchange (Section 4.4, page 346) using vCards (IMC vCard – The Electronic Business Card Exchange Format, Version 2.1, Sept. 1996).
The role taken by the Doctors PDA is the “Push Client” that wants to initiate the exchange, while the role taken by the patient’s PIB device is the “Push Server.”
The patient wants this exchange to be as simple as possible, so the patient’s PIB will automatically accept the Doctor’s information and exchange the public patient information. This means Mary does not have to interact with her PIB beyond enabling it.
Figure 10.7 shows people, devices, and actions involved in the Business Card Exchange.
The doctor is the user of the PDA and asks the patient to press the red button to enable the PIB device.
The patient is the owner of the PIB device and allows the doctor to exchange information without any interaction.
Both the PDA and PIB devices are Bluetooth qualified products and cooperate to allow the exchange of information to happen wirelessly and seamlessly. The high-level steps can be summarized as follows:
1. The doctor asks the patient to press the red button on the PIB device.
2. By pressing the red button, the PIB device is enabled.
3. The PIB device goes through Bluetooth and application initialization.
4. The doctor selects “Get patients?” on his PDA.
6. The PDA does a search for discoverable PIB devices.
7. Discovered PIB devices are displayed in the PDA “Get patients?” window.
8. The doctor uses the remote Bluetooth name to decide which patient is being treated, as this has been programmed with <date_of_entry>, <patient_name>, and <patient_hospital_identification>.
9. The patient is selected and the public information is exchanged. This is the vCard.
10. If the public information is correct, the treatment continues. Otherwise, another patient is chosen.
Initialization – PIB Device
When the patient presses the red button, the PIB device initializes the Bluetooth hardware and software. This only happens if there is no active connection present.
We will explain the initialization by using the Host Controller Interface specification (Bluetooth Core Spec Part H:1, page 535), despite the fact that this interface may be collapsed in the final solution.
The most important commands are described in Table 10.3 with reasons for why they are used.
Initialization – Doctor’s PDA
Initializing the doctor’s PDA employs the same steps for initializing the PIB device, except for the following items:
Using the Generic Access Profile
The purpose of the Generic Access Profile is to select a suitable connecting device based upon the Inquiry procedure and to get the remote name. The business card exchange doesn’t require any security, so this will not occur until critical information has to be exchanged.
For the purposes of the Generic Access Profile (Bluetooth Profile Specification Part K:1, page 23, section 2.2) the doctor’s PDA is known as the A-party (the paging or initiator device) and the patient’s PIB device is known as the B-Party (the paged or acceptor device).
When the doctor asks the patient to press the red button, the initialization of the PIB places the device into the following mode:
Limited Discoverable mode for a period of three minutes. This makes sure the device can only be discoverable during that period.
Connectable mode. The PIB is always in connectable mode when it is powered. This allows other devices that know about the PIB device to connect without going through an inquiry phase.
Afterward, the doctor’s PDA is initialized, which places the device into the following mode:
Device Discovery
Once both devices are initialized, the doctor’s PDA can initiate a one-time inquiry (Bluetooth Core Specification, Appendix IX, page 1041, section 2.2). The inquiry would be initiated by the doctor interacting with a user interface: for instance, by clicking a Select Patients icon on the PDA. See Figure 10.8 for an illustration of the device discovery procedure.
The PDA sends an HCI_Inquiry command to its Bluetooth Host Controller; the Host Controller responds with an HCI_Command_Status_Event, which acknowledges it has received the command. Then the Host Controller sends out a series of Inquiry packets (ID packets containing the General Inquiry Access Code).
Every device within range (which is in discoverable mode) should hear these packets and respond with an FHS (Frequency Hopping Synchronization) packet. These packets contain all the information the PDA needs to connect with the responding PIBs.
The Host Controller sends the inquiry response information up to the PDA in one or more inquiry result events.
There are many possible architectures which can be used to implement a robust PIB system. We have already noted that for the PIB itself, a single processor architecture could provide the cheapest option, but for the rest of the system, it is likely that applications will run on a separate host processor. Let’s consider the two processor architectures as defined in Bluetooth Specification Version 1.1 (Part H:1 Introduction, page 584). The communication occurs using HCI (Host Controller Interface) packets. The host is the processor controlling the Bluetooth Host Controller.
Figure 10.9 shows command and dataflows between a host and Host Controller. The dotted line connecting commands with command complete events shows how the command completes correspond with commands. For every command packet sent, there is a command complete event packet. The command complete events may not come back in the same order that the commands were sent. Some commands, such as the inquiry command, may take many seconds to implement, so it is likely that sometimes the host will want to send more commands while waiting for a command complete event. This means the host must be able to send commands and handle the command complete events synchronously.
If a Bluetooth link is established and data is being exchanged, then data from the host can cause flow control events to come back from the Host Controller indicating how empty the data buffers are. This needs to be processed at a higher priority to avoid the Host Controller’s buffers overflowing with a consequent loss of data.
Because events are sent to the host at the same time as the host is sending data and commands to the Host Controller, an asynchronous communications architecture is needed.
The reason why HCI transport also has to be robust is that HCI packets carry a length field, used to calculate where the end of the packet is. If at any moment in time the counting of bytes is lost due to loss of a byte(s), then the synchronization has to be reestablished, at the expense of losing a complete HCI packet.
Version 1.1 of the Bluetooth specification was published with three HCI transports defined: UART, RS232, and USB. RS232 has not been widely implemented, with most Bluetooth adopters seeming to view it as over-complicated. UART was defined for communication between chips on a PCB and does not perform well over links which are subject to errors (as the cabled serial port links to many PCs are). USB is tolerant of errors, but many Bluetooth host controller devices do not implement USB as it is quite a complex protocol. There is currently an HCI working group that is defining a new HCI transport, which, amongst other improvements, provides error detection and correction across serial links.
The HCI_Inquiry_Result_Event illustrates one aspect of Bluetooth which is likely to provide a challenge for applications developers. Some Host Controller devices will gather all inquiry responses together in the Host Controller, and just send one HCI_Inquiry_Result_Event to the host. Other Host Controller devices will send the host an HCI_Inquiry_Result_Event for every inquiry response received. While still other Host Controllers may even send duplicate events if they receive multiple responses from the same device.
If you are able to specify a complete system including hardware and software, you could write an application which was tailored to the behavior of one Host Controller. However, this makes for a system which can be limiting and difficult to upgrade. In the PIB system, one of the requirements is the ability to use a variety of legacy equipment, so there is a requirement to support whatever Host Controller devices fit onto existing equipment.
Whenever writing Bluetooth applications you should be aware that the Bluetooth specifications often include optional parts, and thus behavior is likely to vary subtly between different manufacturer’s Bluetooth components. If you want your applications to be robust and useful across a wide range of platforms, you must cater for optional parts of the specification.
Selecting a Device
Once the host has received information that the inquiry is complete, the host can examine the responses and use this information to select a device for a connection. The host gets the Bluetooth device address of each device responding, along with what type of device it is. The response also contains information on how each device scans for paging, which the protocol stack can use during paging to establish a connection.
The central database could provide the doctor’s PDA with a lookup facility allowing Bluetooth device addresses to be cross-referenced with patient’s names. This only works if the doctor is currently connected to the database, however. If this is the case, then it would be possible to download all the information anyway. The very fact that the doctor is connecting with the PIB to get records means his PDA is not currently networked!
Since there is currently no network connection, the doctor can connect to each PIB in turn, and retrieve their friendly names. These are human-readable names. At it’s most basic, the name could be:
The Bluetooth specification allows user-friendly names to be up to 248 bytes long, so the name could be used to convey a limited amount of information, such as a hospital index number, date of admission, date of birth, or a reason for admission. Therefore, the name could be:
Mary Smith POMI564 5 November 2001, 9 October 1943, Hip replacement
This is certainly very convenient, but care should be taken when employing the user-friendly name in this fashion since the information can be seen by anyone. It is possible that Mary Smith doesn’t want the whole world to know her date of birth, or that she is in need of a new hip. Index numbers are often used to protect patient’s privacy, so having a device publish name and index numbers immediately provides a way around existing privacy mechanisms.
The issue arises here because the friendly name can be exchanged before authentication and encryption procedures have been performed. When writing Bluetooth applications, you should think about how much information is available unencrypted, and take care to make sure that information sent before encryption is switched on does not compromise a system’s privacy or security requirements.
Using the Service Discovery Application Profile
Once Dr. Merick has found Mary’s device, the next stage is to use the Service Discovery Protocol. First, a data connection must be established, this could be the same ACL link used to get the friendly name from Mary’s PIB.
An L2CAP link is set up on top of the ACL link. The L2CAP link allows multiple services to use the ACL link (in this case, it is set up to the Service Discovery Server). Mary’s PIB contains a Service Discovery Server which can tell Dr. Merick’s PDA how to connect with other services running on her PIB.
Dr. Merick’s PDA gets information about OBEX services running on Mary’s PIB, including the RFCOM DLCI address which is needed to connect with the services.
The Service Discovery Application Profile provides guidance on how a service discovery session should be set up, how the service discovery protocol should be used, and what parameter values should be used.
Using the Serial Port Profile
Once Dr. Merick’s PDA has all the service discovery information it needs, the L2CAP connection can be torn down, and another L2CAP connection set up to RFCOMM. RFCOMM provides a serial port emulation service which is used by many profiles for communicating with higher layer applications and services.
Using the Generic Object Exchange Profile
The next stage is for Dr. Merick’s PDA to establish an OBEX connection. The messages used are essentially the same as would be used with OBEX across an infrared link. The Generic Object Exchange Profile gives guidance on how to use OBEX across Bluetooth connections.
Using the Object Push Profile
Dr. Merick begins by just getting public information about Mary in the form of a virtual business card or vCard. To do this, his PDA and her PIB use the Object Push Profile. This profile defines how objects with predefined formats are exchanged between Bluetooth devices. Using the Object Push Profile, it is possible to:
This profile uses the facilities of the Generic Object Exchange Profile to exchange data.
Using the File Transfer Profile
Once Dr. Merick has retrieved Mary’s card he will want to go on to retrieve medical records with more complex formats. Medical records are not covered by the Object Push Profile, so to retrieve them Dr Merick’s PDA will need to retrieve the data as files using the File Transfer Profile.
Like the Object Push Profile, the File Transfer Profile uses the facilities of the Generic Object Exchange Profile to exchange data. Using the File Transfer Profile it is possible to retrieve files from a remote device. It is also possible to create, delete, and move files on a remote device.
Obviously, you would not want just anybody to be able to come in and alter your medical records. With this in mind, it’s possible to set up security access so different users get different levels of access to the file system on a device. A vital part of the design of a PIB system would be making sure that file access was limited, so unauthorized access to files was not permitted. This is necessary to ensure medical records could not be tampered with across the Bluetooth link, either accidentally or maliciously.
The Object Exchange Profile provides OBEX authentication, which can take place independently of Bluetooth authentication. While Bluetooth authentication is extremely secure, it might be desirable to use OBEX facilities to maintain compatibility with existing infrared-based systems.
Figure 10.10 shows how each of the Bluetooth protocols is used in turn to set up layer after layer of connection, culminating in information exchange through OBEX.
In this section, we will look in more detail at the exchange of OBEX data which actually gets the medical records from Mary’s PIB to Dr. Merick’s PDA. To begin with, it is necessary to explain a couple of terms which are fundamental to OBEX operation: client and server (see Figure 10.11).
A server is any device that offers a service. That service could be providing data, or storing data. A client, on the other hand, is any entity that wants to take something from a server, or give something to a server. A client usually initiates the connection, and can either push data, (put data onto the server) or pull data (get data from the server).
A device can be both a client and server at the same time. ACL and L2CAP connections made by the client can be reused by the client on the other side. However, the client on the other side needs to create a new RFCOMM channel. Each RFCOMM channel is identified by a DLCI (Data Link Connection Identifier). The DLCI value space is divided between the two communicating devices using an RFCOMM server channel and a direction bit.
Figure 10.12 shows how the RFCOMM address byte can be used to distinguish between server and client direction. The figure summarizes the Part F:1 5.4 DLCI Allocation with RFCOMM Server Channels section in the Bluetooth Core Specification and 5.2.1.2 Address Field section in TS 7.10.
Server applications on initiating devices are reachable on odd DLCIs, and server applications on noninitiating devices are reachable on even DLCIs.
Depending on whom the initiator or responder device is, the Command/Response bit indicates if the data is a command or a response to a command.
Note that the byte has been shown as it would appear in a packet. This means it is bit-reversed from all the definitions in the specifications. This is clarified by using the appropriate bit numbering.
By using OBEX put and get messages, it is possible for Dr. Merick’s PDA and Mary’s PIB to exchange data in any format whatsoever. Only the application that is interpreting the data limits the formats.
However, because of the constraints of size and price it is likely that some types of data would not be stored on PIBs. For instance, as noted earlier, medical images such as X-rays usually require very high resolution, which leads to extremely large files. It is unlikely to be economical to store such files on a PIB. Furthermore, the monitors required to display medical imaging data at a useful resolution currently cost around $20,000 each, so even if Dr. Merick could retrieve an X-ray from Mary’s PIB, his PDA would not have the resolution to display it.
Practical issues of what data can be usefully absorbed via the limited user interfaces typically provided by mobile devices should always be considered when designing Bluetooth systems. There is little point to designing a communication system which can push a high quality image to a device if there is no way for that device to display it, or if the image uses up all the device’s storage, preventing it from being used for other purposes.
Considering the User’s View
A crucial part of any application is the user’s view. So, we have to ask ourselves how a PIB will compare with the existing system as far as its users are concerned.
Identifying the System’s Users
The immediate users of the system are obvious: the patient and medical staff who directly access the information. However, the system will also have an impact on the staff members who maintain records. Just as the paper-shuffling activities of a hospital are replaced by the automated distribution of information, the staff who maintain the hospital’s information systems will also be affected by the PIB system.
In designing applications, you should be aware of all users who will be affected by the system. For large applications, this extends to those who will configure and maintain the system in addition to the direct users.
Identifying System Use Cases
In this case study, we have gone into detail of the most obvious use case for a medical Personal Information Base: carrying records around and communicating them to medical staff. However, there are many more future possibilities for the PIB device.
A PIB device could audibly announce which medicine has to be taken at preprogrammed times, and act as a medicine reminder. Medical compliance, ensuring that patients comply with their program of treatment, is a major obstacle to many treatment programs. In most cases where there is a failure to comply, the patient simply forgot to take their medicine. A portable device, which helped to ensure compliance, offers tangible medical benefits.
With the use of Bluetooth ads, patients passing by a Bluetooth-enabled billboard might download information on events happening in the hospital or any other services that are being offered such as taxis, counseling, and so on. This presupposes that the patient has some way of later viewing the information.
Identifying Barriers to Adoption
With new technology, there are often barriers that prevent adoption of systems. These barriers can mean the difference between the success or failure of an application in the market place. In the case of a medical system, cost, safety, user confidence and usability are all potential barriers to adoption. Issues of cost and safety were considered in our earlier discussions, but in this section, we’ll look at user confidence and usability.
For user confidence, one of the biggest challenges for the PIB system is synchronizing the data so that losing the PIB device does not involve a loss of data. It is important for the PIB system to make sure that an authorized person is connected to the correct device, so that the correct information is exchanged with the correct patient, and without any worry of malicious eavesdropping.
Prevention of data loss is very important for user confidence. Data on paper can be seen and felt. Data in electronic format is intangible, and although back-ups may make it safer than paper, there are still issues of confidence which lead many users to feel more secure with paper storage. The system keeps data in two places at any one time so that a single failure in the system will not result in any loss of data; however, it is difficult to protect against double failures in the system. Data will only be synchronized at the central base and then distributed to update any remote changes. For the patient, the role of the PIB in data loss could easily be intimidating. What if you are carrying a device with all your medical information on it and you lose it? What if it should fall into the hands of somebody who would use the information maliciously? To reassure users, security and backup features should be easy to use and unobtrusive, but they also need to be explained well enough to reassure.
For busy medical staff, a system that is both complex to learn and use will not prove welcome. Therefore, to ensure a good user experience, existing interfaces and applications should be reused wherever possible. A new underlying communication system does not necessarily mean that completely new applications must be developed. The Bluetooth protocol stack has been designed to enable a Bluetooth system to fit in with legacy applications, and this should be done wherever possible. Not only does this make it easier for users, it may also make it easier for applications programmers!
For patients, usability translates to doing as little as possible. The device is set up by staff, and most interactions with the PIB are controlled by staff. A patient in a medical environment is already likely to be under stress: it is not the ideal time to start learning a complex user interface! We have shown how the interaction required from the patient can be kept to a minimum.
In designing any Bluetooth application, usability is a potential barrier to adoption that should be considered. Ideally, your application will work straight out of the box, with controls that are obvious to the uninitiated. It can be argued that if the user has to read a manual before using basic features, then your application has failed the usability test!
If you are replacing a legacy system (in this case paper records), you should consider what sort of system your application is replacing, and consider whether your application is as convenient and easy to use as what it replaces. If you are designing a completely new product, your system arguably has greater barriers to overcome, as the user must be convinced they want or need your product. If it is difficult to use, they may never find out how useful your product could have been!
Managing Personal Information Base Performance
The PIB device has many interfaces for communication and for interacting with it, but at the same time it must be extremely power-efficient. This means that the interfaces must only be active when they need to be. Ideally, a PIB device should be able to last for one week (with four hours use a day) before the battery needs to be replaced.
Battery life is very important if uninterrupted access to patient records is required. Each device could be cycled daily, meaning that the only requirement is that it has to run on batteries for a day. This is not a very stringent requirement for a battery-operated device. In comparison, the Bluetooth Human Interface Device profile suggests that a Bluetooth mouse should run for three months!
Bluetooth provides various low-power modes. These modes are most useful when devices wish to remain connected for long periods, but do not have much data to transfer. The PIB system usually establishes connections for short periods of time, exchanges data, then drops the connection. For this sort of usage model, low-power modes are irrelevant. However, if a PIB were used to collect data from a monitor, then it would be expected to remain connected for long periods of time. In this sort of usage scenario, using park or sniff mode would make sense. The PIB could then wake periodically, collect a data update from the monitor, and return to a low power sleep mode for the majority of the time. When collecting data in this fashion, it should be kept in mind that the PIB can have slightly stale data as there are gaps when its radio link is asleep, so data is not being updated.
The PIB must also maintain information from the central system—for example, collecting appointments, or details of test results which have been processed. The PIB could be set to wake every 30 minutes to connect with the nearest networked server and collect any information. This ensures that data is automatically transferred throughout the system.
The user could also request an update, perhaps by pressing a button on the PIB. In this case, it can take up to ten seconds to inquire and find the nearest networked server, and up to another ten seconds to connect with it, going through link and channel setup (this is a worst-case scenario; normally, a link can be established in two to three seconds). This may not sound like a long time, but it can seem like an extremely long delay, so it’s likely that to convey appointment information quickly it will still end up getting scribbled down on paper and handed to the patient. The strength of the PIB system is not in its speed but in its automated backup facilities, and in the automated distribution and storage of information.
Summary
This case study has looked at a device that does not exist today, but that can be created with current technology. Already we are seeing PDAs being used to manage personal appointments as well as information on the move. It is a logical step for large institutions, such as hospitals, to begin to use similar technology to manage their information systems.
Bluetooth wireless technology suits the requirements of a Personal Information Base (PIB) for many reasons:
The chips/chip sets and associated components are low cost.
Bluetooth modules typically have a small form factor making them suitable for incorporation in handheld/mobile devices.
Bluetooth wireless technology is low power, making it suitable for devices which need to run on batteries.
The technology is available in a wide range of devices (PDAs, phones, laptops) providing a variety of candidates for Data Access Terminals.
The ISM band used for Bluetooth radio links is available license-free worldwide.
While the PIB system is not safety-critical in itself, it does handle data that may be critical to medical treatment. The integrity and security of that data is paramount. Bluetooth links may introduce errors, but the application can easily compensate by backing up data, and by implementing application level error checks on records. Security of the radio link is also important. This is provided by authenticating communicating devices, and encrypting medical records on air. Finally, password access can protect the PIBs contents should the device itself fall into the wrong hands.
The Bluetooth specifications provide a variety of profiles that lay out rules for using the Bluetooth protocol stack for particular end-user applications. For a Personal Information Base, the Object Push Profile can be used to exchange virtual business cards (vCards), which publicly identify a PIB’s owner. The File Transfer Profile can be used to exchange medical records.
The Object Push and File Transfer Profiles both rest on the Generic Object Exchange Profile, which uses the Infrared Data Association’s OBEX protocol to exchange data objects. This, in turn, relies on the Serial Port Profile, which uses a modified version of the ETSI TS07.10 specification to emulate serial ports over a radio link (TS07.10 is also used by GSM cellular systems to emulate serial ports). Finally, the Generic Access Profile provides generic procedures related to discovering Bluetooth devices, security levels, and parameters accessible at the user interface.
By using Bluetooth profiles, the PIB application can use standard protocol stacks and features; this enables applications to be easily integrated with existing Bluetooth protocol stacks.
We have looked at a Personal Information Base in a medical context, but many of the elements of this case study are equally applicable to other data exchange applications. As input/output devices come down in price, we are likely to see devices such as the Personal Information Base described in this chapter appearing in more and more contexts.
Solutions Fast Track
Why Choose Bluetooth Technology
The chip’s physical size is small, and there are many chip vendors to choose from.
The range is adequate—the lowest power version offers up to a 10 meter range, which is sufficient.
The available choice of chip vendors leads to a competitive market.
There is worldwide acceptance of the ISM band used by Bluetooth.
A Bluetooth-enabled Personal Information Base (PIB) system in our hospital case study would store all patient information and information about visits, prescriptions, x-rays, and test information. It would be encrypted for both doctors and patients, have a user-friendly interface with low resolution screen; and would have a wireless connection to a main computer or Data Access Terminal.
Data loss is avoided using automated backups. Automated backups are enabled by wireless communications.
Encryption and passwords may be used to prevent unauthorized access to data.
Use of radio devices may be restricted in some areas, so it should be possible to easily disable the Bluetooth transmitter.
Using Bluetooth Protocols to Implement a PIB
For a Personal Information Base, the Object Push Profile can be used to exchange virtual business cards (vCards), which publicly identify a PIB’s owner. The File Transfer Profile can be used to exchange medical records.
The Object Push and File Transfer Profiles both rest on the Generic Object Exchange Profile, which uses the Infrared Data Association’s OBEX protocol to exchange data objects. This, in turn, relies on the Serial Port Profile.
By using Bluetooth profiles, the PIB application can employ standard protocol stacks and features. This enables applications to be easily integrated with existing Bluetooth protocol stacks.
Considering the User’s View
In designing any Bluetooth application, usability is a potential barrier to adoption that should be considered. Ideally your application will work straight out of the box, with controls that are obvious to the uninitiated.
Do not redesign existing system interfaces if it is not necessary. Using legacy applications wherever possible can help to ease adoption of new technology.
The PIB device has many interfaces for communication and for interacting with it, but at the same time it must be extremely power-efficient. This means that the interfaces must only be active when they need to be. Ideally, a PIB device should be able to last one week before the battery needs to be replaced.
Frequently Asked Questions
The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form.
Q: How do I know what profiles are appropriate for my application?
A: Each profile provides a profile overview which includes user scenarios. You need to read through the scenarios which the existing profiles offer and pick one which best matches your requirements.
Q: What do I do if there isn’t a suitable profile?
A: The Bluetooth SIG will consider applications for new profiles. Contact the SIG via the Bluetooth Web site at www.Bluetooth.com for nonmembers, or www.Bluetooth.org for members.
Q: The PIB used a lot of profiles. Do I have to use profiles if I don’t want to?
A: Yes. To get Bluetooth qualification, you must implement profiles which are relevant to the main function of your device. So, if you intend to emulate a serial port, you must use the serial port profile. Of course, there is nothing to stop you from adding extra functionality on top of what the profiles already provide.
Q: What extra considerations are there for medical devices?
A: In the case of the PIB: medical confidentiality and potential life-endangerment (if the medical data is corrupt). There may also be restrictions on using the ISM band in some hospitals, and in some areas of hospitals.
Q: Are there compatibility problems if you have different options on high-end and low-end devices?
A: No, as long as all devices implement a common basic set of functions.
Q: The PIB used Bluetooth PINs and Bluetooth security—how do I know if this will be enough for my application?
A: Bluetooth implements 128-bit security, which is the best currently available on wireless systems. Only you can decide if this is enough for your application. If you feel it isn’t, then you are free to add extra security at the application level. For instance, many packages are available for encrypting data on Internet links. These could be reused to provide application level security on Bluetooth links.