Code point resolution using natural language processing and metathesaurus

A system and related method exchange medical information with a medical management system. The method comprises receiving, using a processor of a code point resolver, from the medical management system, medical text via a network interface. A code point is a single standardized medical terminology code (SMTC) that corresponds to a medical concept contained within the medical text. The method further applies rule-based logic to process the medical text to form a localized mapping of a text portion of the medical text to a plurality of candidate SMTCs (CSMTCs) that are related to at least one metathesaurus concept entity (MCE) in a metathesaurus, and to determines the code point from the CSMTCs. The method transmits, via the network interface, to the medical management system, the code point.

BACKGROUND

Disclosed herein is a system and related method for a code point resolution using natural language processing and a metathesaurus. In the medical domain, applications may use standardized medical terminology codes (SMTCs) to exchange clinical information. A common goal when processing unstructured patient notes is to produce SMTCs corresponding to the medical text. A common approach to extracting SMTCs from natural language is to use a biomedical metathesaurus that contains metathesaurus concept entities (MCEs), such as the Unified Medical Language System (UMLS) Metathesaurus (UMLSM). Concepts or meanings represented by MCEs that are found within the unstructured medical text may be detected using the vocabularies defined by the metathesaurus. The detected concepts may then be mapped to SMTCs using mappings in the metathesaurus and relevant MCEs.

SUMMARY

A method is provided for exchanging medical information with a medical management system. The method comprises receiving, using a processor of a code point resolver, from the medical management system, medical text via a network interface. A code point is a single standardized medical terminology code (SMTC) that corresponds to a medical concept contained within the medical text. The method further applies rule-based logic to process the medical text to form a localized mapping of a text portion of the medical text to a plurality of candidate SMTCs (CSMTCs) that are related to at least one metathesaurus concept entity (MCE) in a metathesaurus, and to determine the code point from the CSMTCs. The method transmits, via the network interface, to the medical management system, the code point.

A code point resolver is provided, comprising a memory, and a processor. The code point resolver is configured to receive, using a processor of a code point resolver, from the medical management system, medical text via a network interface. A code point is a single standardized medical terminology code (SMTC) that corresponds to a medical concept contained within the medical text. The code point resolver applies rule-based logic to process the medical text to form a localized mapping of a text portion of the medical text to a plurality of candidate SMTCs (CSMTCs) that are related to at least one metathesaurus concept entity (MCE) in a metathesaurus. The code point resolver determines the code point from the CSMTCs, and transmits, via the network interface, to the medical management system, the code point.

DETAILED DESCRIPTION

The following general computer acronyms may be used below:

FIG.1Ais a block diagram of an example DPS according to one or more embodiments. In this illustrative example, the DPS10may include communications bus12, which may provide communications between a processor unit14, a memory16, persistent storage18, a communications unit20, an I/O unit22, and a display24.

The processor unit14serves to execute instructions for software that may be loaded into the memory16. The processor unit14may be a number of processors, a multi-core processor, or some other type of processor, depending on the particular implementation. A number, as used herein with reference to an item, means one or more items. Further, the processor unit14may be implemented using a number of heterogeneous processor systems in which a main processor is present with secondary processors on a single chip. As another illustrative example, the processor unit14may be a symmetric multi-processor system containing multiple processors of the same type.

The memory16and persistent storage18are examples of storage devices26. A storage device may be any piece of hardware that is capable of storing information, such as, for example without limitation, data, program code in functional form, and/or other suitable information either on a temporary basis and/or a permanent basis. The memory16, in these examples, may be, for example, a random access memory or any other suitable volatile or non-volatile storage device. The persistent storage18may take various forms depending on the particular implementation.

For example, the persistent storage18may contain one or more components or devices. For example, the persistent storage18may be a hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above. The media used by the persistent storage18also may be removable. For example, a removable hard drive may be used for the persistent storage18.

The communications unit20in these examples may provide for communications with other DPSs or devices. In these examples, the communications unit20is a network interface card. The communications unit20may provide communications through the use of either or both physical and wireless communications links.

The input/output unit22may allow for input and output of data with other devices that may be connected to the DPS10. For example, the input/output unit22may provide a connection for user input through a keyboard, a mouse, and/or some other suitable input device. Further, the input/output unit22may send output to a printer. The display24may provide a mechanism to display information to a user.

