JP2007525288A - System and method for accessing medical information and distributing medical information - Google Patents

Abstract

  Systems and methods for collecting, utilizing and / or distributing medical information. In some cases, the system includes means for receiving medical information from multiple sources. Such sources can include, but are not limited to, physicians, patients, and implantable medical devices. The system further includes means for converting medical information from the implantable medical device into a selected format and means for distributing the medical information to one or more databases.

Description

  The present invention relates to implantable medical devices, and more particularly to systems and methods for collecting and / or distributing information derived from implantable medical devices.

  One or more clinical trials are typically performed to verify the operation of the medical device. This usually involves registering a number of doctors who are eligible to use a specific medical device to supervise the patient. A medical device is deployed in association with the patient, and a physician monitors the patient's progress. At various intervals, information about the patient's progress is provided to the deployed medical device manufacturer. In return, doctors usually get paid for providing information. However, payment is not made until the information is verified by the manufacturer's employees.

  The process described above is very expensive and error prone. Accordingly, there is a need in the art for more advanced systems and methods for collecting, utilizing and / or distributing medical information, at least for the reasons described above.

  The present invention provides systems and methods for collecting and / or distributing medical information. In one exemplary embodiment, the present invention provides centralized retention of medical information derived from patient visits and, for example, researchers, patients, patient physicians, professionals, and / or others Provides distributed access to various medical information by multiple recipients. Thus, for example, the patient visits the patient's doctor, during which the doctor reads information from the implantable medical device associated with the patient, makes other objective measurements of the patient, Record various subjective information about. All of that information is uploaded and retained on various accessible systems.

  In some cases, the systems and methods of the present invention are used to perform clinical trials of medical devices. In such cases, information is collected from a doctor supervising the patient using the medical device. The doctor can use a programmer to read the medical device, and the information extracted from the medical device is uploaded to the raw database via the communication network. In addition, the physician can record various objective and / or subjective information about the patient, and that information is uploaded to the system via the communication network.

  Information from the medical device is decrypted and / or converted to the desired format, and one or more portions of the information are verified. Once verified, the agreed payment for collecting the information is approved and paid to the physician and / or patient. In some cases, the information is then used to verify the effectiveness of a particular medical device and / or guide changes to that medical device.

  Some embodiments of the present invention provide a method for accessing and utilizing medical information. The method includes receiving a data set in a first format from an implantable medical device via a communication network. An interpreter associated with the implantable medical device is identified and applied to the data set to convert the data set from a first data format to a second data format. In one particular case, the first data format is a binary format and the second format is an XML database format. In various examples, the method includes storing a first data set in a first format in a raw database and storing a converted data set in a second format in a comprehensive database. In addition.

  Various other embodiments of the present invention provide a universal medical data access system. Such a system includes a system controller coupled to communicate with a gateway controller. The gateway controller operates to receive information from one or more sources of medical information and, in some cases, is operable to distribute various types of medical information. In one case, the gateway controller includes a processor and a computer readable medium. The computer readable medium is received by the first processor to receive a data set that includes objective data and / or subjective data collected by a physician and to communicate at least a portion of the data set to the system controller. Contains executable instructions. In one particular case, both the gateway controller and the system controller are implemented as a single computer system.

  The above summary only provides a general overview of some embodiments according to the present invention. Many other objects, features, advantages and other embodiments of the present invention will become more fully apparent from the following detailed description, the appended claims and the accompanying drawings.

  In the figures, similar components and / or similar features have the same reference numerals. In addition, different components of the same type are distinguished by a sign followed by a second sign that distinguishes between similar components. If only the first code is used herein, the description applies to any of the similar components having the same first code, regardless of the second code.

  The present invention provides systems and methods for collecting medical information and / or distributing medical information. In one exemplary embodiment, the present invention allows medical information collected from one or more patients to be later accessed by the patient, the patient's physician, researcher, and / or other interested parties. Can be kept on a central database. Thus, for example, a patient visits a patient's doctor, during which the doctor reads information from an implantable medical device associated with the patient, makes other objective measurements of the patient, and Various subjective information can be recorded. All of that information is uploaded to and held in various accessible systems. This system can be accessed in a variety of ways, as access rights to retained medical information can be different for each party based on privacy, need, and / or business concerns.

  As used herein, the term “implantable medical device” is used in the broadest sense to mean any medical device that is implanted within or associated with an organism. By way of example only, a pacemaker is an implantable medical device. Furthermore, as used herein, the term “subjective information” is used in the broadest sense and refers to information based on human interpretation. Thus, for example, a doctor may indicate that a particular individual looks “happy” and / or “healthy”. Both of these decisions are considered subjective information. On the other hand, as used herein, “objective information” is used in the broadest sense and refers to any information based on objective measurements. Thus, for example, based on the measurement, the doctor indicates that the patient has a certain weight or has a certain blood pressure. These are both examples of objective data. In addition, some diagnostic or patient history information may be a combination of subjective and objective information. For example, the fact that a patient has a history of coronary artery disease, or some other disease, is probably objective information based on subjective diagnosis from the past.

  In some cases, the systems and methods of the present invention are used to perform clinical trials of medical devices. In such a case, information is collected from a doctor who is supervising a patient who is taking a class and using a class of medical devices. The doctor uses the programmer to read the medical device and the information extracted from the medical device is uploaded to the raw database via the communication network. As used herein, the term “raw database” implies a computer readable medium that contains information that has not yet been in a converted format. Thus, by way of example only, a raw database includes information received from an implantable medical device that is not yet in the desired format, or some derivative of such information.

  The system and method may further include either objective information or subjective information about the patient, or both. The information is uploaded to the system via the communication network. As used herein, the term “communication network” is used in the broadest sense to mean any network or medium capable of sending information. Thus, the communication network is the Internet, cellular telephone network, public switched telephone network, local area network, wide area network, virtual private network, and / or a combination of the above, but is not limited to the above. .

  In some cases, doctors, patients, and / or other medical staff are paid for collecting various medical data. In such cases, once the information is received and verified by the system, the agreed payment for collecting the information is approved and paid to the physician, patient, and / or other medical staff. Collected medical data may include subjective data collected by a physician, objective data collected by a physician, and / or a data set received from an implantable medical device.

  Various embodiments of the present invention provide a universal medical data access system. Such a system includes a system controller coupled to communicate with a gateway controller. As used herein, a gateway controller is any entry or exit point where information enters or leaves the system. Further, a system controller as used herein is any point where different portions of medical data are combined and / or converted. Thus, in some cases, the system controller and the gateway controller are the same type of device and / or can serve overlapping purposes. In one particular case, both the gateway controller and the system controller are servers that are communicatively coupled to a communication network.

  The gateway controller is operable to receive information from one or more sources of medical information, and in some cases is operable to distribute various types of medical information. In some cases, the gateway controller includes a processor and a computer readable medium. The computer readable medium receives instructions executable by the processor to receive a data set containing objective and / or subjective data collected by a physician and to communicate at least a portion of the data to the system controller. Including. In one particular case, both the gateway controller and the system controller are implemented as a single computer system.

  The system controller holds one or more medical information and converts the various medical information into a desired format, and in some cases, various parts of the medical information to one or more receiving systems. Operable to deliver. The system controller includes a processor and a computer readable medium. The computer readable medium includes instructions executable to receive information from one or more sources, including but not limited to, a first format data set from an implantable medical device. The instructions are further executable to store a data set from the implantable medical device in a raw database, identify a group associated with the implantable medical device, and select an interpreter based on the group. The interpreter is applied to the received data set to convert the data set from the first format to the second format. At least a portion of the data set converted to the second format is stored in a database associated with the gateway controller. Also included are instructions for verifying objective and subjective data collected by the physician.

  In some cases, the system further includes a diagnostic controller (eg, another gateway controller associated with the diagnostic system) coupled to communicate with the system controller. The diagnostic controller operates to provide various medical information to one or more recipients. The medical information is diagnosis-limited information that can be shared without involving privacy issues. As used herein, “diagnostic limited information” includes any information on which a physician or other medically trained staff relies to provide a medical diagnosis. In some cases, but not necessarily in all cases, the diagnostic limited information removes all information that helps identify the patient that the information describes.

  In certain cases, various medical data is provided to one or more recipients who can analyze or diagnose based on the received medical information to determine the meaning of the provided medical information. Give an opinion. The opinion information is received as analysis data (eg, medical diagnosis) at the diagnostic controller. In some cases, the analysis data is stored by the diagnostic controller in association with corresponding medical data, whereas in other cases, the analysis information is provided to the system controller and In the controller, it is stored in a comprehensive database in association with the corresponding medical data. Thus, by way of example only, a group of 10 doctors receives an electrocardiogram from a particular patient. Each of the 10 doctors then presents an opinion about what type of arrhythmia is indicated by the electrocardiogram, and the view is stored in association with the electrocardiogram.

  In certain cases, the diagnostic controller may be further operative to provide diagnostic guidance to one or more system users. For example, a diagnostic query including “specific diagnostic limited data” is received at the system. As used herein, the term “specific diagnosis limited data” includes medical data sets submitted for diagnostic purposes. In some cases, but not necessarily in all cases, information that helps to identify the patient that the information describes is removed from the specific diagnosis limited data. The received specific diagnosis limited data is compared with at least a portion of the diagnosis limited information to determine the closest match. A diagnosis is provided based at least in part on the closest match. Thus, by way of example only, a physician can submit an electrocardiogram associated with the patient. A database is queried to determine if there is a valid match between the presented electrocardiogram and other previously analyzed electrocardiograms. If one or more close matches are found, a diagnosis associated with the matched electrocardiograms is provided to the requester.

  In various embodiments of the invention, information from an implantable medical device is received at a system controller and stored in a raw database in a first format at the system controller. At least a portion of the information held in the raw database is converted to a desired format, stored in a comprehensive database, and / or distributed to one or more subset databases. As used herein, the term “comprehensive database” refers to a database in which a subset of data (ie, a portion of a superset) is maintained. Such a subset database is associated with, for example, a controller operable to perform different functions, and the subset is selected based on the functions to be performed. As just one example of many examples, if access is given to the patient's physician, the subset database may contain patient specific information including patient name and address information. In another example of many examples, the subset database is a diagnostic database used by one or more physicians, researchers, and the like.

  In various cases, information is accessed from a raw database, and one or more subset databases are created from the accessed information. Thus, for example, if the subset database is lost, it is regenerated from the raw database. Alternatively, or in addition, if the initial formation of the subset database is later found to be inadequate, the subset database is a different part of the raw database, a different data transformation, and / or the like. Newly created.

  Referring to FIG. 1, a prior art system 100 for collecting medical information is shown. System 100 includes a patient 110 having an implantable medical device 120. The patient 110 visits a physician's office that includes a programmer 140 that can communicate with the implantable medical device 120 via the communication link 130. Programmer 140 includes an antenna 144 that facilitates such communication. The programmer 140 includes an insertion bay 146 that receives a removable computer readable medium 150, such as a floppy disk. In addition, programmer 140 includes a graphic display 142 and one or more user input devices 147 that control programmer 140.

  The programmer 140 is electrically coupled to a printer 160 that can print information on the paper 170 via, for example, an electrical wire 180. As used herein, the term “electrically coupled” is used in its broadest sense and includes any bond through which electrons that form part of a communication can pass. Thus, for example, an electrical wire that physically connects two devices can be considered to electrically couple the two devices. In contrast, as used herein, the term “communicatively coupled” includes broader and electrically coupled. In particular, being coupled in communication includes any combination in which information can be sent from a source to a destination. Thus, when two devices communicate via wires and / or communicate wirelessly, they are coupled to communicate.

  In operation, patient 110 visits a doctor's office, where the doctor causes implantable medical device 120 to cause programmer 140 to query. Information that is normally in some encoded binary format, such as binary coded decimal (BCD), is transferred from the implantable medical device 120. Furthermore, the encoded binary information can include a combination of different formats, for example, even if some data is in BCD format and other data is in some proprietary format. Good. That information is sent to an interpreter included as part of the programmer 140, which interprets the information into a graphic format that is displayed via the graphic display 142. For example, the information includes a group of Cartesian coordinate data displayed as an electrocardiogram.

  Further, it should be appreciated that the implantable medical device 120 can supply several parameters as part of the information uploaded to the programmer 140. In some cases, the implantable medical device 120 can supply 700-1500, or many more different parameters. The number of parameters supplied is specific to a given implantable medical device and / or programming mode, so a given programmer typically has one type of implantable medical device and / or a group of Specific to implantable medical devices.

  In addition to displaying graphical information derived from information sent from the implantable medical device 120, the physician can save information from the programmer 140 on a removable computer readable medium 150. In addition, the physician can print the information in a graphic format on paper 170 for review and / or for inclusion in a patient file. However, using such a system, a physician cannot electronically display historical records that include multiple patient visits. This limits the physician's ability to function efficiently.

  Further, in a clinical trial scenario, the physician sends a removable computer readable medium 150 with a handwritten questionnaire to the manufacturer of the implantable medical device 120. That information must then be transferred to a database and verified by a human. This is inefficient and / or error prone.

  Referring now to FIG. 2, one embodiment of a system 200 for collecting, verifying, storing, using, manipulating and / or distributing medical information is shown. In the illustrated embodiment, the system 200 is configured to receive medical information and other healthcare information and maintain it in a central database repository system. The system 200 may also be used by medical device manufacturers, patients, patient physicians, and / or third party healthcare providers, researchers, service companies, or organizations to access some or all of the information. It is also configured to be able to. Thus, as shown in FIG. 2, the system 200 includes several computer-based systems that are communicating via a communication network 202. In one embodiment, the system 200 includes a data input device group 204, a data collection system 206, a central data processing-repository system 208, and a medical diagnostic system 210, all of which are over a communication network 202. In communication with one or more systems of other systems.

  According to one embodiment of the present invention, the data input device group 204 is adapted to receive implantable medical device information and communicate that information to various systems. US Patent Application No. 10 / 422,495, filed April 23, 2003 by Bardy, US Patent Application No. 10 / 422,495, entitled “System and Method for Providing Tiered Patent Feedback for Use in Automated Patient Care”, 2001 by Bardy "Computer Ready Storage Medium Conforming Code for Automated Collection and Analysis of Principal Funded Implantable Remedy U.S. Patent No. 6,607,485 entitled ", provides further information about the transfer of information from implantable medical device via a communications network. Each of U.S. Patent No. 6,607,485 and U.S. Patent Application No. 10 / 422,495 are incorporated herein by reference in nature.

  In addition to information collected from implantable medical devices, objective patient information, subjective patient information, and / or diagnostic information can be received and communicated to various systems. Such additional information is a quality-of-life scale that describes a patient's physical well-being, emotional well-being, and symptom records, such as that provided by Duke Activity Status Indicator ™. Is not limited. For example, the disclosure is incorporated by reference herein in its entirety. Braunwald, “Heart Disease-A Textbook of Cardiovascular Medicine”, pages 452-454, W.C. B. Saunders Co. Other types of measures can also be used, including the Minnesota Living with Heart Failure Questionnaire described in (1997). As another example, the relationship between a symptom and the amount of activity required to cause such a symptom, such as New York Heart Association classification I, II, III, IV, as described in the instructional book mentioned above. A functional classification standard to define is given to the system. Based on the disclosure provided herein, those skilled in the art will recognize the myriad information that can be provided to the system 200 in addition to implantable medical information.

  By way of example, a programmer 212, typically located in a physician's office, is adapted to receive information from a medical device implanted in a patient 214. However, instead of dumping data onto a diskette as disclosed above, programmer 212 is connected to communication network 212 and configured to upload medical device information to one or more of systems 206, 208, 210. Is done. In one embodiment, programmer 212 is connected directly to communication network 202. In another embodiment, the programmer 212 is connected to the communication network 202 via the physician's information system 216 or via other intermediate systems. However, as will be appreciated by those skilled in the art, the specific means by which programmer 212 is connected to communication network 202 is as long as medical device information can communicate with network 202 and systems 206, 208, 210 and programmer 212. It does not matter.

  According to another embodiment of the present invention, the patient 214 has a medical device monitor 218 located at the patient's residence that is configured to send and receive medical device information to and from the communication network 202. According to this embodiment, similar to programmer 212, monitor 218 receives information from a medical device implanted in patient 214 via a wireless communication connection. In one embodiment, the monitor 218 is configured to obtain medical device information on a regular basis, for example, every night while the patient is asleep, or optionally weekly. Alternatively, the monitor 218 may be configured to instruct the patient when the data transfer is to take place, or perform a data transfer when a trigger episode (eg, an abnormal event) is detected. Configured to do.

  After the monitor 218 receives information from the implantable medical device, the monitor 218 then uploads the information to the communication network 202 via the communication connection. As will be appreciated by those skilled in the art, the communication connection to the network 202 may be an Internet connection, a wired telephone connection, a wired connection, or any other suitable communication connection now known or developed in the future, such as Any suitable connection. Further, the communications network 202 includes communications including but not limited to the Internet, cellular telephone network, public switched telephone network, local area network, wide area network, virtual private network, or combinations thereof. It will be appreciated that any network that can be smooth may be used.

  According to another embodiment of the present invention, implantable medical device information is uploaded from the mobile monitor 220 to the communication network 202. Such a mobile monitor 220 is integrated with a cellular telephone. According to this embodiment, the mobile monitor 220 is similar to the monitor 218, except that the patient can carry the monitor 220 with him whenever necessary. Since the device monitor 220 is mobile, the connection of the monitor 220 to the communication network 202 is often a wireless connection, but the invention is not limited to this embodiment. Those skilled in the art will appreciate that the mobile monitor can communicate with the network 202 via any suitable communication connection.

  As described above, in addition to medical device information, objective patient information, subjective patient information, diagnostic information, and other medical information are also input and uploaded to the systems 206, 208, and 210. As described above, “objective information” means arbitrary information based on objective measurement values such as a weight measurement value, a blood pressure measurement value, and the like of a patient. Furthermore, “subjective information” means information based on human interpretation, such as diagnosis of a medical condition or symptom of a patient. Furthermore, some diagnostic or patient history information may be a combination of subjective and objective information. For example, the fact that a patient has a history of coronary artery disease, or some other disease, is probably objective information based on subjective diagnosis from the past. Regardless of the classification of information, the present invention is configured to collect, store, and use any suitable medical information, diagnostic information, or other patient information deemed appropriate. Thus, the present invention is not limited to the particular type or form of information collected.

  In one embodiment of the present invention, the data input device 220 can be used by a doctor to input patient information including objective information and subjective information. Further, the data input device 220 can be used to verify medical information and / or provide analytical input corresponding to the medical information. The data input device 220 is a personal computer, mobile computing device, or any suitable data input device such as a cellular device or a wireless device. In one exemplary embodiment, the data input device 220 is a personal digital assistant (PDA) with built-in wireless communication capabilities. In addition, data is entered using a number of different software programs. For example, the data input device 220 includes a data input questionnaire program that prompts the doctor to input specific information. Alternatively, the data input device 220 may include a web browser that processes a data entry web page or a data entry web applet. As will be appreciated by those skilled in the art, patient information can be entered using any suitable device and / or method, and thus the invention is not limited to any particular embodiment or configuration.

  In the illustrated embodiment, the data input device 220 is connected to the communication network 202 via the physician information system 216. Alternatively, the data input device 220 can be connected directly to the communication network 202 or connected via some other intermediate system. However, as will be appreciated by those skilled in the art, the particular means by which the data input device 222 is connected to the communication network 202 is such that the device may send medical information, diagnostic information, and / or other patient information to the network 202 or system. As long as it can communicate to 206, 208, and / or system 210, it is not important.

  In some examples, the physician may not have access to a system for entering patient information. In those situations, the physician may record medical information, diagnostic information, or other patient information in a medical record or form, or the physician may dictate the information to a sound recordable medium. When this is done, the physician sends a medical record, form, and / or voice recordable media to the data entry agent. In this example, the agent uses a data entry system (not shown) to enter the patient information (including objective and subjective information).

  In some cases, a physician entering information into the system 200 may be required to verify and / or authenticate after the system 200 accepts the information. In such a case, the physician can request to view previously entered data via the data input device 222. The physician then verifies the data and provides an indication of the validity and / or authenticity of the data via the data input device 222. If the data is not available, the physician sends a communication to the system agent system 226 via the data input device 222. A system agent using the data input device 224 confirms the availability of the requested data and provides the data to the data input device 222 in real time, where the physician verifies the data, And / or can be authenticated.

  As described above, implantable medical device information is entered and uploaded using a number of different devices including programmer 212, medical device monitor 218, and mobile monitor 220. Once the programmer 212 and / or the monitors 218, 220 receive the medical device information, the data is uploaded to the central data processing-repository system 208 via the communication network 202. In accordance with this aspect of the invention, the central data processing-repository system 208 includes a server 226 that receives medical device information and stores the information in a raw medical device data database 228.

  As will be appreciated by those skilled in the art, data from an implantable medical device is typically in an encoded binary format. In one embodiment, programmer 212 and medical device monitors 218, 220 may upload a medical device data stream to system server 228 or raw medical device data database (“raw database”) 230, It is configured to decode the data stream. According to this embodiment, the uploaded data stream is decrypted but still in a binary format. In an alternative embodiment, programmer 212 and medical device monitors 218, 220 simply receive and upload medical device data without performing any decryption functions. In that embodiment, the central data processing-repository system 208 performs the decryption function. In either case, however, the raw database 230 stores medical device information in a binary format, which makes it difficult for many programs and databases to use the information.

  Thus, in one embodiment, it is desirable to convert medical device data from a binary format to a more database friendly format. In accordance with this aspect of the invention, a data conversion module or system 232 receives medical device data in a binary format and converts the data to a more “user friendly” format, such as an Extensible Markup Language (“XML”) format. Convert to "na" format. As described in more detail below, the data conversion system 232 analyzes the binary data and transfers at least a portion of the data to an XML field.

  After the data is formatted and placed in, for example, an XML field, the XML data is then stored in a data warehouse. In one embodiment, the XML data is stored in the comprehensive database 238 or in some other database location. A data verification module or data verification system 234 then receives the XML data and verifies the accuracy of the data conversion. The data validation system 234 can also perform other functions, such as deleting duplicate XML data, validating and / or normalizing information entered by a physician. The operation of the data verification system 234 is described in more detail below.

  After the XML data is verified, it is populated into a database for use by other programs. In accordance with this aspect of the invention, the database control module or database control system 236 reads the XML data and pre-determines the data, eg, the comprehensive database 238 and / or the subset databases 248, 252. Populate the database. Once populated, all or part of the database 238 is made available for use by several different entities for querying and use. The operation of the database control system 236 is described in more detail below.

  As will be appreciated by those skilled in the art, when a physician participates in a medical device study, the physician is typically paid for the physician's time and effort by the entity performing the study. For example, a medical device manufacturer may arrange research to verify certain functions or obtain FDA approval for the device. In that situation, the medical device manufacturer ensures the assistance of the doctors participating in the study. The research includes implanting medical devices into patients, directing patient assessment and medical device performance tracking, collecting data from implantable medical devices, and sending the data to medical device manufacturers for analysis. Including supplying. Typically, after the doctor performs those functions, the entity performing the study verifies that the doctor has performed the functions correctly and then pays the doctor. In accordance with this aspect of the invention, once the payment authorization-processing module or payment authorization-processing system 240 verifies or confirms that the physician has properly followed the medical device research parameters, an accounting system is verified. And make sure that the doctor is paid. The operation of the payment authorization-processing system 240 is described in more detail below.

  In the illustrated embodiment, the data conversion system 232, the data verification system 234, the database control system 236, and the payment authorization-processing system 240 are all shown as separate systems within the data processing-repository system 208. However, these systems are all illustrated as separate systems, merely to illustrate the function of those modules. The functionality of these systems or modules can be integrated into a single processing system, such as system server 228, so that the invention is not limited to the distributed embodiment shown in FIG. Will be understood by those skilled in the art. Further, the operations of the data conversion system 232, the data verification system 234, the database control system 236, and the payment authorization-processing system 240 will be described separately below, but the functions executed in each system or each module are described in terms of the functions. One skilled in the art will appreciate that the modules are not necessarily limited to those modules. Some of the functions of those modules can optionally be performed by another module. For example, data validation and database control are described as separate modules, but data validation and database control can be combined as a single module or, in some cases, some, but all It is also possible that verification that is not is performed by the database control system 236.

  As described above, in addition to medical device information, objective patient information, subjective patient information, diagnostic information, and other medical information are also input and uploaded to various systems via the communication network 202. According to one embodiment of the present invention, the data collection system 206 is configured to receive objective patient information and subjective patient information from the physician system 216 or from the agent system 226. In one embodiment, the data collection system 206 includes a gateway server 242 for receiving objective and subjective data from the communication network 202 and one or more databases that store the data. In the illustrated embodiment, the data collection system 206 includes an objective database 244, a subjective database 246, and a subset database 248. The objective database 244 stores “objective information” input by the doctor, and the subjective database 246 stores “subjective information” input by the doctor. These databases are shown as separate databases, but this is for illustration only. The data collection system 206 may be configured to have only a single database for both objective and subjective information, and in many instances, such configuration is likely to be configured. It will be understood by the contractor.

  The data collection system 206 obtains objective and subjective data from the physician and then uploads the data to the data processing-repository system 208 where the data is verified and along with the implantable medical device data. And read into the comprehensive database 238. Once populated, the comprehensive database 238 includes medical device information for each patient, and further includes subjective and objective information. As previously described, medical device information may be collected while the patient is visiting a doctor, or may be pre-used at the patient's home or elsewhere using the medical device monitor 218 or mobile monitor 220. Collected at set intervals. However, objective and / or subjective information is typically entered by a physician only after the physician has analyzed and / or diagnosed the patient during the patient visit.

  After the data is collected in the comprehensive database 238, some or all of the data is made available for use by different entities or third parties. For example, a portion of the database 238 is downloaded to the data collection system 206 and stored in the subset database 248. The data collection system 206 can then be accessed by a third party health care provider as well as a physician or patient, for example, by querying the subset database 248 via the communication network 202 and gateway server 242. Can access a smaller subset of data. As will be appreciated by those skilled in the art, a third party can, for example, use a database structured query language, use a software program adapted to access the database, or use embedded database calls. The subset database 248 can be accessed in several different ways, including using a web page or web applet with it.

  In the embodiment shown in FIG. 2, the data collection system 206 and the data processing-repository system 208 are shown as separate systems. In one embodiment, these systems are separate as shown. For example, in one embodiment, the data processing-repository system 208 is a system located at and maintained by a medical device manufacturer, and the data collection system 206 is a third party data collection service. Or it may be a data collection agency. In that embodiment, as described above, the data processing-repository system 208 is configured to collect medical device data and the data collection system 206 is configured to collect objective and subjective data from the physician. .

  Alternatively, in another embodiment, the data collection system 206 collects medical device data, as well as objective and subjective data, and then decrypts, transforms, validates, and / or databases all information. It can also be configured to upload to the data processing-repository system 208 for control and database reading. In yet another embodiment, the data collection system 206 can include one or more of a data conversion system 232 and a data verification system 234. In yet another embodiment, the data collection system 206 and the data processing-repository system 208 can be configured as a single system at one location or as a single system located at multiple sites. It is. Since these systems are networked systems, any networked system configuration can be used.

  The collected medical device information and patient information are used for several different purposes. In one embodiment, the collected data is used to obtain FDA approval for the device, or the data is used to publish a paper about a particular device and how to use the device. used. According to another embodiment, the collected data is used to obtain diagnostic information and other analytical information and possibly distribute that information. According to the embodiment, the medical diagnosis system 210 obtains diagnostic information from doctors and / or specialists, collects the diagnostic information, and then diagnoses the doctor or other third party based on the input symptom information. Configured to be distributed to health care providers.

  In the illustrated embodiment, the medical diagnostic system 210 receives at least a portion of the data from the comprehensive database 238 and stores the data in the subset database 252. In one embodiment, the medical diagnostic system 210 includes a gateway server 250 that receives data and stores it in a database 252. The medical diagnostic system 210 receives at least sufficient data for a physician or expert to create a medical diagnosis. For example, the data may include information about the patient's symptoms, medical device readings, or any other suitable data that a physician needs to make a diagnosis. Those skilled in the art will appreciate that the type and amount of data required to make a diagnosis will depend on several factors, including the disease state in question and the type of medical device.

  According to one embodiment, the medical diagnostic system 210 is a diagnostic adapted to package medical data and send that data to a physician and / or professional to obtain a diagnosis from the physician and / or professional. A tool system or diagnostic tool module 254 is also included. As will be described in more detail below, the diagnostic tool 254 packages medical data for viewing, such as a graphic web page or graphic web applet, an email with a readable attachment, or some other form of data communication. Configured to make possible packages.

  After the medical data package is formatted, the diagnostic tool 254 then sends the package to the specialist system 256 or physician system 216. In the illustrated embodiment, the expert system 256 has a data input device 258 that is in communication with the system 256, and the device 258 reviews the medical data package from which the expert has reviewed the medical data by the expert. The diagnosis information based on the examination can be input. Similarly, the physician system 216 can also have a data input device 222 that is in communication with the system 216 for entering diagnostic information. Data input devices 258, 222 are personal computers, handheld computing devices, cellular devices, or any other suitable input device.

  After a specialist and / or physician has entered diagnostic information, the information is returned to the medical diagnostic system 210 and stored in the subset database 252 where the information is analyzed and processed. For example, in one embodiment, the diagnostic tool module 254 analyzes diagnostic information provided by several different professionals, physicians, or other health care providers and proposes diagnosis and therapy based on input parameters. Configured to formulate. For example, a doctor can input patient symptom information and medical device information into a program or web page, and the diagnostic tool 254 compares the input symptom with medical data and diagnostic information stored in the database 252. By doing so, it is configured to diagnose and possibly determine and provide therapy suggestions. In this way, the diagnostic tool can operate as an intelligent diagnostic machine. As with the data collection system 206, the medical diagnostic system 208 can be a stand-alone system that is operated separately from the data processing-repository system 208 or is integrated with the systems 208, 206. The The specific network configuration is not important.

  In the illustrated embodiment, both the data collection system 206 and the medical diagnostic system 210 include an access tool group 260. As described in more detail below, the access tool 260 is a set of interface tools, security devices, and access rules that allow users to securely access the system and, in some cases, restrict access.

  Referring now to FIG. 3, the user opens an internet browser or some other communication tool installed on a microprocessor-based device local to the user (block 310). Internet browsers are installed on, for example, mobile monitors, bedside monitors, mobile input devices, personal computers, programmers, and / or the like. When the Internet browser is opened, the user is automatically directed to a server or proxy of such server that is operable to receive the uploaded information. In other cases, the user must direct the Internet browser to the appropriate site.

  In some cases, the user first downloads the locally executed applet over the communication network. Such an applet is downloaded, for example, from an access tool 260 associated with the data collection system 206. In one particular case, the applet is written in JAVA code and works properly using a dedicated plug-in, depending on the particular browser selected. Other approaches to prepare for uploading data are also used, known in the art.

  In some cases where the applet is downloaded, the user is presented with a dialog box requesting various authentication and / or authorization information, as is known in the art. Once authentication and / or authorization information is received, the applet allows data to be uploaded to the system. Further, in some cases, an applet is accompanied by an authentication certificate that requires the user to indicate that the applet has been received from a known and / or trusted source. In some cases, authentication and / or authorization is required each time information is to be uploaded to the system.

  The internet browser presents the user with a user interface that asks the user if he wants to upload (block 320). Further, the user interface includes a field for indicating data to be uploaded, or in some cases, the information to be uploaded is obtained from a removable computer medium. For this reason, in some cases where the applet is running as a programmer, the floppy disk information in the programmer is uploaded. In other cases where the applet is running on a computer, many files are stored on the hard disk drive and uploaded simultaneously.

  Once data for upload is selected (block 320), an upload command is entered (eg, a virtual button is clicked) (block 330). If a single patient data file is selected for upload, the upload process is performed in a single scan. Alternatively, if multiple patient data files are selected for upload, an iterative process across the directory structure is completed until all of the patient information is uploaded. Depending on the type and model number of the particular implantable medical device, and as described above, various data is uploaded depending on the information provided by the patient and / or physician. Alternatively, information from the implantable medical device is uploaded in one session, and other subjective and / or objective information is uploaded in one or more other sessions.

  In one particular embodiment where objective patient data, subjective patient data, and data from an implantable medical device are all uploaded using a single upload request, the data is derived from the implantable medical device. It may be automatically distributed between the receiving system server 228 and the gateway server 242 receiving other subjective and / or objective data.

  In one particular case, a thread is started that performs the actual upload to the server contacted via the Internet browser (block 350). In such a case, each upload of patient information begins with a “GET” request to the server indicating the start of a directory upload (block 360). As an example, a specific implantable medical device serial number and application model number and date / time stamp are passed as parameters to a “GET” request and used to create a file name. After the “GET” request is issued, a special “POST” request message is sent to the server for each uploaded file. The contents of the file are sent to the server in the body of the “POST” request, and the name of the file is sent as a parameter.

  In at least some examples, privacy concerns are an issue, so security when transferring information over a communications network is a concern. Security is enhanced by configuring a servlet that delivers Java applets on the server side to run using a secure HTTP connection. This is reflected on the user (eg, client) side by including a privacy indication as is known in the art. Furthermore, setting HTTPS uses the security advantages suggested above. In addition to the above approaches, authentication can be performed.

  On the server side, two servlets handle the above-mentioned “GET” request and “POST” request. In one particular case, the model number, serial number, and / or date / time stamp are used to define a unique path (eg, directory location) for the patient associated with the device. If the path does not exist, the servlet attempts to create the path. As an example, the path will not exist when data about a particular patient is uploaded for the first time. During the initial upload, the received information is archived for traceability and / or other future use. Separate directories are used to store uploaded files received at different times from the patient. Those directories are children of earlier created patient directories. The names of those directories are assigned to reflect the current count of uploaded disks. As an example, “1743_200134 / 0” or “1743_200134 / 1” is used. These reflect the first upload and the second upload for patients with 1743PG and 200134 serial numbers. In one particular embodiment, “/ 0” and “/ 1” are replaced with the received date / time stamp. Thus, if multiple transmissions with the same date / time stamp are received from the same implantable medical device, only one copy of the multiple transmissions is retained. The patient directory is stored as an attribute for the current session and is made available to the servlet. The “POST” request causes a file to be created in the current patient directory, and then the contents of the “POST” request are copied into the newly created file.

  In some cases, if the upload is interrupted or otherwise fails, an orphaned directory with partial data is created on the server. The directory is organized by the management servlet. The management servlet periodically scans the archive area of the raw database 230 and deletes orphan directories. This servlet can use any log information kept in the directory to identify the interrupted session.

  When the upload is complete for a single patient directory, a completion indication is sent to the servlet. The servlet then flags that directory as complete, and also stores log information related to the upload in the directory. The log can capture any information about the upload including, but not limited to, the MAC (Media Access Control) address of the machine that initiated the upload, or other indication.

  In some cases, the uploaded data is from an implantable medical device, and therefore can be in encoded and / or encrypted form. In such cases, the data, or a portion of the data, is directed to the data conversion system 232. Referring to FIG. 4, which represents an embodiment of the data conversion system 232, each of the three ports 403, 406, 409 is dedicated to receiving data from a particular implantable medical device group 404, 407, 410. As a specific example, information from implantable medical devices included in implantable medical device group 404 is received by system server 228. System server 228 then sends the received information from the implantable medical device to port 403. If the information is from an implantable medical device from any of the other implantable medical device groups 407, 410, the received information is sent via another one of the ports 406, 409. It will be appreciated that the design of the data conversion system 232 is scalable and is modified to convert, decode and / or decrypt data from any number of implantable medical device groups. Thus, as will be appreciated, the number of implantable medical device groups illustrated is merely exemplary.

  In one embodiment, a TCP / IP connection is opened to one of the ports 403, 406, 409, and a request to convert the data is provided over the TCP / IP connection. As described above, the port from which data is received indicates the type of data being received (ie, the type of implantable medical device from which the data originated). Thus, the system server 228 is responsible for identifying the received data type and opening a TCP / IP connection to the port of the data conversion system 232 corresponding to the identified data type. The data conversion system 232 is implemented using, for example, “inetd”. The inetd daemon listens and accepts connections to multiple ports. When the inetd daemon accepts the connection, it generates a conversion utility that is specific to the port from which the received data was sent (ie, the implantable medical device).

  The received information 404, 407, 410 passes through the respective ports 403, 406, 409 as encoded data 412, 415, 418. As used herein, the term “encoded data” is used in its broadest sense to mean data that is in the form inherent to the implantable medical device from which the data was derived. Thus, a specific pacemaker generates encoded data in one format, while another pacemaker generates data encoded in another format. The two format types are, for example, encoded data 412 and encoded data 415, respectively.

