U.S. patent application number 15/195737 was filed with the patent office on 2017-02-09 for report links.
The applicant listed for this patent is D.R. Systems, Inc.. Invention is credited to Evan K. Fram, Murray A. Reicher.
Application Number | 20170039323 15/195737 |
Document ID | / |
Family ID | 58053039 |
Filed Date | 2017-02-09 |
United States Patent
Application |
20170039323 |
Kind Code |
A1 |
Reicher; Murray A. ; et
al. |
February 9, 2017 |
REPORT LINKS
Abstract
A medical and/or clinical report includes one or more links to
various external (and/or internal) data sources and/or systems that
include information relevant to the medical report. In an
embodiment, a medical report may be in a PDF format and include
links to images associated with the exam, information regarding the
patient, a scheduling application useful to schedule additional
procedures for the patient, and/or any other information associated
with the patient or exam. The medical report, including various
links, may be generated based on information received from external
medical data systems. For example, a medical report from an
external system may be updated to include various links to systems
and sources of data related to the medical report, as described
herein.
Inventors: |
Reicher; Murray A.; (Rancho
Santa Fe, CA) ; Fram; Evan K.; (Paradise Valley,
AZ) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
D.R. Systems, Inc. |
San Diego |
CA |
US |
|
|
Family ID: |
58053039 |
Appl. No.: |
15/195737 |
Filed: |
June 28, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14017148 |
Sep 3, 2013 |
|
|
|
15195737 |
|
|
|
|
61696763 |
Sep 4, 2012 |
|
|
|
61709626 |
Oct 4, 2012 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 10/1095 20130101;
H04L 67/22 20130101; H04L 67/02 20130101; G16H 10/60 20180101; G16H
15/00 20180101 |
International
Class: |
G06F 19/00 20060101
G06F019/00; H04L 29/08 20060101 H04L029/08; G06Q 10/10 20060101
G06Q010/10 |
Claims
1. A computing system comprising: one or more computer processors
configured to execute software instructions; and one or more
storage devices storing software instructions configured for
execution by the one or more computer processors in order to cause
the computing system to: determine an identity of a viewer of a
medical report associated with a patient; generate a link to a
secondary system, the link based at least in part on the identity
of the viewer and one or more items of information associated with
the medical report; and embed the generated link in the medical
report.
2. The computing system of claim 1, wherein determining the
identity of the viewer further comprises authenticating the
viewer's identity.
3. The computing system of claim 1, wherein the link to the
secondary system is automatically generated.
4. The computing system of claim 1, wherein the link to the
secondary system is generated in response to an input from a user
of the computing system.
5. The computing system of claim 1, wherein the generated link is
further based at least in part on one or more permissions
associated with the identified viewer.
6. The computing system of claim 1, wherein the generated link
comprises a messaging link.
7. The computing system of claim 6, wherein selection of the
messaging link by the viewer is tracked.
8. The computing system of claim 1, wherein the instructions are
further configured to cause the computing system to: in response to
determining that the viewer of the medical report is the patient,
determine a medical condition referenced in the medical report,
wherein generating the link to the secondary system comprises
generating a link to information related to the determined medical
condition.
9. The computing system of claim 1, wherein the instructions are
further configured to cause the computing system to: in response to
determining that the viewer of the medical report is a referring
physician, generating the link to a scheduling system, wherein the
link includes embedded patient and/or procedure information.
10. A computer-implemented method comprising: by one or more
computer processors executing software instructions: determining an
identity of a viewer of a medical report associated with a patient;
generating a link to a secondary system, the link based at least in
part on the identity of the viewer and one or more items of
information associated with the medical report; and embedding the
generated link in the medical report.
11. The computer-implemented method of claim 10, wherein
determining the identity of the viewer further comprises
authenticating the viewer's identity.
12. The computer-implemented method of claim 10, wherein the link
to the secondary system is automatically generated.
13. The computer-implemented method of claim 10, wherein the link
to the secondary system is generated in response to an input from a
user of the computing system.
14. The computer-implemented method of claim 10, wherein the
generated link is further based at least in part on one or more
permissions associated with the identified viewer.
15. The computer-implemented method of claim 10, wherein the
generated link comprises a messaging link.
16. The computer-implemented method of claim 15, wherein selection
of the messaging link by the viewer is tracked.
17. The computer-implemented method of claim 10 further comprising:
by one or more computer processors executing software instructions:
in response to determining that the viewer of the medical report is
the patient, determining a medical condition referenced in the
medical report, wherein generating the link to the secondary system
comprises generating a link to information related to the
determined medical condition.
18. The computer-implemented method of claim 10 further comprising:
by one or more computer processors executing software instructions:
in response to determining that the viewer of the medical report is
a referring physician, generating the link to a scheduling system,
wherein the link includes embedded patient and/or procedure
information.
19. A computer readable storage medium having software instructions
embodied therewith, the software instructions executable by one or
more processors to cause the one or more processors to: determine
an identity of a viewer of a medical report associated with a
patient; generate a link to a secondary system, the link based at
least in part on the identity of the viewer and one or more items
of information associated with the medical report; and embed the
generated link in the medical report.
20. The computer readable storage medium of claim 19, wherein
determining the identity of the viewer further comprises
authenticating the viewer's identity.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a divisional of U.S. patent application
Ser. No. 14/017,148, filed Sep. 3, 2013, which application claims
the benefit of priority under 35 U.S.C. .sctn.119(e) of U.S.
Provisional Application No. 61/696,763, filed Sep. 4, 2012, and
U.S. Provisional Application No. 61/709,626, filed Oct. 4, 2012.
The disclosures of each of the foregoing applications are hereby
incorporated by reference in their entireties.
BACKGROUND
[0002] Medical records, such as radiology reports that indicate
results of review of medical images by a radiologist, for example,
are widely used in the medical field. Because such reports are
typically printed, or scanned versions of printed text documents,
obtaining useful information associated with medical reports is
difficult.
SUMMARY
[0003] In an embodiment, a computing system is disclosed that
comprises one or more computer processors configured to execute
software instructions; and one or more storage devices storing
software instructions configured for execution by the one or more
computer processors in order to cause the computing system to:
generate a link to a scheduling system, the scheduling system
configured to receive information from a viewer of a medical report
in order to schedule an appointment for a patient, the link
including one or more of demographic information regarding the
patient embedded in the link or a patient identifier embedded in
the link; embed the generated link in the medical report associated
with the patient; and provide the medical report including the
embedded link to a referring physician system, wherein the link is
usable by the referring physician system to provide the one or more
of the demographic information or the patient identifier to the
scheduling system in response to selection of the link.
[0004] In another embodiment, a computing system is disclosed that
comprises one or more computer processors configured to execute
software instructions; and one or more storage devices storing
software instructions configured for execution by the one or more
computer processors in order to cause the computing system to:
generate a link to a scheduling system, the scheduling system
configured to receive information from a viewer of a medical report
in order to schedule an appointment for a patient; embed the
generated link in the medical report associated with the patient;
generate a metadata pointer, the metadata pointer useable to access
metadata associated with the medical report and/or the patient; and
provide the medical report and metadata pointer to a referring
physician system, wherein the link is usable by the referring
physician system to cause the metadata pointer to be provided to
the scheduling system in response to selection of the link.
[0005] In yet another embodiment, a computing system is disclosed
that comprises one or more computer processors configured to
execute software instructions; and one or more storage devices
storing software instructions configured for execution by the one
or more computer processors in order to cause the computing system
to: receive a medical report associated with a patient, the medical
report including a link to a medical information application
configured to access one or more items of medical information
associated with the patient and selectively display the one or more
items of medical information associated with the patient in
response to input from a user of the computing system; track
particular items of the one or more items of medical information
that are displayed by the computing system; and transmit a
notification to one or more third party systems indicating the
particular items of medical information that were displayed by the
computing system.
[0006] In yet another embodiment, a computing system is disclosed
that comprises one or more computer processors configured to
execute software instructions; and one or more storage devices
storing software instructions configured for execution by the one
or more computer processors in order to cause the computing system
to: determine an identity of a viewer of a medical report
associated with a patient; generate a link to a secondary system,
the link based at least in part on the identity of the viewer and
one or more items of information associated with the medical
report; and embed the generated link in the medical report.
[0007] In another embodiment, a computing system is disclosed that
comprises one or more computer processors configured to execute
software instructions; and one or more storage devices storing
software instructions configured for execution by the one or more
computer processors in order to cause the computing system to:
receive a medical report associated with a patient, the medical
report including a link to a medical information application
configured to access one or more items of medical information
associated with the patient and selectively display the one or more
items of medical information associated with the patient in
response to input from a user of the computing system.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] FIGS. 1A and 1B are block diagrams that show various example
components of a system for displaying information, among other
methods and processes, according to embodiments of the present
disclosure.
[0009] FIG. 2 illustrates two mobile information display computing
devices, according to embodiments of the present disclosure.
[0010] FIG. 3 illustrates an example medical report including links
to an exam scheduler and an exam viewer, according to an embodiment
of the present disclosure.
[0011] FIG. 4 illustrates an example medical report in which an
indicator is hovering over a link, according to an embodiment of
the present disclosure.
[0012] FIG. 5A illustrates another example medical report including
links to an exam scheduler and an exam viewer, according to an
embodiment of the present disclosure.
[0013] FIG. 5B illustrates an example scheduling application,
according to an embodiment of the present disclosure.
[0014] FIG. 6A illustrates a sample report file that includes both
report data and metadata, according to an embodiment of the present
disclosure.
[0015] FIG. 6B illustrates a sample report including report data
and metadata in separate files, according to an embodiment of the
present disclosure.
[0016] FIGS. 7A and 7B are block diagrams illustrating sample flows
of information between a radiologist, referring doctor, and
scheduling system, according to embodiments of the present
disclosure.
[0017] FIGS. 8A and 8B are flowcharts illustrating example
processes for providing information to a scheduling system,
according to embodiments of the present disclosure.
DETAILED DESCRIPTION
[0018] Embodiments of the disclosure will now be described with
reference to the accompanying figures, wherein like numerals refer
to like elements throughout. The terminology used in the
description presented herein is not intended to be interpreted in
any limited or restrictive manner, simply because it is being
utilized in conjunction with a detailed description of certain
specific embodiments of the disclosure. Furthermore, embodiments of
the disclosure may include several novel features, no single one of
which is solely responsible for its desirable attributes or which
is essential to practicing the embodiments of the disclosure herein
described.
[0019] The present disclosure describes a medical and/or clinical
report that includes links to various external (and/or internal)
data sources and/or systems that include information relevant to
the medical report. For example, in an embodiment, a medical report
may be in a PDF format (or any other format) and include links to
images associated with the exam, information regarding the patient,
a scheduling application useful to schedule additional procedures
for the patient, and/or any other information associated with the
patient or exam.
[0020] In an embodiment, a medical report including various links,
as described herein, may be generated based on information received
from external medical data systems. For example, a medical report
from an external system may be updated to include various links to
systems and sources of data related to the medical report, as
described herein.
[0021] The use of links in medical reports, as described herein,
may provide a number of benefits and advantages including: adding
convenience to the review of medical data, and/or providing
usefulness in satisfying meaningful use regulatory requirements
(e.g., stage 2 requirements) and/or other requirements for sharing
and availability of medical data, among others.
[0022] In order to facilitate an understanding of the systems and
methods discussed herein, a number of terms are defined below. The
terms defined below, as well as other terms used herein, should be
construed to include the provided definitions, the ordinary and
customary meaning of the terms, and/or any other implied meaning
for the respective terms. Thus, the definitions below do not limit
the meaning of these terms, but only provide exemplary
definitions.
[0023] Within the present disclosure, the terms "doctor,"
"physician," "practitioner," and the like may be used
interchangeably to refer to any medical or other professional that
may be a user of the systems and methods described herein. However,
the systems and methods described herein are not limited to use by
physicians, but may also be used by other types of users including,
for example, office personnel, insurance providers, scheduling
assistants, and/or patients, among others.
Scheduler Links with Associated Patient Information
[0024] In an embodiment, a medical and/or clinical report
associated with a patient may be generated. The medical report may
include a link to a scheduling system. The link may include, for
example, demographic and/or other information related to the
patient. When the link is selected, the information related to the
patient may be provided to the scheduling system and may be used,
for example, to pre-fill patient information into a scheduling
form. This may, for example, enable efficient and semi-automated
appointment scheduling for the patient.
[0025] In an embodiment, the information associated with the
patient (e.g., patient name, gender, date of birth, address, etc.)
may be directly embedded in the link. In this embodiment, when the
link is selected, the information embedded in the link may be
directly transmitted to, and received by, the scheduling system (or
other system indicated in the link). Thus, the scheduling system
may pre-populate scheduling forms using the information included in
the link and/or lookup additional information regarding the patient
using the patient information. For example, if the patient's name
and date of birth is included in the link (e.g., the link may be
http://myhospitalschedulercom/patient/sam.stevens/042368), that
information (e.g. the patient's name is Sam Stevens, born Apr. 23,
1968) may be used to look up the patient in a patient database,
such as to retrieve additional information regarding the patient
that is useful in scheduling the exam.
[0026] In some embodiments, a patient identifier may be included
and/or otherwise embedded in the link. In this example, the patient
identifier may be transmitted to, and received by, the scheduling
system as part of the link (e.g., the link may be
http://myhospitalscheduler.com/patientid/M14122). The scheduling
system may then automatically retrieve, from one or more other
systems, information related to the patient based on the patient
identifier (e.g., M14122). In an embodiment, the link may be usable
to access information regarding the patient that is accessible by
the scheduling system in response to the scheduling system
receiving the demographic information and/or the patient identifier
in the link.
[0027] FIG. 3 illustrates an example medical report, according to
an embodiment, including a link 310 to an exam scheduler website or
application, as well as a link 320 to view items associated with
the exam, such as medical images.
[0028] FIG. 4 illustrates the same example medical report as that
illustrated in FIG. 3, with the mouse (or other selector) hovering
over the link 310 so that details of the link are illustrated. In
this embodiment, the link 310 is configured to open a webpage that
is associated with a scheduling application. In this example, the
link includes a patient identifier (e.g., PatientID=534) that is
usable by the scheduling application to select and/or access
information associated with the specific patient identified by the
patient identifier. For example, demographic information associated
with the patient may be automatically selected and/or accessed from
a patient database. For example, the scheduler may use the patient
ID to directly retrieve information (e.g., automatically, without
intervention from the individual that selects the scheduling link
310) from a patient database (e.g., either local or remotely
accessible database) that is useful in scheduling an exam, such as
the patient's name, birthdate, gender, scheduling preferences, etc.
Accordingly, the user that is viewing the medical report and
selecting the link does not need to locate the appropriate patient
before continuing with the scheduling operation, such as by
entering demographic information of the patient in order to locate
the patient in a database of patients or creating a new record for
the patient.
[0029] FIG. 5A illustrates another example medical report including
patient information 502, a link 504 to view items associated with
the exam (such as medical images), and a link 506 to an exam
scheduler website or application. As with FIGS. 3 and 4 above, the
link 504 may be selected by a user to open a viewer or other
application useable for viewing information associated with the
exam. For example, in response to selecting the link 504, medical
images associated with the exam may be provided to the user, as
shown in reference to computing device 295 of FIG. 2. The link 506
may be selected by a user to open a webpage, application, or window
that is associated with the scheduling application. The link 506
may include various items of information associated with the
patient that are useable by the scheduling application to identify
the patient and/or schedule an appointment or exam for the patient.
In the example of FIG. 5A, the link may include a patient name
(e.g., John Smith), a patient identifier (e.g., 753476), referring
doctor information, exam information, and/or procedure information.
As described above, the various items of information may be useable
to access additional information associated with the patient. In an
alternative, only particular items of patient information (such as
a patient ID) may be included in the link. The particular items of
patient information may then be useable, as described above, to
access additional information associated with the patient from, for
example, a patient database. In an embodiment, the scheduling
application, such as that illustrated in FIG. 5B, may be displayed
in response to selecting the scheduling link 506.
[0030] As shown in the example of FIG. 5B, information regarding
the patient that is the subject of the medical report of FIG. 5A is
already populated in the scheduler application. The patient-related
information includes, for example, a patient name (e.g., John
Smith), ID (e.g., 753476), date of birth (e.g., 1/19/1946), and/or
sex (e.g., M), a referring physician (e.g., Dennis H. Broker, MD),
a patient history, and/or a recommended exam or procedure. The
information is automatically populated in the scheduler application
when the link 506 is selected. This functionality may provide the
scheduler and/or referrer tremendous convenience. For example, the
functionality removes the need for the scheduler/referrer to look
up the patient in the scheduling system. Additionally, the
functionality prevents the creation of a duplicate patient record.
Because the patient is accurately identified, the
scheduler/referrer may access information about the patient
accessible via the scheduling system. For example, the
scheduler/referrer may access a record of prior exams and/or other
health information directly from the scheduler application. Such
information may not be available to a referring doctor outside of
the link to the scheduling system.
[0031] Depending on the embodiment, scheduler links, such as links
310 and/or 506, may include an identifier of the patient (e.g., the
patient ID's illustrated in FIGS. 4 and 5A) and/or specific
demographic or other information associated with the patient. For
example, a scheduler link used in a medical report may include name
and address information (and/or any other combination of patient
information) of a patient. The schedule link may be in any suitable
format including, for example, [0032]
https://www.patientscheduler.com/smith?harry?123?main?84321 [0033]
or [0034]
https://www.patientscheduler.com/?last=smith?first=john?address1=1-
23?address 2=main?zip=84321.
[0035] Thus, in one embodiment, the demographic or other
information associated with the patient included in the link may be
used directly in pre-filling a form in the scheduling system for
scheduling an appointment or exam for the patient. For example, the
patient's name, address, phone number, and other necessary
identifying characteristics or information may be included and/or
embedded directly in the link. In another embodiment, and as
described above, the demographic or other information associated
with the patient included in the link may be used by the scheduling
system to identify the patient and retrieve additional information
related to the patient necessary for scheduling the exam or
appointment. In some embodiments, both a patient ID and patient
demographic information may be included in a link.
[0036] In some embodiments, the scheduler link may be configured to
select a specific exam type or procedure within the scheduling
application, which makes the scheduling task even easier and
reduces the risk of scheduling the wrong exam. For example, the
link to the scheduler application may include embedded information
regarding an exam type that is recommended in the report (e.g., by
the reviewing radiologist). Thus, when a referring doctor, for
example, selects the scheduler link, the system may automatically
activate the scheduling system, pre-populate patient information,
and also pre-select the precise exam type that was recommended in
the report. For example, with reference to FIG. 5B, the procedure
recommended in the report may be automatically selected (in the
"Select Procedure" portion of the interface) in response to the
referring doctor (or other user) selecting a scheduling link with
the recommended exam or procedure information encoded in the link.
Thus, when the user first opens the scheduler application using the
scheduler link, the appropriate exam or procedure may already be
selected. In an embodiment, exam notes may be included in the
scheduling application. These notes may be automatically filled
when the user selects the scheduler link, or they may be added by
the user after the link is selected.
[0037] Depending on the embodiment, the encoded exam type may be a
code that is non-descriptive of the associated procedure (e.g.,
"123" or "proc1d" may be included in the schedule link and
associated with a "CT Abdomen W" procedure) or the encoded exam
type may provide some indication of the associated procedure (e.g.,
"CT-Ab-W" may be associated with a "CT Abdomen W" procedure). In
other embodiments, exam or procedure types may be encoded in any
other way.
[0038] In some embodiments, scheduler links may be directed to a
standalone application, rather than a web application. In one
embodiment, scheduler links may refer to a mobile application, such
that a report viewed on a tablet device, for example, may refer to
a mobile scheduling application that is used to schedule additional
procedures for the patient. In one embodiment, the medical report
may include multiple scheduler links that are selectable by the
viewer in order to select various scheduler applications, versions
of the scheduler application for different device types, etc. For
example, hovering over a scheduler link may result in a display of
multiple links that are selectable by the user, such as by clicking
on one of the multiple links.
[0039] As described above, in some embodiments the medical report
and/or link may be accessible and/or selectable by a physician. In
these embodiments, the physician may be enabled to quickly access
medical information related to the patient and to schedule exams or
other types of appointments for the patient. In other embodiments,
the medical report and/or link may be accessible and/or selectable
by other types of users, such as patients. In these embodiments,
the patient may be enabled to quickly access their own medical
information and to easily schedule exams or other types of
appointments for themselves. Various rules may determine when a
patient is able to view particular medical information, as
described below. In various embodiments, physicians, patients,
and/or other types of users may interact with one or more computing
devices, such as computing devices 150 and/or 250 (described in
FIGS. 1A and 1B below), to view medical reports, select links,
and/or accomplish other aspects of the present disclosure.
Metadata
[0040] In some embodiments, a clinical and/or medical report may
have information embedded in the report, such as in a header
portion of the report file and/or in metadata (that is part of the
report file or a separate file) that may be transmitted with the
report file. For example, such metadata may include information
about the patient, referring doctor, demographics, and/or
recommended exam information. The metadata may be used by a
scheduling system, such as various scheduling systems that operate
in different manners, to simplify scheduling by automating
selection of certain exam scheduling parameters in view of the data
included in the metadata (as described above). The metadata file
may be in any available format, such as a CSV, XML, text, or other
format.
[0041] FIG. 6A illustrates a sample report file 610 that includes
both the report data 620 (e.g., the actual PDF data that is
displayed on the referring doctor's screen), as well as metadata
630 that includes various additional information that may be useful
in scheduling additional procedures for the patient. In this
embodiment, the report file 610 may be a PDF, Microsoft Office
file, or any other file type that includes the metadata 630 in a
header (or other) portion of the report file 610. In an example,
the metadata is transmitted along with the actual report data 620
so that the referring doctor, and anyone else that subsequently
accesses the report file 610, also has the associated metadata.
[0042] In the embodiment of FIGS. 6A and 6B, the metadata 630
includes patient data, referring doctor data, recommended exam or
procedure information, and/or any other information that may be
relevant to exam scheduling and/or of interest to a referring
doctor or other individual that accesses the report data 620. In
other embodiments, other information may be stored in the metadata
630. The information in the metadata may be stored in various
formats.
[0043] In the embodiment of FIG. 6B, the metadata 630 is shown as a
separate file from report data 620. In this embodiment, the
metadata 630 may be a file that is transmitted along with the
report data 620 to the referring doctor, for example. Thus, the
metadata is available for scheduling. However, the metadata 630 may
be transmitted and used separate from the report data 620 because
they are in separate files. In an embodiment, the metadata
associated with a particular report may be stored in a separate
system and/or data store that is accessible by the referring
doctor, the scheduling system, and/or anyone else with access to
the report file. The metadata 630 may be associated with the report
data 620 by a common identifier, such as a medical report
identifier that is included in the report data 620 as well as the
metadata 630. Accordingly, metadata associated with any report,
whether stored locally or remotely, may be located using the common
identifier.
[0044] FIGS. 7A and 7B are block diagrams illustrating sample flows
of information between a radiologist (or other examining doctor), a
referring doctor, and a scheduling system. In other embodiments,
the information may be transmitted between different entities. In
an embodiment, each of the radiologist, referring doctor, and
scheduling system comprise one or more computing systems that are
operated by one or more human operators.
[0045] Referring now to the embodiment of FIG. 7A, a medical report
is transmitted from the radiologist to the referring doctor via a
network. Depending on the embodiment, the report may be transmitted
immediately after completion by the radiologist or in response to a
request for the report from the referring doctor. In an embodiment,
the report includes metadata including information that is useful
for scheduling an exam for the patient. For example, the metadata
may include any of the example information discussed above with
reference to FIGS. 6A and 6B and, specifically, with reference to
metadata 630.
[0046] In the embodiment of FIG. 7A, the illustrated report may
include the metadata in a header portion of the actual report file
(e.g., similar to what is shown in FIG. 6A) or may include the
metadata as a separate file (e.g., similar to what is shown in FIG.
6B). In other embodiments, the report may be transmitted separately
from the metadata, possibly to different computing systems (see,
for example, FIG. 7B discussed below). For example, the metadata
may be sent directly to the scheduling computing system (a third
party scheduling system or a schedule computer at the referring
doctor's offices), while the report is sent to a report viewing
computing system at the referring doctor's offices. In such an
embodiment, the appropriate metadata may be accessed by the
referring doctor (or scheduler) providing a medical report
identifier that is received in or with the report to the scheduling
system.
[0047] Turning now to FIG. 7B, an embodiment is illustrated in
which the generated metadata is transmitted separately from the
report. In step 1, when the report is created, the report and a
pointer to associated metadata (or other identifier of the
metadata) is communicated to the referring doctor system, and the
metadata itself is transmitted to a secure database (or other data
structure). The secure database may be, for example, any secure
data store capable of storing the patient information contained in
the metadata which is accessible by the scheduling system and the
source (e.g., radiologist) system (for example, the secure database
124 of FIG. 1A). The metadata pointer may be any indicator capable
of uniquely identifying the metadata associated with the report.
The metadata pointer may be useable to retrieve the associated
metadata from the secure database. In an embodiment, the metadata
pointer may also include a location for the metadata or the secure
database, e.g., the address of a secure, distributed or cloud-based
database. In an embodiment, the metadata pointer may be associated
with the report, but may contain no patient-identifying
information. In an embodiment, the metadata pointer may be embedded
in a link included in the report, such as a scheduling and/or
viewing link. In another embodiment, the metadata pointer may be
embedded in the report or stored in a separate file, similar to the
way metadata storage is described in reference to FIGS. 6A and
6B.
[0048] In step 2, the user of the report, e.g., a referring doctor,
may select a link in the report which opens a new application, such
as a scheduling system, and the metadata pointer is transmitted to
the scheduling system and/or application. In step 3, the scheduling
system/application uses the metadata pointer to access the patient
information stored in the secure database, such as by transmitting
the metadata pointer to the secure database and/or accessing a
location of the secure database indicated in the metadata pointer.
In step 4, the associated metadata is accessed by the scheduling
system/application. The information in the associated metadata may
then be used as input to the scheduling system/application. The
information may include, for example, patient demographic
information, exam information, physician information, etc.
[0049] In an embodiment, the metadata pointer includes
authentication information. The authentication information may be
useable to authenticate the source and/or identity of the metadata
pointer in order to reduce risk of unauthorized access to the
secure database. In an embodiment, the secure database may be a
part of the source (e.g., radiologist) system. In an embodiment,
the metadata may be communicated directly from the source system to
the schedule system.
[0050] In some embodiments, the metadata included with the report,
or in a file separate from the report, may be used in order to
schedule an exam or procedure for the patient. As shown in FIGS. 7A
and 7B, the metadata (or a portion of the metadata) may be
transmitted to a scheduling system for auto population/auto
completion of at least a portion of the exam/procedure scheduling
form. In one embodiment, the referring doctor computing system may
extract information from the metadata and reformat the data for use
by the scheduling system, such as a format that is used by the
specific scheduling system used by the referring doctor. In one
embodiment, the scheduling system is a module of the referring
doctors computing system, such that the metadata may not be
transmitted across a network or may be transmitted across a local
area network to a computing system that is local to the referring
doctor.
[0051] In the embodiments illustrated in FIGS. 7A and 7B, the
metadata associated with the report advantageously allows the
scheduling system, which may be any scheduling system, to receive
data associated with a patient and thereby allow the scheduling
system to automatically select certain parameters for scheduling of
the indicated exam/procedure for the patient.
[0052] FIGS. 8A and 8B are flowcharts illustrating example
processes or methods for providing the patient information to the
scheduling system, according to embodiments of the present
disclosure. In various embodiments, the methods described may
include additional or fewer blocks and/or the blocks may be
performed in a different order than is illustrated. Software code
configured for execution on a computing device in order to perform
the method may be provided on a tangible computer readable medium,
such as a compact disc, digital video disc, flash drive, hard
drive, memory device or any other tangible medium. Such software
code may be stored, partially or fully, on a memory of a computing
device (for example, RAM, ROM, etc.), such as the computing device
150 (see discussion of FIG. 1A below) or 250 (see discussion of
FIG. 1B below), and/or other computing devices illustrated in the
figures, in order to perform the respective methods.
[0053] Turning to FIG. 8A, at blocks 802 and 804, a link to the
scheduling system is generated including an embedded patient
identifier and/or patient demographic information, as described
above in reference to FIGS. 3, 4, 5A, and 5B. At block 806, the
generated link is embedded in the medical report, as further
described above in reference to FIGS. 3, 4, 5A, and 5B, for
example.
[0054] At block 810, the medical report, including the generated
link, is provided to the referring physician system, as described
above in reference to FIG. 7A, for example.
[0055] At block 812, the referring physician, or another user of
the referring physician system, may select the generated link
included with the medical report. In response to selection of the
link, at block 814 the patient information embedded in the link is
provided to the scheduling system, as described in reference to
FIG. 7A above, for example. In an embodiment, the patient
information embedded in the link may comprise patient metadata. As
noted above, metadata associated with the patient may be embedded
in the report, or may be provided in a separate file that is
separately transmitted and/or made accessible to the scheduling
system, as further described in reference to FIGS. 6A, 6B, 7A, and
7B, for example.
[0056] At block 816, the scheduling system may utilize the patient
information provided with the link to pre-fill the scheduling form.
In an embodiment, the scheduling system may utilize embedded
metadata associated with the patient, or metadata provided in a
separate file, to pre-fill the scheduling form. In another
embodiment described above, the scheduling system may use the
patient information, including patient identifying information, to
access additional internal and/or external data sources of
information related to the identified patient. The accessed
information may then be used to pre-fill the scheduling form.
[0057] Turning now to FIG. 8B, another example process for
providing the patient information to the scheduling system is
shown. The process of FIG. 8B is similar to the embodiment
illustrated in FIG. 7B. At block 830, a link to the scheduling
system (which may or may not include embedded patient identifying
information), patient metadata, and a metadata identifier are
generated. At block 832, the generated link is embedded in the
medical report, and at block 836, the metadata is communicated to a
secure database, as described above in reference to FIG. 7B, for
example. At block 838, the report and the metadata pointer are
provided to the referring physician system.
[0058] At block 840, the referring physician, or another user of
the referring physician system, may select the generated link
included with the medical report. In response to selection of the
link, at block 842 the metadata pointer is used to retrieve the
associated metadata stored in the secure database, as described in
reference to FIG. 7B above, for example.
[0059] At block 844, the scheduling system may utilize the patient
information provided with the link and/or the retrieved metadata to
pre-fill the scheduling form. In another embodiment described
above, the scheduling system may use the patient information,
including patient identifying information, to access additional
internal and/or external data sources of information related to the
identified patient. The accessed information may then be used to
pre-fill the scheduling form. In an embodiment, the metadata may be
retrieved directly from the source (e.g., the report generating)
system.
Tracking Medical Images
[0060] In an embodiment, a method comprises generating a medical
report associated with a patient, the medical report including an
exam viewing link (for example, exam viewing link 320 of FIG. 3 or
exam viewing link 504 of FIG. 5A) configured to allow the user to
view one or more medical images of the exam (and/or other exam
information) and/or selectively display medical images of the
patient in response to input from a user of the computing system.
Similar to the links 310 and/or 506 described above, the exam
viewing links 320 and/or 504 may include one or more of a patient
identifier, an exam identifier, exam type information, and/or
patient demographic information. When an exam viewing link is
selected, the included information may then be useable to retrieve
the desired and/or associated exam images or other data.
[0061] For example, selection of the exam viewing link 504 may
cause a web-based or standalone image viewing interface to open up
on the user's computer, such as a user interface that is used on a
Picture Archiving and Communication System (PACS) workstation. The
method may further track medical images that are displayed by the
computing system and/or medical images (or other medical data) that
are interacted with in other ways.
[0062] In one embodiment, the method tracks which medical images
the computing systems has the capability to view (e.g., which
images are available on an electronic health records system of a
doctor or transmitted to the doctor's computing system, even if the
images are not actually displayed).
[0063] In an embodiment, the method further comprises transmitting
a notification to one or more third party systems indicating the
medical images that were displayed by (or otherwise made available
to and/or accessed by) the computing system. In one embodiment, the
one or more third party systems are identified based on meaningful
use requirements and/or other regulatory requirements associated
with respective third party systems. In one embodiment, the
tracking criteria for each of the one or more third party systems
are determined based on preferences for reporting of images
displayed per ordered procedure, per patient, per system, or per
eligible provider.
[0064] In one embodiment, the tracking data (e.g., data indicating
which medical images were displayed by a third-party system, such
as a referring doctors computing system) may be used to prove
compliance with regulatory requirements, such as those originating
from meaningful use regulations. For example, a particular user
(e.g., a doctor) may be required to have the capability to view at
least 10% of exams that are actually ordered. In this embodiment,
the system that delivers the medical images, such as in response to
the doctor selecting exam viewing link 504 (FIG. 5A), may also
store data that is useful to prove compliance with that viewing
requirement. For example, the system may store data indicating how
many exams the doctor ordered and how many exams had images
displayed by one or more computing devices associated with the
doctor (and/or how many exams or images were made available for
display to those computing devices on the doctor's Electronic
Health Record (EHR) system, for example). In one embodiment, the
system may provide the tracking data on a periodic basis, such as
weekly or monthly, to a regulatory device so that the doctor is not
required to submit any forms to complete compliance. The same or
similar reporting data may be provided to the doctor and/or any
other third party system.
Patient Access to Medical Data
[0065] In an embodiment, and as described above, the system can
deliver or make available medical data (e.g., medical images) to a
patient, such as in response to a patient selecting an image
viewing link of a medical report that is provided to the patient.
In one embodiment, medical data is provided to the patient only
after a certain interaction with the medical data has occurred. For
example, a referring doctor or radiologist may set a rule
indicating that patients can receive a medical report 24 hours
after the medical report is delivered to the referring doctor.
Similarly, the rule may indicate that patients can receive the
medical report immediately after the referring doctor provides an
indication that he has reviewed the medical report. In this way,
the patient is given information only after the referring doctor is
prepared to discuss the information. Delivery rules based on any
other criteria, or combination of criteria, may also be used to
determine when medical data can be provided to patients.
Additionally, different types of medical data may have different
applicable rules. For example, a rule may indicate that a medical
report is provided to patients after delivery to the referring
doctor, but medical images may only be delivered after the patient
has actually met or talked to the referring doctor. Additionally,
different patients may have different applicable rules. For
example, a doctor may set rules for groups of users based on the
patient's age, gender, clinical indication, exam results (e.g.,
normal vs. abnormal), etc., such that delivery of medical data
varies from patient to patient. For example, a doctor may allow
immediate delivery to patients of reports that are normal or show
no significant abnormality, while delaying delivery to patients of
reports with abnormal results until after the doctor has indicated
that the reports may be delivered (for example after the doctor has
discussed the results with the patient).
Other Information and Link Enhancements
[0066] In addition to links that allow scheduling and/or exam
viewing, as described above, in some embodiments a medical report
may have links that allow the user to perform other functions, such
as order lab tests and/or refer the patient to a specialist.
[0067] With an electronic medical information exchange, medical
information such as reports, labs, and consultations from multiple
sites can be automatically cross referenced. This can give a more
complete picture of the patient than might be available at any
individual site. For example, a doctor could be provided with links
that allow him to access related information within the electronic
medical information exchange (or linked EMRs or other databases).
For example, when viewing a report, the doctor may want additional
information to put the results of the report in the clinical
context such as reports of other imaging exams (in general or
related to the same body part), reports in the form of
consultations from other physicians that have seen the patient,
and/or lab results
[0068] In an embodiment, related results may have occurred before
or after the imaging exam was performed, and the links in the
report may allow access to both older and newer information. For
example, an internist may order lumbar spine radiographs on a
patient and the reading radiologist may recommend a lumbar spine
MRI based on results of the radiographs. Based on the MRI, lab
tests may be ordered, for example, to evaluate for infection. The
patient might then be referred to a neurosurgeon. A neurosurgeon
viewing the report of the radiographs may then click on one or more
links in the report that would link him to the clinical notes of
the internist that led to the original exam (for example, from
before the lumbar radiographs), the report of the subsequent MRI
(which might have been performed at a second location and performed
after the radiographs), and/or lab test results (which might have
been performed at a third location and after the radiographs).
[0069] In one embodiment, reports may include a general "EMR"
(Electronic Medical Records) or "EHR" (Electronic Health Record)
link that would bring up links to the various EMR's and/or EHR's
where the patient has medical data stored so the doctor could
browse that information, assuming he has rights. Since he has
rights to view the report he is viewing, there may be conditions
where rights to view that report could be used to give him rights
to all of some of the information in the linked EMR's and/or
EHR's.
[0070] In an embodiment, the electronic medical information
exchange, which may include a more complete picture of a patient's
medical history than any particular individual site or EMR, may
also be used to enhance ordering systems. For example, the
information available in the electronic medical information
exchange, possibly with linked EMR's, could also be used to prevent
ordering of potentially unnecessary duplicate exams or lab tests.
For example, a doctor viewing a report of a lumber spine radiograph
might order a lumbar spine CT. In the scheduling systems, he could
be notified by the system that the patient already had a recent
lumbar spine CT based on information within, or linked to, the
electronic medical information exchange.
[0071] In an embodiment, the system could be used to provide
information to doctors related to a patient's radiation exposure
and/or alternative exams. For example, if a doctor ordered a lumbar
spine CT on a patient, he might be advised that the patient has had
five abdominal CT scans in the last year and get him thinking about
whether a lumbar spine MRI might answer the clinical question
without additional radiation exposure.
User-Determined Links
[0072] In an embodiment, the particular links and/or types of links
displayed on a particular report may vary based on one or more
characteristics of the user and/or viewer. For example, the links
displayed in a report may depend on permissions and/or privileges
associated with the user. In these embodiments, the user may first
be identified, and that identity may be authenticated, before the
report (or particular links in the report) is viewable. For
example, a referring doctor viewing a report may be able to see a
link related to scheduling an exam, while a patient viewing the
same report may be able to see a link to educational information
related to a medical condition referenced in the report (but not
the scheduling link).
[0073] In various embodiments, information related to user
identification and/or authentication, and the associated links
displayed, may be managed by the application displaying the report,
e.g., an electronic health record system or personal healthcare
system. In another embodiment, the identification and/or
authentication information and logic related to which links are
displayed may be contained within the report itself. The method of
managing identification, authentication, and link viewing
information may vary depending on the form the report takes, for
example, users may have different rights or preferences to view
links in a report based on a format of the report, such as a screen
displayed by an application such as an EHR, a web page, or a
self-contained document such as a PDF file.
Methods of Generating Links
[0074] In an embodiment, links displayed in a particular report may
be manually chosen by a user creating the report, for example a
radiologist. For example, a radiologist may want to include links
to one or more informational sources, such as a cancer staging
system associated with a cancer discussed in his report. The
radiologist may indicate to the reporting system (or report
generating system) that a link should be present in the report that
links to details of the staging system referred to in the report.
In another example, the user creating the report may insert a link
that links to, and/or causes display of, educational material
related to, or relevant to, the report. For example, the user may
create a link to current medical recommendations related to breast
screening exams. In general, links from the medical report to any
information, systems, and/or resources (for example, the scheduling
system, educational material, etc.) may be referred to as links to
secondary systems.
[0075] In another embodiment, links may be automatically inserted
into reports. For example, links to educational material related to
a condition described in the report, characteristics of the exam
performed, and/or recommendations for further workup may
automatically be included in the report. In an embodiment, natural
language processing may be used to detect conditions reported in
the report and automatically insert associated links. For example,
in the case of recommended follow-up imaging for screening,
material linked to may be based on the findings within the
report.
[0076] In various embodiments, when links are inserted into
reports, manually or automatically, they may be manually and/or
automatically set to be viewable by a subset of authorized viewers
of a report. For example, a link to the scheduling system may be
shown to a referring physician but not to a patient (as mentioned
above).
[0077] In an embodiment, when links are automatically inserted into
a report, the links inserted may be based on user preferences of
various users that may be associated and/or interact with a report,
e.g., the person that ordered the exam (e.g., a referring
physician), the user generating the report (e.g., a radiologist),
and/or the user viewing the report. For example, a referring
physician that ordered the exam, and a patient viewing the report,
may have different links. In another example, different referring
physicians may choose different educational material to be
presented to their patients via links in reports.
Messaging via Report Links
[0078] In various embodiments, links within reports may provide
messaging functionality. The messaging functionality of the links
may vary, for example, based on the identity of the user or viewer
of the report, and/or based on privileges or preferences of the
user or viewer of the report. For example, in the context of a
patient viewing a report, one or more links may enable the patient
to: [0079] Send a message to a referring doctor. [0080] Send a
message to a doctor that interpreted the exam. [0081] Send a
message to a third party to, for example, request a second opinion
related to interpretation of the exam associated with the report.
[0082] Request or initiate communication of the report to an
electronic health record system, e.g., a Personal Healthcare Record
system utilized by the patient.
[0083] In another example, in the context of a referring doctor
viewing a report, one or more links may enable the referring doctor
to: [0084] Send a message to a doctor that interpreted the exam and
generated the report. [0085] Send a message to a patient associated
with the report.
[0086] In various embodiments, report links including messaging
functionality may enable communications performed with secure
messaging, e.g., using protocols associated with the Direct Project
(www.directproject.org) and/or other secure messaging protocols.
Messages using any other messaging protocols and to other entities
may also be associated with report links such that messages may
more easily be transmitted by a viewer of the medical report.
[0087] In an embodiment, selection of messaging links may be
tracked. For example, an electronic communication of a referring
physician to a patient via systems and methods described herein
(for example, selection of messaging links) may be tracked. This
tracked messaging data may then by analyzed in order to, for
example, determine that the referring physician sent electronic
messages to a particular percentage of the referring physician's
patients. For example, messaging link tracking may determine that,
for example, 5% of a physician's patients were contacted
electronically, and/or that those patient responded. Such message
tracking may be valuable to the physician (or other entity using
the messaging functionality) to determine how to better
communicate. Additionally, in one embodiment tracking information
from multiple users (e.g., multiple physicians) may be analyzed
(e.g., such as in a de-personalized manner) in order to determine
messaging patterns across multiple users. For example, the tracking
data may be analyzed in order to determine statistics for
particular classes of physicians, for example, such as data
regarding an average number of customers that receive follow-up
electronic messages from pediatricians in Southern California
within three days of a child's laboratory visit.
Automatic Report User Identification and/or Authentication
[0088] In an embodiment, a report user may be identified and/or
authenticated automatically when a link is selected. For example,
referring to FIGS. 6A and 6B user identifying information (e.g.,
patient data in FIGS. 6A and 6B) may be included among the metadata
630 associated with a report. The user identifying information may
be associated with, for example, a referring physician who has
selected a scheduling link. Referring to FIG. 7A, when a referring
doctor selects a scheduling link, information identifying that
particular referring physician who selected the link may be
communicated to the scheduling system along with the patient
information (for example, via information embedded in the link or
metadata associated with the report).
[0089] In one embodiment, when a user enters a scheduling system
via a scheduling link in a report, the scheduling system may
identify and/or authenticate the user before the user is allowed to
proceed. For example, the user may be required to provide a login
and/or password. In embodiments in which user information is
automatically transferred to the scheduling systems along with the
patient information, the user's login and/or name may be
automatically provided to the scheduling system. In an example, the
user's login may automatically be filled in such that the user only
has to provide their password. In another example, all
authentication credentials may automatically be provided such that
the user is automatically identified and authenticated by the
scheduling system. In yet another example, the name of the user may
be provided to the scheduling system such that the user's name may
be compared against the credentials (login and password) provided
by the user to ensure the identified user matches the identity of
the user who selected the link.
[0090] In one example, the scheduling system may identify a user
who is authorized to order an exam on behalf of a referring
physician. In this embodiment, the scheduling system may
automatically enter the name of the ordering physician who has
authorized the user. In another example, identification and/or
authentication information used to allow the physician (or other
user) to view an exam may be automatically transmitted to the
scheduling system (or other system) so that the physician may not
have to provide credentials (e.g., login and password) to be
re-authenticated. Further, the name of the automatically
authenticated physician may be automatically indicated as the
ordering physician for the exam to be scheduled.
Example Computing Systems
[0091] FIG. 1A is a block diagram which shows the various
components of a system 100 for displaying information utilizing
certain systems and methods described herein. As shown, the system
100 may include an information display computing device 150 (also
referred to herein as a "computing device 150") and may include
other systems, including those shown in FIG. 1A. For example, other
systems may include various specialized computing systems including
an MRI scanner 120, a CT Scanner 122, a PACS System 136, a PACS
Workstation 138, a Radiology Information System 140, an Electronic
Medical Record (EMR) System 141, an Electronic Health Record (EHR)
System 142, a Laboratory Information System 144, a Digital
Pathology System 146, a web server 147, a Computer Aided Diagnosis
System 148, a 3D Processing System 149, a Scheduling System 123, a
Secure Database 124, and a Referring Physician System 125.
[0092] The computing device 150 may take various forms. In one
embodiment, the information display computing device 150 may be a
computer workstation having modules 151, such as software modules
that provide the functionality described above with reference to
the other figures.
[0093] In one embodiment, the information display computing device
150 comprises a server, a desktop computer, a workstation, a PACS
workstation, a laptop computer, a mobile computer, a smartphone, a
tablet computer, a cell phone, a personal digital assistant, a
gaming system, a kiosk, an audio player, any other device that
utilizes a graphical user interface, including office equipment,
automobiles, airplane cockpits, household appliances, automated
teller machines, self-service checkouts at stores, information and
other kiosks, ticketing kiosks, vending machines, industrial
equipment, and/or a television, for example.
[0094] The information display computing device 150 may run an
off-the-shelf operating system 154 such as a Windows, Linux, MacOS,
Android, or iOS, or mobile versions of such operating systems. The
information display computing device 150 may also run a more
specialized operating system which may be designed for the specific
tasks performed by the computing device 150, or any other available
operating system.
[0095] The information display computing device 150 may include one
or more computing processors 152. The computer processors 152 may
include central processing units (CPUs), and may further include
dedicated processors such as graphics processor chips, or other
specialized processors. The processors generally are used to
execute computer instructions based on the information display
software modules 151 to cause the computing device to perform
operations as specified by the modules 151. The modules 151 may
include, by way of example, components, such as software
components, object-oriented software components, class components
and task components, processes, functions, attributes, procedures,
subroutines, segments of program code, drivers, firmware,
microcode, circuitry, data, databases, data structures, tables,
arrays, and variables. For example, modules may include software
code written in a programming language, such as, for example, Java,
JavaScript, ActionScript, Visual Basic, HTML, C, C++, or C#. While
"modules" are generally discussed herein with reference to
software, any modules may alternatively be represented in hardware
or firmware. Generally, the modules described herein refer to
logical modules that may be combined with other modules or divided
into sub-modules despite their physical organization or
storage.
[0096] The information display computing device 150 may also
include memory 153. The memory 153 may include volatile data
storage such as RAM or SDRAM. The memory 153 may also include more
permanent forms of storage such as a hard disk drive, a flash disk,
flash memory, a solid state drive, or some other type of
non-volatile storage.
[0097] The information display computing device 150 may also
include or be interfaced to one or more display devices 155 that
provide information to the users. Display devices 155 may include a
video display, such as one or more high-resolution computer
monitors, or a display device integrated into or attached to a
laptop computer, handheld computer, smartphone, computer tablet
device, or medical scanner. In other embodiments, the display
device 155 may include an LCD, OLED, or other thin screen display
surface, a monitor, television, projector, a display integrated
into wearable glasses, or any other device that visually depicts
user interfaces and data to viewers.
[0098] The information display computing device 150 may also
include or be interfaced to one or more input devices 156 which
receive input from users, such as a keyboard, trackball, mouse, 3D
mouse, drawing tablet, joystick, game controller, touch screen
(e.g., capacitive or resistive touch screen), touchpad,
accelerometer, video camera and/or microphone.
[0099] The information display computing device 150 may also
include one or more interfaces 157 which allow information exchange
between information display computing device 150 and other
computers and input/output devices using systems such as Ethernet,
Wi-Fi, Bluetooth, as well as other wired and wireless data
communications techniques.
[0100] The modules of the information display computing device 150
may be connected using a standard based bus system. In different
embodiments, the standard based bus system could be Peripheral
Component Interconnect ("PCI"), PCI Express, Accelerated Graphics
Port ("AGP"), Micro channel, Small Computer System Interface
("SCSI"), Industrial Standard Architecture ("ISA") and Extended ISA
("EISA") architectures, for example. In addition, the functionality
provided for in the components and modules of information display
computing device 150 may be combined into fewer components and
modules or further separated into additional components and
modules.
[0101] The information display computing device 150 may communicate
and/or interface with other systems and/or devices. In one or more
embodiments, the computing device 150 may be connected to a
computer network 190. The computer network 190 may take various
forms. It may include a wired network or a wireless network, or it
may be some combination of both. The computer network 190 may be a
single computer network, or it may be a combination or collection
of different networks and network protocols. For example, the
computer network 190 may include one or more local area networks
(LAN), wide area networks (WAN), personal area networks (PAN),
cellular or data networks, and/or the Internet.
[0102] The information display computing device 150 may be
configured to interface with various networked computing devices
via the network 190 in order to provide efficient and useful review
of data that.
[0103] Depending on the embodiment, the other devices illustrated
in FIG. 1A may include some or all of the same components discussed
above with reference to the Information Display Computer Device
150.
[0104] FIG. 1B is a system diagram illustrating various components
of a system 200 for managing data utilizing certain systems and
methods described herein. As shown, the system 200 includes a
computing device 250 and may include other systems, including those
shown in FIG. 2.
[0105] The computing device 250 may take various forms. In one
embodiment, the computing device 250 may be a computer workstation
having modules 151. In other embodiments, modules 151 may reside on
another computing device, such as a web server, and the user
directly interacts with a second computing device that is connected
to the web server via a computer network. As mentioned above, the
modules 151 may be configured to cause the computing device to
perform operations implementing the functionality of the systems
and methods described herein and in reference to the other figures
above.
[0106] In one embodiment, the computing device 250 comprises a
server, a desktop computer, a workstation, a laptop computer, a
mobile computer, a Smartphone, a tablet computer, a cell phone, a
personal digital assistant, a gaming system, a kiosk, an audio
player, any other device that utilizes a graphical user interface,
including office equipment, automobiles, airplane cockpits,
household appliances, automated teller machines, self-service
checkouts at stores, information and other kiosks, ticketing
kiosks, vending machines, industrial equipment, and/or a
television, for example.
[0107] The computing device 250 may run an off-the-shelf operating
system 154 such as a Windows, Linux, MacOS, Android, or iOS. The
computing device 250 may also run a more specialized operating
system which may be designed for the specific tasks performed by
the computing device 250.
[0108] As with computing device 150 described herein with reference
to FIG. 1A, computing device 250 may include one more computing
processors 152, may include memory storage 153, may include or be
interfaced to one more display devices 155, may include or be
interfaced to one or more input devices 156, and/or may include one
or more interfaces 157.
[0109] Computing device 250 may communicate and/or interface with
other systems and/or devices via network 190, as described herein
with reference to FIG. 1A.
[0110] Also connected to network 190 may be a server 210 that
communicates with computing device 250, for example allowing
communication of images or other data (e.g., medical or non-medical
data, such as e-commerce data) between server 210 and computing
device 250.
[0111] FIG. 2 illustrates two mobile information display computing
devices. In particular, FIG. 2 illustrates a tablet computing
device 290 and a tablet computing device 295 that may execute a
mobile operating system such as iOS, Android, or Windows Mobile, or
that may execute desktop computer operating systems, such as those
discussed above with reference to the computing device 150. For
example, FIG. 2 shows an example of a user interacting with the
tablet computing device 290 on which is displayed a medical report
(including links), as described above. Additionally, FIG. 2 shows
an example of the user interacting with the tablet computing device
295 on which are displayed medical images. In the examples, the
tablet computing device 290 and the tablet computing device 295 may
be the same device, and the user may have been linked to the images
by selecting a link included in the medical report. Any references
herein to the Information Display Computer Device 150, or more
generally to a Computer Device or simply a computing device,
computing system, or computer, may refer to one of any suitable
computing device including some or all of the components of
computing devices 150 or 250. The devices of FIG. 2 utilize touch
screen input, but other input devices could be utilized on these
devices, as well as other devices, including a computer mouse,
keyboard, trackball, etc.
[0112] In various embodiments, various components of the devices
and systems described above with reference to FIGS. 1A, 1B, and 2,
may be used to implement the systems and methods described in the
present disclosure. In an embodiment, the medical report may be
generated by a device such as the computing device 150 (the
computing device 150 being in communication with various other
systems and data sources). In an embodiment, the medical report may
be transmitted over a network, for example, from one computing
device to another, as shown in FIGS. 1A, 1B, and 7. For example,
one or more of the server 210 and the computing device 250 may be
used to implement a system operated by the radiologist and/or the
referring doctor (of FIG. 7), and/or the scheduling system (as
shown in FIG. 7). Information and data may thereby be transmitted,
received, and/or processed by the various components of the systems
and methods described above. In an embodiment, the referring doctor
of FIG. 7 interacts with a system that may be referred to as a
referring doctor system or a referring physician system. In an
embodiment, as described above, the system may be used by a patient
that is accessing medical data and/or scheduling an
appointment.
Other
[0113] Conditional language, such as, among others, "can," "could,"
"might," or "may," unless specifically stated otherwise, or
otherwise understood within the context as used, is generally
intended to convey that certain embodiments include, while other
embodiments do not include, certain features, elements and/or
steps. Thus, such conditional language is not generally intended to
imply that features, elements and/or steps are in any way required
for one or more embodiments or that one or more embodiments
necessarily include logic for deciding, with or without user input
or prompting, whether these features, elements and/or steps are
included or are to be performed in any particular embodiment.
[0114] Any process descriptions, elements, or blocks in the flow
diagrams described herein and/or depicted in the attached figures
should be understood as potentially representing modules, segments,
or portions of code which include one or more executable
instructions for implementing specific logical functions or steps
in the process. Alternate implementations are included within the
scope of the embodiments described herein in which elements or
functions may be deleted, executed out of order from that shown or
discussed, including substantially concurrently or in reverse
order, depending on the functionality involved, as would be
understood by those skilled in the art.
[0115] All of the methods and processes described above may be
embodied in, and partially or fully automated via, software code
modules executed by one or more general purpose computers. For
example, the methods described herein may be performed by an
Information Display Computing Device and/or any other suitable
computing device. The methods may be executed on the computing
devices in response to execution of software instructions or other
executable code read from a tangible computer readable medium. A
tangible computer readable medium is a data storage device that can
store data that is readable by a computer system. Examples of
computer readable mediums include read-only memory, random-access
memory, other volatile or non-volatile memory devices, CD-ROMs,
magnetic tape, flash drives, and optical data storage devices.
[0116] Many variations and modifications may be made to the
above-described embodiments, the elements of which are to be
understood as being among other acceptable examples. All such
modifications and variations are intended to be included herein
within the scope of this disclosure. The foregoing description
details certain embodiments. It will be appreciated, however, that
no matter how detailed the foregoing appears in text, the disclosed
systems and methods can be practiced in many ways. As is also
stated above, the use of particular terminology when describing
certain features or aspects should not be taken to imply that the
terminology is being re-defined herein to be restricted to
including any specific characteristics of the features or aspects
of disclosed systems and methods with which that terminology is
associated.
* * * * *
References