U.S. patent application number 13/828741 was filed with the patent office on 2014-01-23 for remote monitoring of medical devices.
This patent application is currently assigned to CEPHEID. The applicant listed for this patent is CEPHEID. Invention is credited to Jan Steuperaert.
Application Number | 20140025809 13/828741 |
Document ID | / |
Family ID | 49947506 |
Filed Date | 2014-01-23 |
United States Patent
Application |
20140025809 |
Kind Code |
A1 |
Steuperaert; Jan |
January 23, 2014 |
REMOTE MONITORING OF MEDICAL DEVICES
Abstract
A remote monitoring system for medical data collection can
include a data-flagging process embeds authorization and settings
information into a file containing the test results. Such data
flagging can occur at a medical device or testing site, and may be
based in policy settings received from a remote system. A file
containing the test results can also include data category
information that can be used to protect sensitive information by
preventing such information from being communicated to the wrong
server.
Inventors: |
Steuperaert; Jan; (Le Faget,
FR) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
CEPHEID |
Sunnyvale |
CA |
US |
|
|
Assignee: |
CEPHEID
Sunnyvale
CA
|
Family ID: |
49947506 |
Appl. No.: |
13/828741 |
Filed: |
March 14, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61673612 |
Jul 19, 2012 |
|
|
|
Current U.S.
Class: |
709/224 |
Current CPC
Class: |
G16H 40/67 20180101;
H04L 63/102 20130101; G16H 10/40 20180101; H04L 43/06 20130101;
G16H 40/40 20180101; H04L 67/12 20130101 |
Class at
Publication: |
709/224 |
International
Class: |
H04L 12/26 20060101
H04L012/26 |
Claims
1. A computer-implemented method for processing test results of a
medical device, the method comprising: receiving, via a
communication interface, settings information indicative of one or
more authorization levels associated with an entity, wherein each
of the one or more authorization levels is indicative of a type of
data, from the test results of the medical device, to include in
reporting information; obtaining the test results from the medical
device; creating, with a processor, a file comprising the reporting
information, wherein the reporting information includes information
indicative of: the entity, the one or more authorization levels
associated with the entity, and at least a portion of the test
results; and sending the file via the communication interface.
2. The method of claim 1 further comprising: providing a user with
an interface configured to receive an input; and adjusting at least
one of the one or more authorization levels based, at least in
part, on the input.
3. The method of claim 1 further comprising adjusting, based on the
settings information, at least one of the following settings of the
medical device: a number of tests reported in a certain period of
time, a type of test to include in the reporting information, or a
starting date to provide the reporting information.
4. The method of claim 1 wherein the at least the portion of the
test results includes: a first data set associated with a first
authorization level; and a second data set associated with a second
authorization level.
5. The method of claim 1 wherein receiving the settings information
includes scanning a particular data location for the settings
information.
6. The method of claim 1 wherein sending the reporting information
includes storing the reporting information in a particular data
location for transmittal.
7. The method of claim 1 further including formatting the reporting
information in a meta-language.
8. The method of claim 1 wherein the reporting information further
includes an identifier of the medical device.
9. The method of claim 1 wherein creating the file further
comprises including, in the reporting information, a cartridge
identifier related to the at least the portion of the test
results.
10. The method of claim 1 wherein creating the file further
comprises including, in the reporting information, data category
information related to at least a portion of the reporting
information.
11. A computer-readable storage medium having computer-executable
instructions embedded thereon for processing test results of a
medical device, the computer-readable storage medium including
instructions for: receiving settings information indicative of one
or more authorization levels associated with an entity, wherein
each of the one or more authorization levels is indicative of a
type of data, from the test results of the medical device, to
include in reporting information; obtaining the test results from
the medical device; creating a file comprising the reporting
information, wherein the reporting information includes information
indicative of: the entity, the one or more authorization levels
associated with the entity, and at least a portion of the test
results; and sending the file via the communication interface.
12. The computer-readable storage medium of claim 11 further
comprising instructions for: providing a user interface configured
to receive an input; and adjusting at least one of the one or more
authorization levels based, at least in part, on the input.
13. The computer-readable storage medium of claim 11 further
comprising instructions for adjusting, based on the settings
information, at least one of the following settings of the medical
device: a number of tests reported in a certain period of time, a
type of test to include in the reporting information, or a starting
date to provide the reporting information.
14. The computer-readable storage medium of claim 11 further
comprising instructions for formatting the reporting information
such that: a first data set of the at least the portion of the test
results is associated with a first authorization level; and a
second data set of the at least the portion of the test results is
associated with a second authorization level.
15. The computer-readable storage medium of claim 11 wherein the
instructions for sending the reporting information include
instructions for storing the reporting information in a particular
data location for transmittal.
16. The computer-readable storage medium of claim 11 further
including instructions for formatting the reporting information in
a meta-language.
17. The computer-readable storage medium of claim 11 further
including instructions for including, in the reporting information,
an identifier of the medical device.
18. The computer-readable storage medium of claim 11 wherein the
instructions for creating the file further comprise instructions
for including, in the reporting information, a cartridge identifier
related to the at least the portion of the test results.
19. The computer-readable storage medium of claim 11 wherein the
instructions for creating the file further comprise instructions
for including, in the reporting information, data category
information related to at least a portion of the reporting
information.
20. A computer-implemented method for reporting test results from a
medical device, the method comprising: receiving, via a
communication interface, reporting information indicative of the
test results from the medical device, wherein the reporting
information includes information indicative of: an entity, one or
more authorization levels associated with the entity, wherein each
of the one or more authorization levels is indicative of a type of
data from the test results of the medical device, and at least a
portion of the test results; receiving a request to report the test
results, the request associated with the entity; determining, with
a processor, a subset of the at least the portion of the test
results to report based, at least in part, on: the one or more
authorization levels, and the entity; and providing a report based,
at least in part, on the subset.
21. The method of claim 20 wherein the report is provided via a
web-based portal.
22. The method of claim 20 wherein the reporting information
further includes an identifier of the medical device, the method
further comprising: determining a location associated with the
medical device based, at least in part, on the identifier; and
providing an indication of the location in the report.
23. The method of claim 20 further including sending, via the
communication interface, settings information indicative of the one
or more authorization levels associated with the entity.
24. The method of claim 20 wherein the report is based, at least in
part, on test results from a plurality of medical devices.
25. A system for reporting medical test results, the system
comprising: a first server configured to send settings information
indicative of one or more authorization levels associated with an
entity; at least one medical device configured to: receive the
settings information; create reporting information regarding test
results of a test conducted by the at least one medical device,
wherein creating the reporting information includes embedding the
reporting information with information indicative of: the entity,
the one or more authorization levels associated with the entity,
and at least a portion of the test results; and send the reporting
information; and a second server configured to: receive the
reporting information from the at least one medical device; receive
a request to report the test results of the at least one medical
device, the request associated with the entity; determine a subset
of the at least the portion of the test results to report, based on
the reporting information; and provide a report based, at least in
part, on the subset.
26. The system of claim 25 wherein the report is provided via a
web-based portal.
27. The system of claim 25 wherein: the at least one medical device
is configured to include, in the reporting information, an
identifier of the at least one medical device; and the second
server is further configured to: determine a location associated
with each of the at least one medical device, at least in part, on
the identifier; and provide an indication of the location in the
report.
28. The system of claim 25 wherein the second server is the same
server as the first server.
29. The system of claim 25 wherein the first server is configured
to send settings information regarding at least one of the
following settings of the at least one medical device: a number of
tests reported in a certain period of time, a type of test to
include in the reporting information, or a starting date to provide
the reporting information.
Description
CROSS-REFERENCES TO RELATED APPLICATIONS
[0001] This application claims benefit under 35 USC 119(e) of U.S.
Provisional Application No. 61/673,612, filed on Jul. 19, 2012, the
entire disclosure of which is incorporated by reference herein for
all purposes.
BACKGROUND
[0002] Medical data collection can involve remotely monitoring a
distributed network of medical devices, such as molecular
diagnostic systems and/or other testing devices, and aggregating
and processing the data provided by these medical devices into
useable information. Because the medical devices may be located
throughout the world, the information can be used by a host of
entities, such as governments, hospitals, and other institutions to
not only monitor the status of individual medical devices, but also
to decipher large-scale epidemiological data and determine other
valuable health and disease information. Current aggregation and
processing of data from such medical data collection, i.e., sifting
through data as it trickles in from the medical devices, can be
restrictive. And because different entities (institutions and
individuals) want to view different types of data from the medical
devices, it can be difficult to provide personalized reporting data
to a requesting entity in a quick manner (e.g., in real time).
BRIEF SUMMARY
[0003] Embodiments of the current invention provide for a remote
monitoring system for medical data collection that includes a
data-flagging process that embeds authorization and settings
information into a file containing the test results. Such data
flagging can occur at a medical device or testing site, and may be
based in policy settings received from a remote system. A file
containing the test results can also include data category
information that can be used to protect sensitive information by
preventing such information from being communicated to the wrong
server.
[0004] In some embodiments, a computer-implemented method for
processing test results of a medical device, according to the
disclosure, can comprise receiving, via a communication interface,
settings information indicative of one or more authorization levels
associated with an entity. Each of the one or more authorization
levels is indicative of a type of data, from the test results of
the medical device, to include in reporting information. The method
can further comprise obtaining the test results from the medical
device, and creating, with a processor, a file comprising the
reporting information. The reporting information can comprise
information indicative of the entity, the one or more authorization
levels associated with the entity, and at least a portion of the
test results. The method can also comprise sending the file via the
communication interface.
[0005] In some embodiments, the method optionally can comprise one
or more of the following features. The method can comprise
providing a user with an interface configured to receive an input,
and adjusting at least one of the one or more authorization levels
based, at least in part, on the input. The method can comprise
adjusting, based on the settings information, at least one of the
following exemplary settings of the medical device: a number of
tests reported in a certain period of time, a type of test to
include in the reporting information, or a starting date to provide
the reporting information. Additional settings that may be included
and adjusted will be well known to persons of ordinary skill in the
art. The at least the portion of the test results can comprise a
first data set associated with a first authorization level, and a
second data set associated with a second authorization level.
Additional data sets and authorization levels can also be included.
Receiving the settings information can comprise scanning a
particular data location for the settings information. Sending the
reporting information can comprise storing the reporting
information in a particular data location for transmittal. The
method can comprise formatting the reporting information in a
meta-language. The reporting information can also comprise an
identifier of the medical device. Creating the file can also
comprise including, in the reporting information, a cartridge
identifier related to the at least the portion of the test results
and/or data category information related to at least a portion of
the reporting information.
[0006] In some embodiments, a computer-readable storage medium,
according to the disclosure, has computer-executable instructions
embedded thereon for processing test results of a medical device.
The computer-readable storage medium can comprise instructions for
receiving settings information indicative of one or more
authorization levels associated with an entity. Each of the one or
more authorization levels is indicative of a type of data, from the
test results of the medical device, to include in reporting
information. The computer-readable storage medium can also comprise
instructions for obtaining the test results from the medical
device, and creating a file comprising the reporting information.
The reporting information can comprise information indicative of
the entity, the one or more authorization levels associated with
the entity, and at least a portion of the test results. The
computer-readable storage medium further includes instructions for
sending the file via the communication interface.
[0007] In some embodiments, the computer-readable storage medium
optionally can comprise one or more of the following features. The
computer-readable storage medium can include instructions for
providing a user interface configured to receive an input, and
adjusting at least one of the one or more authorization levels
based, at least in part, on the input. The computer-readable
storage medium can comprise instructions for adjusting, based on
the settings information, at least one of the following settings of
the medical device: a number of tests reported in a certain period
of time, a type of test to include in the reporting information, or
a starting date to provide the reporting information. Additional
settings that may be included and adjusted will be well known to
persons of ordinary skill in the art. The computer-readable storage
medium can comprise instructions for formatting the reporting
information such that a first data set of the at least the portion
of the test results is associated with a first authorization level,
and a second data set of the at least the portion of the test
results is associated with a second authorization level. Additional
data sets and authorization levels can also be included. The
instructions for sending the reporting information can comprise
instructions for storing the reporting information in a particular
data location for transmittal. The computer-readable storage medium
can include instructions for formatting the reporting information
in a meta-language. The computer-readable storage medium can
comprise instructions for including, in the reporting information,
an identifier of the medical device and/or a cartridge identifier
related to the at least the portion of the test results. The
instructions for creating the file further can comprise
instructions for including, in the reporting information, data
category information related to at least a portion of the reporting
information.
[0008] In some embodiments, a computer-implemented method for
reporting test results from a medical device, according to the
description, can comprise receiving, via a communication interface,
reporting information indicative of the test results from the
medical device. The reporting information can comprise information
indicative of an entity, one or more authorization levels
associated with the entity, where each of the one or more
authorization levels is indicative of a type of data from the test
results of the medical device, and at least a portion of the test
results. The method further can comprise receiving a request to
report the test results, where the request associated with the
entity, and determining, with a processor, a subset of the at least
the portion of the test results to report based, at least in part,
on the one or more authorization levels and the entity. The method
can also comprise providing a report based, at least in part, on
the subset.
[0009] In some embodiments, the method optionally can comprise one
or more of the following features. The report can be provided via a
web-based portal. The reporting information can further comprise an
identifier of the medical device, and the method can further
comprise determining a location associated with the medical device
based, at least in part, on the identifier, and providing an
indication of the location in the report. The method can include
sending, via the communication interface, settings information
indicative of the one or more authorization levels associated with
the entity. The report can be based, at least in part, on test
results from a plurality of medical devices.
[0010] In some embodiments, a system for reporting medical test
results, according to the description, can comprise a first server
configured to send settings information indicative of one or more
authorization levels associated with an entity, and at least one
medical device. The at least one medical device is configured to
receive the settings information create reporting information
regarding test results of a test conducted by the at least one
medical device. Creating the reporting information can comprise
embedding the reporting information with information indicative of
the entity, the one or more authorization levels associated with
the entity, and at least a portion of the test results. The at
least one medical device further is configured to send the
reporting information. The system can also comprise at least a
second server configured to receive the reporting information from
the at least one medical device, and receive a request to report
the test results of the at least one medical device, where the
request associated with the entity. The at least second server
further is configured to determine a subset of the at least the
portion of the test results to report, based on the reporting
information, and provide a report based, at least in part, on the
subset.
[0011] In some embodiments, the system optionally can comprise one
or more of the following features. The report can be provided via a
web-based portal. The at least one medical device can be configured
to comprise, in the reporting information, an identifier of the at
least one medical device, and the at least second server can be
further configured to determine a location associated with each of
the at least one medical device, at least in part, on the
identifier, and provide an indication of the location in the
report. The at least second server can be the same server as the
first server. The first server can be configured to send settings
information regarding at least one of the following settings of the
at least one medical device: a number of tests reported in a
certain period of time, a type of test to include in the reporting
information, or a starting date to provide the reporting
information.
[0012] Numerous benefits are achieved by way of the present
invention over conventional techniques. For example, data-flagging
test results with authorization settings can allow for reliable,
real-time data filtering based on the authorization type of an
entity attempting to view the reporting results. The reporting
results can be shown using geographical maps and/or other
techniques to show up-to-date test result information that can
enable an entity to quickly react to infectious outbreaks or other
medical phenomena. These and other embodiments of the invention,
along with many of its advantages and features, are described in
more detail in conjunction with the text below and attached
figures.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] A further understanding of the nature and advantages of
various embodiments may be realized by reference to the following
figures. In the appended figures, similar components or features
may have the same reference label.
[0014] FIGS. 1A and 1B are simplified block diagrams showing two
example configurations of a distributed network capable of
performing the data-flagging processes described herein.
[0015] FIG. 2 is a simplified block diagram that illustrates
various components of a medical device configured to provide
flagged test results (or other medical data).
[0016] FIG. 3 is an exemplary illustration of a reporting policies
user interface, providing an example of how a viewing entity can be
granted certain authorization levels.
[0017] FIG. 4 illustrates the content of a reporting policies file,
corresponding to the exemplary reporting policies shown in FIG.
3.
[0018] FIG. 5 is an exemplary illustration of a local reporting
settings user interface, providing an example of how a lab user can
implement the reporting policies from a reporting policies
file.
[0019] FIG. 6 illustrates the content of a reporting file,
corresponding to the exemplary reporting policies shown in FIGS.
3-5.
[0020] FIG. 7 is a flow diagram illustrating an exemplary
computer-implemented method for processing test results of a
medical device.
[0021] FIG. 8 is a flow diagram illustrating an exemplary process
for reporting test results from a medical device that are flagged
with authorization information.
[0022] FIG. 9 is an exemplary illustration of a computer system,
which may be incorporated, at least in part, into devices
configured to perform some or all of the methods described
herein.
DETAILED DESCRIPTION
[0023] Some embodiments of the current invention provide for a
remote monitoring system for medical data collection that includes
a data-flagging process in which authorization and settings
information can be embedded into a file containing the test
results. Such data flagging can allow for reliable, real-time data
filtering based on the authorization type of an entity attempting
to view the reporting results (hereafter "viewing entity").
Although embodiments provided herein relate to the gathering and
processing of medical data, such as medical test results, the
features and techniques disclosed can be extended to other
distributed networks where levels of authorization are utilized to
access different amounts and/or types of data collected by the
network.
[0024] FIGS. 1A and 1B are simplified block diagrams showing two
example configurations of a distributed network 100 capable of
performing the data-flagging processes described herein. Some
embodiments may differ from the examples shown. For example, some
embodiments can combine, separate, add to, and/or omit components
shown in FIGS. 1A and 1B. Furthermore, the functionality of each of
the components can be provided by one or more devices (e.g.,
computing devices) disposed in one or more geographical
locations.
[0025] A first distributed network 100-1 is shown in FIG. 1A. In
this embodiment, the first distributed network 100-1 includes one
or more medical devices 140, a transportation platform 130, a data
center/web portal 120, one or more user devices 150, and data
communication network(s) 110 communicatively coupling these
components together. Medical data is provided by the one or more
medical devices 140. As described in more detail below, medical
devices 140, such as molecular diagnostic systems, can comprise a
combination of testing and computing components configured to
gather data from and/or conduct medical tests. The one or more
medical devices 140 can be located at various different geographic
locations to help provide large-scale epidemiological data and
determine other valuable health and disease information among one
or more populations.
[0026] The transportation platform 130 can facilitate the
transportation of data between the data center/web portal 120 and
the one or more medical devices 140. It can include components
(e.g., software) installed on the one or more medical devices 140
and/or utilized by the data center/web portal 120, as well as
components (e.g., software and/or hardware) for data storage and/or
processing functionality. With these capabilities, the
transportation platform 130 can deliver data between the one or
more medical devices 140 and the data center/web portal 120 in a
secure and automated manner, providing any needed formatting and/or
other changes to the data being transported. In some embodiments,
the transportation platform 130 can further include diagnostic
services such as monitoring parameters collected on the one or more
medical devices 140, generating corresponding alerts, and
interacting with the one or more medical devices 140 by sending
files, by desktop sharing, and/or by upgrading software.
[0027] The data center/web portal 120 can aggregate and process
medical data and provide a viewing entity with the processed
medical data in various forms (e.g., lists, graphs, geographic
maps, and the like) in accordance with the viewing entity's level
of authorization. Furthermore, the data center/web portal 120,
which can include one or more centralized or distributed computer
systems (e.g., computer servers), can also provide an institution
administrator with an interface to enable the institution
administrator to set one or more reporting policies that can
determine the authorization levels associated with the medical
data. The data center/web portal 120 can provide a web-based portal
and/or other user interface to enable the viewing entities and/or
institution administrator to communicate with the data center/web
portal 120 using one or more user devices 150. The one or more user
devices 150 can include any of a variety of devices, such as a
computer terminal, personal computer, tablet, smart phone, and the
like. Depending on desired functionality, the one or more user
devices 150 can communicate with the data center/web portal 120 via
an Internet browser and/or specialized software application
executed on the one or more user devices 150. Different components
of the data center/web portal 120 may execute different tasks. In
some embodiments, a first server can be utilized to set reporting
policies, while a second, third, or more server(s) can be utilized
to provide a report of test results. In some embodiments, both
tasks can be performed on a single server (or other computer
system).
[0028] The data communication network(s) 110 enables communication
between other components of the distributed network 100. The data
communication network(s) 110 can comprise any combination of a
variety of data communication systems, for example, cable,
satellite, wireless/cellular, or Internet systems, or the like,
utilizing various technologies and/or protocols, such as radio
frequency (RF), optical, satellite, coaxial cable, Ethernet,
cellular, twisted pair, other wired and wireless technologies, and
the like. The data communication network(s) 110 can comprise
packet- and/or circuit-type switching, and can include one or more
open, closed, public, and/or private networks, including the
Internet, depending on desired functionality, cost, security, and
other factors.
[0029] With these components, the distributed network 100 can
implement a data-flagging process that merges authorization and
settings information into a file containing the test results.
Reliable, real-time data filtering based on the authorization type
of a viewing entity can then be performed on the test results to
provide responsive reporting. This data-flagging process begins
when an institution administrator (e.g., an authorized user from a
hospital, doctor's office, university, or other institution that
owns and/or operates the medical devices 140) defines the one or
more reporting policies for certain test results. In some
embodiments, an institution administrator can utilize a user device
150 to access a web-based portal and indicate reporting policies
that determine which tests are reported, how often the tests are
reported, the effective dates to implement the reporting (e.g., a
starting date to start the reporting), and more. Reporting policies
can also define which viewing entities may access the reporting
results, and a level of authorization each viewing entity will
have. In some exemplary embodiments, an institution administrator
can create reporting policies to grant a viewing entity, such as
the World Health Organization (WHO) one or more levels of
authorization to review certain test results. These levels of
authorization determine the types of data reported to the viewing
entity (e.g., WHO).
[0030] Once the reporting policies are finalized, they can be
packaged in a reporting policies file (e.g., an XML file) and
distributed to one or more of the institution's medical devices 140
in the distributed network 100. (The reporting policies file may
identify the medical devices 140 to which the reporting policies
file is to be distributed.) The recipient medical devices 140 can
process the reporting policies file and implement the reporting
policies accordingly. When medical tests are completed, the medical
devices 140 can include the test results in one or more test result
files, which are transmitted by the transportation platform 130 to
the data center/web portal 120 according to the reporting policies.
The test result files can be "flagged," or embedded, with
information regarding the authorization levels of reports for each
viewing entity. With the authorization included with the test
results in a single file in this manner, the data center/web portal
120 can manipulate the data for each viewing entity in real time
with little additional processing via, for example, a web-based
portal.
[0031] The data provided to the viewing entity can vary, depending
on, among other things, authorization levels. The distributed
network 100 can include medical devices 140 from multiple
institutions, allowing a viewing entity to receive aggregate data
from different institutions. The data center/web portal 120 also be
configured to provide the location of medical devices 140 on a map,
and may allow a lab user, the institution administrator, and/or
another authorized user to associate a particular medical device
140 with a specific location. The map not only can indicate the
location of medical devices 140, but can also indicate
corresponding test results for those medical devices 140.
[0032] Embodiments of a distributed network 100 of may provide the
functionality described herein independent of other systems.
Nonetheless, some embodiments may incorporate and/or be used in
conjunction with other systems, such as a Laboratory Information
System (LIS) (also known as a Laboratory Management System or
Laboratory Information Management System). In so doing, some
embodiments can, in addition to providing the functionality
described herein, provide sample tracking and management, assay
data management, data mining, data analysis, electronic laboratory
notebook (ELN), and other functions, depending on desired
functionality.
[0033] The second distributed network 100-2 shown in FIG. 1B
illustrates an embodiment of a distributed network 100 having an
LIS incorporated therein. The second distributed network 100-2 of
FIG. 1B has many of the same components as the first distributed
network 100-1 of FIG. 1A, which can provide the same and/or similar
functionality as described above in relation to FIG. 1A. The second
distributed network 100-2, however, also includes an LIS 180
communicatively coupled with the medical devices 140, thereby
enabling the second distributed network 100-2 to receive data from
and/or provide data to the LIS 180 of one or more institutions.
[0034] An institution server 160, which may be provided and/or
maintained by an institution, is also connected with the medical
devices 140 and LIS 180. The institution server 160 can be
communicatively coupled with the medical devices 140 and/or LIS 180
via, for example, a private local area network (LAN) and/or wide
area network (WAN). The transportation functionality of the
transportation platform 130 of FIG. 1A can also be provided, in
whole or in part, by the institution server 160. Some embodiments
can utilize both an institution server 160 and a transportation
platform 130. Additionally, the institution server 160 can monitor
all medical devices 140 of a particular institution, aggregate and
report medical device data for reporting to the institution, and/or
report medical device data to the data center/web portal 120.
Although only one institution server 160 is shown, many institution
servers 160 may exist in a distributed network 100 in which test
results for medical devices 140 of many institutions are
processed.
[0035] An internal data server 170 can be maintained by a service
provider of the second distributed network 100-2, enabling the
service provider to communicate with the medical devices 140, data
center/web portal 120, and/or other components of the second
distributed network 100-2 to manage devices, access rights, and
more. In some embodiments, the internal data server 170 can, along
with the institution server 160 and data center/web portal 120,
collect and maintain data from medical devices 140 for analysis
and/or integration with other applications.
[0036] In the second distributed network 100-2, data from test
results of the medical devices 140 can be relayed from the
institution server 160 to the data center/web portal 120, and from
the data center/web portal 120 to the internal data server 170. The
content of the data communicated at each of these stages can vary,
and may be governed by relevant governmental regulations. For
example, an institution server 160 may maintain patient data
corresponding to particular test results that is not relayed to the
data center/web portal 120 or internal data server 170 in order to
comply with, for example, the Health Insurance Portability and
Accountability Act (HIPAA) Privacy Rule and/or other such
regulations.
[0037] To help ensure that a system does not receive information it
should not be able to access, the institution server 160, data
center/web portal 120, and/or internal data server 170 can
implement server protection policies to help prevent the
transmittal of certain data. These server protection policies can
be defined by institution administrator and stored by the
institution server 160, which relays the server protection policies
to the other systems.
[0038] In some embodiments, the server protection policies can be
implemented in a two-phase communication protocol between child
system (i.e. a system sending test result information) and parent
system (i.e., a system receiving the test result information).
First, the child system sends an initiation message to the parent
system containing the data category and the owner of the dataset to
come next, in addition to child system and message identifiers. The
parent system sends a response message back to accept or reject the
initiation message, depending on the owner, data category
information, and the parent system's own server protection
settings. If the parent system accepts the initiation message, the
child system will send the dataset. But if the parent system
rejects the initiation message, the child system will not send the
dataset, thereby preventing the parent system from ever receiving
information it should not have access to, according to server
protection policies.
[0039] The data categories used in the server protection policies
can vary, depending on implementation. Administrators can define
and/or specify which data categories are allowed inbound from
specific owners. Moreover, the server protection policies can be
configured to allow data from certain data categories to be sent by
particular systems. For example, patient data may be communicated
from the institution server 160 to the internal data server 170 in
instances where both are maintained by the same entity.
[0040] In some embodiments, distributed networks 100 can vary from
those shown in FIGS. 1A and 1B. For example, additional medical
devices 140, institution servers 160, data center/web portals 120,
and/or internal data servers 170 can be added. For example,
multiple data center/web portals 120 can be utilized to report to
different agencies (e.g., WHO, GMO, etc.). Additional systems can
be "daisy chained" to add additional reporting layers, and each
layer can be configured with different settings as to what is
reported and to which level of detail. In some embodiments, the
systems of the distributed networks 100 can be configured to report
data to multiple other systems (i.e., a child system can report to
multiple parent systems). The data sent and corresponding server
protection policies can vary for each parent/child relationship.
For example, a medical device can send disease results to the
institution server 160 and report technical issues directly to the
data center/web portal 120.
[0041] FIG. 2 is a simplified block diagram that illustrates
various components of a medical device 140 configured to provide
flagged test results (or other medical data). Components can be
implemented, for example, using a combination of software and
hardware, which can be incorporated into a computer system (such as
that described in relation to FIG. 9). As with other embodiments
provided herein, the medical device 140 shown in FIG. 2 is provided
as a non-limiting exemplary embodiment. Various embodiments can
combine, separate, add, and/or omit various components. For
example, some embodiments can omit the transport agent installer
260 and perform similar functionality through other modules and/or
means. A person of ordinary skill in the art will recognize various
modifications that fall within the scope of the present
invention.
[0042] Transport agent installer 260 and transport agent 270 are
components of the medical device 140 that enable the medical device
140 to utilize the transportation platform 130. The transport agent
installer 260 can help ensure proper setup between the medical
device 140 and the transportation platform 130. Upon setup, a lab
user 290 (or other user of the medical device) can provide the
reporting policies user interface (UI) 210 with address and contact
information, as well as device identification information (e.g.,
model number, serial number, and/or other identifier), which is
sent, via communication link 280, to the data center/web portal
120, which can assign the device to an institution and location. In
some embodiments, the data center/web portal 120 can be configured
to assign the medical device to a specific location automatically,
based on location data from a network device (e.g., cell phone
tower, wireless access point, etc.) and/or other location
information.
[0043] A transport agent 270 can receive a reporting policies file
that describes the reporting policies of certain test results, and
place it in storage 250 for retrieval by the test monitor 240. In
some embodiments, for example, the reporting policies file can be
placed in a particular data location (e.g., a "policy" folder),
that is periodically scanned or otherwise checked by the test
monitor 240. Using the reporting policies user interface (UI) 210,
the test monitor 240 can then request the lab user 290 to confirm
the reporting policies, if applicable, before implementing the
policy as a reporting setting on the medical device 140. In some
embodiments, depending on functionality and ethical concerns, a
reporting policy may impact medical tests carried out by testing
hardware 230, in which case the test monitor 240 can communicate
with the testing software 220 to ensure that testing is carried out
accordingly.
[0044] Depending on desired functionality, testing software 220
and/or other components of the medical device 140 can be configured
to allow the lab user 290 to append test results with custom data.
In some embodiments, the testing software 220 can provide the lab
user 290 with a form for entering the appended data, which can be
customized to meet a specific institution's needs. The form can
indicate the field type, the field label, and the data category of
the field (which can be used in the server protection policies
previously described). Table 1 provides an example of the data
fields for a flu testing form:
TABLE-US-00001 TABLE 1 Flu Testing Form Label Type Data Category
Decade age List of ranges Patient demographics Patient zip code
10-character string Patient demographics Cell count (ppm) Number
Patient result Extra notes Freeform text Patient ID
Here, because freeform text may include a patient name, the data
category can include a corresponding indication as a precautionary
measure.
[0045] When using the testing software 220, the lab user 290 can
select a form to use and enter in the corresponding data. The
medical device 140 can verify particular custom data received
against the data type indicated in the form. If not compliant, the
data in the non-complying field can be replaced by an error code so
that the situation can be detected. This verification mechanism can
allow an institution to design communication directly from new or
pre-existing application to the functionality of adding custom data
provided by the testing software 220.
[0046] Custom data can be applied to test results of the medical
device 140 in several ways. For example, the lab user 290 can scan
the barcode(s) of a specific assay cartridge(s) or specify a time
range for which the data is to be applied to test results. The
custom data (e.g., cartridge identifier, lot identifier, etc.) of
the form is then appended to and reported with test results of the
medical device 140. By enabling custom data to be appended to test
results in this manner, this custom data can be linked to specific
lots, cartridges, diagnostic results, laboratory location, and
more. This can allow for various trend detection in the aggregate
data, with better medical value than trending the test result alone
would provide. It can also provide for easier error detection where
it is determined that certain lots may have been subject to errors,
certain cartridges were defective, etc.
[0047] Reporting policies can impact various aspects of medical
data collection to accommodate various different reporting
preferences. In some embodiments, reporting policies can be private
or public. Private policies can be propagated to medical devices
140 associated with a particular institution. Public policies can
be propagated to medical devices 140 of multiple institutions
(e.g., all institutions in a given list of countries). In some
embodiments, institution administrators for each of the receiving
institutions can be notified of these public reporting policies and
can approve them before they are sent to their respective medical
devices 140.
[0048] Reporting policies can include a variety of other
information. In some embodiments for example, policies can
determine the type of tests that are reported and included in
reporting, how often the tests are repeated (e.g., the number of
tests reported in a certain period of time), a starting date to
provide the reporting information (which can include information
from tests conducted prior to the policy date), categories of test
data to report, and the like. Depending on desired functionality, a
medical device 140 can provide a lab user 290 with the option to
approve, override, and/or change some or all reporting policies
before they are implemented in the medical device 140 as reporting
settings.
[0049] Reporting policies can provide one or more authorization
levels to a viewing entity by indicating categories of test data
(i.e. data sets) that can be reported to the viewing entity. FIG. 3
is an illustration of a reporting policies user interface 300,
providing an example of how a viewing entity can be granted certain
authorization levels. In this example, the reporting policies user
interface 300, which can be shown on a screen or other electronic
display of a user device 150 (e.g., a computer monitor), enables an
institution administrator to select various categories of test data
to be shown to the viewing entity, or reporting group, named
"Institute01." For each category of data (namely, "Basic," "Assay
info," "Details," "Support," "System User," and "Test Results"),
the institution administrator is given the option to include the
category in reporting for Institute01 ("Force on"), exclude the
category from reporting for Institute01 ("Force off"), or allow a
lab user 290 to decide whether to include a particular category of
data ("Allow user").
[0050] As indicated above, reporting policies can include a variety
of other data. Thus, the reporting policies user interface 300 can
include options to adjust other reporting policies. In the example
shown in FIG. 3, the reporting policies user interface 300 allows a
user to "activate" the reporting policies (i.e., send the reporting
policies to medical devices 140 of the institution), make the
reporting policies public, edit the list of countries associated
with public reporting policies, edit the reagents involved in the
medical tests, and save or cancel edits to the reporting policies
for the viewing entity. Depending on desired functionality and
available reporting policies, embodiments of a reporting policies
user interface 300 can include additional and/or alternative
options for defining and/or adjusting reporting policies.
[0051] FIG. 4 illustrates the content 400 of a reporting policies
file, corresponding to the exemplary reporting policies shown in
FIG. 3. Among other things, the content 400 of the reporting
policies file indicates the name of a viewing entity
("Institute01"), the policy ID of the reporting policies file
("0123456"), the type of test (assay) to report ("Xpert MTB/Rif"),
a start date ("2011/01/01 00:00:00.0001"), and a number of tests to
be reported per cycle ("5"). The content 400 of the reporting
policies further indicates the authorization levels associated with
the viewing entity ("Institute01"), corresponding to the categories
of data that can be included in subsequent reporting. Specifically,
authorization levels/categories of data entitled "Basic," "Assay,"
and "Result" are included in reporting; "Details" and "Support" are
not; and "SystUser" can be included if authorized by a lab user.
(As shown in FIGS. 3 and 4, the names of authorization
levels/categories of data included in the content 400 of the
reporting policies do not need to match the names indicated in
reporting policies user interface 300.) As indicated previously,
the reporting policies file is distributed to one or more
corresponding medical devices 140. Although the file in FIG. 4 is
provided in XML format, embodiments may utilize reporting policies
files provided in another meta-language and/or format.
[0052] Once the reporting policies file is received by a medical
device 140, the medical device can notify a lab user 290 of the
receipt and enable the lab user 290 to implement the reporting
policies as reporting settings on the medical device 140. FIG. 5 is
an illustration of a local reporting settings user interface 500,
providing an example of how a lab user can implement the reporting
policies from a reporting policies file.
[0053] FIG. 5 continues the example shown in FIGS. 3 and 4, with
corresponding categories of data. In this example, the local
reporting settings user interface 500 indicates that certain
categories of data ("Basic," "Support," "System User," and "Test
Results"), are selected for reporting to the viewing entity
"Institute01," while other categories of data ("Assay Info" and
"Details") are not selected. Here, the local reporting settings
user interface 500 implements the restrictions of the reporting
policies file by enabling only one category of data, "Support," for
selection (or deselection) by the lab user 290. In this example,
the local reporting settings user interface 500 also allows the lab
user 290 to enable basic reporting of tests and error codes, as
well as save or cancel the lab user's changes made on the local
reporting settings user interface 500.
[0054] Once the reporting policies are saved as reporting settings
on the medical device 140, the medical device 140 can then report
the test results accordingly. Referring again to FIG. 2, the
reporting settings UI 210, which can display the local reporting
settings user interface 500, can report selections made by the lab
user 290 to the test monitor 240, which can store the corresponding
reporting settings in storage 250. According to one embodiment, a
resident agent subcomponent of the test monitor can periodically
check the reporting settings to determine the reporting needed,
query a database maintained by the testing software 220 to
determine whether there are test results to be reported, and
produce one or more reporting files containing the test results
with the level of detail requested by corresponding reporting
policy file(s). Depending on desired functionality, the test
monitor 240 can then deliver the one or more reporting files to the
transport agent 270 directly, or place it in storage 250 for
retrieval by the transport agent 270. In some embodiments, the one
or more reporting files can be placed in a particular data location
(e.g., a "test results" folder), which is periodically checked by
the transport agent 270. The transport agent 270 then delivers the
one or more reporting files to the data center/web portal 120 for
data aggregation and reporting to corresponding viewing
entities.
[0055] FIG. 6 illustrates the content 600 of a reporting file,
corresponding to the exemplary reporting policies shown in FIGS.
3-5. Among other things, the content 600 of the reporting file
indicates the authorization levels of each viewing entity to which
the results are reported in a section labeled "<Policies>",
reflecting the policies included in one or more reporting policies
files, and "flagging" (embedding) the test result data with
authorization information. The viewing entity "Institute01," for
example, is provided "Basic," "Assay," "Result," and "SystUser"
authorization levels, corresponding to the selected data category
types shown in FIG. 5. Additionally, a viewing entity named "WHO"
is provided "Basic" and "Result" authorization levels. The data
associated with each of the authorization levels is provided in the
"<Test>" portion of the content 600 of the reporting file,
along with additional information in the "<ID>" sub-portion
regarding the medical device 140 and corresponding medical
test.
[0056] Embedding the authorization information in reporting files
in this manner can be advantageous for the data center/web portal
120 to perform data aggregation. Because test results are stored in
the data center/web portal 120 with authorization levels for each
policy, access to test results on the portal are synchronized with
the authorization level of the viewing entity at all times, as
authorized both by the institution administrator and by the lab
user. This can allow for reliable, real-time data filtering based
on the authorization type of the viewing entity. Depending on
desired functionality, the data center/web portal 120 can display
test results and/or aggregated test results in a variety of forms,
such as lists, charts, graphs, geographic maps, and the like.
[0057] Real-time data filtering enabled by embedding authorization
information in the reporting files can provide a level of accuracy
and speed far beyond current reporting techniques. For example,
embodiments can provide a web portal with map-based reporting that
geographically indicates up-to-date test results for tuberculosis
(TB), human immunodeficiency virus (HIV), sexually transmitted
diseases (STDs) (e.g., chlamydia, gonorrhea, etc.), flu, and/or
other infectious diseases. This can allow health systems,
government agencies, and other entities to quickly identify
specific areas of high rates of infection, or monitor viral loads
and/or infection rates to predict future infection hot spots, and
take appropriate action. Furthermore, because test results can be
traced to particular institutions, buildings, or medical devices
140 (including mobile medical devices that can be temporarily
deployed at particular locations), reporting can indicate accuracy
to a higher level of detail than current techniques, which are
typically limited to a city or a region. Moreover, because
building- or lab-specific results can be reported, institutions
such as hospitals and health-care providers can monitor test
results of their own buildings and labs to ensure they comply with
internal standards and/or governmental regulations. For example,
reporting can indicate instances of Methicillin-resistant
Staphylococcus aureus (MRSA), C. difficile, or other infectious
outbreaks at certain locations and quickly respond accordingly.
[0058] Again, although the file in FIG. 6 is provided in XML
format, embodiments can utilize reporting policies files provided
in another meta-language and/or format. Furthermore, it will be
understood that the user interfaces and files shown in FIGS. 3-6
are examples only. The techniques provided herein can be utilized
in a variety of ways and extended to various embodiments in
addition to those detailed herein. For example, not only can
exchanges between components of the medical device be performed
through files and folders as indicated previously, but they can
additionally or alternatively be performed through other various
means of communications between software applications, such as
function calls or webservice calls.
[0059] FIG. 7 is a flow diagram illustrating an exemplary
embodiment of computer-implemented method for processing test
results of a medical device 700, which can be performed, for
example, by software and/or hardware of a medical device 140 and/or
a computing device associated with a medical device 140. At block
710 settings information is received, the settings information
indicative of one or more authorization levels associated with an
entity. As discussed previously, the settings information (or
policy information) can be provided in a reporting policies file,
although other forms of communicating settings can be used.
Authorization levels associated with an entity (e.g., a viewing
entity) can include, for example, categories of data to provide for
reporting to the entity. In some embodiments, particular elements
of data can be included in the settings information. Any number of
authorization levels may be used, depending on desired
functionality.
[0060] Optionally, at blocks 720 and 730, a user can be provided
with an interface configured to receive an input, and at least one
of the one or more authorization levels can be adjusted based, at
least in part, on the input. The interface can be, for example, a
graphical user interface, such as the local reporting settings user
interface 500 of FIG. 5, shown on a screen or other electrical
display device communicatively coupled with a medical device.
Authorization levels can be adjusted based, at least in part, on
the input of a lab user, who can accept, override, or adjust
certain authorization levels. Some embodiments can allow an
institution administrator to determine whether to grant lab users
the ability to adjust authorization levels in this manner.
[0061] At block 740, test results are obtained from the medical
device. This can include obtaining test results from one component
of a medical device by another component. As shown in FIG. 2, for
example, the test monitor 240 obtains the test results from testing
software 220, which works with the testing hardware 230 of the
medical device to determine the test results. In some embodiments,
test results can be obtained from a separate device.
[0062] At block 750 the reporting information is sent. The
reporting information includes information indicative of the
entity, which can be a serial number, model number, and/or another
identifier. As discussed previously, reporting information can
further be flagged with one or more authorization levels associated
with the entity. As shown herein, the one or more authorization
levels can include categories of data to report to viewing
entities, and a single reporting file can be flagged with
authorization levels for multiple viewing entities, depending on
desired functionality. Additionally, the reporting information will
include at least a portion of the test results for reporting to the
viewing entity.
[0063] FIG. 8 is a simplified flow diagram of a process 800 for
reporting test results from a medical device that are flagged with
authorization information. The process, which can be executed by a
device or system (e.g., the data center/web portal 120 of FIGS. 1A
and 1B) communicatively coupled with a medical device, can begin at
block 810, where reporting information is received. The reporting
information not only includes information indicative of at least a
portion of the test results from the medical device, but can also
include information indicating an entity (e.g., a viewing entity)
and one or more authorization levels associated with the entity. As
discussed herein, such authorization levels can indicate types or
categories of data to report to a viewing entity.
[0064] At block 820 a request to report the test results is
received. The request, which is associated with the entity (e.g.,
viewing entity), can be made from a user device 150 via a web
portal, application, or other communication program. The requested
test results can be one of several test results and/or aggregated
test results to report to the entity.
[0065] At block 830, a subset of the at least the portion of the
test results to report is determined. The subset is based on the
one or more authorization levels and the entity. In the example
shown in FIGS. 3-6, for instance, the authorization levels granted
to the entity "Institute01" enable corresponding portions of the
test results to be reported to the "Institute01" entity. Namely,
test results corresponding to the data categories entitled "Basic,"
"Assay," "Result," and "SystUser" in the reporting file (see FIG.
6) can be reported. Depending on the type of report requested, some
or all of this information can be provided to the "Institute01"
entity. At block 840, the report is provided, based at least in
part on the subset. As indicated above, the report can be displayed
in a variety of forms, such as lists, charts, graphs, geographic
maps, and/or the like.
[0066] It should be appreciated that the specific steps illustrated
in FIGS. 7 and 8 provide examples of methods for processing and
reporting test results of medical devices. Alternative embodiments
may include alterations to the embodiments shown. For example,
alternative embodiments may include additional steps for processing
and/or aggregating data based on one or more factors such as
location, test type, medical device type, results, and the like.
Embodiments can also allow an entity to send several reporting
policies (e.g., several files containing settings information) to
one or more medical devices, in which case a "sum" of all test
results collected by the reporting policies can be provided to the
viewing entity. Furthermore, additional features can be added,
removed, or combined depending on the particular applications. One
of ordinary skill in the art would recognize many variations,
modifications, and alternatives that fall within the scope of the
present disclosure.
[0067] FIG. 9 is an exemplary illustration of a computer system
900, which can be incorporated, at least in part, into devices and
components of the distributed network 100 such the one or more
medical devices 140, user devices 150, transportation platform 130,
institution server 160, internal data server and/or data center/web
portal 120 of FIGS. 1A and 1B. FIG. 9 provides a schematic
illustration of a computer system 900 that can perform the methods
provided by various embodiments of the invention. It should be
noted that FIG. 9 is meant only to provide a generalized
illustration of various components, any or all of which can be
utilized as appropriate. FIG. 9, therefore, broadly illustrates how
individual system elements can be implemented in a relatively
separated or relatively more integrated manner.
[0068] The computer system 900 is shown comprising hardware
elements that can be electrically coupled via a bus 905 (or may
otherwise be in communication, as appropriate). The hardware
elements can include a processing unit, such as processor(s) 910,
which can include without limitation one or more general-purpose
processors, one or more special-purpose processors (such as digital
signal processing chips, graphics acceleration processors, and/or
the like), and/or other processing means; one or more input devices
915, which can include without limitation a mouse, a keyboard, a
camera, a microphone, a touchscreen, medical testing hardware,
and/or the like; and one or more output devices 920, which can
include without limitation a display device, a printer, and/or the
like.
[0069] The computer system 900 can further include (and/or be in
communication with) one or more non-transitory storage devices 925,
which can comprise, without limitation, local and/or network
accessible storage, and/or can include, without limitation, a disk
drive, a drive array, an optical storage device, a solid-state
storage device, such as a random access memory ("RAM"), and/or a
read-only memory ("ROM"), which can be programmable,
flash-updateable, and/or the like. Such storage devices can be
configured to implement any appropriate data stores, including
without limitation, various file systems, database structures,
and/or the like.
[0070] The computer system 900 can include a communications
subsystem 930, which can include without limitation a modem, a
network card (wireless or wired), an infrared communication device,
a wireless communication device, and/or a chipset (such as a
Bluetooth.TM. device, an 802.11 device, a WiFi device, a WiMax
device, cellular communication facilities, etc.), and/or the like.
The communications subsystem 930 can include one or more input
and/or output communication interfaces to permit data to be
exchanged with a network (such as the data communication network(s)
110 of FIGS. 1A and 1B), other computer systems, and/or any other
electrical devices described herein. Depending on the desired
functionality and/or other implementation concerns, a portable
electronic device (or similar device) can communicate image and/or
other information via the communications subsystem 930. In many
embodiments, the computer system 900 will comprise a working memory
935, which can include a RAM or ROM device, as described above.
[0071] The computer system 900 can comprise software elements,
shown as being currently located within the working memory 935,
including an operating system 940, device drivers, executable
libraries, and/or other code, such as one or more application
programs 945, which can comprise computer programs provided by
various embodiments, and/or can be designed to implement methods,
and/or configure systems, provided by other embodiments, as
described herein. Merely by way of example, one or more procedures
described with respect to the method(s) discussed above, such as
those described in relation to FIGS. 7 and 8, might be implemented
as code and/or instructions executable by a computer (and/or a
processing unit within a computer); in an aspect, then, such code
and/or instructions can be used to configure and/or adapt a general
purpose computer (or other device) to perform one or more
operations in accordance with the described methods.
[0072] A set of these instructions and/or code can be stored on a
non-transitory computer-readable storage medium, such as the
storage device(s) 925 described above. In some cases, the storage
medium can be incorporated within a computer system, such as
computer system 900. In other embodiments, the storage medium can
be separate from a computer system (e.g., a removable medium, such
as an optical disc), and/or provided in an installation package,
such that the storage medium can be used to program, configure,
and/or adapt a general purpose computer with the instructions/code
stored thereon. These instructions can take the form of executable
code, which is executable by the computer system 900 and/or can
take the form of source and/or installable code, which, upon
compilation and/or installation on the computer system 900 (e.g.,
using any of a variety of generally available compilers,
installation programs, compression/decompression utilities, etc.),
then takes the form of executable code.
[0073] It will be apparent to those skilled in the art that
substantial variations can be made in accordance with specific
requirements. For example, customized hardware can be used, and/or
particular elements can be implemented in hardware, software
(including portable software, such as applets, etc.), or both.
Connection to other computing devices such as network input/output
devices can be employed.
[0074] Some embodiments can employ a computer system (such as the
computer system 900) to perform methods in accordance with various
embodiments of the invention. In some embodiments, some or all of
the procedures of such methods are performed by the computer system
900 in response to processor(s) 910 executing one or more sequences
of one or more instructions (which can be incorporated into the
operating system 940 and/or other code, such as an application
program 945) contained in the working memory 935. Such instructions
can be read into the working memory 935 from another
computer-readable medium, such as one or more of the storage
device(s) 925. Merely by way of example, execution of the sequences
of instructions contained in the working memory 935 can cause the
processor(s) 910 to perform one or more procedures of the methods
described herein. Additionally or alternatively, portions of the
methods described herein can be executed through specialized
hardware.
[0075] The terms "machine-readable storage medium" and
"computer-readable storage medium," as used herein, refer to any
storage medium that participates in providing data that causes a
machine to operate in a specific fashion. In some embodiments
implemented using the computer system 900, various
computer-readable media can be involved in providing
instructions/code to processor(s) 910 for execution and/or can be
used to store and/or carry such instructions/code. In many
implementations, a computer-readable storage medium is a physical
and/or tangible storage medium. Such a medium can take the form of
a non-volatile media or volatile media. Non-limiting examples of
non-volatile media can include, optical and/or magnetic disks, such
as the storage device(s) 925. Non-limiting examples of volatile
media can include, without limitation, dynamic memory, such as the
working memory 935.
[0076] Non-limiting common forms of physical and/or tangible
computer-readable media can include, for example, a floppy disk, a
flexible disk, hard disk, magnetic tape, or any other magnetic
medium, a CD-ROM, any other optical medium, a RAM, a PROM, EPROM, a
FLASH-EPROM, any other memory chip or cartridge, or any other
medium from which a computer can read instructions and/or code.
[0077] Various forms of computer-readable media can be involved in
carrying one or more sequences of one or more instructions to the
processor(s) 910 for execution. Merely by way of example, the
instructions may initially be carried on a magnetic disk and/or
optical disc of a remote computer. A remote computer can load the
instructions into its dynamic memory and send the instructions as
signals over a transmission medium to be received and/or executed
by the computer system 900.
[0078] The communications subsystem 930 (and/or components thereof)
generally will receive signals, and the bus 905 then can carry the
signals (and/or the data, instructions, etc. carried by the
signals) to the working memory 935, from which the processor(s) 910
retrieves and executes the instructions. The instructions received
by the working memory 935 can optionally be stored on a
non-transitory storage device 925 either before or after execution
by the processor(s) 910.
[0079] The methods, systems, and devices discussed above are
examples. Various configurations can omit, substitute, or add
various procedures or components as appropriate. For instance, in
alternative configurations, the methods can be performed in an
order different from that described, and/or various stages can be
added, omitted, and/or combined. Also, features described with
respect to certain configurations can be combined in various other
configurations. Different aspects and elements of the
configurations can be combined in a similar manner. Also,
technology evolves and many of the elements as described are
provided as non-limiting examples and thus do not limit the scope
of the disclosure or claims.
[0080] Specific details are given in the description to provide a
thorough understanding of exemplary configurations (including
implementations). However, configurations can be practiced without
these specific details. For example, well-known circuits,
processes, algorithms, structures, and techniques have been shown
without unnecessary detail in order to avoid obscuring the
configurations. This description provides exemplary configurations
that do not limit the scope, applicability, or configurations of
the claims. Rather, the preceding description of the configurations
will provide those skilled in the art with an enabling description
for implementing described techniques. Various changes can be made
in the function and arrangement of elements without departing from
the spirit or scope of the disclosure.
[0081] Also, configurations can be described as a process which is
depicted as a flow diagram or block diagram. Although each can
describe the operations as a sequential process, many of the
operations can be performed in parallel or concurrently.
Furthermore, examples of the methods can be implemented by
hardware, software, firmware, middleware, microcode, hardware
description languages, or any combination thereof. When implemented
in software, firmware, middleware, or microcode, the program code
or code segments to perform the necessary tasks can be stored in a
non-transitory computer-readable medium such as a storage medium.
Processors can perform the described tasks.
[0082] Terms, "and" and "or" as used herein, may include a variety
of meanings that also is expected to depend at least in part upon
the context in which such terms are used. Typically, "or" if used
to associate a list, such as A, B, or C, is intended to mean A, B,
and C, here used in the inclusive sense, as well as A, B, or C,
here used in the exclusive sense. In addition, the term "one or
more" as used herein may be used to describe any feature,
structure, or characteristic in the singular or may be used to
describe some combination of features, structures, or
characteristics. However, it should be noted that this is merely an
illustrative example and claimed subject matter is not limited to
this example. Furthermore, the term "at least one of if used to
associate a list, such as A, B, or C, can be interpreted to mean
any combination of A, B, and/or C, such as A, AB, AA, AAB, AABBCCC,
etc.
[0083] Having described several exemplary configurations, various
modifications, alternative constructions, and equivalents can be
used without departing from the spirit of the disclosure. For
example, the above elements can be components of a larger system,
wherein other rules can take precedence over or otherwise modify
the application of the invention. Also, a number of steps can be
undertaken before, during, or after the above elements are
considered. Accordingly, the above description does not bound the
scope of the claims.
* * * * *