WO2001063417A2

WO2001063417A2 - System and method for integrating a software application with a handheld computer

Info

Publication number: WO2001063417A2
Application number: PCT/US2001/006024
Authority: WO
Inventors: Larry A. Greenspan; Steve Mallot; Bob Wardwell
Original assignee: Softdent, Llc
Priority date: 2000-02-23
Filing date: 2001-02-23
Publication date: 2001-08-30
Also published as: AU2001241748A1; WO2001063417A3

Abstract

Information from a healthcare or dental practice application executing on a desktop computer is synchronized with information on a handheld computing device. The healthcare information from the healthcare practice application is adapted for storage in existing fields of an appropriate pre-installed application of the handheld computing device. In addition, the intended use of other fields in the appropriate application can be altered to accommodate healthcare related information. The healthcare information is preferably separated from the other information stored in the appropriate application to permit a user to quickly access the healthcare information. A separate application can be loaded onto the handheld computing device to permit a user to directly access the healthcare information. A special set of commands entered in the handheld computing device can be used when the synchronization process is started to direct the healthcare desktop application to start a process, take an action, or direct or alert a user to take action.

Description

SYSTEM AND METHOD FOR INTEGRATING A

SOFTWARE APPLICATION WITH A HANDHELD

COMPUTER

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application No. 60/184,311 filed on February 23, 2000.

BACKGROUND OF THE INVENTION

The present invention is related generally to the field of portable or handheld computing devices. Specifically, the present invention is related to a method and system for integrating a healthcare management software application with applications on a handheld computing device.

Many handheld or portable computing devices have emerged that have enabled people to take important information stored on a desktop or personal computer, which is typically located in the person's home or office, with them when they are away from the home or office. Additionally, people can enter notes and other important information into the handheld computing device when they are away from the home or office and then subsequently transfer the information back to the desktop computer at a later time. This transferring of information between the handheld computing device and the desktop computer is usually called synchronization.

One example of how the information between a handheld computing device and a desktop computer can be synchronized is illustrated in U.S. Patent No. 6,000,000 to Hawkins et al., which is incorporated herein by reference. In Hawkins, a communication link between the handheld computing device and the desktop computer is established to transfer the information. Usually, this communication link is established through a serial connection between the handheld computer and the desktop computer. Once the communication link between the handheld computing device and the desktop computer has been established, a hotsync program is used to control the synchronization process. The hotsync program will then sequentially load and execute a series of conduit libraries to synchronize the information between the handheld computing device and the desktop computer and to perform other related tasks. A conduit library must be present for each application on the desktop computer that needs to synchronize data with an application on the handheld device, otherwise the application on the desktop computer will not be able to synchronize information with the handheld computer.

To synchronize the information, the conduit library will first read data from databases on both the desktop computer and the handheld computing device. Next, the conduit library will compare and reconcile the data from the handheld computing device with the desktop computer. Finally, the reconciled data is written back to databases on both the handheld computing device and the desktop computer, thereby providing both the handheld computing device and the desktop computer with the same information.

One type of information that can be synchronized between a handheld computing device and a desktop computer is healthcare information stored on the desktop computer. The healthcare professional may need to have access to healthcare information while away from the desktop computer for a variety of different reasons. One reason for needing remote access to healthcare information can be that a patient calls the healthcare professional seeking healthcare advice or treatment when the office is closed. The healthcare professional can then access the healthcare information on the handheld computing device in order to provide advice or treatment to the patient. However, to synchronize the healthcare information, a conduit library must be present that is capable of handling healthcare information and an application on the handheld computing device must also be present that can handle healthcare information. If there is no conduit library or application on the handheld computing device that can handle healthcare information, the healthcare information cannot be synchronized between the desktop computer and the handheld computing device.

Furthermore, the synchronization process frequently has very few procedures or options to set security levels for the information. If an unknown user attempts to synchronize data, the synchronization process will not prevent him from synchronizing data, but only require that the user be registered. While this type of security may be acceptable for individuals and certain businesses, people working with healthcare information require additional security measures. The highly sensitive information involved in the healthcare industry requires extra levels of security and confidentiality to be maintained.

Therefore, what is needed is a synchronization technique for healthcare information that is able to quickly and easily transfer healthcare information between a desktop computer and handheld computing device while maintaining the security of the healthcare information.

SUMMARY OF THE INVENTION

One embodiment of the present invention is directed to a system and method for synchronizing information from a healthcare or dental practice application executing on the desktop computer with information in a handheld computing device. The information from the healthcare application is synchronized with information in the applications on the handheld computing device. The healthcare information can be preferably adapted to be stored in the existing fields of the appropriate application. In addition, the intended use of other fields in the application may be altered to accommodate healthcare related information. The healthcare information is preferably separated from the other information stored in the application to permit a user to quickly access the healthcare information. In addition, a separate application may be loaded onto the handheld computing device to permit a user to directly access the healthcare information.

When synchronizing information from the handheld computing device to the healthcare desktop application, normally, data collected or input into the handheld computing device directly replaces the corresponding data on the desktop application. However, in another preferred embodiment of the present invention, a special set of commands is used to direct the healthcare desktop application to do more than just replace data. The special set of commands may start a process, take an action, or direct or alert a user to take action. hi another preferred embodiment of the present invention, additional security features may be implemented in the healthcare application to control access to the information in the healthcare application. One security feature that can be implemented is that only certain predetermined users will be able to synchronize data with the healthcare application. Another security feature is that users who are synchronizing with the healthcare application may be given access to only certain records. In addition, a user may be required to login to the healthcare application every time synchronization is attempted. Finally, information transferred to the handheld computing device can be indicated as private and require a password to view.

One embodiment of the present invention is directed to a method for transferring healthcare related data between a healthcare application loaded on a computer and a handheld computer having a plurality of pre-installed applications. The method includes executing a synchronization program to facilitate transferring data between the healthcare application and the handheld computer and loading a copy of the healthcare application into a memory device of the computer and executing the copy of the healthcare application as a background application. The method also includes retrieving predetermined healthcare information from the copy of the healthcare application, transferring the predetermined healthcare information to the handheld computer and storing the predetermined healthcare information into a corresponding pre-installed application on the handheld computer.

One advantage of the present invention is that a general handheld computing device is transformed into a healthcare specific computing tool, for use in medical or dental disciplines.

Another advantage of the present invention is that the special set of commands used to direct the healthcare desktop application provides a powerful and simple technique for specifying changes in the healthcare desktop application.

Other features and advantages of the present invention will be apparent from the following more detailed description of the preferred embodiment, taken in conjunction with the accompanying drawings which illustrate, by way of example, the principles of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates the handheld computing device and the desktop computer.

Figures 2A and 2B illustrate the process for synchronizing information between the handheld computing device and a practice management application.

Figure 3 illustrates an interface for an administrator to control what information a user can synchronize with a handheld computing device.

Figure 4 illustrates an interface for a user to customize what information is synchronized with a handheld computing device.

Figure 5 illustrates the process for user authentication during the synchronization process.

Figure 6 illustrates an interface for an administrator to configure other security features that are applied to a user during the synchronization process.

Figure 7 illustrates the process for controlling the transfer of information to a user during the synchronization process.

Figure 8 illustrates a sample audit trail.

Figure 9 illustrates the exchange of information between the desktop computer and handheld computing device.

Figure 10 illustrates the basic process of integrating a healthcare application with a handheld computing device.

Figure 11 illustrates a conceptual overview of the security model for using a handheld computing device with healthcare information.

Figure 12 illustrates a conceptual overview of the process for converting a general handheld computing device to a healthcare specific computing device. Whenever possible, the same reference numbers will be used throughout the figures

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

One embodiment of the present invention is illustrated in Figure 1. In Figure 1, a handheld, palmtop or portable computing device 101 is shown. The handheld computing device 101 preferably has an operating system for controlling the handheld computing device 101, at least one memory device to store information and applications, a touch/display screen 104 that can be used for viewing and entering information and making selections, and pushbuttons or similar devices for entering information and selections. The operating system of the handheld computing device 101 is preferably PalmOS, Windows CE or any other similar type of operating system for a handheld computing device 101. The handheld or personal computing device 101 has a number of applications saved in the memory or storage device included with the personal computing device 101 that are of value to the user of the handheld computing device 101. Preferably, the handheld computing device 101 has a number of frequently used applications for the user pre-installed on the handheld computing device 101. Some examples of applications that are usually pre- installed on a handheld computing device 101 are an address book application 106, a memo pad application 105, a calendar or date book application 107, a calculator application 109, an electronic mail application 108 and any other similar type of application that a user frequently accesses during normal operation of the handheld computing device 101. Additionally, the user can save or install additional applications on the handheld computing device 101 to satisfy the user's specific needs for the handheld computing device 101. The applications saved on the handheld computing device 101 can permit the user to access, from any location, the applications and any associated information saved in the personal computing device 101. One way for a user to access the applications and information saved in the handheld computing device 101 is to select an application icon 105-109 associated with the application that is displayed on the display screen 104. In addition, there can be other ways for the user to access the applications and information stored in the handheld computing device 101, such as accessing the application through a series of menus.

Additionally illustrated in Figure 1 is a desktop or personal computer 102. The desktop or personal computer 102 can be any type of general purpose computer having memory or storage devices (e.g. RAM, ROM, hard disk, CD- ROM, etc.), processing units (e.g. CPU, ALU, etc.) and input/output devices (e.g. monitor, keyboard, mouse, printer, etc.) and a communications port. The desktop computer 102 can frequently have many of the same applications as those stored on the handheld computing device 101 in addition to many other types of applications. In a preferred embodiment, the desktop computer 102 has a healthcare desktop application that is used for the management of healthcare information. Frequently, a user who has both a handheld computing device 101 and a desktop computer 102 desires to synchronize the handheld computing device 101 and the desktop computer 102 so that the information stored in each device is identical to the information stored in the other device. This synchronization of information between the handheld computing device 101 and the desktop computer 102 is frequently accomplished over a communications link 103.

The communication link 103 is used to connect the handheld computing device 101 and the desktop computer 102 so information or data can be exchanged between the handheld computing device 101 and the desktop computer 102. The communication link 103 is frequently a serial connection between the handheld computing device 101 and the desktop computer 102. However, other types of communication links could be used to transfer information such as a Universal Serial Bus (USB) connection, an IEEE- 1394 or Fire Wire connection, an RF, infrared or other wireless connection, a modem connection or a connection over the Internet.

In a preferred embodiment of the present invention, the healthcare desktop application stored on the desktop computer 102 is a dental practice management application, hi the following description of the preferred embodiments the references to the healthcare desktop application may be in the context of a dental practice management or dental practice application. However, it is to be understood that any healthcare practice management application can be used and the references to dental specific items, e.g. procedures and terms, would be modified or changed to correspond to specific items of the specific field of healthcare that relates to the healthcare practice management application.

The basic process for integrating and synchronizing information in the healthcare desktop application on the desktop computer 102 with a handheld computing device 101 is illustrated in Figure 10. In step 1000, the user begins the process for synchronizing a healthcare desktop application, such as a dental practice software application, with a handheld computing device 101. Next, a synchronizing program or conduit associated with the healthcare desktop application or dental practice application is called and executed to facilitate the synchronizing of data between the healthcare desktop application and the handheld computing device 101.

In the present invention, the conduit utilizes an automation technique to obtain the most accurate and current record information of the healthcare desktop application to synchronize with the handheld computing device 101. Automation is a process whereby a software component makes available some or all of its data and functionality to other independent software components. Automation allows the conduit to control the healthcare desktop application to retrieve the information from the healthcare desktop application that is to be synchronized with the handheld computing device 101. The automation technique permits communication between the conduit and a hidden version of the healthcare desktop application stored on the desktop computer 101. In order to communicate with the hidden version of the healthcare desktop application using the automation technique, the conduit has to load the hidden version of the healthcare desktop application into the memory of the desktop computer in step 1002. In one embodiment of the present invention a hidden or background version of the healthcare desktop application is started regardless of whether or not a version of the healthcare desktop application is executing when the synchronization process is started. In another embodiment of the present invention, if a version of the healthcare desktop application is executing on the desktop computer 102, the conduit will communicate directly with the executing healthcare desktop application and not open a hidden version. The use of the automation technique permits the conduit to use predefined entry points into the healthcare desktop application for the purpose of acquiring healthcare record information. The automation technique is described in detail below with regard to Figure 9.

The first communication between the conduit and the healthcare desktop application occurs in step 1003 during the login validation procedure. The conduit uses the healthcare desktop application to validate the login information provided by the user. The conduit will also use, if necessary, the healthcare desktop application's login screen, and then retrieve the login information from the healthcare desktop application. The login process is described in greater detail below with regard to Figures 5 and 6.

In step 1004, the login information is checked to see if it is valid. If the login attempt is unsuccessful the synchronization process ends and the hidden version of the healthcare desktop application is unloaded in step 1005. If the login attempt is successful, the conduit attempts to synchronize all the healthcare record types and process or execute any commands for the healthcare desktop application in step 1006. In step 1009, the conduit checks to see if a record type is to be synchronized or a command is to be processed. For each command to be processed, the conduit determines the action to be taken and updates the healthcare desktop application or database as appropriate in step 1010. This process is described in greater detail below. Alternatively, for each record type, the conduit will query the healthcare desktop application to check if the user wants to synchronize this record type, and if the user has valid security authorization for this record type. Then, assuming the previous conditions have been satisfied, the healthcare desktop application will retrieve all available healthcare records of the current record type in step 1007, and pass these records to the conduit. This procedure is explained in greater detail below with regard to Figure 7. In step 1008, the conduit will then synchronize the retrieved information with the information on the handheld computing device 101, which is described in greater detail below with regard to Figure 2. At the completion of synchronization of the information in step 1008 or the processing of a command in step 1010, the procedure is repeated for either the next healthcare record type or command at step 1006, until all healthcare record types have synchronized and all commands have been processed, then the synchronization process ends and the hidden version of the healthcare desktop application is unloaded in step 1005. h one preferred embodiment of the present invention, the handheld computing device 101 will preferably have an application or navigation tool related to healthcare or dental practice applications or software stored in memory. The application will permit the user of the handheld computing device 101 to be able to quickly find the information that was synchronized to the handheld computing device 101. The application can have several links or shortcuts that correspond to each type of information that was synchronized. The use of the shortcuts in the application can permit a user to quickly find desired information without having to search through all the records on the handheld computing device 101. In addition, the application can also be used to perform functions related to the healthcare or dental practice field apart from the locating of synchronized information.

Figures 2A and 2B illustrate the steps in synchronizing and integrating healthcare or dental practice management software or applications stored on a desktop computer 102 with the handheld computing device 101. The following description of Figures 2A and 2B describe the transfer of information from the healthcare desktop application to the handheld computing device 101, as well as transferring information collected from the handheld computing device 101 back to the healthcare desktop application. In one embodiment of the present invention, healthcare information is transferred in one direction, from the healthcare desktop application to the handheld computing device 101. However, in another embodiment of the present invention, some data collection of healthcare information can be accomplished with the handheld computing device 101 and then synchronized with the healthcare desktop application.

The synchronization process is begun in step 201. Next, the software or conduit that controls the transfer of information between the healthcare desktop application or dental practice management software and the handheld computing device 101 is called and executed in step 202. In steps 203 and 204, commands entered or issued by the user in the records of the date book application 107 and the address book application 106 that relate to healthcare or dental information of the healthcare desktop application or dental practice management software are parsed and executed. A more detailed description is provided below for the operation and types of commands used in the records of the date book application 107 or the address book application 106.

In step 205, the referring doctor information is synchronized between the handheld computing device 101 and the dental practice management software. The referring doctor information is transferred from the dental practice management application and stored in the address hook application 106 on handheld computing device 101. The referring doctor information transferred from the dental practice management software to the address book application 106 is separated from the remaining address information stored in address book application 106 and is organized into a list of referring doctor information having its own category or group within the address book application 106. The placement of the referring doctor information in a separate category permits a user to have quick and easy access to the dental practice management referring doctor information without having to review other address information. In addition, any new referring doctor information stored in address book application 106 is transferred to the dental practice management software. Furthermore, there are special fields related to referring doctors that are both meaningful and necessary to the practitioner and should be included in the record stored in the address book application 106. These meaningful fields from the dental practice management application, including the number of patients referred in, the date of last patient referred in, the number of patients referred out to, and the date of last patient referred out to, as well as the complete list of patients referred in and out of the practice, have to be formatted to fit in the custom or notes section of the address book application 106. Table 1 illustrates the format of the address book application 106 optimized to include the referring doctor information from the dental practice management software.

Title: Home Phone:

Full Name: Work Phone:

Specialty: # of Patients Referred In:

Street Address: Date of Last Patient Referred In:

City: # of Patients Referred Out to:

State: Date of Last Patient Referred Out to:

Zip Code: Patients Referred In:

Patients Referred Out:

Table 1

In step 206 the memo and reminder information is synchronized between the handheld computing device 101 and the dental practice management software. The memo and reminder information stored in the dental practice management software is transferred to the handheld computing device 101 and stored in its pre-installed memo pad application 105. In addition, any new memo or reminder information stored in memo pad application 105 is transferred to the dental practice management software. The memo or reminder information transferred from the dental practice management software to the memo pad application 105 is separated from other memos and reminders and organized into a list having its own category or group within the memo pad application 105. The placement of the memo and reminder information in a separate category permits a user to quickly and easily access the dental practice management memos and reminders without having to review other memos and reminders. Table 2 shows the format for the memo pad application 105 of the handheld computing device 101 that is optimized for use with the dental practice management application.

Subject:

To:

From:

Date:

Message: Table 2

The provider's financial record information for each day is synchronized between the handheld computing device 101 and the dental practice management application in step 207. The financial record information for each day is transferred from the dental practice management application and stored in a no-time appointment for that day in the date book application 107 on the handheld computing device 101. In addition, any new financial record information for any day stored in date book application 107 is transferred to the dental practice management software. Typically, only the goal information will be transferred from the date book application 107 to the dental practice management software to maintain data integrity. The financial information will have the highest data integrity only when it is transferred from the dental practice management application where it is calculated. This financial record information provides the user of the handheld computing device with business critical data regarding each day's financial outcome. Table 3 summarizes the financial information available for each day in date book application 107.

Production Side of Ledger Collection Side of Ledger

Production $xxx Cash $xxx

Charges $xxx Check $xxx

Production Adjustments $xxx Credit Card $xxx

Tax $xxx Collection Adjustments $xxx

Net Production $xxx Net Collections $xxx

Total Receivables $xxx

On Budget Plans $xxx Patients Seen XX

Actual Production $xxx New Patients Seen XX

% of Goal Produced xx%

Production Goal $xxx

Scheduled for Day $xxx

Table 3

The provider's appointment schedule is synchronized between the handheld computing device 101 and the dental practice management application in step 208. The appointment schedule information is transferred from the dental practice management application and stored in the date book application 107 on handheld computing device 101. In addition, any new appointment schedule information stored in date book application 107 is transferred to the dental practice management software. The user of the handheld computing device 101 has significant control over the appearance of the display of the information in the date book application 107. Furthermore, there is important data, in addition to the date and time of appointment and patient's name and phone number, related to the appointment schedule information that are both meaningful and necessary to the practitioner and should be included with the date book application 107. Treatment room, work to be performed, medical alerts, pre-medication, and whether the appointment confirmation status are displayed to the user through an additional information screen. The assistant(s) are displayed as well on the additional information screen. All this appointment schedule information permits a provider to see a snapshot of his/her schedule, with enough information to make intelligent decisions about rearranging or rescheduling appointments.

Any specialized contact information is synchronized between the handheld computing device 101 and the dental practice management application in step 209. One example of specialized contact information is the "End of Day Call Back" list, even though other similar types of specialized contact information can be transferred. The "End of Day Call Back" list is used by healthcare professionals to contact patients that require a follow-up call after their visit is complete. The specialized contact information is transferred from the dental practice management application and stored in the address book application 106 on handheld computing device 101. Similar to the handling of the referring doctor information described above, a separate category is formed in the address book application 106 to separate the list of specialized contact information from the remaining address information stored in address book application 106. The placement of the specialized contact information in a separate category permits a user to have quick and easy access the dental practice management specialized contact information without having to review other address information. In addition, any new specialized contact information stored in address book application 106 is transferred to the dental practice management software. Furthermore, there are special fields related to specialized contact information depending on the type of specialized contact that are both meaningful and necessary to the practitioner and should be included in the record stored in the address book application 106. These meaningful fields from the "End of Day Call Back" list of the dental practice management application, including the work performed on that patient, the patient's date of birth, the patient's special medical problems (drug allergies, conditions, etc.) and the patient's spousal information, have to be formatted to fit in the custom or notes section of the address book application 106. Other specialized lists will require other specialized information. Table 4 illustrates the format of the address book application optimized to include the specialized contact information from the "End of Day Call Back" list of dental practice management software.

Title: Home Phone:

Full Name: Work Phone:

Street Address: Procedures Performed on Patient:

City: Date of Birth:

State: Spouse's/Parents Name:

Zip Code: Patient's Current Prescription

Table 4

In step 210, the provider or practice's pharmacy information is synchronized between the handheld computing device 101 and the dental practice management application. The list of pharmacies is transferred from the dental practice management application and stored in the address book application 106 on handheld computing device 101. Similar to the handling of the referring provider information described above, a separate category is formed in the address book application 106 to separate the pharmacy information from the remaining address information stored in address book application 106. The placement of the pharmacy information in a separate category permits a user to have quick and easy access to the dental practice management pharmacy information without having to review other address information. Furthermore, this makes it very easy for a practitioner or provider to prescribe medications when in contact with a patient away from the office. This information is also beneficial for a practitioner reviewing the "End of Day Call Back" information because it is common to assign or change a prescription for a patient after the follow-up call. In addition, any new pharmacy information stored in the address book application 106 is transferred to the dental practice management software. Table 5 illustrates the format of the address book application 106 optimized to include the pharmacy information from the dental practice management software.

Pharmacy Name: Phone:

FAX:

Street Address:

City: Contact:

State:

Zip Code:

Table 5

In step 211, recent prescription information is synchronized between the handheld computing device 101 and the dental practice management software. The recent prescription information is transferred from the dental practice management application and stored in the address book application 106 on handheld computing device 101. "Recent" is defined by the user of the handheld computing device 101 as the number of days back from today. By defining the number of days included as "recent", the user has the ability to control the storage of as much or as little of the prescription history as the user desires. Similar to the handling of the referring provider information described above, a separate category is formed in the address book application 106 to separate the list of recent prescriptions from the remaining address information stored in address book application 106. The placement of the recent prescriptions in a separate category permits a user to have quick and easy access to the dental practice management recent prescription list without having to review other address information. In addition, any new or refilled prescription information stored in the address book application 106 is transferred to the dental practice management software. Furthermore, there are special fields related to the prescription that are both meaningful and necessary to the practitioner and should be included in the record stored in the address book application 106. These meaningful fields from the dental practice management application, including the name, address and phone number of the patient the prescription was written for, the patient's medical alerts such as allergies, the name of the pharmacy, the date of the prescription, the drug name, the dosage, the refill information, and instructions, have to be formatted to fit in the custom or notes section of the address book application 106. Table 6 illustrates the format of the address book application 106 optimized to include the recent prescription information from the dental practice management software.

Title: Home Phone:

Patient Name: Work Phone:

Pager #: Email Address:

Street Address: Drug Name:

City: Date:

State: Medical Alerts:

Zip Code: Required Pre-medication:

Instructions: Pharmacy:

Dosage: Refill:

Table 6

In step 212 the patient information is synchronized between the handheld computing device 101 and the dental practice management software. The patient information is transferred from the dental practice management application and stored in the address book application 106 on the handheld computing device 101. Similar to the handling of the referring doctor information described above, a separate category is formed in the address book application 106 to separate the list of patients from the remaining address information stored in address book application 106. The placement of the patient information in a separate category permits a user to have quick and easy access to the dental practice management patient information without having to review other address information. In addition, any new patient information stored in address book application 106 is transferred to the dental practice management software. Furthermore, there are special fields related to patients that are both meaningful and necessary to the practitioner and should be included in the record stored in the address book application 106. These meaningful fields from the dental practice management application, including the patient's next appointment date and time, the patient's last exam date, and the patient's date of birth, the patient's medical alerts, the patient's required pre-medication, and the patient's identification number, have to be formatted to fit in the custom or notes section of the address book application 106. Table 7 illustrates the format of the address book application 106 optimized to include the patient information from the dental practice management software.

Title: Home Phone:

Full Name: Work Phone:

Pager #: Email Address:

Street Address: Next Appt Date & Time:

City: Last Regular Exam:

State: Medical Alerts:

Zip Code: Required Pre-medication:

ID #: Date of Birth:

Table 7

As described above, one way for the user of the handheld computing device 101 to enter information into the healthcare desktop application is to enter the information into the handheld computing device 101 and then synchronize the information with the healthcare desktop application. Normally, the handheld user enters information on the handheld device 101 and that information directly replaces the corresponding information on the desktop application, or is added to the desktop application if the information is new. The direct replacement or addition of information can be considered a very static process in that the content or meaning of the change of the information is ignored. For example, the removal of an appointment from the date book application 107 on the handheld device 101 causes the same appointment to be removed from the desktop application's date book. However, the impact of such a removal is not taken into consideration. In healthcare disciplines, merely adding, removing, or changing information can require special handling beyond the changing of the information.

