WO2012151402A1 - Suivi et gestion de soins à des patients dans des cliniques médicales - Google Patents

Suivi et gestion de soins à des patients dans des cliniques médicales Download PDF

Info

Publication number
WO2012151402A1
WO2012151402A1 PCT/US2012/036323 US2012036323W WO2012151402A1 WO 2012151402 A1 WO2012151402 A1 WO 2012151402A1 US 2012036323 W US2012036323 W US 2012036323W WO 2012151402 A1 WO2012151402 A1 WO 2012151402A1
Authority
WO
WIPO (PCT)
Prior art keywords
patient
clinic
information
patients
condition
Prior art date
Application number
PCT/US2012/036323
Other languages
English (en)
Inventor
Sanjeev Yeshwan DHARAP
Original Assignee
Patientscribe Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Patientscribe Inc. filed Critical Patientscribe Inc.
Publication of WO2012151402A1 publication Critical patent/WO2012151402A1/fr

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms

Definitions

  • 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
  • Some such systems are offered for installation on computers belonging to the medical practice; others are offered as software as a service solutions.
  • 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.
  • 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.
  • 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.
  • patients and clinic staff can interact with each other and with the system from anywhere in a clinic.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • a clinic server 200 will be dedicated to and serve only one clinic.
  • 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.
  • 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.
  • 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).
  • 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 AndroidTM operating system from Google Inc. of Mountain View, California.
  • 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.
  • WPA2 Wi-Fi Protected Access 2
  • the clinic infrastructure optionally includes conventional technologies that enable the system to locate mobile devices 220 within the clinic.
  • 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.
  • 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.
  • 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.
  • the patient 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.
  • the EPad can be associated with the patient using an automatic
  • 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.
  • 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.
  • 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).
  • 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).
  • the EPad 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.
  • 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).
  • a nurse can use the patient's EPad to record clinical information, e.g., blood pressure, pulse, or weight.
  • 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.
  • 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.
  • a doctor can select a treatment plan, including selecting and scheduling one or more procedures at the clinic and prescribing concomitant regimens of medication.
  • 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.
  • the system can automatically request preauthorization as may be required by the patient's healthcare insurer prior to each visit.
  • 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.
  • 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.
  • the system provides instant access to the patient's health records.
  • the system can make
  • the information provided to the doctor can include information received by the system from test manufacturers and other sources.
  • 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.
  • the system can provide printed or electronic copies of the patient's records for use by the patient.
  • 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.
  • 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.
  • 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.
  • 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.
  • content e.g., text, graphics and multimedia content
  • the system can also provide services to the patient when the patient is not at the clinic.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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 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 electronically
  • the system can communicate with a secure off-site backup facility 560 that provides off-site data backup and disaster recovery facilities.
  • pharmacies 562 reporting the filling of prescriptions by patients.
  • the system can communicate using the facilities of a data communication network 550, e.g., the Internet, or other data communication resources.
  • 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).
  • 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.
  • modules 600 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.
  • 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.
  • 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.
  • EMR electronic medical records
  • 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.
  • 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.
  • 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.
  • SI 702a and S2 702b are clinic servers that 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the clinic system can provide updates when changes occur in the information.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • the clinic system can provide updates when changes occur in the information.
  • 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.
  • 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
  • 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.
  • 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.
  • the clinic system can provide updates when changes occur in the information.
  • 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.
  • the contact information is simply the name of the doctor and contact information for the respective clinic.
  • 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.
  • the clinic system can provide updates when changes occur in the information.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • the system can also receive diagnoses, prescriptions and treatment plans from a doctor at the clinic using the tablet assigned to the patient.
  • 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.
  • 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.
  • 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.
  • 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.
  • JDBC Java DataBase Connectivity
  • ODBC Open Database Connectivity
  • API native application programming interface
  • 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.
  • PMS practice management system
  • the interface module can be used to communicate with other clinic resources, an electronic medical records system (EMR), for example.
  • EMR electronic medical records system
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • mass storage devices for storing data
  • a computer need not have such devices.
  • 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.
  • PDA personal digital assistant
  • GPS Global Positioning System
  • USB universal serial bus
  • 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;
  • 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.
  • 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.
  • a display device e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor
  • keyboard and a pointing device e.g., a mouse or a trackball
  • 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.
  • 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

Landscapes

  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Biomedical Technology (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

La présente invention concerne des procédés, des systèmes et un appareil, comportant des programmes informatiques codés sur des supports de stockage informatiques, servant au suivi et à la gestion de soins administrés à un patient dans des cliniques médicales. De tels systèmes sont caractérisés en ce qu'ils peuvent créer à la volée une condition basée sur des réseaux pour des patients et des médecins, ou fournir à la volée des moyens de communication basés sur une condition pour des patients et des médecins, en ce qu'ils peuvent fournir de tels réseaux et moyens pour des patients ou des médecins de multiple cliniques, ou fournir des moyens de communication pour des informations et des services entre des cliniques externes et des médecins et des patients, ou fournir une assistance décisionnelle comprenant des coûts de cycle de vie comparatifs de multiples options de traitement, ou prendre en charge une affectation provisoire de dispositifs informatiques individuels aux patients durant leurs visites dans les cliniques et l'utilisation des dispositifs pour communiquer avec des patients dans la clinique.
PCT/US2012/036323 2011-05-03 2012-05-03 Suivi et gestion de soins à des patients dans des cliniques médicales WO2012151402A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201161482110P 2011-05-03 2011-05-03
US61/482,110 2011-05-03

Publications (1)

Publication Number Publication Date
WO2012151402A1 true WO2012151402A1 (fr) 2012-11-08

Family

ID=47108047

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2012/036323 WO2012151402A1 (fr) 2011-05-03 2012-05-03 Suivi et gestion de soins à des patients dans des cliniques médicales

Country Status (1)

Country Link
WO (1) WO2012151402A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015095187A1 (fr) * 2013-12-20 2015-06-25 Medidata Solutions, Inc. Procédé et appareil pour générer un budget d'essai clinique
US10892041B2 (en) 2013-12-20 2021-01-12 Medidata Solutions, Inc. Method and apparatus for determining complexity of a clinical trial
CN112786188A (zh) * 2021-02-05 2021-05-11 北京致医健康信息技术有限公司 辅助诊断系统的离线工作方法、装置、终端设备及介质
CN114864070A (zh) * 2022-04-28 2022-08-05 福建自贸试验区厦门片区Manteia数据科技有限公司 放疗信息管理系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010041991A1 (en) * 2000-02-09 2001-11-15 Segal Elliot A. Method and system for managing patient medical records
US20050187797A1 (en) * 1997-10-29 2005-08-25 Janice Johnson Method and system for consolidating and distributing information
US20060184393A1 (en) * 2004-12-29 2006-08-17 Ewin Leon H Online medical data collection
US20100071044A1 (en) * 2008-09-17 2010-03-18 Taussif Khan Method for tracking location of patients and doctors in a medical office or hospital practice
US20100070306A1 (en) * 2008-09-12 2010-03-18 Dvorak Carl D Patient Community System With Anonymized Electronic Medical Data

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050187797A1 (en) * 1997-10-29 2005-08-25 Janice Johnson Method and system for consolidating and distributing information
US20010041991A1 (en) * 2000-02-09 2001-11-15 Segal Elliot A. Method and system for managing patient medical records
US20060184393A1 (en) * 2004-12-29 2006-08-17 Ewin Leon H Online medical data collection
US20100070306A1 (en) * 2008-09-12 2010-03-18 Dvorak Carl D Patient Community System With Anonymized Electronic Medical Data
US20100071044A1 (en) * 2008-09-17 2010-03-18 Taussif Khan Method for tracking location of patients and doctors in a medical office or hospital practice

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015095187A1 (fr) * 2013-12-20 2015-06-25 Medidata Solutions, Inc. Procédé et appareil pour générer un budget d'essai clinique
US10892041B2 (en) 2013-12-20 2021-01-12 Medidata Solutions, Inc. Method and apparatus for determining complexity of a clinical trial
CN112786188A (zh) * 2021-02-05 2021-05-11 北京致医健康信息技术有限公司 辅助诊断系统的离线工作方法、装置、终端设备及介质
CN114864070A (zh) * 2022-04-28 2022-08-05 福建自贸试验区厦门片区Manteia数据科技有限公司 放疗信息管理系统

Similar Documents

Publication Publication Date Title
US11881291B2 (en) Patient directed data synchronization of electronic health records using a patient controlled health record
US20180039737A1 (en) Patient directed data synchronization of electronic health records using a patient controlled health record
AU2016206450B2 (en) Healthcare data interchange system and method
US10665334B2 (en) Method and system for automated healthcare care coordination and care transitions
Curtis et al. Four health data networks illustrate the potential for a shared national multipurpose big-data network
US20170116384A1 (en) Systems and methods for computerized patient access and care management
US20100082369A1 (en) Systems and Methods for Interconnected Personalized Digital Health Services
Meinert et al. The internet of things in health care in oxford: protocol for proof-of-concept projects
EP2751771A1 (fr) Système de gestion de santé
US20190311791A1 (en) System and method for patient-centric universal health recording and payment
US20200258609A1 (en) Medical communication and management platform
US10847256B2 (en) System and computer program for healthcare information management in a multi-party healthcare network
WO2012151402A1 (fr) Suivi et gestion de soins à des patients dans des cliniques médicales
US20230317301A1 (en) Systems and methods for enhanced networking and remote communications
US20150379215A1 (en) Automated Waiting Room Queue and Management Service
US20140297308A1 (en) Referral and record sharing systems and methods
US20220148693A1 (en) Patent-centric health care system
US20240212806A1 (en) Method and system for patient care using a patient controlled health record
US20230039151A1 (en) Digital Healthcare Tracking and Coordination for Family and Friends
US20230290523A1 (en) System and method for healthcare management
CA2950629A1 (fr) Application de soins de sante reliant les patients aux centres d'urgence et de soins d'urgence et assurant une admission rapide du patient
WO2017064626A1 (fr) Système et procédé pour fournir des soins médicaux par accès instantané au patient
Priolo SINI 2022: Crisp HIE Management of Healthcare Data to Promote Population Health
Lakkaraju et al. Mobile Device Application in Healthcare
Daradkah A Cloud Model for Integrated Healthcare Informatics Solution: HealthGate Cloud (HGC)

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12779415

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12779415

Country of ref document: EP

Kind code of ref document: A1