Integrating pre-hospital encounters into an electronic medical record

Methods, computer systems, and computer storage media are provided for integrating pre-hospital encounters into an electronic medical record (EMR). An electronic Situation-Background-Assessment-Recommendation (SBAR) tool is provided that guides a clinician to gather demographic information and encounter information. The demographic information associated with one or more patients is received via the SBAR tool. The encounter information is received via the SBAR tool. At least a portion of the demographic information and the encounter information is communicated via the SBAR tool, while in transit via an emergency vehicle, to a healthcare facility. The demographic information and the encounter information are integrated into an EMR associated with each patient.

BACKGROUND

Many patients are transported to hospitals via ambulances, helicopters, and other emergency vehicles. Information captured during these transports, if any, is fractured and does not get directly communicated to an electronic medical record (EMR). A lack of an electronic version of a Situation-Background-Assessment-Recommendation (SBAR) tool integrated into the EMR exacerbates this breakdown in communication. Further, there is not a useable EMR for the emergency medical services (EMS) market that is accessible via a tablet platform. Any information that is available is typically faxed or provided orally to a healthcare facility when communication protocols are available. Still further, ancillary conditions can negatively affect transport time, resources available, and benchmarks that define time limits on treatments. Each of these deficiencies result in lost opportunities for providing effective and efficient treatment as well as receiving full reimbursement for the care provided.

BRIEF SUMMARY

Embodiments of the present invention relate to integrating pre-hospital encounters into an EMR. An electronic SBAR tool is provided that guides a clinician to gather demographic information and encounter information. The demographic information associated with one or more patients is received via the SBAR tool. The encounter information is received via the SBAR tool. At least a portion of the demographic information and the encounter information is communicated via the SBAR tool, while in transit via an emergency vehicle, to a healthcare facility. The demographic information and the encounter information are integrated into an EMR associated with each patient.

DETAILED DESCRIPTION

Embodiments of the present invention capture previously missing pieces of a population's health. Many patients are transported to hospitals via emergency vehicles (e.g., ambulances and helicopters). The information captured in these vehicles is fractured and does not end up directly in the EMR. Further, there is not an electronic version of the SBAR communication tool that integrates into the EMR.

Accordingly, in one aspect, an embodiment of the present invention is directed to a method for integrating pre-hospital encounters into an EMR. The method includes providing an electronic SBAR tool that guides a clinician to gather demographic information and encounter information. The method further includes receiving the demographic information associated with one or more patients via the SBAR tool. The encounter information is received via the SBAR tool. At least a portion of the demographic information and the encounter information is communicated via the SBAR tool, while in transit via an emergency vehicle, to a healthcare facility.

In another aspect of the invention, an embodiment is directed to a graphical user interface (GUI). The GUI comprises a patient demographics display area that displays one or more links to tools that guide a clinician to gather demographic information and encounter information for a patient. An encounter display area displays encounter tools configured to receive encounter information. A SBAR display area displays an editable SBAR form that is communicated, while in transit, to a healthcare facility.

In a further aspect, an embodiment is directed to system environment for integrating pre-hospital encounters in an EMR. The system includes an SBAR component that provides an SBAR tool that guides a clinician to gather demographic information and encounter information. A receiving component receives demographic information and encounter information associated with one or more patients via the SBAR tool. A communication component communicates via the SBAR tool, while in transit via an emergency vehicle, at least a portion of the demographic information and the encounter information to a healthcare facility and enables two-way communication between the SBAR tool and the healthcare facility. An integration component integrates the demographic information and encounter information into an EMR associated with each patient. An ancillary information component receives ancillary information. The ancillary information comprises weather information, traffic information, traffic signal information, and environment information that affects an estimated time of arrival. The ancillary information further calculates the estimated time of arrival based on the ancillary information. A protocol component provides an actionable protocol based on the encounter information and the ancillary information and receives a response or dismissal of an action associated with the actionable protocol. The response or dismissal includes a justification. A time limit component receives a time limit associated with the actionable protocol.