In one embodiment of the present invention, a special set of commands is implemented for use at synchronization time in steps 203 and 204. The special set of commands are parsed or read from the handheld computing device 101 and then interpreted by the conduit as a call for some defined action in the healthcare desktop application. A special delimiter, followed by a series of alphanumeric characters, distinguishes the commands from other data or information and each other. However, any similar type of indicia that can be understood by the conduit can be used to indicate a command. Examples of several types of the commands and their corresponding functions that can be parsed and executed in steps 203 and 204 are described below. The list of examples provided below is not meant to be exhaustive and other commands with other functions can be included and used in the present invention.

The first example of a command is the Date Book Cancel command, \SDC. This command is entered into the handheld computing device 101 on the line in the date book application 107 corresponding to the appointment to be canceled. At synchronization time, the conduit interprets this command and creates a memo notification in the healthcare desktop application to all users of the healthcare desktop application, detailing the information of the appointment marked for cancellation. The memo alerts the staff that the appointment needs to be canceled; the patient may need notification and/or rescheduling; and the appointment should be copied to a "tickler" file for later follow-up if rescheduling of the appointment at the current time does not happen.

The next command is the Date Book Memo command, \SDM, followed by the text message. This command is entered into the handheld computing device 101 in the date book application 107 on a given day. At synchronization time, the conduit interprets this command and creates a memo notification to appear on that day in the healthcare desktop application to all users, including the specified message. The users of the healthcare desktop application can then respond to the actions specified in the memo. The next command is the Date Book Note command, \SDN, followed by a number and the text for a note. The number specifies a treatment room or operatory for this note. This command is entered into the handheld computing device in the date book application 107 at a given time and for the specified length. At synchronization time, the conduit interprets this command and creates a note in the healthcare desktop application scheduling function on that date and time, for the specified treatment room. The message for the note can include a call for an action or activity, usually in regards to scheduling patients on that particular date and time.

The next command is the Date Book Block command, \SDB followed by a number and the text for a note. The number specifies a treatment room or operatory for this note. This command is entered into the handheld computing device 101 in the date book application 107 at a given time and for the specified length. At synchronization time, the conduit interprets this command and blocks out the specified time range in the healthcare desktop application scheduling function on that date in the specified treatment room. The message usually specifies the reason for blocking any scheduling of patients during this time range on this date as well as a call for an action or activity, usually in regards to time usage on that particular date and time.

The next command is the Date Book Add Appointment command, \SDA, followed by a number and a message, which usually includes the patient requesting the appointment. The number specifies a treatment room or operatory for this note. This command is entered into the handheld computing device 101 on the line in the date book application 107 for a given date and time, and for the specified treatment room. At synchronization time, the conduit interprets this command as a request for an appointment to be made on the specified date and time. In the healthcare desktop application, a memo is created to notify the staff to make the appointment and a note is placed in the desktop application scheduling function to mark the planned appointment time so others do not schedule for the same time and room. However, the actual appointment is not made until the patient is contacted. This process allows healthcare desktop application users to properly respond to the request to make appointment for a patient, which in healthcare disciplines requires more than just the patient name.

The next command is the Refill Prescription command, \SDR. This command is entered into the handheld computing device 101 on the last name line in the address book application 106 for a patient in the recent prescriptions list. At synchronization time, the conduit interprets this command as the prescription for the patient has been refilled. In the healthcare desktop application, the prescription refill is added to that patient's prescription log. This process allows healthcare desktop application users to properly track all prescriptions for a patient, even if refilled outside the office.

The next command is the Address Book Contact command, \SDC. This command is entered into the handheld computing device 101 on the last name line in the address book application 106 for the patient requiring a contact. At synchronization time, the conduit interprets this command and creates a memo notification in the healthcare desktop application to all users, specifying that the patient needs to be contacted.

When all information has been synchronized between the handheld computing device 101 and the dental practice management application, the synchronization process then ends in step 213. In another embodiment of the present invention, the order in which commands are parsed and executed and the information is synchronized between the dental practice management application and the handheld computing device 101 can be varied to any particular order preferable to the user.

In another preferred embodiment of the present invention, the process ^' for securing the handheld computing device 101 for use in healthcare disciplines such as dentistry is defined by a multi-step process to ensure proper authentication and data access. A user authentication process can be implemented to control which users of handheld devices 101 can gain access to the information stored in the dental practice management application and to control what information authorized users of the dental practice management application can transfer to their handheld computing device 101. A conceptual overview of a security model for using a handheld computing device in healthcare is shown in Figure 11. Figure 11 shows the security model 1100 having a plurality of different components used to provide adequate security for healthcare information to be used on a hand held computing device 101. Some of the different security components include username and. password definitions for all users 1102, forced logins at synchronization time 1104, privatization of data on handheld computing device 1106, maintaining an audit trail of all operations 1108, limiting data access based on each users needs 1110 and controlling administrator rights 1112.

The first step of securing the dental practice management application that is to be synchronized with a handheld computing device 101 is authenticating the user on both the handheld computing device 101 and in the dental practice management application itself. The dental practice management application needs to be able to provide security and control in two areas. The dental practice management application needs: 1) the ability to restrict the users that have the privilege of using a handheld computing device 101; and 2) the ability to restrict the information that may be transferred to the handheld computing device 101 for users with that privilege.

The administrator of the dental practice management application must be able to control which users have the privilege to use a handheld computing device 101. The administrator is the individual designated by the business entity, the healthcare practice, as the person with the responsibility to control access to the healthcare practice management software. The administrator configures the user accounts (username and password). The administrator is also responsible for implementing and maintaining all business rules for each user of the dental practice management application as defined by the business entity. In another embodiment of the present invention there can be more than one administrator each having the responsibilities described above.

For effective security, the administrator should have control over access to every area related to use of the handheld computing device 101 for any user. Ideally, the administrator will have control over the installation and configuration of software associated with using the handheld computing device 101, the access to data and setup or configuration information, and most importantly, the access to the healthcare practice management application security configuration and user account administration. It is very important to permit only the administrator access to the areas of the healthcare practice management application that controls system security and policy configuration. Simply denying the right to use a handheld device 101 without also securing the account creation and administration in the healthcare practice management application does not provide adequate security for the information stored in the healthcare practice management application.

To begin, the administrator must be the only one to perform the creation and modification of user accounts. The administrator will have restricted access to system security and user account creation and setup. By permitting only the administrator to have access to user account creation and setup, a user without handheld rights will be prevented from creating a new user account with the handheld usage right enabled.

