CN113488184A

CN113488184A - Method and device for inputting data, computer readable storage medium and electronic equipment

Info

Publication number: CN113488184A
Application number: CN202110768265.6A
Authority: CN
Inventors: 李欣
Original assignee: Tianjin Happy Life Technology Co ltd
Current assignee: Tianjin Happy Life Technology Co ltd
Priority date: 2021-07-07
Filing date: 2021-07-07
Publication date: 2021-10-08
Anticipated expiration: 2041-07-07
Also published as: CN113488184B

Abstract

The disclosure provides a method and a device for inputting data, a computer readable storage medium and electronic equipment, and relates to the technical field of data processing. The method comprises the following steps: determining whether a target data entry identical to the current data entry exists in the database or not according to the identifier of the current data entry to be recorded into the database; if the target data entry identical to the current data entry exists in the database, determining whether the data operation type of the current data entry is a deletion type; if the data operation type of the current data entry is a non-deletion type, determining whether the data value of the current data entry is the same as the data value of the target data entry; and if the data value of the current data entry is different from the data value of the target data entry, replacing the data value of the target data entry by the data value of the current data entry, and processing the next data entry to be entered into the database. According to the technical scheme, the recording efficiency of the incremental data can be effectively improved while higher recording accuracy is guaranteed.

Description

Method and device for inputting data, computer readable storage medium and electronic equipment

Technical Field

The present disclosure relates to the field of data processing technologies, and in particular, to a data entry method, a data entry device, and a computer-readable storage medium and an electronic device for implementing the data entry method.

Background

Clinical trial Data is currently maintained by databases, such as EDC (Electronic Data Capture) for systematic analysis and study of the clinical trial Data. The data generated during Clinical trials (Clinical trials) is increasing over time. That is, in maintaining clinical trial data via a database, problems arise in that incremental data that is continually generated needs to be entered into the database. Incremental data is generally entered manually in the prior art.

However, the manual entry method has the problem of low entry efficiency.

It is to be noted that the information disclosed in the above background section is only for enhancement of understanding of the background of the present disclosure, and thus may include information that does not constitute prior art known to those of ordinary skill in the art.

Disclosure of Invention

The invention aims to provide a data entry method, a data entry device and electronic equipment, which can improve the entry efficiency of incremental data to a certain extent at least while ensuring higher entry accuracy.

Additional features and advantages of the disclosure will be set forth in the detailed description which follows, or in part will be obvious from the description, or may be learned by practice of the disclosure.

According to an aspect of an embodiment of the present disclosure, there is provided a method of entering data, the method including: determining whether a target data entry identical to a current data entry exists in a database according to an identifier of the current data entry to be recorded into the database; determining whether the data operation type of the current data entry is a deletion type or not in response to the fact that the target data entry which is the same as the current data entry exists in the database; determining whether the data value of the current data entry is the same as the data value of the target data entry or not in response to the data operation type of the current data entry being a non-deletion type; and in response to the data value of the current data entry being different from the data value of the target data entry, replacing the data value of the target data entry with the data value of the current data entry, and processing a next data entry to be entered into the database.

In an exemplary embodiment, based on the foregoing scheme, the method further includes: and responding to the data value of the current data entry being the same as the data value of the target data entry, keeping the data value of the target data entry unchanged, and processing the entry operation of the next data entry to be entered into the database.

In an exemplary embodiment, based on the foregoing scheme, the method further includes: and in response to the fact that the target data item which is the same as the current data item does not exist in the database, recording the data of the current data item into the database.

In an exemplary embodiment, based on the foregoing scheme, the method further includes: and performing logic deletion operation on the data value corresponding to the current data entry in response to the fact that the data operation type contained in the current data entry is a deletion type.

In an exemplary embodiment, based on the foregoing scheme, the current data entry comprises a plurality of data points, each of the data points having a corresponding data value; wherein the determining whether the data value of the current data entry is the same as the data value of the target data entry comprises: determining whether the data value on each data point of the current data entry is consistent with the corresponding data value in the database or not in response to the fact that the data operation type contained in the current data entry is a non-deletion type; the maintaining the data value of the target data entry unchanged in response to the data value of the current data entry being the same as the data value of the target data entry, comprising: and in response to the data value at each data point of the current data entry being consistent with the corresponding data value in the database, discarding the data value corresponding to each data point in the current data entry.

In an exemplary embodiment, based on the foregoing scheme, the method further includes: responding to the data value on each data point of the current data entry and the corresponding data value in the database to be inconsistent, and acquiring a target data point, wherein the target data point is a data point of which the data value in the current data entry is different from the corresponding data value in the database; and replacing the corresponding data value in the database by the data value of the target data point.

In an exemplary embodiment, based on the foregoing scheme, before determining whether the data value of the current data entry is the same as the data value of the target data entry, the method further includes:

determining whether the target data entry contains a preset mark; and in response to the target data entry containing a preset mark, storing the data of the target data entry and the data of the current data entry into a target queue, and keeping the data value of the target data entry in the database unchanged.

In an exemplary embodiment, based on the foregoing scheme, the method further includes: determining a medical record report form (CRF), and determining a mapping relation between a data item of each hierarchy in the CRF and source data; respectively determining identifiers for unique identification for the data items of each hierarchy; and extracting data from the source data according to the mapping relation to obtain data values corresponding to the data entries of each hierarchy.

In an exemplary embodiment, based on the foregoing scheme, the CRF includes N levels; wherein, respectively determining an identifier for unique identification for the data entry of each hierarchy includes: determining a uniquely identified identifier corresponding to a data entry of a first hierarchical level; the identifiers corresponding to the data entries of the (i + 1) th level comprise identifiers of the data entries of the (i) th level, and i is a positive integer smaller than N.

