U.S. patent application number 13/352007 was filed with the patent office on 2012-05-10 for rule management method and system.
Invention is credited to Roy Schoenberg.
Application Number | 20120116813 13/352007 |
Document ID | / |
Family ID | 35097409 |
Filed Date | 2012-05-10 |
United States Patent
Application |
20120116813 |
Kind Code |
A1 |
Schoenberg; Roy |
May 10, 2012 |
Rule Management Method and System
Abstract
A rule processing method includes defining a target group of
patients chosen from a group of existing patients. An action to be
taken concerning one or more patients within the target group of
patients is defined, and an execution time for the action is
scheduled.
Inventors: |
Schoenberg; Roy; (Boston,
MA) |
Family ID: |
35097409 |
Appl. No.: |
13/352007 |
Filed: |
January 17, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10825352 |
Apr 15, 2004 |
|
|
|
13352007 |
|
|
|
|
Current U.S.
Class: |
705/3 |
Current CPC
Class: |
G06Q 10/00 20130101;
G16H 10/60 20180101; G16H 40/67 20180101 |
Class at
Publication: |
705/3 |
International
Class: |
G06Q 50/24 20120101
G06Q050/24 |
Claims
1-35. (canceled)
36. A rule processing computer-based method comprising: determining
by a computer, for a specific computer-executable rule that is
stored to a computer-readable medium, a target group of patients,
wherein said target group of patients comprise at least a subset of
patients for whom a particular medical service provider has an
access key that grants the medical service provider access to
medical records of the patients; determining, for said specific
computer-executable rule, an action to be initiated by the computer
concerning one or more patients within the target group of patients
whose respective medical records satisfy said specific
computer-executable rule, wherein the action comprises
communicating information to the one or more patients; determining,
for said specific computer-executable rule, an execution time for
the action; and initiating by the computer the action concerning
the one or more patients within the target group of patients on or
after the execution time.
37. The method of claim 36 wherein the action includes one or more
of: posting a HTML link for a patient; posting a message for a
patient; providing a tool to a patient; transmitting an email to a
patient; updating a patient's medical record; transmitting a pop-up
message to a patient; recommending that a patient join a discussion
board; providing a patient with medical information; providing a
medical report to a patient; providing a medical report to a third
party; executing a program; and notifying a third party.
38. The method of claim 36 wherein the execution time is a single,
non-recurring, execution time.
39. The method of claim 36 wherein the execution time is a
plurality of non-recurring execution times.
40. The method of claim 36 wherein the execution time is a
recurring execution time.
41. The method of claim 36 wherein the target group of patients is
defined by processing the medical records to determine which of the
medical records define the existence of a selected condition
specified by the specific computer-executable rule.
42. A computer program product residing on a computer readable
medium having a plurality of instructions stored thereon which,
when executed by the processor, cause that processor to: determine
from computer-based medical records of patients for whom a
particular medical service provider has an access key that grants
the medical service provider access to said computer-based medical
records, a target group of said patients whose respective medical
records satisfy a rule defined by the medical service provider;
determine an action to be taken concerning the determined target
group of patients; and schedule an execution time for the action to
be taken concerning the determined target group of patients.
43. The computer program product of claim 42 wherein the
instructions for determining said target group of said patients
whose respective medical records satisfy said rule include
instructions for processing the medical records to determine which
of the medical records define the existence of a selected condition
specified by said rule.
44. The computer program product of claim 43 wherein the selected
condition concerns a medical condition of a patient.
45. The computer program product of claim 43 wherein the selected
condition concerns a physical criteria of a patient.
46. The computer program product of claim 43 wherein the selected
condition concerns a habit of a patient.
47. The computer program product of claim 43 wherein the selected
condition concerns an activity of a patient.
48. The computer program product of claim 42 wherein the action
comprises one or more of: posting a HTML link for a patient;
posting a message for a patient; providing a tool to a patient;
transmitting an email to a patient; updating a patient's medical
record; transmitting a pop-up message to a patient; recommending
that a patient join a discussion board; providing a patient with
medical information; providing a medical report to a patient;
providing a medical report to a third party; executing a program;
and notifying a third party.
49. The computer program product of claim 42 wherein the
instructions for scheduling the execution time include instructions
for specifying a single, non-recurring, execution time.
50. The computer program product of claim 42 wherein the
instructions for scheduling the execution time include instructions
for specifying a plurality of non-recurring execution times.
51. The computer program product of claim 42 wherein the
instructions for scheduling the execution time include instructions
for specify a recurring execution time.
52. The computer program product of claim 42 further comprising
instructions for executing the action concerning the determined
target group of patients on or after the execution time.
53. A rule processing computer-based method comprising: processing,
by a record processing module, a plurality of computer-based
multi-portion medical records that are stored to a
computer-readable repository and that contain medical history
information for a plurality of patients for determining a target
group of said plurality of patients whose medical records a
particular medical service provider is authorized to access,
wherein each portion of each of the multi-portion medical records
is assigned a respective confidentiality level; processing, by a
rule processing engine, the medical records of the determined
target group of patients against a computer-executable rule defined
by said particular medical service provider to identify one or more
of said target group of patients whose medical records satisfy the
rule; determining, by the rule processing engine, an action defined
by said particular medical service provider for the rule, said
determined action to be taken concerning said identified one or
more patients within the target group of patients; and scheduling,
by the rule processing engine, an execution time for the
action.
54. The computer program product of claim 53 further comprising
instructions that when executed by the processor cause the
processor to: determine, from a plurality of computer-based medical
records stored to a computer-readable repository, ones of said
computer-based medical records for which said medical service
provider has an access key that grants the medical service provider
access to said computer-based medical records, said determined ones
of said computer-based medical records for which said medical
service provider has an access key that grants the medical service
provider access to said computer-based medical records forming a
target group of computer-based medical records.
55. The computer program product of claim 54 wherein the
instructions for processing the medical records against said rule
comprises instructions for processing said determined target group
of computer-based medical records against said rule for determining
which of the target group of computer-based medical records define
the existence of a condition specified by said rule.
56. The computer program product of claim 54 wherein said medical
service provider has an access key that grants the medical service
provider access to a portion of information contained in said
target group of computer-based medical records, and wherein the
instructions for processing the medical records against said rule
comprises instructions for processing said determined target group
of computer-based medical records against said rule for determining
from the portion of information contained in said target group of
computer-based medical records which of the target group of
computer-based medical records define the existence of a condition
specified by said rule.
57. A system comprising: a computer-readable repository for storing
medical records; an access key management system for managing
access keys that grant a medical service provider authorized access
to at least a portion of said medical records; and a rule
processing engine configured to: a) receive input from a medical
service provider to define a rule specifying criteria for selecting
one or more of said medical records to which said medical service
provider has an access key that grants the medical service provider
with authorized access; b) receive input specifying corresponding
action to take when said rule is satisfied; c) receive input
specifying a corresponding execution time for performing said
corresponding action; d) process said medical records for which
said medical service provider has an access key that grants the
medical service provider with authorized access against said rule
to determine one or more of said medical records that satisfy the
rule; and e) initiate, for patients to whom the determined one or
more medical records that satisfy the rule relate, said
corresponding action to be performed at said corresponding
execution time.
58. The system of claim 57 wherein said corresponding action
comprises communicating information to said patients to whom the
determined one or more medical records that satisfy the rule
relate.
Description
RELATED APPLICATIONS
[0001] The following U.S. patent is hereby incorporated by
reference into the subject application as if set forth herein in
full: (1) U.S. Pat. No. 6,463,417, entitled "Method of Distributing
Health Information".
FIELD OF THE INVENTION
[0002] This invention relates to rule management and, more
particularly, to rule management within a medical records
management system
BACKGROUND
[0003] Traditionally, the medical records of a patient are
paper-based medical records, in which each medical service provider
(that provides medical services to the patient) maintains a
separate medical record for that patient.
[0004] Often, patients who are within certain age brackets or have
certain conditions are uninformed of information that may be
beneficial to their particular situation. Examples of these
situations include the timing of prostate exams for men and
mammograms for women.
[0005] Unfortunately, with paper-based medical records, the medical
service provider would need to manually review the medical records
of each of their patients to determine which groups of patients
should receive medical information, come in for certain tests, or
learn about certain diseases and warning signs, for example.
[0006] Currently, paper-based medical records are slowly being
converted into electronic, centrally-located databases that are
accessible by various medical service providers.
SUMMARY OF THE INVENTION
[0007] In one implementation, a rule processing method includes
defining a target group of patients chosen from a group of existing
patients. An action to be taken concerning one or more patients
within the target group of patients is defined, and an execution
time for the action is scheduled.
[0008] One or more of the following features may also be included.
Defining a target group of patients may include processing the
medical records of the existing patients to determine which of the
medical records define the existence of a selected condition, such
as a medical condition, physical criteria, habit, or activity of a
patient.
[0009] Defining an action may include one or more of: posting a
HTML link for a patient; posting a message for a patient; providing
a tool to a patient; transmitting an email to a patient; updating a
patient's medical record; transmitting a pop-up message to a
patient; recommending that a patient join a discussion board;
providing a patient with medical information; providing a medical
report to a patient; providing a medical report to a third party;
executing a program; and notifying a third party.
[0010] Scheduling the execution time may include specifying: a
single, non-recurring, execution time; a plurality of non-recurring
execution times; or a recurring execution time.
[0011] The action concerning the one or more patients within the
target group of patients may be executed on or after the execution
time.
[0012] In another implementation, a rule processing method
includes: determining, for a specific rule, a target group of
patients. The action to be taken, for the specific rule, is
determined concerning one or more patients within the target group
of patients. Further, an execution time for the action is
determined for the specific rule. The action concerning the one or
more patients within the target group of patients is executed on or
after the execution time.
[0013] In another implementation, a rule processing computer-based
method includes processing a multi-portion medical record for each
of a group of existing patients to define a target group of
patients chosen from the group of existing patients. Each portion
of the medical record is assigned a confidentiality level. An
action to be taken is defined concerning one or more patients
within the target group of patients. An execution time for the
action is scheduled.
[0014] The above-described methods may also be implemented as a
sequence of instructions executed by a processor.
[0015] The details of one or more implementations is set forth in
the accompanying drawings and the description below. Other features
and advantages will become apparent from the description, the
drawings, and the claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] FIG. 1 is a diagrammatic view of key organization system
coupled to a distributed computing network;
[0017] FIG. 2 is a more-detailed diagrammatic view of the key
organization system of FIG. 1;
[0018] FIG. 3 is a block diagram of a key maintenance module of the
key organization system of FIG. 1;
[0019] FIG. 4 is a diagrammatic view of a key configuration display
screen rendered by the key organization system of FIG. 1;
[0020] FIG. 5 is a block diagram of a key processing module and a
record processing module of the key organization system of FIG.
1;
[0021] FIG. 6 is a diagrammatic view of a patient selection display
screen rendered by the key organization system of FIG. 1;
[0022] FIG. 7 is a diagrammatic view of a patient's medical record
rendered by the key organization system of FIG. 1; and
[0023] FIG. 8 is a block diagram of a rule processing module of the
key organization system of FIG. 1.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0024] Referring to FIG. 1, there is shown a key organization
system 10 that manages the various access keys 12, 14, 16 possessed
by a medical service provider 18. Access keys 12, 14, 16 are
provided to medical service provider 18 by various patients 20, 22,
24.
[0025] Key organization system 10 typically resides on and is
executed by a computer 26 that is connected to network 28. Computer
26 may be a web server running a network operating system, such as
Microsoft Window 2000 Server.TM., Novell Netware.TM., or Redhat
Linux.TM.. Typically, computer 26 also executes a web server
application, such as Microsoft IIS.TM., Novell Webserver.TM., or
Apache Webserver.TM., that allows for HTTP (i.e., HyperText
Transfer Protocol) access to computer 26 via network 28.
[0026] The instruction sets and subroutines of key organization
system 10, which are typically stored on a storage device 30
coupled to computer 26, are executed by one or more processors (not
shown) and one or more memory architectures (not shown)
incorporated into computer 26. Storage device 30 may be, for
example, a hard disk drive, a tape drive, an optical drive, a RAID
array, a random access memory (RAM), or a read-only memory
(ROM).
[0027] As will be explained below in greater detail, a patient
(e.g., patient 20) typically provides an access key (e.g., key 12)
to medical service provider 18 through a patient computer 32, which
is also connected to network 28. Additionally, medical service
provider 18 accesses key organization system 10 through a client
computer 34.
[0028] Referring also to FIG. 2, key organization system 10
includes a centralized key repository 50 and a centralized medical
records repository 52. Typically, centralized key repository 50
includes one or more patient key repositories 54 and one or more
MSP (i.e., medical service provider) key repositories 56.
Additionally, key organization system 10 includes a key maintenance
module 58, a key processing module 60, a record processing module
62, and a rule processing module 64, each of which will be
discussed below in greater detail.
[0029] Centralized medical records repository 52 allows for the
centralized storage of medical records 66, 68, 70 that concern
various patients 20, 22, 24 respectively. As disclosed in U.S. Pat.
No. 6,463,417, medical records 66, 68, 70 are typically divided
into portions or levels, in that certain portions are considered
more confidential than other portions. For example, a portion/level
of the medical record that may be considered the least confidential
might include general patient identification information and
information concerning the patient's blood type and allergies. A
portion/level of a medical record that may be considered to have an
intermediate level of confidentiality might include information
concerning the serological data, psychiatric data, cardiology data,
and genetic data. A portion/level of the medical record that may be
considered highly confidential may include infectious disease
(e.g., HIV, and sexually transmitted diseases) data.
[0030] This specific assignment of confidentiality levels and the
apportionment of the medical record into various portions/levels is
for illustrative purposes only and is not intended to limit the
scope of this disclosure.
[0031] Medical records 66, 68, 70 may be incrementally
generated/configured online by the various medical service
providers that provide care to patients 20, 22, 24. Alternatively,
existing medical records may be uploaded (i.e., transferred) to
medical records repository 52 from a remote storage location (not
shown).
[0032] Referring also to FIG. 3, patients 20, 22, 24 use key
maintenance module 58 to generate 100 access keys 12, 14, 16 that
grant access to various portions of their respective medical
records 66, 68, 70. Accordingly, though the use of key maintenance
module 58, the patient can generate access keys that not only
regulate who has access to their medical records, but can also
regulate the level of access (i.e., which portions of a patient's
medical record are viewable by the medical service provider to
which the key is provided). Examples of access keys 12, 14, 16 are
passwords (that allow access to various portions of a medical
record) and decryption keys (that decrypt various portions of an
encrypted medical record).
[0033] Typically, key maintenance module 58 is a web-enabled
application that is accessed by the patients (e.g., patient 20)
through a browser application (e.g., Microsoft Internet
Explorer.TM., or Netscape Navigator.TM.) that is running on patient
computer 32. Alternatively, key maintenance module 58 may be a
local application that is executed locally on patient computer
32.
[0034] As stated above, key maintenance module 58 allows a patient
to generate 100 an access key for a specific medical service
provider that grants, to that medical service provider, a defined
level of access to that patient's medical records. Once this access
key is generated, it is stored 102 on the patient key repository 54
assigned to that patient (i.e., the patient generating the access
key).
[0035] Once stored 102, the access key is transmitted 104 to the
appropriate medical service provider (e.g., medical service
provider 18). This transmission of the access key may be
implemented by transferring the access key from the patient to the
medical service provider. This may occur by attaching the access
key to an email that is transmitted to the medical service
provider. Once received, the medical service provider may then
transfer the newly-generated key to the key processing module 60
(to be discussed below in greater detail) of the key organization
system 10. Alternatively, the patient may directly transfer the
newly-generated key to the key processing module 60 of the key
organization system 10.
[0036] Referring also to FIG. 4, when a patient is generating an
access key (e.g., access key 14) for a medical service provider,
key maintenance module 58 provides the patient (e.g., patient 22)
with a rendered screen display 120 that allows the patient to
select one or more access parameters 122 that define the access
level granted to that particular medical service provider. Display
120 identifies the patient (i.e., Timothy Smith; patient 22) and
allows the patient to select the recipient 124 of the access key
being generated by the patient. In this example, the recipient 124
is Family Medical Clinic; medical service provider 18.
[0037] As stated above, medical records 66, 68, 70 are typically
divided into portions or levels, such that certain portions are
considered more confidential than other portions. The access
parameters 122 selected (i.e., checked) by the patient define the
various portions of the patient's medical record that the medical
service provider is going to have access to. In this particular
case, the access key being generated by patient Timothy Smith
(i.e., patient 22) for the Family Medical Clinic (i.e., medical
service provider 18) is going to allow the medical service provider
to access only two portions of the patient's medical record, namely
the general portion and the psychiatric data. As the remaining
access parameters are unchecked, medical service provider 18 is
going to be prohibited from accessing any other portion of the
patient's medical record. When generating the access key, the
patient selects the appropriate access parameters 122 using a mouse
pointer 126 (or some other pointing device, not shown).
[0038] Now referring to FIGS. 1, 2 and 5, regardless of the manner
in which the patient transfers the access key to the medical
service provider, the access key will ultimately be received 140 by
key processing module 60, which receives any access keys (e.g.,
keys 12, 14, 16) generated and transmitted by patients 20, 22, 24.
Once these keys are received 140, they are stored 142 on the MSP
key repository 56 within the centralized key repository 50.
Additionally, if key organization system 10 is servicing multiple
medical service providers (e.g., medical service providers 17 and
19 in addition to medical service provider 18), the received keys
are associated 144 with the appropriate medical service provider,
thus preventing the keys transmitted to a first provider from being
available to a second provider and allowing storage in the
appropriate MSP key repository.
[0039] When medical records are initially received, initially
generated, and/or edited, record processing module 62 stores 146
the medical record on centralized medical record repository 52.
Typically, medical record repository 52 is a database that allows
for the organized storage and retrieval of the medical records 66,
68, 70.
[0040] Once these medical records are stored on medical record
repository 52, record processing module 62 allows the medical
service provider 18 to access 148 the medical records 66, 68, 70
stored on medical records repository 52. However, the medical
service provider 18 is only given access to the portions of the
medical records for which the medical service provider 18 possesses
the appropriate key. For example, assume that medical service
provider 18 is a medical clinic that provides an array of medical
services to its patients. Further, assume that patient 20 uses
medical service provider 18 for all of their medical needs; patient
22 uses medical service provider 18 solely for treatment of
depression; and patient 24 uses medical service provider 18 solely
for treatment of HIV.
[0041] Concerning the access keys generated by each of these
patients for medical service provider 18: patient 20 would
typically provide medical service provider 18 with an access key
(i.e., key 12) that grants access to their entire medical record;
patient 22 would typically provide medical service provider 18 with
an access key (i.e., key 14) that grants access to the general and
psychiatric portions of their medical record; and patient 22 would
typically provide medical service provider 18 with an access key
(i.e., key 16) that grants access to the general and infectious
disease portions of their medical record.
[0042] Record processing module 62 is typically a web-enabled
application that is accessed by the medical service provider 18
through a browser application (e.g., Microsoft Internet
Explorer.TM., or Netscape Navigator.TM.) that is running on client
computer 34. Typically, medical service provider 18 logs into key
organization system 10 using an encrypted SSL (i.e., secure sockets
layer) connection.
[0043] Referring also to FIG. 6, when accessing key organization
system 10, record processing module 62 provides the medical service
provider 18 with a rendered screen display 158 that includes a list
of patient identifiers 160. Patient identifiers 160 define the
particular patient(s) who provided access keys to medical service
provider 18 (i.e., granting medical service provider 18 access to
various portions of their medical record(s)). The patient
identifiers 160 may be any element that uniquely identifies the
patient, such as the patient's name, the patient's social security
number, or a unique patient number. In this particular example,
Mary Jones is patient 20, Timothy Smith is patient 22 (as stated
above), and James Greco is patient 24.
[0044] The presence of each of these names in the list of patient
identifiers 160 indicates that a key was received from that
patient. In order to access the medical record of a patient for
which the medical service provider has an access key (i.e., for one
of the patients listed in the list of patient identifiers 160), the
medical service provider 18 selects the appropriate identifier
using a mouse pointer 162 (or some other pointing device, not
shown). For example, if the medical service provider wanted to
access the medical record of Timothy Smith (i.e., patient 22),
medical service provider 18 would typically double click (using a
mouse) on the specific identifier 164 associated with Timothy
Smith. Record processing module 62 would then, in turn, use access
key 14 to access (i.e., retrieve, decrypt, and display) medical
record 68, the medical record of Timothy Smith, i.e., patient
22.
[0045] Referring also to FIG. 7, medical record 68 may be displayed
in a separate window or displayed full screen on the display of
client computer 34. As discussed above, the key provided to the
medical service provider 18 only allows access to the portion(s) of
the patient's medical record that the patient wishes to allow
access. As discussed above, Timothy Smith (i.e., patient 22) is
being treated by medical service provider 18 for depression and
access key 14 grants access to the general and psychiatric portions
of Timothy Smith's medical record.
[0046] However, access key 14 does not permit access (i.e.,
prohibits access) to the other portions of Timothy Smith's medical
record, namely Allergies, Serological Data, Cardiology Data,
Genetic Data, and Infectious Disease Data. Accordingly, these
portions of the patient's medical record are unavailable.
[0047] Medical records (e.g., medical record 68) are typically
database records 180 that define general patient data through the
use of various data fields (e.g., data field 182), each of which
includes a field name 184 and a field value 186. Field value 186
may define an amount (e.g., a patient's systolic pressure) or a
binary condition (e.g., whether or not a patient is a smoker).
Additionally, as discussed above, the medical records include
Allergy data 188, serological data 190, psychiatric data 192,
cardiology data 194, genetic data 196, and infectious disease data
198, each of which may be further broken down into data fields.
[0048] If the manner in which a patient utilizes a medical service
provider changes, key maintenance module 58 allows a patient to
modify or revoke the access key previously provided to the medical
service provider.
[0049] Referring again to FIGS. 1, 2, 3 and 4, assume that patient
22 decides that he would like medical service provider 18 to
monitor and treat him for a heart valve defect. Accordingly,
patient 22 would want medical service provider 18 to have access to
the cardiology data portion of their medical record. Therefore,
patient 22 would use key maintenance module 58 to retrieve 106 the
patient's copy of access key 14, which is being maintained 108 on
patient key repository 54. Once retrieved, the patient can use
display 120 to modify 110 the access key by adjusting the access
parameters selected for that particular medical service provider.
Continuing with the above-stated example, patient 22 would selected
access parameter 128 (i.e., the parameter that grants access to the
cardiology data portion) using mouse pointer 126.
[0050] This modified access key (i.e., access key 14') is then
stored 102 on the patient key repository 54. Typically, the storing
102 of the amended version of the access key (i.e., access key 14')
results in the deletion 112 of the older version of the access key
(i.e., access key 14) from the patient key repository 54. However,
if desired the patient may store the amended access key as a new
access key (e.g., access key 72) without deleting the older version
of the access key (i.e., access key 14).
[0051] As with a newly-generated access key, the amended version of
the access key may be transmitted 104 to the appropriate medical
service provider (e.g., medical service provider 108). As stated
above, the medical service provider would then store amended access
key 14' on their MSP key repository 54, thus allowing the medical
service provider to access the patient's medical records with the
revised level of access. However, when a determination 114 is made
that an access key was amended (as opposed to being a new access
key), it may be desirable to reconcile 116 the key repositories.
This is due to the fact that if the medical service provider fails
to store the amended access key on their MSP key repository, the
medical service provider will continue to have the older level of
access. This could prove problematic when the patient intends to
reduce the level of access afforded to a medical service
provider.
[0052] When reconciling 116 the patient key repository 54 and the
MSP key repository 56, the access keys within the patient key
repository are compared to the access keys with the MSP key
repository. When this comparison is made, only the access keys
(within the patient key repository) that were provided to the
"intended-recipient" medical service provider are examined.
Further, concerning the access keys within the MSP key repository,
only access keys received from the "key-amending" patient are
examined.
[0053] Continuing with the above-stated example, patient 22 (i.e.,
Timothy Smith) generated amended key 14' for medical service
provider 18 (i.e., Family Medical Clinic). Therefore, all of the
keys (within patient key repository 54) that patient 22 sent to
medical service provider 18 are compared to all of the keys (within
MSP key repository 56) that medical service provider 18 received
from patient 22. Assuming that the original key 14 was deleted from
patient key repository 54, the reconciliation process would compare
amended key 14' (stored on patient key repository 54) to original
key 14 (stored on MSP key repository 56). As amended access key 14'
is newer than original access key 14, the reconciliation process
would overwrite original access key 14 (stored in the MSP key
repository) with amended access key 14' (stored in the patient key
repository). As the medical service provider is typically not
allowed to modify an access key, whenever different versions of the
same access key are present on both the MSP key repository and the
patient key repository, the MSP key repository is updated to
include the version of the access key present on the patient key
repository.
[0054] Through the use of rule processing module 64, the medical
service provider may define one or more rules for various groups of
the patients to which they provide medical services. Rule
processing module 64 allows medical service providers to defines
rules that are applied to various groups of patients to which the
medical service provider provides service.
[0055] Referring to FIGS. 1, 2, 7 and 8, processing module 64
allows the medical service provider 18 to define 220 a target group
of patients that are chosen from existing group of patients of the
medical service provider. As discussed above, these are the
patients to which the medical service provider 18 has an access key
that grants the medical service provider with access to at least a
portion of the patient's medical records.
[0056] When defining a rule, the target group of patients may be
defined in various ways. For example, the target group may be
defined as all patients (i.e., of those being cared for by the
medical service provider) that have a specific medical conditions
(e.g., high blood pressure or diabetes). Additionally, the group
may be defined as all patients that meet one or more physical
criteria (e.g., all male patients, or all female patients over the
age of fifty). Further, the group may be defined as all patients
that have a certain habit (e.g., smoking or drinking) or perform an
certain activity (e.g., joggers or skiers). Additionally, the
membership within a group may be reduced by requiring the patients
meet multiple criteria (e.g., male patients over the age of fifty
that have a family history of prostate cancer). Alternatively, the
membership within a group may be increased by requiring that the
patients only meet one of several criteria (e.g., a male patient,
or a patient over the age of fifty, or a patient with a family
history of prostate cancer).
[0057] Typically the target group is defined by processing 222 the
medical records of the existing patients that the medical service
provider provides services to. When processing these medical
records, rule processing module 64 examines the individual data
fields (e.g., field 182) included within the medical record to
determine which medical records include data fields having field
values (e.g., field value 186) that match the various target
criteria specified by the medical service provider.
[0058] In addition to defining the patients that are to be included
in the target group, the medical service provider defines 224 the
action to be taken with respect to the patients within the target
group. Examples of the types of actions that may be defined
include: posting a HTML link for a patient; posting a message for a
patient; providing a tool to a patient (e.g., a diet monitoring
software program); transmitting a email to a patient; updating a
patient's medical record; transmitting a pop-up message to a
patient; recommending that a patient join a discussion board;
providing a patient with medical information; providing a medical
report to a patient; providing a medical report to a third party;
executing a program (e.g., executing the diet monitoring software
program); and notifying a third party, for example. This list is
not meant to be all inclusive and is only meant to provide examples
of the types of actions that may be taken.
[0059] When defining a rule, the medical service provider also
schedules 226 the execution time for the action. The action may be
scheduled in various fashions. For example, the action may be
scheduled to occur once (e.g., Dec. 1, 2003), multiple times (e.g.,
on Dec. 1, 2003 and Mar. 1, 2004), or may continuously repeat
(e.g., the first of every month). Additionally, when defining a
schedule, various scheduling criteria may be combined (e.g., once a
day for a week, then once a week for a year, and then once a year
indefinitely).
[0060] When defining a rule, the medical service provider typically
uses a graphical user interface (not shown) that allows the medical
service provider to define 220 the target group, define 224 the
action, and schedule 226 the action.
[0061] Once the medical service provider defines a rule, rule
processing module 64 executes 228 the action specified by the rule,
which respect to the target group, on or after the execution time
scheduled by the medical service provider.
[0062] Rule processing module 64 is typically a web-enabled
application that is accessed by the medical service provider 18
through a browser application (e.g., Microsoft Internet
Explorer.TM., or Netscape Navigator.TM.) that is running on client
computer 34.
[0063] When a patient logs into key organization system 10 through
a browser application that is running on the patient's computer,
the patient is typically presented with a graphical user interface
(i.e., a desktop, not shown) that allows the patient to accomplish
several tasks, such as create and/or modify access keys (e.g.,
through key maintenance module 58), review their own medical
record(s), obtain web-based medical information, engage in
web-based medical chat rooms, engage in web-based medical
discussions groups, and join web-based medical forums, for example.
Additionally, depending on whether the patient is included in a
target patient group for an executed rule, the patient may be
presented with, for example: an HTML link that is posted to their
desktop; a message that is posted to their desktop message box, or
a pop-up ad that appears on the patient's desktop, for example.
[0064] While key maintenance module 58 is described above as
amending an access key to provide a medical service provider with
an enhanced level of access, other configurations are possible. For
example, the access key may be amended to provide a reduced level
of access (with respect to the original access key). Further, the
access key may be amended so that the amended access parameters do
not provide access to any portion of the patient's medical records,
effectively prohibiting the medical service provider from accessing
the patient's medical records.
[0065] While centralized key repository 50, patient key repository
54, and MSP key repository 56 are described above as being located
on a remote server, other configurations are possible. For example,
the patient key repository may be stored locally on a computer
operated by the patient. Further, the MSP key repository may be
stored locally on a computer operated by the medical service
provider. Additionally, as is known in the art, one or more of
these repositories may be distributed across multiple
computers/servers.
[0066] While rule processing module 64 is described above as
creating "global" rules that apply to all of the patients of a
medical service provider, other configurations are possible. For
example, by defining the target group for a specific rule to be an
individual patient, a "patient-specific" rule is created that
applies only to that individual patient.
[0067] A number of implementations have been described.
Nevertheless, it will be understood that various modifications may
be made. Accordingly, other implementations are within the scope of
the following claims.
* * * * *