US20060143050A1 - Healthcare management system using patient profile data - Google Patents
Healthcare management system using patient profile data Download PDFInfo
- Publication number
- US20060143050A1 US20060143050A1 US11/023,306 US2330604A US2006143050A1 US 20060143050 A1 US20060143050 A1 US 20060143050A1 US 2330604 A US2330604 A US 2330604A US 2006143050 A1 US2006143050 A1 US 2006143050A1
- Authority
- US
- United States
- Prior art keywords
- patient
- medical
- data
- provider
- rule
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/08—Insurance
-
- 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
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- 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
-
- 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/60—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 operation of medical equipment or devices
- G16H40/63—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 operation of medical equipment or devices for local operation
Definitions
- This invention is related to medical systems and more particularly to systems and methods for providing medical alerts based on consolidation of a patient's medical information.
- Healthcare providers such as physicians, druggists, nurses, and even the patient him or her self have only a limited view of health-related information pertaining to that patient which is necessary to make properly informed decisions.
- One limitation is the unavailability of the full range of data needed at a given time to make a fully informed medical decision.
- Another limitation is the inability to track data between different providers or between different visits to the same provider. For discussion, a visit is any contact with anyone in the chain of healthcare provision, including payors, claims processors, laboratories or pharmacists.
- Another problem with the scenario discussed above is that when the provider does make a decision on treatment, he/she then tells the patient to go off and do something and to call if there is a problem. Unless the patient calls with a problem, the provider does not have any insight into what is happening to the patient. This is not a prudent way to manage a person's health and is particularly troublesome when the patient has a chronic illness.
- the present disclosure is directed to a system and method which gathers information from all of a person's healthcare providers and abstracts from that information the data necessary for a healthcare provider to render informed medical decisions.
- information necessary to process proper payment to a provider (re: reimbursement to the insured patent) is used to develop a holistic view of the medical condition pertaining to the patient. Since this information comes from a myriad of providers, including physicians, surgeons, nurse case managers, druggists, testing labs, mental health counselors, dentists, oral surgeons, etc., the holistic view that is developed is comprehensive.
- system and method could set parameters on critical data such that if that data is outside the set parameters, alerts can be sent to the appropriate caregivers and/or patients.
- FIG. 1 is one embodiment of a system and method for consolidating medical information from a myriad of healthcare providers
- FIG. 2 is a flow chart of one embodiment of system operation.
- the forms which are filed (usually electronically) by healthcare providers for reimbursement from payors contain clinical data pertaining to the patient.
- health care plans use pharmacy benefit management companies (PBMs) to evaluate and pay pharmacy claims. This process of verification generates pharmacy data which then compliment the treatment and diagnostic data obtained from doctors.
- PBMs pharmacy benefit management companies
- This process of verification generates pharmacy data which then compliment the treatment and diagnostic data obtained from doctors.
- a physician orders diagnostic tests, (laboratory, imagine, etc. tests), the test costs are billed for either by the ordering physician or by the providing physician, such as by a radiologist.
- the claim for payment also goes to the payor. In most situations the actual test results are available in electronic format and will also go the payor.
- the system and method described herein takes advantage of the fact that all of this data funnels through a common point and can be used to provide a comprehensive holographic view of a patient's health.
- the health plan acts as the aggregator of information pertaining to its members and that aggregated information is used to create a meaningful representation of the medical profile of the member.
- system 10 shows one embodiment of a system and method for consolidating medical information from diverse sources, such as Service Provider 11 , to give a consolidated profile of a patient.
- Service provider 11 represents service providers which could encompass test lab 101 , pharmacies 102 , hospitals 103 , and physicians 104 . Claims from any provider are submitted to a patient's insurer 12 . Others, such as the user, user's family, or even unrelated systems such as, for example, a credit card profile system, shown as 121 . At least a portion of the information coming from these various diverse sources is stored in database 13 . While it is contemplated that the raw data be stored in database 13 it could be that only abstracted data (such as above or below limit data) is so stored. Also note that database. 13 could accept data from other insurers 19 which could occur, for example, if a patient were to have multiple insurers (husband and wife; private and government, etc).
- physician A has prescribed a particular medication for a patient and physician B, possibly because that patient failed to inform physician B of the medication he/she is taking, prescribed another medication that might be dangerous when mixed with the first medication or possibly negates the effects of the first medication.
- the system would generate an alert to the patient and, if desired, to both physicians A and B.
- the reason the alert can be delivered is because of the composite view of a patient's medical history as obtained from payment records. Since the system is based upon data coming to a payor for reimbursement, over-the-counter medicines or medicines that are not paid for by the provider will only get into the system if the patient (or someone acting for the patient) sends in the data.
- the physician cannot take phone calls from patients every day and calculate changes to air flow, but the provider could set the system to accept a patient's input and to call (alerts) when certain limits are met.
- patients can input symptoms, such as coughing, vomiting, chest pain, headaches, temperature, blood pressure, etc., and this data can be used to trigger an alert based either on a general group rule, or on parameters set individually for that patient.
- Compliance by a patient is another major concern.
- the provider asks a patient to take a medication, monitor peak air flow to lungs, check blood sugar, see a specialist, etc.
- the provider does not know whether the patient has complied or not.
- the provider will be notified if certain values decrease or change or hit a certain level. Alerts will be generated if the values are missing, i.e., not put in for two or three consistent days, etc. Also, missing data could be that a prescription has not been filled (or refilled on time), thereby initiating an alert.
- FIG. 2 shows one embodiment of system 20 where process 201 receives reimbursement information (a payment claim) from any one of a number of medical providers.
- This information contains within it enough information so that the third party payor can process the payment to determine how much will be reimbursed.
- This reimbursement can be sent directly to the provider or sometimes it is sent to the patient.
- Each such claim must contain with it enough information so that the payor can properly determine the procedure that was performed, and whether the patient is eligible for reimbursement and what the limits are.
- the provider sends minimal information that certain tests have been performed and does not send the actual test results. However, in some situations, the actual test scores are sent with the payment claim information.
- Pharmacies send in the prescription and sometimes also the diagnosis along with their claim information. In FIG. 1 this information is shown coming from service providers 11 and goes directly to insurer 12 but the data could pass through adapters 120 designed such that the data from each provider is converted so that pertinent data can be removed, as desired, for storage in patient profile storage 13 .
- process 201 will process data from a patient, such as from patient 105 ( FIG. 1 ) This data could be test results that have been self-administered, such as blood sugar levels, peak flow levels, blood pressure, temperature, or any other measurable physiological (or environmental) parameter that is necessary for a medical diagnosis.
- a patient can input symptomatic information, such as chest pain, coughing, vomiting, or any other type of occurrence such as blurry vision, or abdominal pain, all of which will be received by process 201 and processed to become part of the patient profile information stored in storage 13 .
- Process 202 either before the information is stored in patient profile 13 or thereafter, and with or without the help of adaptors 120 , creates an abstract of the information to determine certain information. For example, process 202 could look at various pieces of information and conclude that a patient is a diabetic. This would be concluded, for example, by looking at the medication the patient is taking, patient hospital visits, supplied lab test results, etc., and applying rules under control of rules engine 18 ( FIG. 1 ) to conclude that this patient is in a group of diabetics. Other types of information could lead to an abstracting of a patient so that the patient is classified as a heart patient, a pregnant patient, etc. Each of these categories could then require the further abstracting of information to determine from symptoms provided by the patient when to send an alarm.
- the profile could be organized chronologically for all information, or chronologically for a particular test (such as MRIs) or could be organized in any manner desired. This profile could be made available to a provider or payor when desired and in the manner desired.
- a patient is classified as having heart failure, then upon receiving information from a patient that the patient is having night time cough, the system would, based upon process 204 , determine that this patient (or his/her health care provider) needs be alerted.
- the system is established such that an administrator, who could be a doctor, could establish parameters that would apply to all of the patients in the database. This information would apply to the whole population of patients falling within the rules for the group. Within each group each physician could establish specific parameters for his/her specific patients.
- Process 203 stores the pertinent data either in patient profile storage 13 or in other storage and based upon rules established by rules engine 18 .
- Process 205 determines if an alert is necessary. If an alert should be sent, such an alert will be processed via process 206 to determine what type of an alert, who the alert should go to, and how, and will also determine what type of data should be supplied.
- Process 207 sends the alert to one or more providers, other third parties, or to the patient, as desired.
- Process 208 determines if data is being requested by a physician. This could occur, for example, if a patient shows up in an emergency room of a hospital seeking emergency care. An attending doctor then might request the system to provide an abstract of conditions that would be critical to know how to render proper informed medical assistance. For example, if the patient is diabetic, or is known to be on a medication to thin the blood, the doctor will be so informed. Note that sending a surgeon who is about to perform an operation an entire medical history of the patient is not what is required. What is required at this point is specific characterizations of the patient so that the surgeon can take proper steps. Process 209 handles this task.
- Process 209 determines the proper data or portion of the data or abstract of the data and tailors the report to the requester based upon the nature of the request.
- Process 210 then delivers the report and data to the proper destination. This delivery both from process 210 or process 207 can be, for example, via the Internet or a telephone call or any other type of message, whether wireless or wire line.
- a reminder to refill a prescription can be sent to a patient when a prescription is not filled on time or when a suggested specialist has not been visited.
- Actual insurance reimbursement for future medical visits could, if desired, be dependant upon compliance.
- Notification to a patient may, for instance, be sent to a patient that he/she should not take both of the drugs prescribed (perhaps by different doctors) because one of the drugs has the ingredients of the other. Based on the severity of that situation (for example, two drugs prescribed which are contra-indicated for use with each other), it may be desired to send a message to the caregiver.
- Messages could be delivered warning a patient of expected symptoms when certain medication, or combination of medications, are being taken.
- post-operative suggestions can be sent to patients who have just had a certain procedure performed.
- preliminary diagnosis is possible based upon all of the information that is available. For example, assume a patient (or a provider) enters into the system, (either directly or abstracted from a claims form) a certain set of symptoms. Assume also that these symptoms suggest a disease known to be prevalent in a certain part of the world. The system then could examine the travel records (as obtained from credit card abstracts or airline records) and note to the provider (or to the patient) the fact that the symptoms may be related to the patient's recent trip to a certain country.
- any such message must be HIPPAA compliant and thus secure e-mail, personal telephone calls, may be necessary.
- the message can take any form, such as “Dear Patient, we do not see that you have reordered your XYZ medication. If there is a problem, please call us or please refill it now. Thanks, Your Doctor.” If the prescription remains unfilled on day five, an alert would go to the doctor as an indication that perhaps the doctor needs to call the patient to see what is going on.
- Rules could be, for example, entered into the database to the effect that all males over the age of 50 who have not had a PSA in the last year are identified. Based on such a rule, alerts would be sent to each identified patient and to each patient's provider For those patients who must be seen by a provider at periodic times, reminders can be sent and these reminders could, if desired, already have attached a scheduled provider visit. This could, for example, be accomplished using scheduler 120 ( FIG. 1 ) which would be updated (or synchronized) by each provider's office in the same manner as synchronism occurs in PDA calendars.
Abstract
Description
- The present application is related to concurrently filed, co-pending, and commonly assigned U.S. patent application Ser. No. ______, [Attorney Docket No. 66729/P021US/10409827], entitled “SYSTEM AND METHOD FOR SELECTING HEALTHCARE MANAGEMENT”, the disclosure of which is hereby incorporated herein by reference.
- This invention is related to medical systems and more particularly to systems and methods for providing medical alerts based on consolidation of a patient's medical information.
- Healthcare providers, such as physicians, druggists, nurses, and even the patient him or her self have only a limited view of health-related information pertaining to that patient which is necessary to make properly informed decisions. One limitation is the unavailability of the full range of data needed at a given time to make a fully informed medical decision. Another limitation is the inability to track data between different providers or between different visits to the same provider. For discussion, a visit is any contact with anyone in the chain of healthcare provision, including payors, claims processors, laboratories or pharmacists.
- By way of example, assume a person visits a doctor with a particular problem. The doctor (assuming it's the patients regular doctor) will know about chronic illnesses, such as diabetes, etc. of that patient. But what the doctor does not know is whether the patient has filled the last Rx and if he/she has, taken the medicine regularly. The healthcare provider may or may not know what other healthcare providers may have prescribed, and may or may not have lab test results ordered by other providers. Thus, when treatment is rendered it is done so without access to a wide body of knowledge pertaining to the patient.
- Another problem with the scenario discussed above is that when the provider does make a decision on treatment, he/she then tells the patient to go off and do something and to call if there is a problem. Unless the patient calls with a problem, the provider does not have any insight into what is happening to the patient. This is not a prudent way to manage a person's health and is particularly troublesome when the patient has a chronic illness.
- The present disclosure is directed to a system and method which gathers information from all of a person's healthcare providers and abstracts from that information the data necessary for a healthcare provider to render informed medical decisions. In one embodiment, information necessary to process proper payment to a provider (re: reimbursement to the insured patent) is used to develop a holistic view of the medical condition pertaining to the patient. Since this information comes from a myriad of providers, including physicians, surgeons, nurse case managers, druggists, testing labs, mental health counselors, dentists, oral surgeons, etc., the holistic view that is developed is comprehensive.
- In one embodiment, the system and method could set parameters on critical data such that if that data is outside the set parameters, alerts can be sent to the appropriate caregivers and/or patients.
- The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated that the conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized that such equivalent constructions do not depart from the invention as set forth in the appended claims. The novel features which are believed to be characteristic of the invention, both as to its organization and method of operation, together with further objects and advantages will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the present invention.
- For a more complete understanding of the present invention, reference is now made to the following descriptions taken in conjunction with the accompanying drawing, in which:
-
FIG. 1 is one embodiment of a system and method for consolidating medical information from a myriad of healthcare providers; and -
FIG. 2 is a flow chart of one embodiment of system operation. - The forms which are filed (usually electronically) by healthcare providers for reimbursement from payors contain clinical data pertaining to the patient. In addition, health care plans use pharmacy benefit management companies (PBMs) to evaluate and pay pharmacy claims. This process of verification generates pharmacy data which then compliment the treatment and diagnostic data obtained from doctors. In addition, when a physician orders diagnostic tests, (laboratory, imagine, etc. tests), the test costs are billed for either by the ordering physician or by the providing physician, such as by a radiologist. The claim for payment also goes to the payor. In most situations the actual test results are available in electronic format and will also go the payor.
- The system and method described herein takes advantage of the fact that all of this data funnels through a common point and can be used to provide a comprehensive holographic view of a patient's health. Thus, in the disclosed system and method, the health plan acts as the aggregator of information pertaining to its members and that aggregated information is used to create a meaningful representation of the medical profile of the member.
- Turning now to
FIG. 1 ,system 10 shows one embodiment of a system and method for consolidating medical information from diverse sources, such asService Provider 11, to give a consolidated profile of a patient.Service provider 11 represents service providers which could encompasstest lab 101,pharmacies 102,hospitals 103, andphysicians 104. Claims from any provider are submitted to a patient'sinsurer 12. Others, such as the user, user's family, or even unrelated systems such as, for example, a credit card profile system, shown as 121. At least a portion of the information coming from these various diverse sources is stored indatabase 13. While it is contemplated that the raw data be stored indatabase 13 it could be that only abstracted data (such as above or below limit data) is so stored. Also note that database. 13 could accept data fromother insurers 19 which could occur, for example, if a patient were to have multiple insurers (husband and wife; private and government, etc). - Assuming
patient 16 usedprovider 15 as a primary provider but also used other providers 17 (cardiologist, diabetic specialist, obstetrician/gynecologist), it could be appropriate for any one or more of these providers to set “rules” for the patient. These rules could pertain to filling and refilling a prescription, taking and sending certain monitored readings (sugar levels, air flow, etc.), limits on certain readings, etc. These rules are stored inrules engine 18 on a patient-by-patient basis and when a rule has been attained (i.e., a certain monitored fact is outside a limit), thenmonitor application 14 sends a message, (e-mails, telephone, fax, etc) to provider 15 (and possibly also to one or more other parties, including the patient). - Claims are submitted from various service providers, as well as the patient, and these claims may be formatted differently based on the reason for the data exchange. To handle such a situation, proper interfacing between systems is required and this is handled by adaptors, such as
adapters 120. - One example of how the system and method could work is where physician A has prescribed a particular medication for a patient and physician B, possibly because that patient failed to inform physician B of the medication he/she is taking, prescribed another medication that might be dangerous when mixed with the first medication or possibly negates the effects of the first medication. In such a situation, the system would generate an alert to the patient and, if desired, to both physicians A and B. The reason the alert can be delivered is because of the composite view of a patient's medical history as obtained from payment records. Since the system is based upon data coming to a payor for reimbursement, over-the-counter medicines or medicines that are not paid for by the provider will only get into the system if the patient (or someone acting for the patient) sends in the data.
- Another example would be if a patient has asthma and is asked to measure his/her peak air flow daily and to call the physician if the readings go below a certain level. Frequently patients don't follow through with the instructions or are worried about calling (“bothering”) the physician. Using this system a member could go online to record his/her peak flow every day. This on-line data is then sent to the system. A rule is set up in the system that says: if air flow falls below a certain level, or if there is a significant downward trend, issue an Alert Thus, even if the patient is not at the critical stage, alerts are sent and trouble can be averted. The physician cannot take phone calls from patients every day and calculate changes to air flow, but the provider could set the system to accept a patient's input and to call (alerts) when certain limits are met. In addition, patients can input symptoms, such as coughing, vomiting, chest pain, headaches, temperature, blood pressure, etc., and this data can be used to trigger an alert based either on a general group rule, or on parameters set individually for that patient.
- Compliance by a patient is another major concern. For example, the provider asks a patient to take a medication, monitor peak air flow to lungs, check blood sugar, see a specialist, etc. In reality, the provider does not know whether the patient has complied or not. When the patient ends up in the emergency room because of failure to follow directions it is often too late for help. However, using the system and method described herein, the provider will be notified if certain values decrease or change or hit a certain level. Alerts will be generated if the values are missing, i.e., not put in for two or three consistent days, etc. Also, missing data could be that a prescription has not been filled (or refilled on time), thereby initiating an alert.
- These are all examples of the power obtained when the medical history of a patient can be generated and continually monitored based upon an abstraction of data meant for another purpose, namely payment information.
-
FIG. 2 shows one embodiment ofsystem 20 whereprocess 201 receives reimbursement information (a payment claim) from any one of a number of medical providers. This information contains within it enough information so that the third party payor can process the payment to determine how much will be reimbursed. This reimbursement can be sent directly to the provider or sometimes it is sent to the patient. Each such claim must contain with it enough information so that the payor can properly determine the procedure that was performed, and whether the patient is eligible for reimbursement and what the limits are. Often the provider sends minimal information that certain tests have been performed and does not send the actual test results. However, in some situations, the actual test scores are sent with the payment claim information. Pharmacies send in the prescription and sometimes also the diagnosis along with their claim information. InFIG. 1 this information is shown coming fromservice providers 11 and goes directly toinsurer 12 but the data could pass throughadapters 120 designed such that the data from each provider is converted so that pertinent data can be removed, as desired, for storage inpatient profile storage 13. - In addition,
process 201 will process data from a patient, such as from patient 105 (FIG. 1 ) This data could be test results that have been self-administered, such as blood sugar levels, peak flow levels, blood pressure, temperature, or any other measurable physiological (or environmental) parameter that is necessary for a medical diagnosis. In addition a patient can input symptomatic information, such as chest pain, coughing, vomiting, or any other type of occurrence such as blurry vision, or abdominal pain, all of which will be received byprocess 201 and processed to become part of the patient profile information stored instorage 13. -
Process 202, either before the information is stored inpatient profile 13 or thereafter, and with or without the help ofadaptors 120, creates an abstract of the information to determine certain information. For example,process 202 could look at various pieces of information and conclude that a patient is a diabetic. This would be concluded, for example, by looking at the medication the patient is taking, patient hospital visits, supplied lab test results, etc., and applying rules under control of rules engine 18 (FIG. 1 ) to conclude that this patient is in a group of diabetics. Other types of information could lead to an abstracting of a patient so that the patient is classified as a heart patient, a pregnant patient, etc. Each of these categories could then require the further abstracting of information to determine from symptoms provided by the patient when to send an alarm. The profile could be organized chronologically for all information, or chronologically for a particular test (such as MRIs) or could be organized in any manner desired. This profile could be made available to a provider or payor when desired and in the manner desired. - For example, if a patient is classified as having heart failure, then upon receiving information from a patient that the patient is having night time cough, the system would, based upon
process 204, determine that this patient (or his/her health care provider) needs be alerted. - The system is established such that an administrator, who could be a doctor, could establish parameters that would apply to all of the patients in the database. This information would apply to the whole population of patients falling within the rules for the group. Within each group each physician could establish specific parameters for his/her specific patients.
-
Process 203, as discussed, stores the pertinent data either inpatient profile storage 13 or in other storage and based upon rules established byrules engine 18.Process 205 determines if an alert is necessary. If an alert should be sent, such an alert will be processed viaprocess 206 to determine what type of an alert, who the alert should go to, and how, and will also determine what type of data should be supplied.Process 207 sends the alert to one or more providers, other third parties, or to the patient, as desired. -
Process 208 determines if data is being requested by a physician. This could occur, for example, if a patient shows up in an emergency room of a hospital seeking emergency care. An attending doctor then might request the system to provide an abstract of conditions that would be critical to know how to render proper informed medical assistance. For example, if the patient is diabetic, or is known to be on a medication to thin the blood, the doctor will be so informed. Note that sending a surgeon who is about to perform an operation an entire medical history of the patient is not what is required. What is required at this point is specific characterizations of the patient so that the surgeon can take proper steps.Process 209 handles this task. For example, the surgeon need not know the exact sugar levels over the last six months for this patient, but rather the surgeon needs to know that this patient is a diabetic and is on certain types of medication.Process 209 determines the proper data or portion of the data or abstract of the data and tailors the report to the requester based upon the nature of the request.Process 210 then delivers the report and data to the proper destination. This delivery both fromprocess 210 orprocess 207 can be, for example, via the Internet or a telephone call or any other type of message, whether wireless or wire line. - There can also be continuous interaction between the patient and the system so that the patient or provider can set up personalized interventions or recommendations based upon clinical parameters. Thus, a reminder to refill a prescription (or to visit the care giver or a specialist), can be sent to a patient when a prescription is not filled on time or when a suggested specialist has not been visited. Actual insurance reimbursement for future medical visits could, if desired, be dependant upon compliance. Notification to a patient may, for instance, be sent to a patient that he/she should not take both of the drugs prescribed (perhaps by different doctors) because one of the drugs has the ingredients of the other. Based on the severity of that situation (for example, two drugs prescribed which are contra-indicated for use with each other), it may be desired to send a message to the caregiver.
- Messages could be delivered warning a patient of expected symptoms when certain medication, or combination of medications, are being taken. Also, post-operative suggestions can be sent to patients who have just had a certain procedure performed. In some situations preliminary diagnosis is possible based upon all of the information that is available. For example, assume a patient (or a provider) enters into the system, (either directly or abstracted from a claims form) a certain set of symptoms. Assume also that these symptoms suggest a disease known to be prevalent in a certain part of the world. The system then could examine the travel records (as obtained from credit card abstracts or airline records) and note to the provider (or to the patient) the fact that the symptoms may be related to the patient's recent trip to a certain country.
- Note that any such message must be HIPPAA compliant and thus secure e-mail, personal telephone calls, may be necessary. Also note that the message can take any form, such as “Dear Patient, we do not see that you have reordered your XYZ medication. If there is a problem, please call us or please refill it now. Thanks, Your Doctor.” If the prescription remains unfilled on day five, an alert would go to the doctor as an indication that perhaps the doctor needs to call the patient to see what is going on.
- Rules could be, for example, entered into the database to the effect that all males over the age of 50 who have not had a PSA in the last year are identified. Based on such a rule, alerts would be sent to each identified patient and to each patient's provider For those patients who must be seen by a provider at periodic times, reminders can be sent and these reminders could, if desired, already have attached a scheduled provider visit. This could, for example, be accomplished using scheduler 120 (
FIG. 1 ) which would be updated (or synchronized) by each provider's office in the same manner as synchronism occurs in PDA calendars. - While it would always be best to have a complete file, including x-rays, MRIs, lab tests, etc., accessible for a patient when any diagnosis is being made, this would be the exception and not the rule. A next best situation would be if a profile of the patient could be made available. That profile is then made up of data indicating certain important factors. For example, if a medical history of visits, drugs and tests indicates a patient is a diabetic then a provider may only be told the patient is a diabetic and all of the hundreds of test results would not be sent. This abstract profile is, as discussed above, determined by looking at prescriptions, doctors visited and lab tests, as obtained from payment records. Note that simply giving a printout (electronic or otherwise) of all tests, provider visits, etc is overwhelming and not helpful, but providing the proper level of detailed information can be very helpful.
- Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the invention as defined by the appended claims. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one will readily appreciate from the disclosure, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.
Claims (40)
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/023,306 US20060143050A1 (en) | 2004-12-27 | 2004-12-27 | Healthcare management system using patient profile data |
EP05855083A EP1846855A4 (en) | 2004-12-27 | 2005-12-22 | Healthcare management system using patient profile data |
PCT/US2005/046461 WO2006071701A2 (en) | 2004-12-27 | 2005-12-22 | Healthcare management system using patient profile data |
CA002596033A CA2596033A1 (en) | 2004-12-27 | 2005-12-22 | Healthcare management system using patient profile data |
US14/664,979 US10402538B2 (en) | 2004-12-27 | 2015-03-23 | Healthcare management system using patient profile data |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/023,306 US20060143050A1 (en) | 2004-12-27 | 2004-12-27 | Healthcare management system using patient profile data |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/664,979 Continuation US10402538B2 (en) | 2004-12-27 | 2015-03-23 | Healthcare management system using patient profile data |
Publications (1)
Publication Number | Publication Date |
---|---|
US20060143050A1 true US20060143050A1 (en) | 2006-06-29 |
Family
ID=36612911
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/023,306 Abandoned US20060143050A1 (en) | 2004-12-27 | 2004-12-27 | Healthcare management system using patient profile data |
US14/664,979 Active 2027-09-28 US10402538B2 (en) | 2004-12-27 | 2015-03-23 | Healthcare management system using patient profile data |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/664,979 Active 2027-09-28 US10402538B2 (en) | 2004-12-27 | 2015-03-23 | Healthcare management system using patient profile data |
Country Status (4)
Country | Link |
---|---|
US (2) | US20060143050A1 (en) |
EP (1) | EP1846855A4 (en) |
CA (1) | CA2596033A1 (en) |
WO (1) | WO2006071701A2 (en) |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080195420A1 (en) * | 2007-02-09 | 2008-08-14 | Harley Ramelson | Method, computer program product and apparatus for generating integrated electronic health records |
US20090216562A1 (en) * | 2008-02-22 | 2009-08-27 | Faulkner Judith R | Method and apparatus for accommodating diverse healthcare record centers |
US20090228303A1 (en) * | 2008-02-22 | 2009-09-10 | Faulkner Judith R | Electronic health record system utilizing disparate record sources |
US20090271351A1 (en) * | 2008-04-29 | 2009-10-29 | Affiliated Computer Services, Inc. | Rules engine test harness |
US7672858B2 (en) | 2007-04-26 | 2010-03-02 | Accretive Health, Inc. | Best possible payment expected for healthcare services |
US20120253139A1 (en) * | 2011-04-04 | 2012-10-04 | International Business Machines Corporation | Personalized medical content recommendation |
US8682725B2 (en) | 2010-09-14 | 2014-03-25 | Google Inc. | Regional location-based advertising |
US20140249834A1 (en) * | 2013-03-03 | 2014-09-04 | Caradigm Usa Llc | Methods, apparatuses and computer program products for providing techniques for users to create health care solutions |
US20160357921A1 (en) * | 2013-03-15 | 2016-12-08 | Humana Inc. | Computerized system and method to use payer financial transactions to build a clinical intervention plan using a derived patient schedule |
US20180325470A1 (en) * | 2017-05-09 | 2018-11-15 | LifePod Solutions, Inc. | Voice controlled assistance for monitoring adverse events of a user and/or coordinating emergency actions such as caregiver communication |
US11404062B1 (en) | 2021-07-26 | 2022-08-02 | LifePod Solutions, Inc. | Systems and methods for managing voice environments and voice routines |
US11410655B1 (en) | 2021-07-26 | 2022-08-09 | LifePod Solutions, Inc. | Systems and methods for managing voice environments and voice routines |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11651861B2 (en) | 2019-12-19 | 2023-05-16 | International Business Machines Corporation | Determining engagement level of an individual during communication |
Citations (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4567359A (en) * | 1984-05-24 | 1986-01-28 | Lockwood Lawrence B | Automatic information, goods and services dispensing system |
US5655085A (en) * | 1992-08-17 | 1997-08-05 | The Ryan Evalulife Systems, Inc. | Computer system for automated comparing of universal life insurance policies based on selectable criteria |
US5903889A (en) * | 1997-06-09 | 1999-05-11 | Telaric, Inc. | System and method for translating, collecting and archiving patient records |
US5924074A (en) * | 1996-09-27 | 1999-07-13 | Azron Incorporated | Electronic medical records system |
US6208973B1 (en) * | 1998-02-27 | 2001-03-27 | Onehealthbank.Com | Point of service third party financial management vehicle for the healthcare industry |
US20020010597A1 (en) * | 2000-05-19 | 2002-01-24 | Mayer Gregg L. | Systems and methods for electronic health management |
US20020010679A1 (en) * | 2000-07-06 | 2002-01-24 | Felsher David Paul | Information record infrastructure, system and method |
US20020049617A1 (en) * | 1999-12-30 | 2002-04-25 | Choicelinx Corporation | System and method for facilitating selection of benefits |
US20020111835A1 (en) * | 2000-11-06 | 2002-08-15 | Hele John C. R. | Underwriting insurance |
US6456979B1 (en) * | 2000-10-24 | 2002-09-24 | The Insuranceadvisor Technologies, Inc. | Method of evaluating a permanent life insurance policy |
US20020147617A1 (en) * | 2000-04-25 | 2002-10-10 | Michael Schoenbaum | Health cost calculator/flexible spending account calculator |
US20020147867A1 (en) * | 2001-02-20 | 2002-10-10 | Marcia Satlow | Method and system for processing physician claims over a network |
US20030036683A1 (en) * | 2000-05-01 | 2003-02-20 | Kehr Bruce A. | Method, system and computer program product for internet-enabled, patient monitoring system |
US20030130873A1 (en) * | 2001-11-19 | 2003-07-10 | Nevin William S. | Health care provider information system |
US20030191667A1 (en) * | 2002-04-09 | 2003-10-09 | Fitzgerald David | System and user interface supporting use of rules for processing healthcare and other claim data |
US20030191669A1 (en) * | 2002-04-09 | 2003-10-09 | Fitzgerald David | System for providing consumer access to healthcare related information |
US20040064343A1 (en) * | 2000-10-11 | 2004-04-01 | Korpman Ralph A | System for communication of health care data |
US20040117215A1 (en) * | 2000-07-20 | 2004-06-17 | Marchosky J. Alexander | Record system |
US20040122790A1 (en) * | 2002-12-18 | 2004-06-24 | Walker Matthew J. | Computer-assisted data processing system and method incorporating automated learning |
US20040143462A1 (en) * | 2003-01-17 | 2004-07-22 | Hunt Jacquelyn Suzanne | Process and system for enhancing medical patient care |
US20040205664A1 (en) * | 2003-03-25 | 2004-10-14 | Prendergast Thomas V. | Claim data and document processing system |
US20050010446A1 (en) * | 2003-07-11 | 2005-01-13 | Lash Todd Loren | Health benefit plan monitoring system and method |
US20050222867A1 (en) * | 2004-03-31 | 2005-10-06 | Aetna, Inc. | System and method for administering health care cost reduction |
US20060136264A1 (en) * | 2004-12-21 | 2006-06-22 | Gh Global Health Direct, Llc | System and method for improved health care access |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5576952A (en) * | 1993-03-09 | 1996-11-19 | Metriplex, Inc. | Medical alert distribution system with selective filtering of medical information |
US7256708B2 (en) * | 1999-06-23 | 2007-08-14 | Visicu, Inc. | Telecommunications network for remote patient monitoring |
US7379885B1 (en) * | 2000-03-10 | 2008-05-27 | David S. Zakim | System and method for obtaining, processing and evaluating patient information for diagnosing disease and selecting treatment |
US7346522B1 (en) * | 2002-01-08 | 2008-03-18 | First Access, Inc. | Medical payment system |
US20040078228A1 (en) * | 2002-05-31 | 2004-04-22 | Fitzgerald David | System for monitoring healthcare patient encounter related information |
US20040215494A1 (en) * | 2003-04-24 | 2004-10-28 | Wahlbin Stefan L. | Method and system for determining monetary amounts in an insurance processing system |
US20050246205A1 (en) * | 2004-04-29 | 2005-11-03 | Hao Wang | Data sharing infrastructure |
US20060080153A1 (en) * | 2004-10-08 | 2006-04-13 | Fox John L | Health care system and method for operating a health care system |
-
2004
- 2004-12-27 US US11/023,306 patent/US20060143050A1/en not_active Abandoned
-
2005
- 2005-12-22 WO PCT/US2005/046461 patent/WO2006071701A2/en active Application Filing
- 2005-12-22 EP EP05855083A patent/EP1846855A4/en not_active Ceased
- 2005-12-22 CA CA002596033A patent/CA2596033A1/en not_active Abandoned
-
2015
- 2015-03-23 US US14/664,979 patent/US10402538B2/en active Active
Patent Citations (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4567359A (en) * | 1984-05-24 | 1986-01-28 | Lockwood Lawrence B | Automatic information, goods and services dispensing system |
US5655085A (en) * | 1992-08-17 | 1997-08-05 | The Ryan Evalulife Systems, Inc. | Computer system for automated comparing of universal life insurance policies based on selectable criteria |
US5924074A (en) * | 1996-09-27 | 1999-07-13 | Azron Incorporated | Electronic medical records system |
US5903889A (en) * | 1997-06-09 | 1999-05-11 | Telaric, Inc. | System and method for translating, collecting and archiving patient records |
US6208973B1 (en) * | 1998-02-27 | 2001-03-27 | Onehealthbank.Com | Point of service third party financial management vehicle for the healthcare industry |
US20020049617A1 (en) * | 1999-12-30 | 2002-04-25 | Choicelinx Corporation | System and method for facilitating selection of benefits |
US20020147617A1 (en) * | 2000-04-25 | 2002-10-10 | Michael Schoenbaum | Health cost calculator/flexible spending account calculator |
US20030036683A1 (en) * | 2000-05-01 | 2003-02-20 | Kehr Bruce A. | Method, system and computer program product for internet-enabled, patient monitoring system |
US20020010597A1 (en) * | 2000-05-19 | 2002-01-24 | Mayer Gregg L. | Systems and methods for electronic health management |
US20020010679A1 (en) * | 2000-07-06 | 2002-01-24 | Felsher David Paul | Information record infrastructure, system and method |
US20040117215A1 (en) * | 2000-07-20 | 2004-06-17 | Marchosky J. Alexander | Record system |
US20040064343A1 (en) * | 2000-10-11 | 2004-04-01 | Korpman Ralph A | System for communication of health care data |
US6456979B1 (en) * | 2000-10-24 | 2002-09-24 | The Insuranceadvisor Technologies, Inc. | Method of evaluating a permanent life insurance policy |
US20020111835A1 (en) * | 2000-11-06 | 2002-08-15 | Hele John C. R. | Underwriting insurance |
US20020147867A1 (en) * | 2001-02-20 | 2002-10-10 | Marcia Satlow | Method and system for processing physician claims over a network |
US20030130873A1 (en) * | 2001-11-19 | 2003-07-10 | Nevin William S. | Health care provider information system |
US20030191669A1 (en) * | 2002-04-09 | 2003-10-09 | Fitzgerald David | System for providing consumer access to healthcare related information |
US20030191667A1 (en) * | 2002-04-09 | 2003-10-09 | Fitzgerald David | System and user interface supporting use of rules for processing healthcare and other claim data |
US20040122790A1 (en) * | 2002-12-18 | 2004-06-24 | Walker Matthew J. | Computer-assisted data processing system and method incorporating automated learning |
US20040143462A1 (en) * | 2003-01-17 | 2004-07-22 | Hunt Jacquelyn Suzanne | Process and system for enhancing medical patient care |
US20040205664A1 (en) * | 2003-03-25 | 2004-10-14 | Prendergast Thomas V. | Claim data and document processing system |
US20050010446A1 (en) * | 2003-07-11 | 2005-01-13 | Lash Todd Loren | Health benefit plan monitoring system and method |
US20050222867A1 (en) * | 2004-03-31 | 2005-10-06 | Aetna, Inc. | System and method for administering health care cost reduction |
US20060136264A1 (en) * | 2004-12-21 | 2006-06-22 | Gh Global Health Direct, Llc | System and method for improved health care access |
Cited By (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080195420A1 (en) * | 2007-02-09 | 2008-08-14 | Harley Ramelson | Method, computer program product and apparatus for generating integrated electronic health records |
US7672858B2 (en) | 2007-04-26 | 2010-03-02 | Accretive Health, Inc. | Best possible payment expected for healthcare services |
US20100257126A1 (en) * | 2007-04-26 | 2010-10-07 | Tolan Mary A | Best possible payment expected for healthcare services |
US20100070301A1 (en) * | 2007-04-26 | 2010-03-18 | Tolan Mary A | Best possible payment expected for healthcare services |
US8521565B2 (en) * | 2008-02-22 | 2013-08-27 | Epic Systems Corporation | Electronic health record system utilizing disparate record sources |
US20090228303A1 (en) * | 2008-02-22 | 2009-09-10 | Faulkner Judith R | Electronic health record system utilizing disparate record sources |
US8249895B2 (en) * | 2008-02-22 | 2012-08-21 | Epic Systems Corporation | Electronic health record system utilizing disparate record sources |
US20120310674A1 (en) * | 2008-02-22 | 2012-12-06 | Faulkner Judith R | Electronic Health Record System Utilizing Disparate Record Sources |
US20090216562A1 (en) * | 2008-02-22 | 2009-08-27 | Faulkner Judith R | Method and apparatus for accommodating diverse healthcare record centers |
US20090271351A1 (en) * | 2008-04-29 | 2009-10-29 | Affiliated Computer Services, Inc. | Rules engine test harness |
US8682725B2 (en) | 2010-09-14 | 2014-03-25 | Google Inc. | Regional location-based advertising |
US20120253139A1 (en) * | 2011-04-04 | 2012-10-04 | International Business Machines Corporation | Personalized medical content recommendation |
US8543422B2 (en) * | 2011-04-04 | 2013-09-24 | International Business Machines Corporation | Personalized medical content recommendation |
US20140249834A1 (en) * | 2013-03-03 | 2014-09-04 | Caradigm Usa Llc | Methods, apparatuses and computer program products for providing techniques for users to create health care solutions |
US20160357921A1 (en) * | 2013-03-15 | 2016-12-08 | Humana Inc. | Computerized system and method to use payer financial transactions to build a clinical intervention plan using a derived patient schedule |
US20180325470A1 (en) * | 2017-05-09 | 2018-11-15 | LifePod Solutions, Inc. | Voice controlled assistance for monitoring adverse events of a user and/or coordinating emergency actions such as caregiver communication |
US10722185B2 (en) * | 2017-05-09 | 2020-07-28 | LifePod Solutions, Inc. | Voice controlled assistance for monitoring adverse events of a user and/or coordinating emergency actions such as caregiver communication |
US11020064B2 (en) | 2017-05-09 | 2021-06-01 | LifePod Solutions, Inc. | Voice controlled assistance for monitoring adverse events of a user and/or coordinating emergency actions such as caregiver communication |
US11363999B2 (en) | 2017-05-09 | 2022-06-21 | LifePod Solutions, Inc. | Voice controlled assistance for monitoring adverse events of a user and/or coordinating emergency actions such as caregiver communication |
US11607182B2 (en) | 2017-05-09 | 2023-03-21 | LifePod Solutions, Inc. | Voice controlled assistance for monitoring adverse events of a user and/or coordinating emergency actions such as caregiver communication |
US11404062B1 (en) | 2021-07-26 | 2022-08-02 | LifePod Solutions, Inc. | Systems and methods for managing voice environments and voice routines |
US11410655B1 (en) | 2021-07-26 | 2022-08-09 | LifePod Solutions, Inc. | Systems and methods for managing voice environments and voice routines |
Also Published As
Publication number | Publication date |
---|---|
WO2006071701A2 (en) | 2006-07-06 |
WO2006071701A3 (en) | 2007-02-01 |
US20150193582A1 (en) | 2015-07-09 |
EP1846855A4 (en) | 2008-02-20 |
US10402538B2 (en) | 2019-09-03 |
EP1846855A2 (en) | 2007-10-24 |
CA2596033A1 (en) | 2006-07-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10402538B2 (en) | Healthcare management system using patient profile data | |
US10489843B2 (en) | System and method for selecting healthcare management | |
US20190237174A1 (en) | System for gap in care alerts | |
US6988075B1 (en) | Patient-controlled medical information system and method | |
Bunn et al. | Telephone consultation and triage: effects on health care use and patient satisfaction | |
US8260635B2 (en) | System for communication of health care data | |
US20140108048A1 (en) | Medical History System | |
US20100205005A1 (en) | Patient oriented electronic medical record system | |
US20070035403A1 (en) | Method and system of personal healthcare management | |
US20160078578A1 (en) | System and method for health care management | |
US20200409978A1 (en) | Apparatus and Method for Assessment of Patient Condition | |
US20110010199A1 (en) | Method and system for healthcare information data storage | |
US20130083054A1 (en) | System and method for managing health treatment plans | |
Kohn | Electronic prescribing: CMS should address inconsistencies in its two incentive programs that encourage the use of healthy information technology | |
Rothenhaus et al. | Emergency Department Information Systems (EDIS) Functional Profile | |
Connor | Columbia Basin Hematology & Oncology | |
Falan et al. | Relationships, Caring, and Near Misses: Michael’s Story | |
US20120078964A1 (en) | System for storing and diseminating patient data and related information | |
Devlies et al. | Health data exchange, health data sharing and decentralised clinical data collections--recommendations from a Belgian expert group | |
Krumm et al. | The doctorate of nursing practice: What is it and what does it mean for oncology nurses? | |
Hildebrand et al. | Eye Care Functional Profile Workgroup Health Level Seven |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: THE TRIZETTO GROUP, INC., COLORADO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DEAN, VAL C.;REEL/FRAME:016139/0056 Effective date: 20041220 |
|
AS | Assignment |
Owner name: WELLS FARGO FOOTHILL, INC., CALIFORNIA Free format text: SECURITY AGREEMENT;ASSIGNOR:THE TRIZETTO GROUP, INC.;REEL/FRAME:019834/0112 Effective date: 20070110 Owner name: WELLS FARGO FOOTHILL, INC.,CALIFORNIA Free format text: SECURITY AGREEMENT;ASSIGNOR:THE TRIZETTO GROUP, INC.;REEL/FRAME:019834/0112 Effective date: 20070110 |
|
AS | Assignment |
Owner name: THE TRIZETTO GROUP, INC., CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:WELLS FARGO FOOTHILL, INC.;REEL/FRAME:021328/0858 Effective date: 20080730 Owner name: THE TRIZETTO GROUP, INC.,CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:WELLS FARGO FOOTHILL, INC.;REEL/FRAME:021328/0858 Effective date: 20080730 |
|
AS | Assignment |
Owner name: ROYAL BANK OF CANADA, CANADA Free format text: SECURITY AGREEMENT;ASSIGNORS:TZ US HOLDCO, INC.;TZ MERGER SUB, INC.;THE TRIZETTO GROUP, INC.;AND OTHERS;REEL/FRAME:021523/0159 Effective date: 20080804 Owner name: ROYAL BANK OF CANADA,CANADA Free format text: SECURITY AGREEMENT;ASSIGNORS:TZ US HOLDCO, INC.;TZ MERGER SUB, INC.;THE TRIZETTO GROUP, INC.;AND OTHERS;REEL/FRAME:021523/0159 Effective date: 20080804 |
|
AS | Assignment |
Owner name: ROYAL BANK OF CANADA, CANADA Free format text: SHORT FORM AMENDED AND RESTATED INTELLECTUAL PROPERTY SECURITY AGREEMENT;ASSIGNORS:THE TRIZETTO GROUP, INC.;TZ US HOLDCO, INC.;GATEWAY EDI, LLC;AND OTHERS;REEL/FRAME:026304/0728 Effective date: 20110502 |
|
AS | Assignment |
Owner name: ROYAL BANK OF CANADA, AS COLLATERAL AGENT, CANADA Free format text: SECURITY AGREEMENT;ASSIGNORS:THE TRIZETTO GROUP, INC.;TZ US HOLDCO, INC.;OPTION SERVICES GROUP, INC.;AND OTHERS;REEL/FRAME:029068/0480 Effective date: 20120928 |
|
AS | Assignment |
Owner name: TRIZETTO CORPORATION, COLORADO Free format text: CHANGE OF NAME;ASSIGNOR:TRIZETTO GROUP, INC, THE;REEL/FRAME:030537/0548 Effective date: 20121221 Owner name: TRIZETTO CORPORATION, COLORADO Free format text: CHANGE OF NAME;ASSIGNOR:TRIZETTO GROUP, INC, THE;REEL/FRAME:030532/0465 Effective date: 20121221 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION |
|
AS | Assignment |
Owner name: COGNIZANT TRIZETTO SOFTWARE GROUP, INC., COLORADO Free format text: CHANGE OF NAME;ASSIGNOR:TRIZETTO CORPORATION;REEL/FRAME:042335/0020 Effective date: 20170222 |