WO2005076982A2

WO2005076982A2 - System and method for identifying potential organ donors and notifying organ and tissue organizations

Info

Publication number: WO2005076982A2
Application number: PCT/US2005/003774
Authority: WO
Inventors: John G. Piano; Mathew Kropp; Tracy Wheeler
Original assignee: Transplantconnect, Inc.
Priority date: 2004-02-06
Filing date: 2005-02-07
Publication date: 2005-08-25
Also published as: WO2005076982A3

Abstract

[00106] A system and method for selectively identifying potential organ or tissue donors are provided. Patient information associated with one or more patients is received. The patient information may be from one or more medical facilities, and it may be pre-analyzed data or reports received directly from such medical facilities. It is determined whether a potential organ or tissue donor is at the medical facility based on the patient information. An organ procurement organization is notified based on the patient information.

Description

SYSTEM AND METHOD FOR IDENTIFYING POTENTIAL ORGAN DONORS AND NOTIFYING ORGAN AND TISSUE ORGANIZATIONS

FIELD OF THE INVENTION [0001] The present inventions relate generally to the identification of potential organ and tissue donors, and more particularly to a system and method for (i) identifying potential organ and tissue donors, (ii) notifying organizations, individuals and other entities that facilitate the process of recovering organs and tissue, such as Organ Procurement Organizations or their employees or agents, or similar individuals, organizations or entities (collectively, "OPOs"), and (iii) the evaluation and case management of donor cases by OPOs , and information sharing between or among OPOs and hospitals and other parties. BACKGROUND OF THE INVENTION [0002] Throughout the world, many people are in dire need of organ and tissue transplants. In the United States, Organ Procurement Organizations have regional responsibility for identifying potential organ and tissue donors, evaluating the suitability of such potential donors, obtaining family and other necessary consent and arranging recovery of organs and tissue for eventual placement with recipients through the selected United by Network for Organ Sharing ("UNOS") or through distribution of tissue by individual tissue banks. To successfully provide a healthy organ or tissue for potential recipients, qualified donors are identified, and their condition and medical records are reviewed and evaluated for suitability prior to brain death (in the case of organs) or following cardiac death (in the case of tissue). Because available organs and some tissue often have a very short shelf life, it is critical to identify potential donors quickly. In the U.S., organs typically cannot be released for donation until two doctors verify the donor's brain death. Then, consent of the suitable donor's family is required before any organs or tissue can be recovered. Finally, the OPO representative(s) must coordinate information and communications between hospitals, doctors and staff to locate and arrange an effective transplant for a recipient selected by UNOS (in the case of organs). When the typical organ donation process is successful, a single donor yields, on average, between three and four successful organ transplants; however, the total number of potential transplantable organs per donor is as high as eight. A single donor can donate up to 8 different types of tissue as well. [0003] Unfortunately, various systemic conditions in acute care facilities commonly prevent OPOs from effectively and timely identifying and evaluating potential organ and tissue donors. In current operations, OPOs rely exclusively on very busy emergency doctors and intensive care nurses and staff to contact the OPO via telephone to provide the necessary information about potential donors. Due to the fairly detailed and extensive amount of information needed by OPOs to perform their functions, such telephone calls may take thirty minutes or more — time a busy nurse, doctor or staff member does not have. As a result, many potential donors are not reported to OPOs at all and many others are reported too late for OPOs to effectuate timely procurement. Between non-notification and late notification, a significant number of qualified potential donors are never reported by hospitals, even though such a result is punishable under Medicare regulations, which require that 100% of potential donors be reported to OPOs.

