The target users of the proposed system may feature a number of possible health-related problems: co-morbidity in geriatric population poses strong limitations in the patients’ lifestyle, and may greatly reduce their physical or mental independence. This motivates the need of a technological platform designed for remote health monitoring, under strict usability and accessibility criteria. An ideal remote assistance system should enable users, even older ones, the ability to easily self-monitor various health parameters, and provide important information to medical operators, thus facilitating timely healthcare decisions. The primary goal of the system herein proposed consists in collecting the patient’s data through a properly interfaced network of biological sensors, as the one depicted in Figure 1: different sensors, like oximeter, breathing tester, glycaemia meter and a wearable bracelet, equipped with a blood pressure/temperature monitor and an accelerometer for movement analysis, transfer their data through a network hub, over a wireless link, to the STB.
System architecture and data flows
The STB is able to connect to the network of sensors thanks to a USB-to-WiFi adapter that may be plugged into one of the available USB ports. In fact, commercial STBs are currently available, that support USB-to-WiFi adapters and their related drivers. Once collected by the STB, the measured data are compared with user-specific threshold values, in order to eventually activate a notification event to the health assistance centre. Such a notification is transmitted by the STB on its return channel connection. As the amount of data to transfer is limited, this service may be provided even by old STBs, equipped with a PSTN modem. It is worth to notice that the proposed system is designed according to a layered approach, i.e. it may provide different service levels, as a function of the availability (or not) and the nature of the return channel connection. In fact, according to Figure 2:
a lower-level service is provided when the return channel is not supported. The DVB-T system conveys to the user general medical information, thanks to the broadcast nature of the communication technology chosen. In addition, user-specific information may be delivered, whose confidentiality is ensured by the adoption of smart card-based access, by exploiting the data transfer capability of DVB-T, as it will be explained in the following;
an intermediate-level service may be offered when a slow return channel connection is available (through a PSTN or GPRS link), that enables the possibility of exchanging data between the assisted user and the health operator;
a high-level service is finally provided when a broadband return channel connection is supported, through which a direct Audio/Video link between the patient and the health center facilities may be established, if requested.
In any case, however, the system is not designed to be used in emergency conditions, but only for long term monitoring of patients at home.
The lower-level service is actually the most critical to provide, since sending a direct feedback from the health assistance center to the patient, about the collected health parameters, is not possible. For such a reason, for each patient lacking a return channel connection, a user-specific list of threshold values for the monitored parameters (compiled by the assistance operators) is transferred to the STB over the DVB-T channel. The user’s STB, thanks to a proper MHP application, is able to interpret the received list and to compare the threshold values to the values collected by the sensors. In the case one or more parameters overcome the corresponding thresholds, the MHP application arises an alert for the user, and suggests him to contact the health assistance centre. The high level service may be supported through a classical ADSL return channel connection, for DVB-T STBs equipped with Ethernet interface, with a user bit rate capacity that may span up to 20 Mbit/s. If the cable ADSL connection is not available at the user’s premise, it may be possible to exploit a mobile broadband data connection over UMTS/HSDPA. In such a case, the user needs a mobile device acting as a router, that may interface the STB on a WiFi link, and exchange data over the UMTS/HSDPA network. In the latter scenario, the user’s STB should be chosen to support a USB-to-WiFi adapter, in order to wirelessly connect to the UMTS router device. The expected data transport capacity provided by UMTS in a static condition is enough to support the functionalities foreseen in the high level service profile. As a matter of fact, UMTS/HSDPA data connections are specifically designed to support, among the others, real time A/V connections. However, it is clear that setting up such a scenario requests the availability of a quite advanced STB, enabling USB-to-WiFi interfacing. As an alternative, a wireless return channel could be adopted, like the one provided by DVB-RCT (Return Channel Terrestrial), that offers a wireless interaction channel in the UHF/VHF bands. In the latter case, the user bit rate capacity may rise up to several Mbit/s when the wireless cell radius is reduced (e.g. from 65 Km to 3.5 Km). Both the solutions may ensure enough capacity to properly deliver A/V and data contents, in a bidirectional way, between the user and the remote health center. Similarly, also DVB-RCS (Return Channel Satellite) may support this kind of advanced service, where available (especially in rural areas) [17]. The interactive application designed for the remote health service does not depend on the specific return channel technology available, but on the available capacity to transfer different types of data.
Figure 2 shows the main blocks composing the system. At one end, the user’s premise, where the patient needing assistance lives, with the Biological Sensors Network connected over Infra Red (IR) or radio links. At the other end, the healthcare center, where the health operators, through suitable software applications, can perform a number of actions to provide differentiated levels of health assistance. The overall system is further composed by the broadcasting chain, necessary for DVB-T transmission, an Information Server (IS), and a Centralized Authentication Server (CAS) to manage the authenticated connection of each user, necessary to ensure a confidential transfer of their personal records. At the broadcaster’s premise, a proper DVB Content Manager (CM) server and a Digital Storage Media Command and Control (DSM-CC) Object Carousel (OC) server act as a repository and as a delivery engine, respectively, for the interactive and MHP-compliant applications necessary to provide additional data and services to the home user, over the DTT channel. Additionally, a Service Manager (SM) is inserted into the system architecture, to manage the remote communications (requests and responses from the STB, targeted to the various servers, and from the servers to the STB), and to link together the Web-based world, and the MHP world.
Several actors are involved in the proposed architecture: the patient, who can interact with the health operators through his DTT STB, has the possibility to authenticate by means of his personal smart card; the broadcaster, who is responsible for the delivery of audio, video and data on the radio channel, through a properly formatted MPEG-2 Transport Stream; the health operators, who can monitor each patient, send textual or multimedia messages, and provide remote assistance; finally, the healthcare centre facilities, such as the databases where each patient’s health records are stored and maintained.
Figure 3 illustrates the exchange of data flows among the system elements. The user’s STB, once tuned on the proper A/V service transmitted by one of the broadcasters providing radio coverage of the area where the user lives, is able to download an interactive MHP application (i.e. an Xlet), which can offer several capabilities, like displaying information stored inside the IS, about the patient’s health history and his future medical duties, or connecting the patient to the healthcare center, through a certified procedure to establish a privacy protected link. When available, a broadband connection can be used to convey the audio signal, an optional video signal of the patient, and the information about his physiological parameters, to the healthcare centre. At the other end of the system, the IS holds the information about the patient’s health data, and acts as the content provider for the specified DVB-T service. The DVB CM transfers this information to the OC, that is responsible for the generation of the complete DVB-T Transport Stream, and for periodically broadcasting the MHP interactive application. The SM interfaced by the user’s STB on the return channel, invokes the CAS for the authentication related handshake, and enables the transfer of the user’s physiological data and A/V monitoring signals to the healthcare center, where the assistance operators may exploit the A/V connection with the user. The A/V signal of the healthcare center is privacy-protected, according with the credentials stored in the user’s smart card, either if transmitted over the DVB-T chain, and over the return channel. The assistance operators in the healthcare centre may modify or update the patient’s records stored within the IS, in order to update the ciphered information sent over the DVB-T channel along with the MHP application.
Design of the MHP application for the health assistance service
MHP is an open standard that allows the development of interactive applications in a way which is independent from hardware platform constraints: the interface between the interactive applications and the STB operating system is given by a set of standard Application Program Interfaces (APIs). The STB middleware implements the MHP APIs in order to grant applications the access to the hardware resources in a transparent way, to handle service selection and MPEG decoding, and to execute all the operations related to Xlets and user interaction.
An MHP interactive application may be thought of as a set of graphic and textual pages the user can browse by pressing proper buttons on the remote control. Figure 4 shows two pages included in the graphical user interface of the Xlet designed for the proposed service. It is typical to access the Xlet environment by pressing the red button of the remote control, which makes the STB displaying the Xlet main page, like the one shown in Figure 4 a). From there, the user can navigate a number of pages related to diagnosis information, medical FAQs or health-related news, or he can start the authentication procedure by moving to the so-called authentication page. Once the authentication process is successfully completed, the user can access a number of contents about his personal health record (e.g. his health “history”, medical checks booked, or to book), as shown in Figure 4 b). Thanks to the MHP modular architecture, suited APIs can be added in time, to support emerging requirements; by this way, Conditional Access APIs and smart card management APIs have been included, to allow the authentication and privacy-protection of the personal health data exchanged. Recent evolutions in the delivery of health services by public institutions (such as in Germany, Italy, and France) brought to the adoption of Electronic Health Cards (EHC), based on the microstrip + chip smart card technology. In Italy, health services that are expected to be delivered through the new EHC will be designed according to the Italian National Services Card (NSC) framework [18]. By this way, physical compatibility between the card and the STB reader will be ensured, as DVB-T STBs are already compliant with the physical and electric standards of NSC. As a consequence, being the proposed MHP application designed to interface NSC-based smart cards, it is possible to claim the feasibility of EHC integration, if needed. Among the services that will be supported by the EHC adoption, the Electronic Health Record (EHR) will probably have a strong impact on the way citizens and public health institutions interact. In this sense, the possibility of integrating the information provided by a daily and long term monitoring service, like the one presented here, into the patient’s EHR, opens the way to a number of possible advanced services to be designed in the future.
The MHP application layout
As shown in Figure 5, the MHP application has a quite simple architecture. This allows an easy identification of the main functionalities to be provided, and, accordingly, an efficient maintenance of the software application, even in view of future possible extensions. Further, the application is inspired by an SOA approach: the data can be recovered in a way independent from the technology, and treated by the execution of a specific logic. Health data collected by the sensors in the network are formatted according to a suitable XML schema, which is agreed upon by all the entities involved in the system (i.e. the Information Server, the MHP application, the health centre facilities), and they may be exchanged either over the DVB-T radio channel or the return channel connection.
First of all, the application Home Page provides the user the point of access to the service; once the user presses the red button on the STB remote control, the Authentication Page is opened. The step of user authentication, executed by inserting the user’s smart card into the proper STB slot, is fundamental in the service provisioning. It has an immediate advantage, given by the fact that the user’s personal data are collected directly from the smart card, and it is not needed to manually insert textual information by means of the remote control buttons, through a graphical keyboard. Besides that, authentication and ciphering operations are performed by the security engine implemented into the smart card, and are applied to protect sensible user data, when transferred to the healthcare centre, or to the IS located at the broadcaster’s premise. Once the authentication procedure is successfully executed, which means the user has inserted the correct Personal Identification Number (PIN), the application displays a new page, named Request Page, from which the user may choose to move to the VideoConference Page, or to the Remote Assistance Page. The former is selected when the patient wants to establish an A/V connection to the remote health centre, in order to communicate with the health operators. The latter leads the user to a number of pages dedicated to data collection: health data collected through these pages are then transferred to the remote centre over a secure connection, through the STB return channel, in a way that is transparent to the user. Different application pages deal with different health data to be collected (such as blood sugar level, blood pressure, and so on): each page is related to a specific set of data, and the graphic user interface to insert the data changes correspondingly and automatically. In the perspective of a future extension of the service functionalities, this part of the MHP application has been designed in such a way as to be able to locally save the data inserted by the user in a file, and to read them from a file. Saving data on a file is useful when data are to be transferred to the remote health centre; reading data from a file may be essential when such a file is generated by a proper appliance, that interfaces a network of biomedical devices, and collects the monitored parameters. This may represent a future extension of the service capabilities. Once the monitored data have been written and saved in a file, they are also displayed for a final check by the user, before requesting their transfer to the remote centre, by pressing a proper button on the remote control. This action activates the encryption procedure supplied by the smart card, in a way that is transparent to the user. If the user requires an A/V connection to the remote centre, the MHP application starts listening to the network interface for an UDP/RTP session; the graphic user interface manipulates the video signal to resize and place it in a proper position on the screen.
Authentication and privacy protection in MHP
The provisioning of personal remote services through on-line platforms requires access and data transfer procedures that should be secure, easy to use, and as much general purpose as possible. Smart card based schemes can comply all these requirements, ensuring secure transactions, and privacy protection of the personal data. In the MHP environment, the Security And Trust Services API (SATSA) [19] represents the reference environment for the development of software libraries able to interface smart card devices. In the framework of the proposed service, among the smart card technologies available, the Italian NSC standard has been selected. By means of an NSC device it is possible to provide certified health, bank, postal services and others, to remote users, and univocally identify each user by means of their digital signature. An NSC is a tool for user identification in a network, and can also be used to digitally sign electronic documents. Almost all the commercial STBs provide at least one smart card reader slot for pay-per-view programs and CA systems. CA card readers are in any way compliant with the physical and electrical standards of NSC; software interfaces to smart cards, instead, have to comply with the ISO 7816-4 standard [20]. Through a suitable Java library, the application interfaces the user’s NSC. By inserting the card associated PIN, each user can access certified services, without the need of providing a username and a password for each service, but simply by plugging his card into the reader slot, as shown in Figure 6. When the user plugs the card into the CA reader slot, the STB middleware raises a specific event which is captured by the EventManager implemented by the Java MHP application, that, in its turn, causes the application to display its AuthenticationPage. Through this page, by means of the STB remote control, the user inputs the card PIN. Once the PIN has been typed and verified by the card, it is possible to read user’s personal data from the NSC, by accessing the common name field, under the subject section of the certificate, as reported by the Java MHP code extract:
if (state==STATE_GETCERTIFICATE) {
CNS cns = null;
X509Certificate cert = cns.getCertificate() ;
StringBuffer result = new StringBuffer();
result.append("Version: " +cert.getVersion()+"/n");
result.append("Serial Number: " +cert.getSerialNumber()+"/n");
result.append("Signature Algorithm: " +cert.getSigAlgName()+"/n");
result.append("Certification Authority:" +cert.getIssuerID()
.getName()+"/n");
result.append("Valid since: " +cert.getNotBefore()+"/n");
result.append("Valid until: " +cert.getNotAfter()+"/n");
result.append("Subject: " +cert.getSubjectDN().getName()+"/n");
⋯
} else ⋯
The type of authentication described above is based on Sun X.509 v3 digital certificates, stored inside each user’s NSC device. As in X.509 v1 certificates, specific information are available, such as: serial number, certification authority identifier, card holder identity (the “Common Name” subfield contains the card holder’s tax code, that is basically used as the username in network authentication procedures), public key, expiration time, key pair generation algorithm, and others. Further, X.509 v3 certificates also include information about key usages, certificate policies, and how to query a specific certificate revocation list. When dealing with network authentication, the key usage field is set to the specific non repudiation value. Authentication and identification by means of MHP decoder and user NSC device is performed according to a challenge/response paradigm. The client (MHP STB) extracts from the card internal memory the user’s certificate, and sends it for authentication to the remote server; once the server verifies the client certificate, it generates a random authentication challenge and sends it back to the client. The response is computed by the client, by signing the challenge with the user’s private key stored within his NSC device. Once the response is received by the remote server, it may check the value by means of the user’s public key, that was sent inside the user’s certificate. In a successful verification, the user is authenticated. Both the user’s certificate and the health service provider certificate are issued by a recognized and trusted Certification Authority (CA). In Italy, the CA currently in charge of issuing digital certificates to promote the use of electronic authentication is the CNIPA institute, that is also responsible for the specification of the NSC framework. Thanks to the Java SATSA API, it is possible to query the NSC device for extracting the card holder information, through an MHP application. By this way, the user may avoid the manual insertion of his authentication data through the RC buttons. Figure 7 shows the authentication infrastructure used when dealing with the NSC framework. At first, the user’s connection is dealt with by the access network: the connection is directed towards the NSC authentication subsystem, and only upon successful authentication it is forwarded by the router forwarder (Rtr/FW) to the proper destination, such as the health service provider network, shown in the figure.
Another basic feature supported by MHP is the possibility to implement a secure return channel communication according with the Secure Socket Layer/Transport Layer Security (SSL/TLS) protocols, towards the services exposed by certified entities. In the context of the proposed system, this allows to set up a privacy-protected connection between the home user and the remote servers, for exchanging sensitive information. If the client (i.e. the user’s STB) needs to transfer data to the health centre, it connects to the Service Manager which redirects the connection to the CAS for authentication and authorization purposes. The authentication scheme to perform, and the cipher suite to apply, are negotiated through a proper handshake procedure. The CAS represents the core element to access any available service requiring user authentication: it checks the user credentials, by addressing a query to the User Profiles Database, and gives back the corresponding Simple Object Access Protocol (SOAP) answer. The SOAP answer is processed by the SM, converted to a suited XML file and transmitted back to the user’s STB. The Xlet parses the received XML file, and, as a consequence of a succesfull (or not) user identification, the application is enabled (or not) to use a protected connection towards the health centre.
Further details about the Java card library may be found in [21]. Automatic reading of the subject’s information stored in the card, and its use during a transaction, avoids typing by means of the STB remote control keys, that can be an action not easy to perform, particularly for elderly or impaired people.