WO2012151402A1

WO2012151402A1 - Tracking and managing patient care in medical clinics

Info

Publication number: WO2012151402A1
Application number: PCT/US2012/036323
Authority: WO
Inventors: Sanjeev Yeshwan DHARAP
Original assignee: Patientscribe Inc.
Priority date: 2011-05-03
Filing date: 2012-05-03
Publication date: 2012-11-08

Abstract

Methods, systems, and apparatus, including computer programs encoded on computer storage media, for tracking and managing patient care in medical clinics. Features of such systems include that they can create on-the-fly condition based networks for patients and doctors, or provide on-the-fly, condition-based communication facilities for patients and doctors, that they can provide such networks and facilities for patients or doctors of multiple clinics, or provide communication facilities for information and services from outside clinics to doctors and patients, or provide decision support including comparative lifetime costs of multiple treatment options, or support a temporary assignment of personal table computer devices to patients during their visits to clinics, and the use of the devices to communicate with patients at the clinic.

Description

TRACKING AND MANAGING PATIENT CARE IN MEDICAL CLINICS

CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of the filing date of U.S. Patent Application No. 61/482, 110, for Tracking and Managing Patient Care in Medical Clinics, which was filed on May 3, 2011, and which is incorporated herein by reference.

BACKGROUND

This specification relates to tracking and managing patient care in medical clinics.

Electronic medical records software systems (also referred to as electronic health records software systems) exist that provide a range of functionality that is useful to healthcare providers and their patients. Some such systems are offered for installation on computers belonging to the medical practice; others are offered as software as a service solutions.

SUMMARY

This specification describes innovative patient care management and tracking systems for medical clinics, and methods and computer program products that are implemented in and implemented using such systems.

One innovative aspect of such systems is that they can create on-the-fly condition based networks for patients and doctors.

Another innovative aspect is that they can provide on-the-fly, condition-based communication facilities for patients and doctors.

Another innovative aspect is that they can provide such networks and facilities for patients or doctors of multiple clinics.

Another innovative aspect is that they can provide communication facilities for information and services from outside clinics to doctors and patients.

Another innovative aspect is that they can provide decision support including comparative lifetime costs of multiple treatment options.

Another innovative aspect is that they can support a temporary assignment of personal tablet computer devices to patients during their visits to clinics, and the use of the devices to communicate with patients at the clinic.

These aspects can be implemented in computer systems, apparatus, and computer programs recorded on one or more computer storage devices. The systems, apparatus and programs can be configured to perform the actions described in this specification. A system of one or more computers can be configured to perform particular actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.

Particular embodiments of the subject matter described in this specification can be implemented so as to realize one or more of the following advantages. Clinics can receive data giving insight into the costs of care with financial and clinical models of patients' treatment plans. Patients can be connected to other similar patients, doctors to other doctors treating similar patients and patients to their care providers, their health insurers and pharmaceutical companies. Candidate patients can be identified quickly for clinical research in one clinic and across multiple clinics. Doctors and nurses can better interact with patients by providing them with real-time information about a patient's health history. Clinic billing can be improved by eliminating missed charges, reducing billing time and getting quicker turn-around on payments. A patient care management and tracking system implemented in a clinic tier and cloud tier architecture is scalable and provides fault tolerance. The service-oriented architecture of the system allows new applications to be added and deployed easily. With the use of wireless tablet computers, patients and clinic staff can interact with each other and with the system from anywhere in a clinic. With web services, the system can integrate easily with other applications. The logic for particular medical specialties is isolated allowing it to be changed easily as requirements change.

The details of one or more embodiments of the subject matter of this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a schematic diagram illustrating elements of a patient care management and tracking system.

FIG. 2 is a schematic diagram illustrating elements of a clinic installation of the patient care management and tracking system. FIG. 3 is a schematic diagram illustrating aspects of a user interface of mobile devices implemented for the patient care management and tracking system.

FIG. 4 is a schematic diagram illustrating interactions that can take place using mobile devices implemented for the patient care management and tracking system.

FIG. 5 is a block diagram illustrating structures of the patient care management and tracking system.

FIG. 6 is a schematic diagram illustrating software modules that can be executed on the clinic server of the patient care management and tracking system, with support from the remote server as appropriate.

FIG. 7 is a diagram illustrating an alternative, peer-to-peer implementation of a patient care management and tracking system.

FIG. 8 is a diagram illustrating an alternative, mobile broadband based implementation of a patient care management and tracking system.

FIG. 9 illustrates operations of creating on-the-fly condition-based social networks for patients.

FIG. 10 illustrates operations of creating on-the-fly condition-based

communication channels for clinic patients.

FIG. 11 illustrates operations of providing communications between non-patients based on the condition of patients.

FIG. 12 illustrates operations that can be performed by multiple clinic systems to provide information to research entities identifying doctors having patients who are eligible for particular clinical trials.

FIG. 13 illustrates operations of identifying doctors having patients who are eligible for particular clinical trials.

FIG. 14 is a block diagram of elements of a system for providing lifetime cost and payment profiles for treatments.

FIG. 15 illustrates operations that can be performed by a system serving a medical clinic that has tablets available for temporary assignment to patient.

FIG. 16 illustrates elements of a method of using tablets during patient visits to a clinic.

FIG. 17 illustrates elements of an implementation of a clinic appliance.

Like reference symbols in the various drawings indicate like elements. DETAILED DESCRIPTION

As shown in FIG. 1, a patient care management and tracking system can be implemented with functionality provided by a remote server 100 communicating with multiple medical clinics 120 over any suitable conventional data communication infrastructure 1 10. The remote server can be implemented on one or more computers in one or more locations. The data communication infrastructure can include, for example, a wide area network, e.g., the Internet, with a VPN (virtual private network) to provide secure communications. The remote server is called remote not because it is inherently remote - i.e., located at a different site - from any or all clinic servers, but because it can be so located.

As shown in FIG. 2, each clinic installation includes a clinic server 200 connected over mobile connections 210 to one or more mobile devices 220 that can each be given or assigned to one of the patients 230 of the clinic at a time, while the patient is at the clinic. The clinic server 200 will get an input, e.g., from an administrator or from the patient receiving a tablet, that the server uses to link the tablet to the patient, so that the tablet is associated with the patient during the patient's visit. Generally, a clinic server 200 will be dedicated to and serve only one clinic. Generally, a clinic server 200 will be installed at the facilities of its clinic.

The mobile connections 210 can be implemented using any suitable conventional mobile connection infrastructure. For example, the mobile connections can be implemented over a mobile network that may include a single wireless access point, a network of wireless access points or a mesh network.

The mobile devices 220 can be any personal computing devices that a patient can use. Preferably, the devices are multi-touch tablet computers that support local wireless connections 210 using WiFi technology (e.g., wireless connectivity conforming to standards such as the IEEE 802.1 la/b/g/n standards). Devices using other wireless technologies, e.g., mobile broadband technologies such as 3G or 4G could also be used. Examples of such tablet computers include the iPad® tablet computers from Apple Inc. of Cupertino, California, and multi-touch tablet computers from a variety of manufacturers running an Android™ operating system from Google Inc. of Mountain View, California. Optionally, the tablets can be configured with a speech to text module to enable voice input.

The infrastructure can provide security through use of secure communication protocols, e.g., WPA2 (Wi-Fi Protected Access 2), or the use of location-based security to prevent devices physically outside the clinic from gaining access to the clinic's wireless network, or both. The clinic infrastructure optionally includes conventional technologies that enable the system to locate mobile devices 220 within the clinic.

