Determining information

Field of the Invention

This invention relates to a method of, and tool for, determining clinical information, and in particular to determining and outputting relevant ‘suggestions’ for clinical notes based on a user’s input. The invention further relates to selectable dental charts which form part of the clinical notes.

Statements of Invention

Aspects and embodiments of the invention are set out in the appended claims. These and other aspects and embodiments of the invention are also described herein.

According to a first aspect of the invention, there is provided a method of determining clinical information, comprising: receiving entities input by a user; retrieving clinical information relating to those entities, said information comprising further entities; retrieving relationships between those entities and the further entities; calculating relevance scores of the further entities from said relationships; and outputting the further entities, selected in dependence on the relevance scores.

This can provide a dynamic template which adapts for each consultation. The outputs are dependent on the interactions of the user with clinical information and/or notes. As the user can select relevant further entities, the note-taking process can be much faster and more intuitive. As such, it is more likely to be completed during the consultation. The invention can also assist the user, such as a dentist, in reaching a diagnosis and in ensuring that all relevant sections of the clinical notes are completed.

Preferably the method is for use in guiding clinicians or therapists, and/or in assisting them in diagnosing clinical issues. Preferably, the clinical information is dental. The method could be used during dental note-taking or more generally the recording of any clinical notes. The clinical information may be medical, dermatological, aesthetic, podiatric, or therapeutic, including physiotherapeutic. For example, the method may be implemented during consultation with a podiatrist, physiotherapist, beauty therapist or similar. The user may be the patient or a clinical professional, for example doctor, dentist, nurse, or therapist.

Preferably, the method further comprises recording the entities input by a user to clinical and/or patient notes. This facilitates improved and interactive clinical note-taking. Preferably, the clinical information is stored in a database.

The relationships may be directional. The relationships may also be defined by a weighting, and this weighting is preferably used to define and calculate the relevance scores. The relevance scores may be calculated using statistical averaging of the relationship weightings. For example, entities may be linked by a path including further entities, and the relevance scores may be a statistical average of the relationships of the path.

Preferably, the relevance scores are calculated from relationships defined for entities input by a user in a set period, for example in the consultation or in all previous consultations. Preferably, the relevance scores will be calculated using entities present in the patient medical records.

In a preferable implementation of the invention, the further entities are selectable by a user. This can facilitate clean data entry. Clean data can be used for analysis, which may include amending the defined relationships between entities. Preferably, the relationships develop and/or are refined over time, preferably based on previous entities input by users. The selectable entities also facilitate more accurate data entry.

Preferably, the entities input by a user can be both selectable entities and free text entries. The selectable entities may be customizable by a user. Customized entries and/or free text entries are preferably parsed and tokenized. This can ensure clean data entry, which facilities further analysis. Further analysis may include creating links and defining relationships between entities. The clinical information may comprise information relating to the guidelines of regulatory bodies, preferably wherein the clinical information is updated as the guidelines of regulatory bodies are updated. The relationships between entities can be defined according to the regulations. This can assist in ensuring that the recommended protocols are followed, diagnoses reached, and treatments performed. This can also assist in ensuring that all necessary parts of the notes are completed.

In preferable implementations, the method further comprises outputting a warning in dependence on the relevance scores of entities input by a user. This can alert the user, other person, or entity (such as a regulatory body), if the inputs are not aligned with clinical information and/or guidance as stored in the database. For example, if a user does not complete required sections, or a user makes a choice which is not advised (e.g. a diagnosis or treatment). Preferably, the warning is output in dependence on relevance scores within a defined range. The relevant range may be an overall set value or it may be determined for each individual relationship. The warning may be output in dependence on relevance scores indicating low clinical relevance. The method may preferably further comprise outputting a warning when the user inputs entities which have a low relevance score. This can provide a warning that there may be a problem with the notes. It may output a warning if the user omits to select an entity required by regulations.

The method may preferably further comprise outputting a prompt for further information. This may be a prompt for the user to input a justification. It may also be a prompt for the user to input entities in further sections, for example to ask further questions or to perform further tests.

The method may further comprise recording a pattern of user inputs as a workflow, and updating the clinical information defining relationships between entities based on recorded workflows. This can enable the relationships to be updated according to user preferences and normal working practices. As such, the relationships may be refined and kept up to date. This also can allow the system to accommodate the user’s working preferences, and output entities tailored to the user.

Preferably, the clinical information is stored in a global database and a user database, wherein the global database is updated based on recorded workflows from all users, and the user database is updated based on recorded workflows from one user. This can enable relationships to be updated according to what most dentists would do in a particular situation. Updating the user database can enable outputs for each user to be adapted to that particular user.

The method may further comprise screening the recorded workflows before updating the clinical information in the global database. This may be performed using a monitor application. This can prevent anomalous or incorrect inputs from skewing or polluting the global database.

Preferably, the method further comprises determining and/or calculating a typical user workflow based on recorded workflows. The term ‘a typical user workflow’ is herein used to describe a workflow which has been statistically averaged across the workflows of a collection of users for a particular circumstance. Preferably the collection of users is most or all of the users of the system. This can provide a standard against which individual user’s entries can be compared. It can be useful to determine whether a dentist is acting in the same manner as most dentists in a situation.

The method may further comprise outputting a warning when a user input diverges from the typical user workflow. This may be useful to alert a dentist that they are acting differently to the manner in which most dentists would act in the situation. The method may further comprise outputting a prompt for further information. This can enable a user to provide a justification, for example of their actions, choices, inputs or notes, in such an instance. Preferably, the method further comprises determining a score for a user in dependence on user inputs. This may be a risk score, for example a litigation risk score. The score may be determined in relation to relevance scores of the inputs. The score may be determined in relation to similarity between recorded workflows of the user and typical user workflows. This can provide a score representative of the extent to which a user follows typical workflows, and hence, the risk they may be subject to litigation. In preferable implementations of the invention, the method further comprises assigning entities to a location. Preferably, it is an anatomical location. This can assist in determining relevant entities to output. It can also assist in recording detailed accurate dental notes and enable a dentist to easily locate relevant entries of previous notes.

The method may comprise assigning entities to more than one location, preferably wherein the locations are connected, more preferably wherein the locations are connected in a hierarchical structure. This can allow entities to be assigned to, for example, more than one tooth. Anatomical locations are often connected, for example adjacent teeth, and this may be used in calculating relevant entities to output to connected locations. Preferably locations are offered in a hierarchical structure, and more preferably different levels are selectable. Preferably, these include arches, sextants, quadrants, teeth, and teeth surfaces and roots.

In a preferable example of the invention, the method further comprises storing the assignable locations on a visual chart, wherein the assignable locations are selectable on the visual chart. This can allow visualisation of the relevant locations. Preferably the visual charts are connected to the clinical notes. This can also facilitate selection of a location or locations directly on the visual charts. The connection of text notes and visual charts advantageously allows a dentist to collate the dental records.

According to a further aspect of the invention, there is provided a method of outputting clinical information, comprising: outputting text notes comprising user selectable entities; outputting visual charts comprising user selectable locations; and connecting the text notes and the visual charts.

The term ‘connecting’, ‘connected to’ or similar wording is used herein to mean that information entered or recorded to one of the text notes and the visual notes is also recorded to the other. This may be implemented via recording to a shared and/or joint database. Information from the shared and/or joint database may be output to one or both of the text notes and the visual notes, for example to be displayed. This advantageously allows a user to enter clinical notes at a single point combining both text and visual notes, which can facilitate faster and more intuitive note-taking. As the text notes and visual charts are connected, repeated and duplicated entry of data can be avoided. As the entities and locations are selectable, this can further enhance the speed, accuracy, and convenience of note-taking.

Preferably, upon selection of the selectable locations, the locations are recorded in the text notes. This can allow a user to select a location or locations on the visual charts and then input text notes directly.

Preferably, the entities are assigned to a location, and the text notes are displayed on the visual charts. As the entities are assigned to a location, they can be recorded centrally according to location and then output to both the text notes and the visual charts.