For illustrative purposes, one type of encoded data derived from an exemplary implantable medical device is described herein. The encoded data provided is unique to the implantable medical device from which the data is derived, so interpreting the encoded data will identify the device type that generated the data. Including. Those skilled in the art will recognize a number of different device types, each based on the disclosure provided herein, each generating its own data set. Of course, the following data types will be recognized by those skilled in the art as being exemplary and not limiting. Having stated above, exemplary encoded data includes ASCII header information as follows. That is,
# TYPE: EPISODE SAVE DATE: 02/25/04
# PROGRAMMER MODEL: XXX.X SERIAL: 0123456
# DEVICE MODEL: YYYY SERIAL: 543210
# RAM VERSION: 1.1 ROM VERSION:
# APPLICATION MODEL: ZZZZ VERSION: 1.7
FORMAT CODE, 1
[EPISODE EPISODE: 1432 INDEX: 87]
EpisodeNumber, "1,432"
EpisodeEgmShkChannel, 1
EpisodeEgmVChannel, 1
EpisodeStartDate, 15-FEB-2004
EpisodeStartTime, 16:11
EpisodeEndTime, 01: 47
EpisodeEndMessage, Data Overwritten
EpisodeInduced, Spontaneous
EpisodeInitialRate, 142
EpisodeMeasuredOnsetPercent, 0
EpisodeMeasuredOnsetTime, 0
EpisodeProgrammedStabilityAcc, Off
EpisodeProgrammedStabilityInh, 18
EpisodeProgrammedOnset, 19
EpisodeProgrammedVFRate, 190
EpisodeProgrammedVTRate, 140
EpisodeProgrammedVT1Rate,-
EpisodeProgrammedSRD, 1: 00
EpisodeProgrammedOnsetLogic, And
EpisodeEgmAChannel, 1
EpisodeProgrammedVGreaterARate, On
EpisodeProgranimedAFibThreshold, 200
EpisodeATRTerminationMessage,
[ATTEMPT EPISODE: 1432 ATTEMPT: 1]
AttemptNumber, l
AttemptPreAverageVRate, 142
AttemptMeasuredStability, 3
AttemptDetectionZone, VT Zone
AttemptTherapyAccelerateNote,
AttemptTherapyDelayNote, * Therapy Delayed until SRD
AttemptPostAverageVRate, 143
AttemptTimestamp, 01: 03
AttemptPreAverageARate, 141
AttemptAFib, False
AttemptVGreaterARate, False
AttemptPostAverageARate, 140
AttemptATPBurstTimeOffset, 0l: 23
AttemptATPName, VT ATP 1 Ramp
AttemptATPTherapyDelivered, 3 Bursts

