AAOAACA LOY AAAA
`
`US 20020143434A1
`
`as) United States
`a2) Patent Application Publication (10) Pub. No.: US 2002/0143434 Al
`
` Greeven etal. (43) Pub. Date: Oct. 3, 2002
`
`
`(54) METHOD AND APPARATUS FOR
`DELIVERING AND REFILLING
`PHARMACEUTICALS
`
`(76)
`
`Inventors: John Greeven, Corvallis, OR (US);
`Michelle D. Greeven, Corvallis, OR
`(US); Jeffrey M. Valley, Corvallis, OR
`(US)
`
`Correspondence Address:
`HEWLETT-PACKARD COMPANY
`Intellectual Property Administration
`P.O. Box 272400
`Fort Collins, CO 80527-2400 (US)
`
`(21) Appl. No.:
`
`09/823,188
`
`(22)
`
`Filed:
`
`Mar. 29, 2001
`
`Publication Classification
`
`Int. C17 cases G06F 17/60; GO6F 17/00
`(51)
`(52) U.S. Che
`cassssssssssssstnsene 700/236; 700/237; 705/28
`
`(57)
`
`ABSTRACT
`
`An on-line pharmaceutical ordering system enables the
`transmission of pharmaceutical orders by the Internet. Elec-
`tronic drug delivery appliances that administer or dispense
`drugs and supplies are equipped with data network interface
`circuitry by whichrefills of supplies can be ordered without
`patient or doctor intervention. In an another embodiment, a
`medical service provider can electronically order supplies
`for or by the patient. On-line validation insures legitimacy of
`an order.
`
`
`
`~
`
`|
`
`|
`
`|
`
`
`
`~~ 106
`108
`
`110
`| Ls
`
`
`109
`
`
`
`
`
`
`109.
`
`DATA
`SENSORS
`
`VIDEO
`DISPLAY
`
`114
`
`rT _
`
`
`
`|
`PATIENT
`SCREEN/ Pp
`
`
`
`102
`?
`
`
`TO]
`=
`
`
`Tr
`
`
`
`
`
`
`lL
`
`
`ln
`
`
`
`
`
`
`
`RAM
`ROM
`EEPROM
`
`114-4
`
`
`
`|
`
`118
`
`pc
`INTERFACE
`
`|»
`
`WIRELESS RF
`120 ~~ 0ATA INTERFACE
`
`NETWORK
`INTERFACE
`
`
`TCP/IP ATM 4 t
`
`123
`
`PROVI-1011 - Page 1
`
`PROVI-1011 - Page 1
`
`

`

`Patent Application Publication
`
`Oct. 3, 2002 Sheet 1 of 5
`
`US 2002/0143434 A1
`
`100|
`|
`|
`|
`
`| |
`
`111
`104
`
`|
`|
`! 109
`|
`|
`
`
`
`PATIENT
`DATA
`SENSORS
`
`SCREEN/
`VIDEO
`DISPLAY
`
`102
`
`106
`
`|
`|
`|
`|
`112
`|
`LL \AX108
`
`
`
`|A
`
`110
`he
`|
`115 !
`|
`
`|
`
`109
`
`| |
`
`|
`|
`!
`|
`|
`|
`|
`|
`|
`
`| |
`
`|
`
`PC
`INTERFACE
`
`122
`
`123
`
`RAM
`ROM
`EEPROM
`
`1/0
`
`118
`
`WIRELESS RF
`DATA INTERFACE
`
`
`TCP/IP ATM
`
`NETWORK
`INTERFACE
`
`
`TCP/IP ATM
`
`Fig.
`
`1
`
`PROVI-1011 - Page 2
`
`!
`
`|
`i
`|
`|
`
`| 144
`!
`|
`|
`|
`|
`| 120
`|
`|
`
`-
`
`PROVI-1011 - Page 2
`
`

`

`Patent Application Publication
`
`Oct. 3, 2002 Sheet 2 of 5
`
`US 2002/0143434 A1
`
`00z
`
`ch
`
`CGSZ
`
`
`
`PROVI-1011 - Page 3
`
`PROVI-1011 - Page 3
`
`

