Claims:CLAIMS
What is claimed is:

1. A method for structuring standardizing and management of records comprising of:

deciphering a logical observation identifiers names and codes for tagging a health parameter obtained from a health record, whereby the health record is converted into a text document and each line relating to the health parameter in the text document is broken down into smaller lines;

validating each of the broken lines to be a lab test line, whereby the first part of each of the lab test line is extracted as a token and separated from a remaining part of the broken line which is separately extracted from the token; and

allocation of an identification to the tokens post matching them with a dictionary housed in the repository by performing a fuzzy search, whereby the identified tokens are allocated the logical observation identifiers names and codes based on the source of the token to decipher the lab test results obtained.

2. The method of claim 1, wherein the numerical results and character based results are stored as separate sets.

3. The method of claim 1, wherein the lines are from at least one of: a header and footer; an empty space; a lab result; comments specified by the diagnostic center through the health document; an irrelevant text to be filtered, and a physician’s name.

4. The method of claim 1, wherein the lines are santized by at least one of: removing special characters; expanding the acronyms; and removing the plural forms.

5. The method of claim 1, wherein the deciphered results are in standardized and digitized format.

6. The method of claim 1, wherein at least one of: age based; gender based; and condition based restrictions are considered for scrutinizing the line.

7. The method of claim 1, wherein manual intervention involves addition of further details.

8. A method for training and predictive analysis of the logical observation identifiers names and codes comprising of:

checking for the accuracy of the accuracy predictions of at least one of: lines; logical observation identifiers names and codes; result of a particular health parameter; and the standardized range for a particular health parameter, whereby the accuracy predictions are checked through a machine learning medium;

training of the algorithm prediction for logical observation identifiers names and codes based on previous digitization history, whereby the percentage of accuracy reflects the aberrations in the predictions; and

feeding the data if the machine learning medium into the accuracy prediction statistics database, whereby the accuracy prediction statistics database predicts the logical observation identifiers names and codes accurate for the given line.

9. The method of claim 8, wherein the accuracy predictions involve comparing identified component with the actual test component.

10. A system for structuring standardizing and management of records comprising of:

a device for input of records coupled with the system through a network being further connected to a device for the output of records in a standardized and digitized format, whereby a repository is configured to store data from a preloaded dictionary;

an interface configured to exchange a data and information from the records, whereby the interface is configured to pull out the data from the repository which is deciphered by the user intending to utilize the data. , Description:DESCRIPTION

TECHNICAL FIELD

[0001] The present disclosure generally relates to the field of information analysis. More particularly the present disclosure relates to the standardizing, consolidation, and digitization of records for obtaining a structured parameter.

BACKGROUND
[0002] Computerised implementation for management of records has been in momentum given the varied scope of records and inefficiency in their management. Management of health records involves voluminous data as the past records also play a significant role in the health care management of the patient. The health records which involve medical data are obtained from plethora of sources. Synchronisation of medical data in variations is a prerequisite. More so, each of the source varies in the acceptable limit of parameters to a certain extent thus leading to inconsistency in format. This leads to issues in compilation, processing and evaluation of the clinical data leading to inconsistency in the health records.

[0003] The records are a combination of alphabets and numbers, thus requiring software algorithms which could deal with such variations. Various algorithms available in the prior art may be used but, structuring and formatting of the data by maintaining accuracy and self-estimation is needed for bringing the various records on a single evaluative platform.

BRIEF SUMMARY

[0004] The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not an extensive overview of the disclosure and it does not identify key/critical elements of the invention or delineate the scope of the invention. Its sole purpose is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.

[0005] Exemplary embodiments of the present disclosure are directed towards a system and method for structuring standardizing and management of records.

[0006] An exemplary object of the present disclosure is directed towards structuring records on a large scale.
[0007] Another exemplary object of the present disclosure is directed towards bringing various formatted records under one platform.
[0008] Another exemplary object of the present disclosure is directed towards structured digital data analysis of records.
[0009] Yet another exemplary object of the present disclosure is directed towards a single view by the user across multiple data of the records obtained.
[00010] An exemplary aspect of the present disclosure is directed towards deciphering a logical observation identifiers names and codes for tagging a health parameter obtained from a lab test results which is converted into a text document and each line relating to the health parameter in the text document is broken down into smaller lines.
[00011] Another exemplary aspect of the present disclosure is directed towards validating each of the broken lines to be a lab test line and the first part of each of the lab test line is extracted as a token and separated from a remaining part of the broken line which is separately extracted from the token.
[00012] Yet another exemplary aspect of the present disclosure is directed towards allocation of identification to the tokens post matching them with a dictionary housed in the repository by performing a fuzzy search, whereby the identified tokens are allocated the logical observation identifiers names and codes based on the source of the token to decipher the lab test results obtained.
BRIEF DESCRIPTION OF DRAWINGS

[00013] Other objects and advantages of the present invention will become apparent to those skilled in the art upon reading the following detailed description of the preferred embodiments, in conjunction with the accompanying drawings, wherein like reference numerals have been used to designate like elements, and wherein:

[00014] FIG. 1 is a schematic diagram for an environment for structuring, standardzing and management of records, according to an exemplary embodiment of the present disclosure.

[00015] FIG. 2 is a flow diagram depicting the process of deciphering a unique logical observation identifiers names and codes (LOINC) for tagging a health document, according to an exemplary embodiment of the present disclosure.

[00016] FIG. 3 is a flow chart depicting the process of lab test line check, according to an exemplary embodiment of the present disclosure.

[00017] FIG. 4 is a flow chart depicting the look ahead process, according to an exemplary embodiment of the present disclosure.

[00018] FIG. 5 is a flow chart depicting the process involved in identification and rectification of optical character recognition (OCR) related mistakes, according to an exemplary embodiment of the present disclosure.

[00019] FIG. 6 is a flow chart depicting the process involving an accuracy predictive analysis, according to an exemplary embodiment of the present disclosure.

[00020] FIG. 7 is a process depicting a step by step digitization of the data, according to an exemplary embodiment of the present disclosure.

DETAILED DESCRIPTION

[00021] It is to be understood that the present disclosure is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the drawings. The present disclosure is capable of other embodiments and of being practiced or of being carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting.

[00022] The use of “including”, “comprising” or “having” and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. The terms “a” and “an” herein do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced item. Further, the use of terms “first”, “second”, and “third”, and the like, herein do not denote any order, quantity, or importance, but rather are used to distinguish one element from another.

[00023] FIG. 1 refers to a schematic diagram 100, for an environment for structuring, standardizing and management of records, according to an exemplary embodiment of the present disclosure. A device for records input 102 is connected to the system 106 by coupling to the network 104. The system 106 is further connected to a device 108 for output of records in a standardized and digitized form. The device 102 may not be limited to a computing device, a desktop, a computer, and the like. The records may not be limited to health records obtained from laboratories, pay rolls data, and/or any other data which demands synchronization. The repository is a place for storage of data not limiting to, a dictionary. The repository may store, alphabets, vocabulary, phrases, sentences, numerals, bibliographic details of the patient, the physician and the like. The interface helps in the exchange of data in the records and/or information from the repository. Interface is configured to obtain and pull out the data from the repository as per the requirement. The standardized and digitized records utilize Logical Observation Identifiers Names and Codes (LOINC) which is a database and universal standard for identifying medical laboratory observations which through heuristic algorithms standardizes a given medical report. The device 108 may not be limited to a computer device, a mobile device, a tablet and the like. The data may be displayed on to the dashboard of the device 108 in a standardized format which would be deciphered by the user.