In an exemplary embodiment, based on the foregoing scheme, extracting data in the source data according to the mapping relationship includes: and converting the clinical test data of the subject into an Operational Data Model (ODM) format, and extracting data from the source data according to the mapping relation, wherein the data value corresponding to each level of the extracted data conforms to the ODM format.

According to another aspect of an embodiment of the present disclosure, there is provided an apparatus for entering data, the apparatus including: a first anticipation module, configured to: determining whether a target data entry identical to a current data entry exists in a database according to an identifier of the current data entry to be recorded into the database; a second anticipation module, configured to: in response to the database having a target data entry that is the same as the current data entry, determining whether the current data entry contains a data operation type that is a deletion type; a third prediction module to: determining whether the data value of the current data entry is the same as the data value of the target data entry or not in response to the data operation type of the current data entry being a non-deletion type; an update module to: and in response to the data value of the current data entry being different from the data value of the target data entry, replacing the data value of the target data entry with the data value of the current data entry, and processing a next data entry to be entered into the database.

According to still another aspect of the present disclosure, there is provided an electronic device including: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the above-described method of logging data via execution of the executable instructions.

According to yet another aspect of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored, which computer program, when being executed by a processor, carries out the above-mentioned method of entering data.

In the method for inputting data, the device for inputting data and the electronic device provided by the embodiment of the disclosure, whether a target data entry identical to a current data entry exists in a database is determined according to an identifier of the current data entry of the database to be input. If the target data entry which is the same as the current data entry exists, whether the data operation type contained in the current data entry is the deletion type is further determined. And under the condition that the data operation type of the current data entry is a non-deletion type, further judging whether the data value of the current data entry is the same as the data value of the target data entry in the database or not so as to judge whether the value corresponding to the data entry is updated or not. If the data values are not the same, it is determined that the value corresponding to the data entry is updated, that is, the value corresponding to the current data entry is the incremental data to be recorded into the database, and the data value of the target data entry is replaced by the data value of the current data entry. Thereby completing the counting of the current data entry and processing the next data entry to be entered into the database. In the technical scheme, whether the data entry to be recorded and the corresponding value belong to the incremental data or not is judged, and then the incremental data is recorded into the database. The efficiency and the accuracy of the incremental data entry are improved in an automatic entry mode.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure. It is to be understood that the drawings in the following description are merely exemplary of the disclosure, and that other drawings may be derived from those drawings by one of ordinary skill in the art without the exercise of inventive faculty.

Fig. 1 schematically shows a schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of the present disclosure may be applied.

FIG. 2 schematically illustrates a flow chart of a method of entering data in an exemplary embodiment of the disclosure.

FIG. 3 schematically illustrates a flow chart of another method of entering data in an exemplary embodiment of the disclosure.

Fig. 4 schematically illustrates a flowchart of yet another method of entering data in an exemplary embodiment of the present disclosure.

FIG. 5 schematically illustrates a data structure diagram satisfying an operational data model in an exemplary embodiment of the disclosure.

FIG. 6 schematically illustrates a graphical user interface diagram for uploading files in an exemplary embodiment of the present disclosure.

Fig. 7 is a schematic structural diagram of an apparatus for entering data in an exemplary embodiment of the present disclosure.

Fig. 8 shows a block diagram of an electronic device in an exemplary embodiment of the present disclosure.

Fig. 9 shows a schematic structural diagram of a computer-readable storage medium in an exemplary embodiment of the disclosure.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

Furthermore, the drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus their repetitive description will be omitted. Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

Fig. 1 schematically shows a schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of the present disclosure may be applied. Referring to fig. 1, a system architecture 100 may include: a number of terminals 120 and a server cluster 140.

The terminal 120 may be a mobile terminal such as a mobile phone, a game console, a tablet Computer, an e-book reader, smart glasses, an MP4(moving picture Experts Group Audio Layer IV) player, an intelligent home device, an AR (Augmented Reality) device, a VR (Virtual Reality) device, or a Personal Computer (PC), such as a laptop Computer and a desktop Computer.

Among other things, an application program for providing an entry data scheme may be installed in the terminal 120.

The terminals 120 are connected to the server cluster 140 through a communication network. Illustratively, the communication network is a wired network or a wireless network.

The server cluster 140 is a server, or is composed of a plurality of servers, or is a virtualization platform, or is a cloud computing service center. The server cluster 140 is used to provide background services for applications that provide a schema for entering data. Illustratively, the server cluster 140 undertakes primary computational work and the terminals 120 undertake secondary computational work; alternatively, the server cluster 140 undertakes secondary computing work and the terminal 120 undertakes primary computing work; alternatively, the terminal 120 and the server cluster 140 perform cooperative computing by using a distributed computing architecture.

Illustratively, the clients of the applications installed in different terminals 120 are the same, or the clients of the applications installed on two terminals 120 are clients of the same type of application of different control system platforms. Based on different terminal platforms, the specific form of the client of the application program may also be different, for example, the client of the application program may be a mobile phone client, a PC client, or a World Wide Web (Web) client.

Those skilled in the art will appreciate that the number of terminals 120 described above may be greater or fewer. For example, the number of the terminals may be only one, or several tens or hundreds of the terminals, or more. The number of terminals and the type of the device are not limited in the embodiments of the present application.

Illustratively, the system may further include a management device (not shown in fig. 1), which is connected to the server cluster 140 via a communication network. Illustratively, the communication network is a wired network or a wireless network.