Instructions for the operating system, applications and/or programs may be located in the storage devices26, which are in communication with the processor unit14through the communications bus12. In these illustrative examples, the instructions are in a functional form on the persistent storage18. These instructions may be loaded into the memory16for execution by the processor unit14. The processes of the different embodiments may be performed by the processor unit14using computer implemented instructions, which may be located in a memory, such as the memory16. These instructions are referred to as program code38(described below) computer usable program code, or computer readable program code that may be read and executed by a processor in the processor unit14. The program code in the different embodiments may be embodied on different physical or tangible computer readable media, such as the memory16or the persistent storage18.

The DPS10may further comprise an interface for a network29. The interface may include hardware, drivers, software, and the like to allow communications over wired and wireless networks29and may implement any number of communication protocols, including those, for example, at various levels of the Open Systems Interconnection (OSI) seven layer model.

FIG.1Afurther illustrates a computer program product30that may contain the program code38. The program code38may be located in a functional form on the computer readable media32that is selectively removable and may be loaded onto or transferred to the DPS10for execution by the processor unit14. The program code38and computer readable media32may form a computer program product30in these examples. In one example, the computer readable media32may be computer readable storage media34or computer readable signal media36. Computer readable storage media34may include, for example, an optical or magnetic disk that is inserted or placed into a drive or other device that is part of the persistent storage18for transfer onto a storage device, such as a hard drive, that is part of the persistent storage18. The computer readable storage media34also may take the form of a persistent storage, such as a hard drive, a thumb drive, or a flash memory, that is connected to the DPS10. In some instances, the computer readable storage media34may not be removable from the DPS10.

Alternatively, the program code38may be transferred to the DPS10using the computer readable signal media36. The computer readable signal media36may be, for example, a propagated data signal containing the program code38. For example, the computer readable signal media36may be an electromagnetic signal, an optical signal, and/or any other suitable type of signal. These signals may be transmitted over communications links, such as wireless communications links, optical fiber cable, coaxial cable, a wire, and/or any other suitable type of communications link. In other words, the communications link and/or the connection may be physical or wireless in the illustrative examples.

In some illustrative embodiments, the program code38may be downloaded over a network to the persistent storage18from another device or DPS through the computer readable signal media36for use within the DPS10. For instance, program code stored in a computer readable storage medium in a server DPS may be downloaded over a network from the server to the DPS10. The DPS providing the program code38may be a server computer, a client computer, or some other device capable of storing and transmitting the program code38.

The different components illustrated for the DPS10are not meant to provide architectural limitations to the manner in which different embodiments may be implemented. The different illustrative embodiments may be implemented in a DPS including components in addition to or in place of those illustrated for the DPS10.

Cloud Computing in General

Characteristics are as Follows

Service Models are as Follows

Deployment Models are as Follows

Referring now toFIG.1B, illustrative cloud computing environment52is depicted. As shown, cloud computing environment52includes one or more cloud computing nodes50with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA) or cellular telephone54A, desktop computer54B, laptop computer54C, and/or automobile computer system54N may communicate. Nodes50may communicate with one another. They may be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This allows cloud computing environment52to offer infrastructure, platforms and/or software as services for which a cloud consumer does not need to maintain resources on a local computing device. It is understood that the types of computing devices54A-N shown inFIG.1Bare intended to be illustrative only and that computing nodes50and cloud computing environment52can communicate with any type of computerized device over any type of network and/or network addressable connection (e.g., using a web browser).

Referring now toFIG.1C, a set of functional abstraction layers provided by cloud computing environment52(FIG.1B) is shown. It should be understood in advance that the components, layers, and functions shown inFIG.1Care intended to be illustrative only and embodiments of the invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

Any of the nodes50in the computing environment52as well as the computing devices54A-N may be a DPS10.

Computer Readable Media

The present invention may be a system, a method, and/or a computer readable media at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

Technical Application

The one or more embodiments disclosed herein accordingly provide an improvement to computer technology. For example, an improvement to a computer database comprising medical information allows for a more efficient and effective resolution of ambiguity that may exist within the database.

Code Point Resolution Using Natural Language Processing and a Metathesaurus

The following application specific acronyms may be used below:

TABLE 2Application Specific AcronymsANSIAmerican National Standards InstituteCSMTCcandidate standardized medical terminology codesCTclinical termsCUIconcept unique identifierDICOMDigital Imaging and Communications in MedicineEMRelectronic medical recordHL7Health Level Seven InternationalIDCInternational Classification of DiseasesISOInternational Organization for StandardizationLOINCLaboratory Logical Observation Identifiers Names and CodesMCEmetathesaurus concept entityNCCNNational Comprehensive Cancer NetworkNLPnatural language processingOPCS-4Office of Population Censuses and Surveys Classification ofInterventions and Procedures version 4PETpositron emission tomographySMTCstandardized medical terminology codes, for example, SNOMEDSNOMEDSystematized Nomenclature of MedicineUMLSUnified Medical Language SystemUMLSMUnified Medical Language System metathesaurus

The use of MCEs and SMTCs are known in the medical industry. However, there may be instances in which multiple concepts and related MCEs are present in a span of medical text, or instances in which a single concept may map to multiple SMTCs (a one-to-many relationship). Having multiple concepts and related MCEs or multiple SMTCs may result in a lack of clarity or produce ambiguity, and thus, it may be desirable to eliminate the multiplicity and provide a single MCE and/or SMTC. The process of ultimately producing a single SMTP from a span of medical text is referred to herein as “code point resolution”. Code point resolution means selecting a single SMTC from among multiple candidate SMTCs (CSMTCs) for a given portion of medical text that is most appropriate to a particular application that will use the information, or domain for the solution. By way of example, if a term “radiation” were found in clinical notes with a clinical application, the system would consider codes related to “radiation therapy” (treatment) before considering “ionizing radiation” (physical force), which would not be associated with clinical notes very often.

Disclosed herein is a code point resolver system and related method that may be used to resolve a code point for one or more concepts over a span of unstructured medical text. Code point resolution by the code point resolver may be performed by considering concepts or associated MCEs that are a best fit for an application, and mapping an individual MCE(s) to a single code point. In the case where multiple MCEs cause multiple SMTCs to be CSMTCs, the code point resolver may use other information, such as clinical notes and/or structured data to disambiguate. “Medical text”, “clinical notes”, and “other information” may, in some cases, have a similar form, but may constitute separate documents or be delineated in some manner, such as having different origins or being part of a separate entry and the like. “Clinical notes”, as defined herein, refers to a wide variety of documents generated on behalf of a patient, and may include, but is not limited by, the FHIR definition of clinical notes. Usually, each note is for a specific event, such as a consultation, discharge, procedure, etc. When multiple CSMTCs still exist, the process may, in some embodiments, determine a fitness score for each CSMTC and then determine the code point as the one CSMTC having the highest fitness score. Other techniques discussed herein may be utilized to determine the code point as well. If structured data is available for the patient, information in that structured data may be utilized in addition to the (unstructured) medical text for improving accuracy. “Medical text” may additionally include research papers, clinical trial protocols, or other data not related to a specific patient.

Code point resolution relates to concept detection and mapping these concepts to concept codes, i.e., the SMTCs, such as the Systematized Nomenclature of Medicine—Clinical Terms (SNOMED-CT) codes, using the approaches and techniques described herein, to reach a decision as to which CSMTC best represents the information in a span or portion of medical text. Other SMTCs may involve terminologies such as the International Classification of Diseases (ICD) ICD-9-CM, ICD-10, ICD-O-3, ICD-10-AM, Laboratory Logical Observation Identifiers Names and Codes (LOINC), RxNorm, which is part of the UMLS terminology, and the Office of Population Censuses and Surveys Classification of Interventions and Procedures version 4 (OPCS-4). The SMTCs may support standards such as the American National Standards Institute (ANSI), the Digital Imaging and Communications in Medicine (DICOM), Health Level Seven International (HL7), and the International Organization for Standardization (ISO) standards. The SNOMED-CT, as a particular instance of a SMTC system, is a standardized vocabulary of clinical terminology that is widely used by health care provides for the electronic exchange of clinical health information. SNOMED codes are a common standard for exchanging clinical information between providers. SNOMED-CT codes tend to focus on clinical information. Because of that, SNOMED-CT is often used by care providers and insurance companies for exchanging structured medical information, and thus it is more standard in the industry for “end users”.

