Note: Descriptions are shown in the official language in which they were submitted.
CA 02776989 2012-05-09
A Health Care Management System
Field of the Invention
The invention relates generally to a health care management system and more
particularly to a system for facilitating and managing health care between a
medical
provider and a patient.
Background of the Invention
In the United States alone, approximately 4.5 million complex surgeries are
performed annually. This estimate is expected to increase over time. Patients
having a
medical symptom that necessitates a complex treatment (i.e., surgery) are
typically
limited by the medical providers (e.g., hospitals and medical specialists)
included in the
payer's (e.g., insurance company) plan or network. Furthermore, medical
providers
included in the payer's plan or network may not be specialized in complex
treatments.
Payers also often attempt to offer "out-of-network" coverage, but are
frequently unable
to manage the resulting monetary expenditures. Due to the frequent improper
management of the resulting monetary expenditures, payers can deny the patient
access
to the "out-of-network" medical provider or place a significant supplemental
cost
burden on the patient.
Additionally, due to the complexity and variety of medical symptoms that
compel a complex treatment, each medical case involving a patient having such
a
medical symptom is somewhat unique. Therefore, although a medical provider in
the
payer's network can be specialized in performing a certain complex treatment,
the
patient having the medical symptom may require a different medical provider
that is
focused on a subset of a specialty of medicine. In general, the patient does
not know of
CA 02776989 2012-05-09
the medical providers that specifically specialize in the patient's medical
symptom.
Even if known, the patient typically cannot learn about the quality of care
that these
specialized medical providers have supplied to patients in similar situations.
The
patient does not frequently have information to enable a comparison between
two or
more medical providers. Moreover, besides a primary care physician's referral,
when
patients need a complex treatment, patients often seek alternative sources of
reliable
information to help them identify the most qualified medical provider and best
course
of action. The patient does not generally have broad access to expert medical
providers
and information on these expert medical providers located in various parts of
the
country or in other countries.
Thus, there exists a need to enable patients to attain information about and
to
have access to a broad range of medical providers.
Summary of the Invention
The present invention relates to a method for facilitating and managing health
care between a medical provider and a patient. The present invention
facilitates
communications between a patient having a medical symptom and medical
providers
having expertise in treating the medical symptom of the patient. Further, the
patient
communicates with the medical providers and obtains a treatment proposal for
the
medical symptom in a reduced period of time. The present invention facilitates
the
patient receiving medical information on the medical providers that supply a
treatment
proposal for the medical symptom. Moreover, the patient receives a comparative
report enabling the comparison of information, such as cost and quality of
service,
about medical providers.
In one aspect, the invention includes a method for managing health care. The
method includes providing a patient having a first criteria, which includes a
medical
symptom. The method also includes selecting a subset of medical providers
having
expertise in treating the medical symptom, generating a care request to obtain
a
treatment proposal for the medical symptom of the patient, and updating the
care
request with medical information associated with the medical symptom. The
method
further includes receiving at least one treatment proposal of the medical
symptom from
the medical providers and selecting a treatment proposal of the medical
symptom from
CA 02776989 2012-05-09
the medical providers. In one embodiment. the method additionally includes
transmitting each treatment proposal to each medical provider. receiving a
treatment
proposal from each medical provider, and transmitting each treatment proposal
to the
patient. In one embodiment, the method includes receiving a treatment proposal
that is
modified after transmitting each treatment proposal to each medical provider.
In another aspect, the invention includes a patient-client interface for
providing
a patient having a medical symptom, a provider-client interface for providing
a medical
provider having expertise in treating the medical symptom, and a server in
communication with the provider-client interface for receiving treatment
proposal of
to the medical symptom. The server is also in communication with the patient-
client
interface for receiving a care request corresponding to the medical symptom.
The
server communicates the treatment proposal to the patient-client interface and
receives
a selection of a treatment proposal from the patient-client interface.
In yet another aspect, the invention includes a method of consulting a medical
specialist. The method includes receiving a consultation request from a
treating
physician via a telecommunications system. The consultation request requests a
specialist to be consulted. Additionally, the method includes retrieving
medical
information relevant to but independent from the consultation request from an
information database accessible by a computer. The relevant medical
information is
retrieved by a medical information expert. The method also includes the steps
of
providing the relevant medical information and the consultation request to the
medical
specialist via the telecommunications system and receiving a comment made by a
medical specialist in response to the consultation request and the relevant
medical
information. Additionally, one or more comments are provided to the treating
physician. Further, a continuing medical education credit for the treating
physician is
provided.
Brief Description of the Drawings
The above and further advantages of this invention may be better understood by
referring to the following description in conjunction with the accompanying
drawings,
in which like numerals indicate like structural elements and features in
various figures.
The drawings are not necessarily to scale, emphasis instead being placed upon
CA 02776989 2012-05-09
-4-
illustrating the principles of the invention.
Fig. I illustrates a block diagram of an embodiment of a health care
management system according to the present invention.
Fig. 2 illustrates a flow diagram of an embodiment of the steps performed by
the health care management system according to the present invention.
Fig. 3 illustrates an exemplary embodiment of the present invention.
Figs. 4A, 4B, 4C, and 4D illustrate an exemplary embodiment of a care request
according to the present invention.
Figs. 5A, 513, 5C, and 5D illustrate an exemplary embodiment of a treatment
proposal according to the present invention.
Figs. 6A, 6B, 6C, and 6D illustrate an exemplary embodiment of a comparative
report according to the present invention.
Fig. 7 illustrates a data flow diagram depicting the principle functions
performed by a server during processing and management of a consultation
session
between a primary care physician and a selected medical provider.
Detailed Description
Fig. I illustrates a block diagram of an embodiment of a health care
management system
2 that includes a patient-client computer 10, or patient-client, a server 14,
and a medical
provider-client computer 18, or provider-client. The patient-client 10 is in
communication with
the server 14 over a patient communication path 22 and passes through a
patient-server network
26. The server 14 is also in communication with the provider-client 18 over a
provider
communication path 30 and passes through a provider-server network 34. It
should be noted that
Fig. I is an exemplary embodiment intended only to illustrate, and not limit,
the invention.
The patient-server network 26 and the provider-server network 34 are large
scale
communication networks and can be a local-area network (LAN), a medium-area
network
(MAN), or a wide area network (WAN) such as the Internet or the World Wide Web
(i.e., web).
In one embodiment, the patient-server network 26 (e.g., the patient
communication path 22)
CA 02776989 2012-05-09
-5-
supports secure communications. In a further embodiment. communications occur
after the
user's password is verified by the server 14. In one embodiment. the provider-
server network 34
(e.g., the provider communication path 30) is a protected network that is
physically secure from
public access. In another embodiment, because the provider-server network 34
is not a publicly
available network, the provider-server network 34 is a non-secure network
(i.e., the provider
communication path 30 is a non-secure communication path). Example embodiments
of the
communication paths 22, 30 include standard telephone lines, LAN or WAN links
(e.g.. T1. T3.
56kb, X.25), broadband connections (ISDN, Frame Relay, ATM), and wireless
connections. The
connections over the communication paths 22, 30 can be established using a
variety of
communication protocols (e.g., TCP/IP, IPX, SPX, NetBIOS, Ethernet, RS232, and
direct
asynchronous connections).
The patient-client 10 and the provider-client 18 can be any personal computer
(e.g., 286,
386, 486, Pentium, Pentium II, Macintosh computer), Windows-based terminal,
Network
Computer, wireless device, information appliance, RISC Power PC, X-device,
workstation, mini
computer, main frame computer, personal digital assistant, or other computing
device that has a
windows-based desktop and sufficient persistent storage for executing a small,
display
presentation program. Windows-oriented platforms supported by the patient-
client 10 and the
provider-client 18 can include, without limitation, WINDOWS 3.x, WINDOWS 95,
WINDOWS
98, WINDOWS NT 3.51, WINDOWS NT 4.0, WINDOWS 2000, WINDOWS CE, MAC/OS,
Java, and UNIX. The client 10 can include a visual display device (e.g., a
computer monitor), a
data entry device (e.g., a keyboard), persistent or volatile storage (e.g.,
computer memory) for
storing downloaded application programs, a processor, and a mouse.
The patient-client 10 includes a patient-client interface 36 and the provider-
client 18
includes a medical provider-client interface 40. The interfaces 36, 40 can be
text driven (e.g.,
DOS) or graphically driven (e.g., Windows). In one embodiment, the patient-
client interface 36
is a web browser, such as Internet Explorerm developed by Microsoft
Corporation in Redmond,
WA, to connect to the patient-server network 26. In a further embodiment, the
web browser uses
the existing Secure Socket Layer (SSL) support, developed by Netscape in
Mountain View,
California, to establish the patient-server network 26 as a secure network.
As described more fully below, a patient having a first criteria, including a
medical
symptom, employs the patient-client interface 36 on the patient-client 10 to
obtain treatment for
CA 02776989 2012-05-09
-6-
the medical symptom. In another embodiment, an employer group uses the patient-
client
interface 36 to communicate with the server 14 to enable treatment for the
patient's medical
symptom. Alternatively, a payer organization uses the patient-client interface
36 to
communicate with the server 14. Example embodiments of a payer organization
include. but are
not limited to, insurance companies and HMO's.
Similar to the clients 10, 18, the server 14 can be any personal computer
described above.
In one embodiment, the server 14 hosts one or more software modules 44 that
the patient-client
and/or the provider-client 18 can access. In another embodiment, the server 14
is a member
of a server farm, which is a logical group of one or more servers that are
administered as a single
1o entity. In the embodiment shown. the server farm includes the server 14. a
second server 48, and
a third server 52.
As described more fully below, a medical provider having expertise in treating
the
medical symptom of the patient employs the provider-client interface 40 to
propose a treatment
for the symptom of the patient. Examples of the medical provider include, but
are not limited to,
)5 medical physicians, medically trained individuals, hospitals, medical
specialists, medical experts,
other facilities providing medical treatment, and the like.
In one embodiment, the server 14 is also in communication with a database 56.
The
database 56 is a server that stores and manages data. The server 14 accesses
the information
stored on the database 56 by interfacing with a database module 60. In one
embodiment, the
database module 60 maintains the server 14 data in a Lightweight Directory
Access Protocol
(LDAP) data model. In other embodiments, the database module 60 stores data in
an ODBC-
compliant database. For example, the database module 60 can be provided as an
ORACLE
database, manufactured by Oracle Corporation of Redwood Shores, California. In
other
embodiments, the database module 60 can be a Microsoft ACCESS database or a
Microsoft SQL
server database. The database 56 retrieves data from local memory and
transmits the data to the
server 14 over a data communications network 64. In another embodiment. a
database 56' is
located on the server 14.
In a further embodiment, a second medical provider-client computer 18' having
a second
medical provider-client interface 40' communicates with the server 14 through
the provider-
CA 02776989 2012-05-09
-7-
server network 34. A second medical provider, such as a second hospital. can
propose a second
treatment for the medical symptom of the patient.
Fig. 2 illustrates a flow diagram of an embodiment of the steps performed by
the health
care management system 2 according to the present invention. Patients use the
patient-client
interface 36 to submit (step 202) a care request (i.e., a request for
treatment) to the server 14 over
the patient communication path 22. The software module 44 executing on the
server 14 then
selects (step 204) one of the patients having a first criteria. The first
criteria includes a medical
symptom of the patient. Additional examples of the first criteria include,
without limitation,
insurance coverage of the patient. other means of payment, and a certain level
of complexity
required to treat the medical symptom.
The software module 44 selects (step 206) a subset of medical providers that
have
expertise in treating the medical symptom. For example, the software module 44
selects the
subset of medical providers based on, but not limited to, the previous cost of
treating an identical
or similar medical symptom, the medical experience in the area related to the
medical symptom
(e.g., time working in the area related to the medical symptom), the number of
procedures
treating the medical symptom that have been performed by the medical provider,
the amount of
education received, the reputation of the medical provider, and the like. In
one embodiment, the
server 14 retrieves from the database 56 (using the database module 60)
medical information
associated with a group of medical providers to assist in the determination of
the subset of
medical providers that have expertise in treating the medical symptom. In
another embodiment,
a staff physician, or medically trained individual, that is independent from
the medical providers
selects the subset of medical providers that have expertise in treating the
medical symptom.
Although described above with multiple patients submitting care requests. one
patient
can submit a care request to the server 14. In this embodiment, the software
module 44
continues to determine if the patient is accepted based on the determination
of the patient having
the first criteria (e.g., insurance coverage).
In one embodiment, staff physicians use the server 14 to update (step 208) the
care
request with medical information associated with the medical symptom of the
patient. The staff
physician uses the server 14 to research the medical symptom before updating
the care request.
The database 56 provides the server 14 with relevant articles and other
information on the
medical symptom that the staff physician uses to update the care request. Once
the care request
CA 02776989 2012-05-09
-8-
is complete. the server 14 provides the care request to the provider-clients
18, 18' over the
provider-server network 34. Although described below with two provider-clients
18. 18', the
invention functions properly when the server 14 provides the care request to
the single provider-
client 18.
Each medical provider reviews the care request and determines a treatment
proposal, as
described further below, to treat the medical symptom of the patient. For
example. each medical
provider determines its treatment proposal by examining the difficulty
associated with treating
the medical symptom, the familiarity with treating the medical symptom. and
the availability of
the correct medical specialists. The medical providers then transmit (step
212) their treatment
proposals to the server 14 over the provider-server network 34.
In one embodiment, the software module 44 (or the staff physician) prepares a
preliminary comparative report of the received treatment proposals. The report
lists the
treatment proposals submitted in step 212 and facilitates comparisons between
the two treatment
proposals. The software module 44 then transmits the report to both provider-
clients 18 and 18'.
thereby enabling each medical provider to view (step 214) the other treatment
proposals
submitted by the other medical providers. The medical provider can compare its
treatment
proposal with the other treatment proposals and can modify (step 216) its
treatment proposal
after viewing the other proposals. For example. if the patient requests
treatment for a liver
transplant, a first medical provider can interpret the question (on the
treatment proposal) about
the number of times that a liver transplant has been performed at that medical
provider to mean a
transplant on a living person and a second medical provider can interpret the
question as a
number representing the total number of liver transplants performed (i.e.,
cadaveric and living
liver transplants). More specifically, if the treatment proposal submitted by
the first medical
provider states that the medical provider has performed liver transplants on
10 people over the
past year and a second treatment proposal submitted by the second medical
provider states that
the medical provider has performed cadaveric and living liver transplants 150
times this year, the
first medical provider reviews the second medical provider's treatment
proposal and can change
their number of liver transplants performed to accurately reflect the total
number of transplants
performed in the year. The viewing (step 214) and modifying (step 216) of
treatment proposals
can occur several times. This process of multiple views and modifications of
the treatment
proposal benefits both the patient and the medical providers. More
specifically, the patients
benefit because they obtain treatment proposals that accurately reflect the
services of the medical
CA 02776989 2012-05-09
-9.
providers. Further, the medical providers benefit because they can correct
mistakes and
inaccurate portrayals of their services. In one embodiment, the software
module 44 on the server
14 provides the provider-clients 18, 18' with a date on which no further
changes to the treatment
proposals can occur. Upon this date, the medical providers submit final
treatment proposals to
the server 14.
Once the final treatment proposals are submitted. the staff physician and/or
the software
module 44 generates a final comparative report that includes each treatment
proposal and
provides (step 218) the final comparative report to the patient via the
patient-client interface 36.
In one embodiment, the staff physician recommends a treatment proposal
submitted by one of
the medical providers that the staff physician considers to meet the patient's
interests. Examples
of factors that can affect the staff physician's recommendation include,
without limitation, the
quality of service of the medical provider, cost of the medical provider,
experience of the
medical provider, and travel expenses for the patient to arrive at the medical
provider. The
patient then submits (step 220) its selection of a treatment proposal to the
server 14 over the
patient-server network 26. The server 14 consequently informs the medical
provider that
submitted the selected treatment proposal of the patient's acceptance through
a message to the
provider-client interface 40 (or 40'). In one embodiment, the server 14
transmits an email
message to the provider-client 18 to denote acceptance. However, any other
communication
between the medical provider and the staff physician indicating the patient's
acceptance to the
treatment proposal is sufficient.
Fig. 3 is an illustrative example of the present invention. Sam, a patient, is
diagnosed
(step 302) with a solitary cancer nodule in his left lung. He also has a
significant history of
coronary artery disease with angina, which is a condition in which spasmodic
attacks of
suffocating pain occur. After weighing his choices, Sam determines that he
should undergo
surgery with a team of cardiac and thoracic surgeons to perform a coronary by-
pass and remove
the lung. Sam's primary care physician (i.e., which is member of his medical
insurance network)
referred him to a hospital with a good local reputation. However, Sam's
particular case is
complex and risky, and Sam determines (step 304) that he should look at a
range of medical
providers (i.e., "out-of-network" medical providers).
Sam uses a user interface (i.e., the patient-client interface 36) which, in
one embodiment
is executing on his computer (i.e., patient-client 10), to submit (step 306) a
care request. After
CA 02776989 2012-05-09
- 10 -
Sam's submission, the server 14 and/or the independent staff physician selects
(step 308) a
subset of medical providers having expertise in treating a solitary cancer
nodule in a patient's left
lung while having a history of coronary artery disease with angina (i.e..
expertise in performing a
coronary by-pass and removing the left lung). After the server 14 selects the
medical providers,
the staff physician updates (step 310) the care request with additional
medical information. The
staff physician then transmits (step 312) Sam's care request to these medical
providers. The
selected medical providers each review Sam's care request and submit (step
314) a treatment
proposal to perform Sam's surgeries. The server 14 prepares (step 316) a
comparative report of
the treatment proposals and transmits (step 318) the report to the medical
providers for review
1 o and/or modifications of their respective treatment proposals. Once the
time period for
modifications elapses, the server 14 prepares a final comparative report of
the treatment
proposals and transmits (step 320) this report to Sam. Sam reviews the report
and selects (step
322) one of the treatment proposals. The server 14 consequently informs (step
324) the medical
provider that submitted the selected treatment proposal of Sam's acceptance.
Referring to Figs. 4A, 4B, 4C, and 4D, an example of a care request is shown.
A payer
of the treatment that the patient requests, such as the insurance company that
provides coverage
to the patient, provides general payer information elements 402(a) - 402(m).
In another
embodiment, the patient provides the general payer information elements 402(a)
- 402(m). The
patient then provides general patient information elements 404(a) - 404(f) and
a description of
treatment requested 406. Further, the patient (or payer) provides Current
Procedure
Terminology, or CPT, codes 408. CPT is an accepted listing of descriptive
terms and identifying
codes for reporting medical services under public and private health insurance
programs. The
patient can also provide a medical summary 410, and other medical problems
412. In another
embodiment, a staff physician provides the medical summary 410 of the medical
symptom of the
patient, as illustrated in Fig. 4D.
Referring to Figs. 5A, 5B, 5C, and 5D, an example of a treatment proposal 500
that a
medical provider submits to the server 14 is shown. Information identifying
the care request
(i.e., a case number) and the medical provider is denoted by the identifying
information elements
502(a) - 502(d). General information regarding the medical provider, such as
the city of the
hospital, is denoted by provider information elements 504(a) - 504(e). General
information of
the principle medical expert, such as the number of years in practice, is
denoted by the medical
expert information elements 506(a) - 506(h).
CA 02776989 2012-05-09
-11-
The treatment proposal 500 further includes a care plan 508. An embodiment of
the care
plan is illustrated with care information elements 508(a) through 508(g) and
can include
information such as a detailed description 508(a) of the proposed treatment.
The treatment
proposal 500 includes pre-admission information elements 510(a) - 510(b) to
describe additional
information that is required for pre-admission of the patient. Additionally,
the treatment
proposal 500 contains further information such as, but not limited to, in-
hospital care information
elements 512(a) - 512(e), support team information elements 514(a) - 514(e),
post-discharge
information elements 516(a) - 516(c), additional considerations 518, and
financial proposal
information elements 520(a) - 520(e).
Figs. 6A, 6B, 6C, and 6D illustrate an embodiment of an example of a
comparative report
600. The comparative report 600 facilitates the comparison between the
information included in
a first treatment proposal 602 and a second treatment proposal 604. The
comparative report 600
includes several of the information elements included in the treatment
proposal 500 shown in
Figs. 5A, 513, 5C, and 5D, such as the detailed description 508(a) of the
proposed treatment and
the total proposed price 520(d).
Fig. 7 illustrates a data flow diagram depicting an embodiment of functions
performed by
the patient-client 10 during processing and management of a consultation
session between a
primary care physician and a medical provider. In this embodiment, a medical
physician utilizes
the patient-client 10 to formulate and transmit a request for consultation to
the server 14. The
server 14 processes and relays the request to the provider-client 18. The
server 14 receives the
request for consultation and displays information contained in the request for
initial review by
the staff physician, as indicated at 732. Programmatic tests are performed by
the patient-client
10 and/or the server 14 to test the validity of the data entered into the
formatted fields of the
consultation request. Consequently, the staff physician need only review the
request to insure
that its content is adequate to enable the selection of one or more medical
providers having
expertise in the specialty in which consultation is sought. If the content is
deficient, the staff
physician notes the deficiency in a rejection message returned to the
requesting physician as
indicated at 736 and 737 in Fig. 7.
The staff physician then selects a medical provider to handle the request as
indicated at
738 and forwards the request to the selected medical provider together with
selected materials
CA 02776989 2012-05-09
- 12-
which are obtained and assembled at 739 from the database 56' which stores
medical information
which can be relevant to the request.
This database 56' advantageously includes a publication database module 742
consisting
of abstracts or the full text of articles in medical journals, either stored
locally in the server's
processor's mass storage facility, or in an available medical database 60 (not
shown), such as
Medline/Medlars, connected to the server 14 over the data communications
network 64 (not
shown). In addition, the database 56' further advantageously contains a
tutorial database nodule
744 containing background lessons which are selectively made available to the
requesting
physician as an adjunct to, and in support of, the comments to be received
from the information
assembled at 739 in support of the request. The case study database module 748
stores this
information in a case history file for this consultation, as indicated at 751.
Further information is
thereafter added to this case history file as the consultation proceeds. The
server 14
advantageously stores the request for consultation in the case history file in
the form of a
summary document expressed in hypertext markup language (HTML) which
incorporates links
to other HTML documents and/or supporting materials from the information
database module
740. The consultation request can then be reviewed by the selected medical
provider using a
hypertext document browser, which retrieves and displays selected linked HTML
documents and
linked files as needed directly from the information database 740.
To insure that the request for consultation is handled in a timely fashion by
the selected
medical provider, the staff physician or other supervisory personnel is
notified, as indicated at
752, in the event that an acknowledgment is not received from the provider-
client 18 within a
predetermined duration. In the absence of an indication that the request for
consultation has
been received and is being handled, delay notification 752 permits the staff
physician to select a
different available medical provider to handle the request in timely fashion
when necessary.
Using the facilities provided by the provider-client 18, the selected provider
enters a text
comment answering the consultation report to form information structure
comment information,
which can include reference to supporting articles, lessons, protocols, or
prior case studies in the
information database module 740. As indicated at 754, the provider can make
independent
search requests to the database 56' to obtain information in aid of the
consultation, so that the
citations supplied by the consulting medical provider can include not only
those materials
identified by the automated searches performed by the staff physician but also
supplemental
CA 02776989 2012-05-09
-13-
materials newly cited by the medical provider. Moreover, the provider can
append any other
data which is available to the structured comment information, including image
data or materials
available to the medical provider from another database (not shown).
The structured comment information from the consulting medical provider is
then
returned to the server 14 which forwards the comment information to the
patient-client computer
as indicated at 755. In addition. the server 14 also stores the responsive
comment in the case
study database module 748 for inclusion in the case history file established
at 751 to hold the
original consultation request, as indicated at 756.
The requesting primary care physician is accordingly supplied with the
advisory
to comments of the consulting provider and a body of documented supporting
materials, which can
include relevant published articles from publication database module 742.
documented practices
and protocols from database module 744, tutorial lessons material from the
database module 746,
and prior relevant case histories from the case study database module 748. The
response to the
consultation request which is supplied to the physician also advantageously
takes the form of a
1s summary document expressed in HTML and includes links to supporting HTML
documents and
retrieval supporting documents supplied by the medical provider. Using an HTML
browser, the
requesting primary care physician can, accordingly, review the provider's
comments and the
supporting documentation using the HTML browsing facilities of the patient-
client 10.
Although the initial comment and documentation supplied by the medical
provider can in
many cases wholly satisfy the needs of the requesting primary care physician,
clarification can
be requested when needed. The clarification request message is transmitted to
the server 14
from the patient-client 10 and received as indicated at 763. The incoming
message is examined
at 765 to determine whether a clarification is requested or. in the
alternative. that the requesting
physician wishes to conclude the consultation. If the received message is a
request for
clarification, it is transmitted to the medical provider for further comment
as indicated at 766;
otherwise, a continuing education (CME) accreditation module indicated
generally at 770 is
notified that the consultation has been successfully concluded. The
accreditation module 770
administers a CME database module 772 which records information concerning the
consultation
sessions and produces accreditation reports 775 which can be submitted to the
responsible
accreditation authority to certify that the requesting physician is entitled
to CME credits based on
his or her participation in the consultation session. When required for
credit, the requesting
CA 02776989 2012-05-09
- 14-
physician can also be requested to complete an examination form testing the
knowledge gained,
in which case an examination is made available to the requesting physician as
indicated at 777.
This examination form can also be advantageously implemented by an HTML form
which is
transmitted to the requesting physician, completed, and resubmitted to the
server 14 as indicated
at 779. The completed examination form is then graded and the results posted
to the CME
database module 772 as indicated at 780. The credits accumulated by individual
primary care
physicians who have participated in learning sessions are then detailed in the
CME credit report
775 which is thereafter produced for submission to the responsible accrediting
body as indicated
at 782.
While the invention has been particularly shown and described with reference
to specific
preferred embodiments, it should be understood by those skilled in the an that
various changes in
form and detail can be made therein without departing from the spirit and
scope of the invention
as defined by the appended claims.
