U.S. patent application number 15/078806 was filed with the patent office on 2016-09-29 for application program interface for generating a medical classification code.
This patent application is currently assigned to Intelligent Medical Objects, Inc.. The applicant listed for this patent is Intelligent Medical Objects, Inc.. Invention is credited to Regis Charlot, Daniel Emmons, Frank Naeymi-Rad, Alina Oganesova, David Parks, Bradley Robinson, Steven Rube, Yunwei Wang.
Application Number | 20160283656 15/078806 |
Document ID | / |
Family ID | 56974219 |
Filed Date | 2016-09-29 |
United States Patent
Application |
20160283656 |
Kind Code |
A1 |
Charlot; Regis ; et
al. |
September 29, 2016 |
Application Program Interface for Generating a Medical
Classification Code
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.
Inventors: |
Charlot; Regis; (Lake Bluff,
IL) ; Naeymi-Rad; Frank; (Libertyville, IL) ;
Rube; Steven; (Lake Forest, IL) ; Oganesova;
Alina; (Highland Park, IL) ; Emmons; Daniel;
(Highwood, IL) ; Robinson; Bradley; (Evanston,
IL) ; Wang; Yunwei; (Libertyville, IL) ;
Parks; David; (Barrington, IL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Intelligent Medical Objects, Inc. |
Northbrook |
IL |
US |
|
|
Assignee: |
Intelligent Medical Objects,
Inc.
|
Family ID: |
56974219 |
Appl. No.: |
15/078806 |
Filed: |
March 23, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62137374 |
Mar 24, 2015 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 19/32 20130101;
G16H 40/20 20180101; G06F 16/248 20190101; G06F 16/972 20190101;
G16H 50/50 20180101; G16H 70/60 20180101; G06F 16/24573
20190101 |
International
Class: |
G06F 19/00 20060101
G06F019/00 |
Claims
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 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.
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
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.
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; 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.
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.
Description
[0001] 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
[0002] 1. Field of the Invention
[0003] The present application is directed to electronic health
recordkeeping.
[0004] 2. Description of the Related Art
[0005] 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."
[0006] 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.
[0007] 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.
[0008] 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.
[0009] What are needed are a system and method that address one or
more of these challenges.
BRIEF SUMMARY
[0010] 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.
[0011] 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
[0012] FIG. 1 is one depiction of a system for including a medical
classification code in a computer application.
[0013] 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.
[0014] FIG. 3 is an exemplary screenshot of the implementing
application and widget, depicting options for refining a query.
[0015] FIG. 4 is an exemplary screenshot of the implementing
application and widget, depicting one or more attributes for
further refining a query.
[0016] FIG. 5 is an exemplary screenshot of the implementing
application and widget, depicting results of a refined query.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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
[0023] 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.
[0024] 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.
[0025] Request
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] Processing
[0033] 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.
[0034] Return
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
* * * * *