CROSS-REFERENCE TO RELATED APPLICATIONSThis application claims priority to U.S. patent application Ser. No. 15/295,722 filed Oct. 17, 2016, by inventors Krishna Bhimavarapu et al. and entitled SYSTEMS AND METHODS FOR PROVIDING HEALTH INFORMATION, which in turn claims priority to U.S. provisional patent application Ser. No. 62/242,735 filed Oct. 16, 2015, by inventors Krishna Bhimavarapu et al. and entitled SYSTEMS AND METHODS FOR PROVIDING HEALTH INFORMATION, the complete disclosures of both of which are incorporated herein by reference.
BACKGROUND OF THE INVENTIONThe present disclosure relates to systems and methods for providing health information regarding a patient's visit to a healthcare facility, such as a hospital.
SUMMARYSome of the embodiments of the present disclosure address the past difficulties in presenting timely, helpful, and/or complete information to a patient, his or her friends or family, and other individuals associated with the patient before, during, and/or after the patient's visit to a healthcare facility. In one embodiment, a health information application adapted to be executed on an electronic device, such as, but not limited to, smart cell phone, a tablet, a laptop computer, or the like, is provided to a patient, his or her friends or family, and/or other individuals associated with the patient. The patient, or other receiver of the application, then utilizes the application on his or her smart cell phone or other electronic device. When utilized thereon, the electronic device retrieves a variety of different information about the patient's stay from one or more computer servers or software applications, some of which may be on the healthcare facility's local area network, and some of which may be coupled thereto via another network connection (e.g. the Internet). In other embodiments, a healthcare information application is provided that is accessed and used by healthcare providers in order to easily review and/or input information regarding patients, medical equipment, treatment, and other information.
According to one embodiment, a system is provided that includes a mobile electronic device adapted to perform the following: display on a display of the mobile electronic device first data regarding a patient's visit to a healthcare facility; process information indicating a current location of the mobile electronic device; and display second data regarding the patient's visit to the healthcare facility. The processor of the mobile electronic device delays displaying the second data until the mobile electronic device crosses a boundary of a geo-fenced area.
In some embodiments, the geo-fenced area encompasses the entire healthcare facility. In other embodiments, the geo-fenced area encompasses only a portion of the healthcare facility. In still other embodiments, multiple geo-fenced areas are defined and different data is delayed from being displayed depending upon which geo-fenced area is crossed.
The geo-fenced area or areas may have boundaries substantially defined by one of the following: a room within the healthcare facility, a floor within the healthcare facility, a wing within the healthcare facility, a department within the healthcare facility, a set of elevators within the healthcare facility, and a parking lot of the healthcare facility.
The mobile electronic device also displays, in at least one embodiment, third data regarding the patient's visit to the healthcare facility, wherein the processor of the mobile device delays displaying the third data until a clock in communication with the processor indicates a specific time has passed or a specific event has occurred. The specific time may correspond to a completion of a task in a treatment plan for the patient, and the specific event may include at least one of the following: admission to the healthcare facility; completion of a medical treatment within the medical facility; and discharge from the healthcare facility. In some embodiments, the specific event is a completion of a medical treatment and the mobile electronic device wirelessly receives a message indicating the completion of the medical treatment.
The mobile electronic device may also receive information from the patient and transmit the received information to a healthcare facility computer. In some embodiments, the received information includes answers provided by the patient to at least one question displayed on the display. The question relates to a quality of the patient's visit to the healthcare facility, in some embodiments. The question may be incorporated into a Hospital Consumer Assessment of Healthcare Providers and Systems (HCAHPS) score, in at least some embodiments. Such HCAHPS surveys were developed by the United States Department of Health and Human Services.
The second data displayed on the mobile electronic device relates, in some embodiments, to at least one of the following: a medication prescribed to the patient, a medical treatment scheduled for the patient, a location within the medical facility, a caregiver of the medical facility, dietary guidelines for the patient, and at least one question about a quality of the patient's visit to the healthcare facility.
In some embodiments, the mobile electronic device displays instructions enabling the user to authorize a family member to access third data regarding the patient's visit to the healthcare facility via a second mobile electronic device carried by the family member. The third data includes at least one piece of information recorded in an electronic medical record of the patient.
The mobile electronic device may also display instructions enabling the user to authorize a friend to access fourth data regarding the patient's visit to the healthcare facility via a second mobile electronic device carried by the friend.
In some embodiments, the mobile electronic device displays at least one control for controlling an aspect of a bed assigned to the patient and transmitting a command to the bed in response to the patient manipulating the control.
The mobile electronic device may also provide access to an electronic chat room that is limited to participants who have received treatment for a medical condition that is the same, or similar to, a medical condition of the patient. The electronic chat room may be limited to participants who have received treatment for the medical condition at the healthcare facility.
According to another embodiment, a system is provided that includes a mobile electronic device that is adapted to display first data regarding a patient's visit to a healthcare facility. The processor of the mobile electronic device is also adapted to display a sequence of patient events associated with the patient's visit to a healthcare facility, and to display further information regarding a selected one of the patient events in response to a user of the mobile electronic device selecting the selected patient event.
According to other aspects, the mobile electronic device communicates with an electronic medical records server at the healthcare facility in response to the user selecting the selected patient event.
The mobile electronic device may also, or alternatively, communicate with a bed server at the healthcare facility that receives status data from a plurality of beds. When communicating with the bed server, the device receives data from the bed server indicating how much time the patient has spent out of bed. The data from the bed server may also or alternatively include data indicating when the patient has returned to his or her bed.
According to another embodiment, a mobile electronic device is provided that is adapted to display on its display first data regarding a patient's visit to a healthcare facility. A processor of the mobile electronic device is also adapted to communicate with a bed server at the healthcare facility that receives status data from a plurality of beds. The mobile electronic device authorizes, based on user input, the automatic sending of a notification message to a second mobile electronic device associated with a friend or family member of the patient when the bed server receives status data from the patient's bed.
According to other aspects, the status data may indicate when the patient left his or her bed, returned to his or her bed, and/or when the patient is awake or asleep.
The mobile electronic device may also be configured to display questions regarding the patient's visit to the healthcare facility on the display of the first mobile electronic device, receive answers to the questions, and forward answers to the questions to a server located at the healthcare facility.
In some embodiments, the mobile electronic device, or a server in communication with the mobile electronic device, is adapted to receive a code from an electronic medical records server at the healthcare facility, convert the code to a description of the service, and display the description of the service on the screen of the first mobile electronic device. The code may be an International Classification of Disease (ICD) code, or other code commonly used in healthcare settings for documenting medical tasks.
Before the various embodiments disclosed herein are explained in detail, it is to be understood that the claims are not to be limited to the details of operation or to the details of construction and the arrangement of the components set forth in the following description or illustrated in the drawings. The embodiments described herein are capable of being practiced or being carried out in alternative ways not expressly disclosed herein. Also, it is to be understood that the phraseology and terminology used herein are for the purpose of description and should not be regarded as limiting. The use of “including” and “comprising” and variations thereof is meant to encompass the items listed thereafter and equivalents thereof as well as additional items and equivalents thereof. Further, enumeration may be used in the description of various embodiments. Unless otherwise expressly stated, the use of enumeration should not be construed as limiting the claims to any specific order or number of components. Nor should the use of enumeration be construed as excluding from the scope of the claims any additional steps or components that might be combined with or into the enumerated steps or components.
BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 is a block diagram of a first embodiment of a health information system according to the present disclosure;
FIG. 2 is an elevation view of an illustrative mobile electronic device incorporating a healthcare application of the health information system;
FIG. 3 is a perspective view of an arbitrary healthcare facility having a geo-fenced area that, when crossed, triggers an action by the health information application;
FIG. 4 is a diagram indicating the time sensitivity of the health information application;
FIG. 5 is a diagram of an illustrative set of events regarding a patient's scheduled healthcare facility visit that may be displayed and/or used by the health information application;
FIG. 6 is an illustrative example of a screen shot displayable on the mobile electronic device showing a menu for the health information application;
FIG. 7 is an illustrative example of a screen shot displayable on the mobile electronic device showing information related to a patient's hospital visit integrated into a calendar;
FIG. 8 is an illustrative example of a screen shot displayable on the mobile electronic device showing event information regarding the patient's hospital visit;
FIG. 9 is an illustrative example of a screen shot displayable on the mobile electronic device showing a more detailed listing of event information regarding the patient's hospital visit;
FIG. 10 is an another illustrative example of a screen shot displayable on the mobile electronic device showing detail about a specific event regarding the patient's hospital event;
FIG. 11 is an illustrative example of a screen shot displayable on the mobile electronic device showing more detailed information regarding the event shown inFIG. 10;
FIG. 12 is an illustrative example of a screen shot displayable on the mobile electronic device showing information regarding the patient's upcoming discharge from the hospital;
FIG. 13 is an illustrative example of a screen shot displayable on the mobile electronic device showing information regarding the patient's discharge;
FIG. 14 is an illustrative example of a screen shot displayable on the mobile electronic device showing medical reference information related to the patient's condition and/or treatment;
FIG. 15 is an illustrative example of a screen shot displayable on the mobile electronic device showing a list of discussion topics of an electronic chatroom accessible to the patient;
FIG. 16 is an illustrative example of a screen shot displayable on the mobile electronic device showing the hospital's location and parking information on a map;
FIG. 17 is an illustrative example of a screen shot displayable on the mobile electronic device showing a floorplan of the hospital as well as a menu of items whose location may be of interest;
FIG. 18 is an illustrative example of a screen shot displayable on the mobile electronic device showing a more detailed layout of a floorplan of the hospital;
FIG. 19 is an illustrative example of a screen shot displayable on the mobile electronic device showing a more detailed menu of items whose location may be of interest;
FIG. 20 is an illustrative example of a screen shot displayable on the mobile electronic device showing patient information accessible to, and editable by, authorized friends and/or relatives of the patient;
FIG. 21 is an illustrative example of a screen shot displayable on the mobile electronic device showing a plurality of badges that the patient may be able to earn while at the hospital;
FIG. 22 is an illustrative example of a screen shot displayable on the mobile electronic device showing a notification message that the patient has earned a mobility badge;
FIG. 23 is an illustrative example of a screen shot displayable on the mobile electronic device showing a notification message that the patient has earned an improved restfulness badge;
FIG. 24 is an illustrative example of a screen shot displayable on the mobile electronic device showing a notification message that the patient has earned a discharge badge;
FIG. 25 is an illustrative example of a screen shot displayable on the mobile electronic device showing a patient question regarding his or her pain level;
FIG. 26 is an illustrative example of a screen shot displayable on the mobile electronic device showing a patient question regarding his or her nurse;
FIG. 27 is an illustrative example of a screen shot displayable on the mobile electronic device showing a patient question regarding his or her restroom;
FIG. 28 is an illustrative example of a screen shot displayable on the mobile electronic device showing patient questions used as part of an HCAHPS survey;
FIG. 29 is an illustrative example of a screen shot displayable on the mobile electronic device showing a text or chat feature for enabling patient-caregiver communications;
FIG. 30 is an illustrative example of a screen shot displayable on the mobile electronic device showing a language translation feature for facilitating cross language communication;
FIG. 31 is an illustrative example of a screen shot displayable on the mobile electronic device showing HCAHPS survey information;
FIG. 32 is an illustrative example of a screen shot displayable on the mobile electronic device showing categories of HCAHPS survey information relative to historical data;
FIG. 33 is an illustrative example of a screen shot displayable on the mobile electronic device showing a list of patients and status information regarding the patients;
FIG. 34 is an illustrative example of a screen shot displayable on the mobile electronic device showing detailed information about a patient selected from the list ofFIG. 33;
FIG. 35 is an illustrative example of a screen shot displayable on the mobile electronic device showing a fall risk assessment for a patient from the list ofFIG. 33;
FIG. 36 is an illustrative example of a screen shot displayable on the mobile electronic device showing caregiver rounding information for a patient selected from the list ofFIG. 33;
FIG. 37 is an illustrative example of a screen shot displayable on the mobile electronic device inquiring if a caregiver wishes to save rounding information previously entered;
FIG. 38 is an illustrative example of a screen shot displayable on the mobile electronic device showing patient sleep information;
FIG. 39 is an illustrative example of a screen shot displayable on the mobile electronic device showing feature utilization of a medical device;
FIG. 40 is an illustrative example of a screen shot displayable on the mobile electronic device showing status information regarding a medical device;
FIG. 41 is an illustrative example of a screen shot displayable on the mobile electronic device showing status information regarding a fleet of medical devices; and
FIG. 42 is an illustrative example of a screen shot displayable on the mobile electronic device showing information regarding servicing of a medical device.
DETAILED DESCRIPTION OF THE EMBODIMENTSAhealth information system20 according to a first embodiment of the disclosure is shown inFIG. 1.Health information system20 ofFIG. 1 spans a set of geographic locations that includes at least onehospital22, a place of business of avendor24, an area outside of thehospital22, such as acity26, and one ormore homes28. In different embodiments, the geographic extent ofhealth information system20 may be changed, including consolidating one or more of the resources at thevendor24′s place of business withinhospital22 and/or elsewhere. In still other embodiments,health information system20 is adapted to operate without extending tocity26 and/orhomes28. In still other embodiments, still other modifications to the geographical span ofhealth information system20 may be made.
Health information system20 ofFIG. 1 includes at least one health information software application30 (hereinafter referred to as “health info app30”) that is supplied to one or moreelectronic devices32 of one ormore users34. As shown by way of illustration inFIG. 1, theelectronic devices32 include mobile electronic devices, such assmart phones32a,laptops32b,and/ortablets32c,as well as generally stationary electronic devices, such asnurse station computers32dand/or personal computers (PCs)32e.When implemented on asmart phone32a,thesmart phone32amay utilize an Android operating system or an Apple iOS operating system. In still other embodiments,device32 utilizes another type of operating system besides Android and iOS (such as, but not limited to, Firefox OS, Sailfish OS, Windows Phone, Blackberry, Tizen, and others). Still further, in some embodiments,health info app30 is a web-based application that is accessed by utilizing a conventional web browser, such as, but not limited to, Internet Explorer, Internet Edge, Firefox, and/or Apple Safari.
Theusers34 ofhealth info app30 may vary, and include such users ascharge nurses34a,biomedical technicians34b,nurses orother caregivers34c,patients34d,patient spouses34e,service technicians34fof thevendor24, Information Technology (IT)personnel34gof thevendor24,friends34hofpatients34d,andfamily34iofpatient34d.
Health info app30 is supplied, in the embodiment illustrated, from acloud location36 ofvendor24.Cloud location36 need not be owned by or operated byvendor24, but instead provides a location accessible to the Internet for distributinghealth info app30 to Internet-connected users and allowing one or more resources atvendor24′s place of business to communicate withhealth info app30. As shown by way of illustration inFIG. 1,cloud location36 includes anInternet connection38 that enablesvendor24 to forwardhealth info app30 tohospital22,city26, and one ormore homes28.Cloud location36 also provides a communication conduit forhealth info app30, after installation on one or moreelectronic devices32, to communicate with the resources ofvendor24.
These vendor resources include afile server40, a realtime communication server42, anapplication server44 and acommerce server46. It will be understood that this particular set of resources may vary and thatvendor24 may include a different set of resources, including, but not limited to, connections to resources provided by third parties with whichvendor24 has one or more contractual agreements for providing support and/or services tohealth info app30.File server40 stores files and data used byhealth info app30. Realtime communication server42 manages the ongoing communications between the resources ofvendor24 and themultiple devices32 that havehealth info app30 stored and executing thereon.Application server44 provides thehealth info app30 that is initially downloaded onto thedevices32, as well as overseeing updates tohealth info app30 and other operational aspects ofhealth info app30.Commerce server46 manages the billing and financial information associated with the use of health info app. In some instances, this billing is directed tohospitals22 which providehealth info app30 to one or more of their patients and/or the friends and relatives of the patients. In some instances,commerce server46 may oversee financial charges that are applied directly to one ormore users34 ofhealth info app30.
Afterhealth info app30 is downloaded to ahospital22 viaInternet connection38, it is initially stored on alocal vendor server48.Local vendor server48 is supplied byvendor24.Local vendor server48 is, in some embodiments, purely asoftware server48 that resides on server hardware owned and/or operated byhospital22. In other embodiments,vendor24 may provide server hardware forlocal vendor server48.Local vendor server48 oversees the distribution of individual copies ofhealth info app30 to thedevices32 located withinhospital22, as well as the communication between thosedevices32.Local vendor server48 also provides an interface between thedevices32 withinhospital22 andvendor cloud36. Still further,local vendor server48 provides an interface betweendevices32 and one or more servers or services that are a part of alocal area network50 ofhospital22.
In the embodiment shown inFIG. 1,local area network50 ofhospital22 includes an electronic medical records (EMR)server52, astreaming media server54, aneducation management server56, adatabase server58, amobile information server60, and aweb server62. It will be understood that these particular servers are but one illustration of the makeup of anillustrative hospital network50. The specific number and type of servers that may be present in a givenhospital22 will vary from hospital to hospital, depending upon the computer architecture of a given healthcare facility, as well as the types of servers and/or software applications that are operating on the hospital'snetwork50.Local vendor server48 may therefore communicate with different numbers, types, and/or combinations of the servers illustratively shown inFIG. 1.
Local vendor server48, in at least one embodiment, communicates withelectronic devices32 via one or morewireless access points64 ofcomputer network50 of ahospital22. In at least one embodiment, such wireless communication is carried out via WiFi (IEEE 802.11). Other wireless protocols and/or wired protocols can alternatively be used, including combinations of such protocols (such as, but not limited to, both WiFi and Ethernet). One or more of theelectronic devices32 may also be adapted to communicate with a Bluetooth (IEEE 802.15.1)beacon66 that is communicatively coupled tolocal network50.Such devices32 are therefore able to communicate withlocal vendor server48 via Bluetooth communications, and vice versa.
Local vendor server48 also communicates with one or more of the servers52-62 onnetwork50.EMR server52 is an electronic medical records server that stores, retrieves, and updates medical records of the patients athospital22. Streamingmedia server54 is a server that provides streaming video, audio, and/or other content when requested by thehealth info apps30 operating on any of thedevices32 of any of theusers34, as will be discussed in greater detail below.Education management server56 provides educational materials regarding health conditions, drugs, treatments, and the like. These materials are accessed and displayed byhealth info app30 when such information is requested by auser34.
Database server58 contains data used byhealth info app30 at different times, including, but not limited to, mapinformation regarding hospital22, employees and personnel ofhospital22, work flow information, and other data.Mobile information server60 manages communications between healthcare personnel, such as one or moresmart phones32a,badges, pagers, etc. Thus, for example, if a particular caregiver, or set of caregivers, is to be notified of an alert, or provided with other information,health info app30 can send a notification request vialocal vendor server48 tomobile information server60 andmobile information server60 will send a text, page, or other notification to a mobile device carried by the caregiver, or set of caregivers.Web server62 provides web access to any of the servers and/or applications executing onnetwork50 and/or in communication withnetwork50.Health info app30 is therefore able to utilizeweb server62 to communicate with the World Wide Web usingweb server62.
All of the servers52-62 may be conventional servers.Health info app30 is configured to extract the information contained within any one or more of these servers52-52 as needed byapp30, and in some cases update the information stored therein, as will be described in greater detail below.Health info app30 may be configured to communicate with additional servers not shown inFIG. 1 and/or with different combinations of servers. Still further, in some embodiments, the data contained within any of servers52-62 may be located off site ofhospital22. In such embodiments,local vendor server48 provides the information contained within the server by communicating throughweb server62 and/orInternet connection38 with the offsite servers.
TheBluetooth beacons66 located athospital22 may be part of a location system in which the locations of each of theBluetooth beacons66 are fixed and known toserver48. Whenlocal vendor server48 receives a message from adevice32 that passes through a Bluetooth beacon, the Bluetooth beacon appends to the message a unique identification corresponding to thatparticular Bluetooth beacon66.Local vendor server48 consults a look-up table that correlates that unique identifications it receives from theBluetooth beacons66 to their locations within the hospital22 (such a table may be stored indatabase server58, or elsewhere).Local vendor server48 is therefore able to determine the approximate location of anydevice32 that is communicating withlocal vendor server46 via aBluetooth beacon66. In other words, the location of that device is determined to be within a close proximity of theBluetooth beacon66, given the relatively short range of Bluetooth. Similarly location technology may be used for determining the location of devices communicating viaWiFi access points64 using knowledge of the location of theaccess point64 and, in some cases, triangulation of signal strength. One example of such location technology that may be used withhealth info app30 is disclosed in commonly assigned U.S. patent application Ser. No. 14/559,458 filed Dec. 3, 2014, by inventors Michael Hayes et al. and entitled PATIENT SUPPORT APPARATUS COMMUNICATION SYSTEMS, the complete disclosure of which is incorporated herein by reference.
In other embodiments, a conventional RF ID tag system may be used for detecting the location of mobileelectronic devices32. In still other embodiments, the location of mobileelectronic devices32 can be monitored using any of the locating techniques disclosed in commonly assigned U.S. Pat. No. 8,674,826 issued to Becker et al. and entitled LOCATION DETECTION SYSTEM FOR A DEVICE, the complete disclosure of which is hereby incorporated herein by reference. Still further, in some embodiments, whenhealth info app30 is installed on asmart phone32a,it uses the built-in location technologies of thesmart phone32a(GPS, cellular triangulation, etc.) to determine its location, which is then forwarded tolocal vendor server48.
Access points64 andbeacons66 contained withhospital22 enable users ofhealth info app30 to communicate withvendor cloud36 while those users are athospital22. As will be discussed in greater detail below, however, not all users ofhealth info app30 are located withinhospital22. Some users are located outside ofhospital22, such as incity26. It will be understood that references to “city26” refer to not just the local municipality in whichhospital22 is located, but instead refers to a broader geographic designation that includes any areas in which potential patients and/or relatives of patients ofhospital22 may be located. Thus, in some embodiments, “city26” is broad enough to include any place outside ofhospital22 in which there is Internet access.
Users34 who are located outside ofhospital22 and incity26 are able to communicate withvendor cloud36 via one or more cell phone towers68 that provide Internet access to mobile phone subscribers. As indicated inFIG. 1, such users may befriends34hof a patient athospital22, although such cellular communication is not limited toonly friends34h.Further, it will also be understood that communication withvendor cloud36 is not limited to cellular communications. Thus, for example,users34 located withincity26 may communicate withvendor cloud36 using alternative means, such as, but not limited to, public WiFi access points, public wired Internet connections, and the like.
Users34 may also be located withinindividual homes28. Such users may communicate withvendor cloud36 using a home basedaccess point70, although it will be understood that alternative methods for communicating withvendor cloud36 are possible. Any conventional home-based Internet connection, such as WiFi, Digital Subscriber Lines (DSL), fiber optic connections, satellite connections, cellular connections, etc. may be used by home based users to communicate withvendor cloud36.
Vendor cloud36 allows and manages the communications betweenusers34 ofhealth info app30 who are located outside ofhospital22 and the data located athospital22. In some cases,vendor cloud36 allows communication between thehealth info app30 used bypatient34dat the hospital and thehealth info app30 installed on those userselectronic device32.Vendor cloud36 manages access rights to health information so that only authorized friends of aspecific patient34dare allowed to usehealth info app30 to see information regarding thatspecific patient34d.In other words, the information that is displayable byhealth info app30 is not open to the public. Further, the health information of afirst patient34dis only viewable by authorized friends and relatives of that first patient, and not other members of the public who may havehealth info app30 installed on theirdevice32. Thus, for example, if there are two patients athospital22 and the first patient has a first set of friends and family and the second patient has a second set of friends and family, the first set of friends and family will only be able to access information about the first patient usinghealth info app30, not information about the second patient. Similarly, the second set of friends and family will only be able to access information about the second patient usinghealth info app30, not information about the first patient.
Vendor24 may also have one or more copies ofhealth info app30 operating on one ormore devices32 that are directly coupled tovendor cloud36. Such users include one or more Information Technology (IT)persons34gwho are able to actively manage the operation ofhealth info app30, troubleshoothealth info app30, and access information regarding the operation of health info app.Vendor24 may also include one ormore service technicians34fwho usehealth info app30 for scheduling, monitoring, and carrying out the servicing of one or more medical devices used byhospital22.
AlthoughFIG. 1 illustrates asingle hospital22, it will be understood that this is merely for purposes of illustration. In alternative embodiments ofhealth information system20,multiple hospitals22 are coupled tovendor cloud36, each of which includes alocal vendor server48 that manages communications between thevendor cloud36 and thatparticular hospital22. Further, it will be understood thathealth info app30 is not limited to be used only athospitals22, but instead may be used at other healthcare facilities, nursing homes, clinics, treatment facilities, and/or other locations. Still further,health info app30 is, in some embodiments, a thin client app that runs thinly on thedevice32 with most of its computations done remotely at eitherlocal vendor server48 and/or one or more computing resources located atvendor24. In other embodiments,health info app30 is a thick client app that runs thickly ondevice32 and utilizeslocal vendor server48 and/or the resources ofvendor24 primarily for accessing data it does not have local access to and/or for communications.
Health info app30 is configured in one embodiment to provide timely and contextual information regarding one or more aspects of a patient's visit tohospital22. These features are discussed in more detail below but generally include information regarding arrival at the hospital (e.g. parking, location, check-in, etc.), the patient's expected treatment and procedures, the patient's schedule, milestones achieved by the patient, maps of locations within thehospital22, general medical information, providing feedback to thehospital22 regarding the patient's visit, and follow-up information for after the patient's discharge from thehospital22. In other embodiments,health info app30 is also configured to provide information used for managing one or more pieces of medical equipment at thehospital22. In these embodiments, the equipment management features may be combined together with the patient information features ofhealth info app30, or they may be included in a separatehealth info app30 that is only accessible to authorized users who have need for such equipment management information. If the patient information features and equipment management features are combined into a singlehealth info app30, thenhealth info app30 is configured to limit usage of the equipment management features to only personnel having need for that information, and to likewise limit usage of the patient information features to only people who are authorized to access such information.
FIG. 2 illustrates one manner of allowing auser34 to gain access to and/or installhealth info app30. That is, a user may navigate to a particular web-page, or other Internet location, using his or herdevice32. When arriving at that web-page, or other location, the user is prompted for a code that is entered into acode field72. When an authorized code field is entered infield72, the user is able to installhealth info app30 on his or herdevice32. The list of authorized codes is maintained atvendor cloud36 and/or atlocal vendor server48.Hospital22 and/orvendor24 distribute these codes topatients34dand other authorizedusers34 in cooperation with each other. In some embodiments, one or more additional codes are provided to a patient34dwho is given permission to share those additional codes with people of his or her choosing, such as family members, friends, or other individuals.
In some embodiments,hospitals22 may encourage the use ofhealth info app30 by providing a bar code or QR code at various locations withinhospital22. After scanning the bar code or QR code, the user is taken to the download screen, such as shown inFIG. 2. In some embodiments,hospital22 may providepatients34dwith adevice32a,32c,or the like, that hashealth info app30 pre-loaded on it.Hospitals22 may also advise and/or remind thepatients34dto downloadhealth info app30 upon check in. The code for aparticular patient34dmay be provided at check in, sent to the patient'sdevice32 prior to check in (email, text, etc.), sent via conventional postal mail, or delivered in other manners.
As noted,vendor24 andhospital22 cooperate and share information regarding what codes have been provided tousers34. In this manner, when aparticular hospital22 provides a code to aparticular patient34d,vendor24 is apprised of this fact so that communications received atvendor cloud36 from sources outside of the that hospital22 (e.g.city26 and/or home28) are routed to theproper hospital22.Vendor24 andhospital22 may also agree that the codes provided touser34 expire after certain time periods so thathealth info app30 may no longer provide health information after those time periods expire. The time periods may vary fordifferent users34, the individual schedule and/or treatment of particular patients, and/or based on other factors. In some embodiments, after the time period has expired, apotential user34 who has not downloadedhealth info app30 is no longer able to do so. Further, in some embodiments,users34 who have already downloadedhealth info app30 are no longer able to use some or all of the features ofhealth info app30 after the appropriate time period has expired.
After auser34 has entered an approved code intocode field72,health info app30 is downloaded and installed on that user'sdevice32. The downloadedhealth info app30 comes fromvendor24, who may storehealth info app30 onapplication server44. In some embodiments,vendor24 allows one or more copies ofhealth info app30 to be stored atlocal vendor server48 so thathealth info app30 may be downloaded to devices withinhospital22 without requiring access tovendor24. This enableshealth info app30 to be installed when communications withvendor cloud36 may be temporarily interrupted. In still other embodiments,health info app30 may be downloaded from one or more commercially available app stores, such as, but not limited to, the Apple iTunes store or Google Play store. When downloaded from these commercial stores, the user may need to enter the code prior to installation ofhealth info app30 or it may be entered after download and installation ofhealth info app30. In some embodiments, a first code may need to be entered for downloading and a second code may need to be entered for usinghealth info app30. Other variations are possible.
Oncehealth info app30 is installed on a particular device,health info app30 is configured to tailor many of the features and information provided to theuser34 based upon the user's location. As shown inFIG. 3,health info app30 uses geofencing to determine one or more features to activate and/or data to display or make available.FIG. 3 illustrates a geo-fencedarea74 of anarbitrary hospital22. The boundaries of geo-fencedarea74 may vary (including, but not limited to, geofenced areas as small as an individual bay of a multi-tenant hospital room), and multiple geo-fencedareas74 of different sizes and/or shapes may be included for asingle hospital22.
Health info app30 uses the geo-fencedareas74 in conjunction with location information provided by device32 (e.g. the location services of asmart phone32a) and/or the location information provided from a hospital's location system (e.g. beacons66 and/or any of the location techniques previously described).Health info app30 uses this location information to detect when auser34 crosses one of the boundaries of geo-fencedarea74. As will be described in more detail below,health info app30 is configured in some embodiments to take one or more appropriate actions in response to such boundary crossings. In one embodiment,health info app30 provides info to auser34 that wasn't previously provided to the user prior to the user crossing the geo-fenced area. As one example,health info app30 provides directions to theuser34 ofapp30 regarding where to park, enter, and/or walk within thehospital2 when the user crosses a geo-fenced area that encompasses thehospital22.
In addition to displaying location-sensitive information and/or providing location-sensitive features,health info app30 is also configured to display time-sensitive information and/or provide time-sensitive features. As shown inFIG. 4,health info app30 uses the current date76 (the 19thday of the month) and/or time to display data and/or provide different features, as will be discussed in greater detail below. In some embodiments, for example,health info app30 compares the current time and/or date to one or more events on a time line of the patient's care and takes action according to the proximity of the events to the current time and/or date. For example, if a patient is scheduled for a medical treatment on a specific date and the treatment requires the patient to fast for so many hours prior to the treatment,health info app30 is adapted to send a reminder to the patient (e.g. a text, email, or the like), or otherwise issue a reminder alert (by sound, vibrations, illuminating one or more lights, etc.) when the time for fasting arrives (and/or at a predetermined amount of time prior to its arrival). Other time sensitive reminders, information displays, and/or feature provisions are of course also possible.
FIG. 5 illustrates atimeline78 of an arbitrary example of a patient's schedule with respect to a particular hospital and/or treatment plan.Timeline78 identifies one ormore events80 that are scheduled to occur for a particular patient.Timeline78 is displayable tousers34 ofhealth info app30. The information intimeline78 is communicated tohealth info app30 fromEMR server52 and/or from any other servers maintained athospital22 that contain this information. In addition to displayingtimeline78,health info app30 is configured to provide reminders, locations, and directions associated with each of theevents80. Thus,health info app30 allows a user to select any of theevents80 to receive more information about theevent80, including, but not limited to, the content, time, and/or location of the event, and directions to the event.Health info app30 displays this information in response to the users selection of aparticular event80. It will be understood that the term “selecting” as used herein includes not only clicking or double clicking with a computer mouse, but also touching the area of a touchscreen display that corresponds to the location of the selectedevent80, and/or any other known methods for choosing an item displayed on a screen of anelectronic device32.
FIG. 6 illustrates one example of amain menu screen82 thathealth info app30 displays on thedevice32 on which it has been installed.Main menu screen82 includes a plurality of menu options that a user may select. These include, but are not limited to, atimeline option84, aneducation option86, away finding option88, apatient information option90, abadge option92, and afeedback option94. Examples of screens displayable byhealth info app30 in response to selectingtimeline option84 are shown inFIGS. 7-13. Examples of screens displayable byhealth info app30 in response to selectingeducation option86 are shown inFIGS. 14-15. Examples of screens displayable byhealth info app30 in response to selectingway finding option88 are shown inFIGS. 16-19. An example of a screen displayable byhealth info app30 in response to selectingpatient information option90 is shown inFIG. 20. Examples of screens displayable byhealth info app30 in response to selectingbadge option92 are shown inFIGS. 21-24. Examples of screens displayable byhealth info app30 in response to selectingfeedback option94 are shown inFIGS. 25-28.
It will be understood by those skilled in the art that the particular set of options shown onmain menu screen82 may be changed from what is illustrated inFIG. 6. Additional and/or fewer options are included in some embodiments. In some embodiments, the options presented byhealth info app30 vary based upon theparticular user34 ofapp30 with some users being prevented from accessing one or more options. Still further, in some embodiments, the set of menu items shown onscreen82 changes in response to the current time and/or the location of theuser34.
As noted,FIGS. 7-13 illustrate a plurality of screens that are displayable byhealth info app30 in response to a user selectingtimeline option84 onscreen82.FIG. 7 shows acalendar screen96 in which the patient'stimeline78 is shown on a calendar. In some embodiments,health info app30 is configured to automatically integrate theevents80 oftimeline78 into a conventional calendar program that is also executing on the users device32 (e.g. a Microsoft Outlook calendar, Google calendar, Apple calendar, etc.). In this manner, theuser34 may use all of the reminder features (and other features) of their preferred calendar program with theevents80 oftimeline78.
In some embodiments ofhealth info app30, whenhealth info app30 is downloaded on adevice32 other than the patient34d's device,health info app30 is configured to populate the calendar with an identification of the patient34dso that the user of that device understands who the calendar entries relate to. Such patient identification is not provided, in some embodiments, by the copy ofhealth info app30 that is executing on the patient's device because the patient already knows that theevents80 on his or her calendar relate to himself or herself.
FIG. 9 illustrates asummary screen98 that summarizes all of the events that have occurred so far with respect topatient34d.These events include not only theevents80 scheduled ontimeline78, but any events that have occurred that were not ontimeline78.Summary screen98 is displayed, in some embodiments, the first time auser34 selectstimeline option84 from menu screen82 (FIG. 6). When the user subsequently selectstimeline option84,health info app30 displays a different screen, such as the screen shown inFIG. 9.
Thesummary screen98, as well as the other screens shown inFIGS. 9-13, are populated with content based upon communications betweenhealth info app30 andEMR server52. That is,health info app30 retrievesevents80 and information regarding those events fromEMR server52. In addition,health info app30 is configured to allow on or more caregivers to use their own copies ofhealth info app30 to input data regarding one ormore events80 ofpatients34dunder their care. As a result, the timeline screens shown inFIG. 9-13 may include content that is provided from the caregivers associated with a patient that is sent from thedevices32 of those caregivers tolocal vendor server48, which then forwards the information to thehealth info apps30 executing on thedevices32 that are authorized to receive data for those particular patients. Still further, in some embodiments,health info app30 retrieves information for populating the screens ofFIGS. 9-13 from one or more other servers in communication withnetwork50.
In some embodiments,health info app30, or a server in communication with health info app30 (e.g. local vendor server48), reads medical codes fromEMR server52 and translates the codes into a written description that is understandable to people who are not medical coders. For example, an ICD code ICD-9-CM might be translated to “administered diphtheria immunization.”Health info app30, or a server in communication therewith, is configured in some embodiments to convert codes from different coding systems, such as ICD, HCPCS, CPT, ICF, DRG, and/or NDC into written descriptions that are understandable byuntrained users34 ofhealth info app30.
FIG. 9 illustrates aday listing screen100 that lists one ormore event80 that have occurred, or are scheduled to occur, on a particular day. In the example shown inFIG. 9, there are fiveevents80 listed for November 5, which is an arbitrarily selected day. If auser34 selects one of theevents80 shown onday listing screen100, additional information is retrieved byhealth info app30, if available. Such additional information may include links to documentation, forms, reminders, appointments, staff information, and/or any other information relevant to theparticular event80.
As one example,FIG. 10 illustrates an alternativeday listing screen100a.Theparticular event80 shown onday listing screen100ais a report regarding the sleep quality of a particular patient. If a user selects thisevent80,health info app30 brings up adetailed screen102, such as shown inFIG. 11, that shows more detailed information regarding the event. In this particular example,detailed screen102 identifies additional details regarding quality of a patient's sleep. In one embodiment, this sleep information is retrieved fromlocal vendor server48 which receives this information from one or more sensors positioned on, or within, the patient's hospital bed. For example, in some embodiments ofhealth information system20, one or more beds or stretchers ofhospital22 have sleep sensors incorporated therein in the manner disclosed in commonly assigned U.S. patent publication 2016/0022218 filed Mar. 13, 2014, by inventors Michael Hayes et al. and entitled PATIENT SUPPORT APPARATUS WITH PATIENT INFORMATION SENSORS, the complete disclosure of which is hereby incorporated herein by reference. When equipped with such sleep sensors, the sleep sensors either communicate their data directly tolocal vendor server48, or they communicate their sleep data to a different server onnetwork50 that then shares the sleep quality data withlocal vendor server48.Local vendor server48, in turn, shares the sleep quality data with thehealth info apps30 that are operating withinhospital22 and that are permitted to receive such information.
As shown inFIG. 11, still more information regarding the patient's sleep may be available by selecting an additional information icon104. When selecting additional information icon104, further information regarding the patient's sleep, including detailed sleep quality information for individual days of the patient's visit may be displayed. Such additional information may include the amount of sleep the patient received each day, the quality of that sleep, the categorization of the sleep (amount of REM sleep, etc.), and/or the start and stop times of the sleep, including interruptions.
FIGS. 12 and 13 illustrate still otherday listing screens100band100cthat are displayable byhealth info app30.Day listing100bshows an illustrative listing of events that may occur for a patient prior to the patient being discharged from the hospital.Day listing100cshows an illustrative listing of events that may occur on the day that a patient is discharged. As with theother day listings100, a user may select any of theevents80 listed therein for further information.
Health info app30 is configured to allow a patient, or the patient's spouse, to authorize the sharing of one or more types of information with friends and/orfamily members34hand/or34i.That is, a patient34dand/or his or herspouse34eare able to usehealth info app30 to select what information they are willing to share about the patient's visit tohospital22 with friends andfamily members34hand34i. The selection of what information to share and what information not to share is forwarded tolocal vendor server48 which stores that information. Whenlocal vendor server48 receives information from one or more servers onnetwork50, or fromInternet connection38, it determines whether the receiving information is to be shared withother users34 who are associated with a particular patient (e.g. friends or family members of that patient). Information that is to be shared is forwarded to thedevices32 of the authorized recipients viaInternet connection38. Information that is not to be shared is forwarded, as appropriate, to only the device(s)32 associated with the patient34dand/or his or herspouse34e.
In some embodiments,health info app30 is configured to communicate with a bed server (not shown) that receives status information from the hospital beds. Such a bed server determines information about the patient, such as his or her sleep status (including, but not limited to, the amount of sleep, when the patient has fallen asleep or is awake, the quality of the sleep, the type of sleep, etc.), when he or she is present in the bed or absent from the bed, and other data regarding the patient's movement or activities while in the bed. This bed status information is forwarded tolocal vendor server48 which, as appropriate, forwards it to one ormore users34.
For example, if a patient falls asleep and this is detected by sensors integrated into the patient's bed, the bed communicates a message to the bed server indicating that the patient has fallen asleep. This information is then forwarded by the bed server tolocal vendor server48.Local vendor server48 then updates a current status of the patient to being asleep. Any copies ofhealth info app30 that are installed ondevices32 that are authorized to receive information about that particular patient are then forwarded a message indicating that the patient is currently asleep. In some embodiments, the forwarded message is sent to thosedevices32 immediately so that the devices can alert theusers34 of the change in the patient's status (i.e. having fallen asleep). In other embodiments, thehealth info app30 does not receive the sleep status message until a user executeshealth info app30 on his or herdevice32.Health info app30 andserver48 operate in a similar manner for other data received byserver48 that comes from other sources, such asEMR server52 and/or other devices32 (e.g. info entered from acaregiver30's device who is associated with a particular patient). Still further, in some embodiments, the notification of an event detected byhealth info app32 is forwarded to a patients' social media page, such as a Facebook page. The patient and other users ofhealth info app30 are able to configure which social media websites receive information fromhealth info app30.
Beds that are configured to detect when a patient has fallen asleep or is awake, when the patient is out of bed or has returned, the quality of the patient's sleep, and other characteristics regarding the patient's movement and activities are disclosed in commonly assigned U.S. patent publication 2016/0022218 filed Mar. 13, 2014, by inventors Michael Hayes et al. and entitled PATIENT SUPPORT APPARATUS WITH PATIENT INFORMATION SENSORS, the complete disclosure of which has already been incorporated herein by reference.
As noted previously,FIGS. 14 and 15 illustrate educational screens that are displayable in response to a user selectingeducation option86 from main menu screen82 (FIG. 6).Educational screen106aprovides more information to auser34 of health info app regarding cardiac arrest. Educational screens, such as106a,are provided byhealth info app30 accessing data from one or more databases, including, but not limited to,database58. In some embodiments,health info app30 accesses educational information from one or more locations using the Internet access provided tolocal vendor server48. Education screens106 may also provide videos and/or other multimedia presentations that are viewable by a user ofdevice32. In some embodiments, such education content is streamed to thedevice32 viastreaming media server54.
Educational screen106bofFIG. 15 displays a plurality of conversations from an electronic chat room.Health info app30 enables a user of adevice32 to read, participate in, and start conversations within a chat room that is maintained byhospital22, a plurality ofhospitals22, another healthcare provider, and/or any entity interested in providing health-related chat rooms. In this manner, patients, as well as their friends and family, may engage in electronic conversations with other patients, and/or friends and families or other patients, regarding healthcare information. In this manner, a patient undergoing a particular medical treatment may be able to contact other patients who have undergone the same medical procedure. Further, questions of a patient may be answerable by other people who have participated in, or are participating in, the chat room.
FIGS. 16-19 illustrate navigation screens108 that are displayable byhealth info app30 in response to a user selectingwayfinding option88 from main menu screen82 (FIG. 6).Navigation screen108aofFIG. 16 provides a map showing the location ofhospital22 with respect to its surroundings.Health info app30 allows theuser34 to zoom in or out of the map ofnavigation screen108a.In some embodiments,health info app30 utilizes commercially available mapping services for displaying the information onscreen108a,such as, but not limited to, Google Maps.
Navigation screen108bofFIG. 17 illustrates a more detailed map that includes portions of internal floor plans ofhospital22.Navigation screen108balso includes a menu oflocations110. In response to selecting an item withinmenu110,health info app30 identifies the location of the selected menu item on a map and/or identifies the users current location relative to the location of the selected item.Navigation screen108cofFIG. 18 illustrates in even more detail a floor plan of thehospital22 that identifies individual rooms withinhospital22.Navigation screen108dillustrates a more detailed menu oflocations110athat a user may select. When selecting one of the items ofmenu110a,health info app30 displays the location of the selected item on a map and/or provides directions to the user of how to get to that location from his or her current location.
FIG. 20 illustrates an example of apatient information screen112 that is displayable byhealth info app30 in response to a user selectingpatient info option90 from main menu screen82 (FIG. 6).Patient info screen112 is only accessible to authorized users ofhealth info app30, such as authorized family members or friends of aparticular patient34d.Patient info screen112 allows these authorized individuals to add information regarding the patient that may not have been added to the hospital's records. Thus, in the example illustrated inFIG. 20, a particular patient may have been admitted to thehospital22 without the hospital entering the patient's race, ethnicity, preferred language, current medications, and/or allergies into its records. This information can be added by an authorized friend or family member by entering the missing information onpatient information screen112. This is accomplished by the friends or family members by using their copy ofhealth info app30 that is installed on theirdevices32. Thosedevices32 then communicate this information tolocal vendor server48.
Local vendor server48 forwards the information entered onpatient information screen112 toEMR server52 and/or to any other server located withinhospital22 that the hospital administration has designated. The information is then available to the hospital personnel. In some embodiments, the information is flagged as having been entered by a friend or family member, rather than a hospital employee, so that viewers of the information are apprised of the source of the information. In addition, some embodiments ofhealth info app30 allow friends or family members to change information that was previously entered by hospital personnel, but which may be mistaken. In these embodiments,health info app30 maintains both the incorrectly entered information and the family-supplied corrected information so that viewers can see both data entries. Appropriate individuals at thehospital22 may then be tasked with rectifying such data discrepancies.
FIG. 21-24 illustrate examples of badge screens114 that are displayable byhealth info app30 in response to a user selectingbadge option92 from main menu screen82 (FIG. 6). Badge screens114 are displayed to show a patient's progress in achieving one or more badges, or other types of milestones, while they are athospital22.Badge screen114aofFIG. 21 illustrates a plurality ofbadges116 that are achievable by a particular patient at a particular hospital22 (and which may vary depending upon the reason for the patient's visit to the hospital). In the example shown inbadge screen114a,two of thebadges116aand116bare highlighted in a different color in order to show that those two badges have been achieved by that particular patient.
Badge116ais awarded to a patient when the patient has achieved a mobility milestone. The mobility milestone may vary from patient to patient and condition to condition, but is generally an achievement that is awarded when the patient has reached a predetermined level of mobility. This may include the patient sitting up on his or her own, entering or exiting his or her bed without assistance, being out of bed for a predetermined amount of time, or still other types of mobility thresholds. In some embodiments, the mobility of the patient is measured by one or more sensors that are integrated into the patient's bed and which report their data tolocal vendor server48. The information from such sensors may be augmented by one or more additional sensors that track the amount of movement of the patient when he or she is out of bed.
In some embodiments, the beds athospital22 include mobility sensors such as those disclosed in commonly assigned U.S. patent publication 2016/0106345 filed by inventors Marko Kostic et al. and entitled PERSON SUPPORT APPARATUSES WITH MOTION MONITORING, the complete disclosure of which is incorporated herein by reference. Still further, in some embodiments, one or more mobility sensors of the type disclosed in commonly assigned U.S. patent application Ser. No. 14/928,513 are used for tracking the movement of a patient while in bed and/or out of bed. U.S. patent application Ser. No. 14/928,513 is commonly assigned to the assignee of the present application and was filed Oct. 30, 2015, by inventors Richard Derenne et al and entitled PATIENT SUPPORT APPARATUSES WITH PATIENT MOBILITY MONITORING, the complete disclosure of which is hereby incorporated herein by reference.Health info app30 may also derive mobility information fromEMR52 and/or other sources.
Badge116bofFIG. 23 may be awarded when a patient has achieved one or more sleep milestones while inhospital22. The determination of these sleep milestone may be carried out in any of the manners described above with respect toFIG. 11. Sleep milestones may also be determined by consulting data stored inEMR52. Regardless of where the data is stored and the source of such data,health info app30 awards badge116bwhen one or more milestones relating to sleep are achieved. Administrators and/or healthcare professionals athospital22 are able to use their copies ofhealth info app30, along with their administrator status forhealth info app30, to input and change the sleep milestone for which a patient is to be rewarded with a badge. That is,hospital22 is able to custom tailor thesleep badges116baccording to whatever thresholds it desires, including customizing the thresholds to individual patients. Similar customization and threshold selections are available to authorized individuals of thehospital22 for all of theother badges116 discussed herein.
FIG. 24 illustrates adischarge badge116cthat is awarded to a patient when he or she has recuperated sufficiently to be able to be discharged fromhospital22.Other badges116 may also be illustrated, including, but not limited to, badges relating to eating, medications, treatments, procedures, etc. In some embodiments,health info app30 is configured to allow caregivers to add comments to the badges. Such comments are added through the use of the caregiver'shealth info app30, which is configured to allow them to enter comments for specific patients under their care.Health info app30 is also configured to allow authorized hospital administrators to design their own badges and the criteria for awarding them, thereby allowinghospitals22 to tailor their badges in any manners they see fit.
FIGS. 25-28 illustrate examples of feedback screens118 that are displayable byhealth info app30 in response to a user selectingfeedback option94 from main menu screen82 (FIG. 6). Feedback screens118 allow a patient (and in some cases people other than the patient, such as the patient'sspouse34eand/orfamily members34i) to provide feedback to the hospital about different aspects of the patient's stay at the hospital. For example,feedback screen118aofFIG. 25 asks a patient to rate his or her pain level. In the illustrated example, this question is answered based upon a five option rating system. Other rating systems for assessing a pain level can, of course, be used. Regardless of the specific rating scale, the patient's answer is relayed byhealth info app30 to the appropriate personnel withinhospital22, such as, but not limited to, the caregivers assigned to that particular patient. This feedback may be forwarded to those caregivers viamobile information server60, which may send the patient's answers directly to thesmart phone32a,badge, pager, or other mobile device that is associated with the patient's caregivers. In this manner, the caregivers are provided with up-to-date feedback from the patient, even if they are not in the room with the patient. Timely intervention can then be undertaken.
FIG. 26 shows another example of afeedback screen118bthat may be displayed to inquire about the quality of nurse communications. Depending upon how aparticular hospital22 configures health info app, the patient's answer to the question ofFIG. 26 may be forwarded to an administrator or manager instead of to the patient's caregiver. Such administrators are then informed of the patient's assessment of caregiver communications and can take responsive action, as deemed appropriate.
Feedback screen118cillustrates an inquiry to the patient regarding the cleanliness of his or her restroom. As with the other feedback screens118, the patient's response to this screen may be forwarded to individuals that are custom selected by the hospital. That is, instead of forwarding the patient's answer to the inquiry ofFIG. 27 to a caregiver, this response may be forwarded to appropriate personnel in the hospital's janitorial or cleaning department.
The types of feedback screens118a-cshown inFIGS. 24-27, as well as other feedback inquiries, are displayed on the user's screen not only in response to the user selectingfeedback option94 of main menu82 (FIG. 6), but also in response to the passage of time and/or the occurrence of certain events. Thus, for example, a feedback screen118 is presented in some embodiments automatically every morning that requests patient feedback regarding how well the patient slept. Another feedback screen118 may be automatically generated after every meal requesting feedback about the quality of the patient's meal. Yet another feedback screen may automatically be generated after a caregiver exits the patient's room that inquires how well the caregiver explained information (the caregivers exit may be determined by a conventional tracking system installed inhospital22 that communicates with a tracking server onnetwork50 that is in communication with local vendor server48). Still other feedback inquiries may be configured to automatically appear on the screen of theusers device32 based upon the time of day and/or one or more events associated with the patient. Depending upon the specific inquiry, the patient's answers are forwarded to the appropriate personnel withinhospital22 usingmobile information server60 and/or other servers onnetwork50.
FIG. 28 illustrates afeedback screen118dthat illustrates a portion of an HCAHPS survey. The acronym HCAHPS refers to Hospital Consumer Assessment of Healthcare Providers and Systems. HCAHPS surveys are a set of questions that are asked of patients regarding their visit to a particular hospital. The results of such surveys are forwarded to administrators ofhospital22.Hospital22 also forwards the results of these surveys to a central repository in accordance with federal law. Compilations of the results are then made available to the public.
In some embodiments,health info app30 is configured to automatically present a feedback screen, such asscreen118dofFIG. 28, to the user at or about the time the patient is being discharged fromhospital22. In this manner, the patient is more likely to take the time to fill in responses to the survey (as opposed to mailing the survey to the patient's home and asking him or her to fill out the survey after they've left the hospital). The automatic presentment of thisHCAHPS screen118dmay be accompanied with an aural or vibratory notification on the patient's electronic device32 (such assmart phone32a) so that the patient34dis alerted to the fact thathealth info app30 is requesting the attention of the patient. Similar aural or vibratory notifications may be generated at other times whenhealth info app30 has information to display that is of importance.
FIGS. 29-30 illustrate examples of communication screens120 that are displayable byhealth info app30 in response to a user navigating to these screens. AlthoughFIG. 6 does not illustrate a communication option on themain menu screen82 displayed therein, thismain menu screen82 may be modified to include a communications option that, when selected, brings up one or more communication screens120 such as shown inFIGS. 29-30. Communication screens120 may also be accessed by auser34 ofhealth info app30 in other manners. Regardless of how accessed,communication screen120aofFIG. 29 displays a chat feature ofhealth info app30 that allows a patient34dto communicate with his or her caregivers, such asnurse34c.This communication takes place viahealth info app30 communicating messages tolocal vendor server48 which forwards those messages tomobile information server60.Mobile information server60, in turn, forwards the messages to thedevice32 associated with thenurse34cto whom the patient is communicating. Messages from thenurse34care sent back to the patient'sdevice32 in the same manner.
Communication screen120bofFIG. 30 illustrates a translation feature ofhealth info app30. This translation feature is, in some embodiments, both textual and aural. When textual, the translation feature translates text, such as that entered when chatting in the manner illustrated inFIG. 29, from one language to another language. This enables a patient who does not speak the language of the caregivers within ahospital22 to communicate more easily with the caregivers. When the translation feature is aural, the patient, orother user34, speaks into theelectronic device32 and thehealth info app30 detects the speech from the microphone of theelectronic device32.Health info app30 translates the detected speech into the desired language and generates speech in that language using the speaker(s) of theelectronic device32. Either of both of these translation features may utilize known translation software. Further, in some embodiments,health info app30 forwards the input text and/or detected speech to another computer or service that is accessible tohealth info app30 via local vendor server48 (and its connection bothnetwork50 and the Internet), and that other computer and/or service performs the translation and sends the translated result back to thedevice32 from which the text or speech originated.
It will of course be understood that the information described above that is displayable to auser34 ofhealth info app30 can vary from the specific information shown and discussed.Menu82 may include different options from that illustrated, as well as more or fewer options. In some embodiments,health info app30 also displays information for a patient prior to his or her scheduled visit that may be useful to the patient. This information may include such things as such as dietary restrictions, driving directions, check-in information, etc. Once the patient arrives at hospital22 (as detected by the geolocation fencing feature described above),health info app30 may display additional information to the patient, such as the wait times for clinical procedures, a question log for nurses, education material, bed controls, etc. After the patient leaveshospital22, or is about to leave the facility, still other information is displayable byapp30, such as discharge procedures, post-visit dietary restrictions, medications, etc.
FIGS. 31-42 illustrate features and screens ofhealth info app30 that relate to management of one or more medical devices inhospital22 and/or to one or more administrative tasks ofhospital22. As a result, the screens and features illustrated in these FIGS. are not intended to be used bypatients34dand/or the patient's friends or family. Instead, these features and screens are intended for use by hospital personnel and/or outside support technicians who communicate with the hospital staff. As a result,health info app30 limits access of these screens and features to only authorized personnel. Indeed, in some embodiments, as mentioned previously, the content and features shown in these FIGS. are incorporated into a separate health info app that is independent of thehealth info app30 described above. However, for purposes of the following written description, these features and content will be described as being part ofhealth info app30, although it will be understood that they could be implemented as a separate application, or multiple separate applications.
FIGS. 31 and 32 illustrate feedback summary screens122 that gather, process, analyze, and display the results of the feedback provided bypatients34dusing the feedback screens118 discussed above.Feedback summary screen122aofFIG. 31 includes a plurality of individual questions summaries124 that summarize the results from a plurality ofpatients34dto specific questions. For example,question summary124asummarizes the results of patient responses to inquiries regarding the quietness of the patients' stays athospital22. This summary includes a presentation of the average of the responses received (4.6 in this case), as well as atrend indicator126 indicating the trend (up, down, or constant) of responses over the last24 hours.Summary124bpresents similar information for patient responses to the specific question of how clean the bathrooms were perceived to be by thepatients34d.
In addition to presenting individual question summaries124,feedback summary screen122aofFIG. 31 illustrates detailed summaries128 regarding one or more of the feedback questions presented topatients34d.Detailed summaries128 provide additional information about specific inquiries that goes beyond what is shown in question summaries124. For example,detailed summary128aillustrates actual noise level measurements taken in patients' rooms over a given time period. These noise measurements are taken by microphones, or other sound sensors, positioned in the patient rooms ofhospital22 and, in some embodiments, other locations outside of the patient's rooms. The outputs from these sensors are fed to a server onnetwork50 that shares the results withlocal vendor server48.Local vendor server48, in turn, shares the results with thosehealth info apps30 that are authorized to receive this data.
In addition to including sound data,detailed summary128aofFIG. 31 also displays actual light measurements that are taken in the patients' rooms over a given time period. These light measurements are taken by light sensors who communicate their measurements to a server onnetwork50. That server shares the results withlocal vendor server48 which in turn forwards the results to thosehealth info apps30 that are authorized to receive this data. In some embodiments,health info app30 is also configured to display agraphical map130 showing measured noise and/or sound levels for one or more rooms over a given time period. The values of the measurements are displayed in a color coded fashion to indicate different measured intensities of the sound and/or light. Detailed summary128 therefore provides measured values of sound and/or light along with the results of the patients' responses to inquiries about the quietness of their stay. This simultaneous presentation of subject and objective data allows hospital personnel to view and understand correlations between the patient's subjective observations and the objective measurements of the various sound and light sensors.
As shown inFIG. 31,detailed summary128bshows the average time taken for the patient's restrooms to be cleaned. This information is provided tohealth info app30 via communications with one or more of the servers onnetwork50 that receive data from the janitorial staff ofhospital22. The janitorial staff inputs information into the server, which is shared withlocal vendor server48, after they are finished cleaning each restroom inhospital22.Health info app30 pulls this information from the janitorial server and displays it on feedback summary screens, such asscreen122aofFIG. 31.
FIG. 31 also includes an HCAHPS score summary icon132. When a user selects icon132,health info app30 brings up anHCAHPS summary134, such as the one shown inFIG. 32.HCAHPS summary134 is shown as a circle dividing into a plurality ofsections136. Eachsection136 corresponds to a section of the HCAHPS survey. For example,section136arelates to the hospital environment;section136brelates to the care from nurses;section136crelates to the care from doctors. Eachsection136 includes anaverage score138 indicating the average scores received by the hospital from its patient's for those questions on the HCAHPS survey that fall within the particular category of thatsection136. Eachsection136 also includes apercentile indicator140 that indicates the percentile of the hospital's scores for the HCAHPS survey questions relating to the subject matter of thecorresponding section136. Thus, for example,HCAHPS summary134 ofFIG. 32 indicates that the hospital scored in the 72ndpercentile for the questions relating to the hospital environment (section136a).
Thepercentile indicators140 are based on a comparison of the hospital's scores to the national scores for those HCAHPS sections, in some embodiments. In some embodiments,health info app30 is configured to allow health care administrators compare their HCAHPS scores to any other geographic area of interest. Such geographic areas include cities, counties, states, regions of the country, and the entire country.Health info app30 is also configured to allow hospital administrators to compare their HCAHPS scores to otherspecific hospitals22. The HCAHPS scores from other hospitals are pulled byhealth info app30 from one or more existing Internet-accessible national databases that store the scores and make them available to hospitals.
Health info app30 is configured to share patient answers to feedback questions, such as the HCAHPS survey, as well as other feedback question, with hospital personnel immediately. In this manner, appropriate hospital personnel can receive certain types of feedback from the patients while the patients are still inhospital22. This gives the hospital the opportunity to address any issues the patient may be having prior to the patient leaving. This may improve the overall experience of the patient as well as lead to higher scores on the HCAHPS survey for the hospital.
In some embodiments,health info app30 is adapted to present questions to the patients that are customized by the hospital administrators. The hospital administrators can therefore ask about specific items of interest to them. Further,health info app30 is configurable by the hospital administrators in terms of the timing of those questions. Consequently, the hospital administrators can determine not only the content of one or more questions to the patients, but also the timing of those questions, the frequency of questions, and/or the overall amount of questions. Still further, the questions may be custom tailored based upon the reasons for the patient's stay at the hospital, based upon his or her caregivers, based upon the location of the patient inhospital22, and/or based upon other factors. In this manner, specific questions may be presented to the patients that give the administrators more focused feedback on areas of potential interest to the administrators.
FIGS. 33-37 illustrate rounding screens142 that are presented byhealth info app30 to caregivers ofhospital22. Rounding screens142 assist the caregivers in performing their rounding duties and documenting their work. Roundingscreen142aofFIG. 33 presents a list of patients. The list may be sorted in any suitable manner, including by assigned caregiver, location, alphabetical order, location withinhospital22, or in other manners. The data in this list is pulled fromEMR server52 byhealth info app30. When a caregiver selects one of the patients listed in thescreen142aofFIG. 33,health info app30 displays additional information about the selected patient.
FIG. 34 illustrates one example of the additional information that may be displayed byhealth info app30 in response to a user selecting one of the patients shown on the list ofFIG. 33. Roundingscreen142bofFIG. 34 shows the patient's name, disease or other health condition, hospitalization date, target discharge date, last rounds check, whether the patient is a fall risk or not, and, in some embodiments, information derived from the patient's bed. The bed derived information may include the bed's ID, its location, whether the patient is present on the bed or not, whether the bed is off-line or on-line with respect tonetwork50, and any errors that may be present with the bed. Such information is passed from the bed to a server onnetwork50, such as a dedicated bed server (not shown) or other type of server, that communicates withlocal vendor server48. Beds that are capable of transmitting this type of information to a hospital network are disclosed in, for example, the following commonly assigned U.S. patent applications: U.S. Ser. Nos. 14/692,871 filed Apr. 22, 2015, by inventors Marko Kostic et al. and entitled PERSON SUPPORT APPARATUS WITH POSITION MONITORING; 62/253,167 filed Nov. 10, 2015, by inventors Marko Kostic et al. and entitled PERSON SUPPORT APPARATUS WITH ACCELERATION DETECTION; and 14/873,734 filed Oct. 2, 2015, by inventors Marko Kostic et al. and entitled PERSON SUPPORT APPARATUSES WITH MOTION MONITORING; the complete disclosures of all of which are incorporated herein by reference.
If a caregiver selects any of the items displayed on roundingscreen142bofFIG. 34,health info app30 displays additional information about that item. For example, if the user selects the fall risk item from thescreen142bofFIG. 34,health info app30 displays further information regarding fall risk assessments, such as the roundingscreen142cofFIG. 35. Roundingscreen142cofFIG. 35 includes a checklist of questions for assessing the fall risk of a patient. Roundingscreen142calso includes slider bars144 enabling the user to enter yes or no for each of the questions. Roundingscreen142cthereby assists a caregiver in determining whether or not a particular patient should be considered at risk for falling.Health info app30 calculates a score from the answers to the listed questions and shares the score with the caregiver. The caregiver can then enter a conclusion intohealth info app30 as to whether the patient is at risk of falling or not. In some embodiments,health info app30 is configured to automatically make this determination and enter the patient's fall risk, or lack of fall risk, into the electronic medical record of the patient that is stored onEMR server52.
Health info app30 is supplied byvendor24 with a set of pre-populated fall risk questions that are customizable by the administrators ofhospital22. Thehospital22 can therefore tailor their fall risk assessments in any manner that they see fit. Once tailored,health info app30 presents the caregivers with the custom tailored questions via a screen such as that shown inFIG. 142cofFIG. 35. The answers to the questions are forwarded byhealth info app30 toEMR server52 for storage therein.
In addition to helping the caregivers assess the fall risk of patients, rounding screens142 ofhealth info app30 also provide screens on which data associated with the caregivers rounding duties can be entered and automatically charted to the patient's electronic medical record, or to any other suitable server onnetwork50. Roundingscreen142dofFIG. 36 illustrates an example of such a screen. Roundingscreen142dincludes a list of questions withslider bars144 and/or data entry fields146 that enable the caregiver to input answers to the questions. The questions are designed to document tasks, patient conditions, and other items associated with the rounding duties of caregivers. As with the fall risk assessment questions,health info app30 is supplied byvendor24 with a list of prepopulated rounding questions that are customizable by thehospital22. The answers to the question are forwarded by thedevices32 tolocal vendor server48 which, in turn, forwards the information to the appropriate server onnetwork50, such as, but not limited to,EMR server52.
FIG. 37 illustrates an example of a roundingscreen142ethat may be displayed by health info app after a caregiver has completed all of the questions associated with their rounding duties.Screen142easks the caregiver is he or she would like to complete the rounds for a particular patient. If yes,health info app30 saves the answers and forwards them to the appropriate recipients onnetwork50. If no,health info app30 does not forward the results to network50.
FIG. 38 illustrates an environmental summary screen150 that is displayable byhealth info app30 to authorized users. Environmental summary screen150 displays data regarding the environmental conditions of a patient's room, including data regarding the sleep quality of the patient. The displayed sleep quality data (including the classification of the different types and amounts of sleep) is gathered in any of the same manners discussed above with respect toFIG. 11. The light, noise, and temperature data is gathered from light, noise, and temperature sensors positioned in the patient rooms. In some embodiments,health info app30 is configured to use the sleep quality information, as well as the light, noise, and/or temperature information, to compute a sleep score150. The sleep score is displayed onscreen148, as well as one or more of the other summary screens discussed herein (e.g. summary screens122).
FIGS. 39-41 illustrate examples of medical equipment screens152 that may be displayed byhealth info app30. Medical equipment screens152, in the examples shown in these FIGS., provide information regarding the beds of thepatients34d.It will be understood, however, that screens152 are not limited to displaying information gathered from the patient's beds, but may also or alternatively include information gathered from any other medical devices used withinhospital22. When screens152 show information from the hospital's beds, such information is transmitted by the beds to a server onnetwork50 that shares the bed information withlocal vendor server48. Various conventional beds may be used that are capable of reporting data regarding their use and status to a hospital's local area network. Suitable examples of such beds are disclosed in the following commonly assigned U.S. patent applications: U.S. Ser. Nos. 14/819,844 filed Aug. 6, 2015, by inventors Krishna Bhimavarapu et al. entitled PATIENT SUPPORT APPARATUSES WITH WIRELESS HEADWALL COMMUNICATION; 15/075,747 filed Mar. 21, 2016, by inventors Michael Hayes et al. and entitled LOCATION DETECTION SYSTEMS AND METHODS; 15/185,623 filed Jun. 17, 2016, by inventors Marko Kostic et al. and entitled PATIENT SUPPORT APPARATUSES WITH LOAD CELLS; and 14/212,367 filed Mar. 14, 2014, by inventors Michael Hayes et al. and entitled PATIENT SUPPORT APPARATUS WITH PATIENT INFORMATION SENSORS; the complete disclosures of all of which are incorporated herein by reference.
FIG. 39 illustrates amedical equipment screen152athat summarizes the feature utilization of a piece of medical equipment, such as a patient bed.Screen152ais only displayed to authorizedusers34, such as, but not limited to, service technicians and/or administrators.Medical equipment screen152aincludes acircle154 that is divided into a plurality ofsections156. Eachsection156 corresponds to a different feature or set of features of the bed. For example,circle154 ofFIG. 39 is divided into eightsections156 that correspond to the following features of a bed: protocol reminder, calculator, converter, translations, Braden scale, documentation, sound therapy, and bed status.
Each of these sections refers to different features that are provided by particular beds. The protocol reminder is a built-in feature that reminds caregivers of times and/or steps to be taken for different protocols. The calculator feature is an electronic calculator that is accessible via a screen of the bed and usable to perform calculations. The converter feature is a mathematical function that is accessible via a screen of the bed to allow a user to convert measurements expressed in a first type of units to another type of units (e.g. pounds to kilograms). The translation feature is a feature of the bed that translates words and/or speech from one language to another. The Braden scale feature is a series of questions and/or instructions that are displayable on a screen of the bed for assisting caregivers in assigning a Braden scale score to a patient. The documentation feature is a feature that allows patient data to be documented automatically via the bed toEMR server52. The sound therapy feature is a feature that allows a user to select music, or other desired sounds, to be played on the speakers of the bed. The bed status feature is a feature that allows the bed to transmit data regarding its usage and status tonetwork50. Such data may include, but is not limited to, status regarding the bed's siderails, the height of its litter frame, whether the brakes are activated or not, the state of an exit detection system, the presence or absence of the patient, and/or other data.
Eachsection156 ofcircle154 includes statistics regarding the usage of these different features. Specifically, as shown inFIG. 39, eachsection156 includes an average number of uses of a particular bed over a certain time period, as indicated byindicators158. Eachsection156 also includes apercentile indicator160 that indicates what percentile the frequencies of usage for those features fall into relative to the entire fleet of similar beds maintained athospital22. Other statistics and/or features may also or alternatively be displayed.
FIG. 40 illustrates an example of amedical equipment screen152bthat is displayable byhealth info app30 to authorizedusers34.Screen152billustrates the detailed current state of a particular medical device or piece of medical equipment. In the example shown inFIG. 152b, the medical device is a bed. As can be seen,medical equipment screen152billustrates detailed information about the status of the bed, such as the position of each of the bed's siderails, whether the brake is on or off, whether the bed is at its lowest height or not, whether the bed is in a vascular position, whether the Fowler section of the bed is at an angle greater than30 degrees, whether the exit system is armed or disarmed, and whether the bed is plugged into a source of electrical power or not. Still other information may be displayed by the bed, such as, but not limited to, a volume of the alarms for that bed and/or a style of sound for the alarms for that bed. The patient's fall risk may also be indicated onscreen152b.The specific content ofmedical equipment screen152bmay vary from that shown, depending upon the sensors, features, and capabilities of the beds used inhospital22. Further, the specific content ofmedical equipment screen152bwill change when used to display information regarding equipment other than beds.
FIG. 41 illustrates another example of amedical equipment screen152cthat is displayable byhealth info app30 to authorized users.Medical equipment screen152cis a screen that shows the status of a fleet of medical devices, rather than the status of an individual medical device, such as is shown onscreen152b.The status of the displayed medical devices is abbreviated in comparison to the detailed list of information provided viascreens152b.Each medical device shown onscreen152cis listed in itsown row162. Eachcolumn164 illustrates a different piece of information about the device.Health info app30 is programmed to allow theuser34 to sort the medical devices in any desired manner, such as by type, location, status, etc. Further,health info app30 is programmed to allow a user to sort the list according to each of the characteristics identified in the heading of each column. Thus, for example, if a user wished to display the devices in the order of highest or least amount of uptime—as indicated incolumn164a—he or she can instructhealth info app30 to do so. In some embodiments,health info app30 is also configurable to allow the user to select what columns are to be displayed on medical equipment screens, such as screen152, as well as the order in which the columns are arranged.
FIG. 42 illustrates an example of aservice screen166 that is displayable byhealth info app30 to authorizedusers34.Service screen166 may be displayed in response to selecting a particular column ofscreen152crelating to service status, or it may be selected in other manners.Service screen166 provides information regarding the servicing of a specific piece of medical equipment. In the example shown inFIG. 42, the specific piece of medical equipment is a patient bed. Other types of medical equipment, however, can have their service status information imported intohealth info app30. Regardless of which specific pieces of medical equipment are incorporated intohealth info app30,health info app30 retrieves the service status information for these medical devices via communication withlocal vendor server48, which in turn communicates with a server onnetwork50 that contains service information for equipment athospital22. In some embodiments,local vendor server48 may communicate viaInternet connection38 withvendor cloud36 and/or other another vendors computer system in which servicing information for the medical equipment is stored.
Service screen166 identifies the piece of medical equipment and, in some cases, includes apicture168 of the equipment. If there are any error codes associated with the medical equipment, they are listed onscreen166.Screen166 also includes information regarding a current service call, if any, and past servicing information for that particular medical device. For example,service screen166 shows an expected time or arrival of a service appointment, an estimate of how long the servicing will last, a case number for the service call, and any other information that may be relevant to a service call.
Service screen166 is primarily intended for use by technicians or other personnel involved in the servicing of the equipment athospital22. In some embodiments,screen166 is used byservice tech vendor34f,or by a service technician associated with the vendor of the piece of medical equipment shown onscreen166.Health info app30 is also configured to not only show service information onscreen166, but to allow users ofapp30 to enter service data onto these screens166, including requesting servicing for a particular medical device. Caregivers andother users34 ofhealth info app30 can therefore easily request service of a piece of equipment if they notice it is malfunctioning, or otherwise in need of service, while they are performing their everyday activities, thereby improving the speed at which servicing takes place.
It will be understood that the principles disclosed herein can be embodied as a software application in which instructions for one or more processors are tangibly and non-transitorily fixed in a computer-readable medium. The instructions, when executed by the one or more processors, carry out any one or more of the health information functions described herein.
Various additional alterations and changes beyond those already mentioned herein can be made to the above-described embodiments. This disclosure is presented for illustrative purposes and should not be interpreted as an exhaustive description of all embodiments or to limit the scope of the claims to the specific elements illustrated or described in connection with these embodiments. For example, and without limitation, any individual element(s) of the described embodiments may be replaced by alternative elements that provide substantially similar functionality or otherwise provide adequate operation. This includes, for example, presently known alternative elements, such as those that might be currently known to one skilled in the art, and alternative elements that may be developed in the future, such as those that one skilled in the art might, upon development, recognize as an alternative. Any reference to claim elements in the singular, for example, using the articles “a,” “an,” “the” or “said,” is not to be construed as limiting the element to the singular.