An exemplary computing environment suitable for use in implementing embodiments of the present invention is described below.FIG. 1is an exemplary computing environment (e.g., medical-information computing-system environment) with which embodiments of the present invention may be implemented. The computing environment is illustrated and designated generally as reference numeral100. The computing environment100is merely an example of one 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 environment100be interpreted as having any dependency or requirement relating to any single component or combination of components illustrated therein.

The present invention might be operational with numerous other purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that might be suitable for use with the present invention include personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above-mentioned systems or devices, and the like.

The present invention might be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Exemplary program modules comprise routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. The present invention might 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 might be located in association with local and/or remote computer storage media (e.g., memory storage devices).

With continued reference toFIG. 1, the computing environment100comprises a computing device in the form of a control server102. Exemplary components of the control server102comprise a processing unit, internal system memory, and a suitable system bus for coupling various system components, including data store104, with the control server102. The system bus might 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 architectures. Exemplary architectures comprise Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronic Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus, also known as Mezzanine bus.

The control server102might operate in a computer network106using logical connections to one or more remote computers108. Remote computers108might be located at a variety of locations in a medical or research environment, including clinical laboratories (e.g., molecular diagnostic laboratories), hospitals and other inpatient settings, ambulatory settings, medical billing and financial offices, hospital administration settings, home healthcare environments, clinicians' offices, Center for Disease Control, Centers for Medicare & Medicaid Services, World Health Organization, any governing body either foreign or domestic, Health Information Exchange, and any healthcare/government regulatory bodies not otherwise mentioned. Clinicians may comprise a treating physician or physicians; specialists such as intensivists, surgeons, radiologists, cardiologists, and oncologists; emergency medical technicians; physicians' assistants; nurse practitioners; nurses; nurses' aides; pharmacists; dieticians; microbiologists; laboratory experts; laboratory technologists; genetic counselors; researchers; students; and the like. The remote computers108might also be physically located in nontraditional medical care environments so that the entire healthcare community might be capable of integration on the network. The remote computers108might be personal computers, servers, routers, network PCs, peer devices, other common network nodes, or the like and might comprise some or all of the elements described above in relation to the control server102. The devices can be personal digital assistants or other like devices.

Computer networks106comprise local area networks (LANs) and/or wide area networks (WANs). Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. When utilized in a WAN networking environment, the control server102might comprise a modem or other means for establishing communications over the WAN, such as the Internet. In a networking environment, program modules or portions thereof might be stored in association with the control server102, the data store104, or any of the remote computers108. For example, various application programs may reside on the memory associated with any one or more of the remote computers108. It will be appreciated by those of ordinary skill in the art that the network connections shown are exemplary and other means of establishing a communications link between the computers (e.g., control server102and remote computers108) might be utilized.

In operation, an organization might enter commands and information into the control server102or convey the commands and information to the control server102via one or more of the remote computers108through input devices, such as a keyboard, a pointing device (commonly referred to as a mouse), a trackball, or a touch pad. Other input devices comprise microphones, satellite dishes, scanners, or the like. Commands and information might also be sent directly from a remote healthcare device to the control server102. In addition to a monitor, the control server102and/or remote computers108might comprise other peripheral output devices, such as speakers and a printer.

Although many other internal components of the control server102and the remote computers108are not shown, such components and their interconnection are well known. Accordingly, additional details concerning the internal construction of the control server102and the remote computers108are not further disclosed herein.

Turning now toFIG. 2, an exemplary computing system environment200is depicted suitable for use in implementing embodiments of the present invention. The computing system environment200is 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 the computing system environment200be interpreted as having any dependency or requirement related to any single module/component or combination of modules/components illustrated therein.