In addition, a clinic installation can optionally include one or more monitoring stations 240 installed at strategic locations in the clinic and used by the clinic server to display an actionable list of patients with their location and status, for use by clinic doctors and staff. The monitoring stations can be touch-enabled monitors connected to the clinic server over any conventional secure mobile or local wired network. The monitoring stations can optionally be used to receive information from doctors and staff for storage and processing by the system.

As shown in FIG. 3, in some implementations, the mobile devices 220 include tablet computers 300. Each tablet computer 300 has a touch interface and runs a web browser to provide a web-based interface for the patient care management and tracking system. In other implementations, the mobile devices 220 include devices that have a native interface.

A tablet computer 300, for brevity, will be referred to as an "EPad". An EPad has, in addition to a touchscreen interface 310 for user interaction, a wired interface, e.g., a USB (Universal Serial Bus) interface, and a wireless interface, e.g., a WiFi interface. The EPad also has a web browser, which is used by the clinic server to provide a web-based interface. The web-based interface is implemented using a structure of web page documents that can be navigated by the patient or medical staff and that include patient documents 320, clinic documents 330, and particular doctors' documents 340. The system uses these documents, which are stored as static documents on the clinic server or generated as needed by software modules, described below, to present information to and receive information from an EPad user, who can be a patient or a doctor or other member of the medical staff.

When a patient visits a clinic, the patient receives an EPad that is associated with the patient for the duration of the visit. The EPad can be associated with the patient using a code identifying the patient entered by an authorized person while the EPad has a physical connection to the clinic server at the time the patient arrives at the clinic.

Alternatively, the EPad can be associated with the patient using an automatic

authentication based on an identifier and password combination, which can be entered either by the patient or an authorized member of the clinic staff. Optionally, the EPad can include a card reader, and the patient can identify himself or herself by swiping a personal card, for example, a credit card, a driver's license, or a clinic ID card. Or, the EPad can include a camera, and the patient can identify himself or herself by taking a picture of any form of identifying information, e.g., an identification number, a bar code, or a QR code or other two-dimensional bar code on a patient identification card.

As shown in FIG. 4, once a patient at a clinic receives an EPad and the EPad is associated with the patient (400), a variety of interactions with the patient can take place (410). These interactions need not all occur, nor do they need to occur in any particular order, except as the clinic may require.

While the EPad is associated with the patient, the patient's profile is available on the EPad for viewing by the patient and updating (420). The system allows a medical record to be updated only by an authorized staff member who has authenticated himself or herself on the EPad. The system can be implemented to accept authentication in a number of forms as described above, including user identification and password or identification card.

The system can present material for the patient to read and sign (422). For example, the system can present any required consent forms on the EPad for the patient to read and sign. The system can also present on the EPad, for the patient to read and acknowledge, any disclosures, healthcare information or other material that the patient should read. The patient may indicate consent and acknowledgement with a handwritten signature, using a finger or a stylus, for example, or using an electronic signature. The system can enforce requirements that necessary reading, consents and other paperwork be completed before other activities in the clinic are allowed to take place.

The system can present and allow the patient to enter or correct personal, demographic and insurance information (stored in repository 522, FIG. 5) using the EPad (424). The system can also present and allow the doctor to enter or correct clinical information (stored in repository 522) using the patient's EPad.

The system enables the patient to answer health questions and provide self-assessment on symptoms and conditions using forms presented on the EPad (426). The system maintains a history of the patient's responses to such questions and such self-assessments in a patient data repository 502 (FIG. 5).

In addition, a variety of interactions can take place with the medical staff at the clinic (440), depending on the nature of the visit.

While the EPad is associated with the patient, the patient's medical profile is available on the EPad for viewing and updating by the medical staff (450). The system allows a medical record to be updated only by an authorized staff member who has authenticated himself or herself on the EPad, as described above.

As mentioned above, the patient has the EPad with him or her throughout the visit. Clinical information gathered or generated during the visit can be recorded using the EPad by an authorized member of the medical staff (452). For example, a nurse can use the patient's EPad to record clinical information, e.g., blood pressure, pulse, or weight. Similarly, the medical staff can record on the EPad each procedure carried out on the patient (454). All of the clinical information entered on the EPad is recorded in the patient data repository 502 (FIG. 5). The system can maintain the entire history of care for the patient in the clinic, including vital signs, diagnoses, treatments, treatment plans, prescriptions and laboratory results, in the patient data repository.

The system enhances the interactions between the patient and the medical staff in a number of ways.

A doctor can review the patient's care history and physical examination details on the patient's EPad when the doctor is examining the patient (456). For example, the doctor can face the patient and provide attention to the patient while reviewing all pertinent details of the patient's medical condition on the patient's EPad. In addition, the system allows the doctor to order laboratory tests, prescriptions, consultations, treatments and treatment plans directly from the patient's EPad while interacting with the patient in an examination room (458). At the time of ordering, the doctor can obtain information relating to insurance limitations and procedures, as will be described below, to inform the doctor's decisions. The system allows doctors and nurses to view the patient's medical record, care history and current procedures simultaneously, using personal EPads, connected computers, or other devices.

The system includes a medical information system that provides information relevant to the patient's condition and the doctor's treatment options. The system presents this information so as to make the doctor more efficient by displaying the most relevant information when the doctor is using the patient's EPad. For example, when the doctor is ordering treatment for a particular condition, the system can automatically show approved and commonly used treatments for the condition; or when the doctor is reviewing the patient's lab results, the system can automatically display the exceptions so the doctor can quickly make a decision about treatment.

Using the system, a doctor can select a treatment plan, including selecting and scheduling one or more procedures at the clinic and prescribing concomitant regimens of medication. Generally, a treatment plan is defined by a set of one or more primary drugs, a schedule or times of administration for each of the primary drugs, a schedule or times of laboratory tests, the results of which can be used by the doctor to determine whether to continue with the administration of one or more of the primary drugs, and, optionally, one or more supporting drugs that are administered to offset or reduce any side effects of the primary drugs. The times of administration can be defined as specific dates, specific dates or specific dates and times of day, windows of dates and times, or rules defining relative dates, times of day and dates, or windows of time. With this information, the system can automatically request preauthorization as may be required by the patient's healthcare insurer prior to each visit. Similarly, the system can automatically request preauthorization for medications, and inform the doctor what medications are on the insurers formulary when the doctor is selecting medications to prescribe. In addition, the system can automatically request co-pay information from the patient's healthcare insurer prior to each visit, and provide this information to both the doctor and the patient.

To support the doctor's selection of a treatment or treatment plan, the system provides instant access to the patient's health records. The system can make

recommendations to the doctor about tests that may be necessary based on the patient's prescriptions and diagnosis. The information provided to the doctor can include information received by the system from test manufacturers and other sources.

Thus, the clinic staff can access the patient's health records from an EPad just as well as from a device directly connected to the system in the clinic.

If requested, the system can provide printed or electronic copies of the patient's records for use by the patient.

In all cases, a doctor can use a personal EPad, instead of the patient's EPad, for some or all of the foregoing interactions with the patient care management and tracking system.

Having information about all the clinic's patients and their treatment schedules, the system can predict inventory usage and automatically recommend inventory replenishment quantities and times based on patient treatment models. This is particularly valuable for clinics providing treatments, e.g., chemotherapies, involving supplies that are expensive and have a short shelf life. Similarly, the system can optimize allocation of clinic resources, e.g., chemotherapy chairs in a cancer clinic, by making scheduling recommendations based on the durations of use anticipated for the patients' treatments. Having information about prescribed treatments, including medications, the system can manage the clinic's compliance with treatment and prescription guidelines. For example, the system can send a message to a clinic compliance professional in the event of any apparent violation of guidelines.

