Home >Documents >794 IEEE TRANSACTIONS ON INFORMATION · PDF file794 IEEE TRANSACTIONS ON INFORMATION...

794 IEEE TRANSACTIONS ON INFORMATION · PDF file794 IEEE TRANSACTIONS ON INFORMATION...

Date post:30-Aug-2018
Category:
View:217 times
Download:0 times
Share this document with a friend
Transcript:
  • 794 IEEE TRANSACTIONS ON INFORMATION TECHNOLOGY IN BIOMEDICINE, VOL. 10, NO. 4, OCTOBER 2006

    A Jini-Based Solution for Electronic PrescriptionsGheorghita Ghinea, Member, IEEE, Shervin Asgari, Arash Moradi, and Tacha Serif

    AbstractIn most countries today, handwritten, paper-basedmedical prescriptions are the norm. While efforts have been madein the past and are being made at present to migrate towardelectronic dispensation of prescriptions, these have generallyomitted to incorporate ubiquitous computing technology intheir proposed solutions. In this paper, we focus on this issueand describe a Jini-based prototypical solution for electronicprescriptions, which allows for their wireless transmission toin-range pharmacies and the augmentation of the service levelsrendered to the user, with, for instance, information about queuelengths and estimated waiting times being provided to the patients.Clinical and user evaluation revealed that there were high levels ofagreement as regards the prototypes effectiveness, ease of use, andusefulness.

    Index TermsElectronic prescriptions, Jini, ubiquitouscomputing.

    I. INTRODUCTION

    TODAY, in most countries, a handwritten medical prescrip-tion is the most common way of prescribing medicine. Aprescribing doctor writes the prescription after a direct consul-tation with a patient. The prescription is then signed and handedover to the patient who carries it to the pharmacy for dispens-ing, with the patient being free to choose whichever pharmacyshe/he wishes to go to. The pharmacist is handed over the paperprescription, and she/he enters the details into the system. Thesystem then prints out the usage labels for the drug, and lastlythe patient signs the prescription, pays for the expenses, andreceives the drug.

    While computerized systems for drug treatment have ad-vanced simultaneously with the proliferation of computing andnetworking technologies, work in the field of electronic pre-scriptions has mainly taken place in the context of hospitalscomputerized prescription order entry (CPOE) systems. More-over, while considerable efforts have been undertaken in relatedareas, such as the representation and exchange of computerizedmedical information [1], [2], [3] and the impact of the Interneton online prescription and dispensation of drugs [4], researchdealing with the propagation of electronic prescriptions throughthe practitionerpatientpharmacy chain remains relativelyscarce.

    Pilots of electronic prescription systems (EPSs) took placeas early as 1997 in the U.K. [5]. These were respectively, theTranscript, Pharmacy2U, and Flexiscript models. The Transcript

    Manuscript received October 22, 2005; revised February 13, 2006 and March25, 2006.

    The authors are with the School of Information Systems, Computing andMathematics, Brunel University Uxbridge UB8 3PH, U.K. (e-mail: [email protected]; [email protected]; [email protected]; [email protected]).

    Digital Object Identifier 10.1109/TITB.2006.879586

    model uses a two-dimensional (2-D) barcode on a paper pre-scription that the patients deliver to a pharmacy of their choice.The pharmacist scans in the barcode, validates the digital sig-nature, and dispenses the drugs. The Pharmacy2U model re-lies on the patients using designated pharmacies. The generalpractitioner (GP) encrypts and digitally signs the prescription,and sends it directly to the designated pharmacy. Lastly, theFlexiscript model relies on using a central storage wherethe prescriptions are stored until retrieved by a pharmacist.The system also generates a paper prescription containing aunique data store identification number for the patient and abarcode representation of the digitally signed prescription. Thepatient takes the prescription to any pharmacy, and the pharma-cist uses the identification number to retrieve the e-prescriptionfrom the central storage. Although they were all beset by var-ious shortcomings, acceptability of the developed EPSs washigh [6]. Other models suggest using a smartcard containing themedical history, which the patient always carries around. Theidea is that the patients could deliver this smartcard, which thepharmacists could use to decrypt and to extract the prescriptionfrom [7], [8], [9]. Needless to say, none of these early developedsolutions incorporated wireless technology. More recently, solu-tions that are wireless based have been piloted. Thus, solutionsbased on smartcards, where repeat prescriptions are transmit-ted wirelessly to the patients doctor [10], have been piloted,as have point-of-care systems. Here, prescriptions are writtenon a personal digital assistant (PDA) at the point of care, andtransmitted during cradle synchronization with a PC, to a pre-defined pharmacy [11]. However, all of these solutions sufferfrom either one (or both) of the two major drawbacks. First, theyare not generic (involving specialized scenarios, such as repeatprescriptions, where problems encountered in the more generalcase of prescribing medicine, such as potentially toxic drug in-teractions do not occur). Secondly, they are not truly ubiquitous(since they involve only wireless data upload, in a given, local-ized, settingsuch as a surgery or the patients homewith allsubsequent data communication taking place through a wiredmedium).

    In this paper, we have sought to address the limitations iden-tified earlier, and have developed a wireless prototype solutionfor an EPS. Our proof-of-concept solution is not intended as areplacement for the existing, non-wireless, EPS initiatives. Onthe contrary, it is complementary, harnessing Jini technology tooffer enhanced levels of service to clinicians and patients alike.Accordingly, the structure of this paper is as follows. Section IIpresents an overview of the Jini technology and its applicationsin telemedicine. Section III then goes on to discuss the benefitsof electronic prescriptions and current implementations of EPSs.In Section IV, a detailed description of the implementation ofour solution is provided, while Section V presents a walkthroughof the proposed prototype. Lastly, Section VI presents the results

    1089-7771/$20.00 2006 IEEE

  • GHINEA et al.: A JINI-BASED SOLUTION FOR ELECTRONIC PRESCRIPTIONS 795

    Fig. 1. Jini discover/join protocol.

    of an evaluative study of our solution, while the implications ofour work are elaborated upon in Section VII, where conclusionsand possibilities for future work are presented.

    II. JINI TECHNOLOGY IN TELEMEDICINE

    Jini is a service-oriented framework that enables the entitiesin a distributed environment to define, discover, and advertisetheir services in a robust and impromptu manner [12]. It providesa spontaneous and self-healing environment [13], where theservices and service consumers can enter and leave a networkwithout affecting or interrupting the existing network activities.

    Services are the most important concept within Jini. Theymake use of the infrastructure and programming model to dis-cover other services, take part in federations, and announcetheir presence to other services and users. To do this, the Jinitechnology revolves around a trio of protocols: discover, join,and lookup. The first two provide the service advertisementfunctionality. Thus, the discovery protocol is used when a newservice provider in a Jini federation needs to register with alookup service, in which the service provider uses either unicastor multicast discovery to locate a lookup service [12], [14].

    Once this is done, the join protocol entails the service provideruploading a service object to the lookup service (arrow 1 inFig. 1). This object represents the service and can be regardedas a proxy. The proxy is a part of the service that is visibleto the clients, but its job will be to pass method calls back tothe rest of the objects that form the total implementation ofthe service. At this stage, the service has entered the federa-tion and is ready to be discovered. This is done by the lookupprotocol.

    Accordingly, the client locates a lookup service, finding anappropriate service by its type interface and attributes. The ser-vice object is then loaded into the client (arrow 2). The finalstage involves the client communicating directly with the ser-vice provider via the proxy object (arrow 3). The client employsthe methods provided in the proxy to invoke the service and per-form operations specific to it. Depending on the type of service,the proxy could be a remote method invocation (RMI) referenceto the actual service, a local copy of the entire service, or acombination of both. In the latter case, some of the functionsof the service are provided locally and the remaining throughremote calls to the service implementation.

    A. Telemedicine Applications

    As expected, in the telemedicine area, Jini has been usedto interface and integrate previously disparate devices. Ac-cordingly, Jini has been applied in the Department of NuclearMedicine at Wilhelminenspital, the largest community hospitalin Vienna, Austria. In this study, Knoll et al. [15] integratedthe combination-computed tomography (CT) scanner and thesingle-photon emission computed tomography (SPECT) cam-era. The evaluation confirmed that the Jini technology had in-creased Wilhelminenspitals capacity to spot previously unseentumors in their patients. From a different perspective, Petrovskiand Grundy [16] integrated different development technologiesto implement a health information system. As a part of theirproposed solution, the Jini technology was utilized to supportthe interfacing of observational appliances, such as electrocar-diogram (ECG) monitoring devices, and applet-enabled PDAs.From a similar context, Eko Systems developed a complete med-ical system named Frontiers [17]. In Frontiers, all observationaldevices are integrated in a system in which the Jini ag

Click here to load reader

Reader Image
Embed Size (px)
Recommended