Once it has been established who has the right to use a handheld computing device 101 in the business entity or organization, the administrator implements the security policy for those users (referred to hereafter as Handheld Users). The next step in the security and authentication process is to define the information each Handheld User can access from the healthcare practice management application. This is an extremely important step because each Handheld User may have a different role in the organization and therefore require access only to data related to their particular functions. Figure 3 illustrates one possible interface an administrator could use to configure what information is available for synchronization to each Handheld Users. Data and information critical to one Handheld User may not be useful for or permitted to another Handheld User.

Each Handheld User has the ability to further customize and control the accessible information that is synchronized with the handheld computing device 101. Figure 4 illustrates one possible interface for the Handheld User to control the information that is synchronized. The Handheld User can configure what information is synchronized during the synchronization process. The Handheld User can also determine the format of the information that is synchronized, the frequency the information is synchronized, the information that is removed during the synchronization process and the basis or source of the information that is synchronized.

The process of user authentication at runtime is extremely important in preventing unauthorized use of critical and/or confidential company or patient information. Cases of theft of the device, a disgruntled employee or simply someone snooping around must be prevented. Having established Handheld Users and their individual rights as described above, the process now shifts to validating users when a synchronization and transfer of information between the handheld computing device 101 and the desktop computer 102 is performed. The login procedure for the synchronization process provides a way to uniquely identify a Handheld User. After identifying the Handheld User, the conduit or synchronization software will be able to make security decisions and facilitate custom options based on the logged in Handheld User (see Figure 7). To be able to login to the dental practice management application during a synchronization, valid username and password for the healthcare practice management application is required. Figure 5 is a flowchart illustrating the process of user authentication at synchronization.

The Handheld User at step 501 starts the synchronization process. In step 502, the conduit or synchronization software for the healthcare practice management application is called and executed. At step 503, the conduit determines if the Handheld User must login to the healthcare practice management application every time the Handheld User wants to synchronize information. Forcing the user to login to the healthcare practice management application during each synchronization process is another security feature that can be configured by the administrator. Figure 6 illustrates an interface an administrator can use to configure the healthcare practice management application to require a Handheld User to login for each synchronization process.

If the Handheld User is not required to login for each synchronization process, the practice management conduit will determine in step 504, if a hidden database exists on the handheld computing device 101 that stores the username and password for the Handheld User. The first time a Handheld User attempts the synchronization process, this liidden login database will not exist on the handheld computing device 101. If the login information database does not exist, a login screen will appear to the Handheld User at step 505. The username and password entered by the Handheld User is validated at step 506. If the Handheld User has entered a valid username and password, the synchronization process continues at step 507 and the valid username and password are stored on the handheld computing device 101. The password stored in the hidden login database is encrypted for security purposes and the username may also be encrypted. However, this information may not be stored if the Handheld User is required to login for each synchronization process. If the Handheld User has entered an invalid username or password, the synchronization process ends at step 508. In addition the Handheld User has the option to cancel the synchronization, thereby causing the conduit to end the synchronization process.

Referring back to step 504, if the Handheld User does have hidden login information stored on the handheld computing device 101, this information is used to login the Handheld User at step 509. The retrieval of the hidden login information will require no interaction by the Handheld User to login unless required by the healthcare practice management application. The login information is validated at step 510 and if correct the Handheld User can continue with the synchronization at step 507, otherwise the Handheld User will be presented the login screen at step 505.

Referring back to step 503, if the Handheld User is required to login for each synchronization process, regardless of whether or not the Handheld User has login information stored on the handheld computing device 101, the login screen is presented to the Handheld User at step 505. The Handheld User can then proceed through steps 506-508 as appropriate.

The process for checking that Handheld Users only synchronize authorized information is shown in Figure 7. The Handheld User starts the synchronization process at step 701 and the practice management conduit checks for a valid login at step 702, which is described in greater detail above with regard to Figure 5. Once the Handheld User has been validated or authenticated, the conduit begins the transfer and synchronization of records or information at step 703. If all the records have been synchronized then the synchronization process ends at step 704. Otherwise, the conduit will check with the healthcare practice management application in step 705 to determine if the Handheld User has authorization to synchronize with the current record. If the Handheld User does have synchronization authorization, then the current record is synchronized at step 706 and the Handheld User is returned to step 703 to retrieve the next record. If the Handheld User does not have synchronization authorization for the current record, the Handheld User is not permitted to synchronize with the current record and is returned to step 703 to retrieve the next record.

In another preferred embodiment of the present invention, as an additional security measure, the administrator will be able to designate that any information or data records transferred from the healthcare practice management application to the handheld computing device 101 are stored as private records on the handheld computing device 101. A privatized record will usually require a password to be entered for the record to be viewed. However, the Handheld User can configure the handheld computing device 101 to hide or show all or some of the private records so that the Handheld User does not have to enter the password information each time each time he/she wants to view a privatized record. The option of having the transferred information stored in the handheld computing device 101 as a private record is set by the administrator in a procedure similar to that described above for forcing a Handheld User to login each time he/she wants to synchronize. This can be an important feature because a Handheld User that is not protected through a forced login procedure can be protected from an unauthorized user from taking the handheld computing device 101 and viewing the records.

In another preferred embodiment of the present invention, the healthcare practice management application can have an audit logging feature which can provide additional security. Audit logging is the process by which the healthcare practice management application and/or associated conduit maintains a list, often referred to as a trail, of the operations performed during processing with the handheld computing device 101. Figure 8 illustrates an example of an audit trail. The trail can include information about authorized and unauthorized logins, data or information access, and synchronization. In addition, the trail could also provide information about the Handheld User who is attempting to synchronize and at what time this attempt occurs. The audit trail is preferably designed to be able to display any information recorded by either healthcare practice management application or its associated conduit that would be considered useful and valuable to an administrator of the healthcare practice management application. The information displayed in the audit trail allows the administrators of the healthcare practice management software to detect security breaches, which is the primary and most important function, as well as locate and troubleshoot any problem areas in the synchronization process.

Figure 9 illustrates one arrangement for the synchronization of information between the desktop computer 102 and the handheld computing device 101. A synchronization controller 901 is installed on the desktop computer 102 in order to control the synchronization process. The synchronization controller 901 can be used to detect when the synchronization process is to begin, the order in which the synchronization programs or conduits 902-904 are called and executed to accomplish the synchronization of information, when the synchronization process has completed, and any other related synchronization management function.