The computing system environment200includes a display device250(e.g., dashboard, computer, mobile device, and the like) associated with an emergency vehicle240, one or more medical devices242associated with the emergency vehicle240, pre-hospital encounter engine210, EMR260, and one or more healthcare facilities262, all in communication with one another via a network202. The network202may include, without limitation, one or more secure local area networks (LANs) or wide area networks (WANs). The network202may be a secure network associated with a facility such as a healthcare facility. The secure network202may require that a user log in and be authenticated in order to send and/or receive information over the network202.

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 distributed across multiple pre-hospital encounter engines210. The components/modules illustrated inFIG. 2are 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. By way of example only, the pre-hospital encounter engines210might reside on a server, cluster of servers, or a computing device remote from one or more of the remaining components.

The EMR260is configured to provide information to and store information communicated by, for example, the pre-hospital encounter engine210. The information stored in association with the EMR260is configured to be searchable for one or more items of information stored in association therewith. The information stored in association with the EMR260may comprise information received from or used by various components of the pre-hospital encounter engine.

The EMR260may store EMRs of patients associated with one or more healthcare facilities. EMRs may comprise electronic clinical documents such as images, clinical notes, orders, summaries, reports, analyses, information received from pre-hospital encounter engine210and medical devices242, or other types of electronic medical documentation relevant to a particular patient's condition and/or treatment. Electronic clinical documents contain various types of information relevant to the condition and/or treatment of a particular patient and can include information relating to, for example, patient identification information, images, alert history, culture results, physical examinations, vital signs, past medical histories, surgical histories, family histories, histories of present illnesses, current and past medications, allergies, symptoms, past orders, completed orders, pending orders, tasks, lab results, other test results, patient encounters and/or visits, immunizations, physician comments, nurse comments, other caretaker comments, clinician assignments, and a host of other relevant clinical information.

The content and volume of such information in the EMR260is not intended to limit the scope of embodiments of the present invention in any way. Further, though illustrated as a single, independent component, the EMR260may, in fact, include a plurality of applications and/or storage devices, for instance, a database cluster.

The display device250may be any type of display device capable of communicating via the network202with the pre-hospital encounter engine210, the EMR260, the healthcare facilities262, or the medical devices242. Such devices may include any type of mobile and portable devices including cellular telephones, personal digital assistants, tablet PCs, smart phones, and the like.

The display of the display device250is configured to display information to the user of the display device250(i.e., an emergency responder). The information may include communications initiated by and/or received by the pre-hospital encounter engine210. Embodiments are not intended to be limited to visual display but rather may also include audio presentation, visual presentation, combined audio/visual presentation, and the like.

Components of the pre-hospital encounter engine210may include a processing unit, internal system memory, and a suitable system bus for coupling various system components, including one or more data stores for storing information (e.g., files and metadata associated therewith). The pre-hospital encounter engine210typically includes, or has access to, a variety of computer-readable media.

The computing system environment200is merely exemplary. While the pre-hospital encounter engine210is illustrated as a single unit, it will be appreciated that the pre-hospital encounter engine210is scalable. For example, the pre-hospital encounter engine210may in actuality include a plurality of computing devices in communication with one another. The single unit depictions are meant for clarity, not to limit the scope of embodiments in any form.

As shown inFIG. 2, the pre-hospital encounter engine210comprises, in various embodiments an SBAR component212, a receiving component214, a communication component216, an integration component218, an ancillary information component220, a protocol component222, a time limit component224, a media component226, a consultation component228, a priority component230, a reallocation component232, and a monitor component234. In some embodiments, one or more of the components may be implemented as stand-alone applications. It will be understood that the components illustrated inFIG. 2are exemplary in nature and in number and should not be construed as limiting. Any number of components may be employed to achieve the desired functionality within the scope of embodiments hereof.

