Method, apparatus, and computer-readable medium for generating an audit trail of electronic data records

Abstract

The present invention discloses a method, device and computer-readable medium for generating an audit trail of a record, comprising: receiving a request to generate an audit trail of the record, the request including a record identifier and a date value of the record; identifying a commit data structure corresponding to the record based on the record identifier, each commit data structure corresponding to a set of changes previously applied to a field of the record and including a timestamp value, a list of changes made to the field and a previous commit pointer to a previous commit data structure; identifying a commit data structure related to the request based at least in part on the timestamp value and the date value of at least one commit data structure; and generating the audit trail of the record based on a list of changes to each commit data structure in the identified commit data structures.

Description

[0001] Related application data

[0002] This patent application claims priority to U.S. Provisional Application No. 62 / 892,863, filed on August 28, 2019, the disclosure of which is hereby incorporated by reference in its entirety. Background Art

[0003] Compliance with Part 11 of the U.S. Food and Drug Administration (FDA) (21 CFR Part 11) and Annex XII of the European Union (EU) (EudraLex) Regulation (Volume 4, Good Manufacturing Practice (GlvIP), Medicinal Products for Human and Veterinary Use) requires ensuring the integrity of electronic records and auditing all changes made to electronic records. These regulatory bodies generally share several specific requirements. These requirements can include, for example, automated audit trail entries; ensuring that audit trail entries are secure and cannot be edited; ensuring that audit trail entries contain accurate change timestamps; ensuring that audit trail entries contain change details, including the person who performed the change, the previous and subsequent values, and an explanation of the reason for the change; and the availability of audit trails throughout the record's retention period.

[0004] Conventional audit trail technologies utilize various forms of application and database controls to meet these requirements by entering audit trail entries into the corresponding database. For example, a typical audit trail in a database might appear as a single row, where auditing is controlled by a database trigger or application construct. The audit trail is configured to store a delta for each specific change and the details of that change.

[0005] However, conventional techniques suffer from several problems and drawbacks. These drawbacks include: (i) difficulty in implementation because conventional database solutions allow a single person to access the database to change records; (ii) the need for larger storage spaces given the volume of data and number of changes stored in the audit trail, as the data is essentially replicated across multiple rows; (iii) potential manipulation of the audit trail through defects or by a single bad actor, or corruption of the audit trail through database manipulation when the audit trail is physically decoupled from the recording system; (iv) the inability to obtain an "as of" version of the record, making it difficult for auditors to review the record; and (v) the use of additional auditing techniques for audit records to prove that the database administrator has not changed the record. Conventionally, the requirement for immutability is difficult to enforce because conventional database solutions allow a single person to access the database to change the record.

[0006] Therefore, there is a need for improved audit trail generation techniques to overcome these shortcomings present in conventional techniques while reducing memory usage and ensuring that the integrity of electronic records is maintained. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 A data structure diagram illustrating specialized data structures used in the present system and method for generating an audit trail of electronic data records according to an exemplary embodiment.

[0008] Figure 2 Shown is a diagram of a method for utilizing a Figure 1 Representation of an example of a specialized data structure corresponding to an electronic data record of a graph database.

[0009] Figure 3 A flow chart for generating an audit trail for electronic data records is shown according to an exemplary embodiment.

[0010] Figure 4A A flow chart is shown for identifying a plurality of submission data structures corresponding to electronic data records based at least in part on record identifiers according to an exemplary embodiment.

[0011] Figure 4B The use of the exemplary embodiment is shown Figure 4A The method shown in identifies an example of a plurality of submitted data structures corresponding to an electronic data record.

[0012] Figure 5A Another flow chart for identifying a plurality of submitted data structures corresponding to electronic data records based at least in part on record identifiers is shown according to an exemplary embodiment.

[0013] Figure 5B The use of the exemplary embodiment is shown Figure 5A The method shown in identifies an example of a plurality of submitted data structures corresponding to an electronic data record.

[0014] Figure 6A A flow chart is shown for identifying one or more submission data structures from a plurality of submission data structures related to a request based at least in part on a timestamp value and a date value of each submission data structure, according to an exemplary embodiment.

[0015] Figure 6B An example of this process is shown for three submission data structures according to an exemplary embodiment.

[0016] Figure 7A A flow chart is shown for generating an audit trail of electronic records based at least in part on a list of one or more changes in each of the identified one or more submitted data structures that have been selected for inclusion in the audit trail, according to an exemplary embodiment.

[0017] Figure 7B According to an exemplary embodiment, Figure 7A An example of an iterative traversal process is shown in the flowchart of FIG.

[0018] Figure 8 A flow chart is shown for generating an audit trail of electronic data records based at least in part on a list of one or more changes in each of the identified one or more submitted data structures that have been selected for inclusion in the audit trail, according to an exemplary embodiment.

[0019] Figure 9 According to an exemplary embodiment, Figure 8 An example of the audit trail generation process.

[0020] Figure 10 An exemplary implementation of a process for generating an audit trail (log) in a Java environment according to an exemplary embodiment is shown.

[0021] Figure 11 A flow chart for submitting a new set of changes is shown according to an exemplary embodiment.

[0022] Figures 12A-12B An exemplary implementation of a process for committing a new set of changes in a Java environment is shown, according to an exemplary embodiment.

[0023] Figure 13 A flow chart for requesting a recorded snapshot is shown according to an exemplary embodiment.

[0024] Figure 14 An exemplary implementation of a process for generating a snapshot in a Java environment according to an exemplary embodiment is shown.

[0025] Figure 15 A dedicated computing environment for generating an audit trail of electronic data records is shown according to an exemplary embodiment. DETAILED DESCRIPTION

[0026] Although methods, devices and computer-readable media are described herein by way of examples and embodiments, those skilled in the art recognize that the methods, devices and computer-readable media for generating audit trails of electronic data records are not limited to the embodiments or drawings described. It should be understood that the drawings and descriptions are not intended to be limited to the specific forms disclosed herein. On the contrary, it is intended to cover all modifications, equivalents and alternatives that fall within the spirit and scope of the appended claims. Any headings used herein are for organizational purposes only and are not meant to limit the scope of the specification or claims. As used herein, the word "may" is used in a permissive sense (i.e., meaning it is possible) rather than a mandatory sense (i.e., meaning it must). Similarly, the word "include / including / includes" means including but not limited to.

[0027] Applicants have discovered a new method, apparatus, and computer-readable medium for generating an audit trail of electronic data records that utilize new data structures and techniques.