Conduits 902 and 903 are designed to access information from a corresponding database 905-906 to synchronize the database information with corresponding information in the handheld computing device 101 as is well known in the art. In contrast, the present invention uses a healthcare practice management application conduit 904 that is designed to open a hidden or ghost copy of the healthcare practice management application 907. The hidden healthcare practice management application 907 will preferably have all the functions and capabilities of the version that is displayed to a user but is only executed in the background. In addition, when new versions of the healthcare practice management application are installed, the conduit 904 will also open the new version as the hidden healthcare practice management application 907.

The conduit 904 will query or request the hidden healthcare practice management application 907 for any information needed for synchronization with information on the handheld computing device 101. The hidden healthcare practice management application 907 can then take the request or query received from the conduit 904 and retrieve the appropriate information from the healthcare practice management application database 908 and return that information to the conduit 904 for synchronization.

The use of the hidden healthcare practice management application 907 to obtain information from the database 908 for synchronization with the handheld computing device 101 instead of using the conduit 904 to obtain the information from database 908 permits changes to be made to the schema and organization of the database 908 without having to rewrite or recompile conduit 904 to accommodate those changes. In addition, the use of the hidden healthcare practice management application 907 permits the conduit 904 to benefit from any improved procedures that are implemented into the healthcare practice management application.

Secure and optimized synchronization occurs by having the conduit communicate directly with the healthcare desktop application, instead of accessing the healthcare desktop application database. This is optimal for several reasons: the conduit for the healthcare desktop application remains small and manageable; the conduit encapsulates the data access to the healthcare desktop application reducing the risk of database corruption by having multiple distinct programs accessing the data; stability and longevity of the conduit can be attained in that changes to the database structure of the healthcare desktop application may not affect the conduit since it does not directly access the database; security standards are maintained in the healthcare desktop application, thus providing one source for effecting policy and administration of security procedures and reducing the chance for security breeches and/or errors; and the healthcare desktop application will be harder to "crack" than the conduit, by the sheer application size and complexity of the healthcare desktop application. It becomes both easy and optimal to administer security policies by developing and enforcing them in the healthcare desktop application and having the conduit use the healthcare desktop application to get the information.

All aforementioned embodiments define a process for transforming a handheld computing device, which is designed as a general business tool, for use in healthcare disciplines. Figure 12 illustrates conceptually the steps involved in converting a general handheld computing device 101 to a secure healthcare specific computing device. A handheld computing device 101 is combined with a security model 1100 to protect healthcare data and provide procedures for controlling unauthorized use of data and unauthorized use of the handheld computing device, an effective healthcare mobile data definition model 1202 for the minimum set of critical data required by a healthcare practitioner or user for use with a handheld computing device 101, a distinct categorization 1204 for the healthcare specific data for ease of lookup on the handheld computing device 101, a set of healthcare commands that enhance and extend information transfer from the handheld computing device 101 to the healthcare desktop application, and a navigation tool 1206 for the handheld computing device to easily locate the healthcare data, to become a handheld computing device for use in healthcare disciplines 1208.

Although the present invention has been described in connection with specific examples and embodiments, those skilled in the art will recognize that the present invention is capable of other variations and modifications within its scope. These examples and embodiments are intended as typical of, rather than in any way limiting on, the scope of the present invention as presented in the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A method for transferring healthcare related data between a healthcare application loaded on a computer and a handheld computer having a plurality of pre-installed applications, the method comprising the steps of: executing a synchronization program to facilitate transferring data between the healthcare application and the handheld computer; loading a copy of the healthcare application into a memory device of the computer and executing the copy of the healthcare application as a background application; retrieving predetermined healthcare information from the copy of the healthcare application; transferring the predetermined healthcare information to the handheld computer; and storing the predetermined healthcare information into a corresponding pre-installed application on the handheld computer.

2. The method of claim 1 further comprising the step of formatting custom fields in the corresponding pre-installed application to accommodate specific types of the predetermined healthcare information.

3. The method of claim 1 further comprising the step of creating a category in the corresponding pre-installed application to receive only the predetermined healthcare information.

4. The method of claim 1 further comprising the step of complying with at least one security measure before said retrieving predetermined healthcare information from the copy of the healthcare application.

5. The method of claim 4 wherein said complying with at least one security measure includes validating a username and password to access the copy of the healthcare application.

6. The method of claim 4 wherein said complying with at least one security measure includes the steps of: designating, by an administrator of the healthcare application before said executing of the synchronization program, particular records of the predetermined healthcare information for retrieval by a particular user of a handheld computer; and verifying each record of the predetermined healthcare information as a particular record designated for retrieval by the particular user.

7. The method of claim 4 wherein said complying with at least one security measure includes designating the predetermined healthcare information as private records requiring entry of a password to view on the handheld computer.

8. The method of claim 1 further comprising the step of generating an audit list of all attempted operations relating to the transfer of healthcare related data between a healthcare application and a handheld computer.

9. The method of claim 8 wherein the step of generating an audit list includes recording at least a date and time of each attempted operation, a result of each attempted operation and a user who attempted each operation.

10. The method of claim 1 further comprising the step of repeating the steps of retrieving predetermined healthcare information, transferring the predetermhied healthcare mformation and storing the predetermined healthcare information to complete the transfer of healthcare related data between a healthcare application and a handheld computer.

11. The method of claim 1 further comprising the step of designating, by a user, particular records of the predetermined healthcare information to be transferred to the handheld computer.

12. The method of claim 1 further comprising the step of parsing the plurality of pre-installed applications on the handheld computer for a command directing the healthcare application to perform a corresponding action.

13. The method of claim 12 further comprising the step of executing, by the synchronization program, the parsed command from the plurality of pre-installed applications on the handheld computer to instruct the healthcare application to perform the action corresponding to the parsed command.

14. The method of claim 1 further comprising the steps of: retrieving additional predetermined healthcare information from the plurality of pre-installed applications on the handheld computer; transferring the additional predetermined healthcare information to the healthcare application; and storing the additional predetermined healthcare information in records of the predetermined healthcare information in the healthcare application.

15. The method of claim 1 wherein: the predetermined healthcare information comprises: a patient list; a referring doctors list; memos; a schedule; daily financial data; recent prescriptions; pharmacies; and an end of day call back list; and the plurality of pre-installed applications comprises: a date book application; a memo pad application; an address book application; and an electronic mail application.