The techniques described herein may involve natural language processing (NLP), and may be practiced, for example, without user interaction. They may disambiguate SMTCs for MCEs detected from the medical text “in context”, i.e., using relationships provided in the metathesaurus and context information from external sources, such as available clinical notes (which, e.g., may be broader than just nearby words in a given medical text item).

The UMLS includes a biomedical metathesaurus, the UMLSM, that is organized by concept/meaning, and links similar names (or surface forms) for a particular concept from nearly two-hundred vocabularies. A “concept” is a fundamental unit of meaning in this metathesaurus, which represents a single meaning—every concept is assigned a concept unique identifier (CUI). This metathesaurus also identifies useful relationships between concepts and preserves the meanings and relationships from each vocabulary. Solutions often summarize clinical information as SMTCs, such as SNOMED codes, making use of detected CUIs and relationships defined by the metathesaurus.

The UMLS CUIs are generally used by NLP related tasks to extract meaning from text. UMLS is built from over one-hundred different vocabularies (including SNOMED). Mappings between vocabs get complicated quickly. A single surface form may have multiple possible meanings (CUIs), each CUI may be associated with zero or more SNOMED codes, and SNOMED codes may be associated with more than one CUI/concept. This results is an n-to-n relationship between UMLS CUIs and SNOMED codes that makes it difficult to get from a word or phrase to the ideal SNOMED code or codes that can be used by a higher level application. By way of example, “muscle weakness” vs. “incomplete paralysis” are concepts in different vocabs that might be a single concept in one vocab, and multiple concepts in another. The UMLS tends to provide the mappings and the consumer figures out what to do with them, and thus, it is not a practical tool for end users or high level systems. An aim herein is then to find a single SMTC, such as a SNOMED code, that is most useful to the consumer/application for the medical text.

FIG.2Ais a block diagram of a concept tree200(alternately, surface form) that illustrates an instance in which the text portion maps to a single CUI having multiple CSMTCs (e.g., SNOMED codes). The concept tree200shows a relationship between a key word(s) of a medical text portion, one or more related CUIs, and one or more SMTCs. The concept tree200may have a “covered text” field205that indicates the relevant text for a medical text portion. In the example shown, a medical text (described below) input portion may be “the patent received radiation treatment”, resulting in the covered text being “radiation”. The relevant single UMLS CUI210meaning is designated “C1522449” from the metathesaurus in this example, which corresponds to the concept/meaning of a therapeutic radiology procedure. However, this CUI may be related to two SMTCs: a first SMTC215, such as a first SNOMED code (here, by way of example, 108290001 corresponding to radiation oncology and/or radiotherapy), and a second SMTC, such as a second SNOMED code (here, by way of example, 5343800 corresponding to radiation therapy procedure or service).

There are reasons that multiple SMTCs may be relevant. Although the single CUI in 000this example represents a single meaning, each CUI may map to zero or more SMTCs. It may map to zero SMTCs because it is possible that no SMTC is defined for the particular meaning; it is also possible that multiple SMTCs could apply to the meaning. For example, if the CUI for “Therapeutic Radiology Procedure” is discovered for the text “radiation”, there are two SNOMED codes that are mapped to the CUI.

FIG.2Bis a block diagram that illustrates multiple CUIs due to ambiguity applying to the covered text. A single medical text span or medical text portion may have multiple relevant UMLS concepts defined for it. The UMLS is a combination of many vocabularies, and these vocabularies may not agree on a specific meaning. This is partly because a single surface form might have different meanings in different contexts. For example, inFIG.2B, “nephrectomy” could refer to a total nephrectomy in one context, or any type of nephrectomy in another context. In this example, each CUI has a distinct SNOMED code mapped to it. As shown, the concept tree250has a “covered text” field255that indicates the covered text is “nephrectomy”. The first UMLS CUI260meaning is designated “C0176996” which means a total nephrectomy. This is related to a first SMTC265, such as a first SNOMED code (here, by way of example, 175905003). The second UMLS CUI270meaning is designated “C0027695” which means a nephrectomy. This is related to a second SMTC275, such as a second SNOMED code (here, by way of example, 108022006).

Multiple CUI—Combination of Ideas/Multiple Concepts