[0028] The present system utilizes a snapshot-based version control system for electronic records that allows the audit trail and record system to become a single logical entity. As discussed in further detail below, this is achieved by implementing record version control by using each version of each record as a self-contained repository. Thus, the present inventive concept provides solutions to problems faced in conventional techniques for maintaining electronic records, including conserving physical drive space, maintaining data integrity verification and / or validation, and enabling targeted searching and retrieval of electronic records and audit trails associated with them.

[0029] Because the disclosed system unifies the system of records and audit trails, there are several significant advantages to the inventive concepts disclosed herein. Some of these advantages include, for example, (i) high resistance to any type of tampering; (ii) high efficiency in the use of memory space, which may include physical drive space; and (iii) more user-friendly consumption of data or electronic records. With respect to high resistance to any type of tampering, the inventive concepts disclosed herein make it virtually impossible for a single bad actor to tamper with, alter, or change electronic records.

[0030] With respect to achieving high efficiency in using memory space, the system may utilize a graph database to store records and relationships, thereby minimizing data storage because electronic records are not duplicated in the audit trail because the recording system and the audit component are the same physical entity.

[0031] Additionally, the system includes "as of" view functionality (which allows users to retrieve audit trails as of a specific date) as well as the ability to perform real-time comparisons of records across multiple versions and clone records for reporting purposes or error correction.

[0032] The system disclosed herein implements authentication through a collection of concatenated hashes, which can be implemented using any Secure Hash Algorithm (SHA), such as SHA-1, SHA-2, and SHA-256 hashes, which allows the system to authenticate itself from any single participant.

[0033] The system prevents a single actor (e.g., a database administrator) from tampering with or modifying data without detection. This is achieved through a sequential hashing scheme that relies on the content of the electronic data record and the application code associated with the submission and used to execute, access, modify, or submit changes to the electronic data record.

[0034] The system also protects audits from modification through computational algorithms (e.g., including but not limited to SHA-1) that are typically impossible to manually process through large amounts of electronic records. By using both the change and all previous changes and creating a unique, irreversible signature, the system makes undetectable modification of the system extremely difficult and nearly impossible for a single person to accomplish.

[0035] Furthermore, by complying with CFR Part 11, which requires that all data and records be in electronic format, the system disclosed herein is capable of maintaining millions of records electronically with minimal memory space usage. The system disclosed herein that stores information in a non-human readable format can generate a complete list of changes to documents in real time and on demand, or alternatively generate a list of changes at a later point in time based on a provided date.

[0036] A detailed description of the disclosed method, apparatus, and computer-readable medium is now provided. The disclosed system advantageously ensures the integrity of electronic records by modifying them using a computational algorithm (e.g., a secure hash algorithm) to identify changes and prior changes to the records and create a unique, irreversible signature. This makes undetectable modifications to the system extremely difficult and nearly impossible for a single person, participant, or entity to perform or make.

[0037] Figure 1 A data structure diagram illustrating a dedicated data structure used in the present system and a method for generating an audit trail for an electronic data record according to an exemplary embodiment. The data structure diagram corresponds to a data structure for storing the required information to generate an audit trail for an electronic data record (also referred to herein as a "record").

[0038] like Figure 1As shown, the dedicated data structures include a snapshot data structure 101 (also referred to as a "snapshot" in this document), an index data structure 102 (also referred to as an "index" in this document), a commit data structure 103 (also referred to as a "commit" in this document), and a field data structure 104 (also referred to as a "field" in this document).

[0039] As used herein, an electronic data record includes any type of electronic record having one or more fields and associated values ​​for the one or more fields. In the present system, each version of each field of an electronic data record is stored as a self-contained repository in a field data structure 104 ("field"). Field 104 includes an identifier ("id"), a field type ("type"), a name ("name"), and a stored value ("content") for that particular field data structure, which is shown as being stored in a byte array, but can be stored in any suitable format. To conserve memory space, values ​​can be stored in a compressed byte array so that less physical drive space is used.

[0040] The field data structure 104 also includes a hash value of the value stored in the "content" byte array. This is used for authentication purposes and to detect tampering with the field 104. The field 104 additionally includes a reference to a previous version of the field data structure 104 (which is itself a different field 104 object) in the form of a "priorVersion" field pointer to an earlier field data structure.

[0041] Snapshot data structures 101 provide a view of an electronic data record at any given point in time. Each snapshot data structure 101 has an identifier ("id") and corresponds to an electronic data record identified by a record identifier ("recordid"). Each snapshot 101 also includes a reference to the last change made to the electronic data record in the form of a "lastCommit" pointer to a commit data structure (discussed below).

[0042] Snapshot 101 also includes a history of all changes made to the corresponding electronic data record in the form of a plurality of commit pointers to a plurality of commit data structures (indicated as the variable "history," which itself is a list of pointers to commit data structures). The snapshot also includes a pointer to an index data structure 102 for the electronic data record, which is discussed below.

[0043] An index data structure 102 ("index") corresponds to the current state and value of an electronic data record. The index 102 includes an identifier ("id") and a hash value ("sha1") that is generated by hashing a commit data structure associated with the electronic data record. The index 102 may also include a "currentState" map. The currentState map contains a record identifier ("recordid" in the snapshot, of type "String") as a key, and a corresponding field data structure ("Field") as a value. The currentState map can be used as part of a differential resolution algorithm, rather than the schema itself when a commit is introduced, with the index responsible for identifying which objects have changed. To do this efficiently, the currentState map can be utilized.

[0044] The index 102 is used to track the current versions of all fields in the electronic record, as indicated by the "currentVersions" variable, which is a list of field pointers to the current version of each field (i.e., field data structure) in the electronic data record. The index may additionally include a "noVal" string, which is a placeholder to track whether the field is new. This can be any string value that is not a valid SHA1 hash. Additionally, when implemented in a Java environment, the index (102) may include a java logger ("logger") that is used to log messages during execution.

[0045] The commit data structure 103 includes an identifier ("id") and corresponds to an electronic data record, and more specifically, to a set of changes previously applied to one or more fields of the electronic data record.

[0046] Commit 103 includes a hash value of the current state as of the commit ("sha1") and a second hash value of the current state as of the previous commit ("prevSha1"). The hash value is generated at least in part based on one or more fields of the electronic data record modified by the commit corresponding to the commit data structure (i.e., the fields data structure corresponding to the commit). Additionally, the previous hash value corresponds to the previous hash value of the previous commit data structure pointed to by the previous commit pointer ("priorCommit"). Both hash values ​​can be further generated at least in part based on a salt value derived from the application code associated with the commit (e.g., the application that executes, calls, or implements the commit). This ensures that a party with access to the application code or the electronic record database cannot modify any part of the record without compromising integrity. Concatenating the hashes (storage of the hash in the commit and the previous hash) means that any change to the electronic record causes each hash to be recalculated for each forward commit in order for the record to pass validation checks. Because the integrity of the commit has downstream effects on each individual commit, any change or modification can be traced back to the individual data point that was modified.

