U.S. patent application number 16/988190 was filed with the patent office on 2020-11-26 for method and system for managing health care patient record data.
The applicant listed for this patent is University of Central Florida Research Foundation, Inc.. Invention is credited to Varadraj Gurupur, Xinliang Liu, Ayan Nasir.
Application Number | 20200372985 16/988190 |
Document ID | / |
Family ID | 1000005004919 |
Filed Date | 2020-11-26 |
View All Diagrams
United States Patent
Application |
20200372985 |
Kind Code |
A1 |
Gurupur; Varadraj ; et
al. |
November 26, 2020 |
METHOD AND SYSTEM FOR MANAGING HEALTH CARE PATIENT RECORD DATA
Abstract
A method for managing health care patient record data including:
associating, by a processor, native health care patient record data
of a first patient stored in a database to a plurality of data
fields, wherein the native health care patient record data of the
first patient represents the first patient's health care record;
assigning, by a processor, a relative importance weight score to
each of the plurality of data fields; and generating, by a
processor, a record strength score of the first patient's health
care record based on the relative importance weight score
assignments. The record strength score indicates a percentage of
the first patient's health care record that contains important
native health care patient record data.
Inventors: |
Gurupur; Varadraj; (Orlando,
FL) ; Nasir; Ayan; (Orlando, FL) ; Liu;
Xinliang; (Orlando, FL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
University of Central Florida Research Foundation, Inc. |
Orlando |
FL |
US |
|
|
Family ID: |
1000005004919 |
Appl. No.: |
16/988190 |
Filed: |
August 7, 2020 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15279668 |
Sep 29, 2016 |
10790049 |
|
|
16988190 |
|
|
|
|
62234792 |
Sep 30, 2015 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G16H 10/60 20180101 |
International
Class: |
G16H 10/60 20060101
G16H010/60 |
Claims
1. A method for quantitatively managing the recordation of health
care patient data, the method comprising the steps of: accessing a
digital database using one or more processors; transforming native
health care patient record data of a first patient stored in the
database, using the one or more processors, into a plurality of
parsed data fields; assigning, by the one or more processors, a
relative importance weight score to each of the plurality of data
fields, wherein the relative importance weight score is a numerical
value corresponding to the relative importance of each of the
plurality of data fields; generating, by the one or more
processors, a numerical record strength score of the first
patient's health care record, thereby converting the first
patient's health care record from qualitative data to a numerical
data set, the record strength determined based on the following
formula: RSS ( % ) = ( IW 1 ) ( X 1 ) + ( IW 2 ) ( X 2 ) + ( IW 3 )
( X 3 ) + + ( IW n ) ( X n ) i = 1 n IW 1 .times. 100 ##EQU00008##
wherein RSS is the record strength score which is a total strength
of completeness for the first patient's health care record
constrained from 0 to 100%; IW.sub.i is the importance weight of
i.sup.th data field; and X.sub.i is a binary completeness variable
for i.sup.th data field wherein 1 represents a complete data field
and 0 represents an incomplete data field; and displaying on the
graphic user interface the numerical record strength score of the
first patient's health care record, thereby conveying a
quantitative analysis of a completeness of the first patient's
health care record.
2. The method of claim 1, wherein transforming native health care
patient data further includes transforming the native health care
patient data to a standardized format based at least in part on
concept mapping.
3. The method of claim 1, further comprising a step of: generating,
by the processor, a patient database score, wherein the patient
database score is an average of record strength scores of all
patient health care records in the database; wherein the patient
database score indicates a percentage of all patient health care
records in a database that contains important native health care
patient record data.
4. The method of claim 3, wherein the patient database score is
generated pursuant to the following formula: PDS ( % ) = RSS 1 +
RSS 2 + + RSS n n ##EQU00009## wherein RSSi is the record strength
score which is a total strength of completeness for an individual
patient record constrained from 0 to 100% for an i.sup.th patient;
and n is a total number of patient records in the database.
5. The method of claim 1, further comprising a step of: generating,
by the processor, a patient subgroup score based on the average of
record strength scores of all patient health care records in a
subgroup based on a subpopulation condition; wherein the patient
subgroup score indicates a percentage of all patient health care
records in the subgroup that contains important native health care
patient record data.
6. The method of claim 5, wherein the patient subgroup score is
generated pursuant to the following formula: PSS ( % ) = RSS 2 +
RSS 2 + + RSS n n ##EQU00010## wherein RSSi is the record strength
score which is a total strength of completeness for an individual
patient record constrained from 0 to 100% for an i.sup.th patient
that meets the subpopulation condition; and n is a total number of
patient records that meet the subpopulation condition.
7. The method of claim 1, further comprising a step of: comparing
the strength of a selected data field across two or more databases
using a data field completeness score based on an average of binary
completeness variables of the selected data field in each database;
wherein the data field completeness score indicates a percentage of
all the selected data fields in each database that are
complete.
8. The method of claim 8, wherein the data field completeness score
is generated for all patients pursuant to the following formula:
DFCS k ( % ) = .SIGMA. 1 n X ik n .times. 100 ##EQU00011## wherein
Xik is a binary completeness variable for an i.sup.th patient
wherein 1 represents a complete data field and 0 represents an
incomplete data field; a k.sup.th data field, wherein k remains
constant and i iterates for individual patients; and n is a total
number of patient records.
9. The method of claim 1, further comprising a step of: comparing
the strength of a selected data field for a subgroup across two or
more databases using a data field completeness score based on an
average of binary completeness variables of the selected data field
in each database; wherein the data field completeness score
indicates a percentage of all the selected data fields in each
subgroup of each database that are complete.
10. The method of claim 19, wherein the data field completeness
score is generated for a subgroup of patients pursuant to the
following formula: DFCS k ( % ) = .SIGMA. 1 n X ik n .times. 100
##EQU00012## wherein Xik is a binary completeness variable for an
i.sup.th patient wherein 1 represents a complete data field and 0
represents an incomplete data field; a k.sup.th data field, wherein
k remains constant and i iterates for individual patients that meet
a subpopulation condition; and n is a total number of patient
records that meet the subpopulation condition.
11. A non-transitory computer-readable storage medium containing
program code for executing the following steps: providing remote
access to a database over a network through a graphical user
interface, wherein a user can store health care patient record data
in a native format dependent on a software platform used by the
user; accessing, by one or more processors, the database containing
native health care patient record data; transforming native health
care patient record data of a first patient stored in a database to
a plurality of data fields, wherein the native health care patient
record data of the first patient represents the first patient's
health care record; assigning a relative importance weight score to
each of the plurality of data fields, wherein the relative
importance weight score is a numerical value; and generating a
numerical record strength score of the first patient's health care
record based on the relative importance weight score assignments
and a binary completeness variable for each field wherein 1
represents a complete data field and 0 represents an incomplete
data field; and displaying on the graphic user interface the
numerical record strength score of the first patient's health care
record, thereby conveying a quantitative analysis of a completeness
of the first patient's health care record.
12. The non-transitory computer-readable storage medium of claim
11, further comprising program code for generating a patient
database score based on an average of record strength scores;
wherein the patient database score indicates a percentage of all
patient health care records in a database that contains important
native health care patient record data.
13. The non-transitory computer-readable storage medium of claim
12, wherein the patient database score is generated pursuant to the
following formula: PDS ( % ) = RSS 1 + RSS 2 + + RSS n n
##EQU00013## wherein RSSi is a record strength score which is a
total strength of completeness for an individual patient record
constrained from 0 to 100% for an i.sup.th patient; and n is a
total number of patient records.
14. The non-transitory computer-readable storage medium of claim
11, further comprising program code for generating a patient
subgroup score based on an average of all patient health care
records in a subgroup based on a subpopulation condition; wherein
the patient subgroup score indicates a percentage of all patient
health care records in the subgroup that contains important native
health care patient record data.
15. The non-transitory computer-readable storage medium of claim
14, wherein the patient subgroup score is generated pursuant to the
following formula: PSS ( % ) = RSS 2 + RSS 2 + + RSS n n
##EQU00014## wherein RSSi is the record strength score which is a
total strength of completeness for an individual patient record
constrained from 0 to 100% for an i.sup.th patient that meets the
subpopulation condition; and n is a total number of patient records
that meet the subpopulation condition.
16. The non-transitory computer-readable storage medium of claim
14, wherein the subpopulation condition is selected from a group
consisting of age, race, gender, and/or insurance status.
17. The non-transitory computer-readable storage medium of claim
11, wherein the record strength score of the first patient's health
care record based on the relative importance weight score
assignments, pursuant to the following formula: RSS ( % ) = ( IW 1
) ( X 1 ) + ( IW 2 ) ( X 2 ) + ( IW 3 ) ( X 3 ) + + ( IW n ) ( X n
) i = 1 n IW 1 .times. 100 ##EQU00015## wherein RSS is the record
strength score which is a total strength of completeness for the
first patient's health care record constrained from 0 to 100%; IWi
is the importance weight of ith data field; and Xi is a binary
completeness variable for ith data field wherein 1 represents a
complete data field and 0 represents an incomplete data field.
18. The non-transitory computer-readable storage medium of claim
11, further comprising program code for generating a data field
completeness score based on an average of binary completeness
variables of a selected data field in a database; wherein the data
field completeness score indicates a percentage of all the selected
data fields in the database that are complete; wherein the data
field completeness score is generated for all patients pursuant to
the following formula: DFCS k ( % ) = .SIGMA. 1 n X ik n .times.
100 ##EQU00016## wherein Xik is a binary completeness variable for
an i.sup.th patient wherein 1 represents a complete data field and
0 represents an incomplete data field; a k.sup.th data field,
wherein k remains constant and i iterates for individual patients;
and n is a total number of patient records.
19. The non-transitory computer-readable storage medium of claim
11, further comprising program code for comparing the strength of a
selected data field for a subgroup across two or more databases
using a data field completeness score based on an average of binary
completeness variables of the selected data field in each database;
wherein the data field completeness score indicates a percentage of
all the selected data fields in each subgroup of each database that
are complete; wherein the data field completeness score is
generated for the subgroup of patients pursuant to the following
formula: DFCS k ( % ) = .SIGMA. 1 n X ik n .times. 100 ##EQU00017##
wherein Xik is a binary completeness variable for an i.sup.th
patient wherein 1 represents a complete data field and 0 represents
an incomplete data field; a k.sup.th data field, wherein k remains
constant and i iterates for individual patients that meet a
subpopulation condition; and n is a total number of patient records
that meet the subpopulation condition.
20. A method for managing health care patient record data from
various independent healthcare facilities using independent
healthcare software, the method comprising the steps of: providing
remote access to at least one database over a network through a
graphical user interface, wherein each database stores health care
patient record data in a native format dependent on a software
platform used at each healthcare facility; accessing, by one or
more processors, the at least one database containing native health
care patient record data; transforming native health care patient
record data, using the one or more processors, to a standardized
format in which the native health care patient record data for one
or more patients is converted into a plurality of parsed data
fields; generating, by the one or more processors, a numerical
record strength score for the native health care patient record
data for each patient, thereby converting the native health care
patient record data for each patient from qualitative data to a
numerical data set, the record strength determined based on a
binary completeness variable for a plurality of data fields; and
displaying on the graphic user interface the numerical record
strength score of the native health care patient record data for
each patient, thereby conveying a quantitative analysis of a
completeness of the native health care patient record data for each
patient.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This nonprovisional application is a continuation of and
claims priority to nonprovisional application Ser. No. 15/279,668,
entitled "METHOD AND SYSTEM FOR MANAGING HEALTH CARE PATIENT RECORD
DATA," filed Sep. 29, 2016 by the same inventor, which claims
priority to U.S. provisional application 62/234,792 filed Sep. 30,
2015, the subject matter of which is incorporated by reference in
its entirety.
BACKGROUND OF THE INVENTION
1. Field of the Invention
[0002] The present invention is directed to methods and systems for
managing health care patient record data by evaluating the strength
and completeness of patient record data stored in health
care/medical databases through determining the existence and
relative quality of such data and performing statistical
analyses.
2. Brief Description of the Prior Art
[0003] As health care moves into the 21st century, practitioners
are moving into an era where traditionally qualitative methods of
care are being complemented with quantitative research and analysis
to better understand and solve various problems. To that end, one
important problem health care practices currently face is the
strength of their patient records and databases. While electronic
records of patient information and care are now prevalent
throughout health centers across the United States, there are few
systems in place to ensure the completeness and validity of patient
record data being stored. From basic information such as phone
numbers or email addresses to more involved information such as
family history and procedure records, there is no centralized
mechanism by which data entered by health care staff can be checked
for completeness and validity. Furthermore, there are no
centralized mechanisms by which various health care software
database packages and health center record-keeping measures can be
compared to determine advantages and disadvantages of different
systems.
[0004] Without having a mechanism that can identify strengths and
shortcomings in record-keeping procedures it becomes more difficult
to ensure the highest standard of care across health care centers.
Most importantly, these problems are being uncovered at a time
where data accuracy in health care is becoming a cornerstone for
the burgeoning field of health informatics as well as a fundamental
part of new models of health care practice. Accordingly, there is a
continued need in the art for methods and systems that can identify
strengths and shortcomings in record-keeping procedures for health
care patient record data for the purpose of better and more
accurate management of the patient record data. There is also a
need for such a system that is independent of the health care
platform used to store patient record data so that the system may
be implemented by all health care providers across all health care
platforms.
[0005] Database completeness information is also useful to identify
health care disparities. The Department of Health and Human
Services (DHHS) has found overwhelming evidence of healthcare
disparity in minority groups, including disparities in care for
cancer, cardiac disease, AIDS, asthma, and other illnesses.
Research further shows that racial and ethnic disparities in health
care exist even when insurance status, income, age, and severity of
conditions are comparable. There is also evidence in health care
decision making at multiple levels of bias against individuals
based on age, creating health care disparity for the elderly. From
a gender perspective, differences in health care expenditures and
resource utilization lead to better quality of care among females.
The underlying sources for these disparities are hard to identify.
For example, a physician's assumption of literacy among patients
disproportionately impacts minority patients, becoming a factor
leading to disparity in care.
[0006] Research also points to social sources outside of
interactions within the health care provider environment (such as
neighborhood pressures, socioeconomic circumstances, education,
segregation, impact on income, violence, and impact of segregation)
contributing to real disparities in health care provided to
minorities. These factors, often embedded and persistent
historically, complicate the ability to determine tangible sources
of disparities, ability to measure these sources' effects, and
ability to create effective solutions to these sources of
disparities. Within the provider context, "barriers in the
patient-physician relationship contribute to racial disparities in
the experience of health care." Furthermore, prejudice, clinical
uncertainty (e.g. different interpretations of symptoms from
minority patients), and stereotyping contribute as sources of
health care disparity within the medical environment.
[0007] Analyzing patient record data in terms of variance between
subpopulations is important clinically to determine areas of
incomplete information and finding asymmetries that can be
attributed to disparities in delivery of care. Current systems do
not address the collection and maintenance of health care data with
regard to identifying underlying disparities among various
subpopulations, such as those based on age, gender, and race.
Therefore, current systems fail at identifying and correcting
underlying systemic issues causing these disparities. Accordingly,
there is a need for a system that can identify variances in health
care record completeness among subpopulations.
[0008] Description of the Related Art Section Disclaimer: To the
extent that specific patents/publications/products are discussed
above in this Description of the Related Art Section or elsewhere
in this Application, these discussions should not be taken as an
admission that the discussed patents/publications/products are
prior art for patent law purposes. For example, some or all of the
discussed patents/publications/products may not be sufficiently
early in time, may not reflect subject matter developed early
enough in time and/or may not be sufficiently enabling so as to
amount to prior art for patent law purposes. To the extent that
specific patents/publications/products are discussed above in this
Description of the Related Art Section and/or throughout the
application, the descriptions/disclosures of which are all hereby
incorporated by reference into this document in their respective
entirety(ies).
BRIEF SUMMARY OF THE INVENTION
[0009] The disclosure is directed to inventive methods and systems
for managing health care patient record data by evaluating the
strength and completeness of patient record data stored in health
care/medical databases through determining the existence and
relative quality of such data and performing statistical analyses.
An embodiment can include, but is not limited to, a method and
system that is configured to (i) associate native health care
patient record data of at least a first patient representing the
first patient's health care record stored in a database to a
plurality of data fields (or other type of organization), and
examine the patient record data associated with the particular
fields, (ii) assign a relative importance weight score to each of
the plurality of data fields representing the first patient's
health care patient record data, and (iii) generate statistical
results that can be used to determine the completeness of
individual patient record data as well as the general thoroughness
of record keeping in a medical database. An embodiment can use a
component that can be customized to the settings of the particular
software package used for storing the patient record data, as well
as a Comma Separated Values (CSV) file parser to develop and read
concept maps.
[0010] Such a system (or tool), along with its various embodiments,
can be called the Data Completeness Analysis Package (DCAP), which
is a term used in this disclosure. This tool can either reside on
an individual workstation or an accessible server, each of which
can be separate from and/or directly connected to a health care
database (and can also reside on a health care database itself).
This tool was developed based on the following objectives: develop
a tool that can be used alongside and be compatible with a variety
of health care database software packages to automatically
determine the completeness of individual patient records as well as
aggregate patient records across health care centers and
subpopulations; equip the tool with robust statistical analysis
techniques to ensure that the importance of the various types of
data is accounted for; and make the tool user friendly for health
care staff to evaluate the strength of record-keeping. Based on
these objectives, the tool created was successful in applying the
statistical techniques evaluated and described in this disclosure
and was able to evaluate the strength of an actual health care
database (specifically, the HCUP SID Florida database), as
described below.
[0011] According to an aspect, a method for managing health care
patient record data includes the steps of: associating, by a
processor, native health care patient record data of a first
patient stored in a database to a plurality of data fields, wherein
the native health care patient record data of the first patient
represents the first patient's health care record; assigning, by a
processor, a relative importance weight score to each of the
plurality of data fields; and generating, by a processor, a record
strength score of the first patient's health care record based on
the relative importance weight score assignments.
[0012] According to an embodiment, the step of generating further
comprises the step of determining a record strength score pursuant
to the following formula:
RSS ( % ) = ( IW 1 ) ( X 1 ) + ( IW 2 ) ( X 2 ) + ( IW 3 ) ( X 3 )
+ + ( IW n ) ( X n ) i = 1 n IW i .times. 100 ##EQU00001##
[0013] where RSS=record strength score (total strength of
completeness for the first patient's health care record constrained
from 0 to 100%); IWi=importance weight of i.sup.th data field; and
Xi=binary completeness variable for i.sup.th data field (1
represents complete data field, 0 represents incomplete).
[0014] According to an another aspect, a non-transitory
computer-readable storage medium containing program code includes:
program code for associating native health care patient record data
of a first patient stored in a database to a plurality of data
fields, wherein the native health care patient record data of the
first patient represents the first patient's health care record;
program code for assigning a relative importance weight score to
each of the plurality of data fields; and program code for
generating a record strength score of the first patient's health
care record based on the relative importance weight score
assignments.
[0015] According to an embodiment, the program code for generating
further comprises program code for determining a record strength
score pursuant to the following formula:
RSS ( % ) = ( IW 1 ) ( X 1 ) + ( IW 2 ) ( X 2 ) + ( IW 3 ) ( X 3 )
+ + ( IW n ) ( X n ) i = 1 n IW i .times. 100 ##EQU00002##
[0016] where RSS=record strength score (total strength of
completeness for the first patient's health care record constrained
from 0 to 100%); IWi=importance weight of i.sup.th data field; and
Xi=binary completeness variable for i.sup.th data field (1
represents complete data field, 0 represents incomplete).
[0017] In accordance with a particularly advantageous aspect, a
specialized improved computer system is created as described
herein--here the devices, databases and/or systems that are
specifically structured, configured, connected, and/or programmed
to evaluate the strength and completeness of patient record data
stored in health care/medical databases through determining the
existence and relative quality of such data and performing
statistical analyses.
[0018] The transmission/transfer of data to/from systems,
databases, engines, mobile devices, or other computer based
devices/systems described in this disclosure can be via wireless
communication/transmission over a network, which can be any
suitable wired or wireless network capable of transmitting
communication, including but not limited to a telephone network,
Internet, Intranet, local area network, Ethernet, online
communication, offline communications, wireless communications
and/or similar communications means. The wireless transmission can
be accomplished through any wireless protocol/technology,
including, but not limited to, ZigBee standards-based protocol,
Bluetooth technology, and/or Wi-Fi technology. Further, this data
can be encrypted as needed based on the sensitivity of the data or
the location the database with respect to a mobile device, for
example. One system can be located in the same room, in a different
room in the same building, in a completely different building and
location from another system, or in the "cloud." The storage of the
data in the cloud can be subject to security measures, as should be
appreciated by those of skill in the art. Various alerts and
notifications can be sent to authorized users of the systems
described herein by the data transmission means described herein or
as may be known or appreciated by those of skill in the art.
[0019] The details of one or more embodiments are described below
and in the accompanying drawings. Other objects and advantages of
the present invention will in part be obvious, and in part appear
hereinafter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0020] The present invention will be more fully understood and
appreciated by reading the following Detailed Description in
conjunction with the accompanying drawings. The accompanying
drawings illustrate only typical embodiments of the disclosed
subject matter and are therefore not to be considered limiting of
its scope, for the disclosed subject matter may admit to other
equally effective embodiments.
[0021] Reference is now made briefly to the accompanying drawings,
in which:
[0022] FIG. 1 is a schematic representation of a top level patient
concept map in accordance with an embodiment.
[0023] FIG. 2 is a schematic representation of a patient master map
in accordance with an embodiment.
[0024] FIG. 3 is a schematic representation of a patient concept
map with missing entries in accordance with an embodiment.
[0025] FIG. 4 is a representation of a sample CSV document in
accordance with an embodiment.
[0026] FIG. 5 is a flow chart of a method for managing health care
patient record data in accordance with an embodiment.
[0027] FIG. 6 is a schematic representation of a patient master map
with balance scoring in accordance with an embodiment.
[0028] FIG. 7 is a schematic representation of a patient master map
with balance scoring in accordance with an embodiment.
[0029] FIG. 8 is a schematic representation of a patient map with
balance scoring in accordance with an embodiment.
[0030] FIG. 9 is a representation of a hypothetical patient DCAP
result part 1 document in accordance with an embodiment.
[0031] FIG. 10 is a representation of a hypothetical patient DCAP
result part 2 document in accordance with an embodiment.
[0032] FIG. 11 is a representation of a patient result from
hypothetical data with PSS and subgroup DFCS scores document in
accordance with an embodiment.
[0033] FIG. 12 is a representation of results of HCUP data for
balanced IWs document in accordance with an embodiment.
[0034] FIG. 13 is a representation of results of HCUP data for
unbalanced IWs document in accordance with an embodiment.
[0035] Where applicable, like reference characters designate
identical or corresponding components and units throughout the
several views, which are not to scale unless otherwise indicated.
Moreover, the embodiments disclosed herein may include elements
that appear in one or more of the several views or in combinations
of the several views.
DETAILED DESCRIPTION OF THE INVENTION
[0036] The present invention will be more fully understood and
appreciated by reading the following Detailed Description in
conjunction with the accompanying drawings, wherein like reference
numerals refer to like components.
[0037] As detailed herein, the present disclosure is directed to
embodiments of a method and system for managing health care patient
record data by evaluating the strength and completeness of patient
record data stored in health care/medical databases through
determining the existence and relative quality of such data and
performing statistical analyses. As part of the proof of concept of
embodiments described herein, but in no way limiting the
embodiments described herein in any way, health care patient record
data can be transformed into concept maps and these maps can be
used as the basis for thorough statistical analysis. Concept maps
are visual representations of data stored in a system,
traditionally used for expressing knowledge in both a declarative
and procedural sense. While most concept mapping tools have been
used to express knowledge in a teaching environment to evaluate
student learning of various topics, for the purposes of this
disclosure, concept mapping is used as a schema through which
patient record data stored could be represented and uniformly
examined independent of the platform the data was originally stored
on or other health care protocols that may make cross examinations
of data sets more difficult. These concept maps can be developed
through DCAP and then converted to CSV files. The CSV files can
then be analyzed through a parser that allows the user to determine
the strength of both individual patient records as well as the
strength of record keeping throughout a particular database.
[0038] A premise of the proof of concept of the method and system
described herein is to use concept maps as a representation of
patient record data, although the patient record data can be
represented in any manner as may be understood and/or appreciated
by one of skill in the art. Referring now to FIG. 1, there is shown
a schematic representation of a top level patient concept map in
accordance with an embodiment. While traditionally concept maps are
used to understand the knowledge set and complexity of a human
learner, in the embodiment shown in FIG. 1, concept mapping is
applied to represent patient information. This patient concept map
is generated using data stored in the health care database and
mapped using a user-developed `master map`.
[0039] Referring now to FIG. 2, there is shown a schematic
representation of a patient master map in accordance with an
embodiment. In FIG. 2, the master map is a schema that represents
all the information, both the data fields and the proper
interconnectedness amongst those data fields, the way the user
wishes them to be stored in order to be considered `complete`.
While among patient records within a health care center this master
map may be constrained by the database software used or methods of
patient data recording used by staff, when comparing data sets from
various health care centers using DCAP, the master map can be
broadened as may be desired or necessary.
[0040] Referring now to FIG. 3, there is shown a schematic
representation of a patient concept map with missing entries in
accordance with an embodiment. The example of the master map shown
in FIG. 3, a sample patient concept map with missing entries, i.e.,
not complete, and the example of a patient master map shown in FIG.
2 highlight how the concept of completeness and subsequently the
strength of individual and aggregate patient data can be
visualized. While FIGS. 2 and 3 are not comprehensive, they show
how uniform concept map representations can serve as a platform
through which basic shortcomings in patient data can be understood.
It is also important to note that while cross subgroup
relationships and other schema complexity may be useful in both
traditional educational applications and even patient record
applications. For example, address and phone number are concepts
that can be linked to both personal information and billing
information. For the purposes of this disclosure, having the
information as defined by the master map can be sufficient to
determine completeness.
[0041] Once the native patient data in a particular health care
database software package is converted into concept map
representations using a template master map, the concept maps are
converted into CSV documents. Referring to FIG. 4, a sample CSV
document is shown which includes concept labels, i.e., patient data
fields. A CSV analyzer then parses the documents to see which
fields are filled and unfilled, and then sends its results for
statistical analysis. After the relevant statistics have been
generated, e.g., individual patient records, entire database
completeness, etc., a user-friendly interface system is used to
display the results for the user.
[0042] Referring to FIG. 5, a flowchart of a basic method 100 for
managing health care patient record data is provided based on the
above description, in accordance with an embodiment. Each of the
steps of the method can be carried out by a processor associated
with DCAP and programmed/configured to carry out such steps.
[0043] Turing to step 105 of method 100, native patient record data
is stored in at least one health care database with a particular
software package and platform used for storing the patient record
data. Other health care databases can exist, which store patient
record data, and can include the same or a different software
package and platform used for storing the patient record data.
[0044] The distinct software packages and platforms can make it
difficult to relate information between different packages and
platforms. Thus, some embodiments of the invention include steps
for transforming the native data into a standardized format. The
standardized format can include the health care patient data
represented as a plurality of parsed data fields. In some
embodiments, the transformation is based on concept maps as
explained further below.
[0045] At step 110 of the method 100, a master map is developed
that represents all the information, both the data fields and the
proper interconnectedness amongst those data fields the way a user
wishes them to be stored in order to be considered `complete`. A
concept map of stored native patient data of a particular patient,
or concept maps, each of which is associated with particular
patients, is generated using the developed master map as a
template.
[0046] At step 115 of the method 100, each concept map is converted
into a Comma Separated Values (CSV) document. This conversion to a
CSV document is performed so that, at step 120 of the method 100, a
CSV analyzer can analyze and parse the CSV document(s) to determine
which data fields are filled and unfilled. At step 125 of the
method 100, the results of the CSV analysis are statistically
analyzed. At step 130 of the method 100, results of the statistical
analysis are generated and transmitted and displayed to a user on
any mobile or non-mobile computing device, for example. Further
details of the statistical analysis are set forth in further detail
below.
[0047] Advantages of embodiments, as briefly detailed above and
shown in the Figures, are illustrated by the following Exemplary
System, Uses and Functionalities description. However, the
particular components, uses, functionalities and amounts thereof
recited in this description, as well as other conditions and
details, are to be interpreted to apply broadly in the art and
should not be construed to unduly restrict or limit the invention
in any way.
[0048] In accordance with an exemplary embodiment, once the patient
data has been processed by the CSV analyzer or otherwise is
associated with a plurality of data fields or other organization
means, DCAP is programmed and/or configured to implement
statistical analysis in order to determine the completeness and
strength of the patient data. While completeness in each individual
data field can be identifiable by the presence or lack of data,
holistically analyzing an individual patient's record or an entire
database or subgroup of patients can require determining which data
fields are more important than others. With this in mind, DCAP
generates a Record Strength Score (RSS) that is based upon user
and/or computer determined input of Importance Weights (IW).
[0049] To illustrate this concept, a first example is a scenario
where each data field holds an equivalent importance and thus
equivalent IWs. A second example is a scenario where the IWs are
different. For the scoring itself, each IW ranges from 1 to 100
points, with 100 denoting maximum importance. However, any number
range can be used. For a record with all data fields of equivalent
importance, 100 points are used for each data field. It is also
important to note that while the concept map shows various grouping
concepts that organizes the data fields, such as `personal
information`, `insurance`, or `medical background`, these groupings
have no scoring. Thus, the only scoring concepts are those with
actual corresponding data fields. The scoring equation is as
follows:
RSS ( % ) = ( IW 1 ) ( X 1 ) + ( IW 2 ) ( X 2 ) + ( IW 3 ) ( X 3 )
+ + ( IW n ) ( X n ) i = 1 n IW 1 .times. 100 ( 1 )
##EQU00003##
[0050] where RSS=Record Strength Score (Total Strength of
Completeness for Individual Patient Record constrained from 0 to
100%); IWi=Importance Weight of i.sup.th data field; Xi=Binary
Completeness Variable for i.sup.th data field (1 represents
complete data field, 0 represents incomplete).
[0051] Turning to FIG. 6, a sample patient master map for balanced
scoring is shown, in accordance with an embodiment. FIG. 7 follows
with the sample patient map indicating the Binary Completeness
Variable for each field, in accordance with an embodiment. Based on
those maps and the scoring equation, the RSS for the sample patient
is 64%.
[0052] Table 1, shown below, illustrates IWs for an unbalanced RSS,
and FIG. 8 shows the new sample patient master map with modified
unbalanced IWs, while the Binary Completeness Variables for the
sample patient shown in FIG. 7 remain unchanged, in accordance with
an embodiment. The weights used are for purposes of example and
have no bearing on actual or perceived relative importance of data
fields. Based on those maps and the scoring equation, the RSS for
the sample patient is 58%, showing that these new unbalanced IWs
make this patient record `less complete`.
TABLE-US-00001 TABLE 1 Unbalanced Importance Weights for Sample
Patient Importance Data Field Weight Date of Birth 100 Address 90
Phone # 80 Email 50 Insurance Company 80 Insurance Group # 40
Insurance Policy # 30 Medical History 100 Allergies 100 Weight 70
Height 50
[0053] While there appears to be no certain answer for an optimal
scoring algorithm that can take into account various preferences
for the importance of individual patient record data fields,
implementing the RSS scoring equation in DCAP allows for the score
to be tailored to the needs of the user because it is dynamic and
modifiable. Further development and use of DCAP can also lead to
discoveries in better scoring algorithms, and the possibilities
with those improvements are elaborated upon later in this
disclosure.
[0054] Another important metric to establish is the Patient
Database Score (PDS), which defines the overall strength of all
records in the database and is the average of the various RSS
scores (Equation 2). This metric allows for comparisons between
databases to determine better record keeping software packages and
strategies. Furthermore, using database segmentation techniques,
subpopulations of patient records can be compared using the Patient
Subgroup Score (PSS), which averages the RSS scores of the patients
of interest by age, race, gender, and insurance status, for
example, and can allow for an in depth analysis of record strength
based on patient information (Equation 3). This topic is further
elaborated upon later in this disclosure.
PDS ( % ) = RSS 1 + RSS 2 + + RSS n n ( 2 ) ##EQU00004##
[0055] where RSSi=Record Strength Score (Total Strength of
Completeness for Individual Patient Record constrained from 0 to
100%) for i.sup.th patient; and n=Total number of patient
records.
PSS ( % ) = RSS 2 + RSS 2 + + RSS n n ( 3 ) ##EQU00005##
[0056] where RSSi=Record Strength Score (Total Strength of
Completeness for Individual Patient Record constrained from 0 to
100%) for i.sup.th patient that meets subpopulation condition; and
n=Total number of patient records that meet subpopulation
condition.
[0057] Individual data fields across the patient database can also
be compared using the Data Field Completeness Score (DFCS), which
averages the binary completeness variable of a specific data field
across all (Equation 4), or a subgroup of (Equation 5), patients to
determine how well one particular class of data is being recorded.
The DFCS allows for comparisons across databases and subgroups to
ensure proper patient record keeping for each data field. The
various scores and terms of importance in scoring are summarized in
Table 2, below.
DFCS k ( % ) = .SIGMA. 1 n X ik n .times. 100 ( 4 )
##EQU00006##
[0058] where Xik=Binary Completeness Variable for i.sup.th patient
(1 represents complete data field, 0 represents incomplete) and
k.sup.th data field, where k remains constant and i iterates for
individual patients; and n=Total number of patient records.
DFCS k ( % ) = .SIGMA. 1 n X ik n .times. 100 ( 5 )
##EQU00007##
[0059] where Xik=Binary Completeness Variable for i.sup.th patient
(1 represents complete data field, 0 represents incomplete) and
k.sup.th data field, where k remains constant and i iterates for
individual patients that meet the subpopulation condition; and
n=Total number of patient records that meet subpopulation
condition.
TABLE-US-00002 TABLE 2 Summary of Various Scores Produced by DCAP
Metric Definition Description Example Record Strength See Equation
1 Measures the strength Mr. John Doe's Score (RSS) of an individual
record has a 70% patients record RSS score Patient Database See
Equation 2 Measures the strength XYZ Medical Score (PDS) of the
entire patient Center's PDS Score record database at a is 50%
health care center Patient Subgroup See Equation 3 Measures the
strength The PSS Score of Score (PSS) of the patient records male
patients over of a specific the age of 55 is 95% population of the
patients seen by the health care center Data Feild See Equation 4
Measures the strength The DFCS for Completeness Score for database
of recording for a insurance Policy (DFCS) See Equation 5 specific
data field for Number is 80% for either all patients in a The DFCS
for subpoputation database or a subset height among of patients
females is 86%
[0060] Experimentation--Experimenting with Hypothetical Data
[0061] In order to build and test DCAP, first a random population
set was generated in Excel.RTM. using the same fields as shown in
FIGS. 2 and 3. The Excel random function was used to introduce
random missing fields and the file was converted into a CSV format
to be used by DCAP. In terms of specific mechanics of a DCAP
embodiment itself, DCAP is programmed and/or configured to read in
three CSV files: (1) Patient File--These are each of the patients
records in one CSV, with columns representing fields and rows
representing individual patients; (2) Template File--These are all
of the field labels (one row with multiple columns matching in
order to the fields stored in the patient file); and (3) Importance
Weight File--These are the importance weight corresponding to the
template file.
[0062] DCAP is then programmed and/or configured to take these
files, convert them to arrays, check for completeness against a
defined String variable that indicates incompleteness which can
range from a first character indicator to a blank value, and then
output the general result of the PDS for the entire database and
RSS for each patient. Each of the metrics, PDS and RSS, are also
calculated for balanced IWs so that one can compare a simple
average to the average weighted by user IWs in the Importance
Weight file. DCAP is also programmed and/or configured to
automatically generate the DFCS for each field. FIGS. 9 and 10 show
samples of this DCAP result printout, with FIG. 9 showing a sample
hypothetical patient DCAP result part 1 and FIG. 10 showing a
sample hypothetical patient DCAP result part 2.
[0063] Another aspect of DCAP involves further user input to
generate PSS scores and subfield DFCS scores. First, after DCAP has
generated the data mentioned previously, it can be programmed
and/or configured to ask a user whether they would like to generate
a PSS or subfield DFCS score. If yes, the user can then select a
field and then indicate whether the search inside the field will be
an exact text bound or a numerical range. In the case of text
bound, patients that will meet the population criteria must have an
exact match to the subfield name. For numerical bound, patients
that meet the population criteria must be within the lower and
upper bound as indicated by the user. Upon specifying the
population of interest's parameters, DCAP can be programmed and/or
configured to generate the PSS for this subpopulation. It will then
be programmed and/or configured to ask the user whether they would
like a DFCS score for that subpopulation. If yes is selected, DCAP
will be programmed and/or configured to ask for the field and then
the DFCS for that subpopulation will generate. FIG. 11 provides a
sample patient result for the hypothetical data where PSS and
subgroup DFCS were generated. The subpopulation for the sample
shown in FIG. 11 includes patients between the age of 0 and 50 and
the DFCS field is race.
[0064] In order to test DCAP on real patient data, de-identified
data from the Healthcare Cost and Utilization Project (HCUP) was
used, specifically the State Inpatient Database (SID) with 2012
data from Florida.
[0065] Due to the size of the data set, over 2 million entries, one
thousand records were randomly extracted in order to test DCAP.
Incomplete or missing data was determined based on the guide
provided by HCUP data, usually blank spaces in the CSV file. In
setting the importance weights, it was noted that many fields were
used to handle excess information. For example, there are 31 fields
for up to 31 diagnoses, so having a blank in some of those fields
is not actually resultant of missing information; therefore, the
IWs were adjusted to 0. Otherwise, importance weights were set
first to balanced and then based on general view of importance. Due
to the large number of data variables contained in the HCUP data,
the IWs have been omitted for practical purposes.
[0066] Turning to FIGS. 12 and 13, the results of the HCUP data for
the balanced IWs and unbalanced IWs respectively, are shown in
accordance with an embodiment. The PDS generated with `balanced
IWs` in the result print out incorporates fields as mentioned above
such as multiple diagnosis codes, and thus are not a good measure
of record completeness. This simple analysis of HCUP SID data in
Florida shows that (1) data is not complete to a level necessary
for proper recording of healthcare service, and (2) when the
importance of various fields is taken into consideration that
measure becomes even weaker. This data and the functionality
provided by DCAP allows for multiple areas of further exploration
that are discussed later in this disclosure.
[0067] Suggestions and Potential Areas of Further Investigation
[0068] The issue of automated veracity of patient health care data
could be investigated through common data heuristics or through
communication with a central database as a cross-reference.
Furthermore, IWs can be made less subjective and more objective
based on a panel of health professionals to ensure that the
completeness of a database is an objective measure based on widely
agreed upon standards.
[0069] More work can also be done in the area of subpopulation
completeness, and public databases such as the HCUP data provide
additional data to answer questions of health care record keeping
as it pertains to vulnerable populations. Further research and
analysis can also be conducted in automating concept map building
within DCAP for users and health care personnel to better visualize
data and understand the relative importance of different data
elements. Patient record strength, completeness, and veracity can
ultimately be linked to discrete health care outcomes issues, such
as various diagnoses codes, rates of injury, length of care,
mortality, etc.
[0070] Limitations in access to current clinical data stored in
proprietary software packages led to lack in actual testing against
various healthcare databases, but the DCAP tool provides promise in
its adaptability to various data sets and data elements. Overall,
this disclosure describes the use of real data to show the current
problem of incomplete patient data and the importance of creating
systems to ensure a high standard of data completeness. In its
development and limitations, it also builds a foundation to explore
further areas of interest and advocates work committed to making
sure that important patient data is complete and accurate.
[0071] A "module," as may be used herein, can include, among other
things, the identification of specific functionality represented by
specific computer software code of a software program that is
recorded on a computer readable medium. A software program may
contain code representing one or more modules, and the code
representing a particular module can be represented by consecutive
or non-consecutive lines of code. The computer-executable program
instructions of an embodiment of the present invention can comprise
any computer-programming language known in the art, including but
not limited to C, Java, Python, Perl, ActionScript and JavaScript,
among many others.
[0072] As will be appreciated by one skilled in the art, aspects of
the present invention may be embodied/implemented as a computer
system, method or computer program product. The computer program
product can have a computer processor or neural network, for
example, which carries out the instructions of a computer program.
Accordingly, aspects of the present invention may take the form of
an entirely hardware embodiment, an entirely software embodiment,
and entirely firmware embodiment, or an embodiment combining
software/firmware and hardware aspects that may all generally be
referred to herein as a "circuit," "module," "system," or an
"engine." Furthermore, aspects of the present invention may take
the form of a computer program product embodied in one or more
computer readable medium(s) having computer readable program code
embodied thereon.
[0073] Any combination of one or more computer readable medium(s)
may be utilized. The computer readable medium may be a computer
readable signal medium or a computer readable storage medium. A
computer readable storage medium may be, for example, but not
limited to, an electronic, magnetic, optical, electromagnetic,
infrared, or semiconductor system, apparatus, or device, or any
suitable combination of the foregoing. More specific examples (a
non-exhaustive list) of the computer readable storage medium would
include the following: an electrical connection having one or more
wires, a portable computer diskette, a hard disk, a random access
memory (RAM), a read-only memory (ROM), an erasable programmable
read-only memory (EPROM or Flash memory), an optical fiber, a
portable compact disc read-only memory (CD-ROM), an optical storage
device, a magnetic storage device, or any suitable combination of
the foregoing. In the context of this document, a computer readable
storage medium may be any tangible medium that can contain or store
a program for use by or in connection with an instruction
performance system, apparatus, or device.
[0074] The program code may perform entirely on the user's
computer, partly on the user's computer, completely or partly on
the thermal printer, as a stand-alone software package, partly on
the user's computer and partly on a remote computer or entirely on
the remote computer or server. In the latter scenario, the remote
computer may be connected to the user's computer through any type
of network, including a local area network (LAN) or a wide area
network (WAN), or the connection may be made to an external
computer (for example, through the Internet using an Internet
Service Provider).
[0075] The flow diagrams/charts/block diagrams/system architecture
diagrams in the Figures illustrate the architecture, functionality,
and operation of possible implementations of systems, methods, and
computer program products according to various embodiments of the
present invention. In this regard, each block in the
flowcharts/block diagrams may represent a module, segment, or
portion of code, which comprises instructions for implementing the
specified logical function(s). It should also be noted that, in
some alternative implementations, the functions noted in the block
may occur out of the order noted in the figures. For example, two
blocks shown in succession may, in fact, be performed substantially
concurrently, or the blocks may sometimes be performed in the
reverse order, depending upon the functionality involved. It will
also be noted that each block of the block diagrams and/or
flowchart illustration, and combinations of blocks in the block
diagrams and/or flowchart illustration, can be implemented by
special purpose hardware-based systems that perform the specified
functions or acts, or combinations of special purpose hardware and
computer instructions.
[0076] While embodiments of the present invention have been
particularly shown and described with reference to certain
exemplary embodiments, it will be understood by one skilled in the
art that various changes in detail may be effected therein without
departing from the spirit and scope of the invention as defined by
claims that can be supported by the written description and
drawings. Further, where exemplary embodiments are described with
reference to a certain number of elements it will be understood
that the exemplary embodiments can be practiced utilizing either
less than or more than the certain number of elements.
* * * * *