Patent Application
20050273362
This disclosure relates, in general, to methods and systems for generating medical narratives.
In recent years, the cost of medicine including pharmaceuticals and medical procedures has increased. Payers, such as patients, insurance companies, and government assistance providers, attempt to control costs by implementing cost controls and price limits for medical procedures.
On the other hand, physicians and other medical healthcare providers are experiencing increased costs in expenses, such as insurance and practice management. As a result, healthcare providers are experiencing pressure and possibly lost profits from increased expenses and limits on what can be charged.
In addition to price controls and limits, organized payers, such as medical insurance providers and government entities, request considerable paperwork to justify payment. The paperwork generally includes a medical narrative describing the encounter with the patient. Typically, a healthcare provider may dictate the narrative or write the narrative by hand. The narrative is transcribed by a transcriber and provided with the paperwork. This process adds expense to the healthcare provider's practice and may introduce error into the paperwork. The added expense reduces healthcare provider profits and errors may delay payment or lead to payer rejections. As such, an improved process for generating a narrative would be desirable.
In one particular embodiment, the disclosure is directed to a system including a processor and storage. The storage is accessible by the processor and includes medical findings data and computer-implemented program instructions. The medical findings data includes a discrete input. The computer-implemented program instructions are configured to access the medical findings data and are configured to generate at least a portion of a medical narrative based on the discrete input.
In another exemplary embodiment, the disclosure is directed to a system including a processor and storage accessible to the processor. The storage includes data that includes a discrete input, a plan file, and computer-implemented instructions. The computer-implemented instructions are configured to access the data and are configured to form a linguistic component object.
In a further exemplary embodiment, the disclosure is directed to a computer-implemented method for generating a medical narrative. The method includes accessing a discrete input associated with a medical finding and generating a medical narrative based on the discrete input.
In another exemplary embodiment, the disclosure is directed to a computer-implemented method for generating a narrative. The method includes providing a set of discrete inputs, generating an entity entry associated with the set of discrete inputs, and generating a set of event entries based on the set of discrete inputs.
In one particular embodiment, the disclosure is directed to a computer system and methods for generating a text narrative from discrete inputs. In one exemplary embodiment, the text narrative is a medical text narrative derived from a medical workflow associated with a patient encounter. The discrete inputs include medical findings.
The narrative system 104 may include a computer server system connected to a network. The entry device 106 may be directly connected to the narrative system 104 or connected to the narrative system 104 via the network. As such, the entry device 106 may be a remote device or a local device. In one exemplary embodiment, the entry device 106 is a portable computational device, such as a handheld device or wireless computer pad-type device.
In one embodiment, the system 102 is a medical system. A healthcare provider (HCP) enters discrete inputs associated with medical findings into an entry device 106 during an encounter with a patient. The medical findings inputs are transferred to the narrative system 104 and a medical narrative is generated based on the medical findings.
The system accesses the discrete inputs, as shown at step 204. Discrete inputs include bi-state inputs, tri-state inputs, and canned text phrases with or without units of measure.
Returning to
Using the entity and event objects, predicate argument structures (PAS) are generated, as shown at step 210. In one exemplary embodiment, PASs correspond to the clauses in the text. Each event corresponds to a predicate that indicates the action or state involved. Each entity becomes an argument of one of the predicates.
Using the PASs, the narrative system generates a text narrative, as shown at step 212. In one exemplary embodiment, each PAS is converted in a two-step process into a parse tree, from which the final text is produced. The first step performs several functions to produce the overall structure of the clause. The second step occurs with a passive sentence, rearranging the components to create a parse tree that shows the sentence structure of the final text. The parse tree is converted into sentence text, using proper word order (e.g., adjectives preceding nouns). Punctuation and capitalized words are added where appropriate.
The medical findings data 408 includes one or more discrete inputs, such as individual data items, such as the value entered for the date under Started, “dull” and “burning” under Description, and “moderate” under Severe, as shown in
The discrete inputs and the finding data 408 may be stored in a database or be provided directly as received from a remote data entry device. From these discrete inputs, a narrative system generates a text narrative.
The plan data 410 includes a set of instructions for mapping discrete inputs, such as the medical findings, into a linguistic component, such as an entity or event. In one exemplary embodiment, the plan data includes a set of schema files, each of which include one or more plan list(s) that include one or more plans, as shown in
The actions of the plans generally result in a set of entities 412 and a set of events 414. The set of entities 412 may include entity objects, such as objects associated with a patient or complaint. The set of events 414 may include event objects, such as objects associated with reporting, complaining, precipitating, and alleviating. The entity objects and the event objects may be included in lists of entity objects and event objects.
From the event objects and entity objects, predicate argument structures 416 may be generated. The predicate argument structures 416 may include predicate argument structure objects that are used in the process of generating text narratives.
The computer-implemented instructions and programs 418 are operable to direct the processor 404 to generate the text narratives from the discrete inputs. For example, the computer-implemented instructions 418 may be configured to access the findings data 408 and to read the discrete inputs. In a particular embodiment, the computer-implemented instructions 418 are configured to generate linguistic component objects, such as entities 412 and events 414, based on the discrete inputs. The computer-implemented instructions 418 are configured to generate PAS objects 416 from the linguistic component objects 412 and 414 and are configured to generate output text 424 from PAS objects 416. For example, the computer-implemented instructions and programs 418 may generate a parse tree 422 based on the PAS objects 416 and generate the output text 424 based on the parse tree. In one exemplary embodiment, the computer-implemented instructions 418 may generate interfaces for the collection of discrete inputs and the display of generated text narratives.
In one example, a HCP is provided with an interface including elements for entering discrete inputs associated with a complaint. The discrete inputs are stored for access by a narrative generation system. The narrative generation system accesses the data, generates linguistic component objects based on the discrete input data, and generates text narratives based on the linguistic component objects. The narrative generation system may provide the narrative as part of an interface to the HCP or as part of paperwork provided to a third party payer, such as an insurance company or government program.
In one exemplary embodiment, the PAS objects 510 are accessed by an aggregation and ordering engine 512 and a sentence maker 514. The PAS objects are used to create canonical form 516 and a parse tree 518. A text realizer 520 generates the text narrative 522. An alternative process for sentence generation from a predicate argument structure may be found in Building Natural Language Generation Systems by Ehud Reiter and Robert Dale, Cambridge University Press, 2000.
The medical data items 602 include discrete inputs. In one exemplary embodiment, the discrete inputs are included in a database. Each input may include an indication of category, its value, and an indication of what it modifies. For example, a complaint discrete input may include an indication that it is a complaint and the complaint's name. A severity discrete input may include an indication that it relates to severity, is an adjective, and is associated with a complaint. Alternately, the discrete input may be an annotation or canned text that is treated as a whole and not parsed.
The discrete input is processed in accordance with a plan 606 and lexicon 604. Plans 606 may include precondition statements and action statements. For example, the format of a plan may be:
<name>
PRECONDITION: <list of preconditions>
ACTION: <action list>
where <name> identifies the plan. In one exemplary embodiment, the plans are named by category, such as Location or Onset, followed by a sequence number. For the plan to apply, the preconditions should match the characteristics of the findings data as well as existing entities/events at the time. The actions list the operations to convert the finding into parts of the appropriate entity or event.
In this exemplary embodiment, plans are organized into plan lists, which in turn are grouped into schemas. Each schema provides the sets of plans for a particular part of patient encounter processing, such as Generic Symptoms HPI. Each plan list includes the plans for a particular finding type, such as Location, Severity, etc. Each plan has a name, a set of preconditions and a set of actions. In one particular example, the schema, plan list and plans may be organized or stored as an XML file. See Table 1 for details.
There are several logical designations for the building blocks of plans: preconditions—which test for true or false; expressions—which return a value; plan_actions—which perform some action; and logical connectives—for combining preconditions. In addition XML statements can have attributes in the form: name=“value”.
Preconditions may include several sets of preconditions: the ones checked at the plan list level and those checked within a plan, either at the beginning of a plan or in a switch/case to further distinguish finding characteristics, such as part of speech. The functionality is the same for these two. Preconditions test findings and circumstances to determine which plan list applies and which specific plan is to be used. Table 2 describes exemplary preconditions.
Because expressions return a value, they can be used in several ways. The returned value can be tested as part of a precondition, such as <findingValue> in this example: <equals><findingValue item=“.”/>none</equals>. Here the expression <findingValue> is tested to see whether its returned value is equal to the finding value “none”. The value returned by an expression can also become part of the output. Table 3 lists some of the expressions. The “findingValue” tag returns the value of the current finding. It is used in preconditions and action statements to indicate that the value of the current finding is to be inserted there. The “categoryname” tag is used inside preconditions and action statements when the name of the category is to be inserted. It returns the name of the category for the current finding.
Actions build the entities and events used for constructing clauses and sentences. Actions include Create an instance, Insert a value into a slot in an instance, Add to the slate, and a special case action called CannedText. Within actions, the order of attributes is flexible but for consistency should follow the order: instancename, slotname, other arguments. See Table 4 for details about actions.
The “createEntity” and “createEvent” tags create an instance and give it a name. The “insertValue” tag is used to add the slots for the arguments in that instance and to give them values. The “insertPredicate” tag is a special case of the “insertValue” tag with slotname=“predicate”.
The slate is used to hold information that does not fit into an instance slot, but may be used before the sentence can be generated, such as tense or prepositions to be used as sentence adjuncts. The syntax for addToSlate is similar to insertValue, with the name of the slot indicating how the information may be identified on the slate. For example, this addToSlate statement would save the tense information for this plan.
If a prepositional phrase is to be described (where the current findingValue is the object), this statement would work:
The “CannedText” action is used sparingly for those situations where building a sentence would be too complicated. Sometimes the verb is rare and may not be set up as a predicate. Other times the form of the sentence would be complicated. An example of CannedText includes:
In writing preconditions, the ability to combine several may be used to establish a test. Within the <preconditions> opening and closing tags, a number of individual preconditions can be written using an implied AND combination as well as the explicit AND expression. An exclusive or (XOR) may be used for selecting one of several conditions, as well as logical <OR>. For example, here the finding is tested to determine whether the finding is either an adjective or adjective complement.
In the case of attributes, the XOR test can be done by including more than one choice within quotes, separated by vertical bars:
Each tag or expression may invoke a function call or access a class. In one exemplary embodiment, each tag or expression has an associated Java class.
Referring to
A plan engine converts the medical data item to an instance, as shown at process 608. The instance results in creation of or change to an entity or event 610. An entity may take the form:
where <entity_id> is the name of a finding. Modifiers are generally adjectives. Post_modifiers may turn into prepositional phrases during lexicalization.
An event may take the form:
where <role_name> can be THEME, AGENT, INSTRUMENT, etc. The tag <event_id> is made up from the name of the plan list, the predicate and the category of the finding.
Once the entities and events are created and the discrete inputs processed, the entities and events may be used to generate a text narrative. In one exemplary embodiment, the entities and events are used to generate predicate argument structures. These predicate argument structures are used to generate parse trees and canonical forms, which are used to generate the text narrative.
The general format for a PAS is:
<role_name> is determined by the <predicate_name> which determines the <role_value>. For example, if the Predicate chosen is “describe”, then the roles associated with that predicate may be Agent and Theme. This method follows Charles Fillmore's notions of Case Grammar. The sentence pattern is generally determined by the verb or verbs associated with a particular predicate, as indicated in the predicate argument structure.
In one exemplary embodiment, the narrative system receives a set of discrete inputs. For example, a patient may complain of abdominal pain. A finding may include “periumbilical” whose category is “initial location.” Using one or more plans, two entity objects and an event object may be generated.
The plan may, for example, be associated with location, such as the following example:
For example, a patient entity object may be generated as follows:
A complaint objected may be generated as shown below:
In addition, an event object such as an initial location object may be generated as shown below:
In the exemplary event object, the “valence” value of 1 indicates that an interface box was checked. Based on these linguistic component objects, a text narrative may be generated. For example, the system produces “Initial location was periumbilical.”
The above-disclosed subject matter is to be considered illustrative, and not restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other embodiments, which fall within the true scope of the present invention. Thus, to the maximum extent allowed by law, the scope of the present invention is to be determined by the broadest permissible interpretation of the following claims and their equivalents, and shall not be restricted or limited by the foregoing detailed description.
The present application claims priority from U.S. Provisional Patent Application No. 60/576,363, filed Jun. 2, 2004, entitled “METHOD AND SYSTEM FOR GENERATING MEDICAL NARRATIVE,” naming inventors Mary Dee Harris and Steve Shipman, which application is incorporated by reference herein in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 60576363 | Jun 2004 | US |