[0047] The submission data structure 103 may further include the name of the entity, program, process, or person who performed the submission (the "pass" string). The submission 103 also includes a timestamp of the date of submission. This date may be in any format, such as UNIX time or month, day, and year format.

[0048] Changes to the electronic data record saved by a particular submission 103 are represented as a list of field pointers to field objects ("changes," which is a list of field pointers). Since a new field object is created for each change to a field, storage of these changes in the submission data structure 103 is accomplished by linking to each generated field object for a particular submission.

[0049] As described above, commit data structure 103 additionally includes a prior commit pointer ("priorCommit") that points to the previous commit data structure for the electronic data record. As will be further described below, this pointer is used to traverse commits when generating an audit trail (also referred to herein as a "log"). In addition, commit 103 may include a snapshot pointer ("lastCommitSnap") that, if the commit is the most recent commit for a particular electronic data record, will contain a pointer to the snapshot. This value aids in processing graph queries by providing the ability to rewind a commit record from a snapshot of the record. Maintaining a relationship to the most recent commit allows this process to be performed efficiently.

[0050] In an exemplary embodiment, Figure 1The specialized data structures described in and the pointers therebetween can be stored in a graph database, where each data structure corresponds to a node in the graph database, and each pointer corresponds to a directed edge (relationship) between the nodes. In this case, each commit data structure, each snapshot data structure, each index data structure, and each field data structure is stored as a node in the graph database, and each index pointer, commit pointer, field pointer, and snapshot pointer is stored as a directed edge between nodes in the graph database. The graph database is configured for high-speed traversal of relationships between different nodes, which can improve system performance.

[0051] Figure 2 Shown is a diagram of a method for utilizing a Figure 1 An example of a graph database corresponding to a specialized data structure of an electronic data record. Figure 2 As shown in key 201 of , graph database 200 includes different types of nodes corresponding to field data structures, submission data structures, snapshot data structures, and index data structures. For example, node 203 is a field node, node 202 is a submission node, node 204 is a snapshot node, and node 205 is an index node.

[0052] The graph database 200 also stores pointers between data structures as edges or relationships between nodes. Specifically, each pointer is represented as a directed edge from a parent entity to a child entity. For example, an edge 206 between two commit nodes corresponds to a pointer from commit node 202 to the other commit node. This can correspond to a pointer to a parent entity. Figure 1 Discuss the priorCommit pointer.

[0053] like Figure 2 As shown, a commit node can have outgoing edges to field nodes, indicating that a particular field was modified by a particular commit. Each version of each field in an electronic data record is represented as a different field node. In addition, each commit node can be connected to an earlier commit node. Thus, the relationship between each node and its corresponding previous node indicates the modifications and changes that have been made to the fields of the electronic data record. As will be discussed further below, these features enable the dynamic generation of an audit trail from the record itself by traversing the appropriate nodes in the order corresponding to the audit request. This eliminates the need to store audit information separately and enables customized audit scope for any field in any electronic data record in the system. Furthermore, the immutability requirement is enforced through a hashing process using a hash salt, as previously discussed. By utilizing the current state of the system to calculate the commit hash and also utilizing the previous hash corresponding to an earlier state, the present system makes undetectable modification of an electronic data record or audit trail extremely difficult and virtually impossible for a single person or entity to accomplish.

[0054] Although a graph database is described herein as an exemplary storage system, the present invention may be implemented using alternative storage systems and databases rather than a graph database. Figure 1 The system is implemented using the data structures described herein (e.g., pointers and connection lists). For clarity, several examples in this application utilize a graph database to illustrate and represent the specific processes and functions performed by the system. It should be understood that these processes and functions can be implemented on other types of storage devices without affecting the many advantages of the system.

[0055] Figure 3 A flow chart for generating an audit trail for an electronic data record according to an exemplary embodiment is shown. At step 301, a request to generate an audit trail for an electronic data record is received, the request including a record identifier for the electronic data record and a date value. The date value may indicate an "as of" date (i.e., an end date) for the audit, such that only changes before that date are retrieved and presented in the audit trail. The date value may also indicate a start date, such that only changes after the start date are retrieved and presented in the audit trail. The date value may also include a date range, the date range including a start date and an end date, such that only changes after the start date and before the end date are retrieved and presented in the audit trail. Many variations are possible, and the following examples are not intended to be limiting.

[0056] At step 302, a plurality of commit data structures corresponding to an electronic data record are identified based at least in part on a record identifier. As previously discussed, each commit data structure corresponds to a set of changes previously applied to one or more fields of the electronic data record and includes a timestamp value, a list of one or more changes made to the one or more fields of the electronic data record, and a previous commit pointer to a previous commit data structure corresponding to the previous set of changes applied to the one or more fields of the electronic data record. The list of one or more changes in each commit data structure may be represented as a list of one or more field pointers to one or more field structures, as described with reference to FIG. Figure 1 In addition, as will be referenced Figure 4A-4B and Figure 5A-5B As explained, the step of identifying a plurality of submitted data structures corresponding to the electronic data record may be performed in a variety of ways.

[0057] Figure 4A A flow chart is shown for identifying a plurality of submission data structures corresponding to electronic data records based at least in part on record identifiers according to an exemplary embodiment. Figure 4A The process shown in utilizes the submission history stored in each snapshot to identify the submission data structure corresponding to a particular electronic data record.

[0058] At step 401, a snapshot data structure corresponding to an electronic data record is identified based at least in part on a record identifier. The snapshot data structure includes a plurality of commit pointers to a plurality of commit data structures. As described above, the plurality of commit data structures correspond to the commit history of the record. This step may perform a lookup operation using the record identifier to locate the snapshot, as each electronic data record has only a single corresponding snapshot. At step 402, the plurality of commit data structures are identified by traversing the plurality of commit pointers.

[0059] Figure 4B The use of the exemplary embodiment is shown Figure 4A The method shown in identifies an example of a plurality of submitted data structures corresponding to an electronic data record. Figure 4B The process on a graphical database is shown, but it should be understood that other implementations are possible. Figure 4B As shown, snapshot node 403 shares directed edges to commit nodes 404, 405, and 406, which are all previous commits executed. Thus, the process of identifying multiple commit data structures is performed by traversing the outgoing edges from snapshot node 403 to reach each of commit nodes 404-406.