`

`304
`
`305
`
`306AfAA
`
`UNIQUE IDENTIFIER 308
`
`Patent Application Publication
`
`Oct. 3, 2002 Sheet 3 of 5
`
`US 2002/0143434 Al
`
`301
`
`302
`
`HEADER
`
`SOURCE/ORIGIN
`ADDRESS DATA
`
`DESTINATION
`ADDRESS DATA
`
`PACKET I.D.
`
`TEXT OF ORDER
`OR SCRIPT
`
`310
`
`300
`
`PROVI-1011 - Page 4
`
`PROVI-1011 - Page 4
`
`

`

`Patent Application Publication
`
`Oct. 3, 2002 Sheet 4 of 5
`
`US 2002/0143434 Al
`
`406
`
`
`ARRIVES AT E-PHARMACY A
`
`
`PHYSICIAN ———>tT
`
`
`GENERATES
`TRANSMIT
`Secure PID
`
`
`PRESCRIPTION
`
`
`
`
`ARRIVES AT E-PHARMACY B
`
`
`Tsecure PID ———>TRANSMIT Fsecure PID
`
`
`
`TRANSMIT
`
`ARRIVES AT PATIENT'S DDA
`Fsecure PID
`
`
`SHIP
`PRESCRIPTION
`
`
`
`
`
`
`
`ARRIVES AT
`AUTOMATED
`
`
`E-PHARMACYA APPROVE
`APPROVAL
`
`
`Tsecure PID
`
`
`
`
`
`
`REJECT
`
`ARRIVES AT E-PHARMACYB
`
`418
`
`416
`
`400
`
`PROVI-1011 - Page 5
`
`PROVI-1011 - Page 5
`
`

`

`Patent Application Publication
`
`Oct. 3, 2002 Sheet 5 of 5
`
`US 2002/0143434 A1
`
`| || | | |
`
`INITIAL
`QUANTITY
`
`302
`
`OBTAIN
`
` READ/CALCULATE
`REFILL
`
`
`
`DEPLETION
`YES
`IMMINENT
`
`
`
`
` CHECK
`
`HEURISTICS OF
`THE USER
`
`504
`
`|
`
`
`
`ADJUST/
`RECALCULATE
`
`STORED QUANTITY
`
`506
`
`MESSAGE
`
`PREPARE/
`XMIT DATA
`
`?
`
`REFILL
`
`512
`
`a
`
`500
`
`PROVI-1011 - Page 6
`
`PROVI-1011 - Page 6
`
`

`

`US 2002/0143434 Al
`
`Oct. 3, 2002
`
`METHOD AND APPARATUS FOR DELIVERING
`AND REFILLING PHARMACEUTICALS
`
`FIELD OF THE INVENTION
`
`[0001] This invention relates to medical devices. In par-
`ticular, this invention relates to medical devices that are used
`to dispense maintenance drugs.
`
`BACKGROUND OF THE INVENTION
`
`[0002] Many individuals suffer from chronic health prob-
`lems, the treatment of which requires regular medication
`deliveries. Treatment regimens for diseases such as diabetes,
`asthma, epilepsy, cancer and even allergies, require the
`regular delivery of precise amounts of medication for the
`patient’s survival. Treating chronic medical disorders often
`requires the administration of medication over a long period
`of time, and, according to a treatment regimen specified by
`a medical professional, such as a physician. Other medical
`professionals, such as psychiatrists and dentists, also pre-
`scribe medication that must be regularly taken over a
`relatively long time period.
`
`[0003] One problem that chronic-illness treatment creates
`is the need to regularly obtain additional medication. The
`need to replenish needed medicineis at best, an annoyance
`which can become a problem if, in addition to having to
`physically travel to more supplies, a doctor’s order or script
`must also be obtained and presented to a pharmaceutical
`supplier, such as a drug store or pharmacy. A method and
`apparatus that simplifies pharmaceutical procurement might
`improve the quality oflife and improvethe level of care, for
`those who suffer from chronic illnesses.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0004] FIG. 1 shows a simplified block diagram of an
`intelligent drug delivery appliance.
`
`[0005] FIG. 2 shows a simplified representation of a
`system for automatically obtaining pharmaceuticals from a
`supplier of such products.
`
`[0006] FIG. 3 shows an example of a secure data message
`used to order and validate pharmaceutical orders.
`
`[0007] FIG. 4 showsa simplified flow chart of an example
`procedure of how pharmaceuticals can be automatically
`ordered via a data network.
`
`[0008] FIG. 5 showsa simplified flow chart of the process
`by which a pharmaceuticalrefill is solicited automatically.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENT
`
`[0009] FIG. 1 shows a simplified block diagram of an
`intelligent drug delivery appliance 100 that includes a con-
`trolling processor 102 (e.g., a microcontroller, microproces-
`sor, digital signal processor (DSP), combinational/sequen-
`tial logic and equivalents thereof), operatively coupled to
`peripheral devices that include, but which are not limited to,
`a pharmaceutical control valve or dispensing gate 108 of a
`reservoir of a pharmaceutical 104 through an address/data/
`control bus 112. By way of example, the reservoir 104 might
`contain a supply of controlled or medicinal substances such
`as tablets, liquids, gases, intended to be administered to a
`patient according to a treatment regimen(i.e. a prescription)
`
`of a medical professional (i.e. a doctor, not shown). The
`reservoir 104 might also store dispensable supplies, such as
`syringes, reagent test strips (for blood glucose testing for
`example) antihistamine tablets and the like, also to be used
`according to some prescribed treatment regiment. For pur-
`poses of claim construction, any substance or consumable
`supply item that might be dispensedto, or used by,a patient
`is hereafter referred to as a “pharmaceutical.” Accordingly,
`a function of the drug delivery applianceis the dispensing of
`a pharmaceutical.
`
`[0010] One specific example of a pharmaceutical, which
`might be controllably dispensed, is an aerosol or atomized
`mist of liquid anti-histamine. By using ink-jet print head
`technologies, precise amounts of liquids (e.g., antihista-
`mines; insulin) can be controllably dispensed under software
`control. As the amount of medication is used, the amount
`remaining in a reservoir can be readily determined. Accord-
`ingly, the processor is capable of detecting an impending
`depletion of a pharmaceutical.
`
`Ina drug delivery appliance such as that shown in
`(0011]
`FIG. 1, a treatment regimen (a schedule or circumstance
`according to which a pharmaceutical is taken by, or admin-
`istered to a patient from the drug delivery appliance 100)is
`embodied as computer program instructions (and/or data)
`stored in a memory device 114 within the appliance. Data
`parameters that
`the program operates on, or under the
`control of, are also stored in a memory device 114. By
`executing the program instructions, the controller 102 can
`reliably administer pharmaceuticals according to a doctor’s
`treatment regimen.
`
`[0012] By way of example, the program stored in ROM/
`EEPROM memory 114 (or possibly stored within memory
`of the processor 102 itself) can effectuate the administration
`of the aforementioned antihistamine (an example of a “phar-
`maceutical”) from the reservoir 104 to a patient over a
`predetermined timeinterval (e.g., hourly, daily, weekly) or,
`for emergencies, upon patient demand, by opening a valve
`or gate or other dispensing mechanism 108 for a predeter-
`mined amount of time so that a certain amount of the
`pharmaceutical can be delivered (e.g. flow) from the reser-
`voir 104 to a patient through the valve, (or gate or dispensing
`mechanism) 108.
`
`In a preferred embodiment, sensors 109 for heart
`[0013]
`rate, blood pressure, blood sugar, temperature, electrocar-
`diogram, encephalograph signals and waveforms(as well as
`other patient parameters , are operatively coupled to the
`processor so as to provide real-time data signals indicative
`of a patient’s physical condition. In such an embodiment, the
`administration of therapeutic medicines from the reservoir
`104 by the processor 102 can then be modulated under
`software control in response to the information fed back by
`sensors 109 so as to provide optimal control of a patient’s
`health.
`
`[0014] A human/display interface 111 is operatively
`coupled to the processor 102 via the address/control and data
`bus 112. Real-time status information (on patient vital signs
`as well as pharmaceutical availability information or the
`detection of an operational failure of the drug dispensing
`appliance) can be displayed to an operator on the human/
`display interface 111, which could be embodied as a screen
`such as a CRT or LCD, which for simplicity are generically
`considered to be the human/display interface 111. Appliance
`
`PROVI-1011 - Page 7
`
`PROVI-1011 - Page 7
`
`

`

`US 2002/0143434 Al
`
`Oct. 3, 2002
`
`status information (battery status; time of day; diagnostic
`status) can also be displayed under software control by the
`processor 102.
`
`construction, the step of detecting an impending depletion
`should also be considered to include detecting an actual
`depletion.
`
`[0015] As part of the human/display interface, a keyboard
`or othertactile input device or speech recognition device can
`be used to input queries to the processor, such as a request
`to run diagnostic software or to display the amount of
`pharmaceutical that remains in the reservoir. A keyboard or
`other input device (e.g., push-button, softkey) can also be
`used to modify pharmaceutical dosing, providing for
`example, the capability of delivering an on-demand bolus of
`pharmaceutical, such as for allergy treatment.
`
`[0016] For the visually-impaired, a speech synthesizer can
`be employed to enunciate statistics and other information
`that would otherwise be displayed. Speech recognition can
`be used in place of tactile/switch input devices.
`
`Information, such as the volume of pharmaceutical
`[0017]
`remaining can be critically important so as to warn can be
`made available. For purposes of claim construction,all of
`the foregoing implementations of a human interface are
`considered to be equivalent “human interface devices.”
`
`[0018] When the pharmaceutical in the reservoir 104 is
`depleted, or nears depletion, patient care (and the patient’s
`health) might be jeopardized. In order to help insure that a
`pharmaceutical
`supply within the
`reservoir
`is never
`depleted, pharmaceutical
`refills
`can be
`automatically
`obtained from a pharmaceutical supplier using the methods
`and apparatus disclosed hereinafter. Once a determination is
`made that a pharmaceutical needs replenishment, obtaining
`a refill can be obtained automatically by using data com-
`munications exchanged between the drug delivery appliance
`100, a medical service provider (e.g., a physician) and a
`pharmaceutical supplier (i.e. a pharmacy) as described here-
`inafter. In other words, the intelligent drug delivery appli-
`ance can solicit a pharmaceutical refill by way of a data
`message sent to either a pharmaceutical supplier (e.g., a
`pharmacy)or to a medical service provider(i.e. a physician)
`requesting more supplies or an order for more supplies.
`
`[0019] FIG. 5 showsa simplified block diagram of steps
`of a method by which an intelligent drug delivery appliance
`can dispense pharmaceuticals and automatically obtain
`refills. In step 502,
`the processor 102 is apprised of the
`contents of a reservoir by a data value to the processor 102
`or perhaps by a physical measurement. Once the starting
`contents are known (or believed to be known) in step 504,
`a pharmaceutical
`is dispensed, according to a treatment
`regimen, the parameters of which are provided to the pro-
`cessor 102.
`
`the amount of
`is dispensed,
`[0020] As pharmaceutical
`pharmaceutical as determined in step 502 is decremented or
`otherwise adjusted in step 506. As pharmaceutical is used
`up, a decision must be made in step 508 whether the amount
`calculated to be remaining is so low as to warrant
`the
`solicitation of a refill in step 510 whereupon a data message
`can be prepared and transmitted in step 512 via a data
`network.
`
`[0021] For purposesofthis disclosure and claim construc-
`tion therefore, the process of detecting an impending deple-
`tion includes calculation as well as measurement. By virtue
`of the cooperation between the various components shown
`in FIG. 1 and described herein, for purposes of claim
`
`[0022] The determination of how much pharmaceutical
`remains in the reservoir 104 might be made in different
`ways. The amount of pharmaceutical in the reservoir 104
`might be identified to the control program running in the
`processor 102 when the reservoir 104 is filled. As the
`pharmaceuticalis dispensed, calculating the amount remain-
`ing in the reservoir by subtraction can yield an amountthat
`remains. By dividing the amount remaining by the amount
`to be dispensed per unit time, the time at which the reservoir
`will be depleted can be readily calculated. Other methods by
`which the pharmaceutical within the reservoir can be deter-
`mined would include, but not limited to: a measured weight
`of the reservoir (not shown); a depth measurement by way
`of an ultrasonic or mechanical transducer (not shown) or
`measured static pressure within the reservoir 104. The
`determination of pharmaceutical exhaustion is not germane
`to an understanding of the invention disclosed and claimed
`herein. Once a determination is made that more pharmaceu-
`tical is required, by using the method and apparatus dis-
`closed hereinafter, obtaining a refill can be automated from
`either the drug delivery appliance, a medical service pro-
`vider or a pharmaceutical provider.
`
`[0023] With respect to FIG. 2 there is shown a simplified
`block diagram of a distributed network 200 of computers
`(such as personal computers, work stations or networks
`thereof, all appropriately equipped with data network inter-
`face capability and Internet browsers) which include: the
`medical service providers’ computer 210; patient drug deliv-
`ery appliances 220 such as those shown in FIG. 1 (and
`identified in FIG. 1 by reference numeral 100); and phar-
`maceutical supplier computers 230, all of which are opera-
`tively linked together by a data network 240. As set forth
`below, computers of insurance providers, governmental
`agencies 252 or other third parties can also be part of the
`network 200 shown in FIG. 2, by which pharmaceutical
`supply transactions can be monitored in real time for data
`related to dispensing, payment, billing and reimbursement
`transactions. In the preferred embodiment, the data network
`240 that links the various computers depicted in FIG. 2
`includes the now-ubiquitous Internet but might also include
`local area networks, token rings or other networks by which
`files can be shared between computers.
`
`It is well known that within the United States and
`[0024]
`other countries, the sale and/or distribution of some phar-
`maceuticals is regulated or otherwise controlled by govern-
`mental agencies. Obtaining a refill for controlled-distribu-
`tion pharmaceutical item in such jurisdictions in the U.S.
`typically requires an order (also knownas a “script”) from
`a licensed medical professional, (e.g., a physician) to a
`pharmaceutical supplier (i.e. a pharmacy or pharmacist) to
`provide a particular pharmaceutical. Inasmuch as medical
`professionals in the U.S. are licensed by state agencies, it
`might be unlawful for a physician in one state to issue a
`script for a pharmaceutical, in another state. Doctors are
`therefore generally prevented from prescribing medicines
`outside the jurisdiction in which they are licensed. In an
`automated, on-line drug delivery system, insuring compli-
`ance with state laws regulating the practice of medicine can
`become problematic if for instance,
`the issuance of an
`electronic prescription by a physician is some how construed
`
`PROVI-1011 - Page 8
`
`PROVI-1011 - Page 8
`
`

`