The visual chart may comprise intersecting locations, and preferably the locations are connected, more preferably the locations are connected in a hierarchical structure. This can facilitate entities being assigned to more than one location. This can also allow more than one location to be selected and provides a choice between broader and more specific locations.

Preferably the visual chart displays a selection of different anatomical views comprising user selectable locations. More preferably, the views are anatomical diagrams. This can provide a user with a range of selectable views, which can facilitate more accurate selection of a relevant location. ln preferable implementations of the invention, the view displayed is determined by the entities selected in the text notes. This can mean the most relevant view can be output to a user, which can increase the efficiency of notetaking. Preferably, this is determined using relationships defined between entities, wherein the entities include locations. This may be determined by calculating relevance scores of the locations in dependence on the entities selected in the text notes.

Preferably, the method further comprises outputting entities in the text notes in dependence on the location selected in the visual charts. This can also increase the efficiency of note-taking by outputting relevant entities. Upon selection of a location or locations in the visual notes, a folder may be initialized.

Preferably, multiple locations may be selected concurrently. Multiple locations may be selectable upon initiation of a selection state, preferably wherein selected locations are recorded in text notes upon termination of the selection state. The selection state may be initiated upon a first action. The selection state may be terminated upon a second action. The first/and or second action may be cursor selections and/or mouse clicks. In the selection state, locations may be selected without the requirement of specific user actions, for example without the need for further cursor selections and/or mouse clicks. The locations may be available for selection in dependence on those locations which have previously been selected. In preferable implementations, the locations are available for selection in dependence on being defined in a same category as those locations which have previously been selected. The category is preferably defined by clinical information. The category may be defined by anatomical information. For example, the categories may include tooth surfaces, mouth quadrants, individual teeth, and sextants.

Preferably, the method further comprises taking a measurement in dependence on the further entities.

Preferably, the method further comprises configuring a device in dependence on the further entities.

Preferably, the method further comprises transmitting the further entities to a device. Preferably, the operation of the device is dependent on the further entities.

Preferably, the device comprises a monitoring device and/or a surgical tool and/or a dental tool.

According to a further aspect of the invention, there is provided a tool for determining clinical information, comprising: a means for inputting entities; a means for storing clinical information, comprising entities and relationships between entities; a means for calculating relevance scores from relationships between entities; and a means for outputting entities.

Such a tool can aid a dentist in taking notes during a consultation. The tool of the present invention can provide an adaptive template, which outputs relevant entities to the consultation. Such a tool can also aid a dentist in understanding which notes need to be recorded and in completing the relevant sections.

Preferably the tool comprises a display and/or user interface, a keyboard and a processor, and more preferably further comprises a computer mouse. Preferably the means for inputting entities comprises a keyboard and/or mouse and/or alternative means for selecting and inputting entities. Preferably, the means for calculating comprises a computer processor. Preferably the means for inputting entities and/or the means for outputting entities comprise a user interface. Preferably the means for storing clinical information comprises a computer database.

Preferably the means for calculating the relevance scores and the means for outputting entities are configured to cooperate such that entities are output in dependence on the relevance scores. Preferably, the means for calculating relevance scores from relationships between entities is further configured to rank the relevance scores. Preferably the means for outputting entities is configured to output those entities with the highest relevance scores. If the relationships are amended at any point, the relevance scores can change as a result, so that different entities may be considered more relevant and are output preferentially.

The means for storing clinical information may further comprise information relating to the guidelines of regulatory bodies, preferably wherein the clinical information is updated as the guidelines of regulatory bodies are updated. Preferably the means for storing clinical information comprises recommended protocols, more preferably it comprises information on typical practices.

Preferably the means for calculating relevance scores is further configured to determine warnings, and the means for outputting entities is further configured to output warnings. A warning may be output if an entity is input having a low relevance score or an entity required by regulations is omitted.

The means for inputting entities preferably comprises selectable entities. Preferably the means for inputting entities comprises a display. Preferably the means for outputting entities comprises a display. More preferably the means for inputting entities and the means for outputting entities comprise the same display, and even more preferably the output entities are selectable. The means for inputting entities may be configured to allow the input of new entities, preferably by free-text entry. The means for inputting entities may further be configured to allow customization of selectable entities, preferably by free-text entry.

The tool may preferably further comprise means for collecting data. This can allow the relationships to be defined and amended. Preferably the means for collecting data comprises a user interface and/or a keyboard and/or mouse and/or other means for inputting data.

In a preferable implementation, the means for storing clinical information comprises a global database and a user database. Preferably, each user has a personalized individual user database. In a preferable implementation, the user database is updated according to a user’s inputs. This can facilitate the outputting of entities according to a user’s individual preferences. Preferably, the global database is updated according to user inputs across all users. This can allow the determination of ‘typical workflows’, or ‘what most dentists would do’ in a particular circumstance. A ‘typical workflow’ may be calculated from the statistical average of user inputs. The tool may further comprise means for monitoring the inputs. This can prevent anomalous or incorrect entries from polluting the global database. The databases may be configured to be updated by updating and/or adding entities. The databases may be configured to be updated by updating and/or adding relationships between entities.

Preferably, the entities are assigned to a location. This may be an anatomical location. The entities may be assignable to more than one location, preferably wherein the locations are connected. The locations may be connected in a hierarchical structure. This can allow the location to be made more specific later.

In a preferable implementation of the invention, the means for inputting entities comprises text notes comprising entities selectable by a user and visual charts comprising locations selectable by a user, wherein the text notes and the visual charts are connected. Preferably the means for outputting entities comprises text notes and visual charts, wherein the text notes and visual charts are connected. In a preferable implementation, the means for inputting entities and the means for outputting entities are provided on the same display. More preferably, the means for inputting entities is configured such that entities and/or locations can be input by selection.

According to a further aspect of the invention, there is provided a tool for determining clinical information, comprising: a user interface for inputting entities; a computer database for storing clinical information, comprising entities and relationships between entities; a computer processor for calculating relevance scores from relationships between entities; and a user interface for outputting entities. This tool is configured to perform the functions as described above. The user interface for inputting entities may be the same user interface as the user interface for outputting entities. According to a further aspect of the invention, there is provided a tool for outputting clinical information, comprising a means for outputting text notes comprising entities selectable by a user and a means for outputting visual charts comprising locations selectable by a user, wherein the text notes and the visual charts are connected.

This can allow a user to select data for input into the notes via both the text notes and the visual charts. As the text notes and visual charts are connected, the inputs into both can be recorded centrally, and can be output to the both the text notes and the visual charts. This can mean that the same notes do not need to be entered twice, and that they are easily accessible in the future.

Preferably, the means for outputting text notes is a user interface or alternative form of display. Preferably, the means for outputting visual charts is a user interface or alternative form of display. The means for outputting text notes and means for outputting visual charts may be the same user interface or alternative form of display. The text notes and the visual charts may be output concurrently, for example adjacent to one another.

Preferably the visual chart comprises locations assignable to the entities. More preferably, the visual chart comprises anatomical locations assignable to the entities. The locations may be represented on anatomical diagrams. Preferably the visual charts comprise different views which are selectable by a user. These different views may include teeth, intraoral regions, facial symmetry, and lymph nodes. The locations may be connected, and are preferably connected in a hierarchical structure. Preferably, more than one location can be selected.

According to a further aspect of the invention, there is provided a tool for outputting clinical information, comprising a user interface configured to output text notes comprising entities selectable by a user and to output visual charts comprising locations selectable by a user, wherein the text notes and the visual charts are connected. This tool is configured to perform the functions as described above.

The tool may be an apparatus and/or a device.

According to a further aspect of the invention, there is provided a system comprising the aforesaid tool and a further device, wherein the operation of the further device is dependent on the entities output by the tool. Preferably, the further device comprises a monitoring device and/or a surgical tool and/or a dental tool.

As used herein, the term ‘entities’ is used to mean any item of abstract or real data and can be used interchangeably with the term ‘item’. As used herein, the term ‘chart’ refers to visual and diagrammatic representations of anatomical locations, used for recording clinical data in patient notes.

The invention also provides a computer program and a computer program product for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, and a non- transitory computer readable medium having stored thereon a program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.