The ASCII header information is followed by a number of encoded binary fields. As an example, the following encoded binary data (represented in ASCII character format) received from an implantable medical device is detected near the patient's atrium at or near the beginning of episode number 1432: Describe the patient's cardiac function. That is,
・
・
・
・

As another example of encoded binary data received from an implantable medical device, the following data (again expressed in ASCII character format) was detected near the patient's atrium following episode number 1432: Describe the patient's cardiac function.
・
・
・
・

  In some cases, the encoded data derived from the implantable medical device includes an error detection code and / or an error correction code (eg, checksum or CRC). The code is used to determine whether the data has been manipulated after being received from the implantable medical device or whether the data has not been properly transmitted from the implantable medical device.

  The encoded data 412, 415, 418 is buffered by the respective data reception blocks 421, 424, 427. Each of the data reception blocks 421, 424, 427 releases any of the buffered encoded data 430, 433, 436. The buffered encoded data 430, 433, 436 is sent to corresponding interpretation systems 439, 442, 445, respectively. Each of the interpretation systems 439, 442, 445 is designed to decode the respective buffered encoded data 430, 433, 436. As used herein, the term “decoding” is used in the broadest sense, and any data in which the encoded data is transformed or otherwise modified to conform to the desired format. Means the process.

  As an example of decoding, buffered encoded data 430 may include a portion of an implantable medical device identification number that spans several bits in the data stream. In such a case, the interpretation system 439 can be responsible for reassembling the distributed bits into, for example, a 2-byte word. Alternatively or additionally, the exemplary data described above is parsed and decoded to generate various data fields. For example, device type, model number, serial number, patient name, lead impedance, episode time stamp, episode date stamp, and many other device parameters are decoded from the encoded binary data.

  The decrypted data 448, 451, 454 is sent to the respective data abstraction engines 457, 460, 463. The data abstraction engines 457, 460, 463 each have a global field common to the data received from the implantable medical device groups 404, 407, 410, with particular elements of the respective decrypted data 448, 451, 454, respectively. Associate with. Data abstraction engines 457, 460, 463 provide decrypted and abstracted data sets 466, 469, 472, respectively. In some cases, the decoded and abstracted data set 466, 469, 472 is sent to a format conversion engine 475 that provides a converted data output 478.