Illustratively, the wireless or wired networks described above use standard communication techniques and/or protocols. The Network is typically the Internet, but may be any Network including, but not limited to, a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a mobile, wireline or wireless Network, a private Network, or any combination of virtual private networks. In some embodiments, data exchanged over a network is represented using techniques and/or formats including Hypertext Mark-up Language (HTML), Extensible markup Language (XML), and the like. All or some of the links may also be encrypted using conventional encryption techniques such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), Internet protocol Security (IPsec).

An embodiment of a method of entering data is described below. The method provided by the embodiment of the present disclosure may be performed by any electronic device with computing processing capability, for example, the terminal 120 and/or the server cluster 140 in fig. 1. In the following description, the server cluster 140 is used as an execution subject for illustration.

Fig. 2 schematically illustrates a flow chart of a method for entering data in an exemplary embodiment of the present disclosure. Referring to fig. 2, the scheme shown in this embodiment includes:

step S210, determining whether a target data entry identical to a current data entry exists in a database according to an identifier of the current data entry to be recorded into the database;

step S220, responding to the database that the target data item same as the current data item exists, and determining whether the current data item contains a data operation type which is a deletion type;

step S230, in response to that the data operation type of the current data entry is a non-deletion type, determining whether the data value of the current data entry is the same as the data value of the target data entry;

step S240, in response to that the data value of the current data entry is different from the data value of the target data entry, replacing the data value of the target data entry with the data value of the current data entry, and processing a next data entry to be entered into the database.

Wherein, the current data item refers to the data item being processed, and the next data item refers to the data item to be processed. The data items and the values corresponding to the data items belong to clinical test data, specifically; data generated during clinical trials. Specifically, Clinical Trial (Clinical Trial) refers to any systematic study of drugs in humans (patients or healthy volunteers) to confirm or reveal the effects, adverse effects and/or absorption, distribution, metabolism and excretion of the test drugs in order to determine the efficacy and safety of the test drugs. In a clinical trial, the subject will contain multiple visit periods, and the subject will need to complete the relevant medication and test examinations within the prescribed visit period to generate clinical trial data.

The database may be a database for collecting and maintaining clinical trial data, and the EDC is taken as an example in this embodiment. The EDC system is a computer network-based technology for clinical trial data acquisition, and directly acquires and transfers clinical data in an electronic form through organic combination of software, hardware, standard operating programs and human configuration. In the process of inputting clinical test data, the hard supervision requirement that all operations need to be marked needs to be met, and meanwhile, the repeated uploading of the data needs to be avoided. The technical scheme is used for solving the technical problem and providing the technical scheme for effectively identifying the incremental data and realizing the automatic entry of the incremental data into the related database. According to the technical scheme, the recording efficiency of the incremental data can be effectively improved while higher recording accuracy is guaranteed.

In an exemplary embodiment, fig. 3 and 4 schematically illustrate a flow chart of a method of entering data in an exemplary embodiment of the disclosure, respectively. Specific embodiments of the steps in the method for entering data shown in fig. 2 are described in more detail below with reference to fig. 3 and 4.

The data entry scheme provided by the technical scheme generally comprises the following steps: a data conversion link and a data import system link. The embodiment of the method for entering data shown in fig. 2 is used to describe a related embodiment of a data importing system link, and steps S310 to S330 in fig. 3 are used to describe a related embodiment of a data converting link.

In the technical solution provided with reference to fig. 3, step S310 to step S330 are required to be executed before step S210 is executed. That is, the following first introduces a related embodiment of the data conversion section:

in step S310, a medical record report table CRF is determined, and a mapping relationship between a data entry of each level in the CRF and source data is determined.

Among them, CRF (Case Report Form) is a document for recording all information required by a subject in an experimental plan and reporting to a sponsor, and is a main carrier for collecting data of clinical trials. The file may be printed, visible or electronic in form.

In an exemplary embodiment, the study visit content, form content, data entry (e.g., field/variable) content, and value ranges, etc., contained in the CRF are determined according to the requirements of the clinical trial protocol. Referring to table 1, the form content may include vital signs (screening period), vital signs, physical examination, ECGO scores, and the like. The fields/variables include: weight, whether or not to perform an assessment, abnormal situation description, date of assessment, etc.

TABLE 1

Illustratively, to improve processing efficiency during clinical trial data collection, exchange, submission, analysis, etc., the clinical trial data may be standardized. The contents of the above-mentioned forms and fields conform to the CDISC (Clinical Data Interchange Standards Consortium) standard, i.e., the value range may conform to the Controlled Terminology standard with fields, variable names, naming specifications, etc. conforming to the requirements of the standard.

For example, the process of determining CRF may be configured in Excel and then introduced into the EDC system, or may be directly completed in the EDC system. Specifically, a two-dimensional table structure is generated in a relational database according to the CRF through a computer program, data of different domains are stored in a single two-dimensional table, and the table name, the table structure and the field name of the two-dimensional table need to be consistent with the data entry content of the CRF. For example, two fields of a subject ID and a visit period ID can be added to each table, wherein the subject ID is used for distinguishing different subjects, and the visit period ID is used for distinguishing different visit periods to serve as a reference factor when data sorting and reorganization are performed subsequently.

It should be noted that the data values (for example, the weight value of the subject, whether the subject is evaluated, the abnormal condition description of the subject, etc.) corresponding to the various data entries of the CRF are derived from the source data. Wherein, the source data refers to all information recorded on the original record or the verification copy thereof in the clinical test. Including clinical findings, observations, and other relevant activity records necessary for reconstruction and evaluation of the trial. In the present embodiment, the source data may be all information of clinical trial related activities recorded and stored in an Electronic Health Records (EHR) system in an Electronic form. The EHR is an electronic history record with a reserved value directly formed in health-related activities, including but not limited to information about vital signs, medical history, diagnosis, physical examination, laboratory tests, medication and the like generated by a hospital electronic information system. The data value corresponding to each data entry of the CRF may be a certain field in a certain table in the EHR data.