Because the patient has an EPad while the patient is at the clinic, the system can provide a number of real-time services (460) using the EPad. For example, the system can automatically notify clinic staff of the whereabouts of the patient, e.g., when the patient is going in for lab tests, the system can notify the lab staff before the patient arrives so that the lab staff can be ready with the patients test equipment when the patient arrives. The system can optimize the patient's time in the clinic by scheduling procedures based on the duration of the procedure, the order in which the procedures must be carried out and clinically necessary delays between procedures. The system allows staff members to view information about the patient's visit such as the location of the patient, procedure and clinic personnel with the patient in real time. The system enables doctors and nurses to use their own EPads to interact with a patient. For example, the system allows a nurse to send an instant message to the patient's EPad when the patient is in the clinic, and the patient can instantly respond to a message from the nurse. The system can also automatically notify the patient when clinical staff are running late.

The real-time services at the clinic can also include services from third parties. For example, the system can provide direct-to-patient messaging from pharmaceutical companies in the form of on-demand surveys and questionnaires. Such communications can include communications related to medication options and subsidies for which the patient may be eligible. The system can also provide direct-to-patient messaging from the patient's or other healthcare insurance companies in the form of audio or video broadcasts and on-demand surveys and questionnaires.

The system can also allow the doctor to cause content, e.g., text, graphics and multimedia content, relevant to the patient's condition or treatment to be delivered to the patient's EPad while the patient is at the clinic.

The system can also provide services to the patient when the patient is not at the clinic. For example, the system can be configured to allow a patient to complete some health questionnaires and other forms from any computer connected to the Internet so as to reduce wait times for the patient at the clinic. The system can automatically send a reminder to a patient before the patient's visit or procedure, or automatically obtain confirmation that the patient will keep an appointment. The system can send reminders using several methods, for example, e-mail, SMS (short message service), or automated phone call. The system can, in the same way, automatically remind a patient to take his or her medication and to ask for refills. The system can enable clinic personnel to communicate with the patient using SMS, e-mail or telephone voice messages. The system can enable clinic personnel to send messages to the patient that will be shown to the patient on an EPad assigned to the patient at the beginning of the patient's next visit.

As already mentioned and as shown in FIG. 5, the patient care management and tracking system includes a patient data repository 502 and a repository of clinical and insurance information 522 on the clinic server 200. The system also includes backup storage 500 on the remote server 100 for backing up all of the data on the clinic servers supported by the remote server.

As shown in FIG. 5, the system includes software applications for performing the foregoing and other operations described in this specification. The application software 512 on the clinic server 200 can be can be downloaded for installation and upgrade to the clinic server from a repository of application software 510 on the remote server 100.

In addition to the operations already described, the application software can perform the following operations: The application software can automatically upload patient and other clinic data from the clinic server to the remote server for backup; and the remote server can create off-site backups of the data by transmitting the data securely to an off-site backup service. The application software can also recover from any loss of data on the clinic server 200 by obtaining data from a backup of the data on the remote server 100.

To assist the doctor, patient and clinic with financial matters, the system has a number of features. For example, for billing, the system can automatically request co-pay information from the patient's healthcare insurer prior to each visit, and automatically create a bill for all the procedures for the patient using the correct billing codes and times for the visit. The system allows administrative staff to view the patient's billing in real time during the patient's visit. The billing staff can then ensure that all charges are captured and can make any adjustments needed to the bill. The final bill can then be sent for processing as soon as the patient's visit is complete providing quicker turn-around time on payments. The system can include a payment module that allows the patient to pay the copayment for the visit using a credit or debit card. The system can identify and connect the patient to financial resources available to help the patient with the cost of care, for example, from patient assistance programs run by pharmaceutical companies. And for clinic administration, the system can build a financial model as well as a clinical model of each patient's treatment, and can use the model to provide clinic administrators with information about per patient costs and revenues. A financial model for a treatment plan associates a cost with every element of the treatment plan, including costs of supplies, clinic resources and human resources. Establishing the costs associated with supplies, procedures, and services can be done by a clinic itself, or cost information can be obtained from an outside service and refined by the clinic.

As also shown in FIG. 5, the system can communicate electronically with healthcare insurers 552, pharmaceutical companies 554, clinical test manufacturers and clinical laboratories 556, payment services 558 for processing credit card payments, for example, and other sources of business and clinical information and services of the kind described in this specification. The communication can be managed by the remote server 100, as illustrated, by each clinical server 200, or both. The system can also

communicate with a secure off-site backup facility 560 that provides off-site data backup and disaster recovery facilities. Finally, the system can also communicate with pharmacies 562 reporting the filling of prescriptions by patients. In each case, the system can communicate using the facilities of a data communication network 550, e.g., the Internet, or other data communication resources.

Thus, the system provides clinical decision support for doctors and clinics based on information entered in real time by the patient, the doctor and clinic staff. This clinical decision support is integrated with business decision support for the clinic, enabling the clinic to manage and control costs and minimize wasting of time and resources.

Integration between elements of the system can be implemented through the use of interfaces that comply with standard protocols for the exchange of electronic health information, for example, standards promulgated by HL7 (Health Level Seven).

As shown in FIG. 6, clinic servers of the patient care management and tracking system can be configured with software modules 600 to perform the functions that have been described, with support from the remote server as appropriate. A number of the modules will now be described. Other modules can also be included in a configuration. In alternative implementations, the functionality of the server can be grouped into modules differently.

A clinic server can include modules that constitute a practice management subsystem 610, which performs the functions commonly performed by a medical practice management system. Generally, this subsystem 610 maintains information about patients, schedules and manages patient appointments, sends out insurance claims and patient statements, processes payments from insurers, patients and third parties, and generates administrative and financial reports. Its modules can include a patient data management module 612, which obtains and manages information like the patient's personal and insurance information. This information can be entered by the patient or clinic staff. The subsystem can automatically confirm the patient's insurance benefits electronically with the patient's insurance company.

The subsystem 610 can also include a visit scheduling module 614. This module manages appointments for upcoming patient visits, and tracks patient visits while the patient is at the clinic. This module can manage work-flows associated with patient visits to the clinic. For example, this module can implement work-flows involving patient consent forms and content provided for the patient to read by the patient's doctor. This module can also perform resource-based scheduling based on the availability of clinic resources and patient needs, as shown by diagnoses and prescribed treatment plans.

A billing module 616 can manage insurance claims and patient statements. The module can manage information from the insurers about the services and medications that are approved by the respective insurers according to the patient's diagnosis and medical history. The doctor or other clinic staff use the subsystem 610 to enter charges as services are provided, using standard codes for services and diagnoses. Services have charges associated with them. The charges are sent to the patient's insurer electronically as a claim in the form required by the insurer. The billing module also receives the insurer's response to the claim and reports any exceptions - e.g., charges unexpectedly denied or adjusted - to the clinic's administrative staff. To the extent charges are not covered by insurance, the billing module prepares a statement for the patient and accounts for payments.

A reporting module 618 allows clinic staff to generate predefined and custom reports of detailed data on financial performance and patient financial histories.

A clinic server also includes an electronic medical records subsystem 630, which performs the functions commonly performed by an electronic medical records (EMR) system. Generally, this subsystem 630 supports the practice of the clinic with respect to clinical matters.

The software modules can also include a patient portal module 640, which enables patients to access their medical information, test results, and so on, and to perform other tasks, e.g., scheduling appointments or lab tests, getting test results, exchanging messages, or reviewing claims and statements. A messaging subsystem module 642 supports the exchange of instant messages and other forms of messages, e.g., e-mail and voicemail messages, between and among patients, doctors, clinic staff, and third parties.