[0060] Figure 5A Another flow chart for identifying a plurality of submitted data structures corresponding to electronic data records based at least in part on record identifiers is shown in accordance with an exemplary embodiment. Figure 5A As shown, the step of identifying a plurality of submission data structures corresponding to the electronic data record may also be performed by traversing pointers from the snapshot to the most recent submission and then traversing pointers from each submission to the previous submission.

[0061] At step 501, a snapshot data structure corresponding to an electronic data record is identified based at least in part on a record identifier. The snapshot data structure includes a most recent commit pointer pointing to a most recent commit data structure. The most recent commit data structure corresponds to the most recent set of changes to the electronic record. At step 502, the most recent commit data structure is identified by traversing the most recent commit pointers. At step 503, multiple commit data structures corresponding to the electronic data record are identified by traversing multiple previous commit pointers in the multiple commit data structures, starting from the most recent commit data structure. This is an iterative process, where each previous commit pointer for each commit is used to reach the next previous commit.

[0062] Figure 5B The use of the exemplary embodiment is shown Figure 5A The method shown in identifies an example of a plurality of submitted data structures corresponding to an electronic data record. Figure 5BThe process on a graphical database is shown, but it should be understood that other implementations are possible. Figure 5B As shown, snapshot node 504 has a directed edge to the most recent commit node 505 (corresponding to the most recent commit pointer). Most recent commit node 505 has a directed edge to previous commit node 506 (corresponding to the previous commit pointer). Previous commit node 506 has a directed edge to an even earlier commit node 507 (corresponding to the previous commit pointer). Thus, the process of identifying multiple commit data structures is performed by traversing the outgoing edges from snapshot node 504 to commit node 505, the edge from commit node 505 to commit node 506, and the edge from commit node 506 to commit node 507. This process can continue until the previous commit pointer reaches a null value (i.e., there are no more previous commits).

[0063] Return to Figure 3 At step 303, one or more submission data structures from the plurality of submission data structures that are related to the request are identified based, at least in part, on the timestamp value and date value of at least one submission data structure. This step selects submission data structures for generating the audit trail and filters out submissions (or changes) to the electronic data record that occur before or after the date value, or outside the date range. It is not always necessary to check the timestamps of all submission data structures. For example, if it is determined that a submission data structure is before the start date, all previous submission data structures can be eliminated without checking their timestamps. Similarly, if it is determined that a submission data structure is after the end date, all subsequent submission data structures can be eliminated without checking their timestamps.

[0064] Figure 6A A flow chart is shown for identifying one or more submission data structures from a plurality of submission data structures related to a request based at least in part on a timestamp value and a date value of each submission data structure, according to an exemplary embodiment. Figure 6A The process shown in Figure 3 The method is performed based on at least one of the plurality of submission data structures identified in step 302 and is directed to identifying all submissions before an end date. At step 601, a timestamp of the at least one submission data structure is compared to a date value. At step 602, the at least one submission data structure is identified as being related to the request based at least in part on determining that the date of the timestamp is less than the date value.

[0065] Figure 6B An example of this process for three submission data structures according to an exemplary embodiment is shown. Figure 6BAs shown, the timestamp of commit node 603 does not precede the date value, so it is not included in the set of commits for which an audit trail will be generated. In contrast, the timestamp of commit node 604 precedes the date value, so it is included. The timestamp of commit node 605 does not need to be checked, and it is included because commit node 605 precedes commit node 604 (i.e., the previous commit pointer of node 604 points to node 605), and commit node 604 has already been included.

[0066] return Figure 3 At step 304, an audit trail for the electronic data record is generated based at least in part on the list of one or more changes made to each of the identified one or more submission data structures. As previously discussed, the list of one or more changes made to one or more fields of the electronic data record can be a list of one or more field pointers to one or more field data structures, each field data structure corresponding to a field of the electronic data record. Additionally, as discussed with reference to Figure 1 As explained, each field data structure may include a content value indicating the contents of the field (e.g., a byte array) as a result of a submission corresponding to the submission data structure and a previous version field pointer pointing to a previous version field data structure corresponding to the field of the electronic data record prior to the submission.

[0067] Figure 7A A flow chart is shown for generating an audit trail of electronic records based at least in part on a list of one or more changes in each of the identified one or more submitted data structures that have been selected for inclusion in the audit trail, according to an exemplary embodiment. Figure 7A The process shown in is part of the overall audit trail generation step and involves traversal of the submission data structure / nodes.

[0068] At step 701, a most recent submitted data structure among the identified one or more submitted data structures is identified. The most recent submitted data structure can be identified based on a timestamp based on a position within the graph database (or in an array, list, index, or connected list). The most recent submitted data structure can also be designated as the first submitted data structure traversed, as the traversal proceeds backward in time.

[0069] At step 702, each of the one or more submission data structures is iterated through starting at the most recent submission data structure by traversing the previous submission pointer of each submission data structure. This step traverses each submission data structure and processes each submission data structure (e.g., Figure 8 described) to generate an audit trail.

[0070] Figure 7BAccording to an exemplary embodiment, Figure 7A An example of an iterative traversal process is shown in the flowchart of Figure 7B As shown, the traversal starts from snapshot node 703 and proceeds to commit node 704, the timestamp of which is greater than the date value. Therefore, commit node 704 is excluded from the one or more commit nodes identified as included in the audit trail. Subsequently, the traversal proceeds to commit node 705, the timestamp of which is less than the date value, and is therefore designated as the most recent commit node (the commit node meets the date value condition / standard). Subsequently, the traversal proceeds to commit node 706 and commit node 707.

[0071] Now about Figure 8 Describes the process used to generate an audit trail from each selected / identified commit node. Figure 8 A flow chart is shown for generating an audit trail of electronic data records based at least in part on a list of one or more changes in each of the identified one or more submitted data structures that have been selected for inclusion in the audit trail, according to an exemplary embodiment. Figure 8 The process shown in is also part of the overall audit trail generation step and involves the processing of the traversed submission data structure to generate the audit trail (log).