Additional causes of non-reporting and late reporting by hospitals include: (i) personal biases of some physicians, nurses and/or hospital staff against donation, and (ii) untrained and transient nursing and administrative staff that are unfamiliar with proper reporting requirements and procedures. [0004] For these and other reasons, a large number of potentially successful organ and tissue transplants never occur. Most notably, this results in the loss of life or the substantial diminution in quality of life. From an economic standpoint, these difficulties reduce the ability of OPOs, hospitals, doctors, and related persons and organizations from providing a highly valued and highly compensated service for which they are uniquely situated to provide, resulting in significant losses of potential revenue for all parties. [0005] These and other drawbacks exist with current systems and methods. SUMMARY OF THE INVENTION [0006] Accordingly, various embodiments of the present invention may be directed to a system for identifying and evaluating potential organ and/or tissue donors and notifying relevant entities so that those entities can properly evaluate potential donors and facilitate successful donation and recovery of organs and tissue. One exemplary embodiment is directed to a system for (i) automatically identifying potential organ donors based on data already collected and stored in hospital computer systems, (ii) analyzing that data to determine that the person is a potential organ or tissue donor, (iii) automatically notifying OPO personnel or other responsible organ or tissue procurement person or entity, (iv) allowing communication between relevant personnel via case notes and other comments, and (v) enabling such parties to access pertinent donor medical data for purposes of further evaluation and determination, as well as overall data management and reporting. [0007] The system may comprise a technology solution, such as a computer server or servers and/or appropriate computer software and/or hardware and or a combination thereof, or some other technology implementation (hereinafter described as "server"), that communicates with one or more hospital patient information databases for the purpose of identifying potential donors. Upon successful identification of a donor, the server provides electronic notification to the responsible OPO by way of email, web, wireless PDA, alphanumeric pager, automated telephone call, or other means. The server then provides the OPO with a means to access patient medical records and other information presently stored in the hospital patient information databases by way of web, wireless PDA, telephone, fax, or other electronics communication means. The technology solution described may exist in one or more components. A single server may reside at one or more hospitals and communicate directly with the OPO. A single server may reside at the OPO and communicate directly with one or more hospitals. A server may exist at a third location and communicate to one or more hospitals and/or the OPO directly or through an intermediate technology solution. Any other configuration of the software and hardware components of the technology solution may be employed. [0008] Other embodiments are also within the scope of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS [0009] FIG. 1 depicts an exemplary system for identifying potential organ and/or tissue donors according to an embodiment of the present invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS [0010] An embodiment of the present invention provides a system for automatically identifying potential organ and/or tissue donors and notifying an OPO. In one embodiment a server system analyzes organ and/or tissue donor medical information from one or more hospital data systems. As used herein, the term "hospital" may encompass any medical care facility, organization, and/or personnel. Also, as used herein, the term "data system" may encompass any server, accessible database, telephone system, computer, or other data containing or relaying element, including paper-based record systems. [0011] The server analyzes data in hospital data systems (e.g., via querying or data stream extraction or reception of communications from a hospital data system or otherwise) to identify potential organ and/or tissue donor candidates using existing data (e.g., Glasgow Coma Scale ("GCS"), physician or nursing notes, laboratory values, procedure codes recorded, equipment codes used, diagnostic codes, diagnoses, etc.). Where such information indicates a potential organ and/or tissue donor, the system would then notify the OPO or other responsible entity of such fact, as well as the location and other necessary identifying donor information. Further, the system would then provide OPOs or other entities with detailed medical data relating to the potential donor, such data to be drawn or received directly from the hospital data system, input by hospital or OPO or other entity staff, or otherwise. Upon selection of the candidate as an organ and/or tissue donor, the information collected by the server may then be made available to hospitals, surgeons and authorized staff involved in the recovery of such organs and/or tissue. Thus, the system provides timely notification and comprehensive donor patient information to OPOs and other authorized entities about potential organ and/or tissue donors at participating hospitals, such as acute care hospitals. Automated information delivery will significantly increase both the organ and/or tissue donor referral rate as well as the number of organs and/or tissue recoverable per donor recovered by providing earlier notification to the OPO or other responsible entity about patients that may become organ and/or tissue donors. As a direct result, the number of organ and tissue transplants will increase and the number of lives saved and/or enhanced will increase. [0012] Automated referral benefits participating hospitals by (i) guaranteeing Medicare regulatory compliance (100% referral rate), (ii) significantly reducing staff resources otherwise required to report patient deaths to the OPOs, (iii) increasing hospital revenues resulting from recovery and transplant surgeries and related procedures and services, and (iv) reducing the risk of human error in the reporting and donor patient information transfer process.. [0013] Advantages to OPOs and similar entities of the embodiments described include: eliminating missed potential donor opportunities; eliminating late donor referrals; substantially increasing the number of donor referrals; reducing travel and other costs by streamlining the donor evaluation process; eliminating the need for retrospective medical records auditing; saving more lives through increased transplants; and generating more OPO successes and increased revenues. Additionally, OPOs in the U.S. will be in a position to comply with the September 2003 mandate from the Department of Health and Human Services that calls for nearly 33% increases in organ donations and transplantations. [0014] According to an exemplary embodiment of the invention, a system is provided to automate the hospital referral process by notifying OPOs of potential donors in real-time, so that no phone call or other action by hospital staff is required. This eliminates missed and late referrals caused by hospital-OPO communication breakdowns. [0015] According to an exemplary embodiment of the invention, a system provides a remote, secure access to potential donor information in all OPO hospitals, on one or more centralized systems built for OPO use. This reduces inefficiencies caused by the fragmentation of many hospitals spread out over OPO territory, and it eliminates problems of divergent and/or incompatible hospital technology platforms. Also, or alternatively, the system may reside on each hospital data center to provide direct communication to OPOs or other responsible entities (with potential aggregation of information at one or more central sites). [0016] According to an exemplary embodiment of the invention, a system is provided that allows OPO staff to review patient information, such as charts, labs, histories, and medical notes and any other data/information from the hospital data center. The OPO staff can then collaborate with each other and make evaluations in a location remote from the hospital. This increases efficiency in the donor referral, monitoring and evaluation processes, freeing up OPO and hospital resources. Less time-consuming travel and site visits by the OPO personnel are required to effectuate a successful transplant because data can be obtained and communicated remotely by the OPO. [0017] According to an exemplary embodiment, a system is provided that enables OPOs to update potential donor cases and track overall data in real-time. Records can be updated periodically, such as many times each day. Updating can be manual or automatic. This eliminates the need for retrospective medical records auditing, and it allows OPOs to make updated assessments. [0018] According to an exemplary embodiment of the invention, an OPO-customized interface is provided that is accessible anytime via PC, laptop, PDA, smartphone, alphanumeric pager, telephone or other access device on a secure server. The benefits of the invention would include that nurses and hospital staff may spend less time dealing with OPOs (e.g., reporting new referrals and sharing patient information) and more time directly treating living patients and that OPO staff would be able to be notified and retrieve critical donor information remotely and on a timely, mobile basis. [0019] FIG. 1 depicts a system for identifying potential organ and tissue donors according to an embodiment of the invention. In this embodiment, a server 1 is provided at a remote location from the hospital and OPO. It should be appreciated that the functionality described may be distributed amongst the hospital data center(s), one or more remote locations, one or more OPOs and other systems as well. Also or alternatively, the functionality may reside on one or more hospital data centers for direct communication from the hospital to the OPO or other responsible party. The remote server example shown in Fig. 1 is just as example. Server 1 interfaces with one or more donor hospital systems 10 to transmit and receive patient information. Server 1 may comprise one or more input and output devices for communicating with the hospital systems 10 and one or more OPO access devices 4. OPO access devices 4 and hospital systems 10 may similarly comprise input and output devices for communication. An OPO access device 4 may comprise any communication device, such as a PDA, cell phone, email device, computer (such as a laptop or desktop computer), pager, facsimile machine, telephone, any device that can enable communication between an OPO and the server 1, and/or any other communication device. The communications may occur over the internet or any other wired and/or wireless communication network, such as a phone line, intranet, LAN, WAN, MAN, or dedicated data line. [0020] The server 1 and donor hospital systems 10 may comprise any server, network, router, accessible database, LAN, WAN, MAN, telephone system, computer, or other communication or information device or system. The server 1 may comprise a processor and one or more modules and databases. [0021] The hospital systems 10a, 10b may comprise a data collection system 50, a hospital database 52 for storing information (e.g., information collected by the data collection system 50), and a hospital operation/information system 54. The hospital systems 10 may comprise a hospital intranet, computer system, website, and/or server that stores and monitors hospital patient information and/or other information. The hospital data collection system 50 may comprise any system for collecting hospital and/or patient information, including automatic patient monitoring information systems (e.g., heartbeat monitors) and systems whereby hospital staff such as doctors and nurses manually (or automatically) collect patient data and transfer (e.g., upload) such information to the hospital system 10. [0022] Donor hospital systems 10 receive donor 16 and patient information from the hospital staff 11. The staff 11 may comprise doctors, nurses, other health professionals, information specialists, administrators, and/or other hospital personnel. The patient information may comprise the health condition of one or more patients, or other information related to the patient such as information relating to the patient's closeness to death. Such information may comprise information stored by hospitals for insurance reporting, medicine requirements, and other reasons. [0023] The hospital systems 10 monitor and store patient information. One or more systems may operate on hospital system 10 to pass such patient information to the server 1. The server 1 may also request such information from the hospital systems 10. The hospital systems 10 may automatically update the information on a constant or periodic basis. [0024] Server 1 communicates patient information to one or more OPOs 6 via an OPO access device 4. [0025] The server 1 may comprise various modules for processing information. A donor module 20 processes donor information (e.g., to identify and monitor potential organ donors). [0026] A criteria module 36 may specify criteria for processing patient and other data, such as specifying patient conditions (e.g., health data or diagnostic codes for one or more patients). The criteria may be indicators of imminent brain death, e.g., a Glasco Coma Scale score of 5 or lower. Some other criteria may comprise: diagnostic codes (indicating the various diagnoses of the patient and/or amount and/or type of care being provided to the patient), mechanical codes (e.g., codes that indicate the type of equipment provided or expected to be provided to the patient), physician notes, nursing notes, ventilator settings, heartbeat measurements, breathing rates and measurements for the patient and any breathing assistance apparatus. For instance, if breathing measurements indicate that a patient is substantially not breathing on their own as indicated by the measurements for a breathing apparatus and patient, then that patient may be a potential donor candidate. Also, if a patient's diagnostic codes or other information indicate a stroke or severe head and/or heart trauma, that patient may be a potential candidate. [0027] An updating module 24 may request and/or receive and process information from the hospital systems 10. For instance, the updating module may request updated data for a potential donor candidate. [0028] A reporting module 26 may process and/or aggregate information. For instance, the reporting module 26 may track total number of donors from a given hospital and provide other reporting to OPOs 6, hospitals systems 10, other tissue donation organizations, UNOS, and other entities. [0029] An OPO module 28 processes data useful to OPOs. For instance, the OPO module 28 may identify a potential organ and/or tissue donor by processing information from the donor module 20 and criteria module 36. [0030] A central database 35 stores information at the server 1. The server database 35 may store information received from different hospital systems 10. Further, information processed by the modules may be stored in the database 35. [0031] The server 1, such as an OPO server, requests information from one or more hospital communication systems. Alternately, the information may be provided to the server 1 on a continuous or periodic basis without requiring a request from the server 1. [0032] One or more OPO staff members 6 may be notified of a new potential organ donor 16. They may be notified within a specified time limit, such as within 15 minutes of the patient meeting the potential organ donor quaUfication criteria. Similarly, the OPO 6 may be notified of significant changes in the status of any potential organ donor 16. For instance, the OPO 6 may be notified within a specific time period (e.g., within 15 minutes or other negotiated update frequency period) of the occurrence of said change. [0033] The server 1 (occasionally referred to herein as "system") may provide authorized OPO staff 6 access to information about potential donors 16 such as demographics, diagnostic information, procedure information, lab reports, nursing notes, radiology reports, and any other available information that could help determine donor 16 suitability. The determination of suitability may be done by a person such as an OPO staff member 6 or hospital staff member 11. The OPO Module 28 may also determine information related to the suitability of one or more potential donors 16. [0034] The system 1 may provide the OPO 6 and participating hospitals 10 with information such as death notification and organ recovery reports. Such information may be generated by the reporting module 26 from information received from the hospitals 10 and/or stored at the database 35 (or, in one embodiment, in the hospital databases 52). [0035] Server 1 may receive a reliable stream of donor 16 data on a frequent basis. One possible mode of operation is for the server 1 to poll the hospital system 10 on a periodic basis using a remote workstation connection and 3270 terminal emulation. It may be preferable to the one or more hospitals 10 (e.g., in terms of security and server loading issues) to implement a service on the hospital that periodically transmits messages to the server 1 using a particular communication format or program, such as HL7. (It will be appreciated that while HL7 format is sometimes used herein for exemplary purposes, other formats may be used.) It should be understood that any or all communications between the hospital systems 10 and the server 1 may be in such a desired format. [0036] Periodically, a data collection may be initiated against the current hospital census for a set of designated hospitals 10. This query may identify all patients 16 having a predefined set of inclusionary procedure and diagnostic codes and may reject all patients having a defined set of exclusionary diagnostic codes. These inclusionary and exclusionary codes may be defined to maximize the likelihood that an identified patient will become an organ donation candidate. As a result, the number of identified potential donors at any point in time may be small. [0037] Patient record information including demographics, procedures, diagnoses, lab results, and radiology reports for each of the patients identified by the query may be retrieved. This information may be formatted into a desired format and transmitted to the server 1. This transmission may be encrypted and sent across a protocol to be jointly determined by hospital and server 1. Upon successful receipt of the message, the server 1 may return an acknowledgement message providing hospital with a guarantee of delivery to the OPO. [0038] To simplify the implementation for the hospital, the server 1 may determine when a patient's information has changed from a previous transmission. This frees the hospital system data collection system from having to maintain information regarding what data has been transmitted to server 1. It also ensures that in the event of a failed transmission, all current data may be available at the next transmission. [0039] Also or alternately, hospitals transmit patient update information instead of whole patient records. This decreases the amount of information passed, and thus less powerful communication devices are more able to receive and process the information. For instance, while some PDAs 4 may be ill-equipped to continually receive and process patient records for a plurality of hospitals 10, they may be capable of maintaining a large database and processing smaller changes. Complete patient records may be passed to the server 1 upon request. [0040] Update Frequency: The update frequency may be negotiated based on the needs of the OPO or other responsible party and the impact on the hospital's systems 10. A frequency of once every 15 minutes may be expected to provide an adequate balance between these two concerns. [0041] Patient Query: At each update, the hospital system may execute a query similar to the following pseudo-query to identify potential organ donors currently in the hospital:

SELECT Patient.* FROM Patient, PatientProcedures, PatientDiagnoses WHERE PatientPatientiD = PatientProcedures.Patientld AND PatientPatientlD = PatientDiagnoses.Patientld AND PatientProcedures.ProcedureCode IN <included procedure code list> AND PatientDiagnoses.DiagnosticCode IN <included diagnostic code list> AND Patient.HospitalID IN <included hospital ID list> AND PatientDiagnoses.DiagnosticCode NOT IN <excluded diagnostic code list> [0042] Transport Protocol. The server 1 may work with each hospital to determine an appropriate information transmission protocol that meets the server's 1 mutual needs. Preferred protocols include SOAP over https and LLP over secure TCP/IP, as described below. [0043] According to one embodiment, server 1 can implement a Web Service to which the hospital system 10 can connect and transmit a SOAP-formatted message. (SOAP is used herein as an exemplary format; the messages described herein may have any other format.) The HL7 message can be in either standard or XML format. 128-bit SSL encryption (or any other type of encryption) may be employed to safeguard the transmitted data. [0044] As an equally acceptable solution, server 1 may implement a TCP/IP server that accepts an HL7 message using the LLP protocol. Again 128-bit SSL encryption (or other encryption) may be employed to ensure data security. [0045] The following descriptions help to illustrate exemplary embodiments of the various entities that interact with one another in the execution of one or more embodiments of the invention. Some of the actors may be humans, while others may be software components or other entities. These definitions are not intended to be limiting. Further, as used herein, some of these terms may encompass other terms. [0046] Monitoring Software - The monitoring software may be installed at the hospital patient record system (which may be part of the hospital system 10) and/or the server 1 (or between the two). The monitoring software may intercept data about the patients, filter this data to contain only information pertaining to potential organ donors, and forwarding this filtered data to the server 1. The monitoring software (or a portion thereof) may be installed on the access devices 4. Also, monitoring software may periodically query data stored at the hospital if the hospital system does not stream data. [0047] Coordinator - A coordinator may be employed by the OPO and may be responsible for managing specific patient cases. The coordinator may also be referred to as a "transplant coordinator." [0048] Resource Manager - A resource manager may be an employee or agent of an OPO and may be responsible for determining which coordinators should be working on which cases. This role servers as a supervisor to the coordinators and ensures the quality of their work. [0049] Dispatch - The dispatch may be an agent of an OPO and may be responsible for fielding incoming referrals and determining to which coordinator a referral should be sent. [0050] Administrator - Each OPO may have one administrator who may be responsible for managing all user accounts within the OPO. The administrator has rights to manage only users and information within their OPO. As used herein, the administrator may be an agent of an OPO. [0051] System Administrator (or "server administrator") - The system administrator has access to every part of the server and can perform any role. This actor may be a single person employed by server and may be held to the highest standards of security and confidentiality. The system administrator may be an agent of the OPO. [0052] Hospital staff member - Any employee at a given hospital may serve as this role when entering a new referral into the server. No identification may be needed to serve as this role. [0053] Call Center Representative ("Rep") - An employee of a call center that serves an OPO may be a call center rep and has access to the referral entry screen. The call center rep may be an agent of the OPO. [0054] User - A user may be a user (such as an executive user) at an OPO or hospital that has rights to see some of the reports generated for their OPO, region, or hospital, as may be appropriate for their access control rights. As used herein, the term "user" may be encompassed by the term "OPO." [0055] Central database - The portion of the server that manages the storage and retrieval of all data for the server may be referred to as the central database. [0056] Consent - A family that agrees to donation is providing consent. [0057] Decline - Typically, the patient's next of kin must agree to donation for the OPO to proceed with the donation process. If the family does not agree then the referral may be disqualified for a donation. [0058] Device (aka "OPO access device") - Any hardware and/or software combination that can be used to access a user interface to the server. For example, one a device may comprise a web browser running on a standard PC and a wireless PDA. [0059] Donor - A patient that has been declared brain dead by two separate physicians at two different times, whose family has consented to donation, and whose physical condition and medical history do not preclude the retrieval of viable organs. [0060] Hospital - The entity providing medical services to patients that may be used to report referrals of potential donors. [0061] Medical Rule-Out - A referral that may be disqualified due to unacceptable medical history or conditions (such as excessive age, HIV+, sepsis, or cancer) may be considered a medical rule-out. [0062] Patient - A person that has been admitted to a hospital. [0063] Referral - A referral is a patient identified by a hospital as a potential organ or tissue donor. [0064] User Account - Each person accessing the server may have a user Account with which the server identifies them. A user may be an OPO or OPO-related entity, and vice versa. [0065] According to an embodiment of the invention, a method of identifying a potential organ and/or tissue donor is provided. The method comprises various actions that may be performed in a variety of sequences. It is not necessary that they be performed in the order described below. Because many of the actions are independent of each other, they may be performed in a variety of orders. Also, it is not necessary that all of the steps be performed at all. The steps provided below are provided as a list of exemplary actions and/or steps that may be accomplished according to one or more embodiments of the invention. [0066] It should be understood that the term "user" as used herein may comprise any person, entity, or organization that my access the server 1. For instance, a user may comprise an OPO 6. [0067] An administrator may add and/or modify a user account. The user account may be the account of an OPO 6, hospital 10, hospital staff member 11, or any other person or entity that may have access to the server 1 and/or hospital system 10. For instance, an administrator may create a new account or modify the properties of an existing account. Properties that may be modified for each account may comprise: username, first name, last name, OPO, OPO region(s) covered, role (such as coordinator, resource manager, dispatcher, etc.), email address(es), pager / SMS address(es), office phone number, cell phone number, home phone number, or other information such as personal information. The administrator may specify how many devices (e.g., computer browsers or PDAs) through which the user may be allowed to access the server 1 (the default value may be 1). A system-generated initiation password may be returned to the administrator, and it may be used by the newly created user to log in for the first time. [0068] An administrator may activate and/or deactivate a user account. An administrator may deactivate a user account to prevent the associated login from being used and to remove the user from all displayed user lists. Deactivating a user may not delete any information associated with that user, in order to maintain the integrity of all audit trails. The administrator may reactive the user at a later time and all associated user information may remain in place. [0069] A user may log in using a password, username, and or other identifier (such as an initiation password). When a user account is created, a system-generated password may be provided to the administrator and emailed to the user's primary email address. This may comprise a one-time password which may be used by the user to log into the server 1. Upon login, the user may immediately change his or her password. The server 1 may also install a certificate in the user's web browser or PDA, thereby locking the account to that hardware. By default, the server 1 may allow the user to install a certificate on only one computer 4 or one PDA 4. The user may request his or her administrator to add an additional device 4 to the user's account so that the user can use another computer or PDA. These and other methods of ensuring secure communications and access to hospital 10 and server 1 information may be used in accordance with the invention in this step and any other step that may involve passing information over a network. [0070] The user may initialize an additional OPO access device 4 such as a computer or PDA 4. If a user wishes to access the server 1 using an additional device 4 (e.g., a computer or PDA), they may request from the administrator that another device be added to their account. The administrator can add a device as described above. The user may receive an email at a primary email address with a new initiation password that may be used to log in from the new device. [0071] The user may log in with a full password. A user may log into the server 1 from a web browser or PDA by supplying a username and password. A valid certificate may be installed on the user's device in order for the server 1 to approve the user's credentials. The certificate need not be installed by this user, but may instead have been installed by another approved user. [0072] The administrator may view a device installation list. An administrator may view a list of all authorized devices on which valid certificates have been installed. For each device, the type may be listed (e.g., web browser or PDA) along with the user to which the device was originally issued. [0073] An administrator may de-authorize the access device 4. An administrator may, from the device installation list, de-authorize a device 4, thereby barring all logins, including valid logins, from that device. This feature could be used in the event that a user reported that their computer or PDA had been lost or stolen. [0074] A patient record system may identify one or more new potential donors 16. For instance, monitoring software installed on a hospital's patient record system may execute periodic queries against the current patient database. Monitoring software may also examine a real-time feed of patient data (e.g., from a flow sheet) to identify potential donors. Each patient record may be examined according to various criteria (such as criteria specified by the criteria module, e.g., diagnostic criteria). For instance the patient record may be examined for a Glasco Coma Scale of 5 or lower as the primary indicator of irnminent brain death. Patients showing a breathing rate at the same or within a value of 2 of the set respirator rate may also be identified as potential donors. In patient record systems that do not have data on GCS or ventilator settings, the diagnostic codes may be searched for a predefined set of inclusionary conditions and the procedure codes may be searched for procedures indicating mechanical ventilation. Upon identification of a potential donor, the monitoring software may acquire the complete patient record, including all historical data for the current patient record, and forwards the information to the server 1. [0075] A patient record system (e.g., an updating module or database as described herein) may detect one or more changes to one or more existing potential donors. If the monitoring software detects a change to the patient record for a patient that has previously been identified as a potential donor, this additional new information may be forwarded to the server 1. The server 1 may pass the information to one or more OPOs and/or deliver the information to the OPOs upon request. [0076] The patient record system may reset the status of the donor. For instance, if the monitoring software detects that a patient has been discharged or is otherwise no longer a potential candidate for organ donation, it may stop sending patient data to the server 1. [0077] The server 1 may receive a patient record from a hospital system 10 via the monitoring software. The information may be stored in the central database. The server 1 may receive patient record data at any time from the monitoring software. [0078] The dispatch may receive an email and/or web notification of a new referral. Upon identification of a new potential donor referral, the server 1 sends an email notification to the assign dispatch user. If a dispatch is currently logged into the web application, a notification may be shown on the screen Morming them of a new referral. [0079] The dispatch may assign a coordinator to the referral. From the web interface, dispatch may open a new referral to perform a preliminary rule-out analysis. If dispatch determines that the referral cannot be immediately ruled out (e.g., for age, HIN, cancer, etc.), dispatch may then assign the referral to a coordinator. The server 1 may then send a notification to the coordinator and the resource manager. [0080] The dispatch and/or coordinator may rule out the referral. From the web interface, dispatch may open a new referral to perform a preliminary rule-out analysis. If dispatch determines that the referral should be immediately ruled out (e.g., for age, HIN, cancer, etc.), then dispatch may mark the referral as a medical rule out and supply a reason. The referral may no longer appear in the referral roster. [0081] A resource manager and/or coordinator (e.g., an OPO 6) may receive a referral notification (e.g., via a PDA access device 4b). Once dispatch has assigned a referral to a coordinator, both the assigned coordinator and the resource manager may receive a notification alert, e.g., via a PDA or other communication device. This alert may take the form of an outbound message (such as an SMS or MMS message) that is passed (e.g., immediately) to the PDA 4b. The PDA application may interpret this message and notify the OPO 6, e.g., via pop up an alert on the screen providing basic information about the referral. Information shown may comprise: hospital, unit, patient name, GCS, ventilator status, admit time/date, referral time/date, age, and/or any other information about the referral. [0082] The coordinator may acknowledge receipt of referral notification. The coordinators receiving notification of a referral may acknowledge receipt of the notification. If the coordinator does not acknowledge receipt within a specified period of time after notification (such as 5 minutes), a notification may be sent to dispatch informing them of the coordinator's lack of response. [0083] A resource manager may reassign a referral notification. A resource manager may reassign, at their discretion, a referral to a different coordinator than was assigned by dispatch. From the referral roster, the resource manager may select a referral and assign a new coordinator. Doing so may cause a new notification to be sent to the newly assigned coordinator as well as a cancellation notification to be sent to the previously assigned coordinator, relieving them of their duty for this referral. [0084] A resource manager may be notified of a referral change of status. If the status of a referral is changed (e.g., to open case, medical rule out, decline, etc.), the server 1 may send a notification to the resource manager informing them of the change. If any reason is supplied with the change of status, the reason may be shown with the notification. [0085] A system may request the resource manager to approve a rule-out determination. If a referral is ruled out by a coordinator, the server 1 may send notification to the resource manager of the change of status. This notification may be delivered via PDA and may request that the resource manager approve or reject the rule-out determination. Before deciding on an approval or denial, the resource manager may view the record for the patient. If the resource manager denies the rule-out, the coordinator may be sent a notification informing them of the decline. The method provides for wireless access to patient records. A user, such as a mobile and/or web-based user, may view the referral roster. The user may view the current referral roster to see all patients currently being monitored as potentials donors. These patients have been referred by the server 1 but have not yet been eliminated due to a medical rule out, decline, or not brain dead determination, and have not yet been changed to open case status. By default, the roster may show patients listed in reverse chronological order by time/date referred. For each patient, data shown may comprise: last name, hospital, unit, GCS, admit time/date, refer time/date. The user may select any referral to view the associated full patient chart. [0086] The user may view the donor roster. The user may view the current donor roster to see all patients that have been identified as brain dead and whose families have consented to donation. By default, the roster may show donors listed in chronological order by time/date referred. For each patient, data shown may be: last name, hospital, unit, 1st time of death. The user may select any donor to view the associated full patient chart. [0087] A user may view a patient chart. The patient chart may contain all available data about a particular patient. The user may view a patient chart by selecting a referral from the referral roster or a donor from the case roster. The user may page through multiple pages in the chart containing the following data: patient demographics, lab flow sheet, nursing notes, GCS / ventilator flow sheet, and other information about the patient. [0088] A user may change patient status to rule out / decline / NBD. From the patient chart, a user may change the patient status to medical rule out, decline, or not brain dead. Changing to any of these statuses cause the referral to no longer appear in the referral roster. When specifying such a change in status, the user may supply a reason for the change and a notification containing this reason may be sent to the resource manager for approval. [0089] The user may change patient status to open case. From the patient chart, a user may change the patient status to open case if the patient has not been ruled out for a medical reason and if the family has given consent. This change of status may cause the patient to be removed from the referral roster and placed on the donor roster. [0090] The user may chart patient interaction. The user may record various interactions with the patient in an effort to manage the ongoing details of the case. Each patient interaction may be recorded in a database, e.g., in the OPO charting section of the patient chart. Information charted may comprise: 1st time and physician declaring brain death, 2nd time and physician declaring brain death, time family approached, time family consented, general notes, and/or other patient information. [0091] Data may be accomplished by a different user, or by the same user using different means of accessing the server 1. [0092] A hospital staff member ("hospital staff) and/or call center representative may report a potential donor. For hospitals to which the server 1 does not yet have an automated data feed, a web-based interface may be provided that allows a hospital staff member to report a new potential donor to the server 1. This interface may walk the user step-by-step through the process of reporting a referral, making the process as fast and simple as possible. The steps followed by the user may comprise: (1) enter patient name, age, hospital, unit, referring hospital staff member name, and/or other information; (2) indicate whether the patient is on a ventilator; if no, the user may conduct a tissue donation Questionnaire; (3) enter Glasco Coma Scale if known, and/or answer neurological exam; if Glasco Coma Scale number is not known, the user may fill out a questionnaire; (4) select primary diagnosis; (5) select any exclusionary diagnostic codes from provided list; and (6) the server 1 provides the user with a confirmation number for the completed referral. [0093] The user may view a referral census report. A user may view a referral census report that lists all patients referred. This report may be filtered by region, hospital, unit, coordinator, referral outcome, and timeframe. Data displayed in the report may comprise: patient name, sex, age, race, medical record number, hospital, unit, coordinator, referral outcome, date/time of admit, date/time of referral, date/time of brain death, date/time of cardiac death, organs/tissue offered, organs/tissue placed, and/or other patient information. [0094] A user may view referral summary report information. A user may view a referral summary report that comprises information, such as summary information about demographics, consent rate, placement rate, and other factors. This report can be filtered by various criteria, such as: region, hospital, and timeframe. Data displayed in this report may be totals and percentages according to: race, sex, region, hospital, unit, coordinator, and other variables. It also may comprise totals, e.g., by organ and referral outcome. [0095] A user may view a cross-tab report that allows them to slice the report data in arbitrary ways. This report may provide the user with an interface in which any number of parameters can be selected for a horizontal and vertical axis, with an aggregate function being executed on a third parameter in the cells of the report grid. Parameters that may be added to the cross-tab report are: region, hospital, unit, race, sex, age, coordinator, organ, referral outcome, and time. [0096] A security audit report may be generated. The server 1 administrator may view the security audit report. The security audit report may be used to determine access patterns, to spot malicious activity, to trace the security activities of a user that may be under surveillance, or to analyze and/or compile any other data stored in the central database and/or hospital systems 10. This report may show the following fields: username, first name, last name, date/time, security action (e.g., log in, log out, time out, access denied, and initialize device). The report may be filtered by OPO, region, username, date/time Range, and security action. [0097] A patient data audit report may be generated. A user or administrator may receive and view the patient data audit report. This report may provide an audit trail for events that related to a particular patient. To run this report, the user may specify a patient by first name and/or last name and/or medical record number. A report may be generated that lists every addition, change, and deletion of any data associated with the selected patient. Data listed may comprise: date/time, originator (e.g., "system" or username of editing user), action (e.g., insert, update, delete), property modified, value. The user may filter the report by date Range, by originator, by action, or by other criteria. [0098] The server 1 may integrate into hospital systems 10, such as a hospital's information technology system containing patient information (e.g., updated patient information). The server 1 may directly integrate into different software systems and platforms (e.g., those by Philips, Siemens, etc.) of a plurality of different hospitals. It may do so via a secure communication connection. [0099] The server 1 may collect and process patient data from one or more hospitals. It may do so automatically or manually. For instance, the server 1 may automatically scan the computer systems of hospitals to cull patient information, such as information that indicates which organ donor patients may have a low Glasco Coma Scale rating. Access to the server 1 may be controlled via password and other security measures, as well-known in the art. [00100] The patient data may then be made available to and delivered to OPOs