An ordering subsystem module 644 supports the ordering by doctors of medications and services. Entered in a clinic EPad, for example, an order can be automatically placed with a pharmacy and the elements of a treatment plan can be automatically scheduled for clinic resources, e.g., chemotherapy chairs. This module can also provide to the doctor, at the time of ordering, information about the availability of insurance coverage for the patient for alternative treatment plans, as well as about the total cost of treatment under the alternatives the doctor has. The total cost of treatment can be determined by a separate total treatment cost estimator module 646. The ordering of treatment plans can be provided to an inventory usage prediction and automatic ordering module 648, which keeps track of the clinic's inventory of supplies, in particular perishable and expensive chemotherapy supplies, and orders supplies as required by the treatment plans ordered by the clinic's doctors.

An EPad manager module 650 provides for management of, and supports system interaction with, patient EPads. This module provides services that link EPads and patients while the patients are visiting the clinic. This module also provides user interface services.

As shown in FIG. 7, the functionality of a patient care management and tracking system can also be realized in a peer-to-peer architecture without a separate server acting as a hub between clinic installations. Multiple clinic servers S I, S2 ... SN 702a, 702b, 702c, 702d can implement a peer-to-peer network over a data communication network 704 and provide services based on their collective data. In such an implementation, the clinic servers maintain a peer-to-peer network among themselves. Each clinic server discovers information about other servers and patient profiles at other clinic servers through a discovery mechanism. The discovery mechanism can consist of a system of messages exchanged between the clinic servers and program modules at the servers that allow the servers to infer information about their peers and route messages correctly. Consider, for example, a system implemented in this manner consisting of two clinic servers SI 702a and S2 702b. SI regularly sends messages about itself to S2. These messages provide patient profile information and other information about SI to S2. With this information, S2 can correctly route patient and non-patient communication to S 1. Such a system can optionally include a central discovery and enrollment server 706 to provide enrollment and peer discovery services for the clinic servers, so that the clinic servers do not need to implement such functionality themselves.

As shown in FIG. 8, in an alternative, mobile broadband based implementation of a patient care management and tracking system, the patients 830 are given mobile broadband enabled mobile devices ("BB-EPads") 820, which are configured to communicate with a remote server 800, allowing the system to be implemented without requiring that every clinic install a clinic server. The BB-EPads can connect directly to the remote server over a broadband network, e.g., a wireless 3G or a 4G network, provided by a mobile telephone carrier. In such implementations, the BB-EPad securely transmits data directly to the remote server 800; the remote server determines the destination and routing of patient and non-patient messages sent to it. As in the other implementations, each patient 830 receives a mobile device when the patient visits a clinic; however, in these implementations, BB-EPads 820 held by patients 830 at multiple clinics (e.g., clinic A 810 and clinic B 812) connect to the same remote server 800.

An alternative, hybrid implementation includes clinics having their own clinic servers as described in reference to FIG. 2, as well as clinics that do not, as described in reference to FIG. 8. In further alternative implementations, one or more of the clinic servers or remote servers or both can be implemented in virtual machines deployed in a cloud computing environment.

FIG. 9 illustrates operations, including optional operations, that can be performed by multiple clinic systems, each serving one or more of multiple respective medical clinics, and a remote system to create on-the-fly condition-based social networks for patients.

Each clinic system maintains (910) patient information for patients of the corresponding clinic, the clinic patient information including patient identifying information and patient condition information. The patient condition information does not include patient identifying information.

Each clinic system provides (912), to the remote system, from time to time, current patient condition information for clinic patients. The information can be provided on a regular schedule. The information can be pushed from the clinic system to the remote system at times set by an administrator, for example. Alternatively, or in addition, the clinic system can provide updates when changes occur in the information.

Alternatively, the clinic systems can be polled by the remote system. The remote system receives (920) from the clinic systems, from time to time, and maintains on the remote system, current patient condition information for patients of the multiple clinics. The remote system establishes (922) multiple condition-based social networks. Each of the social network is limited to patients satisfying a condition-based requirement according to the current patient condition information maintained by the remote system. The condition-based requirement can optionally include a requirement of a common diagnosis of a disease and a common treatment plan. The condition-based requirement can optionally include a requirement of a common stage of progression of the disease. The remote system provides (924) to the clinic systems data that identifies patients of the respective clinics who are eligible to become members of one or more condition-based social networks.

Each clinic system receives (930) data from the remote system identifying patients who are eligible to become members of one or more condition-based social networks. Each clinic system notifies (932) patients who are eligible to become members of one or more condition-based social networks through electronic communications to the patients.

In some implementations, the remote system can determine (940) that a member patient of a condition-based social network no longer satisfies the condition-based requirement of the network, according to the current patient condition information maintained by the remote system, and remove (942) the patient from the network.

Optionally, the remote system can determine (944) that a patient satisfies the condition- based requirements of two distinct condition-based social networks and can then notify (946) the patient of the patient's eligibility to become a member of both networks.

In some implementations, the remote system includes a messaging platform to support the exchange (950) of messages between and among patients who are members of the same condition-based social networks. The remote system can implement an instant messaging server or an e-mail server, or provide a secure gateway to such servers. The patients can be patients from different clinics. Optionally, the remote system can continue to exchange messages between patients who had established a relationship in a condition-based social network even after the patients are no longer members of the network. In some implementations, the remote system can identify (952), for a requesting patient, other patients who have an attribute in common with the requesting patient, if the other patients consented to be identified. In some implementations, the remote system can maintain (954) personal profiles and web pages of members of condition-based social networks and make them accessible (956) only to other members of the respective social networks.

In implementations in which a clinic system establishes (960) a temporary association of a personal tablet computer with a patient visiting the medical clinic served by the system while the patient is at the clinic, the remote system can automatically log in (962) each patient associated with a tablet computer as a member of each condition-based social network that the patient is a member of, while the patient is associated with the tablet computer. In some implementations, the remote system provides secure remote log in (964) allowing patients who are members of condition-based social networks to log in remotely to access the networks they are members of.

In some implementations, the remote system also maintains (970) information about financial assistance available to patients according to their treatments and to respond to requests for information from patients about assistance for actual patient condition and treatment patterns.

FIG. 10 illustrates operations, including optional operations, that can be performed by one or more clinic systems, each clinic system serving one of multiple respective medical clinics, to create on-the-fly condition-based communication channels for clinic patients to use. Each clinic system is implemented on one or more computers configured to provide medical information services for at least one medical clinic and to maintain current patient condition information.

Each clinic system can define (1002) multiple condition-based groups of patients. Membership in each group is limited to patients who satisfy a condition-based requirement according to the current patient condition information and who have agreed to be members of such a group. Each clinic system provides (1004) a group-based patient-to-patient communication facility that enables members of each respective group to communicate with other members of the respective group, and that limits

communication through the facility to group members. The facility can be implemented using an instant messaging service implemented on one or more of the clinic systems or on a separate server. Alternatively or in addition, the facility can be implemented using an e-mail server.

FIG. 11 illustrates operations, including optional operations, that can be performed by multiple clinic systems, each serving one or more of multiple respective medical clinics, and a remote system to provide communications between non-patients based on the condition of patients with whom they have a relationship. Each clinic system maintains (11 10) patient information for patients of the corresponding clinic, the clinic patient information including patient identifying information and patient condition information. The patient condition information does not include patient identifying information.

Each clinic system provides (11 12), to the remote system, from time to time, current patient condition information for clinic patients. The information can be provided on a regular schedule. The information can be pushed from the clinic system to the remote system at times set by an administrator, for example. Alternatively, or in addition, the clinic system can provide updates when changes occur in the information.

Alternatively, the clinic systems can be polled by the remote system.

