CROSS-REFERENCE TO RELATED APPLICATIONThis application claims priority to U.S. Provisional Patent Application No. 61/369,461, filed Jul. 30, 2010, which is hereby incorporated by reference in its entirety.
TECHNICAL FIELDThe disclosure generally relates to remote medical diagnostic and monitoring systems and solutions in which a physician conducts an examination of a remotely located patient, and more specifically, to a system and method for performing virtual medical examinations using secure videoconferencing and the secure transmission and receipt of patient diagnostic information.
BACKGROUNDAccess to medical care providers remains a challenge for many patient populations, both due to cost and lack of geographic proximity. Patient populations in rural areas, especially those in third world countries, will likely find themselves without adequate numbers of local treating physicians for decades to come. Many patients are house-bound and cannot easily travel to a medical clinic. In addition, certain types of specialists (e.g., neurologists) are often in short supply, leaving some patient populations underserved.
Telemedicine systems have been proposed as a way of remotely diagnosing and treating patients using telephonic communications. However, known systems typically suffer from several drawbacks. First, many of them lack adequate safeguards to protect the confidentiality of patient medical information. In the United States, the Health Insurance Portability and Accountability Act of 1996 (“HIPAA”) requires entities exchanging health care information to enact appropriate safeguards to protect the confidentiality of electronically transmitted patient information. Many prior telemedicine systems do not allow patients and physicians to communicate in real time in a manner that protects their communications from third parties.
In addition, many known telemedicine systems lack a mechanism for conveniently and securely transmitting patient diagnostic information, such as blood pressure data, pulse oxymeter data, spirometer data, stethoscope data, pulse and blood gas analysis, weight, electrocardiograph data, and blood chemistry data, to a patient records server located remotely from the patient. Many known systems also lack a mechanism by which a physician can remotely and securely access such data. Thus, a need has arisen for a system and method for performing virtual medical examinations which addresses the foregoing issues.
SUMMARYEmbodiments of a method for permitting a real-time virtual medical examination using a patient device and at least one diagnostic device are disclosed herein. In one such embodiment, the method includes receiving, at the patient device, a signal transmitted from the at least one diagnostic device and generating diagnostic information based on the received signal. The method also includes encrypting the diagnostic information, establishing communication over a network between the patient device and a first remote server, establishing a video conferencing session via a second remote server and transmitting the encrypted diagnostic information to the first remote server.
Embodiments of an apparatus for receiving a real-time virtual medical examination using at least one diagnostic device are also disclosed herein. In one such embodiment, the apparatus includes a memory and at least one processor configured to execute instructions stored in the memory to receive a signal transmitted from the at least one diagnostic device and generate diagnostic information based on the received signal. The at least one processor is also configured to encrypt the diagnostic information, establish communication over a network between the patient device and a first remote server, establish a video conferencing session via a second remote server and transmit the encrypted diagnostic information to the first remote server.
Embodiments of a method for permitting a real-time virtual medical examination by a health care provider using health care provider device on a patient using a patient device are also disclosed herein. In one such embodiment, the method includes establishing communication over a network with the health care provider device and the patient device and receiving, from the patient device, encrypted diagnostic information related to the patient. The encrypted diagnostic information is generated from at least one diagnostic device. The method also includes transmitting the encrypted diagnostic information to the health care provider device.
Embodiments of a system for performing a real-time virtual medical examination are also disclosed herein. In one such embodiment, the systems includes a network permitting communication between a patient device and a physician device. The patient device is configured to generate encrypted diagnostic information based on a signal transmitted from at least one diagnostic device received signal. The system also includes a first server in communication with the network and configured to receive the encrypted diagnostic information from the patient device and transmit the encrypted diagnostic information to the physician device. Further, the system includes a second server configured to permit a video conferencing session between the patient device and the physician device.
Embodiments of a method for advertising medical information on a patient device are also disclosed herein. In one such embodiment, the method includes generating at least one advertisement related to a health-related product or service and enabling a user to purchase the health-related product or service via a patient device, the patient device operable to permit a real-time virtual medical examination.
These and other embodiments will be discussed in additional detail hereafter.
BRIEF DESCRIPTION OF THE DRAWINGSReferring now to the drawings, illustrative embodiments are shown in detail. Although the drawings represent some embodiments, the drawings are not necessarily to scale and certain features may be exaggerated, removed, or partially sectioned to better illustrate and explain the present invention. Further, the embodiments set forth herein are exemplary and are not intended to be exhaustive or otherwise limit or restrict the claims to the precise forms and configurations shown in the drawings and disclosed in the following detailed description.
FIG. 1 is a diagram of a system for performing virtual medical examinations in accordance with one embodiment;
FIG. 2 is a schematic diagram of a patient device or a physician device used in the system ofFIG. 1;
FIG. 3 is a schematic diagram of an exemplary diagnostic device for use in the system ofFIG. 1;
FIGS. 4A-4B are an exemplary graphical user interface screens on the patient device ofFIG. 2;
FIG. 5 is a flowchart diagram depicting an exemplary method of generating patient diagnostic information and securely transmitting and storing the data in a patient records server;
FIG. 6 is a flowchart diagram depicting an exemplary method of securely retrieving patient diagnostic information from a patient records server and displaying the retrieved data on a physician device; and
FIG. 7 is a flowchart depicting an exemplary method of performing a virtual medical examination.
DETAILED DESCRIPTIONDescribed herein are systems, methods and apparatuses for performing virtual medical examinations. The systems, methods and apparatuses generally involve the secure transmission of patient diagnostic information by a patient remotely located from a treating physician and the secure retrieval and viewing of the data by the physician. The systems, methods and apparatuses also generally involve secure videoconferencing to allow the physician to remotely conduct a medical examination in real-time, thereby allowing the physician to provide health instruction information by, for example directing the examination, providing therapeutic instructions and any other instructions to the patient.
Referring toFIG. 1, a virtualmedical examination system20 is depicted. The system can include one or morediagnostic devices32 that are configured to generate patient diagnostic information, aremote patient device36, a physician device orhealthcare provider device38, apatient records server40, avideoconferencing server42 and a remotecontent manager server44.Diagnostic devices32,remote patient device36,physician device38,patient records server40,videoconferencing server42 and remotecontent manager server44 can all be connected either directly or indirectly via anetwork50.
Remote patient device36,physician device38,patient records server40,videoconferencing server42 and remotecontent manager server44 may each be a computer having an internal configuration of hardware including a processor such as a central processing unit (CPU) and a memory. Accordingly,remote patient device36 can have aCPU36aand amemory36b,physician device38 can have aCPU38aand amemory38b,patient records server40 can have aCPU40aand amemory40b,videoconferencing server42 can have aCPU42aand amemory42band remotecontent manager server44 can have aCPU44aand amemory44b.CPUs36a,38a,40a,42aand44acan be a controller for controlling the operations ofpatient device36,physician device38,patient records server40,videoconferencing server42 and remotecontent manager server44, respectively.CPUs36a,38a,40a,42aand44acan each be connected tomemories36b,38b,40b,42band44b, respectively, by, for example, a memory bus.Memories36b,38b,40b,42band44bcan store data and program instructions which are used byCPUs36a,38a,40a,42aand44a, respectively. Other suitable implementations ofpatient device36,physician device38,patient records server40,videoconferencing server42 and remotecontent manager server44 are possible. For example, in one embodiment,patient records server40,videoconferencing server42 and remotecontent manager server44 can be integrated into one server.
Exemplarydiagnostic devices32 include electrocardiographs (ECG), pulse oximeters, spirometers, sphygmomanometers, weight scales, stethoscopes, blood chemistry analyzers, microscopes, ultrasounds probes, etc. Thediagnostic devices32 can include a patient diagnostic information wireless transmitter for transmitting patient diagnostic information to aremote patient device36. Communications betweendiagnostic devices32 andpatient device36 can be wired or wireless.
Wireless communications betweendiagnostic devices32 andpatient device36 may be provided using various protocols and other wireless technologies, including 3G and 4G wireless technologies and the IEEE series of wireless technologies. More particularly, wireless communications may take place over a CDMA, EDGE, EV-DO, GPRS, GSM, UMTS, W-CDMA, or a 1xRTT network as well as an IEEE 802.11 (WiFi), 802.15 (Bluetooth and Zigbee), 802.16 (WiMax) or 802.20 (MBWA) network. In the example shown inFIG. 1, wireless communicationsdiagnostic devices32 andpatient devices36 will take place using Bluetooth technology, but the embodiments disclosed herein are not to be limited to Bluetooth.
Bluetooth communications have certain features that can be beneficial in many implementations ofsystem20, including a lack of wires, security features such as secure simple device pairing and adaptive frequency hopping, and an effective device to device transmission range of up to about300 feet. Using the Bluetooth protocol, suitablediagnostic devices32 can be identified and paired with the remotepatient work stations36. Suitable Bluetooth-enableddiagnostic devices32 can be supplied by QRS Diagnostics of Plymouth, Minn.
In other embodiments, rather than communications betweendiagnostic devices32 andpatient device36 occurring directly, communications may occur directly via, for example, a local wireless signal gateway (not shown). The wireless signal gateway can be connected to network50 and is generally in close proximity todiagnostic devices32 at the time of their transmission of diagnostic information. In one embodiment, the wireless signal gateway is a Bluetooth-enabled wireless signal gateway that may operate external to thepatient device36 hardware as a separate entity or can be integrated intopatient devices36 to allow for long-range transmission of patient diagnostic information to an internet server (not separately shown inFIG. 1), and ultimately, topatient records server40. One suitable Bluetooth internet gateway that may be used is the Gigaset-One Bluetooth Gateway supplied by Siemens.
When communication betweendiagnostic device32 andpatient device36 is via a wireless protocol,diagnostic device32 andpatient device32 can be within a suitable distance from one another to permit communication. For example, in one embodiment,diagnostic device32 andpatient device32 are no more than 90 feet one another although other suitable distances are possible. Becausediagnostic devices32 have a relatively limited transmission radius, the transmission of patient diagnostic information fromdiagnostic devices32 topatient devices36 need not be encrypted. However, patient diagnostic information transmitted fromdiagnostic devices32 topatient records server40 can be encrypted to prevent undesired access by other users ofnetwork50. One encryption method includes https (hypertext transfer protocol secure). However, other encryption methods may be used. In one embodiment, wireless signals can secured via unique user identifiers for patient diagnosticperipheral devices32.
In one implementation, thediagnostic devices32 andpatient devices36 utilize the Bluetooth Health Device Profile for transmitting medical data. The Bluetooth Health Device Profile has been standardized by Bluetooth SIG, the industrial association for Bluetooth manufacturers. The Health Device Profile enables a range of additional functions such as exact chronological synchronization of several Bluetooth connected medical sensors or the option of transferring different medical data in parallel via a Bluetooth interface which is necessary when several diagnostic devices generate patient diagnostic information simultaneously. The Health Device Profile consists of one part that specifies transfer protocols used for medical data in the Bluetooth stack and another part that describes the structure of the actual medical data.
Patient records server40 is connected to network50 and can include a number of patient data files stored in a computerized database. The files may be organized by a variety of methods. However, in one implementation, each patient's files are associated with patient identification data, which can be a unique identifier, such as a numeric or alphanumeric identifier. The patient identifier allows a physician or any other health care provider (e.g. nurse, health care administrator, pharmacist surgeon etc.) to retrieve specific data for a desired patient. Patient diagnostic information transmitted fromdiagnostic devices32 can be transmitted in association with a patient identifier so that patient diagnostic information received bypatient records server40 is associated with the specific patient for whom the diagnostic data was generated.
Network50 may take a variety of forms such as a local area network, wide area network, or the Internet. Whennetwork50 is, for example, the Internet medical examinations can be conducted between physicians and patients who are geographically situated at long distances from one another. In the case wherenetwork50 is the internet,patient records server40 is referred to as a patient records internet server. In such cases, patientrecords internet server40 can be assigned a unique internet protocol address to which wireless signal transmissions frompatient device36 are directed when patient diagnostic information is generated bydiagnostic devices32.
Additionally, other networks can be interfaced with or completely replacenetwork50. For example, whenphysician device38 is a handheld device such as a mobile phone, PDA, smart phone or any other suitable handheld device,network50 can be a mobile communications network and can include one or more base stations (e.g. macrocell, femtocell, microcell, picocell, etc.).Physician device38 can send communications to network50 via the mobile communications network or other transmitting/receiving tower. For example, radio waves can be used to transfer signals betweenphysician device38 through one or more base stations in the mobile communications network, which can them transmit the communications to network50.Physician device38 may also communicate in any other suitable manner For example, in one embodiment, physician device may communicate via satellite. Further, for example,physician device38 can connect directly to network50 (e.g. via 3 g or 4 g services).
Whenphysician device38 is a handheld device, it can include a subscriber identity module (SIM) card, which can be equipped with encryption/decryption programming. This encryption/decryption programming can be used to authenticate the handheld device and can be in addition to the encryption and decryption of diagnostic information and health instruction information as will be discussed in more detail below. In some embodiments, the SIM card can be used to perform the encryption/decryption of the diagnostic information and health instruction information.
The SIM card can be in a form that is removable by the user, which can make it possible to carry mobile subscription information and data through different types and generations of handheld devices. Alternatively, the SIM card can be integrated into the handheld device. The SIM card can, for example, contain a microchip that houses a processor (e.g. microprocessor) and a memory. The memory can have instructions stored thereon, that when executed by the processor encrypt voice and data transmissions, which can assist in preventing third parties from intercepting transmissions. The SIM, as discussed previously, can identify the user to the mobile communications network as a legitimate user. Each SIM card can be equipped with an additional memory such as EEPROM (Electrically Erasable Programmable Read-Only Memory), which can contain additional information about the device. For example, EEPROM can store an IMSI (International Mobile Subscriber Identification), a PIN (Personal Identification Number), an international access entitlement, a priority class, and subscriber information.
As indicated inFIG. 1, virtualmedical examination system20 includes aphysician device38, which can be a hand-held computing device with a visual display.Device38 can be programmed to allow the physician to access, retrieve, decrypt, and view patient diagnostic information frompatient records server40.Device38 can be connected tonetwork50. In one embodiment,physician device38 is wirelessly connected to the internet and configured to generate the IP address ofpatient record server40 for the retrieval of patient diagnostic information.Physician device38 can also be programmed to decrypt patient diagnostic information received frompatient records server40 vianetwork50 so the data can be displayed onphysician device38. Thus, the networking ofphysician device38 withpatient records server40 anddiagnostic devices32 allows for the secure transmission of patient diagnostic information topatient record server40 and the secure retrieval of patient diagnostic information frompatient record server40 by a physician.Patient record server40 may be programmed to require one or more passwords or other sign-in credentials to verify the identity of the physician and ensure that access to patient diagnostic information is appropriately limited to authorized individuals. The transmission of patient diagnostic information topatient records server40 and the subsequent retrieval of the data frompatient records server40 by a physician can occur in real-time.
Virtualmedical examination system20 can also be configured to allow a patient and physician to conduct video conference calls. In one implementation,system20 is configured to allow a patient and physician to conduct secure, encrypted video conference calls that cannot be monitored or accessed by unauthorized third parties. In one example, the encryption provides for HIPAA compliant transmission of patient information. In another implementation, multiple authorized parties may participate in the video conference calls, thereby allowing multiple physicians (who may be remote from one another and from the patient) to collaborate and/or jointly conduct an examination of the patient.
In the illustrative example ofFIG. 1, avideoconferencing server42 is provided which allows a patient and physician to conduct a secure encrypted video conference call overnetwork50. A “secure” videoconference server includes features that prevent or minimize the likelihood that third parties will be able to intercept information transmitted from one party to another during the videoconference. Such interception is sometimes referred to as a “man in the middle attack” or “packet sniffing.” In some embodiments,network50 is the Internet, in which case thevideoconferencing server42 may be referred to as a videoconferencing internet server. In one embodiment, the patient speaks into a microphone (which may be provided on device36), and stands in the field of view of a camera (which may also be provided on device36) to generate voice and video data. The voice and video data is encrypted, for example by using https, and transmitted tovideo conferencing server42 vianetwork50. Https can create a secure channel over an unsecure network, such as the internet. The trust inherent in HTTPS is based on major certificate authorities which come pre-installed in browser software, which allows users to confirm the security of the connection if (1) the user trusts that their browser software correctly implements HTTPS with correctly pre-installed certificate authorities; (2) the user trusts the certificate authority to vouch only for legitimate websites without misleading names; (3) the website provides a valid certificate (an invalid certificate shows a warning in most browsers), which means it was signed by a trusted authority; (4) the certificate correctly identifies the website; and (5) either the intervening hops on the Internet are trustworthy, or the user trusts that the protocol's encryption layer (TLS or SSL) is unbreakable by an eavesdropper.
A physician can usedevice38 to receive voice and video data from the patient. The voice and video data is transmitted in encrypted form, fromvideoconferencing server42 todevice38.Device38 includes a display screen for viewing video images of the patient and a speaker for listening to voice communications from the patient. The physician speaks into a microphone (which may be provided on device38) and stands in the field of view of a camera (which may also be provided on device38) to generate voice and video data. The voice and video data are encrypted bydevice38 and transmitted tovideo conferencing server42 vianetwork50. The encrypted voice and video data is then received and decrypted bypatient device36 vianetwork50.Patient device36 can include a visual display for viewing images of the physician and a speaker for listening to voice communications from the physician.
Videoconferencing server42 can be a computer server that is connected to network50.Video conferencing server42 can be a video conferencing internet server, as in the case wherenetwork50 is the internet. Suitable servers are supplied by Visual Systems Group, Inc., Radvision Ltd., and Tandberg. In one embodiment, a video conference call between a patient and physician is conducted using a single, secured TCPIIP connection. In another embodiment,videoconferencing server42 is configured to allow multiple parties to participate in a secure virtual medical examination. This option is particularly useful for situations in which a primary physician and a secondary physician (e.g., a consultant or specialist) are geographically remote from one another and from the patient. In one example, a virtual conference room is provided which allows for a multi-participant secure meeting. In this manner, virtualmedical examination system20 allows for multi-physician medical examinations and real-time consultations which previously may have been cost prohibitive or otherwise infeasible.
In certain implementations,video conferencing server42 is configured as a plurality of geographically distributed video conferencing servers that are interconnected via the internet. The use of distributed video conferencing servers allows for load balancing of the various servers to maintain optimum performance.Video conferencing server42 can be configured to require users to provide passwords or other evidence of their authorization to participate in a video conference to better ensure that the confidentiality of patient information is not compromised. In one embodiment,videoconferencing server42 is a session-initiation protocol (“SIP”) server. Other protocols for establishing video conferencing are also available. For example, video conferencing can be established using IP Multimedia Subsystem (IMS), Media Gateway Control Protocol, Real-Time Transport Protocol (RTP) or any other suitable protocol.
In one embodiment,patient device36 andphysician device38 receive their content from a remotecontent manager server44 connected to network50. In one embodiment, whendevices36 and38 are activated, they retrieve programs that launch graphical user interfaces fromcontent manager server44 vianetwork50. This allows for the centralized updating of the software and interfaces used by thedevices36 and38 and avoids the necessity of individually revising the software used indevices36 and38. In one embodiment,network50 is the Internet, in which casecontent manager server44 may be referred to as a content manager internet server. In other embodiments,content manager server44supplies devices36 and38 with one or more programs that provide a common platform to facilitate that receipt, transmission, and display of patient data and patient/physician voice and video data.Patient device36 andphysician device38 may take a variety of forms, such as a standard personal computer, tablet computer, smartphone, etc. In one embodiment,patient device36 andphysician device38 include a visual display, a camera, and a speaker and patient navigation via screen-displayed icons.
In one embodiment,devices36 and38 are handheld computing devices such mobile phones, PDAs, smartphones, tablets, notebooks, computers, netbooks or any other suitable communication device. One suitable type ofpatient device36 orphysician device38 is, for example, 10.4″ Intel® Atom™ N450 Portable Medical PC. Other suitable devices of varying size and architecture are available. For example, a 17″ Portable Medical PC can be used in lieu of the 10.4″ Portable Medical PC. Another type of suitable device includes a TFT (thin film transistor) LCD resistive touch screen display and an integrated Bluetooth-enabled wireless transmitter. Anothersuitable patient device36 orphysician device38 includes an integrated Bluetooth module, a 2.0 Megapixel CMOS camera, and a 12 Active Matrix Panel resistive touch screen visual display. It also includes a bar code scanner that facilitates the reading of patient identification information from bar codes.
Referring toFIG. 2, anexemplary patient device36 is shown, which also may also be used as aphysician device38.Patient device36 includes avisual display52 which can include a touch screen. Plastic side grips54 are provided to facilitate hand gripping ofdevice36.Visual display52 may include a screen with one ormore icons58 that allow the user to initiate various operations. For example,icons58 can include a collect patientdiagnostic information icon58a,an initiation of avideo conference call58b,a return tohome icon58c, ahelp icon58d, aninternet icon58e(i.e. to access the Internet), a shopping cart icon58f(i.e. to purchase items and/or services) and a healthrecord information icon58gto view current and historical patient diagnostic information. Other icons are also possible.Speaker56 is provided to receive voice communications from a physician, andbuttons60 are provided to allow the user to initiate operations (in addition to or instead of graphical icons58).
During certain examinations, it may be desirable to transmit images of a patient's body to the treating physician. In certain cases, a camera mounted on or integrally provided withdevice36 may be sufficient to generate the necessary images. In other cases, however, it may be desirable to obtain and transmit magnified images to the physician. Thus, in certain embodiments,diagnostic devices32 include adigital microscope62, as shown inFIG. 3.Digital microscope62 can include alens section64 and ahandle66.Digital microscope62 can also include a wireless transmitter, which is Bluetooth-enabled. Thus, in certain embodiments, digital microscope images generated bydigital microscope62 can be received and encrypted bydevice36 and transmitted tovideoconferencing server42. The images can be then received fromvideoconferencing server42 and decrypted byphysician device36 for display thereon. A separate recording server may also be provided to record the digital microscope images (or any other transmission from the video conference call) for subsequent storage inpatient records server40. Alternatively, the digital microscope images can be stored directly inpatient records server40. In accordance with one example, the specific patient-physician video and voice communications from a video conference may be stored with the patient's medical records inpatient records server40 for subsequent retrieval and review, thereby providing an accurate history of patient-physician communications.
As mentioned previously,patient device36 andphysician device38 can include a graphical user interface (GUI) supplied by, for example,content manager server44 which facilitates the initiation of desired functions. Referring toFIGS. 4A-D, exemplary GUI screen frompatient device36 and/orphysician device38 are shown.
FIG. 4A is ascreen68aonpatient device36 presented to a patient who has selected the collect patientdiagnostic information icon58a. When collect patientdiagnostic information icon58ais selected, the patient is presented with one or more selectable touch screen buttons so thatpatient device36 can identify that a diagnostic procedure will be performed by the patient usingdiagnostic device32. In this example, the patient is presented with the option to take their blood pressure by selectingbutton70a, take their blood glucose by selectingbutton70b, their ECG by selectingbutton70c, their weight by selectingbutton70d, their pulse/oxy by selectingbutton70eor their spirometer reading by selectingbutton70f. Each button can receive patient diagnostic information specific to the diagnostic procedure being performed. In some instances, alterative or more or less diagnostic procedures can be displayed to the patient onscreen68a.
FIG. 4B is ascreen68bonpatient device36 presented to a patient who has selected the healthrecord information icon58g. When the healthrecord information icon58gis selected the patient is able to view current or historical data related to the diagnostic procedures that have been performed usingdiagnostic devices32. For example,screen68bincludespatient data78 such as name, birthday, height, weight, etc., height, weight.Screen68balso includes trend data for the patient showing developments for, for example, height, weight andbmi trend data80 or bloodpressure trend data82. Patient can also viewalerts84 related to his/her health. For example, if the patient has abnormally high blood pressure, the alert can indicate that the patient should immediately contact a hospital. Other configurations ofscreen68bare also possible.
FIG. 4C is ascreen68conpatient device36 presented to a patient who has selected the initiation of avideo conference call58b. In this is a graphical user interface screen that allows the user to place a video conference call with a specific doctor conference rooms by selecting one oftouch screen buttons90 or to enter one or more general conference rooms by selecting one oftouch screen buttons92. A similar screen can also be presented onphysician device36. Accordingly, the patient and/or doctor(s) can conduct a video conference if both have entered the same conference room. Communications via the patient and doctor (or between doctors), as discussed previously, is encrypted and secure.
Alternatively to having conference rooms, or in addition, screen68 can include a key pad section, an icon section, and a speed dial section. The key pad section includes phone button images that can allow the patient to key in the telephone number of the doctor participating in the video conference call. The speed dial section can allow the user to pre-program the phone numbers of selected doctors and to associate a designated “button” with each doctor to provide one-touch dialing. The icon section can include various icons that allow a user to initiate desired operations such as calling 911, accessing a phone directory, initiating video for a video call, taking diagnostic data with adiagnostic device32, accessing a medical supplies web site to purchase supplies, and accessing health care information.
Once a video conference room has been selected, the patient (or doctor) can be presented with ascreen68dillustrated inFIG. 4D showing a patient and/or physician device conducting a video conference. In accordance with the example, screen69 includes anicon section102, and a plurality of video display sections, such as firstvideo display section104 and a secondvideo display section106.Video display sections104 and106 can display video images of different video conference participants. For example, forpatient device36,video display section104 may display the primary treating physician, andvideo display section106 may display a consulting physician or specialist. In addition,video display section104 may be used to provide the patient with a video image of himself as generated by a camera ondevice36. For aphysician device38,video display section104 may be used to display the image of the patient generated by a camera located onpatient device36 whilevideo display section106 may be used to display the image of the patient generated bydigital microscope62. In one embodiment, a GUI screen is provided which allows the physician and/or patient to view video images and patient diagnostic information simultaneously.
Device36 can also have screens displaying tutorials or advertisements related todiagnostic devices32. For example, in one embodiment, the GUI ondevice36 can display tutorial information for aid in using the diagnostic device so that the patient is able to properly transmit the information tosystem20. They tutorial may be interactive or non-interactive. In an interactive tutorial, the tutorial may prompt the user to indicate when they have performed a certain action. The following are exemplary prompts for blood pressure tutorial using a sphygmomanometer device and the prompts that the patient will encounter.
1. Put on cuff, left arm, with pressurizing hose at crook of elbow.
2. Press Power button on 2-in-1; cuff will inflate and slowly deflate.
3. When blood pressure reading shows on screen, press “Blood Pressure” icon.
4. Data will transfer and blood pressure device powers off, and “Successful” message appears on your patient device.
The patient can verify once they have performed a one of the actions. Other tutorials are possible.
Device36 can also be used to generate advertisements to the patient. For example, if it is determined that the patient's blood glucose level is too high, an advertisement for a blood glucose medication can be generated for display on the device's GUI. They advertisements may be run whendevice36 is powered on, periodically whendevice36 is running, prior todevice36 shutting down or at any other suitable time. They devices may or may not be tailored specific to the patient. The advertisements may change over time by, for example, an update from thecontent manager server42. Alternatively, the advertisements can be pre-programmed intodevice36 when, for example, the patient receivesdevice36.
Referring toFIG. 5, a method of using virtualmedical examination system20 to generate and securely transmit patient diagnostic information topatient records server40 will now be described. In accordance with the method, a patient selects one or morediagnostic devices32 of the type described previously. Instep1002, the patient uses thediagnostic device32 to generate diagnostic data (e.g., blood pressure, blood chemistry, pulse oximetry, weight, spirometry, etc.).Diagnostic device32 transmits (wirelessly or via a wired connection) patient diagnostic information topatient device36.
Instep1004,patient device36 encrypts patient diagnostic information and information identifying the patient (hereinafter patient identification data) using an encryption protocol such as https.Patient device36 then transmits the encrypted data topatient record server44 vianetwork50, which can be the internet or any other communication network.Patient record server40 can have a unique network address (e.g., IP address), that allows thepatient device36 to uniquely identify it as the intended recipient of the encrypted patient diagnostic information and patient identification data. Thepatient record server40 stores the patient diagnostic information in association with the patient identification data so that the data is accurately identified with the correct patient when retrieved by a health care provider. When the connection betweenpatient device36 anddiagnostic device32 is wireless, patient can beneficially perform diagnostic tests without having to make a wired connection to thediagnostic device32 and a computer or other transmitting device. Instead, the patient need only activate thediagnostic device32 and locate it within the zone of transmission of thepatient device32.
In certain examples,diagnostic devices32 are pre-configured to generate wireless signals comprising patient identification data that corresponds to a specific patient to whichdiagnostic devices32 have been uniquely assigned. For example, each patient may be assigned a unique numeric or alphanumeric code, which corresponds to a particular wireless signal generated bydiagnostic devices32. In one example, the patient files resident inpatient record server40 are setup via the web. When subsequent diagnostics are taken they are applied to the file by opening the utility ready for the diagnostic information to be captured.
Referring toFIG. 6, a method of securely retrieving patient diagnostic information frompatient record server40 is described. In accordance with the method, a physician can enter patient identification information intophysician device38 such as by using touch screen52) atstep1012. Next, atstep1012,physician device38 can transmit (via a wired or wireless connection) the patient identification information topatient record server40 vianetwork50.Patient record server40 can cause a graphical user interface to be displayed onphysician device38 which requests certain physician credential information (e.g., a log-in name and a password).Patient record server40 may be physically resident at a facility such a hospital or clinic with which the physician is associated, although the physician may be remotely located fromserver40 when accessing it. Alternatively, the physician may sign intopatient record server40 before transmitting patient identification data to it.
Once the physician's authorization to review data for a specific patient is confirmed, the data is transmitted in encrypted form tophysician device38. Atstep1016,physician device38 can include executable code (which may be provided by content manager server44) to allow for the decrypting of encrypted patient diagnostic information. The patient diagnostic information can then be display onphysician device38 to be viewed by the physician atstep1018.
Referring toFIG. 7, an exemplary method of performing a virtual medical examination of a remotely located patient is described. Instep1022, the patient initiates a video conference call usingpatient device36 as described previously. A conference call is then initiated withvideoconferencing server42.Videoconferencing server42 transmits data tophysician device38 indicating that a call has been initiated. The patient may then use an icon inicon section58 to activate a camera onpatient device36 and begin the transmission of encrypted patient video data tovideoconferencing server42.
Instep1024, the physician answers the patient's call by pressing appropriate virtual or physical keys onphysician device38. In certain examples, the patient receives video images from a camera on thephysician device38 in video display section76 and sees the video data generated by a camera onpatient device36 in video display section77. Correspondingly, the physician may see video images generated by the camera onpatient device36 in video display section76 ofphysician device38 and video images of herself in video display section77.
In certain examples, the patient may be at his or her home during the virtual medical examination. In other examples, the patient may be alone during the examination. In additional examples, the patient may be with another individual who can assist in the performance of the examination. In one scenario, the patient is in a clinic or hospital and is assisted by a local health care assistant (e.g., nurse or doctor) in providing the remote physician with the diagnostic data necessary to develop a treatment plan. After taking a verbal medical history from the patient and inquiring about any medical issues that may have prompted the request for an examination, the physician can, for example, provide health instruction information to the patient or local health care assistant. For example, the physician can direct the patient and/or a local health care assistant to perform diagnostic tests on the patient using selected diagnostic devices32 (step1026). For example, the physician may direct a local health care assistant to take blood pressure readings or measure the patient's weight. The patient and/or local health care assistant can then use one or more diagnostic devices to generate the patient diagnostic information atstep1028.
As used herein, health instruction information includes any information received from the physician or other health care provider. Health instruction information can be generated fromphysician device38 and transmitted topatient device36 in real-time so that the patient or other health care provider can, administer medication, perform a diagnostic procedure, taking vital signs, manipulate a digital microscope (e.g.digital microscope62 to a certain region of the patient's body or any other action. In some instances, health instruction information may not necessitate any immediate action by the patient. For example, the physician may indicate through health instruction information that the patient should take their temperature in one hour. However, the health instruction information is transmitted and received by the patient in real-time.
Health instruction information can be in the form of voice, text or image data or any other suitable type of data. For example, when voice data is the form in which health instruction information is formulated, the voice data can be transmitted tovideo conferencing server42. Voice data can be oral instructions to the patient. When text or image data is the form in which health instruction information, the text or image data can be transmitted to thepatient records server40. For example, the physician can send a message to a patient to “take blood pressure” rather than communicating the instruction orally. Other suitable techniques for transmitting health instruction information are possible. For example, image data can be sent tovideo conferencing server42 rather thanpatient records server40.
As discussed previously, transmitters in thediagnostic devices32 can wirelessly transmit patient diagnostic information generated bydiagnostic devices32 topatient device36 in association with patient identification information, for example, a unique alphanumeric code assigned to the patient (step1030). The wireless transmission of diagnostic data topatient device36 can be performed using the Bluetooth protocol. Thepatient device36 can encrypt the received patient diagnostic information and patient identification data, using an https protocol or any other secure protocol. Thus encrypted, the patient identification data and patient diagnostic information can be transmitted to the patient record server40 (step1032). Usingphysician device38, the physician can accesspatient record server40 upon login using permissions-assigned passwords for safety and confidentiality and can retrieve and decrypt the patient diagnostic information which is then displayed on physician device38 (step1034). In certain examples, the patient diagnostic information is also transmitted to thepatient device36, where it is decrypted and displayed to the patient. The concurrent transmission of patient diagnostic information frompatient device36 tophysician device38 while thepatient device36 andphysician device38 exchange information to conduct a secure video conference session are in real-time.
In certain situations, the physician may wish to obtain microscope images of certain areas of the patient's body. In such situations, the physician may direct the patient and/or a local health care assistant (such as an emergency room doctor, a nurse, or a physician's assistant) to manipulate digital microscope62 (or other diagnostic device32) to selected regions of the patient's body to obtain the desired microscope images (step1036).Digital microscope62 can transmit video data of the images topatient device36 which then encrypts and transmits the video data tovideo conference server42 for subsequent retrieval by the physician and viewing on thephysician device38. At the outset of the call or during the call, the treating physician may ask another health care provider, such as a specialist, to join the video conference. The specialist can access the videoconference server (such as by inputting an IP address or domain name for the videoconference server into his or her computer terminal). After supplying the appropriate authorization credentials (such as a log in and password), the specialist will be connected to the call.
Instep1038, the physician (alone or in conjunction with a consultant or specialist) communicates therapeutic directions to the patient usingphysician device38. Alternatively, the physician may consider the information provided during the video conference and may conduct a subsequent video conference to provide therapeutic directions. In another scenario, the physician may conduct a secure video conference with another physician and both physicians may view patient diagnostic information from thepatient records server40 to collaborate and develop a joint treatment plan. The method ofFIG. 8 may be used for the diagnosis and treatment of recurring or non-recurring conditions, and it may also be used to perform periodic monitoring of patients with chronic conditions, such as diabetes. The method ofFIG. 7 is not limited to the treatment of any one particular condition, and exemplary conditions include diabetes, asthma, hypertension, chronic obstructive pulmonary disease, and heart failure or any other condition
Exemplary Application
The following is an exemplary application for transmitting patient diagnostic information to a remotely located physician who is using a handheld device such as a mobile phone (e.g. physician device38). A diagnostic device (e.g., diagnostic device32), which is Bluetooth-enabled, can wirelessly transmit patient diagnostic information to a patient device (e.g., patient device36), which is also Bluetooth enabled. The patient device can encrypt and transmit the patient diagnostic information to a patient information sever such as a patient recordsserver40. The patient information server records the received patient diagnostic information in a patient file and then re-transmits the data to the patient device and a physician device. Access to the patient diagnostic information can be controlled via a set of administrator permissions and all patient data can be shelled within a secure HIPAA compliant environment to ensure confidentiality of data via, for example, encrypted HTTPS communication.
A secure videoconference can be conducted between one or more physicians and a patient in a virtual conference room so that the patient and the physician can access the diagnostic information in real-time during the videoconferencing session. After reviewing patient diagnostic information, a physician, via his physician device, can initiate a videoconference with the patient and/or one or more additional physicians (or other healthcare providers). Each physician can access have access to the diagnostic information and be part of the videoconferencing session via their handheld device. As such, each physician can receive the diagnostic information real-time regardless of their location and review the diagnostic information to provide health instruction information. For example, a physician joining the video conference such as a specialist may request that that a certain diagnostic procedure be performed on the patient that was not requested by the physician who was initially part of the video conference. A recording server (e.g. patient records server40) can record all voice and video data from the conference. The virtual conference rooms can be provided by a videoconferencing server (e.g., video conferencing server42) that can provide, for example, secure https encryption of all voice and video data.
Alternatively, as discussed previously, the
The embodiments of remotepatient device36,physician device38,patient records server40,videoconferencing server42 and/or remote content manager server44 (and the algorithms, methods, instructions etc. stored thereon and/or executed thereby) can be implemented in hardware, software, or any combination thereof including, for example, IP cores, ASICS, programmable logic arrays, quantum or molecular processors, optical processors, programmable logic controllers, microcode, firmware, microcontrollers, servers, microprocessors, digital signal processors or any other suitable circuit. In the claims, the term “processor” should be understood as encompassing any the foregoing devices, either singly or in combination. The terms “signal” and “data” are used interchangeably. Further, portions of remotepatient device36,physician device38,patient records server40,videoconferencing server42 and/or remotecontent manager server44 do not necessarily have to be implemented in the same manner.
Further, in one embodiment, for example,remote patient device36,physician device38,patient records server40,videoconferencing server42 or remotecontent manager server44 can be implemented using a general purpose computer/processor with a computer program that, when executed, carries out any of the respective methods, algorithms and/or instructions described herein. In addition or alternatively, for example, a special purpose computer/processor can be utilized which can contain specialized hardware for carrying out any of the methods, algorithms, or instructions described herein.
Further, all or a portion of embodiments of the present invention can take the form of a computer program product accessible from, for example, a computer-usable or computer-readable medium. A computer-usable or computer-readable medium can be any device that can, for example, tangibly contain, store, communicate, or transport the program for use by or in connection with any processor. The medium can be, for example, an electronic, magnetic, optical, electromagnetic, or a semiconductor device. Other suitable mediums are also available.
The above-described embodiments have been described in order to allow easy understanding of the present invention and do not limit the present invention. On the contrary, the invention is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims, which scope is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structure as is permitted under the law.