That is, there is a mapping relationship between the CRF and the source data. Specifically, referring to fig. 4, a mapping 43 exists between CRF tables 41 and subject clinical trial data (source data)42 established in the EDC system.

Referring to fig. 4, in step S410, the subject clinical trial data is converted into CDISC ODM format according to the mapping relationship between source data and CRF.

For example, for the source data in the EHR related to the above mapping relationship, the operational data model ODM format conversion is performed so as to satisfy the CDISC ODM standard, so that the source data satisfying the CDISC ODM standard is imported into the EDC system. Among them, ODM (Operational Data Model) belongs to CDISC standard, specifically XML-based, content and format standard for acquisition, exchange, reporting or submission, and archiving clinical research Data based on CRF.

In an exemplary embodiment, after the definition of the CRF is completed in the EDC system supporting the CDISC standard, Metadata information (Metadata) of the current CRF may be directly generated, including information of all definitions in the CRF related to data elements such as Subject (Subject), visit period (Event), Form (Form), field group (itemggroup), and field (Item).

FIG. 5 schematically illustrates a data structure diagram satisfying an operational data model in an exemplary embodiment of the disclosure. The multi-level data entry metadata information 51 satisfying the operational data model ODM standard and the clinical data (clinical data)52 satisfying the operational data model ODM are shown with reference to fig. 5. The source Data Version of a clinical trial project (Study) comprises: the visit period defines Event Def, Form definition Form Def, field Group definition Item Group Def and field definition Item Def. Specifically, a complete piece of clinical Data (clinical Data) includes a plurality of Subject Data (Subject Data), each Subject has a plurality of visit cycle Data (Event Data), each visit cycle has a plurality of forms of Data (Form Data, which can be understood as a sheet in Excel, such as vital signs and laboratory tests) below it, each Form may have one or more field groups of Data (ItemGroup Data, which can be understood as a row in Excel) below it, each field group has a specific field below it (Item, which can be understood as a cell in Excel), and each field has a respective more detailed definition (such as name, Data type, format, etc. shown on the EDC system interface).

With continued reference to fig. 3, in step S320, an identifier UUOID for unique identification is determined for each of the hierarchy data entries.

In an exemplary embodiment, each level of data entries defined in the CRF is configured with an identifier for unique identification of the data entity. For example, a data entity of a certain level is uniquely located in the EDC system by using UUOID (Unique United Object ID) as the identifier.

For the data entities/data entries having a hierarchical relationship shown in fig. 5, each hierarchy needs to correspond to the UUOID of the hierarchy, for example, the subject hierarchy is SubjectKey, the form hierarchy is FormOID, and the field hierarchy is itemiod. Illustratively, UUOIDs for different hierarchy data entities may be generated by combining the inter-hierarchy OIDs. Specifically, a UUOID at a lower level contains a UUOID at an upper level. Detailed as shown in table 2:

TABLE 2

The UUOID setting mode shown in table 2 can ensure that the data entity of each hierarchy has a globally unique identifier. For example, the UUOIDs of the two forms are the same, but the two forms belong to different visit periods respectively, so that the UUOIDs of the visit periods are different, and the two forms can be effectively distinguished by the method shown in table 2.

It should be noted that, the source data acquired in the HER according to the mapping relationship may also determine the UUOID corresponding to each source data in the above manner, so as to ensure that the EDC system can accurately identify and perform a predetermined operation on the source data (which will be described in detail in the following embodiments).

Continuing with fig. 3, in step S330, data is extracted from the source data according to the mapping relationship, and data values corresponding to the data entries of each hierarchy are obtained.

In an exemplary embodiment, based on the embodiment corresponding to step S410 and the embodiments corresponding to step S310 and step S320, data is extracted from the source data of the EHR according to the mapping relationship between the CRF and the source data. Illustratively, the extracted data is filled into the mapping positions corresponding to the two-dimensional table, so as to obtain the data values corresponding to the data entries of each hierarchy. The data value corresponding to each hierarchy is data which conforms to the CDISC ODM format and is provided with UOID.

In an exemplary embodiment, the two-dimensional table may be organized according to a Form, namely: and mounting the data in the two-dimensional table under the corresponding visit cycle data studio eventdata and subject data objectdata nodes in the form of form data FormData nodes. Each Form includes field data ItemGroupData and field data ItemData.

For example, an exemplary implementation of a two-dimensional table for organizing a Form includes: firstly, calculating the visit period corresponding to each piece of clinical data according to the time sequence relation of the data values, and filling the information into the visit period ID field of the two-dimensional table. Then, the Subject (Subject) and the visit period (Event) are distinguished by the Subject ID and the visit period ID. Namely: data with the same subject ID will be organized under the same SubjectData node, and data with the same visit cycle ID will be organized under the same StudyEventData node. Further, according to the metadata information of the CRF, determining the Form contained in each visit period Event. The data format as shown in fig. 5 is finally formed, that is, the data extracted from the source data is hierarchically organized in the form of ClinicalData → SubjectData → StudyEventData → FormData → ItemGroupData → ItemData.

Illustratively, if there are multiple records under the same field group, the serial number of the record is identified by the increasing number sequence itemgrouprep key, so as to indicate that the current record corresponds to the data of the second row in the EDC system.

Illustratively, the data value corresponding to each hierarchy extracted from the source data further includes a data operation type. Wherein the data operation type is embodied in the CDISC ODM as a TransactionType attribute of the data node. For most data, the TransactionType attribute (data operation type) is set as an "Update" type by default, that is, two operation types of Insert (Insert) and Update (Update) are combined into one, and the EDC system judges whether Insert operation or Update operation is specifically performed according to UUOID, thereby greatly simplifying the data format conversion process.