The invention also provides a signal embodying a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, a method of transmitting such a signal, and a computer product having an operating system which supports a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.

Any apparatus feature as described herein may also be provided as a method feature, and vice versa. As used herein, means-plus-function features may be expressed alternatively in terms of their corresponding structure, such as a suitably programmed processor and associated memory.

Furthermore, features implanted in hardware may generally be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa. Furthermore, any, some and/or all features in one aspect can be applied to any, some and/or all features in any other aspect, in any appropriate combination.

It should also be appreciated that particular combinations of the various features described and defined in any aspects of the invention can be implemented and/or supplied and/or used independently.

Brief Description of Fiqures

Figure 1 shows a schematic illustration of the structure of a system;

Figure 2 shows a schematic of a portion of an example workflow;

Figure 3a shows an example clinical notes folder;

Figure 3b shows a further view of the example clinical notes folder of Figure 3a;

Figure 3c shows a yet further view of the example clinical notes folder of Figure 3a;

Figure 3d shows a yet further view of the example clinical notes folder of Figure 3a;

Figure 4 shows an example clinical notes folder including a visual dental chart;

Figure 5a shows an example visual dental chart visualising teeth;

Figure 5b shows an example visual dental chart visualising teeth segments;

Figure 6a shows an example visual dental chart visualising intraoral regions;

Figure 6b shows an example visual dental chart visualising intraoral regions segments;

Figure 7a shows an example visual dental chart visualising facial symmetry;

Figure 7b shows an example visual dental chart visualising facial symmetry segments;

Figure 8a shows an example visual dental chart visualising lymph nodes;

Figure 8b shows an example visual dental chart visualising lymph nodes segments;

Figure 9 shows a further example visual dental chart; and

Figure 10 shows a further example clinical notes folder including a visual dental chart.

Specific Description Data structure overview

Figure 1 illustrates an overview of the data structure of the clinical notes software. Dental knowledge is recorded in a database comprising both a global knowledge base 10 and a user knowledge base 20. The global knowledge base 10 has at its foundation fundamental dental clinical knowledge. It is maintained to be up to date with the current rules and guidelines of the relevant regulatory bodies in which the dentist is practising; in the UK these are the NHS, General Dental Council (GDC), Faculty of General Dental Practice (FGDP) and the Scottish Dental Clinical Effectiveness Programme (SDCEP). The data is constituted of ‘entities’ (or ‘items’), which include symptom questions, symptom question answers, clinical tests, clinical test results, diagnoses, actual diagnoses, clinical test results diagnoses, diagnoses risks, treatments risks, diagnosis descriptors, diagnosis descriptor results, treatments, actual treatments, materials, and benefits of resolving. The entities are connected by weighted and directional relationships. The global knowledge base 10 is a database built through the data collection tool 45 using clinical expertise to determine these relationships between entities. The data collection tool 45 preferably comprises a user interface to enable the input of clinical information. When completing dental notes, a user will input data, typically via a further user interface 40. The suggestion engine 30 is a processor that can use the relationships defined between entities of the global knowledge base 10 to output ‘suggestions’ to the user in the user interface 40. The ‘suggestions’ are further entities, which are calculated to be relevant to the preceding user inputs, and therefore are likely to be options for the next inputs. Through the user interface 40, changes are made directly to the user knowledge base 20, which form a further database. These changes are then filtered through the monitor application 25, in order to make changes to the global knowledge base 10. Through this method as well as through the data collection tool 45, the system can be continuously developing and evolving.

The modules described with reference to Figure 1 are typically implemented using a computer device. For example, the method steps disclosed herein may be implemented using a processor, which may be a central processing unit (CPU), a graphical processing unit (GPU), or any other type of processing unit. Typically, the computer device comprises one or more of: a communication interface (such as a wired interface, a local area network interface, and/or a Bluetooth® interface) for receiving and/or transmitting information; a user interface (e.g. a touch sensitive display) for receiving and/or outputting information; and a memory (e.g. ROM or RAM) for storing information. Where methods are disclosed herein, these methods may be computer-implemented methods. An computer device for implementing these methods is also disclosed herein.

In use, the user is able to input data in the form of entities, and the software will output ‘suggestions’ as to the next relevant data input required. An example of a simple input and output workflow is shown in Figure 2, in which data related to a patient’s pain is input into the system. At 200, the user indicates the patient complains of ‘pain’. The system outputs a prompt to the user to query whether the pain is ‘intermittent’ or ‘constant’ at 210. If the user selects ‘intermittent’, a first set of follow up questions are displayed at 220. Alternatively, if the user selects ‘constant’, a second set of follow up questions are displayed at 230. The outputted follow up prompts 220, 230 are selected in dependence on the relevance to the previous input as calculated by the suggestion engine 30 from the relationships defined in the knowledge databases. For example, the entity ‘duration present’ as a prompt for follow up questions relating to patient pain is not relevant if the pain is continuous, so is not output if the user selects the entity ‘constant’ at 210. However, if the user selects that the pain is ‘intermittent’ at 210, it is relevant to prompt the dentist to ask and record the duration the pain is present, and so the entity ‘duration present’ will be output by the suggestion engine 30.

The entities output by the suggestion engine 30 are divided into two categories: static suggestions and dynamic suggestions. Static suggestions are entities that are always output in particular circumstances, such as in response to particular other entities. Static suggestions are suggested at page initialization and are then rendered in the front-end user interface when a ‘parent’ entity is selected. Examples of such static entities include risks that are outputted when a user selects a certain treatment. These risks are always present when the treatment is performed. Further examples may include benefits of treatment, which always remain the same and as such are ‘static’. Static suggestions are defined by static or fixed relationships stored in the global database 10. In contrast, dynamic suggestions are entities that are determined and outputted in dependence on the entities selected prior to the request. The further entities are assigned a relevance score calculated using the relationships defined between entities in the system’s knowledge base. Those entities with the highest relevance scores will be output by the suggestion engine 30 to the user. As illustrated in Figure 3a, the output includes both ‘suggested’ prompts 310, such as ‘Symptom started’, and ‘suggested’ inputs 312, such as ‘Today’, ‘Yesterday’, and ‘A few days ago’.

The suggestion engine 30 calculates relevance scores from the relationships as defined in both the global knowledge base 10 and the user knowledge base 20. An individual user knowledge base 20 is developed for each user. The user knowledge base 20 has its foundations in the global knowledge base 10 and then is developed over time to adapt to the preferences of a user. For example, if a user searches for a new input, this new input is recorded to the database. The data is parsed and tokenized, and the system can create or develop relationships between this and other entities. The system can then offer this new input in later sessions. The user can add, edit, and delete suggestions to develop a customized knowledge database. Over time, the system also develops its outputs according to the user’s preferences. The suggestion engine 30 sorts and ranks suggestions based on their likelihood of being relevant to the user by calculating the relevance scores using the weighted relationships between entities. It then outputs the highest scoring entities. The weighting of the relationships between entities is first defined in the global knowledge base 10. As the system records each individual user’s workflows, it will amend the weighting accorded to the relationships between entities and store these amended relationships in the user knowledge base 20. The sorting and ranking system uses the relationships defined in both the global knowledge base 10 and the user knowledge base 20 to calculate the relevance scores, with preference being given to the user knowledge base 20 of each individual user. The weighting accorded to this preference of the user knowledge base 20 may change over time, for example it may increase as the system is able to predict the user’s preferences with greater confidence.

The global knowledge base 10 has at its foundation fundamental dental knowledge which is input via the data collection tool 45. The knowledge base also continuously expands through the inputs of users across the global system. Data is input either through selectable items which facilitate standardised data input, or through free text entry, which is parsed and tokenized. These data entry techniques build a clean database, which allows easy organization of the data records. This means not only can a user have better and more efficient access to records in future, but analysis of the data is possible. The global knowledge base 10 is developed by reviewing the inputs across all users. The data is preferably anonymised before it is recorded to ensure adherence to patient confidentiality and data protection regulations. In order to ensure that the global knowledge base does not become diluted, and to prevent erroneous or anomalous entries from individual users polluting the global knowledge base 10, the inputs of the individual users will not automatically update the global knowledge base 10. The data input by the users is, however, recorded and ranked by the monitor application 25. The input to the monitor application 25 consists of the frequency of creating, editing, and deleting of entities and relationships and shows the most common updates to the dentist who is reviewing it. After undergoing a manual check by a dental professional for clinical accuracy, this data can be used to develop the global knowledge base 10. This can be carried out using the data collection tool 45. The development may take the form both of adding new entities and adjusting the relationships between entities. The weighting and/or directions of the relationships may evolve, and new relationships may be added to the knowledge base. In this way, over time the global knowledge base 10 expands and adapts, using the collective knowledge of all users of the system. Over time, the suggestion engine 30 may also evolve such that some entities may be moved from static suggestions to dynamic suggestions and vice versa.

The system employs a range of analytical techniques to develop the knowledge databases. These include an autorelationship generator, which enables the system to recognise a group of related entities from system usage and automatically create missing relationship links and adjust the weighting of the existing relationships. Natural Language Processing (NLP) techniques can be utilized to understand the context of any user inputs, in particular free-text entries. This can aid in defining new relationships and adjusting existing relationships. It can also aid in determination ofwhether a particular input is only relevant to the current session, or whether it is a more permanent entry. This distinction is important in recalculating relationship weightings, in determining new relationships, and in the assessment of whether a new relationship may be relevant to the global knowledge base 10. As the system parses the inputs using tokenization, entries are cleaned to add to the databases. This enables the system to precisely identify whether the entity already exists in the databases. This also facilitates a more powerful search functionality. For example, entities can be recognised by synonyms and commonly used alternative names, phrases, or abbreviations. This is because the system can recognise the connection between these words and the entries can be assigned categories, from which the system can then recognise similar data. Additionally, the suggestion engine 30 may output suggested predictive words or sentences based on a user’s initial input(s). This can be achieved using a k-nearest neighbours algorithm to determine and suggest entities already defined in the knowledge databases.

The clinical notes are separated into sections. The list of sections offered include: patient complaint, medical history, social history, extraoral soft tissue exam, intraoral soft tissue exam, screening, intraoral hard tissue exam, clinical tests, imaging, diagnosis, patient risks, treatment discussion, further discussion, treatment plan and consent and treatment and post-operative complication. The data input by the user is assigned an anatomical location and then organised into folders within the section: for example, a particular tooth or quadrant of the mouth. Using the example of the ‘pain’ workflow illustrated in Figure 2, the user can first select the ‘pain’ item within the 'patient complaint' section, after which they are prompted to indicate the location to which this information pertains. Alternatively, the user can first select the relevant location to create the folder and then populate the folder with information. It is possible to assign folders not only to the teeth, but also the areas of the mouth, lymph nodes, facial symmetry, and intraoral regions. The system defines a hierarchical list of locations, including quadrants, sextants, individual teeth, and the surfaces and roots of each tooth. As such, each input of data is likely to be associated with several different ‘cascading’ locations - for example a tooth is within a particular quadrant. The folders are therefore interconnected, for example, data input into a folder for the ‘upper right 7’ will also be recorded into the folder of the ‘upper right quadrant’.

The entities and relationships between entities in the knowledge database are defined according to location. Accordingly, the entities outputted by the suggestion engine 30 are also location-based. For example, clinical tests outputted as a result of inputting a patient complaint of pain in the upper right 7 tooth will be different than those suggested as a result of inputting a patient complaint of pain in their soft tissue. More specifically, if, for example, an extraction is being carried out on an upper 6, 7 or 8 tooth then the system will present Sinus perforation as a possible risk. By contrast, if a lower tooth were selected then this risk would not show. If an entity relevant to soft tissue is selected, then suggestions relevant to non-soft tissue areas will not be made. Specifically, if the patient complains of a lesion in the roof of their mouth then diagnoses which are linked to tooth-specific areas are excluded. As a further example, if the patient complains of pain on the tongue, the output diagnoses would not include caries but might include a lesion.

Figure 3a shows an example of a section folder 300 created for inputting data into the clinical notes. In this case a folder has been created when a user selects ‘pain’ in the ‘upper right 7’. The folder 300 has a name 302 corresponding to the relevant anatomical location: in the illustrated example this is ‘UR7’. Each folder is split into sections 304 which have a subheading 306, in this case corresponding to the particular patient complaint of ‘Pain’. Within each section of the folder are subsections 310, and in each subsection 310 the software outputs a relevant prompt for clinical notetaking and corresponding ‘suggested’ inputs 312. The user is able to select the suggested inputs 312. This allows faster note-taking than free text entry systems that are currently in use. The dentist can therefore record the notes during the consultation rather than completing the notes after the patient has left, which ensures greater accuracy. Additionally, as the system outputs prompts and defined responses, paragraphs of written text are not required. As such, the dental nurse can take a more active role in note-taking. In current systems, dentists will often attempt to speed up the free-text note-taking process by creating their own templates for free-text entry. However, these templates are not suitable for all situations, which can lead to significant omissions in the notes. Also, they can soon become out of date in respect of changing guidelines and regulations. By outputting an accurately adaptive template, the system of the present invention facilitates accurate and tailored clinical note-taking. Additionally, the use of selectable suggested inputs ensures clean data entry. This facilitates the recognition of inputted entities, determination of relationships between the inputted entities and other entities, and then the output of relevant suggested entities. The suggestion engine 30 determines the outputted prompts or questions 310 and suggested inputs 312 from the global knowledge base 10 and user knowledge base 20 as described above. The outputs are determined by the calculated relevance scores of these entities in relation to the user’s prior inputs in the patient consultation (and the medical history recorded in the notes from previous consultations). In the example illustrated in Figure 3a, the user has input that the patient is complaining of pain, so the suggestion engine 30 calculates the relevance scores of further entities and outputs those with the highest relevance score. Accordingly, the suggestion engine 30 outputs relevant symptom questions such as when the pain started, how it can be described and how it might be alleviated or exacerbated. The outputted symptom question answers 312 can be selected by the user (for example by clicking on them), as illustrated in Figure 3b. Once a user has selected a particular response and moves onto the next symptom question, the folder view adapts so that only the selected answer 322 remains, as illustrated in Figure 3c. The user may go back and amend their answer, in which case the further suggestions 312 will be visible again. Once the user is satisfied with their notes, they can save notes to the patient’s notes folder in the practice system. As the folders are assigned to an anatomical location, the complete clinical notes of each anatomical location will be easily accessible to the user in future appointments. The dentist does not need to search through numerous free text entries in each patient’s folder, which are often organised by date rather than location, to find the relevant clinical history.

The interface provides functionalities for the user to amend the inputs. The user may add their own answer by selecting the supplementary input icon 314; in this illustrated example this is provided as This can be input as a free text entry. As previously discussed, the system may then parse this entry to tokenise it and assign it to a known category. This can facilitate the determination of relationships between this new entity and existing entities in the databases. Selecting the supplementary input icon 314 can also allow a user to search for further entities which are already present in the system but which have not been output as they were assigned a score below a threshold of relevance. The user may also amend the existing defined responses that have been output by the suggestion engine 30. In the example illustrated in Figure 3d, the user amends the answer ‘Today’ to the more specific Today, morning’. The user can remove sections or subsections by clicking the associated remove button 316, 318, which in the illustrated examples is labelled with an ‘X’. The remove button may be output automatically, or it may become visible when the cursor 390 hovers over the relevant area. This allows the user to quickly remove suggested sections which are not of interest or are not relevant, so that they can quickly and efficiently adapt the template to their requirements.