[0072] Figure 8 The steps shown in are performed for each submission data structure traversed (and included in the submission node identified as included in the audit trail / associated with the request). At step 801, each field pointer in a list of one or more field pointers is traversed to identify one or more field data structures corresponding to the submission data structure. At step 802, the content value of each field data structure in the one or more field data structures is determined. At step 803, the previous version field pointer of each field data structure in the one or more field data structures is traversed to identify one or more previous version field data structures. At step 804, the previous version content value of each previous version field data structure in the one or more previous version field data structures is determined. At step 805, a log record corresponding to the submission data structure is created, the log record including a timestamp value of the submission data structure, a previous version content value of each previous version field data structure in the one or more previous version field data structures, and a content value of each field data structure in the one or more field data structures.

[0073] Figure 9 According to an exemplary embodiment, Figure 8An example of an audit trail generation process. As shown in graphical database 901, commit node 901A is traversed first. The timestamp of commit node 901A is added to the first row of audit trail 902 ("8 / 26 / 2020"). Commit node 901A has a field pointer pointing to field node 901B, so this edge is traversed to reach field node 901B. Field node 901B provides the field name ("desktop widget") and the current value of the field ("37") at the time of the commit corresponding to commit node 901A. Subsequently, the previous version pointer from field node 901B is traversed to reach field node 901C. Subsequently, field node 901C provides the previous value of the field in the first row of audit trail 902 ("34").

[0074] The first commit node 901A is completed, and the previous commit pointer is traversed to reach commit node 901D. The timestamp of commit node 901D is added to the second line of audit trail 902 ("8 / 22 / 2020"). Commit node 901D has a field pointer pointing to field node 901B, so this edge is traversed to reach field node 901C. Field node 901C provides the field name ("Desktop Widget") and the current value of the field ("34") at the time of the submission corresponding to commit node 901D to the second line of audit trail 902. Subsequently, the previous version pointer from field node 901C is traversed to reach field node 901E. Subsequently, field node 901E provides the previous value of the field in the second line of audit trail 902 ("31").

[0075] Of course, if a commit node were to change the values ​​of two or more fields, additional field nodes would be traversed from that commit node, resulting in multiple field name entries in the audit trail (or multiple audit trails corresponding to different fields). For purposes of clarity and explanation, Figure 9 The example only shows changes to a single field.

[0076] Figure 10 An exemplary implementation of a process for generating an audit trail (log) in a Java environment according to an exemplary embodiment is shown. Figure 10 As shown, this embodiment utilizes a log generator and inflates (decompresses) the values ​​stored in each field data structure.

[0077] Figure 11A flow chart for submitting a new set of changes according to an exemplary embodiment is shown. The submit function may take as input a map comprising key-value pairs, where the key is the name of the field and the value is the value corresponding to the field. The submit function may also take as input a string corresponding to the person submitting the change, a string corresponding to the reason for the change, and a string corresponding to the recordId of the record to be updated, and may return a string corresponding to the submission identifier:

[0078] String Commit(Map<String,Serializable> record, String who, String reason, String recordId).

[0079] like Figure 11 As shown, at step 1101, a determination is made as to whether an electronic data record exists. If no electronic data record exists, a new snapshot is created at step 1102. However, if a record exists, the snapshot is retrieved by record ID at step 1103. Next, at step 1104, a secure hash algorithm, such as a SHA-1 hash, is generated for each field-value pair in the provided mapping. A comparison is then performed. Specifically, at step 1105, a determination is made as to whether the current index matches each SHA hash. If there is an exact match and no changes have been made, the commit ID is returned at step 1106. However, if no match is found for the SHA hash, the field-value pair is marked as modified at step 1107. At step 1108, for each modified field, a new field data structure 1104 is prepared / generated using the field key, SHA hash, the previous version of the field, and a compressed byte array of the value.

[0080] At step 1109, a new commit 103 is prepared / generated with the list of committed changes. At step 1110, the index is updated with the new current version of each field. At step 1111, a SHA hash of each SHA of each field in the index is generated. At step 1112, if a SHA for the snapshot exists, the most recent commit is hashed with that SHA, and this new SHA is placed in the record at step 1113. At step 1114, the snapshot is updated with the most recent commit, and if a previous commit exists, it is added to the history, and the snapshot is stored in the database. At step 1114, the new commit hash is returned along with the temporarily generated system. Figures 12A-12B An exemplary implementation of a process for committing a new set of changes in a Java environment is shown, according to an exemplary embodiment.

[0081] Figure 13A flow chart for requesting a snapshot of a record according to an exemplary embodiment is shown. The function for requesting a snapshot takes as input a string corresponding to a record identifier and a date corresponding to the date of the desired snapshot of the electronic data record and returns a snapshot data structure:

[0082] Snapshot(string recordId, date from)

[0083] At step 1301, find snapshot 101 using the provided record id and the most recent commit and all commits in history where the timestamp is less than the provided datetime. At step 1302, generate a data structure of the form<String,Field Data Structure> The map is created and each commit is iterated over in ascending timestamp order, placing or replacing the version of the object in the map with the key value. The purpose of this step is to place the latest version of each field in the map.

[0084] At step 1303, iterate through each key-value pair of the resulting map, inflating the compressed value, and placing the key and inflated value in a string and serializable form.<String,Serializable> Serializable refers to an object that can be written to a binary stream and reconstructed. At step 1304, the generated map is returned or output on a user interface that represents and reflects the updated information represented at steps 1302 and 1303. Figure 14 An exemplary implementation of a process for generating a snapshot in a Java environment according to an exemplary embodiment is shown.

[0085] As previously explained, the system utilizes SHA hashes of the submission data structure to ensure the integrity of the electronic data record and any changes made to its fields. A validation check can be triggered upon invocation, and can be triggered at any time. The validation process traverses the submission data structure and the associated field data structure, calculating a live hash of the submission and comparing it to the current hash. Assuming this check passes, it then verifies that the stored previous hash matches the hash of the previous submission. If this check passes, it then traverses the chain until it reaches the first submission.

[0086] For example, assuming the simplest scenario, to modify the field contents of the third version of a record's field (changing the record's history), the participant would need direct access to the database. Assuming the user does not wish to make meaningful changes to the record (perhaps digitally destroying it), they could change the binary contents of the field data structure in the database. The next validation would detect this. The next validation would calculate the live hash of the fourth submission using the stored previous hash and the hash attached to the submitted field data structure, along with the salt. This would pass. The stored previous hash in the fourth submission would then be compared to the stored previous hash in the third submission. The algorithm would then validate the third submission, which would fail because the contents of the field data structure would no longer result in the same submitted hash. The field data structure itself would then be hashed and compared to the stored hash to verify which object is different, thereby identifying the changed record.

