US20120290310A1 - Dynamic decision tree system for clinical information acquisition - Google Patents
Dynamic decision tree system for clinical information acquisition Download PDFInfo
- Publication number
- US20120290310A1 US20120290310A1 US13/106,766 US201113106766A US2012290310A1 US 20120290310 A1 US20120290310 A1 US 20120290310A1 US 201113106766 A US201113106766 A US 201113106766A US 2012290310 A1 US2012290310 A1 US 2012290310A1
- Authority
- US
- United States
- Prior art keywords
- data
- clinical
- query
- decision
- response
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
- G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
Definitions
- a medical diagnosis may involve a physician reviewing a patient's past medical records, interviewing the patient for information about their history and present condition, conducting a physical examination, performing and/or order laboratory tests, biopsies, and other data inquiries.
- a medical diagnosis may be guided by certain standard inquiry sequences which are used according to established standards of care, billing guidelines, and/or other bases. Although skilled medical judgment remains central to a diagnosis, external tools and guidelines may increase efficiency, compliance with standards, and verifiability. As the use of computer-based technologies becomes increasingly common in medical practice, the need for more dynamic, efficient, and non-intrusive solutions increases.
- EMR electronic medical record systems
- EMR systems emulate this process by providing “fields” for the required clinical elements (e.g. history of present complaint/illness, review of systems, past histories, examination findings and investigation results such as imaging, biopsy and histology findings) into which the dictated notes are transcribed.
- FIG. 1 a is illustrative of an example dynamic decision forest in which decision nodes are connected to form decision trees and at least some decision trees lack a pre-defined sequence prior independent of an information acquisition occurrence.
- FIGS. 1 b - 1 d are illustrative examples of use cases for a dynamic decision forest. Decision trees have been dynamically linked during an information acquisition to provide a dynamic decision pathway.
- FIG. 2 depicts one embodiment of a system capable of gathering clinical information using a dynamic decision forest and generating natural language descriptions of gathered clinical information.
- FIGS. 3 and 4 illustrate example user interfaces for receiving clinical information.
- the figures' arrows illustrate the effect of data entry on the presentation of future user interfaces.
- FIG. 5 illustrates an example user interface for receiving verification information concerning previously received clinical information.
- FIG. 6 illustrates an example user interface which provides natural language text describing stored clinical information.
- FIGS. 7 a - 7 e depict information acquisition steps which may be performed by a dynamic decision forest, including different paths which may be followed during various uses of that dynamic decision forest.
- a physician meets with a patient and uses a computer-based system involving a tablet computer in order to assist in gathering patient history information, determining the next courses of clinical action, making a diagnosis and writing a prescription.
- the clinical data acquisition system includes a dynamic decision forest which is used to provide efficient, adaptable guidance in the clinical steps performed.
- a dynamic decision forest may comprise a plurality of decision trees, at least some of which lack any predefined relationship. Despite this lack of predefined relationship amongst at least some trees, a dynamic decision forest may be capable of performing those decision trees in sequence based, for example, upon dynamically assessed data.
- the system may maintain patient data concerning the particular patient. The system may initially populate the patient data, for example based on previous records stored within or accessible to the system.
- the system may begin without any data specific to the patient, and may prompt the physician to obtain such data by taking a guided medical history from the patient.
- the system may provide user interface data to the physician user.
- the user interface data may relate to a user interface accessible on a device such as a touch-sensitive tablet computing device.
- the system provides user interface data relating to a simple interface in which the physician is presented with a query and a series of possible responses, for example a question to ask the patient and a small number of possible responses.
- the responses may be selectable by the physician through touching the tablet device, and the responses entered for past queries may affect the later queries which the system presents to the physician.
- the example system may store relationships between some queries, the system may also provide data corresponding to a data acquisition path in which a query is selected despite having no predefined relationship with the prior query.
- FIG. 1 a an illustration of a dynamic decision forest is presented.
- FIG. 1 b the forest of FIG. 1 a is shown in a use case in which clinical inquiries were performed in a data acquisition path.
- the system may have received responses resulting from user inputs and have determined subsequent responses based at least in part on those received responses, despite the system having no predefined relationship between two responses which occur in series.
- Data inquiries A 8 and C 1 in FIG. 1 b illustrate an example of such a “jump” between nodes without a predefined relationship.
- the system determines how to “jump” from one query to the other based on the data already acquired, and/or data which remains necessary or useful.
- the physician is presented with a series of interfaces which guide a highly informative data acquisition tailored to the particular patient's history and condition.
- the described embodiment's use of jump paths may also allow for a significant number of paths, may provide for a computationally efficient means of storing data used to guide data potential acquisitions, and may reduce the likelihood of system error resulting from improperly predefined query relationships.
- the physician benefits from the robust system intelligence behind a simplified user interface.
- the system may provide verification data which may enable a user to perform an iterative review of previous inquiries. Such iterative feedback may allow for efficient verification of decision data, which may in turn reduce the likelihood of subsequent queries improperly occurring as a result of an improper previous response.
- FIG. 1 a an illustration of a dynamic decision forest is presented. Queries are represented as nodes, with each node identified by a letter-number pair, such as A 1 , A 2 , A 3 , C 5 , D 7 , E 3 , etc. A beginning point 101 is illustrated where the system may start the data acquisition process.
- query nodes A 1 , A 2 , A 3 , A 4 , A 5 , A 6 , A 7 and A 8 are all interconnected in a tree-like fashion (the “A-tree”) nodes in one lettered tree (e.g., the A-tree and the corresponding B-tree, C-tree, D-tree and E-tree) lack a predefined connection with a node in any other tree (for example, the B-tree or C-tree).
- a predefined relationship between nodes is represented by a dotted line terminating in an arrow. Such a relationship represents that a decision path may proceed from one to a node to which it is connected.
- a decision path would begin at node A 1 , proceed to node A 2 , and then proceed to either node A 3 or node A 4 .
- Each node represents a query, such as a clinical query.
- a clinical query consists of at least a clinical inquiry and a plurality of response options.
- Some clinical queries may be designed to elicit a single response from a list of response options (for example, by presenting the response options as a radio-button interface where only one response may be selected at any time) while other queries may be designed to elicit one or more responses from a list of response options (for example, by presenting the response options as a check-box interface where multiple responses may be selected at any time).
- Other types of nodes, inquiries, and/or responses may additionally or alternatively be used.
- the system in order to complete a node and proceed to a next node, the system would transmit data concerning the current node's clinical inquiry and receive data representative of the user's selection of one or more response options.
- the user's response options may include text, audio, picture, video or other data.
- a picture response may be provided to document a patient's state at the time of the medical interview.
- node A 2 relates to an inquiry in which the patient is asked whether their symptoms are (1) better than the previous visit or (2) equal to or worse than the previous visit
- the system may proceed to node A 3 if it receives data indicating a response that the symptoms are better than the previous visit, and may proceed to node A 4 if it receives data indicating a response that the symptoms are equal to or worse than the previous visit.
- the system may proceed along a pathway if a numeric response to clinical inquiry is within a certain numeric range, and proceed along a different pathway otherwise.
- the system will occasionally proceed from one node to another node for which there is no predefined path relationship, as will be explained further.
- FIG. 1 a illustrates an embodiment in which certain nodes are classified as “jump source” nodes and “jump destination” nodes.
- nodes with a top semi-circle B 1 , B 2 , B 7 , C 1 , D 1 , D 4 and E 1
- nodes with a bottom semi-circle A 5 , A 7 , A 8 , B 9 , C 1 , C 4 , C 6 , D 4 , D 6 and D 7
- the system may perform a jump from any jump source node to any jump destination node.
- any node may function as either a jump source or jump destination node.
- certain nodes may function as both jump source nodes and jump destination nodes.
- node C 1 is both a jump source node and jump destination node.
- the E-tree lacks any jump source nodes, so according to the illustrative embodiment in FIG. 1 a , a decision path which leads to the E-tree would terminate in the E-tree as there could be no jump to another tree.
- node does not imply any specific data structure and does not in any other way limit the invention.
- a relational database may be used and nodes may correspond to entries in that database.
- a linked list of data structures may be used.
- an array of flag bits may be used and a node may be represented by a single element of the array.
- the term node serves to express a basic concept which may appear in a dynamic decision forest present in certain embodiments.
- FIG. 2 depicts one embodiment of a system capable of gathering clinical information using a dynamic decision forest and generating natural language descriptions of gathered clinical information.
- client devices 201 - 204 access a clinical data acquisition server 211 through a network 210 .
- client devices include a touch-sensitive tablet computing device 201 , a laptop 202 , a desktop computer 203 , or a smartphone 204 .
- Other client devices may also be used.
- a client module 212 may be provided for use on a mobile client.
- a client module 212 may comprise an application stored and executed locally on the mobile client.
- the mobile client accesses the clinical data acquisition server without needing to install any new software, for example by using a web-based interface.
- a client module 212 may comprise software such as a script-based programming language, provided by the clinical data acquisition server.
- the client module 212 may be a web browser accessing network-based menu pages in HTML, XHTML, and/or XML.
- a clinical data acquisition server 211 comprises a number of components. These include a web server 212 , a clinical interaction service 214 , a text generation service 215 , a decision node data store 221 , a patient data store 222 , a lexicographic data store 223 , and an interface template data store 224 .
- the web server 213 may provide data to mobile client devices 201 in response to network requests. For example, the web server may transmit data to a mobile client device using the Hypertext Transfer Protocol (HTTP). In other embodiments, a different type of server may be used—for example, one configured to respond using a protocol and/or port designed for the system.
- HTTP Hypertext Transfer Protocol
- the web server 213 receives interface template data 224 from a data store.
- That template data may include, for example, webpage templates such as HTML and/or CSS files which may be used in combination with specific menu data, so that the menu data can be transmitted to the user in a selected format. For example, font size, font color, text distribution within a page, and other visual elements may be affected by interface template data.
- the web server may 213 also interact with a clinical interaction service 214 .
- the clinical interaction service receives a user input event via the web server, processes the event in order to determine its relationship to the ongoing diagnosis, and then determines the next step in performing the diagnosis. For example, the clinical interaction service 214 may determine that, based upon already stored data, and the most recent user input, a jump should be performed to another node. Such a decision could result in the clinical interaction service transmitting data to the web server indicative of the node selected as a result of the jump process, as described above. At other times, the clinical interaction service 214 may determine that a non jump node selection should occur, or that a diagnosis has been reached and no further requests for user input should occur.
- the clinical interaction service 214 may be in communication with decision node data 221 which may be kept in a data store. It will be understood that any one or more of a variety of possible data stores may be used for all data stores illustrated in this embodiment, and for data stores used in other embodiments. Examples of data stores include a SQL database, relational databases, other types of databases, tables, and/or flat files. Also, while FIG. 2 illustrates multiple data elements 221 - 224 , in some embodiments these may be stored within a single data store, while in other embodiments one or more may be stored in separate data stores.
- the decision node data 221 may store data representative of a decision node forest, such as that shown in FIG. 1 .
- the clinical interaction service 214 may receive data from the decision node data 221 which the clinical interaction service 214 may then use in determining the next clinical interaction step, such as the next node for the path being followed in the present clinical examination.
- the clinical data acquisition server 211 may store patient data 222 .
- patient data 222 could include data acquired by interaction with other systems (for example, importing a medical history from another system), data stored from the user physician's previous interactions with the patient, and the already-completed steps of an ongoing medical diagnosis.
- the system may store response to queries, such as menu entries, as data within the patient data 222 .
- the clinical interaction service 214 may therefore transmit data to the patient data store 222 for storage, and may receive data from the patient data store 222 .
- the clinical interaction service may reference the decision node data 221 in order to determine what possible next steps are available, and then reference the patient data 222 in order to determine which next step is appropriate in for the particular case at issue.
- the clinical data acquisition server may also include a text generation service 215 .
- the text generation service 215 may provide descriptive text, such as in sentence or paragraph form, and may be adapted for a specific language such as English.
- the text generation service 215 may be capable of receiving patient data 222 and lexicographic data 223 in order to determine the lexicographic and grammatical structure of data which the service 215 may then output to a web server 213 to be transmitted to a user device 201 .
- Lexicographic data may indicate rule sets for a particular human language, including information about grammatical relationships between different word types. Such data may be stored in any of a variety of formats, and may be designed to facilitate translating patient data into human understandable text.
- FIG. 2 shows certain components of a decision forest system
- the entire system may be run locally on a single device.
- data stores are located on separate hardware than the services which interact with them.
- a system using a dynamic decision forest presents user input prompts, such as through an interactive menu system.
- the system may then receive a user response based on the user's selection of one or more menu items.
- the system may obtain user input through other interfaces or methods.
- Some such embodiments may include lexicographic logic functions whereby information presented to a user, prompts presented to a user, and/or information received in response to user input may be based in part on lexicographic rules.
- a system may include logic for parsing lexicographic items, identifying grammar, and/or classifying words.
- the system may behave based on lexicographic structure of the physician and/or patient's language, such as English.
- lexicographic structure of the physician and/or patient's language such as English.
- One of the interesting features of the English language is that the order in which descriptive words and phrases appear in a sentence is not necessarily the same as the order in which the physician might acquire those data items during a consultation.
- An embodiment of a dynamic decision tree system with menu interaction may therefore present menus in an order and context that a physician will be expecting even though this may not be most convenient for generating text.
- FIG. 3 an embodiment is shown in which the system provides a user with menu-driven prompts for input.
- menus are shown 301 - 304 .
- Each menu consists of a prompt 321 , 331 , 341 , 351 and menu response options.
- the menu prompt requests that the physician user identify the presenting symptoms of the patient 321 .
- the menu response options are categorized as either specific symptoms 321 or general symptoms 323 .
- the specific symptom options shown are “a lump in the breast,” “a lump in the axilla,” “changes to the skin,” “nipple alteration,” “altered sensation,” “changes in shape” and “altered consistency.”
- the general symptom options shown are “malaise,” “lethargy” and “weight loss.”
- this embodiment may present the physician user with the ability to select symptom options and/or other menu-based response options through a touch screen interface of a tablet computing device. In other embodiments, other computer systems are used. The system in the present embodiment determines which menu prompts to display to the user based upon the received input and/or other stored data.
- the system presents a second menu 302 titled “Breast lump duration” 331 , based on receiving user input in the first menu 301 which indicated the presence of a lump in the breast 324 .
- the arrow between the first and second menu 311 indicate this causal relationship. Relating this to FIG. 1 b and the system's behavior of traveling between nodes, the arrow 311 corresponds to a transition from one node to a second (e.g., transition 112 ), whether those node had a predefined relationship (e.g., transition 112 ), or the transition was a jump (e.g., jump 114 ).
- the second menu 302 includes a number of response options 332 , but allow for only a single response to be selected at any time.
- the selected response is “About four months” 333 .
- radio buttons 332 , 342 , 352 indicate when only one response may be selected for a given menu and checkboxes 324 - 327 indicate when multiple response options may be selected for a given menu. In other embodiments, other methods of indicating input options and/or recording input events may be used.
- FIG. 3 contains third 303 and fourth 304 menus, titled “axilla lump duration” 341 and “malaise duration” 351 , respectively.
- the system may present these menus based on the responses given in the example first menu 301 .
- the selection of “a lump in the axilla” 324 results in the system seeking additional data concerning the lump, shown by the transition arrow 312 .
- three items 324 , 326 have been selected in the first menu 301 which cause additional menu screens 302 - 304 .
- the subsequent menus are shown in the order that the triggering user inputs appear in the earlier menu 301 .
- the subsequent menus are shown in the order that the user input events occurred which selected those items in the first menu 301 .
- menu interfaces are provided 401 - 403 .
- three menus occur in sequence, as an input from the first menu 423 causes a transition 411 to the second menu 402 .
- an input 433 causes a transition to the third menu 412 .
- an input verification screen is presented 501 .
- the system may present a summary of information recently received and stored, thereby allowing a user to review for any mistakes.
- the user may be presented with the ability to edit the input 502 , or to verify that the input is accurate and continue 503 .
- verification occurs as an iterative process whereby at certain pre-designated points during a diagnosis process, the system seeks verification of all input received since the last verification if any. This may allow for verification at short intervals which may increase the likelihood that the user will remember their input and be able to recognize if an improper value has been entered.
- verification points are not pre-designated, but are dynamically determined at run time—for example, occurring after every 7 menu interfaces.
- the received input is described as a history of present complaint 601 , with a multi-sentence description 605 incorporating both received data and lexicographic rules for the English language.
- the interface shown in FIG. 6 further allows the user to enter free text 603 (described further below), to edit 602 menu inputs used in the text description, or to verify the note and continue 604 .
- the system has presented a user with seventeen (17) menus and received twenty-four (24) menu responses.
- the system then generates the following text based on the received input data.
- the example illustrates lexicographic capabilities which some embodiments of a dynamic decision tree system may include for generating text output.
- the system may then generate the following text based upon the above-described menu entries: “On examination a lump was found in the upper outer quadrant of the right breast that measured between 2.1-3.5 cm and on palpation this was hard and irregular but, not indurated or inflammatory. The lump itself was painless but the surrounding breast was tender. The mass was fully mobile within a medium-large, D cup breast with no spread to local structures. On ipsi-lateral axillary examination there was one lymph node that was fully mobile which measured about 1.5 cms in diameter. There were no nodes palpable in any of the other gland bearing areas and examination of the contra-lateral breast revealed no abnormalities.”
- the system's text generation may next generate text for the 2nd and 3rd sentences which, for convenience are reproduced here. “The lump itself was painless but the surrounding breast was tender. The mass was fully mobile within a medium-large, D cup breast with no spread to local structures.”
- the text-generating menus for this sentence correspond to the menu sequence (7) through (12) described above.
- cancerous lumps particularly in the relatively early stages, are almost always painless because they do not contain nerves. They only become painful with pressure and/or destruction of the nerves within the organ of origin.
- Embodiments of the system may include menu based sequences based on such subject-specific information.
- menu (3) should follow (1) because the PDUs in both of these menus pertain to characteristics of the lump. But, the physician may wish to compare and contrast any pain associated with the lump and the breast hence, menu (2) follows (1).
- the system in the present embodiment may then generate the 2nd sentence as: “The lump itself was” painless “but the surrounding breast was” tender.
- the system may also construct sentence 3 with the 3 key terms fully mobile, medium-large, D-cup and no with the responses from menus (3), (4) and (5), respectively. The first of these pertains to the lump, the second to the breast and the 3rd to local structures. Hence, the sentence can be constructed as: “The mass was” fully mobile “within a” medium-large, D cup “breast with” no “spread to local structures.”
- the mobility and size of the mass in relation to the size of the breast is important for determining what surgery, if any, can be carried out.
- the last two sentences contain seven key words from only five single choice menus which are shown above as menus (13) through (17).
- menus (13) through (17) On ipsi-lateral axillary examination there was one lymph node that was fully mobile which measured about 1.5 cms in diameter. There were no nodes palpable in any of the other gland bearing areas and examination of the contra-lateral breast revealed no abnormalities.
- the response from (12) was one lymph node and the header contains the key terms ipsilateral and axillary hence the beginning of sentence can be constructed with “On ipsilateral axillary examination” there was “one lymph node”.
- the responses from menus (13) and (14) were 1.5 cms and fully mobile respectively which is the order in which physicians historically gather those points of information. But, the order in which these data will often be dictated or written is the reverse. Hence, the remainder of the second sentence will be “that was” fully mobile “which measured about” 1.5 cms “in diameter.”
- the last sentence is generated from the responses no and normal from menus (16) and (17) respectively. The system then completes the paragraph as: “There were” no “nodes palpable in any of the other gland bearing areas and examination of the” contra-lateral “breast revealed” no abnormalities (the menu item normal is synonymous with no abnormalities)
- menus (1) through (17) includes specific sequences, menus, input options, and lexicographic rules it will be understood that many other sequences, menus, input options and lexicographic rules are within the scope of various embodiments of a dynamic decision forest.
- the embodiment contains a two page verification system which is engaged on completion of each data capture segment that enables the user to check the input for errors.
- the first of these pages has 4 buttons namely “all OK and continue”, “all OK and STOP”, “add free text” and “re-start this section.”
- the system may continue with transmitting new menu data, for example the system may store the generated text on disk then continues to the next section.
- the system may stop transmitting menu data, for example the system may stop after writing the currently considered text to disk.
- the system may present the user with the ability to enter in text, such as through a free-form text field.
- this may be characterized as a “Free Text input” or “FTI.”
- FTI Free Text input
- the system accepts FTI in 16 lines each of 80 Characters—corresponding to about half a page of type written text.
- other text restrictions or no text restrictions may be used. That text may be stored by the system and integrated into note text generated by the lexicographic service. Upon receipt of a “re-start this section” message, the system may re-transmit menu data for the most recent menu section.
- the system displays the user's contribution and requests confirmation with two buttons namely, all OK and re-enter free text input. If the 1st is pressed the program appends the user input text to the computer generated text and, again, stores this on disk before proceeding to the next section.
- free text that pertains to control characters that have special significance for the program's data management systems with browsers using HTML, XHTML and XML, which is effectively all of them. These characters are the ampersand (&), the hash character (#), the pipe character (
- the ampersand and the hash character are used in combination in the system as &#nnn (nnn is a 3 character numeral) to encode characters that do not appear on regular keyboards.
- these invisible characters are used as data separators and the &# combination should not be used in the free text input fields. This restriction should not constitute a problem and both of these characters should be able to be used separately but, just to be on the safe side try to avoid using the ampersand and use and instead.
- other text formatting is used which does not include such special character restrictions.
- text editing software such as Microsoft Word or Open Office Writer may be integrated with the system for text entry.
- Pressing the re-enter free text input at the 2nd verification wipes the free text input and enables you to re-enter corrected text.
- Pressing the re-start this section button at the first verification step re-sets the data stream to that recorded at the beginning of that particular section which enables a re-start of the whole section to be made.
- iterative feedback occurs in a dynamic, calculated manner.
- the theory of Miller's number states that most persons can keep between 5 and 9 objects in their working memory at any given time.
- the system requests verification after each sequence of approximately 7 menu screens.
- other iterative rates are used, or approximate rates are used.
- verification points may be pre-defined.
- other algorithms may be used to dynamically calculate verification points—for example by weighing a variety of factors such as number of entries per menu page, time elapsed, number of menus since previous verifications, and/or other factors.
- One embodiment of the system uses raw data collection that can be used in an audit trail or in data re-construction. These data are collected in a file separate from the various text data files and contains the page name, its sequence number and the numerical response from the text-generating menu pages. If the page is non-text-generating (i.e. NO menu), the item collected is ‘nul’ instead of a numerical value. Each record is separated by the ‘pipe’ (
- the ‘raw data’ file contains two key items.
- the first is a 256 bit ‘long-word’, called vBits, that employs single-bit logic to record which clinical items have been completed.
- the second is a listing of the clinical items in the system, clinList, and the order in which the physician wishes these to be printed out.
- the latter is used in the pathway logic to determine which items are located in which particular path in the system.
- the bits set from zero to unity in vBits have fixed locations for each clinical entity, the order of the clinical entities in clinList is variable and user-determined for each patient.
- jump paths may be triggered in certain situations, for example if the patient is to be scheduled for radical (curative) treatment.
- the fact that a jump will be taken within a dynamic decision forest can be determined a number of steps before the jump actually occurs. This may be referred to as “think ahead” functionality. For example, referring to FIG. 7 a , there is a total of 6 elements in paths A and B but only 4 in path C that need to be completed and these are represented by items a through f, 21 through 29 respectively (in reality there are over 100 such items).
- the last element, item g 29 is the end-point that represents the treatment prescription.
- the first item, a ( 20 , 21 & 22 ), represents the history of present illness/complaint and is common to all three paths but, the structure is different in each hence these are labeled 20 , 21 & 22 as only the ‘name’ is common.
- the sequence depicted in path C 17 is entered if the patient requires treatment for metastatic disease where b and c are not needed.
- FIG. 7 b represents the events that would be engaged by the system if the patient was scheduled for radical treatment after referral to an oncologist by a family practitioner, or a self-referring patient, where no definitive diagnostic procedures (e.g. diagnostic imaging or biopsy to establish the disease stage and diagnosis) had been carried out.
- definitive diagnostic procedures e.g. diagnostic imaging or biopsy to establish the disease stage and diagnosis
- nextLink the default, which is the current path, A 15 at 31 . It now enters the common sequence 23 where items b+c 23 are completed and then continues down path A 15 after execution of nextLink at 33 .
- FIG. 7 c The system enters the radical treatment path B 16 if the referring surgeon has already carried out both the items d and e, 24 & 25 (e.g. diagnostic scan and biopsy to establish the diagnosis and disease stage).
- the relevant clinical data are recorded from the referral letter after establishing and recording the history of present illness (item a 21 ) from the patient and the referral letter.
- Items b+c 23 are located in the common sequence 23 and the system also ‘knows’ not to enter path A 15 after completing the common sequence at 33 because items d and e ( 24 & 25 ) have already been recorded as this avoids duplication. Furthermore, it ‘knows’ that item f 28 is located in the tail-end of path C 17 hence, the think-ahead functionality 30 sets the variable nextLink to path C 17 before entering the common sequence 23 . When the latter has been completed the system executes nextLink at 33 to enter path C 17 .
- the system also enters the radical treatment path B 16 if the referring surgeon has carried out only one, but NOT both, of the items d and e, 24 & 25 (e.g. diagnostic scan and biopsy to establish the diagnosis and disease stage).
- the relevant clinical data are recorded from the referral letter after establishing and recording the history of present illness (item a 21 ) from the patient and the referral letter.
- FIG. 7 e depicts the referral of a patient with metastatic disease who requires palliative treatment. Only 4 items namely a, d, e and f, 22 , 26 , 27 and 28 respectively, need to be completed before treatment is prescribed at item g 29 .
- the system sets nextLink to the default, which is the current path, C 17 at 32 . Items d 26 and e 27 represent brief diagnostic imaging and biopsy reports and these could be by-passed if the patient is known to the physician who already has these data.
- nextLink at 33 the program re-enters path C 17 and thence to item f 28 .
- the described embodiment contains a text engine that converts a sequence of “clicked” menu items into fluent text and it has four main requirements.
- the output must convey meaning, (b) it must be factually accurate, (c) it must be unambiguous and (d) it should not look as if it has been written by a computer.
- the text-generating menus (the majority) contain descriptive key words or phrases that pertain to specific sections of the medical record capture process. Each menu is presented in a logical sequence and appropriate medical context with which the physician will be familiar. When a menu item (button) is selected (pressed, clicked) the program captures the associated numerical value and stores this (hence, the digital acquisition).
- Single choice menus are characterized by radio buttons (round) where only one selection can be made and the multiple choice menus are identified by check boxes (square) where any combination of items can be pressed.
- some sets of single choice menus have been placed in a composite menu. This necessarily requires using check-boxes (it is just the way the web works) so it could be possible to click more than one item from a single-choice menu within the composite.
- this eventuality is identified by the system in an ERROR TRAP that tells the user when the combination of buttons pressed is inappropriate and re-sets the menu automatically for data re-entry.
- the digital (numerical) data collected by the embodiment represent descriptive words or phrases and it is only possible to generate a fluent text output because of the order in which the content in the various menus is presented to the physician. This is the context within which the buttons are pressed and represents the grammar.
- the text generator is not contained within a single algorithm but, it is essentially a series of algorithms that construct the text sentence-by-sentence as each sequence of menu items is clicked.
- the program requests the consultant ID (a three letter string), the organ involved (e.g. breast, lung, prostate, colon etc.), the side for paired organs, the consultant's specialty (radOnc, medOnc, sgyOnc, CCC, comprehensive cancer centre etc.), the disease status (i.e.
- the system may use some of these data in selecting the appropriate pathway for ongoing data gathering.
- Menu 301 contains a list of the most likely presenting symptoms and let us suppose the first two items (primary data units, PDUs) are selected.
- Menu 302 is engaged next where a breast lump duration of ‘about four months’ is recorded.
- menu 1 c is engaged to record an axilla lump duration of ‘one month or less’.
- Menu 302 will be entered if (a) the patient has breast cancer and (b) the disease presentation switch ‘with symptoms’ was pressed which were both established previously. However, the system confirms that it is the correct path by checking against the header in menu 1 a which contains the character string presenting symptoms.
- the dynamic decision forest system may store audio data and related audio bookmarks.
- a mobile device used with the system may include the ability to record audio during a clinical decision process, such as a patient interview. The mobile device may also be used during the clinical decision process to navigate through decision steps, such as through a menu-driven embodiment described above.
- an audio bookmark feature may be used which stores data concerning the stage of audio recording which corresponds to certain decision path actions. For example, referring to FIG. 3 , such an embodiment may store information flagging or bookmarking the point during the audio recording when the data entry of “About four months” 333 occurred in the second menu 302 . In some embodiments, this bookmark may take the form of a timestamp associated with a data entry for the menu selection.
- pointers or other forms of storage may be used.
- the system may then enable a user to select an audio replay of the recorded audio corresponding to a desired portion of menu input. For example, the physician, when reviewing the note, could easily listen to the patient's reaction at around the time the menu input was entered for menu 302 .
- the system may be implemented as a computing system that is programmed or configured to perform the various functions described herein.
- the computing system may include multiple distinct computers or computing devices (e.g., physical servers, workstations, storage arrays, etc.) that communicate and interoperate over a network to perform the described functions.
- Each such computing device typically includes a processor (or multiple processors) that executes program instructions or modules stored in a memory or other non-transitory computer-readable storage medium.
- the various functions disclosed herein may be embodied in such program instructions, although some or all of the disclosed functions may alternatively be implemented in application-specific circuitry (e.g., ASICs or FPGAs) of the computer system.
- computing system includes multiple computing devices
- these devices may, but need not, be co-located.
- the results of the disclosed methods and tasks may be persistently stored by transforming physical storage devices, such as solid state memory chips and/or magnetic disks, into a different state.
- Each service described, such as those shown in FIG. 2 may be implemented by one or more computing devices, such as one or more physical servers programmed with associated server code.
Landscapes
- Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Business, Economics & Management (AREA)
- Medical Informatics (AREA)
- Public Health (AREA)
- Entrepreneurship & Innovation (AREA)
- Strategic Management (AREA)
- Human Resources & Organizations (AREA)
- Data Mining & Analysis (AREA)
- Biomedical Technology (AREA)
- Primary Health Care (AREA)
- General Health & Medical Sciences (AREA)
- Epidemiology (AREA)
- Economics (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- Pathology (AREA)
- Tourism & Hospitality (AREA)
- Quality & Reliability (AREA)
- Operations Research (AREA)
- Marketing (AREA)
- Medical Treatment And Welfare Office Work (AREA)
Abstract
A dynamic decision forest may be used to guide clinical or other decision queries such that multiple decision trees are followed in sequence and jumps occur between decision trees based on previously received query responses and the system's determination of what useful data has not been gathered. For example, rather than storing data concerning all possible paths between various decision trees, a system using the dynamic decision forest may determine at the time of use that a jump should occur from one decision tree to another decision tree despite the system not being pre-populated with data representative of a relationship between the source and destination of the jump. A clinical note may be created based on the path followed through the dynamic decision forest, and iterative verification may be used in order to improve the likelihood that the correct path is being followed.
Description
- Many tasks require complex information acquisitions which include a series of information queries. Often, the information results obtained in response to one or more queries will affect what information queries subsequently occur. For example, a medical diagnosis may involve a physician reviewing a patient's past medical records, interviewing the patient for information about their history and present condition, conducting a physical examination, performing and/or order laboratory tests, biopsies, and other data inquiries. A medical diagnosis may be guided by certain standard inquiry sequences which are used according to established standards of care, billing guidelines, and/or other bases. Although skilled medical judgment remains central to a diagnosis, external tools and guidelines may increase efficiency, compliance with standards, and verifiability. As the use of computer-based technologies becomes increasingly common in medical practice, the need for more dynamic, efficient, and non-intrusive solutions increases.
- Physicians increasingly are using electronic medical record systems (“EMR”). Notwithstanding this, the ability to capture quickly and easily a clinical note during a consultation remains a source of frustration as information overload, either consciously or subconsciously, may frequently be encountered. During a consultation the physician must socially engage with, and reassure, the patient whilst simultaneously making observations and/or requesting investigations relevant to the patient's condition. In an example of a cancer diagnosis, the physician may then consider the acquired data in order to arrive at a diagnosis. A treatment strategy may be created, involving surgery, chemotherapy and radiotherapy in any combination or permutation. In addition, each of these disciplines may require many factors to input into an effective decision making process.
- Traditionally, the physician will make written notes that act as an “aids-de-memoire”, before formalizing the annotations by dictating for a transcription secretary. Many EMR systems emulate this process by providing “fields” for the required clinical elements (e.g. history of present complaint/illness, review of systems, past histories, examination findings and investigation results such as imaging, biopsy and histology findings) into which the dictated notes are transcribed.
- The addition of modern computer systems into the medical field with attendant EMR systems often require the physician to acquire several new skills including typing, use of the mouse and navigation through an application. Through requiring less of the physician's attention being spent on it, a clinical information acquisition system allows the physician to dedicate more attention to the patient.
- The accompanying drawings, which are incorporated in, and form, a part of this specification, illustrate example embodiments of the inventive subject matter, and in no way limit the scope of protection. The accompanying drawings include examples of graphical user interfaces for use with the disclosed system and methods. Other embodiments are contemplated using alternate hardware and/or software platforms, and using significantly different interfaces. The accompanying drawings illustrate embodiments wherein:
-
FIG. 1 a is illustrative of an example dynamic decision forest in which decision nodes are connected to form decision trees and at least some decision trees lack a pre-defined sequence prior independent of an information acquisition occurrence. -
FIGS. 1 b-1 d are illustrative examples of use cases for a dynamic decision forest. Decision trees have been dynamically linked during an information acquisition to provide a dynamic decision pathway. -
FIG. 2 depicts one embodiment of a system capable of gathering clinical information using a dynamic decision forest and generating natural language descriptions of gathered clinical information. -
FIGS. 3 and 4 illustrate example user interfaces for receiving clinical information. The figures' arrows illustrate the effect of data entry on the presentation of future user interfaces. -
FIG. 5 illustrates an example user interface for receiving verification information concerning previously received clinical information. -
FIG. 6 illustrates an example user interface which provides natural language text describing stored clinical information. -
FIGS. 7 a-7 e depict information acquisition steps which may be performed by a dynamic decision forest, including different paths which may be followed during various uses of that dynamic decision forest. - Specific embodiments will now be described with reference to the drawings. These embodiments are intended to illustrate, and do not limit, the inventions set forth in the claims. Nothing in this detailed description is intended to imply that any particular feature, characteristic, or component of the disclosed systems, methods, and computer readable media is essential. Although the following description focuses on clinical applications, the disclosed decision forest system and methods can also be used for other (non-medical) applications involving decision trees. Examples of such other applications include business decision, risk assessment, and technical support problem resolution.
- In one embodiment, a physician meets with a patient and uses a computer-based system involving a tablet computer in order to assist in gathering patient history information, determining the next courses of clinical action, making a diagnosis and writing a prescription. The clinical data acquisition system includes a dynamic decision forest which is used to provide efficient, adaptable guidance in the clinical steps performed. A dynamic decision forest may comprise a plurality of decision trees, at least some of which lack any predefined relationship. Despite this lack of predefined relationship amongst at least some trees, a dynamic decision forest may be capable of performing those decision trees in sequence based, for example, upon dynamically assessed data. For example, the system may maintain patient data concerning the particular patient. The system may initially populate the patient data, for example based on previous records stored within or accessible to the system. Alternatively or additionally, the system may begin without any data specific to the patient, and may prompt the physician to obtain such data by taking a guided medical history from the patient. For example, the system may provide user interface data to the physician user. The user interface data may relate to a user interface accessible on a device such as a touch-sensitive tablet computing device. In this embodiment, the system provides user interface data relating to a simple interface in which the physician is presented with a query and a series of possible responses, for example a question to ask the patient and a small number of possible responses. The responses may be selectable by the physician through touching the tablet device, and the responses entered for past queries may affect the later queries which the system presents to the physician.
- Although the example system may store relationships between some queries, the system may also provide data corresponding to a data acquisition path in which a query is selected despite having no predefined relationship with the prior query. Referring to
FIG. 1 a, an illustration of a dynamic decision forest is presented. Referring toFIG. 1 b, the forest ofFIG. 1 a is shown in a use case in which clinical inquiries were performed in a data acquisition path. For example, the system may have received responses resulting from user inputs and have determined subsequent responses based at least in part on those received responses, despite the system having no predefined relationship between two responses which occur in series. Data inquiries A8 and C1 inFIG. 1 b illustrate an example of such a “jump” between nodes without a predefined relationship. In the present embodiment, the system determines how to “jump” from one query to the other based on the data already acquired, and/or data which remains necessary or useful. As a result, the physician is presented with a series of interfaces which guide a highly informative data acquisition tailored to the particular patient's history and condition. In addition to providing an improved experience by a physician user, the described embodiment's use of jump paths may also allow for a significant number of paths, may provide for a computationally efficient means of storing data used to guide data potential acquisitions, and may reduce the likelihood of system error resulting from improperly predefined query relationships. - Although some of these benefits may seem hidden from the physician user in some embodiments, the physician benefits from the robust system intelligence behind a simplified user interface. Furthermore, in certain embodiments the system may provide verification data which may enable a user to perform an iterative review of previous inquiries. Such iterative feedback may allow for efficient verification of decision data, which may in turn reduce the likelihood of subsequent queries improperly occurring as a result of an improper previous response.
- Referring to
FIG. 1 a, an illustration of a dynamic decision forest is presented. Queries are represented as nodes, with each node identified by a letter-number pair, such as A1, A2, A3, C5, D7, E3, etc. Abeginning point 101 is illustrated where the system may start the data acquisition process. Although query nodes A1, A2, A3, A4, A5, A6, A7 and A8 are all interconnected in a tree-like fashion (the “A-tree”) nodes in one lettered tree (e.g., the A-tree and the corresponding B-tree, C-tree, D-tree and E-tree) lack a predefined connection with a node in any other tree (for example, the B-tree or C-tree). In the present example, a predefined relationship between nodes is represented by a dotted line terminating in an arrow. Such a relationship represents that a decision path may proceed from one to a node to which it is connected. - For example, referring to
FIG. 1 a, a decision path would begin at node A1, proceed to node A2, and then proceed to either node A3 or node A4. Each node represents a query, such as a clinical query. In the present embodiment, a clinical query consists of at least a clinical inquiry and a plurality of response options. Some clinical queries may be designed to elicit a single response from a list of response options (for example, by presenting the response options as a radio-button interface where only one response may be selected at any time) while other queries may be designed to elicit one or more responses from a list of response options (for example, by presenting the response options as a check-box interface where multiple responses may be selected at any time). Other types of nodes, inquiries, and/or responses may additionally or alternatively be used. - In the present embodiment, in order to complete a node and proceed to a next node, the system would transmit data concerning the current node's clinical inquiry and receive data representative of the user's selection of one or more response options. In another embodiment, the user's response options may include text, audio, picture, video or other data. For example, a picture response may be provided to document a patient's state at the time of the medical interview. Once the data for the present node has been received, the clinical data acquisition may proceed to the next node. Often, a subsequent node will be selected based at least upon data received from previous inquiries, and pre-defined clinical paths. For example, if node A2 relates to an inquiry in which the patient is asked whether their symptoms are (1) better than the previous visit or (2) equal to or worse than the previous visit, then the system may proceed to node A3 if it receives data indicating a response that the symptoms are better than the previous visit, and may proceed to node A4 if it receives data indicating a response that the symptoms are equal to or worse than the previous visit. In other examples, the system may proceed along a pathway if a numeric response to clinical inquiry is within a certain numeric range, and proceed along a different pathway otherwise. In the embodiment shown in
FIG. 1 a, the system will occasionally proceed from one node to another node for which there is no predefined path relationship, as will be explained further. -
FIG. 1 a illustrates an embodiment in which certain nodes are classified as “jump source” nodes and “jump destination” nodes. For example, nodes with a top semi-circle (B1, B2, B7, C1, D1, D4 and E1) are jump-source nodes. For example, nodes with a bottom semi-circle (A5, A7, A8, B9, C1, C4, C6, D4, D6 and D7) are jump-destination nodes. In embodiments such as theFIG. 1 a illustration, the system may perform a jump from any jump source node to any jump destination node. In other embodiments, any node may function as either a jump source or jump destination node. In some embodiments, certain nodes may function as both jump source nodes and jump destination nodes. For example, node C1 is both a jump source node and jump destination node. The E-tree lacks any jump source nodes, so according to the illustrative embodiment inFIG. 1 a, a decision path which leads to the E-tree would terminate in the E-tree as there could be no jump to another tree. It will be understood that the use of the term “node” does not imply any specific data structure and does not in any other way limit the invention. For example, in some embodiments a relational database may be used and nodes may correspond to entries in that database. In another embodiment, a linked list of data structures may be used. In still another embodiment, an array of flag bits may be used and a node may be represented by a single element of the array. The term node serves to express a basic concept which may appear in a dynamic decision forest present in certain embodiments. - A dynamic decision forest may be implemented in a number of different embodiments, which could make use of different hardware (e.g., local servers, web servers, desktop computers, laptops, tablet devices, smart phones, etc.) and/or different software, such as different programming languages, interface styles and/or network protocols.
FIG. 2 depicts one embodiment of a system capable of gathering clinical information using a dynamic decision forest and generating natural language descriptions of gathered clinical information. In the illustrated embodiment, one or more client devices 201-204 access a clinicaldata acquisition server 211 through anetwork 210. Exemplary client devices include a touch-sensitivetablet computing device 201, alaptop 202, adesktop computer 203, or asmartphone 204. Other client devices may also be used. Aclient module 212 may be provided for use on a mobile client. In some embodiments, aclient module 212 may comprise an application stored and executed locally on the mobile client. In other embodiments, the mobile client accesses the clinical data acquisition server without needing to install any new software, for example by using a web-based interface. Alternatively or additionally, aclient module 212 may comprise software such as a script-based programming language, provided by the clinical data acquisition server. In another embodiment, theclient module 212 may be a web browser accessing network-based menu pages in HTML, XHTML, and/or XML. - In the embodiment of
FIG. 2 , a clinicaldata acquisition server 211 comprises a number of components. These include aweb server 212, aclinical interaction service 214, atext generation service 215, a decisionnode data store 221, apatient data store 222, alexicographic data store 223, and an interfacetemplate data store 224. Theweb server 213 may provide data tomobile client devices 201 in response to network requests. For example, the web server may transmit data to a mobile client device using the Hypertext Transfer Protocol (HTTP). In other embodiments, a different type of server may be used—for example, one configured to respond using a protocol and/or port designed for the system. - The
web server 213 receivesinterface template data 224 from a data store. That template data may include, for example, webpage templates such as HTML and/or CSS files which may be used in combination with specific menu data, so that the menu data can be transmitted to the user in a selected format. For example, font size, font color, text distribution within a page, and other visual elements may be affected by interface template data. - The web server may 213 also interact with a
clinical interaction service 214. In this embodiment, the clinical interaction service receives a user input event via the web server, processes the event in order to determine its relationship to the ongoing diagnosis, and then determines the next step in performing the diagnosis. For example, theclinical interaction service 214 may determine that, based upon already stored data, and the most recent user input, a jump should be performed to another node. Such a decision could result in the clinical interaction service transmitting data to the web server indicative of the node selected as a result of the jump process, as described above. At other times, theclinical interaction service 214 may determine that a non jump node selection should occur, or that a diagnosis has been reached and no further requests for user input should occur. - The
clinical interaction service 214 may be in communication withdecision node data 221 which may be kept in a data store. It will be understood that any one or more of a variety of possible data stores may be used for all data stores illustrated in this embodiment, and for data stores used in other embodiments. Examples of data stores include a SQL database, relational databases, other types of databases, tables, and/or flat files. Also, whileFIG. 2 illustrates multiple data elements 221-224, in some embodiments these may be stored within a single data store, while in other embodiments one or more may be stored in separate data stores. Thedecision node data 221 may store data representative of a decision node forest, such as that shown inFIG. 1 . Theclinical interaction service 214 may receive data from thedecision node data 221 which theclinical interaction service 214 may then use in determining the next clinical interaction step, such as the next node for the path being followed in the present clinical examination. - The clinical
data acquisition server 211 may storepatient data 222. Suchpatient data 222 could include data acquired by interaction with other systems (for example, importing a medical history from another system), data stored from the user physician's previous interactions with the patient, and the already-completed steps of an ongoing medical diagnosis. The system may store response to queries, such as menu entries, as data within thepatient data 222. Theclinical interaction service 214 may therefore transmit data to thepatient data store 222 for storage, and may receive data from thepatient data store 222. As the clinical interaction service receives a new user input, it may reference thedecision node data 221 in order to determine what possible next steps are available, and then reference thepatient data 222 in order to determine which next step is appropriate in for the particular case at issue. - The clinical data acquisition server may also include a
text generation service 215. Thetext generation service 215 may provide descriptive text, such as in sentence or paragraph form, and may be adapted for a specific language such as English. Thetext generation service 215 may be capable of receivingpatient data 222 andlexicographic data 223 in order to determine the lexicographic and grammatical structure of data which theservice 215 may then output to aweb server 213 to be transmitted to auser device 201. Lexicographic data may indicate rule sets for a particular human language, including information about grammatical relationships between different word types. Such data may be stored in any of a variety of formats, and may be designed to facilitate translating patient data into human understandable text. - Although
FIG. 2 shows certain components of a decision forest system, it will be understood that a number of other embodiments may also or alternatively be used. For example, the entire system may be run locally on a single device. In such an embodiment, there may be no need for a network and a division of client module from clinical data acquisition server. In another embodiment, data stores are located on separate hardware than the services which interact with them. - In some embodiments, a system using a dynamic decision forest presents user input prompts, such as through an interactive menu system. The system may then receive a user response based on the user's selection of one or more menu items. Alternatively or additionally, the system may obtain user input through other interfaces or methods. Some such embodiments may include lexicographic logic functions whereby information presented to a user, prompts presented to a user, and/or information received in response to user input may be based in part on lexicographic rules.
- For example, a system may include logic for parsing lexicographic items, identifying grammar, and/or classifying words. Considering the example of a physician user of a medical dynamic decision tree system, the system may behave based on lexicographic structure of the physician and/or patient's language, such as English. One of the interesting features of the English language is that the order in which descriptive words and phrases appear in a sentence is not necessarily the same as the order in which the physician might acquire those data items during a consultation. An embodiment of a dynamic decision tree system with menu interaction may therefore present menus in an order and context that a physician will be expecting even though this may not be most convenient for generating text.
- For example, referring to
FIG. 3 , an embodiment is shown in which the system provides a user with menu-driven prompts for input. Four menus are shown 301-304. Each menu consists of a prompt 321, 331, 341, 351 and menu response options. In thefirst menu 301 the menu prompt requests that the physician user identify the presenting symptoms of thepatient 321. The menu response options are categorized as eitherspecific symptoms 321 orgeneral symptoms 323. The specific symptom options shown are “a lump in the breast,” “a lump in the axilla,” “changes to the skin,” “nipple alteration,” “altered sensation,” “changes in shape” and “altered consistency.” The general symptom options shown are “malaise,” “lethargy” and “weight loss.” InFIG. 3 , for thefirst menu 301 within the sequence, twospecific symptom options 324 and onegeneral symptom option 326 have been selected. For example, this embodiment may present the physician user with the ability to select symptom options and/or other menu-based response options through a touch screen interface of a tablet computing device. In other embodiments, other computer systems are used. The system in the present embodiment determines which menu prompts to display to the user based upon the received input and/or other stored data. - For example, in
FIG. 3 , the system presents asecond menu 302 titled “Breast lump duration” 331, based on receiving user input in thefirst menu 301 which indicated the presence of a lump in thebreast 324. The arrow between the first andsecond menu 311 indicate this causal relationship. Relating this toFIG. 1 b and the system's behavior of traveling between nodes, thearrow 311 corresponds to a transition from one node to a second (e.g., transition 112), whether those node had a predefined relationship (e.g., transition 112), or the transition was a jump (e.g., jump 114). Thesecond menu 302 includes a number ofresponse options 332, but allow for only a single response to be selected at any time. InFIG. 3 , the selected response is “About four months” 333. In the illustrated example,radio buttons -
FIG. 3 contains third 303 and fourth 304 menus, titled “axilla lump duration” 341 and “malaise duration” 351, respectively. The system may present these menus based on the responses given in the examplefirst menu 301. For example, the selection of “a lump in the axilla” 324 results in the system seeking additional data concerning the lump, shown by thetransition arrow 312. In the present embodiment, threeitems first menu 301 which cause additional menu screens 302-304. In one embodiment, the subsequent menus are shown in the order that the triggering user inputs appear in theearlier menu 301. In another embodiment, the subsequent menus are shown in the order that the user input events occurred which selected those items in thefirst menu 301. - Referring to
FIG. 4 , additional examples of menu interfaces are provided 401-403. Here, three menus occur in sequence, as an input from thefirst menu 423 causes atransition 411 to thesecond menu 402. There, aninput 433 causes a transition to thethird menu 412. - Referring to
FIG. 5 , an input verification screen is presented 501. The system may present a summary of information recently received and stored, thereby allowing a user to review for any mistakes. The user may be presented with the ability to edit theinput 502, or to verify that the input is accurate and continue 503. In some embodiments, verification occurs as an iterative process whereby at certain pre-designated points during a diagnosis process, the system seeks verification of all input received since the last verification if any. This may allow for verification at short intervals which may increase the likelihood that the user will remember their input and be able to recognize if an improper value has been entered. In another embodiment, verification points are not pre-designated, but are dynamically determined at run time—for example, occurring after every 7 menu interfaces. - Referring to
FIG. 6 , an example of text generated by the system is presented. The received input is described as a history ofpresent complaint 601, with amulti-sentence description 605 incorporating both received data and lexicographic rules for the English language. The interface shown inFIG. 6 further allows the user to enter free text 603 (described further below), to edit 602 menu inputs used in the text description, or to verify the note and continue 604. - In a use case for another embodiment, the system has presented a user with seventeen (17) menus and received twenty-four (24) menu responses. The system then generates the following text based on the received input data. The example illustrates lexicographic capabilities which some embodiments of a dynamic decision tree system may include for generating text output. The input data indicated, in the order which their corresponding menus appeared:
- (1) PRESENTING SYMPTOMS: a lump in the breast, a lump in the axilla
- (2) BREAST LUMP DURATION: about four months
- (3) AXILLARY LUMP DURATION: one month or less
- (4) SITE IN BREAST: upper outer quadrant
- (5) SIZE OF PRIMARY: 2.1-3.5 cm
- (6) TUMOR CHARACTERISTICS: hard, irregular
- (7) LUMP CHARACTERISTICS: painless
- (8) SURROUNDING BREAST: tender
- (9) LUMP CHARACTERISTICS: fully mobile
- (10) BREAST CUP SIZE: medium-large-D cup
- (11) LOCAL SPREAD: none
- (12) IPSILATERAL AXILLARY NODE STATUS: one node
- (13) MARKER NODE SIZE ESTIMATE: 1.5 cms
- (14) NODE MOBILITY: fully mobile
- (15) ADDITIONAL NODES: none
- (16) CONTRALATERAL BREAST: normal
- (17) ANY CLINICAL SUSPICION FOR DISTANT METASES: no.
- The format of the above menu sequence is such that each line corresponds to a different menu input presented by the system, numbered in sequential order. The title of the menu is presented in capitalized letters, and the user-selected input is provided after the colon, with multiple-input selections separated by commas. This use scenario will be further described in order to provide an example of text generation from menu driven input.
- In the present example, the system may then generate the following text based upon the above-described menu entries: “On examination a lump was found in the upper outer quadrant of the right breast that measured between 2.1-3.5 cm and on palpation this was hard and irregular but, not indurated or inflammatory. The lump itself was painless but the surrounding breast was tender. The mass was fully mobile within a medium-large, D cup breast with no spread to local structures. On ipsi-lateral axillary examination there was one lymph node that was fully mobile which measured about 1.5 cms in diameter. There were no nodes palpable in any of the other gland bearing areas and examination of the contra-lateral breast revealed no abnormalities.”
- As the diagnosis, organ containing the lesion (lump) and the side have been established upstream this series of menus can only pertain to examination of the patient. Hence, the first sentence must start with “On examination . . . ”, “When the patient was examined . . . ” or some such similar sequence of words where, for convenience, the words other than the menu items are shown in between quotes (“ ”). The next component of the sentence must be what was found i.e. a lump (established earlier), followed by “was found”. The next sequence of primary data units (PDUs) the physician will wish to record will be (a) the site of the lesion in the breast, (b) its size and (c) what does it fell like. These PDUs, are then added to the sentence with addition of “in the” upper outer quadrant “of the right breast” (established upstream), “that measured between” 2.1-3.5 cms “and on palpation this was” hard and irregular. This last menu is multiple-choice and the items that were selected are appended to the sentence in a loading algorithm. An additional algorithm used here also appends the items that were not selected. Hence, the phrases “but, not” indurated or inflammatory are also appended.
- If the selection in menu (6) described above had been “hard, irregular and indurated” the output from the two loading algorithms appending to the sentence would have been “hard, irregular and indurated but not inflammatory”.
- Having completed the 1st sentence in this example scenario, the system's text generation may next generate text for the 2nd and 3rd sentences which, for convenience are reproduced here. “The lump itself was painless but the surrounding breast was tender. The mass was fully mobile within a medium-large, D cup breast with no spread to local structures.” The text-generating menus for this sentence correspond to the menu sequence (7) through (12) described above. As a manner of providing background to one use of the system, cancerous lumps, particularly in the relatively early stages, are almost always painless because they do not contain nerves. They only become painful with pressure and/or destruction of the nerves within the organ of origin. Embodiments of the system may include menu based sequences based on such subject-specific information. Logically, menu (3) should follow (1) because the PDUs in both of these menus pertain to characteristics of the lump. But, the physician may wish to compare and contrast any pain associated with the lump and the breast hence, menu (2) follows (1). The system in the present embodiment may then generate the 2nd sentence as: “The lump itself was” painless “but the surrounding breast was” tender. The system may also construct sentence 3 with the 3 key terms fully mobile, medium-large, D-cup and no with the responses from menus (3), (4) and (5), respectively. The first of these pertains to the lump, the second to the breast and the 3rd to local structures. Hence, the sentence can be constructed as: “The mass was” fully mobile “within a” medium-large, D cup “breast with” no “spread to local structures.”
- The mobility and size of the mass (synonymous in this context with lump, lesion and a number of other descriptive terms) in relation to the size of the breast is important for determining what surgery, if any, can be carried out.
- The last two sentences contain seven key words from only five single choice menus which are shown above as menus (13) through (17). On ipsi-lateral axillary examination there was one lymph node that was fully mobile which measured about 1.5 cms in diameter. There were no nodes palpable in any of the other gland bearing areas and examination of the contra-lateral breast revealed no abnormalities.
- The response from (12) was one lymph node and the header contains the key terms ipsilateral and axillary hence the beginning of sentence can be constructed with “On ipsilateral axillary examination” there was “one lymph node”. The responses from menus (13) and (14) were 1.5 cms and fully mobile respectively which is the order in which physicians historically gather those points of information. But, the order in which these data will often be dictated or written is the reverse. Hence, the remainder of the second sentence will be “that was” fully mobile “which measured about” 1.5 cms “in diameter.” The last sentence is generated from the responses no and normal from menus (16) and (17) respectively. The system then completes the paragraph as: “There were” no “nodes palpable in any of the other gland bearing areas and examination of the” contra-lateral “breast revealed” no abnormalities (the menu item normal is synonymous with no abnormalities)
- Although the above-described use scenario for menus (1) through (17) includes specific sequences, menus, input options, and lexicographic rules it will be understood that many other sequences, menus, input options and lexicographic rules are within the scope of various embodiments of a dynamic decision forest.
- The embodiment contains a two page verification system which is engaged on completion of each data capture segment that enables the user to check the input for errors. The first of these pages has 4 buttons namely “all OK and continue”, “all OK and STOP”, “add free text” and “re-start this section.” Upon receipt of an “all OK and continue” message, the system may continue with transmitting new menu data, for example the system may store the generated text on disk then continues to the next section. Upon receipt of an “all OK and STOP” message, the system may stop transmitting menu data, for example the system may stop after writing the currently considered text to disk. Upon receipt of an “add free text” message, the system may present the user with the ability to enter in text, such as through a free-form text field. In some embodiments, this may be characterized as a “Free Text input” or “FTI.” In one example, the system accepts FTI in 16 lines each of 80 Characters—corresponding to about half a page of type written text. In other embodiments, other text restrictions or no text restrictions may be used. That text may be stored by the system and integrated into note text generated by the lexicographic service. Upon receipt of a “re-start this section” message, the system may re-transmit menu data for the most recent menu section.
- In the present embodiment, on FTI completion the system displays the user's contribution and requests confirmation with two buttons namely, all OK and re-enter free text input. If the 1st is pressed the program appends the user input text to the computer generated text and, again, stores this on disk before proceeding to the next section. However, there is one caveat when entering free text that pertains to control characters that have special significance for the program's data management systems with browsers using HTML, XHTML and XML, which is effectively all of them. These characters are the ampersand (&), the hash character (#), the pipe character (|) and tilder (˜). The ampersand and the hash character are used in combination in the system as &#nnn (nnn is a 3 character numeral) to encode characters that do not appear on regular keyboards. In this embodiment, these invisible characters are used as data separators and the &# combination should not be used in the free text input fields. This restriction should not constitute a problem and both of these characters should be able to be used separately but, just to be on the safe side try to avoid using the ampersand and use and instead. In other embodiments, other text formatting is used which does not include such special character restrictions. In still other embodiments, text editing software such as Microsoft Word or Open Office Writer may be integrated with the system for text entry.
- Pressing the re-enter free text input at the 2nd verification wipes the free text input and enables you to re-enter corrected text. Pressing the re-start this section button at the first verification step re-sets the data stream to that recorded at the beginning of that particular section which enables a re-start of the whole section to be made.
- As mentioned above, in some embodiments, iterative feedback occurs in a dynamic, calculated manner. For example, the theory of Miller's number states that most persons can keep between 5 and 9 objects in their working memory at any given time. In one embodiment, the system requests verification after each sequence of approximately 7 menu screens. In other embodiments, other iterative rates are used, or approximate rates are used. In other embodiments, verification points may be pre-defined. In still other embodiments, other algorithms may be used to dynamically calculate verification points—for example by weighing a variety of factors such as number of entries per menu page, time elapsed, number of menus since previous verifications, and/or other factors.
- One embodiment of the system uses raw data collection that can be used in an audit trail or in data re-construction. These data are collected in a file separate from the various text data files and contains the page name, its sequence number and the numerical response from the text-generating menu pages. If the page is non-text-generating (i.e. NO menu), the item collected is ‘nul’ instead of a numerical value. Each record is separated by the ‘pipe’ (|) symbol. This file is stored on a server together with the text files and in duplicate in a separate domain as a system backup. The text files can be re-generated from this raw data file backup should a ‘disaster’ befall the servers. This is a very unlikely eventuality as the whole system is HIPPA compliant and the data are stored on two servers in separate locations.
- In addition, the ‘raw data’ file contains two key items. The first is a 256 bit ‘long-word’, called vBits, that employs single-bit logic to record which clinical items have been completed. The second is a listing of the clinical items in the system, clinList, and the order in which the physician wishes these to be printed out. The latter is used in the pathway logic to determine which items are located in which particular path in the system. Whereas, the bits set from zero to unity in vBits have fixed locations for each clinical entity, the order of the clinical entities in clinList is variable and user-determined for each patient.
- In some embodiments and use cases, jump paths may be triggered in certain situations, for example if the patient is to be scheduled for radical (curative) treatment. In some embodiments, the fact that a jump will be taken within a dynamic decision forest can be determined a number of steps before the jump actually occurs. This may be referred to as “think ahead” functionality. For example, referring to
FIG. 7 a, there is a total of 6 elements in paths A and B but only 4 in path C that need to be completed and these are represented by items a through f, 21 through 29 respectively (in reality there are over 100 such items). The last element,item g 29, is the end-point that represents the treatment prescription. The first item, a (20, 21 & 22), represents the history of present illness/complaint and is common to all three paths but, the structure is different in each hence these are labeled 20, 21 & 22 as only the ‘name’ is common. The sequence depicted inpath C 17 is entered if the patient requires treatment for metastatic disease where b and c are not needed. -
FIG. 7 b represents the events that would be engaged by the system if the patient was scheduled for radical treatment after referral to an oncologist by a family practitioner, or a self-referring patient, where no definitive diagnostic procedures (e.g. diagnostic imaging or biopsy to establish the disease stage and diagnosis) had been carried out. - Because
item d 24 anditem e 25 have not been carried out the system enterspath A 15. After recording item a 20 the system sets nextLink to the default, which is the current path, A 15 at 31. It now enters thecommon sequence 23 where items b+c 23 are completed and then continues down path A 15 after execution of nextLink at 33. -
FIG. 7 c The system enters the radical treatment path B16 if the referring surgeon has already carried out both the items d and e, 24 & 25 (e.g. diagnostic scan and biopsy to establish the diagnosis and disease stage). The relevant clinical data are recorded from the referral letter after establishing and recording the history of present illness (item a 21) from the patient and the referral letter. - The system now switches the appropriate bits in the ‘long-word’, vBits (see
page 26, ‘RAW DATA’ COLLECTION and AUDIT TRAIL), corresponding to items a, d and e (21, 24 and 25) from zero to unity which tells the system that these items have been completed. It now ‘knows’ that items b+c and f (23 and 28) need to be completed before treatment can be prescribed atitem g 29. - Items b+
c 23 are located in thecommon sequence 23 and the system also ‘knows’ not to enter path A 15 after completing the common sequence at 33 because items d and e (24 & 25) have already been recorded as this avoids duplication. Furthermore, it ‘knows’ thatitem f 28 is located in the tail-end ofpath C 17 hence, the think-ahead functionality 30 sets the variable nextLink topath C 17 before entering thecommon sequence 23. When the latter has been completed the system executes nextLink at 33 to enterpath C 17. - Referring to
FIG. 7 d, the system also enters the radicaltreatment path B 16 if the referring surgeon has carried out only one, but NOT both, of the items d and e, 24 & 25 (e.g. diagnostic scan and biopsy to establish the diagnosis and disease stage). Again, the relevant clinical data are recorded from the referral letter after establishing and recording the history of present illness (item a 21) from the patient and the referral letter. - The difference from
FIG. 7 c is that eitheritem d 24 oritem e 25 must be completed before reachingitem g 29. Again, the appropriate bits in vBits are switched from zero to unity (a+d or a+e) to record the completed items.Path A 15 contains bothitem d 24 anditem e 25 which must be avoided to stop duplication and,path C 17 contains neither hence, the system's think-ahead functionality sets nextLink to path B at 30. After thecommon sequence 23 is completed nextLink is executed at 33 and the system re-enterspath B 16 where eitheritem d 24 oritem e 25 needs to be completed. The system ‘knows’ which item, d or e (24 or 25), to complete by reference to the appropriate bit that has not yet been set to unity in the ‘long-word’, vBits. -
FIG. 7 e depicts the referral of a patient with metastatic disease who requires palliative treatment. Only 4 items namely a, d, e and f, 22, 26, 27 and 28 respectively, need to be completed before treatment is prescribed atitem g 29. After recording item a 22 the system sets nextLink to the default, which is the current path,C 17 at 32.Items d 26 ande 27 represent brief diagnostic imaging and biopsy reports and these could be by-passed if the patient is known to the physician who already has these data. After execution nextLink at 33 the program re-enterspath C 17 and thence toitem f 28. - The described embodiment contains a text engine that converts a sequence of “clicked” menu items into fluent text and it has four main requirements. (a) The output must convey meaning, (b) it must be factually accurate, (c) it must be unambiguous and (d) it should not look as if it has been written by a computer.
- 1) The Menus and Error Trapping
- The text-generating menus (the majority) contain descriptive key words or phrases that pertain to specific sections of the medical record capture process. Each menu is presented in a logical sequence and appropriate medical context with which the physician will be familiar. When a menu item (button) is selected (pressed, clicked) the program captures the associated numerical value and stores this (hence, the digital acquisition).
- Single choice menus are characterized by radio buttons (round) where only one selection can be made and the multiple choice menus are identified by check boxes (square) where any combination of items can be pressed. In order to reduce the number of mouse-clicks the user has to make, some sets of single choice menus have been placed in a composite menu. This necessarily requires using check-boxes (it is just the way the web works) so it could be possible to click more than one item from a single-choice menu within the composite. However, this eventuality is identified by the system in an ERROR TRAP that tells the user when the combination of buttons pressed is inappropriate and re-sets the menu automatically for data re-entry.
- 2) The Text Generator
- Language is complex and the meaning of the same word can depend heavily on the context in which it finds itself. As an example, consider the 4-digit word live in 4 different sentences.
- (a) Does he live in the city ?
- (b) Don't touch that wire it could be live.
- (c) I know my days are numbered but I really want to live a bit longer.
- (d) That girl is a really live wire.
- The difficulty here is that the 4-digit string ‘live’ has no meaning to the computer, it is just a string of characters that is represented by a numerical value in computer memory. Hence, the context within which a word or phrase finds itself is of crucial importance in creating meaning and avoiding ambiguity.
- The digital (numerical) data collected by the embodiment represent descriptive words or phrases and it is only possible to generate a fluent text output because of the order in which the content in the various menus is presented to the physician. This is the context within which the buttons are pressed and represents the grammar. The text generator is not contained within a single algorithm but, it is essentially a series of algorithms that construct the text sentence-by-sentence as each sequence of menu items is clicked. On starting the system the program requests the consultant ID (a three letter string), the organ involved (e.g. breast, lung, prostate, colon etc.), the side for paired organs, the consultant's specialty (radOnc, medOnc, sgyOnc, CCC, comprehensive cancer centre etc.), the disease status (i.e. with a primary, local recurrence or metastases) and clinical presentation (de novo with symptoms, post imaging, after chemotherapy, after surgery, for a 2nd opinion/treatment or co-incidental. The system may use some of these data in selecting the appropriate pathway for ongoing data gathering.
- Consider the set of menus depicted in
FIG. 3-4 that pertain to a breast cancer patient who is presenting with symptoms.Menu 301 contains a list of the most likely presenting symptoms and let us suppose the first two items (primary data units, PDUs) are selected.Menu 302 is engaged next where a breast lump duration of ‘about four months’ is recorded. Then, menu 1 c is engaged to record an axilla lump duration of ‘one month or less’. - The sentence can now be constructed from the following elements and although this is the simplest example of text generation by the system it illustrates a number of features.
- 1)
Menu 302 will be entered if (a) the patient has breast cancer and (b) the disease presentation switch ‘with symptoms’ was pressed which were both established previously. However, the system confirms that it is the correct path by checking against the header in menu 1 a which contains the character string presenting symptoms. - 2) The descriptive phrases chosen were a lump in the breast, a lump in the axilla, about four months and one month or less that, when taken out of context have no valid meaning as the interpretation could be ambiguous.
- 3) However, a lump in the breast is associated with
menu 302 and a lump in the axilla is associated withmenu 303. - 4) It is now possible to construct the text with words to the effect “This patient presented with a lump in the breast for about four months and a lump in the axilla that had been present for one month or less.”
- There are a number of different ways to phrase this sentence and because the lump in the axilla had been noticed for a shorter time than the breast lump it is possible to qualify and emphasize this with the terms “but” and “only” as follows: “This patient presented with a lump in the breast for about four months but the lump in the axilla that had been present for only one month or less.”
- In some embodiments, the dynamic decision forest system may store audio data and related audio bookmarks. For example, a mobile device used with the system may include the ability to record audio during a clinical decision process, such as a patient interview. The mobile device may also be used during the clinical decision process to navigate through decision steps, such as through a menu-driven embodiment described above. In such embodiments, an audio bookmark feature may be used which stores data concerning the stage of audio recording which corresponds to certain decision path actions. For example, referring to
FIG. 3 , such an embodiment may store information flagging or bookmarking the point during the audio recording when the data entry of “About four months” 333 occurred in thesecond menu 302. In some embodiments, this bookmark may take the form of a timestamp associated with a data entry for the menu selection. In other embodiments, pointers or other forms of storage may be used. The system may then enable a user to select an audio replay of the recorded audio corresponding to a desired portion of menu input. For example, the physician, when reviewing the note, could easily listen to the patient's reaction at around the time the menu input was entered formenu 302. - The system, such as the
FIG. 2 embodiment, may be implemented as a computing system that is programmed or configured to perform the various functions described herein. The computing system may include multiple distinct computers or computing devices (e.g., physical servers, workstations, storage arrays, etc.) that communicate and interoperate over a network to perform the described functions. Each such computing device typically includes a processor (or multiple processors) that executes program instructions or modules stored in a memory or other non-transitory computer-readable storage medium. The various functions disclosed herein may be embodied in such program instructions, although some or all of the disclosed functions may alternatively be implemented in application-specific circuitry (e.g., ASICs or FPGAs) of the computer system. Where the computing system includes multiple computing devices, these devices may, but need not, be co-located. The results of the disclosed methods and tasks may be persistently stored by transforming physical storage devices, such as solid state memory chips and/or magnetic disks, into a different state. Each service described, such as those shown inFIG. 2 , may be implemented by one or more computing devices, such as one or more physical servers programmed with associated server code. - Although the inventions have been described in terms of certain preferred embodiments, other embodiments will be apparent to those of ordinary skilled in the art, including embodiments that do not include all of the features and benefits set forth herein. Accordingly, the invention is defined only by the appended claims. Any manner of software designs, architectures or programming languages can be used in order to implement embodiments of the invention. Components of the invention may be implemented in distributed, cloud-based, and/or web-based manners.
- Conditional language used herein, such as, among others, “can,” “might,” “may,” “e.g.,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or states. Thus, such conditional language is not generally intended to imply that features, elements and/or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and/or states are included or are to be performed in any particular embodiment.
Claims (21)
1. A method for generating a natural language clinical note, the method comprising:
storing query data corresponding to a first plurality of clinical queries, each clinical query comprising a clinical inquiry and a plurality of associated response options;
providing, to a user, a first clinical query by transmitting data corresponding to both (1) said first clinical query's clinical inquiry and (2) at least some of said first clinical query's associated response options;
receiving first response data representative of said user's selection of one or more of said first clinical query's associated response options;
storing said first response data;
providing, to said user, a second clinical query by transmitting data corresponding to both (1) said second clinical query's clinical inquiry and (2) at least some of said second clinical query's associated response options, wherein said second clinical query is selected based at least in part on said first response data and said query data does not include any predefined relationship between said first clinical query and said second clinical query;
receiving second response data representative of said user's selection of one or more of said second clinical query's associated response options;
storing said second response data;
generating medical note data representative of said stored first response data and second response data, said medical note data in a natural language format; and
providing to said user said medical note data;
said method performed in its entirety by a computer system.
2. The method of claim 1 , further comprising:
providing, to said user, verification data representative of said first response data and said second response data; and
receiving, from said user, modification data indicative of said user's selection to change the selected one or more of said first clinical query's associated response options.
3. The method of claim 1 , further comprising:
providing said user with the ability to enter text corresponding to said medical note data; and
storing user text data representative of said text entered by said user.
4. The method of claim 1 , wherein said providing, to a user, a first clinical query comprises transmitting data corresponding to all of said first clinical query's associated response options.
5. The method of claim 1 , wherein said providing, to a user, a first clinical query comprises transmitting data corresponding to some, but not all, of said first clinical query's associated response options.
6. The method of claim 1 , wherein said data corresponding to both (1) said first clinical query's clinical inquiry and (2) at least some of said first clinical query's associated response options is formatted to be processed by a web browser.
7. The method of claim 1 , wherein said data corresponding to at least some of said first clinical query's associated response options is formatted for touch-based user interaction.
8. The method of claim 1 , wherein said query data indicates a second plurality of clinical queries including some but not all of said first plurality of clinical queries, and wherein said second clinical query was selected based at least in part on its presence in said second plurality of clinical queries.
9. The method of claim 1 , wherein said query data is stored on a server and said first response data is received by the server from a client device used by said user.
10. The method of claim 1 , further comprising generating diagnosis data characteristic of a clinical diagnosis, wherein said diagnosis data is based at least in part on said first response data and said second response data.
11. A system for generating a natural language clinical note, the system comprising:
a query data store configured to store query data corresponding to a first plurality of clinical queries, each clinical query comprising a clinical inquiry and a plurality of associated response options;
a query service configured to provide, to a user, a first clinical query by transmitting data corresponding to both (1) said first clinical query's clinical inquiry and (2) at least some of said first clinical query's associated response options, and a second clinical query by transmitting data corresponding to both (3) said second clinical query's clinical inquiry and (4) at least some of said second clinical query's associated response options;
a response service configured to receive first response data representative of said user's selection of one or more of said first clinical query's associated response options and second response data representative of said user's selection of one or more of said second clinical query's associated response options;
a response data store configured to store response data; and
a note service configured to generate medical note data representative of said stored first response data and second response data, said medical note data in a natural language format;
wherein said second clinical query was selected based at least in part on said first response data and said query data does not include any predefined relationship between said first clinical query and said second clinical query.
12. The system of claim 11 , further comprising:
providing, to said user, verification data representative of said first response data and said second response data; and
receiving, from said user, modification data indicative of said user's selection to change the selected one or more of said first clinical query's associated response options.
13. The system of claim 11 , further comprising:
providing said user with the ability to enter text corresponding to said medical note data; and
storing user text data representative of said text entered by said user.
14. The system of claim 11 , wherein said query service is configured to transmit data corresponding to all of said first clinical query's associated response options.
15. The system of claim 11 , wherein said query service is configured to transmit data corresponding to some, but not all, of said first clinical query's associated response options.
16. The system of claim 11 , wherein said data corresponding to both (1) said first clinical query's clinical inquiry and (2) at least some of said first clinical query's associated response options is formatted to be processed by a web browser.
17. The system of claim 11 , wherein said data corresponding to at least some of said first clinical query's associated response options is formatted for touch-based user interaction.
18. The system of claim 11 , wherein said query data indicates a second plurality of clinical queries including some but not all of said first plurality of clinical queries, and wherein said second clinical query was selected based at least in part on its presence in said second plurality of clinical queries.
19. The system of claim 11 , wherein said query data store is within a server and said response service is configured to receive response data at the server, from a client device used by said user.
20. The system of claim 11 , further comprising a diagnosis service configured to generate data characteristic of a clinical diagnosis, wherein said diagnosis data is based at least in part on said first response data and said second response data.
21. A method for using a dynamic decision forest to guide a dynamic decision process and gather associated decision data, the method comprising:
storing decision forest data representative of a plurality of decision trees wherein each decision tree comprises a plurality of decision nodes and each decision node comprises a query and a plurality of possible responses;
storing possible decision path data for a plurality of decision nodes, wherein said possible decision path data comprises a plurality of decision steps, each decision step associated with a source decision node and one or more destination decision nodes, and wherein no decision step is associated with a source decision node in a first decision tree and a destination decision node in a second decision tree;
transmitting first decision data representative of a first decision node, said first decision data comprising data representative of a first query associated with said first decision node and a first plurality of possible responses associated with said first decision node;
receiving first response data representative of a first selected plurality of responses, wherein each of said first selected plurality of responses was within the first plurality of possible responses associated with said first decision node;
transmitting second decision data representative of a second decision node, said second decision data comprising data representative of a second query associated with said second decision node and a second plurality of possible responses associated with said second decision node, wherein said possible decision path data comprises a decision step associated with said first query as a source decision node and said second query as a destination decision node;
receiving second response data representative of a second selected plurality of responses, wherein each of said second selected plurality of responses was within the second plurality of possible responses associated with said second decision node;
transmitting third decision data representative of a third decision node, said third decision data comprising data representative of a third query associated with said third decision node and a third plurality of possible responses associated with said third decision node, wherein said possible decision path data does not comprise a decision step associated with said second query as a source decision node and said third query as a destination decision node; and
receiving third response data representative of a third selected plurality of responses, wherein each of said third selected plurality of responses was within the third plurality of possible responses associated with said third decision node.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/106,766 US20120290310A1 (en) | 2011-05-12 | 2011-05-12 | Dynamic decision tree system for clinical information acquisition |
US16/201,929 US10529452B2 (en) | 2011-05-12 | 2018-11-27 | Computer memory with improved performance through single-bit logic |
US16/730,860 US11264136B2 (en) | 2011-05-12 | 2019-12-30 | Computer memory with improved performance through single-bit logic |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/106,766 US20120290310A1 (en) | 2011-05-12 | 2011-05-12 | Dynamic decision tree system for clinical information acquisition |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/201,929 Continuation US10529452B2 (en) | 2011-05-12 | 2018-11-27 | Computer memory with improved performance through single-bit logic |
Publications (1)
Publication Number | Publication Date |
---|---|
US20120290310A1 true US20120290310A1 (en) | 2012-11-15 |
Family
ID=47142474
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/106,766 Abandoned US20120290310A1 (en) | 2011-05-12 | 2011-05-12 | Dynamic decision tree system for clinical information acquisition |
US16/201,929 Active US10529452B2 (en) | 2011-05-12 | 2018-11-27 | Computer memory with improved performance through single-bit logic |
US16/730,860 Active 2031-09-03 US11264136B2 (en) | 2011-05-12 | 2019-12-30 | Computer memory with improved performance through single-bit logic |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/201,929 Active US10529452B2 (en) | 2011-05-12 | 2018-11-27 | Computer memory with improved performance through single-bit logic |
US16/730,860 Active 2031-09-03 US11264136B2 (en) | 2011-05-12 | 2019-12-30 | Computer memory with improved performance through single-bit logic |
Country Status (1)
Country | Link |
---|---|
US (3) | US20120290310A1 (en) |
Cited By (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130131462A1 (en) * | 2010-05-31 | 2013-05-23 | Seca Ag | Device for modular analysis |
US20130204834A1 (en) * | 2012-02-08 | 2013-08-08 | Bank Of America Corporation | Decision Tree Creation and Execution in an Interactive Voice Response System |
US20140136451A1 (en) * | 2012-11-09 | 2014-05-15 | Apple Inc. | Determining Preferential Device Behavior |
US20160132489A1 (en) * | 2012-08-30 | 2016-05-12 | Arria Data2Text Limited | Method and apparatus for configurable microplanning |
US20160292368A1 (en) * | 2015-03-30 | 2016-10-06 | International Business Machines Corporation | Mandating tasks at run-time for case management |
CN107045586A (en) * | 2015-12-02 | 2017-08-15 | 松下知识产权经营株式会社 | Control method and control device |
US20190065688A1 (en) * | 2017-08-31 | 2019-02-28 | Google Llc | Diagnostic Effectiveness Tool |
US10255252B2 (en) | 2013-09-16 | 2019-04-09 | Arria Data2Text Limited | Method and apparatus for interactive reports |
US10282422B2 (en) | 2013-09-16 | 2019-05-07 | Arria Data2Text Limited | Method, apparatus, and computer program product for user-directed reporting |
US10331304B2 (en) | 2015-05-06 | 2019-06-25 | Microsoft Technology Licensing, Llc | Techniques to automatically generate bookmarks for media files |
US10452995B2 (en) | 2015-06-29 | 2019-10-22 | Microsoft Technology Licensing, Llc | Machine learning classification on hardware accelerators with stacked memory |
US10467347B1 (en) | 2016-10-31 | 2019-11-05 | Arria Data2Text Limited | Method and apparatus for natural language document orchestrator |
US10540588B2 (en) | 2015-06-29 | 2020-01-21 | Microsoft Technology Licensing, Llc | Deep neural network processing on hardware accelerators with stacked memory |
US10606651B2 (en) | 2015-04-17 | 2020-03-31 | Microsoft Technology Licensing, Llc | Free form expression accelerator with thread length-based thread assignment to clustered soft processor cores that share a functional circuit |
US10664558B2 (en) | 2014-04-18 | 2020-05-26 | Arria Data2Text Limited | Method and apparatus for document planning |
US10671815B2 (en) | 2013-08-29 | 2020-06-02 | Arria Data2Text Limited | Text generation from correlated alerts |
US10776561B2 (en) | 2013-01-15 | 2020-09-15 | Arria Data2Text Limited | Method and apparatus for generating a linguistic representation of raw input data |
US20210390249A1 (en) * | 2020-06-12 | 2021-12-16 | Augmedix Operating Corporation | Natural-language medicial record generation platform |
US11361568B2 (en) * | 2018-12-05 | 2022-06-14 | Clover Health | Generating document content by data analysis |
US11531935B2 (en) * | 2011-05-05 | 2022-12-20 | Roger Alan Mason | System and method for implementing a diagnostic software tool |
Citations (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5572421A (en) * | 1987-12-09 | 1996-11-05 | Altman; Louis | Portable medical questionnaire presentation device |
US5935060A (en) * | 1996-07-12 | 1999-08-10 | First Opinion Corporation | Computerized medical diagnostic and treatment advice system including list based processing |
US6022315A (en) * | 1993-12-29 | 2000-02-08 | First Opinion Corporation | Computerized medical diagnostic and treatment advice system including network access |
US6047259A (en) * | 1997-12-30 | 2000-04-04 | Medical Management International, Inc. | Interactive method and system for managing physical exams, diagnosis and treatment protocols in a health care practice |
US6108665A (en) * | 1997-07-03 | 2000-08-22 | The Psychological Corporation | System and method for optimizing behaviorial health care collection |
US6196970B1 (en) * | 1999-03-22 | 2001-03-06 | Stephen J. Brown | Research data collection and analysis |
US20010012913A1 (en) * | 1997-03-13 | 2001-08-09 | Iliff Edwin C. | Disease management system and method including correlation assessment |
US20020035486A1 (en) * | 2000-07-21 | 2002-03-21 | Huyn Nam Q. | Computerized clinical questionnaire with dynamically presented questions |
US20020068857A1 (en) * | 2000-02-14 | 2002-06-06 | Iliff Edwin C. | Automated diagnostic system and method including reuse of diagnostic objects |
US20040172294A1 (en) * | 2000-11-22 | 2004-09-02 | Recare, Inc. | Integrated virtual consultant |
US6915254B1 (en) * | 1998-07-30 | 2005-07-05 | A-Life Medical, Inc. | Automatically assigning medical codes using natural language processing |
US20090089100A1 (en) * | 2007-10-01 | 2009-04-02 | Valeriy Nenov | Clinical information system |
US20100250271A1 (en) * | 2009-03-30 | 2010-09-30 | Zipnosis, Inc. | Method and system for digital healthcare platform |
US20120102405A1 (en) * | 2010-10-25 | 2012-04-26 | Evidence-Based Solutions, Inc. | System and method for matching person-specific data with evidence resulting in recommended actions |
US8302003B2 (en) * | 2003-09-03 | 2012-10-30 | Business Integrity Limited | Dynamic questionnaire generation |
-
2011
- 2011-05-12 US US13/106,766 patent/US20120290310A1/en not_active Abandoned
-
2018
- 2018-11-27 US US16/201,929 patent/US10529452B2/en active Active
-
2019
- 2019-12-30 US US16/730,860 patent/US11264136B2/en active Active
Patent Citations (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5572421A (en) * | 1987-12-09 | 1996-11-05 | Altman; Louis | Portable medical questionnaire presentation device |
US6022315A (en) * | 1993-12-29 | 2000-02-08 | First Opinion Corporation | Computerized medical diagnostic and treatment advice system including network access |
US5935060A (en) * | 1996-07-12 | 1999-08-10 | First Opinion Corporation | Computerized medical diagnostic and treatment advice system including list based processing |
US20010012913A1 (en) * | 1997-03-13 | 2001-08-09 | Iliff Edwin C. | Disease management system and method including correlation assessment |
US6108665A (en) * | 1997-07-03 | 2000-08-22 | The Psychological Corporation | System and method for optimizing behaviorial health care collection |
US6047259A (en) * | 1997-12-30 | 2000-04-04 | Medical Management International, Inc. | Interactive method and system for managing physical exams, diagnosis and treatment protocols in a health care practice |
US6915254B1 (en) * | 1998-07-30 | 2005-07-05 | A-Life Medical, Inc. | Automatically assigning medical codes using natural language processing |
US6196970B1 (en) * | 1999-03-22 | 2001-03-06 | Stephen J. Brown | Research data collection and analysis |
US20020068857A1 (en) * | 2000-02-14 | 2002-06-06 | Iliff Edwin C. | Automated diagnostic system and method including reuse of diagnostic objects |
US20020035486A1 (en) * | 2000-07-21 | 2002-03-21 | Huyn Nam Q. | Computerized clinical questionnaire with dynamically presented questions |
US20040172294A1 (en) * | 2000-11-22 | 2004-09-02 | Recare, Inc. | Integrated virtual consultant |
US8302003B2 (en) * | 2003-09-03 | 2012-10-30 | Business Integrity Limited | Dynamic questionnaire generation |
US20090089100A1 (en) * | 2007-10-01 | 2009-04-02 | Valeriy Nenov | Clinical information system |
US20100250271A1 (en) * | 2009-03-30 | 2010-09-30 | Zipnosis, Inc. | Method and system for digital healthcare platform |
US20100287001A1 (en) * | 2009-03-30 | 2010-11-11 | Zipnosis, Inc. | Method and system for digital healthcare platform |
US20120102405A1 (en) * | 2010-10-25 | 2012-04-26 | Evidence-Based Solutions, Inc. | System and method for matching person-specific data with evidence resulting in recommended actions |
Cited By (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130131462A1 (en) * | 2010-05-31 | 2013-05-23 | Seca Ag | Device for modular analysis |
US11531935B2 (en) * | 2011-05-05 | 2022-12-20 | Roger Alan Mason | System and method for implementing a diagnostic software tool |
US20130204834A1 (en) * | 2012-02-08 | 2013-08-08 | Bank Of America Corporation | Decision Tree Creation and Execution in an Interactive Voice Response System |
US8812429B2 (en) * | 2012-02-08 | 2014-08-19 | Bank Of America Corporation | Decision tree creation and execution in an interactive voice response system |
US20160132489A1 (en) * | 2012-08-30 | 2016-05-12 | Arria Data2Text Limited | Method and apparatus for configurable microplanning |
US10565308B2 (en) * | 2012-08-30 | 2020-02-18 | Arria Data2Text Limited | Method and apparatus for configurable microplanning |
US20190102705A1 (en) * | 2012-11-09 | 2019-04-04 | Apple Inc. | Determining Preferential Device Behavior |
US20140136451A1 (en) * | 2012-11-09 | 2014-05-15 | Apple Inc. | Determining Preferential Device Behavior |
US10776561B2 (en) | 2013-01-15 | 2020-09-15 | Arria Data2Text Limited | Method and apparatus for generating a linguistic representation of raw input data |
US10671815B2 (en) | 2013-08-29 | 2020-06-02 | Arria Data2Text Limited | Text generation from correlated alerts |
US11144709B2 (en) * | 2013-09-16 | 2021-10-12 | Arria Data2Text Limited | Method and apparatus for interactive reports |
US10255252B2 (en) | 2013-09-16 | 2019-04-09 | Arria Data2Text Limited | Method and apparatus for interactive reports |
US10282422B2 (en) | 2013-09-16 | 2019-05-07 | Arria Data2Text Limited | Method, apparatus, and computer program product for user-directed reporting |
US10860812B2 (en) | 2013-09-16 | 2020-12-08 | Arria Data2Text Limited | Method, apparatus, and computer program product for user-directed reporting |
US10664558B2 (en) | 2014-04-18 | 2020-05-26 | Arria Data2Text Limited | Method and apparatus for document planning |
CN106021844A (en) * | 2015-03-30 | 2016-10-12 | 国际商业机器公司 | Method and system for mandating tasks during operation of case management |
US20160292618A1 (en) * | 2015-03-30 | 2016-10-06 | International Business Machines Corporation | Mandating tasks at run-time for case management |
US20160292368A1 (en) * | 2015-03-30 | 2016-10-06 | International Business Machines Corporation | Mandating tasks at run-time for case management |
US10606651B2 (en) | 2015-04-17 | 2020-03-31 | Microsoft Technology Licensing, Llc | Free form expression accelerator with thread length-based thread assignment to clustered soft processor cores that share a functional circuit |
US10331304B2 (en) | 2015-05-06 | 2019-06-25 | Microsoft Technology Licensing, Llc | Techniques to automatically generate bookmarks for media files |
US10452995B2 (en) | 2015-06-29 | 2019-10-22 | Microsoft Technology Licensing, Llc | Machine learning classification on hardware accelerators with stacked memory |
US10540588B2 (en) | 2015-06-29 | 2020-01-21 | Microsoft Technology Licensing, Llc | Deep neural network processing on hardware accelerators with stacked memory |
CN107045586A (en) * | 2015-12-02 | 2017-08-15 | 松下知识产权经营株式会社 | Control method and control device |
US10747798B2 (en) * | 2015-12-02 | 2020-08-18 | Panasonic Intellectual Property Management Co., Ltd. | Control method, processing apparatus, and recording medium |
US10963650B2 (en) | 2016-10-31 | 2021-03-30 | Arria Data2Text Limited | Method and apparatus for natural language document orchestrator |
US10467347B1 (en) | 2016-10-31 | 2019-11-05 | Arria Data2Text Limited | Method and apparatus for natural language document orchestrator |
US11727222B2 (en) | 2016-10-31 | 2023-08-15 | Arria Data2Text Limited | Method and apparatus for natural language document orchestrator |
US11488712B2 (en) * | 2017-08-31 | 2022-11-01 | Google Llc | Diagnostic effectiveness tool |
US20190065688A1 (en) * | 2017-08-31 | 2019-02-28 | Google Llc | Diagnostic Effectiveness Tool |
US11361568B2 (en) * | 2018-12-05 | 2022-06-14 | Clover Health | Generating document content by data analysis |
US20220309817A1 (en) * | 2018-12-05 | 2022-09-29 | Clover Health | Generating document content by data analysis |
US20210390249A1 (en) * | 2020-06-12 | 2021-12-16 | Augmedix Operating Corporation | Natural-language medicial record generation platform |
US11893339B2 (en) | 2020-06-12 | 2024-02-06 | Augmedix Operating Corporation | Natural-language medical record generation platform |
Also Published As
Publication number | Publication date |
---|---|
US20200381113A1 (en) | 2020-12-03 |
US11264136B2 (en) | 2022-03-01 |
US20190333637A1 (en) | 2019-10-31 |
US10529452B2 (en) | 2020-01-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11264136B2 (en) | Computer memory with improved performance through single-bit logic | |
US11894140B2 (en) | Interface for patient-provider conversation and auto-generation of note or summary | |
CN109697283B (en) | Method and system for generating a literal record of a patient-health care provider session | |
US20180301222A1 (en) | Method and platform/system for creating a web-based form that incorporates an embedded knowledge base, wherein the form provides automatic feedback to a user during and following completion of the form | |
US8103525B2 (en) | Utilizing conditional logic in medical documentation | |
JP2013537326A (en) | Medical Information Navigation Engine (MINE) system | |
WO2016057468A1 (en) | System and method for evaluating treatment options | |
Alsagaby et al. | Cancer in saudi arabia (CSA): Web-based application to study cancer data among saudis using waterfall model | |
Maclean et al. | Negotiation of collective and individual candidacy for long Covid healthcare in the early phases of the Covid-19 pandemic: Validated, diverted and rejected candidacy | |
US20210225466A1 (en) | Systems and methods for targeted annotation of data | |
WO2017182380A1 (en) | Auto-populating patient reports | |
Mir et al. | Assessing the quality of the after-visit summary (AVS) in a primary-care clinic | |
Smith et al. | Visual evidence: increasing usability of systematic reviews in health systems guidelines development | |
Laitio et al. | Perceived barriers and facilitators in using patient-reported outcome systems for cancer care: systematic mapping study | |
Vrieze et al. | Best practices: the electronic medical record is an invaluable clinical tool: let’s start using it | |
Chaudhry et al. | Designing an Online Appointment System for Semiliterate Users. | |
Choi | Evidence-based research in nursing science: A reproducible framework | |
Kuo et al. | The impact of automatic pre-annotation in Clinical Note Data Element Extraction-the CLEAN Tool | |
De Wet | The development of a contextually appropriate measure of individual recovery for mental health service users in a South African context | |
US20230334076A1 (en) | Determining Repair Information Via Automated Analysis Of Structured And Unstructured Repair Data | |
Folks et al. | Development of a relational database to capture and merge clinical history with the quantitative results of radionuclide renography | |
WO2023201089A1 (en) | Determining repair information via automated analysis of structured and unstructured repair data | |
Zurita et al. | The Transformative Potential of Large Language Models in Mining Electronic Health Records Data | |
US20190392324A1 (en) | Cognitive Analysis and Disambiguation of Electronic Medical Records for Presentation of Pertinent Information for a Medical Treatment Plan | |
Chaparro et al. | Improving the Usability of a Digital Neurobehavioral Assessment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: ONICS INC., NEW YORK Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:WATSON, JAMES VICTOR;REEL/FRAME:026271/0315 Effective date: 20110512 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION |