CA2227103A1 - Method and system for managing wellness plans for a medical care practice - Google Patents

Abstract

Wellness plan administration software provides a user interface to enable users to learn about and select a wellness plan. The software tracks wellness plan service items for patients and dynamically estimates discounts forservice items offered to patients during visits to a medical facility. When a patient's visit is complete, the software can generate an invoice automatically and analyze the product and service items provided during the visit to determine theappropriate discount. The software includes additional features for recording promotional activities associated with wellness plans and computing employee bonuses.

Description

3Rhujab567:i-48670 - I - Express Mail No. EM795148751US

METHOD AND SYSTEM FOR MANAGING WELLNESS
PLANS FOR A M3~DICAL CA~E PRACTICE

FIELD OF THE INVENTION
The invention relates to a computer-implemented method for m~n~ing and enrolling new clients in wellness plans.
BACKGROUND OF THE INV~NTION
With rising health care costs~ it is imperative that health care providers provide health services efficiently and cost effectively. At the same 10 time, the administrative demands of medical record keeping, billing and managing a medical practice have become more burdensome. In particular, health care providers must be thorough and l;:eep detailed records of medical e~ams to accurate:.y document observations and services that have been provided.
One health care product growing in popularity is a wellness plan.
15 The principal objective of a wellness plan is to keep a patient well. A wellness plan provides a way for a patient to pre-pay or pay on a schedule for medical services. Under a typical plan, the patient is entitled to preventative care services and discounts on other types of medical services. By establishing periodic visits at least once a year, wellness plans enable health problems to be identified and treated 20 early. It is generally understood that the cost of healthcare rises exponentially the longer a health problem is postponed. Thus, wellness plans can drastically reduce healthcare costs by encouraging office visits that help identify and resolve health problems early.
While wellness plans are an effective means for keeping patients 25 healthy, l:hey are difficult and costly to administer and promote. As such there is a need for .~ more effective approach to managing wellness plans.
SUMMAl~Y OF THE INV¢NTION
The invention is directed to a method and system for managing wellness plans for a medical care practice. ~Ihile specifically adapted to a 30 veterinary practice, the invention can be applied to other types of medical practices as well.

b ~6~ ;~8670 - 2 - E.~press ;~lail No. E~l~9~ 1~',8~51 US
The invention is implemented in software that provides an interactive user interface and maintains patient, client and employee records associated with wellnesc; plans. In this implementation, the software presents an interactive user interface that enables members of a provider team to help clients select from S among a variety of wellness plans. Each of the plans is represented in memory as a set of predetermined product and service items and plan discounts. Once the client has accepted a wellness plan, the software updates the patient's records to include a list of the service items covered by the selected plan.
The wellness plan software is integrated w-ith software used to 10 manage a patient visit to a medical facility. This software is used to tracl~ the service and product items provided to a patient. As items are provided to a patient, the item, are also recorded in memory. The software can generate cost estimates based on the service items provided to the patient during a visit, including an indicator of the cost savings due to the wellness plan. When the visit is complete, 15 the software generates an invoice and checks whether selected service items are wellness plan items. If they are covered under the patient's plan, the software applies the discounts under the plan to the selected service items.
The wellness plan softl,vare also tracks promotional activities of provider team members. When the software detects a program action associated 20 ~,vith pro:motion of a wellness plan, it records an event identifying the provider responsible for the event. These events are recorded and evaluated to compute bonuses for the providers.
Another aspect of the wellness plan software is that also performs a variety of billing and accounting related functions. A typical medical facility 25 equipped with the software has a computer network that executes software for managing patient visits and keeping patient records. This network is lini;ed with a central computer that automatically handles billing, coilection and account maintena.nce functions. When a new plan is established at the facility, a servcrcomputer communicates plan contract and billing information to the central 30 computer. From this information, the central comp~lter determines when bills arc IRhl'j~b j6'~- 18670 - 3 - E:~press /~lail No. E~1'9~ 14~'51 US

due and produces a payment file of debit and credit card transactions that it sends electronically to a bank for payment. The central computer notifies the respective medical facilities about the status of the accounts, including, for example, indicating when a patient's account is overdue.
Additional features and advantages of the invention will become more apparent from the following detailed description and accompanying drawings.

BRIEF DI~SCRIPTION OF THE DRAWINGS
Fig. 1 is a block diagram of a computer that serves as an operating environment for medical office management software.
Fig. 2 is a block diagram illustrating a computer networli for managing client and patient medical data in a veterinary hospital.
Fig. 3 is an example of a status screen used to check the status of a 15 patient i-n the hospital.
Fig. 4 is an example of a physical exam overviel,v display generated by an implementation of the invention.
Fig. 5 illustrates an example of an interactive physical exam display used to record information about a patient's overall condition.
Fig. 6 illustrates an example of a supplemental user interface screen that is tr:iggered in response to an abnormal observation to prompt the user foradditional input related to the abnormal observation.
Fig. 7 is an example of an interactive user interface screen used to prompt the user for graphical input of medical observations using a graphical 25 depiction of a patient's anatomy.
Fig. 8 is an example of a graphical display depicting the doctor's signature to prompt the doctor to verify medical observations entered into the system.

J~Ujab~6~-18670 - 4 - E.~press Mail No. E?~ 9~148~51US

Fig. 9 illustrates an example of an interactive user interface screen used to display diagnosis generated by the system and to guide the user in selecting a tentative diagnosis.
Fig. 10 is an example of the diagnostic protocol screen used to S manage a treatment protocol.
Fig. I l is an example of an interactive user interface screen used to display an estimate of the cost of services to be provided or already provided to a patient.
Fig. 12 is an example of an interactive user interface screen used to 10 manage the administration of a service item under a treatment protocol.
Fig. 13 is an example of an interactive user interface screen used to check a patient out of an exam room.
Fig. 14 is an example of an interactive user interface screen-used to checl; patients in and out of a medical of fice and to monitor the status of patients in 15 the office.
Fig. 15 is a screen diagram illustrating a menu list for invoking wellness plan software.
Fig. 16 is a screen diagram illustrating a dialog box used to record an event re!ating to the promotion of a wellness plan.
Fig. 17 is a screen diagram illustrating a Wellness Control Center window used to educate clients about wellness plans and to promote the plans.
Fig. 18 is a screen diagram showing an example of a window used to depict the service items provided under a variety of different wellness plan levels.
Fig. 19 is a screen diagram showing an example of a Wellness Plan 25 Designer window used to select a wellness plan.
Fig. 20 is a screen diagram showing an example of an Agreement Acceptance screen used to obtain ~illing information from the client and to confirm that the client wishes to order a plan.

JR~ 'jab ~6~ 670 - 5 - E~pr~ss ;~lail No. E~ 9~ 2~1 US

Fig. 21 is a screen diagram illustrating an e~;ample of a screen used to select specific Wellness plan items and apply them to service items provided during a current patient visit.
Fig. 22 is a screen diagram illustrating an e~cample of a screen display 5 used to show preventative care appointments scheduled for a patient.
Fig. 23 is a screen diagram illustrating an e~;ample of a window used to update the status of a wellness plan.

DETAILED DESCRIPTlON
1 0 Introdu~ction The invention is directed toward a method and system for managing wellness plans for a medical care practice. The specific implementation described below is a software system that manages wellness plans for a ~eterinary practice.
Under a wellness plan, a client pays a fee in exchange for discounts on product and 15 service items provided by a medical care provider. The wellness plan software has a user inlerface that provides information about wellness plans and enables a user to enter information necessary to set-up a plan. The wellness plan soRware then administrates the plan by handling billing and contract renewal, calculating cost estimate~ during office visits and applying plan discounts to products and services 20 provided to the client.
The wellness plan software is integrated with medical management software that manages a variety of aspects of a veterinary practice, including controlling client and patient work flow in a hospital, guiding hospital personnel through rnedical examinations and storing medical records. The medical 25 management software provides an effective forum for implementing wellness plans because it allows the client to see the cost savings achieved under a plan as products and services are being offered during a visit. It also facilitates promotion ofthe plan and tracking of wellness plan marl;eting by hospital employees.
~ecause of the relationship between the wellness plan and the 30 medical practice management software, the following sections describes both of b j6l:~8670 - - 6 - E.Ypress ~ail No Ei~9~ 14S~5 1 US

these co:mponents in detail. The following section begins with a description of the computer system used to execute the soRware. Later sections then describe an implementation of the soRware for managing a medical practice. The final sections describe an implementation of the wellness plan software.
5 System ~rchitecture One implementation of the system is developed for a network computing environment in a veterinary hospital. This system comprises a series of program modules running in a Windows NT operating system environment. The program modules are implemented in the FoxPro programming environment. In a 10 typical configuration, the program modules of the system are organized in a client server architecture. Several computers throughout the hospital are equipped withclient so:ttware, which can access server software on a server via the network. The client so:ftware typically provides a graphical user interface comprising a number of screer s in a windowing environment for prompting the user for input and 15 displaying output.
In one particular client server implementatioll~ the server e~;ecutes database management soRware and maintains a series of relational databases (tables). The client and server soRware is developed usin;, the Fo:;Pro development tools. The client-server soRware is ~Titten in Fo~;Pro for Windo-vs,20 and uses the native Fo~;Pro database file structures.
The server soRware coordinates communication among the client computers, manages a database of client and patient data, monitors data suppliedvia the client computers, performs data processing functions on the data as observations are made, and dynamically updates the display data displayed on the25 client cornputer. While the preferTed implementation for a hospital setting is a networl; e nvironment, many of the soRware functions, including the user interface and data :management functions can be performed on a single computer.
Figure I and the following discussion are intended to provide a brief, general description of a suitable computing environment for the server and client 30 computers. As noted above, the system software is implemented in 2 series of JR~Vj~b'6'~ 8670 - 7 - E:~press ~rlail No EM~9514~1US

progran. modules, comprising computer executable instructions e~cecuted either on a server or client computer. Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The medical system software of the S invention may be ported to other computer system conf1gurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the lil~e.
The invention is typically practiced in distributed computing environrllents where tasks are performed by remote processing devices that are 10 linked through a communications net~vorl~. In a distributed computing environrnent, program modules may be located in both local memory of a client computer and remote memory such as in the server computer.
Figure I illustrates an example of a computer system that seirves as an operatin, environment for the invention. The computer system includes a personal15 computer 120, including a processing unit 121, a .system memory 127, and a system bus 123 that interconnects various system components including the systemmemory to the processing unit I 2 I . The system bus may comprise any of severaltypes of bus structures including a memor,v bus or memory controller, a peripheral bus, and a local bus using a bus architecture such as PCI, VESA, Microchannel 20 (MCA), [SA and 3~:ISA, to name a few. The system memory includes read only memory (ROM) 124 and random access memory (RAM) ]25. A basic input/output system 126 (BIOS), containing the basic routines that help to transfer information between elements within the personal computer 120, such as during start-up, is stored in ROM 124. The personal computer 120 further includes a hard 25 disk drive 127, a magnetic disl; drive 128, e.g., to read from or write to a removable disl; 129, and an optical disl; drive 130, e.g., for reading a CD-ROM
disk 131 or to read from or write to other optical media. The hard dis~; drive 127, magnetic disk drive 128, and optical disl; dri~e 130 are connected to the systembus 1~3 by a hard dis!~ drive interface 13~, a magnetic disl; drive interface 133, and 30 an optical drive interface 134, respectively. Thc drives and their associated JR~l'j;lb56-~8670 - 8 - E~press Mail No. E~ 9~14',~'51US

