US20090248744A1 - Transactional storage system for healthcare information - Google Patents
Transactional storage system for healthcare information Download PDFInfo
- Publication number
- US20090248744A1 US20090248744A1 US12/160,485 US16048506A US2009248744A1 US 20090248744 A1 US20090248744 A1 US 20090248744A1 US 16048506 A US16048506 A US 16048506A US 2009248744 A1 US2009248744 A1 US 2009248744A1
- Authority
- US
- United States
- Prior art keywords
- transaction
- state
- transactions
- representing
- representation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/1734—Details of monitoring file system events, e.g. by the use of hooks, filter drivers, logs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1873—Versioning file systems, temporal file systems, e.g. file system supporting different historic versions of files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/08—Insurance
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/20—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for electronic clinical trials or questionnaires
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/40—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for data related to laboratory analysis, e.g. patient specimen analysis
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
Abstract
Description
- This description relates to storing and retrieving healthcare product information.
- Healthcare information must be accessed by developers, researchers, health care professionals, vendors, managers, insurers, and regulators, among others. The people accessing the information may have a diverse set of needs and resources and be distributed over a large geographic area. Numerous data systems may be required to interact to maintain all the required information and deliver it to the correct places at the proper times.
- For managing healthcare information, current approaches include electronic data capture, large-scale databases of records, and automated systems to maintain and report the progress of the study. For compatibility between users and to comply with government requirements, such as for electronic reporting of clinical data to the FDA, extensible standards such as the Clinical Data Interchange Standards Consortium (CDISC) Operational Data Modeling (ODM) standard are used to store and model clinical data. These standards allow vendors to extend the capability of a standard model to include additional information or functionality of value to the vendor's customers. The FDA requires access to such files, and their auditing benefits from the traceability and retrieval that such standards enable.
- Projects in various healthcare areas have such data tracking & reporting requirements, including clinical studies, complaints about healthcare products, treatments, or drugs, managing patient records, etc. Problems may arise when different aspects of a project use incompatible data systems and information fails to be exchanged in an efficient manner, or at all, for example if a patient sees several specialists who all use different record-keeping systems. Patient records are collected by physicians and experts to keep track of the medical activity and status of a patient, and typically require the tracking of thousands of diverse pieces of information. Clinical trials to determine the safety and efficacy of new drugs, treatments or medical devices also typically require the tracking of such information, including not only patient records, but also experimental results, progress reports, and financial information. Complaints concerning healthcare products must be closely monitored and rapidly reported and addressed. Timeliness and completeness of a manufacturer's response to such complaints, and records about that response, is critical.
- As used in this application, the term “healthcare information” refers to the results or data produced by or associated with any analysis, research, or data collection aimed at evaluating, reporting or claiming information that impacts the health state of a person. “Clinical trial” refers to any study, research, trial, or investigation of the medical efficacy or safety of a medical substance or device. “Patient records” refers to the results or data produced by or associated with any analysis, research, or data collection aimed at the current or past state of a patient in regards to the medical treatments or procedure he has been subject to.
- In general, in one aspect, managing healthcare information data includes, on a computer, representing a state of a system based on the healthcare information, receiving a transaction representing a change to the system, changing the representation of the state of the system according to the transaction, and storing the transaction.
- Implementations may include one or more of the following features.
- Repeatedly, receiving a new transaction representing a new change to the system, changing the representation of the state of the system according to the new transaction, and storing the new transaction with previous transactions in a set of transactions. Representing the state of the system includes representing a system with an empty state, and repeatedly for each transaction in a set of transactions, changing the representation of the state of the system according to the transaction. Representing a state of the system corresponding to a point in time by representing a system with an empty state, and repeatedly for each transaction in a set of transactions corresponding to changes prior to the point in time, changing the representation of the state of the system according to the transaction.
- Representing a state of the system corresponding to a particular transaction by representing a system with an empty state, and repeatedly for each transaction in a set of transactions preceding and including the particular transaction, changing the representation of the state of the system according to the transaction. Representing a state of a subset of the system corresponding to a point in time by representing a system with an empty state, and repeatedly for each transaction in a set of transactions corresponding to changes to the subset of the system prior to the point in time, changing the representation of the state of the system according to the transaction.
- Representing the state of the system includes storing in a memory a hierarchy of elements, each element having one or more values, each value including data or a representation of one or more additional elements.
- On a second computer, representing a copy of the state of the system, and whenever a transaction is added to the set of transactions, changing the copy of the state of the system according to the transaction.
- The transaction includes a representation of the state of the system. The transaction includes a subset of elements including the representation of the state of the system, and a set of values corresponding to one or more elements in the subset of elements.
- Storing the transaction includes adding the transaction or a functional representation of the transaction to a sequence of transactions in a storage. a storage includes one or more of a disk, a flash memory, a network storage device, a virtual storage volume. Adding the transaction to a sequence of transactions includes adding the transaction to a queue of transactions, and moving transactions from the queue of transactions to a storage. Adding the transaction to a sequence of transactions includes sending the transaction to a representation of a storage. The transaction is sent to a representation of a storage in the same manner that data would be sent to a local storage.
- The healthcare information corresponds to one or more of a clinical study, an epidemiological study, information about a healthcare product, medical records, or insurance information. A transaction includes a binary file, and storing the transaction includes storing the binary file in a temporary location, assigning the binary file a unique identifier, adding the unique identifier to the transaction, storing the transaction in a storage, and storing the binary file in the storage.
- Aspects may include a method, a computer or computer system for carrying out the method, software for configuring a computer to carry out the method, and other embodiments.
- Advantages include improved traceability of healthcare information. For example, the historical progression of a clinical trial or its state at a specific point in time can be reconstructed to see if an event at that time should have been recognized as one that required a halt to a trial. Similarly, a history of product complaints can be reconstructed to determine the point in time where a company should have become aware of a defective product, or what circumstances can be identified in retrospect as indicating a defect, to improve future responses. As another example, by reconstructing the history of the clinical trial step by step or focusing on specific data at specific points in time, certain outcomes or other developments might also be more readily correlated with changes in protocol or in eligibility of patients for inclusion which were made during the course of a particular study.
- The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims.
-
FIG. 1 is an example of model data expressed in tabular form and a corresponding block diagram. -
FIG. 2 is an example of the model data and diagram ofFIG. 1 to which hierarchical relationships have been added. -
FIG. 3 is a flow diagram of illustrating a transaction starting with the model data table/diagram ofFIG. 2 and making changes specified in a second model data table/diagram resulting in a third model data table/diagram. -
FIG. 4 is a block diagram of the input of a transaction simultaneously into a data model and into a long-term storage. -
FIG. 5 is a block diagram of a controller handling the flow of a transaction to the components shown inFIG. 4 . -
FIG. 6 is a block diagram of a detailed embodiment of the long-term storage ofFIG. 5 . -
FIG. 7 is a block diagram of a computer system for carrying out the storage system ofFIG. 6 . -
FIG. 8 is a block diagram of a computer system for replicating the model component ofFIG. 5 . -
FIG. 9 is a block diagram of another embodiment of the long-term storage ofFIG. 5 . -
FIGS. 10A and 10B are block diagrams of a detail of steps in the operation of the model component ofFIG. 5 . -
FIG. 11 is a block diagram of an embodiment of one step of the process ofFIGS. 10A and 10B . - Like reference symbols in the various drawings indicate like elements.
- One way to manage a-diverse amount of healthcare information data is a data model. A data model consists of a set of elements and associated values. For example, the elements of a model may include clinical trial data such as protocol definitions, users, roles, experimental results, etc. Depending on the size and complexity of the study, the elements used in the data model to represent the components of the study may be very complex themselves, including files, databases, or even additional data models. The elements could be arranged in a flat structure, in a hierarchy, or in some other arrangement. Similar models can be used to manage patient records or complaints about healthcare products.
- There are numerous ways the data comprising the value of an element may be represented. For example, as shown in
FIG. 1 , values may be associated with elements in Java objects, illustrated in table form in table 102. An element that has a value associated with it is represented in an objectobject. In the Java object represented by table 102, element “Name” has value “Kika Medical”. Other elements and associated values represent an address. In the corresponding block diagram 104 of the same data, elements are represented byovals rectangles FIG. 2 , one element in an object may have as its value additional elements, which in turn may have values or contain still additional elements. For example, an object represented by table 202 corresponds to ahierarchical data model 204, in which the element “Company” 206 has as its value sub-elements “Name” 208 and “Address” 212. The sub-element “Name” has value “Kika Medical” 210 while the sub element “Address” hasadditional sub-elements appropriate values - A data model can be very complex, containing a large amount of information. As a clinical study advances or a patient receives ongoing medical care, the data model is continually updated so that it always represents the current status of all aspects of the subject matter. Whenever new information is available, it is added to the data model. If a user needs current information about some aspect of the modeled information, they use a client to access the model and find the current state of the relevant data. For example, when new information concerning a patient is available, a doctor will add those results to the model. If the doctor needs to see the patient's records, he uses a client to access the model and retrieve those records.
- In some examples, the data model is an extension of the Clinical Data Interchange Standards Consortium (CDISC) Operational Data Modeling (ODM) standard, which documents a hierarchical structure of clinical data elements. One part of each ODM file, known as the metadata, describes the data collected in a study. The metadata consists of definitions, with one type of definition for each of five data levels:
-
Data Level Definition Type 1 SubjectData Protocol 2 StudyEventData StudyEventDef 3 FormData FormDef 4 ItemGroupData ItemGroupDef 5 ItemData ItemDef - The first four levels are container levels while the last level is for actual data values. Container definitions are lists of references, which are pointers to other data definitions. For example, the metadata defining an ItemGroupData-level element Demographics may contain references to ItemDefs Birth_Date and Patient_Sex, indicating that the Demographics element contains two sub-elements at the ItemData level, and these sub-elements are defined according to the Birth_Date and Patient_Sex item definitions and will contain the corresponding data. The item definitions at the ItemData level describe the type of data stored in the defined element, such as text, integer, float, date, etc. In the preceding example, the item definition Birth_Date would indicate that the value must be of type “date.”
- The CDISC standard defines two important elements, Repeating and Mandatory. Repeating, applicable to definitions, indicates whether an element can be included more than once. For example, a StudyEvent-level element Adverse_Event, defined by a StudyEventDef definition, may be repeated several times in a study, so the definition of Adverse_Event would include the element Repeating with a value “true.” Mandatory is applicable to references and indicates whether a referenced sub-element is mandatory.
- Transactions
- The contents of a data model are changed by a transaction. A transaction may consist of instructions to add or remove elements, change the values of elements, or change the relationships between elements, such as their arrangement in a hierarchy. A single transaction may contain instructions to make multiple changes to the data model. For example, a transaction may instruct the data model to change the “Name” element of a particular person and add a “Telephone” element for that person. A transaction can be a data structure consisting of a subset of the elements of the data model it is intended to change. The values of the elements in the transaction could indicate explicit instructions, such as to add or delete an element. Alternatively, the values of the elements in the transaction could differ from the values already associated with the elements in the data model, such that the differences constitute instructions to change the values in the model accordingly.
- A transaction may be represented in the same format as the data model itself. In some examples, as shown in
FIG. 3 , a transaction is represented by a Java object as illustrated in table 302 and the data model is stored in memory is a comparable format. Block diagrams 204, 304, and 306 illustrate the transaction and data model abstractly. A transaction consists of a set of elements in the object of table 302 corresponding to theobject 202 representing the data model. The “Name” element 208-T has a different value 210-T than the corresponding element in the data model, so the transaction is regarded as an instruction to change the value of the “Name”element 208 in the data model. The “Address” element 212-T has a value consisting of the command “[delete]” 318, so the “Address”element 212 will be removed from the data model by deleting the corresponding element from the Java object. The “Telephone” element 310-T and its value 312-T are not found in the existing data model, so a new element and itsvalue 312 will be added to the Java object. These changes are applied to the data model represented by the Java object illustrated in table 202 to produce an updated Java object, illustrated in table 202′, with updated “Company” and “Name”elements 206′ and 208′, anew value 306′ for thename element 208′, and new “Telephone”element 310 havingvalue 312. - In some examples, a minimum set of elements and corresponding values must be included in every transaction. Such elements may include a global unique identifier (GUID) (assigned by a system that processes the transactions), the date of the transaction, the user ID of the author of the modification, a reason for the modification, the GUID of the previous transaction, and references to binaries, if any. A transaction may implicitly indicate when data is to be added or changed, simply by including the new data, or it may be required in a particular implementation to explicitly indicate for each element referenced whether data is being added, changed, or deleted.
- Implementation of the Model
- Two different components are used to store the data model in a complementary manner, as shown in
FIG. 4 . Theshort term storage 402 runs as an application on a computer system and maintains a representation of the current state of the data model. Themodel 404 consists of data in memory representing each element and its current value. By applying the instructions of each transaction to the data model currently in memory as the instructions are received, the representation of the model in the short term storage always represents the current state of the data model as of the most recent transaction, and can be quickly accessed to determine what that state is. When anew transaction 406 is received, theshort term storage 402 analyses the transaction to determine what changes are to be made to the data model, and it makes those changes to the representation of themodel 404 currently in memory. The short term storage may be limited for technical or other reasons. For example, if the data representing the current state of the data model is stored in volatile memory, that data will be lost if the computer hosting it is shut down. Storing the data in volatile memory may have advantages, such as allowing faster access to current information about the state of the data model to users or other processes that may require such information. The data representing the model could also be stored in a non-volatile memory, such as a hard disk or flash memory, with advantages and disadvantages corresponding to elements of the technology used. - The long
term storage component 410 also runs on a computer system, which may be the same system as the one running theshort term storage 402, or may be separate. It stores eachnew transaction 406 as it is received, without analyzing the transaction or applying it to the data model. Transactions are associated with a sequence value indicating the order in which they were received. A sequence oftransactions 406 a, b, etc. is referred to as a “series.” When it is desired to reconstruct the current state of the data model, for example, after the server hosting the short term storage has been rebooted, this is done by starting with an empty model, containing no elements or a default set of elements, and then loading a series of transactions from storage and applying them to the data model according to their sequence numbers to reproduce the process that led to the present state of the data model. Because conditions external to the data model may change between the time a transaction is stored and the time it is used to recreate a change to the data model, it is desirable that the data values in a transaction contain actual values, rather than references to external parameters. For example, if an element is to have a value representing the date on which it was stored, the corresponding value in the transaction needs to represent the actual date, i.e., “1 Jan. 2006,” not a pointer to that value in a computer system, for example, the system clock, which may change, even though such a pointer would have been sufficient on the day the transaction was stored. - To assure the consistency of the current state in the short term storage and the sequence of transactions to reproduce that state in the long term storage, each transaction is applied to the current state and stored in long term storage substantially in parallel. If a transaction is applied to the current state and not stored in the long term storage, and the current state is then reconstructed from the stored sequence of transactions, the reconstructed state will not match the previous current state. Likewise, if a transaction is stored but not applied by the short term storage, the current state in memory will not represent the actual state of the project.
- The storage of individual transactions and information about the order in which they were applied to the model provides several benefits. It effectively gives the model a time dimension, allowing a user to look back in time and reconstruct the model as it was at any point. This allows retrieval of the state of any part of the model at some point in time, and traceability of how the model evolved. For example, a researcher can see how the data describing a particular patient changed over time. In the example of a clinical study, a model can contain not only the data collected in the course of the study, but all information pertaining to the study, including test procedures, policies, forms, i.e., the entire protocol. The transaction storage system allows this information to also be reconstructed, for example to determine whether intake questions were changed after some patients had already started the trial. Without such traceability, costly and time-consuming computations may be required to discover such a fact.
- This traceability also allows statistical analysis of the entire population of a study at any historical point in time. The state of the model can be recreated, by replaying all the transactions up to that point, and then the model as of that point used as the source of data for analysis. If the analysis concerns only a subset of the population, or only a particular symptom, only the transactions affecting the relevant population or symptom need to be replayed, allowing for even faster reproduction and extraction of the needed data.
- Auditing is also improved by this model and transaction system. For example, in a clinical trial, the death of a patient requires that the trial stop. If it is learned that a death occurred and the trial continued, auditors can use the transaction history to rebuild the model as it stood at the time of the death to see what else was going on, who was aware of the situation, and why the trial was not halted. Such auditing using the traceability provided by the transaction history can also reveal fraud, misrepresentations, and defective data.
- Tools to Maintain and Use the Model
- As shown in
FIG. 5 , a controller module is another software application, and is configured to manage the flow of transactions from clients that access the data model. It may or may not operate on the same computer system as the other components. When atransaction 406 is received, acontroller 502 checks it against a set of rules to confirm that the changes it instructs to the data model are valid. The controller then provides the transaction to both theshort term storage 402 and thelong term storage 410 for appropriate handling. To insure reliability, the controller analyses the changes that will be made by the transaction and makes abackup copy 504 of thepart 506 of the data model, as represented in the current state, that is about to be modified by the transaction. The controller may be configured to backup a larger part of the data model than will clearly be affected by the changes, to assure that the backup is adequate. The transaction is then applied to the model by theshort term storage 402, generating a new revision and current state. The state may then be checked against a set of rules to assure that the revised data model continues to comply with them. If a rule is violated, the transaction is rejected and the backup is used to restore the data model to the state that existed before the revision. If no rule is violated, then thecontroller 502 instructs thelong term storage 410 to store the transaction. If for some reason the storage of the transaction is not successful, then the backup 504 is again used to restore the data model to its previous state. Even though no rules were violated by the changes, since they were not stored, the revised state will not be recreated when the sequence of transactions is again applied, so the current state should not reflect the new changes. - The controller also regulates access to the data model to prevent any inconsistencies. When a transaction is received, the controller applies a lock such that only a request handler handling the current transaction can modify the data model. This prevents other clients from submitting transactions to change the model at the same time. Once the transaction is stored, the lock is withdrawn. Likewise, when a client is reading the model, the controller may apply a read-only lock so that other clients may also read the model, but none will be able to change it while it is being read.
- Long Term Storage Component
- The long term storage component is made up of two layers: the dispatcher and storage for series of transactions, as shown in
FIG. 6 . The sequences of transactions comprising each series may be stored on a single server or on multiple servers, depending on the needs of the system. Servers storing the transactions may be integrated with the dispatcher or other components, or may be remote, or both. Thedispatcher 602 receivestransactions 406 that have been accepted by the controller and applied to the corresponding data model and adds them to the appropriate series.Several instances separate storage location dispatcher 602 monitors the state of each instance. If the storage fails to add a transaction to an instance of a series, the dispatcher identifies that instance as no longer available, since writing any additional transactions to it might break the integrity of the sequence represented by that series. - Instances of series may be synchronous or asynchronous. A
synchronous instance 608 writes each transaction to itscorresponding storage location 638 as it is received; with the dispatcher waiting for each write operation to complete before sending the next transaction.Asynchronous instances storage locations dispatcher 602 sends transactions to each queue as the transactions are ready, and the corresponding storage location takes them from the queue and writes them to the storedinstance - Queues may have a limited size, in which case, if a queue fills up, the dispatcher may have to stop sending transactions to the corresponding instance, possibly interrupting the sequence of transactions in that instance. When the dispatcher has stopped writing to an instance because its sequence of transactions has been interrupted, it may later be able to use a synchronizing tool to synchronize the series in that instance with another that was not interrupted so that the instance may be returned to service. The synchronizing tool reads from a valid instance the transactions that are missing from the interrupted series and inserts them into that instance of the series until it is up-to-date. This process could be automated by equipping the storage component with the ability to draw transactions from one instance and write them to other instances to assure that each stays up to date without the dispatcher having to monitor each instance's status.
- The details of how a sequence of transactions constituting a series is stored will vary according to the format of the transaction. In one example, a transaction is represented by an XML file, and a series comprises a set of such XML files. Each transaction file may contain a tag representing the sequence number of the transaction. Alternatively, a separate list of the order of transactions in a particular series may be maintained, using unique identifiers associated with each transaction. If a value of an element in the data model is to include a binary file, which is not ordinarily accommodated by the file type of the transaction, as is the case with XML, the transaction may include an identification of the binary file, with the binary file maintained in a separate file.
- In one example, as shown in
FIG. 7 , an instance 704 of a series is stored locally in a directory of the file system of theserver 702 hosting thedispatcher 602. The layout of the storage directory and the file system can be optimized for reliability and speed. Setup of such an arrangement may require only that the file system of the host computer have available resources. - In another example, also shown in
FIG. 7 ,instances servers network 720, for example, using HTTPS or other protocols. Commands may also be sent using a dedicated data connection between the local system hosting the dispatcher and the remote file system, using a virtual private network or other Internet connection, or in other ways. Using a remote file system allows that file system to differ from the file system used by the local computer. It may be advantageous to use an asynchronous instance on a remote file system due to latency of the network communications.Proxies 734, 736 forinstances local server 702, for example, so that thedispatcher 602 can access the stored instances as if they were local without being required to be configured according to the details of the file systems used on theremote servers - Additional Features
- In one example, shown in
FIG. 8 , anadditional server 804 maintains a duplicate of the current state of the data model, which is maintained inshort term storage 402 on aserver 802. Theadditional server 804 reads transactions stored in the longterm storage component 410 and applies each transaction to the locally-maintainedduplicate 810 of the data model. To make changes to the data model, aclient 806 must send a transaction to theprimary server 802. The client can retrieve information about the current state of the model from the short term storage as usual. Periodically, theadditional server 802 requests new transactions from thelong term storage 410 onserver 802. If any new transactions have been incorporated into the model since the last request, such transactions are transmitted to theserver 802 and incorporated into theduplicate model 810. Aclient 808 can access the duplicate model for purposes that only require read access, such as gathering statistics or reporting on the state of the data model.Data 832 is transmitted to theclient 808. Such an arrangement may reduce communication latency for clients that have a more direct connection to theadditional server 804 than to theprimary server 802. It may also reduce the load on the primary server, as fewer clients will require its resources. It may also improve the integrity of the data model, for example by allowing certain clients to only access the secondary server, such that they can never make changes to the model. - In one example, as shown in
FIG. 9 , if aclient 902 needs to add abinary file 904 to the data model, it uploads the binary file to theserver 906 hosting the controller (not shown). The server assigns aunique identifier 908 to the binary file, similar to identifiers assigned to transaction files, and sends acopy 910 of the file to thestorage locations 914 responsible for eachinstance 912 of the series that will contain the corresponding transaction. Thestorage locations 914 each place thebinary file 904 in atemporary storage location 916. The server then communicates theidentifier 908 of the binary file to the client. The client then sends atransaction 918 as an XML file, with one tag representing the binary file and containing the identifier of the file as its value. If the transaction is successfully added to the data model by the short term storage (not shown), it is sent to the long term storage (not shown) in the same manner as any other transaction. Eachstorage location 914 for an instance of the series that receives thetransaction 918 referencing thebinary file 904 looks for the binary file in its temporarybinary location 916 and moves it to apermanent location 920. If the file is not found, the transaction fails and is removed from the data model as with any other failed transaction. The insertion of the transaction into at least one instance of the series and the moving of the binary into the permanent storage of the corresponding storage component are handled as a single operation to assure consistency. If a single binary file is referenced by more than one transaction, only a single copy of the binary needs to be placed in permanent storage. When a transaction is received referencing such a binary file, the transaction is added to the series as normal with no additional steps required. - Since the stored sequence of transactions is used to recreate the current state of the data model each time the short term storage is loaded, it is easy to recover older versions of the model. For example, as shown in
FIG. 10A , the process of recreating the model can proceed as normal, starting with anempty model 1004, with transactions 1002 a-e resulting in revisions of themodel 1004 a-e. If aclient 1006 wants to know what was in the model at a specific time, for example thetime transaction 1002 c was entered, the reconstruction can be halted after that transaction is applied, and a copy of the corresponding revision of themodel 1004 c sent to the client. Similarly, as shown inFIG. 10B , if aclient 1010 is interested in only a subset of the data represented by the model corresponding to element B, the current state or any revision state of that data may be recreated without recreating the entire data model. This is accomplished by applying only thosetransactions model - If the data model is organized hierarchically, handling of elements in transactions may be more complex. For example, as shown in
FIG. 11 , in a hierarchical arrangement, elements may be categorized as ancestor or child nodes, e.g., nodes A and E, respectively, and a given node could be of both types simultaneously, e.g., node C, which is a child of node A and an ancestor of nodeE. A transaction 1102 must contain elements corresponding to each ancestor of any child nodes it modifies. For example, if child nodes D and F are added, all of their ancestors, A and C, must be present in the transaction and marked either to be inserted themselves or to be updated to recognize the child. If a child node E is modified, all of its ancestors are marked to also be modified. If a child node G is deleted, all of its ancestors, nodes A and B are marked either to be deleted or to be updated. All the changes intransaction 1102 are applied to the present revision of themodel 1104 to produce a revisedversion 1104′. - Elements pertaining to the hierarchy are included in each node to facilitate model reconstruction and history recovery. In one example, these elements include the GUID of the last transaction that inserted or updated any children of the node and the date that transaction was executed. With these elements, the system can rapidly discover which is the last transaction that modified a data node and from that, find who made the modification and whether other nodes were modified at the same time. For example, if a node corresponds to a particular patient, a user may want to know who was the last researcher to update that patient's information, and which other patients' information did that researcher alter at the same time. The node for that patient, which will be a parent node for nodes representing information about the patient, will contain the GUID of the last transaction that modified that patient node or any of its children nodes. That transaction can be retrieved based on its GUID, and the researcher who initiated it identified.
- A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. For example, a last-current copy of the model may be maintained in long-term storage to facilitate rebuilding the active model. Accordingly, other embodiments are within the scope of the following claims.
Claims (23)
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/IB2006/003156 WO2008010012A2 (en) | 2006-07-17 | 2006-07-17 | Transactional storage system for healthcare information |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IB2006/003156 A-371-Of-International WO2008010012A2 (en) | 2006-07-17 | 2006-07-17 | Transactional storage system for healthcare information |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/081,062 Continuation US9747416B2 (en) | 2006-07-17 | 2011-04-06 | Transactional storage system for healthcare information |
Publications (1)
Publication Number | Publication Date |
---|---|
US20090248744A1 true US20090248744A1 (en) | 2009-10-01 |
Family
ID=37562116
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/160,485 Abandoned US20090248744A1 (en) | 2006-07-17 | 2006-01-27 | Transactional storage system for healthcare information |
US13/081,062 Active 2027-06-18 US9747416B2 (en) | 2006-07-17 | 2011-04-06 | Transactional storage system for healthcare information |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/081,062 Active 2027-06-18 US9747416B2 (en) | 2006-07-17 | 2011-04-06 | Transactional storage system for healthcare information |
Country Status (2)
Country | Link |
---|---|
US (2) | US20090248744A1 (en) |
WO (1) | WO2008010012A2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080097901A1 (en) * | 2006-10-16 | 2008-04-24 | Siemens Medical Solutions Usa, Inc. | Transaction Monitoring System |
Families Citing this family (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090248744A1 (en) | 2006-07-17 | 2009-10-01 | Kika Medical | Transactional storage system for healthcare information |
US10089443B2 (en) | 2012-05-15 | 2018-10-02 | Baxter International Inc. | Home medical device systems and methods for therapy prescription and tracking, servicing and inventory |
US10242159B2 (en) | 2010-01-22 | 2019-03-26 | Deka Products Limited Partnership | System and apparatus for electronic patient care |
US11164672B2 (en) | 2010-01-22 | 2021-11-02 | Deka Products Limited Partnership | System and apparatus for electronic patient care |
US11881307B2 (en) | 2012-05-24 | 2024-01-23 | Deka Products Limited Partnership | System, method, and apparatus for electronic patient care |
US10911515B2 (en) | 2012-05-24 | 2021-02-02 | Deka Products Limited Partnership | System, method, and apparatus for electronic patient care |
US11244745B2 (en) | 2010-01-22 | 2022-02-08 | Deka Products Limited Partnership | Computer-implemented method, system, and apparatus for electronic patient care |
US11210611B2 (en) | 2011-12-21 | 2021-12-28 | Deka Products Limited Partnership | System, method, and apparatus for electronic patient care |
US20110313789A1 (en) | 2010-01-22 | 2011-12-22 | Deka Products Limited Partnership | Electronic patient monitoring system |
US10453157B2 (en) | 2010-01-22 | 2019-10-22 | Deka Products Limited Partnership | System, method, and apparatus for electronic patient care |
CA2814657A1 (en) | 2010-10-12 | 2012-04-19 | Kevin J. Tanis | Medical device |
JP5630863B2 (en) * | 2010-11-26 | 2014-11-26 | インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation | Method, apparatus, and computer program for determining and visualizing total order relation of nodes included in structured document based on log information |
US9737649B2 (en) | 2013-03-14 | 2017-08-22 | Smith & Nephew, Inc. | Systems and methods for applying reduced pressure therapy |
AU2015411394B2 (en) | 2015-10-07 | 2021-07-08 | Smith & Nephew, Inc. | Systems and methods for applying reduced pressure therapy |
CA3023932A1 (en) | 2016-05-13 | 2017-11-16 | Smith & Nephew, Inc. | Automatic wound coupling detection in negative pressure wound therapy systems |
US11369730B2 (en) | 2016-09-29 | 2022-06-28 | Smith & Nephew, Inc. | Construction and protection of components in negative pressure wound therapy systems |
WO2019014141A1 (en) | 2017-07-10 | 2019-01-17 | Smith & Nephew, Inc. | Systems and methods for directly interacting with communications module of wound therapy apparatus |
GB201820668D0 (en) | 2018-12-19 | 2019-01-30 | Smith & Nephew Inc | Systems and methods for delivering prescribed wound therapy |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5956489A (en) * | 1995-06-07 | 1999-09-21 | Microsoft Corporation | Transaction replication system and method for supporting replicated transaction-based services |
US5991772A (en) * | 1997-10-31 | 1999-11-23 | Oracle Corporation | Method and apparatus for restoring a portion of a database |
US20020029290A1 (en) * | 2000-08-08 | 2002-03-07 | Herman Burema | System and method for tracking affiliates and merchants |
US20040267809A1 (en) * | 2003-06-23 | 2004-12-30 | Microsoft Corporation | Resynchronization of multiple copies of a database after a divergence in transaction history |
US20050102670A1 (en) * | 2003-10-21 | 2005-05-12 | Bretl Robert F. | Shared object memory with object management for multiple virtual machines |
US20050120039A1 (en) * | 2002-09-19 | 2005-06-02 | Upstream Software, Inc. | System, method and software for acquiring, storing and retrieving electronic transactions |
US7082446B1 (en) * | 2002-04-15 | 2006-07-25 | Steel Eye Technology, Inc. | Hybrid transaction/intent log for data replication |
US7099897B2 (en) * | 2003-02-26 | 2006-08-29 | International Business Machines Corporation | System and method for discriminatory replaying of log files during tablespace recovery in a database management system |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020069192A1 (en) * | 2000-12-04 | 2002-06-06 | Aegerter William Charles | Modular distributed mobile data applications |
US20020143764A1 (en) * | 2001-04-03 | 2002-10-03 | Martin Andrew R. | Data management system and method for intercepting and changing database instructions between a database back end and an application front end |
US6745303B2 (en) * | 2002-01-03 | 2004-06-01 | Hitachi, Ltd. | Data synchronization of multiple remote storage |
EP1387269A1 (en) * | 2002-08-02 | 2004-02-04 | Hewlett Packard Company, a Delaware Corporation | Backup system and method of generating a checkpoint for a database |
US7036044B1 (en) * | 2002-11-15 | 2006-04-25 | Microsoft Corporation | Identifying appropriate undo during a forward pass through a log |
US8156083B2 (en) * | 2005-12-01 | 2012-04-10 | Oracle International Corporation | Database system that provides for history-enabled tables |
US7761426B2 (en) * | 2005-12-07 | 2010-07-20 | International Business Machines Corporation | Apparatus, system, and method for continuously protecting data |
US7555502B2 (en) * | 2006-03-10 | 2009-06-30 | Oracle International Corporation | Detecting database events using recovery logs |
US20090248744A1 (en) | 2006-07-17 | 2009-10-01 | Kika Medical | Transactional storage system for healthcare information |
-
2006
- 2006-01-27 US US12/160,485 patent/US20090248744A1/en not_active Abandoned
- 2006-07-17 WO PCT/IB2006/003156 patent/WO2008010012A2/en active Application Filing
-
2011
- 2011-04-06 US US13/081,062 patent/US9747416B2/en active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5956489A (en) * | 1995-06-07 | 1999-09-21 | Microsoft Corporation | Transaction replication system and method for supporting replicated transaction-based services |
US5991772A (en) * | 1997-10-31 | 1999-11-23 | Oracle Corporation | Method and apparatus for restoring a portion of a database |
US20020029290A1 (en) * | 2000-08-08 | 2002-03-07 | Herman Burema | System and method for tracking affiliates and merchants |
US7082446B1 (en) * | 2002-04-15 | 2006-07-25 | Steel Eye Technology, Inc. | Hybrid transaction/intent log for data replication |
US20050120039A1 (en) * | 2002-09-19 | 2005-06-02 | Upstream Software, Inc. | System, method and software for acquiring, storing and retrieving electronic transactions |
US7099897B2 (en) * | 2003-02-26 | 2006-08-29 | International Business Machines Corporation | System and method for discriminatory replaying of log files during tablespace recovery in a database management system |
US20040267809A1 (en) * | 2003-06-23 | 2004-12-30 | Microsoft Corporation | Resynchronization of multiple copies of a database after a divergence in transaction history |
US20050102670A1 (en) * | 2003-10-21 | 2005-05-12 | Bretl Robert F. | Shared object memory with object management for multiple virtual machines |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080097901A1 (en) * | 2006-10-16 | 2008-04-24 | Siemens Medical Solutions Usa, Inc. | Transaction Monitoring System |
US8352538B2 (en) * | 2006-10-16 | 2013-01-08 | Siemens Medical Solutions Usa, Inc. | Transaction monitoring system |
Also Published As
Publication number | Publication date |
---|---|
WO2008010012A2 (en) | 2008-01-24 |
US20110276605A1 (en) | 2011-11-10 |
WO2008010012A8 (en) | 2009-08-27 |
US9747416B2 (en) | 2017-08-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9747416B2 (en) | Transactional storage system for healthcare information | |
George | HBase: the definitive guide: random access to your planet-size data | |
Kimball et al. | The data warehouse ETL toolkit | |
US7213022B2 (en) | Enterprise content management network-attached system | |
CN104981802B (en) | For the content type of object memories directory system | |
CN101828182B (en) | ETL-less zero redundancy system and method for reporting OLTP data | |
US7310653B2 (en) | Method, system, and product for maintaining software objects during database upgrade | |
EP1347394B1 (en) | Schema-oriented content management system | |
US8244555B2 (en) | Rule model for healthcare information | |
US20040098425A1 (en) | Database System Providing Improved Methods For Data Replication | |
CN107835983A (en) | Backup-and-restore is carried out in distributed data base using consistent database snapshot | |
De Jong et al. | Zero-downtime SQL database schema evolution for continuous deployment | |
US20150302007A1 (en) | System and Methods for Migrating Data | |
Brahmia et al. | Schema versioning in conventional and emerging databases | |
EP1197876A2 (en) | Persistent data storage techniques | |
Liu et al. | Picture archiving and communication systems and electronic medical records for the healthcare enterprise | |
US9223639B2 (en) | In place object reconstruction | |
Klein | An Introduction to IMS: Your Complete Guide to IBM Information Management System | |
Janée | Preserving Geospatial Data: The National Geospatial Digital Archive's Approach | |
Tomášek | Design and implementation of Archival Storage component of OAIS Reference Model | |
Arunachalam et al. | Healthcare Data Warehousing | |
Darmawan et al. | Database Performance Tuning on AIX | |
Warner | Libraries, archives, and digital preservation: a critical overview | |
Fortino | Reengineering of a Big Data architecture for real-time ingestion and data analysis | |
Lakhe et al. | Lambda architecture for real-time Hadoop applications |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: KIKA MEDICAL, FRANCE Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MASSON, ARNAUD;DEMOUSTIER, ROMAIN;REEL/FRAME:021772/0855 Effective date: 20081006 |
|
AS | Assignment |
Owner name: KIKA MEDICAL, FRANCE Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DEMOUSTIER, ROMAN;REEL/FRAME:021809/0121 Effective date: 20081006 |
|
AS | Assignment |
Owner name: KIKA MEDICAL, FRANCE Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE NAME OF INVENTOR PREVIOUSLY RECORDED ON REEL 021809 FRAME 0121;ASSIGNOR:DEMOUSTIER, ROMAIN;REEL/FRAME:021822/0172 Effective date: 20081006 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: MERGE ECLINICAL, INC., WISCONSIN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KIKA MEDICAL INC.;REEL/FRAME:048978/0166 Effective date: 20101231 |
|
AS | Assignment |
Owner name: MERGE HEALTHCARE INCORPORATED, ILLINOIS Free format text: AFFIDAVIT CONCERNING CHANGE OF PATENT OWNERSHIP;ASSIGNOR:MERGE ECLINICAL INC.;REEL/FRAME:049706/0420 Effective date: 20190619 |
|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW YORK Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MERGE HEALTHCARE INCORPORATED;REEL/FRAME:055661/0386 Effective date: 20210319 |
|
AS | Assignment |
Owner name: MERATIVE US L.P., MICHIGAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:061496/0752 Effective date: 20220630 |