[00024] FIG. 2 refers to a flow diagram 200, depicting the process of deciphering a unique logical observation identifiers names (LOIN) and codes for tagging a health document, according to an exemplary embodiment of the present disclosure. The process involves identification of LOIN code wherein the numerical results and character based results are stored as two different sets. A regex R is statistical computing tool for matching the results, similarly RNR for matching normal results, and RCR for matching character based results. A document here (referred to as lab reports) may be a health record from a diagnostic center with a single health parameter and/or multiple health parameters. The process commences at step 202 where the document (lab reports) are converted into text documents not limiting to, a PDF document using preexisting software tools to decipher the lab report in a text format. At step 204, the lab reports of step 202 are broken into lines where each line would be dealt separately to obtain the LOINC. The lines may not be limited to, a header and footer, an empty space which does not denote any text, a lab result, any comments specified by the diagnostic center through the lab report, any irrelevant text which needs to be filtered, and the physician’s name. At step 206 each line is tested to validate if it is a lab test line. If the validation to step 206 is yes, then at step 208 the line is broken into name 208a, i.e name of the patient, the lab result 208b obtained which is the lab reading for a specific parameter, and the acceptable range specified in the lab reports 208c. The name 208a, lab result 208b, and the range 208c are broken down into tokens 212 through the process of tokenization 210. The spacing may not be limited to two spaces as a delimiter. The first part of the line is extracted as a token and kept separately and the remaining part of the line is extracted separately. The tokens at step 212 are matched with the dictionary at step 214 housed in the repository (FIG. 1) and a name is allocated to the tokens at step 216, and a LOIN code is obtained for that particular token which in turn shows the source from where it was obtained. The lab results 208b and range 208c utilise of the tool regex at step 220 and 226 respectively, where the lab results 208b are matched with the dictionary at step 222 and then, the lab results utlise the tool regex at step 226 to obtain LOIN code for both the result and range at step 228. If the validation to step 206 is no, then at step 230 it is validated whether the line is a header. If the validation to step 230 is yes, then the name of the patient, gender of the patient, and age of the patient are extracted at step 232. This step is exclusive to header and footer. The age and gender are separated at step 234 and 236 and are connected to step 226 for obtaining a LOINC at step 228. If the validation to step 230 is no, then, it is validated at step 238 whether they are lab comments. If the validation to step 238 is yes, then the lab comments are retained at step 240. If the answer to validation at step 238 is no, then it is deciphered as a doctor line at step 242 from where the name of the doctor and/or physician is extracted at step 244.

The steps involving the identification of LOIN code for a given lab result include:
Step 0: Sanitizing the lines by removing special characters, expanding the acronyms and removing all the plural forms.
Step 1: When line L is given, the tokens L[0]...L[n] are calculated.
Step 2: For every token K dictionary value in RD K is determined and stored in V[K]
Step 3: If V[0] is then no LOIN code is found[ 1][2].............. V[n] ? V ?V ? T
Step 3a: If V[0] is a unique value then LOIN code is returned[ 1] [2].............. V[n] ? V ?V ?
Step 3b: If V[0] is a set S,then the set is examined.[ 1] [2].............. V[n] ? V ?V ?
Step 4: If S contains only one element with a base B, then that element is returned as LOIN code
Step 5: If S contains more than one element with base B, then the element with higher priority (retrieved from Priority list P) is returned as LOIN code for a given string.

[00025] FIG. 3 refers to a flow chart 300, depicting the process of lab test line check, according to an exemplary embodiment of the present disclosure.
a. A line is a lab’s result if:
L ? D & RS regex matches (R)(RS regex matches (RNR) optionally)
L ? DC& RS matches (RCR)
b. The dictionary is housed in the repository that maps the tokens in a lab test component name to a LOIN code.
c. For example:
d. Pair L (loinc code), T(test name) will generate the following dictionary.
e. (T[0],L)(T[1],L,B) (T[2],L) ……….(T[n],L) where T(k) is kth token generated by splitting the string T using space delimiter an optional base LOIN code is added for certain tokens.

[00026] Any line which doesn’t fall under the category of a header and footer, an empty space which does not denote any text, a lab result, any comments specified by the diagnostic center through the lab report, any irrelevant text which needs to be filtered is by default considered as a physician’s name. A priority list P of the tests is also maintained.

[00027] The method for the process of lab test line check commences at step 302 by breaking the lab test line (which has been described in FIG. 2). The line L is broken down into token (T1) and RS (rest of the line). At step 304 the comparing and mapping of the obtained token is done with the dictionary in the repository.

[00028] The token (T1) obtained is compared with the dictionary and mapped with the available options at step 304 to obtain a Loin Code LC at step 306. The dictionary may be not limiting to, words, a group of first alphabets of a text input, numerals, and the like. The regex R (for matching results) is maintained, RNR (for matching normal ranges), RCR (for matching character results). The line (RS) is tested for type checks at step 308. If the reply to the test is yes, then at step 310 the line (RS) is accepted as a lab test line which marks the end of the process at step 316. If the reply to step 308 is no, then at step 312 the line (RS) is considered as a non-lab test line, thus marking the end of the process at step 316.

[00029] FIG. 4 refers to a flow chart 400, depicting the look ahead process, according to an exemplary embodiment of the present disclosure. The process 400 is desirable when there is age and/or gender based restrictions and if the normal ranges are distributed over multiple lines. The process is performed for identifying lab results and the standardized range. The process commences at step 402, by scrutinizing the lines culled put from the records. At step 404, the appropriate line for mapping and obtaining the LOIN code is identified from the record. The step 406 is not just to look at the line which was culled out of the records but also for subsequent scanning of the reminiscent lines in the report till the right observations are obtained and/or till the report is completely scrutinized. It is enquired at step 408 whether the subsequent line is matching with the regular expression software (regex). If the enquiry to step 408 is yes, then the matched lines are stored and extracted and the process reverts to step 406. If the enquiry to step 408 is no, then the process stops at step 410. For every match in the line a normal range is matched with the line with the help of a regex tool. Also, age based, gender based, and condition based restrictions are taken for scrutinizing the line. If no such restrictions are obtained then, normal range is found and reported.

[00030] FIG. 5 refers to a flow chart 500, depicting the process involved in identification and rectification of optical character recognition (OCR) related mistakes, according to an exemplary embodiment of the present disclosure. The process commences at step 502 by identifying a list of tokens which have been obtained by tokenization of the lines. At step 504, a single token is identified which needs to be mapped. At step 506, a fuzzy search is performed by comparing with the list of vocabulary in the repository. For example: in the word FASTING, alphabet F might be confused by E thus making it EASTING. But, the OCR may not confuse F with a distant alphabet W. At step 508 a differentiated weightage may be given to the token and/strings of tokens to identify mistakes committed by the OCR. At step 510, the aberration in the LOIN codes due to the confusion of OCR may be recognized as the LOIN codes obtain would not point to the same result. To fix the aberration in step 510, at step 512, manual intervention may be done by adding more details for accuracy. The process concludes at step 514 by obtaining an accurate LOIN code.

[00031] Upon the digitization of the reports the values not limiting to, actual line (in the lab report), identified test (component name), identified test component LOIN code, identified lab results , identified normal range, age, gender, and the like are recorded.

[00032] The following values will be manually compared against the actual document(FIG.2)by not limiting to, a quality analyst for recording the components in the following table:

Actual Line
Identified test component name Actual Test Component Name
Identified test component LOIN code Actual Test Component LOIN code
Identified Lab result Actual Test Component Lab result
Identified Normal Range Actual Test Component Normal Range
IdentifiedAge Actual Test Component Age
Identified Gender Actual Test Component Gender

The calculated accuracies will be compared against threshold for future reports to determine as to a second review is needed for a given report.

[00033] FIG. 6 refers to a flow chart 600, depicting the process involving training and an accuracy predictive analysis, according to an exemplary embodiment of the present disclosure. The algorithmic calculations are vulnerable to aberrations. These aberrations may also call for human intervention when needed. The process commences at step 602 which has lines, LOIN codes, result and the standardized range. It is checked whether the prediction is correct and/or wrong by the information (given in the table in FIG. 5) fed into an online machine learning model (Support Vector Machine) as training data. The accuracy of the results and range is checked at step 604. P1 at step 606 is an algorithm prediction of LOIN code which at step 608 undergoes determination of higher accuracy prediction, and finally at step 610 the prediction is utilized. P1 is trained based on previous digitization history. For example: if for a particular medical condition L1 (LOIN code 1) success rate had 95% accuracy and L2 (LOIN code 2) for the same line had success rate of 99% then, L2 is suggested and the prediction history would reflect the faulty prediction in its history. The data in the machine learning model at step 612 further gets fed into the accuracy prediction statistics database 614 which goes to P2 which is the machine learning model’s prediction of LOIN code of the initially given line.

[00034] The model will output the following:
1) Accuracy of identification of lab result line.
2) Accuracy of identification of test component LOIN code using test component’s name. Accuracy of identification of testcomponent LOIN code will be used to model to predict the LOIN code for a given test component name.