computer-readable media provide nonvolatile storage of data, data structures, computc~r-executable instructions (program code such as dynamic link libraries, and executable files), etc. for the personal computer 120. Although the description of computer-readable media above refers to a hard disk, a removable magnetic disk 5 and a CD, it can also include other types of media that are readable by a computer, such as magnetic cassettes, flash memory cards, digital video disks,33ernoulli cartridges, and the like.
A number of program modules may be stored in the drives and RAM
125, including an operating system 135, one or more application programs 136, 10 other program modules 137, and program data 13~. A user may enter commands and information into the personal computer 120 throu~7h a keyboard 140 and pointing device, such as a mouse 142. Other input devices (not shown) may include a microphone, joysticl;, game pad, satellite dish, scanner, or the like.These and other input devices are often connected to the processing unit 121 15 through a serial port interface 146 that is coupled to the system bus, but may be connccted by other interfaces, SUC}I as a parallel port, game port or a universal serial bus (USB). A monitor 147 or other type of display device is also connected to the system bus 1 3 via an interface, such as a video adapter 14~. In addition to the monitor, personal cornputers typically include other peripheral output devices 20 (not sho-vn), such as speakers and printers.
The software system ofthe invention is typically implemented in a network configuration in a veterinary hospital, though it can be implemented on a single PC. In network installations, there are several personal computers like the one depicted in Fig. l . Each of the personal computers (such as PC 120) operate in 25 a networked environment using logical connections to one or more remote computers, such as a remote computer 149. The remote computer 149 is usually a server, but can also be a router, a peer device or other common network node. The remote computer includes many or all of the elements described relative to the personal computer 120, although only ~ memory stora~,e device 150 has been 30 illustraled in Figure 1. The logical connections depicted in Figure I include a local JR~ b j6~j-18670 - 9 - E~press ~ ail No. E,~9~148~1US

area network (LAN) 1 ~ 1 and a wide area network (WAN) 152. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Intemet.
When used in a LAN networking environment, the personal computer 5 120 is connected to the local network 151 through a network interface or adapter 153. When used in a WAN networking environment, the personal computer 120 typically includes a modem 54 or other means for establishing communications over the wide area network 152, such as the Internet. The modem 15~', which may be intemal or external, is connected to the system bus 123 via the serial port 10 interface 146. In a networked environment, program modules depicted relative to the personal computer 120, or portions of them, may be stored in the remote memory storage device The network connections shown are examples only and other means of establishing a communications link between the computer~ mav be used.
~igure 7 is a block diagram illustrating a typical network configuiration 200 used to implement system software of the invention in a veterina:ry hospital. The network configuration 200 includes a server computer 7n2 and a number of personal computers 2W-21~ connected together on a computer networli 216. In this configuration, the network is an ethernet network, but any20 other conventional computer network can be used to implement the system. The computers are distributed throughout the hospital and are designed to provide access to some common functions as well as some special purpose functions unique to the particular computer. Some ofthe client computers have special attribute s that enable them to perform functions relevant to the part of the hospital 25 where they are located: I ) the reception computer 204 checl;s clients and patients in and Ol1t of the office and handles billing functions; 2) the exam room computers 208-210 are used by doctors and nurses to conduct medical examinations, to ma}~ediagnoses, and select a treatment protocol; 3) surgery/treatment computers 212 are located at sur~ery and treatment areas in the hospital and provide patient status 30 data (e.g., traffic control, patient triage information such as names of patients, JR~ b j6'j-48670 - 1 0 - E~;press ~lail No. EM~95 148~1 US
status, presenting complaint, to-do ~ists) as well as similar functions as the exam room computers 208-210; 4) the lab computer 214 interfaces with lab equipment and is used to enter information from lab tests; and 5) the pharmacy computer 216 is used lo fill prescriptions, conduct inventory control on pharrnaceuticals and5 medical supplies, order supplies, and provide database search functions.
While each computer is designed to perforrn certain types of functior.s in the of fice, many of the computers have common features and provide access to the same client and patient information and server functions. For example, if authorized, a doctor can look up client information on any of the I () computers in the network.
~ommunication Among Client i~,'odes Each of the computers can transfer messages to each other via a queue on the server. When the c]ient software running on a computer in the nctwork wishes to communicate with other client soRware, the client sends a 15 mess~ge to the server. The message can indicate that some event has ta~;en place or it can request an action. The server places this message in a shared queue inm.ain memory on the server.
Each ofthe client computers and the server periodically scan the queue for messages. In this implementation, the queue is a database file, and the 2() clients scan the queue by performing a database query on the file. If a client finds ~hat one of the messages is intended for it. it performs the requested action sought in the message. When the requested action is processed, the server deletes the record requesting the action. ~y updating the queue in this manner, each ofthe clients 011 the network are informed that the event or requested action in the ~5 message has been processed.

Authenticating Access to Server Functions and Data The server's database management soRware manages access to server functions and data in the databases by auIhenticating access to databases or 30 functions on the data. Specificaliy, the server 20~ maintains a table that lists JR1~1'jab j6~5-18670 - I I - E.Ypress ~lail No. EM~9~ 1~8~1 US

computers and users indexed to data and functions that the computer or user can access. Another authentication table tracl~s provider teams, which are typicallycomprised of a doctor, nurse and receptionist. This table keeps track of ~vho islogged into the system and determines, based on who is logged in, what functions5 and data each person will be able to access. For example, if a nurse is checked in, the nurse will be able to make preliminary medical observations, but will not beable to access diagnostic screens and make diagnosis.
The server controls access to server functions and data via a table indicating the name of each client computer connected to the network and a list of 10 functions that each client is able to access. In this particular implementation, the server uses the Windows operating system computer name to identify each computer. The server maintains a table of all computers which are attached to the system. This table includes the specific functions which the client computer is intended to perforrn. This enables the server to control which functions each client 1~ is able to access.
The client server model enables the provider teams to worL; together Oll a common set of data. As a member of a team completes part of an e~;arn or conducts some treatment using the system, the server soft~vare dynamically updates he data so that it will be properly reflected to other users when they access 20 it. For example, if a lab technician enters the test results of a blood test on Ihe lab computer, a doctor in the exam room will be able to get this information via theexam room computer.
In the current implementation of the system, the client computers each present a graphical user interface in a windowing environment. The user 25 interface displays text and graphical inforrnation about clients and patients (the client's pets) in windows. The users of the system enter input using a variety of input devices including a key board and pointing devices such as a mouse, tracl;ball, touch screen membrane or touch pad.

JR~Uj~b j6~ 8670 - 12 - E:Ypress Mail No. EM~951d,8~1US

The Li!nk to a Remotc Computer The computer networl~ shou-n in Fig. 2 is an example of the network configuration in a typical hospital. A number of these network configurations around the country are connected to a central computer 220. As shown in Fig. 2, 5 the server computer 20~ is connected to a remote computer 220, which acts as the central computer for several hospitals. The central computer periodically dials-up the server via the telephone network 224 and obtains a copy of the hospital's data All inforrnation at the hospitals which has changed is gathered into the centralsystem .
The server, in this example configuration shown in Fig. 2, is connected to the phone networ~ via a modem ~6. The central computer 2~0 also controls administrative and billing functions. One important function of the central computer is how it administrates wellness plans. Specifically, the central- computer is responsible for handling billing of clients that have selected wellness plans.
15 ~hc Rel.eption Computer As introduced above, the functions of each of the client computers are generally related to uhere they are located in the hospital. In the receptionist area ~30 of the hospital, the receptionist computer 204 is designed primarily to checli patients in and out of the hospital and monitor client and patient traffic by keeping 20 tracl~ of who is in the hospital, where they are, and how long they have been in the hospital. T~pically there are at least tuo reception computers. Each them share a printer 232 used to print invoices and client education information.
Thc E~;am Room Coml)utcrs In the exam rooms 234 of the hospital, the exam room computers 5 208-~10 are used to conduct medical exams. The physical exam software modules wall~ the nurse and doctor through an entire medical exanl. The soft- are displays exam screens that prompt the user for input. The user interface screens guide thc user by clisplaying a list of items that require obser~ation. For some items, the softuare will not allow the user to proceed without entering an obser~ation. At the 30 end of the physical exam, the physical exam softwarc requires the doctor to sigtl ~R~l/jnb~6 ~ 670 - 13 - E.~p~ess l~,lail ~!o, El~l'9~148_~1US

off on the physical exam. The doctor can then proceed to invoke the diagnosis software.
The diagnosis software uses the observations made during the medical exam to prepare a rule out list and prescribe a treatment protocol.
5 Diagnosis software running on the server uses the observations to generate a list of abnormal observations and tentative diagnosis. The doctor can then select a tentative diagnosis by positioning the cursor over a diagnosis and selecting it. By selectin g a tentative diagnosis, the user triggers the generation of a treatment protocol. This treatment protocol can then be integrated into future medical exam 10 sessions. It is integrated because procedures that need to be performed and observations that need to be made are identified in the graphical e~;am screens in follow-up visits. Thus, once a treatment protocol is selected, the system manages the administration of that protocol in future e~am sessions.
Thc Surger~ and ~rcatment Computers In the example shown in Fig. 2, the surgery and treatment computers 212 are combined and are depicted as beimg in a single location 236 (e.g., a surgery and treatment area in the hospital). As emphasized above, it is not necessary tohave separate computers for performing separate functions such as having a surgery computer for displaying triage information or a treatment computer for 20 recording treatments on a patient as they are performed. Instead, surgery and treatment functions can be accessed from a single computer.

Thc Lab Comruter In the lab 238 of the hospital, the lab computer is used to check lab 25 tests that have been ordered and to enter lab results. The lab functions of the system include an interactive user interface that enables members of a provider team to look up a patient and either enter lab results or view a list of tests that need to be per~ormed for a patient. The user interface includes a laboratory screen, listing rerords including client name, patient name, name of a test, and when the 30 test was ordered. The user can clicl; on a record to select it and then proceed to a J~,y~b~6 j ~867~ - 14- E~pressMailNo.E~119~14$'51US

lab results screen by clicking on a buKon in the lab screen. The system will display a lab results screen, which prompts the user to type in the results and record the changes. When the user clicks on a button to record the changes, the changes getupdated in a table used to store laboratory results and symptoms maintained for the S patient.
The service items ordered for a patient, such as lab tests, are recorded in an accounting line item table. When a user enters a change in status for a lab test, the system updates the status of the service item corresponding to this test in the accounting line item table. In addition to updating the status in the accounting 0 line item table, the system posts a note in the medical lab notes for the patient indicating that the test is complete.
The Pharmacy ~omputer In the pharmacy 240 of the hospital, the pharrnacy computeF 216 manages the pharmaceutical products and processes requests for prescriptions. The 15 pharmacy computer executes client phamlacy software that is integrated with the exam software in that it responds to requests to generate labels when a doctor enters a prescription in a prescription screen during the medical e~;am. The pharmacy computer 216 iS connected to a printer 242 used to print prescription labels.
Having described the system architecture of a network configuration in a veterinary hospital, we now describe the software for managing a medical practice in more detail.
~racking the Provider Team The software system tracks user input to the system based on a 25 provider team. As described above, users get access to the system and its functions based on their login name. Once logged in, a user has access to data and functions in the system. As observations are entered, these observations are attributed to the person that made them based on the login of the session. A session refers to thetime period in which a user is logged in to the system and is accessing server 30 functionality. As a member of the medical team takes an action and records this JRJ~Ujab j675-J8670 ~ - E:~pressi\,laiiNo.E~l 95]48~1US

