US20050114283A1

US20050114283A1 - System and method for generating a report using a knowledge base

Info

Publication number: US20050114283A1
Application number: US10/846,255
Authority: US
Inventors: Philip Pearson; Andrew Odlivak; Marc Shapiro; Deepak Agarwal; Aaron Divinsky; Peter Cotton
Original assignee: Olympus America Inc
Current assignee: Olympus Corp
Priority date: 2003-05-16
Filing date: 2004-05-14
Publication date: 2005-05-26
Also published as: WO2004104754A2; JP2007505419A; EP1625751A4; CA2526135A1; JP2007516011A; JP2007516498A; EP1625751A2; EP1629350A2; US20050073578A1; EP1627357A4; WO2004103151A3; CA2526073A1; WO2004104742A2; EP1629350A4; US7492388B2; EP1627356A2; US20050075544A1; CA2526149A1; JP2007503282A; EP1627357A2

Abstract

A method and system for assisting a user in generating a report regarding a procedure such as a medical procedure. A first display region provides a hierarchical menu of available keywords from a knowledge base. A second display region provides a hierarchical menu of particular keywords that have been selected by the user. A third display region provides a report from a sentence that was generated by populating a sentence model based on the selected keywords. The sentence can be edited by selecting a keyword from the sentence, then selecting a replacement keyword from the first display region. A grammar engine corrects the grammar of the sentence based on user settings for the keywords.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. provisional patent application No. 60/471,349, filed May 16, 2003, entitled “System And Method For Endoscope Management” (docket No. P16531), and incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention
The invention relates generally to a system and method for generating a report using a knowledge base and, more specifically, to generating a report using sentence models that are automatically populated with keywords selected by a user. The invention is illustrated in the context of a medical procedure such as an endoscopic examination.
2. Description of the Related Art
Computerized word processing applications have gained widespread use since they allow a user to prepare and manipulate documents in electronic form. Moreover, various applications have been developed to assist users in specific industries in developing reports and other documents. For example, some voice-activated systems use a dictionary developed from scanning published reports to choose a term that most closely matches a spoken word. The spoken words of the user are then converted to text to produce a report. Other systems allow the user to enter information for a report via various prompts and menus. The system then generates a report based on the entered information.
However, such approaches are problematic since the terms are not presented in a uniform sentence structure. Moreover, the terms are not classified in a way that improves understanding and data mining capabilities. Similarly, various other features and benefits have also been lacking in the known systems.

BRIEF SUMMARY OF THE INVENTION

To overcome these and other deficiencies in the prior art, the present invention provides a system and method for generating a report using a knowledge base.
In a particular aspect of the invention, a method is provided for generating a report regarding a procedure. The method includes: (a) displaying available keywords from a knowledge base on a first display region of a user interface, (b) receiving, via the user interface, at least one user command selecting at least one of the available keywords from the first display region, (c) displaying the at least one of the available keywords on a second display region of the user interface, responsive to the selection thereof by the at least one user command, (d) populating a sentence model according to the at least one of the available keywords to provide a populated sentence, and (e) displaying the populated sentence on a third display region of the user interface.
In another aspect of the invention, a method for providing keywords for generating a report regarding a procedure includes: (a) providing respective keywords for use in the report, (b) associating each of the respective keywords with a respective classification in a hierarchically arranged tree structure of classifications, (c) associating respective properties with the respective keywords, and (d) defining, based on the respective properties, a set of allowable values for a group of the respective keywords, where the group of the respective keywords are related
A related user interface and program storage device are also provided.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, benefits and advantages of the present invention will become apparent by reference to the following text and figures, with like reference numbers referring to like structures across the views, wherein:
FIG. 1 illustrates an overview of a report-generating system according to the invention;
FIG. 2 illustrates a Registration and Scheduling clinical flow;
FIG. 3 illustrates a Pre-Procedure clinical flow;
FIG. 4 illustrates a Procedure clinical flow;
FIG. 5 illustrates a Post-Procedure clinical flow;
FIG. 6 illustrates a Home tab of a user interface;
FIG. 7 illustrates a Patient File tab of a user interface;
FIG. 8 illustrates a Registration tab of a user interface;
FIG. 9 illustrates a Pre Procedure tab of a user interface;
FIG. 10 illustrates a Procedure tab of a user interface;
FIG. 11 illustrates a Post-Procedure tab of a user interface;
FIG. 12 illustrates an Analysis tab of a user interface;
FIG. 13 illustrates an Admin tab of a user interface;
FIG. 14 illustrates a Pre-Procedure Lexicon interface;
FIG. 15 illustrates a Lexicon user interface for selecting indications of GI symptoms for a patient;
FIG. 16 illustrates a Lexicon interface that shows the selected keyword “heartburn”;
FIG. 17 illustrates a Lexicon interface that shows a keyword “severity” in expanded form; FIG. 18 illustrates a Lexicon interface that shows a selected keyword “severe”;
FIG. 19 illustrates a Lexicon interface that shows a user input value “6” as a selected keyword;
FIG. 20 illustrates an interface with a list of billing codes;
FIG. 21 illustrates a Lexicon interface in the Post-Procedure tab;
FIG. 22 illustrates an interface for selecting a Procedure Note Template under the Post-Procedure tab;
FIG. 23 illustrates a Procedure Note interface;
FIG. 24 illustrates an interface for selecting a Procedure Note Template under the Admin tab;
FIG. 25 illustrates a class diagram of the Concept Layer of the knowledge base;
FIG. 26 illustrates a class diagram of the Data Layer of the knowledge base;
FIG. 27 illustrates a class diagram of the Sentence Model infrastructure of the knowledge base;
FIG. 28 illustrates a class diagram of the View Layer of the knowledge base;
FIG. 29 illustrates a user interface for adding a keyword to the knowledge base;
FIG. 30 illustrates a user interface for adding a property definition to the knowledge base;
FIG. 31 illustrates a user interface for editing a keyword in the knowledge base;
FIG. 32 illustrates a user interface for editing properties of a keyword in the knowledge base;
FIG. 33 illustrates a user interface for adding properties of a keyword in the knowledge base;
FIG. 34 illustrates a user interface for adding and editing codes in the knowledge base;
FIG. 35 illustrates a user interface for adding and editing sentence models in the knowledge base;
FIG. 36 illustrates a user interface for adding a condition in a sentence model in the knowledge base;
FIG. 37 illustrates a user interface for adding and editing triggers in the knowledge base;
FIG. 38 illustrates a user interface for adding a keyword item to a menu in a view;
FIG. 39 illustrates a user interface for adding a menu in the knowledge base;
FIG. 40 illustrates a user interface for creating a shortcut in the knowledge base;
FIG. 41 illustrates a user interface for editing a shortcut in the knowledge base; and
FIG. 42 illustrates user interfaces for a grammar engine.

DETAILED DESCRIPTION OF THE INVENTION

Overview of the System
FIG. 1 illustrates an overview of a report-generating system according to the invention. In one possible aspect, the invention involves a web-browser based clinical information management system that automates a medical lab such as an endoscopy lab by managing patient examination data at different phases of patient care, including the capture of images, data and written Procedure Notes, and further, the generation of medical records and procedure reports. The system may include an endoscopic workstation 110, a Mavigraph printer 112, RGB monitor 114 and processor 116. The user provides inputs to the workstation 110 via keyboard, mouse, voice interface, or the like. The workstation may be coupled with a web browser interface that provides the necessary information to perform exams, and facilitates for users of endoscopic equipment, e.g., physicians, nurses or clinicians, the efficient capture, management, organization and presentation of endoscopic images and patient and examination data.
The workflow processes associated with this aspect of the system are flexible enough to support small endoscopic practices in addition to endoscopic departments within large healthcare institutions.
The system may function as a stand-alone system including memory for storing patient data and image information. The system may also include a server 140 and database element 145 that may be connected via a gateway application to various “external” systems such as a hospital information system where the gateway facilitates the transfer of healthcare information between the system and other applications. Patient information stored in the system may be downloaded to external systems (e.g., a legacy system) via a gateway interface. The workstation 110 may communicate with the server 140 via the Internet 170 or other network, such as a LAN or intranet. The workstation 110 may also communicate with a fax server 160, for instance, for faxing reports via a fax modem 162. Generally, software instructions, including firmware and microcode, may be stored in any type of program storage device or devices, also referred to as computer-readable media. The software is executed by a processor in a known manner to achieve the functionality described herein.
In a particular aspect, the system includes an Image Management function enabling a user to annotate, label, import, export, and enhance the quality of images, including the ability to manage, record, and export live video clips. Further to this is an “auto-masking” feature that automatically selects an appropriate video mask based on a particular endoscope device being utilized by the health care practitioner.
In another particular aspect, the system includes a medical terminology “Knowledge Base” (KB) comprising keywords relating to the procedure, e.g., such as gastrointestinal, endoscopic and bronchoscopic terminology keywords. The keywords are captured via a graphical user interface (GUI) before, during, and/or after a procedure. The keywords are made available for labeling images captured during an examination to be used in reports, auto-populating appropriate sections of a report such as a Procedure Note, described further below, based on patient history, and building Procedure Note templates or models to auto-populate sections of information. The system also facilitates the use of custom terms that apply to a specific department or location. Thus, for example, during an exam, a user may select KB terms for a procedure via a common user interface, which is employed wherever the user needs to locate or extract keywords. This also provides a consistent way to select and use terminology.
Clinical Flow
FIGS. 2-5 illustrate clinical flow diagrams that describe the most common activities associated with the system and their relationship in time in the context of one possible application of the invention. Clinical flow is based on patient flow, which relates to how a patient is processed before, during, and after an endoscopic procedure. The overall flow across all lifecycle stages starts with an exam request and ends with the generation of a Procedure Note, the release of the patient, and the generation of a set of related reports. User roles are represented as horizontal bands.
The registration and scheduling clinical flow 200 of FIG. 2 includes a collection of all the information necessary to set up a visit. It is initiated through an exam request made by either the patient, a surrogate for the patient, or a referring physician. The nurse and physician share the activity of preparing prep instructions and medical advice for the patient.
The Pre-Procedure clinical flow 300 of FIG. 3 starts with the arrival of the patient at the endoscopy facility and addresses all administrative and medical activities necessary to prepare the patient for the exam.
The Procedure clinical flow 400 of FIG. 4 depicts the actual examination that takes place during the Procedure lifecycle stage. The system is used to capture images, record vital signs, and administer medications during this stage.
The Post-Procedure clinical flow 500 of FIG. 5 depicts the activities that take place after the completion of an exam. These activities include a nurse continuing to monitor the patient's recovery, a nurse completing discharge instructions, releasing the patient, and preparing billing code reports, and a physician reviewing and editing the analysis of an exam by generating a Procedure Note. A physician signs the Procedure Note when it is complete. Afterward, management reports, patient recall requests, and referral letters can be created and distributed.
User Interface
The invention is next described in connection with a user interface that allow the user to select different features under different tabs.
I. Home tab 600 (FIG. 6). The Home tab is the default home page, and is pre-defined for each role. However, the user can modify the page to suit the user's needs. The following are the most common tasks that can be performed in the Home tab. Access to these tasks is based on the user's role. For example, if the user logs into the application as a scheduler, then the user would not see the Sign Reports menu option, since that option is reserved for the physician role.
1) Scheduled Exams—used to view a list of scheduled exams and create a new visit and exam.
2) Create a New Visit—allows the user to schedule a new visit for a patient.
3) Pending Items—used to view all of the pending tasks. The user can also select one or more pending items and close them.
4) Pathology Status—used to view the status of outstanding pathology requests or search the database for an existing record. The user can also edit or delete existing pathology records. When a pathology record is deleted, all of the specimens associated with that record are deleted.
5) Unsigned Reports—an attending physician can use the Unsigned Reports screen to view and sign unsigned Procedure Notes.
6) Sign Reports—A system administrator can use the Sign Reports screen to view unsigned Procedure Notes for a specific physician and mark them as signed.
7) Carbon Copies—When the user distributes a document to a medical provider, clinical staff, or contact via email, a notification is sent to the recipients that a document is available for them in the system. Recipients can then log on to the system and view a list of documents on the Carbon Copies screen.
8) ICU Synchronization—when the user performs an exam in ICU (Image Capture) mode, the user's imaging station is not connected to the network server. When the user finishes the exam, the user must upload images and data from the workstation to the server repository. When the workstation is re-connected to the network, a series of simple commands will upload the data and images captured during the exam. After the data is uploaded, the user uses the ICU Synchronization option to synchronize images and data.
9) Recall Letters—used to recall a patient for another examination. The user can use this option to add an item to the Recall Letter Queue to remind a patient of a follow-up examination.
10) System Log -Allows the system administrator to view errors and messages generated by the application.
II. Patient File tab 700 (FIG. 7)—allows a user to capture information specific to the individual patient. This tab is used to record a patient's demographic information; a patient's medical alerts, GI/pulmonary, medication, family, and social history information, and view a summary of the patient information.
III. Registration tab 800 (FIG. 8). This tab is used to: (a) create and modify visit and/or exam information; (b) view past, current, or future schedules; (c) assign resources for an examination including procedure rooms and equipment; and (d) distribute registration documents.
III. Pre-Procedure tab 900 (FIG. 9). This tab is used to: (a) record care plan information for a specific visit; (b) record medical alert information; (c) record GI, pulmonary, family, and social history information, (d) manage physical examination, patient assessment, and physician check information, (e) manage prep status information for the patient; (f) manage consent information for a visit; (g) capture vital signs and medications administered before the examination; (h) display a summary of selected Pre-Procedure information and capture nurse handoff information; and (i) distribute Pre-Procedure documents.
IV. The Procedure Tab 1000 (FIG. 10). This tab is used to: (a) capture images during an endoscopic procedure; (b) record live video clips; (c) record scope time used during an examination; (d) view images and Procedure Notes from a previous exam; (e) print images for an exam on a laser jet or a Mavigraph printer; (f) record nurse administration information; (g) record accessories and equipment used during an examination; (h) generate pathology requests; (i) capture vital signs and medications administered during the examination; and (j) distribute procedure documents.
V. The Post Procedure Tab 1100 (FIG. 11)—After an examination is completed, this tab is used to perform post-procedural tasks. These tasks include synchronizing images in the ICU mode, monitoring a patient's vital sign and medication information, managing captured images, and writing Procedure Notes. Images from a current procedure, e.g., image 1 and image 2, and from a prior procedure, e.g., image 3, image 4, and image 5, can be displayed together for comparison. This tab is used to: (a) record patient recovery information; (b) manage images captured during an exam; (c) label, annotate, enhance, and print images; (d) import and export images to and from the current examination; (e) manage video clips recorded during an examination; (f) write and sign Procedure Notes; (g) capture patient recall information; (h) assess performance of a trainee participating in an examination; (i) capture patient survey information; (j) distribute Post-Procedure documents; and (k) perform ICU synchronization.
VI. The Analysis Tab 1200 (FIG. 12)—used to generate redefined template-based management reports to satisfy end-user administrative reporting requirements related to patient, procedure and facility management, efficiency analysis, and resource utilization. This tab is used to generate: (a) Continuous Quality Improvement (CQI) reports; (b) efficiency reports; (c) equipment analysis reports; (d) procedure analysis reports; and (e) administration reports.
VII. The Admin Tab 1300 (FIG. 13)—used to perform administrator tasks and ensure the efficiency and security of the system. The system can be customized based on the needs and requirements of the facility, physician, and clinical staff. This tab is used to: (a) maintain system data (such as Patient ID type and department information); (b) maintain application resource data (such as clinical staff and contact information); (c) perform system configuration (such as configure Mavigraph printer and video settings); (d) customize how the application will flow and generate information (for example, changing the order and location of menus within the application and editing or creating templates/models that are used to create Procedure Notes); (e) customize user-defined fields (such as other patient information and other visit information); (f) control access to or within the application (such as user and role maintenance); and (g) maintain equipment used during the procedure.
Knowledge Base
The Knowledge Base (KB) is a terminology database that contains terms related to the specific procedure. For example, the KB may be a medical terminology database that includes gastrointestinal, endoscopic and bronchoscopic terminology in one possible application. The KB can be extended to other medical and non-medical applications by using the appropriate terminology. For example, the knowledge base may be used for any application where standardized terminology is desired. This may include applications for producing reports in various industries, such as financial services, insurance, legal services, real estate and so forth.
The KB contains concepts (terms), keywords (terms used in a specific context), sentence models and views (menus and keyword items). Keywords are the medical terms that are the basic building blocks of the KB. When the user selects a keyword from a menu of available keywords, it appears in a list of selected keywords or terms. Moreover, keywords are organized in menus. For example, a “size” menu type could contain the keywords “small”, “medium”, and “large”. Furthermore, a menu can be configured to be single-select, unique, or multi-select.
Generally, the user can use the KB to: (a) capture keywords before, during, or after a procedure; (b) label images captured during an examination to be used in reports; (c) auto-populate appropriate sections of a Procedure Note based on patient history; and (d) build Procedure Note templates/models to auto-populate sections of information.
During an exam, the user can select KB terms for a procedure. The KB features a common user interface, which is employed wherever the user needs to locate or extract keywords. This also provides a consistent way for the user to select and use terminology. The KB also facilitates the use of custom terms that apply to a specific department or location.
Lexicon Function
A Lexicon function is used to select terms from the KB. The Lexicon arranges the KB content into different report sections, based on Phases of Care. The user can click a tab to see the KB terms associated with the report section. A facility determines which report sections should be available in the Lexicon screen for a phase of care. A system administrator can make a report section available to appropriate phases of care in the Admin tab.
Each tab or report section in the Lexicon screen may contain two panes or display regions. As described further below, the right hand side pane displays a KB view and contains all the available terms of the KB arranged in a logical tree. Typically, only a portion of the tree is visible at a time. The user can navigate the tree to view different portions of it. The left hand side pane contains the selected terms. When the user picks or selects an available term from the right hand side pane, it is copied to the left hand side pane, which displays the selected terms, thus allowing the user to logically building a comprehensive description of the exam. The user uses these selected terms along with other exam data collected during various phases of care to generate Procedure Notes, e.g., reports, and other exam related documents.
Detailed Discussion
Lexicon Function—Pre-Procedure
FIG. 14 illustrates an example of the Pre-Procedure Lexicon screen or interface 1400. The user can use the Lexicon function to select terms from the KB and to record procedure related information of the exam. The Lexicon arranges the KB content into different report sections for the Pre-Procedure, including indications, unplanned events and billing codes. These report sections appear as tabs in the Lexicon screen 1400. To reach this interface, the Pre-Procedure tab is selected, and the menu item “Lexicon” is selected from the far left hand side of the interface. Furthermore, under the Lexicon function, the “Indications” tab has been selected, so the term “Indications” appears at the top of the left hand pane or second display region 1410.
The right-hand pane or first display region 1420 of the interface 1400 displays the available terms in the KB in a hierarchical tree or menu 1425. Generally, there is insufficient room to display all terms at the same time. Instead, the user can view branches of the tree 1425 in an expanded view by clicking on a “+” icon, or in a contracted view by clicking on a “−” icon. The branches of a node of the tree may contain related keywords that qualify the concept of the parent node keyword. For example, in the tree 1425, the keyword “severity” includes branches for keywords “mild”, “moderate” and “severe” that describe the degree of severity of the patient's symptoms. Keywords at lower levels of the tree thus can be provided to qualify the keywords at the higher levels.
In one example approach, the keywords in the tree 1425 are organized into menus in which the physician might organize the indications or symptoms of a patient. These menus may include, e.g., GI or gastrointestinal symptoms, airway symptoms, test results, imaging results, surveillance, treatment of established disease, systemic disorders, follow up, diagnostic sampling, and protocol study. Under each keyword, further qualifying terms can be viewed by expanding the tree. The interface 1400 relates to GI symptoms, and the portion of the tree 1425 shown relates to the indication “abdominal pain”. Multiple menus of indications can be selected by the user together or in turn.
The second display region 1410 contains a tree 1415 with the keywords that the user has selected from the KB terms in the display region 1420. Generally, when the user selects an available term from the first display region 1420, it is copied to the second display region 1410 to logically build a comprehensive description, e.g., of the patient's symptoms, or of the subsequent exam results. For example, in the tree 1415, the indications of diarrhea, weight loss, abdominal pain and heartburn have been selected along with various keywords for detailing each indication. The following discussion explains how the keyword “heartburn” in the tree 1415 is selected by the user.
FIG. 15 illustrates an example lexicon user interface 1500 for selecting indications of GI symptoms for a patient. In the first display region 1420, the various GI symptoms are provided as branches of a tree 1525 in which the keyword “GI symptoms” is a parent node. The user has expanded the tree under the keyword GI symptoms to reveal the next lower level of keywords, e.g., abdominal pain, bloating, etc. The second display region 1410 indicates that the user has not yet selected any GI symptoms.
The user, such as a physician, obtains information regarding the GI symptoms of a patient such as by interviewing the patient. The user learns that the patient is experiencing heartburn. The user then selects the keyword “heartburn” from the tree 1525 in the first display region 1420, e.g., by clicking on “heartburn” with a pointing device such as mouse. The keyword “heartburn” is then copied to the second display region 1410 as a first indication. See the interface 1600 of FIG. 16, which shows the selected keyword “heartburn” displayed in the tree 1615 in the second display region 1410. Other indications such as diarrhea, weight loss and abdominal pain, as provided in the tree 1415 of FIG. 14, may similarly be selected from the tree 1525 to build a lexicon of selected keywords in the second display region 1410.
Moreover, each keyword may be further detailed when selected. For example, when the keyword “heartburn” is selected from the tree 1525 in the first display region 1420, as shown in FIG. 15, the first display region 1420 may be updated to display the tree 1625, in which various additional details appear as branches or child nodes of the selected keyword. For example, as shown in FIG. 16, the tree 1625 displays keywords for detailing the severity, frequency, duration, length of last episode, precipitants and relief factors regarding the heartburn. Note that these same keywords may be used for detailing the other indications, such as diarrhea, weight loss and abdominal pain. Keywords that are specific to a particular indication may also be used for detailing the indication.
Furthermore, each of the keywords in the tree 1625 may be expanded to provide further detailing keywords. For example, the user may expand the node “severity” in the tree 1625 by clicking on the “+” sign next to “severity”. The result is the tree 1725 in the interface 1700 of FIG. 17, where the keywords “mild”, “moderate” and “severe” allow the user to detail the severity of the heartburn. Note that the term “heartburn” is highlighted in the tree 1615, indicating to the user that any further selection from the first display region 1420 will provide details regarding the heartburn. If other indications such as weight loss and abdominal pain were present in the tree 1615, each indication could be highlighted in turn by the user to allow the user to enter the associated details in turn.
Referring to the tree 1725, assume the user selects the child keyword “severe” under the parent keyword “severity”. As shown in the tree 1815 in the interface 1800 of FIG. 18, the term “severe” is copied to the second display region 1410 and provided as a branch of the term “heartburn”. As a further example, assume the user proceeds to detail the frequency of the heartburn. To do this, the user expands the keyword “frequency’ in the tree 1625 to reveal options such as “constantly”, “specify number of times per day”, “specify number of times per week”, “specify number of times per month”, and “specify number of times per year”. The user may select “specify number of times per day”, which causes a pop-up window to be displayed requesting that the user enter a number. The user enters “6” in an Enter Number field if the patient was feeling heartburn six times a day. The user then clicks OK to save the entry. The interface is then updated so that the number “6” appears in the tree 1915 in the interface 1900 of FIG. 19 under the keyword “heartburn”. Alternatively, the interface may display “6 times per day”.
The process as detailed above may be repeated for the different indications to arrive at the interface 1400 of FIG. 14. Note that the hierarchical relationship of the keywords in the tree of available keywords is maintained in the tree of selected keywords. Essentially, the tree of selected keywords is a subset of the tree of available keywords. Advantageously, this allows the context of a keyword to be understood by the user. Also, note that the “specify” keywords prompt the user for a specific entry, e.g., as text or a numerical entry. It is also possible for the numerical values or ranges of values to be provided as keywords in the tree of available keywords.
Generally, the menu or tree of available keywords in the KB can be configured to single-select, unique, or multi-select. A single-select menu allows the user to select one keyword at a time. For example, in the tree 1425 of FIG. 14, the keyword “severity” is classified as a single-select menu, so the user can select only one qualifier from the available qualifiers, such as mild, moderate or severe. In a unique menu, once the user selects a keyword, the user cannot select the keyword again. For example, the GI Symptoms menu 1525 of FIG. 15 is unique, and the user selects “heartburn” as the first symptom. If the user tries to selects this keyword again from the tree 1525, the keyword “heartburn” in the tree 1615 of FIG. 16 is highlighted to indicate that it has already been selected.
A multi-select menu allows the user to select multiple keywords at a time. The user can even select all the keywords in a multi-select menu. For example, if the GI symptoms menu in the tree 1525 of FIG. 15 is classified as a multi-select menu, the user may select multiple symptoms such as diarrhea, weight loss, abdominal pain and heartburn at the same time. For example, the user may select multiple terms by clicking on each term with a mouse while holding down the <Ctrl> key on the keyboard. Each selected symptom appears at the same hierarchical level of the tree 1415 of FIG. 14.

