Method for identifying a care gap for a patient

Abstract

A method of identifying a care gap for a patient comprising: inputting identification data relating to a patient into a clinical decision engine; retrieving, from an FHIR repository, a supplementary d

Description

The present invention relates to a method for identifying a care gap for a patient and particularly for automatically suggesting and / or ordering resultant clinical actions thereafter. The invention further relates to a system suitable for implementing such a method. With the advent of value-based care, healthcare providers, including hospitals and physicians, are transitioning from paper-based systems to Electronic Medical Records (EMR) to enhance patient care and meet regulatory requirements. However, this clinical data resides in many forms, such as labs, progress notes, discharge summaries, medication records, allergy tables, or other data sources, with significant differences between different providers or EMR vendors. This variability is the source of significant inefficiencies in the way data is made available for different applications, such as quality reporting or care management. This variability necessitates providers to invest additional resources in developing provider-specific data interfaces, resulting in increased costs and prolonged time-to-value for healthcare solutions. Moreover, the lack of standardized data integration leads to incomplete and potentially inaccurate information, impeding effective decision-making and compromising patient care outcomes. Due to the above challenges, there is an increase in both true cost of ownership and time to value for the solutions present at a hospital or physician practice. Moreover, providers with lower budgets may be deterred from purchasing various solutions to relate one type of data to another. The patients may ultimately be affected too by a lack of bridging between diverse data formats. Without sufficient information from the various data sources, a gap in care for patient or patients may not be identified in an automated process to back-stop a medical professional. The other problem is providing a programmable mechanism to identify care gap based on the patient data. In the USA, CQM (Clinical Quality Measure) which can be used to assess the degree to which a provider competently and safely delivers clinical services that are appropriate for the patient in an optimal timeframe. It helps to measure performance of the provider and also way to provide support for making clinical decisions. In UK it is provided a clinical performance indicator (https: / / digital.nhs.uk / data-and-information / clinical-indicators). It is a very good repository of documentation created by healthcare professional and revised over reported data to CMS. To create clinical decision support rules and alerts it is good benchmark, but no implementation is provided to convert it to programmable library which can run these rules over data coming from disparate system and disparate formats. Not only is data format variability an issue but also if the source data is unstructured or semi-structured data it will not be not mapped to any medical terminology: different value sets are used; data is not time-annotated; many of the clinical decision support alerts are highly dependent on the time frame (for instance, if patient has been ordered an investigation in last 6 months). Another big issue is the lack of a timely manner in which alerts are generated so that provider can take action in appropriate time. Often information is in silos and not available in near real-time for compilation and assessment. It is an object of the present invention to reduce or substantially obviate the aforementioned problems. According to a first aspect of the invention, there is provided a method for identifying a care gap for a patient, the method comprising the steps of: inputting identification data relating to a patient into a clinical decision engine; retrieving, from an FHIR repository, a supplementary data file relating to the patient based on the identification data, the supplementary data file comprising known patient clinical information; retrieving a clinical ruleset from a database comprising a plurality of clinical rules relating to patient care; applying a subset of the plurality of clinical rules to the supplementary data file according to the known patient clinical information to determine a care gap; and displaying information about the care gap on a user interface of a user device. The present invention provides a mechanism of simply identifying a care gap for a patient based on patient clinical information from all available sources. The present invention utilises information taken from a normalised repository, that is, the FHIR repository, which allows for rapid identification of a care gap based on clinical rules to be made. FHIR transformation of prior records enables quick application of the applicable subset of clinical rules to be made at the point of care provision, for instance, when a patient visits a general practitioner (GP). Speed of processing is also improved by selecting only applicable clinical rules relating to the patient based on retrieved data, such as, existing health conditions, age, sex, weight, family history, and so on. Optionally, the supplementary data file may comprise normalised FHIR data from existing data records. Patient data is currently recorded in many different formats across many different patient care providers. The FHIR integration of the present invention allows for rapid collation of that information so as to subsequently inform both the application of the relevant subset of clinical rules, and also for the identification of the care gap. Preferably, the existing data records may comprise any or all of: unnormalized FHIR data; HL7 data; CDA data; and a combination thereof. Most common healthcare data record systems can be transformed into FHIR data using simple transformation mapping. The supplementary data file may comprise FHIR data from processed unstructured data records. One of the main difficulties with extracting patient data is that some of it is in unstructured form, for example, being in handwritten or freeform typed medical documents. Transformation of such data via the FHIR processing allows for this type of data to be factored into the clinical decision-making process as fully or partially automated by the clinical decision engine. Preferably, the processed unstructured data records may be processed using natural language processing and medical entity identification. One advantageous means of extracting clinical data from unstructured data is achieved by use of natural language processing, which can rapidly identify textual information contained within the unstructured data, and then categorised using medical entity identification, for instance, compatible with the UMLS system. Optionally, the clinical ruleset may comprise at least one pre-existing clinical rule. In most cases, clinical rules will be applied by a central medical governing organisation, such as the National Health Service in the United Kingdom. As such, the clinical ruleset will likely have a primary database of care gaps to be identified. The clinical ruleset may comprise at least one bespoke clinical rule. What is also desirable is if specific care providers are able to identify desirable care gaps to be addressed, perhaps based on local population needs. The present invention provides a UI wizard tool for setting bespoke clinical rules. The at least one bespoke clinical rule may be associated with a value set of synonymical codings for medical entities. The use of value sets where counterpart codings from different vocabularies are provided allows for improved identification of medical entities which are synonymous, significantly reducing false identification of entities during assessment of clinical rules. Optionally, the clinical ruleset may be transformed into a machine-readable format using clinical query language. Clinical query language allows for rapid application of clinical rules as opposed to use of SQL queries. The method may further comprise a step f), subsequent to step e), of automatically identifying a clinical action to address the care gap. Since care gaps can be automatically identified rapidly within the system, it will be apparent that an arrangement can be made in which the means of closing the care gap is also automatically identified, rather than relying on the care provider to reach the relevant conclusion. Furthermore, the method may further comprise a step g), subsequent to step e), of automatically triggering a clinical action to be performed to address the care gap. The system may be adapted to automatically resolve the care gaps which have been identified, which is only achievable when care gaps are identified promptly. According to a second aspect of the invention there is provided a system for identifying a care gap for a patient, the system comprising: a clinical decision engine configured to receive identification data relating to a patient; a FHIR repository having supplementary data file relating to the patient, the supplementary data file comprising known patient clinical information; a database having a clinical ruleset comprising a plurality of clinical rules relating to patient care; wherein the clinical decision engine is configured to applying a subset of the plurality of clinical rules to the supplementary data file according to the known patient clinical information to determine a care gap for a patient; and a user device having a user interface configured to display information about a care gap for a patient According to a third aspect of the invention method for normalising unstructured patient information data, the method comprising the steps of: receiving unstructured patient information data; identifying at least one medical entity from the unstructured patient information data using a natural language processor having named entity recognition capability; for the or each identified medical entity, querying a medical controlled vocabulary and retrieving at least one primary medical descriptor; using a FHIR mapping engine, transforming the at least one primary medical descriptor into normalised FHIR data to generate a supplementary data file comprising known patient clinical information. The FHIR mapping of the present invention allows for the alignment of unnormalised data sets to be brought together, which allows for the care gap identification process to be achieved within the present invention. The method may further comprise the step prior to step d) of further querying the medical controlled vocabulary and retrieving at least one expanded hierarchical medical descriptor and retrieving at least one category descriptor. Enrichment of the data allows for improved cross-referencing of medical entity information which improves FHIR mapping. Optionally, the medical controlled vocabulary may be the Unified Medical Language System (UMLS). The UMLS provides a pre-existing means of concept mapping between known medical terminologies in a structured manner. As such, it represents a suitable system to build a schema for searching around. Preferably, the at least one primary medical descriptor may comprise at least one of a UMLS code, a UMLS textual descriptor, and a concept unique identifier (CUI) for the or each identified medical entity. The UMLS concept mapping provides simple coding to easily identify synonymous or related terms within the controlled medical vocabulary, vastly improving the quality of data retrieval and normalisation. Preferably, the natural language processor may be Apache cTakes API. A natural language processor having named entity recognition provides a large degree of the functionality necessary to implement the present invention, and the Apache cTakes API provides this functionality. However, a separate natural language processor and named entity recognition engine could be provided. For a better understanding of the present invention, and to show more clearly how it may be carried into effect, reference will now be made by way of example only to the accompanying drawings, in which: Figure 1 shows a flow diagram of a method for normalising unstructured patient information data in accordance with the third aspect of the invention; Figure 2 shows a pictorial representation of the data flow of the method shown in Figure 1; Figure 3 shows a data diagram of the hierarchical structure of UMLS concepts and atoms mapped; Figure 4 shows a flow diagram of a method for identifying a care gap for a patient in accordance with the first aspect of the invention; Figure 5 shows a pictorial representation of a wizard-based authoring user interface for rule sets in a first condition; and Figure 6 shows a pictorial representation of the wizard-based authoring user interface of Figure 5 in a second condition. Referring firstly to Figure 1, there is indicated a method, M100, for normalising unstructured patient information data 10 and / or existing unnormalized data records 12. The unstructured patient information data 10 may include data sources such as: Lab reports, typically as PDF documents; voice call recordings; and medical notes. Said unstructured patient information data 10 will need converting into text format, where applicable, for instance, by the use of speech-to-text software, and optical character recognition. The existing unnormalized data records 12 may comprise any or all of: unnormalized FHIR data; HL7 data; CDA data; and a combination thereof. A natural language processor 14 is used to analyse the unstructured patient information data 10. In the present implementation of the invention, the Apache cTakes API (https: / / ctakes.apache.org / ) is used as the natural language processor 14, though other natural language processing tools are available. The unstructured patient information data 10 is analysed using named entity recognition to identify medical entities 16 therein, and classify them. Apache cTakes API performs both natural language processing and named entity recognition, but it will be apparent that different processors could be used to perform the discrete steps here, for instance, Hugging Face (https: / / huqqingface.co / d4data / biomedical-ner-all). Figure 2 shows a selection of potential medical entities 16 that may be present in the unstructured patient information data 10. For the or each identified medical entity 16, a medical controlled vocabulary 18 is queried, and at least one primary medical descriptor retrieved. In the present embodiment, the medical controlled vocabulary 18 is the Unified Medical Language System (UMLS). Once the data has been enriched with UMLS information, the data can be transformed. This is performed using a FHIR mapping engine 20, which outputs FHIR data. Examples of mapping of clinical notes having been processed with natural language processing and named entity recognition, UMLS enrichment, and then FHIR mapping is as follows: Medical Mention -> MedicationOrder, Medicationstatement Disease Disorder Mention -> Condition Procedure Mention -> Procedure, Encounter Sign Symptom Mention -> Observation Date / Time Mention -> Encounter Family History Mention -> FamilyMemberHistory Social History -> Observation Diagnostic Reports -> DiagnosticReport FHIR is the Fast Healthcare Interoperability Resources standard set of rules and specifications for exchanging electronic health care data. It is designed to be flexible and adaptable, so that it can be used in a wide range of settings and with different health care information systems. For the existing unnormalized patient data 12, this is processed from various sources and in various data formats so as to form a unified data repository. This may be performed for instance by CCDA to FHIR mapping, for instance, using mapping guidelines provided at https: / / build.ftiir.org / iq / HL7 / ccda-on-fhir / toc.html. A library was created as part of the present invention to map CCDA documents to FHIR resources. A similar process was followed for HL7 data, in which HL7 messages to FHIR resource mapping was performed. Mapping guidelines can again be found at https: / / b u i I d. fh i r. o rq / i q / H L7 / ccd a-on-f h i r / toc. htm I. The at least one primary medical descriptor is transformed into normalised FHIR data to generate a supplementary data file comprising known patient clinical information, transferred to an FHIR server 22 having an FHIR repository 24 thereon. UMLS data is structured into a concept map. A concept is a fundamental unit of meaning in a collection of multiple vocabularies, code sets, and standards within the UMLS, referred to as a Metathesaurus. A concept represents a single meaning and contains all atoms from any source that express that meaning in any way, whether formal or casual, verbose or abbreviated. All of the atoms within a concept are synonymous. Each concept is assigned at least one semantic type. Every concept is assigned a Concept Unique Identifier, or CUI, which uniquely identifies that single meaning. An atom is the smallest unit of naming in a source, that is, a specific string with specific code values and identifiers from a specific source. As such, they can be thought of as representing a single meaning with a source Atoms are the units of terminology that come from sources and form the building blocks of the concepts in the Metathesaurus. Figure 3 shows the general structure of the concept map 26 within the entity database 16. The medical entities 16 can then be queried using the medical controlled vocabulary. For each medical entity 16 recognised by the natural language processor 14, additional information is retrieved from the medical controlled vocabulary, in the form of at least one primary medical descriptor 28. The at least one primary medical descriptor 28 here comprises detailed descriptions and associated medical codes, typically at least one of a UMLS code and a concept unique identifier (CUI), and taken from sources such as the International Classification of Diseases (ICD-10), Current Procedural Terminology (CPT) coding, RxNorm normalised drug nomenclature, National Drug Code (NDC), and Logical Observation Identifiers Names and Codes (LOINC). This yields an enriched dataset, and the at least one primary medical descriptor 28 is stored in the entity database 30. In this embodiment, this becomes a UMLS-supplemented database. In addition to the above, for each of the medical entities 16, a further query of the medical controlled vocabulary is made, to retrieve at least one category descriptor 32, known as a parent concept within UMLS parlance, and at least one hierarchical medical descriptor 34 associated therewith. This methodology provides a means for combining clinical entity recognition with medical coding and UMLS, or similar medical controlled vocabulary, concept mapping, which provides greater depth of information to allow for in-depth searching. The FHIR repository 24 forms the basis of the primary use case of the present invention, as is depicted in Figure 4, that is, to identify a care cap for a patient. A clinical provider 36 inputs identification data relating to a patient into a clinical decision engine 38. A supplementary data file is retrieved, from the FHIR repository 24, relating to the patient based on the identification data. The supplementary data file comprises known patient clinical information. A clinical ruleset is then retrieved from a database comprising a plurality of clinical rules relating to patient care. A subset of the plurality of clinical rules is applied by the clinical decision engine 38 to the supplementary data file according to the known patient clinical information to determine a care gap. Information about the care gap is then displayed on a user interface of a user device to the clinical provider 36. Clinical rules may be retrieved from a central repository, for example, a database of clinical rules from an overarching regulatory body 40. However, the present invention also provides a user interface, in the form of a UI wizard 40, to allow a user to author bespoke clinical rules. For instance, the user can add initial population criteria, for instance, age group, gender, ethnicity, visit type, specific diagnosed condition, etc. This may also allow criteria to be added for variables ‘denominator’ and ‘numerator’, within the parlance of the UI wizard. The denominator here refers to conditions requiring actionables based on the patient information, which may be clinical conditions, or may be criteria to be met. The numerator here refers to actionables that the provider is obliged to deliver as care to reduce the care gap. For example, numerator actionables may include ordering a diagnostic report, referral to a specialist physician, physical examination, etc. The clinical rulesets are converted into CQL (clinical query language https: / / ecqi.healthit.gov / cql). This provides a machine-readable means of storing query criteria. A database schema has been developed to accommodate the steps performed by a user when creating clinical rules so that they persist in the database 44, whilst also permitting editing or other modification of the rule. Additionally, the clinical rule can be associated with patient criteria which allows for selection of subsets of clinical rules according to said criteria for specific patients. Examples of patient criteria include demographic criteria such as gender, age, and ethnicity. The purpose of this is to provide the filtering capability to reduce the number of clinical rules evaluated by the clinical decision engine 38. The clinical decision engine 38 can then perform evaluation of the subset of clinical rules. This can be triggered by user input, or could be configured automatically, for instance, by CDS hook (https: / / cds-hooks.org / ). When an event is triggered, patient context, such as a patient identifier, and provider context, such as provider or practitioner identifiers, are provided, and these are used to pass context to the clinical ruleset via the clinical decision engine 38. Based on patient characteristics, the subset of clinical rules is applied, and then evaluated each by using a Sevaluate-measure operation on the FHIR server. On evaluation, this provides three outputs: IPP (Initial Population) = true / false DENOM (Denominator) = true / false NUMER (Numerator) = true / false The subset of clinical rules is determined for IPP=true. Where IPP=true but DENOM=false, the user is provided with a list of possible actionables, and the provider can see missing conditions of the denominator. For clinical rules where IPP=true and DENOM=true, the user is provided with actionables and the provide can see the actionables to be performed to eliminate or reduce the care gap as part of the numerator. SQL (Structured Query Language) queries was originally evaluated to determine whether a patient falls under denominator population criteria. However, it was found that this was inadequate at supporting complex measurement criteria and nested AND / OR logic. Thus, the present system utilises CQL as a more robust way to translate measurement criteria in a machine-readable format. The FHIR server 22 is thus constructed so as to support CQL evaluation, in conjunction with open-source libraries. However, this was only achievable following the conversion of input data into the FHIR format, which is the reason for the FHIR mapping engine 20 being central to the present invention. Filtering of the queries to be performed was required to avoid straining of system resources so that real-time care gap evaluation can be performed. Additionally, when evaluating clinical rules with specific terminology codes it was found that high numbers of false negatives arose and too many actionables were lost as a result. As such, the system has been configured to prefer false positives and thus minimize false negatives. It is possible to do this if more matching codes are added at either the patient level or at clinical rule definition. To attach extra codes to patient chart without clinician signoff would not be the correct approach, so it was decided to use a value set approach in clinical rule definition. Additional codes were added to patient specific value set and attached to the clinical rule to be evaluated on temporary basis. This change has allowed us to reduce false negatives by substantial with improved F Score to 98%. The attachment of extra codes can be performed at the level of clinical rule definition. In other words, the lexicon for filterable terms in the database is provided so as to be premapped across different medical controlled vocabularies. This may be provided as the value set for each medical entity, for different medical controlled vocabularies, such as SNOMED, ICD10, and ICD9, by way of example only. Each value set thus contains synonymical codings, which can be queries using the standardised medical controlled vocabulary querying in the present invention, here, the UMLS query. The value sets are attached to the clinical rule sets to enable rapid identification of the different possible codes in the clinical decision engine 38, since unstructured data may have drawn in codes from different sources with different vocabularies. The identification of care gaps can therefore be automated using the clinical decision engine 38. Furthermore, it may be possible for the system to automatically identify suggested options for closing the care gap for the patient. Further still, it may also be possible for the system to automatically order an actionable, such as a test or treatment, to close the care gap, at the point of identification, rather than requiring the provider to action this directly. The authoring process using the UI wizard 40 is indicated in more detail in Figures 5 and 6. The UI wizard 40 has a filter criteria region 46, in which possible filter criteria 48 are selectable in order to form rules. Displayed criteria in Figure 5 include: Boolean operators, identified as ‘Criteria’; interaction context or setting, identified as ‘Context’; patient filters such as age, gender, and race, identified as ‘Filter’; numerical relationship symbols, identified as ‘Operator’; numerical values, which may be input in freeform rather than selected from a list, identified as ‘Value’; and units for the value, identified as ‘Unit’. To ensure that all rules are not applied to all patients, the UI wizard 40 has a cohort selection region 50, in which population selection rules are identified for the actionables which are desirable. This provides filtering of the care gap rules which are to be applied to a patient in any given scenario. To add a rule to the cohort selection region 50, the user presses the add rule button 52, selects the filter criteria within the filter criteria region 46, and presses the confirmation button 54. This populates rules 56 within the cohort selection region 50. It will be apparent that there is a vast number of potential filter criteria which could be applied to form rules, which may be prohibitive to display in the filter criteria region 46. As such, the filter criteria region 46 is designed to have dynamic population of potential filter criteria, in that, once certain selections have been made, only viable or logical subsequent options are presented to the user. For instance, where the user selects ‘Patient’ as the context, the next filter criteria displayed is the ‘Filter’ pane, in which patient-specific filter criteria such as age, gender, and race are displayed. That accelerates the rule generation process by avoiding incorrect rule sequences. The UI wizard 40 also has a numerator selection region 56, which is where actionables are input which would be anticipated being provided based on the cohort information. This can be seen in Figure 6 in detail. For instance, where a toddler is diagnosed with pharyngitis or tonsilitis, the expected actions for the physician would be to conduct a Group A Streptococcal diagnostic text and refer the patient to cardiac outpatient rehabilitation. These actionables can be input into the numerator selection region 56 in much the same way as for the cohort selection region 50. To add an actionable to the numerator selection region 56, the user presses the add actionable button 60, selects the filter criteria within the filter criteria region 46, and presses the confirmation button 54. This populates actionables 62 within the numerator selection region 56. The clinical decision engine 38 can thus propose which actionables must be performed to close the care gap automatically. A care gap is thus identified if a rule in the ruleset triggers, and the actionables performed to-date do not match with those identified in the numerator selection region 56. It is therefore possible to provide a method and system which allows for the identification of a care gap in real-time for a patient, so that actionables can be put into place. This is achievable only by normalization of patient data, ideally from both unstructured data sources and existing unnormalized data sources, in addition to filtering on clinical rules to avoid overuse of system resources which would otherwise prevent the output of the care gap information in real-time. The words ‘comprises / comprising’ and the words ‘having / including’ when used herein with reference to the present invention are used to specify the presence of stated features, integers, steps, or components, but do not preclude the presence or addition of one or more other features, integers, steps, components, or groups thereof. It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment, may also be provided separately or in 5 any suitable sub-combination. The embodiments described above are provided by way of example only, and various changes and modifications will be apparent to persons skilled in the art without departing from the scope of the present invention as defined by the appended claims.