[0087] Making meaningful changes undetectable is much more difficult. The user must first have access to the database and be able to access the stored binary value. This value must be decompressed and serialized, then changed to a meaningful value. To calculate a new hash for the field data structure, the user must also have access to the salt. Subsequently, the user must also recompute the hash of the commit, and every subsequent commit is altered.

[0088] Figure 15 A dedicated computing environment for generating an audit trail of electronic data records according to an exemplary embodiment is shown. The computing environment 1500 includes a memory 1501, which is a non-transitory computer-readable medium and can be a volatile memory (e.g., registers, cache, RAM), a non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two.

[0089] like Figure 15 As shown, memory 1501 stores audit trail generation software 1501A, graph database 1501B, field, submission, index and snapshot data structures 1501C, new submission software 1501D, verification software 1501E, snapshot generation software 1501F, and hash generation software. Each of the software components in memory 1501 stores specialized instructions and data structures configured to perform the techniques described herein.

[0090] As used herein, a computer program and / or software may comprise any sequence of machine-cognizable steps for performing a function. Such computer programs and / or software may be implemented in any programming language or environment, including, for example, C++, C#, Fortran, COBOL, MATLAB, TM, PASCAL, GO, RUST, SCALA, Python, assembly language, markup language (e.g., H TM L, SGML, XML, VoXML), and object-oriented environments such as Common Object Request Broker Architecture ("CORBA"), Java TM (including J2ME, Java Beans, etc.), Wireless Binary Runtime Environment (for example, "BREW"), etc.

[0091] All software stored in memory 1501 may be stored as computer-readable instructions that, when executed by one or more processors 1502, cause the processors to perform operations related to Figures 1-14 Describe the functionality.

[0092] The one or more processors 1502 execute computer-executable instructions and may be real or virtual processors. In a multi-processing system, multiple processors or multi-core processors may be used to execute computer-executable instructions to increase processing power and / or execute certain software in parallel.

[0093] The computing environment also includes a communication interface 1503, such as a network interface, which is used to communicate with devices, applications, or processes on a computer network or computing system, collect data from devices on the network, and perform encryption / decryption operations on network communications within the computer network or data stored in a database of the computer network. The communication interface transmits information, such as computer-executable instructions, audio or video information, or other data in a modulated data signal. A modulated data signal is a signal whose characteristics are set or changed in a manner that encodes information in the signal. By way of example and not limitation, communication media include wired or wireless technologies implemented using electrical, optical, RF, infrared, acoustic, or other carriers.

[0094] The computing environment 1500 further includes input and output interfaces 1504 that allow a user (eg, a system administrator) to provide input to the system and to display or otherwise transmit information for display to the user.

[0095] Interconnection institutions (such as Figure 15 ) (eg, a bus, controller, or network) interconnects the components of the computing environment 1500.

[0096] The input and output interface 1504 can be coupled to input and output devices. One or more input devices can be a touch input device (e.g., a keyboard, mouse, pen, trackball, touch screen, or game controller), a voice input device, a scanning device, a digital camera, a remote control, or another device that provides input to the computing environment. One or more output devices can be a display, a television, a monitor, a printer, a speaker, or another device that provides output from the computing environment 1500. The display can include a graphical user interface (GUI) that provides options for a user (e.g., a system administrator) to configure the encryption and decryption processes.

[0097] The computing environment 1500 may additionally utilize removable or non-removable storage devices such as disks, tapes or cartridges, CD-ROMs, CD-RWs, DVDs, USB drives, or any other medium that can be used to store information and that can be accessed within the computing environment 1500.

[0098] Computing environment 1500 can be a set-top box, a mobile device, a personal computer, a client device, one or more databases, or one or more servers, such as a networked server farm, a clustered server environment, or a cloud network of computing devices and / or distributed databases.

[0099] Having described and illustrated the principles of the invention with reference to the described embodiments, it will be appreciated that the described embodiments may be modified in arrangement and detail without departing from such principles. Elements of the described embodiments shown in software may be implemented in hardware, and vice versa.

[0100] In view of the many possible embodiments to which the principles of the invention may be applied, it is intended that all such embodiments come within the scope and spirit of the following claims and their equivalents.

Claims

1. A method, performed by one or more computing devices, for generating an audit trail of electronic data records, the method comprising: receiving, by at least one of the one or more computing devices, a request to generate an audit trail for the electronic data record, the request including a record identifier and a date value for the electronic data record; identifying, by at least one of the one or more computing devices, a plurality of commit data structures corresponding to the electronic data record based at least in part on the record identifier, each commit data structure corresponding to a set of changes previously applied to one or more fields of the electronic data record and comprising a timestamp value, a list of one or more changes made to the one or more fields of the electronic data record, and a previous commit pointer to a previous commit data structure corresponding to the previous set of changes applied to the one or more fields of the electronic data record, wherein the list of one or more changes made to the one or more fields of the electronic data record comprises a list of one or more field pointers to one or more field data structures, each field data structure corresponding to a field of the electronic data record and comprising: a content value indicating the content of the field as a result of a submission corresponding to the submission data structure; and a previous version field pointer, the previous version field pointer pointing to a previous version field data structure corresponding to the field of the electronic data record before the submitting; identifying, by at least one of the one or more computing devices, one or more submission data structures of the plurality of submission data structures related to the request based at least in part on the timestamp value and the date value of at least one submission data structure; and Generating, by at least one of the one or more computing devices, the audit trail of the electronic data record based at least in part on the list of the one or more changes in each of the identified one or more submission data structures, comprising: for each of the identified one or more submission data structures, traversing each field pointer in the list of one or more field pointers to identify one or more field data structures corresponding to the commit data structure; determining the content value of each of the one or more field data structures; traversing the previous version field pointer of each of the one or more field data structures to identify one or more previous version field data structures; and A previous version content value of each previous version field data structure of the one or more previous version field data structures is determined.

2. The method of claim 1 , wherein each submission data structure further comprises: a hash value generated based at least in part on the one or more fields in the electronic data record changed by a submission corresponding to the submission data structure; and A previous hash value, the previous hash value corresponding to a previous hash value of the previous commit data structure pointed to by the previous commit pointer. 3 . The method of claim 2 , wherein the hash value is further generated based at least in part on a salt value derived from application code of an application associated with the submission.

4. The method of claim 1 , wherein identifying a plurality of submitted data structures corresponding to the electronic data record based at least in part on the record identifier comprises: identifying a snapshot data structure corresponding to the electronic data record based at least in part on the record identifier, the snapshot data structure comprising a plurality of commit pointers to the plurality of commit data structures; as well as The plurality of commit data structures are identified by traversing the plurality of commit pointers.