Views are collections of menus and their associated keywords organized within a tree-structure. The user can use views to navigate through the KB and select appropriate medical terms or keywords. For example, the interface 1400 of FIG. 14 illustrates a collection of menus and keywords or a View in the Lexicon screen. To access the Lexicon screen, the user navigates to the Pre-Procedure tab, selects an exam, and selects the “Lexicon” option from the far left hand menu. The Lexicon screen 1400 may contain the following tools to assist the user in navigating the interface. Any appropriate icon design may be used.



Tool:	Purpose:

Generate	Generate sentences from selected keywords. Active only
Report	in the Procedure Note screen (The Post-Procedure tab).
Move Up	Move keyword up in the selected terms hierarchy.
Move Down	Move keyword down in the selected terms hierarchy.
Code	Generate billing codes based on keyword selection.
Add KB Item	Add a new keyword to the Knowledge Base or available
	terms (the right side pane).
Next	Take the user to the previous multi-select menu one level
	up in the selected terms (the left side pane).
Previous	Take the user one level up in the selected terms (the left
	side pane).
Delete KB Item	Delete a keyword from the selected terms (the left side
	pane).

As mentioned, to select a clinical term for a particular report section (tab), the user clicks on a keyword from the list of available keywords in the first display region 1420, and the selected keyword is copied to the second display region 1410. However, this arrangement of the display regions is an example only. It is possible to have the available and selected keywords displayed in various other configurations. For example, the available keywords may be displayed on a top display region while the selected keywords are in a bottom display region. In another possible approach, the selected keywords are displayed in a window that is overlaid on a window that displays the available keywords. It is also possible to use multiple display screens, where, e.g., the available and selected keywords are displayed on different screens. Various other configurations are possible based on the available display technologies.
Under the “unplanned events” tab of the interface 1400 of FIG. 14, a window may be provided that allows the user to type in details of such an event, or keywords describing the event may be selected from the first display region 1420. For example, an unplanned event during an endoscopic procedure may include bleeding. The location and extent of bleeding can thus be detailed.
Under the “codes” tab, the user can associate billing codes with selected keywords for billing purposes. The user accesses the Lexicon screen and selects a keyword with which to associate the billing code. The user clicks the Code icon, and a Select Billing Codes window is displayed. The user clicks Code Set, and the Code Sets window is displayed. The user searches for a billing code from this window. The user selects a type of code set from the Code Set dropdown list. The user enters the number of the code that is being searched for in the Number field. The user enters a description of the code in the Description field. The used clicks Go, and a list of billing codes based on the search criteria is displayed. If no search criteria are entered, all the billing codes from the selected code set are displayed. FIG. 20 illustrates an interface 2000 with a list of billing codes from the ICD-9 (International Classification of Diseases) Diagnostic Code Set. The user clicks a billing code to select it. To select multiple billing codes, the user presses and holds the <Ctrl> key and selects the billing codes.
Lexicon Function—Post-Procedure
FIG. 21 illustrates an example of the Lexicon screen 2100 in the Post-Procedure tab. In the Post-Procedure phase, the physician or other user uses the Lexicon function to record findings from performing a procedure. These report sections appear as tabs in the Lexicon screen 2100 labeled as: indications, procedure, findings, medication, unplanned events, recommendation, summary and codes. FIG. 21 illustrates the Findings tab. To access the Lexicon screen, the user navigates to the Post-Procedure tab, selects an exam, and selects the Lexicon option from the far left hand menu. The Lexicon interface for Post-Procedure is analogous to that for Pre-Procedure (FIG. 14).
The Post-Procedure Lexicon screen may contain icons for tools as discussed above in connection with the Pre-Procedure lexicon function. Moreover, as with the Pre-Procedure case, a Lexicon menu for Post-Procedure can be configured as single-select, unique, or multi-select.
To select a clinical term for a particular report section (tab), the user clicks on a keyword from the list of available keywords. The selected keyword is copied to the left side of screen or other separate display region. For example, assume the user finds a small polyp in the stomach in the patient during the endoscopic procedure, specifically on the anterior wall of the antrum. To document this finding, the user may perform the following steps:
(a) Access the Lexicon screen.
(b) Select the Findings report section tab. The display region 1420 provides a tree where a parent node is for the keyword “organs” (not shown).
(b) Click the +(plus) sign next to “organs” to expand it, revealing branch nodes for specific organs such as the stomach, duodenum, etc.
(c) Select “stomach” from the first display region 1420. This causes the tree 2115 (FIG. 21) to be updated with the keyword “stomach”, and for the first display region 1420 to display branches including “stomach findings” under the parent node “stomach” (not shown).
(d) Click the + (plus) sign next to “stomach findings” to expand it. This causes the first display region 1420 to display branches of “stomach findings”, including “polyps” (not shown). Note that it is not necessary to update the tree 2115 with the keyword “stomach findings” since it is self-evident that the findings that are subsequently detailed are stomach findings.
(e) Select “polyp” from the first display region 1420. This causes the tree 2115 to be updated with the keyword “polyp” as a child branch of the keyword “stomach”. The first display region 1420 is updated to display a tree that is similar to the tree 2125, except that the keywords are unexpanded. The keywords in the tree 2125, e.g., fundus site. body site, antrum site, other stomach site, etc., are child branches of the keyword “polyp”.
(f) Click the + (plus) sign next to “antrum site” in the tree 2125 to expand it, revealing the child branches of anterior wall, posteriori wall, greater curvature and lesser curvature.
(g) Select “anterior wall of the antrum” from the tree 2125. This causes the tree 2115 to be updated with the keyword “anterior wall of the antrum” as a first branch of the keyword “polyp”.
(h) Click the + (plus) sign next to “size of polyp” to expand it, revealing the branches for diminutive, small, medium, and specify size (mm) in the tree 2125.
(i) Select “small” from the tree 2125 This causes the tree 2115 to be updated with the keyword “small” as a second child branch of the keyword “polyp”. Again, note that the hierarchical relationship of the available keywords is maintained in the tree 2115 for the selected keywords.
(j) Click Save.
The system further allows the user to enter custom information. If the user does not find a keyword in the available KB terms, the user can specify a term using a keyword that begins with “specify” (such as “specify size to enter a size”, “specify finding to enter a finding”, etc.) to add a term. For example, if the user does not find the size that the user wants to specify for the “size of polyp”, the user can specify a different size. To specify a different size in millimeters (mm), for instance, the user can perform the following:
(a) Click the “specify size (mm)” option in the tree 2125 to display a Specify Size (mm) window as a pop up window with a text field.
(b) Enter a value in the Enter Value text field, e.g., “23”.
(c) Click OK. The size of the polyp then appears in the left side tree 2115. For example, in the tree 2115, the entry “23 mm” or “size of polyp 23 mm” may appear in place of the keyword “small”.
(d) Click Save.
Procedure Notes
The Procedure Notes task may be accessed from the Post-Procedure tab of the interface to prepare Procedure Notes regarding a procedure performed on a patient. A Procedure Note may include documented information about a specific exam. It can be used to document findings, diagnosis, medications, recommendations, and other information such as past diagnosis. Generally, the Procedure Note function can be used to: (a) manage images, (b) view information such as images and Procedure Notes for other exams, (c) select terms from the Knowledge Base tree, (d) generate report text, (e) select billing codes, (f) sign a note, (g) generate different versions of a note, (h) discard a note, and (i) delete a note.
The user selects a template/model to use the Procedure Note function. The system administrator creates a Procedure Note template/model based on the manner in which either a facility or a physician wants to display captured information in a document. FIG. 22 illustrates a Select Procedure Note Template screen 2250 in the Post-Procedure screen 2000. To select a template, the user does the following: (a) access the Post-Procedure screen 2200, (b) select an exam, (c) select “Procedure Note” from the far left hand menu, causing the Select Procedure Note Template screen 2250 to be displayed, e.g., as a pop up window, (d) search for the Procedure Note template based on facility and/or physician names, (e) click Go, causing a list of resulting Procedure Note templates to be displayed, and (f) select a particular template to view the Procedure Note screen 2300 of FIG. 23. In the example provided, a template entitled “Standard—Bronch” is available to assist the user in generating a Procedure note for a bronchoscopy procedure.
Referring to FIG. 23, a first display region 2364 may provide a tree 2365 of available KB keywords as discussed in connection with the first display region 1420 of the Lexicon screen 1400 (FIG. 14). Similarly, a second display region 2362 may provide a tree 2363 of selected keywords as discussed in connection with the second display region 1410 of the Lexicon screen 1400. A third display region 2340 provides a Procedure Note Builder for editing and generate reports such as Procedure Notes. A fourth display region 2320 provides an Image Strip section 2320 for managing images for the current exam. Example images for the current exam are displayed at the left side of the section 2320 as “image 1” and “image 2”.
The user can use the Images section 2320 in a similar manner as the Image Management screen. The Images section 2320 may contain tools for the following functions: (a) delete selected images from the current exam, (b) delete all unlabeled images from the current exam, (c) mark selected images for printing, (d) unmark the selected image for printing, (e) view larger image, (f) label all selected images from the current exam, (g) delete the label from all selected images from the current exam, (h) associate findings, (i) disassociate findings, (j) show or hide menu and (k) show or hide strip.
The Procedure Note function can be used to view images and Procedure Notes for other exams associated with the selected patient. The following tools may be used to view other exam information: (a) view large image, (b) view the Procedure Note for the other exam, and (c) close the other exam image window. To view images for another exam, the user accesses the Procedure Note screen, and selects an exam from the Other Exam dropdown list 2322. Images for the selected exam are displayed on the right side of the Images section 2320.
To view Procedure Notes for another exam, the user selects the exam from the Other Exam dropdown list 2322, and clicks the View the Procedure Note icon to display the Procedure Note for the other selected exam in a new window.
The Procedure Note function can also be used to select KB keywords for an examination. The first display region 2364 is used to select keywords as discussed above in connection with the Lexicon function. When the user is done selecting keywords, the user clicks the Generate Report icon, discussed in connection with the tools above, to generate a report in the third display region 2340, which is the report section of the interface 2300. The Generate Report icon is activated if the user makes changes to the selected keywords. Moreover, if any of the selected keywords are associated with a sentence model, the sentence is generated and populated with the keywords in the displayed report within the specific Report Section.
The third display region 2340 may include predefined sections corresponding to the tabs in the Lexicon screen 2100 of FIG. 21, e.g., introduction, indications, procedure, findings, medication, unplanned events, recommendations, summary and codes. The user may build a lexicon for one or more of the sections as discussed above. As the lexicons are developed, one or more sentence models are selected from a number of available sentence models. The selected sentence models are populated using the selected keywords and predefined or static text, as discussed further below.
In the Findings section of the third display region 2340, a Use Organ Labels feature may be set to Yes for the exam type, in which case the sentences for findings are prefixed with the name of the organ. For example, assume there was a finding of “polyp” in “stomach”. Moreover, the polyp is further detailed by the user selecting the keyword “antrum site” and the branch keyword thereof “anterior wall of the antrum”, the keyword “polyp qualifier” and the branch keyword thereof “broad based”, and the keyword “size of polyp” and the branch keyword thereof “small”. These keywords are indicated in the tree 2363 in the second display region 2362. The sentence model in the report might appear as: “Stomach: A small, broad-based polyp was found arising from the anterior wall of the antrum. (2)”. Here, the notation “(2)” denotes a corresponding image in the Images section 2320 associated with the finding, e.g., image 2. When a sentence for a finding is generated, and there is an image associated with the finding, the image number may be provided at the end of the finding.
Also in the third display region 2340, a sentence model is populated to describe findings regarding a second organ, the esophagus. As indicated in the tree of selected keywords 2363, the user has found food in the esophagus. The food is characterized as being a trace amount, in a location described as the upper third of the esophagus, and the presence of the food is attributed to a motor disorder in the patient. Specifically, after building the lexicon of terms to describe the Findings in the tree 2363, the user clicks the Generate Report icon, and the sentence is generated. The sentence might appear as: “Esophagus: Trace of food was found in the upper third of the esophagus, due to motor disorder.”
Similarly, a Recommendation may appear as the sentence: “Start a low fat diet” based, e.g., on one or more keywords selected by the user under the Recommendation tab. Other example recommendations include “admit for observation”, “consult radiologist”, and so forth.
The sentence models advantageously allow the user to quickly generate reports using standard terminology and sentence structures. Moreover, the generated sentences can be easily edited by substituting one keyword in place of another. For example, under Procedure in the third display region 2340, the user may wish to change “The views were excellent” to “The views were good”. To achieve, this, the user highlights the word “excellent” in the sentence. In response, the display region 2362 is updated to show the portion of the tree 2363 in which the selected keyword “excellent” is located. The keyword “excellent” may appear highlighted in the tree 2363. Additionally, the display region 2364 is similarly updated to show the portion of the keyword tree 2365 in which the keyword “excellent” is located. Moreover, in the tree 2365, “excellent” will appear with other related keywords such as “poor”, “fair” and “good”, which are branches of the same parent node, such as “quality”. The keyword “quality” may in turn be a branch of a parent node “views”, for instance. To replace the keyword “excellent” with the keyword “good”, the user selects “good” from the tree 2365. The tree 2363 is then updated with the keyword “good” replacing “excellent”. Next, the user clicks the Generate Report icon to re-populate the sentence model with “good” in place of “excellent”.
Similarly, a sentence can be edited by adding or deleting a keyword. For example, the user may wish to change “A small, broad-based polyp was found . . . ” to “A broad-based polyp was found . . . ” To achieve this, the user highlights “small” in the sentence and clicks on a delete icon. To add a keyword, the user selects the additional keyword from the tree of available keywords 2365. The keyword is then copied to the tree of selected keywords 2363 and shown in the appropriate hierarchical position in the tree. The user then clicks the Generate Report icon to re-populated the sentence in the third display region 2340. For example, the user may select the additional keyword “small” from the tree 2364 to change the sentence “A broad-based polyp was found . . . ” to “A small, broad-based polyp was found . . . ”
This keyword editing feature is very powerful since it allows the user to modify the report to correct erroneous entries, or to modify entries based on further findings or change in judgment, for instance.
The example sentence models discussed above are normal sentence models since they read as complete sentences rather than as sentence fragments. A normal sentence model also typically incorporates all of the selected keywords associated with the report section. However, it is also possible to associate a keyword in the KB with a summary sentence model. If a selected template has a Summary section and a selected keyword has a summary sentence model, the summary sentence for the keyword appears in the Summary section. For example, if the user finds a polyp in the stomach, the summary sentence might be: “Diagnosis—polyp”. Thus, a report can include both normal and summary sentences.
The Procedure Note function can further be used to select relevant billing codes for the exam. If a keyword has a billing code associated with it, the user would see all billing codes and descriptions associated with the keyword when clicking the Code icon. Relevant billing codes associated with a keyword can be selected for the current exam as discussed previously
To save a Procedure Note, the user accesses the Procedure Note screen and clicks Save. The user can sign a Procedure Note if the Procedure Note text is generated. In one approach, only attending physicians for the examination can sign the Procedure Note. If the Validate & Sign Procedure Note settings are set to Yes, the user will be asked to validate the user ID and password. Signing a note will lock the report from further editing. To sign a report, the user accesses the Procedure Note screen and clicks Sign. Signing a Procedure Note updates a patient's past procedure, past diagnosis, and past surgeries record.
In situations where the user makes changes to an existing Procedure Note and wants to apply those changes to future Procedure Notes, the user saves the modified Procedure Note as a template for generating future Procedure Notes. To save a Procedure Note as template, the user accesses the Procedure Note screen, clicks Save As, assigns a name to the template, selects either a facility or physician name to assign an owner to the template, and clicks Save.
Once a Procedure Note is signed, it is locked and cannot be edited. To make any changes to an existing, signed Procedure Note, the user can create a new version of the Procedure Note. The new version of the Procedure Note is an exact copy of the current signed Procedure Note, without regenerating any sentences or updating any database fields. To generate a new version, the user accesses the Procedure Note screen and clicks New.
Discarded Procedure Notes are stored in a Discard Bin, where they can be viewed but not restored. To discard a Procedure Note, the user accesses the Procedure Note screen, makes sure the Procedure Note is signed, clicks Discard, and clicks Yes.
To delete a Procedure Note, the user accesses the Procedure Note screen, makes sure the Procedure Note is not signed, clicks Delete, and clicks OK.
Maintaining the Knowledge Base
A system administrator is responsible for maintaining the Knowledge Base by adding new keywords, sentence models, and menu structures.
Report Sections are used to generate Procedure Notes for a specific exam type. When the user creates a Procedure Note template, the user can choose to include a few or all the report sections in it. The user can also assign these report sections to a phase of care and then use them in the Lexicon screen as tabs to record data. The user can create, modify, and delete report sections from the Report Section List screen. Examples of report sections include: introduction, indications, procedure, findings, medication, unplanned events, recommendation, summary, and billing codes.
A Phase of Care function can be used to assign specific report sections to a phase of care, namely Registration, Pre-Procedure, Procedure, and Post-Procedure.
To create a Procedure Note template for an exam type, the user uses the Report Template function. To access the Report Template screen, the user navigates to the Admin tab, and selects Customization from the left menu. Available customization options are displayed. The user selects Report Template from the left menu, and the Select Procedure Note Template screen is displayed (FIG. 24). To search for a Procedure Note template/model, the user accesses the Select Procedure Note Template screen, selects an exam type, facility, or physician, and clicks Go. A list of Procedure note templates is displayed, based on the search criteria.
Knowledge Base Framework
The KB provides a controlled vocabulary for reporting results, e.g., of medical examinations and procedures. Discussed below are the three structural layers of the KB, an overview of the use of the KB base by the end user while creating Procedure Notes, the use of selected terms for query purposes, and an interface to maintain the KB.
The KB includes three main layers: Concept Layer, Data Layer and View Layer. The Concept Layer represents a dictionary from which individual words can be selected to build a more complicated grammar. The Data Layer represents the data that describes the Concepts in greater detail. The View Layer organizes the Keywords into groups of terms in a tree structure connected by menus. The view is the primary way for the user to navigate through the knowledge base to select the appropriate medical terms for a given examination type.
In the following discussion, class diagrams are provided according to the Unified Modeling Language (UML). As is known, class diagrams describe the static structure of a system. Classes represent an abstraction of entities with common characteristics. Classes are illustrated with rectangles divided into portions. The name of the class is in the top portion, and the attributes of the class are in the middle portion. Write operations may be provided in the bottom portion.
Moreover, associations represent the relationships between classes. Multiplicity or cardinality notations are indicated near the ends of an association. These symbols indicate the number of instances of one class linked to one instance of the other class, as follows: (a) “1” denotes no more than one, (b) “0 . . . 1” denotes zero or one, (c) “*” denotes many, (d) “0 . . . *” denotes zero or many, and (e) “1 . . . *” denotes one or many. A filled diamond represents a composition relationship, denoting a strong ownership between a “whole” class and a “part” class. A hollow diamond represents a simple aggregation relationship, in which the whole class plays a more important role than the part class, but the two classes are not dependent on each other. The diamond end in both a composition and aggregation relationship points toward the whole class or the aggregate.
Concept Layer (The Dictionary)
FIG. 25 illustrates a conceptual class diagram 2500 of the Concept Layer. The classes are “Concept” and “LUI” (Lexical Unique Identifier). There are one or many instances of “LUI” linked to one instance of “Concept”. Also, there is a composition relationship between “Concept” and “LUI”.
The Concept Layer defines the concepts that can exist in the KB. Concepts are given a textual representation and classified according to the dictionary definition of the concept within this layer. The Concept Layer acts much like a dictionary, defining meanings of concepts, whereas the rest of the knowledge base is more like an encyclopedia, defining concept usage.
Concepts are unique objects within the KB that represent the data that does not change regardless of the context in which the data is used. For example, the word “mass” is defined as a unified body of matter with no specific shape. It may also be defined as a large but nonspecific amount or number. These would be two separate concepts within the KB because they have different meanings. However, a mass within the esophagus and a mass within the colon would be the same concept because they are both a unified body of matter with no specific shape. As discussed further below, this approach advantageously allows accurate querying of indications, findings and other data obtained via the system, which distinguishes when the same word is used in different contexts. Concepts have no inherent relationship to any other concepts within the KB.
LUIs represent a specific version of text that represents a Concept. When the text for a Concept changes, a new LUI is created so that the Concept can still be referred to by its old name. For example, a user of the KB may choose to change the name of the Concept “mass” to “tumor” due to personal preference. In this case, all references to that Concept will have the text of “tumor” unless the specific LUI for “mass” is used.
LUIs are used to “lock” the text of a signed Procedure Note. When a Procedure Note is signed, the application traverses the tree of selected terms and stores the LUIs of the concepts at the time of signing. When the signed report is later amended, the selected items refer to the text that was present at the time of signing until that item is modified at which time the newest LUI is used. The LUI infrastructure could also be extended to accommodate other features where the textual representation of a concept needs to change without the underlying meaning being affected, e.g., for internationalization and synonym support.
Data Layer
FIG. 26 illustrates a conceptual class diagram 2600 of the Data Layer. The Data Layer represents all the knowledge that is contained within the KB. The Data Layer allows the application to understand what a concept means in the context of the KB. The Data Layer can be thought of as an encyclopedia of knowledge as apposed to the Concept Layer, which is a dictionary. For instance, while the dictionary definition of “mass” might be quite simple, an encyclopedia entry for mass could talk about all the different causes for, and descriptions of, a mass/tumor.
Keywords are Concepts that have a defined set of properties. Unlike Concepts, Keywords are linked with other Keywords to define a specific use of a Concept. For example, sample data for a Concept called Mass may include a classification as an Entity/ConceptualEntity/PatientProblem/Finding/ImagingFinding/ProtrudingLesions. The use of the “/” in this notation denote that the item following the “/” is a subclass of the item preceding the “/”. For example, Conceptual Entity is a subclass of Entity, PatientProblem is a subclass of Conceptual Entity, and so forth.
Classifications represent the semantics of Concepts. Through Classifications, Concepts are given a meaning. Classifications are constructed in a hierarchy much like a taxonomic classification of organisms. Taxonomy is the scientific discipline of categorizing various species of organisms into conveniently sized groups, referred to as taxa, which share common, identifiable traits. In one possible implementation, the root of the hierarchy is a classification called Entity, from which all other classifications are derived. The hierarchy is structured so that more specific classifications are lower in the hierarchy. For example, under the root classification of Entity there are two classifications; Physical Object and Conceptual Entity. If a Concept is classified as a Physical Object, like a chair for example, we know that that Concept exists in the physical world and could, for example, be measured. Alternatively if a Concept is classified as a Conceptual Entity, for example, occupation, we know this is not a physical thing and could not be held or touched. For example, with the above approach, the user could formulate a search of the KB to find all patients who had neoplasms. The KB would return patients that had tumors and polyps because both Concepts are classified as neoplasms.