In one particular embodiment, the data abstraction engine 457, 460, 463 assembles the decrypted data 448, 451, 454 into an XML flat file format. Format conversion 475 is pass-through. In other embodiments, the XML format is converted to a specific spreadsheet format or other suitable format. One such example of a decoded and abstracted data set in XML format derived from the encoded binary data described above is as follows.
<parameter name = "PatientName"> JONES, SMITH </ parameter>
<parameter name = "PrmRtcDateTime"> 25-FEB-2004 18:35 </ parameter>
<parameter name "SystemModelNumber"> H135 </ parameter>
<parameter name = "ProgrammerModel"> XXXX </ parameter>
<parameter name = "ProgramrnerSerialNumber"> 0123456 </ parameter>
<parameter name = "SystemSerialNumber"> YYYY </ parameter>
<parameter name = "SystemFirmwareRevision"> 1.1 </ parameter>
<parameter name = "ProgrammerApplicationModelNum"> ZZZZ </ parameter>
<parameter name = "ProgrammerApplicationRevision"> 1.7 </ parameter>
<parameter name = "EpisodeNumber"> 1,432 </ parameter>
<parameter name = "EpisodeStartDate"> 15-FEB-2004 </ parameter>
<parameter name = "EpisodeStartTime"> 16:11 </ paranaeter>
<parameter name = "Episodelnduced"> Spontaneous </ parameter>
<collection name = "C_EGRAM_ONSET">
Onset EGM (10 sec max)
<traces frequency = "400 hz">
<egram_data source = "atrium" samples = "4000"> 8202, 8202, 8197, 8192, 8180, 8169, 8174, 8179, 8185, 8192, 8198, 8205, 8207, 8209, 8214, 8219, 8299, 8380, 8076 , 7772, 7973, 8175, 8231, 8287, 8292, 8298, 8270, 8243, 8224, 8205, 8193, 8182, 8175, 8169, 8167 {....}
<collection name = "C_EGRAM_POST_ATTEMPT">
Post-attempt EGM (10 sec max)
<traces frequency = "400 hz">
<egram_data source = "atrium" samples = "2774"> 8192, 8192, 8192, 8192, 8192, 8192, 8190, 8189, 8190, 8192, 8190, 8189, 8190, 8192, 8192, 8192, 8190, 8189, 8192 , 8195, 8193, 8192, 8192, 8192, 8190, 8189, 8199, 8209, 8280, 8352, 8089, 7826, 8002, 8179, 8229 {....}

  In the embodiment of the present invention, each of the interpretation engines 439, 442, and 445 is implemented as software. Further, in some cases, at least a significant portion of the software is identical to software implemented within a programmer that is specific to a particular implantable medical device or a particular group of implantable medical devices. For this reason, the development work required to create the data conversion system 232 is greatly reduced. Further, the scalability of such a system is enhanced because software from the device specific programmer is ported and / or recompiled for use in the data conversion system 232. In addition, a pipe or thread (eg, a combination of port 403, data receive block 421, data abstraction engine 457) is ported and / or around an interpretation system consisting of compiled software (eg, interpretation system 457). It can be assembled.

  In some cases, the decrypted and abstracted data is returned to the system server 228 where it is stored in the generic database 238 in XML format or in a specific database format, as described below. Stored. A unique file name is given to the converted file. That's because those files are equivalent to blank files or episode files, so all files are stored directly under the patient directory or patient record, and there is absolutely no need for another level directory Because it does not exist. For example, “1743_200134 / 0000001234.eps” and “1743_200134 / 00abde87.bnk”. In various cases, the converted output data 478 is returned to the system server 228 and stored in the comprehensive database 238 at the server 228, whereas in other cases the converted output data is Returned to the system server 228 where it is forwarded directly to the requester or requester system.

  Referring to FIG. 5, a flowchart 500 illustrates one method according to some embodiments of the present invention for real-time processing of data from a raw database 230 based on specific requirements. In accordance with flow diagram 500, data conversion system 232 is configured to prepare data for the selected recipient (block 510). This includes indicating a number of data fields known to the data abstraction engines 457, 460, 463 and a specific desired format known to the format conversion engine 475.

  Next, data is pulled from the raw database 230 and sent to a particular one of the ports 403, 406, 409 based on the type of implantable medical device from which the data was obtained (block 520). As described above, the application associated with that particular type of raw data that sets up the pipe (eg, data receiving block 421, interpretation system 439, data abstraction engine 457, format conversion system 475) through which the data is processed. Is generated (block 530). The information is then converted from raw data, ie, encoded data, to a converted data output as described above (block 540). The converted data is then directed to the desired recipient and / or repository (block 550).

  As described above, in some cases, all of the raw information is converted (ie, decrypted) and directed back to the comprehensive database 238. In other cases, only a portion of the raw information is converted and redirected to a recipient and / or repository, such as subset database 248, 252, for example. In such cases, the information to be included with the output (to be used by the data abstraction engines 457, 460, 463) and the format in which the output is to be transmitted (to be used by the format conversion engine 475). A command to indicate is given.

  The data abstraction engine 457, 460, 463 receives the decrypted information 448, 451, 454, but only the part of the information specified by the command is held by the data abstraction engine 457, 460, 463. The That portion of the retained information is sent to the format conversion engine 475, where the data is formatted in the selected format. In some cases where the desired format is identical to the format provided by the data abstraction engines 457, 460, 463, the format conversion engine 475 simply passes the data through. Thus, for example, if the data abstraction engine provides data in XML format and the desired format is XML, no format conversion is performed. Alternatively, if another format is desired, such as a specific spreadsheet format, the data from data abstraction engines 457, 460, 463 is formatted into that spreadsheet format. The information is then returned to the system server 228, which then sends the information to the requesting entity and / or the designated subset database.

  When the conversion is complete, it is determined whether another data generation should be performed (block 560). If additional generation is to be performed (block 560), as described above, the raw data is accessed to match the received command, and the data is transformed and provided to another entity (block 510). Alternatively, if no further generation takes place (block 560), the process ends.

  Referring to FIG. 6a, a flowchart 600 illustrates a method for performing clinical and utility tests using the system 100, according to some embodiments of the present invention. Various participants are identified according to flow diagram 600 (block 602). In a normal scenario, one or more physicians who will implant a certain type of implantable medical device are selected. However, based on the disclosure provided herein, several other “participants” will be recognized by those skilled in the art, including, for example, recipients of a given medical device.

  Those participants are enrolled in the study (block 604). This registration includes downloading or sending one or more software programs or other access tools that allow participants to access the system. Further, registration includes receiving various information about the participants that can be received via a communications network or via regular mail. In certain cases, this information is provided using one or more of the software programs provided when the participant registers. This registration information includes the participant's name and contact information. Further, in some cases, participants are paid for participation, so registration includes obtaining tax payer information, direct deposit information, and the like. One of ordinary skill in the art will recognize a number of other registration data that can be collected for a participant based on the disclosure provided herein.

  Once the participant is registered, various information is collected via the participant or participant system (block 608). The information may be information received from an implantable medical device that is read using a device programmer, or other device monitor, as described above, for example. Furthermore, the participant can input various information such as subjective data, objective data, other patient information, and the like. The received information is processed separately depending on the type of information. For example, information entered by the participant is verified to ensure that the information is entered correctly (block 610). If the information is not entered correctly (block 611), the system notifies the participant to correct the error (block 612). This verification process is described more fully in connection with FIG. 6b.

  Further, the received medical device information is stored in the raw database 230 as described above (block 620). Since the data received from the implantable medical device is encoded, the encoded data is sent to the data conversion system 232 where it is converted as previously described in connection with FIG. 4 (block 622). The resulting converted information is then verified (block 630) to ensure that the conversion has been performed properly and to ensure that the implantable medical device is properly configured. This verification process is described in more detail below in connection with FIG.

  After the information entered by the participant and the uploaded medical device information are verified together, the system processes the payment to the participant (block 640) and places the verified data in the comprehensive database 238. Store (block 650). In addition, various portions of the collected information are distributed to other related databases.

  Next, with reference to FIG. 6b, one embodiment of a method for validating information entered by a participant (block 610) will be described in more detail. As mentioned above, during or immediately after the patient visit, the physician (or assistant or data entry service) may provide objective information, subjective information, or other medical information or diagnosis that may be appropriate about the patient. Enter information about the patient, including information. In one embodiment of the invention, the physician is given a data entry screen. This screen prompts the physician to enter at least some of the patient information. A physician's computer system data entry screen or it runs on a mobile data entry device, such as a PDA, cellular phone, or some other mobile device. The data entry screen may also be any suitable data entry program such as a device resident program or an internet web page or internet web applet downloaded to the physician's device.

  After the physician enters the data into the data entry screen or data entry program, the data field is validated to ensure that the data entry is correct (block 611). Data entry validation includes many different types of validation techniques. For example, in the case of objective data entry, data entry validation ensures that height, weight, or other entered objective measurements are valid. One example compares height, weight, or other variables with a reasonable range. Also, the diagnostic information is verified to ensure that appropriate diagnostic information is entered. For example, an entered medical term is confirmed to ensure that the term actually exists, or an entered diagnosis is confirmed, and the diagnosis is validated based on other entered data. It is ensured that As will be appreciated by those skilled in the art, there can be several different ways of validating data entry fields, and thus the present invention is not limited to any particular validation process or technique.

  The field validation process may also be performed by a data entry device at the physician's location, or may be performed by a central processing system, such as the data collection system 206 or central data processing-repository system 208 in FIG. . In the example performed by the central processing system, the entered data is transmitted from the physician's system to the central processing system, for example via a web page or web applet, where it is verified. However, in both cases, the validation process is real-time and the physician or data entry person is notified of the error relatively quickly (block 612).

  If a data entry error occurs, the physician or data entry person is prompted to correct the error and resubmit the information (block 618). Rather, if the data appears to have been entered correctly, the data is transmitted to a central processing system, such as the data collection system 206 or central data processing-repository system 208 of FIG. In the central processing system, the data entered by the participant enters a second verification process that includes testing the entered data against previously entered data or recorded data (block 613). . In accordance with this aspect of the invention, the entered data is compared with the data in the comprehensive database 238 or the subset database 248 as backup verification.

  Again, several different verification checks are performed. For example, entered height, weight, or other patient demographic information is verified against previously entered data to verify that the information is valid. If the patient's height or weight has changed significantly since the previous visit, the physician is prompted to verify the information entered. In addition, if newly entered diagnostic information is inconsistent with the previous diagnosis, the system notifies the doctor. If the system detects a validation error, the system notifies the physician or data entry person of the error (block 614). The physician can then correct the error or verify that the entered data is correct (block 618).

  It is sometimes beneficial to perform multiple measurements or backup measurements to obtain the most accurate information possible. Thus, in one embodiment, the system is configured to prompt the physician to perform additional or backup measurements for at least some of the fields (block 615). If the system has requested a backup measurement, but the physician has not entered a measurement, the system prompts the physician to enter additional measurement data (block 619). The physician can choose to enter additional measurements (block 619), or the physician can choose not to enter additional measurements. If no additional measurements are entered, the system can flag the measurement data as unreliable, or the system may indicate that the measurement data may have errors or a backup measurement. A weighting factor indicating that the reliability is inferior to that of the data accompanied with can be added to the measurement data.

  Finally, the subjective information entered by the physician is normalized to remove or compensate for possible physician prejudice (block 617). As will be appreciated by those skilled in the art, subjective information is just that, that is, subjective, and doctors can use a variety of medical, emotional, and other factors based on their beliefs or emotional state. Have different views on these factors. For example, some doctors may consistently view one subjective analysis negatively, while others may consistently view the same analysis positively. There is. Thus, according to one embodiment of the present invention, the system can adjust or normalize some subjective data based on known physician preconceptions. Alternatively, the system can calculate a statistical average for subjective information entered by several physicians and discard information that is not within the average range. There are a number of different ways in which the entered data can be normalized based on a number of different factors, so the present invention is not limited to the examples described herein.

  As previously described, implantable medical device data is transmitted to the central data processing-repository system 208 and stored in the raw database 230 (block 620). The implantable medical device information is then decoded and, for example, in XML format as described above with respect to FIG. 4 (block 622). The resulting transformed or decrypted XML data is verified (block 630) to ensure that the transformation is done properly and that the implantable medical device is properly configured. Is done. Next, with reference to FIG. 6c, one embodiment of a method for validating converted medical device data will be described in more detail. In the illustrated embodiment, the transformed XML data is compared to the raw data stream (block 632). In accordance with this aspect of the invention, most of the data in the raw data stream is in ASCII format. Thus, to verify the conversion, the system compares the XML data with the ASCII data to determine whether the data has been properly converted (block 633). If errors are found, the system corrects data fields with errors or re-runs the conversion process to correct those errors (block 634). Also, if an error is found, it may be necessary to troubleshoot and correct the conversion process before proceeding.

  After determining that the converted XML data is error free, the system verifies the implantable medical device configuration (block 636). As described above, one application of the system and method of the present invention is to monitor and manage clinical trials, for example, to obtain FDA approval for a device or to test various applications of a device. Thus, in order for a clinical trial to be successful, it is important for the physician to configure the implantable medical device according to the clinical trial parameters. Also, in some cases, even if the device is not analyzed as part of a clinical trial, for example, by confirming that the device configuration is appropriate for the patient's diagnosis or medical condition, It is still possible to verify the device configuration.

  In accordance with this aspect of the invention, the system analyzes various medical device parameters from the medical device data stream to ensure that the physician is properly configuring the medical device (block 637). . For example, the system can check medical device parameters against a pre-determined clinical trial configuration to verify that the device is configured correctly. If the device is not configured correctly, the system can make the appropriate changes and instruct the physician to adapt the device to clinical study parameters (block 683). As described in more detail below, the system can delay the clinical trial payment to the physician until the device is correctly configured. Thus, one important advantage of the present invention is that it can provide immediate medical device verification feedback to the physician, so that the physician can be implanted while the patient is still in the physician's office. Appropriate changes can be made to possible medical devices, thus facilitating more accurate clinical research and faster payment approval for physician services. After the implantable medical device data is verified, the system continues with the database population procedure and the participant payment procedure (block 639).

  According to an alternative embodiment, the system is configured to provide diagnostic advice in an intelligent manner. For example, the system can analyze the patient's medical condition and history and determine that the implantable medical device is not optimally configured for the patient and the patient's condition. If this occurs, the system can provide device configuration and other diagnostic advice, and the physician may or may not follow the configuration or advice.

  In prior art systems, it was cumbersome and difficult to handle the payments to physicians for participating in clinical trials. Each time a doctor sees a patient, the doctor must submit a document requesting payment. Before a physician receives payment, the paying entity (typically a medical device manufacturer) must verify the physician's work to verify that the physician is complying with clinical research requirements. If clinical research requirements are not met, the paying entity must inform the physician of the changes to be made. A major problem with older systems is that doctors can take weeks, if not months, to be notified of the problem. This delay makes it difficult to obtain the information necessary to correct the problem. In fact, often doctors must revisit patients to correct medical device configuration errors or obtain new patient information. This is very time consuming and expensive. Also, after a follow-up visit, the doctor will need to re-submit documents for payment, and the process will start over.

  On the other hand, if everything is appropriate, the paying entity manually prepares the check request. This must be approved before payment is issued. A check request involves a person manually entering a document by entering payment information, such as name, address, telephone number, tax ID, department where the charge is being made, amount, and the individual approving the request. It is usually necessary to complete. The request is then sent to an approval body that recognizes the request. If approved, the request is then sent to accounting for processing, which generally requires that data be manually entered into the system so that a check can be cut. To do. The paying entity must follow this procedure for each patient of each physician in the clinical trial, which can reach thousands for each study. As a result, medical device manufacturers can cost tens of thousands of dollars to process those check requests, if not every year, up to hundreds of thousands of dollars.

  The system and method of the present invention automates the above process. First, as described above, medical information (including medical device information) is automatically uploaded to the central data processing-repository system 208 and verified in real time or near real time. As a result, if there are data errors or procedural errors, the system can instruct the physician on how to correct those problems. In some examples, the error is corrected while the patient is still at the physician's office, thus reducing the need for a follow-up visit to correct the error. Also, after the data has been verified, the system of the present invention is adapted to automatically process participant payments, thereby eliminating the need for manual procedures.

  Next, with reference to FIG. 6d, one embodiment of a method for processing participant payments (block 640) will be described in more detail. First, the physician has completed a payable task (eg, performing device embedding procedures, performing follow-up tests, entering clinical trial data into the system, etc.) and verifying the task Thereafter, the system automatically enters payment information into the database (block 642). In some embodiments, the payment information includes physician payment information, procedures performed, payment amount, etc. Much of this information is probably already stored in the system database, so it is pulled from that database and populated into automatic payment records for processing. For example, since the physician ID is known, the physician's address, phone number, tax ID, clinical trial information, etc. are pulled from a comprehensive database or some other database and used in the payment record.

  The system is configured to process payment records immediately, or payment records are accumulated and processed periodically, eg, monthly or quarterly (block 644). Regardless of the payment frequency, payment records for multiple physicians are accumulated and forwarded for approval (block 646). In this way, the approver can review and approve hundreds of payment requests at a time, rather than individually, as is done in prior art systems. According to this aspect of the invention, payment records are accumulated and made into an electronic report or form and electronically transferred to an approval authority. In one embodiment, the payment record is formatted into an EXCEL® spreadsheet and transferred via email. In other embodiments, other electronic reports or communication means are used. Those skilled in the art will appreciate that the present invention is not limited to any particular report format or communication process.

  After the payment is approved, payment information is electronically submitted to the accounting system for processing (block 648). Again, any communication process is used. In one embodiment, payment information is converted to an EXCEL® spreadsheet and transferred to an accounting system, which reads the data from the spreadsheet into the system for processing. Alternatively, the payment information can be converted to HTML format, XML format, or some other format and transferred to the accounting system. In yet another embodiment, the accounting system is compatible with the system database so that the accounting system can obtain information directly from the database using SQL calls, etc. Regardless of how the accounting system receives the data, upon receipt, the accounting system processes the payment and prepares the check accordingly. In addition, the system is configured to prepare a payment report for review, and the system is configured to allow the physician to access the system and see how much payment should be made to the physician. Thus, in at least some embodiments of the present invention, a push button approach allows for the extraction of verified payment data for each doctor / clinical for each payment compared to previous manual preparations. It is possible to make daily or quarterly (possibly 6 months to annual) payments per doctor / clinic, and allow multiple payments to be approved for each payment. When done in batch mode, the possibility of duplicate payments is flagged and reconciled. In some embodiments, payment information is extracted from a database and associated with each record is flagged to indicate the payment being processed in relation to that record. For future payments, the flag is checked to determine if the payment has already been processed.

  As described above, after the data (ie, objective information, subjective information, implantable medical device information) is verified, one or more databases, such as a comprehensive database 238 and / or subset databases 248, 252 Automatically populated. The process of populating one or more databases is shown in FIG. 6e. According to the illustrated embodiment, after objective and subjective data for a particular patient is verified, that data is populated into a database record associated with the patient name or other ID. The manner in which data is populated in the database depends on the particular database being used and the format in which the database receives the data. In one embodiment, data is received in XML format in a known manner and populated into database records. That is, the program extracts data from the XML tag and populates the data into the corresponding database record field. As will be appreciated by those skilled in the art, any database system may be used, such as SAP, Oracle, People Soft, JD Edwards, Microsoft SQL Server, SAS, etc. In one embodiment, a SAS database is used.

  In addition, implantable medical device data is also populated in a comprehensive database 238 after being verified. In accordance with this aspect of the invention, implantable medical device data is converted from XML format to a database record. However, before the data is read into the database record, it is marked with a patient identifier and a date-time stamp. The patient identifier is any suitable identifier such as a name, patient ID number, medical device ID number, etc. Date-time stamps are also used to load multiple device downloads from a single day into the system. Downloads are distinguished by time stamps. Similarly, date stamps are used to distinguish between downloads from different days. In this way, the database can hold separate and different records for each medical device download.

  Further, according to another embodiment of the present invention, when a pulse generator, such as a defibrillator, etc., does not generate any new pulses, the implantable medical device information from the first download is It is the same as the device information from the subsequent download. When this occurs, subsequent device download data is duplicate information and is not saved.

  After the data is populated in the comprehensive database 238, some or all of the data is made available for use by third parties as described above. In one embodiment, the system may create one or more third party databases, such as subset databases 248, 252 with a portion of the total available data (block 654). The subset database is maintained in the central data processing-repository system 208 or in other locations, such as the data collection system 206 and / or the diagnostic system 210. For example, data is transmitted to those systems and populated by those systems into a subset database. Further, after the subset database is created, security and control functions that control access to data in the database are implemented (block 656). Thus, in this way, the HIPPA control requirement is satisfied.

  Furthermore, according to other embodiments of the present invention, instead of creating a new database for access by a third party, the third party is allowed to access authorized data, A comprehensive database 238 is configured with security functions and access control functions that prohibit access to unauthorized data. Thus, this may be another way of controlling data access and thus implementing HIPPA requirements.

  Referring to FIG. 7, a flowchart 700 illustrates a method for obtaining a medical analysis according to some embodiments of the present invention. According to flow diagram 700, a medical data set is received (block 705). Such a medical data set is received from a physician enrolled in the study, or other participant, as described above in connection with flowchart 600. The medical data set is processed as described above in connection with blocks 630-690 and is ultimately placed in the comprehensive database 238 (block 710). As will be appreciated, the data is placed in an alternative or additional database, such as subset database 252 associated with diagnostic system 210.

  In addition, reviewer groups associated with the received medical data are identified (block 715). A reviewer group is a collection of one or more individuals or one or more entities that can receive a portion of a medical data set and return an analysis of that portion of the medical data set. As an example, the reviewer group includes one or more doctors, specialists, or other trained medical staff who can provide medical diagnosis based on that portion of the medical data set. Based on the disclosure provided herein, one of ordinary skill in the art will recognize the various possible participants included in the reviewer group.

  A diagnostic limited data set is derived from the received data set (block 720). This process prepares the data for transmission to the reviewer and originates from implantable medical devices, subjective information provided by the physician, objective information provided by the physician, and / or the like Including the data to be used. If the reviewer is interested in only a subset of the received medical data set, the subset of interest is extracted and retained as a diagnostic limited data set. Further, in some cases, it may be desirable to exclude information from the diagnostic limited data set that can identify the patient with which the received medical data set is associated. This diagnostic limited data set is then communicated to each of the reviewers via communication network 202 (block 725).

  FIG. 8 is an example of a diagnostic limited data set presented in a graphic format. Referring to FIG. 8, a user interface 800 is displayed at a receiver such as a data input device 222, 258 associated with the reviewer. As shown, the user interface 800 includes a diagnostic limited data set presented as an electrocardiogram. This particular electrocardiogram is derived from the EGRAM_ONSET data 810, the episode occurrence point 815, and the POST_EGRAM data 820, previously described above as exemplary data in connection with FIG. In addition, the user interface 800 includes an input field 825 where the reviewer can insert a diagnosis based on the electrocardiogram data, and an input field 830 where the reviewer can provide additional notes and analysis. .

  Returning to FIG. 7, the reviewer analyzes the provided diagnostic limited data and provides an analysis of the data (block 730). This analysis is in the form of a medical diagnosis or other memorandum described in connection with FIG. That analysis is received and combined with corresponding analysis from other members of the group of reviewers (block 735). Thus, if there are 10 reviewers and all 10 reviewers report the same medical diagnosis, the analysis is reduced to a single medical diagnosis instruction. In such a case, a note is added indicating that all 10 reviewers have agreed. If a note or analysis is provided by a different reviewer than the other reviewers, the note or analysis is retained. If all examiners disagree, they cannot be combined and are therefore not implemented. The analysis data is associated with the corresponding medical data set (block 740) and stored in relation to the corresponding medical data set (block 750).

  Referring now to FIG. 9, a flowchart 900 illustrates a method for providing a diagnosis or other analysis based on a medical data set according to some embodiments of the present invention. In accordance with flowchart 900, a medical data set is received with a request for diagnosis (block 905). This medical data set is received, for example, from a patient physician seeking further guidance on the patient's condition. The relevant portion of the received medical data set is then identified (block 910). This includes removing portions of the medical data set that are unrelated to the requested diagnosis. As one particular example where a diagnosis related to human heart function is required, the relevant portion of the medical data set includes an electrocardiogram.

  For example, in the generic database 238 or subset database 252, one or more previously analyzed medical data sets are accessed (block 915) and the identified relationships of the received medical data sets The portions of the previously analyzed medical data set that correspond to certain portions of are compared (block 920). Thus, for example, a received electrocardiogram is compared with an electrocardiogram associated with a previously analyzed medical data set. It is determined whether the compared data portions are similar (block 925), and if the data portions are similar, that portion of the compared previously analyzed data set is stored in a temporary memory area. , Along with the analysis information maintained in association with the previously analyzed medical data set (block 930).

  It is determined whether further previously analyzed medical data sets should be considered (block 935). Thus, for example, the process continues until a single positive comparison is found, a preset number of positive comparisons is found, or until all previously analyzed medical data sets are considered. It is done. If further previously analyzed medical data sets are to be considered (block 935), blocks 915-930 are repeated. Alternatively, the process is completed by communicating the relevant portions of the matched previously analyzed medical data set along with the corresponding analysis information to the requester (block 940). As described above with reference to FIG. 7, the analysis information is, for example, medical diagnosis information.

  Finally, one or more embodiments of the present invention have been described in detail above for the sake of clarity and understanding. However, it will be understood that several changes and modifications may be practiced within the scope of the appended claims. Thus, while the present invention has been described in connection with specific embodiments and figures of the invention, these embodiments and figures are merely exemplary and are not intended to limit the invention. Rather, the scope of the present invention should be determined solely by the appended claims.

