U.S. patent application number 15/458711 was filed with the patent office on 2017-06-29 for system and method for problem list reconciliation with care plan generation in an electronic medical record.
The applicant listed for this patent is Intelligent Medical Objects, Inc.. Invention is credited to Alex Burck, Regis Charlot, Emma Lee Foley, Jonathan Gold, Jose A. Maldonado, Fred Masarie, Frank Naeymi-Rad, Ivana Naeymi-Rad, Steven Rube, Emil Setiawan, James Thompson, Yun Wu.
Application Number | 20170185718 15/458711 |
Document ID | / |
Family ID | 53882469 |
Filed Date | 2017-06-29 |
United States Patent
Application |
20170185718 |
Kind Code |
A1 |
Naeymi-Rad; Frank ; et
al. |
June 29, 2017 |
System and Method for Problem List Reconciliation with Care Plan
Generation in an Electronic Medical Record
Abstract
A method for generating orders for a care plan through a problem
list in an electronic medical record or an electronic health record
includes the steps of mapping, using a computer, entries in a
problem list with a respective concept in an interface terminology,
analyzing, by a computer, each mapped entry to determine related
problem list entries, grouping related entries into one or more
categories, and aggregating a plurality of care plans relevant to
one of the categories. Care plans may include medications and labs,
and each care plan entry also may be coded with an external
terminology, such as RxNorm or LOINC.
Inventors: |
Naeymi-Rad; Frank;
(Libertyville, IL) ; Charlot; Regis; (Lake Bluff,
IL) ; Maldonado; Jose A.; (Chicago, IL) ;
Thompson; James; (St. Charles, IL) ; Masarie;
Fred; (Husum, WA) ; Naeymi-Rad; Ivana;
(Libertyville, IL) ; Burck; Alex; (Mount Prospect,
IL) ; Wu; Yun; (Arlington Heights, IL) ;
Setiawan; Emil; (Oak Park, IL) ; Foley; Emma Lee;
(Chicago, IL) ; Gold; Jonathan; (Louisville,
CO) ; Rube; Steven; (Lake Forest, IL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Intelligent Medical Objects, Inc. |
Northbrook |
IL |
US |
|
|
Family ID: |
53882469 |
Appl. No.: |
15/458711 |
Filed: |
March 14, 2017 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14530727 |
Nov 1, 2014 |
|
|
|
15458711 |
|
|
|
|
61943109 |
Feb 21, 2014 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G16H 10/60 20180101 |
International
Class: |
G06F 19/00 20060101
G06F019/00 |
Claims
1. A method for generating orders for a care plan through a problem
list in an electronic medical record or an electronic health
record, comprising: mapping, using a computer, entries in a problem
list with a respective concept in an interface terminology;
analyzing, by a computer, each mapped entry to determine related
problem list entries; grouping related entries into one or more
categories; and aggregating a plurality of care plans relevant to
one of the categories.
2. The method of claim 1, wherein the plurality of care plans
comprises one or more medications.
3. The method of claim 2, wherein each medication is encoded with
an RxNorm code.
4. The method of claim 1, wherein the plurality of care plans
comprises one or more laboratory tests.
5. The method of claim 4, wherein each laboratory test is encoded
with a Logical Observation Identifiers Names and Codes code.
6. The method of claim 1, further comprising: ranking each of the
plurality of care plans; and displaying a ranked list of the
plurality of care plans.
7. The method of claim 6, wherein the ranking is based on at least
one of: severity, timeliness, and alphabetical order.
8. The method of claim 1, wherein, prior to the aggregating step,
each care plan is pre-mapped to a respective one or more problem
list entries.
9. The method of claim 8, wherein the pre-mapping step involves
mapping each care plan to a respective concept in the interface
terminology and cross-checking those mapped concepts with the
interface terminology concepts to which the problem list entries
are mapped.
10. The method of claim 1, wherein the grouping step includes
analyzing semantic distances between concepts mapped to the problem
list entries.
11. The method of claim 10, wherein, based on the semantic
distances, certain problem list entries are clustered as a subset
within a parent entry.
12. The method of claim 11, wherein clustered entries are stored as
a list of elements in a flat file database, with each element
pointing to the parent entry.
13. The method of claim 11, wherein clustered entries are stored as
a tree in a hierarchical database structure underneath a respective
parent entry element.
14. A method for generating orders for a care plan through a
problem list in an electronic medical record or an electronic
health record, comprising: mapping, using a computer, entries in a
problem list with a respective concept in an interface terminology;
analyzing, by a computer, each mapped entry to determine related
problem list entries; grouping related problem list entries into
one or more categories; mapping, using a computer, a plurality of
care plans to at least one respective concept in the interface
terminology; and linking care plans to problem list entries via
matching interface terminology concepts.
15. The method of claim 14, further comprising: aggregating all
care plans linked to problem list entries that are grouped into one
of the categories.
16. The method of claim 15, further comprising: upon selection of a
problem list entry, displaying all care plans aggregated for the
category to which the problem list entry is grouped.
17. The method of claim 14, wherein the plurality of care plans
comprises one or more medications.
18. The method of claim 17, wherein each medication is encoded with
an RxNorm code.
19. The method of claim 14, wherein the plurality of care plans
comprises one or more laboratory tests.
20. The method of claim 19, wherein each laboratory test is encoded
with a Logical Observation Identifiers Names and Codes code.
Description
[0001] This application is a continuation of U.S. application Ser.
No. 14/530,727, filed Nov. 1, 2014, which claims priority to U.S.
provisional application 61/943,109, filed Feb. 21, 2014, which is
incorporated herein by reference.
BACKGROUND OF THE INVENTION
[0002] Patient electronic medical records (EMRs) are used to store
a patient's medical history in one location. EMRs permit more
complete recordkeeping, which may lead to improved patient care, as
healthcare professionals may be able to quickly and thoroughly
review the patient's previous and current medical conditions in one
location. EMRs also may facilitate portability of healthcare
records.
[0003] As computer use has become more prevalent, electronic health
records or electronic medical records (EHRs or EMRs) have become
the industry standard for documenting patient care. Industry
initiatives and government legislation have facilitated EHR
implementation and use. Most notable among them is the Health
Information Technology for Economic and Clinical Health Act (HIT
ECH), which gives incentives to providers toward implementation and
demonstration of meaningful EHR use.
[0004] An aspect of reliable and accurate information is ensuring
that providers have the ability to capture their clinical
intentions regarding patient care through terminologies. Healthcare
terminology has long been called "the language of medicine," but,
in the electronic age, this language has to be readable by both
humans and computers. Various terminologies are used in defining
associated terms.
[0005] Terminology
[0006] Terminology is a set of descriptions used to represent
concepts specific to a particular discipline. It also is the
foundation of EHR data. For example, the terms "heart attack" and
"MI" describe the same concept of myocardial infarction. The
concept in turn may be associated with codes that are used for a
variety of purposes.
[0007] Different healthcare terminologies may have their own unique
features and purposes. For example, one set of terminologies,
RxNorm, encodes medications, while another set of terminologies,
e.g., Logical Observation Identifiers Names and Codes (referred to
under the trademark "LOINC"), is used for laboratory results.
[0008] Terms related to terminology include: Administrative code
sets; Clinical code sets; and Reference terminologies.
[0009] Administrative code sets may be designed to support
administrative functions of healthcare, such as reimbursement and
other secondary data aggregation. Common examples are the
International Classification of Disease (ICD) and the Current
Procedural Terminology, which is referred to via the trademark CPT.
Each system may be different, e.g., ICD's purpose is to aggregate,
group, and classify conditions, whereas CPT is used for reporting
medical services and procedures.
[0010] Clinical code sets have been developed to encode specific
clinical entities involved in clinical work flow, such as LOINC and
RxNorm. Clinical code sets have been developed to allow for
meaningful electronic exchange and aggregation of clinical data for
better patient care. For example, sending a laboratory test result
using LOINC facilitates the receiving facility's ability to
understand the result sent and make appropriate treatment choices
based upon the laboratory result.
[0011] A reference terminology may be considered a "concept-based,
controlled medical terminology." The Systematized Nomenclature of
Medicine Clinical Terms (referred to under the trademark "SNOMED
CT") is an example of this kind of terminology. It maintains a
common reference point in the healthcare industry. Reference
terminologies also identify relationships between their concepts.
Relationships can be hierarchically defined, such as a parent/child
relationship. The reference terminology contains concept A and
concept B, with a defined relationship of B as a child of A. SNOMED
CT includes concepts such as heart disease and heart valve
disorder, and their defined relationship identifies heart valve
disorder as a child of heart disease.
[0012] Reference terminology may allow healthcare systems to get
value from clinical data coded at the point of care. In general,
reference terms may be useful for decision support and aggregate
reporting and may be more general than the highly detailed
descriptions of actual patient conditions. For example, one patient
may have severe calcific aortic stenosis and another might have
mild aortic insufficiency; however, a healthcare enterprise might
be interested in finding all patients with aortic valve disease.
The reference terminology creates links between "medical concepts"
that allow these types of data queries.
[0013] One method of managing these various terminologies may
involve generating an interface terminology configured to capture
each user's clinical intent. The reference terminology may include
a plurality of domains (problem, plan, medication, etc.), a
plurality of unique concepts within each domain, and one or more
descriptions mapped to each concept, where each description
represents an alternative way to express a concept, and where each
description captures various users' clinical intent. Exemplary
methods for managing multiple terminologies through the use of an
interface terminology may be found in the commonly owned U.S.
patent application Ser. No. 13/660,512, the contents of which are
incorporated herein by reference.
[0014] While EHRs aggregate patient information into a single
location, they may suffer from information overload. For example,
an EHR may include a patient problem list. Every time the patient
indicates that he or she has a problem, that problem may get added
to the patient list, causing the list to grow. Other types of
additions include automated additions or additions to the problem
list from multiple caregivers given access to modify the same list.
Over time, this list may contain many entries, including duplicate
problems, inaccurate problems, and outdated or resolved
problems.
[0015] Similarly, because the problem list includes all of the
patient's stated problems, it may contain information that, while
current and unique, may not be that useful to the practitioner,
particularly when the practitioner is a specialist. At the same
time, the problems that actually are most useful to the
practitioner may be overlooked or otherwise missed when the
practitioner is reviewing the entire problem list.
[0016] In addition, while one of the benefits of an EMR is record
portability, difficulties may arise when problem lists from
multiple sources are combined, particularly if those lists come
from different types or formats of EMRs, or contain problems that
are represented within multiple different reference
vocabularies.
[0017] What are needed are a system and method that address one or
more of the issues presented above in order to present a clearer
picture of the patient's problems.
BRIEF SUMMARY OF THE INVENTION
[0018] In one aspect, a method for generating orders for a care
plan through a problem list in an electronic medical record or an
electronic health record includes the steps of mapping, using a
computer, entries in a problem list with a respective concept in an
interface terminology, analyzing, by a computer, each mapped entry
to determine related problem list entries, grouping related entries
into one or more categories, and aggregating a plurality of care
plans relevant to one of the categories.
[0019] In another aspect, a method for generating orders for a care
plan through a problem list in an electronic medical record or an
electronic health record includes the steps of mapping, using a
computer, entries in a problem list with a respective concept in an
interface terminology, analyzing, by a computer, each mapped entry
to determine related problem list entries, grouping related problem
list entries into one or more categories, mapping, using a
computer, a plurality of care plans to at least one respective
concept in the interface terminology, and linking care plans to
problem list entries via matching interface terminology concepts.
The method also may include aggregating all care plans linked to
problem list entries that are grouped into one of the categories.
Additionally, upon selection of a problem list entry, the method
may include displaying all care plans aggregated for the category
to which the problem list entry is grouped.
[0020] In either aspect, the care plans may include one or more
medications, which may encoded with an RxNorm code. Additionally or
alternatively, the care plans may include one or more laboratory
tests, which may be encoded with a Logical Observation Identifiers
Names and Codes (LOINC) code.
[0021] Problem list elements already may be tagged or coded with
one or more terminologies, including administrative, clinical, and
reference terminologies. The method may include determining a
mapping between these terminologies and interface terminology
concepts in order to determine which interface terminology concepts
apply.
[0022] Features and advantages are described in the following
description, with reference to the accompanying drawings.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
[0023] FIG. 1 is a depiction of a method of reconciling a general
problem list into one or more clinical categories based on concept
groupings. In this case the concept group is related to clinical
specialties such as Gastroenterology or Cardiovascular. Many
different concept groupings can be enabled using the methods
described.
[0024] FIG. 2 is a depiction of exemplary relationships between
problem list elements within a clinical category and an example of
how problems can be nested together or seen in full detail.
[0025] FIG. 3 is a depiction of problem lists from different
sources, illustrating differences in the way in which problem list
elements are arranged and displayed.
[0026] FIG. 4 is a depiction of the reconciliation of elements of
multiple problem lists into a single, unified list.
[0027] FIG. 5 illustrates two separate problem lists side-by-side,
the lists requiring reconciliation, but the entries in the lists
being seemingly rather different from one another.
[0028] FIG. 6 illustrates the two lists mapped on top of one
another, with duplicates highlighted in a first fashion and
non-duplicates highlighted in a second fashion.
[0029] FIG. 7 is a depiction of a reconciled problem list created
from the two lists in FIG. 5 using the methods described.
DETAILED DESCRIPTION
[0030] As seen in FIG. 1, a method for processing electronic
medical record problem lists may be employed to generate a
clinically relevant patient profile. In one aspect, the patient
profile may be useful to a clinician because it may categorize and
group related problems according to concept groupings, and
groupings may be determined based on semantic distance between the
represented concepts. For example, all cardiovascular problems may
be grouped under a "cardiovascular" category, all kidney-related
problems may be grouped under a "renal" category, etc.
[0031] In addition, the system may attach indicator flags to the
problems within each category, which may permit later ranking and
ranked display of the problems according to attributes, such as
severity, timeliness, or other concepts such as classification
within a clinical measure. One example of such a flag is seen in
FIG. 2, in which the problem "Diabetes mellitus" and the related
problems clustered underneath that summary problem are marked with
a CQM flag. The system may apply an indicator flag to the summary
problem if any of its clustered problems (as that term is discussed
in greater detail below) include the flag.
[0032] The CQM, i.e., Clinical Quality Measurement, flag indicates
that its associated problem element must comply with CQM
requirements for treatment and documentation in order to be
eligible for the reimbursements provided for such compliance. Thus,
a problem having this flag may be presented to the user as a higher
value or higher priority problem element. In addition to having the
flag callout, this flag also may be used as a factor in problem
list ranking. For example, CQM problems may be ranked and presented
higher on the problem list within each category than other,
non-flagged problem elements.
[0033] Other potential flags may include HCC (Hierarchical
Condition Category), CC (Complication and Comorbidity), and MCC
(Major Complication and Comorbidity). One of ordinary skill in the
art would appreciate that values associated with these terms are
reflective of the severity of their underlying problems. As such,
problems flagged with one or more of these flags may provide a
visual indicator to the user that they may need to be addressed
with higher priority than other problems on the list.
[0034] Returning to FIG. 1, multiple criteria in addition to the
indicator flags may be applied to the problems in order to
determine the rankings within these lists. For example, problems
that are associated with/require medication may be ranked higher
than those that are/do not. Problems that are entered by a
physician/clinician may be ranked higher than those that are
sourced from other entities later in the record review process,
e.g., by a coder or other administrative personnel. Problems that
are obtained from workflow or some other outsider source, e.g.,
those problems that may be extracted from review of the patient's
chart may rank somewhere in between clinician- and coder-generated
problems (assuming all other factors are the same). Problem entries
may be time-stamped, such that more recent problems may be ranked
higher than older problems.
[0035] The clinicians viewing the problem list then can see the
problems that pertain to their specialty quickly and easily, e.g.,
a cardiologist can look for the cardiovascular category and then
focus on its entries. In one aspect, the clinician may be able to
set up a filter to display preferred problems or categories of
problems, while excluding non-selected problems or categories from
being displayed. In another aspect, clinicians may pre-establish a
profile that includes details about their preferred practice
area(s). Upon logging-on to the system, the clinician's personal
information may be retrieved. When the clinician selects a
patient's record, the system then may cross-check the clinician's
profile with each of the categories of problems. The system then
may display one or more problems or categories of problems that
match that clinician's profile. In either case, the filter may
function to bring a specialty-based problem view to the front of
the clinician's review.
[0036] Other filters may include the option to show an expanded
list that shows every problem in a category vs. a summary or nested
list that shows the highest level problem for a group of problems
within a category, with the other problems being closed off or
otherwise hidden from view.
[0037] The system also enables identification of potentially
sensitive problems, so that the EHR can mark them for special
treatment such as a secondary layer of privacy for viewing, or
special attention by the clinician who has access to the Problem
List. Examples of "sensitive" problems include, e.g., HIV and
mental illness. Marking a problem as sensitive may allow it to be
masked from some users, thereby restricting access only to those
who are authorized.
[0038] The system also may generate lists in order to call
attention to problems that may require more immediate attention or
problems that may affect multiple disciplines. For example, another
possible category may be an "in focus now" category, which may
display those problems currently most relevant to the user,
regardless of whether the problem also can fit into one of the
other categories described above, and a "special display" category,
which may list high priority problems of extreme, immediate
importance, or of problems which are always part of the patient's
overall baseline health state. These problems may be categorized
more specifically, but they may have effects that cross
disciplines, such that the clinician may desire to know about them
when addressing the specific problems within his or her
discipline.
[0039] In another aspect, it may be desirable to refine the problem
list by eliminating redundancies or categorizing which problems are
resolved vs. which ones are chronic or ongoing, etc. The same or
similar ranking criteria as those described above with regard to
problem entries within each category may be applied to the problem
list as a whole in order to rank the entries, regardless of
categorization. Alternatively, the category that may apply to a
particular problem also may serve as a criterion in this ranking
analysis, e.g., a cardiac or neurological problem may be ranked
higher than an orthopedic one.
[0040] The system may display or output each tagged problem using
description elements within the interface terminology, i.e.,
alternative ways to express the concept, because this may better
express clinical intent, particularly the intent of the entity that
created the problem/added the problem to the patient's list.
[0041] The system also may include a map between the various
concepts within the interface terminology and with elements of
other, external terminologies and vocabulary datasets, such as
ICD9, ICD10, SNOMEDCT, MeSH, and Clinical Quality Measure elements,
etc. These mappings may be precompiled such that the system may
avoid needing to remap relationships between interface terminology
elements and the external sets when dealing with additional problem
lists, e.g., the lists of other patients.
[0042] This mapping may serve as the basis for the categorization,
grouping, rolling up, nesting, etc., of the entries in a problem
list. Certain interface terminology concepts may be related to
other interface terminology concepts based on similar subject
matter. For example, there may be a plurality of concepts that
pertain to cardiac conditions. Thus, all problems that map to these
concepts may be grouped together for categorization and display
such as that shown in FIG. 1.
[0043] In addition to the ranking or sorting criteria describe
above, these outside vocabulary mappings may be an additional
factor used to rank the problem list entries. For example, mappings
to some established terminologies or vocabularies may be used to
perform the mapping/grouping described in the previous paragraph,
and mappings to a second terminology or vocabulary or a proprietary
mechanism may be used to sort more specifically within the
determined categories.
[0044] Turning now to FIG. 2, it will be seen that certain problems
not only fall within the same category as other problems but that
they also may be considered subsets of another problem, i.e., they
may be clusters within that problem. These relationships can be
determined and managed by using the interface terminology, which
also may recognize that certain concepts are more general than
others and thus are hierarchically related to those other concepts.
The system may group these more specific concepts underneath the
more general, parent concept, thereby further arranging the problem
list, whose entries may be mapped to these sub-concepts. As it
relates to presentation of these problem list entries, the system
may display in the problem list the problem that maps to the more
general, parent concept and an indicator that other problem entries
are nested or clustered and may be viewable under that parent
problem, e.g., by clicking on the indicator.
[0045] In one aspect, clustered problem elements underneath a more
general, parent concept may be ranked or organized using one or
more of the criteria discussed above for ranking elements within
the problem list generally. Alternatively, as seen in FIG. 2,
clustered problem elements may be arranged using a more simplistic
algorithm, e.g., they may be arranged alphabetically. In still
another aspect, the system may rank flagged problems above
non-ranked problems and then apply the more simplistic algorithm
within each of those subsets. In any event, the system may allow
user customization, permitting the user to rearrange the ordering
of elements both in the problem list and within the clustered
subsets, as discussed below.
[0046] From a database management perspective, clustered problems
may be stored as a list of elements in a flat file database, with
each element pointing to its parent problem element. Alternatively,
clusters may be sub-trees in a hierarchical database structure
underneath their respective category elements.
[0047] To this point, the patient list has been described as being
patient specific, i.e., each patient has his or her own list, with
entries specific to that patient in order to accurately record the
patient's problem history. The system and method may function
similarly as a way to bring a clearer clinical picture for a
population aggregator, i.e., determining what problems exist for a
given population, or for a given patient who may have multiple
problems culled from multiple sources within a large data
warehouse. In that case, the number of problems in the aggregated
list may be larger (likely significantly larger) than for an
individual record within an EHR, although the methodology may
remain the same, i.e., each problem may be mapped to an interface
terminology concept, concepts may be grouped and ordered, and the
ordered problems then may be available for logical display and
analysis.
[0048] As seen in FIG. 3, and as discussed above, another issue
with problem lists may become evident when attempts are made to
combine lists from multiple different sources. These sources may
format, store, and/or represent elements in the list differently
from one another and not in a consistent format.
[0049] In order to accomplish reconciliation of elements within a
single list (i.e., grouping problems within a list into categories
and establishing clusters within those categories, which may or may
not include the step of combining elements from multiple problem
lists into a single list), the system may create an anchoring term
from an interface terminology foundation technology that permits
creation of a semantic distance between any two other terms from
external vocabularies. This anchoring term may be considered a
central concept within an interface terminology. In one aspect,
determining this anchoring term may be achieved by a concept
tagging method, and examples of such a method may be found in the
commonly-owned co-pending U.S. application Ser. No. 13/004,128, the
contents of which also are incorporated by reference.
[0050] For example, the process may comprise populating a database
with a plurality of distinct concepts, populating a database with a
plurality of descriptions, relating each description to a
respective concept, reviewing the content (e.g., the problem list
elements) for a satisfactory description match; and creating a tag
for the satisfactory description match. Concepts may be
well-defined clinical findings, i.e., items that are distinct by
nature. Descriptions may comprise a plurality of words. Factors for
determining whether the match is satisfactory may include whether
there is a textual match between a portion of the content and the
description and a distance between words in the content, the words
corresponding to discrete words of each description.
[0051] Each concept may be part of a tree or hierarchy of other
concepts, i.e., each concept preferably may have, at most, one
parent concept, although it also may have multiple child concepts.
A "Knee Pain" concept (term) may be expanded semantically to
parent/child clinical concepts, including semantic distance that
will help build the problem list ranking. For example, knee pain
may be connected up to the broader concept of joint pain, which may
be connected to musculoskeletal pain. Similarly, knee pain may be
connected down to the more specific concepts of anterior knee pain
and knee joint, painful on movement. This semantic difference may
be expressed in terms of discrete positive or negative values away
from the concept.
[0052] The heuristic that determines a problem's final ranking may
be a function of description frequency and description presence
factor, as well as the semantic difference or distance from other
descriptions. Because multiple descriptions may relate to a shared
concept, description frequency may be a compound value of all
occurrences of all description variances of a shared concept, here,
e.g., the concept of "Knee Pain." Relatedly, a term presence factor
may reflect how "close" or "loose" a potential concept match may
be. For example, the phrase "knee pain" may have a high term
presence factor for the concept "knee pain," whereas the phrase
"pain under kneecap" may have a lower term presence factor,
reflecting the difference in terminology and inference that is
required to make the match.
[0053] Thus, each problem list element is analyzed and tagged with
a description that represents the clinical intent behind that
element, the description being part of an interface terminology and
mapping within that terminology to a concept, thereby normalizing
the problem list elements. The problems then may be analyzed, using
those concept tags, to determine if any relationship exists among
them, e.g., whether they represent duplications or related concepts
(broader than/less than/subset of), or whether they are unrelated.
Once analyzed, the elements may be grouped and ranked as described
above, for presentation to and review by the user.
[0054] Turning now to FIG. 4, the method may include incorporating
and reconciling problem lists from multiple sources, e.g., from
multiple EHR sources or from an EHR and from a Consolidated
Clinical Document Architecture (CCDA) source. This latter case may
be particularly useful in order to comply with Meaningful Use,
Stage 2 (MU2) requirements, which require the ability to
incorporate and reconcile an inbound CCDA problem list with the
home EHR list. In still another example, the secondary list needing
reconciliation may be generated by Natural Language Processing
(NLP) suggestions.
[0055] As with a single problem list, the final product may be an
ordered, categorized, clinical problem list. In addition to this
ordering, however, the system may determine and reconcile conflicts
or redundancies between multiple lists. Reconciliation may require
the steps of: identifying which problems are identical; identifying
which problems are closely related; and creating a mechanism to
incorporate, preferably rapidly and accurately, reject, or refine
both sets of problems into a new clinical set.
[0056] In this aspect, tools similar to those described above may
be used to reconcile the multiple problem lists. For example,
problems in each list may be tagged using a common interface
terminology. Once this commonality has been established, the
entries from the two lists may be combined into a single list using
the interface terminology mappings as a guidebook.
[0057] One advantage of this type of reconciliation is that one of
the two lists already may include mappings between the problems and
some kind of code set. For example, the CCDA-structured problem
list that complies with MU2 may have its problems coded with
SNOMED-CT codes. As such, the analysis of the problems in that list
may be simplified, because it may be easier to map the SNOMED-CT
codes to interface terminology concepts than to do a mapping
between the text of the problem and the interface terminology.
[0058] In addition, while this automated procedure may be able to
reconcile problem lists with a high degree of accuracy and
completeness (e.g., between about 90% and about 95%), the system
may benefit from a human interaction component. As such, the system
may include a package of refinement tools that may permit a user,
e.g., a clinician that has the experience and knowledge, to
evaluate potentially similar entries and determine what, if any,
relationship might exist between those entries. For example, the
user may be able to move an entry from one category into another,
from no category to an existing category, or from an existing
category into either a new category or into an undefined area. The
user also may able to move the entry around within the category,
e.g., moving it up or down to reflect a higher or lower priority,
respectively, or determining that it belongs as a subentry of an
already-existing problem.
[0059] FIG. 5 shows one example of two lists for reconciliation
side-by-side, e.g., an EHR list and a CCDA list for import. FIG. 6
then shows a presentation layer implementing one example of the
reconciliation strategy. This presentation layer depicts the
entries from the EHR as the left-justified items and the CCDA
entries as the right-justified items. In addition, the system
analyzes the data sets to determine whether, once the problems have
been mapped to the interface terminology concepts, there are any
duplicates. If so, the presentation layer may alert the user to the
existence of the duplicates, e.g., by locating the duplicate next
to the problem it matches and by graying it out or otherwise
indicating that it should remain in that location and not be moved
elsewhere.
[0060] In addition, the system may flag non-duplicates, e.g., with
the indicator arrows shown in FIG. 6. As can be seen, the system
already automatically may have determined that the non-duplicates
belong in certain categories. In this case, the presentation layer
may be used by the user to move the non-duplicates, either within
the categories in which they were placed or to a different category
altogether.
[0061] Turning now to FIG. 7, a reconciled problem list is shown,
with the multiple lists combined into a single, comprehensive
problem list. New entries may be shown in boldface or otherwise may
be highlighted to alert the user to the additions. In addition,
different term sets may be used on the problem list and may be
presented to the user. In one aspect, the system may display the
problems using the interface terminology concept labels that were
applied to the problem entries. However, the system may also give
the user an option to display the terms as they appeared in the
lists prior to reconciliation, as those terms may more accurately
reflect the clinical intent of the individual that generated the
problem. In that case, the interface terminology mapping may remain
in the background, such that the interface terminology terms may
not be exposed to the end users.
[0062] The system may function as a separate widget or application
accessible by an EHR software package. Preferably, however, this
problem list analysis and reconciliation tool may be integrated
into the EHR package.
[0063] In still another aspect, the system may recognize that
certain combinations of problems may trigger one or more care
plans. Thus, the system may analyze the various problem list
entries to determine whether care plans are recommended and if so,
which ones. This analysis may be performed using the interface
terminology concepts tagged to each problem list element, which may
increase processing efficiency since a comparison between those
existing concepts and the various care plans may be precompiled and
only may require, e.g., a simple table lookup, instead of requiring
analysis and evaluation of non-normalized problem list terms as
entered.
[0064] In conjunction with the organized problem list, the system
then may output and display a care plan callout with indicators
referring to the associated problems. For example, each care plan
that the system recognizes may be displayed/highlighted/etc. in a
distinct color, and the problems associated with a care plan
similarly may be highlighted in the same color.
[0065] Additionally, depending on the number of problems in the
list, the system may determine that multiple care plans are
implicated. Thus, the system may rank those care plans, e.g.,
according to severity, timeliness, or other factors. Factors used
in the ranking may include one or more of those discussed above for
determining problem list rankings. In addition, the system may
analyze the problems that trigger each care plan, using the
rankings of those problems as a factor in ranking the care
plans.
[0066] While the foregoing written description enables one of
ordinary skill to make and use the same, those of ordinary skill
also will understand and appreciate the existence of variations,
combinations, and equivalents of the specific exemplary embodiments
and methods disclosed herein. The claims should therefore not be
limited by the above described embodiment and method but should be
interpreted within the scope and spirit of the invention as
claimed.
* * * * *