Various embodiments of the present disclosure relate generally to search platforms and systems. More specifically, particular embodiments of the present disclosure relate to systems and methods for searching medical codes representing a medical diagnosis or procedure.
In order to be paid by insurers, medical providers document and report the healthcare services provided to their patients. The documentation and reporting may include accurately assigning medical codes to diagnoses or procedures (including laboratory tests), directly by physicians or with help from medical coders. Some of the common “languages” used to share this medical information may be represented by coding systems such as ICD (International Classification of Diseases), DSM (The Diagnostic and Statistical Manual of Mental Disorders), CPT (Current Procedural Terminology), SNOMED CT (Systematized Nomenclature of Medicine—Clinical Terms), HCPCS (Health Care Procedure Coding System), LOINC (Logical Observation Identifiers Names and Codes), MeSH (Medical Subject Headings), UMLS (Unified Medical Language System), NDC (National Drug Code), APC (Ambulatory Payment Classification), DRG (Diagnosis Related Group), LCD/NCD (Local Coverage Determination/National Coverage Determination), Revenue Codes, and Modifiers coding systems.
The ICD is an international coding systems for reimbursement, epidemiology, and health management, which may assign specific diagnostic and procedural codes to diseases and other health conditions. In October of 2015, the US Government mandated a switch from the 36-year old, obsolete ICD-9 to a modern, detailed, and much more complex ICD-10. This brought a significant increase of the code numbers and complexity, disrupting the practice workflows and productivity.
Furthermore, current medical coding approaches may be slow and inefficient. One common method for coding medical codes by medical professionals or medical insurance providers is manual coding, despite being labor intensive and having low productivity. Coders may need to use several monitors to review a patient chart while consulting a local or online resource.
In traditional coding-related lexical searches, users may type a few key words and may get a long list of results, which they need to browse. Users may be reluctant to go to the second or subsequent pages of search results, and may settle on one of the first few results, usually one of the more non-specific codes, or start over with a refined set of words for a subsequent search. In addition, mapping between ICD-9 and ICD-10 (forward and backward mapping) used in many applications may be inefficient, as only 5% of the codes may map 1 to 1. Thus, current coding methods may not be as intuitive for users, and may make it hard for users to find what they are looking for, unless they know the exact name of a database entry.
Computer Assisted Coding may be a more recent approach that may use software integrated into Electronic Medical Records to automate the coding process. It may scan the patient chart for key words, and through Natural Language Processing, it may suggest a list of codes which may need to be validated by coders and physicians. However, Computer Assisted Coding may be expensive and may rely on a difficult variable in the practice, non-standard patient documentation. Two physicians who see the same patient at the same time may document their observations differently, their notes being dependent on their background, education, gender, age, emotional state, etc.
The task of coding also may be complicated by other factors. For example, a disease can be described using various names. A disconnect may exist between physicians who document a medical diagnosis or procedure into the medical record, and coders who may determine which codes are to be selected by reviewing the patient chart. The interaction between these two groups may need to include both a clear and detailed physician description of the patient's current health state, and extensive knowledge of anatomy and physiopathology by coders.
Accurate coding and documentation of patients' diagnoses, complications and comorbidities, and their treatments, may be important as it may directly affect revenue, including future pay for performance metrics, clinical outcomes and public health. There is a need to standardize the capture of medical events (observations, conditions and treatments) through coding, in a consistent and uniform way which is generally accepted by the medical community.
Thus, there is a desire for a system and method of searching medical codes representing a medical diagnosis or procedure, which is fast and efficient, precise in its coding, intuitive for the user, and does not require rigorous training on the part of users. There is also a desire for a platform and user interface that would enable the system and method of searching for medical codes representing a medical diagnosis or procedure, which may be able to facilitate access to complex and precise coding systems (e.g., ICD-10).
The foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure. According to certain aspects of the present disclosure, systems and methods are disclosed for searching medical codes representing a medical diagnosis or procedure.
One method includes: performing one or more iterations of visually selecting one of the descriptive attributes to produce search results displayed on a keyboard-like user interface (“The Technological keyboard”), wherein the search results include other descriptive attributes and medical codes; and selecting the desired medical code from the search results, wherein the one or more iterations includes (1) an order of selecting descriptive attributes and (2) a group of descriptive attributes, and there is more than one order or more than one group of descriptive attributes that can be visually selected to produce a search result.
In accordance with another embodiment, a system for searching medical codes representing a medical diagnosis or procedure comprises: a data storage device storing instructions for enabling a user to search for a desired medical code of the medical codes; a user interface enabling the user to search for the desired medical code, wherein descriptive attributes are assigned to each of the medical codes, at least some of the descriptive attributes including categories comprising other of the descriptive attributes; and a processor configured to enable the user of the system to: perform one or more iterations of visually selecting one of the descriptive attributes to produce search results displayed on a keyboard-like user interface, wherein the search results include other descriptive attributes and medical codes; and select the desired medical code from the search results, wherein the one or more iterations includes (1) an order of selecting descriptive attributes and (2) a group of descriptive attributes, and there is more than one order or more than one group of descriptive attributes that can be visually selected to produce a search result.
In accordance with another embodiment, a method for enabling a user to search for medical codes representing medical diagnoses or procedures, the method comprises: storing medical codes in an electronic storage medium; assigning descriptive attributes to each of the medical codes, at least some of the descriptive attributes including categories comprising other of the descriptive attributes; receiving an input from the user, wherein the input is a selection by a user of one of (a) the descriptive attributes, (b) the medical codes, or (c) the keyboard functionalities to view more descriptive attributes or medical codes, displayed on a keyboard-like user interface, and wherein the input does not include the user typing alphanumeric text of the one of the descriptive attributes, medical codes, or the keyboard functionalities; if the received input is a descriptive attribute or a keyboard functionality, producing and displaying search results on the keyboard-like user interface, wherein the search results include other descriptive attributes and medical codes; and if the received input is matched to a medical code, producing and displaying the medical code on the keyboard-like user interface.
Additional objects and advantages of the disclosed embodiments will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of the disclosed embodiments. The objects and advantages of the disclosed embodiments will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments, as claimed.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various exemplary embodiments, and together with the description, serve to explain the principles of the disclosed embodiments.
Reference will now be made in detail to the exemplary embodiments of the disclosure, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.
As described above, a desire exists for a system and method of searching medical codes representing a medical diagnosis or procedure, which, in embodiments, is, one or more of, fast and efficient, precise in its coding, intuitive for the user, and does not require rigorous training on the part of users. Furthermore, a desire exists for a platform and user interface that, in at least certain embodiments, would enable the system and method of searching for medical codes representing a medical diagnosis or procedure, which may be able to facilitate access to and conversion between complex and precise coding systems (e.g., ICD-9, ICD-10, etc.).
The exemplary embodiments of systems and methods described in the present disclosure may allow for a quick and clear visualization of the ICD-10 structure/options of coding for users, and may be a solution to at least some of the current problems caused by the government mandated switch to the ICD-10 coding language, including the difficulty in the mapping of codes from other medical “languages” (terminologies, classifications, ontologies, etc). Through the platform for searching medical codes representing medical diagnoses and procedures, as described below, physicians may be able to learn the ICD-10 CM “language” based on their existent knowledge, without needing rigorous training.
To facilitate the transition into ICD-10, the platform described in embodiments of the present disclosure allows cross-referencing of a target taxonomy (ICD-10) with helper taxonomies (SNOMED, DMS-5), and an extraction and classification of elements used in describing an ICD-10 code (or any other taxonomy). This means that representation of healthcare information in an organized, consistent and reusable way may involve various structures (e.g., coding languages) for various purposes. For example, the ICD is the global health information standard for mortality and morbidity statistics. SNOMED is the most comprehensive, multilingual clinical terminology in the world. The Diagnostic and Statistical Manual of Mental Disorders (DSM) is the standard classification of mental disorders used by mental health professionals in the US. In each of the above systems, similar medical concepts are described differently and organized at various degrees of granularity while preserving their semantic meanings. In the US, the mandated structure for billing purposes (ICD-10) is designed for statistics which is not optimal for the representation of the clinical process. SNOMED and DSM structures offer more practical alternatives and have partial standardized mappings to ICD-10.
Thus, cross-referencing may refer to the feature described in various embodiments of the present disclosure that may allow users to choose the most accurate concepts from any of the described structures (e.g., coding languages) in a consistently semantic way.
For purposes of demonstration, the embodiments described below relate to a system and method of searching for ICD-10 codes representing a medical diagnosis or procedure. However, the systems and methods described may be used to search for medical codes in other standardized languages for coding (including other versions of the ICD), and the platform may enable the conversion and/or translation of medical codes from one standardized language to another standardized language. Irrespective of the coding language chosen (e.g., ICD-10, DSM-5, SNOMED, etc.), a corresponding list of ICD-10 codes (based on official mappings) may be assigned for billing or other purposes.
The systems and methods described in the present disclosure may, in at least some embodiments, solve the inefficiencies of current coding methods and coding related searches, by presenting a platform for searching medical codes, which is intuitive for the user, and precise in the search results. A user may be able to search on this platform without having to type, for example, by choosing elements from groups of features from a user interface as described below. The user interface may enable users to, one or more of: quickly check one or more recent selections that led to the results of a search; use different types of filters (e.g., a user may choose to filter by anatomy, after having exclusively filtered by “specialty” during a given search process); be guided and/or helped by the application (e.g., by being presented with only relevant filter choices); and/or be worry-free about a wrong filter selection and potentially “losing work” (e.g., by still keeping the other filters active, after removing a given filter, as per user's choice). Thus, the systems and methods of searching medical diagnoses and procedure may enable, one or more of: multi-tagging, multi-filtering visual search of complex medical taxonomy; a flexible orienteering-based navigation towards a result; a ready access and/or view of search filters and/or tags that have been already applied during a search session; a visual feedback for “next steps;” an ability to apply other filters or taxonomies to narrow down the choices, including filters that may be radically different from recently used filters of a search session; an ability for users to add observations to further filter down towards fewer results; and/or multiple paths/selections to the same result.
As will be described further, the user interface may have various user-friendly features that may overcome the one or more problems of current search methods and/or platforms. These features may include one or more display of results in groups of four (e.g., 2×2 grids for fast cognitive review); a parallel display of the main results and the main attribute group options; a refinement of results by hierarchical structure and/or attributes; a display of text and icons on buttons for easy identification; a flexible workflow (e.g., enabling a user to review, change, add, cancel, and/or reset results and attributes at any step, in any order); the enablement of a retrieval of pre-coordinated values irrespective of order of choice; a minimization of the possibility of creating duplicates; a hybrid search feature, by allowing lexical searches, searches by attributes, and hierarchical searches to be combined in any order, at any step; an evolving search, whereby a user may query, quickly skim results, learn, adapt, change the direction of a search, and/or refine a query; an orienteering-based search feature, whereby a user may use currently displayed information to determine where to go next; an ability to follow the progress of a search in real-time to predict the direction of a search and allow the redirecting of a search, if necessary; a flexible, and context-specific orienteering navigation, through the user interface and its combination of filters, for example, where each selected filter, tag, and/or result may impact other filters, tags, and/or results, irrespective of the order of choice or position on the keyboard; an ability to cancel any chosen filter and/or tag individually, while keeping the other choices, regardless of their selection order; and an ability to have any given offerings of choices in a user interface reflect a user's cognitive decision (controlled/focused search), allowing a user with minimum knowledge about a desired code to review available options (all in ICD-10 “vocabulary”) and narrow down choices quickly.
The systems and methods of the present disclosure may, in at least certain embodiments, overcome the problems posed by inconsistencies of observations between various medical professionals and coders, by providing a poly-hierarchical platform that may lead to standardized patient documentation. Coders may be able to search based on elements found on patient charts, for example, unspecified codes, history (e.g., Signs/Symptoms), physical findings (e.g., Anatomy), pathology and/or other familiar terms (e.g., tumor, infection, etc.). The dynamic display and interactions between codes, hierarchical groups, anatomical elements, and anatomical groups in the user interface may allow users to review and use the existing structure and choices in the classifications for even more detailed search refinements. Instead of restricting the use of a coding language (e.g., ICD language system) to a mono-hierarchical structure, at least certain embodiments of the systems and methods of the present disclosure may utilize coding languages as a “poly-hierarchic analytical data.” In other words, a user may reach a desired medical code using more than one path, each path going through a different set of descriptive attributes and/or categories of descriptive attributes.
Furthermore, embodiments of the systems and methods of the present disclosure may be designed to allow the user to have greater flexibility in navigating towards a result (e.g., a user may start with “Body” or “Specialty” as filters, even though the starting filters may be very different). This means that doctors, coders, or other users can structure their observation in a consistent way. Consequently, richer information may by captured at the code level, while providing the user with multiple starting points or pathways in the search process. Each code may provide for a free-text entry—basically notes of the physician that may help in documentation, or for future reference, etc. In some embodiments, the user interface for searching may provide instant feedback on necessary documentation. Thus, at least certain embodiments of the systems and methods of the present disclosure may enable the re-creation of the full observation made during a visit from the elements (and possibly the navigation path taken) during that visit.
Referring now to the figures,
Embodiments of the present disclosure include a user interface, which may be designed for reducing the cognitive load by the user while searching or obtaining medical codes for medical diagnoses or procedures, and which may enable an intuitive, context-sensitive, history-tracking, attributes-based orienteering/navigation towards a medical code.
As depicted in
The user interface 200 (e.g., technological keyboard) may facilitate the ease of the search process by encoding information in a format that is familiar for the user (e.g., concepts learned in medical training). Users may start from any point and navigate a desired path of choices which follows their natural way of thinking about that medical code.
Users may search for concepts by activating the graphical buttons which contain suggestive images or text representing the sought-after concepts. Furthermore, the buttons may be linked to each other. For example, if a filter or tag button is activated, the keyboard offering may change accordingly, in the hierarchical results area 210 and/or the filters and tags area 220. Likewise, if a button in the hierarchical results area 210 is clicked or otherwise selected, the keyboard offering may change accordingly, in the hierarchical results area 210 and/or the filters and tags area 220. Thus, the two parts of the user interface, the hierarchical results area and the filters and tags area, may be ontologically linked to each other, and act as filters against each other. By enabling bi-directional filtering, at least certain embodiments of the systems and methods of the present disclosure may guide the user to the most granular result in the most efficient way (fewest buttons pressed/selected).
While
The hierarchical results area 300A (upper half of the user interface 200) may be organized into a plurality of zones, e.g., four zones as depicted in
On an abstract level, the upper left and lower left zones may be considered as being part of the disease and/or diagnostics side of the hierarchical results area while the upper right and lower right zones may be considered as being the anatomical side of the hierarchical results area. In some embodiments, where one or more searches have been performed resulting in changes in the disease and/or diagnostics side or the anatomical side, a user may use “prior selections buttons” 308D near the disease and/or diagnostics side or the anatomical side, respectively, to access the previously accessible results in the upper left, lower left, upper right, or lower right zones. In some embodiments, a search history icon 308A may allow the displaying of the codes already chosen by the user in a specific time interval. In other embodiments, the user interface may display, at the top of the disease and/or diagnostics side of the hierarchical results area, an indication of the previously selected disease groups, diseases, and/or medical diagnoses or procedures (“breadcrumbs for disease groups and diagnoses” 308B). Likewise, the user interface may display, at the top of the anatomical side of the hierarchical results area, an indication of the previously selected anatomical groups and/or anatomical elements (e.g. “breadcrumbs for anatomical groups and elements” 308C).
Each zone of the hierarchical results area 300A (e.g., upper left 310, lower left 312, upper right 314, lower right 316) may have results of a search presented in 2×2 grids, to make it efficient for human review. In some embodiments, the user interface may enable the user to scroll and view more results in the 2×2 grids, (e.g., via scrolling tools 306). Inside each grid, the results may be presented in a user-adjustable preference order, with a default provided either by frequency of usage or by existing subject matter expertise. Information within one grid may be correlated to information within another grid either hierarchically or semantically. Hierarchically, for example, refers to when information presented in one grid may be considered to be a subgroup and/or element of information presented in another grid. Semantically, for example, refers to when information presented in one grid may be considered to be related to information presented in another grid conceptually and/or by definition. In some embodiments, the grids may be arranged to be of any length or width and therefore display more than four results at a time (e.g., 2×3, 2×4, 3×3 grid, 4×4 grid, 5×5 grid, etc.)
In some embodiments, the right hand side of the hierarchical results area may correspond to other taxonomies for classifying a medical code (e.g., DSM-V, SNOMED, etc.), in addition to, or as an alternative to, corresponding with the anatomical descriptive attributes of a medical code. For example, the upper right zone may include the elements of one or more additional taxonomies (e.g., elementary classifications within the coding languages of the DSM-V, SNOMED, etc). In such embodiments, the lower right zone may include the hierarchical groups of the elements of the additional taxonomies, under which the elements of the additional taxonomies can be classified.
In some embodiments, in addition to the buttons at the filters and tags area of the user interface acting as dynamic filters, the results displayed at the hierarchical results area 300A of the user interface (e.g., the buttons in the upper right, lower right, and lower left zones) may also act as dynamic filters, allowing a further refinement of the search process, resulting in a new offering of buttons in the hierarchical results area and/or filters and tags area. In some embodiments, a user may access the history of a recent search, for example, via the prior selections button 308D next to each zone of the hierarchical results area 300A, the search history button 308A, the breadcrumbs for disease groups and diagnoses 308B, and/or the breadcrumbs for anatomical groups and elements 308C. Furthermore, dividing the results of a search (e.g., the buttons in the hierarchical results area) into groups (e.g., the four zones as depicted in
These buttons may be natural/intuitive to the medical personnel and are designed to minimize and/or eliminate the learning curve necessary to utilize the application effectively. For example, the button 336 for “Pathology” may prompt the user to consider abnormal effects of diseases. The buttons containing the filters and/or tags may have easily recognizable names (e.g., specialty, body, hyper/high, loss, vitals, studies, etc.) and/or easily recognizable symbols (e.g., pathology, zoom, orientation, timing, biological periods, time patterns, etc.). As depicted in
In some embodiments, as depicted in
In some embodiments, the filters and tags, accessible via buttons in the filters and tags area, may be interdependent on one another. In other words, the choice of options that may be presented when selecting a main button (e.g., “pathology”) may depend on whether another main button (e.g., “specialty”) or an option within said another main button (e.g., “endocrine”) has been selected. Furthermore, the display of these interdependent filters may be dynamic and depend on the search context. This means that the selection of one filter may influence the next set of filters to be displayed on the screen.
To make it easier for a user to select a filter and/or tag, or choose an option within a selected filter and/or tag, the cancel button 318 and OK button 320 may also be provided on the user interface. For example, after a user has selected a filter or tag (e.g., specialty) resulting in a list of options (e.g., list of specialties to select), a user may unselect the filter or tag (e.g., unselect specialty) using the cancel button 318. Alternatively, the user may select an option from a list of options (e.g., list of specialties), and then use the OK button 320, to finalize a specific option of a filter or tag.
Thus, the buttons, selections, and/or results of the hierarchical results area and/or the filters and tags area may be arranged intuitively for the workflow used by the target audience. The hierarchical results area 300A (e.g., 210 of
In some embodiments, the user interface may also provide the user with a search button (e.g., 302 in
Thus, one user may facilitate a search, by breaking down every code or concept of the medical diagnosis or procedure into its attributes (e.g., the specific, relevant keywords and notions). For example, “Type 2 diabetes mellitus with mild non-proliferative diabetic retinopathy with macular edema” may be first broken down into relevant keywords: “Type 2,” “diabetes mellitus,” “with,” “mild,” “non-proliferative,” “retinopathy,” “macular,” and “edema”. Once the building blocks (elements of communication) are identified, they may be further encoded through a semantic analysis (e.g., based on SNOMED ontology composition grammar) of their role and an identification of the relevant complementary values. For the above example, the following attributes may be assigned: “type 2” may be a property of measurement; “diabetes mellitus” may be disease of “Endocrinology,” a medical specialty; “with” may be ignored and/or be classified as an unapproved attribute; “mild” may be description of severity; “non-proliferative” may be an associated morphology; “retinopathy” may be linked to “retina,” an anatomical site and “pathy,” a pathological process; “macular” may be linked to “macula lutea,” an anatomical site; and “edema” may be a pathological element. Essentially, this may be a syntax de-construction. Therefore, a user may conduct a search based on these attributes and relationships, and the user interface disclosed in the present disclosure may display those attributes and relationships which may be “available” under the current choices made by the user. The user interface may allow a logical and visually intuitive navigation and selection of filters, e.g., allowing users to describe concepts by using a familiar “medical grammar.”
The systems and methods of the present disclosure may enable a user to conduct a search from using minimal information to using very detailed information about a medical diagnosis or procedure, and the search may be performed through one or more of a selection of filters related to ICD-10, a selection of filters related to supporting taxonomies (SNOMED, DSM-5, etc.), an optional lexical search (keyword typing, voice recognition, etc.).
In some embodiments, the history of the successively chosen filters and tags may be available to a user, so that any filter, regardless of its order in the history, may be reset and/or changed, using one or more keyboard functionalities. The availability of this history and the ability to reset and/or change filters may ensure a consistency of results, and/or provide the user with flexibility within the navigation process. As depicted in
Furthermore, a user may be able to view a previously presented offering of search results and/or descriptive attributes by selecting highlighted and/or activated buttons in the filters and tags area or the hierarchical results area, and/or by selecting a descriptive attribute from the breadcrumbs areas, 308B and 308C, at the top of the hierarchical results area.
In some embodiments, the search platform disclosed in the present disclosure may enable a user with the ability to change the value of any attribute, or to remove it altogether, while keeping all the other choices made by the user intact, and reorienting the search using the new filters. For example, “Numerals” may be edited to include values (e.g., five, eleven, etc.) as attributes that had not yet been options before.
In some embodiments, the search platform may be adjusted easily by editing the attributes associated with a concept, or updated altogether, e.g., to reflect changes in medical knowledge or research. For example, AIDS was initially categorized as an immune disease and included in the respective chapter of the coding system. Later on, when HIV was discovered and AIDS became known as an infectious disease, AIDS was relocated altogether to another chapter of the coding system. With systems and methods described in the present disclosure, a concept's attributes may be rapidly adapted to the new reality. The multidimensional search methodology described in the present disclosure may also help in the ongoing effort of improving ICD's structure (e.g., by shaping the development of a future version of ICD, e.g., ICD-11).
Referring to
As depicted in
The lower left zone of the hierarchical results area, which displays the hierarchical disease groups corresponding to the ICD-10 codes displayed in the upper left zone, may be populated by disease groups that may be considered to belong within the specialty of “endocrine.” The particular selection of disease groups to populate a 2×2 grid based on the recent filters chosen by a user may be based on, for example, the search history of a user, most commonly chosen search terms, an alphanumeric method of selection, a random method of selection, etc.
The upper right zone of the hierarchical results area, which displays the anatomical elements corresponding to the ICD-10 codes displayed in the upper left zone, may be populated by anatomical elements corresponding to the ICD-10 codes that may be considered to fall within the specialty of “Endocrine.” The particular selection of anatomical elements to populate a 2×2 grid based on the recent filters chosen by a user may be based on, for example, the search history of a user, most commonly chosen search terms, an alphanumeric method of selection, a random method of selection, etc.
The lower right zone of the hierarchical results area, which displays the anatomical groups corresponding to the ICD-10 codes displayed in the upper left zone and the anatomical elements corresponding to the upper right zone, may be populated by anatomical groups corresponding to the anatomical elements and ICD-10 codes that may be considered to fall within the specialty of “Endocrine”. The particular selection of anatomical groups to populate a 2×2 grid based on the recent filters chosen by a user may be based on, for example, the search history of a user, most commonly chosen search terms, an alphanumeric method of selection, a random method of selection, etc.
A user may choose to select “Diabetes Mellitus” 412 from the list of hierarchical disease groups at the lower left zone. As depicted in
For example, the prior selections buttons (e.g., 308D in
A user may choose to filter the offerings displayed in the hierarchical results area (“hierarchical results”) further by selecting “Body” 414. The selection may be indicated by a highlight of the button representing “Body” 414. In some embodiments, as depicted in
As depicted in
Subsequently, a user may select the anatomical group “eye” 418 at the lower right zone, which may result in “eye” being highlighted. As depicted in
Subsequently, a user may select the anatomical element “retina” 420 at the upper right zone. As depicted in
A user may search further by selecting a disease group (e.g., Type 2 DM 422). As depicted in
As depicted in
Thus, in the exemplary path of searching for the medical diagnosis, Type 2 Diabetes Mellitus with mild nonproliferative diabetic retinopathy with macular edema 420, the selections were specialty, endocrine, diabetes mellitus, body, face, eye, retina, Type 2 DM, and macula lutea, followed by a scroll through the results (if not available in the initial group of four results displayed in the grid) to find the right code, and then selecting the wanted code.
The systems and methods of the present disclosure offer a flexibility in the way a user may reach a desired medical diagnosis or procedure represented by a ICD-10 code, for example, “Diabetes Mellitus 2 with mild non-proliferative diabetic retinopathy with macular edema.” A user may be able to choose other paths (filters), for example going after “edema” through “Pathology.”
A user may still start by clicking the “Specialty” 402 button in the initial screen, as depicted in
However, in one embodiment, different from the examples described in
The user interface may react to the selection of “Edema” by displaying a list of Pathology terms corresponding to Endocrine disorders associated with edema:
For example, the upper left zone of the hierarchical results area may display the ICD-10 codes for endocrine disorders having “edema.” The lower left zone of the hierarchical results area may display the hierarchical groups in which the ICD-10 codes in the upper left zone may belong to. The upper right zone may display the anatomical elements which may be components of endocrine disorders having “edema.” The lower right zone may display the anatomical groups in which the anatomical elements of the upper right zone may belong to.
A user may then choose to select “Diabetes Mellitus” from the hierarchical groups in the lower left zone. The user interface may react to the selection of “Diabetes Mellitus” by displaying the types of diabetes mellitus in the lower left zone of the hierarchical results area, which may be hierarchical groups under which ICD-10 codes found in the upper left zone may belong to. Thus, the upper left zone of the hierarchical results area may display ICD-10 codes for Diabetes Mellitus having “edema” while the lower left zone may display Groups/types of Diabetes Mellitus having “edema.” The upper right zone of the hierarchical results area may display the anatomical elements which may be components for Diabetes Mellitus having “edema.” The lower right zone of the hierarchical results area may include the hierarchical anatomical groups under which the anatomical elements of the upper right zone may belong to.
Subsequently, the user may select the desired type of Diabetes Mellitus, “Type 2 DM,” in the lower left zone of the hierarchical results area. The user interface may react to the selection of “Type 2 DM” by displaying the types of Type 2 Diabetes Mellitus (Type 2 DM), in the lower left zone of the hierarchical results area, which may comprise for example, Type 2 DM with ophthalmic complications. The upper left zone of the hierarchical results area may include the ICD-10 codes for medical diagnoses and/or procedures belonging to “Type 2 DM with ophthalmic complications having edema.” The upper right zone of the hierarchical results area may include anatomical elements which may be components of “Type 2 DM with ophthalmic complications having edema.” The lower right zone of the hierarchical results area may include the anatomical groups under which the anatomical elements of the upper right zone may belong to.
Subsequently, the user may select the “Type 2 Diabetes Mellitus with ophthalmic complications” from the lower left zone of the hierarchical results area. The user interface may react to the selection of “Type 2 DM w/ophthalmic complications” by displaying the ICD-10 codes corresponding to “Type 2 DM w/ophthalmic complications,” in the upper left zone of the hierarchical results area. The lower left zone of the hierarchical results area may include the group, “Type 2 DM with ophthalmic complications having edema.” The upper right zone of the hierarchical results area may include anatomical elements which may be components of “Type 2 DM w/ophthalmic complications having edema,” for example, retina and macula lutea. The lower right zone of the hierarchical results area may include the anatomical groups under which the anatomical elements of the upper right zone may belong to.
Subsequently, the user may be able to pick the desired medical diagnosis or procedure from the upper left zone, e.g., “Diabetes Mellitus 2 with mild non-proliferative diabetic retinopathy with macular edema,” while the application displays the corresponding alphanumerical ICD-10 code to the user (e.g., as in 428 in
Thus, multiple paths and/or selections may lead to any medical code representing a medical diagnosis or procedure. As demonstrated already by the examples described, obtaining the code does not depend on the order of selections.
To enable the search process, medical codes representing a medical diagnosis or procedure may be organized and/or registered into the search platform. The organization may include determining the descriptive attributes that each medical code may belong to. For example, the medical code for Type 2 Diabetes Mellitus with mild nonproliferative diabetic retinopathy with macular edema, may include the descriptive attributes of belonging to: the specialty—endocrine; the disease group —diabetes mellitus; the body part, region, or mode of selection—face and abdomen; the anatomical groups—eye and endocrine gland; the anatomical element—retina and macula alutea. As described already, at least some of the embodiments of the present disclosure describe a poly-hierarchical classification of medical codes. Thus, Type 2 Diabetes Mellitus with mild nonproliferative diabetic retinopathy with macular edema may also belong to the particular disease group—Type 2 Diabetes Mellitus, and/or may also belong to the anatomical element—macula lutea. In some embodiments, the descriptive attributes may include categories comprised of other taxonomies and/or descriptive attributes. For example, the descriptive attribute of endocrine specialty may also serve as a category for other descriptive attributes, for example, the disease group Type 2 Diabetes Mellitus.
Therefore, step 502 may include the process of selecting descriptive attributes, including categories comprising other descriptive attributes, for a target code (“selecting target taxonomy”). To maintain the multi-directional nature of the search platform, enabling users to search for a medical code using alternate paths, step 504 may include the process of selecting alternative descriptive attributes, including categories comprising other descriptive attributes that may describe the same target code (“selecting helper taxonomy/ies”).
Moreover, steps 502 and 504 may describe the steps for registering and/or loading a medical code into the platform, to enable the user to be able to search for the medical code.
As shown in step 506, the platform may determine what to display in the initial user interface presented to a user for the search (“start point settings”). The platform may allow the flexibility of starting either from a “blank slate,” or from where the previous session ended, or from a menu presenting the most frequently (or recently) used codes and hierarchical structures. In some embodiments, a user may configure the settings of the user interface for a starting point of the search.
Based on the determined start point settings in step 506, step 508 may include a backend server (e.g., “cloud”) providing the user interface with the data necessary for the initial display labels/buttons. Subsequently, after receiving the necessary data, the platform may be designated as being ready for user input (e.g. as in step 510, “App state=ready for input”).
At step 512, a user may make an input. For example, the user may add and/or reset a filter or tag, select from a menu of options after selecting a filter or tag, select a result from the hierarchical results area, and/or select a (target) medical code that is presented.
At step 514, the application may analyze the user input at step 512, and determine whether the selection was an “end product” of the search (e.g., whether the user selected the desired alphanumerical ICD-10 code), or only a step in the search (e.g. add and/or reset a filter or tag, select from a menu of options after selecting a filter or tag, select a result from the hierarchical results area, etc.).
If, at step 514, the application determines that the user input at step 512 was an end product of the search, step 516 may include storing the code. In some embodiments, step 516 may include enabling the user to initiate additional searches, for example, from a top menu, or from somewhere along the search chain of a recent search. In some embodiments, step 516 may include enabling the user to continue to search for other, related codes, for example, by resetting some chosen filters.
If, at step 514, the application determines that the user input at step 512 was only a step in a search, step 518 may include determining whether the application has the necessary data to populate the display as a reaction to the last input (e.g. “App has data needed” to populate the user interface after a user input of opening a submenu, or scrolling through hierarchical code values).
If, at step 518, the application determines that it has the necessary data to populate the display as a reaction to the last input, step 524 may include the user interface reacting to the user input of step 512. Thus, step 524 may include displaying the new data, as may be requested by the user input. For example, if a user has selected the filter, specialty, as the user input at step 512, step 524 may include displaying a list of options of various specialties for a user to select.
If, at step 518, the application determines that it does not have the necessary data to populate the display as a reaction to the last input, step 520 may include sending a request to the cloud for the necessary data. For example, if the user has selected the filter, specialty, as the user input at step 512, and the application does not have the necessary data to supply the list of specialties, the application may send a request to the cloud to retrieve the list of specialties available to be displayed on the user interface. Subsequently, step 522 may include the cloud pushing the requested data back to the platform and/or application, and the platform and/or application processing the received data for display.
Subsequent to step 522, the application may perform step 524 of the user interface reacting to the user input of step 512 (e.g., by displaying the new data, as may be requested by the user input).
At step 526, the application may return to the “ready for input” state (e.g., as in step 510), waiting for a user input, which would commence step 512 again.
Moreover,
In contrast,
As already described in the present disclosure, and abstractly depicted in
The integration of various coding languages and taxonomies inherent within the coding languages (e.g., ICD, SNOMED, DSM), along with the interdependencies of the filters, tags, and hierarchical results of the user interface enable the search method, of at least some embodiments of the present disclosure, to be poly-hierarchical (or multi-hierarchical) in nature. This may enable the user of the platform to search for a medical code representing a medical diagnosis or procedure using one of a plurality of search methods.
Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.
This application claims priority to U.S. Provisional Application No. 62/198,184, filed Jul. 29, 2015, the entire disclosure of which is hereby incorporated herein by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
62198184 | Jul 2015 | US |