Many attempts have been made over the last two decades to computerize the management of patient records using advanced computing and networking facilities across hospitals, clinics, and billing agents. A patient’s record represents the key repository for information concerning his or her health care. While patient record management has achieved modest progress within a closed organization in terms of facilitating seamless integration with an organization-wide health information system, its provision for open patient record management has met with little success. A truly ubiquitous availability of patient records can greatly improve health care delivery by providing medical personnel with timely access of often critical medical records such as past medical history, blood type, and even next-of-kin information [3, 11]. With the increasing mobility of individuals in a global economy, the demand for providing anytime, anywhere, anyplace access to a patient’s medical record has not been met [6].
The emergence of smart card technology is recognized as a potential solution to manage a patient’s medical records effectively and accurately [8]. Medical records contained within the card can be augmented to include multimedia-rich information such as scanned images and voice recordings, to facilitate rapid diagnosis of a patient’s possible symptoms and problems. In short, a smart card provides the rich benefits of storing a comprehensive, accurate, and up-to-date medical history of a patient, while its pocket size offers easy mobility [9].
Although a smart card offers a highly advanced solution for managing an often complex medical record database, it has yet to gain the mass support critical for wide market acceptance of such technology. A major hindrance of such advancement is attributed to the diverse protocol and API standards currently available from various vendors. This has resulted in the development of ad-hoc systems [4, 5] that often limit smart card usage to one environment or enterprise. As such, medical records stored on a smart card from hospital A are not readable by hospital B.
In a step toward facilitating a common standard, ISO has standardized the protocol communication between a smart card and a smart card reader based on the ISO 7816 specification family. While this has addressed part of the standardization barrier, there still exists the need to facilitate a unified file access system and application code transparency. Building on the same spirit as the original Java, Sun has developed the Java Card API specifications [10] to facilitate the concept of “write once, run on all cards.”
Our research aims to further develop the standardization effort to support a Web-based medical-specific smart card application framework. Figure 1 divides the standardization framework into horizontal and vertical dimensions. While ISO 7816 and the Java Card represent the so-called horizontal standards to facilitate a common computing platform for smart card development environment, we propose a vertical standard framework that addresses the design requirements specific to the development of medical applications. Examples of such requirements are efficient medical record structuring, a uniform file access system, patient’s record security, Web integration, and ease of record viewing and updating.
The concept of the Java Card Web Servlet (JCWS) was developed to provide a seamless access interface between a Web browser and a Java Card-enabled smart card as shown in Figure 2. In essence, the smart card is viewed as a repository of Web-enabled objects comprised of applets, HTML page, data objects, and Java Card applets.
The framework supports tight integration of smart card technology with an existing Web infrastructure. Therefore, a hospital with a Java-compliant smart card reader is able to access medical information directly from the card using a standard Web browser via the JCWS. An applet contained within the card can be dynamically loaded into the browser to browse and update medical information. The applet can also provide Web links to Internet databases to facilitate wide-area access of further information such as a video of a recent CT scan, high-resolution X-ray image scans, and so forth. Figure 3 illustrates the concept of the smart card viewed as a mobile database containing a patient’s medical record. As the smart card database travels to a new location, the JCWS binds the database to the framework, while providing Web-based browsing and updating services. In this case, the browsing and updating applet can be downloaded from the smart card itself via the browser interface.
Smart card technology presents a new paradigm in computing environments based on embedding processing elements on a credit card-sized platform. The technology offers the benefits of easy mobility, with the capability of storing a great capacity of information as compared to the magnetic-based plastic cards. More importantly, smart cards with local processing capabilities facilitate the development of active programs designed to manage complex patient medical records effectively and accurately. The patient’s information is essentially augmented with active programs residing within the smart card to provide rich services, such as record management facilities, security and authentication, and a clinical alert system.
While smart card technology for medical applications has been in existence for some time now, its use has been largely restricted to within large organizations such as hospitals, health insurance firms, and medical groups. The services provided are limited to the workflow of simple patient-record management that operates within company departments. Extending and integrating such technology and services to a wider community across hospitals, medical insurance firms, polyclinics, and dental clinics, poses major technical limitations due to a lack of network infrastructure and access points. With the continue proliferation of Internet technology, the consideration of integrating smart card and Internet technology to facilitate a wide-area medical information system must be revisited. By closely combining the benefits of these technologies for medical applications, rich services can be developed and implemented rapidly, with the ultimate objective of accelerating productivity and quality of health care. In short, the marriage of these two technologies presents the following complementary benefits:
Efficient medical record management. A smart card with its quantum storage capacity is ideal for storing essential medical records such as a patient’s blood type, drugs allergies, regularly prescribed drugs, and so on. Such benefits, coupled with the portable nature of the device, means that patients can carry and their medical records available anytime, anywhere, and anyplace. In contrast with a low-memory magnetic-stripe card counterpart, which requires online operation, there is no explicit need for a smart card to login to a central server to access critical data. While a smart card can leverage on the rich services available for online operation, the requirement for offline access and management of medical records is vital in the event of an emergency or unavailability of network access. The JCWS framework is designed to support both offline and online operation of smart card information access. In the former case, the standard Web browser operates in a standalone mode such that the access procedure to a smart card’s medical record is facilitated by an active applet downloaded from within the card itself. A smart card that carries its own record management applet while being hosted by a commonly available Web browser presents a powerful paradigm to support a truly mobile and open environment. Indeed, it enables medical personnel to gain access to vital patient medical records quickly without the need for a compatible information system in a hospital or clinic. Such immediate availability and easy access to critical patient records in the event of an accident or emergency may mean the difference between life and death.
Rapid deployment of enhanced networked services. The ability of a Web-enabled smart card to seamlessly integrate evolving Internet technology potentially translates to a medical information system offering rich services provided by the underlying infrastructure. The Internet, and the Web in particular, offer an opportunity to provide distributed health services that allow for exchanging medical knowledge and monitoring patient health [1]. For example, complex services such as remote diagnostics and a health-related decision-making process can be integrated efficiently with a smart card’s patient record to provide added treatment alternatives to improve the overall quality of health services.
Moreover, the medical information system within a hospital is able to access and extract vital patient information from the smart card using standard browser functions. The hyperlinked medical Web page from within the smart card’s repository enables doctors to systematically browse through a structured set of critical medical information. In this context, it is possible for the smart card entity to participate within the workflow of the hospital’s health information system including admission and registration, laboratory information management, and financial management. The exchange of electronic medical data, however, requires the establishment of a canonical medical record structure with supporting data abstraction processes to provide unified views of medical information.
Low deployment costs. The significant infiltration of Internet technology to home and offices via various access methods (including dial-up, leased line, ADSL, and cable modem) enable us to rapidly and economically deploy medical information systems across a wide medical community. In particular, there is no need to install special network hardware or user agents on each of the potential participants’ (including doctors, hospitals, or patients) computers.
Ubiquity access. Flowing from the wide accessibility of Internet technology, the browser is seen as the defacto user interface to access the rich information repository within the Web. Far from simply adopting the traditional client/server approach, the Web browser supports a rich spectrum of computing paradigms, including client-side programming using applets, server-side programming using servlets, plug-ins, CGI interfaces, and XML. The mobility of a smart card, coupled with the ubiquitous access of a software-configurable Web browser, plays an important role in promoting a truly mobile and interactive medical information technology.
JCWS Architecture Overview
The main objective of the JCWS architecture is to form a Web service interface between the smart card data objects repository and a standard Web browser. The framework is comprised of two sublayers of Java-based components, as depicted in Figure 4.
The Web Servlet Component (WSC) layer is concerned with providing general Web services to incoming requests. It functions specifically as a lightweight HTTP Web server to the smart card’s Web repository. For example, to gain initial access to a user’s personal and medical information on a smart card (if security permits), a doctor may issue a HTTP request on the loopback URL address of 127.0.0.1. This will invoke the request for the index file, which can be comprised of a static Web page directory of medical information.
Alternatively, the index file may act as a container for an applet downloaded directly from the smart card to assist in active browsing and updating medical records, as shown in Figure 5. The attractive benefit of such an approach is the ability of the framework to operate in an autonomous mode without the need for online operation. Additionally, the benefit of a smart card able to carry its own record-management tool eliminates the need for software agents from different systems. Such an approach truly supports the “write once, manage everywhere” concept.
The Service Component (SC) sublayer is a collection of common medical specific services. The objective of SC is to augment and complement the functionality of the WSC sublayer. In addition to providing direct services to WSC, each service specific component is encapsulated with open programming interfaces to enable remote method invocation (RMI) from other components to enhance the services provided. In particular, we have employed a similar approach to enable the downloaded record management applet to invoke service interfaces from the Web browser. Figure 5 shows the record management applet for browsing and inputting a doctor’s assessment of a patient’s medical history. Each tab in the user interface represents an area of clinical examination.
Each of the service components is implemented using a two-level service-proxy entities approach. The service entity of the component is executed on the host, while the proxy counterpart is executed on the smart card platform. The main rational for such an approach is to enable offloading of much of the service component to be executed on the host due to memory constrain of smart card device. The proxy entity on the smart card is responsible for the low-level execution of commands mediated by the service entity. Importantly, the proxy entity is designed to facilitate open interfaces to resources available on the smart card, while implementing comprehensive control and policy within the service entity. For example, in the security service component, the proxy entity is responsible for providing open access to the cryptography services supported by the Java Card framework, such as privacy and authentication.
Although a smart card offers a highly advanced solution for managing an often complex medical record database, it has yet to gain the mass support critical for wide market acceptance of such technology.
Given the open interfaces supported by the proxy counterpart, the service entity is required to implement comprehensive high-level access control and policy to enforce security requirements specific for medical record management. The two-level service-proxy entities approach provides a consistent way to separate the low-level mechanisms from the central control policy. Such a layering approach promotes rapid development and deployment of improved services, without the risk of incurring large maintenance overheads.
The core service components include:
A medical file system. This component provides high-level file management services to WCS and object applications to implement hierarchically structured medical record storage. The service defines several well-known object interfaces to enable applications to create, retrieve, and manage medical record access, while facilitating the direct mapping of these requests to a low-level Java Card API.
Security service. This component provides a comprehensive framework for medical record access security. It supports authentication and access control to sensitive information such as a patient’s psychiatric history, sensitive social history, among others. It supports a hierarchical approach to managing a patient’s medical records. For example, a nurse may have access to a patient’s key medical information (perhaps without security password); pharmacies are authorized to gain access to a patient’s drug allergy and related information, while physicians are allowed full access to a patient’s detailed medical history and the ability to update it.
Event notification service. This component provides interfaces for medical application objects to register or unregister specific events of interests. For example, applets or objects can be designed to closely monitor the risk of drug interactions or allergic reactions by registering the event(s) with the event notification service objects. Whenever a smart card is inserted into the reader, a structured list of registered events is loaded into the repository of the event notification service component. The detection of a registered event will result in triggering a procedural call to the various objects interested in the event.
The component services implemented here represent the core service facilities usable by WSC and application objects. Note, however, the architecture of JCWS encourages the extension of service facilities by allowing the capability of adding service components when needed.
Due to the current availability of smart card reader hardware and software development tools, we chose to develop the platform for the x86 PC architecture under the Windows operating system. The system components are written entirely in the Java language. As such, the portability of Java ensures the framework will operate across heterogeneous operating systems and environments. Our implementation focuses on the interface between the smart card and Web browser. Communications between the two entities are achieved using standard HTTP1 request-reply via the JCWS service. At the moment, the JCWS supports a file access open programming interface call using Java RMI, while further functionality such as security and alert interfaces can be added at a later stage.
The next important component in our implementation is the browsing and management applet. The applet is designed to provide the user with the ability to actively browse and manage contents within the smart card repository. The user interface of the applet is in the form of a tab-controlled panel organized according to the clinical examination category as shown in Figure 5. The applet is designed to be stored as part of the repository objects contained within the smart card.
To promote the development of a highly structured patient medical record, with well-defined metadata specifications, we have used XML as the baseline formatting language for markup. As opposed to HTML, which is designed for display markup, XML supports customized specifications of application-specific tags to promote machine-understandable data processing. This approach of using XML for medical record structuring is in line with the recent announcement of a group within the Health Level 7 (HL7) standard body to derive a standardized medical-specific information structure built on XML [7].
Conclusion
As VLSI technology continues to advance, processor-based smart cards will be packed with more powerful processors, with much higher memory configuration, capable of storing tens of pages of text. Such advancement offers the possibility of moving away from the use of pure optical memory cards (currently used in most Hong Kong medical smart card trials [12]) to a more general processor-based smart card for medical applications. This will enable us to use the processing capabilities of the built-in processor, while incorporating the rich benefits of Java Card technology. More importantly, this will significantly reduce the per-unit cost of a smart card and the associated card reader. As the cost of these devices continues to plummet, smart card technology will begin to infiltrate the client market. Such a trend will inevitably create the necessary critical acceptance of the technology. It is estimated that over 100 billion transactions will be made using smart cards this year with an estimated growth of more than 50% yearly [2]. It is also expected that the research will contribute to facilitate rapid adoption and integration of this technology to the cutting edge of information technology.
The framework supports transitional migration by:
- Supporting standalone ubiquitous access of smart card medical records by using widely available Web browsers.
- The seamless integration of smart card access to the Internet will facilitate close coupling between distributed medical services and clients. For example, a client can purchase prescribed drugs from the Internet-based pharmacy by slotting his or her smart card into his or her personal card reader. The prescribed drug information, together with the doctor’s identification, will be sent securely to the pharmacy for processing.
With Internet access soaring, and the comprehensive communication infrastructure in place, Hong Kong is well positioned to capitalize on the benefits of e-commerce. This research aims to contribute in the area of health commerce, with the ultimate objective of enhancing the quality and efficiency of health services in Hong Kong.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment