Note: Descriptions are shown in the official language in which they were submitted.
CA 02415013 2002-12-23
Claim Submission System and Method
2
3 BACKGROUND OF THE INVENTION
4
FIELD OF THE INVENTION
6 [0001] The present invention relates to the submission and
processing of insurance claims,
7 and more particularly to the completion of claim forms.
8
9 DESCRIPTION OF THE PRIOR ART
[0002] Currently, the insurance industry uses many different formats for
insurance claim
11 submission, including paper and electronic. Further, the insurers often
receive claim
12 submissions from a variety of sources, including patients, primary
providers, secondary
13 providers, and call centres. This distributed system of claim submission
can result in many
14 mistakes in the claim submission forms, which are detailed in nature.
One solution that is used
by insurers is to direct all claim submissions through experienced staff at
the call centres.
16
17 [0003] However, the collection and electronic submission of claim
data by the call centre
18 staff can be laborious, including selecting relevant claim data from
extensive databases. For
19 example, patient and provider infoiniation are typically contained in
detailed databases, and
retrieval of this information displayed on database interfaces can be time
consuming.
21 Furthermore, as the insurance industry progresses to on-line real-time
claim submission and
22 adjudication, the efficient capture of the claim data into the
appropriate electronic claim forms,
23 both timely and correctly, is becoming evermore critical.
24
[0004] For example, it is common that multiple providers with many
different offices treat
26 patients. Further, it is also common that each health care professional
may be employed by a
27 number of different providers and practice at a number of office
locations. This
28 interconnectivity of patient and healthcare professional information can
increase the response
29 time of the call centre personnel in sorting out the relevant claim
information from the detailed
databases.
- 1
CA 02415013 2002-12-23
1
2 [0005] It is an object of the present invention to provide a claim
submission system and
3 method to obviate or mitigate at least some of the above-presented
disadvantages.
4
SUMMARY OF THE INVENTION
6 [0006] According to the present invention there is provided a method
to request insurance
7 data for populating data fields of an electronic claim form. The method
comprises the steps of:
8 supplying a database including insurance related patient data and
provider data; associating a
9 unique identifier data field with the claim form, the unique identifier
field for directing retrieval
of the patient data and the provider data from the database, the unique
identifier data field using a
11 set of unique identifiers for relating an office location of each
specified one of the providers with
12 a respective one of the patients; entering a selected one of the unique
identifiers in the identifier
13 data field; retrieving the insurance data from the database according to
the selected one of the
14 unique identifiers; and displaying the retrieved data in the electronic
claim form; wherein the
same unique identifier is associated with both the provider and the patient of
the provider.
16
17 [0007] According to a further aspect of the present invention
there is provided a system to
18 provide requested insurance data for populating data fields of an
electronic claim form. The
19 system comprises: a database including insurance related patient data
and provider data; an
interface for accessing the database, the interface capable of displaying the
electronic claim form
21 on a display; a unique identifier data field associated with the claim
form, the unique identifier
22 field for directing retrieval of the patient data and the provider data
from the database, a set of
23 unique identifiers employable by the unique identifier data field for
associating an office location
24 of each specified one of the providers with a respective one of the
patients; and a data retrieval
protocol for displaying the insurance data according to a selected one of the
unique identifiers
26 entered in the identifier data field; wherein the same unique identifier
is associated with both the
27 provider and the patient of the provider.
28
29 [0008] According to a still further aspect of the present
invention there is provided a
computer program product to provide requested insurance data for populating
data fields of an
- 2 -
_
CA 02415013 2002-12-23
1 electronic claim fottn. The computer program product comprises: a
computer readable medium;
2 a database module stored on the computer readable medium for including
insurance related
3 patient data and provider data; an interface module coupled to the
database module, the interface
4 module capable of displaying the electronic claim form on a display; a
unique identifier module
associated with the claim form, the unique identifier module for directing
retrieval of the patient
6 data and the provider data from the database module, a set of unique
identifiers employable by
7 the identifier module for associating an office location of each
specified one of the providers
8 with a respective one of the patients; and a data retrieval module for
displaying the insurance
9 data according to a selected one of the unique identifiers used by the
identifier module; wherein
the same unique identifier is associated with both the provider and the
patient of the provider.
11
12 BRIEF DESCRIPTION OF THE DRAWINGS
13 [0009] These and other features of the preferred embodiments of
the invention will become
14 more apparent in the following detailed description in which reference
is made to the appended
drawings by way of example only, wherein:
16 [0010] Figure 1 is a diagram of a claim submission system;
17 [0011] Figure 2 shows the content of a patient/provider database
of Figure 1;
18 [0012] Figure 3 shows the contents of a dataset of the database of
Figure 2;
19 [0013] Figure 4 shows the contents of another dataset of the
database of Figure 2;
[0014] Figure 5 shows the contents of another dataset of the database of
Figure 2;
21 [0015] Figure 6 shows the contents of another dataset of the
database of Figure 2;
22 [0016] Figure 7 gives a method for operating the system of Figure
1;
23 [0017] Figure 8 is an embodiment of the interface of the system of
Figure 1;
24 [0018] Figure 9 is a further embodiment of the interface of the
system of Figure 1;
[0019] Figure 10 is a further embodiment of the interface of the system of
Figure 1;
26 [0020] Figure 11 is a further embodiment of the interface of the
system of Figure 1; and
27 [0021] Figure 12 is a further embodiment of the interface of the
system of Figure 1.
28
29 DESCRIPTION OF THE PREFERRED EMBODIMENTS
- 3 -
CA 02415013 2011-03-21
1 [0022] Referring to Figure 1, a claim submission system 10 has a call
centre 12 for
2 receiving insurance information 13 relating to insurance claims from
patients 14 and providers
3 16, such as but not limited to dentists. Once completed, the call centre
12 communicates
4 insurance claims 18 over a network 20 to a communication switch 22, which
directs the claims
18 (for example see Figure 11 for an example electronic claim form format)
over a secure
6 network 24 to an adjudication centre 26. The submission format can be an
EDI format as in
7 known in the art. The adjudication centre 26 can perform real time
adjudication of the claim 18
8 and report the adjudication results back to the patient 14 and/or
provider 16 either though the call
9 centre 12 or directly through the network 20. Patient and provider
information 27 can be supplied
to the call centre 12, upon request, from the patient/provider database 28. It
is recognised that
11 this information 27 can be used to supplement and/or otherwise pre-
populate the claim
12 information required by the call centre 12 to complete the claim 18,
such that the information
13 actively supplied by the provider 16 and/or patient 14 is minimised to
help streamline the
14 completion and processing of the claim 18. For example, preferably the
claim 18 can be
compiled by the call centre 12, and adjudicated by the adjudication centre 26
in fewer than 2
16 minutes. It is noted that the switch 22 can also direct claim
information 30 from other sources 32
= 17 to the adjudication centre 26. Further, the switch 22 could also
employ a translation module (not
=
18 shown) to reformat the claims 18, 30 to a format required by the
adjudication centre 26.
19 [0023] Referring again to Figure 1, the call centre 12 can use a
support system 304 for
retrieving the claim information 18, 27 and monitoring processing of the claim
18 by the
21 adjudication centre 26. The support system 304 can include a processor
306 coupled to an
22 interface 39. The processor 306 is coupled to a display 400 for
displaying the interface 39 and to
23 user input devices 402, such as a keyboard, mouse, or other suitable
devices. If the display 400 is
24 touch sensitive, then the display 400 itself can be employed as the user
input device 402. A
computer readable storage medium 404 is coupled to the processor 306 for
providing instructions
26 to the processor 306 to instruct and/or configure the various components
of the system 304, such
27 as but not limited to presentation of the interface 39, and the
processes related to operation of
28 interface 39. These instructions can be used to help set-up and define
the protocols and other
29 procedures related to the operation of the system 304. The computer
readable medium 404 can
- 4 -
CA 02415013 2011-03-21
1 include hardware and/or software modules such as, by way of example only,
magnetic disks,
2 magnetic tape, optically readable medium such as CD ROM's, and semi-
conductor memory such
3 as PCMCIA cards. In each case, the medium 404 may take the form of a
portable item such as a
4 small disk, floppy diskette, cassette, or it may take the form of a
relatively large or immobile
item such as hard disk drive, solid state memory card, or RAM provided in the
support system
6 304. It should be noted that the above listed example mediums 404 can be
used either alone or in
7 combination. Further, it is recognised that the medium 404 can have
instructions/data for
8 accessing the patient 14/provider 16 database 28 as required. The
interface 39 is preferably a web
9 interface for displaying the electronic claim forms.
[0024] Referring to Figure 2, the database 28 contains data sets relating
to full patient 34,
11 full provider 36, patient subset 38, provider subset 40, fee schedules
and codes 42 (could also
12 include service codes), transaction data 44 (for example history as well
as status), and others 46.
13 Accordingly, the database 28 is structured to help facilitate minimising
transaction times for the
14 claims 18, from data capture to processing to adjudication result. The
database 28 is used to
provide supplementary claim 18 data to the call centre 12 (see Figure 1) to
help reduce the
16 keying in process of claim 18 data by the call centre 12 staff, the
claim 18 data pertaining to
17 patient 14 and provider 16 details somewhat independent from the
particular insured services
18 provided to the provider 16 to the patient 14, for example such as but
not limited to during
19 patient 14 visits to the provider 16 offices. Accordingly, the data sets
34, 36, 38, 40, 42, 44, and
46 are stored in look-up tables provided and maintained by insurers 48 (see
Figure 1) and
21 providers 16 of the insured services.
22 [0025] For example, referring to Figure 3, data set 34 contains
all the patient 14 information
23 for each individual patient 52, such as but not limited to name,
address, phone, relationship,
24 certificate number of all the insured members enrolled with the insurer
48. This data set 34 is
preferably updated on a daily basis (for example) from an upload file 50 sent
by the insurer 48,
26 containing Adds/Deletes/Modifications to the patient data contained
within. Furthermore, the
27 data set 34 also lists a provider office number 54 associated with each
individual patient 52 data,
28 or multiple provider office numbers 54 if the patient 52 has insured
services provided by a
- 5 -
CA 02415013 2002-12-23
1 number of provider offices 54. It should be noted that each provider
office has a unique provider
2 office number 54 or identifier assigned. Further, each patient 52 can
have multiple provider
3 office numbers 54 assigned to each patient 52 in the dataset 34, so as to
help reduce having
4 multiple records as per patient/provider office transactions.
6 [0026] Referring to Figure 4, dataset 36 contains all provider 16
(such as but not limited to
7 dentist) information for each individual provider 56, such as but not
limited to name, provider
8 number, address, phone number, employed health care professionals, and
provider office number
9 54. It should be noted that each individual provider 56 in the data set
36 may have multiple
office locations, each with a unique provider office number 54. Similarly, the
dataset 36 can be
11 updated on a daily basis from the upload file 50 sent by the insurer 48,
containing
12 Adds/Deletes/Modifications. It should be noted that each provider 16 can
have multiple provider
13 office numbers 54 assigned to each individual provider 56 in the dataset
36, so as to help reduce
14 having multiple records as per provider/office transactions.
16 [0027] Referring to Figure 5, the dataset 38 contains information
similar information as the
17 full patient dataset 34, however the individual patients 52 are assigned
with their provider office
18 number(s) 54 attached. It should be noted that the information contained
in the dataset 38 is only
19 that required to complete the claim 18. Extraneous patient 52
information, such as but not
limited to history and validation information, may not required in the dataset
38. Accordingly,
21 each patient 52 in the dataset 38 may have more than 1 entry with
different office numbers 54
22 attached. One advantage to the different patient datasets 34, 38 is that
in the dataset 34 there
23 could be multiple patients 52 with the same last name, as compared to
the potentially limited
24 number of patients 52 with that name sorted as per provider office
number 54. Therefore, the
access and retrieval of the patient claim infoiniation from the database 28 by
the call centre 12
26 staff is facilitated, when the call centre 12 instead of the dataset 34
accesses the dataset 38. The
27 dataset 38 is also updated on a preset interval, which may be different
from the update frequency
28 of the dataset 34. Further, a format conversion protocol, as is known in
the art, could be used to
29 reformat the data contained in the dataset 34 and port this data as
updated to the dataset 38.
- 6 -
CA 02415013 2002-12-23
1 [0028] Referring to Figure 6, the dataset 40 contains similar
information as the full provider
2 dataset 36, however the individual providers 56 are assigned with their
provider office number
3 54 attached. It should be noted that the information contained in the
dataset 40 is only that
4 required to complete the claim 18. Extraneous provider 56 information,
such as but not limited
to history and validation information, may not required in the dataset 40.
Accordingly, each
6 provider professional in the dataset 40 may have more than 1 entry with
different office numbers
7 54 attached. One advantage to the different provider datasets 36, 40 is
that in the dataset 36 there
8 could be multiple providers 56 with multiple office numbers 54 with
individual associated
9 patient and professional lists. Therefore, the access and retrieval of
the provider claim
information from the database 28 by the call centre 12 staff is facilitated,
when the call centre 12
11 instead of the dataset 36 accesses the dataset 40. The dataset 40 is
also updated on a preset
12 interval, which may be different from the update frequency of the
dataset 36. Further, a format
13 conversion protocol, as is known in the art, could be used to refoitnat
the data contained in the
14 dataset 36 and port this data as updated to the dataset 40.
16 10029] Accordingly, in view of the above, the datasets 38, 40 are
sorted by provider office
17 number 54 to facilitate claim 18 information retrieval and input into
the claim 18 by the call
18 centre 12 staff. This sorting of the full patient and provider
information 34, 36 by office number
19 54 helps to reduce infoimation overload as displayed on the interface
39, thereby helping the call
centre 12 staff to straightforwardly access the required claim 18 information,
rather than
21 searching through complicated data structures and/or relying upon the
provider 16 and/or patient
22 14 to manually provide the required claim 18 data. The full datasets 34,
36 are not accessed by
23 the call centre 12 staff, unless the required patient 14 and provider 16
information are not present
24 in the datasets 38, 40. In this case, the call centre 12 can take new
patient 14 and/or provider 16
information and update the datasets 34, 36, 38, 40 before proceeding with
completing the claim
26 18 submission. Further, it is noted that rather than having separate
datasets 34, 36, 38, 40, the
27 display contents of the full datasets 34, 36, on the interface 39, could
be filtered by the office
28 number 54, by using such as but not limited to pointers of object
orientated languages, and
29 appropriate provider 56 and/or patient 52 information requested. The
patient and provider data
- 7
CA 02415013 2002-12-23
1 includes the office numbers 54, which are used by the interface 39 as
input to predefined unique
2 identifier data fields in the electronic claim forms.
3
4 [0030] Referring to Figures 1, 5, 6, and 7, data retrieval 98 of the
call centre 12 starts by first
receiving a claim request 100 from the provider 16 using their office
identifier 54, subsequently
6 used by the data retrieval protocol. The call centre 12 enters 102 the
identifier 54 into the
7 interface 39 (see Figure 8) and takes the patient name/ID. If the patient
is listed 104 with the
8 office identifier in the dataset 38, the call centre 12 retrieves 106 the
relevant patient information
9 (see Figure 9) from the dataset 38. If the patient is not listed 104 with
the office identifier in the
dataset 38, the call centre 12 searches 108 all patients with the respective
patient ID in the full
11 dataset 34, as displayed on the interface 39. The appropriate patient is
selected 110 from the full
12 list and the patient is then added 112 to the dataset 38 attached to the
appropriate office identifier
13 54. The call centre 12 then retrieves 106 the relevant patient
information from the dataset 38. In
14 the next step, the call centre 12 takes the individual provider name/ID
(such as the dentist). If the
individual provider is listed 114 with the office identifier in the dataset
40, the call centre 12
16 retrieves 116 the relevant individual provider information from the
dataset 40. If the individual
17 provider is not listed 114 with the office identifier 54 in the dataset
40, the call centre 12
18 searches 118 all individual providers with the respective individual
provider ID in the full dataset
19 36, as displayed on the interface 39. The appropriate individual
provider is selected 120 from the
full list and the individual provider is then added 122 (see Figure 12) to the
dataset 40, attached
21 to the appropriate office identifier 54. The call centre 12 then
retrieves 116 the relevant
22 individual provider information from the dataset 40.
23
24 [0031] Once the above patient and provider information is
complete, the call centre 12 then
inputs 124 the specific claim transaction details (see Figure 10) and submits
126 the claim 18 to
26 the adjudication centre 26. The adjudication centre 26 then communicates
128 the results to the
27 call centre 12, which in turn informs the provider 16. The involved call
centre 12 staff is then
28 free to take the next call 130.
29
- 8 -
CA 02415013 2013-04-19
1 100321 It should be noted that the claim submission process 98
is coordinated through use of
2 the unique provider office numbers 54 with the data retrieval protocol.
Therefore, when new
3 patients and providers are registered, each is assigned to a specific
office number 54. This office
4 number 54 is used in the electronic claim forms to reduce the amount of
information displayed
on the interface 39, so as to help the call centre 12 staff streamline the
claim 18 data capture
6 process. Further, the import of the patient/provider data 50 supplied by
the insurer 48 to the
7 datasets 34, 36 can use a formatting routine to update the datasets 38,
40 used predominantly by
8 the call centre 12 for display on the interface 39. Alternatively, a
filtering routine could be used,
9 dependent upon the office identification number 54, to access the full
datasets 34, 36 when
prompted by the call centre (initially at steps 104, 06, 114, 116 (see Figure
7)), thereby limiting
11 the amount of display data supplied to the interface 39. This filtering
effectively could display
12 the relevant patient/provider information by office number. One example
of the filtering routine
13 could use such as but not limited to pointers associated with object-
oriented languages.
14
9
