Patent Document

CROSS-REFERENCE TO RELATED APPLICATION  
       [0001]    This application claims priority to U.S. Provisional Application Serial No. 60/376,632, entitled “System and Method for Managing and Reconciling Asynchronous Patient Data,” filed Apr. 30, 2002 (attorney docket no. 29794/38270), the disclosure of which is hereby expressly incorporated herein by reference. 
     
    
     
       TECHNICAL FIELD  
         [0002]    This patent relates generally to healthcare information systems, and more particularly, to a system for managing patient data in asynchronous environments and a method for reconciling asynchronous patient data with patient data housed in a patient data repository.  
         BACKGROUND  
         [0003]    The management of patient data in asynchronous environments presents a significant challenge for software development. An asynchronous environment, taken within the context of a healthcare information system, may take at least two common forms. In a first form, a healthcare information system may permit asynchronous conditions that take the form of temporary, unresolved patient health records. These records may be created and stored by client applications running on a number of device types, including but not limited to handheld devices, laptop devices, and workstations.  
           [0004]    Client applications may create and store these temporary, unresolved patient records when a user requires access to a given patient health record at a time when that record is not available to the client application via a live, real-time connection to a patient health record repository and is also not available locally. In this case, the entire temporary patient record is subject to resolution when the client application is once again able to communicate directly with the patient health record repository.  
           [0005]    In a second form, a healthcare information system may permit asynchronous conditions that take the form of patient health records that contain data values that require resolution with the patient health record repository. These records may be modified or edited by client applications running on a number of device types, including but not limited to handheld devices, laptop devices, and workstations.  
           [0006]    Client applications would modify and store these patient records when a user requires access to a given patient health record that is available locally to the client application but not via a live, real-time connection to the patient health record repository. In this case, the entire temporary patient record does not require resolution. Instead, when the client application is once again able to communicate directly with the patient health record repository, the data items that have been modified are subject to resolution.  
           [0007]    Operating in an asynchronous environment implies that a given patient record or piece of patient data may not be represented on or available to the client application in real time. The asynchronous conditions may have arisen because of a lost or interrupted connection between the client application and the patient health record repository, because the client application could not establish the appropriate connection so that it could access the appropriate patient data, or because the client application is configured in such a way that it does not depend on a real-time connection to the patient health record repository to function appropriately. An asynchronous environment necessitates one of two responses: the end-user is either prevented from working with a given patient because a real-time connection to the patient health record repository does not exist, or the end-user is allowed to perform certain tasks with an unresolved version of the given patient record or a temporary, unresolved patient record, which will then be subject to later resolution with the data in the patient health record repository when a connection becomes available.  
         SUMMARY  
         [0008]    The present patent overcomes the disadvantages of the prior art by providing a system for the collection of temporary patient data using applications operating in an asynchronous environment and a method for reconciling asynchronous patient data stored by the applications with patient data stored in a patient health record repository. The system includes a mechanism for capturing patient data in temporary, unresolved patient records and a method that defines the manner in which these temporary, unresolved patient records are reconciled with the patient data stored in the patient health record repository.  
           [0009]    In another aspect of the patent, a system is provided for the collection of patient data in temporary unresolved patient records for operation in asynchronous environments, either by allowing for the creation of unresolved patient data based on a locally available version of the desired patient record (item-level), or by creating a new, temporary, unresolved patient record (record-level).  
           [0010]    In yet another aspect of the patent, a method is disclosed for resolving one or more temporary patient records with the patient health record repository that combines duplicate checking functionality, an architecture of rules and rule relationships for solving data conflicts, and a resolution work queue that allows users to perform both record-level and item-level resolutions.  
           [0011]    In another aspect of the patent, a client application running on a handheld device may be configured to communicate with the patient health record repository either via a real-time, wireless connection or via an intermittently-used wired connection, such as a cradle device or docking device. This client application could operate in an asynchronous environment if the real-time, wireless connection was temporarily lost, as well as when the handheld device is not physically connected to the patient health record repository via the intermittently-used wired connection.  
           [0012]    Such a client application could allow users to create temporary, unresolved patient records to represent patient data that is not available locally when the real-time connection to the patient health record repository does not exist. In addition, such a client application could allow users to modify data within patient health records that are available locally when the real-time connection to the patient health record repository does not exist. When the connection between the client application and the patient health record repository becomes available, either as a real-time wireless connection or via an intermittently-used wired connection such as a cradle device or docking device, both the temporary unresolved patient records and the patient records with modified data items may be subject to resolution.  
           [0013]    Another aspect of the patent allows a client application running on a laptop device to be configured to communicate with the patient health record repository either via a real-time, wireless connection or via an intermittently-used wired connection, such as a docking device or a network port. This client application would operate in an asynchronous environment if the real-time wireless connection was temporarily lost, as well as when the laptop device was not physically connected to the patient health record repository via the intermittently-used wired connection.  
           [0014]    Such a client application could allow users to create temporary, unresolved patient records to represent patient data that is not available locally when the real-time connection to the patient health record repository does not exist. In addition, such a client application could allow users to modify data within patient health records that are available locally when the real-time connection to the patient health record repository does not exist. When the connection between the client application and the patient health record repository becomes available, either as a real-time wireless connection or via an intermittently-used wireless connection such as a docking device or a network port, both the temporary unresolved patient records and the patient records with modified data items may be subject to resolution.  
           [0015]    In another aspect of the patent, a client application running on a workstation that is normally in constant, real-time communication with the patient health record repository via a network port (or some other analogous connection) may also be configured to function in an asynchronous environment. This client application could operate in an asynchronous environment if the real-time connection with the patient health record repository was temporarily lost or interrupted (due to network conditions, server loads, etc.).  
           [0016]    Such a client application could allow users to create temporary, unresolved patient records to represent patient data that is not available locally when the real-time connection to the patient health record repository is lost or interrupted. In addition, such a client application could allow users to modify data within patient health records that are available locally when the real-time connection to the patient health record repository is lost or interrupted. When the connection between the client application and the patient health record repository is restored, both the temporary unresolved patient records and the patient records with modified data items may be subject to resolution.  
           [0017]    In short, the present patent describes a system for managing patient data in asynchronous environments and a method for reconciling asynchronous patient data with patient data housed in a central patient data repository. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0018]    [0018]FIG. 1 is a block diagram of a general purpose data network.  
         [0019]    [0019]FIG. 2 is a schematic diagram of an embodiment of a network computer.  
         [0020]    [0020]FIG. 3 is a schematic diagram of several system components located in a healthcare facility.  
         [0021]    [0021]FIG. 4 is a block diagram of an overview of a healthcare information system operating in synchronous mode.  
         [0022]    [0022]FIG. 5 is a block diagram of an exemplary mobile handheld dictation system.  
         [0023]    [0023]FIG. 6 is a flowchart illustrating some of the steps used in the collection of unresolved patient data.  
         [0024]    [0024]FIG. 7 is a flowchart representing some of the steps used for item-level resolution.  
         [0025]    [0025]FIG. 8 is a flowchart representing some of the steps that may be used for record-level resolution. 
     
    
     DETAILED DESCRIPTION  
       [0026]    [0026]FIG. 1 illustrates an embodiment of an enterprise-wide data network  10  including a first group of healthcare facilities  20  operatively coupled to a network computer (i.e. machine)  30  via a network  32 . The plurality of healthcare facilities  20  may be located, by way of example rather than limitation, in separate geographic locations from each other, in different areas of the same city, or in different states. The network  32  may be provided using a wide variety of techniques well known to those skilled in the art for the transfer of electronic data. For example, the network  32  may comprise dedicated access lines, plain ordinary telephone lines, satellite links, combinations of these, etc. Additionally, the network  32  may include a plurality of network computers or server computers (not shown), each of which may be operatively interconnected in a known manner. Where the network  32  comprises the Internet, data communication may take place over the network  32  via an Internet communication protocol.  
         [0027]    The network computer  30  may be a server computer of the type commonly employed in networking solutions. The network computer  30  may be used to accumulate, analyze, and download data relating to a healthcare facility&#39;s medical records. For example, the network computer  30  may periodically receive data from each of the healthcare facilities  20  indicative of information pertaining to a patient&#39;s medical record, billing information, employee data, etc. The healthcare facilities  20  may include one or more facility servers  36  that may be utilized to store information for a plurality of patients/employees/accounts/etc. associated with each facility.  
         [0028]    Although the enterprise-wide data network  10  is shown to include one network computer  30  and three healthcare facilities  20 , it should be understood that different numbers of computers and healthcare facilities may be utilized. For example, the network  32  may include a plurality of network computers  30  and dozens of healthcare facilities  20 , all of which may be interconnected via the network  32 . According to the disclosed example, this configuration may provide several advantages, such as, for example, enabling near real time uploads and downloads of information as well as periodic uploads and downloads of information. This provides for a primary backup of all the information generated in the process of updating and accumulating healthcare data.  
         [0029]    [0029]FIG. 2 is a schematic diagram of one possible embodiment of the network computer (i.e. machine)  30  shown in FIG. 1. The network computer  30  may have a controller  50  that is operatively connected to a patient health record repository  52  (such as a Universal Patient Record repository) via a link  56 . The patient health record repository  52  may include one or more databases or data repositories that store patient healthcare data and related healthcare business data using one or more database management systems that run on one or more computing platforms on one or more computing devices. It should be noted that, while not shown, any additional databases or repositories may be linked to the controller  50  in a similar manner.  
         [0030]    The controller may include a program memory  60 , a microcontroller or a microprocessor (MP)  62 , a random-access memory (RAM)  64 , and an input/output (I/O) circuit  66 , all of which may be interconnected via an address/data bus  70 . It should be appreciated that although only one microprocessor  62  is shown, the controller  50  may include multiple microprocessors  62 . Similarly, the memory of the controller  50  may include multiple RAMs  64  and multiple program memories  60 . Although the I/O circuit  66  is shown as a single block, it should be appreciated that the I/O circuit  66  may include a number of different types of I/O circuits. The RAM(s)  64  and programs memories  60  may be implemented as semiconductor memories, magnetically readable memories, and/or optically readable memories, for example. The controller  50  may also be operatively connected to the network  32  via a link  72 .  
         [0031]    [0031]FIG. 3 is a schematic diagram of one possible embodiment of several components located in one or more of the healthcare facilities  20  from FIG. 1. Although the following description addresses the design of the healthcare facilities  20 , it should be understood that the design of one or more of the healthcare facilities  20  may be different than the design of other healthcare facilities  20 . Also, each healthcare facility  20  may have various different structures and methods of operation. It should also be understood that the embodiment shown in FIG. 3 illustrates some of the components and data connections present in a healthcare facility, however it does not illustrate all of the data connections present in a typical healthcare facility. For exemplary purposes, one design of a healthcare facility is described below, but it should be understood that numerous other designs may be utilized.  
         [0032]    The healthcare facilities  20  may have a facility server  36 , which includes a controller  80 , wherein the facility server  36  is operatively connected to a plurality of client device terminals  82  via a network  84 . The network  84  may be a wide area network (WAN), a local area network (LAN), or any other type of network readily known to those persons skilled in the art. The client device terminals  82  may also be operatively connected to the network computer  30  from FIG. 1 via the network  32 . The client device terminals  82  as well as the facility server  36  may be referred to as machines for the purposes of this patent.  
         [0033]    Similar to the controller  50  from FIG. 2, the controller  80  may include a program memory  86 , a microcontroller or a microprocessor (MP)  88 , a random-access memory (RAM)  90 , and an input/output (I/O) circuit  92 , all of which may be interconnected via an address/data bus  94 . As discussed with reference to the controller  50 , it should be appreciated that although only one microprocessor  88  is shown, the controller  80  may include multiple microprocessors  88 . Similarly, the memory of the controller  80  may include multiple RAMs  90  and multiple programs memories  86 . Although the I/O circuit  92  is shown as a single block, the I/O circuit  92  may include a number of different types of I/O circuits. The RAM(s)  90  and programs memories  86  may also be implemented as semiconductor memories, magnetically readable memories, and/or optically readable memories, for example. All of these memories or data repositories may be referred to as machine-accessible mediums.  
         [0034]    The client device terminals  82  may include a display  96 , a controller  97 , a keyboard  98  as well as a variety of other input/output devices (not shown) such as a printer, mouse, touch screen, track pad, track ball, isopoint, voice recognition system, etc. Each client device terminal  82  may be signed onto and occupied by a healthcare employee to assist them in performing their duties. Healthcare employees may sign onto a client device terminal  82  using any generically available technique, such as entering a user name and password. If a healthcare employee is required to sign onto a client device terminal  82 , this information may be passed via the link  84  to the facility server  36 , so that the controller  80  will be able to identify which healthcare employees are signed onto the system and which client device terminals  82  the employees are signed onto. This may be useful in monitoring the healthcare employees&#39; productivity.  
         [0035]    Typically, facility servers  36  store a plurality of files, programs, and other data for use by the client device terminals  82  and the network computer  30 . One facility server  36  may handle requests for data from a large number of client device terminals  82 . Accordingly, each facility server  36  may typically comprise a high end computer with a large storage capacity, one or more fast microprocessors, and one or more high speed network connections. Conversely, relative to a typical facility server  36 , each client device terminal  82  may typically include less storage capacity, a single microprocessor, and a single network connection.  
         [0036]    [0036]FIG. 4 is a block diagram of a health care information system operating in a synchronous mode. Such a system may include the patient health record repository  52 , as well as client applications running on a handheld device  82 A, a workstation  82 B, and a laptop computer  82 C. These client applications communicate with the patient health record repository  52  via a web server  36 A (if the client application is a web browser  82 D). The client applications may also communicate with the patient health record repository  52  via one or more gateway servers (if the client application is running on the wireless handheld device  82 A with a real-time, wireless connection), such as a gateway server  36 B. Connection to the patient health record repository  52  may also be made using wired communications devices  110  (used intermittently to connect handheld devices and laptop devices to the system), and wireless communications devices  112  (used to facilitate real-time, wireless connections between handheld devices and handheld devices with other system components).  
         [0037]    Client applications running on workstations and laptop computers may also communicate directly with the patient health record repository  52  via standard, wired network connections and protocols. Such a system is said to operate in a synchronous mode because each of these connections is continually available, thus allowing a client application immediate access to a given patient health record and includes the ability to lock patient health records so that only a single user or process can edit the record&#39;s data at a given time.  
       Overall Operation of the System  
       [0038]    One manner in which an exemplary system may operate is described below in connection with a block diagram overview and a number of flow charts which represent a number of portions or routines of one or more computer programs. These computer program portions may be stored in one or more of the memories in the controllers  50  and  80 , and may be written at any high level language such as C, C++, or the like, or any low-level, assembly or machine language. By storing the computer program portions therein, various portions of the memories are physically and/or structurally configured in accordance with the computer program instructions.  
         [0039]    [0039]FIG. 5 is a block diagram overview of an exemplary health care information system operating in an asynchronous mode. The embodiment of FIG. 5 is similar to the embodiment shown in FIG. 4 and includes many of the same structures and components. For clarity, the structures and components remaining the same are shown with like reference numbers as those from FIG. 4. An asynchronous environment includes a system configuration characterized by the lack of a continuous, real-time connection between a client application and the patient health record repository  52 , while allowing users to manipulate patient data and healthcare business data even when a real-time connection does not currently exist.  
         [0040]    Referring to FIG. 5, the system may include the patient health record repository  52 , as well as client applications running on the handheld device  82 A, a workstation  82 B, and a laptop computer  82 C. Persons skilled in the art will appreciate that while only one computing device of each type  82 A,  82 B, and  82 C is shown, a plurality of the devices  82 A,  82 B, and  82 C, as well as other types of computing devices could be used. The client applications may communicate with the patient health record repository  52  via a web server  36 A (if the client application is a web browser  82 D). The client applications may also communicate with the patient health record repository  52  via one or more gateway servers (if the client application is running on the wireless handheld device  82 A with a real-time, wireless connection), such as a gateway server  36 B. Those skilled in the art will appreciate that the enterprise may include other types of servers as well, such as, for example, application servers and database servers. Connection to the patient health record repository  52  may also be made using wired communications devices  120  (used intermittently to connect handheld devices and laptop devices to the system), and wireless communications devices  122  (used to facilitate real-time, wireless connections between handheld devices and handheld devices with other system components).  
         [0041]    Client applications running on workstations and laptop computers may also communicate directly with the patient health record repository  52  via standard, wired network connections and protocols. Such a system is said to operate in an asynchronous mode because of the aforementioned connections between the client applications and the patient health record repository  52  may not exist continually. This situation, in combination with the client application&#39;s ability to create temporary, unresolved patient records locally and to edit patient records that are already locally available, allows for multiple versions of the same patient health record to exist temporally and geographically.  
         [0042]    The network connections described above may take place over a computer network that includes industry standard network hardware (routers, switches, connectors, etc.) and software (network and communication protocols) that serve to allow communication between the patient health record repository  52 , the end-user client applications running on various device types, and the various types of servers. This network may take the form of a cable-based or fiber optic network, a wireless local area network (LAN), a wireless wide area network (WAN), a virtual private network (VPN), the Internet, or any other type of wired or wireless network that allows communication between computing devices.  
         [0043]    [0043]FIG. 6 is a flowchart  150  illustrating some of the steps in a client application for collecting of unresolved patient data. When the client application is operating in an asynchronous mode, it may be configured to allow for the collection of unresolved patient data (block  152 ). If configured to allow for the collection of unresolved patient data, the user can then attempt to gain access to a given patient health record (block  154 ). If the patient health record, or the applicable portion of the record, is available locally, the client application may open a local version of the patient record (block  156 ), and make it, or some portion of it, available for editing (block  160 ).  
         [0044]    If the record in question, or the applicable portion of the record, is not available locally, the client application may create a temporary, unresolved patient health record (block  162 ), and make it, or some portion of it, available for editing (block  160 ). In addition, the client application may mark the record as unresolved, so that when the client application can communicate with the patient health record repository in real time, the record can be submitted for resolution.  
         [0045]    If the record being marked as unresolved was available locally, it may be marked for item-level resolution. If the record is a new, temporary, unresolved patient record, it may be marked for record-level resolution. After the user edits or modifies the patient health record in question (block  164 ), or at least a portion of the patient health record in question, the client application may save the record locally (block  166 ). When the client application can once again communicate with the patient health record repository in real time (block  170 ), each of the records marked for resolution are submitted to the patient health record repository for resolution (block  172 ).  
         [0046]    [0046]FIG. 7 is a flow chart  200  illustrating some of the steps that may be used for item-level resolution. When a patient health record marked for item-level resolution is submitted for resolution (block  202 ), the unresolved patient record may be matched with the corresponding source record (block  204 ) and the unresolved-data may be evaluated to determine if data conflicts exist between the source record and the unresolved record (block  206 ). If no conflicts exist, the source record may be updated and the unresolved record discarded.  
         [0047]    Data conflicts may be checked at a block  210 . If data conflicts do exist, each point of data conflict may be examined in light of one or more conflict resolution rules (block  212 ). If it is determined at a block  214  that the application of one or more conflict resolution rules solves all of the data conflicts, the conflicts may be considered resolved (block  216 ) and the source record updated accordingly (block  220 ). If all the data conflicts cannot be solved by the application of one or more conflict resolution rules, the unresolved patient health record may be submitted to a resolution work queue for later examination (block  222 ), where it may remain until a user evaluates the remaining data conflicts (block  224 ), and determines a solution for these conflicts. Once the user has determined a solution for each data conflict in a given record (block  226 ), the conflicts may be considered resolved (block  216 ) and the source record updated accordingly (block  220 ). After the source record is updated, the unresolved version of the record may be discarded.  
         [0048]    [0048]FIG. 8 is a flow chart  250  representing some of the steps that may be used for record-level resolution. When a patient health record marked for record-level resolution is submitted for resolution (block  252 ), the temporary, unresolved patient record may be submitted to a duplicate checker to determine whether the unresolved record can be automatically matched to its corresponding source record, according to one or more criteria (block  254 ). If it is determined at a block  256  that no potential duplicates are found, the system may create a new record in the patient health record repository (block  258 ) and transfer the data from the temporary, unresolved record to this new, source record and discard the unresolved record (block  260 ). If there are potential matches provided by the duplicate checker (block  262 ), the system may determine whether the matches between any potential duplicate and the temporary, unresolved record exceed a pre-defined threshold that indicates a satisfactory match (block  264 ).  
         [0049]    If a satisfactory match does not exist, the unresolved record may be submitted to a resolution work queue for later examination (block  266 ), where it may remain until a user evaluates the potential matches produced by the duplicate checking process (block  270 ). If the user is able to satisfactorily associate a source record with the unresolved record, the records may be evaluated to determine whether data conflicts exist between the source record and the unresolved record (block  272 ). If it is determined at a block  274  that no data conflicts exist, the source record may be updated accordingly and the unresolved record discarded (block  260 ).  
         [0050]    If data conflicts do exist, each point of data conflict may be examined in the light of one or more conflict resolution rules (block  276 ). If it is determined at a block  280  that the application of one or more conflict resolution rules solves all of these data conflicts, the conflicts may be considered resolved (block  282 ) and the source record updated accordingly (block  260 ). If it is determined at a block  280  that all the data conflicts cannot be solved by the application of one or more conflict resolution rules, the unresolved patient health record may remain in the resolution work queue (block  284 ) until a user evaluates the remaining data conflicts (block  286 ). Once the user has determined a solution for each data conflict in a given record (block  290 ), the conflicts may be considered resolved (block  282 ) and the source record may be updated accordingly (block  260 ). After the source record is updated, the unresolved version of the record may be discarded.  
         [0051]    Returning to the block  264 , if it is determined that a satisfactory match exists, the records may be evaluated to determine whether data conflicts exist between the source record and the unresolved record (block  272 ). If no data conflicts exist, the source record may be updated accordingly and the unresolved record may be discarded (block  260 ). If data conflicts do exist, each point of data conflict may be examined in the light of one or more conflict resolution rules (block  276 ). If the application of one or more conflict resolution rules solves all of the data conflicts, the conflicts may be considered-resolved (block  282 ) and the source record may be updated accordingly (block  260 ).  
         [0052]    If all the data conflicts cannot be solved by the application of one or more conflict resolution rules, the unresolved patient health record may be submitted to a resolution work queue for later examination (block  284 ), where it may remain until a user evaluates the remaining data conflicts (block  286 ). Once the user has determined a solution for each data conflict in a given record (block  290 ), the conflicts may be considered resolved (block  282 ) and the source record may be updated accordingly (block  260 ). After the source record is updated, the unresolved version of the record may be discarded.  
         [0053]    Although the technique for reconciling asynchronous patient data described herein, is preferably implemented in software, it may be implemented in hardware, firmware, etc., and may be implemented by any other processor associated with a healthcare enterprise. Thus, the routine(s) described herein may be implemented in a standard multi-purpose CPU or on specifically designed hardware or firmware as desired. When implemented in software, the software routine(s) may be stored in any computer readable memory such as on a magnetic disk, a laser disk, or other storage medium, in a RAM or ROM of a computer or processor, etc. Likewise, the software may be delivered to a user or process control system via any known or desired delivery method including, for example, on a computer readable disk or other transportable computer storage mechanism or over a communication channel such as a telephone line, the Internet, etc. (which are viewed as being the same as or interchangeable with providing such software via transportable storage medium).  
         [0054]    While the present invention has been described with reference to specific examples, which are intended to be illustrative only and not to be limiting of the invention, it will be apparent to those of ordinary skill in the art that changes, additions or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the invention.

Technology Category: g