Properties define the set of allowable values for a group of related keywords. A keyword can have any number of properties that are made up of a homogenous list of keywords that all share the same classification or inherit from the same classification. For example, the property Location on Mass has a classification of BodyLocation; this means that any keyword that is also classified as BodyLocation or something derived from BodyLocation, such as Organ, can be assigned as an allowable value to the property. The following table indicates sample properties, classifications and values for the keyword “mass.”

Keyword - Mass

Property	Classification	Values

Location	Entity/PhysicalObject/	esophagus, stomach,
	AnatomicalStructure/	duodenum, distance from entry
	AnatomicalForm/BodyLocation
Appearance	Entity/ConceptualEntity/	nodular, ulcerated, friable,
	FindingModifier/VisualAppearance	firm, frond-like/villous,
		fungating, infiltrative,
		polypoid, submucosal, smooth
Bleeding	Entity/ConceptualEntity/	oozing, spurting, not bleeding,
	FindingModifier/Bleeding	bleeding on contact
Circumferential	Entity/ConceptualEntity/	<25%, 25-49%, 50-74%, 75-99%,
	QuantitativeConcept/Size	specify
Narrowing	Entity/ConceptualEntity/	Extrinsic, intrinsic, uncertain,
	QuantitativeConcept	nodular, friable, firm, ulcerated,
		infiltrative, submucosal, smooth