The remote system receives (1 120) from the clinic systems, from time to time, and maintains on the remote system, current patient condition information for patients of the multiple clinics. The remote system receives (1 122) a message from a message source. The message includes data that represents a patient condition pattern, message content, a communication request, and a target audience. Information about a patient included in a condition pattern will include the patient's age, gender, primary diagnosis, and will generally include one or more of the time since diagnosis was made, the current treatment, the time since beginning of treatment, the stage of disease, any non-primary diagnoses, and any such information relating to the non-primary diagnoses. The remote system provides (1124) the message content to those members of the target audience who have a relationship to those patients who satisfy the patient condition pattern. The message content is provided according to the communication request.

Particular implementations of this functionality can support some or all of the following scenarios. The patient condition pattern can be a pattern identifying a medical diagnosis; the communication request is a request to provide the message content to the target audience; and the target audience is patients fitting the pattern. The patient condition pattern identifies a medication made by a pharmaceutical company; the message source is the pharmaceutical company; and the message content includes information about financial assistance available to cover costs of the medication. The message source is a medical research entity; and the message content includes information about clinical trials in which patients fitting the pattern may be eligible to participate. The patient condition pattern identifies a healthcare insurer insuring the patients in the target audience; the message source is the healthcare insurer; and the message content includes information about insurance coverage for the medical diagnosis. The message source is a clinic patient who fits the pattern. The patient condition pattern is a pattern identifying a medical diagnosis; the communication request is a request to provide the message content to the target audience; and the target audience is clinic doctors of patients fitting the pattern. The message source is a clinic doctor. The message source is a medical research entity; and the message content includes information about clinical trials in which patients fitting the pattern may be eligible to participate.

In some implementations, the remote system can provide (1 126), in response to a request from a research entity, aggregate statistical information to the research entity about patients fitting the pattern. The information can include the number of patients.

FIG. 12 illustrates operations, including optional operations, that can be performed by multiple clinic systems, each serving one or more of multiple respective medical clinics, and a remote system to provide information to research entities identifying doctors having patients who are eligible for particular clinical trials.

Each clinic system maintains (1210) patient information for patients of the corresponding clinic, the clinic patient information including patient identifying information and patient condition information. The patient condition information does not include patient identifying information. The clinic patient information includes information identifying one or more clinic doctors treating the respective patients.

Each clinic system provides (1212), to the remote system, from time to time, current patient condition information for clinic patients and information identifying clinic doctors. The information can be provided on a regular schedule. The information can be pushed from the clinic system to the remote system at times set by an administrator, for example. Alternatively, or in addition, the clinic system can provide updates when changes occur in the information. Alternatively, the clinic systems can be polled by the remote system.

The remote system receives (1220) from the clinic systems, from time to time, and maintains on the remote system, current patient condition information for patients of the multiple clinics. The remote system receives (1222) a query relating to a clinical trial. The query identifies a patient condition pattern that patients have to fulfill to be eligible to participate in the clinical trial. The remote system identifies (1224) patients fitting the pattern from among the patients of multiple clinics. The remote system responds (1226) to the query, providing contact information of the clinic doctors who have patients fitting the pattern. In some implementations, the contact information is simply the name of the doctor and contact information for the respective clinic. Optionally, the remote system can receive the query from a research entity conducting the clinical trial and provide the contact information to the research entity in response to the query.

FIG. 13 illustrates operations, including optional operations, that can be performed by multiple clinic systems, each serving one or more of multiple respective medical clinics, and a remote system to provide information to research entities identifying doctors having patients who are eligible for particular clinical trials.

Each clinic system maintains (1310) patient information for patients of the corresponding clinic. The clinic patient information includes information identifying one or more clinic doctors treating the respective patients.

Each clinic system provides (1312), to the remote system, from time to time, current patient condition information and doctor information for clinic patients. The information can be provided on a regular schedule. The information can be pushed from the clinic system to the remote system at times set by an administrator, for example. Alternatively, or in addition, the clinic system can provide updates when changes occur in the information. Alternatively, the clinic systems can be polled by the remote system.

The remote system receives (1320) from the clinic systems, from time to time, and maintains on the remote system, current patient condition information for patients of the multiple clinics. The remote system establishes (1322) one or more condition-based social networks, each social network having as members clinic doctors who have patients satisfying a condition-based requirement according to the current patient condition information maintained by the remote system. The remote system updates (1324) the membership of the condition-based social networks as the current patient condition information maintained by the remote system changes. In some implementations, the remote system includes a module configured to provide to a doctor in a condition-based social network information describing treatment plans of other doctors in the condition- based social network for patients satisfying condition-based requirement.

FIG. 14 is a block diagram of elements 1400 of a system for providing lifetime cost and payment profiles for treatments provided by a medical clinic.

The system includes a patient data repository 1402. The patient data repository stores current patient information 1404 for each of a number of patients. The patient information includes data identifying one or more current medical conditions and a current insurance plan. The system also includes an insurance data repository 1410. The insurance data repository stores insurance coverage information specifying coverage parameters for multiple treatment plans under each of multiple insurance plans.

The system also includes a cost prediction module 1420. The cost prediction module is configured to receive input data 1422 that identifies a patient profile, a medical condition, an insurance plan, and a treatment plan, and in response to produce output data 1424 representing a predicted lifetime cost of the treatment plan for a patient having the patient profile, medical condition and insurance plan. The output data represents a treatment cost profile, which includes an estimate of what costs that will be incurred at what times, which of the costs the insurance plan will pay, and which of the costs the patient will be responsible for.

The system also includes a doctor interface module 1430. The doctor interface module is configured to receive data identifying a patient and two or more treatment plans and to present to a doctor a treatment cost profile for each of the two or more treatment plans.

In some implementations, the doctor interface module is configured to use, as a user interface device, a personal tablet computer that has been temporarily assigned to the patient while the patient is with the doctor at a medical clinic, as described above. The user interface can be implemented using web pages provided to a web browser application running on the tablet computer. The doctor interface module can receive from a clinic server information 1432 about the patient to whom the tablet computer is assigned. The doctor interface module can receive, e.g., from the doctor using the tablet computer, input 1436 identifying the two or more treatment plans, and display on the tablet computer a treatment cost profile 1434 for each of the two or more treatment plans.

FIG. 15 illustrates operations, including optional operations, that can be performed by a system, e.g., a clinic server, serving a medical clinic that has tablets (personal tablet computers) available for temporary assignment to patients during their visits to the clinic.

The system receives (1510) data input specifying that an arbitrary one of the tablets has been temporarily assigned to a patient of the clinic while the patient is at the clinic. The system provides (1512) various kinds of practice management support for the clinic. In some implementations, the system can provide, to doctors, insurance coverage and formulary information at the time the doctors are prescribing treatments and medications, and can optimize patient visit schedules according to resource availability and prescribed treatment plans. The system also provides (1514) various kinds of business decision support for the medical clinic. In some implementations, the server can manage the ordering and stocking of medications as required for prescribed treatment plans, and manage claims and payments relating to prescribed and completed services. The system also communicates (1516) with the patient through the tablet assigned to the patient. For example, the system can present questionnaires to the patient to fill out on the tablet and receive completed questionnaires from the patient. In some

implementations, the system can also receive diagnoses, prescriptions and treatment plans from a doctor at the clinic using the tablet assigned to the patient. Optionally, the system can also do one or more of the following: provide instant messaging through the tablet assigned to the patient between members of the clinic staff and the patient; present forms to the patient for the patient to sign on the tablet and receive the signed forms from the patient electronically; provide messages from the system to the patient to advise the patient of a current status and schedule of the patient's visit; and present content selected by the patient's doctor on the tablet.