The system records any customisations that the user makes, and any new inputs that they enter. These can be recorded as ‘workflows’. It may use natural language processing (NLP) to assign any new free-text entries to a particular category, which can be useful in determining relationships between this new entry and other entities. Regardless of whether the user inputs any new or customised entities, the system records the ‘workflow’ that the dentist follows. The ‘workflow’ in this context is the pattern of steps the dentist takes in note-taking, such as which entities they select and the order in which the select them. This is used to update the user knowledge database 20 according to the user’s preferences. As a result, in future the suggestion engine 30 will output suggested prompts and inputs according to the user’s individual preferences. From the records of workflows by all dentists using the software, the system can learn what most dentists would do in particular situations. This insight is used to amend the relationships between entities as defined in the global knowledge database 10. This also provides a useful standard against which to measure an individual’s workflow. The system defines a ‘typical workflow’ based on “what most dentists would do” in a particular situation. This is calculated from the statistical average of the recorded workflows of all dentists using the software (although some anomalous workflows may be removed by manual checks using the monitor application 25). The user will be notified by the system if their workflow diverges too far from such a typical workflow. As the system obtains clean input data, this enables interconnection of the patient records. The system can generate accurate and personalised consents and prescriptions during the consultation. Using the information input by the user, the clinical notes software can output directly personalized treatment plans and associated consent forms. The system also enables the integration of clinical review features such as charts, treatment planning, payment systems and appointment systems. Because the entities are tied to specific locations, when formulating a treatment plan a single entity can be associated with all of its relevant locations in one plan. For example, an extraction may be required on UR 4,5,6 and LR 5,6,7. From the entity relationships, the system determines that the UR 4,5,6 extraction is linked to a risk of Sinus perforation, while the LR 5,6,7 extraction is linked to a risk of Inferior Alveolar Dental nerve damage. Consequently, when consenting for this treatment plan, the system outputs each of these risks so that they are clearly outlined to the patient in the consent form.

Additionally, the interconnection of patient records enables the system to output a clear illustration of the link between diagnosis and treatment. As each diagnosis is linked to a location, the system includes this information to personalise the consent form or treatment plan. For example, a dentist advises the patient that a tooth needs an extraction because it has caries. The link between diagnosis and treatment is clearly illustrated to the patient. This connection is important for informed consent.

As a further example, the system can directly output the consequences of no treatment. The entity relationships define the consequences of no treatment being performed. The specific outcomes are linked to a specific diagnosis or diagnoses. For example, the consequence of not treating reversible pulpitis might be further pain, infection and swelling. By contrast, different consequences will arise if periodontitis goes untreated. Therefore, the consequences of no treatment are highly specific and tailored to the patient diagnosis. The system can output the specific consequences for each diagnosis. It is important to let the patient know the consequences of not having treatment if they refuse a recommended treatment. Furthermore, the system can output the shared risks and benefits of treatments, which can assist patients choosing between treatment options.

By way of further illustration of the interconnection of the patient records, the entities defined in the patient’s medical record are used in formulating the treatment plan. Treatment plans should consider individual patient factors such as medical history and age of a patient. For example, a lower fluoride toothpaste would be recommended for a patient under the age of 16 than one recommended to a patient older than 16. As a further example, if a patient is taking warfarin, metronidazole would not be prescribed as is modifies its efficacy.

Suggestion and warning system

The suggestion engine 30 is based on fundamental dental knowledge, the collective dental knowledge recorded across users, and dental guidelines. It is updated to remain in step with these guidelines as they are revised and as the system learns more about the workflows of the global community of users. The suggestion engine 30 can output warnings to a user. These can occur if a dentist chooses to do something that is not recommended based on the current clinical notes, the dentist chooses to do something that is anomalous compared to the behaviour of the global collective of dentists, and/or if a dentist omits mandatory notes for certain stages of a procedure. In any one of these instances, a user will be choosing inputs which have a low relevance score as calculated by the suggestion engine 30 based on the relationships defined in the knowledge databases. This may be important if a dentist is required to defend their actions in a future lawsuit. Firstly, the defence of a dentist’s actions often depends on whether they acted in the same manner as most dentists would in the same situation. It is therefore beneficial for the system to compare the user’s workflow with what is determined to be the norm based on the actions of the global community. Therefore the system computes a ‘typical workflow’ from the global community as described previously. Each user’s inputs are compared against the ‘typical workflow’ and the system outputs a warning when these diverge. Additionally, incomplete notes can make it impossible to effectively defend a dentist’s actions. Current dental guidelines often stipulate the requirements of dental records, including which information must be recorded and which sections must be present. The system can therefore also output a warning if the notes are incomplete, and/or sections required by the current guidelines are missing. The warnings can include the output of a request for the user to provide further information, which may justify their actions and can later be used if required in a defence. A justification can be entered as free-text. Suggestions and warnings can be output at any point within the chart, examples of which are provided below.

Patient complaint

The suggestion engine 30 can output likely complaints that a patient may have based on their medical history. For example, the user can input in the ‘medical history’ section of the notes that the patient is taking prednisolone. This medication can lead to dry mouth, and so this is reflected in the weighted relationship between the two entities. The suggested input ‘dry mouth’ in the patient complaint section will therefore have a high relevance score and will correspondingly be output to the user. Dry mouth can be an easily and commonly missed symptom. As the system prompts the user to ask about this specifically, it is more likely that the dentist will pick up on it and record it in the notes. This means the recorded notes are more comprehensive and, as such, a more accurate diagnosis is likely to be reached.

Intraoral hard tissue examination

The suggestion engine 30 can output suggestions as to what the user might see when they examine the patient. For example, a patient may attend having undergone trauma: as a result of taking a punch to the face, a tooth has changed position. Such a situation does not occur very frequently, so it is likely that a dentist would not be familiar with the correct documenting format and requirements. However, the global knowledge database 10 defines information regarding how this should be documented and on what the dentist is likely to observe. The suggestion engine 30 outputs the relevant sections to complete and ‘suggestions’ of input regarding the diagnosis that a dentist might observe when they examine the patient. In this way, the system leads the user to document the injury correctly and fully by completing the required sections and subsections. As such, the suggestion engine 30 can be considered output a relevant and up to date ‘template’, which can be described as ‘adaptive’ to the situation.

Clinical Tests

The suggestion engine 30 can output the correct clinical tests to perform. For example, if a patient has suffered trauma to a tooth then guidelines suggest that there are six clinical tests that should be carried out on the affected teeth. These will be defined in the global knowledge database 10 and the suggestion engine 30 will output them to the user in the clinical test section. Guidelines are constantly changing within dentistry and it is difficult for dentists to remember all changes and updates. Therefore, the system can take into account relevant guidelines and adjust the relevancy weighting for certain relationships to ensure that the user is alerted to input the most relevant tests.

Imaging

The suggestion engine 30 can output the correct imaging to perform. For instance, when the gums are checked as part of the screening process, the results from this can influence which images need to be taken. For example, if there are deep pockets then it is advised that periapical radiographs are taken. This is a further example of the relationships being defined based on regulatory guidelines. If a radiograph is not taken the system will output a warning to the dentist that it is highly recommended.

The suggestion engine 30 can output what the user might see in the imaging. When an x-ray is taken, it is important for the dentist to write a report on what they have found on the image. X-rays are one of the most difficult tests to report on as they can indicate so many different diseases and therefore - unlike other clinical tests which have set answers - the information obtained from x-rays is extremely varied. The system can output ‘suggestions’ of what might be seen. The suggestion engine 30 calculates a relevance score for potential observations using the previously input entities. It then outputs those further entities which have a high relevance score, which can assist in x-ray reporting. For example, if a patient has complained of pain on biting then the suggestion engine 30 may output that it is likely that changes in the bone beneath the affected tooth might be seen in the radiograph. The outputted suggestions for what might be observed in the x-ray report prompts the user to look for these items. This helps to prevent the dentist from missing out important diagnoses. Additionally, it enables quick, complete, and intuitive input into the clinical notes.

Diagnosis

The suggestion engine 30 can output the most likely diagnoses for a particular location. Based on the previously input data, the system can calculate and output the most likely diagnosis for a particular tooth. For example, a dentist has input ‘decay’ for a particular tooth and inputted a clinical test result indicating that the nerve of the tooth is dead. The system will then calculate and output the most likely diagnoses based on the relationships defined between these entities in the global knowledge base 10.