5. The method of claim 1 , wherein each commit data structure includes a previous commit pointer that points to a previous commit data structure corresponding to a previous set of changes applied to one or more fields of the electronic data record, and wherein Identifying a plurality of submission data structures corresponding to the electronic data record based at least in part on the record identifier includes: identifying a snapshot data structure corresponding to the electronic data record based at least in part on the record identifier, the snapshot data structure including a most recent commit pointer to a most recent commit data structure; identifying the most recent commit data structure by traversing the most recent commit pointer; and The plurality of submitted data structures corresponding to the electronic data record are identified by traversing a plurality of previous submitted pointers in the plurality of submitted data structures starting from the most recently submitted data structure.

6. The method of claim 1 , wherein, for at least one of the plurality of submission data structures, identifying one or more submission data structures in the plurality of submission data structures related to the request based at least in part on the timestamp value and the date value of the at least one submission data structure comprises: comparing the timestamp of the at least one submission data structure to the date value; as well as The at least one submission data structure related to the request is identified based at least in part on determining that the date of the timestamp is less than the date value.

7. The method of claim 1 , wherein each commit data structure includes a previous commit pointer that points to a previous commit data structure corresponding to a previous set of changes applied to one or more fields of the electronic data record, and wherein Generating the audit trail of the electronic data record based at least in part on the list of the one or more changes in each of the identified one or more submission data structures further comprises: identifying a most recent committed data structure of the identified one or more committed data structures; and Each of the one or more commit data structures is iterated through starting at the most recent commit data structure by traversing the previous commit pointer of each commit data structure.

8. The method of claim 1 , wherein generating the audit trail of the electronic data record based at least in part on the list of the one or more changes in each of the identified one or more submission data structures further comprises, for each of the identified one or more submission data structures: A log record corresponding to the submission data structure is created, the log record including the timestamp value of the submission data structure, the previous version content value of each of the one or more previous version field data structures, and the content value of each of the one or more field data structures.

9. The method of claim 6, wherein each commit data structure, each snapshot data structure, and each field data structure are stored as nodes in a graph database, and wherein each commit pointer and each field pointer are stored as directed edges between nodes in the graph database.

10. An apparatus for generating an audit trail of an electronic data record, the apparatus comprising: one or more processors; and one or more memories operatively coupled to at least one of the one or more processors and having instructions stored thereon that, when executed by at least one of the one or more processors, cause the at least one of the one or more processors to: receiving a request to generate an audit trail for the electronic data record, the request including a record identifier and a date value for the electronic data record; identifying, based at least in part on the record identifier, a plurality of commit data structures corresponding to the electronic data record, each commit data structure corresponding to a set of changes previously applied to one or more fields of the electronic data record and comprising a timestamp value, a list of one or more changes made to the one or more fields of the electronic data record, and a previous commit pointer to a previous commit data structure corresponding to the previous set of changes applied to the one or more fields of the electronic data record, wherein the list of one or more changes made to the one or more fields of the electronic data record comprises a list of one or more field pointers to one or more field data structures, each field data structure corresponding to a field of the electronic data record and comprising: a content value indicating the content of the field as a result of a submission corresponding to the submission data structure; and a previous version field pointer, the previous version field pointer pointing to a previous version field data structure corresponding to the field of the electronic data record before the submitting; identifying one or more submission data structures of the plurality of submission data structures that are related to the request based at least in part on the timestamp value and the date value of at least one submission data structure; and Generating the audit trail of the electronic data record based at least in part on the list of the one or more changes in each of the identified one or more submission data structures comprises: for each of the identified one or more submission data structures, traversing each field pointer in the list of one or more field pointers to identify one or more field data structures corresponding to the commit data structure; determining the content value of each of the one or more field data structures; traversing the previous version field pointer of each of the one or more field data structures to identify one or more previous version field data structures; and A previous version content value of each previous version field data structure of the one or more previous version field data structures is determined.

11. The apparatus of claim 10, wherein each submission data structure further comprises: a hash value generated based at least in part on the one or more fields in the electronic data record altered by a submission corresponding to the submitted data structure; and A previous hash value, the previous hash value corresponding to a previous hash value of the previous commit data structure pointed to by the previous commit pointer.

12. The apparatus of claim 11, wherein the hash value is further generated based at least in part on a salt value derived from application code of an application associated with the submission.

13. The apparatus of claim 10 , wherein the instructions, when executed by at least one of the one or more processors, cause the at least one of the one or more processors to identify a plurality of submission data structures corresponding to the electronic data record based at least in part on the record identifier, and further cause the at least one of the one or more processors to: identifying a snapshot data structure corresponding to the electronic data record based at least in part on the record identifier, the snapshot data structure comprising a plurality of commit pointers to the plurality of commit data structures; and The plurality of commit data structures are identified by traversing the plurality of commit pointers.

14. The apparatus of claim 10 , wherein each commit data structure includes a previous commit pointer that points to a previous commit data structure corresponding to a previous set of changes applied to one or more fields of the electronic data record, and wherein the instructions, when executed by at least one of the one or more processors, cause the at least one of the one or more processors to identify a plurality of commit data structures corresponding to the electronic data record based at least in part on the record identifier, and further cause the at least one of the one or more processors to: identifying a snapshot data structure corresponding to the electronic data record based at least in part on the record identifier, the snapshot data structure including a most recent commit pointer to a most recent commit data structure; identifying the most recent commit data structure by traversing the most recent commit pointer; as well as The plurality of submitted data structures corresponding to the electronic data record are identified by traversing a plurality of previous submitted pointers in the plurality of submitted data structures starting from the most recently submitted data structure.

15. The apparatus of claim 10 , wherein the instructions, when executed by at least one of the one or more processors, cause the at least one of the one or more processors to identify, based at least in part on the timestamp value and the date value of at least one submission data structure, one or more submission data structures of the plurality of submission data structures related to the request, comprising, for at least one submission data structure of the plurality of submission data structures: comparing the timestamp of the at least one submission data structure to the date value; and The at least one submission data structure related to the request is identified based at least in part on determining that the date of the timestamp is less than the date value.

16. The apparatus of claim 10 , wherein each commit data structure includes a previous commit pointer that points to a previous commit data structure corresponding to a previous set of changes applied to one or more fields of the electronic data record, and wherein the instructions, when executed by at least one of the one or more processors, cause the at least one of the one or more processors to generate the audit trail for the electronic data record based at least in part on the list of the one or more changes in each of the identified one or more commit data structures, and further cause the at least one of the one or more processors to: identifying a most recent committed data structure of the identified one or more committed data structures; and Each of the one or more commit data structures is iterated through starting at the most recent commit data structure by traversing the previous commit pointer of each commit data structure.

