[ad_1]
Methods
The display is driven by a single query, identifying active ED visits by selecting encounters with an ED arrival date/time and a null ED departure date/time within the electronic health record (EHR) application database. The query is re-submitted approximately every 5 min using a batch scheduling process as the principal data refresh mechanism. Query output volumes for the enterprise typically range between 200 and 300 concurrent visits during midday and evening hours, decreasing to 50–100 visits in the overnight period.
The output is organised in a matrix display format, reserving a row for each ED facility. The facility’s geographical region is concatenated with its name as the top-level grouping in a single-tier hierarchical structure. This method was chosen to consolidate data for presentation while still allowing the user to visually aggregate data by region through a dual sorting technique (figure 1).
TeleEM Dashboard matrix display format.
After establishing a base query and data presentation structure, we considered how to balance our goal of pre-emptive patient identification based on our telehealth programme’s activation criteria, with limited data afforded by near real-time monitoring. For example, if a local clinician suspects that a patient may have an intracranial haemorrhage, data present within the EHR provide few options for early identification of this situation by a remote audience. A diagnostic finding, such as the result of a head CT, could provide a reliable data source; however, the examination’s turnaround time precludes its use as an early identification mechanism.
Alternatively, the clinician may articulate a hunch and related decision-making in a working draft of the visit. Although we thought that this could potentially mitigate data availability issues at times, data storage within our EHR presented a limitation. As of the date of this publication, medical decision-making within ED provider notes was not stored discretely and we did not have integration with a natural language processing tool that could facilitate a technical path forward. As a result, we considered other more readily available data sources as potential markers:
-
ESI (Emergency Severity Index) level: patient’s acuity as assessed on presentation.
-
Chief complaint: patient’s principal complaint(s) as recorded on patient arrival.
-
Vital signs: initial and subsequent measurements manually recorded or automatically captured in the EHR through biomedical device integration.
-
Ventilator usage: indication based on device data such as flow rate or ventilator mode of operation manually recorded or automatically captured in the EHR through biomedical device integration.
-
Medical history: discrete medical history data of diagnosed conditions or problems from across the continuum of care.
-
Active care plans: discrete, condition and patient-specific care from across the continuum of care.
-
Clinical decision support: existing asynchronous alerts built into our EHR, which continually assess biometric data and diagnostic findings to aid in the identification of certain high-risk conditions.
-
Documentation tool use: metadata maintained in our EHR that identifies the use of scenario-specific charting tools for trauma, code, sedation, stroke and potential ST-elevation myocardial infarction (STEMI) cases.
-
Order set selection: metadata maintained in our EHR which identifies the use of complaint or scenario-oriented order sets.
-
Medication ordering behaviour: groupers of orderable medications categorised by pharmacological indications.
These data sources became the basis for a cross-walk, mapping TeleEM activation criteria into broader alert categories that could leverage available data markers as illustrated in table 1.
TeleEM activation criteria mapping to alert categories
With this initial set of alert categories defined, we devised a rule-based approach to evaluate each active visit returned in the master query against a set of rules (21) that would independently test each alert category’s conditions. These rules contained a mixture of functions using standard logical operations to perform direct data checks as well as additional embedded sub-level rules as demanded by the category’s level of evaluation complexity, particularly if multiple data types were to be examined (eg, vitals data plus chief complaint…or medical history plus use of a specific order set).
Ultimately, each top-tier level rule produced a Boolean response, where 1-Yes signified affirmation that an alert category’s conditions were met. We then assigned a column to each alert category on the matrix display and used a ‘total count’ function to sum the number of 1-Yes responses found for each region-facility combination present in the row data. To improve readability, a colour-coding schema was applied to produce a red highlight whenever a row’s count of 1-Yes responses was greater than 0 (figure 2). Based on this preemptive warning, remote viewers could drill down into the underlying visit details for each facility and ultimately the respective patient chart to further assess the situation prior to contacting the local clinician.
TeleEM Dashboard alert category display by facility.
[ad_2]
Source link