Obstructing	Entity/ConceptualEntity/	Possible, mild, moderate, severe
	QuantitativeConcept
Size	Entity/ConceptualEntity/	diminutive, small, medium, large,
	QuantitativeConcept/Size	measured (cm), measured (mm)
Stigmata	Entity/ConceptualEntity/	adherent clot, loose clot, spot, visible
	FindingModier/Bleeding	vessel, no bleeding stigmata

FIG. 27 illustrates a conceptual class diagram 2700 of the Sentence Model infrastructure. Sentences define the prose that will be generated for a given set of keyword selections. A sentence model may include up to four different types of placeholders. Text placeholders are used to add static text to the sentence model. Node-placeholders are used as a placeholder for any value of the property specified in the placeholder. Conditional-placeholders are used to generate text that depends on the value or values of a property or properties, respectively, in the sentence model. Trigger-placeholders are used to put the keyword that this sentence model is associated with into the sentence. Moreover, a keyword may be associated with a summary sentence model and/or a normal sentence model. The summary sentence model is used specifically in the summary report section.
The following code illustrates example sentence models. In the examples, text-placeholders are represented surrounded by angle brackets (<>), node-placeholders are represented surrounded by square brackets ([ ]), trigger-placeholders are displayed all in uppercase, and conditional-placeholders are surrounded by curly braces ({ }).