(e.g., in summary form). Such patient data may comprise "triggering conditions" (i.e., conditions that indicate a high probably of death of a potential donor). Triggering conditions may vary from hospital-to-hospital, and they may comprise: diagnostic codes and procedure codes; Glasco Coma Scale rating; ventilator settings; physician or nurse notes; medical history; current medications and/or treatment; and any other information relating to a particular patient. The purposes are (1) to identify potential organ and tissue donors, and (2) create a comprehensive patient chart for effective OPO/tissue bank donor case management. Another purpose may be to create a comprehensive ICU patient database. [00101] The system may provide for the automated transfer of information into a central database at the server 1. For instance, once a "trigger" occurs, the server 1 may automatically process and/or transfer relevant patient record data. The data may be stored in the central database and be made readily available to OPOs. The information may also be transmitted to them directly via web, PDA, email, SMS, alpha pager, telephone, or any other communication method. Comprehensive patient data may then be accessible to (or delivered to) OPO and tissue bank staff. The OPOs may run various search queries to locate or process specific information. The OPOs may also track and audit the information and produce custom reports. These functions may be accomplished in real time. The OPO (or OPO access device) may confirm that the OPO has received the information (e.g., automatically). [00102] The system may comprise a self-uploading mechanism. In lieu of, or in addition to, the automated process above, the system may enable hospital staff to enter data into the server's 1 database via an internet website, API, phone, fax, and/or any other means of communication. [00103] OPOs, tissue bank staff, and other authorized persons may also create and/or input (e.g., upload) information for the benefit of themselves or for the benefit of other individuals and entities who have access to the system, such as other OPOs, tissue bank staff, hospitals, and hospital staff. The information may be stored on a database residing at the server, OPO, access device, hospital, or other database. For instance, an OPO may insert notes or comments about a particular patient, such as information regarding a determination about a patient's suitability as a donor or health status. OPOs can also edit incorrect data and input missing data. The OPOs may also transfer data to other parties such as transplant teams. [00104] The embodiments of the present inventions are not to be limited in scope by the specific embodiments described herein. For example, although many of the embodiments disclosed herein have been described with reference to patient diagnostics, the principles herein are equally applicable to other criteria. Indeed, various modifications of the embodiments of the present inventions, in addition to those described herein, will be apparent to those of ordinary skill in the art from the foregoing description and accompanying drawings. Thus, such modifications are intended to fall within the scope of the following appended claims. Further, although the embodiments of the present inventions have been described herein in the context of a particular implementation in a particular environment for a particular purpose, those of ordinary skill in the art will recognize that its usefulness is not limited thereto and that the embodiments of the present inventions can be beneficially implemented in any number of environments for any number of purposes. Accordingly, the claims set forth below should be construed in view of the full breath and spirit of the embodiments of the present inventions as disclosed herein. [00105] Additional documents are attached hereto. The documents should not to limit or narrow the scope of the embodiments as described herein.

Claims

1. A method for selectively identifying potential organ and/or tissue donors comprising the steps of: analyzing patient information at one or more medical facilities or receiving pre- analyzed data or reports directly from such medical facilities; determining, based on the patient information, whether a potential organ and/or tissue donor is at the medical facility; and notifying an OPO or similar entity.

2. The method of claim 1, further comprising the step of providing the OPO with remote access to donor patient information for the purpose of evaluation and determination.

3. The method of claim 1 , further comprising the step of providing the organ or tissue recipient's transplant team with access to the donor's medical record and other information.

4. The method of claim 1, further comprising the step of providing an auditable historical medical record for donated organs and tissue.