SBAR component212provides an SBAR tool that guides a clinician to gather demographic information and encounter information. The SBAR tool provides various tools that enable the clinician to capture information relevant to the particular situation. Receiving component214receives demographic information and encounter information associated with one or more patients via the SBAR tool and associated tools. For example, tools may include a keyboard tool to document the encounter, a subjective-objective-assessment-plan (SOAP) narrative tool to create SOAP notes for the encounter, a Broselow tool to quickly identify correct dosage of medication and equipment sizes, an Revised Trauma Score (RTS) scoring tool to triage the patient while in transit to the healthcare facility, a Parkland formula tool to provide an indication of a burn percentage of a patient via a rule of 9's tool that calculates the appropriate amount of resuscitation fluid needed by the patient. Additional encounter tools may include a drug calculator tool, a drug look up tool, a call information tool a medications and allergies tool, a Glasgow Coma Scale (GCS) tool, a treatments and procedures tool, a transmit tool that transmits information to the healthcare facility, a forms tool that provides forms to the patient in advance of the patient's arrival at the healthcare facility, and a photographs tool that captures and communicates photographs of the patient to the healthcare facility.

Communication component216communicates via the SBAR tool, while in transit via an emergency vehicle, at least a portion of the demographic information and the encounter information to a healthcare facility. The information may be communicated directly to the healthcare facility or to an EMR associated with the patient accessible by the healthcare facility. Communication component216further enables two-way communication between the SBAR tool and the healthcare facility. Encounter information may further be provided by the one or more medical devices242. In one embodiment, monitor component234monitors equipment (e.g., medical devices) in the emergency vehicle. Monitor component234may communicate medical device information directly to the pre-hospital encounter engine210, the EMR260, or the healthcare facility262.

Integration component218integrates the demographic information and the encounter information into an EMR associated with each patient. Integration component218may communicate the demographic information and the encounter information via the network202to the EMR260or to a healthcare facility262. Integration component218enables information that may otherwise be lost during an emergency encounter to be documented and charted in the EMR. In so doing, integration component218prevents repeated work or care from being provided because documentation regarding such pre-hospital work is readily accessible to the clinicians treating the patient at the healthcare facility (e.g., hospital).

Ancillary information component220receives ancillary information. The ancillary information may comprise weather information, traffic information, traffic signal information, and environment information and may affect an estimated time of arrival. The ancillary information component220calculates the estimated time of arrival based on the ancillary information. For example, ancillary information component220may receive ancillary information that indicates construction will delay an emergency vehicle headed to a particular healthcare facility. The delay may cause the ancillary information component220to reroute the emergency vehicle to a different healthcare facility, alter the path the emergency vehicle travels to the particular healthcare facility, identify and request additional resources (e.g., a different type of emergency vehicle) that can arrive faster or in a more timely manner than the current emergency vehicle, or determine the clinician associated with the particular emergency vehicle should perform a particular action (i.e., actionable protocol) based on the delay or estimated time or arrival.

Protocol component222provides an actionable protocol based on the encounter information and the ancillary information. Protocol component222further receives a response or dismissal of an action associated with the actionable protocol. The response or dismissal may include a justification. This may enable a healthcare facility or clinician to be reimbursed for the actionable protocol if a particular action related to the actionable protocol is not able to be performed or the patient refuses the action. Time limit component224receives a time limit associated with the actionable protocol. The time limit may be related to a required amount of time a particular action must be performed relative to a particular event or another action.

In one embodiment, media component226receives physical pictures and/or video of the patient via the SBAR tool. Media component226may communicate the physical pictures and/or video to the healthcare facility via the communication component216. In one embodiment, consultation component228enables a clinician consultation via the SBAR tool. The communication component216may provide the two-way communication necessary for the consultation. The consultation enables a remote clinician (e.g., healthcare facility or primary care clinician) to provide a consultation for the patient.

In one embodiment, priority component230prioritizes patients for the healthcare facility based on the encounter information and the ancillary information. The priority allows the healthcare facility to triage and prepare for patients arriving by emergency vehicles. In one embodiment, reallocation component232reallocates resources for a patient in trauma. Resources may be reallocated based on priority or based on specific information associated with the encounter information.