1 illustrates a prior art system for collecting medical information. FIG. 1 is a schematic diagram illustrating one embodiment of a system for collecting, validating, storing, using, and / or distributing medical device information. FIG. 5 is a flow diagram illustrating a method for uploading medical data according to some embodiments of the present invention. 1 is a block diagram illustrating a conversion system according to various embodiments of the invention. FIG. 5 is a flow diagram illustrating a method according to the present invention for operating the conversion system of FIG. 2 is a flow diagram illustrating a method for performing clinical and / or utility testing according to some embodiments of the present invention. 6b is a flow diagram illustrating one embodiment of a method for performing the “Participant Input Information Verification” task of the method of FIG. 6a. 6b is a flow diagram illustrating one embodiment of a method for performing the “device data verification” task of the method of FIG. 6a. 6b is a flow diagram illustrating one embodiment of a method for performing the “Participant Payment Processing” task of the method of FIG. 6a. 6b is a flow diagram illustrating one embodiment of a method for performing the “database population” task of the method of FIG. 6a. 4 is a flow diagram illustrating a method for obtaining an analysis associated with one or more medical data sets according to some embodiments of the invention. FIG. 6 illustrates an exemplary graph analysis request interface according to various embodiments of the present invention. 6 is a flow diagram illustrating a method for providing a diagnosis or other analysis based on a medical data set according to some embodiments of the invention.