In addition, for a data deletion operation having a small occurrence probability, the TransactionType attribute (data operation type) may be set to the "Delete" type. Further, the EDC system determines a corresponding data node according to the UUOID, and performs a logical deletion operation on the data. Wherein the logical delete operation is a non-physical delete, which is simply marked with a delete flag in the EDC system.

It should be noted that, if the relevant data node already has a deletion flag in the database, the current "Delete" type is ignored, and no operation is performed.

Through the technical scheme, balance can be realized between a data conversion link and a data import system link, namely: the method reduces the workload of manual intervention and the like in the data conversion link, further ensures the automation to the maximum extent, fully exerts the characteristics of the EDC system, and has more flexible adjustment space in the aspect of logical judgment operation in the process of importing the data into the system link.

In the above embodiments, a related embodiment of the data conversion section is described, and in the following, a related embodiment of the data import system section is described.

Referring to fig. 2 or fig. 3, in step S210, it is determined whether a target data entry identical to a current data entry already exists in a database according to an identifier of the current data entry to be entered into the database.

In an exemplary embodiment, the EDC system can be imported in bulk after the clinical data is organized in an ODM fashion. Reference is made to fig. 6, which schematically illustrates a graphical user interface diagram for uploading files in an embodiment of the disclosure. Through the interface, a user can realize batch uploading of ODM compressed files (ODM ZIPs) 600.

Specifically, the interface includes a select subject file portion 610, a select subject data file portion 620, and a display 630 that shows the ODM upload task and the task upload status. Illustratively, the user can determine all data files belonging to a subject by clicking/touching the add file control 61 according to the subject ID. For example, the user may select a file to be uploaded from all data files of the subject by clicking/touching the add file control 62, or may upload all data files of the subject, which is not limited herein. Further, the upload status of each ODM task can be clearly viewed through 630.

In an exemplary embodiment, the data uploaded to the EDC system is automatically identified and predetermined (e.g., by a predetermined module of the EDC system). Specifically, in the data in the ODM format, the data entities (data entries and corresponding data values) in different hierarchies uniquely identify the identifier UUOID, so that the EDC system can be ensured to analyze the data entities in each hierarchy in the ODM, and perform step-by-step positioning through the UUOID, thereby implementing automatic identification operation.

The following describes embodiments related to automated predictive operations for data uploaded to an EDC system:

specifically, the prejudging module in the EDC system may judge whether the UUOID is in the current database according to the UUOID information corresponding to each hierarchy. Illustratively, step S420 is performed: and judging whether the current data entry is a new data entry or not through the UOID. In other words, a determination is made as to whether a data entry corresponding to the UUOID already exists in the data.

If the current data entry does not exist in the current database, the data entry is a new data entry, namely the data value corresponding to the data entry is incremental data and needs to be recorded into the database. As a specific implementation of step S350 (entering the data value corresponding to the current data entry into the database): step S490 is executed to perform Insert operation on the data value corresponding to the current data entry in the database.

If the current data entry already exists in the current database (that is, the database has a target data entry corresponding to the current data entry), it indicates that there is a possibility that the data value corresponding to the data entry is incremental data, and further some type of modification operation needs to be performed on the original data, or the data value corresponding to the data entry does not belong to the incremental data and needs to be logically deleted. In this embodiment, the data entry corresponding to the UUOID needs to be further determined, so step S430 is executed: a determination is made based on the data operation type of the current data entry (a specific implementation of step S220). As mentioned above, the data operation type is embodied as a TransactionType attribute of the data node in the CDISC ODM, and includes two types, namely "update" and "Delete".

If the data operation type of the current data entry is Delete, execute step S440: the logic deletes all data in the database under the target data entry. Specifically, a logical delete operation is performed on a data value corresponding to a target data entry corresponding to a current data entry in the database, and the target data entry is marked in a back-end database of the EDC system. If the corresponding target data entry in the database is marked with the logical deletion mark, the current logical deletion operation is ignored.

If the data operation type of the current data entry is Upsert, whether the data value on each data point of the lower layer is consistent with the corresponding data value in the database needs to be further judged.

Referring to fig. 3, as a specific embodiment of step S230: in response to the data value of the current data entry being the same as the data value of the target data entry, i.e. indicating that the data value of the current data entry is not incremental clinical trial data for which an update has occurred, step S340 is performed: and keeping the data value of the target data entry unchanged, and processing the entry operation of the next data entry to be entered into the database. In response to there being no target data entry in the database that is the same as the current data entry, i.e., the incremental clinical trial data that indicates the data value of the current data entry as being updated, step S350 is executed: and inputting the data of the current data entry into the database. Through the implementation of step S230, it can be simply and quickly determined whether the data value corresponding to the data entry to be entered is the updated clinical trial data, but the data operation type ODM is not reflected or whether a manual modification flag is included, so that the entry accuracy of the implementation is to be improved.

In order to effectively improve the data entry accuracy, the present technical solution further provides another implementation manner of step S230.

Referring to fig. 4, step S450 is performed: and judging whether the data value of each data point of the current data item is consistent with the data value of the corresponding data point in the target data item in the database.

If the data value of each data point of the current data entry is consistent with the corresponding data value in the database, it indicates that the content corresponding to the current data entry is not updated, that is, the data value under the current data entry is further used as the incremental data recorded into the database. The EDC system therefore automatically ignores the data of the own node, i.e., performs step S4100: discarding the data value corresponding to each data point in the current data entry without performing any operation on the target data entry in the database.

