Patent Application
20180357381
The present application is directed to systems and methods for managing local deployments of ontological mappings, such as mappings between an interface terminology and one or more external codes sets. In one aspect, the interface terminology and external code sets may be used to encode data in one or more domains for recordkeeping within a plurality of electronic health records or other data repositories.
Electronic medical ontologies, also known as medical classification codes, are necessary with the implementation and proliferation of electronic medical records. Various ontologies have been developed for various reasons, including administrative code sets that may be designed to support administrative functions of healthcare, such as reimbursement and other secondary data aggregation; clinical code sets that encode specific clinical entities involved in clinical work flow and allow for meaningful electronic exchange and aggregation of clinical data for better patient care; and reference terminology code sets that may be considered a “concept-based, controlled medical terminology” to maintain a common reference point in the healthcare industry. Reference terminologies also identify relationships between their concepts, e.g., relationships can be hierarchically defined, such as a parent/child relationship. Common examples of administrative code sets are the International Classification of Diseases (ICD) and the Current Procedural Terminology, which is referred to via the trademark CPT. Examples of clinical code sets are the Logical Observation Identifiers Names and Codes, referred to under the trademark LOINC, and a normalized terminology for medication information, such as the terminology of the National Library of Medicine referred to under the trademark RxNorm. One example of a reference terminology is the Systematized Nomenclature of Medicine—Clinical Terms, referred to under the trademark “SNOMED CT.”
One challenge with implementing an electronic medical ontology is to ensure the accuracy and completeness of recordkeeping, at the time of the patient visit or otherwise during data entry. One method of structuring and codifying the data to achieve this goal includes implementing an interface terminology that recognizes semantic meaning, mapping that interface terminology to the various other ontologies, and then relying on that interface terminology to analyze the practitioner's entries. One example of a system and method for using an interface terminology and the relevant ontology mappings may be found in the commonly-owned U.S. Pat. No. 9,594,872, issued Mar. 14, 2017, the contents of which are incorporated by reference in their entirety. In that example, the interface terminology comprises a plurality of concepts within one or more domains (problem, procedure, plan, medication, etc.) and one or more descriptions (lexicals) linked to each concept, where each description reflects clinical intent and an alternative way to express the concept.
The process of mapping between an ontology such as an interface terminology and one or more external code sets, such as an administrative terminology, a clinical terminology, and/or a reference terminology, is dynamic, with mappings being added or deleted as the elements of the ontology or of the code sets are added, removed, or otherwise modified. For example, since descriptions or lexicals within the interface terminology may reflect clinical intent, variants of those descriptions may be developed over time as a practitioner or institution develops a personalized way of expressing the underlying concept. Alternatively, as the various terminologies are modified or updated, such as with the transition from ICD-9 to ICD-10, numerous terminology elements may be added, eliminated, or otherwise modified, and maps to those elements must be created or modified accordingly.
One benefit of mappings between interface terminology elements and the various external code set elements is that a user can rely on their clinical intent to represent a problem, procedure, etc., with the mapping then determining the appropriate external code element, thereby freeing the clinician from having to recall or search for each specific external code element. At the same time, however, it may be difficult for physicians, billing agents, or other terminology users to keep track of the modifications in mappings to ensure that their clinical intent is being mapped to the most accurate, most complete, or otherwise most appropriate external code elements. Similarly, if a clinician's term is mapped to a deactivated external code element, the clinician's documentation may not map to external codes that are necessary for adequate documentation, billing, etc., which may require a billing agent or other individual to have to seek out the clinician at a later date to discern what an appropriate mapping should be, which may result in inaccuracies and/or the expense of additional time and resources. These difficulties may be exacerbated by the fact that the specific changes from release to release may not be published to end users. As such, the first time those users may ascertain whether relevant changes have been made may be when they attempt to use a deactivated, deleted, or otherwise outdated mapping.
In contrast to the benefits provided by broad adoption of an interface terminology, e.g., more uniform documentation and more accurate and timely billing, widespread use of the interface terminology may be met with a lack of user customization. For example, if an end user disagrees with a mapping between an interface terminology and an ICD-10 code, it may take the agreement of a significant number of other end users in order to effectuate a change in the mapping. Until then, or if such agreement is not reached, the end user may not have the benefit of a mapping that more specifically addresses one or more situations it documents.
What are needed are a system and method that preferably address one or more of these challenges.
In one aspect, a method for generating local deployments of ontological mappings includes the steps of: receiving a user selection of a reference ontological mapping, wherein the reference ontological mapping is loaded on a computer system, receiving a user selection of a customizable ontological mapping, wherein the customizable ontological mapping includes an indicator for one or more individual mappings within the customizable ontological mapping, parsing the customizable ontological mapping according to the indicator for the one or more individual mappings, generating a subset of the customizable ontological mapping based on the parsing step, presenting the subset to a user, receiving user-generated modifications to the subset, and saving the user-generated modifications in a local instantiation of an ontological mapping.
In another aspect, a method for generating local deployments of ontological mappings includes the steps of: receiving a user selection of a reference ontological mapping, wherein the reference ontological mapping is loaded on a computer system, receiving a user selection of a customizable ontological mapping, wherein the customizable ontological mapping includes an indicator for one or more individual mappings within the customizable ontological mapping, parsing the customizable ontological mapping according to the indicator for the one or more individual mappings, generating a subset of the customizable ontological mapping based on the parsing step, presenting the subset to a user, receiving user-generated modifications to metadata affiliated with the subset, and saving the user-generated modifications in a local instantiation of an ontological mapping.
As set forth in greater detail herein, the present system and method are operable within a network of computer systems, with a plurality of computers each having a processor configured to operate electronic health record (“EHR”) software accessible by one or more care providers to document patient encounters. In one aspect, each computer system operates the same EHR software. In another aspect, the computer systems may operate different EHR software packages that receive and/or store patient data in different ways. In this latter aspect, however, the various EHR software packages may interface with a common ontology such as an interface terminology in order to provide a common encoding mechanism for their respective sets of patient data.
As described in greater detail below, the present system and method permit end users to manage local deployments of ontological mappings, such as mappings between an interface terminology and one or more external code sets and metadata elements ascribed to the interface terminology or external code set elements. As part of that process, the system and method provide for release-to-release comparison, support local terminology customizations by allowing users to customize default mappings, generate or modify local versions of the mappings within the interface terminology, permit customization of the interface terminology itself, facilitate editing of metadata associated with the mappings, the interface terminology, or one or more of the external code sets, and leverage local usage data to make informed customization decisions about mappings.
In one aspect, the system includes a plurality of data files that include data such as: 1) each interface terminology concept, 2) unique identifiers pertaining to each interface terminology concept, 3) one or more interface terminology descriptions (or lexicals), 4) mappings between the interface terminology descriptions and their relevant concepts, 5) elements of one or more external code sets, 6) unique identifiers pertaining to each of the elements of the one or more external code sets, 7) mappings between the interface terminology concepts or descriptions and the elements of the one or more external code sets, 8) metadata relating to the interface terminology concepts or descriptions, and 9) metadata relating to the external code set elements.
Data may be stored or arranged in multiple ways. For example, the data files may be relational or other types of databases, with tables for one or more of the categories of data listed above, and links between the tables used to account for other categories, e.g., for the mappings between categories of data. Additionally or alternatively, the data may be stored in one or more text files, e.g., in tabular form as seen in
Just as data may be stored or arranged in multiple ways, so too may the customization to the ontological mapping. For example, a user may be permitted to customize the interface terminology itself, e.g., by adding, deleting, hiding, or otherwise modifying one or more local instances of interface terminology concept-description mappings. Similarly, the system may permit the addition or removal of an external code set element. Moreover, the system may permit modification of the mapping between an interface terminology element and an external code set element, as discussed in greater detail below. Still further, the system may permit modifications to the metadata associated with one or more of the external code sets and/or the interface terminology.
Updates to one or more of the data files may be pushed automatically to a user's computer systems. Alternatively, users may be advised that updates are available but must actively obtain or download the updated data files.
In either case, once the updated data files have been downloaded to the user's computer system, the system may permit installation of the newest version of the ontology mapping. As part of that process, and as seen in
Turning to
Turning to
It will be understood that these indicators are merely exemplary, that more or fewer indicators may be used to describe the state of each mapping, and that other types of indicators may be used to represent mapping variants. Other indicators, e.g., “new,” “modified,” deactivated,” “reactivated,” “unchanged,” etc., or other numeric, alphabetic, alphanumeric, or symbolic indicators, may be employed to categorize each mapping. Additionally, it will be appreciated that, for at least the “active and unchanged” and “active but modified” indicators, it may be necessary to compare that indicator value against each version of the ontological mappings between the reference version and the customizable version in order to determine whether those mappings are accurate as they relate to the comparison with the reference version.
Once the customizable version has been loaded and compared with the reference version, the system may present the user with a list or table of all entries (or a subset of entries) within an ontology or within one or more domains within that ontology, which may be, e.g., a list of problems, procedures, medications, labs, etc. In another aspect, as seen in
As seen in
In one aspect, the system may only present the user with a proposed replacement when that replacement reflects an exact equivalence with the external code set description. In this context, equivalence may refer to semantic or clinical equivalence, as opposed to identity of terminology. For example, “fracture of left arm” may be deemed an exact equivalent to “fracture of left upper extremity” and/or “fx left arm.” Similarly, as seen in
The system may distinguish these suggestions from other entries in the table for which the user has selected a replacement or affirmatively confirmed the system's suggestion. For example, the suggested entries may be highlighted a different color as compared to other replacement entries. Alternatively, the suggested entries may be highlighted while the other replacement entries are not, in order to indicate to the user that additional action may be necessary with regard to those suggested entries.
In another aspect, as seen in
Turning now to
The system then may receive a user selection of one of search results to create a localized mapping of that ontological description to the relevant external code description and identifier. That process may be repeated for additional entries in the list or table. As described above, the list or table may represent fewer than all entries in the ontology and, more specifically, may represent the mappings being deactivated from the reference version to the customizable version. Thus, the user may not need to determine replacements for all entries in the list or table but instead may be able to limit review to those ontology descriptions that they anticipate continuing to use.
In one example, a previous release version may include an external code description mapped to the ontological description “fracture of arm or leg.” In that instance, the new version may turn off that mapping because it is ambiguous and because there may be two separate replacements, i.e., “fracture of arm” and “fracture of leg,” where one of those mappings accurately represents the problem being mapped to, as determined by a user's local usage of the content. Thus, if a user were to search for “arm fracture,” the system may return the ontological description “fracture of arm” and may update the mapping to the external code set with that description upon selection by the user.
In another instance, a user may want the system to recognize some of his or her shorthand abbreviations as being valid ontological abbreviations for the external code set description. For example, the user may want the system to recognize the term “ht” as “heart attack.” In this case, the search query may not recognize the connection between those terms, so that inputting “ht” into the search box may not return the desired result. As such, the system may open a directory of all ontological concepts within the domain being queried, e.g., a list of all problem-related concepts. Such a list may be sorted, e.g., alphabetically or into clusters or categories of related entries, thereby permitting the user to manually review the list for the desired match. Upon receiving a user selection of the desired concept, the system may facilitate the desired customization in at least one of two different ways.
First, the system may permit the user to add a local instance of a description mapped to the selected concept. This option may be better suited for situations where the desired description is viewed as a common alternative for one of the existing descriptions. For example, the system may permit the addition of a description “lung” for the concept “pulmonary” (presuming such a description was not already part of the interface terminology). Alternatively, the system may permit modification of the metadata associated with a description selected by the user after selecting the desired concept. In this second instance, the metadata associated with a concept or a description may include lesser-used synonyms, misspellings, or other variants of the description. For example, the user may wish to add the synonym “pmnry” to the local instance of the ontology mapping, as that may reflect a term used by the user but that may not be used commonly by other users. To do so, the system may generate a local synonym table that includes a column for the interface terminology concept or description (or an equivalent identifier), and a second column that includes the synonym entry. The local synonym table also may include a column to hold a status flag, e.g., that the synonym is active or retired.
The system also may facilitate the local modification of other types of metadata associated with the ontological mapping. For example, certain interface terminology or external code set concepts may include default flags reflecting variable such as age, gender, etc. In the vast majority of circumstances, those concepts may pertain to a specific group, such that the system may default a metadata flag to represent that group. At the same time, the end user may be faced with a situation presenting the exception to that default rule and may wish to create a local exception to the metadata flag. For example, the concept “cancer of ovary” may have a gender flag defaulted to “female,” as that is a concept almost entirely unique to females. However, as there are rare instances in which a male may have ovaries, the local user may encounter a situation of a male with the recorded problem “cancer of ovary.” In that case, the system may generate a local gender flag table, with a first entry for female and a second entry for male, with each entry having its own, unique flag, e.g., “1” for female and “2” for male. The system then may add a column to the local interface terminology concept table to make a gender query, whereby the user can set the flag to “2” for a given patient's record if applicable.
The system may facilitate the local modification of other forms of metadata, including permitting the user to set whether a certain interface terminology description is a clinician term or a person health term, i.e., whether it is the term commonly used by physicians at that facility or whether it reflects a more widely understood term to be provided to lay people. Additionally, with regard to the search feature described above and depicted in
As discussed above, the system may generate these local metadata variations by creating relevant local tables for each type of metadata being modified. Alternatively, the system may generate one or more general rule tables that may record each different type of change being made, with columns for the relevant changes and an additional column reflecting the metadata type. Thus, when the system generates the local instantiation, it can make the necessary local modifications by looking in one place for those changes.
As seen in
The local release can take several forms. For example, it may involve rewriting the mapping data file, table, or database to replace existing maps with the user-defined maps, to remove system-defined maps, or to create new user-defined maps (e.g., when a user changes an ICD-10 mapping). One way to do this is to add or remove rows (or columns) in the table or database where each row (or column) includes one map.
Alternatively, the local release may be stored separately from the universal mapping data, e.g., by building out a distinct database object or table that holds each of the user-approved changes in a change/rule table, and then by universally or selectively applying the changes to the chosen target data file, which may be the file/database storing the customizable mapping selected earlier by the user. In that case, building the local release may involve loading the base or canonical data into a source database, loading the local revisions as another object, e.g., a rule table, in the database, and then updating the source database in accordance with the customized rules in the rule table. This process may involve, e.g., replacing a value in a column (or row) with an indicator that represents whether the mapping is active. For example, the column (or row) could contain a status indicator variable, where “0” corresponds to that mapping being inactive and “1” corresponds to that mapping being active. Thus, the mappings being deactivated may have their status indicator set to “0” and the mappings being user-added or modified may be set to “1.” Those mappings may be appended to the end of a mapping file, table, or database, or the system may be configured to read the universal mapping file first, then to read the local instantiation, replacing universal mapping entries with local entries where appropriate and/or adding local entries where no corresponding universal entry previously existed.
One advantage of mapping rules being stored in isolation from the databases or files containing the ontology and the one or more external codes and of the local instantiation maps may be stored separately from the records of universal maps, is permanence of the local instantiation. In other words, by separating the local maps from other ontology maps, those local maps may be applied to the customizable version each time a new such version is made available to the user, such that the system retains the user's preferences and eliminates the user's need to duplicate previous review work.
While the figures present the user with mappings between ontological descriptions and a single external code set, the process is extendable to make similar customizations to mappings between the ontological descriptions and other code sets. In one aspect, this may be accomplished by presenting each of the mapped code sets on the same list or table as the one shown in
In addition, the system may include audit trails so that changes can be walked back incrementally. Additionally, the system may permit batch rebuilds, where multiple rule changes are reversed, e.g., all changes made since the last version was released.
In addition to being stored locally, rules that third parties execute may be returned back to central computer system for analysis or consideration as to whether the third party change should be adopted system-wide. Thus, it is possible that a local ontology map may become a universal map in a later release version. In that case, in one instance, the system may delete the local map from the user's local map file upon its adoption as a universal map. In another instance, the system may retain the local map, in the event that the universal map is changed again at some future date.
While the system may permit local customization, it also may include features to prevent accidental or potentially detrimental user modifications to the ontology mapping. For example, the system may collect usage data corresponding to each mapping, using that data to determine which terms are used more often than others. The system then may cross-check proposed local mapping changes with those terms to prevent potentially inadvertent changes to frequently-used mappings, since changes may be made by a local system administrator or someone with less understanding of the impact making the change would have on the local system's users.
In addition to frequently used terms, the system also may prevent the user from modifying other classes of ontological mappings. For example, the system may include a preferred class of terms, where the preference comes, e.g., from the accuracy of the ontological description to the external code set entry. Additionally, the ontological mapping may include internal hierarchies, e.g., where one description maps to an external code that supports post-coordination, i.e., modifier use, and additional descriptions map to the external codes that apply the modifiers. In that case, the system may prevent the user from providing localized maps to the more general entry, since the impact of modifying that map may ripple down through the other, more specific entries.
Alternatively, as seen in
In one instance, the system and the relevant files or databases may be installed locally on a user's computer system. In another instance, the system may run on a virtual machine installed on the user's local computer. In yet another instance, the system may run on a central server dedicated to the user's organization. In still another instance, the system may be hosted in a cloud-computing environment that is accessible through, e.g., an Internet connection, by each third party organization seeking user customization.
Thus, the system and method as described herein allow for internal overrides or edits of mappings between elements of an ontology such as interface terminology descriptions and elements of one or more external code sets, such as ICD-10 or SNOMED CT. As such, users may be able to take advantage of a core ontological mapping to the external code sets and then extend that mapping to meet the needs specific to the users' organizations through customization of content and dynamic analytics based on the users' unique needs and usage data.
While the foregoing written description of the invention enables one of ordinary skill to make and use what is considered presently to be the best mode thereof, those of ordinary skill will understand and appreciate the existence of variations, combinations, and equivalents of the specific exemplary embodiment and method herein. The invention should therefore not be limited by the above described embodiment and method, but by all embodiments and methods within the scope and spirit of the invention as claimed.