EXAMPLE 1

Finding

<There was a> [Size] [Mass Appearance] TUMOR/MASS <present> {IF ([site]==(distance cm from teeth)) “at” else “in the” } [Site] {IF ([site]!=(whole esophagus) AND [site]!=(Distance cm from teeth) AND [site]==(ANY)) “of the esophagus” ELSE “”} {IF ([site]==(Distance cm from teeth)) “from the entry site” ELSE “”}<.>
The trigger-placeholder “TUMOR/MASS” indicates that the particular sentence model will be populated and displayed on the user interface, such as on the Procedure Note Builder display region 2340 (FIG. 23), when the user selects the keyword “TUMOR/MASS” from the available keywords and clicks the Generate Report icon. The node placeholders [Size] and [Mass Appearance] will be populated by the respective keywords selected by the user for those concepts. For example, [Size] and [Mass Appearance] may be populated by the keywords “large” and “rounded”, respectively. Moreover, note that various conditional statements are used to in the example code above to adjust the grammar of the sentence depending on the keywords selected by the user to characterize the finding. For example, if the “site” is described by a distance in cm from the teeth, the sentence will state: “There was a large rounded tumor/mass present at 10 cm from the teeth”. If the site is described by something other than a distance in cm from the teeth, e.g., the site is described as being the esophagus, the sentence will state: “There was a large rounded tumor/mass present in the esophagus”. The sentence models thus account for the different ways in which information can be provided by the user for the same findings, for instance.

EXAMPLE 2

Medication