FIG.3Ais a block diagram of a concept tree300that combines multiple ideas, which is another reason that multiple concepts may exist. In this example, the concept tree300represents a combination of ideas, and the combination does not have a single UMLS CUI.FIG.3Aillustrates an example concept tree300in which the covered text field305includes a combination of ideas: “BillRoth II” and “GastroJejunostomy”. Here, the first UMLS CUI310meaning is designated “C0399839” which means a gastrojejunostomy. This is related to a first SMTC315, such as a first SNOMED code (here, by way of example, 442338001). The second UMLS CUI320meaning is designated “C0192444” which means a BillRoth II procedure. This is related to a second SMTC325, such as a second SNOMED code (here, by way of example, 83985009).

Increased Complexity

In practice, these examples may combine to create enormous complexity.FIG.3Bis a block diagram that illustrates a concept tree350for an example of increased complexity. For example, inFIG.3B, the covered text field355includes the term “radiation”, which has multiple CUIs: one with multiple SNOMED codes, and one with a single SNOMED code. Here, the first UMLS CUI360meaning is designated “C1533449” which means a therapeutic radiology procedure. This is related to two SMTCs: a first SMTC365, such as a first SNOMED code (here, by way of example, 108390001 for radiation oncology and/or radiotherapy), and a second SMTC370, such as a second SNOMED code (here, by way of example, 53438000 for a radiation therapy procedure or service). The second UMLS CUI375meaning is designated “C1534030” which means radiation ionizing radiotherapy. This is related to a third (single) SMTC380, such as a second SNOMED code (here, by way of example, 135576007). Far more complex concept trees are possible by invoking this principle. The result is a significant increase of SMTCs associated with a single event.

FIGS.4A-4Care block diagrams illustrating process flows400A,400B,400C for associating a best-fit SMTC with a respective event.

FIG.5is a block diagram illustrating a system500within which the code point resolver520may operate. As shown inFIG.5, medical input data514, including the medical text512, may originate from a medical management system510. The medical management system510may comprise any number of computers, such as DPSs10, that are connected via a network, and may be implemented, for example, in a cloud computing environment52. The code point resolver520may operate with the application processing96, as described above. The medical input data514may comprise medical text512and related other information, such as clinical notes and structured data, may be all or a part of an electronic medical record (EMR). The medical input data514may be received by the code point resolver520via a network interface522, and received by rule-based logic540, which may comprise an NLP542, pattern matching rules544, supervised machine learning (ML) models546, or any other rule-based mechanism. Where supervised ML models546are used, such models may be trained in a training phase using a set of training data that relates medical text to SMTCs and/or provides selecting a single SMTC from a set of SMTCs. The rule-based logic540may comprise a knowledge base that stores relationships and mappings between CUIs and SMTCs.

In some embodiments, the medical text512may be broken down into medical text portions. For example, if the medical text512contains information from multiple visits to a facility, multiple procedures performed, etc., the NLP542may break the information into individual portions to simplify the processing. This breaking down or parsing of the medical text512by the NLP542may be based on a mechanism such as punctuation, keywords, parts of language (nouns, verbs, etc.) or using other known techniques for language parsing. The medical text portions may be further processed by the NLP542to remove superfluous words and organize the text in a consistent manner. Additionally, the NLP542may perform a tokenization of the medical text512. The NLP542may determine one or more concepts/CUIs associated with the medical text512or text portions.

The code point resolver520, in order to resolve the code point, i.e., the best-fit SMTC, may consider multiple concepts/CUIs that are the best fit for an application. The code point resolver520may determine that certain concepts and/or certain types of concepts are more valuable for a medical text portion512than others. The rule-based logic540may make this determination by incorporating NLP542, pattern matching rules544, and/or supervised machine learning models546. By way of example, if the algorithm540has a relevance determiner548that determines a medical text portion512relates to a radiation procedure, then it would determine applicable CUIs that are therapeutic or preventive procedures. Since this relates to a procedure, non-procedure-based concepts (such as the concept for “electromagnetic radiation” or “radiation physical force”) may thus be considered not relevant and filtered out and not considered for mapping into an SMTC(s), since it is much more likely that documentation of a clinical visit is referring to a type of radiation therapy. The delineation of a procedure vs. non-procedure may be, for example, found in definitions of the SMTCs themselves, or may be distinguished by being “therapeutic and diagnostic procedures” as opposed to something that is for example a “physical object” (e.g., a positron emission tomography (PET) scan vs PET system).