As shown by FIG. 16, a medical clinic can use tablets (personal tablet computers) during patient visits as follows. The clinic maintains (1610) multiple tablets at the clinic. The clinic temporarily assigns (1612) an arbitrary one of the tablets to each of multiple patients visiting the clinic to receive a medical service. Any tablet can be assigned temporarily to a patient while the patient is at the clinic. Tablets are assigned for the duration of the visits. The clinic exchanges (1614) information with each of the patients through the tablet assigned to the patient. After the visit, the tablet is returned and can be assigned to another patient. Optionally, the exchange of information can be one or more of the following: presenting a questionnaire on a tablet for the respective patient to fill out on the tablet and receiving completed questionnaires from the patient; presenting consent forms on a tablet for the respective patient for signature on the tablet and receiving signed forms from the patient from the tablet; presenting on the tablet content selected by the patient's doctor and receiving from the tablet confirmation that the patient has read the content; exchanging instant messages between the tablet and members of the clinic staff; sending a message to a patient to advise the patient of a current status and schedule of the patient's visit; or presenting copay information to the patient.

FIG. 17 illustrates elements of an implementation of a clinic appliance 1700. The appliance can be used as the basis for implementing the clinic servers that have been described in this specification. The clinic appliance 1700 is intended to be installed in a medical clinic. It can be implemented as a Linux-based appliance sized to support hundreds of users. It runs a web application server 1710 and a database engine for a database 1720. The appliance can be implemented with 1 -2 gigabytes of random access memory. The appliance can be implemented with Jetty as the web application server and SQLite as the database engine. Other lean applications could also be used. The web application server is used to interact with users over a network. The appliance can be implemented as a solid-state appliance with SSD (solid state drive) or CF (compact flash) disks.

A server runs as a daemon on the appliance. The daemon provides web services, network services, and data security services. The daemon can be a Java program running in a Jetty web server. The server starts when the appliance boots and an init process monitors the server (daemon), restarting it if it dies. Preferably, all data communication with the appliance is encrypted, e.g., using Blowfish, Twofish or similar encryption. Data on disk are also encrypted.

All software components of the clinic appliance can interact with the database 1720 using JDBC (Java DataBase Connectivity), ODBC (Open Database Connectivity), or native application programming interface (API) connections.

The interface module 1730 is used to communicate with a clinic's practice management system, for example, using its application programming interface (API). The appliance can access a practice management system (PMS) using its API to obtain patient schedules, for example. The interface module can be used to communicate with other clinic resources, an electronic medical records system (EMR), for example. The interface module can both obtain data from, and provide data to, other such clinic resources as well. The PMS and EMR can be deployed on the clinic appliance computer or on one or more separate computers, located on the clinic site or elsewhere. Thus, a clinic server 200 (FIG. 5) can include a clinic appliance 1700, a PMS and an EMR.

A PMS is the keeper of the clinic schedule and patient payments. In a clinic, the clinic appliance can interface with the in-clinic PMS to obtain the schedule for the day and the patient records for all patients scheduled on that day. This interface module 1730 enables the appliance to update the PMS with co-payment information. The appliance can maintain visit information within the appliance so the appliance does not have to ask for a patient's information twice.

If the clinic has an EMR system, the appliance will interface with it to send it any updated data from the patient's visit. The appliance includes one or more specialty modules 1740. A specialty module contains specialty-specific logic. A specialty module for oncology, for example, contains submodules for chemotherapy regimens, treatment orders and so on.

A patient visit module 1742 manages the patient's visit, maintains the patient records, consent forms, orders and other visit-specific information.

An optional campaigns module 1744 manages on-demand campaigns that can be run from time to time. Examples of campaigns include advertisements or surveys from pharmaceutical companies.

A resource manager 1746 performs services related to managing clinic resources. For example, it helps with inventory management, clinic resource optimization and inventory predictions.

A synchronization module 1750 periodically checks to see if new data has been added to the database 1720 and sends it securely to the remote server. It also periodically checks for updates and new modules from the remote server and installs them locally on the clinic appliance.

A monitoring and management module 1760 provides a publish-subscribe infrastructure for alerts and sends periodic status updates to the remote server for action if needed.

In some implementations, the remote server is implemented as an enterprise grade server that can serve thousands of clinics, e.g., a Linux server that runs Apache HTTP Server (available from The Apache Software Foundation), has a large database engine, e.g., MySQL or Oracle® database management systems (available from Oracle

Corporation), and ample disk storage. The remote server maintains open secure connections to all the clinic servers and contains the entire system's metadata. It optionally has a dashboard to display the status of the system. It optionally provides a gateway for clinics to submit laboratory and electronic prescription orders and obtain results. For example, the remote server can provide a gateway to the Surescripts e- prescription network. Alternatively, the clinic servers can connect to such services directly. The remote server can also manage downloads from third party data providers of various kinds of metadata, e.g., reference data from Quest Diagnostics Incorporated (Madison, New Jersey), or lab ordering module metadata from LabCorp (Laboratory Corporation of America, Burlington, North Carolina). The remote server also provides automatic fault-tolerance for clinic appliances: if an appliance has to be switched out, the new appliance provisions and syncs itself from the remote server.

The remote server also acts as the messaging and communication platform for inter-clinic messages and on-the-fly communities. It securely routes requests and messages to the appropriate clinics for display to the right persons.

The remote server communicates with all the clinic appliances and so can provide system- wide analytics.

Mobile devices are used by patients and staff to communicate with the clinic appliance, as described above. Users interact with the system through a web interface. Web sessions are stateful and the appliance web server manages sessions for users.

Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, in tangibly-embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible nonvolatile program carrier for execution by, or to control the operation of, data processing apparatus. Alternatively or in addition, the program instructions can be encoded on a propagated signal that is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them.

The term "data processing apparatus" encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). The apparatus can also include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A computer program (which may also be referred to or described as a program, software, a software application, a module, a software module, a script, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

The processes and logic flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

Computers suitable for the execution of a computer program include, by way of example, can be based on general or special purpose microprocessors or both, or any other kind of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a central processing unit for performing or executing instructions and one or more memory devices for storing instructions and data.

Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive), to name just a few.

Computer-readable media suitable for storing computer program instructions and data include all forms of non- volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks;

magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user's client device in response to requests received from the web browser.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous.

What is claimed is:

Claims

1. A system comprising:

a remote system, the remote system comprising one or more computers; and a plurality of clinic systems, each clinic system comprising one or more computers, each clinic system providing medical information services for a corresponding medical clinic of a plurality of medical clinics;

wherein:

each clinic system is configured to maintain clinic patient information for patients of the corresponding clinic, the clinic patient information including patient identifying information and patient condition information, wherein the patient condition information does not include patient identifying information;

each clinic system is configured to provide, to the remote system, current patient condition information for clinic patients; and

the remote system is configured to receive from the clinic system, and to maintain on the remote system, current patient condition information for patients of the plurality of clinics;

wherein the remote system is configured to perform actions comprising:

establishing a plurality of condition-based social networks, each social network being limited to patients satisfying a condition-based requirement according to the current patient condition information maintained by the remote system; and

providing, to the clinic systems, data that identifies patients of the respective clinics who are eligible to become members of one or more condition-based social networks; and

wherein the clinic systems are each configured to perform operations comprising: receiving data from the remote system identifying patients who are eligible to become members of one or more condition-based social networks; and

notifying patients of their eligibility to become members of one or more condition-based social networks through electronic communications to the patients.

2. The system of claim 1, wherein:

the condition-based requirement includes a requirement of a common diagnosis of a disease and a common treatment plan.

3. The system of claim 2, wherein:

the condition-based requirement includes a requirement of a common stage of progression of the disease.

4. The system of claim I, wherein:

the remote system is further configured to perform actions comprising:

determining that a first member patient of a first condition-based social network no longer satisfies the condition-based requirement of the first condition-based social network according to the current patient condition information maintained by the remote system; and

removing the first member patient from the first condition-based social network.

5. The system of claim I, wherein:

the remote system is further configured to perform actions comprising:

determining that a first clinic patient satisfies the condition-based requirements of two distinct condition-based social networks; and

notifying the first patient of the eligibility of the first patient to become a member of both distinct condition-based social networks.

6. The system of claim 1, wherein:

the remote system is further configured to exchange messages between patients who are members of the same condition-based social networks.

7. The system of claim 1, wherein:

the remote system is further configured to exchange messages between patients who had established a relationship in a condition-based social network even after the patients are no longer members of the same condition-based social network.

8. The system of claim 1, wherein:

the remote system is further configured to identify for a requesting patient other patients having an attribute in common with the requesting patient, the other patients having consented to be identified.

9. The system of claim I, wherein:

the remote system is further configured to maintain personal profiles and web pages for members of a condition-based social networks and make the profiles and pages accessible only to other members of the respective social networks.

10. The system of claim I, wherein:

each clinic system is configured to establish a temporary association of a personal tablet computer with a patient visiting the medical clinic served by the clinic system while the patient is at the clinic; and

the remote system is further configured to automatically log in each patient temporarily associated with a tablet computer as a member of each condition-based social network that the patient is a member of, while the patient is associated with the tablet computer;

wherein the personal tablet computer has an installed instant messaging client.

1 1. The system of claim 1, wherein:

the remote system is further configured to allow each patient who is a member of a condition-based social network to log in remotely to access each condition-based social network that the patient is a member of.

12. The system of claim 1, wherein:

the remote system is further configured to maintain information about financial assistance available to patients according to their treatments and to respond to requests for information about assistance for actual patient condition and treatment patterns.

13. A system comprising:

one or more computers, wherein the one or more computers are configured to provide medical information services for a first medical clinic and to maintain current patient condition information for patients of the first medical clinic;

wherein the one or more computers are configured to perform actions comprising: defining a plurality of condition-based groups of patients, membership in each group being limited to patients who satisfy a condition-based requirement according to the current patient condition information and who have agreed to be members of such a group; and

providing a group-based patient-to-patient communication facility enabling members of each respective group to communicate with other members of the respective group, communication through the facility being limited to group members.

14. The system of claim 13, wherein the one or more computers are configured to provide medical information services for a different second medical clinic and to maintain current patient condition information for patients of both the first and the second medical clinics.

15. The system of claim 13, wherein the one or more computers are configured to provide medical information services for a different second medical clinic and to maintain current patient condition information for patients of both the first and the second medical clinics.

16. The system of claim 13, wherein the one or more computers are configured to maintain current patient condition information solely for patients of the first medical clinic.

17. The system of claim 13, wherein the one or more computers include a remote computer providing services to multiple clinics and a clinic computer dedicated to the first clinic.

18. A system, comprising:

wherein:

the remote system is configured to receive from the clinic system, and to maintain on the remote system, current patient condition information for patients of the plurality of clinics; and

wherein the remote system is configured to perform actions comprising:

receiving a message from a message source, wherein the message includes data that represents a patient condition pattern, message content, a communication request, and a target audience; and

providing the message to members of the target audience having a relationship to patients who satisfy the patient condition pattern, wherein the message is provided in accordance with the communication request.

19. The system of claim 18, wherein:

the patient condition pattern is a pattern identifying a medical diagnosis;

the communication request is a request to provide the message content to the target audience; and

the target audience is patients fitting the pattern.

20. The system of claim 19, wherein:

the patient condition pattern identifies a medication made by a pharmaceutical company;

the message source is the pharmaceutical company; and

the message content includes information about financial assistance available to cover costs of the medication.

21. The system of claim 19, wherein:

the message source is a medical research entity; and

the message content includes information about clinical trials in which patients fitting the pattern may be eligible to participate.

22. The system of claim 19, wherein:

the patient condition pattern identifies a healthcare insurer insuring the patients in the target audience;

the message source is the healthcare insurer; and

the message content includes information about insurance coverage for the medical diagnosis.

23. The system of claim 19, wherein:

the message source is a clinic patient fitting the pattern.

24. The system of claim 18, wherein:

the patient condition pattern is a pattern identifying a medical diagnosis;

the target audience is clinic doctors of patients fitting the pattern.

25. The system of claim 24, wherein:

the message source is a clinic doctor.

26. The system of claim 24, wherein:

the message source is a medical research entity; and

27. The system of claim 26, wherein:

the remote system is configured to provide, in response to a request from the research entity, aggregate statistical information to the research entity about patients fitting the pattern.

28. A system, comprising:

a remote system, the remote system comprising one or more computers; and a plurality of clinic systems, each clinic system comprising one or more computers, each system providing medical information services for a corresponding medical clinic of a plurality of medical clinics;

wherein:

wherein the remote system is configured to perform actions comprising:

receiving a query relating to a clinical trial, wherein the query identifies a patient condition pattern of patients eligible to participate in the clinical trial;

identifying patients fitting the pattern from among the patients of multiple clinics; and

providing, in response to the query, contact information for the clinic doctors of the patients fitting the pattern.

29. The system of claim 28, wherein the remote system is further configured to perform actions comprising:

receiving the query from a research entity conducting the clinical trial; and providing the contact information to the research entity in response to the query.

30. A system, comprising:

wherein:

each clinic system is configured to maintain clinic patient information for patients of the corresponding clinic, the clinic patient information including patient condition information, wherein the patient condition information includes information identifying one or more clinic doctors treating the respective patients;

wherein the remote system is configured to perform actions comprising:

establishing a plurality of condition-based social networks, each social network having as members clinic doctors who have patients satisfying a condition-based requirement according to the current patient condition information maintained by the remote system.

31. The system of claim 30, wherein:

the remote system is further configured to update the membership of the condition-based social networks as the current patient condition information maintained by the remote system changes.

32. The system of claim 30, wherein:

the remote system includes a module configured to provide to a doctor in a condition-based social network information describing treatment plans of other doctors in the condition-based social network for the patients defining the social network.

33. A system, comprising:

a patient data repository, the patient data repository storing current patient information, the patient information including data identifying one or more current medical conditions and a current insurance plan;

an insurance data repository, the insurance data repository storing insurance coverage information specifying coverage parameters for multiple treatment plans under each of multiple insurance plans;

a cost prediction module, the cost prediction module being configured to receive input data identifying a patient profile, a medical condition, an insurance plan, and a treatment plan, and in response to produce output data representing a predicted lifetime cost of the treatment plan for a patient having the patient profile, medical condition and insurance plan, the output data representing a treatment cost profile, the treatment cost profile including an estimate of costs that will be incurred and at what times the costs will be incurred, which of the costs the insurance plan will pay, and which of the costs the patient will be responsible for; and

a doctor interface module, the doctor interface module being configured to receive data identifying a patient and two or more treatment plans for the medical condition or conditions of the patient and to present to a doctor a treatment cost profile for each of the two or more treatment plans.

34. The system of claim 33, wherein the doctor interface module is further configured: to use, as a user interface device, a personal tablet computer temporarily assigned to the patient while the patient is with the doctor at a clinic,

to receive, from a clinic server for the clinic, information about the patient associated with the tablet computer,

to receive, from the doctor using the tablet computer of the patient, information identifying the two or more treatment plans, and

to display on the tablet computer a treatment cost profile for each of the two or more treatment plans.

35. A system comprising:

a plurality of tablets, where each tablet is a personal tablet computer; and a clinic server providing services to a medical clinic, the clinic server comprising one or more computers and one or more storage devices storing instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform operations comprising:

receiving data indicating that an arbitrary one of the tablets is temporarily assigned to a patient of the clinic while the patient is at the clinic;

providing practice management support for the clinic, including:

providing to doctors insurance coverage and formulary information at the time the doctors are prescribing treatments and medications; and

optimizing patient visit schedules according to resource availability and prescribed treatment plans;