action through the user interface client, the system attributes the action to the person and team that took the action.
Tracking the provider team has implications on generating billing reports and producti~dty reports. In the system, activities of team members can be 5 classifled as a selling or providing. As products or services are provided to a client/patient, a member of the team enters the information on the user interface, typically by selecting the item on the user interface. These items are added to a file representing the client's bill and in addition are attributed to the provider team.
Charg,eable service or products provided by the team are attributed to a selling and 10 providing person in a predetermined proportion~ such as 55/45 percent This enables l:he system to generate productivity reports i'or a provider based on individual product and service items This feature also enables the system to give credit to The providers that are responsible for getting clients to sign up on av.~ellness plan, which is also administered on the server.
15 T~a~king Patient Workflo~
~ n addition to guiding a user through the physical exam and diagnosis process~ e system also tracks the work flow in a medical facility such as a hospital or doctor's office. When a patient arrives, the patient is "checl;ed into" the system. Throughout the visit, the system trac~s the patient's progress through 20 various stages of the visit, such as waiting in the lobby, undergoing a ph~ sical examination in an exam room, awaiting check-out, undergoing tests in the lab, hospitalized, etc. These stages generally correspond to different parts ofthe medical i-~acility such as the lobby, e~cam room, lab, surgery room etc. However, it is important to emphasize that the stages do not have to be associated with separate 25 physical locations, especially in a srnaller facility where a single room is used for the medical exam, lab tests and surgery.
As the patient progresses through a visit, the system software guides the provider team through the visit by prompting the user for input needed to complete each stage. This input can include patient data, medical findings (or at 30 least conllrmation that examination is complete)~ or authorization from a doctor.

Vj~b'6'j-J~670 - l6- E.~pressi~[ailNo.EI~79~I4S~5IIJS

When a member of the provider team completes a stage in the visit, such as checking in a patient or conducting a medical e~am, the system tracks the flow by updating the status of the patient's visit in memory. In a client server configu:ration, this status information is maintained on the server so that members 5 of the provider team can check the patient's status from different client computers.
By trac~ing patient status in this manner, the system ensures that the patient's visit proceeds in an orderly manner, that all necessary services are provided, and that a complete record of an entire visit is recorded in the system. In addition, it gives the provider team an opportunity to trac~ which patients are in the facility, what their 10 current status is, and how long each patient has been in the facility.
Patient Check In When a client brings a patient to the veterinary hospital, the first step on the system is to checli-in the client and patient at the receptionist com~3uter. l'he receptioilist computer acts as an interface to the systems Appointment Schedulerl i and also provides a Reception screen that enables the user to change the status or location of patients w,ithin the hospital, as tracl;ed by the server. l he receptionist perfcrms se~eral tasl;s using the reception screen as a method of identifying the p~.tient to service. These functions include checl;ing patients into the hospital, assigning e~;am rooms, malcing appointments, mal~ing follo~ up telephone calls, ~0 and performing patient checl~-out and cash receipts functions.
The reception screen is used to checl; in a client and the patient (the client's pet). If either the client of patient is new, the system presents screens to prompt the user for missing information. For patients, the system prompts the user for patient information such as: gender (male, female, unl;no~n), whether neutered 25 or spayed, noting of allergic reaction, tendency of a pet to bite~ and whether pet is on welln,-ss plan.
As part of the client checl; in procedure, the system may request the client to verify client information. At a client checl; in screen, the system will checli whether the client has been in the hospital in the last 15 days. If so, the 30 system ~,ill assume that the client information displayed in this screen is current.

b'6~-15670 - 17 - E.Ypress l~ilail No. E~1~9~1~S~51US

If not, the client screen will prompt the user to verify client information. Thereceptionist must enter input acknowledging that the client has signed a release to provide care to the patient. The entry of the release to the system is a critical event that must occur before the system will proceed to a medical exam. The S receptionist can also enter a list of items that the client left with the pet. This informa-tion is useful at a check out screen, where the reception computer retrieves a list of these items from the server and displays them as reminder to return them to the client.
As part of the patient check in procedure, a receptionist enters the 10 presenth1g complaint via the user interface of the reception computer. The reception computer sends the te~t describing the presenting complaint to the server, which ir, turn records it in the patient's medical record. ~ new medical record,with presenting complaint, is created for eacll visit of the patient to the h~spital.
Client computers load and display the presenling complaint (as well as other I S patient data) in a banner displayed in a variety of screens in client computers in the hospital ~~-hen accessed by members of the provider team. The receptionist also enters the patient's weight and records the weight in the system. The entry of the weight informatioll is another critical event that needs to occur before any exam or procedure can occur on the patient during the visit. For e~;ample, the system will 20 not allow a user to e~;ecute the physical e~;am software for this patient without having this information recorded first.
When a user enters a request al a client computer to load physical exam software for a patient, the client computer sends the request to the server.
The server checl~s the patient's data file to checl; whether a critical event ( entry of 25 the weight) has occurred. If not, the server will transfer a message to the client computer indicating the error and the reason for the error. The client computer will then display a message bo:~ to the user indicating that the critical event must occur before the physical e?;am can proceed.
A main control screen, accessible f'rorn thc receptionist computer, 30 tracl;s the stalus of patients relative to the traff ic at the hospital. The server IR~ b j6~ 670 - l 8 - E~;press l~aiI ~lo. E~1 95148~IUS

classifies patients as 1 ) Awaiting Pick Up, 2) Checking Out, 3) Missed Appointments, 4) In the Lobby, and 5) Scheduled to come in. Category 4 is brol~en into two further categories, using attributes assigned to the record in a traffic database: A) Scheduled to Come In, Drop Off; and Scheduled to come In, In 5 Lobby.
This feature is implemented by dynamically tracking the patients in a hospital in a file on the server. The server maintains patient status table storing a dyr.amic list of all patients which are in the hospital at a given time. This table also includes the date and time the patient arrived, and the current physical location 10 of the patient within the hospital. The server updates the table in response to messages from the clients that change the status of the patient. For e:;ample, when the reception computer checks in a patient, it also sends a message to the server indicating the name and status of the patient. The server places a time stamped record in the patient status table. As the patient proceeds through the hospital from .i 5 receptiorl, exam room, to check out, the client computers update the status of the patient by sending a message to the server indicating the patient and the current patient status.
Automal:ic Selection and Playback of Clicnt Education Video The system is programmed to playback client education videos for 2() clients in the waiting room of the hospital. There are two ways to select a video in the system. One way is for the receptionist to select a video from a list. In this case, the receptionist specifies the video7 the exam room, and a programmable delay period. In response, the server issues a command to the exam computer to queue the video and play it aRer the programmed delay period. The video is 2~ preferably stored on the client computer (e.g., the exam room computer) where it will be played back. The video will begin to play on the exam room computer after the delay period chosen by the receptionist elapses.
The second way to playbacl; a video in the system is by automatic selection by the server. The server matches the patient in the hospital with a room 30 where the patient is located using two tables: I ) the patient status table, which b~67s-~867o - 19- E~pressMailNo.E~vl'9~14S'51US

shows t.he patients currently in the hospital and each of the patients' current status;
and 2) a client computer table, which maintains the status and identification of each computer in the hospital. When the patient is assigned to an exam room, the system rnatches the patient to the computer associated with that exam room. The server then evaluates a variety of attributes about the patient to select an appropriate video. One attribute is a patient record indicating the purpose of the visit. Other attributes used to select a video are the type of pet, the age of the pet, and the time of year. The server first tries to find a matching video for the purpose of the visit by text searching the list of videos for a topic that matches the purpose I() ofthe visit. Finding no matches, the server continues searching for matches based on other criteria in a predetermined order.

Physi-al E~;~millation TransferrinO from One '7~oom "~o Anol'l er 1 J Before the physical exam can begin, the receptionist has to check the patient into an exam room. The receptionist does this by entering the exam room r.umber at the reception computer. The reception computer sends a message to theserver, ~hich in turn, updates the patient status table to reflect the location of the patient, e .g., the patient is in a medical e.;am in exam room 1.
Personnel in the hospital can check on the status of patients occupied in the exam room. Fig. 3 illustrates a screen diagram indicating a window for checkin~, the status of an exam room. To bring-up this screen, a user can doubleclick on the patient's name in the reception screen displayed by a client computer.
.~s shown in Fig. 3, the Exam Room Status screen 300 is a graphical window divided into two primary sections: a banner 302 showing patient information; and a window 304 showing exam room status information. The banner 30~ includes the client name, patient name, gender, weight, and species. The banner is also colorcoded so that the provider team can readily identify key information about the patient or client. Gender is depicted with colors (e.g., blue for male, and pink for JR~ b~6~ 670 - 20 - EYpress Mail No. EM 9~148 51US

female). A client ~vith an overdue bill is depicted with a red colored banner (aclient in "collection").
The window 304 includes a box 306 called "Presenting Complaint"
that lists the service category, service description, and any further description. The S window ,04 also includes dynamically updated information such as the time of check-in 3 10 and elapsed time in the office 312.
This window also illustrates an example of ho~ the system navigates a patien~ and client through an office visit. A user can change the status of a patient in the exam room by clicl~ing on a control button 320 in the windo-v. For example, in this screen, the user can indicate that the patient is ready for check out.
This sends a message to the server, ~vhich updates the status of the patient. The reception screen can then be used to check out the palient.
T~Je P~ysicnl ~xomioatiotl -When the nurse logs onto the computer located ~vithin the exam i S room, the physical examination for the patient assigned to the exam room is p~esente(:h No action is required on the part of the nurse to select the exam, the e:;am room, or the patient. The client computer in the exam room displays the ~hysical Examination Screen, populated ~vith information about the patient that is checl;ed into the e~;am room.
~ig. 4 shows an example of the Physical ~:xamination Screen 400.
This screen includes the following graphical elements: the client patient banner 40~, the preseilting complaint box 404, a preventative care box 406, a tentative diagnosis box 40S, a series of buttons 410 that list and navigate to screens used to obtain input and guide the user through the physical e~;am, and control buttons 4 l ~-416 for changing the status of the e:;am.
The banner 402 and the presenting complaint bo~; are the same features as shown in ~ig. 3.
The preventative care box 406 lists preventative care services and their status in a color coded fashion. When a client signs up for a wellness plan for ,0 his or hel pet, the system loads additional sottware components that are used to Ujab ~675~18670 ~ E:~:press ;~,lail No. E.~1~9~ 148 '51 US

~lmini~ter the plan. This is an example of such a feature. In this case, the physical exam screens display additional information about the status of the preventativecare ser~ices provided under the plan. The physical exam screen prompt the user about the status of a preventative care service and tell the user when the service 5 should be provided.
In this version of the soRware, the preventative care status is displayed in a color coded fashion. The possible status includes: Red=due now, Yellow=-due soon, r~lue=ordered this visit, White=don't give, and Green=current.rhis stal:us information is dynamically updated on the server as a member of a 10 provider team enters input indicating that a service has been performed. In addition, the system has a scheduler that deterrnines when changes in status occur based on the order date and the current date. When the physical examination process is initiated, the server ioo};s up the status of each preventive care item so that the most recent information can be returned to the client for display. This15 status information is maintained in an Accounting Sales Line Item table on the ser~er.
The tentative diagnosis bo~; provides the diaonosis history ofthe patient. This box Iists diagnosis that have been made as result of previous physical exams. The diagnosis soRware is explained in further detail below. Houever, to ~0 summarize briefly, the server generates tentative diagnosis based on obser-,ations collected. during the physical exam. When the doctor selects a diagnosis using the diagnosi s tools, the server adds these to a diagnosis table. The server generates the diagnosi s history from this table. From this window, the provider can retrieve more detailed medical history data, including diagnoses.
~5 The physical exam buttons represent the top level in a hierarchy of physical exam screens. The physical exam is broken into the following areas:
I ) . Overal I Condition ~) Coat and Skin 3) Ocular JR~\,Vj;lb56'~t,670 - 22 - E~;press Mail ~lo. EM '951487~1US

