US20160283656A1

US20160283656A1 - Application Program Interface for Generating a Medical Classification Code

Info

Publication number: US20160283656A1
Application number: US15/078,806
Authority: US
Inventors: Regis Charlot; Frank Naeymi-Rad; Steven Rube; Alina Oganesova; Daniel Emmons; Bradley Robinson; Yunwei Wang; David Parks
Original assignee: Intelligent Medical Objects Inc
Current assignee: Intelligent Medical Objects Inc
Priority date: 2015-03-24
Filing date: 2016-03-23
Publication date: 2016-09-29
Also published as: US10885148B2; US20160283673A1

Abstract

A system and method for including a medical classification code in a computer application such as an electronic health record includes a web service configured to render as an interactive object in a portion of an application user interface. In response to a query, the web service returns an output including data, user interface components, and behavioral logic in order to update an interactive object.

Description

This application claims the benefit of priority from U.S. Provisional Application No. 62/137,374, filed Mar. 24, 2015, the contents of which are incorporated herein by reference in their entirety.

BACKGROUND

1. Field of the Invention
The present application is directed to electronic health recordkeeping.
2. Description of the Related Art
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 Disease (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. patent publication 2014/0122117, published May 1, 2014, 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, and one or more descriptions (lexicals) linked to each concept, where each description reflects an alternative way to express the concept.
In one example, clinical interface terminology content may be released and updated on a monthly basis, for multiple domains of clinical terminology, e.g., for multiple history domains, conditions & diagnoses, procedures & orders, etc. Additionally, each domain may be tailored to a specific phase of care for a patient. As such, domains may vary greatly, as do the information and terminology they contain.
Another challenge is that clinical application capturing patient care data points may implement per-domain subsets of clinical interface terminology, either by filtering on data flags, or by using a workflow tied to a specific term within that domain. As a consequence, the implementer may have the difficult task of selecting features and behavior or designing specific patient care workflow.
What are needed are a system and method that address one or more of these challenges.

BRIEF SUMMARY

In one aspect, a method for including a medical classification code in a computer application includes the steps of: providing a web service configured to render as an interactive object in a portion of an application user interface on a first computer system, receiving, within the interactive object, a user query requesting a medical classification code, transmitting first data corresponding to the query to a server including one or more processors, analyzing, by the one or more processors, the first data to determine at least one root lexical result, at least one variant for each root lexical result, and at least modifier for each variant, returning to the first computer system, an output comprising second data, user interface components, and behavioral logic in order to update the interactive object, receiving, within the interactive object, a user selection of a modifier, updating the interactive object to exclude combinations representing medical classification codes not including the user-selected modifier, receiving a user selection of a medical classification code, and integrating the medical classification code into the computer application.
In another aspect, a method for populating a data field in an electronic health record includes the steps of: in response to a user selection of a data field within the electronic health record, providing a web service configured to render as an interactive object interfacing with the electronic health record on a first computer system, receiving a user query within the interactive object, transmitting first data corresponding to the query to a server including one or more processors, analyzing, by the one or more processors, the first data to determine at least one potential match to the user query, the at least one potential match comprising second data, returning to the first computer system, an output comprising the second data, user interface components, and behavioral logic in order to update the interactive object, receiving, within the interactive object, a user selection of a modifier, filtering the second data based upon the user-selected modifier, receiving a user selection of an entry for the electronic medical record, and writing the user selection into the data field.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is one depiction of a system for including a medical classification code in a computer application.

FIG. 2 is an exemplary screenshot of an implementing application including a widget for locating a medical classification code, the widget including a searching component.

FIG. 3 is an exemplary screenshot of the implementing application and widget, depicting options for refining a query.

FIG. 4 is an exemplary screenshot of the implementing application and widget, depicting one or more attributes for further refining a query.

FIG. 5 is an exemplary screenshot of the implementing application and widget, depicting results of a refined query.

FIG. 6 is an exemplary first screenshot of a spline-based method for navigating through a plurality of modifiers to determine a medical classification code.

FIG. 7 is an exemplary second screenshot of a spline-based method for navigating through a plurality of modifiers to determine a medical classification code.

FIG. 8 is an exemplary first screenshot of a box-based method for navigating through a plurality of modifiers to determine a medical classification code.

FIG. 9 is an exemplary second screenshot of a box-based method for navigating through a plurality of modifiers to determine a medical classification code.

FIG. 10 is an exemplary first screenshot of a tile-based method for navigating through a plurality of modifiers to determine a medical classification code.

FIG. 11 is an exemplary second screenshot of a tile-based method for navigating through a plurality of modifiers to determine a medical classification code.

DETAILED DESCRIPTION

With reference to the accompanying figures, a system and method for generating an application program interface (“API”), such as a diagnosis, problem, and symptom search and medical classification code retrieval API is described. The API is embeddable as an interactive object in an implementing application for executing one or more tasks or one or more modalities, including searching, refinement, and/or decision support. A searching modality example is describe below in greater detail. Similarly, several examples of refinement modalities that include processing a clinical workflow with the goal of locating a desired medical classification code also are described below. Examples of decision support may include analyzing a record or collection of data entries to determine if sufficient data has been recorded to support a medical necessity finding or if one or more diagnosis-related groups (“DRGs”) are supported by the data. The API may be implementable in one or more other modalities, as would be appreciated by one of ordinary skill in the relevant art.
In one aspect, the implementing application is an electronic health record (“EHR”), such as the EHRs licensed by Allscripts under the trademark TOUCHWORKS and by NextGen under the name Ambulatory EHR. Similarly, in one aspect, the medical classification code is an International Classification of Disease, 10th Revision, Clinical Modification (“ICD-10-CM”) code, although the system also may support the delivery of other codes, such as the Systematized Nomenclature of Medicine-Clinical Terms (referred to under the trademark SNOMED-CT), Current Procedural Terminology (referred to under the trademark CPT), Logical Observation Identifiers Names and Codes (referred to under the trademark LOINC), and RxNorm. Other implementing applications and medical classification codes may be used in connection with the system 10, as would be appreciated by one of ordinary skill in the relevant art.
Request
With reference to FIG. 1, the system 10 may include a RESTful API 12 hosted on a platform, which in one aspect includes a server 14 including instructions stored in memory 15 and a processor 16 that executes those instructions in order to carry out the processes described herein. The API receives user queries from one or more computing devices 18 and returns results as one or more HTML objects that are renderable as an interactive object. Both the API and the implementing application software may be hosted on a server controlled by the entity whose users are using the software, e.g., by a hospital whose users are physicians, nurse practitioners, billing specialists, etc. Alternatively, neither may be hosted by that entity, such as when they reside on servers belonging to the provider(s) of the API and implementing application, which may be the same or different entities, or on servers belonging to an intermediary. In still another alternative, the end-user entity may host one of the API and the implementing application software, with the other being hosted by another party.
The API 12 may manifest itself as a widget 20 sharing display real estate with the user interface (“UI”) 22 of the implementing application. In one aspect, a user may not recognize the widget 20 as being viewable distinct from the application. Instead, widgets may be fully restyled so they can be perceived as a native component of the application. In another aspect, the widget may manifest itself as a pop-up window overlapping a portion of the application or as another window adjacent the application window, although the widget may incorporate styling (font choice, size, and color, background shading color, logos or other branding, etc.) from the application in order to create the perception that the widget is part of the application software. The widget 20 may include multiple display sections, e.g.: search, results, and alerts, which may include decision support options.
Turning to FIGS. 2-5, in one aspect, the widget 20 initially may include a search bar or other feature configured to receive a user input request, e.g., a string query representing a search term or phrase used to find one or more medical classification codes relating to that term or phrase. After receiving an initial user input, the widget 20 may render an interactive object, e.g., providing one or more additional, selectable optional parameters to provide greater specificity to the user's query. For example, the medical classification codes may be categorized according to a plurality of different domains, such as problem, history, plan, medication, etc. Additionally, the widget 20 may present to a user other selectable, optional parameters in an attempt to achieve greater specificity or accuracy pertaining to the initial query. Thus, in one aspect, in addition to the variations depicted in the figures, modifications to the initial user query may be achieved through the use of a selector, such as a domain selector, which may include a series of check-boxes, a drop-down menu, an expandable list, or another feature, as would be appreciated by one of ordinary skill in the relevant art. In another aspect, the system may recognize the domain based on the portion of the implementing application in which the user is working and tailor the widget 20 to the specifics of that domain.
Once the user's initial inputs have been received, the API 12 may call its hosting server 14 and transmit data pertaining to the user query. Additional server calls may be made after each user selection within the interactive objects rendered by the API. Alternatively, after receiving the initial user query, the server may transmit all data pertaining to that query and all possible variations to the user's computer so that the interactive objects may be fully populated without needing to make additional server calls.
Search data may include one more data types, including one or more strings corresponding to the user-entered query and one or more enumerated types corresponding to the domain selection. Other information transmitted to the server may include an organization identifier, alone or in combination with a site identifier and/or a user identifier, in order to ensure authorized access. Still further, the data transmitted to the server 14 may include a field identifying the implementing application with which the API is used, as formatting of the results may be customized to the specific application UI 22 that is being used.
Access to the server 14 called by the API may be over HTTP or HTTPS. Requests may be encoded using one or more different data interchange formats, including, e.g., JSON, XML, or Protocol Buffers.
Processing
After receiving the user's search data, licensing may be verified to ensure that the query came from an authorized user. Additionally, the data request may be parsed, a terminology portal may be accessed and searched using at least some of the parsed data, and one or more matches may be found and communicated to the user using the UI, as discussed above with regard to FIGS. 3-5. One example of a technology portal and its process for analyzing a data request to compile a plurality of concepts that match, e.g., within a given confidence level, is the processing undertaken by the platform disclosed and claimed in the commonly-assigned U.S. Pat. No. 9,135,318, titled “System and Method for Implementing a 64 Bit Data Searching and Delivery Portal,” the contents of which are incorporated by reference in their entirety.
Return
In particular, the system 10 may return HTML objects that include data, behavior (script), and user interface elements. Data may include the medical classification code(s) most closely matching the user's request and descriptions relating to those codes. Additionally or alternatively, data may include base medical classification codes or a clinical interface diagnosis that may be broader than the user's query, along with one or more variants having one or more modifiers selectable, and/or one more flags below to filter results in order to guide the user to a desired medical classification code. Flags may be used to filter the user's initial query and, in the context of queries relevant to EHR entries, may reflect categories such as: severity, gender, age, groupers, and specialty-based categorization. While not required, data may be returned using the same data interchange format as the request, e.g., XML, JSON, or Protocol Buffers.
Behavior elements may be logic, e.g., expressed in JavaScript or another scripting language. Behavior may be implemented as a separate file to be included locally within the containing application page and may be universal to all widgets of a specific domain or to each method of interactive display, examples of which are provided below. The behavior library may implement several JavaScript events, designed to interface with and trigger workflows within the containing application. As discussed in greater detail below, one example of behavior is the logic used to update a display of selectable modifiers based upon one or more user inputs as to other modifiers. Other logic may include decision support, e.g., prompting the user to verify that other actions related to the user's selection have been or will be completed. For example, in the context of logic pertaining to EHR entries, a user selection relating to a certain procedure may require a finding of medical necessity to support reimbursement for that procedure, which may be reflected in prompting the user, through the API, to verify the applicability of additional codes relating to the problems or procedures that provide that medical necessity. The logic may be stored in memory 15 on the server as a series of links between data elements, where the links are analyzed by the API and conveyed to the user upon selection of one or more linked elements.
User interface elements may be reflected in code instructing a user interface (UI) how to implement the logic, i.e., how to present the data and modify the presentation based on the logic and on user inputs. In one aspect, user interface elements may be provided in HTML and/or Cascading Style Sheets (CSS). In particular, the behavior may include instructions defining one or a plurality of user-selectable, interactive view modes, e.g., a graph mode, a box mode, and a tile mode. In another aspect, multiple widgets may be available by domain in order to allow the implementer a choice of UI representation. Regardless of the view mode selected, the system may guide the user through a process of selecting relevant modifiers to reach a most appropriate and specific ICD-10-CM code.
Depending on the completeness of the user's query, returned results may be a fully-defined classification code concept or an interface terminology concept that maps to a classification code concept. More likely, results may be less than fully defined, such that even greater specificity is possible and, in fact, may be necessary in order to obtain a fully defined concept and its corresponding classification code value. These search results may be termed “root lexicals,” and the additional specificity may be achieved through the use of one or more modifiers selected from among one or more variants.
One visual method for navigating through a plurality of modifiers may be seen in FIGS. 6 and 7, as well as described and claimed in the commonly-assigned U.S. patent application Ser. No. 14/817,912, titled “System and Method for Medical Classification Code Modeling,” the contents of which are incorporated herein by reference in their entirety. Specifically, one manner in which the system and method accomplish these tasks is by generating an interactive visual mapping of components of an interface terminology that map all medical classification codes suggested as a result of the initial user query. The system then may receive user selections of one or more modifiers, where the system may remove visual representations of medical classification codes that do not include mappings to the selected modifiers.
After receiving the user's search request and presenting the user with one or more possible root lexical results, the system may receive a selection from the user of an entry within a results list. Upon receiving the selection and highlighting that selection for user convenience and visual recognition, the system may query a database to determine what variants, if any, exist to potentially modify the root lexical. Each variant may represent a category having one or more options. Each root lexical may map to multiple medical classification codes via combination with different modifiers. These relationships may be precompiled, so that, rather than building the relationships each time a user selection is made, the query involves retrieving data reflecting those relationships, thereby shortening processing time and reducing the demand for system resources. Thus, upon receiving the user's root lexical selection, the system already may be aware of the variants necessary for further specificity.
The system then may generate visual maps 30 based on the underlying mappings between the modifiers of each code set value. Visual depictions of multiple overlapping mappings may be generated at the same time, eliminating a need for a user to move back and forth between multiple displays.
In the example of FIGS. 6 and 7, variants 32 may be reflected as a series of parallel lines, with the modifiers 34 for each variant reflected as one or more nodes on each respective line, although other methods of arranging modifiers into groups and depicting those groups separately. The system also may generate curves or splines 36 connecting all the nodes that yield fully-defined medical classification codes. As such, each spline 36 represents both a combination and a classification code set value, e.g., an ICD-10 code. Each spline 36 also may correspond to a fully specified interface terminology element, which may be considered a hyperprecoordinated term.
As mentioned above, the widget may be interactive within the implementing application. Thus, selecting one or more nodes may causes the system to remove all curves from the display that do not pass through the node. (Similarly, selecting a node that already has been selected removes that node from selection and may redraw or redisplay all curves that pass through other nodes on that variant level.) Additionally, when the user selects a node, the system may update a summary of changes shown within the widget real estate on the display to reflect only those changes that relate to splines passing through those nodes.
In another aspect, navigating through multiple variants and modifiers may be accomplished by providing the user with a series of discrete boxes 40, tiles, drop-down menus, etc., in which different variants 42 are presented in the discrete sections. One such example of this navigation method is seen in FIGS. 8 and 9, in which the UI generates a plurality of adjacent columns 46 having different variants 42 for a given search term. As a user selects a modifier 44 within one variant 42, the system 10 may update the listings of variants 42 and modifiers 44 to distinguish between modifiers that remain combinable with the selected modifier and those that are eliminated from consideration because no medical classification code includes such a combination. In one aspect, distinguishing may mean that the two categories are visually distinguishable from one another. For example, as seen in FIG. 7, selecting the modifier “allergic” within the “otitis media type” variant results in each modifier in the “spontaneous tympanic membrane rupture” and “suppurative otitis media location” variant boxes being grayed out and become non-selectable, because no medical classification code may include the combination of the “allergic” media type with any of those modifiers.
Another example of a similar graphical workflow may be described and claimed in the commonly-assigned U.S. Patent Publication No. 2015/0154362, titled “Method & System for Concept-Based Terminology Management,” the contents of which are incorporated herein by reference in their entirety. In that case, the boxes may be collapsed into a series of drop-down menus for each variant, where the entries within a menu correspond to the one or more modifiers relating to that variant.
Turning to FIGS. 10 and 11, in still another aspect, modifiers 54 may be presented as a series of adjacent tiles 50 grouped together according to their respective variants 52. In these figures, the variants 52 are presented in a first column, and their respective modifiers 54 are displayed in a second, adjacent column, with one or more rows of modifiers being displayed for each variant, depending upon a width of the column, which may be a function of the UI real estate provided to the widget by the implementing application. As with the other examples described above, selecting a modifier 54 within one variant 52 may update the display of the other modifiers within that variant to make them non-selectable. Similarly, other modifiers of other variants that are not combinable with the selected modifier also may become non-selectable.
The user choice of interactive method may result in different user interface elements being returned to the user's computer. For example, each interactive method may be associated with its own object in a database, where the object includes CSS or other formats informing the implementing application of where in its real estate to position the widget as well as how to display the content presented therein.
Regardless of the interactive method selected by the user, once the user selects sufficient modifiers to result in a single medical classification code or has narrowed a list of potential medical classification codes to such an extent that a desired code is selectable from among a plurality of displayed codes, the system may receive the user's selection of such a code and integrate it into the implementing application. In one aspect, this integration may be achieved by a script in the implementing application that launches the widget when the data field is selected and that includes instructions to write the results of the user's interaction with the widget into that data field.
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.

Claims

We claim:

1. A method for including a medical classification code in a computer application, comprising:

providing a web service configured to render as an interactive object in a portion of an application user interface on a first computer system;

receiving, within the interactive object, a user query requesting a medical classification code;

transmitting first data corresponding to the query to a server including one or more processors;

analyzing, by the one or more processors, the first data to determine at least one root lexical result, at least one variant for each root lexical result, and at least modifier for each variant;

returning to the first computer system, an output comprising second data, user interface components, and behavioral logic in order to update the interactive object;

receiving, within the interactive object, a user selection of a modifier;

updating the interactive object to exclude combinations representing medical classification codes not including the user-selected modifier;

receiving a user selection of a medical classification code; and

integrating the medical classification code into the computer application.

2. The method of claim 1, wherein the computer application is an electronic health record.

3. The method of claim 1, wherein the medical classification code is part of the International Classification of Disease, 10th Revision, Clinical Modification,

4. The method of claim 1, wherein the medical classification code is part of the Systematized Nomenclature of Medicine-Clinical Terms.

5. The method of claim 1, wherein the first data is in a data interchange format including at least one of XML, JSON, and Protocol Buffers.

6. The method of claim 1, wherein the second data is in a data interchange format including at least one of XML, JSON, and Protocol Buffers.

7. The method of claim 1, wherein the first data and the second data are in the same data interchange format.

8. The method of claim 1, further comprising:

providing a plurality of user interface representations for graphically depicting the at least one variant and the at least one modifier.

9. The method of claim 8, wherein one user interface representation comprises:

displaying each of the at least one variants as a line;

displaying each modifier for each of the at least one variants as a separate node on its respective line;

generating a spline through each node combination that correlates to a fully defined medical classification code; and

upon selection of a modifier, visually distinguishing modifiers that are combinable with the selected modifier to correspond to medical classification codes from modifiers not combinable with the selected modifier to correspond to medical classification codes.

10. The method of claim 8, wherein one user interface representation comprises:

displaying each of the at least one variants as a box or column;

displaying each modifier for each of the at least one variants as entries within each respective box or column; and

11. The method of claim 8, wherein one user interface representation comprises:

displaying each of the at least one variants as an entry in a column;

displaying each modifier for each of the at least one variants as entries in an adjacent column; and

12. The method of claim 1, wherein the user interface components comprise HTML.

13. The method of claim 1, wherein the behavioral logic is provided in JavaScript.

14. A method for populating a data field in an electronic health record, comprising:

in response to a user selection of a data field within the electronic health record, providing a web service configured to render as an interactive object interfacing with the electronic health record on a first computer system;

receiving a user query within the interactive object;

analyzing, by the one or more processors, the first data to determine at least one potential match to the user query, the at least one potential match comprising second data;

returning to the first computer system, an output comprising the second data, user interface components, and behavioral logic in order to update the interactive object;

receiving, within the interactive object, a user selection of a modifier;

filtering the second data based upon the user-selected modifier;

receiving a user selection of an entry for the electronic medical record; and

writing the user selection into the data field.

15. The method of claim 14, wherein the potential match is a medical classification code within the International Classification of Disease, 10th Revision, Clinical Modification,

16. The method of claim 14, wherein the potential match is a medical classification code within the Systematized Nomenclature of Medicine-Clinical Terms.

17. The method of claim 14, wherein the first data is in a data interchange format including at least one of XML, JSON, and Protocol Buffers.

18. The method of claim 14, wherein the second data is in a data interchange format including at least one of XML, JSON, and Protocol Buffers.

19. The method of claim 14, wherein the user interface components comprise HTML.

20. The method of claim 14, wherein the behavioral logic is provided in JavaScript.