And if the data value on each data point of the current data item is inconsistent with the corresponding data value in the database, discarding the data value of the data point of the current data item, which is consistent with the corresponding data value in the database. Whereas data values at data points for a current data entry that are inconsistent with corresponding data values in the database theoretically belong to incremental data that can be entered into the database. However, in the embodiment, whether the manual modification mark exists or not is also considered preferentially, and the data point containing the manual modification mark is confirmed manually, so that a manual confirmation link is added in the automatic data entry process, so that the personalized requirement is increased, and the entry accuracy is improved.

Therefore, the technical solution needs to further determine whether the data value of the current data entry includes a preset flag (e.g., a manual modification flag). Step S460 is executed in the present embodiment: and judging whether the data value corresponding to the current data point in the database contains a preset mark or not.

If the data value corresponding to the current data point in the database has no preset mark (i.e. the data value at the current data point is inconsistent with the corresponding data value in the database, and the data value corresponding to the current data point in the database has no preset mark), then step S470 is executed: and performing Update operation on the data value on the corresponding data point in the database. Specifically, a target data point is obtained in a current data entry, wherein the target data point is a data point of which the data value in the current data entry is different from the data value on a corresponding data point in the target data entry; and replacing the corresponding data value in the database by the data value of the target data point.

If the data value corresponding to the current data point in the database has the preset mark (that is, the data value on the current data point is inconsistent with the corresponding data value in the database, and the data value corresponding to the current data point in the database has the preset mark), it indicates that the data point has been manually modified, because the default priority of manual modification of the system is higher than that of automatic machine filling, the Update operation is not directly executed, but the inconsistent condition is put into an alarm queue (step S480: adding the data value corresponding to the current data point in the source data and the data value corresponding to the current data point in the database into the target queue), and then the result of automatic machine filling is manually judged to be accepted or rejected.

It can be seen that even if the data to be entered is completely consistent with the data already entered in the previous batch (i.e. there is no incremental data), since the EDC system is configured with the above-mentioned UUOID-based anticipation mechanism (for example, according to the anticipation operation in step S450, for a data point whose data value corresponding to the data point is the same as the corresponding data value in the database, although the data operation type is update, the data point may be directly discarded without any processing, and for example, in the anticipation operation in step S430, the data point with the Delete operation mark may not be executed any more because the data point does not exist in the EDC system, and so on), as a whole, besides increasing the burden of the corresponding and anticipation data of the EDC system, there is no negative effect on the clinical test data already in the EDC system; since no valid data operation is performed, no redundant trace data is generated. If the newly introduced data is different from the previous data, the same part is discarded, and the different part is captured by the anticipation mechanism of the EDC system and corresponding operation is performed. Through the strict prejudgment and interception mechanism, automatic and repeated import of incremental clinical data can be realized, the labor cost is greatly reduced, and the timeliness and the accuracy of data entry are improved. Therefore, the predication operation and the recording operation of the incremental clinical test data are realized.

In an exemplary embodiment, the clinical trial data newly generated during the clinical trial can be entered into the EDC system using the technical solutions provided in the above embodiments. For example, the operation frequency can be set to T +1 day, or the operation can be performed at T + M days (1 ≦ M ≦ 7) according to the data generation speed and the data timeliness requirement of the project.

According to the technical scheme, the automatic entry of incremental clinical test data is effectively realized through an identifier configuration scheme and identification operation, prejudgment operation and interception operation based on the identifier. In the scheme, the data production process and the data import process are integrated and considered by specifically combining the relevant data standard of the CDISC and the functional characteristics of the EDC system, so that the problem that the clinical test data follow-up visit visual cycle propulsion increment is generated and then needs to be imported for multiple times is solved. Under the conditions of not increasing the complexity of data conversion and not increasing the invalid trace data of the EDC system, the efficiency and the accuracy of data entry of clinical test data are effectively improved.

Those skilled in the art will appreciate that all or part of the steps to implement the above embodiments are implemented as computer programs executed by a processor, including a GPU/CPU. When executed by the GPU/CPU, performs the above-described functions defined by the above-described methods provided by the present disclosure. The program may be stored in a computer readable storage medium, which may be a read-only memory, a magnetic or optical disk, or the like.

Furthermore, it should be noted that the above-mentioned figures are only schematic illustrations of the processes involved in the methods according to exemplary embodiments of the present disclosure, and are not intended to be limiting. It will be readily understood that the processes shown in the above figures are not intended to indicate or limit the chronological order of the processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, e.g., in multiple modules.

An embodiment of the data logging device of the present disclosure is described below with reference to fig. 7, which can be used to execute the above-mentioned data logging method of the present disclosure.

Fig. 7 is a schematic structural diagram of an apparatus for entering data in an exemplary embodiment of the present disclosure. As shown in fig. 7, the apparatus 700 for entering data includes: a first anticipation module 701, a second anticipation module 702, a third anticipation module 703, and an updating module 704.

The first prejudging module 701 is configured to: determining whether a target data entry identical to a current data entry exists in a database according to an identifier of the current data entry to be recorded into the database; the second anticipation module 702 is configured to: in response to the database having a target data entry that is the same as the current data entry, determining whether the current data entry contains a data operation type that is a deletion type; the third prediction module 703 is configured to: determining whether the data value of the current data entry is the same as the data value of the target data entry or not in response to the data operation type of the current data entry being a non-deletion type; and the update module 704 is configured to: and in response to the data value of the current data entry being different from the data value of the target data entry, replacing the data value of the target data entry with the data value of the current data entry, and processing a next data entry to be entered into the database.

In an exemplary embodiment, based on the foregoing solution, the apparatus 700 for entering data further includes: a holding module.