Claims

1. A method for identifying a care gap for a patient, the method comprising the steps of:a) inputting identification data relating to a patient into a clinical decision engine;b) retrieving, from an FHIR repository, a supplementary data file relating to the patient based on the identification data, the supplementary data file comprising known patient clinical information;c) retrieving a clinical ruleset from a database comprising a plurality of clinical rules relating to patient care;d) applying a subset of the plurality of clinical rules to the supplementary data file according to the known patient clinical information to determine a care gap; ande) displaying information about the care gap on a user interface of a user device.

2. A method as claimed in claim 1, wherein the supplementary data file comprises normalised FHIR data from existing data records.

3. A method as claimed in claim 2, wherein the existing data records comprise any or all of: unnormalized FHIR data; HL7 data; CDA data; and a combination thereof.

4. A method as claimed in claim 1 or claim 2, wherein the supplementary data file comprises FHIR data from processed unstructured data records.

5. A method as claimed in claim 4, wherein the processed unstructured data records are processed using natural language processing and medical entity identification.

6. A method as claimed in any one of the preceding claims, wherein the clinical ruleset comprises at least one pre-existing clinical rule.

7. A method as claimed in any one of the preceding claims, wherein the clinical ruleset comprises at least one bespoke clinical rule.

8. A method as claimed in claim 6 or claim 7, wherein the clinical ruleset is transformed into a machine-readable format using clinical query language.

