US20120116800A1 - Clinical collaboration using an online networking system - Google Patents

Abstract

Methods are provided for sharing patient information by way of an online collaboration system. A requesting clinician, through an online networking system, identifies one or more clinicians with whom the requesting clinician wishes to collaborate by sending at least one patient-focused clinical data element. For the clinicians who have been identified as not being authorized to access patient-identifying data, the at least one patient-focused clinical data element is de-identified such that it no longer includes any patient-identifying data. The de-identified patient-focused clinical data element is then communicated to the clinicians not allowed access to the patient-identifying information.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application is a continuation-in-part of U.S. application Ser. No. 13/072,248, filed Mar. 25, 2011, which is a divisional of U.S. application Ser. No. 11/023,057, filed Dec. 27, 2004, both of which are herein incorporated by reference in their entirety.
STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
• Not Applicable.
BACKGROUND
• Modern health care delivery for a given patient involves an increasingly complex network of clinicians. These clinicians may include healthcare professionals, such as doctors, nurses, physical therapists, and others, as well as related staff members. Clinicians frequently generate a large amount of patient-related data, at least some of which are stored in the associated patient's electronic medical record (EMR) stored within a computerized clinical information system. These data may include (i) observations made by the clinicians and memorialized in the record, (ii) results of various tests the patient has undergone, or (iii) various documents (e.g., in the form of attached files) containing information related to the patient, as examples.
• A clinician treating a given patient may want to know more about data within the patient's EMR or other record related to the patient. For instance, a primary care physician treating a patient for a particular ailment may want to ask a radiologist about a diagnosis made based on the results of an x-ray or MRI image for the patient. One way to accomplish this is to track down the author of the data, or a clinician of a certain level of expertise that could help in explaining and/or interpreting the data. These individuals, however, are often scattered throughout a health system or institution. In fact, “face-to-face” contact between and among treating clinicians is decreasing because electronic patient records may be stored on networked information systems (e.g., LANs, WANs) and accessed remotely by authorized users. There is not a strong necessity for clinicians to be physically located within the same building or even geographic area. Even if data authors are found, they may be occupied with other tasks that prevent them from having a discussion with the requesting clinician. Clinicians that have a certain specific medical expertise, or association with the data author, are likewise difficult to locate, and identifying their degree of relevance to the medical issue or data at hand may be impossible based only on the patient's record.
• Clinicians are, therefore, desiring to more quickly and effectively locate and engage in collaboration with other individuals to aid in delivering health care services to a given patient. It is advantageous for clinicians requesting collaboration sessions to, at times, have additional contextual information regarding the patient or relevant data within a record. There is also a desire for collaboration to take place dynamically and with the exchange of data that may be embodied in various electronic forms, such as text, voice and graphical.
BRIEF SUMMARY
• The present invention generally provides a system and associated methods that enable online collaboration among clinicians. Specifically, an online networking system is utilized that is accessible to both the requesting clinician and one or more clinicians identified by the requesting clinicians with whom the requesting clinician wishes to collaborate about a particular patient. For instance, the requesting clinician may wish to collaborate with a specialist, or to get a second opinion. Alternatively, the requesting clinician may not have the time to manage a particular patient's care, or for teaching purposes, may want another clinician in the office, such as an intern or resident physician, to make an attempt at diagnosing and treating a patient under the care of the requesting clinician. There are many scenarios not described herein, but that are contemplated to be within the scope of the present invention. Generally, embodiments of the present invention may be used with any scenario where a requesting clinician wishes to collaborate with one or more other clinicians by way of an online networking system.
• In one embodiment, the requesting clinician communicates a request and at least one patient-focused clinical data element from the patient's EMR to the online networking system, along with an identification of one or more clinicians with whom the requesting clinician wishes to collaborate. This patient information, for instance, may be posted on a website associated with an online networking system for medical clinicians. The identified clinician(s), thus may access this information if he or she is a registered user of the online networking system. In one instant, the identified clinician(s) may receive an alert (e.g., e-mail, text message, telephone call) indicating that he or she has been sent a message requesting a consultation, second opinion, etc. This clinician may review the information when he or she has time, and respond if desired and if requested to respond. In some instance, a response may not be necessary, such as in the instance of a resident physician being requested by an attending physician to review documents and a treatment plan for a particular patient. The resident physician may not need to respond to the request, but may simply review the patient information and treat the patient accordingly.
• One aspect of the present invention is directed to a method in a computer system having a processor and a memory for providing an online medical collaboration. The method includes receiving from a requesting clinician through an online networking system for medical clinicians an identification of one or more clinicians to whom at least one patient-focused clinical data element is to be communicated and identifying a first subset of the one or more clinicians to whom the requesting clinician is not authorized to send the at least one patient-focused clinical data element that includes patient-identifying data. Further, the method includes de-identifying the at least one patient-focused clinical data element such that it does not include any of the patient-identifying data and communicating the at least one de-identified patient-focused clinical data element to the first subset of the one or more clinicians.
• Another aspect of the present invention is directed to one or more computer storage media having computer-executable instructions embodied thereon that, when executed, enable a computing device to perform a method of providing an online medical collaboration. The method includes receiving a request from a requesting clinician to share a message and at least one patient-focused clinical data element with one or more clinicians by way of an online networking system for medical clinicians. Further, the method includes determining if at least one of the one or more clinicians is not allowed access to the at least one patient-focused clinical data element having patient-identifying data. If the at least one of the one or more clinicians is not allowed access to the at least one patient-focused clinical data element having patient-identifying data, the method includes de-identifying the at least one patient-focused clinical data element having patient-identifying data, sharing the at least one de-identified patient-focused clinical data element with the at least one of the one or more clinicians, and sharing the at least one patient-focused clinical data element that has not been de-identified with the one or more clinicians who are allowed access to the at least one patient-focused clinical data element having patient-identifying data. If, however, the at least one of the one or more clinicians is allowed access to the at least one patient-focused clinical data element having patient-identifying data, the method includes sharing the at least one patient-focused clinical data element having patient-identifying data with the one or more clinicians.
• Another aspect of the present invention is directed to one or more computer storage media having computer-executable instructions embodied thereon that, when executed, enable a computing device to perform a method of providing an online medical collaboration. The method includes receiving, from a requesting clinician through an online networking system for medical clinicians, a request that includes an identification of at least one clinician to collaborate in medical care of a particular patient. The at least one clinician is associated with the medical care of the patient such that the at least one clinician is allowed to access patient-identifying data for the patient. Further, the method includes receiving at least one patient-focused clinical data element associated with the patient. The at least one patient-focused clinical data element is found in an electronic medical record associated with the patient and the at least one patient-focused clinical data element includes the patient-identifying data. The method additionally includes communicating the request and the at least one patient-focused clinical data element to the at least one clinician.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
• In the accompanying drawings which form a part of the specification and are to be read in conjunction therewith and in which like reference numerals are used to indicate like elements in the various views:
• FIG. 1 is a block diagram of a computing system suitable for use in implementing the present invention;
• FIG. 2 is a flow diagram illustrating a sequential flow through high-level components;
• FIG. 3 is a flow diagram of one method for roster generation;
• FIG. 4 illustrates an example of an electronic medical record;
• FIG. 5 illustrates one example of person-focused clinical data and a roster;
• FIG. 6 is a flow diagram illustrating a method for facilitating a collaboration session;
• FIG. 7 is an exemplary graphical interface of a collaboration session;
• FIG. 8 illustrates a block diagram of an exemplary computing system environment suitable for use in implementing embodiments of the present invention;
• FIG. 9 illustrates a flow diagram of a method for enabling an online medical collaboration, in accordance with an embodiment of the present invention; and
• FIG. 10 illustrates a flow diagram of another method for enabling an online medical collaboration, in accordance with an embodiment of the present invention.
DETAILED DESCRIPTION
• The present invention provides a system and associated methods that allow for the generation of a roster of potentially available clinicians for a collaboration session with a requesting clinician, and then for facilitating such a collaboration session. This allows for a clinician to better locate others that may provide helpful medical information and/or context to patient-focused clinical data of a medical record. The collaboration session is conducted electronically, enabling the clinicians to be remotely located with respect to one another. Further embodiments of the present invention allow for an online networking system to be used for sharing patient information between clinicians. Oftentimes, a clinician identified by a requesting clinician may not have a medical relationship with the patient, and thus because of relevant privacy regulations, is not able to access patient-identifying information. Thus, the patient information may be de-identified prior to being shared with or accessed by the identified clinician.
• FIG. 1 illustrates an example of a suitable computing system environment in which the invention may be implemented. The computing system environment is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing system environment be interpreted as having any dependency or requirement to any one or combination of components illustrated in the exemplary operating environment.
• The present invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, cellular telephones, portable wireless devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
• The present invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
• With reference toFIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer orcomputing system100. It should be understood that the terms “computer” or “system” may be used interchangeably when referring tocomputing system100.System100 serves at least in part as a general medical information system. Components ofsystem100 include, but are not limited to, aprocessing unit101, asystem memory102, and asystem bus111 that couples various system components including thesystem memory102 to theprocessing unit101. Thesystem bus111 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus and a local bus using any of a variety of bus architecture. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standard Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.
• System100 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed bysystem100 and includes both volatile and nonvolatile media, removable and nonremovable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and nonremovable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed bysystem100. Communications media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has on or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct wired connection, and wireless media such as acoustic, radio frequency (RF), infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
• Thesystem memory102 includes computer storage media in the form of a volatile and/or nonvolatile memory such as read only memory (ROM)103 and random access memory (RAM)105. A basic input/output system (BIOS)104, containing the basic routines that help to transfer information between elements withinsystem100, such as during start-up, s typically stored inROM103.RAM105 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processingunit101. By way of example, and not limitation,FIG. 1 illustratesoperating system106,application programs107,other program modules108, andprogram data109.
• Thesystem100 may also include other removable/nonremovable, volatile/nonvolatile computer storage media. By way of example only,FIG. 1 illustrates ahard disk drive117 that reads from or writes to nonremovable, nonvolatile magnetic media, amagnetic disk drive118 that reads from or writes to removable, nonvolatilemagnetic disk120, and anoptical disk drive119 that reads from or writes to a removable, nonvolatileoptical disk121 such as a CD ROM or other optical media. Other removable/nonremovable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital video disks, digital video tape, Bernoulli cartridges, solid state RAM, solid state ROM, and the like. Thehard disk drive117,magnetic disk drive118 andoptical disk drive119 are typically connected to thesystem bus111 by a Small Computer System Interface (SCSI)112. Alternatively, thehard disk drive117,magnetic disk drive118 andoptical disk drive119 may be connected to thesystem bus111 by a hard disk drive interface, a magnetic disk drive interface, and an optical drive interface, respectively.
• The drives and their associated computer storage media discussed above and illustrated inFIG. 1, provide storage of computer readable instructions, data structures, program modules and other data for thesystem100. InFIG. 1, for example,hard disk drive117 is illustrated as storingoperating system127,application programs128,other program modules129, andprogram data130. Note that these components can either be the same as or different fromoperating system106,application programs107,other program modules108, andprogram data109. A user may enter commands and information into thesystem100 through input devices such as akeyboard123 andpointing device122, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to theprocessing unit101 through auser input interface113 or aserial port interface114 that is coupled to thesystem bus111, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). Amonitor116 or other type of display device is also connected to thesystem bus111 via an interface, such as avideo adapter110. In addition to themonitor116, computers may also include other peripheral output devices such as speakers and printers, which may be connected through an output peripheral interface.
• Thesystem100 may operate in a networked environment using logical connections to one or more remote computers, such as aremote computer133 and/or other communications, such as acommunication device132. Theremote computer133 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to thesystem100, although only a memory storage device has been illustrated inFIG. 1.Remote computer133 may, for example, be found at a variety of health system related locations, such as hospitals, other inpatient settings, pharmacies, a clinician's office, ambulatory settings, testing labs and a patient's home environment, though other locations may be chosen as well. Thecommunication device132 may be a mobile cellular phone, mobile text-pager or other portable communications device, and typically includes some of the elements described above relative to thesystem100. The logical connections depicted inFIG. 1 include a local area network (LAN)126 and a wide area network (WAN)125, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
• When used in a LAN networking environment, thesystem100 is connected to theLAN126 through a networking interface oradapter115. When used in a WAN networking environment, thesystem100 typically includes amodem124 or other means for establishing communications over theWAN125, such as the Internet. Themodem124, which may be internal or external, may be connected to thesystem bus111 via theserial port interface114 or other appropriate mechanism. In a networked environment, program modules depicted relative to thesystem100, or portions thereof, may be stored in the remote storage device. By way of example, and not limitation,FIG. 1 illustratesremote application programs131 as residing onmemory devices132 and133. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers and/or portable communication devices may be used.
• Although many other internal components of thesystem100 are not shown, those of ordinary skill in the art will appreciate that such components and the interconnection are well known. Accordingly, additional details concerning the internal construction of the computer20 need not be disclosed in connection with the present invention.
• Those skilled in the art will understand that program modules such as theoperating system106 and127,application programs107 and128, andprogram data109 and130 are provided to thesystem100 via one of its memory storage devices, which may includeROM103,RAM105,hard disk drive117,magnetic disk drive118 oroptical disk drive119. Preferably, thehard disk drive117 is used to storeprogram data130 and109,application programs107 and128, andoperating system106 and127.
• When thesystem100 is turned on or reset, theBIOS104, which is stored in theROM103 instructs theprocessing unit101 to load the operating system from thehard disk drive117 into theRAM105. Once theoperating system127 is loaded inRAM105, theprocessing unit101 executes the operating system code and causes the visual elements associated with the user interface of theoperating system127 to be displayed on themonitor116. When anapplication program107 and128 is opened by a user or waken up by an inbound request for collaboration, the program code and relevant data are read from thehard disk drive117 and stored inRAM105.
• The sequential flow of activity through a set ofgeneral component modules200, functioning within thesystem100, can be viewed with reference toFIG. 2. Various terminology discussed with respect to the present invention may have particular meaning as described below. For instance, the term “clinician” includes, but is not limited to, a treating physician, specialists such as surgeons, radiologists and cardiologists, emergency medical technicians, physician's assistants, nurse practitioners, nurses, physical therapists, pharmacists, dieticians, microbiologists, and the like, and aides or assistants thereto. The term “patient” refers to a person that is receiving or has received health-care-related services in any location in a medical environment (e.g., hospitals or other inpatient or outpatient settings, a clinician's office, ambulatory settings, testing labs, patient's home environment, or in any other setting). The set ofgeneral component modules200 interact with various types of medical records that contain information about patients. As an example, these medical records may take the form of an electronic medical record (EMR) for a particular patient. The electronic medical record is typically designed to contain various types of information about an individual patient, such as: observed conditions of the patient (e.g., physiological conditions such as blood pressure, oxygen saturation levels in blood, or other “vital signs”); medications taken; current immunizations; food and drug allergies; diagnoses of various clinicians; listing of clinician names that are currently providing or that have provided care to the patient; and may include, directly in the EMR or attached thereto, other files containing various information/data, such as image data (e.g., X-ray, MRI image, skin or tissue photos), voice data (e.g., .wav file or other audio formatted recording of clinician providing patient-related information), or other textual information. The information in an EMR or other medical record as described herein may be referred to generally as patient-focused clinical data. However, it should be understood that the term “medical record”, or “electronic medical record” in particular, should not be interpreted to be limited to any type of computer-readable format or record, but includes any electronically-stored data structure containing information relative to at least one specific patient and from which information may be viewed and/or extracted by the system of the present invention.
• Thegeneral component modules200 include, in one embodiment, a receivingcomponent202, aroster generation component204 and aninterfacing component206. Methods for facilitating collaboration sessions of the present invention generally involve actions that flow from the receivingcomponent202, to theroster generation component204, and on to theinterfacing component206. The receivingcomponent202 may be configured to receive a request for the initiation of a collaboration session between a requesting clinician and one or more other clinicians that may potentially be available to collaborate. Such a collaboration request relates to a piece of the patient-focused clinical data (also referred to as the “context”) that resides, for example, in a medical record, such the particular patient's EMR. Selection of the context causes the request for collaboration session initiation to be generated. Based on the context related to, or contained within, the request, theroster generation component204 begins the building of a roster of specific potentially available clinicians using a selectingsubcomponent208 and aranking subcomponent210. Certain input from the requesting clinician and analysis by theroster generation component204 and subcomponents thereof may be used to configure and arrange the roster of potentially available clinicians for collaboration. Once the roster is complete, theinterfacing component206 sends invitations for a collaboration session for those entities on the roster, and subsequently receives replies from entities interested in joining the session. The interfacing component may also negotiate the capabilities of all collaborating entities, including the requesting clinician, and determines which mode of electronic communication is feasible and/or preferred for the session.
• Onemethod300 of roster generation concerning potentially available clinicians for a collaboration session is presented inFIG. 3. Reference will also be made to thegeneral component modules200 ofFIG. 2. Themethod300 is capable of implementation with a particular patient's EMR, such as amedical record400 shown inFIG. 4, which will be described and referenced along with the discussion ofFIG. 3.
• A requesting clinician will first initiate a request for a collaboration session upon a piece of patient-focused clinical data (i.e., the “context”), instep302. An example of this context is shown inFIG. 4 and generally designated402. Thecontext402 may be generally classified into one of two categories. In either category, the context is preferably hyperlinked for negotiating a certain access protocol to reach the roster building capabilities of theroster generation component204. The hyperlinked context is selectable with any input device (e.g., a mouse). The first category ofcontext402amay include individual caregivers or clinicians listed in themedical record400; in other words, “record related clinicians.” In the example shown, the Primary Care Physician (“PCP”) is “Tom Fangman.” By selecting the Primary Care Physician as the record related clinician, other clinicians having some connection with the Physician may be brought to the attention of the requesting clinician, as will be explained below. Alternatively, the second category ofcontext402bmay include certain types of information or data other than clinicians. For example, certain information inmedical record400 may be eligible as something about which to spur a collaboration request, and may be so identified with certain visual cues, such as a “Collaborate About” icon next to thecontext402b.Context402bcan include, but is not limited to, information such as vital signs, current medications, allergies, clinical diagnoses, and problems articulated by the patient. The receivingcomponent202 receives these selections as requests to build a roster, and invokes theroster generation component204 to conduct a collaboration session.
• The method continues atstep304, where theroster generation component204 analyzes the received selection relating to one of the particular pieces ofcontext402aor402bto identify clinicians having some connection with, or relevancy to, the chosen context. A list of all the clinicians in a given institution that may be contacted may be maintained, for example, in a searchable database of thesystem100 located on one or more of thestorage devices117,118,119, or at another location in a medical information system.
• In the case of thecontext402abeing a clinician (i.e., a record related clinician), other categories of relevant clinicians may include, but are not limited to: (i) clinicians associated with the record related clinician, such as other clinicians in their practice group or organization (e.g., a primary care physician or nurse); (ii) clinicians associated with the record related clinician and the requesting clinician, which may be referred to as “associates-in-common” (e.g., clinicians in the same practice group or organization as the record-associated and requesting clinician, or clinicians frequently utilized by both clinicians); (iii) clinicians that share the same role as the record related clinician, such as in the example ofmedical record400, Primary Care Physicians in addition to “Tom Fangman”; or (iv) clinicians in a “web of care” with the patient whosemedical record400 contains thecontext402a.The concept of web of care relates to a quantitative measurement of the relationship between the clinician and patient. This relationship may take into account a number of factors, including the quality, nature, and frequency of contact or care given by the clinician for the patient, as is explained in U.S. patent application Ser. No. 10/860,458, filed Jun. 4, 2004 and entitled “SYSTEM AND METHOD FOR CREATING A VISUALIZATION INDICATING RELATIONSHIPS AND RELEVANCE TO AN ENTITY,” the teachings of which are incorporated herein by reference.
• Alternatively, when the initiation of a request for a collaboration session is throughcontext402bas data other than clinician names, various relevant clinicians may include, but are not limited to: (i) those clinicians that are authors ofsuch context402bor initiated an activity to derive thecontext402b(e.g., ordered an X-ray attached with the medical record400); or clinicians related to the authors/initiators of thecontext402b,where the relationship involves one of the clinician associations recited above with respect to thecontext402abeing a clinician.
• The activity instep304 of the method is performing a merging of various social networks within an institution to find an initial set of potential clinician collaborators that is at least partially based on the perceived intent of the requesting clinician. Thus, themethod300 is working towards finding the individuals that will have the most relevant information about the patient-focused clinical data.
• After an initial set of potential clinician collaborators relevant to the context is established, and in the case of the patient-focused clinical data being other than a clinician name, i.e.,context402b,theroster generation component204 may analyze thecontext402bfor relevant content to share with the requesting clinician in conjunction with thecontext402b,instep306.
• For instance, this method step may optionally involve selection of a relevance perspective corresponding to thecontext402b.The selected relevance perspective may be used in a clinical relevance scoring algorithm to rank order the roster of potentially available clinicians, as will be more fully explained below. In a sense, the relevance perspective defines a mathematical function modeling a particular health care treatment scenario for a given patient.
• One particular example of a relevance perspective involves identifying the most relevant clinical decision maker for a patient. In this illustration, an applicable mathematical function places a higher value on, for example, the number of medication orders or invasiveness of the procedures undertaken on the patient. Another example of a relevance perspective involves identifying the clinician who, in a sense, best knows the patient's current care plan. This perspective places a higher value on the number of touches rather than the type of touch. In any case, the relevance perspective may either be a default selected by theroster generation component204 for aparticular context402b,or may also selected by the requesting clinician from a predefined set of relevance perspectives stored withsystem100.
• Alternatively, the analysis undertaken by theroster generation component204 instep306 may be conducted without regard to any relevance perspective. For instance, if the requesting clinician wants to collaborate about a diagnosis or medication listed in a given patient'smedical record400, it may be desirable for the requesting clinician and/or any collaborating clinician to select other patient related data (e.g., demographics, past diagnoses) for display or quick reference during a collaboration session. Such additional patient related data may, as an example, be accessed through a hyperlinked uniform resource locator (URL) to allow navigation through the medical information system to a proper file or record location, in accordance with known security and preference privileges, as those of skill in the art will appreciate. This additional patient related data will allow clinicians participating in the collaboration to put into the proper perspective patient issues that become part of the collaboration session.
• Themethod300 may also include, instep308, analyzing the patient-focused clinical data orcontext402 to determine if any software agents should be invited to the collaboration session. Software agents generally include executable software knowledge program modules contained within thesystem100 that monitor and give guidance or other information based on the event flow during a collaboration session. Theroster generation component204 checks an existing mapping of thecontext402 against software agents to determine which software agents may be appropriate for a collaboration session. This mapping may be pre-established in a medical information system (e.g., within a database thereof) based on the usefulness of information provided by the software agents in various situations. One example of a software agent is a question-answer engine that works on-demand for collaboration participants, retrieving information from a patient's EMR or from various databases holding medical information (e.g., the MULTUM database containing drug-drug interactions offered by Cerner Multum, Inc.), and commanding various medical devices to perform a task (e.g., take a blood pressure reading). The software agent may work by using natural language processing to understand requests logged by any collaborating clinician, whether entered into thesystem100 by text, voice recognition or other means. Other actions may be taken by software agents to provide useful information in a collaboration environment, as those of skill in the art will appreciate. As another example, if the initial set of potential clinician collaborators include clinicians of a certain area of practice or specialty, for instance, oncology, then the software agent may provide information such as the definitions of relevant terminology within the specialty field, and may link such information with other information already being presented to the requesting collaborator and potential collaborators relating to the patient-focused clinical data.
• There may be certain situations, however, where software agents may not be invoked even if available. If the processing burden placed on the medical information system by the software agent exceeds a given threshold, or if the particular user interfaces of electronic devices or computers used by the requesting collaborator and potential collaborators cannot display a certain type of content, then software agents may not be invoked at all (e.g., video data on a device displaying text only).
• At this point in themethod300, theroster generation component204 aggregates the initial set of potentially available clinicians from the previous method steps, and any software agents, into a preliminary roster, instep310. Thus, at this point, the entities on the collaboration roster may include both human clinicians as collaborators and executable program modules.
• Then, instep312, theroster generation component204 retrieves presence information for the potentially available clinicians on the roster. Such presence information may indicate contact-type information, such as the clinician's current location, online/offline status, availability, and/or collaboration device capabilities (e.g., forcommunications device132 or remote computer133). For instance, a signal requesting a response may be generated and transmitted bysystem100 to the electronic devices associated with each clinician on the roster. The presence information on the roster may be updated in real-time and displayed as part of the roster so that the requesting clinician is informed of which potential clinician collaborators are, in fact, available for a collaboration session. Duringstep312, thecomponent204 is continuously acquiring, updating, and displaying availability information on the roster. Additionally, the presence information may be displayed in a variety of formats. For example, the color of an individual's name may represent the presence status of that individual. The color red may indicate that the individual is unavailable, yellow may indicate that the individual is busy, and green may indicate that the individual is available for collaboration. Other schemes may obviously be implemented, including other visual or audible cues indicating clinician availability.
• A selectingsubcomponent208 of theroster generation component204 may be used to apply personal preferences of the requesting clinician, as well as institutional preferences and policies, to the roster. This ensures that the roster of potentially available clinicians fully includes all persons that may be helpful and necessary to a collaboration session.
• Specifically, instep314, the selectingsubcomponent208 may apply personal preferences of the requesting clinician to the roster to allow for pre-selection of favorite or preferred collaborators to be included on the roster. These personal preferences may be clinicians with which the requesting clinician frequently collaborates, or software agents that the requesting clinician requires to monitor the collaboration session, as examples. As an illustration, a primary care physician may frequently want to include a particular nurse practitioner in all collaboration sessions conducted by the physician to ensure the best possible communication of relevant issues related to the care of a particular patient discussed in a collaboration session. As another example, a podiatrist as a requesting clinician may require a software agent configured to inject surgical diagrams into a collaboration session where the viewing of video images is possible. As will be understood, other examples may also be envisioned for this method step. These personal preferences are stored within the medical information system and may be edited and updated as desired by the requesting clinician.
• The selectingsubcomponent208 may also take into account preferences and policies of an institution with which the requesting clinician and/or the potentially available clinicians are associated with in their respective medical practices, instep316. Theroster generation component204 manages these preferences, which may include certain clinicians, role groups (e.g., a set of cardiologists), software agents, and the like, and ensures that these representative members of these preferential groups are present on the roster for the collaboration session if possible. The intent is that if an institution develops evidence that certain software agents or consultation patterns produce better outcomes in collaborative exchanges, the medical information system will support this by requiring the inclusion of the appropriate entities (i.e., human collaborators and software agents). Another situation that may necessitate the implementation of institution preferences and policies is when a requesting user is not a fully-trained practicing clinician, such as a student or intern in a health profession. As one example, the institution may require certain supervising clinicians be on the collaboration roster when the requesting user is a student nurse or an intern to evaluate or monitor the collaboration.
• Once this stage of themethod300 has been reached, the roster now contains all of the entities that may potentially be part of a specific collaboration session. Instep318, aranking subcomponent210 of theroster generation component204 is invoked to rank order entities using a clinical relevance scoring algorithm. This step may take into account the relevance perspective ofstep304 and any previous rank ordering of potentially available clinicians.
• Theranking subcomponent210 preferably uses the clinical relevance scoring algorithm to take into account the degree of clinical relevance between the entities on the roster and the piece of person-focused clinical data orcontext402 that was selected by the requesting clinician instep302.FIG. 5 shows one exemplarygraphical interface500 presenting aradiological image502 selected as thecontext402binstep302, and aroster504 of clinicians that have some relevancy to the context (or were otherwise selected by the requesting clinician and/or associated institution). Software agents may also be present on theroster504, though not shown inFIG. 5. Various information about the clinicians may be provided, as more fully explained in previous steps of themethod300.
• The clinical relevance scoring algorithm identifies the most relevant entities for this piece ofcontext402 and conducts roster ranking based on those results. Accordingly, the scoring algorithm may be implemented by a mathematical function that ranks, for theexample roster504 shown inFIG. 5, the author of theradiological image502 first, followed by clinicians on the roster that have looked at the image for the particular patient, other clinicians that have not looked at that particular image but have a certain expertise in understanding radiological images in general (i.e., a radiologist), and lastly, other clinicians that have cared for the particular patient. The mathematical function for this scoring algorithm places a higher ranking value for individuals on the roster that have come in contact the most with the particular patient.
• Generally, the clinical relevance scoring algorithm applies a mathematical function against data collected about particular activity types, including frequency of such activities, in order to rank the collaborators on the roster. The mathematical function may be a simple linear function or a more complex function applied to the activity data. In another illustration, the mathematical function for this scoring algorithm may rank the potentially available clinicians on the roster according to employment relationships with the requesting clinician. This may include clinicians on the roster that are in the same practice/role group as the requesting clinician, such as cardiologists, or that have been on the same medical team as the requesting clinician.
• Continuing withstep320, thesystem100 presents the rank ordered and complete roster of potentially available collaborating entities (i.e., clinicians and software agents) to the requesting clinician for modification thereof. The display of the complete roster may be in tabular form, for example, and presents the collaborator roster as arranged by the clinical relevance scoring algorithm or other rank order schemes. Additionally, the roster may contain a display of real-time presence information for each clinician shown. The requesting clinician can input selections of specific clinicians and software agents that the requester wishes to invite for a collaboration session such as by selecting boxes located next to the name of each potential collaborator. Certain boxes may already be checked or pre-selected based on the requesting clinician's stored preferences and the institution's stored preferences and policies, as described previously forsteps314 and316. The roster of collaborators may be modified by selecting or de-selecting the entities on the complete roster. Optionally, thesystem100 may allow the requesting clinician launch a person-to-person ad-hoc collaboration session with one of the clinicians on the roster whose presence information indicates that that individual is available for collaboration. Such an ad-hoc collaboration may be initiated by, for example, selecting an icon next to the clinician's name, or by clicking on the name itself.
• Preferred modalities of collaboration may optionally be selected by the requesting clinician instep322. These modalities refer to types of communications used in computing systems and other electronic devices. Examples of these modalities include, but are not limited to, text messaging, voice over internet protocol (IP), video, shared whiteboard or other real-time communicative collaboration capabilities, as those of skill in the art will appreciate. The requesting clinician may select one or more of the collaboration modalities, and information relating to these selected modalities may be transmitted as part of the entity invitation process, as will be more fully explained below. Additionally, based on the particular type of communication or computing device to be used by the requesting clinician for the collaboration session, thesystem100 may automatically identify the capabilities of the device and preclude certain modalities of collaboration from being presented as an option for the clinician. Still further, if the particular device used by the requesting clinician is only capable of one modality of collaboration (e.g., a pager capable only of text messaging), then step322 may be skipped.
• At this point, roster generation is complete and the requesting clinician is ready to engage in a collaboration session with at least one of the potentially available clinicians and software agents on the roster. Onemethod600 for facilitating a collaboration session is set forth inFIG. 6 and with continued reference to thegeneral component modules200 of thesystem100 shown inFIG. 2. In accordance withmethod600, theinterfacing component206 receives the completed roster of entities for a collaboration session, and manages the collaborative exchange of information between the requesting clinician and entities that ultimately participate in the session.
• Theinterfacing component206, instep602, and in view of selections made by the requesting clinician on the roster, invites the selected and potentially available clinicians and software agents (the entities) on the roster to participate in a collaboration session. Invitations to collaborate are sent to the entities along with information related to the desired/preferred collaboration modalities of the requesting clinician. In addition, the person-focused clinical data, or context, about which the requesting clinician wishes to collaborate may also be sent as part of the invitation. The clinical context data may optionally be presented as a hyperlinked uniform resource locator that the invited roster entities can invoke to begin a real-time collaboration session with the requesting clinician.
• Thereafter, instep604,interfacing component206 negotiates the capabilities of the responding entities and initiates the appropriate collaboration mechanisms. The requesting clinician, the potentially available clinicians and software agents may be referred to collectively as “collaborators” when invited to, or currently participating in, a collaborative exchange of information within a collaboration session.
• As a first action instep604, the system, throughinterfacing component206, receives replies from the invited collaborators along with the capabilities (i.e., modalities of collaboration) they support. For instance, an invited collaborator may respond by accepting the invitation and indicating that he/she is capable of collaborating through voice communication only. One example of a health care delivery situation where this could apply is with a surgeon presently occupied with a surgical procedure in an operating room. As to outside requesting clinicians seeking to collaborate with the surgeon, it may be most appropriate for the surgeon to provide speaking comments captured by a portable device or computer, but not for them to type any text or view any video images. Alternatively, the surgeon or other invited collaborators may respond by rejecting the invitation or may not respond to the invitation at all. These responses are noted by thecomponent206. The invitations for which no responses have been received may be left as open requests for collaboration or may be rescinded by the system or timed-out based on preferences of the system.
• A number of additional rules may control the responding entities that are allowed to participate in the collaboration session. In one example, collaborative exchanges within the session may be conducted between the requesting clinician and one other clinician, although software agents may simultaneously participate as well. By limiting the session to two clinicians, the requesting clinician avoids information overflow in the exchange and is able to candidly evaluate the information gleaned from the other party without interference or interruption by other clinicians. At the same time, it may be desirable in certain circumstances for a given collaborative session to involve the requesting clinician and multiple other clinicians so that specific questions can be answered quickly by those who possess the best knowledge. The strength of medical opinions (e.g., diagnostic opinions) can also be verified more easily and thoroughly by multiple collaborating entities. As another rule, for invitations to role-groups, such as the “first available cardiologist” or “resident on call”, the system is able to rescind all other invitations to that role group when any one of the clinician members accepts. This may be done by sending a notice to the other members in the role group that the invitation has been rescinded and disabling their ability to enter the collaboration session.
• A second action ofstep604 is, for the invited collaborators who have accepted the invitation, theinterfacing component206 establishing the appropriate connections necessary to initiate the collaboration session. Once the system confirms that such connections are established, instep606, the collaboration session begins using the agreed-upon modalities. During the collaboration session, the requesting clinician may share some or all of the current pieces of patient-focused clinical data (e.g., context402) and any other relevant content with the other collaborators. This may be done by sharing a URL for independent browsing of the record, with each collaborator having their own security and preferences applied, or by other sharing schemes. In one illustration, a requesting clinician may be currently looking at a clinical flow sheet contained in an electronic medical record, and desire that other collaborators look at the same sheet concurrently. The requesting clinician is able to send the URL for that flow sheet to the other collaborators so that each collaborator can browse to the correct location and filter it through their own security and preferences for independent browsing. Additionally, this may be done through an application sharing mode involving co-browsing.
• Typically, collaboration instep606 requires at least one human collaborator, such as a clinician; however, if a software agent has sufficient functionality, the agent may provide relevant information to the requesting clinician based on thecontext402 without any human collaborators present.
• One exemplarygraphical interface700 is provided inFIG. 7, and shows a collaboration session utilizing text message and video modalities for information exchange. Each collaborator can input text intext box702 and view the exchange of textual information indisplay area704. Additionally, the collaborators can see each other in thecamera display area706. Settings for the collaboration session are also configurable so that camera video images, or text messages (i.e., “talking”) may be selectably activated or de-activated during the collaboration session by each collaborator.
• Collaboration session activity instep606 may involve parallel activities of specific software agents that were present on the collaboration roster generated. As a firstparallel activity606awithin the collaboration session facilitated by theinterfacing component206, software agents monitor the communicative exchange between clinicians in the collaboration session for specific triggering events of interest. If such a triggering event is realized, a secondparallel activity606bis invoked where the software agent may perform one of a range of clinically relevant tasks. Illustrations of triggering events of interest may include a spoken word, a typed phrase, a call to the agent by name, user actions such as the sharing a newly created piece of patient-focused clinical data, or other type of event. As an example, during a collaboration session, the requesting clinician may call for a software agent called “OrderBot” to order a specific medication, in this case Acetaminophen 375 mg. OrderBot will then take action to order the prescribed medication for that particular patient. Another example may be a natural language processing agent that is aware of medical terminology that highlights words in text messages or voice transcripts, hyper linking them to their definitions or to related clinical actions from an evidence-based medicine standpoint. Still further, another example of a triggering event response may be software agents that act as question-answer systems on demand from collaborators, or agents that passively monitor the collaboration session and build annotated and conceptually abstracted transcripts. All of these software agents are capable of injecting the results into the events stream of the collaboration session.
• Thegeneral component module200 may additionally include astoring component212 for storage any transcript or log of events and data streams built by the software agent or other system component during the collaboration session. Each transcript may be stored within the given patient's electronic medical record (i.e., the patient associated with the context402) as a clinical document. Such transcripts may also take the form of the preferred modality of the collaboration session, such as text messaging, voice, or other modalities as previously explained. Additionally, each transcript may be stored in a personal clinician record as a clinical document. Personal clinician records may be secure documents that can only be accessed by authorized users (e.g., may be password protected, etc.). Such personal clinician records are preferred when a collaboration session: (i) involves a general private conversation that is not to be accessed or reviewed by everyone who has authorized access to a given patient's record; or (ii) a specific private conversation based on the fact that the collaboration session spanned multiple patients and multiple pieces ofcontext402.
• Once a transcript is embedded in or electronically attached to a patient record, it may be retrieved and viewed or played back in much the same way that a piece of patient-focused clinical data is chosen when initiating a request for a collaboration session. An example of a transcript may be theclinical document506 displayed in the roster list shown inFIG. 5. In this way, the transcript itself may function as thecontext402 about which the requesting clinician desires to have a communicative collaborative exchange with another clinician.
• Therefore, the present invention can be seen to achieve increased efficiencies in the delivery of health care related services. These efficiencies are realized because, with the present invention, clinicians can more quickly and completely understand patient-focused clinical data in a respective electronic medical record by collaborating with other clinicians and software agents that have some level of specific knowledge and/or expertise to lend. Furthermore, since certain changes may be made in the above invention without departing from the scope hereof, it is intended that all matter contained in the above description or shown in the accompanying drawing be interpreted as illustrative and not in a limiting sense.
• Referring now toFIG. 8, a block diagram is provided illustrating an exemplarycomputing system environment800 suitable for use in implementing embodiments of the present invention. It will be understood and appreciated by those of ordinary skill in the art that thecomputing system environment800 shown inFIG. 8 is merely an example of one suitable computing system environment and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the present invention. Neither should thecomputing system environment800 be interpreted as having any dependency or requirement related to any single module/component or combination of modules/components illustrated therein. Among other components not shown, thesystem800 includes a requestingcomputing device802, a receiving computing device803, adata store806, and an online networking system, that communicate with each other by way of anetwork804. Thenetwork804 may be, in one embodiment, one or more local area networks (LANs). Alternatively, thenetwork804 may take the form of a wide area network, which may include, without limitation, one or more wide area networks (WANs), such as the Internet. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. Accordingly, thenetwork804 is not further described herein.
• In some embodiments, one or more of the illustrated components/modules may be implemented as stand-alone applications. In other embodiments, one or more of the illustrated components/modules may be integrated directly into other components. It will be understood by those of ordinary skill in the art that the components/modules illustrated inFIG. 8 are exemplary in nature and in number and should not be construed as limiting. Any number of components/modules may be employed to achieve the desired functionality within the scope of embodiments hereof. Further, components/modules may be located on any number of servers, client devices, or the like.
• With continued reference toFIG. 8, each of thecomputing devices802 and803 and theonline networking system808 may be any type of computing device, such ascomputing device100 described with reference toFIG. 1, for example. A computing device as used herein may include a laptop, smart phone device, a tablet, PDA, a personal computer, or any other device that can communicate by way of thenetwork804. The requestingcomputing device802 and the receiving computing device803 may communicate with one another indirectly, such as when the requestingcomputing device802 communicates a message and a patient-focused clinical data element to theonline networking system808, and the receiving computing device803 accessed that patient data through theonline networking system808. In one embodiment, a user of the requestingcomputing device802 sends a request through theonline networking system808 that includes an identification of one or more other clinicians with whom the requesting clinician would like to collaborate. This collaboration may include a request for a second opinion regarding, for instance, treatment options or a diagnosis of a particular patient.
• Alternatively, the requesting clinician may simply want to share patient information with another clinician for that clinician's information, such as if the other clinician may also be involved in the treatment of the patient. The other clinician, in one embodiment, is a resident physician or a nurse who works directly with the requesting clinician such that the patient information may be relevant to the other clinicians. This is a convenient way of sharing information if the clinicians are physically located in the same geographical area (e.g., same building or complex) or if the clinicians are located in different geographical areas. In yet another embodiment, the requesting clinician may not be sending a request to another clinician, but may like to send certain pieces of information from a patient's EMR to review at a later time. The patient information may thus be uploaded onto the online networking system and reviewed at a later time. There may be more than one clinicians identified by the requesting clinician, and as such there may be multiple receiving computing devices803, although one is shown inFIG. 8 for simplicity. As such, it should be understood that any number of computing devices may be employed within thesystem800 within the scope of the present invention. Each may comprise a single device or multiple devices cooperating in a distributed environment. Additionally, other components not shown may also be included within thesystem800, while components shown inFIG. 8 may be omitted in some embodiments.
• Theonline networking system808 may include various components including a requestingcomponent810, a determiningcomponent812, adata de-identifying component814, and a communicatingcomponent816. While four components are illustrated inFIG. 8, other components may be utilized in various embodiments and are contemplated to be within the scope of the present invention. As mentioned, theonline networking system808 generally functions as an interactive system for clinicians in the medical field. It may take the form of a website or multiple websites that are accessible to clinicians who are registered with the system. As such, one clinician may share or request a consultation (e.g., second opinion) with another clinician who is also registered with the system. As such, a clinician may access theonline networking system808 by way of, for example, the Internet and may use a user interface on a website to make requests and send patient information, such as patient-focused clinical data elements from a patient's EMR to other clinicians.
• The requestingcomponent810 is generally responsible for receiving requests from requesting clinicians and processing the requests in the system. The requestingcomponent810 may determine whether the one or more clinicians identified in the request are registered with theonline networking system808. If a clinician is not registered, an attempt may be made theonline networking system808 to contact that clinician and ask if he or she would like to register with the system, as there is a message or request pending from another clinician. The requestingcomponent810 also may analyze the request to determine what type of request is being made, such as if the request is to share information or if the request is to ask for assistance, in which case the receiving clinician would be asked to respond to the request by the requesting clinician and likely provide information to the requesting clinician via theonline networking system808.
• The determiningcomponent812 determines whether the identified clinician(s) is allowed access to the patient-identifying data included in the request. As mentioned, the request may include a patient-focused clinical data element which, in one embodiment, is pulled directly from the patient's EMR, and thus may include information that identified the patient. Depending on the applicable privacy regulation, patient-identifying information may not be allowed to be shared with clinicians not associated with the patient, such as clinicians who are not currently treating the patient or clinicians who work directly with the treating clinician (e.g., nurse, physician's assistant, resident physician). In this case, the patient-identified information would need to be removed prior to being sent to the identified clinician. Adata store806 may be accessed by the determiningcomponent812 to determine whether the identified clinician(s) is allowed access to the patient-identifying information.
• In one embodiment, the determiningcomponent812 utilizes a rules-based authentication subsystem or an equivalent system that is able to automatically determine, given names and other identifying information of both the patient and the receiving clinicians, whether the receiving clinicians are allowed access to the patient-identifying information of a particular patient. For exemplary purposes only, XACML is one type of rules-based authentication subsystem that may be used to make these types of determinations. The rules used by the rules-based authentication subsystem may include, for example, that any clinician listed below has an ongoing professional, medical relationship with the patient, and thus is allowed access to the patient-identifying data. As such, the subsystem would understand that any other clinician not listed is not granted access to the identifying information.
• Even further, in one embodiment, the communication of de-identified patient data to the receiving clinicians may act as an initial inquiry to determine if there are any clinicians who are interested in responding to the collaboration request sent by the requesting clinician. As such, a receiving clinician may decide to act as a consultant, and thus may eventually be granted access to the full set of data, including patient-identifying information. This may happen, for instance, with the requesting clinician and the patient's consent. Joining the collaboration as a consultant enables a deeper collaboration with a full set of patient data accessible by the new consultant. In one instance, the initial request with de-identified data may act as a “fishing expedition” to identify the most qualified specialists in a particular area, and to further identify those who are interested in joining the medical team
• The datade-identifying component814 de-identifies the data by removing all forms of data that may contribute to identification of the patient. For example, current HIPAA privacy standards mandate that eighteen specific identifiers would need to be removed prior to sharing the patient information. These identifiers include names, geographic subdivisions smaller than a state, all elements of dates (except year) related to an individual (including dates of admission, discharge, birth, death and, for individuals over 89 years old, the year of birth must not be used), telephone numbers, FAX numbers, electronic mail addresses, Social Security numbers, medical record numbers, health plan beneficiary numbers, account numbers, certificate/license numbers, vehicle identifiers and serial numbers including license plates, device identifiers and serial numbers, web URLs, Internet protocol addresses, biometric identifiers (including finger and voice prints), full face photos and comparable images, and any unique identifying number, characteristic or code. The removal of patient-identifying information may be done manually, or alternatively may be done automatically using an algorithm that recognizes words and numbers that would need to be removed. While patient-identifying information, in compliance with HIPPA, for example, may be removed before being sent to a receiving clinician, the de-identified data retains sufficient clinical detail to enable the collaboration to proceed. As such, the de-identification process will preserve sufficient clinical information to enable the responding clinician to make a decision whether or not to collaborate.
• In one embodiment, a requesting clinician may wish to share patient information in a collaborative environment, such as in an online networking system, but may not have a particular clinician in mind with which the requesting clinician wishes to share information. In this case, the patient information may be published onto the online networking system for many clinicians to see. Here, the patient information would be de-identified to remove all patient-identifying information, This type of online sharing and collaboration allows a larger set of clinicians to review the patient information and respond to the requesting clinician with ideas for diagnosis and treatment of the patient. De-identifying data allows many different clinicians to be able to review the patient's information in a social networking setting. For instance, a generic message may be sent to all neurologists by a requesting clinician who has a patient with a potential neurological disorder. One or more neurologists may then review the information and provide feedback to the requesting clinician regarding a possible diagnosis. Even further, embodiments of the present inventions may be used similar to social networking sites where a message with de-identified patient information is broadcast to a group of clinicians who are in the network of the requesting clinician.
• The communicatingcomponent816 communicates the message and patient-focused clinical data elements to the identified or receiving clinician(s). While this communication may comprise sending an electronic communication directly to the identified clinician(s), it may also or alternatively publish or post the information on theonline networking system808, such as a website associated therewith, and alert the clinician that information is ready to be viewed. The receiving clinician(s) may then access the message and patient information by signing on to theonline networking system808 to view the information and request. If the request and patient are posted online, it may be accessible only to the receiving clinicians and not any other clinician that has access to theonline networking system808.
• In one embodiment, any communications between the requesting clinician and the receiving clinician(s) may be archived and saved to the patient's EMR for future reference. This may occur no matter if the receiving clinician was given access to the full EMR or de-identified data associated with the patient's EMR. For example, if the requesting clinician asked a particular receiving clinician with expertise in a particular heart condition to consult on a case, the information received back from the receiving clinician, or specialist, may be needed in the future care of the patient, and thus archiving this information may be extremely helpful in the future. Further, having a record of what information was sent, what was received, etc. may also prove to be helpful in the future, especially with ongoing privacy concerns regarding what information is made available to clinicians who are not authorized to have access to patient identifying information. While in one embodiment this collaboration information is archived to the patient's EMR, in another embodiment, this information may be archived in a different location, such as in a separate database that stores all of the collaboration information for a particular hospital, medical office, etc.
• Turning now toFIG. 9, a flow diagram of amethod900 for enabling an online medical collaboration is illustrated, in accordance with an embodiment of the present invention. Initially, an identification of a clinician(s) and a patient-focused clinical data element is received from a requesting clinician atstep910. As mentioned, the patient-focused clinical data element may be a portion of the patient's EMR, and is retrieved and sent to the online networking system to be shared with other clinicians. Atstep912, it is determined whether the receiving or identified clinician is allowed access to the patient-identifying data that is contained within the patient-focused clinical data element or other patient information sent through the system. As mentioned, a clinician may be allowed access to patient-identifying information if the clinician is within a network of clinicians responsible for treating the patient. This may include a clinician within the same office as the requesting clinician or a clinician not associated with the requesting clinician, but who currently treats the patient. If it is determined that the clinician is allowed access to the patient-identifying data, the patient-focused clinical data element with patient-identifying data is shared with the identified clinician atstep914. If the clinician, however, is not allowed access to the patient-identifying data associated with the particular patient, the patient-focused clinical data element is de-identified atstep916 and the de-identified information is shared with the clinician atstep918. As such, for a clinician who is not treating the patient or who is not otherwise associated with the medical care of the patient, this clinician would only receive the patient's medical information with all patient-identifying data having been removed.
• Referring toFIG. 10, a flow diagram is shown of amethod1000 for enabling an online medical collaboration, in accordance with an embodiment of the present invention. Atstep1010, a request is received that includes an identification of a clinician who is allowed to access patient-identifying data. As such, this clinician may be associated with the treatment of the patient, or for some other reason is allowed to access the patient's identifiable information. At step1012, a patient-focused clinical data element is received from the patient's EMR. In one embodiment, more than one patient-focused clinical data element is received at the online networking system. The requesting clinician, for example, may need a second opinion or need assistance from a specialist to determine the best treatment option for the patient, and thus may send relevant patient information to the online networking system so that another clinician can access the patient information and assist in this determination. In one embodiment, if the patient information is being sent to a clinician who also treats the patient, the information may not need to be de-identified prior to being accessed by the clinician. Atstep1014, the request and the patient-focused clinical data element is communicated to the clinician. In one embodiment, this information is communicated by being posted on a website associated with the online networking system so that the identified clinician(s) is able to access the data and respond to the request.

Claims (20)

1. A method in a computer system having a processor and a memory for providing an online medical collaboration, the method comprising:

receiving from a requesting clinician through an online networking system for medical clinicians an identification of one or more clinicians to whom at least one patient-focused clinical data element is to be communicated;

identifying a first subset of the one or more clinicians to whom the requesting clinician is not authorized to send the at least one patient-focused clinical data element that includes patient-identifying data;

de-identifying the at least one patient-focused clinical data element such that it does not include any of the patient-identifying data; and

communicating the at least one de-identified patient-focused clinical data element to the first subset of the one or more clinicians.

2. The method ofclaim 1, further comprising:

identifying a second subset of the one or more clinicians to whom the clinician is authorized to send the at least one patient-focused clinical data element that includes the patient-identifying data; and

communicating the at least one patient-focused clinical data element to the second subset of the one or more clinicians.

3. The method ofclaim 2, further comprising communicating a message from the requesting clinician to the first subset and the second subset of clinicians.

4. The method ofclaim 3, wherein the at least one patient-focused clinical data element provides context in relation to a particular patient for the message communicated to the one or more clinicians.

5. The method ofclaim 1, wherein the requesting clinician is requesting the one or more clinicians to provide a second opinion on the medical condition or medical treatment of a patient corresponding to the at least one patient-focused clinical data element.

6. The method ofclaim 1, wherein de-identifying the at least one patient-focused clinical data element further comprises removing any of the patient-identifying data to comply with relevant privacy regulations.

7. The method ofclaim 1, wherein the at least one de-identified patient-focused clinical data element is communicated by way of the online networking system.

8. The method ofclaim 7, wherein the online networking system is a medical networking website for medical clinicians.

9. The method ofclaim 1, wherein communicating the at least one de-identified patient-focused clinical data element further comprises posting a message and the at least one de-identified patient-focused clinical data element on the online networking system that is accessible only to the first subset of the one or more clinicians.

10. One or more computer storage media having computer-executable instructions embodied thereon that, when executed, enable a computing device to perform a method of providing an online medical collaboration, the method comprising:

receiving a request from a requesting clinician to share a message and at least one patient-focused clinical data element with one or more clinicians by way of an online networking system for medical clinicians;

determining if at least one of the one or more clinicians is not allowed access to the at least one patient-focused clinical data element having patient-identifying data;

if the at least one of the one or more clinicians is not allowed access to the at least one patient-focused clinical data element having patient-identifying data,

(1) de-identifying the at least one patient-focused clinical data element having patient-identifying data,

(2) sharing the at least one de-identified patient-focused clinical data element with the at least one of the one or more clinicians, and

(3) sharing the at least one patient-focused clinical data element that has not been de-identified with the one or more clinicians who are allowed access to the at least one patient-focused clinical data element having patient-identifying data; and

if the at least one of the one or more clinicians is allowed access to the at least one patient-focused clinical data element having patient-identifying data, sharing the at least one patient-focused clinical data element having patient-identifying data with the one or more clinicians.

11. The method ofclaim 10, wherein the at least one of the one or more clinicians not allowed access to the patient-identifying data are not currently associated with a patient corresponding to the at least one patient-focused clinical data element.

12. The method ofclaim 11, wherein a clinician is not currently associated with the patient if the clinician is not currently treating the patient for a medical condition.

13. The method ofclaim 10, wherein an amount and a type of data de-identified from the at least one patient-focused clinical data element corresponds to a current privacy regulation.

14. The method ofclaim 10, wherein sharing the at least one de-identified patient-focused clinical data element further comprises posting a message and the at least one de-identified patient-focused clinical data element on the online networking system accessible only to the at least one of the one or more clinicians.

15. The method ofclaim 10, wherein the at least one of the one or more clinicians allowed access to the patient-identifying data are either currently treating the patient or are directly associated with the requesting clinician.

16. The method ofclaim 10, wherein the at least one patient-focused clinical data element is located in an electronic medical record (EMR) associated with the patient.