17. The apparatus of claim 10 , wherein the instructions, when executed by at least one of the one or more processors, cause the at least one of the one or more processors to generate the audit trail of the electronic data record based at least in part on the list of the one or more changes in each of the identified one or more submission data structures, and further cause the at least one of the one or more processors to, for each of the identified one or more submission data structures: A log record corresponding to the submission data structure is created, the log record including the timestamp value of the submission data structure, the previous version content value of each of the one or more previous version field data structures, and the content value of each of the one or more field data structures.

18. The apparatus of claim 15, wherein each commit data structure, each snapshot data structure, and each field data structure are stored as nodes in a graph database, and wherein each commit pointer and each field pointer are stored as directed edges between nodes in the graph database.

19. At least one non-transitory computer-readable medium storing computer-readable instructions that, when executed by one or more computing devices, cause at least one of the one or more computing devices to: receiving a request to generate an audit trail for an electronic data record, the request including a record identifier and a date value for the electronic data record; identifying, based at least in part on the record identifier, a plurality of commit data structures corresponding to the electronic data record, each commit data structure corresponding to a set of changes previously applied to one or more fields of the electronic data record and comprising a timestamp value, a list of one or more changes made to the one or more fields of the electronic data record, and a previous commit pointer to a previous commit data structure corresponding to the previous set of changes applied to the one or more fields of the electronic data record, wherein the list of one or more changes made to the one or more fields of the electronic data record comprises a list of one or more field pointers to one or more field data structures, each field data structure corresponding to a field of the electronic data record and comprising: a content value indicating the content of the field as a result of a submission corresponding to the submission data structure; and a previous version field pointer, the previous version field pointer pointing to a previous version field data structure corresponding to the field of the electronic data record before the submitting; identifying one or more submission data structures of the plurality of submission data structures that are related to the request based at least in part on the timestamp value and the date value of at least one submission data structure; and Generating the audit trail of the electronic data record based at least in part on the list of the one or more changes in each of the identified one or more submission data structures comprises: for each of the identified one or more submission data structures, traversing each field pointer in the list of one or more field pointers to identify one or more field data structures corresponding to the commit data structure; determining the content value of each of the one or more field data structures; traversing the previous version field pointer of each of the one or more field data structures to identify one or more previous version field data structures; and A previous version content value of each previous version field data structure of the one or more previous version field data structures is determined.

20. The at least one non-transitory computer-readable medium of claim 19, wherein each submission data structure further comprises: a hash value generated based at least in part on the one or more fields in the electronic data record altered by a submission corresponding to the submitted data structure; and A previous hash value, the previous hash value corresponding to a previous hash value of the previous commit data structure pointed to by the previous commit pointer.

21. The at least one non-transitory computer-readable medium of claim 20, wherein the hash value is further generated based at least in part on a salt value derived from application code of an application associated with the submission.

22. The at least one non-transitory computer-readable medium of claim 19, wherein the instructions, when executed by at least one of the one or more computing devices, cause the at least one of the one or more computing devices to identify a plurality of submission data structures corresponding to the electronic data record based at least in part on the record identifier, and further cause the at least one of the one or more computing devices to: identifying a snapshot data structure corresponding to the electronic data record based at least in part on the record identifier, the snapshot data structure comprising a plurality of commit pointers to the plurality of commit data structures; and The plurality of commit data structures are identified by traversing the plurality of commit pointers.

23. The at least one non-transitory computer-readable medium of claim 19 , wherein each commit data structure includes a previous commit pointer that points to a previous commit data structure corresponding to a previous set of changes applied to one or more fields of the electronic data record, and wherein the instructions, when executed by at least one of the one or more computing devices, cause the at least one of the one or more computing devices to identify a plurality of commit data structures corresponding to the electronic data record based at least in part on the record identifier, and further cause the at least one of the one or more computing devices to: identifying a snapshot data structure corresponding to the electronic data record based at least in part on the record identifier, the snapshot data structure including a most recent commit pointer to a most recent commit data structure; identifying the most recent commit data structure by traversing the most recent commit pointer; as well as The plurality of submitted data structures corresponding to the electronic data record are identified by traversing a plurality of previous submitted pointers in the plurality of submitted data structures starting from the most recently submitted data structure.

24. The at least one non-transitory computer-readable medium of claim 19, wherein the instructions, when executed by at least one of the one or more computing devices, cause the at least one of the one or more computing devices to identify one or more submission data structures of the plurality of submission data structures related to the request based at least in part on the timestamp value and the date value of at least one submission data structure, comprising, for at least one submission data structure of the plurality of submission data structures: comparing the timestamp of the at least one submission data structure to the date value; and The at least one submission data structure related to the request is identified based at least in part on determining that the date of the timestamp is less than the date value.

25. The at least one non-transitory computer-readable medium of claim 19 , wherein each commit data structure includes a previous commit pointer that points to a previous commit data structure corresponding to a previous set of changes applied to one or more fields of the electronic data record, and wherein the instructions, when executed by at least one of the one or more computing devices, cause the at least one of the one or more computing devices to generate the audit trail for the electronic data record based at least in part on the list of the one or more changes in each of the identified one or more commit data structures, and further cause the at least one of the one or more computing devices to: identifying a most recent committed data structure of the identified one or more committed data structures; and Each of the one or more commit data structures is iterated through starting at the most recent commit data structure by traversing the previous commit pointer of each commit data structure.

26. The at least one non-transitory computer-readable medium of claim 19, wherein the instructions, when executed by at least one of the one or more computing devices, cause the at least one of the one or more computing devices to generate the audit trail of the electronic data record based at least in part on the list of the one or more changes in each of the identified one or more submission data structures, and further cause the at least one of the one or more computing devices to, for each of the identified one or more submission data structures: A log record corresponding to the submission data structure is created, the log record including the timestamp value of the submission data structure, the previous version content value of each of the one or more previous version field data structures, and the content value of each of the one or more field data structures.

27. At least one non-transitory computer-readable medium according to claim 24, wherein each commit data structure, each snapshot data structure, and each field data structure are stored as a node in a graph database, and wherein each commit pointer and each field pointer are stored as a directed edge between nodes in the graph database.

28. A computer program product comprising computer-readable instructions that, when executed by one or more computing devices, cause at least one of the one or more computing devices to perform the method of any one of claims 1-9.

Images