9. A method as claimed in claim 7 or claim 8, wherein the at least one bespoke clinical rule is associated with a value set of synonymical codings for medical entities.

10. A method as claimed in any one of the preceding claims, further comprising a step f), subsequent to step e), of automatically identifying a clinical action to address the care gap.

11. A method as claimed in any one of the preceding claims, further comprising a step g), subsequent to step e), of automatically triggering a clinical action to be performed to address the care gap.

12. A system for identifying a care gap for a patient, the system comprising:a clinical decision engine configured to receive identification data relating to a patient;a FHIR repository having supplementary data file relating to the patient, the supplementary data file comprising known patient clinical information;a database having a clinical ruleset comprising a plurality of clinical rules relating to patient care;wherein the clinical decision engine is configured to applying a subset of the plurality of clinical rules to the supplementary data file according to the known patient clinical information to determine a care gap for a patient; anda user device having a user interface configured to display information about a care gap for a patient.

13. A method for normalising unstructured patient information data, the method comprising the steps of:a) receiving unstructured patient information data;b) identifying at least one medical entity from the unstructured patient information data using a natural language processor having named entity recognition capability;c) for the or each identified medical entity, querying a medical controlled vocabulary and retrieving at least one primary medical descriptor;d) using a FHIR mapping engine, transforming the at least one primary medical descriptor into normalised FHIR data to generate a supplementary data file comprising known patient clinical information.

14. A method as claimed in claim 13, further comprising the step prior to step d) of further querying the medical controlled vocabulary and retrieving at least one expanded hierarchical medical descriptor and retrieving at least one category descriptor.

15. A method as claimed in claim 13 or claim 14, wherein the medical controlled vocabulary is the Unified Medical Language System (UMLS).

16. A method as claimed in claim 15, wherein the at least one primary medical descriptor comprises at least one of a UMLS code, a UMLS textual descriptor, and a concept unique identifier (CUI) for the or each identified medical entity.

17. A method as claimed in any one of claims 13 to 16, wherein the natural language processor is Apache cTakes API.

Images