The suggestion engine 30 can output a warning when the user has chosen an item of low relevance. The system can ask the user to justify their choice and/or suggest a further clinical test to confirm this diagnosis. When inputting data into the clinical notes, the user does not need to choose from only the suggested entities. As outlined previously, the user is able to input their own response (via free-text entry) or search for a further response (which may be a further selectable entity which is already defined in the system). These entities were not output by the suggestion engine 30 as their relevance score was below the threshold. As such, by choosing this alternative response the user is choosing a response which has not been scored well by the suggestion engine 30 based on the relationships defined in the global knowledge base 10 and user knowledge base 20. This will prompt the system to output a warning to the user and request that they provide further information, usually in the form of an explanation justifying this course of action. The suggestion engine may also output further clinical tests to confirm and/or justify this diagnosis. For example, the suggestion engine 30 may calculate a high relevance score for a filling, but the dentist is instead extracting the tooth at the request of the patient. The system prompts the user to input into the clinical notes a justification for their action. Without this on record, the dentist’s actions are not defensible in any potential lawsuit.

The system outputs suggestions which direct the dentist to choosing the correct diagnosis. Then, if the dentist deviates from the course of action considered by the system to be what most dentists would do (as defined in the ‘typical workflow’ for the situation), the system with output a prompt for justification. This can help to ensure the notes provide a more robust and thorough clinical record, which is important should the notes come to be assessed as part of a claim against the dentist. During legal proceedings against a dentist, a critical question is often whether the dentist acted in the manner most dentists would have acted, and if not, a robust justification is required. As the global knowledge base 10 can be evolved based on the inputs of dentists across the system, the system provides an up-to-date indication of the course of action chosen by most dentists in any clinical situation.

The user knowledge base 20 develops overtime as the system learns the individual user’s preferences. Often, this may only relate to nuances of the manner in which the user prefers to work and/or to input data. Alternatively, it may simply be a result of the user having particular expertise in a certain area of dentistry and so the system suggests outputs relating to ‘typical workflows’ within this area. However, there may also be situations in which the user knowledge base 20 diverges in a way that could cause some concern. For example, the user may frequently choose a response to a prompt which is given a low relevance score by the suggestion engine 30 based on the relationships defined in the global knowledge base 10. This will cause the relationship between the relevant entities to evolve in the user knowledge base 20, so that the relevance scoring changes and this response starts being output to the user. The relationship defined between the relevant entities in the user database 20 will therefore differ from the relationship defined in the global database 10. Once this has occurred, a situation can arise in which the user’s chosen input does not deviate significantly from the relationships defined in the user knowledge base 20 but does deviate significantly from the relationships defined in the global knowledge base 10. In this situation, the system will output a warning and a request that the user input further information including a justification. The system may also provide a general warning to the user that the user knowledge base 20 has diverged in this way from the global knowledge database 10. The user may preferably be able to input a justification which will be fed back to the monitor application 25. If the justification is considered valid and clinically sound, this may be used to redefine the relationships in the global knowledge base 10. For example, there may be more complex factors relevant which are not yet defined in the global database 10. If the dentist checking the monitor application 25 agrees with this justification, the global knowledge base 10 can be developed to define more complex and sophisticated relationships.

The system may also calculate a ‘risk score’ or a litigation risk score’ for each user based on the manner in which a user interacts with the system. This may be dependent on the relevance scores of the inputs chosen by the user, relative to the preceding inputs. For example, the user may score poorly if they often choose an input which has a low relevance score in their workflow. The score may also be dependent on the extent to which the actions of that particular user are aligned with the actions that most dentists would take, as defined in the global database 10. This may be a comparison of the user’s inputs and/or workflows in relation to a determined typical user workflow. This may also be dependent on the extent to which comprehensive notes are taken, including, for example, justifications where necessary.

The suggestion engine 30 can also output suggestions relating to rarer diagnoses. Oral cancer has a low survival rate and the earlier it is picked up the higher the chance of survival. There are hundreds of lesions present that are sometimes linked to factors that are not easily recalled by the dentist, for example in the medical history. Dentists are usually good at picking up on and describing a lesion but not always good at knowing what this lesion is as they are rarely seen. Therefore a dentist may likely be unsure of how quickly the patient needs to be seen by an oral medicine department. The system outputs ‘suggestions’ in the form of prompts and relevant inputs, which guide the dentist to describe the lesion in a defined manner. Based on this description, the system can output possible diagnoses as well as flag possible warning signs exhibited by the lesion. In this manner, the system can ‘warn’ the dentist of suspicious lesions. As the database also defines relationships between diagnoses and treatments, the suggestion engine can also calculate and output possible treatments to try in the meantime.

Treatment

The suggestion engine 30 can output the treatment which is most likely required. Once the user has entered the relevant information, such as the diagnoses, the system outputs ‘suggestions’ of the treatment or treatments required based on their relevance scores. For example, in the case of a decayed tooth, the system may output the options of a filling or a crown. The system will not output irrelevant suggestions such as, for example, cleaning the tooth, as this will have a low relevance score. The system allows for further detailing of diagnoses that can influence treatment. For example, suggestions for early decay may include monitoring; decay into the dentine may include filling or crown; while decay affecting the nerve is likely to involve root canal treatment. This provides an example of how a particular diagnosis can have varied presentations. Therefore, the relationships defined in the system are sensitive to variations. Accordingly, the suggestion engine 30 calculates and outputs entities that they tailored to the severity of the disease.

Furthermore, the suggestion engine 30 outputs entities tailored for each patient. This can be influenced by medical history; for example, if a patient is taking certain blood thinning medications or has a medical condition which predisposes them to heavy bleeding, an extraction might be contraindicated in practice and a specialist or hospital referral preferred. By contrast, for another patient with the exact same clinical presentation, but who is not taking blood-thinning medications, the extraction might be the highest-ranking suggestion. The suggestion engine 30 uses data in the medical history in the calculation of the relevance score. Furthermore, the weighting of relationships can be adjusted to indicate any specific rules. For example, for a medical condition that definitely cannot be treated in a dental practice then there will be a high relevance score defined for a referral. Alternatively, it may be hardcoded in the system to output a referral (for example as a ‘static entity’) in response to the input of the diagnosis. In both instances, the system can output an alert to the user that this treatment is required.

As a further example, medications prescribed by dentists, such as antibiotics and steroids, can interfere with a patient’s current medication. For instance, a patient may be taking warfarin, which can make them more susceptible to bleeding. The antibiotic metronidazole is commonly prescribed by dentists but can increase the effect of warfarin and potentially cause a harmful bleed. The relationship between metronidazole and warfarin is defined in the global knowledge database 10, and the suggestion engine will accordingly output a warning that the medication the dentist is about to prescribe can interact with the patient’s current medications as listed in their medical history.

The relationships between entities defined by the suggestion engine 30 are bidirectional. A typical workflow might follow a path of: clinical tests ® diagnosis ® treatments

However, the user is able to input data into the clinical notes in any order. For example, the user may input the diagnosis first. In this case, the suggestion engine 30 will tailor the outputted clinical tests and clinical test results accordingly, as well as the outputted treatments. This enables the user to input data in the order of their own preference. However, inputting data into the records in an unconventional sequence can result in incomplete clinical records. It can also indicate that the dentist has not followed the correct methodology to reach the diagnosis. This can present problems in the future if the patient commences litigation and the dentist has no record that they followed the correct legal procedures and performed the required clinical tests. Therefore, the system can output a warning when the dentist enters data in a non-standard sequence, for example by entering a diagnosis before performing relevant clinical tests. The dentist is therefore prompted to enter the omitted information to ensure that comprehensive notes have been recorded. Alternatively, the user can input further information providing a justification as to why they have chosen this workflow, for example to justify why the clinical test has not been performed.

Location-based suggestions