`US 2002/0143434 Al
`
`Oct. 3, 2002
`
`to be written by the doctor outside the jurisdiction in which
`the physician is licensed. Similarly, the transmission of an
`order or prescription for a pharmaceutical, such as a con-
`trolled substance, by an unlicensed or otherwise unautho-
`rized person might subject the pharmaceutical provider to
`civil and/or criminal liability. By using a secure, electronic
`data messages to order pharmaceuticals “on-line” unlawful
`practices can be minimized. For example, by using a unique
`secure identifier as described hereinafter, a pharmaceutical
`provider can determine whether an electronic drug order,
`received via a data network, truly originated from an indi-
`vidual duly licensed to prescribe medication to the patient in
`the jurisdiction where the pharmaceutical supplieris located
`or doing business. Presumably, a secure identifier for a
`medical professional uniquely identifies the professional and
`is not readily compromised. Uponreceipt of a pharmaceu-
`tical order accompanied with a unique, secure identifier, a
`pharmaceutical provider can thereafter provide the item to
`the patient (by express delivery service, U.S. Postal Service,
`messenger or the like). In addition to sending pharmaceu-
`ticals, a medical service provider’s directions (i.e., instruc-
`tions) on how and whento take or use a particular pharma-
`ceutical can also be delivered thereby providing at least a
`modicum of assurance that the pharmaceutical will be used
`appropriately as well as providing some assurance that
`various state and federal laws controlling the practice of
`medicine or the distribution sale or of controlled substances,
`are not violated.
`
`[0025] For purposes of claim construction, the term “data
`message” as well as any other “data” that is sent, received,
`or exchanged by way of a data network, should not be
`construed to include facsimile transmissions by which
`images on a printed page are converted into electronic
`signals, which are in turn, converted into modulated audio
`signals for transmission through a telephone network As
`used herein, a “data message” is not considered to be a fax
`or a telephonecall but is instead a true data message which
`a digital computer can send and understand.
`[0026] With respect to FIG. 2, a medical service provider
`(e.g. a physician, not shown) can initiate the delivery of a
`pharmaceutical via the Internet (or other data network) by
`sending a predetermined data message from a personal
`computer 212 (or other data terminal) coupled to the Internet
`through an appropriate network interface 214, such as
`modem, Ethernet or local area network interface or other
`equipment by which the computer can send and/or receive
`data. In a preferred embodiment, an encrypted (and perhaps
`digitally-signed) data message is sent from the medical
`service provider’s computer 212 to one or more pharma-
`ceutical providers’ computers 230 via a data message(typi-
`cally including one or more multi-byte data packets) across
`the Internet 240. In encrypting and/ordigitally signing a data
`message, the message itself becomes secure and, for pur-
`poses of claim construction,is considered to be a secure data
`message. A “secure prescription data message”is considered
`to be a secure data message but for the express purpose of
`obtaining a pharmaceutical using a prescription or script.
`Uponreceipt of the secure data message by the pharmaceu-
`tical supplier, the pharmaceutical supplier can electto fill the
`order, or in an alternate embodiment, require a separate
`(second) affirmative approval (i.e, confirmation) message
`from the putative sender of the pharmaceutical order. For
`purposes of claim construction, an “approval” message can
`come from either a health care service provider (e.g. a
`
`physician, hospital) as well as a patient. Confirmatory
`approval messages to confirm a pharmaceutical order can
`provide assurance that an order for a pharmaceutical was
`issued by a duly licensed (authorized) practitioner.
`
`[0027] A pharmaceutical order approval message can take
`a variety of forms including a confirmatory data exchange
`between the pharmaceutical provider and the medical ser-
`vice provider such as the exchange of passwords, state
`license numbers or the like. Such a confirmatory message
`might also take the form of a phone call or facsimile
`message between the medical service provider and the
`pharmaceutical supplier to establish the true identity of the
`party ordering a pharmaceutical. Once an order is confirmed
`using a procedure such as one of the foregoing methods
`(which, for purposes of claim construction are considered to
`be processes by which a pharmaceutical order is “vali-
`dated”) the pharmaceutical order can be filled from the
`pharmaceutical supplier’s inventory with an increased assur-
`ance that the order is legitimate.
`
`[0028] FIG. 3 shows an exemplary data message 300 that
`might be used to order pharmaceuticals over a data network
`240, such as the Internet. Those skilled in the art will
`recognize that various message formats might be used to
`securely transmit sensitive data over an insecure network.
`The message 300 of FIG. 3 is comprised of several indi-
`vidual data items, in several data fields. A header block 301
`is encoded with a particular data value or binary digit (bit)
`pattern to identify to recipient computers(e.g. 212, 232, 242,
`252) that the following data items are a pharmaceutical data
`message 300. Like an Ethernet data packet, a source address
`302 uniquely identifies the computer from which the mes-
`sage originated. A destination address 304 uniquely identi-
`fies the computer to which the packet is to be sent. In
`instances where multiple packets 300 might be sent, a
`numerical packet identifier 305 might be required soas to be
`able to reconstruct a multi-packet message if the packets of
`a multi-packet message are not received in order.
`
`[0029] Text of an order or message 306, (e.g. dosage
`instructions) is followed by a unique data identifier 308 or
`secure prescription identifier,
`the purpose of which is to
`identify the originator of the message. Those skilled in the
`art of data transmission will recognize that sending a mes-
`sage across a data network such as the Internet can be
`accomplished in a variety of ways. Moreover, the security of
`such transmissions can be compromised. The depiction of
`FIG. 3 is only a hypothetical example of how such a
`message might be formatted. Accordingly, at
`least one
`prudent security measure is to encrypt the message 300 and
`to include somesort of digital signature, either before or
`after encryption, so as to help insure the safe delivery of the
`message to its intended recipient.
`
`[0030] An encrypted data message from a medical service
`provider to a pharmaceutical provider (such as that shownin
`FIG.3) will includeat least a lawfully valid prescription or
`order for a particular pharmaceutical (including dosage
`instructions).
`In at
`least one preferred embodiment,
`the
`encrypted data message will include a unique identifier for
`the medical service provider. By way of example, a unique
`identifier 308 for a medical service provider might include
`a multi-digit or multi-character code word (or words) issued
`by, or generated by and obtained from, a governmental
`agency, a professional organization or a pharmaceutical
`
`PROVI-1011 - Page 9
`
`PROVI-1011 - Page 9
`
`

`