4) Otic 5) Oral/Nasal 6) Respiratory 7) Cardiovascular S 8) Abdominal -9) Urogenital 1 0) Perineal I 1) Musculoskeletal I 1) Neurological i 0 12) ~3ehavioral When the user clicl;s on any of these buttons, the system launches a new screen for the selected part of the physical exam. The interactive exam screens guide the user through the physical exam. As user enters information (byI S clicking on buttons or entering text), the server dynamically updates the database and evaluates the data to determine whether to prompt the user for additional information by displaying questions and supplemental screens that prompt the user ~o input medical observations.
During an initial exam, many of the observations listed in the e~am screens default to normal. If an abnormal observation is checked, subsequent exams will default to the previous findings by displaying the abnormal observation as marked in a previous exam. In some instances where critical information is necessary, the user will not be allowed to e:;it from a screen until certain observati:ons are made, as reflected by the user entering some obser~ation.
Some observations trigger actions that need to be performed right a-vay, and others trigger actions that can be performed later. In either case, the client monitors for this type of input, and when it detects the observation, it evaluates preprogrammed expressions to determine ~~hich actions should be performed right away or per~ormed later. ~or actions that should be perforrned right aw2y, it displays additional queries using message boxes or additional J'~Vj;~b~6'7-S~670 - ~3 - E~;press l~lail ~!o. E.~ 9~148~1US

screens. As observations are made during the physical exam, the need to present additional screens is maintained in memory variables which control the operationand behavior of the exam as a ~vhole, and the operation and behavior of individual sub-exam screens.
The user can proceed through the physical exam portions in any order, but must complete all parts ofthe exam before any diagnosis is performed.To reflect parts of the exam that are complete, the physical exam screen shown in Fig. 4 includes a status box (e.g., 420) next to each navigational button that links to the portions of the physical exam. These boxes are color coded to indicate the 10 status of'the corresponding part ofthe exam. In this version, green means allfindings are normal in this part of the exam, red means that the nurse has marked abnorm3.1 fmdings l'or the doctor's revie~v, and blue means that text questions ~ere not ans~!ered by the doctor.
The control buttons across the bottom enable the user to control the 15 slatlls of the exam. For example, the user can choose to check out of the exam, to suspend the exam, indicate that the exam is complete.

~xamp/e ~xam Screerls Fig. ~ illustrates an example of a physical exam screen used to record 20 information about a patient's overall condition. The Overall Condition Screen ~00 includes the banner ~02, a control bar ~04 across the bottom, and a variety of graphicai user interface controls for collecting input (text or cursor control device) and for displaying output (including numerical data, observations recorded as text, and graphical data generated by the server).
2~ The graphical user interface controls prompt the user to enter information because they display an item to be observed and then give the user an option to make some observation for that item. ~or example, in this screen, the user can select the overall condition or temperature observation by checking a check bui:ton (e.g., ~10, ~12). The user can enter numerical data such as temperature via a g,raphical box ~14 that allows the user to scroll through a range J~Uj~b j6~ S670 - 74 - E.~press ,~lail No. EM~9~ 14~51 US

of numbers. In addition, the user can enter or select text input from drop-down bo~;es (e.g., 516).
The screens display patient data dynamically as well. For example the temperature history box 5~0 displays temperature observations. The user can 5 also choose to display a graph of the temperature by clicl~ing on the "graph temperature" button 5~.
The system also documents when services have been offered and declinecl by the client. For example, the screen in Fig. 5 has a box 530 entitled "Recommended Care Declined" ~vhich lists any services that the client has declined 10 in the past.
The data displayed in this and other exam screens is dynamic in that it is updated by the server soon after it is entered. l'hus, the screens reflect up-to-the-minllte data, some of which may have been entered just monlents ago-on the ,ame or a different client computer. The interface screens are formatted to display 15 infor nal:ion about a patient, and the system draws this information from thepatient's records, which are updated each time new information is entered at anyclient computer. When the user selects a screen for display, the patient data in the display is drawn from the current patient records on the server.
When the user initiates the exam, the ser~er evaluates the ~0 observations and determines whictl questions and warnillgs should be displayed to the user. As the user accesses screens in the exam, these warnings or questions forrn part of the display screen. Thus, the display changes based on prior recorded observations.
Tfle Con~ro/ ~nr ~5 Several of the physical exam screens hal. e a control bar such as theone shov~n in ~ig. 5. This control bar includes graphical control buttons that provide helpful functions during the exam. The example-shown in ~ig. 5 includes a checl; rnart~ 540, a stop button 54~, an exclamation point 544, a drop down list of videos 5~6, a warning bell 548, and a medical note pad editor 550.

J~Uj~bS6~ S670 - ~ - E:;press Mail No. E~1~95148~1US

The check mark is a navigational control that enables the user to tell the server that the user is ready to move on to the ne.~t screem The stop buttonhalts the exam and returns the client to the physical e~am screen. The e~;clamation point enables a nurse to checl; a part ofthe e~cam to call it to the doctors attention S This input event tells the doctor that he or she needs to check this part of the e~am.
The screen is marked in blue to tell the doctor to observe more closely.
The video screen drop do- n list enables the user to select and instruct the server to play a selected video. The server selects these videos dynamicallybased 0]1 the current screen being displayed.
The warning bell button enables a member of the team to call for help in case of a problem. When a user presses this button, the client sends a message to the server that an alarm should be played on the other client computers. In this implem, ntation, the alarm includes a visual alert screen and an audio alert generated on the other computers within the system. An alternative is to sound an 15 audio alarm on the other computers. The alert is triggered through the addition of a record onto the message queue that all computers in the system are monitoring.
The alert is cleared through the deletion of the record.
Finally, the notepad button launctles a te.~;t editor in a window that enables the user to enter a medical note. ~The server records the date, time, the te:;t ~0 entered by the user, and who made the observation.
Lin/.-inr, of Screens As a user mal;es observations, the system evaluates whether the observations require supplemental information. Some observations can generate warning, in screens for other parts of the e~am. To improve performance, the ~5 client maintains the patient s e:~am file in memory and issues conte;;t sensitive additional questions that are generated based on obser-ations entered during thee~;am. As observations are made during the physical e:;am, the client e~ecuting the physical e~am software determines when to present additional screens. The conditions that need to be satisfied to tri=ger additional e~altl screens are JRl~y~b~6~ s67o - '76 - E.Ypress ~fall ~o. E~ 9~118~51US

maintained in memory variables which control the operation and behavior of the e~;am as a whole, and the operation and behavior of individual sub-exam screens.~ ig. 6 illustrates an e~;ample of a supplementAI screen that is triggered in response to an abnorrmal observation. In this example, the client prompts the.
5 user for more information ~ith a supplemental screen because the user has entered an abnormal observation on the abdominal screen. The supplemental screen shown in Fig. ~, prompts the user to record any additional abnormalities from a predetermilled list.
In addition to generating ne-v questions and supplemental screens lO dynamically, another feature is the ability to launch other soft~are processes in the system in response to an observation or a request to perform some treatment. Forinstance, if the doctor decides to prescribe a drug that is listed on a treatment list, the doctor can select that treatment by clic};ing on it. The client soft~vare-will then launch a prescription screen so that the doctor can hnmediately fill the prescription.
l5 ~hen the doctor completes the prescription and exits the prescription screen. the client sends a print job to the prescription printer. It then prints the label on the altached printer.
During the examination, the doctor may prescribe and dispense various treatments via additional user interface screens. One such screen, called 20 the therapy screen, can be accessed via a drop down menu. As explained further be!o~v, this screen lists therapy service items that have been prescribed based on a previous diagnosis. When the doctor completes the service, he or she enters the change in status through the therapy screen. The server automatically adds service items co.mpleted during the visit to the client's invoice. rhe doctor can also use ~5 another screel1, called the order screen, to prescribe and dispense a treatment item.
Grapllical Displays Use~l to Enter Paticnt 015scrvations Fig. 7 is an e~;ample of a screen 700 used to prompt the user for graphical input of medical observations. In this example, the screen displays a graphical representation of the pet 702, 70 1 and enables the user to marl; the 30 location ~f lesions on the sl;hl graphically. The graphical representation shows a - 27 - E:;press ;~,lail No. E~1~9~14~51US

part of t:he anatomy of the pet and is responsive to cursor input from a pointing devices such as a mouse, track ball, or touch screen. The user can mark the location of lesions on the patient using the cursor control device.
The type of observation (i.e. the type of lesion in this example) is 5 entered via a selection list 706. First, the user selects the type of lesion by clicking on a selection in the list, and then marks the location of a lesion by positioning the cursor over the position on the graphical depiction of the skin where the lesion is located on the pet.
Each time the user clicks on the graphical representation, the client 10 software records medical observations as observation records in a database file.
These records include: the type of observation, top or bottom view, the date andtime, the doctor-nurse team who recorded the observation, and the coordinates ofthe pixel where the user mar~ed the lesion. These coordinates are mapped to actual bo~ily region (based on their location, e.g., pixel at (5, 19) is mapped to the dorsal 5 paw) l~erifcatio~ of tlre ~-anr The physical e:;am software provides a user interface control that enables the doctor to record an event certifying that all of the observations have been documented. Specifically, the client soft~vare displays the dialog box shol,vn 20 in Fig. ~. The client software displays this dialog box in response to a user clicl;ing on the exam complete button in the physical e;;am screen.
In order to complete an exam, tlle doctor must login to the system.
After logging in, the doctor can review and edit the observations made by the nurse, perform treatment, etc. When complete, the doctor clicl;s on the exam 25 complete button, which causes the client to display the signature box. The doctor's signature is stored as an image in the hospital database. The server ensures that the signature is inserted on all ofthe forms requiring a doctor's signature.

CA 02227l03 l998-0l-l6 IR.~L'j~b j6~ 8670 - 28- E:~press,~ailNo.EM~9~11S~51US