16. A computer program product embodied on a computer readable medium and executable by a computer for transferring healthcare related data between a healthcare desktop application loaded on a computer and a handheld computer having a plurality of pre-installed applications, the computer program product comprising computer instructions for executing the steps of: executing a synchronization program to facilitate transferring data between the healthcare desktop application and the handheld computer; loading a copy of the healthcare desktop application into a memory device of the desktop computer and executing the copy of the healthcare desktop application as a background application; retrieving predetermined healthcare information from the copy of the healthcare desktop application; transferring the predetermined healthcare information to the handheld computer; and storing the predetermined healthcare information into a corresponding pre-installed application on the handheld computer.

17. The computer program product of claim 16 further comprising computer instructions for executing the step of formatting custom fields in the corresponding pre-installed application to accommodate specific types of the predetermined healthcare information.

18. The computer program product of claim 16 further comprising computer instructions for executing the step of creating a category in the corresponding pre-installed application to receive only the predetermined healthcare information.

19. The computer program product of claim 16 further comprising computer instructions for executing the step of complying with at least one security measure before said retrieving predetermined healthcare information from the copy of the healthcare desktop application.

20. The computer program product of claim 19 wherein said complying with at least one security measure includes validating a username and password to access the copy of the healthcare desktop application.

21. The computer program product of claim 19 wherein said complying with at least one security measure includes the steps of: designating, by an administrator of the healthcare desktop application before said executing of the synchronization program, particular records of the predetermined healthcare information for retrieval by a particular user of a handheld computer; and verifying each record of the predetermined healthcare information as a particular record designated for retrieval by the particular user.

22. The computer program product of claim 19 wherein said complying with at least one security measure includes designating the predetermined healthcare information as private records on the handheld computer requiring a password to view.

23. The computer program product of claim 16 further comprising computer instructions for executing the step of generating an audit list of all attempted operations relating to the transfer of healthcare related data between a healthcare desktop application and a handheld computer.

24. The computer program product of claim 23 wherein generating an audit list includes recording at least a date and time of each attempted operation, a result of each attempted operation and a user who attempted each operation.

25. The computer program product of claim 16 further comprising computer instructions for executing the step of repeating the steps of retrieving predetermined healthcare information, transferring the predetermined healthcare information and storing the predetermined healthcare information to complete the transfer of healthcare related data between a healthcare desktop application and a handheld computer.

26. The computer program product of claim 16 further comprising computer instructions for executing the step of designating, by a user, particular records of the predetermined healthcare information to be transferred to the handheld computer.

27. The computer program product of claim 16 further comprising computer instructions for executing the step of parsing the plurality of pre- installed applications on the handheld computer for a command directing the healthcare desktop application to perform a corresponding action.

28. The computer program product of claim 27 further comprising computer instructions for executing the step of executing, by the synchronization program, the parsed command from the plurality of pre- installed applications on the handheld computer to instruct the healthcare desktop application to perform the action corresponding to the parsed command.

29. The computer program product of claim 16 further comprising computer instructions to execute the steps of: retrieving additional predetermined healthcare information from the plurality of pre-installed applications on the handheld computer; transferring the additional predetermined healthcare information to the healthcare desktop application; and storing the additional predetermined healthcare information in records of the predetermined healthcare information in the healthcare desktop application.

30. The computer program product of claim 16 wherein: the predetermined healthcare mformation comprises: a patient list; a referring doctors list; memos; a schedule; ^• daily financial data; recent prescriptions; pharmacies; and an end of day call back list; and the plurality of pre-installed applications comprises: a date book application; a memo pad application; an address book application; and an electronic mail application.

31. A system to transfer healthcare related data between a practice management application and a handheld computer comprising: a computer; said computer comprising at least one memory device and a practice management application stored in said at least one memory device; a handheld computer; said handheld computer comprising at least one storage device and a plurality of applications stored in said at least one storage device; a communications link connecting said computer and said handheld computer; a conduit to transfer data between the practice management application and the handheld computer; said conduit comprising: means for loading a copy of said practice management application into said at least one memory device of said computer and executing said copy of said practice management application as a background application; means for retrieving predetermined healthcare information from said copy of said practice management application; and means for transferring said retrieved predetermined healthcare information to said handheld computer; and means for storing said transferred predetermined healthcare information into a corresponding application of said plurality of applications on said handheld computer.

32. The system of claim 31 further comprising: each of said plurality of applications on said handheld computer comprises at least one custom field; and means for formatting said at least one custom field in said corresponding application to accommodate specific types of said transferred predetermined healthcare information.

33. The system of claim 31 further comprising: each of said plurality of applications on said handheld computer comprises at least one category to organize information in said application; and means for creating a new category in said corresponding application to receive only said transferred predetermined healthcare.

34. . The system of claim 31 further comprising means for implementing at least one security measure before retrieval of said predetermined healthcare information from said copy of said practice management application.

35. The system of claim 34 wherein said means for implementing at least one security measure comprises means for validating a username and password to access said copy of said practice management application.

36. The system of claim 34 wherein said means for implementing at least one security measure comprises: means for designating, by an administrator of said practice management application, particular records of said predetermined healthcare information for retrieval by a particular user of a handheld computer; and means for verifying each record of said predetermined healthcare information as a particular record designated for retrieval by said particular user.

37. The system of claim 34 wherein said means for implementing at least one security measure comprises means for designating said transferred predetermined healthcare information as private records requiring entry of a password to view on said handheld computer.

38. The system of claim 31 further comprising means for generating an audit list of all attempted operations relating to the transfer of healthcare related data between said practice management application and said handheld computer.

39. The system of claim 38 wherein means for generating an audit list comprises means for recording at least a date and time of each attempted operation, a result of each attempted operation and a user who attempted each operation.

40. The system of claim 31 further comprising means for designating, by a user of said practice management application, particular records of said predetermined healthcare information to be transferred to said handheld computer.

41. The system of claim 31 further comprising means for parsing said plurality of applications on said handheld computer for a command directing said practice management application to perform a corresponding action.

42. The system of claim 41 wherein said conduit comprises means for executing said parsed command from said plurality of applications on said handheld computer to instruct said practice management application to perform said action corresponding to said parsed command.

43. The system of claim 31 further comprising: said conduit comprises: means for retrieving additional predetermined healthcare information from said plurality of applications on said handheld computer; and means for transferring said additional predetermined healthcare information to said copy of said practice management application; and means for storing said additional predetermined healthcare information in records of said predetermined healthcare information in said practice management application.

44. The system of claim 31 wherein: said predetermined healthcare information comprises: a patient list; a referring doctors list; memos; a schedule; daily financial data; recent prescriptions; pharmacies; and an end of day call back list; and said plurality of applications comprises: a date book application; a memo pad application; an address book application; and an electronic mail application.