The system allows specificity of locations for each entity. When a user creates an entity, it is assigned to one or more locations. These will differ depending on the nature of the entity itself, for example caries can only be present on teeth and tooth surfaces. Therefore, these are the only locations presented to a user when they are creating caries folders. The system defines a hierarchical structure of locations, and so the system also allows intersection of locations. This means that entities assigned to a specific location are also recorded in the relevant broader locations in which they are encompassed and vice versa. For example, each arch of the mouth comprises a right and left quadrant, each quadrant is made up of teeth, and each tooth is formed of roots and tooth surfaces. If an entity is assigned the location of, for example, UR7, it will also be assigned to the broader location of the upper right quadrant. Although an entity assigned to a broader location, such as a quadrant, may not automatically be stored to more localised locations, the suggestion engine can factor in the entity during calculations relevant to the more specific location. For instance, if a patient has previously complained of a symptom in the upper right quadrant, this may be relevant to, for example, clinical tests and diagnoses on the UR7.

As a result of the use of location specific entities, the system is capable of determining and outputting not only entities such as symptoms, diagnosis etc., but also relevant locations. Below are provided examples which illustrate this. Patient complaint

Typically, suggestions are not output in the patient complaint section. This is because this section is usually completed first, and its input therefore informs the rest of the consultation. The input is dependent on the patient’s reason for visiting the dentist. The patient’s complaint is likely to be for a broader area, rather than a specific location. For example, a patient may complain of a pain in one area or quadrant but not know which tooth or teeth are causing the problem. As the system allows the input of more general locations such as the upper right, upper left, right side etc., the user can input the more general location first, and then narrow the location down during the patient consultation and examination.

Intraoral examination

The suggestion engine 30 is capable of determining (and then outputting) the most likely location of diseases. If there has been pain in the upper right quadrant then the system can determine and output which corresponding locations might be affected. In this case, the user assigns the 'upper right' location in the patient complaint section. Based on the relationships between entities, the system suggests a possible diagnosis is caries, which only affects teeth. The system can then indicate to the user that it is the teeth on the upper right that are most likely to have this diagnosis. This is an example of linking the location of the patient complaint to the possible locations that the diagnosis might be seen.

Clinical Tests

The suggestion engine 30 is capable of determining (and then outputting) where to carry out clinical tests. For example, a patient may be complaining of pain in the upper right quadrant of their mouth. The system also creates a folder for the intersecting location UR7 containing decay. Then, once the user inputs a test, the system can suggest where is the most likely location of that test. This is useful when there are multiple issues in the mouth. For example, one tooth may require a cold test and another area may require assessment of bleeding. In this instance, the suggestion engine 30 can output entities of high relevance and their relevant locations in turn.

Diagnosis

The suggestion engine 30 is capable of determining (and then outputting) location-specific diagnoses. For example, a patient may present with multiple decayed teeth and one in particular is causing pain. For this tooth the user might carry out tests and note down extra information on an x-ray. When the system assigns diagnoses for these teeth, out of all of the teeth with decay this particular tooth will have a high relevance score for an additional diagnosis that indicates that the nerve has died. The suggestion engine 30 will output a prompt to the user to also note this down within the folder. This is important because if treatment such as root canal treatment or extraction is to be carried out then the dentist must note down the diagnosis that led to this decision. If a dentist does not provide sufficient written record of the tests and examination which led to this diagnosis, their notes will not stand up to legal scrutiny.

Treatment

The suggestion engine 30 is capable of determining (and then outputting) which locations are most likely to require a particular treatment. For example, a patient may attend with a few small areas of decay and other areas in which the nerve has been affected. When planning treatments, the system can calculate which teeth are most likely to need extraction or root canal treatment and which are likely to need fillings as the most relevant treatment. The system may also output a warning if the dentist selects a course of action different from that calculated to have the highest relevance score. For example, if a filling has a high relevance score for a particular tooth and the dentist is extracting the tooth, then the system can output a warning to the dentist to provide further information. The dentist may be required to enter a justification as to why they are extracting the tooth. The dentist may then input, for example, that the patient has requested it. Without a clear record of this in the notes, this action would not be defensible.

Dental charts

At present, record-keeping systems, especially for dentists, consist predominantly of written records. If a user also wishes to keep visual records in the form of dental charts, these are separate and distinct to the text-based records. A user can place predefined text entries onto the chart manually. By contrast, the present invention provides a system in which the charts are integrated with the text-based dental records. As previously described, the clinical records are formed of a hybrid of plain text entry and defined selectable entities, all of which are assigned to one or more locations. The charts can be considered to provide a diagram of these locations. As the charts and written records are different representations of the same integrated data collection system, data can be input and accessed from both the written notes and the visual charts.

Figure 4 shows an example of the software interface, which allows a user to input notes on interactive dental charts. The user interface displays both a visual chart 400 and text notes 300 so the user is able to view both simultaneously. The user can first initialize a folder and input data, and then use the charts to assign a location to this data. Alternatively, the user can use the selection of the location to initialize a folder, which they will then populate with data. The system provides a selection of different views of charts, which are available to select. In the example of Figure 4, the user has chosen a representation of ‘Teeth’ using the area selector 410. The views comprise diagrammatic representations of anatomical locations.

Figures 5 to 8 illustrate further views available to the user. Figures 5a and 5b show the teeth, providing two optional views as whole teeth or with the option to select particular regions of each tooth, including the roots and different sections of each tooth respectively. The views are segmented into intersecting locations, including maxillary arch and mandibular arch, right and left 418, right posteriors, anterior and left posteriors 416, quadrants 414, sextants 412, and individual teeth 410. The dashed lines 425 of Figures 5a and 5b indicate the boundaries of selectable locations. The teeth themselves can optionally be further segmented, as shown in Figure 5b, into the surfaces of the tooth 422, including distal, facial, labial, buccal, incisal, lingual, mesial, occlusal and proximal surfaces. The segments of the root 424 can also be presented as separate and selectable regions. These locations can be considered to be connected as selecting the upper right seventh tooth will also input data to the upper right posterior sextant, the upper right quadrant, the right posteriors and the ‘right’ of the mouth. As such, these locations can be considered to form a hierarchical structure with ‘cascading’ levels, as the upper right seventh tooth lies within the upper right posterior segment, which lies within the right posteriors etc. Providing connected and ‘cascading’ locations on the charts means that a user can initialize notes with a broad region and hone-in on the relevant affected area during the consultation. Additionally, it is beneficial that the notes in the broader region automatically record issues in more specific locations within that region as they may affect future conditions and treatment.

The user can also choose alternative anatomical views of the dental chart 400. Figures 6a and 6b illustrate the intraoral regions provided as views with labelled regions and broken into further sections, respectively. The selectable locations include ‘left’ and ‘right’, lip (upper and lower), labial (upper and lower), vestibule (upper and lower), gingivae (upper and lower), palate, buccal mucosa (left and right), fauces, tongue (upper and lower), and floor of mouth. Figures 7a and 7b show facial symmetry with labelled views and then further sectioned respectively. The selectable locations include the forehead, eyelid, nose, upper lip, check, chin, lower jaw line jaw angle, check, pre auricular, and ear. The user can also select ‘right’ and ‘left’. Figures 8a and 8b show views of the lymph nodes labelled and further sectioned respectively. Selectable locations include carotid, occipital, muscular, supraclavicular, and clavicle. Returning to the user interface as illustrated in Figure 4, the user can quickly and easily alternate between the views of the chart 400 through the area selector 410. In each of these views the anatomy is presented as selectable regions. The user can click on the relevant region of the chart, for example, UR7 420, and a folder is initialized for this particular tooth. The input is also recorded to relevant intersecting locations, for example entities assigned the location of ‘UR7’ will also be recorded to ‘upper right quadrant’. The user can then work through the relevant outputted subsections 310. Once they have inputted all the relevant data, they can select ‘Update notes’ 360 to record the entries to the patient’s file.

It is possible to select more than one region at a time, and the corresponding data input by the dentist will then be saved to the folders for each of these regions. In this case, each of the selected regions will be highlighted and a new folder will be created for each region or tooth. These folders can be presented below one another and next to the chart so that the user is able to see all the information on one screen. Additionally, all the sections of the examination will be allocated to the same location, for example patient complaint, clinical test, diagnoses, and treatment plan. Alternatively, multi-location folders can be created by selecting multiple locations on the charts.