Diagnosis and Therapy Selection When the physical exam is complete, the doctor can proceed to a diagnosis screen. Fig. 9 illustrates an e~cample of the diagnosis screen. This screen is displayed in response to the doctor certifying that the exam is complete as S e~;plained above. The diagnosis screen includes the patient banner 902, a box for displaying abnormal observations 904, a bo~; for displayincg a rule out list 906, and a box for displaying tentative diagnosis 908. The box 910 labeled as "unresolvedsymptorns" keeps a running total of symptoms that are not linked to a diagnosis.The diagnosis screen also includes a number of navigational controls 10 used to navigate to other parts of the system or to launch other features. These controls include: I ) a "search for diagnosis" button 91~ that launches the interface to a database search tool for l;eyword searching the systemls list of diagnosis, ~) a "protocol" button 914 ~hich launches a service for applying a protocol to the patient given the tentative diagnosis selected in the dia$nosis screen, 3) a healthy 15 pet button 916 which enables the team member to indicate that no diagnosis ortreatment protocol need be selected, and ~) an e~;it button 91~ used to e~;it ~he diagnosi~ screen and return to the main window of the client software.
When the e~;am is complete and certified, the client software on the e.~;am PC' sends a message to the ser~,~er, ~,vhich compiles a list ofthe abnormal 20 observations in response and places them in a table. These abnormal observations are then ,iisplayed in the abnormal observation bo:~ 90~. ~ach of the records in this list can be marked as either diagnosed or removed. l o remove an observation, the doctor clicks on the "remove symptom" button 920. This button toggles between "remove symptom" and "use symptom in diagnosis" to enable the user to add a 25 symptom bact; onto the list of abnormal observations.
The rule out !ist is a list of possible diagnosis automatically generated by the se;ver. The rule out list is generated from a table that l;eeps a list of all ailments called the "all ailments table." Each item within the all ailments table has observations potentially associated with it. The actual observations made during b j67';-1~670 - 29 - E.~press l~lail No. EM79~148'51US

the physical examination are matched against the list of observations associatedwith ailrnents. Ailments which match are then added to the diagnosis rule out list.
The doctor can select a diagnosis by clicking on an item in the rule out list. When the doctor does so, the client sends a message to the server S indicatin.g the selected diagnosis. The server removes the diagnosis from the rule out list, i~dds it to the tentative diagnosis, and determines which abnormal observations are linked to the diagnosis. It then marks the abnormal observations that are linked to the selected diagnosis with a "D." The server sends the results of these operations back to the client to update the display dynamically. In the 10 display, the selected diagnosis moves to the tentative diagnosis box, the abnormal observations linked to the selected diagnosis are marl;ed with a "D" and the unresolved symptoms count is updated to a number reflecting the number of abnormal observations that are undiagnosed and not marl;ed as removed. .
In the tentative diagnosis bo~;, the client also displays the status of the 15 diagnosi " as reflected in the diagnosis table maintained on the server. The ?ossible status includes: Needs protocol, Undergoing Therapy, Client Postponed, and Client Declined. This status is updated automatically as the user tal;es actions that change the status of a diagnosis. ~or e~;ample in this version, the initial status of a selected diagnosis is "Needs Protocol." When the doctor places the cursor 20 over a dii~gnosis in the tentative diagnosis bo~c, it becomes highlighted. The doctor can then launch a protocol by clicking on the protocol button. In response, the client sends a message to the server, which changes the status of the diagnosis to Undergoi:ng therapy. In addition, the server generates the protocol.
To generate a protocol, the server looks up the protocol in a protocol 25 table using the selected diagnosis as a l;ey. The protocol for a tentative diagnosis includes one or more (typically several) recommended therapy items, each having a status. When the user clicks on the protocol button, the server generates the protocol and sends the protocol items and status to the client. In tum, the client displays a diagnostic protocol screen.

r~l~56 j~8670 -30- E::press~lail~lo.Ei',1~9~148~1US

Fig. 10 is an example of the diagnostic protocol screen used to manage a treatment protocol. The diagnostic protocol screen 1000 includes the patient banner 100~ (the same as in other screens described above), a tentative diagnosis box 1004, a recommended therapy box 1006, a diagnosis status check 5 list 100g, and navigational control buttons 1010-1014 to link to other screens and~
launch other features.
The tentative diagnosis box 1004 lists the selected diagnosis from the diagnosis screen. The recommended therapy box 1006 lists the therapy items for the trealmen~ protocol corresponding to the selected diagnosis. Note that the 10 therapy items each have a status associated ~ith them, either required or recommended. The doctor can change the status from recommended to required or vice-versa by clicking on a therapy item.
The diagnostic status check list 10()8 includes a series of check buttons that enables the user to record the status of the treatment protocol tor the 15 s~elected diagnosis. This feature facilitates thorou~,h record keeping and enables the medical practice to document that the protocol options were presented to the client and ~hether the client refused the treatment.
The navigational controls linl; to other screens and provide access to additional functions. One function is the estimate function, ~vhich causes the ~0 system to display a list of services, the status of tile services, and a cost estimate.
To access this function, the user clicks on the Estimate button. The estimate screen is described in further detail below.
The additional therapy button 10~ 2 and continue button 1014 link to other screens. This enables the doctor to go to another screen to modify the ~5 therapy protocol.
The server compiles the services in the treatment protocol into a cost estimate. In addition, it forces follow-up in two important ways. First, it handles scheduling ofthe next visits and schedules follow-up calls. Second, it automatically adds prompting mess,~ges in future physical exam sessions to remind JK~l!j3bS6~;~S670 - 31 - E.~press ~ail No. EM 9~14~51US

the provider team that certain observations are made and therapy service items are performed.
Fig. 1 1 is an example of the Estimate screen 1 100. This screen can be accessed from several different screens in the physical exam and diagnostic 5 software to show a cost estimate of product and service items that have been or are to be provided to the patient. Specifically, the cost estimated can be generated as service items are requested by the client during a visit or at the end of the visit.
The Estimate screen is linked to the treatment protocol screen to give the client a cost estimate of all of the therapy service items that are to-be provided under the 1 0 protocol.
The list of service items in the cost estimate is dynamically generated during patient visits, either as a result of the provider team selecting a product or service f'or the patient or the treatment protocol automatically adding therapy items to the list. In addition, if the patient is on a wellness plan, preventative care 15 services are automaticall,v added to this list when the plan is initiated. As items are prescribed for the palient, records are added to a table called the Accounting Sales Line Itern table. Items added have an initial status code which indicates that the item is to be done. Once an item is completed, the status code is changed to reflect that the item is done. The status of each record reflects its status as an item which ~0 has been completed, or needs to be done. To generate a cost estimate, the server searches the Accounting Sales Line Item table in the status field to identify items that are c:ompleted and generates a list of completed items along with the cost of each item.
The ~stimate screen 1 100 includes the patient banner 1 10~, a service 25 item box 1104, and several cost summary boxes 1106-1110. The screen also includes control buttons I I 1~, 1 1 14 to print out a cost estimate and exit the screen.
The services box 1 104 lists the following records: a service item, its estimated cost, the name of the patient, and date completed.

J~ b~67~ 670 - 32 - E~press ~ail No. EM79~1~S751US

The Estimate Screen estimates costs in three different categories: the ~vellnes.s plan cost estimate 1 106, the regular fee estimate 1 108 and the client's estimate 1 110.
The user can print an estimate by clicking on the print control S button 1112. When the user e~cits the estimate screen, the client software returns to the physical exam screen. At this point, the doctor can proceed to provide the therapy for the patient. To generate the therapy screen for the patient, the user selects ~herapy: patient from a drop do~in menu.
Fig. 12 is an e,~;ample of the therapy screen 1200 used to Inanage the 10 administration of a therapy service item. The therapv screen displays all the items that have been prescribed to be administered to the patient. Additional information relating to dosage is also included. The therapy screen may optionally view the current medical record *om a standpoint of all items prescribed, or only t~ose items re~maining to be performed. The therapy screen allows access to other I ~ screens ;uch as the physical exan~ination, the medical notes, diagnosis and orderin_ screens, via drop down menus~ navigational controls and user selection of therapy service items displayed on the screen. The therapy screen is accessible from other screens as well via a drop do~-n menu and navigational control buttons.
The therapy screen 1200 includes a banner 1202, a bo.~; 170J, showing 20 therapy service items and related attributes, a list of checi; buttons i 206 tor selectinc,~ portions of the service table for viewing, a status control button 1208 for changing the status of selected service items; a print label button 1210 for printing labels, and a remove item button 1212 for removing selected therapy service items.
This screen also includes a bo~; 1214 for viewing the tentative diagnoses, including 2~ a list of diagnoses where each diagnoses has a date and status attribute. Finaliy, the therapy screen includes navigationai buttons 1270-1276 used to lini; to other screens alld access other f'unctionality.
The bo~; of therapy items 170J" in this version, includes a list of product and service items, with fields for the date the order was received. thc 30 quantity ot'the item, and the status. In the case of prescriptions, the bo~; also ~Uj~b~6~ 670 - 33- E~pr~ssl~lail~'o.EI~f~9514S~lUS

displays dosage and frequency. This box 1204 enables the doctor to vie~v a list of service items scheduled for a patient to keep track of ~vhat has been done and what needs tc be done. When the doctor or other member of a provider team provides a product or service, the team member can update the status of a service item in the S patient"; data by selecting an item and indicating that it is done. For instance, the doctor can select items and press the "mal~e all done" button to indicate that the status of these items has changed from "to-do" to "done." In response, the server dynamically updates the status of the data in the patient's database. The clientsends a message to the server with the change in status so that the server data 10 matches the status currently displayed 011 the screen of the client computer. In a similar fashion, the doctor can remove items ~rom the list by selecting them andclicl;ing on the "remove items" button 1212.
The print labels button is used to initiate a print process for printing a l~bel for a prescriplion selected from the list of items in the list of therapy box l 204. When the user cliclis on the print labels button 1210, the client sends amessage to the server with the pertinent data about the prescription. The pharmacy computer then retrieves this message from the server and processes the re~uest by initiatin g a print process to print a label with the information provided in the message.
The navigational buttons 1220-1226 linl;: to other screens. For example, the physical exam button 1222 linlis to the physical exam screen.

Client Check Out To complete a patient visit and transfer a patient's file to checl;ing-25 out statu,, the doctor (or other member of the provider team) returns to the physical exam screen (Fig. 4) and then selects the Exan1 checl;-out button 402. This causes the clienl: computer to display an exam room check out screem An example of thiswindo~v is shown in ~ig. 13.
The exam room checl; out screen includes a patient banner 1302, a 30 "next appointment" message box 1304, a service message bo:; ]306, and control ~jab ~6~ 670 - 34 - E~press ~ai I No. EM~9514~ 1 US

buttons 1308-1312,1322-1324. The "next appointment" message box displays the next appointment scheduled for the patient from the patient's medical record stored on the server. The service message box 1306 is used to display and enter a service categorf, service description, and any additional descriptive infomnation about a 5 service item to be provided at an appointment. The user enters this information by selecting it from a predeterrnined list or entering it via the keyboard.
rhe e~cam room check out window includes a number of list boxes 132() displaying "Days", "Weeks", and "Months" that enable the user to select an approximate time for a call-back or another appointment. When the user10 enters infommation in these boxes, the button 1322 shown as ''Book Appt. And Callback" changes from "No Appt. Or Callback" to "Book Appt. And Callback" to reflect that an appointment is being scheduled.
ARer entering information for an appointment and/or callbacl;, the user can click on the button labeled 132~) to cause the server to schedule Ihe 15 appointrnent or ca]lbacl;. The server has a scheduler program that can schedule .,ppointments based on load (attempt to schedule appointments off-peak time p-riods). If the user requests an appointment by clicl;ing on button 1322, a scheduler on the server will search for a time slot available near the appro~;imate time entered by the user and enter a record of the appointment for the available20 time. Fcir call backs, the scheduler will schedule a reminder for the provider team -to call the client back at or before the appro:~imate callbacl; time entered by the user. Jf the user wants to view the available time slots and schedule an appointment directly, he or she can launch the user interface for the scheduler by clicking on the appointment scheduler button 1324. This brings the user to another 25 screen used for the scheduler.
The "return to examination" button 1310 is a navigational control that allows the user to retum to the main medical exam screen shown in Fig. 4. The "hospitalize patient" button is used to navigate to another screen to checl; thepatient into the hospital and change the status of the patient to "hospitalized."

IRl-lJab56~ 18670 ~ ~ 5 - E~press~lailNo.E~ 9~148~51US

~ rom the exam room check out screen 1300, the user can also issue an instruction to print an invoice of all the chargeable items provided during the visit. As products and services are provided during the visit, the provider teamenters them. The server updates the status attributes in the patient's data base and 5 also keeps a running list of the chargeable items in a separate invoice table. When a user instructs the client to print an invoice, the client computer sends a message to the server, which in turn, initiates a print process on the receptionist computer.
The invoice is then printed at the printer in the receptionist area.
Once the user enters an appointment or notes that no appointment is 10 necessary viathe button 1322, the "See CSC" button 1308 becomes active (CSC
means ('ustomer Service Consultant). -i-his button allows the user to navigate to the "Reception" screen sho~ n in Fig. 14. When the user clicl;s on this button I ~08, the status of the patient changes to "checl;ing-out."
A user, typically the customer service consultant at the reception 15 computer, checl;s a patient out of the facility at the reception desk screen 1400 sho~-n in Fig. 14. This screen shows the patient's banner 1402, a list of check buttons 14W for controlling the display, a box for viewing patient status 14()6. and another box for viewing the status ofthe exam rooms 1408. The checi; buttons 1404 enable the user to control which patient status data is displayed in the box 20 1406. F or example, if the user selects the button labeled "Entire hospital," box 1~06 displays the status of patients in the entire hospital. If the user selects the button labeled "scheduled," the box 1406 only displays patients that are scheduled.
The reception screen also enables a user to check the status of patients in the medicai exam rooms. The user can select (e.g., double-clici; on) a 25 patient name from the lower box 1408 to display the status ofthe patient in an exam room, including a description of the service category (e.g., preventative care), the service description (e.g., vaccination), the time that the patient was checl;ed into the exam room, and the elapsed time that the patient has spent in the exam room.

J~Uj~b ,67,~670 ~ 3 6 - E~press l\~lai I No. EM 7951 4~ 751 US

During the check out process, the receptionist returns any items left at the hospital, as reflected on a patient check in screen, which is accessible from a patient drop down menu at any time during operation of the system. The receptionist receives or confirms some form of payment and then checks the S patient out of the hospital by selecting a checl~ out option on the screen. When the receptionist checks the patient out, the patient's visit is over and the status of the patient is updated to reflect that the patient is checked out. At this point, the system discontinues tracl~ing the time spent in the hospital.
Wellness Plan Soft~ arc rhe software for managino a health care practice described above interacts with additional software components that manage welllless plans for patients. In the following sections, we describe an implementation of wellness plan softwar- integrated with the veterinary practice management software above.
While cur description is specific to wellness plans for pets, the software could be 5 applied to wellness plans for humans as uell.
33efore describing the software in detail, it is useful to provide an overvie.v of its operation. The wellness plan soR~vare enables a user to select fror among 1.~YO or more pre-defined wellness plans. Each of these plans has a numberof product and service items associated ~-ith it. Some plans have additional 2 0 options in addition to standard options that the client can select. ~or example, the client can select additional wellness plan optional items such as spay, neuter, hip dysplasia, etc. on puppy/kitten plans. Once the user has selected a plan and anyplan options, the user is prompted for billing inforlnatioll used to administer the plan. The user is also asked to confirm acceptance of the plan. Upon acceptance,25 the software schedules patient visits and establishes a set of service or product items that the patient is entitled to under the selected plan.
During patient visits, the wellness plan software operates in conjuncl:ion with the software that guides the hospital's provider team throug7h an office ~ isit. The wellness plan sof'tware deterrnines which product and service Vjab~6~ 670 - 37 - E~;press L~lail ~'o. E;\1~9~148~1US

items provided to the patient are subject to a discount under the wellness plan. It also generates cost estimates of the savings provided by the wellness plan.
The wellness plan software also tracks provider team actions associated with the promotion of wellness plans. By trac}~ing promotional efforts S in this manner, the soft~,vaTe can determine bonuses for employees as an incentive to educate clients about the plan and increase wellness plan enrollments.
The implementation ofthe wellness plan software includes the following principal components:
I ) a wellness plan designer component running on the hospital 10 computer system or networl;
2) a local wellness plan administrator component running on the hospital computer system or networli; and 3) a central wellness plan administrator component running-on a remote computer.
I ~ The software for the hospital computer networl; is designed accordingto a client server model. Components I and 2 above run on client computers and aserver computer is used to maintain data and to enable resource sharing among the client computers linl;ed to the server via the netuork.
This software architecture is designed to allou for central 20 administration of wellness plans for a number of different hospitals. The central administrator software runs on the central computer and manages the wellness plans for a number of different hospitals around the country. In the current implementation, the central administrator obtains selected files from the servercomputers located at hospital locaiions. These selectèd files include billing 2~ information used to administer payment for the wellness plans, accounting information to generate a variety of reports to track financial information associated with the plans, and employee data used to compute bonuses for promoting the wellness plans.
The local wellness plan administrator software runs on the server and 30 one or more other computers on the netuorks installed in the hospitals. One part of JR~LJ~b j6?5-18670 - ~ - E~press ~lail i~lo. E~ 9514~1US

this software is conventional communication software that is used to dial up thecentral computer and transfer copies of database files associated with the wellness plans. Since the wellness plan software is integrated ~,vith the medical management software described above, there is no distinction beh~een this communication 5 soft~,vare and the software used to transfer medical records to the central computer.
Another part of the software is the software used to tracl~ and compute plan discounts and to track promotional activities of empl~yees. These and additionalfeatures are detailed below.
The wellness plan designer component runs on the server and one or I () more other computers on the networ~s installed at t,he hospilals. This part of the system h? used to display promotional and educational information about plans and to handle the process of setting~ up new wellness plan contracts. The designer also has an appointment scheduling component that is used to schedule appointments t'or patie:nts under the wellness plans.
The wellness plan software is implemented as an extension to the medical management soft~,vare described above. The medical management wellness plan software is a database application implemented in the Fo:;Pro development environment. Though not required, most hospitals adhere to a client server m~del where a database client application runs on the user's computer andthe data~ase server application runs on the server computer. Li~;e the medical management software, the wellness plan software is V~Titten in FoxPro for the Windows operating system and uses native Fo~;Pro database file structures. To simplify the discussion, we refer to the client database software as client software and the database server application soft~vare as server software.
While a typical hospital will have a networ~; configuration and employ software in the client-server architecture, it is also possible to implement the funct;.ons of the client and server components on a single computer in smallhospitals that do not have a coMputer networl;.
The wellness plan sottuare running at a hospital networl; is integrated with the medical management sottware. ~i(g. 15 is a screen diagram J'~M~'j~b ~6~ 8670 - 39 - E.~press ~lail No. Ei~f'95 1 I Q7"~ 1 US

1500 illustrating a drop-do~n menu 1502 used to access wellness plan software from within the medical management software The option listed as "Wellness Plan..." 1504 is used to open a screen entitled "~/ellness Control Center," a user interface that educates clients about wellness plans and helps them select a plan.
S The option listed as "(~rder WP Items..." 1506 is used to control the use of wellness plan service or product items. Each of these features are addressed further below.
~racking Wellness Pla~l O~servn~io~zs The wellness plan software at a hospital trac}~s events associated ~ith wellness plans in order to keep records of promotional activities of provider team iC members. The software records these events in ~wo ways: I) automatically in respons; to a provider action associated Wittl a wellness plan; or 2) in response to an explicit entry of a wellness plan observation. An example of the first way ofrecording an event is when the user invol;es "selling screens" to give a client a present~tion about wellness plans. This event is recorded automatically ~vhen the 15 user selects the wellness plan "selling screens " In this case, the event is attributed io the user that is currently logged into the client computer. An example of thesecond way of recording an event is in a dialog box 2hat is designed to prompt the user tor user IL:) information to record an observation. The dialog hox; ~an be triggered explicitly in response to an e~plicit request to display the dialoo box or 20 automatically when the user invol;es the wellness plan software. For e~;ample, in the current implementation, a user can cause the client computer to display the dialog box by pressing a special control t~ey (e.g., F9).
The dialog box appears automatically when a user selects the wellness plan software. For instance, when a user selects the "Wellness Plan..."25 option, the local wellness plan software running on the computer presents a dialog box to record a wellness plan observation. An example of this dialog bo:; is shown in Fig. 16. As illustrated in Fig. 16, the dialog box 1600 includes text bo:;es to record the client and patient names as well as the user ID of the provider team member that is currently worl~ing with the patient (1602-1606).

IR~L'jab ~6~-18670 - 40 - E~press Mail No. EM~9~ 148~51 US
When the wellness plan software captures an automatic observation or an observation entered at the dialog bo~, it keeps a record of the event. In respons,- to the user clicking the OK button 1608 in the dialog bo~, for example, the client software running on the computer creates a data record indicating the5 clinic, employee ID, customer (also referred to as the client), pet, date and time.
The client sends the data record to the server where it is stored as a new entry in a bonus observation table.
Selec~in~, n Wellness Pla~l To select a wellness plan, the user begins by selecting the "Wellness 10 Plan..." option 1504 from the drop down menu of Fig. I ~. After the wellness plan observalion is recorded, the client displays a Wellness Control Center window asshown in Fig. 17. The control center winclow 1700 displays the patient banner 1702, a -te~;t bo~; for listing the plan, a series ofte~;t bo~;es sho-~ing plan statistics (170~-1714), and a variety of control buttons (1720-1728). The control center I i win~low displays the minimum annual sa~ings 1706, dail,~ in~estment 1708, one time membership fee ] 710, monthly in~ estment 1712, and the additional monthly investment for the next higher plan level 1714. Tlle identity of the current plan is obtained from a Wellness Plan Contract file for the client and patient that the user has selected. For example, in Fig. 17, the currently selected client and pet are20 illustrated in the patient banner 1702. This particular pet is not enrolled in a wellness plan yet, so the current plan text bo~; 1704 displays "none."
From the control center, the user can initiate the display of educational and promotional inforrnation about wellness plans. For e~;ample, thevideo button 1720 invokes a program to show videos about wellness plans relevant2~ to the pet. The benefits button 1722 cause the client software to display a series of screens that explain the benefits of wellness plans.
The graph button 1724 sho-~is a chart of the service and product items associated with different wellness plans. Fig. 18 is a screen diagram 1800 il lustrating an e:;ample of this type of chart. Along the left hand column, the chart ~0 1800 shcws a list of service items 1802. Each plan has a bar graph (1804- 1818) JRI~Vj;~b~6''-~670 - 41 - E:;press l~lail No. E;~1~9~14S~IUS

that indicates which of the product and service items are covered under the respective plans. The chart also displays the additional discounts 1812 associated with the plans.
When the user chooses the "select plan" button 1726 from the control center window of Fig. 17, the client software displays a Wellness plan designer window. An example of this window 1900 is shown h1 Fig. 19. The top portion of the window 1902 shows the patient banner. The left portion 1904 of the this windo~v shows a text box 1906 listing the type of plan and a chec~ list 190~ forselecting the level of plan. The right portion 1908 of the window shows a number10 oftext boxes (1910-1914) for displaying fees associated with the plan type and level. The lower right portion 1920 displays figures to indicate the plan value 192~, minimum savings under the plan 1924 and per day cost 1926. These ~alues , re assi ~ned to the wellness plan when the plan is created at the central facility.
If the client wishes to accept the plan, the user then selects the "plan l~ accepted" button 19~0 on the lower left portion ofthe display. This causes the client soi'tware to add an entry in the patient's medical record indicating that the patient is on a wellness plan. In response to the user selecting the "plan accepted"
button~ a wellness plan contract record is created on the server that reflects the terms of the agreement, and is set as tentative until the contracting process is20 finalized. In this particular implementation, the process is finalized when the client signs and pays for the contract as e~cplained below.
After selecting the plan via the "plan accepted" button 1930, the user then completes the plan acceptance procedure by selecting "Client to Invoice" from the client drop down menu (see Fig. 15, for an example of the drop dou-n menu).
2~ By selecting the "Client to Invoice" option, the user causes the system to display a Wellness Plan Agreement Acceptance ~vindo~lv. Fig. 20 illustrates an example of this window 2000. As shoun in Fig. 20, the user can select a payment plan (full payment or installment plan via checl; buttons 2002-200~ and list bo~ 2006), enter credit card information or banli inrormation via text bo~es 2008-~0~0, and enter30 client address information for billing purposes 20~ 0~6.

JR~ b j6~S670 - 42 - E.~press jvlail No. Ei~ 9~14~51US

After entering this information, the user can then print the ~vellness plan contract by selecting the "Print Agreement" button 2040. Once the client has signed the agreement, the user then selects the "Agreement Endorsed" button 204~.
If the client changes his~her mind, the user can cancel the agreement by selecting 5 the "cancel all" button 2044. By selecting the cancel all button, the user causes the client software to re-compute the invoice for any product or service items for the current visit to reflect that the patient is not on a wellness plan.
When a wellness plan agreement is endorsed. the tentative contract record that has already been created is updated to ref~ect the payment terms and to I 1~ indicate that the contract is final, as opposed to being merely tentative. The contract records are stored in a ~ellness Plan Contract table on the server and include ~m indicator ofthe clinic, client, patient, level of plan, date initiated, initiation amount, number of payments, payment starting date, and payment amount. Additional items stored in a wellness plan contract record can include pavment method preference, chec~ing account bank number, check.ng account number, credit card number, and credit card expiration. At plan endorsement, thepatient record on the server is also updated to reflect that the tentative agreement has been initiated.
When a contract is created, the client software causes the server to 2() set-up a Wellness Plan Item table to store a list of wellness plan service and product items associated with the selected plan level and type. The server retrieves this list from a wellness plan table. The records in the Wellness Plan Item table are assigned an initial status of open/to-do and are flagged as being part of a wellness plan. These records also include the regular price for the item so that the wellness 25 plan software can estimate cost savings for comparison during invoicing at patient visits. During a patient visit, an Accounting Sales Line Item table is established to track product and service items provided to a patient during a visit. To estimatc plan discounts during a visit and compute the invoice, the accounting sales lineitems for the visit are matched against the wellness plan items on a case by casc JRM,'j:lb567~ 670 - 43 - E.~press i~lail ~;o. E~ 9~1~8~1IJS

basis to determine whether items provided during a visit are covered by the wellness plan and whether an item has not yet been provided.
The ~vellness plan item table stores an un-discounted retail value with each service item in the table so that the production of a provider team member,5 e.g., a doctor, can be computed based on the retail value.
(~nce a wellness plan is created, the discounts available under the plan are available immediately. Before the wellness plan item records are created, the server examines the accounting sales line item records associated ~,vith thecurrent -~ isit. Wellness plan pricing and service items covered under the plan are 10 applied to the items provided during the current visit. This may include ma~ing the offic,- visit/physical e~;am fee zero. This may also include discounting theitenls that were provided during the current visit, which are not specifically .wellness plan service or product items. The wellness plan items applied to the ;:urrent visit are not removed from the wellness plan item table made for the plan, I~ but instead are flagged as consumed.
During a visit, the user can select wellness plan product or service items that the client wants to apply to the current visit. The drop down menu 1507 of Fi~,. 15 has an option called "Order WP items" 1506. When the user selects this option, the client software displays a windo~v listing welltless plan product and 20 service items for the current patient. Only the wellness plan items which are not flagged as consumed are displayed in this window. This list is created from the Wellness Plan Item table for the patient.
~ ig. 21 illustrates an example of a display window 2100 that displays wellness plan items. This window includes a "select from" bo:c 2102, listing the25 wellness plan product and service items to select from, and a "selection" bo~; 2104, listing any selected items. rhe user selects items using the "select" and "select all"
buttons 2106, 210~, and the user de-selects items using the "de-select" and "de-select all" 2110, 2112 list. Wellness plan items that have already been provided are flagged so that they are not displayed in the "select from" box 2107.
30 When the user selects a wellness plan item and clic};s "OK," the software causes ~ ,y~b ~6~ s670 - 4~ - E:~press l~lai l No. E~ 9~145~1 US

accounti.ng sales line item records to be created in an Accounting Sales Line Item table on the server for each of the wellness plan items selected.

Sc~ledulin~, OfJ~ce Visits When the wellness plan contract is endorsed, the server automatically schedules preventative care appointments for the patient. In the current implementation, the server determines the number of appointments that need to becreated by checking the Wellness Plan Contract table associated with the selected plan. The server creates appointment records for two appointments per year.
10 ~ppointment records are stored with the patient's recnrds and indicate the lime and date of the appointment. A pre-selected list of wellness plan service items are associated with each visit. This list of items is defined in a lable used to store detaiis for each wellness plan, called the Wellness Plan Details table. The Wellnes~ Plan Details table lists the service items associated with wellness plan 15 v isits and other plan details, such as plan pricing and a list of items covered by thc-plan. More information on the Wellness Plan Details table is provided belo-v.
The provider team can re-assign w-ellness plan items among the scheduled visits by selecting the desired service items for a v isit ~ith the welllless plan order feature e:;plained above and illustrated in Fig. 21.
Fig. 2~ illustrates an e,~:ample of a display screen 2~00 sho~ving scheduled appointments immediately after a client has endorsed a wellness plan.
This window includes a patient banner 220~ for the current patient and client and a bo~c 220 ~ listing scheduled appointments and several attributes associated with the scheduled appointments. For e~;ample, this window sho~s the patient name, date of the appointment, and reason for the ~ isit. Note that visits scheduled under a wellness plan are referred to as preventative carc.
The scheduled appointments screen 2200 includes control buttons labeled "Schedule Appointment" ~206 and "Delete Appointment" ~208. When the user selects button 2206, the software displays a scheduler ~indow that enables the ~0 user to manually schedule an appointment. The user can delete an appointment by JR~Vj:lb 56'~ 8670 - 45 - E:~press ~lail No. EM~9~ 14S~5 1 US

selecting an appointment entry displayed in the box ~04 and then selecting the delete appointment button ~08.
The software includes an auto-scheduler that automatically schedules wellness plan appointments in response to a wellness plan contract being finalized.
5 In performing this auto-scheduling function, the software assumes that the first wellness plan appointment is the day that the contract is started. If it is not, then the first appointment is entered manually by the user via an appointment scheduler window The user can access this windo-v by selecting the "Ma}~e Appointment"
option under the "Patient" drop dovvn menu list shown in Fig. 15. Once the first10 appointment is established, the software automaticall~ schedules the next appointrnent. The software is pre-programmed with peal~ and non-peali months. Ituses the peali: and non-pea~ month data and the date of the initial appointment to find a new time and date for the next appointment during a non-peal; month. Lil;e other pla.n administrator software at the medical facility, the scheduler software I S runs on the client computer and stores its data on the server.
Whether scheduled automatically or entered manually by the user, the appointments are stored as records in an appointment file. This file is maintained on the server, and it is also sent periodically to the central computer so that appointment data can be maintained on the central computer as wvell.
~0 Patient visi~s When a client brings a patient to the hospital for a visit, the provider team uses the medical management software described above to tracl; the patient's progress through the visit. In addition, the provider team uses the medical management software to guide it through the medical exam process. As product ~5 and service items are provided, they are recorded in an Accounting Sales Items table created for the visit. The medical management software uses information from the Wellness Plan Item table to estimate cost savings dynamically and to apply wellness plan discounts.

JR~yab j6'j~670 - 46 - E~{press ~[ail No. E~ 9~ 51US

Estimatin~ Cost Savin~s The soRware can dynamically estimate cost savings attributable to a wellness plan as product and service items are selected during a visit. As an example, consider the Estimate window shown in Fig. 11. During an office visit, S product ~md service items that are provided or are scheduled to be provided are added to the Accounting Sales Line Item table. The records in this table includeinformation about each item. including the value under the wellness plan and theregular retail price.
As items are ordered, a member of the provider team updates the 10 status ~r the item to "done," meaning that it has been provided This action causes a new record for the item to be added to the Accounting Sales Line Item table. As items are ordered, the client soRware checl;s the Wellness Plan Item table to see if there is an ur.-used item corresponding to the item that has just been ordered. If there is an un-used item, it adds a record to the Accounting Sales Item table with a I 5 field indicating the appropriate cost under the wellness plan (the actual cost). If there are no un-used items corresponding to the item, it adds a record with a field srlowing Ihat ttle actual cost is the regular price.
Items covered under the wellness plan can be ordered hl this manner or by specifically ordering wellness plan items as described above in connection20 wiIn Fig. 21. The user interface of Fig. 21 is preferred because it enables the user to select -from wellness plan items that are not flagged as consumed.
The soRware updates the cost estimates shown in Fig. 1 1 as the user sclects product and service items. To compute the basic wellness plan estimate 1106. regular fee estimate 1108, and the client's estimate 11 10, the soRware totals 25 the wellness plan, regular fee and actual prices from corresponding pricing fields in the records in the Accounting Sales Item table for the current visit. Note, as an alternative, the software can also compute cost savings by summing the difference between Ihe actual and retail price fields for each of the records in the Accounting Sales Itern Table.

JR~ b j6~ 670 - 47 - E:~;press ~lail No. EM~9~ 14~1 US

