embodiments of the invention provide techniques for extracting specific data elements as a result of automated speech recognition of medical dictations . for example , an automatic speech recognition ( asr ) system is supplemented by natural language processing , constrained by one or more tables of data elements for locating relevant information in the dictation . the natural language processing analyzes the dictation and extracts data according to the desired table , preferably without interaction with the speaker and preferably without the speaker dictating the data for the table in any particular sequence . the extracted data may be presented along with original audio , to a medical transcriptionist ( mt ) for editing . other embodiments are within the scope of the invention . referring to fig1 , a system 10 for transcribing audio and editing transcribed audio includes a speaker / person 12 , a communications network 14 , a voice mailbox system 16 , an administrative console 18 , an editing device 20 , a communications network 22 , a database server 24 , a communications network 26 , a model builder / modifier 29 , and an automatic transcription device 30 . here , the network 14 is preferably a public switched telephone network ( pstn ) although other networks , including packet - switched networks could be used , e . g ., if the speaker 12 uses an internet phone for dictation . the network 22 is preferably a packet - switched network such as the global packet - switched network known as the internet . the network 26 is preferably a packet - switched , local area network ( lan ). other types of networks may be used , however , for the networks 14 , 22 , 26 , or any or all of the networks 14 , 22 , 26 may be eliminated , e . g ., if items shown in fig1 are combined or eliminated . as discussed below , the model builder / modifier 29 is configured to build and / or modify models ( e . g ., trigger models , content models , order models ) used to accurately extract the requested data fields from the transcription . preferably , the voice mailbox system 16 , the administrative console 18 , and the editing device 20 are situated “ off site ” from the database server 24 and the automatic transcription device 30 . these systems / devices 16 , 18 , 20 , however , could be located “ on site ,” and communications between them may take place , e . g ., over a local area network . similarly , it is possible to locate the automatic transcription device 30 off - site , and have the device 30 communicate with the database server 24 over the network 22 . the network 14 is configured to convey dictation from the speaker 12 to the voice mailbox system 16 . preferably , the speaker 12 dictates into an audio transducer such as a telephone , and the transduced audio is transmitted over the telephone network 14 into the voice mailbox system 16 , such as the intelliscript ™ product made by escription ™ of needham , mass . the speaker 12 may , however , use means other than a standard telephone for creating the digital audio file for each dictation . for example , the speaker 12 may dictate into a handheld pda device that includes its own digitization mechanism for storing the audio file . or , the speaker 12 may use a standard “ dictation station ,” such as those provided by many vendors . still other devices may be used by the speaker 12 for dictating , and possibly digitizing the dictation , and sending it to the voice mailbox system 16 . the voice mailbox system 16 is configured to digitize audio from the speaker 12 to produce a digital audio file of the dictation . for example , the system 16 may use the intelliscript ™ product made by escription . the voice mailbox system 16 is further configured to prompt the speaker 12 to enter an identification code and a worktype code . the speaker 12 can enter the codes , e . g ., by pressing buttons on a telephone to send dtmf tones , or by speaking the codes into the telephone . the system 16 may provide speech recognition to convert the spoken codes into a digital identification code and a digital worktype code . the mailbox system 16 is further configured to store the identifying code and the worktype code in association with the dictation . the identification code can associate the dictation with a particular speaker and / or an entity associated with the speaker ( e . g ., the speaker &# 39 ; s employer or affiliate hospital , etc .). speakers with multiple affiliations ( e . g ., to different entities such as hospitals ) preferably have multiple identification codes , with each identification code corresponding to a respective one of the affiliated entities . the system 16 preferably prompts the speaker 12 to provide the worktype code at least for each dictation related to the medical field . the worktype code designates a category of work to which the dictation pertains , e . g ., for medical applications this could include office note , consultation , operative note , discharge summary , radiology report , etc . the worktype code may be used to define settings such as database fields and / or to refine settings , such that settings may be specific not only to speaker - transcriptionist pairings , but further to worktype of dictations provided by the speaker , and / or to other parameters or indicia . the voice mailbox system 16 is further configured to transmit the digital audio file and speaker identification code and worktype code over the network 22 to the database server 24 for storage . this transmission is accomplished by the system 16 product using standard network transmission protocols communicating with the database server 24 . the database server 24 is configured to store the incoming data from the voice mailbox system 16 , as well as from other sources , in a database 40 . the database server 24 may include the editscript ™ database product from escription . software of the database server is configured to produce a database record for the dictation , including a file pointer to the digital audio data , and a field containing the identification code for the speaker 12 . if the audio and identifying data are stored on a pda , the pda may be connected to a computer running the handiscript ™ software product made by escription that will perform the data transfer and communication with the database server 24 to enable a database record to be produced for the dictation . the database 40 stores a variety of information regarding transcriptions . the database 40 stores the incoming data from the voice mailbox system 16 , the database record produced by the database software , data fields associated with transcriptions , etc . the data fields are stored in a tabular data fields section 41 , of the database 40 , that includes sets of data fields associated with particular transcriptions . these fields may be accessed by the automatic transcription device 30 , e . g ., for storing data in the fields , or the administration console 18 , e . g ., for searching the fields for particular information . preferably , all communication with the database server 24 is intermediated by a “ servlet ” application 32 that includes an in - memory cached representation of recent database entries . the servlet 32 is configured to service requests from the voice mailbox system 16 , the automatic transcription device , the editing device 20 , and the administrative console 18 , reading from the database 40 when the servlet &# 39 ; s cache does not contain the required information . the servlet 32 includes a separate software module that helps ensure that the servlet &# 39 ; s cache is synchronized with the contents of the database 40 . this helps allow the database 40 to be off - loaded of much of the real - time data - communication and to grow to be much larger than otherwise possible . for simplicity , however , the below discussion does not refer to the servlet , but all database access activities may be realized using the servlet application 32 as an intermediary . the automatic transcription device 30 may access the database in the database server 24 over the data network 26 for transcribing the stored dictation . the automatic transcription device 30 uses an automatic speech recognition ( asr ) device ( e . g ., software ) to produce a draft transcription for the dictation . an example of asr technology is the autoscript ™ product made by escription , that also uses the speaker identifying information to access speaker - dependent asr models with which to perform the transcription . the device 30 transmits the draft transcription over the data network 26 to the database server 24 for storage in the database and to be accessed , along with the digital audio file , by the editing device 20 . the editing device 20 is configured to be used by a transcriptionist to access and edit the draft transcription stored in the database of the database server 24 . the editing device 20 includes a computer ( e . g ., display , keyboard , mouse , monitor , memory , and a processor , etc . ), an attached foot - pedal , and appropriate software such as the editscript client ™ software product made by escription . the transcriptionist can request a dictation job by , e . g ., clicking an on - screen icon . the request is serviced by the database server 24 , which finds the dictation for the transcriptionist , and transmits the corresponding audio file and the draft transcription text file , as stored in the database . the transcriptionist edits the draft using the editing device 20 and sends the edited transcript back to the database server 24 . for example , to end the editing session the transcriptionist can click an on - screen icon button to instruct the editing device 20 to send the final edited document to the database server 24 via the network 22 , along with a unique identifier for the transcriptionist . with the data sent from the editing device 20 , the database in the server 24 contains , for each dictation : a speaker identifier , a transcriptionist identifier , the digital audio signal , and the edited text document . the edited text document can be transmitted directly to a customer &# 39 ; s medical record system or accessed over the data network 22 from the database by the administrative console 18 . the console 18 may include an administrative console software product such as emon ™ made by escription . the raw and edited versions of a transcription may be used by the model builder / modifier 29 to models for data extraction . the raw and edited versions of transcriptions associated with their respective speakers are stored in the database 40 . the model builder / modifier 29 uses the transcriptions for each speaker to build or modify models for the speaker ( and / or speaker and worktype ) for extracting data from transcriptions . these models are stored in the database 40 so that they may be accessed and used by the automatic transcription device 30 to extract data from transcriptions . referring also to fig2 , the automatic transcription device 30 includes an asr module 31 , a memory 44 , and a natural language processing module ( nlp ) 42 . the nlp module 42 includes memory and a processor for reading software code stored in the memory and for executing instructions associated with this code for performing functions described below . the nlp module 42 is configured to analyze raw transcribed speech data from the automatic transcription device 30 to extract data elements from the transcribed text , and possibly use the extracted data to fill in a table or database fields . the memory 44 includes a raw / modified text section 46 , a table section 48 , and a trigger section 50 . the raw / modified text section 46 includes the stored raw text of the speech - recognized transcription and the corresponding text as modified by the nlp module 42 . the table section 48 includes stored tables that may be desired to be filled in with data extracted from various transcriptions . the trigger section 50 includes triggers corresponding to particular types of data desired to be extracted from the transcriptions in accordance with the tables stored in the table section 48 . trigger models may be built and / or modified by the model builder / modifier 29 ( fig1 ). referring to fig3 , an exemplary database 82 of tabular data stored in the tabular data fields section 41 of the database 40 ( fig1 ) associated with corresponding transcriptions includes data sets 84 with dictation identifications 85 and several data fields , here data fields 86 , 88 , 90 , 92 , 94 , 96 . the dictation identification is uniquely associated with a corresponding dictation and the data fields are preferably in sets corresponding to the type of transcription , e . g ., here being for medical record transcriptions . thus , in this example , the database 82 includes data sets 84 each with data in an age data field 86 , a gender data field 88 , a date of birth ( dob ) data field 90 , a resting respiration data field 92 , a resting pulse data field 94 , and a resting blood pressure data field 96 . the data fields 86 , 88 , 90 , 92 , 94 , 96 are searchable , e . g ., using known database search techniques on the database 82 . the data sets 84 each correspond to a separate transcription and the corresponding data fields are populated with the data extracted from the associated transcription . information stored in the data fields 86 , 88 , 90 , 92 , 94 , 96 may be extracted from transcriptions and / or entered independently ( e . g ., through the administration console 18 shown in fig1 ). referring again to fig1 - 2 , the nlp module 42 is configured to access a table to be filled in with data extracted from a transcription . for example , the nlp module 42 can access a particular table from the table section 48 in accordance with the worktype code entered by the speaker . other techniques , however , may be used to determine which table to access to be filled in with data extracted from the transcription . for example , one or more tables may be associated with a particular speaker through the identification code , or tables may be accessed in accordance with a combination of identification code and worktype code , or worktype code alone , etc . fields of the table ( s ) accessed by the nlp module 42 are associated with corresponding “ trigger ” phrases stored in the trigger section 50 . a trigger phrase provides context for data and may include a single word or character ( e . g ., a symbol such as a number sign (#), the symbol for feet (′), or the symbol for inches (″)), multiple or characters , or combinations of one or more words and one or more characters . a trigger phrase indicates that the transcription likely contains desired data in the vicinity of the trigger phrase . the trigger phrases may be stored in sets that are associated with corresponding ones of the tables in the table section 48 , or may be stored individually and associated with any table that includes a field corresponding with the particular trigger phrase , etc . the trigger phrases may be predictive , ( e . g ., “ the blood pressure is ______ ”), retroactive ( e . g ., ______ beats per minute ”), or both ( e . g ., “ temperature is ______ degrees orally ”). several passes can be made over the transcribed text by the nlp module 42 to refine the search for table data , especially if the nlp module 42 is operating as a background asr , and is therefore not operating as a real - time interactive processing module . the nlp module 42 may assess the tabular data fields to be filled in or data otherwise to be extracted from the transcription based on various probabilities that the data corresponds to desired table or other data to be extracted , potentially both of the data field in question as well as other data fields . the nlp module 42 may use the trigger phrases in a variety of manners in order to extract data from the transcription , preferably to help improve the accuracy with which data are extracted from the transcription . for example , the triggers may be probabilistically weighted based on various parameters such as speaker - specific or speaker - independent textual data . for example , a different trigger phrase may be associated with a number of different table items potentially , with different likelihoods associated with the different potential table items . the different probabilities associated with the different data items may be speaker independent or speaker dependent . for example , given the existence of a trigger phrase in the transcription of “ the patient is ,” the subsequent data may be the age with 80 % probability , or height with 15 % probability , or appearance with 5 % probability . these probabilities are exemplary , and may be different in practice , especially for different speakers . further , the nlp module 42 may train trigger phrases using natural asr raw data output so that the trigger phrases can incorporate or accommodate typical errors . usually , such a trigger model would be a speaker - specific model . additionally , the nlp module 42 may use a single trigger phrase to extract data for multiple data fields . for example , a medical care provider may dictate “ vital signs one hundred over sixty , eighty - two and regular .” the nlp module 42 may analyze the use of the trigger phrase “ vital signs ” as an indicator of both blood pressure and pulse . the nlp module 42 is further configured to analyze the transcription in view of a content model to help modify transcribed text into common formats , taking account of different manners in which different speakers may say the same thing . the nlp 42 can thus make the format of various types of data be presented consistently despite inconsistent manners in which the data is spoken . for example , one speaker may say “ the patient &# 39 ; s temperature was one hundred and one point three degrees ” while another speaker may say “ the patient &# 39 ; s temperature was one oh one three .” the data , the patient &# 39 ; s temperature of 101 . 3 ° f . is the same , but the text is different in these two examples . the nlp module 42 applying a content model built and / or modified by the model builder / modifier 29 can analyze these two different texts and modify the transcription to produce a consistent edited text , e . g ., of 101 . 3 ° f . examples of different styles of speech for conveying similar information that the nlp module 42 can preferably make consistent are : the content model can accept the speaker saying ninety , or some form of a hundred , followed by either a digit , or the word point followed by a digit . the content model would further be able to identify digits ( e . g ., “ zero ” and “ oh ”) and distinguish between digits and non - digits ( e . g ., “ two ” versus “ too ”). the content model can accept various manners for specifying month , day , and year . the content model can recognize numeric or name specifications of months ( e . g ., “ three ” versus “ march ”) and various manners of specifying days ( e . g ., “ five ” versus “ fifth ”) and years ( e . g ., “ oh five ” versus “ two thousand five ” versus “ two thousand and five ”) as well as month - year combinations ( e . g ., “ march two thousand five ” versus “ march of two thousand five ”). preferably , the nlp module 42 can apply the content model to these various texts to deduce the underlying data and present the underlying data in a consistent manner for each of the exemplary pairs of alternate expressions shown , as well as other alternative texts for conveying the same data , or other data or data types ( i . e ., the examples shown are exemplary only , not exclusive , and not required ). content models provided by the model builder / modifier 29 can be based on allowable grammars . per - speaker probabilities can be assigned to “ paths ” through a grammar based on how the speaker dictates each data type . the model builder / modifier 29 can compute these probabilities and build / modify the content models using these probabilities , preferably offline . the nlp module 42 may also apply syntax constraints to the asr output associated with particular types of data . applying these constraints can help resolve ambiguity when the same trigger phrase is potentially used to indicate different types of data . for example , if a trigger phrase could be used to indicate either a pulse or a respiratory rate , then the nlp module 42 prefers pulse if the transcription contained a numeric quantity greater than 30 and a respiratory rate otherwise . thus , the nlp module 42 applies constraints based on known characteristics and / or likely values ( e . g ., ranges ) of the various parameters or data types that the data may be in order to select which data type corresponds to particular data in a transcription . further , the syntax constraints may lead to content models not employing non - absolute probabilities ( i . e ., probabilities greater than 0 % and less than 100 %) for some or all instances associated with the models . for example , to evaluate a transcription for a blood pressure value , if the transcription does not contain text in the form of a first number , followed by the word “ over ,” followed by a second number that is smaller than the first , then the model would not assign a value to a blood pressure variable . this may , however , be viewed as a 0 % probability and thus an implementation of probabilities . if the first number “ over ” second number syntax is found , then the value for blood pressure would be hypothesized , with the probability of this being true being computed from the trigger model and order model ( discussed below ). further , the nlp module 42 is configured to use information about the subject of the transcription ( e . g ., a patient ) available from the transcription or otherwise to constrain the search for given data types . for example , the transcription may indicate , or it may be otherwise known that ( e . g ., independently entered or determined that ), the patient is a 47 - year old male . in this case , certain values for the patient &# 39 ; s weight and height would be deemed more likely to be correct if they comport with values for these data types typically associated with a 47 - year old male . for example , a value of higher than 60 inches may be deemed to be more likely to be indicative of the patient &# 39 ; s height and a value of 120 or more may be deemed to be more likely to be associated with the patient &# 39 ; s weight . additionally , the data search process performed by the nlp module 42 could be supplemented by providing access by the nlp module 42 to the patient &# 39 ; s historical data from medical records , e . g ., stored in the database 40 . this information could be obtained either by having the speaker enter a patient - identifying code ( such as the patient &# 39 ; s medical record number ( mrn )) with each dictation or by extracting this information from the spoken dictation , etc . once the patient identification is obtained , the nlp module 42 may query the patient &# 39 ; s historical medical data , and use this data to limit or constrain searches for valid content words ( i . e ., the words indicative of data values ). for example , the search for blood pressure , cholesterol values , birth date , height , weight , etc . could benefit from constrained searches based upon information about the patient . the nlp module 42 may further employ a model when analyzing the transcription in accordance with the order in which the speaker dictates the table fields and expected orders for such dictations . for example , the nlp module 42 may employ an n - gram formulation to analyze the n previous data fields that were extracted and determine a probability for the next data field being any of various potential data fields . thus , the nlp module 42 employing a 3 - gram formulation can determine the likelihood that the speaker is about to dictate the blood pressure field conditioned on the preceding two fields dictated being the patient &# 39 ; s pulse and respiratory rate . this model may be deterministic and thus require a specific sequence of data fields or may be non - deterministic / probabilistic , not requiring a particular sequence of data fields . such a model assists the search by attributing a probability to each possible dictation sequence to increase the likelihood that particular data in the transcription is accurately extracted from the transcription , e . g ., and stored in an appropriate data field and / or table entry . the model builder / modifier 29 may produce custom trigger models for use in analyzing the transcription . for example , the database 40 may contain the history of text documents produced from the speaker &# 39 ; s dictations , as well as the automatic transcriptions of the speaker &# 39 ; s dictations provided by the automatic transcription device 30 . the trigger phrases and content word syntax for each data type dictated by the speaker can be derived by correlating the final documents with the raw transcriptions , in effect reversing the decoding process to determine trigger phrases from the content words used by the speaker . the trigger models used by the nlp module 42 can be updated , e . g ., periodically , as more dictations are gathered for the speaker over time . in this way , the models can track changes in the speaker &# 39 ; s speaking style . the nlp module 42 preferably uses the updated model for the next transcription to be analyzed from the particular speaker . the nlp module 42 , however , could re - evaluate a transcription from the speaker that was the last transcription analyzed before the trigger model was updated ( e . g ., the transcription that induced the update in the trigger model ). further , the model builder / modifier 29 may weight more recent transcriptions from the speaker more heavily than earlier transcriptions to help account for changes in the speaker &# 39 ; s style . further , the nlp module 42 may not fill all of the data fields desired to be extracted ( e . g ., associated with a particular table at issue ), as the speaker may not dictate data corresponding to all of the data fields and / or may not dictate the data with sufficient confidence that the nlp module 42 fills all the data fields . for example , the nlp module 42 may not fill a data field associated with a table if data from the transcription has an undesirably low probability of being associated with a particular data field . thus , the nlp module 42 may leave the raw text of the transcription in tact and not fill a data field if the highest probability of data in the transcription being associated with that data field does not meet or exceed a threshold probability value . in this case , the “ free text ” form of the transcription may be left alone such that the mt can choose to move data from the text into a particular data field ( e . g ., in a table ) as appropriate . the nlp module 42 thus can provide a sparse data extraction process where the speaker may not dictate all desired data items or may not dictate all desired data items with sufficient confidence for the nlp module 42 to associate the dictated data with particular data fields . referring also to fig4 , the table structure may be encoded or stored as a combination of literal text and data - type tags , e . g ., tags 60 - 73 as shown . the data - type tags 60 - 73 may be limited in any variety of manners , e . g ., with underscores on either side of the tags 60 - 73 as shown in fig4 to separate the tags 60 - 73 from the literal text . fig4 illustrates a portion 80 of an exemplary encoded table and is not limiting of the invention . the nlp module 42 attempts to replace all of the data - type tags 60 - 73 in the table portion 80 with appropriate data items extracted from the transcription . the nlp module 42 further attempts to exclude the raw text associated with these items from which the data for the corresponding data fields is drawn . the transcription is thus edited to remove the text indicative of the data , and the table portion 80 is updated with the data extracted from the raw text . the table portion 80 illustrates the generality of potential table data fields . the table fields need not be restricted to numeric data . for example , descriptive data may be appropriate for some of the fields ( e . g ., the _s1_s2_status field 71 may have a value of “ normal ”). other fields may be filled with other text including full paragraphs ( e . g ., the _conclusion_field 73 may have a value of “ this is a problematic test . the patient should be considered for cardiac angiography in the next few days .”). referring to fig5 , with further reference to fig1 - 2 , a process 110 of performing sparse data extraction using system 10 , and in particular the nlp module 42 , includes the stages shown . the process 110 , however , is exemplary only and not limiting . the process 110 can be altered , e . g ., by having stages added , removed , or rearranged . at stage 112 , dictation is obtained and transcribed . the speaker 12 dictates text that is conveyed through the network 14 to , and stored in , the voice mailbox 16 . the dictation is conveyed through the network 22 , the database server 24 , and the lan 26 to the automatic transcription device 30 . the device 30 transcribes the stored dictation and provides the transcribed text to the memory 44 where it is stored in the raw / edited text section 46 . at stage 114 , the nlp module 42 determines the desired data for extraction . for example , if the data to be extracted corresponds to a table , then the nlp module 42 accesses the appropriate table from the table section 48 of the database 40 . the nlp module 42 accesses the appropriate table , e . g ., by searching for a table corresponding to the worktype code and / or the identification code entered by the speaker 12 or transcribed from the dictation from the speaker 12 . the table that is accessed provides indicia of the data fields to be extracted from the transcription for filling in the table , with the data fields being associated with corresponding trigger phrases . at stage 116 , the nlp module 42 searches for triggers in the raw transcription corresponding to the data desired to be extracted and extracts the data . for each data type desired by the table , the raw text transcription is searched by the nlp module 42 for potential triggers , and the adjacent content words are assigned likelihoods for being one or more of the desired data fields based on the posterior trigger probability and the syntax likelihood of the content words . multiple possible parses of the raw text transcription are scored and preferably the best fit between the table structure and the trigger and content words is found . for each data type accounted for in the best - fit parse , the corresponding table fields are filled in and the corresponding trigger and content words are removed from the raw text transcription . the best - fit may be a table - wide best fit , a partial - table best fit , or may be the best fit for each individual data field . the following example is provided to illustrate multiple potential parses being applied to a portion of transcribed text for determining data fields . a portion of an exemplary raw text transcription may read : this is a cardiac stress test on john doe that lasted 37 minutes . he is 46 - year - old male . i don &# 39 ; t have the date of birth available at this time . the test was performed at 11 : 00 a . m . where the patient &# 39 ; s pulse was measured at 87 bpm . bp 150 / 85 . after 20 minutes , rate was up to 145 . s1 / s2 normal . the other heart sounds were normal . two exemplary potential parses for this transcription fragment are as follows : a ) this is a cardiac stress test on john doe which lasted 37 minutes . trigger_patient_age_patient_age_ . male . i don &# 39 ; t have the date of birth available at this time . trigger_test_start_test_start_trigger_resting_pulse — — resting_pulse_trigger_resting_bp_resting_bp_ . after twenty minutes , trigger_peak_pulse_peak_pulse_ . trigger_s1_s2_status — — s1_s2_status_ . the other heart sounds were normal . b ) this is a cardiac stress test on john doe trigger_test_duration_test_duration_ . he is a 46 - year - old male . i don &# 39 ; t have the date of birth available at this time . trigger_test_start — — test_start_trigger_peak_pulse — — peak_pulse_trigger_resting_bp — — resting_bp_ . after twenty minutes , rate was up to 145 . trigger_s1_s2_status_s1_s2_status_ . the other heart sounds were normal . in these parses , where a trigger phrase or data type is hypothesized , the underlying raw text words appearing in the transcription raw text ( either the trigger phrase or content words ) are subsumed , so that they do not appear in the document as hypothesized . also , each trigger phrase and data type in the parses has an associated probability , so that standard search techniques , such as viterbi decode , may be applied to the entire sequence to try to find the parse with the higher / highest overall probability . if the first parse is chosen as the more likely parse by the search , then the corresponding section of the output might appear as follows : patient age : 46 patient gender : ______ patient dob : ______ time of test : 11 : 00 a . m . duration of test : ______ resting pulse rate : 87 peak pulse rate : 145 resting respirations : ______ peak respirations : ______ resting blood pressure : 150 / 85 peak blood pressure : ______ s1 / s2 : normal . s3 / s4 : ______ this is a cardiac stress test on john doe which lasted 37 minutes . male . i don &# 39 ; t have the date of birth available at this time . after twenty minutes , the other heart sounds were normal . the text below the dash line is fragmented because trigger phrases and content words have been removed . this text can be used by the transcriptionist to potentially ease the task of filling in any data fields not filled in automatically by the nlp module 42 . alternatively , the text below the dashed line could be deleted , with the mt filling in the remaining fields that have been dictated by the speaker using the audio played to the mt . alternatively still , some of the text may be deleted while other portions of the text may be provided to the mt . for example , the phrase “ after twenty minutes ” may possibly be removed as this text portion is a sentence fragment . the draft transcription at this point is a modified ( from the raw text ), partially - structured , transcription ready for uploading . the modified transcription includes a structured document , to the extent it has been filled in by the nlp module 42 , and the remaining raw text , to the extent that it has been deemed worth including in the draft . subsequent formatting steps can be applied to the remaining raw text , that may include text that does not contribute to the structured part of the document . the draft in this stage is preferably uploaded to the database 40 . at stage 118 , the draft transcription is edited by the medical transcriptionist . the mt retrieves the draft transcription stored in the database 40 via the network 22 . the mt edits the draft transcription using the editing device 20 . this editing includes modifying data that was extracted from the transcribed text , e . g ., including modifying data entries for a table . further , the editing may include adding information that was not extracted from the text , including adding data to the table where data was not dictated corresponding to one or more data fields . at stage 120 , the extracted and / or edited and / or added data is stored in the appropriate database fields . the extracted or otherwise provided data from the editing device 20 is stored in corresponding database fields in the tabular data field section 41 of the database 40 . for example , age , gender , date of birth , resting respiration , resting pulse and / or resting blood pressure is stored in the corresponding database fields 86 , 88 , 92 , 94 , 96 in an appropriate entry 84 of the database 82 . the database fields and the data in these fields may be accessed separately , including independently of the nlp module 42 . at stage 122 , trigger phrases are customized by the model builder / modifier 29 . the edited transcription can be compared by the nlp module 42 with the draft transcription provided by the nlp module 42 to determine whether data determined by the nlp module 42 corresponding with a particular data field was changed by the medical transcriptionist . using this information , the nlp module 42 can modify the trigger phrases and / or models used to associate the extracted data with the corresponding data fields . thus , trigger phrases and / or trigger models can be modified to accommodate changes in style of speakers and / or trigger phrases used by the speaker , or multiple speakers associated with a common entity , etc . the nlp module 42 would then apply the modified trigger phrases and / or trigger models and / or other models provided / modified by the model builder / modifier 29 ( or otherwise provided , e . g ., stored in the memory 44 ) to future analyses of transcriptions to perform sparse data extraction on the transcriptions . the process 110 can be modified and , as such , the process illustrated in fig5 as described above is illustrative only . for example , the extracted data may be stored before the transcription is edited by the medical transcriptionist and the data modified , if at all , by the medical transcriptionist and re - stored subsequent to the transcription editing . referring to fig6 and with further reference to fig1 - 3 , process 130 of searching for data associated with desired data types using the system 10 includes the stages shown . the process 130 , however , is exemplary only in not limiting . the process 130 can be altered , e . g , by having stages added , removed or rearranged . at stage 132 , a request for a data search is received . a user can enter a data search request through the administration console 18 . for example , a healthcare provider might use a software application that queries the database 40 for all of the patient &# 39 ; s peak pulse values for cardiac stress tests taken over a period of time . alternatively , healthcare researchers may ask for the blood pressure values of numerous patients so that the researcher might judge the efficacy of a certain treatment regimen . the data request is forwarded through the network 22 to the database server 24 to be performed on the information stored on the database 40 . at stage 134 , an inquiry is made as to whether data of the data types to be searched for are stored in separate data fields separate from transcriptions stored in the database 40 . in particular , the database server 24 can determine whether database fields corresponding to the data types to be searched are stored in the database 40 . if not , then the process 130 proceeds to stage 138 described below and otherwise proceeds to stage 136 . at stage 136 , the database server 24 searches the stored database fields for data corresponding to the search request . the server 24 searches through stored data , e . g , the database 82 for data corresponding to data types indicated by the search request . for example , the server 24 may search for data corresponding to age , gender , and blood pressure corresponding to specific worktype codes entered or otherwise provided by the speaker when producing the dictation leading to a transcription . at stage 138 , the database server 24 searches stored transcriptions for the desired data corresponding to the indicated data type to be searched . the database server 24 may search the stored transcriptions as edited by a medical transcriptionist using the editing device 20 . in this case , the server may employ the nlp module 42 to search through the stored transcriptions using appropriate trigger phrases and / or trigger models . the transcriptions are normalized by having portions formatted in structured tables , although the tables may differ . in this case , the trigger phrases and / or trigger models may be adapted to a search for text associated with structured tables of data , with the text associated with the structured tables potentially being different than trigger phrases that may be used in transcription . for example , in dictations , the speaker may say something like , “ the patient is a 47 - year - old male .” the trigger phrase searched for in raw text may be a phrase such as “ the patient is a ,” because this is a typical spoken lead - in to an age description , while a trigger phrase for searching in a normalized transcription may be more succinct , such as “ age ” or “ gender ” or “ sex ” as these are more likely to appear in a table . other embodiments are within the scope and spirit of the appended claims . for example , due to the nature of software , functions described above can be implemented using software , hardware , firmware , hardwiring , or combinations of any of these . features implementing functions may also be physically located at various positions , including being distributed such that portions of functions are implemented at different physical locations . for example , the nlp module 42 may be disposed wholly or partially elsewhere ( i . e ., other than at the automatic transcription device 30 ), such as at the database server 24 . in other embodiments , for example , the nlp processing may take place after the mt has edited the original raw text transcription produced by the asr device 30 . thus , referring to fig5 , the editing stage 118 may be performed before the nlp processing stage 116 . in this instance , the mt may make no attempt to fill in the table format . this table may not be available to the mt at all . instead , the mt corrects the raw speech recognition as usual and instructs the edited transcription to be stored . the stored edited transcription is analyzed by the nlp module 42 to perform the nlp processing stage 116 . the trigger phrase and content models may be much more restrictive than in cases where the raw text is used as an input since the edited text is presumably more error free than the raw text transcription . in other embodiments , a combination of techniques discussed above can be used . for example , a process may proceed according to stages 112 , 114 and 116 shown in fig5 . in the editing stage , however , the medical transcriptionist may correct speech recognition and formatting errors but not move data into table fields or edit the tables fields and may not delete any of the transcribed text . the nlp module 42 may be applied to analyze the edited transcription with the further constraint that already filled - in table fields should not be located . thus , the nlp module 42 would search over the remaining , non - table raw text for a subset of the original table fields that were neither filled in by the original analysis by the nlp module 42 nor filled in during the editing performed by the medical transcriptionist . while the description above focused on medical transcriptions , the invention is not limited to medical transcriptions . the invention may be applied to data extraction for non - medical applications such as legal dictations ( e . g ., for billing ), student evaluations ( e . g ., situations involving ratings and / or test scores including psychological evaluations ), etc . further , while the discussion above refers to “ the invention ,” more than one invention may be disclosed .