[00035] FIG. 7 refers to a process 700, depicting a step by step digitization of the data, according to an exemplary embodiment of the present disclosure. The step starts at 702 where a text of the blood report’s one of the parameter. Step 702 in the figure represents the blood test basic details like: GLUCOSE - SERUM / PLASMA (POST PRANDIAL) 85.00 70-140 mg/dl Method Glucose Oxidase-Peroxidiuo. This describes the basic details not limited to name of the test, the value of the result obtained, the range prescribed and the method used to perform the test. At step 704 the preprocessing of the result obtained is done which includes the following sub steps:
? line1 => "GLUCOSE - SERUM / PLASMA (POST PRANDIAL) 85.00 70-140 mg/dl "
? line => "glucose - serum / plasma post prandial 85.00 70-140 mg/dl "
? regex_line => "glucoseserumplasmapostprandial850070140mgdl"
? specimen_type => "plasma"
? formatted => "glucose - serum / plasma post" prandial 85.00 70-140 mg/dl
? is_lab_result_line => [true, 1, nil]
? normalized_specimen_type => "plasma"

In the above process the use of regex ensures the removal of special characters and ensures the entire line is reflected as a single unbroken string.

The extraction in the form of tokens, formatted lines, and the result obtained in particular is done at step 706 as follows:
? tokens => ["glucose - serum / plasma post prandial", " 85.00", " 70-140", " mg/dl"]
? formatted_line => "glucose - serum / plasma post prandial 85.00 70-140 mg/dl "
? char_value => nil ? number_value => "85.00"
? result => "85.00"

Step 708 involves the identification of an appropriate LOIN code for the specific test performed. The example is as follows:

?test_component => "glucose - serum / plasma post prandial"
? test_component(after processing) => "glucose serum / plasma post prandial"
? word_keys => ["glucose", "serum", "/", "plasma", "post", "prandial"]
? word_hash => {"glucose"=>{:tokens=>["4548-4-D","53553-4","1521-4","41604-0","50212-0","502 13-8","50214-6","12646-6","EKC-GTT-PG-02","EKC-GTT-PG-01","32546-4","234 5-7"]},"/"=>{:tokens=>["1759-0","3097-3","44734-2","9830-1","11054-4","1920-8"," 1742-6","6768-6","4544-3","14030-1","1874-7","44716-9","9321-1","EKC-GTT-PG -02","9318-7","65987"]},"plasma"=>{:tokens=>["1521-4","41604-0","50212-0","50 213-8","50214-6","EKC-CBP-PC-02","EKC-GTT-PG-02","EKC-GTT-PG-01","529 2-8","53553-4","2345-7"]},

? "post"=>{:tokens=>["1521-4"]}, ? "prandial"=>{:tokens=>["1521-4"]}} ? loinc_final => "1521-4"

Hence, the LOIN code obtained for glucose serum plasma post prandial test is “1521-4”.

Step 710 deals with the extraction of the medically acceptable range for the glucose serum plasma post prandial test.
? last_bit => "0 70-140 mg/dl "
? range => "70-140"
? range(after processing) => ",70-140,,,”
The step 712 deals with the output of the entire test giving out the details of the test conducted, specimen obtained, report date, sample date, and the like without limiting the scope of the disclosure. The output may be represented as follows:

Output: {:lonic_code=>"1521-4", :result=>"85.00", :range=>",70-140,,,", :name=>"glucose - serum / plasma post prandial", :specimen=>"plasma", :report_date=>"", :sample_date=>""}

[00033] The above description of FIG. 7 is an example but is extendible to other medical tests not limiting to. ELISA, HIV/AIDS test, Liver function test, Kidney function test, and the like.

[00034] Although the present disclosure has been described in terms of certain preferred embodiments and illustrations thereof, other embodiments and modifications to preferred embodiments may be possible that are within the principles and spirit of the invention. The above descriptions and figures are therefore to be regarded as illustrative and not restrictive.

[00035] Thus the scope of the present disclosure is defined by the appended claims and includes both combinations and sub combinations of the various features described herein above as well as variations and modifications thereof, which would occur to persons skilled in the art upon reading the foregoing description.