In addition to the distinction of “procedure vs. non-procedure”, other forms of distinction may be considered as well. For example, “disorder vs. organism” might be a distinction that could be used to delineate various terms, such as SARS, where the text could potentially refer to either a disorder or an organism. In some embodiments, the surface form matching logic uses the longest match it can find.

In some embodiments, the individual concepts are mapped to a code point. The code point resolver520determines the code point for a CUI by applying the rule-based logic540that considers common parameters of an application. The rule-based logic540may thus use the relevance determiner548to select an SMTC or filter SMTCs based on the most correct intent of the CUI in the context of the medical application (e.g., codes for procedures are favored over codes for non-procedures or other intents) that may be provided to the code point resolver520. Although the relevance determiner548is show separately from the pattern matching rules544and the supervised machine learning models546, the relevance determiner548may make use of them or be a part of them. Similarly, the fitness scorer549, discussed in more detail below, may make use of the pattern matching rules and/or supervised ML models546or be a part of them. The code point resolver520may have access to external data information sources, such as the interchange coding system552(e.g., SNOMED and others discussed above) to provide the SMTCs554, and a biomedical metathesaurus556(e.g., UMLSM discussed above) to provide the metathesaurus concept entities558.

If multiple CSMTCs remain, and these codes exist in a hypernym-hyponym relationship, then the rule-based logic540may choose the hypernym over the hyponym. The case inFIG.2Billustrates this. “Nephrectomy” could be mapped to “total nephrectomy” or “nephrectomy”. Since there is uncertainty at this point, the more general one is picked. But if other documents later include medical text about a “total nephrectomy” on the same day, then that decision may be revised to a more specific code. In another example, “mastectomy” may be chosen as the hypernym, but could be later determined to refer to other kinds of mastectomies (e.g., simple, radical, bilateral . . . ). These examples are largely based on how UMLS and SNOMED organize the relationships between procedures. The mastectomy could be viewed as an example of speaking generally about something more specific. However, in terms of code resolution, this problem may also happen because different vocabs have different mappings. Sometimes this leads to more than one mapping for the same medical text, and therefore it may be desirable to pick the most general concept for accuracy.

If multiple CSMTCs continue to remain, then a source rater may determine a reliability of the sources for the respective CSMTCs, and the CSMTC with the highest reliability rating. Because UMLS has many vocabularies and mappings, some sources are more reliable. If multiple CSMTCs continue to remain, then further logic may apply, such as the oldest CUI that exists in UMLS being chosen. Older CUIs are more familiar, and are more often used in practice. To determine the age of a CUI, it may be possible to determine an absolute or possibly a relative age based on a length or a value of the CUI (e.g., newer CUIs may have longer identifiers). In other embodiments, the age might be determined by loading each version of the UML's database and recording when a particular CUI first appeared in the database. In some embodiments, age is used as a proxy for how frequently a code is used, based on a presumption that CUIs that have been around a while are more in use than newer ones. Determining the frequency that a CUI or SMTC is used within a large corpus may be an alternative mechanism for decision-making.

As noted above, in the case where multiple concepts have resulted in multiple CSMTCs, the code point resolver520may try to disambiguate using other information, such as clinical notes or structured data. The code point resolver520will often detect a same event for a particular SMTC in multiple notes associated with the text portion. Some of these notes have more detail than others. For example, an operative clinical note may state a specific “skin-saving mastectomy”, while an assessment clinical note may simplify this and simply state in a general manner that the patient had a “mastectomy”. These operative and assessment clinical notes may be aggregated together by the code point resolver520, and SMTC disambiguation may be performed at that time. In order for the code point resolver520to aggregate events or information from different text portions, it may consider identifying information related to the events, relationships between SMTCs and CSMTCs, as well as any detected date for the event. Further, the code point resolver520may then decide whether to combine the information from two events or not. If events are combined, then the most suitable code, based on the process discussed above, may be selected for the combined event.

By way of example, for the mastectomy example above, the code point resolver520may determine that the patient identifier is the same for two events represented by text portions, and the two clinical notes are both for the same day (or within a predefined segment of time), and thus logically determine that these two different notes both refer to the same event. Other rules or logic may be used to make this determination by the rule-based logic540.

FIGS.4A-4Care block diagrams illustrating process flows for associating a best-fit SMTC with a respective event, according to some embodiments.

