U.S. patent application number 12/644919 was filed with the patent office on 2011-06-23 for adaptable medical workflow system.
This patent application is currently assigned to CAREFUSION 303, INC.. Invention is credited to Ali Dufour, Sebastien Dumont, Jean-Francois Lagace, Jean-Sebastien Tremblay.
Application Number | 20110153343 12/644919 |
Document ID | / |
Family ID | 44152352 |
Filed Date | 2011-06-23 |
United States Patent
Application |
20110153343 |
Kind Code |
A1 |
Tremblay; Jean-Sebastien ;
et al. |
June 23, 2011 |
ADAPTABLE MEDICAL WORKFLOW SYSTEM
Abstract
Examples of systems and methods are provided for adapting a
medical workflow implemented at a computer coupled to a hospital
network, including receiving a message comprising medical
information data, predicting a healthcare worker's workflow using,
at least in part, the medical information data; communicating,
based on the predicted workflow, a menu comprising one or more
medical action options for displaying to the healthcare worker.
Inventors: |
Tremblay; Jean-Sebastien;
(Quebec, CA) ; Dumont; Sebastien; (St-Nicholas,
CA) ; Dufour; Ali; (St-Augustin-De-Desmaures, CA)
; Lagace; Jean-Francois; (Quebec, CA) |
Assignee: |
CAREFUSION 303, INC.
San Diego
CA
|
Family ID: |
44152352 |
Appl. No.: |
12/644919 |
Filed: |
December 22, 2009 |
Current U.S.
Class: |
705/2 ; 706/46;
709/203; 715/825 |
Current CPC
Class: |
G16H 40/20 20180101;
G06Q 10/06 20130101 |
Class at
Publication: |
705/2 ; 715/825;
709/203; 706/46 |
International
Class: |
G06Q 10/00 20060101
G06Q010/00; G06F 3/048 20060101 G06F003/048; G06F 15/16 20060101
G06F015/16 |
Claims
1. A method of adapting a medical workflow implemented at a
processor coupled to a hospital network, comprising: receiving a
message comprising medical information data; predicting a
healthcare worker's workflow using, at least in part, the medical
information data; communicating to an interface, based on the
predicting, a menu comprising one or more medical action
options.
2. The method of claim 1, wherein the predicting further comprises
predicting using the healthcare worker's identity and the
authorization level.
3. The method of claim 1, wherein the medical information data
comprises at least one of a patient identification, a medical item
identification or a barcode information.
4. The method of claim 1, wherein the medical information data
comprises a medical action selected by the healthcare worker.
5. The method of claim 1 further comprising: determining a state
associated with the medical information data.
6. The method of claim 5, wherein the predicting further comprises
predicting using the state associated with the medical information
data.
7. The method of claim 1, further comprising: associating a session
information with the first message.
8. The method of claim 7, wherein the predicting further comprises
predicting based on the session information.
9. The method of claim 1, wherein the predicting further comprises:
accessing a workflow database comprising medical action option
entries; and including at least one medical action option in the
healthcare worker's predicted workflow.
10. The method of claim 1, further comprising: updating the
workflow database based on a system administrator's input.
11. The method of claim 1, further comprising: facilitating
disabling a menu item from the menu.
12. A machine-readable medium encoded with instructions for
adapting a medical workflow, the instructions comprising code to
cause a processor to: receive a message comprising medical
information data; predict a healthcare worker's workflow using, at
least in part, the medical information data; communicate to an
interface, based on the predicting, a menu comprising one or more
medical action options.
13. The machine-readable medium of claim 12, wherein the code for
predicting further comprises code for predicting using the
healthcare worker's identity and the authorization level.
14. The machine-readable medium of claim 12, wherein the medical
information data comprises at least one of a patient
identification, a medical item identification or a barcode
information.
15. A system for adapting a medical workflow, comprising: a server;
a scanner having an interface; and a database; wherein the server
comprises: a medical information reception section configured to
receive a message from the scanner comprising medical information
data; a workflow prediction section configured to predict a
healthcare worker's workflow using, at least in part, the medical
information data; a menu communication section configured to
communicate to the scanner, based on the predicted workflow, a menu
comprising one or more medical action options for displaying on the
interface.
16. The system of claim 15, wherein the workflow prediction section
is further configured to predict the healthcare worker's workflow
using the healthcare worker's identity and the authorization
level.
17. The system of claim 15 further comprising: a state
determination section configured to determined a state associated
with the medical information data.
18. The system of claim 17, wherein the workflow prediction section
is further configured to predict using the state associated with
the medical information data.
19. The system of claim 15, further comprising: a session
management section configured to associate a session information
with the first message.
20. The system of claim 19 wherein, the workflow prediction section
is further configured to predict using the session information.
Description
FIELD
[0001] The present disclosure relates to medical workflow
systems.
BACKGROUND
[0002] The work of a healthcare worker (e.g., a nurse) generally
involves performing several tasks related to patient treatment.
Often, a healthcare worker performs tasks such as feeding a patient
or recording the temperature of a patient using devices such as
barcode scanners to enter identities of medications and patients in
a medical computer system. During care and treatment of a patient,
a healthcare worker may perform several tasks that may collectively
be referred to as a "workflow" of the healthcare worker. A
healthcare worker may follow a workflow specified by regulation of
a healthcare facility. The workflow may be provided by a medical
computer system to the healthcare worker on a display screen.
[0003] Acceptance of new technologies by a healthcare worker is a
problem faced by the healthcare industry. Introduction of a new
technology often means some changes to a healthcare worker's
workflow and therefore may require efforts on part of the
healthcare worker to adopt the new technology. For example, a
certain healthcare system configuration may expect a healthcare
worker to perform tasks A, B and C, in that order (e.g., scanning a
label, administering a medication, documenting a patient's vital
signs, etc.). A change or an upgrade to the healthcare system
configuration may require the healthcare worker to perform tasks in
the order A, C, B or may add an additional task D (e.g., new
workflow is A, B, D and C). Such changes in the healthcare system
configuration may be disruptive to the workflow that the healthcare
worker is used to follow. In some instances, upgrades or changes to
existing healthcare configurations may therefore lead to increased
errors or reduced efficiency on the part of healthcare workers
during the time period in which the healthcare workers become
accustomed to the changes.
SUMMARY
[0004] Methods and systems that solve the above-discussed and other
needs for improved medical workflow are disclosed.
[0005] In one aspect of the disclosure, a method of adapting a
medical workflow implemented at a processor coupled to a hospital
network is disclosed. The method comprises receiving a message
comprising medical information data, predicting a healthcare
worker's workflow using, at least in part, the medical information
data, and communicating to an interface, based on the predicting, a
menu comprising one or more medical action options.
[0006] In another aspect of the disclosure, a machine-readable
medium encoded with instructions for adapting a medical workflow is
disclosed. The instructions comprise code to cause a processor to
receive a message comprising medical information data, predict a
healthcare worker's workflow using, at least in part, the medical
information data and communicate to an interface, based on the
predicting, a menu comprising one or more medical action
options.
[0007] In yet another aspect of the disclosure, a system for
adapting a medical workflow is disclosed. The system comprises a
server; a scanner having an interface and a database. The server
comprises a medical information reception section configured to
receive a message from the scanner comprising medical information
data, a workflow prediction section configured to predict a
healthcare worker's workflow using, at least in part, the medical
information data and a menu communication section configured to
communicate to the scanner, based on the predicted workflow, a menu
comprising one or more medical action options for displaying on the
interface.
[0008] The foregoing and other features, aspects and advantages of
the embodiments of the present disclosure will become more apparent
from the following detailed description and accompanying
drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] FIG. 1 is a diagrammatic view of a system, in accordance
with embodiments of the present disclosure.
[0010] FIG. 2 is a conceptual block diagram of a server, in
accordance with embodiments of the present disclosure.
[0011] FIG. 3A is a flow chart depicting an exemplary process
implemented on a server, in accordance with embodiments of the
present disclosure.
[0012] FIG. 3B is a conceptual block diagram depicting entries of a
medical database, in accordance with embodiments of the present
disclosure.
[0013] FIG. 4A is a flow chart depicting an exemplary prior art
process implemented on a server.
[0014] FIG. 4B is a flow chart depicting an exemplary prior art
process implemented on a server.
[0015] FIG. 4C is a flow chart depicting an exemplary process
implemented on a server, in accordance with embodiments of the
present disclosure.
[0016] FIG. 5 illustrates a scanner with an exemplary menu screen,
in accordance with embodiments of the present disclosure.
[0017] FIG. 6 illustrates a scanner with an exemplary menu screen,
in accordance with embodiments of the present disclosure.
[0018] FIG. 7 illustrates a scanner with an exemplary menu screen,
in accordance with embodiments of the present disclosure.
[0019] FIG. 8 illustrates a scanner with an exemplary menu screen,
in accordance with embodiments of the present disclosure.
[0020] FIG. 9 illustrates a scanner with an exemplary menu screen,
in accordance with embodiments of the present disclosure.
DETAILED DESCRIPTION
[0021] The detailed description set forth below is intended as a
description of various configurations of the subject technology and
is not intended to represent the only configurations in which the
subject technology may be practiced. The appended drawings are
incorporated herein and constitute a part of the detailed
description. The detailed description includes specific details for
the purpose of providing a thorough understanding of the subject
technology. However, it will be apparent to those skilled in the
art that the subject technology may be practiced without these
specific details. In some instances, well-known structures and
components are shown in block diagram form in order to avoid
obscuring the concepts of the subject technology. Like components
are labeled with identical element numbers for ease of
understanding.
[0022] The disclosed embodiments address and solve problems related
to the aforementioned medical workflow configurations. The
embodiments solve these problems, at least in part, by minimizing
or eliminating the need for a healthcare worker to follow only a
single specific sequence of actions to accomplish certain
healthcare tasks. The disclosed embodiments solve these problems,
at least by predicting workflow of a healthcare worker based on an
identity of a medical item scanned by the healthcare worker. In
certain embodiments, workflow prediction is used to create a menu
presented to the healthcare worker at a display in response to the
healthcare worker's prior actions and menu selections.
[0023] According to certain embodiments, the prediction of a
workflow is triggered by the act of a healthcare worker scanning a
label such as a patient's identification (ID) tag or a medical
package label. Using the identity of the scanned medical object, a
predictive process at a computer calculates possible next actions
by a healthcare worker. Based on the predicted next actions, the
computer then directs a display to present a menu to the healthcare
worker to facilitate fulfilling the possible next actions. The
predictive process adapts based on prior scans performed by the
healthcare worker during a session. Therefore, in certain aspects,
the predictive process relieves the healthcare worker from having
to remember a specific sequence of scanning various medical
objects.
[0024] FIG. 1 illustrates a simplified diagram of system 110 in
accordance with certain configurations of the present disclosure.
System 110 includes one or more medical devices 102 capable of
communication with a computer server 100 (server) via hospital
network 104. System 110 further includes an interface 108
communicatively coupled to server 100. Server 100 communicates to
interface 108 for displaying to a healthcare worker. Interface 108
provides a display to a user, as well as an input device for a user
to input information into system 110. An example of interface 108
is a touch screen, although in other embodiments, the interface 108
includes a separate display and input device. Interface 108
communicates user interactions (e.g., menu selections) to server
100. In certain embodiments, interface 108 is directly attached to
server 100. In certain other embodiments, interface 108 is remotely
located, and communicates with server 100 over hospital network
104. In yet other embodiments, interface 108 is integrated into
medical device 102.
[0025] Still referring to FIG. 1, system 110 further includes
medical database 106 communicatively coupled to server 100 through
management network 105. Server 100 is configured to predict
workflow of a healthcare worker based on the healthcare worker's
interaction with medical device 102 and/or interface 108. Server
100 communicates with database 106 to receive or store certain
relevant information useful in the prediction of a workflow. By way
of illustration and not limitation, in certain configurations
server 100 predicts workflow of a healthcare worker using a
software application running on a processor of server 100.
[0026] Still referring to FIG. 1, by way of illustration and not
limitation, medical device 102 may be a computer, a mobile phone, a
laptop computer, a thin client device, a personal digital assistant
(PDA), a portable computing device, a barcode scanner, a radio
frequency identification (RFID) receiver or another device with a
processor. As used herein, the terms "scanning," and "scan" refer
to a wired or wireless operation of transferring information from
an entity to a processor. This includes, for example, barcode
scanning by an infrared receiver, sensing of radio frequency
identification (RFID) using an RFID antenna, manually reading and
entering barcode or patient information to a computer, and so
on.
[0027] Still referring to FIG. 1, by way of illustration and not
limitation, networks 104 and 105 may be, for example, modem
connections, a LAN connection including the Ethernet or a broadband
WAN connection including DSL, Cable, T1, T3, Fiber Optics, Wi-Fi,
or a mobile network connection including GSM, GPRS, 3G, WiMax or
other network connections. In certain configurations, hospital
network 104 is a dedicated point-to-point link between medical
device 102 and server 100 (e.g., a Bluetooth or a wireless USB
link).
[0028] FIG. 2 illustrates a simplified block diagram of
configuration 200 of server 100 in accordance with certain
configurations of the present disclosure. Operating system (OS) 218
is in communication with a medical information reception section
202, a workflow prediction section 204, a menu communication
section 206, a verification section 208, a state determination
section 210, a database access section 212, a database update
section 216 and a session management section 214. Features and
functions of these sections according to certain aspects of the
present disclosure may be readily implemented in software, in
hardware and/or a combination thereof, and are further described in
the disclosure.
[0029] FIG. 3A is a flow chart illustrating an exemplary process
300 implemented on server 100, in accordance with certain aspects
of the present disclosure. Server 100 is configured to receive
messages from medical device 102. Process 300 is initiated by the
server 100 receiving a message comprising medical information data
in operation 302. In certain configurations, a healthcare worker
uses medical device 102 (e.g., a barcode reader) to scan a barcode
label or perform a frequency identification (MID) scan of a medical
object. The medical object may be, for example, a medication vial,
a food item, a patient's wristband comprising the patient's
identity information, and so on. In certain configurations, a
healthcare worker directly enters an identity of the medical object
into medical device 102 via, for example, a touch screen or a
keyboard.
[0030] In response to the scan or other input by a healthcare
worker, medical device 102 communicates a message comprising
certain medical information data to server 100. In certain
embodiments, the message is in the form of an internet protocol
(IP) packet or any other well-known machine-to-machine
communication format. The medical information data includes medical
object identification information. For example, the medical
information data may include a barcode value or an RFID value that
uniquely represents a medical object.
[0031] Medical information reception section 202 (FIG. 2) processes
the received message carrying the medical information data received
by server 100. In certain configurations, medical information
reception section 202 parses the received message to extract
medical information data. In certain configurations, medical
information reception section 202 performs authentication of
medical device 102 to ensure that medical device 102 is not a rogue
medical device.
[0032] Session management section 214 associates a session, based
on the medical information received, to the received message. In
certain configurations, prediction of a workflow is performed in
the context of a session for the workflow. For example, in certain
configurations, session management section 214 creates a new
session every time a patient ID scan is received or every time a
healthcare worker logs in. In certain configurations, workflow
prediction process, described in greater detail below, predicts
workflow by using one to all messages received during a session to
predict a healthcare worker's next action.
[0033] Still referring to FIG. 3A, at operation 304, workflow
prediction section 204 of server 100 predicts the healthcare
worker's workflow using, at least in part, the received medical
information data. In certain configurations, workflow prediction
section 204 predicts a healthcare worker's workflow based actions
possible for the medical object whose identity is communicated in
the medical information data. For example, if a scanned medical
object is "milk," then workflow prediction section 204 includes in
a list of predicted action all possible actions to take for milk,
including "feed," "store," and "document feeding" actions. If the
scanned medical object corresponds to a patient's wristband, then
using the patient's identity, the workflow prediction module 204
predicts the healthcare worker's next possible action (e.g.,
administer medication to the patient or take the patient's
temperature, etc,)
[0034] Still referring to FIG. 3A, state determination section 210
determines, based on the identity of the medical object, a state
(or states) associated with the scanned medical object. For
example, if a scanned medical object is a patient's wristband,
state determination section 210 determines if the patient is in a
pre-operating state, a post-operating state, an under-observation
state, etc. State determination section 210 also obtains
information regarding the patient's vitals state (e.g., weight,
drug allergies etc.) from database 106. For example, if the scanned
medical object is a medication vial, state determination section
210 determines an expiration state (whether medication has expired
or not), a recall state (whether there have been any recalls issued
for the medication), and so on. State determination section 210
makes the determination regarding states of a scanned medical
object by querying database 106 via database access section 212.
State determination section 210 determines a state of the scanned
medical object by reading state entries and their values associated
with the scanned medical object and stored in a memory coupled to
server 100 (e.g., database 106). State determination section 210
communicates the retrieved state information to workflow prediction
section 204.
[0035] Still referring to FIG. 3A, based on state information
obtained from state determination section 210 and session
information from session management section 214, workflow
prediction section 204 predicts next possible actions in the
healthcare worker's workflow. In certain configurations, workflow
prediction section 204 predicts a single next possible action.
Alternatively, in certain other configurations, workflow prediction
section 204 predicts multiple levels of next possible actions
(e.g., next possible action and the one after that and so on). When
needed, workflow prediction section 204 also queries medical
database 106 through database access section 212 for establishing a
patient's diagnostics needs in order to predict the healthcare
worker's workflow. Workflow prediction section 204 also
communicates with state determination section 210 to determine a
state (or states) associated with the medical object identified in
the medical information data received, as previously described.
[0036] In certain configurations, the prediction operation 304
comprises a database lookup operation. For example, medical
database 106 may include a list of possible operations for a
certain medical object (e.g., a medicine) and workflow prediction
section 204 may simply use the list associated with the medical
object as the predicted next possible action by a healthcare
worker. In certain configurations, the prediction operation
comprises selecting one of several possible next actions by a
healthcare worker, associated with a medical object in medical
database 106. In certain configurations, the prediction operation
includes using information related to past actions by the
healthcare worker (or another healthcare worker having a similar
role such as a nurse) and/or the same patient and including these
actions in the predicted workflow. Therefore, in certain aspects,
workflow prediction section 204 is able to train itself by storing
in memory the information about previous workflows and selections
by a healthcare worker. In certain configurations, the prediction
operation uses prior actions performed by a healthcare worker
during the ongoing session to select a next possible action based
on the medical object included in the message received in operation
302.
[0037] In certain configurations, the prediction operation may
associate probabilities with actions possible by a healthcare
worker. A probability value associated with a possible next action
may be used to prioritize display of the actions in the menu. For
example, higher probability actions may be displayed at the top of
the menu list, or may be made visibly prominent (e.g., color or
font size) to the healthcare worker.
[0038] Still referring to FIG. 3A, at operation 306, menu
communication section 206 of server 100 communicates, based on the
predicted workflow received from workflow prediction section 204, a
menu comprising one or more medical action options for displaying
to the healthcare worker on interface 108. Various formats are
possible for the communication of menu from menu communication
section 206 to interface 108. For example, in certain
configurations, menu communication section 206 conveys data to be
displayed on interface 108 by including display instructions or
graphics commands. Such configurations are suitable when interface
108 is embedded in medical device 102 and medical device 102 has a
processor capable of receiving graphics commands and displaying a
menu to the healthcare worker by decoding the graphics commands.
For example, menu communication section 206 may specify display
properties such as font, size, color and placement of the menu on
interface 108. As an example, in certain configurations, menu
communication section 206 uses a well-known technique such as the
hypertext markup language (HTML) to specify the menu.
Alternatively, in certain configurations, interface 108 is directly
connected to server 100 and menu communication section 206
communicates menu to interface 108 using one of several well known
graphics peripheral standards such as video graphics array (VGA)
and the like.
[0039] Still referring to FIG. 3A, in certain configurations, menu
communication section 206 includes one or more action items in the
predicted workflow, but disables or "grays out" display of the
action items so that a healthcare worker may be able to see the
action items on the menu, but may not be able to interact with the
action item by selecting it from the menu. For example, display
menu item for ordering new medication items to re-stock inventory
may be grayed out if menu communication section 206 has determined
that a sufficient number of doses are available in the inventory.
In certain configurations, menu communication section 206 uses one
or more operational parameters such as the time of the day, and
state values associated with the scanned medical object in making
decisions regarding disabling an action item. The grayed out action
is displayed to make a healthcare worker aware, for her future
reference, that such an action is possible for the scanned medical
object.
[0040] In certain embodiments, workflow database update section 216
allows updates to database 106, based on a system administrator's
input. For example, a system administrator may update workflow
database to improve the quality of healthcare provided to patients.
A system administrator may update database 106 to adapt "best
practices" across several healthcare facilities managed by the
system administrator. In certain configurations, updating database
106 includes updating a list of predicted workflows associated with
a received medical object ID. In certain configurations, updating
database 106 includes adding new patient care rules, such as "do
not administer medication X and medication Y together."
[0041] Referring now to FIG. 3B, a conceptual block diagram of the
entries of database 106 is depicted. In certain embodiments,
medical database 106 includes a list 350 of a plurality of medical
objects 352. For each medical object 352 in the list 350, medical
database 106 includes a plurality of possible actions 354 possible
for a healthcare worker. Each of the plurality of possible actions
354 has zero or more states 356. In certain configurations, the
list 350 of the plurality of medical objects also includes a
default entry 360 for an "unknown" medical object.
[0042] As an example, list 350 includes medical objects such as
"patient," "drug vial," "food item," "IV fluid container," and so
on. As an example, possible actions 354 for the entry corresponding
to the medical object 352 "drug vial" include "administer," and
"discard." As an example, possible actions corresponding to the
entry 360 "unknown" include "re-scan," "switch to manual entry,"
"help," and "contact system administrator." If server 100 cannot
recognize a scanned medical object 352, server 100 requests medical
device 102 to display the list of possible actions 354
corresponding to the "unknown" entry 360.
[0043] Still referring to FIG. 3B, example states 356 associated
with the plurality of possible actions 354 include various
previously discussed patient states (e.g., pre-operating state,
etc.), vital sign states, and so on. In certain configurations,
entries of database 106 are static and pre-determined based on
rules of the healthcare facility where database 106 is used. In
certain configurations, the server 100 updates, from time to time,
entries of database 106 and values of state fields 356. For
example, the server 100 updates the entries depending on a
healthcare worker's previous scans and/or selections.
[0044] By way of illustration, and not limitation, the process of
adapting a healthcare worker's workflow by predicting the
healthcare worker's actions is further illustrated below via an
example workflow wherein a healthcare worker feeds milk to a baby
patient and documents the feeding in medical records. In
particular, two different workflows to perform the "document
feeding" task are described below. The workflow illustrated in
FIGS. 4A and 4B generally relates to a prior art "static" workflow
wherein server 100 is not predicting a healthcare worker's
workflow. On the other hand, in the workflow illustrated in FIG.
4C, the server 100 predicts the workflow, based on an identity of a
scanned medical object.
[0045] Referring to FIG. 4A, process 401 illustrates an example
prior art process related to documenting feeding milk to a baby
patient when a medical workflow system is not predicting the
workflow. At operation 403, a menu is displayed to a healthcare
worker. The menu includes a list of several possible tasks. In
general, this list of tasks includes several tasks not pertinent to
the current task of documenting a feeding. The healthcare worker
chooses from the displayed tasks. Since the healthcare worker
intends to document a feeding, the healthcare worker interacts with
a "document feeding" workflow. In the document feeding workflow,
the healthcare worker chooses milk functions (operation 405) or
chooses baby functions (action 407). Based on this selection by the
healthcare worker, either a menu of possible milk-related functions
is shown to the healthcare worker (operation 409) or a menu of baby
functions is displayed to the healthcare worker (operation 411). In
response to the displayed menu of milk or baby functions, the
healthcare worker indicates, in operation 413, that she wants to
document a feeding session. At operation 415, the healthcare worker
is prompted for a baby ID. The healthcare worker scans a barcode
containing a patient's identification (e.g., a patient
bracelet).
[0046] As can be seen from the description above of the operations
illustrated in FIG. 4A, a healthcare worker cannot simply scan a
baby's ID bracelet to begin the "document feeding" workflow.
Instead, the healthcare worker has to navigate through multiple
menu screens, before she is able to scan a medical object (baby
ID).
[0047] Still referring to FIG. 4A, at operation 417, a server (not
shown in FIG. 4A) verifies the baby ID received at the server. If
the scanned baby ID is not valid, an error message is displayed to
the healthcare worker. If the scanned baby ID is valid, the server
sends a request to a medical device 102 to display "choose feeding
type" menu screen in operation 419. In certain configurations, the
healthcare worker is given at least three choices: formula feeding,
breast feeding or container feeding.
[0048] Referring now to FIG. 4B, if the healthcare worker chooses
the "formula feeding" option, then a "document formula feeding
event" menu screen is displayed to the healthcare worker at
operation 421. If the healthcare worker chooses the breast feeding
option, then a "document breast feeding event" option is displayed
to the healthcare worker at operation 423. If the healthcare worker
chooses the container option, then a "feeding events list" option
is displayed, at operation 425, to the healthcare worker.
[0049] Still referring to FIG. 4B, if "formula feeding" or "breast
feeding" event is chosen at operations 421 or 423, the healthcare
worker (e.g., a nurse) documents the feeding event in operation 429
by entering pertinent data into a medical device. At operation 433,
the server communicates with database 106 and registers the feeding
event. If "feeding events list" is chosen at operation 425, then a
menu of possible events is displayed to the healthcare worker. At
operation 427, the healthcare worker chooses an event from the
displayed menu. In response to the selection, server 100 instructs,
at operation 431, an interface 108 (not shown in FIG. 4B) to
display a form for documenting container feeding. If the delay
expected before the documentation is entered (e.g., waiting to
finish a typical milk feeding), then the healthcare worker
documents the feeding event (operation 435) and the server also
causes a state of the container maintained by the server to change
at operation 437. If the expected delay before the feeding can be
documented has not elapsed, then server 100 causes a delay message
to be displayed (operation 439) to the healthcare worker.
[0050] FIG. 4C shows exemplary process 400 implemented using the
scanner of the present disclosure to predict a healthcare worker's
workflow based on identities of scanned medical items. At operation
402, a healthcare worker scans a medical object. For example, the
scanned object may be a baby patient's wristband or a milk
container. Upon receiving a message comprising medical information
data related to the scanned medical object, server 100 verifies the
received ID at operation 404. For example, if the scanned ID was
for a baby patient, at operation 404, server 100 verifies that the
baby patient is a currently admitted patient. If the scanned ID
corresponds to a valid baby ID, at operation 406, server 100 sends
a message to a medical device 102 to display a menu of baby-related
actions to the healthcare worker. For example, one of the actions
relates to documenting feeding of milk to the baby patient. The
healthcare worker may want to document a milk feeding given to the
baby patient in the hospital's medical records and may choose the
"document feeding" option at operation 408.
[0051] In comparison to process 401 illustrated in FIG. 4A and FIG.
4B, a healthcare worker is able to communicate to server 100 the
current task (document feeding) by first scanning a medical object
ID. Therefore, process 400 avoids the need for a healthcare worker
to navigate through a set of menus before she can communicate to
server 100 that the current task (workflow) relates to document
feeding of a baby patient.
[0052] Still referring to FIG. 4C, at operation 410, server 100
facilitates the display of a "choose feeding type" menu to the
healthcare worker by sending a display request to a medical device
102. If the healthcare worker chooses the "breast feeding" menu
(operation 412), server 100 communicates a request to medical
device 102 to display a workflow menu predicted from "breast
feeding a baby" actions. If the healthcare worker chooses "formula
feeding" menu (operation 414), server 100 communicates a request to
medical device 102 to display a workflow menu predicted from the
selection of the "formula feeding" action and patient ID for a
baby. Subsequent to either operation 412 or operation 414, the
healthcare worker documents the feeding event operation 416.
[0053] Still referring to FIG. 4C, if the healthcare worker
chooses, at operation 410, the "container feeding" menu, then
server 100 predicts possible actions that the healthcare worker may
want to perform and, in operation 418, communicates a menu to
medical device 102 comprising predicted actions. The healthcare
worker may choose, at operation 420, an action from the menu
displayed. In response to the healthcare worker's selection at
operation 420, server 100 communicates a request to medical device
102 to display, at operation 422, a list of "document container
feed" actions. The healthcare worker is also shown a similar
message at operation 422, if medical asset ID scanner in operation
402 was that of a container and server 100 was able to link, at
operation 424, the scanned container ID with the identity of a baby
in the hospital. At operation 426, server 100 checks the expected
delay (e.g., duration of feeding milk to a baby patient) has
elapsed. If the delay has expired, at operation 430, server 100
facilitates documentation of the feeding event by the healthcare
worker. Server 100 updates a medical database coupled to the
hospital network, at operation 432, to reflect the feeding. Server
100 then changes a state associated with the container scanned in
operation 402 to indicate, for example, that the container has been
used. If server 100 decides at operation 426 that a delay has not
elapsed, server 100 communicates a message, at operation 428, to a
medical device 102 to display a delay message to the healthcare
worker.
[0054] In comparison to process 401 illustrated in FIG. 4A, process
400 illustrated in FIG. 4C is initiated by a healthcare worker
scanning a medical object (e.g., a milk container or a baby
patient's wrist ID). Based on the identity of the scanned medical
object, server 100 predicts the healthcare worker's workflow and
presents menu action items to the healthcare worker. In some
aspects, the exact order in which various scans are performed does
not matter for a successful execution of a workflow. For example,
in process 400, a healthcare worker need not go through multiple
menu screens to communicate to server 100 what the healthcare
worker wants to accomplish. Instead, the healthcare worker need
only scan a baby ID and a milk container, for server 100 to predict
the healthcare worker's workflow. Furthermore, the exact order in
which the baby ID is scanned and the container ID is scanned does
not matter to server 100 supporting the workflow.
[0055] It will be appreciated that in certain aspects of the
present disclosure, an adaptive workflow method is provided that
guides a healthcare worker to a menu of medical tasks by predicting
the healthcare worker's workflow from a received barcode scan
information. In certain configurations, a medical device
communicatively coupled to a server displays a "top level" menu
upon starting operation and awaits a barcode scan from the
healthcare worker. Upon receiving data related to a barcode scan,
the server interprets what has been scanned and displays to the
healthcare worker a menu of actions such that it is possible to
perform a meaningful medical task with the previously scanned
object. The server is configured to accept any barcode format.
[0056] In certain configurations, a healthcare worker uses a
barcode reader or other device to scan medical objects such as a
patient ID, a baby ID or a milk container ID. Based on what was
scanned, the system will facilitate the display of next possible
tasks to the healthcare worker. In certain configurations, e.g., as
described above with respect to FIGS. 1 to 4C, the healthcare
worker is a nurse administering milk to a baby. Regardless of the
order in which the nurse scans barcodes (e.g., the baby's wristband
ID first or the milk container ID first), the server 100 is able to
predict that the workflow relates to administering milk to the
baby. Based on this prediction, server 100 facilitates presentation
of an appropriate medical task menu to the nurse.
[0057] FIGS. 5-9 illustrate various display screens displayed on
interface 108 to a healthcare worker during accomplishment of
medicals tasks by predicting workflows. For example, in certain
configurations, interface 108 is a part of a medical device 102
such as a barcode or and RFID scanner. In such configurations, a
healthcare worker scans barcode using the medical device 102 and
interacts with menu displayed on the interface 108.
[0058] FIG. 5 illustrates an exemplary menu screen 500, in
accordance with certain aspects of the present disclosure. In
certain configurations, medical device 102 displays menu screen 500
to a healthcare worker as an initial login to a predictive workflow
scanning application in accordance with various application
configurations described above with respect to FIGS. 1 to 4C. Menu
screen 500 comprises area 502 where the healthcare enters her user
name and further enters a password in area 504. In certain
configurations, when a healthcare worker logs in from screen 500,
session management section 214 begins a new session for workflow
prediction.
[0059] FIG. 6 illustrates an exemplary menu screen, in accordance
with certain aspects of the present disclosure. Menu screen 600
illustrates a message displayed for a healthcare worker suggesting
a next action to perform, based on predictive workflow calculations
of the present disclosure. In this case, the suggested actions
include scanning a patient's wristband or a medical container label
or tapping the interface 108 to receive more possible actions.
[0060] FIG. 7 illustrates an exemplary menu screen, in accordance
with certain aspects of the present disclosure. Menu screen 700 of
interface 108 includes display area 702 displaying a healthcare
worker's identity and a patient's identity. Menu screen 700 further
includes a list of baby functions, as indicated by a heading
display area 704, displaying actions that are possible for a baby
patient. Menu screen 700 further comprises a list of actions that
the healthcare worker may need to perform, as calculated by
predicting the healthcare worker's workflow. The example
illustrated in FIG. 7 shows a "baby functions" action in region
704, a "check out task" in region 706, an "administer milk" action
in region 708, "document feeding" in region 710 and "print labels"
in region 712. Menu screen 700 is an example of a menu that may be
presented to a healthcare worker at operation 406 described in FIG.
4C.
[0061] FIG. 8 illustrates an exemplary menu screen, in accordance
with certain aspects of the present disclosure. Menu screen 800
includes display area 802 displaying a healthcare worker's identity
and a patient's identity. Menu screen 800 further includes a list
of adult functions, as indicated by a heading display area 804,
displaying actions possible for an adult patient. Menu screen 800
further comprises a list of actions that the healthcare worker may
need to perform, as calculated by predicting the healthcare
worker's workflow. The example illustrated in FIG. 8 shows an
"adult functions" action in region 804, a "check out task" in
region 806, a "print labels" action in region 808 and a "receive
milk" action in region 810.
[0062] FIG. 9 illustrates an exemplary menu screen, in accordance
with certain aspects of the present disclosure. Menu screen 900
includes display area 902 displaying a healthcare worker's identity
and a patient's identity. Menu screen 900 further includes a list
of milk functions, as indicated by a heading display area 904,
displaying actions possible for milk (e.g., when a milk container
is scanned as a medical object). Menu screen 900 further comprises
a list of actions that the healthcare worker may need to perform,
as calculated by predicting the healthcare worker's workflow. The
example illustrated in FIG. 9 shows a "receive milk" action in
region 906 an "administer milk" action in region 908, a "fortify
milk" action in region 908, and a "document feeding" action in
region 912.
[0063] The menu screens 500, 600, 700, 800 and 900 described above
with respect to FIGS. 5 to 9 are used at various operations in a
workflow for feeding milk to a baby patient. For example, during
process 400 illustrated in FIG. 4C, menu screen 700 may be
presented at operation 406. Similarly, menu screen 600 may be
presented at operation 402.
[0064] It will be appreciated that, in certain aspects, workflow
prediction techniques described presently, free up a healthcare
worker from having to remember a specific sequence of scanning
medical objects. The methods and systems of the present disclosure
provide for a server in a medical facility to manage menu screens
displayed to a healthcare worker in ways that minimize disruption
to a healthcare worker's workflow. In certain aspects, the
healthcare worker "trains" a system to better predict her next
actions, based on her actions during a previous medical workflow.
Therefore, configurations of the present disclosure relieve a
healthcare worker from having to memorize menu screens and inputs
expected from her to accomplish certain healthcare tasks. In
certain aspects, workflow prediction is based on IDs of medical
objects scanned by a healthcare worker.
[0065] Although embodiments of the present disclosure have been
described and illustrated in detail, it is to be clearly understood
that the same is by way of illustration and example only and is not
to be taken by way of limitation, the scope of the present
invention being limited only by the terms of the appended
claims.
* * * * *