![[INET 2000]](/web/20160103041143im_/http://www.isoc.org/inet2000/cdproceedings/inet00sm.gif)
![[ Up ]](/web/20160103041143im_/http://www.isoc.org/inet2000/cdproceedings/up.gif)
![[Prev]](/web/20160103041143im_/http://www.isoc.org/inet2000/cdproceedings/prev.gif)
![[Next]](/web/20160103041143im_/http://www.isoc.org/inet2000/cdproceedings/next.gif)
The paper presents a national project to introduce smart cards into the health-care sector in Slovenia and its future perspectives. This project is aimed at integrating smart card technology with the communication infrastructure to support a nationwide health-care information system. Based on experience gained so far and to achieve this goal, the required functionality is discussed in this paper, starting with smart cards and ending with electronic data interface (EDI) technology. The current architecture is investigated in light of emerging standards and available commercial products. Technical and architectural solutions are given to enable a real-time and EDI-based environment for a general set of applications in the medical sector, supported by the flexibility and security of modern smart card technologies.
Keywords: smart cards, EDI, web technology, health-care information system infrastructure.
Health institutions and health providers in Europe and other parts of the world are rapidly introducing health-care information systems. Deployment of the latest smart card technology is common to several of these projects and is envisaged as becoming a regular component in the coming years. The evolution of smart-card-based medical information systems is oriented not only to manipulation of health-related data but also to support of all transactions in the health-care sector.
Slovenia is engaged in a similar scenario. It is a well-developed country in terms of medical and health informatics, and institutions are reasonably well equipped with personal computers. However, current health-care information systems are quite heterogeneous and the level of countrywide integration is weak. Different standards are used, implementations of electronic patient records are mutually incompatible, and systems are based on outdated technology that presents barriers to further integration or extension without substantial re-engineering. Furthermore, medical data, information, and documents are stored on media systems ranging from classic data collections (which still account for 70% of all data) to computer-assisted systems. The development of a nationwide health-care information system is a long-term process with a number of components and development directions. Ever new developments are taking place.
In 1995 the Health Insurance Institute of Slovenia (HIIS) started a project of introducing smart cards nationwide [1, 2]. This is now becoming an important component of a further improved and integrated nationwide health-care information system. The new system is based on smart cards using symmetric key cryptography and an Internet protocol (IP) network that links computers within institutions and provides connection to the Internet. Currently only elementary transactions of insurance relevant data are supported. The final goal is to provide an infrastructure basis that integrates this system with other telematics solutions in the national health-care information system. This system has to be in line with specific standards in the field of smart cards and health-care information systems [3, 4]. It also has to be in line with more general standards related to EDI, computer communications, and public key infrastructure (e.g., [5, 6, 7, 8]). And finally, the system has to be based on widely available commercial solutions in order to reduce costs and enhance reliability, which basically implies web technology [9, 10].
Particular architectural issues need to be addressed to achieve a level of modularity that will not limit future integration of new services. These issues are interoperability of the smart card solutions and platforms, chip independence of applications on smart cards, independence of card issuer and card reader vendors, and dynamic downloading of applications. In addition, scalable and widely accepted standardized solutions for authenticated access and secured transactions, along with secure execution of different applications on smart cards, have to be considered. Last but not least, the role of the insurance card must be clearly identified and this will be discussed in the following sections.
The Slovene Health Insurance Card System uses two types of smart cards: an insured person's Health Insurance Card and a Health Professional Card. The insurance card serves for identification and as a crypto device medium for carrying administrative data. It will gradually replace the conventional health-care booklet to eliminate extensive administrative procedures. The card stores insured persons' details, contribution obligor's data, data concerning compulsory and voluntary health insurance, and data on selected personal physicians and organ donation. Introduction of electronic prescription is currently taking place. Other applications (electronic order for technical aids, documentation of issued drugs, medical record pointers, and G7 emergency data set) will be achieved in not more than five years.
The professional card is introduced to ensure access rights for accessing identification data on the insurance card and, in the future, various remote databases. It contains the cardholders' identification number, serial number, cardholder's first name and surname, profession, specialization, country code, Institute of Public Health number, and type of authorization. If a cardholder is not a physician, the professional card also contains the country code of the authorized legal entity, Institute of Public Health number of the authorized legal entity, and its title.
Currently the infrastructure of the nationwide health insurance card system consists of two subsystems. The first subsystem is a network of self-service terminals, where insurance data can be updated, using the insurance card. Self-service terminals are connected to two central databases at the HIIS and the Adriatic insurance company. This communication is done through a secure communication channel that is based on a proprietary solution. The second subsystem consists of personal computers (PCs) at doctors' offices, where insurance cards are used after the process of mutual authentication with the professional card. The doctors' PCs use standalone proprietary applications without a real-time remote communication.
One of the main problems is the use of symmetric cryptography-based smart cards that affect a large part of the whole system architecture. The most likely transition scenario includes web servers as front-ends to database management systems, while on the other side, web browsers will serve as front-ends to smart cards. Secure channels between web browsers and servers could be established this way, which is, however, not an ideal solution. End-to-end secure channels are the final goal in order to ensure security from smart cards to peer entities over the network. This requires smart-card technology capable of X.509 certificate and secure socket layer (SSL) operations. Currently, this is not economically feasible, but will change in the near future. Support of public-key operations is also needed for deployment of IPv6, the latter being choice at the level of transport protocols. However, network providers are not able to offer this service and a nationwide public key infrastructure does not yet exist.
Another problem involves professional-card-based access rights that are realized with symmetric group keys. In order to preserve the rest of the architecture of the information system and to support backward traceability of data, we are investigating the following scenario:
The overall security of the current system relies heavily on keeping symmetric group keys secret. These keys are stored and used only by smart cards and never leave the cards. The decision to share the same key among many cards was based on the assumption that smart cards can provide a high level of protection against seizure of key material, which is discussed in the next subsection.
It is unrealistic to assume that information stored in a smart card can be protected from a capable motivated opponent backed up with significant funding [11]. Furthermore, low-cost, non-invasive attacks are possible using differential power analysis [12]. This method is based on measurements of a circuit's power consumption. In addition to large-scale power variations due to instruction sequence, there are effects relating to the data values being manipulated. When an encryption algorithm is publicly known, a relatively small number of power consumption traces are needed to test possible key candidates. A similar approach may be used with electromagnetic radiation traces. Although techniques exist for preventing differential power analysis and related attacks [13], new methods of successful attack are possible in the future.
Reducing the number of cards that share the same key can significantly reduce the damage caused by a successful attack. As each insurance card may interact with each professional card, the number of different key pairs is high. Increasing the number of different key pairs in the system soon reaches the limit posed by the size of available memory on the card. Public key cryptography, in which each card has its own private key, minimizes the damage caused by revealing key material.
Owning a valid insurance card authenticates a user, while authenticity of a card is verified through cryptographic algorithms. To support better authentication, PIN (personal identification number)-enabled cards are being considered. However, the PIN is easy to forget, especially by older people. There is also a problem with organ donors. More promising methods for user authentication are based on human biometry. Several approaches are being developed, e.g., fingerprint sensor, face recognition, hand geometry, and retinal scans. The technology is improving very fast and error rates are becoming acceptable. Currently, the false rejection rate is typically below 0.1%, while the false acceptance rate is below 0.001%.
An interesting interim approach exists, which would partially solve the problem of card forgery. The more medically relevant data are on the card, the less the likelihood of its misuse. As these data are the basis for treatment, getting a wrong blood group, for example, could be fatal.
In an open environment, where various entities from different administrative domains (e.g., hospitals, pharmacies, and insurance companies) exchange data, support of EDI is mandatory. However, there are only some particular specifications that could be used in a medical sector, such as a physician letter (HL7), hospital-to-hospital documentation (EDIfact), etc. Many of them are intended for other business sectors. Therefore costly converters are needed, which poses problems for true interoperability (similar experiences are described in [14]). To make things worse, there are some basic data sets, like electronic patient records, that have yet to be standardized.
For the successful introduction of EDI, data sets have to be defined and they have to be stable. Appropriate documents should be defined along with transactions, that is, the sequence of steps and corresponding documents that are exchanged. Thus complete EDI support requires a set of protocols for conducting highly structured exchanges of data between different organizations. There is currently a notable lack of such specifications in the health-care sector. This presents one of the basic problems for architecture definition and for deployment of a nationwide health-care information system in Slovenia.
It should be noted that basic documents in the field of smart cards and their interoperability are already three to four years old (see, e.g., [4]). In the meantime, web technology has become an obvious choice for conducting e-business. Therefore the above-mentioned documents need to be revised to take into account widely accepted technological changes. Web technology is the most widespread and efficient technology that supports on-line transactions, and it should be considered seriously. The following are the implications for the EDI world:
The starting point is a transition to public-key-based architecture. Also for this reason, web technology will become the basis for the insurance card project. It will present transport means for complete document transactions, especially as many necessary security features are provided by default through SSL layer. The most common architecture for a smart-card-based information system is shown in figure 1(a). Transactions are based on exchange of small chunks instead of complete documents. Such a system could be described as DBMS (Data Base Management System), a transactions-oriented rather than an EDI-oriented one, which is also the case with the insurance card project. The required architecture is given in figure 1(b).
Figure 1: A common model of interoperable architecture of a smart-card-based information system (left) and a web-centric smart-card-based information system (right).
Another notable difference between the two models is their support of real time transactions. The first one significantly relies on e-mail; it is therefore an off-line system with additional requirements for infrastructure [3]. The second one is an on-line system with "all in a box" solutions.
The environment where smart card-enabled application will be executed should not limit developers. The same holds true for smart cards and card terminals. We have studied an architecture (see figure 2) for a typical client in the insurance card system. It is based on the Open Card Framework (OCF) specification [17] that embeds personal computer/smart card (PC/SC) specification [18]. These are two industrial initiatives for integrating smart cards into computer systems. Microsoft and several other companies introduced PC/SC to enable PC applications to exploit smart cards for security and e-commerce-related applications, but it does not support non-Win32-based systems. Therefore other providers, including Gemplus and Schlumberger, recognized the need for a common framework to support smart cards on other platforms. This has resulted in the OCF specification, which addressed in particular the independence of the host operating system and transparent support of different multi-application cards and management schemes. It is especially important for the insurance card project that the OCF specification supports card readers with multiple slots. Such readers are needed in health-care applications, where a master smart card has to be present in the same reader to unlock the use of the second card belonging to a patient.
Figure 2: Client architecture.
Several of the above stated objectives regarding the insurance card system are met by OCF. The OCF is independent of the underlying operating system because it is implemented in JAVA. All OCF components written in JAVA become immediately available on any JAVA-enabled platform, be it a client at the doctor's office, a database server, or a self-service terminal. The interoperability of the smart card solutions and the independence of the system from specific card issuer and card reader vendor can be achieved. In addition, a transparent support of different multi-application cards can be achieved, something which will be required in a future health-care information system.
JAVA card provides the solution to the above-mentioned problems [19]. Currently, card applets should not require extensive processing. Therefore an efficient SSL-like end-to-end protocol between the card and a remote server is not possible. Such implementation would require an additional cryptographic processor. Some manufacturers offer JAVA cards with crypto processor, but export laws prohibit their global use.
The need for a cryptographic processor is evident also from the performance measurements that we carried out on the Cyberflex JAVA card from Schlumberger. We have implemented several test applets. An empty loop (statement "for") consumed 10 ms of the execution time. The algorithm RC4, which is a part of SSL protocol cipher suite, needed 25 s for the initialization phase, while the encryption of a stream of 16 bytes took 3 s to complete. However, the card in the insurance card system performs much better and encrypts a block of 8 bytes with DES3 algorithm in only 20 ms. Such performance of JAVA card is not sufficient for immediate migration, especially when taking into account programming limitations, which are:
Other significant limitations of the JAVA card environment are:
The current processing requirements for the insurance card and the professional card are low as the cards perform only authentication and file system access. This will not be the case in the future. Other applications, such as storing digital prescription, establishing an end-to-end secure channel, and authenticating the user with biometry techniques, will make higher demands. When current cards will be redeemed, JAVA card will be most likely deployed. Due to Moore' s law, many of the above-mentioned limitations will be overcome by that time.
The health insurance card project in Slovenia is on the point of full-scale deployment. Together with networking activities it provides an infrastructure that will support further development of the national health-care information system. We expect to achieve significant benefits with the employment of web and JAVA Card technologies. The development of the Slovene health-care information system is an ongoing intensive process, and at present, it is undergoing renovation, which provides a good opportunity for introducing advanced solutions. Basic requirements, as discussed in this paper, are:
Regarding the first requirement, things are more or less obvious. Regarding the second bullet, a complete and comprehensive EDI set of health-care-sector-related specifications, suitable for the web environment, is needed. An internationally coordinated project is to be carried out in the field of EDI to define stable data-sets, appropriate electronic documents, and procedures (protocols) for conducting business in the medical sector. Some of these issues are still in the definition or development stage, so that full implementation in Slovenia is likely to extend over a period of several years. Regarding the third requirement, the design of future insurance card system will be based on JAVA cards, but its system capabilities have to be improved. And finally, the role of smart cards can be clearly identified: they will serve for authentication, for storage of minimal data sets, and as pointers to appropriate data sets in a network.