Abstract:
A computing device-based system and method are described for generating a medical procedure description recorded into the system by a physician. The system and method manipulate a set of database records comprising medical content which is naturally descriptive of clinical procedures and clinically accurate diagrams which are naturally descriptive to document a medical procedure. To support the generation of a set of said medical procedure descriptions, the system and method provide interchangeable, connected, ontologically-based medical procedure database cartridges of medical content terms, rules, and diagrams that naturally describe constrained procedure representations for clinical procedure descriptions.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims priority to U.S. patent application Ser. No. 10/745,759 filed on Dec. 23, 2003, entitled NATURALLY EXPRESSED MEDICAL PROCEDURE DESCRIPTIONS GENERATED VIA SYNCHRONIZED DIAGRAMS AND MENUS, the disclosure of which is hereby incorporated by reference in its entirety. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The field of the present invention generally relates to systems and methods for medical procedure documentation, and in particular to a system and method for generating naturally expressed medical procedure descriptions via a synchronized diagram and menu system. 
       BACKGROUND OF THE INVENTION 
       [0003]    The invention generally relates to graphical user interfaces, and more particularly to a graphical user interface used by physicians to quickly and concisely document procedures and/or exams conducted in healthcare facilities. 
         [0004]    The development of graphical user interfaces started in the development labs of Xerox, IBM, and others and eventually made it to the public domain via the introduction of the Apple LISA personal computer, X-Windows on Unix terminals, TopView from IBM, and Windows from Microsoft. As the graphical user interface established itself as the primary means of computer to human interfacing there have been various methods seeking to improve the look, the feel, and the speed at which information is transferred from the end user to the software application and database operating under a graphical user interface. The present invention serves to improve upon these already developed methods by tying together methods that have been heretofore not engineered in a way the benefits the physician during their documentation of medical procedures and exams. The traditional method of physician medical procedure documentation is via the dictation and transcription model. Several vendors have developed structured methods of medical procedure documentation that are based on menus and menu trees. Other structured methods have been based on anatomic diagrams and annotating diagrams with text that documents findings, intervention, and maneuvers conducted during the medical procedure. A structured language bridge or ontology does not exist that uniquely matches up the documentation conducted via the menu method and the diagram method. 
         [0005]    The invention allows the physician to generate naturally expressed medical procedure descriptions via a synchronized diagram and menu system. The physician is free to choose either method of documentation, either via a diagram or via a menu system. Entries or changes in one method of documentation are automatically synchronized with the other. This enables the physician to quickly and concisely generate naturally expressed medical procedure descriptions in a method that suits their needs. 
         [0006]    There are systems and methods that address these issues. However, the prior art does not sufficiently address the issue of providing an efficient and effective means to solve these problems. There are several software systems in the public domain that allow for the entry of information via a menu system and several software systems that allow documentation and annotations to be completed via a diagram but none of the prior art brings these two methods together in a synchronized manner. 
         [0007]    It would therefore be advantageous to have a method and system for designing and implementing a system and method for generating naturally expressed medical procedure descriptions via a synchronized diagram and menu system. In this manner, physicians are able to describe their procedures in a clinical style that is natural to the physician with alternative user interface methods that allows for the rapid entry of concise and complete medical procedure documentation. 
         [0008]    The object of the invention is to provide a concise and complete procedure documentation system that generates naturally expressed medical procedure descriptions by allowing the physician to work with a user interface that is consistent with their style of documentation for their medical specialty. For example, cardiologists typically utilize pictures to describe their findings when speaking with the patient&#39;s family in the waiting room. The physician draws a heart showing the patient&#39;s family the findings and interventions that they encountered during the procedure. Afterward, the physician has to dictate their note and wait for the transcription to return before they are “completed” with the procedure. With the invention in place, the physician can utilize the diagram documentation method and use these diagrams as part of the procedure description and also use the diagrams to show the patient&#39;s family the findings and interventions. 
         [0009]    It is another objective of the invention to keep the two methods of documentation synchronized to ensure that the documentation is correct independent of the method of data entry. The synchronization will additionally help to reduce medical errors. For example, the physician could document their procedure completely by using the diagrams and the documentation generated by the invention would have all of the information necessary to correctly assign the CPT and ICD9 codes associated with the medical procedure. Alternatively, the physician could document their procedure completely by using the menuing system and the documentation generated by the invention would have all of the information necessary to correctly assign the CPT and ICD9 codes associated with the medical procedure. The physician could choose to use either method during the procedure documentation process and the invention would keep the data synchronized. 
         [0010]    Thus, as will be appreciated from a review of the drawings and detailed descriptions of the preferred embodiments, the present invention overcomes the significant limitations and shortcomings of the prior art. 
       SUMMARY OF THE INVENTION 
       [0011]    The benefits of this invention will become clear and will be best appreciated with reference to the detailed description of the preferred embodiments. Other objects, advantages, and novel features will be apparent from the description when read in conjunction with the appended claims and attached drawings. 
         [0012]    The present invention is an automated medical procedure documentation method utilizing a synchronized menu and diagramming system to generate the naturally expressed medical procedure descriptions. 
         [0013]    A computer based system and method are described for generating naturally expressed medical procedure descriptions via a synchronized diagram and menu system which concisely and completely summarizes a clinical procedure description recorded into the system by a physician. The system and method manipulate a set of database records comprising medical content, such as procedure descriptions and medical diagrams which are naturally descriptive of clinical procedures. 
         [0014]    The system provides the features that eliminate the error prone process of dictation and the often lengthy delays associated with transcribing, reviewing, recreating, and approving transcripts. Additionally, the system provides a diagram that can be used in a natural way to describe the findings, interventions, etc. that are part of the medical procedure. A minimal learning curve is required to become productive when using the invention. 
         [0015]    The system&#39;s document driven charge capture module completes the process by transferring the documentation to the healthcare facilities billing system. 
         [0016]    The present invention is a software program operating on a single general purpose computing device or a plurality of computing devices interconnected via a network system. The procedure documentation is readily available for review, print, fax, email operations. 
         [0017]    The invention interface comprises a set of procedure descriptors designed as anticipatory driven drop down menus that controls the information input by a physician to document a medical procedure and an interface that allows for a simple interaction between a diagram and icons that represent, for example, various procedure or exam based findings, maneuvers, and interventions. The invention uses an anticipatory menu physician interface, which emulates a typical procedural workflow and a clinician&#39;s thought processes, instantly and automatically adapting to each piece of information that is input by the physician with a corresponding anatomic diagram that is tied to the procedure being documented. 
         [0018]    A procedure description narrative is constructed based on the initial procedure category selected by a physician. As the physician documents the procedure using the anticipatory interface menus, the narrative is edited as the next procedure description item is selected from a next menu in the documentation process. While the physician is documenting the procedure using the anticipatory interface menus, a concurrent process is taking place that creates the synchronized diagram for printing, review, or editing. At the completion of the procedure documentation process, the procedure description narrative is completed and its description fields are filled in. The system reduces the time spent by the physician paging through a maze of screens to find the correct place to record information. The system also reduces the time spent by the physician scrolling through dozens of pull-down menus or the time spent by the physician reading through endless lists of words in search for terminology appropriate for the procedure at hand. The system reduces the time spent by the physician in documenting their procedure description by allowing the physician to document via a method that is more intuitive to their style. 
         [0019]    Alternatively, the physician can invoke the diagram method of documentation and be presented with a diagram that presents the anatomy of the patient specific to the procedure being documented with icons representing various maneuvers, findings, and interventions. Certain elements of the diagram method are better represented with menus and thus the menu system is invoked to augment the diagram method of generating naturally expressed medical procedure descriptions. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0020]    The present invention can be better understood with reference to the following diagrams. The components within the drawings are not necessarily to scale relative to each other, emphasis instead being placed upon clearly illustrating the principles of the present invention. 
           [0021]      FIG. 1  is a graphical view illustrating a computing device called a personal computing device. 
           [0022]      FIG. 2  is a graphical view illustrating a computing device called a laptop computing device. 
           [0023]      FIG. 3  is a graphical view illustrating a computing device called a personal digital assistant. 
           [0024]      FIG. 4  is a graphical view illustrating a computing device called a tablet pc. 
           [0025]      FIG. 5  is a graphical view illustrating a computing device called a portable device monitor. 
           [0026]      FIG. 6  is a graphical view illustrating a computing device called a data acquisition computing device. 
           [0027]      FIG. 7  is a graphical view illustrating a computing device called a stationary device monitor. 
           [0028]      FIG. 8  is a graphical view illustrating a computing device called an image capture computing device. 
           [0029]      FIG. 9  is a graphical view illustrating a typical configuration of system architecture. 
           [0030]      FIG. 10  is a graphical view illustrating the physical connections in a typical configuration of a system within the healthcare facility. 
           [0031]      FIG. 11  is a graphical view illustrating the physical connections in a WAN and internet configuration of the system. 
           [0032]      FIG. 12  is a graphical view illustrating the logical connections between the clients and servers. 
           [0033]      FIG. 13  is a screen shot illustrating the physician logon screen for the system. 
           [0034]      FIG. 14  is a screen shot illustrating the form that allows the physician to select the specialty for the procedure documentation. 
           [0035]      FIG. 15  is a screen shot illustrating the main selection form for the launching of the procedure documentation component. 
           [0036]      FIG. 16  is a screen shot illustrating the anticipatory physician interface of system. 
           [0037]      FIG. 17  is a screen shot illustrating the scheduling component of the system. 
           [0038]      FIG. 18  is a screen shot illustrating the system&#39;s physician interface after selecting a patient that has undergone a procedure. 
           [0039]      FIG. 19  is a screen shot illustrating the system&#39;s physician interface prompting the physician for the procedure name for the procedure that is requiring documentation. 
           [0040]      FIG. 20  is a screen shot illustrating the system&#39;s diagramming physician interface. 
           [0041]      FIG. 21  is a screen shot illustrating the system&#39;s physician interface prompting the physician to select a procedure that is requiring documentation. 
           [0042]      FIG. 22  is a screen shot illustrating the system&#39;s physician interface after the physician has selected a procedure. 
           [0043]      FIG. 23  is a screen shot illustrating the system&#39;s physician interface prompting the physician for the next attribute for the procedure that is requiring documentation. 
           [0044]      FIG. 24  is a screen shot illustrating the system&#39;s physician interface which displays the finding menu with the Diagram Documentation menu selection. 
           [0045]      FIG. 25  is a screen shot illustrating the system&#39;s diagramming physician interface. 
           [0046]      FIG. 26  is a screen shot illustrating the system&#39;s diagramming physician interface after a stenosis has been selected. 
           [0047]      FIG. 27  is a screen shot illustrating the system&#39;s diagramming physician interface after a stenosis has been placed in an artery. 
           [0048]      FIG. 28  is a screen shot illustrating the system&#39;s diagramming physician interface requiring additional data entry for the procedure. 
           [0049]      FIG. 29  is a screen shot illustrating the system&#39;s diagramming physician interface requiring additional data entry for the procedure. 
           [0050]      FIG. 30  is a screen shot illustrating the system&#39;s diagramming physician interface requiring additional data entry for the procedure. 
           [0051]      FIG. 31  is a screen shot illustrating the system&#39;s diagramming physician interface after all data entry is completed and before physician selects the save button. 
           [0052]      FIG. 32  is a screen shot illustrating the system&#39;s physician interface after returning from the diagramming physician&#39;s user interface. 
           [0053]      FIG. 33  is a screen shot illustrating the system&#39;s physician interface requiring additional data entry for the procedure. 
           [0054]      FIG. 34  is a screen shot illustrating the system&#39;s physician interface requiring additional data entry for the procedure. 
           [0055]      FIG. 35  is a screen shot illustrating the system&#39;s physician interface requiring additional data entry for the procedure. 
           [0056]      FIG. 36  is a screen shot illustrating the system&#39;s physician interface requiring additional data entry for the procedure. 
           [0057]      FIG. 37  is a screen shot illustrating the system&#39;s physician interface requiring additional data entry for the procedure. 
           [0058]      FIG. 38  is a screen shot illustrating the system&#39;s physician interface requiring additional data entry for the procedure. 
           [0059]      FIG. 39  is a screen shot illustrating the system&#39;s physician interface after two stenosis have been documented via the menuing system. 
           [0060]      FIG. 40  is a screen shot illustrating the system&#39;s physician interface which displays the finding menu with the Diagram Documentation menu selection. 
           [0061]      FIG. 41  is a screen shot illustrating the system&#39;s diagramming physician interface which shows the stenosis documented in the menu system displayed in the diagramming physician interface. 
           [0062]      FIG. 42  is a screen shot illustrating the system&#39;s diagramming physician interface for the diagram documentation related to Echocardiography. 
       
    
    
     DETAILED DESCRIPTION 
       [0063]    Reference will now be made in detail to the present preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings, wherein like reference numerals refer to like elements throughout. 
         [0064]    Referring to  FIG. 9 , the present invention includes a plurality of general purpose computing devices interconnected in networked configuration. Referring to  FIG. 11 , this networked configuration can be in the form of a LAN, WAN, ISDN, Internet, or wired or wireless networked configuration. Referring to  FIG. 1  to  FIG. 8 , the general purpose computing devices can be any of a personal computing device  100 , a laptop computing device  200 , a Pocket PC  300 , a tablet pc  400 , a portable device monitor  500 , a data capture computing device  600 , a stationary device monitor  700 , or an image capture device  800 . The computing device can additionally or alternatively be any of the commonly known Windows/Intel PC, Apple Computers, Citrix ICA computers, Unix Workstations, and Linux workstations, and can be produced by vendors including but not limited to Sun, IBM, Compaq, Dell, Apple, and HP. 
         [0065]    Referring to  FIG. 10 , the general purpose computing devices communicate with a database server via standard TPC/IP network wireless or wired protocols. The database, which includes a knowledge base in the form of a plurality of medical content specialties, is managed by the database server. The database can be any known database, such as relational, Object, text based, XML based, object-relational, and flat file, produced by vendors including but not limited to Oracle, Microsoft, Sybase, IBM, Computing device Associates, and Informix. The networked computing device system can be any of TPC/IP, Peer-to-Peer, Wireless, RPC, IPX/SPX, DLC, and Windows Networking, and can be produced by vendors including but not limited to IBM, Novell, Apple, RedHat, Unix, BSD, and Microsoft. 
         [0066]    A plurality of printers is also included in this configuration. The computing devices may have their own local printers. 
         [0067]    The system is written with commercially available application development and database applications. The system can be written in any programming language using commercially available database system. Referring to  FIG. 12 , the current system runs on Windows computing devices but the present invention is not limited to any specific operating systems, programming language, database vendor, or computing device. 
         [0068]    Referring to  FIG. 16 , a physician uses the invention by going through the anticipatory system menus to document the procedure or by using the diagramming method to document the procedure. The system is designed so that the physician is presented with natural procedure descriptors, in a manner that the physician would expect, and in a manner in which the physician would describe the procedure. Additionally, the system is designed so the physician can document his or her work in a diagramming method and that all of the necessary pieces of documentation are captured to ensure correct CPT and ICD9 coding. 
         [0069]    To maximize the value of the information maintained by the system, it is important to facilitate both information entry, to ensure that the system can access all pertinent information, and information retrieval, to ensure that the information is accessible and that such retrieved information is accurately provided to the provider for proper interpretation. Further, the physicians must have confidence that the information is accurate, secure, and fail-safe; otherwise, physicians will be reluctant to rely upon the system for maintaining medical information. 
         [0070]    In a typical configuration, the program modules of the system are organized in a multi-tier architecture. Several computing devices throughout the healthcare facility are equipped with the client-side components of the system, which can access other server-side components located on other computing devices via the network. The client-side system components physician user interface comprises a number of screens in a computing environment that prompts the physician for input and displaying output. 
         [0071]    Examples of suitable user interfaces include traditional Windows clients, browser/HTML based, J2EE, JAVA, XML based, Windows Forms, Windows .NET, Windows FX, speech recognition, speech navigation, and Pocket PC interfaces. These may be produced by vendors including but not limited to IBM, Novell, Apple, Sun, and Microsoft. 
         [0072]    While the preferred implementation for a hospital setting is a network environment, many of the system functions, including the physician interface and data management functions can be performed on a single computing device. 
         [0073]    The discussions are intended to provide a brief, general description of a suitable computing environment for the server and client computing devices. As noted previously, the system is implemented as a series of program modules, comprising computer executable instructions executed either on a server or client computing device. Generally, program modules include routines, programs, components, and data structures that perform specific coordinated and synchronized tasks. 
         [0074]    The physician logs on to the system with a user name and password  1300   FIG. 13 . After securing access to the system, referring now to  FIG. 14 , the physician is presented with a screen that allows them to select the specialty area for procedure documentation  1400 . Referring now to  FIG. 15 , the physician is presented a listing of procedures that need procedure documentation  1500 . The listings of procedures  1500  is typically generated by a scheduling interface or by scheduling personnel using the scheduling module  1700 ; see  FIG. 17 . The physician begins the documentation of the procedure by selecting rows of data in the listing of procedures  1500 . The physician user interface then displays a screen illustrated in  FIG. 18 . 
         [0075]      FIG. 18  is a screen shot illustrating the operation of a system program  1800 , and more particularly the navigation tree and report area, according to an embodiment of the present invention. Referring now to  FIG. 18 , the display of the system program typically comprises a navigation tree  1801 , a report area  1802 , a program function icon area  1806 , and a program function menu bar  1805 . The system stores the data in a commercially available SQL database. The database is comprised of programming logic in the form of Structured Query Language SQL stored procedures and data tables. 
         [0076]    Referring to  FIG. 18 , the navigation tree  1801  is comprised of several nodes  1809 ,  1807  that represent distinct areas of report documentation. One specific node, Note Record  1808  contains demographic information about the patient that is typically entered by the nursing or front desk personnel but can be automatically populated by an interface from the hospital information system. After entering data into the sub-nodes  1809  detailed within the Note Record  1808 , the data is automatically copied to the demographic subsection  1803  of the report area  1802 . Additional data is entered via the navigation tree  1801  by clicking on other nodes  1807 . The data entered is automatically copied to subsection  1804  of the report area  1802 . 
         [0077]    The invention utilizes a well known and established object oriented design pattern documented in the book “Design Patterns-Elements of Reusable Object Oriented Software” by Gamma, Helm, Johnson, and Vlissides coupled with the invention&#39;s ontology inference engine that enables a documentation method utilizing a synchronized menu and diagramming system to generate the medical procedure descriptions. 
         [0078]    The well-known object oriented design pattern is called the Observer Pattern in the book but is known by other names such as the Publish-Subscribe model. The key objects in the algorithm are the subject and observer. A subject may have any number of dependent observers. All observers are notified whenever the subject undergoes a change in state. In response, each observer will query the subject to synchronize its state with the subject&#39;s state. This kind of interaction is also known as publish-subscribe. The subject is the publisher of notifications. It sends out these notifications without having to know who its observers are. Any number of observers can subscribe to receive notifications. 
         [0079]    Referring to the present invention, the system is managed by two primary subjects called Main Document and Diagram Document with a number of observers for each subject. Main Document and Diagram Document are programming object code that are responsible for keeping track of its observers and holding data before it is written to the database. The Main Document subject is responsible for the procedure note documentation functionality, see  FIG. 19 . The Diagram Document subject is responsible for the diagram documentation functionality, see  FIG. 20 . 
         [0080]    Referring to  FIG. 19 , the Main Document subject  1900  has two observers, Tree Menu  1901  and Edit Window  1902 . Referring to  FIG. 20 , the Diagram Document subject  2000  has two observers, Diagram Tree Menu  2001  and Diagram Window  2002 . 
         [0081]      FIG. 21  is a screen shot illustrating the first step in the constructing of a procedure description. After the physician selects a patient record to document, the system creates a subject called Main Document and two observers called Tree Menu and Edit Window. The system informs the subject of its observers and the subject is now in control of the application. Main Document calls its observers, Tree Menu and Edit Window informing them that they need to get coordinated. After receiving this information from the subject, Main Document, the observers, Tree Menu and Edit Window, query the subject and retrieve the data that has changed. 
         [0082]    Referring now to  FIG. 21 , the observers display the data which was retrieved  2100  from the Main Document subject. Main Document retrieved this data from the medical content database. The Tree Menu observer additionally has logic that auto-navigates the cursor to the most frequent procedure documented in the selected specialty  2101 . Referring to  FIG. 21 , this is the menu selection Cardiac Cath  2101 . In other medical specialties supported by the system, Tree Menu will automatically navigate to a node labeled Procedure Category. The physician also has the ability to navigate to the procedure node from any other node in the navigation tree. 
         [0083]    The physician next selects their procedure from the menu  2100 . The observer, Tree Menu, observes the menu selection and informs the subject, Main Document, of the data change. Main Document may be uncoordinated with its observer&#39;s Tree Menu and Edit Window and informs them that they need to get coordinated. The observers react to this message and then query the subject, Main Document, for the change in data and the screen is refreshed with the data selected, see  FIG. 22 . Tree Menu displays the menu selection  2201  underneath the procedure node and Edit Window displays the long name of the procedure  2200 . The subject, Main Document, and the observers, Tree Menu and Edit Window, are now synchronized. 
         [0084]    Referring now to  FIG. 23 , the physician is next presented with a pertinent medications menu  2300 . The same interactions described above between the subject, Main Document and the observers, Tree Menu and Edit Window, occur each time a menu is presented and selected by the physician. The physician makes the menu selection. The observer, Tree Menu, observes the menu selection and informs the subject, Main Document, of the data change. Main Document may be uncoordinated with its observer&#39;s Tree Menu and Edit Window and informs them that they need to get coordinated. The observers react to this message and then query the subject, Main Document, for the change in data and the screen is refreshed with the data selected. Tree Menu displays the menu selection underneath the corresponding node and Edit Window displays the text associated with the menu selections. The subject, Main Document, and the observers, Tree Menu and Edit Windows, are now synchronized. 
         [0085]    The physician could continue to document their procedure note using the aforementioned method. Alternatively, the physician could choose to document the procedure using the diagramming approach, see  FIG. 20 . The diagram approach utilizes a subject called Diagram Document and two observers called Diagram Tree Menu and Diagram Window. Referring to  FIG. 24 , the diagram method of procedure documentation can be activated any number of ways and in this example, the activation is initiated via a menu selection called Diagram Documentation  2400 . 
         [0086]    After the physician selects the menu selection, Diagram Documentation  2400 , the system creates a subject called Diagram Document and two observers called Diagram Tree Menu and Diagram Window. The system informs the subject of its observers and the subject is now in control of the application. Diagram Document calls its observers, Diagram Tree Menu and Diagram Window informing them that they need to get coordinated. After receiving this information from the subject the observers, Diagram Tree Menu and Diagram Window query the subject and retrieve the data that has changed. 
         [0087]    The data retrieved by the observers is processed by the ontology inference engine. The ontology inference engine maps the data elements between the menu data elements and diagram data elements. This mapping enables the synchronization between the two disparate representations of data. 
         [0088]    Referring now to  FIG. 25 , the observers, Diagram Tree Menu and Diagram Window, display the data  2500  which was retrieved from the Diagram Document subject. Diagram Document retrieved this data from the medical content database and the information associated with the selected patient. The diagram displayed was a diagram that was linked to a specific set of procedures. In this example, nothing has been previously documented therefore the diagram that is shown is the default diagram. The subject, Diagram Document, and its observers, Diagram Tree Menu and Diagram Window, are now synchronized. 
         [0089]    The physician, in this example, decides to document a stenosis in an artery. Referring now to  FIG. 26 , the physician clicks on the icon  2600  associated with a diffuse stenosis. The Diagram Window observer responses to the click and presents the physician with an enhanced cursor that looks like a diffuse stenosis  2601 . The physician has full control to move the enhanced cursor and can place it within any artery  2602 . The subject, Diagram Document, has not been notified of any changes and the observer, Diagram Window, is in control. 
         [0090]    Referring now to  FIG. 27 , the physician has determined that the location of the diffuse stenosis was in the mid-right coronary artery and moves the enhanced cursor to a location on the diagram and places the stenosis in this location  2700  by clicking on the mouse button. The Diagram Window observer responds to this action and notifies it subject, Diagram Document, of the change in state. Diagram Document may be uncoordinated with its observer&#39;s Diagram Tree Menu and Diagram Window and informs them that they need to get coordinated. Diagram Document calls its observers, Diagram Tree Menu and Diagram Window informing them that they need to get coordinated. After receiving this information from the subject the observers, Diagram Tree Menu and Diagram Window query the subject and retrieve the data that has changed. 
         [0091]    The data retrieved by the observers is processed by the ontology inference engine. The ontology inference engine maps the data elements between the menu data elements and diagram data elements. This mapping enables the synchronization between the two disparate representations of data. 
         [0092]    Referring now to  FIG. 28 , Diagram Tree Menu observer displays data that is the result of the diffuse stenosis being placed in a specific location, see  FIG. 27 . A selective Coronary Arteriography  2800  with a stenosis  2801  is displayed in the tree  2806 , with the location of Mid RCA  2802 , and stenosis type of Diffuse  2803 . The Diagram Window observer calls the subject, Diagram Document, and refreshes its data set and receives information from the subject that additional actions are required. The subject, Diagram Document, and the observers, Diagram Tree Menu and Diagram Window, are now synchronized. 
         [0093]    The Diagram Windows observer reacts to the additional actions given to it by the Diagram Document subject. Referring to  FIG. 28 , the additional actions present the physician with menu selections necessary to complete the findings for the stenosis  2805 . The physician needs to document the degree  2804  of the lumen  2805  for the stenosis  2801  and in this example; the physician selects 43 degrees  2807 . The Diagram Window observer responds to this action and notifies it subject, Diagram Document, of the change in state. Diagram Document may be uncoordinated with its observer&#39;s Diagram Tree Menu and Diagram Window and informs them that they need to get coordinated. Diagram Document calls its observers, Diagram Tree Menu and Diagram Window informing them that they need to get coordinated. After receiving this information from the subject the observers, Diagram Tree Menu and Diagram Window query the subject and retrieve the data that has changed. 
         [0094]    The data retrieved by the observers is processed by the ontology inference engine. The ontology inference engine maps the data elements between the menu data elements and diagram data elements. This mapping enables the synchronization between the two disparate representations of data. 
         [0095]    The Diagram Tree Menu observer displays data  2904  that is the result of the degree selection, see  FIG. 29 . The Diagram Window observer calls the subject Diagram Document, refreshes its data set, and receives information from the subject that additional actions are required. The diagram is updated accordingly by selections that affect the structure of the diagram. The subject, Diagram Document, and the observers, Diagram Tree Menu and Diagram Window, are now synchronized. 
         [0096]    The Diagram Windows observer reacts to the additional actions given to it by the Diagram Document subject. Referring to  FIG. 29 , the additional actions present the physician with menu selections necessary to complete the findings for the stenosis  2905 . The physician needs to document the description  2908  for the stenosis  2901  and in this example; the physician selects Eccentric  2907 . The Diagram Window observer responds to this action and notifies it subject, Diagram Document, of the change in state. Diagram Document may be uncoordinated with its observer&#39;s Diagram Tree Menu and Diagram Window and informs them that they need to get coordinated. Diagram Document calls its observers, Diagram Tree Menu and Diagram Window informing them that they need to get coordinated. After receiving this information from the subject the observers, Diagram Tree Menu and Diagram Window query the subject and retrieve the data that has changed. 
         [0097]    The data retrieved by the observers is processed by the ontology inference engine. The ontology inference engine maps the data elements between the menu data elements and diagram data elements. This mapping enables the synchronization between the two disparate representations of data. 
         [0098]    The Diagram Tree Menu observer displays data  3008  that is the result of the description selection, see  FIG. 30 . The diagram is updated accordingly by selections that affect the structure of the diagram. The Diagram Window observer calls the subject, Diagram Document, refreshes its data set, and receives information from the subject that additional actions are required. The subject, Diagram Document, and the observers, Diagram Tree Menu and Diagram Window, are now synchronized. 
         [0099]    The Diagram Windows observer reacts to the additional actions given to it by the Diagram Document subject. Referring to  FIG. 30 , the additional actions present the physician with menu selections necessary to complete the findings for the stenosis  3005 . The physician needs to document the Thrombus  3009  for the stenosis  3001  and in this example; the physician selects YES  3010 . The Diagram Window observer responds to this action and notifies it subject, Diagram Document, of the change in state. Diagram Document may be uncoordinated with its observer&#39;s, Diagram Tree Menu and Diagram Window, and informs them that they need to get coordinated. Diagram Document calls its observers, Diagram Tree Menu and Diagram Window informing them that they need to get coordinated. After receiving this information from the subject the observers, Diagram Tree Menu and Diagram Window query the subject and retrieve the data that has changed. 
         [0100]    The data retrieved by the observers is processed by the ontology inference engine. The ontology inference engine maps the data elements between the menu data elements and diagram data elements. This mapping enables the synchronization between the two disparate representations of data. 
         [0101]    The Diagram Tree Menu observer displays data  3109  that is the result of the Thrombus selection, see  FIG. 31 . The diagram is updated accordingly by selections that affect the structure of the diagram. The Diagram Window observer calls the subject, Diagram Document, refreshes its data set, and receives information from the subject that no additional actions are required. The subject, Diagram Document, and the observers, Diagram Tree Menu and Diagram Window, are now synchronized and the physician is presented with  FIG. 31 . In this example, the physician is satisfied with their documentation and hits the Save key  3111 . The subject, Diagram Document, writes all of its data to the database and program control is now returned to the Main Document subject and its observers Tree Menu and Edit Window. 
         [0102]    The system creates a subject called Main Document and two observers called Tree Menu and Edit Window. The system informs the subject of its observers and the subject is now in control of the application. Main Document calls its observers, Tree Menu and Edit Window informing them that they need to get coordinated. After receiving this information from the subject the observers, Tree Menu and Edit Window query the subject and retrieve the data that has changed. 
         [0103]    Referring now to  FIG. 32 , the observer Tree Menu displays the data  3200  which was retrieved from the Main Document subject. The observer, Edit Windows, displays the data  3201  which was retrieved from the Main Document subject. Main Document retrieved this data from the medical content database and the patient database. 
         [0104]    A system for the generating of naturally expressed medical procedure descriptions via a synchronized diagram and menu system has been described when documenting via the diagramming functionality. The procedure description documented in the diagram where propagated and synchronized with the menus. Now we need to describe the synchronized diagram and menu system when documenting via the menu functionality. 
         [0105]    Now referring to  FIG. 33 , the physician navigates to the findings tree node  3301  and is presented with the menu tree  3302  and in this example, the finding information  3304  documented during the diagram documentation described previously. In the next example, the physician will be documenting a stenosis found in a different artery via the menu tree. The physician selects the menu selection Stenosis  3303 . The observer, Tree Menu, observes the menu selection and informs the subject, Main Document, of the data change. Main Document may be uncoordinated with its observer&#39;s Tree Menu and Edit Window and informs them that they need to get coordinated. The observers react to this message and then query the subject, Main Document, for the change in data and the screen is refreshed with the data selected 
         [0106]    Referring to  FIG. 34 , the observer, Edit Window, displays the text string associated with a stenosis  3403  and the observer, Tree Menu, displays the menu selection  3400  underneath the findings node and receives notice from Diagram Document that additional actions are required. The subject, Main Document, and the observers, Tree Menu and Edit Window, are now synchronized. 
         [0107]    The observer, Tree Menu, executes the additional actions and the physician is next presented with a Locations menu  3402 . The same interactions described above between the subject, Main Document, and the observers, Tree Menu and Edit Window, occur each time a menu is presented and selected by the physician. The physician makes a menu selection and in this example, the physician has selected a location of Mid-LAD Artery  3401 . The observer, Tree Menu, observes the menu selection and informs the subject, Main Document, of the data change. Main Document may be uncoordinated with its observer&#39;s Tree Menu and Edit Window and informs them that they need to get coordinated. The observers react to this message and then query the subject, Main Document, for the change in data and the screen is refreshed with the data selected. 
         [0108]    Referring to  FIG. 35 , the observer, Edit Window, displays the text string associated with a location  3503  and the observer, Tree Menu, displays the menu selection  3500  underneath the findings node and receives notice from Main Document that additional actions are required. The subject, Main Document, and the observers, Tree Menu and Edit Window, are now synchronized. 
         [0109]    The observer, Tree Menu, executes the additional actions and the physician is next presented with a Degree menu  3502 . The same interactions described above between the subject, Main Document, and the observers, Tree Menu and Edit Window, occur each time a menu is presented and selected by the physician. The physician makes a menu selection and in this example, the physician has selected a degree of 44  3504 . The observer, Tree Menu, observes the menu selection and informs the subject, Main Document, of the data change. Main Document may be uncoordinated with its observer&#39;s Tree Menu and Edit Window and informs them that they need to get coordinated. The observers react to this message and then query the subject, Main Document, for the change in data and the screen is refreshed with the data selected. 
         [0110]    Referring to  FIG. 36 , the observer, Edit Window, displays the text string associated with a degree  3603  and the observer, Tree Menu, displays the menu selection  3600  underneath the findings node and receives notice from Main Document that additional actions are required. The subject, Main Document, and the observers, Tree Menu and Edit Window, are now synchronized. 
         [0111]    The observer, Tree Menu, executes the additional actions and the physician is next presented with a Stenosis Type menu  3602 . The same interactions described above between the subject, Main Document and the observers, Tree Menu and Edit Window, occur each time a menu is presented and selected by the physician. The physician makes a menu selection and in this example, the physician has selected a Stenosis Type of Discrete  3604 . The observer, Tree Menu, observes the menu selection and informs the subject, Main Document, of the data change. Main Document may be uncoordinated with its observer&#39;s Tree Menu and Edit Window and informs them that they need to get coordinated. The observers react to this message and then query the subject, Main Document, for the change in data and the screen is refreshed with the data selected. 
         [0112]    Referring to  FIG. 37 , the observer, Edit Window, displays the text string associated with a stenosis type  3703  and the observer, Tree Menu, displays the menu selection  3700  underneath the findings node and receives notice from Main Document that additional actions are required. The subject, Main Document, and the observers, Tree Menu and Edit Window, are now synchronized. 
         [0113]    The observer, Tree Menu, executes the additional actions and the physician is next presented with a Description menu  3702 . The same interactions described above between the subject, Main Document, and the observers, Tree Menu and Edit Window, occur each time a menu is presented and selected by the physician. The physician makes a menu selection and in this example, the physician has selected a Description of Eccentric  3704 . The observer, Tree Menu, observes the menu selection and informs the subject, Main Document, of the data change. Main Document may be uncoordinated with its observer&#39;s Tree Menu and Edit Window and informs them that they need to get coordinated. The observers react to this message and then query the subject, Main Document, for the change in data and the screen is refreshed with the data selected. 
         [0114]    Referring to  FIG. 38 , the observer, Edit Window, displays the text string associated with a description  3803  and the observer, Tree Menu, displays the menu selection  3800  underneath the findings node and receives notice from Main Document that additional actions are required. The subject, Main Document, and the observers, Tree Menu and Edit Window, are now synchronized. 
         [0115]    The observer, Tree Menu executes the additional actions and the physician is next presented with a Thrombus menu  3802 . The same interactions described above between the subject, Main Document, and the observers, Tree Menu and Edit Window, occur each time a menu is presented and selected by the physician. The physician makes a menu selection and in this example, the physician has selected a Thrombus of Yes  3804 . The observer, Tree Menu, observes the menu selection and informs the subject, Main Document, of the data change. Main Document may be uncoordinated with its observer&#39;s Tree Menu and Edit Window and informs them that they need to get coordinated. The observers react to this message and then query the subject, Main Document, for the change in data and the screen is refreshed with the data selected. 
         [0116]    Referring to  FIG. 39 , the observer, Edit Window, displays the text string associated with a thrombus  3902  and the observer, Tree Menu, displays the menu selection  3900  underneath the findings node and receives notice from Main Document that no additional actions are required. The subject, Main Document, and the observers, Tree Menu and Edit Window, are now synchronized. The information displayed in the menu tree  3901  is consistent with the text displayed in the text window  3902  for both of the stenosis documented by the physician. 
         [0117]    The physician&#39;s documenting of the findings via the menuing system has resulted in the creation of a synchronized diagram that has the stenosis correctly placed on the diagram given the information that was entered by the physician. 
         [0118]    Referring to  FIG. 40 , the physician navigates to the Diagram Documentation menu selection  4002  and clicks on the menu item. After the physician selects the menu selection, Diagram Documentation  4002 , the system stores the information stored in the Main Document subject and creates a new subject called Diagram Document and two observers called Diagram Tree Menu and Diagram Window. The system informs the subject, Diagram Document, of its observers and the subject is now in control of the application. Diagram Document calls its observers, Diagram Tree Menu and Diagram Window informing them that they need to get coordinated. After receiving this information from the subject the observers, Diagram Tree Menu and Diagram Window query the subject and retrieve the data that has changed. 
         [0119]    The data retrieved by the observers is processed by the ontology inference engine. The ontology inference engine maps the data elements between the menu data elements and diagram data elements. This mapping enables the synchronization between the two disparate representations of data. 
         [0120]    Referring now to  FIG. 41 , the observers, Diagram Tree Menu and Diagram Window, display the data which was retrieved from the Diagram Document subject. Diagram Document retrieved this data from the medical content database and the information associated with the selected patient. The data that was previously entered shows up in the inspection list  4100 , a diffuse stenosis found in the Mid RCA artery  4101 , and a discrete stenosis found in the Mid LAD artery  4102 . The subject, Diagram Document, and its observers, Diagram Tree Menu and Diagram Window, are now synchronized and the physician is able to document additional findings via the Diagram Document subject if needed. 
         [0121]    A system for the generating of naturally expressed medical procedure descriptions via a synchronized diagram and menu system has been described when documenting via the menu functionality. The procedure description documented in the menu where propagated and synchronized with the diagrams. 
         [0122]    The description of invention demonstrates synchronization between the Findings of a Cardiac Catheterization procedure and a diagram but the invention is not limited to a specific section of the medical procedure description. 
         [0123]    Referring to  FIG. 42 , the Echocardiography specialty has a need to document their medical procedure descriptions via a similar menu and diagram system. The invention has been implemented in the Echocardiography specialty with the same interaction model of the subject, Diagram Document  4200 , and observers, Diagram Tree Menu  4201  and Diagram Window  4202 . The invention is not limited to a specific medical specialty that completes medical procedure descriptions. 
         [0124]    Those skilled in the art will recognize that the embodiments disclosed herein are exemplary in nature and that various changes can be made without departing from the scope and the spirit of this invention. Such various changes would become clear to one of ordinary skill in the art after inspection of the specification and the drawings. In that regard, as many changes as are possible to the embodiments of this invention utilizing the teachings thereof, the descriptions above, and the accompanying drawings should be interpreted in the illustrative and not the limited sense. The invention therefore is not to be restricted except within the spirit and scope of any appended claims. 
         [0125]    The invention is by no means restricted to the embodiment shown. Many alternative versions are feasible in respect of the actual construction of the means used. The invention is not limited to procedure descriptions completed for procedures performed in Cardiology but in fact can be used to document procedures in any medical specialty. It should be noted that the invention is not restricted either to a special type of data, special configurations of data, programming languages, database systems, operating systems, or computing devices.