FIG.4Ais a block diagram illustrating an event400A for processing an event with ambiguous CSMTCs420,425. The medical input data514relates to a surgery event410having a first possible CSMTC420, where the CSMTC refers to a nephrectomy, and a second possible CSMTC425refers to a total nephrectomy. The date evidence414associated with the surgery event410indicates the date of occurrence simply as being some time in 2019. The event evidence416makes reference to a generic “nephrectomy”. As can be seen by the medical text430A, the indication is that “the patient had a nephrectomy”432A “in 2019”434A.

FIG.4Bis a block diagram illustrating an event400B that shows another event that has been constructed from a different text portion showing more detail, namely, the text portion clarifies that “the patient had a total nephrectomy”432B and has a more specific “December 2019”434B date. It also has a single CSMTC425. The event inFIG.4Bcan be combined with the event inFIG.4Abased on a relatedness of the procedures and relatedness of the date, even though one is more general than the other.

FIG.4Cis a block diagram illustrating a combination400C of the events400A,400B fromFIG.4AandFIG.4B. The most specific code425, the total nephrectomy, has been selected for the new event by the rule-based logic540, based on the more specific text portion430B,432B. The most specific date434B has also been updated by the rule-based logic540. The evidence from the two prior events400A,400B may be included in the new event400C.

Returning toFIG.5, a fitness score may be determined by the rule-based logic540in the event that the code point516cannot be determined by other mechanisms described herein. The rule-based logic540may utilize a fitness scorer549for each of the CSMTCs and then choose the CSMTC having the highest score. The fitness scorer may perform certain of the rule-based logic540described above, such as providing a higher score to a hypernym over a hyponym, providing a higher score for a UMLS or SMTC that is more reliable or has a higher reliability measure, providing a higher score where an older UMLS is present. A reliability measure for various sources may be provided in the configuration files of the code point resolver520, and may be determined from developer experience, and combined potentially with measuring the accuracy of the overall system. When choosing mappings between UMLSs and SMTCs, some sources of the mapping are known or believed to be better sources than others.

In the event that no other principled logic yields a single CSMTC, then an arbitrary decision may be made by the rule-based logic540to ensure a single CSMTC is returned as the code point516. This arbitrary decision may be based on, e.g., a numerical order of a SNOMED ID value, a random selection of remaining CSMTCs, or any other mechanism to ensure a return of a single value. In some embodiments, it may be advantageous to ensure a consistent return of the code point516for a given input of data.

Multiple factors discussed above may be used by the fitness scorer549to determine the fitness score, and these may be applied, in some embodiments, by applying a weighting to the factors described above. For example, a weighting may be applied to an MCE that is based on a medical application intent (e.g., a procedure may have a higher weighting than a test); a weighting might be applied in which hypernyms are weighted higher than hyponyms; a source that is more reliable may be weighted higher than one that is less reliable; and a weighting may be weighted according to codes by an industry acceptance rating.

FIG.6is a flowchart of an example process600that may be utilized by the code point resolver520. In operation602, the code point resolver520receives, via a network interface522, medical input data514that may comprise medical text512, with possibly other information, from a medical management system510. In operation604, rule-based logic540may be used to process the medical text512, and may comprise, in some embodiments, the components of a natural language processor542, pattern matching rules544, supervised ML models546, a relevance determiner548, and a fitness scorer549. These components may interact with one another or share algorithms and functionality.

The rule-based logic540may utilize other information, such as clinical reports, and structured data, along with medical terminology codes (SMTCs)554or an interchange coding system552, such as SNOMED. The rule-based logic may further utilize a biomedical metathesaurus, such as the UMLSM556to provide metathesaurus concept entities558. A plurality of CSMTCs are associated with the medical input data514. Ultimately, in operation606, the code point resolver520resolves a single code point516from the plurality of CSMTCs. In operation608, the code point516is transmitted, via the network interface522, to the medical management system510in order to assist the medical management system510in resolving any ambiguity that may be present in the initial medical input data514. The code point516may be further utilized to construct a timeline of a patient's history. By way of example, this could be used by an oncology application that assists a physician with following National Comprehensive Cancer Network (NCCN) guidelines, and/or matching patients with relevant clinical trials. Additionally, the code point516may be utilized to convert the unstructured text and other associated medical input data514into structured data, such as into a Fast Healthcare Interoperability Resources (FHIR) record format for storage and use in the above-discussed applications.