Wherein, the holding module is configured to: and responding to the data value of the current data entry being the same as the data value of the target data entry, keeping the data value of the target data entry unchanged, and processing the entry operation of the next data entry to be entered into the database.

In an exemplary embodiment, based on the foregoing solution, the apparatus 700 for entering data further includes: and adding a module.

Wherein, the adding module is configured to: and in response to the fact that the target data item which is the same as the current data item does not exist in the database, recording the data of the current data item into the database.

In an exemplary embodiment, based on the foregoing scheme, the current data entry contains a data operation type; the apparatus 700 for entering data further comprises: and a logic deleting module.

Wherein, the logic deleting module is configured to: and performing logic deletion operation on the data value corresponding to the current data entry in response to the fact that the data operation type contained in the current data entry is a deletion type. In an exemplary embodiment, based on the foregoing scheme, the current data entry comprises a plurality of data points, each of the data points having a corresponding data value; the third prediction module is specifically configured to: determining whether the data value of each data point of the current data entry is consistent with the corresponding data value in the database or not in response to the data operation type of the current data entry being a non-deletion type; the holding module is specifically configured to: and in response to the data value at each data point of the current data entry being consistent with the corresponding data value in the database, discarding the data value corresponding to each data point in the current data entry.

In an exemplary embodiment, based on the foregoing solution, the apparatus 700 for entering data further includes: and an acquisition module.

Wherein, the obtaining module is configured to: responding to the data value on each data point of the current data entry and the corresponding data value in the database to be inconsistent, and acquiring a target data point, wherein the target data point is a data point of which the data value in the current data entry is different from the corresponding data value in the database;

the update module 703 is further configured to: and replacing the corresponding data value in the database by the data value of the target data point.

In an exemplary embodiment, based on the foregoing solution, the apparatus 700 for entering data further includes: a fifth pre-judging module and an enqueue module.

Wherein the fifth prediction module is configured to: determining whether the target data entry contains a preset mark before determining whether the data value of the current data entry is the same as the data value of the target data entry;

the enqueue module is configured to: and in response to the target data entry containing a preset mark, storing the data of the target data entry and the data of the current data entry into a target queue, and keeping the data value of the target data entry in the database unchanged.

In an exemplary embodiment, based on the foregoing solution, the apparatus 700 for entering data further includes: the device comprises a mapping relation determining module, an identifier configuring module and an extracting module.

Wherein the mapping relation determining module is configured to: determining a medical record report form (CRF), and determining a mapping relation between a data item of each hierarchy in the CRF and source data; the identifier configuration module is configured to: respectively determining identifiers for unique identification for the data items of each hierarchy; the extraction module is configured to: and extracting data from the source data according to the mapping relation to obtain data values corresponding to the data entries of each hierarchy.

In an exemplary embodiment, based on the foregoing scheme, the CRF includes N levels; the identifier configuration module is specifically configured to: determining a uniquely identified identifier corresponding to a data entry of a first hierarchical level; the identifiers corresponding to the data entries of the (i + 1) th level comprise identifiers of the data entries of the (i) th level, and i is a positive integer smaller than N.

In an exemplary embodiment, based on the foregoing scheme, the extracting module is specifically configured to: and converting the clinical test data of the subject into an Operational Data Model (ODM) format, and extracting data from the source data according to the mapping relation, wherein the data value corresponding to each level of the extracted data conforms to the ODM format.

The specific details of each unit in the above apparatus for entering data have been described in detail in the method for entering data, and therefore are not described herein again.

As will be appreciated by one skilled in the art, aspects of the present disclosure may be embodied as a system, method or program product. Accordingly, various aspects of the present disclosure may be embodied in the form of: an entirely hardware embodiment, an entirely software embodiment (including firmware, microcode, etc.) or an embodiment combining hardware and software aspects that may all generally be referred to herein as a "circuit," module "or" system.

An electronic device 800 according to this embodiment of the disclosure is described below with reference to fig. 8. The electronic device 800 shown in fig. 8 is only an example and should not bring any limitations to the functionality and scope of use of the embodiments of the present disclosure.

As shown in fig. 8, electronic device 800 is in the form of a general purpose computing device. The components of the electronic device 800 may include, but are not limited to: the at least one processing unit 810, the at least one memory unit 820, and a bus 830 that couples the various system components including the memory unit 820 and the processing unit 810.

Wherein the storage unit stores program code that is executable by the processing unit 810 to cause the processing unit 810 to perform steps according to various exemplary embodiments of the present disclosure as described in the "exemplary methods" section above in this specification. For example, the processing unit 810 may execute step S210 shown in fig. 2, and determine whether a target data entry identical to a current data entry already exists in a database according to an identifier of the current data entry to be entered into the database; step S220, responding to the database that the target data item same as the current data item exists, and determining whether the current data item contains a data operation type which is a deletion type; step S230, in response to that the data operation type of the current data entry is a non-deletion type, determining whether the data value of the current data entry is the same as the data value of the target data entry; step S240, in response to that the data value of the current data entry is different from the data value of the target data entry, replacing the data value of the target data entry with the data value of the current data entry, and processing a next data entry to be entered into the database.

The storage unit 820 may include readable media in the form of volatile memory units such as a random access memory unit (RAM)8201 and/or a cache memory unit 8202, and may further include a read only memory unit (ROM) 8203.

The storage unit 820 may also include a program/utility 8204 having a set (at least one) of program modules 8205, such program modules 8205 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.

Bus 830 may be any of several types of bus structures including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