Turning now toFIG. 3, a flow diagram is provided illustrating a method300for integrating pre-hospital encounters into an EMR, in accordance with an embodiment of the present invention. Initially, as shown at step310, an electronic SBAR tool is provided that guides a clinician to gather demographic information and encounter information. Demographic information associated with one or more patients is received, at step312, via the SBAR tool. The encounter information is received via the SBAR tool at step314. At least a portion of the demographic information and the encounter information is communicated via the SBAR tool, at step316, while in transit via an emergency vehicle, to a healthcare facility. At step318, the demographic information and the encounter information is integrated into an EMR associated with each patient. In one embodiment, patients are prioritized for the healthcare facility based on the encounter information and the ancillary information. In one embodiment, resources are reallocated for a patient in trauma. For example, the healthcare facility is able to utilize the information integrated into each patient's EMR to prepare resources that may be required by each patient. In one embodiment, the SBAR tool monitors equipment in the emergency vehicle and may communicate any information received from the equipment to the EMR, the healthcare facility, or a clinician associated with the healthcare facility.

In one embodiment, ancillary information is received by the SBAR tool. The ancillary information may comprise weather information, traffic information, traffic signal information, and environment information. The ancillary information may affect an estimated time of arrival of the emergency vehicle at the healthcare facility. For example, heavy traffic, malfunctioning traffic signals, or bad weather may cause delays in the arrival time. Similarly, environment information, such as criminal activity in the area, may also cause delays in the arrival time. The SBAR tool utilizes the received ancillary information, in one embodiment, to calculate the estimated time of arrival. The estimated time of arrival may influence recommendations or actionable protocols provided by the SBAR tool.

In one embodiment, two-way communication between the SBAR tool and the healthcare facility is enabled. The two-way communication may provide the healthcare facility with additional information necessary to prepare for the arrival of the patient. The two-way communication may additionally provide the clinicians associated with the emergency vehicle information that may assist the clinicians in providing care to the patient. In one embodiment, physical pictures and/or video of the patient is received via the SBAR tool. In one embodiment, the physical pictures and/or video is communicated, via the SBAR tool, to the healthcare facility. In one embodiment, a clinician consultation is enabled via the SBAR tool, enabling a clinician not physically located in the emergency vehicle to provide a consultation for the patient. For example, the clinician may physically be located at the healthcare facility awaiting the patient. The clinician may be the primary care physician associated with or a clinician that has previously provided care for the patient.

In one embodiment, an actionable protocol based on the encounter information and the ancillary information is provided via the SBAR tool. The actionable protocol may instruct a clinician to perform action or a series of actions. The actions are charted within the SBAR tool and communicated to the EMR, enabling the care provided while in the emergency vehicle to be reimbursed. In one embodiment, a response or dismissal of an action associated with the actionable protocol is received. The response or dismissal may include a justification. For example, the protocol may require the clinician to chart the blood pressure of the patient. In order to be reimbursed, the clinician may be required to follow the protocol. However, if the patient has no arms or refuses care, the clinician may dismiss the action associated with the blood pressure, provide the justification for dismissing the action, and proceed to the next action.

In one embodiment, a time limit associated with the actionable protocol is received. The time limit is utilized by the SBAR tool to provide a record of the time required to perform actions associated with the actionable protocol. Performing the actions within the time limit may affect reimbursement and because the SBAR tool is able to confirm whether the time limits are met, the SBAR tool may maximize and streamline the reimbursement process.

With reference toFIGS. 4-6, illustrative screen displays for integrating pre-hospital encounters into an EMR are provided. It is understood that each of the illustrative screen displays are connected logically, such that they comprise a user interface designed for integrating pre-hospital encounters into an EMR. The screen displays may appear in any order and with any number of screen displays, without regard to whether the screen display is described or depicted herein. The screen displays provide tools that enable pre-hospital encounters to be integrated into EMR.

Referring now toFIG. 4, an illustrative screen display400of an embodiment of the present invention is shown. A patient demographics display area400that displays one or more links410,420,430to tools that guide a clinician to gather demographic information and encounter information for a patient. The link410to the patient demographics tool enables the clinician to launch a tool that receives demographics information associated with the patient. The link420to the patient assessment tool enables the clinician to launch one or more tools that receive assessment information associated with the patient. Similarly, the link430to the vital signs tool provides the clinician with the current vital signs432of the patient.