`US 2002/0143434 Al
`
`Oct. 3, 2002
`
`provider. In order to maintain it’s value as an identifier, a
`code word identifying a medical service provideris prefer-
`ably known to only the medical service provider and the
`issuing entity.
`
`[0031] By including a uniqueidentifier with a pharmaceu-
`tical dispensing order, a pharmaceutical provider (i.e. a
`pharmacy or pharmacist) can have at least a modicum of
`assurance that an incomingelectronic order for a controlled
`pharmaceutical, actually originated with a lawfully-qualified
`medical service provider, e.g. a medical doctor. Before
`filling an order, a pharmaceutical provider can have some
`assurance that the prescribed medicationis at the instance of
`a legitimate health care provider, for a legitimate purpose.
`
`[0032] With reference to FIG. 2, data transfers across the
`Internet 240 and between a medical service provider, phar-
`maceutical providers and patients can take place in a number
`of ways. One method includes web-hosted communication.
`By way of example, a pharmaceutical provider might host a
`website through which orders for pharmaceuticals can be
`delivered using hyper text transfer protocol (HTTP) mes-
`sages. A computer (e.g. a server) that directly or indirectly
`“hosts” the web site (232 perhaps) can be programmed to
`accept or read data messages (ASCII strings as well as
`numeric data) sent to the “web site” by the medical service
`provider’s computer 212 (using a web browser). Another
`method by which pharmaceuticals might be ordered using
`data transfers between computer coupled to a data network
`is by way of “e-mail” messages comprised of data packages,
`such as the one shown in FIG.3.
`
`In addition to a health care provider sending a data
`[0033]
`message, automatically obtaining a pharmaceuticalrefill can
`also be realized by the patient’s intelligent drug delivery
`appliance sending an electronic pharmaceutical order mes-
`sage 300 to one or more pharmaceutical providers’ comput-
`ers or computer networks 232; 242 via the Internet or other
`data network 240 requesting a pharmaceutical refill (ie.
`analogousto a bidding process). As shown in FIG.2, secure
`electronic prescriptive orders (R,,) can be sent from a medi-
`cal service provider to the drug delivery appliance (220 in
`FIG.2), a pharmaceutical supplier 230 or other third-party
`computer 252, via the data network 240. In much the same
`way the pharmaceutical scripts are filled today, (ie. a
`physician provides a script to the patient, who then obtains
`the pharmaceutical himself) an electronic pharmaceutical
`order can originate from a physician or other health care
`service provider computer 212 and then be transmitted to the
`intelligent drug delivery appliance 220. From the drug
`delivery appliance 220, the electronic order can be sent to
`via the data network 240 virtually anywhere,
`including
`insurance providers 252 or pharmaceutical suppliers 232,
`242. In such a scenario, validation of an electronic order for
`a pharmaceutical might be made by the intelligent drug
`delivery appliance or by the pharmaceutical provider’s com-
`puters 232, 242, by querying the medical service provider’s
`computer 212 via the data network 240 to confirm or
`re-establish the validity of the putative order received via the
`patient (by requesting and receiving a security code).
`
`[0034] Like the scenario described above, the intelligent
`drug delivery appliance mightsolicit competitive bids from
`multiple vendors, or might send an explicit order as circum-
`stances warrant. In sending a request for a bid or quote (in
`the format shown in FIG. 3 for instance) to multiple
`
`pharmaceutical suppliers 232, 242, a patient and/or his
`doctor might be able to realize economic savings, or better
`or faster delivery service, preferential payment terms from
`one or more particular suppliers, or a combination of other
`inducements upon which a decision to conduct business with
`a particular pharmaceutical vendor can be made. Depending
`upon whether the message sent to a vendor from the medical
`service provider was an explicit order for a refill, or a request
`for a quotation or bid, upon receipt of the message 300, the
`pharmaceutical provider(s) can respond to the message
`originator by an appropriate responsive data message that
`the order/request message from the service provider was
`received, including as appropriate, a request for confirma-
`tion of the validity of the electronic pharmaceutical order.
`Terms or conditions responsive to a request for a quote,
`including price and/or delivery terms upon whichthe vendor
`might provide the pharmaceutical can be provided thereaf-
`ter.
`
`In addition to sending a response to the medical
`[0035]
`service provider, a pharmaceutical supplier’s computer,
`(232242) can send a responsive message to the patient’s
`drug delivery appliance (220) or the medical service pro-
`vider 212 via the network 240 soas to advise both parties of
`the order 300 andits fulfillment or denial. As set forth above,
`a responsive message might also require an affirmation from
`the putative message originator to validate the legitimacy of
`the order to the supplier. In addition, advisory messages and
`affirmation requests can also be sent to the intelligent drug
`delivery appliance 220.
`
`Instead of sending a request for a bid or quote to
`[0036]
`multiple pharmaceutical suppliers, a medical service pro-
`vider might instead send a directive order to a particular
`supplier for a pharmaceutical refill. Upon receipt of the
`directive message (and validation of the order by way of the
`unique identifier 308) the pharmaceutical provider(s) can
`respond to the message originator by an appropriate
`acknowledgement message followed by shipment of the
`supplies directly to the patient. In yet another alternate
`embodiment, the replenishing shipment can be madeto the
`health care service provider.
`
`[0037] Automatically obtaining a pharmaceutical refill can
`also be realized by the patient’s intelligent drug delivery
`appliance sending an encrypted data message 300 to a
`pharmaceutical providers’ computers or computer networks
`232; 242 via the Internet (or other data network) 240
`requesting a refill, A pharmaceutical order (R,) can be
`transmitted to a supplier from the intelligent drug delivery
`appliance 220 that actually originated from the medical
`service provider’s computer 212 and which was routed to
`the drug delivery appliance 220 via the data network 240. In
`such a scenario, validation of the order might be made by the
`intelligent drug delivery appliance or by the pharmaceutical
`provider’s computers 232, 242, which might also query the
`medical service provider’s computer 212 via the data net-
`work 240 to establish the validity of the putative order
`received via the patient. By sending electronic orders to
`multiple vendors, the intelligent drug delivery appliance can
`solicit competitive bids from multiple vendors, or might
`send an explicit order as circumstances warrant.
`
`to FIG. 1, data communications
`[0038] With respect
`between a data network 240 (shown in FIG. 2) and the
`intelligent drug delivery appliance is by way of appropriate
`
`PROVI-1011 - Page 10
`
`PROVI-1011 - Page 10
`
`

`

`US 2002/0143434 Al
`
`Oct. 3, 2002
`
`network interfaces between the drug delivery appliance 100
`and the data network 240. In FIG. 1, the processor 102
`communicates with an input/output port 118, via the
`address/data/control bus 112. The input/output port 118,
`which could be any bi-directional interface, in turn provides
`a communications interface between the processor (execut-
`ing the stored program that operates the device 100) and the
`“outside world”that is accessed viaat least one of a wireless
`
`data interface 120 (typically a two-wayradio data link) or a
`wireline network interface 123, such as an Ethernet (local
`area network) LAN card or other mechanism of exchanging
`messages to and from a data network 240 such as the
`Internet. At least one alternate embodimentof the intelligent
`drug delivery appliance provides generic serial and parallel
`interfaces 122 to a personal computer such that the PC (not
`shown) acts as a de facto network interface to the drug
`delivery appliance 100.
`
`In the provision of an on-line drug ordering and
`[0039]
`delivery system,at least one significant aspect of the inven-
`tion (at least in jurisdictions where the sale and distribution
`of certain pharmaceuticals is regulated) is order validation
`and automated approval of the order on the determination of
`the order validity. Automated approval and automated vali-
`dation is enabled through the use of a secure prescription
`identifier or