The electronic device 800 may also communicate with one or more external devices 1000 (e.g., keyboard, pointing device, bluetooth device, etc.), with one or more devices that enable a user to interact with the electronic device 600, and/or with any devices (e.g., router, modem, etc.) that enable the electronic device 800 to communicate with one or more other computing devices. Such communication may occur via an input/output (I/O) interface 650. Also, the electronic device 800 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the internet) via the network adapter 860. As shown, the network adapter 860 communicates with the other modules of the electronic device 800 via the bus 830. It should be appreciated that although not shown in the figures, other hardware and/or software modules may be used in conjunction with the electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

In an exemplary embodiment of the present disclosure, there is also provided a computer-readable storage medium having stored thereon a program product capable of implementing the above-described method of the present specification. In some possible embodiments, various aspects of the disclosure may also be implemented in the form of a program product comprising program code for causing a terminal device to perform the steps according to various exemplary embodiments of the disclosure described in the "exemplary methods" section above of this specification, when the program product is run on the terminal device.

Referring to fig. 9, a program product 900 for implementing the above method according to an embodiment of the present disclosure is described, which may employ a portable compact disc read only memory (CD-ROM) and include program code, and may be run on a terminal device, such as a personal computer. However, the program product of the present disclosure is not limited thereto, and in this document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

A computer readable signal medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Program code for carrying out operations for the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device and partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., through the internet using an internet service provider).

It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the present disclosure. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.

Moreover, although the steps of the methods of the present disclosure are depicted in the drawings in a particular order, this does not require or imply that the steps must be performed in this particular order, or that all of the depicted steps must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions, etc.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

Claims

1. A method of entering data, comprising:

determining whether a target data entry identical to a current data entry exists in a database according to an identifier of the current data entry to be recorded into the database;

in response to the database that a target data entry identical to the current data entry exists, determining whether the data operation type of the current data entry is a deletion type;

in response to the data operation type of the current data entry being a non-deletion type, determining whether the data value of the current data entry is the same as the data value of the target data entry;

and in response to that the data value of the current data entry is different from the data value of the target data entry, replacing the data value of the target data entry with the data value of the current data entry, and processing a next data entry to be entered into the database.

2. The method of claim 1, further comprising:

and responding to the data value of the current data entry being the same as the data value of the target data entry, keeping the data value of the target data entry unchanged, and processing the entry operation of the next data entry to be entered into the database.

3. The method of claim 1, further comprising:

in response to no target data entry in the database that is the same as the current data entry, entering data of the current data entry into the database.

4. The method according to any one of claims 1 to 3, further comprising:

and performing logic deletion operation on the data value corresponding to the target data entry in response to the fact that the current data entry contains a data operation type which is a deletion type.

5. The method of claim 2, wherein the current data entry contains a plurality of data points, each of the data points having a corresponding data value; wherein the content of the first and second substances,

the determining whether the data value of the current data entry is the same as the data value of the target data entry comprises: determining whether the data value at each data point of the current data entry is consistent with the data value at the corresponding data point in the target data entry;

the maintaining the data value of the target data entry unchanged in response to the data value of the current data entry being the same as the data value of the target data entry, comprising: discarding the data value corresponding to each data point in the current data entry in response to the data value at each data point in the current data entry corresponding to the data value at the corresponding data point in the target data entry.

6. The method of claim 5, further comprising:

acquiring a target data point in response to the data value on each data point of the current data item being inconsistent with the data value on the corresponding data point in the target data item, wherein the target data point is a data point in the current data item having a data value different from the data value on the corresponding data point in the target data item;

and replacing the corresponding data value in the database by the data value of the target data point.

7. The method of any of claims 1-3, wherein prior to determining whether the data value of the current data entry is the same as the data value of the target data entry, the method further comprises:

determining whether the target data entry contains a preset mark;

and in response to the target data entry containing a preset mark, storing the data of the target data entry and the data of the current data entry into a target queue, and keeping the data value of the target data entry in the database unchanged.

8. The method according to any one of claims 1 to 3, further comprising:

determining a medical record report table (CRF), and determining a mapping relation between a data entry of each level in the CRF and source data;

determining an identifier for unique identification for each level of data entry;

and extracting data from the source data according to the mapping relation to obtain data values corresponding to the data items of each hierarchy respectively.

9. The method of claim 8, wherein the CRF comprises N levels; wherein determining an identifier for unique identification for each of the hierarchy data entries comprises:

determining a uniquely identified identifier corresponding to a data entry of a first hierarchical level;

the identifiers corresponding to the data entries of the (i + 1) th level comprise identifiers of the data entries of the (i) th level, and i is a positive integer smaller than N.

10. The method of claim 8, wherein extracting data from the source data according to the mapping relationship comprises:

and converting the clinical test data of the subject into an Operational Data Model (ODM) format, and extracting data from the source data according to the mapping relation, wherein the data value corresponding to each level of the extracted data conforms to the ODM format.

11. An apparatus for entering data, comprising:

a first anticipation module, configured to: determining whether a target data entry identical to a current data entry exists in a database according to an identifier of the current data entry to be recorded into the database;

a second anticipation module, configured to: in response to the fact that the target data entry which is the same as the current data entry exists in the database, determining whether the current data entry contains a data operation type which is a deletion type;

a third prediction module to: in response to the data operation type of the current data entry being a non-deletion type, determining whether the data value of the current data entry is the same as the data value of the target data entry;

an update module to: and in response to that the data value of the current data entry is different from the data value of the target data entry, replacing the data value of the target data entry with the data value of the current data entry, and processing a next data entry to be entered into the database.

12. A computer-readable storage medium, having stored thereon a computer program;

the computer program, when executed by a processor, implements a method of logging data as claimed in any one of claims 1 to 10.

13. An electronic device, comprising:

a processor; and

a memory for storing executable instructions of the processor;

wherein the processor is configured to perform the method of logging data of any of claims 1 to 10 via execution of the executable instructions.