<Start> CIPROFLOXACIN [dose][route] {IF ([frequency]==(qpm)) “every evening” ELSE “”} {IF ([frequency]==(q12 h)) “every twelve (12) hours” ELSE “”} {IF ([duration]==(ANY) “for” ELSE “” } [duration]<.>
The trigger-placeholder “CIPROFLOXACIN” indicates that the particular sentence model will be populated and displayed on the user interface, such as on the Procedure Note Builder screen region 2340 (FIG. 23), when the user selects the keyword “CIPROFLOXACIN” from the available keywords and clicks the Generate Report icon. The node placeholders [dose] and [route] will be populated by the respective keywords selected by the user for those concepts. For example, [dose] and [route] may be populated by the keywords “IV” and “2 mg”, respectively. Again, note that various conditional statements are used to adjust the grammar of the sentence depending on the keywords selected by the user to characterize the finding. For example, if the “frequency” is described by 12-hour period (variable “q12 h”), the sentence will state: “Start CIPROFLOXACIN IV 2 mg every twelve (12) hours.”
Triggers are used to signal the application that some action must be taken when the triggering keyword is selected. There are two forms of triggers that can be assigned to a keyword: Education and Recall. An education trigger is used to signal the system that a particular document should be queued for printing when the keyword is selected. A recall trigger is used to generate an item in a recall queue for a patient when the keyword is selected.
Codes are used to associate external codes to a keyword in the KB, primarily for billing. Any number of Codes can be assigned to a keyword. Codes are assigned to a Keyword from a code set, which is the universe of all possible codes for a given code set type.
View Layer
FIG. 28 illustrates a class diagram 2800 of the View Layer. Items are Keywords that appear within a View. Items are grouped into menus when they are inserted into a view. Menus are used to group related items together within a view. Shortcuts are stored selections that will be expanded when selected. Shortcuts are named entities that have their own menu structure. A shortcut menu appears under the parent of the highest-level menu for the shortcut.
Using the Knowledge Base
Procedure Note Data
When terms are selected from a view and associated with an examination, a reference to the keywords, not the terms, is saved. The references are stored in an ordered tree based on the order in which the terms are selected from the view.
Queries
The reference data associated with the examination will be open to queries. The query can look at either the concepts or keywords associated with the examination. For example to find all patients that had a finding of mass in the esophagus, the query could be: findings.mass.location=esophagus. To find all patients that had a finding of mass in the esophagus greater than 2 cm, the query could be: findings.mass.location=esophagus and findings.mass.size>2 cm. To find all patients that had a confirmed diagnosis of cancer in the esophagus, the query could be: diagnosis.(concept.classification=cancer).location=esophagus and diagnosis.(concept.classification=cancer).certainty=confirmed. Thus, the invention allows advanced data mining techniques from a database of patient information. Other techniques that simply search a database by keyword yield less accurate results. For instance, a search for the word “mass” in a database with such techniques might yield a finding stating that “no mass was found” as well as other tangential or irrelevant results.
Maintaining the Knowledge Base
Generally, the KB can be tailored to the user's specific needs. In one possible approach, a complete baseline KB is defined by the developer of the system to enable users such as physicians to immediately use the system. The users can subsequently fine-tune the system to meet their specific needs after gaining experience with the system by employing the following maintenance features.
FIG. 29 illustrates a user interface for adding a keyword to the KB. The KB maintenance user interface 2900 may include a number of tools, including: add menu/term, edit menu/term, add concept, edit concept, add property definition, edit property, remove, copy, past, move up, move down, create shortcut, edit sentence, edit codes and triggers.
In a pop up window 2920, the user enters a new concept named “stomach” in a field 2924. A classification tree 2922 indicates that the classification of the concept is under “organ”. The user can navigate the tree 2922 by clicking on the desired classification. The higher-level classifications in the tree are also shown, up to the top-level classification “Entity”. The user can also enter a plural term for the concept, and a description of the concept, via the window 2920. A classification description is also provided in a grayed out manner to indicate that it cannot be edited. In the display region 2905 of the interface 2900, the classification tree is repeated. A display region 2910 indicates that “esophagus” and “duodenum” are concepts that are related to “stomach” since they are all members of the classification “organ”. The user can check a “specify” checkbox 2925 so that the user is prompted to enter a value to replace the keyword when the report is generated. The data type specified by the drop down menu 2930 determines whether the user is allowed to enter a text or numeric value. Note that the keyword “stomach” is also defined for a certain exam type, e.g., EGD, and for a report section, e.g., Findings. The user can also adjust these factors.
FIG. 30 illustrates a user interface for adding a property definition to the knowledge base. The user interface 3000 includes a display region 3005 indicating that the property definition is for the classification of “body location”.
FIG. 31 illustrates a user interface 3100 for editing a keyword in the knowledge base. A tree 3120 indicates that the user has selected the keyword “ulcer”. The concept “ulcer” is presented in a grayed out manner to indicate it cannot be edited. The sentence name can be edited if desired. If the keyword is a “specify” type item that prompts the user for a value, the check box 3125 will be checked, and the user will be allowed to determine its data type with the drop down menu 3130.
FIG. 32 illustrates a user interface 3200 for editing properties of a keyword in the knowledge base. The keyword tree 3120 is the same as shown in FIG. 31. A display region 3210 allows the user to edit the properties of a keyword, such as “size”. The classification of the keyword is identified as a quantitative concept. The user selects one or more keywords for the quantitative concept from a pop up window 3230. The selected keywords are then copied to a display region 3220 as available values for detailing the property of “size”. The user may check a checkbox 3225 to indicate that a value for size is required to be entered by the user, e.g., when reporting the findings of a procedure.
FIG. 33 illustrates a user interface 3300 for assigning properties to a keyword in the knowledge base. The user selects a classification from the Select Class tree. A display region 3340 indicates the properties available in the selected class, and a user may choose a property to assign to the keyword. In window 3310, the user may create a new property by assigning it to a classification.
FIG. 34 illustrates a user interface 3400 for adding and editing codes in the knowledge base. The keywords are provided in the tree 3410. A pop up window 3430 allows the user to select codes such as for billing. For example, the user may choose a code set from a drop down menu, and one or more individual codes. A display region 3420 displays the selected codes.
FIG. 35 illustrates a user interface 3500 for adding and editing sentence models in the knowledge base. The tree 341 0 is the same as in FIG. 34. The keywords in the tree 3410 that trigger a sentence model may be highlighted, e.g., in bold font. A display region 3520 provides the sentence model for the normal or full sentence, while the display region 3530 provides the summary sentence model. The placeholder terms in brackets may be highlighted in yellow, for instance. The pop up window 3540 indicates the available nodes that the user may choose to insert into the sentence model.
FIG. 36 illustrates a user interface 3600 for adding a condition in a sentence model in the knowledge base. For example, the user may desire to add a conditional placeholder to the sentence model in the display region 3520. To do this, the user positions the cursor to a location in the sentence model in which the conditional placeholder is to be added, and clicks on the “conditional” icon, causing the window 3630 to pop up. The window 3630 allows the user to define a condition, operator, and values. The user also defines the text that is to be entered in the sentence model depending on whether or not the condition is met. The user can click on an icon 3635 to cause a window 3640 to pop up that display values from which to select. Once the user defines the conditions, corresponding code, such as in the C language, is generated in the sentence model. The example sentence model in the display region 3620 is simplified. In practice, detailed sentence models contain several conditional statements to account, e.g., for variations in the way a finding can be described, the level of detail, grammatical concerns and so forth.
FIG. 37 illustrates a user interface 3700 for adding and editing triggers in the knowledge base. As mentioned previously, selected keywords may trigger an action such as printing a document or scheduling a patient recall. For instance, the user may select the keyword “polyp” from the keyword tree 3705. In a display region 3710, the user checks a check box 3720 to set an education trigger. Additionally, a document is selected from a drop down menu 3725 to identify a relevant document to provide to the patient. The document may be printed and handed to the patient during the patient's examination, mailed to the patient's home, or emailed to the patient, for instance. Another checkbox sets a recall reminder for a given number of days, weeks or months, based on a second drop down list. A follow-up examination may be scheduled based on the recall.
FIG. 38 illustrates a user interface 3800 for adding a keyword item to a menu in a view. The user selects a menu such as “colon findings” in the tree 3810, then selects from a menu of available terms in a list 3820, after selecting a classification in region 3830 to display a list of available keywords in the selected classification.
FIG. 39 illustrates a user interface 3900 for adding a menu in the knowledge base. The user selects a keyword, e.g., “normal”, from the tree 3910, for which the menu is to be provided. Assume the user desires to add a menu for “rectal sites” under “normal” in the tree 3910. To do this, the user types in the menu name in a display region 3920. Other factors, such as menu type, can also be defined.
FIG. 40 illustrates a user interface 4000 for creating a shortcut in the knowledge base. With this feature, the user can select multiple keywords at a time, which is desirable when the same group of keywords is selected over and over, e.g., for different patients. The user provides pre text 4025 for the report, which appears prior to the selected keywords, and post text 4030, which appears after the selected keywords. When the user selects the multiple keywords from the tree 4010, a sentence model is populated to provide a preview 4035 of the resulting sentence.
FIG. 41 illustrates a user interface 4100 for editing a shortcut in the knowledge base. The shortcut named “Std Meds” was created using the interface 4000 of FIG. 40. The keyword “Shortcuts” appears in the tree 4110 along with the specific shortcut “Std Meds”. The user can quickly generate the report in the display region 4120 by selecting the keyword “Std Meds”.
Grammar Engine
As discussed, the user may automatically generate a report from selected keywords by clicking on the Generate Report icon. Furthermore, a grammar checking routine or grammar engine may be used to correct or optimize the grammar in the populated sentences. The grammar engine may be run automatically when a sentence is populated. Various grammar engines, including those known in the art, may be used.
A grammar engine can be helpful for various reasons, such as ensuring that the verb and subject of a sentence agree, providing correct punctuation and capitalization, and ensuring that singular and plural nouns are properly modified. In one possible approach, a grammar engine includes three main components. First, a part-of-speech tagger assigns a part of speech (POS) tag to each word or word component (e.g., noun or verb) in the generated sentence. Second, a lexical analyzer is run to break the sentence into grammatical components, phrases, and clauses. The final portion updates the sentence with the necessary corrections.
Each keyword in the KB may be assigned a primary tag by default that identifies the most likely grammatical characteristic of the keyword in the domain in which it is used. Tags for other allowable grammatical characteristic may also be provided. Tags may also be provided for the words in a sentence that are not keywords, such as static text. Example grammatical characteristics identify a word as being, e.g., an adjective, singular noun, plural noun, adverb and so forth. The tag may be a two-letter codeword, for instance.
FIG. 42 illustrates user interfaces for a grammar engine. In accordance with a further aspect of the invention, user interfaces may be provided that allow a user to set grammatical characteristics, and view existing characteristics, for keywords or groups of keywords in the KB for use by a grammar engine. This allows the user to tailor the system to the user's preferences and needs, as well as to gain a better understanding of the operation of the grammar engine. A first interface 4200 allows the user to search a dictionary of terms. “Dilated bile duct” is an example. The interface indicates that the term has been assigned to the grammatical characteristic or category of NN, denoting a singular noun. The user then clicks on “edit” to edit the dictionary entry definition. A user interface 4220 provides the name of the entry and the base word, e.g., “duct”. The user can use check boxes, drop down menus and other widgets to set the grammatical characteristics of the entry. For example, the part of speech can be changed by clicking on the “edit” button, thereby causing the user interface 4240 to appear. The interface 4240 provides a list of available grammatical characteristics on the left hand display region 4242 and the one or more assigned characteristics on the right hand display region 4244. The user can assign an available characteristic by clicking on the characteristic in the display region 4242 and clicking on the right-pointing arrow. Similarly, the user can delete an assigned characteristic by clicking on the characteristic in the display region 4244 and clicking on the left-pointing arrow. When multiple characteristics are assigned, the user designates one of them as a primary characteristic by selecting the characteristic and clicking on the “primary” button in the display region 4244.
The invention has been described herein with reference to particular exemplary embodiments. Certain alterations and modifications may be apparent to those skilled in the art, without departing from the scope of the invention. The exemplary embodiments are meant to be illustrative, not limiting of the scope of the invention, which is defined by the appended claims.

Claims

1. A method for generating a report regarding a procedure, comprising:

displaying available keywords from a knowledge base on a first display region of a user interface;

receiving, via the user interface, at least one user command selecting at least one of the available keywords from the first display region;

displaying the at least one of the available keywords on a second display region of the user interface, responsive to the selection thereof by the at least one user command;

populating a sentence model according to the at least one of the available keywords to provide a populated sentence; and

displaying the populated sentence on a third display region of the user interface.

2. The method of claim 1, wherein:

the populating the sentcnce model comprises selecting the sentence model from among a plurality of available sentence models according to the at least one of the available keywords.

3. The method of claim 1, farther comprising:

editing the populated sentence by: (a) receiving, via the user interface, at least one user command selecting the at least one of the available keywords in the populated sentence, and at least one user command selecting another of the available keywords from the first display region, and (b) re-populating the sentence model using the another of the available keywords in place of the at least one of the available keywords.

4. The method of claim 1, wherein:

the displaying the populated sentence comprises displaying the populated sentence with the at least one of the available keywords highlighted therein.

5. The method of claim 1, wherein:

the populating the sentence model comprises providing static text in at least one text placeholder.

6. The method of claim 1, wherein:

the populating the sentence model comprises providing a specified property value in at least one node placeholder.

7. The method of claim 1, wherein:

the populating the sentence model comprises generating text in the at least one sentence that depends on the value of a property.

8. The method of claim 1, wherein:

the receiving comprises receiving, via the user interface, at least one user command selecting a plurality of the available keywords from the first display region;

the populating the sentence model comprises populating the sentence model according to the plurality of the available keywords to provide the populated sentence; and

the sentence model comprises a summary sentence model in which fewer than all of the plurality of the available keywords are used.

9. The method of claim 1, wherein:

the rccciving comprises receiving, via the user interface, at least one user command selecting a plurality of the available keywords from the first display region;

the sentence model comprises a normal sentence model in which all of the plurality of the available keywords are used.

10. The method of claim 1, further comprising:

receiving, via the user interface, at lest one user command setting a grammatical property of the at least one of the available keywords;

analyzing a grammar of the at least one populated sentence based on the grammatical property.

11. The method of claim 1, wherein:

the displaying the available keywords comprises displaying the available keywords on the first display region organized according to at least one hierarchical menu wherein related keywords are child keywords of a parent keyword.

12. The method of claim 11, wherein:

the receiving comprises receiving, via the user interface, at least one user command selecting a plurality of the available keywords from the first display region; and

the displaying the at least one of the available keywords comprises displaying the plurality of the available keywords on the second display region organized according to at least one hierarchical menu in accordance with the at least one hierarchical menu in the first display region.

13. The method of claim 11, wherein:

the child keywords qualify the parent keyword.

14. The method of claim 1, wherein:

the receiving comprises receiving, via the user interface, a shortcut command for selecting multiple keywords at a time from the available keywords.

15. The method of claim 1, further comprising:

receiving at least one user command for maintaining the knowledge base.

16. The method of claim 15, wherein:

the at least one user command for maintaining the knowledge base comprises at least one user command for adding a keyword to the knowledge base.

17. The method of claim 15, wherein:

the at least one user command for maintaining the knowledge base comprises at least one user command for editing properties of the at least one of the available keywords.

18. The method of claim 15, wherein:

the at least one user command for maintaining the knowledge base comprises at least one user command for associating a billing code with the at least one of the available keywords.

19. The method of claim 15, wherein:

the at least one user command for maintaining the knowledge base comprises at least one user command for at least one of creating and editing the sentence model.

20. The method of claim 15, wherein:

the at least one user command for maintaining the knowledge base comprises at least one user command for at least one of adding and editing a trigger for the at least one of the available keywords.

21. The method of claim 1, further comprising:

displaying at least one image obtained from the procedure in a fourth display region of the user interface.

22. A method for providing keywords for generating a report regarding a procedure, comprising:

providing respective keywords for use in the report;

associating each of the respective keywords with a respective classification in a hierarchically arranged tree structure of classifications;

associating respective properties with the respective keywords; and

defining, based on the respective properties, a set of allowable values for a group of the respective keywords;

wherein the group of the respective keywords are related.

23. The method of claim 22, wherein:

the group of the respective keywords which are related are associated with the same classification.

24. The method of claim 22, wherein:

the group of the respective keywords which are related inherit from the same classification.

25. The method of claim 22, further comprising:

displaying the available keywords on a first display region of a user interface organized in a first tree structure that is based on the hierarchically arranged tree structure of classifications;

receiving, via the user interface, at least one user command selecting at least one of the available keywords from the first tree structure;

displaying the at least one of the available keywords on a second display region of the user interface, responsive to the receiving, in a second tree structure that is based on the first tree structure.

26. The method of claim 22, further comprising:

displaying the populated sentence on the user interface.

27. The method of claim 22, further comprising:

querying a database containing the keywords based on at least one of the respective classifications.

28. A user interface for assisting a user in generating a report regarding a procedure, comprising:

a first display region displaying available keywords from a knowledge base;

wherein the user provides at least one user command selccting at least one of the available keywords from the first display region;

a second display region displaying the at least one of the available keywords responsive to the selection thereof by the at least one user command; and

a third display region displaying a populated sentence that is provided by populating a sentence model according to the at least one of the available keywords.

29. A program storage device tangibly embodying a program of instructions executable by a machine to perform a method for providing keywords for generating a report regarding a procedure, the method comprising:

providing respective keywords for use in the report;

associating respective properties with the respective keywords; and

wherein the group of the respective keywords are related.