17. One or more computer storage media having computer-executable instructions embodied thereon that, when executed, enable a computing device to perform a method of providing an online medical collaboration, the method comprising:

receiving, from a requesting clinician through an online networking system for medical clinicians, a request that includes an identification of at least one clinician to collaborate in medical care of a particular patient, wherein the at least one clinician is associated with the medical care of the patient such that the at least one clinician is allowed to access patient-identifying data for the patient;

receiving at least one patient-focused clinical data element associated with the patient, wherein the at least one patient-focused clinical data element is found in an electronic medical record associated with the patient and wherein the at least one patient-focused clinical data element includes the patient-identifying data; and

communicating the request and the at least one patient-focused clinical data element to the at least one clinician.

18. The method ofclaim 17, wherein the request to collaborate in the medical care of the particular patient is a request for a second opinion regarding a treatment or a medical diagnosis of the particular patient.

19. The method ofclaim 17, wherein communicating the request and the at least one patient-focused clinical data element to the at least one clinician further comprises publishing the request and the at least one patient-focused clinical data element on the online networking system such that it can be accessed by the at least one clinician who is registered with the online networking system.

20. The method ofclaim 17, further comprising determining that the at least one clinician is associated with the particular patient in a way allowed by a privacy regulation such that the at least one clinician is allowed to view the patient-identifying data.

Images