U.S. patent application number 13/095561 was filed with the patent office on 2011-08-18 for system and method for providing telepharmacy services.
Invention is credited to William Rex Akers, Jeff W. Canterbury, Jerry L. Graves, Kevin P. Hale, James R. King, Blake B. Miller, Robert J. Normyle, Jay Travis Patterson, Karen D. Rau, Craig Alan Walker, Brandon T. Watts.
Application Number | 20110202366 13/095561 |
Document ID | / |
Family ID | 25311573 |
Filed Date | 2011-08-18 |
United States Patent
Application |
20110202366 |
Kind Code |
A1 |
Akers; William Rex ; et
al. |
August 18, 2011 |
SYSTEM AND METHOD FOR PROVIDING TELEPHARMACY SERVICES
Abstract
A system for distributing packaged medical supplies is provided.
The system includes a record server configured to generate medical
supply data. The medical supply data includes identification of a
physical package containing physical medical supplies,
identification of the physical medical supplies, and identification
of a remote site the physical package is to be physically moved to.
The record server is configured to correlate the package data with
verification data received from a remote client. The verification
data includes identification of a physical package received by the
record client, identification of a patient prescription received by
the remote client, and identification of the site of the remote
client.
Inventors: |
Akers; William Rex;
(Colleyville, TX) ; Canterbury; Jeff W.; (Fort
Worth, TX) ; Miller; Blake B.; (Austin, TX) ;
Walker; Craig Alan; (Austin, TX) ; King; James
R.; (Waxahachie, TX) ; Graves; Jerry L.;
(Benbrook, TX) ; Patterson; Jay Travis;
(Arlington, TX) ; Normyle; Robert J.;
(Colleyville, TX) ; Hale; Kevin P.; (Fort Worth,
TX) ; Watts; Brandon T.; (Park City, UT) ;
Rau; Karen D.; (Farwell, MN) |
Family ID: |
25311573 |
Appl. No.: |
13/095561 |
Filed: |
April 27, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10369843 |
Feb 19, 2003 |
7956894 |
|
|
13095561 |
|
|
|
|
09851745 |
May 9, 2001 |
7885822 |
|
|
10369843 |
|
|
|
|
09170509 |
Oct 13, 1998 |
6597392 |
|
|
09851745 |
|
|
|
|
Current U.S.
Class: |
705/2 |
Current CPC
Class: |
G16H 40/67 20180101;
G16H 10/60 20180101; G16H 20/10 20180101 |
Class at
Publication: |
705/2 |
International
Class: |
G06Q 50/00 20060101
G06Q050/00; G06Q 10/00 20060101 G06Q010/00 |
Claims
1. A system for distributing packaged medical supplies comprising:
a record server comprising software systems operating on a
processing platform, the record server configured to: generate
medical supply package data, the medical supply package data
comprising: identification of at least one physical package
containing physical medical supplies; identification of the
physical medical supplies; and identification of a remote site the
physical package is to be physically moved to; and correlate the
package data with verification data received from a record client,
the verification data comprising: identification of at least one
physical package received by the record client; identification of a
patient prescription received by the record client; and
identification of the site of the record client.
2. The system of claim 1, further comprising an inventory tracking
system coupled to the record client and configured to update
inventory data, the inventory data comprising the size of an
inventory of the physical medical supplies stored at the remote
site.
3. The system of claim 1, wherein the record server further
comprises a record encapsulation system configured to receive the
verification data and encapsulate the verification data.
4. The system of claim 1, wherein the record client further
comprises a remote data system, the remote data system configured
to generate counseling data and transmit the counseling data to the
record server.
5. The system of claim 1, wherein the record client further
comprises a data reader configured to read verification data from a
package.
6. The system of claim 1, wherein the record client further
comprises an image data capture device configured to generate image
data, and wherein the verification data comprises the image
data.
7. The system of claim 1, wherein the physical medical supplies
comprise medicine.
8. A method for distributing packaged medical supplies comprising:
providing a record server comprising software systems operating on
a processing platform; storing, by the record server, package data
comprising: identification of at least one physical package
containing physical medical supplies; identification of the
physical medical supplies; and identification of a remote site the
physical package is to be physically moved to; transmitting the
physical package to a remote site; receiving, by the record server,
received package data from the remote site, the received package
data comprising: identification of at least one physical package
received by the remote site; identification of a patient
prescription received by the remote site; and identification of the
remote site; and authorizing, by the record server, release of the
physical package if: the stored package data identification of the
at least one physical package matches the received package data
identification of the at least one physical package; the stored
package data identification of the physical medical supplies
matches the received package data identification of the patient
prescription; and the stored package data remote site matches the
received package data identification of the remote site.
9. The method of claim 8, further comprising: generating patient
counseling data.
10. The method of claim 8, further comprising incrementing order
data after the package is released.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of, and claims the
benefit of the filing date of, co-pending U.S. patent application
Ser. No. 10/369,843 entitled APPARATUS AND METHOD FOR COMPUTERIZED
MULTI-MEDIA MEDICAL AND PHARMACEUTICAL DATA ORGANIZATION AND
TRANSMISSION, filed Feb. 19, 2003, which is a continuation-in-part
of U.S. patent application Ser. No. 09/851,745 entitled SYSTEM AND
METHOD FOR ELECTRONIC MEDICAL FILE MANAGEMENT, filed May 9, 2001,
now U.S. Pat. No. 7,885,822, and of U.S. patent application Ser.
No. 09/170,509 entitled APPARATUS AND METHOD FOR COMPUTERIZED
MULTI-MEDIA DATA ORGANIZATION AND TRANSMISSION, filed Oct. 13,
1998, now U.S. Pat. No. 6,597,392.
TECHNICAL FIELD
[0002] The present invention pertains to the field of medical
record management. More specifically, the invention relates to a
system and method for electronic medical record management that
allows for providing telepharmacy services.
BACKGROUND OF THE INVENTION
[0003] Electronic medical file systems, also known as telemedicine
systems, are known in the art. These telemedicine systems allow
medical practitioners to engage in diagnostic activities without
being in the same physical location as the patient. For example,
some telemedicine systems allow doctors to remotely view a patient
using video cameras, still pictures, or other suitable imaging
devices. Likewise, other telemedicine systems allow doctors to send
and receive diagnostic data, such as x-rays, sonograms, audio data,
audiovisual data, graphic data, text data, or other suitable
diagnostic data. These systems may be subject to one or more
standards organizations or regulatory bodies, such as Digital
Imaging and Communications in Medicine (DICOM), the National
Electrical Manufacturers Association (NEMA), the American Medical
Association (AMA), and other private, state, or federal regulatory
agencies and standards organizations.
[0004] Although these telemedicine systems exist and have been
implemented, there are significant problems that prevent them from
being widely used. One such problem is that medical records created
using the telemedicine systems and apparatuses cannot be
controlled. Thus, it is possible for medical files to be lost,
corrupted, modified, or otherwise changed. Such changes can result
in significant legal liability, and the ability to perform such
changes is an impediment to the widespread adoption of telemedicine
systems and methods.
[0005] Other serious problems with telemedicine systems are the
inability to verify whether a receiving physician is present,
whether the receiving system can receive the transmitted files,
whether the receiving system has received all prior files, and to
otherwise ensure continuity of the medical record. For example, it
is possible for doctors to be sent an x-ray or sonogram data, and
for that doctor to diagnose the x-ray or sonogram data with a
misunderstanding as to the identity, age, sex, or other physical
conditions of the patient. Thus, it is possible for doctors to
perform diagnostic services using mistaken assumptions, which can
also create legal liability.
[0006] These and other problems with existing telemedicine systems
have resulted in the delayed implementation of such telemedicine
systems. Likewise, these problems with telemedicine systems prevent
telemedicine from being fully developed to the point where the full
range of medical services, such as diagnostic, pharmaceutical, and
other similar services can be provided.
BRIEF SUMMARY OF THE INVENTION
[0007] In accordance with the present invention, a system and
method for electronic medical file management are provided that
overcome known problems with managing electronic medical files.
[0008] In accordance with an exemplary embodiment of the present
invention, a system for distributing packaged medical supplies is
provided. The system includes a record server configured to
generate medical supply data. The medical supply data includes
identification of a physical package containing physical medical
supplies, identification of the physical medical supplies, and
identification of a remote site the physical package is to be
physically moved to. The record server is configured to correlate
the package data with verification data received from a remote
client. The verification data includes identification of a physical
package received by the record client, identification of a patient
prescription received by the remote client, and identification of
the site of the remote client.
[0009] The foregoing has outlined rather broadly the features and
technical advantages of an exemplary embodiment of the present
invention in order that the detailed description of exemplary
embodiments of the invention that follows may be better understood.
Additional features and advantages of embodiments of the invention
will be described hereinafter.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
[0010] For a more complete understanding of the present invention,
and the advantages thereof, reference is now made to the following
description of exemplary embodiments taken in conjunction with the
accompanying drawings, in which:
[0011] FIG. 1 is an illustration of an exemplary
capture-and-storage device for providing health care access to
remote and rural patients with image-assisted diagnosis;
[0012] FIG. 2 is an illustration of an exemplary session
initialization window;
[0013] FIG. 3 is an illustration of an exemplary Graphical User
Interface ("GUI") for receiving input and for displaying data;
[0014] FIGS. 4A-4C are exemplary program structure diagrams
regarding the interconnection of the program modules through
connecting links;
[0015] FIG. 5 is a diagram of a system for providing telemedicine
services in accordance with an exemplary embodiment of the present
invention;
[0016] FIG. 6 is a diagram of a system for providing file
synchronization functionality in accordance with an exemplary
embodiment of the present invention;
[0017] FIG. 7 is a diagram of a system for providing medical record
data file tracking functionality in accordance with an exemplary
embodiment of the present invention;
[0018] FIG. 8 is a diagram of a system for providing remote data
input in accordance with the exemplary embodiment of the present
invention;
[0019] FIG. 9 is a diagram of a system for providing record client
functionality in accordance with an exemplary embodiment of the
present invention;
[0020] FIG. 10 is a flow chart of a method for providing file
synchronization and tracking in accordance with an exemplary
embodiment of the present invention;
[0021] FIG. 11 is a flow chart of a method for generating and
encapsulating diagnostic data in accordance with an exemplary
embodiment of the present invention;
[0022] FIG. 12 is a flow chart of a method for providing
telepharmacy services in accordance with an exemplary embodiment of
the present invention;
[0023] FIG. 13 is a flow chart of a method for workflow processing
in accordance with an exemplary embodiment of the present
invention;
[0024] FIG. 14 is a flow chart of a method for prescription fill or
verification processing in accordance with an exemplary embodiment
of the present invention;
[0025] FIG. 15 is a diagram of a system for workflow management in
accordance with an exemplary embodiment of the present invention;
and
[0026] FIG. 16 is a flowchart of a method for signature capture in
accordance with an exemplary embodiment of the present
invention.
DETAILED DESCRIPTION OF THE INVENTION
[0027] In the following description, numerous specific details are
set forth to provide a thorough understanding of the present
invention. It should be noted, however, that those skilled in the
art are capable of practicing the present invention without such
specific details. Referring to the drawings, depicted elements are
not necessarily shown to scale, and like or similar elements are
designated by the same reference numeral through the several
views.
[0028] Provided herein is a telemedicine solution, one exemplary
embodiment of which improves homecare and customer service while
reducing medical costs by allowing patients to remain at home. It
should be noted that although the present invention is described
with reference to use in the medical field, the present invention
has applications to fields where image-assisted analysis is.
desired without the need for traveling conventionally required by
on-site examination. For example, other conceivable applications
would be for mechanical analysis, for peer discussions, or for
telecommuting where input is sought from others over a remote
distance.
[0029] Referring to FIG. 1, the capture-and-storage device 100 of
an exemplary embodiment of the present invention utilizes existing
telephone lines to provide health care access to remote and rural
patients with image-assisted diagnosis. The ability to use
low-level communications lines such as POTS ("Plain Old Telephone
System") gives the health care diagnostician greater access to
patients. Such communications systems are presently used with
conventional MODEM devices that allow the computer to transmit
information over standard telephone lines. Nevertheless, as
communications technologies advance, such as the widespread
implementation of ISDN (Integrated Service Digital Network), other
telecommunications technologies can be implemented to allow the
transfer of multimedia data.
[0030] The capture-and-storage device 100 has a portable laptop
computer 102, a digital camera 104, and an executable software
program 106, which is installed on, and executed by, the laptop
computer 102 to provide image capture, transfer, and database
storage. An executable program is understood to be a computer
program that is ready to run. The term refers to a compiled program
that has been translated into machine code in a format that can be
loaded into memory and executed by the microprocessor; however, for
interpreted languages, the term can simply refer to source code in
the proper format.
[0031] The laptop computer 102 can include a 5.times.86
microprocessor operating at about 133 MHZ or other suitable
processors, a color display screen 18 sufficient to convey adequate
information to the user for analysis, and sufficient
random-access-memory (RAM) to accommodate the images.
[0032] The digital camera 104 has macro focus and low light
capabilities. A suitable digital camera is a model Pixera
Professional available from Pixera Corporation of Los Gatos, Calif.
It should be noted, however, that as technology advances, faster
computers with more powerful microprocessor and graphics capability
can be used. The software program 106 loaded into the program
memory is executed by the microprocessor of the laptop computer 102
to provide video and audio conferencing capabilities to enable a
diagnostician to survey a patient from a remote site. The term
"remote" as used herein means not in the immediate vicinity of the
computer system 102, the computer system being remotely accessible
by another device located in another place (being a room, building,
city, state, or country) that is accessible through some type of
cable or communications link.
[0033] The capture-and-storage device 100 captures high resolution
still-images that can also be transmitted to corresponding computer
devices connected across the telecommunications path, or
transferred using common file transfer techniques associated with
computer technology, as is known in the art. These images can be
annotated by both parties, and saved or discarded. When saved, the
software program 106 saves the images and related patient
information in a patient "episode-of-care" folder for patient
history and for retrieval purposes.
[0034] In another application--such as with rural health care,
homecare, long term care facilities, or the like--the
capture-and-storage device 100 can be used for data acquisition.
For example, a homecare nurse at a patient residence can connect to
a physician through a video conferencing session provided by the
software program 106. Both parties can have their cameras in use,
or just at the patient site. Once in the care session, the nurse or
the physician can capture a still image from the remote camera 104.
The captured-image can then be shared between the parties and be
mutually annotated by each party to discuss care for a particular
symptom. Each party has the capability to save an image or images
for their records and end the session.
[0035] The saved data images are stored in the device 100 database
and electronic file cabinet, along with information on the patient,
nurse, physician, service date, and capture date of each image. A
memo field is also available for both the nurse and the physician
to record additional information. The filed information is "hot
synchronized" to keep a united record for the health system.
Furthermore, additional scanned information pertinent to the
patient can be added to the database record at any time, such as
prescriptions image, X-ray images, pathology report images, or the
like. The term "image" as used herein, refers to a digital
representation of a document or other such information.
[0036] A description of the software program 106 follows regarding
the integrated software solution for capturing multi-media data for
organization and transmission with a database.
[0037] FIG. 2 shows an exemplary session initialization window 200
upon activation of the device and selection of the software program
106 for execution by the computer 102 (see FIG. 1). The activation
of the software program 106 can take place through conventional
invocation techniques such as pressing an icon indicating selection
of the program or through voice commands via the headset 122.
Activating the program 106 loads the database into program memory,
and prompts the user to make selections through the session
initialization window 200.
[0038] Three options are available through the Session
Initialization window 200: (I) work with the patient by pressing
icon 202; (2) Open_the_File Cabinet function (to look at patient
history, make notes, append documents, etc.) by pressing icon 204;
or (3) import or export records to or from another device 100 by
pressing either icon 206 or icon 208.
[0039] With pressing either the icon 202 or icon 204,
Work_with_the_Patient function (begin a new episode-of-care), or
the Open_the_File_Cabinet functions are selected. If so, then the
user selects a Performing Provider (the provider onsite with the
patient) for the field 210 from the pick list or adds them by
clicking on the "New" button 212, and then selecting a patient name
for the field 214 from the pick list or add a Patient by clicking
on the "New" button 216. Optionally, a Reviewing Provider (the
Provider that will be called) is selected in the field 218 from the
pick list or add a Reviewing Provider by clicking on the "New"
button 220. Also, as an option a location (the location where the
patient is being seen) is selected in the field 222 from the pick
list or adds a location by clicking on the "New" button 224.
[0040] With this information in place, and the mode selected
through the Open_File_Cabinet icon 204 or through the
Work_with_Patient icon 202, the "Open File Cabinet" option invokes
the data viewing aspects of the device 100 opening the
communications and capture functions, discussed later in detail.
The "Work with Patient" function invokes a new episode-of-care,
which opens both the data aspects of the device 100 by opening the
"electronic file cabinet" and the communications and data capture
software packages. The execution of the selected option takes place
by pressing the "Go" button 226.
[0041] Selecting the import icon 206 or the export icon 208 imports
or exports records to or from another device 100. The underlying
functions are known to those skilled in the art and are not
discussed in detail. The "Import" function is available if imported
files are stored on the device 100 and have not been imported.
Selecting the import icon 206 initiates importing files from a
sending device 100. Files received from the transmitting device are
merged with files on the receiving system 100. With the export icon
208 selected, the report files to be exported are copied to a
temporary Export directory for file transfer, and are then exported
from the device 100 according to a specified date range.
[0042] With respect to the "Open File Cabinet" mode and the "Work
with Patient" mode, the same information is available for review,
analysis, and commentary by the reviewing provider. The difference,
however, is that additional data acquisition and communications
capabilities are made available through the "Work with Patient"
mode.
[0043] Referring to FIG. 3, shown is a Graphical User Interface
("GUI") 300 displayed on the screen 18. The GUI 300 is provided by
the executable program 106 (see FIG. 1). The configuration shown in
FIG. 3 is representative of the appearance of the user interface
for the device 100 when in the "Open File Cabinet" mode or the
"Work with Patient" mode invoked through the Session Initialization
window 200 (see FIG. 2).
[0044] If the "Open File Cabinet" mode is chosen, the selected
patient history (prior episodes) is displayed in a records window
302. An imaging window 306 displays the image(s) associated with
the most recent episode-of-care (in this example, one image from a
session on 29 Sep. 1997). In this mode, the prior episodes can be
accessed and reviewed, or searches conducted on the database.
[0045] If the "Work with Patient" mode is chosen, a new
episode-of-care for the selected patient is started. The patient
and provider names are "written" into the database with the current
date (taken from the internal clock of the computer 102). The GUI
300 displays the records window 302, the episode information window
304, an imaging window 306, and a communications-and-image-capture
window 308. The records window 302 displays an overview on the data
for the current session, and the previous sessions for the patient,
if any. The episode information window 304 displays data for the
session that entered through the Session Initialization window 200
(see FIG. 2), and the data is updated as the provider session
progresses. The image window 306 is initially blank until an image
is captured through the controls of the image capture window
308.
[0046] A GUI is a type of display format that enables the user to
choose commands, start programs, and view lists of files and the
operation by pointing to pictorial representations (icons) and
lists of menu items on the screen. Choices can generally be
activated either with the keyboard 120 or with a mouse. Graphical
user interfaces are used on the Apple Macintosh and by such
programs as Microsoft Windows, and the OS/2 Presentation
Manager.
[0047] Additionally, choices may also be activated using a
voice-command software package and associated communications
headset 122 to provide voice-activation and voice transcription of
notes. Such a feature allows the provider to work with the patient
to capture, transmit, and store data images without having to
resort to manual keystrokes. A further advantage of voice-command
is the user-friendly feature available to users having limited
computer skills. A suitable voice-command module is available from
Verbex Voice Systems, of Edison, N.J.
[0048] In FIG. 3, the GUI 300 shows, in a side-by-side orientation,
a records window 302, an episode information window 304, an imaging
window 306, and a communications-and-image-capture window 308.
These windows are invoked through the selection of modes in the
session initialization window 200 (see FIG. 2) discussed above in
detail.
[0049] The term "window," as used in the applications and graphical
interface contexts, is understood to be a portion of the screen
that can contain its own document or message. In window-based
programs such as GUIs, the screen can be divided into several
windows, each of which has its own boundaries and can contain a
different document (or another view into the same document). It
should be noted that the windows of the GUI 200 can be placed in an
overlapped orientation.
[0050] The GUI 200 provides a data input/output path to a software
database, which in conjunction with the keyboard 120 and the
headset 122, and mouse if used, a user can provide multimedia
information that is readily accessed and updated through the GUI,
including graphical image data captured with the digital camera
104.
[0051] A software database is an aggregation of data, which is
arranged in a number of records or tables, each of which is
constructed of fields (or columns) of a particular type, together
with a collection of operations that facilitate searching, sorting,
recombination, and similar activities. A suitable database is
available under the mark ACCESS.TM. from Microsoft, Inc., of
Seattle, Wash.
[0052] The software database is the organizational aspect of the
device 100. Text and graphical data information, or program
indexes, are stored in the database for each session or
episode-of-care. The database has a series of tables that allow
organization and storage on a per-episode basis. In this manner, a
vast amount of useful information is conveyed to a user at one time
on which to base diagnosis and treatments, as well as the gathering
and storage of such information in a concise location. Up to this
time, such availability required consulting with numerous
physicians and specialists, as well as culling through numerous
files and charts to arrive at a suitable treatment. The software
database has the following tables:
TABLE-US-00001 No Table Description 1 Docs This table tracks
scanned documents and document folders. All data is entered by the
software application except for the optional page title, which is
entered by the user in the Episode window 204. 2 Episode This is
the Master Table, which keeps track of image folders, document
folders, notes, patients, providers and location information for
each visit. All data is entered by the software application. 3
Images Keeps track of saved images and their associated information
through the JView window 208. All information is entered by the
software application except for the optional image title, which is
entered by the user in the Episode window 204. 4 Location Contains
data storage location information. Data is accessed from the
Session Initialization, the records window 202, and the episode
information window 204. The dialog box fields are the Location_ID,
Type, Description, and Facility. 5 LocType A sub-table for the
Location Table that codifies location information. Values are
preloaded by manufacturer and are based on the ANSI ASC X12 data
dictionary. 6 Notes Contains notes, creator of note and time/date
information. Notes are entered by the user in the episode window
204. 7 Patient Contains the name, address, and demographic
information on patients. Data is entered by the user. This table is
accessed from the session initialization window, the records window
202, and the episode window 204. The Patient ID number is the
database record key, and is the data field used to tie the database
to other health care applications. 8 PatientIDTypes A sub-table for
the Patient table that contains qualifiers to indicate the type or
source of the patient ID number. Values are preloaded by the device
manufacturer, and are based on the ANSI ASC X12 data dictionary. 9
Pharmacy Sub-table of the Patient table. 10 Provider Contains name,
address, and demographic informarion on all health care providers.
Data is entered by the user. This is accessed from the session
initialization screen, the records window 202, and the episode
window 204. 11 ProviderCode A sub-table for the Provider table that
contains qualifiers to indicate the type of provider. Values are
preloaded by the device manufacturer, and are based on the ANSI ASC
X12 data dictionary. 12 ProviderIDType A sub-table for the Provider
table that contains qualifiers to indicate the type or source of
the provider ID number. Values are preloaded by the device
manufacturer, and are based on the ANSI ASC X12 data
dictionary.
[0053] Further details concerning the database structure are
provided in Appendix A, which is incorporated herein by
reference.
[0054] The records window 302 provides several fields for accepting
and displaying information. In general, the records window 302 is a
nexus of the capture-and-storage device 100 in that the functions
associated with the episode information window 304, the imaging
window 306, and the communications-and-image-capture window 308 are
generated by selections and actions taken in this window. In this
manner, a centralized record containing text, images, annotations
can be created that is complete within itself.
[0055] The records window 302 has a Type field 310, which shows
whether the session was an Episode (created by using
Work-with-Patient mode) or a Document folder. A document folder can
be attached to a patient file drawer without being associated with
a particular episode. The Date_Visited field 312 shows the date of
the session. Sessions are organized in the table from most recent
to the oldest. The "I" field 314 shows a numerical count of the
number of images in the Episode folder for that session. The "D"
field 316 shows a numerical count of the number of scanned document
pages in the associated document folder that is part of the Episode
for that session. The "N" field 318 shows a numerical count of the
number of associated notes for the episode. The Loc field 320 has a
two character descriptor of the type of facility where the session
was performed. This list. is shown in Appendix A in the LocType
table, IDUser column.
[0056] When selected, the File Menu 322 of the records window 302
provides several user options. The menus options are Scan, Print,
New_Episode.sub.----of_Care, or Search_for_Records.
[0057] When the Scan option is selected, the user can select "To
Patient File" to scan a document or image to a non-Episode folder
that is associated globally to the patient (not to a particular
Episode). On the other hand, the user can select "To This Episode"
to scan a document or image to a Doc folder having the same "x"
designator as the Episode and is associated with the current
Episode shown in the record window 302. The number of document
pages is then displayed in the "D" field 316 of the Episode shown
in the record window 302.
[0058] When the Print option is selected, the user can print a
total record or a data only record. If the user chooses to print
Data-and-Images, then each image and each document associated with
the selected Episode is printed. The database information sheet
that is Scan, Print, New-Episode-of-Care, or printed contains: (a)
Episode ID; (b) Episode Type; (c) Date/Time Visited; (d) Patient
ID; (e) Patient Name; (t) Performing Provider Name; (g) Reviewing
Provider Name; and (h) Notes, each with Provider Name and the
Date/Time of entry.
[0059] Each image in the Episode folder is printed on a separate
page with a header that displays "Captured Image x of x from
Episode x." Each page in the associated document folder is printed
on a separate page with a header the displays "Document x of x from
Episode x."
[0060] If the user selects the New_Episode.sub.----of_Care option,
then the user is returned to the session initialization window 200
to select new options or to exit the system.
[0061] If the user selects the Search_for_Records option, the user
is able to key in search terms that are searched for in the
database. If a narrower search is desired, search categories can be
used, such as providers and patients, a specific episode of care
between a specific beginning and end date, or based on a location
identifier or location description.
[0062] Still referring to FIG. 3, the View Menu 324 is selected to
allow a user to view additional information for a selected episode
shown in the record window 302. If the "Episode Information" option
is selected, the episode information window 304 is spawned. The
episode information window 304 is discussed later in detail.
[0063] Also, the "Patient Information," "Provider Information,"
"Location Information" or "Notes" options can be selected from the
View Menu 324. Upon selection, a display window is invoked to show
the detailed information associated with these tables.
[0064] The Tools Menu 326 of the records window 302 allows a user
to add new patients, providers or locations to the database. These
additions can also be done in the session initialization window
200.
[0065] As discussed above, when the "Episode Information" option is
selected from the View Menu 324, the episode information window
304. By highlighting a different Episode line with the window
cursor 328 in the listing of the records window 302, the
information displayed in the episode information window 304 and the
imaging window 306 will change accordingly to reflect data stored
with respect to that episode.
[0066] The episode information window 304 displays database
information, and accepts database information. This window is
titled "Current Episode" under the Work with Patient mode and is
automatically displayed when the application begins. This window is
titled "Episode Information" under the Open File Cabinet mode and
is opened by choosing the View Episode Information option in the
records window 304.
[0067] This window functions mainly on buttons and pull-down menus.
It has the following data fields: [0068] a. Patient Name--This
shows the name of the selected patient. Pressing the "Info" button
next to this field pops-up the Patient screen. The Patient
information can also be accessed from the records window 302.
[0069] b. Performing Provider--This shows the name of the
Performing Provider for the Episode. Pressing the "Info" button
next to this field pops-up the Provider screen. The Provider
information can also be accessed from the records window 302.
[0070] c. Reviewing Provider--This shows the name of the Reviewing
Provider (if one is active) for the Episode. Pressing the "Info"
button next to this field pops-up the Provider screen. The Provider
information can also be accessed from the records window 302.
[0071] d. Location--This shows the description of the Location (if
one is active) for the Episode. Pressing the "Info . . . " button
next to this field pops-up the Location screen. The Location
information can also be accessed from the records window 304.
[0072] e. Service Date--Displays the date and type of the Episode.
This is taken from the system clock of the computer 102. [0073] f.
Image of x--Displays the number of images for the Episode, with the
[0074] g. individual number and date/time stamp in the first box
and the total number of images for the Episode in the second box.
Using the down arrow-displays information on the other images in
the folder. Selecting an image by moving the arrow, changes the
information in this window and refocuses the image viewed in the
imaging module window. [0075] h. Description--The "Description" box
directly beneath the "Image" box displays the title of the
currently displayed image. Clicking the mouse in the box allows
input of data. This box displays the optional title of the
currently selected image. [0076] i. Document of x--Displays the
number of pages in the optional Document folder for the Episode,
with the individual number and date/time stamp in the first box and
the total number of documents for the Episode in the second box.
Using the down arrow displays information on the other documents in
the folder. Selecting a document by moving the arrow changes the
information in this window and refocuses the document viewed in the
imaging window 306. [0077] j. Description--The "Description" box
directly beneath the "Document" box displays the title of the
currently displayed document page. Clicking the mouse in the box
allows input of data. This box displays the optional title of the
currently selected document page. [0078] k. Notes--The last field
on the window shows how many notes are associated with the Episode.
Notes are accessed through the "Notes" button or the records window
302.
[0079] The image communications functions of the GUI 300 is carried
out through the "Export Image" key 330, which selects the current
image in the imaging window 306 and sends it to the
communications-and-image-capture window 308 for transfer to a
connected party. If in the event the
communications-and-image-capture window 308 is not active, the
window will open and the image will be displayed within.
[0080] The "Close" key 332 closes the episode information window
304. If the device 100 is in the "Work with Patient" mode, then the
program returns to the session initialization window 200 (see FIG.
2). Otherwise, if the program is in the "Open File Cabinet" mode,
the "Close" key 332 simply closes the episode information window
304.
[0081] FIGS. 4A through 4C are program structure diagrams regarding
the interconnection of the program modules through connecting
links. The software program 106 initially referred to with respect
to FIG. 1 is an integrated solution that has several program
function modules to provide multimedia information formats to a
user. The software program 106 has a communications module 402, an
imaging module 404, and a database 406, which is discussed in
detail above and with respect to Appendix A. Connecting links 408,
410, 412, 414, and 416 respectively interconnect the communications
module 402 and imaging module 404, respectively, for integration
with. the database 406. Such links between the program modules are
known to those skilled in the art.
[0082] The communications module 402 captures images, can establish
a phone connection to a similar device 10, can share images with a
similar device 10, and can save images for later recall. A suitable
communications module is available under the product name Audio
Vision from Smith Micro Software of Aliso Viejo, Calif.
[0083] The AudioVision product provides two-way video and audio
communications over the Internet, intranet, or standard POTS lines
using standard analog modem connections. The operation of such
products is known to those skilled in the art and accordingly, is
not discussed in further detail. The communications module is
activated when the "Work with Patient" option is selected, invoking
the communications-and-image-capture window 308 (see FIG. 3).
[0084] The communications module 402 has a JView plug-in function,
which is a high resolution image capture, annotate, and store
program. The JView function program can capture a
640.times.480.times.24 bit true-color image through the digital
camera 104 (see FIG. 1), and is linked with connecting link 390,
illustrated in Appendix C, Diagram 3, that enables the JView module
to pass data to the imaging module 340.
[0085] When JView is selected, the high resolution viewer is
activated and overlays most of the screen as illustrated in
Appendix A, Screen Diagram 15. The communication module 320 can
operate with and without an established telecommunications
connection between the two parties. If there is a
telecommunications connection, then additional features are made
available.
[0086] Referring to FIG. 4A, the imaging module 404 is an
electronic filing cabinet with document and image filing and
scanning capabilities. A imaging module is available under the
product name View Wise from WhetStone Technologies of Park City,
Utah. The imaging module serves as links 408 between the records
window 302 and the episode window 304. The imaging module 404
displays the image/document folder selected in the record window
302, and the selected image or document of the episode information
window 304.
[0087] Referring to FIG. 4B, when an image is saved through the
JView function of the communications-and-image-capture window 308,
the link 410 is activated to pass the image and associated
information (size, compression ratio, date/time stamp) to the
database 406 for storage. The captured image is placed in the
episode folder of for the patient and is given a unique identifier
for retrieval and identification purposes. If multiple images are
saved for an episode, they are all written to the episode folder.
The software application 106 automatically gives each data image a
unique filename. When JView is exited, the user is prompted whether
to save any images that have not already been saved.
[0088] The record window 302 is updated to reflect the image was
captured in the "I" field 314 (see FIG. 3). The episode information
window 304 is similarly updated to display the active image. The
program 106 then returns to the communication module 402 to conduct
further image processing when called by the user.
[0089] During the saving of an image to a patient Episode of Care
folder, the images are transferred from the communications module
402 to the imaging module 404 (the electronic file cabinet).
[0090] As the saved images are imported into the file cabinet, they
are converted into a XIF format, with each image being a JPEG file.
The typical JPEG compression is set at 75, but the user has the
option to alter this. If altered on the communication module 402
image will be saved accordingly. The time/date stamp becomes a
permanent part of the image and cannot be removed. The file formats
were chosen to maintain the quality of the image and to reduce
storage requirements. A 640.times.480.times.24 bit image is 921,600
bytes while a typical compressed JPEG for storage is from about
30,000 to about 50,000 bytes.
[0091] Referring to FIG. 4C, shown is the program structure for
opening previously function of the communications module 402, link
414 allows the export of a stored image from the database 406 to
the communications module 402. When the retrieved image is in the
possession of the communications module 402, the image can be
transmitted to a connected reviewer. This is done with the
connecting link 395 on the Current Episode window that "exports"
the currently displayed image from the imaging window 306, invokes
the JView function, and displays the image in the
communications-and-image-capture window 308. The user then selects
"Transmit" to send the image to a reviewer. The image is opened
with the same attributes it had when it was saved. The time/date
stamp is displayed and the quality is set to the value it had when
originally saved.
[0092] The user can opt to review a previous episode before taking
new images. For example, this might be important if they want to
capture a wound from the same angle as it was taken during the last
patient visit. To select a previous episode, they can either
highlight the episode in "Date Visited" field 312 in the records
window 302 to a previous episode, or older sessions can be viewed
accordingly. Once a previous episode is selected, the imaging
window 306 displays the images in that folder, and the episode
information window 304 displays information about that episode (see
FIG. 3).
[0093] FIG. 5 is a diagram of a system 500 for providing
telemedicine services in accordance with an exemplary embodiment of
the present invention. System 500 allows physicians to ensure the
continuity and integrity of medical records so as to enable them to
use telemedicine to treat patients without incurring significant
risk of legal liability or other serious problems.
[0094] System 500 includes record server 502 which can be
implemented in hardware, software, or a suitable combination of
hardware and software, and which can be one or more software
systems operating on a general purpose server platform. As used
herein, a software system can include one or more objects, agents,
threads, line of code, subroutines, separate software applications,
two or more lines of code or other suitable software structures
operating in two or more separate software applications, on two or
more different processors, or other suitable software
architectures. In one exemplary embodiment, a software system can
include one or more lines of code or other suitable software
structures operating in a general purpose software application,
such as an operating system, and one or more lines of code or other
suitable software structures operating in a specific purpose
software application. In another exemplary embodiment, a software
system can include one or more lines of hypertext markup language
(*.HTML) or other suitable software operating in a general purpose
web browser system, so as to create a specific purpose system
receiving information input from a user.
[0095] Record server 502 is coupled to record clients 504a through
504b by communications medium 514. As used herein, the term
"couple", and its cognate terms such as "couples" and "coupled",
can include a physical connection (such as through a copper
conductor), a virtual connection (such as one or more randomly
assigned memory locations of a data memory device), a logical
connection (such as through one or more logical devices of a
semiconducting circuit), a wireless connection, other suitable
connections, or a suitable combination of such connections. In one
exemplary embodiment, systems and components are coupled to other
systems and components through intervening systems and components,
such as through an operating system of a general purpose processing
platform. Communications medium 514 can be a local area network, a
wide area network, the public switched telephone network, the
Internet, a frame relay, a wireless network, an optical network,
other suitable communications media, or a suitable combination of
such communications media.
[0096] Record server 502 transfers medical record data files to
record clients 504a through 504b. To ensure that medical records
sent to record clients 504a through 504b will not be inadvertently
misfiled or confused by practitioners with those other patients,
record server 502 includes sync system 508. Sync system 508
transmits a synchronization data file to record client 504a or 504b
prior to transmission of medical record data files. In one
exemplary embodiment, sync system 508 can transmit the entire
medical record data file for a patient to record client 504a or
504b, such that record client 504a or 504b stores the latest
version of the entire medical record data file regardless of
whether any version of that file exists on record client 504a or
504b. In another exemplary embodiment, sync system 508 can first
determine which medical record data file or files a record client
504a or 504b has for a patient, and can then transmit only files or
portions of files that have been changed, new files, or other
suitable files. In this manner, sync system 508 ensures that the
medical record data files stored on record client 504a and 504b are
the most recent medical files, and further that sufficient files
exist to particularly identify any patient, so as to prevent
inadvertent misdiagnosis, misplacement or misfiling of medical
record data files, or other problems.
[0097] Record server 502 also includes tracking system 510.
Tracking system 510 is used to track access to medical record data
files. In one exemplary embodiment, tracking system 510 includes an
algorithm that creates a unique tracking access code number based
upon the previous value of the tracking identification number, the
date of access, the location of access, and other suitable data,
such that the modification history for the medical data file can be
determined from the tracking access code number. Tracking system
510 further prevents predetermined portions of the medical record
data file from being modified. In another exemplary embodiment,
medical diagnostic data, physician comment data, and other suitable
data can be encapsulated such that any attempt to alter or modify
the data will be prevented or detected.
[0098] Tracking system 510 on record server 502 can coordinate with
tracking system 150 on record client 504a so that files that have
been transmitted to record client 504a are checked when record
client 504a returns the files to record server 502. In this matter,
any modifications or attempt to modify sealed medical record data
will be detected. Likewise, record server 502 and record client
504a can be configured to prevent access to medical records except
through record server 502 and record client 504a, such as by using
encryption and decoding systems. Record client 504b includes remote
data system 512. Remote data system 512 can be implemented in
hardware, software, or suitable combination of hardware and
software, and can be one or more software systems operating on a
general purpose processing platform. Remote data system 512
generates audio data, audiovisual data, graphical data, text data,
or other suitable data and transmits it to record server 502, so
that the data can be viewed by an operator at that location.
Likewise, record server 502 can forward the data to record client
504a or other suitable systems for remote viewing by others. Remote
data system 512 interacts with tracking system 510 and sync system
508, such that the remote data can be encapsulated as it is
generated, at predetermined times, stored with diagnostic data
received from a doctor, or otherwise combined. In one exemplary
embodiment, tracking system 510 can receive the graphical image
data or other data from remote data system 512, can provide that
data to record client 504a, and can also receive diagnostic data
from practitioners at record client 504a. The graphical image data
can be encapsulated separately from the diagnostic data received
from each doctor, and all three sets of data can then be
encapsulated to prevent subsequent modification. In this manner, a
clear record of the medical treatment, diagnostic data, and other
information can be kept. The graphical image data described herein,
such as in regards to the description of the systems and methods
shown in the FIGS., can be JPEG format data, Digital Imaging and
Communications in Medicine (DICOM), Tagged Image File Format (TIFF)
graphic image formats, or other suitable image data formats.
Likewise, the image data can be generated using View Wise, Image
Viewer, Microsoft compatible media and imaging annotation/editing
tools, or other suitable image data processing tools. In one
exemplary embodiment, a viewer can select image data, video
sequence data, x-ray-data, ultrasound data, or other suitable data
for examination, annotation, comparison, or other suitable
purposes.
[0099] Record clients 504a and 504b can be implemented in hardware,
software, or a suitable combination of hardware and software, and
can be one or more software systems operating on a general purpose
processing platform. In one exemplary embodiment, record clients
504a and 504b can operate on a server physically located at a
medical facility or remote treatment facility, can be application
services providers (ASP) providing services to terminals at
different medical facilities, or can be implemented in other
suitable manners.
[0100] In operation, system 500 facilitates the provision of
telemedicine services by ensuring medical record data file
integrity and continuity. Medical record data file integrity is
ensured by sealing diagnostic data, doctor comments, and other
suitable data to prevent subsequent modification of the data.
Medical record data file continuity is ensured by keeping a track
of all access to the medical record data file so that it can be
readily determined whether a medical record was accessed, when it
was accessed, who accessed it, and what was done to the medical
record data file. In this manner, system 500 allows a medical
record data file to be generated and maintained as a permanent part
of a patient's medical record, thus minimizing any legal liability
for loss of medical record data, intentional or inadvertent
modification or manipulation of medical record data, or other
similar problems typically encountered in the prior art.
[0101] FIG. 6 is a diagram of a system 600 for providing file
synchronization functionality in accordance with an exemplary
embodiment of the present invention. System 600 includes sync
system 108 and file detection system 602, file transfer system 604,
notification system 606, and excerpt transfer system 608, each of
which can be implemented in hardware, software, or a suitable
combination of hardware and software, and which can be one or more
software systems operating on a general purpose processing or
server platform.
[0102] File detection system 602 interfaces with a record client
504 or other suitable systems to determine whether a medical record
data file for a patient is present on such system. In one exemplary
embodiment, file detection system 602 can determine which of a
plurality of medical record data files exists, the version of such
medical record data files, and other suitable information such as
size and access date so as to determine whether modifications have
been made to the files, whether such modifications are authorized,
or other suitable information. File detection system 602 can then
transfer the latest version of files, new files, or other suitable
files to a record client 504 or other suitable systems. File
detection system 602 can also interface with a file storage system
operating on system 600 to update file access and status
records.
[0103] File transfer system 604 can transfer medical record data
files from sync system 508 to record client 504 or other suitable
systems, and can likewise transfer the files or receive the files
from such systems and store them on sync system 508 or system 600.
File transfer system 604 keeps track of where medical record data
files have been transmitted, the time of transmission, and the
contents of the medical record data files at the time of
transmission, such that it can be readily determined which
practitioners were given access to the medical record data file and
what was in the file when they were given access. File transfer
system 604 can also be used to determine what additional
information may have been added to a medical record data file after
it was transmitted to a practitioner and before it was returned to
system 600.
[0104] Notification system 606 generates notification data such
that practitioners at a record client 504 or other suitable systems
can be made aware of the presence of a file or a file excerpt. In
one exemplary embodiment, notification system 606 operates in
conjunction with excerpt transfer system 608 so as to notify a
practitioner that an excerpt is available for review and comment.
In this exemplary embodiment, notification system 606 can send a
pager message, email message, phone message, or other suitable
message to a doctor or other medical professional requesting that
doctor to view a file, such as by accessing a website, an FTP
server, or by receiving an email with a medical record excerpt
attachment, or by other suitable methods, and can also receive
confirmation from such medical professional when the medical record
excerpt has been reviewed and returned. Notification system 606 can
also notify a local physician of the availability of a medical
record data file and when such file was flagged for review by the
medical professional, and can status a file unreviewed if the
medical professional declines or otherwise indicates that review of
the record will not be performed.
[0105] Excerpt transfer system 608 allows a portion of a medical
record, such as encapsulated graphic image data, x-ray image data,
audio data, audiovisual data, graphic data, text data, ultrasound
data, or other suitable data, to be accessed by a predetermined
practitioner and for that practitioner to enter comments or other
suitable data. In one exemplary embodiment, excerpt transfer system
608 is used to receive diagnosis input from remotely-located
practitioners, such as review of x-ray data by a surgical expert,
internal organ expert, or other suitable experts. Excerpt transfer
system 608 can be used to prevent transfer of the entire medical
record when only a portion of the medical record needs to be
transferred. Excerpt transfer system can operate in conjunction
with notification system 606, file transfer system 604, and file
detection system 602 to ensure that minimal data transfer
requirements are performed in order to facilitate the receipt of
diagnostic data from remote practitioners.
[0106] In operation, system 600 allows medical record data files to
be synchronized prior to transmission, facilitates the complete
transfer of medical records, and tracks the status of such medical
records so as to determine whether modifications to records have
been performed without proper authorization. System 200 thus helps
to prevent inadvertent misplacement of medical records, and also
helps to prevent the need for transmitting entire medical record
data files when only excerpts of the medical record data files need
to be transmitted. System 200 can also be used to detect when
medical record data files have been improperly modified.
[0107] FIG. 7 is a diagram of a system 700 for providing medical
record data file tracking functionality in accordance with an
exemplary embodiment of the present invention. System 700 includes
tracking system 510 and record encapsulation system 702, detail
encapsulation system 704, inventory tracking system 706, record
access tracking system 708, record database system 710, record
notification system 712, workflow system 714, and signature capture
system 716, each of which can be implemented in hardware, software,
or a suitable combination of hardware and software, and which can
be one or more software systems operating on a general purpose
server platform.
[0108] Record encapsulation system 702 can encapsulate an entire
medical record data file for a patient so as to maintain the
integrity of the entire medical record data file. In one exemplary
embodiment, record encapsulation system 702 includes encryption
algorithms that generate a value based upon the exact data
structure of the entire medical record data file, such that any
modifications to the medical record data file can be detected.
Record encapsulation system 702 can also buffer the medical record
when it is accessed, such that if an attempt is made to modify the
medical record data file prior to closing it, then a suitable flag
can be generated and the previous version of the medical record can
be stored separately from the modified version. Record
encapsulation system 702 can thus be used to notify an operator of
record tampering without alerting the party that has tampered with
the record of the notification.
[0109] In one exemplary embodiment, sync system 508, excerpt
transfer system 608, tracking system 510, record encapsulation
system 702, and other suitable systems can be used as a
point-to-point live consultation system, such as to allow a
physician to consult with a patient at a remote site, two
physicians to consult where one of the physicians is with the
patient, two physicians to consult using medical record data, or
other suitable point-to-point consultation functionality.
[0110] Detail encapsulation system 704 receives diagnostic data,
comment data, or other suitable medical record data file data and
performs separate encapsulation of such data. In one exemplary
embodiment, detail encapsulation system 704 can encapsulate graphic
image data, x-ray data, sonogram data, or other suitable data so
that inadvertent modification of such data is not performed.
Likewise, detail encapsulation system 704 can buffer detail data
and detect whether any changes have been made, such as through a
suitable encryption algorithm. In this manner, detail encapsulation
system 704 can be used to store the original and modified detail
data so as to determine whether tampering with data has
occurred.
[0111] Inventory tracking system 706 can be used to keep track of
inventory at a remote location. In one exemplary embodiment,
inventory tracking system 706 can be implemented in conjunction
with remote data system 512, such as to track the number of
pharmaceutical batches that have been stored and are ready for
dispensing. Other suitable inventory tracking functionality can be
provided.
[0112] Record access tracking system 708 performs record access
tracking for parties accessing medical record data files through
record encapsulation system 702 or detail data through detail
encapsulation system 704. In one exemplary embodiment, record
access tracking system 708 performs predetermined operations on the
data field of the files, on preselected portions of such data
fields, or on other suitable software data structures, and can
generate record tracking data that indicates the status of part or
all of the medical record data file prior to processing it with
record access tracking system 708. This record tracking data can be
compared to previous record tracking data values such as by sync
system 508 or other suitable systems to determine whether
modification to part or all of a medical data record file has
occurred. In this manner, record access tracking system 708 helps
to maintain the integrity and continuity of medical record
data.
[0113] Record database system 710 stores local record data for
medical record data files. In one exemplary embodiment, record
database system 710 can coordinate with sync system 508 and
tracking system 510 or other suitable systems operating on a record
client 504 to determine whether to store a new file as a new
version of the medical record data file, replace an existing
medical record data file, flag data records as having been
improperly modified, or perform other suitable database
functions.
[0114] The record data stored by record database system 710 can be
organized as one or more files or tables, where each file or table
has one or more data fields. The data fields can include common
data fields, and the files or tables can be associated with each
other so as to form a database. The following exemplary files or
table structures can be used, and all the data fields provided can
be used, a subset of the data fields can be used, some or all of
the data fields can be supplemented with other suitable data
fields, or sets of other suitable data fields can be used.
Likewise, other file or table structures can be used that combine
the data fields provided herein in other suitable manners.
[0115] One exemplary file or table structure includes vital sign
data fields such as a vital sign reading identification number; an
episode identification number; systolic blood pressure data;
diastolic blood pressure data; pulse rate data; pulse oximetry
data; temperature data; bronchial capacity data; bronchial peak
flow volume data; spirometry test data; spirometry test type data;
blood glucose reading average; blood glucose reading count; height
in feet; height in inches; weight in pounds; electro-cardio gram
data; and time/date modified data.
[0116] Another exemplary file or table structure includes audioclip
data fields such as an audioclip identification number; an episode
identification number; audioclip name and location; audioclip type
designation; audioclip time/date created data; and an audioclip
instance number.
[0117] Another exemplary file or table structure includes
demographics data fields such as patient identification
alpha/numeric; provider identification alpha/numeric; demographic
survey scribe; patient age data; patient gender data; patient
religion data; patient ethnicity data; patient level of education
data; patient insurance coverage data; patient household income
data; number of household occupants; patient familiarity with
telemedicine data; time/date modified; and the number of years the
patient has smoked.
[0118] Another exemplary file or table structure includes document
identification data such as a document identification number;
episode identification number; document description data; document
creation date; and a document instance number.
[0119] Another exemplary file or table structure includes episode
data such as an episode identification number; episode type;
patient identification alpha/numeric; performing provider
alpha/numeric; reviewing provider alpha/numeric; episode creation
date; episode image Tag Image File Format (TIF) name and path;
episode document TIF name and path; episode creation location;
episode diagnosis created; episode cpt code assignment; episode
prescription created; new data flag for file transfer; raw audit
information; audit code generated from raw audit info; audit index
for file transfer; and an episode billing status.
[0120] Another exemplary file or table structure includes fetal
worksheet data such as a worksheet identification number; episode
identification number; worksheet instance number; examination type;
patient identification alpha/numeric; patient name (last, first,
m.i.); examination date; performing provider identification
alpha/numeric; performing provider name (last, first, m.i.);
patient's intake indication; patient's age; last menstrual period;
gestational age; times pregnant; times given birth; patient abort
history; single/multiple fetus; multiple designation type; fetal
heart activity; fetal extremities activity; fetal respiration
activity; fetal presentation grade; normal amniotic fluid data;
hydro amniotic fluid data; oligo amniotic fluid data; variable
amniotic fluid data; anterior placenta position; posterior placenta
position; fundal placenta position; placenta condition; placenta
grade; cranium identification data; spine identification data; post
fossa identification data; ventricles identification data; heart 4
chambers identification data; left VOT identification data; right
VOT identification data; fluid GI identification data; bladder
identification data; right kidney identification data; left kidney
identification data; male gender identification data; female gender
identification data; 3 vessel cord identification data; umbilicus
identification; extremities identification; face identification;
amniotic fluid volume grade; tone grade; reactivity grade; movement
grade; respiration grade; sum of bio elements; sum of bio grades;
bi-parietal diameter; bi-parietal age; bi-parietal percentile;
bi-parietal associated image number; head circumference
measurement; head circumference age; head circumference percentile;
head circumference associated image number; abdominal circumference
measure; abdominal circumference age; abdominal circumference
percentile; abdominal circumference associated image number; long
femur bone measurement; long femur bone age; long femur bone
percentile; long femur bone associated image number; crown/rump
length measurement; crown/rump length age; crown/rump length
percentile; crown/rump length associated image number; fetal sac
measurement; fetal sac age; fetal sac percentile; fetal sac image
number; average age; total cardial diameter; total cardial age;
total cardial percentile; total cardial image number; humerus
length measurement; humerus length age; humerus length percentile;
humerus length associated image number; effective fetal weight;
estimated date of delivery; fetus systolic blood pressure; and
fetus diastolic blood pressure data.
[0121] Another exemplary file or table structure includes
glucometer reading data such as a reading identification number;
episode identification number; patient identification
alpha/numeric; blood glucose measurement; and a measurement time
and date.
[0122] Another exemplary file or table structure includes image
data such as an image identification number; episode identification
number; image description; image creation time/date; image instance
number; image quality setting; subjective notes; objective notes;
assessment notes; and plan notes.
[0123] Another exemplary file or table structure includes location
data such as a location identification number; location
description; userid; and facility data.
[0124] Another exemplary file or table structure includes location
type data such as a location type identification number; location
type description; and a userid.
[0125] Another exemplary file or table structure includes note data
such as a note identification number; episode identification
number; provider identification alpha/numeric; note creation
time/date; and note text.
[0126] Another exemplary file or table structure includes patient
data such as a patient identification alpha/numeric; patient
identification type; prefix; firstname; middlename; lastname;
suffix; date of birth; address; city; state; postal code; home
phone; work phone; patient pharmacy identifier; patient insurance
information; patient diagnosis history; patient prescription
history; patient profile modification history; disease state
management note history; weight; height feet; height inches;
systolic blood pressure minimum; systolic blood pressure maximum;
diastolic blood pressure minimum; diastolic blood pressure maximum;
heart rate minimum; heart rate maximum; pulse oximetry minimum;
pulse oximetry maximum; temperature minimum; temperature maximum;
blood glucose minimum; blood glucose maximum; bronchial capacity
minimum; bronchial capacity maximum; peak flow minimum; and peak
flow maximum.
[0127] Another exemplary file or table structure includes patient
identification type data such as a patient type identification
number; patient type name; and a patient type mask.
[0128] Another exemplary file or table structure includes pharmacy
data such as a pharmacy identification number; pharmacy name; phone
number; and a fax number.
[0129] Another exemplary file or table structure includes provider
data including a provider identification alpha/numeric; provider
identification type; provider activity code; firstname; middlename;
lastname; suffix; organization name; address; city; state; postal
code; work number; modem number; fax number; password; prefix; hcv
privileges; ip address/machine name; provider profile modification
history; and a global patient access flag.
[0130] Another exemplary file or table structure includes provider
code data such as a provider activity code and code
description.
[0131] Another exemplary file or table structure includes provider
identification type data such as an identification number;
identification name; and identification mask.
[0132] Another exemplary file or table structure includes site data
such as a federal identifier; company name; address; city; state;
zip code; primary user identifier; voice number; and fax
number.
[0133] Another exemplary file or table structure includes
spirometry data such as a spirometry identification number; episode
identification number; patient identification alpha/numeric; test
time/date; test type; test sequence number; test date; mouth piece
number; physician name; forced vital capacity (FVC); forced
expiratory volume (FEV) 0.5 second; forced expiratory volume 1st
second; forced expiratory volume 3rd second; percentage ratio of
FEV (timed) to FVC; peak expiratory flow rate; forced expiratory
flow @ 25%; forced expiratory flow @ 50%; forced expiratory flow @
75%; forced expiratory flow @ middle of test; forced inspiratory
vital capacity; forced inspiratory vital capacity @ 0.5 second;
forced inspiratory vital capacity @ 1 second; forced inspiratory
vital capacity (FIV) @ 3 second; peak inspiratory flow (FIF) rate;
FIF @ 50%; FIF @ 75%; FIF between 200 ml and 1200 ml. 1000 ml
measure; percentage ratio of expiratory time to volume; maximum
voluntary ventilation; maximum total ventilation; respiratory rate;
slow vital capacity; body temperature and pressure, saturated; and
room temperature during test.
[0134] Another exemplary file or table structure includes videoclip
data such as identification data; episode identifier; a drive or
server path where the clip is located; the type of clip; time stamp
data; and page number data.
[0135] Another exemplary file or table structure includes activity
log data such as an identifier; the action that is being logged;
user; filename; time of activity; and send/receive status data.
[0136] Another exemplary file or table structure includes data for
interfacing with the Epi Info.TM.. system available from the U.S.
Department of Health and Human Services Center for Disease Control.
The data fields in the Epi Info.TM.. can be changed by third
parties over time, and allow the tracking of data for epidemiologic
and statistical purposes, including but not limited to the tracking
of head circumference data, body-mass index data, and other
suitable data. In one exemplary embodiment, Epi Info.TM.. or other
suitable systems can be used to calculate and graphically depict
historical trends and values of biometrics (as well as to compare
biometrics to other individuals, groups, the national averages, or
other suitable data). Biometrics can include but are not limited to
blood pressure, temperature, heart rate, pulse oximetry,
spirometry, weight, height, glucometry, fetal profile data and
measurements, gestational age, heart and cardio rhythm data, and
other suitable measurement data. Such calculations can use input
patient data and readings and can be compared to national and
professional standards, averages, clinical standards, or other
suitable data sets. In addition, historical patient-specific or
episode-related data can be input for graphical representations,
such as for documenting disease outbreaks for a specific patient as
a function of time. Cross computational calculations and other
calculations depicting ratios can also or alternatively be
employed.
[0137] Record notification system 712 generates notification data
to notify a party that a record has been received and that the
record should be reviewed. In one exemplary embodiment, a medical
record data file or an excerpt is transmitted with the name of a
practitioner, an email address, a pager number, or other suitable
data. Record notification system 712 logs the received files or
excerpts and notifies the practitioner in one or more predetermined
manners, such that diagnostic treatment can be performed without
requiring the participation of all involved parties. In this
manner, record notification system 712 facilitates the processing
of telemedicine diagnostic data, such as by allowing doctors to
diagnose such data when they have available time, and does not
require practitioners to be present when the diagnostic data is
being acquired. Record notification system 712 can thus be used in
a local mode to also facilitate the coordination of medical advice
after diagnostic data has been acquired.
[0138] Workflow system 714 manages workflow data, such as workflow
data for prepping a tote at a pharmacy that contains one or more
prescriptions, workflow data for filling prescriptions, workflow
data for verifying that a prescription has been properly filled, or
other suitable workflow data. In one exemplary embodiment, workflow
data can track the number of errors that a given employee makes,
can track the time that an employee requires to complete workflow
steps, or can otherwise provide management data for determining an
employee's optimal skills, for tracking employees with substandard
skills, and for otherwise managing pharmacy workflow. Likewise,
workflow system 714 allows the status of unfilled prescriptions to
be readily determined, allows the amount of time for a prescription
to be filled to be determined, and provides other suitable
functions.
[0139] Signature capture system 716 allows signature data to be
obtained and stored in a database in lieu of paper logs, and
further allows patients who have refused to sign, have not signed,
or who need to sign again to be readily determined and tracked. In
one exemplary embodiment, signature capture system 716 can be
implemented in conjunction with a palm pilot or other suitable palm
top or portable processor, such as to allow patients at a pharmacy
drive-through window or other suitable locations to execute a
privacy policy acceptance, refill reminder acceptance, third party
data release acceptance, or to otherwise allow sensitive personal
information to be used for reasons other than treatment, payment,
or health care operations. Likewise, a signature verifying the
receipt of the prescription by the patient or a third party, the
receipt of counseling, or other suitable data can also be obtained.
Signature capture system 716 can also generate reports showing
patients that have refused to sign, patients with signatures that
have expired, patients that signed an approval for an older version
of a privacy policy, patients that have authorized the release of
their information to third parties, patients having pending or
past-due refills and who have provided authorization to be
reminded, or other suitable reports.
[0140] In operation, system 700 allows medical record data files to
be tracked and access to such medical record data files or medical
record data contained within such medical record data files to be
tracked, coordinated and controlled so as to prevent unauthorized
modification of data, to maintain the integrity of the data file,
and to ensure continuity of the medical record data file. System
700 thus allows telemedicine services and other suitable services
requiring access to a medical record data file to be provided
without incurring the risks posed by prior art systems.
[0141] FIG. 8 is a diagram of a system 800 for providing remote
data input in accordance with the exemplary embodiment of the
present invention. System 800 includes remote data system 512 and
counseling display system 802, data input system 804, and local
inventory tracking system 806, each of which can be implemented in
hardware, software, or a suitable combination of hardware and
software, and which can be one or more software systems operating
on a general purpose processing platform.
[0142] Counseling display system 802 can generate graphic image
data, text data, comment data, or other suitable data and can
transmit that data to a record server 502 or other suitable systems
for processing. Counseling display system 802 thus allows remote
access to audio data, audiovisual data, graphic data, text data,
x-ray data, sonogram data, or other suitable data. In one exemplary
embodiment, counseling display system 802 can be used to allow a
pharmacist or other medical professional to provide counseling to
patients located at a record client 504b, such that the pharmacist,
physician or other suitable medical practitioner does not have to
be physically present in order to provide counseling of the
patient. Counseling display system 802 can also interface with
detail encapsulation system 704, record encapsulation system 702,
or other suitable systems of record server 502 to allow the data to
be stored and encapsulated to prevent modification or loss of the
data. In this manner, both the data provided to the doctor to
facilitate diagnosis and counseling and the data received from the
doctor in response to the provided data can be stored either on
remote data system 512, at a record server 502, at both locations,
or in other suitable locations.
[0143] Data input system 804 allows data to be input to assist with
counseling provided through counseling display system 802 or for
other suitable purposes. In one exemplary embodiment, data input
system 804 includes a still image camera, sonogram data generating
equipment, x-ray scanning equipment, or other suitable data input
systems that can provide data from a remote location to a physician
at a record server 502, at another record client 504, or other
suitable systems. In another exemplary embodiment, data input
system 804 can receive data such as a bar code or other identifying
data on a package of pharmaceutical supplies, and this information
or data can be used to identify both the type of drug stored within
the package, and also the identity of the patient for whom the
pharmaceutical materials are being provided. It may then be
determined by data input system 804, remote data system 512, record
server 502, or other suitable systems whether the patient has
received the pharmaceutical materials before or otherwise requires
counseling. Data input system 804 can then coordinate with
counseling display system 402 to allow a practitioner to provide
counseling to the patient or otherwise ensure that all necessary
procedures for providing the pharmaceutical supplies to the patient
have been followed.
[0144] Local inventory tracking system 806 can keep track of the
number of packages of pharmaceuticals or other suitable packages or
materials that have been dispensed by a record client 504, remote
data system 512 or other suitable systems. Local inventory tracking
system 806 can coordinate with an inventory tracking system 706 of
a record server 502, another record client 504, or other suitable
systems so as to ensure that the amount of pharmaceutical materials
provided to a remote location is controlled. In one exemplary
embodiment, remote data system 512 is implemented on a record
client 504b located in a remote pharmaceutical dispensing facility
that does not have a licensed pharmacist on site. Remote data
system 512, record client 504 and record server 502 can then be
used to counsel a patient at the remote facility if the patient has
not received the drugs before, and to store such counseling so as
to generate a record showing that the patient received sufficient
counseling as may be required by law or good medical practice. In
this manner, system 800 facilitates telepharmacy services, by
generating record data that can be used to respond to regulatory
authorities if they ever question whether regulatory policies have
been followed, such as a requirement for the counseling of a
patient when they receive a prescription drug for the first
time.
[0145] In operation, system 800 allows data to be gathered from
remote locations where there is no licensed practitioner, and then
allows the licensed practitioner to access that data and to provide
comments, diagnostic information or other suitable information.
System 800 can thus be used to assist with telepharmacy services,
with remote telemedicine counseling, or other suitable
processes.
[0146] FIG. 9 is a diagram of a system 900 for providing record
client functionality in accordance with an exemplary embodiment of
the present invention. System 900 includes record client 504 and
diagnostic record system 902, comment request system 904, comment
system 906, and remote comment system 908, each of which can be
implemented in hardware, software, or a suitable combination of
hardware and software, and which can be one or more software
systems operating on a general purpose server platform.
[0147] Diagnostic record system 902 generates diagnostic record
data for inclusion in a medical record data file. In one exemplary
embodiment, diagnostic record system 902 can include (but is not
limited to) a handheld still image generating camera, a handheld
video image generating camera, eye/ear/nose and throat imaging
equipment, arterialscopic or other invasive imaging equipment,
x-ray imaging equipment, ultrasound equipment, an intracavity
transducer, an abdominal transducer, a vital signs monitor, a
glucometer, an electrocardiograph, a larynagoscope, a spirometer,
an opthalmoscope, a dermascope, sonographic imaging equipment,
audio monitoring equipment such as for listening to heartbeats or
other sounds, or other suitable diagnostic equipment. Diagnostic
record system 902 generates the diagnostic record data, and can
encapsulate some or all of the data, such as segments of the data
that are relied on by a surgeon or practitioner to render advice,
or other suitable data.
[0148] Comment request system 904 can be used to request comments
on some or all of a medical record data file. In one exemplary
embodiment, comment request system 904 can interact with a remote
comment system 908 operating on another record client 504, systems
operating on a record server 502 or other suitable systems to
request comment data from one or more remotely located
practitioners. Comment request system 904 can then track whether
such comments have been received, and can coordinate with comment
system 906 to store the comments and encapsulate them for inclusion
in the medical record data file.
[0149] Comment system 906 receives comments, such as from a local
practitioner or from a remote practitioner, and associates those
comments with diagnostic record data or other suitable data.
Comment system 906 can also encapsulate the comments at the
completion of the diagnostic session for inclusion in the medical
record data file.
[0150] Remote comment system 908 coordinates with other systems to
receive comments or requests for comments. In one exemplary
embodiment, a remote comment system 908 can receive a request for
comment and can notify a local physician of the request for
comment, such as by email, pager message, file transfer protocol
(FTP), or other suitable procedures. In this manner, remote comment
system 908 can operate in an "unattended" mode, such that FTP
protocol or other suitable protocols for the transfer of large
files can be initiated without requiring an operator to be present
at the receiving end to initiate the transfer. Remote comment
system 908 can then receive the comments from the local physician,
can generate displays of graphical diagnostic record data or other
suitable data, can support real time video conferencing, or can
perform other suitable functionality. Remote comment system 908 can
also coordinate with remote comment system 906 to store such
diagnostic data locally, such as by storing record affiliation
data, so that the local physician or practitioner can keep a record
of the advice rendered and the data on which that advice was
based.
[0151] In operation, system 900 allows practitioners to generate
diagnostic records, view existing diagnostic records, view existing
comments, and store new comments. System 900 further allows
practitioners to coordinate with other practitioners to receive
comment data on records, select portions of the record for access
by or transmission to such remote practitioners, or perform other
suitable functions. In this manner, system 900 facilitates the
provision of telemedicine services by ensuring record integrity and
continuity.
[0152] FIG. 10 is a flow chart of a method 1000 for providing file
synchronization and tracking in accordance with an exemplary
embodiment of the present invention. Method 1000 begins at 1002
where a remote diagnosis is initiated. In one exemplary embodiment,
the remote diagnosis can be initiated when the physician logs on,
requests initiation of the remote diagnosis, receives the request
for initiation of the remote diagnosis, or otherwise indicates that
they will participate in a remote diagnosis. For example, remote
diagnosis may start when a physician determines that another
physician should receive the medical record data file and provide
diagnostic data/comments. The method then proceeds to 1004 where it
is determined whether the medical record data file is present at
the remote site. If it is determined that the medical record data
file is not present, the method proceeds to 1006 where the file is
transferred. The method then proceeds to 1010. Otherwise, if it
determined that the medical record data file is present, the method
proceeds to 1008 where any portions of the medical record data file
that are not present can be transferred, updated with the most
recent data, or other suitable procedures can be used. Likewise,
1008 can be bypassed when portions of the medical record data file
are not used. The method then proceeds to 1010.
[0153] At 1010, record notification data is generated. For example,
a list identifying all of the medical record data files that have
been received can be generated that alerts the practitioner to the
receipt of the records in the order in which they were received, in
order of priority, in order or urgency, or in other suitable
orders. Likewise, an email, pager message, or other suitable record
notification message can also or alternatively be generated. The
method then proceeds to 1012.
[0154] At 1012, it is determined whether the record has been
reviewed. For example, the record notification procedure can be
implemented a predetermined number of times, after which time the
medical record data file will receive a status of not having been
reviewed or of having review declined. If it is determined that the
record has not been reviewed at 1012, then the method proceeds to
1014 where the medical record data file status is assigned. In one
exemplary embodiment, review may be declined when a physician has
received a medical record improperly, is not familiar with the
patient, is no longer treating the patient, or in other suitable
circumstances. If it is determined at 1012 that the record has been
reviewed, the method proceeds to 1016.
[0155] At 1016, record tracking data is updated. For example, when
the medical record data file is opened, an algorithm can be used to
modify tracking data that identifies the most recent access to the
record, the time and date, the location, the name of the physician
accessing the record, the size of the file, the structure of the
file, or other suitable data. The method then proceeds to 1018
where the diagnostic record data is presented to the practitioner
for review and comment.
[0156] In operation, method 1000 provides for synchronization and
tracking of medical record data files to ensure the integrity and
continuity of the file. Method 1000 can be used to prevent the
inadvertent misclassification or misidentification of medical
record data files. Method 1000 further provides for tracking of all
access to medical record data files, to maintain an audit trail
capability so that all practitioners who had access to the record
and their comments made at that time can be determined. Likewise,
it can also be determined whether a physician was requested to
access a record and declined to do so.
[0157] FIG. 11 is a flow chart of a method 1100 for generating and
encapsulating diagnostic data in accordance with an exemplary
embodiment of the present invention. Method 1100 begins at 1102
where diagnostic data is generated. In one exemplary embodiment,
the diagnostic data can be generated by creating photographic image
data, x-ray data, ultrasound data, specialized graphic image data,
or other suitable data. The method then proceeds to 1104.
[0158] At 1104, the diagnostic data is encapsulated. In one
exemplary embodiment, the diagnostic data can be encapsulated by
including it in a format that is proprietary such that any attempt
to access the data with a nonproprietary image viewer or other data
viewer will result in the corruption of the data or damage to the
data. Likewise, the data can be encapsulated in a manner that
causes the data to be buffered and where any modifications are
stored along with the prior unmodified image or data, so that
notification data can be generated and the attempt to tamper with
the record can be detected. The method then proceeds to 1106.
[0159] At 1106, it is determined whether comment data is being
provided with the encapsulated diagnostic data. If it is determined
at 1106 that comment data is not being received, the method
proceeds to 1110. Otherwise, the method proceeds to 1108 where the
comment data is received. The method then proceeds to 1110.
[0160] At 1110, it is determined whether remote comment data is
requested or is being provided. If it is determined that no remote
comment data is being requested or provided, the method proceeds to
1116. Otherwise, the method proceeds to 1112 where excerpts or real
time data transfer is provided. In one exemplary embodiment, the
diagnostic data that has been encapsulated is provided to the
remote location in real time, such as by providing a live video
feed as the data is being encapsulated. Likewise, the data can be
stored as a file and transmitted for later viewing by a remotely
located practitioner. Likewise, the comment data received at 1108
can be transmitted, and can be encapsulated prior to transmission.
The method then proceeds to 1116.
[0161] At 1116, the remote comment data is received. The remote
comment data can be received in real time with the comment data
received at 1108, can be received in a time-shifted manner, such
that the remote comment data is encapsulated, or other suitable
procedures can be used. The method then proceeds to 1116.
[0162] At 1116, the comment data is encapsulated. If the comment
data has previously been encapsulated, such as at 1108, then the
combined set of comment data from the various sources can be
encapsulated at 1116 to form a comment data record. The method then
proceeds to 1118 where a record copy of the medical record data
file is stored. For example, each time the medical record data file
is transmitted between a server and a record client, the medical
record data file can be stored such that a sequence of
modifications to the medical record data file can be determined and
verified. Likewise, the latest version of the medical record data
file can be stored at the record client, and the record server can
be used to store all historical versions of the file or other
suitable procedures can be used. The method then proceeds to
1120.
[0163] At 1120, the medical record data file is transmitted to a
medical record server for storage and maintenance. Likewise, the
server can perform any continuity or integrity checks, such as to
determine whether attempts have been made to tamper with the
medical record data file, whether parties have had access to the
file after the file was provided to the practitioner, or other
suitable procedures can be performed.
[0164] In operation, method 1100 allows diagnostic data to be
generated and encapsulated and further allows comment data from one
or more practitioners to be associated with the diagnostic data.
All diagnostic data and comment data can then be encapsulated to
provide a consistent and traceable medical record.
[0165] FIG. 12 is a flow chart of a method 1200 for providing
telepharmacy services in accordance with an exemplary embodiment of
the present invention. Method 1200 begins at 1202 where a
prescription is packaged. In one exemplary embodiment, the
prescription can include sealed packaging having a predetermined
number of doses of medicine. The prescription can further be
packaged in response to a notice that is generated based upon the
number of remaining pre-packaged prescriptions at a remote
location, or in response to other suitable data. The method then
proceeds to 1204.
[0166] At 1204, the package data is stored. Package data can
include a package identifier, the number of doses of medicine in
the package, the strength, the brand, the location which will
receive the package, patient data, and other suitable data. The
method then proceeds to 1206.
[0167] At 1206, the package is transferred to a remote site. The
remote site can be a facility that does not have a licensed
practitioner onsite but which has personnel that have been trained
to operate telepharmacy equipment or other suitable equipment. The
method then proceeds to 1208.
[0168] At 1208, the package data is read at the remote site. In one
exemplary embodiment, a patient can request to have a prescription
filled, and the package can be removed from a secured storage area
at that time and read by a package data reader. Patient data can
also be received at that time, such as identification data,
prescription data, insurance data, or other suitable data. The
method then proceeds to 1210 where the data read from the package
is transmitted to a central site. The method then proceeds to
1212.
[0169] At 1212, it is determined whether the record has been
verified. For example, the client prescription data and the package
data must match, the package data must indicate that the proper
package has been received, that the package is at the proper site,
and other suitable verification. If the record is verified, the
method proceeds to 1216. Otherwise, the method proceeds to 1214
where an exception report is generated. For example, the exception
report may include direct notification to the remote site that an
error has been committed and a request for correction, record
verification data can be generated that indicates that an improper
activity may be occurring at the remote site with a flag for follow
up that does not notify personnel at the remote site, the proper
authorities can be notified, or other suitable procedures can be
implemented. The method then proceeds to 1216.
[0170] At 1216, it is determined whether the patient has received
this prescription before. If the patient is receiving the
prescription for the first time, the method proceeds to 1218 where
remote counseling data is stored. The remote counseling data can
include audiovisual data generated at a central site and at a
remote site, where the patient is given advice on how and when to
take the medicine and any questions that the patient has may be
answered. The remote counseling data is stored in a manner that
allows the data to be readily audited by legal authorities in order
to verify that any legal requirements for dispensing
pharmaceuticals are being followed. The method then proceeds to
1220 where inventory count data is updated. The inventory count
data can be used to track the number of remaining packages of
pharmaceuticals at the remote location, the expiration dates of the
packages, the rate of use of the packages, and other suitable data
so that additional packages can be prepared and shipped as
needed.
[0171] FIG. 13 is a flow chart of a method 1300 for workflow
processing in accordance with an exemplary embodiment of the
present invention. Method 1300 allows pharmacy workflow to be
managed so as to ensure that quality is being maintained while
allowing efficiency to be increased.
[0172] Method 1300 begins at 1302, where an operator logs in and
data storage is performed. In one exemplary embodiment, operator
log-in can include scanning an ID badge, entering a user identifier
and a corresponding password, or other suitable processes that can
be used to track the operator who is performing the workflow
functions. The data stored at 1302 can include a tote identifier
that is used to identify a group of prescriptions, operator
identification data, start time data, and other suitable data. The
method then proceeds to 1304.
[0173] At 1304, tote preparation instructions are displayed for
preparing the tote or other receptacle that is used to hold the
prescriptions. In one exemplary embodiment, the instructions can
include scanning the tote identifier (if not already done),
entering data into an electronic file from a written prescription,
printing a label of the entered prescription data, capturing an
image, and performing other processes that are used to prepare the
tote and the prescriptions therein for subsequent filling by
pharmacy personnel. The method then proceeds to 1306.
[0174] At 1306, a label for the prescription is printed. In one
exemplary embodiment, the label can include a label for the
prescription bottle, a label for an accompanying set of advisory
materials, or other suitable labels. The method then proceeds to
1308 where the tote and prescription data are received, such as to
enter the data requested at each step of the instructions. The
method then proceeds to 1310.
[0175] At 1310, it is determined whether it is necessary to capture
an image, such as an image of the handwritten prescription, an
image of a pharmaceutical (such as for verification purposes where
an image has not previously been provided), or other suitable
images. If it is determined that an image is not required, the
method proceeds to 1314 where the process data, identification data
for each of the prescriptions in the tote, the time of completion,
and other suitable data is stored. If an image is required, the
method proceeds to 1312, where one or more images are generated and
selected for storage. In one exemplary embodiment, the image can be
generated using a digital camera, such as by placing a handwritten
prescription in a predetermined location and then by generating one
or more sets of image data until a legible image of the handwritten
prescription is generated. In this manner, scanning of the
prescription is not required. The method then proceeds to 1314.
[0176] In operation, method 1300 allows totes or other receptacles
to be prepared that are used to hold one or more prescriptions
while the prescriptions are being filled by pharmacy personnel.
Method 1300 allows a series of instructions to be displayed and the
responses to each set of instructions to be stored, so as to allow
errors to be detected, the time for processing each prescription to
be monitored, and other useful functions to be performed.
[0177] FIG. 14 is a flow chart of a method 1400 for prescription
fill or verification processing in accordance with an exemplary
embodiment of the present invention. Method 1400 allows pharmacy
workflow to be managed so as to ensure that quality is being
maintained while allowing efficiency to be increased.
[0178] Method 1400 begins at 1402, where an operator logs in and
data storage is performed. In one exemplary embodiment, operator
log-in can include scanning an ID badge, entering a user identifier
and a corresponding password, or other suitable processes that can
be used to track the operator who is performing the workflow
functions. The data stored at 1402 can include a tote identifier
that is used to identify a group of prescriptions, operator
identification data, start time data, and other suitable data. The
method then proceeds to 1404.
[0179] At 1404, instructions for filling prescriptions or
performing verification are displayed, depending on the process
being performed. In one exemplary embodiment, the instructions can
include scanning the tote identifier (if not already done),
scanning a prescription label, interfacing with one or more robotic
systems that retrieve bottles of pharmaceuticals from predetermined
locations and transport them to personnel who are filling the
prescriptions, scanning a label on a bottle of pharmaceuticals, and
performing other processes that are used to prepare the
prescriptions or perform verification of prescriptions that have
already been prepared. The method then proceeds to 1406.
[0180] At 1406, the tote and prescription data are received, such
as by entering the data requested at each step of the instructions.
The method then proceeds to 1408, where the prescription data is
compared to the pharmaceutical data. In one exemplary embodiment,
the prescription data from the label can be compared to the data
from the bottle of pharmaceuticals, the prescriptions from the tote
prep stage can be compared to the prescriptions scanned at 1406,
the prescription data entered at the tote prep stage can be
compared to the handwritten prescription data, or other suitable
comparisons can be made. If it is determined that a discrepancy
exists between the prescription and pharmaceutical data at 1410,
the method proceeds to 1412 where an error message is generated,
such as a notification that the pharmaceutical data does not match
the prescription data. Otherwise, the method proceeds to 1414 where
the process data, time of completion, and other suitable data is
stored.
[0181] In operation, method 1400 allows one or more prescriptions
to be filled by pharmacy personnel, and allows the filled
prescriptions to be verified for correctness. Method 1400 allows a
series of instructions to be displayed and the responses to each
set of instructions to be stored, so as to allow errors to be
detected, the time for processing each prescription to be
monitored, and other useful functions to be performed.
[0182] FIG. 15 is a diagram of a system 1500 for workflow
management in accordance with an exemplary embodiment of the
present invention. System 1500 allows pharmacy workflows to be
tracked and managed to increase the reliability and efficiency of
pharmacy operations.
[0183] System 1500 includes workflow system 714 and process
sequence system 1502, image upload system 1504, error tracking
system 1506 and workflow management system 1508, each of which can
be implemented in hardware, software, or a suitable combination of
hardware and software, and which can be one or more software
systems operating on a general purpose processing platform. Process
sequence system 1502 provides process sequence data to an operator
and generates indication data when each process sequence step has
been completed. In one exemplary embodiment, process sequence
system 1502 includes one or more process lists, such as tote prep
processes, prescription fill processes, prescription verification
processes, and other suitable processes, and tracks when completion
of each process step has occurred so as to prevent a user from
changing the status of a process prior to performing all of the
process steps. In this exemplary embodiment, a tote prep process
can include the steps of scanning or entering a user ID; scanning
or entering a tote or receptacle number; entering prescription
data; printing a prescription label; scanning the prescription
label; capturing an image of a handwritten prescription using a
digital camera; and capturing an image of a pharmaceutical with a
digital camera if an image is not available. A prescription fill
process can include the steps of scanning or entering a user ID;
scanning or entering a tote or receptacle number; scanning the
prescription label; comparing the prescription label at the
prescription fill step to a prescription label at the tote prep
step; scanning a drug bottle identifier; comparing the prescription
data to the drug bottle data; displaying a stored image of the
pharmaceutical; and generating error notifications if an expected
match does not occur. A prescription verification process can
include the steps of scanning or entering a user ID; scanning or
entering a tote or receptacle number; scanning the prescription
label; comparing the prescription label to the handwritten
prescription; displaying a stored image of the pharmaceutical; and
generating error notifications if an expected match does not occur.
Process sequence system 1502 can also interface with other suitable
systems, such as robotic systems that retrieve bottles of
pharmaceuticals from predetermined storage areas and transport them
to personnel that are filling prescriptions. Other suitable
processes can likewise be performed.
[0184] Image upload system 1504 allows image data of a
pharmaceutical, a handwritten prescription, a printed label, or
other suitable image data to be generated. In one exemplary
embodiment, image upload system 1504 includes a camera that
provides flexible image data generation capability such that
different objects can be imaged. Image upload system 1504 further
allows a number of image data sets of an object to be made and
reviewed by an operator, so as to allow the operator to quickly
select clear image data, or to generate additional image data if
needed.
[0185] Error tracking system 1506 tracks errors committed by users
at tote prep, prescription fill, verification, or other suitable
stages. In one exemplary embodiment, error tracking system 1506 can
determine the number of times an operator attempted to use the
wrong pharmaceutical to fill a prescription, the number of times an
operator entered data from a handwritten prescription incorrectly,
the number of times that the prescriptions in a tote that the
operator previously handled were not present in the tote at the
next stage, or other errors that can result in incorrect
pharmaceuticals being provided to patients. In this manner,
pharmacy workers that commit a larger than acceptable number of
errors can be detected.
[0186] Workflow management system 1508 tracks pharmacy workload
data, such as the length of time a worker requires to perform tote
prep, prescription fill, prescription verification, the number of
operations performed by a worker, the number of prescriptions per
tote handled by the worker, or other suitable functions. Likewise,
workflow management system 1508 can display the status of prepared
totes that have not had prescriptions filled, the number of filled
prescriptions that have not been verified, or other suitable data
that can be used to determine whether prescriptions are taking
longer than an allotted time to prepare, when a prescription is
expected to be ready, or other data of interest.
[0187] In operation, system 1500 allows a pharmacy operation having
two or more personnel to be managed by tracking the length of time
each worker requires to perform predetermined tasks and the error
rates for workers. Likewise, pharmacy process data can be generated
for each worker, image data required to support and document
actions performed by operators of system 1500 can be generated, and
other suitable processes can be performed to improve pharmacy
management.
[0188] FIG. 16 is a flowchart of a method 1600 for signature
capture in accordance with an exemplary embodiment of the present
invention. Method 1600 allows patient signatures to be obtained
when necessary to support pharmacy operations.
[0189] Method 1600 begins at 1602 where signature log data is
retrieved, such as when a patient presents a prescription for
filling. The method then proceeds to 1604 where it is determined
whether all signatures have been obtained for the patient. For
example, a signature can be required for acceptance of a privacy
policy, for receipt of reminders of prescription refills, for
authorizing pick-up of prescriptions by third-parties, or for other
purposes where patient data may be disclosed or used for treatment,
payment, or health care operations. If all requested signature have
been obtained, the method proceeds to 1608. Otherwise, the method
proceeds to 1606 where it is determined whether a good faith effort
has been made to obtain the patient signatures. In one exemplary
embodiment, the number of times that a patient is approached and
requested to sign can be set by the pharmacy, for each patient, or
in other suitable manners so as to establish that a good faith
effort was made to obtain a signature. If the number of times a
signature was requested is equal to or greater than the number of
times for establishing a good faith effort, the method proceeds to
1612. Otherwise, the method proceeds to 1610 where the signature is
requested. In one exemplary embodiment, a palm pilot or other
handheld device can be used to requested the signature, such as
where the patient is at a pharmacy drive-through window. The method
then proceeds to 1612.
[0190] If it is determined that all requested signatures have been
obtained, the method proceeds to 1608 where it is determined
whether any of the signatures have expired. In one exemplary
embodiment, signatures for refill reminders or other signatures can
be renewed once a year, new privacy policy signatures may need to
be obtained if the privacy policy is revised, or other expired
signatures may need to be renewed. If no signatures have expired,
the method proceeds to 1612. Otherwise, the method proceeds to 1610
where the signature is requested.
[0191] At 1612, it is determined whether a new signature is
required, such as for a third party agreement. If no new signature
is required, the method proceeds to 1616, otherwise the method
proceeds to 1614 where a signature is requested. The method then
proceeds to 1616 where it is determined whether the signature was
refused. If the signature was not refused, the method proceeds to
1620 where the signature data is stored. If the signature was
refused, the method proceeds to 1618 where a reason code is
entered, and the method then proceeds to 1620 where the reason code
is stored.
[0192] In operation, method 1600 allows signature data to be
obtained where needed, so as to replace paper signature logs with
electronic databases. Method 1600 further provides reminders where
new signatures are required, such as where a signature has expired,
a privacy policy has been revised, or where otherwise suitable.
Method 1600 further allows the number of times for a good faith
attempt to obtain a signature to be set according to the patient,
pharmacy, or based on other suitable criteria.
[0193] Although the invention has been described with reference to
a specific embodiment, these descriptions are not meant to be
construed in a limiting sense. Various modifications of the
disclosed embodiments, as well as alternative embodiments of the
invention will become apparent to persons skilled in the art upon
reference to the description of the invention. It is therefore
contemplated that the claims will cover any such modifications or
embodiments that fall within the true scope and spirit of the
invention.
* * * * *