Applving Wellness Plan Discounts The software computes a final invoice in a similar fashion as the cost estimates described above. Specifically, it sums the pricing information in the pricing fields of the accounting sales line item records. In addition to computing S the invoice amount and wellness plan amounts, the software flags items that have been pn~vided as being consumed, and stores a linl~ from items in the AccountingSalts Item table to the Wellness Plan Item table. This link enables users to easily verify that wellness plan service items have been provided.
ess Plntl 5~lS
The software provides a way for authorized users to change the status of a patient's wellness plan. From the "management" drop do~n menu 150~
shown in Fig. 15, an authorized user can access a Wellness Plan Maintenance c.isplay screen An e~ample of this screen 2300 is shown in Fig. 23. In c~rcier to access this screen, the user rnust have special access rights associated v~ith his or l 5 her Iog-in. In this implementation, for example, the user must have a System Administrator log-in. . .
The Wellness ~lan Maintenance screen 2300 shows the client name 2302 the patient name 230~, the type of plan 2306, and the status ofthe plan 2308.
The client software automatically fills in this inforrnation based on the patient and 20 client records of the selected patient. In other words, before accessing the screen, the user has already selected the client and patient. Thus, when the user accesses the screen, the client software automatically retrieves the proper data from thepatient's records stored on the server.
If the client has not endorsed the plan, the status ofthe plan is listed 25 as tentative. This feature is implementecl by flagging the patient's file ~ith the wellness plan information and the tentative status when the plan is selected. The wellness plan status is updated to active wtlen the wellness plan is actually endorsecl as described abovc.
To change inforrnation about thc plan. the user can click on the "edit"
30 button 2:310 and then mal;e the desired changes. ~or c~amplc~ the user can change J~y~b 56~ 8670 - 48 - E.~press ~lail No E~ 9~ 148~51 US

the stahls of the wellness plan from tentative to canceled by selecting the "canceled" status from the Contract Status list box 2308. The user can also select automatic renewal in the "Automatic Renewal" check buttons 2312-2314 displayed in the window.
To save the changes, the user selects the "Save" button 2316. In response, the client software sends a message to the server to update the patient files stored on the server. These files include the Wellness Plan Contract file and the patient file. The client file is not updated for wellness plan activity, as the client may have one pet covered and another pet not covered by a wellness plan.
The Wellness plan maintenance screen 2300 also includes a data link bo~ ~320 that includes a check bo~ that the user can select to instruct the client soft~ are to refer to the customer data (in this case the customer is Terrie Maas as sho~n in bo~; 2302) rather than the contract purchaser data. This is useful in cases ~vhere the purchaser is different than the client. The client is usually the pet owner.
I ~ ~ile MairlterJance on tlte Central Computer and tlte Server The server at eac}i hospital maintains several database files that are relevant to the operation of the vlellness plan soft~ are. The follo-ving ta.bleprovides a list ofthese files and the fields contained in them. A file. in this implementation, refers to a relational database table. Each table includes a number of records corresponding to rows in the table. Each record has one or more fields corresponding to columns in the table. ~ link is an identifier stored in a field of a record that uniquely identifies a table related to that record.

JR~4Lj~b ~6~8670 - 49 - E~press ~lail No. EM29~ 1482~1 US

File Fields Comments Wellness Plan Contract Title of plan; This file defines the terms of Definition Payment Tenns; a wellness plan as established Averaoe Daily Cost; by the plan administrator.
Avera ,e Daily Savin~s; There is a file for each Monthly Payment. wellness plan. The central - computer maintains copies of these files and also sends copies to the server at each hospital.
Wellness Plan Detail Link to Wellness Plan Each of the records in the Contract Definition Table; table relate to items that are Lini; to Inventory Table; provided under the wellness Item Description; plans. These records contain Relative Sales Value; the fields listed here.
Doctor Production Value. "Relative Sales Value" is the uorth assh7ned to an item, not necessarily the retaii price.
The "Doctor Production Value" is the price ofthe item anributed to the sellim~
doctor. To =,et the wellness plan items for a particular plan, the soft~vare relates the plan identiher with this table.
5 Wellness Plan Contract Clinic; This file is updated when a Customer; new contract is endorsed.
Pet; One file is created tor each ~ Plan Level; endorsed contract.
Date Initiated;
Initiation Amount;
Number of Payments;
Payment Startin~ Date;
Payment Amount.
Wellness Plan Items Lini; to Wellness Plan This table includes records Contract File; for each weliness plan item Link to Patient Table; covered under the plan. This Link to Inventory Item; table is created for each Value of how much of the wellness plan.
wellness plan contract has been delivered/still owed to the client.
Client Name; Thistable includes records Address; for clients. Each record (possibly other client contact includes felds containin~
information). c I ient contact infonmation such as the client's name and address.

JR~ b56~5-~5670 - 50 - E~press l\/lail No. E~ 9~148~1US

File Fields Comments Patient (Pets) Name of Breed; A patient file includes patient Species; records. Eact1 patient record Se.~;; has a number of fields that A~e; provide inforrnation about a Birth date; patient such as the attributes Wellness Plan Flao; showll here. In addition, the Wellness Plan Level; file includes a Wellness plan Plan F~;piration Date. indicatin, whether the pet is on a plan.
Bonus C)bservation Clinic; This file is updated when a Employee; wellness plan event occurs.
Customer;
Pet;
Date;
Time.
Bonuses Recorded Employee Palient Name; This file is ~eneraled and Patient; maintained on the central Linl; to Wellness Plan; computer. It is computed in Contract File for the patient; the process of generatin~ a Date Paid; pa~roll report forspecifying Amount of Bonus (dollars). err.ployee bonus information to the pay roll system.
Inventorv Item Name; This table is used to maintain Description; information about product ~etail Price; and service itcms provi~led at Ac~luisition Cost: a clinic.
Method of Administra~ion;
Species Specihc Inforrnation.
5 Accountlng Sales Line Item Item Name; This table is created durin~ a Retail Price; patient visit to l;eep tracl; of Actual Charge to Client; product and service items that Wellness Plan Value; are either provided or Doctor Production Value; scheduled to be provided ("to Item Status (Uto do, or do" status) durin~ the visit.
"done~); This table, alon~, with the Linl; to Wellness Plan wellness plan item table, is Contract File; used to compute an invoice Linli to Patient Table; for an office visit.
Linl; to Inventory Item.

The server computer at each hospital sends a copy of each ofthese files to the central computer on a periodic basis (e.g., daily). The central wellness plan administrator maintains a set of these files for all of the hospitals that it 10 manages. When the central wellness plan administrator receives these files, il adds JR~I/jab ~ S670 - 51 - E.l~press ,~lail No. Ei~1'9~ 14S~5 1 US

new records in its files for new plans and updates records based on changes recorded at the hospitals.
The central wellness plan administrator performs a variety of functions relating to the management of wellness plans, including:
1) Computation of Wellness Plan Bonuses;
2) Preparation of Payment files; and ~) Report Generation.
The central wellness plan administrator computes employee bonuses based on the wellness plan observations recorded at the hospitals and uploaded to the central computer. This feature is explained in more detail below.
The central ~vellness plan administrator analyzes the billing hlformation uploaded from the hospitals and creates the files necessary to obtain payments from a client's bank account or credit carcl. Specifically, it creates payment files and submits thern electronically to the bank. The bank mal;es all of I 5 the individual charges, including both credit card charges and account debits, and makes the deposit directly into the plan administrator's account.
Because the central compuler captures and maintainj inforrnation about the wellness plans from each hospital7 it is able to generate a variety ofreports. Some examples of these reports include employee earnings, current and >O deferred earnings (revenue report per hospital, initiation fees earned per hospital, cash received, deferred revenue, contracts valuation, cash projection, etc.), customer contracts report, expired credit cards, returned payments, renewal notices, expiring contracts, etc. The precise nature of these reports is not particularlycritical to the invention, so a detailed description ofthem is omitted.
~mployee Bonl(ses There are two principal aspects to determining employee bonuses associated with the promotion of wellness plans. ~irst, as explained above, the system tracks wellness plan observations and keeps a record of them. Second, therecorded observations are evaluated to compute the bonuses due each member of the provider team.

Ljab~6 j-~8670 -5~- E:~pressMailNo EM''95145''51US

As explained above, the central wellness plan administrator obtains the bonus observation file from the hospital. On a periodic basis, the ~(lmini.~trator analyzes this file and calculates employee bonuses attributable to promotion of wellness plans. The administrator computes the bonuses as follows. The 5 administrator analy~es the bonus observation file to produce a list of bonus observations for patients associated with new wellness plan contracts. This list is filtered further so that there is at most one observation per employee for each new contract. The bonus amount for the wellness plan are computed based on the levelofthe wellness plans:
10 Level 1=10 Level 2=~0 Level 3=30 Level 4=40 The administrator applies bonuses equally to the last 4 instances of 15 client contacts, e~;cluding duplicates. If there are fewer then 4 client contacts after duplicates are removed, then the bonuses are applied equally to these client contacts. The administrator computes a bonus per employee by dividing the bonus amount by the number of non-duplicate c:lient contacts. It then prepares a report listing the bonuses per employee for entry into a payroll system.
Conclusion While we have described the invention with reference to a specific implementation, we do not intend to limit the scope of the invention to this implementation. The system can be implemented in a client-server configuration, 25 or in a single computer. In the latter case, both the client and server functions are pert'ormed on the same computer and the tables are maintained on this computer, rather than a remote server. The specific display format of the user interface screens can vary as well.
In view of the many possible embodiments to ~vhich the principles of 30 our invention may be applied, it should be recognized that thc illustrated JR~jnb ~6~ 670 - 53 - E~press ~vlail No. EM~95 148251 US

embodiment is only a preferred e~ample of the in~ention and should not be taken as a limitation on the scope of the invention. Rather, the scope of the invention is defined by the following claims. We therefore claim as our invention all that comes within the scope and spirit of these claims.

Claims (11)

1. A computer implemented method for managing a wellness plan comprising:
maintaining a list of wellness plan items associated with a wellness plan for a patient;
displaying a user interface for enabling a user to select among product or service items;
in response to receiving an entry of a selected product or service item in the user interface, recording the selected entry;
computing an invoice for a patient visit, checking whether the selected entry is in the wellness plan items, and if so, discounting the selected entry.

2. The method of claim 1 further including:
displaying a user interface enabling a user to select a wellness plan for a patient from among two or more wellness plan options displayed to the user, where each of the wellness plan options is associated with a set of wellness plan items; and in response to a user selecting one of the wellness plan options, creating a record of the set of wellness plan items associated with the selectedwellness plan option for the patient.

3. The method of claim 1 wherein the user interface for managing a patient visit includes a series of display screens that guide the user through amedical exam and enable the user to select from among the product or service items.

4. The method of claim 1 further including:
computing a cost estimate of selected product or services items entered during the patient visit; and displaying an indicator of cost savings for the products or service items attributable to the wellness plan.

5. The method of claim 1 further including:
automatically scheduling patient visits for the patient covered by the wellness plan.

6. The method of claim 1 further including:
in response to a program action associated with promotion of a wellness plan, recording an event including a provider identifier indicating a provider associated with the event; and evaluating, events to determine bonuses for providers.

7. The method of claim 6 wherein the program action comprises entry of an observation related to a wellness plan.

8. A computer readable medium having instructions for performing the steps of claim 1.

9. A wellness plan management system comprising:
a medical facility computer having a user interface for enabling a client to enter billing information and to select a wellness plan from among two or more wellness plans, each having a set of predetermined wellness plan items, theuser interface further including an interactive display for selecting product orservice items provided to a patient during a visit; the medical facility computer being programmed to record selected product or service items provided to the patient and to compare predetermined wellness plan items with the selected itemsto determine a wellness plan discount; and a remote computer in communication with the medical facility computer for obtaining the billing information and for automatically billing clients that have selected a wellness plan.

10. The system of claim 9 wherein the medical facility computer is programmed to estimate cost savings for the selected product and service items due under a wellness plan associated with the patient and is programmed to display the cost savings.

11. The system of claim 9 wherein the medical facility computer is programmed to record events associated with a promotional activity of the wellness plans, wherein the events identify an employee responsible for the promotional activity and are evaluated to compute employee bonuses.