providing business decision support for the medical clinic, including: managing the ordering and stocking of medications as required for prescribed treatment plans; and

managing claims and payments relating to prescribed and completed services; and

communicating with the patient through the tablet assigned to the patient, including presenting questionnaires to the patient to fill out on the tablet and receiving completed questionnaires from the patient.

36. The system of claim 35, wherein the clinic server operations further comprise:

receiving diagnoses, prescriptions and treatment plans from a doctor at the clinic using the tablet assigned to the patient.

37. The system of claim 35, wherein the services for communicating with the patient through the tablet assigned to the patient further include:

instant messaging between members of the clinic staff and the patient;

presenting forms to the patient for signature and receiving signed forms from the patient, the signing being done on the tablet;

local messaging from the clinic server to the patient to advise the patient of a current status and schedule of the patient's visit; and

presenting content selected by the patient's doctor on the tablet.

38. A method comprising:

maintaining at a medical clinic a plurality of tablets, wherein each tablet is a personal tablet computer;

temporarily assigning a respective arbitrary one of the tablets to each of multiple patients visiting the clinic to receive a medical service, a tablet being assigned temporarily to a patient while the patient is at the clinic; and

exchanging information with each of the patients through the tablet assigned to the respective patient.

39. The method of claim 38, wherein exchanging information comprises:

presenting a questionnaire on a tablet for the respective patient to fill out on the tablet and receiving completed questionnaires from the patient.

40. The method of claim 38, wherein exchanging information comprises:

presenting consent forms on a tablet for the respective patient for signature and receiving signed forms from the patient, the signing being done on the tablet.

41. The method of claim 38, wherein exchanging information comprises:

presenting on the tablet content selected by the patient's doctor; and

receiving from the tablet confirmation that the patient has read the content.

42. The method of claim 38, wherein exchanging information comprises:

exchanging instant messages between the tablet and members of the clinic staff.

43. The method of claim 38, wherein exchanging information comprises:

sending a message to a patient to advise the patient of a current status and schedule of the patient's visit.

44. The method of claim 38, wherein exchanging information comprises:

presenting copay information to the patient.

45. One or more non-transitory computer storage media encoded with computer program instructions that, when executed by a remote system comprising one or more computers and one or more clinic systems each comprising one or more computers serving a respective corresponding medical clinic, cause the remote system and the clinic systems to perform operations comprising:

on each clinic system:

maintaining clinic patient information for patients of a medical clinic, the clinic patient information including patient identifying information and patient condition information, wherein the patient condition information does not include patient identifying information; and

providing, to the remote system, current patient condition information for clinic patients;

on the remote system:

receiving from the clinic system, and maintaining on the remote system, current patient condition information for patients of the plurality of clinics;

on each clinic system:

receiving data from the remote system identifying patients who are eligible to become members of one or more condition-based social networks; and

46. A computer program product, encoded on one or more non-transitory computer storage media, comprising instructions that when executed by one or more computers cause the one or more computers to perform operations comprising:

defining a plurality of condition-based groups of patients, membership in each group being limited to patients who satisfy a condition-based requirement according to current patient condition information and who have agreed to be members of such a group; and

providing a group-based patient-to-patient communication facility enabling members of each respective group to communicate with other members the respective group, communication through the facility being limited to group members.

47. One or more non-transitory computer storage media encoded with computer program instructions that, when executed by a remote system comprising one or more computers and one or more clinic systems each comprising one or more computers serving a respective corresponding medical clinic, cause the remote system and the clinic systems to perform operations comprising:

on each clinic system:

maintaining clinic patient information for patients of the corresponding clinic, the clinic patient information including patient identifying information and patient condition information, wherein the patient condition information does not include patient identifying information;

providing, to the remote system, current patient condition information for clinic patients; and

on the remote system:

48. One or more non-transitory computer storage media encoded with computer program instructions that, when executed by a remote system comprising one or more computers and one or more clinic systems each comprising one or more computers serving a respective corresponding medical clinic, cause the remote system and the clinic systems to perform operations comprising:

on each clinic system:

on the remote system:

49. A non-transitory computer storage medium encoded with computer program instructions that when executed by one or more computers cause the one or more computers to perform operations comprising:

receiving input data identifying a patient profile, a medical condition, an insurance plan, and a treatment plan;

producing output data representing a predicted lifetime cost of the treatment plan for a patient having the patient profile, medical condition and insurance plan, the output data representing a treatment cost profile, the treatment cost profile including an estimate of costs that will be incurred and at what times the costs will be incurred, which of the costs the insurance plan will pay, and which of the costs the patient will be responsible for; and

receiving from a user data identifying a patient and two or more treatment plans for the medical condition or conditions of the patient; and

presenting to the a treatment cost profile for each of the two or more treatment plans.

50. The medium of claim 49, the operations further comprising:

maintaining a patient data repository, the patient data repository storing current patient information, the patient information including data identifying one or more current medical conditions and a current insurance plan; and

maintain an insurance data repository, the insurance data repository storing insurance coverage information specifying coverage parameters for multiple treatment plans under each of multiple insurance plans.

51. A non-transitory computer storage medium encoded with computer program instructions that when executed by one or more computers cause the one or more computers to perform operations comprising:

receiving an input indicating that a tablet is temporarily assigned to a patient of a medical clinic while the patient is at the clinic, the tablet being a personal tablet computer;

interfacing with a practice management support system for the clinic to perform operations including:

providing to doctors at the clinic insurance coverage and formulary information at the time the doctors are prescribing treatments and medications; and optimizing patient visit schedules according to resource availability and prescribed treatment plans;

managing the ordering and stocking of medications as required for prescribed treatment plans;

managing claims and payments relating to prescribed and completed services; and communicating with the patient through the tablet assigned to the patient, including presenting questionnaires to the patient to fill out on the tablet and receiving completed questionnaires from the patient.

52. A system comprising:

a plurality of tablets, where each tablet is a personal tablet computer;

a clinic computer system providing services to a medical clinic, the clinic computer system comprising one or more computers and one or more storage devices; and

a mobile connection infrastructure implementing wireless connections between the tablets and the clinic computer system over a wireless network, wherein the mobile connection infrastructure is configured to use location-based security to prevent tablets physically outside the clinic from gaining access to the wireless network;

wherein the clinic computer system is configured to perform operations comprising:

establishing a temporary association of the patient with the tablet assigned to the patient while the patient is at the clinic; and

exchanging information with the patient through the tablet assigned to the patient while the patient is at the clinic.

53. The system of claim 52, wherein the clinic server is configured to determine the locations of tablets within the clinic.

54. The system of claim 52, wherein exchanging information with the patient through the tablet assigned to the patient comprises:

55. The system of claim 52, wherein exchanging information with the patient through the tablet assigned to the patient comprises:

56. The system of claim 52, wherein exchanging information with the patient through the tablet assigned to the patient comprises:

57. The system of claim 52, wherein exchanging information with the patient through the tablet assigned to the patient comprises:

presenting on the tablet content selected by the patient's doctor; and

receiving from the tablet confirmation that the patient has read the content.

58. The system of claim 52, wherein exchanging information with the patient through the tablet assigned to the patient comprises:

exchanging instant messages between the tablet and members of the clinic staff.

59. The system of claim 52, further comprising:

a remote system, the remote system comprising one or more computers in communication with the clinic computer system, wherein the remote system is configured to automatically log in each patient temporarily associated with a tablet as a member of a social network while the patient is associated with the tablet.

60. The system of claim 52, further comprising:

a doctor interface module that is configured to perform operations comprising: using, as a user interface device, a tablet temporarily assigned to a patient while the patient is with the doctor at a clinic, and

receiving, from the clinic computer system, information about the patient associated with the tablet.