Turning now toFIGS. 5 and 6, illustrative screen displays500,600of embodiments of the present invention are shown. Encounter display area500displays encounter tools configured to receive encounter information. The encounter tools may include a keyboard tool510that opens a keyboard512allowing the clinician to document. A SOAP narrative tool520enables the clinician to create SOAP notes for the encounter. A Broselow tool530enables the clinician to open an electronic version of the Broselow tape532to quickly identify correct dosage of medication and equipment sizes. An RTS scoring tool540provides the clinician an electronic physiologic scoring system to triage the patient while in transit to the healthcare facility. The RTS may also be communicated to the healthcare facility to allocate resources to a patient in trauma, prior to the arrival of the patient. A Parkland formula tool550enables the clinician to electronically provide an indication of a burn percentage of a patient via a rule of 9's tool552and calculate the appropriate amount of resuscitation fluid needed by the patient.

Encounter display area600displays additional encounter tools configured to receive encounter information. The additional encounter tools may include: a drug calculator tool610, a drug look up tool620, a call information tool630, a medications and allergies tool640, a GCS tool650, a treatments and procedures tool660, a transmit tool670, a forms tool680, and a photographs tool690. The transmit tool670enables the clinician to transmit demographic information and/or encounter information to the healthcare facility. The forms tool680enables the clinician to provide forms to the patient in advance of the patient's arrival at the healthcare facility. The forms tool680may also receive required signatures form the patient for the various forms. The photographs tool690enables the clinician to capture and communicate photographs of the patient to the healthcare facility.

InFIG. 7, an illustrative screen display700of an embodiment of the present invention is shown. A SBAR display area displays an editable SBAR form that is communicated, while in transit, to a healthcare facility. The SBAR form enables the clinician to document the situation710and any concerns712regarding the patient's status. The SBAR form further enables the clinician to document and/or review the patient's background720, including the most recent and/or previous vital signs. Still further, the SBAR form enables the clinician to provide an assessment730of the patient and provide an indication of potential problems732affecting the patient. The SBAR form also enables the clinician to provide a recommendation740for the patient. The recommendation may be made from a dropdown menu750or from a list of common protocols754.

Referring now toFIG. 8, a flow diagram is provided illustrating a method800for integrating pre-hospital encounters into an EMR, in accordance with an embodiment of the present invention. Initially, as shown at step810, an emergency vehicle is contacted. Information is provided to the emergency vehicle, at step812. At step814, a decision is made whether an air unit is needed. A ground unit is dispatched at step816. The emergency vehicle arrives on the scene at step818. At step820, an automatic response determines what resources will respond to a given scenario and resources are added, if necessary, at step822.

An initial assessment is provided at the scene utilizing the SBAR tool, at step824. Procedures, medications, and past medical history are documented via the SBAR tool, at step826, based on the initial assessment. A more focused examination is then provided, at step828, utilizing the SBAR tool. Procedures, medications, and past medical history are documented via the SBAR tool, at step830, based on the more focused examination. At step832, a transport/ongoing assessment is prepared. The assessment is communicated, via the SBAR tool, to a receiving healthcare facility at step834.

Still referring toFIG. 8, the emergency vehicle arrives at the receiving healthcare facility at step836. Report is given to receiving personnel at step838. An electronic version of the run sheet is communicated via the SBAR tool, at step840, to the receiving healthcare facility and integrated into the patient's EMR. Billing is autogenerated based on the information communicated by the SBAR tool at step842. After the patient is treated and released at step844, billing is autogenerated again, at step846, based on additional information received by the patient's EMR. Information regarding the pre-hospital encounter is provided to the patient's primary care provider at step848.

As can be understood, the present invention provides systems, methods, and user interfaces for providing clinical decision support based on a patient's clinical situation. The present invention has been described in relation to particular embodiments, which are intended in all respects to be illustrative rather than restrictive. Alternative embodiments will become apparent to those of ordinary skill in the art to which the present invention pertains without departing from its scope.