Over time, records will be efficiently created and built up for each location. The user can search for a particular region or tooth and will be presented with a comprehensive medical history for that region. Using the current systems, the dentist would need to search in each individual folder, and perhaps the records for each visit to build a complete record relevant to that tooth. This is, of course, very time-consuming and can be inaccurate as information can be easily missed. The system of the current invention, by contrast, provides clean input of information in a standardized form which is recorded centrally and tagged to all the relevant locations. Therefore, when a user opens the patient’s records, they can choose a region, and gain access to all the relevant clinical history. They do not need to search for further information saved in different locations. The choice of region can be inputted either by text entry or by selecting the relevant area or areas in the charts. The records can be presented as folders of written text. Alternatively or additionally, when a user clicks on or hovers over a particular tooth or region, the dental history of that region is presented in a text box within the chart 438, 440. An example of such a user interface is illustrated in Figure 9. The data shown on the chart is selective in the sense that it only shows the most relevant information, usually in an abbreviated form.

The data may preferably be presented in a chronological order or in an order according to relevance. For example, it may be preferable to implement a system which ranks the most relevant entities in the clinical history and presents them according to this ranking. The system calculates a relevance score, by which to rank the entities using the relationships defined in the knowledge databases. This ranking may be defined according to general clinical importance, or it may be programmed to evolve depending on the inputs of the current consultation. The system can output items of dental history in broader or more specific overlapping locations. For example, if a patient visits the dentist complaining of pain in a particular tooth, prior trauma to the broader region in which that tooth is located will be shown. This is also shown preferentially to more recent items of lower clinical relevance, for example a recent cleaning of the particular tooth.

The system can output suggestions based on the relevant locations. This includes suggested entities to record in the notes based on the locations. This is refined further by selection of secondary locations, for example, if a user selects the root of a tooth the outputted entities will be relevant to the root. The suggestion engine 30 can also output suggested locations based on the previous inputs to the written records. The locations can be refined during patient examination. For example, a patient may complain of pain in the upper left quadrant, and the dentist can then refine the problem to a particular tooth during intraoral examination.

Additionally, the system can output details from the selected region of the charts directly to the written notes. Figure 10 illustrates an example of this, in which the user is recording a note relating to the upper left 4 (UL4). The user inputs caries, and then selects the area of the UL4 tooth in which the caries is located. This input is sent to the written notes as text inputs ‘BUCCAL’ and ‘DISTAL’. This also illustrates that the system outputs the most relevant chart. The chart shows the teeth with all the surfaces available to be selected, but not the roots as they are not relevant for the diagnosis of caries. This is different to the default options of the general imagery of the whole teeth as shown in Figure 5a and the representation of teeth with all areas selectable as shown in Figure 5b.

The selection of regions of the charts may be provided via a ‘click and drag’ action. This may comprise ‘activating’ or ‘initiating’ a selection process or ‘selection state’ by selecting a first region. The user can then select further regions simply by moving the cursor over the representation of those further regions on the charts. The selected regions can then all be recorded to the text notes. This enables a user to quicky select several regions in one movement, instead of being required to select each region consecutively and individually. The selection may be instigated by a first ‘mouse click’ to select the first region, and the recording of the regions to the notes by a further ‘mouse click’. The selection of the further regions between these two mouse clicks can be achieved by simply hovering the cursor over the relevant region or regions. Alternatively, the user may select the first region and hold the mouse button while moving the cursor over the further regions, thereby selecting them, and then the recording is effected upon ‘release’ of the mouse button. Other manners of implementing the ‘selection’ and ‘recording’ of the ‘click and drag’ process may also be used. This may include protocols related to ‘mouse clicks’, or implementation on other hardware systems, such as touch screens.

The regions of the charts available for selection may be determined by the one or more regions which have already been selected. For example, once a user selects a region, only regions in a same ‘category’ may be available for selection. For example, the user may select the buccal surface of UL4. When they then move the cursor to an adjacent tooth, only the buccal surfaces will be available for selection. If they move the cursor over, for example, the buccal surface of UL5, this will be selected. However, if they move the cursor over the distal surface of UL5, this will not be available for selection and so will not be selected. This can allow the user to select a group of buccal surfaces quickly without the requirement to move the mouse with precision. Each region may form part of more than one category. For example, the buccal surface of UL4 is defined as a surface of UL4 in addition to being defined as a buccal surface. As such, when the buccal surface of UL4 is selected, not only are the adjacent buccal surfaces available for selection, but so are the other surfaces of the same tooth. Therefore, if a user moves the cursor over the distal surface of UL4, this will also be selected. By grouping the regions into categories, the system can predict the regions relevant to the user at a particular time. By only making available for selection those regions which are likely to be relevant, the user is able to select relevant regions quickly by simply moving the cursor over them.

In a similar manner to the example described above, if a user first selects a particular tooth, then only those regions which are defined as teeth may be available for selection. As a further example, if a user selects a quadrant, only the further quadrants may be available for selection. The different types of categories may typically include: tooth surface, including mesial, distal, buccal, palatial and lingual; mouth quadrant, including upper right (UR), upper left (UL), lower right (LR), and lower left (LL); individual teeth; and sextants, including UR Posterior, Upper Anterior, UL Posterior, LR Posterior, Lower Anterior, LL Posterior. Other categories may be included, and/or more complex relationships between regions may be defined to determine which regions may be selected in dependence on the selection of a first one or more regions.

The categories may be refined in dependence on the combination of regions selected. For example, if the buccal surface of the UL4 is selected, the other surfaces of the UL4 may also then be available. However, if the user then goes on to select the buccal surface of the UL5 and UL6, the other surfaces of the UL4 may no longer be available. As another possibility, additional regions may become available in dependence on the selection of a combination of regions. For example, if the UR6 tooth is selected, only other teeth may be available for selection. However, if the user then goes on to select further individual teeth in the UR quadrant, the region of ‘UR quadrant’ may then become available for selection.

In some instances, the dentist may use dental photographic equipment as part of the consultation. For example, a camera may be attached to the dentist’s loupes, which then send photographs and/or video to the user’s computer. These recordings can be saved in the patient’s notes in connection with the input flow described above. In some embodiments, the software may implement photo recognition protocols trained on dental data and imagery. The software may then automatically update the patient’s notes. For example, the image recognition software corresponds and links the teeth in the image to layout of the dental chart. It then automatically inputs information to the appropriate folder (such as the UR7) in the patient records, for example regarding a missing tooth or a filing.

Alternatives and modifications

It will be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.

For example, the output entities may be used to configure a further device. In this regard, the present disclosure extends to a device, such as a monitoring device and/or a surgical device, that is arranged to receive an output entity and/or a signal that depends upon an output entity. The further device may be arranged to operate in dependence on the output entity. For example, where a patient has indicated that they are taking blood-thinning medication, the output device may be configured to check the patient’s blood pressure at regular intervals (or to remind the patient to check their blood pressure). The device may, for example, be a smartphone or a smartwatch. The device may also, for example, be a surgical device, such as a dental drill. A suitable configuration of such a device may depend on the entities determined to be relevant for a patient (e.g. based on a characteristic of a patient or of the problem of a patient). The device may, for example, be arranged to use a drilling pressure that is suitable for a specific situation defined by the output entities.

The configuring of the device may be based on a user configuring the device manually based on the output entities. Equally, the device may comprise a communication interface (e.g. a wired interface or a local area network interface) so that the device is able to receive instructions from the system. This enables the provision of a device that is automatically configured.

The device may comprise a computer device with a user interface, e.g. another device on which the system is implemented. With such an embodiment, the device may be arranged to receive the output entities and/or the user’s profile so as to identify a user knowledge based. Therefore, the device is useable to also implement the disclosures herein. This enables, for example, multiple dentists to interact with a user using separate devices while providing a seamless experience.

Furthermore, there is disclosed herein a method of obtaining a measurement from a patient in dependence on the output entities. In this regard, the system may output an entity that prompts a dentist to obtain a measurement from a patient, such as a blood pressure measurement. The system may further be arranged to receive this measurement and/or to determine a further entity based on the measurement.

While the examples provided herein have largely related to dentists and dentistry, it will be appreciated that the disclosures herein are useable for other purposes.

Each feature disclosed in the description, and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination.

Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.