Claims (13)

A microprocessor-based controller;
A system for controlling the distribution of medical data including a computer readable medium containing instructions executable by the microprocessor-based controller, wherein the instructions receive a first format data set from an implantable medical device Steps,
Identifying a group associated with the implantable medical device that is one of a plurality of groups;
Selecting an interpreter associated with the group;
Applying the interpreter to the data stream such that the data stream is converted from the first format to the second format. The computer-readable medium is
Storing the data stream in the first format in a raw database;
10. The system of claim 9, further comprising instructions executable by the microprocessor-based controller to store the converted data stream in the second format in a comprehensive database. The computer-readable medium is
Storing the data stream in the first format in a raw database;
Storing a first portion of the converted data stream in the second format in a first subset database;
10. The instructions further comprising: instructions executable by the microprocessor-based controller to store a second portion of the converted data stream in the second format in a second subset database. The described system. The computer-readable medium is
Accessing the raw database;
12. The system of claim 11, further comprising instructions executable by the microprocessor-based controller to generate at least one of the first subset database and the second subset database.   The system of claim 11, wherein the first subset database includes patient specific information.   The system of claim 11, wherein the second subset database includes diagnostic limited information. The computer-readable medium is
Providing a portion of the diagnostic limited information provided to a plurality of recipients;
Receiving the diagnostic data associated with the portion of the diagnostic limited information from at least one of the plurality of recipients and storing the diagnostic data in the second subset database. 15. The system of claim 14, further comprising instructions executable by a plurality of controllers. The computer-readable medium is
Receiving a diagnostic query including specific diagnostic limited data;
Comparing the specific diagnostic limited data with at least a portion of the diagnostic limited information to determine a closest match;
Instructions executable by the microprocessor-based controller;
16. The system of claim 15, further comprising instructions executable by the microprocessor based controller to provide a diagnosis based at least in part on the closest match. The computer-readable medium is
Receiving a data set containing objective data collected by a physician;
10. The system of claim 9, further comprising instructions executable by the microprocessor-based controller to receive a data set that includes subjective data collected by a physician.   The system of claim 9, wherein the data set in the first format from the implantable medical device is received via a communication network.   19. The data set in the first format from the implantable medical device is collected by a collection device selected from the group consisting of a device group specific programmer, a bedside monitor, and a mobile monitor. System.   The communication network includes at least one element selected from the group consisting of the Internet, a cellular telephone network, a public switched telephone network, a local area network, a wide area network, and a virtual private network. System.   The microprocessor-based controller includes a single processor based system, a multiple processor based system in which all of the processors are juxtaposed, a multiple processor, one or more of the multiple processors being a computer Including a processor selected from the group consisting of systems distributed over a network, wherein the computer readable medium is a single computer readable medium, a plurality of juxtaposed computer readable media, one or more across the computer network 10. The system of claim 9, wherein is selected from the group consisting of a plurality of distributed computer readable media.

Images